DR.D.Y.

PATILINSTITUTEOFTECHNOLOGYPIMPRI,PUNU-18
DEPARTMENT OF COMPUTER ENGINEERING

Department of Computer Engineering

QUESTION BANK

Class:S.E. (Comp.)

Subject: Software Engg

UNIT 1
Q.1 What are the various umbrella activities applied throughout a software project?

Umbrella Activities:

In addition to the framework activities, the process model defines a set of umbrella activities that
persist across the entire software process. These umbrella activities include:

Software project tracking and control:

When plan, tasks, models all have been done then a network of software engineering tasks that will
enable to get the job done on time will have to be created.

Formal technical reviews: This includes reviewing the techniques that has been used in the project.

Software quality assurance: This is very important to ensure the quality measurement of each part to
ensure them.
Software configuration management: Software configuration management (SCM) is a set of activities
designed to control change by identifying the work products that are likely to change, establishing
relationships among them, defining mechanisms for managing different versions of these work
products.

Document preparation and production: All the project planning and other activities should be hardly
copied and the production get started here.

Re-usability management: This includes the backing up of each part of the software project they can
be corrected or any kind of support can be given to them later to update or upgrade the software at
user/time demand.

Measurement & Metrics: This will include all the measurement of every aspects of the software
project.

Risk management: Risk management is a series of steps that help a software team to understand and
manage uncertainty. It’s a really good idea to identify it, assess its probability of occurrence, estimate
its impact, and establish a contingency plan that─ ‘should the problem actually occur’.

Each of these umbrella activities is defined by a set of tasks that are adapted to the project type and
degree of rigor with which software engineering is to be applied.

Q.2 What are the elements of waterfall process model? State its merit & demerits
The waterfall model is a sequential (non-iterative) design process, used in software development
processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the
phases of conception, initiation, analysis, design, construction, testing, production/implementation and
maintenance.
The waterfall development model originates in the manufacturing and construction industries: highly
structured physical environments in which after-the-fact changes are prohibitively costly, if not
impossible. Because it was created in a time when no formal software development methodologies
existed, this hardware-oriented model was simply adapted for software development.

Q. 3 Compare process between Agile and Evolutionary model

Evolutionary models are iterative. They are characterized in a manner that enables software engineers
to develop increasingly more complete versions of the software.
The Incremental Model
The incremental model combines elements of the linear sequential model (applied repetitively) with
the iterative philosophy of prototyping. , the incremental model applies linear sequences in a staggered
fashion as calendar time
progresses.
The Spiral Model
The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software process model
that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear
sequential model. It provides the potential for rapid development of incremental versions of the
software. Using the spiral model, soft-ware is developed in a series of incremental releases. During
early iterations, the incremental release might be a paper model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.
The word ‘agile’ means −
Able to move your body quickly and easily.
Able to think quickly and clearly.
In business, ‘agile’ is used for describing ways of planning and doing work wherein it is understood
that making changes as needed is an important part of the job. Business‘agililty’ means that a company
is always in a position to take account of the market changes.

characteristics of Agility
Following are the characteristics of Agility −
 Agility in Agile Software Development focuses on the culture of the whole team with multi-
discipline, cross-functional teams that are empowered and selforganizing.
It fosters shared responsibility and accountability.
Facilitates effective communication and continuous collaboration.
The whole-team approach avoids delays and wait times.
Frequent and continuous deliveries ensure quick feedback that in in turn enable the team align
to the requirements.
Collaboration facilitates combining different perspectives timely in implementation, defect
fixes and accommodating changes.
Progress is constant, sustainable, and predictable emphasizing transparency.

Q. 4 What is extreme programming? Explain the Extreme programming process

Software Engineering involves −
Creativity
Learning and improving through trials and errors
Iterations
Extreme Programming builds on these activities and coding. It is the detailed (not the only) design
activity with multiple tight feedback loops through effective implementation, testing and refactoring
continuously.
Extreme Programming is based on the following values −
Communication
Simplicity
Feedback
Courage
Respect

What is Extreme Programming?

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop a
software.
eXtreme Programming (XP) was conceived and developed to address the specific needs of software
development by small teams in the face of vague and changing requirements.
Extreme Programming is one of the Agile software development methodologies. It provides values
and principles to guide the team behavior. The team is expected to self-organize. Extreme
Programming provides specific core practices where −
Each practice is simple and self-complete.
Combination of practices produces more complex and emergent behavior.

Embrace Change
A key assumption of Extreme Programming is that the cost of changing a program can be held mostly
constant over time.
This can be achieved with −
 Emphasis on continuous feedback from the customer
Short iterations
Design and redesign
Coding and testing frequently
Eliminating defects early, thus reducing costs
Keeping the customer involved throughout the development
Delivering working product to the customer

Extreme Programming in a Nutshell

Extreme Programming involves −
Writing unit tests before programming and keeping all of the tests running at all times. The unit
tests are automated and eliminates defects early, thus reducing the costs.
Starting with a simple design just enough to code the features at hand and redesigning when
required.
Programming in pairs (called pair programming), with two programmers at one screen, taking
turns to use the keyboard. While one of them is at the keyboard, the other constantly reviews
and provides inputs.
Integrating and testing the whole system several times a day.
Putting a minimal working system into the production quickly and upgrading it whenever
required.
Keeping the customer involved all the time and obtaining constant feedback.
Iterating facilitates the accommodating changes as the software evolves with the changing
requirements.

Q5) Explain Software Engineering

Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to
software. (2) The study of approaches as in (1).

Q6)Justify “Software engineering is a layered technology” OR Explain Software process layer

architecture
Referring to Figure any engineering approach (including software engineering) must rest on an
organizational commitment to quality. Total quality management, Six Sigma, and similar philosophies
foster a continuous process improvement culture, and it is this culture that ultimately leads to the
development of increasingly more effective approaches to software engineering. The bedrock that
supports software engineering is a quality focus.The foundation for software engineering is the process
layer. The software engineering process is the glue that holds the technology layers together and
enables rational and timely development of computer software. Process defines a framework that must
be established for effective delivery of software engineering technology. The software process forms
the basis for management control of software projects and establishes the context in which technical
methods are applied, work products (models, documents, data, reports, forms, etc.) are produced,
milestones are established, quality is ensured, and change is properly managed. Software engineering
methods provide the technical how-to’s for building software. Methods encompass a broad array of
tasks that include communication, requirements
analysis, design modeling, program construction, testing, and support. Software engineering methods
rely on a set of basic principles that govern each area of the technology and include modeling activities
and other descriptive techniques.

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

Q7) Explain V-V Model

A variation in the representation of the waterfall model is called the V-model. Represented in Figure
2.4, the V -model [Buc99] depicts the relationship of quality assurance actions to the actions associated
with communication, modeling, and early construction activities. As a software team moves down the
left side of the Vbasic problem requirements are refined into progressively more detailed and technical
representations of the problem and its solution. Once code has been generated, the team moves up the
right side of the V, essentially performing a series of tests (quality assurance actions) that validate each
of the models created as the team moved down the left side.

In reality, there is no fundamental difference between the classic life cycle and the V-model. The V-
model provides a way of visualizing how verification and validation actions are applied to earlier
engineering work.
Q7) Explain how incremental model of software works
There are many situations in which initial software requirements are reasonably well defined, but the
overall scope of the development effort precludes a purely linear process. In addition, there may be a
compelling need to provide a limited set of software functionality to users quickly and then refine and
expand on that functionality in

later software releases. In such cases, you can choose a process model that is designed to produce the
software in increments.

The incremental model combines elements of linear and parallel process flows discussed in Section
2.1. Referring to Figure , the incremental model applies linear sequences in a staggered fashion as
calendar time progresses. Each linear sequence produces deliverable “increments” of the software
[McD93] in a manner that is similar to the increments produced by an evolutionary process flow
(Section 2.3.3).
For example, word-processing software developed using the incremental paradigm might deliver basic
file management, editing, and document production functions in the first increment; more sophisticated
editing and document production

capabilities in the second increment; spelling and grammar checking in the third increment; and
advanced page layout capability in the fourth increment. It should be

noted that the process flow for any increment can incorporate the prototyping paradigm.

When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features (some

known, others unknown) remain undelivered. The core product is used by the customer (or undergoes
detailed evaluation). As a result of use and/or evaluation, a

plan is developed for the next increment. The plan addresses the modification of the core product to
better meet the needs of the customer and the delivery of additional features and functionality. This
process is repeated following the delivery of each incremental process model focuses on the delivery
of an operational product with each increment. Early increments are stripped-down versions of the
final product, but they do provide capability that serves the user and also provide a platform for
evaluation by the user.

Incremental development is particularly useful when staffing is unavailable for a complete

implementation by the business deadline that has been established for the project. Early increments
can be implemented with fewer people. If the core product is well received, then additional staff (if
required) can be added to implement the next increment. In addition, increments can be planned to
manage technical risks. For example, a major system might require the availability of new hardware
that is under development and whose delivery date is uncertain. It might be possible to plan early
increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be
delivered to end users without inordinate delay.

Q8) Explain Prototyping model

The prototyping paradigm begins with communication. You meet with other stakeholders to define
the overall objectives for the software, identify whatever requirements are known, and outline areas
where further definition is mandatory. A prototyping iteration is planned quickly, and modeling (in the
form of a “quick design”) occurs. A quick design focuses on a representation of those aspects of the
software that will be visible to end users (e.g., human interface layout or output display

Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual
system, and developers get to build something immediately. et, prototyping can be problematic for the
following reasons:

Stakeholders see what appears to be a working version of the software, unaware that the prototype is
held together haphazardly, unaware that in the rush to get it working you haven’t considered overall
software quality or long-term maintainability. When informed that the product must be rebuilt so that
high levels of quality can be maintained, stakeholders cry foul and demand that “a few fixes” be applied
to make the prototype a working product. Too often, software development management relents. As a
software engineer, you often make implementation compromises in order to get a prototype working
quickly. An inappropriate operating system or programming language may be used simply because it
is available and known; an inefficient algorithm may be implemented simply to demonstrate capability.
After a time, you may become comfortable with these choices and forget all the reasons why they were
inappropriate. The less-than-ideal choice has now become an integral part of the system.

Q8) Explain Spiral model with example

The Spiral Model. Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary
software process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model. It provides the potential for rapid development of
increasingly more complete versions of the software. Boehm [Boe01a] describes the model in the
following manner:

The spiral development model is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems. It has two main distinguishing
features. One is a cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk. The other is a set of anchor point milestones for
ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.

Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a model or prototype. During later iterations, increasingly more
complete versions of the engineered system are produced.

A spiral model is divided into a set of framework activities defined by the software engineering team.
For illustrative purposes, I use the generic framework activities

Each of the framework activities represent one segment of the spiral path illustrated in Figure 2.7. As
this evolutionary process begins, the software team performs activities that are implied by a circuit
around the spiral in a clockwise direction beginning at the center.

Risk is considered as each revolution is made. Anchor point milestones—a combination of work
products and conditions that are attained along the path of the spiral—are noted for each evolutionary
pass.

The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then progressively more
sophisticated versions of the software. Each pass through the planning region results in adjustments
to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after
delivery. In addition, the project manager adjusts the planned number of iterations required To
complete the software.

Q9) Explain concurrent development model

The concurrent development model, sometimes called concurrent engineering, allows a software team
to represent iterative and concurrent elements of any of the process models described in this chapter.
For example, the modeling activity defined for the spiral model is accomplished by invoking one or
more of the following software engineering actions: prototyping, analysis, and design.

Figure provides a schematic representation of one software engineering activity within the modeling
activity using a concurrent modeling approach. The activity—modeling—may be in any one of the
states noted at any given time. Similarly,

other activities, actions, or tasks (e.g., communication or construction) can be represented in an

analogous manner. All software engineering activities exist concurrently but reside in different states.
For example, early in a project the communication activity (not shown in the figure) has completed its
first iteration and exists in the awaiting changes state. The modeling activity (which existed in the
inactive state while initial communication was completed, now makes a transition into the under
development state. If, however, the

customer indicates that changes in requirements must be made, the modeling activity moves from the
under development state into the awaiting changes state. Concurrent modeling defines a series of
events that will trigger transitions from state to state for each of the software engineering activities,
actions, or tasks. For example, during early stages of design (a major software engineering action that
occurs during the modeling activity), an inconsistency in the requirements model is uncovered. This
generates the event analysis model correction, which will trigger the requirements analysis action from
the done state into the awaiting changes state. Concurrent modeling is applicable to all types of
software development and provides an accurate picture of the current state of a project. Rather than
confining software engineering activities, actions, and tasks to a sequence of events, it defines a
process network. Each activity, action, or task on the network exists simultaneously with other
activities, actions, or tasks. Events generated at one point in the process network trigger transitions
among the states.

Q10) Define Software Engineering

Software Engineering is the establishment and the use of sound engineering principle

in order to obtain a reliable and efficient software.

OR

Software engineering is a discipline in which theories, methods and tools are applied

to develop professional software product.

OR

Systematic, disciplined, quantifiable approach to the development, opertions

Q11) What are the layers present in layered Technology

∑ Tools

∑ Methods
∑ Process

∑ A Quality Focus

Q12) What are the various categories of software?

System software

Application software

Embedded software

Engineering/ Scientific software

Artificial Intelligence software.

Q13)What are the activities in Process frame work?

Process framework activities are,

̧ Communication: Collaboration with customer , gathering information

̧ Planning: establish a work plan, describe technical risks, list resource,

work products etc

̧ Modeling: creation of models, and design

̧ Construction: code generation and testing

̧ Deployment: delivered to the customer ,evaluate, and provides a feedback

Q14) What is the difference between verification and validation?

Validation

Verification

1. Are we building the product right? 1. Are we building the right product?

2. Verification shows conformance 2. Validation shows that the program

with specification.

meets the customer’s needs.

Q15) Define software life cycle and types of lifecycle model.

Software life cycle is the period of time beginning with a concept for a software

product and ending whenever the software is no longer available for use.
1. Prescriptive process model

2. Water fall model

3. Incremental process Model

1. Incremental Model

2. RAD Model

4. Evolutionary process Model

1. Prototyping model

2. Spiral Model

3. The concurrent development Model

5. Specialized Process Model

1. Component based development Model

2. Formal Methods Model

3. Aspect oriented S/W development (AOSD)

6. Unified process model

Q16) Drawbacks of waterfall model

∑ Oldest model. Rarely follows the sequential flow.

∑ Difficult to collect requirement explicitly at the beginning.

∑ A working version not available in later releases.

∑ It leads a blocking state.

Q17) What are the phases encompassed in RAD model?

a. Business modeling

b. Data modeling

c. Process modeling

d. Application generation

e. Testing

Q18) What are the advantages of prototyping model?

∑Prototyping model is used when a customer defines a set of objectives for software

but doesn’t identify detailed input, processing and output requirements.

∑ It serves as the mechanism for identifying software requirements.

∑ If the prototype is built the developer attempts to use existing program fragments to

develop a working program.

Q19) which type of application would suit RAD model? Suitability of RAD

The following criteria can be evaluated to determine whether the development would suit a RAD style:

Project Scope: If the scope is focused and the business objectives are well defined and narrow, then
the project is suitable for RAD. Conversely if the scope of the business objectives is obscure or broad
then the project is unsuitable for RAD. Project Data: Data for the project already exists (completely or
in part). The project largely comprises analysis or reporting of the data then the project is suitable for
RAD. However, if the Data is complex and voluminous and therefore must be analysed, designed and
created within the scope of the project, then the project is unsuitable for RAD. Project Decisions: If
project or development decisions can be made by a small

number of people who are available and, preferably co-located, then it is suitable for RAD. If many
people must be involved in the decisions on the project, the decision makers are not available on a
timely basis or they are geographically dispersed, then the project is unsuitable for RAD. Project Team:
If the project team is small (preferably six people or fewer) then it is suitable for RAD; but if the
project team is large or there are multiple teams whose work needs to be coordinated, then it is
unsuitable for RAD. Project Technical Architecture: When the technical architecture is defined and
clear and the key technology components are in place and tested, the architecture is suitable for RAD.
Therefore if the technical architecture is unclear and much of the technology will be used for the first
time within the project, then it is unsuitable for RAD.

Project Technical Requirements: If the project technical requirements (response times, throughput,
database sizes, etc) are reasonable and well within the capabilities of the technology being used, then
the project is suitable for RAD. In fact targeted performance should be less than 70% of the published
limits of the technologies. However if the project technical requirements are tight for the equipment to
be used, then the project is unsuitable for RAD

Q20) what is meant by rapid prototyping? Explain how do you incorporate such a scheme in the
software project management?

Rapid Prototyping (RP) can be defined as a group of techniques used to quickly fabricate a scale model
of a part or assembly using three-dimensional computer aided design (CAD) data. Rapid Prototyping
has also been referred to as solid free-form manufacturing, computer automated manufacturing, and
layered manufacturing. RP has obvious use as a vehicle for visualization. In addition, RP models can
be used for testing, such as when an airfoil shape is put into a wind tunnel. RP models can be used to
create male models for tooling, such as silicone rubber molds and investment casts. In some cases, the
RP part can be the final part, but typically the RP material is not strong or accurate enough. When the
RP material is suitable, highly convoluted shapes (including parts nested within parts) can be produced
because of the nature of RP.

UNIT 2 :
Q21) Explain different tasks are to be carried out in Software Requirement Engineering [3]

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.
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.

Q.22 Distinguish functional and nonfunctional requirement

Functional requirements

Functional requirements specifies a function that a system or system component must be able
to perform. It can be documented in various ways. The most common ones are written
descriptions in documents, and use cases.
Use cases can be textual enumeration lists as well as diagrams, describing user actions. Each
use case illustrates behavioural scenarios through one or more functional requirements. Often,
though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive
the functional requirements that must be implemented to allow a user to perform each use case.
Functional requirements is what a system is supposed to accomplish. It may be
Calculations
Technical details
Data manipulation
Data processing
Other specific functionality
A typical functional requirement will contain a unique name and number, a brief summary, and
a rationale. This information is used to help the reader understand why the requirement is
needed, and to track the requirement through the development of the system.
Non-functional requirements

Non-functional requirements are any other requirement than functional requirements. This are
the requirements that specifies criteria that can be used to judge the operation of a system,
rather than specific behaviours.
Non-functional requirements are in the form of "system shall be ", an overall property of the
system as a whole or of a particular aspect and not a specific function. The system's overall
properties commonly mark the difference between whether the development project has
succeeded or failed.
 Non-functional requirements - can be divided into two main categories:
Execution qualities, such as security and usability, which are observable at run time.
Evolution qualities, such as testability, maintainability, extensibility and scalability,
which are embodied in the static structure of the software system.
Non-functional requirements place restrictions on the product being developed, the
development process, and specify external constraints that the product must meet.
The IEEE-Std 830 - 1993 lists 13 non-functional requirements to be included in a Software
Requirements Document.

1. Performance requirements
2. Interface requirements
3. Operational requirements
4. Resource requirements
5. Verification requirements
6. Acceptance requirements
7. Documentation requirements
8. Security requirements
9. Portability requirements
10. Quality requirements
11. Reliability requirements
12. Maintainability requirements
13. Safety requirements

Whether or not a requirement is expressed as a functional or a non-functional requirement may depend:

on the level of detail to be included in the requirements document
the degree of trust which exists be The IEEE-Std 830 - 1993 lists 13 non-functional
requirements to be included in a Software Requirements Document. tween a system customer
and a system developer.

Q.23) Explain four desirable characteristics of good software requirement specification document

Good requirements should have the following characteristics:

Unambiguous
Testable (verifiable)
Clear (concise, terse, simple, precise)
Correct
Understandable
Feasible (realistic, possible)
Independent
Atomic
Necessary
Implementation-free (abstract)
Besides these criteria for individual requirements, three criteria apply to the set of requirements. The
set should be
 Consistent
Nonredundant
Complete
[2]

Q.24) Distinguish requirement negotiation and validation? States its technique [3]

Purpose of Requirements Validation

Reviewing requirements in order to discover errors or quality problems

Early assurance that (documented) requirements:

represent the actual needs and expectations of the stakeholders

have the necessary level of quality

can be approved for further development activities

Design, implementation, test, ...

Especially important in client–contractor relationships

Essential Validation Principles

1.Involvement of correct stakeholders

2.Separation of the identification and correction of errors
3.Validation from different views
4.Adequate change of document type
5.Construction of development artifacts
6.Repeated validation

Techniques:

Core techniques (review techniques)

Commenting

Inspections

Walkthroughs

Supporting techniques

Perspective-based reading

Prototyping
 Validation checklists

Each technique requires upfront preparation (e.g., identification and

involvement of correct stakeholders)

Purpose of Requirements Negotiation

Unresolved conflicts reduce system acceptance

E.g., when only one of the contradictory requirements is implemented,
the other party is demotivated
Overall goal of negotiation
Gain a common and agreed-upon understanding of the requirements
among all stakeholders
Resolving contradictory requirements of different stakeholders
“Shut down in case of failure” vs. “Restart in case of failure”
Negotiation needs to be done throughout the entire requirements
engineering process (not as a single step at the end!)
Performing Requirements Negotiation

Negotiation requires systematic conflict management, which includes:

conflict identification
conflict analysis
conflict resolution
documentation of the resolution
Q.25) What is requirement engineering? State its process and explain requirement elicitation problem.

Requirement Engineering

It is a four step process, which includes –

Feasibility Study

Requirement Gathering

Software Requirement Specification

Software Requirement Validation

Let us see the process briefly -

Feasibility study

When the client approaches the organization for getting the desired product developed, it comes up

with rough idea about what all functions the software must perform and which all features are expected

from the software. Referencing to this information, the analysts does a detailed study about

whether the desired system and its functionality are feasible to develop. This feasibility study is

focused towards goal of the organization. This study analyzes whether the software product can be
practically materialized in terms of implementation, contribution of project to organization, cost

constraints and as per values and objectives of the organization. It explores technical aspects of the

project and product such as usability, maintainability, productivity and integration ability. The output

of this phase should be a feasibility study report that should contain adequate comments and

recommendations for management about whether or not the project should be undertaken.

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with gathering

requirements from the user. Analysts and engineers communicate with the client and end-users to know

their ideas on what the software should provide and which features they want the software to include.

Q26) Explain Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from various

stakeholders. SRS defines how the intended software will interact with hardware, externa linterfaces,

speed of operation, response time of system, portability of software across various platforms,

maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from client are written in natural language. It is the responsibility of system

analyst to document the requirements in technical language so that they can be comprehended and

useful by the software development team. SRS should come up with following features:

User Requirements are expressed in natural language.

Technical requirements are expressed in structured language, which is used inside the organization.

Design description should be written in Pseudo code.

Format of Forms and GUI screen prints.

Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are

validated. User might ask for illegal, impractical solution or experts may interpret the requirements

incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked

against following conditions -

If they can be practically implemented

If they are valid and as per functionality and domain of software

If there are any ambiguities

If they are complete

If they can be demonstrated

Q27) Explain requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

Requirements gathering - The developers discuss with the client and end users and know their
expectations from the software.
Organizing Requirements - The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.
Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and conflicts, they
are discussed for clarity and correctness. Unrealistic requirements are compromised
reasonably.
Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.

Q28) Write down requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software system
by communicating with client, end users, system users and others who have a stake in the software
system development.
There are various ways to discover requirements

Interviews
Interviews are strong medium to collect requirements. Organization may conduct several types of
interviews such as:
Structured (closed) interviews, where every single information to gather is decided in advance,
they follow pattern and matter of discussion firmly.
Non-structured (open) interviews, where information to gather is not decided in advance, more
flexible and less biased.
Oral interviews
Written interviews
 One-to-one interviews which are held between two persons across the table.
Group interviews which are held between groups of participants. They help to uncover any
missing requirement as numerous people are involved.

Surveys
Organization may conduct surveys among various stakeholders by querying about their expectation
and requirements from the upcoming system.

Questionnaires
A document with pre-defined set of objective questions and respective options is handed over to all
stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire,
the issue might be left unattended.

Task analysis
Team of engineers and developers may analyze the operation for which the new system is required. If
the client already has some software to perform certain operation, it is studied and requirements of
proposed system are collected.

Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a great help
to analyze general and specific requirements.

Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for further
requirements analysis.

Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no software
installed at client’s end for developer’s reference and the client is not aware of its own requirements,
the developer creates a prototype based on initially mentioned requirements. The prototype is shown
to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.

Observation
Team of experts visit the client’s organization or workplace. They observe the actual working of the
existing installed systems. They observe the workflow at client’s end and how execution problems are
dealt. The team itself draws some conclusions which aid to form requirements expected from the
software.

Q29) List down Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence
they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
Clear
 Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Credible source

UNIT III SOFTWARE DESIGN

Q30 )What are the elements of design model?

i. Data design
ii. Architectural design
iii. Interface design
iv. Component level design

Q32). Define design process.

Design process is a sequence of steps carried through which
the requirements are translated into a system or software model.

Q33). List the principles of a software design.

i. The design process should not suffer from “tunnel vision”
ii. The design should be traceable to the analysis model.
iii. The design should exhibit uniformity and integration.
iv. Design is not coding.
v. The design should not reinvent the wheel.

Q34 ) What is the benefit of modular design?

Changes made during testing and maintenance becomes manageable and they do not affect other
modules.

Q35) What is a cohesive module?

A cohesive module performs only “one task” in software procedure with little interaction with other
modules. In other words cohesive module performs only one thing.

Q36) . What are the different types of Cohesion?

i. Coincidentally cohesive - The modules in which the set I of tasks are related with each other
loosely.
ii. Logically cohesive –A module that performs the tasks that are logically related with each other
iii. Temporal cohesion –The module in which the tasks need to be executed in some specific time
span
iv. Procedural cohesion When processing elements of a module are related with one another and
must be executed in some specific order
v. Communicational cohesion – When the processing elements of a module share the data then
such module is called communicational cohesive.

Q37.) What is coupling

Coupling is the measure of interconnection among modules in a program structure . It depends on
the interface complexity between modules.

Q38 ) What are the various types of coupling?

i. Data coupling –The data coupling is possible by parameter passing or data interaction.
ii. Control coupling - The modules share related control data in control coupling.

Q39)What is an architectural style?

Architectural style describes system category that encompasses

∑ a set of components that performs a function required by a system.

∑ Set of connectors that enable communication, coordination among components

∑ How components can be integrated to form the system

∑ Semantic models enable a designer to understand the overall properties of a

system.

Q40)List the principles of a software design.

i. The design process should not suffer from “tunnel vision”.

ii. The design should be traceable to the analysis model.

iii. The design should exhibit uniformity and integration.

iv. Design is not coding.

v. The design should not reinvent the wheel.

Q41) What are the various models produced by software design process?

*Data design

*Architectural design

*Interface design

* Component level design.

Q42) What are the quality parameters considered for effective modular design?

Two quality parameters are Coupling and Cohesion.

Coupling is defined as a interdependency between the modules.

Cohesion is defined as a individual strength of a module

Q43) What are types of architectural styles?

i. Data centered architecture.

ii. Data flow architecture.

iii. Call and return architecture.

iv. Object-oriented architecture.

v. Layered architecture

Q44) Explain in detail about data modeling

Data modeling makes use of the Entity Relationship Diagram.

∑ Data Objects, Attributes and Relationships

Data object – representation of something that has a number of different properties or

attributes,Example

Attributes - name a data object, describe its characteristics, make reference to another object.

Relationships – Indicate the manner in which data objects are connected to one another. Example

diagram

Q45) Define Cardinality and Modality

∑ Cardinality and Modality Cardinality is the specification of the number of occurrences of one object

that can be related to the number of occurrences of another object.

o One-to-one cardinality.

o One-to-many cardinality.

o Many-to-Many cardinality.

Modality of a relation is 0 if there is no explicit relationship or relation is optional.Modality is 1 if an

occurrence of relationship is mandatory.

∑ Entity/Relationship Diagrams

Components of ER Diagram

ER diagram for manufacturer and relationship

Q46) Explain in detail the design concepts.

∑ Abstraction

ß Functional or Procedural abstraction

ß Data abstraction

ß Control abstraction

∑ Refinement

∑ Modularity

ß 5 criteria to define a effective modular system

ß Modular decomposability

ß Modular composability

ß Modular Understandability

ß Modular Continuity

ß Modular protection

∑ Software Architecture

∑ Control Hierarchy

∑ Structural Partitioning

ß Horizontal partitioning
ß Vertical partitioning

∑ Data Structure

∑ Software Procedure

∑ Information Hiding

Q47) What are the various elements of data design?

i. Data object – The data objects are identified and relationship among various data objects
can be represented using ERD or data dictionaries.
ii. Databases – Using software design model, the data models are translated into data
structures and data bases at the application level.
Iii. Data warehouses – At the business level useful information I s identified from various
databases and the data warehouses are created.

Q48) Explain the design principles.

∑ The design process should not suffer from tunnel vision.

∑ The design should be traceable to the analysis model.

∑ Design should not reinvent the wheel.

∑ The design should minimize the intellectual distance between the software and problem as it exists

in the real world.

∑ The design should be structured to degrade gently, even when aberrant data, events or operating

conditions are encountered.

∑ Design is not coding, coding is not design.

∑ The design should be assessed for quality as it is being created, not after the fact.

∑ The design should be reviewed to minimize conceptual (semantic) errors

Q49). Explain User interface design process

∑ Diagram

∑ Frame work activities for User inte rface design process

1.User,task,environment analysis and modeling

2.Interface design

3.Interface construction

4.Interface validation

Q50) What are the objectives of Analysis modeling?

i. To describe what the customer requires.

ii. To establish a basis for the creation of software design.
iii. To devise a set of valid requirements after which the software can be built.

Q51) What is an Architectural design?

The architectural design defines the relationship between major structural elements of the software,
the “design patterns” that can be used to achieve the requirements that have been defined for the
system.

Q52). What is data design?

The data design transforms the information domain model created during analysis into the data
structures that will be required to implement the software.

Q53) What is interface design?

The interface design describes how the software communicates within itself, with systems that
interoperate with it, and with humans who use it.

Q54). What is component level design?

The component level design transforms structural elements of the software architecture into a
procedural description of software components.

Q55). What is software design?

Software design is an iterative process through which the requirements are translated into a
“blueprint” for constructing the software.

Q56) What is user interface design?

User interface design creates an effective communication medium between a human and a
computer.
25. What is system design?
System design process involves deciding which system capabilities are to be implemented in
software and which in hardware

Q57) Explain design process

Design process is a sequence of steps carried through which the requirement are translated into a
system or software model

Design products In architectural design the subsystem components can be identified.

The abstract specification is used to specify the subsystems.

The interfaces between the subsystems are designed, which is called interface design.

In component design of subsystems components is done ..

The data structure is designed to hold the data

For performing the required functionality, the appropriate algorithm is designed.

UNIT 4:

Q58) Define measure.

Measure is defined as a quantitative indication of the extent, amount, dimension, or size of

some attribute of a product or process.

Q59) . Define metrics.

Metrics is defined as the degree to which a system component,or process possesses a given
attribute.

Q60) What are the types of metrics?

Direct metrics – It refers to immediately measurable attributes.

Example –Lines of code, execution speed.

Indirect metrics –It refers to the aspects that are not immediately quantifiable or measurable.
Example –functionality of a program.

Q61) . Write short note on the various estimation techniques.

Algorithmic cost modeling –the cost estimation is based on the size of the software.
Expert judgment –The experts from software development and the application domain .Estimation
by analogy
–The cost of a project is computed by comparing the project to a similar project in the same
application domain

Parkinson‟s Law –
The cost is determined by available resources rather than by objective assessment. Pricing to win –
The project costs whatever the customer ready to spend it.
Q62). What is COCOMO model?
COnstructive COst MOdel is a cost model, which gives the estimate of number of man-months it
will take to develop the software product.

Q63) Give the procedure of the Delphi method.

1. The co-coordinator presents a specification and estimation form to each expert.
2. Co- coordinator calls a group meeting in which the experts discuss estimation issues with the
coordinator and each other.
3. Experts fill out forms anonymously.
4. Co-coordinator prepares and distributes a summary of the estimates.
5. The Co-coordinator then calls a group meeting.
Q64) What is the purpose of timeline chart?
The purpose of the time line chart is to emphasize the scope of the individual task. Hence set of
tasks are given as input to the timeline chart. That is meant by Software project management?
Software project management is an activity of organizing, planning and scheduling software
projects.

Q65) What is meant by software measurement?

Software measurement means deriving a numeric value for an attribute of a software product or
process.

Q66) What is meant by software cost estimation?

The software cost estimation is the process of predicting the resources required for software
development process.

Q67)What is meant by CASE tools?

The computer aided software engineering tools automatic the project management activities,
manage all the work products. The CASE tools assist to perform various activities such as analysis,
design, coding and testing.

Q 68) What is meant by Delphi method?

The Delphi technique is an estimation technique intended to active a common agreement for
estimation efforts.

Q69) What is meant by software evolution?

Software evolution is a process of managing the changes in the software.

Q 70 ) What is software configuration management (SCM)?

Software configuration management is the art of identifying, organizing, and controlling

modifications to the software being built by a programming team.

Q71 )What is meant by risk management?

Risk management is an activity in which risks in the software projects are identified.

Q72) What is meant by software project scheduling?

Software project scheduling is an activity that distributes estimated effort across the planned project
duration by allocating the effort to specified software engineering tasks.

Q 73) Write about software change strategies.

The software change strategies that could be applied separately or together are:
Software maintenance
– The changes are made in the software due to requirements.
Architectural transformation
–It is the process of changing one architecture into another form.
Software re -engineering
–New features can be added to existing system and
then the system is reconstructed for better use of it in future.
UNIT 6:

Q 74 ) Explain Test Characteristics

A good test has a high probability of finding an error

The tester must understand the software and how it might fail

A good test is not redundant

Tests that have the highest likelihood of uncovering a whole class of errors should be used

A good test should be neither too simple nor too complex

Each test should be executed separately; combining a series of tests could cause side effects and mask

certain errors

Q75) Write down two Unit Testing Techniques

Black-box testing

Knowing the specified function that a product has been designed to perform, test to see if that
function is fully operational and error free

Includes tests that are conducted at the software interface

Not concerned with internal logical structure of the software

White-box testing

Knowing the internal workings of a product, test that all internal operations are performed according
to specifications and all internal components have been exercised

Involves tests that concentrate on close examination of procedural detail

Logical paths through the software are tested

Test cases exercise specific sets of conditions and loops

Test Case Design

Objective to uncover error

Criteria in a complete manner

Constraint with a minimum of effort and time

Q76)Why to perform white box testing?

There are three main reasons behind performing the white box testing.
Programmers may have some incorrect assumptions while designing or implementing some
functions. Due to this there are chances of having logical errors in the program. To detect and correct
such logical errors procedural details need to be examined.

Certain assumptions on flow of control and data may lead programmer to make design errors. To
uncover the errors on logical path, white box testing is must.

There may be certain typographical errors that remain undetected even after syntax and type
checking mechanisms. Such errors can be uncovered during white box testing.

Q77) Cyclomatic Complexity

Cyclomatic complexity is a software metric that gives the quantitative measure of logical complexity
of the program. The Cyclomatic complexity defines the number of independent paths in the basis set
of the program that provides the upper bound for the number of tests that must be conducted to
ensure that all the statements have been executed at least once.

The cyclomatic complexity can be computed by one of the following ways.

The number of regions of the flow graph correspond to the cyclomatic complexity.

2. Cyclomatic complexity, V(G), for a flow graph, G, is defined as:

V(G) = E - N + 2 ,

E - number of flow graph edges, N - number of flow graph nodes 3. V(G) = P + 1

where P is the number of predicate nodes contained in the flow graph G.

Q78)Define Structural Testing

The structural testing is sometime called as white-box testing.

In structural testing derivation of test cases is according to program structure. Hence knowledge of
the program is used to identify additional test cases.

Objective of structural testing is to exercise all program statements.

Condition Testing

To test the logical conditions in the program module the condition testing is used. This condition can
be a Boolean condition or a relational expression. The condition is incorrect in following situat ions.

i) Boolean operator is incorrect, missing or extra.

Boolean variable is incorrect.

Boolean parenthesis may be missing, incorrect or extra.

Error in relational operator.

Error in arithmetic expression.

The condition testing focuses on each testing condition in the program.

The branch testing is a condition testing strategy in which for a compound condition each and every
true or false branches are tested.

The domain testing is a testing strategy in which relational expression can be tested using three or
four tests.

Basis Path Testing

White-box testing technique proposed by Tom McCabe

Enables the test case designer to derive a logical complexity measure of a procedural design

Uses this measure as a guide for defining a basis set of execution paths

Test cases derived to exercise the basis set are guaranteed to execute every statement in the program
at least one time during testing

Flow Graph Notation

A circle in a graph represents a node, which stands for a sequence of one or more procedural
statements

A node containing a simple conditional expression is referred to as a predicate node

Each compound condition in a conditional expression containing one or more Boolean operators
(e.g., and, or) is represented by a separate predicate node

A predicate node has two edges leading out from it (True and False)

An edge, or a link, is a an arrow representing flow of control in a specific direction

An edge must start and terminate at a node

An edge does not intersect or cross over another edge

Areas bounded by a set of edges and nodes are called regions

When counting regions, include the area outside the graph as a region, too

Independent Program Paths

Defined as a path through the program from the start node until the end node that introduces at least
one new set of processing statements or a new condition (i.e., new nodes)

Must move along at least one edge that has not been traversed before by a previous path

Basis set for flow graph on previous slide

Path 1: 0-1-11

Path 2: 0-1-2-3-4-5-10-1-11

Path 3: 0-1-2-3-6-8-9-10-1-11
Path 4: 0-1-2-3-6-7-9-10-1-11

The number of paths in the basis set is determined by the cyclomatic complexity

Deriving the Basis Set and Test Cases

1) Using the design or code as a foundation, draw a corresponding flow graph

Determine the cyclomatic complexity of the resultant flow graph

Determine a basis set of linearly independent paths

4) Prepare test cases that will force execution of each path in the basis set

Loops are fundamental to many algorithms and need thorough testing.

There are four different classes of loops: simple, concatenated, nested, and unstructured.

Examples:
Create a set of tests that force the following situations:

Simple Loops, where n is the maximum number of allowable passes through the loop.

o Skip loop entirely

o Only one pass through loop o Two passes through loop

o m passes through loop where m<n.

o (n-1), n, and (n+1) passes through the loop.

Nested Loops

Start with inner loop. Set all other loops to minimum values.

Conduct simple loop testing on inner loop.

Work outwards

Continue until all loops tested.

Concatenated Loops

If independent loops, use simple loop testing.

If dependent, treat as nested loops.

Unstructured loops

Boundary Value Analysis

A boundary value analysis is a testing technique in which the elements at the edge of the domain are
selected and tested.
Instead of focusing on input conditions only, the test cases from output domain are also derived.

Boundary value analysis is a test case design technique that complements equivalence partitioning
technique.

Guidelines for boundary value analysis technique are

If the input condition specified the range bounded by values x and y, then test cases should be
designed with values x and y. Also test cases should be with the values above and below x and y.

If input condition specifies the number of values then the test cases should be designed with
minimum and maximum values as well as wit~ the values that are just above and below the
maximum and minimum should be tested.

If the output condition specified the range bounded by values x and y, then test cases should be
designed with values x and y. Also test cases should be with the values above and below x and y.

If output condition specifies the number of values then the test cases should be designed with
minimum and maximum values as well as with the values that are just above and below the
maximum and minimum should be tested.

If the internal program data structures specify such boundaries then the test cases must be designed

such that the values at the boundaries of data structure can be tested.

Q79) Explain Regression Testing

The selective retesting of a software system that has been modified to ensure that any bugs have been

fixed and that no other previously working functions have failed as a result of the reparations and that

newly added features have not created problems with previous versions of the software. Also referred

to as verification testing, regression testing is initiated after a programmer has attempted to fix a

recognized problem or has added source code to a program that may have inadvertently introduced

errors. It is a quality control measure to ensure that the newly modified code still complies with its

specified requirements and that unmodified code has not been affected by the maintenance activity.

Q80 ) Define software testing?

Software testing is a critical element of software quality assurance

and represents the
ultimate review of specification, design, and coding.
Q81) . What are the objectives of testing?
i. Testing is a process of executing a program with the intend of finding an error.
ii. A good test case is one that has high probability of finding an undiscovered error.
iii. A successful test is one that uncovers as an yet undiscovered error.

Q82) What are the testing principles the software engineer must apply while performing the
software
testing?
i. All tests should be traceable to customer requirements.
ii. Tests should be planned long before testing begins.
iii. The pareto principle can be applied to software testing
80% of all errors uncovered during testing will likely be traceable to 20% of all program modules.
iv. Testing should begin “in the small” and progress toward testing “in the large”.
v. Exhaustive testing is not possible.
vi. To be most effective, an independent third party should conduct testing

Q83) . What are the two levels of testing?

i. Component testing Individual components are tested. Tests are derived from developer‟s
experience.
ii. System Testing- The group of components are integrated to create a system or sub -system is
done.
These tests are based on the system specification.

Q84). What are the various testing activities?

i. Test planning
ii. Test case design
iii. Test execution
iv. Data collection
v. Effective evaluation

Q85). Write short note on black box testing.

The black box testing is also called as behavioral testing. This method fully focus on the functional
requirements of the software. Tests are derive d that fully exercise all functional requirements.

Q86) . What is equivalence partitioning?

Equivalence partitioning is a black box technique that divides the input domain into classes of data.

From this data test cases can be derived. Equivalence class represents a set of valid or invalid states

for input conditions.

Q87). What is a boundary value analysis?

A boundary value analysis is a testing technique in which the elements at the edge of the
domain are selected and tested. It is a test case design technique that complements equivalence
partitioning technique.

Q 88) . What are the reasons behind to perform white box testing?
 There are three main reasons behind performing the white box testing.
1. Programmers may have some incorrect assumptions while designing or implementing some
functions.
2. Certain assumptions on flow of control and data may lead programmer to make design errors. To
uncover the errors on logical path, white box testing is must.
3. There may be certain typographical errors that remain undetected even after syntax
and type checking mechanisms. Such errors can be uncovered during white box testing.

Q89) . What is cyclomatic complexity?

Cyclomatic complexity is software metric that gives the quantitative Measure of logical complexity
of the program.

Q90) . How to compute the cyclomatic complexity?

The cyclomatic complexity can be computed by any one of the following ways
.1. The numbers of regions of the flow graph correspond to the cyclomatic complexity.
2. Cyclomatic complexity (G), for the flow graph G, is defined as: V(G)=E
- N+2, E – number of flow graph edges, N
--number of flow graph nodes
3.V(G)= P+1 Where P is the number of predicate nodes contained in the flow graph.

Q91) . Distinguish between verification and validation.

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

Q92). What are the various testing strategies for conventional software?
i. Unit testing
ii. Integration testing.
iii. Validation testing.
iv. System testing.

Q93) . Write about drivers and stubs.

Drivers and stub software need to be developed to test incompatible software. The “driver ”is a
program that accepts the test data and prints the relevant results.
The “stub” is a subprogram that uses the module interfaces and performs the minimal data
manipulation if required.

Q94) What are the approaches of integration testing?

The integration testing can be carried out using two approaches.

1. The non incremental testing.

2. Incremental testing.
Q95) What are the benefits of smoke testing?

* Integration risk is minimized.

* The quality of the end
-product is improved.
* Error diagnosis and correction are simplified.
* Assessment of program is easy.

Q96) . What are the conditions exists after performing validation testing?
* The function or performance characteristics are according to the specifications and are
accepted.
* The requirement specifications are derived and the deficiency list is created.

Q97) Distinguish between alpha and beta testing

Alpha and beta testing are the types of acceptance testing.
Alpha test:
The alpha testing is attesting in which the version of complete software is tested by the customer
under the supervision of developer. This testing is performed at developer‟s site.
Beta test:
The beta testing is a testing in which the version of the software is tested by the customer without
the developer being present. This testing is performed at customer‟s site.

Q98) . What are the various types of system testing?

1. Recovery testing – is intended to check the system‟s ability to recover from failures.
2. Security testing – verifies that system protection mechanism prevent improper penetration or data
alteration.
3. Stress testing – Determines break point of a system to establish maximum service level.
4. Performance testing – evaluates the run time performance of the software, especially real - time
software.

Q99) Define debugging.

Debugging is defined as the process of removal of defect. It occurs as a consequence of successful
testing.

Q100).What are the common approaches in debugging?

Brute force method:

The memory dumps and run -time tracks are examined and program with write statements is loaded
to obtain clues to error causes.
Back tracking method:
The source code is examined by looking backwards from symptom to potential causes of errors.
Cause elimination method:
This method uses binary partitioning to reduce the number of locations where errors
can exists

Q101). What is meant by structural testing?

In structural testing derivation of test cases is according to program structure. Hence knowledge of
the program is used to identify additional test cases.
Q102) What is meant by regression testing?
Regression testing is used to check for defects propagated to other modules by changes made to
existing program. Thus, regression testing is used to reduce the side effects of the changes.

Q103) What is meant by unit testing?

The unit testing focuses verification effort on the smallest unit of software design, the software
component or module.