Waterfall Model and Prototyping Model

Waterfall Model

The Waterfall Model is a linear, sequential approach to software/information system development where each phase must be completed before the next phase begins. It follows a strict top-down approach, resembling a waterfall flowing downward. It was one of the earliest SDLC models, proposed by Winston W. Royce in 1970.

Phases of the Waterfall Model:

Each phase acts as an input to the next phase, and once a phase is completed, it is assumed to be final. There is no going back to a previous phase.

Prototyping Model

Prototyping is a form of Rapid Application Development (RAD). Instead of spending a lot of time producing very detailed specifications, the developers find out only generally what the users want. The developers do not develop the complete system all at once. Instead, they quickly create a prototype, which either contains portions of the system or is a small-scale working model of the entire system. After reviewing the prototype with the users, the developers refine and extend it. This process is continued until the final specifications are met.

A prototype is a preliminary working model of the system that demonstrates the functionality but may not contain exact logic or complete features.

Steps in the Prototyping Model:

Step 1: Requirement Gathering

• Basic and initial requirements are identified from the user.
• Developers find out generally what the users want without going into full detail.

Step 2: Quick Design

• When requirements are known, a quick design for the system is created.
• It is not a detailed design and includes only the important aspects of the system.

Step 3: Build Prototype

• Information gathered from the quick design is used to form the first prototype.
• This prototype represents the working model of the required system.

Step 4: User Evaluation

• The proposed prototype is presented to the user.
• The user recognizes its strengths and weaknesses, such as what is to be added or removed.

Step 5: Refine Prototype

• If the user is not satisfied with the prototype, the current prototype is refined with the additional information provided by the user.
• The cycle of build → evaluate → refine continues iteratively.

Step 6: Engineer Final Product

• Once the requirements are completely met, the user accepts the final prototype.
• The final system is then followed by routine maintenance on a regular basis to prevent large-scale failures and minimize downtime.

Diagram of Prototyping Model:

Requirement Gathering
        ↓
   Quick Design
        ↓
  Build Prototype
        ↓
  User Evaluation ←─────────────┐
        ↓                       │
  Satisfied? ──── No ──→ Refine Prototype
        │
       Yes
        ↓
 Engineer Final Product
        ↓
    Maintenance

Merits of the Prototyping Model

1. Active User Involvement -- Users participate throughout the development process, leading to better understanding of requirements.
2. Reduced Risk of Failure -- Errors and misunderstandings are detected early through continuous user feedback.
3. Better Requirement Clarity -- Helps identify missing or unclear requirements at an early stage.
4. Improved Communication -- The prototype serves as a visual and working tool for discussion between users and developers.
5. Faster Initial Delivery -- Users can see a working model quickly, which increases confidence and satisfaction.
6. Flexibility -- Changes can be easily incorporated at early stages before full development begins.

Demerits of the Prototyping Model

1. Increased Cost -- Multiple iterations of building and refining prototypes can be expensive and resource-intensive.
2. Time-Consuming -- Continuous user feedback and revisions may delay the overall project completion.
3. Scope Creep -- Users may keep requesting changes endlessly, expanding the project scope beyond original plans.
4. Poor Documentation -- Focus on rapid prototyping may lead to inadequate or incomplete documentation.
5. User Confusion -- Users may mistake the prototype for the final system, leading to unrealistic expectations.
6. Quality Compromise -- Developers may use shortcuts in the prototype that inadvertently carry over to the final system.

Conclusion

The Waterfall Model is best suited for projects with well-defined and stable requirements, where each phase can be completed sequentially without revisiting. The Prototyping Model, on the other hand, is ideal when requirements are unclear or likely to change, as it allows iterative refinement through active user participation and rapid model building. Both models are important SDLC approaches used in information systems development depending on the nature and complexity of the project.

Feasibility Study: Definition, Categories, and Economic Feasibility Measurement

1. Definition of Feasibility

A feasibility study is an analysis that considers all of a project's relevant factors -- including economic, technical, legal, and scheduling considerations -- to ascertain the likelihood of completing the project successfully. Whether a project is feasible or not can depend on several factors, including the project's cost and return on investment.

In simple terms, feasibility determines whether a proposed system or project is worth pursuing before significant resources are committed to it. It reduces the number of business options and helps the organization decide whether to continue, redirect, or kill a project.

2. Categories of Feasibility

There are four major categories of feasibility studied during system development:

2.1 Economic Feasibility (Cost-Benefit Analysis)

Economic feasibility (also called Cost-Benefit Analysis) is the analysis of a system to determine whether the expected benefits equal or exceed the expected costs.

• The main purpose is to identify the financial benefits and costs associated with the development project.
• During project initiation and planning, it may be impossible to define precisely all benefits and costs.
• Review worksheets are used to record costs and benefits.
• These worksheets are used after each SDLC phase to decide whether to continue, redirect, or terminate the project.

2.2 Technical Feasibility

Technical feasibility evaluates:

• Whether the new system will perform adequately.
• Whether the organization has the ability to construct the proposed system.

Key points:

• All projects carry risk, and that risk is not necessarily something to avoid.
• Organizations typically expect a greater return on investment for riskier projects.
• Potential risks need to be identified as early as possible.

The amount of technical risk associated with a project depends on four primary factors:

2.3 Operational Feasibility

Operational feasibility assesses whether the proposed system will likely solve the business problem or take advantage of identified opportunities.

• It is important to understand how the new system will fit into the existing organizational environment.
• It considers whether users will accept and use the new system.
• It evaluates whether the system will be supported by management and staff.

2.4 Schedule Feasibility

Schedule feasibility determines whether the project can be completed within an acceptable time frame.

• It considers the deadlines and milestones set for the project.
• If the project cannot be delivered on time, it may not be feasible even if it is economically and technically sound.

Note: Schedule and legal feasibility are standard categories supplementing the notes above.

3. Measuring Economic Feasibility

Economic feasibility is measured through Cost-Benefit Analysis (CBA). The steps and methods are as follows:

Step 1: Identify and Estimate Costs

Costs are broadly classified as:

a) Development Costs (One-time costs)

• Hardware and software purchase
• Personnel (analysts, programmers, testers)
• Training costs
• Installation and setup costs

b) Operational Costs (Recurring costs)

• Maintenance and support
• Licensing fees
• Operational staff salaries

Step 2: Identify and Estimate Benefits

Benefits can be:

a) Tangible Benefits (Quantifiable in monetary terms)

• Reduction in operational costs
• Increased revenue or productivity
• Reduction in errors and rework

b) Intangible Benefits (Difficult to quantify)

• Improved customer satisfaction
• Better decision-making
• Enhanced organizational image

Step 3: Apply Measurement Techniques

The following techniques are commonly used to measure economic feasibility:

a) Break-Even Analysis

Determines the point at which total benefits equal total costs.

Break-Even Point = Total Development Cost / (Annual Benefits - Annual Operating Costs)

b) Return on Investment (ROI)

Measures the profitability of the investment.

ROI = (Net Benefits / Total Costs) x 100%

Where:

Net Benefits = Total Benefits - Total Costs

c) Net Present Value (NPV)

Accounts for the time value of money by discounting future benefits to present value.

NPV = Sum of [Benefit(t) / (1 + r)^t] - Initial Cost

Where:

• r = discount rate
• t = time period

If NPV > 0, the project is economically feasible.

d) Payback Period

The time required to recover the initial investment from net benefits.

Payback Period = Initial Investment / Annual Net Benefit

Step 4: Use Review Worksheets

After each SDLC phase, review worksheets are updated with actual and revised cost-benefit data. Based on these worksheets, management decides to:

• Continue the project as planned
• Redirect the project (change scope or approach)
• Kill the project (if costs outweigh benefits)

Summary Table

Conclusion: Feasibility study is a critical early step in the SDLC. Economic feasibility, measured through cost-benefit analysis tools like ROI, NPV, and payback period, is the most critical dimension as it directly determines the financial viability of the proposed system.