managing software projects. the project reel j.s “critical success factors in software...
TRANSCRIPT
The ProjectReel J.S “Critical success factors in Software Projects”, IEEE Software, May 1999
The ProjectReel J.S “Critical success factors in Software Projects”, IEEE Software, May 1999
Reel’s five step approach for successful projects Start on the right foot
Understand the problem, set realistic objectives, build the right team, provide the needed infrastructure
Maintain momentum Take measures to avoid gradual disintegration
Track progress Process and project measures to assess progress
Make smart decisions In terms of resources, make/bu
Conduct a postmortem analysis Extract lessons learned
Reel’s five step approach for successful projects Start on the right foot
Understand the problem, set realistic objectives, build the right team, provide the needed infrastructure
Maintain momentum Take measures to avoid gradual disintegration
Track progress Process and project measures to assess progress
Make smart decisions In terms of resources, make/bu
Conduct a postmortem analysis Extract lessons learned
To Get to the Essence of a Project - W5HH Principle
Barry B Bohem, “Anchoring the Software Process” IEEE Software Vol 13 July 1996
To Get to the Essence of a Project - W5HH Principle
Barry B Bohem, “Anchoring the Software Process” IEEE Software Vol 13 July 1996
1) WHY is the system being developed?Validity of business reasons for software work
2) WHAT will be done?Task set which is required for project
3) By WHEN?Project schedule
4) WHO is responsible for a function?Role and responsibility of each member must be
defined
5) WHERE are they organizationally located?All roles don’t reside with in software team
1) WHY is the system being developed?Validity of business reasons for software work
2) WHAT will be done?Task set which is required for project
3) By WHEN?Project schedule
4) WHO is responsible for a function?Role and responsibility of each member must be
defined
5) WHERE are they organizationally located?All roles don’t reside with in software team
W5HH Principle (cont.)W5HH Principle (cont.)
6) HOW will the job be done technically and managerially?After scope, strategy is need to be build
7) HOW MUCH of each resource (e.g., people, software, tools, database) will be needed?Estimates are required
6) HOW will the job be done technically and managerially?After scope, strategy is need to be build
7) HOW MUCH of each resource (e.g., people, software, tools, database) will be needed?Estimates are required
Measures, Metrics and Indicators
Measures, Metrics and Indicators
Measure (number of errors in component)Provides quantitative indication of the extent,
amount, dimension, capacity or size of some attribute of product or process
Measurement (finding mechanism)Act of determining a measure
Metric (average number of errors found by one test)A measure of degree to which a system, component
or process possess a given attribute Indicator (test1 performed better)
Metric(s) that provide insight
Measure (number of errors in component)Provides quantitative indication of the extent,
amount, dimension, capacity or size of some attribute of product or process
Measurement (finding mechanism)Act of determining a measure
Metric (average number of errors found by one test)A measure of degree to which a system, component
or process possess a given attribute Indicator (test1 performed better)
Metric(s) that provide insight
Software Qualitymeasurement is essential, if quality is to be
achieved
Software Qualitymeasurement is essential, if quality is to be
achieved
Quality is Conformance to explicitly stated functional and
performance requirementsExplicitly documented development
standardsImplicit characteristics – expected of all
professionally developed software
Quality is Conformance to explicitly stated functional and
performance requirementsExplicitly documented development
standardsImplicit characteristics – expected of all
professionally developed software
McCall’s Quality Factors McCall’s Quality Factors
Transition
PortabilityReusabilityInteroperability
MaintainabilityFlexibilityTestability
Correctness
Reliability
Usability
Integrity
Efficiency
Production OperationProduction Operation Correctness
Extent to which program satisfies specifications and customer’s objectives (defects per KLOC)
Reliability Extent to which program can be expected to perform its
intended function with precision Usability
Effort required to learn, operate, prepare input for and interpret output
Integrity Extent of control on unauthorized access
Efficiency Amount of computing resources required
Correctness Extent to which program satisfies specifications and
customer’s objectives (defects per KLOC) Reliability
Extent to which program can be expected to perform its intended function with precision
Usability Effort required to learn, operate, prepare input for and
interpret output Integrity
Extent of control on unauthorized access Efficiency
Amount of computing resources required
Product TransitionProduct Transition
PortabilityEffort required to transfer the program from
one hardware/software system environment to another
ReusabilityExtent to which a program can be reused in
other applications Interoperability
Effort required to couple one system to another
PortabilityEffort required to transfer the program from
one hardware/software system environment to another
ReusabilityExtent to which a program can be reused in
other applications Interoperability
Effort required to couple one system to another
Product RevisionProduct Revision
Maintainability the ease that a program can be corrected adapted if the environment changes enhanced if the customer desires changes in
requirements based on the time-oriented measure mean time
to change. Flexibility
Effort required to modify an operational program Testability
Effort required to test a program
Maintainability the ease that a program can be corrected adapted if the environment changes enhanced if the customer desires changes in
requirements based on the time-oriented measure mean time
to change. Flexibility
Effort required to modify an operational program Testability
Effort required to test a program
Product MetricsProduct MetricsSingle Metric: “IMPOSSIBLE HOLY GRAIL”=> No single metrics for Software Complexity
Single Metric: “IMPOSSIBLE HOLY GRAIL”=> No single metrics for Software Complexity
Product MetricsProduct Metrics
Evaluation of analysis and design models
Indication of complexity of procedural designs and source code
Facilitate design for effective testing
Evaluation of analysis and design models
Indication of complexity of procedural designs and source code
Facilitate design for effective testing
Metrics for Analysis ModelMetrics for Analysis Model
Functionality DeliveredIndirect measure of functionality that is
deliveredSystem Size
Measures over all size of system (LOC)Specification Quality
Indication of completeness
Functionality DeliveredIndirect measure of functionality that is
deliveredSystem Size
Measures over all size of system (LOC)Specification Quality
Indication of completeness
Function Based Metricsproposed by Albrecht
Function Based Metricsproposed by Albrecht
Function Point Metric (FP) Means of measuring the functionality delivered
by system Use historic data to
Estimate cost or effort required to design, code and test Predict number of errors Forecast number of components and number of LOC
Derived using empirical relationship based on
countable measures of software information domain and assessment of software complexity
Function Point Metric (FP) Means of measuring the functionality delivered
by system Use historic data to
Estimate cost or effort required to design, code and test Predict number of errors Forecast number of components and number of LOC
Derived using empirical relationship based on
countable measures of software information domain and assessment of software complexity
Information Domain valuesInformation Domain values
Number of external Input (EIs) Input originate from user or another application
Number of External Output (EOs) Provide information to user
Number of external inquiries (EQs) Input that results in generation of system response
Number of Internal Logic Files (ILFs) Logical grouping of data that resides within
application Number of External Interface Files (EIFs)
Logical grouping of data that resides external to application
Number of external Input (EIs) Input originate from user or another application
Number of External Output (EOs) Provide information to user
Number of external inquiries (EQs) Input that results in generation of system response
Number of Internal Logic Files (ILFs) Logical grouping of data that resides within
application Number of External Interface Files (EIFs)
Logical grouping of data that resides external to application
Function Point CalculationFunction Point Calculation
Weighting Factormeasurement parameter count simple averagecomplex
number of user outputs * 4 5 7=# of user inquiries * 3 4 6 =
number of files * 7 10 15 =# of external interfaces * 5 7 10 =
count_total
number of user inputs * 3 4 6=
Function Point CalculationFunction Point Calculation
Computing function pointsRate each factor on a scale of 0 to 5
no influence incidental moderate average significant essential
0 1 2 3 4 5
1. does the system require reliable backup and recovery?
2. are data communications required?
3. are there distributed processing functions?
4. is performance critical?
........
14. is the application designed to facilitate change and ease of use by the user?
Function-Oriented MetricsFunction-Oriented Metrics
FP = count_total * [0.65 + 0.01 * sum of Fi]FP = count_total * [0.65 + 0.01 * sum of Fi]
Outcome:errors per FPdefects per FP$ per FPpage of documentation per FPFP per person_month
A dataflow Model for SafeHome Software
A dataflow Model for SafeHome Software
UserSafeHome
user Interaction Function
Sensors
user
Monitoring & Response subsystem
System Configuration data
Password
Zone Inquiry
Sensor Inquiry
Panic Button
Activate/deactivate
Test Senso
r
Zone Setting
Messages
Sensor StatusActivate/deactivateAlarm Alert
Password, sensors…
Information Domain MeasuresInformation Domain Measures
EI: password, panic button, activate/deactivate
EQ: Zone Inquiry, Sensor Inquiry ILF: System Configuration FileEO: Messages and Sensor StatusEIF: Test Sensor, Zone Setting,
Activate/Deactivate, Alarm Alert
EI: password, panic button, activate/deactivate
EQ: Zone Inquiry, Sensor Inquiry ILF: System Configuration FileEO: Messages and Sensor StatusEIF: Test Sensor, Zone Setting,
Activate/Deactivate, Alarm Alert
Function Point CalculationFunction Point Calculation
Weighting Factormeasurement parameter count simple averagecomplex
number of user outputs 2 * 4 5 7=# of user inquiries 2 * 3 4 6 =
number of files 1 * 7 10 15 =# of external interfaces4 * 5 7 10 =
count_total207689
50
number of user inputs 3 * 3 4 6=
Function-Oriented MetricsFunction-Oriented Metrics
FP = 50 * [0.65 + 0.01 * 46] = 56*** 46 is for moderately complex product
FP = 50 * [0.65 + 0.01 * 46] = 56*** 46 is for moderately complex product
Outcome:errors per FPdefects per FP$ per FPpage of documentation per FPFP per person_month
Typical Size-Oriented MetricsTypical Size-Oriented Metrics
Errors per KLOC Errors per KLOC Defects per KLOC Dollars per KLOC Pages of documentation per KLOC Errors per person month LOC per person month Dollars per page of documentation
Metrics for Design ModelMetrics for Design Model
Architectural MetricsComponent level metrics Interface design metricsSpecialized OO Design Metrics
CBO (coupling between object classes)LCOM (lack of Cohesion in Methods)
Architectural MetricsComponent level metrics Interface design metricsSpecialized OO Design Metrics
CBO (coupling between object classes)LCOM (lack of Cohesion in Methods)
Metrics for Source CodeMetrics for Source Code
Complexity MetricsLength Metrics
Complexity MetricsLength Metrics
Metrics for TestingMetrics for Testing
Statement and branch coverage metrics
Defect related metricsTesting Effectiveness
Statement and branch coverage metrics
Defect related metricsTesting Effectiveness
Project MetricsProject Metrics
Software Project Measures Are Tacticalused by a project manager and a software teamto adapt project work flow and technical activities
Software Project Measures Are Tacticalused by a project manager and a software teamto adapt project work flow and technical activities
• The Intent of Project Metrics Is Twofold to minimize the development schedule to assess project quality on an ongoing basis
Production Rates pages of documentation review hours function points delivered source lines errors uncovered during SW engineering
Software MetricsSoftware Metrics
Direct measures Cost and effort applied (in SEing process) Lines of code(LOC) produced Execution speed CPU utilization Memory size Defects reported over certain period of time
Direct measures Cost and effort applied (in SEing process) Lines of code(LOC) produced Execution speed CPU utilization Memory size Defects reported over certain period of time
Indirect Measures Functionality, quality, complexity,
efficiency, reliability, maintainability.
Defect Removal EfficiencyDefect Removal Efficiency
Defect removed before shipment as a percentage of total defects
DRE = E/(E+D)
E – errors found before deliveryD – errors found after delivery (within the
first year of operation)
Defect removed before shipment as a percentage of total defects
DRE = E/(E+D)
E – errors found before deliveryD – errors found after delivery (within the
first year of operation)
Defect Removal EfficiencyJones 1997
Defect Removal EfficiencyJones 1997
Design InspectionCode InspectionQuality AssuranceTestingWorst 30% 37% 50% 55% 65% 75% 77% 85% 95%Median 40% 53% 65% 70% 80% 87% 90% 97% 99%Best 50% 60% 75% 80% 87% 93% 95% 99% 99.9%
Sample size – 1500 projects
BaselineBaseline
‘Data colleted from past projects’
Data must be reasonably accurateData should be collected over many
projectsMeasures must be consistent –
same technique or yardstick for data collection
Applications should be similar to work that is to be estimated
Feedback to improve baseline’s quality
‘Data colleted from past projects’
Data must be reasonably accurateData should be collected over many
projectsMeasures must be consistent –
same technique or yardstick for data collection
Applications should be similar to work that is to be estimated
Feedback to improve baseline’s quality
Empirical Estimation ModelsEmpirical Estimation ModelsBased upon historic data
Basic Structure E = A + B * (ev)C
whereA, B, c are empirical constants‘ev’ is the effort in terms of lines of code or FP ‘E’ is the effort in terms of person months
COCOMO - COnstructive COst MOdel
E = 3.2 (KLOC)1.05
Based upon historic data Basic Structure
E = A + B * (ev)C
whereA, B, c are empirical constants‘ev’ is the effort in terms of lines of code or FP ‘E’ is the effort in terms of person months
COCOMO - COnstructive COst MOdel
E = 3.2 (KLOC)1.05
Software Project EstimationSoftware Project Estimation
Project adjustment components Problem complexity Staff experience Development environment and tools
Factors – human, technical, environmental, political
Estimation is difficult – not an exact science
Project adjustment components Problem complexity Staff experience Development environment and tools
Factors – human, technical, environmental, political
Estimation is difficult – not an exact science
The Software EquationThe Software Equation
It’s a Dynamic Multivariable Estimation Model
Assumes a specific distribution of effort over the life of the software development project
Derived from productivity data collected for over 4000 projects
It’s a Dynamic Multivariable Estimation Model
Assumes a specific distribution of effort over the life of the software development project
Derived from productivity data collected for over 4000 projects
E = [LOC x B0.333/P]3 x (1/t4)E = [LOC x B0.333/P]3 x (1/t4)
E – effort in person months or person years t – project duration in months or years B – special skill factor
Increases slowly as the need for integration, testing, QA, documentation, management skills grow
P – productivity parameter Overall process maturity and management practices The extent to which good SE practices are used The level of programming language used The state of the software environment The skills and experience of the software team The complexity of the application
E – effort in person months or person years t – project duration in months or years B – special skill factor
Increases slowly as the need for integration, testing, QA, documentation, management skills grow
P – productivity parameter Overall process maturity and management practices The extent to which good SE practices are used The level of programming language used The state of the software environment The skills and experience of the software team The complexity of the application
Buy versus buildBuy versus build
Develop specification for function and performance of the desired software. Define measurable characteristics whenever possible
Estimate internal cost and time to develop Select 3-4 candidate applications that best
meet your specifications Select reusable software components that
will assist in constructing the required application
Develop specification for function and performance of the desired software. Define measurable characteristics whenever possible
Estimate internal cost and time to develop Select 3-4 candidate applications that best
meet your specifications Select reusable software components that
will assist in constructing the required application
Buy versus buildBuy versus build
Develop comparison matrix that presents a head-to-head comparison of key function. Alternatively, conduct benchmark tests to compare candidate software
Evaluate each software package or component based on past product quality, vendor support, product direction, reputation, etc
Contact other users of the software and ask for opinion
Develop comparison matrix that presents a head-to-head comparison of key function. Alternatively, conduct benchmark tests to compare candidate software
Evaluate each software package or component based on past product quality, vendor support, product direction, reputation, etc
Contact other users of the software and ask for opinion
Buy versus buildBuy versus build
Delivery dateDevelopment Cost
Acquisition + customizationMaintenance Cost
Delivery dateDevelopment Cost
Acquisition + customizationMaintenance Cost
Cost estimation is one of the issues addressed in Project Plan
Cost estimation is made forCost benefit analysis by customer &
developerFor bidding purposesFor project control once development
begins
Cost estimation is one of the issues addressed in Project Plan
Cost estimation is made forCost benefit analysis by customer &
developerFor bidding purposesFor project control once development
begins
Break-down of project costBreak-down of project cost
Requirements of software, hardware & human resources.Hardware resource : Computer, terminal
time, memory required etc.Software resource: Tools, Compilers etc.Human Resources:
Bulk of the cost is due to human resource needed. Cost models focus on that & calculate effort in Person-months.
Requirements of software, hardware & human resources.Hardware resource : Computer, terminal
time, memory required etc.Software resource: Tools, Compilers etc.Human Resources:
Bulk of the cost is due to human resource needed. Cost models focus on that & calculate effort in Person-months.
Uncertainties of Cost Estimation
Uncertainties of Cost Estimation
Cost estimation can be provided at any stage of development life cycle.
Later is more accurate, as we have more information about the final product.
At the beginning a lot of uncertainty exists about the actual specification of the system.
At the beginning stage cost estimates can’t be accurate and can be off by as much as the factor of 4.
Cost estimation can be provided at any stage of development life cycle.
Later is more accurate, as we have more information about the final product.
At the beginning a lot of uncertainty exists about the actual specification of the system.
At the beginning stage cost estimates can’t be accurate and can be off by as much as the factor of 4.
Parameters affecting costParameters affecting cost
Cost for a project is a function of many parametersSize of the projectProgrammers abilityExperience in the areaComplexity of the project Reliability Requirements
Cost for a project is a function of many parametersSize of the projectProgrammers abilityExperience in the areaComplexity of the project Reliability Requirements
Software Project EstimationSoftware Project Estimation
Purpose To achieve reliable cost and effort estimates
Delay estimation until late in the project Base estimates on similar projects that have
already been completed. Use relatively simple decomposition techniques
to generate project cost and effort estimates. Use one or more empirical models for software
cost and effort estimation.
Purpose To achieve reliable cost and effort estimates
Delay estimation until late in the project Base estimates on similar projects that have
already been completed. Use relatively simple decomposition techniques
to generate project cost and effort estimates. Use one or more empirical models for software
cost and effort estimation.
Decomposition Techniques“divide and conquer” approachCost and effort estimation done step wise
Empirical estimation modelsComplement decomposition techniquesA model based on experience
Decomposition Techniques“divide and conquer” approachCost and effort estimation done step wise
Empirical estimation modelsComplement decomposition techniquesA model based on experience
Software SizingSoftware Sizing
The accuracy of a software project estimate is predicated on Degree to which the planner has properly
estimated the size of the product to be built Ability to translate the size estimate into human
effort, calendar time, and dollars Degree to which the project plan reflects the
abilities of the software team Stability of product requirements and the
environment that supports the software engineering effort.
The accuracy of a software project estimate is predicated on Degree to which the planner has properly
estimated the size of the product to be built Ability to translate the size estimate into human
effort, calendar time, and dollars Degree to which the project plan reflects the
abilities of the software team Stability of product requirements and the
environment that supports the software engineering effort.
Cost ModelCost ModelCost model requires some
knowledge or estimate of some of the parameters, which are then used to predict the cost.
COCOMO gives estimates within 20% of actual cost 68% of time.
Cost model requires some knowledge or estimate of some of the parameters, which are then used to predict the cost.
COCOMO gives estimates within 20% of actual cost 68% of time.
COCOMOCOCOMO
Boehm derived a cost model called COCOMO (Constructive Cost Model) using data from a large set of projects at TRW, a consulting firm based in California (Fenton, 1997).
COCOMO is a relatively straightforward model based on inputs relating to the size of the system and a number of cost drivers that affect productivity.
The original COCOMO model was first published in 1981 (Boehm, 1981).
Boehm and his colleagues have since defined an updated COCOMO, called COCOMO II, that accounts for recent changes in software engineering technology (Fenton, 1997).
Boehm derived a cost model called COCOMO (Constructive Cost Model) using data from a large set of projects at TRW, a consulting firm based in California (Fenton, 1997).
COCOMO is a relatively straightforward model based on inputs relating to the size of the system and a number of cost drivers that affect productivity.
The original COCOMO model was first published in 1981 (Boehm, 1981).
Boehm and his colleagues have since defined an updated COCOMO, called COCOMO II, that accounts for recent changes in software engineering technology (Fenton, 1997).
COCOMO ModelCOCOMO Model
It is a multivariable model Obtain an initial estimate of effort from the
estimate of KDL Determine a set of 15 multiplying factors from
different attributes of a project (cost drivers) Adjust the effort estimate by multiplying the
initial estimate with all the multiplying factors.
Initial estimate of effort in person-month is determined by : Ei= a*( KDL)^b
It is a multivariable model Obtain an initial estimate of effort from the
estimate of KDL Determine a set of 15 multiplying factors from
different attributes of a project (cost drivers) Adjust the effort estimate by multiplying the
initial estimate with all the multiplying factors.
Initial estimate of effort in person-month is determined by : Ei= a*( KDL)^b
Values of the constants ‘a’ and ‘b’ depend on the project type.
Values of the constants ‘a’ and ‘b’ depend on the project type.
Organic - In Organic type relatively small software teams develop familiar types of software in an in-house environment. Most of the personals has previous experience in working with related or similar systems
Examples – simple business systems, simple inventory mgmt. Systems, and data processing systems
Embedded Type - The project may require new technology, unfamiliar algorithms, or an innovative new method for solving a problem. Organization has little experience.
Examples – embedded avionics systems and real-time command systems
Semi-detached - Is an intermediate stage between organic and embedded type. It has a mixture of organic and intermediate characteristics
Examples – developing a new os, a dbms and complex inventory mgmt. system
Organic - In Organic type relatively small software teams develop familiar types of software in an in-house environment. Most of the personals has previous experience in working with related or similar systems
Examples – simple business systems, simple inventory mgmt. Systems, and data processing systems
Embedded Type - The project may require new technology, unfamiliar algorithms, or an innovative new method for solving a problem. Organization has little experience.
Examples – embedded avionics systems and real-time command systems
Semi-detached - Is an intermediate stage between organic and embedded type. It has a mixture of organic and intermediate characteristics
Examples – developing a new os, a dbms and complex inventory mgmt. system
Type Effort Organic Ei = 3.2(KDSI)1.05 , Semi-Detached Ei = 3.0(KDSI)1.12
Embedded Ei= 2.8(KDSI)1.20
KDSI = Delivered source instruction in thousands
Type Effort Organic Ei = 3.2(KDSI)1.05 , Semi-Detached Ei = 3.0(KDSI)1.12
Embedded Ei= 2.8(KDSI)1.20
KDSI = Delivered source instruction in thousands