Software Development Life Cycle Models PDF

You Tube Display of Waterfall Model https://www.youtube.com/watch?v=Y_A0E1ToC_I https://www.youtube.com/watch?v=bGk9W65vXNA Eniac  Iterative Waterfall Model To overcome the major shortcomings of the classical waterfall model, we come up with the iterative wate...

You Tube Display of Waterfall Model https://www.youtube.com/watch?v=Y_A0E1ToC_I https://www.youtube.com/watch?v=bGk9W65vXNA Eniac  Iterative Waterfall Model To overcome the major shortcomings of the classical waterfall model, we come up with the iterative waterfall model. Fig 3.1 : Iterative Waterfall Model Description Here, we provide feedback paths for error correction as & when detected later in a phase. Though errors are inevitable, but it is desirable to detect them in the same phase in which they occur. If so, this can reduce the effort to correct the bug.  The advantage of this model is that there is a working model of the system at a very early stage of development which makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to take corrective measures in a limited budget.  The disadvantage with this SDLC model is that it is applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules.  Prototyping Model A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut implementation of a function, for example, may produce the desired results by using a table look-up instead of performing the actual computations. A prototype usually turns out to be a very crude version of the actual system. Need for a prototype in software development There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customer’s needs:  how the screens might look like  how the user interface would behave  how the system would produce outputs  Another reason for developing a prototype is that it is impossible to get the perfect product in the first attempt. Many researchers and engineers advocate that if you want to develop a good product you must plan to throw away the first version. The experience gained in developing the prototype can be used to develop the final product.  A prototyping model can be used when technical solutions are unclear to the development team. A developed prototype can help engineers to critically examine the technical issues associated with the product development. Often, major design decisions depend on issues like the response time of a hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the technical issues.. A prototype of the actual product is preferred in situations such as:  User requirements are not complete  Technical issues are not clear  Diagram. Fig 3.2: Prototyping Model  Evolutionary Model It is also called successive versions model or incremental model. At first, a simple working model is built. Subsequently it undergoes functional improvements & we keep on adding new functions till the desired system is built. Applications:  Large projects where you can easily find modules for incremental implementation. Often used when the customer wants to start using the core features rather than waiting for the full software.  Also used in object oriented software development because the system can be easily portioned into units in terms of objects. Advantages:  User gets a chance to experiment partially developed system  Reduce the error because the core modules get tested thoroughly. Disadvantages:  It is difficult to divide the problem into several versions that would be acceptable to the customer which can be incrementally implemented & delivered.  Diagram. Fig 3.3: Evolutionary Model  Spiral Model. The Spiral model of software development is shown in below: Fig 3.4: Diagram of Spiral Model  Spiral Model The Spiral model of software development is shown in fig. 3.4. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study, the next loop with requirements specification, the next one with design, and so on. Each phase in this model is split into four sectors (or quadrants) as shown in fig. 3.4. The following activities are carried out during each phase of a spiral model. First quadrant (Objective Setting)  During the first quadrant, it is needed to identify the objectives of the phase.  Examine the risks associated with these objectives. Second Quadrant (Risk Assessment and Reduction)  A detailed analysis is carried out for each identified project risk.  Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.  Spiral Model Third Quadrant (Development and Validation)  Develop and validate the next level of the product after resolving the identified risks. Fourth Quadrant (Review and Planning)  Review the results achieved so far with the customer and plan the next iteration around the spiral.  Progressively more complete version of the software gets built with each iteration around the spiral. Circumstances to use spiral model The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models – this is probably a factor deterring its use in ordinary projects.. Comparison of all Different Life Cycle Models  The classical waterfall model can be considered as the basic model and all other life cycle models as embellishments of this model. However, the classical waterfall model cannot be used in practical development projects, since this model supports no mechanism to handle the errors committed during any of the phases.  This problem is overcome in the iterative waterfall model. The iterative waterfall model is probably the most widely used software development model evolved so far. This model is simple to understand and use. However this model is suitable only for well-understood problems; it is not suitable for very large projects and for projects that are subject to many risks.  The prototyping model is suitable for projects for which either the user requirements or the underlying technical aspects are not well understood. This model is especially popular for development of the user-interface part of the projects. Comparison of all Different Life Cycle Models  The evolutionary approach is suitable for large problems which can be decomposed into a set of modules for incremental development and delivery. This model is also widely used for object-oriented development projects. Of course, this model can only be used if the incremental delivery of the system is acceptable to the customer.  The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models – this is probably a factor deterring its use in ordinary projects. Comparison of all Different Life Cycle Models The different software life cycle models can be compared from the viewpoint of the customer. Initially, customer confidence in the development team is usually high irrespective of the development model followed. During the lengthy development process, customer confidence normally drops off, as no working product is immediately visible. Developers answer customer queries using technical slang, and delays are announced. This gives rise to customer resentment. On the other hand, an evolutionary approach lets the customer experiment with a working product much earlier than the monolithic approaches. Another important advantage of the incremental model is that it reduces the customer’s trauma of getting used to an entirely new system. The gradual introduction of the product via incremental phases provides time to the customer to adjust to the new product. Also, from the customer’s financial viewpoint, incremental development does not require a large upfront capital outlay. The customer can order the incremental versions as and when he can afford them.  Requirement Analysis and Specification Before we start to develop our software, it becomes quite essential for us to understand and document the exact requirement of the customer. Experienced members of the development team carry out this job. They are called as system analysts. The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be used to develop the requirements of the system. He then analyzes the collected information to obtain a clear and thorough understanding of the product to be developed, with a view to remove all ambiguities and inconsistencies from the initial customer perception of the problem. The following basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good grasp of the problem:  What is the problem?  Why is it important to solve the problem?  What are the possible solutions to the problem?  What exactly are the data input to the system and what exactly are the data output by the system?  What are the likely complexities that might arise while solving the problem?  If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be? After the analyst has understood the exact customer requirements, he proceeds to identify and resolve the various requirements problems. The most important requirements problems that the analyst has to identify and eliminate are the problems of anomalies, inconsistencies, and incompleteness. When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements, he resolves them by carrying out further discussions with the end- users and the customers.  Part of SRC Document Functional requirements of the system Non-functional requirements of the system, and Goals of implementation Functional requirements:- The functional requirements part discusses the functionalities required from the system. The system is considered to perform a set of high-level functions {fi}. The functional view of the system is shown in fig. 3.5. Each function fi of the system can be considered as a transformation of a set of input data (ii) to the corresponding set of output data (oi). The user can get some meaningful piece of work done using a high-level function. Fig. 3.5: View of a system performing a set of functions Non-functional requirements:- Non-functional requirements deal with the characteristics of the system which cannot be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc. Goals of implementation:- The goals of implementation part documents some general suggestions regarding development. These suggestions guide trade-off among design goals. The goals of implementation section might document issues such as revisions to the system functionalities that may be required in the future, new devices to be supported in the future, reusability issues, etc. These are the items which the developers might keep in their mind during development so that the developed system may meet some aspects that are not required immediately. Example: - Consider the case of the library system, where –  F1: Search Book function Input: an author’s name Output: details of the author’s books and the location of these books in the library So the function Search Book (F1) takes the author's name and transforms it into book details. Functional requirements actually describe a set of high-level requirements, where each high-level requirement takes some data from the user and provides some data to the user as an output. Also each high-level requirement might consist of several other functions.  Documenting functional requirements For documenting the functional requirements, we need to specify the set of functionalities supported by the system. A function can be specified by identifying the state at which the data is to be input to the system, its input data domain, the output data domain, and the type of processing to be carried on the input data to obtain the output data. Let us first try to document the withdraw-cash function of an ATM (Automated Teller Machine) system. The withdraw-cash is a high-level requirement. It has several sub-requirements corresponding to the different user interactions. These different interaction sequences capture the different scenarios. Example: - Withdraw Cash from ATM R1: withdraw cash Description: The withdraw cash function first determines the type of account that the user has and the account number from which the user wishes to withdraw cash. It checks the balance to determine whether the requested amount is available in the account. If enough balance is available, it outputs the required cash; otherwise it generates an error message.  R1.1 select withdraw amount option Input: “withdraw amount” option Output: user prompted to enter the account type  R1.2: select account type Input: user option Output: prompt to enter amount  R1.3: get required amount Input: amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of 100. Output: The requested cash and printed transaction statement. Processing: the amount is debited from the user’s account if sufficient balance is available, otherwise an error message displayed Properties of a good SRS document The important properties of a good SRS document are the following:  Concise. The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities.  Structured. It should be well-structured. A well-structured document is easy to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the customer requirements. Often, the customer requirements evolve over a period of time. Therefore, in order to make the modifications to the SRS document easy, it is  Black-box view. It should only specify what the system should do and refrain from stating how to do these. This means that the SRS document should specify the external behaviour of the system and not discuss the implementation issues. The SRS document should view the system to be developed as black box, and should specify the externally visible behaviour of the system. For this reason, the SRS document is also called the black- box specification of a system.  Conceptual integrity. It should show conceptual integrity so that the reader can easily understand it.  Response to undesired events. It should characterize acceptable responses to undesired events. These are called system response to exceptional conditions.  Verifiable. All requirements of the system as documented in the SRS document should be verifiable. This means that it should be possible to determine whether or not requirements have been met in an implementation. Problems without a SRS document The important problems that an organization would face if it does not develop a SRS document are as follows:  Without developing the SRS document, the system would not be implemented according to customer needs.  Software developers would not know whether what they are developing is what exactly required by the customer.  Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system.  It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document.