Scribd
Upload
13 views4 pages

3 - Process Models (Incremental Model)

The document discusses various software process models, focusing on the evolution from informal methods like Build and Fix to structured models such as Waterfall and Incremental. It highlights the advantages and disadvantages of each model, emphasizing the need for structured approaches to address issues in software development. The Incremental Model is presented as a flexible alternative that allows for early delivery and adaptability to changes, making it suitable for projects with evolving requirements.

Uploaded by

huzaifaltaf605
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
13 views4 pages

3 - Process Models (Incremental Model)

The document discusses various software process models, focusing on the evolution from informal methods like Build and Fix to structured models such as Waterfall and Incremental. It highlights the advantages and disadvantages of each model, emphasizing the need for structured approaches to address issues in software development. The Incremental Model is presented as a flexible alternative that allows for early delivery and adaptability to changes, making it suitable for projects with evolving requirements.

Uploaded by

huzaifaltaf605
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

3_Process Models (Incremental Model):

Software Process Models

Context:

This lecture introduces software process models, explaining how software is developed through structured steps. It
focuses on the evolution from informal models like Build and Fix to formal models like Waterfall and Incremental.

1. Build and Fix Model

Context:

This is the earliest and most basic model used in software development, mainly before formal methodologies were
adopted.

Key Points:

• No formal planning or specification is done.


• Developers keep building and revising the software until the client is satisfied.
• Works only for very small projects, like personal tools or one-time scripts.

Problems:

• Cannot be used for larger or long-term projects.


• Maintenance becomes a huge challenge.
• Difficult to predict project outcomes or manage resources.
• Often results in poor software quality due to lack of structure.

2. Why Do We Need Software Models?

Context:

This section addresses the software crisis, highlighting why structured models became necessary.

Key Points:

• Symptoms of the crisis:


o Projects exceed time and budget.
o Users are unhappy with the results.
o Software is often buggy or unreliable.
• Structured models help overcome these issues by improving planning and control.
3. Process as a “Black Box”

Context:

This metaphor explains problems that occur when we don’t clearly understand or observe the internal process of
software development.

Key Points:

• Requirements are taken at the beginning, and then the process is hidden until delivery.
• This assumes all requirements are known from the start — which is rarely true.
• Customer interaction is minimal, causing misunderstandings and unmet expectations.

4. Process as a “White Box”

Context:

This approach improves on the black box by making the development process transparent and interactive.

Key Points:

• Allows customer feedback during development.


• Helps catch issues early.
• Reduces risk and improves final software quality.
• Encourages communication between developers and clients throughout the project.

5. Prescriptive Models

Context:

These models are rule-based and emphasize an organized structure for completing a software project.

Key Points:

• Follow a fixed order of steps or activities (called a process framework).


• Includes key stages like:
o Communication (understanding requirements)
o Planning (estimating cost, time)
o Modeling (designing system structure)
o Construction (coding and testing)
o Deployment (releasing to users)
• Adaptable based on:
o Project size and type
o Team experience
o Work environment
6. Waterfall Model (Linear Sequential Model)

Context:

One of the earliest structured models. It introduced clear phases and documentation in software engineering.

Key Features:

• Follows a linear flow — each phase must be completed before moving to the next.
• Phases:
o Requirement Gathering
o System Design
o Implementation
o Testing
o Deployment
o Maintenance

Advantages:

• Simple and easy to manage.


• Good documentation helps in project tracking.
• Works well for projects with fixed and clear requirements.

Disadvantages:

• Inflexible to changes after development starts.


• No early working version of software.
• Not suitable for projects where requirements evolve.

When to Use:

• Requirements are well-known and stable.


• Technology is well-understood.
• Adequate skilled resources are available.
• There’s no ambiguity in the client’s needs.

7. Incremental Model

Context:

Introduced as an improvement over the Waterfall model, especially when faster delivery and flexibility are needed.

Key Concept:

• The software is developed and delivered in small parts (increments).


• Each increment adds a piece of functionality.
• Follows same steps as the prescriptive model:
o Communication → Planning → Modeling → Construction → Deployment

Advantages:
• Working software is available early in the development.
• Can accommodate changes more easily than Waterfall.
• Useful when:
o Skilled developers are limited
o Risk must be managed incrementally
• Easier testing and debugging
• More flexibility in development and customer interaction

Disadvantages:

• Needs clear planning and design from the start.


• Full system definition is required, even if delivered in parts.
• Total cost may become higher than Waterfall due to repeated steps.

When to Use:

• Some high-risk features or goals are expected to change.


• Not all team members are available from the beginning.
• A new or unfamiliar technology is involved.
• Quick market delivery is needed.
• Core requirements are known, but detailed design can evolve.

Yes, you're right — the PDF contains several diagrams, especially ones that visually show steps or comparisons between
different models.

Here are the exact page numbers from the PDF where diagrams appear:

1. Page 5 – A diagram showing the "Process as a Black Box" (illustrates informal requirements and hidden
processes).
2. Page 7 – A diagram showing the "Process as a White Box" (adds feedback loops and makes processes visible).
3. Page 12 – A Waterfall Model phase diagram, showing each phase in a linear sequence.
4. Page 18 – An Incremental Model process diagram, showing how increments are built and delivered step by
step.

Let me know if you'd like me to recreate or simplify any of these diagrams into easier visuals for notes or presentations!

You might also like