Embed Size (px)
DESCRIPTION
dddd
Citation preview
SOFTWARE PROJECT MANAGEMENT
TOPIC 8
1
Software project managementConcerned with activities involved in ensuring that
software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.
Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.
2
Management activities1. Proposal writing.2. Project planning and scheduling.3. Project costing.4. Project monitoring and reviews.5. Personnel selection and evaluation.6. Report writing and presentations.
3
Management commonalitiesThese activities are not peculiar to software management.Many techniques of engineering project
management are equally applicable to software project management.
Technically complex engineering systems tend to suffer from the same problems as software systems.
4
Project staffingMay not be possible to appoint the ideal people to work
on a project:i. Project budget may not allow for the use of highly-
paid staff;ii. Staff with the appropriate experience may not be
available;An organisation may wish to develop employee skills on a
software project.Managers have to work within these constraints especially
when there are shortages of trained staff.
5
Project planningProbably the most time-consuming project management
activity.Continuous activity from initial concept through to
system delivery. Plans must be regularly revised as new information becomes available.
Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget.
6
Types of project plans
7
Plan Description
Quality plan Describes the quality procedures and standards that will beused in a project. See Chapter 27.
Validation plan Describes the approach, resources and schedule used forsystem validation. See Chapter 22.
Configurationmanagement plan
Describes the configuration management procedures andstructures to be used. See Chapter 29.
Maintenance plan Predicts the maintenance requirements of the system,maintenance costs and effort required. See Chapter 21.
Staff developmentplan.
Describes how the skills and experience of the project teammembers will be developed. See Chapter 25.
Project planning process
8
The project planThe project plan sets out:
I. The resources available to the project;II. The work breakdown;III. A schedule for the work.
9
Project plan structure1. Introduction.2. Project organisation.3. Risk analysis.4. Hardware and software resource requirements.5. Work breakdown.6. Project schedule.7. Monitoring and reporting mechanisms.
10
Activity organizationActivities in a project should be organised to produce
tangible outputs for management to judge progress.Milestones are the end-point of a process activity.Deliverables are project results delivered to customers.The waterfall process allows for the straightforward
definition of progress milestones.
11
Milestones in the RE process
12
Evalua tionrepor t
Prototypede velopment
Userrequirements
Requir ementsanalysis
Feasibilityrepor t
Feasibilitystud y
Architectur aldesign
Designstud y
Systemrequirements
Requir ementsspecification
ACTIVITIES
MILESTONES
Project schedulingSplit project into tasks and estimate time and
resources required to complete each task.Organize tasks concurrently to make optimal use of
workforce.Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.Dependent on project managers intuition and experience.
13
The project scheduling process
14
Estimate resourcesfor activities
Identify activitydependencies
Identifyactivities
Allocate peopleto activities
Softwarerequirements
Activity chartsand bar char ts
Create projectchar ts
Scheduling problemsEstimating the difficulty of problems and hence the cost of
developing a solution is hard.Productivity is not proportional to the number of people
working on a task.Adding people to a late project makes it later because of
communication overheads.The unexpected always happens. Always allow contingency
in planning.
15
Bar charts and activity networksGraphical notations used to illustrate the project schedule.Show project breakdown into tasks. Tasks should not be
too small. They should take about a week or two.Activity charts show task dependencies and the critical
path.Bar charts show schedule against calendar time.
16
Task durations and dependencies
17
Activity Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
Activity network
18
star t
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7 /03
8 da y s
14/7 /03 15 da y s
4/8/03
15 da ys
25/8/03
7 da ys
5/9/03
10 day s
19/9/03
15 da ys
11/8/03
2 5 da ys
10 da y s
20 da y s
5 da y s25/7 /03
15 da y s
25/7 /03
1 8/7 /03
10 da ys
T1
M1 T3T9
M6
T11
M8
T12
M4
Activity timeline
19
4/7 11/7 18/7 2 5/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11M8
T12
Star t
Finish
Staff allocation
20
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
Risk managementRisk management is concerned with identifying risks
and drawing up plans to minimise their effect on a project.
A risk is a probability that some adverse circumstance will occur ◦ Project risks affect schedule or resources;◦ Product risks affect the quality or performance of the
software being developed;◦ Business risks affect the organisation developing or
procuring the software.
21
Software risks
22
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule.
Requirements change Project and product
There will be a larger number of changes to the requirements than anticipated.
Specification delays Project and product
Specifications of essential interfaces are not available on schedule
Size underestimate Project and product
The size of the system has been underestimated.
CASE tool under-performance
Product CASE tools which support the project do not perform as anticipated
Technology change Business The underlying technology on which the system is built is superseded by new technology.
Product competition Business A competitive product is marketed before the system is completed.
The risk management process1. Risk identification◦ Identify project, product and business risks;
1. Risk analysis◦ Assess the likelihood and consequences of these risks;
1. Risk planning◦ Draw up plans to avoid or minimise the effects of the
risk;1. Risk monitoring◦ Monitor the risks throughout the project;
23
The risk management process
24
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
Risk identificationi. Technology risks; risks that derive from the software
or hardware technologies that are used to develop the system.
ii. People risks; risks that are associated with the people in the development team.
iii. Organisational risks; risks that derive from organizational environment where the software is being developed.
iv. Requirements risks; risks that derive from changes to the customer requirements and the process of managing the requirements change.
v. Estimation risks; risks that derive from the management estimates of the resources required to build the system.
25
Risks and risk types
26
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per secondas expected.Software components that should be reused contain defects that limit theirfunctionality.
People It is impossible to recruit staff with the skills required.Key staff are ill and unavailable at critical times.Required training for staff is not available.
Organisational The organisation is restructured so that different management are responsible forthe project.Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed.Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.The rate of defect repair is underestimated.The size of the software is underestimated.
Risk analysisAssess probability and seriousness of each risk.Probability may be very low, low, moderate, high
or very high.Risk effects might be catastrophic, serious,
tolerable or insignificant.
27
Risk analysis
28
Risk Probability Effects
Organisational financial problems force reductions inthe project budget.
Low Catastrophic
It is impossible to recruit staff with the skills requiredfor the project.
High Catastrophic
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused containdefects which limit their functionality.
Moderate Serious
Changes to requirements that require major designrework are proposed.
Moderate Serious
The organisation is restructured so that differentmanagement are responsible for the project.
High Serious
Risk analysis
29
Risk Probability Effects
The database used in the system cannot process asmany transactions per second as expected.
Moderate Serious
The time required to develop the software isunderestimated.
High Serious
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the im pact ofrequirements changes.
Moderate Tolerable
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestim ated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is ineffi cient. Moderate Insignificant
Risk planningConsider each risk and develop a strategy to manage that
risk.1. Avoidance strategies◦ The probability that the risk will arise is reduced;
1. Minimisation strategies◦ The impact of the risk on the project or product will be
reduced;1. Contingency plans◦ If the risk arises, contingency plans are plans to deal
with that risk;
30
Risk management strategies
31
Risk Strategy
Organisationalfinancial problems
Prepare a briefing document for senior managementshowing how the project is making a very importantcontribution to the goals of the business.
Recruitmentproblems
Alert customer of potential difficulties and thepossibility of delays, investigate buying-incomponents.
Staff illness Reorganise team so that there is more overlap of workand people therefore understand each other’s jobs.
Defectivecomponents
Replace potentially defective components with bought-in components of known reliabilit y.
Risk management strategies
32
Risk Strategy
Requirementschanges
Derive traceabili ty information to assess requirementschange impact, maximise information hiding in thedesign.
Organisationalrestructuring
Prepare a briefing document for senior managementshowing how the project is making a very importantcontribution to the goals of the business.
Databaseperformance
Investigate the possibilit y of buying a higher-performance database.
Underestimateddevelopment time
Investigate buying in components, investigate use of aprogram generator
Risk monitoringAssess each identified risks regularly to decide whether
or not it is becoming less or more probable.Also assess whether the effects of the risk have changed.Each key risk should be discussed at management
progress meetings.
33
Risk indicators
34
Risk type Potential indicators
Technology Late delivery of hardware or support software, many reported technology problems
People Poor staff morale, poor relationships amongst team member, job availability
Organisational Organisational gossip, lack of action by senior management
Tools Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported defects
Key points
Good project management is essential for project success.
The intangible nature of software causes problems for management.
Managers have diverse roles but their most significant activities are planning, estimating and scheduling.
Planning and estimating are iterative processes which continue throughout the course of a project.
35
Key points
A project milestone is a predictable state where a formal report of progress is presented to management.
Project scheduling involves preparing various graphical representations showing project activities, their durations and staffing.
Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats.
36
37
Software cost estimation
38
Software cost componentsHardware and software costs.Travel and training costs.Effort costs (the dominant factor in most
projects)◦ The salaries of engineers involved in the project;◦ Social and insurance costs.
Effort costs must take overheads into account◦ Costs of building, heating, lighting.◦ Costs of networking and communications.◦ Costs of shared facilities (e.g library, staff restaurant,
etc.).
39
Costing and pricingEstimates are made to discover the cost, to the
developer, of producing a software system.There is not a simple relationship between the
development cost and the price charged to the customer.Broader organisational, economic, political and business
considerations influence the price charged.
40
Software pricing factors
41
A measure of the rate at which individual engineers involved in software development produce software and associated documentation.
Not quality-oriented although quality assurance is a factor in productivity assessment.
Essentially, we want to measure useful functionality produced per time unit.
Software productivity
42
Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc.
Function-related measures based on an estimate of the functionality of the delivered software. Function-
points are the best known of this type of measure.
Productivity measures
43
Estimating the size of the measure (e.g. how many function points).
Estimating the total number of programmer months that have elapsed.
Estimating contractor productivity (e.g. documentation team) and incorporating this estimate in overall estimate.
Measurement problems
44
Lines of code (LOC) is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code.
LOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or effort once the software is produced.
The measure was first proposed when programs were typed on cards with one line per card;
How does this correspond to statements as in Java which can span several lines or where there can be several statements on one line.
Lines of code
advantages:1. Scope for Automation of Counting: Since line of code
is a physical entity; manual counting effort can be easily eliminated by automating the counting process.
Small utilities may be developed for counting the LOC in a program. However, a code counting utility developed for a specific language cannot be used for other languages due to the syntactical and structural differences among languages.
2. An Intuitive Metric: line of code serves as an intuitive metric for measuring the size of software due to the fact that it can be seen and the effect of it can be visualizedThis way, LOC comes in handy to express the size of software among programmers with low levels of experience.
45
Disadvantages:1. Lack of Accountability: Lines of code measure suffers
from some fundamental problems. Some think it isn't useful to measure the productivity of a project using only results from the coding phase, which usually accounts for only 30% to 35% of the overall effort.
2. Lack of Cohesion with Functionality: Though experiments have repeatedly confirmed that effort is highly correlated with LOC, functionality is less well correlated with LOC. That is, skilled developers may be able to develop the same functionality with far less code, so one program with less LOC may exhibit more functionality than another similar program. In particular, LOC is a poor productivity measure of individuals, because a developer who develops only a few lines may still be more productive than a developer creating more lines of code.
46
Cont’d
3. Adverse Impact on Estimation: estimates based on lines of code can adversely go wrong, in all possibility.
4. Developer’s Experience: Implementation of a specific logic differs based on the level of experience of the developer.
Hence, number of lines of code differs from person to person. An experienced developer may implement certain functionality in fewer lines of code than another developer of relatively less experience does, though they use the same language.
47
48
The lower level the language, the more productive the programmer◦ The same functionality takes more code to implement in
a lower-level language than in a high-level language.The more verbose the programmer, the higher the
productivity◦ Measures of productivity based on lines of code suggest
that programmers who write verbose code are more productive than programmers who write compact code.
Productivity comparisons
49
System development times
Function pointsFunction point measures the functionality from the user
point of view, that is, on the basis of what the user request and receives in return. Therefore, it deals with the functionality being delivered, and not with the lines of code, source modules, files etc.
Measuring size in this way has the advantage that size measure is independent of the technology used to deliver the function.
50
Importance of function point (features)
This is independent of the languages tools, or methodology used for implementation.
They can be estimated from requirement specification or design specification.
They are directly linked to the statement of request.
51
52
Function pointsBased on a combination of program characteristics◦ external inputs and outputs;◦ user interactions;◦ external interfaces;◦ files used by the system.
A weight is associated with each of these and the function point count is computed by multiplying each raw count by the weight and summing all values.
53
Function pointsThe function point count is modified by complexity of the
project.FPs can be used to estimate LOC depending on the
average number of LOC per FP for a given language.◦ LOC = AVC * number of function points; ◦ AVC is a language-dependent factor varying from 200-
300 for assemble language to 2-40 for a 4GL;FPs are very subjective. They depend on the estimator◦ Automatic function-point counting is impossible.
54
Object pointsObject points (alternatively named application points)
are an alternative function-related measure to function points when 4Gls or similar languages are used for development.
Object points are NOT the same as object classes. The number of object points in a program is a weighted
estimate of:◦ The number of separate screens that are displayed;◦ The number of reports that are produced by the system;◦ The number of program modules that must be
developed to supplement the database code;
55
Object point estimationObject points are easier to estimate from a specification
than function points as they are simply concerned with screens, reports and programming language modules.
They can therefore be estimated at a fairly early point in the development process.
At this stage, it is very difficult to estimate the number of lines of code in a system.
56
Real-time embedded systems, 40-160 LOC/P-month.
Systems programs , 150-400 LOC/P-month.Commercial applications, 200-900
LOC/P-month.In object points, productivity has been measured
between 4 and 50 object points/month depending on tool support and developer capability.
Productivity estimates
57
Factors affecting productivity
58
All metrics based on volume/unit time are flawed because they do not take quality into account.
Productivity may generally be increased at the cost of quality.
It is not clear how productivity/quality metrics are related. If requirements are constantly changing then an approach
based on counting lines of code is not meaningful as the program itself is not static
Quality and productivity
59
Estimation techniquesThere is no simple way to make an accurate estimate of the
effort required to develop a software system◦ Initial estimates are based on inadequate information in a
user requirements definition;◦ The software may run on unfamiliar computers or use
new technology;◦ The people in the project may be unknown.
Project cost estimates may be self-fulfilling◦ The estimate defines the budget and the product is
adjusted to meet the budget.
60
Changing technologiesChanging technologies may mean that previous estimating
experience does not carry over to new systems.◦ Distributed object systems rather than mainframe
systems;◦ Use of web services;◦ Use of ERP or database-centred systems;◦ Use of off-the-shelf software;◦ Development for and with reuse;◦ Development using scripting languages;◦ The use of CASE tools and program generators.
61
Estimation techniques1. Expert judgement2. Estimation by analogy3. Algorithmic cost modelling4. Pricing to win5. Parkinson's law
62
Estimation techniques
Algorithmic cost modelling
A formulaic approach based on historical cost information and which is generally based on the size of the software.
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.
Advantages: Relatively cheap estimation method. Can be accurate if experts have direct experience of similar systems
Disadvantages: Very inaccurate if there are no experts!
Estimation by analogyThe cost of a project is computed by comparing the
project to a similar project in the same application domain
Advantages: Accurate if project data availableDisadvantages:Impossible if no comparable
project has been tackled. Needs systematically maintained cost database
Parkinson's LawThe project costs whatever resources are
availableAdvantages: No overspendDisadvantages: System is usually unfinished
Pricing to winThe project costs whatever the customer has to spend on
itAdvantages: You get the contractDisadvantages: The probability that the
customer gets the system he or she wants is small. Costs do not accurately reflect the work required
68
Top-down and bottom-up estimationAny of these approaches may be used top-down or
bottom-up.Top-down◦ Start at the system level and assess the overall system
functionality and how this is delivered through sub-systems.
Bottom-up◦ Start at the component level and estimate the effort
required for each component. Add these efforts to reach a final estimate.
69
Top-down estimationUsable without knowledge of the system architecture and
the components that might be part of the system.Takes into account costs such as integration,
configuration management and documentation.Can underestimate the cost of solving difficult low-level
technical problems.
70
Bottom-up estimationUsable when the architecture of the system is
known and components identified.This can be an accurate method if the system has
been designed in detail.It may underestimate the costs of system level
activities such as integration and documentation.
71
Algorithmic cost modelling Cost is estimated as a mathematical function of
product, project and process attributes whose values are estimated by project managers:◦ Effort = A × Size B × M
◦ A is an organisation-dependent constant, B reflects the disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes.
The most commonly used product attribute for cost estimation is code size.
Most models are similar but they use different values for A, B and M.
72
Estimate uncertainty
x
2 x
4x
0.5x
0.25x
Feasibility Requirements Design Code Delivery
73
The COCOMO modelCOCOMO model stands for Constructive Cost Model.An empirical model based on project experience.Well-documented, ‘independent’ model which is not tied
to a specific software vendor.Long history from initial version published in 1981
(COCOMO-81) through various instantiations to COCOMO 2.
COCOMO 2 takes into account different approaches to software development, reuse, etc.
74
COCOMO 81
75
COCOMO 2 COCOMO 81 was developed with the assumption that a waterfall
process would be used and that all software would be developed from scratch.
Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development.
76
COCOMO 2 models COCOMO 2 incorporates a range of sub-models that produce
increasingly detailed software estimates. The sub-models in COCOMO 2 are:◦ Application composition model. Used when software is
composed from existing parts.◦ Early design model. Used when requirements are available but
design has not yet started.◦ Reuse model. Used to compute the effort of integrating reusable
components.◦ Post-architecture model. Used once the system architecture has
been designed and more information about the system is available.
77
Use of COCOMO 2 models
Number ofapplication points
Number of functionpoints
Based on Used for
Used for
Used for
Used for
Based on
Based on
Based on
Number of lines ofcode reused or
generated
Number of lines ofsource code
Applicationcomposition model
Early design model
Reuse model
Post-architecturemodel
Prototype sy stemsdeveloped using
scripting, DBprog ramming etc.
Initial effortestimation based onsystem requirementsand design options
Effort to integ ratereusable components
or automaticallygenerated code
Development effor tbased on system
design specification
Types of COCOMO Models This model gives 3 levels of estimations namely basic, intermediate
and detail.
1.Basic COCOMO model It gives an order of magnitude of cost. This model uses estimated size of software project and the type of software being developed.
The estimation varies for various types of projects and these various kinds are:-
• Organic-mode project:- These project include relatively small teams working in a familiar environment, developing a well understood application, the feature of such project are-
78
Cont’ed
1) The communication overheads are low.
2) The team members know what they can achieve.3) This project is much common in nature.
• Semi-detached model: A project consists of mixed project team of experienced and fresh engineers. The team has limited experience of related system development and some of them are unfamiliar with output and also some aspects of system being developed.
• Embedded model:- There will be very strong coupled hardware, software regulations and operational procedures. Validation costs are very high. For e.g. System program and development of OCR for English.
79
2. Intermediate COCOMO modelThe intermediate COCOMO model estimates the software
development effort by using 15 cost drivers’ variables besides the size variable used in basic COCOMO.
Intermediate COCOMO computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes. This extension considers a set of four "cost drivers", each with a number of subsidiary attributes:
• Product attributeso Required software reliabilityo Size of application databaseo Complexity of the product
80
Cont’ed
Hardware attributeso Run-time performance constraintso Memory constraintso Volatility of the virtual machine environmento Required turnabout timePersonnel attributeso Analyst capabilityo Software engineering capabilityo Applications experienceo Virtual machine experienceo Programming language experienceProject attributes o Use of software tools o Application of software engineering methods o Required development schedule 81
3.Detailed COCOMO modelDetailed COCOMO - incorporates all characteristics of the
intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process.
The detailed COCOMO model can estimate the staffing cost and duration of each of the development phases, subsystem, and modules. It allows you to experiment with different development strategies, to find the plan that best suits your needs and resources.
82
development phases of the detailed COCOMO model
1. plan/requirements: this is the first phase of the development cycle. The requirement is analyzed, the product plan is set up and a full product specification is generated. This phase consumes from 6% to 8% of the effort and 10% to 40% of the development time.
2. product design: The second phase of the COCOMO development cycle is concerned with the determination of the product architecture and the specification of the subsystems. This requires 16% to 18% of the normal effort and 19% to 38% of the development time.
83
Cont’dCont’d
3. programming: This is the third phase and is divided into sub phases : detailed phase and code/unit phase. This requires 48% to 68% of the effort and 24% to 64% of the development time.
4. integration/test : This phase of COCOMO occurs before delivery. This mainly consists of putting the tested parts together and then testing the final product. This requires 16% to 34% of normal effort and 18% to 34% of the development time.
84
85
Application composition modelSupports prototyping projects and projects where
there is extensive reuse.Based on standard estimates of developer
productivity in application (object) points/month.Takes CASE tool use into account.Formula is◦ PM = ( NAP × (1 - %reuse/100 ) ) / PROD
◦ PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.
86
Object point productivity
87
Early design modelEstimates can be made after the requirements
have been agreed.Based on a standard formula for algorithmic
models◦ PM = A × SizeB × M where
◦ M = PERS × RCPX × RUSE × PDIF × PREX × FCIL × SCED;◦ A = 2.94 in initial calibration, Size in KLOC, B varies
from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity.
88
MultipliersMultipliers reflect the capability of the developers, the non-
functional requirements, the familiarity with the development platform, etc.◦ RCPX - product reliability and complexity;◦ RUSE - the reuse required;◦ PDIF - platform difficulty;◦ PREX - personnel experience;◦ PERS - personnel capability;◦ SCED - required schedule;◦ FCIL - the team support facilities.
89
The reuse modelTakes into account black-box code that is reused without
change and code that has to be adapted to integrate it with new code.
There are two versions:◦ Black-box reuse where code is not modified. An effort
estimate (PM) is computed.◦ White-box reuse where code is modified. A size
estimate equivalent to the number of lines of new source code is computed. This then adjusts the size estimate for new code.
90
Reuse model estimates 1For generated code:◦ PM = (ASLOC * AT/100)/ATPROD◦ ASLOC is the number of lines of generated code◦ AT is the percentage of code automatically generated.◦ ATPROD is the productivity of engineers in integrating
this code.
91
Reuse model estimates 2When code has to be understood and integrated:◦ ESLOC = ASLOC * (1-AT/100) * AAM.◦ ASLOC and AT as before.◦ AAM is the adaptation adjustment multiplier computed
from the costs of changing the reused code, the costs of understanding how to integrate the code and the costs of reuse decision making.
92
Project duration and staffingAs well as effort estimation, managers must
estimate the calendar time required to complete a project and when staff will be required.
Calendar time can be estimated using a COCOMO 2 formula◦ TDEV = 3 × (PM)(0.33+0.2*(B-1.01))
◦ PM is the effort computation and B is the exponent computed as discussed above (B is 1 for the early prototyping model). This computation predicts the nominal schedule for the project.
The time required is independent of the number of people working on the project.
93
Key points
There is not a simple relationship between the price charged for a system and its development costs.
Factors affecting productivity include: domain experience, process quality, the project size, technology support and the working environment.
Software may be priced to gain a contract and the
functionality adjusted to the price.
94
Key points
Different techniques of cost estimation should be used when estimating costs.
The COCOMO model takes project, product, personnel and hardware attributes into account when predicting effort required.
Algorithmic cost models support quantitative option analysis as they allow the costs of different options to be compared.
The time to complete a project is not proportional to the number of people working on the project.
