9/24/2011 Sof o tw t a w re e P roc o e c s e s s s Mo M d o e d l e s l 1 Wh W a h t t i s i s a Pr P oc o ess s 2 1

Transcription

1 Software Process Models 1 What is a Process 2 1

2 What is a Process? Given input, transforms it into output Consist of a set of activities Ordering among the activities (a partial order) Software Process Also called methodology sometimes People are everything Involves use of resources, such as??? Software process models ~~ software lifecycle models Process descriptions are also specifications Should be as complete, consistent and clear 3 Why Software Process? Quality of product Quality of Process Garbage in garbage out, so get the right requirements P roc e ss Product So, know the input sources, specify process & specify product 4 2

3 Why Software Process? What? A software process - a series of predictable steps that leads to a timely, high-quality product. Who? Managers, software engineers, and customers. Why? Provides stability, control, and organization to an activity otherwise chaotic activity. Steps? A handful of activities are common to all software processes, details vary. Work product? Programs, documents, and data. Correct process? Assessment, quality deliverable. 5 A Layered Technology Software Engineering tools methods process model a quality focus 6 3

4 Software process A Process Framework Process framework Umbrella activities framework activity #1 task sets task sets SE action #1.1 work tasks work products QA points milestones SE action #1.2 work tasks work products QA points milestones framework activity #2 task sets task sets SE action #2.1 work tasks work products QA points milestones SE action #2.2 work tasks work products QA points milestones 7 Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management 8 4

5 Framework Activities Communication Planning Modeling Analysis of requirements Design Construction Code generation Testing Deployment 9 Software lifecycle models: Generic software process models The waterfall model Separate and distinct phases of specification and development Incremental development (w. evolutionary) Each increment represents one functionality; Specification and development can be interleaved The Spiral model Each loop in the spiral represents an incremental phase in the process. Reuse-based development The system is assembled from existing components 10 5

6 Waterfall model 1 [aka Royce Separate and distinct phases of specification and development [aka Royce1970] Systems Engineering Software Req. Analysis Operation/Maintenance Project Planning Design Implementation Testing/Verification Release 11 Requirements definition Waterfall model 2 [Sommerville [Sommerville2000] System and software design Implementation and unit testing Integration and system testing Operation and maintenance 12 6

7 Waterfall model pros and cons Inflexible partitioning of the project into distinct stages This makes it difficult to respond to changing customer requirements This model is only appropriate when the requirements are well-understood Big design up front - time spent early on making sure that requirements and design are correct is very useful in economic terms (it will save you much time and effort later) Simplicity and controllability 13 Incremental development Define outline requirements Assign requirements to increments Design system architecture Develop system increment Validate increment System incomplete Integrate increment Validate system Final system Development and delivery is broken down into increments Each increment delivers part of the required functionality Requirements are prioritised and the highest priority requirements are included in early increments Once the development of an increment is started, the requirements are frozen Requirements for later increments can continue to evolve 14 7

8 Incremental development advantages System functionality is available earlier and customer does not have to wait as long Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure The highest priority system services tend to receive the most testing 15 Spiral development Process is represented as a spiral rather than as a sequence of activities with backtracking Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required Risks are explicitly assessed and resolved throughout the process 16 8

9 Spiral Model Deter mine objectives alternatives and constraints Plan next p hase REVIE W Require ments plan Life-cycle plan Develop ment plan Integration and test p lan Risk analys is Risk analys is Risk analys is Prototype 2 Risk analysis Prototype 1 Concept of Operation S/W require ments Require ment validation Design V&V Serv ice Accep tance test Evaluate alternatives identify, resolve risks Prototype 3 Operational protoype Simulations, models, bench marks Product design Code Unit test Integr ation test Detailed design Develop, verif y next-level product 17 Reuse-oriented development Based on systematic reuse where systems are integrated from existing components Process stages Component analysis Requirements modification System design with reuse Development and integration Becoming important but still limited experience with it Requirements specification Component analysis Requirements modification System design with reuse Development and integration System validation 18 9

10 The CMMI The CMMI defines each process area in terms of specific goals and the specific practices required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific practices refine a goal into a set of process-related related activities. 19 Capability Maturity Model [SEI] Developed in 1986 with leadership from the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU), CMU-SEI. For assessing and improving software processes As a guidance for measuring software process maturity Standard, Consistent process Predictable process Continuously Improving process 5 - Optimizing 4 - Managed 3- Defined Disciplined process 2 - Repeatable 1 - Initial 20 10

11 CMMI-SE/SW/IPPD/SS - Staged Optimizing (5) Organizational Innovation and Deployment (OID) Causal Analysis and Resolution (CAR) Quantitative Management (2 PAs) Process Standardization (11 PAs) Basic Project Management (7 PAs) Initial (1) Managed (2) Defined (3) Quantitatively Managed (4) Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control (PMC) Supplier Agreement Management (SAM) Measurement and Analysis (M&A) Process and Product Quality Assurance (PPQA) Configuration Management (CM) Ad hoc, chaotic processes Organizational Process Performance (OPP) Quantitative Project Management (QPM) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organization Training (OT) Integrated Project Management (IPM) * Risk Management (RSKM) Decision Analysis and Resolution (DAR) 21 Some CMM Observations The number of companies using CMM to assess their software management practices more than doubles every 5 years Software Quality Assurance is the biggest obstacle for organizations trying to move from level 1 to level 2. Organization Process Definition is one of the biggest obstacles for organization trying to move from level 2 to level 3. On average, it takes an organization: 25 months to move from level 1 to 2 22 months to move from level 2 to months to move from level 3 to

12 Some CMM Observations Only 1.2% of companies engaged in CMM have IT departments with over 2000 employees. Of these large companies, 40% are at CMM levels 3, 4 or 5. About 80% of companies engaged in CMM have IT departments with less than over 300 employees. Of these smaller companies, 21% are at CMM levels 3, 4, or 5. About 1/3 of companies engaged in CMM are located overseas (primarily India), and are 3 times more likely to reach CMM level 4 or 5 than US organizations. Only about 23% of organizations surveyed eventually move from level 2 to level 3 or higher. 23 Software Process Variability Software processes may vary radically from one organization to another Factors contributing to this variability include Technical maturity Disciplinary involvement Organizational culture Application domain There is therefore no ideal software engineering process 24 12

13 Process Assessment The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment options are available: SCAMPI CBA IPI SPICE ISO 9001: Assessment and Improvement Software Process identifies modifications to is examined by identifies capabilities and risk of Software Process Assessment Software Process Improvement leads to leads to Capability Determination motivates 26 13

14 The Primary Goal of Any Software Process: High Quality Remember: High quality project timeliness Why? Less rework! 27 14