Chapter 3 - Software Project Management - Estimation, Scheduling and Metrics
White diamond - aggregation (a part of)
Cost Estimation Techniques
- Expert Judgement
- Past Experience
- Build up a databank of past projects and their cost
- Top down
- Break the problem up into smaller problems and estimate these
- Function Point analysis
- Uses the requirement specification to assess inputs, outputs, file accesses, user interactions and interfaces and calculates the size based on these
- Algorithmic Cost Modelling
- COnstructive Cost MOdelling (COCOMO), Barry Boehm 1981, has been an influential approach
Function Point Analysis (FPA)
Getting an idea of complexity from the quantity of components.
The following system components are considered. Number of:
- external inputs (eg, input files of transactions)
- external outputs (eg output files of reports, messages)
- user interactions / enquiries (eg menu selection, queries)
- internal or logical files used by the system
- number of external or interface files shared with other applicatoins
In each case, depending on the number of field types associated with each component, and the variety of file types that these elements refer to, these components are rated as simple, average or complex.
A weight is associated with each of the ratings, simple average or complex. The number of external inputs is multiplied by the selected weighting for that system component likewise for external outputs and the other system components.
The weighted total are added to give the Unadjusted Function Points.
UFP is then adjusted to take account of the type of application
- This adjustment is made by multiplying UFP by a technical complexity factor.
- As preparation for calculating TCF, fourteen General System Characteristics are scored for Degree of Influence from 0 to 5 (no influence to strong influence)
- Data communications
- Distributed functions
- Heavily used configuration
- Transaction Rate
- On-line data entry
- End-user efficiency
- On-line update
- Complex Processing
- Installation ease
- Operational ease
- Multiple sites
- Facilitate change
TCF is then calculated as
TCF = 0.65 + 0.01 x DIwhere DI is the total Degree of Influence from the 14 scored characteristics
Function points (FP) are calculated as
FP = UFP * TCF. FPs can be used to estimate Lines of Code (LOC), assuming that the average number of LOC per FP for a given language can be calculated.
But there are some difficulties:
- FPs, and particularly the scores given to the General System Characteristics, are very subjective. They cannot be counted automatically and depend on the analyst's assessment.
- There are only 3 complexity levels for weighting the functionality of the main system components
- The approach has to be calibrated or adjusted for different programming tasks and environments
3 Classes of project are recognised
- Simple (or organic): small teams, familiar environment, well understood applications, no difficult non-functional requirements
- Moderate (or semi-detached): project team may have experience mixture, system may have more significant non-functional constraints, organisation may have less familiarity with application.
- Embedded: HW/SQ systems, tight constraints, unusual for team to have deep application experience.
COCOMO: E = a x KDSIb; D = 2.5 x Ec
- E = Effort in Person-months
- a, b, c = Constants based on project class & historical data
- D = development time in months
- KDSI = Thousands of delivered source instructions (~Lines of code)
The multipliers and exponents for basic COCOMO's formulae change according to the class of the project.
Intermediate COCOMO takes the basic COCOMO formula as its starting point. The value a is equal to 3.2, 3.0, 2.8, for organic, semi-detached and embedded projects respectively.
Additionally Intermediate COCOMO identifies personnel, product, computer and project attributes which affect cost. With intermediate COCOMO, the basic cost is adjusted by attribute multipliers: presently we'll give values to a sample of these multipliers:
These are attributes which were found to be significant in one organisation with a limited project history database. Other attributes may be more significant for other projects and other organisations.
In an on-going project, all products of the software process have to be managed.
- Test data
- User manuals
Thousands of separate documents are generated for a large software system.
- Defines the types of documents to be managed and a document naming scheme
- Defines who takes responsibility for the CM procedures and creation of baselines
- Defines policies for change control and version management
- Defines the CM records which must be maintained
The configuration database
All CM information should be maintained in a configuration database. This should allow for queries. The CM database should preferably be linked to the software being managed. (eg. Who has a particular system version? What platform is required for a particular version? What versions are affected by a change to component X?)
The change management process
- Request change by completing a change request form
- Analyse change request
- if change is valid then
- assess how change might be implemented
- asses change cost
- submit request to change control board
- if change is accepted then
- do this until software quality is adequate
- make changes to software
- submit changed software for quality approval
- create new system version
- do this until software quality is adequate
- reject change request
- reject change request
A record of changes applies to a document or code component. It should record, in outline form, the change made, the rationale for the change, who made the change and when it was implemented.
An instance of a system which is functionally distinct in some way from other system instances
An instance of a system which is functionally identical but non-functionally distinct from other instances of a system
An instance of a system which is distributed to users outside of the development team
When you can measure what you are speaking about and express it in numbers, you know something about it
Allow processes and products to be assessed. Used as indicators for improvement
Defect Removal Efficiency
Measures how good quality assurance is. DRE should be 1 (in an ideal situation)
DRE = E/(E+D)
E = Number of errors before delivery.
D = Number of defects after delivery.
Defects per kLOC
C = #defects/kLOC
A system's ability to withstand attacks (including accidental ones) on security
I = sigma[1 - threat x (1 - security)]
Threat = probability than an attack of a particular type will occur at a given time
Security = probability that an attack of that type will be repelled
'fan-in and fan-out' in a structure chart. High fan-in = high coupling. High fan-out = high coupling (complexity). Length is any measure of program size such as LOC.
Complexity = Length * (fan-in * fan-out)2
Probability of failure on demand
This is a measure of the likelihood that the system will fail when a service request is made. a PoFOD of 0.001 means that 1 out of every 1000 service requests result in failure. This is relevant for safety-critical or non-stop systems. It is computed by measuring the number of system failures for a given number of system inputs.
Rate of occurrence of failures at time t
The mean rate of failures per unit time at time
t. A RoCOF of 0.02 means 2 failures are likely in each 100 operational time units