Phillips_-_The_Software_Project_Managers_Handbook_-_sec_6.3-6.4

8/7/2019 Phillips_-_The_Software_Project_Managers_Handbook_-_sec_6.3-6.4

1/22

146 THE SOFTWARE PROJECT MANAGER'S HANDBOOKThe final group of best practices are covered in CMM Levels 3, 4, and 5. In fact,many criticize the CMM for deferring these practices until higher levels. "How canyou possibly omit such and such until level X? Yo u won't reach that level for threeyears and such and such is essential today." This is a valid criticism when taken outof context, but the levels are in the CMM because people ca n absorb only so muchchange a t a time. It would be great t o bring in all the best practices a t once, but thatis hardly feasible.Reviews, inspections, and walkthroughs (see Chapter 9) le t people look at the workof others to find and fix errors early and remove misunderstandings.Reusable items cut down on the new work to be done. Reuse is an excellent goal,but few people have it. It is difficult t o capture work done t o date, put it in a library,and make it easy t o search, retrieve, and reuse. Source code is not the only item youcan reuse. Aim to reuse parts of CM plans, requirements, designs, test scripts, and

test data. Always think about reuse when building something for the first time. Askwhat could be done differently that will make the item reusable. Also ask if some-thing is available that can be reused t o fit the current need.Testing early and often is essential. Errors kill projects because if found late , thecost of fucing them is far out of proportion t o their value. Inspect, test, and reviewproducts early. Use visibility to get people thinking about the work of others.The PSP emphasizes simple methods of defect tracking. Where were errors com-mitted? Who found them? How? Where? When? How long did it take t o fix them?What kind of errors were they? What practices will let us find them earlier or prevent

them? These are difficult questions, but the answer8 are available and valuable.

6.3 Making the project visible: Planning techniques6.3.1 Project contextThe first thing I do on a new project is create a project context document. This docu-ment is fo r my development team and me only-no one else. A project context dia-gram structured as in Figure 6.14is on the first page; the rest of the document dis-cusses the diagram. The project context diagram is very different from the contextdiagram in Figure 5.7 (see Chapter 5).The context diagram is a high-level dataflowdiagram. The project context diagram, on the other hand, shows the context or set-ting of a project.

As the figure shows, the left side of the diagram contains th e names of the cus-tomer, executive sponsor, and our team (producer).The developers must know who isand is not the customer. Do not disdain outsiders who w a n t t o help, but know a n dlisten to your customer first. The customer and marketplace objectiues are the proj-ect's high-level goals. They are qualitative not quantitative and come from marketingo r customer surveys. They will influence the project requirements.

Also influencing the project requirements are the three items on the right. Exter-nal requirements include compatibility issues and support required by others. Thenew system will not exist in a vacuum. It must work with existing systems and or-ganizations. In the same way, the project must fit with company and project policies.Businesses have personnel work standards and rules. List these so that everyoneknows what is influencing management's decisions. Finally, there are the project's

CustomerExecutiveSponsor

Producer

Figure6.14 The projectco

constraints. Time, monechallenge them ("ifwe bcan save 3 months andAll these items comwant from the project, ntitative. They are an intThe final tw o blockspaper. The system requi

design concept is a one wFigure 6.15 shows Jones Inc. t o give you athe company and projecTh e project context

put them on paper whedocumented, I share ththe diagram and refme this document and shaand months.The ideas in the doccreated in an hour constel l new development tethis away from the custo


2/22

, CustomerExecutiveSponsor

Producer

ICustomerMarketplaceObjectivesI.ProjectRequirementsLSystemRequirements(High-Level)

SystemDesignConcept

Figure 6.14 The projectcontext diagram

C0

ExternalRequirements

ntSraint

Company andProject PoliciesS

PLANN ING 147

constraints. Time, money, an d equipment are limited. State the limitations and thenchallenge them (if we buy SQL Sup er instead of using the same old Power team, wecan save 3 months and $500,000).All these items come together into the project requirements. These are what wewant from the project, not the system. These requirements are qualitative and quan-titative. They are an interpretation of the objectives in light of the constraints.The final two blocks in the d iagram ar e simple atte mpt s at building the system onpaper. The sys tem requirements a re wha t we want from the new system. The sys temdesign concept is a one way t o achieve those desires.Figure 6.15 shows a project context diagram for a new accounting system for

Jones Inc. t o give you an idea of how these blocks are filled in with project dat a (bothth e company and project a re fictitious).

The project context diagram helps me gather my thoughts about the project, andput them on paper where I can see them. ARer Im satisfied th at my ideas are clearlydocumented, I share them with the initial, small development team. We work overthe diagram and refine it. The project context puts us all on the sam e track. We keepthis document and share it with each new person who joins the project over weeks

The ideas in the document are not concrete. Do not let t he system design conceptcreated in an hour constrain the project. Use it for wha t it is-a simple, quick tool t otell new development team members what the project is about in genera l terms. Keepthis away from the customer, who can easily misinterpret your inten t.


3/22

t


4/22

Analyze the requirements for X.Design at a high level for X.Design at a low level for X .Build components for X.Test components for X.Integrate and test components for X .Test system for X.

Figure 6.16 shows an example. Across the topan accounting software package called D-Count (t

PLANNING 149

f the figure a re four products forere should be more products, butthis is sufficient fo r the example). Note th e addition of a system product. Always addthis to the product list because every project will have tasks devoted t o the projectitself. Make a ta sk card for each task block. Use plain 3 x 5 o r 5 x 7 cards o r Post-Itsof this size. Each task card will eventually contain all the task elements shown inFigure 6.1. The example in Figure 6.16 will have 28 task cards. This is probably toomany, bu t it's easier t o discard tasks later than t o think of ones you should have

System~ Analyze I~ Requirements j1 ~ - D e n i g n T1 High-Level I

D-Count Software

' Designat- ~ - a l! High-Level IDesign at

User's Manual

Design at

Test Suite[ X n i TRequirementsI Des i gnat '1 High-Level 1

Design at~..

' Build

~~ System , Test ~

Test Conceptswork breakdown structure,


5/22

I50 THE SOFTWARE PROJECT MANAGER'S HANDBOOK3. Lay out an ini t ial task network. Figure 6.17 shows the initial task networkfor the example in Figure 6.16.Tack o r tape the task cards t o the walls an dconnect them with yarn or string, or cover the walls with white boards, tapethe task cards on the boards, and connect them by drawing lines on theboards with markers. Use large Post-Its instead of regular cards t o make thiseasier.

The initial task network is structured around the three main products (D-Countsoftware, test suite, and user's manual). These have horizontal strips of tasks associ.ated with them. The three task strips join at control gates or milestones-junctioasthat stop the project and give everyone a chance t o think before embarking on a new(expensive)flurry of activity. The task strips are parallel, which means tasks can beperformed simultaneously if the people are available. Assign people t o tasks at thistime.Creating the initial task network requires some thought, but it is mostly a me.chanical process. Put the tasks associated with each product in strips. Place a controlgate after system high-level design, aRer the low-level design of each product, andbefore all the products are integrated.4. Refine the ini t ial network. This is the creative and difficult part of the proc-

ess. Delete, add, combine, and rearrange the cards. Move them around an dchange their connections. Change the people, time, resources, inputs, andoutputs on each card. Challenge the people refining the network. "Could yourpeople outline the user's manual in three days?" 'Won't you need t o finish thedesign of the main routine before you design that subroutine? How can you dothem in parallel?"The refined network is the project's schedule-your commitment t o everyone-andyou must take it seriously. Allow for vacations, illness, and training. Give your peoplethe time and resources they need to succeed.

Figure 6.17 Initial task network for the example in Figure 6 16

Figure 6.18 shows the fmanagement software packsoftware will generate a Gtion than you could possiblyDocument the decisionsthe user's manual will be wgins. This is unusual. W hy d

tives? What factors pushedUse the project managePERT and Gantt charts. POdoing the work. The project

thing wrong, listen and chharder. You will destroy yo6.3.3Cards on the walCards on the wall is a wor6 ) ,but it is also an excellenple working a task networticipants own the plan, andvolve people from as manyand so on) as possible.

I

Figure6.18 The final task net


6/22


7/22

152 THE SOFTWARE PROJECT MANAGERS HANDBOOK...,....a. . . . .I . .

Flgure6.19 Cards on the wall planning session.

As the project manager, dont worry too much about the task network-that willget done. Instead, focus on the people. If someone is sitting back at the table, bringthem to the wall. Suggest a few stupid ideas and move cards related t o them t o thewrong place. Push them into asserting their expertise t o correct you. Make themwork on the plan until they own it.

Prepare for the cards on the wall session in the same way you would prepare for aJAD session (see Chapter 5) . A cards on the wall session involves a number of peoplefor one to five days. It costs money, so it deserves and requires forward thinking.Find a room off site t o minimize interruptions. Ensure it has ample blank cards,yarn, empty walls or white boards, tape, pens, paper, bathrooms, refreshments, com-puters, printers, and so on. Do not start until everyone arrives. Get a commitmentfrom management that everyone will stay until finished. Do a warm-up exercise likea task network for celebrating after the project.This may seem like a silly gimmick, but it works. Some may ask Cant one personjus t do the schedule and have others comment on it? This approach might work, butthe plan would always belong t o the person who created it. It is Bills plan, not yourplan. When people own a plan, they work hard t o see it succeed.

6.4 Making the project visible: EstimatingtechniquesEstimation is predicting the size of a product o r the length of a task. Most people donot estimate well, even though estimation is an essential par t of planning. Its takenme years of successes and failures t o evolve the following guidelines:

Know the purpose of the estimate and the desired accuracy. If someone needs theestimate for an informal discussion and it need be only within an order of magnitude,pause and give an answer. If the survival of the business depends on the estimateand it must be accurate within f 2 percent, an offhand reply would be disastrous. Youare more likely t o encounter the first example in practice.

Use prerequisites whand use a repeatable prtion. Es timates withouwith metrics. If an orgasign, build, and integrattions), its people knowpredict how much timepline, matu re process, aIf the prerequisites aviding the tasks or proeasier (almost anyone cdivide-until-small task duces the feeling of creation will require. Perfotemptation t o fall back (just solve it) and work

Be real is t ic . For mossoftware. A n optimisticthe job). It can also meworking 80 hours a wee

There a re two mainThe Rayleigh model is PSP is an example of tence, and both work. Dhours to perform.

6.4.1 Rayleigh modThe Rayleigh model gifor a project are realis19961 [Putnam 19971d

The model is basedLord Rayleigh). As Figproject beginning withuct. The horizontal axistaff-months per montof the project. This sho

The first vertical dotial operational capabware reaches final opecal dotted line is 39 pepercent of the total, aMany people think theThis model states thatpoint, the remaining 6


8/22

PLANNING 153e prerequisites whenever they are auailable. Have metrics from past projectsuse a repeatable process. Metrics provide a reliable foundation for any estima-Estimates without past data are dangerous. A repeatable process is a partner

t how much time the same steps will require on the next project. Their disci-

tation to fall back on a familiar task. Resist the temptation t o start coding now

t can also mean a failed project (more time and money than estimated o r0 hours a week for 40 hours pay).are tw o main types of approaches t o software estimating: macro and micro.eigh model is an example of the macro approach; the Probe technique in the

.4.1 RayleighmodelThe Rayleigh model gives you an overall project perspective t o help ensure that plans6m a project are realistic. Larry Putnam and Ware Myers [Putnam 19921 [Putnam15961[Putnam 19971 developed this model from years of experience.The model is based on the Rayleigh curve (named after the 19th century physicistlord Rayleigh). As Figure 6.20 shows, the curve is the actual effort expended in aproject beginning with design and ending with the delivery of a highly reliable prod-&.The horizontal axis is time in the project. The vertical axis is the current effort instaffmonths per month. The a rea under the curve is the total effort o r staff-monthsofthe project. This shows the cos t (staff-months times dollars per staff-month).

The f is t vertical dotted line is a t time TD.This is where the software reaches ini-tial operational capability (100. The second vertical dotted line is where the soft-ware reaches final operational capability (FOC). The area t o the left of the first verti-cal dotted line is 39 percent of the total area, the area between the dotted lines is 39percent of the total, and the remaining 22 percent is in the long tail t o the right.Many people think they are done when the software works for the first time (100 .


9/22

1154 THE SOFTWARE PROJECT MANAGERS HANDBOOK

Staff M o n t hPer Month

Figure6.20The Rayleigh Curve

The Rayleigh curve fits the staffing of large software projects. The curve beginswhen design does. The project needs only a few people a t th at time because there isonly so much anyone can do. After the designers divide the design into parts, theparts need further design and division, so more people join the project. Coding beginst o the left of the curves peak, and staffing increases again . The software is ready faruser testing near the curves peak, the IOC. Testing involves the maximum numberof people for the project. Staffing declines after testing as the testers, and some pro-grammers move on t o other projects. The remaining programmers correct the errorsfound during testing. As the number of errors declines, so does the number of pro-grammers. The software reaches an acceptable threshold of errors at FOC and is de-livered. A s the figure shows, however, 22 percent of the work remains in respondingt o the customer and supporting the product.

Figure 6.21 lists the equations for the Rayleigh model. The first equation (11,de-rived by Futnam and Myers, gives your organizations productiuity parameter. Th eauthors consider productivity t o be more than just LOC divided by time. The produc.tivity parameter is calculated from past project performance and indicates the 01-ganizations overall capability. The product size is the (often argued) lines of code(LOC) in the delivered software. This method requires us ing LOC, but there aremethods for converting function points t o LOC. Effort is the staff-years needed forthe project. B is a special skills factor tha t ranges from 0.16 for products with 5,000t o 15,000 LOC t o 0.39 for products with 70,000+LOC [Putnam 19921 [Putnam 19971.This constant compensates for the differences in different size projects. (Larger praj.ects have more people, which requires more communication. This means more meet.ings and more miscommunication, which c a n lead t o more errors.) Time is expressedin years.

Next is the software equation. Notice that time (T) is raised t o a power greaterthan one. This reflects the nonlinear nature of software projects. That is, softwareproducts twice as big require much more than twice as much time and money.The software equation lets you calculate the time, effort, and cost of a projectgiven your organizations past performance and the estimated LOC for the project.

You merely insert the final LOC, the staff-years of effort, the time required in years,and the correct special skills factor B from a similar project and calculate the produc.

Flgure6.21 E

tivity paramthese numban even moUse the

d a t e d t o fin staff-yeato multiplymonth (stafCheckingvalidity ofneering sofin 18 montstaff-year).31,481 to asoftware h19971. (Remparametercan tell frosignificantlfort, and cogate to seemeet their Estimatinbuild partstion). Figurof phases bfeasibility sproduct sizcompanys bility studyfew more psize and ca


10/22

Time

curve begins

sis ready for

C and is de-

(l), de-TheThe produc-or-of code

w i t h 5,00019971.more meet-s expressed

wareof a projectthe project.ed in years,the produc-

PLANNING 155( 1 ) Productivity Parameter = Product S i y(Effort/B)'"*Time'"

(3) Th,"= 8.14 * (Product SizeIPmductivlty Parameterp'.' in months(4) Effort in man ?ears = 15 * B * Th,"'with T In years( 5 ) Effort in man months = 180 * B * Tb2 with TI " years(6) Cost =Man Months * $Ma n Months

Figure 6.21 Equationsof the Rayleigh model.

tivity parameter. Most organizations, even those without metrics programs, havethese numbers. In the next section, I describe how t o use the Probe approach to getan even more accurate estimate of the proposed product's LOC.

Use the estimated LO C fo r this project and the productivity parameter just cal-culated to find the minimum TDfo r this project. Equation (2) is for calculating Tominin staff-years; Equation (3) lets you calculate in staff-months. The final step is simplyt o multiply the staff-months (or staff-years) of effort by the average cost of a staff-month (staf-year) for your organization.Checkingproposals. As Figure 6.22 shows, these equations ca n help you check thevalidity of proposed plans and costs. The company here proposes t o write an engi-neering software package with an estimated 300,000 LOC, which they hope t o buildin 18months with 800 staff-months at a cost of $9.99 million (charging $150,000 perstaff-year). The first calculation shows that their productivity parameter must be31,481t o accomplish this. History says the average firm that produces engineeringsohare has a productivity parameter of about 14,000 [Putnam 19921 [F'utnam19971. (Remember tha t the 31,481is not a s bad a s it seems because the productivityparameter scale is nonlinear.) Assuming the company is about average (which youc a n tell from past project performance), the 14,000value gives a schedule and costsignificantly higher than proposed. Use the 14,000 value and calculate the time, ef-for t , and cost as shown. Do not accept this proposal. Explain the doubts and investi-!ate to see if the company c a n justify the higher productivity parameter needed tomeet their proposal.Estimating time before main-build. The Rayleigh model pertains t o the mainbuild parts of a software project (design, code, inspection, testing, and documenta-tion). Figure 6.23 is another view of the Rayleigh curve that shows the relative timesof phases before the main build. The first phase is what h t n a m and Myers call thefeasibility stu dy. A few people analyze the requirements of the system, estimating theproduct size in ranges (minimum, expected, and maximum size). These sizes and thecompany's productivity parameter let you calculate Tomlnas shown earlier. The feasi-bility study should last only one fourth of TD.The functional design phase is where afew more people perform the high-level design. They revise the estimate of productsize and calculate a better TD .This phase should last only one third of TO.


11/22

156 THE SOFTWARE PROJECT MANAGER'S HANDBOOK

EstimatedProposed

Size = 300,000 lines of codeTime = 18 months = 1.5 yearsEffort = 80 0 man-months= 66.6 man-yeanCast Rate = $150.000pe r man-yearCoat = $9.99M

Required Productivity Parameter = (GG.6/0.39)'"* (1.6)'"= 31,481

Industly Average Pmductivity Parameter = 14,000T, ~ = 0.68* (300,000/14,000)"'"=2.54 man-yearsEffort= 15 * 0.39* 2.54' = 95.86 man-yearsCast = $150,000 * 95.86 = $14.4M

Figure6.22 Checking the validity of a proposal for an engineering system.

Man-MonthsPerMonth t

MainFunctional

. ... .. .Study

0 T DFigure6.23Relative time prior to main build.


12/22

Time

PLANNING 157

0.5 1.0Past Data ShowsProductivity Parameter = lO,OOO/((201(12*0.16))'M (11/12)") = 5,142Expected Lines of Code = (20.000+ 30,000)12= 25,M)OMinimum To=8.14 * (25,00015,144)0~43=16.1 months = 1.34yearsEffort = 180 0. 16 " 1.34O." = 69.3 ma n mo n t h sTotal Cost = 69.3 manmonths 510,000 per man-month = 56.93MEmn= 69.3 man-monthsl16.1 months = 4.3 peopleTime Actual Rounded Manpower Actual Rounded MonthsLength Time Months Ratio Manpower PeopleRatio (months) beop le)0.15 2.42 2 0.5 1.72 2 0-20.3 4.83 5 1.0 4.3 4 2-50. 7 11.27 11 1.5 6.45 6 5-110.85 13.69 14 1.0 4.3 4 11-141.0 16.1 16 0.5 1.72 2 14-1616-202 people

Flgure 6.24 Simple'estimation model of a 25.000 LOC project.

Planning project staffing. Figure 6.24 illustrates a 25,000 LOC project. Thesquared-off curve indicates that people are added t o the project in whole units (nohalf o r quarter people). This curve is for relatively small projects. Different curvesare used for different size projects [Putnam 19921 [F'utnam 19971. This curve is nor-malized so that the average project effort is 1.0 on the vertical axis and the time t oreach FOC is 1.0 on the horizontal axis. T h e shape of the curve will always be asshown for this project size.

Data from past projects leads to a productivity parameter of 5,144. The TD calcu-lation yields 1.34 years o r 16.1 months, and the effort is 69.3 staff-months. Given ourcost of $10,000 per staff-month, the total cost of the project is approximately $7 million.If you replace the normalized numbers on the curve with actual ones, the 1.0 onthe horizontal axis becomes 16.1 months (in this curve and for this size project, theIOC and FOC are the same). The 1.0 on the vertical axis is effort divided by TDo r 4.3people. The table a t the bottom of the figure shows the conversions for normalizing t oactual numbers. The first column is the normalized time numbers. Multiplying each

by 16.1 produces actual time in months, which you then round off to get a practicalnumber. The next three columns pertain t o manpower. Multiplying the normalizednumbers by 4.3 gives you the actual manpower, which you again round t o wholenumbers (people). The result is that tw o people will be the staff the first tw o months,four people the next three months, six people the next six months, and so on. Two peo-ple will probably be needed to support the customer for four months after delivery.


13/22

158 THE SOFTWARE PROJECT MANAGER'S HANDBOOKA closer look at this example shows the dollars and cents value of process im-provement. The cost ($7million) seems expensive for 25,000 LOC. Sta rt a t total costand trace backward. The cost is a simple multiplication of effort. The biggest con.tributor to effort is time raised to the third power. Cut the time and effort by stream.lining the process and cost will fall dramatically. The time equation has a constant,the LOC, and the productivity parameter. Increase the productivity parameter mdall the expensive numbers fall. If this rises from 5,144 t o 10,000 (not that much asthis is a nonlinear item), To would fall t o 12 months, and effort would fall to 29.3staff-months. The cos t would be about $3 million instead of $7million. Thus, a single,one-year project would save $4 million. Process improvement is expensive and timeconsuming, but as these figures show, it h as a definite payoff.The Rayleigh model delves into more topics than I can discuss here. It lets youcalculate the proper staff build-up rates, peak staff time, defect rates, and so on.Read more about this model in books and papers by Putnam and Myers. Tens ofyears and hundreds of actual projects are the model's foundation. It is not theory. Itworks a t work.

6.4.2 PSP's ProbeThe Personal Software Process [Humphrey 19951 uses Probe t o predict the product'ssize and the required build time. In Probe (short fo r Proxy-Based Estimation), yousubstitute experience on similar past products and projects t o predict future ones.

Figure 6.25 shows an overview of the estimating process. You combine the basicdesign for the product with historical size data (proxies) to estimate the size of thenew product. The size estimate and historical productiuity data (more proxies) let youestimate resources, including time. The next s tep is to put the tasks and times into aschedule (make schedule). Finally, you execute the plan t o produce the product, feedback the actual size and time t o the historical databases, and gather metrics. Metricsare crucial t o the success of the process.

LM a k e Schedule

ILExecute Plan , Gather Mstrica

IPmduct

Figure6.25 Overview of the PSPplanning and estimating process

Figurebasic techlems you similar t oestimatespast estimFigure

Figure 6.par ts of thThe relatifill in the

Figure 6.26

Figure 6.2


14/22

h-

as29.3

youon.ofIt

you

ua

Basic Design

IDivide into parts-NO1Do parts resemble parts

m lusmrical data?1 Y esSelect similar partsfrom historical database

Estimate size fromsimilar parts1Sum it up4Adjust usinglinear regression

W i n the table with actual numbers from past projects.

-

Keep dividing untilthe answer is Ye s

Figure6.26Overview of the "estimate size* step in Figure 6.25,

PLANNING 159Figure 6.26shows the elements of the estimate size step in Figure 6.25.This is the

basic technique of taking an unsolvable problem and breaking it into smaller prob-lemsyou can solve. The s teps consist of dividing the product in to small parts that aresimilar to parts from past projects. You can then use the actual sizes of past parts aspast estimated and actual projects using linear regression.

Figures 6.27and 6.28 give additional task breakdowns in estimating product size.Figure 6.27shows a table t ha t s tar ts with data on past sofiware. You then categorizeparts of the software by function type and list them in the left column of Figure 6.28.Th e relative sizes of these pa rt s form the column heads in Figure 6.27.You c a n then

VeryLarge

136.5155.2144.5157.6160.2141.6

Relative [email protected]/OLogicSetupText

Very S m a l l Medium LargeS m a l l

8.3 42.1 75.6 99.67.5 44.3 82.1 102.46.9 39.6 71.5 107.511.2 45.2 69.7 95.27.7 33.6 83.2 93.19.5 51.2 77.9 89.6

Figure 6.27 Classifying historical data to determine product size.


15/22

160 THE SOFTWARE PROJECT MANAGER'S HANDBOOKNam e Category Relative Lines of CodeSize from HistoricalSource CodeTableMain-mutine Setup Small 42.1Percent-remaining Calculation Large 99.6Balancesummary U O Very Lame 144.5Fileenpen-andrreate UO Medium 71.5... ... .. . ...

Init ia l Total Est imated Size: 1,566.6 Lin e s of CodeFlgure 6.28 A table for estimating product size.

The PS P uses lines of code to measure product size. Figure 6.28, a size-estimatingtable, shows subroutine categories and sizes in LOC. Many argue that subroutinesare passe in an object-oriented world and tha t LOC is a bad measure of software size.I will not debate that here. My advice is to adapt Probe using whatever works-LOC,function points, number of data-entry screens, pages in a book, slides in a presenta-tion, object classes, and so on-but be consistent throughout. Here I continue t o usesubroutines and LOC, but this is not the only scheme tha t will work with Probe.

To derive the table in Figure 6.28, you first design the product at a high level toproduce a list of subroutines. You can then categorize each subroutine, decide on itsrelative size, and fill in the rightmost column with numbers from the table in Figure6.27. Sum the rightmost column t o get the initial estimate of LOC. The next step,linear regression, will produce the final estimate.

Figure 6.29 s h o w s the linear regression equations. Most people use a rule ofthumb-add 40 percent to the initial estimate-to get this number. Linear regressionarrives a t a final estimate with more rigor and less subjectivity. Do not be alarmed ifspreadsheets and handheld calculators provide answers in five minutes. Linear re-gression fits a straight line through data, as shown by the top half of Figure 6.30, aplot of the estimated LOC vs. the actual LOC for five projects. Linear regressionequations not only calculate the equation of the line passing through these points,but also the actual LOC that corresponds to the estimated LOC on the line. Anyonecan draw a line on th e graph tha t seems to fit the points. Linear regression providesa line that has the best fit for the points. The bottom half of Figure 6.30 shows thefinal estimates for several initial estimates.

Final Estim ated LOC = P. + ( P i * Initial Estimated LOC)Z(Est1mated LOC. Actual LOC,) .n Estimated LOCAvo*Actual LOC,,,

X( Estim ated LOC,)'. n*(Estimated LOC,,)*P ,=for n prior projects

Po=Actual LOC,,. B, * Estimated LOC.,,Figure6.29TrOnSfOrming the initial estimated size to the fin d estimated size using linearregression.

h t u

Ir

XC

I-

*m

C

Figure6.30

The finth e size esand t he acsimilar t o sactu al size

Tim

P =

Po=Figure6.31


16/22

Code

software size,works-LOC,

its

regressione alarmed if6.30,aregression

oneion providesshows the

i

PLANNING 161*lull u xt

DataEstimated Actual550 6751100 7951500 14501750 12002100 2315p a = 0.96!3 I= -43Actual LO C = -43 + (0.95)*(EsimakdLOC)Calculated ValuesInitial Estimate Final Estimate10002000 1877

Figure6.30A graph of linear regression for five projects.91 7

The final step of Probe is t o use linear regression to produce a time estimate fromthe size estimate. As Figure 6.31shows, the equations for this use the es timated sizean d the actual time of past programs. These equations can then be graphed in a waysimilar t o size estimating. If estimated sizes of past projects are not available, use theactual size of pas t projects in these equations.

Time Estimated = Po+ (p,* M C Estimated)I x(L0C Estimated, * Time Actua l,) .n * LOC Estimated,, . T h e Actual,,,for n prior projects

P = E[ W C Estimated,)'. n'(WC Estimated,,)*

I Po= Time Actual A v ~P ,* LOC Estimated *"uFigure6.31 Calculating estimated time from past project size in Loc


17/22

162 THE SOFTWARE PROJECT MANAGER'S HANDBOOK IProbe transforms a seemingly impossible estimating problem into small, possiblesteps. However, it does depend on d ata from past projects, which is one reason Hum-phrey teaches the PSP in steps, postponing its introduction until after the studenthas completed several projects. Use the PSP or some other means t o begin recordingsize and time data . It will seem like bureaucracy, but it is the only way t o provide t h evisibility you need to estimate and plan future projects.

Probe also transforms a qualitative rule of thumb (like add 40 percent to get afinal estimate) into a quantitative, visible estimate. Because it is visible, people canwork through it, understand it, and improve it. The graphs and equations give formand discipline t o otherwise fuzzy ideas.Humphrey created Probe t o work with an individual programmer on one-personprojects (the numbers in examples here are from such projects), but you can easilyextend this technique t o multiperson projects. Probe can estimate the size and timeof any task type (the number of slides in a presentation, the time to prepare it; th enumber of people t o attend a meeting, the length of the meeting, and so on).

6.4.3 A technique for simple estimationThis book is about approaches th at work a t work. Sometimes the most powerful approach is also a simple one. I've found value in a straightforward estimation tech-nique that does not require past data. Instead it uses the idea of a low, high, andmost likely estimate for any quant ity (size, time, difficulty, and so on) [Putnam 19921.Figure 6.32 gives the equations for this technique. The first produces an estimatefrom a low, high, and most likely ranking. The s tandard dev ia t ion for the estimatecomes from the low and high estimates.

% error indicates the confidence in the estimate on the basis of the standard de-viation and estimate. If this value is 20 percent or higher, the estimate needs morework. A large difference between high and low signifies to o many unknowns. Breakthe item being estimated into smaller, more manageable, less risky parts a n d deriveestimates for the parts . Repeat thi s process until the percentage of error is near 10percent.The final three equations show how t o combine estimates for many parts. This

gives a final estimate for an enti re project as well as the percentage of error. Again, ifthe percentage of error is to o high, rework the estimate.This simple, quick, and effective estimating method works well if past data is notavailable. However, laziness should not be your motivation for using it if such data isavailable.

Estimate = L o w + 4'Most Likely + Hieh Total Estimate = ZEstimate6

Standard D eviation = Hi gh. L ow Total Standard =S qua re r w t@ (Standard Deviation))6 Deviation

% Error = Standard DeviationEstimateFigure6.32Simple estimation.

X Error Total =To tal Standard DeviationTotal Estimate

6.4.4 JudReviewingyou must r19961. Figuto meet in

Flgure6.33A

Figure6.34


18/22

possibleHum-studentrecordingthet o get a

c a ngive form

can easilyand timeit; the

ap-high, and19921.estimateestimate

de-ds mor eBreak

nd derivenear 10!PhisAgain, if

is notis

PLANN ING 1636.4.4 Judging an estimateReviewing an estimate is a necessary part of planning. If the estimate is insufficient,you must revise it. Figure 6.33 gives a checklist for reviewing estimates [Park June19961. Figure 6.34 [Park Ju ly 19961 gives a list that each organization should striveto meet in its estimating efforts.

1.Are the objectives of the estimates clear a n d correct?2. Has the t a s k been appropriately sized?3. Are the estimated cost and schedule consistent with

demonstrated accomplishments on oth er projects?4. Have the factors that affect the estimate beenidentified an d explained?

5. Have steps been taken t o ensure the integrity of theestimating process?6. Is the organization's historical evidence capable of

supporting a reliable estimate?7. Has the situation changed since the estimate w a s prepared?Figure6.33A checklist for reviewing an estimate.

Six Requisites for Reliable Estimating Proced ures1.A corporate memory (historical database).2. Structured processes for estimating product size and reuse.3. Mechanisms for extrapolating from demonstrated accomplishmentson past projects.4. Audit tra ils (values for the cost model parameters used to produceeach estimate a re recorded and explained).5. Integrity in dealing with dictated costs and schedules (imposedanswers are acceptable only when legitimate design-to-costor

build-to-cost processes are followed).6.Date collection and feedback processes that foster capturing andcorrectly interpreting dat a from work performed).Seven Indicators ofEstimating Capability1.Management acknowledges its responsibility for developing and2. The estimating function is supported by a budget and funds.3. Estimators have been equipped with the tools and training needed4 . The people assigned as estimators are experienced and capable.5.Recognition and career paths exist such that qualified people want6. Estimators work with process improvement teams to quantify and7. The estimating capability of the organization is quantified, tracked,

sustaining an estimation capability.

for reliable estimating.

to serve as estimators.track progress in software process improvement.and evaluated.

Flgure 6.34An organizationaland capability checklist for reliable estimating.


19/22

164 THE SOFTWARE PROJECT MANAGERS HANDBOOK

6.4.5 Tailoring techniques to the processmodelEach project will use the basic task network, cards on the wall, and estimating tech-niques, but the order, time, and way in which they are used will vary across projects.Most of the variance stems from the process model being used.

In the next sections I give examples of how you can tailor the use of these tech-niques to the particular process model. Each example revolves around a softwarecompany that employs 10 people. It has been doing banking applications for the lastdecade and has changed as th e computing industry has changed (mainframes to ne tworks of PCs, text-based interact ion to GUIs). A primary customer is 80 percent of ibbusiness. The software company wants to grow by serving new customers. Assumethat in each case you ar e the project manager.Waterfall project. Your primary customer wants a new report capability. This issimilar t o many of the projects youve done in the past . You and your customer knowthe product well, so you select the straight waterfall process.

Use the basic techniques in a straightforward manner. List the deliverables andcreate a work breakdown structure (WBS) for each (analysis, high-level design, low-level design, build, test, and integrate and test). Put these task cards on a wall in aninitial task network. Hold a half-day cards-on-the-wall session t o refine the task net-work. Use Probe t o estimate product size for each task and the time required t o buildit. Sum these t o get a total for the project. Use the Rayleigh model t o check the va-lidity of your estimate.Execute the plan. This is a simple process for a simple product

Evolutionary project. A small, young accounting firm, th at heard about youthrough your primary customer, asks you t o develop a complete accounting systemfor their business. Your company is not familiar with accounting businesses and theaccounting firm is not sur e what they want and need.This project requires an evolutionary process. Figure 6.35 shows three evolution-ary plans. The top plan is the generic view of evolutionary projects using a series ofV-charts.The next plan is the first plan for the project. You must work down t o the x tolearn the customers requirements. Yo u can then design, build, test, and integratethe requirements i n which the customer has the most confidence. That brings yo u tothe second x , where work stops.The next area of the plan is unknown. At the second

x , everyone will know more about the product, and work will continue with greaterconfidence. The endpoint of the project (far right) is known. Work will stop at thattime or when th e allotted funds run out.

Work out the details of this first plan. Treat this first, short evolution as a com-plete project. List the deliverables, make a WBS, lay out the initial task network,hold a cards-on-the-wall session, use Probe on each task, and check it all with theRayleigh model.Execute the plan until you reach the second x . At this point everyone is smarter,and the project is far less risky. Calculate the time and money left to go beforereaching the final limit. Decide if th e project should continue. Maybe this is just notgoing t o work, o r maybe the customer knows enough now t o buy some shrink-wrapped applications.

Flgure6.3If thediagramgrate thetions ast o ProbeExecuDetermiwith thethey sotions anIf thenal limi

techniquThister 7 fobasics r

char t anSpiral businesties. Atyou arebusinewill ganess t owastedproach


20/22

these tech-fo r the last

its

isw

in annet-t o buildk th e va-

eries ofthe x to

you t ogreaterthat

s a com-the

just not

GenericEvolutions

1.Plan 4

lJnbowvn\'\

Seeand -man ',

PLANNING 165

r

,-I\, past New Plan Unknown"$,, /i" \,\ ,/ \ \ \ ~ ~ /\ r

Figure 6.35 Planning an evolutionary project.If the decision is t o continue, plan the next tw o evolutions. The second plan (lastdiagram in Figure 6.35)shows this. Each evolution will design, build, test, and inte-grate the requirements with the highest level of confidence. Trea t these tw o evolu-

tions as two complete projects. Start with the deliverables and a W BS and go throughto Probe and th e Rayleigh model.

Execute these two evolutions. This brings you t o the third x in the second plan.Determine the time and money left before the final limit. Is the customer satisfiedwith the current product? Are they so happy they want t o extend the final limit? Arethey so disappointed they want t o quit now and cut the ir losses? Answer these ques-tions and make a decision.

If the situation is satisfactory, plan evolutions that will take the project t o the fi -nal limit. Tre at each evolution as a project and reapply the planning and estimationtechniques.This was a risky project with many unknowns-many invisible items. (See Chap-

ter 7 for more details on managing risky projects.) A disciplined application of projectbasics removed the unknowns one at a time. The invisible became visible. The V-chart and the planning and estimating techniques let you work through the difficulties.Spiral project. A local, well-established printing company wants t o expand theirbusiness by adding image processing, photographic processing, a nd graphics capabili-ties. At least they think this is what they want. They are somewhat uncertain, andyou are uncertain about attempting t he work. Your people know neither the printingbusiness nor image and photographic processing. However, if this works, th e printerswill gain market share and your company will have a new, very popular line of busi-ness to offer customers. On the other hand, if it does not work, everyone will havewasted time and money and damaged their reputation. The two of you agree t o ap-proach this as partners and share costs .


21/22

166 THE SOFTWARE PROJECT MANAGER'S HANDBOOKThis is a risky project that could fail at several distinct points. The spiral processis the best choice here because, as described below, it contains plans for severalpoints a t which management can decide t o quit. Figure 6.36 shows a spiral for thisproject (see also the discussion of Figures 6.7 through 6.9). This is a generic spiralexcept for the products given in the third o r lower right quadrant. These are th e de-sired products of each cycle. The first product is a concept of the final system. If th efirst spiral can produce a concept (every product in a spiral is a big iD, the project ca n

move on and your task becomes filling in the blanks. If not, stop the project. The see.ond spiral attempts t o find algorithms for image and photographic processing. If youcan find these algorithms, you will attempt t o write processing subroutines in t h enext cycle. If the processing works, the next cycle will explore how the users will usethe system. Its goal is to determine the type of user interface required. If everythingworks in the first four cycles, the fifth cycle will be a straight waterfall process tobuild the system.Begin planning by sketching the spiral. Estimate a time period and cos t for eachcycle. This is a rough estimate and gives everyone an idea of what the entire projectmight cost. Plan the first cycle as if it were a complete project whose deliverable is asystem concept. Build a WBS and go through all the steps as in the previous exam-ples. Limit the product so that the cycle will end before you spend too much t ime an d

money.

Objectives,Constraints,Alternatives /'/'Evaluate Risksfor Each Alternative

system /Plan the Validat/Review RisksNext Cycle Build the ProductCommit or Stop of this Cycle

Executnext cyclecomplete acceptablemates? Dosuing? Ifthe experiAll thesuing cycl

The prth e custommiddle. Tno t a disa

t h i s plan

6.5 CoThe projeplanning,Project plments an

Thereother thater 2 andfor th at b

That tthe projemaintainith e baseliCM plan.The p

work. Thof producthe CM psound judcompletedaily. It iect, Projedo so hav

The Cpracticallonger th1 ies of the

6.6 St1i All-in-onunderstanFigure6.36Planning with a spiral process


22/22

e spiral processfor severalthisspiralse are t he de-If thethe project can

ing. If youin the. If everything

cost for eachentire projectis a

ch time and

P L A N N I N G 167Execute the first cycle as planned. At the end of it, the fourth quadrant, plan thenext cycle and update the rough plan for the entire spiral. Treat the next cycle a s a

complete project and work through all the planning and estimating steps. Reviewthis plan and the history of the first cycle in detail. Was the product of the first cycleacceptable?How close were the actual time and expense of the first cycle to the esti-mates? Do you and your customer think this business opportunity is still worth pur-suing? If it is, continue t o the next cycle. If not, quit now. Everyone is smarter fromthe experience and no one has wasted to o much time and money.

All the remaining cycles ar e like the first. Execute them as planned; plan the en-suing cycle; review everything, and decide whether to continue or stop.The project may reach the end of the final cycle and deliver the new capabilities t othe customer. It is entirely possible th at a spiral project will stop somewhere in themiddle. That is its nature . If the project stops, however, it will be because of a plan,

no t a disaster.

6.5 Configuration managementThe project plan belongs in the functional baseline. It fits here because requirements,planning, and risk management revolve around each other in timing and people.Project planning itself, however, does not fall neatly into one baseline like require-ments and design because planning crosses many baselines.

There isnt much t o say about putting the project plan into the functional baselineother than to do it, following the process set forth in the projects CM plan (see Chap-ter 2 and Appendix B). The functional baseline and the Configuration Control Boardfor that baseline already exist; as project manager, you need only initiate action.That there is not much t o say illustrates t he simple power of CM. At this point inthe project, the project manager does not have t o search for people interested inmaintaining the functional baseline. They are already designated in the CM plan asthe baselines CCB. All tha t remains t o bring the product to the people is t o follow theCM plan.The project plan contains information that changes often, such as the task net-

work. The project manager will need t o reestimate the duration of tasks and the sizeof products a t regular intervals as wel l as rearrange tasks in the network. However,the CM plan is designed so that the project manager and the CCB must exercisesound judgment in how they incorporate changes t o the project plan. As tasks arecompleted, some on time, others early, and others late, the schedule changes-almostdaily. It is easy to enter schedule changes into a commercial product (Microsoft Proj-ect, Project Scheduler, and others). It is not easy t o track every change. Attempts todo so have always frust rated me.The CM plan empowers the CCB t o control their baseline the way they see fit. Apractical method is to put the project plan into the baseline monthly for projectslonger than a year (twice monthly for shorter projects). The CM staff must keep cop-ies of the plan for each month.

6.6 StandardsAll-in-one military and commercial standards are available t o help project managersunderstand the necessary tasks. An IEEE standard can help in documentation.

Phillips_-_The_Software_Project_Managers_Handbook_-_sec_6.3-6.4

Documents