Transcript
Page 1: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT1

MANAGING SOFTWARE MANAGING SOFTWARE DEVELOPMENTDEVELOPMENT

MANAGING SOFTWARE MANAGING SOFTWARE DEVELOPMENTDEVELOPMENT

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

Page 2: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT2

MANAGING SOFTWARE DEVELOPMENT OUTLINEMANAGING SOFTWARE DEVELOPMENT OUTLINE

The Software Development Plan– the challenge– deliverables– development environment– size and effort estimates– risk planning– lifecycle model– work breakdown structure (WBS)– schedules– staffing and organization– product teams– time-phased budget– metrics plan

Project Tracking and Control

11

Page 3: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT3

THE SOFTWARE DEVELOPMENT PLAN (SDP) —THE SOFTWARE DEVELOPMENT PLAN (SDP) —THE CHALLENGE THE CHALLENGE

Up front we need to:

Planning the development is a continuous process:“plan the work” and “work the plan”.

come up with a plan for software development with– incomplete knowledge (requirements, people, etc.)

– limited resources (time, money, skills, etc.)

decide– what features are required – tasks to be done

– whether to build or buy – effort to be expended

– what resources are required – schedule to follow

– what are the risks – what development tools to use ...

Page 4: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT4

THE SOFTWARE DEVELOPMENT PLAN (SDP)THE SOFTWARE DEVELOPMENT PLAN (SDP)

the SDP documents exactly how the project will be managed it defines the project

first need to define the scope of the development– define the problem agree on what constitutes success– analyze the requirements so you can make sizing estimates– prepare a top-level package diagram overall view of the system– estimate the time and effort needed to deliver the product

input needed from:– development manager project organization, WBS, budget– experienced system architect top-level package diagram,

project sizing– expert user or domain expert requirements understanding

The outcome is a go/no-go decision.

Page 5: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT5

DELIVERABLESDELIVERABLES

Customer products given to the customer– executable code – tutorials– user manuals – examples– help files – templates– installation scripts – developer manuals– installation manuals – license managers

Process artifacts outcomes of the development process– use-case databases – requirements, analysis,

design specs– object design files – source code

Internal deliverables of continuing value to the organization– source code libraries – make files– test libraries – problem report database

Services additional deliverables for the customer– training – on-site support– consulting – customization– installation

Page 6: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT6

DEVELOPMENT ENVIRONMENTDEVELOPMENT ENVIRONMENT

need to choose hardware and software development tools appropriate for the project

development tools ≠ development process

tools are effective only if they make well-understood processes more efficient

in choosing a development support tool evaluate:– support of the lifecycle: UML; management oversight and control;

architectural control; collaboration support;developer efficiency; library integration;documentation support

– risk of adoption to both cost and schedule:external cost; internal cost; time loss;product instability; investment protection

Page 7: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT7

SIZE AND EFFORT ESTIMATESSIZE AND EFFORT ESTIMATES

EstimatingEstimating: trying to : trying to quantifyquantify something something before it occursbefore it occurs..EstimatingEstimating: trying to : trying to quantifyquantify something something before it occursbefore it occurs..

we usually need to estimate:– size – effort – duration – productivity – development cost

based on:– experience – historical data – courage!

which is facilitated if we:– establish project scope in advance– use software metrics from past projects– divide and conquer

Estimating carries inherent risk.

Page 8: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT8

SOFTWARE METRICS FOR ESTIMATINGSOFTWARE METRICS FOR ESTIMATING

We can collect many types of metrics about many aspects of software.

Question: What metrics are useful for estimating andhow can they be used for estimating?

Technical metrics

Quality metrics

Productivity metrics

Size-oriented metrics

Function-oriented metrics

Human-oriented metrics

Productivity metrics

Size-oriented metrics

Function-oriented metrics

Page 9: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT10

SIZE-ORIENTED METRICSSIZE-ORIENTED METRICS

and use it to calculate:

Productivity = KLOC/effort Quality = errors/KLOC

Cost = $K/KLOC Documentation = pages/KLOC

project effort $K KLOC pages errors people

A231 24 168 12.1 365 29 3B752 62 440 27.2 1224 86 5C812 43 314 20.2 1050 54 6

We collect:

What is the problem with this approach?

Page 10: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT11

FUNCTION-ORIENTED METRICSFUNCTION-ORIENTED METRICS

FP = count-total * [0.65 + 0.01 * sum(Fi)]

Productivity = FP/effort Quality = errors/FPCost = $/FP Documentation = pages/FP

Weighting factorMeasurement parameter Count Simple Average Complex

Number of user inputs x 3 4 6 =

Number of user outputs x 4 5 7 =

Number of user inquiries x 3 4 6 =

Number of files x 7 10 15 =

Number of external interfaces x 5 7 10 =

Count - total

Page 11: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT14

ESTIMATION METHODSESTIMATION METHODS

System/Package-level analogy– use experience from a previous similar development

may use Delphi technique - average 3 or more estimates

Pert estimation

each expert provides a range of values, typically– optimistic – most likely – pessimistic

expected value computed as a weighted average of optimistic (o), most likely (m) and pessimistic (p)

E = (o + 4m + p)/6 StdDev = (p - o)/6

actual size between E-StdDev and E+StdDev 68% of the time

SD is a measure of schedule and budget risk

Page 12: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT15

ESTIMATION METHODS (cont’d)ESTIMATION METHODS (cont’d)

Parametric models

use parametric formulas empirically derived from a limited sample of projects to predict effort, project duration, etc.

static single-variable models (e.g., COCOMO)

Resource = c1 x (estimated characteristic)C2

static multi-variable models

Resource = c11e1 + c12e2 + ...

dynamic multi-variable models (e.g., Putnam)– estimates resource requirements as a function of time

c - empirically derived constants e - ith software characteristic

Page 13: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT16

COCOMO—COCOMO—COCONSTRUCTIVE NSTRUCTIVE COCOST ST MOMODELDEL

Model 1 - Basic COCOMO

E = ab(KLOC)**(bb) effort in person-month

D = cb(E)**(db) development time in months

Software project ab bb cb db

Organic 2.4 1.05 2.5 0.38Semi-detached 3.0 1.122.5 0.35Embedded 3.6 1.20 2.5 0.32

organic – relatively small, simple software projects, non-rigid requirementssmall teams with good application experience

semi-detached – an intermediate project;teams with mixed experience levels;must meet a mix of rigid and less rigid requirements

embedded – project must meet set of tight hardware, software and operational constraints

Page 14: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT17

COCOMO—COCOMO—COCONSTRUCTIVE NSTRUCTIVE COCOST ST MOMODELDEL

Model 2 - Intermediate COCOMO

E = ai(LOC)**bi x EAF effort in person-month

Software project ai bi

Organic 3.2 1.05Semi-detached 3.0 1.12Embedded 2.8 1.20

Model 3 - Advanced COCOMO– Model 2 plus an assessment of each cost driver’s impact on each

step of the software engineering process

Page 15: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT19

PUTNAM ESTIMATION MODELPUTNAM ESTIMATION MODEL

E = L3

Ck3td

4

L = LOCCk = state-of-technology constanttd = development time in years

Requirements Analysis & Design Implementation Operation & Maintenance

Coding

Test & validation

Installation

Time

Man

pow

er (

pers

on/y

ear)

Page 16: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT20

ESTIMATION — FINAL THOUGHTSESTIMATION — FINAL THOUGHTS

incomplete and imprecise requirements hinder accurate cost estimation

under uncertainty, develop resource requirements incrementally

a cost estimation model is doing well if it can estimate software development costs within 20% of actual costs, 70% of the time on its “own turf”

always perform estimation in more than one way and do cross-checks on your results

essential to have experienced developers do estimating

automated tools can help

Page 17: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT21

RISK PLANNINGRISK PLANNING

If you do not If you do not actively attack risksactively attack risks, they will , they will actively attack youactively attack you!!T. Gilb

If you do not If you do not actively attack risksactively attack risks, they will , they will actively attack youactively attack you!!T. Gilb

In risk planning we try to:– determine what can go wrong, before it happens– determine its impact– determine the likelihood that it could happen– develop cost-effective contingency plans (what to do if it happens)

the ability to do this well is one of the important qualities of a good manager

related to preventive management (i.e., determine the risk and execute preventive action before the problem can take place)

Page 18: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT22

RISK ANALYSISRISK ANALYSIS

RiskRisk is one of the few is one of the few certainties of lifecertainties of life!!RiskRisk is one of the few is one of the few certainties of lifecertainties of life!!

project risks– budget, schedule, personnel, resource, customer, requirements

problems, …

technical risks– design, implementation, interfacing, testing, maintenance, …

business risks– no market, no need, sales force can’t sell, no management support,

...

It is important to identify all the risks that we can.

Use a risk checklist.

Page 19: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT23

RISK PROJECTION (ESTIMATION)RISK PROJECTION (ESTIMATION)

We need to estimate:

likelihood (li) of the risk (ri)

– establish a scale Boolean, subjective, probabilities

consequences and impact (xi) of the risk

– its nature what is likely to happen

– its scope what is likely to be affected and to what degree

– its timing when and duration

accuracy of projection– basis for likelihood and impact

Prioritize risks.

Page 20: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT24

RISK ASSESSMENTRISK ASSESSMENT

for each risk identified attempt to define the referent point– project will be terminated above referent point

Projected cost overrun

Proj

ecte

d sc

hedu

le o

verr

un Project terminationwill occur in thisregion

referent point

Avoid/manage risks which could lead to project termination.

Page 21: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT25

RISK MANAGEMENT AND MONITORINGRISK MANAGEMENT AND MONITORING

Example: ri=high staff turnover li=0.7xi=“increase duration by 15% and overall cost by 12%”

What steps can be taken to mitigate this risk?

“If you know the enemy and you know yourself, you need not fear the result of a hundred battles.”

The Art of War, Sun Tzu

“If you know the enemy and you know yourself, you need not fear the result of a hundred battles.”

The Art of War, Sun Tzu

need to perform cost/benefit analysis of countermeasures

Do they cost more than the consequencesof the risk itself?

apply 80:20 rule: 80% of all project risk is accounted for by 20% of identified risks

Page 22: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT26

WORK BREAKDOWN STRUCTURE (WBS)WORK BREAKDOWN STRUCTURE (WBS)

breaks the project into tasks, sub-tasks, … divide and conquer– usually shown in a tree structure– identify all the activities/tasks required to complete the project– estimate resources required for each leaf node and then “roll-up” to

get estimate for the entire project– used in both budgets (cost of task) and schedules (time to do task)

WBS should allow each task to be:– easily planned has a well-defined start and end

– easily assigned to individuals/teams

– tracked can monitor progress and know who is working on it

– budgeted has an associated cost

– of the right granularity not too small and not too large

Page 23: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT28

SCHEDULESSCHEDULES

need to determine schedule items and when they happen– task ordering dependencies (sequential, parallel)– time estimates for each task start time, duration (range?)– resource assignment people, hardware, software– milestones important management decision points– deliverables specifications, documents, code, etc.– critical path chain of tasks which determine project duration

prioritize by risk, criticality, resource utilization

usually three levels of schedule needed:– master schedule for communicating with management, customer– macroschedule for day-to-day management of project– microschedule for team management

Gantt and PERT charts commonly used

Page 24: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT29

SCHEDULES — GANTT CHART EXAMPLESCHEDULES — GANTT CHART EXAMPLE

Task

Prepare project plan

Capture Requirements

Build System Prototype

Database Design

Implementation

Testing and Evaluation

Deployment

Post Project Review

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

WeekCurrent WeekIncomplete Task

Partially Complete Task

Completed Task

Page 25: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT30

SCHEDULES — PERT CHART EXAMPLESCHEDULES — PERT CHART EXAMPLE

4

A B

C

D E

F

G H

1 3

4

5 9

10

2 1

critical path 7

1 2 3 5 6 8 9

Overall schedule depends on critical path.

dummy task

dummy task

Page 26: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT32

STAFFING AND ORGANIZATIONSTAFFING AND ORGANIZATION

We need to create a (hierarchical) project organization chart that:– identifies project roles and responsibilities– plans the number of staff in each role– establishes product teams as needed

interdisciplinary teams to coordinate certain efforts Need at least one project member with similar system experience!

The team organization should:– be modular to limit communication and complexity of interaction– invest each team member with a clear sense of ownership

This implies that:– teams should be formed to “own” the design and implementation of

one or more packages– classes should be assigned to individuals for design and

implementation– owners (leads, PIC) should be identified for packages and the system

achieving right level of communication is key to success

Page 27: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT33

TIME-PHASED BUDGETTIME-PHASED BUDGET

A time-phased budget details– when the project’s budget is planned to be spent– what is expected to have been accomplished at each level of

expenditure

Manpower will likely be the major cost– to each WBS item assign costs based on duration, staffing level,

and cost for each type of staff

BUT, don’t forget other costs!– travel – software licenses– hardware – etc.– plus some reserve (between 10-15%)

Track the spending!Compare planned and actual money spent

against planned and actual completion monthly.

Page 28: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT34

METRICS PLANMETRICS PLAN

For purposes of project management we need to:– identify which development metrics to collect

– provide a plan for how to collect each of them

– describe procedures and tools the will be used to collect them

Project management metrics are usually related to size:– number of use cases

– number of classes

– lines of source code

Compare planned sizes with current sizes to determine:– progress: how much of the planned development is in place

– stability: how much change has there been in project requirements and change estimates

Page 29: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT35

PROJECT TRACKING AND CONTROLPROJECT TRACKING AND CONTROL

““software projects fall behind schedule one day at a time”software projects fall behind schedule one day at a time”““software projects fall behind schedule one day at a time”software projects fall behind schedule one day at a time”

need to have constant, consistent, inoffensive monitoring of project activities

primary purpose is to make sure the project ismeeting the budget and schedule

change is nearly inevitable despite best efforts to minimize it key is to handle it in a controlled manner SCM

“Adding manpower to a late software project makes it later.”Frederick P. Brooks The Mythical Man-Month

“Adding manpower to a late software project makes it later.”Frederick P. Brooks The Mythical Man-Month

Page 30: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT36

METHODS OF PROJECT TRACKING & CONTROLMETHODS OF PROJECT TRACKING & CONTROL

project status meetings weekly, monthly

doing project reviews and evaluating the results of each review

check if milestones are accomplished as planned

compare actual budget with planned budget and actual start dates with planned start dates for activities

informal chats with project staff

if slipping– diagnose and recover as best you can: reorganize, change

schedule, etc.

Page 31: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT37

PROJECT TRACKING & CONTROL – FINAL THOUGHTSPROJECT TRACKING & CONTROL – FINAL THOUGHTS

need to identify what tasks in the WBS need to be done by when and by who, AHEAD OF TIME

its the only way to know what you are doing and what else can be changed (reordered) to try to stay on track

even if the schedule changes, you should identify why first and incorporate knowledge into measurements for next time

a schedule slip is not good, but understandable, if you know why it happened

BUT, missed deadlines with no schedule or knowledge of why things are happening that way is INCOMPETENCEINCOMPETENCE

Page 32: 310414 MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING

310414310414 MANAGING DEVELOPMENTMANAGING DEVELOPMENT38

MANAGING SOFTWARE DEVELOPMENT MANAGING SOFTWARE DEVELOPMENT SUMMARYSUMMARY

““Manage the process, don’t let the process manage you.”Manage the process, don’t let the process manage you.”

Khoa Nguyen, CEO Videoserver


Top Related