Software Engineering

unit-2

Text Books:1.Software Engineering, A practitioner’s approach

Roger s. Pressman 6th edition McGraw-Hill
2.Software Engineering Somerville 7th edition

1
 PROCESS MODELS
• Help in the software development

• Guide the software team through a set of

framework activities

• Process Models may be linear,

incremental or evolutionary

2
 THE WATERFALL MODEL
• Used when requirements are well
understood in the beginning
• Also called classic life cycle
• A systematic, sequential approach to
Software development
• Begins with customer specification of
Requirements and progresses through
planning, modeling, construction and
deployment
3
 The Waterfall Model
This Model suggests a systematic, sequential
approach to SW development that begins at
the system level and progresses through
analysis, design, code and testing
Communication
Project initiation
requirement gathering
Planning
Estimating
Scheduling
tracking Modeling
Analysis
design
Construction
Code
test Deployment
Delivery
Support
feedback
4
 PROBLEMS IN WATERFALL
MODEL
• Real projects rarely follow the sequential
flow since they are always iterative
• The model requires requirements to be
explicitly spelled out in the beginning,
which is often difficult
• A working model is not available until late
in the project time plan

5
 THE INCREMENTAL PROCESS
MODEL
• Linear sequential model is not suited for
projects which are iterative in nature
• Incremental model suits such projects
• Used when initial requirements are
reasonably well-defined and compelling
need to provide limited functionality quickly
• Functionality expanded further in later
releases
• Software is developed in increments
6
 The Incremental Model
Communication
Software functionality and features

Increment # n
Planning
Modeling Communication
Planning
Modeling
Construction Analysis
design
Construction
Code
test
Deployment
Delivery
Support

Deployment
feedback

delivery of
nth increment
Increment#2

Communication
Planning
Modeling
Construction Deployment
Increment # 1
Analysis
design Code
test
Delivery
Support
Delivery of
feedback
2nd increment

Communication
Planning
Modeling
Analysis Construction Deployment
design
delivery of
Code Delivery
test Support
feedback

1ST increment

Project calendar time

7
 THE INCREMENTAL MODEL
• Software releases in increments
• 1st increment constitutes Core product
• Basic requirements are addressed
• Core product undergoes detailed evaluation by
the customer
• As a result, plan is developed for the next
increment
Plan addresses the modification of core product
to better meet the needs of customer
• Process is repeated until the complete product is
produced
8
 THE RAD MODEL
(Rapid Application Development)
• An incremental software process model
• Having a short development cycle
• High-speed adoption of the waterfall
model using a component based
construction approach
• Creates a fully functional system within a
very short span time of 60 to 90 days

9
 The RAD Model
Team # n
Modeling
Business modeling
Data modeling
Process modeling

Construction
Team # 2 Component reuse
automatic code
generation
Communication Modeling testing

Business modeling
Data modeling
Process modeling

Construction
Planning Team # 1 Component reuse
automatic code
generation
testing
Modeling
Business modeling Deployment
Data modeling integration
Process modeling delivery
feedback

Construction
Component reuse
automatic code
generation
testing

10
 THE RAD MODEL
• Multiple software teams work in parallel on different
functions
• Modeling encompasses three major phases: Business
modeling, Data modeling and process modeling
• Construction uses reusable components, automatic code
generation and testing
• Problems in RAD

Requires a number of RAD teams

Requires commitment from both developer and customer
for rapid-fire completion of activities

Requires modularity

Not suited when technical risks are high

11
 EVOLUTIONARY PROCESS
MODEL
• Software evolves over a period of time
• Business and product requirements often
change as development proceeds making a
straight-line path to an end product unrealistic
• Evolutionary models are iterative and as such
are applicable to modern day applications
• Types of evolutionary models
– Prototyping
– Spiral model
– Concurrent development model

12
 PROTOTYPING
• Mock up or model( throw away version) of a
software product
• Used when customer defines a set of
objective but does not identify
input,output,or processing requirements
• Developer is not sure of:
– efficiency of an algorithm
– adaptability of an operating system
– human/machine interaction

13
Evolutionary Models: Prototype
Quick
Communication Plan

Modeling
Quick design

Construction
Deployment of prototype
delivery &
feedback

14
 STEPS IN PROTOTYPING
• Begins with requirement gathering
• Identify whatever requirements are known
• Outline areas where further definition is
mandatory
• A quick design occur
• Quick design leads to the construction of
prototype
• Prototype is evaluated by the customer
• Requirements are refined
• Prototype is turned to satisfy the needs of
customer
15
 LIMITATION OF PROTOTYPING
• In a rush to get it working, overall software
quality or long term maintainability are
generally overlooked

• Use of inefficient algorithm

• Use of inappropriate OS or PL

16
 THE SPIRAL MODEL
• An evolutionary model which combines the
best feature of the classical life cycle and
the iterative nature of prototype model
• Include new element : Risk element
• Starts in middle and continually visits the
basic tasks of communication,
planning,modeling,construction and
deployment
17
Evolutionary Models: The Spiral

18
 THE SPIRAL MODEL
• 1.COMMUNICATION
*Tasks required are establish effective communication between
developer
• 2.PLANNING
*Estimation
*Scheduling
*Risk analysis
• MODELING
*Analysis
*Design
• CONSTRUCTION
*Code
*Test
• DEPLOYMENT
*Delivery
*Feedback
19
 THE SPIRAL MODEL
• Realistic approach to the development of
large scale system and software
• Software evolves as process progresses
• Better understanding between developer
and customer
• The first circuit might result in the
development of a product specification
• Subsequent circuits develop a prototype
• And sophisticated version of software
20
 THE SPIRAL MODEL
• Each pass through the planning region
results in adjustments to the project plan.
• Cost and schedule are adjusted based on
feedback derived from the customer after
delivery

21
 Disadvantages of Spiral model

• Because of the prototype development and risk analysis in each

phase, it is very expensive and time taking.

• It is not suitable for a simpler and smaller project because of

multiple phases.

• It requires more documentation as compared to other models.

• Project’s success is highly dependent on the risk analysis phase.

22
THE CONCURRENT DEVELOPMENT
MODEL

•Also called concurrent engineering

•Constitutes a series of framework activities, software
engineering action, tasks and their associated states
•All activities exist concurrently but reside in different
states
•Applicable to all types of software development
•Event generated at one point in the process trigger
transitions among the states

23
 A FINAL COMMENT ON
EVOLUTIONARY PROCESS
• Difficult in project planning
• Speed of evolution is not known
• Does not focus on flexibility and
extensibility (more emphasis on high
quality)
• Requirement is balance between high
quality and flexibility and extensibility

24
25
 THE UNIFIED PROCESS
• Evolved by Rumbaugh, Booch, Jacobson
• Combines the best features their OO models
• Adopts additional features proposed by other
experts
• Resulted in Unified Modeling Language(UML)
• Unified process developed Rumbaugh and Booch
• A framework for Object-Oriented Software Engineering
using UML
• It follows an iterative, incremental, architecture-centric, and
use-case driven approach

26
The Unified Process (UP)

27
 THE UNIFIED PROCESS
INCEPTION PHASE
•Encompasses both customer communication and planning
activities.
•A rough architecture for the system is proposed
•A plan for the iterative, incremental nature of the ensuing
project is developed.

ELABORATION PHASE
•Encompasses the communication and modeling activities
•Refines and expands the preliminary use cases that were
developed as part of the inception phase and expands the
architectural representation 28
 PHASES OF UNIFIED PROCESS
Elaboration creates an “executable architectural baseline”
that represents a “first cut” executable system.
CONSTRUCTION PHASE
Architectural model as input, the construction phase
develops or acquires the software components that will
make each use case operational for end users.
TRANSITION PHASE
Encompasses the latter stages of the generic construction
activity and the first part of the generic deployment
(delivery and feedback) activity.

29
PHASES OF UNIFIED PROCESS
PRODUCTION PHASE
•The ongoing use of the software is
monitored, support for the operating
environment (infrastructure) is provided, and
defect reports and requests for changes are
submitted and evaluated.

30
UNIFIED PROCESS WORK PRODUCTS
• Tasks which are required to be completed during
different phases
• Inception Phase
*Vision document *Initial
Use-Case model *Initial Risk
assessment *Project Plan
• Elaboration Phase *Use-
Case model *Analysis model
*Software
Architecture description *Preliminary
design model *Preliminary
model

31
UNIFIED PROCESS WORK PRODUCTS

• Construction Phase
*Design model
*System components *Test
plan and procedure *Test
cases
*Manual
• Transition Phase
*Delivered software increment
*Beta test results
*General user feedback
32
SOFTWARE REQUIREMENTS
• IEEE defines Requirement as :
1. A condition or capability needed by a user to
solve a problem or achieve an objective

2. A condition or capability that must be met or

possessed by a system or a system
component to satisfy constract,standard,
specification or formally imposed document

3. A documented representation of a condition

or capability as in 1 or 2

33
 SOFTWARE REQUIREMENTS
• Encompasses both the User’s view of the
requirements( the external view ) and the
Developer’s view( inside characteristics)
• User’s Requirements
--Statements in a natural language plus
diagram, describing the services the system is
expected to provide and the constraints
• System Requirements
• --Describe the system’s function, services and
operational condition

34
SOFTWARE REQUIREMENTS
• System Functional Requirements
--Statement of services the system should provide
--Describe the behavior in particular situations
--Defines the system reaction to particular inputs
• Nonfunctional Requirements
- Constraints on the services or functions offered by the system
--Include timing constraints, constraints on the development
process and standards
--Apply to system as a whole
• Domain Requirements
--Requirements relate to specific application of the system
--Reflect characteristics and constraints of that system

35
 FUNCTIONAL REQUIREMENTS
• Should be both complete and consistent
• Completeness
-- All services required by the user should
be defined
• Consistent
-- Requirements should not have
contradictory definition
• Difficult to achieve completeness and
consistency for large system
36
 NON-FUNCTIONAL
•
REQUIREMENTS
Types of Non-functional Requirements
• 1.Product Requirements
-Specify product behavior
-Include the following
• Usability
• Efficiency
• Reliability
• Portability
2.Organisational Requirements
--Derived from policies and procedures
--Include the following:
 Delivery
 Implementation
 Standard

• 3.External Requirements
-- Derived from factors external to the system and its development process
--Includes the following
 Interoperability
 Ethical
 Legislative

37
 Different types of non-functional
requirements
Non-functional
requirements

Product Organisational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements

Usability Delivery Implementa tion Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements
38
 PROBLEMS FACED USING THE
NATURAL LANGUAGE
• 1. Lack of clarity
-- Leads to misunderstanding because of
ambiguity of natural language
2. Confusion
-- Due to over flexibility,sometime difficult to
find whether requirements are same or distinct.
3. Amalgamation problem
-- Difficult to modularize natural language
requirements

39
 STRUCTURED LANGUAGE
SPECIFICATION
• Requirements are written in a standard
way
• Ensures degree of uniformity
• Provide templates to specify system
requirements
• Include control constructs and graphical
highlighting to partition the specification

40
 SYSTEM REQUIREMENTS
STANDARD FORM
• Function
• Description
• Inputs
• Source
• Outputs
• Destination
• Action
• Precondition
• Post condition
• Side effects
41
 Interface Specification
• Working of new system must match with the existing
system
• Interface provides this capability and precisely specified
• Three types of interfaces
1.Procedural interface
-- Used for calling the existing programs
by the new programs
2.Data structures
--Provide data passing from one sub-system to
another
3.Representations of Data
-- Ordering of bits to match with the existing system
--Most common in real-time and embedded system
42
 The Software Requirements document
• The requirements document is the official
statement of what is required of the system
developers.
• Should include both a definition of user
requirements and a specification of the system
requirements.
• It is NOT a design document. As far as possible,
it should set of WHAT the system should do
rather than HOW it should do it

43
The Software Requirements document
• Heninger suggests that there are 6 requirements
that requirement document should satisfy. It
should
 specify only external system behavior
 specify constraints on the implementation.
 Be easy to change
 Serve as reference tool for system maintainers
 Record forethought about the life cycle of the system.
 Characterize acceptable responses to undesired
events

44
 Purpose of SRS

• communication between the Customer,

Analyst,system developers, maintainers, ..
• firm foundation for the design phase
• support system testing activities
• Support project management and control
• controlling the evolution of the system

45
 IEEE requirements standard

• Defines a generic structure for a

requirements document that must be
instantiated for each specific system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.

46
 IEEE requirements standard

1.Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview

47
2. General description
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific Requirements
- Functional requirements
-External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability,maintainability,
transferability/conversion
- Other requirements
48
• Appendices
• Index

49