Download to read offline
More Related Content
Similar to 4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models (1).ppt
4_25655_SE291_2020_1__2_1_Lecture 3 - Software Process Models (1).ppt
- 1. RAPID APPLICATION DEVELOPMENT (RAD) Therapid application development (RAD) model was proposed in the early 90’s in an attempt to overcome the rigidity of the waterfall model. This model has the features of both prototyping and evolutionary models. It deploys an evolutionary delivery model to obtain and incorporate the customer feedbacks on incrementally delivered versions
- 2. Main Motivation The majorgoals of the RAD model are as follows: • To decrease the time taken and the cost incurred to develop software systems. • To limit the costs of accommodating change requests. • To reduce the communication gap between the customer and the developers
- 3. Working of RAD •In the RAD model, development takes place in a series of short cycles or iterations. • At any time, the development team focuses on the present iteration only, and therefore plans are made for one increment at a time. • The time planned for each iteration is called a time box. How does RAD facilitate faster development? • RAD model emphasises code reuse as an important means for completing a project faster. • In fact, the adopters of the RAD model were the earliest to embrace object-oriented languages and practices. • Further, RAD advocates use of specialised tools to facilitate fast creation of working prototypes. These specialised tools usually support the following features: • Visual style of development. • Use of reusable components.
- 4. Applicability of RADModel The following are some of the characteristics of an application that indicate its suitability to RAD style of development: Customised software Non-critical software Highly constrained project schedule Large software RAD unsuitable Generic products (wide distribution) Requirement of optimal performance and/or reliability Lack of similar products Monolithic entity
- 5. Rapid Prototyping Model (contd.) •Rapid prototype characteristics: • Used in the requirements phase • Evaluated by the customer/user • Then, it is discarded -do not turn into product • Rapid prototyping model is not proven and has its own problems • Possible solution • Rapid prototyping for defining requirements • Waterfall model for rest of life cycle
- 6. Incremental Model • IncrementalModel is a process of software development where requirements are broken down into multiple standalone modules of software development cycle. • Each iteration passes through the requirements, design, coding and testing phases. • Typical product takes from 5 to 25 builds (iterations).
- 7.
- 8. Incremental Model (contd.) • Waterfalland rapid prototyping models • Deliver complete product at the end • Incremental model • Deliver portion of the product at each stage • Advantages • The software will be generated quickly during the software life cycle • It is flexible and less expensive to change requirements and scope • Throughout the development stages changes can be done • This model is less costly compared to others • A customer can respond to each building • Errors are easy to be identified
- 9. Incremental Model (contd.) •Disadvantages: • It requires a good planning designing • Problems might arise due to system architecture as not all requirements collected up front for the entire software lifecycle • Each iteration phase is rigid and does not overlap each other • Correcting a problem in one unit requires correction in all the units and consumes a lot of time
- 10. When to useIncremental models? • Requirements of the system are clearly understood • When demand for an early release of a product arises • When software engineering team are not very well skilled or trained • When high-risk features and goals are involved • Such methodology is more in use for web application and product based companies
- 11. Spiral Model • Thespiral model is a risk-driven software development process model. • Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping. • Risk Analysis: Identification of potential risk is done while risk mitigation strategy is planned and finalized • Precede each phase by • Alternatives • Risk analysis • Follow each phase by • Evaluation • Planning of next phase
- 12.
- 13.
- 14. When to useSpiral Methodology? • When project is large • When releases are required to be frequent • When creation of a prototype is applicable • When risk and costs evaluation is important • For medium to high-risk projects • When requirements are unclear and complex • When changes may require at any time • When long term project commitment is not feasible due to changes in economic priorities
- 15. Advantages of SpiralModel • Additional functionality or changes can be done at a later stage • Cost estimation becomes easy as the prototype building is done in small fragments • Continuous or repeated development helps in risk management • Development is fast and features are added in a systematic way • There is always a space for customer feedback
- 16. Disadvantages of Spiral Model •Risk of not meeting the schedule or budget • It works best for large projects only also demands risk assessment expertise • For its smooth operation spiral model protocol needs to be followed strictly • Documentation is more as it has intermediate phases • It is not advisable for smaller project, it might cost them a lot
- 17. Agile Process Models •Agile software engineering combines a philosophy and a set of development guidelines • Philosophy • Encourages customer satisfaction and early incremental delivery of the software • Small highly motivated project teams • Informal methods • Minimal software engineering work products • Overall development simplicity • Development guidelines • Stress delivery over analysis and design • Active and continuous communication between developers and customers
- 18. Agile Process Models(contd.)
- 19. Agile Process Models(contd.)
- 20. Agile vs. WaterfallMethod Agile Model Waterfall Model Agile method proposes incremental and iterative approach to software design Development of the software flows sequentially from start point to end point. The agile process is broken into individual models that designers work on The design process is not broken into an individual models The customer has early and frequent opportunities to look at the product and make decision and changes to the project The customer can only see the product at the end of the project Agile model is considered unstructured compared to the waterfall model Waterfall model are more secure because they are so plan oriented
- 21. Agile vs. WaterfallMethod (contd.) Agile Model Waterfall Model Small projects can be implemented very quickly. For large projects, it is difficult to estimate the development time. All sorts of project can be estimated and completed. Error can be fixed in the middle of the project. Only at the end, the whole product is tested. If the requirement error is found or any changes have to be made, the project has to start from the beginning Development process is iterative, and the project is executed in short (2-4) weeks iterations. Planning is very less. The development process is phased, and the phase is much bigger than iteration. Every phase ends with the detailed description of the next phase. Documentation attends less priority than software development Documentation is a top priority and can even use for training staff and upgrade the software with another team
- 22. Agile vs. WaterfallMethod (contd.) Agile Model Waterfall Model In agile testing when an iteration end, shippable features of the product is delivered to the customer. New features are usable right after shipment. It is useful when you have good contact with customers. All features developed are delivered at once after the long implementation phase. Testers and developers work together Testers work separately from developers At the end of every sprint, user acceptance is performed User acceptance is performed at the end of the project. It requires close communication with developers and together analyze requirements and planning Developer does not involve in requirement and planning process. Usually, time delays between tests and coding
- 23. Extreme Programming (XP) • Somewhatcontroversial new approach; variation of the incremental model • First step • Determine features that client wants (stories) • Estimate duration and cost of each feature • Client selects stories for each successive build • Each build is divided into tasks • Test cases for a task are drawn up • Pair programming –working with a partner on one screen • Continuous integration of tasks
- 24.
- 25. Features of XP •Computers are put in center of large room lined with cubicles • Client representative works with the XP team at all the times • Individual cannot work overtime for 2 successive weeks • There is no specialization • all members of the XP team work on specification, design, code, and testing • There is no overall design phase before various builds are constructed – Refactoring
- 26. Advantages of AgileModel • Customer satisfaction by rapid, continuous delivery of useful software. • People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other. • Working software is delivered frequently (weeks rather than months). • Face-to-face conversation is the best form of communication. • Close, daily cooperation between business people and developers. • Regular adaptation to changing circumstances. • Even late changes in requirements are welcomed
- 27. Disadvantages of Agile model •In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. • There is lack of emphasis on necessary designing and documentation. • The project can easily get taken off track if the customer representative is not clear what final outcome that they want. • Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.
- 28. When to useAgile model • When new changes need to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced. • To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it. • Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. • Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; meaning the project can continue to move forward without fear of reaching a sudden standstill.
- 29. Unified Process • Unifiedprocess is a framework for OO software engineering using UML (Unified Modeling Language) • Unified process (UP) is an attempt to draw on the best features and characteristics of conventional software process models, but characterize them in a way that implements many of the best principles of agile software development.
- 30. Unified Process Characteristics • Itis an iterative and incremental development framework • It is architecture-centric with major work being done to define and validate an architectural design for most coding is done • It is risk-focused and emphasizes that highest-risk factors be addressed in the earliest deliverables possible • It is use-case and UML model driven with nearly all requirements being documented in one of those forms
- 31. Unified Process: Phases •Inception phase • Encompasses the customer communication and planning activities • Rough architecture, plan, preliminary use-cases • Elaboration phase • Encompasses the customer communication and modeling activities • Refines and expands preliminary use-cases • Expands architectural representation to include: use-case model, analysis model, design model, implementation model, and deployment model • The plan is carefully reviewed and modified if needed
- 32. Unified Process: Phases •Construction phase • Analysis and design models are completed to reflect the final version of the software increment • Using the architectural model as an input develop or acquire the software components, unit tests are designed and executed, integration activities are conducted • Use-cases are used to derive acceptance tests • Transition phase • Software is given to end-users for beta testing • User report both defects and necessary changes • Support information is created (e.g., user manuals, installation procedures) • Software increment becomes usable software release
- 33.
- 35. How to Choosebetween SDLC Methods?
- 36. How to Choosebetween SDLC Methods? • To know which is the best model out of all the different types of SDLC models, it is important to understand that each of these approaches are suitable for different projects, environments, and requirements. • For example, if your project is simple and straightforward with set requirements that do not need to be changed, then Waterfall is best suited for it. • However, if your project is large-scale and consists of multiple components and segments, then choosing Iterative or Spiral methodology would suit your project better.
- 37. How to Choosebetween SDLC Methods? • To answer the question simply, there is no ONE model is best from all the SDLC models discussed. • A preference of one method over the others cannot be determined. • However, to select the right SDLC methodologies, you should know all the types of SDLC models, assess the requirements of all the stakeholders and then decide on a method that best fits your needs.
- 38. Criteria for decidingon a model include • Criteria for deciding on a model include • Product Complexity • Product Size • Magnitude of Changes • Frequency of Changes • Skills of the Dev Team • Time constraints • Access to Users
- 39.