slide 15.1 copyright © 2004 by the mcgraw-hill companies, inc. all rights reserved. an introduction...

1

Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

An Introduction toObject-Oriented

Systems Analysis and Design with UML and

the Unified Process

McGraw-Hill, 2004

Stephen R. Schach

[email protected]

2


CHAPTER 15

PLANNING AND ESTIMATING

3


Chapter Overview

Planning and the Information System Life Cycle Estimating Duration and Cost Components of a Project Management Plan Project Management Plan Framework IEEE Project Management Plan Framework Project Management Plan: Osbert Oglesby Case

Study Planning of Testing

4


Chapter Overview (contd)

Training Requirements Documentation Standards CASE Tools for Planning and Estimating Testing the Project Management Plan

5


Planning

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

6


Planning and the Information System Life Cycle

Ideally, the plan for the entire information system project would be drawn up at the very beginning of the life cycle

This is impossible– There is insufficient information that early

7



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

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

8



Early estimates can be wildly inaccurate

9



Suppose that the delivered cost of an information system is found to be $1 million

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)

10



– 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)

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

11



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

12


Estimating Duration and Cost

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

Accurate cost estimation is critical

13


Estimating Duration and Cost (contd)

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

External cost– The cost to the client

14



Sometimes– External cost = internal cost + profit margin

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

15



Estimating the duration of the project is equally important– The client wants to know when the finished information

system will be delivered

If the project falls behind schedule– At best the developers lose credibility– At worst penalty clauses are invoked

If the developments overestimate the time needed– The client will probably go elsewhere

16



It is hard to estimate duration and cost accurately– The human factor is critical

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

17



Human factors therefore preclude accurate estimates of duration or cost

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

18



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

19


Metrics for the Size of an Information System

The most common size metric– Lines of code (LOC), or– Thousand delivered source instructions (KDSI)

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?

20



– 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

21



Lines of code is anything but a straightforward metric

22



Some metrics estimate size on the basis of the estimated number of lines of code

This is doubly dangerous

It is an uncertain input to an uncertain formula

23



Alternatives to lines of code– So-called software science

» Anything but science!

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)

24



– 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

25



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)

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

26


Techniques of Cost Estimation

Expert judgment by analogy– An expert compares the target information system to

completed systems and notes similarities and differences

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

27


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

28


Techniques of Cost Estimation (contd)

Algorithmic cost estimation models– A metric is used as input to a model– The model is then used to estimate duration and cost

Unlike a human, a model is unbiased– However, estimates from a model are only as good as its

underlying assumptions

Hybrid models incorporate mathematical equations, statistical modeling, and expert judgment– The most important hybrid model is COCOMO

29


COCOMO

COCOMO estimation is done in two stages

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

From these two parameters, the nominal effort can be computed

30


COCOMO

Example:– The target information system is straightforward, and – Estimated to be 12,000 lines of code

The nominal effort will be 43 person-months

31


COCOMO (contd)

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

32


COCOMO (contd)

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

33


COCOMO (contd)

The estimated effort is then used in additional formulas to determine various estimates, including– Dollar costs– Development schedules– Activity distributions– Annual maintenance costs

34


COCOMO (contd)

COCOMO is a complete algorithmic cost estimation model– It gives the user virtually every conceivable assistance in

project planning

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

35


COCOMO (contd)

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

Management must monitor all predictions throughout information system development

36


COCOMO II

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

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

37


COCOMO II (contd)

COCOMO II is both flexible and sophisticated– Consequently, it is much more complex than the original

COCOMO

The model still is too new to estimate – Its accuracy, and– The extent to which it is an improvement over the original

COCOMO

38


Tracking Duration and Cost Estimates

While the information system is being developed– Actual development effort must constantly be compared

against predictions

Deviations from predictions serve as early warnings that – Something has gone wrong, and – Corrective action must be taken

39


Tracking Duration and Cost Estimates (contd)

Management must then take appropriate action to minimize the effects of– Cost overruns, and– Duration overruns

Careful tracking of predictions must be done throughout the development process– Irrespective of the prediction techniques that were used

Detect deviations early in order to– Take immediate corrective action

40


Components of a Project Management Plan

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

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

41



Use of resources of all kinds varies with time, including – Personnel– Computer time– Support software– Computer hardware– Office facilities, and– Travel

Resource consumption varies with time according to the Rayleigh distribution

42



A Rayleigh curve showing how resource consumption varies with time

Every project management plan is a function of time

43



The work to be done falls into two categories– Project functions– Activities and tasks

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

44



Activities and tasks– Work that relates to a specific workflow

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

45



An activity, in turn, comprises a set of tasks– A task is the smallest unit of work subject to management

accountability

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)

46



The completion of a work product is termed a milestone– The work product must first pass a series of reviews

Once a work product has been reviewed and agreed on, it becomes a baseline – It can be changed only through formal procedures,

47



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

A detailed budget must be worked out and the money allocated, as a function of time, to the project functions and activities

48


Project Management Plan Framework (contd)

There are many ways of drawing up a project management plan– One of the best is IEEE Standard 1058

The components of the plan are shown on the next slide

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

49



Components of the IEEE project management plan

50



The plan essentially is a framework

Each organization tailors the contents for a particular domain, development team, or technique

The IEEE project management plan framework is ideal for the Unified Process

51



The full plan framework is described in Section 15.5

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

52


Planning of Testing

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

53


Planning of Testing (contd)

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

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

54


Planning of Testing (contd)

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

Every test plan must specify – What testing is to be performed– When it is to be performed– How it is to be performed

55


Training Requirements

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

Once the training needs have been determined and the training plan drawn up– The plan must be incorporated into the project

management plan

56


Documentation Standards

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

Standards are needed for every type of documentation– These standards must be incorporated in the project

management plan

57


Documentation Standards (contd)

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

58


CASE Tools for Planning and Estimating

COCOMO and COCOMO II have been automated– Including spreadsheet implementations

A word processor is essential for developing and updating the plan itself

Management information tools also are useful for planning, such as scheduling tools

59


CASE Tools for Planning and Estimating (contd)

More general types of management information also are needed

Commercially available management tools can assist with the development process as a whole:– Planning– Estimating, and– Monitoring

Commercial examples:– MacProject, Microsoft Project

60


Testing the Project Management Plan

Cost and duration estimates must be as accurate as possible

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

61


Testing the Project Management Plan (contd)

The plan inspection team must review the project management plan in detail– Special attention must be paid to the duration and cost

estimates

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

This must be done irrespective of the metrics used

slide 15.1 copyright © 2004 by the mcgraw-hill companies, inc. all rights reserved. an introduction...

Documents