Tweet
Tweet

Slide 1

Slide 1 text

jgs CSE 563 Software Requirements and Specification Lecture 24: COCOMO Dr. Javier Gonzalez-Sanchez [email protected] javiergs.engineering.asu.edu | javiergs.com PERALTA 230U Office Hours: By appointment

Slide 2

Slide 2 text

jgs Fall 2021 | 00000001 Announcements § All midterm grades are posted. § Midterms Exams are open for ASU Sync Students. § I am publishing Frequently Asked Questions on Canvas, and I will be advising you to read it when applying. § Statistics – Over the last years, 5 exams were updated (~300 students). Grade changes less than 3%. For instance, 74.7 moved to 75.9. Updates can go up or down.

Slide 3

Slide 3 text

jgs Fall 2021 | 00000001 Announcements § The final Exam is on December 5 (As scheduled by ASU) “three exams in one day” is possible and not considered a conflict

Slide 4

Slide 4 text

jgs Fall 2021 | 00000001 Final Project § User Stories in Taiga (Backlogs) § Sprint(s) § Tasks and their responsible (Taskboard) § Daily report (Burndown Chart) § Source Code § JavaDoc (Classes and Methods) § UML Class Diagram (Recommended but not mandatory). If you create one, include it in your submission.

Slide 5

Slide 5 text

jgs Fall 2021 | 00000001 We are here Burndown Chart

Slide 6

Slide 6 text

jgs Fall 2021 | 00000001 Sprint(s) Review and Retrospective

Slide 7

Slide 7 text

jgs Fall 2021 | 00000001 Final Project § User Stories in Taiga (Backlogs) § Sprint(s) § Tasks and their responsible (Taskboard) § Daily report (Burndown Chart) § Source Code § JavaDoc (Classes and Methods) § UML Class Diagram (Recommended but not mandatory). If you create one, include it in your submission. § Sprint(s) Retrospective – A document about your team and team process § Sprint(s) Review - A document about the product (complete? Missing parts?)

Slide 8

Slide 8 text

jgs Fall 2021 | 00000001 Advice • Take Screenshots of your Taiga – Showing dates, names, etc. • Back up your code. • You are a self-organized team. TAs are not responsible for you

Slide 9

Slide 9 text

jgs Where we are?

Slide 10

Slide 10 text

jgs Fall 2021 | 00000001 Where we are? Product Requirement Task As a (role), I want (feature), So that (benefit) … move the pacman … show the pacman … move a ghost … show a ghost … show power pills features tasks (new)

Slide 11

Slide 11 text

jgs Fall 2021 | 00000001 Where we are? § How many hours (time)? § Or How many people?

Slide 12

Slide 12 text

jgs Fall 2021 | 00000001 Where we are? Timer KeyListener JFrame ActionListener Game Ghost Pacman Maze Drawable PowerDot JPanel

Slide 13

Slide 13 text

jgs Fall 2021 | 00000001 Where we are? Timer KeyListener JFrame ActionListener Game Ghost Pacman Maze Drawable PowerDot JPanel Software Design (CSE 564)

Slide 14

Slide 14 text

jgs Javier Gonzalez-Sanchez | SER332 | Spring 2018 | 16

Slide 15

Slide 15 text

jgs Fall 2021 | 00000001 Where we are? § How many hours (time)? § Or How many people? VS § How many lines of code?

Slide 16

Slide 16 text

jgs Constructive Cost Model Cocomo

Slide 17

Slide 17 text

jgs Fall 2021 | 00000001 COCOMO § The constructive cost model was developed by Barry Boehm (the Spiral model guy) in the late 1970 and published in Software Engineering Economics. § It is a model for estimating effort, cost, and schedule for software projects. § It drew on a study of 63 projects at TRW Aerospace. § The study examined projects ranging in size from 2,000 to 100,000 lines of code and diverse programming languages. § These projects were based on the waterfall model of software development (prevalent in 1981).

Slide 18

Slide 18 text

jgs Fall 2021 | 00000001 Regression-Based Model

Slide 19

Slide 19 text

jgs Fall 2021 | 00000001 COCOMO § The constructive cost model was developed by Barry Boehm (the Spiral model guy) in the late 1970 and published in Software Engineering Economics. § It is a model for estimating effort, cost, and schedule for software projects. § It drew on a study of 63 projects at TRW Aerospace. § The study examined projects ranging in size from 2,000 to 100,000 lines of code and diverse programming languages. § These projects were based on the waterfall model of software development (prevalent in 1981). Software Project, Process, & Quality Management (CSE 566)

Slide 20

Slide 20 text

jgs Fall 2021 | 00000001 COCOMO II

Slide 21

Slide 21 text

jgs Fall 2021 | 00000001 COCOMO II Web Tool by USC http://softwarecost.org/tools/COCOMO/

Slide 22

Slide 22 text

jgs Fall 2021 | 00000001 Factors of development cost 1. Software Size (Lines of Code) 2. Software Scale Drivers: sources of exponential effort variation 3. Software Cost Drivers: sources of linear effort variation. They group in 4 categories: product, platform, personnel and project Factor are rated between very low and very high per rating guidelines

Slide 23

Slide 23 text

jgs Fall 2021 | 00000001 COCOMO II - Inputs

Slide 24

Slide 24 text

jgs Fall 2021 | 00000001 Scale Drivers Rating Scale Factors (Wi ) Very Low Low Nominal High Very High Extra High Precedentedness (PREC) thoroughly unprecedented largely unprecedented somewhat unprecedented generally familiar largely familiar throughly familiar Development Flexibility (FLEX) rigorous occasional relaxation some relaxation general conformity some conformity general goals Architecture/Risk Resolution (RESL)* little (20%) some (40%) often (60%) generally (75%) mostly (90%) full (100%) Team Cohesion (TEAM) very difficult interactions some difficult interactions basically cooperative interactions largely cooperative highly cooperative seamless interactions Process Maturity (PMAT) Weighted average of “Yes” answers to CMM Maturity Questionnaire * % significant module interfaces specified, % significant risks eliminated

Slide 25

Slide 25 text

jgs Fall 2021 | 00000001 COCOMO II - Inputs

Slide 26

Slide 26 text

jgs Fall 2021 | 00000001 Cost Drivers | Product Factors 1.1. Required Reliability (RELY) 1. 2. Data Base Size (DATA) 1. 3. Complexity (CPLX) 1. 4. Developed for Reusability (RUSE) 1. 5. Documentation (DOCU)

Slide 27

Slide 27 text

jgs Fall 2021 | 00000001 Cost Drivers | Personnel factors 2.1 Analyst capability (ACAP) 2.2 Programmer (Software Engineer) capability (PCAP) 2.3. Applications experience (APEX) 2.4. Platform (or VM) experience (PLEX) 2.5. Language and tool experience (LTEX) 2.6. Personnel continuity (PCON)

Slide 28

Slide 28 text

jgs Fall 2021 | 00000001 Cost Drivers | Platform Factors 3.1. Time constraint (TIME) 3.2. Storage constraint (STOR) 3.3. Platform volatility (PVOL)

Slide 29

Slide 29 text

jgs Fall 2021 | 00000001 Cost Drivers | Project Factors Project Factors 4.1. Use of Software tools (TOOL) 4.2. Multisite development (SITE) 4.3. Required schedule - stretch-out or acceleration (SCED) Multisite development

Slide 30

Slide 30 text

jgs Test Yourselves

Slide 31

Slide 31 text

jgs Fall 2021 | 00000001 Pacman § It has 1200 LOC § Nothing to be reuse § What could be its cost in the best-case scenario? § What could be its cost in the worse-case scenario? § What is the best-case scenario? (value for the factors) § What is the worse-case scenario? (value for the factors)

Slide 32

Slide 32 text

jgs Fall 2021 | 00000001 Questions

Slide 33

Slide 33 text

jgs Fall 2021 | 00000001 Reference § Somerville, Chapter 23

Slide 34

Slide 34 text

jgs Appendix A: Product Factors

Slide 35

Slide 35 text

jgs Fall 2021 | 00000001 1.1. Required Reliability (RELY) § Measures the extent to which the software must perform its intended function over a period of time. § Ask: what is the effect of a software failure? Very Low Low Nominal High Very High Extra High RELY slight inconvenience low, easily recoverable losses moderate, easily recoverable losses high financial loss risk to human life

Slide 36

Slide 36 text

jgs Fall 2021 | 00000001 1.2. Data Base Size (DATA) § Captures the effect large data requirements have on development to generate test data that will be used to exercise the program § Calculate the data/program size ratio (D/P): DatabaseSize(bytes) / ProgramSize (LOC) Very Low Low Nominal High Very High Extra High DATA DB bytes/ Pgm SLOC < 10 10 £ D/P < 100 100 £ D/P < 1000 D/P > 1000

Slide 37

Slide 37 text

jgs Fall 2021 | 00000001 1.3. Product Complexity (CPLX) It is divided into five areas: 1. control operations, 2. computational operations, 3. device-dependent operations, 4. data management operations, and 5. user interface management operations. Select the area or combination of areas that characterize the product or a sub-system of the product. Use a subjective weighted average of the attributes, weighted by their relative product importance.

Slide 38

Slide 38 text

jgs Fall 2021 | 00000001 1.3. Product Complexity (CPLX) Very Low Low Nominal High Very High Extra High Control Operations Straightline code with a few non- nested structured programming operators: DOs, CASEs, IFTHENELSEs. Simple module composition via procedure calls or simple scripts. Straightforward nesting of structured programming operators. Mostly simple predicates. Mostly simple nesting. Some intermodule control. Decision tables. Simple callbacks or message passing, including middleware- supported distributed processing. Highly nested structured programming operators with many compound predicates. Queue and stack control. Homogeneous, dist. processing. Single processor soft real- time ctl. Reentrant and recursive coding. Fixed-priority interrupt handling. Task synchronization, complex callbacks, heterogeneous dist. processing. Single- processor hard real- time ctl. Multiple resource scheduling with dynamically changing priorities. Microcode- level control. Distributed hard real- time control. Computational Operations Evaluation of simple expressions: e.g., A=B+C*(D-E) Evaluation of moderate-level expressions: e.g., D=SQRT(B**2- 4.*A*C) Use of standard math and statistical routines. Basic matrix/vector operations. Basic numerical analysis: multivariate interpolation, ordinary differential eqns. Basic truncation, roundoff concerns. Difficult but structured numerical analysis: near-singular matrix equations, partial differential eqns. Simple parallelization. Difficult and unstructured numerical analysis: highly accurate analysis of noisy, stochastic data. Complex parallelization. Very Low Low Nominal High Very High Extra High Device- dependent Operations Simple read, write statements with simple formats. No cognizance needed of particular processor or I/O device characteristics. I/O done at GET/PUT level. I/O processing includes device selection, status checking and error processing. Operations at physical I/O level (physical storage address translations; seeks, reads, etc.). Optimized I/O overlap. Routines for interrupt diagnosis, servicing, masking. Communication line handling. Performance-intensive embedded systems. Device timing- dependent coding, micro-programmed operations. Performance- critical embedded systems. Data Management Operations Simple arrays in main memory. Simple COTS- DB queries, updates. Single file subsetting with no data structure changes, no edits, no intermediate files. Moderately complex COTS-DB queries, updates. Multi-file input and single file output. Simple structural changes, simple edits. Complex COTS-DB queries, updates. Simple triggers activated by data stream contents. Complex data restructuring. Distributed database coordination. Complex triggers. Search optimization. Highly coupled, dynamic relational and object structures. Natural language data management. User Interface Management Simple input forms, report generators. Use of simple graphic user interface (GUI) builders. Simple use of widget set. Widget set development and extension. Simple voice I/O, multimedia. Moderately complex 2D/3D, dynamic graphics, multimedia. Complex multimedia, virtual reality.

Slide 39

Slide 39 text

jgs Fall 2021 | 00000001 1.4 Required Reusability (RUSE) Accounts for the additional effort needed to construct components intended for reuse. Very Low Low Nominal High Very High Extra High RUSE none across project across program across product line across multiple product lines

Slide 40

Slide 40 text

jgs Fall 2021 | 00000001 1.5. Documentation (DOCU) Level of required documentation. Very Low Low Nominal High Very High Extra High DOCU Many life-cycle needs uncovered Some life-cycle needs uncovered Right-sized to life- cycle needs Excessive for life- cycle needs Very excessive for life-cycle needs

Slide 41

Slide 41 text

jgs Appendix B: Personal Factors

Slide 42

Slide 42 text

jgs Fall 2021 | 00000001 2.1. Analyst Capability (ACAP) Analysts work on requirements, high level design and detailed design. Consider analysis and design ability, efficiency and thoroughness, and the ability to communicate and cooperate. Very Low Low Nominal High Very High Extra High ACAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile

Slide 43

Slide 43 text

jgs Fall 2021 | 00000001 2.2. Programmer Capability (PCAP) Evaluate the capability of the programmers as a team rather than as individuals. Consider ability, efficiency and thoroughness, and the ability to communicate and cooperate. Very Low Low Nominal High Very High Extra High PCAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile

Slide 44

Slide 44 text

jgs Fall 2021 | 00000001 2.3. Applications Experience (AEXP) Assess the project team's equivalent level of experience with this type of application. Very Low Low Nominal High Very High Extra High AEXP £ 2 months 6 months 1 year 3 years 6 years

Slide 45

Slide 45 text

jgs Fall 2021 | 00000001 2.4. Platform Experience (PEXP) Very Low Low Nominal High Very High Extra High PEXP £ 2 months 6 months 1 year 3 years 6 year Assess the project team's equivalent level of experience with this platform including the OS, graphical user interface, database, networking, and distributed middleware.

Slide 46

Slide 46 text

jgs Fall 2021 | 00000001 2.5. Language and Tool Experience (LTEX) Measures the level of programming language and software tool experience of the project team. o Very Low Low Nominal High Very High Extra High LTEX £ 2 months 6 months 1 year 3 years 6 years

Slide 47

Slide 47 text

jgs Fall 2021 | 00000001 2.6. Personnel Continuity (PCON) The scale for PCON is in terms of the project's annual personnel turnover. Very Low Low Nominal High Very High Extra High PCON 48% / year 24% / year 12% / year 6% / year 3% / year

Slide 48

Slide 48 text

jgs Appendix C: Platform Factors

Slide 49

Slide 49 text

jgs Fall 2021 | 00000001 3.1. Time Constraint (TIME) Measures the constraint imposed upon a system in terms of the percentage of available execution time expected to be used by the system. Very Low Low Nominal High Very High Extra High TIME £ 50% use of available execution time 70% 85% 95%

Slide 50

Slide 50 text

jgs Fall 2021 | 00000001 3.2. Storage Constraint (STOR) § Measures the degree of main storage constraint imposed on a software system or subsystem. § Given the remarkable increase in available processor execution time and main storage, one can question whether these constraint variables are still relevant. However, many applications continue to expand to consume whatever resources are available, making these cost drivers still relevant. Very Low Low Nominal High Very High Extra High STOR £ 50% use of available storage 70% 85% 95%

Slide 51

Slide 51 text

jgs Fall 2021 | 00000001 3.3. Platform Volatility (PVOL) Assesses the volatility of the platform, i.e., the complex of hardware and software the software product calls on to perform its tasks Very Low Low Nominal High Very High Extra High PVOL major change every 12 mo.; minor change every 1 mo. major: 6 mo.; minor: 2 wk. major: 2 mo.; minor: 1 wk. major: 2 wk.; minor: 2 days

Slide 52

Slide 52 text

jgs Appendix D: Project Factors

Slide 53

Slide 53 text

jgs Fall 2021 | 00000001 4.1. Use of Software Tools (TOOL) Assess the usage of software tools used to develop the product in terms of their capabilities and maturity. Software tools have improved significantly since the 1970's projects used to calibrate COCOMO. The tool rating ranges from simple edit and code, very low, to integrated lifecycle management tools, very high. Very Low Low Nominal High Very High Extra High edit, code, debug simple, frontend, backend CASE, little integration basic lifecycle tools, moderately integrated strong, mature lifecycle tools, moderately integrated strong, mature, proactive lifecycle tools, well integrated with processes, methods, reuse

Slide 54

Slide 54 text

jgs Fall 2021 | 00000001 4.2. Multisite Development (SITE) Assess and average two factors: site collocation and communication support. Very Low Low Nominal High Very High Extra High SITE: Collocation International Multi-city and Multi-company Multi-city or Multi-company Same city or metro. area Same building or complex Fully collocated SITE: Communications Some phone, mail Individual phone, FAX Narrowband email Wideband electronic communication Wideband elect. comm, occasional video conf. Interactive multimedia

Slide 55

Slide 55 text

jgs Fall 2021 | 00000001 4.3. Required Schedule (SCED) Measure the imposed schedule constraint in terms of the percentage of schedule stretch-out or acceleration with respect to a nominal schedule for the project. Very Low Low Nominal High Very High Extra High SCED 75% of nominal 85% 100% 130% 160%

Slide 56

Slide 56 text

jgs CSE 563 Software Requirements and Specification Javier Gonzalez-Sanchez, Ph.D. [email protected] Fall 2021 Copyright. These slides can only be used as study material for the class CSE563 at ASU. They cannot be distributed or used for another purpose.