Software Engineering Process Models

1. Software Engineering Process Models In this course we will have a project with: Product requirements A defined development process A team of 3-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: Systematic, disciplined quantifiable approach to the development, operation and maintenance of SW. • Three distinct phases: • Definition phase: WHAT, i.e., what information, function, performance • Development phase: HOW • Support Phase: CHANGE, i.e., correction, adaptation, enhancement, prevention Software Engineering Phases Analyze— Requirmnts, Spec. Develop— Design, Code. Maintain

3. Developing a program / system How do you develop a program / system from scratch? For example: --what did you do in your first computing class? --what do you do differently now? --what good / bad practices have you come into contact with in your co-op jobs? --what are differences for small / large projects?

4. 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 • Optimizing--desired level: Continuous process improvement from quantitative feedback • Question: what software process models have you used? How large / complex was the project? What level did the associated process represent?

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

6. What does the model need to provide? --organized development: specify, design, implement, test, maintain --testing strategy --tracking / change management --schedule Etc.

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

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

9. Analysis Design Code Test Maintain 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 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. Waterfall Model

10. 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)

11. Evolutionary Models

12. Incremental Model 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. Incremental: A-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M (A=analysis, D=design, C=coding, T=testing, M=maintenance)

13. 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 Component Based Development • Component based: • A-->D-->Library-->Integrate-->T-->M • C • (A=analysis, D=design, C=coding, T=testing, M=maintenance)

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

15. 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 Formal Methods

16. Extreme Programming—an Agile Process Model • Extreme Programming-- • An Agile Process Model

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

18. Introduction to Extreme Programming

19. “12 Practices” of XP

20. Metaphor

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

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

23. 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 (you use this approach in week 1 lab to gain some java skills)

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

25. 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"

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

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

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

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

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

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

32. “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

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

34. Analysis and specification in XP Question: How are analysis and specification done --in the “extreme programming” model? --in the waterfall model?