Software Engineering Lecture 2 - Updated

Download as pdf or txt
Download as pdf or txt
You are on page 1of 54

CSE291 - Introduction To Software

Engineering
(Spring 2020)

Lecture 2
Software Process and
Process Models
2/17/2020 CSE291 - Introduction to Software Engineering 2

Introduction to Software Development


Construction
Some of the major construction activities are listed below.
• Requirement Gathering
• Design Development
• Coding
• Testing
Management
Some of the major management activities are listed below.
• Project Planning and Management
• Configuration Management
• Software Quality Assurance
• Installation and Training
2/17/2020 CSE291 - Introduction to Software Engineering 3

Figure 1: Development Activities


2/17/2020 CSE291 - Introduction to Software Engineering 4

The Software Process

A structured set of activities required to develop a


software system.
• Many different software processes but all involve:
• Specification – defining what the system should do
• Design and implementation – defining the organization of the
system and implementing the system
• Validation – checking that it does what the customer wants
• Evolution – changing the system in response to changing customer
needs.
A software process model is an abstract representation of
a process. It presents a description of a process from some
particular perspective.
2/17/2020 CSE291 - Introduction to Software Engineering 5

Software Process Descriptions

• When we describe and discuss processes, we usually talk


about the activities in these processes such as
specifying a data model, designing a user interface, etc.
and the ordering of these activities.
• Process descriptions may also include:
• Products, which are the outcomes of a process activity;
• Roles, which reflect the responsibilities of the people involved in
the process;
• Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a
product produced.
2/17/2020 CSE291 - Introduction to Software Engineering 6

Ad hoc Software Development

• Developing software without planning for each phase, and


without specifying tasks, deliverables, or time constraints.

• Relies entirely on the skills and experience of the


individuals performing the work.
2/17/2020 CSE291 - Introduction to Software Engineering 7

Case Study : SaudiTech


What could go wrong in a software development project?
SaudiTech is a software company. It has a team of 25 programmers.
Ali has recently established a dental clinic in Riyadh and asked
SaudiTech to develop a management system for his dental clinic.
Ali’s request was to develop a system to electronically manage
patient records and perform administrative functions similar to ‘what is
being used in other clinics’ but within a budget of 50 Saudi riyals and
delivered within 3 months.
SaudiTech adopts an ad hoc approach (Developing software
without planning for each phase, and without specifying tasks,
deliverables, or time constraints) to software development and has
not worked on large scale projects before. What problems do you
anticipate in this project? And how can we overcome problems?
2/17/2020 CSE291 - Introduction to Software Engineering 8

How can we overcome problems with ad


hoc software development?
 Problems:
to distinguish between tasks  important tasks may be
 Difficult
ignored.
 Inconsistent schedules, budgets, functionality and product quality.
 Delayed problem discovery  more costly to fix.

Solution? Software Process Model


“an abstract representation of a process. It presents a
description of a process from some particular perspective.”

 Software Process Models provide guidelines to organize how


software process activities should be performed and in what
order.
2/17/2020 CSE291 - Introduction to Software Engineering 9

Software Development Loop


Software development activities could be performed in a cycle
called software development loop which is shown in Figure
below
2/17/2020 CSE291 - Introduction to Software Engineering 10

Software Development Loop

• Problem Definition: In this stage, Determine what is the


problem against which we are going to develop software. Here
we try to completely comprehend the issues and requirements
of the software system to build.

• Technical Development: This is the stage where a new


system is actually developed that solves the problem defined in
the first stage.

• Solution Integration: All existing system(s) integrate with our


new system at this stage.
2/17/2020 CSE291 - Introduction to Software Engineering 11

Software Development Loop

• Status Quo: After going through the previous three stages


successfully, when we actually deployed the new system at the
user site then that situation is called status quo. But once we
get new requirements then we need to change the status quo.

• After getting new requirements we perform all the steps in the


software development loop again.

• The software developed through this process has the property


that this could be evolved and integrated easily with the
existing systems.
2/17/2020 CSE291 - Introduction to Software Engineering 12

Plan-driven and Agile Processes


• Plan-driven processes are processes where all of the
process activities are planned in advance and progress is
measured against this plan.
• Plan drives everything!

• In Agile Processes, planning is incremental and it is


easier to change the process to reflect changing
customer requirements.

• In practice, most practical processes include


elements of both plan-driven and agile.
2/17/2020 CSE291 - Introduction to Software Engineering 13

Software Process/SDLC Models


Following are the most important and popular SDLC models followed in
the industry:

 Waterfall model.
 V Model
 Evolutionary development.
 Component-Based development model (CBSE).
 Process iteration(incremental and spiral Models)

The other related methodologies are Agile and RAD Model – Rapid
Application Development
2/17/2020 CSE291 - Introduction to Software Engineering 14

Waterfall Model
• First published model

• Because of the cascade from


one phase to another, this
model is known as ‘Waterfall
Model’.

• It is also referred to as linear-


sequential life cycle model.

• Each phase must be completed


before the next phase can begin
and there is no overlapping in
the phases.
2/17/2020 CSE291 - Introduction to Software Engineering 15

Waterfall Model
The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible


requirements of the system to be developed are captured in
this phase and documented in a requirement specification
document.
• System’s services
• Constraints
• Goals

System Design: The requirement specifications from first


phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system
requirements and also helps in defining overall system
architecture.
2/17/2020 CSE291 - Introduction to Software Engineering 16

Waterfall Model
Implementation and unit testing: With inputs from system
design, the system is first developed in small programs
called units, which are integrated in the next phase. Each
unit is developed and tested for its functionality which is
referred to as Unit Testing.

Integration and Testing: All the units developed in the


implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is
tested for any faults and failures.
2/17/2020 CSE291 - Introduction to Software Engineering 17

Waterfall Model
Deployment of system: Once the functional and non
functional testing is done, the product is deployed in the
customer environment or released into the market.

Maintenance: There are some issues which come up in


the client environment. To fix those issues patches are
released.
Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes
in the customer environment.
2/17/2020 CSE291 - Introduction to Software Engineering 18

Waterfall Model
2/17/2020 CSE291 - Introduction to Software Engineering 19

Waterfall Model
Applicability:

• Requirements are very well understood, clear and fixed.

• Product definition is stable.

• Technology is understood.
2/17/2020 CSE291 - Introduction to Software Engineering 20

Waterfall Model
Advantages:
• Documentation - at each phase
• Phases are processed and completed one at a time.
• Easy to arrange tasks.

Problems:
• Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
2/17/2020 CSE291 - Introduction to Software Engineering 21

V Model
• A variation of the waterfall
model

• Development phases are


presented in a V-shaped
graph.

• It is also known as
Verification and Validation
model.

• For every single phase in


the development cycle there
is a directly associated
testing phase.
2/17/2020 CSE291 - Introduction to Software Engineering 22

Verification and Validation


Verification
• Does the product meet system specifications?
• Have you built the product right?

Validation
• Does the product meet user expectations?
• Have you built the right product?
2/17/2020 CSE291 - Introduction to Software Engineering 23

V Model
2/17/2020 CSE291 - Introduction to Software Engineering 24

V Model Verification Phases


Following are the Verification phases in V-Model
Requirement Analysis:
• This phase involves detailed communication with the customer
to understand his expectations and exact requirement.
• The acceptance test planning is done at this stage as user
requirements can be used as an input for acceptance testing.
System Design:
• System design would comprise of understanding and detailing
the complete hardware and communication setup for the
product under development.
• System test plan is developed based on the system design.
2/17/2020 CSE291 - Introduction to Software Engineering 25

V Model Verification Phases


Architectural Design:
• System design is broken down further into modules taking up
different functionality.
• The data transfer and communication between the internal
modules and with the outside world (other systems) is clearly
understood and defined in this stage.
• With this information, integration tests can be designed and
documented during this stage.
Module Design:
• In this phase the detailed internal design for all the system
modules is specified
• It is important that the design is compatible with the other
modules in the system architecture and the other external
systems.
• Unit tests can be designed at this stage
2/17/2020 CSE291 - Introduction to Software Engineering 26

V Model
Coding Phase
• The actual coding of the system modules designed in the
design phase is taken up in the Coding phase.
• The best suitable programming language is decided
based on the system and architectural requirements.
• The coding is performed based on the coding guidelines
and standards.
• The code goes through numerous code reviews and is
optimized for best performance before the final build is
checked into the repository.
2/17/2020 CSE291 - Introduction to Software Engineering 27

V Model Validation Phases


Following are the Validation phases in V-Model:
Unit Testing:
• Unit tests designed in the module design phase
• Unit testing is the testing at code level and helps to
eliminate bugs at an early stage

Integration Testing:
• Integration testing is associated with the architectural
design phase.
• Integration tests are performed to test the coexistence
and communication of the internal modules within the
system.
2/17/2020 CSE291 - Introduction to Software Engineering 28

V Model Validation Phases


System Testing:
• System tests check the entire system functionality and the
communication of the system under development with external
systems.

• Most of the software and hardware compatibility issues can be


uncovered during system test execution.

Acceptance Testing:
• Acceptance testing is associated with requirement analysis
phase and involves testing the product in user environment.

• It also discovers the non functional issues such as load and


performance defects in the actual user environment.
2/17/2020 CSE291 - Introduction to Software Engineering 29

V Model
Applicability:

• The V-shaped model should be used for projects where


requirements are clearly defined and fixed.

• The V model should be chosen when technical resources


are available with needed technical expertise.

• High confidence of customer is required for choosing the


V-Shaped model approach.
2/17/2020 CSE291 - Introduction to Software Engineering 30

V Model
Advantages:
• Testing activities like planning, test designing happens
well before coding.
• Higher chances of success over the waterfall model.
• Works well for projects where requirements are easily
understood.

Problems:
• No iteration of phases
• Difficult to handle changes in requirements throughout the
life cycle
2/17/2020 CSE291 - Introduction to Software Engineering 31

Evolutionary Process Models


Evolutionary Development:
• Evolutionary Models are iterative
• Initial system is developed from abstract specification
• Then refined with customer input to produce a system that
satisfies the customer’ s needs.

Two types of evolutionary development


1. Exploratory
2. Prototyping
2/17/2020 CSE291 - Introduction to Software Engineering 32

Evolutionary Models
Exploratory Model

• Objective of the process is to work with customers to explore


their requirements and deliver a final system.

• The development starts with the parts of the system that are
understood.

• The system evolves by adding new features proposed by


customer.

• This model works best in situations where few, or none, of the


system or product requirements are known in detail.
2/17/2020 CSE291 - Introduction to Software Engineering 33

Exploratory Models

Initial
Specification
Version

Outline Intermediate
Description Development Version

Validation Final
Version
2/17/2020 CSE291 - Introduction to Software Engineering 34

Exploratory Model
 Problems:

 Lack of process visibility


 Systems are often poorly structured

 Applicability:

 For small or medium-size interactive systems


 For parts of large systems (e.g. the user interface)
2/17/2020 CSE291 - Introduction to Software Engineering 35

Evolutionary Models
Prototyping Model

• When a customer defines a set of general objectives for a software


but does not identify detailed requirements for functions and
features.

• A prototype is built to understand the requirements.

• By using this prototype, the client can get an “actual feel” of the
system

• The interactions with prototype can enable the client to better


understand the requirements of the desired system

• Prototyping is an attractive idea for complicated and large systems


2/17/2020 CSE291 - Introduction to Software Engineering 36

Evolutionary Models
Prototyping Model

Consists of 4 iterating phases:


• Requirements gathering.
• Design and build prototype.
• Evaluate prototype with customer.
• Refine requirements.
2/17/2020 CSE291 - Introduction to Software Engineering 37

Prototype Model
1. Requirements gathering.
2. Design and build SW prototype.
1/4
3. Evaluate prototype with customer.
Listen to
Customer 4. Refine requirements.

3
2
Customer
Build / Revise
Test-Drives
prototypes
prototypes
2/17/2020 CSE291 - Introduction to Software Engineering 38

Prototyping
Engineer Requirements
Product
No Quick
Yes Design
Changes?

Build
Refine Prototype
Prototype
Evaluate
Prototype (Pressman, 1996)
2/17/2020 CSE291 - Introduction to Software Engineering 39

Prototype Model
Advantages:
• Users are actively involved in the development
• Users get a better understanding of the system being
developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better
solutions.
Disadvantages:
• Practically, this methodology may increase the complexity
of the system as scope of the system may expand beyond
original plans.
2/17/2020 CSE291 - Introduction to Software Engineering 40

Prototype Model
Applicability:

• Prototype model should be used when the desired system


needs to have a lot of interaction with the end users.

• Typically, online systems, web interfaces have a very high


amount of interaction with end users, are best suited for
Prototype model.
2/17/2020 CSE291 - Introduction to Software Engineering 41

Component-based Software Engineering


• Based on systematic reuse where systems are integrated
from existing components.

• People working on the project  Know of design or code


(similar to that required) Modify them as needed 
incorporate them into their system

• Process stages
• Component analysis
• Requirements modification
• System design with reuse
• Development and integration

• This approach is becoming increasingly used


2/17/2020 CSE291 - Introduction to Software Engineering 42

Component-based Software Engineering


2/17/2020 CSE291 - Introduction to Software Engineering 43

Component-based Software Engineering


Component analysis
• Given the requirement specification
• Search is made for components
• Usually there is no exact match.
Requirement Modification
• Requirements are analyzed—using information of discovered
components
• If modifications are impossible— component analysis activity
may be re-entered to search for alternate solution
System Design with Reuse
• Frame work of system is designed or an existing frame work is
reused.
Development and integration Software
• Existing software /modified and newly developed components
are integrated.
2/17/2020 CSE291 - Introduction to Software Engineering 44

Component-based Software Engineering


Advantages
• Reduce the amount of software to be developed
• Reducing cost and risk
• Faster delivery of software
Disadvantages
• Requirement changes—may lead to a system that does
not meet the real needs of users
• Control over the system evolution is lost
2/17/2020 CSE291 - Introduction to Software Engineering 45

Process Iteration
• Change is necessary in all large software projects.

• What to do?

• Iteration means earlier stages are reworked in the process for


large systems

Two (related) process models

• Incremental delivery
• Spiral development
2/17/2020 CSE291 - Introduction to Software Engineering 46

Incremental Approach
“The software specification, design and implementation are
broken down into a series of increments that are each
developed in turn”

• System development is decomposed into increments and


each delivers a proportion of the system.

• Increments are developed based on their requirement


priorities.
2/17/2020 CSE291 - Introduction to Software Engineering 47

Incremental Development

Define outline Assign requirements Design system


requirements to increments architecture

Develop system Validate Integrate Validate


increment increment increment system
Final
system
System incomplete
2/17/2020 CSE291 - Introduction to Software Engineering 48

Incremental Delivery(Steps)
1. Customer identify—services provided by the system
2. Then identify which of the services are most important
and which are least important
3. No of delivery increments are then identified with sub-
set of the system functionality
4. Highest priority services delivered first
5. Requirements for the first increment are defined in
detail
6. First Increment is developed and delivered ..customer
can put into service
7. During development ….further requirements analysis for
later increments can take place
2/17/2020 CSE291 - Introduction to Software Engineering 49

Incremental Model
Advantages:
• Customer value can be delivered with each increment so
system functionality is available earlier.
• Early increments act as a prototype to help elicit
requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most
testing.
Disadvantages:
• Increments should be relatively small (20,000 lines of code).
• Can be difficult to map the customer’s requirements onto
increments of the right size..
2/17/2020 CSE291 - Introduction to Software Engineering 50

Spiral Model
• The spiral model of the software process was originally
proposed by Boehm (Boehm, 1988).

• Rather than represent the software process as a


sequence of activities with some backtracking… process
is represented as spiral

• Each loop in spiral represents a phase of the software


process

• Innermost loop might be concerned with system feasibility


• Next loop with requirements definition…next with system
designed and so on.
2/17/2020 CSE291 - Introduction to Software Engineering 51

Spiral Model Sectors

Each loop in spiral is split into four sectors

Objective setting
• Specific objectives for that phase of the project are identified
• Detail management plan is drawn up
• Identify Project risks
• Alternative strategies depending on these risks ...may be
planned
2/17/2020 CSE291 - Introduction to Software Engineering 52

Spiral Model Sectors


Risk assessment and reduction
• For every identified risk  Detailed analysis is carried out
• Steps are taken to reduce the risk
E.g.
Risk :
Requirements are inappropriate
Solution / Strategy
A prototype system may be developed
* Risks are
• poorly understood requirements
• poorly understood architecture
• performance problems
2/17/2020 CSE291 - Introduction to Software Engineering 53

Spiral Model Sectors


Development and validation
• A development model for the system is chosen which can be
any of the generic models
• For example, if user interface risks are dominant, an
appropriate model may be “Evolutionary Prototyping”.
• Selection of model will depend on your risk analysis.
Planning
• The project is reviewed
• Decision made whether to continue with a further loop of the
spiral
• If decided to continue , the next phase of the spiral is
planned
2/17/2020 CSE291 - Introduction to Software Engineering 54

Spiral Model of the Software Process


Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
anaysis
l Proto-
REVIEW type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product

You might also like