6/05/2007SE 652 - TSP Strat/Launch/Plan1 Team Software Project Concept / Launch Phase topics Planning Phase

6/05/2007 SE 652 - TSP Strat/Launch/Plan 1

Team Software Project

Concept / Launch Phase topics

Planning Phase


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


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


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


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


Goal Setting

Use a confidence level to set goals (e.g. 90%)

SMART GoalsSpecific

Measurable

Actionable

Realistic

Timely


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


Commitment

What is it?A promise!

Commitment pitfallsFrequently implied (assumed commitment)

Frequently given even though intent is not a commitment


TSPi Tool


TSP Development Phase

Preliminary Plan

Documentation:Conceptual Design (in Project Plan)

STRAT form (in Project Plan)

ITL log (Risks & Issues – extended version)


Development Strategy

Why Plan?Common understanding of objective & work required

Basis for tracking work completion

Provides assessment of effort required & if objectives are achievable


Development Approach

Waterfall

Iterative

Build one, throw it away

Rapid Application Design (RAD)

Extreme Programming (XP)


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

Project Plan Presentations


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.”


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


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


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.


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


Other Suggested Improvements


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…”


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


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…”


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


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


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.”


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.


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


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.


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


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


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


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


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


Automated Configuration Mgmt

Lucent: Sablime / SBCS & SCCS

Rational: DDTS / ClearCase

Perforce Software: Perforce

Microsoft: Visual SourceSafe

MKS


Change Workflow

New / Proposed

Assigned

Resolved

Study

Integrated

Delivered

Verified

NoChangeDeferredDeclined


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)

Backup Slides


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


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


TSP Development Plan Script

Input:Development Strategy

Conceptual Design

Output:Task & Schedule Forms

SUMP, SUMQ & SUMS Forms


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


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


TSP Task List & Schedule Plan

Size Summary (SUMS)Size Summary (SUMS)

TASK & SCHED forms

Plan Summary (SUMP)



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


Quality Plan




Quality Plan (SUMQ)


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


Final Planning Steps





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)


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


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)


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


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!

Documents

6/05/2007SE 652 - TSP Strat/Launch/Plan1 Team Software Project Concept / Launch Phase topics Planning Phase