1. University of Southern California Center for Software Engineering C S E USC Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said

2. University of Southern California Center for Software Engineering C S E USC 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 multiplicative regression, WinWin uses Theory W)

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

4. University of Southern California Center for Software Engineering C S E USC 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. University of Southern California Center for Software Engineering C S E USC 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. University of Southern California Center for Software Engineering C S E USC Year: 1991 a computer system to replace the entire manual 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 Example: London Ambulance Service

7. University of Southern California Center for Software Engineering C S E USC 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. Example: London Ambulance Service

8. University of Southern California Center for Software Engineering C S E USC Example: London Ambulance Service Business CaseWaterfallConsequence Implement a state of the art system within 12 months to meet government ambulance performance standards Schedule allows enough calendar months to move sequentially Dictated schedule was too tight to develop and test the system

9. University of Southern California Center for Software Engineering C S E USC Example: London Ambulance Service Business CaseHigh-AssuranceConsequence Select lowest bidderDeveloper is experienced and knowledgeable in developing similar systems Developer had no previous experience in implementing ambulance dispatch systems

10. University of Southern California Center for Software Engineering C S E USC Example: London Ambulance Service High-AssuranceWaterfallConsequence Fall back procedures exist in case of failure or service degradation Full system testing including backup system was not performed Back-up system didn’t work when the main system failed

11. University of Southern California Center for Software Engineering C S E USC Example: London Ambulance Service Business CaseHigh-AssuranceConsequence Low cost Intel486 PCs used as main servers Design feasibility is determineable in advance (i.e., modeling, simulation) System performance degraded due to ambulance allocation algorithm’s CPU and memory demands

12. University of Southern California Center for Software Engineering C S E USC Example: London Ambulance Service RADScalabilityConsequence MS-Visual Basic used to rapidly generate system’s screens Tools scalability sufficiently matches application size and complexity System performance degraded due to early VB slowness

13. University of Southern California Center for Software Engineering C S E USC Example: London Ambulance Service EnvironmentWaterfallConsequence Data feeds from radio-based system are always perfect Requirements cover all real-world situations Buildings obscured data signals (black spots)

14. University of Southern California Center for Software Engineering C S E USC Research Strategy Case Study Analysis [LAS, MasterNet, Denver] Select a set of software models Identify models’ assumptions with respect to req., arch., maintenance, change, environment, project size, developer, customer, organization Identify model clashes among models’ assumptions Identify model clashes’ causes and patterns Assess if MBASE model integration framework identifies model-clashes early Run an experiment to establish relationship between model clashes and software project’s risk

15. University of Southern California Center for Software Engineering C S E USC Software Models Focus ProductProcess Custom COTS: Single & Multi Product Line Distributed/Mobile Waterfall Evolutionary Agile Open Source RAD PropertySuccess Scalability High-Assurance Cost (COCOMO) Environment Business Case IKIWISI Correctness Controllability

16. University of Southern California Center for Software Engineering C S E USC Assumptions Coverage Requirements Architecture Testing&Tran. Maintenance Environment Change Project Size Developer Customer Organizations Model

17. University of Southern California Center for Software Engineering C S E USC Assumptions Coverage Requirements Architecture Testing&Tran. Maintenance Environment Change Project Size Developer Customer Organizations Model Stability Feasibility Clarity Testability Document Knowability Completeness Validity *Part based on SEI risk Taxonomy

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

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

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

21. University of Southern California Center for Software Engineering C S E USC Requirements Assumptions/Model Clashes Assume Yes Requirements Aspect Assume No  Waterfall  Fixed-reqts/cost/schedule contract  Formal derivation and verification Knowable in advance of design and development  Evolutionary development  Agile methods  COTS-assessment-intensive system  Stakeholder win-win  Waterfall  Fixed rqts./cost/schedule contract Low risk of infeasibility  Spiral  Cost/schedule as independent process  Heterogeneous COTS elements  Waterfall  Formal derivation and verification  Milestone planning Highly Stable  Evolutionary development  Agile methods  Cost/schedule as independent process  Models in left column will clash with models in right column

22. University of Southern California Center for Software Engineering C S E USC Research Contribution 1.Assumptions and model-clashes of the most common software engineering models 2.An insight into model-clashes properties: (causes, patterns, relations) 3.Processes and visualization techniques for rapid model-clash identification 4.The relation between model-clashes and risk in software projects

23. University of Southern California Center for Software Engineering C S E USC Schedule Spr’0 2 Sum’02Fall’02Spr’03 4567891011121234 Complete model assumptions Identification Identify model clashes Identify model clash Causes and patterns Test MBASE model integration framework Run Model Clash Analysis Experiment Thesis Writing Defense Task

24. University of Southern California Center for Software Engineering C S E USC Questions