Module1_Part2 Software Engineering, chapter 2.pptx

Module 1, Chapter 2, Process Models. Software Engineering: A Practitioner's Approach, 7/e
by Roger S. Pressman

1. Chapter 2 ‹#› Process Models Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman

2. Software process from a technical point of view? Software process as a framework for the activities, actions, and tasks that are required to build high-quality software. Software Process Software Engineering A software process defines the approach that is taken as software is engineered. Along with the process, it also encompasses technologies that populate the process—technical methods and automated tools.

3. A Generic Process Model ‹#› Each framework activity is populated by a set of software engineering actions. Each software engineering action is defined by a task set that identifies - the work tasks that are to be completed, - the work products that will be produced, - the quality assurance points that will be required, and - the milestones that will be used to indicate progress.

4. Process Flow It describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time.

5. Process Flow ‹#›

6. A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment. An iterative process flow repeats one or more of the activities before proceeding to the next. An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software. A parallel process flow executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software).

7. Defining a Framework Activity For a small software project requested by one person (at a remote location), the work tasks (the task set) that this action encompasses are: 1.Make contact with stakeholder via telephone. 2.Discuss requirements and take notes. How does a Framework activity change as the nature of the project changes? 3.Organize notes into a brief written statement of requirements. 4.E-mail to stakeholder for review and approval.

8. Defining a Framework Activity For considerably more complex with many stakeholders, each with a different set of (sometime conflicting) requirements, the communication activity might have six distinct actions: inception, elicitation, elaboration, negotiation, specification, and validation. Each of these software engineering actions would have many work tasks and a number of distinct work products.

9. 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

10. 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— a consistent method for describing problem solutions within the context of the software process. By combining patterns, a software team can solve problems and construct a process that best meets the needs of a project.

11. Patterns can be defined at any level of abstraction. In some cases, a pattern might be used to describe a problem (and solution) associated with a complete process model (e.g., prototyping). In other situations, patterns can be used to describe a problem (and solution) associated with a framework activity (e.g., planning) or an action within a framework activity (e.g., project estimating) .

12. Template for Process Pattern Pattern Name: The pattern is given a meaningful name describing it within the context of the software process (e.g., Technical Reviews). Forces: The environment in which the pattern is encountered and the issues that make the problem visible and may affect its solution.

13. ‹#› Process Pattern Types Stage patterns —defines a problem associated with a framework activity for the process. Ex: establishing communication Task patterns —defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice. Ex: Requirements gathering Phase patterns —define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature. Ex: Spiral Modeling or Prototyping

14. Initial context : Describes the conditions under which the pattern applies. Prior to the initiation of the pattern: (1) What organizational or team-related activities have already occurred? (2) What is the entry state for the process? (3) What software engineering information or project information already exists? For example, the Planning pattern (a stage pattern) requires that (1) customers and software engineers have established a collaborative communication; (2) successful completion of a number of task patterns [specified] for the Communication pattern has occurred; and (3) the project scope, basic business requirements, and project constraints are known.

15. Problem: The specific problem to be solved by the pattern. Solution : Describes how to implement the pattern successfully. This section describes how the initial state of the process (that exists before the pattern is implemented) is modified as a consequence of the initiation of the pattern. It also describes how software engineering information or project information that is available before the initiation of the pattern is transformed as a consequence of the successful execution of the pattern.

16. Resulting Context: Describes the conditions that will result once the pattern has been successfully implemented. Upon completion of the pattern: (1) What organizational or team-related activities must have occurred? (2) What is the exit state for the process? (3) What software engineering information or project information has been developed?

17. Related Patterns: Provide a list of all process patterns that are directly related to this one. This may be represented as a hierarchy or in some other diagrammatic form. For example, the stage pattern Communication encompasses the task patterns: ProjectTeam, CollaborativeGuidelines, ScopeIsolation, RequirementsGathering, ConstraintDescription, and ScenarioCreation.

18. Known Uses and Examples : Indicate the specific instances in which the pattern is applicable. For example, Communication is mandatory at the beginning of every software project, is recommended throughout the software project, and is mandatory once the deployment activity is under way.

19. Process patterns provide an effective mechanism for addressing problems associated with any software process. The patterns enable you to develop a hierarchical process description that begins at a high level of abstraction (a phase pattern). The description is then refined into a set of stage patterns that describe framework activities and are further refined in a hierarchical fashion into more detailed task patterns for each stage pattern. Once process patterns have been developed, they can be reused for the definition of process variants—that is, a customized process model can be defined by a software team using the patterns as building blocks for the process model.

20. Process Assessment and Improvement The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term quality characteristics. Process patterns must be coupled with solid software engineering practice. In addition, the process itself can 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. A number of different approaches to software process assessment and improvement have been proposed over the past few decades.

21. 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]

22. 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?

23. The Waterfall Model ‹#›

24. The V-Model ‹#›

25. The Incremental Model ‹#›

26. Evolutionary Models: Prototyping ‹#› Construction of prototype communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

27. Evolutionary Models: The Spiral ‹#›

28. Evolutionary Models: Concurrent ‹#›

29. Still Other Process Models ‹#› Component based development —the process to apply when reuse is a development objective Formal methods —emphasizes the mathematical specification of requirements AOSD —provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process —a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

30. The Unified Process (UP) ‹#› elaboration inception

31. UP Phases ‹#›

32. UP Work Products ‹#›

33. 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. ‹#›

34. 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.