1 Software Engineering Process Models In this course we will have a project with: Product requirements A defined development process A team of 4-5 developers We will use the Unified Modeling Language (UML) to describe our product specifications and design Today we will discuss some standard process models

2 Software Engineering Phases

3 Capability Maturity Model CMM : capability maturity model--defines level of the development process itself 1. Initial: ad hoc 2. Repeatable: basic project management processes in place 3. Defined: documented process integrated into an organization-wide software process 4. Managed: detailed measures are collected 5. Optimizing--desired level: Continuous process improvement from quantitative feedback

4 Software Process Model Software Process Model: --A development strategy that encompasses the process, methods, and tools --Specific model is chosen based upon the project/application, the methods/tools to be used, resources available, and the deliverables required basic model: problem  develop  integrate each step is carried out recursively until an appropriate level of detail is achieved

5 Process Model Types Process Model Types: “Prescriptive” Model includes a specific set of tasks, along with a workflow for these tasks and definite milestones and outcomes for each task; end result is the desired product "Agile" Model tends to be simpler than prescriptive models; emphasis is on incremental development, customer satisfaction, and minimal process overhead "Mathematical" Formal Method Model stresses mathematical rigor and formal proofs that product is meeting carefully-defined goals

6 Some Common Prescriptive Models Some common models used in practice: Prescriptive: "Basic": Linear Sequential Model Prototyping Model "Evolutionary" (product evolves over time): Incremental Model Component-based Model “Formal Methods” Z-based methods “Agile” Extreme Programming

7 Waterfall Model AnalysisDesignCodeTestMaintain Linear Sequential Model (“waterfall model”): Sequential approach from system level through analysis, design, coding, testing, support--oldest and most widely used paradigm Advantages: --better than nothing --can be appropriate for for small, well-understood projects Disadvantages: --Real projects rarely follow a sequential flow --Requirements usually not fully known. --Working version not available until late in project.

8 Prototyping Model Prototyping Model: customer defines set of general objectives; no details on input, processing, output requirements; may be unsure of algorithm efficiency, adaptability, OS, human/machine issues Advantages: --Focuses on what is visible to customer --Quick design leads to a prototype --Prototype evaluated by the customer who can refine requirements --Ideal mechanism for identifying and refining SW requirements Disadvantages: --Customer sees something that appears to work and wants it. --Less than ideal choices move from prototype to product SW Prototyping:A-->D-->C-->T-->M (A=analysis, D=design, C=coding, T=testing, M=maintenance)

9 Evolutionary Models

10 Incremental Model Incremental: A-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M (A=analysis, D=design, C=coding, T=testing, M=maintenance) Incremental Model: Elements of linear sequential (applied repetitively) with prototyping. As result of use, a plan is developed for next increment. Advantages: Unlike prototyping, an operational product is delivered at each increment. Disadvantages: Variable staffing at each increment (task dependent). Risk analysis must be done at each increment.

11 Component Based Development Component based: A-->D-->Library-->Integrate-->T-->M C (A=analysis, D=design, C=coding, T=testing, M=maintenance) Component Based Development: emphasizes the creation of classes that encapsulate data and the algorithms to manipulate the data. Reusability. Evolutionary and iterative. But composes applications from prepackaged SW components (classes) Process steps: --candidate class is identified --library is searched for existing class --if none exists, then one engineered using object-oriented methods. Advantages: Faster development and lower costs. Disadvantages: requires expertise in this type of development

12 Process Models--Comparison Graphical comparison of basic and evolutionary models: Basic waterfall model: A-->D-->C-->T-->M (A=analysis, D=design, C=coding, T=testing, M=maintenance) Prototyping:A-->D-->C-->T-->M Incremental: A-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M  Component based:A-->D-->Library-->Integrate-->T-->M C

13 Formal Methods Formal Methods: formal mathematical specification of SW. Uses rigorous mathematical notation. Advantages: --Ambiguity, incompleteness, inconsistency found more easily. --Serves as a basis for program verification. --”promise” of defect-free SW Disadvantages: --Very time consuming --extensive training required --not a good communication mechanism (especially for customer) --handles syntax well; not so successful with semantics uses: Safety critical SW (medicine and avionics) or when severe economic hardship will be incurred by developer if error occurs

14 Extreme Programming—an Agile Process Model Extreme Programming-- An Agile Process Model

15 Review of Process Models In process models discussed previously: problem  develop  integrate each step is carried out recursively until an appropriate level of detail is achieved Basic method:

16 Introduction to Extreme Programming

17 “12 Practices” of XP

18 Metaphor

19 Release Planning 2. release planning requirements are given in terms of "user stories" each "story" is a short (~ 1 index card) description of what the customer wants, in natural language requirements are prioritized by customer resources and risks are estimated by developer "planning game"--each increment is restricted to a "time box"; highest priority and highest risk user stories are in early time boxes; after each increment, replay the "planning game"

20 Testing 3. testing development is test-driven tests are written before code unit must run at 100% before going on acceptance tests written with customer; they act as "contract", measure progress

21 Pair Programming 4. pair programming two engineers, one task, one computer "driver" controls keyboard & mouse "navigator" watches, identifies defects, participates in brainstorming roles are rotated periodically

22 Refactoring 5. refactoring improve design of existing code, but don't change functionality relies on testing; no new errors can be introduced

23 Simple Design 6. simple design no big design up front "do the simplest thing that could possibly work" don't add features you won't need may use "CRC cards"

24 Collective Code Ownership 7. collective code ownership code belongs to project, not individual engineers may browse into and modify ANY class

25 Continuous Integration 8. continuous integration pair writes unit test cases & code pair tests code to 100% pair integrates pair runs ALL test cases to 100% pair moves on to next task

26 On-Site Customer 9. on-site customer clarifies stories, participates in critical decisions developers don't make assumptions no waiting for decisions face-to-face communication

27 Small Releases 10. small releases timeboxed as small as possible, but with "business value" get feedback early and often do planning game after each iteration

28 40-Hour Work Week hour work week burning midnight oil kills performance tired developers make more mistakes workforce is more content

29 Coding Standards 12. coding standards use coding conventions write intention-revealing code

30 “13th Practice” "13th practice": stand up meeting 15 minutes at start of each day stand up to keep meeting short each participant says --what they did yesterday --what they plan to do today --any obstacles they are facing pairs can be reformed based on meeting

31 Contrast with Waterfall Model example contrasts: "waterfall model” || XP planning: upfront || incremental control of project, "people" questions: centralized || distributed customer involvement: only for specification, reviews || ongoing risk analysis, scheduling: all at beginning || in increments code development: assigned sections || collective ownership testing: specific phase || ongoing and required to 100% project type: well-understood, static || new, dynamic