Presentation on theme: "Requirements and Incremental Design0 2.11.1999 Contents How do requirements behave today? CMM - Capability Maturity Model - Req."— Presentation transcript:
Requirements and Incremental Design0 Johan.Sjoblom@ericsson.fi 2.11.1999 Contents How do requirements behave today? CMM - Capability Maturity Model - Req. Mgmt The Incremental Development Model Johan Sjöblom Product Area Manager Ericsson WasaLab Johan.Sjoblom@ericsson.fi
Requirements and Incremental Design1 Johan.Sjoblom@ericsson.fi 2.11.1999 How Do Requirements Behave Today? Requirements Loosen Up when moving from networks to services and applications
Requirements and Incremental Design2 Johan.Sjoblom@ericsson.fi 2.11.1999 Requirements without 50k of ITU/ETSI specs? No Microsoft type player around in Telecom?? Industry Consortiums: –Symbian, EPOC operating system, www.symbian.com –WAP Forum, www.wapforum.org –Bluetooth Other de facto standards –IETF: Req. For Comments (RFC’s) –Java API’s –W3C (HTML, XHTML, XML)
Requirements and Incremental Design3 Johan.Sjoblom@ericsson.fi 2.11.1999 CMM & Requirement Management CMM - Capability Maturity Model Levels 1-5 Level 2 is project oriented, and is called “repeatable” KPA - Key Process Areas Requirement Management is a KPA in CMM level 2
Requirements and Incremental Design4 Johan.Sjoblom@ericsson.fi 2.11.1999 CMM 2 - KPA - RM - Activity 1 The software engineering group reviews the allocated requirements BEFORE they are incorporated into the software project –4. Commitments resulting from the allocated requirements are negotiated with the affected groups.
Requirements and Incremental Design5 Johan.Sjoblom@ericsson.fi 2.11.1999 CMM 2 - KPA - RM - Activity 2 The software engineering group uses the allocated requirements as the basis for software plans, work products, and activities. –1. Allocated requirements are managed and controlled.
Requirements and Incremental Design6 Johan.Sjoblom@ericsson.fi 2.11.1999 CMM 2 - KPA - RM - Activity 3 Changes to the allocated requirements are reviewed and incorporated into the software project –1. The impact to existing commitments is assessed, and changes are negotiated as appropriate.
Requirements and Incremental Design7 Johan.Sjoblom@ericsson.fi 2.11.1999 Incremental Development ID
Requirements and Incremental Design8 Johan.Sjoblom@ericsson.fi 2.11.1999 Introduction to Incremental Development Part I Waterfall model Problems with the waterfall model Incremental Development concepts Part II Incremental Development: Benefits, Pitfalls & Concerns Experiences
Requirements and Incremental Design9 Johan.Sjoblom@ericsson.fi 2.11.1999 Waterfall model Analysis ImplementationTest time
Requirements and Incremental Design10 Johan.Sjoblom@ericsson.fi 2.11.1999 Existing Problems (1) Late feedback for customers and designers How to cope with changing requirements? Big bang integration with interface and integration problems Big Bang Integration
Requirements and Incremental Design11 Johan.Sjoblom@ericsson.fi 2.11.1999 Existing problems (2) Rush on test resources Lack of Project Control Slow process improvement “Rush on test resources”
Requirements and Incremental Design12 Johan.Sjoblom@ericsson.fi 2.11.1999 ID Process View * Divide the work in small controllable parts (= increments) * Increments must be testable parts of the system Analysis ImplementationTest Plan Integrate Plan Integrate
Requirements and Incremental Design13 Johan.Sjoblom@ericsson.fi 2.11.1999 ID System View 1246357 Each accumulation of developed increments is a complete user executable system User Functionality Platform
Requirements and Incremental Design14 Johan.Sjoblom@ericsson.fi 2.11.1999 Benefits & Pitfalls
Requirements and Incremental Design15 Johan.Sjoblom@ericsson.fi 2.11.1999 Benefits ImplementationTest Analysis waterfall incremental Analysis Implementation Test 1) Lead-time reduction
Requirements and Incremental Design16 Johan.Sjoblom@ericsson.fi 2.11.1999 Benefits 2) No ‘big bang’ integration Waterfall Incremental Development Integrate Time to solve problems Integrate
Requirements and Incremental Design17 Johan.Sjoblom@ericsson.fi 2.11.1999 Benefits 3) Handling of unstable requirements Unstable requirement Added requirement
Requirements and Incremental Design18 Johan.Sjoblom@ericsson.fi 2.11.1999 Pitfalls 1) Planning & Tracking ChargingSW Superv. HW Superv. HW Init. Statistics Traffic Load appl. Load OS Commands Allocation of features dependent of technical contents. Delay in one part of the project can on short term impact early deliveries. Planning Anatomy
Requirements and Incremental Design19 Johan.Sjoblom@ericsson.fi 2.11.1999 Pitfalls project X product baseline project Y incr. 1 2) Configuration Management incr. 1
Requirements and Incremental Design20 Johan.Sjoblom@ericsson.fi 2.11.1999 Pitfalls 3) Postponement of features
Requirements and Incremental Design21 Johan.Sjoblom@ericsson.fi 2.11.1999 Concerns More increments implies shorter design - verification cycles Extra testing –Test cases needs to be rerun in several increments –Possibility for continues system test More reviews and inspections –Documents impacted by several increments need more inspections. (simplyfied inspections from R&I)
Requirements and Incremental Design22 Johan.Sjoblom@ericsson.fi 2.11.1999 Conclusion ID solves the following problems in waterfall projects: –Late feedback / Changing requirements / Big bang integration –Rush on test resources / Lack of project control / Slow process improvement Is has been used successfully for the last decade Extra attention needed for: –Planning & Tracking –Configuration Management Increased use of testing and reviews & inspections
Your consent to our cookies if you continue to use this website.