Software

Engineering and
Management
[21CS61]

Department of AI &ML

Page 1
 Module-1:Introduction
What is software?
A program is a set of instructions that performs a specific
task. Software is a set of programs that accomplish a collective
functionality.
Properties of software differ from the properties of physical
constructs. The abstract and intangible nature of the software
makes it different. Software could be complex, difficult to
understand and expensive to change depending on the type of
software being developed. Depending on the context of its
operation different types of software require different
approaches for development. It is also possible that software
can fail. The failure of software could be due to:
1)Increase in demand and
2)Low expectation

What is Software Engineering?

Software Engineering is an engineering discipline that involves
the education of building software using appropriate theories
and methods to solve problems bearing in mind organizational
and financial constraints. While doing so, all aspects of
software production are considered and not just technical
process of development. Also, project management and the
development of tools, methods etc. to support software
production should also be considered.

Why is software engineering required?

Software engineering principles involve techniques and
practices that are used and tested. It is very much required to
be able to produce reliable and trustworthy systems
economically and quickly. It is usually cheaper, in the long

Page 2
 run, to use software engineering methods and techniques for
software systems.
Software products can be categorised into:
1. Generic products: These are stand-alone systems that are
marketed and sold to any customer who wishes to buy them.
Examples – PC software such as graphics programs, project
management tools; CAD software; software for specific markets
such as appointments systems for dentists.
2. Customized products: Software that is commissioned by a
specific customer to meet their own needs. Such products are
generally used to solve a problem in a specific domain.
Examples – embedded control systems, air traffic control
software, traffic monitoring systems.
The attributes of good software are:
Maintainability –Every software developed should be able to
meet the changing needs of customers.
Dependability and security- Software developed for any
situation should not cause physical or economic damage in the
event of system failure. Care should be taken that malicious
users should not be able to access or damage the system.
Efficiency – Depending on the context, the developed software
would be evaluated based on its responsiveness, processing
time and memory utilisation
Acceptability- Any software developed should be
understandable, usable and compatible with other systems in
the context that work in unison with it.
Software crisis
It is obvious to note that it is very difficult to write efficient
software within the right time specified. This could be due to
various reasons such as

Page 3
 1. Heterogeneity –increasingly, systems are required to
operate as distributed systems across networks that
include different types of computer and mobile devices.
2. Business and social change: Business and society are
changing incredibly quickly as emerging economies
develop and new technologies become available. They
need to be able to change their existing software and to
rapidly develop new software.
Security and trust also plays a very important role in
developing a software module. As software is intertwined with
all aspects of our lives, it is essential that we can trust that
software. Hence appropriate security measures need to be
taken to safeguard the software from external attack.

Software Engineering Ethics

Software development does not just involve technical skills,
but also includes ethics. The team involved in the software
development is expected to be honest and ethically responsible
for the software at all times. The following factors need to be
addressed during, before and after software development.
a) Confidentiality: It is the employers‟ responsibility to
maintain confidentiality of the employee information and
it is the employee responsibility to maintain the secrecy
and confidentiality involved in the development of
software.
b) Competence: It is the ethical responsibility of an
employee to accept work that matches his technical
skills. He should be competent enough to carry out the
task assigned to him.
c) IPR (Intellectual Property Rights) – Very tricky, but very
essential. It has to be taken care that when reusing

Page 4
 existing components for software development, the
components is available for use as per IPR.
d) Computer misuse- Using the computer provided by the
employer for personal use is misconduct and misuse of
the system. Watching videos, playing songs, browsing
social networking sites all mark the misuse of computer.

Software process activities

Any software developed generally follows the following software
process activities:
1. Software specification – Involves gathering requirements
for the development of software
2. Software development- involves the implementation of
the software.
3. Software validation – verifying if the software developed
meets its requirements.
4. Software evolution- making sure that the software can
be modified with respect to change in requirements over
time.
Case studies
Insulin pump control system:
This is a system that collects data from a blood sugar sensor
and calculates the amount of insulin required to be injected.
Calculation is based on the rate of change of blood sugar
levels. It is programmed to send signals to a micro-pump to
deliver the correct dose of insulin.
This system is considered as a safety-critical system as low
blood sugars can lead to brain malfunctioning, coma and
death; and high-blood sugar levels have long-term
consequences such as eye and kidney damage. Hence the
software involved should function just as expected. The
architecture of the system is shown in Fig 1.

Page 5
 Fig 1: Architecture of insulin pump control system

High-level requirements specifications can be written as

follows
1. The system shall be available to deliver insulin when
required.
2. The system shall perform reliably and deliver the correct
amount of insulin to counteract the current level of
blood sugar.
3. The system must therefore be designed and implemented
to ensure that the system always meets these
requirements.

MHC-PMS (Mental Health Care-Patient Management

System)
This is a system which makes use of a centralized database of
patient information. When the local systems have secure
network access, they use patient information in the database
but they can download and use local copies of patient records
when they are disconnected. Most mental health patients do
not require dedicated hospital treatment but need to attend
specialist clinics. Fig 2 shows the architecture of this system.

Page 6
 Fig 2: Architecture of
MHC-PMS The system is expected to
support the following functionality:
1. Individual care management
2. Patient monitoring
3. Administrative reporting
4. Other Aspects that need to be considered other than
functional are:
Privacy - patient information is confidential. At
most care need to be taken to protect the privacy of the
patient and his illness details.
Safety - prescribe the correct medication to
patients.

Software Processes
Software processes are a integral part of software process
models. Various process activities that are carried out during
every phase of development form the software activities. To
define technically, A software process is a structured set of
activities required to develop a software system. The activities
by and large include:
1. Specification – defining what the system should do;
2. Design and implementation – defining the organization of
the system and implementing the system;

Page 7
 3. Validation – checking that it does what the customer
wants;
4. Evolution – changing the system in response to changing
customer needs.

Requirements engineering process

Requirements engineering process consists of the following
activities:
a) Feasibility study – Technical and Financial feasibility of
the project needs to be considered.
b) Requirements elicitation and analysis – Expectation from
the system. The functionalities that the system is
expected to provide.
c) Requirements specification – Defining requirements for
every activity performed by the user or set of users and
the expected outcome for each of these activities.
d) Requirements validation – Checking validity of the
requirements. Verifying if the requirements specification
contains the functionalities that the system is expected
to perform.
The requirements engineering process is depicted in Fig 3.

Page 8
 Fig 3: Requirements Engineering Process
Once the feasibility study has been completed a feasibility
report is generated. It is observed that the requirements
elicitation and analysis, requirements specification and
requirements validation are iterative activities. Based on the
analysis it is required to decide on a system model that needs
to be incorporated as a part of requirements document. The
requirements specification activity gives the complete user and
system requirements. The requirements validation process
checks if the system performs the required functions and the
requirement specification covers all functionalities to be
provided by the system. The outcome of each activity is an
input to the requirements document.

Software design and implementation

Once the requirements for specific software have been
gathered the next activity is to design and develop the
software. These activities could be performed individually or in
parallel depending on the project. Each of these activities have
a set of process activities to be carried out. They are described
in detail below:
Software design
The major aim of this phase of software development is to
design a software structure that realises the specification as
given by the requirements specification document.

Page 9
 Model of the design process

Fig 4: Design process and activities involved

Design activities involve Architectural design, interface design

and component design. The system architecture and its
components need to be defined and specified as a part of
architectural design. The interface design involves the
specification and working of interfaces for enables inter and
intra component communication.

Implementation
Translate this structure into an executable program. This
requires the use of a programming language. The choice of
programming language is based on the complexity of the
software, the requirements specification of the software, the
reusability of components in the software etc.

Software validation
Validating the software involve checking for conformation of
the system to its specification. This also involves checking and
review processes and system testing. System testing involves

Page 10
executing the system with test cases. The system testing
involves Component testing and acceptance testing.
Component testing involves testing of each component that is
used to build the software. The interfaces between the
components and the working of components with the existing
system code needs to be tested. The process activities involved
in testing and its iterations are shown in Fig 5. Every
individual component is tested and then system is tested as a
whole. Acceptance testing is done to determine if the system is
functioning well in the domain of its application.

Fig 5: Testing activities

The various phases of testing are depicted below in Fig 6. It is
a wrong notion that testing only begins after implementation is
complete. As a fact, testing is carried out throughout the
development process. The figure below depicts the outcome of
each activity in the phase of testing.

Testing phases

Page 11
 Fig 6: Phases of testing
As and when the requirements specification is complete the
acceptance test plan is also parallel written because the
acceptance testing involves testing of the software in its
working domain. Acceptance test cases are written at this
stage. The test plan gets its input from both requirements
specification as well as system specification activities. The
system integration test plan is an output of system
specification and design. Workings of individual components,
testing for interfaces between them are all a part of system
integration testing. Once the detailed design is available the
sub system integration test plan is also drafted. Later on the
tests are accomplished by making use of the test plan.
This is also called as V-model for test plan driven software
development process.

Software Evolution

Page 12
 Fig 7: Activities in software evolution
It is obvious that software is inherently flexible and can
change. As requirements change through changing business
circumstances, the software that supports the business must
also evolve and change. Although there has been a
demarcation between development and evolution
(maintenance) this is increasingly irrelevant as fewer and fewer
systems are completely new. Fig 7 depicts the activities
involved in software evolution. Existing system is continuously
assessed based on the system requirements. If any change has
been proposed the system needs to be modified and a new
system is then released. This is an iterative process and
continues until the required outcome has been obtained.

Software Process Model

A software process model is an abstract representation of a
process. The process descriptions may also include:
1. Products, which are the outcomes of a process activity;
2. Roles, which reflect the responsibilities of the people
involved in the process.
3. Pre- and post-conditions, which are statements that are
true before and after a process activity has been enacted
or a product produced.

Page 13
 Process activities
Processes are inter-leaved sequences of activities with the
overall goal of specifying, designing, implementing and testing
a software system. The four basic process activities of software
development are organized differently in different development
processes depending on the application being developed. The
activities are: specification, development, validation and
evolution. Each of these is explained in detail in the rest of the
chapters.

Software specification
The specification of the software requires answering the
following questions:
a) What are the services required by the software? – To get
the functionalities of the software to be developed.
b) What are the constraints on system operation?- To get
the domain information of the software to be developed.

Models
a) The waterfall model: This is a plan-driven model. There
are separate and distinct phases of specification and
development.
b) Incremental development: This is model where the
specification, development and validation are
interleaved. Incremental development may follow either
plandriven approach or agile approach.
c) Reuse-oriented software engineering: The system is
assembled from existing components. This approach
also may be plan-driven or agile.
There is no hard rule on the model chosen for
developing a particular application. In practice, most large
systems are developed using a process that incorporates
elements from all of these models. Each of these models are
described in detail below:

Page 14
 Water fall model

Fig 8: Waterfall
model The phases of Waterfall model
depicted in Fig 8 are:
a) Requirements analysis and definition – Gathering the
requirements and defining the functionality of each
requirement. This could be done through various
techniques discussed in the next section.
b) System and software design- Design and architecting the
software as a whole. The components involved, the
interface between them and other design considerations
are depicted as diagrams. UML diagrams are most
frequently used design representations.
c) Implementation and unit testing – Developing the system
and testing each module one by one as a single unit.
Every component developed or reused are individually
tested.
d) Integration and system testing- The components are
integrated together and the system is tested as a whole.

Page 15
 The interfaces and communication modules between the
systems are tested here.
e) Operation and maintenance- Once the system is put into
use, the functionality of the system in the operational
domain needs to be taken care of. The maintenance and
operation of the system at the client end is important.

Problems with Waterfall model

The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway.
Inflexible partitioning of the project into distinct stages makes
it difficult to respond to changing customer requirements. The
waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites.

Incremental development and delivery

Fig 9: Process in incremental

development

Page 16
Incremental development involves developing the system in
increments and evaluating each increment before proceeding
to the development of the next increment. This is the normal
approach used in agile methods. The evaluation of software
developed using incremental approach is done by
user/customer proxy.
Incremental delivery involves deploying an increment for use
by end-users. This is a more realistic evaluation about
practical use of software. It is difficult to implement for
replacement systems as increments have less functionality
than the system being replaced.
Advantages and disadvantages
Cost of accommodating changing customer requirements is
reduced. Customer feedback on the development is obtained
as and when an increment is ready to be released. Rapid
delivery and deployment of useful software can be
accomplished by making use of this approach.
The Problems with this approach is that the process is not
visible. Also, it is inevitable that system structure tends to
degrade as new increments are added.

Boehm‟s spiral model

Page 17
 Fig 10: Boehm‟s spiral model
Fig 10 shows the Boehm‟s spiral model. Here the process is
represented as a spiral rather than as a sequence of activities
with backtracking. Each loop in the spiral represents a phase
in the process. There are no fixed phases such as specification
or design. The loops in the spiral are chosen depending on
what is required. Risks are explicitly assessed and resolved
throughout the process. Spiral model has been very influential
in helping people think about iteration in software processes
and introducing the risk-driven approach to development. In
practice, however, the model is rarely used as published for
practical software development.
Sectors of spiral model
The following are the sectors of the spiral model:
1. Objective setting -Specific objectives for the phase are
identified.
2. Risk assessment and reduction-Risks are assessed and
activities put in place to reduce the key risks.

Page 18
 3. Development and validation-A development model for the
system is chosen which can be any of the generic
models.
4. Planning-The project is reviewed and the next phase of
the spiral is planned.

Requirements Engineering
Requirements engineering definition: The process of
establishing the services that the customer requires from a
system and the constraints under which it operates and is
developed. The requirements themselves are the descriptions
of the system services and constraints that are generated
during the requirements engineering process. A requirement
may range from a high-level abstract statement of a service or
of a system constraint to a detailed mathematical functional
specification. This is inevitable as requirements may serve a
dual function as described in the following scenarios:
1) May be the basis for a bid for a contract - therefore must
be open to interpretation;
2) May be the basis for the contract itself - therefore must be
defined in detail;
3) 3) Both these statements may be called requirements.
Types of requirements:
Requirements can be basically categorised into:
1. User requirement which are statements in natural
language plus diagrams of the services the system
provides & its operational constraints. Basically specifies
external system behavior. These are the requirements
which are written for customers
2. Systems Requirements are a structured document
setting out detailed descriptions of the system‟s
functions, services & operational constraints. It is

Page 19
 necessary that the systems requirements should reflect
accurately what the customer wants and should also
precisely define what should be implemented. This could
be a part of a contract between client and contractor
Example of a user requirement:
In a Library management system, the following functionalities
are expected to be present
1. The system will maintain records of all library items
including books, serials, newspapers, magazines, video
and audio tapes, reports, collections of transparencies,
computer discs and CD-ROMs.
2. Paper-based library items are stored on open shelves in
the library and the system records their reference
position in the library.
3. No item will be removed from the library without the
details of its borrowing being recorded in the system.
4. All items will have a bar code containing a unique
reference number by which an item can be identified
within the system.
For the same application the example of a System requirement
could be:
1. The system will permit all users to search for an item by
title, by author or by ISBN
2. Staff will be able to search for an item by bar code ref.
number
3. Books can be borrowed for 15 days while CD-ROMs,
Audio tapes & reports can be borrowed only for 3 days
4. Borrowed items that are one day overdue in their return
will cause a reminder letter to be printed
5. Librarian should be able to find out details like Number
of books & materials borrowed (on a given day, by a
given client)
6. Selected items may be temporarily blocked by authorized
staff

Page 20
 Readers of different types of requirements
specification

Fig 11: Readers of requirements

Fig 11 shows that the users of User requirements and system

requirements are generally the System end-users, client
engineers and system architects. Additionally, Contract
managers and client managers will be using the user
requirements and the system requirements are the guiding
path for system developers.
Classification of requirements – Another way
1. Functional requirements: Statements of services the
system should provide, how the system should react to
particular inputs and how the system should behave in
particular situations. These requirements may also state
what the system should not do.
2. Non-functional requirements: Constraints on the
services or functions offered by the system such as

Page 21
 timing constraints, constraints on the development
process, standards, etc.
3. These requirements often apply to the system as a whole
rather than individual features or services.
4. Domain requirements: Constraints on the system from
the domain of operation of the final system.
Each of the above requirements is explained in detail.
Functional Requirements:
Describe functionality or system services and depend on the
type of software, expected users and the organization where
the software is used. This could be high-level statements of
what the system should do. However, it should describe all the
system services in detail which could include its inputs, its
Outputs, exceptions and so on. Such requirements are
generally described in fairly abstract but precise way.
Non-Functional Requirements:
Define system properties and constraints e.g. reliability,
response time and storage occupancy, Security, etc..
Alternatively they may define platform constraints like, I/O
devices capability, data representations. Process requirements
may also be specified mandating a particular CASE system,
programming language or development method. These
requirements arise through organizational policies, budget
limits, interoperability needs etc. They may be considered to be
more critical than functional requirements because if these are
not met, the system will be useless.
Non-functional requirements can be further classified as
shown in Fig 12

Page 22
 Fig 12: Classification of
Non-functional requirements The classification can
be described as given below:
1. Product requirements: Requirements which specify that
the delivered product must behave in a particular way
e.g. execution speed, reliability, etc.
2. Organisational requirements: Requirements which are a
consequence of organisational policies and procedures
e.g. process standards used, implementation
requirements, etc.
3. External requirements: Requirements which arise from
factors which are external to the system and its
development process e.g. interoperability requirements,
legislative requirements, etc.
Non-functional requirements may affect the overall
architecture of a system rather than the individual
components. For example, to ensure that performance
requirements are met, you may have to organize the system to
minimize communications between components.
A single non-functional requirement, such as a security
requirement, may generate a number of related functional

Page 23
requirements that define system services that are required. It
may also generate requirements that restrict existing
requirements.

Metrics for specifying nonfunctional requirements

Since non-functional requirements are equally important for
the operation of a software metrics have been defined to
indicate non-functional requirements as a part of
requirements specification document. This is indicated in
Table 1.

Table 1 : Metrics for non-functional requirements

The software requirements document

The software requirements document is the official statement
of what is required of the system developers. It should include
both a definition of user requirements and a specification of
the system requirements. It is not a design document. As far

Page 24
as possible, it should be a set of what the system should do
rather than how it should do it.
Fig 13 shows the users of a requirements document. The
illustration is self-explanatory. It should be noted that
requirements specification is not just for end users or for
developers.
It is for all those entities who are involved through out the
software development process.

Fig 13: Users of a software requirements document

Page 25
 IEEE structure of a requirements document
The table below describes the various chapters and its
description for a standard requirements document. This is
given by the IEEE. All software do not necessarily follow this
exact structure. But a standard structure tuned to the needs
of the application is required to be followed.

Table 2: The IEEE structure of a requirements document

Chapter
Description

Preface This should define the expected readership of the

document and describe its version history,
including a rationale for the creation of a new
version and a summary of the changes made in
each version.
Introduction This should describe the need for the system. It should
briefly describe the system‟s functions and
explain how it will work with other systems. It
should also describe how the system fits into the
overall business or strategic objectives of the
organization commissioning the software.
Glossary This should define the technical terms used in the
document. You should not make assumptions about
the experience or expertise of the reader.
User requirements Here, you describe the services provided for
the user. The nonfunctional definition system requirements should
also be described in this section. This description may use natural
language, diagrams, or other notations that are understandable to
customers. Product and process standards that must be followed
should be specified.
System architecture
This chapter should present a high-level overview of the

Page 26
 anticipated system architecture, showing the
distribution of functions across system modules.
Architectural components that are reused should be
highlighted.
System requirements This should describe the functional and
nonfunctional requirements in specification more detail. If
necessary, further detail may also be added to the nonfunctional
requirements. Interfaces to other systems may be defined.
System models This might include graphical system models showing
the relationships between the system
components and the system and its environment.
Examples of possible models are object models,
data-flow models, or semantic data models.
System evolution This should describe the fundamental
assumptions on which the system is based, and
any anticipated changes due to hardware
evolution, changing user needs, and so on. This
section is useful for system designers as it may
help them avoid design decisions that would
constrain likely future changes to the system.
Appendices These should provide detailed, specific information that
is related to the application being developed; for
example, hardware and database descriptions.
Hardware requirements define the minimal and
optimal configurations for the system. Database
requirements define the logical organization of
the data used by the system and the
relationships between data.

Index Several indexes to the document may be included. As well

as a normal alphabetic index, there may be an index of
diagrams, an index of functions, and so on.

Ways of writing system requirements specification

There are different ways of writing requirements specification.
Table 3 describes the notations generally used and its
description:

Table 3: Notations for writing requirement specification

Page 27
 Notation Description
Natural The requirements are written using
numbered sentences in language natural language. Each
sentence should express one requirement.
Structured The requirements are written in natural
language on a standard natural form or template. Each
field provides information about an language aspect of
the requirement.
Design This approach uses a language like a
programming language, description but with more
abstract features to specify the requirements by
languages defining an operational model of the system.
This approach is
now rarely used although it can be
useful for interface specifications.
Graphical Graphical models, supplemented by text
annotations, are used to notations define the functional
requirements for the system; UML use case and
sequence diagrams are commonly used.
Mathematical These notations are based on
mathematical concepts such as specifications finite-state
machines or sets. Although these unambiguous
specifications can reduce the ambiguity in a
requirements document, most customers don‟t
understand a formal specification. They cannot check
that it represents what they want and are reluctant to
accept it as a system contract

Tools for Specifying System Requirements

This section deals with the ways to write requirements
specification.
1. Structured language: A language with constructs
similar to programming
Example: System Requirements for Address book
Case : 1
List Option selected
Show
first 3
addresses

Page 28
If down arrow
pressed
scroll the
addresses
else
If any “Alpha key pressed
Display the first address starting from that
alpha

End if
Endif
2. Form Based approach: Creates a standard format for
specifying requirements.
Typically can have entries like :
1. Definition of the function or entity.
2. Description of inputs and where they come from.
3. Description of outputs and where they go to.
4. Indication of other entities required.
5. Pre and post conditions (if appropriate )
This method eliminates problems of natural language. This
also brings in uniformity & comprehensiveness. Not always
useful Example specifying interactions)
3. Tabular Model
This is also used to supplement natural language.
This is particularly useful when you have to define a
number of possible alternative courses of action.
Example:

Page 29
 Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of CompDose = 0
increase decreasing ((r2-r1)<(r1-r0)) CompDose = round ((r2-r1)/4)
Sugar level increasing and rate of If rounded result = 0 then
increase stable or increasing. ((r2-r1) ≥
(r1-r0)) CompDose = MinimumDose
4. Graphical Model ( like sequence diagram of UML)
This is most useful when state changes need to be depicted
OR Sequence of actions & interactions need to be described.
Sample Requirements Document
A typical SRS would look like the following example taken from
a weblink free to download document.
To be strictly used for Educational purpose only:
A document of Global Digital Megacorp Student Information
Management System available on:
web.uvic.ca/~cloke/Seng321Designer/SENG321-2008_Group
4_RS1.0.doc
Requirements Engineering (RE) processes
The processes used for RE vary widely depending on the
application domain, the people involved and the organisation
developing the requirements. However, there are a number of
generic activities common to all processes which are:
1. Feasibility Study
2. Requirements elicitation;
3. Requirements analysis;
4. Requirements validation;
5. Requirements management.
In practice, RE is an iterative activity in which these processes
are interleaved.
The spiral view of requirements engineering process is shown
in Fig 14

Page 30
 Fig 14: Spiral view of Requirements
engineering process
1. Feasibility Study : Decides whether or not the proposed system
is worthwhile attempting. A short focused study that checks
the following:
a) If the system contributes to organisational
objectives;
b) If the system can be engineered using current
technology and within budget;
c) If the system can be integrated with other systems
that are used
d) If the system can fit into the cultural framework of
the organizational culture and acceptable to all the
stake-holders
Information collection is done by asking questions to the
stake-holders of the system Typical Questions could be:
a) What if the system wasn‟t implemented?

Page 31
 b)What are current process problems?
c)How will the proposed system help?
d)What will be the integration problems?
e)Is new technology needed? What skills?
f)What facilities must be supported by the proposed
system?
2. Requirement Elicitation
Involves Interacting with technical staff working with
customers to find out about
the application domain, the services that the system should
provide and the system‟s operational constraints. This may
involve stakeholders like end-users, managers, Engineers
involved in maintenance, domain experts, trade unions, etc.
Domain requirements are also discovered at this stage.
Domain Requirements are derived from the application domain
rather than specific needs of a customer in that domain. They
usually refer to specialized domain terminology / concepts.
They describe system characteristics & features that reflect
the domain. Domain requirements could be
1. New functional requirements,
2. Constraints on existing requirements or
3. Define specific computations.
If domain requirements are not satisfied, the system may be
unworkable.
The requirements elicitation and analysis process
Fig 15 shows the process of requirements elicitation and
analysis.

Page 32
 Fig 15: Requirements elicitation and analysis process
Requirements Elicitation is done through
1. Interviewing: The RE team puts questions to
stakeholders about the system that they use and the
system to be developed. There are two types of
interviews:
Closed interviews where a pre-defined set of
questions are answered.
Open interviews where there is no pre-defined
agenda and a range of issues are explored with
stakeholders.
Normally a mix of closed and open-ended
interviewing is good for getting an overall understanding
of what stakeholders do & how they interact with the
system. This method is not good for understanding
domain requirements
2. Observation & study: Observation (in-situ): The RE team
observes the manual process in action, in-situ and infers
required information. This is good for process oriented
systems. Minimal disturbance to user staff.
Study- Additional information is gathered from
study of documents, forms manuals , rulebooks and
other artifacts used by the actors of the system . Here
the analyst must be well experienced with the domain
Problems with Requirement Elicitation
1. Stakeholders don‟t know what they really want.
2. Stakeholders express requirements in their own terms.
3. Different stakeholders may have conflicting
requirements.
4. Organisational and political factors may influence the
system requirements.
5. The requirements change during the analysis process

Page 33
 6. New stakeholders may emerge and the business
environment change
Activities of Requirement Analysis
1. Requirements classification and organisation : Grouping
related requirements and organising them into coherent
clusters
2. Prioritisation and negotiation: Prioritising requirements
and resolving requirements conflicts requirements
documentation
3. Requirements are documented and input into the next
round of the spiral Requirements validation
This is concerned with demonstrating that the requirements
define the system that the customer really wants.
Requirements error costs are high so validation is very
important. Fixing a requirements error after delivery may cost
up to 100 times the cost of fixing an implementation error.
Requirements checking
To check the requirements for a software, the following
parameters need to be considered:
1. Validity. Does the system provide the functions which
best support the customer‟s needs?
2. Consistency. Are there any requirements conflicts?
3. Completeness. Are all functions required by the
customer included?
4. Realism. Can the requirements be implemented given
available budget and technology
5. Verifiability. Can the requirements be checked?
Requirements validation techniques
Various ways exist for validating the requirements:
1. Requirements reviews: This involves systematic manual
analysis of the requirements.
2. Prototyping: This involves using an executable model of
the system to check requirements.

Page 34
 3. Test-case generation: Developing tests for requirements
to check testability.
Requirements reviews
It is essential that regular reviews should be held while the
requirements definition is being formulated. Both client and
contractor staff should be involved in reviews. Reviews may be
formal (with completed documents) or informal. Good
communications between developers, customers and users can
resolve problems at an early stage.
Review checks
Parameters for review checks consist of checking for the
following:
1. Verifiability: Is the requirement realistically testable?
2. Comprehensibility: Is the requirement properly
understood?
3. Traceability: Is the origin of the requirement clearly
stated?
4. Adaptability: Can the requirement be changed without a
large impact on other requirements?
Requirements management
Process of understanding and controlling the changing
requirements during the requirements engineering process
and system development forms the major activity of
requirements management. Requirements are inevitably
incomplete & inconsistent. New requirements emerge during
the process as business needs change and a better
understanding of the system is developed. Different viewpoints
have different requirements and these are often contradictory.
All this needs reconciliation & management.
Reasons for change in Requirements
1. The business and technical environment of the system
always changes after installation. New hardware may be
introduced, it may be necessary to interface the system
with other systems, business priorities may change (with
consequent changes in the system support required),

Page 35
 and new legislation and regulations may be introduced
that the system must necessarily abide by.
2. The people who pay for a system and the users of that
system are rarely the same people. System customers
impose requirements because of organizational and
budgetary constraints. These may conflict with end-user
requirements and, after delivery; new features may have
to be added for user support if the system is to meet its
goals.
3. Large systems usually have a diverse user community,
with many users having different requirements and
priorities that may be conflicting or contradictory. The
final system requirements are inevitably a compromise
between them and, with experience, it is often discovered
that the balance of support given to different users has
to be changed.
Requirements management planning
This activity establishes the level of requirements management
detail that is required. It is essential that Requirements
management decisions need to be taken for the following
purposes:
1. Requirements identification- Each requirement must be
uniquely identified so that it can be cross-referenced
with other requirements.
2. A change management process -This is the set of
activities that assess the impact and cost of changes. I
discuss this process in more detail in the following
section.
3. Traceability policies- These policies define the
relationships between each requirement and between
the requirements and the system design that should be
recorded.

Page 36
4. Tool support- Tools that may be used range from
specialist requirements management systems to
spreadsheets and simple database systems.

Page 37
 Module 2 :System
Models
Introduction
The aim of this Session is to introduce system modeling
concepts that may be developed as part of the requirements
engineering and system design processes.
At the end of the session, the students will:
1. Understand What is Modelling
2. Justify why Modeling is required before building a
software system
3. Appreciate fundamental system modeling perspectives of
context, interaction, structure, and behavior
4. Be aware of the ideas underlying model-driven
engineering, Difference between structural and
behavioral models
✔ Software Systems are abstract and intangible and hence
tend to be complex
✔ A Model represents essential characteristics of a complex
system
✔ System modeling is the process of developing (abstract)
models of a system, with each model presenting a view of
that system
✔ A system model represents aspects of a system and its
environment
✔ Modeling Helps Understand Information systems

What is a Model
A Model is a simplified representation of either reality or
vision. Since “a picture is worth a thousand words,” most
models use pictures to represent the reality or vision. Usually,
the system model becomes the blueprint for designing and
constructing an improved system.
A Model is a simplified representation of a complex system

Page 38
System Modeling
System modeling is the process of developing abstract models
of a system, with each model presenting a different view or
perspective of that system.
Since “a picture is worth a thousand words,” most models use
some kind of graphical notation representing a system, which
is now almost always based on notations in the Unified
Modeling Language (UML).
Model-driven analysis is a problem-solving approach that
emphasizes the drawing of graphical or pictorial system
models to document and validate both existing and/or
proposed system.
Benefits of System Modeling
1. Ease project management tasks.
2. Can provide complete views of a system, as well as
detailed views of subsystems.
3. Clarify structures and relationships.
4. Offer a communication framework for ideas within and
between teams.
5. Can generate new ideas and possibilities.
6. Allow quality assurance and testing scenarios to be
generated.
7. Are platform independent.

Why Modeling
Modeling is required to
1. Understand the existing software application to do any
enhancement
2. Derive the requirements for a New software application
3. Discuss Different Design proposals to optimize the
solution architecture
4. Document a Software Systems Structure and Operations
to create Manuals
5. To Create Test Cases early in the Software Development
Life Cycle

Page 39
 6. Modeling is used to
i.

Conceptualize, ii.

Understand and iii.

Communicate the functioning of a

complex software system to stakeholders

Fig 1.1 Models of a Software System

Types of Models
Different models may represent a system from different
perspectives. For example:
1. An external perspective model representing the context
or environment of the system
2. An interaction perspective Model where the interactions
between a system and its environment or between the
components of a system is represented.
3. A structural perspective model showing the organization
of a system or the structure of the data that is processed
by the system.
4. A behavioral perspective, where the model shows the
dynamic behavior of the system and how it responds to
events.

Page 40
How to represent a Model
1. System Models are Usually represented graphically and
so are the software system Models.
2. Graphical models are very popular because they are
easy to understand and construct.
3. The Unified Modeling Language (UML) provides a
standard for the artifacts of development (semantic
models, syntactic notation, and diagrams
4. UML is a general-purpose, developmental, modeling
language in the field of software engineering, that is
intended to provide a standard way to visualize the
design of a system.
5. The creation of UML was originally developed by Grady
Booch, Ivar Jacobson and James Rumbaugh at Rational
Software in 1996.
6. In 2005 UML was also published by the International
Organization for Standardization (ISO) as an approved
ISO standard.
7. The UML standard is being periodically revised

UML Diagram Types

UML diagrams represent two different views of a system model
i. Static (or structural) view: emphasizes the static
structure of the system using objects, attributes,
operations and relationships. It includes class diagrams
and composite structure diagrams.
ii. Dynamic (or behavioral) view: emphasizes the dynamic
behavior of the system by showing collaborations among
objects and changes to the internal states of objects.
This view includes sequence diagrams, activity diagrams
and state machine diagrams.

Page 41
Universal Modeling Language
In building a visual model of a system, many different
diagrams are needed to represent different views of the
system. The UML provides a rich notation for visualizing our
models. This includes the following key diagrams:
1. Use Case diagrams to illustrate user interactions with
the system.
2. Class diagrams to illustrate logical structure.
3. Object diagrams to illustrate objects and links.
4. State diagrams to illustrate behavior.
5. Component diagrams to illustrate physical structure of
the software.
6. Deployment diagrams to show the mapping of software
to hardware configurations.
7. Interaction diagrams (i.e., collaboration and sequence
diagrams) to illustrate behavior.
8. Activity diagrams to illustrate the flow of events in a use
case.

Fig 1.2 UML Diagrams

Page 42
 Fig 1.3 : UML Diagrams at different stages
of SDLC

System Model Representation

1. Context models
2. Interaction models
3. Structural models
4. Behavioral models
5. Model-driven engineering

Context Models
• A context model is a model that shows how a system fit
into the context of the environment.
• Shows the scope and boundaries of a system at a glance
including the other systems that interface with it
• No technical knowledge is assumed or required to
understand the diagram
• Easy to draw and amend due to its limited notation
• Easy to expand by adding related systems

Page 43
 • Can benefit a wide audience including stakeholders,
business analyst, data analysts, developers
• Context models provide an overview (abstraction) of an
entire system, and shows the most important aspects.
• Details are not included.
• Context models are most useful in the requirements
analysis and design stages.
• A context model is a model that shows how a system fit
into the context of the environment.
• Context models provide an overview (abstraction) of an
entire system, and shows the most important aspects.
• Details are not included.
• Context models are most useful in the requirements
analysis and design stages.

Fig 1.4 Context Model of an ATM showing the

external perspective

Process Models
• Context models simply show the other systems in the
environment, NOT how the system being developed is
used in that environment.
• Process models reveal how the system being developed is
used in broader business processes.
• UML activity diagrams may be used to define business
process models.

Page 44
Activity Diagrams
Activity diagrams are intended to show the activities
that make up a system process and the flow of control
from one activity to another.
▪ The start of a process is indicated by a filled circle;
the end by a filled circle inside another circle.
▪ Rectangles with round corners represent activities,
which are subprocesses that must be carried out.
▪ A solid bar is used to indicate activity
coordination.
When the flow from more than one activity leads to a solid bar
then all of these activities must be complete before progress is
possible.
When the flow from a solid bar leads to a number of activities,
these may be executed in parallel. Arrows may be annotated
with guards that indicate the condition when that flow is
taken.

Fig 1.5 Activity Diagram of a Library

Page 45
Interaction Models
• Interaction Models help to identify user requirements.
• Interaction Modeling helps to understand the
communication process between system-to-system
interaction
• Modeling system interaction helps us understand and
improve the system performance and dependability.
• Use case diagrams and sequence diagrams may be used
for interaction modelling.
Use Case Modeling

“A use case specifies the behavior of a system or a part of a

system, and is a description of a set of sequences of actions,
including variants, that a system performs to yield an
observable result of value to an actor.”
- The UML User Guide, [Booch,99]
“An actor is an idealization of an external person, process, or
thing interacting with a system, subsystem, or class. An actor
characterizes the interactions that outside users may have
with the system.”
- The UML Reference Manual, [Rumbaugh,99]

• Use cases were developed originally to support

requirements elicitation and now incorporated into the
UML.
• Each use case represents a discrete task that involves
external interaction with a system.
• Actors in a use case may be people or other systems.
• Represented diagrammatically to provide an overview of
the use case and in a more detailed textual form.
• An actor is a direct external user of a system
• An object or a set of objects that communicates directly
with the system but that is not part of the system

Page 46
• Modelling the actors helps to define a system by
identifying the objects within the system and those on its
boundary
• An actor is directly connected to the system
• An indirectly connected object is not an actor and
should not be included as part of the system model
• Any interaction with an indirectly connected object must
pass through actors Examples
• Customer and Repair Technician are actors of a vending
machine
• Traveler, Agent and Airline are actors of a travel agency
system
• User and Administrator are actors for a computer
database system
• Actors can be persons, devices and other systems
(anything that interacts directly with the system)
• the Dispatcher of repair technicians from a service
bureau is not an actor of a vending machine

• UML has a graphical notation for

• summarizing use cases into use case
diagrams
• A rectangle contains the use cases for
a system with the actors listed on the
outside
• The name of the system is written
near a side of the rectangle
• A name within an ellipse denotes a
usecase
• A “stick man” icon denotes an actor
with the name placed below the icon
• Solid

lines
connect
use

Page 47
 cases
to participating actors

Sequence Models
Sequence models show the sequence of object
interactions that take place between the actors and the
objects within a system
Sequence diagrams are part of the UML and are used
to represent the sequence model.
• The objects and actors involved are listed along the top
of the diagram, with a dotted line drawn vertically from
these.
• Time is represented vertically so models are read top to
bottom
• Interactions are represented by labelled arrows, Different
styles of arrow represent different types of interaction
• A thin rectangle in an object lifeline represents the time
when the object is the controlling object in the system
Drawing Sequence Diagrams
i. Determine the context of the sequence diagram ii.
Identify the object that are participate in the
sequence iii. Set of the lifeline for each object iv. Lay
out of messages from the top to the bottom of the
diagram based on the order in which they sent
v. Add the execution occurrence
to each object‟s lifeline vi. Validate the
sequence diagram
Sequence Diagram of a Patient Information System

Page 48
Structural Models
Structural models show the organization of a system
in terms of the components that make up that system and
their relationships. Structural models may be
• Static models, which show the structure of the
system design, or
• Dynamic models, which show the organization of
the system when it is executing.
Structural models are created during discussion and
designing the system architecture

Class Diagrams
Class diagrams are used when developing an object-oriented
system model to show the classes in a system and the
associations between these classes.
An object class can be thought of as a general definition of one
kind of system object. An association is a link between classes
that indicates that there is some relationship between these
classes.

Page 49
When you are developing models during the early stages of the
software engineering process, objects represent something in
the real world, such as a patient, a prescription, doctor, etc.
UML Classes and Associations

Generalizations
Complexity is managed by Generalization Technique.
Instead of detailed characteristics of every event that
we experience, we generalise these experiences into general
classes (animals, cars, houses, etc.) and learn the
characteristics of these classes.
As different members of these classes have some
common characteristics (e.g. squirrels and rats are
rodents), it will be easier to understand (and design) similar
events by co-relating the events and rebuilding the
scenario.
In modeling systems, one of the common technique is
to identify the features of classes with scope for
generalization. If changes are proposed, then there will be
no need to look at all classes in the system to see if they are

Page 50
affected by the change. In object-oriented languages, such
as Java, generalization is implemented using the class
inheritance mechanisms built into the language.
In a generalization, the attributes and operations
associated with higher-level classes are also associated with
the lower-level classes.
The lower-level classes are subclasses and inherit the
attributes and operations from their superclasses. These
lower-level classes then add more specific attributes and
operations.
A Generalization Heirarchy

Page 51
 Object Class Aggregation Models

Behavioral Models
Behavioral models are models of the dynamic behavior of a
system as it is executing. They show what happens or what
is supposed to happen when a system responds to a
stimulus from its environment.
These stimuli may be of two types:
i. Data Some data arrives that has to be processed by
the system, (Data Driven) ii. Events Some event happens
that triggers system processing. Events may have
associated data, although this is not always the case.
(Event Driven)
Data Driven Modeling
Many business systems are data-processing systems that
are primarily driven by data. They are controlled by the
data input to the system, with relatively little external event
processing.
Data-driven models show the sequence of actions
involved in processing input data and generating an
associated output.
They are particularly useful during the analysis of
requirements as they can be used to show end-to-end
processing in a system.

Page 52
 Data Flow Modeling
Data-flow models are used to show how data flows
through a sequence of processing steps. For example, a
processing step could be to filter duplicate records in a
customer database.
The data is transformed at each step before moving on
to the next stage.
These processing steps or transformations represent
software processes or functions when data-flow diagrams
are used to document a software design.
They are simple and intuitive

Fig Order Processing Sequence Diagram

Page 53
 Fig Order Processing Sequence Diagram

Event-driven Modeling
Real-time systems are often event-driven, with
minimal data processing. For example, a landline phone
switching system responds to events such as „receiver off
hook‟ by generating a dial tone.
Event-driven modeling shows how a system responds to external
and internal events.
It is based on the assumption that a system has a
finite number of states and that events (stimuli) may cause
a transition from one state to another.

State Machine Models

These model the behaviour of the system in response
to external and internal events.
They show the system‟s responses to stimuli so are
often used for modelling real-time systems.
State machine models show system states as nodes and
events as arcs between these nodes. When an event occurs,
the system moves from one state to another. Statecharts
are an integral part of the UML and are used to represent
state machine models.

Page 54
 Microwave Oven Operation

State Diagram of a Microwave Oven

States And Stimuli For The Microwave Oven

State Description

Page 55
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows „Half power‟.
Full power The oven power is set to 600 watts. The display shows „Full power‟.
Set time The cooking time is set to the user‟s input value. The display shows
the cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on.
Display shows „Not ready‟.
Enabled Oven operation is enabled. Interior oven light is off. Display shows
„Ready to cook‟.
Operation Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for five
seconds. Oven light is on.
Display shows „Cooking complete‟ while buzzer is sounding.

Model-driven Engineering
Model-driven engineering (MDE) is an approach to software
development where models rather than programs are the
principal outputs of the development process. The
programs that execute on a hardware/software platform
are then generated automatically from the models.
Proponents of MDE argue that this raises the level of
abstraction in software engineering so that engineers no
longer have to be concerned with programming language
details or the specifics of execution platforms.
Model Driven Architecture
Model-driven engineering is still at an early stage of
development, and it is unclear whether or not it will have a
significant effect on software engineering practice. Pros
▪ Allows systems to be considered at higher levels of
abstraction
▪ Generating code automatically means that it is
cheaper to adapt systems to new platforms.
Cons

Page 56
 ▪ Models for abstraction and not necessarily right for
implementation.
▪ Savings from generating code may be outweighed by
the costs of developing translators for new platforms.
Types of Models
A computation independent model (CIM)
These model the important domain abstractions
used in a system. CIMs are sometimes called domain
models.
A platform independent model (PIM)
These model the operation of the system without
reference to its implementation. The PIM is usually
described using UML models that show the static
system structure and how it responds to external and
internal events.
Platform specific models (PSM)
These are transformations of the platform-independent
model with a separate PSM for each application platform. In
principle, there may be layers of PSM, with each layer
adding some platform-specific detail.
MDA Transformations

Page 57
 MDA Platform Specific Models

Agile Methods and MDA

The developers of MDA claim that it is intended to
support an iterative approach to development and so can be
used within agile methods.
The notion of extensive up-front modeling contradicts the
fundamental ideas in the agile manifesto and I suspect that
few agile developers feel comfortable with modeldriven
engineering.
If transformations can be completely automated and a
complete program generated from a PIM, then, in principle,
MDA could be used in an agile development process as no
separate coding would be required.
Executible UML
The fundamental notion behind model-driven
engineering is that completely automated transformation of
models to code should be possible.
This is possible using a subset of UML 2, called
Executable UML or xUML.
Features of Executible UML
To create an executable subset of UML, the number of
model types has therefore been dramatically reduced to
these 3 key types:

Page 58
 Domain models that identify the principal concerns
in a system. They are defined using UML class
diagrams and include objects, attributes and
associations.
Class models in which classes are defined, along
with their attributes and operations.
State models in which a state diagram is
associated with each class and is used to describe the
life cycle of the class.
The dynamic behavior of the system may be specified
declaratively using the object constraint language (OCL), or
may be expressed using UML‟s action language.

Design and Implementation

Introduction
In software engineering the goal is to build a software product
or to enhance an existing one
Designing
software is a
process An
effective process
• Provides guidelines for efficient development of quality
software
• Reduces risk and increases predictability  Captures and
presents best practices
⮚ Learn from experiences
⮚ Mentor for New Recruits
⮚ Extension of training material
• Promotes common vision and culture
• Enables applying tools
• Provides efficient information exchange,

Page 59
 Rational Unified Process (RUP)
The Rational Unified Process (RUP) (Krutchen, 2003) is an
adaptable process model that has been derived from work on
the UML and the associated Unified Software Development
Process.
It brings together elements from all of the generic software
development process models RUP enforces good practice in
specification and design and supports prototyping and
incremental delivery.
The RUP recognizes that conventional process models present
a single view of the process. In contrast, the RUP is normally
described from three perspectives:
1. A dynamic perspective, which shows the phases of the
model over time.
2. A static perspective, which shows the process activities
that are enacted.
3. A practice perspective, which suggests good practices to
be used during the process.
Most descriptions of the RUP attempt to combine the static
and dynamic perspectives in a single diagram. I think that
makes the process harder to understand, so I use separate
descriptions of each of these perspectives.
Dynamic perspective
The RUP is a phased model that identifies four discrete phases
in the software process. However, unlike the waterfall model
where phases are equated with process activities, the phases
in the RUP are more closely related to business rather than
technical concerns.

Page 60
It is a software engineering process, aimed at guiding software
development organizations in their endeavors to develop
effective software efficiently
The practice perspective on the RUP describes good software
engineering practices that are recommended for use in
systems development. Six fundamental best practices are
recommended:
1. Develop software iteratively : Plan increments of the
system based on customer priorities and develop the
highest priority system features early in the development
process.
2. Manage requirements : Explicitly document the
customer‟s requirements and keep track of changes to
these requirements. Analyse the impact of changes on
the system before accepting them.
3. Use component-based architectures : Structure the
system architecture into components, as discussed
earlier in this chapter.
4. Visually model software : Use graphical UML models to
present static and dynamic views of the software.
5. Verify software quality. : Ensure that the software
meets the organizational quality standards.
6. Control changes to software. : Manage changes to the
software using a change management system and
configuration management procedures and tools.

Page 61
 The RUP may not be a suitable process for all types of
development e.g. embedded software development. However,
it does represent an approach that potentially combines the
three generic process models discussed in section 2.1. The
most important innovations in the RUP are the separation
of phases and workflows, and the
recognition that deploying software in a user‟s environment
is part of the process. Phases are dynamic and have goals.
Workflows are static and are technical activities that are not
associated with a single phase but may be used throughout
the development to achieve the goals of each phase.

Design and Implementation

Software design and implementation is the stage in the
software engineering process at which an executable
software system is developed.
Software design and implementation activities are
invariably inter-leaved. Software design is a creative
activity to identify software components and their
relationships, based on a customer‟s requirements.
Implementation is the process of realizing the design
as a program.
Build or Buy
In a wide range of domains, it is now possible to buy
off-the-shelf systems (COTS) that can be adapted and
tailored to the users‟ requirements.
For example, if you want to implement a medical records
system, you can buy a package that is already used in
hospitals. It can be cheaper and faster to use this approach
rather than developing a system in a conventional
programming language.
When you develop an application in this way, the design
process becomes concerned with how to use the

Page 62
configuration features of that system to deliver the system
requirements.
System Context And Interactions
Understanding the relationships between the software that
is being designed and its external environment is essential
for deciding how to provide the required system
functionality and how to structure the system to
communicate with its environment. Understanding of the
context also lets the developer establish the boundaries of
the system. Setting the system boundaries helps designor
decide what features are implemented in the system being
designed and what features are in other associated
systems.
Context and Interaction Models
A system context model is a structural model that
demonstrates the other systems in the environment of the
system being developed.
An interaction model is a dynamic model that shows
how the system interacts with its environment as it is used.
Architectural Design
Once interactions between the system and its
environment have been understood, we use this information
for designing the system architecture.
we identify the major components that make up the system
and their interactions, and then may organize the
components using an architectural pattern such as a
layered or client-server model.
The weather station is composed of independent
subsystems that communicate by broadcasting messages
on a common infrastructure.

Page 63
 The Object Model
A general view of program structure shared by
UML and object-oriented programming
languages like Java and C++ Computation takes
place in objects that:
store data and
implement behaviour
are linked together
in a network
communicate by
sending messages
are described by
classes
Object Oriented Design Process
There are a variety of different object-oriented design
processes that depend on the organization using the
process.
Common activities in these
processes include: Define the
context and modes of use of
the system;

Page 64
 Design the system architecture;
Identify the principal system objects;
Develop design models;
Specify object interfaces.
Process illustrated here using a design for a wilderness
weather station.
Approaches to Object Identification
Use a grammatical approach based on a natural
language description of the system (used in Hood OOD
method).
Base the identification on tangible things in the
application domain.
Use a behavioural approach and identify objects based
on what participates in what behaviour.
Use a scenario-based analysis. The objects, attributes
and methods in each scenario are identified.
Examples of Design Models
Sequence models that show the sequence of object
interactions.
State machine models that show how individual
objects change their state in response to events.
Other models include use-case models, aggregation
models, generalization models, etc.
Sub-system models show logical
groupings of objects into coherent
subsystems.
how the design is organized into logically related
groups of objects.
In the UML, these are shown using packages - an
encapsulation construct. This is a logical model. The actual
organization of objects in the system may be different.

Page 65
 Design Models and Code
UML is based on the same object model as
object-oriented programming languages

Example : Weather Station Information

Requirements: Use Case Diagram

Page 66
Collect weather information
from instruments at regular
intervals
Transmit this information, on
request, to the weather
information system over the
satellite link
Store information if
communications are not
available
Monitor external conditions
and shut down power
generation/instruments if
threat of

damage from extreme

weather

Run regular diagnostic tests

to assess overall health of
system
Context Model for weather station

Page 67
 Weather Station Class Models
WeatherS WeatherData
tation
identifier airTemperatures
groundTemperature
reportWeather s windSpeeds
() windDirections
calibrate pressures rainfall
(instruments)
test ()
startup collect ()
(instruments) summarise ()
shutdown
(instruments)

Groun Anemomet er Baromet

thermom er
er windSpeed pressure
temperature windDirection height
test ()
test ( test ()
calibrate () calibrate ()

Page 68
 Weather Station Subsystems

Design Patterns
A design pattern is a way of reusing abstract
knowledge about a problem and its solution.
A pattern is a description of the problem and the
essence of its solution.
It should be sufficiently abstract to be reused in
different settings.
Pattern descriptions usually make use of
object-oriented characteristics such as inheritance and
polymorphism.
A design pattern is a descriptions of communicating
objects and classes that are customized to solve a general
design problem in a particular context
Design patterns represent the best practices used by
experienced object-oriented software developers.
Design patterns are solutions to general problems that
software developers faced during software development.

Page 69
 These solutions were obtained by trial and error by
numerous software developers over quite a substantial
period of time.
Design patterns are optimized, reusable solutions to
the programming problems that we encounter every day.
A design pattern is not a class or a library that we can
simply plug into our system; It is a template that has to be
implemented in the correct situation.
It's not language-specific.
A good design pattern should be implementable in
most programming languages, depending on the
capabilities of the language.
Any design pattern when correctly implemented , it can be a
Great Solution, However, if implemented in the wrong place,
it can be disastrous and create many problems.

Benefits of patterns
Design reuse
Uniform design vocabulary
Enhance understanding, restructuring, & team
communication
Basis for automation
Transcends language-centric biases/myopia
Abstracts away from many unimportant details
Patterns, Architectures and Frameworks
There can be confusion between patterns,
architectures and frameworks.
Let‟s try to distinguish them:
Architectures model software structure at the highest
possible level, and give the overall system view. An
architecture can use many different patterns in different
components

Page 70
 Patterns are more like small-scale or local
architectures for architectural components or
sub-components
Frameworks are partially completed software systems that
may be targeted at a particular type of application. These
are tailored by completing the unfinished components.
Pattern Elements
Name : A meaningful pattern identifier.
Problem description : Explains the problem and its
context
Solution description : Not a concrete design but a
template for a design solution that can be instantiated in
different ways.
Consequences : The results and trade-offs of applying
the pattern

Types of Design Patterns

There are 3 types of pattern …

Creational: address problems of creating an object in a flexible
way. Separate creation, from operation/use.
Structural: These design patterns concern class and object
composition. Concept of inheritance is used to compose
interfaces and define ways to compose objects to obtain new
functionalities.
Behavioral: These design patterns are specifically concerned
with communication between objects. Patternsaddress
problems of assigning responsibilities to classes.
Suggest both static relationships and patterns of communication
(use cases)

Page 71
Creational Design Patterns

Creational patterns often used in place of direct instantiation with

constructors. They make the creation process more adaptable
and dynamic. In particular, they can provide a great deal of
flexibility about which objects are created, how those objects
are created, and how they are initialized.
Singleton

Page 72
When an application wants to have one and only one instance
of any class per JVM, in all possible scenarios without any
exceptional condition.
Factory
This is most suitable where there is some complex object
creation steps are involved. To ensure that these steps are
centralized and not exposed to composing classes, factory
pattern should be used.
Abstract factory
Whenever you need another level of abstraction over a group of
factories, you should consider using abstract factory pattern.
Structural Design Patterns
These design patterns show you how to glue different pieces of
a system together in a flexible and extensible fashion.
Structural patterns help you guarantee that when one of the
parts changes, the entire structure does not need to change.
Adapter
Convert the interface of a class into another interface clients
expect. Adapter lets classes work together that couldn‟t
otherwise because of incompatible interfaces.
Decorator
This is used to add additional features or behaviors to a
particular instance of a class, while not modifying the other
instances of same class.
Behavioral Design Patterns
A behavioral pattern abstracts an action you want to take from
the object or class that takes the action. By changing the object
or class, you can change the algorithm used, the objects
affected, or the behavior, while still retaining the same basic
interface for client classes.
Command
Command pattern is a behavioral design pattern which is
useful to abstract business logic into discrete actions which we

Page 73
call commands. This command object helps in loose coupling
between two classes where one class (invoker) shall call a
method on other class (receiver) to perform a business
operation.
Visitor
When you want a hierarchy of objects to modify their behavior
but without modifying their source code.
Memento
Memento design pattern provides ability to capture(save) an
object‟s state and then restore back this captured state when
required by the system.
State
State Design Pattern allows the behavior of an object to vary
based on its state. I.e.
whenever the object‟s state changes, its behavior changes as
per its new state. To the observer it appears as if the object has
changed its class.

Using Design Patterns

To use patterns in our design, we need to recognize
that any design problem may have an associated pattern
that can be applied.
Tell several objects that the state of some other object
has changed (Observer pattern).
Tidy up the interfaces to a number of related objects
that have often been developed incrementally (Façade
pattern).
Provide a standard way of accessing the elements in a
collection, irrespective of how that collection is implemented
(Iterator pattern).
Allow for the possibility of extending the functionality
of an existing class at run-time (Decorator pattern).

Page 74
 Some general guidelines for using design patterns are :
Is there a pattern that addresses my problem?
Does the pattern provide an acceptable solution?
Is there a simpler solution? (pattern overuse)
Is the context of the pattern consistent with my
problem?
Are the consequences of using the pattern
acceptable?
Are there forces in my environment that conflict with
the use of the pattern?
Software Implementation
Software Implementation is often the most important
step in the software process cycle. Some of the issues of
implementation are
Reuse Most modern software is constructed by reusing
existing components or systems. When you are
developing software, you should make as much use as
possible of existing code.
Configuration management During the development
process, you have to keep track of the many different
versions of each software component in a configuration
management system.
Host-target development Production software does not
usually execute on the same computer as the software
development environment. Rather, you develop it on one
computer (the host system) and execute it on a separate
computer (the target system).
Software Reuse
From the 1960s to the 1990s, most new software was
developed from scratch, by writing all code in a high-level
programming language.
The only significant reuse or software was the reuse
of functions and objects in programming language
libraries.

Page 75
 Costs and schedule pressure mean that this approach
became increasingly unviable, especially for commercial
and Internet-based systems.
An approach to development based around the reuse of
existing software emerged and is now generally used for
business and scientific software.
Reuse Level
The abstraction level : At this level, you don‟t reuse
software directly but use knowledge of successful
abstractions in the design of your software.
The object level : At this level, you directly reuse objects
from a library rather than writing the code yourself.
The component level : Components are collections of
objects and object classes that you reuse in application
systems.
The system level : At this level, you reuse entire
application systems
Reuse Costs
The costs of the time spent in looking for software to
reuse and assessing whether or not it meets your needs.
Where applicable, the costs of buying the reusable
software. For large off-the-shelf systems, these costs can be
very high.
The costs of adapting and configuring the reusable
software components or systems to reflect the requirements
of the system that you are developing.
The costs of integrating reusable software elements
with each other (if you are using software from different
sources) and with the new code that you have developed.
Configuration Management
Configuration management is the name given to the
general process of managing a changing software system.

Page 76
 The aim of configuration management is to support the
system integration process so that all developers can access
the project code and documents in a controlled way, find
out what changes have been made, and compile and link
components to create a system.
Version management : Versioning is the
mechanism to manage systems changes Complex
systems developed, installed, and maintained in series
of versions to simplify testing and support
Alpha version – incomplete testing version
Beta version – end-user testing version
Production release version – formally distributed to users or made
operational
Maintenance release – bug fixes, small changes
where support is provided to keep track of the
different versions of software components. Version
management systems include facilities to
coordinate development by several programmers.
System integration, where support is provided to help
developers define what versions of components are used to
create each version of a system. This description is then
used to build a system automatically by compiling and
linking the required components.
Problem tracking, where support is provided to allow users
to report bugs and other problems, and to allow all
developers to see who is working on these problems and
when they are fixed.
Host Target Development
Most software is developed on one computer (the host),
but runs on a separate machine (the target).
More generally, we can talk about a development platform
and an execution platform. A platform is more than just
hardware. It includes the installed operating system plus

Page 77
other supporting software such as a database management
system or, for development platforms, an interactive
development environment.
Development platform usually has different installed
software than execution platform; these platforms may have
different architectures.
Development Platform Tools
Some of the development platform tools are,
An integrated compiler and syntax-directed editing
system that allows you to create, edit and compile code.
A language debugging system.
Graphical editing tools, such as tools to edit UML
models.
Testing tools, such as Junit that can automatically run
a set of tests on a new version of a program.
Project support tools that help you organize the code
for different development projects.
Software development tools are often grouped to create
an integrated development environment (IDE).
An IDE is a set of software tools that supports different
aspects of software development, within some common
framework and user interface.
IDEs are created to support development in a specific
programming language such as Java. The language IDE
may be developed specially, or may be an instantiation of a
general-purpose IDE, with specific language-support tools
Deployment Factors
If a component is designed for a specific hardware
architecture, or relies on some other software system, it
must obviously be deployed on a platform that provides the
required hardware and software support.
High availability systems may require components to
be deployed on more than one platform. This means that, in

Page 78
the event of platform failure, an alternative implementation
of the component is available.
If there is a high level of communications traffic
between components, it usually makes sense to deploy
them on the same platform or on platforms that are
physically close to one other. This reduces the delay
between the time a message is sent by one component and
received by another
Open Source Development
If a component is designed for a specific hardware
architecture, or relies on some other software system, it
must obviously be deployed on a platform that provides the
required hardware and software support.
High availability systems may require components to
be deployed on more than one platform. This means that, in
the event of platform failure, an alternative implementation
of the component is available.
If there is a high level of communications traffic
between components, it usually makes sense to deploy
them on the same platform or on platforms that are
physically close to one other. This reduces the delay
between the time a message is sent by one component and
received by another
The best-known open source product is, of course, the
Linux operating system which is widely used as a server
system and, increasingly, as a desktop environment. Other
important open source products are Java, the Apache web
server and the mySQL database management system
Open Source Issues
Should the product that is being developed make use
of open source components?
Should an open source approach be used for the
software‟s development?

Page 79
 More and more product companies are using an open
source approach to development.
Their business model is not reliant on selling a
software product but on selling support for that product.
They believe that involving the open source community
will allow software to be developed more cheaply, more
quickly and will create a community of users for the
software.
Open Source Licensing
A fundamental principle of open-source development is
that source code should be freely available, this does not
mean that anyone can do as they wish with that code.
Legally, the developer of the code (either a company or an
individual) still owns the code. They can place restrictions
on how it is used by including legally binding conditions in
an open source software license.
Some open source developers believe that if an open
source component is used to develop a new system, then
that system should also be open source.
Others are willing to allow their code to be used
without this restriction. The developed systems may be
proprietary and sold as closed source systems.
The GNU General Public License (GPL). This is a
so-called „reciprocal‟ license that means that if you use
open source software that is licensed under the GPL
license, then you must make that software open source.
The GNU Lesser General Public License (LGPL) is a
variant of the GPL license where you can write components
that link to open source code without having to publish the
source of these components.
The Berkley Standard Distribution (BSD) License. This
is a non-reciprocal license, which means you are not

Page 80
 obliged to re-publish any changes or modifications made to
open source code. You can include the code in proprietary
systems that are sold.
License Management
• Establish a system for maintaining information about
open-source components that are downloaded and used.
• Be aware of the different types of licenses and
understand how a component is licensed before it is
used.
• Be aware of evolution pathways for components.
• Educate people about open source.
• Have auditing systems in place.
• Participate in the open source community.
Implementation Process
The process of software implementation consists of the
following steps
1. Acquisition
2. Development
3. Testing
4. Documentation
5. Software versioning
6. Data porting and conversion
7. System deployment
8. Training
9. Maintenance

Acquisition refers to the decision of either build or buy

the software after due diligence

Program development is time consuming. It may

account for as much as one-third of development labor.
One-third to one-half of project development schedule

Page 81
Quality assurance is the process of Process of ensuring
information system meets minimum quality standards as
Determined by users, implementation staff, and
management. It also involves Identification of gaps or
inconsistencies in system requirements. QA integrated into
project throughout SDLC and the Cost of fixing errors rise
as project progresses

System testing involves testing hardware devices,

testing and debugging computer programs, and testing
information processing procedures.
An important part of testing is the production of
prototypes of displays, reports, and other output.
It is important to involve end users in the testing stage
to recognize errors, and to provide feedback.

Software Implementation consists of smooth transition from

old system to New System. This involves porting old data to
new system or converting old data format to new formats.
Major forms of conversion are
Parallel: both old and new systems are operated until IS
team and management agrees to convert
Pilot: one department or work site serves as a tester.
Phased: only parts of the new system or only a few
departments, offices, or plant locations at a time are
converted
Plunge: direct abandonment of old system and
conversion to new system.

Data Conversion : Data needed at system startup

Files or databases of system being replaced
Manual records
Files or databases of other systems

Page 82
 User feedback during normal system operation
Reuse of existing databases
Reloading database contents
Creating new databases

Installation
After development and testing, system must be put into
operation. New system can be installed and quickly made
operational, However, in case of enhancement or defect
removal, the following points need to be taken care of
Overlapping systems turned off
Both systems concurrent for brief time
Advantage – simplicity and fewer logistics issues to
manage
Disadvantage – risk due to no backup
Important planning considerations include
Costs of operating both systems in parallel,
Detecting and correcting errors in new system,
Potentially disrupting the company and IS
operations
Training personnel and customers with new
procedures

System Documentation
One of the most important aspect of the project is
documentation. In fact, the success of a project depends
entirely on the quality of documentation. The documentation
should cover but not limited to
Descriptions of system functions, architecture, and
construction details
User manuals for maintenance personnel and future
developers
Source code, Analysis and design models, Operational
details (System Manual) as applicable

Page 83
 Failure to maintain system documentation
compromises value of a system

User Documentation
Special attention should be paid for user
documentation which will be used by Used by end users
and system operators. It should include the details about

Descriptions of how to interact with and maintain

the system
Startup and shutdown
Keystrokes, mouse, or command functions to
perform specific functions
Program function for specific business procedures
Common errors and correction techniques

Page 84
 Module 3: Agile Software Development
The Agile Manifesto: Values and
Principles
Module – 3
Chapter 1: Software Testing

Introduction:-
• Testing is intended to show that a program does what it is intended to
do and to discover program defects before it is put into use.
• The testing process has two distinct goals:
1. To demonstrate to the developer and the customer that the software
meets its requirements.
For custom software, this means that there should be at least one
test for every requirement in the requirements document.
For generic software products, it means that there should be tests
for all of the system features, plus combinations of these features,
that will be incorporated in the product release.
2. To discover situations in which the behavior of the software is
incorrect, undesirable, or does not conform to its specification. Defect
testing is concerned with rooting out undesirable system behavior
such as system crashes, unwanted interactions with other systems,
incorrect computations, and data corruption.
The diagram shown in Figure 3.1 explains the differences between
validation testing and defect testing. Think of the system being tested as a
black box. The system accepts inputs from some input set I and generates
outputs in an output set O. Some of the outputs will be erroneous. These are
the outputs in set Oe that are generated by the system in response to inputs

Page 85
in the set Ie. The priority in defect testing is to find those inputs in the set Ie
because these reveal problems with the system. Validation testing involves
testing with correct inputs that are outside Ie. These stimulate the system to
generate the expected correct outputs.

3.1 Development
Testing
• Development testing includes all testing activities that are carried out by
the team developing the system.
• During development, testing may be carried out at three levels of
granularity:
1. Unit testing, where individual program units or object classes are
tested. Unit testing should focus on testing the functionality of objects
or methods.
2. Component testing, where several individual units are integrated to
create composite components. Component testing should focus on
testing component interfaces.
3. System testing, where some or all of the components in a system are
integrated and the system is tested as a whole. System testing should
focus on testing component interactions.
• Development testing is primarily a defect testing process, where
the aim of testing is to discover bugs in the software. It is therefore

Page 86
 usually interleaved with debugging— the process of locating problems
with the code and changing the program to fix these problems.

3.1.1 Unit Testing

• Unit testing is the process of testing program components, such as
methods or object classes. Individual functions or methods are the
simplest type of component.
• Your tests should be calls to these routines with different input
parameters. This approach can be used to design the function or
method tests.
• When you are testing object classes, you should design your tests to
provide coverage of all of the features of the object. This means that you
should:
• test all operations associated with the object;
• set and check the value of all attributes associated with the object;
• put the object into all possible states. This means that you should
simulate all events that cause a state change.
• Units may be:
▪ Individual functions or methods within an object
▪ Object classes with several attributes and methods
▪ Composite components with defined interfaces used to access
their functionality.

The weather station object Interface:-

Page 87
 • To test the states of the weather station, we use a state model. Using
this model, you can identify sequences of state transitions that have to
be tested and define event sequences to force these transitions.
• In principle, you should test every possible state transition sequence,
although in practice this may be too expensive.
• Examples of state sequences that should be tested in the weather
station include: o Shutdown _ Running _ Shutdown o Configuring _
Running _ Testing _ Transmitting _ Running o Running _ Collecting _
Running _ Summarizing _ Transmitting _ Running
Automated Testing
• Whenever possible, unit testing should be automated so that tests are
run and checked without manual intervention.
• In automated unit testing, you make use of a test automation
framework (such as JUnit) to write and run your program tests.
• Unit testing frameworks provide generic test classes that you extend to
create specific test cases. They can then run all of the tests that you
have implemented and report, often through some GUI, on the success
of otherwise of the tests.
• An automated test has three parts:
1. A setup part, where you initialize the system with the test case,
namely the inputs and expected outputs.
2. A call part, where you call the object or method to be tested.
3. An assertion part where you compare the result of the call with
the expected result. If the assertion evaluates to true, the test has
been successful; if false,then it has failed.

3.1.2 Choosing Unit-test cases.

• The test cases should show that, when used as expected, the
component that you are testing does what it is supposed to do.
• If there are defects in the component, these should be revealed by test
cases.
• This leads to 2 types of unit test case:

Page 88
 o The first of these should reflect normal operation of a program
and should show that the component works as expected.
o The other kind of test case should be based on testing experience
of where common problems arise. It should use abnormal inputs
to check that these are properly processed and do not crash the
component.
• The Two possible strategies here that can be effective in helping you
choose test cases. These are:
1. Partition testing, where you identify groups of inputs that have
common characteristics and should be processed in the same way.
You should choose tests from within each of these groups.
2. Guideline-based testing, where you use testing guidelines to
choose test cases. These guidelines reflect previous experience of
the kinds of errors that programmers often make when developing
components.

Equivalence-Class Partitioning
• The input data and output results of a program often fall into a number
of different classes with common characteristics.
• Examples of these classes are positive numbers, negative numbers, and
menu selections.
• Programs normally behave in a comparable way for all members of a
class. That is, if you test a program that does a computation and
requires two positive numbers, then you would expect the program to
behave in the same way for all positive numbers.
• Because of this equivalent behavior, these classes are sometimes called
equivalence partitions or domains (Bezier, 1990).
• In Figure 3.2, the large shaded ellipse on the left represents the set of
all possible inputs to the program that is being tested.
• The smaller unshaded ellipses represent equivalence partitions.

Page 89
 Fig 3.2:
Equivalence
Partitioning
• A program being tested should process all of the members of an input
equivalence partitions in the same way.
• Output equivalence partitions are partitions within which all of the
outputs have something in common.
• The shaded area in the left ellipse represents inputs that are invalid.
The shaded area in the right ellipse represents exceptions that may
occur (i.e., responses to invalid inputs).
• Once you have identified a set of partitions, you choose test cases from
each of these partitions.
• A good rule of thumb for test case selection is to choose test cases on
the boundaries of the partitions, plus cases close to the midpoint of the
partition. The reason for this is that designers and programmers tend
to consider typical values of inputs when developing a system.
• For example, say a program specification states that the program
accepts 4 to 8 inputs which are five-digit integers greater than 10,000.
You use this information to identify the input partitions and possible
test input values. These are shown in Figure 3.3

Page 90
 Fig 3.3: Equivalence
Partitions
Testing Guidelines (Sequences)
• Test software with sequences which have only a single value.
• Use sequences of different sizes in different tests.
• Derive tests so that the first, middle and last elements of the
sequence are accessed.
• Test with sequences of zero length. General Testing Guidelines:-
• Choose inputs that force the system to generate all error
messages
• Design inputs that cause input buffers to overflow
• Repeat the same input or series of inputs numerous times
• Force invalid outputs to be generated
• Force computation results to be too large or too small.

3.1.3 Component Testing

✧ Software components are often composite components that are made up
of several interacting objects.
▪ For example, in the weather station system, the reconfiguration
component includes objects that deal with each aspect of the
reconfiguration.
✧ You access the functionality of these objects through the defined
component interface.

Page 91
 ✧ Testing composite components should therefore focus on showing that
the component interface behaves according to its specification.
▪ You can assume that unit tests on the individual objects within
the component have been completed.
✧ Figure 3.4 illustrates the idea of component interface testing. Assume
that components A, B, and C have been integrated to create a larger
component or subsystem.

Fig 3.4: Interface

✧
Testing
The test cases are not applied to the individual components but rather
to the interface of the composite component created by combining
these components.
✧ Interface errors in the composite component may not be detectable by
testing the individual objects because these errors result from
interactions between the objects in the component.

Interface Types:
There are different types of interface between program components and,
consequently, different types of interface error that can occur:
1. Parameter interfaces: These are interfaces in which data or
sometimes function references are passed from one component to another.
Methods in an object have a parameter interface.

Page 92
2. Shared memory interfaces: These are interfaces in which a block of
memory is shared between components. Data is placed in the memory by
one subsystem and retrieved from there by other sub-systems. This type of
interface is often used in embedded systems, where sensors create data that
is retrieved and processed by other system components.
3. Procedural interfaces: These are interfaces in which one component
encapsulates a set of procedures that can be called by other components.
Objects and reusable components have this form of interface.
4. Message passing interfaces These are interfaces in which one
component requests a service from another component by passing a
message to it. A return message includes the results of executing the
service. Some object-oriented systems have this form of interface, as do
client–server systems.

Interface errors:
These errors fall into three classes:
1. Interface misuse:-A calling component calls some other component
and makes an error in the use of its interface. This type of error is
common with parameter interfaces where parameters may be of the
wrong type or be passed in the wrong order, or the wrong number of
parameters may be passed.
2. Interface misunderstanding: - A calling component misunderstands
the specification of the interface of the called component and makes
assumptions about its behavior. The called component does not
behave as expected which then causes unexpected behavior in the
calling component.
For example, a binary search method may be called with a parameter
that is an unordered array. The search would then fail.
3. Timing errors These occur in real-time systems that use a shared
memory or a message-passing interface. The producer of data and the
consumer of data may operate at different speeds. Unless particular
care is taken in the interface design, the consumer can access

Page 93
 out-of-date information because the producer of the information has
not updated the shared interface information.

Some general guidelines for interface testing are:

1. Examine the code to be tested and explicitly list each call to an
external component. Design a set of tests in which the values of the
parameters to the external components are at the extreme ends of their
ranges. These extreme values are most likely to reveal interface
inconsistencies.
2. Where pointers are passed across an interface, always test the
interface with null pointer parameters.
3. Where a component is called through a procedural interface, design
tests that deliberately cause the component to fail. Differing failure
assumptions are one of the most common specification misunderstandings.
4. Use stress testing in message passing systems. This means that you
should design tests that generate many more messages than are likely to
occur in practice. This is an effective way of revealing timing problems.
5. Where several components interact through shared memory, design
tests that vary the order in which these components are activated. These
tests may reveal implicit assumptions made by the programmer about the
order in which the shared data is produced and consumed.

3.1.4 System Testing:

✧ System testing during development involves integrating components to
create a version of the system and then testing the integrated system.
✧ System testing checks that components are compatible, interact
correctly and transfer the right data at the right time across their
interfaces. It obviously overlaps with component testing but there are
two important differences:
1. During system testing, reusable components that have been separately
developed and off-the-shelf systems may be integrated with newly
developed components. The complete system is then tested.

Page 94
 2. Components developed by different team members or groups may be
integrated at this stage. System testing is a collective rather than an
individual process.

Wilderness weather station system:

• The weather station is asked to report summarized weather data
to a remote computer. The Figure 3.5 shows the sequence of operations
in the weather station when it responds to a request to collect data for
the mapping system.

Fig 3.5: Collect

weather data
sequence chart
• You can use this diagram to identify operations that will be tested and to
help design the test cases to execute the tests. Therefore, issuing a
request for a report will result in the execution of the following thread of
methods:

Page 95
SatComms:request _ WeatherStation:reportWeather _
Commslink:Get(summary) _ WeatherData:summarize

• The sequence diagram helps you design the specific test cases that you
need as it shows what inputs are required and what outputs are created:
1. An input of a request for a report should have an associated
acknowledgment. A report should ultimately be returned from the request.
During testing, you should create summarized data that can be used to
check that the report is correctly organized.
2. An input request for a report to WeatherStation results in a
summarized report being generated. You can test this in isolation by creating
raw data corresponding to the summary

Page 96
that you have prepared for the test of SatComms and checking that the
WeatherStation object correctly produces this summary. This raw data is
also used to test the WeatherData object.
• For most systems, it is difficult to know how much system testing is
essential and when you should to stop testing.
• Exhaustive testing, where every possible program execution
sequence is tested, is impossible. Testing, therefore, has to be based
on a subset of possible test cases.
For example:
1. All system functions that are accessed through menus should
be tested.
2. Combinations of functions (e.g., text formatting) that are
accessed through the same menu must be tested.
3. Where user input is provided, all functions must be tested with
both correct and incorrect input.
• Automated system testing is usually more difficult than automated
unit or component testing. Automated unit testing relies on predicting
the outputs then encoding these predictions in a program. The
prediction is then compared with the result.

3.2 Test-driven development

• Test-driven development (TDD) is an approach to program
development in which you interleave testing and code development
(Beck, 2002; Jeffries and Melnik, 2007).
• Essentially, you develop the code incrementally, along with a test for
that increment.
You don’t move on to the next increment until the code that you have
developed passes its test.
• The fundamental TDD process is shown in Figure 3.6.

Page 97
 Fig 3.6: Test-Driven
Development
• The steps/activities in the process are as follows:
1. You start by identifying the increment of functionality that is required.
This should normally be small and implementable in a few lines of code.
2. You write a test for this functionality and implement this as an
automated test. This means that the test can be executed and will report
whether or not it has passed or failed.
3. You then run the test, along with all other tests that have been
implemented. Initially, you have not implemented the functionality so the
new test will fail. This is deliberate as it shows that the test adds something
to the test set.
4. You then implement the functionality and re-run the test. This may
involve refactoring existing code to improve it and add new code to what’s
already there.
5. Once all tests run successfully, you move on to implementing the next
chunk of functionality.

• An automated testing environment, such as the JUnit environment

that supports Java program testing (Massol and Husted, 2003), is
essential for TDD.

Page 98
 • As the code is developed in very small increments, you have to be able
to run every test each time that you add functionality or refactor the
program. Therefore, the tests are embedded in a separate program
that runs the tests and invokes the system that is being tested.
• A strong argument for test-driven development is that it helps
programmers clarify their ideas of what a code segment is actually
supposed to do.
• For example, if your computation involves division, you should check
that you are not dividing the numbers by zero. If you forget to write a
test for this, then the code to check will never be included in the
program.

Benefits of test-driven development are:

1. Code coverage: - In principle, every code segment that
you write should have at least one associated test. Therefore, you
can be confident that all of the code in the system has actually
been executed. Code is tested as it is written so defects are
discovered early in the development process.
2. Regression testing: - A test suite is developed
incrementally as a program is developed. You can always run
regression tests to check that changes to the program have not
introduced new bugs.
3. Simplified debugging:- When a test fails, it should be
obvious where the problem lies. The newly written code needs to be
checked and modified. You do not need to use debugging tools to
locate the problem.
4. System documentation: - The tests themselves act as a
form of documentation that describe what the code should be
doing. Reading the tests can make it easier to understand the code.
• One of the most important benefits of test-driven development is
that it reduces the costs of regression testing. Regression testing

Page 99
 involves running test sets that have successfully executed after
changes have been made to a system.
• The regression test checks that these changes have not introduced
new bugs into the system and that the new code interacts as expected
with the existing code.
• Regression testing is very expensive and often impractical when a
system is manually tested, as the costs in time and effort are very
high.
• Test-driven development is of most use in new software development
where the functionality is either implemented in new code or by using
well-tested standard libraries.
• Test-driven development has proved to be a successful approach for
small and medium-sized projects. Generally, programmers who have
adopted this approach are happy with it and find it a more productive
way to develop software (Jeffries and Melnik, 2007).
.
3.3 Release testing
• Release testing is the process of testing a particular release of a
system that is intended for use outside of the development team.
• Normally, the system release is for customers and users. In a complex
project, however, the release could be for other teams that are
developing related systems.
• For software products, the release could be for product management
who then prepare it for sale.
There are two important distinctions between release testing and
system testing during the development process:

1. A separate team that has not been involved in the system development
should be responsible for release testing.
2. System testing by the development team should focus on discovering
bugs in the system (defect testing). The objective of release testing is to

Page 100
check that the system meets its requirements and is good enough for
external use (validation testing).
• The primary goal of the release testing process is to convince the
supplier of the system that it is good enough for use. If so, it can be
released as a product or delivered to the customer.
• Release testing is usually a black-box testing process where tests
are derived from the system specification. The system is treated as
a black box whose behavior can only be determined by studying its
inputs and the related outputs. Another name for this is
‘functional testing’, so-called because the tester is only concerned
with functionality and not the implementation of the software.

3.3.1 Requirements-based testing

• Requirements-based testing, therefore, is a systematic approach to
test case design where you consider each requirement and derive a set
of tests for it.
• Requirements-based testing is validation rather than defect
testing—you are trying to demonstrate that the system has properly
implemented its requirements.
• For example, consider related requirements for the MHC-PMS
(introduced in Chapter 1), which are concerned with checking for drug
allergies:
If a patient is known to be allergic to any particular
medication, then prescription of that medication shall result
in a warning message being issued to the system user.
If a prescriber chooses to ignore an allergy warning, they
shall provide a reason why this has been ignored.
To check if these requirements have been satisfied, you may need to develop
several related tests:

Page 101
1. Set up a patient record with no known allergies. Prescribe medication
for allergies that are known to exist. Check that a warning message is not
issued by the system.
2. Set up a patient record with a known allergy. Prescribe the medication
to that the patient is allergic to, and check that the warning is issued by the
system.
3. Set up a patient record in which allergies to two or more drugs are
recorded. Prescribe both of these drugs separately and check that the
correct warning for each drug is issued.
4. Prescribe two drugs that the patient is allergic to. Check that two
warnings are correctly issued.
5. Prescribe a drug that issues a warning and overrule that warning.
Check that the system requires the user to provide information explaining
why the warning was overruled.
3.3.2 Scenario testing
• Scenario testing is an approach to release testing where you devise
typical scenarios of use and use these to develop test cases for the
system.
• A scenario is a story that describes one way in which the system
might be used.
• Scenarios should be realistic and real system users should be able to
relate to them.
• As an example of a possible scenario from the MHC-PMS, Figure 3.7
describes one way that the system may be used on a home visit.

Page 102
 Fig 3.7: An usage
scenario for
MHC-PMS
It tests a number of features of the MHC-PMS:
1.Authentication by logging on to the system.
2.Downloading and uploading of specified patient records to a laptop.
3.Home visit scheduling.
4.Encryption and decryption of patient records on a mobile device.
5.Record retrieval and modification.
6.Links with the drugs database that maintains side-effect information.
7.The system for call prompting.
• If you are a release tester, you run through this scenario, playing the
role of Kate and observing how the system behaves in response to
different inputs.
• As ‘Kate’, you may make deliberate mistakes, such as inputting the
wrong key phrase to decode records. This checks the response of the
system to errors. You should carefully note any problems that arise,
including performance problems.

Page 103
• If a system is too slow, this will change the way that it is used. For
example, if it takes too long to encrypt a record, then users who are
short of time may skip this stage.
• If they then lose their laptop, an unauthorized person could then view
the patient records.
• When you use a scenario-based approach, you are normally testing
several requirements within the same scenario.

3.3.3 Performance testing

• Performance tests have to be designed to ensure that the system can
process its intended load.
• This usually involves running a series of tests where you increase the
load until the system performance becomes unacceptable.
• Performance testing is concerned both with demonstrating that the
system meets its requirements and discovering problems and defects
in the system. To test whether performance requirements are being
achieved, you may have to construct an operational profile.
• An operational profile is a set of tests that reflect the actual mix of
work that will be handled by the system.
• Therefore, if 90% of the transactions in a system are of type A; 5% of
type B; and the remainder of types C, D, and E, then you have to
design the operational profile so that the vast majority of tests are of
type A. Otherwise, you will not get an accurate test of the operational
performance of the system.
• This approach, of course, is not necessarily the best approach for
defect testing.
• Stress testing is particularly relevant to distributed systems based on
a network of processors. These systems often exhibit severe
degradation when they are heavily loaded. The network becomes
swamped with coordination data that the different processes must

Page 104
 exchange. The processes become slower and slower as they wait for
the required data from other processes.
• Stress testing helps you discover when the degradation begins so that
you can add checks to the system to reject transactions beyond this
point.

3.4 User testing

• User or customer testing is a stage in the testing process in which
users or customers provide input and advice on system testing.
• This may involve formally testing a system that has been
commissioned from an external supplier, or could be an informal
process where users experiment with a new software product to see if
they like it and that it does what they need.
• There are three different types of user testing:
1. Alpha testing, where users of the software work with the development
team to test the software at the developer’s site.
2. Beta testing, where a release of the software is made available to
users to allow them to experiment and to raise problems that they discover
with the system developers.
3. Acceptance testing, where customers test a system to decide
whether or not it is ready to be accepted from the system developers and
deployed in the customer environment.

1. Alpha testing:-
• users and developers work together to test a system as it is
being developed. This means that the users can identify
problems and issues that are not readily apparent to the
development testing team.
• Developers can only really work from the requirements but
these often do not reflect other factors that affect the practical
use of the software

Page 105
 • Alpha testing is often used when developing software products
that are sold as shrink-wrapped systems.
• It also reduces the risk that unanticipated changes to the
software will have disruptive effects on their business.
• Alpha testing may also be used when custom software is being
developed.
2. Beta testing:-
• takes place when an early, sometimes unfinished, release of a
software system is made available to customers and users for
evaluation.
• Beta testers may be a selected group of customers who are early
adopters of the system. Alternatively, the software may be made
publicly available for use by anyone who is interested in it.
• Beta testing is mostly used for software products that are used
in many different environments.
• Beta testing is therefore essential to discover interaction
problems between the software and features of the environment
where it is used.
3. Acceptance testing:-
• Is an inherent part of custom systems development. It takes
place after release testing.
• It involves a customer formally testing a system to decide
whether or not it should be accepted from the system developer.
Acceptance implies that payment should be made for the
system.
• There are six stages in the acceptance testing process, as
shown in Figure 3.8. They are:

Page 106
1. Define acceptance criteria This stage should, ideally, take
place early in the process before the contract for the system is
signed. The acceptance criteria should be part of the system
contract and be agreed between the customer and the developer.
In practice, however, it can be difficult to define criteria so early
in the process. Detailed requirements may not be available and
there may be significant requirements change during the
development process.
2. Plan acceptance testing This involves deciding on the
resources, time, and budget for acceptance testing and
establishing a testing schedule. The acceptance test plan should
also discuss the required coverage of the requirements and the
order in which system features are tested. It should define risks
to the testing process, such as system crashes and inadequate
performance, and discuss how these risks can be mitigated.
3. Derive acceptance tests Once acceptance criteria have been
established, tests have to be designed to check whether or not a
system is acceptable. Acceptance tests should aim to test both
the functional and non-functional characteristics (e.g.,
performance) of the system. They should, ideally, provide
complete coverage of the system requirements.
4. Run acceptance tests The agreed acceptance tests are
executed on the system. Ideally, this should take place in the
actual environment where the system will be used, but this may
be disruptive and impractical. Therefore, a user testing
environment may have to be set up to run these tests. It is

Page 107
 difficult to automate this process as part of the acceptance tests
may involve testing the interactions between end-users and the
system. Some training of endusers may be required.
5. Negotiate test results It is very unlikely that all of the defined
acceptance tests will pass and that there will be no problems
with the system. If this is the case, then acceptance testing is
complete and the system can be handed over. More commonly,
some problems will be discovered. In such cases, the developer
and the customer have to negotiate to decide if the system is
good enough to be put into use. They must also agree on the
developer’s response to identified problems.
6. Reject/accept system This stage involves a meeting between
the developers and the customer to decide on whether or not the
system should be accepted. If the system is not good enough for
use, then further development is required to fix the identified
problems. Once complete, the acceptance testing phase is
repeated.

Page 108
 Module 3
Chapter 2
Software Evolution

Introduction
Software development does not stop when a system is delivered but
continuesthroughout the lifetimeof the system. After a system has been deployed,
it inevitablyhas to change if it is to remain useful.
Causes of system change

⮚ Business changes and changes to user expectationsgenerate new

requirements for the existing software.
⮚ Parts of the softwaremay have to be modified to correct errors that are
found in operation
⮚ To adapt itforchanges to its hardware and software platform
⮚ To improve its performance orother non- functional characteristics.
An alternative view of the software evolutionlife cycle, as shown in the following
figure

Fig: Evolution and Servicing

⮚ This model is depicted as having four phases – initial development,
evolution, servicing and phaseout.
⮚ Evolution is the phase in which significant changes to the
softwarearchitecture and functionality may be made.
⮚ During evolution, the software is used successfully and there is a constant
streamof proposedrequirements changes.
⮚ At some stage in the life cycle, thesoftware reaches a transition point where
significant changes,implementing newrequirements, become less and less
cost effective.
⮚ At that stage, the software moves from evolution to servicing.
⮚ During servicing, the only changes thatare made are relatively small,
essential changes. However, the software is still useful.
⮚ In the final stage, phase-out, the software may still be used but nofurther
changes are beingimplemented.
RNSIT

Evolution processes
Change identification and evolution
process
System change proposals causes system evolution in all organizations.
Change proposals may come from
⮚ existing requirements that have not been implementedin the released
system
⮚ requests for new requirements
⮚ bug reports from system stakeholders
⮚ new ideas for software improvement from the system development team
The processes ofchange identification and system evolution are cyclic
andcontinue throughout the lifetime ofa system. This process is as shown in the
following figure

Fig: Change identification and evolution process

SOFTWARE ENGINEERING AND MANAGEMENT 1

RNSIT

The software evolution process

Fig: The software evolution process

⮚ An overview of the evolution process is as shown in the above figure
⮚ The process includes the fundamental activities of change analysis, release
planning,systemimplementation, and releasing a system to customers.
⮚ In the impact analysis stage, cost and impact of proposed changes are
assessed to see  how much of the system is affected by the change,
 how much it might cost toimplement the change.
⮚ If the proposed changes are accepted,a new release of the system
isplanned.
⮚ During release planning, all proposed changes - fault repair, adaptation,
and newfunctionality - are considered.
⮚ A decision is then made on which changes to implement in the next version
of the system.
⮚ The changes are implemented and validated, and a new version of the
system is released.
⮚ The processthen iterates with a new set of changes proposed for the next
release.
The change implementation process

Fig: Change Implementation

⮚ Change implementation is an iteration of the development process, where the
revisions to the system are designed, implemented, and tested.
⮚ The change implementation process is as shown in the above figure.
⮚ New requirements that reflect the system changes are proposed, analysed,
and validated.

SOFTWARE ENGINEERING AND MANAGEMENT 2

RNSIT

⮚ System components are redesigned and implemented and the system is

retested.
⮚ If appropriate, prototyping of the proposed changes may be carried out as part
of the change analysis process.
The emergency repair process

Fig: The emergency repair process

⮚ Change requests sometimes relate to system problems that have to be tackled
urgently.
⮚ These urgent changes can arise for three reasons:
1. If a serious system fault occurs that has to be repaired to allow normal
operation to continue.
2. If changes to the systems operating environment have unexpected effects
that disrupt normal operation.
3. If there are unanticipated changes to the business running the system,
such as the emergence of new competitors or the introduction of new
legislation that affects the system.
⮚ The emergency repair process is required to quickly fix the above problems.
⮚ The source code is analyzed and modified directly, rather than modifying the
requirements and design
⮚ The disadvantages of emergency repair process are as follows o the
requirements, the software design, and the code become inconsistent o the
process of software aging is accelerated since a quick workable solution is
chosen rather than the best possible solution for quick fix o future changes
become more difficult and maintenance costs increase
Program evolution dynamics
⮚ Program evolution dynamics is the study of system change.
⮚ Lehman’s laws’ concerning system change are as shown below

SOFTWARE ENGINEERING AND MANAGEMENT 3

RNSIT

Continuing change
⮚ The first law states that system maintenance is an inevitable process.
⮚ As the system’s environment changes, new requirements emerge and the
system must be modified.
Increasing complexity
⮚ The second law states that, as a system is changed, its structure is degraded.
⮚ To avoid this, invest in preventative maintenance.
⮚ Time is spent improving the software structure without adding to its
functionality.
⮚ This means additional costs, more than those of implementing required system
changes. Large program evolution
⮚ It suggests that large systems have a dynamic of their own
⮚ This law is a consequence of structural factors that influence and constrain
system change, and organizational factors that affect the evolution process.
 Structural factors:
⮚ These factors come from complexity of large systems.
⮚ As you change and extend a program, its structure tends to degrade.
⮚ Making large changes to a program may introduce new faults and then inhibit
further program changes.
 Organisational factors:

SOFTWARE ENGINEERING AND MANAGEMENT 4

RNSIT

⮚ These are produced by large organizations.

⮚ Companies have to make decisions on the risks and value of the changes and
the costs involved. Such decisions take time to make.
⮚ The speed of the organization’s decision-making processes therefore governs
the rate of change of the system. Organizational stability
⮚ In most large programming projects a change to resources or staffing has
imperceptible (slight) effects on the long-term evolution of the system.

Conservation of familiarity
⮚ Adding new functionality to a system inevitably introduces new system faults.
⮚ The more functionality added in each release, the more faults there will be.
⮚ Relatively little new functionality should be included in this release.
⮚ This law suggests that you should not budget for large functionality
increments in each release without taking into account the need for fault
repair.

Continuing growth
⮚ The functionality offered by systems has to continually increase user
satisfaction.
⮚ The users of software will become increasingly unhappy with it unless it is
maintained and new functionality is added to it.

Declining quality
 The quality of systems will decline unless they are modified to reflect changes
in their operational environment.

Feedback system
 Evolution processes must incorporate feedback systems to achieve significant
product improvement.
Software maintenance
⮚ It is the general process of changing a system after it has been delivered.
⮚ There are three different types of software maintenance:
o Fault repairs o
Environmental adaptations o
Functionality addition

SOFTWARE ENGINEERING AND MANAGEMENT 5

RNSIT

Fault repairs
⮚ Coding errors are usually relatively cheap to correct
⮚ Design errors are more expensive as they may involve rewriting several
program components.
⮚ Requirements errors are the most expensive to repair because of the extensive
system redesign which may be necessary.
Environmental adaptation
⮚ This type of maintenance is required when some aspect of the system’s
environment such as the hardware, the platform operating system, or other
support software changes.
⮚ The application system must be modified to adapt it to cope with these
environmental changes.
Functionality addition
 This type of maintenance is necessary when the system requirements change
in response to organizational or business change.

Maintenance effort distribution

Fig: Maintenance effort distribution

⮚ Software maintenance takes up a higher proportion of IT budgets than new

development.
⮚ Also, most of the maintenance budget and effort is spent on implementing new
requirements than on fixing bugs. This is shown in the above figure

Development and maintenance costs

SOFTWARE ENGINEERING AND MANAGEMENT 6

RNSIT

Fig: Development and maintenance costs

⮚ The above figure shows that overall lifetime costs may decrease as more effort
is expended during system development to produce a maintainable system.
⮚ In system 1, more development cost has resulted in lesser overall lifetime costs
when compared to system 2.
⮚ It is usually more expensive to add functionality after a system is in operation
than it is to implement the same functionality during development. The
reasons for this are:

1. Team stability
⮚ The new team or the individuals responsible for system maintenance are
usually not the same as the people involved in development
⮚ They do not understand the system or the background to system design
decisions.
⮚ They need to spend time understanding the existing system before
implementing changes to it.
2. Poor development practice
⮚ The contract to maintain a system is usually separate from the system
development contract.
⮚ There is no incentive for a development team to write maintainable software.
⮚ The development team may not write maintainable software to save effort. 
This means that the software is more difficult to change in the future.
3. Staff skills
⮚ Maintenance is seen as a less-skilled process than system development.
⮚ It is often allocated to the most junior staff.
⮚ Also, old systems may be written in obsolete programming languages.
⮚ The maintenance staff may not have much experience of development in these
languages and must learn these languages to maintain the system. 4.
Program age and structure
⮚ As changes are made to programs, their structure tends to degrade.
⮚ As programs age, they become harder to understand and change.

SOFTWARE ENGINEERING AND MANAGEMENT 7

RNSIT

⮚ System documentation may be lost or inconsistent.

⮚ Old systems may not have been subject to stringent configuration
management so time is often wasted finding the right versions of system
components to change.

Maintenance prediction
⮚ It is important try to predict what system changes might be proposed and
what parts of the system are likely to be the most difficult to maintain.
⮚ Also estimating the overall maintenance costs for a system in a given time
period is important.
⮚ The following figure shows these predictions and associated questions

Fig: Maintenance prediction

⮚ The number of change requests for a system requires an understanding of the
relationship between the system and its external environment.

⮚ Therefore, to evaluate the relationships between a system and its environment

the following assessment should be made
1. The number and complexity of system interfaces The larger the number of
interfaces and the more complex these interfaces, the more likely it is that
interface changes will be required as new requirements are proposed.
2. The number of inherently volatile system requirements The requirements
that reflect organizational policies and procedures are likely to be more volatile
than requirements that are based on stable domain characteristics.
3. The business processes in which the system is used As business processes
evolve, they generate system change requests. The more business processes
that use a system, the more the demands for system change.
⮚ After a system has been put into service, the process data may be used to help
predict maintainability.
⮚ The process metrics that can be used for assessing maintainability are as
follows:

SOFTWARE ENGINEERING AND MANAGEMENT 8

RNSIT

1. Number of requests for corrective maintenance An increase in the number

of bug and failure reports may indicate that more errors are being introduced
into the program than are being repaired during the maintenance process.
This may indicate a decline in maintainability.
2. Average time required for impact analysis The number of program
components that are affected by the change request. If this time increases, it
implies more and more components are affected and maintainability is
decreasing.
3. Average time taken to implement a change request This is the amount of
time needed to modify the system and its documentation. An increase in the
time needed to implement a change may indicate a decline in maintainability.
4. Number of outstanding change requests An increase in this number over
time may imply a decline in maintainability.

Software reengineering
⮚ Reengineering is done to improve the structure and understandability of
legacy software systems
⮚ Reengineering makes legacy software systems easier to maintain
⮚ Reengineering may involve redocumenting the system, refactoring the
system architecture, translating programs to a modern programming
language, and modifying and updating the structure and values of the
system’s data.
⮚ The functionality of the software is not changed due to reengineering

Benefits of reengineering
Reduced risk Reengineering reduces the high risk in redeveloping
business-critical software. Errors may be made in the system specification or
there may be development problems. Delays in introducing the new software may
mean that business is lost and extra costs are incurred.
Reduced cost The cost of reengineering may be significantly less than the cost of
developing new software.

The reengineering process

SOFTWARE ENGINEERING AND MANAGEMENT 9

RNSIT

Fig: The reengineering process

The activities involved in reengineering process are as follows
1. Source code translation
 Using a translation tool, the program is converted from an old programming
language to a more modern version of the same language or to a different
language.
2. Reverse engineering
⮚ The program is analyzed and information extracted from it.
⮚ This helps to document its organization and functionality.
⮚ This process is usually completely automated.
3. Program structure improvement
⮚ The control structure of the program is analyzed and modified to make it
easier to read and understand.
⮚ This can be partially automated but some manual intervention is usually
required.
4. Program modularization
⮚ Related parts of the program are grouped together.
⮚ Where appropriate, redundancy is removed.
⮚ This is a manual process.
5. Data reengineering
⮚ The data processed by the program is changed to reflect program changes.
⮚ This may mean redefining database schemas, converting existing databases
to the new structure, clean up the data, finding and correcting mistakes,
removing duplicate records, etc.
⮚ Tools are available to support data reengineering.

SOFTWARE ENGINEERING AND MANAGEMENT 10

RNSIT

Reengineering approaches
⮚ The costs of reengineering depend on the extent of the work that is carried out.
⮚ The following figure shows a spectrum of possible approaches to reengineering

Fig: Reengineering approaches

⮚ Costs increase from left to right.
⮚ Source code translation is the cheapest option.
⮚ Reengineering as part of architectural migration is the most expensive.

Disadvantages of reengineering
⮚ There are limits to how much you can improve a system by reengineering.
⮚ It isn’t possible to convert a system written using a functional approach to an
object- oriented system.
⮚ Major architectural changes of the system data management cannot be carried
out automatically.
⮚ The reengineered system will probably not be as maintainable as a new system
developed using modern software engineering methods.

Preventative maintenance by
refactoring
⮚ Refactoring is the process of making improvements to a program to slow down
degradation through change.
⮚ It means modifying a program to improve its structure, to reduce its
complexity, or to make it easier to understand.
⮚ Refactoring a program is not adding new functionality.
⮚ Refactoring is considered as ‘preventative maintenance’ that reduces the
problems of future change.

SOFTWARE ENGINEERING AND MANAGEMENT 11

RNSIT

Difference between reengineering and refactoring

⮚ Reengineering takes place after a system has been maintained for some time
and maintenance costs are increasing.
⮚ Refactoring is a continuous process of improvement throughout the
development and evolution process. It is intended to avoid the structure and
code degradation that increases the costs and difficulties of maintaining a
system.
⮚ There are situations (bad smells) in which the code of a program can be
improved or refactored. They are as follows

1. Duplicate code The same of very similar code may be included at different
places in a program. This can be removed and implemented as a single method or
function that is called as required.
2. Long methods If a method is too long, it should be redesigned as a number
of shorter methods.
3. Switch (case) statements These often involve duplication, where the
switch depends on the type of some value. The switch statements may be
scattered around a program. In objectoriented languages, you can often use
polymorphism to achieve the same thing.
4. Data clumping Data clumps occur when the same group of data items
(fields in classes, parameters in methods) reoccur in several places in a program.
These can often be replaced with an object encapsulating all of the data.
5. Speculative generality This occurs when developers include generality in a
program in case it is required in future. This can often simply be removed.
Legacy system management
⮚ Organizations have a limited budget for maintaining and upgrading legacy
systems.
⮚ They have to decide how to get the best return on their investment.
⮚ This involves making a realistic assessment of their legacy systems and then
deciding on the most appropriate strategy for evolving these systems.
⮚ There are four strategic options:
1. Scrap the system completely This option should be chosen when the
system is not making an effective contribution to business processes.
2. Leave the system unchanged and continue with regular maintenance
This option should be chosen when the system is still required but is fairly stable
and the system users make relatively few change requests.
3. Reengineer the system to improve its maintainability This option
should be chosen when the system quality has been degraded by change and
where a new change to the system is still being proposed.

SOFTWARE ENGINEERING AND MANAGEMENT 12

RNSIT

4. Replace all or part of the system with a new system This option should
be chosen when factors, such as new hardware, mean that the old system cannot
continue in operation or where off-the-shelf systems would allow the new system
to be developed at a reasonable cost.

Legacy system assessment

Legacy systems can be assessed from two perspectives
• Business perspective is to decide whether or not the business really needs
the system.
• Technical perspective is to assess the quality of the application software
and the system’s support software and hardware.
There are four clusters of systems
1. Low quality, low business value Keeping these systems in operation will
be expensive and the rate of the return to the business will be fairly small. These
systems should be scrapped.
2. Low quality, high business value These systems are making an important
business contribution so they cannot be scrapped. However, their low quality
means that it is expensive to maintain them. These systems should be
reengineered to improve their quality.
They may be replaced, if a suitable off-the-shelf system is available.
3. High quality, low business value These are systems that don’t contribute
much to the business but which may not be very expensive to maintain. It is not
worth replacing these systems so normal system maintenance may be continued if
expensive changes are not required and the system hardware remains in use. If
expensive changes become necessary, the software should be scrapped.
4. High quality, high business value These systems have to be kept in
operation. However, their high quality means that you don’t have to invest in
transformation or system replacement. Normal system maintenance should be
continued.
Business perspective
The four basic issues that have to be discussed with system stakeholders to
assess business value of the system are as follows
1. The use of the system If systems are only used occasionally or by a small
number of people, they may have a low business value. However, there may be
occasional but important use of systems. For example, in a university, a student
registration system may only be used at the beginning of each academic year.
However, it is an essential system with a high business value.

SOFTWARE ENGINEERING AND MANAGEMENT 13

RNSIT

2. The business processes that are supported When a system is introduced,

business processes are designed to exploit the system’s capabilities. However, as
the environment changes, the original business processes may become obsolete.
Therefore, a system may have a low business value because it forces the use of
inefficient business processes.
3. The system dependability If a system is not dependable and the problems
directly affect the business customers or mean that people in the business are
diverted from other tasks to solve these problems, the system has a low business
value.
4. The system outputs If the business depends on the system outputs, then
the system has a high business value. Conversely, if these outputs can be easily
generated in some other way or if the system produces outputs that are rarely
used, then its business value may be low.
Technical perspective
To assess a software system from a technical perspective, you need to consider
both the application system itself and the environment in which the system
operates.
Factors used in environment assessment

SOFTWARE ENGINEERING AND MANAGEMENT 14

RNSIT

Factors used in application assessment

Data can be collected to assess the quality of the system. The data that can be
collected are
1. The number of system change requests System changes usually corrupt
the system structure and make further changes more difficult. The higher this
value, the lower the quality of the system.
2. The number of user interfaces The more interfaces, the more likely that
there will be inconsistencies and redundancies in these interfaces, hence
reducing system quality.

SOFTWARE ENGINEERING AND MANAGEMENT 15

RNSIT

3. The volume of data used by the system The higher the volume of data
(number of files, size of database, etc.), the more likely that it is that there will be
data inconsistencies that reduce the system quality.

Chapter2
Agile methods and Devops
Learning Objectives
By studying The Agile Manifesto: Values and Principles.
• You will Understand and Appreciate the rationale for Agile
Software Development Methods
• You will Understand and Appreciate the Agile Manifesto:
Values and
Principles, and
• You will Understand and Appreciate the differences between
Agile and Plan Driven Development

Introduction
Agile Movement is towards developing software and software systems
in a rapid way. In this chapter the Agile Manifesto: Values and
Principles, we study the rationale for Agile Software Development
Methods, the Agile Manifesto: Values and Principles, and the
differences between Agile and Plan Driven Development
Need for Agile Software Development
Software is a part of every system and such a software shall be
released on-time, help users to fulfill their expectations, and also,
ensure business value. These critical requirements can be addressed
by adapting practices of rapid development and delivery of software so
that we can address technical disruptions, emergence of competing
products and services, new opportunities and markets, and align to
changing social and economic conditions. However making it possible
is not so easy but quite a challenging one because of changes that
have become common phenomena which come in the form of –

SOFTWARE ENGINEERING AND MANAGEMENT 16

RNSIT

demand for do it fast in days or weeks; expectations of customer,

users, and team members to understand their ideas and incorporate
them; more aggressive demand to give out workable product as soon
as possible; and that too without any need for cumbersome and
rigorous processes including sign-offs. In order to address these
challenges, software development community and organizations are
always seeking for superior approaches, and as days are progressing
these superior approaches have basis in repaid development and
delivery of software approaches.
Agile Software Development is one such rapid development and
delivery of software approach that helps to address a critical
requirement in software product development by making it
increasingly possible to release software product on time, making it
relevant and useful, and incorporate changes even in later stages in
software development life cycle stages. Agile practices will help in
release of workable product by increasing possibility of higher value to
business and users.
However mindset and rigorous practice of processes over years have
„conditioned‟ software development community and organizations
that have „institutionalized‟ process based culture where all roles in
software development and delivery are reflecting and exhibiting
mindset of worrying only about the project by forgetting the product in
every acts and deeds which show-off in the form of - customer needs
everything that would have been addressed yesterday, conflicts and
negotiations that are more inclined towards making someone
accountable by exhibiting culture of „If it is your problem, fix it at
your cost‟ than focusing on addressing the concern; and attitude that
intensively focuses where in no-one wants to pay for anything which
hinders the very thought process of adding innovation and value.
Though this is predominantly representing existing situations, the
context is increasingly compelling software development and
organizations to look-out solutions for „what to do now to stay and be

SOFTWARE ENGINEERING AND MANAGEMENT 17

RNSIT

relevant?!‟. Failure to find solutions or exhibition of „corporate ego

and arrogance‟ may result in abandonment of product by customers
and bankruptcy of well-to do companies faster than our imagination.
Hence to stay in business and continue to be relevant there is no
other option than accepting that change is bound to be here,
understanding that project and customer-vendor mindset is “not
working”, and customer and user needs greater product and then we
shall move forward to establish culture of worrying about delivering
the workable product by getting away from irrelevant project
development, process, and documentation. Agile Software
Development provides more optimistic path to achieve these goals and
objectives.

Agile Model
Unlike other software development models, assumes that the change
is constant so adapt to change rather than control change
This is very practical and major movement away from conventional
software development models which assume that Requirements will
not rapidly change ones we specify them and Object Oriented models
that work with objective of need to design for the future and need to
design for reuse Agile Manifesto and Four Key Ideas in Agile
To produce better software product by reducing the time gap between
doing some activity and gaining feedback.
In order to implement agile manifesto, agile development approach
uses four key ideas:
• Individuals and interactions are preferred over processes and
tools
• Working software is preferred over comprehensive
Documentation
• Customer collaboration is preferred over contract negotiation
• Responding to change is preferred over following a plan
And agile manifesto and agile software development uses following Key
Principles.

SOFTWARE ENGINEERING AND MANAGEMENT 18

RNSIT

Key Principles of Agile Manifesto and Agile Software

Development
Agile manifesto and agile software development uses following Key
Principles.
• #1 Principle: Customer Involvement: Customer Should be
Closely involved throughout the Development Process Their role
is provide and priorities new system requirements and to
evaluate the iterations of the system.
• #2 Principle: Incremental Delivery: The Software Developed in
Increments with the customer specifying the requirements to be
included in each increment.
• #3 Principle: People Not Process: The Skills of Development
Team should be recognized and exploited. Team member should
be left to develop their own ways of working without prescriptive
process.
• #4 Principle: Embrace Change: Expect the System
Requirements to Change and so design system to accommodate
these changes.
• #5 Principle: Maintain Simplicity: Focus on Simplicity in both
the software being developed and in the development process.
Wherever possible, actively work to eliminate the complexity
from the system.
Agile Methods: Where is it Working Well?
Agile methods work very well in small and medium scale software
development and teams. Agile methods are found be effective under
situations mentioned below:
• Product Development where software company is developing a
small or medium sized product for sale
• Customer System Development within an organization where
there is clear commitment from the customer involved in the
development process and where there are not a lot of external
rules and regulations that affect the software Agile methods
seems to be less effective in project, teams, and software that

SOFTWARE ENGINEERING AND MANAGEMENT 19

RNSIT

are large in size, and also, where systems are safety and mission
critical. Agile methods face issues and failures when
• Putting in a fixed price contract where managing cost & effort
becomes more important over business value. Agile methods
since focus on value more than cost and effort frequently fail to
stick to cost and effort.
• Expecting all of the scope to be delivered: Agile methods focus
on workable product and on-time delivery. Hence in agile we can
notice negotiating with scope by reducing or increasing scope
when it is found to be of value can be quite a common
characteristic.
• Pushing the team hard – making unrealistic demands: Agile
uses group creativity and co-creation and as such team
motivation is critical for success. When we push the team hard
by putting unrealistic demands, we can see that it may result in
demotivated team. Demotivated team frequently fails to deliver
value and innovation.
• Focusing on project execution efficiency as against product
value delivered: Project efficiency is all about sticking to scope,
effort, schedule, and budget. Agile accepts changes and hence
scope always undergoes change even in later stages of the
software development life cycle and it may consume more effort
and budget. Hence agile methods may not of great value in
fixed-budget and fixedscope projects.

Plan-Driven and Agile Development

Learning Objectives
By studying Plan-driven and Agile Development:
• You will understand and appreciate the differences between
Agile Development and Plan-driven Approaches

SOFTWARE ENGINEERING AND MANAGEMENT 20

RNSIT

• You will understand on range of questions to be answered so as

to effectively balance Agile Development and Plan-driven
Approaches
Introduction
Plan-driven development focuses on sticking to scope, using allocated
effort and budget, sticking to on-time delivery, and compliance with
process. It believes that quality product is result of plan-driven project
management and process management.
When compared with plan-driven approach, agile development focuses
on providing value and delivering workable product. Accepting
changes and varying scope, using more effort and cost than allocated
are seen frequently in agile development. However agile believes in
fixed-schedule ensuring on-time delivery. In brief, agile development
believes in workable product by willingly accepting changes with
higher value against that of plan-driven development wherein ones
plan including processes is accepted then changes are discouraged. In
this section, we study the differences between Agile Development and
Plan-driven Approaches, and understand on range of questions to be
answered so as to effectively balance Agile Development and
Plan-driven Approaches.
The Differences between Agile Development and Plan-driven
Development Approaches
Following table provides the differences Agile Development and
Plan-driven Development Approaches:
Table 3.1 : Difference between Agile Development and
Plan-driven Development Approach
Agile Development Approach Plan-driven Development
Approach
“Producing Workable Product”: “Process Centric Delivery”
 Creativity of People and their  Compliance with Processes shall
be

SOFTWARE ENGINEERING AND MANAGEMENT 21

RNSIT

Decision shall be considered as considered as the basis to produce

the basis to produce Workable “Quality Product”
Product  Well planned Product Integration
 Continuous Incremental and Deployment of the Product
Integration and Deployment of the only after User Acceptance of the
Product
Product as fast as possible
“Design and Implementation” centric “Stage-wise Implementation”
 Requirement Specification,  Well Defined Stages with Clearly
Designing, Implementation, And Defined Inputs, Entry Criteria,
Verification & Validation Take Outputs with Baselined Output Of
Place “Simultaneously” One Stage becomes Input To Begin
The Next Stage.
“Active Participation in All Tasks” “Well-defined Role and Role Specific
• All Stake Holders are Accountable Tasks”
and Actively Engage throughout • Each Role is Accountable for a
• Engage Specific Role and Work Product
to • Work only for Delivering the Work
Product they are Responsible for
add
value
with
Simplicity

“Active “Role Specific Involvement and

Analytical Thinking”
Participation • Accountable for the Delivery of a
Specific Phase-end Work Product
of • Analytical Thinking, Role Specific
Communication and Participation
People throughout and Group
Creativity”

SOFTWARE ENGINEERING AND MANAGEMENT 22

RNSIT

• Accountable for Delivery of the

Workable End-Product
• Group Thinking, Seamless
Communication and Active
Participation
“No Explicit Testing Phase” “Explicit Testing Phase”
• Development Development and Testing are Separate
Phases
and
Verification and Validation takes place
Testing only
“after Creation” of Work Product
are
Testing is the Role of Specific Roles only
Simultaneous Activities
• Verification and Validation takes
place Simultaneously with the
Creation of Work Product
• All are involved in Testing User Acceptance Testing is the basis for
• Stake Holders Decide on Product Deciding on Product Readiness
Readiness
“Relevant Documentation based on “Intensive Documentation based on
Need felt by Stake Holders” Stringent Requirements of the Phase
• Emphasis in
Life Cycle”
on
• Emphasis on Intensive and In depth
Relevant Documentation
Documentation only • Project Specific tailored Process
• Stake Holders decide on Need, „forces‟ on Rigorous and Mandatory
Type, and Depth of Documentation Documentation
Effectively Balancing Agile Development and Plan-driven
Approaches
Most projects include Balancing of practices from Agile Development
and Plan-driven
Approaches. To arrive at effective combined approach we need to
answer a range of Technical, Human, and Organizational Questions.

SOFTWARE ENGINEERING AND MANAGEMENT 23

RNSIT

We have to ask this range of questions and get proper professional

and corroborated answers so as to effectively balance Agile
Development and Plan-driven Approaches.
Questions and what we seek for: A Range of Technical, Human, and
Organizational
Questions to Define a Combined Project Specific Approach
Question #1: Need for Very Detailed Specification and Design
• Is it Important to have a very detailed specification and design before moving
to Implementation?
• If
YES
=> Probably need to use Plan-driven Approach
Question #2: Incremental Delivery with Rapid Feedback from Customer
• Is an Incremental delivery strategy, where you deliver the software to the
customer and get rapid feedback from them, realistic?
• If
YES
=> If so, consider using Agile Approach

Question #3: How large is the system that is being developed and
team size and where it is located?
• If the system developed is small by a small co-located team who can
communicate informally
If YES
=> Consider using Agile Approach
• If the system developed large by a larger team who can communicate
formally
If YES
=> Consider using Plan-driven Approach

SOFTWARE ENGINEERING AND MANAGEMENT 24

RNSIT

Question #4: What type of System is being developed?

 Does the system requires a lot of analysis and detailed design before
implementation?
If YES
=> Consider using Plan-driven Approach

Question #5: What is the expected System Life Time?

• Does the expected system life time is long and requires a lot of
detailed documentation to communicate with maintenance and
support team?
If YES
=> Consider using Plan-driven Approach
• Does the expected system life time is small with rudimentary and
incomplete documentation with no need of maintenance and
support the workable product?
If YES
=> Consider using Agile Approach
Question #6: What Technologies are available to support system
development?
• If technologies that are available are robust, stable, and with enough
expertise?
If YES
=> Consider using Plan-driven Approach
• If technologies are bleeding edge and whose stability and robustness
are yet to be evaluated
If YES
=> Consider using Agile Approach

SOFTWARE ENGINEERING AND MANAGEMENT 25

RNSIT

Question #7: How is the Development Team Organized?

• Distributed, Outsourced, and need intensive documentation and
formal communication?
If YES
=> Consider using Plan-driven Approach
• Co-located, homogeneous, and rudimentary and basic
documentation and interactive communication?
If YES
=> Consider using Agile Approach
Question #8: Are their cultural issues that may affect system
development?
• Traditional Engineering Organizations with a need of intensive
documentation and formal communication?
If YES
=> Consider using Plan-driven Approach
• Non-traditional, deployment oriented organizations with
continuous live updates and replacements that require
rudimentary and basic documentation and interactive
communication?
If YES
=> Consider using Agile Approach
Question #9: How good are the designers and programmers in the
development team?
• If the designers and programmers in the development team are
with higher skills, capability, competence, and adaptability?
If YES
=> Consider using Plan-driven Approach
• Non-traditional, deployment oriented organizations with
continuous live updates and replacements that require
rudimentary and basic documentation and interactive
communication?
If YES
=> Consider using Agile Approach

SOFTWARE ENGINEERING AND MANAGEMENT 26

RNSIT

Question #10: Is the System subject to external regulation?

• Is the System subject to external regulation requiring external
regulatory authority to approve with the requirement to produce
intensive and formal documentation?
If YES
=> Consider using Plan-driven Approach
• Is the System not subjected to any external regulation and does not
require any external regulatory authority to approve?
If YES
=> Consider using Agile Approach
The above questions are acting as cues and trigger much needed
though processes. By using these questions, and by understanding
situations and context, we have to make professional judgements to
go in depth to develop an insight and then make a proper choice of
plan-driven development approach and agile development approach.

Agile Methods: SCRUM Approach

Learning Objectives
By studying Agile Methods- SCRUM Approach:
• You will Understand and Appreciate the SCRUM Approach and
• You will Understand and Appreciate How Key Practices in
Extreme
Programming relate to the General Principles of Agile
Methods
Introduction
Scrum is the most popular framework for agile implementation in
projects. Scrum is an iterative incremental framework for managing
agile projects. The SCRUM Approach of Agile has roles, terminology,
and software process framework with agile specific programming
approach referred to as extreme programming.

SOFTWARE ENGINEERING AND MANAGEMENT 27

RNSIT

SCRUM Approach and Roles

Scrum is the most popular framework for agile implementation in
projects. Scrum is an iterative incremental framework for managing
agile projects. Scrum has following roles:
• Scrum Master – maintains the Scrum processes
• Product Owner – represents the stakeholders
• Team – a group of about 7 people o The team does the actual
development: analysis, design, implementation, testing, etc.
While using Scrum Approach, we shall be conversant with certain
Scrum specific terminology which include the following”
• Product Backlog: All features that have to be developed
• Sprint Backlog: All features planned for the current sprint
• Sprint: An iteration in the Scrum development and its usually
few weeks
Scrum Process Framework
Scrum Process Framework starts with “Product Backlog”. “Product
Backlogs” is set of features that form the basis to start with agile
implementation. There can be changes to the product backlog as we
proceed since agile welcomes changes at any stage in software
development.
The “Product Backlogs” is split into many “Sprint Backlogs” with each
spring backlog having a set of specific features. While deciding on
sprint backlog and its scope, importance is given for rigid “2-weeks
schedule” (sometimes up to 4 weeks buy never beyond 4 weeks) for
implementation of the sprint backlog. All Scrum Roles contribute in
deciding “Sprint Backlogs” and by doing estimation.
Each “Sprint Backlog” forms the scope of “Sprint” which is an
iteration in the Scrum development and its usually 2-4 weeks. Scrum
focuses on design-and-program by using
“Extreme Programming” approach. At the end of each Sprint we get
workable Configuration Item which shall be maintained in
configuration management tool. As and when we complete a sprint it

SOFTWARE ENGINEERING AND MANAGEMENT 28

RNSIT

is integrated, workable product is built, and rolled out. We require

automation with proper build and release strategy towards this.

Fig 3.1 Scrum Approach

Stage 1: Outline Planning and Architectural Design
Agile Team is established comprising of developers and testers,
typically Select maximum 7 members. The “Product Backlog” received
from the client are Broken up into “Sprint Backlogs”. Sprints are of
fixed length, normally of 2-4 weeks. The team arrives at a high level
plan for the sprint. Team deliberates on Architectural Design, Strategy
for Continuous Integration, Unit Testing and Automation.
Stage 2: Implement Sprint Cycle
Sprint Cycle implementation involves following 4 Phases:
• 2.1 Assess Phase
• 2.2 Select Phase

SOFTWARE ENGINEERING AND MANAGEMENT 29

RNSIT

• 2.3 Develop Phase

• 2.4 Review Phase
2.1 Assess Phase
This involves the following:
• Study “Sprint Backlogs”
• Write user stories for each product backlog
– User Stories are the simplest description of the business
requirement that will allow acceptance tests to be created
and estimates to be done
– The Business Customers are the owners of these user stories
and are the one point contact to the development team for
the queries
– Use user stories to create time estimates for the release
planning meeting
2,2 Select Phase
This involves the following:
• Select features and functionality to be developed with discussion
involving the team that works with customer each iteration
starts with an Iteration Planning Meeting.
• Arrive at Development Tasks
• Team Member chooses Development Tasks he wants to own
• Decide on “Test-Code-Refactor” based Iterative development

2.3 Develop Phase

This involves the following steps:
• 2.3.1 Test First Approach: write a test and make design
decisions
• 2.3.2 Code by using Xtreme Programming with Paired
Programming. Write Just Enough Code and Test
simultaneously. Automate Unit Testing, and Refactor to keep
Code Healthy
Following sections discuss on each of these steps in length.

SOFTWARE ENGINEERING AND MANAGEMENT 30

RNSIT

2.3.1 Test First Approach: Write a Test and Make Design

Decisions
XP uses Test-first Development. Test-first Development or Test Driven
Development involves incremental Test Development from User Stories
by involving User in the Test Development and Validation. These Test
Cases are being used as specification for development of code and
also, testing and also, using Automated Testing Framework with focus
on stronger Unit Testing using Test Automation Tools. For example, in
Java programming Junit is used.
Test-first Development or Test Driven Development (TDD), also known
as test-first programming or test-first development, is a testing
methodology associated with Agile Programming.
Test First Approach is an evolutionary approach to development where
you must first write a test that fails before you write new functional
code. We write tests not as an afterthought to ensure our code works,
but instead as just part of the everyday, every minute way of building
software. Instead of writing our detailed design specifications on
paper, we write them in code. Instead of first striving to perfectly
design a system on paper, we use tests to guide our design. Here every
chunk of code is covered by unit tests, which must all pass all the
time. This would eliminate unit-level and regression bugs during
development.

SOFTWARE ENGINEERING AND MANAGEMENT 31

RNSIT

Fig 3.2 Test First or Test Driven Development (TDD) Approach

TDD concentrates on designing and developing one requirement at a
time. After the requirement is implemented it is tested. If the test
fails, the problem is rectified and is tested again. This process of
testing and rectifying occurs until the test becomes successful. All the
requirements are designed, developed and tested one by one.
Integration will be continual.
Test First Development addresses the following: Ad-hoc unit testing
and building infrastructure for regression testing, load testing and
stress testing
TDD focuses on Internal Quality Characteristics which are related to
quality of code:
Correctness, Structured, Modularity, and Documentation.
2.3.2 Code by using Xtreme Programming with Paired
Programming
Here we write “Just Enough Code and Test simultaneously”. Automate
Unit Testing, and Refactor to keep Code Healthy. Now we shall discuss
on Xtreme Programming with Paired Programming concpets in length.
Extreme (XTreme) Programming (XP)
Extreme Programming (XP) is perhaps the most popular agile
development methodology that uses good practices of iterative
development that provides the highest value for the customer. In order
to make it happen it uses a set of values, principles and practices for
rapidly developing high-quality software. XP is characterized by

SOFTWARE ENGINEERING AND MANAGEMENT 32

RNSIT

• User stories
• Pair programming
• Refactoring frequent integration
Following are Key Practices in Extreme Programming relate to the
General Principles of Agile Methods:
• Incremental Development: Incremental Development is well
supported through small frequent releases of the system with
the help of requirements that are represented as Functionalities
in the form of User Stories
• Customer Involvement is supported: Representative of End-User
of the System and Customer shall Involve, Engage, and
Constructively Criticise and also, define
& prioritise requirements and developing Acceptance Test for the system
• People but not Processes: People but not Processes is supported
through Paired
Programming, Collective Ownership of the Code, and
Suitable Development Process that discourages long working
hours
• Change is Embraced through Regular and Frequent Releases to
Customer: Test First Development, Refactoring to avoid Code
Degeneration and Continuous Integration of New Functionality
• Maintaining Simplicity is Supported: By constant refactoring
that improves code quality and by using simple design that do
not unnecessarily anticipate future changes to the system
Extreme Programming Principles or Practices
Following are Extreme Programming Principles and Practices:
Principle or Practice Description
Incremental Planning “Requirements” => Recorded as “User Stories”
one per “Story Card” => Prioritised => User
Stories are split into
“Development Tasks” by developers

SOFTWARE ENGINEERING AND MANAGEMENT 33

RNSIT

Small Releases “Minimal useful Set of Functionalities” that

provide “Business Value” is Developed first.
“Frequent and
Incremental Development and Release”
Simple Design Good Enough Design that is Just Sufficient to
meet the
Current Requirements
Test-First Emphasis for Unit Test Automation
Development Framework using Test Scenarios and Providing
them as the basis for Validation before
commencement of Implementation/
Coding
Refactoring Code is Continuously Refactored as and when
scope for improvement comes. Also, keep the
Code Simple and
Maintainable
Paired Programming Developers work in Pairs. Check each others
Code and Provide Inputs and Expertise to
Improve Upon Each other‟s Code
Collective Ownership All Stake Holders including Customer,
Developer, Tester, and any other role will
seamlessly interact and exchange with no bar
on their role by taking collective
Ownership and Accountability
Continuous As soon as the work in the task is complete
Integration then it is integrated into whole system. After
any such Integration all the Unit Test in the
System must Pass
Sustainable Pace Team is not over stretched so as to work extra
hours. This would enhance Code Quality and
Productivity since team works with higher
motivational levels and lesser stress.

On-site Customer Representative of End-User of the System and

Customer shall Involve, Engage, and
Constructively Criticise and also, define &
prioritise requirements

SOFTWARE ENGINEERING AND MANAGEMENT 34

RNSIT

Extreme Programming Process

Life Cycle of XP include a lightweight process targeted towards
engineering teams and also focused on adaptive to changes.
XP works out very effectively for small and medium sized project
teams, i.e., 3-20 members. To make XP to work effectively,
communication between development and testing team shall be
enabled all the time.

Fig 3.3 Steps in EP Process

Extreme Programming (XP) uses paired programming concept.
Paired Programming and Refactoring
Extreme Programming (XP) uses paired programming concept. In
Paired Programming, The coding is usually done in pairs where two
programmers periodically switch roles. The pairs also change often.
The code review happens continuously. The pairs are determined
while iteration planning. This ensures
• Higher quality code

SOFTWARE ENGINEERING AND MANAGEMENT 35

RNSIT

• Continuous cross training happening

• Improves team communication.
Paired Programming will be effective when used with “Refactoring”.
When each iteration is in progress towards small release, there can be
request for changes or revisions to user stories. To address these
changes or revisions
▪ Code is refactored, means, in case the developed code needs
some changes the same will be done.
▪ Also, changes will be carried out on test cases as well to align
with these changes.
▪ This cycle continues until the module is developed
2.4 Review Phase
In review phase, we carry put following activities:
• Refactoring is used to Review and Improve Code and to Keep
Code healthy
• When each iteration is in progress towards small release, there
can be request for changes or revisions to user stories.
• To address these changes or revisions
– code is refactored, means, in case the developed code needs
some changes the same will be done.
– Also, changes will be carried out on test cases as well to align
with these changes.
– This cycle continues until the module is developed
Stage 3: Project Closure
Continuous Integration and Acceptance Tests by involving Customers
is the basis
• Customers are responsible for verifying the correctness of the
acceptance tests and reviewing test scores to decide which failed
tests are of highest priority.
• Acceptance tests are also used as regression tests prior to a
production release.
• A user story is not considered complete until it has passed all
its acceptance tests.

SOFTWARE ENGINEERING AND MANAGEMENT 36

RNSIT

• The acceptance test score is published to the developer. It is the

developer‟s responsibility to schedule time in each iteration to
fix any failed tests.
• The code that passes the acceptance test is integrated with code
of other developers. Like this, final system is evolved
Now we discuss,
• 3.1 Continuous Integration and Small Releases
• 3.2 Acceptance Testing
3.1 Continuous Integration and Small Releases
The Code from each developer is regularly integrated with code of
other developers. All unit tests are then run successfully. Code is
normally integrated multiple times per day.
Acceptance tests are run daily to reduce occurrences of major
integration issues. Frequent small releases happen at the end of each
iteration.
This gives an opportunity
▪ To show case the progress to Customer more frequently.
▪ Feedbacks from the customer are then incorporated into the
subsequent iterations
3.2 Acceptance Testing
Acceptance tests are black box system tests. Customers are
responsible for verifying the correctness of the acceptance tests and
reviewing test scores to decide which failed tests are of highest
priority. Acceptance tests are indicators of the completion of a
requirement or feature. When all acceptance tests for a requirement
or feature are passing, you know you‟re done. Acceptance tests are
also used as regression tests prior to a production release. A user
story is not considered complete until it has passed all its acceptance
tests.
The acceptance test score is published to the developer. It is the
developer‟s responsibility to schedule time in each iteration to fix any
failed tests. The code that passes the acceptance test is integrated

SOFTWARE ENGINEERING AND MANAGEMENT 37

RNSIT

with code of other developers. Like this, final system is evolved. Tester
will execute all the system test cases and log the defects with respect
to that module/iteration which are fixed immediately
Advantages of SCRUM in Telecommunication Software (Ref:
Rising and Janoff) Study on Telecommunication Software developed
by using Scrum revealed following advantages:
• Advantage #1: The Product Backlog is broken down into a set of
manageable and understandable Chunks
• Advantage #2: Unstable Requirements do not hold up progress
• Advantage #3: The whole team has visibility of everything and
consequently team communication has improved
• Advantage #4: Customer see on-time delivery of increments an
gain feedback on how product works
• Advantage #5: Trust between customers and developers is
established and a positive culture is created in which everyone
expects the project to succeed

Scaling Agile Methods

Agile Methods worked conventionally very well with small and medium
sized projects, Co-located Team, and team sizes ranging from 7 to 20
members. Scaling agile to larger projects and large organizations so as
to get the advantages and benefits of this approach has gained
momentum and interest.
“Scaling Agile Methods”: Characteristics of Large Software System
Development Large Software System Development have the following
characteristics:
• #1: Geographical Distributed Teams working independently on
their Sub-system with no need to communicate with teams
working on other sub-systems. Missing whole system view, and
possible risks related to integration

SOFTWARE ENGINEERING AND MANAGEMENT 38

RNSIT

• #2: Many of them are “Brown Field Systems” with new system is
built to work by connecting with existing systems. These may
pose problems of Interoperability, portability, and immune to
change
• #3: More System Configuration and Lesser New Incremental
Development of Software
• #4: Large System Development are Bound by Stronger Processes
with No Flexibility. Hence Software Development effort is more
towards Process
Management and Compliance with Rules and Regulations
• #5: Large Systems have a diverse set of stake holders who can
not be involved in development process
“Scaling Agile Methods”: Two Perspectives
Following are two perspectives on “Scaling Agile Methods” to make it
effective for Large Software System Development
• “Scaling up” Perspective: By using Agile Methods small teams
can not develop large software system
• “Scaling out” Perspective: Concerned with how agile methods
can be introduced across a large organizations with many years
of software experience
“Scaling Agile Methods”: Adaption to Cope with Large
Systems Engineering
“It is essential to maintain the fundamentals of agile methods
characterised by Flexible Planning, Frequent System Releases,
Continuous Integration, Test Driven Development, and Good Team
Communication” (Leffingwell, 2007)
Critical Adaptions for Large Systems Development
• #1: Do not just focus on Just Enough Code and Test
simultaneously. You need to do more up-front design involving
describing critical aspects of the system, database schema, work
break down across teams, and system documentation

SOFTWARE ENGINEERING AND MANAGEMENT 39

RNSIT

• #2: Establish Cross Team Communication Mechanism by using

team structuring, by making use of more advanced
conferencing technologies, and knowledge management
• #3: Adapt Effective Configuration Management Tool with System
Configuration, System Building, Frequent Release, Change
Management, and Live Update and Replacement. Appropriate
Integration-Build-Release- Issue Management with the help of
automation of Configuration Management is very crucial.
“Scaling Agile Methods”: Difficulties in Adaption to Cope with
Large Companies Following difficulties have been observed in
adaption of agile mthods to cope with large companies:
• #1 Reluctance of Project Managers to accept Agile Approach:
Project Managers who are accustomed to Project Driven and
Process Driven Culture feel more comfort and confidence. They
are reluctant to accept challenges and risks of adapting to Agile
Approach
• #2 Matured Processes do not encourage Agile Approach:
Existing Matured Quality Management System with stable and
standard processes that are against frequent changes and
continuous adaption discourage use of agile approaches
• #3: Skill Variance and Team Attrition does not suite to Agile
Approach: Large
Companies have greater Skill Variance, have Globally
Distributed Teams, and Individuals may move to other
companies. Agile requires Uniform Skills and Capability,
Homogenous Team Culture, and Co-located Teams
• #4 Organizations with Conventional Systems Engineering
Processes are reluctant to use Agile Approaches since they have
evolved and reached stability in earnings and have ability to
cope with economic recession successfully

SOFTWARE ENGINEERING AND MANAGEMENT 40

RNSIT

"Why do we fail to get best out of Agile“: Top 6

Reasons Following are top 6 reasons for not getting
the best out of agile.
• Lack of System Thinking and Contextualization
• Difficulty in moving from “task oriented, process driven
mindset” to “solution oriented, workable product oriented
mindset”
• Complexity in ensuring seamless communication among agile
team members
• Scaling up agile to large projects is not very effective
• Confidence level of delivering the best within a given effort is
uncertain
• Decay in agile culture as team progresses
Summary
Agile Software Development is People Centric Approach. It works very
well with Small Teams, Small Projects, and Frequent Releases but
struggles to adapt to large projects and large companies. In agile,
Interactive and Constructive Communication is key to success. In
agile, User Stories, Flexible Planning, Frequent System Releases,
Continuous Integration, Test Driven Development, Test-Code-Refactor
and Good Team
Communication are key practices. Agile software development is
Design and Implementation Centric approach that encourages
frequent releases of workable product.
In agile software development, Unit Test Automation and Automation
of Configuration Management play crucial role. Agile quite effective
and customers and users increasingly like it because of its willingness
to accept changes even in late phases of development is acceptable.
Agile software development works with “Fixed Time” Approach.
However compromises with effort, budget, and requirements. Success
of agile software development depends heavily on Skills and Capability
of Team. Organizations shall take decision on whether to Adapt Agile

SOFTWARE ENGINEERING AND MANAGEMENT 41

RNSIT

Approach or not with care since it is involving tectonic shift in

organizational culture.

Module 4: Introduction to Project

Management
Software Engineering is all about producing Producing good Quality
software product that
1. Meets users needs,
2. Is highly reliable
3. Has MINIMUM number of bugs ( preferably 0 )
4. Developed in cost effective way and
5. Delivered according to planned schedules.

Term “Quality” as applied to software means different things to

different stake holders:

SOFTWARE ENGINEERING AND MANAGEMENT 42

RNSIT

Fig 4.1: Software Quality

However, we can consider Good quality software as one that meets the
user‟s needs in terms of Correctness (meets Functional
Requirements),Reliability(User can depend on it;
Operates as expected over specified time) and Robustness ( Behaves
„reasonably‟ even under „unspecified‟ circumstances).
Other important attributes are Efficiency & Performance,
Maintainability & Evolvability, Usability / reusability &I
interoperability, Understandability & Portability .
Thus we see that Software Quality is Not as “ simple and straight
forward “ as for other engineering products. It is Problematic because:
– Software specs are usually incomplete & often
inconsistent. – Some quality needs are difficult to specify
in an unambiguous way; – There is a tension between
quality requirements of :
• Customer (efficiency, reliability, etc.)
and
• Developer (maintainability, reusability, etc.);

Further It is not possible for any system to be optimized for all of

these attributes – for example, improving robustness may lead to loss
of performance. The quality plan should therefore define the most
important quality attributes for the software that is being developed.

SOFTWARE ENGINEERING AND MANAGEMENT 43

RNSIT

The plan should also include a definition of the quality assessment

process - An agreed way of assessing whether some quality, such as
maintainability /robustness, is present in the product
The focus may be „fitness for purpose‟ rather than specification
conformance.
FITNESS FOR PURPOSE is decided based on answers to questions
like:
– Has the software been properly tested?
– Is the software sufficiently dependable to be put into
use?
– Is the performance of the software acceptable for normal
use?
– Is the software usable?
– Is the software well-structured and understandable?
– Have programming and documentation standards been
followed in the development process?
Further, Quality Requirement priorities Vary from Domain to domain.
– Business Software - Data integrity, availability &
Security, Transaction Performance & Ease of use
– Web Based Software – Security, Scalability & Content
– PC Software - Ease of use & Convenience
– Real Time Systems - Precise response time, reliable &
Time-critical performance
– Embedded software - Online response with limited
resources
2. Engineering Software - Precision & Accuracy
Next question is how do we produce this quality software?. What are
the processes and steps we use to ensure that Quality software is
produced? Quality issues need to be managed at different levels to
ensure good quality software comes out. At organization level it
involves ( QA) it involves establishing a framework of processes and
standards and Continuous monitoring and validation of these
processes to make sure that they ensure quality of developed product.
At project level, it involves (QC), it involves establishing a workable

SOFTWARE ENGINEERING AND MANAGEMENT 44

RNSIT

Quality plan that sets quality goals and correct application of specific
quality processes defined in the plan and Ensuring that the project
outputs conform to the specified standards

Quality management Tasks are

• Provide an independent check on the software development
process
• Check the project deliverables to ensure that they are consistent
with organizational standards and goals
• Done by quality team that is independent from the development
team so that:
– they can take an objective view of the software without
being influenced by software development issues

Fig 4.2: Quality management Tasks

Another important issue in ensuring Quality of the software
developed is Verification & validation (V & V) .
It is nothing but Checking and analyzing products & processes
executed during & after the development , to ensure that software
being developed meets the specifications and Delivers the expected
functionality.

Verification & validation are NOT the same thing. Boehm (1979)
differentiated the two with a clear expression as follows :
1. VERIFICATION - "Are we building the product right”. (The
software should conform to its specification)

SOFTWARE ENGINEERING AND MANAGEMENT 45

RNSIT

2. VALIDATION - "Are we building the right product”. (The software

should do what the user really requires.)
V & V – Has TWO principal objectives o The discovery of defects
in a system; o The assessment of whether or not the system is
useful and useable in an operational situation
o Goal is to establish confidence that the software is fit for purpose. (
This does NOT mean completely free of defects. Rather, it must be
good enough for its intended use)
o The type of use will determine the degree of confidence that is
needed.
V & V Confidence Depends on following factors:
o Software function o The level of confidence depends on
how critical the software is to an organisation. o User
expectations o Users may have low expectations of certain kinds
of software.
o Marketing environment o Getting a product to market
early may be more important than finding defects in the
program.
V & V Process Is a whole life-cycle process applied at each stage in
the software process. Verification & validation (V & V).Starts with
requirement review and continues through design reviews, code
inspection and product testing. It is very expensive, complex,
monotonous BUT very important and critical activity that is
manpower intensive and it can never be totally automated
TWO approaches for V & V
1. Software inspections
- Concerned with analysis of the static system
representation to discover problems (static verification)
- May be supplement by tool-based document & code
analysis

SOFTWARE ENGINEERING AND MANAGEMENT 46

RNSIT

2. Software testing
- Concerned with exercising and observing product
behaviour (dynamic verification)
- The system is executed with test data and its operational
behaviour is observed

Verification & Validation techniques

1. Inspection
Inspection involves program inspections, automated source code
analysis, formal verification of programs. It can only check the
correspondence between a program & its specifications (verification). It
Cannot demonstrate the operational usefulness of the software being
developed, Nor can it check emergent properties of the software like
performance, reliability etc..
2. Testing
Testing is most widely used and main technique for V & V that
involves exercising the program with data. It can reveal the presence
of errors NOT their absence. It is the only validation technique for
non-functional requirements as the software has to be executed to see
how it behaves. It should be used in conjunction with Inspection
(static verification) to provide full V&V coverage
Testing & Debugging are Two distinct processes. While Testing is
concerned with establishing the existence of defects in a program,
Debugging is concerned with locating & repairing these errors.
Planning V & V is Very important since more than half the budget is
spent on this process in many cases. Careful planning is required to
get the most out of testing and inspection processes. It Should start
early in the development process. The plan should identify the balance
between static verification and testing. Test planning is about defining
standards for the testing process rather than describing product tests

SOFTWARE ENGINEERING AND MANAGEMENT 47

RNSIT

Test Plan ia a link between development & testing, Planning

document must contain following Details.
• The testing process.
• Requirements traceability.
• Tested items.
• Testing schedule.
• Test recording procedures.
• Hardware and software requirements.
• Constraints.

Software Inspections Involve people examining the source

representation with the aim of discovering anomalies and defects. It
may be used before implementation as there is no need for system
execution. It may be applied to any representation of the system
(requirements, design, configuration data, test data, etc.). It is shown
to be an effective technique for discovering program errors. Success
depends on the quality of people performing inspection

Software Testing involves execution of code on the machine using

test cases and test data prepared for these cases in advance. It is the
only validation technique for nonfunctional requirements as the
software has to be executed to see how it behaves. It
Should be used in conjunction with static verification to provide full
V&V coverage Objectives of testing can be stated as : o To
demonstrate to the developer and the customer that the software
meets its requirements ( Leads to validation Testing)
o To discover faults or defects in software where the behavior
is incorrect, undesirable or does not conform to its
specification (leads to verification testing)
Testing can not demonstrate that the software is free of defects or it
will behave as specified in every situation.

SOFTWARE ENGINEERING AND MANAGEMENT 48

RNSIT

“Testing can only show the presence of errors not their

absence”. Hence the goal of testing should be to convince developers
& customers that the software is ready for use

Inspection V/s Testing

• Three advantages over testing:
a. In testing, one defect ,may mask another so several
executions are required; Many different defects may be
discovered in a single inspection
b. Inspection can be performed on incomplete versions
too; But testing needs fully developed product
c. Inspection can also consider broader quality attributes
like standards compliance, programming style etc., but
testing can only look for specific functionality / bug
• BUT disadvantages of inspections are :
a. Inspection is highly dependent on the expertise and
interest of the people performing inspections
b. Inspections can check conformance with a
specification but not conformance with the customer‟s
real requirements.
c. Inspections cannot check non-functional
characteristics such as:
performance,
usability, etc The
program inspection
Process.

Program inspections are reviews, done to detect defects like logical

errors, code anomalies, non-compliance of standards etc.. in the
program. It was first developed by IBM in 70‟s and now fairly widely
used method of verification. It is carried out formally by a team of at
least 4 people. Team consists of members who represent different view

SOFTWARE ENGINEERING AND MANAGEMENT 49

RNSIT

points ( Like for example of Author of the code, testing team

representative, System expert and moderator). Inspection does not
require execution of a system; Hence done before implementation. It
may be used on any system element(doc) like Reqt. Design,
configuration data, test data,Code…. . it is shown to be an effective
technique for discovering program errors. Pre-conditions for
inspection are :
a. A precise specification must be available.
b. Team members must be familiar with the
organisation standards.
c. Syntactically correct code or other system
representations must be available.
d. An error checklist should be prepared.
e. Management must accept that inspection will
increase costs early in the software process.
f. Management should not use inspections for
staff appraisal
i.e. finding out who makes mistakes

Inspection Process (Inspection procedure)

1. System overview presented to inspection team.
2. Code and associated documents like checklists are
distributed to inspection team in advance.
3. Inspection takes place and discovered errors are noted.
4. Modifications are made to repair discovered errors.
5. Re-inspection may or may not be required.

SOFTWARE ENGINEERING AND MANAGEMENT 50

RNSIT

Fig 4.3: Inspection Process

Inspection Checklists are commonly used tool in Inspection. It

Contains a list of common errors should be used to drive the
inspection. It is Dependent on programming language and reflects the
characteristic errors that are likely to arise in the language. In
general, the 'weaker' the type checking, the larger the checklist.
Examples: Initialisation, Constant naming, loop termination, array
bounds, etc.

SOFTWARE ENGINEERING AND MANAGEMENT 51

RNSIT

Inspection – some remarks : Inspecting 500 lines costs about 40

man/hours effort; (hence it turns out to be less expensive than
testing). Since program inspection is a public process of error
detection, management needs to be sensitive. As organization gain
experience of the inspection process, the process improvements can
be attempted. Collection of data on types of errors can lead to process
modifications that can cut errors at source

Static Analysis – is a process of examining a program to discover

errors WITHOUT executing it (The essence of inspection ) . ItCan be
automated for some standard common errors resulting in STATIC
ANALYZERS - Software tools that scan & parse the text of a program
and detect possible faults and anomalies. It Can detect Whether the
statement has been well formed. It Can do control flow analysis &
even compute the data set needed to test the program. It
Complements the error detection facilities of a compiler and serves as
an effective V & V aid supplementing inspection. Automate static
analysis includes Control Flow analysis, Data use Analysis, Interface
analysis, Information flow analysis and Path analysis

Another Quality Assurance technique is IMPOSITION OF

STANDARDS. Software standards are something set up and
established by an authority as a rule or norm for the measure of
quantity, functionality, value, or quality. Standardization is the wide
use of components, parts, procedures, or processes in which there is
regularity, repetition, and a successful practice and predictability.
Standards Define the required attributes of a product / process that
play an important role in quality management. Standards may be
International, National, or organizational or Project standards
WHY USE STANDARDS? It avoids repetition of past mistakes,
encapsulates best practices, and pProvides framework for defining

SOFTWARE ENGINEERING AND MANAGEMENT 52

RNSIT

what quality means in a particular setting i.e. that organization‟s view

of quality.Further, it provides continuity by making it easy for new
staff to understand the organisation by understanding the standards
that are used.

Product and Process Standards

Product standards apply to the software product being developed.
They Include document standards, such as the structure of
requirements documents, documentation standards, such as a
standard comment header for an object class definition, & coding
standards, defining the use of a programming language in coding
Process standards define the processes to be followed during software
development. It may include definitions of specification, design and
validation processes,process support tools and a description of the
documents that should be written during these processes
Steps involved in Development of Standards are : Involving
practitioners in development. Engineers should understand the
rationale underlying a standard. Standards and their usage need to be
reviewed regularly. Standards can quickly become outdated and this
reduces their credibility amongst practitioners. Also theremust be
specialized tool support. Excessive clerical work is the most significant
complaint against standards. Web-based forms are not good enough
Standardization has three Drawbacks :
1. Soon become more of document filling ritual
2. Need some automation tools; otherwise consumes too much
time in filling forms
3. Needs constant revision; otherwise engineers fell it is irrelevant
and just a ritual

ISO 9000 Standards framework : Provides An international set of

standards to be used as a basis for developing quality management
systems. It Applies to organizations that design, develop and maintain

SOFTWARE ENGINEERING AND MANAGEMENT 53

RNSIT

products, including software. It is a framework for developing software

standards. It Sets out general quality principles, Describes quality
processes in general and Lays out the organizational standards and
procedures that should be defined . These should be documented in
an organizational quality manual

ISO 9001 & Quality Management

Fig 4.4: ISO 9001 & Quality management

ISO 9001 Limitations

The ISO 9001 certification is inadequate because it defines quality to
be the conformance to standards.It takes no account of quality as
experienced by users of the software. For example: A company could
define test coverage standards specifying that all methods in objects
must be called at least once. This standard can be met by incomplete
software testing that does not include tests with different method

SOFTWARE ENGINEERING AND MANAGEMENT 54

RNSIT

parameters. But as long as the defined testing procedures are followed

and test records maintained, the company is ISO 9001 certified!!! .

Testing
Testing is the Most widely used and main technique for V & V. it
Involves exercising the program with data .
TESTING Can reveal the presence of errors NOT their absence. It
is The only validation technique for non-functional requirements as
the software has to be executed to see how it behaves.It Should be
used in conjunction with static verification to provide full V&V
coverage .

Objectives of testing: is to demonstrate to the developer and the

customer that the software meets its requirements ( Leads to
validation Testing) It is two fold.
■ To discover faults or defects in software where the behavior is
incorrect, undesirable or does not conform to its specification
(leads to verification testing)
■ Testing can not demonstrate that the software is free of defects
or it will behave as specified in every situation.
“Testing can only show the presence of errors not their
absence” Hence the goal of testing should be to convince developers &
customers that the software is ready for use

SOFTWARE ENGINEERING AND MANAGEMENT 55

RNSIT

Testing Policies constrain the extent and scope of testing by

defininge approach to testing . Only exhaustive testing can show a
program is free from defects. However, exhaustive testing is
impossible, Hence we adopt Testing policies like
■ All functions accessed through menus should be
tested;
■ Combinations of functions accessed through the same
menu should be tested;
■ Where user input is required, all functions must be
tested with correct and incorrect input

Testing process

Fig 4.5: Testing process

SOFTWARE ENGINEERING AND MANAGEMENT 56

RNSIT

Testing Phases
1. Component testing is testing of individual program components; It is
usually the responsibility of the component developer (except
sometimes for critical systems); Tests are derived from the developer‟s
experience.
2. System testing is Testing of groups of components integrated to create
a system or subsystem; Independent testing team takes up this
responsibility and Tests are based on a system specification.

Testing individual functions / methods aresimplest. Tests are

nothing but a set of calls to these methods with different set of
parameters : Right values , Wrong value, Border values and Various
combination of right, wrong and border values. Results are matched
with expected results.

Component testing is the process of testing individual components

in isolation. It is a defect testing process meant to discover errors
Components may be:
o Individual functions or methods within an
object; o Object classes with several attributes and
methods; o Composite components with defined
interfaces used to access their functionality
– Developers of the component are responsible for this
testing Complete test coverage of a class involves
Testing all operations associated with an object;
Setting and interrogating all object attributes; and
Exercising the object in all possible states.

Inheritance makes testing all the more difficult: When a super-class

provides operations that are inherited by the sub-classes, All of these
subclasses must be tested with All inherited operations using All
parameters used by these methods because Subclass may make

SOFTWARE ENGINEERING AND MANAGEMENT 57

RNSIT

certain presumptions about other operations & attributes / Method

may be overridden in sub-class

Composite component testing - Composite components are made

up of a several interacting objects, whose functionality is tested
basically through the interfaces these objects expose to the external
world, Hence testing composite components is primarily concerned
with testing those

Interface Testing : Here the Objective is to detect faults due to

interface errors or invalid assumptions about interfaces. Different
types of interfaces to be tested are: o Parameter interfaces
 Data passed from one procedure to
another.
o Shared memory interfaces
▪ Block of memory is shared between
procedures or functions.
o Procedural interfaces
▪ Sub-system encapsulates a set of
procedures to be called by other sub-systems. o
Message passing interfaces
▪ Sub-systems request services from other
sub-systems Generally the errors can be classified
into 3 categories:
– Interface misuse o A calling component calls another
component and makes an error in its use of its
interface e.g. parameters in the wrong order.
– Interface misunderstanding o A calling component
embeds assumptions about the behaviour of the called
component which are incorrect.

SOFTWARE ENGINEERING AND MANAGEMENT 58

RNSIT

– Timing errors o The called and the calling component

operate at different speeds and out-of-date information
is accessed
Guidelines for interface testing o Design tests so that parameters to
a called procedure are at the extreme ends of their
ranges
o Always test pointer parameters with null
pointers o Design tests which cause the
component to fail o Use stress testing in message
passing systems o In shared memory systems,
vary the order in which components are
activated.

Test Case Design Involves designing the test cases (inputs and
outputs) used to test the system. The goal of test case design is to
create a set of tests that are effective in validation and defect testing
such that it Throw up maximum errors with minimum number of test
cases. Design approaches generally considered are :
o Requirements-based testing; o Partition testing;
o Structural testing.
Approach – 1 Requirements-based Testing is a general principle of
requirements engineering is that requirements should be testable.
Requirements-based testing is a validation testing technique where
you consider each requirement and derive a set of tests for that
requirement.

Approach 2 – Partition testing involves dividing Input data and

output results of a program often fall into different classes that have
common characteristics such as: Positive numbers, Negative
numbers, Menu selections etc... Each of these classes is an
equivalence partition or domain where the program behaves in an

SOFTWARE ENGINEERING AND MANAGEMENT 59

RNSIT

equivalent way for each class member. Test cases should be chosen
from each partition.
Input partitions for search routine
– Test software with sequences which have only a single
value.
– Use sequences of different sizes in different tests.
– Derive tests so that the First, Middle and Last
elements of the sequence are accessed.
– Test with key element NOT in the sequence

Approach 3 – Structural testing is an approach where test cases are

derived from the knowledge of the software‟s structure &
implementation it is also known as white-box / glass-box / clear-box
testing. Objective is to exercise all program statements, not all path
combinations

Testing is an expensive process phase. Hence automation is

necessary to reduce time and cost. Testing workbenches provide a
range of tools to reduce the time required and total testing costs.
Systems such as Junit support the automatic execution of tests. Most
testing workbenches are open systems because testing needs are
organisation-specific.
They are sometimes difficult to integrate with closed design and
analysis workbenches.

Software project management

Software project management is an essential part of Software
engineering, Concerned with activities involved in ensuring that
software is delivered on time and within budget estimates in
accordance with the requirements of the organisations developing and
procuring the software. This is very essential because all projects have
budget and time constraints to be met.

SOFTWARE ENGINEERING AND MANAGEMENT 60

RNSIT

Many techniques of engineering project management are equally

applicable to software project management.
Technically complex engineering systems tend to suffer from the same
problems as software systems. But there are Features unique to
software projects like:
1. The product is intangible and uniquely flexible
2. Software engineering is not yet matured like other
engineering discipline like mechanical, electrical engineering,
etc.
3. The software development process is not standardised.
4. Many software projects are 'one-off' projects.

Though Software project management varies from organization to

organizations, It basically involves activities like:
1. Proposal Planning.
2. Project planning and scheduling.
3. Project monitoring and reviews.
4. Project costing.
5. Risk Management

Proposal Writing: Most projects start with this activity to get

management approval for starting a project.
The Proposal describes, The objectives of the project, How the project
will be carried out, thePrice and schedule estimates . It is a A critical
task that needs good skills that can be developed ONLY through
practice and experience. No guidelines can be set for this task.
An important aspect of this exercise is to come up with cost / price for
the project. It involves Project pricing involves estimating how much
the software will cost to develop, taking factors such as staff costs,
hardware costs, software costs, etc. into account.
Though pricing is based on estimates, There is NO SIMPLE
RELATIONSHIP between development cost and the price charged to

SOFTWARE ENGINEERING AND MANAGEMENT 61

RNSIT

the customer. Broader organizational, economic, political and

business considerations influence the price charged.

Factors affecting software pricing

Pricing Strategies :
1. Under- pricing – (Quoting below the normal price) is done at times
to gain a contract and keep staff busy & retain them for future
opportunities OR to get entry to new market area.
2. Over Pricing - (Quoting above the normal price) is done at times to
cover high risks involved in fixed price contracts.

SOFTWARE ENGINEERING AND MANAGEMENT 62

RNSIT

3. Pricing to win – (Priced according to what the software developer

believes the buyer is willing to pay even if this is less that the
development costs, The software functionality may be reduced
accordingly with a planto add extra functionality being added in a
later release. Additional costs may be added as the requirements
change and these may be priced at a higher level to make up the
shortfall in the original price.

Project Planning
Project Planning is the most important and probably the most
time-consuming project management activity. It is a Continuous
activity from initial concept through to system delivery. The Plan
drives the development towards the project goals. Plans must be
regularly revised as new information becomes available. Various
different types of plan may be developed to support the main software
project plan that is concerned with schedule and budget. Types of
Project Plans

Plan Description
Describes the quality procedures and
Quality plan standards that will be used in a
project.
Validation plan Describes the approach, resources
and schedule used for system
validation.
Configuration Describes the configuration
management management procedures and
plan structures to be used.
Predicts the maintenance
Maintenance requirements of the system,
maintenance costs and effort
plan required..
Describes how the skills and
Staff development plan. experience of the project team
members will be developed.

SOFTWARE ENGINEERING AND MANAGEMENT 63

RNSIT

Project Planning Process

The Project Plan sets out the resources available to the project; The
work breakdown; and a schedule for the work. The Project Plan
document should have following chapters:
1. Introduction.
2. Project organisation.
3. Risk analysis.
4. Hardware and software resource requirements.
5. Work breakdown.
6. Project schedule
7. Monitoring and reporting mechanisms.
Activities in a project should be organised to produce tangible
outputs for management to judge progress. Milestones are the
end-point of a process activity. Deliverables are project results
delivered to customers.

Project Planning Process :

SOFTWARE ENGINEERING AND MANAGEMENT 64

RNSIT

Fig 4.6: Project planning process

Project Scheduling
Project Scheduling is the task of estimating the time and resources
needed to complete the activities and organizing them into a coherent
sequence. The steps involved are:
1. Split project into tasks
2. Estimate time & resources required to complete each task
3. Organize tasks concurrently to make optimal use of
workforce
4. Minimize task dependencies to avoid delays caused by one
task waiting for another to complete
The entire exercise is dependent on Manager‟s experience dependent
on project manager‟s intuition and experience. The project
scheduling process:

Fig 4.7: Project Scheduling process

Project Activities (tasks) are the basic planning element. Each
activity has:

SOFTWARE ENGINEERING AND MANAGEMENT 65

RNSIT

• A duration in calendar days or months,

• An effort estimate, which shows the number of person-days or
person-months to complete the work,
• A deadline by which the activity should be complete,
• A defined end-point, which might be a document, the holding of
a review meeting, the successful execution of all tests, etc.

 Schedule representation is done using graphical notations.

They Show project breakdown into tasks. Tasks should not be
too small are too large (They should take about a week or two.).
Activity charts show task dependencies and
the critical path. Bar charts show schedule
against calendar time

Task duration data for example:

Activity Duration Dependencies

(days)
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)

SOFTWARE ENGINEERING AND MANAGEMENT 66

RNSIT

Corresponding BAR CHART

Fig 4.8: GANTT chart

Corresponding Activity Network:

SOFTWARE ENGINEERING AND MANAGEMENT 67

RNSIT

Fig 4.9: Activity Network

Fig 4.10: Critical Path Method Example

Staff Allocation Chart:

Fig 4.11: Staff Allocation Chart

SOFTWARE ENGINEERING AND MANAGEMENT 68

RNSIT

Project Costing and Estimation

Project Costing Involves answering following fundamental questions:
1. How much effort is required to complete an activity?
2. How much calendar time is needed to complete an
activity?
3. What is the total cost of an activity?
• Project estimation and scheduling are interleaved management
activities
• Three Parameters involved in computing the cost of software
development project
1. Hardware & Software cost ( including maintenance)
2. Travel & training costs
3. Effort costs

Costing &
Pricing : –
Costing
– The process of estimating that discovers the cost, to the
developer, of producing a software system
– Must be done objectively with the aim of producing the
accurate costs incurred during development
– Must be regularly updated once the project is underway
 Pricing
– The process of deciding the money to be charged to
customer for the software development effort
– It is NOT simply cost + profit
– Broader organisational, economic, political and business
considerations influence the price charged.

Cost Estimation Process:

• Determine size of the product.
• From the size estimate, determine the effort needed.
• From the effort estimate, determine project duration, and cost.

SOFTWARE ENGINEERING AND MANAGEMENT 69

RNSIT

Fig 4.12: Project Costing

Effort Estimation: No simple way to make an accurate estimate of
the effort required to develop a software system. Initial estimates are
based on inadequate information in a user requirements definition.
The software may run on unfamiliar computers or use new
technology. The people in the project may be unknown.
Size Estimation is very hard due to the elusive and abstract nature
of the product. Different metrics used for measuring the size of the
product and in turns the effort involved are
1. Size related measures
– Based on some output from the software process like
Lines of delivered source code (LOC), object code size ....
2. Function-related measures
– Based on an estimate of the functionality of the delivered
software like function points, object points etc.

Two types of estimation techniques that can be used:

– Experience-based techniques - The estimate is based on
the manager‟s experience of past projects and the
application domain. Essentially, the manager makes an
informed judgment of what the effort requirements are
likely to be
2. Algorithmic cost modelling

SOFTWARE ENGINEERING AND MANAGEMENT 70

RNSIT

– A formulaic approach used to compute the project effort

based on estimates of product attributes, Such as size,
using process characteristics, like experience of staff
involved etc.

Experience-based approaches rely on judgments based on

experience of past projects and the effort expended in these projects.
Typically: Several experts on the proposed software development
techniques and the application domain are consulted. They each
estimate the project cost. These estimates are compared and
discussed. The estimation process iterates until an agreed estimate is
reached.
However, there is some Problem with experience-based approaches.
New software project may not have much in common with previous
projects. Software development changes very quickly. New projects
often use unfamiliar techniques such as web services, application
system configuration or HTML5. Hence, previous experience may not
help you to estimate the effort required.

Algorithmic cost modelling Cost is estimated as a mathematical

function of product, project and process attributes whose values are
estimated by project managers: Effort =
A ´ SizeB ´ M
A is an organisation-dependent constant, B reflects the
disproportionate effort for large projects and M, a multiplier reflecting
product, process & people attributes. The most commonly used
product attribute is code size. Most models are similar but they use
different values for A, B and M.

Estimation Accuracy Estimation depends on size of the software. The

size of a software system can only be known accurately when it is
finished. Several factors influence the final size. Use of reused systems

SOFTWARE ENGINEERING AND MANAGEMENT 71

RNSIT

and components; Programming language; Distribution of system etc...

.As the development process progresses then the size estimate
becomes more accurate. The estimates of the factors contributing to B
and M are subjective and vary according to the judgment of the
estimator

Effectiveness of algorithmic models Algorithmic models are a

systematic way to estimate the effort required to develop a system.
However, they are complex and difficult to use because of many
attributes and considerable scope for uncertainty in estimating their
values. The practical application of algorithmic cost modelling has
been limited to a relatively small number of large companies, mostly
working in defence and aerospace systems engineering.

COCOMO Cost Modelling is an empirical model based on project

experience. It is a
Well-documented, „independent‟ model which is not tied to a specific
software vendor. It has a Long history from initial version published in
1981 (COCOMO-81) through various instantiations to COCOMO 2.
COCOMO 2 takes into account different approaches to software
development, reuse, etc.

COCOMO 2 GROUP of Models Incorporates a range of sub-models

that produce increasingly detailed software estimates. The sub-models
in COCOMO 2 are:
1. Application composition model.
-Used when software is composed from existing parts.
2. Early design model.
-Used when requirements are available but design has
not yet started.
3. Reuse model.
-Used to compute the effort of integrating reusable
components.

SOFTWARE ENGINEERING AND MANAGEMENT 72

RNSIT

4. Post-architecture model.
-Used once the system architecture has been designed
and more information about the system is available

Fig 4.13: COCOMO 2 GROUP of Models

Staffing requirements
Staff required can‟t be computed by dividing the development time by
the required schedule. The number of people working on a project
varies depending on the phase of the project. The more people who
work on the project, the more total effort is usually required. A very
rapid build-up of people often correlates with schedule slippage.
Project duration and staffing
Apart from effort estimation, managers must estimate the calendar
time required to complete a project and when staff will be required.
COCOMO 2 formula for calendar time estimation is
TDEV = 3 ´ (PM)(0.33+0.2*(B-1.01)) Where
PM is the effort computation and
B is the exponent computed as discussed above (B is 1 for the early
prototyping model).

SOFTWARE ENGINEERING AND MANAGEMENT 73

RNSIT

This computation predicts the nominal schedule for the project.. The
time required is independent of the number of people working on the
project.

Software Metrics
Software metric is A standard of measure of a degree to which a
software system or process possesses some property. Example : Lines
of code in a program, number of persondays required to develop a
component etc.. Metric can be used to quantify intangible qualities of
software product & process. Metric may also be used to predict
product attributes or to control the software process. Product metrics
can be used for general predictions or to identify anomalous
components.

Examples of Process metric:

1. The time taken for a particular process to be completed - can be the
total time devoted to the process, calendar time, or the time spent on
the process by particular engineers …. 2. The resources required for a
particular process - might include total effort in persondays, travel
costs, or computer resources.
3. The number of occurrences of a particular event - like: the number
of defects discovered during code inspection, the number of
requirements changes requested, the number of bug reports in a
delivered system & av. nbr of LOC modified in response to a
requirement change etc..

The computation and use of metric is based on the assumptions that

:
• A software property can be measured accurately
• The relationship exists between what we can
• measure and what we want to know

SOFTWARE ENGINEERING AND MANAGEMENT 74

RNSIT

• We can only measure internal attributes but are often more

interested in external software attributes
• This relationship has been formalised and validated
– It may be difficult to relate what can be measured to
desirable external quality attributes

Metric Measurement process:

SOFTWARE ENGINEERING AND MANAGEMENT 75

RNSIT

Fig 4.14: Metric measurement process Metric relationships – Internal

& External

Fig 4.15: Metric Relationships

Why metrics are not commonly used in Industry ?
• Impossible to quantify the return on investment of introducing
an organizational metrics program
• No standards for software metrics or standardized processes for
measurement and analysis
• In many companies, software processes are not standardized
and are poorly defined and controlled
• Most work on software measurement is focused on code based
metrics and plandriven development processes
• Introducing measurement adds additional overhead to
processes

Empirical Software Engineering : is a field of academic interest. It is

a A research area in which experiments on software systems and the
collection of data about real projects has been used to form and
validate hypotheses about software engineering methods and

SOFTWARE ENGINEERING AND MANAGEMENT 76

RNSIT

techniques. Software measurement and metrics are the basis of

empirical software engineering. Research on empirical software engg.,
has not had a significant impact on software engineering practice. It is
difficult to relate generic research to a project that is different from
the research study

SOFTWARE ENGINEERING AND MANAGEMENT 77