India’s Mega Online Education Hub for Class 9-12 Students,

Engineers, Managers, Lawyers and Doctors.

Free Resources for Free Resources for Free Resources for Free Resources for Free Resources for
Class 9-12 Students Engineering Students MBA/BBA Students LLB/LLM Students MBBS/BDS Students

• Lecture Notes • Lecture Notes • Lecture Notes • Lecture Notes • Lecture Notes

• Project Reports • Project Reports • Project Reports • Project Reports • Project Reports

• Solved Papers • Solved Papers • Solved Papers • Solved Papers • Solved Papers

View More » View More » View More » View More » View More »

▼▼ Scroll Down to View your Downloaded File! ▼▼

Disclaimer

Please note none of the content or study material in this document or content in this file is prepared or
owned by Studynama.com. This content is shared by our student partners and we do not hold any
copyright on this content.

Please let us know if the content in this file infringes any of your copyright by writing to us at:
info@studynama.com and we will take appropriate action.
 UNIT – I

Topic: - Introduction to Software Engineering

Unit-01/Lecture-01
Software Engineering : [ RGPV/JUNE-2013(7), JUNE 2011(10)]

Practical application of scientific knowledge in the design and construction of computer

programs and the associated documentation required to develop, operate, and maintain
them.
The study of systematic and effective processes and technologies for supporting software
development and maintenance activities
–  Improve quality
–  Reduce costs
Software product may be m
o
1. Custom- developed for a single customer according to their specifications.

.c
2. Generic- developed to be sold to a range of different customers.

a
Software Characteristics

m
While developing any kind of software product, the first question in any developer s mind
is, What are the qualities that good software should have? Well before going into

a
technical characteristics, I would like to state the obvious expectations one has from any

n
software. First and foremost, a software product must meet all the requirements of the
customer or end-user. Also, the cost of developing and maintaining the software should

y
be low. The development of software should be completed in the specified time-frame.

d
Well these were the obvious things which are expected from any project (and software

u
development is a project in itself). Now let s take a look at Software Quality factors. These

t
set of factors can be easily explained by Software Quality Triangle. The three
characteristics of good application software are :-
S
1) Operational Characteristics
2) Transition Characteristics
3) Revision Characteristics
 m
o
.c
What Operational Characteristics should a software have ?
These are functionality based factors and related to exterior quality of software. Various
Operational Characteristics of software are :
a
m
a) Correctness: The software which we are making should meet all the specifications

a
stated by the customer.
b) Usability/Learn ability: The amount of efforts or time required to learn how to use the

n
software should be less. This makes the software user-friendly even for IT-illiterate

y
people.
c) Integrity: Just like medicines have side-effects, in the same way a software may have a

d
side-effect i.e. it may affect the working of another application. But a quality software
should not have side effects.
u
d) Reliability: The software product should not have any defects. Not only this, it

t
shouldn t fail while execution.

S
e) Efficiency: This characteristic relates to the way software uses the available resources.
The software should make effective use of the storage space and execute command as
per desired timing requirements.
f) Security: With the increase in security threats nowadays, this factor is gaining
importance. The software shouldn t have ill effects on data / hardware. Proper measures
should be taken to keep data secure from external threats.
g) Safety: The software should not be hazardous to the environment/life.

What are the Revision Characteristics of software?

These engineering based factors of relate to interior quality of the software like
efficiency, documentation and structure. These factors should be in-build in any good
software. Various Revision Characteristics of software are :-
Studynama.com - #1 destination for free notes, eBooks, papers & projects.
Choose your course/study level below and start downloading:

CLASSES 6-10 CLASSES 11-12

 Class 6 CBSE NCERT Notes, Solutions
 Class 7 CBSE NCERT Notes, Solutions
 Class 8 CBSE NCERT Notes, Solutions
 Class 6, 7, 8 CBSE NCERT Projects
 Class 9 Notes, eBook CBSE PDF Download
 Class 10 Notes, eBooks CBSE
 Class 9 & 10 Projects, PPTs PDF Free
 Class 9, 10 Solved Board Papers
 Class 11 Science & Medical Notes, eBooks
 Class 12 Science & Medical Notes, eBooks
 Class 11/12 Science & Medical Projects
 Class 11/12 Science & Medical Solved Papers
 Class 11 Commerce Notes, PDF eBooks
 Class 12 Commerce Notes, PDF eBooks
 Class 11 Arts Notes, eBooks Free
 Class 12 Arts Notes, eBooks Free

ENGINEERING – BE / BTECH. STUDY MATERIAL

 First Year Engineering Notes, Projects
 Computer Sc. Engineering Notes, Projects
 Electronics Engineering Notes, Projects
 Electrical/EEE Engineering Notes, Projects
 Mechanical Engineering Notes, Projects
 Civil Engineering Notes, eBooks, Projects
 Production Engineering Notes, Projects
 Chemical Engineering Notes, Projects
 Aerospace Engineering Notes, Projects
 Metallurgical Engineering Notes, Projects
 CSE/IT Engineering Projects, Reports
 Electronics Engineering Projects, Reports
 Electrical/EE Engineering Projects, Reports
 Mechanical Engineering Projects, Reports
 Civil Engineering (CE) Projects, Reports

BBA / BBM MBA / PGDM

 BBA/BBM CORE Notes, Books, eBooks
 BBA/BBM Marketing Notes, Books, eBooks
 BBA/BBM Finance Notes, Books, eBooks
 BBA/BBM HR Notes, Books, eBooks
 BBA/BBM Operations Notes, Books, eBooks
 BBA & BBM Projects, Training Report
 MBA Core/General Notes, eBooks, Projects
 MBA Marketing Notes, eBooks, Projects
 MBA Finance Notes, eBooks, Projects, Reports
 MBA HR Notes, eBooks, Projects, Reports
 MBA Operations Notes, eBooks, Projects

SCROLL DOWN TO SEE SUBJECT NOTES

a) Maintainability: Maintenance of the software should be easy for any kind of user.
b) Flexibility: Changes in the software should be easy to make.
c) Extensibility: It should be easy to increase the functions performed by it.
d) Scalability: It should be very easy to upgrade it for more work(or for more number of
users).
e) Testability: Testing the software should be easy.
f) Modularity: Any software is said to made of units and modules which are independent
of each other. These modules are then integrated to make the final software. If the
software is divided into separate independent parts that can be modified, tested
separately, it has high modularity.

Transition Characteristics of the software :

a) Interoperability: Interoperability is the ability of software to exchange information with

m
other applications and make use of information transparently.
b) Reusability: If we are able to use the software code with some modifications for
different purpose then we call software to be reusable.
o
.c
c) Portability: The ability of software to perform same functions across all environments
and platforms, demonstrate its portability.

a
Importance of any of these factors varies from application to application. In systems

m
where human life is at stake, integrity and reliability factors must be given prime
importance. In any business related application usability and maintainability are key

a
factors to be considered. Always remember in Software Engineering, quality of software is

n
everything, therefore try to deliver a product which has all these characteristics and
qualities.

y
d
Software Crisis:
A software crisis is a mismatch between what software can deliver and the capacities of

u
computer systems, as well as expectations of their users. This became a growing problem

t
in the 20th century as computing grew by leaps and bounds and software was unable to
keep pace. As the complexity of systems grows, so do the needs of users, who expect
S
increasingly more performance from their software. Programmers may struggle to keep
pace, creating a software crisis.

Consumer software typically moves through a slow series of development phases, but
makes up a small portion of the volume of business in the industry. The bulk of software
development is sunk into systems for specific applications, ranging from the programs
that handle missile guidance aboard naval cruisers to internal record-keeping for health
insurance companies. This software generally requires a substantial investment from the
customer, as well as extensive programming from personnel charged with developing,
testing, and maintaining it.
Studynama.com - #1 destination for free notes, eBooks, papers & projects.
Choose your course/study level below and start downloading:

LLB / LAW MEDICAL

 LLB Notes, eBooks FREE PDF Download  MBBS Notes, eBook, Project, Papers & Cases
 LLB Law First Year PDF Notes, Projects, Papers  BDS Notes, eBook, Project, Papers & Cases
 LLB Law 2nd Year PDF Notes, Projects, Papers  BHMS Notes, eBook, Project, Papers & Cases
 LLB Law 3rd Year PDF Notes, Projects, Papers  BPharma Notes, Projects, Papers & Cases

B.COM ENGINEERING / GATE ENTRANCE

 B.Com. General Notes, eBooks PDF Download
 B.Com. Honours (Hons.) Notes, eBooks
 B.Com. Finance Notes, eBooks PDF Download
 B.Com. Human Resources Notes, eBooks PDF
 B.Com. IT Notes, eBooks PDF Download
 B.Com. Accounting & Taxation Notes, eBooks
 B.Com. Marketing Notes, eBooks PDF Download
 B.Com. BFSI Notes, eBooks PDF Download
 IIT-JEE Mains 2019 Solved Papers, Notes, Cutoffs
 IITJEE Advanced 2019: Solved Papers, Notes
 BITSAT 2019 - Solved Papers, Notes, Cutoffs
 VITEEE/SRMEEE/MU-OET 2019: Papers, Notes
 UPTU/AKTU 2019 - Solved Papers, Notes, Cutoffs
 WBJEE 2019 - Solved Papers, Notes, Cutoffs
 MH-CET 2019: Solved Papers, Notes, Cutoffs
 EAMCET, COMEDK 2019: Solved Papers, Notes

BCA / MCA / B.SC. MEDICAL ENTRANCE

 BCA Notes, eBooks Download
 BCA Project Reports & PPTs
 MCA Notes, eBooks Download
 B.Sc. Notes, eBooks Download
 B.Sc.(IT) Notes, eBooks, Papers, Projects
 AIIMS Medical 2019 - Solved Papers, Notes
 NEET (AIPMT) 2019: Solved Papers, Notes
 AIPVT Medical 2019: Solved Papers, Notes
 AFMC Medical 2019: Solved Papers, Notes
 BHU-PMT, CMC Vellore 2019: Papers, Notes

GATE – ENTRANCE FOR MTECH & PSU

 GATE CSE/IT engineering Notes & Papers  GATE Electronics engineering Notes & Papers
 GATE Mechanical engineering Notes & Papers  GATE Civil Engg. Free PDF Notes & papers

SCROLL DOWN TO SEE SUBJECT NOTES

Such projects can run into a software crisis where they start to go over budget and take
much longer than expected to develop. The programmers working on the software may
have to deal with ongoing bug fixes while learning new aspects of a system, making
adjustments for the client, and addressing other issues that arise. Low quality can be a
concern, as the programmers may experience increasing pressure to meet budgets at all
costs, even if it means the software won t be of good quality. Less documentation tends
to be produced as well.

This is not just an issue for the development of new software products. Another concern
can be the need to maintain older software which may have problems related to poor
development or the failure to anticipate growing needs. Programmers could be spending
large amounts of time on keeping legacy software functional so a company can continue
to operate. With high investment in the older software, the company may be reluctant to
order a new program, even if it would better meet their needs, because this could involve

m
more expense and problems during the changeover.

o
Pressure to produce complex, advanced code can be a significant contributor to a

.c
software crisis. It can be difficult to control the pressure while keeping costs under control
and staying on a time table. Some measures for dealing with a software crisis can include

a
substantial advanced planning, selection of highly qualified personnel, and ongoing
updates to make sure the project stays on task and on focus.

Traditional Software Engineering m

a
One of the main events in the software industry at the beginning of the new century is

n
the appearance of the agile methodologies for software development. Most of the
companies today are using these methodologies to manage their projects. They radically

y
changed the landscape of the development methods.

d
The agile methods are based on a set of new principals of design and build – different

u
from the principals used before. However to understand the agile methodologies first of

t
all we need to understand the reason of their appearance. Thus we ve to first understand
the traditional methods of software development – their features, their pros and cons,
S
and nevertheless we ve to understand their relevance.

Features of the Traditional Methods

The so called traditional approaches, also known as engineering approaches, are
defined at the very beginning of the software sciences. Of course the software
development process needs to be controlled somehow. To do so the software engineers
came along with the well known engineering methods of controlling the processes. These
methods are applying a disciplined approach where the stages of design and build are
well predictable. Detailed stages of analysis and design precede the stage of building the
software.
These methodologies are well documented and thus are quite complex to apply. Of
course this is the main reason when we talk about their disadvantages. One of the main
disadvantages is that these traditional methodologies are very bureaucratic. In practice
the high level of detail in a methodology leads to a high level of complexity. Actually the
work of managing the methodology itself is more than the work on the software product.

Traditional software engineering, CMMI and its problems

Well into the 1980s the largest buyer of software development services in the world, the
US Department of Defense, was having trouble getting projects done on time, on budget
and with the right specifications. Despite working with some of the best and most
renowned software development companies out there, it still had close to a 50 / 50
chance of getting a project right. Worried about its performance, it set up to fund,
together with Carnegie Mellon University, the Software Engineering Institute. This
institute was tasked with compiling a set of software development best practices that

m
could provide both a benchmark aginst which to measure current vendors, as well as
concrete guidelines current vendors should follow to improve their software engineering
o
practices. The initiative ultimately gave birth to the Capability Maturity Model Integration

.c
(CMMI) and its levels of 1 to 5.

a
The Capability Maturity Model ranks companies into levels, going from those that are at
Level 1 (operating under processes that are not managed, or ad-hoc) to those that reach

m
Level 5 (optimizing). It is not our purpose here to go into detail about what each level
means, except to point out that at Level 5 companies must have complied with following

a
the tenets of more than 16 software and systems development process areas, including

n
the ability to (at level 2) manage their software development process (configuration
management, project monitoring and control, project planning, requirements

y
management); define their approach to software development (decision analysis and

d
resolution, organizational training, risk management, validation,
verification); quantitatively manage their development process (measure organizational

u
process performance, reliably measure productivity, error injection and other key

t
variables) and optimize their process, which involves constantly reviewing the causes of
process problems and taking measures to improve and resolve them.
S
The nature of the DoD s needs influenced CMMI at the core. The DoD s software
development projects tend to be large and often interact with hardware. Furthermore,
they are government funded, which requires measures of financial transparency that
limit budget flexibility, often requiring projects to provide a fixed cost. Thus, it is not
surprising to see a CMMI model that was slanted towards traditional RUP (the Rational
Unified Process) methodologies, especially in what regards to:

1. Big Requirements Up Front (BRUF). BRUF is necessary to adopt so-called formal

estimation techniques (such as COCOMO I/II, Function Points, Feature Points, etc.)
that allow a software development team to have a shot at estimating, in advance,
the effort required –and hence the cost—of a project;
 2. High formality and preciseness in the way requirements are elicited and
documented. Under strict RUP or even under a more archaic waterfall
approach , requirement engineering is a ceremonious process that documents, in
writing, use cases (i.e. using UML diagrams, for example), functional and non-
functional requirements, process flows, mock-up screens, etc.
It is not surprising that under RUP (or also under a traditional waterfall approach),
the inception and elaboration stages take 40 to 50% of the total time spent in
the software development project.

3. Testing after the fact , i.e. after code has been written. This is clearly a quality
control, but often leads to detecting errors late, when correcting them is more
expensive.

m
4. Strict controls to requirement changes . Processes for changing requirements are
o
often so heavy and difficult, they seem to be designed more to prevent change

.c
than to manage change within a software development.

a
In essence, the software development methodologies proclaimed to be best-practices

m
under CMMI and RUP, did produce significant gains in the quality of the code. However,
this came at a significant price both in terms of:

 a
n
Time (time was more predictable but the formality significantly increased the
length of the software development vs. ad-hoc programming);

 y
d
Functional relevance (a rigid process did not allow applications to easily adapt to
changes in the business environment, so the ensuing application often was what

u
the client asked for but not really what the client needed ;

t

S
Frustration with cost (the ensuing application was not cheap to make, due to the
administrative overhead of all the formality of the process, and the predicted cost
of the application still did not match the initial fixed price estimate –yes,
estimates where off by a lesser amount vs. ad-hoc estimations, but they were still
significantly off.
S.NO RGPV QUESTIONS Year Marks
Q.1 Discuss the major differences between software JUNE 7
engineering & some other engineering. Discipline, such as 2013
bridge design or house building. Would you consider state
of art software engineering as a true engineering
discipline?
Q.2 What is prime objective of software engineering? Define JUNE 10
software engineering paradigm. 2011
Q.3 Give the importance of software engineering. Define JUNE 10
software process. State the important features of a 2011
process

m
o
.c
a
m
a
n
y
d
u
t
S
 UNIT – I

Topic:-Object Oriented Software Engineering, Layered Technology

Unit-01/Lecture-02
Object Oriented Software Engineering
Object-oriented software engineering (commonly known by acronym OOSE) is an object
modelling language and methodology.
OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first object-
oriented design methodology to employ use cases to drive software design. It also uses
other design products similar to those used by Object-modelling technique.
It was documented in the 1992 book Object-Oriented Software Engineering: A Use Case

m
Driven Approach, ISBN 0-201-54435-0
The tool Objectory was created by the team at Objectory AB to implement the OOSE

o
methodology. After success in the marketplace, other tool vendors also supported OOSE.

.c
After Rational Software bought Objectory AB, the OOSE notation, methodology, and tools
became superseded.
 As one of the primary sources of the Unified Modelling Language (UML), concepts

a
and notation from OOSE have been incorporated into UML.
 The methodology part of OOSE has since evolved into the Rational Unified
Process (RUP).
m
a
 The OOSE tools have been replaced by tools supporting UML and RUP.
 OOSE has been largely replaced by the UML notation and by the RUP
methodology.
n
y
Software Engineering: Layered Technology-:-[ RGPV/JUNE-2013(7) ]
d
u
Software Development is a Layered Technology: Software development is totally a

t
layered technology. That means, to develop software one will have to go from one layer
to another. The layers are related and each layer demands the fulfillment of the previous

S
layer. Figure below is the upward flowchart of the layers of software development.
1. A Quality Focus : Software engineering must rest on an organizational commitment to
quality. Total quality management and similar philosophies foster a continuous process
improvement culture, and this culture ultimately leads to the development of increasingly

m
more mature approaches to software engineering. The bedrock that supports software
engineering is a quality focus.
o
.c
2. Process: The foundation for software engineering is the process layer. Process defines a
framework for a set of Key Process Areas (KPAs) that must be established for effective

a
delivery of software engineering technology. This establishes the context in which
technical methods are applied, work products such as models, documents, data, reports,

m
forms, etc. are produced, milestones are established, quality is ensured, and change is
properly managed.

a
n
3. Methods: Software engineering methods provide the technical how-to's for building
software. Methods will include requirements analysis, design, program construction,

y
testing, and support. This relies on a set of basic principles that govern each area of the

d
technology and include modeling activities and other descriptive techniques.

u
3.Tools: Software engineering tools provide automated or semi-automated support for

t
the process and the methods. When tools are integrated so that information created by
one tool can be used by another, a system for the support of software development,
S
called computer-aided software engineering, is established.

Goals of Software Engineering:

• Need to understand requirements.
• Want software with maximum functionality.
• Code must be reliable.
• Cost to develop and maintain important.
• Want results as fast as possible.
• Must minimize development risks.

Software Process Framework:

Software Process: Process defines a framework for a set of Key Process Areas (KPAs) that
must be established for effective delivery of software engineering technology. This
establishes the context in which technical methods are applied, work products such as
models, documents, data, reports, forms, etc. are produced, milestones are established,
quality is ensured, and change is properly managed.

Software Process Framework: A process framework establishes the foundation for a

complete software process by identifying a small number of framework activities that are
applicable to all software projects, regardless of size or complexity. It also includes a set of
umbrella activities that are applicable across the entire software process. Some most
applicable framework activities are described below.

m
o
.c
a
m
a
n
y
d
u
Communication: This activity involves heavy communication with customers and other

t
stakeholders in order to gather requirements and other related activities.

S
Planning: Here a plan to be followed will be created which will describe the technical
tasks to be conducted, risks, required resources, work schedule etc.

Modeling: A model will be created to better understand the requirements and design to
achieve these requirements.

Construction: Here the code will be generated and tested.

Deployment: Here, a complete or partially complete version of the software is

represented to the customers to evaluate and they give feedbacks based on the
evaluation.
These above described five activities can be used in any kind of software development.
The details of the software development process may become a little different, but the
framework activities remain the same.

S.NO RGPV QUESTIONS Year Marks

Q.1 What do you understand by a layered software design? JUNE 7
What are the advantages of a layered design? Explain 2013
your answer by using suitable examples.

m
o
.c
a
m
a
n
y
d
u
t
S
 UNIT – I
Topic:-CBSE, Software Development Process

Unit-01/Lecture-03
Component Based Software Engineering[ RGPV/ JUNE-2014,2013(7) ]
Component-based software engineering (CBSE) (also known as component-based
development (CBD)) is a branch of software that emphasizes the separation of concerns in
respect of the wide-ranging functionality available throughout a given software system. It
is a reuse-based approach to defining, implementing and composing loosely coupled
independent components into systems. This practice aims to bring about an equally wide-
ranging degree of benefits in both the short-term and the long-term for the software
itself and for organizations that sponsor such software.
Software engineering practitioners regard components as part of the starting platform

m
for service-orientation. Components play this role, for example, in web services, and more

o
recently, in service-oriented architectures (SOA), whereby a component is converted by
the web service into a service and subsequently inherits further characteristics beyond

.c
that of an ordinary component.
Components can produce or consume events and can be used for event-driven

a
architectures (EDA).

m
Characteristics of components
An individual software component is a software package, a web service, a web resource,

a
or a module that encapsulates a set of related functions (or data).

n
All system processes are placed into separate components so that all of the data and
functions inside each component are semantically related (just as with the contents of

y
classes). Because of this principle, it is often said that components are modular and

d
cohesive.
With regard to system-wide co-ordination, components communicate with each other

u
via interfaces. When a component offers services to the rest of the system, it adopts

t
a provided interface that specifies the services that other components can utilize, and
how they can do so. This interface can be seen as a signature of the component – the
S
client does not need to know about the inner workings of the component
(implementation) in order to make use of it. This principle results in components referred
to as encapsulated. The UML illustrations within this article represent provided interfaces
by a lollipop-symbol attached to the outer edge of the component.
However, when a component needs to use another component in order to function, it
adopts a used interface that specifies the services that it needs. In the UML illustrations in
this article, used interfaces are represented by an open socket symbol attached to the
outer edge of the component.
 A simple example of several software components – pictured within a hypothetical
holiday-reservation system represented in UML 2.0. m
o
.c
Another important attribute of components is that they are substitutable, so that a
component can replace another (at design time or run-time), if the successor component
meets the requirements of the initial component (expressed via the interfaces).
a
Consequently, components can be replaced with either an updated version or an
alternative without breaking the system in which the component operates.
m
As a general rule of thumb for engineers substituting components, component B can

a
immediately replace component A, if component B provides at least what component A
provided and uses no more than what component A used.
n
Software components often take the form of objects (not classes) or collections of objects

y
(from object-oriented programming), in some binary or textual form, adhering to some
interface (IDL) so that the component may exist autonomously from other components in
a computer.
d
u
When a component is to be accessed or shared across execution contexts or network

t
links, techniques such as serialization or marshalling are often employed to deliver the
component to its destination.

S
Reusability is an important characteristic of a high-quality software component.
Programmers should design and implement software components in such a way that
many different programs can reuse them. Furthermore, component-based usability
testing should be considered when software components directly interact with users.
It takes significant effort and awareness to write a software component that is effectively
reusable. The component needs to be:

Software Development Life Cycle [ RGPV/ JUNE-2014,2012(7),JUNE 2011(10) ]

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in
systems engineering, information systems and software engineering, is the process of
creating or altering systems, and the models and methodologies that people use to
develop these systems. The concept generally refers to computer or information systems.

In software engineering the SDLC concept underpins many kinds of software development
methodologies. These methodologies form the framework for planning and controlling
the creation of an information system: the software development process.

The System Development Life Cycle framework provides a sequence of activities for
system designers and developers to follow. It consists of a set of steps or phases in which
each phase of the SDLC uses the results of the previous one.

A Systems Development Life Cycle (SDLC) adheres to important phases that are essential
for developers, such as planning, analysis, design, and implementation, and are explained
in the section below. A number of system development life cycle (SDLC) models have
been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and

m
synchronize and stabilize. The oldest of these, and the best known, is the waterfall model:
a sequence of stages in which the output of each stage becomes the input for the next.

o
These stages can be characterized and divided up in different ways, including the

.c
following

a
There are following six phases in every Software development life cycle model:

Requirement gathering and analysis

m
a
Design

Implementation or coding
n
Testing y
d
u
Deployment

Maintenance
t
this
S
1) Requirement gathering and analysis: Business requirements are gathered in
phase. This phase is the main focus of the project managers and stake
holders. Meetings with managers, stake holders and users are held in order to determine
the requirements like; Who is going to use the system? How will they use the
system? What data should be input into the system? What data should be output by the
system? These are general questions that get answered during a requirements gathering
phase. After requirement gathering these requirements are analyzed for their validity and
the possibility of incorporating the requirements in the system to be development is also
studied.

Finally, a Requirement Specification document is created which serves the purpose of

guideline for the next phase of the model.

2) Design: In this phase the system and software design is prepared from the
requirement specifications which were studied in the first phase. System Design helps in
specifying hardware and system requirements and also helps in defining overall system
architecture. The system design specifications serve as input for the next phase of the
model.

3) Implementation / Coding: On receiving system design documents, the work is divided

in modules/units and actual coding is started. Since, in this phase the code is produced so
it is the main focus for the developer. This is the longest phase of the software
development life cycle.

4) Testing: After the code is developed it is tested against the requirements to make sure

m
that the product is actually solving the needs addressed and gathered during the
requirements phase. During this phase unit testing, integration testing, system testing,
acceptance testing are done.
o
.c
5) Deployment: After successful testing the product is delivered / deployed to the

a
customer for their use.

6) Maintenance: Once when the customers starts using the developed system then the
m
actual problems comes up and needs to be solved from time to time. This process where

a
the care is taken for the developed product is known as maintenance.

n
y
d
u
t
S
SDLC Model
1. Waterfall Model
2. V-Shaped Model
m
3. Evolutionary Prototyping Model
4. Spiral Method (SDM) o
.c
5. Iterative and Incremental Method
6. Extreme programming (Agile development)

Waterfall Model[ RGPV/ JUNE-2011(5) ] a

m
a
This model involves finishing the first phase completely before commencing the next one.

n
When each phase is completed successfully, it is reviewed to see if the project is on track

y
and whether it is feasible to continue.

d
u
t
S

 Requirements – defines needed information, function, behavior, performance and

interfaces.
 Design – data structures, software architecture, interface representations,
 algorithmic details.
 Implementation – source code, database, user documentation, testing.
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost or schedule
Waterfall Strength
 All requirements must be known upfront
 Deliverables created for each phase are considered frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software development – iterations of
phases

m
 Integration is one big bang at the end
 Little opportunity for customer to preview the system (until it may be too late)
Waterfall Deficiencies
o
.c
 Requirements are very well known
 Product definition is stable

a
 Technology is understood
 New version of an existing product

V-Shaped Model: m
a
This model focuses on execution of processes in a sequential manner, similar to the
n
waterfall model but with more importance placed on testing. Testing procedures are

y
written even before the commencement of writing code. A system plan is generated
before starting the development phase.
d
u
t
S
Studynama’s BDS Community is one of India’s Largest Community of Dental Students. About
19,232 Indian Dental Course students are members of this community and share FREE study
material, cases, projects, exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for BDS (Dental) students:

 Orthodontic Fixed Appliances - BDS Lecture Notes PDF Download
 Amalgam Restoration - BDS Lecture Notes PDF Download
 COMPLEX NON-SKELETAL PROBLEMS IN PREADOLESCENT CHILDREN - BDS Lecture Notes
 Anatomy of Scalp - BDS Lecture Notes PDF Download
 Cerebrospinal Fluid (CSF) - BDS Lecture Notes PDF Download
 Cementum - BDS Lecture Notes PDF Download
 Recent Advances in Instrumentation Techniques - BDS Lecture Notes PDF Download
 Ameloblastoma - BDS Lecture Notes PDF Download
 Prevention of Odontogenic Infection - Principles of Management - BDS Lecture Notes
 Therapeutic Dentistry Histology of Teeth Dental Charting - BDS Lecture Notes PDF Download
 Maxillofacial Trauma and Management - BDS Lecture Notes PDF
 Technical Endodontics - BDS Lecture Notes PDF Download
And 698 more free downloads for Dental Students.
Other Popular Links for Law Study Material:
 BDS Lecture Notes, eBooks, Guides, Projects and Case Papers FREE PDF Download
 BDS Lecture Notes, eBooks, Guides & Handouts FREE PDF Download
 BDS University Previous Year Exam Question Papers & Solutions FREE PDF Download
V Shape Strength
 Emphasize planning for verification and validation of the product in early stages of
product development
 Each deliverable must be testable
 Project management can track progress by milestones
 Easy to use

V Shape Weakness
 Emphasize planning for verification and validation of the product in early stages of
product development
 Each deliverable must be testable
 Project management can track progress by milestones
 Easy to use

Evolutionary Prototyping Model m

o
.c
It refers to the activity of creating prototypes of software applications, for example,
incomplete versions of the software program being developed. It is an activity that can

a
occur in software development. It used to visualize some component of the software to
limit the gap of misunderstanding the customer requirements by the development team.

m
This also will reduce the iterations may occur in waterfall approach and hard to be
implemented due to inflexibility of the waterfall approach. So, when the final prototype is

a
developed, the requirement is considered to be frozen.

It has some types, such as:

n
y
· Throwaway prototyping: Prototypes that are eventually discarded rather than becoming
d
a part of the finally delivered software

u
securing his information.
t
S
Evolutionary prototyping: prototypes that evolve into the final system through iterative
incorporation of user feedback.

m
o
.c
a
Incremental prototyping: The final product is built as separate prototypes. At the end the
separate prototypes are merged in an overall design.

m
a
n
y
d
u
t
S
Extreme prototyping: used at web applications mainly. Basically, it breaks down web
development into three phases, each one based on the preceding one. The first phase is a
static prototype that consists mainly of HTML pages. In the second phase, the screens are
programmed and fully functional using a simulated services layer. In the third phase the
services are implemented

The usage
· This process can be used with any software developing life cycle model. While this shall
be focused with systems needs more user interactions. So, the system do not have user
interactions, such as, system does some calculations shall not have prototypes.
Studynama’s Engineering Community is one of India’s Largest Community of BE & BTECH Students. About 79,182
Indian Engineering students are members of this community and share FREE study material, notes, eBooks, major
and minor projects, exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for Engineering (BE/BTech) students:

CSE & IT Engineering Electronics Engineering Electrical Engineering Mechanical Engineering Civil Engineering

Computer Science Electronics Engineering BTech Civil/Structural

Electrical/EE Engineering Mechanical/Automobile/IP
(CSE/IT Engineering) (ECE/ET/EC) Engineering Second
Second/2nd Year Notes Engineering second year notes
Second/2nd Year Notes Second/2nd Year Notes Year Lecture Notes

CSE/IT Computer Electronics Engineering BTech Civil/Structural

Electrical/EE Engineering Mechanical/Automobile/IP
Science Engg. Final/4th (ECE/EC/ET) Third/3rd Engineering Fourth
Third/3rd Year notes Engineering fourth year notes
Year Notes Year Notes Year Lecture Notes

Computer Science Electronics (ECE/ET/EC) BTech Civil/Structural

Electrical/EE Engineering Mechanical/Automobile/IP
Engineering (CSE/IT) Engineering Final/Fourth Engineering Third Year
Fourth/4th Year Notes Engineering third year notes
Third/3rd Year Notes Year Notes Lecture Notes

Advanced Java Antenna & wave Electrical Machine-1 pdf Automobile engineering lecture
Surveying 1 - eBook
Programming eBook propagation eBook download notes

Web Technology - Network analysis & Electrical machines-II Engineering materials & SOM - strength of
eBook synthesis notes eBook metallurgy lecture notes materials - eBook

E-Commerce lecture VLSI engineering pdf Manufacturing Technology-1 Engineering Geology

EMI eBook
notes lecture notes lecture notes eBook

And 12998 more free downloads for BE & BTech Students.

Other Popular Links for Engineering Study Material:

• Engineering First Semester (Sem 1) Notes
• Engineering Second Semester (Sem 2) Notes
• Engineering chemistry pdf eBook
• Engineering Mechanics PDF Lecture Notes
• Electrical/EE Engineering notes
• Mechanical/Automobile/IP Engineering notes
• Powerplant Engineering Lecture Notes
• Engineering Mechanics lecture notes
Advantages/Disadvantages
· Reduced time and costs, but this can be disadvantage if the developer lose time in
developing the prototypes· Improved and increased user involvement.
· Insufficient analysis· User confusion of prototype and finished system.
· Developer misunderstanding of user objectives.
· Excessive development time of the prototype· Expense of implementing prototyping

S.NO RGPV QUESTIONS Year Marks

Q.1 Explain the software life cycle model in detail. JUNE 7
2013
Q.2 Explain Waterfall model. JUNE 5

m
2011
Q.3 Define the term component. What are the benefits of JUNE 7
component based software engineering (CBSE).
o 2014,

.c
2013

a
m
a
n
y
d
u
t
S
 UNIT – I
Topic:-SDLC Model
Unit-01/Lecture-04
Spiral Model-:-[ RGPV/JUNE-2013(10),JUNE-2011(5) ]

 Adds risk analysis, and 4gl RAD prototyping to the waterfall model
 Each cycle involves the same sequence of steps as the waterfall process model

m
o
.c
a
m
a
n
y
 Objectives: functionality, performance, hardware/software interface, critical

d
success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
u
 Constraints: cost, schedule, interface, etc.

t
 Spiral Quadrant

S
 Objectives: functionality, performance, hardware/software interface, critical
success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.
 Objectives: functionality, performance, hardware/software interface, critical
success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.

Spiral Model Strength

 Provides early indication of insurmountable risks, without much cost

Studynama’s Law Community is one of India’s Largest Community of Law Students. About
29,982 Indian Law students are members of this community and share FREE study material,
cases, projects, exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for LAW (LLB & BA.LLB) students:
• Family law pdf lecture notes & eBook download for LLB students
• Jurisprudence Law lecture notes pdf & eBook download for LLB students
• Company Law lecture notes pdf & eBook download for LLB students
• Law of Evidence lecture notes pdf & eBook download for LLB students
• Contract Law lecture notes pdf & eBook download for LLB students
• Criminal law pdf lecture notes & eBook download for LLB students
• Taxation Law lecture notes pdf & eBook download for LLB students
• Law of torts pdf eBook & lecture notes for LLB students
• Constitutional law pdf lecture notes & eBook download
• Labour law lecture notes pdf & eBook download for LLB students
• Administrative law lecture notes pdf & eBook download for LLB students
• Constitutional Law - I q&a notes pdf & eBook download for LLB
And 1998 more free downloads for Law & LLB Students.

Other Popular Links for Law Study Material:

• LLB/LLM Lecture Notes, eBooks, Guides, Handouts FREE PDF Download
• LLB - Law third year notes, eBooks, handouts and study material - semester 5 & 6
• LLB - Law second year notes, eBooks, handouts and study material - semester 3 & 4
• LLB - Law first year notes, eBooks, handouts and study material - semester 1 & 2
  Users see the system early because of rapid prototyping tools
 Critical high-risk functions are developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently

Spiral Model Weakness

 Time spent for evaluating risks too large for small or low-risk projects
 Time spent planning, resetting objectives, doing risk analysis and prototyping may
be excessive
 The model is complex
 Risk assessment expertise is required

m
 Spiral may continue indefinitely
 Developers must be reassigned during non-development phase activities

o
 May be hard to define objective, verifiable milestones that indicate readiness to

.c
proceed through the next iteration

a
5. Iterative and Incremental Method

It is developed to overcome the weaknesses of the waterfall model. It starts with an

m
initial planning and ends with deployment with the cyclic interactions in between. The

a
basic idea behind this method is to develop a system through repeated cycles (iterative)
and in smaller portions at a time (incremental), allowing software developers to take
n
advantage of what was learned during development of earlier parts or versions of the
system.
y
d
It consists of mini waterfalls

u
t
S
The usage

It is used in shrink-wrap application and large system which built-in small phases or
segments. Also can be used in system has separated components, for example, ERP
system. Which we can start with budget module as first iteration and then we can start
with inventory module and so forth.

Extreme programming (Agile development)

It is based on iterative and incremental development, where requirements and solutions

evolve through collaboration between cross-functional teams.

m
o
.c
a
m
a
n
y
The usage d
u
t
It can be used with any type of the project, but it needs more involvement from customer

S
and to be interactive. Also, it can be used when the customer needs to have some
functional requirement ready in less than three weeks.

Advantages/Disadvantages

· Decrease the time required to avail some system features.· Face to face communication
and continuous inputs from customer representative leaves no space for guesswork.· The
end result is the high quality software in least possible time duration and satisfied
customer · Scalability· Skill of the software developers· Ability of customer to express
user needs· Documentation is done at later stages· Reduce the usability of components.·
Needs special skills for the team.
S.NO RGPV QUESTIONS Year Marks
Q.1 Explain the software life cycle model in detail. JUNE 7
2013
Q.2 List several software process paradigms. Explain how both JUNE 7
water fall model & prototype model can be accommodated 2014
in the spiral model?
Q.3 Explain why spiral model is considered to be meta data JUNE 10
model. 2013
Q.4 Discuss the selection process parameters for a life cycle JUNE 10
model. 2011

m
o
.c
a
m
a
n
y
d
u
t
S
Studynama’s MBA Community is one of India’s Largest Community of MBA & PGDM Students. About 29,882 Indian
Management students are members of this community and share FREE study material, notes, eBooks, projects, case
studies exam papers etc. to enable each other to do well in their semester exams.

Links to Popular Study Material for Management (MBA/PGDM) students:

MBA General MBA Marketing MBA Finance MBA HR MBA Operations

MBA/PGDM first Enterprise resource Security analysis & Business environment MBA Operations
year notes planning (ERP) pdf portfolio Mgmt. Notes Notes

MBA/PGDM second Marketing International Fin. Human resource MIS pdf

year notes management pdf management eBook management pdf

Principles of International Advanced financial Compensation Industrial safety

management pdf marketing eBook management eBook management Notes eBook

Managerial Retail marketing Corporate taxation International human Import export

economics eBook eBook pdf eBook resource management pdf mgmt. lecture notes

Organizational Sales management Financial Human resource TQM eBook

behavior pdf eBook management eBook development eBook

Operation research Brand management Management Organization & Management

lecture notes pdf accounting notes management process pdf control systems

And 12,998 more free downloads for MBA & PGDM Students.

Other Popular Links for MBA Study Material:

• MBA/PGDM Core (General) Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM Marketing Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM Finance Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM HR Notes, eBooks, Projects, Cases & Reports FREE PDF Download
• MBA/PGDM Operations Notes, eBooks, Projects, Cases & Reports FREE PDF Download
 UNIT – I
Topic:-Rational Unified Model
Unit-01/Lecture-05

Rational Unified Model:- [ RGPVJUNE-2014,2013,2012(7)]

THE UNIFIED APPROACH TO MODELING

The Unified Approach (UA) is the methodology for software development, based on
methodologies by Booch, James Rumbaugh and Jacobson. UA has the following features:

1. Just like Jacobson's model, the UA is also a Use-case driven software development
methodology. In UA to modeling, all the models are built around the use-case

m
model.
2. UA utilizes a standard set of tools for modeling.

o
3. The OO analysis is done by utilizing use-cases and object modeling.

.c
4. It favors repositories of reusable classes and emphasizes on maximum reuse.
5. UA follows a layered approach to software development.

a
6. UA is suitable for different development lifecycles such as Incremental development
and prototyping.

m
7. UA favors continuous testing throughout the development lifecycle.

a
Unified process is a refinement of rational unified process. It is an extensible framework
that can be customized for specific projects.
n
y
This process divides the development process into four phases:
 Inception
d
 Elaboration

u
 Conception

t
 Transition
UP have the following major characteristics:
S
 It is use-case driven
 It is architecture-centric
 It is risk focused
 It is iterative and incremental
The 6 RUP Best Practices

The Unified Process

phase phase

Inc. Elaboration Construction Trans.

iteration
Release
Final release
The end of each
iteration is a
minor release

m
1.Develop Iteratively o
.c
The software requirements specification (SRS) keeps on evolving throughout the
development process and loops are created to add them without affecting the cost of
development.
2.Manage Requirements a
m
The business requirements documentation and project management requirements need

a
to be gathered properly from the user in order to reach the targeted goal.

3. Use Components
n
y
The components of large project which are already tested and are in use can be
conveniently used in other projects. This reuse of components reduces the production
time.
d
u
4. Model Visually
t
Use of Unified modeling language (UML) facilitates the analysis and design of various

S
components. Diagrams and models are used to represent various components and their
interactions.

5. Verify Quality
Testing and implementing effective project quality management should be a major part of
each and every phase of the project from initiation to delivery (aka the project
management life cycle).

6. Control Changes
Synchronization of various parts of the system becomes all the more challenging when
the parts are being developed by various teams working from different geographic
locations on different development platforms. Hence special care should be taken in this
direction so that the changes can be controlled.
Advantages of RUP Software Development
1. This is a complete methodology in itself with an emphasis on accurate
documentation.
2. It is proactively able to resolve the project risks associated with the client's evolving
requirements requiring careful change request management.
3. Less time is required for integration as the process of integration goes on
throughout the software development life cycle.
4. The development time required is less due to reuse of components.
5. There is online training and tutorial available for this process.

Disadvantages of RUP Software Development

1.The team members need to be expert in their field to develop a software under this
Methodology.

m
2. The development process is too complex and disorganized.
3. On cutting edge projects which utilize new technology, the reuse of components
o
will not be possible. Hence the time saving one could have made will be impossible

.c
to fulfill.
4. Integration throughout the process of software development, in theory sounds a

a
good thing. But on particularly big projects with multiple development streams it
will only add to the confusion and cause more issues during the stages of testing

m
S.NO a
RGPV QUESTIONS Year Marks

n
Q.1 What are the different phases of unified modeling? JUNE 10

y
2012
Q.2 Explain the unified approach to software development. JUNE 7

d
Discuss the merits & demerits of this approach. 2013,2014

u
t
S
 UNIT – I
Topic:- Difference between process & methodology
Unit-01/Lecture-06
Difference between process & methodology

Processes are probably the easiest to understand since we all work with them daily, even
when we don t know it. A process is simply a well defined set of steps and decisions
points for executing a specific task. Well planned and deeply understood processes are
essential to your ability to automate business tasks. This is really where that magic
happens, a process level. Generally speaking, processes are highly repeatable and if it can
be repeated it can be automated (with exceptions or occasional human intervention of
course).

m
An example of a process would be how you process payments to vendors you work with

o
and the steps and decisions involved in doing so. When working through processes and

.c
defining them be EXTREMELY detailed, otherwise attempts to automate will end in
futility. Capture every action and decision and outline sub-processes as necessary.

a
Hopefully that clears up the differences between frameworks, methodologies and
processes. While they appear somewhat hierarchical, and can be, they aren t always

m
necessarily so, particularly in both directions. Frameworks will typically have
methodologies but not always. Methodologies will typically have [multiple] processes

a
embedded, but some processes will be stand alone.

n
The real power of combining these things is in developing processes in the context of a

y
methodology and applying methodologies in the context of a framework and most
importantly, when you utilize all of those things in the context of YOUR business. The
d
exact same approach won t work for every business but every business, no matter how

u
large or small, can benefit from applying these principles.

t
software configuration management-:-[ RGPV/JUNE-2014(7) ]

S
Software configuration management is referred to as source control, change
management, and version control.

Software configuration management systems are commonly used in software

development groups in which several developers are concurrently working on a common
set of files. If two developers change the same file, that file might be overwritten and
critical code changes lost. Software configuration management systems are designed to
avoid this inherent problem with sharing files in a multiuser environment.

Any software configuration management system creates a central repository to facilitate

file sharing. Each file to be shared must be added to the central repository to create the
first version of the file. After a file is part of the central repository, users can access and
update it, creating new versions.
Software Configuration Management (SCM) is the overall management of a software
design project as it evolves into a software product or system. This includes technical
aspects of the project, all level of communications, organization, and the control of
modifications changes to the project plan by the programmers during the development
phase. Software Configuration Management is also called Software Control Management.

Changes are inevitable when software is built. A primary goal of software engineering is
to improve the ease with which changes can be made to software. Configuration
management is all about change control. Every software engineer has to be concerned
with how changes made to work products are tracked and propagated throughout a
project. To ensure that quality is maintained the change process must be audited. A
Software Configuration Management (SCM) Plan defines the strategy to be used for

m
change management.

Software Configuration Items (SCI)

o
.c
 Computer programs (both source and executable)
 Documentation (both technical and user)

a
 Data (contained within the program or external to it)

m
Fundamental Sources of Change
 New business or market conditions dictate changes to product requirements or
business rules
a
n
 New stakeholder needs demand modification of data, functionality, or services
delivered by a computer-based system

y
 Business reorganization causes changes in project priorities or software engineering

d
team structure
 Budgetary or scheduling constraints cause system to be redefined
u
t
Configuration Management System Elements
 Component elements – set of tools coupled within a file management system to
S
enable access to and management of each SCI
 Process elements – collection of procedures and tasks that define and effective
approach to change management for all stakeholders
 Construction elements – set of tolls that automate the construction of software by
ensure a set of validated components is assembled
 Human elements – team uses a set of tools and process features encompassing other
CM elements

Baselines
 A work product becomes a baseline only after it is reviewed and approved.
 A baseline is a milestone in software development that is marked by the delivery of
 one or more configuration items.
 Once a baseline is established each change request must be evaluated and verified by
a formal procedure before it is processed.
 Baseline work products are place in a project database or repository

SCM Repository Functions

 Data integrity
 Information sharing
 Tool integration
 Data integration
 Methodology enforcement
 Document standardization

SCM Content
 Problem description
m
o
 Problem domain information
 Emerging system solution

.c
 Software process rules and instructions
 Project plan, resources, and history
 Organizational content information
a
m
a
SCM Tool Features
 Versioning - control changes to all work products before and after release to
customer
n
y
 Dependency tracking and change management - tracking relationships among
multiple versions of work products to enable efficient changes (link management)

d
 Requirements tracing – depends on link management, provides the ability to track all

u
work products that result from a specific requirements specification (forward tracing)

t
and to identify which requirement generated by any given work product (backward
tracing)

S
 Configuration management – works closely with link management and versioning
facilities to keep track of a series of configurations representing project milestones or
production releases
 Audit trails - establishes additional information about when, where, why, and by
whom changes were made

SCM Process Objectives

1. Identify all items that define the software configuration
2. Manage changes to one or more configuration items
3. Facilitate construction of different versions of a software application
4. Ensure that software quality is maintained as configuration evolves
Software Configuration Management Tasks
 Identification (tracking multiple versions to enable efficient changes)
 Version control (control changes before and after release to customer)
 Change control (authority to approve and prioritize changes)
 Configuration auditing (ensure changes made properly)
 Reporting (tell others about changes made)

Configuration Object Identification

 To control and manage configuration items, each must be named and managed using
an object-oriented approach
 Basic objects are created by software engineers during analysis, design, coding, or
testing
 Aggregate objects are collections of basic objects and other aggregate objects
 Configuration object attributes: unique name, description, list of resources, and a

m
realization (a pointer to a work product for a basic object or null for an aggregate

o
object)

.c
Version Control
 Combines procedures and tools to manage the different versions of configuration
objects created during the software process
a
 Version control systems require the following capabilities

m
o Project repository – stores all relevant configuration objects
o Version management capability – stores all versions of a configuration object
a
(enables any version to be built from past versions)

n
o Make facility – enables collection of all relevant configuration objects and

y
construct a specific software version
o Issues (bug) tracking capability – enables team to record and track status of

d
outstanding issues for each configuration object
 Uses a system modeling approach (template – includes component hierarchy and
u
component build order, construction rules, verification rules)

t
S
Change Control
 Change request is submitted and evaluated to assess technical merit and impact on
the other configuration objects and budget
 Change report contains the results of the evaluation
 Change control authority (CCA) makes the final decision on the status and priority of
the change based on the change report
 Engineering change order (ECO) is generated for each change approved (describes
change, lists the constraints, and criteria for review and audit)
 Object to be changed is checked-out of the project database subject to access control
parameters for the object
 Modified object is subjected to appropriate SQA and testing procedures
 Modified object is checked-in to the project database and version control mechanisms
 are used to create the next version of the software
 Synchronization control is used to ensure that parallel changes made by different
people don t overwrite one another

Software Configuration Audit Questions

1. Has the change specified by the ECO been made without modifications?
2. Has a FTR been conducted to assess technical correctness?
3. Was the software process followed and software engineering standards been properly
applied?
4. Do the attributes of the configuration object reflect the change?
5. Have the SCM standards for recording and reporting the change been followed?
6. Were all related SCI's properly updated?

Content Management System

m
 Establishes a process that acquires existing content, structures it to be presented to
an end-user, and provides for display to the client-side environment
 Collection subsystem
o
.c
o converts content to displayable format
o organizes content for client-side display

a
 Management subsystem
o content database

m
o database capabilities
o configuration management functions
 Publishing subsystem
a
n
o static elements
o publication services
o external services
y
d
Benefits of software configuration management

u
t
If you have not used a software configuration management system or are not that familiar

S
with the concept, you might wonder whether it is appropriate to use software
configuration management on your project. Test automation is a software development
effort. Every time a test script is created, whether through recording or coding, a file is
generated that contains code. When created, developed, or edited, that code is a valuable
test asset.

A team environment presents the risk of losing functioning code or breaking test scripts
by overwriting files. A software configuration management system offers a way to
overcome this risk. Every time a file changes, a new version is created and the original file
is preserved.

For the team that is new to software configuration management, all of the essential
features for versioning test scripts are available through the Functional Tester interface.
This integration simplifies the use and adoption of software configuration management.

Software configuration management products

The ClearCase or Rational Team Concert integration for versioning Functional Tester test
assets is specialized and cannot be duplicated with other tools. For this reason, some
ClearCase operations cannot be performed outside Functional Tester.

When you use Functional Tester, the ClearCase or Rational Team Concert operations
appear to be very simple. But a lot is going on behind the scenes. A Functional Tester
script is a collection of files. The complexity of treating several files as a single entity is
hidden because all actions in the Functional Tester user interface are performed on the
script. You do not see the related files anywhere in the user interface. In addition, some

m
software configuration management operations, such as merging, are very complex.
There is built-in logic to determine the order in which files are merged, and then different
utilities are employed as needed to complete the merge.
o
.c
a
S.NO RGPV QUESTIONS
m Year Marks

a
Q.1 Explain in detail configuration management. JUNE
2014
7

n
y
d
u
t
S
 UNIT – I
Topic:-Safety

Unit-01/Lecture-07

Safety in Software Engineering:-

Software system safety, an element of the total safety and software development
program, cannot be allowed to function independently of the total effort. Both simple
and highly integrated multiple systems are experiencing an extraordinary growth in the
use of computers and software to monitor and/or control safety-critical subsystems or
functions. A software error, design flaw, or the lack of generic safety-critical
requirements can contribute to or cause a system failure or erroneous human decision.

m
To achieve an acceptable level of safety for software used in critical applications,

o
software system safety engineering must be given primary emphasis early in the
requirements definition and system conceptual design process.

.c
Safety-critical software must then receive continuous management emphasis and

a
engineering analysis throughout the development and operational lifecycles of the
system. Software system safety is directly related to the more critical design aspects

m
and safety attributes in software and system functionality, whereas software quality
attributes are inherently different and require standard scrutiny and development
a
rigor. Software safety hazard analysis required for more complex systems where

n
software is controlling critical functions generally are in the following sequential
categories and are conducted in phases as part of the system safety or safety

y
engineering process: software safety requirements analysis; software safety design

d
analyses (top level, detailed design and code level); software safety test analysis, and
software safety change analysis.

u
t
Once these "functional" software safety analyses are completed the software

S
engineering team will know where to place safety emphasis and what functional
threads, functional paths, domains and boundaries to focus on when designing in
software safety attributes to ensure correct functionality and to detect malfunctions,
failures, faults and to implement a host of mitigation strategies to control hazards.
Software security and various software protection technologies are similar to software
safety attributes in the design to mitigate various types of threats vulnerability and
risks. Deterministic software is sought in the design by verifying correct and predictable
behaviour at the system level.

Goals
 Safety consistent with mission requirements, is designed into the software in a
timely, cost effective manner.
  On complex systems involving many interactions safety-critical functionality
should be identified and thoroughly analyzed before deriving hazards and
design safeguards for mitigations.
 Safety-critical functions lists and preliminary hazards lists should be determined
proactively and influence the requirements that will be implemented in
software.
 Contributing factors and root causes of faults and resultant hazards associated
with the system and its software are identified, evaluated and eliminated or the
risk reduced to an acceptable level, throughout the lifecycle.
 Reliance on administrative procedures for hazard control is minimized.
 The number and complexity of safety critical interfaces is minimized.
 The number and complexity of safety critical computer software components is
minimized.
 Sound human engineering principles are applied to the design of the software-

m
user interface to minimize the probability of human error.
 Failure modes, including hardware, software, human and system are addressed
in the design of the software.
o
.c
 Sound software engineering practices and documentation are used in the
development of the software.

a
 Safety issues and safety attributes are addressed as part of the software testing
effort at all levels.

m
 Software is designed for human machine interface, ease of maintenance and
modification or enhancement

a
Software with safety-critical functionality must be thoroughly verified with

n
objective analysis and preferably test evidence that all safety requirements have
been met per established criteria.

y
d
Open Source Software Development
Open-source software development is the process by which open-source software, or

u
similar software whose source code is publicly available, is developed. These are

t
software products available with its source code under an open-source license to study,
change, and improve its design. Examples of some popular open-source software
S
products are Mozilla Firefox, Google Chromium, Android, LibreOffice and the Apache
OpenOffice Suite. Open-source software development has been a large part of the
creation of the World Wide Web as we know it, with Tim Berners-Lee contributing his
HTML code development as the original platform upon which the internet is now built.

Open-source software development model

Open-source software development can be divided into several phases. The phases
specified here are derived from Sharma et al.[3] A diagram displaying the process-data
structure of open-source software development is shown on the right. In this picture, the
phases of open-source software development are displayed, along with the
corresponding data elements. This diagram is made using the meta-modeling and meta-
process modeling techniques.
 m
o
.c
a
m
Starting an open-source project
a
There are several ways in which work on an open-source project can start-
n
y
1. An individual who senses the need for a project announces the intent to develop a
project in public.
d
2. A developer working on a limited but working codebase, releases it to the public as

u
the first version of an open-source program.

t
3. The source code of a mature project is released to the public.
4. A well-established open-source project can be forked by an interested outside

S
party.

Eric Raymond observed in his essay The Cathedral and the Bazaar that announcing the
intent for a project is usually inferior to releasing a working project to the public.

It's a common mistake to start a project when contributing to an existing similar project
would be more effective (NIH syndrome). To start a successful project it is very important
to investigate what's already there. The process starts with a choice between the
adopting of an existing project, and the starting of a new project. If a new project is
started, the process goes to the Initiation phase. If an existing project is adopted, the
process goes directly to the Execution phase.
 UNIT – I
Topic:-Risk Assessment
Unit-01/Lecture-08

Risk Assessment:-[RGPV/JUNE-2012(10),JUNE-2014(5)]

The goal of risk assessment is to prioritize the risks so that attention and resources can
be focused on the more risky items. Risk identification is the first step in risk assessment,
which identifies all the different risks for a particular project. These risks are project-
dependent and identifying them is an exercise in envisioning what can go wrong.
Methods that can aid risk identification include checklists of possible risks, surveys,
meetings and brainstorming, and reviews of plans, processes, and work products.

m
Checklists of frequently occurring risks are probably the most common tool for risk

o
identification—most organizations prepare a list of commonly occurring risks for

.c
projects, prepared from a survey of previous projects. Such a list can form the starting
point for identifying risks for the current project.

a
Based on surveys of experienced project managers, Boehm [11] has produced a list of

m
the top 10 risk items likely to compromise the success of a software project. Figure
shows some of these risks along with the techniques preferred by management for

a
managing these risks. Top risks in a commercial software organization can be found in

n
y
d
u
t
S

Figure 4.3: Top risk items and techniques for managing them

The top-ranked risk item is personnel shortfalls. This involves just having fewer people
than necessary or not having people with specific skills that a project might require. Some
of the ways to manage this risk are to get the top talent possible and to match the needs
of the project with the skills of the available personnel. Adequate training, along with
having some key personnel for critical areas of the project, will also reduce this risk.

The second item, unrealistic schedules and budgets, happens very frequently due to
business and other reasons. It is very common that high-level management imposes a
schedule for a software project that is not based on the characteristics of the project and
is unrealistic. Underestimation may also happen due to inexperience or optimism.

The next few items are related to requirements. Projects run the risk of developing the
wrong software if the requirements analysis is not done properly and if development
begins too early. Similarly, often improper user interface may be developed. This requires
extensive rework of the user interface later or the software benefits are not obtained
because users are reluctant to use it. Gold plating refers to adding features in the
software that are only marginally useful. This adds unnecessary risk to the project
because gold plating consumes resources and time with little return.

m
Risk identification merely identifies the undesirable events that might take place during
o
the project, i.e., enumerates the unforeseen events that might occur. It does not specify

.c
the probabilities of these risks materializing nor the impact on the project if the risks
indeed materialize. Hence, the next tasks are risk analysis and prioritization.

a
In risk analysis, the probability of occurrence of a risk has to be estimated, along with the

m
loss that will occur if the risk does materialize. This is often done through discussion, using
experience and understanding of the situation, though structured approaches also exist.

a
n
Once the probabilities of risks materializing and losses due to materialization of different
risks have been analyzed, they can be prioritized. One approach for prioritization is

y
through the concept of risk exposure (RE) [11], which is sometimes called risk impact. RE

d
is defined by the relationship

u
RE = Prob(UO) * Loss(UO),

t
where Prob(UO) is the probability of the risk materializing (i.e., undesirable outcome) and
S
Loss(UO) is the total loss incurred due to the unsatisfactory outcome. The loss is not only
the direct financial loss that might be incurred but also any loss in terms of credibility,
future business, and loss of property or life. The RE is the expected value of the loss due
to a particular risk. For risk prioritization using RE is, the higher the RE, the higher the
priority of the risk item.

Software Risk Management:

Since there could be various risks associated with the software development projects, the
key to identify and manage those risks is to know about the concepts of software risk
management. Many concepts about software risk management could be identified but
the most important are risk index, risk analysis, and risk assessment-
1.Risk Index: Generally risks are categorized into two factors namely impact of risk
events and probability of occurrence. Risk index is the multiplication of impact and
probability of occurrence. Risk index can be characterized as high, medium, or low
depending upon the product of impact and occurrence. Risk index is very important and
necessary for prioritization of risk.

2. Risk Analysis: There are quite different types of risk analysis that can be used. Basically,
risk analysis is used to identify the high risk elements of a project in software engineering.
Also, it provides ways of detailing the impact of risk mitigation strategies. Risk analysis has
also been found to be most important in the software design phase to evaluate criticality
of the system, where risks are analyzed and necessary counter measures are introduced.

The main purpose of risk analysis is to understand risks in better ways and to verify and
correct attributes. A successful risk analysis includes important elements like problem

m
definition, problem formulation, data collection.

o
3. Risk Assessment: Risk assessment is another important case that integrates risk

.c
management and risk analysis. There are many risk assessment methodologies that focus
on different types of risks. Risk assessment requires correct explanations of the target

a
system and all security. It is important that a risk referent levels like performance, cost,
support and schedule must be defined properly for risk assessment to be useful.

Risk Classification: m
a
The key purpose of classifying risk is to get a collective viewpoint on a group of factors.

n
These are the types of factors which will help project managers to identify the group that
contributes the maximum risk. A best and most scientific way of approaching risks is to

y
classify them based on risk attributes. Risk classification is considered as an economical

d
way of analyzing risks and their causes by grouping similar risks together into classes.
Software risks could be classified as internal or external. Those risks that come from risk

u
factors within the organization are called internal risks whereas the external risks come

t
from out of the organization and are difficult to control. Internal risks are project risks,
process risks, and product risks. External risks are generally business with the vendor,
S
technical risks, customers satisfaction, political stability and so on. In general, there are
many risks in the software engineering which is very difficult or impossible to identify all
of them. Some of most important risks in software engineering project are categorized as
software requirement risks, software cost risks, software scheduling risk, software quality
risks, and software business risks. These risks are explained detail below –

1. SOFTWARE REQUIREMENT RISKS

 Lack of analysis for change of requirements.
 Change extension of requirements
 Lack of report for requirements
 Poor definition of requirements
  Ambiguity of requirements
 Change of requirements
 Inadequate of requirements
 Impossible requirements
 Invalid requirements

2.SOFTWARE COST RISKS

 Lack of good estimation in projects
 Unrealistic schedule
 The hardware does not work well
 Human errors
 Lack of testing
 Lack of monitoring
 Complexity of architecture
 Large size of architecture
m
 Extension of requirements change
 The tools does not work well o
.c
 Personnel change, Management change, technology change, and environment
change
 Lack of reassessment of management cycle
a
3.SOFTWARE SCHEDULING RISKS
m
 Inadequate budget
a
 Change of requirements and extension of requirements
 Human errors
n
y
 Inadequate knowledge about tools and techniques
 Long-term training for personnel
d
 Lack of employment of manager experience

u
 Lack of enough skill

t
 Lack of good estimation in projects

S
4.SOFTWARE QUALITY RISKS
 Inadequate documentation
 Lack of project standard
 Lack of design documentation
 Inadequate budget
 Human errors
 Unrealistic schedule
 Extension of requirements change
 Poor definition of requirements
 Lack of enough skill
 Lack of testing and good estimation in projects
  Inadequate knowledge about techniques, programming language, tools, and so on

Strategies for Risk Management:

During the software development process various strategies for risk management could
be identified and defined according to the amount of risk influence. Based upon the
amount of risk influence in software development project, risk strategies could be divided
into three classes namely careful, typical, and flexible, careful risk management strategy is
projected for new and inexperienced organizations whose software development projects
are connected with new and unproven technology; typical risk management strategy is
well-defined as a support for mature organizations with experience in software
development projects and used technologies, but whose projects carry a decent number
of risks; and flexible risk management strategy is involved in experienced software
development organizations whose software development projects are officially defined
and based on proven technologies.

m
o
S.NO RGPV QUESTIONS Year Marks
Q.1 What do you mean by risk assessment? Explain JUNE 2012 10

.c
briefly

a
m
a
n
y
d
u
t
S
 UNIT – I
Topic:- Difference between user requirements and specifications

Unit-01/Lecture-09
Difference between user requirements and specifications

This is a blog post I wrote for the intranet at my previous workplace to help influence a
change in thinking in what constitutes requirements . Often, business will hand down It
must look like this and must work like this which significantly constrains the design and is
based on a lot of assumptions, competitors products and previous requirements. Plus it
short-circuits any knowledge of technology, trends and patterns that the design and
development team could have contributed.

m
USER REQUIREMENTS should detail what is needed by users; they should define the
problem, the space within which a solution can be designed.
o
.c
UI specifications detail a particular solution that can be implemented to meet the
identified requirements.
a
There should be a clear and traceable relationship between every element of a design and
the requirements.
m
a
The requirements and the specification can be in the same document but it should be
n
clear that the requirements are defined and accepted first and that they are fixed

y
whereas the solution specified is just one way that the requirements can be met.

d
Elements of a solution that cannot be traced back to a requirement indicate incomplete

u
requirements or surplus design.

t
The following words should typically not be used when discussing user requirements as

S
they refer to a user interface solution and confuse the purpose of a requirements
document, preempt solutions and constrain the design, possibly excluding the optimal
solution:

button, screen, panel, drop-down, list, scroll, click, tap, calendar, flip out, fold, animated,
swipe, heading, label, line, grid, table, row, column, select, drag and drop, window, resize,
right li k, e u, sort, ap, li k, widget, ox, i o , see, hear, tou h …

This is a confused user requirement:

A user can sort the table by any of the columns

Rather, the user requirement might be:

A user can opt to view the tabular data in ascending or descending order on any element
of the data

And the matching UI specification might be written (or committed straight to wireframes)
as:

In every cell of the header row will be two controls visible at all times, one for sorting the
relevant column in ascending order and one for descending order

m
REFERENCCE
o
.c
a
BOOK AUTHOR m PRIORITY

a
n
Software 1

y
Engineering P,S. Pressman

Software
d 2
Engineering
u Pankaj jalote

t
S
 1

UNIT-02
Measures, Metrics and Indicators
UNIT-02/LECTURE-01
Measures, Metrics and Indicators: : [RGPV/June 2014,2012(7),June 2011(5)]

Measure: Quantitative indication of the extent, amount, dimension, or size of some attribute of
a product or process. A single data point.
Metrics: The degree to which a system, component, or process possesses a given attribute.
Relates several measures (e.g. average number of errors found per person hour.)
Indicators: A combination of metrics that provides insight into the software process, project or
product.
m
o
Direct Metrics: Immediately measurable attributes (e.g. line of code, execution speed, defects

.c
reported).

a
Indirect Metrics: Aspects that are not immediately quantifiable (e.g. functionality, quantity,
reliability).
Faults: m
a
Errors: Faults found by the practitioners during software development.

n
Defects: Faults found by the customers after release.

y
d
u
t
S
 2

Process Metrics:-
Focus on quality achieved as a consequence of a repeatable or managed process. Strategic and
Long Term.
Statistical Software Process Improvement (SSPI). Error Categorization and Analysis:
 All errors and defects are categorized by origin
 The cost to correct each error and defect is recorded
 The number of errors and defects in each category is computed
 Data is analyzed to find categories that result in the highest cost to the organization
 Plans are developed to modify the process
Defect Removal Efficiency (DRE). Relationship between errors (E) and defects (D). The ideal is a
DRE of 1:

m
DRE=E/(E+D)

o
Project metrics:-

.c
Used by a project manager and software team to adapt project work flow and technical
activities. Tactical and Short Term.
Purpose: a

m
Minimize the development schedule by making the necessary adjustments to avoid
delays and mitigate problems.
a

n
Assess product quality on an ongoing basis.
Metrics:
y

d
Effort or time per SE task

u
Errors uncovered per review hour

t
Scheduled vs. actual milestone dates


S
Number of changes and their characteristics
Distribution of effort on SE tasks
Project metrics:-
 Focus on the quality of deliverables.
 Product metrics are combined across several projects to produce process metrics
Metrics for the product:
 Measures of the Analysis Model
 Complexity of the Design Model
1. Internal algorithmic complexity
 3

3. Data flow complexity

 Code metrics
Metrics Guideline:-
 Use common sense and organizational sensitivity when interpreting metrics data

 Provide regular feedback to the individuals and teams who have worked to collect
measures and metrics.
 Don’t use metrics to appraise individuals
 Work with practitioners and teams to set clear goals and metrics that will be used to
achieve them
 Never use metrics to threaten individuals or teams
 Metrics data that indicate a problem area should not be considered negative. These

m
data are merely an indicator for process improvement

o
Don’t obsess on a single metric to the exclusion of other important metrics

Normalization for Metrics

.c
•
a
How does an organization combine metrics that come from different individuals or

m
projects?

a
• Depend on the size and complexity of the project

n
• Normalization: compensate for complexity aspects particular to a product

y
• Normalization approaches:

d
 Size oriented (lines of code approach)

u
 Function oriented (function point approach)

t
Typical Normalized Metrics

• Size-Oriented:

 errors per KLOC (thousand lines of code), defects per KLOC, R per LOC, page of
documentation per KLOC, errors / person-month, LOC per person-month, R / page of
documentation
 4

• Function-Oriented:
 errors per FP, defects per FP, R per FP, pages of documentation per FP, FP per person-
month
Why Opt for FP Measures? : [RGPV/Jun 2014(7)]
• Independent of programming language. Some programming languages are more
compact, e.g. C++ vs. Assembler
• Use readily countable characteristics of the information domain of the problem
• Does not penalize inventive implementations that require fewer LOC than others
• Makes it easier to accommodate reuse and object-oriented approaches
• Original FP approach good for typical Information Systems applications (interaction
complexity)
•
m
Variants (Extended FP and 3D FP) more suitable for real-time and scientific software

o
(algorithm and state transition complexity)

.c
a
m
a
n
y
d
u
t
S
 5

Analyzing the Information Domain

weighting factor
measurement parameter count simple avg. complex
number of user inputs X 3 4 6 =
number of user outputs X 4 5 7 =
number of user inquiries X 3 4 6 =
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 =
count-total
complexity multiplier
m
function points o
.c
Taking Complexity into Account
•
a
Complexity Adjustment Values (F_i) are rated on a scale of 0 (not important) to 5 (very
important): m
a
1. Does the system require reliable backup and recovery?

n
2. Are data communications required?

y
3. Are there distributed processing functions?

d
4. Is performance critical?

u
5. System to be run in an existing, heavily utilized environment?

t
6. Does the system require on-line data entry?
S
7. On-line entry requires input over multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and instillation included in the design?
13. Multiple installations in different organizations?
14. Is the application designed to facilitate change and ease-of-use?
 6

Exercise: Function Points[RGPV/Jun 2013(7)]

• Compute the function point value for a project with the following information domain
characteristics:
Number of user inputs: 32
Number of user outputs: 60
Number of user enquiries: 24
Number of files: 8
Number of external interfaces: 2
Assume that weights are average and external complexity adjustment values are not
important.
Answer: 32*4+60*5+24*4+8*10+2*7

Example: SafeHome Functionality m

o
.c
Test Sensor
Password
Zone Setting Sensors

a
Zone Inquiry

User Sensor Inquiry SafeHome Messages

m
System User
Sensor Status
Panic Button

a
(De)activate (De)activate

n Monitor

y
Password, Alarm Alert and
Sensors, etc. Response

d
System
System

u
Config Data

t
S
 7

Example: SafeHome FP Calc

weighting factor
measurement parameter count simple avg. complex
number of user inputs 3 X 3 4 6 = 9

number of user outputs 2 X 4 5 7 = 8

number of user inquiries 2 X 3 4 6 = 6
number of files 1 X 7 10 15 = 7

number of ext.interfaces 4 X 5 7 10 = 22
count-total 52
complexity multiplier[0.65  0.01  F ]  [0.65  0.46]
i 1.11
function points 58

m
Exercise: Function Points
o
.c
• Compute the function point total for your project. Hint: The complexity adjustment values

a
should be low ( )
• Some appropriate complexity factors are (each scores 0-5):
1. Is performance critical?
m
a
2. Does the system require on-line data entry?

n
3. On-line entry requires input over multiple screens or operations?

y
4. Are the inputs, outputs, files, or inquiries complex?

d
5. Is the internal processing complex?

u
6. Is the code designed to be reusable?

t
7. Is the application designed to facilitate change and ease-of-use?

S
 8

RGPV QUESTION YEAR MARKS

S.NO
Q.1 What are the software metrics? June 2012 10
show why & how software
metrics can improve software
process.
Q.2 Write short notes on Software June 2011 5

metrics.
Q.3 Explain the need for software June 2014 7
measures & describe various
metrics
m
Q.4 Compute the function point value June 2013
o 7

.c
for a project with the following
information domain
characteristics: a
Number of user inputs: 32
m
a
Number of user outputs: 60

n
Number of user enquiries: 24

y
Number of files: 8
Number of external interfaces: 2

d
Assume that weights are average
and uexternal complexity

t
adjustment values are not

S
important.
 9

UNIT-02/LECTURE-02
OO Metrics: Distinguishing Characteristics
• The following characteristics require that special OO metrics be developed:
 Encapsulation — Concentrate on classes rather than functions
 Information hiding — An information hiding metric will provide an indication of
quality
 Inheritance — A pivotal indication of complexity
 Abstraction — Metrics need to measure a class at different levels of abstraction
and from different viewpoints
 Conclusion: the class is the fundamental unit of measurement
OO Project Metrics
• Number of Scenario Scripts (Use Cases):
m
o
 Number of use-cases is directly proportional the number of classes needed to

.c
meet requirements
 A strong indicator of program size
• Number of Key Classes (Class Diagram): a
m
 A key class focuses directly on the problem domain

a
NOT likely to be implemented via reuse

n
 Typically 20-40% of all classes are key, the rest support infrastructure (e.g. GUI,

y
communications, databases)
•
d
Number of Subsystems (Package Diagram):

u
 Provides insight into resource allocation, scheduling for parallel development and

t
overall integration effort
S
OO Analysis and Design Metrics
• Related to Analysis and Design Principles
• Complexity:
 Weighted Methods per Class (WMC): Assume that n methods with cyclomatic
complexity c ,c ……….cn are defined for a class C:
WMC   ci
 Depth of the Inheritance Tree (DIT): The maximum length from a leaf to the root
of the tree. Large DIT leads to greater design complexity but promotes reuse
 10

 Number of Children (NOC): Total number of children for each class. Large NOC
may dilute abstraction and increase testing

Further OOA&D Metrics[RGPV/Jun 2014(7)]

 Coupling:
 Coupling between Object Classes (COB): Total number of collaborations listed
for each class in CRC cards. Keep COB low because high values complicate
modification and testing
 Response for a Class (RFC): Set of methods potentially executed in response to a
message received by a class. High RFC implies test and design complexity
 Cohesion:

m
 Lack of Cohesion in Methods (LCOM): Number of methods in a class that access

o
one or more of the same attributes. High LCOM means tightly coupled methods

OO Testability Metrics .c
 Encapsulation: a
m
 Percent Public and Protected (PAP): Percentage of attributes that are public.

a
Public attributes can be inherited and accessed externally. High PAP means more
side effects
n
y
 Public Access to Data members (PAD): Number of classes that access another

d
classes attributes. Violates encapsulation

u
Inheritance:

t
 Number of Root Classes (NRC): Count of distinct class hierarchies. Must all be

S
tested separately
 Fan In (FIN): The number of superclasses associated with a class. FIN > 1
indicates multiple inheritance. Must be avoided
 Number of Children (NOC) and Depth of Inheritance Tree (DIT): Superclasses
need to be retested for each subclass
DRE  E /( E  D)

Quality Metrics
• Measures conformance to explicit requirements, following specified standards, satisfying
of implicit requirements
• Software quality can be difficult to measure and is often highly subjective
 11

• Correctness:
 The degree to which a program operates according to specification
 Metric = Defects per FP
2. Maintainability:
 The degree to which a program is amenable to change
 Metric = Mean Time to Change. Average time taken to analyze, design,
implement and distribute a change

Quality Metrics: Further Measures

3. Integrity:
 The degree to which a program is impervious to outside attack

m
 Summed over all types of security attacks, i, where t = threat (probability that an

o
attack of type i will occur within a given time) and s = security (probability that an

.c
attack of type i will be repelled)
4. Usability:
 The degree to which a program is easy to use. a
m
 Metric = (1) the skill required to learn the system, (2) the time required to

a
become moderately proficient, (3) the net increase in productivity, (4)

n
assessment of the users attitude to the system
 Covered in HCI course
y
d
u
t
S
 12

m
o
.c
a
Quality Metrics: Deriving McCall’s Quality Metrics
• Assess a set of quality factors on a scale of 0 (low) to 10 (high)
• m
Each of McCall’s Quality Metrics is a weighted sum of different quality factors
•
a
Weighting is determined by product requirements
• Example:
n
y
 Correctness = Completeness + Consistency + Traceability

d
 Completeness is the degree to which full implementation of required function

u
has been achieved

t
 Consistency is the use of uniform design and documentation techniques

S
 Traceability is the ability to trace program components back to analysis
 This technique depends on good objective evaluators because quality factor
scores can be subjective
Managing Variation
• How can we determine if metrics collected over a series of projects improve (or
degrade) as a consequence of improvements in the process rather than noise?
• Statistical Process Control:
 Analyzes the dispersion (variability) and location (moving average)
 Determine if metrics are:
 13

(b) Unstable (process exhibits out of control changes and metrics cannot be used to
predict changes)

Control Chart
6
Er, Errors found/ rev iew hour

1
m
0
o
.c
1 3 5 7 9 11 13 15 17 19

Project s
a
m
Compare sequences of metrics values against mean and standard deviation. E.g. metric is
unstable if eight consecutive values lie on one side of the mean.
a
n
S.NO
y
RGPV QUESTION YEAR MARKS
Q.1
d
Compute the function point JUNE 2013 7

u
value for a project with the

t
following:

S No of external inputs:32
No of external outputs:60
No of external inquiries:24
No of external interface files:2
No of internal logical files:8
Assume that all complexity
adjustment values are average.
Q.2 Discuss the impact of cohesion, JUNE 2014 7

coupling in design phases.

 14

UNIT-02/LECTURE-03
Software Reliability:
 Probability of failure-free operation for a specified time in a specified environment for a
given purpose
 This means quite different things depending on the system and the users of that system
 Informally, reliability is a measure of how well system users think it provides the services
they require.
Software reliability
 Cannot be defined objectively
• Reliability measurements which are quoted out of context are not meaningful
 Requires operational profile for its definition
•
m
The operational profile defines the expected pattern of software usage
 Must consider fault consequences
o
.c
• Not all faults are equally serious. System is perceived as more unreliable if there
are more serious faults
a
Failures and faults
m
a
 A failure corresponds to unexpected run-time behaviour observed by a user of the
software.
n
y
 A fault is a static software characteristic which causes a failure to occur.

d
 Faults need not necessarily cause failures. They only do so if the faulty part of the

u
software is used.

t
 If a user does not notice a failure, is it a failure? Remember most users don’t know

S
the software specification.
 15

Input/output mapping
Inputs causing
erroneous
Input set I outputs
e

Program

Erroneous
m
Output set Oe o
outputs

.c
Reliability improvement
a
m
 Reliability is improved when software faults which occur in the most frequently used
a
parts of the software are removed
n
 Removing x% of software faults will not necessarily lead to an x% reliability
improvement y
d
 In a study, removing 60% of software defects actually led to a 3% reliability
u
t
improvement

S
 Removing faults with serious consequences is the most important objective
 16

Reliability perception

Possible
inputs

User 1 Erroneous
inputs

User 3
User 2

m
o
.c
Reliability and formal methods a

m
The use of formal methods of development may lead to more reliable systems as it can

a
be proved that the system conforms to its specification

n
The development of a formal specification forces a detailed analysis of the system which

y
discovers anomalies and omissions in the specification

d
However, formal methods may not actually improve reliability

u
The specification may not reflect the real requirements of system users

t
A formal specification may hide problems because users don’t understand it


S
Program proofs usually contain errors
The proof may make assumptions about the system’s environment and use which are incorrect
Reliability and efficiency
 As reliability increases system efficiency tends to decrease
 To make a system more reliable, redundant code must be includes carrying out run-
time checks, etc. This tends to slow it down
 Reliability is usually more important than efficiency
 No need to utilise hardware to fullest extent ( erdvė) as computers are cheap and
fast
 Unreliable software isn’t used
 17

 Hard to improve unreliable systems

 Software failure costs often far exceed system
costs
 Costs of data loss are very high

Reliability metrics
 Hardware metrics not really suitable for software as they are based on component
failures and the need to repair or replace a component once it has failed. The design
is assumed to be correct.
 Software failures are always design failures. Often the system continues to be
available in spite of the fact that a failure has occurred.

m
 Probability of failure on demand

o
 This is a measure of the likelihood that the system will fail when a service

.c
request is made
 POFOD = 0.001 means 1 out of 1000 service requests result in failure
 a
Relevant for safety-critical or non-stop systems
 Rate of fault occurrence (ROCOF)
m

a
Frequency of occurrence of unexpected behaviour

n
ROCOF of 0.02 means 2 failures are likely in each 100 operational time units

y
Relevant for operating systems, transaction processing systems
 Mean time to failure
d
•
u
Measure of the time between observed failures
• t
MTTF of 500 means that the time between failures is 500 time units
• S
Relevant for systems with long transactions e.g. CAD systems
 Availability
• Measure of how likely the system is available for use. Takes
repair/restart time into account
• Availability of 0.998 means software is available for 998 out of 1000 time units
• Relevant for continuously running systems e.g. telephone switching systems

Reliability measurement
 Measure the number of system failures for a given number of system inputs
 18

o Used to compute POFOD

 Measure the time (or number of transactions) between system failures
o Used to compute ROCOF and MTTF
 Measure the time to restart after failure
o Used to compute AVAIL

m
o
.c
a
m
a
n
y
d
u
t
S
 19

UNIT-02/LECTURE-04

Reliability specification Reliability requirements are only rarely expressed in a quantitative,

verifiable way.
 To verify reliability metrics, an operational profile must be specified as part of the
test
plan.
 Reliability is dynamic – reliability specifications
related to the source code are meaningless.
• No more than N faults/1000 lines.
• This is only useful for a post-delivery process analysis.

m
COCOMO MODEL: [RGPV/JUNE 2014,2013,2011(7)]
o
.c
COCOMO, Constructive Cost Model is static single-variable model. Barry Boehm introduced
COCOMO models. There is a hierarchy of these models.
a
• The Constructive Cost Model (COCOMO) is the most widely used software estimation
model in the world. It
m
a
• The COCOMO model predicts the effort and duration of a project based on inputs
relating to the size of the resulting systems and a number of cost drives that affect
productivity.
n
Effort y
• Effort Equation
– d
PM = C * (KDSI)n (person-months)
u
• where PM = number of person-month (=152 working hours),

t
• C = a constant,

S
• KDSI = thousands of delivered source instructions (DSI) and
n = a constant.

Productivity

• Productivity equation
– (DSI) / (PM)
• where PM = number of person-month (=152 working hours),
• DSI = delivered source instructions

Schedule

• Schedule equation
– TDEV = C * (PM)n (months)
• where TDEV = number of months estimated for software development.
 20

Average Staffing

• Average Staffing Equation

– (PM) / (TDEV) (FSP)
• where FSP means Full-time-equivalent Software Personnel.

• COCOMO is defined in terms of three different models:

– the Basic model,
– the Intermediate model, and
– the Detailed model.
• The more complex models account for more factors that influence software projects,
and make more accurate estimates.

The Development mode

m
The most important factors contributing to a project’s duration and cost is the Development
Mode
o
.c
 Organic Mode: The project is developed in a familiar, stable environment, and the
product is similar to previously developed products. The product is relatively small, and

a
requires little innovation.
 Semidetached Mode: The project’s characteristics are intermediate between Organic

m
and Embedded
 Embedded Mode: The project is characterized by tight, inflexible constraints and

a
interface requirements. An embedded mode project will require a great deal of

n
innovation.

y
d
u Modes
t
Feature Organic Semidetached Embedded

S
Organizational Thorough Considerable General
understanding of
product and
objectives
Experience in Extensive Considerable Moderate
working with related
software systems

Need for software Basic Considerable Full

conformance with
pre-established
requirements

Need for software Basic Considerable Full

conformance with
external interface
specifications

SEG3300 A&B W2004 R.L. Probert 16

 21

Modes (.)
Feature Organic Semidetached Embedded

Concurrent Some Moderate Extensive

development of
associated new
hardware and
operational
procedures

Need for innovative Minimal Some Considerable

data processing
architectures,
algorithms
Premium on early Low Medium High
completion
Product size range <50 KDSI <300KDSI All

m
SEG3300 A&B W2004 R.L. Probert 17

o
.c
Cost Estimation Process

Cost=SizeOfTheProject x Productivity
a
m
Model 1: a
n
y
Basic COCOMO model is static single-valued model that computes software development effort
(and cost) as a function of program size expressed in estimated lines of code.

Model 2: d
u
t
Intermediate COCOMO model computes software development effort as a function of program

S
size and a set of cost drivers that include subjective assessments of product, hardware,
personnel, and project attributes.

Model 3:

Advanced COCOMO model incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step, like analysis, design, etc.

COCOMO can be applied to the following software project’s categories.

Organic mode:

These projects are very simple and have small team size. The team has a good application
experience work to a set of less than rigid requirements. A thermal analysis program developed
for a heat transfer group is an example of this.
 22

Semi-detached mode:

These are intermediate in size and complexity. Here the team has mixed experience to meet a
mix of rigid and less than rigid requirements. A transaction processing system with fixed
requirements for terminal hardware and database software is an example of this.

Embedded mode:

Software projects that must be developed within a set of tight hardware, software, and
operational constraints. For example, flight control software for aircraft.

The basic COCOMO model takes the form

m
where,

E is the effort applied in person-month,

o
.c
D is the development time in chronological month,
KLOC is the estimated number of delivered lines ( expressed in thousands ) of code for project,
The ab and cb and the exponents bb and db are given in the table below.
a
m
a
n
y
d
u
t
S
Basic COCOMO

The basic model is extended to consider a set of cost drivers attributes . These attributes can
be grouped together into four categories.

1. Product attributes

a) Required software reliability.

b) Complexity of the project.
c) Size of application database.
2. Hardware attributes

a) Run-time performance constraints.

b) Volatility of the virtual machine environment.
c) Required turnaround time.
 23

d) Memory constraints.
3. Personnel attribute

a) Analyst capability.
b) Software engineer capability.
c) Virtual machine experience.
d) Application experience.
e) Programming language experience.
4. Project attributes

a) Application of software engineering methods.

b) Use of software tools.
c) Required development schedule.

Each of the 15 attributes is rated on a 6-point scale that ranges from very low to very high
in importance or value. Based on the rating, an effort multiplier is determined from the tables
given by Boehm. The product of all multipliers results in an effort adjustment factor (EAF).
Typical values of EAF range from 0.9 to 1.4.
m
Example : Problem Statement same as LOC problem refer section 3.2.1
o
KLOC = 10.9
.c
a
E = ab (KLOC)exp(bb)
= 2.4(10.9)exp(1.05)

m
= 29.5 person-month

D = Cb(E)exp(db)
a
n
= 2.5(29.5)exp(.38)
= 9.04 months

y
d
The intermediate COCOMO model takes the following form.

u
E = ai(LOC)exp(bi) X EAF

Where, t
S
E is the effort applied in person-months,
LOC is the estimated number of delivered lines of code for the project.
The coefficient ai and the exponent bi are given in the table below.
 24

INTERMEDIATE COCOMO MODEL

Software project ai bi

organic 3.2 1.05

Semi-detached 3.0 1.12

embedded 2.8 1.20

COCOMO represents a comprehensive empirical model for software estimation. However,

Boehm’s own comments [BOE81] about COCOMO (and by extension all models) should be
heeded:

m
Today, a software cost estimation model is doing well if it can estimate software development

o
costs within 20% of actual costs, 70% of the time, and on its own turf (that is, within the class of

.c
projects to which it has been calibrated ... This is not as precise as we might like, but it is

a
accurate enough to provide a good deal of help in software engineering economic analysis and
decision making.

m
a
To illustrate the use of the COCOMO model, we apply the basic model to the CAD software

n
example [described in SEPA, 5/e]. Using the LOC estimate and the coefficients noted in Table

y
5.1, we use the basic model to get:
E = 2.4 (KLOC) 1.05
d
= 2.4 (33.2) 1.05
u
= 95 person-months t
S
This value is considerably higher than the estimates derived using LOC. Because the COCOMO
model assumes considerably lower LOC/pm levels than those discussed in SEPA, 5/e, the results
are not surprising. To be useful in the context of the example problem, the COCOMO model
would have to be recalibrated to the local environment.

To compute project duration , we use the effort estimate described above:

D = 2.5 E 0.35
= 2.5 (95) 0.35
= 12.3 months
 25

The value for project duration enables the planner to determine a recommended number of
people, N, for the project:
N = E/D
= 95/12.3
~ 8 people
In reality, the planner may decide to use only four people and extend the project duration
accordingly.

m
o
.c
a
m
a
n
y
d
u
t
S
 26

UNIT-02/LECTURE-05
Relation between LOC and FP:
• Relationship:
– LOC = Language Factor * FP
– where
• LOC (Lines of Code)
• FP (Function Points)

m
o
.c
a
m
Assuming LOC’s per FP for:
a
Java = 53,
n
C++ = 64
y
d
u
aKLOC = FP * LOC_per_FP / 1000

t
It means for the SpellChekcer Example: (Java)

S
LOC=52.25*53=2769.25 LOC or 2.76 KLOC

Effort Computation
• The Basic COCOMO model computes effort as a function of program size. The Basic
COCOMO equation is:
– E = aKLOC^b
•
• Effort for three modes of Basic COCOMO.
 27

Mode a b

Organic 2.4 1.05

Semi-detached 3.0 1.12

Embedded 3.6 1.20

Example

m
o
.c
a
m
• a
The intermediate COCOMO model computes effort as a function of program size and a
n
set of cost drivers. The Intermediate COCOMO equation is:
– E = aKLOC^b*EAF y
• d
Effort for three modes of intermediate COCOMO.
u
t
Mode
S a b

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20

 28

Effort Adjustment Factor

m
o
Total EAF = Product of the selected factors .c
a
m
Adjusted value of Effort: Adjusted Person Months:
APM = (Total EAF) * PM
a
n
y
d
u
t
S
 29

Software Development Time

Development Time Equation Parameter Table: m
o
Parameter Organic Semi- .c
Embedded
detacheda
C 2.5 m
2.5 2.5

a
n
D 0.38 0.35 0.32

y
Development Time,
d
TDEV = C * (APM **D)
Number of Personnel,
u NP = APM / TDEV

t
S
Distribution of Effort
• A development process typically consists of the following stages:
• - Requirements Analysis
• - Design (High Level + Detailed)
• - Implementation & Coding
• - Testing (Unit + Integration)

The following table gives the recommended percentage distribution of Effort (APM) and TDEV
for these stages:
 30

Percentage Distribution of Effort and Time Table:

• Calculate the estimated number of errors in your design, i.e.total errors found in
requirements, specifications, code, user manuals, and bad fixes:
– Adjust the Function Point calculated in step1
AFP = FP ** 1.25
– Use the following table for calculating error estimates
– m
o
.c
Error Type Error / AFP

a
Requirements 1

m
Design 1.25

Implementation 1.75
a
Documentation 0.6 n
y
d
Due to Bug Fixes 0.4

u
t
S
 31

m
o
S.NO RGPV QUESTION
.c
YEAR MARKS
Q.1 Explain
COCOMO model
in detail about
a
JUNE 2014,
2013,2012
7

m
a
n
y
d
u
t
S
 32

UNIT-02/LECTURE-06

COCOMOII:

Constructive Cost Model II (COCOMO® II) is a model that allows one to estimate the cost, effort,
and schedule when planning a new software development activity. COCOMO® II is the latest
major extension to the original COCOMO® (COCOMO® 81) model published in 1981. It consists
of three submodels, each one offering increased fidelity the further along one is in the project
planning and design process. Listed in increasing fidelity, these submodels are called the
Applications Composition, Early Design, and Post-architecture models.

COCOMO® II can be used for the following major decision situations

m

o
Making investment or other financial decisions involving a software development effort

.c
 Setting project budgets and schedules as a basis for planning and control
 Deciding on or negotiating tradeoffs among software cost, schedule, functionality,
performance or quality factors a

m
Making software cost and schedule risk management decisions

a
Deciding which parts of a software system to develop, reuse, lease, or purchase

n
Making legacy software inventory decisions: what parts to modify, phase out, outsource,
etc
y

d
Setting mixed investment strategies to improve organization’s software capability, via

u
reuse, tools, process maturity, outsourcing, etc
 t
Deciding how to implement a process improvement strategy, such as that provided in the SEI
CMM S
The original COCOMO® model was first published by Dr. Barry Boehm in 1981, and reflected the
software development practices of the day. In the ensuing decade and a half, software
development techniques changed dramatically. These changes included a move away from
mainframe overnight batch processing to desktop-based real-time turnaround; a greatly
increased emphasis on reusing existing software and building new systems using off-the-shelf
software components; and spending as much effort to design and manage the software
development process as was once spent creating the software product.
 33

These changes and others began to make applying the original COCOMO® model problematic.
The solution to the problem was to reinvent the model for the 1990s. After several years and
the combined efforts of USC-CSSE, ISR at UC Irvine, and the COCOMO® II Project Affiliate
Organizations, the result is COCOMO® II, a revised cost estimation model reflecting the changes
in professional software development practice that have come about since the 1970s. This new,
improved COCOMO® is now ready to assist professional software cost estimators for many years
to come.

About the Nomenclature

The original model published in 1981 went by the simple name of COCOMO®. This is an
acronym derived from the first two letters of each word in the longer phrase Constructive Cost

m
Model. The word constructive refers to the fact that the model helps an estimator better

o
understand the complexities of the software job to be done, and by its openness permits the

.c
estimator to know exactly why the model gives the estimate it does. Not surprisingly, the new
model (composed of all three submodels) was initially given the name COCOMO® 2.0. However,

a
after some confusion in how to designate subsequent releases of the software implementation

m
of the new model, the name was permanently changed to COCOMO® II. To further avoid

a
confusion, the original COCOMO® model was also then re-designated COCOMO® 81. All

n
references to COCOMO® found in books and literature published before 1995 refer to what is

y
now called COCOMO® 81. Most references to COCOMO® published from 1995 onward refer to

d
what is now called COCOMO® II.

u
t
If in examining a reference you are still unsure as to which model is being discussed, there are a

S
few obvious clues. If in the context of discussing COCOMO® these terms are used: Basic,
Intermediate, or Detailed for model names; Organic, Semidetached, or Embedded for
development mode, then the model being discussed is COCOMO® 81. However, if the model
names mentioned are Application Composition, Early Design, or Post-architecture; or if there is
mention of scale factors Precedentedness (PREC), Development Flexibility (FLEX),
Architecture/Risk Resolution (RESL), Team Cohesion (TEAM), or Process Maturity (PMAT), then
the model being discussed is COCOMO® II.

Reverse engineering :
Reverse engineering, the process of taking a software program’s binary code and recreating it
 34

so as to trace it back to the original source code, is being widely used in computer hardware and
software to enhance product features or fix certain bugs. For example, the programmer writes
the code in a high-level language such as C, C++ etc. (you can learn basic C programming with
this beginners course); as computers do not speak these languages, the code written in these
programming languages needs to be assembled in a format that is machine specific. In short,
the code written in high level language needs to be interpreted into low level or machine
language.

The process of converting the code written in high level language into a low level language
without changing the original program is known as reverse engineering. It’s similar to
disassembling the parts of a vehicle to understand the basic functioning of the machine and

m
internal parts etc. And thereafter making appropriate adjustments to give rise to a better

o
performing or superior vehicle.

.c
If we have a look at the subject of reverse engineering in the context of software engineering,

a
we will find that it is the practice of analyzing the software system to extract the actual design

m
and implementation information. A typical reverse engineering scenario would comprise of a

a
software module that has been worked on for years and carries the line of business in its code;

n
but the original source code might be lost, leaving the developers only with the binary code. In

y
such a case, reverse engineering skills would be used by software engineers to detect probable

d
virus and malware to eventually protect the intellectual property of the company. Learn more

u
protecting Intellectual Property in this course.

t
S
At the turn of the century, when the software world was hit by the technology crisis Y2K,
programmers weren’t equipped with reverse engineering skills. Since then, research has been
carried out to analyse what kind of development activities can be brought under the category of
reverse engineering so that they can be taught to the programmers. Researchers have revealed
that reverse engineering basically comes under two categories-software development and
software testing. A number of reverse engineering exercises have been developed since then in
this regard to provide baseline education in reversing the machine code.

Reverse Engineering
Reverse engineering can be applied to several aspects of the software and hardware
 35

development activities to convey different meanings. In general, it is defined as the process of

creating representations of systems at a higher level of abstraction and understanding the basic
working principle and structure of the systems under study. With the help of reverse
engineering, the software system that is under consideration can be examined thoroughly.
There are two types of reverse engineering; in the first type, the source code is available, but
high-level aspects of the program are no longer available. The efforts that are made to discover
the source code for the software that is being developed is known as reverse engineering. In the
second case, the source code for the software is no longer available; here, the process of
discovering the possible source code is known as reverse engineering. To avoid copyright
infringement, reverse engineering makes use of a technique called clean room design.

m
In the world of reverse engineering, we often hear about black box testing. Even though the

o
tester has an API, their ultimate goal is to find the bugs by hitting the product hard from

.c
outside. Learn more about different software testing techniques in this course.

a
Apart from this, the main purpose of reverse engineering is to audit the security, remove the

m
copy protection, customize the embedded systems, and include additional features without

a
spending much and other similar activities.

n
y
Where is Reverse Engineering Used?

d
Reverse engineering is used in a variety of fields such as software design, software testing,

u
programming etc.

t
S
In software design, reverse engineering enables the developer or programmer to add new
features to the existing software with or without knowing the source code. Different techniques
are used to incorporate new features into the existing software.
 Reverse engineering is also very beneficial in software testing, as most of the virus
programmers don’t leave behind instructions on how they wrote the code, what they
have set out to accomplish etc. Reverse engineering helps the testers to study the virus
and other malware code. The field of software testing, while very extensive, is also
interesting and requires vast experience to study and analyze virus code. Learn more
about software test design in this course.
 The third category where reverse engineering is widely used is in software security.
 36

Reverse engineering techniques are used to make sure that the system does not have
any major vulnerabilities and security flaws. The main purpose of reverse engineering is
to make the system robust so as to protect it from spywares and hackers. Infact, this can
be taken a step forward to Ethical hacking, whereby you try to hack your own system to
identify vulnerabilities. You can learn more about Ethical hacking with this course.

 While one needs a vast amount of knowledge to become a successful reverse engineer,
he or she can definitely have a lucrative career in this field by starting off with the basics.
It is highly suggested that you first become familiar with assembly level language and
gain significant amount of practical knowledge in the field of software designing and
testing to become a successful software engineer. Learn how to kick-start your career in

m
this interesting field by visiting our online course agile testing for reverse engineering

o
applications.

.c
Reverse Engineering Tools
a
As mentioned above, reverse engineering is the process of analyzing the software to determine
m
its components and their relationships. The process of reverse engineering is accomplished by
a
making use of some tools that are categorized into debuggers or disassemblers, hex editors,
monitoring and decompile tools: n
y
d
Disassemblers – A 36artridges36 is used to convert binary code into assembly code and also
u
t
used to extract strings, imported and exported functions, libraries etc. The disassemblers

S
convert the machine language into a user-friendly format. There are different dissemblers that
specialize in certain things.
Debuggers – This tool expands the functionality of a 36artridges36 by supporting the CPU
registers, the hex duping of the program, view of stack etc. Using debuggers, the programmers
can set breakpoints and edit the assembly code at run time. Debuggers analyse the binary in a
similar way as the disassemblers and allow the reverser to step through the code by running
one line at a time to investigate the results.
Hex Editors – These editors allow the binary to be viewed in the editor and change it as per the
requirements of the software. There are different types of hex editors available that are used
for different functions.
 37

PE and Resource Viewer – The binary code is designed to run on a windows based machine and
has a very specific data which tells how to set up and initialize a program. All the programs that
run on windows should have a portable executable that supports the DLLs the program needs to
borrow from.

Reverse engineering has developed significantly and taken a positive approach to creating
descriptive data set of the original object. Today, there are numerous legitimate applications of
reverse engineering. Due to the development of numerous digitizing devices, reverse
engineering software enables programmers to manipulate the data into a useful form. The kind
of applications in which reverse engineering is used ranges from mechanical to digital, each with
its own advantages and applications. Reverse engineering is also beneficial for business owners

m
as they can incorporate advanced features into their software to meet the demands of the

o
growing markets.

.c
S.NO RGPV QUESTION YEAR MARKS
Q.1 Write short note on Reverse June 2013 5
engineering? a
m
a
n
y
d
u
t
S
 38

UNIT-02/LECTURE-07
What is reverse engineering (RE)? : [RGPV/JUNE 2(5)]

Reverse Engineering (RE): disassemble or analyze in detail in order to discover concepts

involved in manufacture. – reverse engineer. The Merriam-Webster Dictionary, New ed. 2004.
Reverse engineering is the process of discovering the technological principles of a
mechanical application through analysis of its structure, function and operation. That involves
sometimes taking something apart and analyzing its workings in detail, usually with the
intention to construct a new device or program that does the same thing without actually
copying anything from the original.

m
5. What are some common uses for reverse engineering?

o
 As a learning tool.

.c
 As a way to make new compatible products that are cheaper than what’s currently on
the market.
 a
for making software interoperate more effectively or to bridge different operating
systems or databases.
m

a
To uncover the uncoordinated features of commercial products

n
.This kind of inquiry engages individuals in a constructive learning process about the operation

y
of systems and products. The process of taking something apart and revealing the way in which

d
it works is an effective way to learn how to build a technology or make improvements to it.

u
t
According to A Methodology for Reverse Engineering, reverse engineering consists of the


S
following steps:
Observe and assess the mechanisms that make the device work.
 Dissect and study the inner workings of a mechanical device.
 Compare the actual device to your observations and suggest improvement.

Through reverse engineering, a researcher can gather the technical data necessary for the
documentation of the operation of a technology or component of a system. When reverse
engineering software, researchers are able to examine the strength of systems and identify their
weaknesses in terms of performance, security, and interoperability. The reverse engineering
 39

process allows researchers to understand both how a program works and also what aspects of
the program contribute to its not working. Independent manufacturers can participate in a
competitive market that rewards the improvements made on dominant products. For example,
security audits, which allow users of software to better protect their systems and networks by
revealing security flaws, require reverse engineering. The creation of better designs and the
interoperability of existing products often begin with reverse engineering.

6. How is reverse engineering implemented legally?

There are two basic legalities associated with reverse engineering:

a. Copyright Protection – protects only the look and shape of a product.

b. Patent Protection – protects the the idea behind the functioning of a new product.
m
o
.c
According to npd-solutions a patent is no more than a warning sign to a competitor to
discourage competition. Also npd-solutions says that if there is merit in an idea, a competitor
will do one of the following:
a
 Negotiate a license to use the idea.
m

a
Claim that the idea is not novel and is an obvious step for anyone experienced in the

n
particular field.

y
Make a subtle change and claim that the changed product is not protected by patent.

d
u
Commonly, RE is performed using the clean-room or Chinese wall. Clean-room, reverse

t
engineering is conducted in a sequential manner:

S
A team of engineers are sent to disassemble the product to investigate and describe
what it does in as much detail as possible at a somewhat high level of abstraction.
 Description is given to another group who has no previous or current knowledge of the
product.
 Second party then builds product from the given description. This product might achieve
the same end effect but will probably have a different solution approach.

7. What are some legal cases and ethical issues involving reverse engineering?
New court cases reveal that reverse engineering practices which are used to achieve
interoperability with an 39artridges39ly created computer program, are legal and ethical. In
 40

December, 2002, Lexmark filed suit against SCC, accusing it of violating copyright law as well as
the DMCA. SCC reverse engineered the code contained in Lexmark printer 40artridge so that it
could manufacture compatible cartiges. According to Computerworld , Lexmark alleged that
SCC’s Smartek chips include Lexmark software that is protected by copyright. The software
handles communication between Lexmark printers and toner 40artridges; without it,
refurbished toner 40artridges won’t work with Lexmark’s printers. The court ruled that
copyright law shouldn’t be used to inhibit interoperability between one vendor’s products and
those of its rivals. In a ruling from the U.S. Copyright Office in October 2003, the Copyright
Office said the DMCA doesn’t block software developers from using reverse engineering to
access digitally protected copyright material if they do so to achieve interoperability with an
independently created computer program.

m
o
8. Is reverse engineering unethical?

.c
This issue is largely debated and does not seem to have a clear cut answer. The number one
argument against reverse engineering is that of intellectual property. If an individual or an

a
organization produces a product or idea, is it ok for others to disassemble the product in order

m
to discover the inner workings? Lexmark does not think so. Since Lexmark and companies like

a
them spend time and money to develop products, they find it unethical that others can reverse

n
engineer their products. There are also products like Bit Keeper that have been hurt by reverse

y
engineering practices. Why should companies and individuals spend major resources to gather

d
intellectual property that may be reversed engineered by competitors at a fraction of the cost?

u
t
There are also benefits to reverse engineering. Reverse engineering might be used as a way to

S
allow products to interoperate. Also reverse engineering can be used as a check so that
computer software isn’t performing harmful, unethical, or illegal activities.

S.NO RGPV QUESTION YEAR MARKS

Q.1 Write short note on Reverse June.2013 5
engineering.
 41

UNIT-02/LECTURE-08
Project Scheduling

Overview

The chapter describes the process of building and monitoring schedules for software
development projects. To build complex software systems, many engineering tasks need to
occur in parallel with one another to complete the project on time. The output from one task
often determines when another may begin. Software engineers need to build activity networks
that take these task interdependencies into account. Managers find that it is difficult to ensure
that a team is working on the most appropriate tasks without building a detailed schedule and
sticking to it. This requires that tasks are assigned to people, milestones are created, resources
are allocated for each task, and progress is tracked.

Root Causes for Late Software

m
 Unrealistic deadline established outside the team
 Changing customer requirements not reflected in schedule changes
 Underestimating the resources required to complete the project
o
.c
 Risks that were not considered when project began
 Technical difficulties that complete not have been predicted in advance

a
 Human difficulties that complete not have been predicted in advance
 Miscommunication among project staff resulting in delays

m
 Failure by project management to recognize project failing behind schedule and failure to

a
take corrective action to correct problems

n
How to Deal With Unrealistic Schedule Demands
y
1. Perform a detailed project estimate for project effort and duration using historical data.

d
2. Use an incremental process model that will deliver critical functionality imposed by
deadline, but delay other requested functionality.
u
3. Meet with the customer and explain why the deadline is unrealistic using your estimates

t
based on prior team performance.

S
4. Offer an incremental development and delivery strategy as an alternative to increasing
resources or allowing the schedule to slip beyond the deadline.

Project Scheduling Perspectives

 Project scheduling is an activity that distributes estimated effort across the planned project
duration by allocating the effort to specific software engineering tasks.
 One view is that the end-date for the software release is set externally and that the software
organization is constrained to distribute effort in the prescribed time frame.
 Another view is that the rough chronological bounds have been discussed by the developers
and customers, but the end-date is best set by the developer after carefully considering how
to best use the resources needed to meet the customer’s needs.
 Schedules evolve over time as the first macroscopic schedules is refined into the detailed
schedule for each planned software increment.
 42

Software Project Scheduling Principles

 Compartmentalization – the product and process must be decomposed into a manageable
number of activities and tasks
 Interdependency – tasks that can be completed in parallel must be separated from those
that must completed serially
 Time allocation – every task has start and completion dates that take the task
interdependencies into account
 Effort validation – project manager must ensure that on any given day there are enough
staff members assigned to completed the tasks within the time estimated in the project plan
 Defined Responsibilities – every scheduled task needs to be assigned to a specific team
member
 Defined outcomes – every task in the schedule needs to have a defined outcome (usually a
work product or deliverable)
 Defined milestones – a milestone is accomplished when one or more work products from an
engineering task have passed quality review

m
o
Relationship Between People and Effort : [RGPV/JUNE 2013 (7)]


.c
Adding people to a project after it is behind schedule often causes the schedule to slip

a
further
 The relationship between the number of people on a project and overall productivity is not

m
linear (e.g. 3 people do not produce 3 times the work of 1 person, if the people have to
work in cooperation with one another)

a
The main reasons for using more than 1 person on a project are to get the job done more

n
rapidly and to improve software quality.

y
d
Project Effort Distribution
 The 40-20-40 rule:

u
o 40% front-end analysis and design
o 20% coding
t
S
o 40% back-end testing
 Generally accepted guidelines are:
o 02-03 % planning
o 10-25 % requirements analysis
o 20-25 % design
o 15-20 % coding
o 30-40 % testing and debugging

Software Project Types

1. Concept development – initiated to explore new business concept or new application of
technology
2. New application development – new product requested by customer
3. Application enhancement – major modifications to function, performance, or interfaces
(observable to user)
 43

immediately obvious to user)

5. Reengineering – rebuilding all (or part) of a legacy system

Factors Affecting Task Set

 Size of project
 Number of potential users
 Mission criticality
 Application longevity
 Requirement stability
 Ease of customer/developer communication
 Maturity of applicable technology
 Performance constraints
 Embedded/non-embedded characteristics
 Project staffing
 Reengineering factors

m
Concept Development Tasks
 Concept scoping – determine overall project scope o
.c
 Preliminary concept planning – establishes development team’s ability to undertake the
proposed work
a
 Technology risk assessment – evaluates the risk associated with the technology implied by
the software scope
m
 Proof of concept – demonstrates the feasibility of the technology in the software context

a
 Concept implementation – concept represented in a form that can be used to sell it to the
customer
n
 Customer reaction to concept – solicits feedback on new technology from customer

y
Scheduling
d
u
 Task networks (activity networks) are graphic representations can be of the task

t
interdependencies and can help define a rough schedule for particular project
 Scheduling tools should be used to schedule any non-trivial project.
S
 Program evaluation and review technique (PERT) and critical path method (CPM) ) are
quantitative techniques that allow software planners to identify the chain of dependent
tasks in the project work breakdown structure (WBS) that determine the project duration
time.
 Timeline (Gantt) charts enable software planners to determine what tasks will be need to be
conducted at a given point in time (based on estimates for effort, start time, and duration
for each task).
 The best indicator of progress is the completion and successful review of a defined software
work product.
 Time-boxing is the practice of deciding a priori the fixed amount of time that can be spent
on each task. When the task’s time limit is exceeded, development moves on to the next
task (with the hope that a majority of the critical work was completed before time ran out).
 44

 Periodic project status meetings with each team member reporting progress and problems
 Evaluation of results of all work product reviews
 Comparing actual milestone completion dates to scheduled dates
 Comparing actual project task start-dates to scheduled start-dates
 Informal meeting with practitioners to have them asses subjectively progress to date and
future problems
 Use earned value analysis to assess progress quantitatively

Tracking Increment Progress for OO Projects

 Technical milestone: OO analysis complete
o All hierarchy classes defined and reviewed
o Class attributes and operations are defined and reviewed
o Class relationships defined and reviewed
o Behavioral model defined and reviewed
o Reusable classed identified
 Technical milestone: OO design complete
o Subsystems defined and reviewed
m
o Classes allocated to subsystems and reviewed
o Task allocation has been established and reviewed o
.c
o Responsibilities and collaborations have been identified
o Attributes and operations have been designed and reviewed
o Communication model has been created and reviewed
 Technical milestone: OO programming complete a
m
o Each new design model class has been implemented

a
o Classes extracted from the reuse library have been implemented
o Prototype or increment has been built

n
 Technical milestone: OO testing complete

y
o The correctness and completeness of the OOA and OOD models has been reviewed
o Class-responsibility-collaboration network has been developed and reviewed

d
o Test cases are designed and class-level tests have been conducted for each class

u
o Test cases are designed, cluster testing is completed, and classes have been
integrated
t
o System level tests are complete

S
WebApp Project Scheduling
 During the first iteration a macroscopic is developed by allocating effort to specific tasks (it
is understood that this is changeable schedule)
 The project is broken up into increments and the increments are refined in to detailed
schedules as each is begun (some increments may be developed in parallel)
 Each task on the task list for each increment is adapted in one of four ways as its detailed
schedule is created
o task is applied as is
o task is eliminated because it is not necessary for the increment
o new (custom) task is added
o task is refined (elaborated) into a number of named subtasks that each becomes part of
the schedule
 This process continues until each planned increment is completed
 45

Earned Value Analysis

 Earned value is a quantitative measure given to each task as a percent of project completed
so far.
1. The total hours to complete each project task are estimated (BCWS – budgeted cost of
work scheduled)
2. The effort to complete the project is computed by summing the effort to complete each
task (BAC – budget at completion)
3. Each task is given an earned value based on its estimated percentage contribution to the
total (BCWP – budgeted cost of work completed).
 It is compute the actual cost of work performed (ACWP) at any point in the project and to
compute progress indicators for both schedule and costs based on these measures

S.NO RGPV QUESTION YEAR MARKS

Q.1 What is the role of effort JUNE 2013 m 7
estimation in a project & why is o
it important to do this
.c
estimation early?
a
m
Q.2 Explain problem based JUNE 2013 10

a
estimation technique.

n
y
d
u
t
S
 46

UNIT-02/LECTURE-09
Project Scheduling (Basic Principles): [RGPV/JUNE 20113(5)]

Software project scheduling is an activity that distributes estimated effort across the planed
project duration by allocating the effort to specific software engineering tasks.
First, a macroscopic schedule is developed.
---> a detailed schedule is redefined for each entry in the macroscopic schedule.
A schedule evolves over time.
Basic principles guide software project scheduling:
- Compartmentalization
- Interdependency

m
- Time allocation

o
- Effort allocation

.c
- Effort validation
- Defined responsibilities
- Defined outcomes a
- Defined milestones
m
a
Defining A Task Set For The Software Project

n
There is no single set of tasks that is appropriate for all projects.

y
An effective software process should define a collection of task sets, each

d
designed to meet the needs of different types of projects.

u
A task set is a collection of software engineering work

t
-> tasks, milestones, and deliverables.

S
Tasks sets are designed to accommodate different types of projects and different degrees of
rigor.
Typical project types:
- Concept Development Projects
- New Application Development Projects
- Application Enhancement Projects
- Application Maintenance Projects
- Reengineering Projects
Obtaining Information
Degree of Rigor:
 47

- Casual
- Structured
- Strict
- Quick Reaction
Defining Adaptation Criteria:
-- This is used to determine the recommended degree of rigor.
Eleven criteria are defined for software projects:
- Size of the project
- Number of potential users
- Mission criticality
- Application longevity

m
- Ease of customer/developer communication

o
- Maturity of applicable technology

.c
- Performance constraints
- Embedded/non-embedded characteristics
- Project staffing
a
- Reengineering factors
m
a
Defining A Task Network

n
y
Defining A Task Network

d
Individual tasks and subtasks have interdependencies based on their sequence.

u
A task network is a graphic representation of the task flow for a project.

t
Figure 7.3 shows a schematic network for a concept development project.

S
Critical path:
-- the tasks on a critical path must be completed on schedule to make the whole
project on schedule.

T7 T8

T1 T2 T3 T4

T5 T6
 48

Scheduling of a software project does not differ greatly from scheduling of any multitask
engineering effort.
Two project scheduling methods:
- Program Evaluation and Review Technique (PERT)
- Critical Path Method (CPM)
Both methods are driven by information developed in earlier project planning activities:
- Estimates of effort
- A decomposition of product function
- The selection of the appropriate process model
- The selection of project type and task set

m
Both methods allow a planer to do:

o
- determine the critical path

.c
- time estimation
- calculate boundary times for each task
Boundary times:
a
m
- the earliest time and latest time to begin a task

a
- the earliest time and latest time to complete a task

n
- the total float.

y
d
u
t
S
 49

Timeline Charts (Gantt charts)

Work tasks Week 1 Week 2

Task 1
Sub-task 1.1
Sub-task 1.2
Sub-task 1.3

Task 2
Sub-task 2.1
Sub-task 2.2

Task 3
Sub-task 3.1
Sub-task 3.2 m
o
.c
Task 4
Sub-task 4.1
Sub-task 4.2

a
Sub-task 4.3

m
Task 5
Sub-task 5.1

a
Sub-task 5.2

n
y
d
u
t
Tracking the Schedule

S
The project schedule provides a road map for a software project manager.
It defines the tasks and milestones.
Several ways to track a project schedule:
- conducting periodic project status meeting
- evaluating the review results in the software process
- determine if formal project milestones have been accomplished (Figure 7.4)
- compare actual start date to planned start date for each task
- informal meeting with practitioners
Project manager takes the control of the schedule in the aspects of:
- project staffing
 50

- project problems
- project resources
- reviews
- project budget

The Project Plan

The software project plan is a relatively brief document that is addressed to a diverse audience.
It must consists the following:
- communication scope, resources, staffing, and customer
- define risks and risk management techniques
- define cost and schedule for management review

m
- provide an overall approach to software development

o
- outline how quality will be ensured and change will be managed.

.c
The plan concentrates on a general statement of what and a specific statement of how much
and how long.
The purpose of a project plan is:
a
m
-> help establish the viability of the software development effort.

a
The project plan need not be a lengthy and complex document .

n
y
S.NO RGPV QUESTION YEAR MARKS

d
Q.1 Write short note on task June 2011 5

u
scheduling with an example.

t
S
REFERENCCE

BOOK AUTHOR PRIORITY

Software 1
Engineering P,S. Pressman
Software 2
Engineering Pankaj jalote
 51

m
o
.c
a
m
a
n
y
d
u
t
S
 1

UNIT-03
Coding Standard & Guideline
UNIT-03/LECTURE-01
Programming Standards and Procedures: [RGPV/June 2014(7)]
• Standards for you
– methods of code documentation
• Standards for others
– Integrators, maintainers, testers
– Prologue documentation
– Automated tools to identify dependencies
• Matching design with implementation
m
o
– Low coupling, high cohesion, well-defined interfaces

.c
• Allow flexibility to be creative and evolve product s details in stages
• Flexibility does not preclude standards
a
Programming Guidelines
m
Control Structures
a
• Make the code easy to read
n
y
• Build the program from modular blocks

d
• Make the code not too specific, and not too general

u
• Use parameter names and comments to exhibit coupling among components

t
• Make the dependency among components visible

S
Example of Control Structures
• Control skips around among the program s statements
benefit = minimum;
if (age < 75) goto A;
benefit = maximum;
goto C;
if (AGE < 65) goto B;
if (AGE < 55) goto C;
 2

A: if (AGE < 65) goto B;

benefit = benefit * 1.5 + bonus;
goto C;
B: if (age < 55) goto C;
benefit = benefit * 1.5;
C: next statement
• Rearrange the code
if (age < 55) benefit = minimum;
elseif (AGE < 65) benefit = minimum + bonus;
elseif (AGE < 75) benefit = minimum * 1.5 + bonus;
else benefit = maximum;

m
o
Programming Guidelines

.c
Algorithms
• Common objective and concern: performance (speed)
• Efficiency may have hidden costs a
– cost to write the code faster
m
– cost to test the code
a
– cost to understand the code
n
– y
cost to modify the code

d
Programming Guidelines u
Data Structures t
S
• Several techniques that used the structure of data to organize the program
– keeping the program simple
– using a data structure to determine a program structure
Programming Guidelines
Keep the Program Simple
Example: Determining Federal Income Tax
1. For the first $10,000 of income, the tax is 10%
2. For the next $10,000 of income above $10,000, the tax is 12 percent
3. For the next $10,000 of income above $20,000, the tax is 15 percent
 3

4. For the next $10,000 of income above $30,000, the tax is 18 percent
5. For any income above $40,000, the tax is 20 percent
tax = 0.
if (taxable_income == 0) goto EXIT;
if (taxable_income > 10000) tax = tax + 1000;
else{
tax = tax + .10*taxable_income;
goto EXIT;
}
if (taxable_income > 20000) tax = tax + 1200;
else{

m
tax = tax + .12*(taxable_income-10000):

o
goto EXIT;

.c
}
if (taxable_income > 30000) tax = tax + 1500;
else{
a
tax = tax + .15*(taxable_income-20000);
m
a
goto EXIT;

n
}

y
if (taxable_income < 40000){

d
tax = tax + .18*(taxable_income-30000);

u
goto EXIT;
}
t
else
S
tax = tax + 1800. + .20*(taxable_income-40000);

• Define a tax table for each bracket of tax liability

•
 4

• Simplified algorithm
for (int i=2; level=1; i <= 5; i++)
if (taxable_icome > bracket[i])
level = level + 1;
tax= base[level]+percent[level] * (taxable_income - bracket[level]);

Programming Guidelines
Data Structures Example: Rooted Tree
• Recursive data structure
• Graph composed of nodes and lines
– Exactly one node as root
–
m
If the lines emanating from the root are erased, the resulting graph is a rooted
tree
o
.c
a
m
a
n
y
d
u
t
S
 5

m
o
.c
a
m
a
n
y
d
u
t
S
 6

UNIT-03/LECTURE-02
Programming Guidelines
General Guidelines to Preserve Quality: [RGPV/Jun 2012,2011(10)]
• Localize input and output
• Employ pseudocode
• Revise and rewrite, rather than patch
• Reuse
– Producer reuse: create components designed to be reused in future applications
– Consumer reuse: reuse components initially developed for other projects
Programming Guidelines
Consumer Reuse
• Four key characteristics to check about components to reuse m
– o
does the component perform the function or provide the data needed?
–
.c
is it less modification than building the component from scratch?
– is the component well-documented?
a
–
m
is there a complete record of the component s test and revision history?
Programming Guidelines
a
n
Producer Reuse

y
• Several issues to keep in mind
–
d
make the components general
–
u
separate dependencies (to isolate sections likely to change)
–
t
keep the component interface general and well-defined
– S
include information about any faults found and fixed
– use clear naming conventions
– document data structures and algorithms
– keep the communication and error-handling sections separate and easy to
modify
• Reuse Council
– Created inventory of components
– Formed matrix with the features of all past and planned projects
– Met every week to make component selections, inspect design documentation,
 7

and monitor levels of reuse

Documentation
• Internal documentation
– header comment block
– meaningful variable names and statement labels
– other program comments
– format to enhance understanding
– document data (data dictionary)
• External documentation
– describe the problem
– describe the algorithm
• What is the component called m
• Who wrote the component o
• Where the component fits in the general system design
.c
• When the component was written and revised
a
• Why the component exists
m
a
• How the component uses its data structures, algorithms, and control

n
The Programming Process
y
d
Programming as Problem-Solving

u
• Polya s (1957) four distinct stages of finding a good solution
–
t
understanding the problem
– S
devising plan
– carrying out the plan
– looking back
• Two types of participants
– customers: who define the features using stories, describe detailed tests and
assign priorities
– programmers: who implement the stories
 8

UNIT-03/LECTURE-03

Software Requirement Specification: [RGPV/June2014,2012(7,10)]

There are many good definitions of System and Software Requirements Specifications that will
provide us a good basis upon which we can both define a great specification and help us
identify deficiencies in our past efforts. There is also a lot of great stuff on the web about
writing good specifications. The problem is not lack of knowledge about how to create a
correctly formatted specification or even what should go into the specification. The problem is
that we don't follow the definitions out there.

We have to keep in mind that the goal is not to create great specifications but to create great
products and great software. Can you create a great product without a great specification?
Absolutely! You can also make your first million through the lottery – but why take your
chances? Systems and software these days are so complex that to embark on the design before

m
knowing what you are going to build is foolish and risky.

o
The IEEE (www.ieee.org) is an excellent source for definitions of System and Software

.c
Specifications. As designers of real-time, embedded system software, we use IEEE STD 830-
1998 as the basis for all of our Software Specifications unless specifically requested by our

a
clients. Essential to having a great Software Specification is having a great System Specification.
The equivalent IEEE standard for that is IEEE STD 1233-1998. However, for most purposes in

m
smaller systems, the same templates can be used for both.

a
What are the benefits of a Great SRS?
n
y
The IEEE 830 standard defines the benefits of a good SRS:

d
Establish the basis for agreement between the customers and the suppliers on what the
u
software product is to do. The complete description of the functions to be performed by the

t
software specified in the SRS will assist the potential users to determine if the software

S
specified meets their needs or how the software must be modified to meet their needs. [NOTE:
We use it as the basis of our contract with our clients all the time].

Reduce the development effort. The preparation of the SRS forces the various concerned
groups in the customer s organization to consider rigorously all of the requirements before
design begins and reduces later redesign, recoding, and retesting. Careful review of the
requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in
the development cycle when these problems are easier to correct.

Provide a basis for estimating costs and schedules. The description of the product to be
developed as given in the SRS is a realistic basis for estimating project costs and can be used to
obtain approval for bids or price estimates. [NOTE: Again, we use the SRS as the basis for our
fixed price estimates]

Provide a baseline for validation and verification. Organizations can develop their validation and
 9

contract, the SRS provides a baseline against which compliance can be measured. [NOTE: We
use the SRS to create the Test Plan].

Facilitate transfer.The SRS makes it easier to transfer the software product to new users or new
machines. Customers thus find it easier to transfer the software to other parts of their
organization, and suppliers find it easier to transfer it to new customers.

Serve as a basis for enhancement. Because the SRS discusses the product but not the project
that developed it, the SRS serves as a basis for later enhancement of the finished product. The
SRS may need to be altered, but it does provide a foundation for continued production
evaluation. [NOTE: This is often a major pitfall – when the SRS is not continually updated with
changes]

What should the SRS address?

m
Again from the IEEE standard:

The basic issues that the SRS writer(s) shall address are the following:
o
a) Functionality. What is the software supposed to do?
.c
a
b) External interfaces. How does the software interact with people, the system s
hardware, other hardware, and other software?

m
c) Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?

a
d) Attributes. What is the portability, correctness, maintainability, security, etc.
considerations?
n
e) Design constraints imposed on an implementation. Are there any required standards

y
in effect, implementation language, policies for database integrity, resource limits,
operating environment(s) etc.?
d
u
t
What are the characteristics of a great SRS?

S
Again from the IEEE standard:

An SRS should be

a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
 10

Correct - This is like motherhood and apple pie. Of course you want the specification to be
correct. No one writes a specification that they know is incorrect. We like to say - "Correct and
Ever Correcting." The discipline is keeping the specification up to date when you find things that
are not correct.

Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has
only one interpretation. Again, easier said than done. Spending time on this area prior to
releasing the SRS can be a waste of time. But as you find ambiguities - fix them.

Complete - A simple judge of this is that is should be all that is needed by the software
designers to create the software.

Consistent - The SRS should be consistent within itself and consistent to its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in

m
another.

o
Ranked for Importance - Very often a new system has requirements that are really marketing

.c
wish lists. Some may not be achievable. It is useful provide this information in the SRS.

a
Verifiable - Don't put in requirements like - "It should provide the user a fast response."
Another of my favorites is - "The system should never crash." Instead, provide a quantitative

m
requirement like: "Every key stroke should provide a user response within 100 milliseconds."

a
Modifiable - Having the same requirement in more than one place may not be wrong - but
tends to make the document not maintainable.
n
y
Traceable - Often, this is not important in a non-politicized environment. However, in most
organizations, it is sometimes useful to connect the requirements in the SRS to a higher level
d
document. Why do we need this requirement?

u
t
S
What is the difference between a System Specification and a Software Specification?

Very often we find that companies do not understand the difference between a System
specification and a Software Specification. Important issues are not defined up front and
Mechanical, Electronic and Software designers do not really know what their requirements are.

The following is a high level list of requirements that should be addressed in a System
Specification:

 Define the functions of the system

 Define the Hardware / Software Functional Partitioning
 Define the Performance Specification
 Define the Hardware / Software Performance Partitioning
 Define Safety Requirements
 Define the User Interface (A good user s manual is often an overlooked part of the
 11

System specification. Many of our customers haven t even considered that this is the
right time to write the user s manual.)
 Provide Installation Drawings/Instructions.
 Provide Interface Control Drawings (ICD s, External I/O)

One job of the System specification is to define the full functionality of the system. In many
systems we work on, some functionality is performed in hardware and some in software. It is
the job of the System specification to define the full functionality and like the performance
requirements, to set in motion the trade-offs and preliminary design studies to allocate these
functions to the different disciplines (mechanical, electrical, software).

Another function of the System specification is to specify performance. For example, if the
System is required to move a mechanism to a particular position accurate to a repeatability of ±
1 millimeter that is a System s requirement. Some portion of that repeatability specification will
belong to the mechanical hardware, some to the servo amplifier and electronics and some to
the software. It is the job of the System specification to provide that requirement and to set in
motion the partitioning between mechanical hardware, electronics, and software. Very often

m
the System specification will leave this partitioning until later when you learn more about the
system and certain factors are traded off (For example, if we do this in software we would need
o
to run the processor clock at 40 mHz. However, if we did this function in hardware, we could

.c
run the processor clock at 12 mHz). [This implies that a certain level of research or even
prototyping and benchmarking needs to be done to create a System spec. I think it is useful to

a
say that explicitly.]

m
However, for all practical purposes, most of the systems we are involved with in small to
medium size companies, combine the software and the systems documents. This is done

a
primarily because most of the complexity is in the software. When the hardware is used to

n
meet a functional requirement, it often is something that the software wants to be well
documented. Very often, the software is called upon to meet the system requirement with the

y
hardware you have. Very often, there is not a systems department to drive the project and the

d
software engineers become the systems engineers. For small projects, this is workable even if
not ideal. In this case, the specification should make clear which requirements are software,

u
which are hardware, and which are mechanical.

t
S
What is the difference between a design requirement and software requirement?
[RGPV/June 2011(10)

In short, the SRS should not include any design requirements. However, this is a difficult
discipline. For example, because of the partitioning and the particular RTOS you are using, and
the particular hardware you are using, you may require that no task use more than 1 ms of
processing prior to releasing control back to the RTOS. Although that may be a true
requirement and it involves software and should be tested – it is truly a design requirement and
should be included in the Software Design Document or in the Source code.

Consider the target audience for each specification to identify what goes into what documents.
 12

Marketing/Product Management

Creates a product specification and gives it to Systems. It should define everything Systems
needs to specify the product

Systems

Creates a System Specification and gives it to Systems/Software and Mechanical and Electrical
Design.

Systems/Software

Creates a Software Specification and gives it to Software. It should define everything Software
needs to develop the software.

Thus, the SRS should define everything explicitly or (preferably) by reference that software
needs to develop the software. References should include the version number of the target

m
document. Also, consider using master document tools which allow you to include other
documents and easily access the full requirements.

o
.c
a
Is this do-able? Won’t we miss our deadlines if we take the time to do this?

This is a great question. There is no question that there is balance in this process. We have seen
m
companies and individuals go overboard on documenting software that doesn t need to be

a
documented, such as a temporary utility. We have also seen customers kill good products by
spending too much time specifying it.
n
y
However, the bigger problem is at the other end of the spectrum. We have found that taking
the time up front pays dividends down stream. If you don t have time to specify it up front, you
d
probably don t have the time to do the project.

u
Here are some of our guidelines:
t

S
Spend time specifying and documenting well software that you plan to keep.

 Keep documentation to a minimum when the software will only be used for a short time
or has a limited number of users.

 Have separate individuals write the specifications (not the individual who will write the
code).
 13

 The person to write the specification should have good communication skills.

 Pretty diagrams can help but often tables and charts are easier to maintain and can
communicate the same requirements.

 Take your time with complicated requirements. Vagueness in those areas will come back
to bite you later.

 Conversely, watch out for over-documenting those functions that are well understood by
many people but for which you can create some great requirements.

m
 Keep the SRS up to date as you make changes.
o
.c

a
Approximately 20-25% of the project time should be allocated to requirements
definition.
m
a

n
Keep 5% of the project time for updating the requirements after the design has begun.

y
d
u
 Test the requirements document by using it as the basis for writing the test plan.

t
S
Feasibility Study: [RGPV/June 2012(10)]
Feasibility is defined as the practical extent to which a project can be performed successfully. To
evaluate feasibility, a feasibility study is performed, which determines whether the solution
considered to accomplish the requirements is practical and workable in the software.
Information such as resource availability, cost estimation for software development, benefits of
the software to the organization after it is developed and cost to be incurred on its maintenance
are considered during the feasibility study. The objective of the feasibility study is to establish
the reasons for developing the software that is acceptable to users, adaptable to change and
conformable to established standards. Various other objectives of feasibility study are listed
below.
 14

 To analyze whether the software will meet organizational requirements

 To determine whether the software can be implemented using the current technology and
within the specified budget and schedule

 To determine whether the software can be integrated with other existing software.

m
o
.c
a
m
a
n
y
d
u
t
S
Feasibility Study Process
Feasibility study comprises the following steps.

1. Information assessment: Identifies information about whether the system helps in achieving
the objectives of the organization. It also verifies that the system can be implemented using
new technology and within the budget and whether the system can be integrated with the
existing system.
2. Information collection: Specifies the sources from where information about software can be
obtained. Generally, these sources include users (who will operate the software), organization
(where the software will be used), and the software development team (which understands
user requirements and knows how to fulfil them in software).
3. Report writing: Uses a feasibility report, which is the conclusion of the feasibility study by the
 15

software development team. It includes the recommendations whether the software

development should continue. This report may also include information about changes in the
software scope, budget, and schedule and suggestions of any requirements in the system.
4. General information: Describes the purpose and scope of feasibility study. It also describes
system overview, project references, acronyms and abbreviations, and points of contact to be
used. System overview provides description about the name of the organization responsible for
the software development, system name or title, system category, operational status, and so
on. Project references provide a list of the references used to prepare this document such as
documents relating to the project or previously developed documents that are related to the
project. Acronyms and abbreviations provide a list of the terms that are used in this document
along with their meanings. Points of contact provide a list of points of organizational contact
with users for information and coordination. For example, users require assistance to solve
problems (such as troubleshooting) and collect information such as contact number, e-mail
address, and so on.
5. Management summary: Provides the following information.
m
o
6. Environment: Identifies the individuals responsible for software development. It provides

.c
information about input and output requirements, processing requirements of the software and
the interaction of the software with other software. It also identifies system security
requirements and the system's processing requirements
a
7. Current functional procedures: Describes the current functional procedures of the existing
m
system, whether automated or manual. It also includes the data-flow of the current system and

a
the number of team members required to operate and maintain the software.

n
8. Functional objective: Provides information about functions of the system such as new services,

y
increased capacity, and so on.
9. Performance objective: Provides information about performance objectives such as reduced
d
staff and equipment costs, increased processing speeds of software, and improved controls.

u
10. Assumptions and constraints: Provides information about assumptions and constraints such as

t
operational life of the proposed software, financial constraints, changing hardware, software

S
and operating environment, and availability of information and sources.
11. Methodology: Describes the methods that are applied to evaluate the proposed software in
order to reach a feasible alternative. These methods include survey, modelling, benchmarking,
etc.
12. Evaluation criteria: Identifies criteria such as cost, priority, development time, and ease of
system use, which are applicable for the development process to determine the most suitable
system option.
13. Recommendation: Describes a recommendation for the proposed system. This includes the
delays and acceptable risks.
14. Proposed software: Describes the overall concept of the system as well as the procedure to be
used to meet user requirements. In addition, it provides information about improvements, time
and resource costs, and impacts. Improvements are performed to enhance the functionality and
 16

performance of the existing software. Time and resource costs include the costs associated with
software development from its requirements to its maintenance and staff training. Impacts
describe the possibility of future happenings and include various types of impacts as listed
below.
15. Equipment impacts: Determine new equipment requirements and changes to be made in the
currently available equipment requirements.
16. Software impacts: Specify any additions or modifications required in the existing software and
supporting software to adapt to the proposed software.
17. Organizational impacts: Describe any changes in organization, staff and skills requirement.
18. Operational impacts: Describe effects on operations such as user-operating procedures, data
processing, data entry procedures, and so on.
19. Developmental impacts: Specify developmental impacts such as resources required to develop
databases, resources required to develop and test the software, and specific activities to be
performed by users during software development.

m
20. Security impacts: Describe security factors that may influence the development, design, and
continued operation of the proposed software.
o
.c
21. Alternative systems: Provide description of alternative systems, which are considered in a
feasibility study. This also describes the reasons for choosing a particular alternative system to

a
develop the proposed software and the reason for rejecting alternative systems.

Types of Feasibility Study m

a
 Technical Feasibility - Does the company have the technological resources to undertake the

n
project? Are the processes and procedures conducive to project success?


y
Schedule Feasibility - Does the company currently have the time resources to undertake the

d
project? Can the project be completed in the available time?


u
Economic Feasibility - Given the financial resources of the company, is the project

t
something that can be completed? The economic feasibility study is more commonly
called the cost/benefit analysis.


S
Cultural Feasibility - What will be the impact on both local and general cultures? What sort
of environmental implications does the feasibility study have?

 Legal/Ethical Feasibility - What are the legal implications of the project? What sort of
ethical considerations are there? You need to make sure that any project undertaken will
meet all legal and ethical requirements before the project is on the table.

 Resource Feasibility - Do you have enough resources, what resources will be required, what
facilities will be required for the project, etc.

 Operational Feasibility - This measures how well your company will be able to solve
problems and take advantage of opportunities that are presented during the course of the
project
 17

 Marketing Feasibility - Will anyone want the product once its done? What is the target
demographic? Should there be a test run? Is there enough buzz that can be created for the
product?

 Real Estate Feasibility - What kind of land or property will be required to undertake the
project? What is the market like? What are the zoning laws? How will the business impact
the area?

 Comprehensive Feasibility - This takes a look at the various aspects involved in the project -
marketing, real estate, cultural, economic, etc. When undertaking a new business venture,
this is the most common type of feasibility study performed.

S.NO RGPV QUESTION YEAR MARKS

Q.1 Explain SRS. What are the good June 2014,2012 7,10
characteristics of SRS?
Q.2 What do you mean by June 2012
m 10
feasibility study? Explain
o
.c
different type of feasibilities.
Q.3 10
a
What is the difference between June 2011
a design requirement and
software requirement?
m
a
n
y
d
u
t
S
 18

UNIT-03/LECTURE-04
Software Design: [RGPV/June 2014(7)]
A software design creates meaningful engineering representation (or model) of some software
product that is to be built. Designers must strive to acquire a repertoire of alternative design
information and learn to choose the elements that best match the analysis model. A design
model can be traced to the customer's requirements and can be assessed for quality against
predefined criteria. During the design process the software requirements model (data, function,
and behaviour) is transformed into design models that describe the details of the data
structures, system architecture, interfaces, and components necessary to implement the
system. Each design product is reviewed for quality (i.e. identify and correct errors,
inconsistencies, or omissions, whether better alternatives exist, and whether the design model
can be implemented within the project constraints) before moving to the next phase of
software development.
 Encompasses the set of principles, concepts, and practices that lead to the development
of a high quality system or product
 Design principles establish and overriding philosophy that guides the designer as the
work is performed
m
o
 Design concepts must be understood before the mechanics of design practice are

.c
applied
 Goal of design engineering is to produce a model or representation that is bug free
(firmness), suitable for its intended uses (commodity), and pleasurable to use (delight)
a
 Software design practices change continuously as new methods, better analysis, and
broader understanding evolve
m
a
Software Engineering Design


n
Data/Class design - created by transforming the analysis model class-based elements (class

y
diagrams, analysis packages, CRC models, collaboration diagrams) into classes and data
structures required to implement the software

d
Architectural design - defines the relationships among the major structural elements of the
software, it is derived from the class-based elements and flow-oriented elements (data flow
u
diagrams, control flow diagrams, processing narratives) of the analysis model

t
Interface design - describes how the software elements, hardware elements, and end-users

S
communicate with one another, it is derived from the analysis model scenario-based elements
(use-case text, use-case diagrams, activity diagrams, swim lane diagrams), flow-oriented
elements, and behavioural elements (state diagrams, sequence diagrams)
 Component-level design - created by transforming the structural elements defined by the
software architecture into a procedural description of the software components using
information obtained from the analysis model class-based elements, flow-oriented elements,
and behavioural elements

Generic Design Task Set

1. Examine information domain model and design appropriate data structures for data objects
and their attributes
2. Select an architectural pattern appropriate to the software based on the analysis model
3. Partition the analysis model into design subsystems and allocate these subsystems within
the architecture
o Be certain each subsystem is functionally cohesive
 19

o Design subsystem interfaces

o Allocate analysis class or functions to subsystems

4. Create a set of design classes

o Translate analysis class into design class
o Check each class against design criteria and consider inheritance issues
o Define methods and messages for each design class
o Evaluate and select design patterns for each design class or subsystem after considering
alternatives
o Revise design classes and revise as needed

5. Design any interface required with external systems or devices

6. Design user interface

o Review task analyses
o Specify action sequences based on user scenarios
o Define interface objects and control mechanisms
o Review interface design and revise as needed
m
7. Conduct component level design o
.c
o Specify algorithms at low level of detail
o Refine interface of each component
o Define component level data structures
o Review components and correct all errors uncovered a
8. Develop deployment model m
a
n
Design Concepts


y
Abstraction – allows designers to focus on solving a problem without being concerned

d
about irrelevant lower level details (procedural abstraction - named sequence of events and
data abstraction – named collection of data objects)

u
Software Architecture – overall structure of the software components and the ways in which

t
that structure provides conceptual integrity for a system
o Structural models – architecture as organized collection of components
S
o Framework models – attempt to identify repeatable architectural patterns
o Dynamic models – indicate how program structure changes as a function of external
events
o Process models – focus on the design of the business or technical process that system
must accommodate
o Functional models – used to represent system functional hierarchy
 Design Patterns – description of a design structure that solves a particular design problem
within a specific context and its impact when applied
 Separation of concerns – any complex problem is solvable by subdividing it into pieces that
can be solved independently
 Modularity - the degree to which software can be understood by examining its components
independently of one another
 Information Hiding – information (data and procedure) contained within a module is
inaccessible to modules that have no need for such information
 20

 Functional Independence – achieved by developing modules with single-minded purpose

and an aversion to excessive interaction with other models
o Cohesion - qualitative indication of the degree to which a module focuses on just one
thing
o Coupling - qualitative indication of the degree to which a module is connected to other
modules and to the outside world
 Refinement – process of elaboration where the designer provides successively more detail
for each design component
 Aspects – a representation of a cross-cutting concern that must be accommodated as
refinement and modularization occur
 Refactoring – process of changing a software system in such a way internal structure is
improved without altering the external behaviour or code design

Design Classes

 Refine analysis classes by providing detail needed to implement the classes and implement a
software infrastructure the support the business solution
m
o
 Five types of design classes can be developed to support the design architecture
o user interface classes – abstractions needed for human-computer interaction (HCI)

.c
o business domain classes – refinements of earlier analysis classes
o process classes – implement lower level business abstractions

a
o persistent classes – data stores that persist beyond software execution
o System classes – implement software management and control functions

m
Design Class Characteristics a
 n
y
Complete (includes all necessary attributes and methods) and sufficient (contains only those
methods needed to achieve class intent)

 d
Primitiveness – each class method focuses on providing one service
High cohesion – small, focused, single-minded classes
 u
Low coupling – class collaboration kept to minimum
t
Design Model
S
 Process dimension – indicates design model evolution as design tasks are executed during
software process
o Architecture elements
o Interface elements
o Component-level elements
o Deployment-level elements
 Abstraction dimension – represents level of detail as each analysis model element is
transformed into a design equivalent and refined
o High level (analysis model elements)
o Low level (design model elements)
 Many UML diagrams used in the design model are refinements of diagrams created in the
analysis model (more implementation specific detail is provided)
 21

 Design patterns may be applied at any point in the design process

Data Design

 High level model depicting user s view of the data or information

 Design of data structures and operators is essential to creation of high-quality applications
 Translation of data model into database is critical to achieving system business objectives
 Reorganizing databases into a data warehouse enables data mining or knowledge discovery
that can impact success of business itself

Architectural Design

 Provides an overall view of the software product

 Derived from
o Information about the application domain relevant to software
m
o
o Relationships and collaborations among specific analysis model elements
o Availability of architectural patterns and styles

.c
 Usually depicted as a set of interconnected systems that are often derived from the analysis
packages with in the requirements model

a
Interface Design
m
 a
Interface is a set of operations that describes the externally observable behaviour of a class

 n
and provides access to its public operations

y
Important elements
o User interface (UI)

d
o External interfaces to other systems

u
o Internal interfaces between various design components
 Modelled using UML communication diagrams (called collaboration diagrams in UML 1.x)
t
S
Component-Level Design

 Describes the internal detail of each software component

 Defines
o Data structures for all local data objects
o Algorithmic detail for all component processing functions
o Interface that allows access to all component operations
 Modelled using UML component diagrams, UML activity diagrams, pseudocode (PDL), and
sometimes flowcharts
 22

Deployment-Level Design

 Indicates how software functionality and subsystems will be allocated within the physical
computing environment.
 Modelled using UML deployment diagrams.
 Descriptor form deployment diagrams show the computing environment but does not
indicate configuration details.
 Instance form deployment diagrams identifying specific named hardware configurations are
developed during the latter stages of design.

S.NO RGPV QUESTION YEAR MARKS

Q.1 Describe the design process in June 2014 7
software development. What
are the characteristics & criteria
for design? m
o
.c
a
m
a
n
y
d
u
t
S
 23

UNIT-03/LECTURE-05
Function-oriented design[RGPV/June 2013(7)]
 Design with functional units which transform inputs to outputs
 Practiced informally since programming began
 Thousands of systems have been developed using this approach
 Supported directly by most programming languages
 Most design methods are functional in their approach

A function-oriented view of design

Shared memory

m
o
.cF3
F1 F2
a
m
a
F4
n F5

y
d
u
Functional design process

t
Data-flow design


S
o Model the data processing in the system using data-flow diagrams
Structural decomposition
o Model how functions are decomposed to sub-functions using graphical structure
charts
 Detailed design
o The entities in the design and their interfaces are described in detail. These may
be recorded in a data dictionary and the design expressed using a PDL
Data flow diagrams[RGPV/June 2012(10)]
 Show how an input data item is functionally transformed by a system into an output
data item.
 24

 Are an integral part of many design methods

 May be translated into either a sequential or parallel design. In a sequential design,
processing elements are functions or procedures; in a parallel design, processing
elements are tasks or processes

DFD notation
 Rounded rectangle – function or transform
 Rectangle – data store
 Circles – user interactions with the system
 Arrows – show direction of data flow
 keywords and/ or. Used to link data flows

m
o
Design report generator

.c
a
m
a
n
y
d
u
t
S
Structural decomposition
 Structural decomposition is concerned with developing a model of the design which
shows the dynamic structure i.e. function calls
 This is not necessarily the same as the static composition structure
 The aim of the designer should be to derive
design units which are highly cohesive and
loosely coupled
 25

 In essence, a data flow diagram is converted to a structure chart

Decomposition guidelines
 For business applications, the top-level structure chart may have three functions namely
input, process and output
 Data validation functions should be subordinate to an input function
 Coordination and control should be the responsibility of functions near the top of the
hierarchy
 Each node in the structure chart should have between two and seven subordinates
 The aim of the design process is to identify loosely coupled, highly cohesive functions.
Each function should therefore do one thing and one thing only

m
 Cohesion – the degree to which a module performs one and only one function.

o
 Coupling – the degree to which a module is connected to other modules in the system .

Coupling and cohesion[RGPV/June 2014(7)] .c

a
m
a
n
y
d
u
t
S
 26

Process steps
 Identify system processing transformations
o Transformations in the DFD which are concerned with processing rather than
input/output activities. Group under a single function in the structure chart
 Identify input transformations
o Transformations concerned with reading, validating and formatting inputs. Group
under the input function
 Identify output transformations
o Transformations concerned with formatting and writing output. Group under the
output function

m
S.NO RGPV QUESTION YEAR MARKS

o
Q.1 Explain extensions of DFD for June 2011 10

.c
real time systems.
Q.2 Differentiate between data June 2013 7
structure design & object oriented
a
m
design.

a
Q.3 Discuss the impact of cohesion, June 2014 7

n
coupling, fan-in, fan-out &

y
factoring June 2013in design

d
phase

u
t
S
 27

UNIT-03/LECTURE-06
Object Oriented Design: [RGPV/June 2012(10)]
The Object Oriented Design converts the Object Oriented Analysis model into a design model.
This serves an outline for software construction. Object Oriented Design supports following
object oriented concepts such as Abstraction, Information Hiding, Functional Independence,
and Modularity. Design is the initial step in moving towards from the problem domain to the
solution domain. A detailed design includes specification of all the classes with its attributes,
detailed interface. The purpose of design is to specify a working solution that can be easily
translated into a programming language code.

The Object Oriented Design is classified into

m
 Architectural Design

o
 Detailed Design

Architectural Design
.c
a
Architectural design divides the system into different sub systems known as packages. Then the

m
dependency, relationship and communication between the packages are also identified.

a
Package diagram is use to represent architectural design using UML.

n
Detailed Design
y
d
It describes the detailed description of the classes that is all the attributes (Variables and

u
functions). The detailed class diagram represents the detailed design using UML.

t
Concerned with producing a short design specification (minispec) of each function. This should


S
describe the processing, inputs and outputs
These descriptions should be managed in a data dictionary
 From these descriptions, detailed design descriptions, expressed in a PDL or programming
language, can be produced

Characteristics of OOD
 Objects are abstractions of real-world or system entities and manage themselves.
 Objects are independent and encapsulate state and representation information.
 System functionality is expressed in terms of object services.
 Shared data areas are eliminated. Objects
 28

communicate by message passing.

 Objects may be distributed and may execute
sequentially or in parallel.

Interacting objects

m
o
.c
Advantages of OOD
 Easier maintenance. Objects may be understood as stand-alone entities.
 Objects are potentially reusable components.
a
m
 For some systems, there may be an obvious mapping from real world entities to system

a
objects.

n
y
The Unified Modelling Language

d
Several different notations for describing object-oriented designs were proposed in the 1980s
and 1990s.
 u
t
The Unified Modelling Language is an integration of these notations.

S
It describes notations for a number of different models that may be produced during OO analysis
and design.
 It is now a de facto standard for OO modelling.
 29

Employee object class (UML)

Em plo yee

nam e: string
address: string
dateOfBir th: Date
em ploy eeNo: integer
socialSecurity No: string
depar tm ent: Dept
m anager: Em ploy ee
salar y : integer
status: {current, left, retired}
taxCode: integer
. ..

j oin ()
leave ()
retire ()
changeDetails ()

Object communication m
 Conceptually, objects communicate by message passing. o
 Messages
.c
a
o The name of the service requested by the calling object; Copies of the

m
information required to execute the service and the name of a holder for the

a
result of the service.

n
In practice, messages are often implemented by procedure calls

y
o Name = procedure name;

d
o Information = parameter list.

u
t
Generalisation and inheritance

S
 Objects are members of classes that define attribute types and operations.
 Classes may be arranged in a class hierarch where one class (a super-class) is a generalisation
of one or more other classes (sub-classes).
 A sub-class inherits the attributes and operations from its super class and may add new
methods or attributes of its own.
Generalisation in the UML is implemented as inheritance in OO programming languages.
 30

A generalisation hierarchy

Em ployee

Mana ger Prog ram m er

budgetsControlled proj ect

progLanguages
dateAppointed

Proj ect Dept. Strateg ic

Mana ger Mana ger Mana ger

proj ects dept responsibilities

m
o
.c
a
m
a
n
y
d
u
t
S
 31

UNIT-03/LECTURE-07
Design Pattern Implementation Strategy:
Significant changes are taking place in management and especially project management today.
We hear that organizations, like the New York Times, Tribune Co., Ernst & Young switched from
the so-called top-down management style to bottom-up management. Others, including some
of the world s biggest corporations, such as Toyota and IBM, implemented bottom-up
management style elements in some of their departments. The popularity of the bottom-up
approach to management is growing. In spite of this fact, the discussions about the two major

m
approaches are still hot. Why have organizations become so anxious about changing their

o
management style? If we compare the two management approaches, the answer to this

.c
question will be clear.

Managing projects top-down

a
m
The top-down approach remains extremely popular in contemporary project management. The

a
phrase top-down means that all the directions come from the top. Project objectives are

n
established by the top management. Top managers provide guidelines, information, plans and

y
fund processes. All of the project manager s expectations are clearly communicated to each

d
project participant. Following this approach, ambiguity opens the door for potential failure, and

u
the managers should be as specific as possible when communicating their expectations. Process

t
formality is very important for this approach.

S
Examples of the top-down approach applications can be found in many organizations. One of
such example is the New York Times, a leader in the newspaper industry. Several years ago,
American Journalism Review (www.ajr.com) reported that The Times executive management
felt that they were far from what was necessary for creation of a vibrant workplace and a
successful organization. Power was centralized and masthead editors experienced overall
control. Editors introduced the same management pattern in the projects for which they were
responsible. One person s emotions and opinions influenced all the project decisions, and this
person was the project manager. What was the result? Team members felt that they weren't
listened to, that their voices didn't count. There was no effective collaboration between the
 32

journalists. They were not morally motivated to do their jobs. The managing executives then
realized that they needed to give more freedom to the teams and change their management
style. It took quite a while to introduce bottom-up management to the organization. But,
obviously, it was worth the time and effort, as New York Times employees say that collaboration
became much more efficient, and team members now work together more productively.

Similar problems caused by utilizing the top-down approach can be observed in many
organizations with a traditional management style. Experience shows that this top-down
management often results in reduced productivity and causes bottlenecks or so-called
lockdowns. A lockdown gives the project manager total control over his team. Such lockdowns
can lead to unnecessary pain and significantly slow down a project s completion.

m
o
Bottom-up project management options

.c
The factors mentioned above may play a vital role in a project s failure, and this is the reason
why numerous organizations have turned to a bottom-up management style or at least some of

a
its elements. The New York Times is one of the good examples. The bottom-up approach implies

m
proactive team input in the project executing process. Team members are invited to participate

a
in every step of the management process. The decision on a course of action is taken by the

n
whole team. Bottom-up style allows managers to communicate goals and value, e.g. through

y
milestone planning. Then team members are encouraged to develop personal to-do lists with

d
the steps necessary to reach the milestones on their own. The choice of methods and ways to

u
perform their tasks is up to the team. The advantage of this approach is that it empowers team

t
members to think more creatively. They feel involved into the project development and know

S
that their initiatives are appreciated. The team members motivation to work and make the
project a success is doubled. Individual members of the team get an opportunity to come up
with project solutions that are focused more on practical requirements than on abstract
notions. The planning process is facilitated by a number of people, which makes it flow
significantly faster. The to-do lists of all the team members are collected into the detailed
general project plan. Schedules, budgets and results are transparent. Issues are made clear by
the project manager to avoid as many surprises as possible. Bottom-up project management
can also be viewed as a way of coping with the increasing gap between the information
necessary to manage knowledge workers and the ability of managers to acquire and apply this
information.
 33

m
o
.c
a
m
a
n
y
d
Today, leading companies use a combination of integration techniques to implement their end
to end business processes. Typically these include a messaging backbone, integration brokers,

u
Enterprise Application Integration, object request brokers and transaction monitors. But it is

t
both difficult and time-consuming to manage all of these middleware infrastructure products
and develop application adapters. Middleware companies are well aware of this and their
S
products are improving all the time to simplify process integration.

Piecemeal approaches to process integration do not work. As processes change in the business,
integration costs escalate out of control. Point to point solutions creates an unmanageable and
complex topology. What starts as a neat top down design deteriorates rapidly. The
disconnected activities of application integration and B2B integration are not geared to
supporting end to end process design and deployment.
 34

m
o
.c
a
m
a
Figure - Without process management, as processes change, integration costs escalate out of

n
control

y
Process management products unify these disparate middleware activities. Each element acts

d
as a distributed computing service supporting the process management system.
Communication between systems is based on the processes that drive their use, not on the

u
connections between or configuration of lower level services. The advantages are clear:

 t
Process design is independent of technical deployment

S
Process models developed in different parts of the enterprise, or by partners, can be
composed (or decomposed) and related to each other.
 High level models of the business can be refined by further modelling.
 Abstract models can act as blueprints for subsequent concrete models, thereby ensuring
that all business activities fall within the agreed strategies.
 Process improvements achieved in one part of the business can be exported to other
parts of the business, with adaptation as required.
 High level business models expressed by the CEO or other senior managers can be
codified and used to drive further modelling.
 Deployed processes can be incrementally refined.

The result is that the process model the business wants to deploy is the model that actually is
deployed, and that model drives the integration and automation activities across the many
systems of the business and its partners. Constraints at every level are respected and enforced
 35

participate in the process.

This top down approach does not imply that everything has to be done at once, nor does it
imply there must be a single enterprise process model – clearly impractical. Rather, the term
top down implies the ability to model at all levels simultaneously, to combine models yet
retain their meaning, and to use process design patterns to constrain the behaviour of sub-
processes. This top down approach will often be used in conjunction with bottom up
integration and aggregation of web services.

m
o
.c
a
m
a
Figure - Top down business process management complements bottom up web services
n integration

y
For an initial implementation of process management, we advise companies to focus on a
d
manageable problem, understand how to model it, and then deploy it on a BPMS. As

u
experience grows, business managers will gain confidence that the process management

t
methodology can be extended to larger problems, such as supporting the supply chain.

S
The top down approach is very different from the traditional software engineering cycle, where
business strategies are translated to business requirements, to business objects and finally to
software code. Process management is straight through - there is no translation to executable
code. The live system can be tuned live. Process improvements can be metered and measured,
and investments in IT justified. Process management delivers a continuous and predictable
return on investment.
 36

UNIT-03/LECTURE-08
Formal & informal Specification
Formal specification is part of a more general collection of techniques that are known as formal
methods .
 These are all based on mathematical representation and analysis of software.
 Formal methods include
o Formal specification;
o Specification analysis and proof;
o Transformational development;
o Program verification.

m
 Acceptance of formal methods

o
Formal methods have not become mainstream software development techniques as was

.c
once predicted
o Other software engineering techniques have been successful at increasing

a
system quality. Hence the need for formal methods has been reduced;

m
o Market changes have made time-to-market rather than software with a low error

a
count the key factor. Formal methods do not reduce time to market;

n
o The scope of formal methods is limited. They are not well-suited to specifying

y
and analysing user interfaces and user interaction;

d
o Formal methods are still hard to scale up to large systems.

u
t
Use of formal methods

S
The principal benefits of formal methods are in reducing the number of faults in
systems.
 Consequently, their main area of applicability is in critical systems engineering. There
have been several successful projects where formal methods have been used in this
area.
 In this area, the use of formal methods is most likely to be cost-effective because high
system failure costs must be avoided.

 Specification in the software process

 Specification and design are inextricably intermingled.
 37

 Architectural design is essential to structure a specification and the specification

process.
 Formal specifications are expressed in a mathematical notation with precisely defined
vocabulary, syntax and semantics.

Specification and design

m
o
.c
Specification in the software process a
m
a
n
y
d
u
t
S
Use of formal specification
 Formal specification involves investing more effort in the early phases of software
development.
 This reduces requirements errors as it forces a detailed analysis of the requirements.
 Incompleteness and inconsistencies can be discovered and resolved.
 Hence, savings as made as the amount of rework due to requirements problems is
reduced.
 38

UNIT-03/LECTURE-09

Goals of Analysis Modeling: [RGPV/June 2011(10)]

• Provides the first technical representation of a system
• Is easy to understand and maintain
• Deals with the problem of size by partitioning the system
• Uses graphics whenever possible
• Differentiates between essential information versus implementation information
• Helps in the tracking and evaluation of interfaces
• Provides tools other than narrative text to describe software logic and policy

m
A Set of Models
o
•
.c
Flow-oriented modeling – provides an indication of how data objects are transformed

a
by a set of processing functions
• Scenario-based modeling – represents the system from the user's point of view
• m
Class-based modeling – defines objects, attributes, and relationships
• a
Behavioral modeling – depicts the states of the classes and the impact of events on
these states n
Analysis Modeling Approaches y
• d
Structured analysis
– u
Considers data and the processes that transform the data as separate entities
– t
S
Data is modeled in terms of only attributes and relationships (but no operations)
– Processes are modeled to show the 1) input data, 2) the transformation that
occurs on that data, and 3) the resulting output data
• Object-oriented analysis
– Focuses on the definition of classes and the manner in which they collaborate
with one another to fulfill customer requirements
 39

Elements of the Analysis Model

Object-oriented Analysis Structured Analysis

Scenario-based
modeling
Use case text
Use case diagrams
Activity diagrams
Swim lane diagrams
Flow-oriented
modeling
Data structure diagrams
Data flow diagrams
Control-flow diagrams
Processing narratives

Class-based Behavioral
modeling modeling
Class diagrams
State diagrams
Analysis packages
Sequence diagrams
CRC models
Collaboration diagrams

m
10

o
.c
Flow-oriented Modeling

a
1. Data Model
• Identify the following items
– Data objects (Entities) m
– Data attributes a
– Relationships n
– y
Cardinality (number of occurrences)

d
Data Flow and Control Flow
• Data Flow Diagramu
– t
S
Depicts how input is transformed into output as data objects move through a
system.
• Process Specification
– Describes data flow processing at the lowest level of refinement in the data flow
diagrams.
• Control Flow Diagram
– Illustrates how events affect the behavior of a system through the use of state
diagrams.
 40

2. Scenario-based Modeling
Writing Use Cases
• Writing of use cases was previously described in Chapter 7 – Requirements Engineering.
• It is effective to use the first person I to describe how the actor interacts with the
software.
• Format of the text part of a use case.

m
o
.c
a
m
a
n
y
d
u
t
S
 41

m
o
.c
a
Activity Diagrams
• Creation of activity diagrams was previously described in Chapter 7 – Requirements
Engineering. m
• a
Supplements the use case by providing a graphical representation of the flow of

n
interaction within a specific scenario.
• Uses flowchart-like symbolsy
– d
Rounded rectangle - represent a specific system function/action.
– u
Arrow - represents the flow of control from one function/action to another.
– t
Diamond - represents a branching decision.
– S
Solid bar – represents the fork and join of parallel activities.
 42

Example Activity Diagram

Set counter = positive n
Set accumulator = initial value

F
n>1
T
Set accumulator = accumulator * n
Set n = n - 1

F (n mod 5) == 0

T
Display accumulator value

m
o
19
Return accumulator value

.c
a
Class-based Modeling
Identifying Analysis Classes
m
1) Perform a grammatical parse of the problem statement or use cases.

a
2) Classes are determined by underlining each noun or noun clause.

n
3) A class required to implement a solution is part of the solution space.

y
4) A class necessary only to describe a solution is part of the problem space.

d
5) A class should NOT have an imperative procedural name (i.e., a verb)

u
6) List the potential class names in a table and "classify" each class according to some
t
S
taxonomy and class selection characteristics.
7) A potential class should satisfy nearly all (or all) of the selection characteristics to be
considered a legitimate problem domain class.
 General classifications for a potential class
 External entity (e.g., another system, a device, a person)
 Thing (e.g., report, screen display)
 Occurrence or event (e.g., movement, completion)
 Role (e.g., manager, engineer, salesperson)
 Organizational unit (e.g., division, group, team)
 Place (e.g., manufacturing floor, loading dock)
 Structure (e.g., sensor, vehicle, computer)
 43

Example Class Box

Class Name Component
+ componentID
- telephoneNumber
Attributes - componentStatus
- delayTime
- masterPassword
- numberOfTries
+ program()
+ display()
Operations + reset()
+ query()
- modify()
+ call()

m
26

o
.c
Association, Generalization and Dependency

a
• Association
– Represented by a solid line between two classes directed from the source class
to the target class m
– a
Used for representing (i.e., pointing to) object types for attributes
– n
May also be a part-of relationship (i.e., aggregation), which is represented by a
diamond-arrow y
• Generalization d
– u
Portrays inheritance between a super class and a subclass
– t
S
Is represented by a line with a triangle at the target end
• Dependency
– A dependency exists between two elements if changes to the definition of one
element (i.e., the source or supplier) may cause changes to the other element
(i.e., the client)
– Examples
• One class calls a method of another class
• One class utilizes another class as a parameter of a method
 44

3. Behavioral Modeling
1. Identify events found within the use cases and implied by the attributes in the class
diagrams.
2. Build a state diagram for each class, and if useful, for the whole software system.

RGPV QUESTION YEAR MARKS

S.NO
Q.1 Explain the requirement Jun.2011 10
analysis & Modelling.

REFERENCCE
m
o
BOOK AUTHOR
.c
PRIORITY
Software
a 1

m
Engineering P,S. Pressman

a
Software Pankaj jalote 2
Engineering

n
y
d
u
t
S
 1

UNIT-04
Coding standard and guidelines
UNIT-04/LECTURE-01
Software Coding standard: [RGPV/Jun 2014(7)]
Software coding standards are language-specific programming rules that greatly reduce the
probability of introducing errors into your applications, regardless of which software
development model (iterative, waterfall, extreme programming, and so on) is being used to
create that application.
Software coding standards originated from the intensive study of industry experts who

m
analyzed how bugs were generated when code was written and correlated these bugs to

o
specific coding practices. They took these correlations between bugs and coding practices and

.c
came up with a set of rules that when used prevent coding errors from occurring. Coding
standards offer incredible value to software development organizations because they are pre-

a
packaged automated error prevention practices; they close the feedback loop between a bug

m
and what must be done to prevent that bug from reoccurring. You don'tt have to write your

a
own rules to get the benefit of coding standards – the experts have already done it for you.

n
In a team environment or group collaboration, coding standards ensure uniform coding

y
practices, reducing oversight errors and the time spent in code reviews. When work is

d
outsourced to a third-party contractor, having a set of coding standards in place ensures that

u
the code produced by the contractor meets all quality guidelines mandated by the client
company.
t
S
Coding Standards Are NOT merely a way of enforcing naming conventions on your code.
Coding Standards Enforcement IS static analysis of source code for:
 Certain rules and patterns to detect problems automatically
 Based on the knowledge collected over many years by industry experts
 Virtual code review or peer review by industry respected language experts –
AUTOMATICALLY
Previous efforts at standards enforcement include SEI - CMM and ISO 9001. These efforts failed
to deliver on their promise because they created stacks upon stacks of bureaucratic documents.
There was no automation of processes– because of this the cost of implementation
overwhelms the benefit of process implementation.
 2

How Coding Standards are Classified

Software coding standards are classified by language, usage, and severity levels. Language
specific rules and best coding practices are determined by industry experts in that particular
language. Usage types and severity levels are set by the user.
Language
Parasoft provides coding standards for:
 C and C++ Testing
 Java
 .NET Languages (including C#, VB.NET, ASP.NET and Managed C++)
 SOA and Web (XML, HTML, CSS, JavaScript, JSP, WSDL, etc.)

m
How the Coding Standards Process is Automated

o
Coding standards are automated through:

.c
1. Daily usage by developers. Each developer enforces rules every time a class is written
and before the class is checked in to the source code repository.

a
2. Automated nightly builds. Coding standards are enforced upon all source code modified

m
during the day by automatically running and testing the code in "batch mode".

a
Both of these methods verify that each developer adhered to the coding standards. In

n
conjunction with Parasoft's reporting system, developers can send reports to management on

y
the current status of their project. This closes the software development lifecycle feedback loop

d
to ensure that the process is indeed in place and running properly.

u
Code review

t
Code review is systematic examination (often as peer review) of computer source code. It is

S
intended to find and fix mistakes overlooked in the initial development phase, improving both
the overall quality of software and the developers' skills. Reviews are done in various forms
such as pair programming, informal walkthroughs, and formal inspections.
Inspection
Inspection in software engineering refers to peer review of any work product by trained
individuals who look for defects using a well defined process. An inspection might also be
referred to as a Fagan inspection after Michael Fagan, the creator of a very popular software
inspection process.
 3

The process
The inspection process was developed by Michael Fagan in the mid-1970s and it has later been
extended and modified.
The process should have entry criteria that determine if the inspection process is ready to
begin. This prevents unfinished work products from entering the inspection process. The entry
criteria might be a checklist including items such as "The document has been spell-checked".
The stages in the inspections process are: Planning, Overview meeting, Preparation, Inspection
meeting, Rework and Follow-up. The Preparation, Inspection meeting and Rework stages might
be iterated.
 Planning: The inspection is planned by the moderator.
 Overview meeting: The author describes the background of the work product.


m
Preparation: Each inspector examines the work product to identify possible defects.


o
Inspection meeting: During this meeting the reader reads through the work product,

.c
part by part and the inspectors point out the defects for every part.
 Rework: The author makes changes to the work product according to the action plans
from the inspection meeting.
a

m
Follow-up: The changes by the author are checked to make sure everything is correct.

a
The process is ended by the moderator when it satisfies some predefined exit criteria.

n
y
Inspection roles

d
During an inspection the following roles are used.

u
 Author: The person who created the work product being inspected.

t
Moderator: This is the leader of the inspection. The moderator plans the inspection and


S
coordinates it.
Reader: The person reading through the documents, one item at a time. The other
inspectors then point out defects.
 Recorder/Scribe: The person that documents the defects that are found during the
inspection.
 Inspector: The person that examines the work product to identify possible defects.

inspection types
Code review
A code review can be done as a special kind of inspection in which the team examines a sample
 4

of code and fixes any defects in it. In a code review, a defect is a block of code which does not
properly implement its requirements, which does not function as the programme intended, or
which is not incorrect but could be improved (for example, it could be made more readable or
its performance could be improved). In addition to helping teams find and fix bugs, code
reviews are useful for both cross-training programmes on the code being reviewed and for
helping junior developers learn new programming techniques.

Peer Reviews
Peer Reviews are considered an industry best-practice for detecting software defects early and
learning about software artifacts. Peer Reviews are composed of software walkthroughs and
software inspections and are integral to software product engineering activities. A collection of

m
coordinated knowledge, skills, and behaviours facilitates the best possible practice of Peer

o
Reviews. The elements of Peer Reviews include the structured review process, standard of

.c
excellence product checklists, defined roles of participants, and the forms and reports.
Software inspections are the most rigorous form of Peer Reviews and fully utilize these

a
elements in detecting defects. Software walkthroughs draw selectively upon the elements in

m
assisting the producer to obtain the deepest understanding of an artifact and reaching a

a
consensus among participants. Measured results reveal that Peer Reviews produce an

n
attractive return on investment obtained through accelerated learning and early defect

y
detection. For best results, Peer Reviews are rolled out within an organization through a

d
defined program of preparing a policy and procedure, training practitioners and managers,

u
defining measurements and populating a database structure, and sustaining the roll out
infrastructure.
t
S.NO
S RGPV QUESTION YEAR MARKS
Q.1 Explain the coding standards of Jun.2014 7
software engineering
 5

UNIT-04/LECTURE-02

coding conventions :
coding conventions are a set of guidelines for a specific programming language that
recommend programming style, practices and methods for each aspect of a piece program
written in this language. These conventions usually cover file organization, indentation,
comments, declarations, statements, white space, naming conventions, programming practices,
programming principles, programming rules of thumb, etc. Software programmers are highly
recommended to follow these guidelines to help improve the readability of their source code
and make software maintenance easier. Coding conventions are only applicable to the human
maintainers and peer reviewers of a software project. Conventions may be formalized in a

m
documented set of rules that an entire team or company follows, or may be as informal as the

o
habitual coding practices of an individual. Coding conventions are not enforced by compilers. As

.c
a result, not following some or all of the rules has no impact on the executable programs
created from the source code.

a
Common conventions
m
 Comment conventions
a
 Indent style conventions
n
 Naming conventions
y

d
Programming practices

u
Programming principles

t
Programming rules of thumb

S
Programming style conventions

Rapid application development (RAD)

Software prototyping is the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed. It is an activity that can occur
in software development and is comparable to prototyping as known from other fields, such
as mechanical engineering or manufacturing.
A prototype typically simulates only a few aspects of, and may be completely different from, the
final product.
Prototyping has several benefits: The software designer and implementer can get valuable
 6

feedback from the users early in the project. The client and the contractor can compare if the
software made matches the software specification, according to which the software program is
built. It also allows the software engineer some insight into the accuracy of initial project
estimates and whether the deadlines and milestones proposed can be successfully met.

It refers to a type of software development methodology that uses minimal planning in favor of
rapid prototyping. The "planning" of software developed using RAD is interleaved with writing
the software itself. The lack of extensive pre-planning generally allows software to be written
much faster, and makes it easier to change requirements.
Rapid application development is a software development methodology that involves methods
like iterative development and software prototyping. According to Whitten (2004), it is a merger

m
of various structured techniques, especially data-driven Information Engineering, with

o
prototyping techniques to accelerate software systems development.

.c
In rapid application development, structured techniques and prototyping are especially used to
define users' requirements and to design the final system. The development process starts with

a
the development of preliminary data models and business process models using structured

m
techniques. In the next stage, requirements are verified using prototyping, eventually to refine

a
the data and process models. These stages are repeated iteratively; further development results

n
in "a combined business requirements and technical design statement to be used for

y
constructing new systems".

d
RAD approaches may entail compromises in functionality and performance in exchange for

u
enabling faster development and facilitating application maintenance.

t
This table contains a high-level summary of some of the major types of RAD and their relative

S
strengths and weaknesses.

Agile software development (Agile)

Minimizes feature creep by developing in short intervals resulting in miniature softwar

Pros
releasing the product in mini-increments.

Short iteration may add too little functionality, leading to significant delays in final iteratio
emphasizes real-time communication (preferably face-to-face), using it is problematic f
Cons
team distributed system development. Agile methods produce very little written docu
require a significant amount of post-project documentation.
 7

Extreme Programming (XP)

Lowers the cost of changes through quick spirals of new requirements. Most design activity occu
Pros
incrementally and on the fly.

Programmers must work in pairs, which is difficult for some people. No up-front detailed desig
occurs, which can result in more redesign effort in the long term. The business champion attached to t
Cons
project full time can potentially become a single point of failure for the project and a major source
stress for a team.

Joint application design (JAD)

Captures the voice of the customer by involving them in the design and development of the applicati
Pros
through a series of collaborative workshops called JAD sessions.

m
The client may create an unrealistic product vision and request extensive gold-plating, leading a team

o
Cons
over- or under-develop functionality.

Lean software development (LD)

.c
Pros a
Creates minimalist solutions (i.e., needs determine technology) and delivers less functionality earlier; p

m
the policy that 80% today is better than 100% tomorrow.

a
Product may lose its competitive edge because of insufficient core functionality and may exhibit po

n
Cons
overall quality.

y
Rapid application development (RAD)

d
u
Promotes strong collaborative atmosphere and dynamic gathering of requirements. Business own
Pros

t
actively participates in prototyping, writing test cases and performing unit testing.

Cons
S
Dependence on strong cohesive teams and individual commitment to the project. Decision making rel
on the feature functionality team and a communal decision-making process with lesser degree
centralized PM and engineering authority.

Scrum

Improved productivity in teams previously paralyzed by heavy process , ability to prioritize work, use
Pros backlog for completing items in a series of short iterations or sprints, daily measured progress a
communications.

Reliance on facilitation by a master who may lack the political skills to remove impediments and deliv
Cons
the sprint goal. Due to relying on self-organizing teams and rejecting traditional centralized "proce
 8

control", internal power struggles can paralyze a team.

Table 1: Pros and Cons of various RAD types

Disadvantages of prototyping
Insufficient analysis: The focus on a limited prototype can distract developers from properly
analyzing the complete project. This can lead to overlooking better solutions, preparation of
incomplete specifications or the conversion of limited prototypes into poorly engineered final
projects that are hard to maintain. Further, since a prototype is limited in functionality it may
not scale well if the prototype is used as the basis of a final deliverable, which may not be
noticed if developers are too focused on building a prototype as a model.

m
User confusion of prototype and finished system: Users can begin to think that a prototype,

o
intended to be thrown away, is actually a final system that merely needs to be finished or

.c
polished. (They are, for example, often unaware of the effort needed to add error-checking and
security features which a prototype may not have.) This can lead them to expect the prototype

a
to accurately model the performance of the final system when this is not the intent of the

m
developers. Users can also become attached to features that were included in a prototype for

a
consideration and then removed from the specification for a final system. If users are able to

n
require all proposed features be included in the final system this can lead to conflict.

y
d
Developer misunderstanding of user objectives: Developers may assume that users share their

u
objectives (e.g. to deliver core functionality on time and within budget), without understanding
wider commercial
t issues. For example, user representatives attending Enterprise

S
software (e.g. PeopleSoft) events may have seen demonstrations of "transaction auditing"
(where changes are logged and displayed in a difference grid view) without being told that this
feature demands additional coding and often requires more hardware to handle extra database
accesses. Users might believe they can demand auditing on every field, whereas developers
might think this is feature creep because they have made assumptions about the extent of user
requirements. If the developer has committed delivery before the user requirements were
reviewed, developers are between a rock and a hard place, particularly if user management
derives some advantage from their failure to implement requirements.

Developer attachment to prototype: Developers can also become attached to prototypes they
 9

have spent a great deal of effort producing; this can lead to problems like attempting to convert
a limited prototype into a final system when it does not have an appropriate underlying
architecture. (This may suggest that throwaway prototyping, rather than evolutionary
prototyping, should be used.)

Excessive development time of the prototype: A key property to prototyping is the fact that it
is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to
develop a prototype that is too complex. When the prototype is thrown away the precisely
developed requirements that it provides may not yield a sufficient increase in productivity to
make up for the time spent developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and delaying the final product.

m
o
Expense of implementing prototyping: the start up costs for building a development team

.c
focused on prototyping may be high. Many companies have development methodologies in
place, and changing them can mean retraining, retooling, or both. Many companies tend to just

a
jump into the prototyping without bothering to retrain their workers as much as they should.

m
A common problem with adopting prototyping technology is high expectations for productivity

a
with insufficient effort behind the learning curve. In addition to training for the use of a

n
prototyping technique, there is an often overlooked need for developing corporate and project

y
specific underlying structure to support the technology. When this underlying structure is

d
omitted, lower productivity can often result.

u
t
S
 10

UNIT-04/LECTURE-03
Debugging
Debugging is that activity which is performed after executing a successful test case. Debugging
consists of determining the exact nature and location of the suspected error and fixing the error.
Debugging is probably the most difficult activity in software development from a psychological
point of view for the following reasons:
 Debugging is done by the person who developed the software, and it is hard for that
person to acknowledge that an error was made.
 Of all the software-development activities, debugging is the most mentally taxing
because of the way in which most programs are designed and because of the nature of

m
most programming languages (i.e., the location of any error is potentially any statement
in the program).
o

.c
Debugging is usually performed under a tremendous amount of pressure to fix the

a
suspected error as quickly as possible.
 Compared to the other software-development activities, comparatively little research,
m
literature, and formal instruction exist on the process of debugging.
a
Of the two aspects of debugging, locating the error represents about 95% of the activity. Hence,

n
the rest of this section concentrates on the process of finding the location of an error, given a

y
suspicion that an error exists, based on the results of a successful test case.

d
u
Debugging by Brute Force
t
S
The most common and least effective method of program debugging is by "brute force". It
requires little thought and is the least mentally taxing of all the methods. The brute-force
methods are characterized by either debugging with a memory dump; scattering print
statements throughout the program, or debugging with automated debugging tools.
Using a memory dump to try to find errors suffers from the following drawbacks:
 Establishing the correspondence between storage locations and the variables in the
source program is difficult.
 Massive amounts of data, most of which is irrelevant, must be dealt with.
 A dump shows only the static state of the program at only one instant in time. The
dynamics of the program (i.e., state changes over time) are needed to find most errors.
 11

 The dump is rarely produced at the exact-time of the error. Hence the dump does not
show the program's state at the time of the error.
 No formal procedure exists for finding the cause of an error analyzing a storage dump.
Scattering print statements throughout the program, although often superior to the use of a
dump in that it displays the dynamics of a program and allows one to examine information that
is easier to read, is not much better and exhibits the following shortcomings:
 It is still largely a hit-or-miss method.
 It often results in massive amounts of data to be analyzed.
 It requires changing the program, which can mask the error, alter critical timing or
introduce new errors.
 It is often too costly or even infeasible for real-time software. Debugging with

m
automated tools also exhibits the shortcomings of hit-or-miss and massive amounts of

o
data which mist be analyzed. The problem of changing the program however is

.c
circumvented by the use of the automated debugging tool.
The biggest problem with the brute-force methods is that they ignore the most powerful

a
debugging tool in existence, a well trained and disciplined human brain. Myers suggests that

m
experimental evidence, both from students and experienced programmers, shows:

a
 Debugging aids do not assist the debugging processes.

n
 In terms of the speed and accuracy of finding the error, people who use their brains

y
rather than a set of "aids" seem to exhibit superior performance.

d
Hence, the use of brute-force methods is recommended only when all other methods fail or as

u
a supplement to (not a substitute for) the thought processes described in the subsequent
sections.
t
S
Debugging by Induction
Many errors can be found by using a disciplined thought process without ever going near the
computer. One such thought process is induction, where one proceeds from the particulars to
the whole. By starting with the symptoms of the error, possibly in the result of one or more test
cases, and looking for relationships among the symptoms, the error is often uncovered.
The induction process is illustrated in Figure 1 and described by Myers as follows:
 Locate the pertinent data. A major mistake made when debugging a program is failing
to take account of all available data or symptoms about the problems. The first step is
the enumeration of all that is known about what the program did correctly, and what it
 12

did incorrectly (i.e., the symptoms that led one to believe that an error exists).
Additional valuable clues are provided by similar, but different, test cases that do not
cause the symptoms to appear.
 Organize the data. Remembering that induction implies that one is progressing from the
particulars to the general, the second step is the structuring of the pertinent data to
allow one to observe patterns, of particular importance is the search for contradictions
(i.e., "the errors occurs only when the pilot perform a left turn while climbing"). A
particularly useful organizational technique that can be used to structure the available
data is shown in the following table. The "What" boxes list the general symptoms, the
"Where" boxes describe where the symptoms were observed, the "When" boxes list
anything that is known about the times that the symptoms occur, and the "To What

m
Extent" boxes describes the scope and magnitude of the symptoms. Notice the "Is" and

o
"Is Not" columns. They describe the contradictions that may eventually lead to a

.c
hypothesis about the error.

a
m
a
n

y
Devise a hypothesis. The next steps are to study the relationships among the clues and

d
devise, using the patterns that might be visible in the structure of the clues, one or more

u
hypotheses about the cause of the error. If one cannot devise a theory, more data are

t
necessary, possibly obtained by devising and executing additional test cases. If multiple


S
theories seem possible, the most probable one is selected first.
Prove the hypothesis. A major mistake at this point, given the pressures under which
debugging is usually performed, is skipping this step by jumping to conclusions and
attempting to fix the problem. However, it is vital to prove the reasonableness of the
hypothesis before proceeding. A failure to do this often results in the fixing of only a
symptom of the problem, or only a portion of the problem. The hypothesis is proved by
comparing it to the original clues or data, making sure that this hypothesis completely
explains the existence of the clues. If it does not, either the hypothesis is invalid, the
hypothesis is incomplete, or multiple errors are present.
 13

Figure 1. Inductive Debugging Process

Debugging By Deduction
An alternate thought process, that of deduction, is a process of proceeding from some general
theories or premises, using the processes of elimination and refinement, to arrive at a

m
conclusion. This process is illustrated in Figure 2 and also described by Myers as follows:

o
.c
 Enumerate the possible causes or hypotheses. The first step is to develop a list of all
conceivable causes of the error. They need not be complete explanations; they are

a
merely theories through which one can structure and analyze the available data.

m
Use the data to eliminate possible causes. By a careful analysis of the data, particularly

a
by looking for contradictions (the previous table could be used here), one attempts to

n
eliminate all but one of the possible causes. If all are eliminated, additional data are

y
needed (e.g., by devising additional test cases) to devise new theories. If more than one

d
possible cause remains, the most probable cause (the prime hypothesis) is selected first.

u
 Refine the remaining hypothesis. The possible cause at this point might be correct, but

t
it is unlikely to he specific enough to pinpoint the error. Hence, the next step is to use


S
the available clues to refine the theory to something more specific.
Prove the remaining hypothesis. This vital step is identical to the fourth step in the
induction method.
 14

Figure 2. Deductive Debugging Process

Debugging by Backtracking
For small programs, the method of backtracking is often used effectively in locating errors. To
use this method, start at the place in the program where an incorrect result was produced and
m
go backwards in the program one step at a time, mentally executing the program in reverse
o
order, to derive the state (or values of all variables) of the program at the previous step.

.c
Continuing in this fashion, the error is localized between the points where the state of the

a
program was what was expected and the first point where the state was not what was

m
expected.

a
n
Debugging by Testing

y
The use of additional test cases is another very powerful debugging method which is often used

d
in conjunction with the induction method to obtain information needed to generate a

u
hypothesis and/or to prove a hypothesis and with the deduction method to eliminate suspected

t
causes, refine the remaining hypothesis, and/or prove a hypothesis.

S
The test cases for debugging differ from those used for integration and testing in that they are
more specific and are designed to explore a particular input domain or internal state of the
program. Test cases for integration and testing tend to cover many conditions in one test,
whereas test cases for debugging tend to cover only one or a very few conditions. The former
are designed to detect the error in the most efficient manner whereas the latter are designed to
isolate the error most efficiently.

Debugging Guidelines (Error Locating)

As was the case for the testing guidelines, many of these debugging guidelines is intuitively
obvious, yet they often forgotten or overlooked. The following guidelines are suggested by
 15

Myers to assist in locating errors.

Debugging is a problem solving process. The most effective method of debugging is a mental
analysis of the information associated with the error's symptoms. In efficient program debugger
should be able to pinpoint most errors without going near a computer.
If you reach an impasse, sleep on it.
The human subconscious is a potent problem-solver. What we often refer to as inspiration is
simply the subconscious mind working on a problem when the conscious mind is working on
something else, such as eating, walking, or watching a movie. If you cannot locate an error in a
reasonable amount of time (perhaps 30 minutes for a small program, a few hours for a large
one), drop it and work on something else, since your thinking efficiency is about to collapse

m
anyway. After "forgetting" about the problem for a while, either your subconscious mind will

o
have solved the problem, or your conscious mind will be clear for a fresh examination of the

.c
symptoms.
If you reach an impasse, describe the problem to someone else.

a
By doing so, you will probably discover something new. In fact, it is often the case that by simply

m
describing the problem to a good listener, you will suddenly see the solution without any

a
assistance from the listener.

n
Use debugging tools only as a second resort.

y
And then, use them as an adjunct to, rather than as a substitute for, thinking. 15 noted earlier in

d
this section, debugging tools, such as dumps and traces, represent a haphazard approach to

u
debugging. Experiments show that people who shun such tools, even when they are debugging

t
problems that are unfamiliar to them, tend to be more successful than people who use the
tools.
S
Avoid experimentation.
Use it only as a last resort. The most common mistake made by novice debuggers is attempting
to solve a problem by making experimental changes to the program. This totally haphazard
approach cannot even be considered debugging; it represents an act of blind hope. Not only
does it have a miniscule chance of success, but it often compounds the problem by adding new
errors to the program.

Debugging Guidelines (Error Repairing)

The following guidelines for fixing or repairing the program after the error is located are also
 16

suggested by Myers.
Where there is one bug, there is likely to be another.
When one finds an error in a section of a program, the probability of the existence of another
error in that section is higher. When repairing an error, examine its immediate vicinity for
anything else that looks suspicious.
Fix the error, not just a symptom of it.
Another common failing is repairing the symptoms of the error, or just one instance of the error,
rather than the error itself. If the proposed correction does not match all the clues about the
error, one may be fixing only a part of the error.
The probability of the fix being correct is not 100%.
Tell this to someone, and of course he would agree, but tell it to someone in the process of

m
correcting an error, and one often gets a different reaction (e.g., "Yes, in most cases, but this

o
correction is so minor that it just has to work"). Code that is added to a program to fix an error

.c
can never be assumed correct. Statement for statement, corrections are much more error prone
than the original code in the program. One implication is that error corrections must be tested,
perhaps more rigorously than the original program.
a
m
a
The probability of the fix being correct drops as the size of the program increases.

n
Experience has shown that the ratio of errors due to incorrect fixes versus original errors

y
increases in large programs. In one widely used large program, one of every six new errors

d
discovered was an error in a prior correction to the program.

u
Beware of the possibility that an error correction creates a new error.

t
Not only does one have to worry about incorrect corrections, but one has to worry about a

S
seemingly valid correction having an undesirable side effect, thus introducing a new error. Not
only is there a probability that a fix will be invalid, but there is also a real probability that a fix
will introduce a new error. One implication is that not only does the error situation have to be
tested after the correction is make, but one must also perform regression testing to determine
if a new error has been introduced.
The process of error repair should put one back temporarily in the design phase.
One should realize that error correction is a form of program design. Given the error-prone
nature of corrections, common sense says that whatever procedures, methodologies, and
formalism were used in the design process should also apply to the error-correction process.
For instance, if the project rationalized that code inspections were desirable, then it must be
 17

doubly important that they be used after correcting an error.

Change the source code, not the object code.
When debugging large systems, particularly a system written in an assembly language,
occasionally there is the tendency to correct an error by making an immediate change to the
object code, with the intention of changing the source program later. Two problems associated
with this approach are (l) it is usually a sign that "debugging by experimentation" is being
practiced, and (2) the object code and source program are now out of synchronization, meaning
that the error could easily surface again when the program is recompiled or reassembled.

m
o
.c
a
m
a
n
y
d
u
t
S
 18

UNIT-04/LECTURE-04

Software Testing Strategy: [RGPV/June 2014,2013(7),June 2012(10)]

A test strategy is an outline that describes the testing approach of the software development
cycle. It is created to inform project managers, testers, and developers about some key issues of
the testing process. This includes the testing objective, methods of testing new functions, total
time and resources required for the project, and the testing environment.
Test strategies describe how the product risks of the stakeholders are mitigated at the test-level,
which types of test are to be performed, and which entry and exit criteria apply. They are
created based on development design documents. System design documents are primarily used
and occasionally, conceptual design documents may be referred to. Design documents describe

m
the functionality of the software to be enabled in the upcoming release. For every stage of

o
development design, a corresponding test strategy should be created to test the new feature

.c
sets.

Strategic Approach to Software Testing a


m
Many software errors are eliminated before testing begins by conducting effective technical
reviews
a

n
Testing begins at the component level and works outward toward the integration of the
entire computer-based system.
y

d
Different testing techniques are appropriate at different points in time.

u
The developer of the software conducts testing and may be assisted by independent test

t
groups for large projects.
 S
Testing and debugging are different activities.
 Debugging must be accommodated in any testing strategy.

Verification and Validation: [RGPV/June2012,2011(10)]

 Make a distinction between verification (are we building the product right?) and validation
(are we building the right product?)
 Software testing is only one element of Software Quality Assurance (SQA)
 Quality must be built in to the development process, you can’t use testing to add quality
after the fact
 19

Organizing for Software Testing

 The role of the Independent Test Group (ITG) is to remove the conflict of interest inherent
when the builder is testing his or her own product.
 Misconceptions regarding the use of independent testing teams
o The developer should do no testing at all
o Software is tossed over the wall to people to test it mercilessly
o Testers are not involved with the project until it is time for it to be tested
 The developer and ITGC must work together throughout the software project to ensure that
thorough tests will be conducted

m
Software Testing Strategy

o
Unit Testing – makes heavy use of testing techniques that exercise specific control paths to

.c
detect errors in each software component individually
 Integration Testing – focuses on issues associated with verification and program

a
construction as components begin interacting with one another

m
Validation Testing – provides assurance that the software validation criteria (established

a
during requirements analysis) meets all functional, behavioral, and performance
requirements
n

y
System Testing – verifies that all system elements mesh properly and that overall system

d
function and performance has been achieved

u
t
Strategic Testing Issues


S
Specify product requirements in a quantifiable manner before testing starts.
Specify testing objectives explicitly.
 Identify categories of users for the software and develop a profile for each.
 Develop a test plan that emphasizes rapid cycle testing.
 Build robust software that is designed to test itself.
 Use effective formal reviews as a filter prior to testing.
 Conduct formal technical reviews to assess the test strategy and test cases.
 Develop a continuous improvement approach for the testing process.
 20

Unit Testing[RGPV/ June 2011(10)]

 Module interfaces are tested for proper information flow.
 Local data are examined to ensure that integrity is maintained.
 Boundary conditions are tested.
 Basis (independent) path are tested.
 All error handling paths should be tested.
 Drivers and/or stubs need to be developed to test incomplete software.

Integration Testing: [RGPV/June 2013(7),June 2012(10)]

 Sandwich testing uses top-down tests for upper levels of program structure coupled with
bottom-up tests for subordinate levels

m
 Testers should strive to indentify critical modules having the following requirements

o
Overall plan for integration of software and the specific tests are documented in a test

.c
specification

Integration Testing Strategies a

 Top-down integration testing
m
a
1. Main control module used as a test driver and stubs are substitutes for components directly
subordinate to it.
n
y
2. Subordinate stubs are replaced one at a time with real components (following the depth-

d
first or breadth-first approach).

u
3. Tests are conducted as each component is integrated.

t
4. On completion of each set of tests and other stub is replaced with a real component.

S
5. Regression testing may be used to ensure that new errors not introduced.

 Bottom-up integration testing

1. Low level components are combined into clusters that perform a specific software function.
2. A driver (control program) is written to coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the program structure.

 Regression testing – used to check for defects propagated to other modules by changes
made to existing program
 21

1. Representative sample of existing test cases is used to exercise all software functions.
2. Additional test cases focusing software functions likely to be affected by the change.
3. Tests cases that focus on the changed software components.

 Smoke testing
1. Software components already translated into code are integrated into a build.
2. A series of tests designed to expose errors that will keep the build from performing its
functions are created.
3. The build is integrated with the other builds and the entire product is smoke tested daily
(either top-down or bottom integration may be used).

m
General Software Test Criteria
 Interface integrity – internal and external module interfaces are tested as each module or
o
.c
cluster is added to the software
 Functional validity – test to uncover functional defects in the software
 a
Information content – test for errors in local or global data structures

m
Performance – verify specified performance bounds are tested

a
Object-Oriented Test Strategies
n

y
Unit Testing – components being tested are classes not modules

d
Integration Testing – as classes are integrated into the architecture regression tests are run

u
to uncover communication and collaboration errors between objects

t
Systems Testing – the system as a whole is tested to uncover requirement errors

S
Object-Oriented Unit Testing
 smallest testable unit is the encapsulated class or object
 similar to system testing of conventional software
 do not test operations in isolation from one another
 driven by class operations and state behavior, not algorithmic detail and data flow across
module interface

Object-Oriented Integration Testing

 22

 focuses on groups of classes that collaborate or communicate in some manner

 integration of operations one at a time into classes is often meaningless
 thread-based testing – testing all classes required to respond to one system input or event
 use-based testing – begins by testing independent classes (classes that use very few server
classes) first and the dependent classes that make use of them
 cluster testing – groups of collaborating classes are tested for interaction errors
 regression testing is important as each thread, cluster, or subsystem is added to the system

WebApp Testing Strategies

1. WebApp content model is reviewed to uncover errors.
2. Interface model is reviewed to ensure all use-cases are accommodated.

m
3. Design model for WebApp is reviewed to uncover navigation errors.

o
4. User interface is tested to uncover presentation errors and/or navigation mechanics

.c
problems.
5. Selected functional components are unit tested.
6. Navigation throughout the architecture is tested. a
m
7. WebApp is implemented in a variety of different environmental configurations and the

a
compatibility of WebApp with each is assessed.
8. Security tests are conducted.
n
9. Performance tests are conducted.
y
d
10. WebApp is tested by a controlled and monitored group of end-users (looking for content

u
errors, navigation errors, usability concerns, compatibility issues, reliability, and
performance).
t
S
Validation Testing
 Focuses on visible user actions and user recognizable outputs from the system
 Validation tests are based on the use-case scenarios, the behavior model, and the event
flow diagram created in the analysis model
o Must ensure that each function or performance characteristic conforms to its
specification.
o Deviations (deficiencies) must be negotiated with the customer to establish a means for
resolving the errors.
 Configuration review or audit is used to ensure that all elements of the software
 23

configuration have been properly developed, cataloged, and documented to allow its
support during its maintenance phase.

Acceptance Testing
 Making sure the software works correctly for intended user in his or her normal work
environment.
 Alpha test – version of the complete software is tested by customer under the supervision
of the developer at the developer’s site
 Beta test – version of the complete software is tested by customer at his or her own site
without the developer being present

m
System Testing: [RGPV/June2013(7)]

o
Series of tests whose purpose is to exercise a computer-based system

.c
 The focus of these system tests cases identify interfacing errors
 Recovery testing – checks the system’s ability to recover from failures
 a
Security testing – verifies that system protection mechanism prevent improper penetration
or data alteration
m

a
Stress testing – program is checked to see how well it deals with abnormal resource

n
demands (i.e. quantity, frequency, or volume)

y
Performance testing – designed to test the run-time performance of software, especially
real-time software
d

u
Deployment (or configuration) testing – exercises the software in each of the environment

t
in which it is to operate

S
 24

S.NO RGPV QUESTION YEAR MARKS

Q.1 What are testing principles the Jun.2014, 2013 7
software engineer must apply
while performing the software
testing?
Q.2 Explain the integration testing Jun.2013 7

process & System Testing

processes & discuss their
outcomes.
Q.3 Discuss software testing Jun.2012 10
strategies. Differentiate
between verification & m
validation. o
Q.4 Describe verification &
.c
Jun.2011 10

validation criteria for software.

a
m
Q.5 Describe unit testing & June 2011 10

a
integration testing. How test

n
plans are generated?

y
d
u
t
S
 25

UNIT-04/LECTURE-05
Black Box Testing[RGPV/June 2014(7),June 2011(10)]

The technique of testing without having any knowledge of the interior workings of the
application is Black Box testing. The tester is oblivious to the system architecture and does not
have access to the source code. Typically, when performing a black box test, a tester will
interact with the system's user interface by providing inputs and examining outputs without
knowing how and where the inputs are worked upon.

Advantages Disadvantages
 Well suited and efficient for large code
 Limited Coverage since only a selected
segments.
number of test scenarios are actually
 Code Access not required.
performed.


m
Clearly separates user's perspective
 Inefficient testing, due to the fact that
from the developer's perspective

o
the tester only has limited knowledge
through visibly defined roles.
about an application.

.c
 Large numbers of moderately skilled
 Blind Coverage, since the tester cannot
testers can test the application with no
target specific code segments or error
knowledge of implementation,
programming language or operating
systems.
 a
prone areas.
The test cases are difficult to design.

m
White Box Testing a
n
y
White box testing is the detailed investigation of internal logic and structure of the code. White
box testing is also called glass testing or open box testing. In order to perform white box testing

d
on an application, the tester needs to possess knowledge of the internal working of the code.

u
The tester needs to have a look inside the source code and find out which unit/chunk of the
t
code is behaving inappropriately.

S Advantages
 As the tester has knowledge of the
source code, it becomes very easy to
find out which type of data can help in
testing the application effectively.
 It helps in optimizing the code.
 Extra lines of code can be removed
which can bring in hidden defects.
 Due to the tester's knowledge about
the code, maximum coverage is
attained during test scenario writing.
Disadvantages
 Due to the fact that a skilled tester is
needed to perform white box testing,
the costs are increased.
 Sometimes it is impossible to look into
every nook and corner to find out
hidden errors that may create
problems as many paths will go
untested.
 It is difficult to maintain white box
testing as the use of specialized tools
like code analyzers and debugging tools
are required.
 26

Grey Box Testing

Grey Box testing is a technique to test the application with limited knowledge of the internal
workings of an application. In software testing, the term the more you know the better carries a
lot of weight when testing an application.

Mastering the domain of a system always gives the tester an edge over someone with limited
domain knowledge. Unlike black box testing, where the tester only tests the application's user
interface, in grey box testing, the tester has access to design documents and the database.
Having this knowledge, the tester is able to better prepare test data and test scenarios when
making the test plan.

Advantages Disadvantages
 Offers combined benefits of black box
and white box testing wherever
 Since the access to source code is not
possible.

m
available, the ability to go over the
 Grey box testers don't rely on the
code and test coverage is limited.

o
source code; instead they rely on
 The tests can be redundant if the
interface definition and functional

.c
software designer has already run a
specifications.
test case.
 Based on the limited information


a
Testing every possible input stream is
available, a grey box tester can design
unrealistic because it would take an
excellent test scenarios especially

m
unreasonable amount of time;
around communication protocols and
therefore, many program paths will go

a
data type handling.
untested.
 The test is done from the point of view

n
of the user and not the designer.

y
d
Black Box vs. Grey Box vs. White Box

S.N. u
Black Box Testing Grey Box Testing White Box Testing

t
The Internal Workings of an Tester has full knowledge of

S
Somewhat knowledge of the
1 application are not required the Internal workings of the
internal workings are known
to be known application
Another term for grey box
Also known as closed box testing is translucent testing Also known as clear box
2 testing, data driven testing as the tester has limited testing, structural testing or
and functional testing knowledge of the insides of code based testing
the application
Performed by end users and Performed by end users and
Normally done by testers
3 also by testers and also by testers and
and developers
developers developers
Testing is based on external Testing is done on the basis
Internal workings are fully
expectations - Internal of high level database
4 known and the tester can
behavior of the application is diagrams and data flow
design test data accordingly
unknown diagrams
 27

The most exhaustive and

This is the least time Partly time consuming and
5 time consuming type of
consuming and exhaustive exhaustive
testing
Not suited to algorithm Not suited to algorithm
6 Suited for algorithm testing
testing testing
Data domains and Internal Data domains and Internal
This can only be done by trial
7 boundaries can be tested, if boundaries can be better
and error method
known tested

S.NO RGPV QUESTION YEAR MARKS

Q.1 What is black box testing? It is Jun.2014 7
necessary to perform this?
Explain various test activities.

m
o
.c
a
m
a
n
y
d
u
t
S
 28

UNIT-04/LECTURE-06
Cyclomatic complexity
is a software metric that provides a quantitative measure of the logical complexity of a program.
When used in the context of a basis path testing method, the value computed for Cyclomatic
complexity defines the number for independent paths in the basis set of a program and
provides us an upper bound for the number of tests that must be conducted to ensure that all
statements have been executed at least once.

An independent path is any path through the program that introduces at least one new set of
processing statements or a new condition.

m
Computing Cyclomatic Complexity: Cyclomatic complexity has a foundation in graph theory and

o
provides us with extremely useful software metric. Complexity is computed in one of the three

.c
ways:

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

m
a
2. Cyclomatic complexity, V(G), for a flow graph, G is defined as

n
V (G) = E-N+2P Where E, is the number of flow graph edges, N is the number of flow graph
nodes, P is independent component.
y
d
u
3. Cyclomatic complexity, V (G) for a flow graph, G is also defined as:

t
V (G) = Pie+1 where Pie is the number of predicate nodes contained in the flow graph G.

S
4. Graph Matrices: The procedure for deriving the flow graph and even determining a set of
basis paths is amenable to mechanization. To develop a software tool that assists in basis path
testing, a data structure, called a graph matrix can be quite useful.
A Graph Matrix is a square matrix whose size is equal to the number of nodes on the flow
graph. Each row and column corresponds to an identified node, and matrix entries correspond
to connections between nodes. The connection matrix can also be used to find the cyclomatic
complexity
 29

Converting Code to Graph

Converting Code to Graph

CODE FLOWCHART GRAPH

if expression1 then T F
expr1 n1 For a strongly connected graph:
statement2 ?
else Create a virtual edge
(a) statement3 statm2 statm3 n2 n3
to connect the END node
end if
statement4 to the BEGIN node
statm4 n4

switch expr1
case 1: 1 3
expr1
statement2 ? n1

m
case 2: 2
(b) statm3
statm2 statm3 statm4 n2 n3 n4
case 3:

o
statm4
end switch
n5
statm5 statm5

statm1
.c n1

a
do
statement1
T
(c) while expr2 expr2
n2
end do ?

m
statement3 F
n3
statm3

a
5

n
Paths in Graphs
y
•
d
A graph is strongly connected if for any two nodes x, y there is a path from x to y and
vice versa
u
•
t
A path is represented as an n-element vector where n is the number of edges

•
S
<฀, ฀, …, ฀>
The i-th position in the vector is the number of occurrences of edge i in the path
 30

Example Paths
Paths:

e10
e1

e6
e2
e3
e4
e5

e7
e8
e9
e10
e1 n1
if expression1 then P1 = e1, e2, e4, e6, e7, e8 1, 1, 0, 1, 0, 1, 1, 1, 0, 0
statement2 n2 e3
end if P2 = e1, e2, e4, e5, e4, e6, e7, e8 1, 1, 0, 2, 1, 1, 1, 1, 0, 0
e2 n3
do P3 = e3, e4, e6, e7, e8, e10 0, 0, 1, 1, 0, 1, 1, 1, 0, 1
e4 e5
statement3
P4 = e6, e7, e8, e10, e3, e4 0, 0, 1, 1, 0, 1, 1, 1, 0, 1
while expr4 n4
end do e6 P5 = e1, e2, e4, e6, e9, e10 1, 1, 0, 1, 0, 1, 0, 0, 1, 1
if expression5 then e7 n5 P6 = e4, e5 0, 0, 0, 1, 1, 0, 0, 0, 0, 0
statement6
n6 e9
end if P7 = e3, e4, e6, e9, e10 0, 0, 1, 1, 0, 1, 0, 0, 1, 1
statement7 e8 n7 P8 = e1, e2, e4, e5, e4, e6, e9, e10 1, 1, 0, 2, 1, 1, 0, 0, 1, 1

m
o
NOTE: A path does not need to start in node n1 and
does not need to begin and end at the same node.

.c
E.g.,
 Path P4 starts (and ends) at node n4

a
 Path P1 starts at node n1 and ends at node n7

m
Paths in Graphs (2)
a
•
n
A circuit is a path that begins and ends at the same node
–
y
e.g., P3 = <e3, e4, e6, e7, e8, e10> begins and ends at node n1
–
d
P6 = <e4, e5> begins and ends at node n3
•
u
A cycle is a circuit with no node (other than the starting node) included more than once

t
S
 31

Example Circuits & Cycles

Circuits:

e10
e1

e6
e2
e3
e4
e5

e7
e8
e9
e10
e1 n1
if expression1 then P3 = e3, e4, e6, e7, e8, e10 0, 0, 1, 1, 0, 1, 1, 1, 0, 1
statement2 n2 e3
end if P4 = e6, e7, e8, e10, e3, e4 0, 0, 1, 1, 0, 1, 1, 1, 0, 1
e2 n3
do P5 = e1, e2, e4, e6, e9, e10 1, 1, 0, 1, 0, 1, 0, 0, 1, 1
e4 e5
statement3
P6 = e4, e5 0, 0, 0, 1, 1, 0, 0, 0, 0, 0
while expr4 n4
end do e6 P7 = e3, e4, e6, e9, 10 0, 0, 1, 1, 0, 1, 0, 0, 1, 1

m
if expression5 then e7 n5 P8 = e1, e2, e4, e5, e4, e6, e9, e10 1, 1, 0, 2, 1, 1, 0, 0, 1, 1
statement6
e9

o
end if n6 P9 = e3, e4, e5, e4, e6, e9, 10 0, 0, 1, 2, 1, 1, 0, 0, 1, 1
statement7 e8 n7

.c
a
m
a
Cycles:
P3 = e3, e4, e6, e7, e8, e10
n
P5 = e1, e2, e4, e6, e9, e10
y
d
P6 = e4, e5

u
P7 = e3, e4, e6, e9, 10

t
S
Linearly Independent Paths
• A path p is said to be a linear combination of paths p1, …, pn if there are integers a1, …, an
such that p = aipi
• A set of paths is linearly independent if no path in the set is a linear combination of any
other paths in the set
• A basis set of cycles is a maximal linearly independent set of cycles
– In a graph with e edges and n nodes, the basis has e  n + 1 cycles
• Every path is a linear combination of basis cycles
 32

Baseline method for finding the basis set of cycles

• Start at the source node
• Follow the leftmost path until the sink node is reached
• Repeatedly retrace this path from the source node, but change decisions at every node
with out-degree ≥2, starting with the decision node lowest in the path

Linearly Independent Paths

Paths:
m

e10
e1

e6
e2
e3
e4
e5

e7
e8
e9
o
e10
e1 n1
if expression1 then P1 = e1, e2, e4, e6, e7, e8 1, 1, 0, 1, 0, 1, 1, 1, 0, 0

.c
statement2 n2 e3
end if P2 = e1, e2, e4, e5, e4, e6, e7, e8 1, 1, 0, 2, 1, 1, 1, 1, 0, 0
e2 n3
P3 = e3, e4, e6, e7, e8, e10 0, 0, 1, 1, 0, 1, 1, 1, 0, 1

a
do e4
statement3 e5
P4 = e6, e7, e8, e10, e3, e4 0, 0, 1, 1, 0, 1, 1, 1, 0, 1
while expr4 n4

m
end do e6 P5 = e1, e2, e4, e6, e9, e10 1, 1, 0, 1, 0, 1, 0, 0, 1, 1

a
if expression5 then e7 n5 P6 = e4, e5 0, 0, 0, 1, 1, 0, 0, 0, 0, 0
statement6
n6 e9

n
end if P7 = e3, e4, e6, e9, 10 0, 0, 1, 1, 0, 1, 0, 0, 1, 1
statement7 e8 n7 P8 = e1, e2, e4, e5, e4, e6, e9, e10 1, 1, 0, 2, 1, 1, 0, 0, 1, 1

y
d
V(G) = e – n + 2 = 9 – 7 + 2 = 4
Or, if we count e10, then e – n + 1 = 10 – 7 + 1 = 4

u EXAMPLE #1: P5 + P6 = P8 EXAMPLE #2: 2P3 – P5 + P6 =

Cycles: t P5 {1, 1, 0, 1, 0, 1, 0, 0, 1, 1} 2P3 { 0, 0, 2, 2, 0, 2, 2, 2, 0, 2}

S
P3 = e3, e4, e6, e7, e8, e10
+ P6 {0, 0, 0, 1, 1, 0, 0, 0, 0, 0}
= P8 {1, 1, 0, 2, 1, 1, 0, 0, 1, 1}
– P5
___
+ P6
{ 1, 1, 0, 1, 0, 1, 0, 0, 1, 1}
{-1,-1, 2, 1, 0, 1, 2, 2,-1, 1}
{ 0, 0, 0, 1, 1, 0, 0, 0, 0, 0}
P5 = e1, e2, e4, e6, e9, e10 = P? {-1,-1, 2, 2, 1, 1, 2, 2,-1, 1}
P6 = e4, e5
P7 = e3, e4, e6, e9, 10

Unit Testing: Path Coverage

– Finds the number of distinct paths through the program to be traversed at least
once
• Minimum number of tests necessary to cover all edges is equal to the number of
 33

independent paths through the control-flow graph

Issues (1)

Single statement: Two (or more) statements:

stat-1

statement
= CC = stat-2

m
Cyclomatic complexity (CC) remains the same for a linear sequence of
o
.c
statements regardless of the sequence length
—insensitive to complexity contributed by the multitude of statements

a
m
a
n(2)
Issues
y
d
Optional action: u Alternative choices:

t
S
T
expr
?
F
= CC =
T
expr
?
F

Optional action versus alternative choices —

the latter is psychologically more difficult
 34

Issues (3)
Simple condition: Compound condition:

if (A) then D; if (A OR B) then D;

T T
A? A || D ?

D F
= CC = F

BUT, compound condition can be written T F

A?
as a nested IF:
D T
if (A) then D; B?

else if (B) then D; D F

m
o
Issues (4)
.c
a
Switch/Case statement:
m
N1 predicates:

1
expr
N
a T expr=1 F

= CC =n
? ?
2
statm1 T expr=2 F
statm1 statm2 statmN ?

y
statm2
T expr=N
?

d
statmN

Counting a switch statement:

—as a single decision u
t
proposed by W. J. Hansen, “Measurement of program complexity by the pair (cyclomatic number, operator count),”
SIGPLAN Notices, vol.13, no.3, pp.29-33, March 1978.

S
—as log2(N) relationship
proposed by V. Basili and R. Reiter, “Evaluating automatable measures for software development,”•Proceedings of the
IEEE Workshop on Quantitative Software Models for Reliability, Complexity and Cost , pp.107-116, October 1979.
 35

CC for Modular Programs (2)

Intuitive expectation:
Modularization should not increase complexity

V=e–n+2 V = e – n + 2p
= 12 – 11 + 2 = 3 = 10 – 10 + 2 x 2 = 4
n0 n0

A:
n1 n3 n1 n3

CALL A

n2 n4 n5 n2 n9 n4 n5

n7 n6 n7 n6

n8 n8

m
o
Issues (5) .c
a
Two sequential decisions: m
Two nested decisions:

a
n
T F T F
expr1 expr1
? ?

y=
T F
expr2

T
expr2
F
= CC ?

d
?

u
t
S
But, it is known that people find nested decisions more difficult …
 36

CC for Modular Programs (1)

Adding a sequential node
does not change CC:
V=e–n+2
= 12 – 11 + 2 = 3
n0 n0

n1 n3 n1 n3
n9'

n2 n4 n5 n2 n4 n5

n9"
n7 n6 n7 n6

m
n8 n8
o
.c
19

Alternative CC Measures
• Given p connected components of a graph:
a
– V(G) = e – n + 2p (1) m
– VLI(G) = e – n + p + 1 a (2)
– n
Eq. (2) is known as linearly-independent cyclomatic complexity
– y
VLI does not change when program is modularized into p modules
d
u
t
S
 37

CC for Modular Programs (3)

Intuitive expectation:
Modularization should not increase complexity

V=e–n+2 V = e – n + 2p
= 12 – 11 + 2 = 3 = 10 – 10 + 2 x 2 = 4
n0 n0

A:
n1 n3 n1 n3

CALL A

n2 n4 n5 n2 n9 n4 n5

n7 n6 n7
m n6

o
.c
VLI = e – n + p + 1 VLI = e – n + p + 1
n8 n8
= 12 – 11 + 1 + 1 = 3 = 10 – 10 + 2 + 1 = 3

a
m
a
n
y
d
u
t
S
 38

UNIT-04/LECTURE-07

Example of Test Case Design

Initial Functional Test Cases for Example ATM System
The following initial test cases can be identified early in the design process as a vehicle for
checking that the implementation is basically correct. No attempt has been made at this point
to do thorough testing, including all possible errors and boundary cases. That needs to come
later. These cases represent an initial check that the functionality specified by the use cases is
present.
Some writers would argue for developing test cases like these in place of use cases. Here, they
are presented as a vehicle for "fleshing out" the use cases, not as a substitute for them.

Use Case
Function Being Initial System
Input m
Expected Output
Tested State
o
.c
System is started
System Activate the "on" System requests

a
when the switch is System is off
Startup switch initial cash amount
turned "on"

System is m
System System accepts
a
requesting cash
Enter a legitimate
System is on
Startup initial cash amount
n
amount
amount

y
d
System output

u
Perform a should demonstrate
System Connection to the System has just
Startup t
bank is established been turned on
legitimate inquiry that a connection has

S transaction been established to

the Bank

System is shut down System is on and

System Activate the "off"
when the switch is not servicing a System is off
Shutdown switch
turned "off" customer

Connection to the Verify from the bank

System Bank is terminated System has just side that a
Shutdown when the system is been shut down connection to the
shut down ATM no longer exists
 39

System reads a System is on and Card is accepted;

Insert a readable
Session customer's ATM not servicing a System asks for entry
card
card customer of PIN

Card is ejected;
System is on and System displays an
System rejects an Insert an
Session not servicing a error screen;
unreadable card unreadable card
customer System is ready to
start a new session

System displays a
System accepts System is asking
Session Enter a PIN menu of transaction
customer's PIN for entry of PIN
types

System allows System is m

customer to displaying menu Perform a o System asks whether

.c
Session customer wants
perform a of transaction transaction
another transaction
transaction types
a
System allows
System is asking
m
multiple a
whether System displays a

n
Session customer wants Answer yes menu of transaction
transactions in one

y
another types
session

d
transaction

u System is asking

t
Session ends when
whether System ejects card

S
customer chooses
Session customer wants Answer no and is ready to start a
not to do another
another new session
transaction
transaction

Individual types of
Transaction transaction will be
tested below

Enter an incorrect The Invalid PIN

System handles an A readable card
Transaction PIN and then Extension is
invalid PIN properly has been entered
attempt a performed
 40

transaction

System asks
Menu of Choose System displays a
customer to choose
Withdrawal transaction types Withdrawal menu of account
an account to
is being displayed transaction types
withdraw from

System asks
Menu of account System displays a
customer to choose Choose checking
Withdrawal types is being menu of possible
a dollar amount to account
displayed withdrawal amounts
withdraw

System dispenses this

amount of cash;

m
System prints a
Choose an o correct receipt

System performs a
System is
.c
amount that the showing amount and

legitimate
displaying the
a
system currently correct updated

m
Withdrawal menu of has and which is balance;
withdrawal

a
withdrawal not greater than System records
transaction properly

n
amounts the account transaction correctly

y
balance in the log (showing

d
both message to the

u
bank and approval

t
back)

S System has been

started up with
less than the
Choose an System displays an
System verifies that maximum
amount greater appropriate message
it has sufficient cash withdrawal
Withdrawal than what the and asks customer to
on hand to fulfill the amount in cash
system currently choose a different
request on hand;
has amount
System is
requesting a
withdrawal
 41

amount

System displays an
Choose an
appropriate message
System verifies that System is amount that the
and offers customer
customer's balance requesting a system currently
Withdrawal the option of
is sufficient to fulfill withdrawal has but which is
choosing to do
the request ammount greater than the
another transaction
account balance
or not.

System displays an
A withdrawal
appropriate message
transaction can be
System is and offers customer

m
cancelled by the
Withdrawal displaying menu Press "Cancel" key the option of

o
customer any time
of account types choosing to do

.c
prior to choosing
another transaction
the dollar amount

a
or not.

m
System displays an
A withdrawal

a
appropriate message
transaction can be System is

n
and offers customer
cancelled by the displaying menu

y
Withdrawal Press "Cancel" key the option of
customer any time of dollar

d
choosing to do
prior to choosing amounts

u
another transaction
the dollar amount

t
or not.

S
System asks
customer to choose
Menu of
Choose Deposit
System displays a
Deposit transaction types menu of account
an account to transaction
is being displayed types
deposit to

System asks System displays a

Menu of account
customer to enter a Choose checking request for the
Deposit types is being
dollar amount to account customer to type a
displayed
deposit dollar amount

Deposit System asks System is Enter a legitimate System requests that

 42

customer to insert displaying a dollar amount customer insert an

an envelope request for the envelope
customer to type
a dollar amount

System accepts
envelope;
System prints a
correct receipt
showing amount and
System is correct updated
System performs a
requesting that Insert an balance;
Deposit legitimate deposit
transaction properly
customer insert envelope
m
System records
an envelope
o transaction correctly

.c
in the log (showing

a
message to the bank,
approval back, and

m acceptance of the

a envelope)

n System displays an
A deposit
y appropriate message

d
transaction can be
System is and offers customer
Deposit u
cancelled by the
displaying menu Press "Cancel" key the option of
t
customer any time
of account types choosing to do
S
prior to inserting an
envelope
another transaction
or not.

System displays an
A deposit
System is appropriate message
transaction can be
requesting and offers customer
cancelled by the
Deposit customer to Press "Cancel" key the option of
customer any time
enter a dollar choosing to do
prior to inserting an
amount another transaction
envelope
or not.
 43

System displays an
A deposit
System is appropriate message
transaction can be
requesting and offers customer
cancelled by the
Deposit customer to Press "Cancel" key the option of
customer any time
insert an choosing to do
prior to inserting an
envelope another transaction
envelope
or not.

A deposit System displays an

transaction is System is appropriate message
cancelled requesting Wait for the and offers customer
Deposit automatically if an customer to request to time the option of
envelope is not insert an out
m
choosing to do
inserted within a envelope
o another transaction

.c
reasonable time or not.

a
System asks System displays a
Menu of
customer to choose Choose Transfer menu of account
Transfer
an account to
transaction types
m transaction types specifying
transfer from a
is being displayed
transfer from

n
y
System asks Menu of account System displays a

d
customer to choose types to transfer Choose checking menu of account
Transfer

u
an account to from is being account types specifying

t
transfer to displayed transfer to

S
System asks Menu of account
customer to enter a types to transfer Choose savings
System displays a
request for the
Transfer
dollar amount to to is being account customer to type a
transfer displayed dollar amount

System is System prints a

System performs a displaying a correct receipt
Enter a legitimate
Transfer legitimate transfer request for the showing amount and
dollar amount
transaction properly customer to type correct updated
a dollar amount balance;
 44

System records
transaction correctly
in the log (showing
both message to the
bank and approval
back)

System displays an
A transfer
System is appropriate message
transaction can be
displaying menu and offers customer
cancelled by the
Transfer of account types Press "Cancel" key the option of
customer any time
specifying choosing to do
prior to entering
dollar amount
transfer from
m
another transaction

o or not.

.c
System displays an
A transfer

a
System is appropriate message
transaction can be
displaying menu and offers customer
Transfer
cancelled by the
m
of account types Press "Cancel" key the option of
customer any time
a
specifying choosing to do
prior to entering
n
transfer to another transaction
dollar amount
y or not.

d
u
System displays an
A transfer

t
System is appropriate message
transaction can be

S
requesting and offers customer
cancelled by the
Transfer customer to Press "Cancel" key the option of
customer any time
enter a dollar choosing to do
prior to entering
amount another transaction
dollar amount
or not.

System asks
Menu of System displays a
customer to choose Choose Inquiry
Inquiry transaction types menu of account
an account to transaction
is being displayed types
inquire about
 45

System prints a
correct receipt
showing correct
balance;
System performs a System is
Choose checking System records
Inquiry legitimate inquiry displaying menu
account transaction correctly
transaction properly of account types
in the log (showing
both message to the
bank and approval
back)

System displays an
An inquiry
transaction can be m
appropriate message

cancelled by the
System is
o and offers customer

.c
Inquiry displaying menu Press "Cancel" key the option of
customer any time

a
of account types choosing to do
prior to choosing an
another transaction

m
account
or not.

a Enter an incorrect

n PIN;

y Attempt an
Invalid PIN
d
Customer is asked
inquiry
Customer is asked to
Extension
u
to re-enter PIN
transaction on the
re-enter PIN

t customer's
S checking account

Request to re- Original transaction

Invalid PIN Correct re-entry of
enter PIN is being Enter correct PIN completes
Extension PIN is accepted
displayed successfully

An incorrect PIN
A correctly re-
has been re- This transaction
Invalid PIN entered PIN is used Perform another
entered and completes
Extension for subsequent transaction
transaction successfully as well
transactions
completed
 46

normally

An appropriate
Request to re- message is displayed
Invalid PIN Incorrect re-entry of Enter incorrect
enter PIN is being and re-entry of the
Extension PIN is not accepted PIN
displayed PIN is again
requested

Enter incorrect
Correct re-entry of Request to re- Original transaction
Invalid PIN PIN the first time,
PIN on the second enter PIN is being completes
Extension then correct PIN
try is accepted displayed successfully
the second time

Enter incorrect
Correct re-entry of Request to re- m
PIN the first time Original transaction
Invalid PIN
o
PIN on the third try enter PIN is being and second times, completes

.c
Extension
is accepted displayed then correct PIN successfully

a
the third time

Three incorrect re- m An appropriate

Invalid PIN entries of PIN result a

Request to re-
Enter incorrect
message is displayed;

n
enter PIN is being Card is retained by
Extension in retaining card and PIN three times

y
displayed machine;
aborting transaction

d
Session is terminated

u
t
S
 47

UNIT-04/LECTURE-08

Software Evolution
 It is impossible to produce system of any size which do not need to be changed. Once
software is put into use, new requirements emerge and existing requirements changes as
the business running that software changes.
 Parts of the software may have to be modified to correct errors that are found in operation,
improve its performance or other non-functional characteristics.
 All of this means that, after delivery, software systems always evolve in response to demand
for change.

m
o
Program Evolution Dynamic

.c
 Program evolution dynamic is the study of system change. The majority of work in
this area has been carried out by Lehman and Belady. From these studies , they
proposed a sets of laws concerning system change.a
m
a
n
y
d
u
t
S
 48

Software Evolution Approaches

 There are a number of different strategies for software change.[SOM2004]
 Software maintenance
 Architectural transformation
 Software re-engineering.
 Software maintenance
 Changes to the software are made in response to changed requirements but the
fundamental structure of the software remains stable. This is most common approach
used to system change.

m
o
.c
a
m
a
n
y
d
u
t
S
 49

UNIT-04/LECTURE-09
Maintenance activities[RGPV/June 2014(7)]
 Software maintenance is the general process of changing a system after it has been diverted.
 The change may be simple changes to correct coding errors, more extensive changes to
correct design errors or significant enhancement to correct specification error or
accommodate new requirements.

Maintenance Characteristics
 We need to look at maintenance from three different viewpoints: [PRE2004]
– the activities required to accomplish the maintenance phase and the impact of a
software engineering approach (or lack thereof) on the usefulness of such
activities m
– the costs associated with the maintenance phase o
–
.c
the problems that are frequently encountered when software maintenance is
undertaken
a
The Maintenance Process m
 a
Maintenance process vary considerably depending on the types of software being
n
maintained, the development processes used in an organization and people involved
in the process. y
d
u
t
S

Types of Maintenance

Corrective maintenance

Corrective maintenance deals with the repair of faults or defects found in day-today system
 50

functions. A defect can result due to errors in software design, logic and coding. Design errors
occur when changes made to the software are incorrect, incomplete, wrongly communicated,
or the change request is misunderstood. Logical errors result from invalid tests and conclusions,
incorrect implementation of design specifications, faulty logic flow, or incomplete test of data.
All these errors, referred to as residual errors, prevent the software from conforming to its
agreed specifications. Note that the need for corrective maintenance is usually initiated by bug
reports drawn by the users.

In the event of a system failure due to an error, actions are taken to restore the operation of
the software system. The approach in corrective maintenance is to locate the original
specifications in order to determine what the system was originally designed to do. However,
due to pressure from management, the maintenance team sometimes resorts to emergency

m
fixes known as patching. Corrective maintenance accounts for 20% of all the maintenance
activities. o
.c
Adaptive Maintenance a
m
Adaptive maintenance is the implementation of changes in a part of the system, which has

a
been affected by a change that occurred in some other part of the system. Adaptive

n
maintenance consists of adapting software to changes in the environment such as the

y
hardware or the operating system. The term environment in this context refers to the

d
conditions and the influences which act (from outside) on the system. For example, business

u
t
rules, work patterns, and government policies have a significant impact on the software system.

S
For instance, a government policy to use a single 'European currency' will have a significant
effect on the software system. An acceptance of this change will require banks in various
member countries to make significant changes in their software systems to accommodate this
currency. Adaptive maintenance accounts for 25% of all the maintenance activities.

Perfective Maintenance

Perfective maintenance mainly deals with implementing new or changed user requirements.
Perfective maintenance involves making functional enhancements to the system in addition to
the activities to increase the system's performance even when the changes have not been
suggested by faults. This includes enhancing both the function and efficiency of the code and
 51

Examples of perfective maintenance include modifying the payroll program to incorporate a

new union settlement and adding a new report in the sales analysis system. Perfective
maintenance accounts for 50%, that is, the largest of all the maintenance activities.

Preventive Maintenance

Preventive maintenance involves performing activities to prevent the occurrence of errors. It

tends to reduce the software complexity thereby improving program understandability and
increasing software maintainability. It comprises documentation updating, code optimization,
and code restructuring. Documentation updating involves modifying the documents affected by
the changes in order to correspond to the present state of the system. Code optimization
involves modifying the programs for faster execution or efficient use of storage space. Code

m
restructuring involves transforming the program structure for reducing the complexity in source

o
code and making it easier to understand.

.c
Preventive maintenance is limited to the maintenance organization only and no external
requests are acquired for this type of maintenance. Preventive maintenance accounts for only
5% of all the maintenance activities. a
S.NO RGPV QUESTION
m YEAR MARKS
Q.1 Discuss briefly on
a
software Jun.2014 7
maintenance activities & how
n
do you estimate
y the cost

d
involved. Explain.

u
t
S
REFERENCCE

BOOK AUTHOR PRIORITY

Software 1
Engineering P,S. Pressman
Software 2
Engineering Pankaj jalote
 52

m
o
.c
a
m
a
n
y
d
u
t
S
 1

UNIT-05/LECTURE-01
Matrix Organization: [RGPV/June 2012(10)]
An organizational structure that facilitates the horizontal flow of skills and information. It is
used mainly in the management of large projects or product development processes, drawing
employees from different functional disciplines for assignment to a team without removing
them from their respective positions.
Employees in a matrix organization report on day-to-day performance to the project or product
manager whose authority flows sideways (horizontally) across departmental boundaries. They
also continue to report on their overall performance to the head of their department whose
authority flows downwards (vertically) within his or her department. In addition to a multiple
command and control structure, a matrix organization necessitates new support mechanisms,

m
organizational culture, and behaviour patterns. Developed at the US National Aeronautics &

o
Space Administration (NASA) in association with its suppliers, this structure gets its name from

.c
its resemblance to a table (matrix) where every element is included in a row as well as a
column.

a
m
RMMM[RGPV/June 2012(10)]

a
RISK MITIGATION, MONITORING, AND MANAGEMENT (RMMM) PLAN

n
The RMMM Plan maybe developed in the form of a document. Alternatively, an organization

y
may create a set of Risk Information Sheets (RIS) [often in electronic form] that contain all

d
pertinent information outlined below. IMPORTANT note: Like most software engineering

u
documents, the RMMM Plan evolves over time.
1.0 Introduction
t
S
This section provides an overview of the RMMM Plan.
1.1 Scope and intent of RMMM activities
A description of the overall RMMM focus including objectives, organizational responsibilities.
1.2 Risk management organizational role
Description of who has responsibility for risk management.

2.0 Project risks

This section describes all known project risks.
2.1 Risk table
A presentation of all risks, probabilities and impact.
 2

2.1.1 Description of risk m

Risk m is described along with relevant sub conditions. Section2.1.1 is repeated for each of m
risks.
2.1.2 Probability and impact for risk m
Probability and impact for risk m is described Section 2.1.2 is repeated for each of m risks.
2.2 Risk refinement
High probability/high impact risks are refined using the CTC approach.

3.0 Risk mitigation, monitoring, and management

This section discusses RMMM for each risk.
3.1 Risk mitigation for risk m
How do we avoid risk m? Section 3.1 is repeated for each of m risks.
3.2 Risk monitoring for risk m m
o
What conditions do we monitor to determine whether risk m is becoming more or less likely?
Section3.2 is repeated for each of m risks.
.c
3.3 Risk management for risk m
a
m
What contingency plans should we put into plan under the assumption that risk m will occur?

a
Section 3.3 is repeated for each of m risks.

n
y
Software Project Scheduling[RGPV/June 2012(10),June 2014(5)]

d
u
- Introduction

t
- Project scheduling

S
- Task network
- Timeline chart
- Earned value analysis

Introduction
Eight Reasons for Late Software Delivery
• An unrealistic deadline established by someone outside the software engineering group
and forced on managers and practitioners within the group
• Changing customer requirements that are not reflected in schedule changes
• An honest underestimate of the amount of effort and /or the number of resources that
 3

will be required to do the job

• Predictable and/or unpredictable risks that were not considered when the project
commenced
• Technical difficulties that could not have been foreseen in advance
• Human difficulties that could not have been foreseen in advance
• Miscommunication among project staff that results in delays
• A failure by project management to recognize that the project is falling behind schedule
and a lack of action to correct the problem
Handling Unrealistic Deadlines
• Perform a detailed estimate using historical data from past projects; determine the
estimated effort and duration for the project
• Using an incremental model, develop a software engineering strategy that will deliver

m
critical functionality by the imposed deadline, but delay other functionality until later;
document the plan o
•
.c
Meet with the customer and (using the detailed estimate) explain why the imposed
deadline is unrealistic
–
a
m
Be certain to note that all estimates are based on performance on past projects
–
a
Also be certain to indicate the percent improvement that would be required to

n
achieve the deadline as it currently exists

y
1) Offer the incremental development strategy as an alternative and offer some options
–
d
Increase the budget and bring on additional resources to try to finish sooner
–
u
Remove many of the software functions and capabilities that were requested
–
t
Dispense with reality and wish the project complete using the prescribed

S
schedule; then point out that project history and your estimates show that this is
unrealistic and will result in a disaster
Project Scheduling
General Practices
• On large projects, hundreds of small tasks must occur to accomplish a larger goal
– Some of these tasks lie outside the mainstream and may be completed without
worry of impacting on the project completion date
– Other tasks lie on the critical path; if these tasks fall behind schedule, the
completion date of the entire project is put into jeopardy
• Project manager’s objectives
 4

– Define all project tasks

– Build an activity network that depicts their interdependencies
– Identify the tasks that are critical within the activity network
– Build a timeline depicting the planned and actual progress of each task.
– Track task progress to ensure that delay is recognized one day at a time .
– To do this, the schedule should allow progress to be monitored and the project
to be controlled.
• On large projects, hundreds of small tasks must occur to accomplish a larger goal.
– Some of these tasks lie outside the mainstream and may be completed without
worry of impacting on the project completion date
– Other tasks lie on the critical path; if these tasks fall behind schedule, the
completion date of the entire project is put into jeopardy.
• Project manager’s objectives m
– Define all project tasks o
–
.c
Build an activity network that depicts their interdependencies.
–
–
a
Identify the tasks that are critical within the activity network.

m
Build a timeline depicting the planned and actual progress of each task.
–
a
Track task progress to ensure that delay is recognized one day at a time .
–
n
To do this, the schedule should allow progress to be monitored and the project

y
to be controlled.

d
Basic Principles for Project Scheduling
•
u
Compartmentalization
–
t
The project must be compartmentalized into a number of manageable activities,

S
actions, and tasks; both the product and the process are decomposed.
• Interdependency
– The interdependency of each compartmentalized activity, action, or task must be
determined.
– Some tasks must occur in sequence while others can occur in parallel.
– Some actions or activities cannot commence until the work product produced by
another is available.
• Time allocation
– Each task to be scheduled must be allocated some number of work units.
– In addition, each task must be assigned a start date and a completion date that is
 5

a function of the interdependencies.

– Start and stop dates are also established based on whether work will be
conducted on a full-time or part-time basis.

• Effort validation
– Every project has a defined number of people on the team.
– As time allocation occurs, the project manager must ensure that no more than
the allocated number of people has been scheduled at any given time.
• Defined responsibilities
– Every task that is scheduled should be assigned to a specific team member.
• Defined outcomes
– m
Every task that is scheduled should have a defined outcome for software

o
projects such as a work product or part of a work product.
–
.c
Work products are often combined in deliverables.
• Defined milestones
–
a
m
Every task or group of tasks should be associated with a project milestone
–
a
A milestone is accomplished when one or more work products has been

n
reviewed for quality and has been approved

y
d
S.NO RGPV QUESTION YEAR MARKS

u
Q.1 Briefly describe Software Jun.2012 10

t
project management standards.
Q.2
S
Write short notes on Software
project management standards.
Jun.2014 5

Q.3 Explain Matrix Organization in June2011 10

detail.
Q.4 Explain RMMM in detail June2012 10
 6

UNIT-05/LECTURE-02

Task Network:
Defining a Task Set
• A task set is the work breakdown structure for the project
• No single task set is appropriate for all projects and process models
– It varies depending on the project type and the degree of rigor (based on
influential factors) with which the team plans to work
• The task set should provide enough discipline to achieve high software quality
– But it must not burden the project team with unnecessary work
Types of Software Projects
•
m
Concept development projects
–
o
Explore some new business concept or application of some new technology
•

.c
New application development
– Undertaken as a consequence of a specific customer request
• Application enhancement
a
–
m
Occur when existing software undergoes major modifications to function,

a
performance, or interfaces that are observable by the end user

n
• Application maintenance

y
– Correct, adapt, or extend existing software in ways that may not be immediately

d
obvious to the end user

u
• Reengineering projects
–
t
Undertaken with the intent of rebuilding an existing (legacy) system in whole or

S
in part

Factors that Influence a Project’s Schedule

• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
 7

• Performance constraints
• Embedded and non-embedded characteristics
• Project staff
• Reengineering factors

Purpose of a Task Network

• Also called an activity network
• It is a graphic representation of the task flow for a project
• It depicts task length, sequence, concurrency, and dependency
• Points out inter-task dependencies to help the manager ensure continuous progress
toward project completion
• The critical path
– A single path leading from start to finish in a task network m
– o
It contains the sequence of tasks that must be completed on schedule if the
project as a whole is to be completed on schedule
.c
–
a
It also determines the minimum duration of the project

m
Example a
Task Network
n
y
d
u Task F
2
Task G
3
Task H
5

t
Task B
3

S
Task N
2
Task A
3 Task C Task E Task I Task J
7 8 4 5
Task M
0

Task D
5 Task K Task L
3 10

Where is the critical path and what tasks are on it?

 8

Example Task Network

with Critical Path Marked

Task F Task G Task H

2 3 5
Task B
3

Task N
2
Task A
3 Task C Task E Task I Task J
7 8 4 5
Task M
0

Task D
5 Task K Task L
3 10

Critical path: A-B-C-E-K-L-M-N

m
o
.c
a
m
a
n
y
d
u
t
S
 9

UNIT-05/LECTURE-03

Timeline Chart

Mechanics of a Timeline Chart

• Also called a Gantt chart; invented by Henry Gantt, industrial engineer, 1917

• All project tasks are listed in the far left column

• The next few columns may list the following for each task: projected start date,

m
projected stop date, projected duration, actual start date, actual stop date, actual

o
duration, task inter-dependencies (i.e., predecessors)‫‏‬

•
.c
To the far right are columns representing dates on a calendar

a
•
m
The length of a horizontal bar on the calendar indicates the duration of the task

a
n
• When multiple bars occur at the same time interval on the calendar, this implies task

y
concurrency

d
u
• A diamond in the calendar area of a specific task indicates that the task is a milestone; a

t
milestone has a time duration of zero

S
 10

Timeline chart: SOLUTION

4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3

Task # Task Name Duration Start Finish Pred.

A Establish increments 3 4/1 4/3 None
B Analyze Inc One 3 4/4 4/6 A
C Design Inc One 8 4/7 4/14 B
D Code Inc One 7 4/15 4/21 C
E Test Inc One 10 4/22 5/1 D
F Install Inc One 5 5/2 5/6 E
G Analyze Inc Two 7 4/7 4/13 A, B
H Design Inc Two 5 4/14 4/18 G m
o
.c
I Code Inc Two 4 4/19 4/22 H
J Test Inc Two 6 5/2 5/7 E, I
K Install Inc Two 2 5/8 5/9 J
a
L Close out project 2 5/10 5/11
m
F, K

a
Task network and the critical path: A-B-C-D-E-J-K-L
n
y
d
B. Analyze C. Design D. Code E. Test F. Install
Inc One Inc One Inc One Inc One Inc One

u 3 8 7 10 5

t
A. Establish
Increments L. Close out
3
S Project
2
G. Analyze H. Design I. Code J. Test K. Install
Inc Two Inc Two Inc Two Inc Two Inc Two
7 5 4 6 2
 11

Task Network for a Long-Distance Move of 8,000 lbs of Household Goods

2. Get money
to pay for
the move

3. Determine
date to move
out or move in
12. Plan travel 13. Find lodging 14. Make
4. Determine
route and with space lodging
destination overnight stops to park truck reservations
location
5. Lease or buy
home at
m
o
destination
1. Make 18. Drive truck

.c
6. Decide on 19. Unload
decision 11. Milestone from origin
type/size of truck
to move to destination
rental truck
a
m
7. Arrange for
workers to
load truck
a15. Reserve
8. Arrange for
n rental truck
16. Pick up 17. Load 20. Return

y
rental truck truck truck and
person to and supplies
supplies
d
drive truck/car

u
9. Arrange for

t • Where is the critical path and what tasks are on it?

workers to
unload truck
• Given a firm start date, on what date will
S 10. Pack the project be completed?
household • Given a firm stop date, when is the latest date
goods that the project must start by?
 12

Timeline Chart for Long Distance Move

m
o
.c
a
m
a
n
y
d
u
t 28
S
 13

UNIT-05/LECTURE-04
Example Timeline Chart:

Example Timeline Chart

m
o
.c
a
m
a
n
y
d
u
t
S

29
 14

Methods for Tracking the Schedule

• Qualitative approaches
– Conduct periodic project status meetings in which each team member reports
progress and problems
– Evaluate the results of all reviews conducted throughout the software
engineering process
– Determine whether formal project milestones (i.e., diamonds) have been
accomplished by the scheduled date
– Compare actual start date to planned start date for each project task listed in the
timeline chart
– Meet informally with the software engineering team to obtain their subjective
assessment of progress to date and problems on the horizon m
• Quantitative approach o
–
.c
Use earned value analysis to assess progress quantitatively

a
m
Project Control and Time Boxing
•
a
The project manager applies control to administer project resources, cope with

n
problems, and direct project staff
•
y
If things are going well (i.e., schedule, budget, progress, milestones) then control should

d
be light
•
u
When problems occur, the project manager must apply tight control to reconcile the

t
problems as quickly as possible. For example:

S
– Staff may be redeployed
– The project schedule may be redefined
• Severe deadline pressure may require the use of time boxing
– An incremental software process is applied to the project
– The tasks associated with each increment are time-boxed (i.e., given a specific
start and stop time) by working backward from the delivery date
– The project is not allowed to get stuck on a task
– When the work on a task hits the stop time of its box, then work ceases on that
task and the next task begins
– This approach succeeds based on the premise that when the time-box boundary
 15

is encountered, it is likely that 90% of the work is complete

– The remaining 10% of the work can be
• Delayed until the next increment

Milestones for OO Projects

• Task parallelism in object-oriented projects makes project tracking more difficult to do
than non-OO projects because a number of different activities can be happening at once
• Sample milestones
– Object-oriented analysis completed
– Object-oriented design completed
– Object-oriented coding completed
– Object-oriented testing completed
• m
Because the object-oriented process is an iterative process, each of these milestones

o
may be revisited as different increments are delivered to the customer

.c
Earned Value Analysis
•
a
m
Earned value analysis is a measure of progress by assessing the percent of completeness

a
for a project
•
n
It gives accurate and reliable readings of performance very early into a project
•
y
It provides a common value scale (i.e., time) for every project task, regardless of the type

d
of work being performed
•
u
The total hours to do the whole project are estimated, and every task is given an earned

t
value based on its estimated percentage of the total

S
Determining Earned Value
• Compute the budgeted cost of work scheduled (BCWS) for each work task i in the
schedule
– The BCWS is the effort planned; work is estimated in person-hours or person-
days for each task
– To determine progress at a given point along the project schedule, the value of
BCWS is the sum of the BCWSi values of all the work tasks that should have been
completed by that point of time in the project schedule
• Su ‫‏‬up‫‏‬the‫‏‬BCWS‫ ‏‬alues‫‏‬for‫‏‬all‫ ‏‬ork‫‏‬tasks‫‏‬to‫‏‬deri e‫‏‬the‫ ‏‬udget‫‏‬at‫ ‏‬o pletio ‫ ‏‬BAC ‫‏‬
 16

• Co pute‫‏‬the‫ ‏‬alue‫‏‬for‫‏‬the‫ ‏‬udgeted‫ ‏‬ost‫‏‬of‫ ‏‬ork‫‏‬perfor ed‫ ‏‬BCWP ‫‏‬

– BCWP is the sum of the BCWS values for all work tasks that have actually been
completed by a point of time on the project schedule

Progress Indicators provided through Earned Value Analysis

• SPI = BCWP/BCWS
– Schedule performance index (SPI) is an indication of the efficiency with which the
project is utilizing scheduled resources
– SPI close to 1.0 indicates efficient execution of the project schedule
• SV = BCWP – BCWS
– Schedule variance (SV) is an absolute indication of variance from the planned
schedule
• PSFC = BCWS/BAC m
– o
Percent scheduled for completion (PSFC) provides an indication of the

.c
percentage of work that should have been completed by time t
• PC = BCWP/BAC
–
a
m
Percent complete (PC) provides a quantitative indication of the percent of work

a
that has been completed at a given point in time t
•
n
ACWP = sum of BCWP as of time t
–
y
Actual cost of work performed (ASWP) includes all tasks that have been

d
completed by a point in time t on the project schedule
•
u
CPI = BCWP/ACWP
–
t
A cost performance index (CPI) close to 1.0 provides a strong indication that the

S
project is within its defined budget
• CV = BCWP – ACWP
– The cost variance is an absolute indication of cost savings (against planned costs)
or shortfall at a particular stage of a project
 17

UNIT-04/LECTURE-05
Re-Engineering
Restructuring or rewriting part or all of a system without changing its functionality

• Applicable when some (but not all) subsystems of a larger system require frequent
maintenance
• Reengineering involves putting in the effort to make it easier to maintain
• The reengineered system may also be restructured and should be redocumented

When do you decide to reengineer?

• When system changes are confined to one subsystem, the subsystem needs to be
reengineered
• When hardware or software support becomes obsolete
• When tools to support restructuring are readily available

Business Process Reengineering

m
• o
Concerned with redesigning business processes to make them more responsive and

.c
more efficient
• Often relies on the introduction of new computer systems to support the revised

•
processes
a
May force software reengineering of legacy computer systems which designed to
support existing processes
m
a
n
y
Reengineering Process

System
d Design and Ne w

u
specification implementation system

t
Forward engineering
S
Existing Understanding and Re-engineered
software system transformation system

Software re-engineering

• Inventory analysis
– sorting active software applications by business criticality, longevity, current
maintainability, and other local criteria
– helps to identify reengineering candidates
 18

• Document restructuring options

– live with weak documentation
– update poor documents if they are used
– fully rewrite the documentation for critical systems focusing on the "essential
minimum"
• Reverse engineering
– process of design recovery
– analyzing a program in an effort to create a representation of the program at
some abstraction level higher than source code
• Code restructuring
– m
source code is analyzed and violations of structured programming practices are
noted and repaired o
– revised code needs to be reviewed and tested
.c
• Data restructuring
–
a
m
usually requires full reverse engineering
–
a
current data architecture is dissected
–
n
data models are defined
–
y
existing data structures are reviewed for quality
•
d
Forward engineering
–
u
sometimes called reclamation or renovation
–
t
recovers design information from existing source code

S
– uses this design information to reconstitute the existing system to improve its
overall quality or performance
 19

UNIT-05/LECTURE-06
Forward Engineering[RGPV/June 2014(5)]
Forward engineering is the process of building from a high-level model or concept to build in
complexities and lower-level details. This type of engineering has different principles in various
software and database processes.
Generally, forward engineering is important in IT because it represents the 'normal’
development process. For example, building from a model into an implementation language.
This will often result in loss of semantics, if models are more semantically detailed, or levels of
abstraction.
Forward engineering is thus related to the term 'reverse engineering,’ where there is an effort

m
to build backward, from a coded set to a model, or to unravel the process of how something
was put together.
o
.c
a
Forward Engineering Client/Server Architectures
• application functionality migrates to each client computer
• new GUI interfaces implemented at client sites m
• a
database functions allocated to servers
•
n
specialized functionality may remain at server site
•
y
new communications, security, archiving, and control requirements must be established

d
at both client and server sites

u
t
Forward Engineering User Interfaces
• S
understand the original user interface and how the data moves between the user
interface and the remainder of the application
• remodel the behavior implied by the existing user interface into a series of abstractions
that have meaning in the context of a GUI
• introduce improvements that make the mode of interaction more efficient build and
integrate the new GUI

Web Engineering[RGPV/June 2013(7)]

There is still no common answer
 20

Web Engineering is concerned with establishment and use of sound scientific,

engineering and management principles and disciplined and systematic
approaches to the successful development, deployment and maintenance of high
quality Web-based systems and applications , SIGWEB Newsletter
Web Engineering is a discipline among disciplines, cutting across computer
science, information systems, and software engineering, as well as benefiting
from several non-IT specializations , IEEE Multimedia
While Web Engineering adopts and encompasses many software engineering
principles, it incorporates many new approaches, methodologies, tools,
techniques, and guidelines to meet the unique requirements of Web-based
systems. Developing Web-based systems is significantly different from traditional
software development and poses many additional challenges , IEEE MultiMedia

m
The application of systematic, disciplined, and quantifiable approaches to the

o
design, production, deployment, operation, maintenance and evolution of Web-
based software products.
.c
a
 A holistic and proactive approach to Web systems development
 Offers systematic approaches and disciplined processes for development
m
 Deals with the management of complexity and diversity of Web development
a
 Brings to Web-based system development
 Control n
 Risk minimization y
d
 Enhanced maintainability and quality
u
t
 Other factors

S
 Document orientation
 Navigational design
 Changing technology
 Budget and time constraints
 People and internal politics
 Division between theory and practice
 Lack of understanding

 Web System – an infrastructure or system enabling the operation of a Web application

 Web Application – a distributed application that accomplishes a certain business need
 21

 based on the technologies of WWW and that consists of a set of Web-specific resources

Web Application Development

 Still Ad-Hoc instead of a disciplined procedure

 Copy-and-Paste Paradigm
 Lack between Design Model and Implementation Model

m
 Design concepts get lost in the underlying model

o
 Short lifecycle of a Web Application -> Maintenance and Evolution issues -> Reuse issues

Web Systems: Problems .c

 Problems a
 Inability to maintain
m
a
 Unable to meet evolving needs and grow at the rate needed – scaleability
 Unreliable – crashes
n
y
 Web-dependent organizations cannot afford to have

d
 Faulty systems – reliability, security issues

u
 Frequent downtime – dependability

t
 Wrong, inconsistent, or stale content/information

S
 Web systems problems are not easy to hide

Web Development Issues

 Many developers think that Web application development is just accomplished using
off the shelf tools
 They have been taught to think this way
 Certain classes of applications do fit this simple generalization
 Many other Web applications do not
 There is more to Web application development than visual design and user interface
 Planning, system design, testing, continual maintenance, quality assurance, performance
 22

evaluation, scalability.

S.NO RGPV QUESTION YEAR MARKS

Q.1 Write short notes on Forward Jun.2014,2013 5
Engineering.
Q.2 Write short notes on web Jun.2014,2013 5
Engineering.

m
o
.c
a
m
a
n
y
d
u
t
S
 23

UNIT-05/LECTURE-07

Goals of Web Engineering[RGPV/June 2013(7)]

 Develop high quality Web applications
 Effective
 Efficient
 Achieve desired application
 Maintain and evolve
 Plan for change – solution may change the problem
 Encourage the use of systematic, disciplined and quantifiable approaches and process
models

m
o
.c
Key Knowledge Areas
a
m
Software
Hypermedia
Engineering

•Process a •Design & Structure

•Design n Information Space
•Implementation
•Test y Web •Navigation
•Visualization
•Operation d Engineering •Usability
•Maintenance
u •Collaboration

t
SNetwork
Engineering
Information
Systems

•Physical Layer •Data Design, ER,...

•Internet Layer Others... •RDBMS
•Transport Layer •Query Languages
•Performance •Strg.Devices: FS,...
 24

Web Engineering Activities

 Requirements specification and analysis
 Web-based system analysis and design
 Web development methodologies and techniques
 Migration of legacy systems to Web environments
 Web-based real-time applications development
 Web-based multimedia application development
 Testing, verification and validation techniques and tools
 Quality assessment, control and assurance
 Management of access to applications and privileges
 Configuration and project management
 Web metrics – metrics for estimation of development effort m
 Performance specification and evaluation o
 Update and maintenance
.c
 Development models, teams, and staffing
 Human and cultural aspects
a
 User-centric development m
a
 Graphics, animation, and streaming
n
 Copyright, legal and social aspects
y
dWeb Engineering is
u Multidisciplinary
t
S
 25

UNIT-05/LECTURE-08

Management
 The activities and tasks undertaken by one or more persons for the purpose of
planning and controlling the activities of other in order to achieve objectives that
could not be achieved by the others acting alone

Project Management[RGPV/June 2014(7)]

– A system of management procedures, practices, technologies, skills, and
experience necessary to successfully manage an engineering project

m
Software Engineering Project Management
–
o
Project management where the product is software

Universality of Management
.c
–
a
Management performs the same functions regardless of organizational position
or enterprise
m
–
a
Management functions are characteristic duties of all managers

n
– Management practices, methods, activities and tasks are specific to the
enterprise
y
d
u
Issues with Software Engineering

t
70% of software organization have no defined methods

S
Process are defined during the development
Software ends up
– Late
– Over budget
– Fails to meet requirements

Today’s major problems with software development are not technical problems, but
management problems.

Functions of management
 26

– Planning
– Organizing
– Staffing
– Directing (leading)
– Controlling

Planning Activities[RGPV/June 2014(5)]

Set objectives and goals
Develop strategies
Develop policies
Forecast future situations
Conduct a risk assessment
Determine possible courses of action m
Make planning decisions o
Set procedures and rules
.c
Develop project plans
a
m
Prepare budgets

a
Document project plans

n
y
Organizing Activities

d
Identify and group project function, activities, and tasks

u
Select organizational structures

t
Create organizational positions

S
Define responsibilities and authority
Establish position qualifications
Document organizational decisions

Organizational Structure
Conventional organization structure
– Line organization
– Staff organization
Project organization structure
– Functional
 27

– Project
– Matrix
Team Structure
– Egoless
– Chief programmer
– Hierarchical

Issues In Staffing[RGPV/June 2014(5)]

Lack of project management training
Greatly varying skills
Inability to predict productivity of engineers
Lack of experience
Turnover m
Not enough software engineers o
– Most graduates are theoretical
.c
– Or just coders
a
m
a
Staffing Activities

n
y
Fill organizational positions

d
Assimilate newly assigned personnel

u
Educate or train personnel

t
Provide for general development

S
Evaluate and appraise personnel
Compensate
Terminate assignments
Document staffing decisions

Directing Activities
Provide leadership
Supervise personnel
Delegate authority
Motivate personnel
 28

Build teams
Coordinate activities
Facilitate communication
Resolve conflicts
Manage changes
Document directing decisions

Controlling Activities
Develop standards of performance
Establish monitoring and reporting systems
Measure and analyze results
Initiate corrective actions
Reward and discipline m
Document controlling methods o
.c
a
m
S.NO RGPV QUESTION YEAR MARKS

a
Q.1 Write short notes on Project Jun.2014,2013 5

n
Management Standards.

y
Q.2 Write short notes on web Jun.2014,2013 5

d
Engineering.

u
t
S
 29

UNIT-04/LECTURE-09
Software Quality Assurance[RGPV/June 2013,2011(7)]
 Conformance to software requirements is the foundation from which software quality is
measured.
 Specified standards are used to define the development criteria that are used to guide the
manner in which software is engineered.
 Software must conform to implicit requirements (ease of use, maintainability, reliability, etc.)
as well as its explicit requirements.

Quality

 m
Quality, simplistically, means that a product should meet its specification
 This is problematical for software systems o
•
.c
Tension between customer quality requirements (efficiency, reliability, etc.) and

•
a
developer quality requirements (maintainability, reusability, etc.)

m
Some quality requirements are difficult to specify in an unambiguous way
•
a
Software specifications are usually incomplete and often inconsistent

Quality compromise n
y

d
We cannot wait for specifications to improve before paying attention to quality management


u
Must put procedures into place to improve quality in spite of imperfect specification


t
Quality management is therefore not just concerned with reducing defects but also with other

S
product qualities

Quality management activities

 Quality assurance

• Establish organisational procedures and standards for quality

 Quality planning

• Select applicable procedures and standards for a particular project and modify these as

required

 Quality control
 30

• Ensure that procedures and standards are followed by the software development team

 Quality management should be separate from project management to ensure independence

Quality management and software development

m
o
.c
©Ian Sommerville 2000
a
Software Engineering, 6th edition. Chapter 24 Slide 9

m
Quality assurance and standards a
n

y
Standards are the key to effective quality management


d
They may be international, national, organizational or project standards


u
Product standards define characteristics that all components should exhibit e.g. a common

t
programming style

 S
Process standards define how the software process should be enacted

Importance of standards

 Encapsulation of best practice- avoids repetition of past mistakes

 Framework for quality assurance process - it involves checking standard compliance

 Provide continuity - new staff can understand the organisation by understand the standards

applied.
 31

Problems with standards

m
 Not seen as relevant and up-to-date by software engineers
o
.c
 Involve too much bureaucratic form filling
 Unsupported by software tools so tedious manual work is involved to maintain standards
a
m
aprocess
Documentation
n
y
d
u
t
S

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 20

 32

Quality control

 Checking the software development process to ensure that procedures and standards are
being followed
 Two approaches to quality control
• Quality reviews
• Automated software assessment and software measurement

Quality reviews

 The principal method of validating the quality of a process or of a product

 Group examined part or all of a process or system and its documentation to find potential
problems
m
 There are different types of review with different objectives
o
.c
• Inspections for defect removal (product)
• Reviews for progress assessment(product and process)
• Quality reviews (product and standards) a
m
Types of review
a
n
y
d
u
t
S
 33

Review Process

S.NO RGPV QUESTION YEAR

m
MARKS
Q.1 Explain Software Quality Jun.2011
o 7

.c
Assurance. Why should the
quality assurance organization
be independent of a
development organization?
m
Q.2
a
Write short notes on Software Jun.2011 5
Quality Assurance (SQA).
n
y
d
u
t
S
 34

REFERENCCE

BOOK AUTHOR PRIORITY

Software P.S. Pressman 1
Engineering
Software 2
Engineering Pankaj Jhalote

m
o
.c
a
m
a
n
y
d
u
t
S
 Millions of University Lecture Notes, Book Solutions,
Summary, Assignments and Projects are available for FREE.