Lecture 17 Estimation Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman. Software Engineering Fall 2005. Overview. Software planning involves estimating how much time, effort, money, and resources will be required to build a specific software system.
The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project.
So the end result gets done on time, with quality!
- Risk analysis,
- Quality management planning, and
- Change management planning.
1. Establish project scope
2. Determine feasibility
3. Analyze risks
4. Define required resources
5. Estimate cost and effort
- Decompose the problem;
- Develop two or more estimates using size, function points, process tasks or use-cases;
- Reconcile the estimates.
6. Develop a project schedule
- Establish a meaningful task set;
- Define a task network;
- Use scheduling tools to develop a timeline chart;
- Define schedule tracking mechanisms.
- the task to be performed,
- the functions to be implemented,
- and the cost, effort, and time involved for each.
Why is a feasibility assessment part of the planning process?
- Human Resources- number of people required and skills needed to complete the development project;
- Reusable Software Resources- off-the-shelf components, full-experience components, partial-experience components, new components;
- Environment Resources - hardware and software required to be accessible by software team during the development process.
For software categories:
S = (Sopt + 4Sm + Spess)/6 (23-1)
gives heaviest credence to the ‘most likely’ estimate.
Representative values developed by QSM (Quantitative Software Management)
The mechanical CAD software will accept two- and three-dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter.
Burdened labor rate of €8000 per month, the cost per line of code is approximately €13.
- the total estimated project cost is
€431,000 ( 33200 x 13)
- the estimated effort is
54 person-months (33200 / 620)
(S Fi = 52)
FP est = count_total * ( 0.65 + 0.01 * S Fi )
FP est = 318 * (0.65 + 0.01 * 52) = 372
Burdened labor rate = €8000 per month, the cost per FP is approximately €1230.
- the total estimated project cost is
€458,000 (FP est x 1230)
- the estimated effort is
57 person-months (FP est / 6.5)
Obtained from “process framework”
Effort required to accomplish
each framework activity for each application function
- the total estimated project cost is $368,000, and
- the estimated effort is 46 person-months.
- are described using many different formats and styles, there is no standard form;
- represent an external view (the user’s view) of the software and are often written at different level of abstraction;
- do not address the complexity of the functions and features are often written at different levels of abstraction;
- do not describe complex behaviour (e.g. interactions) that involves many functions and features.
For example: we may assume that one use-case corresponds to one FP.
LOC estimate = N x LOCavg + [(Sa/Sh -1) + (Pa/Ph -1)] x LOCadjust
N = actual number of use-cases
LOCavg = historical average LOC per use-case for this type of subsystem.
LOCadjust = represents an adjustment based on n percent of LOCavg where n is defined locally and represents the difference between this project and ‘average’ projects.
Sa = actual scenarios per use-case
Sh = average scenarios per use-case for this type of subsystem.
Pa = actual pages per use-case
Ph = average pages per use-case for this type of subsystem.
- User interface subsystem (includes UICF).
- Engineering subsystem group (includes 2DGA subsystem, SDGA subsystem, and DAM subsystem).
- Infrastructure subsystem group (includes CGDF subsystem and PCF subsystem).
User interface subsystem
Engineering subsystem group
Infrastructure subsystem group
e subsystem group
42,568Example 4: Use-Case Based Estimation
- the total estimated project cost is €552,000
- the estimated effort is 68 person-months.
Effort = A + B * (est_var) C
where A, B and C are constants and
est_var is either LOC or FP
PM = person-months
KDSI = thousand of delivered software instructions
1. Use the function point method to estimate lines of code
2. Use Boehm’s formulas to estimate labor required
3. Use the labor estimate and Boehm’s formula to estimate duration
Effort in Person-months = aKLOC b
Duration = c Effort d
Where c = labour estimate, d = complexity of project type
Software Project a b c d
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Hierarchy of three different models:
- Object points
- Function points
- Lines of source code
- medium, or
object points = screen x wf + report x wf + component x wf
NOP = (object points) x [(100 - %reuse)/100]
where NOP is defined as new object points.
PROD = NOP/person-month
estimated effort = NOP/PROD
Use the COCOMO II model to estimate the effort required to build software for a simple ATM that produces 12 screens, 10 reports, and will require approximately 80 software components. Assume average complexity and average developer/environment maturity. Use the application composition model with object points.
Using the weightings from Table 23.6 the unadjusted object points are:
object point = 12 * 2 + 10 * 5 + 80 * 10 = 874
If we assume 80% reuse
NOP = (object points) * [(100 - %reuse)/100]
= (874) * [(100 – 80)/100]
= 874 * 0.2 = 174.8
Using the weightings from Table 23.7 for nominal developer experience
PROD = 13
The estimated effort in person months is
estimated effort = NOP/PROD = 174.8 / 13 = 13.45
Lorenz and Kidd suggest the following approach:
1. Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications.
2. Using object-oriented analysis modeling, develop use-cases and determine a count.
3. From the analysis model, determine the number of key classes (called analysis classes).
Interface type Multiplier
No GUI 2.0
Text-based user interface 2.25
Complex GUI 3.0
Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes.
5. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.
6. Cross check the class-based estimate by multiplying the average number of work-units per use-case
1. Each user scenario (a mini-use-case) is considered separately for estimation purposes.
2. The scenario is decomposed into the set of software engineering tasks that will be required to develop it.
3. Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.”
4. Estimates for each task are summed to create an estimate for the scenario.
5. The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment.
Why is the "make-buy" decision and deciding whether or not to outsource software development an important part of the software planning process?
It maybe more cost effective to acquire a piece of software, rather than develop it. Similarly, deciding to outsource software development frees resources for other purposes (or reduces expenses) but it makes outsourcing can make it harder to control and manage delivery times and development costs.
A program allows students to add/remove courses to/from his/her schedule. Students can look up the database of courses to see when the course is scheduled.
The university administrator edits the database of courses: adds and removes the courses from the database.
Initial analysis of the problem has identified the use cases shown in Figure 1. Use function point analysis and Basic COCOMO, to estimate the effort and time required to develop this system using Java. Use provided tables. Weight all the use cases high with a weight of 7.
Look up course
Edit database of courses
Add course to database
Remove course from databaseBasic COCOMO Model: Example 2: Figure 1
FPadjusted = FP (0.65 + 0.01 Fi)
Inserting the total of 25, from table above, into the equation for FPadjusted gives
FPadjusted= 42 (0.65 + 0.01 25) = 42 0.9 = 37.8
Using Table 2, relating function points to lines of code, this then suggests 30 lines of OO code per function point, so that we would need to develop about 1323 lines of OO code to implement this system.
37.8 x 30 = 1134 rounded up gives 1100 LOC (1.1KLOC)
Viewing the scheduling system as an exceptionally simple organic system, take the parameters a,b from the basic COCOMO model in Table 3, to obtain Effort.
E = a x (KLOC)b
E = 2.4 x 1.11.05
E = 2.4 x 1.105 = 2.69 rounding up to 2.7, person-months.
The optimal duration is then found using parameters c, d for the Basic COCOMO model in the Table 3.
D = c x E d
D = 2.5 x 2.70.38 = 2.5 x 1.45 = 3.64
rounding up to 3.7, months.