Software Engineering

Part-2
Software Process
Presented by
Asmaul Hosna Sadika
Assistant Lecturer

Dept of CSE, IIUC

Contents
❑ What is Software process?
❑ Software process model
❑ Linear sequential Process model
❑ Water fall
❑ Prototyping
❑ Incremental
❑ Spiral
❑ Other appropriate models (Agile)
❑ Agile Project management
What is software process?

❑ A software process is a set of related activities that leads to the

production of a software product
❑ There are many different software processes but all must include
four activities that are fundamental to software engineering:
1. Software specification
2. Software design and implementation
3. Software validation
4. Software evolution
More about software process

Software processes are complex and, like all intellectual and creative
processes, rely on people making decisions and judgments.
There is no ideal process and most organizations have developed their
own software development processes.
Processes have evolved to take advantage of the capabilities of the
people in an organization and the specific characteristics of the systems
that are being developed.
For some systems,
Critical systems a very structured development process
Business systems(rapidly changing requirements) less formal, flexible process
 More about software process

❑ Software processes are categorized as

1. Plan-driven processes - are processes where all of the process activities
are planned in advance and progress is measured against this plan.
2. Agile processes - planning is incremental and it is easier to change the
process to reflect changing customer requirements.
❑ As Boehm and Turner (2003) discuss, each approach is suitable for different
types of software. Generally, you need to find a balance between
plan-driven and agile processes
❑ Although there is no ‘ideal’ software process, there is scope for improving
the software process in many organizations.
❑ Software processes can be improved by process standardization where the
diversity in software processes across an organization is reduced.
Standardization is also an important first step in introducing new software
engineering methods and techniques and good software engineering
practice.
Software process models

▪ A software process model is a simplified representation of a software

process.
▪ Each process model represents a process from a particular perspective,
and thus provides only partial information about that process.
▪ For example, a process activity model shows the activities and their
sequence but may not show the roles of the people involved in these
activities.
▪ The generic models are not definitive descriptions of software processes.
Rather, they are abstractions of the process that can be used to explain
different approaches to software development. You can think of them as
process frameworks that may be extended and adapted to create more
specific software engineering processes.
 Software process models

Some examples of the types of software process model that may be

produced are:
1. A workflow model This shows the sequence of activities in the process
along with their inputs, outputs, and dependencies. The activities in
this model represent human actions.
2. A dataflow or activity model This represents the process as a set of
activities, each of which carries out some data transformation. It shows
how the input to the process, such as a specification, is transformed
into an output, such as a design. The activities here may represent
transformations carried out by people or by computers.
3. A role/action model This represents the roles of the people involved in
the software process and the activities for which they are responsible.
 Software process models
Most software process models are based on one of three general models or paradigms of software
development:
The waterfall approach
o This takes the above activities and represents them as separate process phases such as requirements
specification, software design, implementation, testing, and so on.
o After each stage is defined it is ‘signed-off’, and development goes on to the following stage.
Iterative development
o This approach interleaves the activities of specification, development, and validation. An initial system is
rapidly developed from very abstract specifications.
o This is then refined with customer input to produce a system that satisfies the customer’s needs. The
system may then be delivered.
o Alternatively, it may be reimplemented using a more structured approach to produce a more robust and
maintainable system.
Component-based software engineering (CBSE)
o This technique assumes that parts of the system already exist. The system development process focuses on
integrating these parts rather than developing them from scratch
Waterfall Model

• This model was proposed by Royce in 1970

• It is also called linear sequential life cycle model

• Steps or Phases are arranged in linear order

• A step take input from previous step, gives output to the next step (if
any)

• Exit criteria of a step must match with entry criteria of succeeding step

• Phases are not overlapped

• Different people work in different phase

 Waterfall Model

Requirement Analysis

Design

Implementation

Testing

Deployment

Maintenance
 Waterfall Model
Requirement Analysis: Basically understanding the context of application.
Meetings with managers, stake holders and users are held in order to
determine the requirements like
• Who is going to use the system?
• How will they use the system?
• What data should be input into the system?
• What data should be output by the system?
❖ Requirement Specification(SRS) document is created
Design: Software design is prepared from the requirement specifications,
helps in defining overall system architecture.
🡪Translate the requirements into Software Architecture
🡪 Database design
The system design specification document is created
Waterfall Model

Implementation / Coding: On receiving system design documents, the

work is divided in modules/units and actual coding is started.
Testing: After the code is developed it is tested against the requirements to
make sure that the product is actually solving the needs addressed and
gathered during the requirements phase.
🡪Each unit is developed and tested for its functionality
🡪All units developed in Implementation Phase are integrated into a system
🡪Entire System is tested for any faults and failures
Deployment: After successful testing, the product is delivered/deployed to
the customer for their use.
🡪The product is deployed in the customer environment or released in
market
 Waterfall Model

Maintenance: Once when the customers starts using the developed system then the
actual problems comes up and needs to be solved from time to time. This process where
care is taken for the developed product is known as maintenance.
🡪Some issues or changes arise in customer or client environment are maintained
When is this model applicable?

o Product definition is stable.

o Requirements are very well documented, clear, and fixed.
o There are no ambiguous requirements.
o Technology is understood and is not dynamic.
o Ample resources with the required expertise are available to support the product.
o The project is short.
When is this model not applicable?
Waterfall Model
Advantages of waterfall model:
• 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 of waterfall model-

• No working software is produced until late during the life cycle

• Poor model for long and ongoing projects.

• Not a good model for complex and object-oriented projects.

• It is difficult to measure progress within stages.

• Cannot accommodate changing requirements.

Incremental Model
Incremental Model

• The whole requirement is divided into various builds

• During each iteration, the development cycle goes through
• Analysis
• Design
• Implementation
• Testing Phases
• Each subsequent release of the module adds function to the previous release
• The process continues till the complete system is ready as per the
requirement
• The basic idea behind this method is to develop a system
• through repeated cycles (iterative) and
• in smaller portions at a time (incremental)
Incremental Model

When is this model applicable?

• Requirements of the complete system are clearly defined and understood
• Major requirements must be defined and some functionalities or
requested enhancements may evolve with time
• A new technology is being used and is being learnt by the development
team while working on the project
• Resources with needed skill set are not available and are planned to be
used on contract basis for specific
• There are some high risk features and goals which may change in the
future
When is this model not applicable?
Incremental Model

Advantages of Incremental model

• Some working functionality can be developed quickly and early in the
life cycle

• Results are obtained early and periodically

• Progress can be measured

• It is easier to find functional or design flaws

• Finding issues at an early stage of development enables to take

corrective measures in a limited budget
 Incremental Model

Disadvantages of the incremental model

• It is applicable only to large and bulky software development projects
• More resources may be required
• More management attention is required
From a management perspective, the incremental approach has two
problems-
1. The process is not visible. Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
2. System structure tends to degrade as new increments are added. Unless time
and money is spent on refactoring to improve the software, regular change
tends to corrupt its structure. Incorporating further software changes
becomes increasingly difficult and costly.
Prototype Model

• Prototype refers to building software application prototypes which

• displays the functionality of the product under development
• but may not actually hold the exact logic of the original software

• Software prototyping is becoming very popular as a software development model

• as it enables to understand customer requirements at an early stage of
development

• It helps
• get valuable feedback from the customer
• software designers and developers understand about what exactly is expected
from the product under development
Prototype Model

the very basic requirements are showcased

and user interfaces are provided

Prototyping

Requirement Design Customer

Analysis Evaluation
Customer
satisfied
Review &
Updating
Feedback is collected

Maintenance Testing Development

Prototype Model

When this model is applicable?

o Software Prototyping is most useful in development of systems
having high level of user interactions such as online systems
o Systems which need users to fill out forms or go through various
screens before data is processed
When is this model not appropriate?
o Software that involves too much of data processing and most of the
functionality is internal with very little user interface does not
usually benefit from prototyping
Prototype Model

Advantages of prototype model-

▪ Increased user involvement in the product even before its
implementation.

▪ Since a working model of the system is displayed, the users get a

better understanding of the system being developed.

▪ Reduces time and cost as the defects can be detected much earlier.

▪ Quicker user feedback is available leading to better solutions.

▪ Missing functionality can be identified easily.

▪ Confusing or difficult functions can be identified

Prototype Model

Disadvantages of prototype model-

▪ Risk of insufficient requirement analysis owing to too much
dependency on the prototype.

▪ Users may get confused in the prototypes and actual systems.

▪ Developers may try to reuse the existing prototypes to build the

actual system, even when it is not technically feasible

▪ The effort invested in building prototypes may be too much if it is

not monitored properly.
Spiral Model
❑ A risk-driven software process framework (the spiral model) was proposed by
Boehm (1988). This is shown in Figure 2.1.
❑ Here, the software process is represented as a spiral, rather than a sequence of
activities with some backtracking from one activity to another.
❑ Each loop in the spiral represents a phase of the software process.
❑ Thus, the innermost loop might be concerned with system feasibility, the next
loop with requirements definition, the next loop with system design, and so on.
❑ The spiral model combines change avoidance with change tolerance.
❑ It assumes that changes are a result of project risks and includes explicit risk
management activities to reduce these risks.
❑ Spiral Model is the combination of
▪ Iterative Model
▪ Waterfall model
Spiral Model

Figure 2.1 : Boehm’s spiral model of the software process (©IEEE 1988)
Spiral Model

Each loop in the spiral is split into four sectors:

1. Objective setting: Specific objectives for that phase of the project are defined. Project risks
are identified. Alternative strategies, depending on these risks, may be planned.
2. Risk assessment and reduction: For each of the identified project risks, a detailed analysis
is carried out. Steps are taken to reduce the risk. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.
3. Development and validation: After risk evaluation, a development model for the system is
chosen. For example, Best development approach

UI risks are dominant prototyping

Safety risks are the dominant based on formal transformations
Sub-system integration is dominant risk waterfall model

4. Planning: The project is reviewed and a decision made whether to continue with a further
loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the
project.
Spiral Model

When is the model applicable?

• 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
priorities as the requirements change with time
• customer is not sure of their requirements
• Requirements are complex and need evaluation to get clarity
• New product line which should be released in phases to get
enough customer feedback
When is the model not applicable?
Agile Model

❑ Agile methods are iterative development approaches where small

increments are regularly released (every two or three weeks) to
customers, involving them for swift feedback on changing requirements
and relying on informal communication rather than formal
documentation
❑ Agile methods prioritize software development over extensive design
and documentation, relying on incremental approaches suited for
evolving requirements. They excel in application development, rapidly
delivering working software for customer feedback and embracing
changes for later iterations
❑ Agile means “the ability to respond to changes-Requirements,
Technology, People ”
❑ Agile Method is an Adaptive approach
 Agile method

Planning

Requirement
Testing Analysis

Iteration 1 Planning
Building Designing

Requirement
Testing Analysis
2-4 weeks Iteration 2
Building Designing
Planning

Requirement
Testing Analysis
2-4 weeks Iteration 3
Building Designing
Adaptive approach

What is adaptive approach?

It usually works without any detailed planning
There is clarity on future tasks only in respect of what features need to be
developed
This is feature driven development
The team adapts to the changing product requirements dynamically
The product is tested very frequently, through release iterations,
minimizing the risk of any major failures in future
Example of Adaptive Approach is Agile Mode
 Agile methods

The most popular agile methods include

1. Rational Unified Process (1994)
2. Scrum (1995)
3. Crystal Clear
4. Extreme Programming (1996)
5. Adaptive Software Development
6. Feature Driven Development and
7. Dynamic Systems Development Method (DSDM) (1995)
8. These are now collectively called Agile Methodologies
Agile Manifesto : Principles
Advantage of agile

Is a very realistic approach to software development

In agile development, self-organization and motivation are important
Promotes teamwork and cross training.
Functionality can be developed rapidly and demonstrated.
Delivers early partial working solutions.
Enables concurrent development and delivery within an overall planned
context
Little or no planning required
Easy to manage
Gives flexibility to developers
 Disadvantage of agile
1. It depends on customer interaction, so if customer is not clear, team
can be driven in wrong direction
2. There is very high individual dependency, since there is minimum
documentation generated
3. Transfer of technology to new team members may be quite challenging
due to lack of documentation
Agile Manifesto : Principles

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

 Agile Project management

❑ The principal responsibility of software project managers is to manage

the project so that the software is delivered on time and within the
planned budget for the project.
❑ The Scrum approach (Schwaber, 2004; Schwaber and Beedle, 2001) is a
general agile method but its focus is on managing iterative development
rather than specific technical approaches to agile software engineering.
❑ There are three phases in Scrum.
V model

V-Model also referred to as the Verification and Validation Model. In this,

each phase of SDLC must complete before the next phase starts. It follows
a sequential design process same as the waterfall model. Testing of the
device is planned in parallel with a corresponding stage of development.
 V model

Verification: It involves a static analysis method (review)

done without executing code. It is the process of
evaluation of the product development process to find
whether specified requirements meet.

Validation: It involves dynamic analysis method

(functional, non-functional), testing is done by executing
code. Validation is the process to classify the software
after the completion of the development process to
determine whether the software meets the customer
expectations and requirements.

So V-Model contains Verification phases on one side of

the Validation phases on the other side. Verification and
Validation process is joined by coding phase in V-shape.
Thus it is known as V-Model.
 V model
There are various phases of the Verification Phase of the V-model:
Business requirement analysis: This is the first step where product requirements
understood from the customer's side. This phase contains detailed communication to
understand customer's expectations and exact requirements.
System Design: In this stage system engineers analyze and interpret the business of the
proposed system by studying the user requirements document.
Architecture Design: The baseline in selecting the architecture is that it should understand
all which typically consists of the list of modules, brief functionality of each module, their
interface relationships, dependencies, database tables, architecture diagrams, technology
details, etc.
Module Design: In the module design phase, the system breaks down into small modules.
The detailed design of the modules is specified, which is known as Low-Level Design
Coding Phase: After designing, the coding phase is started. Based on the requirements, a
suitable programming language is decided. There are some guidelines and standards for
coding. Before checking in the repository, the final build is optimized for better performance,
and the code goes through many code reviews to check the performance.
 V model

There are the various phases of Validation Phase of V-model:

Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design
phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is the
smallest entity which can independently exist, e.g., a program module. Unit testing verifies
that the smallest entity can function correctly when isolated from the rest of the codes/ units.
Integration Testing: Integration Test Plans are developed during the Architectural Design
Phase. These tests verify that groups created and tested independently can coexist and
communicate among themselves.
System Testing: System test plans are developed during the System Design Phase. Unlike
Unit and Integration Test Plans, System Tests Plans are composed by the client’s business
team. System Test ensures that expectations from an application developer are met.
Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It
includes testing the software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.
V model
When to use V-Model?
• When the requirement is well defined and not ambiguous.
• The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
• The V-shaped model should be chosen when sample technical resources are
available with essential technical expertise.
Advantages of V-Model:
• Easy to Understand.
• Testing Methods like planning, test designing happens well before coding.
• This saves a lot of time. Hence a higher chance of success over the waterfall
model.
• Avoids the downward flow of the defects.
• Works well for small plans where requirements are easily understood.
V model

Disadvantages of V-Model:
• Very rigid and least flexible.
• Not a good for a complex project.
• Software is developed during the implementation stage, so no early
prototypes of the software are produced.
• If any changes happen in the midway, then the test documents along with
the required documents, has to be updated.
 Scrum

1. The first is an outline planning phase where you establish the general
objectives for the project and design the software architecture.
2. This is followed by a series of sprint cycles, where each cycle develops an
increment of the system.
3. Finally, the project closure phase wraps up the project, completes required
documentation
❑ A Scrum sprint is a planning unit in which
- the work to be done is assessed
- features are selected for development, and
- the software is implemented.
At the end of a sprint, the completed functionality is delivered to stakeholders
Scrum Process
Scrum

Key elements of Scrum include:

• Roles:
• Product Owner (defines the product vision and prioritizes work),
• Scrum Master (ensures the team follows Scrum principles and
removes obstacles),
• Development Team (delivers the work incrementally).
• Sprints: Short, time-boxed iterations (usually 1-4 weeks) during which a
set of tasks is completed.
• Artifacts:
• Product Backlog (list of features or tasks),
• Sprint Backlog (tasks selected for a sprint),
• Increment (completed product or feature).
Scrum
Scrum meetings:
• Sprint Planning:
• Occurs at the beginning of each sprint.
• The team discusses and selects items from the Product Backlog to work on during the sprint.
• The meeting sets the sprint goal and defines the tasks necessary to meet it.
• Daily Scrum (Daily Stand-up):
• A short, 15-minute daily meeting where the development team members share:
• What they worked on yesterday.
• What they plan to work on today.
• Any blockers or obstacles they face.
• Helps keep the team synchronized and identify issues early.
• Sprint Review:
• Held at the end of the sprint.
• The team demonstrates the work completed during the sprint to the Product Owner and stakeholders.
• Feedback is gathered to help refine future work and adjust priorities.
• Sprint Retrospective:
• Follows the sprint review.
• The team reflects on the sprint, discussing what went well, what didn't, and what can be improved.
• The goal is to continuously improve processes, communication, and teamwork.
 RAD model

❑ The RAD (Rapid Application Development) model

is based on prototyping and iterative development
with no specific planning involved.
❑ Rapid Application Development focuses on gathering
customer requirements through workshops or focus
groups, early testing of the prototypes by the
customer using iterative concept, reuse of the
existing prototypes (components), continuous
integration and rapid delivery.
❑ Rapid application development is a software
development methodology that uses minimal
planning in favor of rapid prototyping. A prototype is
a working model that is functionally equivalent to a
component of the product.
RAD model distributes the analysis, design, build and test phases into a series of short,
iterative development cycles.
Following are the various phases of the RAD Model −
Business Modelling
The business model for the product under development is designed in terms of flow of
information and the distribution of information between various business channels. A
complete business analysis is performed to find the vital information for business, how it can
be obtained, how and when is the information processed and what are the factors driving
successful flow of information.
Data Modelling
The information gathered in the Business Modelling phase is reviewed and analyzed to form
sets of data objects vital for the business. The attributes of all data sets is identified and
defined. The relation between these data objects are established and defined in detail in
relevance to the business model.
Process Modelling
The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model.
The process model for any changes or enhancements to the data object sets
is defined in this phase. Process descriptions for adding, deleting, retrieving
or modifying a data object are given.
Application Generation
The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.
Testing and Turnover
The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration. However, the data flow and the
interfaces between all the components need to be thoroughly tested with
complete test coverage.
 Any
Question?