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

CSE563 Lecture 24

CSE563 Lecture 24

Software Requirements and Specification
COCOMO
(202212)

Javier Gonzalez-Sanchez
PRO

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

    View Slide

  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.

    View Slide

  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

    View Slide

  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.

    View Slide

  5. jgs
    Fall 2021 | 00000001
    We are here
    Burndown
    Chart

    View Slide

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

    View Slide

  7. 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?)

    View Slide

  8. 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

    View Slide

  9. jgs
    Where we are?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. jgs
    Constructive Cost Model
    Cocomo

    View Slide

  17. 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).

    View Slide

  18. jgs
    Fall 2021 | 00000001
    Regression-Based Model

    View Slide

  19. 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)

    View Slide

  20. jgs
    Fall 2021 | 00000001
    COCOMO II

    View Slide

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

    View Slide

  22. 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

    View Slide

  23. jgs
    Fall 2021 | 00000001
    COCOMO II - Inputs

    View Slide

  24. 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

    View Slide

  25. jgs
    Fall 2021 | 00000001
    COCOMO II - Inputs

    View Slide

  26. 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)

    View Slide

  27. 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)

    View Slide

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

    View Slide

  29. 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

    View Slide

  30. jgs
    Test Yourselves

    View Slide

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

    View Slide

  32. jgs
    Fall 2021 | 00000001
    Questions

    View Slide

  33. jgs
    Fall 2021 | 00000001
    Reference
    § Somerville, Chapter 23

    View Slide

  34. jgs
    Appendix A: Product Factors

    View Slide

  35. 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

    View Slide

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

    View Slide

  37. 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.

    View Slide

  38. 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.

    View Slide

  39. 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

    View Slide

  40. 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

    View Slide

  41. jgs
    Appendix B: Personal Factors

    View Slide

  42. 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

    View Slide

  43. 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

    View Slide

  44. 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

    View Slide

  45. 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.

    View Slide

  46. 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

    View Slide

  47. 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

    View Slide

  48. jgs
    Appendix C: Platform Factors

    View Slide

  49. 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%

    View Slide

  50. 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%

    View Slide

  51. 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

    View Slide

  52. jgs
    Appendix D: Project Factors

    View Slide

  53. 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

    View Slide

  54. 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

    View Slide

  55. 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%

    View Slide

  56. 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.

    View Slide