Methods
Life cycle models describes the inter-relationships between software development phases.
The common life cycle models are:
* Waterfall Model
* Spiral Model
* V-Model
* Prototyping Model
* Evolutionary Development Model
* Reusable Software Model
* Synchronize and Stabilize Model
Since the life cycle steps are described in general terms, the models are adaptable and their implementation details will vary among different organizations. The spiral model is the most general. Most life cycle models can infact be derived as special instances of the spiral model. Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities.
Waterfall Model
This is also known as Classic Life Cycle Model (or) Linear Sequential Model (or) Waterfall Method. This has the following features:
* It is least flexible and most obsolete of the life cycle models.
* It is well suited to projects that has low risk in the areas of user interface and performance requirements, but high risk in budget and schedule predictability and control.
Stages involved in Software development process:
1. System Engineering and Modeling
2. Software Requirements Analysis
3. Systems Analysis and Design
4. Code Generation
5. Unit Testing
6. Integration Testing
7. System Testing
8. Operation
9. Maintenance
The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in the Figure. In this model each phase has a well defined starting and ending point, with identifiable deliveries to the next phase.
System/Information Engineering
As software is always of a large system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system.
Feasibility:
Defining a preferred concept for the software product and determining its life-cycle feasibility and superiority to alternative concepts.
Requirements:
A complete, verified specification of the required functions, interfaces, and performance for the software product.
Product Design:
A complete verified specification of the overall hardware-software architecture, control structure, and data structure for the product, along with such other necessary components as draft user's manuals and test plans.
Detailed Design:
A complete verified specification of the control structure, data structure, interface relations, sizing, key algorithms and assumptions of each program component.
Coding:
A complete, verified set of program components. A proper functional software product composed of the software components.
Implementation:
A fully functioning operational hardware-software system, including such objectives as program and data conversion, installation and training.
Maintenance:
A fully functioning update of the hardware-software system repeated for each update.
Phaseout:
A clean transition of the functions performed by the product to its successors.
Advantages
* Testing is inherent to every phase of the waterfall model
* It is an enforced disciplined approach
* It is documentation driven, that is, documentation is produced at every stage
Disadvantages
* It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
* As the client usually has a vague idea of exactly what is required from the software product, the Waterfall Model has difficulty accommodating the natural uncertainty that exists at the beginning of the project.
* The customer only sees a working version of the product after it has been coded which may result in disaster. Any undetected problems are precipitated to this stage.
Strengths and Weakness of different Software Development Life Cycle Models:
Waterfall Model:
waterfall performs well for products with clearly understood requirements or when working with well understood technical tools, architectures and infrastructures. It's weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.
Strengths
* Minimizes planning overhead since it can be done up front.
* Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff.
Weaknesses
* Inflexible.
* Only the final phase produces a non-documentation deliverable.
* Backing up to address mistakes is difficult
Spiral Model
The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks. After major risks have been addressed, the spiral model terminates as a waterfall model.
Strengths
* Early iterations of the project are the cheapest, enabling the highest risks to be addressed at the lowest total cost. This ensures that as costs increase, risks decrease.
* Each iteration of the spiral can be tailored to suit the needs of the project.
Weaknesses
* It is complicated and requires attentive and knowledgeable management to pull it off.
Prototype Models:
Prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration.
Strengths
* Customers can see steady progress.
* This is useful when requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements or when no one fully understands the application area.
Weaknesses
* It is impossible to know at the outset of the project how long it will take.
* There is no way to know the number of iterations that will be required.
Code-and-Fix
If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk. Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes.
Strengths
* No time spent on "overhead" like planning, documentation, quality assurance, standards enforcement or other non-coding activities.
* Requires little experience.
Weaknesses
* Dangerous.
* No means of assessing quality or identifying risks.
* Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out.
