A systems development lifecycle (SDLC) has three primary objectives: ensure that high quality systems are delivered, provide strong management controls over the projects, and maximize the productivity of the systems staff. In order to meet these objectives the SDLC has many specific requirements it must meet, including: being able to support projects and systems of various scopes and types, supporting all of the technical activities, supporting all of the management activities, being highly usable, and providing guidance on how to install it. The technical activities include: system definition (analysis, design, coding), testing, system installation (e.g., training, data conversion), production support (e.g., problem management), defining releases, evaluating alternatives, reconciling information across phases and to a global view, and defining the project's technical strategy. The management activities include: setting priorities, defining objectives, project tracking and status reporting, change control, risk assessment, step wise commitment, cost/benefit analysis, user interaction, managing vendors, post implementation reviews, and quality assurance reviews. In order to meet all of the SDLC's objectives and requirements there are certain design approaches that are required: the SDLC must be an example of a system created using the techniques it espouses; it must use a layered approach to analysis, design, installation support and production support; it must keep distinct the "what" from the "how" in regards to doing the tasks and creating the outputs; and it must organize its information in a hierarchical manner so that users with varying degrees of familiarity can find what they want easily and quickly. Defining or selecting an SDLC should be undertaken as a project with full time resources who have the appropriate level of expertise. It is an extremely high leverage effort. It also represents a major cultural change for the staff. It must be planned and executed in as professional a manner as possible.
A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize". SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results. Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software. In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".
Now after discussing all about SDLC I will now discuss the 3 systems development model that I had identified. First one is the waterfall model, or the most traditional model of all SDLC. According to wikipedia.org a waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance
Advantages of Waterfall Model
1. Clear project objectives.
2. Stable project requirements.
3. Progress of system is measurable.
4. Strict sign-off requirements.
Disadvantages of Waterfall Model
1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes
The Waterfall Model is the classic software life cycle model. According to Schach [1999], this model was the only widely accepted life cycle model until the early 1980s. This model represents the software life cycle using processes and products. Each process transforms a product to produce a new product as output. Then the new product becomes the input of the next process. The table below lists the processes and products of the Waterfall Model.
| Input Product | Process | Output Product |
| Communicated Requirements | Requirements Engineering | Requirements Specification Document |
| Requirements Specification Document | Design | Design Specification Document |
| Design Specification Document | Programming | Executable Software Modules |
| Executable Software Modules | Integration | Integrated Software Product |
| Integrated Software Product | Delivery | Delivered Software Product |
| Delivered Software Product | Maintenance | Changed Requirements |
Notice that the output product on the right becomes the input product on the left of the process at the next lowest level. The general formula for describing the transformation of products by processes can be written as follows:
Each product is represented by a gray box and each process is represented by a solid arrow connecting the boxes. To learn more about these processes and products, view the Waterfall Model animation below.
So I think I have all discuss all the important things that are needed for you to understand all about the waterfall model, now we will go on to the next stage which is the V-model. According to wikipedia.org a v-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time. The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V. As shown below;
Verification Phases
Requirements analysis
In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. See also Functional requirements, its is to develop in testing in now a days
System Design
Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:
• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.
The unit test design is developed in this stage.
Validation Phases
Unit Testing
In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer. It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing
System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.
User Acceptance Testing
Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.
V-Model advantages:
• It is also called as verification and validation Model.
• This means the verification and validation will be done side by side.
• It emphasis the strict process flow to develop a quality product.
• The errors occurred in any phase will be corrected in that phase itself.
V-Model disadvantages:
• It needs lot of resources and money.
• It needs an established process to implement.
• It can be implemented by only some big companies.
So lastly, we wll now go to the last example which is the spiral model. According to wikipedia.org a spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
History of the spiral model
The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software Development and Enhancement”. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.
Steps
The steps in the spiral model iteration can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
• evaluating the first prototype in terms of its strengths, weaknesses, and risks;
• defining the requirements of the second prototype;
• planning and designing the second prototype;
• constructing and testing the second prototype.
Spiral mostly Used
Game development is a main area where the spiral model is used and needed, that is because of the size and the constantly shifting goals of those large projects. The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003 - 2009), it had a 2 year iteration (spiral). FCS should have resulted in 3 consecutive prototypes (one prototype per spiral - every 2 years). It was canceled in May, 2009
Advantages
1. This model improves avoidance of risk
2. This model is very useful to choose a methodology for a software iteration
3. This model can associate other methodologies like Waterfall, Prototyping, and Incremental methodologies. Suppose a project having a low risk of not meeting the user requirement and on other side having high risk of missing budget would follow waterfall approach
4. In this model more functionality can be added in later versions.
Disadvantages
1. This model limiting reusability
2. This model is quite complex
3. Spiral model is very customized for every project
4. To use this model an experienced and skilled team required
5. There is no proper control to move from one cycle to another cycle
In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the spiral), Boehm [1988] used the template below for risk assessment during the development of a software productivity tool. The rows of the template represented various management elements of the project. For each new phase, he created a new instance of the template to review the status of the project and decided whether the risks were too great to continue. To illustrate the use of the template, the rows have been filled with a fictitious example phase [Sommerville 1996].
| Template | Explanation | Example Phase |
| Objectives | The goals of the software project | Significantly improve software quality |
| Constraints | Limitations which the project must meet | Within three years |
| Alternatives | Possible ways to achieve the objectives | Reuse existing certified software |
| Risks | Potential risks for this phase | No cost effective quality improvement possible |
| Risk Resolution | Strategies for reducing the risks | Literature survey, Pilot project, Survey of potential reusable components, Assessment of available tool support, Staff training and motivation seminars |
| Results | Results of applying risk resolution strategies | Experience of formal methods is limited - very hard to quantify improvements |
| Plans | Development plans for the next phase | Explore reuse option in more detail |
| Commitment | Resources needed to achieve the plans | Fund further 18-month study phase |
In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff know very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components.
So to summarized it all, I had identified and discuss 3 examples of a systems development models. There are many systems development models that are available. It depends on what do you want to use in order to help you achieve what you are achieving for.
References:
http://www.blurtit.com/q7769291.html
http://courses.cs.vt.edu/csonline/SE/Lessons/Spiral/index.html
http://en.wikipedia.org/wiki/Spiral_model
http://www.allinterview.com/showanswers/33292.html
http://en.wikipedia.org/wiki/V-Model_(software_development)
http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/index.html
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://benderrbt.com/Bender-SDLC.pdf
http://www.blurtit.com/q533918.html
