Software development process models
Download as PPTX, PDF12 likes8,226 views
The document discusses various software development process models, explaining their structures, advantages, and limitations. Key models include the Waterfall, Incremental, Rapid Application Development (RAD), Prototyping, Spiral, and Concurrent Development models, each serving specific project needs and contexts. It emphasizes the importance of adapting models to enhance software quality and manage risks effectively.
Software development process models
- 2. Software Process Model Process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software. Process models are not perfect, but provide roadmap for software engineering work. Software models provide stability, control, and organization to a process that if not managed can easily get out of control Software process models are adapted to meet the needs of software engineers and managers for a specific project.
- 3. Build and Fix Model
- 4. The earlier approach Product is constructed without specification or any attempt at design. Developers simply build a product that is reworked as many times as necessary to satisfy the client. Model may work for small projects but is totally unsatisfactory for products of any reasonable size. Maintenance is high. Source of difficulties and deficiencies impossible to predict impossible to manage
- 5. Why Models are Needed? Symptoms of inadequacy: the software crisis scheduled time and cost exceeded user expectations not met poor quality
- 6. Personal & Team Process Models The Personal Software Process (PSP) shows engineers how to manage the quality of their projects make commitments they can meet improve estimating and planning reduce defects in their products PSP emphasizes the need to record and analyze the types of errors you make, so you can develop strategies eliminate them.
- 7. PSP model Framework Activities Planning – isolates requirements and based on these develops both size & resource estimates. A defect estimate is made. High level Design – external specification of all components. All issues are recorded and tracked. High level Design Review- formal verification to uncover errors Development- metrics are maintained for all important tasks & work results. Postmortem- using measures & metrics collected effectiveness of process is determined an improved.
- 8. The Team Software Process (TSP), along with the Personal Software Process, helps the high-performance engineer to ensure quality software products create secure software products improve process management in an organization TSP Framework Activities Launch high level design Implementation Integration Test postmortem
- 9. Process Models- Prescriptive Models Waterfall Model (classic life cycle, linear sequential model) Suggests a systematic, sequential approach to software development that begins with customer specification of requirement and progresses through planning, modeling, construction and deployment, finishing in ongoing support of the completed s/w.
- 10. The V- Model
- 11. Limitations of the waterfall model 1. Real projects are rarely follow the sequential model. 2. Difficult for the customer to state all the requirement explicitly. 3. Assumes patience from customer - working version of program will not available until late in the project life span. 4. Some teams sit ideal for other teams to finish The model implies that you should attempt to complete a given stage before moving on to the next stage. 5. The model implies that once the product is finished, everything else is maintenance. 6. Delivers a large amount of work products. This model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.
- 12. Incremental Process Model Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. C- Communication P - Planning M – Modeling C - Construction D - Deployment
- 13. First Increment is often core product Includes basic requirement Many supplementary features (known & unknown) remain undelivered A plan of next increment is prepared Modifications of the first increment Additional features of the first increment Incremental model focus more on delivery of operation product with each increment
- 14. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments.
- 15. Increment can be planned to manage technical risks. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. It is particularly useful when enough staffing is not available for the whole project
- 16. Rapid Application Development (RAD) Model Rapid application development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle.
- 17. Communication – to understand business problem. Planning – multiple s/w teams works in parallel on diff. system. Modeling – Business modeling – Information flow among business is working. Ex. What kind of information drives? Who is going to generate information? From where information comes and goes? Data modeling – Information refine into set of data objects that are needed to support business. Process modeling – Data object transforms to information flow necessary to implement business.
- 18. Construction – Highlighting the use of pre-existing software component. Deployment – Deliver to customer basis for subsequent iteration. RAD model emphasize a short development cycle. “High speed” edition of linear sequential model. If requirement are well understood and project scope is constrained then it enable development team to create “ fully functional system” within a very short time period. Makes heavy use of reusable software components with an extremely short development cycle Each major function can be addressed by a separate team and then integrated to form a whole.
- 19. Drawback: For large but scalable projects RAD requires sufficient human resources Projects fail if developers and customers are not committed in a much shortened time-frame Problematic if system can not be modularized Not appropriate when technical risks are high ( heavy use of new technology)
- 20. Evolutionary Process Models Prototyping Model
- 21. Best approach when: Objectives defines by customer are general but does not have details like input, processing, or output requirement. Developer may be unsure of the efficiency of an algorithm, O.S., or the form that human machine interaction should take. It can be used as standalone process model, but commonly used as a technique within the context of any other process model. Model assist software engineer and customer to better understand what is to be built when requirement are fuzzy.
- 22. Prototyping start with communication, between a customer and software engineer to define overall objective, identify requirements and make a boundary. Going ahead, planned quickly and modeling (software layout visible to the customers/end-user) occurs. Quick design leads to prototype construction. Prototype is deployed and evaluated by the customer/user. Feedback from customer/end user will refine requirement and that is how iteration occurs during prototype to satisfy the needs of the customer.
- 23. Prototype can be serve as “the first system”. Both customers and developers like the prototyping paradigm. Customer/End user gets a feel for the actual system Developer get to build something immediately. Prototype Throwaways Evolutionary
- 24. Problem Areas Customer cries foul and demand that “a few fixes” be applied to make the prototype a working product, due to that software quality suffers as a result. Developer often makes implementation in order to get a prototype working quickly without considering other factors in mind like OS, Programming language, etc.
- 25. Spiral Model Couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model
- 26. It provide potential for rapid development of increasingly more complete version of the software. Using spiral, software developed in as series of evolutionary release. Early iteration, release might be on paper or prototype. Later iteration, more complete version of software. Divided into framework activities (C,P,M,C,D). Each activity represent one segment. Evolutionary process begins in a clockwise direction, beginning at the center. Risk is considered as each revolution is made.
- 27. First circuit around the spiral might result in development of a product specification. Subsequently, develop a prototype and then progressively more sophisticated version of software. Each pass through the planning region results in adjustments to the project plan. Unlike other process models that end when software is delivered. It can be adapted to apply throughout the life of software.
- 29. Concept Development Project: Start at the core and continues for multiple iterations until it is complete. If concept is developed into an actual product, the process proceeds outward on the spiral. New Product Development Project: New product will evolve through a number of iterations around the spiral. Later, a circuit around spiral might be used to represent a “Product Enhancement Project” Product Enhancement Project: There are times when process is dormant or software team not developing new things but change is initiated, process start at appropriate entry point. Product Maintenance Project: Once the product is deployed maintenance phase is represented as a circuit around the spiral.
- 30. Spiral models uses prototyping as a risk reduction mechanism but, more important, enables the developer to apply the prototyping approach at each stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but also incorporates it into an iterative framework activity. If risks cannot be resolved, project is immediately terminated Problem Area: It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. If a major risk is not uncovered and managed, problems will undoubtedly occur.
- 31. The Concurrent Development Model Represents iterative and concurrent elements of any of the process models.
- 32. Defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks. It is often more appropriate for system engineering projects where different engineering teams are involved. The activity-modeling may be in any one of the states for a given time. All activities exist concurrently but reside in different states. E.g. The analysis activity (existed in the none state while initial customer communication was completed) now makes a transition into the under development state. Analysis activity moves from the under development state into the awaiting changes state only if customer indicates changes in requirements. Series of event will trigger transition from state to state. E.g. During initial stage there was inconsistency in design which was uncovered. This will triggers the analysis action from the Done state into Awaiting Changes state.
- 33. Visibility of current state of project It define network of activities Each activities, actions and tasks on the network exists simultaneously with other activities ,actions and tasks. Events generated at one point in the process network trigger transitions among the states.
- 34. Specialized Process Models Component Based Development Component-based development (CBD) model incorporates many of the characteristics of the spiral model. It is evolutionary by nature and iterative approach to create software. CBD model creates applications from prepackaged software components (called classes).
- 35. Steps of CBD Available Component Based products are researched and evaluated for the application domain in question Component integration issues are considered. A s/w architecture is designed to accommodate the components Components are integrated into the architecture Comprehensive testing is conducted to ensure proper functionality.
- 37. CBD model leads to software reusability Based on studies, CBD model leads to 70 % reduction in development cycle time. 84% reduction in project cost. Productivity is very high.
- 38. THE FORMAL METHODS MODEL Encompasses a set of activities that leads to formal mathematical specification of computer software. Enable a software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. A variation on this approach, called cleanroom software engineering. Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily, not through ad hoc review but through the application of mathematical analysis. Offers the promise of defect-free software.
- 39. Problems The development of formal models is currently quite time consuming and expensive. Because few software developers have the necessary background to apply formal methods, extensive training is required. It is difficult to use the models as a communication mechanism for technically unsophisticated customers. Best Suited for; safety-critical software
- 40. The Unified Process The Unified Process is an iterative and incremental development process.
- 41. The UP organizes work and iterations across four major phases Inception – approximate vision, business case, scope, vague estimates. NOT a requirements phase, but a feasibility phase Elaboration – refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. A phase where the core architecture is iteratively designed and implemented Construction – iterative implementation of the remaining lower risk and easier elements, preparation for deployment. Transition – beta tests and deployment