1

CSC 501 LECTURE COURSEWARE

Course Code: CSC 501

Course Title: SOFTWARE ENGINEERING

Course Unit: 3 UNITS (2, 1, 0)

Lecturers: DR. (MRS.) J. N. ODII

DR. (MRS) C.G. ONUKWUGHA
DR. CAESAR NWANDU

CSC 501: SOFTWARE ENGINEERING (2 0 1)

Software development process models; Requirements and specifications; Design
methodologies: Objected-oriented, Component-based, knowledge-based,
Experimental, Agent-based, Formal methods, Prototyping, etc; Data, process and flow
design methodologies; Software metrics; Testing and quality assurance; Software test
automation; Software maintenance; IEEE and other software standards; SE project
management; CASE tools; Case studies and software design mini-projects for planning,
control, communication, embedded systems, Internet, and agent-based applications,
etc. Prerequisite: CIT201 or CSC204
 2

Course Description:
Software Engineering is a three credit unit course for
fifth (final) year first degree students in core computer
science discipline that intimates the students with the
concepts of Software development, process models,
requirements and specifications. It explains the design
methodologies available such as object oriented,
component-based, knowledge-based, experimental,
Agent-based, Formal methods and prototyping. The
various data, process and flow design methodologies
as applicable to software design are explored. It
exposes the students on the essence and methods of
carrying out testing, quality assurance, test automation
and maintenance on a software after design.

Course Objectives:
At the end of this course, the students should be able to answer
the following questions:

● What is Software Engineering?

● why is software development said to be an Engineering
process?
● Outline the different software design process models.
● Explain their understanding of computer models
● Differentiate between modelling and simulation.
● Explain the difference between the functional and non-
functional system requirements.
● Explain and compare the various design methodologies
visa-vis their strengths, weaknesses and areas of
applications
 3

● Discuss briefly the various Data, process and flow design

methodologies
● Compare and contrast the different Software testing metrics
● Explain how Software test automation and Software
maintenance can be achieved. What are the IEEE and other
software standards
● How can Software project be developed and managed using
some CASE tools/case studies.
● Design software mini-projects for planning, control,
communication, embedded systems, Internet, and agent-
based applications.

COURSE OUTLINE
Software Development Process Models, Software Requirements
specifications. Design Methodologies: Object oriented,
component-based, knowledge-based, experimental, Agent-based,
Formal methods, prototyping. Data process and flow design
methodologies. Software metrics: Testing and quality assurance,
Software test automation, Software maintenance; IEEE and other
software standards. Software project management CASE tools;
case studies and software design mini-projects for planning,
control, communication, embedded systems, Internet, and agent-
based applications.
Recommended Text books:
i. Software Engineering : New Age International by K.K.
Aggarwal and Yogesh Singh
ii. An Integrated Approach to Software Engineering,
second edition, by Pankaj Jalote.
iii. Software engineering by Ian Somerville.
 4

LECTURE ONE
Module 1
1.1 INTRODUCTION:
What is software Engineering and why is software
development said to be an engineering process?
As a way of introduction, it is important that we understand
what software engineering is and why software development
is likened (called) an engineering process.
● Software engineering is the establishment and use of
sound engineering principles in order to develop
software that is economical, functional, reliable and
that can work efficiently on real machines/computer
systems. (what are these engineering principles)?
● Software engineering can also be said to be the
application of a systematic, disciplined,
quantifiable approach to the development,
deployment, operation and maintenance of
software / an application
● Software development is said to be an engineering
process because it involves generic (progressive)
developmental phases (ie the engineering
principles) which start from
Requirement specification—> Design—>
Implementation--🡪Testing/Verification—

>deployment—>Documentation -🡪
Maintenance
just like any other engineering process. It is this
generic nature of software development that
makes it an engineering process is as shown in
the diagram below:
 5

Requirement/system specification: involves

determining the exact requirement of the system.
System specification is used to derive what the system
should do without saying how this is to be achieved.
Design: this involves addressing how the system is to
be implemented.

Implementation : this stage is the programming stage.

System testing: this stage is aimed at tracking bugs

Maintenance: this keeps the system updated for new

changes that need to be implemented.

Note that the main purpose of software engineering is

to reduce risk and cost.

1.2 SOFTWARE DEVELOPMENT PROCESS

MODELS
Software development process is the process of dividing
 6

software development work into distinct phases mainly:

i. To improve design,
ii. For project management,
iii. For (product) software management.

● Software development follows a development process also

known as a software development life cycle (SDLC).
● The software development cycle is therefore defined as the
specific processes or procedures or steps that are
created, taken and completed by a project team in order
to develop or maintain an application.
A software “development Pprocess model" refers to a specific
process chosen
by a specific organization from many different approaches to
modeling. Hence, a software process models is one of the
software processes chosen or adjusted to give the best solution
to any project.

What is a model or what do we mean by a model in software

development?
● A software process model can be said to be an
● abstract representation of a software process.
● Modeling in a nutshell simply means the way a software
process is represented or presented.
● In science, a model is a representation of an idea, an object,
or a system that is used to describe or explain a phenomenon
that cannot be explained directly.
● Modelling can be mathematical modelling or computer
modelling.
● Computer modeling is the construction and manipulating of
abstract representation of situations or natural phenomenon
simulated with the help of computers.
● Computer models can be represented either mathematically
 7

or graphically (ie pictorially).

● Modelling is just the use of something or anything called
models to represent a system, entity, phenomenon, process
etc.
● Whereas simulation is a method/ process of implementing a
model.
● The act of simulating something first requires that a model
must be developed.
● A computer or software model can be an algorithm or the
equations used to capture the behavior of system being
modelled.
● While computer simulation is the actual running of the
program that contains these equations or algorithms.
● Simulation therefore is the process of running a model.
Models are used to predict what will happen in the system.
It helps in making alterations and quickly seeing the
outcome especially when building a prototype.

Examples software process models include:

● The waterfall model
● Prototype model
● Incremental development model
● The spiral model
● Iterative model
● The agile model
● RAD model etc

Exercise 1
1.)Outline these difference between software development
lifecycle and software development processes with specific
examples.
 8

2.)Explain the software process models above each with its

strengths and weaknesses

2.1 SOFTWARE DEVELOPMENT REQUIREMENTS

SPECIFICATIONS (SRS)
● Software (system) requirements specification (SRS) is a
documented concise description of a software system to be
developed.
● It is a document that captures the complete description
about how the system is expected to perform

● It is also known as a stakeholder requirements specification

(StRS).

● These are the requirements that the ‘user/client’ is expecting

from the programmer or software Engineer.

● It must be well thought out , balanced and clearly

understood by all involved

● Software requirements specification lists sufficient and

necessary requirements for the project development.

● To derive these requirements, the developer needs to have

clear and thorough understanding of the products to be
developed.

● This is achieved through detailed and continuous

communications with the project team and client/user
throughout the software development process.

SRS must layout the following:

● functional and non-functional requirements (what
 9

do you understand by functional and non functional

requirements?). The functional requirements
specify what the system/software should do. That is
the functions that the system is pexpected to
perform. For example: display
● names, DLepts, sex, TNU, TGP, CGPA, class of
degree etc. Give examples of other functional
●
where
L

as the non functional requirements specifies how the system

works or how the system should behave . For examples are the
system’s attributes like the response time, throughput, scalability,
utilization, reliability, maintainability, availability, usability,
security, interoperability, serviceability and other system’s
behavioral attributes
● may include a set of use cases that describe user
interactions that the software must provide. ( what
are USE CASES)
In software engineering, a USE CASE is a list of actions or steps
of events that shows or stipulates the various interactions that will
occur or occurs between a system and user (external event). It
specifies the flow of events/interactions in a system to achieve
the desired goal. It is used to identify, clarify, and organize a set
of possible sequence of interactions between a system and users
in a particular environment to achieve a particular goal.
● Software requirements specification establishes the
basis for an agreement between users and software
developer on how the software product should
function.
● It is a rigorous assessment of requirements before
the more specific system design stages,
● Its goal is to reduce later redesign.
 10

● It should also provide a realistic basis for estimating

software costs, risks, and schedules.
● When software requirements are specified
appropriately, it can help prevent software project
failure.

2.1b Qualities of SRS

● Must be correct
● Complete
● Unambiguous
● Consistent
● Verifiable
● Modifiable
● Traceable
● Stable

LECTURE MODULE 3
Software Development Methodology

What is software development methodology?

Definition: In software engineering , Software design
methodology is the sum total of the methods (tactics,
strategies, policies, devices, outline, structure, procedures,
style etc ) needed or used by software engineer in the design
of software.

That is to say:
In software engineering, software design methodology can be
● a framework
● or an approach
 11

used for the development of software application

Software Development Methodology as a Framework

What is a framework?

Framework is a kind of laid out structure for software DevOps

(Development and Operations).
Now what is DevOps?....
DevOps as used in software Engineering is a kind of combining
software development with Information technology operations so
as to shorten the system development lifecycle.

Hence we can say that software development methodology is a

framework that is used;
● to structure, plan, and control the process of developing a
software or an information system.
● Framework is a foundation or an incomplete structure
which can be extended to build an information system.
● It’s a universal reusable software environment that provides
some functionalities to facilitate the dev of a software.
● It may include code libraries, compilers, other tools needed
in software development process.
● It is a kind of scaffold / platform for developing software
products.
● It streamlines the software development such that
programmers don’t have to write all codes each time.
● is used to express, show, or describe the structure, plan, and
control the process of developing an information system .
● It is a kind of loose but incomplete structure which still
gives room for other practices and tools needed to develop
a software. That is it can be extended to develop a software
product.
 12

● Examples of software frameworks include: waterfall, spiral

, prototype methodologies.

Sof
tware Development Methodology as an Approach

Software development methodology may also refer to the

approach used or applied in order to actualize an information
system. This approach applied here is also called software
Development Life Cycle (SDLC). In general software
methodology approaches include:

● SDM (System Development Methodology)

● Structured Systems Analysis and Design

Methodology (SSADM)

● Information Requirement Analysis/Soft systems

methodology

● Object Oriented and Design Methodology (OODM)

● Rapid Application Development (RAD)

 13

● Dynamic Systems Development Methodology (DSDM)

● Scrum

● Component-based methodology
● knowledge-based methodology
● Experimental methodology
● Agent-based methodology
● Formal methods
● Prototyping
● Extreme programming

Hence, software development approaches that have been used

since the origin of information technology are broadly
classified into two as given below:

● Traditional Software development methodology

approach

● Agile methodology approach ( popularly called Agile

manifesto)

Traditional Software Development Methodology:

The traditional software development methodology or the oldest
formalized software methodology approach for
building information systems. The main idea of the SDLC has
been "to pursue the development of information systems in a
 14

very deliberate, structured and methodical way (cycle) requiring

each stage of the life cycle from inception of the idea to delivery
of the final system to be carried out rigidly and sequentially.
Examples are:

● Waterfall: a linear framework

● Spiral: a combined linear-iterative framework
● Incremental: a combined linear-iterative framework or
V Model
● Prototyping: an iterative framework
● Rapid application development (RAD): an iterative
framework

The traditional methodologies use linear approach where

the stages of the software development process must be
completed in a sequential order. This means one stage
must be completed before the next one begins.

The Agile methodology Approach

Agile is an umbrella term for several iterative and incremental
software development approaches, where each of the variations
can be on its own. This is called the Agile Manifesto, and was
formulated in 2001. It uses iterative and team based approach.
The main objective of Agile methodology is to

● quickly deliver the application that has complete and

 15

functional components.

● That instead of completing software development in a

sequential order, they are developed in bits called sprints.

● It takes an average of four weeks to complete a sprint.

Different stages of software development life cycle can be
revisited when need arises.
Examples of Agile approach to software development involve
the following stages: project initiation, sprint planning and
demos.

Examples of methodologies under Agile manifesto are but not

limited to:

● Scrum
● Extreme programming
● Adaptive Software Development (ASD)
● Dynamic System Development Method (DSDM)

The Traditional Software Methodology vs the Agile

Methodology.
The major difference between the two approaches is in the
sequence of phases taken to complete software project.
● The traditional uses a linear approach while Agile uses an
iterative and team based approach.
● Instead of developing task in sequence the Agile complete
in sprints usually within one to four weeks.
 16

● The traditional is rigid while agile is flexible

● This means making unplanned changes in the software is
costlier while in agile changes can easily be made even
after the project has be completed.
● The traditional method show details of entire project
before the project starts.
● The traditional only involve customers at the early stage of
the software dev, may be during requirement specification
and will only see the software again at completion.
● But in agile methodology customers are highly involved in
every stage and can make suggestions for improvement.
● The traditional is highly documented but not so with agile
due quick time delivery.

Factors to Consider in Choice of Software Development

Methodology
There are a number of things to consider:
● Schedule Time/ Speed needed to complete the project
● Size of the project
● Cost/ Fund /resources available.
● Level of collaboration and interaction that exist among the
software project team
● Quality of product needed.

Hence we can say that;

● Whenever time is a constraint….Agile should be an option
● This is because Agile allows you to quickly release a
product which you can later modify to add more features.
● Now with limited resources too…Agile comes to mind.
● Agile works best if we need a basic software to keep your
 17

business running and going.

● Agile provides more benefits for start ups.
● Agile also fits in for small to medium size applications.
● More customer involvement changes are constantly made to
the application and as such gives a better quality.

On the other hand:

● For large enterprise projects… Consider traditional
methodology.
● Here the specification and requirements must be clearly
specified or defined before the project begins.
● Also…. when the project team (software developers, tester,
vendors, designers, customers) are not in staying together in
a place Agile become difficult… hence traditional is an
option.
Assignment:
1. What is the difference btw software life cycle, a
software development process, software process
model software development method.
2. What is software DevOps and their significance in
software engineering…
3. What are the main phases and activities during each of
the software life cycle
4. What are the elements of a software development process
5. What are the characteristics a good software
development process

Note:
A good software project should be developed on time , within
budget and to the satisfaction of the customers irrespective of the
approach.
In the course of this lecture we are to consider the following
methodologies:
i) Object oriented methodology
ii) Component-based methodology
 18

iii) knowledge-based methodology

iv) Experimental methodology
v) Agent-based methodology
vi) Formal methods,
vii) prototyping

4.0 Lecture 4: Module One

4.1 Object Oriented and Design Methodology

Object oriented methodology is an approach to building
applications/systems by using the object oriented paradigm
throughout the entire software development life cycle.
Questions: i). what is object in this context
ii) why the term object oriented paradigm?
iii What is object oriented paradigm?:

Objects in this context are real life things like cars, humans, trees
houses etc.
Paradigm means a model, example, architype, prototype of
something
Object oriented paradigm therefore means modelling based on
objects only
In OOP ,the following terms are frequently used:
● properties
● methods
● events
● classes
● instances
 19

These Objects are known to possess some attributes/

characteristics size, shape, color, height, and these are called
properties”
“Methods” are procedures used to modify the
objects.(e.g., drive, stop, start ,an object such as car)
Events are the actions taken on the system to carryout the
methods. e.g., Clicking , double Clicking the Mouse
Classes are like a group name for group of objects, a particular
structure for representing a particular group of objects.

Eg,

“ A class thus is a blueprint or prototype , that

defines the variables and the methods common to
all objects of that class. A class can define types of
operations, or methods, that can be performed on an object. For
example, the car class might specify an accelerate( method)
which would update the speed ( attribute )of the car object. A
 20

class is therefore used in organizing data into different data types so a

programmer can reuse elements when making multiple instances of that data
type

Instances depict the different types of classes

In the above image, there are three instances: polo, mini , and
beetle .

In object Oriented Methodology (OOM), we have

Object Oriented Design (OOD) --- used for design
Object Oriented Analysis (OOA) ----- used for analysis
Hence combining both the design and analysis phases we have
what we call Object Oriented Analysis and Design Methodology
(OOADM).
Characteristics of OODM:
● It is an iterative and incremental software
development process
● It encourages and facilitates the re-use of software
components.
● Ensuring higher productivity,
● lower maintenance cost
● and better quality software product.
● It employs international unified modeling language
(UML) from the object management group. UML is
the widely accepted language for OOA and OOD.

Software development using Object oriented methodology

undergoes six phases namely:
i) planning stage
ii) architecture definition stage
iii) technical architecture definition stage
iv) the incremental delivery planning stage
v) the incremental design and build stage
vi) the deployment stage.
 21

Object oriented methodology, is developed on a component basis

by sharing of its other system components.
The Oriented Methodology gives the software engineer the
opportunity to determine the followings:
● What the objects of the system are
● What responsibilities and relationships an object has
with the other objects
● How these objects behave over time

Objectives of Object Oriented Methodologies

The objectives object oriented methodology include but not
limited to the following:
● To encourage greater re-use of software components
● To produce a more detailed specification of system
constraints.
● To have fewer problems with validation (Are we
building the right product?).

Benefits of Object Oriented Methodologies

Object oriented methodology has the following benefits:
● It represents the problem domain, because it is
easier to produce and understand designs.
● It allows changes more easily.
● It provides nice structures for thinking, abstracting
and leads to modular design.
● Simplicity: The software object's model
complexity is reduced and the program structure is
very clear.
● Reusability: It is a desired goal of all development
process. It contains both data and functions which
act on data. It makes easy to reuse the code in a new
 22

system. Messages provide a predefined interface to

an object's data and functionality.
● Increased Quality: This feature of increase in
quality is largely a by-product of this program
reuse.
● Maintainable: The OOP method makes code more
maintainable. The objects can be maintained
separately, making locating and fixing problems
easier.
● Scalable: The object oriented applications are more
scalable than structured approach. It makes easy to
replace the old and aging code with faster
algorithms and newer technology.
● Modularity: The OOD systems are easier to
modify. It can be altered in fundamental ways
without ever breaking up since changes are neatly
encapsulated.
● Modifiability: It is easy to make minor changes in
the data representation or the procedures in an
object oriented program.
● Client/Server Architecture: It involves the
transmission of messages back and forth over a
network.

Types / Generations of Object Oriented Methodologies

We have three types/ generations of Object Oriented
Methodologies

● Object Modeling Techniques (OMT)

● Object Process Methodology (OPM)
● Rational Unified Process (RUP)
 23

Object Modeling Techniques (OMT)

OMT is among the first generation object oriented methodologies
introduced as early as 1991. It uses three different models (the
object model, Dynamic model, and functional model) as shown
in the diagram below.

The main goal of the analysis is to build real world models

Using the available user requirements and developers /managers
information.

The Object Model depicts the object class and their relationships
as a class diagram, which represents the static structure of the
system. It observes all the objects as static and does not pay any
attention to their dynamic nature.

While the Dynamic Model captures the behavior of the system

over time and the flow control and events in the Event-Trace
Diagrams and State Transition Diagrams.
It portrays the changes occurring in the states of various objects
with the events that might occur in the system.
The Functional Model describes the flow of data and the changes
that occur to the data throughout the system.
 24

The Design Stage specifies all of the details needed to describe

how the system will be implemented. In this phase, the details of
the system analysis and system design are implemented. And the
objects identified in the system design phase are designed.

2. Object Process Methodology (OPM)

This is also called as second generation object oriented
methodology and was first introduced in 1995. It has only one
diagram that is the Object Process Diagram (OPD) which is used
for modeling the structure, function and behavior of the system.
It has a strong emphasis on modeling but has a weaker emphasis
on process. It consists of three main processes:
● Initiating: It determines high level requirements, the scope
of the system and the resources that will be required.
● Developing: It involves the detailed analysis, design and
implementation of the system.
● Deploying: It introduces the system to the user and
subsequent maintenance of the system.

3. Rational Unified Process (RUP)

This third generation was developed in Rational Corporation in
1998. It consists of four phases which can be broken down into
iterations.
● Inception
● Elaboration
● Construction
● Transition
Each iteration consists of nine work areas called disciplines.
A discipline depends on the phase in which the iteration is taking
place.
For each discipline, RUP defines a set of responsibilities of the
members of the development team).

In OOM we use Object Oriented Programming

 25

OBJECT ORIENTED PROGRAMMING

● Is a programming language in which pgms are organized /arranged
around data ( called objects) rather than functions and logic.
● Before now programing was seen/known as how to write logic not
how to define data (objects).
● But OOP takes a different view . OOP really/only cares about the
data (objects) it wants to manipulate rather than the logic
/computations required to manipulations
● Note in OOP, that objects are just data fields that have unique
attributes and behavior.

● And we said that examples of objects are physical entities such as

human beings ( attributes such as name, address, size etc),cats, dogs
or even houses, buildings, ( with attributes like height, colour, shape
) or computer Widgets on computer desk tops like mouse buttons,
scroll bars.
● OOp is opposed to the traditional /historical approach to
programming where emphasis is how the logic is written rather than
how to define the data within the logic.
● In oop the first task of a developer is to identify the objects and their
relationship with one another.
● Simply put , OOP is used to manipulate data fields (objects).
● Note a group of objects is called a class
● A class of objects defines the type of data it contains and the
sequence of logic ( called methods) to manipulate them.
● That is each logic sequence /procedure/ operation on any object or
class of objects is called a method.
● Examples OOP pgming languages are: Java, java script, python,
VB.Net, PHP scala, ruby.
● OOP is well suited for projects that are large, complex and are
frequently maintained or updated. It is applicable in collaborative
software development.
● Major benefits of OOP are scalability, reusability and efficiency.

Principles of OOP
 26

Oop is based on the following 4 principles:

1. Encapsulation : this principle is a kind of class self privacy. That
is each class has /maintains its own privacy from classes, other
objects outside this class have no access/ authority to interfere with
another class. But they can use make use of call list declared as
publics functions/ methods/variable. This is equally called data
hiding and provides security to the software.
As an eg in java we can hv:
Class Account{
Private int account-number;
Private int account-balance;
Public void show Data(){
//code to show data
}
Public void deposit(int a){
2. Abstraction: just like the above principle, only internal
mechanisms relevant to outsiders are revealed while hiding other
private/unnecessary implementations. That is hiding
implementation details from the user.
3. Inheritance: the concept class or data class in OOP makes it
possible to have or define subclasses of data objects that share ( ie
inherit) all or some of the characteristics of the main class. Hence
the ability of the subclasses to share some of the characteristics of
the main class is called inheritance. This principle allows the
software developer to re-use a common logic while still maintaining
a unique hierarchy. That is a relationship between two or more
classes where derived or sub classes inherits the behavior and
attributes of the existing classes. This reduces time and ensures high
level of accuracy. It is intended to help re use of existing codes with
little or no modification.
4. Polymorphism: this principle allows the software developer to
create any new data that is not already defined in the programming
language. That is to say objects can take more than one form
depending on the context. This also implies that the programmer
determines the meaning and usage of objects depending on the
context.
PROBLEMS OF OOP
● OOP is not easily understood by beginners
● OOP over emphasizes on data component of software development
and does not give enough attention to the computation or algorithm
● OOP codes are more complicated and take longer time to compile.
 27

KNOWLEDGE-BASED METHODOLOGY
What is knowledge base?
A knowledge base is just o repository or library of information
about something like product, a topic, depart,
organization…anything at all that is designed to provide self
served help… this is to free up users time which often is better
used in challenging and complex scenarios.
Knowledge based methodology or knowledge based
engineering is simply the application of knowledge based systems
technology in the design of software products.

What are knowledge based systems?

● Knowledge based systems are just computer
programs that reason and use a knowledge base to
solve complex problems.
● A knowledge base is a repository
(warehouse/storehouse) of knowledge just like we
have database.
● A knowledge base system is a technology used to store
complex structured and unstructured information used
by computer systems to solve problems.
● Knowledge based systems unlike other systems
represent the stored knowledge vividly using rules
and tools like ontologies ( means a representation or
formal naming/definitions used in defining the
categories, properties and relations between the given
concepts data or entities) rather using codes as in a
normal computer program.

Components of knowledge based system

 28

A knowledge based system comprises of three components or

subsystem namely
● The knowledge
● The user interface
● The Inference engine
Note:
Knowledge here represents real world facts / information gotten
or gathered from real world experts from the particular field of
interest. Example is collection of information in a medical field—
for collection of information in a given field -- medical diagnosis,
for example medical diagnosis.
User interface represents where the interactions between humans
and computers occur. Users query and interact with system
through this interface.
Inference engine represents logical assertions / rules and
conditions that are used for decision making. The inference
engine deduces insights from the information housed in the
knowledge base.

In Summary
● A knowledge-based systems (KBS) capture the knowledge
of human experts to support decision-making.
● They exhibit a kind of intelligence called artificial
intelligence.
● Examples of knowledge-based systems include expert
systems, which are so called because of their reliance on
human expertise.

Knowledge based methodology

In a knowledge-based system, the methodology may vary with
respect to its problem-solving method or approach.
● For example some systems encode expert knowledge as
 29

rules and are therefore referred to as rule based

methodology or rule-based systems
● Another approach, case-based reasoning, substitutes cases
for rules, hence called case based methodology or cased
based systems .Cases are essentially solutions to existing
problems that a case-based system will attempt to apply to
a new problem.

Hence, Knowledge-based systems use a rules-based or case-

based approach
Examples
● MYCIN, was an early knowledge-based system created to
help doctors diagnose diseases. Healthcare has remained an
important market for knowledge-based systems, which are
now referred to as clinical decision-support systems in the
health sciences context.

● Early AI used "top-down approach

● Examples of AI following the bottom up approach include
neural network systems, a type of deep-learning
technology that concentrates on signal processing and
pattern recognition problems such as facial recognition.

Assignment
1What is component based system. What are components
in this context.
2. Define component models.
3. What are advantages of CBM over OOM
4. Discuss the different component based systems.

4.4 Agent-Based Methodology

 30

Agent-based Software engineering also known as Agent Oriented

Software Engineering (AOSE) is a software development
methodology that is employed in development of software
agents . Agent based methodology is used in developing software
systems.

● A software agent is a computer program that acts for/ on

behalf of the user.
● software agents are computer applications that are designed
to autonomously sense and respond to environment in
pursuit of certain designed objectives.
● These software agents exhibit some kind of intelligence,
hence are also known as intelligent agents.
● An intelligent system is a system that can sense and respond
to its environment in pursuing its goals and objectives. It
learns and adapts based on past experiences.
● They can be used to assist the user in performing repetitive
tasks such as seeking information, shopping , scheduling,
monitoring, control, negotiation, and bargaining.
● That is there is an agreement for the program to act or
represent the user in an established relationship/interaction.
● It may include the ability to take decisions on behalf of the
user.
● Agents are autonomous ( meaning : independent, self-
sufficient) software units used in decision making and
exchange of information.
Note: a system is autonomous:
● If it requires little help from the
human user
● If we don’t have to tell it what to do
step by step
 31

● If it can set its own goal and the way

to actualize it
● If its behavior is determined by its
own experience
● If we don’t understand its internal
workings.
● These software agents are known as bots and they come in
various shapes and forms examples may include
knowbots , taskbots, Robots, Chatbots, shopbots,
softbots, personal agents, information agents, etc.
● These agents are abstractions of living /autonomous entities
of real world.
● It is this concept that makes modeling and implementing
software systems with autonomous behavior, decision
making, easy and realistic.

● An agent can be single (individual) agent or multiple agent.

● But no matter the form, intelligent agents exhibit one or

more of the following characteristics.
Characteristics of software agents:
Software agents can:
● stand on their own – autonomy
● intelligence- being able to exhibit intelligent behavior such
as reasoning, generalizing, learning, dealing with
uncertainty, using heuristic and natural language
processing.
● adaptive learning- being able to learn and adapt to their
external environment.
● social ability- able to communicate , collaborate, bargain,
compete, and interact with other agents and humans on
behalf of their owners. Also able to communicate with
 32

using agent communication language ACL Example is an

autonomous pilot controlling an aircraft.( auto pilot).
● make decisions about what to do without direct
intervention of humans or other agents.
● Be reactive- they are situated in an environment (which
may be physical world, user interface, internet) where they
will be able to perceive their environment through sensors
and respond timely to changes that may occur.
● Pro-active- agents do not only act in response to their
environment, they have ability to take initiative.
● have human like qualities like natural language
● human like understanding- take initiative.
● Mobile – being able migrate to themselves from one
system to another in a network such as web.
● goal oriented- able to act in accordance with the built in
goals and objectives.
● Agent based system are built around three important
methodologies:
1. Logic ---- for reasoning
2. Game theory----for strategies
3. Algorithms----- for artificial agents.

Agent based systems mainly used in

● artificial intelligence,
● neural networks, (a computer system modelled on human
brain and nervous system)
● Robotics etc.

Experimental-based methodology
Experimental software engineering all about
● gathering evidence (data) through measurements and
experiments needed when developing software
 33

systems.
● This evidence / data is used as basis of theories about
the processes involved in software engineering.

Empirical software engineering is a related concept, sometimes

used synonymously with experimental software engineering.
● Empirical software engineering emphasizes the use of
empirical studies of all kinds to accumulate knowledge.
● Empirical research is based on firm verifiable data
collected by observation of facts under natural condition
or obtained through experimentation.

Advantages of experimental methodology;

● Experimental methodology are valuable tools for
software engineers who are involved in evaluating and
choosing between different methods, techniques,
languages, and tools.
● The purpose of experimentation in software
engineering to introduce students, researchers to
empirical studies in software engineering using
controlled experiments.
● The introduction to experimentation is provided
through a process perspective and the focus is on the
steps that we have to go through perform n experiment.

4.5 COMPONENT-BASED METHODOLOGY

This is a software development methodology that
emphasizes on the development of software systems with
the help of reusable software components. Reusability
is an important characteristic of high quality software
components. By this it mean that programmer should
design and implement software components in such a
way that many different programs can reuse them.
Reusability means:
 34

● Fully documented
● Thoroughly tested
● Robust—has comprehensive input validity
checking technique
● Able to pass back appropriate error messages
or return codes
● Designed with the awareness that it put to
unforeseen uses.

● A component is a software unit whose functionality and

dependencies are completely defined by its interfaces.
● A software component is a software package , or a web
service, web resource, a module that combines or
compresses a set of related functions..
● that is to say all system processes separated into different
components contains data and functions that are
semantically related.
● Components communicate with each other via interfaces
● A component specifies the service it can offer to other
components and vice versa.
● During the CBSE process, the processes of requirements
engineering and system design are interleaved.
● Component composition is the process of ‘wiring’
components together to create a system.
● When composing reusable components, adaptors are
written to reconcile different component interfaces.
● In choosing compositions, you have to consider required
functionality, nonfunctional requirements and system
evolution.
 35

Component-based methodology is applicable to Component

Based Software Engineering (CBSE). It is also known as
component-based Development (CBD).
What do we mean by component here ?
● Component here means software component.
● A software component is an independent executable entity
that can be made up of one or more executable objects.
● It is a software element that conforms to a component
model and can be independently deployed and composed
without modification according to a composition standard.
● That is to say, a software component also has specified
interfaces that can be deployed independently.
● The component is an independent, executable entity. It
does not have to be compiled before it is used with other
components.

A component model is a definition of standards for component

implementation, documentation and deployment. The component
model specifies how interfaces should be defined and the
elements that should be included in an interface definition. It is a
definition of the properties that components must satisfy, the
methods and mechanisms for component composition.
Examples of component models
● EJB model --- (Enterprise Java Beans)
● COM --- component object model
● .NET model
● CORBA ---- Component object request
broker architecture

Component composition: The process of assembling

components to create a system is called component composition.
Composition involves integrating components with each other
and with the component infrastructure. Normally‘glue codes’ are
 36

written to integrate components.

Types of component composition

● Sequential composition: where the composed components
are executed in sequence.
● Hierarchical composition: where one component calls on
the services of another.
● Additive composition: where the interfaces of two
components are put together to create a new component.

In summary we can say that Components are:

Standardized: Component standardization means that a
component that is used in a CBSE process has to conform to a
standardized component model.
Independent: A component should be independent – it should be
possible to compose and deploy it without having to use other
specific components.
Composable: For a component to be composable, all external
interactions must take place through publicly defined interfaces.
In addition, it must provide external access to information about
itself such as its methods and attributes.
Deployable : For component to be deployable, a component has
to be self-contained and must be able to operate as a stand-alone
entity on some component platform that implements the
component model. This usually means that the component is a
binary component that does not have to be compiled before it is
deployed.
Documented: Components have to be fully documented so that
potential users of the component can decide whether or not they
meet their needs. All the syntaxes and semantics of all component
interfaces have to be specified.
Advantages of CBSE
● Component-based software engineering (CBSE) is an
approach to software development that relies on software
 37

reuse.
● It emerged from the failure of object-oriented development
to support effective reuse.
● In object oriented development single object classes are too
detailed and specific.
● But Components are more abstract than object classes and
can be considered to be standalone service providers.
● Apart from the benefits of reuse, CBSE is based on sound
software engineering design principles:
● Components are independent so do not interfere with each
other; Component implementations are hidden.
● Communication is through well-defined interfaces.
● Component platforms are shared and reduce development
costs.
● Components are language independent.

4.7 Software Engineering Formal methods

In software engineering,
● formal methods are specific mathematical approaches to
solving both software and hardware problems at the
requirement, and specification and design levels of
development process.
● These formal methods are mostly employed for safety or
security purposes.
● Formal methods models are concerned with the application
of mathematical techniques in designing and
implementing the software.
● It lays the foundation on which the system is based.
 38

● This eliminates errors or mistakes which are difficult to

overcome using other models.
● The use of formal methods for software and hardware
design is motivated by the expectation that, as in other
engineering disciplines, performing appropriate
mathematical analysis can contribute to the reliability and
robustness of a design.
● Formal methods comprise formal specification using
mathematics to specify the desired properties of the system
Advantages of formal methods include:
● It helps to discover ambiguity, incompleteness and
inconsistencies in the software.
● Gives error free software
● It grows an effective solution incrementally at every
iteration
● It does not involve high complexity rate.
● Formal language can verify any self consistency.
Disadvantages:
● Its time consuming
● It is difficult to use this as a communication mechanism for
those who are not technical
● Requires extensive training for developers to understand the
model

Prototyping Methodology
The Prototyping Model is a systems development method in
which a prototype (an approximation of a final system or
product) is built, tested, and then reworked as necessary until an
acceptable prototype is finally achieved from which the complete
system or product can now be developed.
● Software prototype is simulated version of the intended
 39

software product.
● Prototype provides initial look and feel of the software
product and simulates few aspect of actual product.
● This model works best in scenarios where not all of the
project requirements are known in detail ahead of time.
● It is an iterative, trial-and-error process that involves
both the developers and the users.
There are several steps in the Prototyping Model:
● The new system requirements are defined in as much detail
as possible. This usually involves interviewing a number of
users representing all the departments or aspects of the
existing system.
● A preliminary design is created for the new system.
● A first prototype of the new system is constructed from the
preliminary design. This is usually a scaled-down system,
and represents an approximation of the characteristics of the
final product.
● The users thoroughly evaluate the first prototype, noting
its strengths and weaknesses, what needs to be added, and
what should to be removed. The developer collects and
analyzes the remarks from the users.
● The first prototype is modified, based on the comments
supplied by the users, and a second prototype of the new
system is constructed.
● The second prototype is evaluated in the same manner as
was the first prototype.
● The preceding steps are iterated/ repeated as many times as
necessary, until the users are satisfied that the prototype
represents the final product desired.
● The final system is constructed, based on the final
prototype.
● The final system is thoroughly evaluated and tested.
 40

● Routine maintenance is carried out on a continous basis to

prevent large-scale failures and to minimize downtime.

LECTURE MODULE 5
DATA PROCESS AND FLOW DESIGN
METHODOLOGIES

Data process and flow methodologies in software development is

of paramount importance for the following reasons:
● To show the flow of information through the system.
● To show different presentations for identifying data flows.
● To effectively communicate within different units of
system
● For documentation purposes.

To depict the flow of data or process in an information system we

use the following data flow models:
● The Data Flow Diagram (DFD)
● Entity Relationship Diagram (ERD)
● Structured English
● HIPO diagram
● Pseudo-Code
● Data dictionary
● Use Case diagram

5.1 Data Flow Diagrams (DFDs)

Basic Concepts
 41

● Data flow diagram is graphical representation of flow of

data in an information system.

● DFD is used to depict incoming data flow, outgoing data

flow and stored data.

● DFD is different from Flowchart.

● While flowchart shows flow of control in program

modules., DFDs show flow of data in the system.

● Also, DFD does not contain any control or branch

instructions as obtainable in flowcharts.

● For example, the Yes or No options in typical flowcharts

are absent in DFDs.
That is to say in a nutshell: A Data Flow Diagram has
● No control flow
● No decision rules and
● No loops

● DFD is generally used for outlining the pattern and

framework of a data system without showing processing
options in sequence,
● In reality, DFD is just used for data visualization.

DFDs Components and Symbols

DFDs are used basically to represent the Source, destination,
storage and flow of data using the following set of components
-
 42

● Entities - Entities are the sources and destinations of data.

Entities are represented in DFD using rectangles or
squares with their respective names.
● Process - Activities and action taken on the data are
represented by Circle or Round-edged rectangles.
● Data Storage - There are two variants of data storage - it
can either be represented as a rectangle with absence of
both smaller sides or as an open-sided rectangle with only
one side missing.
● Data Flow - Movement of data is shown by pointed
arrows. Data movement is shown from the base of arrow
as its source towards head of the arrow as destination.
●

Examples of the DFDs.

 43

5.2 Entity-Relationship Model (ERD)

● Entity-Relationship model is just a kind of database model
showing real world entities and relationships among them.

● ER Model is used to create a set of entities with their

attributes and relationship among them.

● ER Model is best used for the conceptual design of

database but it does not show how to implement the
database.

● An example of ER Model can be represented generally as

follows :
 44

● Entity - An entity in ER Model is a real world being, which

has some properties called attributes.
For example, Consider a school database. Here, a student
is an entity. Student has various attributes like name, Dept.
age and reg no. etc.
● Relationship - The logical association among entities is
called relationship. Relationships are mapped with entities
in various ways.
● The relationship can be:
o one to one
o one to many
o many to one
o many to many

Basic Concepts of ERD

● ERD used to reflect /show the key relationships between
different entities in an information system.
● The most common practical uses of ERD include relational
databases.

Below are good examples of the ERDs

 45

Fig (a)

Fig (b)

Differences between DFDs and ERDs

1.Difference in their Methodology
● DFD is mainly concerned with entering, transforming
and storing data in an information system. In contrast,
ERD shows the overall framework of the database system
without explaining much about the implementations of the
database.
● Also entities in DFD are usually processed individually
and linked interactively. Whereas Entities in an ERD often
represents a group of similar entities.
● That is to say, logically, ERD models show how the data
units are grouped into entities. And physically, ERD
reflects how data elements are stored in a database.
 46

2. Difference in Presentation
DFD models show detailed flow of information, whereas ERD
models presents show the relationships among entities.

5.3 Structure Charts

● Structure chart is a chart derived from Data Flow Diagram.

● Structure chart represent hierarchical structure of modules.

● It shows more details of the system than DFD.

● It breaks down the entire system into its various functional

modules, describes functions and sub-functions of each
module of the system to a greater detail than DFD.

● At each level a specific task is performed.

Here are the symbols used in construction of structure charts -
● Module - It represents process or subroutine or task. A
control module branches to more than one sub-module.
Library Modules are re-usable and invokable from any

module.
● Condition - It is represented by small diamond at the base
of module. It depicts that control module can select any of
 47

sub-routine based on some condition.

● Jump - An arrow is shown pointing inside the module to

depict that the control will jump in the middle of the sub-

module.
● Loop - A curved arrow represents loop in the module. All
sub-modules covered by loop repeat execution of module.
 48

● Data flow - A directed arrow with empty circle at the end

represents data flow.

● Control flow - A directed arrow with filled circle at the
end represents control flow.

5.4 Hierarchical Input Process Output Diagram (HIPO

Diagram)
● HIPO diagram represents the hierarchy of modules in the
software system. Thus decomposes functions into sub-
functions in a hierarchical manner.

● HIPOs combine two organized methods to analyze the

system and provide means of documentation.

● Secondly, HIPO diagrams are used to show high level

model of the system

● And the high level model depicts the functions performed

by system.

● HIPO diagrams are good for documentation purposes.

● Their graphical representation makes it easier for designers

and analysts to get the pictorial idea of the system structure.
 49

5.5 Structured English

● Sometimes most programmers find it difficult to represent
a large software pictorially or graphically

● And more so many forms of data flow and process methods

which use graphs or diagrams are sometimes interpreted or
understood differently by different people.

● software developers or designers came up with tools such

as Structured English to represent their system.

● Structured English is nothing but the description of what is

required to code and how to code it in a simple English
language

● Structured English helps the programmer to write error-

free code.

● Structured English uses plain English words in structured

programming paradigm.

● It is not the ultimate code but a kind of description what is

required to code and how to code it.
.
 50

Example: Using Structured English to authenticate a student.

Enter Student_Name
SEEK Student_Name in Student Class List_DB file
IF Student_Name found THEN
Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
PRINT error message
Call procedure NEW_STUDENT_REQUEST()
ENDIF
Note:

● The code written in Structured English is more like day-to-

day spoken English.

● It can not be implemented directly as a code of software.

● Structured English is independent of programming

language.

5.6 Pseudo-Code
● Pseudo code is written more close to programming
language.

● It is often considered as augmented programming

language, and it’s full of comments and descriptions.

● Except that Pseudo code avoids variable declaration but

they are written using some actual programming
language’s constructs, like C, Fortran, Pascal etc.
 51

● Pseudo code contains more programming details than

Structured English.

● It provides a method to perform the task, as if a computer

is executing the code.
Example of Pseudo code is given below:

5.8 Data Dictionary

● Data dictionary is the centralized collection of information
about data.

● It stores meaning and origin of data, its relationship with

other data, data format for usage etc.

● Data dictionary has rigorous definitions of all names in

order to facilitate user and software designers.

● Data dictionary is often referenced as meta-data (data about

data) repository.

● It is created along with DFD (Data Flow Diagram) model

of software program and is expected to be updated
whenever DFD is changed or updated.
5.8.1 Requirement of Data Dictionary
● The data is referenced via data dictionary while designing
and implementing software.

● Data dictionary removes any chances of ambiguity.

● Data dictionary provides a way of documentation for the

complete database system in one place

● . Validation of DFD is carried out using data dictionary.

Data dictionary should contain information about the following

 52

● Data Flow
● Data Structure
● Data Elements
● Data Stores
● Data Processing

SOFTWARE METRICS
The word 'metrics' refer to
● standards for measurements.
● Software Quality Metrics means measurement of attributes,
pertaining to software quality along with its process of
development.
● software quality metrics means measuring the software
qualities by recording the number of defects or security
loopholes present in the software.

Why Software Quality Metrics?

Software metric/ measurement as a standard of measurement in

software development used
● to measure the quality of software.
● It is a quantitative measurement of a software product
● help users to developers/users to understand the software
performance, quality, productivity and efficiency.
● Its main objective is to ensure that we obtain a software of
high performance.
● Software quality is a measurement of “how good” a
 53

software product really is.

● The essence of software metrics is to determine the quality
of the software product, improve the quality, and predict the
quality of the software product if completed.
● To evaluate and assess each of these process and attribute
against the given requirements and specifications.
● However, quality measurement is not restricted to counting
of defects or vulnerabilities but also covers other aspects of
the qualities such as maintainability, reliability, integrity,
usability, customer satisfaction, etc.

The qualities of software that interest users are:

● Reliability
● Correctness
● Integrity
● Maintainability
● Usability
● Reusability
● Portability
● Interoperability
● Testability
● Efficiency
● Availability
● Capability

Classification of software metrics

It can be classified into three categories: product metrics, process
 54

metrics, and project metrics.

Product metrics describe the characteristics of the product such
as size, complexity, design features, performance, and quality
level.
Process metrics can be used to improve software development
and maintenance. Examples include the effectiveness of defect
removal during development, the pattern of testing defect arrival,
and the response time of the fix process.

Project metrics describe the project characteristics and

execution. Examples include the number of software developers,
the staffing pattern over the life cycle of the software, cost,
schedule, and productivity.
Types of Software Metrics
a). Formal code metric: Formal code metric include Lines of Code
(LOC), code complexity, Instruction Path Length, etc. In modern
development environments, these are considered less useful.

b).Developer productivity metric: These metrics helps us

understand how much time and work developers are investing in
a software project. Such as active days, assignment scope,
efficiency and code churn.
c.) Agile process metrics: Agile metrics measure the progress of
a development team in producing working, shipping-quality
software features such as lead time, cycle time and velocity.

d.) Operational metric: This metric checks how software is

running in production and how effective operations staff are at
maintaining it such as Mean Time Between Failures (MTBF) and
Mean Time to Recover (MTTR).
e). Test metrics: Test metric measures how comprehensively a
software is tested, which should be correlated with software
quality. Such as code coverage, percent of automated tests, and
defects in production.

f.) Customer satisfaction: This is the ultimate measurement of

how customers experience the software and their interaction with
 55

the software vendor. Such as Net Promoter Score (NPS),

Customer Effort Score (CES) and Customer Satisfaction Score
(CSAT).

Relevant Software Metrics

Reliability: This is a measure of how stable the software and the
degree of risk of failure Production incidents, average failure rate,
and load testing,

Performance: This measures how efficient the code is, how

optimal is the architecture, is the system able to scale, load times
of pages or key functionality Load testing, stress testing, soak
testing, Application Performance Monitoring (APM).
Security: This metric measures how likely it is that attackers
might breach the system, interrupt it or gain access to sensitive
information. Number of vulnerabilities, time to resolution,
deployment of updates, number and severity of security incidents.
Maintainability and code quality: this metric measures how
easy is the system is to debug, troubleshoot, maintain, integrate
and extend with new functionality. Out of these four software
metrics , performance is probably the one that is easiest to
measure. The other three are tricky to quantify and while metrics
exist, they do not show the complete picture.

Features of good Software Quality Metrics

1. Should be specific to measure the particular attribute or an
attribute of greater importance.
2. Comprehensive for wide variety of scenarios.
3. Should not consider attributes that have already been
measured by some other metrics.
4. Reliable to work similarly in all conditions.
5. Should be easy and simple to understand and operate.

CASE (Computer Aided Software Engineering).

Computer Aided software engineering is the development and
maintenance of software projects with help of various automated
 56

software tools.
CASE Tools CASE tools are set of software application
programs, which are used to automate SDLC activities.
CASE tools are used by software project managers, analysts and
engineers to develop software system. There are number of CASE
tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools,
Project management tools, Database Management tools,
Documentation tools are to name a few. Use of CASE tools
accelerates the development of project to produce desired result
and helps to uncover flaws before moving ahead with next stage
in software development.
Components of CASE Tools: CASE tools can be broadly
divided into the following parts based on their use at a particular
SDLC stage:
Central Repository - CASE tools require a central repository,
which can serve as a source of common, integrated and consistent
information. Central repository is a central place of storage where
product specifications, requirement documents, related reports
and diagrams, other useful information regarding management is
stored. Central repository also serves as data dictionary.

Upper Case Tools - Upper CASE tools are used in planning,

analysis and design stages of SDLC.
Lower Case Tools - Lower CASE tools are used in
implementation, testing and maintenance.
Integrated Case Tools - Integrated CASE tools are helpful in all
the stages of SDLC, from Requirement gathering to Testing and
 57

documentation. CASE tools can be grouped together if they have

similar functionality, process activities and capability of getting
integrated with other tools.
Scope of Case Tools: The scope of CASE tools goes throughout
the SDLC.

Case Tools Types:

Now we briefly go through various
CASE tools Diagram tools These tools are used to represent
system components, data and control flow among various
software components and system structure in a graphical form.
For example, Flow Chart Maker tool for creating state-of-the-art
flowcharts.
Process Modeling Tools: Process modeling is method to create
software process model, which is used to develop the software.
Process modeling tools help the managers to choose a process
model or modify it as per the requirement of software product.
For example, EPF Composer
Project Management Tools: These tools are used for project
planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project
execution with every mentioned step in software project
management. Project management tools help in storing and
sharing project information in real-time throughout the
organization. For example, Creative Pro Office, Trac Project,
Basecamp.
Documentation Tools: Documentation in a software project
starts prior to the software process, goes throughout all phases of
SDLC and after the completion of the project. Documentation
tools generate documents for technical users and end users.
Technical users are mostly in-house professionals of the
development team who refer to system manual, reference manual,
training manual, installation manuals etc. The end user
documents describe the functioning and how-to of the system
such as user manual. For example, Doxygen, DrExplain, Adobe
RoboHelp for documentation.
 58

Analysis Tools: These tools help to gather requirements,

automatically check for any inconsistency, inaccuracy in the
diagrams, data redundancies or erroneous omissions. For
example, Accept 360, Accompa, CaseComplete for requirement
analysis, Visible Analyst for total analysis.
Design Tools: These tools help software designers to design the
block structure of the software, which may further be broken
down in smaller modules using refinement techniques. These
tools provides detailing of each module and interconnections
among modules. For example, Animated Software Design

Configuration Management Tools. An instance of software is

released under one version. Configuration Management tools deal
with
– Version and revision management
– Baseline configuration management
– Change control management

CASE tools help in this by automatic tracking, version

management and release management. For example, Fossil, Git,
Accu REV.
Change Control Tools: These tools are considered as a part of
configuration management tools. They deal with changes
made to the software after its baseline is fixed or when the
software is first released. CASE tools automate change tracking,
file management, code management and more. It also helps in
enforcing change policy of the organization.
Programming Tools: These tools consist of programming
environments like IDE Integrated Development Environment, in-
built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include
features for simulation and testing. For example, Cscope to search
code in C, Eclipse.
Prototyping Tools: Software prototype is simulated version of
the intended software product. Prototype provides initial look and
feel of the product and simulates few aspect of actual product.
Prototyping CASE tools essentially come with graphical libraries.
 59

They can create hardware independent user interfaces and design.

These tools help us to build rapid prototypes based on existing
information. In addition, they provide simulation of software
prototype. For example, Serena prototype composer, Mockup
Builder.
Web Development Tools: These tools assist in designing web
pages with all allied elements like forms, text, script, graphic and
so on. Web tools also provide live preview of what is being
developed and how will it look after completion. For example,
Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Quality Assurance Tools: Quality assurance in a software

organization is monitoring the engineering process and methods
adopted to develop the software product in order to ensure
conformance of quality as per organization standards. QA tools
consist of configuration and change control tools and software
testing tools. For example, SoapTest, AppsWatch, JMeter.

Maintenance Tools: Software maintenance includes

modifications in the software product after it is delivered.
Automatic logging and error reporting techniques, automatic
error ticket generation and root cause Analysis are few CASE
tools, which help software organization in maintenance phase of

Scope of Software Metrics

Software metrics contains many activities which include the
following −
1. Cost and effort estimation
2. Productivity measures and model
3. Data collection
4. Quantity models and measures
5. Reliability models
6. Performance and evaluation models
7. Structural and complexity metrics
8. Capability – maturity assessment
 60

9. Management by metrics
10. Evaluation of methods and tools
Software measurement is a diverse collection of these activities
that range from models predicting software project costs at a
specific stage to measures of program structure.

Cost and Effort Estimation Effort is expressed as a function of

one or more variables such as the size of the program, the
capability of the developers and the level of reuse. Cost and effort
estimation models have been proposed to predict the project cost
during early phases in the software life cycle. The different
models proposed are −

Productivity Model and Measures Productivity can be

considered as a function of the value and the cost. Each can be
decomposed into different measurable size, functionality, time,
money, etc. Different possible components of a productivity
model can be expressed in the following diagram.

Data Collection The quality of any measurement program is

clearly dependent on careful data collection. Data collected can
be distilled into simple charts and graphs so that the managers can
understand the progress and problem of the development. Data
collection is also essential for scientific investigation of
relationships and trends.

Quality Models and Measures Quality models have been

developed for the measurement of quality of the product without
which productivity is meaningless. These quality models can be
combined with productivity model for measuring the correct
productivity. These models are usually constructed in a tree-like
fashion. The upper branches hold important high level quality
factors such as reliability and usability.
The notion of divide and conquer approach has been implemented
as a standard approach to measuring software quality.

Reliability Models Most quality models include reliability as a

 61

component factor, however, the need to predict and measure

reliability has led to a separate specialization in reliability
modeling and prediction. The basic problem in reliability theory
is to predict when a system will eventually fail.

Performance Evaluation and Models It includes externally

observable system performance characteristics such as response
times and completion rates, and the internal working of the
system such as the efficiency of algorithms. It is another aspect
of quality.

Structural and Complexity Metrics Here we measure the

structural attributes of representations of the software, which are
available in advance of execution. Then we try to establish
empirically predictive theories to support quality assurance,
quality control, and quality prediction.

Capability Maturity Assessment This model can assess many

different attributes of development including the use of tools,
standard practices and more. It is based on the key practices that
every good contractor should be using.

Management by Metrics For managing the software project,

measurement has a vital role. For checking whether the project is
on track, users and developers can rely on the measurement-based
chart and graph. The standard set of measurements and reporting
methods are especially important when the software is embedded
in a product where the customers are not usually well-versed in
software terminology.

Evaluation of Methods and Tools This depends on the

experimental design, proper identification of factors likely to
affect the outcome and appropriate measurement of factor
attributes.
 62

TESTING AND QUALITY ASSURANCE

Software testing and QA (Quality Assurance) are not the same
notions. They have different goals, specific features and methods
to apply.
Quality Assurance is a set of methods and activities designed to
ensure that the developed software corresponds to all the
specifications, e.g., SRS, FRS, and BRS. It is a planned strategy
of the testing process evaluation aimed at the quality product
yield. QA works out ways to prevent possible bugs in the process
of software development. QA deals more with the management
stuff: methods and techniques of development, project analysis,
checklists, etc.QA vs testing and quality control

QA goes through the whole product life cycle (SDLC) and heads
the process of software maintenance.
Software Testing is a way of exploring the system to check how
it operates and find the possible defects. Various methods are
used to test the product, locate bugs and check if they are fixed.
Testing enables customers with the possibility to see if the
developed product meets their expectations on its design,
compatibility, functioning, etc.
testing process description
Despite the fact that software testing works out ways to break the
software (aiming to check the system), it is a complex and crucial
process. Testing is product-oriented, time-limited and reports to
QC process.
 63

Difference between QA and Testing

Having analyzed these two notions, we can compare them
according to their aim, focus, definition, activity type, and
orientation. QA controls the Testing process and verifies that
software is able to work under the given set of conditions. Testing
concentrates on case studying, their implementation and
evaluation.
QA and testing differences
QA and Testing work in the same direction and focus on product
quality. Professional attitude towards the common goal together
with strong communication will ensure the realization of the
stated goal.
 64

SOFTWARE TEST AUTOMATION

In software testing, test automation is the use of special software
(separate from the software being tested) to control the execution
of tests and the comparison of actual outcomes with predicted
outcomes. Test automation can automate some repetitive but
necessary tasks in a formalized testing process already in place,
or perform additional testing that would be difficult to do
manually. Test automation is critical for continuous delivery and
continuous testing.
Some software testing tasks, such as extensive low-level interface
regression testing, can be laborious and time-consuming to do
manually. In addition, a manual approach might not always be
effective in finding certain classes of defects. Test automation
offers a possibility to perform these types of testing effectively.
Once automated tests have been developed, they can be run
quickly and repeatedly. Many times, this can be a cost-effective
method for regression testing of software products that have a
long maintenance life. Even minor patches over the lifetime of
the application can cause existing features to break which were
working at an earlier point in time.
 65

There are many approaches to test automation, however below

are the general approaches used widely:

Graphical user interface testing. A testing framework that

generates user interface events such as keystrokes and mouse
clicks, and observes the changes that result in the user interface,
to validate that the observable behavior of the program is correct.
API driven testing. A testing framework that uses a
programming interface to the application to validate the
behaviour under test. Typically API driven testing bypasses
application user interface altogether. It can also be testing public
(usually) interfaces to classes, modules or libraries are tested with
a variety of input arguments to validate that the results that are
returned are correct.
Test automation tools can be expensive, and are usually employed
in combination with manual testing. Test automation can be made
cost-effective in the long term, especially when used repeatedly
in regression testing. A good candidate for test automation is a
test case for common flow of an application, as it is required to
be executed (regression testing) every time an enhancement is
made in the application. Test automation reduces the effort
associated with manual testing. Manual effort is needed to
develop and maintain automated checks, as well as reviewing test
results.
In automated testing the test engineer or software quality
 66

assurance person must have software coding ability, since the test
cases are written in the form of source code which, when run,
produce output according to the assertions that are a part of it.
Some test automation tools allow for test authoring to be done by
keywords instead of coding, which do not require programming.
One way to generate test cases automatically is model-based
testing through use of a model of the system for test case
generation, but research continues into a variety of alternative
methodologies for doing so. In some cases, the model-based
approach enables non-technical users to create automated
business test cases in plain English so that no programming of
any kind is needed in order to configure them for multiple
operating systems, browsers, and smart devices.
What to automate, when to automate, or even whether one really
needs automation are crucial decisions which the testing (or
development) team must make. A multi-vocal literature review of
52 practitioner and 26 academic sources found that five main
factors to consider in test automation decision are: 1) System
Under Test (SUT), 2) the types and numbers of tests, 3) test-tool,
4) human and organizational topics, and 5) cross-cutting factors.
The most frequent individual factors identified in the study were:
need for regression testing, economic factors, and maturity of
SUT.

Unit testing
A growing trend in software development is the use of unit testing
frameworks such as the xUnit frameworks (for example, JUnit
and NUnit) that allow the execution of unit tests to determine
whether various sections of the code are acting as expected under
various circumstances. Test cases describe tests that need to be
run on the program to verify that the program runs as expected.
Test automation mostly using unit testing is a key feature of
extreme programming and agile software development, where it
is known as test-driven development (TDD) or test-first
development. Unit tests can be written to define the functionality
before the code is written. However, these unit tests evolve and
are extended as coding progresses, issues are discovered and the
 67

code is subjected to refactoring. Only when all the tests for all the
demanded features pass is the code considered complete.
Proponents argue that it produces software that is both more
reliable and less costly than code that is tested by manual
exploration.[citation needed] It is considered more reliable
because the code coverage is better, and because it is run
constantly during development rather than once at the end of a
waterfall development cycle. The developer discovers defects
immediately upon making a change, when it is least expensive to
fix. Finally, code refactoring is safer when unit testing is used;
transforming the code into a simpler form with less code
duplication, but equivalent behavior, is much less likely to
introduce new defects when the refactored code is covered by unit
tests.

Graphical User Interface (GUI) testing

Many test automation tools provide record and playback features
that allow users to interactively record user actions and replay
them back any number of times, comparing actual results to those
expected. The advantage of this approach is that it requires little
or no software development. This approach can be applied to any
application that has a graphical user interface. However, reliance
on these features poses major reliability and maintainability
problems. Relabelling a button or moving it to another part of the
window may require the test to be re-recorded. Record and
playback also often adds irrelevant activities or incorrectly
records some activities.[citation needed]

A variation on this type of tool is for testing of web sites. Here,

the "interface" is the web page. However, such a framework
utilizes entirely different techniques because it is rendering
HTML and listening to DOM Events instead of operating system
events. Headless browsers or solutions based on Selenium Web
Driver are normally used for this purpose.

Another variation of this type of test automation tool is for testing

mobile applications. This is very useful given the number of
 68

different sizes, resolutions, and operating systems used on mobile

phones. For this variation, a framework is used in order to
instantiate actions on the mobile device and to gather results of
the actions.

Another variation is script-less test automation that does not use

record and playback, but instead builds a model of the application
and then enables the tester to create test cases by simply inserting
test parameters and conditions, which requires no scripting skills.

API driven testing

API testing is also being widely used by software testers due to
the difficulty of creating and maintaining GUI-based automation
testing. It involves directly testing APIs as part of integration
testing, to determine if they meet expectations for functionality,
reliability, performance, and security. Since APIs lack a GUI,
API testing is performed at the message layer. API testing is
considered critical when an API serves as the primary interface to
application logic since GUI tests can be difficult to maintain with
the short release cycles and frequent changes commonly used
with agile software development and DevOps.

Continuous testing
Continuous testing is the process of executing automated tests as
part of the software delivery pipeline to obtain immediate
feedback on the business risks associated with a software release
candidate. For Continuous Testing, the scope of testing extends
from validating bottom-up requirements or user stories to
assessing the system requirements associated with overarching
business goals.

What to test
Testing tools can help automate tasks such as product installation,
test data creation, GUI interaction, problem detection (consider
parsing or polling agents equipped with test oracles), defect
logging, etc., without necessarily automating tests in an end-to-
end fashion.
 69

One must keep satisfying popular requirements when thinking of

test automation:

Platform and OS independence

Data driven capability (Input Data, Output Data, Metadata)
Customization Reporting (DB Data Base Access, Crystal Reports
Easy debugging and logging
Version control friendly – minimal binary files
Extensible & Customization (Open APIs to be able to integrate
with other tools)
Common Driver (For example, in the Java development
ecosystem, that means Ant or Maven and the popular IDEs). This
enables tests to integrate with the developers' workflows.
Support unattended test runs for integration with build processes
and batch runs. Continuous integration servers require this.
Email Notifications like bounce messages
Support distributed execution environment (distributed test bed)
Distributed application support (distributed SUT)

SOFTWARE MAINTENANCE
Software maintenance in software engineering is the modification
of a software product after delivery to correct faults, to improve
performance or other attributes.
A common perception of maintenance is that it merely involves
fixing defects. However, one study indicated that over 80% of
maintenance effort is used for non-corrective actions. This
perception is perpetuated by users submitting problem reports
that in reality are functionality enhancements to the system. More
recent studies put the bug-fixing proportion closer to 21%.

Importance of software maintenance

The key software maintenance issues are both managerial and
technical. Key management issues are: alignment with customer
priorities, staffing, which organization does maintenance,
 70

estimating costs. Key technical issues are: limited understanding,

impact analysis, testing, maintainability measurement.
Software maintenance is a very broad activity that includes error
correction, enhancements of capabilities, deletion of obsolete
capabilities, and optimization. Because change is inevitable,
mechanisms must be developed for evaluation, controlling and
making modifications.
So any work done to change the software after it is in operation
is considered to be maintenance work. The purpose is to preserve
the value of software over the time. The value can be enhanced
by expanding the customer base, meeting additional
requirements, becoming easier to use, more efficient and
employing newer technology. Maintenance may span for 20
years, whereas development may be 1–2 years.
Software maintenance planning
An integral part of software is the maintenance one, which
requires an accurate maintenance plan to be prepared during the
software development. It should specify how users will request
modifications or report problems. The budget should include
resource and cost estimates. A new decision should be addressed
for the developing of every new system feature and its quality
objectives. The software maintenance, which can last for 5–6
years (or even decades) after the development process, calls for
an effective plan which can address the scope of software
maintenance, the tailoring of the post delivery/deployment
process, the designation of who will provide maintenance, and an
estimate of the life-cycle costs. The selection of proper
enforcement of standards is the challenging task right from early
stage of software engineering which has not got definite
importance by the concerned stakeholders.

Software maintenance processes

This section describes the six software maintenance processes as:
The implementation process contains software preparation and
transition activities, such as the conception and creation of the
maintenance plan; the preparation for handling problems
identified during development; and the follow-up on product
 71

configuration management.
The problem and modification analysis process, which is
executed once the application has become the responsibility of
the maintenance group. The maintenance programmer must
analyze each request, confirm it (by reproducing the situation)
and check its validity, investigate it and propose a solution,
document the request and the solution proposal, and finally,
obtain all the required authorizations to apply the modifications.
The process considering the implementation of the modification
itself.
The process acceptance of the modification, by confirming the
modified work with the individual who submitted the request in
order to make sure the modification provided a solution.
The migration process (platform migration, for example) is
exceptional, and is not part of daily maintenance tasks. If the
software must be ported to another platform without any change
in functionality, this process will be used and a maintenance
project team is likely to be assigned to this task.
Finally, the last maintenance process, also an event which does
not occur on a daily basis, is the retirement of a piece of software.
There are a number of processes, activities and practices that are
unique to maintainers, for example:

Transition: a controlled and coordinated sequence of activities

during which a system is transferred progressively from the
developer to the maintainer;
Service Level Agreements (SLAs) and specialized (domain-
specific) maintenance contracts negotiated by maintainers;
Modification Request and Problem Report Help Desk: a problem-
handling process used by maintainers to prioritize, documents
and route the requests they receive;

Categories of maintenance in ISO/IEC 14764

three categories of maintenance:
● corrective,
 72

● adaptive, and
perfective.
Corrective maintenance: Reactive modification of a software
product performed after delivery to correct discovered problems.
Adaptive maintenance: Modification of a software product
performed after delivery to keep a software product usable in a
changed or changing environment.
Perfective maintenance: Modification of a software product after
delivery to improve performance or maintainability.
Preventive maintenance: Modification of a software product after
delivery to detect and correct latent faults in the software product
before they become effective faults.
There is also a notion of pre-delivery/pre-release maintenance
which is all the good things you do to lower the total cost of
ownership of the software. Things like compliance with coding
standards that includes software maintainability goals. The
management of coupling and cohesion of the software. The
attainment of software supportability goals (SAE JA1004,
JA1005 and JA1006 for example). Note also that some academic
institutions[who?] are carrying out research to quantify the cost
to ongoing software maintenance due to the lack of resources
such as design documents and system/software comprehension
training and resources (multiply costs by approx. 1.5-2.0 where
there is no design data available).
 73

Areas to cover:
● Software Engineering standards
● IEEE and other software standards.
● Computer Aided Software Engineering (CASE) tools;
● Software project management

Lecture 1:

Introduction
What do we mean by standard and why do we bother about standards and
how does standard apply or fit into computing?
Standards are mainly heard in world of commerce and industry. Standards
are meant to define benchmarks by which things or processes can be
measured. Frequently we hear of standard concerning our goods and
services especially the consumables. But here we are to talk about how
standards apply to the evolving world of computing and software
engineering in particular.

SOFTWARE ENGINEERING STANDARDS

Definitions /Meanings
● Standard literally portrays a level of quality, especially a
level thought to be acceptable.
● Something is said to a standard when it is set up by an
authority as a rule for evaluations, or as a measure of :
quantity, weight, extent, value, quality.
● Standards can be published documents created to ensure
the reliability of materials, products, methods, and or
services.
● they establish requirements, specifications, guidelines,,
 74

characteristics and or procedures designed.

● Standards are minimally accepted professional practice and
quality that must be observed by the stakeholders.
In the same vein , Software standard is :
● a standard, a protocol, or other common formats for
(documents, file, or data transfer ) accepted and used by one
or more software developers working independently on one
or more computer applications.
● Software standards are set up majorly to enable
interoperability between different programs created by
different developers. Interoperability is the ability of
software to exchange and make use of information. It is a
characteristic of a software product whose interfaces are
completely understood , to work with other products at
present, in the future without any restrictions in either
implementation or access
● Simply put, software standard help software to connect to
each other.
● It fosters compatibility, and interoperability between
software, or platforms, and devices.
● Software standards consist of or must contain certain, data
formats, document styles and techniques or terms/ concepts
agreed upon by software developers so that their software
can understand the files and data created by a different
developers on different computers
● For an example for a certain protocol to be considered a
standard , it needs to be accepted and incorporated by a
group of developers who contribute to the definition and
maintenance of the protocol..

Hence, it is the communication standard that enables emails sent

from Microsoft Outlook to be read from within the Yahoo mail
application. Without a standardized technique , the two different
applications would be unable to accurately share or deliver
 75

information.
But there are some widely used data formats quite understood
and used by a variety of programs that are not considered a
software standard.
● Example is the Microsoft Office file formats, such as .doc
and .xls, .These formats are not accepted standard
formats because they are still owned and controlled by
Microsoft and they are commonly converted by other
computer programs before use.
● But, text files like .TXT or .RTF are accepted standard
formats and are readily used without any conversion.

EXAMPLES OF SOFWARE STANDARDS

Commonly used software standards that application designers
must understand and follow are:
● TCP/IP, - transmission control protocol/ internet protocol
● SMTP, - simple mail transport protocol
● POP – post office protocol
● FTP – file transfer protocol
● HTTP –Hyper Text transfer protocol
● HTTPS - Hyper Text transfer protocol secure
● UDP – User diagram protocol.
● Telnet
● Gopher
● .
HOW SOFTWARE STANDARDS ARE CREATED/FORMED
Software standards are created by software standard organizations like
W3C - World Wide Web Consortium. Hv developed a range of
specificatins and guidelines that power the internet
ISO – International Organization for standardization.
IEEE – Institute of Electrical and Electronic Engineers
These organizations are made up representatives of large software
 76

companies that come together to make and agree on a common unified

standard that will address the problem of interest. Standards are developed
thru a consus process approved by various national and international
agencies, professional societies or industry.

CHARATERISTICS OF SOFTWARE STANDARDS

Software standards are supposed have the following attributes in order to
utilized and serve the role for which it is created.;
● Simple
● Maintainable
● Understandable
But how simple or complex a standard is depends on the kind of problem
its meant to address… Example, FTP and SMTP are not solving same
problem. While FTP is concerned with transfer of files between two
applications , the SMTP is created for sending and receiving of emails.

TYPES OF SOFWARE STANDARDS:

We have two types of software standards namely:
● Open standard and
● closed standards
A standard is said to be open if the documentation for standard
is open to the public and anyone can create a software that
implements and uses the standard.

● Whereas a standard is said to be closed if documentation

and specification are not available to the public.
Closed standard enables the software developer to sell and license
the code to manage his/her data format to other interested
software developers. This idea of selling or licensing the software
may generate revenue, but the disadvantage is that it limits
acceptance of the close software and leads to the adoption of a
similar open standard instead.

IMPORTANCE OF SOFTWARE STANDARDS

The Importance of software standards are but not limited to the following:
 77

● Help Produce Efficient Software Product

● For reliable, and safe software products
● For effective communication b/w disparate systems
● For easy monitoring and tracking of software metrics and more.
● As a means of transferring good practice in software engineering
● Reduce Risk
● Improve Performance
● Advance Innovation And New Techs
● Reduce Cost/ cost effective.

IEEE AND OTHER SOFTWARE STANDARDS

It is good to know that a number of organizations are charged with just this
task of setting standards in computing. Example of such organizations /
bodies like
● W3C that developed a range of guidelines and specifications that
power the internet.
● ISO – International Organization for Standardization.
● IEEE – Institute of Electrical and Electronic Engineers.
● APA – American Psychology Association ( used in reference)
● ITU - International Telecommunication Union)
● IEC International Electrotechnical Commission
Examples of other Standard granting organizations are
ANSI - American National Standard Institute
ETSI – European Telecommunications Standards Institute
ICC- International Code Council

IEEE AND OTHER SOFTWARE STANDARDS

These are series of internationally agreed set of standards for
software testing. These standards establish a common framework
for software life cycle processes. They contain the processes,
activities and tasks that are to be applied during the acquisition of
a software system, product or service, supply, development,
operation, maintenance and disposal of software product. This
 78

involves stake holders and with the ultimate goal of satisfying the
customers. Examples include:
The IEEE is a global association and organization of
professionals working toward the development, implementation
and maintenance of technology centered services. There are over
230 active , draft and archived standrds pulished by IEEE and
used throughout the industry tody.
● ISO/IEC/IEEE 29119
● IEEE1207-2017- ISO/IEC/IEEE
● ISO/IEC/12207 – an international standard that defines all
processes required for developing and maintaining software
systems.

LECTURE 2
COMPUTER AIDED SOFTWARE ENGINEERING (CASE)
TOOLS
CASE (Computer Aided Software Engineering).
Computer Aided software engineering is the development and
maintenance of software projects with help of various automated
software tools.
CASE Tools CASE tools are set of software application
programs, which are used to automate SDLC activities.
CASE tools are used by software project managers, analysts and
engineers to develop software system. There are number of CASE
tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools,
Project management tools, Database Management tools,
Documentation tools are to name a few. Use of CASE tools
accelerates the development of project to produce desired result
and helps to uncover flaws before moving ahead with next stage
in software development.
Components of CASE Tools: CASE tools can be broadly
divided into the following parts based on their use at a particular
SDLC stage:
Central Repository - CASE tools require a central repository,
which can serve as a source of common, integrated and consistent
 79

information. Central repository is a central place of storage where

product specifications, requirement documents, related reports
and diagrams, other useful information regarding management is
stored. Central repository also serves as data dictionary.

Upper Case Tools - Upper CASE tools are used in planning,

analysis and design stages of SDLC.
Lower Case Tools - Lower CASE tools are used in
implementation, testing and maintenance.
Integrated Case Tools - Integrated CASE tools are helpful in all
the stages of SDLC, from Requirement gathering to Testing and
documentation. CASE tools can be grouped together if they have
similar functionality, process activities and capability of getting
integrated with other tools.
Scope of Case Tools: The scope of CASE tools goes throughout
the SDLC.

Case Tools Types:

Now we briefly go through various
CASE tools Diagram tools These tools are used to represent
system components, data and control flow among various
software components and system structure in a graphical form.
For example, Flow Chart Maker tool for creating state-of-the-art
flowcharts.
Process Modeling Tools: Process modeling is method to create
software process model, which is used to develop the software.
Process modeling tools help the managers to choose a process
 80

model or modify it as per the requirement of software product.

For example, EPF Composer
Project Management Tools: These tools are used for project
planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project
execution with every mentioned step in software project
management. Project management tools help in storing and
sharing project information in real-time throughout the
organization. For example, Creative Pro Office, Trac Project,
Basecamp.
Documentation Tools: Documentation in a software project
starts prior to the software process, goes throughout all phases of
SDLC and after the completion of the project. Documentation
tools generate documents for technical users and end users.
Technical users are mostly in-house professionals of the
development team who refer to system manual, reference manual,
training manual, installation manuals etc. The end user
documents describe the functioning and how-to of the system
such as user manual. For example, Doxygen, DrExplain, Adobe
RoboHelp for documentation.
Analysis Tools: These tools help to gather requirements,
automatically check for any inconsistency, inaccuracy in the
diagrams, data redundancies or erroneous omissions. For
example, Accept 360, Accompa, CaseComplete for requirement
analysis, Visible Analyst for total analysis.
Design Tools: These tools help software designers to design the
block structure of the software, which may further be broken
down in smaller modules using refinement techniques. These
tools provides detailing of each module and interconnections
among modules. For example, Animated Software Design

Configuration Management Tools. An instance of software is

released under one version. Configuration Management tools deal
with
– Version and revision management
– Baseline configuration management
– Change control management
 81

CASE tools help in this by automatic tracking, version

management and release management. For example, Fossil, Git,
Accu REV.
Change Control Tools: These tools are considered as a part of
configuration management tools. They deal with changes
made to the software after its baseline is fixed or when the
software is first released. CASE tools automate change tracking,
file management, code management and more. It also helps in
enforcing change policy of the organization.
Programming Tools: These tools consist of programming
environments like IDE Integrated Development Environment, in-
built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include
features for simulation and testing. For example, Cscope to search
code in C, Eclipse.
Prototyping Tools: Software prototype is simulated version of
the intended software product. Prototype provides initial look and
feel of the product and simulates few aspect of actual product.
Prototyping CASE tools essentially come with graphical libraries.
They can create hardware independent user interfaces and design.
These tools help us to build rapid prototypes based on existing
information. In addition, they provide simulation of software
prototype. For example, Serena prototype composer, Mockup
Builder.
Web Development Tools: These tools assist in designing web
pages with all allied elements like forms, text, script, graphic and
so on. Web tools also provide live preview of what is being
developed and how will it look after completion. For example,
Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Quality Assurance Tools: Quality assurance in a software

organization is monitoring the engineering process and methods
adopted to develop the software product in order to ensure
conformance of quality as per organization standards. QA tools
consist of configuration and change control tools and software
testing tools. For example, SoapTest, AppsWatch, JMeter.
 82

Maintenance Tools: Software maintenance includes

modifications in the software product after it is delivered.
Automatic logging and error reporting techniques, automatic
error ticket generation and root cause Analysis are few CASE
tools, which help software organization in maintenance phase of

LECTURE 8
SOFTWARE ENGINEERING STANDARDS
Introduction
What do we mean by standard and why do we bother about standards and
how does standard apply or fit into computing?
Standards are mainly heard in world of commerce and industry. Standards
are meant to define benchmarks by which things or processes can be
measured. Frequently we hear of standard concerning our goods and
services especially the consumables. But here we are to talk about how
standards apply to the evolving world of computing and software
engineering in particular.

SOFTWARE ENGINEERING STANDARDS

Definitions /Meanings
● Standard literally portrays a level of quality, especially a level
thought to be acceptable.
● Something is said to a standard when it is set up by an authority as a
rule for evaluations, or as a measure of: quantity, weight, extent,
value, quality.
● Standards can be published documents created to ensure the
reliability of materials, products, methods, and or services.
● Standards establish requirements, specifications, guidelines,,
characteristics and or procedures designed.
● Standards are minimally accepted professional practice that must
be observed by the stakeholders.
In the same vein, Software standard is:
● a standard, a protocol, or other common formats for (documents,
file, or data transfer ) accepted and used by one or more software
developers working independently on one or more computer
applications.
 83

● Software standards are set up majorly to enable interoperability

between different programs created by different developers.
Interoperability is the ability of software to exchange and make use
of information. It is a characteristic of a software product whose
interfaces are completely understood , to work with other products
at present, in the future without any restrictions in either
implementation or access
● Simply put, software standard help software to connect to each
other.
● It fosters compatibility, and interoperability between software, or
platforms, and devices.
● Software standards consist of or must contain certain, data formats,
document styles and techniques or terms/ concepts agreed upon by
software developers so that their software can understand the files
and data created by a different developers on different computers
● For an example for a certain protocol to be considered a standard, it
needs to be accepted and incorporated by a group of developers who
contribute to the definition and maintenance of the protocol.
Hence, it is the communication standard that enables emails sent from
Microsoft Outlook to be read from within the Yahoo mail application.
Without a standardized technique, the two different applications would be
unable to accurately share or deliver information.
HOW SOFTWARE STANDARDS ARE CREATED/FORMED
Software standards are created by software standard organizations like
W3C - World Wide Web Consortium.
ISO – International Organization for standardization.
IEEE – Institute of Electrical and Electronic Engineers
These organizations are made up representatives of large software
companies that come together to make and agree on a common unified
standard that will address the problem of interest. Standards are developed
through a consensus process approved by various national and
international agencies, professional societies or industry.

CHARATERISTICS OF SOFTWARE STANDARDS

Software standards are supposed to have the following attributes in order
to utilize and serve the roles for which it is created.;
● Simple
● Maintainable
● Understandable
 84

But how simple or complex a standard is depends on the kind of problem

its meant to address…

TYPES OF SOFWARE STANDARDS:

We have two types of software standards namely:
● Open standard and
● closed standards

Open Standards
A standard is said to be open if the documentation for the standard is open
to the public and anyone can create a software that implements and uses
the standard. Open standards must be freely and publicly available under
royalty free terms at a reasonable and non discriminatory cost. Examples
of open software standards are:

i) XML -- eXtensive Markup Language : used for transferring

structured data efficiently.
ii) HTML -- Hyper Text Markup Language: Managed by W3C
iii) CSS – Cascading Style sheets: Managed by W3C
iv) PDF: Portable Document Format: This was initially created
and managed by Adobe but later made vendor neutral and royalty
-free open standard
v) JSON – Java Script Object Notation- used for transferring
structured data.
vi) PNG – Portable Network Graphics: For Images
vii) GIF—Graphics Interchange Format for fixed colour map images
viii) HTTP – Hyper Text Transfer Protocol . used for plain texts
ix) HTTPS – Secured, encrypted HTTP
x) WebRTC – Web Real –Time Communications : an encrypted
used in point to point standard for audio and video on modern
web browsers.

Advantages of open standards

Generally open standards lower costs and increase revenue as it
provides the following benefits:
● Vendor neutrality
● Greater use by many people
● Efficient use of the existing resources.
● Flexibility
● Interoperability
 85

● Lower and manageable risks

● Robustness and durability
● More options for optimization
● Better human communication
● Increase available skill
● Security.
There are some standard that well known and widely used formats which
but do not fulfill all the necessary criteria to be called open standards
despite their wide usage. This category of standards are called FAUXPEN
STANDARDS. Reason is that no version of Microsoft office currently
provides files which are fully complaint with the formats. Examples of
fauxpen standards are :
1. Microsoft’s Office Open XML also known as OOXML, or Open
XML which include:
i) DOCX for text documents
ii) XLSX for spreadsheets
iii) PPTX for presentations
iv) DOTX – used for templates
2. Fraunhofer Institute’s MP3 format. Used for music files.

Closed (Proprietary) Standards

A standard is said to be closed if documentation and specification are not
available to the public. They are standards that are unilaterally controlled
by a single vendor or entity. It is a file format , protocol or program which
has wide public acceptance but which does not comply with the
requirements for open standard. They are contolled by one company. It is
not governed by standards’ organisations.
When proprietary standard such as WINDOWS is widely used it becomes
a “de facto standard.
Closed standards have documentations often available in part. For
example, the coding can be available while decoding algorithm is secret.
Closed standard enables the software developer to sell and license the code
to manage his/her data format to other interested software developers. This
idea of selling or licensing the software may generate revenue. Examples
include:
i) Microsoft’s office legacy formats such as :
DOC ---text documents
XLS – spreadsheets
PPT – power point presentations
MDB – database files
 86

ii) Microsoft’s Windows Media player Audio and Video Format: eg

WMP , WMV
iii) Apple’s Quick Time Format for audio and video compression.
iv) AutoDesk’s AutoCAD formats eg; DWG
v) Microsoft’s Silvelight : framework for WWW.
vi) Real Network’s RealPlayer formats: used for audio and video.
vii) Adobe’s Flash: which is a rich content framework for ubiquitous
computing.

Note the difference between open source software and open standard.
Open software is a software whose source code is freely available to users
for reference purposes , debugging , modification, and or extension. But
open standard is a typically specifications, formal description of software
or software interfaces.
IMPORTANCE OF SOFTWARE STANDARDS
The Importance of software standards are but not limited to the following:
● Help Produce Efficient Software Product
● For reliable, and safe software products
● For effective communication b/w disparate systems
● For easy monitoring and tracking of software metrics and more.
● As a means of transferring good practice in software engineering
● Reduce Risk
● Improve Performance
● Advance Innovation And New Techs
● Reduce Cost/ cost effective.

IEEE AND OTHER SOFTWARE STANDARDS

A number of organizations are charged with this task of setting standards
in computing. Example of such organizations / bodies are:
● W3C - World Wide Web consortium.
● ISO – International Organization for Standardization.
● IEEE – Institute of Electrical and Electronic Engineers.
● APA – American Psychology Association ( used in reference)
● ITU - International Telecommunication Union)
● IEC International Electrotechnical Commission
 87

● ANSI - American National Standard Institute

● ETSI – European Telecommunications Standards Institute
● ICC- International Code Council

Examples of Software standards

These are series of internationally agreed set of standards for software
development and testing. These standards establish a common framework
for software life cycle processes. They contain the processes, activities and
tasks that are to be applied during the acquisition of a software system,
product or service, supply, development, operation, maintenance and
disposal of software product. This involves stake holders and with the
ultimate goal of satisfying the customers.
There are over 230 active, draft and archived software standards published
by IEEE and used throughout the industry today.
● ISO/IEC/IEEE 29119
● IEEE1207-2017- ISO/IEC/IEEE
● ISO/IEC/12207 – an international standard that defines all processes
required for developing and maintaining software systems.

Some Important IEEE Software Engineering Standards

List of Important IEEE Software Engineering Standards

IEEE Standard for This standard describes an
Developing Software Life approach for the definition of
IEEE Std 1074-2006 Cycle Processes software life cycle processes.
This standard is the first of a
planned series of standards on
the integration of CASE tools into
a productive software
IEEE Guide for CASE Tool engineering environment. This
Interconnections - part describes fundamental
IEEE Std 1175.1- Classification and concepts and introduces the
2002 Description remaining parts.
IEEE Recommended This recommended practice
IEEE Std 1175.2- Practice for CASE Tool describes interconnections that
2006 Interconnection: need to be understood and
 88

Characterization of evaluated when buying, building,

Interconnections testing, or using computer-aided
software engineering (CASE)
tools.
This standard describes the
IEEE Standard for the systems engineering activities and
Application and process required throughout a
Management of the system's life cycle to develop
IEEE Std 1220-2005 Systems Engineering systems meeting customer needs,
(ISO/IEC 26702) Process requirements and constraints.

This standard describes the

minimum content of a plan for
the software aspects of
development, procurement,
IEEE Standard for Software maintenance and retirement of a
IEEE Std 1228-1994 Safety Plans safety-critical system.
This document provides guidance
on the development of a System
Requirements Specification,
covering the identification,
organization, presentation, and
modification of requirements. It
IEEE Guide for Developing also provides guidance on the
System Requirements characteristics and qualities of
IEEE Std 1233-1998 Specifications requirements.
This document provides guidance
IEEE Guide for Information on the format and content of a
Technology-- System Concept of Operations (ConOps)
IEEE Std 1362- Definition-- Concept of document, describing
1998 (Reaffirmed Operations (ConOps) characteristics of a proposed
2007) Document system from the users' viewpoint.
IEEE Standard--Adoption of
IEEE Std 1462-1998 International Guideline for the
// ISO/IEC Standard ISO/IEC 14102: 1995-- Evaluation and Selection
14102:1995 Information Technology-- of CASE tools
IEEE Standard Adoption of This standard describes
International quality requirements
IEEE Std 1465-1998 Standard ISO/IEC 12119:1994(E), specifically suitable for
// ISO/IEC 12119 Information Technology-- Software software packages and
 89

packages-- Quality requirements and guidance on testing the

testing package against those
requirements.

IEEE Recommended Practice This document recommends a

for Architectural Description conceptual framework and content
IEEE Std 1471-2000 of Software Intensive for the architectural description of
(ISO/IEC 42010) Systems software-intensive systems.
This document is the IEEE adoption
of a Project Management Body of
IEEE Guide-- Adoption of Knowledge defined by the Project
PMI Standard-- A Management Institute. It identifies
Guide to the Project and described generally accepted
Management Body of knowledge regarding project
IEEE Std 1490-2003 Knowledge management.
IEEE Standard for This standard provides life cycle
Information Technology— processes for systematic software
Software Life Cycle reuse. The processes are suitable for
Processes— Reuse use with IEEE/EIA 12207.
IEEE Std 1517-1999 Processes
This standard specifies the
requirements for an organizational
quality management system aiming
to provide products meeting
Quality Management requirements and enhance customer
ISO 9001:2000 Systems-- Requirements satisfaction.
This standard provides a model for
software product quality covering
internal quality, external quality, and
quality in use. The model is in the
Software Engineering-- form of a taxonomy of defined
ISO/IEC 9126- Product Quality- -Part 1: characteristics which software may
1:2001 Quality Model exhibit.
 90

This International Standard

establishes a common framework for
software life cycle processes, with
well-defined terminology, that can
be referenced by the software
industry. It applies to the acquisition
of systems and software products
and services, to the supply,
development, operation,
maintenance, and disposal of
software products and the software
Systems and Software portion of a system, whether
IEEE/EIA 12207- Engineering - Software Life performed internally or externally to
2008 Cycle Processes an organization.
Industry Implementation of
International
Standard ISO/IEC
12207:1995, Standard for
Information Technology-- This document provides guidance on
IEEE/EIA 12207.1- Software Life Cycle recording data resulting from the life
1996 Processes--Life Cycle Data cycle processes of IEEE/EIA 12207.0.

IEEE Adoption of ISO/IEC

14143-1:1998--
Information Technology—
IEEE Std 14143.1- Software This standard describes the
2000 Measurement— Functional fundamental concepts of a class of
// ISO/IEC 14143- Size Measurement— Part 1: measures collectively known as
1:1998 Definition of Concepts functional size.
Information technology--
This document provides guidance in
Software engineering-
establishing processes and activities
ISO/IEC TR Guidelines for the adoption
that may be applied in the adoption
14471:1999 of CASE tools of CASE technology.
This standard elaborates on the
maintenance process provided in
ISO/IEC 12207. It provides guidance
Information Technology-- in implementing the requirements of
ISO/IEC 14764:2006 Software Maintenance that process.
 91

This International Standard

introduces the concepts of software
integrity levels and software integrity
requirements. It defines the concepts
associated with integrity levels,
defines the processes for
Information Technology-- determining integrity levels and
System and Software software integrity requirements, and
ISO/IEC 15026:1998 Integrity Levels places requirements on each process.
Information technology--
Guide for ISO/IEC 12207
ISO/IEC TR (Software Life Cycle This document is a guide to the use of
15271:1998 Processes) ISO/IEC 12207.
This standard provides a framework
Systems Engineering-- of processes used across the entire
ISO/IEC 15288:2008 System Life Cycle Processes life cycle of human-made systems.
This technical report (now being
revised as a standard) provides
requirements on methods for
ISO/IEC TR 15504 (9 performing process assessment as a
parts) and Draft IS Software Engineering-- basis for process improvement or
15504 (5 parts) Process Assessment capability determination.
This standard provides a life cycle
Software Engineering-- process for software measurement.
Software Measurement The process is suitable for use with
ISO/IEC 15939:2002 Process IEEE/EIA 12207.
This standard provides a life cycle
IEEE Standard for Software process for software risk
Life Cycle Processes- Risk management. The process is suitable
ISO/IEC 16085:2006 Management for use with IEEE/EIA
This standard describes the COSMIC-
FFP Functional Size Measurement
Software engineering-- Method, a functional size
COSMIC-FFP-- A functional measurement method conforming to
ISO/IEC 19761:2003 size measurement method the requirements of ISO/IEC 14143-1.
Software engineering - This standard describes IFPUG 4.1
IFPUG 4.1 Unadjusted Unadjusted Function Point Counting,
functional size a functional size measurement
measurement method - method conforming to the
ISO/IEC 20926:2003 Counting practices manual requirements of ISO/IEC 14143-1.
 92

This standard describes Mk II

Function Point Analysis, a functional
Software engineering--Mk II size measurement method
Function Point Analysis-- conforming to the requirements of
ISO/IEC 20968:2002 Counting Practices Manual ISO/IEC 14143-1.
IEEE Recommended Practice
for the Internet-Web Site This document recommends
Engineering, Web Site practices for engineering World
ISO/IEC 23026 (IEEE Management and Web Site Wide Web pages for use in Intranet
Std 2001-2002) Life Cycle and Extranet environments.
Software and Systems This standard provides guidance for
Engineering-- Guidelines for organizations in the application of
the Application of ISO ISO 9001:2000 to the acquisition,
9001:2000 to Computer supply, development, operation and
ISO/IEC 90003 Software maintenance of computer software.

LECTURE 9
COMPUTER AIDED SOFTWARE ENGINEERING (CASE)
TOOLS
Computer Aided software engineering: is the development and
maintenance of software projects with aid/ help of various automated
software tools. The overall aim of CASE technology is to improve the
productivity, and quality of the software by assisting the developer
throughout the different stages/phases of software development from the
acquisition of the functional and the non- functional requirements to
design, and implementation, and even to non -phase activities such as
project management and configuration.

CASE Tools
● CASE tools are set of software application /package / programs
which are used to provide support for the design and
implementation of information system.
● Are used to simplify/automate various stages of Software
Development Life Cycle.
● Case tools are used for developing high quality, defect free and
maintainable software.
● Use of CASE tools accelerates the development of project to
 93

produce desired result and helps to uncover flaws before moving

ahead with next stage in software development.

CATEGORIES OF CASE TOOLS:

CASE tools can be broadly divided into the following three
categories/groups depending on their use at a particular SDLC stage:

1. Upper CASE Tools

● The tools used to support the analysis and design phases of
software development are called Upper CASE tools.
● They are front end tools for requirement specification,
planning and design.
● In a nutshell, they support database planning and design,
including data collection and analysis, data model generation
and application design.
● Eg. Report generators.

2. Lower CASE Tools

● The tools used in implementation, testing and maintenance
are called lower case tools.
● The lower CASE tools support database implementation
including data conversion, report generation, application
code generation ,prototyping and testing.
● They are the back end tools such as tools for implementation,
code generation, integration and maintenance
● These tools support coding, testing, and debugging phases.
● Examples include code designers, program editors

3. Integrated CASE Tools

● These tools are called Integrated CASE tools because they
are helpful/ support all the stages of SDLC. They share tasks
and information across all other tools and system
development activities.
● They support all phases of database development and
provides the functionalities of both upper CASE and lower
CASE .
 94

● They support the analysis, design and coding phases .

● They include a combination of both uppercase and lower
case tools.
● Examples of integrated Case tools are

BENEFITS OF CASE TOOLS

● CASE Tools help in improved software project management.
● Improved software product quality
● Promotes the standards of database making them easy to reuse and
maintain.
● Increased productivity by reducing development time.
● It helps to keep data linked, consistent and integrated for
organization.
● Reduced development time and effort
● Easier and better maintenance of software
● Better documentation
● Automatic Code and diagram generation
● Help in reverse engineering- also called back is process of a man
made object is deconstructed to reveal its designs, arch or extract
knowledge from the object.
● Also help in re-engineering – to redesign or re construct a device or
machine.
● CASE tools take out most of the work of the software engineer’s
work.

CHARACTERISTICS OF CASE TOOLS

● Flexible
● Easily integrated
● Should support standard software techniques
● Not usually cheap.

TYPES / CLASSIFICATION OF CASE TOOLS

There are various types of CASE tools available for use, they include the
following:
 95

1. Analysis Tools:
● These tools are used for requirement analysis
● By helping to gather requirements automatically, check
for any inconsistency, inaccuracy, data redundancies or
erroneous omissions.
● They are equally used to check for the proper functionality
of the software product.

● Examples are Artemis , Zoho Desk etc.

2. Design Tools:
● These tools help software developers to automate the
design process.
● Example : Adobe illustrator, Photoshop, Animated
Software Design etc.

3. Diagram tools:
● These tools are used to represent various software components and
system structure in a graphical form.
● Examples are Flow Chart Maker tools, Microsoft Visio, Dia etc.

4. Project Management Tools:

● These tools are used to plan and manage the whole
software project ‘
● The tools automate software features, functionalities,
resource management, budge, cost time etc.
● Examples are Creative Pro Office, Trac Project,
dashboards, project scheduling etc.
5. Documentation Tools:
● Used to generate documents for software product.
● The Documents being generated are the system manuals, reference
manuals, training manuals, installation manuals , user manuals for
both technical users and end users which can be referred to any
time.
● For example, webhelp, MarkdownPad, Doxygen, DrExplain,
Adobe RoboHelp etc.
 96

6. Programming Tools:
● These tools consist of programming environments like
IDE (Integrated Development Environment) in-built
modules library and simulation tools.
● These tools provide comprehensive aid in building
software product and include features for simulation and
testing.
● They provide a kind of solid framework for coding.
● Examples are Dreamweaver, Net-Beans, Cscope, Eclipse
etc.

7. Prototyping Tools: .
● These tools help us to build rapid prototypes of any
software product.
● In addition, they provide simulation of software
prototype.
● Example are Framer, Serena prototype composer,
Mockup Builder etc.
8. Web Development Tools:
● These tools assist in designing web pages with all allied
elements like forms, text, script, graphics and so on.
● For example, Fontello, Adobe Edge Inspect, Foundation
3, Brackets.

9. Quality Assurance Tools:

● Quality Assurance(QA) tools ensure that the quality of software
being developed is of highest standard..
● Examples are Appium, selenium, SoapTest, AppsWatch, etc.

LECTURE 10
SOFTWARE PROJECT MANAGEMENT
As a software engineer, you have two specific jobs namely:
1. to develop software and
2. to manage the developed software
Software development is just like any other project. Which means, it is /
 97

should be a well-defined task that involves a collection of several

operations done in order to achieve a goal.
A software project is therefore a complete process of software development
starting from requirement gathering to testing and maintenance carried
out using specified methodologies in a specified period of time to actualize
an information system or application.
Software project can be characterized as follows:
● every software project should have a unique/ distinct goal
● it is not a routine activity ie a day to day operations
● software project should have a start date/time and end date/time
● the software project ends when its goal is achieved, hence its
temporary for any organization
● software project needs adequate resources like time, human
resources, material resources, financial resources and knowledge
bank.

WHY DO WE NEED TO MANAGE OUR SOFWARE PROJECTS.

Software project management is essential for the following reasons:
● software development is usually a complex one
● takes long time.
● It’s a non physical/ intangible product
● It is a kind of new trend and only few people have experience in
building software products
● Most software products are client’s made or tailor made to fit
clients’ requirements
● Frequent / rapid changes and advances in underlying technology
affect software products such that what applies to one product may
not work in another product.

CONSTRAINTS TO SOFWARE PROJECTS

There are four major constraints to software projects:
● Time
● Cost
● Quality
● Scope.
Hence, this means that you are required /expected as software developer
 98

to deliver to your clients as follows:

🡪A quality software product
🡪keep the cost within the client’s budget
🡪deliver as scheduled/ within the shortest possible time.
🡪 And within the area of coverage/scope.
It is important to state that the first three ( time, cost, and quality) are
dependent on the scope.

SOFTWARE PROJECT MANAGER

A software project manager is one who:
● Who thoroughly understands all the phases of SDLC that a software
should go through
● Undertakes the responsibility of executing a software project
● He/she controls and manages the activities involved in producing the
end product even though he/she may not be involved in producing
the end product.
● Monitors all development processes , prepares and executes all the
plans
● Maintains communication among all the team members
● Addresses the issues of time, budget, cost, resources, and customer
satisfaction.
● Manages both the project and the people involved in the software
development.

In a nut shell, Software project management comprises of a number of

activities, which include :
● Software project planning 🡪 Software project planning is a set of
multiple processes, which facilitates software production
● identify the scope of software product 🡪 the scope of a software
project includes all the activities or processes that need to be done
in order to make a deliverable software product. Scope
management is essential because it creates boundaries of the
project by clearly defining what would be done in the project and
what would not be done.
● Estimation of costs :🡪 Cost estimation is considered as the most
difficult of all because it depends on more elements than any of
the previous ones. For estimating software project cost, it is
 99

required to consider -:Size of software, Software quality,

Hardware, Additional software or tools, licenses etc. Skilled
personnel with task-specific skills , Travel expenses involved,
Communication, Training and support
● Project estimation 🡪 Software project is estimated in terms of :
size, effort, time and cost. There are two broadly recognized
techniques used in estimation of software projects:
1. Decomposition Technique: This technique assumes the
software as a product of various compositions. And the
decomposition technique adopts two main models in this
viz: i). Line of Code (LOC) Estimation: Done based on the
number of lines of code in the software product.
ii) Function Points Estimation: Done based on the
number of function points in the software product.
a. Empirical Estimation Technique
The second called the empirical estimation technique uses empirically
derived formulae to make estimation. These formulae are based on LOC .
the models involved in this technique are:
i). Putnam Model: Putnam model maps time and efforts required with
software size.
ii). COCOMO: COCOMO stands for COnstructive COst Model. It
divides the software product into three categories of software: organic,
semi-detached and embedded.

Software project scheduling:

Project Scheduling refers to roadmap of all activities to be done with
specified order and within time slot allotted to each activity. For proper
scheduling we are required to:
■ Break down the project tasks into smaller, manageable form
■ Find out various tasks and correlate them
■ Estimate time frame required for each task
■ Divide time into work-units
■ Assign adequate number of work-units for each task
■ Calculate total time required for the project from start to finish

Resource management.
Resources include all elements used to develop a software product may.
This may include human resource, productive tools and software libraries.
And because the resources are available in limited quantity and stay in the
 100

organization as a pool of assets. The shortage of resources hampers the

development of project and it can lag behind the schedule. It is therefore
necessary to estimate and allocate adequate resources for the project.
Resource management includes –
■ creating a project team and allocating responsibilities to each team
member
■ Determining resources required at a particular stage and their
availability
■ Manage Resources by generating resource request when they are
required and de-allocating them when they are no more needed.

Software Project Risk Management

Risk management involves all activities pertaining to identification,
analyzing and making provision for predictable and non-predictable risks
in the project.
Risk may include the following:

■ Experienced staff leaving the project and new staff coming in.
■ Change in organizational management.
■ Requirement change or misinterpreting requirement.
■ Under-estimation of required time and resources.
■ Technological changes, environmental changes, business
competition.
Risk Management Process
There are following activities involved in risk management process:

■ Identify all possible risks, which may occur in the project.

■ Categorize known risks into high, medium and low risk intensity as
per their possible impact on the project.
■ Analyze the probability of occurrence of risks at various phases.
Make plan to avoid or face risks. Attempt to minimize their side-
effects.
■ Closely monitor the potential risks and their early symptoms
■ . Also monitor the effects of steps taken to mitigate or avoid them.
 101

Software Execution and Monitoring

At this juncture all the activities described at the planning stage are
executed according to their schedules. It equally needs monitoring in order
to check whether everything is going according to the plan. Monitoring
measures include –
■ Activity Monitoring - All activities scheduled within some task can
be monitored on day-to-day basis to ensure all tasks are complete.
■ Status Reports - The reports contain status of activities and tasks
completed within a given time frame, generally a week. Status can
be marked as finished, pending or work-in-progress etc.
■ Milestones Checklist - Every project is divided into multiple phases
where major tasks are performed based on the phases of SDLC. This
checklist can be prepared once every few week and reports of their
status .

Software Configuration Management

Configuration management is a process of tracking and controlling the
changes in software in terms of the requirements, design, functions and
development of the product. IEEE defines it as “the process of identifying
and defining the items in the system, controlling the change of these items
throughout their life cycle, recording and reporting the status of items and
change requests, and verifying the completeness and correctness of items”.