Cost estimation 2
FPs can be used to estimate LOC
depending on the average number of LOC per function point for a given language LOC = AVC * function points - FPs are very subjective. They depend on the estimator
The most commonly used product attribute for cost estimation is...
is code size.
The exponent term
1. Precedentedness 2. Development flexibility 3. Architecture/risk resolution 4. Team cohesion 5. Process maturity
software productivity quantified by..
- Classic Approach is Lines of Code Produced/Day - Estimation of LoC per Task (Function, Class, etc.) - Cumulative Assessment of LoC for Project
Reuse model estimates for generated code
(LOC * % automatically generated code )/ productivity
Scheduling problems
- Estimating 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.
two estimation techniques
- Experience-based techniques - Algorithmic cost modeling
Estimation techniques
- Initial estimates are based on inadequate information in a user requirements definition • Project cost estimates may be self-fulfilling
Productivity comparisons (problems with LOC)
- The more verbose the programmer, the higher the productivity - The lower level the language, the more productive the programmer
Story-based planning (XP)
- The system specification in XP is based on user stories that reflect the features that should be included in the system. - The project team read and discuss the stories and rank them in order of the amount of time they think it will take to implement - Release planning involves selecting and refining the stories and the order in which the stories should be implemented. - Stories to be implemented in each iteration are chosen, with the number of stories reflecting the time to deliver an iteration (usually 2 or 3 weeks
Estimation accuracy factors
- Use of COTS and components; Programming language; Distribution of system. - The estimates of the factors contributing to B and M are subjective and vary according to the judgment of the estimator.
Project scheduling
- deciding how the work in a project will be organized as separate tasks, and when and how these tasks will be executed. • calendar time, the effort required and who will work on the tasks • resources needed to complete each task, such as the disk space, specialized hardware, such as a simulator, and what the travel budget
Agile planning
- developed and delivered in increments - functionality of these increments is not planned in advance but is decided during the development - customer's priorities and requirements change so it makes sense to have a flexible plan
Schedule Tracking
- each team member reports progress and problems. - milestones accomplished? - compare actual start to planned start - earned value analysis
Function points examples
- external inputs and outputs; - user interactions; - external interfaces; - files used by the system.
COCOMO 2 models submodes
1. Application composition model 2. Early design model 3. Reuse model 4. Post-architecture model
Factors affecting productivity
1. Application domain experience 2. Process quality 3. Project size 4. Technology support 5. Working environment
Productivity measures
1. Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc. 2. 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.
Estimation process overview
1. estimate size of product: algorithmic approach, size estimation software, previous experience 2. Estimate the effort (man-months) 3. Estimate the schedule (calendar months) 4. A more general step (a meta-step) - provide estimates in ranges and periodically refine the ranges to provide increasing precision as the project progresses
Effort Allocation
40-50% front-end activities - customer communication - analysis, design, review and modification 15-20% construction activities - coding or code generation 30-40% testing and installation -unit, integration - white-box, black box - regression
Working environment
A quiet working environment with private work areas contributes to improved productivity.
Technology support
Good support technology such configuration management systems, etc. can improve productivity.
Application domain experience
Knowledge of the application domain is essential for effective software development. Engineers who already understand a domain are likely to be the most productive.
reuse estimate when you must understand and integrate code
LOC * % generated * adaptation adjustment multiplier - 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.
Object point estimation
Object points are easier to estimate from a specification than function points as they are simply concerned with screens, reports and programming language modules. - can be estimated at a early point in the development process
Agile planning stages
Release planning: looks ahead for several months and decides on the features that should be included in a release of a system. Iteration planning: has a shorter term outlook, and focuses on planning the next increment of a system. Typically 2-4 weeks of work
Assumptions with Shortest Possible Schedule
Staffing (team has drawn from the top 10 percent of the talent pool) Management (assumes project has ideal management) Tool support (assumes advanced tools are available) Methodology (assumes using a time-efficient methodology) Note - there is a shortest possible schedule and you can't beat it
Three kinds of software products
Systems software - e.g. firmware, real-time embedded software, avionics, process control etc. Business software - e.g. payroll, inventory etc. Shrink-wrap software - e.g. software packaged and sold commercially like word processor
Assumptions with Efficient Schedule
Team has drawn from the top 25 percent of the talent pool Assumes project has ideal management Assumes advanced tools are available Also assumes using a time-efficient methodology
Assumptions with Nominal Schedule
Team has drawn from the top 50 percent of the talent pool Programming tools and modern programming practices are used to some extent
Specific Estimation Techniques: The COCOMO model
The COCOMO 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.
Process quality
The development process used can have a significant effect on productivity.
Project size
The larger a project, the more time required for team communications. Less time is available for development so individual productivity is reduced.
Post-architecture model.
Used once the system architecture has been designed and more information about the system is available.
Reuse model
Used to compute the effort of integrating reusable components. Takes into account black-box code that is reused without change and code that has to be adapted to integrate it with new code. - white box and black box
Early design model
Used when requirements are available but design has not yet started. - estimates can be made after requirements have been agreed
Application composition model
Used when software is composed from existing parts. • Supports prototyping projects and projects where there is extensive reuse. • Based on standard estimates of developer productivity in application (object) points/month.
post architecture level
Uses the same formula as the early design model but with 17 rather than 7 associated multipliers. • The code size is estimated as: - Number of lines of new code to be developed; - Estimate of equivalent number of lines of new code computed using the reuse model; - An estimate of the number of lines of code that have to be modified according to requirements changes.
Milestones
are points in the schedule against which you can assess progress, for example, the handover of the system for testing.
Deliverables
are work products that are delivered to the customer, e.g. a requirements document for the system.
estimation accuracy
predicted on the degree to which..: - proper estimate of size - size translated into human effort, calendar time, and dollars -if plan reflects the abilities of the software team - the stability of product requirements
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.
Black-box reuse
where code is not modified. An effort estimate (PM) is computed.
effort validation
—be sure resources are available
compartmentalization
—define distinct tasks
defined outcomes
—each task must have an output
interdependency
—indicate task interrelationship
defined responsibilities
—people must be assigned
defined milestones
—review for quality
Algorithmic cost modelling
• A formulaic approach based on historical cost information and which is generally based on the size of the software • Most commonly used product attribute for cost estimation is code size - Effort=AxSizeB xM - 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.
Software productivity
• 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.
Size estimation
• Algorithmic approach - such as function points, that estimates program size from program features • Use size-estimation software that estimates program size from your description of program features - screens, dialogs, files, database tables, etc. • If you have already worked on a similar project and know its size - Estimate each major piece of the new system as a % of the size of a similar piece of the old system. - Add up all the estimated sizes of the pieces
Quality and productivity
• 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;
Project duration and staffing
• As well as effort estimation, managers must estimate the calendar time required to complete a project and when staff will be required • The time required is independent of the number of people working on the project.
Estimation Tips
• Avoid off-the-cuff estimates • Allow time for the estimate, and plan it • Use data from previous projects • Use developer-based estimates • Estimate by walkthrough • Estimate by categories - e.g. easy, medium, hard • Estimate at a low level of detail • Don't omit common tasks • Use software estimation tools • Use several different estimation techniques, and compare the results • Change estimation practices as the project progresses
Function points
• Based 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 • The function point count is computed by multiplying each raw count by the weight and summing all values
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.
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 SizeB 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.
Estimation methods
• Each method has strengths and weaknesses. • Estimation should be based on several methods. • If these do not return approximately the same result, then you have insufficient information available to make an estimate. • Some action should be taken to find out more in order to make more accurate estimates. • Pricing to win is sometimes the only applicable method.
Experience-based approaches
• Experience-based techniques rely on judgments based on experience of past projects and the effort expended in these projects on software development activities. • Typically, you identify the deliverables to be produced in a project and the different software components or systems that are to be developed. • You document these in a spreadsheet, estimate them individually and compute the total effort required. • It usually helps to get a group of people involved in the effort estimation and to ask each member of the group to explain their estimate. • Process iterates until some consensus is reached.
Software cost components
• Hardware and software costs. • Travel and training costs. • Effort costs (the dominant factor in most projects) - engineer salaries, 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.).
Fundamental estimation questions
• How much effort is required to complete an activity? • How much calendar time is needed to complete an activity? • What is the total cost of an activity?
Example of Specific Estimation Techniques
• Parkinson's Law • Pricing to win • The COCOMO model(s) • Management options
Parkinson's Law
• Parkinson's Law states that work expands to fill the time available. The cost is determined by available resources rather than by objective assessment. • If the software has to be delivered in 12 months and 5 people are available, the effort required is estimated to be 60 person-months
Estimation Techniques
• Past (similar) project experience - task breakdown and effort estimates - size (e.g., FP) estimates • Empirical models • Automated tools
Multipliers
• Product attributes - Concerned with required characteristics of the software product being developed. • Computer attributes - Constraints imposed on the software by the hardware platform. • Personnel attributes - Multipliers that take the experience and capabilities of the people working on the project into account. • Project attributes - Concerned with the particular characteristics of the software development project.
Project Estimation
• Project scope must be understood • Elaboration (decomposition) is necessary • Historical metrics are very helpful • At least two different techniques should be used
Productivity estimates LOC
• 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.
Project scheduling activities
• Split 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.
Staffing requirements
• Staff required can't be computed by diving the development time by the required schedule. • The number of people working on a project varies depending on the phase of the project. • The more people who work on the project, the more total effort is usually required. • A very rapid build-up of people often correlates with schedule slippage.
Object points
• 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;
Pricing to win
• The project costs whatever the customer has to spend on it. • Advantages: - 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.
Pricing to win pros cons
• 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 development.
Function-Point Estimation
• This kind of size estimation is often used in a project's early stages • Based on counting - Inputs - screens, forms, dialog boxes, controls etc. - Outputs - screens, reports, graphs etc. - Inquiries - input/output combinations - Logical internal files - files controlled by the program - External interface files - files controlled by other programs
Why Are Projects Late?
• an unrealistic deadline • changing customer requirements • an honest underestimate • predictable and/or unpredictable risks • technical difficulties • human difficulties • miscommunication • a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem
Scheduling Principles
• compartmentalization • interdependency • effort validation • defined responsibilities • defined outcomes • defined milestones
Defining Task Sets
• determine type of project • assess the degree of rigor required • identify adaptation criteria • select appropriate software engineering tasks
Measurement problems
• size of the measure (e.g. how many function points). • total number of programmer months •contractor productivity (e.g. documentation team)
