Prototyping Model

Definition

The Prototyping Model is a software development approach in which a working prototype (an early, incomplete version of the system) is built, evaluated by the user, and iteratively refined based on feedback until the final system is developed.

: "Instead of spending a lot of time producing very detailed specifications, the developers find out only generally what the users want... they quickly create a prototype, which either contains portions of the system or is a small-scale working model of the entire system."

Concept

Rather than freezing all requirements before design or coding begins, a prototype is created to help users visualize and validate the system. The prototype is refined repeatedly until the customer is satisfied, after which the final engineered product is delivered.

Phases of the Prototyping Model

a) Requirement Gathering

Basic and general requirements are collected from the customer. Complete details are not required at this stage.

b) Quick Design

A simple, quick design is prepared focusing on important aspects such as user interface and input/output formats. It is not a detailed design.

c) Build Prototype

Information gathered from the quick design is used to construct the first working prototype, which represents a working model of the required system.

d) User Evaluation

The prototype is presented to the user, who evaluates it and identifies its strengths and weaknesses, such as what needs to be added or removed.

e) Refine Prototype

If the user is not satisfied, the prototype is refined using the additional information provided by the user. Steps (b) through (e) are repeated iteratively.

f) Engineer Product

Once requirements are completely met and the user accepts the final prototype, the complete final system is engineered with proper coding, testing, and documentation. Routine maintenance follows to prevent large-scale failures and minimize downtime.

Neat Diagram

        +-------------------------+
        |   Requirement Gathering |
        +-------------------------+
                    |
                    v
        +-------------------------+
        |      Quick Design       |
        +-------------------------+
                    |
                    v
        +-------------------------+
        |     Build Prototype     |
        +-------------------------+
                    |
                    v
        +-------------------------+
        |     User Evaluation     |
        +-------------------------+
                    |
          +---------+---------+
          |                   |
    Not Satisfied          Satisfied
          |                   |
          v                   v
  +----------------+   +------------------+
  | Refine         |   |  Engineer Final  |
  | Prototype      |   |  Product         |
  +----------------+   +------------------+
          |                   |
          |                   v
          +---------->  +------------+
                         | Maintain   |
                         | System     |
                         +------------+

The loop between Quick Design, Build Prototype, User Evaluation, and Refine Prototype continues until the user is satisfied.

Advantages of the Prototyping Model

Disadvantages of the Prototyping Model

Conclusion

The Prototyping Model is best suited for projects where requirements are unclear or frequently changing. It ensures higher user satisfaction through early visualization and active involvement. However, it must be carefully managed to avoid scope creep, poor documentation, and degraded system architecture.

Black Box Testing vs White Box Testing and the Testing Process

1. Differentiation: Black Box vs White Box Testing

2. The Testing Process

Software testing is the process of verifying and validating that a software or application is bug-free and meets technical requirements. It also measures efficiency, accuracy, and usability of the software.

The testing process follows a structured sequence of stages as described below:

Step 1: Inspections

• A testing technique in which participants examine program code for predictable, language-specific errors.
• Syntax, grammar, and other routine errors can be checked by automated inspection software.
• This is typically the first step before actual execution begins.

Step 2: Desk Checking

• A testing technique in which the programmer manually traces through the logic of the program using paper and pencil.
• The reviewer acts as the computer, mentally checking each step and its results for the entire set of computer instructions.
• This helps catch logical errors early without running the program.

Step 3: Unit Testing

• An automated technique where each module is tested alone in an attempt to discover any errors that may exist in the module's code.
• The goal is to isolate each part of the program and verify that individual parts work correctly.

Step 4: Stub Testing

• A technique used in testing modules, especially where modules are written and tested in a top-down fashion.
• A "stub" is a dummy module that simulates the behavior of modules not yet written, allowing higher-level modules to be tested first.

Step 5: Integration Testing

• The process of bringing together more than one module that a program comprises for testing purposes.
• After individual modules pass unit testing, they are combined and tested together to check for interface errors and interaction problems between modules.

Step 6: System Testing

• The process of bringing together all of the programs that a system comprises for testing purposes.
• The system is tested as a whole to verify that it meets all specified requirements.
• System testing can be carried out using:
  • Black Box Testing -- testing based on inputs and expected outputs without knowledge of internal code.
  • White Box Testing -- testing based on knowledge of the internal structure and logic of the system.

Summary Diagram of Testing Process

Inspections
     |
Desk Checking
     |
Unit Testing
     |
Stub Testing
     |
Integration Testing
     |
System Testing
(Black Box / White Box)

Conclusion

The testing process moves from individual code review (inspections, desk checking) to module-level testing (unit and stub testing) and finally to system-level testing (integration and system testing). Black box testing focuses on what the system does, while white box testing focuses on how the system does it. Together, they ensure that the software is both functionally correct and internally sound.

Advantages of Normalization and Explanation of 2NF

Advantages of Normalization

Normalization is the process of organizing data in a database to reduce redundancy and improve data integrity. Its key advantages are:

1. Eliminates Data Redundancy: Removes duplicate data stored across multiple tables, saving storage space.
2. Prevents Update Anomalies: Ensures that updating a single fact requires changing it in only one place.
3. Prevents Insertion Anomalies: Allows new data to be inserted without requiring unrelated data to be present.
4. Prevents Deletion Anomalies: Ensures that deleting a record does not unintentionally remove other important data.
5. Improves Data Integrity and Consistency: Data remains accurate and consistent throughout the database.
6. Easier Maintenance: A well-normalized database is easier to modify and extend.

Second Normal Form (2NF)

Definition

A relation is in Second Normal Form (2NF) if:

• It is already in First Normal Form (1NF), AND
• Every non-key attribute is fully functionally dependent on the entire primary key (i.e., there is no partial dependency on any part of a composite primary key).

Partial Dependency: A non-key attribute depends on only a part of the composite primary key, not the whole key.

Example

Consider the following relation with a composite primary key (StudentID, CourseID):

Primary Key: (StudentID, CourseID)

Identifying Partial Dependencies:

• StudentName depends only on StudentID (not on the full key) -- Partial Dependency
• CourseName depends only on CourseID (not on the full key) -- Partial Dependency
• Marks depends on both StudentID and CourseID -- Full Dependency (OK)

Since partial dependencies exist, this relation is NOT in 2NF.

Converting to 2NF

We decompose the table to remove partial dependencies:

Table 1: Student (depends on StudentID)

Table 2: Course (depends on CourseID)

Table 3: Enrollment (depends on full composite key)

Now all non-key attributes are fully functionally dependent on the entire primary key in each table. The database is now in 2NF.

Note: 2NF is only relevant when the primary key is composite. If a relation has a single-attribute primary key and is in 1NF, it is automatically in 2NF.

Discounted Payback Period Using Net Present Value

STEP 1 - Given Data

STEP 2 - Solution

Present Value Formula

$$PV_n = \frac{Y}{(1+i)^n}$$

Step 1: Discounted Cash Inflows Per Year

Step 2: Cumulative Discounted Cash Flow (NPV progression)

Step 3: Locate the Break-even

• End of Year 3: cumulative = $-525$ (still negative)
• End of Year 4: cumulative = $+26{,}795$ (positive)

So the payback occurs during Year 4.

Step 4: Exact Discounted Payback Period

$$\text{Fraction} = \frac{\text{Unrecovered amount at start of year}}{\text{Discounted inflow of that year}} = \frac{525}{27{,}320} = 0.0192$$

$$\boxed{\text{Discounted Payback Period} = 3 + 0.019 \approx 3.02 \text{ years}}$$

Conclusion

Considering the time value of money at a 10% discount rate, the Rs. 1,00,000 investment is recovered in approximately 3.02 years (just over 3 years). The tiny rounding differences (Rs. 525 vs Rs. 528) do not change the result.