1 / 47

Requirements Engineering

Requirements Engineering. PROJECT MANAGEMENT Part II. Estimating costs: early calculations. $4. Range of cost estimates after conceptualization phase, based on actual cost of $1. Conceptual- ization phase. $1. 25c. Range of cost estimates after requirements analysis phase. Requirements

ondrea
Download Presentation

Requirements Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Engineering PROJECT MANAGEMENT Part II

  2. Estimating costs: early calculations

  3. $4 Range of cost estimates after conceptualization phase,based on actual cost of $1 Conceptual- ization phase $1 25c Range of cost estimates after requirements analysis phase Requirements analysis $1 Design $1 Range of Errors in Estimating Eventual Cost Implementation $1 Integration/Test $1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. Software Cost Estimation • Costs • Hardware and software • Travel and Training • Work effort • Overhead loading factor • Other factors • Market opportunity • Nose in the door • Cost estimate uncertainty • Contractual terms e.g. retained rights • Volatility • Financial Health

  5. Software Cost Estimation • Productivity effect • Size • LOSC/Month • Executable only • All loc • Level of the language • Function • Function point count • Language independent • Based on • External input and outputs • User interactions • External interfaces • Files used by the system • Un-adjusted Function point count • Sum of like elements times complexity count • Adjusted by other factors • Degree of reuse • Degree of distribution • Productivity • Etc ……..

  6. Costs - productivity • Object Counts • When 4gl and higher level language used • Count objects (not to be confused with object classes) • Object points • Screens produced - 1-3 • Number of reports 2/5/8 • Number of 3GL modules to be developed to support 4GL 10 points • Function point + Code estimation • Code size = AVC x FPC • 4GL 2-40 loc/fp • Asm 200-300 loc/fp • Java 53 loc/fp

  7. Cost estimation techniques • Techniques • Expert Judgment • Experience based • Algorithmic • Model developed

  8. Expert Judgment

  9. Cost estimation • Cost estimation • Techniques continued • Estimation by analogy • Parkinson’s law (work expands to fill the time available) • Time avail x people available (12 mo’s X 5 people = 60 person months) • Not good can get in trouble big time • Pricing to win • ditto

  10. Typical Cost Estimation Roadmap 1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code. and / or 1B. Use function point method to estimate lines of code 1B.1 Compute un-adjusted function points. 1B.2 Apply adjustment process. 2. Use lines of code estimates to compute labor and duration using COCOMO formulas. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  11. Steps in FP method • Identify functions in the system • Compute each functions contribution • Apply difficulty factors to each function • Compute the general characteristic contributions (weights) • Calculate the adjusted function point total

  12. Step 2 Function Point Computation for a Single Function (IFPUG) External Inquiries (EIN) Internal Logical Files (ILF)* Function Logical group of user data Logical group of user data Logical group of user data External Outputs (EO) External Inputs (EI) External Logical Files (ELF) file * Internal logical grouping of user data into files file file

  13. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) PARAMETERsimplecomplex Ext. inputsEI… 3 or… 4 or ...6 = ___ Ext. outputs EO … 4 or … 5 or ...7= ___ countTotal

  14. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) PARAMETERsimplecomplex Ext. inputsEI… 3 or… 4 or ...6 = ___ Ext. outputs EO … 4 or … 5 or ...7= ___ Ext. inquiriesEIN… 3 or … 4 or ...6= ___ Int. logical files ILF ... 7 or …10 or ... 15= ___ Ext. logical files ELF ... 5 or …7 or ... 10= ___ countTotal

  15. Unadjusted Function Point Computation for First Encounter Functions:“Set up Player Character” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  16. Unadjusted Function Point Computation for Second Encounter Functions: “Encounter Foreign Character” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  17. General Characteristics for FP Adjustment 1-7 incidental average essential 0 1 2 3 4 5 1. Requires backup/recovery? 0-2 2. Data communications required? 0-1 3. Distributed processing functions? 0 4. Performance critical? 3-4 5. Run on existing heavily utilized environmt.? 0-1 6. Requires on-line data entry? 5 7. Multiple screens for input? .... Continued 4-5 Case study none moderate significant

  18. General Characteristics for FP Adjustment 8-14 incidental average essential 0 1 2 3 4 5 Case study none moderate significant 8. Master fields updated on-line? 3-4 9. Inputs, outputs, inquiries of files complex? 1-2 10. Internal processing complex? 1-3 11. Code designed for re-use? 2-4 12. Conversion and installation included? 0-2 13. Multiple installation in different orgs.? 1-3 14. Must facilitate change & ease-of-use by user? 4-5

  19. Computation of Adjusted Function Points (IFPUG) (Adjusted) Function points = [ Unadjusted function points(41) ]r [ 0.65 + 0.01r( total general characteristics ) ] 41 x [0.65 + 0.01 x (24 to 41))] = 36 to 43 Loc = (36 to 43) x 53 =1.9 to 2.3 loc (java)

  20. Estimating effort and duration from lines of code

  21. Basic COCOMO Formulae (Boehm) Effort in Person-months = aKLOC b Duration = c Effort d Organic – stand alone Embedded – hardware software systems Semi detached - mix Software Project a b c d Organic 2.4 1.05 2.5 0.38 Semidetached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32 Due to Boehm [Bo]

  22. Computing COCOMO Case Study ModelsVERY EARLY ESTIMATES Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. Later revisions to estimate • Need to account for • Product reliability and complexity (RCPX) • Reuse required (RUSE) • Platform difficulty (PDIF) • Personnel Capability (PERS) • Personnel Experience (PREX) • Schedule (SCED) • Facilities (FCIL) • Effort =a x Kb x M • M=(RCPX)(RUSE)(PDIF)(PERS)(PREX)(SCHED)(FCIL)

  24. Estimate Cost and Duration Very Early in Project 1. Use the function point method to estimate lines of code 2. Use Boehm’s formulas to estimate labor required 3. Use the labor estimate and Boehm’s formula to estimate duration Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  25. The Team Software Process

  26. TSP Launch Issues to Settle(Humphrey) • Process to be used • Quality goals • Manner of tracking quality goals • How team will make decisions • What to do if quality goals not attained • fallback positions • What to do if plan not approved • fallback positions • Define team roles • Assign team roles Graphics reproduced with permission from Corel.

  27. To Be Produced at Launches (Humphrey) 1. Written team goals 2. Defined team roles 3. Process development plan 4. Quality plan 5. Project’s support plan computers, software, personnel etc. 6. Overall development plan and schedule 7. Detailed plans for each engineer 8. Project risk assessment 9. Project status report

  28. TSPi Cycle Structure (Humphrey) 1 1 1 1 1 1 Week 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Cycle 1 launch Delivery Milestones Cycle 2 launch Cycle 3 launch 1. strategy 2. plan 3. requirements 4. design 5. implementation 6. test 7. postmortem Iteration 1 Iteration 2 1. strat. 1. strategy…. Iteration 3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  29. The Software Project Management Plan

  30. IEEE 1058.1-1987 SPMP Table of Contents 1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization 2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities . . . .

  31. IEEE 1058.1-1987 SPMP Table of Contents 3.2 Assumptions, dependencies & constraints 3.3 Risk management 3.4 Monitoring & controlling mechanisms 3.5 Staffing plan 4. Technical process 4.1 Methods, tools & techniques 4.2 Software documentation 4.3 Project support functions 5. Work packages, schedule & budget 5.1 Work packages 5.2 Dependencies 5.3 Resource requirements 5.4 Budget & resource allocation 5.5 Schedule 1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization 2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities

  32. Quality in project management

  33. Defects detected per ... ... 100 requirements, or ... design diagram, or ... KLOC This project / norm Phase in which defects detected Detailed require-ments Design Implemen- tation Phase containing defects Detailed requirements 2 / 5 0.5 / 1.5 0.1 / 0.3 Design 3 / 1 1 / 3 Implementa-tion 2 / 2 Table 2.5 Defects by Phase Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  34. Five Process Metric Examples Compare each of the followingwith company norms averaged over similar processes. 1. Number of defects per KLOC detected within x weeks of delivery 2. Variance in schedule on each phase actual duration - projected duration projected duration 3. Variance in costactual cost - projected cost projected cost 4. Total design time / total programming time should be at least 50% (Humphry) 5. Defect injection and detection rates per phase e.g. “1 defect per class in detailed design phase” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  35. IEEE 739-1989 Software Quality Assurance Plans Table of Contents Part 2 of 2 7. Test -- can reference Software Test Documentation 8. Problem reporting & corrective action 9. Tools, techniques and methodologies -- can reference SPMP 10. Code control -- reference SCMP 11. Media control 12. Supplier control 13. Records collection, maintenance & retention 14. Training 15. Risk Management -- can reference SPMP

  36. One way to ... Gather Process Metrics 1. Identify & define metrics team will use by phase; include ... time spent on 1. research, 2. execution, 3. review … size (e.g. lines of code) … # defects detected per unit (e.g., lines of code) include source … quality self-assessment of each on scale of 1-10 maintain bell-shaped distribution 2. Document these in the SQAP 3. Accumulate historical data by phase 4. Decide where the metric data will be placed • as the project progresses SQAP? SPMP? Appendix? 5. Designate engineers to manage collection by phase • QA leader or phase leaders (e.g., design leader) 6. Schedule reviews of data for lessons learned • Specify when and how to feed back improvement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  37. Requirements Document: 200 detailed requirements Meeting Research Execution Personal Review Inspection Hours spent 0.5 x 4 4 5 3 6 % of total time 10% 20% 25% 15% 30% % of total time: norm for the organization 15% 15% 30% 15% 25% Self-assessed quality 1-10 2 8 5 4 6 Defects per 100 N/A N/A N/A 5 6 Defects per 100: organization norm N/A N/A N/A 3 4 Hours spent per detailed requirement 0.01 0.02 0.025 0.015 0.03 Hours spent per detailed requirement: organization norm 0.02 0.02 0.04 0.01 0.03 Process improvement Improve strawman brought to meeting Spend 10% more time executing Summary Productivity: 200/22 = 9.9 detailed requirements per hour Probable remaining defect rate: 6/4´[organizational norm of 0.8 per hundred] = 1.2 per 100 Table 2.6 Project Metric Collection for phases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  38. Process improvement and the Capability Maturity Model

  39. Motor control applications Process Waterfall Spiral, 2-4 iterations Spiral, 5-10 iterations Company average -- Defects per thousand source lines of code at delivery time injected at ... ... requirements time 4.2 3.2 2.4 ... architecture time 3.1 2.5 3.7 ... detailed design time 1.1 1.1 2.2 ... implementation time 1.0 2.1 3.5 TOTAL 9.4 8.9 11.8 Table 2.7 Example of Process Comparison Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  40. One way to ... Feed Back Process/Project Improvement 1. Decompose the process or sub-process being measured into Preparation, Execution and Review • include Research if learning about the procedure 2. Note time taken, assess degree of quality for each part on a 1-10 scale, count defects • try to enforce a curve 3. Compute quality / (percent time taken) 4. Compare team’s performance against existing data, if available 5. Use data to improve next sub-process • note poorest values first e.g., low quality/(percent time) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  41. For each part ... Preparation Execution Review % time 45 30 25 Quality (0 to 10)* If low, investigate 6 2 investigate 6 Quality/(% time) If low, investigate 0.13 investigate 0.07 investigate 0.24 Typical? No Joe lost specs Yes Yes Action Schedule 20% more time for execution, taken equally from other phases Table 2.8 Measuring Team Phase Performance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  42. Miscellaneous tools and techniques for project management Model

  43. Remote Team Options • Same office area + ideal for group communication - labor rates sub-optimal • Same city, different offices communication fair • Same country, different cities - communication difficult + common culture • Multi-country - communication most difficult - culture issues problematical + labor rates optimal Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  44. Limited customer contact Central up-front design Build for the future too Complex implementation Tasks assigned Developers in isolation Infrequent integration Limited communication Customer on team Open evolving design Evolve; just in time Radical simplicity Tasks self-chosen Pair programming Continuous integration Continual communication Non-Extreme vs Extreme Programming Adapted from Andserson, A., et al, "At Chrysler, Objects Pay", Distributed Computing, October 1998

  45. Triage in Project Management • Among top items in importance? • if so, place it in do at once category • otherwise Could we ignore without substantially affecting project? • if so, place it in last to do category • otherwise (do not spend decision time on this) • place in middle category Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  46. Summary of the project management process

  47. Summary • Project management: “silver bullet”? • “People” aspects co-equal technical • Specify SPMP • Define and retire risks • Estimate costs with several methods • expect to revisit and refine • use ranges at this stage • Schedule project with appropriate detail • Maintain a balance among cost, schedule, quality and functionality Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

More Related