1 Software Process Models-ii Presented By; Mehwish Shafiq

2 Pros and Cons of Prototype Both customer and developer likes the prototype approach Requirement gathering is quick and easy Inherits iteration No proper analysis phase Requirement focus is on customer visualization Developer trade-off requirements for technical limitations in start

3 Our Goal! Primary Goal: High Quality High Quality = Project Timeliness (coz its Less Rework)

4 Software Risks Project Risk:  Threaten project plan, Budget, staffing. Technical Risks:  Threaten quality, time schedule Business Risk:  Developing product that no one really wants  Developing a product that no longer fits business strategy  Loosing budget and/or personnel commitment

5 RAD-Iterative Model Extremely short development cycle using Component base construction. When requirements are well defined and project scope is constrained.

6 RAD-Phases Business modeling (What info drivers the business process? What info is generated? Who generates? Where the info go? Who processes it? Data Modeling Set of data objects to support business Process Modeling Processing requirements created to add, manage, delete and transform objects Application Engineering Reuse or create reusable Testing and turnover Many components already tested. Integration test is critical.

7 Spiral Model Customer communication: Establish effective communication between customer and developer Planning: Define resources, timelines and other project information Risk Analysis: Asses both technical and management risks Engineering : Build representation of the applications, via prototyping, increments etc Construction and release: Construct, test, install and provide user support

8 Agile Methodologies Agile process  Focus on Small and medium sized projects (Small Teams)  Progressing, not spending too much time on design and specification that might be useless Agility  Adaptable instead of predictable  Light weight methodologies  Minimizing risk by short term focus (1-8 Weeks)

9 Agile Manifesto Individuals and interaction over processes and tools  Close daily cooperation  Self organizing teams  Trust in motivated individuals Working software over comprehensive documentation  Working software is the principal measure of progress  Simplicity Customer collaborations  Customers involved at each and every step Responding to change over following a plan

10 Agile processes In this module we will study  eXtreme Programming (XP)  Dynamic Systems Development Methodology (DSDM)

11 XP

12 XP Phases 1.Exploration Phase:  User stories FR and NFR gathered and prioritized (story cards are developed) 2.Planning phase:  time required to implement each story card is estimated 3.Iteration to release phase  Prioritized story cards are implemented. Iteration is 1-4weeks long. Design and coding is done

13 XP-Phases 4.Productionizing phase  Testing is done here. Story cards are validated. 5.Maintenance phase  Customer are supported by probably new team.  Improvement suggestions are considered and fulfilled. 4.Death phase  End of software development

14 XP-Practices The planning game  Iteration planning: predicting what will be accomplished by the due date  Release planning determining what to do next.  Planning involves breaking up a project into short iterations of 1-3 weeks and undertaking the project one iteration at a time. At the end of iteration, system is presented before customers for feedback. Small Releases  Release working-s/w after every 2-3 weeks for customer evaluation  This makes software visible and keeps everything open.  Early feedback from customers enables developers to know about the functionality of system

15 XP Practices Pair Programming  Pair of programmers work together and develop system artifacts.  Pairs are exchanged, everyone knows each part of system.  Pairing provides better code, better acceptance tests, and effective knowledge sharing between developers. Onsite Customer  In XP customers work with the developers during the course of product development to help understand each others’ problems.  In this way the turnaround time for queries is reduced and also it prevents developers from making incorrect assumptions about requirements.

16 DSDM

17 DSDM Phases Feasibility study  Conducted to evaluate technical feasibility of project for the use of DSDM.  Result = feasibility report. Business study  FR and NFR specified & prioritized.  Customer is involved in business study.  Result= Business area definition containing ER Diagrams & use cases. Functional model iteration  Iterative process  Prototype is developed, contains only FR (multiple iterations).  Analysis model is defined to analyze the prototype.  Prototype review document contains user comments.  List of NFR for this prototype is generated.  Risk analysis document for next prototype is produced.

18 DSDM Phases Design and Build iteration  Iterative process  Prototype is completed by adding NFR Tested and reviewed by customer. Implementation  Iterative process  Developed system is transferred into real application field.  Result= user manual & project review document (project’s outcomes).

19 Why Projects Fail? Unrealistic deadline is established Changing customer requirements An honest underestimate of efforts Predictable and/or unpredictable risks Technical difficulties Miscommunication among project staff Failure in project management

20 Thank You!