Transcript SE 532 Software Quality Management

Team Software Project
Concept / Launch Phase topics
Planning Phase
6/05/2007
SE 652 - TSP Strat/Launch/Plan
1
Due Today
• Project Plan
– Draft, baseline post class (COB Wednesday – June 7)
• Presentation
– Functionality
– Development approach, estimates, etc.
• Weekly Meeting kick-off
– First weekly minutes including WEEK form
6/05/2007
SE 652 - TSP Strat/Launch/Plan
2
Deliverables
Course deliverables include everything – not just the final program
(e.g. SRS, User Documentation, CM Plan)
Deliverables should demonstrate team collaboration
– Clarity in presentation, to the point
– Review/inspect all team deliverables
– Ensure quality records created & maintained
6/05/2007
SE 652 - TSP Strat/Launch/Plan
3
Team Meeting
Meeting Objective
Synchronize on upcoming activities, assess status, raise issues, assign action items,
discuss resolutions
Gather & analyze the team’s data for prior week and to date
Change Control Board, but may need additional reviews during some phases
Interval
Once a week (for formal meeting)
Follow WEEK script (modified)
Capture
Discussions
Decisions
Action Items
Issues
Risks
Data (ala WEEK form)
Output
Weekly minutes document
TASK & SCHEDULE forms (when applicable)
Updated Project Notebook
6/05/2007
SE 652 - TSP Strat/Launch/Plan
4
Launching a Project – Goals
Typical Project Goals
Customer Needs
Target Market
Date
Functionality
Goal Setting
Unrealistic Goals = demotivator
Aggressive but realistic = ideal
Cisco Strategy
“Under-commit, exceed customer expectations”
But,
A reputation for “sandbagging” can be very dangerous
6/05/2007
SE 652 - TSP Strat/Launch/Plan
5
Goal Setting
Use a confidence level to set goals (e.g. 90%)
SMART Goals
Specific
Measurable
Actionable
Realistic
Timely
6/05/2007
SE 652 - TSP Strat/Launch/Plan
6
Project Team Goals
Produce a quality product
Example metrics:
Defect density
Customer satisfaction
Run a productive & well managed product
Example metrics:
Estimates vs. Actual
Quality Records
Morale
Finish on Time:
Example metrics:
Schedule variation
6/05/2007
SE 652 - TSP Strat/Launch/Plan
7
Commitment
What is it?
A promise!
Commitment pitfalls
Frequently implied (assumed commitment)
Frequently given even though intent is not a commitment
6/05/2007
SE 652 - TSP Strat/Launch/Plan
8
TSPi Tool
6/05/2007
SE 652 - TSP Strat/Launch/Plan
9
TSP Development Phase
Preliminary Plan
Documentation:
Conceptual Design (in Project Plan)
STRAT form (in Project Plan)
ITL log (Risks & Issues – extended version)
6/05/2007
SE 652 - TSP Strat/Launch/Plan
10
Development Strategy
Why Plan?
Common understanding of objective & work required
Basis for tracking work completion
Provides assessment of effort required & if objectives are achievable
6/05/2007
SE 652 - TSP Strat/Launch/Plan
11
Development Approach
Waterfall
Iterative
Build one, throw it away
Rapid Application Design (RAD)
Extreme Programming (XP)
6/05/2007
SE 652 - TSP Strat/Launch/Plan
12
Strategy Assessment
Development Approach / Conceptual Design
High Level System Architecture (components)
Size estimate (LOC, FP)
Effort (staff hours, days, weeks)
Time (calendar time)
Functionality
Risks
Configuration Management Process
6/05/2007
SE 652 - TSP Strat/Launch/Plan
13
Project Plan Presentations
Project Plan Drafts
Discussion
Overall . . .
Fluff (from a previous class)
Background
“The developers at XYZ Labs have been expending a large amount of resources
manually counting LOC. It has come to the attention of management that it
would be a cost effective solution …. There are no commercially available off
the shelf solutions ….. The customer has provided a need statement, …”
“This system is intended to be a deliverable for our software quality management
class. Our objectives are to deliver a quality product on schedule, have fun,
and learn while we’re at it.”
Users
“There will be a hierarchy of users of the system. The top level will be the
primary customer…”
“A user of this system consists of any individual who wishes to obtain LOC
metrics and track various software version changes.”
6/05/2007
SE 652 - TSP Strat/Launch/Plan
15
Other Project Plan Notes
Roles – document team assignments including summary of deliverables by person
Update & Maintain risk section
Break out detailed schedule to MS Project
6/05/2007
SE 652 - TSP Strat/Launch/Plan
16
Feature List Summary
A-Team – used variant of STRAT form
Broke out features, but would be useful to include estimates
(though template didn’t help here)
Trinity
Provided a little more detail, but no reference to target cycle
Recommendation: use STRAT form
6/05/2007
SE 652 - TSP Strat/Launch/Plan
17
2007 SE652 High Level Development Schedule
Date
June 05
Milestone
June 12
C1 Launch, Strategy &
Plan
C1 Requirements
June 19
C1 Design
June 26
C1 Implementation
July 3*
C1 System Test
July 10
Entry
Exit
Project Plan
Project Plan
Baselined C1 Requirements
Baselined Requirements
Baselined C1 High Level Design
Baselined High Level
Design
Unit & Integration Tested Code
Other team’s integration
passed application
Zero Defect application
C1 Post Mortem
C2 Launch & Plan
Completed C1 development
Updated C2 Project Plan
July 17
C2 Requirements
Baselined C2 Project Plan
Baselined C2 Requirements
July 24
C2 Design &
Implementation
Baselined C2 Requirements
Baselined C2 High Level Design
Unit & Integration Tested Code
July 31
C2 System Test
Other team’s integration
passed application
Zero Defect application
August 7
C2 Post Mortem
Completed C2 development
Final, etc.
6/05/2007
SE 652 - TSP Strat/Launch/Plan
18
Strategy Forms –
Requirements & Coding Estimates
Estimates:
Team
Metric
Steve
Document
(Pages)
Greg
Code
(LOC)
Document
(Pages)
Ron
Code
(LOC)
Document
(Pages)
Code
(LOC)
Units / Hour
Total Phase1
units
Total Phase2
units
6/05/2007
SE 652 - TSP Strat/Launch/Plan
19
Other Suggested Improvements
6/05/2007
SE 652 - TSP Strat/Launch/Plan
20
What is a risk?
Examples from prior Project Plans
“Use of java as a programming language”
“Smaller group size”
“Team members drop out of class”
“Requirements must be dropped in Cycle 2, due to compressed…”
“Hourly slip in schedule in Cycle 2…”
6/05/2007
SE 652 - TSP Strat/Launch/Plan
21
Risks
Defined:
Issues – will happen
Risks – are potential problems
probability of an undesirable event occurring and impact/consequences
3 Risk Components
– Event
– Probability of occurrence
– Impact
Risk Management Objectives
Take proactive steps to minimize the probability & consequences of adverse
events
6/05/2007
SE 652 - TSP Strat/Launch/Plan
22
What is a risk?
Examples from prior Project Plans
“Use of java as a programming language”
“Smaller group size”
“Team members drop out of class”
“Requirements must be dropped in Cycle 2, due to compressed…”
“Hourly slip in schedule in Cycle 2…”
6/05/2007
SE 652 - TSP Strat/Launch/Plan
23
Risk Management Strategy
• Identify
e.g. brainstorming, “moose on the table”
• Assess risk exposure
– Plan
determine which risks to manage/mitigate
• Track – build tripwires into project plan
• Mitigate
• Communicate
6/05/2007
SE 652 - TSP Strat/Launch/Plan
24
Risk Mitigation
Avoidance
Transference
Mitigation
Acceptance
Risk reduction
risk choice
6/05/2007
– eliminate the risk
– shift consequence of risk to another party
– reduce the probability &/or consequence
– conscious decision to not change plan
– e.g. avoidance/mitigation strategy shifting to a lower
SE 652 - TSP Strat/Launch/Plan
25
Risk Details from Project Plan
“Team Members may drop out during the course, leaving the remaining team members
with extra unscheduled & unfamiliar work. To prevent this, the importance of all
present team members will be heavily stressed. However if a team member does
drop the course, there is no other choice but to redistribute the responsibilities.”
“Mitigated by the similarities between Java and other languages. Accepted due to the
expected increase in productivity of primary developer.”
6/05/2007
SE 652 - TSP Strat/Launch/Plan
26
Risk from Previous Offering Project Plan
Description: Situation arises where the schedule documented in the project plan is unrealistic or is
unachievable, resulting in the product not being able to be delivered on time with desired
functionality and quality given the level of staff and project resources.
Probability: 30%
Impact (1 to 10 scale, 10 high impact/loss): 10
Risk Exposure: 3
First Indicator: Delivery of first draft of requirements document falls behind schedule.
Mitigation Approaches
–
–
–
–
Allow certain amount of slack or buffer time in schedule for delays.
Analyze time necessary to deliver proposed functionality per iteration to determine if there is necessary
time to deliver product on scheduled delivery date and use this information to generate schedule.
Agree to less functionality in first iteration in order to better estimate schedule for second iteration of
development.
Allow for one member of the team at any given time to be in a Waiting state, where they do not have a
specified task to complete and are available for performing delayed task.
Owner: Mark
Current Status: Risk Control
Contingency Plan: Utilize slack time in schedule to minimize effect of delay and utilize free team
member to quicken task delivery pace until project is on schedule.
Trigger for Contingency Plan: Milestone in project is not met on time.
6/05/2007
SE 652 - TSP Strat/Launch/Plan
27
Indirect Risk Mitigation
Risk: All functionality may not be ready to go at the start of the new fiscal
year
Mitigation:Build “bridge code” between old system and new, using subsystems 3 & 4 of old until all is ready
Probability: 50%
Tripwire: If all DDRs are not passed by 12/21/1997, we build bridge
Cost: “Al” + 2 contractors = 6 work months = $200K
6/05/2007
SE 652 - TSP Strat/Launch/Plan
28
Ring Software, Ltd.
Risk Identification
You were previously a project manager at Ring Software who has just been
promoted to lead the EZ Procurement Release 2 project, a B to B system that
enables customers to automate their procurement processes and achieve
price reductions through the included supplier bidding system.
Release 1 was a dismal “success”. Though the project finally got out the
door, it was a year late, under-featured and “buggy”. The customers are
very unhappy with the release and sales are suffering, putting the company’s
future at risk.
The team morale is awful. They worked nights and weekends for the last 2+
years and are worn out. Recently, developers have started resigning to
follow their fortunes elsewhere, rather than face a repeat performance on R2.
There are extensive standard processes, but most are not followed with the
excuse that there isn’t enough time.
Your predecessor was terminated on the grounds of mismanaging the
release.
Your job is to deliver R2 with quality, on time and on budget or suffer the
fate of your predecessor.
6/05/2007
SE 652 - TSP Strat/Launch/Plan
29
Some Risk Mitigation Strategies
Risk
Mitigation Strategy
Personnel
Training
Team building
Communication (e.g. team meetings)
Reassignment
Budget & Schedule
Design to budget
Reduce feature commitment
Renegotiate schedule
Developing wrong product
Prototyping
User surveys
Too large or ambitious project
Requirements scrubbing
Cyclic software development
Too many unknowns
Prototyping, Cyclic Development
Excessive changes
Real-time performance
Control adders (cost/benefit)
Simulation, prototyping
6/05/2007
SE 652 - TSP Strat/Launch/Plan
30
Configuration Management Process
Three aspects:
Change Tracking
Version Control
Library
Objectives:
Product content known & available at all times
Product configuration is documented & provides known basis for changes
Products labeled & correlated w/ associated requirements, design & product info
Product functions traceable from requirements to delivery
All product contents properly controlled & protected
Proposed changes identified & evaluated for impact prior to go/no go decisions
6/05/2007
SE 652 - TSP Strat/Launch/Plan
31
Configuration Management
Types of product elements
Maintained (e.g. software)
Baselined & Maintained (e.g. SRS)
Quality Records (e.g. meeting notes, action item list)
Key Functions
Latest Version of each product element (software, documents, quality records)
Copies of prior versions of each product element
Who changed from previous version
When changed
What changed
Why changed
6/05/2007
SE 652 - TSP Strat/Launch/Plan
32
Configuration Management Plan
Configuration identification
•Name Configuration items
•Owner
•Storage location
Configuration control procedure
•Process for making changes, lock-out procedures (e.g. check-out, check-in procedures)
Configuration control board (CCB)
•Reviews all change requests
•Determine if change is appropriate, well understood & resources available
•Approvals, commitments
•? Defects: holding for CCB vs. urgency of change ?
Configuration change request form (CCR, aka CR)
Baseline Process (see page 326)
Backup procedures & facilities
Configuration status reports (CSR)
Software Change Management status reports @ weekly meeting
6/05/2007
SE 652 - TSP Strat/Launch/Plan
33
Baseline Considerations
Criteria
–
–
–
–
Defined in Configuration Management Plan
Review / inspection completed & stakeholders recommend approve for
baseline
All major and blocking issues should be resolved
CRs tracking any remaining (and unresolved) issues
Actions
–
–
Update version # to reflect baselined document (e.g. 1.0)
Place under change control
Project “Baseline” – snapshot of CIs, baselined & current versions
6/05/2007
SE 652 - TSP Strat/Launch/Plan
34
Automated Configuration Mgmt
Lucent: Sablime / SBCS & SCCS
Rational: DDTS / ClearCase
Perforce Software: Perforce
Microsoft: Visual SourceSafe
MKS
6/05/2007
SE 652 - TSP Strat/Launch/Plan
35
Change Workflow
New / Proposed
Study
Assigned
NoChange
Deferred
Declined
Resolved
Integrated
Delivered
Verified
6/05/2007
SE 652 - TSP Strat/Launch/Plan
36
Due Next Week
Requirements (SRS) draft for inspection
Draft to Quality Manager & instructor by COB Friday
Configuration Management Plan (draft)
Planning Baselines
Updated & Baselined Project Plan
MS Project schedule (replaces Task & Schedule forms)
SUMP
Heads Up: System Test Planning, Quality/Measurement Plan
Standard Forms (i.e. Weekly meeting minutes, WEEK form)
6/05/2007
SE 652 - TSP Strat/Launch/Plan
37
Backup Slides
TSP Development Plan
Purpose:
Basic structure of work
Scheduling the tasks
Balancing the workload
Progress Tracking
Planning & Tracking:
Time Estimates => Earned Values => Progress Tracking
Plan Contents
Component list
Task list & their allocation to team members
Team schedule & team member schedules
Team quality plan
6/05/2007
SE 652 - TSP Strat/Launch/Plan
40
Planning Process
System – component – module – object
Higher level product assembly of lower level parts
Planning starts from the bottom:
– Size estimate of lower level => time estimates for higher level
Component size estimates => time estimates per task
6/05/2007
SE 652 - TSP Strat/Launch/Plan
41
TSP Development Plan Script
Input:
Development Strategy
Conceptual Design
Output:
Task & Schedule Forms
SUMP, SUMQ & SUMS Forms
6/05/2007
SE 652 - TSP Strat/Launch/Plan
42
TSPi Support Tool
Input: logs, forms & templates
Planning output:
• Team & team member task plans
• Team & team member schedules
• Project Quality Plan
Tracking output:
• Project status information
• Completed tasks, time & defects
But, a tool is just a tool:
It only accepts & calculates data,
Responsibility for planning belongs to the team
6/05/2007
SE 652 - TSP Strat/Launch/Plan
43
TSP Task & Size Summary
Size Summary (SUMS)
TASK & SCHED forms
Plan Summary (SUMP)
Quality Plan (SUMQ)
Final Planning steps
TSPi Tool Setup:
Enter Project Information (Team Leader)
Enter Team Members & Roles (Team Leader)
Size Estimates
Populate TASK form (generate task list button)
Enter product & process deliverables (TASK) into SUMS
Estimate & enter size information
Enter software component names & sizes
Tool Notes:
Highest Level “part of” = SYSTEM
Valid size measures: Text pages, Req pages, HLD pages, DLD pages, LOC
6/05/2007
SE 652 - TSP Strat/Launch/Plan
44
TSP Task List & Schedule Plan
Size Summary (SUMS)
TASK & SCHED forms
Plan Summary (SUMP)
Quality Plan (SUMQ)
Final Planning steps
TSPi Tool:
Use previously generated task list
Add in additional tasks identified
Enter time estimates for each role
(note: if > 10 hours, consider splitting task into smaller components)
If not entered from SUMS, enter:
• Size estimates
• Measurement unit
• Rate / hour
Rollup # hours / week for all team members and add to SCHED form
Verify total planned hours from SCHED form supports estimates
Note: SUMP Size & Time data should be automatically populated
6/05/2007
SE 652 - TSP Strat/Launch/Plan
45
Quality Plan
Size Summary (SUMS)
TASK & SCHED forms
Plan Summary (SUMP)
Quality Plan (SUMQ)
Final Planning steps
TSPi Tool:
Estimate defects injected in each phase
note: tool uses defects injected / hour (even for LOC)
Estimate defect removal yield for each defect removal phase (see table 5.8)
Compare SUMQ results with table 5.8
How to interpret:
Compare table 5.8 percent defect free (PDF) / phase with SUMQ Process
Yields
Adjustments to improve PDF:
Lower defect injection rates
Increase time in defect removal activities to improve yields
6/05/2007
SE 652 - TSP Strat/Launch/Plan
46
Final Planning Steps
Size Summary (SUMS)
TASK & SCHED forms
Plan Summary (SUMP)
Quality Plan (SUMQ)
Final Planning steps
Individual Engineer Plans
Assign tasks to each engineer based on available hours / week
Generate individual copies of TASK & SCHDULE forms
Delete task hours assigned to other engineers
Add in individual tasks
Balance Team Workload (TASK form)
Produce Consolidated Team Plan (SUMP, SUMQ, TASK, SCHED)
6/05/2007
SE 652 - TSP Strat/Launch/Plan
47
Quality Plan Measures
Summary Rates
Productivity (LOC / hour)
Reuse percentages
TSP Defect Definition
Requirements, Design or implementation issue which could cause improper design,
implementation, test, use or maintenance of the product.
Major – modifies executable
Minor – does not impact executable (e.g. comments, formatting)
Percent Defect Free (PDF)
% of components with no defects in a phase
Objective: steadily increasing PDF for each successive phase
Analysis hint: look at high defect parts, likely to be the source of future problem
6/05/2007
SE 652 - TSP Strat/Launch/Plan
48
Defect Metrics
Provide targets for the following measures in your Quality Plan:
Defects/Page (e.g. requirements, HLD)
Defects/KLOC
Graph by phase – should show decreasing #’s
Graph by module – shows potential problem sources
Defect Ratios
Code review / compile
Design review / unit test
higher #’s indicate better up front defect removal
Defect-Injection Rates
# of defects injected per unit (e.g. hours)
Defect-Removal Rates
# of defects removed per unit (e.g. hours)
6/05/2007
SE 652 - TSP Strat/Launch/Plan
49
Additional Metrics
Development Ratios
Design Review Time / Total Design Time
Requirements Inspection Time / Total Requirements Time
Appraisal / Failure Ratio
Review & Inspection Rates (TSPi p103 for guidelines)
e.g. # pages / hour, # LOC / hour
Phase Yield
% defects removed in a given phase
Actual yield #’s decline as defects found in later phases
(note: phase intro very important data to capture)
Process Yield
% defects removed prior to entering a given phase
6/05/2007
SE 652 - TSP Strat/Launch/Plan
50
Quality Plan Summary
Only requires tracking a few items:
Time
Unit measures (e.g. LOC)
Defects
Phase Introduced
Phase Detected
In-Process Status
Look for quality trends (e.g. decreasing find rates)
Investigate high defect objects
Scan ratios focusing on prevention activities (e.g. reviews)
But,
GIGO rule applies!
6/05/2007
SE 652 - TSP Strat/Launch/Plan
51