Value Model Clash Analysis

Transcription

1 Value Model Clash Analysis Mohammed Al-Said Annual Research Review USC-CSE March 2003

2 Research Overview Problem Currently, many software models exist Each model is based on certain assumptions Many software projects embrace models with conflicting assumptions and get into trouble Little information exist about the problem of model clashes Research: Develop technique(s) to identify model clashes Determine the relationship between model clashes and risk Value: Reduce software project risk and rework

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

4 Model Clashes SpiderWeb Users Value Propositions Acquirers Value Propositions Many features Changeable Requirements Applications Compatibility High levels of Service Voice in acquisition Flexible Contract Early Availability PD PD PD PP PC PC PP SS PP SS SS PC PC Mission: cost/effectivness Limited budget, schedule Government standards Compliance Political correctness Development visibility & control Rigorous contract Ease of of Transition Ease of Maintenance Applications Compatibility Voice in acquisition PD PD PD PC PC PP PD PC PC PD Flexible contract Ease of meeting budget & schedule Stable requirements Freedom of choice: Process Freedom of choice: Team Freedom of choice: COTS/reuse Maintainers Value Propositions Developers Value Propositions

5 Examples of Conflicting Assumptions Model Waterfall COTS Assumption Complete requirements are specified in advance of system design and implementation: Frozen requirements COTS product(s) capabilities and structures constrain system requirements and architectures Consequence: Unnecessary custom software development Change of requirements

6 Examples of Conflicting Assumptions Model High Assurance COTS Assumption System testing ensures against failure presentation under different operational circumstances COTS maintenance and evolution are out of the control of the customer, developer, and user. Consequence: Degradation to system s reliability and availability System s long term viability

7 Examples of Conflicting Assumptions Model RAD COTS Assumption System development is tightly scheduled (i.e. timeboxed) Development schedule allows enough time to assess, evaluate, and integrate COTS product(s) Consequence: Select the wrong COTS product Schedule impact Functionality impact Aesop Example: 6 Months --> 2 Years

8 Model Assumptions Identification Approach Model Category 1 Category 2... Category N Attribute1 Attribute1... AttributeN Attribute1 Attribute1... AttributeN... Attribute1 Attribute1... AttributeN

9 Model Assumptions Identification Taxonomy Requirements Architecture & Design Completeness Stability Feasibility Clarity Documentation Stability Functionality Difficulty Interfaces Documentation Feasibility Time frame Coverage Early Functionality Software Model Coding-Testing- Integration-Transition Maintenance Environment Developer Customer Traceability Evolveability Documentation SW/HW Constraints Facilities Quality Assurance Configuration Management Change Management Experience Technical Skills Communication Skills Representation Knowledge Availability Cooperation

10 Classification of Models Based on Assumptions Conflicts Waterfall Fixed-reqts/cost/schedule contract Formal derivation and verification Waterfall Fixed rqts./cost/schedule contract Waterfall Formal derivation and verification Assume Yes Milestone planning Requirements Aspect Completely specified in advance of design and development Low risk of infeasibility Highly Stable Evolutionary development Agile methods COTS-assessmentintensive system Stakeholder win-win Spiral Cost/schedule as independent process Heterogeneous COTS elements Assume No Evolutionary development Agile methods Cost/schedule as Models in left column will clash with models in right column independent process

11 Relationship between Model Clashes and Risk Risk Pair <Probability of loss, Size of loss> answers: I. What is the likelihood that unsatisfactory outcome will occur? II. If unsatisfactory outcome occurs, what is the measure of loss? Model-Clash Pair <Occurrence Probability, Severity>?

12 Model Clashes Occurrence Probability & Severity CeBASE Data Base Fall2000-Spring2002 Projects Weekly Progress Reports Project Top 10 Risks Assumptions Models Model Clashes Stakeholders Frequency Severity Occurrence Probability

13 Mode Clashes Occurrence Probability & Severity: Example Assumptions S M OP SV Developer needs extensive, on demand user/customer interaction User/Customer are available at limited times Dev User/ Cust SS SS 0.82 M User/Customer are free to add/modify system requirements during the system implementation Changes/additions to system requirements require extra budget and schedule User/ Cust Dev PD PP 0.46 H

14 Formulating Risk Statement using Model Clashes* If Models Clash then there is potential harmful (Time) Consequence (risk) Formally: xyzw model(x) model(y) assumption(x,z) assumption(y,w) clash(z,w) v consequence(clash(z,w),v) where (x y w z v) * Builds on CMU-SEI Risk Management work

15 Model Clashes Co-occurring Consequences co-occurring consequence set assumptions Schedule overrun Business Case: Developer implements the product in 12 months Budget overrun COCOMO: 20 months are needed to implement the product Unsatisfied customer Formally: xyzw model(x) model(y) assumption(x,z) assumption(y,w) clash(z,w) v1 vn ((consequence(clash(z,w),v1) consequence(clash(z,w),v2) consequence(clash(z,w),vn) ) where (x y z w v1 v2 vn)

16 Model Clashes Cascade Consequences assumptions Waterfall: Complete requirements are specified in advance of system design and implementation COTS: Requirements are flexible and negotiable till COTS is selected clash Late requirements cascade consequence set Late development Lost product benefits Formally: xyzw model(x) model(y) assumption(x,z) assumption(y,w) clash(z,w) v1 vn ((consequence(clash(z,w),v1) consequence(clash(z,w),v2) consequence(clash(z,w),vn) ) where (x y z w v1 v2 vn)

17 Value of Model Clashes Identification and Avoidance Risk Reduction - LCO and LCA Milestones Total Risk Exposure = n i=1 MC i (PL * SL) LCO LCA Projects

18 Distribution of Clashes between Software Models Model Clashes Types Distribution Product-Product Product-Process 4% 3% 3% Product-Property 30% 16% Product-Success Process-Process Process-Property 4% 6% Property-Property 7% 13% 16% Success-Property Success-Success Success-Process

19 Distribution of Clashes between Software Models 3 % Success Models 7 % 3 % Process Models 6 % 4 % 13 % 30 % Product Models 4 % Property Models 16 % 16 %

20 Contribution of Model Clashes Types to Software Project Risk Contribution of Model Clash Types to Project Risk Product-Product 9% 10% 8% 2% 24% Product-Process Product-Property Process-Process Process-Property 13% 3% 7% 18% 6% Property-Property Success-Property Success-Product Success-Process Success-Success

21 Contribution of Inter and Intra Model Clashes to Project Risk Contribution of Inter and Intra Model Clashes to Project Risk 100 % Total Risk Inter Model Clashes Intra Model Clashes

22 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 modelclash identification 4. The relation between model-clashes and risk in software projects

23 Questions?