KEMBAR78
SWE Lecture 2 | PDF | Software Development Process | Prototype
0% found this document useful (0 votes)
3 views8 pages

SWE Lecture 2

The document outlines the software process, which consists of four fundamental activities: specification, development, validation, and evolution. It discusses various software process models, including the Waterfall and Agile models, highlighting their advantages and disadvantages, as well as the concept of reuse-oriented software engineering. Additionally, it addresses coping with change through prototyping and incremental delivery, detailing their processes and benefits.

Uploaded by

Youstina Mitcho
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
0% found this document useful (0 votes)
3 views8 pages

SWE Lecture 2

The document outlines the software process, which consists of four fundamental activities: specification, development, validation, and evolution. It discusses various software process models, including the Waterfall and Agile models, highlighting their advantages and disadvantages, as well as the concept of reuse-oriented software engineering. Additionally, it addresses coping with change through prototyping and incremental delivery, detailing their processes and benefits.

Uploaded by

Youstina Mitcho
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/ 8

SWE Lecture 2

Software Process
It's a sequence of activities that leads to the production of a software product.

It's Four Fundamental Activities :


1. Software specification, they are the inputs, outputs, etc...
2. Software development, software is designed and programmed.
3. Software validation, testing and checking to ensure it satisfies the customer.
4. Software evolution, modifying the software to fulfill customer and market requirements.

Process Descriptions
They include:

Sub-activities such as requirements validation, unit testing, etc.


Supporting process activities such as documentation and software configuration
management.
The ordering of these activities.
Products, which are the outcomes of a process activity.
Pre- and post-conditions, which are statements that are true before and after a
finishing the product.

Software Processes Categories

Plan-driven Agile
processes where all of the process planning is incremental and it is easier to
activities are planned in advance. change the process midway.

Waterfall Model
This model is known as the ‘waterfall model’ or software development life cycle (SDLC).
T
It's a plan-driven process meaning that you must plan and schedule all of the process
activities before starting to work on them.

Advantages

Simple and easy to understand and implement.


Easy to manage.
Phases are clearly defined and completed one at a time.

Disadvantages

Costs of producing and approving documents.


No working software is produced until late stages.
There is no chance to change customer requirements.
High amount of risk.

When to use

The requirements are understood from the beginning.


The requirements are unlikely to change.
The delivery time is not a problem.

Agile Model
The system is developed as a series of versions (increments), with each version adding
functionality to the previous version.

Initial implementation for the system, then showing it to the user and
evolving it in increments.

Incremental development is now the most common approach for the development
of application systems.

Advantages

Less cost.
The customer can evaluate the system at a relatively early stage which helps in
validating the system.
More rapid delivery and deployment of useful software.

Disadvantages

The process is not visible.


System structure tends to become complex.
They are not fit for large systems because there are different teams for different parts
and it needs a stable framework and architecture.

Reuse-Oriented Software Engineering


This approach is based on the existence of a significant number of reusable
components.

It focuses on integrating these components into a system rather than


developing them from scratch.
They are called COTS or commercial off-the-shelf systems.

Types of Software Components

1. Web services.
2. Collections of objects that are developed as a package to be integrated with a
component framework such as .NET or J2EE.
3. Stand-alone software systems that are configured for use in a particular environment
(COTS).

Advantages

Reduces the amount of software to be developed and so reducing cost and risks.
leads to faster delivery of the software

Disadvantages

Compromising on requirements is unavoidable, and this can result in a system that


doesn't fully meet users' needs.
The organization loses control over system updates because new versions of reusable
components aren't managed by them. (They don't own the components)

Coping with Change


Software projects frequently experience changes due to evolving business requirements,
new technologies, and platform shifts.

Rework Reduction Approaches

1. Change Avoidance:
Involves anticipating changes before they require significant rework.
A prototype can help users visualize features and refine requirements early, preventing
costly modifications later.

2. Change Tolerance:

The development process is structured to allow low-cost changes.


This approach is common in incremental development, where modifications are made to
parts of the system without affecting the other parts.

Two Ways of “coping with change”

1. Prototyping

A prototype is an initial version of the system that is quickly developed.

Properties

A preliminary version of the system is quickly developed.


Helps check customer requirements and design feasibility.
Supports change avoidance
Reduces the number of changes after the system is completed.

In requirements engineering, a prototype helps elicit and confirm system


needs.

In system design process, a prototype helps test software ideas and improve
the user interface.

Prototype Process

1. Planning Prototype
2. Outlining Prototype Functionalities
3. Developing Prototype
4. Evaluating Prototype

Prototype Model

1. Gather Initial Requirements – Identify basic system needs from users.


2. Design Prototype – Create a basic version of the system.
3. Develop Prototype – Build a working model with key features.
4. User Evaluation – Users test the prototype and give feedback.
5. Review & Update – Make improvements based on feedback.
6. Testing – Ensure the prototype works correctly.
7. Maintain & Finalize – If users are satisfied, proceed with full development. If not, repeat
the cycle.

Prototypes focus on functional rather than non-functional requirements

Prototype should focus on areas of the product that are not well-understood.

Prototypes should be discarded after development as they are not a good


basis for a production system

2. Incremental Delivery

Instead of delivering the entire system at once, it is developed and released in smaller
increments.
Priority requirements are addressed first, ensuring critical features are available early.
Each new increment is integrated with previous ones, gradually improving system
functionality.

Incremental Development vs Delivery

Incremental development Incremental delivery


Key focuses on creating and refining releases increments for actual
Difference increments internally. use and evaluation.
Deployment Each increment is reviewed but not Each increment is deployed and
deployed for real use. used by end-users.

Incremental Development Steps

1. Define Requirements – Identify the system’s main needs.


2. Assign Requirements to Increments – Divide requirements into smaller parts.
3. Design System Architecture – Plan how the system will be structured.
4. Develop Increment – Build a part of the system.
5. Check if System is Complete:
If not complete, continue developing more increments.
6. Validate Increment – Test if the new increment works correctly.
7. Integrate Increment – Combine it with previous increments.
8. Validate System – Ensure the entire system works well.
9. Deploy Increment – Release the completed part for use.
10. Check if Final System is Complete:
If yes, the process ends with the Final System.
If not, repeat steps for the next increment.

Advantages

1. Real System Prototypes – Customers test real parts early, reducing re-learning.
2. Quick Access – Essential features are available sooner.
3. Better Testing – Critical parts get more testing, reducing failures.

Disadvantages

1. Difficult to Plan Common Features – Early shared system needs are unclear.
2. Doesn’t Suit Traditional Contracts – Many prefer a full plan before development.
3. No Full Design at the Start – The system evolves over time.

When Incremental Delivery May Not Work

1. Large Systems – Difficult when teams work in different locations.


2. Critical Systems – Needs full requirement analysis for safety and security.

You might also like