planning and estimating

9.1/84

PLANNING

AND

ESTIMATING

9.2/84Prologue

• There is no easy solution to the difficultiesof constructing a SW product,

• A large product takes time and resources,

• Careful planning at the beginning of the project is perhaps the single most important factor that distinguishes success from failure,

• planning reach a peak after the specification phase ,

• The initial planning is by no means enough. Planning, like testing and documentation, must continue throughout the SW development and maintenance process.

9.3/84Overview

• Planning and the SW process,

• Cost & Duration Estimation,

• COCOMO,

• SW Project Management Plan,

• Planning of testing,

• Planning of object-oriented projects,

• Training requirements,

• Documentation standards,

• CASE tools for the planning phase,

• Testing during the planning phase ,

9.4/84



• COCOMO,




• Training requirements ,



• Testing during the planning phase.

9.5/84 Planning and the SW process

• The earliest possible detailed planning isafter the specification phase, because we do not have enough information available during the initial phases,

• And what if we have a prototype?

• There is a world of difference between the information at the end of the requirements phase,and at the end of the specification phase, Sketch VS blue print:

9.6/84



• COCOMO,






• CASE Tools for the Planning Phase,

• Testing during the Planning Phase.

9.7/84Estimation Accuracy VS Process Phase …

9.8/84Estimation Accuracy… (Cont'd)

• Examples based upon the previous figure for a finally cost 1M$ product:

Phase Estimation Min. Max.

During Req. 1M$ 0.25M$ 4M$

During Spec. 1M$ 0.5M$ 2M$

End Of Spec. 1M$ 0.67M$ 1.5M$, Conclusion: estimation is not an exact science ,

9.9/84Cost Estimation

• Yet, accurate cost estimation is critical,

• Underestimation might:cause us to loose money,

• Overestimate might:Cancel the project or,Make the client go elsewhere,

• Two type of cost estimation:– Internal – salaries, HW, SW, consultant…– External – the price presented to the customer,

• There are too many variables for accurate estimateof cost or duration ,

9.10/84The Human Factor …

• Matched pairs of programmers with same background, seniority, and same product size: The comparison measured:– Development time,– Coding time,– Debugging time,– Quality,

• Guess …

9.11/84The Human Factor (Cont’d)

• Differences of up to 1 to 28 between pairs of matched programmers!,

• Does it important in big teams?,

• And what about same programmer consistency?,

• Critical staff members may resign during the project ,

• Can we measure the turnover?

,

9.12/84Tracking Our Estimates

• Whatever estimation method used, careful tracking is vital,

• Assume that we predicted a top level-design phase of 3 month require 7 person-months effort. However 4 months have gone and 10 person-months effort have been expended – and we are only half way through…

• We must re-consider our preliminary estimation! ,

9.13/84Metrics for the Size of a Product

(I) LOC & KDSI

• The most obvious: Code size,

• LOC – Lines of Code ,

• KDSI – Thousand Delivered Source Instructions.

9.14/84Problems With LOC and KDSI …

• LOC is known when the product finished,

• Source code is only a small part of the total SW effort, what about planning, designing etc.,

• Different languages lead to different lengths of code ,

• It is not clear how to count lines of code:– Executable lines of code?– Data definitions? – Comments? – JCL statements? – Changed / deleted lines?– What if we reuse code?

9.15/84Problems With LOC and KDSI (Cont'd)

• LOC is not defined for nonprocedural languages (LISP),

• Not everything written is delivered to the client,(e.g. code for testing..),

• What if we use code generator? ,

• Estimation based on LOC is doubly dangerous: – To start the estimation process, LOC in the finished

product must be estimated,– The LOC estimate is then used to estimate the cost of

the product — an uncertain input to an uncertain cost estimator.

9.16/84Metrics (Cont’d)

(II) ‘SW Science Metric’:

• Metrics based on the number of operands and operators ,

• Limited predictive power — metrics can be computed only after the product has been implemented.

9.17/84Metrics – Function Points …

(III) – FP

• We look for measurable quantities that can be determined early in SW life cycle,

• Three steps process:1. UFP

• Based on the number of inputs (Inp), outputs (Out), inquiries (Inq), master files (Maf), interfaces (Inf),

9.18/84Metrics – FP (Cont'd) …


2.TCF

• Compute the Technical Complexity Factor (TCF):

• Assign a value from 0 (“not present”) to 5 (“strong influence”) to each of 14 factors:

• Sum these numbers DI Degree of Influence [0, 70],

• TCF = 0.65 + 0.01 DI ,

• TCF is [0.65, 1.35].

,

9.21/84Metrics – FP (Cont'd)

3.

• The number of Function Points (FP) is given by

FP = UFP TCF

9.22/84Analysis of FP

• Function points are usually better than KDSI— but there are some problems,

• “Errors in excess of 800% counting KDSI, but only 200% in counting function points” [Jones, 1987],a most revealing remark… ,

• What about maintenance? It can be inaccurately measured.

9.23/84FP VS KDSI Comparison

• KDSI/Month: ASM KDSI > Ada KDSI? (in 60%!!),

Same product was developed in Assembler and Ada:

KDSI: It is cheaper to code in ASM? ,

FP: More sensible results!

Actual

Data

Pre –

Estimate

9.24/84More Size Estimation Methods

(IV) Mk II Function Points

• Aimed to compute UFP more accurately,

• Decompose SW into component transactions, each consisting of input, process, and output,

(V) Feature Points

• Aimed for SW with algorithm major role: real-time embedded, communications, etc.,

• Maf - Master Files , Alg - Algorithms

• Feature Points = FP – 3 * Maf + 3 * Alg,

(VI) Boeing 3D Function Points

• Aimed for scientific and real-time SW.

9.25/84Duration Estimation

• Accurate duration estimation is critical! (Time to Market, occupation for employees),

• In order to estimate the size and the duration of a SW project, above its size, we must consider:

• Personnel skill level (1:28)…,

• Project complexity,

• Development team familiarity with application area,

• The target HW,

• Availability of CASE tools,

• The deadline effect ,

9.26/841. Expert Judgment by Analogy

• Experts compare target product to completed products: – Would give the most accurate budget because several

experts can estimate, compare and discuss the project cost. The estimation process iterates until an agreed estimate is reached. Therefore, the experience driven costing would give a more realistic budget,

– Guesses can lead to hopelessly incorrect cost estimates, – Experts may recollect completed products inaccurately,– Human experts have biases ,

9.27/842. Bottom-up approach

• Break the product into smaller components,

• Estimate each part separately,

• Advantages:– Faster and more accurate – per part,

• Disadvantages:– The smaller components may be no easier to estimate,– The product is more than the sum of its components ,

9.28/843. Algorithmic models

• A model is built from historical cost information that relates SW metric (usually it's size) to the project cost,

• The model gets new SW estimated metrics and predicts the effort required,

• An algorithmic model is unbiased, and superior to expert opinion,

• However, estimates are only as good as the underlying assumptions ,

• Examples:– RCA Price S Model,– COnstructive COst MOdel (COCOMO).

9.29/84



• COCOMO








9.30/84COCOMO …

• COCOMO was put together in 1981,

• COCOMO consists of three models:Macro-estimation model for the product as a whole,Intermediate COCOMO,Micro-estimation model which treats the product in detail ,

• We examine intermediate COCOMO.

9.31/84Intermediate COCOMO …

1.Estimate the length of the product in KDSI ,

2.Estimate the product development mode:Organic Or Semidetached Or Embedded

Organic (Small and straightforward) project that is routine for a company. It is in a well understood domain of application, or it is being done by a team that works well together. A project of this type will run smoothly, few hitches anticipated. This is the "easy" end.

9.32/84Intermediate COCOMO (Cont'd) …

2.Product development mode (Cont’d):

Semidetached (medium-sized), The middle of the difficulty spectrum. Projects here are somewhat complex but something the company has experience dealing with. The overall project is not massive or huge, nor is it simple and compact.

Embedded (complex), A project that will be difficult for a company. Perhaps it is in a domain of application that is fully novel (in 1965, build a software system to control a rocket that will fly men to the moon and back), or perhaps it is an area in which the company has little experience.


• 3. Set a & b parameters value:

4. Compute Nominal Effort = a (KDSI)b person-months ,

There are 5th and 6th steps, but first, an example.


• Example:

• Est. 12,000 delivered source statements (12 KDSI),

• Straightforward product (“organic mode”),

• Nominal Effort = 3.2 (KDSI)1.05 person-months,

• Thus Nominal Effort = 3.2 (12)1.05 = 43 person-months ,

• 12,000 / 43 = 279 LOC per month!


• 5. Set 15 SW development cost multipliers:

9.36/84Intermediate COCOMO (Cont'd)

• Example: Product complexity multiplier – Very low: [0.7] if-then-else, do-while, case, etc.,– Low: [0.85] nested if-then-else etc.,– Nominal: [1.0] intermodule control & decision tables, etc.,– High: [1.15] operators are highly nested, compound

predicates, queues, stacks, etc.,– Very high: [1.30] reentrant, recursive coding, etc.,– Extra high: [1.65] multiple resource scheduling with

dynamically changing priorities, etc. ,

• 6. Multiply the Nominal Effort by each of the selected 15 multipliers,This can lead to 0.088 to 72.3 variance!

9.37/84Intermediate COCOMO – Example …

• Example: μP-based communications processing SW for electronic funds transfer network with high reliability, performance, development schedule, and interface requirements,

• 1. Estimate: 10,000 delivered source instructions,

• 2. Complex (“embedded”) mode,

• 3. a=2.8, b=1.2,

• 4. Nominal effort = 2.8 (10)1.20 = 44 person-months ,

• 5. Set 15 SW development cost multipliers.(next slide).

9.38/84Inter. COCOMO – Example (Cont'd)


• 6. Product of effort multipliers = 1.35,So estimated effort for project is 1.35 44 = 59 person-months ,

• Estimated effort for project (59 person-months) is used as input for additional formulas for:– Dollar costs,– Development schedules,– Phase and activity distributions,– Computer costs,– Annual maintenance costs,– Related items.

9.40/84Intermediate COCOMO (Cont'd)

• Intermediate COCOMO has been validated with respect to a broad sample,

• Actual values are within 20% of predicted values about 68% of the time ,

• Intermediate COCOMO was most accurate estimation method of its time.

9.41/84COCOMO II

• 1995 extension to 1981 COCOMO that incorporates:– Object orientation,– Modern life-cycle models,– Rapid prototyping,– Fourth-generation languages,– COTS SW ,

• COCOMO II is far more complex than the first version…

9.42/84



• COCOMO,








9.43/84SW Project Management Plan (SPMP)

• The SPMP should define:

The work to be done,

The resources with which to do it,

The money to pay for it ,

The development process.

9.44/84Work Categories

• Project function:– Work carried on throughout project,– Examples: project management, quality control, etc.,

• Activity:– Work that relates to a specific phase,– A major unit of work, – With precise beginning and ending dates,– That consumes resources, and– Results in work products like the budget, design, schedules,

source code, or users’ manual ,

• Task:– The smallest unit of work subject to management

accountability.(An activity comprises a set of tasks).

9.45/84Completion of Work Products

• Milestone: date on which the work product is to be completed,

• It must first pass reviews performed by: – Fellow team members,– Management,– Client,

• Once the work product has been reviewed and agreed upon, it becomes a baseline,

Millstone…

9.46/84Work Package

• Work product, plus:

Predecessors,

Staffing requirements,

Estimated Duration,

Resources,

Name of responsible individual,

Acceptance criteria for work product ,

Successors.

9.47/84Resources

• Resources needed for SW development:

People – developers,

Hardware – development environment and target ,

Support SW – OS, CASE, etc.

9.48/84Use of Resources Varies With Time

• Rayleigh curves accurately depict resource consumption,

• Entire SW development plan must be a function of time ,

,2

2

22

kt

c ek

tR

9.49/84Resources Requirement and Allocation

• We need three senior programmers with at least 5 years of experience,

Three senior programmers with at least 5 years of experience in real-time programming are needed, two to start three months after the project commences, the third to start six months after that. Two will be phase out when the product testing starts, the third when maintenance begins ,

As a matter of fact, all resourced are time dependents.

,

9.50/84Money

• A vital component of the plan,

• The detailed budget must be worked out as a function of time ,

• Money must be allocated, as a function of time, to project functions & activities.

9.51/84How to Plan SW Development

• State problem clearly (specification phase),

• Determine viable solution strategies (specification phase),

• Should client be advised to computerize?– Cost–benefit analysis ,

• If so, which viable solution strategy?Decide by:– Minimizing total cost to client, or.– Maximizing total return on investments, or.– Other methods.

9.52/84SPMP (Cont’d) …

• Determine work units,

• Estimate resources required,

• Draw up budget,

• Come up with detailed timetable ,

• Develop SPMP for the product as whole.

9.53/84Framework for SPMP …

• IEEE standard 1058.1:

Advantages of standardization,

Standard widely agreed upon,Designed for use with all types of SW product,

It is a framework that can be used irrespective of process model or specific techniques ,

It can be tailored for each organization for a particular application area, development team or technique.

9.54/84IEEE SPMP (1058.1) …


1. Introduction: – 1.1 Project Overview, (millstones, schedule, budget)– 1.2 Project Deliverables, – 1.3 Evolution of the Software Project Management

Plan,mechanism for plan updating,

– 1.4 Reference Materials, (Standards etc.)– 1.5 Definitions and Acronyms ,

2. Project Organization: – 2.1 Process Model,– 2.2 Organizational Structure,– 2.3 Organizational Boundaries and Interfaces,– 2.4 Project Responsibilities (for each function).


3. Managerial Process: – 3.1 Management Objectives and Priorities,

Philosophy, goals, & management priorities,– 3.2 Assumptions, Dependencies, and Constraints,– 3.3 Risk Management,– 3.4 Monitoring and Controlling Mechanisms,

(including review and audit mechanisms),– 3.5 Staffing Plan ,

4. Technical Process: – 4.1 Methods, Tools, and Techniques,

(Standards implementation),– 4.2 Software Documentation,– 4.3 Project Support Functions (Such as CM, QA etc.).

9.57/84SPMP (Cont’d)

5. Work Packages, Schedule, and Budget:5.1 Work Packages,

Described in activities and tasks level,

5.2 Dependencies,

5.3 Resource Requirements,As a function of time,

5.4 Budget and Resource Allocation,

5.5 Schedule, (Detailed schedule),

6. Additional Components,

7. Index ,

8. Appendices.

9.58/84



• COCOMO,








9.59/84Planning of Testing …

• The SPMP must explicitly state what testing is to be done – for each phase ,

• Traceability: It must be possible to connect each statement in the specification document to a part of the design, and each part of the design must be explicitly reflected in the code.The statements in the specification document should be numbered to ensure that these numbers are reflected in both the design and the code.

9.60/84Planning of Testing (Cont’d)

• Faults documentation: Measuring current project quality (versus previous projects, other groups other customer etc.),Serving as a warning to the next phases ,

• Black box test cases: These test cases must be drawn up as soon as possible after specifications are complete, and later than can be executed by the SQA team.Other test cases will be part of the later phases.

9.61/84



• COCOMO,








9.62/84Planning of OOD Projects …

• In a Structured-Oriented project, the product is generally one large unit,

• Object-oriented product consists of largely independent pieces,

• Planning is somewhat easier,

• Early estimation tools (FP, intermediate COCOMO), can work well, assuming no reuse ,

• COCOMO II support OOP and reuse.

9.63/84Planning of OOD Projects (Cont'd)

• However, reuse enters the estimation in two ways:– Reuse of existing components during development,– Production of components for future reuse,

• It might take about as three times as long, to design, implement, test and document a reusable component compared to a non reusable component!,

• Newer data: savings outweigh costs,

• These work in opposite directions ,

9.64/84



• COCOMO,








9.65/84Training Requirements …

• “We don’t need to worry about training until the product is finished, and then we can train the user”,

• What abut training the development team?,

• Training is generally needed by the members of the development group, starting with training in SW planning,

• A new SW development method necessitates training for every member of the group ,

• Introduction of new hardware or SW tools of any sort necessitates training.

9.66/84Training Requirements (Cont’d) …

• Programmers may need training in the OS and/or implementation language,

• Documentation preparation training may be needed ,

• Computer operators require training.

9.67/84Training Requirements (Cont’d)

• The required training cab be obtained in a number of ways:

• In-house training,– By fellow employees,– By consultants,– A ‘private coach’ – buddy,– Self-instruction Video-tapes,– OTJ – On The Job training.

• External courses:– College’ courses ,

• Training plan should be incorporated into the SPMP.

9.68/84



• COCOMO,








9.69/84Documentation Standards …

• How much documentation is generated throughout a product development process?

• IBM internal commercial product (50 KDSI)– 28 pages of documentation per KDSI,

• Commercial SW product of same size– 66 pages per KDSI,

• IMS/360 Version 2.3 (about 166 KDSI)– 157 pages of documentation per KDSI, (26,062 pages..) ,

• For every 100 hours spent on coding activities, 150–200 hours were spent on documentation-related activities.

9.70/84Types of Documentation …

• Planning,

• Control,

• Financial,

• Technical,

• Source code,

• Comments within source code ,

• Users’ manuals.

9.71/84Documentation Standards (Cont’d)

• Standard documentation:

• Defined in the SPMP (sections 1.4 and 4.1),

• Reduce misunderstandings between team members,

• Aid SQA,

• Only new employees have to learn standards, (training – again),

• Standards assist maintenance programmers,

• Standardization is important for user manuals ,

• In a very real sense the product is the the documentation, because without documentation the product cannot be maintained.

9.72/84



• COCOMO,








9.73/84CASE Tools for the Planning Phase …

• Word processor,

• Spreadsheet: Excel, Lotus 1-2-3,

• Automated intermediate COCOMO/COCOMO II,

• Management tools assist with planning and monitoring: MacProject, MS Project ,

• Tools for schedule planning, managing and tracking.

9.74/84Planning Phase Tools (Cont’d) …

• Several thousands of activities have to be performed in the course of building a product.

• Some activities have precede others (a module cannot be coded until it has been designed). Other activities can be carried in parallel (implementation of the various modules can be assigned to different teams),

• CPM – Critical Path Management,

• PERT – Program Evaluation Review Techniques.


• Critical activity,

• Example:Suppose that two activities are started at the same time, and can be performed in parallel, but both both have to be completed before proceeding with the project as a whole.If the firs takes 12 days, whereas the second needs only 3 days, then the first activity is critical ,

Any delay in the first activity will cause the project as whole to be delayed.


Activity_1/12 Days

Activity_2/3 Days

Start

First Milestone

End

Second Milestone


• The second activity can be delayed up to 9 days without adversely impacting the project,

• There is a slack of 9 days associated with the second activity,

• Using PERT/CPM the manager inputs the activities, their estimated durations, and any precedence relations,

• The PERT will determine which activities are critical, and will compute the slack for any non-critical activity ,

• PERT will find the critical path as well.


A

B

C

D

E

F

G

H

J

6

4

2

3

25

16

4

7 11

3

5

What is the critical path?


A

B

C

D

E

F

G

H

J

6

4

17

3

25

16

4

7 11

3

5

After 17 days: Activity AD is delayed in 15 days.

What is the critical path now?

9.80/84Planning Phase Tools (Cont’d)

• Simply printing a PERT chart showing the expected duration of each activity is in itself of little use,

• The actual effort is tracked and compared to predictions during the development process. The most important factor to consider is to detect deviations early and to take immediate corrective action,

• Data regarding actual durations must be input continually, and the PERT chart updated ,

• Who is responsible for the continual update of the PERT data?– We need integrated environment,– Program manager.

9.81/84



• COCOMO,








9.82/84Testing during the Planning Phase

• A fault in the SPMP can have serious financial implications for the developers,

• We must check the SPMP as a whole,

• The entire SPMP must be checked by the SQA group before estimates are given to the client ,

• Paying particular attention to the duration and cost estimates.

9.83/84Summary



• COCOMO,







• Testing during the planning phase.

9.84/84

PLANNING

AND

ESTIMATING.

The End

planning and estimating

Documents