Slide 15.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach

Slide 15.2 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 15 PLANNING AND ESTIMATING

Slide 15.3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l Planning and the Information System Life Cycle l Estimating Duration and Cost l Components of a Project Management Plan l Project Management Plan Framework l IEEE Project Management Plan Framework l Project Management Plan: Osbert Oglesby Case Study l Planning of Testing

Slide 15.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview (contd) l Training Requirements l Documentation Standards l CASE Tools for Planning and Estimating l Testing the Project Management Plan

Slide 15.5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning l There are two types of planning –Planning, like testing, must continue throughout the development and maintenance life cycle –After the specification document has been drawn up, duration and cost estimates are computed and a detailed plan is produced

Slide 15.6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning and the Information System Life Cycle l Ideally, the plan for the entire information system project would be drawn up at the very beginning of the life cycle l This is impossible –There is insufficient information that early

Slide 15.7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning and the Information System Life Cycle l There is not enough information available at the end of the requirements workflow to plan the system –At that stage, the developers at best have an informal understanding of what the client needs l Planning has to wait until the end of the analysis workflow –At that stage, the developers have a detailed appreciation of most aspects of the target information system –This is the earliest point in the life cycle at which accurate duration and cost estimates can be determined

Slide 15.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning and the Information System Life Cycle l Early estimates can be wildly inaccurate

Slide 15.9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning and the Information System Life Cycle l Suppose that the delivered cost of an information system is found to be $1 million l The figure shows that if a cost estimate had been made –Midway through the requirements workflow, the relative range for the cost estimate was 4 »The cost estimate was probably in the range ($1 million / 4, $1 million  4), or ($0.25 million, $4 million) –Midway through the analysis workflow the relative range for the cost estimate was 2 »The range of likely estimates would have shrunk to ($1 million / 2, $1 million  2), or ($0.5 million, $2 million)

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning and the Information System Life Cycle –At the end of the analysis workflow, the relative range at this point was 1.5 »The estimate was probably in the still relatively wide range of ($1 million / 1.5, $1 million  1.5) or ($0.67 million, $1.5 million) l Cost estimation is not an exact science –And a premature estimate is likely to be even less accurate than one made at the correct time

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning and the Information System Life Cycle l The assumption throughout the remainder of this chapter is that –The analysis workflow has been completed,so meaningful estimating and planning now can be carried out

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Estimating Duration and Cost l Before development commences, the client wants to know how much the information system will cost –If the development team underestimates, the development organization will lose money on the project –If the development team overestimates, then the client may decide against proceeding, or –The client may give the job to another development organization whose estimate is more reasonable l Accurate cost estimation is critical

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Estimating Duration and Cost (contd) l Internal cost –The cost to the developers, including »Salaries of the development teams, managers, and support personnel »The cost of the hardware and software »The cost of overhead such as rent, utilities, and salaries of senior management l External cost –The cost to the client

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Estimating Duration and Cost (contd) l Sometimes –External cost = internal cost + profit margin l However, economic and psychological factors can affect this –If the developers desperately need work they may charge the client the internal cost or less –When a contract is awarded on the basis of bids, a team may try to come up with a bid that will be slightly lower than what they believe will be their competitors’ bids

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Estimating Duration and Cost (contd) l Estimating the duration of the project is equally important –The client wants to know when the finished information system will be delivered l If the project falls behind schedule –At best the developers lose credibility –At worst penalty clauses are invoked l If the developments overestimate the time needed –The client will probably go elsewhere

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Estimating Duration and Cost (contd) l It is hard to estimate duration and cost accurately –The human factor is critical l Experiments of Sackman –With matched pairs, Sackman observed differences of »6 to 1 in information system size »8 to 1 in information system execution time »9 to 1 in development time »18 to 1 in coding time »28 to 1 in debugging time –The best and worst performances were by two programmers, each of whom had 11 years of experience

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Estimating Duration and Cost (contd) l Human factors therefore preclude accurate estimates of duration or cost l Differences among individuals do not tend to cancel out, even on large projects –One or two very good (or very bad) team members can cause major deviations from estimations

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Estimating Duration and Cost (contd) l Critical staff members can resign during the project –Time and money then are spent »Finding replacements and integrating them into the team, or »Reorganizing the remaining team members –Schedules slip and estimates become inaccurate

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics for the Size of an Information System l The most common size metric –Lines of code (LOC), or –Thousand delivered source instructions (KDSI) l There are many problems with this metric –Source code is only a small part of the development effort –Versions in different languages have different numbers of lines of code –Should comments in the code be counted?

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics for the Size of an Information System –How should changed lines or deleted lines be counted? –What if code is not written, but rather inherited from a parent class? –Not all the code written is delivered to the client »Half the code may be for tools –What if thousands of lines are generated by »A report generator »A screen generator, or »A graphical user interface (GUI) generator

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics for the Size of an Information System l Lines of code is anything but a straightforward metric

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics for the Size of an Information System l Some metrics estimate size on the basis of the estimated number of lines of code l This is doubly dangerous l It is an uncertain input to an uncertain formula

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics for the Size of an Information System l Alternatives to lines of code –So-called software science »Anything but science! l What is required is a metric that can be computed from quantities available early in the life cycle –FFP metric »Size = Number of Files + Number of Flows + Number of Processes »Validated for medium-scale information systems »Never extended to databases –Function points (see over)

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics for the Size of an Information System –Function points »Based on the number of input items, output items, inquiries, master files, and interfaces »The metric also incorporates the effects of 14 technical factors

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics for the Size of an Information System l Function points and the FFP metric have the same disadvantage –Maintenance often is inaccurately measured –Major changes can be made without changing »The number of files, flows, and processes or »The number of inputs, outputs, inquiries, master files, and interfaces »(Lines of code is no better in this respect) l Mk II function points (an extension) are widely used to estimate the size of a target information system –Function points have also been extended to object- oriented information system

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Techniques of Cost Estimation l Expert judgment by analogy –An expert compares the target information system to completed systems and notes similarities and differences l Different estimates from experts are reconciled using the Delphi technique –Estimates and rationales are distributed to all the experts –They now produce a second estimate

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Techniques of Cost Estimation –Estimation and distribution continue until the experts agree within an accepted tolerance –No group meetings take place during the iteration process –Estimation by a group of experts should reflect their collective experience »If this is broad enough, the result well may be accurate

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Techniques of Cost Estimation (contd) l Algorithmic cost estimation models –A metric is used as input to a model –The model is then used to estimate duration and cost l Unlike a human, a model is unbiased –However, estimates from a model are only as good as its underlying assumptions l Hybrid models incorporate mathematical equations, statistical modeling, and expert judgment –The most important hybrid model is COCOMO

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO l COCOMO estimation is done in two stages l First, a rough estimate of the development effort is determined, based on –The number of lines of code in the target system, and –The level of difficulty of developing that target system l From these two parameters, the nominal effort can be computed

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO l Example: –The target information system is straightforward, and –Estimated to be 12,000 lines of code l The nominal effort will be 43 person-months

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO (contd) l Second, the nominal effort is multiplied by 15 development effort multipliers, such as –Required software reliability, and –Product complexity to yield the estimated effort –The multipliers can range in value from 0.70 to 1.66

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO (contd) l Example: –A network of ATMs is complex and the network has to be reliable –According to the COCOMO guidelines, the multiplier »Required software reliability is 1.15, and »Product complexity is 1.30

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO (contd) l The estimated effort is then used in additional formulas to determine various estimates, including –Dollar costs –Development schedules –Activity distributions –Annual maintenance costs

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO (contd) l COCOMO is a complete algorithmic cost estimation model –It gives the user virtually every conceivable assistance in project planning l COCOMO has proved to be the most reliable estimation method –Actual values come within 20 percent of the predicted values about two thirds of the time

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO (contd) l The major problem with COCOMO –Its most important input is the number of lines of code in the target information system –If this estimate is incorrect, then every single prediction of the model may be incorrect l Management must monitor all predictions throughout information system development

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO II l COCOMO was put forward in 1981 –It could not incorporate future technologies, such as »Client-server, and »The object-oriented paradigm had not yet been put forward –Accordingly, COCOMO is less accurate than it was l COCOMO II is a major revision of 1981 COCOMO that can deal with –The object-oriented paradigm –Various modern life-cycle models –Rapid prototyping –COTS packages

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. COCOMO II (contd) l COCOMO II is both flexible and sophisticated –Consequently, it is much more complex than the original COCOMO l The model still is too new to estimate –Its accuracy, and –The extent to which it is an improvement over the original COCOMO

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Tracking Duration and Cost Estimates l While the information system is being developed –Actual development effort must constantly be compared against predictions l Deviations from predictions serve as early warnings that –Something has gone wrong, and –Corrective action must be taken

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Tracking Duration and Cost Estimates (contd) l Management must then take appropriate action to minimize the effects of –Cost overruns, and –Duration overruns l Careful tracking of predictions must be done throughout the development process –Irrespective of the prediction techniques that were used l Detect deviations early in order to –Take immediate corrective action

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l The three main components of a project management plan are –The work to be done –The resources with which to do it, and –The money to pay for it all l The major resources required are –The people who will develop the information system, –The hardware on which the information system is to run, and –The support software such as operating systems, text editors, and version control systems

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l Use of resources of all kinds varies with time, including –Personnel –Computer time –Support software –Computer hardware –Office facilities, and –Travel l Resource consumption varies with time according to the Rayleigh distribution

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l A Rayleigh curve showing how resource consumption varies with time l Every project management plan is a function of time

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l The work to be done falls into two categories –Project functions –Activities and tasks l Project functions –Work that continues throughout the project, and –Does not relate to any specific workflow of the information system life cycle –Examples: »Project management »Quality assurance

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l Activities and tasks –Work that relates to a specific workflow l An activity is a major unit of work that –Has precise beginning and ending dates –Consumes resources, such as computer time or person- days, and –Results in work products such as a budget, design artifacts, schedules, source code, or user’s manual

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l An activity, in turn, comprises a set of tasks –A task is the smallest unit of work subject to management accountability l Therefore, there are three kinds of work in a project management plan –Project functions carried on throughout the project –Activities (major units of work), and –Tasks (minor units of work)

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l The completion of a work product is termed a milestone –The work product must first pass a series of reviews l Once a work product has been reviewed and agreed on, it becomes a baseline –It can be changed only through formal procedures,

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l A work package defines not just the work product but also the –Staffing requirements –Duration –Resources –Name of the responsible individual, and –Acceptance criteria for the work product l A detailed budget must be worked out and the money allocated, as a function of time, to the project functions and activities

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Project Management Plan Framework (contd) l There are many ways of drawing up a project management plan –One of the best is IEEE Standard 1058 l The components of the plan are shown on the next slide l The IEEE project management plan is designed for use with all types of information systems –It does not impose a specific life-cycle model –It does not prescribe a specific methodology

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l Components of the IEEE project management plan

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l The plan essentially is a framework l Each organization tailors the contents for a particular domain, development team, or technique l The IEEE project management plan framework is ideal for the Unified Process

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Components of a Project Management Plan l The full plan framework is described in Section 15.5 l A slightly abbreviated version of the framework is used in Section 15.6 for a management plan for a small-scale project, the Osbert Oglesby case study

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning of Testing l Like every other development activity, testing must be planned –The project management plan must include resources for testing –The detailed schedule must show the testing to be done during each workflow

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning of Testing (contd) l Development must be traceable –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 reflected explicitly in the code l One technique is to number each statement in the specification document and ensure that these numbers are reflected in both the design and the resulting code –This has to be specified in the test plan –Numbering is hard to add after the product is complete

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Planning of Testing (contd) l The detailed list of faults detected during an inspection is a powerful aspect of inspections –Unless the test plan states that details of all faults have to be carefully recorded, it is unlikely that this will be done l Every test plan must specify –What testing is to be performed –When it is to be performed –How it is to be performed

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Training Requirements l Training is needed by the users when the system has been delivered –Training also may be needed by members of the development team »Especially when new techniques are introduced l Once the training needs have been determined and the training plan drawn up –The plan must be incorporated into the project management plan

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Documentation Standards l Documentation absorbs a considerable portion of the information system development effort –Typically, 150 to 200 hours are spent on documentation for every 100 hours spent coding the system l Standards are needed for every type of documentation –These standards must be incorporated in the project management plan

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Documentation Standards (contd) l Documentation is an essential aspect of the information system development effort –The documentation effort must be planned in detail, and –Then the plan must be adhered to

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Tools for Planning and Estimating l COCOMO and COCOMO II have been automated –Including spreadsheet implementations l A word processor is essential for developing and updating the plan itself l Management information tools also are useful for planning, such as scheduling tools

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Tools for Planning and Estimating (contd) l More general types of management information also are needed l Commercially available management tools can assist with the development process as a whole: –Planning –Estimating, and –Monitoring l Commercial examples: –MacProject, Microsoft Project

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Testing the Project Management Plan l Cost and duration estimates must be as accurate as possible l The entire project management plan must be checked by the quality assurance group before estimates are given to the client –The best way to test the plan is by a plan inspection

Slide Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Testing the Project Management Plan (contd) l The plan inspection team must review the project management plan in detail –Special attention must be paid to the duration and cost estimates l To reduce risks even further –As soon as the members of the planning team have determined their estimates, duration and cost estimates should be computed independently by a member of the quality assurance group l This must be done irrespective of the metrics used