CSC 423 Chapter 02, Fall 2011

1 Chapter 2  Process Models 2 A Generic Process Model 3 Process Flow 4 Identifying a Task Set  A task set defines the actual work to be done to accomplish the objectives of a software engineering action.  A list of the task to be accomplished  A list of the work products to be produced  A list of the quality assurance filters to be applied 5 Process Patterns  A process pattern  describes a process-related problem that is encountered during software engineering work,  identifies the environment in which the problem has been encountered, and  suggests one or more proven solutions to the problem.  Stated in more general terms, a process pattern provides you with a template [Amb98]—a consistent method for describing problem solutions within the context of the software process. 6 Process Assessment and Improvement  Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting and learning.  CMM-Based Appraisal for Internal Process Improvement (CBA IPI) —provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment [Dun01]  SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process. [ISO08]  ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies. [Ant06] 7 Prescriptive Models  Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions …  If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change?  Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? 8 The Waterfall Model Communication Planning Modeling Construction Deployment analysis design code test project initiation requirement gathering estimating scheduling tracking delivery s upport f eedback 9 The V-Model 10 The Incremental Model C o m m u n i c a t i o n P l a n n i n g M o d e l i n g C o n s t r u c t i o n D e p l o y m e n t d e l i v e r y f e e d b a c k analys is des ign c ode t es t increment # 1 increment # 2 delivery of 1st increment delivery of 2nd increment delivery of nth increment increment # n project calendar time C o m m u n i c a t i o n P l a n n i n g M o d e l i n g C o n s t r u c t i o n D e p l o y m e n t d e l i v e r y f e e d b a c k analys is des ign c ode t es t C o m m u n i c a t i o n P l a n n i n g M o d e l i n g C o n s t r u c t i o n D e p l o y m e n t d e l i v e r y f e e d b a c k analy s is des ign c ode t es t 11 Class Activity  In groups of 2, write your names on a piece of paper:  Describe 3 increments for word-processing software developed using the incremental paradigm 12 Evolutionary Models: Prototyping Construction of prototype Communication Quick plan Construction of prototype Mode ling Quick de sign Delivery & Feedback Deployment communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback 13 Evolutionary Models: The Spiral communication planning modeling construction deployment delivery feedback start analysis design code test estimation scheduling risk analysis 14 Evolutionary Models: Concurrent Under review Baselined Done Under revision Awaiting changes Under development none Modeling activity represents the state of a software engineering activity or task 15 The Unified Process (UP) software increment Release Inception Elaboration construction transition production inception elaboration Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) 16 UP Phases Inception Elaboration Construction Transition Production UP Phases Workflows Requirements Analysis Design Implementation Test Iterations #1 #2 #n-1 #n Support 17 UP Work Products Inception phase Elaboration phase Construction phase Transition phase Vision document Initial use-case model Initial project glossary Initial business case Initial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Inc ept i o n Use-case model Supplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk list Project plan including iteration plan adapted workflows milestones technical work products Preliminary user manual Design model Software components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installation manuals description of current increment Delivered software increment Beta test reports General user feedback 18 Personal Software Process (PSP)  Planning. This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created.  High-level design. External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.  High-level design review. Formal verification methods (Chapter 21) are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.  Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.  Postmortem. Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness. 19 Team Software Process (TSP)  Build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPT) of three to about 20 engineers.  Show managers how to coach and motivate their teams and how to help them sustain peak performance.  Accelerate software process improvement by making CMM Level 5 behavior normal and expected.  The Capability Maturity Model (CMM), a measure of the effectiveness of a software process, is discussed in Chapter 30.  Provide improvement guidance to high-maturity organizations.  Facilitate university teaching of industrial-grade team skills.