Spiral Model vs. Waterfall Model: A Comparative Analysis

Posted on Mar 2, 2024 in Computers

• The spiral model is a risk-driven process model generator for software projects.

• This Spiral model is a combination of iterative development process model and sequential linear development model.

• i.e. the waterfall model with a very high emphasis on risk analysis. It allows incremental releases of the product or incremental refinement through each iteration around the spiral.

• The spiral model has four phases.

• A software project repeatedly passes through these phases in iterations called Spirals.

Identification

• Starts with gathering the business requirements in the baseline spiral
• Also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral, the product is deployed in the identified market.

Evaluation and Risk Analysis

• Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of the first iteration, the customer evaluates the software and provides feedback.

Design

• Starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and the final design in the subsequent spirals.

Construct or Build

• Refers to production of the actual software product at every spiral.
• In the baseline spiral, when the product is just thought of and the design is being developed a POC (Proof of Concept).
• Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. These builds are sent to the customer for feedback.

Spiral Model Application

• When there is a budget constraint and risk evaluation is important.
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the case.
• Significant changes are expected in the product during the development cycle.

Pros of Spiral Model

• Allows elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design.
• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.
• Users see the system early.

Cons of Spiral Model

• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low-risk projects and could be expensive for small projects.
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive documentation

Waterfall Model

• The Waterfall Model was the first Process Model.

• It is also referred to as a linear-sequential life cycle model.

• It is very simple to understand and use.

• In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

• In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

• Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document. • System Design − The requirement specifications from the first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and software requirements and helps in defining the overall system architecture.  • Development − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.   • Integration and Testing − All the units developed in the development phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.  • Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market. • Maintenance − There are some issues which come up in the client environment. To fix those issues and to update the system on the latest version, maintenance is done.  

Waterfall Model – Advantages

• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

Waterfall Model – Disadvantages

• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• It is difficult to measure progress within stages. 

 SRS Characteristics.

1.Complete: An SRS is complete when it is documented after. 1. Involvement of all staff 2. Focusing on all problems, goals and objectives and not only on functions and features. 3. Correct definition of scope and boundaries of the system. 2.Consistent: Consistency achieved in SRS by  Use of standard terms and definitions  Consistent application of business rules and procedures  Use of data dictionary 3.Correct: An SRS is correct if every requirement if every requirement included in the SRS represents something required in the final system. 4.Modifiable: Having the same requirement at more than one place may not always be wrong but it makes a document un-maintainable. If only one occurrence of the requirement is stated into two places and if the requirement later needs changes, if only one occurrence is modified the resulting SRS will become inconsistent.So,SRS must be modifiable 5.Ranked:Allrequirements are not equally important. Some are critical but importants.Some are core requirements which are not likely to change as time passes while others are dependent on time. So SRS should me ranked. 6.Testable: An SRS must be stated in such manner that we can test it against a pass/Fail or quantitative assessment criteria derived from the SRS itself. 7.Traceable: An SRS is traceable if the origin of its requirements explicitly referencing of each requirement in future development or documentation enhancement.Two types of traceability 7.1.Backward Traceability: It depends upon each requirement explicitly referencing its source in earlier documents.

7.2.Forward Traceability: It depends upon each requirement in SRS having a unique name or reference number. 

8. Unambiguous: An SRS is unambiguous if and only if every requirement stated or has one and only one interpretation. 9. Valid: To validate the SRS, the entire development team and the customer must be able to understand, analyse, accept and approve it. 10. Verifiable: An SRS is verifiable if only every stated requirement is verifiable. The requirement is verifiable if there exist some cost-effective process that can check whether the final software needs the requirements. This implies that the requirement should be as little subjective as possible because subjective requirements are difficult to verify.

Requirement gathering techniques 1. Interview: Interview is a fact-finding technique where two parties work together. One is the interviewer and the other is the interviewee. The person who collects information is known as a system analyst. Types of Interview 1. Structured; Where the interviewee is asked a standard set of questions in a particular order All interviewees are asked the same set of questions Eg, “Are you satisfied with the current product?”

2. Unstructured  Undertaken in a question and answer format  More flexible than structured Interview  Rightly used to gather general information about the system Pros::  Useful for those individuals who cannot communicate effectively in writing  Allow the analyst to determine areas of confusion, impractical prospect and even indicate to the points for resistance to the proposed system  It is considered as the best qualitative source of the interview  Permit the interviewees to reply freely and openly to any type of questions Cons::  Interviews are considered as time-consuming and costly fact-finding techniques  Interviews can be subject to bias if the interviewer has a closed mind about the difficulty  This technique fails if a suitable environment is not provided for conducting an interview. 2. Questionnaires  Methods of information gathering where the potential users of the system are given questionnaires to be filled up and returned to the analyst.  Questionnaires are special purpose documents that allow the analyst to collect information and opinions from respondents. Types of questionnaires

1. Structured  Respondent needs to select from possible options for answers and thus the range of answers is limited Eg, MCQ, Selection of ranking scale, selection of a rating and fill in the blanks 2. Unstructured  Respondents are freely to give answer  Such questions are open-ended Pros  Questionnaires are considered as an economical way of collecting facts from a huge number of people  If it is well formatted and designed, then the results can be easily analyzed and computerized  Respondents get time to think over the questions and provide more accurate data Cons  Good questionnaires are difficult to construct. 3. Record Review(Recording Outcome)  Records and review are the gathering of information and data collected over time by the users about the system and its operation  For a better understanding of any existing system is to review its related records, existing documents, forms or files  This process is known as reviewing of existing records or record review  It starts at the preliminary stage of the system study or later on in the study for measuring actual operations with what the record indicates  Records and reports may have a limitation if they are not up to date or if some essential links are missing 4. Observation  System analyst known as on-site observation or direct observation where the analyst personally goes to the site and discovers the functioning of the system Analyst can get direct knowledge of the activities, operations, processes of the system on-site, Hence here the role of an analyst is of an information seeker.  This technique is useful when one needs to actually observe how documents are handled, how operations and activities are carried out Advantages  Facts gathered using this technique are highly reliable  Inexpensive way of collecting data  System analyst can make out tasks that have been missing or wrongly illustrated by other fact-finding techniques Disadvantages  Time-Consuming  Analyst should not jump to conclusions or draw assumptions from minute samples of observation rather the analyst should be more patient in gathering the information 5. Join Application Development (JAD)  JAD (Joint Application Development) is a methodology that involves the client or end-user in the design and development of an application, through a succession of collaborative workshops called JAD sessions.’

Chuck Morris and Tony Crawford, both of IBM, developed JAD in the late 1970s and began teaching the approach through workshops in 1980.  The JAD approach, in comparison with the more traditional practice, is thought to lead to faster development times and greater client satisfaction because the client is involved throughout the development process.  In comparison, in the traditional approach to systems development, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews.  A variation on JAD, rapid application development (RAD) creates an application more quickly through such strategies as using fewer formal methodologies and reusing software components. JAD concept is based on four ideas  Users who do the job have the best understanding of that job  The developers have the best understanding of how technology works  The business process and the software development process work the same basic way  The best software comes out of a process that all groups work as equals and as one Pros  JAD actively involves users and management in the development project  JAD helps to avoid the requirements from being too specific which cause trouble during implementation and acceptance  JAD reduces the amount of time required to develop systems since it eliminates process delays and misunderstanding and improves system quality Cons  Slow communication and long feedback time  Weak or no support from upper management 6. FAST (Facilitated Application Specification Technique)  It is a technique for requirements abstraction for software development.  The objective is to close the gap between what the developers intend and what users expect.  It is a team-oriented approach for gathering requirements. Basic guidelines 1. Meetings are conducted at a neutral site attended by both developers and users. 2. The group establishes rules for preparation and participation. 3. An agenda is to cover all important points and free flow of ideas. 4. A facilitator controls the meeting. 5. A definition mechanism is used. -The main goal is to identify the problem, propose solutions, negotiate different approaches, and specify a preliminary set of software requirements. – After the initial meeting, the user and developer should write a one or two product request form. -Before the next meeting, it is distributed to all other attendees. Each attendee is asked to make the following lists: 1. List of objects 2. List of services 3. List of constraints 4. Performance criteria Representatives of FAST 1. Marketing person 2. Software and hardware engineer 3. Representative from manufacturing 4. An outside facilitator  Record Review(Recording Outcome)  Records and reports are the gathering of information and data collected over time by the users about the system and its operations.  This procedure is known as reviewing of existing records or record review.  It starts at the preliminary stage of the system study or later on in the study for measuring actual operations with what the records indicate.  Records and reports may have a limitation if they are not up-to-date or if some essential links are missing