DIFFERENT SOFTWARE DEVELOPMENT MODELS.docx

**DIFFERENT SOFTWARE DEVELOPMENT MODELS** **Build-and-Fix Model** Build-and-fix model is a software development model where the entire software product is built and delivered to the client. The client points out what has to be changed and changes are made until the client is satisfied. The product...

**DIFFERENT SOFTWARE DEVELOPMENT MODELS** **Build-and-Fix Model** Build-and-fix model is a software development model where the entire software product is built and delivered to the client. The client points out what has to be changed and changes are made until the client is satisfied. The product then goes into operation mode. Building good functional, maintainable software is a challenging adventure. In spite of this, good and functional software is of paramount importance to almost every human endeavor today. In the earliest days of software development, code was written and then debugged. There was no formal design or analysis. This code and debug approach rapidly became less than optimal as complex software systems were required. Since the approach to developing complex hardware systems was well understood, it provided a model for developing software. This brought about most of the software engineering models. The build-and-fix model does not follow series of stages/phases religiously like the waterfall model. Here, the specification phase, the planning phase, the design phases are all omitted. The development team immediately writes the code and delivers the product to the client who now tests it and points out things to be changed. This means that there is no coherent and cohesive overall structure, and maintenance becomes a big problem. The build-and-fix model should be used when the product is small and there is no possibility of the product ever having to be maintained in the future. For example, if a student is to write a 25-50 line homework problem to solve a particular computational need (e.g. program to keep track of student's record in the class), then it would be a waste of time to specify, plan and design the development effort. **Phases Involved in Build and Fix Model and how it Works** - **Build Phase: in this phase software code is developed and passes on to the next phase** - **Fix Phase: the code developed in this phase is made error free because the code is modified according to the clients requirements.** **Advantages of the Build-and-Fix Model** - It provides immediate feedback to developers: This shows immediate signs of progress - Removes planning/design/documentation overhead. - Suitable for smaller software because it requires little experience to execute or manage than the ability to program - the model can be configured after it is built **Disadvantages of the Build-and-Fix Model** - Much time is spent debugging - Does not promote documentation and therefore produced software is costlier to maintain - Design changes cost much more after coding has started as it requires rework until clients requirements are meant - No real means is available for assessing the progress, quality and risk - Informal design of the software is unplanned procedure - Maintenance is extremely difficult - After the sequences of changes, the codes structure becomes so messy that subsequent corrections become harder to apply and results become less reliable. Life Cycle Phases of Build-and-Fix Model **Spiral Model** The spiral model of software development and evolution represents a risk-driven approach to software process analysis and structuring. The main objective here is to determine the risks involved in developing a particular software and then to resolve each risk in turn. For example, a typical risk is that the delivered software may not satisfy the client's real needs. This type of risk can be taken care of by building a rapid prototype and have the client experiment on it. A project is terminated if at any time it becomes clear that the product to be built will not be cost effective. The spiral model uses the best waterfall model and the rapid prototyping model. This incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. System development in this model therefore spirals out only so far as needed according to the risk that must be managed. Risk analysis, which seeks to identify situations that might cause a development effort to fail or go over budget/schedule, occurs during each spiral cycle. In each cycle, it represents roughly the same amount of angular displacement, while the displaced sweep volume denotes increasing levels of effort required for risk analysis. Spiral model is particularly useful in ADE (Aerospace, Defense and Engineering) projects, because they are risky in nature. They tend to use mature technology and to work well-known problems. Spiral model is also applicable to many business applications, especially those for which success is not guaranteed or the applications require much computation, such as in decision support systems. **Advantages of Spiral Model** - spiral model combines the best features of the waterfall and prototyping models - it address risks associated with software development - it enables the developer to apply prototyping at any stage in the evolution of the software product - it control costs and risk through prototyping - allows for work force specialization facilitates allocation of resources - Does not require a complete set of requirements at the onset. - **Disadvantages of Spiral Model** - the overall cost is comparatively high - it is complicated - it is unstable for small projects were risks are modest - requires considerable risk assessment expertise **Phases involved in Spiral Model** The spiral model's development is divided into four quadrants; planning, risk analysis, engineering, and client evaluation quadrants. Starting at the planning quadrant (innermost quadrant), you move clockwise direction through the quadrants spiraling outwards until you have completed a final product. At each interaction cycle, a progressively more complete version of the prototype is built. At each client evaluation, the engineering work is evaluated and suggestions for modifications are made. The project is terminated if at risk analysis, it is determined that the risks are too much. The figure below illustrates the spiral model. **Advantages of Spiral Model** - Each cycle begin with an identification of stakeholder and their winning conditions, and ends with review and commitment therefore it has strong approval and documentation control. - Every time a new prototype is obtain it is re-evaluated again and again by the customer therefore, more customer is involved it gives room for customer feedback. - There is proper control over cost, time and man power requirement for a project work - Error is eliminated in early phases of the project development - Deployment is very fast **Disadvantages of Spiral Model** - This model required risk identification, projection, risk assessment and risk management because it is not an easy task. Risk analysis required highly specific expertise - The Model I not suitable for a small project - Process is complex as large number of intermediate stages required excessive documentation. - Spiral may go indefinitely **Waterfall Model** Waterfall model is a type of model whereby the software developer follows a well-defined engineering procedure in the development of a software product. The phase to go through include; requirement analysis, specification, design, coding, testing and validation, deployment and maintenance. The waterfall model was derived from engineering models to put order in the development of large software products. The waterfall model consists of several stages/phases which are processed in a linear fashion. Code-and-fix model is very similar to the waterfall model but in this case, the entire product is built and then delivered to the client. The client points out what has to be changed and the developer affects the changes to the satisfaction of the client. In this unit, we shall consider basically the waterfall model and the code-and-fix model. The waterfall model is an approach to software development that emphasizes completing a phase of the development before proceeding to the next phase. The waterfall model was derived from engineering models to put some order in the development of large software product. It consists of different stages which are processed in a linear fashion. In conjunction with certain phase completions, a baseline is established that \"freezes\" the products of the development at that point. If a need is identified to change these products, a formal change process is followed to make the change. The graphic representation of these phases in software development resembles the downward flow of a waterfall. In the waterfall model, no phase is started until the result of the previous phase has been carefully verified. The application of the waterfall model should be in situations where the requirements and the implementation of those requirements are very well understood and also when the software to be produced is large. For example, if a company has experience in building accounting systems, I/O controllers, or compilers, then building another such product based on the existing designs is best managed with the waterfall model. **Phases Involved in Waterfall Model** - **Requirement Stage/Phase**: In this phase (first phase), members of the development team meet with the client (customer) and members of the client organization. Here, the development team aims at determining exactly what the client's needs are. If the client currently has a manual system in place that is to be replaced by the proposed automated products, the developers will obtain a detailed understanding of the manual system and why it is considered inadequate. To help developers gather the needed understanding, developers will have to interview appropriate members of the client's organization. Developers should also study relevant documents (organizational charts, procedure manuals, operational manuals etc). The findings of the requirement team are presented in the form of a document. The document will be thoroughly checked (refined) before proceeding to the next stage. - **Specification Stage/Phase**: Specification is the second stage. At this stage, the development team having ascertained the client's real needs in form of a requirement document draws the specification. A specification document is a written document that states exactly what the proposed system (product) is to do. While drawing the specification document, the developers may obtain more understanding/insights into the client's requirement. If this happens, requirement document will be revisited and amended to reflect the latest discovery. The carefully drawn specification document is presented to the client for checking. The client goes through the specification document and certifies it ok if all is well to him. On the other hand, if the client's notices any error, the correction must be affected before moving on to the next stage. - **Planning Stage/Phase**: This is the third phase of the waterfall model. Once the specification document has been approved by the client, the developers draw up the software project management plan (SPMP). The SPMP usually contains the description of what is to be done, how long it will take, how much it will cost, the human and computer resources that will be needed and a detailed timetable showing who will do what and when. The overall cost of the project is also made known to the client. If the client accepts the above specifications, the design begins. - **The Design Stage/Phase**: This phase consists of two steps: architectural and detailed designs. During the architectural design step, the product is broken down into modules. During the detailed design, each module in turn is designed. The function each module is to carry out what is determined, and what algorithm and data structures are to be used. If any fault in the plan or specification document is detected, the feedback loops takes care of the corrections. This takes us to the implementation stage.  Life Cycle Phases of the Waterfall Model - **Implementation Stage/Phase:** At this stage, each module in turn is coded in the particular programming language specified in the contract. The coded modules are then tested. While this is being done, if any design or specification error is detected, the feedback loops are followed and the fault corrected. - **Integration Stage/Phase:** At this stage, the different modules are brought together (linked) to form a complete system (product). The source code together with all documentations is now tested. When the developers are convinced that the software satisfies its specification document and that all the documentation is correct and complete, the software product is handed over to the client for acceptance testing. Once the client tests and certifies that the product does what it is supposed to do, he/she signs off the product. - **Operation and Maintenance Stage/Phase:** Once the client sign off the product, the product is then installed on the client's computers and it goes into operation mode. From this time on, any changes made to the product whether to the source code or to the documentation are maintenance. - **Maintenance** could be a corrective maintenance (where a fault in the code or documentation is detected and corrected), or an enhancement maintenance (maintenance that involves a change in the requirement). The rightmost dashed line in the figure shows what happens when the requirements are change and these changes in turn trigger changes in the specification document, design document, and implementation of the product. **Advantages of the Waterfall Model** - It enforces a disciplined engineering approach - It is easy to manage because verification and review is done after each phase - Documentation produced can reduce maintenance cost because documentation is produced at every stage - Feedback loops help to correct faults immediately. - The model simple, easy to understand and use **Disadvantages of the Waterfall Model** - Documentation slows down the process - - - - - It lacks flexibility - Generate few visible sign of progress until the very end - Not a good model for complex and object oriented projects - High amount of risk and uncertainty because the customer only see a working version and this may result in disaster if any undetected problem are precipitated to this stage **Incremental Model** The incremental model performs the waterfall in overlapping sections attempting to compensate for the length of waterfall model projects by producing usable functionality earlier. This may involve a complete upfront set of requirements that are implemented in a series of small projects. As an alternative, a project using the incremental model may start with general objectives. Then some portion of these objectives is defined as requirements and is implemented, followed by the next portion of the objectives until all objectives are implemented. **Advantages of the Incremental Model** - The cost of accommodating changing customer requirement is reduced - It is easier to get customer feedback on development work that has been done - More rapid delivery and deployment of useful software to customer is possible, even if all the functionality has not been included - Finding out exactly where the fault is located is easier using incremental implementation **Disadvantages of the Incremental Model** - Managers need regular deliverable to measure progress. If system are developed quickly, it is not cost effective to produce document that reflect every version of the system - System structure tends to degrade as new increment is needed. **Rapid Prototyping Model** Rapid prototyping model is a type of model where the development team gathers information as in waterfall model, and presents their findings in form of a document to the client. After this, they proceed to build a rapid prototype. A prototype is a reduced functionality or a limited performance version of a software system. The key points are to build code rapidly that will show the client the inputs and the outputs in order for the client to say either, "yes that's exactly what I want" or "No what I really want is something else." **Phases Involved in Rapid Prototyping** The phases involved in the rapid prototyping model are similar to that of waterfall model but they are not the same. In rapid prototyping model, the phases start with "rapid prototype". What happens is that the requirement team gathers information as before and presents their findings in form of a document to the client. After presenting their finding to the client, they proceed to build a rapid prototype. The prototype is built as quickly as possible to speed up the software development process. The sole purpose of the prototype is to capture the client's need; once this has been determined, the rapid prototype is effectively discarded. The development team uses information captured from the client to draw up the specification document. From here, the process continues as it is in the waterfall model. Another difference in the rapid prototyping model is that the feedback loop is missing. This is because the rapid prototype built is normally used to capture all the errors/faults to be corrected. Rapid prototype model is used to overcome issues related to understanding and capturing of user's requirements. An essential aspect of rapid prototype is embedded in the word "rapid". The developer should endeavor to construct the prototype as quickly as possible to speed up the software development process. Rapid Prototyping model is very useful to demonstrate technical feasibility when the technical risk is high. It can also be used to better understand and extract user requirements. In either case, the goal is to limit cost by understanding the problem before committing more resources. Prototyping can always be used with the analysis and design portions of objected-oriented model. **Advantages of Rapid Prototyping Model** - Developers can benefit from the experience gained from building - The prototype and apply this experience towards building a better product - gathers client's feedback early in the process to avoid costly redesign later early functionality - Provides a process to perfect the requirements definition. - Provides risk control - Documentation focuses on the end product not the evolution of the product. **Disadvantages of Rapid Prototyping Model** - Adding the rapid prototype will lengthen the requirements phase - Depending on the type of software system, it may not be possible - To build a meaningful prototype without considerable effort - Less applicable to existing systems than to new, original development.