Family: Iterative Enhancement Origin: Ivar Jacobson, James Rumbaugh, Grady Booch, 1996 Defines process framework that is adaptable to

Transcription

1 Unified Process Family: Iterative Enhancement Origin: Ivar Jacobson, James Rumbaugh, Grady Booch, 1996 Defines process framework that is adaptable to various application domains different organizations different competence levels different project sizes Characteristics: use case driven architecture-centric iterative incremental (component-based) Provides only rudimentary instructions Product: Rational Unified Process (RUP), IBM Slide 1

2 Unified Process Lifecycle Phases Core Workflows Inception Elaboration Construction Transition Requirements Analysis Design Implementation Test (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt ) Slide 2

3 Unified Process: Requirements List potential requirements Feature list Understand system context Domain model Business process model Determine functional requirements Use case model (actuators, use cases, use case descriptions, model description) Architecture view on use cases Prototypes Glossary (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt ) Determine non-functional requirements Extended use case model Supplementary requirements Slide 3

4 Unified Process: Analysis Architectural analysis Analysis package Analysis class Architecture description Analyze a use case Use case realization (analysis) Analysis class Analyze a class Analysis class Analyze a package Analysis package (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt ) Slide 4

5 Unified Process: Design Architectural design nodes and network configurations design subsystem interfaces generic design mechanisms architecture description Design a use case use case realization (design) design classes subsystems interfaces Design a class design classes (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt ) Design a subsystem subsystems interfaces Slide 5

6 Unified Process: Implementation Architectural implementation components architecture description Integrate system integration build plan implementation model Implement a subsystem implementation subsystem interfaces Implement a class components Perform unit test components (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt ) Slide 6

7 Unified Process: Test Plan Test test plan (test strategy, distribution) Design test test cases test procedure Implement test test components Perform integration test defects Perform system test defects Evaluate test test evaluation (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt ) Slide 7

8 IBM Cleanroom Process Family: Iterative Enhancement Origin: Harlan D. Mills et al. (1980) Motivation for the Cleanroom process Software with known mean time to failure (software with significantly higher quality and demonstrated reliability) Software with near-zero defects (software that experiences near-zero defects after delivery to its users) Quality software that is cheaper to produce (increased productivity across the software lifecycle) Slide 8

9 Cleanroom Impacts on Process Model Requirements Specification Function and Performance but with Usage Statistics Software Design/Implementation Incremental Software Development but with Correctness Verification not Unit Test Independent Software Test Integration & Test of Released Increments but with Representative Statistical Usage Samples Software Acceptance Demonstrated Function and Performance but with Certified Software MTTF (Ref: Michael Dyer: The Cleanroom Approach to Quality Software Development ) Slide 9

10 Process Overview Customer requirements Requirements specification Use specification Design Team Incremental design Correctness verification Incremental development plan Testing Team Test-case generation for each increment Documentation Team User/system documentation No Correct? Yes Statistical testing Certification model No Certified? Yes Incremental certified system Slide 10

11 Structure of STARS IR70E Introduction The Cleanroom Engineering Process: The Management Basis Why CR Engineering? Mathematical Basis of Software Design Software Engineering under Statistical Quality Control Human Issues of CR Engineering Developing a Box Structures Model Process Basis for CR Engineering (the process model) State Data for CR Engineering Responses for CR Engineering Managing a CR Project CR Specification Team Practices CR Development Team Practices CR Certification Team Practices Slide 11

12 Example Description based on Mills notation: - Products are state variables - Decisions are described as conditions - Control flow specification - Processes produce events Slide 12

13 Extreme Programming Families: Iterative Enhancement / Prototyping Origin: Kent Beck, Ward Cunningham, Ron Jeffries (end of 1990s) Idea: light-weight process model, agile process Characteristic: Minimum of accompanying measures (documentation, modeling, ) Team orientation (e.g., common responsibility for all development artifacts) Small teams (12-14 persons) Involvement of user/client at an early stage Social orientation Scope: Prototype projects, small projects, low criticality of the results Slide 13

14 Extreme Programming: Overview Planning Collect user stories Create prototype architecture Create release plan Develop test scenarios Iterative Phase 2 Develop test cases Plan & implement the increment Revise architecture Test current increment Collect data Iteration 1 Iteration 2 Perform acceptance test Iteration n (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt) Slide 14

15 Extreme Programming: Planning Collect user stories Text documents Use cases Create release plan Increment planning Day tasks Create prototype architecture Data recording Class diagrams Develop test scenarios Scenarios (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt) Slide 15

16 Extreme Programming: Iterative Phase Develop test cases Test cases Test environment Plan & implement the increment Source code Revise architecture Class diagram Test current increment Test results Collect data Measurement data Iteration 1 Iteration 2 Perform acceptance test Test results Iteration n (Ref: Bunse / von Knethen: Vorgehensmodelle kompakt) Slide 16

17 3.4 Structure of Process Handbooks An example for the structure of process handbooks: Introduction Purpose, target audience, history Specifics of the process Statements regarding applicability Relationships to other models (e.g., national standards, manuals) Information about the version of the process model Structure of the document Definitions Terminology Abbreviations Schemes for product, process, and role descriptions Slide 17

18 Development of Process Manuals Products Processes possibly subdivided into different classes (e.g., engineering, organization, management, support, customersupplier) Roles Techniques and practices Tailoring Appendices should include examples templates checklists hints (e.g., about tailoring) List of figures and tables, index List of references Slide 18

19 3.5 Comparison of Selected Examples V-Modell XT IEEE Std 1074 IBM Cleanroom Development Process Slide 19

20 Comparison of Selected Examples V-Modell XT IEEE 1074 Cleanroom Introduction Fundamentals (Ch. 1) Scope References Definitions and abbreviations Structure of the document Use of standard Application Basic statements Project overview Definitions Fundamentals (Ch. 1) - in the introduction - Schema in ch. 3 Products Processes V-Modell Reference Work Products (Ch. 5) [Product Templates (Ch. 9), Tool] V-Modell Reference Activities (Ch. 6) --- Ch. 5 Project Mgmt, Pre-Development, Development, Post-Development, Integral Processes Ch. 4 (Program Mgmt, Project Information Mgmt, Software Solution Specification, Software Development and Certification) Roles V-Modell Reference Roles (Ch. 4) --- Implicit (3 teams) Techniques Appendix (Ch. 9) --- Comprehensive description for all teams Tailoring Examples, etc. V-Modell Reference Tailoring (Ch. 3) A tour through the V-Modell (Ch. 2) Informally in ch. 2, template in appendix B --- Detailed examples and checklists Lists Figures, tables Figures, tables Figures References Appendix (Ch. 8) Ch. 8 Only for ch Slide 20

21 3.6 Process Deployment Experiences from industrial practice Providing process documentation is not enough Process deployment is (not only) a technical challenge Process change requires change of behavior Typical process management failures Inflexible, unfit-for-purpose process descriptions Vague, incomplete process definitions Poorly defined inter-team interfaces Person-to-person, team-to-team variance... Encouraging (or: enforcing) process-conformant behavior requires several measures: Training & coaching Providing enriched and easy-to-navigate process descriptions Implementing feedback and improvement mechanism Integration with development environment (including tools) Creatíon of process gates Slide 21

22 Process Deployment Problems in process execution Documents (e.g., templates, checklists, guidelines) cannot be found when needed... because they are not attached to process steps Varying process execution... because process documentation is permanently incomplete and inconsistent Non-observance of processes or execution of obsolete/out-dated processes... because process documentation is continuously out of date Deferred certification or assessment (e.g., FDA, CMM/CMMI, ISO 9000, ISO 15504, TPI)... because appropriate process documentation cannot be produced promptly Process Deployment Strategies Training & coaching Implementing feedback and improvement mechanism Providing enriched (with templates, examples, hints, annotation mechanisms,...) and easy to navigate process descriptions Integration into development environment (including tools) Setting up a task force for deployment and feedback Establishing process evolution procedures Slide 22

23 Summary Prescriptive process models define processes Important prerequisites for ideal prescriptive models have been introduced Prescriptive process models are on different levels of abstraction (e.g., lifecycle level, engineering level) Examples have been presented and compared (e.g., V-Modell XT, Unified Process, Cleanroom) Problems with process models in practice have been sketched Deployment of prescriptive process models requires comprehensive strategies Slide 23