8/6/2019 jmmod3se

1/65

1

Project ManagementConceptsProject ManagementConcepts

8/6/2019 jmmod3se

2/65

2

The 4 PsThe 4 Ps People the mostimportantelementofa

successful project Product the software to be built

Process the setof frameworkactivities

and software engineeringtasks to getthejob done

Project allwork requiredto make theproducta reality

People the mostimportantelementofa

successful project Product the software to be built

Process the setof frameworkactivities

and software engineeringtasks to getthejob done

Project allwork requiredto make theproducta reality

8/6/2019 jmmod3se

3/65

3

StakeholdersStakeholders Senior managers who define the business issues thatoftenhave

significantinfluence onthe project. Project(technical) managers who mustplan, motivate, organize,and

controlthe practitioners who do software work. Practitioners who deliverthe technical skills thatare necessaryto

engineera productorapplication. Customers who specifythe requirements forthe software to be

engineeredand other stakeholders who have a peripheral interestintheoutcome.

End-users who interactwiththe software once itis released forproduction use.

Senior managers who define the business issues thatoftenhavesignificantinfluence onthe project.

Project(technical) managers who mustplan, motivate, organize,and

controlthe practitioners who do software work. Practitioners who deliverthe technical skills thatare necessaryto

engineera productorapplication. Customers who specifythe requirements forthe software to be

engineeredand other stakeholders who have a peripheral interestintheoutcome.

End-users who interactwiththe software once itis released forproduction use.

8/6/2019 jmmod3se

4/65

4

Software TeamsSoftware TeamsHowto lead?

Howto organize?

Howto motivate?

Howto collaborate?

Howto create good ideas?

8/6/2019 jmmod3se

5/65

5

Team LeaderTeam Leader The MOI Model:

Motivation. The abilityto encourage (bypush or pull) technicalpeople to produce to their bestability.

Organization. The abilityto mold existing processes (or inventnewones) thatwill enable the initial conceptto be translated into a finalproduct.

Ideas or innovation. The abilityto encourage people to create and

feel creative evenwhentheymustworkwithin bounds establishedfora particular software productorapplication.

The MOI Model:Motivation. The abilityto encourage (bypush or pull) technicalpeople to produce to their bestability.

Organization. The abilityto mold existing processes (or inventnewones) thatwill enable the initial conceptto be translated into a finalproduct.

Ideas or innovation. The abilityto encourage people to create and

feel creative evenwhentheymustworkwithin bounds establishedfora particular software productorapplication.

8/6/2019 jmmod3se

6/65

6

Software TeamsSoftware Teams The difficultyofthe problem to be solved The size ofthe resultantprogram(s) in lines of code or function points The time thatthe team will staytogether (team lifetime) The degree to whichthe problem can be modularized The required qualityand reliabilityofthe system to be built The rigidityofthe deliverydate The degree of sociability(communication) required forthe project

The difficultyofthe problem to be solved The size ofthe resultantprogram(s) in lines of code or function points The time thatthe team will staytogether (team lifetime) The degree to whichthe problem can be modularized The required qualityand reliabilityofthe system to be built The rigidityofthe deliverydate The degree of sociability(communication) required forthe project

The following factors mustbe consideredwhen selectingThe following factors mustbe consideredwhen selectinga software projectteam structure ...a software projectteam structure ...

8/6/2019 jmmod3se

7/65

7

Organizational ParadigmsOrganizational Paradigms Closed paradigmstructures ateam along atraditionalhierarchyof

authority Random paradigmstructures ateam looselyand depends on individual

initiative ofthe team members Open paradigmattempts to structure ateam ina mannerthatachieves

some ofthe controls associatedwiththe closed paradigm butalso muchofthe innovationthatoccurs when usingthe random paradigm

Synchronous paradigmrelies onthe natural compartmentalization ofaproblem and organizes team members to work on pieces ofthe problem

with little active communicationamongthemselves

Closed paradigmstructures ateam along atraditionalhierarchyofauthority

Random paradigmstructures ateam looselyand depends on individual

initiative ofthe team members Open paradigmattempts to structure ateam ina mannerthatachieves

some ofthe controls associatedwiththe closed paradigm butalso muchofthe innovationthatoccurs when usingthe random paradigm

Synchronous paradigmrelies onthe natural compartmentalization ofaproblem and organizes team members to work on pieces ofthe problem

with little active communicationamongthemselves

suggested byConstantine [CON93]

8/6/2019 jmmod3se

8/65

8

Avoid Team ToxicityAvoid Team Toxicity A frenziedworkatmosphere inwhichteam members waste energyand

lose focus onthe objectives ofthe workto be performed. High frustration caused bypersonal, business, ortechnological factors

thatcause frictionamongteam members. Fragmented or poorlycoordinated procedures ora poorlydefined or

improperlychosen process modelthatbecomes a roadblocktoaccomplishment.

Unclear definition of roles resulting ina lack ofaccountabilityandresultantfinger-pointing.

Continuous and repeated exposure to failurethatleads to a loss ofconfidence anda lowering of morale.

A frenziedworkatmosphere inwhichteam members waste energyandlose focus onthe objectives ofthe workto be performed.

High frustration caused bypersonal, business, ortechnological factors

thatcause frictionamongteam members. Fragmented or poorlycoordinated procedures ora poorlydefined or

improperlychosen process modelthatbecomes a roadblocktoaccomplishment.

Unclear definition of roles resulting ina lack ofaccountabilityandresultantfinger-pointing.

Continuous and repeated exposure to failurethatleads to a loss ofconfidence anda lowering of morale.

8/6/2019 jmmod3se

9/65

9

Agile TeamsAgile Teams Team members musthave trustin one another.

The distribution of skills mustbe appropriate to the problem.

Mavericks mayhave to be excluded from the team, ifteam cohesivenessis to be maintained.

Team is self-organizing

Anadaptive team structure

Uses elements ofConstantines random, open,and synchronous

paradigmsSignificantautonomy

Team members musthave trustin one another.

The distribution of skills mustbe appropriate to the problem.

Mavericks mayhave to be excluded from the team, ifteam cohesivenessis to be maintained.

Team is self-organizing

Anadaptive team structure

Uses elements ofConstantines random, open,and synchronous

paradigmsSignificantautonomy

8/6/2019 jmmod3se

10/65

10

Team Coordination &CommunicationTeam Coordination &Communication Formal, impersonalapproaches include software engineering documents and

work products (including source code),technical memos, projectmilestones,schedules,and projectcontroltools (Chapter 23), change requests and relateddocumentation, errortracking reports,and repositorydata (see Chapter 26).

Formal, interpersonal procedures focus on qualityassurance activities (Chapter25) appliedto software engineeringwork products.These include status reviewmeetings and designand code inspections.

Informal, interpersonal procedures include group meetings for informationdisseminationand problem solvingand collocation of requirements anddevelopmentstaff.

Electronic communication encompasses electronic mail, electronic bulletinboards,and byextension, video-based conferencing systems.

Interpersonalnetworking includes informal discussions withteam members andthose outside the projectwho mayhave experience or insightthatcanassistteam members.

Formal, impersonalapproaches include software engineering documents andwork products (including source code),technical memos, projectmilestones,schedules,and projectcontroltools (Chapter 23), change requests and relateddocumentation, errortracking reports,and repositorydata (see Chapter 26).

Formal, interpersonal procedures focus on qualityassurance activities (Chapter25) appliedto software engineeringwork products.These include status reviewmeetings and designand code inspections.

Informal, interpersonal procedures include group meetings for informationdisseminationand problem solvingand collocation of requirements anddevelopmentstaff.

Electronic communication encompasses electronic mail, electronic bulletinboards,and byextension, video-based conferencing systems.

Interpersonalnetworking includes informal discussions withteam members andthose outside the projectwho mayhave experience or insightthatcanassistteam members.

8/6/2019 jmmod3se

11/65

11

The Product ScopeThe Product Scope Scope:

Context.Howdoes the software to be builtfitinto a larger

system, product, or business contextandwhatconstraints areimposedas a resultofthe context?

Information objectives. Whatcustomer-visible data objects(Chapter8) are producedas outputfrom the software? Whatdata objects are required for input?

Functionand performance. Whatfunction does the softwareperform to transform inputdata into output?Are anyspecialperformance characteristics to be addressed?

Software projectscope mustbe unambiguous and understandable atthemanagementandtechnical levels.

Scope:

Context.Howdoes the software to be builtfitinto a larger

system, product, or business contextandwhatconstraints areimposedas a resultofthe context?

Information objectives. Whatcustomer-visible data objects(Chapter8) are producedas outputfrom the software? Whatdata objects are required for input?

Functionand performance. Whatfunction does the softwareperform to transform inputdata into output?Are anyspecialperformance characteristics to be addressed?

Software projectscope mustbe unambiguous and understandable atthemanagementandtechnical levels.

8/6/2019 jmmod3se

12/65

12

Problem DecompositionProblem Decomposition Sometimes called partitioning or problem elaboration

Once scope is defined

Itis decomposed into constituentfunctions

Itis decomposed into user-visible data objects

or

Itis decomposed into a setof problem classes

Decomposition process continues untilall functions or problemclasses have been defined

Sometimes called partitioning or problem elaboration

Once scope is defined

Itis decomposed into constituentfunctions

Itis decomposed into user-visible data objects

or

Itis decomposed into a setof problem classes

Decomposition process continues untilall functions or problemclasses have been defined

8/6/2019 jmmod3se

13/65

13

The ProcessThe Process Once a process frameworkhas been established

Consider projectcharacteristics

Determine the degree of rigor required

Define atask setfor each software engineeringactivity

Task set=Software engineeringtasks

Work products

Qualityassurance points

Milestones

Once a process frameworkhas been established

Consider projectcharacteristics

Determine the degree of rigor required

Define atask setfor each software engineeringactivity

Task set=Software engineeringtasks

Work products

Qualityassurance points

Milestones

8/6/2019 jmmod3se

14/65

14

Melding the Problemand the ProcessMelding the Problemand the Process

8/6/2019 jmmod3se

15/65

15

The ProjectThe Project Projects getinto trouble when

Software people dontunderstandtheir customers needs.The productscope is poorlydefined.

Changes are managed poorly.The chosentechnologychanges.Business needs change [orare ill-defined].Deadlines are unrealistic.Users are resistant.Sponsorship is lost[orwas never properlyobtained].

The projectteam lacks people withappropriate skills.Managers [and practitioners]avoid bestpractices and lessons learned.

Projects getinto trouble when Software people dontunderstandtheir customers needs.The productscope is poorlydefined.

Changes are managed poorly.The chosentechnologychanges.Business needs change [orare ill-defined].Deadlines are unrealistic.Users are resistant.Sponsorship is lost[orwas never properlyobtained].

The projectteam lacks people withappropriate skills.Managers [and practitioners]avoid bestpractices and lessons learned.

8/6/2019 jmmod3se

16/65

16

Common-Sense Approachto ProjectsCommon-Sense Approachto Projects Startonthe rightfoot. This is accomplished byworkinghard (veryhard) to

understandthe problem thatis to be solvedandthen setting realistic objectivesand expectations.

Maintain momentum.The projectmanager mustprovide incentives to keepturnover of personnelto anabsolute minimum,the team should emphasizequalityin everytask itperforms,and senior managementshould do everything

possible to stayoutofthe teams way. Track progress. Fora software project, progress is trackedas work products

(e.g., models, source code, sets oftestcases) are producedandapproved (usingformaltechnical reviews) as partofa qualityassurance activity.

Make smartdecisions. In essence,the decisions ofthe projectmanagerandthesoftware team should be to keep itsimple.

Conducta postmortem analysis. Establisha consistentmechanism forextracting lessons learned for each project.

Startonthe rightfoot. This is accomplished byworkinghard (veryhard) tounderstandthe problem thatis to be solvedandthen setting realistic objectivesand expectations.

Maintain momentum.The projectmanager mustprovide incentives to keepturnover of personnelto anabsolute minimum,the team should emphasizequalityin everytask itperforms,and senior managementshould do everything

possible to stayoutofthe teams way. Track progress. Fora software project, progress is trackedas work products

(e.g., models, source code, sets oftestcases) are producedandapproved (usingformaltechnical reviews) as partofa qualityassurance activity.

Make smartdecisions. In essence,the decisions ofthe projectmanagerandthesoftware team should be to keep itsimple.

Conducta postmortem analysis. Establisha consistentmechanism forextracting lessons learned for each project.

8/6/2019 jmmod3se

17/65

17

To Get to the Essenceof a ProjectTo Get to the Essenceof a Project Whyis the system being developed?

Whatwill be done?

Whenwill itbe accomplished? Who is responsible?

Where are theyorganizationallylocated?

Howwillthe job be done technicallyand managerially?

Howmuch of each resource (e.g., people, software,tools,database) will be needed?

Whyis the system being developed?

Whatwill be done?

Whenwill itbe accomplished? Who is responsible?

Where are theyorganizationallylocated?

Howwillthe job be done technicallyand managerially?

Howmuch of each resource (e.g., people, software,tools,database) will be needed?

BarryBoehm

8/6/2019 jmmod3se

18/65

18

Critical PracticesCritical Practices Formal risk management

Empirical costand schedule estimation

Metrics-based projectmanagement

Earned value tracking

Defecttrackingagainstqualitytargets

People aware projectmanagement

Formal risk management

Empirical costand schedule estimation

Metrics-based projectmanagement

Earned value tracking

Defecttrackingagainstqualitytargets

People aware projectmanagement

8/6/2019 jmmod3se

19/65

19

Process and ProjectMetrics

Process and ProjectMetrics

8/6/2019 jmmod3se

20/65

20

A Good Manager MeasuresA Good Manager Measures

measurementmeasurement

Whatdo weWhatdo weuse as ause as abasis?basis? size?size? function?function?

projectmetricsprojectmetrics

process metricsprocess metricsprocessprocess

productproduct

productmetricsproductmetrics

8/6/2019 jmmod3se

21/65

21

Why Do We Measure?Why Do We Measure? assess the status ofan ongoing project

track potential risks uncover problem areas before theygo

critical,

adjustwork flowortasks, evaluate the projectteams abilityto control

qualityof software work products.

assess the status ofan ongoing project

track potential risks uncover problem areas before theygo

critical,

adjustwork flowortasks, evaluate the projectteams abilityto control

qualityof software work products.

8/6/2019 jmmod3se

22/65

22

Process MeasurementProcess Measurement We measure the efficacyofa software process indirectly.

Thatis,we derive a setof metrics based onthe outcomes thatcan bederived from the process.

Outcomes include measures of errors uncovered before release ofthe software defects deliveredto and reported byend-users work products delivered (productivity) human effortexpended calendartime expended schedule conformance

other measures. We also derive process metrics bymeasuringthe characteristics of

specific software engineeringtasks.

We measure the efficacyofa software process indirectly.Thatis,we derive a setof metrics based onthe outcomes thatcan bederived from the process.

Outcomes include measures of errors uncovered before release ofthe software defects deliveredto and reported byend-users work products delivered (productivity) human effortexpended calendartime expended schedule conformance

other measures. We also derive process metrics bymeasuringthe characteristics of

specific software engineeringtasks.

8/6/2019 jmmod3se

23/65

23

Process Metrics GuidelinesProcess Metrics Guidelines Use common sense and organizational sensitivitywhen interpreting

metrics data. Provide regular feedbackto the individuals andteams who collect

measures and metrics. Dontuse metrics to appraise individuals. Workwith practitioners andteams to setcleargoals and metrics thatwill

be usedto achieve them. Never use metrics to threaten individuals orteams. Metrics datathatindicate a problem area shouldnotbe considered

negative.These dataare merelyan indicator for process improvement. Dontobsess ona single metricto the exclusion of other important

metrics.

Use common sense and organizational sensitivitywhen interpretingmetrics data.

Provide regular feedbackto the individuals andteams who collect

measures and metrics. Dontuse metrics to appraise individuals. Workwith practitioners andteams to setcleargoals and metrics thatwill

be usedto achieve them. Never use metrics to threaten individuals orteams. Metrics datathatindicate a problem area shouldnotbe considered

negative.These dataare merelyan indicator for process improvement. Dontobsess ona single metricto the exclusion of other important

metrics.

8/6/2019 jmmod3se

24/65

24

Software Process ImprovementSoftware Process Improvement

SPI

Process model

Improvementgoals

Process metrics

Process improvementrecommendations

8/6/2019 jmmod3se

25/65

25

Process MetricsProcess Metrics Quality-related

focus on qualityofwork products and deliverables

Productivity-relatedProduction ofwork-products relatedto effortexpended StatisticalSQA data

error categorization & analysis

Defectremoval efficiencypropagation of errors from process activityto activity

Reuse dataThe number of components producedandtheir degree of reusability

Quality-relatedfocus on qualityofwork products and deliverables

Productivity-relatedProduction ofwork-products relatedto effortexpended StatisticalSQA data

error categorization & analysis

Defectremoval efficiencypropagation of errors from process activityto activity

Reuse dataThe number of components producedandtheir degree of reusability

8/6/2019 jmmod3se

26/65

26

Project MetricsProject Metrics usedto minimize the developmentschedule bymakingthe adjustments

necessaryto avoid delays and mitigate potential problems and risks

usedto assess productqualityonan ongoing basis and,whennecessary, modifythe technicalapproachto improve quality.

everyprojectshould measure:

inputsmeasures ofthe resources (e.g., people,tools) requiredto do thework.

outputsmeasures ofthe deliverables orwork products created duringthe

software engineering process.

resultsmeasures thatindicate the effectiveness ofthe deliverables.

usedto minimize the developmentschedule bymakingthe adjustmentsnecessaryto avoid delays and mitigate potential problems and risks

usedto assess productqualityonan ongoing basis and,whennecessary, modifythe technicalapproachto improve quality.

everyprojectshould measure:

inputsmeasures ofthe resources (e.g., people,tools) requiredto do thework.

outputsmeasures ofthe deliverables orwork products created duringthe

software engineering process.

resultsmeasures thatindicate the effectiveness ofthe deliverables.

8/6/2019 jmmod3se

27/65

27

Typical Project MetricsTypical Project Metrics Effort/time per software engineeringtask

Errors uncovered per reviewhour Scheduled vs.actual milestone dates

Changes (number) andtheir characteristics

Distribution of efforton software engineeringtasks

Effort/time per software engineeringtask

Errors uncovered per reviewhour Scheduled vs.actual milestone dates

Changes (number) andtheir characteristics

Distribution of efforton software engineeringtasks

8/6/2019 jmmod3se

28/65

28

Metrics GuidelinesMetrics Guidelines Use common sense and organizational sensitivitywhen interpreting

metrics data. Provide regular feedbackto the individuals andteams who have worked

to collectmeasures and metrics. Dontuse metrics to appraise individuals. Workwith practitioners andteams to setcleargoals and metrics thatwill

be usedto achieve them. Never use metrics to threaten individuals orteams. Metrics datathatindicate a problem area shouldnotbe considered

negative.These dataare merelyan indicator for process improvement. Dontobsess ona single metricto the exclusion of other important

metrics.

Use common sense and organizational sensitivitywhen interpretingmetrics data.

Provide regular feedbackto the individuals andteams who have worked

to collectmeasures and metrics. Dontuse metrics to appraise individuals. Workwith practitioners andteams to setcleargoals and metrics thatwill

be usedto achieve them. Never use metrics to threaten individuals orteams. Metrics datathatindicate a problem area shouldnotbe considered

negative.These dataare merelyan indicator for process improvement. Dontobsess ona single metricto the exclusion of other important

metrics.

8/6/2019 jmmod3se

29/65

29

Typical Size-Oriented MetricsTypical Size-Oriented Metrics errors per KLOC(thousand lines of code) defects per KLOC

$per LOC pages of documentation per KLOC errors per person-month Errors per reviewhour LOCper person-month $per page of documentation

errors per KLOC(thousand lines of code) defects per KLOC

$per LOC pages of documentation per KLOC errors per person-month Errors per reviewhour LOCper person-month $per page of documentation

8/6/2019 jmmod3se

30/65

30

Typical Function-Oriented MetricsTypical Function-Oriented Metrics errors per FP (thousand lines of code)

defects per FP $per FP

pages of documentation per FP

FP per person-month

errors per FP (thousand lines of code)

defects per FP $per FP

pages of documentation per FP

FP per person-month

8/6/2019 jmmod3se

31/65

31

Comparing LOC and FPComparing LOC and FPProgramming LOC per Function point

Language avg. median low high

Ada 154 - 10 205Assembler 337 315 91 69C 162 109 33 70C++ 66 53 29 178

COBOL 77 77 1 00Java 63 53 77 -JavaScript 58 63 2 75Perl 60 - - -PL/1 78 67 22 263Powerbuilder 32 31 11 105SAS 40 1 33 9Smalltalk 26 19 10 55SQL 40 37 7 110Visual Basic 47 2 16 158

Representative values developed byQSM

8/6/2019 jmmod3se

32/65

32

Why Opt for FP?Why Opt for FP? Programming language independent

Used readilycountable characteristics thataredetermined earlyinthe software process

Does notpenalize inventive (short) implementationsthatuse fewer LOCthatother more clumsyversions

Makes iteasierto measure the impactof reusablecomponents

Programming language independent

Used readilycountable characteristics thataredetermined earlyinthe software process

Does notpenalize inventive (short) implementationsthatuse fewer LOCthatother more clumsyversions

Makes iteasierto measure the impactof reusablecomponents

8/6/2019 jmmod3se

33/65

33

Object-Oriented MetricsObject-Oriented Metrics Number of scenario scripts (use-cases)

Number of supportclasses (requiredto implementthe system butare notimmediatelyrelatedto theproblem domain)

Average number of supportclasses per keyclass

(analysis class) Number of subsystems (anaggregation of classes

thatsupporta functionthatis visible to the end-user ofa system)

Number of scenario scripts (use-cases)

Number of supportclasses (requiredto implementthe system butare notimmediatelyrelatedto theproblem domain)

Average number of supportclasses per keyclass

(analysis class) Number of subsystems (anaggregation of classes

thatsupporta functionthatis visible to the end-user ofa system)

8/6/2019 jmmod3se

34/65

34

WebE Project MetricsWebE Project Metrics Number of static Web pages (the end-userhas no control overthe

contentdisplayed onthe page) Number of dynamic Web pages (end-useractions resultin customized

contentdisplayed onthe page) Number of internal page links (internal page links are pointers that

provide ahyperlinkto some other Web page withinthe WebApp) Number of persistentdata objects Number of external systems interfaced Number of static contentobjects

Number of dynamic contentobjects Number of executable functions

Number of static Web pages (the end-userhas no control overthecontentdisplayed onthe page)

Number of dynamic Web pages (end-useractions resultin customized

contentdisplayed onthe page) Number of internal page links (internal page links are pointers that

provide ahyperlinkto some other Web page withinthe WebApp) Number of persistentdata objects Number of external systems interfaced Number of static contentobjects

Number of dynamic contentobjects Number of executable functions

8/6/2019 jmmod3se

35/65

35

Measuring QualityMeasuring Quality Correctness the degree to whicha program

operates accordingto specification

Maintainabilitythe degree to whicha program isamenable to change

Integritythe degree to whicha program is

impervious to outside attack Usabilitythe degree to whicha program is easyto

use

Correctness the degree to whicha programoperates accordingto specification

Maintainabilitythe degree to whicha program isamenable to change

Integritythe degree to whicha program is

impervious to outside attack Usabilitythe degree to whicha program is easyto

use

8/6/2019 jmmod3se

36/65

36

Defect Removal EfficiencyDefect Removal Efficiency

DRE = E /(E+D)

E is the number of errors found before delivery ofthe software to the end-userD is the number of defects found after delivery.

8/6/2019 jmmod3se

37/65

37

Metrics forSmallOrganizationsMetrics forSmallOrganizations time (hours or days) elapsed from the time a requestis made until

evaluation is complete,tqueue. effort(person-hours) to perform the evaluation, Weval.

time (hours or days) elapsed from completion of evaluationtoassignmentof change orderto personnel,teval. effort(person-hours) requiredto make the change, Wchange. time required (hours or days) to make the change,tchange. errors uncovered duringworkto make change,Echange. defects uncoveredafter change is releasedto the customer base,

Dchange.

time (hours or days) elapsed from the time a requestis made untilevaluation is complete,tqueue.

effort(person-hours) to perform the evaluation, Weval.

time (hours or days) elapsed from completion of evaluationtoassignmentof change orderto personnel,teval. effort(person-hours) requiredto make the change, Wchange. time required (hours or days) to make the change,tchange. errors uncovered duringworkto make change,Echange. defects uncoveredafter change is releasedto the customer base,

Dchange.

8/6/2019 jmmod3se

38/65

38

Establishing a MetricsProgramEstablishing a MetricsProgram Identifyyour business goals. Identifywhatyou wantto knowor learn. Identifyyour subgoals.

Identifythe entities andattributes relatedto your subgoals. Formalize your measurementgoals. Identifyquantifiable questions andthe related indicators thatyou will use to help

you achieve your measurementgoals. Identifythe data elements thatyou will collectto constructthe indicators that

help answeryour questions. Define the measures to be used,and make these definitions operational. Identifythe actions thatyou willtake to implementthe measures. Prepare a plan for implementingthe measures.

Identifyyour business goals. Identifywhatyou wantto knowor learn. Identifyyour subgoals.

Identifythe entities andattributes relatedto your subgoals. Formalize your measurementgoals. Identifyquantifiable questions andthe related indicators thatyou will use to help

you achieve your measurementgoals. Identifythe data elements thatyou will collectto constructthe indicators that

help answeryour questions. Define the measures to be used,and make these definitions operational. Identifythe actions thatyou willtake to implementthe measures. Prepare a plan for implementingthe measures.

8/6/2019 jmmod3se

39/65

39

Chapter 3Estimation forSoftware

Projects

Chapter 3Estimation forSoftware

Projects

Software Engineering:A PractitionersApproach,6th editionbyRogerS. Pressman

8/6/2019 jmmod3se

40/65

40

Software Project PlanningSoftware Project PlanningThe overall goal of project planning is toThe overall goal of project planning is toestablish a pragmatic strategy for controlling,establish a pragmatic strategy for controlling,tracking, and monitoring a complex technicaltracking, and monitoring a complex technicalproject.project.

Why?Why?

So the end result gets done on time, withSo the end result gets done on time, with

quality!quality!

8/6/2019 jmmod3se

41/65

41

Project Planning Task Set-IProject Planning Task Set-I Establish projectscope

Determine feasibility Analyze risks

Define required resources

Determine require human resourcesDefine reusable software resources

Identifyenvironmental resources

Establish projectscope

Determine feasibility Analyze risks

Define required resources

Determine require human resourcesDefine reusable software resources

Identifyenvironmental resources

8/6/2019 jmmod3se

42/65

8/6/2019 jmmod3se

43/65

43

EstimationEstimation Estimation of resources, cost,and schedule fora software

engineering effortrequires

experienceaccess to goodhistorical information (metrics

the courage to committo quantitative predictions whenqualitative information is allthatexists

Estimation carries inherentriskandthis risk leads touncertainty

Estimation of resources, cost,and schedule fora softwareengineering effortrequires

experienceaccess to goodhistorical information (metrics

the courage to committo quantitative predictions whenqualitative information is allthatexists

Estimation carries inherentriskandthis risk leads touncertainty

8/6/2019 jmmod3se

44/65

44

Write it Down!Write it Down!

SoftwareSoftwareProjectProject

PlanPlan

ProjectScopeProjectScopeEstimatesEstimatesRisksRisksScheduleScheduleControl strategyControl strategy

8/6/2019 jmmod3se

45/65

45

To Understand Scope ...To Understand Scope ... Understandthe customers needs

understandthe business context understandthe projectboundaries

understandthe customers motivation

understandthe likelypaths for change

understandthat...

Understandthe customers needs

understandthe business context understandthe projectboundaries

understandthe customers motivation

understandthe likelypaths for change

understandthat...Evenwhenyou understand,Evenwhenyou understand,nothing is guaranteed!nothing is guaranteed!

8/6/2019 jmmod3se

46/65

46

What is Scope?What is Scope? Software scope describes

the functions and features thatare to be deliveredto end-users

the datathatare inputand outputthe content thatis presentedto users as a consequence of usingthe software

the performance, constraints, interfaces,and reliabilitythatboundthe system.

Scope is defined using one oftwo techniques:Anarrative description of software scope is developedaftercommunicationwithall stakeholders.

A setof use-cases is developed byend-users.

Software scope describes

the functions and features thatare to be deliveredto end-users

the datathatare inputand outputthe content thatis presentedto users as a consequence of usingthe software

the performance, constraints, interfaces,and reliabilitythatboundthe system.

Scope is defined using one oftwo techniques:Anarrative description of software scope is developedaftercommunicationwithall stakeholders.

A setof use-cases is developed byend-users.

8/6/2019 jmmod3se

47/65

47

ResourcesResources

project

people

skills

er

loc tion

reus lesoft re

OTScomponents

full-experiencecomponents

newcomponents

part.-experiencecomponents

environment

har ware

softwaretools

networkresources

8/6/2019 jmmod3se

48/65

8/6/2019 jmmod3se

49/65

49

Estimation TechniquesEstimation Techniques Past(similar) projectexperience

Conventional estimationtechniquestask breakdownand effortestimates

size (e.g., FP) estimates

Empirical models

Automatedtools

Past(similar) projectexperience

Conventional estimationtechniquestask breakdownand effortestimates

size (e.g., FP) estimates

Empirical models

Automatedtools

8/6/2019 jmmod3se

50/65

50

Estimation AccuracyEstimation Accuracy Predicated on

the degree to whichthe plannerhas properlyestimatedthe size ofthe productto be built

the abilityto translate the size estimate into human effort, calendartime,and dollars (a function ofthe availabilityof reliable softwaremetrics from pastprojects)

the degree to whichthe projectplan reflects the abilities ofthesoftware team

the stabilityof productrequirements andthe environmentthatsupports the software engineering effort.

Predicated on

the degree to whichthe plannerhas properlyestimatedthe size ofthe productto be built

the abilityto translate the size estimate into human effort, calendartime,and dollars (a function ofthe availabilityof reliable softwaremetrics from pastprojects)

the degree to whichthe projectplan reflects the abilities ofthesoftware team

the stabilityof productrequirements andthe environmentthatsupports the software engineering effort.

8/6/2019 jmmod3se

51/65

51

FunctionalDecompositionFunctionalDecomposition

functionalfunctional

decompositiondecomposition

StatementStatement

ofofScopeScope Perform a GrammaticalPerform a Grammatical

parseparse

8/6/2019 jmmod3se

52/65

52

Conventional Methods:LOC/FP ApproachConventional Methods:LOC/FP Approach

compute LOC/FP using estimates ofinformation domain values

use historical datato build estimates forthe project

compute LOC/FP using estimates ofinformation domain values

use historical datato build estimates forthe project

8/6/2019 jmmod3se

53/65

53

Process-Based EstimationProcess-Based EstimationObt i fr r ss fr rkObt i fr r ss fr rk

li tili tif ti sf ti s

frameworkactivitiesframeworkactivities

EffortrequiredtoEffortrequiredtoaccomplishaccomplisheach frameworkactivityeach frameworkactivityfor eachapplicationfor eachapplicationfunctionfunction

8/6/2019 jmmod3se

54/65

54

Process-Based Estimation ExampleProcess-Based Estimation ExampleActiv ity

Task

Functio n

UICF

2D GA

3DGA

DSM

PCF

CGD F

DAM

Tota ls

% effort

CC P la nn ingRis k

An a lys is E ng ine e r i ngCons tru ction

Re le a s e Tota lsCE

an a lys is des i gn code tes t

0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation

0.50

0.75

0.500.50

0.500.25

2.50

4.00

4.003.00

3.002.00

0.40

0.60

1.001.00

0.750.50

5.002.00

3.001.50

1.501.50

8.40

7.35

8.506.00

5.754.25

0.50 2.00 0.50 2.00 5.00

n/an/a

n/an/an/an/an/a

Based on an average burdened labor rate of $8, per month, theBased on an average burdened labor rate of $8, per month, thetotal estimated project cost is $368, and the estimated effort is 46total estimated project cost is $368, and the estimated effort is 46personperson--months.months.

8/6/2019 jmmod3se

55/65

8/6/2019 jmmod3se

56/65

8/6/2019 jmmod3se

57/65

8/6/2019 jmmod3se

58/65

58

COCOMO-IICOCOMO-II COCOMO II is actuallyahierarchyof estimation models thataddress the

followingareas:

Application composition model.Used duringthe earlystages ofsoftware engineering,when prototyping of user interfaces,consideration of software and system interaction,assessmentofperformance,and evaluation oftechnologymaturityare paramount.

Earlydesign stage model.Used once requirements have beenstabilizedand basic software architecture has been established.

Post-architecture-stage model.Used duringthe construction ofthesoftware.

COCOMO II is actuallyahierarchyof estimation models thataddress thefollowingareas:

Application composition model.Used duringthe earlystages ofsoftware engineering,when prototyping of user interfaces,consideration of software and system interaction,assessmentofperformance,and evaluation oftechnologymaturityare paramount.

Earlydesign stage model.Used once requirements have beenstabilizedand basic software architecture has been established.

Post-architecture-stage model.Used duringthe construction ofthesoftware.

8/6/2019 jmmod3se

59/65

59

The Software EquationThe Software EquationA dynamic multivariable modelA dynamic multivariable model

E = [LO

C x BE = [LO

C x B.333.333

/P]/P]33

x (1/tx (1/t44

))wherewhere

E = effort in personE = effort in person--months or personmonths or person--yearsyearst = project duration in months or yearst = project duration in months or years

B = special skills factorB = special skills factorP = productivity parameterP = productivity parameter

8/6/2019 jmmod3se

60/65

60

Estimation forOO Projects-IEstimation forOO Projects-I Develop estimates using effortdecomposition, FPanalysis,andany

other methodthatis applicable for conventionalapplications. Using object-orientedanalysis modeling (Chapter8), develop use-cases

and determine a count. From the analysis model, determine the number of keyclasses (calledanalysis classes inChapter8).

Categorize the type of interface forthe applicationand develop amultiplier for supportclasses:

Interface type Mul tiplierNo GUI 2.0Text-based user interface 2.25GUI 2.5Complex GUI 3.0

Develop estimates using effortdecomposition, FPanalysis,andanyother methodthatis applicable for conventionalapplications.

Using object-orientedanalysis modeling (Chapter8), develop use-cases

and determine a count. From the analysis model, determine the number of keyclasses (calledanalysis classes inChapter8).

Categorize the type of interface forthe applicationand develop amultiplier for supportclasses:

Interface type Mul tiplierNo GUI 2.0Text-based user interface 2.25GUI 2.5Complex GUI 3.0

8/6/2019 jmmod3se

61/65

61

Estimation forOO Projects-IIEstimation forOO Projects-II Multiplythe number of keyclasses (step 3) bythe multiplier

to obtainan estimate forthe number of supportclasses.

Multiplythe totalnumber of classes (key+ support) bytheaverage number ofwork-units per class. Lorenzand Kiddsuggest15to 20 person-days per class.

Cross checkthe class-based estimate bymultiplyingtheaverage number ofwork-units per use-case

Multiplythe number of keyclasses (step 3) bythe multiplierto obtainan estimate forthe number of supportclasses.

Multiplythe totalnumber of classes (key+ support) bytheaverage number ofwork-units per class. Lorenzand Kiddsuggest15to 20 person-days per class.

Cross checkthe class-based estimate bymultiplyingtheaverage number ofwork-units per use-case

8/6/2019 jmmod3se

62/65

62

Estimation forAgile ProjectsEstimation forAgile Projects Each user scenario (a mini-use-case) is considered separatelyfor estimation

purposes. The scenario is decomposed into the setof software engineeringtasks thatwill

be requiredto develop it. Eachtask is estimated separately. Note: estimation can be based onhistorical

data,an empirical model, or experience.Alternatively,the volume ofthe scenario can be estimated in LOC, FP or some othervolume-oriented measure (e.g., use-case count).

Estimates for eachtaskare summedto create an estimate forthe scenario.Alternatively,the volume estimate forthe scenario is translated into effortusinghistorical data.

The effortestimates forall scenarios thatare to be implemented foragivensoftware incrementare summedto develop the effortestimate forthe increment.

Each user scenario (a mini-use-case) is considered separatelyfor estimationpurposes.

The scenario is decomposed into the setof software engineeringtasks thatwillbe requiredto develop it.

Eachtask is estimated separately. Note: estimation can be based onhistoricaldata,an empirical model, or experience.

Alternatively,the volume ofthe scenario can be estimated in LOC, FP or some othervolume-oriented measure (e.g., use-case count).

Estimates for eachtaskare summedto create an estimate forthe scenario.Alternatively,the volume estimate forthe scenario is translated into effortusinghistorical data.

The effortestimates forall scenarios thatare to be implemented foragivensoftware incrementare summedto develop the effortestimate forthe increment.

8/6/2019 jmmod3se

63/65

63

The Make-Buy DecisionThe Make-Buy Decision

system Xsystem Xreusereuse

simple (0.30)simple (0.30)

difficult(0.70)difficult(0.70)

minorminor changeschanges

(0.40)(0.40)

majormajorchangeschanges

(0.60)(0.60)

simple (0.20)simple (0.20)

complex (0.80)complex (0.80)

majormajor changeschanges (0.30)(0.30)

minorminor changeschanges

(0.70)(0.70)

$380,000$380,000

$450,000$450,000

$275,000$275,000

$310,000$310,000

$490,000$490,000

$210,000$210,000

$400,000$400,000

buybuy

contractcontract

withoutchanges (0.60)withoutchanges (0.60)

with changes (0.40)with changes (0.40)

$350,000$350,000

$500,000$500,000

buildbuild

8/6/2019 jmmod3se

64/65

64

Computing Expected CostComputing Expected Cost((path probability ) x (estimated path cost)path probability ) x (estimated path cost)

ii ii

For example, the expected cost to build is:For example, the expected cost to build is:

expectedcost = .3 ($38 K) + .7 ($ K)expectedcost = .3 ($38 K) + .7 ($ K)

similarly,similarly,

expectedcost =expectedcost =$382K$382Kexpectedcost =expectedcost =$267K$267Kexpectedcost =expectedcost =$ K$ K

b ildb ild

reusreuseebuybuy

contcontrr

expected cost=expected cost=

= $ 29= $ 29 KK

8/6/2019 jmmod3se

65/65