Model of SDLC
Planning->Analysis->Design->Implementation-maintenance
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.They are
1) Waterfall Model
2) Spiral Model
3) RAD(Rapid Application Model)
4) Incremental Model
5) Prototype Modelling
6) Agile Model
7) Big Bang Model
8) V model
Strength and Weakness of SDLC
Waterfall Model
A project using waterfall model moves down a series of steps starting from an initial idea to a final product. At the end of each step, the project team holds a review to determine if they’re ready to move to the next step. If the project isn’t ready to progress, it stays at that level until it’s ready. Each phase requires well-defined information, utilizes well-defined process, and results in well-defined outputs. Resources are required to complete the process in each phase and each phase is accomplished through the application of explicit methods, tools and techniques.
The Waterfall model is also called the Phased model because of the sequential move from one phase to another, the implication being that systems cascade from one level to the next in smooth progression. It has the following seven phases of development:
The figure represents the Waterfall Model.
Notice three important points about this model.
There’s a large emphasis on specifying what the product will be.
The steps are discrete; there’s no overlap.
There’s no way to back up. As soon as you’re on a step, you need to complete the tasks for that step and then move on.
Spiral Model
The traditional software process models don't deal with the risks that may be faced during project development. One of the major causes of project failure in the past has been negligence of project risks. Due to this, nobody was prepared when something unforeseen happened. Barry Boehm recognized this and tried to incorporate the factor, project risk, into a life cycle model. The result is the Spiral model, which was first presented in 1986. The new model aims at incorporating the strengths and avoiding the different of the other models by shifting the management emphasis to risk evaluation and resolution.
Each phase in the spiral model is split into four sectors of major activities.
These activities are as follows:
Objective setting:
This activity involves specifying the project and process objectives in terms of their functionality and performance.
Risk analysis:
It involves identifying and analyzing alternative solutions. It also involves identifying the risks that may be faced during project development.
Engineering:
This activity involves the actual construction of the system.
Customer evaluation:
During this phase, the customer evaluates the product for any errors and modifications.
RAD Model
RAD (rapid application development) is a concept that products can be developed faster and of higher quality through:Also sometimes referred to as Rapid Prototyping, Rapid Application Development is a method of decreasing the time taken to design software systems. It uses incremental development and the construction of prototypes - and encourages constant feedback from users/customers by keeping lines of communication clear - with the end goal of expediting the development cycle.
* Gathering requirements using workshops or focus groups
* Prototyping and early, reiterative user testing of designs
* The re-use of software components
* A rigidly paced schedule that defers design improvements to the next product
version
* Less formality in reviews and other team communication
Rapid Application Development encouraged the creation of quick-and-dirty prototype-style software which fulfilled most of the user’s requirements but not necessarily all. Development would take place in a series of short cycles, called time boxes, each of which would deepen the functionality of the application a little more. Features to be implemented in each time box were agreed in advance and this game plan rigidly adhered to. The strong emphasis on this point came from unhappy experience with other development practices in which new requirements would tend to be added as the project was evolving, caused massive chaos and disrupting the already carefully prepared plans and development schedules. Rapid Application Development methodology advocated that development be undertaken by small, experienced teams using CASE (Computer Aided Software Engineering) tools to enhance their productivity.
Prototype model
The Prototyping model, also known as the Evolutionary model, came into SDLC because of certain failures in the first version of application software. A failure in the first version of an application inevitably leads to need for redoing it. To avoid failure of SDLC, the concept of Prototyping is used. The basic idea of Prototyping is that instead of fixing requirements before the design and coding can begin, a prototype is to understand the requirements. The prototype is built using known requirements. By viewing or using the prototype, the user can actually feel how the system will work.
The prototyping model has been defined as:
“A model whose stages consist of expanding increments of an operational software with the direction of evolution being determined by operational experience.”
Prototyping Process
The following activities are carried out in the prototyping process:
The developer and die user work together to define the specifications of the critical parts of the system.
The developer constructs a working model of the system.
The resulting prototype is a partial representation of the system.
The prototype is demonstrated to the user.
The user identifies problems and redefines the requirements.
The designer uses the validated requirements as a basis for designing the actual or production software
Prototyping is used in the following situations:
When an earlier version of the system does not exist.
When the user's needs are not clearly definable/identifiable.
When the user is unable to state his/her requirements.
When user interfaces are an important part of the system being developed.
Bin – Bang Model
The Big- Bang Model is the one in which we put huge amount of matter (people or money) is put together, a lot of energy is expended – often violently – and out comes the perfect software product or it doesn’t.
The beauty of this model is that it’s simple. There is little planning, scheduling, or Formal development process. All the effort is spent developing the software and writing the code. It’s and ideal process if the product requirements aren’t well understood and the final release date is flexible. It’s also important to have flexible customers, too, because they won’t know what they’re getting until the very end.
Incremental Model
Incremental model is an evolution of waterfall model. The product is designed, implemented, integrated and tested as a series of incremental builds. It is a popular model software evolution used many commercial software companies and system vendor.
Incremental software development model may be applicable to projects where:
- Software Requirements are well defined, but realization may be delayed.
- The basic software functionality are required early.
Advantages are
- Generates working software quickly and early during the software life cycle.
- More flexible - less costly to change scope and requirements.
- Easier to test and debug during a smaller iteration.
- Easier to manage risk because risky pieces are identified and handled during
its iteration.
Disadvantages are
- Each phase of an iteration is rigid and do not overlap each other.
- Problems may arise pertaining to system architecture because not all
requirements are gathered up front for the entire software life cycle.
V model
The V-Model, also called the Vee-Model, is a product-development process originally developed in Germany for government defense projects. It has become a common standard in software development. The V-Model gets its name from the fact that the process is often mapped out as a flowchart that takes the form of the letter V.
The development process proceeds from the upper left point of the V toward the right, ending at the upper right point. In the left-hand, downward-sloping branch of the V, development personnel define business requirements, application design parameters and design processes. At the base point of the V, the code is written. In the right-hand, upward-sloping branch of the V, testing and debugging is done. The unit testing is carried out first, followed by bottom-up integration testing. The extreme upper right point of the V represents product release and ongoing support.
The V-Model has gained acceptance because of its simplicity and straightforwardness. However, some developers believe it is too rigid for the evolving nature of IT (information technology) business environments.
The V-model consists of a number of phases. The Verification Phases are on the right hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the left hand side of the V .
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, it 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 are 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. -to develop
No comments:
Post a Comment