SDLC and Software Process Models
Download as PPTX, PDF8 likes6,094 views
The document discusses software development life cycles (SDLC). It describes the typical stages of an SDLC including feasibility study, requirements analysis, system design, development, testing, implementation, and maintenance. Several SDLC models are mentioned, including waterfall, spiral, iterative, prototyping, and RAD (rapid application development). The waterfall model is described as having distinct sequential stages with no overlap between phases. Prototyping and RAD methodologies are also explained in further detail.
SDLC and Software Process Models
- 1. Lecture tw0 Nana Kwabena Sarpong (J-Prompt Professional Institute of Technology) naksarpong@gmail.com
- 2. A software development life cycle is a set of stages which indicates how we could develop software. It usually shows either a descriptive or prescriptive characterization of how software is or should be developed. Also called SDLC
- 3. SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software.
- 4. A typical Software Development life cycle consists of the following stages: Stage 1: Feasibility Study Stage 2: Requirements Analysis Stage 3: System Design Stage 4: Development Stage 5: Testing Stage 6: Implementation Stage 7: Maintenance
- 5. Ensure delivery of high quality systems Provide strong management controls Maximize productivity
- 6. There are various software development life cycle models defined and designed which are followed during software development process. The are also called Software process Models Water Fall Model * Spiral Model V Model Iterative Model Prototyping * RAD(Rapid Application Development) *
- 7. The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model or classic software life cycle or sequential model or traditional waterfall process model .It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can beg in and there is no overlapping in the phases
- 9. A feasibility study establishes whether or not the project is to proceed. It may be that the system is unnecessary, too expensive or too risky. One approach to a feasibility study is to perform cost-benefit analysis
- 10. All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc. the developer finds out what the user (client or customer) wants the software to do and records the requirements as clearly as possible. The product of this stage is a requirements specification.
- 11. The requirement specifications from first phase are studied in this phase and system design is prepared.
- 12. The detailed designs are converted into instructions written in the programming language. If system is large it is developed into small programs or modules called units . There may be a choice of programming languages, from which one must be selected. The product is the code
- 13. All units of the system coded are tested separately for errors and failures (unit testing). The overall system is also tested(system testing).
- 14. Once all testing is done, the product is deployed in the customer environment or released into the market. At this phase the system is put to use.
- 15. When the software is in use, sooner or later it will almost certainly need fixing or enhancing. Making these changes constitutes maintenance. Software maintenance often goes on for years after the software is first constructed. The product of this activity is the modified software
- 16. Organized approach with specific stages Reflects common engineering practices It is documentation driven, that is, documentation is produced at every stage Simple and easy to understand and use Clearly defined stages. Provides structure to inexperienced staff
- 17. Doesn’t cope well with changes required by the client Development teams might wait for each other The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage. All requirements must be known upfront
- 18. Prototyping is the practice of building an early version of a system which does not necessarily reflect all the features of the final system, but rather those which are of interest.
- 19. In prototyping, the customer is presented at a very early stage with a working version of the system. (It may not be a complete system, but it is at least part of the system and it works.) They can check that it does what they want, or specify modifications. The developer amends the system and demonstrates it again and again until it does what the customer wants. Thus the main purpose of prototyping is ensuring that the user’s needs are satisfied
- 21. In throwaway prototyping the various versions of the system are constructed and then thrown away. (The final system is implemented in some different way.) A throwaway prototype implements only those requirements that are poorly understood. It is discarded after the desired information is learned
- 22. Throwaway prototyping is sometimes called rapid prototyping and as the name suggests, a rapid prototype should cost very little and take very little time to develop.
- 23. This type of prototyping is based on the idea of developing an initial implementation, exposing it to user comment and refining it through repeated stages until an adequate system has been developed
- 24. Evolutionary Prototyping has a very big advantage over Throwaway Prototyping. The advantage is in the fact that evolutionary prototypes are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.
- 25. ▪ Prototypes may be easily changed or even discarded. ▪ Prototyping may improve communication between and among developers and customers ▪ Users may be more satisfied with systems developed using prototyping. ▪ A prototype may provide the proof of concept necessary to attract funding. ▪ A prototype may serve as a marketing tool. ▪ A prototype may serve as the basis for operational specifications. ▪ Early visibility of the prototype may help management assess progress. ▪ Exploratory prototyping allows productive work to proceed despite initial uncertainties. ▪ Prototypes may demonstrate progress at an early stage of development. ▪ Prototypes may provide early training for future users of the system. ▪ Prototyping may prevent unpleasant surprises by calling attention to incomplete or inconsistent requirements, or to missing functionality.
- 26. ▪ Prototyping may encourage an excess of change requests. ▪ Working prototypes may lead management and customers to believe that the final product is almost ready for delivery. ▪ The excellent (or disappointing) performance characteristics of prototypes may mislead the customer. ▪ Customers may not be prepared to provide the level or frequency of feedback required for iterative prototyping. ▪ Customers may not be willing to participate in the iteration cycle over the long haul ▪ Developers may have difficulty writing the back-end code needed to support the slick front-end interface designed with the prototyping tool. ▪ Due to time and market constraints, system specifications may be frozen before the prototyping process has reached a definitive stage. ▪ During prototyping, the only "design specification" is the prototype itself, which may allow uncontrolled change. ▪ Early prototypes may be of low fidelity, dismissed as toys.
- 27. RAD is a linear sequential software development process model that emphasis an extremely short development cycle using a component based construction approach Rapid Application Development as “an approach to building computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques
- 28. Business Modeling: Data Modeling Process Modeling Application Generation Testing and Turn over
- 29. In this phase, define the flow of information within the organization, so that it covers all the functions. Questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on. This helps in clearly understand the nature, type ,source and process of information
- 30. In this phase, convert the component of the information flow into a set of data objects. Each object is referred as an Entity that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined.
- 31. The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. In addition adding , deleting, modifying and retrieving the data objects are included in process modeling.
- 32. In this phase, the generation of the application and coding take place. Using fourth generation programming languages or 4 GL tools is the preferred choice for the software developers
- 33. Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised Resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training.
- 34. Due to emphasis on rapid development , it results in the delivery of fully functional project in short time period. It encourages the development of program component reusable. Can obtain support from automated tools and techniques.
- 35. It requires dedication and commitment on the part of the developers as well as the client to meet the deadline. If either party is indifferent in needs of other, the project will run into serious problem. Its application area is restricted to system that are modular and reusable in nature. It is not suitable for the applications that have a high degree of technical risk. It is not suitable for the large projects because they require more manpower for creating multiple RAD groups.