CSCI 3428: Software Engineering Tami Meredith Chapter 2 Modeling the Process and Life Cycle Process A series of steps involving activities, constraints, and resources that produce an intended output of some kind. A. Describes all major activities: a) each has clearly defined entry and exit criteria. b) activities are sequenced in some manner c) each has principles that explain the goals B. Uses resources, subject to constraints to produce intermediate and final products C. Constraints may apply at any time to resources, activities, or output Software Life Cycle 1. Requirements analysis and definition 2. System design 3. Program design 4. Implementation 5. Unit testing 6. Integration testing 7. System testing 8. Delivery 9. Maintenance Waterfall Model US DoD Standard 2167A: A Procurement Model Milestones and Deliverables are the foundations Fundamentally sound! a) Doing the steps in another order would not work b) Skipping steps would be a disaster c) Can do more but never really do less Major Problem: Software development is very complex and the waterfall model is very simple Human make mistakes, we miss things, we have to back and fix them, we have to contend with unknowns... Software Development (Actual) Prototyping Creation of a partially developed product that allows customers to examine some aspect of the proposed solution Sometimes several prototypes created to assess alternatives Balance needed: Time spent on prototype vs. time saved in actual development Heavily used for User Interfaces (UI) Issues: Customers want to keep the prototype If prototype works, managers want to keep it Evaluation Validation (Completeness): Have all the requirements been met? We build the right system! Verification (Correctness): Do things work correctly? We build the system right! Justification (Conciseness): Have we added anything extra? We just build the system! Waterfall Model with Prototyping The V Model Waterfall model with explicit evaluation German Ministry of Defense More fully integrates testing to evaluation Key Idea: Requirements and design documents are crucial at all stages and should be constantly referenced! V Model The Prototyping Model Requires strong client/user input Not agile programming requirements and design still have a key role Exploring alternatives is one of its strengths Unexpected problems can irritate clients Client pressure to use early prototypes can be problematic Can get stuck in revision cycles (usually due to communication/understanding w.r.t. client) Prototyping Model Operational Specification Key: Convert specification to code algorithmically Useful when requirements are complex and/or uncertain Automated approaches require powerful tool support Minimal coding translation only, if done manually Transformation process often ensures verification, validation, and justification of resulting system Ad-hoc variation uses code as the specification language (cf. prototyping) Operational Specification Transformational Development Refinement of operational specification Requires strong tool support (e.g., VHDL, Rhapsody) Very dependent upon notation Minimises programming but very expensive tools and needed experts in the (complex) notations Operational Spec: Does it work the way we want? Focus on the system's operation/functionality cf. Transformational Dev: Focus on getting the specification correct. Let tools do the rest of the job Transformational Model Phased Development Intended to get a (minimal) product into consumer's hands fast! Deliver a basic, minimal, system to the client While client uses the system (e.g., finds faults) develop an improved/extended version More of a "Meta-Model" and each release still requires its own development process/model Closely matches "Evolutionary" software development Phased Development Incremental & Iterative Models Incremental Development: Deliver a basic system with few features Add features in subsequent releases Each feature is complete when it is released Iterative Development: Deliver an initial system with all features partly working Subsequent releases improve the features with better or additional functionality Hybrid (Actual) Development: Subsequent releases may improve some features or add new ones. Both approaches used Phased Models Advantages (Phased Approaches) Early training for clients/users Somewhat like prototyping; minimal functionality can enable things to be easily changed if they are not correct Faster time to market Frequent releases permit fault repair on subsequent releases Earlier finding of faults in core (earliest) features Each release may focus on one area, making tasks easier for programming and development Spiral Model Combine development with risk management Recognises iterative nature of software development Extra "Concept of Operations" document before requirements analysis and specification Budgeting, planning, exploration of alternatives, risk analysis, and prototyping are all integrated into the model Extremely heavy-weight but detailed and thorough Lots of steps involved for 4 complete iterations Boehm's Spiral Model Agile Manifesto Four tenets of software development: 1) Value individuals over processes and tools 2) Focus on the software, not the documents 3) Customer involvement for more than contract negotiations and sign-offs 4) Respond to change rather than a rigid plan Agile Methods... Adaptive Software Development Agile Modelling Agile Unified Process Crystal Clear Dynamic Systems Development Method Essential Unified Process Extreme Programming Feature Driven Development Graphical System Design Kanban Lean Software Development Open Unified Process Scrum Velocity Tracking Extreme Programming (Part 1) 1. Planning Game: Client-driven prioritised story-boarding (use-cases) 2. Small Releases: Get it to the user fast and often 3. Metaphor: Selection of common language, metaphors, concepts 4. Simple Design: Design for the current needs, do not plan for tomorrow 5. Write Tests First: Test cases create client-based specifications 6. Refactoring: Reconsider, adapt, and modify existing design/parts Extreme Programming (Part 2) 7. Pair Programming: Share knowledge, catch mistakes earlier 8. Collective Ownership: Everyone knows all parts of the code 9. Continuous Integration: Small, regular releases without huge changes 10. Sustainable Pace: Tired, overworked programmers are sloppy and make errors 11. On-Site Customer/Client: Client is an active participant for all elements 12. Coding Standards: Needed to support collective ownership Some Issues for Agile Methods Lack of planning; Dynamic approaches can lead to weak architecture and design Not scalable to large teams due to independence. Customer must be committed to participating Refactoring is often not supported (takes time for no new features) Coding faults often less frequent but design and requirements faults can go unnoticed for longer periods of time Paired programming can fail badly! Can't be forced on programmers Keeping clients close to programmers can be very problematic (see too much, in-the-way, programmers not always good CSRs) Process Modelling Useful for academia and research Not seen as useful in most industrial settings Value increases as risk and complexity increases Most useful for safety/mission critical software Can be: a) Static depict the model as a whole b) Dynamic show the model in action Various notations: Lai notation, Abdel-Hamid approach, Marvel Specification Language Only modelling the process not the software, requirements, or other development artefacts Famous Moments in Software Engineering