SEA Side Software Engineering Annotations

1. SEA Side Software Engineering Annotations • AAnnotation 5: Process Model One hour presentation to inform you of new techniques and practices in software development. Professor Sara Stoecklin Director of Software Engineering- Panama City Florida State University – Computer Science sstoecklin@mail.pc.fsu.edu stoeckli@cs.fsu.edu 850-522-2091 850-522-2023 Ex 182

2. The Process Model(Software Development Life Cycle (SDLC))Methodology

3. Overview • Heavyweight • Waterfall Model, DOD Waterfall • Unified Process • RAD, Component Assembly Model • Iterative, Evolutionary • Spiral • Middleweight • Korbra • UML Components • CleanRoom • Lightweight • XP • Agile Software Development • CaLM

4. A Common Process Framework Work Tasks Work Products Milestones Deliverables QA Checkpoints

5. Some Common Process Flows Linear Process Flows Iterative Process Flows Incremental Process Flows

6. Linear Models

7. Linear Model Characteristics • Documentation driven model • systematic and requires rigor. • Inflexible partitioning of project into distinct stages • difficult to respond to changes in customer requirements • Model appropriate when requirements are well-understood. • Programmers HATE to create documentation. • l Users HATE to read documentation. • l If users read, they rarely understand documentation. • Programmers don't understand other programmers documentations. • Standards for documentation not clear although UML ordained.

8. Prototyping Iterative Models

9. Evolutionary/Prototype Model • Issues • Process is not visible--Lack of process visibility • Systems are often poorly structured—Change tends to corrupt the structures • Special tools and techniques may be required—Special skills (e.g. in languages for rapid prototyping) may be required • Applicability • For small or medium-size interactive systems • For parts of large systems (e.g. the user interface) • For short-lifetime systems

10. b u s i n e s s m o d e l i n g b u s i n e s s d a t a m o d e l i n g m o d e l i n g business p r o c e s s m o d e l i n g d a t a modeling m o d e l i n g a p p l i c a t i o n g e n e r a t i o n t e s t i n g & p r o c e s s t u r n o v e r data m o d e l i n g modeling a p p l i c a t i o n g e n e r a t i o n process modeling t e s t i n g & t u r n o v e r application generation testing & turnover Iterative Models team #3 team #2 team #1 60 - 90 days RAD

11. S y s t e m / i n f o r m a t i o n e n g i n e e r i n g a n a l y s i s d e s i g n c o d e t e s t a n a l y s i s d e s i g n c o d e t e s t a n a l y s i s d e s i g n c o d e t e s t a n a l y s i s d e s i g n c o d e t e s t The Incremental Model increment 1 delivery of 1st increment delivery of increment 2 2nd increment delivery of increment 3 3rd increment increment 4 delivery of 4th increment calendar time

12. Waterfall Model SSR - System Software Review PDR - Preliminary Design Review CDR - Critical Design Review TRR - Test Rediness Review FCA - Functional Configuration Audit PCA - Physical Configuration Audit ORR - Operational Rediness Review Software Requirements Analysis Software Design SRS Code and Unit Testing SDS Software Integration and Test STP Software Acceptance Test SIP SSR PDR CDR TRR FCA PCA CRR

13. Hardware Hardware Implementation System Design Operational Timelines Software Requirements Analysis Preliminary Software Design Detailed Software Design Code and Unit Testing Software Integration and Test Software Acceptance Test SDR SSR PDR CDR TRR FCA PCA Waterfall - DOD Model NASA Model) PP SRS PDD SDS STP SIP

14. Software Requirements Analysis Build Prototype Software Design Code and Unit Testing Software Integration and Test Software Acceptance Test SSR PR PDR CDR TRR FCA PCA CRR Rapid Application Development Model Rapid Throwaway Prototype Model SRS PDD SDS STP SIP

15. RAD Characteristics • High speed adaptation of the linear model • Based on Component-based construction • Has incremental flavor • Not well- suited where precision is required, • e.g. high risk systems not easily modularized systems • Have rigid performance requirements • 1. Model the Information Flow • 2. Refine the flows into Data elements • 3. Model the data transformations • 4. Generate the code 4GLs, component reuse, CASE • 5. Test and integration

16. Software Requirements Analysis Build Prototype Software Design Code and Unit Testing Software Integration and Test Software Acceptance Test SSR PR PDR CDR TRR FCA PCA CRR Evolutionary (Prototype) Model ONLY A PART OF THE FULL SYSTEM SRS PDD SDS STP SIP Series of Implementations of each PART

17. Software Requirements Analysis Software Design Code and Unit Testing Software Integration and Test Software Acceptance Test SSR PDR CDR TRR FCA PCA CRR Incremental Development Model ONLY A PART OF THE FULL SYSTEM SRS SDS STP SIP Can Determine a PART at any phase.

18. Characteristics of Incremental Model • Same Requirements, specification, maintenance,and requirement phases as in Waterfall • The systems is partitioned into builds where each build is independently designed and scheduled "incrementally“ The 1st build gives some "production"functionality Subsequent builds add functionality • User perspective • Get some results quickly • Reduces new system "culture shock"

19. Characteristics of Incremental Model • Costs easily prorated over the development cycle • It employs the systems approach • Changes are easier to implement (e.g.design of later builds may not start until some phases are complete and all their changes well known). • Problems - May degenerate into "Build and Fix“ • May result in builds that cannot integrate with one another

20. Spiral Model Risk Analysis Prototyping Planning Simulation Operational Prototype Verification for Next Level Developing Client Evaluation and Input

21. C u s t o m e r E v a l u a t i o n An Evolutionary (Spiral) Model P l a n n i n g R i s k A n a l y s i s Prototyping C u s t o m e r C o m m u n i c a t i o n E n g i n e e r i n g C o n s t r u c t i o n & R e l e a s e And input Simulation/ Operational Prototype/Verification for the Next Level/Development

22. V Model OPERATION Validate requirements REQUIREMENTS & MAINTENANCE ANALYSIS ACCEPTANCE TESTING SYSTEM DESIGN SYSTEM TESTING Verify design PROGRAM UNIT & INTE- DESIGN GRATION TESTING CODING [Pfleeger 98]

23. Operational Specification Model [Pfleeger 98] Execute and Revise OPERATIONAL TRANSFORMED TEST SPECIFICATION SPECIFICATION (problem-oriented) (implementation- oriented) DELIVERED SYSTEM SYSTEM REQUIREMENTS (sometimes informal or incomplete)

24. Still Other Process Models • Concurrent process model—recognizes that different part of the project will be at different places in the process • Formal methods—the process to apply when a mathematical specification is to be developed

25. Heavyweight Methodologies • Predictable sequential series of tasks • Structured sequence of events • Plan and work the plan • Allows management of milestones • Are rigid in deviations to the plan • Lack flexibility to use different methods for different problems • Trouble handling uncertainty

26. Capability Maturity Model • Organizations are not born using a mature process model. • Most organizations use NO known process model • Watts Humphrey wrote a book to lay out a plan for improving the process model within organizations. His book “Managing the Software Process” and other research has greatly improved the software engineering process. • The SEI Developed a capability maturity model which proposes a model for maturing an organizations process model.

27. Capability Maturity Model • Five Process Maturity Levels • Level 0: Chaos • Level 1: Initial • Level 2: Repeatable • Level 3: Defined • Level 4: Managed • Level 5: Optimizing

28. Middleweight Methodologies • Predictable sequential series of tasks • Structured sequence of events • Plan and work the plan • Allows management of milestones • Are NOT rigid in deviations to the plan • Contain flexibility to use different methods for different problems • Handle uncertainty • Domain experts and programmers work closely

29. Specification Incremental Development Planning Specification and Design Usage Design Statistical Testing Certification CleanRoom Approach

30. Software Requirements Analysis Software Design Code and Unit Testing Software Integration and Test Software Acceptance Test SSR PDR CDR TRR FCA PCA CRR Reuse and Automated Development Models/Component Assembly Model SRS SDS STP SIP Identify Reusable Components Informal Specification Formal Specifications Code

31. LightWeight Methodologies • Lightweight methodologies : • Customer is the highest priority at all phases • Change in requirements welcomed anytime • Deliver is done frequently • Domain experts and programmers work closely • Motivate developers via various methods • Hold conversations while prototyping or programming • Amount of workable software is the measure of success • Good Design occurs every moment • Reflection on designs happen often

32. LightWeight Methodologies • Differenced between light and heavy • Individuals over process • Working software over documentation • Customer collaboration over contracts • Responding to change over planning • Stepping up to the plate

33. LightWeight Methodology – CaLM Design Project Management Implementation Meetings

34. The XP Process Defines user requirements requirements bugs Build User Stories new velocity Conduct Release Planning Build Iteration Conduct Acceptance Testing release metaphor release plan Define Architectural Spikes estimating next iteration Controls Scope Improves Quality

35. Twelve XP Practices • Five Basic XP Principles • Small Releases • 40-hour work week • On-site customer • Collective Ownership • Coding Standards • Seven Process Techniques

36. Twelve XP Practices • Seven Process Techniques • The Planning Game • Metaphor • Simple Design • Pair Programming • Refactoring • Continuous Integration • Testing

37. LightWeight Methodology – Agile • Visioning. A good visioning practice • Project initiation. • Short, iterative, feature-driven, timeboxed delivery • Constant feedback. • Customer involvement. • Technical excellence.

38. THE BEST • Management must have milestones. • Deliverables must be the payment guide. • Lightweight methodologies do not scale. • Pair programming WORKS for GOOD design. • Customer involvement with constant feedback. • Training is essential.