Software Engineering

SOFTWARE ENGINEERING

UNIT-I: Introduction - Evolving Role of Software - Changing Nature of Software –

SoftwareMyths; A Generic View of Process: Layered Technology - Process Models:
Waterfall Model - Evolutionary Process Models.

The software is instruction or computer program that when executed provide desired
features, function, and performance.

Engineering on the other hand, is all about developing products, using well-defined,
scientific principles and methods.

Software engineering is an engineering branch associated with development of

software product using well-defined scientific principles, methods and procedures. The
outcome of software engineering is an efficient and reliable software product.

Department Of Computer Applications

Indo-American College, Cheyyar Page 1
 Software Engineering

Software Characteristics
Different individuals judge software on different basis. This is because they are
involved with the software in different ways. For example, users want the software to
perform according to their requirements. Similarly, developers involved in designing, coding,
and maintenance of the software evaluate the software by looking at its internal
characteristics, before delivering it to the user.

Software characteristics are classified into six major components.

Functionality: Refers to the degree of performance of the software against its intended
purpose.
• Reliability: Refers to the ability of the software to provide desired functionality under the
given conditions.
• Usability: Refers to the extent to which the software can be used with ease.
• Efficiency: Refers to the ability of the software to use system resources in the most
effective and efficient manner.
Maintainability: Refers to the ease with which the modifications can be made in a software
system to extend its functionality, improve its performance, or correct errors.
• Portability: Refers to the ease with which software developers can transfer software from
one platform to another, without (or with minimum) changes. In simple terms, it refers to the
ability of software to function properly on different hardware and software platforms without
making any changes in it.
In addition to the above mentioned characteristics, robustness and integrity are also
important. Robustness refers to the degree to which the software can keep on functioning in
spite of being provided with invalid data while integrity refers to the degree to which
unauthorized access to the software or data can be prevented.

Classification of Software
Software can be applied in countless fields such as business, education, social sector,
and other fields. It is designed to suit some specific goals such as data
processing, information sharing, communication, and so on. It is classified according to the
range of potential of applications.
These classifications are listed below.
• System software: This class of software manages and controls the internal operations of a
computer system. It is a group of programs, which is responsible for using computer
resources efficiently and effectively. For example, an operating system is a system software,
which controls the hardware, manages memory and multitasking functions, and acts as an
interface between application programs and the computer.
• Real-time software: This class of software observes, analyzes, and controls real world
events as they occur. Generally, a real-time system guarantees a response to an external event
within a specified period of time. An example of real-time software is the software used for
weather forecasting that collects and processes parameters like temperature and humidity
from the external environment to forecast the weather. Most of the defence organizations all
over the world use real-time software to control their military hardware.

Department Of Computer Applications

Indo-American College, Cheyyar Page 2
 Software Engineering
• Business software: This class of software is widely used in areas where management and
control of financial activities is of utmost importance. The fundamental component of a
business system comprises payroll, inventory, and accounting software that permit the user to
access relevant data from the database. These activities are usually performed with the help
of specialized business software that facilitates efficient framework in business operations
and in management decisions.
• Engineering and scientific software: This class of software has emerged as a powerful
tool in the research and development of next generation technology. Applications such as the
study of celestial bodies, under-surface activities, and programming of an orbital path for
space shuttles are heavily dependent on engineering and scientific software. This software is
designed to perform precise calculations on complex numerical data that are obtained during
real time environment.
• Artificial intelligence (AI) software: This class of software is used where the problem-
solving technique is non-algorithmic in nature. The solutions of such problems are generally
non-agreeable to computation or straightforward analysis. Instead, these problems require
specific problem-solving strategies that include expert system, pattern recognition, and game-
playing techniques. In addition, they involve different kinds of search techniques which
include the use of heuristics. The role of artificial intelligence software is to add certain
degrees of intelligence to the mechanical hardware in order to get the desired work done in an
agile manner.
• Web-based software: This class of software acts as an interface between the user and the
Internet. Data on the Internet is in the form of text, audio, or video format, linked with
hyperlinks. Web browser is a software that retrieves web pages from the Internet. The
software incorporates executable instructions written in special scripting languages such as
CGI or ASP. Apart from providing navigation on the Web, this software also supports
additional features that are useful while surfing the Internet.
• Personal computer (PC) software: This class of software is used for both official and
personal use. The personal computer software market has grown over in the last two decades
from normal text editor to word processor and from simple paintbrush to advanced image-
editing software. This software is used predominantly in almost every field, whether it
is database management system, financial accounting package, or multimedia-based software.
It has emerged as a versatile tool for routine applications.

Department Of Computer Applications

Indo-American College, Cheyyar Page 3
 Software Engineering

Software Evolution

The process of developing a software product using software engineering principles

and methods is referred to as software evolution. This includes the initial development of
software and its maintenance and updates, till desired software product is developed, which
satisfies the expected requirements.

Evolution starts from the requirement gathering process. After which developers
create a prototype of the intended software and show it to the users to get their feedback at
the early stage of software product development. The users suggest changes, on which
several consecutive updates and maintenance keep on changing too. This process changes to
the original software, till the desired software is accomplished.

Even after the user has desired software in hand, the advancing technology and the
changing requirements force the software product to change accordingly. Re-creating
software from scratch and to go one-on-one with requirement is not feasible. The only
feasible and economical solution is to update the existing software so that it matches the
latest requirements.

Software Evolution Laws

Lehman has given laws for software evolution. He divided the software into three different
categories:

 S-type (static-type) - This is a software, which works strictly according to

defined specifications and solutions. The solution and the method to achieve it, both

Department Of Computer Applications

Indo-American College, Cheyyar Page 4
 Software Engineering
are immediately understood before coding. The s-type software is least subjected to
changes hence this is the simplest of all. For example, calculator program for
mathematical computation.

 P-type (practical-type) - This is a software with a collection of procedures. This is

defined by exactly what procedures can do. In this software, the specifications can be
described but the solution is not obvious instantly. For example, gaming software.

 E-type (embedded-type) - This software works closely as the requirement of real-

world environment. This software has a high degree of evolution as there are various
changes in laws, taxes etc. in the real world situations. For example, Online trading
software.

Changing Nature of Software:

Nowadays, seven broad categories of computer software present continuing challenges for
software engineers .which is given below:
1. System Software:
System software is a collection of programs which are written to service other
programs. Some system software processes complex but determinate, information
structures. Other system application process largely indeterminate data. Sometimes
when, the system software area is characterized by the heavy interaction with computer
hardware that requires scheduling, resource sharing, and sophisticated process
management.
2. Application Software:
Application software is defined as programs that solve a specific business need.
Application in this area process business or technical data in a way that facilitates
business operation or management technical decision making. In addition to convention
data processing application, application software is used to control business function in
real time.
3. Engineering and Scientific Software:
This software is used to facilitate the engineering function and task. however modern
application within the engineering and scientific area are moving away from the
conventional numerical algorithms. Computer-aided design, system simulation, and
other interactive applications have begun to take a real-time and even system software
characteristic.

Department Of Computer Applications

Indo-American College, Cheyyar Page 5
 Software Engineering

4. Embedded Software:
Embedded software resides within the system or product and is used to implement and
control feature and function for the end-user and for the system itself. Embedded
software can perform the limited and esoteric function or provided significant function
and control capability.
5. Product-line Software:
Designed to provide a specific capability for use by many different customers, product
line software can focus on the limited and esoteric marketplace or address the mass
consumer market.
6. Web Application:
It is a client-server computer program which the client runs on the web browser. In their
simplest form, Web apps can be little more than a set of linked hypertext files that
present information using text and limited graphics. However, as e-commerce and B2B
application grow in importance. Web apps are evolving into a sophisticate computing
environment that not only provides a standalone feature, computing function, and
content to the end user.
7. Artificial Intelligence Software:
Artificial intelligence software makes use of a nonnumerical algorithm to solve a
complex problem that is not amenable to computation or straightforward analysis.
Application within this area includes robotics, expert system, pattern recognition,
artificial neural network, theorem proving and game playing.

Software Myth:

The development of software requires dedication and understanding on the developers' part.
Many software problems arise due to myths that are formed during the initial stages of
software development. Unlike ancient folklore that often provides valuable lessons, software
myths propagate false beliefs and confusion in the minds of management, users and
developers.

Management Myth:

 The members of an organization can Standards are often incomplete,

acquire all-the information, they require inadaptable, and outdated.
from a manual, which contains standards, Developers are often unaware of all the

Department Of Computer Applications

Indo-American College, Cheyyar Page 6
 Software Engineering

procedures, and principles; established standards.

 Developers rarely follow all the known
standards because not all the standards
tend to decrease the delivery time of
software while maintaining its quality.

 Adding more manpower to the project,

which is already behind schedule, further
 If the project is behind
delays the project.
schedule, increasing the number of
 New workers take longer to learn about
programmers can reduce the time gap.
the project as compared to those already
working on the project.

 Outsourcing software to a third party does

not help the organization, which is
 If the project is outsourced to a third
incompetent in managing and controlling
party, the management can relax and let
the software project internally. The
the other firm develop software for them.
organization invariably suffers when it
out sources the software project.

User Myth:

 Starting development with incomplete

and ambiguous requirements often lead to
 Brief requirement stated in the initial software failure. Instead, a complete and
process is enough to start development; formal description of requirements is
detailed requirements can be added at the essential before starting development.
later stages.  Adding requirements at a later stage often
requires repeating the entire development
process.

 Software is flexible; hence software Incorporating change requests earlier in

requirement changes can be added during the development process costs lesser than

Department Of Computer Applications

Indo-American College, Cheyyar Page 7
 Software Engineering
any phase of the development process. those that occurs at later stages. This is
because incorporating changes later may
require redesigning and extra resources.

Developer Myth:

 50% to 70% of all the efforts are

 Software development is considered
expended after the software is delivered
complete when the code is delivered.
to the user.

 The quality of programs is not the only

 The success of a software project depends factor that makes the project successful
on the quality of the product produced. instead the documentation and software
configuration also playa crucial role.

 Software engineering is about creating

 Software engineering requires quality at every level of the software
unnecessary documentation, which slows project. Proper documentation enhances
down the project. quality which results in reducing the
amount of rework.

 The deliverables of a successful project

 The only product that is delivered after
includes not only the working program
the completion of a project is the working
but also the documentation to guide the
program(s).
users for using the software.

 The quality of software can be measured

during any phase of development process
by applying some quality assurance
 Software quality can be assessed only
mechanism. One such mechanism is
after the program is executed.
formal technical review that can be
effectively used during each phase of
development to uncover certain errors.

Department Of Computer Applications

Indo-American College, Cheyyar Page 8
 Software Engineering

Software engineering - Layered technology

 Software engineering is a fully layered technology.

 To develop a software, we need to go from one layer to another.
 All these layers are related to each other and each layer demands the fulfillment of the
previous layer.

The layered technology consists of:

1. Quality focus
The characteristics of good quality software are:
 Correctness of the functions required to be performed by the software.
 Maintainability of the software
 Integrity i.e. providing security so that the unauthorized user cannot access information or
data.
 Usability i.e. the efforts required to use or operate the software.
2. Process
 It is the base layer or foundation layer for the software engineering.
 The software process is the key to keep all levels together.
 It defines a framework that includes different activities and tasks.
 In short, it covers all activities, actions and tasks required to be carried out for software
development.
3. Methods
 The method provides the answers of all 'how-to' that are asked during the process.
 It provides the technical way to implement the software.
 It includes collection of tasks starting from communication, requirement analysis, analysis
and design modelling, program construction, testing and support.

Department Of Computer Applications

Indo-American College, Cheyyar Page 9
 Software Engineering

4. Tools
 The software engineering tool is an automated support for the software development.
 The tools are integrated i.e the information created by one tool can be used by the other tool.
For example: The Microsoft publisher can be used as a web designing tool.

Classical Waterfall Model:

Classical waterfall model is the basic software development life cycle model. It is
very simple but idealistic. Earlier this model was very popular but nowadays it is not used.
But it is very important because all the other software development life cycle models are
based on the classical waterfall model.
Classical waterfall model divides the life cycle into a set of phases. This model
considers that one phase can be started after completion of the previous phase. That is the
output of one phase will be the input to the next phase. Thus the development process can be
considered as a sequential flow in the waterfall. Here the phases do not overlap with each
other. The different sequential phases of the classical waterfall model are shown in the below
figure:

Department Of Computer Applications

Indo-American College, Cheyyar Page 10
 Software Engineering

Let us now learn about each of these phases in brief details:

1. Feasibility Study: The main goal of this phase is to determine whether it would be
financially and technically feasible to develop the software.
The feasibility study involves understanding the problem and then determine the
various possible strategies to solve the problem. These different identified solutions are
analyzed based on their benefits and drawbacks, The best solution is chosen and all the
other phases are carried out as per this solution strategy.
2. Requirements analysis and specification: The aim of the requirement analysis and
specification phase is to understand the exact requirements of the customer and
document them properly. This phase consists of two different activities.
 Requirement gathering and analysis: Firstly all the requirements regarding the
software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness (an
incomplete requirement is one in which some parts of the actual requirements
have been omitted) and inconsistencies (inconsistent requirement is one in which
some part of the requirement contradicts with some other part).
 Requirement specification: These analyzed requirements are documented in a
software requirement specification (SRS) document. SRS document serves as a
contract between development team and customers. Any future dispute between
the customers and the developers can be settled by examining the SRS document.
3. Design: The aim of the design phase is to transform the requirements specified in the
SRS document into a structure that is suitable for implementation in some programming
language.
4. Coding and Unit testing: In coding phase software design is translated into source
code using any suitable programming language. Thus each designed module is coded.
The aim of the unit testing phase is to check whether each module is working properly
or not.
5. Integration and System testing: Integration of different modules are undertaken soon
after they have been coded and unit tested. Integration of various modules is carried out
incrementally over a number of steps. During each integration step, previously planned

Department Of Computer Applications

Indo-American College, Cheyyar Page 11
 Software Engineering
modules are added to the partially integrated system and the resultant system is tested.
Finally, after all the modules have been successfully integrated and tested, the full
working system is obtained and system testing is carried out on this.
System testing consists three different kinds of testing activities as described below :

 Alpha testing: Alpha testing is the system testing performed by the development
team.
 Beta testing: Beta testing is the system testing performed by a friendly set of
customers.
 Acceptance testing: After the software has been delivered, the customer
performed the acceptance testing to determine whether to accept the delivered
software or to reject it.
6. Maintainence: Maintenance is the most important phase of a software life cycle. The
effort spent on maintenance is the 60% of the total effort spent to develop a full
software. There are basically three types of maintenance :
 Corrective Maintenance: This type of maintenance is carried out to correct
errors that were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the
software to work in a new environment such as work on a new computer platform
or with a new operating system.
Advantages of Classical Waterfall Model
Classical waterfall model is an idealistic model for software development. It is very simple,
so it can be considered as the basis for other software development life cycle models.

Below are some of the major advantages of this SDLC model:

 This model is very simple and is easy to understand.

 Phases in this model are processed one at a time.
 Each stage in the model is clearly defined.
 This model has very clear and well undestood milestones.
 Process, actions and results are very well documented.
 Reinforces good habits: define-before- design,
design-before-code.

Department Of Computer Applications

Indo-American College, Cheyyar Page 12
 Software Engineering
 This model works well for smaller projects and projects where requirements are well
understood.

Drawbacks of Classical Waterfall Model

Classical waterfall model suffers from various shortcomings, basically we can’t use it in real
projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model:

 No feedback path: In classical waterfall model evolution of a software from one phase
to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phases. Therefore, it does not incorporate any mechanism for
error correction.
 Difficult to accommodate change requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project,
but actually customers’ requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is
complete.
 No overlapping of phases: This model recommends that new phase can start only after
the completion of the previous phase. But in real projects, this can’t be maintained. To
increase the efficiency and reduce the cost, phases may overlap.

Evolutionary Process Models:

 Evolutionary models are iterative type models.

 They allow to develop more complete versions of the software.

Following are the evolutionary process models.

1. The prototyping model
2. The spiral model
3. Concurrent development model

Department Of Computer Applications

Indo-American College, Cheyyar Page 13
 Software Engineering

1. The Prototyping model

 Prototype is defined as first or preliminary form using which other forms are copied or
derived.
 Prototype model is a set of general objectives for software.
 It does not identify the requirements like detailed input, output.
 It is software working model of limited functionality.
 In this model, working programs are quickly produced.

The different phases of Prototyping model are:

1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the software.

2. Quick design
 Quick design is implemented when requirements are known.
 It includes only the important aspects like input and output format of the software.
 It focuses on those aspects which are visible to the user rather than the detailed plan.
 It helps to construct a prototype.

Department Of Computer Applications

Indo-American College, Cheyyar Page 14
 Software Engineering

3. Modeling quick design

 This phase gives the clear idea about the development of software because the software is
now built.
 It allows the developer to better understand the exact requirements.
4. Construction of prototype
The prototype is evaluated by the customer itself.
5. Deployment, delivery, feedback
 If the user is not satisfied with current prototype then it refines according to the requirements
of the user.
 The process of refining the prototype is repeated until all the requirements of users are met.
 When the users are satisfied with the developed prototype then the system is developed on
the basis of final prototype.

Advantages of Prototyping Model

 Prototype model need not know the detailed input, output, processes, adaptability of
operating system and full machine interaction.
 In the development process of this model users are actively involved.
 The development process is the best platform to understand the system by the user.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies the confusing or difficult
functions.
Disadvantages of Prototyping Model:
 The client involvement is more and it is not always considered by the developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a thrown away prototype when the users are confused with it.

Department Of Computer Applications

Indo-American College, Cheyyar Page 15
 Software Engineering

2. The Spiral model

 Spiral model is a risk driven process model.
 It is used for generating the software projects.
 In spiral model, an alternate solution is provided if the risk is found in the risk analysis, then
alternate solutions are suggested and implemented.
 It is a combination of prototype and sequential model or waterfall model.
 In one iteration all activities are done, for large project's the output is small.
The framework activities of the spiral model are as shown in the following figure.

NOTE: The description of the phases of the spiral model is same as that of the process
model.

Advantages of Spiral Model

 It reduces high amount of risk.
 It is good for large and critical projects.
 It gives strong approval and documentation control.
 In spiral model, the software is produced early in the life cycle process.
Disadvantages of Spiral Model
 It can be costly to develop a software model.
 It is not used for small projects.

Department Of Computer Applications

Indo-American College, Cheyyar Page 16
 Software Engineering

3. The concurrent development model

 The concurrent development model is called as concurrent model.

 The communication activity has completed in the first iteration and exits in the awaiting
changes state.
 The modeling activity completed its initial communication and then go to the
underdevelopment state.
 If the customer specifies the change in the requirement, then the modeling activity moves
from the under development state into the awaiting change state.
 The concurrent process model activities moving from one state to another state.

Advantages of the concurrent development model

 This model is applicable to all types of software development processes.
 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a project.

Department Of Computer Applications

Indo-American College, Cheyyar Page 17
 Software Engineering

Disadvantages of the concurrent development model

 It needs better communication between the team members. This may not be achieved all the
time.
 It requires to remember the status of the different activities.

REFERENCES
1. [Link]
2. [Link]
3. [Link]

Department Of Computer Applications

Indo-American College, Cheyyar Page 18
 Software Engineering

UNIT-II: Requirements Engineering: Tasks - Initiating the Requirements Engineering

Process - Eliciting Requirements - Building the Analysis Model - Requirements Analysis -
Data Modeling Concepts.

Introduction to requirement engineering

 The process of collecting the software requirement from the client then understand, evaluate
and document it is called as requirement engineering.
 Requirement engineering constructs a bridge for design and construction.

Requirement engineering consists of seven different tasks as follow:

1. Inception
 Inception is a task where the requirement engineering asks a set of questions to establish a
software process.
 In this task, it understands the problem and evaluates with the proper solution.
 It collaborates with the relationship between the customer and the developer.
 The developer and customer decide the overall scope and the nature of the question.
2. Elicitation
Elicitation means to find the requirements from anybody.
The requirements are difficult because the following problems occur in elicitation.
Problem of scope: The customer give the unnecessary technical detail rather than clarity of
the overall system objective.
Problem of understanding: Poor understanding between the customer and the developer
regarding various aspect of the project like capability, limitation of the computing
environment.
Problem of volatility: In this problem, the requirements change from time to time and it is
difficult while developing the project.
3. Elaboration
 In this task, the information taken from user during inception and elaboration and are
expanded and refined in elaboration.
 Its main task is developing pure model of software using functions, feature and constraints
of a software.


Department Of Computer Applications

Indo-American college, Cheyyar1
 Software Engineering

4. Negotiation
 In negotiation task, a software engineer decides the how will the project be achieved with
limited business resources.
 To create rough guesses of development and access the impact of the requirement on the
project cost and delivery time.
5. Specification
 In this task, the requirement engineer constructs a final work product.
 The work product is in the form of software requirement specification.
 In this task, formalize the requirement of the proposed software such as informative,
functional and behavioral.
 The requirement are formalize in both graphical and textual formats.
6. Validation
 The work product is built as an output of the requirement engineering and that is accessed
for the quality through a validation step.
 The formal technical reviews from the software engineer, customer and other stakeholders
helps for the primary requirements validation mechanism.
7. Requirement management
 It is a set of activities that help the project team to identify, control and track the
requirements and changes can be made to the requirements at any time of the ongoing
project.
 These tasks start with the identification and assign a unique identifier to each of the
requirement.
 After finalizing the requirement traceability table is developed.
 The examples of traceability table are the features, sources, dependencies, subsystems and
interface of the requirement.

Eliciting Requirements

Eliciting requirement helps the user for collecting the requirement

Eliciting requirement steps are as follows:
1. Collaborative requirements gathering
 Gathering the requirements by conducting the meetings between developer and customer.
 Fix the rules for preparation and participation.

Department Of Computer Applications

Indo-American college, Cheyyar2
 Software Engineering

 The main motive is to identify the problem, give the solutions for the elements, negotiate
the different approaches and specify the primary set of solution requirements in an
environment which is valuable for achieving goal.
2. Quality Function Deployment (QFD)
 In this technique, translate the customer need into the technical requirement for the software.
 QFD system designs a software according to the demands of the customer.
QFD consist of three types of requirement:
Normal requirements
 The objective and goal are stated for the system through the meetings with the customer.
 For the customer satisfaction these requirements should be there.
Expected requirement
 These requirements are implicit.
 These are the basic requirement that not be clearly told by the customer, but also the
customer expect that requirement.
Exciting requirements
 These features are beyond the expectation of the customer.
 The developer adds some additional features or unexpected feature into the software to make
the customer more satisfied.
For example, the mobile phone with standard features, but the developer adds few
additional functionalities like voice searching, multi-touch screen etc. then the customer
more exited about that feature.
3. Usage scenarios
 Till the software team does not understand how the features and function are used by the end
users it is difficult to move technical activities.
 To achieve above problem the software team produces a set of structure that identify the
usage for the software.
 This structure is called as 'Use Cases'.
4. Elicitation work product
 The work product created as a result of requirement elicitation that is depending on the size
of the system or product to be built.
 The work product consists of a statement need, feasibility, statement scope for the system.
 It also consists of a list of users participate in the requirement elicitation.

Department Of Computer Applications

Indo-American college, Cheyyar3
 Software Engineering

Requirement Engineering

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement engineering
provides the appropriate mechanism to understand what the customer desires, analyzing the
need, and assessing feasibility, negotiating a reasonable solution, specifying the solution
clearly, validating the specifications and managing the requirements as they are transformed
into a working system. Thus, requirement engineering is the disciplined application of proven
principles, methods, tools, and notation to describe a proposed system's intended behavior
and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

Department Of Computer Applications

Indo-American college, Cheyyar4
 Software Engineering

1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing the software
that is acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies,

which are needed to accomplish customer requirements within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and customer
requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software
can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified with
the help of customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

Department Of Computer Applications

Indo-American college, Cheyyar5
 Software Engineering

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software

analyst after the requirements collected from the various sources - the requirement received
by the customer written in ordinary language. It is the job of the analyst to write the
requirement in technical language so that they can be understood and beneficial by the
development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a
company, an organization, a set of procedures, a computer hardware system, a
software system, or any combination of the preceding. The DFD is also known as a
data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store information
about all data items defined in DFDs. At the requirements stage, the data dictionary
should at least define customer data items, to ensure that the customer and developers
use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is the
entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e. data
entities, relationships, and their associated attributes.

Department Of Computer Applications

Indo-American college, Cheyyar6
 Software Engineering

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the check against the following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

5. Software Requirement Management:

Requirement management is the process of managing changing requirements during the

requirements engineering process and system development.

New requirements emerge during the process as business needs a change, and a better
understanding of the system is developed.

The priority of requirements from different viewpoints changes during development process.

The business and technical environment of the system changes during the development.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development project.
Hence they should be clear, correct, and well-defined.
Department Of Computer Applications
Indo-American college, Cheyyar7
 Software Engineering

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized into two

categories:

1. Functional Requirements: Functional requirements define a function that a system

or system element must be qualified to perform and must be documented in different
forms. The functional requirements are describing the behavior of the system as it
correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify the criteria
that can be used to decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are observable at run
time.
o Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.

Department Of Computer Applications

Indo-American college, Cheyyar8
 Software Engineering

Building The Analysis Model:

 Analysis model operates as a link between the 'system description' and the 'design model'.
 In the analysis model, information, functions and the behaviour of the system is defined and
these are translated into the architecture, interface and component level design in the 'design
modeling'.

Elements of the analysis model

1. Scenario based element

 This type of element represents the system user point of view.
 Scenario based elements are use case diagram, user stories.
2. Class based elements
 The object of this type of element manipulated by the system.
 It defines the object,attributes and relationship.
 The collaboration is occurring between the classes.
 Class based elements are the class diagram, collaboration diagram.
3. Behavioral elements
 Behavioral elements represent state of the system and how it is changed by the external
events.
 The behavioral elements are sequenced diagram, state diagram.
4. Flow oriented elements
 An information flows through a computer-based system it gets transformed.
 It shows how the data objects are transformed while they flow between the various system
functions.
 The flow elements are data flow diagram, control flow diagram.

Department Of Computer Applications

Indo-American college, Cheyyar9
 Software Engineering

Data Modeling vs. Requirements Modeling

To understand data modeling and how it contributes to software engineering, it is best

to take a step back and examine how data modeling fits into requirements modeling.

Requirements modeling in software engineering is part of analysis and design. It's the
planning stage of developing a software application. Requirements modeling focuses on the
'what', not the 'how'. In other words, requirements modeling identifies what requirements the
application must meet in order to be successful.

Requirements modeling includes many sub-stages, one of them being data modeling.
Generally speaking, requirements modeling will begin with scenario-based modeling, which
results in creating a use case. A use case, simply put, is a primary example of how the
software application will be used and what it is expected to do. Once a use case exists, one of
the stages that follow will be data modeling.

Data Objects, Attributes, and Relationships

Data modeling, sometimes also called information modeling, is the process of visually
representing what data the application or system will use, and how it will flow. The resulting
diagram or other visual representation is meant to be designed in a way that is as easy to
understand as possible. The fundamental elements that a data model needs to include and
describe are the data objects, more frequently called 'entities', the attributes of those
objects/entities, and the relationships between the objects/entities.

What is Data Modeling?

The process of creating a model for the storage of data in a database is termed as data
modeling. It is a theoretical presentation of data objects and associations among various data
objects. Data modeling is a process of formulating data in an information system in a
structured format. It helps in analyzing data easily which will further help in meeting
business requirements.

The process of data modeling requires data modelers which will precisely work with
stakeholders and prospective users of an information system. Data modeling process ends
with the creation of a data model that supports the business information system infrastructure.
This process also involves understanding the structure of an organization and proposing a

Department Of Computer Applications

Indo-American college, Cheyyar10
 Software Engineering

solution that enables the organization to achieve its objectives. It bridges the gaps between
technical and functional areas.

Primary reasons for using a data model are listed below:

 Visual representation of data helps improve data analysis. It provides a holistic picture
of the data which can be used by developers to create a physical database.
 All important data of an enterprise are accurately presented in the model. The data
model reduces the chances of data omission. Data omission can lead to incorrect
results and faulty reports.
 The data model portrays a better understanding of business requirements.
 It helps in the creation of a robust design that brings the entire data of an organization
on the same platform. It assists in identifying the redundant, duplicate, and missing
data as well.
 A qualified data model helps in providing better consistency across all projects of an
enterprise.
 It improves data quality.
 It helps Project Managers with a better scope and quality management. It also
improves performance to the core.
 It defines relational tables, stored procedures, and primary and foreign keys.

Advantages and Disadvantages of Data Models

Advantages

 Data objects provided by the functional team are presented accurately with data
modeling.
 Data modeling allows you to query data from the database and derive various reports
based on the data. It indirectly contributes to data analysis with the help of reports.
These reports can be used for improving the quality and productivity of the project.
 Businesses have plenty of data in a variety of formats. Data modeling provides a
structured system for such unstructured forms of data.
 Data modeling improves business intelligence by making data modelers work closely
with the ground realities of the project which include gathering data from multiple
unstructured sources, reporting requirements, spending patterns, etc.

Department Of Computer Applications

Indo-American college, Cheyyar11
 Software Engineering

 It improves communication across the organization.

 It helps in documenting data mapping during the ETL process.

Disadvantages

 Development of a data model is a very tedious job. One should be aware of the
physical characteristics of the data storage.
 This system involves complex application development and knowledge of
biographical truth.
 The model is not quite user-friendly. Small changes induced in the system require
major modification in the entire application.

REFERENCES

[Link]

[Link]

TEXT BOOK: Roger S Pressman, “Software Engineering - A Practitioner’s

Approach”, Sixth Edition, McGraw Hill International Edition, New York: 2005.

Department Of Computer Applications

Indo-American college, Cheyyar12
 UNIT-III:

Data Engineering: Design Process and Design Quality - Design Concepts - The Design Model
Creating an Architectural Design: Software Architecture - Data Design -Architectural Design -
Mapping Data Flow into Software Architecture; Performing User Interface Design: Golden
Rules.

 The main aim of design engineering is to generate a model which shows firmness, delight and
commodity.
 Software design is an iterative process through which requirements are translated into the
blueprint for building the software.

1)Software Quality

 A design is generated using the recognizable architectural styles and compose a good design
characteristic of components and it is implemented in evolutionary manner for testing.
 A design of the software must be modular i.e the software must be logically partitioned into
elements.
 In design, the representation of data , architecture, interface and components should be distinct.
 A design must carry appropriate data structure and recognizable data patterns.
 Design components must show the independent functional characteristic.
 A design creates an interface that reduce the complexity of connections between the
components.
 A design must be derived using the repeatable method.
 The notations should be use in design which can effectively communicates its meaning.

2)Quality attributes

The attributes of design name as 'FURPS' are as follows:

Functionality:
It evaluates the feature set and capabilities of the program.
 Usability:
It is accessed by considering the factors such as human factor, overall aesthetics, consistency and
documentation.

Reliability:
It is evaluated by measuring parameters like frequency and security of failure, output result
accuracy, the mean-time-to-failure(MTTF), recovery from failure and the the program
predictability.

Performance:
It is measured by considering processing speed, response time, resource consumption,
throughput and efficiency.

Supportability:

 It combines the ability to extend the program, adaptability, serviceability. These three term
defines the maintainability.
 Testability, compatibility and configurability are the terms using which a system can be easily
installed and found the problem easily.
 Supportability also consists of more attributes such as compatibility, extensibility, fault
tolerance, modularity, reusability, robustness, security, portability, scalability.

3)Design concepts

The set of fundamental software design concepts are as follows:

1. Abstraction

 A solution is stated in large terms using the language of the problem environment at the highest
level abstraction.
 The lower level of abstraction provides a more detail description of the solution.
 A sequence of instruction that contain a specific and limited function refers in a procedural
abstraction.
 A collection of data that describes a data object is a data abstraction.

2. Architecture

 The complete structure of the software is known as software architecture.

 Structure provides conceptual integrity for a system in a number of ways.
 The architecture is the structure of program modules where they interact with each other in a
specialized way.
 The components use the structure of data.
 The aim of the software design is to obtain an architectural framework of a system.
 The more detailed design activities are conducted from the framework.

3. Patterns
A design pattern describes a design structure and that structure solves a particular design
problem in a specified content.

4. Modularity

 Software is separately divided into name and addressable components. Sometime they are
called as modules which integrate to satisfy the problem requirements.
 Modularity is the single attribute of a software that permits a program to be managed easily.

5. Information hiding
Modules must be specified and designed so that the information like algorithm and data
presented in a module is not accessible for other modules not requiring that information.

6. Functional independence

 The functional independence is the concept of separation and related to the concept of
modularity, abstraction and information hiding.
 The functional independence is accessed using two criteria i.e Cohesion and coupling.

Cohesion

 Cohesion is an extension of the information hiding concept.

 A cohesive module performs a single task and it requires a small interaction with the other
components in other parts of the program.
Coupling
Coupling is an indication of interconnection between modules in a structure of software.

7. Refinement

 Refinement is a top-down design approach.

 It is a process of elaboration.
 A program is established for refining levels of procedural details.
 A hierarchy is established by decomposing a statement of function in a stepwise manner till the
programming language statement are reached.

8. Refactoring

 It is a reorganization technique which simplifies the design of components without changing its
function behaviour.
 Refactoring is the process of changing the software system in a way that it does not change the
external behaviour of the code still improves its internal structure.

9. Design classes

 The model of software is defined as a set of design classes.

 Every class describes the elements of problem domain and that focus on features of the problem
which are user visible.
4)Software Design Process

The design phase of software development deals with transforming the customer requirements as
described in the SRS documents into a form implementable using a programming language.
The software design process can be divided into the following three levels of phases of design:

1. Interface Design
2. Architectural Design
3. Detailed Design

Interface Design:
Interface design is the specification of the interaction between a system and its environment.
this phase proceeds at a high level of abstraction with respect to the inner workings of the system
i.e, during interface design, the internal of the systems are completely ignored and the system is
treated as a black box. Attention is focussed on the dialogue between the target system and the
users, devices, and other systems with which it interacts. The design problem statement produced
during the problem analysis step should identify the people, other systems, and devices which are
collectively called agents.

Interface design should include the following details:

 Precise description of events in the environment, or messages from agents to which the
system must respond.
 Precise description of the events or messages that the system must produce.
 Specification on the data, and the formats of the data coming into and going out of the
system.
 Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.

Architectural Design:
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them. In
architectural design, the overall structure of the system is chosen, but the internal details of
major components are ignored.
Issues in architectural design includes:

 Gross decomposition of the systems into major components.

 Allocation of functional responsibilities to components.
 Component Interfaces
 Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.
 Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design of the
internals of the major components is ignored until the last phase of the design.

Detailed Design:
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.
The detailed design may include:

 Decomposition of major system components into program units.

 Allocation of functional responsibilities to units.
 User interfaces
 Unit states and state changes
 Data and control interaction between units
 Data packaging and implementation, including issues of scope and visibility of program
elements
 Algorithms and data structures

Data Design

Like other software engineering activities, data design (sometimes referred to as data
architecting) creates a model of data and/or information that is represented at a high level of
abstraction (the customer/user’s view of data). This data model is then refined into progressively
more implementation-specific representations that can be processed by the computer-based
system. In many software applications, the architecture of the data will have a profound
influence on the architecture of the software that must process it.

The structure of data has always been an important part of software design. At the
program component level, the design of data structures and the associated algorithms required to
manipulate them is essential to the creation of high-quality applications. At the application level,
the translation of a data model (derived as part of requirements engineering) into a database is
pivotal to achieving the business objectives of a system. At the business level, the collection of
information stored in disparate databases and reorganized into a “data warehouse” enables data
mining or knowledge discovery that can have an impact on the success of the business itself. In
every case, data design plays an important role.

Data Design at the Component Level

 Data design at the component level focuses on the representation of data structures that
are directly accessed by one or more software components. Wasserman has proposed a
set of principles that may be used to specify and design such data structures. In actuality,
 the design of data begins during the creation of the analysis model. Recalling that
requirements analysis and design often overlap, we consider the following set of
principles for data specification:
 1. The systematic analysis principles applied to function and behavior should also be
applied to data. We spend much time and effort deriving, reviewing, and specifying
functional requirements and preliminary design. Representations of data flow and content
should also be developed and reviewed, data objects should be identified, alternative data
organizations should be considered, and the impact of data modeling on software design
should be evaluated. For example, specification of a multiringed linked list may nicely
satisfy data requirements but lead to an unwieldy software design. An alternative data
organization may lead to better results.
 2. All data structures and the operations to be performed on each should be identified.
The design of an efficient data structure must take the operations to be performed on the
data structure into account . For example, consider a data structure made up of a set of
diverse data elements. The data structure is to be manipulated in a number of major
software functions. Upon evaluation of the operations performed on the data structure, an
abstract data type is defined for use in subsequent software design. Specification of the
abstract data type may simplify software design considerably.
 3. A data dictionary should be established and used to define both data and program
design. The concept of a data dictionary has been introduced in . A data dictionary
explicitly represents the relationships among data objects and the constraints on the
elements of a data structure. Algorithms that must take advantage of specific
relationships can be more easily defined if a dictionarylike data specification exists.
 4. Low-level data design decisions should be deferred until late in the design process. A
process of stepwise refinement may be used for the design of data. That is, overall data
organization may be defined during requirements analysis, refined during data design
work, and specified in detail during componentlevel design. The top-down approach to
data design provides benefits that are analogous to a top-down approach to software
design—major structural attributes are designed and evaluated first so that the
architecture of the data may be established.
  5. The representation of data structure should be known only to those modules that must
make direct use of the data contained within the structure. The concept of information
hiding and the related concept of coupling provide important insight into the quality of a
software design. This principle alludes to the importance of these concepts as well as "the
importance of separating the logical view of a data object from its physical view".
 6. A library of useful data structures and the operations that may be applied to them
should be developed. Data structures and operations should be viewed as a resource for
software design. Data structures can be designed for reusability. A library of data
structure templates (abstract data types) can reduce both specification and design effort
for data.
 7. A software design and programming language should support the specification and
realization of abstract data types. The implementation of a sophisticated data structure
can be made exceedingly difficult if no means for direct specification of the structure
exists in the programming language chosen for implementation.

5)Architectural Design

Introduction: The software needs the architectural design to represents the design of software.
IEEE defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of these
many architectural styles.
Each style will describe a system category that consists of :
 A set of components(eg: a database, computational modules) that will perform a function
required by the system.
 The set of connectors will help in coordination, communication, and cooperation between
the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties of the system.
The use of architectural styles is to establish a structure for all the components of the system.
Taxonomy of Architectural styles:

Data centred architectures:

 A data store will reside at the center of this architecture and is accessed frequently by the
other components that update, add, delete or modify the data present within the store.
 The figure illustrates a typical data centered style. The client software access a central
repository. Variation of this approach are used to transform the repository into a
blackboard when data related to client or data of interest for the client change the
notifications to client software.
 This data-centered architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the architecture
without the permission or concern of other clients.
 Data can be passed among clients using blackboard mechanism.

Data flow architectures:

 This kind of architecture is used when input data to be transformed into output data through
a series of computational manipulative components.
  The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has
a set of components called filters connected by pipes.
 Pipes are used to transmit data from one component to the next.
 Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.
 If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.

Call and Return architectures: It is used to create a program that is easy to scale and modify.
Many sub-styles exist within this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a network.
 Main program or Subprogram architectures: The main program structure decomposes
into number of subprograms or function into a control hierarchy. Main program contains
number of subprograms that can invoke other components.
Object Oriented architecture: The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The coordination and
communication between the components are established via the message passing.
Layered architecture:
 A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
 At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.
 6)Software Architecture

 The concept of software architecture is similar to the architecture of building.

 The architecture is not an operational software.
 The software architecture focuses on the role of software components.
 Software components consist of a simple program module or an object oriented class in an
architectural design.
 The architecture design extended and it consists of the database and the middleware that allows
the configuration of a network of clients and servers.

Following are the reasons for the importance of software architecture.

1. The representation of software architecture allows the communication between all stakeholder
and the developer.
2. The architecture focuses on the early design decisions that impact on all software engineering
work and it is the ultimate success of the system.
3. The software architecture composes a small and intellectually graspable model.
4. This model helps the system for integrating the components using which the components are
work together.

The architectural style

 The architectural style is a transformation and it is applied to the design of an entire system.
 The main aim of architectural style is to build a structure for all components of the system.
 An architecture of the system is redefined by using the architectural style.
 An architectural pattern such as architectural style introduces a transformation on the design of
an architecture.
 The software is constructed for computer based system and it shows one of the architectural
style from many of style.
 The design categories of architectural styles includes:

1. A set of components such as database, computational modules which perform the function
required by the system.
2. A set of connectors that allows the communication, coordination and cooperation between the
components.
3. The constraints which define the integration of components to form the system.
4. Semantic model allows a designer to understand the overall properties of a system by using
analysis of elements.

Architectural design

 The architectural design starts then the developed software is put into the context.
 The information is obtained from the requirement model and other information collect during
the requirement engineering.

Representing the system in context

All the following entities communicates with the target system through the interface that is small
rectangles shown in above figure.

Superordinate system
These system use the target system like a part of some higher-level processing scheme.
 Subordinate system
This systems is used by the target system and provide the data mandatory to complete target
system functionality.

Peer-level system
These system interact on peer-to-peer basis means the information is consumed by the target
system and the peers.

Actors
These are the entities like people, device which interact with the target system by consuming
information that is mandatory for requisite processing.

Defining Archetype

 An archetype is a class or pattern which represents a core abstraction i.e critical to implement or
design for the target system.
 A small set of archetype is needed to design even the systems are relatively complex.
 The target system consists of archetype that represent the stable elements of the architecture.
 Archetype is instantiated in many different forms based on the behavior of the system.
 In many cases, the archetype is obtained by examining the analysis of classes defined as a part
of the requirement model.

An Architecture Trade-off Analysis Method (ATAM)

ATAM was developed by the Software Engineering Institute (SEI) which started an iterative
evaluation process for software architecture.

The design analysis activities which are executed iteratively that are as follows:
1. Collect framework
Collect framework developed a set of use cases that represent the system according to user point
of view.
 2. Obtained requirement, Constraints, description of the environment.
These types of information are found as a part of requirement engineering and is used to verify
all the stakeholders are addressed properly.

3. Describe the architectural pattern

The architectural patterns are described using an architectural views which are as follows:

Module view: This view is for the analysis of assignment work with the components and the
degree in which abstraction or information hiding is achieved

Process view: This view is for the analysis of the software or system performance.

Data flow view: This view analyzes the level and check whether functional requirements are met
to the architecture.

4. Consider the quality attribute in segregation

The quality attributes for architectural design consist of reliability, performance, security,
maintainability, flexibility, testability, portability, re-usability etc.

5. Identify the quality attributes sensitivity

 The sensitivity of quality attributes achieved by making the small changes in the architecture
and find the sensitivity of the quality attribute which affects the performance.
 The attributes affected by the variation in the architecture are known as sensitivity points.
Mapping Requirements in Software Architecture

Software requirements can be mapped into various representations of the design model.
The architectural styles represent radically different architectures, so it should come as no
surprise that a comprehensive mapping that accomplishes the transition from the requirements
model to a variety of architectural styles does not exist. In fact, there is no practical mapping for
some architectural styles, and the designer must approach the translation of requirements to
design for these styles in an ad hoc fashion.

To illustrate one approach to architectural mapping, we consider the call and return
architecture—an extremely common structure for many types of systems. The mapping
technique to be presented enables a designer to derive reasonably complex call and return
architectures from data flow diagrams within the requirements model. The technique, sometimes
called structured design, has its origins in earlier design concepts that stressed modularity , top-
down design , and structured programming . Stevens, Myers, and Constantine were early
proponents of software design based on the flow of data through a system. Early work was
refined and presented in books by Myers and Yourdon and Constantine.

Structured design is often characterized as a data flow-oriented design method because it

provides a convenient transition from a data flow diagram to software architecture. The transition
from information flow (represented as a DFD) to program structure is accomplished as part of a
six-step process: (1) the type of information flow is established; (2) flow boundaries are
indicated; (3) the DFD is mapped into program structure; (4) control hierarchy is
defined; (5) resultant structure is refined using design measures and heuristics; and (6) the
architectural description is refined and elaborated.

The type of information flow is the driver for the mapping approach required in step 3. In
the following sections we examine two flow types.

Transform Flow

Recalling the fundamental system model (level 0 data flow diagram), information must
enter and exit software in an "external world" form. For example, data typed on a keyboard,
tones on a telephone line, and video images in a multimedia application are all forms of external
world information. Such externalized data must be converted into an internal form for
processing. Information enters the system along paths that transform external data into an
internal form. These paths are identified as incoming flow. At the kernel of the software, a
transition occurs. Incoming data are passed through a transform center and begin to move along
paths that now lead "out" of the software. Data moving along these paths are called outgoing
flow. The overall flow of data occurs in a sequential manner and follows one, or only a few,
"straight line" paths. When a segment of a data flow diagram exhibits these characteristics,
transform flow is present.

Transaction Flow

The fundamental system model implies transform flow; therefore, it is possible to

characterize all data flow in this category. However, information flow is often characterized by a
single data item, called a transaction, that triggers other data flow along one of many paths.
When a DFD takes the form shown in figure, transaction flow is present.

Transaction flow is characterized by data moving along an incoming path that converts
xternal world information into a transaction. The transaction is evaluated and, based on its value,
flow along one of many action paths is initiated. The hub of information flow from which many
action paths emanate is called a transaction center.

It should be noted that, within a DFD for a large system, both transform and transaction
flow may be present. For example, in a transaction-oriented flow, information flow along an
action path may have transform flow characteristics.
Software Engineering User Interface Design

User interface is the front-end application view to which user interacts in order to use the
software. The software becomes more popular if its user interface is:

 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interface screens
There are two types of User Interface:

1. Command Line Interface: Command Line Interface provides a command prompt, where
the user types the command and feeds to the system. The user needs to remember the
syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides the simple interactive
interface to interact with the system. GUI can be a combination of both hardware and
software. Using GUI, user interprets the software.
User Interface Design Process:
The analysis and design process of a user interface is iterative and can be represented by a
spiral model. The analysis and design process of user interface consists of four framework
activities.

[Link], task, environmental analysis, and modeling: Initially, the focus is based on the profile
of users who will interact with the system, i.e. understanding, skill and knowledge, type of user,
etc, based on the user’s profile users are made into categories. From each category requirements
are gathered. Based on the requirements developer understand how to develop the interface.
Once all the requirements are gathered a detailed analysis is conducted. In the analysis part, the
tasks that the user performs to establish the goals of the system are identified, described and
elaborated. The analysis of the user environment focuses on the physical work environment.
Among the questions to be asked are:

 Where will the interface be located physically?

 Will the user be sitting, standing, or performing other tasks unrelated to the interface?
  Does the interface hardware accommodate space, light, or noise constraints?
 Are there special human factors considerations driven by environmental factors?
2. Interface Design: The goal of this phase is to define the set of interface objects and actions
i.e. Control mechanisms that enable the user to perform desired tasks. Indicate how these
control mechanisms affect the system. Specify the action sequence of tasks and subtasks,
also called a user scenario. Indicate the state of the system when the user performs a
particular task. Always follow the three golden rules stated by Theo Mandel. Design issues
such as response time, command and action structure, error handling, and help facilities are
considered as the design model is refined. This phase serves as the foundation for the
implementation phase.
3. Interface construction and implementation: The implementation activity begins with the
creation of prototype (model) that enables usage scenarios to be evaluated. As iterative
design process continues a User Interface toolkit that allows the creation of windows,
menus, device interaction, error messages, commands, and many other elements of an
interactive environment can be used for completing the construction of an interface.
4. Interface Validation: This phase focuses on testing the interface. The interface should be
in such a way that it should be able to perform tasks correctly and it should be able to
handle a variety of tasks. It should achieve all the user’s requirements. It should be easy to
use and easy to learn. Users should accept the interface as a useful one in their work.

Golden Rules:
The following are the golden rules stated by Theo Mandel that must be followed during the
design of the interface.

Place the user in control:

 Define the interaction modes in such a way that does not force the user into unnecessary or
undesired actions: The user should be able to easily enter and exit the mode with little or no
effort.
 Provide for flexible interaction: Different people will use different interaction mechanisms,
some might use keyboard commands, some might use mouse, some might use touch
screen, etc, Hence all interaction mechanisms should be provided.
  Allow user interaction to be interruptable and undoable: When a user is doing a sequence
of actions the user must be able to interrupt the sequence to do some other work without
losing the work that had been done. The user should also be able to do undo operation.
 Streamline interaction as skill level advances and allow the interaction to be customized:
Advanced or highly skilled user should be provided a chance to customize the interface as
user wants which allows different interaction mechanisms so that user doesn’t feel bored
while using the same interaction mechanism.
 Hide technical internals from casual users: The user should not be aware of the internal
technical details of the system. He should interact with the interface just to do his work.
 Design for direct interaction with objects that appear on screen: The user should be able to
use the objects and manipulate the objects that are present on the screen to perform a
necessary task. By this, the user feels easy to control over the screen.
Reduce the user’s memory load:
 Reduce demand on short-term memory: When users are involved in some complex tasks
the demand on short-term memory is significant. So the interface should be designed in
such a way to reduce the remembering of previously done actions, given inputs and results.
 Establish meaningful defaults: Always initial set of defaults should be provided to the
average user, if a user needs to add some new features then he should be able to add the
required features.
 Define shortcuts that are intuitive: Mnemonics should be used by the user. Mnemonics
means the keyboard shortcuts to do some action on the screen.
 The visual layout of the interface should be based on a real-world metaphor: Anything you
represent on a screen if it is a metaphor for real-world entity then users would easily
understand.
 Disclose information in a progressive fashion: The interface should be organized
hierarchically i.e. on the main screen the information about the task, an object or some
behavior should be presented first at a high level of abstraction. More detail should be
presented after the user indicates interest with a mouse pick.
Make the interface consistent:
 Allow the user to put the current task into a meaningful context: Many interfaces have
dozens of screens. So it is important to provide indicators consistently so that the user
 know about the doing work. The user should also know from which page has navigated to
the current page and from the current page where can navigate.
 Maintain consistency across a family of applications: The development of some set of
applications all should follow and implement the same design, rules so that consistency is
maintained among applications.
 If past interactive models have created user expectations do not make changes unless there
is a compelling reason.

REFERENCES:

TEXT BOOK: Roger S Pressman, “Software Engineering - A Practitioner’s Approach”,

Sixth Edition, McGraw Hill International Edition, New York: 2005.

[Link]

[Link] [Link]

[Link]
 Software Engineering

UNIT-IV:

Testing Strategies: Strategic Approach to Software Testing- Test Strategies for

Conventional and Object Oriented Software - Validation Testing - System Testing -Art of
Debugging. Testing Tactics: Fundamentals - White Box- Basis Path - Control Structure - Black
Box Testing Methods

Software Testing Basics

Software testing can be stated as the process of verifying and validating that a software or
application is bug free, meets the technical requirements as guided by it’s design and
development and meets the user requirements effectively and efficiently with handling all the
exceptional and boundary cases.

The process of software testing aims not only at finding faults in the existing software but also at
finding measures to improve the software in terms of efficiency, accuracy and usability. It
mainly aims at measuring specification, functionality and performance of a software program or
application.

Software testing can be divided into two steps:

1. Verification: it refers to the set of tasks that ensure that software correctly implements a
specific function.
2. Validation: it refers to a different set of tasks that ensure that the software that has been built
is traceable to customer requirements.

Verification: “Are we building the product right?”

Validation: “Are we building the right product?”

What are different types of software testing?

Software Testing can be broadly classified into two types:

Department Of Computer Application

Indo-American College,Cheyyar 1
 Software Engineering

1. Manual Testing: Manual testing includes testing a software manually, i.e., without using any
automated tool or any script. In this type, the tester takes over the role of an end-user and tests
the software to identify any unexpected behavior or bug. There are different stages for manual
testing such as unit testing, integration testing, system testing, and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test a software to ensure the completeness of
testing. Manual testing also includes exploratory testing, as testers explore the software to
identify errors in it.

2. Automation Testing: Automation testing, which is also known as Test Automation, is when
the tester writes scripts and uses another software to test the product. This process involves
automation of a manual process. Automation Testing is used to re-run the test scenarios that were
performed manually, quickly, and repeatedly.
Apart from regression testing, automation testing is also used to test the application from load,
performance, and stress point of view. It increases the test coverage, improves accuracy, and
saves time and money in comparison to manual testing.

What are different levels of software testing?

Software level testing can be majorly classified into 4 levels:

1. Unit Testing: A level of the software testing process where individual units/components of a
software/system are tested. The purpose is to validate that each unit of the software performs as
designed.
2. Integration Testing: A level of the software testing process where individual units are
combined and tested as a group. The purpose of this level of testing is to expose faults in the
interaction between integrated units.
3. System Testing: A level of the software testing process where a complete, integrated
system/software is tested. The purpose of this test is to evaluate the system’s compliance with the
specified requirements.
4. Acceptance Testing: A level of the software testing process where a system is tested for
acceptability. The purpose of this test is to evaluate the system’s compliance with the business
requirements and assess whether it is acceptable for delivery.

Department Of Computer Application

Indo-American College,Cheyyar 2
 Software Engineering

Following are the issues considered to implement software testing strategies.

 Specify the requirement before testing starts in a quantifiable manner.

 According to the categories of the user generate profiles for each category of user.
 Produce a robust software and it's designed to test itself.
 Should use the Formal Technical Reviews (FTR) for the effective testing.
 To access the test strategy and test cases FTR should be conducted.
 To improve the quality level of testing generate test plans from the users feedback.

Test strategies for conventional software

Following are the four strategies for conventional software:

1) Unit testing
2) Integration testing
3) Regression testing
4) Smoke testing

Department Of Computer Application

Indo-American College,Cheyyar 3
 Software Engineering

1) Unit testing

 Unit testing focus on the smallest unit of software design, i.e module or software component.
 Test strategy conducted on each module interface to access the flow of input and output.
 The local data structure is accessible to verify integrity during execution.
 Boundary conditions are tested.
 In which all error handling paths are tested.
 An Independent path is tested.
Following figure shows the unit testing:

Department Of Computer Application

Indo-American College,Cheyyar 4
 Software Engineering

Unit test environment

The unit test environment is as shown in following figure:

Difference between stub and driver

Stub Driver

Stub is considered as subprogram. It is a simple main program.

Stub does not accept test case data. Driver accepts test case data.

It replace the modules of the program into subprograms Pass the data to the tested components and
and are tested by the next driver. print the returned result.

2) Integration testing

Integration testing is used for the construction of software architecture.

Department Of Computer Application

Indo-American College,Cheyyar 5
 Software Engineering

There are two approaches of incremental testing are:

i) Non incremental integration testing
ii) Incremental integration testing

i) Non incremental integration testing

 Combines all the components in advanced.

 A set of error is occurred then the correction is difficult because isolation cause is complex.

ii) Incremental integration testing

 The programs are built and tested in small increments.

 The errors are easier to correct and isolate.
 Interfaces are fully tested and applied for a systematic test approach to it.

Following are the incremental integration strategies:

a. Top-down integration
b. Bottom-up integration

a. Top-down integration

 It is an incremental approach for building the software architecture.

 It starts with the main control module or program.
 Modules are merged by moving downward through the control hierarchy.

Department Of Computer Application

Indo-American College,Cheyyar 6
 Software Engineering

Following figure shows the top down integration.

Problems with top-down approach of testing

Following are the problems associated with top-down approach of testing as follows:

 Top-down approach is an incremental integration testing approach in which the test conditions
are difficult to create.
 A set of errors occur, then correction is difficult to make due to the isolation of cause.
 The programs are expanded into various modules due to the complications.
 If the previous errors are corrected, then new get created and the process continues. This
situation is like an infinite loop.

b. Bottom-up integration

In bottom up integration testing the components are combined from the lowest level in the
program structure.

Department Of Computer Application

Indo-American College,Cheyyar 7
 Software Engineering

The bottom-up integration is implemented in following steps:

 The low level components are merged into clusters which perform a specific software sub
function.
 A control program for testing(driver) coordinate test case input and output.
 After these steps are tested in cluster.
 The driver is removed and clusters are merged by moving upward on the program structure.

Following figure shows the bottom up integration:

Department Of Computer Application

Indo-American College,Cheyyar 8
 Software Engineering

3) Regression testing

 In regression testing the software architecture changes every time when a new module is added
as part of integration testing.

4) smoke testing

 The developed software component are translated into code and merge to complete the product.

Difference between Regression and smoke testing

Regression testing Smoke testing

Regression testing is used to check defects At the time of developing a software

generated to other modules by making the changes product smoke testing is used.
in existing programs.

In regression tested components are tested again to It permit the software development team
verify the errors. to test projects on a regular basis.

Regression testing needs extra manpower because Smoke testing does not need an extra
the cost of the project increases. manpower because it does not affect the
cost of project.

Testers conduct the regression testing. Developer conducts smoke testing just
before releasing the product.

Department Of Computer Application

Indo-American College,Cheyyar 9
 Software Engineering

Alpha and Beta testing

Alpha testing Beta testing

Alpha testing is executed at developers end by the Beta testing is executed at end-user sites in the
customer. absence of a developer.

It handles the software project and applications. It usually handles software product.

It is not open to market and the public. It is always open to the market and the public.

Alpha testing does not have any different name. Beta testing is also known as the field testing.

Alpha testing is not able to test the errors because the In beta testing, the developer corrects the errors
developer does not known the type of user. as users report the problems.

In alpha testing, developer modifies the codes before In beta testing, developer modifies the code after
release the software without user feedback. getting the feedback from user.

Types of System Testing:

 Performance Testing:
Performance Testing is a type of software testing that is carried out to test the speed,
scalability, stability and reliability of the software product or application.
 Load Testing:
Load Testing is a type of software Testing which is carried out to determine the behavior of
a system or software product under extreme load.
 Stress Testing:
Stress Testing is a type of software testing performed to check the robustness of the system
under the varying loads.

Department Of Computer Application

Indo-American College,Cheyyar 10
 Software Engineering

 Scalability Testing:
Scalability Testing is a type of software testing which is carried out to check the
performance of a software application or system in terms of its capability to scale up or
scale down the number of user request load.

The art of debugging.

Software testing is a process that can be systematically planned and specified. Test case
design can be conducted, a strategy can be defined, and results can be evaluated against
prescribed expectations.

Debugging occurs as a consequence of successful testing. That is, when a test case uncovers an
error, debugging is the process that results in the removal of the error. Although debugging can
and should be an orderly process, it is still very much an art. A software engineer, evaluating the
results of a test, is often confronted with a "symptomatic" indication of a software problem. That
is, the external manifestation of the error and the internal cause of the error may have no obvious
relationship to one another. The poorly understood mental process that connects a symptom to a
cause is debugging.

The Debugging Process

Debugging is not testing but always occurs as a consequence of testing.4 Referring to figure, the
debugging process begins with the execution of a test case. Results are assessed and a lack of
correspondence between expected and actual performance is encountered. In many cases, the
noncorresponding data are a symptom of an underlying cause as yet hidden. The debugging
process attempts to match symptom with cause, thereby leading to error correction.

Department Of Computer Application

Indo-American College,Cheyyar 11
 Software Engineering

The debugging process will always have one of two outcomes: (1) the cause will be
found and corrected, or (2) the cause will not be found. In the latter case, the person performing
debugging may suspect a cause, design a test case to help validate that suspicion, and work
toward error correction in an iterative fashion.

However, a few characteristics of bugs provide some clues:

1. The symptom and the cause may be geographically remote. That is, the symptom may appear
in one part of a program, while the cause may actually be located at a site that is far removed.
Highly coupled program structures exacerbate this situation.
2. The symptom may disappear (temporarily) when another error is corrected.
3. The symptom may actually be caused by nonerrors (e.g., round-off inaccuracies).
4. The symptom may be caused by human error that is not easily traced.
5. The symptom may be a result of timing problems, rather than processing problems.
6. It may be difficult to accurately reproduce input conditions (e.g., a real-time application in
which input ordering is indeterminate).
7. The symptom may be intermittent. This is particularly common in embedded systems that
couple hardware and software inextricably.
8. The symptom may be due to causes that are distributed across a number of tasks running on
different processors.

During debugging, we encounter errors that range from mildly annoying (e.g., an incorrect
output format) to catastrophic (e.g. the system fails, causing serious economic or physical
damage). As the consequences of an error increase, the amount of pressure to find the cause also
increases. Often, pressure sometimes forces a software developer to fix one error and at the same
time introduce two more.

Psychological Considerations
Unfortunately, there appears to be some evidence that debugging prowess is an innate
human trait. Some people are good at it and others aren't. Although experimental evidence on
debugging is open to many interpretations, large variances in debugging ability have been

Department Of Computer Application

Indo-American College,Cheyyar 12
 Software Engineering

reported for programmers with the same education and experience. Commenting on the human
aspects of debugging, Shneiderman states:

Debugging is one of the more frustrating parts of programming. It has elements of

problem solving or brain teasers, coupled with the annoying recognition that you have made a
mistake. Heightened anxiety and the unwillingness to accept the possibility of errors increases
the task difficulty. Fortunately, there is a great sigh of relief and a lessening of tension when the
bug is ultimately . . . corrected.

Although it may be difficult to "learn" debugging, a number of approaches to the problem can be
proposed. We examine these in the next section.

Debugging Approaches

Regardless of the approach that is taken, debugging has one overriding objective: to find and
correct the cause of a software error. The objective is realized by a combination of systematic
evaluation, intuition, and luck. Bradley describes the debugging approach in this way:

Debugging is a straightforward application of the scientific method that has been developed over
2,500 years. The basis of debugging is to locate the problem's source [the cause] by binary
partitioning, through working hypotheses that predict new values to be examined.

Take a simple non-software example: A lamp in my house does not work. If nothing in the house
works, the cause must be in the main circuit breaker or outside; I look around to see whether the
neighborhood is blacked out. I plug the suspect lamp into a working socket and a working
appliance into the suspect circuit. So goes the alternation of hypothesis and test.

In general, three categories for debugging approaches may be proposed : (1) brute
force, (2) backtracking, and (3) cause elimination.

The brute force category of debugging is probably the most common and least efficient method
Department Of Computer Application
Indo-American College,Cheyyar 13
 Software Engineering

for isolating the cause of a software error. We apply brute force debugging methods when all
else fails. Using a "let the computer find the error" philosophy, memory dumps are taken, run-
time traces are invoked, and the program is loaded with WRITE statements. We hope that
somewhere in the morass of information that is produced we will find a clue that can lead us to
the cause of an error. Although the mass of information produced may ultimately lead to success,
it more frequently leads to wasted effort and time. Thought must be expended first!

Backtracking is a fairly common debugging approach that can be used successfully in small
programs. Beginning at the site where a symptom has been uncovered, the source code is traced
backward (manually) until the site of the cause is found. Unfortunately, as the number of source
lines increases, the number of potential backward paths may become unmanageably large.

The third approach to debugging—cause elimination—is manifested by induction or deduction

and introduces the concept of binary partitioning. Data related to the error occurrence are
organized to isolate potential causes. A "cause hypothesis" is devised and the aforementioned
data are used to prove or disprove the hypothesis. Alternatively, a list of all possible causes is
developed and tests are conducted to eliminate each. If initial tests indicate that a particular cause
hypothesis shows promise, data are refined in an attempt to isolate the bug.
Each of these debugging approaches can be supplemented with debugging tools. We can apply a
wide variety of debugging compilers, dynamic debugging aids ("tracers"), automatic test case
generators, memory dumps, and cross-reference maps. However, tools are not a substitute for
careful evaluation based on a complete software design document and clear source code.

Any discussion of debugging approaches and tools is incomplete without mention of a powerful
ally—other people! Each of us can recall puzzling for hours or days over a persistent bug. A
colleague wanders by and in desperation we explain the problem and throw open the listing.
Instantaneously (it seems), the cause of the error is uncovered. Smiling smugly, our colleague
wanders off. A fresh viewpoint, unclouded by hours of frustration, can do wonders. A final
maxim for debugging might be: "When all else fails, get help!"

Once a bug has been found, it must be corrected. But, as we have already noted, the correction of
Department Of Computer Application
Indo-American College,Cheyyar 14
 Software Engineering

a bug can introduce other errors and therefore do more harm than good. Van Vleck suggests
three simple questions that every software engineer should ask before making the "correction"
that removes the cause of a bug:

1. Is the cause of the bug reproduced in another part of the program? In many situations, a
program defect is caused by an erroneous pattern of logic that may be reproduced elsewhere.
Explicit consideration of the logical pattern may result in the discovery of other errors.

2. What "next bug" might be introduced by the fix I'm about to make? Before the correction
is made, the source code (or, better, the design) should be evaluated to assess coupling of logic
and data structures. If the correction is to be made in a highly coupled section of the program,
special care must be taken when any change is made.

3. What could we have done to prevent this bug in the first place? This question is the first
step toward establishing a statistical software quality assurance approach . If we correct the
process as well as the product, the bug will be removed from the current program and may be
eliminated from all future programs.

What are different techniques of Software Testing?

Software techniques can be majorly classified into two categories:

1. Black Box Testing: The technique of testing in which the tester doesn’t have access to the
source code of the software and is conducted at the software interface without concerning with
the internal logical structure of the software is known as black box testing.
2. White-Box Testing: The technique of testing in which the tester is aware of the internal
workings of the product, have access to it’s source code and is conducted by making sure that all
internal operations are performed according to the specifications is known as white box testing.

Department Of Computer Application

Indo-American College,Cheyyar 15
 Software Engineering

BLACK BOX TESTING WHITE BOX TESTING

Internal workings of an application are not

required. Knowledge of the internal workings is must.

Also known as closed box/data driven

testing. Also knwon as clear box/structural testing.

End users, testers and developers. Normally done by testers and developers.

THis can only be done by trial and error Data domains and internal boundaries can be
method. better tested.

Control Structure Testing

Control structure testing is used to increase the coverage area by testing various control
structures present in the program. The different types of testing performed under control
structure testing are as follows-

1. Condition Testing
2. Data Flow Testing
3. Loop Testing
1. Condition Testing :
Condition testing is a test cased design method, which ensures that the logical condition and
decision statements are free from errors. The errors present in logical conditions can be incorrect
boolean operators, missing parenthesis in a booleans expression, error in relational operators,
arithmetic expressions, and so on.
The common types of logical conditions that are tested using condition testing are-

1. A relation expression, like E1 op E2 where ‘E1’ and ‘E2’ are arithmetic expressions and
‘OP’ is an operator.
2. A simple condition like any relational expression preceded by a NOT (~) operator.
For example, (~E1) where ‘E1’ is an arithmetic expression and ‘a’ denotes NOT operator.

Department Of Computer Application

Indo-American College,Cheyyar 16
 Software Engineering

3. A compound condition consists of two or more simple conditions, Boolean operator, and
parenthesis.
For example, (E1 & E2)|(E2 & E3) where E1, E2, E3 denote arithmetic expression and ‘&’
and ‘|’ denote AND or OR operators.

4. A Boolean expression consists of operands and a Boolean operator like ‘AND’, OR, NOT.
For example, ‘A|B’ is a Boolean expression where ‘A’ and ‘B’ denote operands and |
denotes OR operator.
2. Data Flow Testing :
The data flow test method chooses the test path of a program based on the locations of the
definitions and uses all the variables in the program.
The data flow test approach is depicted as follows suppose each statement in a program is
assigned a unique statement number and that theme function cannot modify its parameters or
global variables.
For example, with S as its statement number.

DEF (S) = {X | Statement S has a definition of X}

USE (S) = {X | Statement S has a use of X}

If statement S is an if loop statement, them its DEF set is empty and its USE set depends on the
state of statement S. The definition of the variable X at statement S is called the line of statement
S’ if the statement is any way from S to statement S’ then there is no other definition of X.

A definition use (DU) chain of variable X has the form [X, S, S’], where S and S’ denote
statement numbers, X is in DEF(S) and USE(S’), and the definition of X in statement S is line at
statement S’.

A simple data flow test approach requires that each DU chain be covered at least once. This
approach is known as the DU test approach. The DU testing does not ensure coverage of all
branches of a program.

However, a branch is not guaranteed to be covered by DU testing only in rar cases such as then
in which the other construct does not have any certainty of any variable in its later part and the

Department Of Computer Application

Indo-American College,Cheyyar 17
 Software Engineering

other part is not present. Data flow testing strategies are appropriate for choosing test paths of a
program containing nested if and loop statements.

3. Loop Testing :
Loop testing is actually a white box testing technique. It specifically focuses on the validity of
loop construction.
Following are the types of loops.
1. Simple Loop – The following set of test can be applied to simple loops, where the
maximum allowable number through the loop is n.
1. Skip the entire loop.
2. Traverse the loop only once.
3. Traverse the loop two times.
4. Make p passes through the loop where p<n.
5. Traverse the loop n-1, n, n+1 times.

2. Concatenated Loops – If loops are not dependent on each other, contact loops can be
tested using the approach used in simple loops. if the loops are interdependent, the steps are
followed in nested loops.

Department Of Computer Application

Indo-American College,Cheyyar 18
 Software Engineering

3. Nested Loops – Loops within loops are called as nested loops. when testing nested loops,
the number of tested increases as level nesting increases.
The following steps for testing nested loops are as follows-
1. Start with inner loop. set all other loops to minimum values.
2. Conduct simple loop testing on inner loop.
3. Work outwards.
4. Continue until all loops tested.
4. Unstructured loops – This type of loops should be redesigned, whenever possible, to
reflect the use of unstructured the structured programming constructs.

Department Of Computer Application

Indo-American College,Cheyyar 19
 Software Engineering

What is black box testing?

Black box testing refers to a software testing method where the SUT (Software under Test)
functionality is tested without worrying about its details of implementation, internal path
knowledge and internal code structure of the software.

This method of testing is completely based on the specifications and requirements of the
software.

Department Of Computer Application

Indo-American College,Cheyyar 20
 Software Engineering

The focus of the black box testing is upon the output and inputs of the software system rather
than the program’s internal knowledge.

The system that undergoes this type of testing is considered as the “black box”, and it can be any
software like a database, website or an Operating System.

What Is The Purpose Of Black Box Testing?

Black box testing focuses on testing the complete functionality of the system as well as its
behavior.

This testing method is also referred to as behavioral testing and functional testing.

This testing method is critical during the stages of software testing life cycle like regression
testing, acceptance, unit, system, integration and software development.

The techniques of Black box testing are beneficial for the end users who wish to perform
software verification.

Techniques of Black Box Testing

The following are the techniques employed while using Black box testing for a software
application.

BVA or Boundary Value Analysis:

Department Of Computer Application
Indo-American College,Cheyyar 21
 Software Engineering

It is one among the useful and critical Black box testing technique that helps in equivalence
partitioning. BVA helps in testing any software having a boundary or extreme values.

This technique is capable of identifying the flaws of the limits of the input values rather than
focusing on the range of input value. Boundary Value Analysis also deals with edge or extreme
output values.

Equivalence Class Partitioning:

Department Of Computer Application

Indo-American College,Cheyyar 22
 Software Engineering

This technique of Black box testing is widely used to write test cases. It can be useful in
reducing a broad set of possible inputs to smaller but effective ones.

It is performed through the division of inputs as classes, and each class is given a value.

It is applied when the need for exhaustive testing arises and for resisting the redundancy of
inputs.

State Transition Testing

This technique usually considers the state, outputs, and inputs of a system during a specific
period.

Based on the type of software that is tested, it checks for the behavioral changes of a system in a
particular state or another state while maintaining the same inputs.

Department Of Computer Application

Indo-American College,Cheyyar 23
 Software Engineering

The test cases for this technique are created by checking the sequence of transitions and state or
events among the inputs.

The whole set of test cases will have the traversal of the expected output values and all states.

Decision Table Testing:

In some instances, the inputs combinations can become very complicated for tracking several
possibilities.

Such complex situations rely on decision tables, as it offers the testers an organized view about
the inputs combination and the expected output.

This technique is identical to the graph-based testing technique; the major difference is using
tables instead of diagrams or graphs.

Department Of Computer Application

Indo-American College,Cheyyar 24
 Software Engineering

Graph-Based Testing:

This technique of Black box testing involves a graph drawing that depicts the link between the
causes (inputs) and the effects (output), which trigger the effects.

This testing utilizes different combinations of output and inputs. It is a helpful technique to
understand the software’s functional performance, as it visualizes the flow of inputs and outputs
in a lively fashion.

REFERENCES:
TEXT BOOK: Roger S Pressman, “Software Engineering - A Practitioner’s Approach”, Sixth
Edition, McGraw Hill International Edition, New York: 2005.
[Link]
[Link] [Link]
[Link]

Department Of Computer Application

Indo-American College,Cheyyar 25
 Software Engineering

UNIT-V:

Project Management: Management Spectrum - People - Product - Process - Project. Estimation:

Project Planning Process - Resources - Software Project Estimation - Project Scheduling -
Quality Concepts - Software Quality Assurance - Formal Technical Reviews.

The Management Spectrum:

In software engineering, the management spectrum describes the management of a

software project. The management of a software project starts from requirement analysis and
finishes based on the nature of the product, it may or may not end because almost all software
products faces changes and requires support. It is about turning the project from plan to reality.

The management spectrum focuses on the four P’s; people, product, process and project. Here,
the manager of the project has to control all these P’s to have a smooth flow in the progress of
the project and to reach the goal.
The four P’s of management spectrum are

1. People
2. Product
3. Process
4. Project

The four P’s of management spectrum has been described briefly in below.

The People:

People of a project includes from manager to developer, from customer to end user. But mainly
people of a project highlight the developers. It is so important to have highly skilled and
motivated developers that the Software Engineering Institute has developed a People
Management Capability Maturity Model (PM-CMM),

The Product:

Department Of Computer Applications

Indo-American College, Cheyyar 1
 Software Engineering

The product is the ultimate goal of the project. This is any types of software product that
has to be developed. To develop a software product successfully, all the product objectives and
scopes should be established, alternative solutions should be considered and technical and
management constraints should be identified beforehand. Lack of these information, it is
impossible to define reasonable and accurate estimation of the cost, an effective assessment of
risks, a realistic breakdown of project tasks or a manageable project schedule that provides a
meaningful indication of progress.

The Process:

A software process provides the framework from which a comprehensive plan for
software development can be established. A number of different tasks sets— tasks, milestones,
work products, and quality assurance points—enable the framework activities to be adapted to
the characteristics of the software project and the requirements of the project team.
Finally, umbrella activities overlay the software process model. Umbrella activities are
independent of any one framework activity and occur throughout the process.

The Project:

The project is the complete software project that includes requirement analysis,
development, delivery, maintenance and updates. The project manager of a project or sub-project
is responsible for managing the people, product and process. The responsibilities or activities of
software project manager would be a long list but that has to be followed to avoid project failure.

Department Of Computer Applications

Indo-American College, Cheyyar 2
 Software Engineering

A software project could be extremely complex and as per the industry data the failure
rate is high. Its merely due to the development but mostly due to the steps before development
and sometimes due to the lack of maintenance.

Software Engineering Project Planning

Once a project is found to be possible, computer code project managers undertake project
designing. Project designing is undertaken and completed even before any development activity
starts. Project designing consists of subsequent essential activities:

Estimating the subsequent attributes of the project:

 Project size:
What’s going to be downside quality in terms of the trouble and time needed to develop the
product?
 Cost:
What proportion is it reaching to value to develop the project?
 Duration:
However long is it reaching to want complete development?
 Effort:
What proportion effort would be required?
The effectiveness of the following designing activities relies on the accuracy of those
estimations.

 planning force and alternative resources

 workers organization and staffing plans
 Risk identification, analysis, and abatement designing
 Miscellaneous arranges like quality assurance plan, configuration, management arrange,
etc.

Department Of Computer Applications

Indo-American College, Cheyyar 3
 Software Engineering

Precedence ordering among project planning activities:

The different project connected estimates done by a project manager have already been
mentioned. The below diagram shows the order during which vital project coming up with
activities is also undertaken. It may be simply discovered that size estimation is that the 1st
activity. It’s conjointly the foremost basic parameter supported that all alternative coming up
with activities square measure dispensed, alternative estimations like the estimation of effort,
cost, resource, and project length also are vital elements of the project coming up with.

Sliding Window Planning:

Project designing needs utmost care and a spotlight since commitment to unrealistic time and
resource estimates end in schedule slippage. Schedule delays will cause client discontent and
adversely have an effect on team morale. It will even cause project failure.
However, project designing could be a terribly difficult activity. particularly for giant
comes, it’s pretty much troublesome to create correct plans. A region of this issue is thanks to the
actual fact that the correct parameters, the scope of the project, project workers, etc. might
amendment throughout the span of the project. So as to beat this drawback, generally project
managers undertake project designing little by little. Designing a project over a variety of stages
protects managers from creating huge commitments too early. This method of staggered
designing is thought of as window designing. Within the window technique, beginning with
associate initial set up, the project is planned additional accurately in sequential development
stages.

Department Of Computer Applications

Indo-American College, Cheyyar 4
 Software Engineering

At the beginning of a project, project managers have incomplete information concerning

the main points of the project. Their info base step by step improves because the project
progresses through completely different phases. When the completion of each section, the project
managers will set up every ulterior section additional accurately and with increasing levels of
confidence.

Estimation is the process of finding an estimate, or approximation, which is a value that can be
used for some purpose even if input data may be incomplete, uncertain, or unstable.

Estimation determines how much money, effort, resources, and time it will take to build a
specific system or product. Estimation is based on −

 Past Data/Past Experience

 Available Documents/Knowledge

 Assumptions

 Identified Risks

The four basic steps in Software Project Estimation are −

 Estimate the size of the development product.

 Estimate the effort in person-months or person-hours.

 Estimate the schedule in calendar months.

 Estimate the project cost in agreed currency.

Observations on Estimation

 Estimation need not be a one-time task in a project. It can take place during −

o Acquiring a Project.

o Planning the Project.

o Execution of the Project as the need arises.

 Project scope must be understood before the estimation process begins. It will be helpful
to have historical Project Data.
Department Of Computer Applications
Indo-American College, Cheyyar 5
 Software Engineering

 Project metrics can provide a historical perspective and valuable input for generation of
quantitative estimates.

 Planning requires technical managers and the software team to make an initial
commitment as it leads to responsibility and accountability.

 Past experience can aid greatly.

 Use at least two estimation techniques to arrive at the estimates and reconcile the
resulting values. Refer Decomposition Techniques in the next section to learn about
reconciling estimates.

 Plans should be iterative and allow adjustments as time passes and more details are
known.

General Project Estimation Approach

The Project Estimation Approach that is widely used is Decomposition Technique.

Decomposition techniques take a divide and conquer approach. Size, Effort and Cost estimation
are performed in a stepwise manner by breaking down a Project into major Functions or related
Software Engineering Activities.

Step 1 − Understand the scope of the software to be built.

Step 2 − Generate an estimate of the software size.

 Start with the statement of scope.

 Decompose the software into functions that can each be estimated individually.

 Calculate the size of each function.

 Derive effort and cost estimates by applying the size values to your baseline productivity
metrics.

 Combine function estimates to produce an overall estimate for the entire project.

Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost
estimates by breaking down a project into related software engineering activities.

Department Of Computer Applications

Indo-American College, Cheyyar 6
 Software Engineering

 Identify the sequence of activities that need to be performed for the project to be
completed.

 Divide activities into tasks that can be measured.

 Estimate the effort (in person hours/days) required to complete each task.

 Combine effort estimates of tasks of activity to produce an estimate for the activity.

 Obtain cost units (i.e., cost/unit effort) for each activity from the database.

 Compute the total effort and cost for each activity.

 Combine effort and cost estimates for each activity to produce an overall effort and cost
estimate for the entire project.

Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from
Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if
widely divergent estimates occur conduct further investigation concerning whether −

 The scope of the project is not adequately understood or has been misinterpreted.

 The function and/or activity breakdown is not accurate.

 Historical data used for the estimation techniques is inappropriate for the application, or
obsolete, or has been misapplied.

Step 5 − Determine the cause of divergence and then reconcile the estimates.

Estimation Accuracy

Accuracy is an indication of how close something is to reality. Whenever you generate an

estimate, everyone wants to know how close the numbers are to reality. You will want every
estimate to be as accurate as possible, given the data you have at the time you generate it. And
of course you don’t want to present an estimate in a way that inspires a false sense of
confidence in the numbers.

Department Of Computer Applications

Indo-American College, Cheyyar 7
 Software Engineering

Important factors that affect the accuracy of estimates are −

 The accuracy of all the estimate’s input data.

 The accuracy of any estimate calculation.

 How closely the historical data or industry data used to calibrate the model matches the
project you are estimating.

 The predictability of your organization’s software development process.

 The stability of both the product requirements and the environment that supports the
software engineering effort.

 Whether or not the actual project was carefully planned, monitored and controlled, and
no major surprises occurred that caused unexpected delays.

Following are some guidelines for achieving reliable estimates −

 Base estimates on similar projects that have already been completed.

 Use relatively simple decomposition techniques to generate project cost and effort
estimates.

 Use one or more empirical estimation models for software cost and effort estimation.

Refer to the section on Estimation Guidelines in this chapter.

To ensure accuracy, you are always advised to estimate using at least two techniques and
compare the results.

Estimation Issues

Often, project managers resort to estimating schedules skipping to estimate size. This may be
because of the timelines set by the top management or the marketing team. However, whatever
the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to
accommodate the scope changes.

Department Of Computer Applications

Indo-American College, Cheyyar 8
 Software Engineering

While estimating, certain assumptions may be made. It is important to note all these
assumptions in the estimation sheet, as some still do not document assumptions in estimation
sheets.

Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often
treated as though they are accurate.

The best way of expressing estimates is as a range of possible outcomes by saying, for example,
that the project will take 5 to 7 months instead of stating it will be complete on a particular date
or it will be complete in a fixed no. of months. Beware of committing to a range that is too
narrow as that is equivalent to committing to a definite date.

 You could also include uncertainty as an accompanying probability value. For example,
there is a 90% probability that the project will complete on or before a definite date.

 Organizations do not collect accurate project data. Since the accuracy of the estimates
depend on the historical data, it would be an issue.

 For any project, there is a shortest possible schedule that will allow you to include the
required functionality and produce quality output. If there is a schedule constraint by
management and/or client, you could negotiate on the scope and functionality to be
delivered.

 Agree with the client on handling scope creeps to avoid schedule overruns.

 Failure in accommodating contingency in the final estimate causes issues. For e.g.,
meetings, organizational events.

 Resource utilization should be considered as less than 80%. This is because the resources
would be productive only for 80% of their time. If you assign resources at more than
80% utilization, there is bound to be slippages.

Department Of Computer Applications

Indo-American College, Cheyyar 9
 Software Engineering

Estimation Guidelines

 During estimation, ask other people's experiences. Also, put your own experiences at
task.

 Assume resources will be productive for only 80 percent of their time. Hence, during
estimation take the resource utilization as less than 80%.

 Resources working on multiple projects take longer to complete tasks because of the
time lost switching between them.

 Include management time in any estimate.

 Always build in contingency for problem solving, meetings and other unexpected events.

 Allow enough time to do a proper project estimate. Rushed estimates are inaccurate,
high-risk estimates. For large development projects, the estimation step should really be
regarded as a mini project.

 Where possible, use documented data from your organization’s similar past projects. It
will result in the most accurate estimate. If your organization has not kept historical data,
now is a good time to start collecting it.

 Use developer-based estimates, as the estimates prepared by people other than those who
will do the work will be less accurate.

 Use several different people to estimate and use several different estimation techniques.

 Reconcile the estimates. Observe the convergence or spread among the estimates.
Convergence means that you have got a good estimate. Wideband-Delphi technique can
be used to gather and discuss estimates using a group of people, the intention being to
produce an accurate, unbiased estimate.

 Re-estimate the project several times throughout its life cycle.

Department Of Computer Applications

Indo-American College, Cheyyar 10
 Software Engineering

Types of Resources Used in Project Development

Project resources simply mean resources that are required for successful development
and completion of project. These resources can be capital, people, material, tool, or supplies that
are helpful to carry out certain tasks in project. Without these resources, it is impossible to
complete project. In project planning phase, identification of resources that are required for
completion of project and how they will be allocated is key element and very important task to
do. In project management, some resources that are required are assigned to each task of project
to get job done.
There are three types of resources that are considered and are very essential for execution of
project and completion of project on time and on budget. These resources can be denoted by
pyramid which is also known as Resource Pyramid. At base of pyramid i.e. last layer, hardware
and software tools are present, then at middle layer, reusable components are present, and at top
of pyramid i.e. top layer, human resources are present. This is shown in following diagram :

When software planner wants to specify resources, they specify it using four characteristics :

 Description of resource
 Resource availability
 Time of resource when it will be available
 Duration of resource availability
Department Of Computer Applications
Indo-American College, Cheyyar 11
 Software Engineering

Types of resources :
1. Human Resource –
Human plays an important role in software development process. No matter what size is
and how much complexity is there in project, if you want to perform project task in an
effective manner, then human resources are very essential. In software industry, people are
assigned some organizational positions such as manager, software developer, software
testing, engineer, and so on. These positions are according to their skills and specialty.
For small project only, single individual can perform all these roles. But for large project,
team of people works on it. The total number of people that are required for project is
estimated by calculating development effort inters of person-months.

2. Reusable Components –
For bringing ease in software development process or to accelerate development process
software, industry prefers to use some ready software components. The components can be
defined as the software building blocks that can be created and reused in software
development process. Generally, regardless of their type, size, or complexity, all projects
need money. Managing budget for project is one of most important tasks that all project
managers have to do. The reusable resources also known as cost resources are very helpful
as they help in reducing overall cost of development. The use of components emphasizes
reusability. This is also termed as Component-Based Software Engineering.
3. Hardware and Software tools –
These are actually material resources that are part of project. This type of resource should
be planned before starting development of project otherwise it way causes problems for the
project.
For example, if you require certain software elements during performing task and somehow
you can’t manage to get them on time, even they could take few weeks to ship from
manufacturer and this will cause delay to your project.

Department Of Computer Applications

Indo-American College, Cheyyar 12
 Software Engineering

Project Scheduling

A schedule in your project’s time table actually consists of sequenced activities and
milestones that are needed to be delivered under a given period of time.

Project schedule simply means a mechanism that is used to communicate and know about that
tasks are needed and has to be done or performed and which organizational resources will be
given or allocated to these tasks and in what time duration or time frame work is needed to be
performed. Effective project scheduling leads to success of project, reduced cost, and increased
customer satisfaction. Scheduling in project management means to list out activities,
deliverables, and milestones within a project that are delivered. It contains more notes than your
average weekly planner notes. The most common and important form of project schedule is
Gantt chart.

Process :
The manager needs to estimate time and resources of project while scheduling project. All
activities in project must be arranged in a coherent sequence that means activities should be
arranged in a logical and well-organized manner for easy to understand. Initial estimates of
project can be made optimistically which means estimates can be made when all favorable things
will happen and no threats or problems take place.
The total work is separated or divided into various small activities or tasks during project
schedule. Then, Project manager will decide time required for each activity or task to get
completed. Even some activities are conducted and performed in parallel for efficient

Department Of Computer Applications

Indo-American College, Cheyyar 13
 Software Engineering

performance. The project manager should be aware of fact that each stage of project is not
problem-free.

Problems arise during Project Development Stage :

 People may leave or remain absent during particular stage of development.
 Hardware may get failed while performing.
 Software resource that is required may not be available at present, etc.
The project schedule is represented as set of chart in which work-breakdown structure and
dependencies within various activities are represented. To accomplish and complete project
within a given schedule, required resources must be available when they are needed. Therefore,
resource estimation should be done before starting development.

Resources required for Development of Project :

 Human effort
 Sufficient disk space on server
 Specialized hardware
 Software technology
 Travel allowance required by project staff, etc.
Advantages of Project Scheduling :
There are several advantages provided by project schedule in our project management:
 It simply ensures that everyone remains on same page as far as tasks get completed,
dependencies, and deadlines.
 It helps in identifying issues early and concerns such as lack or unavailability of resources.
 It also helps to identify relationships and to monitor process.
 It provides effective budget management and risk mitigation.

Software Engineering | Software Quality Assurance

Software Quality Assurance (SQA) is simply a way to assure quality in the software. It
is the set of activities which ensure processes, procedures as well as standards suitable for the
project and implemented correctly.

Department Of Computer Applications

Indo-American College, Cheyyar 14
 Software Engineering

Software Quality Assurance is a process which works parallel to development of a software. It

focuses on improving the process of development of software so that problems can be prevented
before they become a major issue. Software Quality Assurance is a kind of an Umbrella activity
that is applied throughout the software process.

Software Quality Assurance have:

1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism
Major Software Quality Assurance Activities:
1. SQA Management Plan:
Make a plan how you will carry out the sqa through out the project. Think which set of
software engineering activities are the best for [Link] level of sqa team skills.
2. Set The Check Points:
SQA team should set checkpoints. Evaluate the performance of the project on the basis of
collected data on different check points.
3. Multi testing Strategy:
Do not depend on single testing approach. When you have lot of testing approaches
available use them.
4. Measure Change Impact:
The changes for making the correction of an error sometimes re introduces more errors
keep the measure of impact of change on project. Reset the new change to change check
the compatibility of this fix with whole project.
5. Manage Good Relations:
In the working environment managing the good relation with other teams involved in the
project development is mandatory. Bad relation of sqa team with programmers team will
impact directly and badly on project. Don’t play politics.
Benefits of Software Quality Assurance (SQA):
1. SQA produce high quality software.

Department Of Computer Applications

Indo-American College, Cheyyar 15
 Software Engineering

2. High quality application saves time and cost.

3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for long time.
5. High quality commercial software increase market share of company.
6. Improving the process of creating software.
7. Improves the quality of the software.
Disadvantage of SQA:
There are a number of disadvantages of quality assurance. Some of them include adding more
resources, employing more workers to help maintain quality and so much more.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for
SDE interviews with the CS Theory Course at a student-friendly price and become industry
ready.

Formal Technical Reviews

 Formal Technical review is a software quality assurance activity performed by software

engineer.

Objectives of FTR

1. FTR is useful to uncover error in logic, function and implementation for any
representation of the software.
2. The purpose of FTR is to ensure that software meets specified requirements.
3. It is also ensure that software is represented according to predefined standards.
4. It helps to review the uniformity in software development process.
5. It makes the project more manageable.

 Besides the above mentioned objectives, the purpose of FTR is to enable junior engineer
to observer the analysis, design, coding and testing approach more closely.

 Each FTR is conducted as meeting and is considered successfully only if it is properly

planned, controlled and attended.

Department Of Computer Applications

Indo-American College, Cheyyar 16
 Software Engineering

Steps in FTR

1. The review meeting

 Every review meeting should be conducted by considering the following constraints-

1. Involvement of people

Between 3 and 5 people should be involve in the review.

2. Advance preparation Advance preparation should occur but it should be very short that is
at the most 2 hours of work for each person can be spent in this preparation

3. Short duration The short duration of the review meeting should be less than two hour.

 Rather than attempting to review the entire design walkthrough are conducted for
modules or for small group of modules.
 The focus of the FTR is on work product (a software component to be reviewed). The
review meeting is attended by the review leader, all reviewers and the producer.
 The review leader is responsible for evaluating for product for its deadlines. The copies
of product material is then distributed to reviewers. -The producer organises
“walkthrough” the product, explaining the material, while the reviewers raise the issues
based on theirs advance preparation.
 One of the reviewers become recorder who records all the important issues raised during
the review. When error are discovered, the recorder notes each.
 At the end of the review, the attendees decide whether to accept the product or not, with
or without modification.

2. Review reporting and record keeping

 During the FTR, the reviewer actively record all the issues that have been raised.
 At the end of meeting these all raised issues are consolidated and review issue list is
prepared.
 Finally, formal technical review summary report is produced.

Department Of Computer Applications

Indo-American College, Cheyyar 17
 Software Engineering

3. Review guidelines

 Guidelines for the conducting of formal technical review must be established in advance.
These guidelines must be distributed to all reviewers, agreed upon, and then followed.
 For example,

Guideline for review may include following things

1. Concentrate on work product only. That means review the product not the producers.
2. Set an agenda of a review and maintain it.
3. When certain issues are raised then debate or arguments should be limited. Reviews
should not ultimately results in some hard feelings.
4. Find out problem areas, but don’t attempt to solve every problem noted.
5. Take written notes (it is for record purpose)
6. Limit the number of participants and insists upon advance preparation.
7. Develop a checklist for each product that is likely to be reviewed.
8. Allocate resources and time schedule for FTRs in order to maintain time schedule.
9. Conduct meaningful trainings for all reviewers in order to make reviews effective.
10. Reviews earlier reviews which serve as the base for the current review being conducted.

REFERENCES:
TEXT BOOK: Roger S Pressman, “Software Engineering - A Practitioner’s Approach”, Sixth
Edition, McGraw Hill International Edition, New York: 2005.
[Link]
[Link] [Link]
[Link]

Department Of Computer Applications

Indo-American College, Cheyyar 18