Software Project Planning SEN-269 Software Engineering Engr

Software Project Planning SEN-269 : Software Engineering Engr. Tazeen Muzammil

Project Planning The overall goal of project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost and schedule. Why? So the end result gets done on time, under budget and with quality! 2

Project Planning Task Establish project scope Determine feasibility Analyze risks (Done in previous lecture) Define required resources Determine require human resources Define reusable software resources Identify environmental resources Estimate cost and effort Decompose the problem Develop two or more estimates using size, function points, process tasks or use-cases Reconcile the estimates Develop a project schedule (Done in previous lecture) 3

Software Sope 4

What is Scope? Software scope describes the functions and features that are to be delivered to endusers the data that are input and output the “content” that is presented to users as a consequence of using the software the performance, constraints, interfaces, and reliability that bound the system. Scope is defined using one of two techniques: A narrative description of software scope is developed after communication with all stakeholders. A set of use-cases is developed by end-users. 5

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

Feasibility Once the scope has been identified, then we ask the following questions: Technology: Do we have the requisite technology. Finance: Do we have the requisite finances/budget. Resources: Do we have the requisite skilled resources. 7

Resources 8

Resources 9

Estimation 10

Estimation of resources, cost, effort and schedule requires experience access to good historical information (metrics) the courage to commit to quantitative predictions when qualitative information is all that exists Project scope must be understood Elaboration (decomposition) is necessary At least two different techniques should be used Uncertainty is inherent in the process Estimation should define Best case scenario Worst case scenario 11

Why Estimate Software? 30% of project never complete 100 -200% cost overruns not uncommon Average project exceeds cost by 90%; schedule by 120% 15% of large project never deliver anything Only 16. 2% of projects are successful 12

What are the consequences? Economic Loss of contracts Company failure Technical Dependency on software growing Managerial Change of personnel 13

Estimation Techniques Expert Judgment Estimation by Analogy Pricing to win Decomposition Techniques (e. g. LOC, FP Based ) Empirical models (e. g. COCOMO) Automated Estimation. Tools 14

Expert Judgement One or more experts in both software development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached. Pros: Little or no historical data needed. Suitable for new or unique projects. Relatively cheap method; Accurate if experts have direct experience of similar systems Cons: Very subjective. Experts may introduce bias. Larger number of experts will help to reduce bias Qualification of experts may be questioned. 15

Expert Judgement-Steps Gather a group of experts together, Describe overall program in enough detail so experts can provide an estimate. Each member of the expert group then does an independent of the resources needed. Estimates are gathered anonymously and compared, If there exists significant divergence among the estimates, the estimates will be returned to the expert group, The expert group then discusses the estimates and the divergence and works to resolve differences, and The expert group once again submits anonymous, independent estimates which continues until a stable estimate results. 16

Expert Judgement-Example Three software engineers are renown in the ERP software development. You hold interviews with each explaining the requirements, sizing level, and development process for your new system. Each member of the group submits their opinion of the final cost and the estimate converges to $50 M. 17

Estimation by Analogy Estimates costs by comparing proposed programs with similar, previously completed programs for which historical data is available. Actual costs of similar existing system are adjusted for complexity, technical, or physical differences to derive new cost estimates Analogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed approach Compares similarities and differences Focus is on main cost drivers. 18

Estimation by Analogy Pros: Inexpensive Easily changed Based on actual experience (of the analogous system) Cons: Very Subjective Large amount of uncertainty Truly similar projects must exist and can be hard to find Must have detailed technical knowledge of program and analogous system Needs systematically maintained cost database 19

Estimation by Analogy-Steps Determine estimate needs/ground rules, Define new system, Breakout new system into subcomponents for analogy estimating, Assess data availability of historical similar systems, Collect historical system component technical and cost data, Process/normalize data into constant year dollars (e. g. , constant FY 2003$), Develop factors based on prior system, Example: Program Management is 10% of total development cost Develop new system component costs. Obtain complexity (and other translation) factors Example: Historical database is for 4 million records and new database will need to house 24 million records => complexity factor of 6 (4*6 = 24) times the historical database cost Apply factors to historical costs to obtain new system costs 20

Estimation by Analogy. Example Your company is developing a new IT payroll system serving 5, 000 people and containing 100, 000 lines of C++ code. Another company developed a similar 100, 000 lines of code system for $20 M for only 2, 000 people. Your software engineers tell you that the new system is 25% more complicated than the other system. Other system development cost was $20 M. Estimated cost for new system = 1. 25 * $20 M = $25 M Plus 5, 000/2, 000, or 2. 5 * $25 M = $62. 5 M total cost 21

Pricing to win The project costs whatever the customer has to spend on it. This approach may seem unethical and un-businesslike. However, when detailed information is lacking it may be the only appropriate strategy. The project cost is agreed on the basis of an outline proposal and the development is constrained by that cost. A detailed specification may be negotiated or an evolutionary approach used for system development Advantages: You get the contract. Disadvantages: The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required. 22

Decomposition Techniques 23

Decomposition Techniques To obtain an estimation, we can decompose the problem to be solved, or decompose the process. Decomposition should be done in such a way that 1. size can be properly estimated, 2. cost or effort required for each component can be accurately estimated, 3. the team's ability to handle the components is well known, and 24

Problem-Based Estimation 1. Based on the software scope, decompose the software into problem functions that can be estimated individually. 2. Estimate LOC or FP of each function. 3. Make optimistic (sopt), most likely (sm), and pessimistic (spess) estimates for each item. Then compute the expected value: EV (Expected Value) = (sopt + 4 sm + spess)/6 4. Apply baseline productivity metrics to compute estimated cost or effort. 25

Example Problem Statement: Take the Library management system case. Software developed for library will accept data from operator for issuing and returning books. Issuing and returning will require some validity checks. For issue it is required to check if the member has already issued the maximum books allowed. In case for return, if the member is returning the book after the due date then fine has to be calculated. All the interactions will be through user interface. Other operations include maintaining database and generating reports at regular intervals. 26

Example Major software functions identified. User interface Database management Report generation For user interface EV Sopt : 1800 EV Sm : 2000 Spess : 4000 EV For database management EV Sopt : 4600 Sm : 6900 EV Spess : 8600 EV For report generation Sopt : 1200 EV Sm : 1600 EV Spess : 3200 for user interface = (1800 + 4*2000 + 4000) / 6 = 2300 for database management = (4600 + 4*6900 + 8600) / 6 = 6800 for report generation = (1200 + 4*1600 + 3200) / 6 EV = 1800 27

Lines of code (LOC) Given: LOC Estimate = 33200 LOC Productivity = 620 LOC/P-M(Person-Month) Effort = 54 P-M Labor Rate = $ 8000 P-M Cost per LOC = $ 13 P-M Effort = LOC/Productivity Project Cost= $ 431600 Cost per LOC = Labor Rate/Productivity Project Cost= LOC estimate * Cost per LOC 28

LOC-Example 29

Function Point Five information domain characteristics are determined and counts for each are provided and recorded in a table. Number Number of of of user inputs user outputs user inquires files external interfaces Once the data have been collected, a complexity value is associated with each count. Each entry can be simple, average or complex. Depending upon these complexity values is calculated. 30

Function Point Formula: FP = Count Total * [0. 65+0. 01*Sum(Fi)] Fi are complexity adjustment values based on response to questions(1 -14) given below. The constant values in the equation and the weighing factors that are applied to information domain are determined empirically. Rate each factor on a scale of 0 to 5 0 1 2 3 4 5 - No influence Incidental Moderate Average Significant Essential Count-total is sum of all FP entries. 31

Fi 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilized operational environment? 6. Does the system require on-line entry? 7. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8. Are the inputs, outputs, files, or inquiries complex 9. Is the internal processing complex? 10. Is the code designed to be reusable? 11. Are master files updated on-line? 12. Are conversion and installations included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease of use by the user? 32

Function Point Once function points have been calculated, productivity, quality, cost and documentation can be evaluated. Productivity = FP / person-month Quality = defects / FP Documentation = pages of documentation / FP Effort = FP Estimate/Productivity Cost per FP = Labor rate/Productivity Project Cost Estimate = FP * Cost per FP 33

Computing function-point metrics 34

Example (Same as LOC) Information Domain Values Opt likely Pess est Account wt FP Account Number of Inputs 4 10 16 10 4 40 Number of Outputs 4 7 16 8 5 40 Number of Inquiries 5 12 19 12 4 48 Number of Files 3 6 9 6 10 60 Number of external interfaces 2 2 3 2 7 14 Count Total 202 35

Example Complexity weighing factors are determined and the following results are obtained. Factor Value Backup Recovery 4 Data Communication 1 Distributed processing 0 Perfomance Critical 3 Existing Operating Environment 2 On-line data entry 5 Input transaction over multiple screens 5 Master file updated online 3 Information domain values complex 3 Internal processing complex 2 Code design for reuse 0 Conversion/Installation in design 1 Multiple installations 3 Application designed for change 5 Sum ( Fi ) 37 36

Example Estimated number of FP : FPestimated = count-total * [0. 65 +. 01 * sum(Fi) ] FPestimated = 206 From historical data, productivity is 55. 5 FP/person-month and development cost is $8000 per month. Productivity = FP/ person-month = FP/Productivity = 202/55. 5 = 3. 64 person-month Total Cost = Development cost * person-month = 8000 * 3. 64 =$29100 Cost per FP = Cost/FP = 29100/202 = $144. 2 per FP 37

Function Point-Example Given Productivity = 6. 5 FP/P-M Labor Rate = $8000/P-M 38

Process-based estimation Most commonly-used technique for project estimation Project is broken down into a relatively small set of tasks and the effort required to accomplish each task is estimated Begins with a delineation of software functions obtained from the project scope

Process-based estimation A series of framework activities must be performed for each function Representative framework activities: Customer communication Planning / risk analysis Engineering Construction / release Functions and activities may be shown together as a table:

Process-based estimation table Activity CC Planning Risk analysis Engineering Release CE Totals Function Anal. Design Code Test UICF 0. 75 2. 50 0. 40 5. 00 n/a 8. 65 2 DGA 0. 75 4. 00 0. 60 2. 00 n/a 7. 35 3 DGA 0. 50 4. 00 0. 60 2. 00 n/a 7. 10 CGDF 0. 50 4. 00 1. 00 3. 00 n/a 8. 50 DBM 0. 50 3. 00 1. 50 n/a 6. 00 PCF 0. 25 2. 00 0. 75 1. 50 n/a 4. 50 DAM 0. 50 2. 00 n/a 5. 00 Totals . 25 3. 50 17. 50 4. 25 15. 00 % effort 1% 1% 1% 7% 45% 12% 40% 34. 80

Process-based estimation Once functions and activities are melded, the planner estimates the effort (person-months) required to accomplish each activity per function Average labor rates are then applied to the estimated efforts (may vary per task) Cost and effort for each function and activity (row and column totals) are computed as the last step

Empirical Estimation Models An estimation model provides empirically derived formulas to predict effort as a function of LOC or FP. The data used to support these models are derived from a limited sample. Thus no model is appropriate for all classes of software. 43

Empirical models Examples of Commercially Available Models COCOMO The Software Equation COSTXPERT SLIM SEER Costar, REVIC, etc. 44

Structure of Estimation Model E = A + B XC where A, B, and C are empirically derived constants, E is the effort in person months, and X is the estimation variable, either in LOC or FP. 45

COCOMO, COnstructive COst MOdel is static single-variable model. Barry Boehm introduced COCOMO models. There is a hierarchy of these models. Model 1: Basic COCOMO model is static single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code. Model 2: Intermediate COCOMO model computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes. Model 3: Advanced COCOMO model incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step, like analysis, design, etc. COCOMO can be applied to the following software project's categories. 46

Three Software Project's Categories Organic -- a relatively small simple project in which small teams with good application experience work to a set of less than rigid requirements. Semi-detached -- an intermediate project in which teams with mixed experience must meet a mix of rigid and less than rigid requirements. Embedded -- a project that must meet tight hardware, software, and operational constraints. 47

COCOMO The COnstructive COst MOdel It is LOC-based. Formula: E = a(KLOC)b T = c. Ed where E is the effort required in person-months, T is the required development time in chronological months, KLOC is the estimated size of software in thousand lines of delivered source code. The constants a, b, c, and d are listed below: 48

The Software Equation A dynamic multivariable model E = [LOC x B 0. 333/P]3 x (1/t 4) where E = effort in person-months or personyears t = project duration in months or years B = “special skills factor” P = “productivity parameter” 49

Automated Estimation Tools The automated estimation tools allow the planner to estimate cost and effort and to perform what if analysis for important project variables such as delivery date or staffing. Six generic functions: 1. 2. 3. 4. 5. 6. Sizing of project deliverables Selecting project activities Predicting staffing levels Predicting software effort Predicting software cost Predicting software schedules 50