For University Use Only Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

Chapter 5 Software Project Planning

Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Why? So the end result gets done on time, with quality!

Objectives Provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule The attempt to determine Money Effort Resources Time ++

Risk on estimation Project complexity Project size Degree of structural uncertainty Availability of historical information ++

The Steps Scoping—understand the problem and the work that must be done Estimation—how much effort? how much time? Risk—what can go wrong? how can we avoid it? what can we do about it? Schedule—how do we allocate resources along the timeline? what are the milestones? Control strategy—how do we control quality? how do we control change?

Write it Down! Project Scope Software Estimates Project Risks Plan Schedule Control strategy Software Project Plan

Software Scope Describes: Data & control Function Performance Constraints Interfaces reliability ++

To Understand Scope ... Understand the customers needs understand the business context understand the project boundaries understand the customer’s motivation understand the likely paths for change understand that ... Even when you understand, nothing is guaranteed!

Reusable software components Hardware/software tools Resources Hardware/software tools Reusable software components People People Reusable software components Hardware/software tools ++

Software Project Estimation Options: Delay estimation until late in the project Base estimates on similar projects Use relatively simple decomposition techniques to generate project cost and effort estimates Use one or more empirical models for software cost and effort estimation ++

Cost Estimation project scope must be explicitly defined task and/or functional decomposition is necessary historical measures (metrics) are very helpful at least two different techniques should be used remember that uncertainty is inherent

Estimation Techniques past (similar) project experience conventional estimation techniques task breakdown and effort estimates size (e.g., FP) estimates tools (e.g., Checkpoint)

Accuracy of Estimate The accuracy of software estimate is determined by: Estimated size of the product Ability to translate the size into effort, time and budget The ability of software team meets the project plan The stability of requirements and environment ++

Functional Decomposition Statement perform of Scope a "grammatical parse"

Creating a Task Matrix Obtained from “process framework” framework activities application functions Effort required to accomplish each framework activity for each application function

Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values use historical effort for the project

LOC/FP What do LOC & FP oriented estimation have in common? ++ Bounded statement of software scope is decomposed to be estimated individually Baseline productivity metrics (eg. LOC/PM, FP/PM) are then applied ++

LOC/FP – Differences They differ in the level of detail of decomposition and the target of partitioning For LOC estimates, decomposition focuses on software function (& its sub-functions) For FP estimates, decomposition focuses on information domain characteristics (ie, input, output, data files, inquiries, & external interfaces) ++

Expected Value S = (Sopt + 4Sm + Spess)/6 Where Sopt, Sm, Spess is optimistic, most likely and pessimistic estimates ++

Example: LOC Approach

Example: FP Approach

Tool-Based Estimation project characteristics calibration factors LOC/FP data

Empirical Estimation Models General form: exponent effort = tuning coefficient * size usually derived empirically as person-months derived of effort required usually LOC but may also be function point either a constant or a number derived based on complexity of project

Empirical Estimation Models – Examples Boehm simple model E = a * (KLOC)b D = 2.5 (E)d Coefficient table S/W Project ab bb db Organic 2.4 1.05 0.38 Semi detached 3.0 1.12 0.35 Embedded 3.6 1.20 0.32

Estimation Guidelines estimate using at least two techniques get estimates from independent sources avoid over-optimism, assume difficulties you've arrived at an estimate, sleep on it adjust for the people who'll be doing the job—they have the highest impact

The Make-Buy Decision Acquisition options: Software may be purchased (or licensed) off-the-self “full-experience” or “partial-experience” software components may be acquired and modified Software may be custom built by outside contractor ++

Decision Tree Analysis

Computing Expected Cost (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost = 0.30($380K)+0.70($450K) build = $429 K similarly, expected cost = $382K reuse expected cost = $267K buy expected cost = $410K contr

Outsourcing Software engineering activities are contracted to a third party who does the work at lower cost and, hopefully, higher quality Outsourcing decision is often a financial one +- … Positive side: cost saving Negative side: lose some control ++

Automated Estimation Tools Sizing of project deliverables Selecting project activities Predicting staffing levels Predicting software effort Predicting software cost Predicting software schedules ++