6/05/2007se 652 - tsp strat/launch/plan1 team software project concept / launch phase topics...
Post on 22-Dec-2015
218 Views
Preview:
TRANSCRIPT
6/05/2007 SE 652 - TSP Strat/Launch/Plan 1
Team Software Project
Concept / Launch Phase topics
Planning Phase
6/05/2007 SE 652 - TSP Strat/Launch/Plan 2
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 3
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 4
Team Meeting
Meeting ObjectiveSynchronize on upcoming activities, assess status, raise issues, assign action items,
discuss resolutionsGather & analyze the team’s data for prior week and to dateChange Control Board, but may need additional reviews during some phases
IntervalOnce a week (for formal meeting)
Follow WEEK script (modified)Capture
DiscussionsDecisionsAction ItemsIssuesRisksData (ala WEEK form)
OutputWeekly minutes document TASK & SCHEDULE forms (when applicable)Updated Project Notebook
6/05/2007 SE 652 - TSP Strat/Launch/Plan 5
Launching a Project – Goals
Typical Project GoalsCustomer Needs
Target Market
Date
Functionality
Goal SettingUnrealistic 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 6
Goal Setting
Use a confidence level to set goals (e.g. 90%)
SMART GoalsSpecific
Measurable
Actionable
Realistic
Timely
6/05/2007 SE 652 - TSP Strat/Launch/Plan 7
Project Team Goals
Produce a quality productExample metrics:
Defect density
Customer satisfaction
Run a productive & well managed productExample metrics:
Estimates vs. Actual
Quality Records
Morale
Finish on Time:Example metrics:
Schedule variation
6/05/2007 SE 652 - TSP Strat/Launch/Plan 8
Commitment
What is it?A promise!
Commitment pitfallsFrequently implied (assumed commitment)
Frequently given even though intent is not a commitment
6/05/2007 SE 652 - TSP Strat/Launch/Plan 10
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 11
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 12
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 13
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 15
Project Plan DraftsDiscussion
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 16
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 17
Feature List Summary
A-Team – used variant of STRAT formBroke out features, but would be useful to include estimates
(though template didn’t help here)
TrinityProvided a little more detail, but no reference to target cycle
Recommendation: use STRAT form
6/05/2007 SE 652 - TSP Strat/Launch/Plan 18
2007 SE652 High Level Development Schedule
Date Milestone Entry ExitJune 05 C1 Launch, Strategy &
PlanProject Plan
June 12 C1 Requirements Project Plan Baselined C1 Requirements
June 19 C1 Design Baselined Requirements Baselined C1 High Level Design
June 26 C1 Implementation Baselined High Level Design
Unit & Integration Tested Code
July 3* C1 System Test Other team’s integration passed application
Zero Defect application
July 10 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 19
Strategy Forms – Requirements & Coding Estimates
Estimates:
Team Steve Greg Ron
Metric
Document(Pages)
Code(LOC)
Document (Pages)
Code(LOC)
Document(Pages)
Code(LOC)
Units / Hour
Total Phase1units
Total Phase2units
6/05/2007 SE 652 - TSP Strat/Launch/Plan 21
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 22
Risks
Defined:Issues – will happenRisks – are potential problems
probability of an undesirable event occurring and impact/consequences
3 Risk Components– Event– Probability of occurrence– Impact
Risk Management ObjectivesTake proactive steps to minimize the probability & consequences of adverse
events
6/05/2007 SE 652 - TSP Strat/Launch/Plan 23
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 24
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 25
Risk Mitigation
Avoidance – eliminate the risk
Transference – shift consequence of risk to another party
Mitigation – reduce the probability &/or consequence
Acceptance – conscious decision to not change plan
Risk reduction – e.g. avoidance/mitigation strategy shifting to a lower risk choice
6/05/2007 SE 652 - TSP Strat/Launch/Plan 26
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 27
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): 10Risk Exposure: 3First 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: MarkCurrent Status: Risk ControlContingency 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 28
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 sub-systems 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 29
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 30
Some Risk Mitigation Strategies
Personnel TrainingTeam buildingCommunication (e.g. team meetings)Reassignment
Budget & Schedule Design to budgetReduce feature commitmentRenegotiate schedule
Developing wrong product PrototypingUser surveys
Too large or ambitious project Requirements scrubbingCyclic software development
Too many unknowns Prototyping, Cyclic Development
Excessive changes Control adders (cost/benefit)Real-time performance Simulation, prototyping
Risk Mitigation Strategy
6/05/2007 SE 652 - TSP Strat/Launch/Plan 31
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 32
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 33
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 & facilitiesConfiguration status reports (CSR)Software Change Management status reports @ weekly meeting
6/05/2007 SE 652 - TSP Strat/Launch/Plan 34
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 35
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 36
Change Workflow
New / Proposed
Assigned
Resolved
Study
Integrated
Delivered
Verified
NoChangeDeferredDeclined
6/05/2007 SE 652 - TSP Strat/Launch/Plan 37
Due Next Week
Requirements (SRS) draft for inspectionDraft to Quality Manager & instructor by COB Friday
Configuration Management Plan (draft)
Planning Baselines Updated & Baselined Project PlanMS Project schedule (replaces Task & Schedule forms)SUMP
Heads Up: System Test Planning, Quality/Measurement PlanStandard Forms (i.e. Weekly meeting minutes, WEEK form)
6/05/2007 SE 652 - TSP Strat/Launch/Plan 40
TSP Development Plan
Purpose:Basic structure of workScheduling the tasksBalancing the workloadProgress Tracking
Planning & Tracking:Time Estimates => Earned Values => Progress Tracking
Plan ContentsComponent listTask list & their allocation to team membersTeam schedule & team member schedulesTeam quality plan
6/05/2007 SE 652 - TSP Strat/Launch/Plan 41
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 42
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 43
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 44
TSP Task & Size Summary
Size Summary (SUMS)
TASK & SCHED formsTASK & SCHED forms
Plan Summary (SUMP)Plan Summary (SUMP)
Quality Plan (SUMQ)Quality Plan (SUMQ)
Final Planning stepsFinal Planning steps
TSPi Tool Setup:Enter Project Information (Team Leader)
Enter Team Members & Roles (Team Leader)
Size EstimatesPopulate 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 45
TSP Task List & Schedule Plan
Size Summary (SUMS)Size Summary (SUMS)
TASK & SCHED forms
Plan Summary (SUMP)
Quality Plan (SUMQ)Quality Plan (SUMQ)
Final Planning stepsFinal 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 46
Quality Plan
Size Summary (SUMS)Size Summary (SUMS)
TASK & SCHED formsTASK & SCHED forms
Plan Summary (SUMP)Plan Summary (SUMP)
Quality Plan (SUMQ)
Final Planning stepsFinal 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 47
Final Planning Steps
Size Summary (SUMS)Size Summary (SUMS)
TASK & SCHED formsTASK & SCHED forms
Plan Summary (SUMP)Plan Summary (SUMP)
Quality Plan (SUMQ)Quality Plan (SUMQ)
Final Planning steps
Individual Engineer PlansAssign 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 48
Quality Plan Measures
Summary RatesProductivity (LOC / hour)Reuse percentages
TSP Defect DefinitionRequirements, Design or implementation issue which could cause improper design,
implementation, test, use or maintenance of the product.Major – modifies executableMinor – 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 phaseAnalysis hint: look at high defect parts, likely to be the source of future problem
6/05/2007 SE 652 - TSP Strat/Launch/Plan 49
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 #’sGraph by module – shows potential problem sources
Defect Ratios Code review / compileDesign review / unit testhigher #’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 50
Additional Metrics
Development RatiosDesign 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 51
Quality Plan Summary
Only requires tracking a few items:Time
Unit measures (e.g. LOC)
Defects
Phase Introduced
Phase Detected
In-Process StatusLook 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!
top related