PLANNING AND ESTIMATING Planning and Estimating l Before

PLANNING AND ESTIMATING

Planning and Estimating l Before starting to build software, it is essential to plan the entire development effort in detail l Planning continues during development and then postdelivery maintenance ¡ Initial planning is not enough ¡ Planning must proceed throughout the project ¡ The earliest possible time that detailed planning can take place is after the specifications are complete

Planning and the Software Process l The accuracy of estimation increases as the process proceeds

Planning and the Software Process l Example ¡ Cost estimate of $1 million during the requirements workflow l Likely actual cost is in the range ($0. 25 M, $4 M) ¡ Cost estimate of $1 million at the end of the requirements workflow l Likely actual cost is in the range ($0. 5 M, $2 M) ¡ Cost estimate of $1 million at the end of the analysis workflow (earliest appropriate time) l Likely actual cost is in the range ($0. 67 M, $1. 5 M) ¡ Estimate is closer to the actual cost at a later stage

Planning and the Software Process l These four points are shown in the cone of uncertainty Figure 9. 2

Estimating Duration and Cost l Accurate duration estimation is critical ¡ l Accurate cost estimation is critical ¡ ¡ ¡ l You must tell your client when the software will be delivered Internal, external costs Internal cost – the cost to the developers External cost – price paid by the client There are too many variables for accurate estimate of cost or duration ¡ Many are factors related to the staff, such as experiences, skills, leaving the company etc

Metrics for the Size of a Product l Lines of code (LOC, KDSI, KLOC) l FFP l Function Points l COCOMO l If you can estimate the size of a product then hopefully you can estimate the cost as well as the duration!!!!!!

Lines of Code (LOC) l Alternate metric ¡ Thousand l Source delivered source instructions (KDSI) code is only a small part of the total software effort l Different languages lead to different lengths of code (for example writing in assembly language certainly will produce more LOC then writing in C++ )

Lines of Code (contd) l It is not clear how to count lines of code ¡ Executable lines of code? ¡ Data definitions? ¡ Comments? ¡ Changed/deleted lines? l Not everything written is delivered to the client l A report, screen, or GUI generator can generate thousands of lines of code in minutes (such as the Windows Form )

Lines of Code l LOC is accurately known only when the product finished l 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 ¡ Using LOC to estimate the cost is not reliable

Metrics for the Size of a Product l Metrics based on measurable quantities that can be determined early in the software life cycle ¡ FFP ¡ Function points l Measurable of file etc quantities – size of data, size

FFP Metric l For cost estimation of medium-scale data processing products l The three basic structural elements of data processing products ¡ Files – a collection of logically related records permanently resident in the product ¡ Flows – a data interface between the product and the environment (a report, a GUI) ¡ Processes – functionally defined logical or arithmetic manipulation of data (eg sorting, updating etc)

FFP Metric (contd) l Given the number of files (Fi), flows (Fl), and processes (Pr) ¡ The size (S), cost (C) are given by S C l The = = Fi + Fl + Pr b S constant b (efficiency or productivity) varies from organization to organization

Function Points l Based on the number of inputs (Inp), outputs (Out), inquiries (Inq), master files (Maf), interfaces (Inf) l For any product, the size in “function points” is given by FP = 4 Inp + 5 Out + 4 Inq + 10 Maf + 7 Inf l This is an oversimplification of a 3 -step process

Function Point l Input – user or control data element entering an application l Output – user or control data element leaving an application l Logical master file – an internal file or a data store acted on by the user l Interface file – a file that is used by another application or an external file l Query – an input-output combination (an input that results in an immediate output)

Function Points (contd) l Step 1. Classify each component of the product (Inp, Out, Inq, Maf, Inf) as simple, average, or complex ¡ Assign the appropriate number of function points ¡ The sum gives UFP (unadjusted function points) The about means the average input item has 4 FPs Adding all the function points will give the UFP (unadjusted function points)

Function Points (contd) l Step 2. Compute the technical complexity factor (TCF) ¡ Assign a value from 0 (“not present”) to 5 (“strong influence throughout”) to each of 14 factors such as transaction rates, portability Figure 9. 4

Function Points (contd) l Add the 14 numbers ¡ This gives the total degree of influence (DI) TCF = 0. 65 + 0. 01 DI l Maximum value of DI = 5 x 14 = 70 l The technical complexity factor (TCF) lies between 0. 65 and 1. 35 (=0. 65+70*0. 01)

Function Points (contd) l Step 3. The number of function points (FP) is then given by FP = UFP TCF

Analysis of Function Points l Function points are usually better than KDSI — but there are some problems l “Errors in excess of 800% counting KDSI, but only 200% in counting function points” [Jones, 1987]

Analysis of Function Points l We obtain nonsensical(無意義的) results from metrics ¡ KDSI person month and ¡ Cost per source statement Figure 9. 5 l Cost per function point is meaningful

Analysis of Function Points l Like FFP, maintenance can be inaccurately measured l It is possible to make major changes without changing ¡ The number of files, flows, and processes; or ¡ The number of inputs, outputs, inquiries, master files, and interfaces l In theory, it is possible to change every line of code without changing the number of lines of code

Techniques of Cost Estimation l Expert judgment by analogy l Bottom-up approach l Algorithmic cost estimation models

Expert Judgment by Analogy Experts compare the target product to completed products ¡ Guesses can lead to hopelessly incorrect cost estimates ¡ Experts may recollect completed products inaccurately ¡ Human experts have biases ¡ However, the results of estimation by a broad group of experts may be accurate l Experts should consider other experts’ estimates in order to produce a consensus l

Bottom-up Approach Break the product into smaller components and estimate the smaller items; l However, l ¡ ¡ l The smaller components may be no easier to estimate There are process-level costs – putting the smaller components together requires additional efforts When using the object-oriented paradigm ¡ ¡ The independence of the classes make estimate easier to perform However, the interactions among the classes complicate the estimation process

Algorithmic Cost Estimation Models A metric (such as Functional Point) is used as an input to a model to compute cost and duration ¡ An algorithmic model is unbiased, and therefore superior to expert opinion ¡ However, estimates are only as good as the underlying assumptions (eg FP is based on assumption of quantities such as input item, output item etc) l Examples ¡ COnstructive COst MOdel (COCOMO) l

9. 2. 3 Intermediate COCOMO l COCOMO consists of three models ¡A macro-estimation model for the product as a whole ¡ Intermediate COCOMO ¡ A micro-estimation model that treats the product in detail l We study the intermediate COCOMO

Intermediate COCOMO (contd) Step 1. Estimate the length of the product in KDSI Step 2. Estimate the product development mode (organic, semidetached, embedded) ¡ Development mode is a measure of level of difficulty of developing the product ¡ Organic – small and straightforward ¡ Semidetached – medium size ¡ Embedded – complex l Example: ¡ Straightforward product (“organic mode”) Nominal effort = 3. 2 (KDSI)1. 05 person-months The above equation will estimate the duration of the project l l

Intermediate COCOMO (contd) Step 3. Compute the nominal effort General equation for COCOMO model ¡ a x (KDSI) b ¡ a = 2. 4 (organic) 3. 0 (medium) 3. 6 (complex) ¡ b = 1. 05 (organic) 1. 12 (medium) 1. 20 (complex) l Example: ¡ Organic product ¡ 12, 000 delivered source statements (12 KDSI) (estimated) Nominal effort = 2. 4 x (12)1. 05 = 32. 6 person-month Development time can also be estimated by D = C x (nominal effort) d c = 2. 5 for all cases d = 0. 38 (organic) 0. 35 (medium) 0. 32 (embedded) The number of people required = E / D l l

Intermediate COCOMO (contd) l Step 4. Multiply the nominal value by 15 software development cost multipliers Figure 9. 6

Intermediate COCOMO (contd) l Example: ¡ Microprocessor-based communications processing software for electronic funds transfer network with high reliability, performance, development schedule, and interface requirements l Step 1. Estimate the length of the product ¡ 10, 000 delivered source instructions (10 KDSI) l Step 2. Estimate the product development mode ¡ Complex (“embedded”) mode

Intermediate COCOMO (contd) l Step 3. Compute the nominal effort ¡ Nominal effort = 2. 8 (10)1. 20 = 44 personmonths l Step 4. Multiply the nominal value by 15 software development cost multipliers ¡ Product of effort multipliers = 1. 35 (see table on next slide) ¡ Estimated effort for project is therefore 1. 35 44 = 59 person-months ¡ 1. 35 is the product of the 15 cost multipliers

Intermediate COCOMO (contd) l Software development effort multipliers Figure 9. 7

Intermediate COCOMO (contd) l Estimated effort for project (59 personmonths) is used as input for additional formulas for ¡ Dollar costs ¡ Development schedules ¡ Phase and activity distributions ¡ Computer costs ¡ Annual maintenance costs ¡ Related items

Intermediate COCOMO (contd) l Intermediate COCOMO has been validated with respect to a broad sample l Actual values are within 20% of predicted values about 68% of the time ¡ Intermediate COCOMO was the most accurate estimation method of its time l Major ¡ If problem the estimate of the number of lines of codes of the target product is incorrect, then everything is incorrect

9. 2. 4 COCOMO II l 1995 extension to 1981 COCOMO that incorporates ¡ Object orientation ¡ Modern life-cycle models ¡ Rapid prototyping ¡ Fourth-generation languages ¡ COTS software l COCOMO II is far more complex than the first version

COCOMO II (contd) l There are three different models ¡ Application composition model for the early phases l Based on feature points (similar to function points) ¡ Early l design model Based on function points ¡ Post-architecture l model Based on function points or KDSI

COCOMO II (contd) l The underlying COCOMO effort model is effort = a ×(size)b ¡ Intermediate COCOMO l l ¡ COCOMO II l l l Three values for (a, b) 1. 05 (organic) 1. 12 (semidetached) 1. 20 (embedded) b varies depending on the values of certain parameters b varies between 1. 01 and 1. 26 COCOMO II supports reuse

COCOMO II (contd) l COCOMO drivers ¡ Seven l It II has 17 multiplicative cost (was 15) are new is too soon for results regarding ¡ The accuracy of COCOMO II ¡ The extent of improvement (if any) over Intermediate COCOMO

PERT chart PERT – program evaluation and review technique l PERT is a model for project management designed to analyze and represent the tasks involved in completing a given project l PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. l

PERT chart Terminology A PERT event: is a point that marks the start or completion of one or more tasks. It consumes no time, and uses no resources. It marks the completion of one or more tasks, and is not “reached” until all of the activities leading to that event have been completed. l A predecessor event: an event (or events) that immediately precedes some other event without any other events intervening. It may be the consequence of more than one activity. l

PERT Chart A successor event: an event (or events) that immediately follows some other event without any other events intervening. It may be the consequence of more than one activity. l A PERT activity: is the actual performance of a task. It consumes time, it requires resources (such as labour, materials, space, machinery), and it can be understood as representing the time, effort, and resources required to move from one event to another. A PERT activity cannot be completed until the event preceding it has occurred. l

PERT terminology Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected l Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes). l Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal. l Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time). • TE = (O + 4 M + P) ÷ 6 l

PERT Terminology Critical Path: the longest possible continuous pathway taken from the initial event to the terminal event. It determines the total calendar time required for the project; and, therefore, any time delays along the critical path will delay the reaching of the terminal event by at least the same amount. l Critical Activity: An activity that has total float equal to zero. Activity with zero float does not mean it is on critical path. l Lead time : the time by which a predecessor event must be completed in order to allow sufficient time for the activities that must elapse before a specific PERT event is reached to be completed. l

PERT Terminology l Lag time: the earliest time by which a successor event can follow a specific PERT event. l Slack: the slack of an event is a measure of the excess time and resources available in achieving this event. Positive slack(+) would indicate ahead of schedule; negative slack would indicate behind schedule; and zero slack would indicate on schedule.

Implementing PERT The first step to scheduling the project is to determine the tasks that the project requires and the order in which they must be completed. The order may be easy to record for some tasks (e. g. When building a house, the land must be graded before the foundation can be laid) while difficult for others (There are two areas that need to be graded, but there are only enough bulldozers to do one). l Additionally, the time estimates usually reflect the normal, non -rushed time. Many times, the time required to execute the task can be reduced for an additional cost or a reduction in the quality. l

Example Activity Predecessor Time estimates Expected Pess. (p) time Opt. (a) Normal (m) A 2 4 6 4 B 3 5 9 5. 33 C A 4 5 7 5. 17 D A 4 6 10 6. 33 E B, C 4 5 7 5. 17 F D 3 4 8 4. 5 G E 3 5 8 5. 17

PERT chart D F A G C start B E End

Network diagram l l l A network diagram starts with a node “start” The “Start” node has a duration of zero Then you draw each activity that does not have a predecessor activity and connect them with an arrow from start to each node (a, b). Next, since both c and d list a as a predecessor activity, their nodes are drawn with arrows coming from a. Activity e is listed with b and c as predecessor activities, so node e is drawn with arrows coming from both b and c, signifying that e cannot begin until both b and c have been completed. Activity f has d as a predecessor activity, so an arrow is drawn connecting the activities. Likewise, an arrow is drawn from e to g. Since there are no activities that come after f or g, it is recommended (but again not required) to connect them to a node labeled finish.

Network diagram The activity name The normal duration time The early start time (ES) The early finish time (EF) The late start time (LS) The late finish time (LF) The slack

Network diagram In order to determine this information it is assumed that the activities and normal duration times are given. The first step is to determine the ES and EF. The ES is defined as the maximum EF of all predecessor activities, unless the activity in question is the first activity, for which the ES is zero (0). The EF is the ES plus the task duration (EF = ES + duration). l The ES of the “End” is the expected duration of the project l

Network diagram l To determine the LF, needs to move backward l The LF is defined as the minimum LS of all successor activities, unless the activity is the last activity, for which the LF equals the EF. The LS is the LF minus the task duration (LS = LF - duration).

Critical path l l l The critical path is the path that takes the longest to complete. To determine the path times, add the task durations for all available paths. Activities that have slack can be delayed without changing the overall time of the project. Slack is computed in one of two ways, slack = LF - EF or slack = LS - ES. Activities that are on the critical path have a slack of zero (0). In the example, critical path is ACEG Activities not included in the critical path can be delayed without affecting the duration of the project

Network diagram

Activities that have a slack l Activity b has an LF of 9. 17 and an EF of 5. 33, so the slack is 3. 84 work days. l Activity d has an LF of 15. 01 and an EF of 10. 33, so the slack is 4. 68 work days. l Activity f has an LF of 19. 51 and an EF of 14. 83, so the slack is 4. 68 work days.

Gantt chart l. A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project.

Gantt Chart

Exercise Identify the critical path l Determine the earliest completion time l Is it possible to reduce the duration of the project by reducing the duration of activity C l

Exercise Activity Duration (weeks) precedence A B C 2 3 3 A B D E F G H I J 7 6 2 5 4 8 2 B B C, D D, E F, G H H, I

9. 3 Components of a Software Project Management Plan l The planning of the execution of the project must be proper documented in the project management plane. l Items included in the plan ¡ The work to be done ¡ The resources with which to do it ¡ The money to pay for it

Resources l Resources needed for software development: ¡ People ¡ Hardware ¡ Support software

Use of Resources Varies with Time Rayleigh curves accurately depict resource consumption l According to the curve, sufficient resources must be available to cope with the consumption l Figure 9. 8

Work Categories There are two types of “work to be done” l Project function ¡ Work carried on throughout the project ¡ Examples: l Project management l Quality control l 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 l

Work Categories (contd) l Task ¡ An activity comprises a set of tasks (the smallest unit of work subject to management accountability)

Completion of Work Products l Milestone: The date on which the work product is to be completed l It must first pass reviews performed by ¡ Fellow team members ¡ Management ¡ The client l Once the work product has been reviewed and agreed upon, it becomes a baseline

Work Package l Work product, plus ¡ Staffing requirements ¡ Duration ¡ Resources ¡ The name of the responsible individual ¡ Acceptance criteria for the work product ¡ The detailed budget as a function of time, allocated to Project functions l Activities l

Software Project Management Plan Framework l There are many ways to construct an SPMP l One of the best is IEEE Standard 1058. 1 ¡ The standard is widely accepted ¡ It is designed for use with all types of software products ¡ It supports process improvement l Many sections reflect CMM key process areas ¡ It is ideal for the Unified Process l There are sections for requirements control and risk management

Software Project Management Plan Framework (contd) l Some of the sections are inapplicable to small-scale software ¡ Example: Subcontractor management plan

9. 5 IEEE Software Project Management Plan Figure 9. 9

Documentation Standards l How much documentation is generated by a product? ¡ IBM internal commercial product (50 KDSI) l 28 pages of documentation per KDSI ¡ Commercial software product of the same size l 66 pages per KDSI ¡ IMS/360 Version 2. 3 (about 166 KDSI) l 157 pages of documentation per KDSI ¡ [TRW] For every 100 hours spent on coding activities, 150– 200 hours were spent on documentation-related activities

Types of Documentation l Planning l Control l Financial l Technical l Source code l Comments within source code

Documentation Standards l Reduce misunderstandings between team members l Aid SQA l Only new employees have to learn the standards l Standards assist maintenance programmers l Standardization is important for user manuals

Documentation Standards (contd) l As part of the planning process ¡ Standards l In must be set up for all documentation a very real sense, the product is the documentation l There is the ANSI/IEEE Standard for software test documentation l IEEE standard 1063 for software user documentation