CHAPTER-1

Introduction to Software Engineering

Software engineering is field of computer science that deals with
development of software system for the complex system by the team of engineers.

Difference between programming and software engineering

Programming
Software Engineering
1. Programming
is
personal 1. Software engineering is essentially a
activity.
2. Program

team activity.
writes

complete 2. Software engineering defines software

program

components which are combined to build

system.

A software component written can be modified by others to develop latest

versions.
Evolution of Software engineering
In early days, users are the engineers who build the hardware and also they
are the persons who developed programs as a side activity .The program have less
complexity.
As hardware become powerful and cheaper the software written in high
level language satisfied the user .In turn there is a great demand for

programmers, who are not known about inside of the computer. So there was a
development of software crisis having following attributes.
1. software projects were failed
2. Many software projects ware over budget, expensive and unreliable.
3. Many software projects did not satisfy the user requirements.
4. Complexities of software projects were expensive to maintain.
5. Demand for new software projects had increased rather than its
production.
What is software Engineering?
The baseline definition in 1969 by Fritz Bauer as The establishment and use of
sound engineering principles in order to obtain economically, software that is
reliable and works efficiently on real machines.
The Goals of Software engineering are:
1. Improve quality of software products.
2. To increase productivity.
3. To give job satisfaction to software engineers.
Relationship of Software Engineering with other disciplines
The following disciplines provides foundation
1. Computer science
2. Management science
3. Economics
4. System engineering
5. Communication skills.
Computer science gives scientific foundation to the software as engineering is
engineering.
Since software engineering is a team activity it requires technical and
managerial control, which is provided by management science for project
management.

Economics provides the foundation for resources estimation and cost control.
System engineering is concerned with studying complex system. Since software
is a component of such a large system.
A good interpersonal communication skills is very important for
software engineers. Because software engineering is activity within organizational
context and among customers, managers, software engineering engineers.

SOFTWARE CHARACTERISTICS
1. Software engineering is engineering is engineered, not manufactured
software engineering is a logical, than a physical element.
2. High quality software engineering development can be achieved by good
design. Software engineering is not subject to manufacturing problems.
3. Software engineering does not wear out
There are no spare parts of software which can be plug into, when software
fails. A software engineering must be reengineered to remove software
engineering failures. All software failures are caused by design faults.

4. Although software components are coming into use

As for software engineering development, we have subroutine libraries
implement well define algorithms.
5. Software engineering does not degrade as time goes on. Software
engineering failures is often by design and implementation error time and
not by using it over time.

Reusable Software Engineering Components:

Off the shelf components: These are components developed by the team for
a past project.

They also called as COTS (Commercial Off The Shelf

components)

Full Experience Components : These are software engineering components

developed in past for similar, but not same projects

Partial experience components: these are components developed in past but

require substantial modification.

New Components: These are Components to be built.

A Well-Engineered S/W?
A well engineered S/W system should have the following attributes:
S/W must be easy to maintain.
S/W must be reliable & efficient
S/W must provide an appropriate user-interface.

THE SOFTWARE LIFECYCLE

1. Requirement Analysis & Specification:
Here, we collect functional & non- functional requirements of the proposed
system from the customer. Functional requirements describe the system
softwares processing & input /output needs. Non functional describe about
machine in terms of its size & capacity.
2. System & Software Design:
In this stage, the designers produce a system architecture i.e. description of
hardware

&

software

systems.

The

software

designers

design

Units/Models/Subroutines, which is ready for translation in M/C code.

The output of this phase is description of program units written in a formal
language which is given to programmer for translation.
3. Coding and Unit testing:
The designed module is given to the purpose of coding. In this stage, each
unit is coded using a programming language and tested for its proper working.
4. Implementation & Integration of S/W Units:

The design is translated to program units. These units are tested

individually to ensure that it matches design & its requirement specification. The
common errors are typing mistakes, statement omission.
Then the units are integrated in a pre-defined way such as top-down or
bottom-up to form a system.
5. Software Operation & Maintenance:
This phase describes modification to the system developed while operation.
Corrective maintenance defines modification as a result of error discover.
Adaptive

maintenance

requires

modification

because

of

change

in

environment or system requirement.

Meaning of process
Process is a step involving activities and resources that produce a needful
output. Concerned to software development, a process is called as life cycle,
because it is a set of tasks performed to develop the software.
A process comprised of tools and techniques to develop a product, which
should be documented and practiced which helps us to examine, understand and
improve the activities.
It also helps us to learn from the past development projects, to develop
more qualitative products than previous. It enables us to pass the experiences of
project to others.
The software development usually involves steps

Feasibility study

Requirement analysis and definition

System design

Coding / unit testing

Unit testing

Integration testing

System testing

Maintenance
5

Where each stage is a process or processes each has activities such as constraints
inputs, outputs and resources.
For example, requirement analysis look like a single process, but it is a collection
of

activities

i.e.

budget

and

scheduling

the

production,

collecting

the

requirements from the user.

Need for process models

Process models are described/used for the development of software product for
following reasons:
1. Helps the development team to find out problems inconsistencies to correct
them. As problems are solved final product will be effective
2. Since models aims at goals and quality of the final product, the
development team focuses on the goal and errors are fixed before its design.

WATERFALL MODEL:
The model is used by US defense. The beginning of a stage is after the
completion of previous stage. Thus providing completeness and consistency
Requirements
Analysis
System Design
Program Design
Codin
g
Unit & Integration
Testing
System Testing
Acceptance
Testing
Operation &
Maintenance

1. Feasibility study: This is to determine whether developing the product is

financially worth while and technically possible.
2. Requirement analysis and definition: This stage provides a document
exactly and completely. The document is called as Software Requirements
specification (SRS)
3. Design: This stage produces the software architecture, which is helpful to
write in some programming language. The SRS is the input to this stage.
4. Coding: The design provided will be coded using some programming language
by programmer.
5. Unit Testing: The coded modules are tested that they meet requirements or
not, and whether they work requirements properly or not.
6. Integration and system testing: different units are integrated in some
predefined manner and tested that all modules are integrated.
Then the integrated system functions are tested to ensure that it works
according to SRS.
7. Maintenance: The maintenance requires more effort than its development.
The ideal waterfall model assumes that there is no defect at any stage. The defeat
in a stage can be found in its next stage. For example the design defeats can be
found at coding stage.
Advantages:

Easy to explain to user.

Well defined stages and activities

Helps to plan and schedule the project

Verification at each stage ensures detection of errors and correcting

them.

Disadvantages:

The requirements provided is stable across the project

Next stage begins after completion of previous stage, which looks quite
difficulty.

User training is not given much importance

7

Testing is done at the end of SDLC, not throughout cycle.

Implementation is ignored.

2. PROTOTYPING MODEL:
Prototype is a partially developed product with key requirements of project,
which enables customer and developers to examine proposed system and decide it
is suitable for the product or not.
Before starting actual project, a working prototype is built. It is toy
implementation of the system with limited functionality and low reliability. This
helps

developers

to

pick

from

alternatives

for

the

project

and

better

understanding of user needs.

The prototyping model starts with minimum / approximate requirements,
carry out a quick design using shortcuts (i.e., dummy functions). The developed
prototype is submitted to customer for his evaluation. Depending on his feedback,
requirements are refined. This cycle continues till user approves the prototype.
Then design of product is carried out. As usual, implementation, coding,
testing and maintenance are done.
Advantages

Requirments Gathering

1. Helps to determine feasibility of system.

Quick Design

2. Minimizes change requests and massive redesign costs of final product.

Build Prototype

Refine Requirments
3. A prototype
modification is faster and cheaper than modification of final
Customer
software.

Suggestions

Customer Evolution of the

Prototype

4. As user and developers interaction is high commitment is high

Acceptance by
Customer

Disadvantages
Design

1. user may not want to discard prototype

2. prototyping tools are expensive
Implementation
Test

Maintenance

3. PHASED DEVELOPMENT
Cycle time: The time between the requirements documents was written and the
time the system was delivered to the customer.
In early days, the cycle time is higher, since users are lesser. But todays
business environment can not tolerate this long delay. So the phased development
module was used to reduce the cycle time.
In this model, system is designed so that it can be delivered in pieces,
enabling the users to have some functionality, while the rest is being developed.
Thus, production and development system are both running simultaneously.
Development System: The system which is next version that is developed to
replace current production system.
We refer to this system by release numbers developers build release 1, test
it and submit to users as first operational system. As the users release 1,
developers were building the release 2. Thus developers are working on N + 1
release while N is operational.

Developers

Build Release 1

Build Release 2

Build Release 3

Time

Users
Use Release 1

Use Release
2
9

Use Release 3

This model uses two popular approaches:

1. incremental development
2. iterative development
1. Incremental development: in this approach, the system is partitioned into
subsystems by functionality. The first release begins with small function
subsystem and then adding more functionality in next releases. Finally full
functionality system is released.

Incremental
Development

2. Iterative development: In this approach, at the beginning full system was

delivered and then changes are made to the functionality of each subsystem
with each new release.

Iterative
Development

To understand difference between incremental and iterative development,

consider a word processing package, which delivers the functionality; creating
text, formatting text, cut and paste operations.

10

Using incremental development, in release 1 the system performs only

creation, in release 2 both creation & formatting and in release 3, all the
functionalities will be given to the system.
Using iterative development, in release 1 all functionalities will be delivered
i.e. text creation, formatting, but cut & paste operation is slower. In release 2 the
same functionalities with enhanced quality is provided to the customer. In this
way, each release improves the functionality than the previous releases.
This model is desirable for reasons:
1. User training is given with each release; if some functions are missing
developers get the suggestions from the user. Hence the developers are
responsive to the users.
2. Market can be created for the functionality.
3. Frequent releases make the product qualitative, as they are reported by the
users very quickly.
4. The development team can focus on different areas to improve the
performance, such as graphical user interface.

SPIRAL MODEL
Boehm (1988) viewed the software development process in terms of risks
and suggested the spiral model to minimize and control risk.
Here, the concept of operations document is prepared before the
development process begins, which contains an initial plan to evaluate risks to
describe how the system should work.
From that document, a set of requirements are specified and checked for
the complete and correctness.
11

In the second iteration, the requirement specification is done.

In the third iteration, system development is performed.
The fourth iteration performs testing.

In each iteration, risk analysis is performed to understand the risks in each

stage and prototyping verifies the feasibility and provides alternatives.
When risks are identified, project managers decide how to eliminate or
minimize the risk. Prototyping is done at each stage, so the users can select
which strategy to be chosen and used.
Spiral model cannot be used for small or medium projects.
The model requires ample budget and resources for development.

Advantages:
1. Similarity to incremental & iterative model, but major focus on risks.
2. Each cycle has fixed number of activities.
3. The interesting idea used is customer communication and planning.
4. Customer evaluation is higher.
12

Disadvantages:
1. When to stop is not clear.
2. Lack of risk experts.
3. Technical difficulty must be solved at design stage not at the testing stage.

13

CHAPTER -2
SOFTWARE PROJECT PLANNING
Software Management:
The applications of knowledge, skills, tools and techniques to project
activities, in order to meet or exceed user needs and expectations of customer
from a project.
The software brooks stated that project management is an activity of
making visible which is invisible.
They also noted that processes and products of software project has certain
characteristics:
1. Invisibility: The software development is a logical work rather than physical,
the progress is invisible.
2. Complexity: The complexity of software project is higher than other
engineering works.
3. Flexibility: The software system has to be more flexible, since it has to
accommodate with physical or organizational structure and other components.
4. Standard process: The software development process is to be followed by
project managers to meet required standard of product.
They have to monitor the progress on time and within cost estimation.

Software project planning:

Software project planning consists of following activities.
1. Defining a problem
a. Develop definite statement of problem, includes describing present
situation, and goals to be achieved in formal language.
b. Justify computerized solution strategy
14

c. Identify functions to be provided, hardware subsystem & people subsystem.

2. Developing a solution strategy:
a. Outline several solution strategies.
b. Conduct feasibility study of each strategy.
c. Recommend a solution strategy, indicating why other strategies were
rejected.
d. Develop a list of priorities for product.
3. Planning a development processing:
a. Define a life- cycle model
b. Plan configuration management, quality assurance & validation activities.
c. Determine tools, techniques & notations to be used.
d. Determine preliminary cost estimation for system development.
e. Establish preliminary development schedule.
f. Establish preliminary staff estimation.
g. Develop preliminary estimates of computing resources.
h. Prepare glossary of terms.
i. Identify sources of information and refer them throughout project plan.
Planning is the most important for the effective software management. Project
manager should identify problems and prepare plan to solve them.
The initial plan should be used as driver of the project, which changes as the
project progresses.

1. Defining the problem:

The first step is to prepare a document in customers terminology,
describing problem to be solved and also to be achieved by new software.
Problem definition requires thorough understanding of problem. This can
be gained by customer interviews, observation of problem tasks. The planner
must be skillful to perceive customer problem.

15

Software system may fail because of less understanding of problem or

unable to communicate the true problem. The reason is due to social, economic
or political circumstances.
The second step is to plan software project to determine feasibility, and also
socially and politically acceptable to customer.
A computing system consists of three subsystems.
a. People subsystem: include operators, maintenance personnel & end users.
b. Hard ware subsystem: include hardware & peripheral devices, antennas,
radars.
c. Software sub system: include software to be developed, existing software.
The preliminary definition plans the functions performed by major subsystem.

GOALS AND REQUIREMENTS:

The common goals of project and product are they should be useful, reliable,
understandable and cost effective. The goals on the process and product are:
a. Qualitative process goal: The development process should enhance skills
of quality assurance personnel.
b. Quantitative process goal: system should be delivered within 12 months.
c. Qualitative product goal: system should make users jobs more interesting.
d. Quantitative product goal: The system should reduce 25% of cost for each
transaction.
The other goals are transportability, ease of use for non-programmers.
Requirements specify the capabilities that a system must provide in order
to solve the problem.
Functional

requirements,

performance

requirements

for

hardware,

firmware, software and user interfaces. They should specify standards and quality
assurance standard for project and product.
The quality requirements are:
16

a. Software management response external interrupts must be within 0.25

seconds.
b. Software management should be fully operational.
c. Software management reside in 50 k bytes in primary memory qualitative
requirements are:
a. Accuracy should be sufficient.
b. Software management shall use of primary memory efficiently.
The quality attributes are the high level goals & requirements, such as
reliability. Reliability can be expressed in terms of source code accuracy,
robustness, completeness & consistency.
The problem must be clearly stated, to avoid misunderstanding between
customer & developers. Acceptance criteria must be stated by verifying products
using methods, inspection and analysis. A requirement must be enclosed with
method to verify it.

2. Developing a Solution Strategy

A solution strategy is not a detailed plan, but a general statement
containing possible solutions.
The strategy factor consider, such as batch or time sharing, database or file
system, graphics or text, real time or off-line processing methods.
Several solution strategies are considered but best one is adopted. The
planners chose the best one to perform feasibility study and preliminary cost
estimation.
A solution strategy will be generated without regarding feasibility. A solution
strategy is examined under solution constraints. Constraints describe the
boundaries of solution. Feasibility study determines possibility of solution within
constraints.

17

A solution strategy must satisfy goals and requirements .techniques used to

determine feasibility of solution strategy are case studies, worst-case analysis,
simulation and building prototypes.
Prototype

is

having

limited

functionality,

low

reliability

and

poor

performance.
When recommending a strategy, document is written defining reasons for
rejecting other strategies and justification of proposed strategy.
A solution strategy should include a priority list of product features .Since
at development cycle there may be some change, where we can indicate available
feature in priority list. Product priority is very useful is planning successive
versions to be built later.

3. Planning Development process:

This involves following activities:
a. Define life-cycle and organizational structure
b. Plan configuration management, Quality assurance, validation activities.
c. Determine tools, techniques and notations to be used.
d. Establish preliminary cost estimation, development schedule and staffing
estimates.
e. Develop preliminary computing resources estimation
f. Prepare a glossary of terms.
Second step of above and project management plan is treated as other
planning activities.
a. Planning configuration management:
Concerned with change in work products, accounting for status of work
product and maintaining program library.
b. Planning Quality Assurance: This plans quality to be achieved in different phases.
c. Planning verification and validation: Verification ensures the various work
products are complete and consistent to customer needs.
But validation is concerned with assessing quality of software.
18

d. Project Management plan: After completion of project planning, projects

managers document results of planning phase called as Software project
Management plan (SPMP). SPMP defines clear statement of goals and major
decisions taken to achieve goal. The document should not contain any ambiguity.
ORGANIZATION OF THE SOFTWARE PROJECT MANAGEMENT PLAN (SPMP)
DOCUMENT
1. Introduction
a. objectives.
b. Major functions
c. Performance issues
d. Management and Technical Constraint
2. Project Estimates
5. Project Resources

a. Historical Data Used.

a. People

b. Estimation Techniques Used.

b. Hardware and Software

c. Effort Resource,

c. Special Resources

d. cost and Project Duration

6. Staff Organization

3. Risk management Plan

a. Team Structure

a. Risk Analysis

b. Management Reporting

b. Risk Identification

7. Project Tracking and Control Plan

c. Risk Estimation

8. Miscellaneous plans

d. Risk Abatement Producers

a. Process Tailoring

4. Schedule

b. Quality Assurances

a. Work Breakdown Structure

c. Configuration Management

b. Task Network representation

d. Validation and Verification

c. Gantt Chart representation

e. System Testing

d. PERT Chart representation

f. Delivery Installation & Maintenance

CHAPTER-3
SOFTWARE REQUIREMENT

SPECIFICATION
19

A system is a collection of elements that are organized to perform a task

using some method. They involve elements such as hardware, software, people,
procedures & processes. A system analyst defines these elements of system
initially.
System Analysis Objectives:
Before preparing SRS (Software requirement specification) system should be
analyzed for following tasks;
a) To identify customer needs.
b) Feasibility of system
c) To perform technical & economic analysis
d) Establish cost.
The main aim is to identify customer needs, which lead to success of
software system.
Feasibility Study:
This is a study about time & money is enough or not. This involves costbenefit analysis of the system.
Technical feasibility indicates that what technology to be used for
development & tools needed.
Requirements Engineering:
This phase believes A problem well specified is half-solved.
Requirement engineering is a disciplined application of proven, principals,
methods, tools &notations to describe a proposed systems intended behavior &
its associated constraints.
This includes following activities:
1) Identification & documentation of user needs.
2) Creation of a document describing external behavior & its associated
constraints.
3) Analysis & validation of document to ensure completeness.
The primary output of this stage is requirement specification, which
describes both hardware & software. If it describes only software then it is
20

Software requirement Specification. The document must be understandable by:

users, customers, designers & testers. The document includes.
1) Inputs & Outputs.
2) Functional requirements.
3) Non-functional requirements-performance.
Reasons for Poor-Requirement Engineering:
1) Requirements will change.
2) Difficult to cover.
3) Communication barrier between developers & users.
4) Lake of confidence by developers.
5) Use of in-appropriate methods.
6) Insufficient training.

Software Requirement Specification (SRS)

SRS is a means of translating ideas in the minds of clients into a formally
specified set of requirements. SRS document is a communication medium
between customer & the supplier. The document is initially not to be edited.
This phase includes following activities;
a) Problem/Requirement Specification
b) Requirement Specification.
The first step is to understand the problem, goals, & constraints.
Second step is the specification of needs that is identified in first step. This
phase terminates with validated requirement specification document.

Why SRS is required?

This may be used in competitive tendering of the company or writing to
their own.
Used to capture user requirements & highlight any inconsistencies,
conflicting requirements.

21

The client doesnt know about software or software development & the
developers dont understand clients problem & application area. Hence there is a
communication gap between client & developers. Thus, SRS act as a bridge
between this communication gaps.
A good SRS should satisfy all parties. SRS also helps clients to understand
their needs.

What is contained in SRS? / Components of SRS

The SRS document should contain a list of requirements that has to be
agreed by both client & developers.
1) Functional requirements
2) Performance requirements
3) Interface requirements
4) Operational requirements
5) Resource requirements

7) Acceptance testing requirements

8) Documentation requirements
9) Quality requirements
10)

Safety requirements

11)

Reliability & Maintainability requirements

6) Verification requirements

1) Functional Requirements:
This is a subset of overall system requirements. This consider trade-offs
(hardware & software) & also describes how the system operates under normal
conditions & response to software failures OR invalid inputs to system.
2) Performance Requirements:
This can be stated in measurable value i.e., rate, frequency, speeds & levels.
This can be extracted from system specifications.
3) Interface Requirements:
This

can be

specified

separately

for hardware & software.

These

requirements specify any interface standard that is requested. These should be

carefully documented.
4) Operational Requirements:
This gives the in the field view of the system. The specified details are,
22

a) How system will operate & communicate?

b) What are the operator syntax/notations?
c) How many operators & their qualification required?
d) What help is provided by system.
e) How error messages should be displayed?
f) What is screen layout look?
5) Resource Requirements:
Specify utilization of hardware, Such as amount, percentage & memory
usage. This is very important when extending hardware. The software resources
include using specific, certified, standard compilers & databases.

6) Verification Requirements:
This specifies how customer accepts after completion of project. This specifies
how functional & performance requirements to be measured. This also states,
whether tests are to be staged or only under completion of the project and also
whether a representative of clients company should present or not.
7) Acceptance Testing:
This provides details of tests to be performed for customer acceptance in
document.
8) Documentation Requirements:
This specifies what documents are to be supplied to client, either through
the project OR at the end of the project. The document & other relevant
documentation
9) Quality Requirements:
This specifies whether product should meet international or local
standards. The quality factors are: Correctness, reliability, efficiency, integrity,
usability, maintainability, flexibility, portability, reusability
10) Safety Requirements:

23

This specifies safety steps to be taken for protection of human, equipments

& data. i.e., protecting from moving parts, electrical circuitry & other physical
dangers
11) Reusability Requirements:
This states that software must perform function under stated conditions,
for a given period of time.
12) Maintainability Requirements:
This is maintenance of software in the site it is used, for hardware &
software changes in the system.

Characteristics of Good SRS:

The SRS must be clear, concise, consistent, traceable & unambiguous.
Complete: The SRS should include all types of requirements to be specified.
Consistent: There should not be any conflict, there may be following confliction.

Multiple descriptors: Two or more words referring to the same object.

Opposing physical requirements: Description of real world objects clash,

i.e., one requirement states warning indicates orange & another states red.

Opposing functional requirements: This is a conflict in functions.

Traceable: Tracing the references, which help in modifications have made to

requirement to bring out to its current state. This is an aid in modification in
future documents by stating references.
Unambiguous: This means Not having two or more possible meanings. This
means each requirement can have only one interpretation. One way of removing
the ambiguity is to use requirement specification language. This is beneficial
when detecting ambiguity using lexical syntactic analyzers. The disadvantage is
time needed for learning and understanding of the system to be built.
Verifiable: The software requirement specification must be verifiable, that it
contains all of the requirements of the user. Verifiable requirements are that the
software product must use a cost effective method. Non-verifiable requirements
are system should have good-interface and work well under most conditions.
24

How requirement are specified?

The two factors needed for requirement specification are:
1. Notation used to describe requirement
2. How the notations is to be presented to the reader of SRS document
Notations
These are the terms used for specifying the requirements. This is used
since the customer does not understand the technical language. Hence the
requirement expert must know the ability of knowledge of customer to
understand modeling. Modeling techniques include Z schema, DFD, ER diagram,
state transition diagram, and flow charts.

Benefits of Good SRS

1. Establish basis for agreement between client and supplier.
2. Reduces development cost
3. Helps in removal of inconsistencies, omissions and misunderstandings.
4. Helps in validation of final product.

Chapter-4
SOFTWARE COST ESTIMATION
Estimation of cost of the software products is an important task. There are
many factors which influence on cost of a software products development and
maintenance.
The primary cost factors are:
a) Programmer ability & familiarity of application area
25

b) Complexity of product
c) Size of the product & available time
d) Required level of reliability
e) Level of technology used
f) Familiarity & availability of technology.
1) PROGRAMMER ABILITY:
In 1968, Harold sack man conducted an experiment on colleges, to
determine influence of batch & time shared access on programmers productivity.
Twelve well experienced programmers were given with two programming
problems to solve. They have resulted that differences in individual performance
among programmers were much greater than batch.
On small projects (5 people) individual difference in ability is significant,
but for the large project that is not significant, cost is less when project involves
best programmers.
2) PRODUCT COMPLEXITY:
There are 3 categories of S/W products.
1. Application programs: Database processing or scientific programs
Usually application programs are developed using programming language
compiler such as C or PASCAL.
2. Utility programs: Compilers, linkers, loaders
Utility programs interacts with operating software management provides user
processing environment.
3. System programs: DBMS, operating systems, real-time system.
System Programs interacts directly with hardware,
Brooks states that writing utility programs is 3 times difficult than to write
application programs. System programs are 3 times difficult to write as utility
programs. Then complexity is
Application (1): utility (3): system programs (9)
Boehm, use three levels of complexity & gives equations to find programmer
months (pm) effort. In terms of thousands of delivered instructions (KDSI).
Application programs:

pm=2.4*(KDSI)**1.05
26

Utility programs:

pm=3.0*(KDSI)**1.12

System programs:

pm=3.6*(KDSI)**1.20

As the effort is more, cost will be high.

3) PRODUCT SIZE:
As the product size increases the cost will be higher. The rate of increase in
effort grows at an exponential slightly less than one, but most use exponent
ranges from 1.05 to 1.83.
4) REQUIRED LEVEL OF RELIABILITY:
Reliability defined as the program performs a required function under
stated conditions to stated period of time. Reliability is expressed in terms of
accuracy, robustness, complete & consistent of source code.
The level of reliability should be established at planning phase, by
considering cost of S/W failures.
5) LEVEL OF TECHNOLOGY:
This is the programming language, hardware & software tools used in
project development.
Use of high level languages instead of middle level languages increases the
programmer productivity. The latest/ modern programming languages such as
java includes enhanced features such as data abstraction, debugging, separate
compilation, interrupt handling & exception handling.
The

hardware

also

influence

on

programmer

productivity,

since

programmers familiarity, stability & knowledge of access with that hardware. If

new machine is found, programmer has to learn it as part of development
process.
Use of modern practices & tools in development reduces the effort.

27

COST ESTIMATION TECHNIQUES:

1. Empirical Estimation Technique:
This technique based on making cost estimation by educated guess using
project parameters & past experience.
2. Expert Judgement:
This technique is widely used. An expert makes an educated guess after
analyzing the problem thoroughly. Then estimates the different components of the
system & combine to make over-all estimate. But the expert must have experience
of that project.
This approach believes on individual as the team may have personal biases,
political considerations & influence of seniors.
3. Delphi Cost Estimation:
In this estimation is done by a group of experts & a coordinator, firstly,
coordinator provides SRS document & form for recording cost estimation to each
estimator return the form filled to coordinator anonymously. Then coordinator
displays summary of response of estimators.
The process is iterated by several rounds & there is no discussion between
estimators throughout the process.
4) Work Breakdown Structure (WBS):
This provides notations for representing major tasks to be carried out to
solve a problem.
The major activities are divided to form a tree. Where, each node is broken
down into small components as children of the node. The following fig represents
WBS of management information system (MIS) application.
MIS
Application

Requirements
Specification

Database
Part

Design

Graphical
Interface part

Coding

28
Database
Part

Test

Graphical
Interface part

Document

5) Activity Networks:
WBS representing interdependencies of various tasks, where as activity
network shows both interdependencies & also estimated duration.
Rectangular nodes represent tasks & duration shown alongside of each
task. WBS & activity networks are used for cost estimation.

6) Heuristics Techniques:
This technique uses mathematical expressions to mode the project
parameters. The heuristic estimation models divided into 3 classes,

Static single variable

Static multivariable

Dynamic multivariable model.

Static

single

variable

model

provides

mean

to

estimate

different

characteristics of a problem using previously estimated characteristic of S/W

product such as product size. This takes form,

Resource = c1 x ed1
E previously estimated characteristic of S/W.
Resource to be predicted, i.e, effort, duration, staff size, etc
c1, d1 Constants derived by past experience.
The example is COCOMO model.

COCOMO MODEL
Constructive cost Estimation model was proposed by Boehm. He postulates
three classes of products:
1) Organic products Application programs (Data processing & scientific)
2) Semi- detached Utility programs ( Compilers, Linkers)
3) Embedded System programs
Boehm introduces three forms of COCOMO:
29

1) Basic COCOMO:
Computes development effort & cost, given program size in estimated lines of
code.

2) Intermediate COCOMO:
Computes effort as function of program size & various cost drivers that relates
to product, hardware, personnel, & project attributes
3) Advanced COCOMO:
This model incorporates all intermediate model characteristics with an
assessment of cost drivers impact on each step of Software engineering
process.

COCOMO can be applied to 3 modes of the projects

a) Organic mode: these are simple, small projects developed by small teams
with good experience.
b) Semi-Detached: these are medium sized projects (in size and complexity)
developed by the team with mixed experience. This project doesnt meet the
rigid requirements of the project.
c) Embedded project: these projects should be developed within set of tight
constraints.
Ex: Flight control software.

Basic COCOMO Equation

E= ab x (KLOC) exp(bb) [Effort of person months]

D=cb x (E) exp(db) [development time in months]
Where
E - Effort applied in person months
D - Development time
30

KLOC- estimated no of lines of code

ab, cb co-efficients
bb, db components are in table.
From E & D, we can compute no of peoples required for project N, by equation, N
= N / D [People]

Software project
Organic
Semi-detached
Embedded

ab
2.4
3.0
3.8

bb
1.05
1.12
1.20

Cb
2.5
2.5
2.5

db
0.38
0.35
0.32

Intermediate COCOMO
This is an extended model with a set of cost drivers. The equation is
E= ai(LOC) exp(bi) x EAF
EAF effort adjustment Factor (range 0.9 1.4)
E- Effort applied in person months

ai, bi co-efficients in following table.

Software project
Organic
Semi-detached
Embedded

ai
3.2
3.0
2.8

bi
1.05
1.12
1.20

Table of cost drivers

COST DRIVER
RELY
DATA
CPLX
TIME
STOR
VIRT

DESCRIPTION
Required software reliability
Database size
Product complexity
Execution time constraints
Virtual machine volatility degree to which the

TURN

computer operating system change

Computer turn around time
31

ACAP
Analyst capability
AEXP
Application experience
PCAP
Programmer capability
VEXP
Virtual machine (i.e operating system) experience
LEXP
Programming language experience
MODP
Use of modern programming practices
TOOL
Use of software tools
SCED
Required development schedule.
Staffing level estimation:
Modern studied different staffing patterns of different R & D projects and
uses Raleigh curve for staffing estimation.
This is the simplest way to determine numbers of software engineers is to
divide effort estimation. This is an important since all phases of development
doesnt require constant number of engineers. If a constant number of engineers
E=K/td2 x t x exp[-t2/2td2]
used may cause some phases will be over staffed and some under staffed.
He derived an equation
Where E- effort required at time t. This is also an indication of no of engineers at
particular time.
K Area under curve.
td- Time at which curve attains max, value.

E=K/td2 x t x exp[-t2/2td2]

Effort

Td=Design Time

Td

Time

Putnam Estimation Model:

32

Putnam studied staffing problem of software projects and says that Raleigh.
Modern curve can be used to relate the number of delivered lines of code to effort
and development time.
Putnam estimation model is a dynamic multivariable model. The derives an
equation.

L= CkK1/3 ta

4/3

Where, K - effort extended

td Time to develop software
Ck State of technology constant. The typical values are ck=2, poor
development i.e no methodology, poor documentation and review, etc.,

CHAPTER-5
SOFTWARE DESIGN
This is the step of moving form problem domain towards solution domain.
Input to this stage is the SRS (Software Requirement Specification) document and
output of this stage is architecture design of system to be build.
Design is the stage in software development, which produces a model or a
representation of a system, which is used to build the system.
The design specification must be language independent and used in
implementation and testing.
Design objectives:
The major goal of this stage is to provide a best possible design, within
limitations by requirements, by social and physical environment constraints. The
criteria used to evaluate design are
1. Verifiability

a) Completeness
b) Consistency
c) Efficiency

2. Traceability

a) Simplicity / understandability

33

Software design: Design is a blueprint or a plan of the solution system,

representing components, subsystems and their interactions.
Two levels of design:
1. Top level design / conceptual design or system design :
This level focuses on identifying different modules to be developed their
specifications, connections and interactions between them
2. Logic or detailed design:
This is the internal design of models to satisfy specifications of modules.
The design may be function oriented.

Major design activities are:

1. Architectural design: identifying subsystems and their relationships which
makeup the system and documented.
2. Abstract specification: Each subsystem must be abstract and its services to
be provided.
3. Component design: Designing services and interfaces of different components
4. Data structure design: Designing detail specification of data structure to be
used in system.
5. Algorithm design: Designing algorithm used to service to be provided in the
system.

Architectural design:
The steps involved are:
a) system structuring: The system structure is decomposed into major
subsystems and each subsystem is an independent software product
b) Control modeling: The control relationship between different parts of
system is designed.
c) Modular decomposition: Decomposition of each subsystem into modules
and their interconnections.

34

There is no single design model that fits all the requirements. An

architectural model is a block diagram of the system and provides overview of the
system.
There are three standard models that are used popularly are:
1. Repository model
2. A client-server model
3. Abstract machine model

Design Concepts
The design concepts are used to reduce the complexity of design process
and also reduce the errors that are introduced in the design stage.
Partitioning:
Partitioning process focuses on defining a large problem into number of
smaller tasks. That is termed as Fine grained decomposition of a problem.
A good partitioning divides problem into smaller pieces, both computation
and data associated with the problem is called domain decomposition.
The functional decomposition is an approach of first decomposing
computation and then data.
Abstraction:
Abstraction is a tool, that designer has to consider a component at an
abstract level without worrying the implementation details of the component.
Abstraction describes external behavior of system without bothering its internal
details.
Abstraction is the most important, since at this stage the component
doesnt exist. There are two abstract mechanisms are:
1) Functional abstraction: In this a model is specified with its function it
performs. For ex: searching of an element is specified as searching
2) Data abstraction: This is a process of binding data together with the
operations that can be performed on it. This technique is helpful in

35

preventing misuse of data from external objects. This is the basis for object
oriented design.
Information hiding:
In this approach, each module in the system hides the internal details of its
processing activities and modules communicate only through well defined
interfaces.
The information hiding includes:
a. Data abstraction
b. Control abstraction ( format of control blocks, queues, stacks)
c. Character codes
d. Machine dependents details
Structure:
The general fro of system structure is network. The design represents
network as directed graph, consists of nodes and arcs. Nodes representing
processing element that transform data and arcs represents link between nodes.

Module level concepts:

A module is a logically separable part of program which is discrete unit. In
a programming language, a module is a function or a procedure. A module should
support well defined abstractions, solvable and modifiable separately.
The criteria used for modularization are:
a. Coupling
b. Cohesion
Coupling: Coupling is the strength of interconnections between modules or a
measure of interdependence among modules.
If two modules are closely connected means they are highly coupled.
Loosely coupled modules are having weak interconnections, where modules
have no inter connections are having no coupling.
Coupling increases as the complexity of interface between modules
increases.
36

Coupling is an abstract concept and it cannot be measured or formulated.

Coupling can be minimized by reducing number of interface per module &
complexity of interface.

Two components can be dependent on:

a) Reference made between components. I.e. model A invokes module B, that
means B depends on A.
b) Amount of data passed between modules, just like passing a block (array) of
data from module A to module B.
c) Amount of control that a component has on another.
d) The degree of complexity in interface between components.
In practical, it is impossible to build components with no coupling. But if
coupling is high, then other components are affected at the time of modification of
a component. Hence, a low coupling helps to minimize number of components
needing revision.

The types of coupling are:

1)

No coupling: The modules are not having interconnections.

2)

Data coupling: In this coupling, only data will be passed from one
module to another.

3)

Stamp Coupling: in this, data structure will be passed from one

component to another.

4)

Control Coupling: in this a component passed a parameter to control

the activity of another.

5)

Common Coupling: in this many modules access from a common data

store (global data). In this, it is difficult to determine which component is
responsible for change in data.

6)

Content Coupling: One component is completely dependent on another.

That is a component uses data or control information maintained within
another module.
37

Components in object-oriented design has low coupling since each object

contains functions which defines actions performed by it or on it. Thus, low
coupling is an advantage of object-oriented design.

Cohesion:
Cohesion of a module represents how tightly bound the internal elements of
the module to one another. This is an intra-module concept
There are different levels of cohesion, they are
1)

Co-incidental Cohesion: This is a condition, where there is no

meaningful relationship among the elements of the module.

2)

Logical Cohesion: In this, there is some logical relationship between

elements of the module.

3)

Temporal Cohesion: The elements in a module are executed

together. These exit in modules performing initialization, clean-up,&
termination.

4)

Procedural Cohesion: A procedurally cohesive module contains

elements that belongs to same procedural limit

5)

Communicational Cohesion: In this level, module has elements

that are related by a reference to the same input or output data. This level
module is performing more than one function.

6)

Sequential Cohesion: The elements are together in one module,

where output of one forms an input to another.

7)

Functional cohesion: This is the strongest cohesion, in which all

elements of a module are related for performing a single function.
Functions like compute square are functionally cohesive.
All models in a design must be good when it functionally cohesive and low

coupling, the number of modules obtained by the portioning must be minimized.

Because large number complexity and lead to a bad design

Design Notations

38

The representations schemes used in design are called as Design notations

. Notations used to specify the external characteristics structure and processing
details of the system, the design notations used are
1. Pseudo code
2. Structured English
3. Data flow diagram
4. Structural charts

Pseudo

code:

pseudo

code

is

like

flow

charts.

They

describe

system

characteristics using short. Concise, English language phrases that are

structured as keyword like if then-else, while, for, do etc.
Pseudo code can replace flow charts and reduce the amount of external
documentation

Structured English: This is used to provide a step by step specification for an

algorithm. This uses common English words .This is used to specify cookbook
recipes.

DATA FLOW DIAGRAMS

DFD is a tool used by system analysts to show the flow of data in an
information system. The different symbols or components for representation are
1. Process:
Process transforms a data flow by either changing its structure or by
generating new information from it.
A process must have at least one data flow into it and one data flow out of
it. A process in DFD having contains a process id, location of process and process
title

Process Id

Location of
Process

Title of the process

39

2. Data flows:
A data flows can be represented by an arrow depicts data flowing form one
process to another. The arrow head shows directions of flow and with a label as
identification.

Data Flow Name

3. Data stores:
A data store is a computer file, a manual record or a pile of documents. It
is a collection of related information a telephone book, patient records student
records.

ID

Data Store Name

Each data store is having a unique id that is a letter followed by a number

and data store name.

4. Sources and sinks (terminations or external entities)

External entities are which provide or reactive information form to the
system.
Source name

Sink name

A sink is a one which receives information form the information to the system. An
external entities are people, place, a manager a sales department

5. DFD leveling:
DFDs allows analyst or user to look a system at different levels of details.
DFD leveling is a practice where a DFD depend on its details into set of DFDs.
The DFD depend on its detail representation called as level 2 diagrams. If
necessary it is possible to design level 3 and level 4 etc for more detailed
representation.
Context diagrams (level 0 DFD):
40

A level O DFD is known as context diagram representing high level details

of the system. Context diagram comprises a process box for entire system, with
external entities and data flows between them.
A current physical DFD Is a s DFD showing data and operation within
current existing system.
Guidelines to draw context diagram:
a. Read case study from start to end, until you get a fair idea about system and
its processes.
b. Make a list of external entities.
c. Identify data flows from system and to the s/m
Level 1 DFD:
More detailed representation is shows in level 1 DFD. Level 1 DFD contains
data flows, data stores, process and external entities. The data flows are
connected to and from the actual process which create reactive or change them.
Processes are identified by number as 1,2,3,4 & so on.

Guidelines to draw level 1 DFD:

a. Make a sentence of function in system and identify verb as a process in the
system
b. Make a list of all potential process
c. Group potential

process to from 3 to 10

process A DFD must contain

minimum of 3 and maximum of 10 process

d. Identify data flows
e. Identify list of data stores
Advantages of DFD:
1. Easy to understand and validate correctness
2. Since DFD is a pictorial representation , it can be understood quickly than
textural narration
3. DFD shows an abstract specification of system. It only shows what system
will do? Rather than how it can be done?
41

Structured Charts:
This is used in functional oriented design. The structure of a program is
made up of modules and their interconnections.
A structured chart is a graphical representation of structure of a problem.
In this module is represented by a box, with its name. The flow of data
parameters are represented by arrows. The parameters can be shown as data by
unfilled circle of the arrow.
The invoking (calling) function is called superiordinates and called
function is called subordinate
Main

a, n
Read nums

Sum

Sort

Add - n

x, y

x, y
Swap()

There may be situations, where designer wish to communicate procedural

information explicitly like loops and decisions, there are represented as follows

Iteration

Decision

Design techniques
42

Several techniques have been developed for software design include

1. Step wise refinement
2. levels of abstraction
3. Structured design
4. Integrated Top-down development
5. Jackson method
The design techniques are called as Design methodologies Design
methodology is based on top-down bottom up approach used in design. In Topdown approach a system is decomposed into subsystems and importance is given
to specific tasks. In top down approach lowest level ( elementary) modules are
specified

first , the primary advantages of this strategy is more attention

is

towards customers needs , users interfaces.

In bottom up strategy designer identifiers a set of primitive objectives ,
actions and relationships that provides

basis for problem solution , high level

concepts ate then formulated in terms of primitives The success of bottom up

design depends on identifying the proper set of primitives ideas.

1. Stepwise refinement:
This is a top-down technique for decomposing a system from highlevel
specifications into more elementary levels. This is also called as stepwise
program development and successive refinement. This is originally descried by
WIRTH (WIR71).
This technique involves following activities:
1. Decomposing design decisions to elementary levels
2. Isolated design aspects that are not truly interdependent
3. Demonstrating each step as an explosion of previous step.
4. postponing design decisions
In each step postponing design decisions as long as possible provides
designer to build consistent design. The input to this technique is software
requirement specification and external deign. The problem is decomposed into few

43

major processing steps and process is repeated until each part of system contains
sufficient detail can be executed in programming language straightly.

This technique uses structured charts and pseudo code for representation,
pseudo code is consists as refinement proceed.
This technique makes problem into small, manageable pieces with
sufficient amount of detail, which can be learned at a particular time is
minimized. Hence designer makes proper time to proper concerns of the problem..
The success of this technique is purely depend upon understanding of the
problem and ability of design

2. Levels of Abstraction :
Described by dijkstra as for bottomup approach of design, he considers an
operating system design of layers (levels).
Each level of abstraction includes group of functions some functions are
externally visible i.e. invoked by function on higher levels of abstraction, some fins
are internal which can be invoked only by functions of the same level. Internal
functions are hidden to other levels.
The functions of higher level cannot be used by functions at lower level.
Thus function usage makes levels of abstraction.
Each level performs set of services to functions at next higher level. each
level uses certain resources such as Input / output devices , data structures ,
which are not permitted to access by other level .
Levels of abstraction in T.H.E operating system
Level 0

processor allocation, clock and interrupt handling

Level 1

Memory segment controller

Level 2

Console Message interpreter

Level 3

I/O Buffering

Level 4

User programs

Level 5

Operator

3. Structured design Methodology:

44

This methodology though that overall activities is to identify the input and
output and the primary transformation by the software system. The primary
attention is given on the transformation process function. The goal of SDM is to
reduce coupling between models and enhance in different models. The
documentation tool used is structured charts.
The following are the major steps are:
1. Restate problem as DFD
2. identify input and output
3. first level factoring
4. factoring of input , output and transform branches

1. Restate problem as DFD:

A DFD is constructed as first step of SDM in this major transformation are
shown in picture.
2. Identify most abstract and output:
The software system transformation cannot be applied on actual physical
input to produce desired output. Instead input is first converted into a form which
can be transformed to desired output easily. In the similarly manner,
transformation modules produce, output that to be converted that to desired
physical output. The goal of the second step is to separate transformation in DFD,
which convert input or output to desired from the one that perform actual
transformation. Thus identify most abstract input or output, which are removed
from physical input or output in the system.
3. First level factoring:
Identifying the central transformation and most abstract input and output
data is done in second step then identify main modules to invoke its
subordinates. Then

most specified

finally central transform

a subordinate

module to main one is specified , which are transformation modules , whose

function is to accept data from main module and return appropriate data back to
main module,
4. Factoring input output and transforms branches:
45

First level factoring is high level structure where subordinate module has
to do more than it look , hence in this stage , in more detail the input output
and central transformation is described. This step is nothing but more detailed
representation of factoring.

Object oriented design

This design identifies objectives in a system, which s are packed with
information and relationships and interactions between objectives.
The advantages of OOD is modifiability, reusability and avoidance of misuse
Components of OOD:
1. class and objects from basic building blocks
2. Encapsulation of data with its implementation prevents external misuse of
data.
3. Class defines set of objects share common projects and operations . Data
declaration limits its access to others ( such as public or private)
4. interfaces defines how a part of an object can s be accessed
5. method of a class defines operations that can be performed on object
6. Message passing is used between objects to invoke service of an object, The
invoking object (server) sends message to object (called client) to invoke its
service.

46

CHAPTER-6
CODING
This is the phase where you can see actual development of software
product. Coding is the phase where design is translated into some programming
language instructions. The goal of this phase is to reduce the work of tester and
maintainer. The programs constructed must be easy to write, read and
understand. The criterias used to judge a program as good are
1. readability
2. Program size
3. execution time
4. Required memory
The primary goals of coding are understandability and modifiability.
Structured coding technique
This technique is told as go-to less programming. The program has a
static structure I as well as dynamic. Static structure is the structure of the text
of program. Which is a liner organization of statements of program are executed
during execution. if the statements are linear then it is helpful in verification .
The program must have single exit and single entry.
Data encapsulation:
This involves the process of packaging of data structures and its access
routines in a single module. The data structure can only be accessed by access
routines. Routines are not known about the details of data structure. Thus forms
an abstract data type (objectives) an abstract data type is a user defined template
47

that can be used to create numerous instances of encapsulated data objects.

Data abstract describes design principle of both data encapsulation and abstract
data type.
Recursion:
Recursion means process of calling itself as small problems of it. Recursion
program are easy to understand and lowering complexity. Hence recursion serves
clarify and efficiency, if it is used appropriately.

Coding Style
The

coding

style

enhances

the

readability

maintainability

and

understandability of the program significantly. Thorough knowledge of syntax of

programming language is to be used in writing a good program some guidance
to write a good program are given below
1.

Names: The module and variable names used must be appropriate to its
function that it performs the length names usage is not a good practice. The
names should be short, precise and closely reflect their activity. The
appropriate names helps in the referencing

2.

Control constructs: Single entry and single exit control statement must
be used fewer standard constructs must be used is desirable rather than
using a verify of control constructs , more control constructs may decrease
program understandability .

3.

Gotos: Gotos in the program must be used in a disciplined manner. In

COBOL, FORTRAN Gotos usage is common .An alternative can be used (loop)
rather than Gotos.

4. Information hiding: Information hiding must be done where it is possible to

the data only access functions has to be made.
5. User defined types: Modern languages allows to define types , that should
be used wherever possible when working with dates, you can defined types

48

6. Nesting: Control constructs can be nested, but the nesting should not be
deep, which decease understandability of program. Hence deep nesting
must be avoided , which leads to different to understand
7. Module size: less size models (less than 5 statements) will be unnecessary,
since compiler has to perform more actions when accessing a module and a
large size module will be less functionally cohesive.
8. Module interface: A module having complex interface must be examined.
Simple interface must be used. The parameters should not be more than 5 ,
since there may be difficulty in understanding
9. Program Layout: The program must be organized and presented well to
increase readability. proper indentation , blank spaces and program
automated tools it is a good practice to make clear layout of program
10. Side effects: A module function should not modify other module data or
function; the global data should be handled carefully by the modules. if a
module has side effects it should be documented ,

Internal documentation:
Internal documentation i.e. some statements about particular data or
function written in the program should be used to make better understandability.
Comments are statement used for this purpose in the program, which are not
executed but held within the program
Comments of module as called prologue of the module.

Verification:
This is the process of detecting errors introduced during coding. The goal is
to show the consistency of the code with the design.

The verification methods are in two categories:

1) Static Method: In this method, program is not executed or compiled. This is
a conceptual execution & manual. This involves verification, code reading,
49

code reviews, walk, though & symbolic execution, this is an economical

method.
2) Dynamic Method: In this method, actual program is executed with some
test data & outputs are tested for presence of errors. The overall program will
not be tested for errors.

Code Reading:
This is a process of careful reading the program by programmer to detect
any errors/ inconsistencies between design specification & implementation.
This also checks for abstraction of a module with design specification. This
is a process starting from inner-most structure towards abstract; specification of
a module code reading is useful, economical & can detect errors which are not
detected at testing.

Static Analysis:
Analysis of program by analyzing program text is called static analysis.
Some tools are used mechanically to detect errors. The program is not executed,
but program test is an input to the tools.
The aim of this analysis is to detect errors, potential errors (logical errors)
or generate information about structure of program for better documentation &
understanding the program.
Static analysis is very cost-effective. & determine violation of standard
programming standards. This process can reduce the effort of testing.
This also finds data flow anomalies, which is not detected by compiler.
Data flow anomalies are caused by carelessness in typing, error in coding. An
example for data flow anomalies is a variable is assigned a value but not used in
program later. Other examples are unreachable code, unused variables &
unreferenced labels. These are not technical errors but may cause inefficient
programs.

Code reviews:
50

Code review is done after code writing is completed, compile & passed out
of static analysis to detect errors.
The review is team includes programmer, designer & tester. The aim of
review is to detect errors that fail to implement design. This may be due to usage
of different module, interface that is not specified in the design.

The code defects are classified into two categories:

1. Logic and control errors : Such as infinite lops

unreachable code ,

missing or unreferenced labels and improper use of nesting

2. Data

operations

computations

and

computations

incorrect

access

of

errors:
array

Includes

components

defects
,

improper

initialization and misuse of variables

CHAPTER-7
Testing and Maintenance

The software testing involves verification and validation techniques.

Verification & validation techniques
51

in

The verification and validation techniques are used to access and improve
quality of products this also checks for quality attributes such as correctness,
completeness, reliability, usefulness, efficiency, standards and over all cost
effectiveness.

Two types of verification

1. life-cycle verification : This process determines degree to which products
at a given of cycle fulfill specification the prior phases
2. Formal verification: This is a rigorous mathematical demonstration that
source code conforms to its specifications.
Validation is the process of evaluation of software at the end of development
process to determine compliance with requirements
Boehm phrases to differentiate verification and validation as
Verification

: Are we building products right?

Validation : are we building right product?

Verification and validation assess work products to its conformance of

specifications,
documentation

specifications
implementation

include

requirement

language

standards,

specification,
project

design

standards,

organizational standards user expectations and notations used in product

specifications.
Requirements are examined for conformance of user needs, environmental
constraints and notations.
Design documentation is examined with respect to requirements and
notational conventions.
Supporting documents such as users manual, test plan must be examined
for correctness, completeness.

The errors may be caused are

52

1. Requirement errors: This may be caused by incorrect specification of user

needs or incomplete specification.
2. Design errors: these are caused due to failure to translate requirement to
correct , complete design this cannot be find out until source code is tested
, this is most costlier to correct errors .
3. Implementation errors: Errors caused during translating design to code.
This can be unreferenced data, incorrect input / output, in control flow
logic in module interfaces.
The quality of work products can be assessed and improved by using
systematic quality assurance procedures by walkthroughs and inspections.
The techniques used are:
1. Software quality assurance procedures
2. walkthroughs and s inspections
3. unit testing
4. integration testing
Software quality assurance (SQA):
SQA is a planned and systematic pattern of action taken to ensure quality
in software SQA involves reviewing and auditing the software products and
activities to verify compliance with procedures and standards.
SQA group works also s during early stages in planning establishing
standards and procedures, hence participation of SQA team helps them to verify
needs and ensure the quality. The team reviews and audits throughout the life
cycle and provide visibility of adherence of plans, standards and procedures to
management.
Goals:

Adherence of product and activities to established plans standards and

requirements are verified

Affected groups and individuals are informed of software quality assurance

activities and results

53

Non-compliance issues that cannot be resolved are addressed to senior

management

Activities Performed
1. SQA plan is prepared according to document procedure at project planning
2. Activities performed as per plan
a. Responsibilities and authorities of SQA group
b. Staff , tools and facilities requirements of SQA group
c. Schedule and fund of SQA group activities
d. SQA group participation in planning , standards
e. its and reviews performed by SQA group
f. procedures to be used for documentation
g. Documentation to be produced by SQA group
3. Participation of group in preparation and review of plan standards and
procedures
4. verification of compliance of product by reviewing

evaluation of deliverable product before delivery

Corrections are verified

Deviations are identified , documented

5. Reporting the results of activities to software engineering group

Walking through and Inspections:

Walkthrough and inspections are used to systematically examine the
products through the cycle, the requirements, design specifications, test plans
source code, and principles of operation users manual and maintenance
procedure are examined.
A walk through is not a project review, but an in depth examinations of
work product by individuals who are experts and give opinions.
54

Inspection comprises a team of trained inspectors work from check list of

item to be examined and perform inspections of work products.
Walk through session held in open environment the goal of walk through is
to discover and document problem areas. Problems are not resolved by reviewee
following sessions. A review may work with one or more reviews to resolves the
problem.
Memos and meetings are issued to reviews for information of actions taken.
But solving the problem is the responsibility of reviews.

Guidelines for successful walkthroughs:

1. Every work is to be reviewed on scheduled basis
2. Emphasis on detecting errors, but resolving problem is not to be in
walkthrough session
3. walkthrough must take detailed discussion of minor and major problem ]
4. Walkthrough session must be limited to 2 hours
Inspection team consists of 1 -4 members who are trained to their tasks ,
Inspectors pick

items from check list for inspection and each

participant

of

team has a definite role to play

According to Fagan an inspection team consists of four persons, moderator,
designer, implementer and tester. Inspected items are completeness of design with
respect to requirements, correctness of inter faces controls, data, referencing
computational expressions.
Input / Output statements and memory usage
The interesting fact is error found is given to correct by programmer who
made and with this feedback they eliminate similar errors from their subsequent
works this improves quality and productivity
Fagan says a moderator in team is rather than review, directs effort and
gives detailed error feed back to the individual programmers
Software Testing:
Testing is the process of executing the program to find errors in the code.
55

Objective of testing is to find errors (incorrectness) and testing is successful

when an error is detected and error may be at design or programmers work.
Testing should not be a separate phase, but it should be through all phase
of cycle
Unit testing:
Unit testing is the analysis of individual units to check whether they meet
requirement specification or not.
A unit can be a module which is a subtask of the program. A unit tested
using inputs structural testing is also called white box or Glass box testing.
The programming faults are identified using static and dynamic analysis.
Structure faults are found out by dynamic analysis.

Debugging:
Debugging is the process of isolating and correcting causes of known
errors. Debugging methods include induction, deduction and backtracking.
Backtracking involves moving back from where error is observed, to the
actual error caused point.
Traditional debugging techniques are diagnostic output statements, snapshot dumps, selective traces on data values and control flow and instruction
breakpoints.
Integration testing:
Integration or subsystem testing is concerned with verifying design and
requirements. Units are integrated by a pre-defined strategy such as bottom-up or
top-down strategy.
The growing system and interfaces are checked for compatibility. i.e.,
function parameters tested for order and type.
System and acceptance testing:

56

System and acceptance testing concerns with the execution of test cases to
evaluate whole system with respect to requirements of user.
An acceptance testing is the process of executing test cases agreed with
customers as adequate representation of user requirements. This is called as
Black Box Testing.
Functional testing:
Functional testing is a black-box technique to verify functions are written
correctly and perform required operation.

Software Maintenance
Maintenance costs more than the budget of overall development process.
Somerville states that maintenance costs in between 1 and 4 times of
development costs.
Software maintenance is the process of changing a system after it has been
delivered to client and is in use.
The process begins with problem report or a modification request by users.
Thus, software maintenance can be defined as Process of changing of a system to
maintain its ability to survive.
Three types (categories) of software maintenance are:

1. Corrective maintenance:
This process is concerned with fixing reported errors in the software. Where
coding errors are cheaper to correct and design errors are expensive as new
programs to be written. Requirement errors are most expensive since system has
to be redesigned from the beginning.
2. Adaptive maintenance:
This concern with the process of changing software to new environment
such as different hardware platform or operating system.
3. Perfective maintenance:
This process involves implementing new features on customer demands.
57

Maintenance can be long phase may be up to life time of the product.

Maintenance is successful, if all the documents of development process (design
and coding) exist, because it is difficult to:

Trace changes in code in various version

Read someone elses code

Change code without knowledge of design.

Hence, maintenance is costlier than developing a new product.

58