Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering Software Engineering Lecture 07 COCOMO and Function Point Analysis Prof. Dr. Ir. Riri Fitri Sari MM MSc 18 November 2011 Faculty of.

Similar presentations


Presentation on theme: "Software Engineering Software Engineering Lecture 07 COCOMO and Function Point Analysis Prof. Dr. Ir. Riri Fitri Sari MM MSc 18 November 2011 Faculty of."— Presentation transcript:

1 Software Engineering Software Engineering Lecture 07 COCOMO and Function Point Analysis Prof. Dr. Ir. Riri Fitri Sari MM MSc 18 November 2011 Faculty of Engineering University of Indonesia

2 ELH71413 2 Development process - when to do what phase - document: SPMP Management structure - hierarchical, peer,... Risk identification & retirement Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 2 Focus Corporate practices Development phases Schedule Cost estimate SPMP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3 ELH71413 3 Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 2 Focus Corporate practices Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4 8. Estimating costs: early calculations

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

6 ELH71413 6 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.

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

8 ELH71413 8 Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) Ext. inputs EI … 3 or… 4 or... 6 = ___ Ext. outputs EO … 4 or … 5 or... 7 = ___ PARAMETER simple complex countTotal

9 ELH71413 9 Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) Ext. inputs EI … 3 or… 4 or... 6 = ___ Ext. outputs EO … 4 or … 5 or... 7 = ___ Ext. inquiries EIN … 3 or … 4 or... 6 = ___ Ext. logical files ELF... 5 or …7 or... 10 = ___ Int. logical files ILF... 7 or …10 or... 15 = ___ PARAMETER simple complex countTotal

10 ELH71413 10 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.

11 ELH71413 11 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.

12 ELH71413 12 General Characteristics for FP Adjustment 1-7 1. Requires backup/recovery? 0-2 2. Data communications required? 0-1 3. Distributed processing functions? 0..... 0 incidental average essential 12345 Case study none moderate significant

13 ELH71413 13 General Characteristics for FP Adjustment 1-7 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?.... continued4-5 0 incidental average essential 12345 Case study none moderate significant

14 ELH71413 14 8. Master fields updated on-line? 3-4 9. Inputs, outputs, inquiries of files complex? 1-2 10. Internal processing complex? 1-4.... 012345 General Characteristics for FP Adjustment 8-14 incidental average essential Case study none moderate significant

15 ELH71413 15 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 012345 General Characteristics for FP Adjustment 8-14 incidental average essential Case study none moderate significant

16 ELH71413 16 Computation of Adjusted Function Points (IFPUG) (Adjusted) Function points = [ Unadjusted function points ] [ 0.65 + 0.01 ( total general characteristics ) ]

17 ELH71413 17 Unadjusted Function Point Scores for Video Store Example Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18 ELH71413 18 012345 FP Adjustment Factors for Video Example 1. Requires backup/recovery?…………………………. 4 2. Data communications required ?………...…………. 0 3. Distributed processing functions ?…………………. 0 4. Performance critical ?………………….……………. 3 5. Run on existing heavily utilized environment ?……. 1 6. Requires on-line data entry ?……………………….. 5.... none incidental moderate average significant essential

19 ELH71413 19 012345 FP Adjustment Factors for Video Example 1. Requires backup/recovery?…………………………. 4 2. Data communications required ?………...…………. 0 3. Distributed processing functions ?…………………. 0 4. Performance critical ?………………….……………. 3 5. Run on existing heavily utilized environment ?……. 1 6. Requires on-line data entry ?……………………….. 5 7. Multiple screens for input ?…………………………. 3 8. Master fields updated on-line ?…………………….. 5 9. Inputs, outputs, inquiries of files complex ?……….. 2 10. Internal processing complex ?………………………. 1 11. Code designed for re-use ?…………………………...3 12. Conversion and installation included ?…………….. 3 13. Multiple installation in different orgs. ?……………. 3 14. Must facilitate change & ease-of-use by user ?…….. 2 none incidental moderate average significant essential Total 35

20 9. Estimating effort and duration from lines of code

21 ELH71413 21 Meaning of the COCOMO Formulas (Boehm) Applies to design through integration & test. *Effort = total person-months required. (2) Duration for increasing Effort* ( y b 2.5x 0.35 ) (1) Effort* for increasing LOC ( y b 3x 1.12 ) exponent: < 1 > 1

22 ELH71413 22 Basic COCOMO Formulae (Boehm) Effort in Person-months = a KLOC b Duration = c Effort d Software Project a b c d Organic2.41.05 2.5 0.38 Semidetached3.01.12 2.5 0.35 Embedded3.61.20 2.5 0.32 Due to Boehm [Bo]

23 ELH71413 23 Computing COCOMO Case Study Models Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

24 ELH71413 24 Computing COCOMO Case Study Models Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

26 10. The Team Software Process

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

28 ELH71413 28 To Be Produced at Launches (Humphrey) 1. Written team goals 2. Defined team roles 3. Process development plan 4. Quality plan 5. Projects 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

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

30 11. The Software Project Management Plan

31 ELH71413 31 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..

32 ELH71413 32 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 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

33 12. Quality in project management

34 ELH71413 34 Defects detected per...... 100 requirements, or... design diagram, or... KLOC This project / norm Phase in which defects detected Detailed require- ments DesignImplemen- tation Phase containing defects Detailed requirements 2 / 50.5 / 1.50.1 / 0.3 Design 3 / 11 / 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.

35 ELH71413 35 Five Process Metric Examples 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 cost actual cost - projected 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 Compare each of the following with company norms averaged over similar processes. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36 ELH71413 36 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

37 ELH71413 37 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) … size (e.g. lines of code) … # defects detected per unit (e.g., lines of code) … # defects detected per unit (e.g., lines of code) include source include source … quality self-assessment of each on scale of 1-10 … 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.

38 ELH71413 38 Requirements Document: 200 detailed requirements MeetingResearchExecution Personal Review Inspection Hours spent0.5 x 44536 % of total time10%20%25%15%30% % of total time: norm for the organization 15% 30%15%25% Self-assessed quality 1-1028546 Defects per 100N/A 56 Defects per 100: organization norm N/A 34 Hours spent per detailed requirement 0.010.020.0250.0150.03 Hours spent per detailed requirement: organization norm 0.02 0.040.010.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.

39 13. Process improvement and the Capability Maturity Model

40 ELH71413 40 Motor control applications Process WaterfallSpiral, 2-4 iterations Spiral, 5-10 iterations Company average -- Defects per thousand source lines of code at delivery time injected at...... requirements time4.23.22.4... architecture time3.12.53.7... detailed design time1.1 2.2... implementation time1.02.13.5 TOTAL9.48.911.8 Table 2.7 Example of Process Comparison Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

41 ELH71413 41 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 teams 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.

42 ELH71413 42 For each part... PreparationExecutionReview % time 453025 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 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.

43 14. Miscellaneous tools and techniques for project management Model

44 ELH71413 44 Remote Team Options n Same office area + ideal for group communication - labor rates sub-optimal n Same city, different offices communication fair n Same country, different cities - communication difficult + common culture n 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.

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

46 ELH71413 46 Triage in Project Management n Among top items in importance? – if so, place it in do at once category n otherwise Could we ignore without substantially affecting project? – if so, place it in last to do category n otherwise …… Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

47 ELH71413 47 Triage in Project Management n Among top items in importance? – if so, place it in do at once category n otherwise Could we ignore without substantially affecting project? – if so, place it in last to do category n 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.

48 16. Summary of the project management process

49 ELH71413 49Summary n Project management: silver bullet? n People aspects co-equal technical n Specify SPMP n Define and retire risks n Estimate costs with several methods –expect to revisit and refine –use ranges at this stage n Schedule project with appropriate detail n 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.

50 SPMP for the Encounter video game

51 ELH71413 51 Gaming Industries Consolidated President VP EngineeringVP Marketing... IV&V EncounterGame 123... SQA Game Lab... Software Engineering Labs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

52 ELH71413 52 Member Team leader CM Leader QA leader Require- ments manageme nt leader Design leader Implementati on Leader Liaison Respon- sibility VP Engineer ing Marketing Software engineeri ng lab Docume nt Responsi -bility SPMPSCMP SQAP STP SRSSDDCode base Table 2.9 Encounter Project Responsibilities Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

53 ELH71413 53 Program Monitoring & Control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

54 ELH71413 54 Name Team Leader CM Leader. QA Leader Requ. Mngmnt Leader Design Leader Implemen- tation Leader Ed BraunX X Al Pruitt X Fern Tryfill X Hal Furnass X Karen Peters X Liaison withVP Eng. Marketing Soft. Eng. Lab Table 2.11 Encounter Staffing Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

55 ELH71413 55 Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones Delivery Complete testing Iteration 1 Iteration 2 Freeze requirements Risk I&R SCMP SQAP SPMP rel. 1 E. Braude 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 J. Pruitt 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 F. Tryfill 1 1 1 1 1 1 1 1 1 1 1 1 1 H. Furnass 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 K. Peters 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Tasks Work Breakdown Structure Excluding Secretarial TOTAL 5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 3.5 3.5 F. Smith (tech support).5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

56 ELH71413 56 Method* Mini- mum Maxi- mum Comment (1)7.5**170 (2)4.2300 (3)11.446 1.9-2.3 for two identified functions 6-20 times as many in complete application Most conservative 11.4300 Maximum of minimums and maximum of maximums. Least conservative 4.246 Minimum of minimums and minimum of maximums. Widest range 4.2300 Minimum of minimums and maximum of maximums. Narrowest range 11.446 Maximum of minimums and minimum of maximums. Table 2.12 Very Rough Estimate of Application Size Prior to Requirements Analysis Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

57 ELH71413 57 High Level Task Chart with Fixed Delivery Date: Order of Completion Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones(1 * ) Delivery Begin system testing Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk identification & retirement (5) * Indicated the order in which the parts of this table were built SCMP complete SQAP complete SPMP rel. 1 complete (2) Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

58 Software quality assurance plan Part 2 of 2

59 ELH71413 59 1. Defect Number: 2. Proposer: 3. Documents / sections affected:__________ Source code affected*: 4. package(s)_______ 5. class(es) ____6. method(s) ______ 7.Severity: ____8. Type: _____ 9. Phase injected**: Req Arch Dtld.Dsg Code Int 10. Detailed description: ___________________ 11. Resolution: ____ 12. Status closed / open:__ Sign-off: 13. Description and plan inspected: __ 14. Resolution code and test plan inspected: ___ 15. Change approved for incorporation: ______ Problem Reporting Form * for source code defects **earliest phase with the defect Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.


Download ppt "Software Engineering Software Engineering Lecture 07 COCOMO and Function Point Analysis Prof. Dr. Ir. Riri Fitri Sari MM MSc 18 November 2011 Faculty of."

Similar presentations


Ads by Google