CS 325: Software Engineering January 15, 2015 Software Process & Methodology Prototyping Process Model Evolutionary Process Model Spiral Process Model Unified Process Model Agile Process Models Software Development Methodologies Agile Methodology: Scrum Agile Methodology: XP Agile Methodology: AUM

Prototyping Process Model CS 325 January 15, 2015 Page 10 To validate the user requirements for new software before progressing too far in the development process, prototypes of the software system may be developed. Whether a low-fidelity prototype that illustrates the look-and-feel of the design or a high-fidelity prototype that implements part of the system’s functionality, approval by the customer is required before full system implementation is begun. Initial Requirements Development Test Maintain Customer Satisfaction

Evolutionary Process Model CS 325 January 15, 2015 Page 11 Larger systems may require the development of an iterative sequence of prototypes, each refining the system as requirements become clear and alternatives are explored. Developer Conception Customer Conception These prototypes tend to be less disposable than in the prototyping process model, representing early working versions of the actual final system.

Spiral Process Model CS 325 January 15, 2015 Page 12 This variation of the evolutionary approach emphasizes extensive risk assessment to allow for easy adaptation to changes and identification of problems. Quadrant 3Quadrant 3 Putting into practice a solution to reach the Q1 goals in view of the Q2 risksPutting into practice a solution to reach the Q1 goals in view of the Q2 risks Quadrant 4Quadrant 4 Assessing the results of the risk-reduction strategies and planning the next phaseAssessing the results of the risk-reduction strategies and planning the next phase Quadrant 2Quadrant 2 Analyzing the strategy for achieving this phase’s goals from the viewpoint of riskAnalyzing the strategy for achieving this phase’s goals from the viewpoint of risk Quadrant 1Quadrant 1 Determining the current phase’s objectives, alternatives, and constraintsDetermining the current phase’s objectives, alternatives, and constraints Requirements Plan Risk Analysis Prototype #1 Requirements Validation Life-Cycle Plan Risk Analysis Prototype #2 Software Product Design Design Verification & Validation Development Plan Risk Analysis Prototype #3 UML Models Integration & Test Plan Risk Analysis Operational Prototype Benchmarks Detailed Design Code Unit Tests Integration Integration Tests Implementation

Unified Process Model CS 325 January 15, 2015 Page 13 This iterative approach emphasizes a heavily structured hierarchy of activities and milestones. Project Life-Cycle Phases Inception (Validate initial costs and budget) Inception Elaboration (Identify problem domain & mitigate risks) Elaboration Construction (Build an operational software system) Construction Transition (Validate system & train users) Transition IterationsIterations Task Categories Business Modeling RequirementsRequirements Analysis & Design ImplementationImplementation TestTest DeploymentDeployment Config/Change Mgmt Project Mgmt EnvironmentEnvironment

Agile Process Models CS 325 January 15, 2015 Page 14 The predictive nature of conventional software development is sometimes seen as an illusion. An alternative approach, agile development, is characterized by: Small but highly competent development teams The principal measure of progress is working code Changes in requirements are welcome, even if late Developers, customers, and managers are all on the same team Software delivery is stressed more than analysis and design

Software Development Methodologies CS 325 January 15, 2015 Page 15 While the process lays out the phases of the software development, the methodology details the actual steps taken to accomplish the software development. Implement- ation Imple- ment Train Users User Approval & User Guide- lines Assess Impact on Business Design & Build Iteration Identify Design Proto- types Review Design Proto- type Create Design Proto- type Agree Plan Functional Model Iteration Agree Plan Identify Function- al Proto- type Review Function- al Proto- type Create Function- al Proto- type Business Study Prioritize Require- ments Design Architec- ture Resolve Risks Plan To Build, Test, Deploy, Support For example, the Dynamic Systems Development Method lays out steps for following the Unified Process.

Agile Methodology: Scrum CS 325 January 15, 2015 Page 16 Scrum is an agile approach in which prioritized requirements are achieved in strict time intervals with regular team input. PREGAME PHASE DEVELOPMENT PHASE POSTGAME PHASE PRODUCT BACKLOG LIST PLANNINGPLANNING regular updates priorities effort estimates STANDARDSCONVENTIONSTECHNOLOGYRESOURCESARCHITECTURESTANDARDSCONVENTIONSTECHNOLOGYRESOURCESARCHITECTURE HIGH-LEVEL DESIGN/ ARCHITECTURE ARCHITECTURE SPRINT BACKLOG LIST SPRINT ANALYSISDESIGNEVOLUTIONTESTINGDELIVERYANALYSISDESIGNEVOLUTIONTESTINGDELIVERY requirements no more requirements NEW PRODUCT INCREMENT FINAL RELEASE DOCUMENTATIONDOCUMENTATION INTEGRATIONINTEGRATION SYSTEM TESTING

Agile Methodology: XP CS 325 January 15, 2015 Page 17 Extreme programming (XP) is an agile approach that emphasizes rapid feedback, stressing simplicity, and embracing change. PAIR PROGRAMMING ANALYSISDESIGN PLANNING FOR TESTING TESTING STORIESSTORIES STORIES FOR NEXT ITERATION STORIES COLLECTIVE DATABASE TESTTEST SMALL RELEASE UPDATED RELEASES FINAL RELEASE EXPLORATION PHASE PLANNING PHASE ITERATIONS-TO-RELEASE PHASE PRODUCTIONIZING PHASE MAINTENANCE PHASE DEATH PHASE regular updates priorities effort estimates continuous review continuous integration feedback customer approval

Agile Methodology: AUM CS 325 January 15, 2015 Page 18 The Agile Unified Methodology. begins with a brief planning phase in which requirements are identified and use cases (models of how the system will be used to achieve particular goals) are derived. Acquiring Requirements Deriving Use Cases From Requirements Allocating Use Cases & Subsystems To Iterations Producing An Architectural Design Accommodating Requirements Change Domain Modeling User Interface Design Behavior Modeling & Responsibility Assignment Deriving Design Class Diagram Test-Driven Development Integration, & Deployment Business Goals & Needs Requirements High-Level Use Cases Use-Case Iteration Allocation Matrix Software Architecture Customer Feedback Iteration Use Cases Domain Model Expanded Use Cases & UI Design Behavior Model Design Class Diagram Iterative Phase Planning Phase This is followed by an iterative phase in which changes to requirements are addressed, use cases are updated, the user’s domain is conceptualized, the algorithms are formulated (via activity, sequence, and state diagrams), and the planned classes are diagrammed and then implemented and tested.