Notesale: Turn your study into money

Document Preview

Extracts from the notes are below, to see the PDF you'll receive please use the links above

---

LECTURE NOTES
ON
SOFTWARE ENGINEERING
Course Code: BCS-306
By
Dr
...
S
...
Prof K
...
Sahu
Asst
...
THE INFORMATION PRESENTED HERE IS
MERELY A COLLECTION BY THE COMMITTEE MEMBERS FOR
THEIR RESPECTIVE TEACHING ASSIGNMENTS
...
THE OWNERSHIP OF THE INFORMATION LIES
WITH THE RESPECTIVE AUTHORS OR INSTITUTIONS
...
Design and Analysis: Cohesion and coupling, Data flow oriented Design:
Transform centered design, Transaction centered design
...

Module II:
Object-oriented Design: Object modeling using UML, use case diagram, class diagram,
interaction diagrams: activity diagram, unified development process
...
Testing: Objectives, black box and white box testing, various
testing strategies, Art of debugging
...
Reliability: Concepts, Errors, Faults, Repair and availability, reliability and
availability models
...

Module IV:
Software quality: SEI CMM and ISO-9001
...
Computer-aided software engineering (CASE),
Component model of software development, Software reuse
...
Mall Rajib, Fundamentals of Software Engineering, PHI
...
Pressman, Software Engineering Practitioner’s Approach, TMH
...
)
Lecture 22: Debugging, Integration and System Testing
Lecture 23: Integration Testing
Lecture 24: Software Maintenance
Lecture 25: Software Maintenance Process Models
Lecture 26: Software Reliability and Quality Management
Lecture 27: Reliability Growth Models

Module 4:
Lecture 28: Software Quality
Lecture 29: SEI Capability Maturity Model
Lecture 30: Software Project Planning
Lecture 31: Metrics for Software Project Size Estimation
Lecture 32: Heuristic Techniques, Analytical Estimation Techniques
Lecture 33: COCOMO Model
Lecture 34: Intermediate COCOMO Model
Lecture 35: Staffing Level Estimation

DEPT OF CSE & IT
VSSUT, Burla

Lecture 36: Project Scheduling
Lecture 37: Organization Structure
Lecture 38: Risk Management
Lecture 39: Computer Aided Software Engineering
Lecture 40: Software Reuse
Lecture 41: Reuse Approach

References

DEPT OF CSE & IT
VSSUT, Burla

MODULE 1
LECTURE NOTE 1

INTRODUCTION TO SOFTWARE ENGINEERING
The term software engineering is composed of two words, software and engineering
...
A program is an executable code, which serves
some computational purpose
...
Software, when made for a
specific requirement is called software product
...

So, we can define software engineering as an engineering branch associated with the
development of software product using well-defined scientific principles, methods and
procedures
...

IEEE defines software engineering as:
The application of a systematic, disciplined, quantifiable approach to the development,
operation and maintenance of software
...
The experience is
arranged in the form of methodologies and guidelines
...
But if one wants to develop a large software product, then
software engineering principles are absolutely necessary to achieve a good quality software cost
effectively
...
In
industry it is usually needed to develop large programs to accommodate multiple functions
...
Software engineering helps to
reduce this programming complexity
...
The principle of
abstraction implies that a problem can be simplified by omitting irrelevant details
...
Once the simpler problem is solved, then the omitted details can be taken into
consideration to solve the next lower level abstraction, and so on
...
The other approach to tackle problem complexity is
DEPT OF CSE & IT
VSSUT, Burla

decomposition
...
However, in this technique any random
decomposition of a problem into smaller parts will not help
...
A good
decomposition of a problem should minimize interactions among various components
...

NEED OF SOFTWARE ENGINEERING
The need of software engineering arises because of higher rate of change in user requirements
and environment on which the software is working
...




Scalability- If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing one
...
But the cost of software remains high if
proper process is not adapted
...
If the nature of software is always
changing, new enhancements need to be done in the existing one
...




Quality Management- Better process of software development provides better and
quality software product
...
This software
must satisfy on the following grounds:


Operational



Transitional



Maintenance

DEPT OF CSE & IT
VSSUT, Burla

Well-engineered and crafted software is expected to have the following characteristics:
Operational
This tells us how well software works in operations
...
A life cycle model represents all the activities required
to make a software product transit through its life cycle phases
...
In other words, a life cycle model maps the different
activities performed on a software product from its inception to retirement
...
Thus, no matter
which life cycle model is followed, the basic activities are included in all life cycle models
though the activities may be carried out in different orders in different life cycle models
...


THE NEED FOR A SOFTWARE LIFE CYCLE MODEL
The development team must identify a suitable life cycle model for the particular project and
then adhere to it
...
When a software product is being
developed by a team there must be a clear understanding among team members about when and
what to do
...
This problem can be illustrated
by using an example
...
From then on, suppose the team members are
allowed the freedom to develop the parts assigned to them in whatever way they like
...
This would be one of the perfect recipes for project failure
...
A phase can start only if its
phase-entry criteria have been satisfied
...
Without software life cycle models it becomes difficult
for software project managers to monitor the progress of the project
...
Each of them has some advantages as well as
some disadvantages
...
CLASSICAL WATERFALL MODEL
The classical waterfall model is intuitively the most obvious way to develop software
...
Thus, this model can be
considered to be a theoretical way of developing software
...
So, in order to be able to appreciate other
life cycle models it is necessary to learn the classical waterfall model
...
2
...
1: Classical Waterfall Model
Feasibility study - The main aim of feasibility study is to determine whether it would be
financially and technically feasible to develop the product
...
They study different input data to the
system and output data to be produced by the system
...




After they have an overall understanding of the problem they investigate the different
solutions that are possible
...




Based on this analysis they pick the best solution and determine whether the solution is
feasible financially and technically
...


Requirements analysis and specification: - The aim of the requirements analysis and
specification phase is to understand the exact requirements of the customer and to document
them properly
...
This is done to clearly understand the customer
requirements so that incompleteness and inconsistencies are removed
...
For example, to perform the requirements analysis of a business accounting software
required by an organization, the analyst might interview all the accountants of the organization to
ascertain their requirements
...
Therefore it is necessary to identify all ambiguities and
contradictions in the requirements and resolve them through further discussions with the
customer
...
During
this activity, the user requirements are systematically organized into a Software Requirements
Specification (SRS) document
...
The important components of
this document are functional requirements, the nonfunctional requirements, and the goals of
implementation
...
In
technical terms, during the design phase the software architecture is derived from the SRS
document
...





Traditional design approach -Traditional design consists of two different activities; first
a structured analysis of the requirements specification is carried out where the detailed
structure of the problem is examined
...

During structured design, the results of structured analysis are transformed into the
software design
...
The object structure is further
refined to obtain the detailed design
...
Each component of the design is implemented as a program module
...
During this phase, each
module is unit tested to determine the correct working of all the individual modules
...

Integration and system testing: -Integration of different modules is undertaken once they have
been coded and unit tested
...
The different modules making up a software product are almost
never integrated in one shot
...
During each integration step, the partially integrated system is tested and a set of
previously planned modules are added to it
...
The goal of system testing is to ensure that
the developed system conforms to its requirements laid out in the SRS document
...

β –testing: It is the system testing performed by a friendly set of customers
...


System testing is normally carried out in a planned manner according to the system test plan
document
...
It also lists all the test cases and the
expected outputs for each test case
...
Many studies carried out in the past confirm this and
indicate that the relative effort of development of a typical software product to its maintenance
effort is roughly in the 40:60 ratios
...
This is
called corrective maintenance
...
This is called perfective maintenance
...
For example, porting may be
required to get the software to work on a new computer platform or with a new operating
system
...

Shortcomings of the classical waterfall model
The classical waterfall model is an idealistic one since it assumes that no development error is
ever committed by the engineers during any of the life cycle phases
...
The source of the defects can be many: oversight, wrong assumptions, use
of inappropriate technology, communication gap among the project engineers, etc
...
For example, a design defect might go unnoticed
till we reach the coding or testing phase
...
Therefore, in
any practical software development work, it is not possible to strictly follow the classical
waterfall model
...


ITERATIVE WATERFALL MODEL
To overcome the major shortcomings of the classical waterfall model, we come up with the
iterative waterfall model
...
1 : Iterative Waterfall Model
Here, we provide feedback paths for error correction as & when detected later in a phase
...
If so, this can reduce the effort to correct the bug
...
Finding issues
at an early stage of development enables to take corrective measures in a limited budget
...
This is because it is hard to break a small software system
into further small serviceable increments/modules
...
PRTOTYPING MODEL
Prototype
A prototype is a toy implementation of the system
...
A prototype is usually built using several shortcuts
...
The shortcut implementation of a function,
for example, may produce the desired results by using a table look-up instead of performing
the actual computations
...

Need for a prototype in software development
There are several uses of a prototype
...
This is a valuable
mechanism for gaining better understanding of the customer’s needs:




how the screens might look like
how the user interface would behave
how the system would produce outputs

Another reason for developing a prototype is that it is impossible to get the perfect product
in the first attempt
...
The experience gained in
developing the prototype can be used to develop the final product
...
A developed prototype can help engineers to critically examine the technical issues
associated with the product development
...

In such circumstances, a prototype may be the best or the only way to resolve the technical
issues
...
2: Prototype Model
4
...
At first, a simple working
model is built
...

Applications:
 Large projects where you can easily find modules for incremental implementation
...

 Also used in object oriented software development because the system can be easily
portioned into units in terms of objects
...

Disadvantages:
 It is difficult to divide the problem into several versions that would be acceptable to the
customer which can be incrementally implemented & delivered
...
3: Evolutionary Model

DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 4

5
...
4
...
The diagrammatic representation
of this model appears like a spiral with many loops
...
Each loop of the spiral represents a phase of the software process
...
Each phase in this model is split into four
sectors (or quadrants) as shown in fig
...
1
...


Fig 4
...

• Examine the risks associated with these objectives
...

• Steps are taken to reduce the risks
...

Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified
risks
...

• Progressively more complete version of the software gets built with each iteration
around the spiral
...
Risk
handling is inherently built into this model
...
However, this
model is much more complex than the other models – this is probably a factor deterring its use in
ordinary projects
...
However, the classical waterfall model cannot be used
in practical development projects, since this model supports no mechanism to handle the errors
committed during any of the phases
...
The iterative waterfall model is
probably the most widely used software development model evolved so far
...
However this model is suitable only for well-understood problems; it is
not suitable for very large projects and for projects that are subject to many risks
...
This model is especially popular for
development of the user-interface part of the projects
...
This model is also widely used for objectoriented development projects
...

The spiral model is called a meta model since it encompasses all other life cycle models
...
The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks
...

The different software life cycle models can be compared from the viewpoint of the customer
...
During the lengthy development process, customer confidence
normally drops off, as no working product is immediately visible
...
This gives rise to customer resentment
...
Another important advantage of the
incremental model is that it reduces the customer’s trauma of getting used to an entirely new
system
...
Also, from the customer’s financial viewpoint,
incremental development does not require a large upfront capital outlay
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 5

REQUIREMENTS ANALYSIS AND SPECIFICATION
Before we start to develop our software, it becomes quite essential for us to understand and
document the exact requirement of the customer
...
They are called as system analysts
...
He then
analyzes the collected information to obtain a clear and thorough understanding of the product to
be developed, with a view to remove all ambiguities and inconsistencies from the initial
customer perception of the problem
...
The most important requirements problems that the
analyst has to identify and eliminate are the problems of anomalies, inconsistencies, and
incompleteness
...

Parts of a SRS document
• The important parts of SRS document are:
Functional requirements of the system
Non-functional requirements of the system, and
Goals of implementation
DEPT OF CSE & IT
VSSUT, Burla

Functional requirements:The functional requirements part discusses the functionalities required from the system
...
The functional view of the
i

system is shown in fig
...
1
...
The user can get some
i

meaningful piece of work done using a high-level function
...
5
...

Goals of implementation:The goals of implementation part documents some general suggestions regarding development
...
The goals of implementation section
might document issues such as revisions to the system functionalities that may be required in the
future, new devices to be supported in the future, reusability issues, etc
...


DEPT OF CSE & IT
VSSUT, Burla

Identifying functional requirements from a problem description
The high-level functional requirements often need to be identified either from an informal
problem description document or from a conceptual understanding of the problem
...
There can be many types of users of a system and their requirements from the
system may be very different
...

Example: - Consider the case of the library system, where –
F1: Search Book function
Input: an author’s name
Output: details of the author’s books and the location of these books in the library

So the function Search Book (F1) takes the author's name and transforms it into book details
...
Also
each high-level requirement might consist of several other functions
...
A function can be specified by identifying the state at which the data is
to be input to the system, its input data domain, the output data domain, and the type of
processing to be carried on the input data to obtain the output data
...
The withdraw-cash
is a high-level requirement
...
These different interaction sequences capture the different scenarios
...
It checks the balance to
determine whether the requested amount is available in the account
...


DEPT OF CSE & IT
VSSUT, Burla

R1
...
2: select account type
Input: user option
Output: prompt to enter amount
R1
...

Output: The requested cash and printed transaction statement
...
The SRS document should be concise and at the same time unambiguous,
consistent, and complete
...




Structured
...
A well-structured document is easy to
understand and modify
...
Often, the customer requirements evolve over a
period of time
...




Black-box view
...
This means that the SRS document should specify the external
behavior of the system and not discuss the implementation issues
...
For this reason, the SRS document is also called the
black-box specification of a system
...
It should show conceptual integrity so that the reader can easily
understand it
...
It should characterize acceptable responses to undesired
events
...




Verifiable
...
This means that it should be possible to determine whether or not
requirements have been met in an implementation
...




Software developers would not know whether what they are developing is what exactly
required by the customer
...




It will be very much difficult for user document writers to write the users’ manuals
properly without understanding the SRS document
...

• It would be very much difficult to modify that document
...

• The SRS document might be unambiguous and inconsistent
...
The edges of a decision tree represent conditions and the leaf nodes
represent the actions to be performed depending on the outcome of testing the condition
...

Action: If proper information is entered then a membership record for the member is
created and a bill is printed for the annual membership charge plus the security deposit
payable
...

Action: If the membership is valid then membership expiry date is updated and the
annual membership bill is printed, otherwise an error message is displayed
...

Action: The membership is cancelled, a cheque for the balance amount due to the
member is printed and finally the membership record is deleted from the database
...
6
...


Fig 6
...

The upper rows of the table specify the variables or conditions to be evaluated
...
A
column in a table is called a rule
...

Example: Consider the previously discussed LMS example
...
6
...
Here the table is divided into two parts, the
upper part shows the conditions and the lower part shows what actions are taken
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
2: Decision table for LMS

From the above table you can easily understand that, if the valid selection condition is false then
the action taken for this condition is 'display error message'
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 7

FORMAL SYSTEM SPECIFICATION
Formal Technique
A formal technique is a mathematical method to specify a hardware and/or software system,
verify whether a specification is realizable, verify that an implementation satisfies its
specification, prove properties of a system without necessarily running the system, etc
...

Formal Specification Language
A formal specification language consists of two sets syn and sem, and a relation sat between
them
...
For a given specification syn, and model of the
system sem, if sat (syn, sem), then syn is said to be the specification of sem, and sem is said to be
the specificand of syn
...
The well-formed
formulas are used to specify a system
...
Abstract data type
specification languages are used to specify algebras, theories, and programs
...
Concurrent and distributed
system specification languages are used to specify state sequences, event sequences, statetransition sequences, synchronization trees, partial orders, state machines, etc
...
This satisfaction is determined by using a homomorphism
known as semantic abstraction function
...
There can be different specifications describing
different aspects of a system model, possibly using different specification languages
...
Consequently, two broad classes of semantic abstraction functions are defined: those
that preserve a system’s behavior and those that preserve a system’s structure
...
property-oriented approaches
Formal methods are usually classified into two broad categories – model – oriented and property
– oriented approaches
...

In the property-oriented style, the system's behavior is defined indirectly by stating its properties,
usually in the form of a set of axioms that the system must satisfy
...
In a property-oriented style, it is
probably started by listing the properties of the system like: the consumer can start
consuming only after the producer has produced an item; the producer starts to produce
an item only after the consumer has consumed the last item, etc
...
After processing of data, CPU
outputs characters to the buffer for printing
...
The CPU is constrained by the capacity of the buffer,
whereas the printer is constrained by an empty buffer
...

In a model-oriented approach, we start by defining the basic operations, p (produce) and c
(consume)
...
Thus the model-oriented approaches
essentially specify a program by writing another, presumably simpler program
...

Model-oriented approaches are more suited to use in later phases of life cycle because here even
minor changes to a specification may lead to drastic changes to the entire specification
...

Property-oriented approaches are suitable for requirements specification because they can be
easily changed
...

Operational Semantics
Informally, the operational semantics of a formal method is the way computations are
represented
...
Some commonly used operational semantics are as follows:
Linear Semantics:In this approach, a run of a system is described by a sequence (possibly infinite) of events or
states
...
For example, a concurrent activity a║b is represented by the set of
DEPT OF CSE & IT
VSSUT, Burla

sequential activities a;b and b;a
...
The behavior of a system in this model consists of the set of all its runs
...

Branching Semantics:In this approach, the behavior of a system is represented by a directed graph
...
The descendants of each node of
the graph represent the states which can be generated by any of the atomic actions enabled at that
state
...

Maximally parallel semantics:In this approach, all the concurrent actions enabled at any state are assumed to be taken together
...

Partial order semantics:Under this view, the semantics ascribed to a system is a structure of states satisfying a partial
order relation among the states (events)
...

This fact identifies concurrency as a phenomenon not translatable to any interleaved
representation
...



Formal specifications encourage rigor
...
The
construction of a rigorous specification clarifies several aspects of system behavior
that are not obvious in an informal specification
...
Thus, formal
specifications are not only more precise, but also mathematically sound and can be
used to reason about the properties of a specification and to rigorously prove that an
implementation satisfies its specifications
...
Therefore, ambiguity in specifications
is automatically avoided when one formally specifies a system
...
For example, a tableau-based technique has been used to automatically
check the consistency of specifications
...
The
possibility of automatic verification is one of the most important advantages of formal
methods
...
This concept of executable specifications is related to rapid
prototyping
...


Limitations of formal requirements specification
It is clear that formal methods provide mathematically sound frameworks within large, complex
systems can be specified, developed and verified in a systematic rather than in an ad hoc manner
...




The basic incompleteness results of first-order logic suggest that it is impossible to
check absolute correctness of systems using theorem proving techniques
...
This shortcoming results
from the fact that, even moderately complicated problems blow up the complexity of
formal specification and their analysis
...


Axiomatic Specification
In axiomatic specification of a system, first-order logic is used to write the pre and postconditions to specify the operations of the system in the form of axioms
...
In essence, the pre-conditions capture the requirements on the input parameters of a
function
...
Thus, the postconditions are essentially constraints on the results produced for the function execution to be
considered successful
...

Also find out other constraints on the input parameters and write it in the form of a
predicate
...




Establish the changes made to the function’s input parameters after execution of the
function
...

Combine all of the above into pre and post conditions of the function
...

f (x : real) : real
pre : x ∈ R
post : {(x≤100) ∧ (f(x) = x/2)} ∨ {(x>100) ∧ (f(x) = 2∗x)}

Example2: Axiomatically specify a function named search which takes an integer array and an
integer key value as its arguments and returns the index in the array where the key value
is present
...
Xlast], X[i] = key
post : {(X′[search(X, key)] = key) ∧ (X = X′)}

Here the convention followed is: If a function changes any of its input parameters and if
that parameter is named X, and then it is referred to as X′ after the function completes
execution faster
...

For assessing user requirements, an SRS (Software Requirement Specification) document is
created whereas for coding and implementation, there is a need of more specific and detailed
requirements in software terms
...

Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain
...

Software Design Levels
Software design yields three levels of results:


Architectural Design - The architectural design is the highest abstract version of the
system
...
At this level, the designers get the idea of proposed solution domain
...
High-level design focuses on how the system
along with all of its components can be implemented in forms of modules
...




Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs
...
It defines logical structure of each module and their
interfaces to communicate with other modules
...

These modules may work as basic constructs for the entire software
...

Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software
...




Concurrent execution can be made possible



Desired from security aspect

Concurrency
Back in time, all softwares were meant to be executed sequentially
...
Say, a software has multiple modules, then only one
of all the modules can be found active at any time of execution
...
In other words,
concurrency provides capability to the software to execute more than one part of code in
parallel to each other
...

Example
The spell check feature in word processor is a module of software, which runs alongside the
word processor itself
...
As we know, modules are set of instructions put together in order to
achieve some tasks
...
There are measures by which the quality of a design of modules and their
interaction among them can be measured
...

Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module
...


DEPT OF CSE & IT
VSSUT, Burla

There are seven types of cohesion, namely –


Co-incidental cohesion - It is unplanned and random cohesion, which might be the result
of breaking the program into smaller modules for the sake of modularization
...




Logical cohesion - When logically categorized elements are put together into a module,
it is called logical cohesion
...




Procedural cohesion - When elements of module are grouped together, which are
executed sequentially in order to perform a task, it is called procedural cohesion
...




Sequential cohesion - When elements of module are grouped because the output of one
element serves as input to another and so on, it is called sequential cohesion
...
Elements of module in functional cohesion are grouped because they all
contribute to a single well-defined function
...


Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a
program
...
The lower the
coupling, the better the program
...




Common coupling- When multiple modules have read and write access to some global
data, it is called common or global coupling
...




Stamp coupling- When multiple modules share common data structure and work on
different part of it, it is called stamp coupling
...
If a module passes data structure as parameter, then the
receiving module should use all its components
...

DEPT OF CSE & IT
VSSUT, Burla

Design Verification
The output of software design process is design documentation, pseudo codes, detailed logic
diagrams, process diagrams, and detailed description of all functional or non-functional
requirements
...

It is then becomes necessary to verify the output before proceeding to the next phase
...
If
the outputs of design phase are in formal notation form, then their associated tools for
verification should be used otherwise a thorough design review can be used for verification and
validation
...
A good design review is important for good software design,
accuracy and quality
...
Software design takes the user requirements as challenges and tries to find
optimum solution
...

There are multiple variants of software design
...
Software design takes the user requirements as challenges and tries to find
optimum solution
...

There are multiple variants of software design
...
It is basically concerned with the solution design
...
Structured design also makes it
simpler for designer to concentrate on the problem more accurately
...

The small pieces of problem are solved by means of solution modules
...

These modules are arranged in hierarchy
...
A good structured
design always follows some rules for communication among multiple modules, namely Cohesion - grouping of all functionally related elements
...

A good structured design has high cohesion and low coupling arrangements
...
These functions are capable of performing significant task in the system
...

Function oriented design inherits some properties of structured design where divide and conquer
methodology is used
...
These functional modules can
share information among themselves by means of information passing and using information
available globally
...
Function oriented
design works well where the system state does not matter and program/functions work on input
rather than on a state
...




DFD depicts how functions change the data and state of entire system
...




Each function is then described at large
...
This design strategy focuses on entities and its characteristics
...

Let us see the important concepts of Object Oriented Design:


Objects - All entities involved in the solution design are known as objects
...
Every entity has some
attributes associated to it and has some methods to perform on the attributes
...
An object is an instance of a
class
...

DEPT OF CSE & IT
VSSUT, Burla

In the solution design, attributes are stored as variables and functionalities are defined
by means of methods or procedures
...
Encapsulation not only bundles
important information of an object together, but also restricts access of the data and
methods from the outside world
...




Inheritance - OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables and methods
from their immediate super classes
...
This
makes it easier to define specific class and to create generalized classes from specific
ones
...
This is called
polymorphism, which allows a single interface performing tasks for different types
...


Design Process
Software design process can be perceived as series of well-defined steps
...




Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics
...




Application framework is defined
...
Further, these sub-systems and components may have their one set of sub-system
and components and creates hierarchical structure in the system
...
Each subDEPT OF CSE & IT
VSSUT, Burla

system or component is then treated as a system and decomposed further
...

Top-down design starts with a generalized model of system and keeps on defining the more
specific part of it
...

Top-down design is more suitable when the software solution needs to be designed from scratch
and specific details are unknown
...
It proceeds with
composing higher level of components by using basic or lower level components
...
With each higher level, the amount of abstraction is increased
...

Both, top-down and bottom-up approaches are not practical individually
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 10

SOFTWARE ANALYSIS & DESIGN TOOLS
Software analysis and design includes all activities, which help the transformation of
requirement specification into implementation
...
These requirement specifications come in
the shape of human readable and understandable documents, to which a computer has nothing to
do
...

Let us see few analysis and design tools used by software designers:
Data Flow Diagram
Data flow diagram is a graphical representation of data flow in an information system
...
The DFD does not
mention anything about how data flows through the system
...
The flowchart depicts flow of
control in program modules
...
DFD does
not contain any control or branch elements
...



Logical DFD - This type of DFD concentrates on the system process and flow of data in
the system
...




Physical DFD - This type of DFD shows how the data flow is actually implemented in
the system
...


DEPT OF CSE & IT
VSSUT, Burla

DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components -

Fig 10
...
Entities are represented
by rectangles with their respective names
...




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 movement is shown
from the base of arrow as its source towards head of the arrow as destination
...
Starting with a set of high-level
functions that a system performs, a DFD model hierarchically represents various sub-functions
...
Human mind is such that it can easily
understand any hierarchical model of a system – because in a hierarchical model, starting with a
very simple and abstract model of a system, different details of the system are slowly introduced
through different hierarchies
...
DFD is an elegant modeling technique that turns out to be
useful not only to represent the results of structured analysis of a software problem, but also for
several other applications such as showing the flow of documents or items in an organization
...
The data items
listed include all data flows and the contents of all data stores appearing on the DFDs in the DFD
model of a system
...
For example, a data dictionary
entry may represent that the data grossPay consists of the components regularPay and
overtimePay
...
Composite
data items can be defined in terms of primitive data items using the following data definition
operators:
+: denotes composition of two data items, e
...
a+b represents data a and b
...
e
...

For example, [a,b] represents either a occurs or b occurs
...

e
...
a+(b) represents either a occurs or a+b occurs
...
g
...
{name}*
represents zero or more instances of name data
...
g
...

/* */: Anything appearing within /* and */ is considered as a comment
...
A move consists of marking previously
unmarked square
...
e
...

As soon as either the human player or the computer wins, a message
congratulating the winner should be displayed
...
The computer always tries to win a game
...
2 (a) Level 0 (b) Level 1 DFD for Tic-Tac-Toe game

DEPT OF CSE & IT
VSSUT, Burla

It may be recalled that the DFD model of a system typically consists of several DFDs: level 0,
level 1, etc
...
Figure 10
...
The data dictionary for the model is given below
...
A consistent vocabulary for data items is very important,
since in large projects different engineers of the project have a tendency to use different
terms to refer to the same data, which unnecessary causes confusion
...

Balancing a DFD
The data that flow into or out of a bubble must match the data flow at the next level of DFD
...
The concept of balancing a DFD has been illustrated in fig
...
3
...
1 and the data item d2
flows into the bubble 0
...
In the next level, bubble 0
...
The decomposition is
balanced, as d1 and d3 flow out of the level 2 diagram and d2 flows in
...
10
...
It represents the
entire system as a single bubble
...
The various external entities with which the system interacts and the data flow occurring
between the system and the external entities are also represented
...
These
data flow arrows should be annotated with the corresponding data names
...
e
...
The context
diagram is also called as the level 0 DFD
...
Here, the term
“users of the system” also includes the external systems which supply data to or receive data
from the system
...
This is in contrast with the bubbles in all other levels which are
annotated with verbs
...

Example 1: RMS Calculating Software
...
In this example, the context diagram (fig
...
4) is simple to draw
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
4: Context Diagram

To develop the data flow model of a system, first the most abstract representation of the problem
is to be worked out
...
After, developing the context diagram, the higher-level DFDs have to be developed
...

Level 1 DFD: - To develop the level 1 DFD, examine the high-level functional requirements
...
We can then examine the input data to these functions
and the data output by these functions and represent them appropriately in the diagram
...

Such a bubble can be split in the lower DFD levels
...

Decomposition:Each bubble in the DFD represents a function performed by the system
...
Decomposition of a bubble
is also known as factoring or exploding a bubble
...
Too few bubbles at any level make that level
DEPT OF CSE & IT
VSSUT, Burla

superfluous
...
Also, too many bubbles, i
...
more than 7 bubbles at any level
of a DFD makes the DFD model hard to understand
...

Numbering of Bubbles:It is necessary to number the different bubbles occurring in the DFD
...
The bubble at the context
level is usually assigned the number 0 to indicate that it is the 0 level DFD
...
1, 0
...
3, etc, etc
...
1, x
...
3, etc
...

Example:A supermarket needs to develop the following software to encourage regular customers
...
Each customer who registers for this scheme is assigned a
unique customer number (CN) by the computer
...
In this case, the value of his purchase is
credited against his CN
...
Also, it
intends to award a 22 caret gold coin to every customer whose purchase exceeded
Rs
...
The entries against the CN are the reset on the day of every year after the prize
winners’ lists are generated
...
10
...
10
...
10
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
5: Context diagram for supermarket problem

DEPT OF CSE & IT
VSSUT, Burla

Fig
...
6: Level 1 diagram for supermarket problem

DEPT OF CSE & IT
VSSUT, Burla

Fig
...
7: Level 2 diagram for supermarket problem
Example: Trading-House Automation System (TAS)
...
The following are the
salient features of the system to be developed:
•

•

The trading house has a set of regular customers
...
The trading house maintains the names and
addresses of its regular customers
...
The
customers quote their CIN on every order they place
...
The credit-worthiness of the
customer is determined by analyzing the history of his payments to different bills sent
to him in the past
...

DEPT OF CSE & IT
VSSUT, Burla

•
•

•

•

•

If the customer is not credit-worthy, his orders are not processed any further and an
appropriate order rejection message is generated for the customer
...
The items in the order which the
trading house does not deal with, are not processed any further and an appropriate
apology message for the customer for these items is generated
...
If the items are available in the inventory in the desired
quantity, then
 A bill with the forwarding address of the customer is printed
...
The customer can produce this material
issue slip at the store house and take delivery of the items
...

If any of the ordered items are not available in the inventory in sufficient quantity to
satisfy the order, then these out-of-stock items along with the quantity ordered by the
customer and the CIN are stored in a “pending-order” file for the further processing to
be carried out when the purchase department issues the “generate indent” command
...
When a command to generate indents is issued, the system should
examine the “pending-order” file to determine the orders that are pending and
determine the total quantity required for each of the items
...

The system should also answer managerial queries regarding the statistics of different
items sold over any given period of time and the corresponding quantity sold and the
price realized
...
10
...
10
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
8: Context diagram for TAS

DEPT OF CSE & IT
VSSUT, Burla

Fig
...
9: Level 1 DFD for TAS
Data Dictionary for the DFD Model of TAS:
response: [bill + material-issue-slip, reject-message]
query: period /*query from manager regarding sales statistics */
period: [date + date, month, year, day]
date: year + month + day
year: integer
month: integer
day: integer
order: customer-id + {items + quantity}* + order#
accepted-order: order /* ordered items available in inventory */
DEPT OF CSE & IT
VSSUT, Burla

reject-message: order + message /*rejection message*/
pending-orders: customer-id + {items + quantity}*
customer-address: name + house# + street# + city + pin
name: string
house#: string
street#: string
city: string
pin: integer
customer-id: integer
customer-file: {customer-address}*
bill: {item + quantity + price}* + total-amount + customer-address + order#
material-issue-slip: message + item + quantity + customer-address
message: string
statistics: {item + quantity + price}*
sales-statistics: {statistics}* + date
quantity: integer
order#: integer /* unique order number generated by the program */
price: integer
total-amount: integer
generate-indent: command
indent: {indent + quantity}* + vendor-address
indents: {indent}*
vendor-address: customer-address
vendor-list: {vendor-address}*
item-file: {item}*
item: string
indent-request: command

DEPT OF CSE & IT
VSSUT, Burla

Commonly made errors while constructing a DFD model
Although DFDs are simple to understand and draw, students and practitioners alike encounter
similar types of problems while modelling software problems using DFDs
...
It is
therefore helpful to understand the different types of mistakes that users usually make while
constructing the DFD model of systems
...
A context diagram should depict the system as a single bubble
...
All external
entities interacting with the system should be represented only in the context diagram
...

It is a common oversight to have either too less or too many bubbles in a DFD
...
e
...

Many beginners leave different levels of DFD unbalanced
...
It is important to realize that a
DFD is the data flow representation of a system, and it does not represent control
information
...
A book can be searched in the library catalog by
inputting its name
...
If the book is not listed in the catalog, then an error message
is generated
...
10
...
But, this is control
information and should not be shown on the DFD
...
10
...

If a bubble A invokes either the bubble B or the bubble C depending upon some
conditions, we need only to represent the data that flows between bubbles A and B or
bubbles A and C and not the conditions depending on which the two modules are
invoked
...
A data store
cannot be connected to another data store or to an external entity
...
No function of
the system specified in its SRS document should be overlooked
...
e
...

Improper or unsatisfactory data dictionary
...
Some students and even practicing
engineers use symbolic data names such a, b, c, etc
...


Shortcomings of a DFD model
DFD models suffer from several shortcomings
...
However, a short label may not capture the entire
functionality of a bubble
...
g
...
Further, the find-book-position bubble may not
convey anything regarding what happens when the required book is missing
...
A DFD model does not
specify the order in which the different bubbles are executed
...

The method of carrying out decomposition to arrive at the successive levels and the
ultimate level to which decomposition is carried out are highly subjective and depend on
the choice and judgment of the analyst
...
Further, many times it is not
possible to say which DFD representation is superior or preferable to another one
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 11

STRUCTURED DESIGN
The aim of structured design is to transform the results of the structured analysis (i
...
a DFD
representation) into a structure chart
...

• Transform analysis
• Transaction analysis
Normally, one starts with the level 1 DFD, transforms it into module representation using either
the transform or the transaction analysis and then proceeds towards the lower-level DFDs
...
These are discussed in the subsequent subsections
...
e
...
Hence, the structure chart representation can be easily
implemented using some programming language
...
g
...

The basic building blocks which are used to design structure charts are the following:







Rectangular boxes: Represents a module
...

Data flow arrows: Arrows are annotated with data name; named data passes
from one module to another module in the direction of the arrow
...

Selection: Represented by a diamond symbol
...


Structure Chart vs
...
Flow chart is a convenient
technique to represent the flow of control in a program
...

• Data interchange among different modules is not represented in a flow chart
...

Transform Analysis
Transform analysis identifies the primary functional components (modules) and the high level
inputs and outputs for these components
...
g
...
g
...
Each input portion is
called an afferent branch
...
Each output
portion is called an efferent branch
...

In the next step of transform analysis, the structure chart is derived by drawing one functional
component for the central transform, and the afferent and efferent branches
...
Identifying the
highest level input and output transforms requires experience and skill
...

Processes which validate input or add information to them are not central transforms
...
The first level structure chart is produced by
representing each input and output unit as boxes and each central transform as a single box
...
Many levels of functional components
may be added
...
Factoring includes adding read and write modules, error-handling modules,
initialization and termination process, identifying customer modules, etc
...


DEPT OF CSE & IT
VSSUT, Burla

Example: Structure chart for the RMS software
For this example, the context diagram was drawn earlier
...
11
...


Fig
...
1: Level 1 DFD
By observing the level 1 DFD, we identify the validate-input as the afferent branch and writeoutput as the efferent branch
...
e
...
By applying the step 2 and step 3 of transform analysis, we get the structure chart
shown in fig
...
2
...
11
...
Transaction analysis
is useful while designing transaction processing programs
...

This is in contrast to a transform centered system which is characterized by similar processing
steps for each data item
...
A
simple way to identify a transaction is to check the input data
...
However,
some transaction may not require any input data
...

For each identified transaction, trace the input data to the output
...
These bubbles should be mapped to the same module on the
structure chart
...
Every transaction carries a tag, which identifies its type
...

The structure chart for the supermarket prize scheme software is shown in fig
...
3
...
11
...

A model in the context of software development can be graphical, textual, mathematical, or
program code-based
...

Models also facilitate the analysis and design procedures themselves
...
UML is primarily a graphical
modeling tool
...

Need for a model
An important reason behind constructing a model is that it helps manage complexity
...

In all these applications, the UML models can not only be used to document the results but also
to arrive at the results themselves
...
For example, a model developed for initial analysis and specification should be very
different from the one used for design
...

On the other hand, a model used for design purposes should capture all the design decisions
...


DEPT OF CSE & IT
VSSUT, Burla

Unified Modeling Language (UML)
UML, as the name implies, is a modeling language
...
It provides a set of notations (e
...

rectangles, lines, ellipses, etc
...
Like any other language,
UML has its own syntax (symbols and sentence formation rules) and semantics (meanings of
symbols and sentences)
...

Origin of UML
In the late 1980s and early 1990s, there was a proliferation of object-oriented design techniques
and notations
...
These diverse notations used to give rise to a lot of
confusion
...
The principles ones in use were:
• Object Management Technology [Rumbaugh 1991]
• Booch’s methodology [Booch 1991]
• Object-Oriented Software Engineering [Jacobson 1992]
• Odell’s methodology [Odell 1992]
• Shaler and Mellor methodology [Shaler 1992]
It is needless to say that UML has borrowed many concepts from these modeling techniques
...
UML
was adopted by Object Management Group (OMG) as a de facto standard in 1997
...


We shall see that UML contains an extensive set of notations and suggests construction of many
types of diagrams
...
The
elegance of UML, its adoption by OMG, and a strong industry backing have helped UML find
widespread acceptance
...


DEPT OF CSE & IT
VSSUT, Burla

UML Diagrams
UML can be used to construct nine different types of diagrams to capture five different views of
a system
...
; the
different UML diagrams provide different perspectives of the software system to be developed
and facilitate a comprehensive understanding of the system
...

The UML diagrams can capture the following five views of a system:
• User’s view
• Structural view
• Behavioral view
• Implementation view
• Environmental view

Fig
...
1: Different types of diagrams and views supported in UML
User’s view: This view defines the functionalities (facilities) made available by the system to
its users
...
The users’ view is a black-box view of the system where
the internal structure, the dynamic behavior of different system components, the
implementation etc
...
The users’ view is very different from all other views in the
sense that it is a functional model compared to the object model of all other views
...
This thinking is in fact the crux of any user centric development style
...
It also captures the
DEPT OF CSE & IT
VSSUT, Burla

relationships among the classes (objects)
...


Behavioral view: The behavioral view captures how objects interact with each other to realize
the system behavior
...


Implementation view: This view captures the important components of the system and their
dependencies
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 13

USE CASE DIAGRAM
Use Case Model
The use case model for any system consists of a set of “use cases”
...
A simple way to find all
the use cases of a system is to ask the question: “What the users can do using the system?” Thus
for the Library Information System (LIS), the use cases could be:
• issue-book
• query-book
• return-book
• create-member
• add-book, etc
Use cases correspond to the high-level functional requirements
...
To complete each transaction may involve either a single message or
multiple message exchanges between the user and the system to complete
...
The use cases do not mention any specific algorithm to be used or the
internal data representation, internal structure of the software, etc
...
These interactions consist
of one mainline sequence
...
The mainline sequence is the most occurring sequence of interaction
...
Several variations to the main line sequence may
also exist
...
For the bank ATM example, variations or alternate scenarios may occur, if the
password is invalid or the amount to be withdrawn exceeds the amount balance
...
A use case can be viewed as a set of related scenarios tied
together by a common goal
...
Each scenario is a single path of user events and system
activity through the use case
...
In the use case diagram, each use case is represented by an ellipse with
the name of the use case written inside the ellipse
...
e
...
The name of the system
being modeled (such as Library Information System) appears inside the rectangle
...
Each stick
person icon is normally referred to as an actor
...
It is possible that the same user may play the role of multiple actors
...
The line connecting the actor and the use case is called
the communication relationship
...
Both the human users and the external systems can be represented by
stick person icons
...

Example 1:
Tic-Tac-Toe Computer Game
Tic-tac-toe is a computer game in which a human player and the computer make
alternative moves on a 3×3 square
...
The player who first places three consecutive marks along a
straight line on the square (i
...
along a row, column, or diagonal) wins the game
...
If neither player manages to get
three consecutive marks along a straight line, but all the squares on the board are
filled up, then the game is drawn
...

The use case model for the Tic-tac-toe problem is shown in fig
...
1
...
Note that the use case “get-usermove” is not used here
...


Fig
...
1: Use case model for tic-tac-toe game
DEPT OF CSE & IT
VSSUT, Burla

Text Description
Each ellipse on the use case diagram should be accompanied by a text description
...
It should include all the behavior associated with the use case in
terms of the mainline sequence, different variations to the normal behavior, the system responses
associated with the use case, the exceptional conditions that may occur in the behavior, etc
...
The text description may be informal, but some structuring is
recommended
...

Contact persons: This section lists the personnel of the client organization with whom the use
case was discussed, date and time of the meeting, etc
...

Pre-condition: The preconditions would describe the state of the system before the use case
execution starts
...

Non-functional requirements: This could contain the important constraints for the design and
implementation, such as platform and environment conditions, qualitative statements, response
time requirements, etc
...
Obviously, errors that are not domain
related, such as software errors, need not be discussed here
...

Specific user interface requirements: These contain specific requirements for the user
interface of the use case
...

Document references: This part contains references to specific domain-related documents
which may be useful to understand the system operation
Example 2:
A supermarket needs to develop the following software to encourage regular
customers
...
Each customer who registers
for this scheme is assigned a unique customer number (CN) by the computer
...

In this case, the value of his purchase is credited against his CN
...
Also, it intends to award a 22 caret
gold coin to every customer whose purchase exceeded Rs
...
The entries
against the CN are the reset on the day of every year after the prize winners’ lists
are generated
...
13
...
As discussed
earlier, the use cases correspond to the high-level functional requirements
...
As a sample, the text description for the use case “register-customer” is shown
...
13
...


Scenario 1: Mainline sequence
1
...

2
...

Customer: enter the necessary values
...
System: display the generated id and the message that the customer has been
successfully registered
...
System: displays the message that the customer has already registered
...
System: displays the message that some input information has not been
entered
...

The description for other use cases is written in a similar fashion
...

They along with the accompanying text description serve as a type of requirements specification
of the system and form the core model to which all other models must conform
...
Another possible use
is in preparing the documentation (e
...
users’ manual) targeted at each category of user
...

Factoring of use cases
It is often desirable to factor use cases into component use cases
...
First, complex use cases need to be factored into simpler use
cases
...
Without
decomposition, the interaction diagrams for complex use cases may become too large to be
accommodated on a single sized (A4) paper
...
Factoring would make it possible to define
such behavior only once and reuse it whenever required
...
This makes analysis of the class design
much simpler and elegant
...
Factoring of use cases should not
be done except for achieving the above two objectives
...

DEPT OF CSE & IT
VSSUT, Burla

UML offers three mechanisms for factoring of use cases as follows:
1
...
Generalization works the same
way with use cases as it does with classes
...
The notation is the same too (as shown in fig
...
3)
...


Fig
...
3: Representation of use case generalization
Includes
The includes relationship in the older versions of UML (prior to UML 1
...
The includes relationship involves one use case including the
behavior of another use case in its sequence of events and actions
...
The factoring of such behavior will help in not repeating the specification and
implementation across different use cases
...
It can also be gainfully
employed to decompose a large and complex use cases into more manageable parts
...
13
...
In the includes relationship, a base use case compulsorily and automatically
DEPT OF CSE & IT
VSSUT, Burla

includes the behavior of the common use cases
...
13
...
The base use case may
include several use cases
...
The common use case becomes a separate use case and the independent
text description should be provided for it
...
13
...
13
...
An optional system behavior is extended only under certain
conditions
...
13
...
The extends relationship is similar to generalization
...
The extension points are points within the use case where variation
to the mainline (normal) action sequence may occur
...


Fig
...
6: Example use case extension
Organization of use cases
When the use cases are factored, they are organized hierarchically
...
13
...
Top-level use
cases are super-ordinate to the refined use cases
...
Note that only the complex use cases should be decomposed and organized
in a hierarchy
...
The functionality of the superordinate use cases is traceable to their sub-ordinate use cases
...
In
the highest level of the use case model, only the fundamental use cases are shown
...
Therefore, this level is also referred to as the context diagram
...
In the top-level diagram, only those use
cases with which external users of the system
...
Any number of levels involving the subsystems may be
utilized
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
7: Hierarchical organization of use cases

DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 14

CLASS DIAGRAMS
A class diagram describes the static structure of a system
...
The static structure of a system comprises of a number of class diagrams and
their dependencies
...

Classes
The classes represent entities with common features, i
...
attributes and operations
...
Classes have a mandatory name
compartment where the name is written centered in boldface
...
The class names are usually chosen to be
singular nouns
...
A class may appear on
several diagrams
...

Attributes
An attribute is a named property of a class
...

Attributes are listed with their names, and may optionally contain specification of their type, an
initial value, and constraints
...
Typically, the first letter of a class name is a small letter
...

bookName : String
Operation
Operation is the implementation of a service that can be requested from any object of the class to
affect behaviour
...
A
class may have any number of operations or no operation at all
...
Abstract operations are written in italics
...
An operation may
have a return type consisting of a single return type expression
...

issueBook(in bookName):Boolean

Association
Associations are needed to enable objects to communicate with each other
...
The association relation between two objects is called object
connection or link
...
A link is a physical or conceptual connection
between object instances
...
Here,
DEPT OF CSE & IT
VSSUT, Burla

borrowed is the connection between the objects Amit and Graph Theory book
...
e
...
An association describes a
group of links with a common structure and common semantics
...
Here, borrows is the association between the class
LibraryMember and the class Book
...
However, three or more different classes can be involved in an association
...
In this case, it is usually assumed
that two different objects of the class are linked by the association relationship
...

Fig
...
1 illustrates the graphical representation of the association relation
...
An arrowhead may be placed on the association
line to indicate the reading direction of the association
...
On each side of the
association relation, the multiplicity is noted as an individual number or as a value range
...
Value ranges
of multiplicity are noted by specifying the minimum and maximum value, separated by two dots, e
...

1
...
An asterisk is a wild card and means many (zero or more)
...
14
...
Observe that associations (and links)
appear as verbs in the problem statement
...
14
...

Thus, associations can be implemented using pointers from one object class to another
...
Some CASE tools use the role names of the association
relation for the corresponding automatically generated attribute
...
The aggregate takes the responsibility of forwarding messages to the appropriate parts
...
When an instance of one
object contains instances of some other objects, then aggregation (or composition) relationship exists
between the composite object and the component object
...
The number of instances of the component class
aggregated can also be shown as in fig
...
2

Fig
...
2: Representation of aggregation
Aggregation relationship cannot be reflexive (i
...
recursive)
...
Also, the aggregation relation is not symmetric
...
However, the aggregation relationship can be transitive
...


Composition
Composition is a stricter form of aggregation, in which the parts are existence-dependent on the
whole
...
When the whole is
created, the parts are created and when the whole is destroyed, the parts are destroyed
...
As soon as the invoice object is
created, all the invoice items in it are created and as soon as the invoice object is destroyed, all
invoice items in it are also destroyed
...
An example of the composition relationship is shown in fig
...
3

Fig 14
...
Aggregation vs
...
Aggregation is a stronger
relationship where one is a part of the other
...

 Association relationship can be reflexive (objects can have relation to itself), but
aggregation cannot be reflexive
...

 Composition has the property of exclusive aggregation i
...
an object can be a part of
only one composite at a time
...
For example,
a Wall may be a part of one or more Room objects
...
e
...





in general, the lifetime of parts and composite coincides
parts with non-fixed multiplicity may be created after composite itself
parts might be explicitly removed before the death of the composite

For example, when a Frame is created, it has to be attached to an enclosing Window
...


Inheritance vs
...
Inheritance means
that the object of the derived class inherits the properties of the base class; aggregation means
that the object of the whole has objects of the part
...




Inheritance is used to model a “generic-specific” relationship between classes whereas
aggregation/composition is used to model a “whole-part” relationship between classes
...
e
...

Inheritance is defined statically
...
Aggregation is defined
dynamically and can be changed at run-time
...






For example, consider this situation in a business system
...
Initially we might be tempted to model it as in Fig 14
...

But in fact, during its lifetime, a business partner might become a customer as well as a
supplier, or it might change from one to the other
...
4(b)
...
Here, we have only two types
...
But what if there were several different types and combinations
thereof? The inheritance tree would be absolutely incomprehensible
...
e
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
4 a) Representation of BusinessPartner, Customer, Supplier relationship
using inheritance

Fig
...
4 b) Representation of BusinessPartner, Customer, Supplier relationship
using aggregation

DEPT OF CSE & IT
VSSUT, Burla

• The advantage of aggregation is the integrity of encapsulation
...
The significant
disadvantage of aggregation is the increase in the number of objects and their relationships
...
But the
significant disadvantage is that it breaks encapsulation, which implies implementation dependence
...
Typically, each interaction diagram realizes the behavior of a single use case
...

There are two kinds of interaction diagrams: sequence diagrams and collaboration diagrams
...
However, they are both useful
...
The interaction diagrams can
be considered as a major tool in the design methodology
...
The chart is read
from top to bottom
...
Inside the box the name of the object is written with a colon
separating it from the name of the class and both the name of the object and the class are underlined
...
However, if some object is created during the execution of the use case and
participates in the interaction (e
...
a method call), then the object should be shown at the appropriate
place on the diagram where it is created
...
The
lifeline indicates the existence of the object at any particular point of time
...
Each message is indicated as an arrow between the life line of two objects
...
That is, reading the diagram
from the top to the bottom would show the sequence in which the messages occur
...
Some control information can also be included
...

• A condition (e
...
[invalid]) indicates that a message is sent, only if the condition is true
...
The basis of
the iteration can also be indicated e
...
[for every book object]
...
15
...
The development of the sequence diagram in the development methodology would help
us in determining the responsibilities of the different classes; i
...
what methods should be supported
by each class
...
15
...
This is unlike a
sequence diagram which shows only the behavioral aspects
...
In this diagram, an object is also
called a collaborator
...
The link between objects is shown as a solid line and can be used to send
messages between two objects
...

Messages are prefixed with sequence numbers because they are only way to describe the relative
sequencing of the messages in this diagram
...
15
...
15
...
The use of the collaboration diagrams in our development process would be to
help us to determine which classes are associated with which other classes
...
2: Collaboration diagram for the renew book use case

DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 16

ACTIVITY AND STATE CHART DIAGRAM
The activity diagram is possibly one modeling element which was not present in any of the
predecessors of UML
...
It is possibly based on the event diagram of Odell [1992] through the notation is very
different from that used by Odell
...
An activity is a state with
an internal action and one or more outgoing transitions which automatically follow the termination
of the internal activity
...
An interesting feature of the activity diagrams is the swim lanes
...
g
...

hostel office
...

The activities in a swim lane can be assigned to some model elements, e
...
classes or some
component, etc
...
This is carried out during
the initial stages of requirements analysis and specification
...
Later these diagrams can be
used to develop interaction diagrams which help to allocate activities (responsibilities) to classes
...
16
...
This
shows the part played by different components of the Institute in the admission procedure
...
After all these activities complete (this synchronization is represented as a horizontal
line), the identity card can be issued to a student by the Academic section
...
16
...
procedural flow charts
Activity diagrams are similar to the procedural flow charts
...

STATE CHART DIAGRAM
A state chart diagram is normally used to model how the state of an object changes in its lifetime
...
However, if we are interested in modeling some behavior that involves several
objects collaborating with each other, state chart diagram is not appropriate
...


DEPT OF CSE & IT
VSSUT, Burla

A FSM consists of a finite number of states corresponding to those of the object being modeled
...
The FSM formalism existed long before
the object-oriented technology and has been used for a wide variety of applications
...

A major disadvantage of the FSM formalism is the state explosion problem
...
This problem
is overcome in UML by using state charts
...
A state chart is a hierarchical model of a system and introduces the concept of a composite
state (also called nested state)
...
Activities are associated with states and can take longer
...

The basic elements of the state chart diagram are as follows:





Initial state- This is represented as a filled circle
...

State- These are represented by rectangles with rounded corners
...
Normally, the name of the
event which causes the transition is places alongside the arrow
...
A guard is a Boolean logic condition
...
The syntax for the label of the transition is shown in 3 parts: event
[guard]/action
...

16
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
2: State chart diagram for an order object
Activity diagram vs
...
Activity
diagram is essentially a flowchart showing flow of control from activity to activity
...

An activity diagram is a special case of a state chart diagram in which all or most of the states
are activity states and all or most of the transitions are triggered by completion of activities in
the source state (An activity is an ongoing non-atomic execution within a state machine)
...
State
chart diagrams may be attached to classes, use cases, or entire systems in order to visualize,
specify, and document the dynamics of an individual object
...
The programmers adhere to standard and well
defined style of coding which they call their coding standard
...

Promotes good programming practices
...
A programming
language should have the following features:
Characteristics of a Programming Language


Readability: A good high-level language will allow programs to be written in some ways
that resemble a quite-English description of the underlying algorithms
...




Portability: High-level languages, being essentially machine independent, should be able
to develop portable software
...




Brevity: Language should have the ability to implement the algorithm with less amount
of code
...




Error checking: Being human, a programmer is likely to make many mistakes in the
development of a computer program
...




Cost: The ultimate cost of a programming language is a function of many of its
characteristics
...




Quick translation: It should admit quick translation
...




Modularity: It is desirable that programs can be developed in the language as a
collection of separately compiled modules, with appropriate mechanisms for ensuring
self-consistency between these modules
...


A coding standard lists several rules to be followed during coding, such as the way variables are
to be named, the way the code is to be laid out, error return conventions, etc
...

The following are some representative coding standards
...
Rules for limiting the use of global: These rules list what types of data can be declared
global and what cannot
...
Contents of the headers preceding codes for different modules: The information
contained in the headers of different modules should be standard for an organization
...
The following are some standard header data:
• Name of the module
...

• Author’s name
...

• Synopsis of the module
...

• Global variables accessed/modified by the module
...
Naming conventions for global variables, local variables, and constant identifiers: A
possible naming convention can be that global variable names always start with a capital
letter, local variable names are made of small letters, and constant names are always
capital letters
...
Error return conventions and exception handling mechanisms: The way error
conditions are reported by different functions in a program are handled should be
standard within an organization
...

The following are some representative coding guidelines recommended by many software
development organizations
...
Do not use a coding style that is too clever or too difficult to understand: Code
should be easy to understand
...
Clever coding can obscure meaning of the
code and hamper understanding
...

2
...
An
obscure side effect is one that is not obvious from a casual examination of the code
...
For example, if a
global variable is changed obscurely in a called module or some file I/O is performed
which is difficult to infer from the function’s name and header information, it becomes
difficult for anybody trying to understand the code
...
Do not use an identifier for multiple purposes: Programmers often use the same
identifier to denote several temporary entities
...
The rationale that is
usually given by these programmers for such multiple uses of variables is memory
efficiency, e
...
three variables use up three memory locations, whereas the same variable
used in three different ways uses just one memory location
...
Some of the problems
caused by use of variables for multiple purposes as follows:


Each variable should be given a descriptive name indicating its purpose
...
Use of a variable for
multiple purposes can lead to confusion and make it difficult for somebody trying to
read and understand the code
...

4
...

5
...
For the same reason, lengthy functions are likely to have disproportionately
larger number of bugs
...
Do not use goto statements: Use of goto statements makes a program unstructured and
very difficult to understand
...
Code reviews are extremely cost-effective strategies for
reduction in coding errors and to produce high quality code
...
These two types code review techniques are code inspection
and code walk through
...
In this technique, after a module has
been coded, successfully compiled and all syntax errors eliminated
...
Each member selects some test cases and simulates execution of the code by
hand (i
...
trace execution through each statement and function execution)
...
The members
note down their findings to discuss these in a walk through meeting where the coder of the
module is present
...
Of course, these guidelines are based on personal experience, common sense, and
several subjective factors
...
Some of these guidelines are the following:
 The team performing code walk through should not be either too big or too small
...



Discussion should focus on discovery of errors and not on how to fix the discovered
errors
...


Code Inspection
In contrast to code walk through, the aim of code inspection is to discover some common types
of errors caused due to oversight and improper programming
...
For instance, consider the classical
error of writing a procedure that modifies a formal parameter while the calling routine calls that
procedure with a constant actual parameter
...
In addition to the commonly made errors, adherence to coding
standards is also checked during code inspection
...
Such a list of commonly committed errors can be
used during code inspection to look out for possible errors
...

Jumps into loops
...

Incompatible assignments
...

Improper storage allocation and deallocation
...

Use of incorrect logical operators or incorrect precedence among operators
...

Comparison of equally of floating point variables, etc
...
This type of testing relies heavily on walk throughs,
inspection, and formal verification
...
The software
development philosophy is based on avoiding software defects by using a rigorous inspection
process
...
The name ‘clean room’ was
derived from the analogy with semi-conductor fabrication units
...
In this kind of development,
inspections to check the consistency of the components with their specifications has replaced
unit-testing
...

The clean room approach to software development is based on five characteristics:









Formal specification: The software to be developed is formally specified
...

Incremental development: The software is partitioned into increments which are
developed and validated separately using the clean room process
...

Structured programming: Only a limited number of control and data abstraction
constructs are used
...

Static verification: The developed software is statically verified using rigorous software
inspections
...
These statistical tests are based on the operational profile
which is developed in parallel with the system specification
...


Software Documentation
When various kinds of software products are developed then not only the executable files and the
source code are developed but also various kinds of documents such as users’ manual, software
requirements specification (SRS) documents, design documents, test documents, installation
manual, etc are also developed as part of any software engineering process
...
Good documents are very useful and
server the following purposes:
o Good documents enhance understandability and maintainability of a software
product
...

o Use documents help the users in effectively using the system
...

Even when an engineer leaves the organization, and a new engineer comes in, he
can build up the required knowledge easily
...
The project manager knows that measurable progress is
achieved if a piece of work is done and the required documents have been
produced and reviewed
...
Internal documentation is provided through appropriate module headers and comments
embedded in the source code
...
Careful experiments suggest that out
of all types of internal documentation meaningful variable names is most useful in understanding
the code
...
The research finding is obviously true when comments are written without
thought
...

a = 10; /* a made 10 */
But even when code is carefully commented, meaningful variable names still are more helpful in
understanding a piece of code
...

External documentation is provided through various types of supporting documents such as
users’ manual, software requirements specification document, design document, test documents,
etc
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 18

TESTING
Program Testing
Testing a program consists of providing the program with a set of test inputs (or test cases) and
observing if the program behaves as expected
...

Some commonly used terms associated with testing are:
 Failure: This is a manifestation of an error (or defect or bug)
...

 Test case: This is the triplet [I,S,O], where I is the data input to the system, S is the state
of the system at which the data is input, and O is the expected output of the system
...

Aim of Testing
The aim of the testing process is to identify all defects existing in a software product
...
This is because of the fact that the input data
domain of most software products is very large
...
Even with this practical
limitation of the testing process, the importance of testing should not be underestimated
...
Thus
testing provides a practical way of reducing defects in a system and increasing the users’
confidence in a developed system
...
Thus
while verification is concerned with phase containment of errors, the aim of validation is that the
final product be error free
...

Therefore, we must design an optional test suite that is of reasonable size and can uncover as
many errors existing in the system as possible
...
e
...
Thus, the number of random test cases in a test suite is, in general, not an indication of the
effectiveness of the testing
...
Consider the following example code segment which finds the greater of two
integer values x and y
...

if (x>y)
max = x;
else
max = x;
For the above code segment, the test suite, {(x=3,y=2);(x=2,y=3)} can detect the error, whereas a
larger test suite {(x=3,y=2);(x=4,y=3);(x=5,y=1)} does not detect the error
...
This implies that the test suite
should be carefully designed than picked randomly
...
In an optimal test suite, each test case is designed to
detect different errors
...
Structural Testing
In the black-box testing approach, test cases are designed using only the functional specification
of the software, i
...
without any knowledge of the internal structure of the software
...
On the other hand, in the white-box
testing approach, designing test cases requires thorough knowledge about the internal structure
of software, and therefore the white-box testing is called structural testing
...
testing in the small
Software products are normally tested first at the individual component (or unit) level
...
After testing all the components individually, the components
are slowly integrated and tested at each level of integration (integration testing)
...
Integration and system testing are known as
testing in the large
...
Unit testing
(or module testing) is the testing of different units (or modules) of a system in isolation
...
That is, besides the module under test itself, the following steps are
needed in order to be able to test the module:
• The procedures belonging to other modules that the module under test calls
...

• A procedure to call the functions of the module under test with appropriate parameters
...
The role of stub and driver
modules is pictorially shown in fig
...
1
...
For example, a
stub procedure may produce the expected behavior using a simple table lookup mechanism
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
1: Unit testing with the help of driver and stub modules
Black Box Testing
In the black-box testing, test cases are designed from an examination of the input/output values
only and no knowledge of design or code is required
...

• Equivalence class portioning
• Boundary value analysis
Equivalence Class Partitioning
In this approach, the domain of input values to a program is partitioned into a set of equivalence
classes
...
The main idea behind defining the equivalence
classes is that testing the code with any one value belonging to an equivalence class is as good as
testing the software with any other value belonging to that equivalence class
...
The following are
some general guidelines for designing the equivalence classes:
1
...

2
...


DEPT OF CSE & IT
VSSUT, Burla

Example 1: For a software that computes the square root of an input integer which can assume
values in the range of 0 to 5000, there are three equivalence classes: The set of negative integers,
the set of integers in the range of 0 and 5000, and the integers larger than 5000
...

Example 2: Design the black-box test suite for the following program
...
It reads two integer pairs (m1,
c1) and (m2, c2) defining the two straight lines of the form y=mx + c
...

Boundary Value Analysis
A type of programming error frequently occurs at the boundaries of different equivalence classes
of inputs
...

Programmers often fail to see the special processing required by the input values that lie at the
boundary of the different equivalence classes
...
Boundary value analysis leads to selection of test cases at
the boundaries of the different equivalence classes
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 20

WHITE-BOX TESTING
One white-box testing strategy is said to be stronger than another strategy, if all types of errors
detected by the first testing strategy is also detected by the second testing strategy, and the
second testing strategy additionally detects some more types of errors
...
The concepts of stronger and complementary testing are schematically
illustrated in fig
...
1
...
20
...
The principal idea governing the statement coverage strategy is that
unless a statement is executed, it is very hard to determine if an error exists in that statement
...
However, executing some statement
once and observing that it behaves properly for that input value is no guarantee that it will

DEPT OF CSE & IT
VSSUT, Burla

behave correctly for all input values
...

Example: Consider the Euclid’s GCD computation algorithm:
int compute_gcd(x, y)
int x, y;
{
1 while (x! = y)
{
2 if (x>y) then
3 x= x – y;
4 else y= y – x;
5}
6 return x;
}
By choosing the test set {(x=3, y=3), (x=4, y=3), (x=3, y=4)}, we can exercise the program such
that all statements are executed at least once
...
Branch testing is also known as edge testing as
in this testing scheme, each edge of a program’s control flow graph is traversed at least once
...
For Euclid’s GCD computation
algorithm, the test cases for branch coverage can be {(x=3, y=3), (x=3, y=2), (x=4, y=3), (x=3,
y=4)}
...
For example, in the conditional
expression ((c1
...
c2)
...
c3), the components c1, c2 and c3 are each made to assume both true
and false values
...
Thus, condition testing is a stronger testing strategy than branch testing and
branch testing is stronger testing strategy than the statement coverage-based testing
...
Thus, for condition coverage, the number of test cases increases exponentially with the
number of component conditions
...


DEPT OF CSE & IT
VSSUT, Burla

Path Coverage
The path coverage-based testing strategy requires us to design test cases such that all linearly
independent paths in the program are executed at least once
...

Control Flow Graph (CFG)
A control flow graph describes the sequence in which the different instructions of a program get
executed
...
In order to draw the control flow graph of a program, all the statements of a program
must be numbered first
...
20
...
An edge from one node to another node exists if the execution of
the statement representing the first node can result in the transfer of control to the other node
...
After all, a program is made up from these
types of statements
...
20
...
It is important to note that for the iteration type of constructs such as the while
construct, the loop condition is tested only at the beginning of the loop and therefore the control
flow from the last statement of the loop is always to the top of the loop
...
20
...

Sequence:
a=5;
b = a*2-1;

Fig
...
2 (a): CFG for sequence constructs
Selection:
if (a>b)
c = 3;

DEPT OF CSE & IT
VSSUT, Burla

else
c =5;
c=c*c;

Fig
...
2 (b): CFG for selection constructs
Iteration :
while (a>b)
{
b=b -1;
b=b*a;
}
c = a+b;

Fig
...
2 (c): CFG for and iteration type of constructs
DEPT OF CSE & IT
VSSUT, Burla

EUCLID’S GCD Computation Algorithm

Fig
...
3: Control flow diagram

DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 21
Path
A path through a program is a node and edge sequence from the starting node to a terminal node
of the control flow graph of a program
...

Writing test cases to cover all the paths of a typical program is impractical
...

Linearly independent path
A linearly independent path is any path through the program that introduces at least one new
edge that is not included in any other linearly independent paths
...
This is
because; any path having a new node automatically implies that it has a new edge
...

Control Flow Graph
In order to understand the path coverage-based testing strategy, it is very much necessary to
understand the control flow graph (CFG) of a program
...

Linearly Independent Path
The path-coverage testing does not require coverage of all paths but only coverage of linearly
independent paths
...

Cyclomatic Complexity
For more complicated programs it is not easy to determine the number of independent paths of the
program
...
Also, the McCabe’s cyclomatic complexity is very simple to
compute
...
Though the McCabe’s metric does
not directly identify the linearly independent paths, but it informs approximately how many paths to
look for
...
The answers computed by the
three methods are guaranteed to agree
...

For the CFG of example shown in fig
...
3, E=7 and N=6
...

Method 2:
An alternative way of computing the cyclomatic complexity of a program from an inspection
of its control flow graph is as follows:
V(G) = Total number of bounded areas + 1
In the program’s control flow graph G, any region enclosed by nodes and edges can be called
as a bounded area
...

But, what if the graph G is not planar, i
...
however you draw the graph, two or more edges
intersect? Actually, it can be shown that structured programs always yield planar graphs
...
Therefore, for non-structured
programs, this way of computing the McCabe’s cyclomatic complexity cannot be used
...

Therefore, the McCabe’s metric provides a quantitative measure of testing difficulty and the
ultimate reliability
...
20
...
Therefore the cyclomatic complexity, computing
with this method is also 2+1 = 3
...
On the other
hand, the other method of computing CFGs is more amenable to automation, i
...
it can be
easily coded into a program which can be used to determine the cyclomatic complexities of
arbitrary CFGs
...
If N is the number of decision statement of a
program, then the McCabe’s metric is equal to N+1
...

For a statement numbered S, let
DEF(S) = {X/statement S contains a definition of X}, and
USES(S) = {X/statement S contains a use of X}
For the statement S:a=b+c;, DEF(S) = {a}
...
The definition of variable X at
statement S is said to be live at statement S1, if there exists a path from statement S to statement S1
which does not contain any definition of X
...
One simple data flow testing strategy is to require that every DU
chain be covered at least once
...


Mutation Testing
In mutation testing, the software is first tested by using an initial test suite built up from the different
white box testing strategies
...
The
idea behind mutation testing is to make few arbitrary changes to a program at a time
...
A
mutated program is tested against the full test suite of the program
...
If
a mutant remains alive even after all the test cases have been exhausted, the test data is enhanced to
kill the mutant
...
These primitive changes can be
alterations such as changing an arithmetic operator, changing the value of a constant, changing a data
type, etc
...

Since mutation testing generates a large number of mutants and requires us to check each mutant
with the full test suite, it is not suitable for manual testing
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 22

DEBUGGING, INTEGRATION AND SYSTEM TESTING
Need for Debugging
Once errors are identified in a program code, it is necessary to first identify the precise program
statements responsible for the errors and then to fix them
...

Debugging Approaches
The following are some of the approaches popularly adopted by programmers for debugging
...
In this
approach, the program is loaded with print statements to print the intermediate values
with the hope that some of the printed values will help to identify the statement in error
...

Backtracking:
This is also a fairly common approach
...
Unfortunately, as the number of source lines to be traced back
increases, the number of potential backward paths increases and may become
unmanageably large thus limiting the use of this approach
...
A related technique of
identification of the error from the error symptom is the software fault tree analysis
...
Here the search space is reduced by defining
slices
...


DEPT OF CSE & IT
VSSUT, Burla

Debugging Guidelines
Debugging is often carried out by programmers based on their ingenuity
...
Trying
to debug based on a partial understanding of the system design and implementation may
require an inordinate amount of effort to be put into debugging even simple problems
...
In such cases, a
common mistake that novice programmers often make is attempting not to fix the error
but its symptoms
...

Therefore after every round of error-fixing, regression testing must be carried out
...
We can classify these into two broad categories of program analysis tools:




Static Analysis tools
Dynamic Analysis tools
Static program analysis tools

Static Analysis Tool is also a program analysis tool
...
Typically, static analysis tools analyze
some structural representation of a program to arrive at certain analytical conclusions, e
...
that
some structural properties hold
...

Code walk throughs and code inspections might be considered as static analysis methods
...
So, a compiler can be
considered to be a static program analysis tool
...
A dynamic analyzer usually instruments the code
(i
...
adds additional statements in the source code to collect program execution traces)
...
After the software has been tested with its full test suite and its behavior recorded, the
DEPT OF CSE & IT
VSSUT, Burla

dynamic analysis tool caries out a post execution analysis and produces reports which describe
the structural coverage that has been achieved by the complete test suite for the program
...

Normally the dynamic analysis results are reported in the form of a histogram or a pie chart to
describe the structural coverage achieved for different modules of the program
...
The dynamic analysis results the extent of testing performed in white-box
mode
...
Further, dynamic analysis results can help to eliminate redundant test cases from the
test suite
...
e
...
During integration
testing, different modules of a system are integrated in a planned manner using an integration
plan
...
After each integration step, the partially integrated system is tested
...
The structure
chart (or module dependency graph) denotes the order in which different modules call each
other
...

Integration test approaches
There are four types of integration testing approaches
...
Those approaches are the following:





Big bang approach
Bottom- up approach
Top-down approach
Mixed-approach

Big-Bang Integration Testing
It is the simplest integration testing approach, where all the modules making up a system are
integrated in a single step
...
However, this technique is practicable only for very small systems
...
Therefore, debugging errors reported during big bang integration testing are very
expensive to fix
...
A
subsystem might consist of many modules which communicate among each other through welldefined interfaces
...
Both control and data interfaces are tested
...
A principal advantage of bottom-up
integration testing is that several disjoint subsystems can be tested simultaneously
...
A disadvantage of bottomup testing is the complexity that occurs when the system is made up of a large number of small
subsystems
...


DEPT OF CSE & IT
VSSUT, Burla

Top-Down Integration Testing
Top-down integration testing starts with the main routine and one or two subordinate routines in
the system
...
Top-down integration testing approach requires the
use of program stubs to simulate the effect of lower-level routines that are called by the routines
under test
...
A disadvantage of
the top-down integration testing approach is that in the absence of lower-level routines, many
times it may become difficult to exercise the top-level routines in the desired manner since the
lower-level routines perform several low-level functions such as I/O
...
In top-down approach, testing can start only after the top-level
modules have been coded and unit tested
...
The mixed approach overcomes this shortcoming of the topdown and bottom-up approaches
...
Therefore, this is one of the most commonly used integration testing
approaches
...
Incremental Testing
The different integration testing strategies are either phased or incremental
...

o In phased integration, a group of related modules are added to the partial system
each time
...
However, when failures are detected, it is easier to debug the system in the
incremental testing approach since it is known that the error is caused by addition of a single
module
...

System testing
System tests are designed to validate a fully developed system to assure that it meets its
requirements
...
Alpha testing refers to the system testing carried out by the test team
within the developing organization
...
Beta testing is the system testing performed by a select group of friendly
customers
...
Acceptance testing is the system testing performed by the customer
to determine whether he should accept the delivery of the system
...
Broadly, these tests can be classified into functionality and performance tests
...
The performance test tests the
conformance of the system with the nonfunctional requirements of the system
...
There are several types of performance testing
...
The types of performance testing to be carried
out on a system depend on the different non-functional requirements of the system documented
in the SRS document
...

• Stress testing
• Volume testing
• Configuration testing
• Compatibility testing
• Regression testing
• Recovery testing
• Maintenance testing
• Documentation testing
• Usability testing
Stress Testing -Stress testing is also known as endurance testing
...
Stress tests are
black box tests which are designed to impose a range of abnormal and even illegal input
conditions so as to stress the capabilities of the software
...
are tested beyond the designed capacity
...
A realtime system might be tested to determine the effect of simultaneous arrival of several
high-priority interrupts
...
For example, if the nonfunctional requirement specification states that the response time should not be more than
20 secs per transaction when 60 concurrent users are working, then during the stress
testing the response time is checked with 60 users working simultaneously
...
) have been designed to successfully extraordinary situations
...

Configuration Testing - This is used to analyze system behavior in various hardware
and software configurations specified in the requirements
...
For instance, we might define a minimal
system to serve a single user, and other extension configurations to serve additional users
...

Compatibility Testing -This type of testing is required when the system interfaces with
other types of systems
...
For instance, if the system needs to communicate with a large
database system to retrieve information, compatibility testing is required to test the speed
and accuracy of data retrieval
...
Regression testing is the practice of running an old test suite after each
change to the system or after each bug fix to ensure that no new bug has been introduced
due to the change or the bug fix
...

Recovery Testing -Recovery testing tests the response of the system to the presence of
faults, or loss of power, devices, services, data, etc
...
For example, the printer can be
disconnected to check if the system hangs
...

Maintenance Testing- This testing addresses the diagnostic programs, and other
procedures that are required to be developed to help maintenance of the system
...

Documentation Testing- It is checked that the required user manual, maintenance
manuals, and technical manuals exist and are consistent
...


DEPT OF CSE & IT
VSSUT, Burla

Usability Testing- Usability testing concerns checking the user interface to see if it
meets all user requirements concerning the user interface
...

Error Seeding
Sometimes the customer might specify the maximum number of allowable errors that may be
present in the delivered system
...
Error seed can be used to estimate the number of
residual errors in a system
...
In other words, some artificial errors are introduced into the program artificially
...
These values in conjunction with the number of unseeded errors detected can be
used to predict:
• The number of errors remaining in the product
...

Let N be the total number of defects in the system and let n of these defects be found by testing
...

n/N = s/S
or
N = S × n/s
Defects still remaining after testing = N–n = n×(S – s)/s
Error seeding works satisfactorily only if the kind of seeded errors matches closely with the kind
of defects that actually exist
...
To some extent, the different categories of errors that remain can be estimated to a first
approximation by analyzing historical data of similar projects
...

Regression Testing
Regression testing does not belong to either unit test, integration test, or system testing
...
The functionality of regression testing
has been discussed earlier
...
This is no surprise, given the rate of hardware obsolescence, the immortality of a
software product per se, and the demand of the user community to see the existing software
products run on newer platforms, run in newer environments, and/or with enhanced features
...
Also, whenever the support environment of a software
product changes, the software product requires rework to cope up with the newer interface
...

Thus, every software product continues to evolve after its development through maintenance
efforts
...

Types of software maintenance
There are basically three types of software maintenance
...

 Adaptive: A software product might need maintenance when the customers need the
product to run on new platforms, on new operating systems, or when they need the
product to interface with new hardware or software
...

Problems associated with software maintenance
Software maintenance work typically is much more expensive than what it should be and takes
more time than required
...
The primary reason being that software maintenance is one of the most
neglected areas of software engineering
...

Software maintenance has a very poor image in industry
...
Even though maintenance suffers from a
poor image, the work involved is often more challenging than development work
...

Another problem associated with maintenance work is that the majority of software products
needing maintenance are legacy products
...
The purpose of reverse engineering is to
facilitate maintenance work by improving the understandability of a system and to produce the
necessary documents for a legacy system
...
Even welldesigned products become legacy software as their structure degrades through a series of
maintenance efforts
...
A process model for reverse engineering has been shown in fig
...
1
...
Many legacy software products with complex control structure and unthoughtful
variable names are difficult to comprehend
...
All
variables, data structures, and functions should be assigned meaningful names wherever possible
...


Fig
...
1: A process model for reverse engineering

DEPT OF CSE & IT
VSSUT, Burla

After the cosmetic changes have been carried out on a legacy software the process of extracting
the code, design, and the requirements specification can begin
...
24
...
In order to extract the design, a full understanding of the code is needed
...
The structure chart (module invocation sequence and data interchange among modules)
should also be extracted
...


Fig
...
2: Cosmetic changes carried out before reverse engineering
Legacy software products
It is prudent to define a legacy system as any software system that is hard to maintain
...
Many of
the legacy systems were developed long time back
...

The activities involved in a software maintenance project are not unique and depend on several
factors such as:
• the extent of modification to the product required
DEPT OF CSE & IT
VSSUT, Burla

• the resources available to the maintenance team
• the conditions of the existing product (e
...
, how structured it is, how well documented it
is, etc
...

When the changes needed to a software product are minor and straightforward, the code can be
directly modified and the changes appropriately reflected in all the documents
...
Usually, for
complex maintenance projects for legacy systems, the software process can be represented by a
reverse engineering cycle followed by a forward engineering cycle with an emphasis on as much
reuse as possible from the existing code and other documents
...
The first
model is preferred for projects involving small reworks where the code is changed directly and
the changes are reflected in the relevant documents later
...
25
...
In this approach, the project starts by gathering the requirements for
changes
...
At this stage, the association of at least a few members of the original development team
goes a long way in reducing the cycle team, especially for projects involving unstructured and
inadequately documented code
...
Also, debugging of the reengineered system becomes
easier as the program traces of both the systems can be compared to localize the bugs
...
25
...
This approach can be represented by a reverse engineering
cycle followed by a forward engineering cycle
...
This process model is depicted in fig
...
2
...
During the reverse engineering, the old code is analyzed
(abstracted) to extract the module specifications
...
The design is analyzed (abstracted) to produce the original requirements
specification
...
At the design, module specification, and coding a substantial
reuse is made from the reverse engineered products
...
The efficiency improvements
are brought about by a more efficient design
...
An empirical study indicates that process 1 is preferable when the amount of rework is
no more than 15%
...

 Reengineering might also be preferable for legacy products having poor design
and code structure
...
25
...
e
...
25
...

Estimation of approximate maintenance cost
It is well known that maintenance efforts require about 60% of the total life cycle cost for a
typical software product
...
For embedded systems, the maintenance cost can be as much as 2 to 4 times the
development cost
...
Boehm’s maintenance cost estimation is made in terms of a quantity
called the Annual Change Traffic (ACT)
...

ACT = KLOC added + KLOC deleted
KLOCtotal
where, KLOCadded is the total kilo lines of source code added during maintenance
...

Thus, the code that is changed, should be counted in both the code added and the code deleted
...

Most maintenance cost estimation models, however, yield only approximate results because they
do not take into account several factors such as experience level of the engineers, and familiarity
of the engineers with the product, hardware requirements, software complexity, etc
...
non-repeatable software development organization
A repeatable software development organization is one in which the software development
process is person-independent
...
Thus, in a non-repeatable software
development organization, the chances of successful completion of a software project is to a
great extent depends on the team members
...

Alternatively, reliability of a software product can also be defined as the probability of the
product working “correctly” over a given period of time
...
It is also
clear that the reliability of a system improves, if the number of defects in it is reduced
...
For example, removing errors from parts of a software which are rarely
executed makes little difference to the perceived reliability of the product
...
These most used 10% instructions are often called the core of the program
...
It therefore may not be very surprising to note that removing 60% product
defects from the least used parts of a system would typically lead to only 3% improvement to the
product reliability
...

Thus, reliability of a product depends not only on the number of latent errors but also on the
exact location of the errors
...
e
...
If it is selected input data to the system such that only the
“correctly” implemented functions are executed, none of the errors will be exposed and the
perceived reliability of the product will be high
...


DEPT OF CSE & IT
VSSUT, Burla

Reasons for software reliability being difficult to measure
The reasons why software reliability is difficult to measure can be summarized as
follows:
 The reliability improvement due to fixing a single bug depends on where the bug is
located in the code
...

 The reliability of a product keeps changing as errors are detected and fixed
...
software reliability differs
...
For example, hardware failures
are inherently different from software failures
...
A logic gate may be stuck at 1 or 0, or a resistor might short circuit
...
On the other hand, a software
product would continue to fail until the error is tracked down and either the design or the code is
changed
...
To put
this fact in a different perspective, hardware reliability study is concerned with stability (for
example, inter-failure times remain constant)
...
e
...
The change of failure rate over the product
lifetime for a typical hardware and a software product are sketched in fig
...
1
...
The system then enters its useful life
...
This gives the
plot of hardware reliability over time its characteristics “bath tub” shape
...
As the system is tested,
more and more errors are identified and removed resulting in reduced failure rate
...
As the software
becomes obsolete no error corrections occurs and the failure rate remains unchanged
...
26
...
For
this reason, it is necessary that the level of reliability required for a software product should be
specified in the SRS (software requirements specification) document
...
A
good reliability measure should be observer-dependent, so that different people can agree on the
degree of reliability a system has
...
However, in practice, it is very difficult to formulate
a precise reliability measurement technique
...
There are six reliability metrics which can be used to quantify the reliability of
software products
...
e
...
ROCOF measure of a software product
can be obtained by observing the behavior of a software product in operation over a
specified time interval and then recording the total number of failures occurring during
the interval
...
To measure MTTF, we can record the
failure data for n failures
...
Then,
1

2

n

MTTF can be calculated as









It is important to note that only run time is considered in the time measurements, i
...
the
time for which the system is down to fix the error, the boot time, etc are not taken into
account in the time measurements and the clock is stopped at these times
...
MTTR measures the average time it takes to track the errors causing the failure and
to fix them
...
Thus, MTBF of 300 hours indicates that once a
failure occurs, the next failure is expected after 300 hours
...

Probability of Failure on Demand (POFOD) - Unlike the other metrics discussed, this
metric does not explicitly involve time measurements
...
For example, a POFOD of 0
...

Availability- Availability of a system is a measure of how likely shall the system be
available for use over a given period of time
...
This metric is important for systems such
as telecommunication systems, and operating systems, which are supposed to be never
down and where repair and restart time are significant and loss of service during that time
is important
...

 Permanent- Permanent failures occur for all input values while invoking a function of
the system
...





Unrecoverable- In unrecoverable failures, the system may need to be restarted
...
An example of a cosmetic failure is the case where the mouse button has
to be clicked twice instead of once to invoke a given function through the graphical user
interface
...
A reliability growth model can be used to predict when (or if at
all) a particular level of reliability is likely to be attained
...
Although several
different reliability growth models have been proposed, in this text we will discuss only two very
simple reliability growth models
...
Such a model is shown in fig
...
1
...



...
27
...
It also models the fact
that as errors are repaired, the average improvement in reliability per repair decreases (Fig
...
2)
...
This distribution models the fact that error corrections with large
contributions to reliability growth are removed first
...

DEPT OF CSE & IT
VSSUT, Burla

Fig
...
2: Random-step function model of reliability growth
Statistical Testing
Statistical testing is a testing process whose objective is to determine the reliability of software
products rather than discovering errors
...

Operation profile
Different categories of users may use a software for different purposes
...
whereas a library member might use to software to query about the availability of the book,
or to issue and return books
...
If the input to a number of classes {C i} is
divided, the probability value of a class represent the probability of an average user selecting his
next input from this class
...

Steps in statistical testing
Statistical testing allows one to concentrate on testing those parts of the system that are most
likely to be used
...
The next step is to generate a set of test data corresponding to the determined operation
profile
...
After a statistically significant number of failures have been observed, the reliability can
be computed
...
Therefore, it results in a system that the users to be more reliable (than actually it is!)
...
But it is not easy to perform statistical testing properly
...
Also it is very much
cumbersome to generate test cases for statistical testing because the number of test cases with
which the system is to be tested should be statistically significant
...
That is, a quality
product does exactly what the users want it to do
...

Although “fitness of purpose” is a satisfactory definition of quality for many products such as a
car, a table fan, a grinding machine, etc
...
To give an example, consider a software product that is
functionally correct
...
But, has
an almost unusable user interface
...
Another example may be that of a product which does
everything that the users want but has an almost incomprehensible and unmaintainable code
...

The modern view of a quality associates with a software product several quality factors such as
the following:
 Portability: A software product is said to be portable, if it can be easily made to work in
different operating system environments, in different machines, with other software
products, etc
...
e
...

 Reusability: A software product has good reusability, if different modules of the product
can easily be reused to develop new products
...

 Maintainability: A software product is maintainable, if errors can be easily corrected as
and when they show up, new functions can be easily added to the product, and the
functionalities of the product can be easily modified, etc
...


DEPT OF CSE & IT
VSSUT, Burla

A quality system consists of the following:
Managerial Structure and Individual Responsibilities- A quality system is actually the
responsibility of the organization as a whole
...
The quality system of an organization
should have support of the top management
...

Quality System Activities- The quality system activities encompass the following:
- auditing of projects
- review of the quality system
- development of standards, procedures, and guidelines, etc
...

Evolution of Quality Management System
Quality systems have rapidly evolved over the last five decades
...
Since that time, quality systems of organizations have undergone through four stages
of evolution as shown in the fig
...
1
...
Quality control focuses not only on detecting the defective products and
eliminating them but also on determining the causes behind the defects
...
The next breakthrough
in quality systems was the development of quality assurance principles
...
The modern
quality paradigm includes guidance for recognizing, defining, analyzing, and improving the
production process
...
TQM goes a step
further than quality assurance and aims at continuous process improvement
...
A term related to TQM is Business
Process Reengineering (BPR)
...
From the above discussion it can be stated that over the years the quality paradigm
has shifted from product assurance to process assurance (as shown in fig
...
1)
...
28
...
ISO published its 9000 series of standards in 1987
...
The ISO 9000
standard specifies the guidelines for maintaining a quality system
...
The
ISO standard mainly addresses operational aspects and organizational aspects such as
responsibilities, reporting, etc
...
It is important to realize that ISO 9000 standard is a set of
guidelines for the production process and is not directly concerned about the product itself
...
The ISO 9000 series
of standards is based on the premise that if a proper process is followed for production, then
good quality products are bound to follow automatically
...

ISO 9001 applies to the organizations engaged in design, development, production, and servicing
of goods
...


DEPT OF CSE & IT
VSSUT, Burla

ISO 9002 applies to those organizations which do not design products but are only involved in
production
...
Therefore, ISO 9002 is not applicable to software development
organizations
...

Software products vs
...





Software is intangible in nature and therefore difficult to control
...
In contrast, any other industries such as car
manufacturing industries where one can see a product being developed through various
stages such as fitting engine, fitting doors, etc
...

During software development, the only raw material consumed is data
...


Need for obtaining ISO 9000 certification
There is a mad scramble among software development organizations for obtaining ISO
certification due to the benefits it offers
...
This is especially true in the international market
...
For this reason, it is vital for
software organizations involved in software export to obtain ISO 9000 certification
...
A welldocumented software production process contributes to repeatable and higher quality of
the developed software
...

ISO 9000 certification points out the weak points of an organization and recommends
remedial action
...


DEPT OF CSE & IT
VSSUT, Burla

Summary of ISO 9001 certification
A summary of the main requirements of ISO 9001 as they relate of software development is as
follows
...
1)
 The management must have an effective quality policy
...

 A management representative, independent of the development process, must be
responsible for the quality system
...

 The effectiveness of the quality system must be periodically reviewed by audits
...
2)
A quality system must be maintained and documented
...
3)
Before entering into a contract, an organization must review the contract to ensure that it is
understood, and that the organization has the necessary capability for carrying out its obligations
...
4)
 The design process must be properly controlled, this includes controlling coding also
...

 Design inputs must be verified as adequate
...

 Design output must be of required quality
...

Document Control (4
...

 Document changes must be controlled
...

Purchasing (4
...

Purchaser Supplied Product (4
...

DEPT OF CSE & IT
VSSUT, Burla

Product Identification (4
...
In software terms this means
configuration management
...
9)
 The development must be properly managed
...

Inspection and Testing (4
...
e
...
Test records must be maintained
...
11)
If integration, measuring, and test equipments are used, they must be properly maintained and
calibrated
...
12)
The status of an item must be identified
...

Control of Nonconforming Product (4
...

Corrective Action (4
...
If an error occurs despite the
quality system, the system needs improvement
...
15)
This clause deals with the storage, packing, and delivery of the software product
...
16)
Recording the steps taken to control the quality of the process is essential in order to be able to
confirm that they have actually taken place
...
17)
Audits of the quality system must be carried out to ensure that it is effective
...
18)
Training needs must be identified and met
...
This requires a configuration management system
to be in place
...

 Important documents should be independently checked and reviewed for effectiveness
and correctness
...

 Several organizational aspects should be addressed e
...
, management reporting of the
quality team
...
Some of these shortcomings of the ISO 9000 certification process are
the following:
 ISO 9000 requires a software production process to be adhered to but does not guarantee
the process to be of high quality
...



ISO 9000 certification process is not fool-proof and no international accreditation agency
exists
...




Organizations getting ISO 9000 certification often tend to downplay domain expertise
...
However, many areas of software development are so specialized that
special expertise and experience in these areas (domain expertise) is required
...

Once a process is calibrated, it can be run again and again producing quality goods
...




ISO 9000 does not automatically lead to continuous process improvement, i
...
does not
automatically lead to TQM
...

SEI CMM can be used two ways: capability evaluation and software process assessment
...
Capability evaluation provides a way to assess the software process
capability of an organization
...
Therefore, the results of software process
capability assessment can be used to select a contractor
...
Thus,
this type of assessment is for purely internal use
...
The
different levels of SEI CMM have been designed so that it is easy for an organization to slowly
build its quality system starting from scratch
...
Very few or no processes are defined and followed
...
Therefore, it is also called chaotic level
...
When engineers leave, the successors have
great difficulty in understanding the process followed and the work completed
...

Level 2: Repeatable - At this level, the basic project management practices such as tracking cost
and schedule are established
...
are used
...
Please remember that opportunity to repeat a process exists
only when a company produces a family of products
...
There is a common organization-wide understanding of activities,
roles, and responsibilities
...
ISO 9000 aims at achieving this level
...
Two types of metrics are
collected
...
Process metrics reflect the effectiveness
of the process being used, such as average defect correction time, productivity, average number
of defects found per hour inspection, average number of failures detected during testing per
LOC, etc
...
The software process and product
quality are measured and quantitative quality requirements for the product are met
...
are used to measure the product and process quality
...
Thus, the results of
process measurements are used to evaluate project performance rather than improve the process
...
Process and
product measurement data are analyzed for continuous process improvement
...
Also, the lessons learned from
specific projects are incorporated in to the process
...
Such an organization identifies the best
software engineering practices and innovations which may be tools, methods, or processes
...

Key process areas (KPA) of a software organization
Except for SEI CMM level 1, each maturity level is characterized by several Key Process Areas
(KPAs) that includes the areas an organization should focus to improve its software process to
the next level
...
29
...


DEPT OF CSE & IT
VSSUT, Burla

CMM Level
1
...
Repeatable
3
...
Managed
5
...
29
...
Thus, it provides a way for gradual quality improvement over several
stages
...
For example, it considers that trying to implement a defined process (SEI CMM
level 3) before a repeatable process (SEI CMM level 2) would be counterproductive as it
becomes difficult to follow the defined process due to schedule and budget pressures
...
SEI/CMM
For quality appraisal of a software development organization, the characteristics of ISO 9000
certification and the SEI CMM differ in some respects
...
Therefore, ISO 9000
certification can be quoted by an organization in official documents, communication with
external parties, and the tender quotations
...

 SEI CMM was developed specifically for software industry and therefore addresses many
issues which are specific to software industry alone
...
In fact, ISO 9001 aims at level 3 of SEI
CMM model
...

Thus, it provides a way for achieving gradual quality improvement
...
For those large organizations, SEI
CMM model is perfectly applicable
...
For such organizations, a CMM-based appraisal is probably
excessive
...

For example, they need to practice effective project management, reviews, configuration
management, etc
...
PSP
is suitable for individual use
...
PSP recognizes that the process for individual use is
different from that necessary for a team
...
PSP is
a framework that helps engineers to measure and improve the way they work
...

Time measurement- PSP advocates that engineers should rack the way they spend time
...

Therefore, the actual time spent on a task should be measured with the help of a stop-clock to get
an objective picture of the time spent
...
An engineer should measure the time he spends for
designing, writing code, testing, etc
...
They must estimate the maximum, minimum,
and the average LOC required for the product
...
They
must record the plan data in a project plan summary
...
29
...
While carrying out the different phases, they must
record the log data using time measurement
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
2: Schematic representation of PSP
The PSP levels are summarized in fig
...
3
...
29
...
The
checklists are developed from gathering and analyzing defect data earlier projects
...
It
can be used to improve every facet of business, from production, to human resources, to order
entry, to technical support
...
Therefore, it is applicable to virtually every industry
...
Six Sigma is a
disciplined, data-driven approach to eliminate defects in any process – from manufacturing to
transactional and product to service
...

To achieve Six Sigma, a process must not produce more than 3
...
A Six Sigma defect is defined as any system behavior that is not as per customer
specifications
...
Process sigma can easily be calculated using a Six Sigma calculator
...
This is accomplished through the
use of two Six Sigma sub-methodologies: DMAIC and DMADV
...
The Six Sigma
DMADV process (define, measure, analyze, design, verify) is an improvement system used to
develop new processes or products at Six Sigma quality levels
...
Both Six Sigma processes are
executed by Six Sigma Green Belts and Six Sigma Black Belts, and are overseen by Six Sigma
Master Black Belts
...
Six Sigma Consultants
all over the world have also developed proprietary methodologies for implementing Six Sigma
quality, based on the similar change management philosophies and applications of tools
...
It is
very difficult to objectively describe the job responsibilities of a project manager
...
Most managers take responsibility for project proposal
writing, project cost estimation, scheduling, project staffing, software process tailoring, project
monitoring and control, software configuration management, risk management, interfacing with
clients, managerial report writing and presentations, etc
...
The project planning activity is
undertaken before the development starts to plan the activities to be undertaken during
development
...

Skills necessary for software project management
A theoretical knowledge of different project management techniques is certainly necessary to
become a successful project manager
...
In addition to
having a good grasp of the latest software project management techniques such as cost
estimation, risk management, configuration management, project managers need good
communication skills and the ability get work done
...
None the less, the importance of sound
knowledge of the prevalent project management techniques cannot be overemphasized
...

Project planning is undertaken and completed even before any development activity starts
...






Scheduling manpower and other resources
...

Risk identification, analysis, and abatement planning
Miscellaneous plans such as quality assurance plan, configuration management plan, etc
...
Fig
...
1 shows the order in which important project planning activities may be undertaken
...
30
...
It is also the most
fundamental parameter based on which all other planning activities are carried out
...


Fig
...
1: Precedence ordering among planning activities
Sliding Window Planning
Project planning requires utmost care and attention since commitment to unrealistic time and
resource estimates result in schedule slippage
...
It can even cause project failure
...
Especially for large projects, it is very much
difficult to make accurate plans
...
may change during the span of the project
...
Planning a project over a number of stages protects managers from making big
commitments too early
...
In the sliding window technique, starting with an initial plan, the project is planned
more accurately in successive development stages
...
Their information base gradually
improves as the project progresses through different phases
...

Software Project Management Plan (SPMP)
Once project planning is complete, project managers document their plans in a Software Project
Management Plan (SPMP) document
...
This list can be used as a possible organization of the
SPMP document
...
Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraints
2
...
Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation

DEPT OF CSE & IT
VSSUT, Burla

4
...
Staff Organization
(a) Team Structure
(b) Management Reporting
6
...
Project Tracking and Control Plan
8
...
In order to be able to accurately estimate the project size,
some important metrics should be defined in terms of which the project size can be expressed
...
It is
neither the byte size of the executable code
...

Currently two metrics are popularly being used widely to estimate size: lines of code (LOC) and
function point (FP)
...

Lines of Code (LOC)
LOC is the simplest among all metrics available to estimate project size
...
Using this metric, the project size is estimated by
counting the number of source instructions in the developed program
...

Determining the LOC count at the end of a project is a very simple job
...
In order to estimate
the LOC count at the beginning of a project, project managers usually divide the problem into
modules, and each module into submodules and so on, until the sizes of the different leaf-level
modules can be approximately predicted
...
By using the estimation of the lowest level modules, project
managers arrive at the total size estimation
...
This metric overcomes many of the
shortcomings of the LOC metric
...
One of the important advantages of using the function point metric is
that it can be used to easily estimate the size of a software product directly from the problem
specification
...
The conceptual idea behind the function point
metric is that the size of a software product is directly dependent on the number of different
functions or features it supports
...
Each function when invoked reads
DEPT OF CSE & IT
VSSUT, Burla

some input data and transforms it to the corresponding output data
...
31
...
Thus, a computation of the
number of input and the output data values to a system gives some indication of the number of
functions supported by the system
...


Fig
...
1: System function as a map of input data to output data
Besides using the number of input and output data values, function point metric computes the
size of a software product (in units of functions points or FPs) using three other characteristics of
the product as shown in the following expression
...
The weights
associated with the five characteristics were proposed empirically and validated by the
observations over many projects
...
The first step is to
compute the unadjusted function point (UFP)
...
Data inputs should be
distinguished from user inquiries
...

DEPT OF CSE & IT
VSSUT, Burla

Inquiries are counted separately
...
For example, while entering the data concerning an employee to an
employee pay roll software; the data items name, age, sex, address, phone number, etc
...
All these data items can be considered to be related, since
they pertain to a single employee
...
While outputting the number of outputs the individual data items within
a report are not considered, but a set of related data items is counted as one input
...
These inquiries are the user commands which require specific action
by the system
...
A logical file means groups of logically related
data
...

Number of interfaces: Here the interfaces considered are the interfaces used to exchange
information with other systems
...

Once the unadjusted function point (UFP) is computed, the technical complexity factor (TCF) is
computed next
...
Each of these 14 factors is
assigned from 0 (not present or no influence) to 6 (strong influence)
...
Now, TCF is computed as (0
...
01*DI)
...
65 to 1
...
Finally, FP=UFP*TCF
...
For example, one
programmer might write several source instructions on a single line whereas another
might split a single instruction across several lines
...

However, a more intricate problem arises because the length of a program depends on the
choice of instructions used in writing the program
...
This
situation does not improve even if language tokens are counted instead of lines of code
...
That is, it should consider the local effort needed to specify,
design, code, test, etc
...
LOC, however, focuses on the
coding activity alone; it merely computes the number of source lines in the final program
...
It is also wrong to argue that the overall product development
effort is proportional to the effort required in writing the program code
...
In such cases, code size is a grossly improper indicator of the problem size
...
Larger code
size does not necessarily imply better quality or higher efficiency
...
In fact, it is very likely that a poor and sloppily written piece of code
might have larger number of source instructions than a piece that is neat and efficient
...
The
paradox is that if a programmer consciously uses several library routines, then the LOC
count will be lower
...
Thus, if managers use
the LOC count as a measure of the effort put in the different engineers (that is,
productivity), they would be discouraging code reuse by engineers
...
Between two programs
with equal LOC count, a program having complex logic would require much more effort
to develop than a program with very simple logic
...

It is very difficult to accurately estimate LOC in the final product from the problem
specification
...
Therefore, the LOC metric is little use to the project managers during
project planning, since project planning is carried out even before any development
activity has started
...


Feature Point Metric
A major shortcoming of the function point measure is that it does not take into account the
algorithmic complexity of a software
...
But,
we know that this is normally not true, the effort required to develop any two functionalities may
vary widely
...
To overcome
this problem, an extension of the function point metric called feature point metric is proposed
...
This parameter
ensures that the computed size using the feature point metric reflects the fact that the more is the
complexity of a function, the greater is the effort required to develop it and therefore its size
should be larger compared to simpler functions
...
The important
project parameters that are estimated include: project size, effort required to develop the
software, project duration, and cost
...
There are three broad
categories of estimation techniques:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques
Empirical Estimation Techniques
Empirical estimation techniques are based on making an educated guess of the project
parameters
...
Although empirical estimation techniques are based on common
sense, different activities involved in estimation have been formalized over the years
...

Expert Judgment Technique
Expert judgment is one of the most widely used estimation techniques
...
Usually, the expert estimates the cost of the different components (i
...

modules or subsystems) of the system and then combines them to arrive at the overall
estimate
...
Also, it
is possible that the expert may overlook some factors inadvertently
...

For example, he may be conversant with the database and user interface parts but may not
be very knowledgeable about the computer communication part
...

Estimation by a group of experts minimizes factors such as individual oversight, lack of
familiarity with a particular aspect of a project, personal bias, and the desire to win
contract through overly optimistic estimates
...
Also, the decision made by the group may
be dominated by overly assertive members
...
Delphi estimation is carried out by a team comprising of a group of
experts and a coordinator
...
Estimators complete their individual estimates anonymously
and submit to the coordinator
...
The coordinator
prepares and distributes the summary of the responses of all the estimators, and includes
any unusual rationale noted by any of the estimators
...
This process is iterated for several rounds
...
The idea
behind this is that if any discussion is allowed among the estimators, then many
estimators may easily get influenced by the rationale of an estimator who may be more
experienced or senior
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 32

HEURISTIC TECHNIQUES
Heuristic techniques assume that the relationships among the different project parameters can be
modeled using suitable mathematical expressions
...
Different heuristic estimation models can
be divided into the following two classes: single variable model and the multi variable model
...
A single variable estimation model takes the following form:
d

Estimated Parameter = c * e
1

1

In the above expression, e is the characteristic of the software which has already been estimated
(independent variable)
...
The
dependent parameter to be estimated could be effort, project duration, staff size, etc
...
The values of the constants c and d are usually determined using data collected from
1

1

past projects (historical data)
...

A multivariable cost estimation model takes the following form:
d

Estimated Resource = c *e
1

1 1

d

+ c *e
2

+
...
Multivariable estimation models are expected to give more
1

2

1

2

accurate estimates compared to the single variable models, since a project parameter is typically
influenced by several independent parameters
...
This is modeled by the constants c , c , d , d , …
...
The intermediate
COCOMO model can be considered to be an example of a multivariable estimation model
...
Thus, unlike empirical and heuristic techniques, analytical techniques do
have scientific basis
...

Halstead’s software science can be used to derive some interesting results starting with a few
DEPT OF CSE & IT
VSSUT, Burla

simple assumptions
...
In fact, it outperforms both empirical and heuristic techniques when used
for predicting software maintenance efforts
...
Halstead used a few primitive program parameters to
develop the expressions for overall program length, potential minimum value, actual volume,
effort, and development time
...


2

1
2

Length and Vocabulary
The length of a program as defined by Halstead, quantifies total usage of all operators and
operands in the program
...
Halstead’s definition of the length of the
1

2

program as the total number of operators and operands roughly agrees with the intuitive notation
of the program length as the total number of tokens used in the program
...

Thus, program vocabulary η = η + η
...
e
...
In other words, for the same
programming problem, the length would depend on the programming style
...
Thus, while expressing program size, the
programming language used must be taken into consideration:
V = Nlog η
2

Here the program volume V is the minimum number of bits needed to encode the program
...
In this scheme, Nlog η bits will be needed to store a program of
2

length N
...


DEPT OF CSE & IT
VSSUT, Burla

Potential Minimum Volume
The potential minimum volume V* is defined as the volume of most succinct program in which a
problem can be coded
...
say a function call like foo( ) ;
...

Thus, if an algorithm operates on input and output data d , d , … d , the most succinct program
1

2

n

would be f(d , d , … d ); for which η = 2, η = n
...

1

2

n

1

2

2

2

2

The program level L is given by L = V*/V
...
Using this
definition, languages can be ranked into levels that also appear intuitively correct
...
This result agrees with the intuitive notion that it takes more
effort to develop a program in assembly language than to develop a program in a high-level
language to solve a problem
...
Thus, effort E = V/L, where E
is the number of mental discriminations required to implement the program and also the effort
required to read and understand the program
...
Experience shows that E is well correlated to the effort
needed for maintenance of an existing program
...
The value of S
has been empirically developed from psychological reasoning, and its recommended value for
programming applications is 18
...
Using this method, the
program parameters such as length, volume, cost, effort, etc
...
His method is summarized below
...
In fact, once a piece of code occurs identically at several places, it is made into a
procedure or a function
...
Now, it is standard combinatorial result that for any given alphabet of
r

size K, there are exactly K different strings of length r
...

η

N/η ≤ η Or, N ≤ η

η+1

Since operators and operands usually alternate in a program, the upper bound can be further
refined into N ≤ η η

η1
1

η

2

η2


...
e
...

Therefore,
η1

N

2 =ηη

1

η

η2
2

Or, taking logarithm on both sides,
N = log η +log (η
2

2

η1
1

η

η2
2

)

So we get,
N = log (η
2

η1
1

η

η2

)

2

(approximately, by ignoring log η)
2

Or,
N = log η

η1

2 1

+ log η

η2

2 2

= η log η + η log η
1

2 1

2

2 2

Experimental evidence gathered from the analysis of larger number of programs suggests that the
computed and actual lengths match very closely
...

In conclusion, Halstead’s theory tries to provide a formal definition and quantification of such
qualitative attributes as program complexity, ease of understanding, and the level of abstraction
based on some low-level parameters such as the number of operands, and operators appearing in

DEPT OF CSE & IT
VSSUT, Burla

the program
...

Example:
Let us consider the following C program:
main( )
{
int a, b, c, avg;
scanf(“%d %d %d”, &a, &b, &c);
avg = (a+b+c)/3;
printf(“avg = %d”, avg);
}
The unique operators are:
main,(),{},int,scanf,&,“,”,“;”,=,+,/, printf
The unique operands are:
a, b, c, &a, &b, &c, a+b+c, avg, 3,
“%d %d %d”, “avg = %d”
Therefore,
η = 12, η = 11
1

2

Estimated Length = (12*log12 + 11*log11)
= (12*3
...
45)
= (43+38) = 81
Volume = Length*log(23)
= 81*4
...
In order to classify a product into the identified categories, Boehm not only
considered the characteristics of the product but also those of the development team and
development environment
...
Normally, data processing programs are
considered to be application programs
...
, are utility programs
...
are system programs
...

Boehm’s [1981] definition of organic, semidetached, and embedded systems are elaborated
below
...

Semidetached: A development project can be considered of semidetached type, if the
development consists of a mixture of experienced and inexperienced staff
...

Embedded: A development project is considered to be of embedded type, if the software being
developed is strongly coupled to complex hardware, or if the stringent regulations on the
operational procedures exist
...
According to
Boehm, software cost estimation should be done through three stages: Basic COCOMO,
Intermediate COCOMO, and Complete COCOMO
...
The basic
COCOMO estimation model is given by the following expressions:
a

Effort = a х (KLOC) PM
1

2

b

Tdev = b x (Effort) Months
1

2

Where
• KLOC is the estimated size of the software product expressed in Kilo Lines of
Code,
• a , a , b , b are constants for each category of software products,
1

2

1

2

• Tdev is the estimated time to develop the software, expressed in months,
• Effort is the total effort required to develop the software product, expressed in
person months (PMs)
...
It is the area under the
person-month plot (as shown in fig
...
1)
...
33
...


Fig
...
1: Person-month curve

DEPT OF CSE & IT
VSSUT, Burla

According to Boehm, every line of source text should be calculated as one LOC irrespective of
the actual number of instructions on that line
...
The values of a , a , b , b for different categories of
1

2

1

2

products (i
...
organic, semidetached, and embedded) as given by Boehm [1981] are summarized
below
...

Estimation of development effort
For the three classes of software products, the formulas for estimating the effort based on the
code size are shown below:
1
...
4(KLOC)

PM
1
...
0(KLOC)

PM

1
...
6(KLOC)

PM

Estimation of development time
For the three classes of software products, the formulas for estimating the development time
based on the effort are given below:
0
...
5(Effort)

Months
0
...
5(Effort)

Months

0
...
5(Effort)

Months

Some insight into the basic COCOMO model can be obtained by plotting the estimated
characteristics for different software sizes
...
33
...
From fig
...
2, we can observe that the effort is somewhat super linear in the size
of the software product
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
2: Effort versus product size
The development time versus the product size in KLOC is plotted in fig
...
3
...
33
...
e
...
This can be explained by the fact that for larger products, a larger
number of activities which can be carried out concurrently can be identified
...
This reduces the time to complete
the project
...
33
...
For example, a 60 KLOC program can be
developed in approximately 18 months, regardless of whether it is of organic, semidetached, or
embedded type
...
33
...
But, implicit in this project cost computation is the assumption
that the entire project cost is incurred on account of the manpower cost alone
...

It is important to note that the effort and the duration estimations obtained using the COCOMO
model are called as nominal effort estimate and nominal duration estimate
...
But, if anyone completes the project over a longer period
of time than the estimated, then there is almost no decrease in the estimated cost value
...
Assume that the average salary of software engineers be Rs
...
Determine the effort required to develop the software product and the nominal
development time
...
05

Effort = 2
...
38

Nominal development time = 2
...
210,000/-

DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 34

INTERMEDIATE COCOMO MODEL
The basic COCOMO model assumes that effort and development time are functions of the
product size alone
...
Therefore, in order to
obtain an accurate estimation of the effort and project duration, the effect of all relevant
parameters must be taken into account
...
For example, if
modern programming practices are used, the initial estimates are scaled downward by
multiplication with a cost driver having a value less than 1
...
Boehm requires the
project manager to rate these 15 different parameters for a particular project on a scale of one to
three
...
In general, the cost
drivers can be classified as being attributes of the following items:
Product: The characteristics of the product that are considered include the inherent complexity
of the product, reliability requirements of the product, etc
...

Personnel: The attributes of development personnel that are considered include the experience
level of personnel, programming capability, analysis capability, etc
...
An important parameter that is considered is the
sophistication of the automation (CASE) tools used for software development
...
However, most large systems are made up
several smaller sub-systems
...
For
example, some sub-systems may be considered as organic type, some semidetached, and some
embedded
...
The
complete COCOMO model considers these differences in characteristics of the subsystems and
estimates the effort and development time as the sum of the estimates for the individual
subsystems
...
This approach reduces the
margin of error in the final estimate
...
A distributed Management Information System (MIS) product for an
organization having offices at several places across the country can have the following subcomponents:
• Database part
• Graphical User Interface (GUI) part
• Communication part
Of these, the communication part can be considered as embedded software
...
The costs for these three
components can be estimated separately, and summed up to give the overall cost of the system
...
Putnam first studied the problem of what should be a
proper staffing pattern for software projects
...
In order to
appreciate the staffing pattern of software projects, Norden’s and Putnam’s results must be
understood
...
He found that the staffing pattern
can be approximated by the Rayleigh distribution curve (as shown in fig
...
1)
...
E is an indication of the number of engineers (or the
staffing level) at any particular time during the duration of the project, K is the area under the
curve, and t is the time at which the curve attains its maximum value
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
1: Rayleigh curve
Putnam’s Work
Putnam studied the problem of staffing of software projects and found that the software
development has characteristics very similar to other R & D projects studied by Norden and that
the Rayleigh-Norden curve can be used to relate the number of delivered lines of code to the
effort and the time required to develop the project
...

 t corresponds to the time of system and integration testing
...

C is the state of technology constant and reflects constraints that impede the progress of
k

the programmer
...
), C = 8 for good software
k

development environment (software engineering principles are adhered to), C = 11 for an
k

excellent environment (in addition to following software engineering principles,
automated tools and techniques are used)
...

Putnam suggested that optimal staff build-up on a project should follow the Rayleigh curve
...
As the project progresses and more detailed work is required, the number
of engineers reaches a peak
...

However, the staff build-up should not be carried out in large installments
...

Experience shows that a very rapid build up of project staff any time during the project
development correlates with schedule slippage
...
If a constant
number of engineers are used over all the phases of a project, some phases would be overstaffed
and the other phases would be understaffed causing inefficient use of manpower, leading to
schedule slippage and increase in cost
...

DEPT OF CSE & IT
VSSUT, Burla

or, K1/K2 = td24/ td14
or, K ∝ 1/t

4

d

or, cost ∝ 1/t

d

(as project development effort is equally proportional to project development cost)
From the above expression, it can be easily observed that when the schedule of a project is
compressed, the required development effort as well as project development cost increases in
proportion to the fourth power of the degree of compression
...
For example, if the estimated development time is 1 year, then in order to
develop the product in 6 months, the total effort required to develop the product (and hence the
project cost) increases 16 times
...
It involves deciding which
tasks would be taken up when
...
Identify all the tasks needed to complete the project
...
Break down large tasks into small activities
...
Determine the dependency among different activities
...
Establish the most likely estimates for the time durations necessary to complete the
activities
...
Allocate resources to activities
...
Plan the starting and ending dates for various activities
...
Determine the critical path
...

The first step in scheduling a software project involves identifying all the tasks necessary to
complete the project
...
Next, the
large tasks are broken down into a logical set of small activities which would be assigned to
different engineers
...
Dependency
among the different activities determines the order in which the different activities would be
carried out
...
In general, the task dependencies define a partial ordering among
tasks, i
...
each tasks may precede a subset of other tasks, but some tasks might not have any
precedence ordering defined between them (called concurrent task)
...

Once the activity network representation has been worked out, resources are allocated to each
activity
...
After resource allocation is
done, a PERT chart representation is developed
...
For task scheduling, the project manager needs to decompose
the project tasks into a set of activities
...
The end of each activity is called milestone
...
If he observes that
the milestones start getting delayed, then he has to carefully control the activities, so that the
overall deadline can still be met
...
WBS provides a notation for representing the major tasks need to be carried out in
order to solve a problem
...
Each node of the
tree is broken down into smaller activities that are made the children of the node
...
Fig
...
1 represents the WBS of a MIS (Management
Information System) software
...
If
a task is broken down into large number of very small activities, these can be carried out
independently
...
Therefore, to be able to complete a project in the least amount of time, the
manager needs to break large tasks into smaller ones, expecting to find more parallelism
...
Very fine subdivision means that a disproportionate amount of time must be spent on
preparing and revising various charts
...
36
...
An activity network shows the different activities making up a project, their
estimated durations, and interdependencies (as shown in fig
...
2)
...

Managers can estimate the time durations for the different tasks in several ways
...
This however is not a good idea,
because software engineers often resent such unilateral decisions
...
However, some managers
prefer to estimate the time for various activities themselves
...
However, careful
experiments have shown that unrealistically aggressive schedules not only cause engineers to
compromise on intangible quality aspects, but also are a cause for schedule delays
...


Fig
...
2: Activity network representation of the MIS problem
Critical Path Method (CPM)
From the activity network representation following analysis can be made
...
The earliest start
(ES) time of a task is the maximum of all paths from the start to the task
...
The earliest
finish time (EF) of a task is the sum of the earliest start time of the task and the duration of the
task
...
The slack time (ST) is LS – EF and equivalently can be written
as LF – EF
...
The slack time indicates the “flexibility” in starting and
completion of tasks
...
A path from the start node to
the finish node containing only critical tasks is called a critical path
...


Task

ES

EF

LS

LF

ST

Specification

0

15

0

15

0

Design database

15

60

15

60

0

Design GUI part

15

45

90

120

75

Code database

60

165

60

165

0

Code GUI part

45

90

120

165

75

Integrate and test

165

285

165

285

0

Write user manual

15

75

225

285

210

The critical paths are all the paths whose duration equals MT
...
36
...

Gantt Chart
Gantt charts are mainly used to allocate resources to activities
...
Gantt charts (named after its developer Henry
Gantt) are useful for resource planning
...
The bars are drawn along a time line
...

Gantt charts are used in software project management are actually an enhanced version of the
standard Gantt charts
...
The shaded part of the bar shows the length of time
each task is estimated to take
...
A Gantt chart representation for the MIS problem of fig
...
2 is
shown in the fig
...
3
...
36
...
The boxes represent activities and the arrows represent task dependencies
...
Thus,
in a PERT chart instead of making a single estimate for each task, pessimistic, likely, and
optimistic estimates are made
...
Since all possible completion times
between the minimum and maximum duration for every task has to be considered, there are not
one but many critical paths, depending on the permutations of the estimates for each task
...
A critical path in a PERT chart is
shown by using thicker arrows
...
36
...
36
...
PERT charts are a more sophisticated form of activity chart
...
Since, the actual durations might
vary from the estimated durations, the utility of the activity diagrams are limited
...
Also, it is easier to
identify parallel activities in a project using a PERT chart
...


Fig
...
4: PERT chart representation of the MIS problem

DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 37

ORGANIZATION STRUCTURE
Usually every software development organization handles several projects at any time
...
Each type
of organization structure has its own advantages and disadvantages so the issue “how is the
organization as a whole structured?” must be taken into consideration so that each software
project can be finished before its deadline
...
project format
There are essentially two broad ways in which a software development organization can be
structured: functional format and project format
...
37
...
In the
functional format, the development staffs are divided based on the functional group to which
they belong
...


a) Project Organization
DEPT OF CSE & IT
VSSUT, Burla

b) Functional Organization
Fig
...
1: Schematic representation of the functional and project organization
In the functional format, different teams of programmers perform different phases of a project
...

The partially completed product passes from one team to another as the project evolves
...
This requires good quality documentation to be produced after every activity
...
Thus, the same team carries out all
the life cycle activities
...

Advantages of functional organization over project organization
Even though greater communication among the team members may appear as an avoidable
overhead, the functional format has many advantages
...

The functional organization allows the engineers to become specialists in particular roles, e
...

requirements analysis, design, coding, testing, maintenance, etc
...
It also results in more
attention being paid to proper documentation at the end of a phase because of the greater need
for clear communication as between teams doing different phases
...
We have already seen that the staffing
pattern should approximately follow the Rayleigh distribution for efficient utilization of the
personnel by minimizing their wait times
...
This possibly is the most important advantage of the functional
organization
...
This results in engineers idling in the
initial phase of the software development and are under tremendous pressure in the later phase of
the development
...
This is because engineers can be brought in from
the functional pool when needed
...

Unsuitability of functional format in small organizations
In spite of several advantages of the functional organization, it is not very popular in the software
industry
...
The project format provides job
rotation to the team members
...
On the other hand, considering the present skill
shortage, it would be very difficult for the functional organizations to fill in slots for some roles
such as maintenance, testing, and coding groups
...
Also, for obvious
reasons the functional format is not suitable for small organizations handling just one or two
projects
...
There are
some possible ways in which the individual project teams can be organized
...
Problems of different
complexities and sizes often require different team structures for chief solution
...
The chief programmer partitions the task into small activities and assigns
them to the team members
...
The structure of the chief programmer team is shown in fig
...
2
...
However, the chief programmer team leads to
lower team morale, since team-members work under the constant supervision of the chief
programmer
...
The chief programmer team is subject to
single point failure since too much responsibility and authority is assigned to the chief
programmer
...
37
...
For example, suppose an organization has
successfully completed many simple MIS projects
...
The chief programmer team structure works well
when the task is within the intellectual grasp of a single individual
...
The chief programmer team structure should not be used unless the
importance of early project completion outweighs other factors such as team morale, personal
developments, life-cycle cost etc
...
37
...
Typically, a manager provides the administrative leadership
...


Fig
...
3: Democratic team structure
The democratic organization leads to higher morale and job satisfaction
...
Also, democratic team structure is appropriate for less understood
problems, since a group of engineers can invent better solutions than a single individual as in a
chief programmer team
...
For large sized projects, a pure
democratic organization tends to become chaotic
...

Mixed Control Team Organization
The mixed team organization, as the name implies, draws upon the ideas from both the
democratic organization and the chief-programmer organization
...
37
...
This team organization incorporates both
DEPT OF CSE & IT
VSSUT, Burla

hierarchical reporting and democratic set up
...
37
...
The mixed control team
organization is suitable for large team sizes
...
Each democratic setup at the
programmer level attempts solution to a single part
...
This team structure is extremely popular and is
being used in many software development companies
...
37
...
Software development requires original thinking too, although of a different
type
...
Just like temperamental artists, programmers find it
extremely difficult to locate bugs in their own programs or flaws in their own design
...
Often, having to
explain one’s program to someone else gives a person enough objectivity to find out what might
have gone wrong
...
An application
of this, is to encourage a democratic team to think that the design, code, and other deliverables to
belong to the entire group
...


DEPT OF CSE & IT
VSSUT, Burla

Characteristics of a good software engineer
The attributes that good software engineers should possess are as follows:
 Exposure to systematic techniques, i
...
familiarity with software engineering principles
...

 Good programming abilities
...
These skills comprise of oral, written, and interpersonal
skills
...

 Sound knowledge of fundamentals of computer science
...

 Ability to work in a team
 Discipline, etc
...
An
experiment conducted by Sackman [1968] shows that the ratio of coding hour for the worst to the
best programmers is 25:1, and the ratio of debugging hours is 28:1
...

Technical knowledge in the area of the project (domain knowledge) is an important factor
determining the productivity of an individual for a particular project, and the quality of the
product that he develops
...
g
...
Lack of familiarity with the
application areas can result in low productivity and poor quality of the product
...
A software engineer not
only needs to effectively communicate with his teammates (e
...
reviews, walk throughs, and
other team communications) but may also have to communicate with the customer to gather
product requirements
...
Software engineers are also required at times to
make presentations to the managers and to the customers
...
A software engineer is also expected to
document his work (design, code, test, etc
...
This requires good written communication skill
...
Even though no systematic studies have been reported in this regard, it is
generally agreed that even bright engineers may turn out to be poor performers when they have
lack motivation
...
Motivation is to a great extent determined by personal traits, family and social
backgrounds, etc
...
In order to be able to
systematically identify the important risks which might affect a software project, it is necessary
to categorize risks into different classes
...

There are three main categories of risks which can affect a software project:
1
...
An important project risk is schedule slippage
...
It is
very difficult to control something which cannot be seen
...
He
can for instance, see that the engine is fitted, after that the doors are fitted, the car is
getting painted, etc
...
The
invisibility of the product being developed is an important reason why many software
projects suffer from the risk of schedule slippage
...
Technical risks
Technical risks concern potential design, implementation, interfacing, testing, and
maintenance problems
...

Most technical risks occur due to the development team’s insufficient knowledge about
the project
...
Business risks
This type of risks include risks of building an excellent product that no one wants, losing
budgetary or personnel commitments, etc
...

For risk assessment, first each risk should be rated in two ways:
• The likelihood of a risk coming true (denoted as r)
...


DEPT OF CSE & IT
VSSUT, Burla

Based on these two factors, the priority of each risk can be computed:
p=r*s
Where, p is the priority with which the risk must be handled, r is the probability of the risk
becoming true, and s is the severity of damage caused due to the risk becoming true
...

Risk Containment
After all the identified risks of a project are assessed, plans must be made to contain the most
damaging and the most likely risks
...
In
fact, most risks require ingenuity on the part of the project manager in tackling the risk
...

Transfer the risk- This strategy involves getting the risky component developed by a third
party, buying insurance cover, etc
...
For example,
if there is risk that some key personnel might leave, new recruitment may be planned
...
For this the risk leverage of
the different risks can be computed
...
More
formally,
risk leverage = (risk exposure before reduction – risk exposure after reduction) / (cost
of reduction)
Risk related to schedule slippage
Even though there are three broad ways to handle any risk, but still risk handling requires a lot of
ingenuity on the part of a project manager
...
Risks relating to schedule slippage arise primarily due to the intangible nature

DEPT OF CSE & IT
VSSUT, Burla

of software
...
Visibility of a software product can be increased by producing relevant documents
during the development process wherever meaningful and getting these documents reviewed by
an appropriate team
...
Completion of a
phase of the development process before followed need not be the only milestones
...
A milestone is reached, once documentation produced as part of a software engineering task
is produced and gets successfully reviewed
...
An
approximate rule of thumb is to set a milestone every 10 to 15 days
...
g
...
These objects are usually referred to and modified by a number of
software engineers through out the life cycle of the software
...
The state of each deliverable
object changes as development progresses and also as bugs are detected and fixed
...
Version vs
...
On the other hand a new revision of a software refers
to minor bug fix in that software
...

For example, one version of a mathematical computation package might run on Unix-based
machines, another on Microsoft Windows and so on
...
Enhancements to the functionalities of the
software may also be needed
...
Often systems are described as version m, release n; or simple m
...
Formally,
a history relation is version of can be defined between objects
...

Necessity of software configuration management
There are several reasons for putting an object under configuration management
...
Unless strict discipline is enforced regarding updation and storage of
different objects, several problems appear
...


DEPT OF CSE & IT
VSSUT, Burla



Inconsistency problem when the objects are replicated
...
g
...
As
each engineer makes changes to his local copy, he is expected to intimate them to other
engineers, so that the changes in interfaces are uniformly changed across all modules
...
This makes the different copies of
the object inconsistent
...

Therefore, when several team members work on developing an object, it is necessary for
them to work on a single copy of the object, otherwise inconsistency may arise
...
Suppose there is a single copy of a
problem module, and several engineers are working on it
...
Though the problem associated with concurrent access to
program code has been explained, similar problems occur for any other deliverable
object
...
When a project is underway, the team
members need a stable environment to make progress
...
When an effective configuration management is in place, the
manager freezes the objects to form a base line
...
The
requester makes changes to his private copy
...
This establishes a baseline for others to use and depend on
...
Freezing a configuration may involve archiving
everything needed to rebuild it
...




System accounting and maintaining status information
...




Handling variants
...
Suppose somebody has several variants of the same module, and finds a bug in
one of them
...
To do it efficiently, he
should not have to fix it in each and every version and revision of the software separately
...
A configuration management tool provides
automated support for overcoming all the problems mentioned above
...
The
configuration management tool enables the engineers to change the various components in a
controlled manner
...

• Configuration control ensures that changes to a system happen smoothly
...
Controlled objects
are those which are already put under configuration control
...
Pre controlled objects are not yet under configuration control, but
will eventually be under configuration control
...
Controllable objects include both controlled and pre
controlled objects
...

• Source code for each module
• Test cases
• Problem reports
The configuration management plan is written during the project planning phase and it lists all
controlled objects
...
If too much is controlled, overheads due to configuration
management increase to unreasonably high levels
...

Configuration Control
Configuration control is the process of managing changes to controlled objects
...
The configuration control system prevents unauthorized changes to

DEPT OF CSE & IT
VSSUT, Burla

any controlled objects
...
38
...
Configuration
management tools allow only one person to reserve a module at a time
...
38
...
Thus, by preventing more than one engineer to simultaneously
reserve a module, the problems associated with concurrent access are solved
...
38
...
The engineer needing to change a module first obtains a private copy of the module
through a reserve operation
...

However, restoring the changed module to the system configuration requires the permission of a
change control board (CCB)
...
For every change that needs to be carried out, the CCB reviews the changes made to
the controlled object and certifies several things about the change:
1
...

2
...

3
...

4
...
g
...

DEPT OF CSE & IT
VSSUT, Burla

The change control board (CCB) sounds like a group of people
...
Once the CCB
reviews the changes to the module, the project manager updates the old base line through a
restore operation (as shown in fig
...
1)
...
By constraining the developers’ ability to replace reserved
objects, a stable environment is achieved
...
Also, since only the manager can update the baseline after the CCB approval,
unintentional changes are eliminated
...
SCCS or RCS can be used for controlling and managing different versions of text files
...
e
...
) SCCS and RCS provide an efficient way of storing versions that minimizes the
amount of occupied disk space
...
1,
MOD1
...
3
...
1 together with
changes needed to transform MOD1
...
2 and MOD1
...
3
...
The
main reason behind storing the deltas rather than storing the full version files is to save disk
space
...
e
...
Individual developers
check out components and modify them
...

Revisions are denoted by numbers in ascending order, e
...
, 1
...
2, 1
...
It is also possible to
create variants or revisions of a component by creating a fork in the development history
...
In a more restrictive sense, a CASE tool means
any tool used to automate some activity associated with software development
...
Some of these CASE tools assist in phase related tasks such as specification,
structured analysis, design, coding, testing, etc
...

Reasons for using CASE tools
The primary reasons for using a CASE tool are:
• To increase productivity
• To help produce better quality software at lower cost
CASE environment
Although individual CASE tools are useful, the true power of a tool set can be realized only
when these set of tools are integrated into a common framework or environment
...

Since different tools covering different stages share common information, it is required that they
integrate through some central repository to have a consistent view of information associated
with the software development artifacts
...
Through the central repository all the CASE tools in a CASE environment share
common information among themselves
...
A schematic representation of a CASE
environment is shown in fig
...
1
...
39
...
In contrast to a CASE environment, a programming environment is an integrated
collection of tools to support only the coding phase of software development
...
Some
of those benefits are:




A key benefit arising out of the use of a CASE environment is cost saving through all
development phases
...

Use of CASE tools leads to considerable improvements to quality
...


DEPT OF CSE & IT
VSSUT, Burla









CASE tools help produce high quality and consistent documents
...

CASE tools take out most of the drudgery in a software engineer’s work
...

CASE tools have led to revolutionary cost saving in software maintenance efforts
...

Introduction of a CASE environment has an impact on the style of working of a
company, and makes it oriented towards the structured and orderly approach
...
The important features of a prototyping
CASE tool are as follows:
• Define user interaction
• Define the system control flow
• Store and retrieve data required by the system
• Incorporate some processing logic
Features of a good prototyping CASE tool
There are several stand-alone prototyping tools
...
A good prototyping tool
should support the following features:
 Since one of the main uses of a prototyping CASE tool is graphical user interface (GUI)
development, prototyping CASE tool should support the user to create a GUI using a
graphics editor
...

 It should integrate with the data dictionary of a CASE environment
...

 The user should be able to define the sequence of states through which a created
prototype can run
...


DEPT OF CSE & IT
VSSUT, Burla



The run time system of prototype should support mock runs of the actual system and
management of the input and output data
...
The
following supports might be available from CASE tools
...

 It should support effortlessly drawing analysis and design diagrams
...

 The CASE tool should provide easy navigation through the different levels and through
the design and analysis
...
Whenever it is possible, the system
should disallow any inconsistent operation, but it may be very difficult to implement such
a feature
...

Code generation and CASE tools
As far as code generation is concerned, the general expectation of a CASE tool is quite low
...
More pragmatic supports
expected from a CASE tool during code generation phase are the following:






The CASE tool should support generation of module skeletons or templates in one or
more popular languages
...

The tool should generate records, structures, class definition automatically from the
contents of the data dictionary in one or more popular languages
...

The tool should generate code for user interface from prototype definition for X window
and MS window based applications
...

 It should generate test set reports in ASCII format which can be directly imported into the
test plan document
...
Thus, instead of defining hardware requirements for a CASE tool, the task at hand
becomes to fit in an optimal configuration of CASE tool in the existing hardware capabilities
...

The heterogeneous network is one instance of distributed environment and this can be chosen for
illustration as it is more popular due to its machine independent features
...
The multiple
clients who run different modules access data dictionary through this server
...
Though it is possible to run many servers for different
projects but distributed implementation of data dictionary is not common
...
The
data dictionary provides consistent view of all project entities, e
...
a data record definition and its
entity-relationship diagram be consistent
...
This means that it should allow back up/restore, copy, cleaning part of the
data dictionary, etc
...
The tool should support multi-windowing environment for the users
...
It also facilitates navigation
and switching from one part to the other
...
This helps in producing up-to-date documentation
...
It should be possible to export text, graphics, tables, data dictionary reports
to the DTP package in standard forms such as PostScript
...


DEPT OF CSE & IT
VSSUT, Burla

External Interface
The CASE tool should allow exchange of information for reusability of design
...
Similarly, the data dictionary should provide a programming interface to
access information
...

Reverse Engineering
The CASE tool should support generation of structure charts and data dictionaries from the
existing source codes
...
If the tool is
used for re-engineering information systems, it should contain conversion tool from indexed
sequential file structure, hierarchical and network database to relational database systems
...
It should have print facility to obtain hard copy of the viewed screens
...
Ideally, it should support a
query language to view its contents
...
This would necessitate the function of a CASE administrator organization who can
tailor the CASE tool to a particular methodology
...
The future CASE tools would provide
help to aesthetically and automatically lay out the diagrams
...

 Data dictionary standards- The user should be allowed to integrate many development
tools into one environment
...
Moreover, a preferred tool would require tuning up for a
particular system
...
This is possibly only if
some standard on data dictionary emerges
...
This facility may be used to build some special methodologies
...


DEPT OF CSE & IT
VSSUT, Burla

Architecture of a CASE environment
The architecture of a typical modern CASE environment is shown diagrammatically in fig
...
2
...
Characteristics of a tool set have been discussed
earlier
...
39
...

Object Management System (OMS) and Repository
Different case tools represent the software product as a set of entities such as specification,
design, text data, project plan, etc
...
The commercial relational
database management systems are geared towards supporting large volumes of information
structured as simple relatively short records
...
By contrast, CASE tools create a large number of entity and relation types with
DEPT OF CSE & IT
VSSUT, Burla

perhaps a few instances of each
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 40

SOFTWARE REUSE
Advantages of software reuse
Software products are expensive
...
A possible
way to reduce development cost is to reuse parts from previously developed software
...

Artifacts that can be reused
It is important to know about the kinds of the artifacts associated with software development that
can be reused
...
However, the prominent items that can be effectively reused are:
• Requirements specification
• Design
• Code
• Test cases
• Knowledge
Pros and cons of knowledge reuse
Knowledge is the most abstract development artifact that can be reused
...
e
...
However, two major difficulties with
unplanned reuse of knowledge are that a developer experienced in one type of software product
might be included in a team developing a different type of software
...
A planned reuse of
knowledge can increase the effectiveness of reuse
...
But, it is usually very difficult to extract and document
reusable knowledge
...
No one in his right mind would think of writing a routine to compute sine or
cosine
...
Several interesting aspects
emerge
...
Everyone has clear ideas about what kind of argument
should cosine take, the type of processing to be carried out and the results returned
...
For example, cosine requires only one parameter
...

Basic issues in any reuse program
The following are some of the basic issues that must be clearly understood for starting any reuse
program
...
Selection of the right kind of components having potential for reuse is important
...

Component indexing and storing- Indexing requires classification of the reusable
components so that they can be easily searched when looking for a component for reuse
...

Component searching- The programmers need to search for right components matching
their requirements in a database of components
...

Component understanding- The programmers need a precise and sufficiently complete
understanding of what the component does to be able to decide whether they can reuse the
component
...

Component adaptation- Often, the components may need adaptation before they can be
reused, since a selected component may not exactly fit the problem at hand
...

Repository maintenance- A component repository once is created requires continuous
maintenance
...


DEPT OF CSE & IT
VSSUT, Burla

The faulty components have to be tracked
...
In this case, the obsolete components might have to be
removed from the repository
...

Reuse domain- A reuse domain is a technically related set of application areas
...
A reuse domain is shared understanding of
some community, characterized by concepts, techniques, and terminologies that show some
coherence
...

Just to become familiar with the vocabulary of a domain requires months of interaction with the
experts
...
Domain analysis identifies the objects, operations, and the
relationships among them
...
The reusable operations can be
scheduling a flight, reserving a seat, assigning crew to flights, etc
...
A domain model transcends specific applications
...

During domain analysis, a specific community of software developers gets together to discuss
community-wide-solutions
...
The actual construction of reusable components for a domain is called
domain engineering
...
The problem-oriented languages are also known as application
generators
...
The domains slowly develop
...
Obviously, no reusable components are
available
...

Stage 2: Here, only experience from similar projects is used in a development effort
...


DEPT OF CSE & IT
VSSUT, Burla

Stage 3: At this stage, the domain is ripe for reuse
...
Standard solutions to standard problems are available
...

Stage 4: The domain has been fully explored
...
Programs are not written in the traditional sense any more
...


DEPT OF CSE & IT
VSSUT, Burla

LECTURE NOTE 41

REUSE APPROACH
Components Classification
Components need to be properly classified in order to develop an effective indexing and storage
scheme
...
Hardware components are classified using a
multilevel hierarchy
...
The higher the level at which a
component is described, the more is the ambiguity
...

Prieto-Diaz’s classification scheme: Each component is best described using a number of
different characteristics or facets
...
A popular search
technique that has proved to be very effective is one that provides a web interface to the
repository
...
The approximate automated search locates products that
appear to fulfill some of the specified requirements
...
These serve as the starting point for
browsing the repository
...
Browsing is done using the keyword-to-keyword, keyword-to-product, and
product-to-product links
...
Finding a satisfactorily item from the repository may require several locations
of approximate search followed by browsing
...
However, we must
remember that the items to be searched may be components, designs, models, requirements, and
even knowledge
...
The software industry is always trying to implement something that has
not been quite done before
...
However, as technology
advances, some components which are still reusable, do not fully address the current
requirements
...
Making a product available before it has been thoroughly

DEPT OF CSE & IT
VSSUT, Burla

assessed can be counter productive
...

Application generator -The problem- oriented languages are known as application generators
...
The specification is
usually written using 4GL
...
Application generator
can be applied successfully to data processing application, user interface, and compiler
development
...
The
biggest of these is that the application generators can express the variant information in an
appropriate language rather than being restricted to function parameters, named constants, or
tables
...

Shortcomings of application generators
Application generators are handicapped when it is necessary to support some new concepts or
features
...

Re-use at organization level
Achieving organization-level reuse requires adoption of the following steps:
• Assessing a product’s potential for reuse
• Refining products for greater reusability
• Entering the product in the reuse repository
Assessing a product’s potential for reuse
...
The
questionnaire can be devised to access a component’s reusability
...
Depending on the answers given by the programmers, either the
component be taken up for reuse as it is, it is modified and refined before it is entered
into the reuse repository, or it is ignored
...

• Is the component’s functionality required for implementation of systems in the
future?
• How common is the component’s function within its domain?
• Would there be a duplication of functions within the domain if the component is
taken up?

DEPT OF CSE & IT
VSSUT, Burla

• Is the component hardware dependent?
• Is the design of the component optimized enough?
• If the component is non-reusable, then can it be decomposed to yield some reusable
components?
Can we parameterize a non-reusable component so that it becomes reusable?
Refining products for greater reusability
...
Machine dependency must be abstracted
out or localized using data encapsulation techniques
...

• Operation generalization: Operations should be added to make the component
more general
...

• Exception generalization: This involves checking each component to see which
exceptions it might generate
...

• Handling portability problems: Programs typically make some assumption
regarding the representation of information in the underlying machine
...
The programs also often need to
call some operating system functionality and these calls may not be same on all
machines
...
A portability solution to overcome these problems is shown in fig
...
1
...
Also, all platform-related calls should be routed through the portability
interface
...


DEPT OF CSE & IT
VSSUT, Burla

Fig
...
1: Improving reusability of a component by using a portability interface
Factors that inhibit an effective reuse program
In spite of all the shortcomings of the state-of-the-art reuse techniques, it is the experience of
several organizations that most of the factors inhibiting an effective reuse program are nontechnical
...

 Need for commitment from the top management
...

 Adequate incentive to reward those who reuse
...

 Providing access to and information about reusable components
...


DEPT OF CSE & IT
VSSUT, Burla

REFERENCES
BIBLIOGRAPHY
1
...

WEBLIOGRAPGY
2
...
tutorialspoint

---