Software Project Planning
description
Transcript of Software Project Planning
Software Project Planning
SEN-269 : Software EngineeringEngr. Tazeen Muzammil
Project Planning
The overall goal of project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost and schedule.
Why?So the end result gets done on time, under budget and with quality!
2
Project Planning TaskEstablish project scopeDetermine feasibilityAnalyze risks (Done in previous lecture)Define required resources
Determine require human resourcesDefine reusable software resourcesIdentify environmental resources
Estimate cost and effortDecompose the problemDevelop two or more estimates using size, function points, process tasks or use-casesReconcile the estimates
Develop a project schedule (Done in previous lecture)
3
Software Sope
4
What is Scope?Software scope describes
the functions and features that are to be delivered to end-usersthe data that are input and outputthe “content” that is presented to users as a consequence of using the softwarethe performance, constraints, interfaces, and reliability that bound the system.
Scope is defined using one of two techniques:A narrative description of software scope is developed after communication with all stakeholders.A set of use-cases is developed by end-users.
5
Obtaining Information Necessary for Scope
Understand the customers needsUnderstand the business contextUnderstand the project boundariesUnderstand the customer’s motivationUnderstand the likely paths for changeUnderstand that ...
Even when you understand, nothing is guaranteed!
6
Feasibility
Once the scope has been identified, then we ask the following questions:
Technology: Do we have the requisite technology.Finance: Do we have the requisite finances/budget.Resources: Do we have the requisite skilled resources.
7
Resources
8
Resources
9
Estimation
10
EstimationEstimation of resources, cost, effort and schedule requires
experienceaccess to good historical information (metrics)the courage to commit to quantitative predictions when qualitative information is all that exists
Project scope must be understoodElaboration (decomposition) is necessaryAt least two different techniques should be usedUncertainty is inherent in the processEstimation should define
Best case scenarioWorst case scenario
11
Why Estimate Software?
30% of project never complete 100-200% cost overruns not uncommon Average project exceeds cost by 90%; schedule by 120% 15% of large project never deliver anything Only 16.2% of projects are successful
12
What are the consequences?
EconomicLoss of contracts Company failure
TechnicalDependency on software growing
ManagerialChange of personnel
13
Estimation Techniques
Expert JudgmentEstimation by AnalogyPricing to winDecomposition Techniques (e.g. LOC, FP Based )Empirical models (e.g. COCOMO)Automated EstimationTools
14
Expert JudgementOne or more experts in both software development and the application domain use their experience to predict software costs.Process iterates until some consensus is reached.Pros:
Little or no historical data needed. Suitable for new or unique projects.Relatively cheap method; Accurate if experts have direct experience of similar systems
Cons:Very subjective.Experts may introduce bias.
Larger number of experts will help to reduce biasQualification of experts may be questioned.
15
• Gather a group of experts together,• Describe overall program in enough detail so experts can
provide an estimate.• Each member of the expert group then does an
independent of the resources needed.• Estimates are gathered anonymously and compared,• If there exists significant divergence among the
estimates, the estimates will be returned to the expert group,
• The expert group then discusses the estimates and the divergence and works to resolve differences, and
• The expert group once again submits anonymous, independent estimates which continues until a stable estimate results.
16
Expert Judgement-Steps
Expert Judgement-Example
Three software engineers are renown in the ERP software development.
You hold interviews with each explaining the requirements, sizing level, and development process for your new system. Each member of the group submits their opinion of the final cost and the estimate converges to $50M.
17
Estimation by Analogy
Estimates costs by comparing proposed programs with similar, previously completed programs for which historical data is available.
Actual costs of similar existing system are adjusted for complexity, technical, or physical differences to derive new cost estimatesAnalogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed approachCompares similarities and differences
Focus is on main cost drivers.
18
Estimation by AnalogyPros:
InexpensiveEasily changedBased on actual experience (of the analogous system)
Cons:Very SubjectiveLarge amount of uncertaintyTruly similar projects must exist and can be hard to findMust have detailed technical knowledge of program and analogous systemNeeds systematically maintained cost database
19
Estimation by Analogy-Steps
Determine estimate needs/ground rules,Define new system,Breakout new system into subcomponents for analogy estimating,Assess data availability of historical similar systems,Collect historical system component technical and cost data,Process/normalize data into constant year dollars (e.g., constant FY2003$), Develop factors based on prior system,
Example: Program Management is 10% of total development cost
Develop new system component costs.Obtain complexity (and other translation) factorsExample: Historical database is for 4 million records and new database will need to house 24 million records => complexity factor of 6 (4*6 = 24) times the historical database costApply factors to historical costs to obtain new system costs
20
Estimation by Analogy- Example
Your company is developing a new IT payroll system serving 5,000 people and containing 100,000 lines of C++ code. Another company developed a similar 100,000 lines of code system for $20M for only 2,000 people. Your software engineers tell you that the new system is 25% more complicated than the other system. Other system development cost was $20M.
Estimated cost for new system = 1.25 * $20M = $25M
Plus 5,000/2,000, or 2.5 * $25M = $62.5M total cost
21
Pricing to winThe project costs whatever the customer has to spend on it.This approach may seem unethical and un-businesslike.However, when detailed information is lacking it may be the only appropriate strategy.The project cost is agreed on the basis of an outline proposal and the development is constrained by that cost.A detailed specification may be negotiated or an evolutionary approach used for system developmentAdvantages:
You get the contract.Disadvantages:
The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required.
22
Decomposition Techniques
23
Decomposition TechniquesTo obtain an estimation, we can decompose the problem to be solved, or decompose the process.Decomposition should be done in such a way that
1. size can be properly estimated,2. cost or effort required for each component
can be accurately estimated,3. the team's ability to handle the
components is well known, and
24
Problem-Based Estimation1. Based on the software scope, decompose the
software into problem functions that can be estimated individually.
2. Estimate LOC or FP of each function.3. Make optimistic (sopt), most likely (sm), and
pessimistic (spess) estimates for each item. Then compute the expected value:
EV (Expected Value) = (sopt + 4 sm + spess)/6
4. Apply baseline productivity metrics to compute estimated cost or effort.
25
ExampleProblem Statement: Take the Library management system case. Software developed for library will accept data from operator for issuing and returning books. Issuing and returning will require some validity checks. For issue it is required to check if the member has already issued the maximum books allowed. In case for return, if the member is returning the book after the due date then fine has to be calculated. All the interactions will be through user interface. Other operations include maintaining database and generating reports at regular intervals.
26
ExampleMajor software functions identified.
User interfaceDatabase managementReport generation
For user interfaceSopt : 1800Sm : 2000Spess : 4000
For database managementSopt : 4600Sm : 6900Spess : 8600
For report generationSopt : 1200Sm : 1600Spess : 3200
27
EV for user interfaceEV = (1800 + 4*2000 + 4000) / 6EV = 2300
EV for database managementEV = (4600 + 4*6900 + 8600) / 6EV = 6800
EV for report generationEV = (1200 + 4*1600 + 3200) / 6EV = 1800
Lines of code (LOC)
Given:LOC Estimate = 33200 LOCProductivity = 620 LOC/P-M(Person-Month)Labor Rate = $ 8000 P-M
Effort = LOC/ProductivityCost per LOC = Labor Rate/ProductivityProject Cost= LOC estimate * Cost per LOC
28
Effort = 54 P-MCost per LOC = $ 13 P-MProject Cost= $ 431600
LOC-Example
29
Functions
UICF
2DGA
3DGA
DSM
CGDF
PCF
DAM
Totals
estimated LOC $/LOC Cost Effort (months)LOC/pm
2340
5380
6800
3350
4950
2140
8400
33,360
14
20
20
18
22
28
18
315
220
220
240
200
140
300
32,000
107,000
136,000
60,000
109,000
60,000
151,000
655,000
7.4
24.4
30.9
13.9
24.7
15.2
28.0
145.0
Function PointFive information domain characteristics are determined and counts for each are provided and recorded in a table.
Number of user inputsNumber of user outputsNumber of user inquiresNumber of filesNumber of external interfaces
Once the data have been collected, a complexity value is associated with each count. Each entry can be simple, average or complex. Depending upon these complexity values is calculated.
30
Function PointFunction Point Formula:
FP = Count Total * [0.65+0.01*Sum(Fi)]
Fi are complexity adjustment values based on response to questions(1-14) given below. The constant values in the equation and the weighing factors that are applied to information domain are determined empirically.
Rate each factor on a scale of 0 to 5
0 - No influence1 - Incidental2 - Moderate3 - Average4 - Significant5 - Essential
Count-total is sum of all FP entries.
31
Fi1. Does the system require reliable backup and recovery?2. Are data communications required?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing, heavily utilized operational environment?6. Does the system require on-line entry?7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?8. Are the inputs, outputs, files, or inquiries complex9. Is the internal processing complex?10. Is the code designed to be reusable?11. Are master files updated on-line?12. Are conversion and installations included in the design?13. Is the system designed for multiple installations in different organizations?14. Is the application designed to facilitate change and ease of use by the user?
32
Function PointOnce function points have been calculated, productivity, quality, cost and documentation can be evaluated.
Productivity = FP / person-monthQuality = defects / FPDocumentation = pages of documentation / FPEffort = FP Estimate/ProductivityCost per FP = Labor rate/ProductivityProject Cost Estimate = FP * Cost per FP
33
Computing function-point metrics
34
Example (Same as LOC)
35
Information Domain Values
Optlikely
Pessest Account
wt FP Account
Number of Inputs 4 10 16 10 4 40
Number of Outputs 4 7 16 8 5 40
Number of Inquiries 5 12 19 12 4 48
Number of Files 3 6 9 6 10 60
Number of external interfaces
2 2 3 2 7 14
Count Total 202
ExampleComplexity weighing factors are determined and the following results are obtained.
36
Factor Value
Backup Recovery 4
Data Communication 1
Distributed processing 0
Perfomance Critical 3
Existing Operating Environment 2
On-line data entry 5
Input transaction over multiple screens
5
Master file updated online 3
Information domain values complex 3
Internal processing complex 2
Code design for reuse 0
Conversion/Installation in design 1
Multiple installations 3
Application designed for change 5
Sum ( Fi ) 37
ExampleEstimated number of FP :FPestimated = count-total * [0.65 + .01 * sum(Fi) ]FPestimated = 206From historical data, productivity is 55.5 FP/person-month and development cost is $8000 per month.Productivity = FP/ person-monthperson-month = FP/Productivity= 202/55.5 = 3.64 person-monthTotal Cost = Development cost * person-month= 8000 * 3.64=$29100Cost per FP = Cost/FP= 29100/202= $144.2per FP
37
Function Point-Example
38
number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces algorithms
measurement parameter
4 5 4 7 7 3
count
x x x x x x
count-total
= = = = = =
weight
complexity multiplier
feature points
0.25 p-m / FP = 120 p-m
40 25 12 4 4 60
160 125 48 28 28 180
569
.84
478
Given Productivity = 6.5 FP/P-MLabor Rate = $8000/P-M
Process-based estimationMost commonly-used technique for project estimationProject is broken down into a relatively small set of tasks and the effort required to accomplish each task is estimatedBegins with a delineation of software functions obtained from the project scope
Process-based estimationA series of framework activities must be performed for each functionRepresentative framework activities:
Customer communicationPlanning / risk analysisEngineeringConstruction / release
Functions and activities may be shown together as a table:
Process-based estimation table
Activity CC PlanningRisk
analysisEngineering Release CE Totals
Function Anal. Design Code Test
UICF 0.75 2.50 0.40 5.00 n/a 8.65
2DGA 0.75 4.00 0.60 2.00 n/a 7.35
3DGA 0.50 4.00 0.60 2.00 n/a 7.10
CGDF 0.50 4.00 1.00 3.00 n/a 8.50
DBM 0.50 3.00 1.00 1.50 n/a 6.00
PCF 0.25 2.00 0.75 1.50 n/a 4.50
DAM 0.50 2.00 0.50 2.00 n/a 5.00
Totals .25 .25 .25 3.50 17.50 4.25 15.00 34.80
% effort 1% 1% 1% 7% 45% 12% 40%
Process-based estimationOnce functions and activities are melded, the planner estimates the effort (person-months) required to accomplish each activity per functionAverage labor rates are then applied to the estimated efforts (may vary per task)Cost and effort for each function and activity (row and column totals) are computed as the last step
Empirical Estimation Models
An estimation model provides empirically derived formulas to predict effort as a function of LOC or FP.The data used to support these models are derived from a limited sample. Thus no model is appropriate for all classes of software.
43
Empirical models
Examples of Commercially Available ModelsCOCOMOThe Software EquationCOSTXPERTSLIMSEERCostar, REVIC, etc.
44
Structure of Estimation Model
E = A + B XC
where A, B, and C are empirically derived constants, E is the effort in person months, and X is the estimation variable, either in LOC or FP.
45
COCOMO
COCOMO, COnstructive COst MOdel is static single-variable model. Barry Boehm introduced COCOMO models. There is a hierarchy of these models. Model 1:
Basic COCOMO model is static single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code.
Model 2:Intermediate COCOMO model computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes.
Model 3:Advanced COCOMO model incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step, like analysis, design, etc.COCOMO can be applied to the following software project's categories.
46
Three Software Project's Categories
Organic -- a relatively small simple project in which small teams with good application experience work to a set of less than rigid requirements.
Semi-detached -- an intermediate project in which teams with mixed experience must meet a mix of rigid and less than rigid requirements.
Embedded -- a project that must meet tight hardware, software, and operational constraints.
47
COCOMOThe COnstructive COst MOdel
It is LOC-based.Formula:
E = a(KLOC)bT = cEd
where E is the effort required in person-months, T is the required development time in chronological months, KLOC is the estimated size of software in thousand lines of delivered source code. The constants a, b, c, and d are listed below:
48
The Software Equation
A dynamic multivariable modelE = [LOC x B0.333/P]3 x (1/t4)
whereE = effort in person-months or person-yearst = project duration in months or yearsB = “special skills factor”P = “productivity parameter”
49
Automated Estimation Tools
The automated estimation tools allow the planner to estimate cost and effort and to perform what if analysis for important project variables such as delivery date or staffing.Six generic functions:1. Sizing of project deliverables2. Selecting project activities3. Predicting staffing levels4. Predicting software effort5. Predicting software cost6. Predicting software schedules
50