$30 off During Our Annual Pro Sale. View Details »

CSE563 Lecture 24

CSE563 Lecture 24

Software Requirements and Specification
COCOMO
(202212)

Javier Gonzalez-Sanchez

September 08, 2021
Tweet

More Decks by Javier Gonzalez-Sanchez

Other Decks in Programming

Transcript

  1. 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
  2. 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.
  3. 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
  4. 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.
  5. 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?)
  6. 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
  7. 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)
  8. jgs Fall 2021 | 00000001 Where we are? § How

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

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

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

    many hours (time)? § Or How many people? VS § How many lines of code?
  12. 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).
  13. 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)
  14. jgs Fall 2021 | 00000001 COCOMO II Web Tool by

    USC http://softwarecost.org/tools/COCOMO/
  15. 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
  16. 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
  17. 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)
  18. 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)
  19. jgs Fall 2021 | 00000001 Cost Drivers | Platform Factors

    3.1. Time constraint (TIME) 3.2. Storage constraint (STOR) 3.3. Platform volatility (PVOL)
  20. 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
  21. 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)
  22. 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
  23. 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
  24. 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.
  25. 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.
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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.
  32. 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
  33. 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
  34. 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%
  35. 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%
  36. 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
  37. 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
  38. 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
  39. 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%
  40. 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.