Software Engineering Process Models In this course we

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 1

Software Engineering Phases Software Engineering: Systematic, disciplined quantifiable approach to the development, operation and maintenance of SW. Three distinct phases: Analyze— Requirmnts, Spec. • Definition phase: WHAT, i. e. , what information, function, performance Develop— Design, Code. • Development phase: HOW Maintain • Support Phase: CHANGE, i. e. , correction, adaptation, enhancement, prevention 2

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? 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 Question: what software process models have you used? How large / complex was the project? What level did the associated process represent? 4

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

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

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 7

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 8

Waterfall Model Linear Sequential Model (“waterfall model”): Sequential approach from system level through analysis, design, coding, testing, support--oldest and most widely used paradigm Analysis Design Code Test Maintain 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. 9

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

Evolutionary Models 11

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) 12

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

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 14

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 15

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

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 17

Introduction to Extreme Programming 18

“ 12 Practices” of XP 19

Metaphor 20

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

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 22

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) 23

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

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

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

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 27

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 28

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 29

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

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

“ 13 th Practice” "13 th 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 32

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 33

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