Software Engineering

INFS-334
Offered in Level-8, as College Required Course
in [CS | IT & Security | CNET] programs

Compiled by:
Dr. Wali Ullah
Recent Update: 2018-19 (1439-40 H) Spring Semester

College of Computer Science and Information Technology

Jazan University, Jazan (KSA)
1
 Lecture Notes are prepared using the Text Book prescribed in the Course Description

Editorial Director: Marcia Horton

Editor in Chief: Michael Hirsch
Acquisitions Editor: Matt Goldstein
Editorial Assistant: Chelsea Bell
Managing Editor: Jeff Holcomb
Senior Production Project Manager: Marilyn
Lloyd
Director of Marketing: Margaret Waples
Marketing Coordinator: Kathryn Ferranti
Senior Manufacturing Buyer: Carol Melville
Text Designer: Susan Raymond
Cover Art Director: Elena Sidorova
Front Cover Photograph: © Jacques
Pavlovsky/Sygma/Corbis
Interior Chapter Opener: ©
graficart.net/Alamy
Full-Service Project Management: Andrea
Stefanowicz, GGS Higher Education
Resources,
a Division of PreMedia Global, Inc.
Composition and Illustrations: GGS Higher
Education Resources, a Division of
PreMedia Global, Inc.
Printer/Binder: Edwards Brothers
Cover Printer: Lehigh-Phoenix
Color/Hagerstown

Copyright © 2011, 2006, 2005, 2001, 1996 Pearson Education, Inc., publishing as Addison-
Wesley. All rights reserved. Manufactured in the United States of America. This publication is
protected by copyright, and permission should be obtained from the publisher prior to any
prohibited reproduction, storage in retrieval system, or transmission in any form or by any
means, electronic, mechanical, photocopying, recording, or likewise. To obtain permission(s) to
use material from this work, please submit a written request to Pearson Education, Inc.,
Permissions Department, 501 Boylston Street, Suite 900, Boston, Massachusetts 02116.
Many of the designations by manufacturers and seller to distinguish their products are claimed
as trademarks. Where those designations appear in this book, and the publisher was aware of a
trademark claim, the designations have been printed in initial caps or all caps.
Library of Congress Cataloging-in-Publication Data
Somerville, IanSoftware engineering / Ian Sommerville. — 9th edition
ISBN-13: 978-0-13-703515-1

2
 Contents at a glance
Chapter Topic Page No
1 Introduction 04-09
2 Software Processes 10-23
3 Requirements Engineering 24-32
4 System Modeling 33-39
5 Architectural Design 40-44
6 Design and Implementation 45-50
7 Software Testing 51-56
8 Software Maintenance 57-63
Course Description
Software engineering is a major branch of computing science that deals with the
development of software systems as practical and cost-effective solutions for individuals
and society. This course covers the fundamentals of software engineering like software
life cycle, requirements engineering, system development paradigm, and system modeling
using UML. It also covers software verification & validation, important implementation
issues, open source development and concepts of software re-engineering. The course has
a strong technical relation with graduation project providing the opportunity to practice
software engineering knowledge, skills, and practices in a realistic development
setting with a real client.

Course Objectives
What is the main purpose for this course?
 What is software development life cycle (SDLC)
 How to elicit requirements from a client and their classification
 How to use graphical models (UML) to represent software systems
 What is an architectural design and how to object oriented design processes
 What are good coding practices
 What are various type of software testing, and where they are used
 How to modify a system after delivery
 How to draft project plan and SDLC in software documentation.

3
Chapter 1: Introduction
1. Introduction
At the first conference on software engineering in 1968, Fritz Bauer defined software engineering
as “The establishment and use of sound engineering principles in order to obtain economically
developed software that is reliable and works efficiently on real machines”.
Stephen Schach defined the same as “A discipline whose aim is the production of quality
software, software that is delivered on time, within budget, and that satisfies its requirements”.
Both the definitions are popular and acceptable to majority.
However, due to increase in cost of maintaining software, objective is now shifting to produce
quality software that is maintainable, delivered on time, within budget, and also satisfies its
requirements.

1.1 Professional software development

Software engineering is intended to support professional software development, rather than
individual programming. It includes techniques that support program specification, design, and
evolution, none of which are normally relevant for personal software development.

A professionally developed software system is often more than a single program. The system
usually consists of a number of separate programs and configuration files that are used to set up
these programs.

It may include system documentation, which describes the structure of the system; user
documentation, which explains how to use the system, and websites for users to download recent
product information.

1.2 Roll of Management in Software Development

The management of software development is heavily dependent on four factors: People, Product,
Process, and Project. Order of dependency is as shown in Fig 1.1

Software development is people centric activity. Hence success of project is on the shoulder of the
people who are involved in the development.

4
People: Software development requires good managers. The manager who can understand the
psychology of the people and provide good leadership. After having a good manager, project is in
safe hands. It is the responsibility of a manager to manage, motivate, encourage, guide and control
the people of his/her team.

Fig. 1.1

Product: What is delivered to the customer, is called a product. It may include source code,
specification document, manuals, documentation etc. Basically, it is nothing but a set of
deliverables only.

Process: Process is the way in which we produce software. It is the collection of activities that
leads to (a part of) a product. An efficient process is required to produce good quality products. If
the process is weak, the end product will undoubtedly suffer, but an obsessive over reliance on
process is also dangerous.

Project: A proper planning is required to monitor the status of development and to control the
complexity. Most of the projects are coming late with cost overruns of more than 100%. In order
to manage a successful project, we must understand what can go wrong and how to do it wright.

5
1.3 Software Products:
1.3.1 Generic products:

These systems are produced by a development organization and sold in the open market, and any
customer can buy them according to their need. For example: word processors, web browsers,
drawing packages, and project-management tools. All the mobile applications (apps) that are cab
be downloaded and used from play-stores are examples of generic products.

1.3.2 Customized (or bespoke) products:

These are the systems that are developed by a software contractor for a particular customer. For
example: Examples of this type of software include inventory managements system, content
management system, for more relevant examples JUMP system, JU e-register, JU Edugate-Portal.

1.4 Attributes of good software

Product Description
Characteristics
Software should be written in such a way that it can evolve to meet
the changed customer requirements. This is a critical attribute because
Maintainability
changing in software is quite a normal process due changing in
business environment.

Software dependability includes characteristics like reliability,

Dependability and security, and safety. Dependable software should not cause physical
Security or economical damage due to system failure. Malicious users should
not be able to access or damage the system.

Software should not make wasteful use of system resources such as

memory and processor. Efficiency therefore includes processing
Efficiency
time, and proper memory utilization to give the results in required
time.

Software must be acceptable to the type of users for which it is

Acceptability designed. This means that it must be understandable, usable, and
compatible with other systems that they use.

6
1.5 Importance of Software Engineering Practices:

1. More and more, individuals and society is relying on advanced software systems. Automation
in each and every field of life has become a necessity. To fulfill all these demands software
products are being developed that are reliable and trustworthy to its users.

2. Initial cost for any software development has remained an obstacle in the history but time has
proved that well engineered software products are cheaper in longer run than those software that
are just developed like a personal programming project.

1.6 Challenges for Software Engineering Practices

There is no universal software engineering method or technique that can be applied all types of
software products. Due to this reason software engineers have to keep in mind three general issues
that may affect different types of software:

1.6.1 Heterogeneity: Increasingly, systems are required to operate as distributed systems across
networks that include different types of computer and mobile devices. As well as running on
general-purpose computers, software may also have to execute on mobile phones. You often have
to integrate new software with older legacy systems written in different programming languages.
The challenge here is to develop techniques for building dependable software that is flexible
enough to cope with this heterogeneity.

1.6.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.

Many traditional software engineering techniques are time consuming and delivery of new systems
often takes longer than planned. They need to evolve so that the time required for software to
deliver value to its customers is reduced.

1.6.3 Security and trust: As software is intertwined with all aspects of our lives, it is essential
that we can trust that software. This is especially true for remote software systems accessed through
a web page or web service interface. We have to make sure that malicious users cannot attack our
software and that information security is maintained. Of course, these are not independent issues.

7
To address these challenges we will need new tools and techniques as well as innovative ways of
combining and using existing software engineering methods.

1.7 Software Engineering Diversity

Software engineering is a systematic approach that leads the production of software according to
nature of software. This systematic approach varies dramatically depending on type of software
and its users, as well as the people involved in the development process. In forthcoming chapters
we will learn about software engineering practices but in this chapter different types of applications
are discussed that are commonly used in different areas of life.

1.7.1. Stand-alone Applications. These are application systems that run on a local computer, such
as a PC. They include all necessary functionality and do not need to be connected to a network.
Examples of such applications are office applications on a PC, CAD programs, photo manipulation
software, etc.

1.7.2 Interactive Transaction-Based Applications. These are applications that execute on a

remote computer and that are accessed by users from their own PCs or terminals. Obviously, these
include web applications such as e-commerce applications where you can interact with a remote
system to buy goods and services.

This class of application also includes business systems, where a business provides access to its
systems through a web browser or special-purpose client program and cloud-based services, such
as mail and photo sharing. Interactive applications often incorporate a large data store that is
accessed and updated in each transaction.

1.7.3 Embedded Control Systems. These are software control systems that control and manage
hardware devices. Numerically, there are probably more embedded systems than any other type of
system. Examples of embedded systems include the software in a mobile (cell) phone, software
that controls anti-lock braking in a car, and software in a microwave oven to control the cooking
process.

1.7.4 Batch Processing Systems. These are business systems that are designed to process data in
large batches. They process large numbers of individual inputs to create corresponding outputs.
Examples of batch systems include periodic billing systems, such as phone billing systems, and
salary payment systems.

8
1.7.5 Entertainment Systems. These are systems that are primarily for personal use and which
are intended to entertain the user. Most of these systems are games of one kind or another. The
quality of the user interaction offered is the most important distinguishing characteristic of
entertainment systems.

1.7.6 Systems for Modeling and Simulation. These are systems that are developed by scientists
and engineers to model physical processes or situations, which include many, separate, interacting
objects. These are often computationally intensive and require high-performance parallel systems
for execution.

1.7.7 Data Collection Systems. These are systems that collect data from their environment using
a set of sensors and send that data to other systems for processing. The software has to interact
with sensors and often is installed in a hostile environment such as inside an engine or in a
remote location.

1.7.8 Systems of Systems. These are systems that are composed of a number of other software
systems. Some of these may be generic software products, such as a spread sheet program. Other
systems in the assembly may be specially written for that environment.

1.8 Deliverables and Milestones

Different deliverables are generated during software development. The examples are sourse code,
user manuals, operating procedure manuals etc.

The milestones are the events that are used to ascertain the status of the project. Finalization of
specification is mile stone. Completion of design document is another milestone. The milestone
are essential for project planning and management.

9
Chapter 2: Software Process
2. Software life Cycle
The goal of Software Engineering is to provide models and processes that lead to the production
of well-documented maintainable software in a manner that is predictable.
In the IEEE standard Glossary of Software Engineering Terminology, the software life cycle is:
The period of time that starts when a software product is conceived and ends when the product is
no longer available for use. The software life cycle typically includes a requirement phase, design
phase, implementation phase, test phase, installation and check out phase, operation and
maintenance phase, and sometimes retirement phase”.

These activities involve the development of software from scratch until it is delivered to customers.

2.1 Software Process Model

Software process model is a simplified representation of a software process that shows the
activities involved and their sequence. There are many well-defined process models and still latest
research is ongoing to find more and more better models. In each model number of activities and
their arrangement varies but some of the activities are common as given below:

2.1.1 Software Specification: The functionality of the software and constraints on its operation
must be defined.

2.1.2 Software Design and Implementation: The software to meet the specification must be
produced.

2.1.3 Software Validation: The software must be validated to ensure that it does what the
customer wants.

2.1.4 Software Evolution: The software must evolve to meet changing customer needs.

2.2 Types of Software Process Models

There is no ideal process model also most organizations have developed their own process models.
Selection of a process model is done according to nature of software. It also depends how much a
customer knows about his system and in how much detail he can provide the requirements of his
system. For business systems, with rapid changes a less formal and flexible model can be more

10
effective. In the section we are going to discuss some generic models that are commonly discussed
in books. But in practical life these generic models are not used as it is rather are followed as
abstract models to explain different stages of software development.

2.3 Waterfall Model

The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and there is no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development. The
waterfall Model illustrates the software development process in a linear sequential flow; hence it
is also referred to as a linear-sequential life cycle model. This means that any phase in the
development process begins only if the previous phase is complete. In waterfall model phases do
not overlap.
2.3.1 Waterfall Model Design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development is
divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the
input for the next phase sequentially.
Following figure 2.1 is a diagrammatic representation of different phases of waterfall model.

Fig 2.1: Waterfall Process Model

11
The sequential phases in Waterfall model are:
 Requirement Gathering and analysis: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification doc.

 System Design: The requirement specifications from first phase are studied in this phase and
system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.

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

 Integration and Testing: All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any faults
and failures.

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

 Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model phases do not overlap.

2.3.2 Waterfall Model Application

Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are:
12
 Requirements are very well documented, clear and fixed

 Product definition is stable

 Technology is understood and is not dynamic

 There are no ambiguous requirements

 Ample resources with required expertise are available to support the product

 The project is short

2.3.3 Waterfall Model Pros & Cons

The advantage of waterfall development is that it allows for departmentalization and control. A
schedule can be set with deadlines for each stage of development and a product can proceed
through the development process model phases one by one. Development moves from concept,
through design, implementation, testing, installation, troubleshooting, and ends up at operation
and maintenance. Each phase of development proceeds in strict order.
The disadvantage of waterfall development is that it does not allow for much reflection or revision.
Once an application is in the testing stage, it is very difficult to go back and change something that
was not well-documented or thought upon in the concept stage.
The following table lists out the Pros and Cons of Waterfall Model:
Pros Cons

 Simple and easy to understand and  No working software is produced until

use. late during the life cycle.
 Easy to manage due to the rigidity of  High amounts of risk and uncertainty.
the model – each phase has specific  Not a good model for complex and
deliverables and a review process. object-oriented projects.
 Phases are processed and completed  Poor model for long and ongoing
one at a time. projects.
 Works well for smaller projects  Not suitable for the projects where
where requirements are very well requirements are at a moderate to high
understood. risk of changing. So risk and
 Clearly defined stages. uncertainty is high with this process
 Well understood milestones. model.
 Easy to arrange tasks.  It is difficult to measure progress
within stages.

13
  Process and results are well  Cannot accommodate changing
documented. requirements.
 No working software is produced
until late in the life cycle.
 Adjusting scope during the life cycle
can end a project
 Integration is done as a "big-bang” at
the very end, which doesn't allow
identifying any technological or
business bottleneck or challenges
early.

2.4 Incremental Development Model

Incremental model use the linear sequential approach with the iterative nature of prototyping.

Incremental development is based on the idea of developing an initial implementation, delivering

it to user for comments and improving it through several versions of product releases until an
acceptable system is developed as show in Fig 2.2.

2.4.1 Incremental Model design

In incremental model the whole requirement is divided into various builds. During each iteration,
the development module goes through the requirements, design, implementation and testing
phase

Fig 2.2: Incremental Development Model

14
Each subsequent release of the module adds function to the previous release. The process continues
till the complete system is ready as per the requirement.

The key to successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those requirements
within each cycle of the model. As the software evolves through successive cycles, tests have to
be repeated and extended to verify each version of the software.

2.4.2 Incremental Model Application

Like other SDLC models, Iterative and incremental development has some specific applications
in the software industry. This model is most often used in the following scenarios:
 Requirements of the complete system are clearly defined and understood.

 Major requirements must be defined; however, some functionalities or requested

enhancements may evolve with time.

 There is a time to the market constraint.

 A new technology is being used and is being learnt by the development team while working
on the project.

 Resources with needed skill set are not available and are planned to be used on contract basis
for specific iterations.

 There are some high risk features and goals which may change in the future.

2.4.3. Incremental Model Pros and Cons

The advantage of this model is that there is a working model of the system at a very early stage of
development which makes it easier to find functional or design flaws. Finding issues at an early
stage of development enables to take corrective measures in a limited budget.

15
The disadvantage with this SDLC model is that it is applicable only to large and bulky software
development projects. This is because it is hard to break a small software system into further small
serviceable increments/modules.

The following table lists out the pros and cons of Iterative and Incremental SDLC Model:

Pros Cons

 Some working functionality can be  More resources may be required.

developed quickly and early in the life  Although cost of change is lesser but it is
cycle. not very suitable for changing
 Results are obtained early and periodically. requirements.
 Parallel development can be planned.  More management attention is required.
 Progress can be measured.  System architecture or design issues may
 Less costly to change the arise because not all requirements are
scope/requirements. gathered in the beginning of the entire life
 Testing and debugging during smaller cycle.
iteration is easy.  Defining increments may require
 Risks are identified and resolved during definition of the complete system.
iteration; and each iteration is an easily
managed milestone.  Not suitable for smaller projects.
 Easier to manage risk - High risk part is  Management complexity is more.
done first.  End of project may not be known which is
 With every increment operational product a risk.
is delivered.  Highly skilled resources are required for
 Issues, challenges & risks identified from risk analysis.
each increment can be utilized/applied to  Project’s progress is highly dependent
the next increment. upon the risk analysis phase.
 Risk analysis is better.
 It supports changing requirements.
 Initial Operating time is less.

16
  Better suited for large and mission-critical
projects.
 During life cycle software is produced
early which facilitates customer evaluation
and feedback.

2.5 Reuse-oriented Software Engineering Model:

This approach is based on the existence of a significant number of reusable components. The
system development process focuses on integrating these components into a system rather than
developing them from scratch.

In the majority of software projects, there is some software reuse. This often happens informally
when people working on the project know of designs or code that is similar to what is required.

Figure 2.3: Reuse-oriented software engineering

A general process model for reuse-based development is shown in Fig 2.3. Stages of “requirements
specification” and “system validation” are same as in other models but intermediate stages in this
model are different. They can be explained in detail as below: Component Analysis: After getting
user requirements a search is made for components to be implemented that are available in library
as it is or with small variations. Usually, there is no exact match and already available components
only provide some of the required functionality. Requirements Modification: During this stage,
the requirements are analyzed using information about the components that have been discovered.
They are then modified to reflect the available components. Where modifications are impossible,
the component analysis activity may be re-entered to search for alternative solutions.

17
System Design with Reuse: During this phase, the framework of the system is designed or an
existing framework is reused. The designers take into account the components that are reused and
organize the framework to cater for this. Some new software may have to be designed if reusable
components are not available.

Development and Integration: Software that cannot be externally procured is developed, and the
components and COTS systems are integrated to create the new system. System integration, in this
model, may be part of the development process rather than a separate activity.

2.6 Boehm’s Spiral Model

A risk-driven software process framework (the spiral model) was proposed by Boehm. Here, the
software process is represented as a spiral, rather than a sequence of activities with some
backtracking from one activity to another. Each loop in the spiral represents a phase of the software
process. Thus, the innermost loop might be concerned with system feasibility, the next loop with
requirements definition, the next loop with system design, and so on. Risks are explicitly assessed
and resolved throughout the process.

Fig 2.4: Boehm’s spiral model of the software process

18
Each loop in the spiral is split into four sectors explained as below:

Objective setting: Specific objectives for that phase of the projects are defined. Constraints on the
process and the product are identified and a detailed management plan is drawn up. Project risks
are identified. Alternative strategies, depending on these risks, may be planned.

Risk Assessment and Reduction: For each of the identified project risks, a detailed analysis is
carried out. Steps are taken to reduce the risk. For example, if there is a risk that the requirements
are inappropriate, a prototype system may be developed.

Development and Validation: After risk evaluation, a development model for the system is
chosen. For example, throwaway prototyping may be the best development approach if user
interface risks are dominant. If safety risks are the main consideration, development based on
formal transformations may be the most appropriate process, and so on. If the main identified risk
is sub-system integration, the waterfall model may be the best development model to use.

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

2.6.1 Spiral Model Application

Spiral Model is very widely used in the software industry as it is in synch with the natural
development process of any product i.e. learning with maturity and also involves minimum risk
for the customer as well as the development firms.
Following are the typical uses of Spiral model:
 When costs there is a budget constraint and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment because of potential changes to economic priorities as the
requirements change with time
 Customer is not sure of their requirements which is usually the case
 Requirements are complex and need evaluation to get clarity
 New product line which should be released in phases to get enough customer feedback
 Significant changes are expected in the product during the development cycle

19
2.6.2 Spiral Model Pros and Cons

The advantage of spiral lifecycle model is that it allows for elements of the product to be added in
when they become available or known. This assures that there is no conflict with previous
requirements and design. This method is consistent with approaches that have multiple software
builds and releases and allows for making an orderly transition to a maintenance activity. Another
positive aspect is that the spiral model forces early user involvement in the system development
effort. On the other side, it takes very strict management to complete such products and there is a
risk of running the spiral in indefinite loop. So the discipline of change and the extent of taking
change requests is very important to develop and deploy the product successfully.

The following table lists out the pros and cons of Spiral SDLC Model:

Pros Cons

 Changing requirements can be

 Management is more complex.
accommodated.
 End of project may not be known
 Allows for extensive use of prototypes
early.
 Requirements can be captured more
 Not suitable for small or low risk
accurately.
projects and could be expensive for
 Users see the system early.
small projects.
 Development can be divided into  Process is complex
smaller parts and more risky parts can
 Spiral may go indefinitely.
be developed earlier which helps better
 Large number of intermediate stages
risk management.
requires excessive documentation

20
2.7 Agile Model

Agile model is a combination of iterative and incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of working software product.

Agile Methods break the product into small incremental builds. These builds are provided in
iterations. At the end of each iteration a working product is displayed to the customer.

Agile is based on the adaptive software development methods where there is no detailed planning
and there is clarity on future tasks only in respect of what features need to be developed. There is
feature driven development and the team adapts to the changing product requirements
dynamically. The product is tested very frequently, through the release iterations, minimizing the
risk of any major failures in future.

Customer interaction is the backbone of Agile methodology, and open communication with
minimum documentation are the typical features of Agile development environment. The agile
teams work in close collaboration with each other and are most often located in the same
geographical location.

Fig 2.5: Graphical Illustration of the Agile Model

21
2.7.1 Agile Manifesto Principles

Individuals and interactions: In agile development, self-organization and motivation are

important, as are interactions like co-location and pair programming.

Working software: Demo working software is considered the best means of communication with
the customer to understand their requirement, instead of just depending on documentation.

Customer collaboration: As the requirements cannot be gathered completely in the beginning of

the project due to various factors, continuous customer interaction is very important to get proper
product requirements.

Responding to change: Agile development is focused on quick responses to change and

continuous development.

2.7.2 Agile Model Pros and Cons

Agile methods are being widely accepted in the software world recently, however, this method
may not always be suitable for all products. Here are some pros and cons of the agile model.

Following table lists out the pros and cons of Agile Model

Pros Cons

 Is a very realistic approach to software  Not suitable for handling complex

development. dependencies.
 Promotes teamwork and cross training.  More risk of sustainability,
 Functionality can be developed rapidly maintainability and extensibility.
and demonstrated.  An overall plan, an agile leader and
 Resource requirements are minimum. agile PM practice is a must without
 Suitable for fixed or changing which it will not work.
requirements.  Strict delivery management dictates the
 Delivers early partial working solutions. scope, functionality to be delivered, and
 Good model for environments that adjustments to meet the deadlines.
change steadily.  Depends heavily on customer
interaction, so if customer is not clear,

22
 Minimal rules, documentation easily team can be driven in the wrong
employed. direction.
 Enables concurrent development and  There is very high individual
delivery within an overall planned dependency, since there is minimum
context. documentation generated.
 Little or no planning required.  Transfer of technology to new team
 Easy to manage. members may be quite challenging due

 Gives flexibility to developers. to lack of documentation.

23
Chapter 3: Requirements Engineering

3. Requirements Engineering

Requirements describe the “what” of a system, not the “how”. Requirements engineering produces
one large document, written in natural language, contains a description of what the system will do
without describing how it will do. The input to the requirements engineering is the problem
statement prepared by the customer.
3.1 Crucial process steps of Requirement Engineering

The quality of a software product is only as god as the process that creates. Requirements
engineering is one of the most crucial activity in this creation process. Without well-written
requirements specifications, developers do not know what to build, customers do not know what
to expect, and there is no way to validate that the built system satisfies the requirements.
The requirements engineering consists of four steps as shown in figure 3.1

Problem Statement

Requirement
elicitation

Requirement
Requirement
analysis
engineering

Requirement
documentation

Requirement
review

SRS

Fig. 3.1: Crucial process steps of requirement engineering

24
1) Requirements elicitation: This is also known as gathering of requirements. Here requirements
are identified with the help of customer and existing systems process if available.

2) Requirements analysis: The requirements are analyzed in order to identify inconsistencies,

defects, omissions, and also resolve conflicts if any.

3) Requirements documentations: It is the foundation for the design of the software. The
document is known as software requirements specification (SRS).

4) Requirements review: The. review process is carried out to improve the quality of the SRS

The primary output of requirements engineering is requirements specifications. If it describes both

hardware and software, it is a system requirements specifications. If it describes only software, it
is a software requirements specifications.

3.2 Types of Requirements

Software requirements are broadly classified as functional and non-functional requirements.

a. Functional Requirements: These are related to the expectations from the intended software.
They describe what the software has to do. They are also called product features. Sometimes,
functional requirements may also specify what the software should not do.

b. Non-Functional requirements: Non-functional requirements are mostly quality requirements

that stipulate how well the software does what it has to do. Non-functional requirements that
are especially important to the users include specifications of desired performance, availability,
reliability, usability. Non-functional requirements for developers are maintainability,
portability, and testability.

c. Non-functional Classifications

Fig 3.2: Classification of Non-Functional Requirements

25
Product requirements: These requirements specify the behavior properties of software like
performance (how fast the system executes and how much memory it requires), reliability (what
is acceptable failure rate), security and usability.

Organizational requirements: These requirements are broad system requirements derived from
policies and procedures in the customer’s organization and developer side. These requirements
include operational requirements that means how the system will be used, development
requirements specify the programming language, whereas environmental requirements specify the
operating environment of the system.

External requirements: These requirements are derived from factors external to the system and
its development process. They include regulatory requirements that mean the features that helps
in approving the system by a regulator, legislative requirements ensure that the system operates
within the law, and ethical requirements ensure that the system will be acceptable to its users and
the general public.

3.3. User and System Requirements

User requirement are written for the users and include functional and non-functional requirement.
User requirements should specify the external behavior of the system with some constraints and
quality parameters.
System requirement are derived from user requirement. They are expanded form of user
requirements.

 A measure provides a quantitative indication of the extent, amount, dimension, capacity, or

size of some attribute of the product or process”.
 Measurement is the act of determine a measure.
 The metric is a quantitative measure of the degree to which a system, component, or process
possesses a given attribute.

3.4 Categories of Metrics

i. Product metrics: describe the characteristics of the product such as size, complexity, design
features, performance, efficiency, reliability, portability, etc.

26
 ii. Process metrics: describe the effectiveness and quality of the processes that produce the
Software product. Examples are:
 Effort required in the process
 Time to produce the product
 Effectiveness of defect removal during development
 Number of defects found during testing
 Maturity of the process
iii. Project metrics: describe the project characteristics and execution. Examples are:
 Number of software developers
 Staffing pattern over the life cycle of the software
 Cost and schedule
 Productivity

3.4.1 Metrics for specifying Non-functional Requirements

Attributes Measure
Processed transactions / second
Speed
Screen refresh time
M bytes
Size
Number of ROM chips
Training time
Ease of use
Number of help frames
Mean time to failure
Reliability Probability of unavailability
Rate of failure occurrence
Time to restart after failure
Robustness Percentage of events causing failure
Probability of data corruption on failure
Percentage of target dependent statements
Portability
Number of target systems

27
3.5 Quality Attributes

There are number of quality attributes of software that can serve as requirements.

S. NO. Quality Attributes Definition

1 Correctness Extent to which program satisfies specifications, fulfills

user’s mission objectives.

2 Efficiency Amount of computing resources and code required to

perform function.

3 Flexibility Effort needed to modify operational program.

4 Interoperability Effort needed to couple one system with another.

5 Reliability Ability of a system or component to perform its required

functions under stated conditions for a specified period of
time.

6 Reusability Extent to which it can be reuse in another application.

7 Testability Effort needed to test to ensure performance as intended.

8 Usability Effort required to learn operate, prepare input, interpret

output.

9 Maintainability Effort required to locate and fix an error during operation.

10 Portability Effort needed to transfer from one hardware or software

environment to another.

11 Integrity/security Extent to which access to software or data by unauthorized

people can be controlled.

28
3.6 SRS Document

The SRS is a specification for a particular s/w product, program, or set of programs that performs
certain functions in a specific environment. The SRS serve as contract document between customer
and developer. SRS reduces the probability of the customer being disappointed with the final
product.

Nature of the SRS The basic issues of that SRS writer(s) shall address the following:

1. Functionality
2. External interface
3. Performance
4. Attributes
5. Design constraints imposed on an implementation

Characteristics of a good SRS

The SRS should be:
 Correct
 Unambiguous
 Complete
 Consistent
 Rank for importance and/ stability
 Verifiable
 Modifiable
 Traceable

29
3.6.1 Organization of the SRS
The Institute of Electrical and Electronics Engineering (IEEE) has published guidelines and
standards to organize an SRS document. Different projects may require their requirements to be
organized differently. It provides different ways of structuring the SRS. The first two sections of
the SRS are the same in all of them.

The general organization of an SRS is given in Fig. 3.3

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

2. The Overall Description

2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements

2.2 Product Functions

2.3 User Characteristics
2.4 Constraints
2.5 Assumptions for Dependencies
2.6 Apportioning of Requirements

3. Specific Requirements
3.1 External Interfaces
3.2 Functions
30
 3.3 Performance Requirements
3.4 Logical Database Requirements
3.5 Design Constraints
3.5.1 Standards Compliance
3.6 Software System Attributes
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability

3.7 Organization of Specific Requirements

3.7.1 System Mode
3.7.2 User Class
3.7.3 Objects
3.7.4 Feature
3.7.5 Stimulus
3.7.6 Response
3.7.7 Functional Hierarchy
3.8 Additional Comments.

4. Change Management Process

5. Document Approvals

6. Supporting Information

Fig. 3.3: Organization of an SRS

31
3.6.2 Problems during Requirements Elicitation

 Stakeholders don’t know what they really want.

 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting requirements.
 Organisational and political factors may influence the system requirements.
 The requirements change during the analysis process. New stakeholders may emerge and
the business environment may change.

 * Stakeholder
The term stakeholder is used to refer to anyone who may have some direct or indirect
influence on the system requirements. Stakeholder includes end-users who will interact
with the system and everyone else is an organization who will be affected by it.

32
Chapter 4: System Modeling
4. 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.

• System modeling has now come to mean representing a system using some kind of graphical
notation, which is now almost always based on notations in the Unified Modeling Language
(UML).

• System modelling helps the analyst to understand the functionality of the system and models
are used to communicate with customers.

4.1 Existing and Planned System Models

• Models of the existing system are used during requirements engineering. They help clarify
what the existing system does and can be used as a basis for discussing its strengths and
weaknesses. These then lead to requirements for the new system.

• Models of the new system are used during requirements engineering to help explain the
proposed requirements to other system stakeholders. Engineers use these models to discuss
design proposals and to document the system for implementation.

• In a model-driven engineering process, it is possible to generate a complete or partial system

implementation from the system model.

4.2 UML Diagram Types:

Activity diagram: that show the activities involved in a process or in data processing.

Use case diagram: that shows the interactions between a system and its environment.

Sequence diagram: that shows interactions between actors and the system and between system
components.

Class diagrams: that shows the object classes in the system and the associations between these
classes.

State diagrams: that shows how the system reacts to internal and external events.

33
4.3 Use of Graphical Models

 Context Model: in this model, context diagram and activity diagram is used.
 Interaction Model: in this model, use-case diagram and sequence diagram is used.
 Structural Model: in this model, class diagram and object diagram is used.

4.3.1 Context Model:

 Context model is used to illustrate the operational context of a system - they show what
lies outside the system boundaries.
 Social and organisational concerns may affect the decision on where to position system
boundaries.
 Architectural models show the system and its relationship with other systems.

Fig 4.1: Context Diagram for specifying JUMP system boundaries

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
34
by a filled circle inside another circle. Rectangles with round corners represent activities, that is,
the specific sub-processes that must be carried out. You may include objects in activity charts.
UML activity diagrams are used to define major business process models.

Fig 4.2: UML activity diagram for inventory system

4.3.2 Interaction Model

 By modeling user interactions with the system helps in identifying user requirements.

 By modeling system-to-system interaction identify communication problems that may arise.

 By modeling the interaction between components helps in understanding that proposed system
will meet required performance and dependability.

4.3.2.1 Use Case Modeling

 Use cases were developed originally to support requirements elicitation and later incorporated
into the UML diagrams.

 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.

35
 Fig 4.3: Use-case diagram for ATM

Use case diagrams give a fairly simple overview of an interaction so you have to provide more
detail to understand what is involved. This detail can either be a simple textual description, a
structured description in a table, or a sequence diagram.

4.3.2.2 Sequence Diagrams

 Sequence diagrams are part of the UML and are used to model the interactions between
the actors and the objects within a system.

 A sequence diagram shows the sequence of interactions that take place during a particular
use case or use case instance.

 The objects and actors involved are listed along the top of the diagram, with a dotted line
drawn vertically from these.

 Interactions between objects are indicated by annotated arrows.

36
 Fig 4.3: Sequence diagram for ATM

4.3.3 Structural Models

 Structural models of software display 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 when we are discussing and designing the system
architecture.

4.3.3.1 Class Diagrams

 Class diagrams are used when developing an object-oriented system to show the
components in a system and relationship between them.

37
  Class diagram is an illustration of the relationships and source code dependencies among
classes in the Unified Modeling Language (UML).

Class Diagram Notations: UML class is represented by the diagram shown below that is divided
into three sections.

 First section is used to name the class.

 Second section is used to show the attributes / member variable of the class.

 Third section is used to describe the operations performed by the class.

Class Students {
private:
int ID;
char * Name;
public:
void Registration();
};
Types of Relationship between the classes:

1. Shows Generalization between two classes to

maintain parent-child relationship. (is-a relation)
2. Shows Aggregation between two classes to maintain
containership. (has-a relation)
3. Shows Composition between two classes to maintain
containership. (has-a relation)
4. Shows Association between two classes to maintain a
simple connectivity.

Difference between Aggregation and Composition: (Has-a Relationship)

In aggregation contained class exist even if main class is deleted. Eg: Car has Engine, If car is
broken still engine exist and can be used in another car.

In composition contained class live or die on the basis of main class. Eg: Folder has file, If you
delete a folder all files will be deleted as well.

38
Generalization: (Is-a Relationship)

Generalization is used in class diagrams to deal with most powerful concept of object orientation
that is Inheritance. Generalization is drawn between two classes to show Parent-Child relation.

In modeling systems, it is often useful to examine the classes in a system to see if there is scope
for generalization. If changes are proposed, then you do not have to look at all classes in the system
to see if they are affected by the change.

The lower-level classes are subclasses that inherit the attributes and operations from their
superclasses. These lower-level classes then add more specific attributes and operations.

Fig 4.4: Class diagram showing different type of relationships.

39
Chapter 5: Architectural Design

5. Software Architecture

High-level breakdown of a system into its parts is known as software architecture.

5.1 Architectural Design

Architectural design means how a system should be organized and designing the overall structure
of that system. According to SDLC architectural design is the first stage in the software design
process. It is the link between actual design and requirements engineering.

Fig 5.1: The architecture of a packing robot control system

5.1.1 Architectural Model Representations

 Simple, informal block diagrams showing entities and relationships are the most frequently
used method for documenting architectural models.

 But in these models do not show the types of relationships between entities and properties of
entities in the model are also not visible.

 Requirements for architectural model semantics depend on how the models are used.

40
5.1.2 Use of Architectural Models

 A high-level architectural view of a system is useful for communication with system

stakeholders and project planning. Stakeholders can relate the abstract view of the system with
requirements. They can then discuss the system as a whole without being confused in detail.
 The aim here is to produce a complete system model that shows the different components in a
system, their interfaces and their connections.

5.1.3 Architectural Design Decisions

Architectural design is a creative process so the process differs depending on the type of system
being developed.

However, a number of common decisions span all design processes and these decisions affect the
non-functional characteristics of the system.

1. Is there a generic application architecture that can act as a template for the system that is being
designed?

2. How will the system be distributed across a number of cores or processors?

3. What architectural patterns or styles might be used?

4. What will be the fundamental approach used to structure the system?

5. How will the structural components in the system be decomposed into subcomponents?

6. What strategy will be used to control the operation of the components in the system?

7. What architectural organization is best for delivering the non-functional requirements of the
system?

8. How will the architectural design be evaluated?

9. How should the architecture of the system be documented?

5.2 Architectural Views

 What views are useful when designing and documenting a system’s architecture?

 What notations should be used for describing architectural models?

 Each architectural model only shows one view or perspective of the system.

41
 It might show how a system is decomposed into modules, how the run-time processes interact
or the different ways in which system components are distributed across a network.

5.2.1 4 + 1 View Model of Software Architecture

Logical view: that shows the key abstractions in the system as objects or object classes.

Process view: that shows how, at run-time, the system is composed of interacting processes.

Development view: that shows how the software is decomposed for development.

Physical view: that shows the system hardware and how software components are distributed
across the processors in the system.

Related using use cases or scenarios (+1)

5.3 Architectural Patterns

 Patterns are a means of representing, sharing and reusing knowledge.

 An architectural pattern is a stylized description of good design practice, which has been tried
and tested in different environments.

 Patterns should include information about when they are and when they are not useful.

 Patterns may be represented using tabular and graphical descriptions.

5.4 Application Architectures

Application systems are designed to meet an organizational need. As businesses have much in
common, their application systems also tend to have a common architecture that reflects the
application requirements.

A generic application architecture is an architecture for a type of software system that may be
configured and adapted to create a system that meets specific requirements.

5.4.1 Use of Application Architectures

 As a starting point for architectural design.

 As a design checklist.

 As a way of organizing the work of the development team.

42
 As a means of assessing components for reuse.

 As a vocabulary for talking about application types.

5.4.2 Transaction Processing Systems (TPS)

TPS is a type of information system that collects, stores, modifies and retrieves the data
transactions of an organization. For Example: airline reservation systems, electronic transfer of
funds, bank account processing systems.

From a user perspective a transaction is:

 Any coherent sequence of operations that satisfies a goal.

 For example - find the times of flights from London to Paris.

Users make asynchronous requests for service which are then processed by a transaction manager.

5.4.3 Application architecture of TPS

Transaction processing systems are usually interactive systems in which users make asynchronous
requests for service. (Asynchronous means that you do not halt all other operations while waiting
for the web service call to return.) Fig 5.2 illustrates the conceptual architectural structure of TPS.
First a user makes a request to the system through an I/O processing component. The request is
processed by some application specific logic. A transaction is created and passed to a transaction
manager, which is usually embedded in the database management system. After the transaction
manager has ensured that the transaction is properly completed, it signals to the application that
processing has finished.

Fig 5.2: Architecture of TPS

43
5.4.4 Application architecture of ATM System

An example of a transaction is a customer request to withdraw money from a bank account using
an ATM. This involves getting details of the customer’s account, checking the balance, modifying
the balance by the amount withdrawn, and sending commands to the ATM to deliver the cash.
Until all of these steps have been completed, the transaction is incomplete and the customer
accounts database is not changed.

Fig 5.3: Architecture of ATM

44
Chapter 6: Design and Implementation
6. Design and Implementation

Software design and implementation is the stage in SDLC where executable software system is
developed.

Software design and implementation activities are invariably inter-leaved. Software design is a
creative activity in which you identify software components and their relationships, based on a
customer’s requirements. Implementation is the process of realizing the design as a program.

6.1 An Object-oriented Design Process

Structured object-oriented design processes involve developing a number of different system

models.

They require a lot of effort for development and maintenance of these models and, for small
systems, this may not be cost-effective.

However, for large systems developed by different groups design models are an important
communication mechanism.

6.1.1 Process Stages

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;

 Design the system architecture;

 Identify the principal system objects;

 Develop design models;

 Specify object interfaces.

6.1.2 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. (See section 4.3 in chapter 4)
45
 An interaction model is a dynamic model that shows how the system interacts with its
environment as it is used. (See section 4.3 in chapter 4)

Fig 6.1: Context Model for the Weather Station

Fig 6.2: Weather Station Use Cases

46
6.2 Implementation Issues

Software engineering includes all of the activities involved in software development from the
initial requirements of the system through to maintenance and management of the deployed
system. A critical stage of this process is, of course, system implementation, where you create an
executable version of the software.

Implementation may involve developing programs in high- or low-level programming languages

or tailoring and adapting generic, off-the-shelf systems to meet the specific requirements of an
organization.

Some aspects of implementation that are particularly important to software engineering that are
often not covered in programming texts. These are:

 Reuse
 Configuration management
 Host-target development

6.2.1 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.

 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.

6.2.1.1 Reuse Levels

The abstraction level: At this level, we don’t reuse software directly but use knowledge of
successful abstractions in the design of your software.

The object level: At this level, we directly reuse objects from a library rather than writing the code
yourself.

47
The component level: Components are collections of objects and object classes that we reuse in
application systems.

The system level: At this level, we reuse entire application systems.

6.2.2 Configuration Management

Configuration management is the name given to the general process of managing a changing
software system.

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.

6.2.2.1 Configuration Management Activities

 Version management, 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.

6.2.3 Host-Target Development

Most software is developed on one computer (the host), but runs on a separate machine (the target).
In general terms we can say development platform and an execution platform.

 A platform is more than just hardware.

 It includes the installed operating system plus 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.

48
6.3 Open Source Development

Open-source software (OSS) is computer software distributed with its source code available for
modification. The software usually includes a license for programmers to change the software in
any way they choose. They can fix bugs, improve functions, or adapt the software to suit their own
needs.

Its roots are in the Free Software Foundation (www.fsf.org), which advocates that source code
should not be proprietary but rather should always be available for users to examine and modify
as they wish.

6.3.1 Open Source Systems

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:

Apache HTTP Server (web server)

Blender (3D graphics and animation package)
GNOME (Linux desktop environment)
GNU Compiler Collection (GCC, a suite of compilation tools for C, C++, etc)
Moodle (virtual learning system)
Firefox (web browser based on Mozilla)
MySQL (database)
OpenOffice.org (office suite, including word processor, spreadsheet, and presentation software)
Perl (programming/scripting language)
Python (programming/scripting language)

6.3.2 Open Source Business

 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.
49
6.3.3 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.

50
Chapter 7: Software Testing

7 Software Testing

Testing is the process of executing a program with the intent of finding errors.

“Testing can reveal the presence of errors NOT their absence”

Why should we Test?

Although software testing is itself an expensive activity, yet launching of software without testing
may lead to cost potentially much higher than that of testing, specially in systems where human
safety is involved.

 Testing assure to the developer and the customer that the software meets its requirements.
o For custom software (be-spoke products) there should be at least one test case for every
requirement.
o For generic software products there should be tests for all of the system features, plus
combinations of these features, that will be incorporated in the product release.
 It discovers the situations where behavior of the software is incorrect, undesirable or does not
match to its specification.
 Testing identifies undesirable system behavior such as system crashes, unwanted interactions
with other systems, incorrect computations and data corruption.

Who should do the Testing?

Testing requires the developers to find errors from their software. It is difficult for software
developer to point out errors from own creations. Many organizations have made a distinction
between development and testing phase by making different people responsible for each phase.

What should we Test?

We should test the program’s responses to every possible input. It means, we should test for all
valid and invalid inputs. Suppose a program requires two 8 bit integers as inputs. Total possible
combinations are 28x28. If only one second it required to execute one set of inputs, it may take 18
hours to test all combinations. Practically, inputs are more than two and size is also more than 8

51
bits. We have also not considered invalid inputs where so many combinations are possible. Hence,
complete testing is just not possible, although, we may wish to do so.

A strategy should develop test cases for the testing of small portion of program and also test cases
for complete system or function.

7.1 Verification and Validation

Verification is the process of evaluating a system or component to determine whether the products
of a given development phase satisfy the conditions imposed at the start of that phase.

Validation is the process of evaluating a system or component during or at the end of development
process to determine whether it satisfies the specified requirements.

7.3 Stages of Testing

 Development testing

 Release testing

 User testing

7.3.1 Development Testing

Development testing includes all testing activities that are carried out by the development team.
One of the popular development testing techniques is White Box Testing (WBT) that can be
applied at the unit, integration and system levels of the testing process. (WBT is discussed
separately in section 7.5)

 Unit testing: where individual program units or object classes are tested. Unit testing should
focus on testing the functionality of objects or methods.

 Component testing: where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces.

 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.
52
7.3.2 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.

The primary goal of the release testing process is to convince the supplier of the system that it is
good enough for use.

Release testing shows that the system delivers its specified functionality, performance and
dependability, and that it does not fail during normal use.

Release testing is usually a Black Box Testing (BBT) process where tests are only derived from
the system specification. (BBT is discussed separately in section 7.4)

7.3.3 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.

User testing is essential, even when comprehensive system and release testing have been carried
out.

The reason for this is that influences from the user’s working environment have a major effect on
the reliability, performance, usability and robustness of a system. These cannot be replicated in a
testing environment.

7.3.3.1 Types of user testing

Alpha testing: Users of the software work with the development team to test the software at the
developer’s site.

Beta testing: 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.

Acceptance testing: 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, especially for custom (be-
spoke) products.

53
7.4 Black Box Testing (BBT)

Black-box testing, also called behavioral testing, focuses on the functional requirements of the
software. BBT enables the software engineer to derive sets of input conditions that will fully
exercise all functional requirements for a program. As shown in Fig7.2 BBT is concerned only
with the possible inputs and their desired output regardless of the developmental details. BBT is
performed by a separate testing team not the developer their self hence it is one type of release
testing.

Fig 7.2: Black Box Testing

There are further many types of BBT but two of the most commonly used types are as follows:

 Equivalence Partitioning
 Boundary Value Analysis
7.4.1 Equivalence Partitioning

Equivalence partitioning is a black-box testing method that divides the input domain of a program
into classes of data from which test cases can be derived.

Examples: If a code of calculator has to test using BBT then possible partitioning of input test
data are:

Test Cases Possible Valid Results Possible Invalid Results

Test case 1: 2 + 2 = ? 2+2=4 2+2=0
Test case 2: 2.52 + 4.36 = ? 2.52 + 4.36 = 6.88 2.52 + 4.36 = 6
Test case 3: ‘a’ + 345 = ? ‘a’ + 345 = error ‘a’ + 345 = 345
Test case 4: 23 – 45 = ? 23 – 45 = -22 23 – 45 = 22
Test case 5: 43 x 2.4 = ? 43 x 2.4 = 103.2 43 x 2.4 = 86
Test case 6: 10 / 0 = ? 10 / 0 = error 10 / 0 = 0
Test case 7: 45 mod 4 = ? 45 mod 4 = 1 45 mod 4 = 11

54
7.4.2 Boundary Value Analysis

Boundary value analysis enhances the performance of equivalence partitioning because it leads to
the selection of test cases at the "edges" of the class.

Examples: In boundary value analysis testing test cases are generated as shown in Fig 7.3

Fig 7.3: Boundary Value Analysis ranges

7.5 White Box Testing (WBT)

White-box testing also called glass-box testing. In WBT test cases are designed using the control
structure of the procedural design. Using white-box testing, software engineers can derive test
cases that:

 Guarantee that all independent paths within a module have been exercised at least once.
 Exercise all logical decisions on their true and false sides
 Execute all loops at their boundaries and within their operational bounds
 Exercise internal data structures to ensure their validity.

WBT can be applied at any level of development testing. (see section 7.3.1) In WBT first of all
procedure is converted into descriptive code and then using the three methods correctness of the
program code can be assured.

7.5.1 Methods used in WBT

1. The number of regions of the flow graph corresponds to the cyclomatic complexity.

2. Cyclomatic complexity, V(G), for a flow graph, G, is defined as V(G) = E - N + 2

3. Cyclomatic complexity, V(G), for a flow graph, G, is also defined as V(G) = P + 1

55
Descriptive Code:

x = 10
1
y = 10 2
while (y <= 100)
3 y=y+x
if (y <= 50) 4

print (“small”) 5
else
print (“big”) 6
end-if 7
end-while 8

Flow Graph:

1. Possible Paths

1-2-3-4-5-7-8

1-2-3-4-6-7-8

1-2-8

Total Number = 3

2. V(G) = E - N + 2 where E means edges and N means nodes

V(G) = 9 - 8 + 2 = 3

3. V(G) = P + 1 where P means number of predicate node,

where we have to take decision. In our example it is 2 that is node-2

and node-4.

V(G) = 2 + 1 = 3

As all three methods give same result it means there is no problem in the logic of procedure.

56
Chapter 8: Software Maintenance

8. Software maintenance

Modifying a program after it has been put into use.

The term is mostly used for changing custom software. Generic software products are said to
evolve to create new versions.

Maintenance does not normally involve major changes to the system’s architecture.

Changes are implemented by modifying existing components and adding new components to the
system.

8.1 Problems During Maintenance

1. Often the program is written by another person or group of persons.
2. Often the program is changed by person who did not understand it clearly.
3. Program listings are not structured.
4. High staff turnover.
5. Information gap.
6. Systems are not designed for change

8.2 Types of maintenance

There are three different types of software maintenance:

8.2.1 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.

57
8.2.2 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.

8.2.3 Functionality addition:

This type of maintenance is necessary when the system requirements change in response to
organizational or business change. The scale of the changes required to the software is often much
greater than for the other types of maintenance.

8.3 The Software Maintenance Process

Once particular maintenance objective is established, the maintenance personnel must first
understand what they are to modify. They must then modify the program to satisfy the maintenance
58
objectives. After modification, they must ensure that the modification does not affect other
portions of the program. Finally, the must test the program. These activities can be accomplished
in the four phases as shown in Fig. 81.

Fig 8.1: Software Maintenance Process

59
8.4 Maintenance costs

 Usually greater than development costs (2* to 100* depending on the application).

 Affected by both technical and non-technical factors.

 Increases as software is maintained. Maintenance corrupts the software structure so makes

further maintenance more difficult.

 Ageing software can have high support costs (e.g. old languages, compilers etc.).

8.4.1 Maintenance cost factors

Team stability: Maintenance costs are reduced if the same staff are involved with them for some
time.

Contractual responsibility: The developers of a system may have no contractual responsibility

for maintenance so there is no incentive to design for future change.

Staff skills: Maintenance staffs are often inexperienced and have limited domain knowledge.

Program age and structure: As programs age, their structure is degraded and they become harder
to understand and change.

8.5 Maintenance prediction

Maintenance prediction is concerned with assessing which parts of the system may cause problems
and have high maintenance costs.

Change acceptance depends on the maintainability of the components affected by the change.

Implementing changes degrades the system and reduces its maintainability.

Maintenance costs depend on the number of changes and costs of change depend on
maintainability.

60
 Fig 8.2: Maintenance Prediction

8.6 Software RE-Engineering

Software re-engineering is concerned with taking existing legacy systems and re-implementing
them to make them more maintainable without changing its functionality.
The critical distinction between re-engineering and new software development is the starting point
for the development as shown in Fig. 8.2.
As a part of this re-engineering process, the system may be re-documented or restructured. It may
be translated to a more modern programing language, implemented on existing hardware
technology. Thus software re-engineering allows translate source code to new language,
restructured old code, migrate to a new platform (such as client-server), capture and then
graphically display design information, and re-document poorly documented systems. The cost of
re-engineering depend on the extent of the work that is carried out. Other factors affecting costs
are: the quality of the software, tool support available, extent of data conversion, availability of
expert staff.
The alternative to re-engineering a software system is to develop that system using modern
software engineering techniques. Where systems are very badly structured this may be the only
viable option as the re-engineering costs for these systems are likely to be high.
61
 Fig. 8.3: Comparison of new software development with re-engineering

8.6.1 Advantages of reengineering

Reduced risk: There is a high risk in new software development. There may be development
problems, staffing problems and specification problems.

Reduced cost: The cost of re-engineering is often significantly less than the costs of developing
new software.

8.6.2 Reengineering process activities

Source code translation: Convert code to a new language.

Reverse engineering: Analyze the program to understand it.

Program structure improvement: Restructure automatically for understandability.

Program modularization: Reorganize the program structure.

Data reengineering: Clean-up and restructure system data.

62
8.6.3 Reengineering cost factors

 The quality of the software to be reengineered.

 The tool support available for reengineering.
 The extent of the data conversion which is required.
 The availability of expert staff for reengineering.
 This can be a problem with old systems based on technology that is no longer widely used.

63