Stages of Waterfall Software Process Model
- Requirements Analysis & Definition:
The complete service documentation will be prepared in this stage by the developers who will be consulting with the client. The clients will provide their necessities along with constraints and flow of work. The developers will analyze the given information to create the documentation both for developers and for the clients. The next stage starts with this approved document. - System & Software Design:
The system design process then, based on the approved project documentation, defines the software and hardware requirements for the project. The software architecture will be built which will include modules and their relations, databases and their relations At the end of the system, the developers will exactly know what they are going to develop, what are the problems to be solved, how the parts will be integrated etc. - Implementation & Unit Testing:
At this stage all the parts of the systems will be developed and those will be tested separately to find out if each part is working as expected. If bugs were found, those will be solved to. At the end of this stage, all parts of the system are supposed to working accurately as desired. - Integration & System Testing:
At this stage, the approved system parts will be integrated into one complete system. The complete system will then be tested again to see if it meets the requirements approved in the first stage, If any bug were found, those will be solved. - Operation & Maintenance:
At this stage, the fully functional system will be put to real life use. Errors or bugs which will now be discovered will be solved too. The maintenance part continues with system enhancement and along with changes in requirements which might cause new development or changes in system.
Advantages of Waterfall Model:
- Each stage produces a document thus the whole development process remain documented.
- Waterfall model fits with other engineering process models which is an advantage as software engineering is different from other types engineering.
Disadvantages of Waterfall Model:
- It is hard to implement changes at any stage as each stage documented in earlier stage.
- In practical, gaps or bugs or errors can of any stage like design, requirements etc can be discovered at a time while another stage has already been started. Thus it is obviously required to pause the current stage and make changes to documents and rework current stage to suit the changes.
- It is costly if the project requirements has chances of frequent changes.
Waterfall model is generally used for developing parts of larger systems where requirements are fixed.
Prototyping Model :
Often, a customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human/machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach.
Often, a customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human/machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach.
(i) Communication : Firstly, developer and customer meet and define the overall objectives, requirements, and outline areas where further definition is mandatory.
(ii) Quick Plan : Based on the requirements and others of the communication part a quick plane is made to design the software.
(iii) Modeling Quick Design : Based on the quick plane, ‘A Quick Design’ occurs. The quick design focuses on a representation of those aspects of the software that will be visible to the customer/user, such as input approaches and output formats.
(iv) Construction of Prototype : The quick design leads to the construction of a prototype.
(v) Deployment, delivery and feedback : The prototype is evaluated by the customer/user and used to refine requirements for the software to be developed. All these steps are repeated to tune the prototype to satisfy user’s need. At the same time enable the developer to better understand what needs to be done.
Problems With Prototype Model :
Problems With Prototype Model :
(i) In the rush to get the software working the overall software quality or long-term maintainability will not get consideration. So software, in that way, gets the need of excessive modification to ensure quality.
(ii) The developer may choose inappropriate operating system, algorithms, language in the rush to make the prototype working.
Prototyping is an effective paradigm for software engineering. It necessary to build the prototype to define requirements and then to engineer the software with a eye toward quality.
Linear Sequential Model/Waterfall Model/Classic Life Cycle : The linear sequential model, sometimes called theclassic life cycle or the waterfall model, suggests a systematic, sequential approach to software development that begins at the system level and progresses through communication, planning, modeling, construction and deployment. The following given figure illustrates the linear sequential model for software engineering.
(i) Communication : This activity involves heavy communication with customers and other stakeholders in order to gather requirements and other related activities.
(ii) Planning : Here a plan to be followed will be created which will describe the technical tasks to be conducted, risks, required resources, work schedule etc.
(iii) Modeling : A model will be created to better understand the requirements and design to achieve these requirements.
(iv) Construction : Here the code will be generated and tested.
(v) Deployment : Here, a complete or partially complete version of the software is represented to the customers to evaluate and they give feedbacks based on the evaluation.
This is the oldest paradigm of software engineering. However many problems have been encountered when this model is applied. Some of these are described below.
(i) Real projects rarely follow the linear sequential model. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds.
(ii) It is often difficult for the customers to state all the requirements explicitly. This model requires this and has difficulty accommodating the natural uncertainty.
(iii) The customers must have patience. A working version of the program will not be available until late in the project time-span. A major mistake, if undetected until the working program is reviewed, can be disastrous.
RAD Model : Rapid Application Development (RAD) is an incremental software development process model which is a “high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods, such as in 60 to 90 days.
(i) Communication : This step works to understand the business problems and the information characteristics that the software must accommodate.
(ii) Planning : This is very important as multiple teams work on different systems.
(iii) Modeling : Modeling includes the major phases, like business, data, process modeling and establishes design representation that serves as the basis for RAD’s construction activity.
(iv) Construction : This includes the use of preexisting software components and the application of automatic code generation.
(v) Deployment : Deployment establishes a basis for the subsequent repetitions, if required.
Problems with the RAD model : Like others, RAD approach has backwards.
(i) For large but scalable projects, RAD requires sufficient human resources to create the right number of RAD teams.
(ii) If developers and customers are not committed to the rapid fire activities, RAD projects will fail.
(iii) RAD may not be appropriate when technical risks are high.
(iv) If a system can not be properly modularized, building the components will be problematic.
(v) If high performance is be achieved through tuning the interfaces into system components, the RAD approach may not work.
Evolutionary Software Process Model :
Evolutionary software models are iterative. They are characterized in manner that enables the software engineers to develop increasingly more complete version of a software. That is, initially a rapid version of the product is being developed and then the product is developed to more accurate version with the help of the reviewers who review the product after each release and submit improvements. Specification, development and validation are interleaved rather than separate in evolutionary software process model.
These models are applied because as the requirements often change so the end product will be unrealistic, where a complete version is impossible due to tight market deadlines it is better to introduce a limited version to meet the pressure. Thus the software engineers can follow a process model that has been explicitly designed to accommodate a product that gradually complete over time.
Incremental Model : The incremental model combines elements of the linear sequential model with the iterative philosophy of prototyping. The incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable “increment” of the software.
In incremental model, the first increment is often a core product. Here the basic requirements are addressed, but many supplementary features remain undelivered. The core product is used by the customer to develop a plan for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced.
Incremental development is particularly useful when staffing is unavailable for a complete implementation. If the core product is well received with fewer staffs then additional staff, if required), can be added to implement the next increment.
Spiral Model : The spiral model is an evolutionary software process model that combines the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. Using the spiral model, software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.
A spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions. Given figure is of a spiral model that contains five task regions.
model that contains five task regions.
(i) Customer communication — Tasks required to establish effective communication between developer and customer.
(ii) Planning — Tasks required to define resources, timelines, and other project related information.
(iii) Modeling — Tasks required in building one or more representations of the application.
(iv) Construction and release — Tasks required to construct, test, install.
(v) Deployment — Tasks required to deliver the software, getting feedbacks etc.
A spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions. Given figure is of a spiral model that contains five task regions.
model that contains five task regions.
(i) Customer communication — Tasks required to establish effective communication between developer and customer.
(ii) Planning — Tasks required to define resources, timelines, and other project related information.
(iii) Modeling — Tasks required in building one or more representations of the application.
(iv) Construction and release — Tasks required to construct, test, install.
(v) Deployment — Tasks required to deliver the software, getting feedbacks etc.
Software engineering team moves around the spiral in a clockwise direction, beginning at the center. The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from customer evaluation. In addition, the project manager adjusts the planned number of iterations required to complete the software.
The spiral model is a realistic approach to the development of large-scale systems and software. The spiral model enables the developer to apply the prototyping approach at any stage in the evolution of the product. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic. It demands considerable risk assessment expertise and relies on this expertise for success.
The spiral model is a realistic approach to the development of large-scale systems and software. The spiral model enables the developer to apply the prototyping approach at any stage in the evolution of the product. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic. It demands considerable risk assessment expertise and relies on this expertise for success.
Component Based Development : The component-based development (CBD) model incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, the component-based development model composes applications from prepackaged software components, called classes.
The component-based development model leads to software reuse, and re-usability provides software engineers with a number of measurable benefits.
Modeling and construction activities begin with the identification of candidate components. Regardless of the technology that has been used to create the components, the model incorporates the following steps
(i) Available component-based products are researched and evaluated for the application domain in question.
(ii) Component integration issues are considered.
(iii) A software architecture is designed to accommodate the components.
(iv) Components are integrated into the architecture.
(v) Comprehensive testing is conducted to ensure proper functionality.
Comments
Post a Comment