Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said

1. Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said

2. Models and Modeling Software System • Model (Webster): • A description or analogy used to help visualize or analyze something; a pattern of something to be made • For us is representation of an aspect of software development based on a set of assumptions • Models may use other models as part of their assumptions (e.g.., COCOMO uses multiplicativeregression, WinWin uses Theory W)

3. SoftwareModels Success Models • Win-Win • Business Case Analysis • Software Warranties • QFD • 10X • Six Sigma • Award Fees . IKIWISI • JAD Product Models Process Models • UML • CORBA •COM • Requirements • Architectures • Product Lines • OO Analysis & Design • Domain Ontologies • COTS • GOTS • Spiral • Waterfall • Open Source • Business Process Reengineering • CMM’s • Peopleware • IPT’s • Agile • Evolutionary • COCOMO • COCOTS • Checkpoint • System Dynamics . Metrics . ilities • Simulation and Modeling . Environment Property Models

4. Assumptions and Models Assumption:A statement that is taken for granted as “true” Example: COCOMO cost drivers are multiplicative Model:a consistent set of assumptions and their logical derivations that represent a viewpoint Example: COCOMO represents the effort “viewpoint” of a project. It has another assumption that states effort is proportional to (SIZE)E. Hence the logical “AND” implies that effort is proportional to the cost drivers AND (SIZE)E Note:these assumptions are only taken to be true with respect to the COCOMO model itself

5. Model-Clash: An incompatibility among the assumptions of a set of models Example: IKIWISI (I’ll know it when I see it) success model assumes requirements are generated after something is implemented (prototype) Waterfall process model assumes nothing is implemented until requirements are specified. There is no model in which both of above statements are consistent (there is at least an implementation or a requirement that can not satisfy both) • Yet many projects embrace both models and get into trouble • Need techniques to identify and avoid model clashes • USC-CSE MBASE approach one way to do this

6. Example: London Ambulance Service • Year: 1991 • a computer system to replace the entiremanual system for scheduling of ambulances for 999 calls • time scale 12 months • intended budget of $2.2 million • Complex problem: • 300 ambulances • >400 patient transport service vehicles • >326 paramedics • 1,300 - 1,600 emergency calls per day

7. Example: London Ambulance Service • LAS required a system able to support: • input & verification of call and incident details, • selection of most suitable ambulances, • communication of incident details to selected ambulances, and • forward planning to place vehicles and staff at positions where they are most likely to be required.

8. Example: London Ambulance Service

9. Example: London Ambulance Service

10. Example: London Ambulance Service

11. Example: London Ambulance Service

12. Example: London Ambulance Service

13. Example: London Ambulance Service

14. Research Strategy

15. Software Models Focus

16. Assumptions Coverage Testing&Tran. Organizations Requirements Environment Maintenance Architecture Project Size Developer Customer Change

17. Assumptions Coverage Testing&Tran. Organizations Requirements Environment Maintenance Architecture Project Size Developer Customer Change Document Completeness Knowability Testability Feasibility Stability Validity Clarity *Part based on SEI risk Taxonomy

18. Multi-Model Clashes Example Waterfall COTS System requirements are fully specified prior to design and implementation stages COTS capabilities determine many of the software system's requirements COTS product capabilities may impose additional requirements on the system being developed Requirements are sufficiently testable The requirements’ nature will change little during development and evolution. Much of requirements evolution are driven by COTS (even during development) All design decisions are clearly justifiable Schedule allows enough calendar months to progress sequentially COTS vendor claims cannot be counted on as requirements Minimum changes are introduced once each phase deliverables are approved A COTS product’s internal architecture is not always visible to external developers Interfaces to other software or hardware are completely defined Results of original COTS testing process are not visible to external developers COTS vendor is economically viable COTS vendor is sufficiently responsive to requests for new features and improvements COTS integration issues are not predictable in advance

19. Multi-Model Clashes Example Waterfall COTS System requirements are fully specified prior to design and implementation stages COTS capabilities determine many of the software system's requirements COTS product capabilities may impose additional requirements on the system being developed Requirements are sufficiently testable The requirements’ nature will change little during development and evolution. Much of requirements evolution are driven by COTS (even during development) All design decisions are clearly justifiable Schedule allows enough calendar months to progress sequentially COTS vendor claims cannot be counted on as requirements Minimum changes are introduced once each phase deliverables are approved A COTS product’s internal architecture is not always visible to external developers Interfaces to other software or hardware are completely defined Results of original COTS testing process are not visible to external developers COTS vendor is economically viable COTS vendor is sufficiently responsive to requests for new features and improvements COTS integration issues are not predictable in advance Capabilities, conditions, and constraints for each requirement are clearly identifiable early in the development process Full architecture analysis is performed with respect to the quality attributes of the system System maintenance and operation are sufficiently feasible High-Assurance

20. Business-Case Fast time to market Waterfall COTS System requirements are fully specified prior to design and implementation stages COTS capabilities determine many of the software system's requirements COTS product capabilities may impose additional requirements on the system being developed Requirements are sufficiently testable The requirements’ nature will change little during development and evolution. Much of requirements evolution are driven by COTS (even during development) All design decisions are clearly justifiable Schedule allows enough calendar months to progress sequentially COTS vendor claims cannot be counted on as requirements Minimum changes are introduced once each phase deliverables are approved A COTS product’s internal architecture is not always visible to external developers Interfaces to other software or hardware are completely defined Results of original COTS testing process are not visible to external developers COTS vendor is economically viable COTS vendor is sufficiently responsive to requests for new features and improvements COTS integration issues are not predictable in advance Capabilities, conditions, and constraints for each requirement are clearly identifiable early in the development process Full architecture analysis is performed with respect to the quality attributes of the system System maintenance and operation are sufficiently feasible High-Assurance

21. Requirements Assumptions/Model Clashes • Models in left column will clash with models in right column

22. Research Contribution • Assumptions and model-clashes of the most common software engineering models • An insight into model-clashes properties: (causes, patterns, relations) • Processes and visualization techniques for rapid model-clash identification • The relation between model-clashes and risk in software projects

23. Schedule Task

24. Questions