Software Process Models Lecture Slides

Software Process Models Instructor: Mehroze Khan 1 Software Life Cycle When the process involves the building of some product, we sometimes refer to the process as a life cycle. Thus, the software development process is sometimes called the software life cycle, because...

Software Process Models Instructor: Mehroze Khan 1 Software Life Cycle When the process involves the building of some product, we sometimes refer to the process as a life cycle. Thus, the software development process is sometimes called the software life cycle, because it describes the life of a software product from its conception to its implementation, delivery, use, and maintenance. 2 Software Life Cycle Software development usually involves the following stages: Requirements analysis and definition System design Program design Writing the programs (program implementation) Unit testing Integration testing System testing System delivery Maintenance 3 Process A process is defined as a collection of work activities, actions, and tasks that are performed when some work product is to be created. Each of these activities, actions, and tasks reside within a framework or model that defines their relationship with the process and with one another. A software process is a framework for the activities, actions, and tasks that are required to build high-quality software. 4 Generic A generic process framework for software engineering Process defines five framework Framewor activities: Communication k Planning Modeling Construction Deployment 5  Process Flow Process flow—describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time. A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment. 6  Process Flow An iterative process flow repeats one or more of the activities before proceeding to the next. 7  Process Flow An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software. 8  Process Flow A parallel process flow executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software). 9 Task Set For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call with the appropriate stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that this action encompasses are: 1. Contact stakeholder via telephone. 2. Discuss requirements and take notes. 3. Organize notes into a brief written statement of requirements. 4. E-mail to stakeholder for review and approval. 1 0 Task Set If the project was considerably more complex with many stakeholders, each with a different set of (sometime conflicting) requirements, the communication activity might have six distinct actions: Inception Elicitation Elaboration Negotiation Specification Validation. 1 1  Task Set Inception: The initial stage where the project is conceived, and the goals and objectives are outlined. Identifying the key stakeholders, understanding their initial requirements, and setting the project's overall direction. Elicitation: The process of gathering information and requirements from stakeholders to understand their needs and expectations. Conducting interviews, surveys, workshops, or other methods to extract relevant information from stakeholders. Elaboration: The stage where gathered requirements are analyzed and detailed to create a comprehensive understanding of the project scope. Breaking down high-level requirements into more detailed specifications, creating use cases, and developing a more intricate project plan. Negotiation: The process of reconciling conflicting requirements and priorities among stakeholders. Facilitating discussions and negotiations to resolve conflicts, finding compromises, and ensuring alignment among stakeholders. Specification: The formal documentation and communication of detailed project requirements and specifications. Creating detailed documentation, such as requirements documents, design specifications, and other relevant materials that serve as a reference for project development. Validation: The stage where the documented requirements are reviewed and verified to ensure they meet the stakeholders' expectations. Conducting reviews, inspections, and tests to validate that the project deliverables align with the specified requirements and meet the intended objectives. 1 2 Software Development Process Models Waterfall model Classical With prototyping V model Prototyping model Phased development: increments and iterations Spiral model Unified process Rapid Application Development (RAD) Agile methods XP Scrum Kanban 1 3 The Waterfall Model One of the first process development models proposed Works for well understood problems with minimal or no changes in the requirements Simple and easy to explain to customers It presents a very high-level view of the development process sequence of process activities Each major phase is marked by milestones and deliverables (artefacts) 1 4 The Waterfall Model 1 5 The Waterfall Model 1 6 The Waterfall Model  Provides no guidance how to handle changes to products and activities during development (assumes requirements can be frozen)  Views software development as manufacturing process rather than as building process  There are no iterative activities that lead to building a final product  Long wait before a final product  Generates lots of documentation  Considered suitable for large projects 1 7 Problems with Waterfall Model It is often difficult for Real projects rarely the customer to state follow the sequential all requirements workflow that the explicitly at the model proposes. beginning of most projects. The customer must have patience because a Major blunders may working version of the not be detected until program(s) will not be the working program available until late in the is reviewed. project time span. 1 8 Waterfall Model with Prototyping A prototype is a partially developed product Prototyping helps developers assess alternative design strategies (design prototype) users understand what the system will be like (user interface prototype) 1 9 Waterfall Model with Prototyping 2 0  The V-Model A variant of the waterfall model Uses unit testing to verify procedural design Uses integration testing to verify architectural (system) design Uses acceptance testing to validate the requirements If problems are found during verification and validation, the left side of the V can be re- executed before testing on the right side is re-enacted Verification: Each function works correctly Validation: All requirements have been implemented and each functionality can be traced back to a particular requirement 2 1 The V-Model 2 2 Phased Development Cycle time Time between when requirements document was written and when the system was delivered Shorter cycle time Decomposed system System delivered in pieces enables customers to have some functionality while the rest is being developed Two systems functioning in parallel the production system (release n): currently being used the development system (release n+1): the next version 2 3 Phased Development 2 4  Phased Development Incremental development: starts with small functional subsystem and adds functionality with each new release Iterative development: delivers a full system at the very beginning and then changes the functionality of each subsystem with each new release. 2 5 Phased Development Training on early release Responsive developers Markets for early functionality Quick and Global fixing on unanticipated problems Ability to work on different areas of expertise with different releases 2 6  Prototyping Model Allows repeated investigation of the requirements or design Reduces risk and uncertainty in the development 2 7 Prototyping Model Pros: There is a reduced impact of requirement changes. The customer is involved early and often. It works well for small projects. There is reduced likelihood of product rejection. Cons: Customer involvement may cause delays. There may be a temptation to “ship” a prototype. Work is lost in a throwaway prototype. It is hard to plan and manage. 2 8 References 1. Shari PFleeger, Joanne Atlee, Software Engineering: Theory and Practice, 4th Edition 2. Roger S. Pressman, Software Engineering A Practitioner’s Approach, 9th Edition. McGrawHill 2 9