DIWAKAR EDUCATION HUB

SOFTWARE ENGINEERING
UNIT – 6
AS PER UPDATED SYLLABUS
DIWAKAR EDUCATION HUB

THE LEARN WITH EXPERTIES

 SOFTWARE ENGINEERING UNIT – 6

Software Process
A software process (also known as software methodology) is a set of related activities that
leads to the production of the software. These activities may involve the development of the
software from the scratch, or, modifying an existing system.
Any software process must include the following four activities:
1. Software specification (or requirements engineering): Define the main functionalities of
the software and the constrains around them.
2. Software design and implementation: The software is to be designed and programmed.
3. Software verification and validation: The software must conforms to it’s specification
and meets the customer needs.
4. Software evolution (software maintenance): The software is being modified to meet
customer and market requirements changes.
In practice, they include sub-activities such as requirements validation, architectural design,
unit testing, …etc.

DIWAKAR EDUCATION HUB Page 2

 SOFTWARE ENGINEERING UNIT – 6
There are also supporting activities such as configuration and change management, quality
assurance, project management, user experience.
Along with other activities aim to improve the above activities by introducing new techniques,
tools, following the best practice, process standardization (so the diversity of software
processes is reduced), etc.
When we talk about a process, we usually talk about the activities in it. However, a process
also includes the process description, which includes:
1. Products: The outcomes of the an activity. For example, the outcome of architectural
design maybe a model for the software architecture.
2. Roles: The responsibilities of the people involved in the process. For example, the
project manager, programmer, etc.
3. Pre and post conditions: The conditions that must be true before and after an activity.
For example, the pre condition of the architectural design is the requirements have
been approved by the customer, while the post condition is the diagrams describing the
architectural have been reviewed.
Software process is complex, it relies on making decisions. There’s no ideal process and most
organizations have developed their own software process.
For example, an organization works on critical systems has a very structured process, while
with business systems, with rapidly changing requirements, a less formal, flexible process is
likely to be more effective.
Software Process Models
A software process model is a simplified representation of a software process. Each model
represents a process from a specific perspective.
A quick glance about very general process models.
These generic models are abstractions of the process that can be used to explain different
approaches to the software development. They can be adapted and extended to create more
specific processes.
Some methodologies are sometimes known as software development life cycle (SDLC)
methodologies, though this term could also be used more generally to refer to any
methodology.
Waterfall Model
The waterfall model is a sequential approach, where each fundamental activity of a process
represented as a separate phase, arranged in linear order.
In the waterfall model, you must plan and schedule all of the activities before starting working
on them (plan-driven process).
Plan-driven process is a process where all the activities are planned first, and the progress is
measured against the plan. While the agile process, planning is incremental and it’s easier to
change the process to reflect requirement changes.
The phases of the waterfall model are: Requirements, Design, Implementation, Testing, and
Maintenance.

DIWAKAR EDUCATION HUB Page 3

 SOFTWARE ENGINEERING UNIT – 6

The Waterfall Model

The Nature of Waterfall Phases
In principle, the result of each phase is one or more documents that should be approved and
the next phase shouldn’t be started until the previous phase has completely been finished.
In practice, however, these phases overlap and feed information to each other. For example,
during design, problems with requirements can be identified, and during coding, some of the
design problems can be found, etc.
The software process therefore is not a simple linear but involves feedback from one phase to
another. So, documents produced in each phase may then have to be modified to reflect the
changes made.
When To Use?
In principle, the waterfall model should only be applied when requirements are well
understood and unlikely to change radically during development as this model has a relatively
rigid structure which makes it relatively hard to accommodate change when the process in
underway.
Prototyping
A prototype is a version of a system or part of the system that’s developed quickly to check the
customer’s requirements or feasibility of some design decisions.
So, a prototype is useful when a customer or developer is not sure of the requirements, or of
algorithms, efficiency, business rules, response time, etc.
In prototyping, the client is involved throughout the development process, which increases the
likelihood of client acceptance of the final implementation.
While some prototypes are developed with the expectation that they will be discarded, it is
possible in some cases to evolve from prototype to working system.
A software prototype can be used:

DIWAKAR EDUCATION HUB Page 4

 SOFTWARE ENGINEERING UNIT – 6
[1] In the requirements engineering, a prototype can help with the elicitation and validation
of system requirements.
It allows the users to experiment with the system, and so, refine the requirements. They may
get new ideas for requirements, and find areas of strength and weakness in the software.
Furthermore, as the prototype is developed, it may reveal errors and in the requirements. The
specification maybe then modified to reflect the changes.
[2] In the system design, a prototype can help to carry out deign experiments to check the
feasibility of a proposed design.
For example, a database design may be prototype-d and tested to check it supports efficient
data access for the most common user queries.

The process of prototype development

The phases of a prototype are:
1. Establish objectives: The objectives of the prototype should be made explicit from the
start of the process. Is it to validate system requirements, or demonstrate feasibility,
etc.
2. Define prototype functionality: Decide what are the inputs and the expected output
from a prototype. To reduce the prototyping costs and accelerate the delivery schedule,
you may ignore some functionality, such as response time and memory utilization unless
they are relevant to the objective of the prototype.
3. Develop the prototype: The initial prototype is developed that includes only user
interfaces.
4. Evaluate the prototype: Once the users are trained to use the prototype, they then
discover requirements errors. Using the feedback both the specifications and the
prototype can be improved. If changes are introduced, then a repeat of steps 3 and 4
may be needed.
Prototyping is not a standalone, complete development methodology, but rather an approach
to be used in the context of a full methodology (such as incremental, spiral, etc).
Incremental Development
Incremental development is based on the idea of developing an initial implementation,
exposing this to user feedback, and evolving it through several versions until an acceptable
system has been developed.
The activities of a process are not separated but interleaved with feedback involved across
those activities.
DIWAKAR EDUCATION HUB Page 5
 SOFTWARE ENGINEERING UNIT – 6

The Incremental Development Model

Each system increment reflects a piece of the functionality that is needed by the customer.
Generally, the early increments of the system should include the most important or most
urgently required functionality.
This means that the customer can evaluate the system at early stage in the development to
see if it delivers what’s required. If not, then only the current increment has to be changed
and, possibly, new functionality defined for later increments.
Incremental Vs Waterfall Model
Incremental software development is better than a waterfall approach for most business, e-
commerce, and personal systems.
By developing the software incrementally, it is cheaper and easier to make changes in the
software as it is being developed.
Compared to the waterfall model, incremental development has three important benefits:
1. The cost of accommodating changing customer requirements is reduced. The amount
of analysis and documentation that has to be redone is much less than that’s required
with waterfall model.
2. It’s easier to get customer feedback on the work done during development than when
the system is fully developed, tested, and delivered.
3. More rapid delivery of useful software is possible even if all the functionality hasn’t
been included. Customers are able to use and gain value from the software earlier than
it’s possible with the waterfall model.
It can be a plan-driven or agile, or both
Incremental development is one of the most common approaches. This approach can be
either a plan-driven or agile, or both.

DIWAKAR EDUCATION HUB Page 6

 SOFTWARE ENGINEERING UNIT – 6
In a plan-driven approach, the system increments are identified in advance, but, in the agile
approach, only the early increments are identified and the development of later increments
depends on the progress and customer priorities.
It’s not a problem-free
But, it’s not a problem-free …
 Some organizations have procedures that have evolved over the time, and can’t follow
informal iterative or agile process. For example, procedures to ensure that the software
properly implements external regulations.
 System structure tends to degrades as new increments are added and get corrupted as
regular changes are incorporated. Even if time and money spent on refactoring to
improve the software, further changes becomes more difficult and costly.
Spiral Model
The spiral model is a risk-driven where the process is represented as spiral rather than a
sequence of activities.
It was designed to include the best features from the waterfall and prototyping models, and
introduces a new component; risk-assessment.
Each loop (from review till service — see figure below) in the spiral represents a phase. Thus
the first loop might be concerned with system feasibility, the next loop might be concerned
with the requirements definition, the next loop with system design, and so on.

DIWAKAR EDUCATION HUB Page 7

 SOFTWARE ENGINEERING UNIT – 6

The spiral model

Each loop in the spiral is split into four sectors:
1. Objective setting: The objectives and risks for that phase of the project are defined.
2. Risk assessment and reduction: For each of the identified project risks, a detailed
analysis is conducted, and steps are taken to reduce the risk. For example, if there’s a
risk that the requirements are inappropriate, a prototype may be developed.
3. Development and validation: After risk evaluation, a process model for the system is
chosen. So if the risk is expected in the user interface then we must prototype the user
interface. If the risk is in the development process itself then use the waterfall model.
4. Planning: The project is reviewed and a decision is made whether to continue with a
further loop or not.
Spiral model has been very influential in helping people think about iteration in software
processes and introducing the risk-driven approach to development. In practice, however, the
model is rarely used.
Iterative Development
Iterative development model aims to develop a system through building small portions of all
the features, across all components.
DIWAKAR EDUCATION HUB Page 8
 SOFTWARE ENGINEERING UNIT – 6
We build a product which meets the initial scope and release it quickly for customer feedback.
An early version with limited features important to establish market and get customer
feedback.
In each increment, a slice of system features is delivered, passing through the requirements till
the deployment.

The phases of iterative development

The phases of iterative development are:
1. Inception: The goal is to establish a business case for the system. We should identify all
the external entities that will interact with the system, and define these interactions.
Then, uses this information to assess the contribution that the system makes to the
business. If the contribution is minor, then the project may be cancelled.
2. Elaboration: We develop an understanding of the problem domain and architecture
framework, develop the project plan, and identify risks.
3. Construction: Incrementally fills-in the architecture with production-ready code
produced from analysis, design, implementation, and testing of the requirements. The
components of the system are dependent on each other and they’re developed in
parallel and integrated during this phase. On the completion of this phase, you should
have a complete working software.
4. Transition: We deliver the system into the production operating environment.
All the phases will be done once, while the construction phase will be incrementally visited for
each increment; for each slice of system features.
Agile
Agility is flexibility, it is a state of dynamic, adapted to the specific circumstances.
The agile methods refers to a group of software development models based on the
incremental and iterative approach, in which the increments are small and typically, new
releases of the system are created and made available to customers every few weeks.

DIWAKAR EDUCATION HUB Page 9

 SOFTWARE ENGINEERING UNIT – 6

The principles of agile methods

They involve customers in the development process to propose requirements changes. They
minimize documentation by using informal communications rather than formal meetings with
written documents.
They are best suited for application where the requirements change rapidly during the
development process.
There are a number of different agile methods available such as: Scrum, Crystal, Agile
Modeling (AM), Extreme Programming (XP), etc.
Increment Vs Iterative Vs Agile
You might be asking about the difference between incremental, iterative and agile models.
Each increment in the incremental approach builds a complete feature of the software, while
in iterative, it builds small portions of all the features.
An agile approach combines the incremental and iterative approach by building a small
portion of each feature, one by one, and then both gradually adding features and increasing
their completeness.
Reuse-oriented Software Engineering
It’s attempting to reuse an existing design or code (probably also tested) that’s similar to
what’s required. It’s then modified, and incorporated to the new system.

DIWAKAR EDUCATION HUB Page 10

 SOFTWARE ENGINEERING UNIT – 6

The Reuse-oriented software engineering model

Although the initial “requirements specification” phase and the “validation ” phase are
comparable with other software processes, the intermediate phases in a reuse-oriented
process are different. These phases are:
1. Component analysis: A search is made for the components to implement the given
requirements specification. Usually, there’s no exact match, and components may be
only provide some of the functionality required.
2. Requirements modification: During this phase, the requirements are analyzed using
information about the components that have been discovered. They are then modified
to reflect the available components. If the modifications are impossible, the component
analysis activity may be re-entered to search for alternative solutions.
3. System design with reuse: During this phase, the framework of the system is designed
or an existing framework is reused. The designers take into account the components
that are reused and they will organize the framework accordingly. Some new software
has to be designed if some reusable components are not available.
4. Development and integration: The components are integrated to create the new
system. System integration, in this model, may be part of the development process
rather than a separate activity.
There are basically three types of software components that can be used in a reuse-oriented
process:
1. Web services that are developed according to well-known service standards and which
will become available for remote invocation.
2. Collections of objects that are developed as a package to be integrated with a
component framework such as .NET or Java EE.
3. Standalone software systems that are configured for use in a particular environment.
It’s has an obvious advantage, But!
Reuse-oriented software engineering has an obvious advantage of reducing the amount of
software to be developed and therefore reduced cost and risks, and usually leads to faster
delivery.
However, requirements compromises can’t be avoided, which may lead to a system that does
not meet the real needs of users.
Furthermore, some control over the system evolution might also be lost as new versions of the
reusable components are not under the control of the organization using them.

DIWAKAR EDUCATION HUB Page 11

 SOFTWARE ENGINEERING UNIT – 6
Framework
Framework is a Standard way to build and deploy applications. Software Process
Framework is a foundation of complete software engineering process. Software process
framework includes all set of umbrella activities. It also includes number of framework
activities that are applicable to all software projects.

A generic process framework encompasses five activities which are given below one by one:
1. Communication: In this activity, heavy communication with customers and other
stakeholders, requirement gathering is done.
2. Planning: In this activity, we discuss the technical related tasks, work schedule, risks,
required resources etc.
3. Modeling: Modelling is about building representations of things in the ‘real world’.In
modelling activity, a product’s model is created in order to better understanding and
requirements.
4. Construction: In software engineering, construction is the application of set of
procedures that are needed to assemble the product. In this activity, we generate the
code and test the product in order to make better product.
5. Deployment: In this activity, a complete or non-complete products or software are
represented to the customers to evaluate and give feedback. on the basis of their
feedback we modify the products for supply better product.
Umbrella activities include:
 Risk management
 Software quality assurance(SQA)
 Software configuration management(SCM)

DIWAKAR EDUCATION HUB Page 12

 SOFTWARE ENGINEERING UNIT – 6
 Measurement
 Formal technical reviws(FTR)
Task Set
A number of different process models were already discussed. These models offer different
paradigms for software development. Regardless of whether a software team chooses a linear
sequential paradigm, an iterative paradigm, an evolutionary paradigm, a concurrent paradigm
or some permutation, the process model is populated by a set of tasks that enable a software
team to define, develop, and ultimately support computer software.

No single set of tasks is appropriate for all projects. The set of tasks that would be appropriate
for a large, complex system would likely be perceived as overkill for a small, relatively simple
software product. Therefore, an effective software process should define a collection of task
sets, each designed to meet the needs of different types of projects.

A task set is a collection of software engineering work tasks, milestones, and deliverables that
must be accomplished to complete a particular project. The task set to be chosen must
provide enough discipline to achieve high software quality. But, at the same time, it must not
burden the project team with unnecessary work.
Task sets are designed to accommodate different types of projects and different degrees of
rigor. Although it is difficult to develop a comprehensive taxonomy of software project types,
most software organizations encounter the following projects:

1. Concept development projects that are initiated to explore some new business concept or
application of some new technology.
2. New application development projects that are undertaken as a consequence of a specific
customer request.
3. Application enhancement projects that occur when existing software undergoes major
modifications to function, performance, or interfaces that are observable by the end-user.
4. Application maintenance projects that correct, adapt, or extend existing software in ways
that may not be immediately obvious to the end-user.
5. Reengineering projects that are undertaken with the intent of rebuilding an existing (legacy)
system in whole or in part.

Even within a single project type, many factors influence the task set to be chosen. When
taken in combination, these factors provide an indication of the degree of rigor with which the
software process should be applied.

Degree of Rigor

Even for a project of a particular type, the degree of rigor with which the software process is
applied may vary significantly. The degree of rigor is a function of many project characteristics.
As an example, small, non-business-critical projects can generally be addressed with

DIWAKAR EDUCATION HUB Page 13

 SOFTWARE ENGINEERING UNIT – 6
somewhat less rigor than large, complex business-critical applications. It should be noted,
however, that all projects must be conducted in a manner that results in timely, high-quality
deliverables. Four different degrees of rigor can be defined:

Casual. All process framework activities (Chapter 2) are applied, but only a minimum task set is
required. In general, umbrella tasks will be minimized and documentation requirements will
be reduced. All basic principles of software engineering are still applicable.

Structured. The process framework will be applied for this project. Framework activities and
related tasks appropriate to the project type will be applied and umbrella activities necessary
to ensure high quality will be applied. SQA, SCM, documentation, and measurement tasks will
be conducted in a streamlined manner.

Strict. The full process will be applied for this project with a degree of discipline that will
ensure high quality. All umbrella activities will be applied and robust work products will be
produced.

Quick reaction. The process framework will be applied for this project, but because of an
emergency situation only those tasks essential to maintaining good quality will be applied.
“Back-filling” (i.e., developing a complete set of documentation, conducting additional
reviews) will be accomplished after
the application/product is delivered to the customer.

The project manager must develop a systematic approach for selecting the degree of rigor that
is appropriate for a particular project. To accomplish this, project adaptation criteria are
defined and a task set selector value is computed.

Defining Adaptation Criteria

Adaptation criteria are used to determine the recommended degree of rigor with which the
software process should be applied on a project. Eleven adaptation criteria are defined for
software projects:
• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Embedded and nonembedded characteristics
• Project staff
• Reengineering factors

DIWAKAR EDUCATION HUB Page 14

 SOFTWARE ENGINEERING UNIT – 6

Each of the adaptation criteria is assigned a grade that ranges between 1 and 5, where 1
represents a project in which a small subset of process tasks are required and overall
methodological and documentation requirements are minimal, and 5 represents a project in
which a complete set of process tasks should be applied and overall methodological and
documentation requirements are substantial.
Computing a Task Set Selector Value

To select the appropriate task set for a project, the following steps should be conducted:
1. Review each of the adaptation criteria in Section 7.3.2 and assign the appropriate grades (1
to 5) based on the characteristics of the project. These grades should be entered into Table
2. Review the weighting factors assigned to each of the criteria. The value of a weighting factor
ranges from 0.8 to 1.2 and provides an indication of the relative importance of a particular
adaptation criterion to the types of software developed within the local environment. If
modifications are required to better reflect local circumstances, they should be made.

3. Multiply the grade entered in Table 7.1 by the weighting factor and by the entry point
multiplier for the type of project to be undertaken. The entry point multiplier takes on a value
of 0 or 1 and indicates the relevance of the adaptation criterion to the project type. The result
of the product grade x weighting factor x entry point multiplier is placed in the Product column
of Table 7.1 for each adaptation criteria individually.

4. Compute the average of all entries in the Product column and place the result in the space
DIWAKAR EDUCATION HUB Page 15
 SOFTWARE ENGINEERING UNIT – 6
marked task set selector (TSS). This value will be used to help select the task set that is most
appropriate for the project.

Interpreting the TSS Value and Selecting the Task Set

Once the task set selector is computed, the following guidelines can be used to select the
appropriate task set for a project:
Task set selector value Degree of rigor
TSS < 1.2 casual
1.0 < TSS < 3.0 structured
TSS > 2.4 strict

The overlap in TSS values from one recommended task set to another is purposeful and is
intended to illustrate that sharp boundaries are impossible to define when making task set
selections. In the final analysis, the task set selector value, past experience, and common
sense must all be factored into the choice of the task set for a project.

Table illustrates how TSS might be computed for a hypothetical project. The project manager
selects the grades shown in the Grade column. The project type is new application
development. Therefore, entry point multipliers are selected from the NDev column. The entry
in the Product column is computed using Grade x Weight x NewDev entry point multiplier.
Process Pattern
The software process can be defined as a collection of patterns that define a set of activities,
actions, work tasks, work products and/or related behaviors required to develop computer
software.

Patterns can be defined at any level of abstraction. In some cases, a pattern might be used to
describe a complete process (e.g., prototyping). In other situations, patterns can be used to
describe an important framework activity (e.g., planning) or a task within framework activity
(e.g., project- estimating). Ambler has proposed the following template for describing a
process pattern:

Pattern Name. The pattern is given a meaningful name that describes its functions within the
software process (e.g., customer-communication).

Intent. The objective of the pattern is described briefly. For example, the intent of customer-
communication is “to establish a collaborative relationship with the customer in an effort to
define project scope, business requirements, and other projects constraints”.

Type. The pattern type is specified. Ambler suggests three types:

• Task pattern define a software engineering action or work task that is part of the process
and relevant to successful software engineering practice (e.g., requirements gathering is a task
DIWAKAR EDUCATION HUB Page 16
 SOFTWARE ENGINEERING UNIT – 6
pattern).

• Stage patterns represent a framework activity for the process. Since a framework activity
encompasses multiple work tasks, a stage pattern incorporates multiple task patterns that are
relevant to the stage. An example of a stage pattern might be communication. This pattern
would incorporate the task pattern requirements gathering and others.

• Phase patterns define the sequence of framework activities is iterative in nature. An example
of a phase pattern might be a spiral model or prototyping.

Initial context. The conditions under which the pattern applies are described. Prior to the
initiation of the pattern, we ask (1) what organizational team created activities have already
occurred (2) what is the entry state for the process? And (3) what software engineering
information or project information already exists?

For example, the planning pattern (a stage pattern) requires that (1) customers and software
engineers have established a collaborative communication: (2) successful completion of a
number of task patterns (specified) for the customer-communication pattern has occurred:
and (3) project scope, basic business requirements, and project constraints are known.

An Example Process Pattern:

The following abbreviated process pattern describes an approach that may be applicable when
stakeholders have a general idea of what must be done, but are unsure of specific software
requirements.

Pattern name. Prototyping.

Intent: The objective of the pattern is to build a model (a prototype) that can be assessed
iteratively by stakeholders in an effort to identify or solidity software requirements.

Type: Phase pattern.

Initial context: The following conditions must be met prior to the initiation of this pattern:( 1)
stakeholders have been identified; (2) a mode of communication between stakeholders and
the software team has been established; (3) the overriding problem to be solved has been
identified by stakeholders: (4) an initial understanding of project scope, basic business
requirements, and project constraints has been developed.

Problem: Requirements are hazy or nonexistent, yet there is clear recognition that there is a
problem, and the problem must be addressed with a software solution. Stakeholders are
unsure of what they want; that is, they cannot describe software requirements in any detail.

DIWAKAR EDUCATION HUB Page 17

 SOFTWARE ENGINEERING UNIT – 6
Solutions: A description of the prototype that identifies basic requirements (e.g., modes of
interaction, computational features, processing functions) is approved by stakeholders.
Following this, (1) the prototype may evolve through a series of increments to become the
production software or (2) the prototype may be discarded and the production software built
using some other process pattern.

Related Patterns: The following patterns are related to this pattern: customer-
communication; iterative design; iterative development, customer assessment; requirement
extraction.

Known uses/examples: Prototyping is recommended when requirements are uncertain.

Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality softwares. The SDLC aims to produce a high-quality software that
meets or exceeds customer expectations, reaches completion within times and cost estimates.
 SDLC is the acronym of Software Development Life Cycle.
 It is also called as Software Development Process.
 SDLC is a framework defining tasks performed at each step in the software development
process.
 ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be
the standard that defines all the tasks required for developing and maintaining
software.
SDLC is a process followed for a software project, within a software organization. It consists of
a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.

DIWAKAR EDUCATION HUB Page 18

 SOFTWARE ENGINEERING UNIT – 6

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis
Requirement analysis is the most important and fundamental stage in SDLC. It is performed by
the senior members of the team with inputs from the customer, the sales department, market
surveys and domain experts in the industry. This information is then used to plan the basic
project approach and to conduct product feasibility study in the economical, operational and
technical areas.
Planning for the quality assurance requirements and identification of the risks associated with
the project is also done in the planning stage. The outcome of the technical feasibility study is
to define the various technical approaches that can be followed to implement the project
successfully with minimum risks.
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts. This
is done through an SRS (Software Requirement Specification) document which consists of all
the product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as
risk assessment, product robustness, design modularity, budget and time constraints, the best
design approach is selected for the product.
DIWAKAR EDUCATION HUB Page 19
 SOFTWARE ENGINEERING UNIT – 6
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if
any). The internal design of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The programming
code is generated as per DDS during this stage. If the design is performed in a detailed and
organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming
tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java and PHP are used for coding. The
programming language is chosen with respect to the type of software being developed.
Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing
only stage of the product where product defects are reported, tracked, fixed and retested,
until the product reaches the quality standards defined in the SRS.
Stage 6: Deployment in the Market and Maintenance
Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometimes product deployment happens in stages as per the business strategy of that
organization. The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the market,
its maintenance is done for the existing customer base.
SDLC Models
There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred as
Software Development Process Models". Each process model follows a Series of steps unique
to its type to ensure success in the process of software development.
Following are the most important and popular SDLC models followed in the industry −
 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Big Bang Model
Other related methodologies are Agile Model, RAD Model, Rapid Application Development
and Prototyping Models.
The following framework activities are carried out irrespective of the process model chosen by
the organization.

DIWAKAR EDUCATION HUB Page 20

 SOFTWARE ENGINEERING UNIT – 6
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment

The name 'prescriptive' is given because the model prescribes a set of activities, actions, tasks,
quality assurance and change the mechanism for every project.

There are three types of prescriptive process models. They are:

1. The Waterfall Model

2. Incremental Process model
3. RAD model
1. The Waterfall Model
 The waterfall model is also called as 'Linear sequential model' or 'Classic life cycle
model'.
 In this model, each phase is fully completed before the beginning of the next phase.
 This model is used for the small projects.
 In this model, feedback is taken after each phase to ensure that the project is on the
right path.
 Testing part starts only after the development is complete.

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

An alternative design for 'linear sequential model' is as follows:

DIWAKAR EDUCATION HUB Page 21

 SOFTWARE ENGINEERING UNIT – 6

Advantages of waterfall model

 The waterfall model is simple and easy to understand, implement, and use.
 All the requirements are known at the beginning of the project, hence it is easy to
manage.
 It avoids overlapping of phases because each phase is completed at once.
 This model works for small projects because the requirements are understood very well.
 This model is preferred for those projects where the quality is more important as
compared to the cost of the project.
Disadvantages of the waterfall model
 This model is not good for complex and object oriented projects.
 It is a poor model for long projects.
 The problems with this model are uncovered, until the software testing.
 The amount of risk is high.
2. Incremental Process model
 The incremental model combines the elements of waterfall model and they are applied
in an iterative fashion.
 The first increment in this model is generally a core product.
 Each increment builds the product and submits it to the customer for any suggested
modifications.
 The next increment implements on the customer's suggestions and add additional
requirements in the previous increment.
 This process is repeated until the product is finished.
For example, the word-processing software is developed using the incremental model.

DIWAKAR EDUCATION HUB Page 22

 SOFTWARE ENGINEERING UNIT – 6

Advantages of incremental model

 This model is flexible because the cost of development is low and initial product delivery
is faster.
 It is easier to test and debug during the smaller iteration.
 The working software generates quickly and early during the software life cycle.
 The customers can respond to its functionalities after every increment.
Disadvantages of the incremental model
 The cost of the final product may cross the cost estimated initially.
 This model requires a very clear and complete planning.
 The planning of design is required before the whole system is broken into small
increments.
 The demands of customer for the additional functionalities after every increment causes
problem during the system architecture.
3. RAD model
 RAD is a Rapid Application Development model.
 Using the RAD model, software product is developed in a short period of time.
 The initial activity starts with the communication between customer and developer.
 Planning depends upon the initial requirements and then the requirements are divided
into groups.
 Planning is more important to work together on different modules.
The RAD model consist of following phases:

1. Business Modeling
 Business modeling consist of the flow of information between various functions in the
project.
 For example what type of information is produced by every function and which are the
functions to handle that information.

DIWAKAR EDUCATION HUB Page 23

 SOFTWARE ENGINEERING UNIT – 6
 A complete business analysis should be performed to get the essential business
information.
2. Data modeling
 The information in the business modeling phase is refined into the set of objects and it
is essential for the business.
 The attributes of each object are identified and define the relationship between objects.
3. Process modeling
 The data objects defined in the data modeling phase are changed to fulfil the
information flow to implement the business model.
 The process description is created for adding, modifying, deleting or retrieving a data
object.
4. Application generation
 In the application generation phase, the actual system is built.
 To construct the software the automated tools are used.
5. Testing and turnover
 The prototypes are independently tested after each iteration so that the overall testing
time is reduced.
 The data flow and the interfaces between all the components are are fully tested.
Hence, most of the programming components are already tested.

Software Project Management

Software project management refers to the branch of project management dedicated to the
planning, scheduling, resource allocation, execution, tracking and delivery of software and
web projects.
Project management in software engineering is distinct from traditional project management
in that software projects have a unique lifecycle process that requires multiple rounds of
testing, updating, and customer feedback. Most IT-related projects are managed in the agile

DIWAKAR EDUCATION HUB Page 24

 SOFTWARE ENGINEERING UNIT – 6
style, in order to keep up with the increasing pace of business, and iterate based on customer
and stakeholder feedback.
The role and responsibility of a software project manager
Software project managers may have to do any of the following tasks:
1. Planning: This means putting together the blueprint for the entire project from ideation
to fruition. It will define the scope, allocate necessary resources, propose the timeline,
delineate the plan for execution, lay out a communication strategy, and indicate the
steps necessary for testing and maintenance.
2. Leading: A software project manager will need to assemble and lead the project team,
which likely will consist of developers, analysts, testers, graphic designers, and technical
writers. This requires excellent communication, people and leadership skills.
3. Execution: The project manager will participate in and supervise the successful
execution of each stage of the project. This includes monitoring progress, frequent team
check-ins and creating status reports.
4. Time management: Staying on schedule is crucial to the successful completion of any
project, but it’s particularly challenging when it comes to managing software projects
because changes to the original plan are almost certain to occur as the project evolves.
Software project managers must be experts in risk management and contingency
planning to ensure forward progress when roadblocks or changes occur.
5. Budget: Like traditional project managers, software project managers are tasked with
creating a budget for a project, and then sticking to it as closely as possible, moderating
spend and re-allocating funds when necessary.
6. Maintenance: Software project management typically encourages constant product
testing in order to discover and fix bugs early, adjust the end product to the customer’s
needs, and keep the project on target. The software project manager is responsible for
ensuring proper and consistent testing, evaluation and fixes are being made.
How to manage a software project successfully?
A recent article in Forbes suggests that there are eight ways to improve and streamline the
software project management process; these eight suggestions include:
 Take non-development work off your team’s plate to let them focus on developing
 Motivating your team by sharing others’ success stories—like those of tech giants,
which will inspire and excite your team
 Avoid altering the task once its assigned
 Try to stick to the plan (until it needs to be changed)
 Encouraging organization by being organized
 Streamline productivity through effective delegation
 Get to know your team and build a rapport
 Break down the plan and give them specific daily tasks
Agile software engineering
Agile software engineering represents a reasonable compromise between to conventional
software engineering for certain classes of software and certain types of software projects.

DIWAKAR EDUCATION HUB Page 25

 SOFTWARE ENGINEERING UNIT – 6
Agile processes can deliver successful systems quickly. It stresses on continuous
communication and collaboration among developers and customers.
Agile software engineering embraces a philosophy that encourages customer satisfaction,
incremental software delivery, small project teams (composed of software engineers and
stakeholders), informal methods, and minimal software engineering work products. Agile
software engineering guidelines stress on-time delivery of an operational software increment
over analysis and design
 An agile team is able to respond to changes during project development
 Agile development recognizes that project plans must be flexible
 Agility encourages team structures and attitudes that make communication among
developers and customers more facile
 Agility eliminates the separation between customers and developers
 Agility emphasizes the importance of rapid delivery of operational software and de-
emphasizes importance of intermediate work products
 Agility can be applied to any software process as long as the project team is allowed to
streamline tasks and conduct planning in way that eliminate non-essential work
products
Agile Processes
 Are based on three key assumptions
1. It is difficult to predict in advance which requirements or customer priorities will
change and which will not
2. For many types of software design and construction activities are interleaved
(construction is used to prove the design)
3. Analysis, design, and testing are not as predictable from a planning perspective as
one might like them to be
 Agile processes must be adapted incrementally to manage unpredictability
 Incremental adaptation requires customer feedback based on evaluation of delivered
software increments (executable prototypes) over short time periods
Agility Principles
 Highest priority is to satisfy customer through early and continuous delivery of valuable
software
 Welcome changing requirements even late in development, accommodating change is
viewed as increasing the customer’s competitive advantage
 Delivering working software frequently with a preference for shorter delivery schedules
(e.g., every 2 or 3 weeks)
 Business people and developers must work together daily during the project
 Build projects around motivated individuals, given them the environment and support
they need, trust them to get the job done
 Face-to-face communication is the most effective method of conveying information
within the development team
 Working software is the primary measure of progress

DIWAKAR EDUCATION HUB Page 26

 SOFTWARE ENGINEERING UNIT – 6
 Agile processes support sustainable development, developers and customers should be
able to continue development indefinitely
 Continuous attention to technical excellence and good design enhances agility
 Simplicity (defined as maximizing the work not done) is essential
 The best architectures, requirements, and design emerge from self-organizing teams
 At regular intervals teams reflects how to become more effective and adjusts its
behavior accordingly
Human Factors
 Traits that need to exist in members of agile development teams:
o Competence
o Common focus
o Collaboration
o Decision-making ability
o Fuzzy-problem solving ability
o Mutual trust and respect
o Self-organization
Agile Process Models
 Extreme Programming (XP)
 Adaptive Software Development (ASD)
 Dynamic Systems Development Method (DSDM)
 Scrum
 Crystal
 Feature Driven Development (FDD)
 Agile Modeling (AM)
Extreme Programming
 Relies on object-oriented approach
 Key activities
o Planning (user stories created and ordered by customer value)
o Design (simple designs preferred, CRC cards and design prototypes are only work
products, encourages use of refactoring)
o Coding (focuses on unit tests to exercise stories, emphasizes use of pairs
programming to create story code, continuous integration and smoke testing is
utilized)
o Testing (unit tests created before coding are implemented using an automated
testing framework to encourage use of regression testing, integration and
validation testing done on daily basis, acceptance tests focus on system features
and functions viewable by the customer)
Adaptive Software Development
 Self-organization arises when independent agents cooperate to create a solution to a
problem that is beyond the capability of any individual agent
DIWAKAR EDUCATION HUB Page 27
 SOFTWARE ENGINEERING UNIT – 6
 Emphasizes self-organizing teams, interpersonal collaboration, and both individual and
team learning
 Adaptive cycle characteristics
 Phases
o Mission-driven
o Component-based
o Iterative
o Time-boxed
o Risk driven and change-tolerant
o Speculation (project initiated and adaptive cycle planning takes place)
o Collaboration (requires teamwork from a jelled team, joint application
development is preferred requirements gathering approach, minispecs created)
o Learning (components implemented and testes, focus groups provide feedback,
formal technical reviews, postmortems)
Dynamic Systems Development Method
 Provides a framework for building and maintaining systems which meet tight time
constraints using incremental prototyping in a controlled environment
 Uses Pareto principle (80% of project can be delivered in 20% required to deliver the
entire project)
 Each increment only delivers enough functionality to move to the next increment
 Uses time boxes to fix time and resources to determine how much functionality will be
delivered in each increment
 Guiding principles
o Active user involvement
o Teams empowered to make decisions
o Fitness foe business purpose is criterion for deliverable acceptance
o Iterative and incremental develop needed to converge on accurate business
solution
o All changes made during development are reversible
o Requirements are baselined at a high level
o Testing integrates throughout life-cycle
o Collaborative and cooperative approach between stakeholders
 Life cycle activities
o Feasibility study (establishes requirements and constraints)
o Business study (establishes functional and information requirements needed to
provide business value)
o Functional model iteration (produces set of incremental prototypes to
demonstrate functionality to customer)
o Design and build iteration (revisits prototypes to ensure they provide business
value for end users, may occur concurrently with functional model iteration)

DIWAKAR EDUCATION HUB Page 28

 SOFTWARE ENGINEERING UNIT – 6
o Implementation (latest iteration placed in operational environment)
Scrum
 Scrum principles
o Small working teamed used to maximize communication, minimize overhead, and
maximize sharing of informal knowledge
o Process must be adaptable to both technical and business challenges to ensure
bets product produced
o Process yields frequent increments that can be inspected, adjusted, tested,
documented and built on
o Development work and people performing it are partitioned into clean, low
coupling partitions
o Testing and documentation is performed as the product is built
o Provides the ability to declare the product done whenever required
 Process patterns defining development activities
o Backlog (prioritized list of requirements or features the provide business value to
customer, items can be added at any time)
o Sprints (work units required to achieve one of the backlog items, must fir into a
predefined time-box, affected backlog items frozen)
o Scrum meetings (15 minute daily meetings) addressing these questions: What was
done since last meeting? What obstacles were encountered? What will be done
by the next meeting?
o Demos (deliver software increment to customer for evaluation)
Crystal
 Development approach that puts a premium on maneuverability during a resource-
limited game of invention and communication with the primary goal of delivering useful
software and a secondary goal of setting up for the next game
 Crystal principles
o Its always cheaper and faster to communicate face-to-face
o As methodologies become more formal teams become weighed down and have
trouble adapting to project work vagaries
o As projects grow in size, teams become larger and methodologies become heavier
o As projects grow in criticality some degree of formality will need to be introduced
in parts of the methodology
o As feedback and communication become more efficient the need for
intermediate work products is reduced
o Discipline, skills, and understanding counter process, formality, and
documentation
o Team members not on the critical project path can spend their excess time
improving the product or helping people who are on the critical path
 Incremental development strategy used with 1 to 3 month time lines

DIWAKAR EDUCATION HUB Page 29

 SOFTWARE ENGINEERING UNIT – 6
 Reflection workshops conducted before project begins, during increment development
activity, and after increment is delivered
 Crystal methodologies
o Clear (small, low criticality projects)
o Orange (larger, moderately critical projects)
o Orange Web (typical e-business applications)
Feature Driven Development
 Practical process model for object-oriented software engineering
 Feature is a client-valued function, can be implemented in two weeks or less
 FDD Philosophy
o Emphasizes collaboration among team members
o Manages problem and project complexity using feature-based decomposition
followed integration of software increments
o Technical communication using verbal, graphical, and textual means
o Software quality encouraged by using incremental development, design and code
inspections, SQA audits, metric collection, and use of patterns (analysis, design,
construction)
 Framework activities
o Develop overall model (contains set of classes depicting business model of
application to be built)
o Build features list (features extracted from domain model, features are
categorized and prioritized, work is broken up into two week chunks)
o Plan by feature (features assessed based on priority, effort, technical issues,
schedule dependencies)
o Design by feature (classes relevant to feature are chosen, class and method
prologs are written, preliminary design detail developed, owner assigned to each
class, owner responsible for maintaining design document for his or her own work
packages)
o Build by feature (class owner translates design into source code and performs unit
testing, integration performed by chief programmer)
Agile Modeling
 Practice-based methodology for effective modeling and documentation of software
systems in a light-weight manner
 Modeling principles
o Model with a purpose
o Use multiple models
o Travel light (only keep models with long-term value)
o Content is more important than representation
o Know the models and tools you use to create them
o Adapt locally

DIWAKAR EDUCATION HUB Page 30

 SOFTWARE ENGINEERING UNIT – 6
 Requirements gathering and analysis modeling
o Work collaboratively to find out what customer wants to do
o Once requirements model is built collaborative analysis modeling continues with
the customer
 Architectural modeling
o Derives preliminary architecture from analysis model
o Architectural model must be realistic for the environment and must be
understandable by developers
Requirement Modeling
Following are the requirement modeling strategies:
1. Flow Oriented Modeling
2. Class-based Modeling
1. Flow Oriented Modeling
It shows how data objects are transformed by processing the function.
The Flow oriented elements are:
i. Data flow model
 It is a graphical technique. It is used to represent information flow.
 The data objects are flowing within the software and transformed by processing the
elements.
 The data objects are represented by labeled arrows. Transformation are represented by
circles called as bubbles.
 DFD shown in a hierarchical fashion. The DFD is split into different levels. It also called as
'context level diagram'.
ii. Control flow model
 Large class applications require a control flow modeling.
 The application creates control information instated of reports or displays.
 The applications process the information in specified time.
 An event is implemented as a boolean value.
For example, the boolean values are true or false, on or off, 1 or 0.
iii. Control Specification
 A short term for control specification is CSPEC.
 It represents the behaviour of the system.
 The state diagram in CSPEC is a sequential specification of the behaviour.
 The state diagram includes states, transitions, events and activities.
 State diagram shows the transition from one state to another state if a particular event
has occurred.
iv. Process Specification
 A short term for process specification is PSPEC.
 The process specification is used to describe all flow model processes.

DIWAKAR EDUCATION HUB Page 31

 SOFTWARE ENGINEERING UNIT – 6
 The content of process specification consists narrative text, Program Design
Language(PDL) of the process algorithm, mathematical equations, tables or UML activity
diagram.
2. Class-based Modeling
 Class based modeling represents the object. The system manipulates the operations.
 The elements of the class based model consist of classes and object, attributes,
operations, class – responsibility - collaborator (CRS) models.
Classes
Classes are determined using underlining each noun or noun clause and enter it into the
simple table.

Classes are found in following forms:

 External entities: The system, people or the device generates the information that is
used by the computer based system.
 Things: The reports, displays, letter, signal are the part of the information domain or the
problem.
 Occurrences or events: A property transfer or the completion of a series or robot
movements occurs in the context of the system operation.
 Roles: The people like manager, engineer, salesperson are interacting with the system.
 Organizational units: The division, group, team are suitable for an application.
 Places: The manufacturing floor or loading dock from the context of the problem and
the overall function of the system.
 Structures: The sensors, computers are defined a class of objects or related classes of
objects.
Attributes
Attributes are the set of data objects that are defining a complete class within the context of
the problem.
For example, 'employee' is a class and it consists of name, Id, department, designation and
salary of the employee are the attributes.

Operations
The operations define the behaviour of an object.

The operations are characterized into following types:

 The operations manipulate the data like adding, modifying, deleting and displaying etc.
 The operations perform a computation.
 The operation monitors the objects for the occurrence of controlling an event.
CRS Modeling
 The CRS stands for Class-Responsibility-Collaborator.
 It provides a simple method for identifying and organizing the classes that are applicable
to the system or product requirement.

DIWAKAR EDUCATION HUB Page 32

 SOFTWARE ENGINEERING UNIT – 6
 Class is an object-oriented class name. It consists of information about sub classes and
super class.
 Responsibilities are the attributes and operations that are related to the class.
 Collaborations are identified and determined when a class can achieve each
responsibility of it. If the class cannot identify itself, then it needs to interact with
another class.
Behavioral patterns for requirement modeling
Behavioral model shows the response of software to an external event.

Steps for creating behavioral patterns for requirement modeling as follows:

 Evaluate all the use cases to completely understand the sequence, interaction within
the system.
 Identify the event and understand the relation between the specific event.
 Generate a sequence for each use case.
 Construct a state diagram for the system.
 To verify the accuracy and consistency review the behavioral model.
Software Requirement Specification (SRS)
 The requirements are specified in specific format known as SRS.
 This document is created before starting the development work.
 The software requirement specification is an official document.
 It shows the detail about the performance of expected system.
 SRS indicates to a developer and a customer what is implemented in the software.
 SRS is useful if the software system is developed by the outside contractor.
 SRS must include an interface, functional capabilities, quality, reliability, privacy etc.
Characteristics of SRS
 The SRS should be complete and consistence.
 The modification like logical and hierarchical must be allowed in SRS.
 The requirement should be easy to implement.
 Each requirement should be uniquely identified.
 The statement in SRS must be unambiguous means it should have only one meaning.
 All the requirement must be valid for the specified project.
Requirements Review
The requirements review is an opportunity to check the requirements document for errors
and omissions, and confirm that the overall quality of the requirements is acceptable before
the project proceeds. It is also one final opportunity to communicate and confirm project
requirements with all stakeholders.
While stakeholders may complain that they are too busy to attend, requirements reviews are
crucial. Simply sending the document out for review will likely lead to rubber stamping by busy
people, although a formal signoff can still happen following the requirements review meeting.

DIWAKAR EDUCATION HUB Page 33

 SOFTWARE ENGINEERING UNIT – 6
Since some important stakeholders may not even really know what they are looking at, they
need guidance to effectively understand the requirements.
There are many benefits of a face-to-face review meeting.
 The discussion among the broader team to validate the clarity and accuracy of
requirements is likely to be higher quality than individuals independently reviewing the
requirements document.
 It ties the web of requirements together in everyone’s minds as they discuss the
complete requirements in context.
 Stakeholders align around the scope and confirm the requirements are clear enough
that they all interpret them the same way. They also gain an understanding of how the
requirements affect them.
 Stakeholders who may not be knowledgeable about requirements gathering, authoring,
and reviewing will be educated in the process. This may not be important for the project
at hand, but it facilitates long-term knowledge transfer and retention.
Some benefits can be enhanced both before and during the review by tools like QVscribe:
 Improving the quality of requirements
 Finding redundancies and similarities between requirements
 Improving the consistency of the requirements
 Generate configurable, shareable reports
Steps in the review process
1. Decide how to conduct the review
There are several things to consider as you decide how the review will be conducted.
Will the review be formal or informal?
Depending on project complexity, stakeholder maturity, and organizational culture, the review
process can be conducted either formally or informally. In a formal review, the project team
steps through each requirement with the stakeholders and explains the implications one-by-
one. An informal review is more relaxed in its depth and is generally better suited to
stakeholders who are very familiar with the process.
Will the review be broad or focused?
In a broad review, the entire team reviews the entire document. A broad review is usually best
for smaller documents. In a focused review, different parts of the document are distributed
among different teams so the review is a less overwhelming task. This approach can also be
useful if different stakeholders are affected by different parts of the requirements document.
Of course, it is easier to miss the big picture and potentially conflicting requirements when the
review is divided. You will likely still want a broad review of the entire document following
focused reviews, but it will go faster knowing that the details have already been reviewed. A
QVscribe report can give you an added level of confidence in the cohesiveness of large
requirements documents.
Will the review be onsite or offsite?
Consider holding the review meeting offsite. While this likely involves the cost of renting
meeting space and can be less convenient, it offers the opportunity for participants to be more

DIWAKAR EDUCATION HUB Page 34

 SOFTWARE ENGINEERING UNIT – 6
focused. They will not have the ability to wander off to their desks or to other meetings or to
be caught in the hallway by other employees with questions.
Will the review be face-to-face or involve remote meetings?
Without a doubt, face-to-face meetings are always better. But there are almost certainly
stakeholders distributed around the country – or even around the world. If remote meetings
are the only option, check that necessary communication and screen sharing technology is
available and functions well. One option to consider for dispersed participants is to meet face-
to-face in an airport hub city. Although this means everyone must travel, it also means all
participants can get a non-stop flight. Many airports even have meeting space available for
rental right at the airport.
2. Identify the participants and schedule the meeting
It is essential to identify the right participants for the review. Take the time to do this well.
Look back at your stakeholder register. Assuming you have kept this current throughout the
project, it will make it easy to generate your participant list and ensure the proper cross-
section of stakeholders.
Consider how best to get representation from each department or function, from the shop
floor users to management, and one personality type to another. Be sure there are people
with different skills, backgrounds, and knowledge in the review. Wide representation is best so
as many stakeholders as possible are involved and no viewpoint or input is missed.
In most organizations, it is difficult to find a time when all participants are available for a
lengthy review. Schedule the meeting as far in advance as possible to allow all key
stakeholders to attend.
Software Design And Implementation
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.
For assessing user requirements, an SRS (Software Requirement Specification) document is
created whereas for coding and implementation, there is a need of more specific and detailed
requirements in software terms. The output of this process can directly be used into
implementation in programming languages.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.
The implementation phase is the process of converting a system specification into an
executable system. If an incremental approach is used, it may also involve refinement of the
software specification.
A software design is a description of the structure of the software to be implemented, data
models, interfaces between system components, and maybe the algorithms used.
The software designers develop the software design iteratively; they add formality and detail
and correct the design as they develop their design.
Here’s an abstract model of the design process showing the inputs, activities, and the
documents to be produced as output.

DIWAKAR EDUCATION HUB Page 35

 SOFTWARE ENGINEERING UNIT – 6

The software design process

The diagram suggests that the stages of the design process are sequential. In fact, they are
interleaved. A feedback from one stage to another and rework can’t be avoided in any design
process.
These activities can vary depending on the type of the system needs to be developed. We’ve
showed four main activities that may be part of the design process for information systems,
and they are:
1. Architectural design: It defines the overall structure of the system, the main
components, their relationships.
2. Interface design: It defines the interfaces between these components. The interface
specification must be clear. Therefore, a component can be used without having to
know it’s implemented. Once the interface specification are agreed, the components
can be designed and developed concurrently.
3. Component design: Take each component and design how it will operate, with the
specific design left to the programmer, or a list of changes to be made to
a reusable component.
4. Database design: The system data structures are designed and their representation in a
database is defined. This depends on whether an existing database is to be reused or a
new database to be created.
These activities lead to a set of design outputs. The detail and representation vary based on
the system being developed.
For example, in critical systems, detailed design documents giving a precise and accurate
description of the system must be produced.
These outputs may be graphical models of the system, and in many cases, automatically
generating code from these models.

DIWAKAR EDUCATION HUB Page 36

 SOFTWARE ENGINEERING UNIT – 6
Software Design Levels
Software design yields three levels of results:
 Architectural Design - The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of proposed solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple component’
concept of architectural design into less-abstracted view of sub-systems and modules
and depicts their interaction with each other. High-level design focuses on how the
system along with all of its components can be implemented in forms of modules. It
recognizes modular structure of each sub-system and their relation and interaction
among each other.
 Detailed Design- Detailed design deals with the implementation part of what is seen as
a system and its sub-systems in the previous two designs. It is more detailed towards
modules and their implementations. It defines logical structure of each module and
their interfaces to communicate with other modules.
Modularization
Modularization is a technique to divide a software system into multiple discrete and
independent modules, which are expected to be capable of carrying out task(s) independently.
These modules may work as basic constructs for the entire software. Designers tend to design
modules such that they can be executed and/or compiled separately and independently.
Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software.
Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
Concurrency
Back in time, all software are meant to be executed sequentially. By sequential execution we
mean that the coded instruction will be executed one after another implying only one portion
of program being activated at any given time. Say, a software has multiple modules, then only
one of all the modules can be found active at any time of execution.
In software design, concurrency is implemented by splitting the software into multiple
independent units of execution, like modules and executing them in parallel. In other words,
concurrency provides capability to the software to execute more than one part of code in
parallel to each other.
It is necessary for the programmers and designers to recognize those modules, which can be
made parallel execution.

DIWAKAR EDUCATION HUB Page 37

 SOFTWARE ENGINEERING UNIT – 6
Example
The spell check feature in word processor is a module of software, which runs along side the
word processor itself.
Coupling and Cohesion
When a software program is modularized, its tasks are divided into several modules based on
some characteristics. As we know, modules are set of instructions put together in order to
achieve some tasks. They are though, considered as single entity but may refer to each other
to work together. There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling and cohesion.
Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module. The greater the cohesion, the better is the program design.
There are seven types of cohesion, namely –
 Co-incidental cohesion - It is unplanned and random cohesion, which might be the
result of breaking the program into smaller modules for the sake of modularization.
Because it is unplanned, it may serve confusion to the programmers and is generally
not-accepted.
 Logical cohesion - When logically categorized elements are put together into a module,
it is called logical cohesion.
 Temporal Cohesion - When elements of module are organized such that they are
processed at a similar point in time, it is called temporal cohesion.
 Procedural cohesion - When elements of module are grouped together, which are
executed sequentially in order to perform a task, it is called procedural cohesion.
 Communicational cohesion - When elements of module are grouped together, which
are executed sequentially and work on same data (information), it is called
communicational cohesion.
 Sequential cohesion - When elements of module are grouped because the output of
one element serves as input to another and so on, it is called sequential cohesion.
 Functional cohesion - It is considered to be the highest degree of cohesion, and it is
highly expected. Elements of module in functional cohesion are grouped because they
all contribute to a single well-defined function. It can also be reused.

Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a
program. It tells at what level the modules interfere and interact with each other. The lower
the coupling, the better the program.
There are five levels of coupling, namely -
 Content coupling - When a module can directly access or modify or refer to the content
of another module, it is called content level coupling.

DIWAKAR EDUCATION HUB Page 38

 SOFTWARE ENGINEERING UNIT – 6
 Common coupling- When multiple modules have read and write access to some global
data, it is called common or global coupling.
 Control coupling- Two modules are called control-coupled if one of them decides the
function of the other module or changes its flow of execution.
 Stamp coupling- When multiple modules share common data structure and work on
different part of it, it is called stamp coupling.
 Data coupling- Data coupling is when two modules interact with each other by means of
passing data (as parameter). If a module passes data structure as parameter, then the
receiving module should use all its components.
Ideally, no coupling is considered to be the best.
Design Verification
The output of software design process is design documentation, pseudo codes, detailed logic
diagrams, process diagrams, and detailed description of all functional or non-functional
requirements.
The next phase, which is the implementation of software, depends on all outputs mentioned
above.
It is then becomes necessary to verify the output before proceeding to the next phase. The
early any mistake is detected, the better it is or it might not be detected until testing of the
product. If the outputs of design phase are in formal notation form, then their associated tools
for verification should be used otherwise a thorough design review can be used for verification
and validation.
By structured verification approach, reviewers can detect defects that might be caused by
overlooking some conditions. A good design review is important for good software design,
accuracy and quality.
Object-Oriented Design
After the analysis phase, the conceptual model is developed further into an object-oriented
model using object-oriented design (OOD). In OOD, the technology-independent concepts in
the analysis model are mapped onto implementing classes, constraints are identified, and
interfaces are designed, resulting in a model for the solution domain. In a nutshell, a detailed
description is constructed specifying how the system is to be built on concrete technologies
The stages for object–oriented design can be identified as −
 Definition of the context of the system
 Designing system architecture
 Identification of the objects in the system
 Construction of design models
 Specification of object interfaces
System Design
Object-oriented system design involves defining the context of a system followed by designing
the architecture of the system.
 Context − The context of a system has a static and a dynamic part. The static context of
the system is designed using a simple block diagram of the whole system which is

DIWAKAR EDUCATION HUB Page 39

 SOFTWARE ENGINEERING UNIT – 6
expanded into a hierarchy of subsystems. The subsystem model is represented by UML
packages. The dynamic context describes how the system interacts with its
environment. It is modelled using use case diagrams.
 System Architecture − The system architecture is designed on the basis of the context of
the system in accordance with the principles of architectural design as well as domain
knowledge. Typically, a system is partitioned into layers and each layer is decomposed
to form the subsystems.
Object-Oriented Decomposition
Decomposition means dividing a large complex system into a hierarchy of smaller components
with lesser complexities, on the principles of divide–and–conquer. Each major component of
the system is called a subsystem. Object-oriented decomposition identifies individual
autonomous objects in a system and the communication among these objects.
The advantages of decomposition are −
 The individual components are of lesser complexity, and so more understandable and
manageable.
 It enables division of workforce having specialized skills.
 It allows subsystems to be replaced or modified without affecting other subsystems.
Identifying Concurrency
Concurrency allows more than one objects to receive events at the same time and more than
one activity to be executed simultaneously. Concurrency is identified and represented in the
dynamic model.
To enable concurrency, each concurrent element is assigned a separate thread of control. If
the concurrency is at object level, then two concurrent objects are assigned two different
threads of control. If two operations of a single object are concurrent in nature, then that
object is split among different threads.
Concurrency is associated with the problems of data integrity, deadlock, and starvation. So a
clear strategy needs to be made whenever concurrency is required. Besides, concurrency
requires to be identified at the design stage itself, and cannot be left for implementation
stage.
Identifying Patterns
While designing applications, some commonly accepted solutions are adopted for some
categories of problems. These are the patterns of design. A pattern can be defined as a
documented set of building blocks that can be used in certain types of application
development problems.
Some commonly used design patterns are −
 Façade pattern
 Model view separation pattern
 Observer pattern
 Model view controller pattern
 Publish subscribe pattern
 Proxy pattern

DIWAKAR EDUCATION HUB Page 40

 SOFTWARE ENGINEERING UNIT – 6
Controlling Events
During system design, the events that may occur in the objects of the system need to be
identified and appropriately dealt with.
An event is a specification of a significant occurrence that has a location in time and space.
There are four types of events that can be modelled, namely −
 Signal Event − A named object thrown by one object and caught by another object.
 Call Event − A synchronous event representing dispatch of an operation.
 Time Event − An event representing passage of time.
 Change Event − An event representing change in state.
Handling Boundary Conditions
The system design phase needs to address the initialization and the termination of the system
as a whole as well as each subsystem. The different aspects that are documented are as
follows −
 The start–up of the system, i.e., the transition of the system from non-initialized state to
steady state.
 The termination of the system, i.e., the closing of all running threads, cleaning up of
resources, and the messages to be sent.
 The initial configuration of the system and the reconfiguration of the system when
needed.
 Foreseeing failures or undesired termination of the system.
Boundary conditions are modelled using boundary use cases.
Object Design
After the hierarchy of subsystems has been developed, the objects in the system are identified
and their details are designed. Here, the designer details out the strategy chosen during the
system design. The emphasis shifts from application domain concepts toward computer
concepts. The objects identified during analysis are etched out for implementation with an aim
to minimize execution time, memory consumption, and overall cost.
Object design includes the following phases −
 Object identification
 Object representation, i.e., construction of design models
 Classification of operations
 Algorithm design
 Design of relationships
 Implementation of control for external interactions
 Package classes and associations into modules
Object Identification
The first step of object design is object identification. The objects identified in the object–
oriented analysis phases are grouped into classes and refined so that they are suitable for
actual implementation.
The functions of this stage are −

DIWAKAR EDUCATION HUB Page 41

 SOFTWARE ENGINEERING UNIT – 6
 Identifying and refining the classes in each subsystem or package
 Defining the links and associations between the classes
 Designing the hierarchical associations among the classes, i.e., the
generalization/specialization and inheritances
 Designing aggregations
Object Representation
Once the classes are identified, they need to be represented using object modelling
techniques. This stage essentially involves constructing UML diagrams.
There are two types of design models that need to be produced −
 Static Models − To describe the static structure of a system using class diagrams and
object diagrams.
 Dynamic Models − To describe the dynamic structure of a system and show the
interaction between classes using interaction diagrams and state–chart diagrams.
Classification of Operations
In this step, the operation to be performed on objects are defined by combining the three
models developed in the OOA phase, namely, object model, dynamic model, and functional
model. An operation specifies what is to be done and not how it should be done.
The following tasks are performed regarding operations −
 The state transition diagram of each object in the system is developed.
 Operations are defined for the events received by the objects.
 Cases in which one event triggers other events in same or different objects are
identified.
 The sub–operations within the actions are identified.
 The main actions are expanded to data flow diagrams.
Algorithm Design
The operations in the objects are defined using algorithms. An algorithm is a stepwise
procedure that solves the problem laid down in an operation. Algorithms focus on how it is to
be done.
There may be more than one algorithm corresponding to a given operation. Once the
alternative algorithms are identified, the optimal algorithm is selected for the given problem
domain. The metrics for choosing the optimal algorithm are −
 Computational Complexity − Complexity determines the efficiency of an algorithm in
terms of computation time and memory requirements.
 Flexibility − Flexibility determines whether the chosen algorithm can be implemented
suitably, without loss of appropriateness in various environments.
 Understandability − This determines whether the chosen algorithm is easy to
understand and implement.
Design of Relationships
The strategy to implement the relationships needs to be chalked out during the object design
phase. The main relationships that are addressed comprise of associations, aggregations, and
inheritances.
DIWAKAR EDUCATION HUB Page 42
 SOFTWARE ENGINEERING UNIT – 6
The designer should do the following regarding associations −
 Identify whether an association is unidirectional or bidirectional.
 Analyze the path of associations and update them if necessary.
 Implement the associations as a distinct object, in case of many–to-many relationships;
or as a link to other object in case of one–to-one or one–to-many relationships.
Regarding inheritances, the designer should do the following −
 Adjust the classes and their associations.
 Identify abstract classes.
 Make provisions so that behaviors are shared when needed.
Implementation of Control
The object designer may incorporate refinements in the strategy of the state–chart model. In
system design, a basic strategy for realizing the dynamic model is made. During object design,
this strategy is aptly embellished for appropriate implementation.
The approaches for implementation of the dynamic model are −
 Represent State as a Location within a Program − This is the traditional procedure-
driven approach whereby the location of control defines the program state. A finite
state machine can be implemented as a program. A transition forms an input statement,
the main control path forms the sequence of instructions, the branches form the
conditions, and the backward paths form the loops or iterations.
 State Machine Engine − This approach directly represents a state machine through a
state machine engine class. This class executes the state machine through a set of
transitions and actions provided by the application.
 Control as Concurrent Tasks − In this approach, an object is implemented as a task in
the programming language or the operating system. Here, an event is implemented as
an inter-task call. It preserves inherent concurrency of real objects.
Packaging Classes
In any large project, meticulous partitioning of an implementation into modules or packages is
important. During object design, classes and objects are grouped into packages to enable
multiple groups to work cooperatively on a project.
The different aspects of packaging are −
 Hiding Internal Information from Outside View − It allows a class to be viewed as a
“black box” and permits class implementation to be changed without requiring any
clients of the class to modify code.
 Coherence of Elements − An element, such as a class, an operation, or a module, is
coherent if it is organized on a consistent plan and all its parts are intrinsically related so
that they serve a common goal.
 Construction of Physical Modules − The following guidelines help while constructing
physical modules −
o Classes in a module should represent similar things or components in the same
composite object.
o Closely connected classes should be in the same module.

DIWAKAR EDUCATION HUB Page 43

 SOFTWARE ENGINEERING UNIT – 6
o Unconnected or weakly connected classes should be placed in separate modules.
o Modules should have good cohesion, i.e., high cooperation among its
components.
o A module should have low coupling with other modules, i.e., interaction or
interdependence between modules should be minimum.
Design Optimization
The analysis model captures the logical information about the system, while the design model
adds details to support efficient information access. Before a design is implemented, it should
be optimized so as to make the implementation more efficient. The aim of optimization is to
minimize the cost in terms of time, space, and other metrics.
However, design optimization should not be excess, as ease of implementation,
maintainability, and extensibility are also important concerns. It is often seen that a perfectly
optimized design is more efficient but less readable and reusable. So the designer must strike
a balance between the two.
The various things that may be done for design optimization are −
 Add redundant associations
 Omit non-usable associations
 Optimization of algorithms
 Save derived attributes to avoid re-computation of complex expressions
Addition of Redundant Associations
During design optimization, it is checked if deriving new associations can reduce access costs.
Though these redundant associations may not add any information, they may increase the
efficiency of the overall model.
Omission of Non-Usable Associations
Presence of too many associations may render a system indecipherable and hence reduce the
overall efficiency of the system. So, during optimization, all non-usable associations are
removed.
Optimization of Algorithms
In object-oriented systems, optimization of data structure and algorithms are done in a
collaborative manner. Once the class design is in place, the operations and the algorithms
need to be optimized.
Optimization of algorithms is obtained by −
 Rearrangement of the order of computational tasks
 Reversal of execution order of loops from that laid down in the functional model
 Removal of dead paths within the algorithm
Saving and Storing of Derived Attributes
Derived attributes are those attributes whose values are computed as a function of other
attributes (base attributes). Re-computation of the values of derived attributes every time
they are needed is a time–consuming procedure. To avoid this, the values can be computed
and stored in their computed forms.

DIWAKAR EDUCATION HUB Page 44

 SOFTWARE ENGINEERING UNIT – 6
However, this may pose update anomalies, i.e., a change in the values of base attributes with
no corresponding change in the values of the derived attributes. To avoid this, the following
steps are taken −
 With each update of the base attribute value, the derived attribute is also re-computed.
 All the derived attributes are re-computed and updated periodically in a group rather
than after each update.
Design Documentation
Documentation is an essential part of any software development process that records the
procedure of making the software. The design decisions need to be documented for any non–
trivial software system for transmitting the design to others.
Usage Areas
Though a secondary product, a good documentation is indispensable, particularly in the
following areas −
 In designing software that is being developed by a number of developers
 In iterative software development strategies
 In developing subsequent versions of a software project
 For evaluating a software
 For finding conditions and areas of testing
 For maintenance of the software.
Contents
A beneficial documentation should essentially include the following contents −
 High–level system architecture − Process diagrams and module diagrams
 Key abstractions and mechanisms − Class diagrams and object diagrams.
 Scenarios that illustrate the behavior of the main aspects − Behavioural diagrams
Features
The features of a good documentation are −
 Concise and at the same time, unambiguous, consistent, and complete
 Traceable to the system’s requirement specifications
 Well-structured
 Diagrammatic instead of descriptive
Data Design
The data design action translates data defined as part of the analysis model into data
structures at the software component level and. When necessary into a database architecture
at the application level.

a) Data Design at the Architectural Level

The challenge in data design is to extract useful information from this data environment,
particularly when the information desired is cross-functional.
To solve this challenge, the business IT community has developed data mining techniques, also
called knowledge discovery in database (KDD) , that navigate through existing databases in an
DIWAKAR EDUCATION HUB Page 45
 SOFTWARE ENGINEERING UNIT – 6
attempt to extract appropriate business-level information. An alternative solution, called a
data warehouse, adds an additional layer to the data architecture.

A data warehouse is a separate data environment that is not directly integrated with day –to-
day application but encompasses all data used by a business.

b) Data Design at the Component Level

Data design at the component level focuses on the representation of the data structures that
are directly accessed by one or more software components. We consider the following set of
principles (adapted from for data specification):

1. The systematic analysis principles applied to function and behavior should also be applied to
data.
2. All data structure and the operations to be performed on each should be identified.
3. A mechanism for defining the content of each data object should be established and used to
define both data and the operation applied it.
4. Low-level design decision should be known only to those modules that must make direct
use of the data contained within the structure.
5. The representation of a data structure should be known only to those modules that must
make direct use of the data contained within the structure.
6. A library of useful data structures and the operations that may be applied to them should be
developed.
7. A software design and programming language should support the specification and
realization of abstract data types.
Architectural Styles
The software that is built for computer- based systems also exhibits one of many architectural
styles. Each styles describes a system category that encompasses (1) a set of components that
performs a function required by a system; (2) a set of connectors that enables
“communication, coordination and cooperation “between components; (3) constraints that
define how components can be integrated to form the system, and (4) semantic models that
enable a designer to understand the overall properties of a system by analyzing the unknown
properties of its constituent parts.

a) Data-centered architecture. A data store (e.g., a file or database) resides at the center of
this architecture and is accessed frequently by other components that update, add, delete, or
otherwise modify data within the store. Figure 4 .1 illustrates a typical data- centered style.
Client software accesses a central repository.

b) Data-flow architecture. The architecture is applied when input data are to be transformed
through a series of computational or manipulate components into output data. A pipe and
filter structure in figure 4.2 has a set of components, called filters, connected by pips that
transmit data from one component to accept data input of a certain form , and produces data

DIWAKAR EDUCATION HUB Page 46

 SOFTWARE ENGINEERING UNIT – 6
output ( to the next filters) of a specified form. However, the filter does not require knowledge
of the workings of its neighboring filters.

c) Call and return architecture. This architectural style enables a software designer (system
architect) to achieve a program structure that is relatively easy to modify and scale. Two sub
styles within category:

• Main programs/ subprograms architecture. This classic program structure decomposes

functions into a control hierarchy where a “main” program invokes a number of program
components, which in turn may invoke still other components.
• Remote procedure called architecture. The components of a main program/sub- program
architecture are distributed across multiple computers on a network.

d) Object-oriented architecture. The components of a system encapsulate data and the

operations that must be applied to manipulate the data. Communication and coordination
between components is accomplished via message passing.

e) Architectural Design. As architectural design begins, the software to be developed must be

put into context that is, the design should define the external entities that the software
interacts with and the nature of the interactions. Once context is modeled and all external
software interfaces have been described, the designer specifies the structure of the system by
defining and refining software components that implement the architecture. This process
continues iteratively until complete architectural structure has been derived.

f) Defining Archetypes. An archetypes is a class or pattern that represents a core abstraction

that is critical to the design of architecture for the target system.

Archetypes can be derived by examining the analysis model. Continuing our discussion of the
safehome home security function, we might define the following archetypes.

• Node. Represents a cohesive collection of input and output elements of the home security
function. For example a node might be comprised of (1) various sensors and (2) a variety of
alarm (output) indications.
• Detector. An abstraction that represents all mechanism s (e.g., alarm siren. Flashing lights,
bell) for indicating that an alarm condition is occurring.
• Controller. An abstraction that depicts the mechanism that allows the aiming or disarming of
a node. If controllers reside on a network, they have the ability to communicate with one
another.

g) Refining the Architecture into components. As the software architecture is refined in to

components, the structure of the system begins to emerge. These analysis classes represents
entities within the application domain is one source for the derivation and refinement of
components. Another source is the infrastructure domain. The architecture must

DIWAKAR EDUCATION HUB Page 47

 SOFTWARE ENGINEERING UNIT – 6
accommodate many infrastructure components that enable application components.

Continuing the safehome home security function example, we might define the set of top-level
components that address the following functionally:

• External communication management—coordinates communication of the security function

with external entities, for example, Internal based system, external alarm notification.
• Control panel processing- manages all control panel functionally.
• Detector management- coordinates access to all detectors attached to the system.
• Alarm processing-verifies and acts on all alarm conditions.

The design details of all attributes and operations would not be specified until components-
level design, is generated.
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.

DIWAKAR EDUCATION HUB Page 48

 SOFTWARE ENGINEERING UNIT – 6

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.

These principles form a basis for a component-level data design approach that can be
integrated into both the analysis and design activities.
Architectural Design
Objective: Architectural design tools model the overall software structure by representing
component interfaces, dependencies and relationships, and interactions.

Mechanics: Tools mechanics vary. In most cases, architectural design capability is part of the
functionality provided by automated tools for analysis and design modeling.

Representative Tools:
Adalon, developed by Synthis Corp. ([Link]), is a specialized design tool for the
design and construction of specific Web-based component architectures.

ObjectiF, developed mico Tools GmbH ([Link]), is a UML-based design tool that
leads to architectures (e.g., Coldfusion, j2EE, Fusebox) amenable to component- based
software engineering.

Rational Rose, developed by Rational ([Link] is a UML- based design tool that support all
DIWAKAR EDUCATION HUB Page 49
 SOFTWARE ENGINEERING UNIT – 6
aspects of architectural design).

Pattern–Based Software Design:

The best designers in any field have an uncanny ability to see patterns that characterize a
problem and corresponding patterns that can be combined to create a solution. Throughout
the design process, a software engineer should look for every opportunity to reuse existing
design patterns (when they meet the needs of the design) rather than creating new ones.

Describing a Design Pattern

Mature engineering disciplines make use of thousands of design patterns, For example, a
mechanical engineer uses a two- step, keyed shaft as a design pattern. Inherent in the pattern
are attributes (the diameters of the shaft, the dimensions of the keyway, etc.) and operations
(e.g., shaft rotation, shaft connection). An electrical engineer uses an integrated circuit (an
extremely complex design pattern) to solve a specific element of a new problem. Design
patterns may be described using the template shown in the sidebar.

Design Pattern Template:

Pattern name describes the essence of the pattern in a short but expressive name.

Intent - describes the pattern and what it does.

Also - known - as - lists any synonyms for the pattern.

Motivation - provides an example of the problem.

Applicability – notes specific design situations in which the pattern is applicable.

Structure - describes the responsibilities of the classes that are required to implement the
pattern.

Participants - describes the responsibilities of the classes that are required to implement the
pattern.

Collaborations - describes the responsibilities of the classes that are required to implement the
pattern.

Collaborations – describes how the participants collaborate to carry out their responsibilities.

Consequences - describes the “design forces” that affect the pattern and the potential trade-
offs that must be considered when the pattern is implemented.

Related Patterns - cross- references related design patterns.

DIWAKAR EDUCATION HUB Page 50

 SOFTWARE ENGINEERING UNIT – 6

A description of the design pattern may also consider a set of design forces. Design forces
describe non- functional requirements (e.g., ease of maintainability, portability) associated
with the software for which the pattern is to applied. In addition forces define the constraints
that may restrict the manner in which the design is to be implemented. In essence, design
forces describe the environment and conditions that must exist to make the design pattern
applicable. The pattern characteristics (classes, responsibilities, and collaborations) indicate
the attributes of the design that may be adjusted to enable the pattern to accommodate a
variety of problems. These attributes represent characteristics of the design that can be
searched (e.g., via a database) so that an appropriate pattern can be found. Finally, guidance
associated with the use of a design pattern provides an indication of the ramifications of
design decisions.

Martin Fowler “patterns are half- baked—meaning you always have to finish them yourself
and adapt them to your own environment.”

The names of design patterns should be chosen with care. One of the key technical problems
in software reuse is the inability to find existing reusable patterns when hundreds or
thousands of candidate pattern exist. The search for the “right” pattern is aided immeasurably
by a meaningful pattern name.
Using Patterns in design
Design patterns can be used throughout software design. Once the analysis model has been
developed, the designer can examine a detailed representation of the problem to be solved
and the constraints that are imposed by the problem. The problem description is examined at
various levels of abstraction to determine if it is amenable to one or more of the following
types of design patterns:

Architectural patterns: These patterns define the overall structure of the software and
indicate the relationship among subsystems and software components, and ages,
components, subsystems) of the architecture.

Design patterns: These patterns address a specific element of the design such as an
aggregation of components to solve some design problem, among components, or the
mechanisms of effecting components-to-components communications.

Idioms: Sometimes called coding patterns, these language – specific patterns generally
implement an algorithmic element of a component, a specific protocol, or a mechanism for
communication among components.

Each of these pattern types differs in the level of abstraction with which it is represented and
the degree to which it provides direct guidance for the construction activity ( in this case,
coding) of the software process.

DIWAKAR EDUCATION HUB Page 51

 SOFTWARE ENGINEERING UNIT – 6
Frameworks:

In some cases it may be necessary to provide an implementation- specific skeletal

infrastructure, called a framework, for design work. That is, the designer may select a
“reusable mini- architecture that provides the generic structure and behavior for a family of
software abstractions, along with a context… which specifies their collaboration and use within
domain.”

A framework is not an architectural pattern, but rather a skeleton with a collection with a
collection of “plug points” (also called hooks and slots) that enables it to be adapted to specific
classes or functionality within the skeleton. In an object- oriented context, a framework is a
collection of cooperating classes.

In essence, the designer of a framework will argue that one reusable mini – architecture is
applicable to all software to be developed within a limited domain of application. To be most
effective, frameworks are applied with no changes. Additional design elements may be added,
but only via the plug points that allow the designer to flush out the framework skeleton.

Design engineering commences, as the first iteration of requirements engineering comes to a

conclusion. The intent of software design is to apply a set of principles, concepts, and practices
that lead to the development of a high- quality system or product. The goal design is to create
a model of software that will implement all customer requirements correctly and bring delight
to those who use it. Design engineers must shift through many design alternatives and
coverage on a solution that best suits the needs of project stakeholders.

The design process moves from a “big picture” view of software to a more narrow view that
defines the details required to implement a system. The process begins by focusing on
architecture. Subsystems are defined; communication mechanisms among subsystems are
established; components are identified; and a detailed description of each component is
developed. In addition, external, internal, and user interfaces are designed.

Design concepts have evolved over the first half-century of software engineering work. They
describe attributes of computer software that should be present regardless of the software
engineering process that is chosen, the design methods that are applied, or the programming
languages that are used.

The design model encompasses four different elements. As each of these elements is
developed, a more complete view of the design evolves. The architectural elements used
information derived from the application domain, the analysis model, and available catalogs
for patterns and styles to derive a complete structural representation of the software, its
subsystems and components. Interface design elements model external and internal interfaces
and the user interface. Component- level elements define each of the modules (components)
that populates the architecture. Finally, deployment- level design elements allocate the

DIWAKAR EDUCATION HUB Page 52

 SOFTWARE ENGINEERING UNIT – 6
architecture, its components, and the interfaces to the physical configuration that will house
the software.

Pattern- based design is a technique that ruses design elements that have proven successful in
the past. Each architectural pattern, design pattern, or idiom is cataloged, thoroughly
documented, and carefully considered as it assessed for inclusion in a specific application.
Frameworks, an extension of patterns, provide an architectural skeleton for the design of
complete subsystems within a specific application domain.
Graphical User Interface
Graphical User Interface provides the user graphical means to interact with the system. GUI
can be combination of both hardware and software. Using GUI, user interprets the software.
Typically, GUI is more resource consuming than that of CLI. With advancing technology, the
programmers and designers create complex GUI designs that work with more efficiency,
accuracy and speed.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Every graphical component provides a way to work with the system. A GUI system has
following elements such as:

 Window - An area where contents of application are displayed. Contents in a window

can be displayed in the form of icons or lists, if the window represents file structure. It is
easier for a user to navigate in the file system in an exploring window. Windows can be
minimized, resized or maximized to the size of screen. They can be moved anywhere on
the screen. A window may contain another window of the same application, called child
window.
 Tabs - If an application allows executing multiple instances of itself, they appear on the
screen as separate windows. Tabbed Document Interface has come up to open multiple
documents in the same window. This interface also helps in viewing preference panel in
application. All modern web-browsers use this feature.
DIWAKAR EDUCATION HUB Page 53
 SOFTWARE ENGINEERING UNIT – 6
 Menu - Menu is an array of standard commands, grouped together and placed at a
visible place (usually top) inside the application window. The menu can be programmed
to appear or hide on mouse clicks.
 Icon - An icon is small picture representing an associated application. When these icons
are clicked or double clicked, the application window is opened. Icon displays
application and programs installed on a system in the form of small pictures.
 Cursor - Interacting devices such as mouse, touch pad, digital pen are represented in
GUI as cursors. On screen cursor follows the instructions from hardware in almost real-
time. Cursors are also named pointers in GUI systems. They are used to select menus,
windows and other application features.
Application specific GUI components
A GUI of an application contains one or more of the listed GUI elements:
 Application Window - Most application windows uses the constructs supplied by
operating systems but many use their own customer created windows to contain the
contents of application.
 Dialogue Box - It is a child window that contains message for the user and request for
some action to be taken. For Example: Application generate a dialogue to get
confirmation from user to delete a file.

 Text-Box - Provides an area for user to type and enter text-based data.
 Buttons - They imitate real life buttons and are used to submit inputs to the software.

DIWAKAR EDUCATION HUB Page 54

 SOFTWARE ENGINEERING UNIT – 6
 Radio-button - Displays available options for selection. Only one can be selected among
all offered.
 Check-box - Functions similar to list-box. When an option is selected, the box is marked
as checked. Multiple options represented by check boxes can be selected.
 List-box - Provides list of available items for selection. More than one item can be
selected.

Other impressive GUI components are:

 Sliders
 Combo-box
 Data-grid
 Drop-down list
User Interface Design Activities
There are a number of activities performed for designing user interface. The process of GUI
design and implementation is alike SDLC. Any model can be used for GUI implementation
among Waterfall, Iterative or Spiral Model.
A model used for GUI design and development should fulfill these GUI specific steps.

DIWAKAR EDUCATION HUB Page 55

 SOFTWARE ENGINEERING UNIT – 6
 GUI Requirement Gathering - The designers may like to have list of all functional and
non-functional requirements of GUI. This can be taken from user and their existing
software solution.
 User Analysis - The designer studies who is going to use the software GUI. The target
audience matters as the design details change according to the knowledge and
competency level of the user. If user is technical savvy, advanced and complex GUI can
be incorporated. For a novice user, more information is included on how-to of software.
 Task Analysis - Designers have to analyze what task is to be done by the software
solution. Here in GUI, it does not matter how it will be done. Tasks can be represented
in hierarchical manner taking one major task and dividing it further into smaller sub-
tasks. Tasks provide goals for GUI presentation. Flow of information among sub-tasks
determines the flow of GUI contents in the software.
 GUI Design & implementation - Designers after having information about requirements,
tasks and user environment, design the GUI and implements into code and embed the
GUI with working or dummy software in the background. It is then self-tested by the
developers.
 Testing - GUI testing can be done in various ways. Organization can have in-house
inspection, direct involvement of users and release of beta version are few of them.
Testing may include usability, compatibility, user acceptance etc.
GUI Implementation Tools
There are several tools available using which the designers can create entire GUI on a mouse
click. Some tools can be embedded into the software environment (IDE).
GUI implementation tools provide powerful array of GUI controls. For software customization,
designers can change the code accordingly.
There are different segments of GUI tools according to their different use and platform.
Example
Mobile GUI, Computer GUI, Touch-Screen GUI etc. Here is a list of few tools which come handy
to build GUI:
 FLUID
 AppInventor (Android)
 LucidChart
 Wavemaker
 Visual Studio
User Interface Golden rules
The following rules are mentioned to be the golden rules for GUI design, described by
Shneiderman and Plaisant in their book (Designing the User Interface).
 Strive for consistency - Consistent sequences of actions should be required in similar
situations. Identical terminology should be used in prompts, menus, and help screens.
Consistent commands should be employed throughout.

DIWAKAR EDUCATION HUB Page 56

 SOFTWARE ENGINEERING UNIT – 6
 Enable frequent users to use short-cuts - The user’s desire to reduce the number of
interactions increases with the frequency of use. Abbreviations, function keys, hidden
commands, and macro facilities are very helpful to an expert user.
 Offer informative feedback - For every operator action, there should be some system
feedback. For frequent and minor actions, the response must be modest, while for
infrequent and major actions, the response must be more substantial.
 Design dialog to yield closure - Sequences of actions should be organized into groups
with a beginning, middle, and end. The informative feedback at the completion of a
group of actions gives the operators the satisfaction of accomplishment, a sense of
relief, the signal to drop contingency plans and options from their minds, and this
indicates that the way ahead is clear to prepare for the next group of actions.
 Offer simple error handling - As much as possible, design the system so the user will not
make a serious error. If an error is made, the system should be able to detect it and
offer simple, comprehensible mechanisms for handling the error.
 Permit easy reversal of actions - This feature relieves anxiety, since the user knows that
errors can be undone. Easy reversal of actions encourages exploration of unfamiliar
options. The units of reversibility may be a single action, a data entry, or a complete
group of actions.
 Support internal locus of control - Experienced operators strongly desire the sense that
they are in charge of the system and that the system responds to their actions. Design
the system to make users the initiators of actions rather than the responders.
 Reduce short-term memory load - The limitation of human information processing in
short-term memory requires the displays to be kept simple, multiple page displays be
consolidated, window-motion frequency be reduced, and sufficient training time be
allotted for codes, mnemonics, and sequences of actions
Software Quality
Software quality product is defined in term of its fitness of purpose. That is, a quality product
does precisely what the users want it to do. For software products, the fitness of use is
generally explained in terms of satisfaction of the requirements laid down in the SRS
document. Although "fitness of purpose" is a satisfactory interpretation of quality for many
devices such as a car, a table fan, a grinding machine, [Link] software products, "fitness of
purpose" is not a wholly satisfactory definition of quality.
Example: Consider a functionally correct software product. That is, it performs all tasks as
specified in the SRS document. But, has an almost unusable user interface. Even though it may
be functionally right, we cannot consider it to be a quality product.
The modern view of a quality associated with a software product several quality methods such
as the following:
Portability: A software device is said to be portable, if it can be freely made to work in various
operating system environments, in multiple machines, with other software products, etc.
Usability: A software product has better usability if various categories of users can easily
invoke the functions of the product.

DIWAKAR EDUCATION HUB Page 57

 SOFTWARE ENGINEERING UNIT – 6
Reusability: A software product has excellent reusability if different modules of the product
can quickly be reused to develop new products.
Correctness: A software product is correct if various requirements as specified in the SRS
document have been correctly implemented.
Maintainability: A software product is maintainable if bugs can be easily corrected as and
when they show up, new tasks can be easily added to the product, and the functionalities of
the product can be easily modified, etc.
Software Quality Management System
A quality management system is the principal methods used by organizations to provide that
the products they develop have the desired quality.
A quality system subsists of the following:
Managerial Structure and Individual Responsibilities: A quality system is the responsibility of
the organization as a whole. However, every organization has a sever quality department to
perform various quality system activities. The quality system of an arrangement should have
the support of the top management. Without help for the quality system at a high level in a
company, some members of staff will take the quality system seriously.
Quality System Activities: The quality system activities encompass the following:
Auditing of projects
Review of the quality system
Development of standards, methods, and guidelines, etc.
Production of documents for the top management summarizing the effectiveness of the
quality system in the organization.
Evolution of Quality Management System
Quality systems have increasingly evolved over the last five decades. Before World War II, the
usual function to produce quality products was to inspect the finished products to remove
defective devices. Since that time, quality systems of organizations have undergone through
four steps of evolution, as shown in the fig. The first product inspection task gave method to
quality control (QC).
Quality control target not only on detecting the defective devices and removes them but also
on determining the causes behind the defects. Thus, quality control aims at correcting the
reasons for bugs and not just rejecting the products. The next breakthrough in quality
methods was the development of quality assurance methods.
The primary premise of modern quality assurance is that if an organization's processes are
proper and are followed rigorously, then the products are obligated to be of good quality. The
new quality functions include guidance for recognizing, defining, analyzing, and improving the
production process.
Total quality management (TQM) advocates that the procedure followed by an organization
must be continuously improved through process measurements. TQM goes stages further
than quality assurance and aims at frequently process improvement. TQM goes beyond
documenting steps to optimizing them through a redesign. A term linked to TQM is Business
Process Reengineering (BPR).

DIWAKAR EDUCATION HUB Page 58

 SOFTWARE ENGINEERING UNIT – 6
BPR aims at reengineering the method business is carried out in an organization. From the
above conversation, it can be stated that over the years, the quality paradigm has changed
from product assurance to process assurance, as shown in fig.

Software Quality Factors

The various factors, which influence the software, are termed as software factors. They can be
broadly divided into two categories. The first category of the factors is of those that can be
measured directly such as the number of logical errors, and the second category clubs those
factors which can be measured only indirectly. For example, maintainability but each of the
factors is to be measured to check for the content and the quality control.
Several models of software quality factors and their categorization have been suggested over
the years. The classic model of software quality factors, suggested by McCall, consists of 11
factors (McCall et al., 1977). Similarly, models consisting of 12 to 15 factors, were suggested by
Deutsch and Willis (1988) and by Evans and Marciniak (1987).
All these models do not differ substantially from McCall’s model. The McCall factor model
provides a practical, up-to-date method for classifying software requirements (Pressman,
2000).
McCall’s Factor Model
This model classifies all software requirements into 11 software quality factors. The 11 factors
are grouped into three categories – product operation, product revision, and product
transition factors.
 Product operation factors − Correctness, Reliability, Efficiency, Integrity, Usability.
 Product revision factors − Maintainability, Flexibility, Testability.
 Product transition factors − Portability, Reusability, Interoperability.
Product Operation Software Quality Factors

DIWAKAR EDUCATION HUB Page 59

 SOFTWARE ENGINEERING UNIT – 6
According to McCall’s model, product operation category includes five software quality
factors, which deal with the requirements that directly affect the daily operation of the
software. They are as follows −
Correctness
These requirements deal with the correctness of the output of the software system. They
include −
 Output mission
 The required accuracy of output that can be negatively affected by inaccurate data or
inaccurate calculations.
 The completeness of the output information, which can be affected by incomplete data.
 The up-to-dateness of the information defined as the time between the event and the
response by the software system.
 The availability of the information.
 The standards for coding and documenting the software system.
Reliability
Reliability requirements deal with service failure. They determine the maximum allowed
failure rate of the software system, and can refer to the entire system or to one or more of its
separate functions.
Efficiency
It deals with the hardware resources needed to perform the different functions of the
software system. It includes processing capabilities (given in MHz), its storage capacity (given
in MB or GB) and the data communication capability (given in MBPS or GBPS).
It also deals with the time between recharging of the system’s portable units, such as,
information system units located in portable computers, or meteorological units placed
outdoors.
Integrity
This factor deals with the software system security, that is, to prevent access to unauthorized
persons, also to distinguish between the group of people to be given read as well as write
permit.
Usability
Usability requirements deal with the staff resources needed to train a new employee and to
operate the software system.
Product Revision Quality Factors
According to McCall’s model, three software quality factors are included in the product
revision category. These factors are as follows −
Maintainability
This factor considers the efforts that will be needed by users and maintenance personnel to
identify the reasons for software failures, to correct the failures, and to verify the success of
the corrections.
Flexibility

DIWAKAR EDUCATION HUB Page 60

 SOFTWARE ENGINEERING UNIT – 6
This factor deals with the capabilities and efforts required to support adaptive maintenance
activities of the software. These include adapting the current software to additional
circumstances and customers without changing the software. This factor’s requirements also
support perfective maintenance activities, such as changes and additions to the software in
order to improve its service and to adapt it to changes in the firm’s technical or commercial
environment.
Testability
Testability requirements deal with the testing of the software system as well as with its
operation. It includes predefined intermediate results, log files, and also the automatic
diagnostics performed by the software system prior to starting the system, to find out
whether all components of the system are in working order and to obtain a report about the
detected faults. Another type of these requirements deals with automatic diagnostic checks
applied by the maintenance technicians to detect the causes of software failures.
Product Transition Software Quality Factor
According to McCall’s model, three software quality factors are included in the product
transition category that deals with the adaptation of software to other environments and its
interaction with other software systems. These factors are as follows −
Portability
Portability requirements tend to the adaptation of a software system to other environments
consisting of different hardware, different operating systems, and so forth. The software
should be possible to continue using the same basic software in diverse situations.
Reusability
This factor deals with the use of software modules originally designed for one project in a new
software project currently being developed. They may also enable future projects to make use
of a given module or a group of modules of the currently developed software. The reuse of
software is expected to save development resources, shorten the development period, and
provide higher quality modules.
Interoperability
Interoperability requirements focus on creating interfaces with other software systems or with
other equipment firmware. For example, the firmware of the production machinery and
testing equipment interfaces with the production control software.
ISO/IEC 9126
This standard deals with the following aspects to determine the quality of a software
application −
 Quality model
 External metrics
 Internal metrics
 Quality in use metrics
This standard presents some set of quality attributes for any software such as −
 Functionality
 Reliability

DIWAKAR EDUCATION HUB Page 61

 SOFTWARE ENGINEERING UNIT – 6
 Usability
 Efficiency
 Maintainability
 Portability
ISO 9126 is an international standard for the evaluation of software. The standard is divided
into four parts which addresses, respectively, the following subjects: quality model; external
metrics; internal metrics; and quality in use metrics. ISO 9126 Part one, referred to as ISO
9126-1 is an extension of previous work done by McCall (1977), Boehm (1978), FURPS and
others in defining a set of software quality characteristics.

ISO9126-1 represents the latest (and ongoing) research into characterizing software for the
purposes of software quality control, software quality assurance and software process
improvement (SPI). This article defines the characteristics identified by ISO 9126-1. The other
parts of ISO 9126, concerning metrics or measurements for these characteristics, are essential
for SQC, SQA and SPI but the main concern of this article is the definition of the basic ISO 9126
Quality Model.

The ISO 9126 documentation itself, from the official ISO 9126 documentation, can only be
purchased and is subject to copyright. [Link] only reproduces the basic structure of the ISO
9126 standard and any descriptions, commentary or guidance are original material based on
public domain information as well as our own experience.

The ISO 9126-1 software quality model identifies 6 main quality characteristics, namely:
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability
These characteristics are broken down into subcharacteristics, a high level table is shown
below. It is at the subcharacteristic level that measurement for SPI will occur. The main
characteristics of the ISO9126-1 quality model, can be defined as follows:-

Functionality
Functionality is the essential purpose of any product or service. For certain items this is
relatively easy to define, for example a ship's anchor has the function of holding a ship at a
given location. The more functions a product has, e.g. an ATM machine, then the more
complicated it becomes to define it's functionality. For software a list of functions can be
specified, i.e. a sales order processing systems should be able to record customer
information so that it can be used to reference a sales order. A sales order system should also
provide the following functions:
 Record sales order product, price and quantity.

DIWAKAR EDUCATION HUB Page 62

 SOFTWARE ENGINEERING UNIT – 6
 Calculate total price.
 Calculate appropriate sales tax.
 Calculate date available to ship, based on inventory.
 Generate purchase orders when stock falls below a given threshold.
The list goes on and on but the main point to note is that functionality is expressed as a
totality of essential functions that the software product provides. It is also important to note
that the presence or absence of these functions in a software product can be verified as either
existing or not, in that it is a Boolean (either a yes or no answer). The other software
characteristics listed (i.e. usability) are only present to some degree, i.e. not a simple on or off.
Many people get confused between overall process functionality (in which software plays a
part) and software functionality. This is partly due to the fact that Data Flow Diagrams (DFDs)
and other modeling tools can depict process functionality (as a set of data in\data out
conversions) and software functionality. Consider a sales order process, that has both manual
and software components. A function of the sales order process could be to record the sales
order but we could implement a hard copy filing cabinet for the actual orders and only use
software for calculating the price, tax and ship date. In this way the functionality of the
software is limited to those calculation functions. SPI, or Software Process Improvement is
different from overall Process Improvement or Process Re-engineering, ISO 9126-1 and other
software quality models do not help measure overall Process costs\benefits but only the
software component. The relationship between software functionality within an overall
business process is outside the scope of ISO 9126 and it is only the software functionality, or
essential purpose of the software component, that is of interest for ISO 9126.

Quality Control
Quality control is a set of methods used by organizations to achieve quality parameters or
quality goals and continually improve the organization's ability to ensure that a software
product will meet quality goals.
Quality Control Process:

DIWAKAR EDUCATION HUB Page 63

 SOFTWARE ENGINEERING UNIT – 6
The three class parameters that control software quality are:
 Products
 Processes
 Resources
The total quality control process consists of:
 Plan - It is the stage where the Quality control processes are planned
 Do - Use a defined parameter to develop the quality
 Check - Stage to verify if the quality of the parameters are met
 Act - Take corrective action if needed and repeat the work
Quality Control characteristics:
 Process adopted to deliver a quality product to the clients at best cost.
 Goal is to learn from other organizations so that quality would be better each time.
 To avoid making errors by proper planning and execution with correct review process.
Software Quality Assurance (SQA)
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.
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

DIWAKAR EDUCATION HUB Page 64

 SOFTWARE ENGINEERING UNIT – 6
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.
Processes could be −
 Software Development Methodology
 Project Management
 Configuration Management
 Requirements Development/Management
 Estimation
 Software Design
 Testing, etc.
Once the processes have been defined and implemented, Quality Assurance has the following
responsibilities −
 Identify the weaknesses in the processes
 Correct those weaknesses to continually improve the process
Benefits of Software Quality Assurance (SQA):
1. SQA produce high quality software.
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.
Components of SQA System
An SQA system always combines a wide range of SQA components. These components can be
classified into the following six classes −
Pre-project components
This assures that the project commitments have been clearly defined considering the
resources required, the schedule and budget; and the development and quality plans have
been correctly determined.
Components of project life cycle activities assessment
The project life cycle is composed of two stages: the development life cycle stage and the
operation–maintenance stage.

DIWAKAR EDUCATION HUB Page 65

 SOFTWARE ENGINEERING UNIT – 6
The development life cycle stage components detect design and programming errors. Its
components are divided into the following sub-classes: Reviews, Expert opinions, and Software
testing.
The SQA components used during the operation–maintenance phase include specialized
maintenance components as well as development life cycle components, which are applied
mainly for functionality to improve the maintenance tasks.
Components of infrastructure error prevention and improvement
The main objective of these components, which is applied throughout the entire organization,
is to eliminate or at least reduce the rate of errors, based on the organization’s accumulated
SQA experience.
Components of software quality management
This class of components deal with several goals, such as the control of development and
maintenance activities, and the introduction of early managerial support actions that mainly
prevent or minimize schedule and budget failures and their outcomes.
Components of standardization, certification, and SQA system assessment
These components implement international professional and managerial standards within the
organization. The main objectives of this class are utilization of international professional
knowledge, improvement of coordination of the organizational quality systems with other
organizations, and assessment of the achievements of quality systems according to a common
scale. The various standards may be classified into two main groups: quality management
standards and project process standards.
Organizing for SQA – the human components
The SQA organizational base includes managers, testing personnel, the SQA unit and the
persons interested in software quality such as SQA trustees, SQA committee members, and
SQA forum members. Their main objectives are to initiate and support the implementation of
SQA components, detect deviations from SQA procedures and methodology, and suggest
improvements.
Pre-project Software Quality Components
These components help to improve the preliminary steps taken before starting a project. It
includes −
 Contract Review
 Development and Quality Plans
Contract Review
Normally, a software is developed for a contract negotiated with a customer or for an internal
order to develop a firmware to be embedded within a hardware product. In all these cases,
the development unit is committed to an agreed-upon functional specification, budget and
schedule. Hence, contract review activities must include a detailed examination of the project
proposal draft and the contract drafts.
Specifically, contract review activities include −
 Clarification of the customer’s requirements
 Review of the project’s schedule and resource requirement estimates

DIWAKAR EDUCATION HUB Page 66

 SOFTWARE ENGINEERING UNIT – 6
 Evaluation of the professional staff’s capacity to carry out the proposed project
 Evaluation of the customer’s capacity to fulfil his obligations
 Evaluation of development risks
Development and Quality Plans
After signing the software development contract with an organization or an internal
department of the same organization, a development plan of the project and its integrated
quality assurance activities are prepared. These plans include additional details and needed
revisions based on prior plans that provided the basis for the current proposal and contract.
Most of the time, it takes several months between the tender submission and the signing of
the contract. During these period, resources such as staff availability, professional capabilities
may get changed. The plans are then revised to reflect the changes that occurred in the
interim.
The main issues treated in the project development plan are −
 Schedules
 Required manpower and hardware resources
 Risk evaluations
 Organizational issues: team members, subcontractors and partnerships
 Project methodology, development tools, etc.
 Software reuse plans
The main issues treated in the project’s quality plan are −
 Quality goals, expressed in the appropriate measurable terms
 Criteria for starting and ending each project stage
 Lists of reviews, tests, and other scheduled verification and validation activities
Risk
"Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a problem that
could cause some loss or threaten the progress of the project, but which has not happened
yet.
These potential issues might harm cost, schedule or technical success of the project and the
quality of our software device, or project team morale.
Risk Management is the system of identifying addressing and eliminating these problems
before they can damage the project.
Different methods are required to address these two kinds of issues.
For example, staff storage, because we have not been able to select people with the right
technical skills is a current problem, but the threat of our technical persons being hired away
by the competition is a risk.
Risk Management
A software project can be concerned with a large variety of risks. In order to be adept to
systematically identify the significant risks which might affect a software project, it is essential
to classify risks into different classes. The project manager can then check which risks from
each class are relevant to the project.

DIWAKAR EDUCATION HUB Page 67

 SOFTWARE ENGINEERING UNIT – 6
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource,
and customer-related problems. A vital project risk is schedule slippage. Since the software is
intangible, it is very tough to monitor and control a software project. It is very tough to control
something which cannot be identified. For any manufacturing program, such as the
manufacturing of cars, the plan executive can recognize the product taking shape.
2. Technical risks: Technical risks concern potential method, implementation, interfacing,
testing, and maintenance issue. It also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence. Most
technical risks appear due to the development team's insufficient knowledge about the
project.
3. Business risks: This type of risks contain risks of building an excellent product that no one
need, losing budgetary or personnel commitments, etc.
Other risk categories
1. 1. Known risks: Those risks that can be uncovered after careful assessment of the
project program, the business and technical environment in which the plan is being
developed, and more reliable data sources (e.g., unrealistic delivery date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project experience
(e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to
identify in advance.
Principle of Risk Management
1. Global Perspective: In this, we review the bigger system description, design, and
implementation. We look at the chance and the impact the risk is going to have.
2. Take a forward-looking view: Consider the threat which may appear in the future and
create future plans for directing the next events.
3. Open Communication: This is to allow the free flow of communications between the
client and the team members so that they have certainty about the risks.
4. Integrated management: In this method risk management is made an integral part of
project management.
5. Continuous process: In this phase, the risks are tracked continuously throughout the
risk management paradigm.

Risk Management Activities

Risk management consists of three main activities, as shown in fig:

DIWAKAR EDUCATION HUB Page 68

 SOFTWARE ENGINEERING UNIT – 6

Risk Assessment
The objective of risk assessment is to division the risks in the condition of their loss, causing
potential. For risk assessment, first, every risk should be rated in two methods:
o The possibility of a risk coming true (denoted as r).
o The consequence of the issues relates to that risk (denoted as s).
Based on these two methods, the priority of each risk can be estimated:
p=r*s
Where p is the priority with which the risk must be controlled, r is the probability of the risk
becoming true, and s is the severity of loss caused due to the risk becoming true. If all
identified risks are set up, then the most likely and damaging risks can be controlled first, and
more comprehensive risk abatement methods can be designed for these risks.
1. Risk Identification: The project organizer needs to anticipate the risk in the project as early
as possible so that the impact of risk can be reduced by making effective risk management
planning.
A project can be of use by a large variety of risk. To identify the significant risk, this might
affect a project. It is necessary to categories into the different risk of classes.
There are different types of risks which can affect a software project:
1. Technology risks: Risks that assume from the software or hardware technologies that
are used to develop the system.
2. People risks: Risks that are connected with the person in the development team.
3. Organizational risks: Risks that assume from the organizational environment where the
software is being developed.

DIWAKAR EDUCATION HUB Page 69

 SOFTWARE ENGINEERING UNIT – 6
4. Tools risks: Risks that assume from the software tools and other support software used
to create the system.
5. Requirement risks: Risks that assume from the changes to the customer requirement
and the process of managing the requirements change.
6. Estimation risks: Risks that assume from the management estimates of the resources
required to build the system
2. Risk Analysis: During the risk analysis process, you have to consider every identified risk and
make a perception of the probability and seriousness of that risk.
There is no simple way to do this. You have to rely on your perception and experience of
previous projects and the problems that arise in them.
It is not possible to make an exact, the numerical estimate of the probability and seriousness
of each risk. Instead, you should authorize the risk to one of several bands:
1. The probability of the risk might be determined as very low (0-10%), low (10-25%),
moderate (25-50%), high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of the
plan), serious (would cause significant delays), tolerable (delays are within allowed
contingency), or insignificant.
Risk Control
It is the process of managing risks to achieve desired outcomes. After all, the identified risks of
a plan are determined; the project must be made to include the most harmful and the most
likely risks. Different risks need different containment methods. In fact, most risks need
ingenuity on the part of the project manager in tackling the risk.
There are three main methods to plan for risk management:
1. Avoid the risk: This may take several ways such as discussing with the client to change
the requirements to decrease the scope of the work, giving incentives to the engineers
to avoid the risk of human resources turnover, etc.
2. Transfer the risk: This method involves getting the risky element developed by a third
party, buying insurance cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk. For instance,
if there is a risk that some key personnel might leave, new recruitment can be planned.
Risk Leverage: To choose between the various methods of handling risk, the project plan must
consider the amount of controlling the risk and the corresponding reduction of risk. For this,
the risk leverage of the various risks can be estimated.
Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.
Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of
reduction)
1. Risk planning: The risk planning method considers each of the key risks that have been
identified and develop ways to maintain these risks.
For each of the risks, you have to think of the behavior that you may take to minimize the
disruption to the plan if the issue identified in the risk occurs.

DIWAKAR EDUCATION HUB Page 70

 SOFTWARE ENGINEERING UNIT – 6
You also should think about data that you might need to collect while monitoring the plan so
that issues can be anticipated.
Again, there is no easy process that can be followed for contingency planning. It rely on the
judgment and experience of the project manager.
2. Risk Monitoring: Risk monitoring is the method king that your assumption about the
product, process, and business risks has not changed.
Risk mitigation
Risk mitigation planning is the process of developing options and actions to enhance
opportunities and reduce threats to project objectives. Risk mitigation implementation is the
process of executing risk mitigation actions. Risk mitigation progress monitoring includes
tracking identified risks, identifying new risks, and evaluating risk process effectiveness
throughout the project.
MITRE SE Roles & Expectations: MITRE systems engineers (SEs) working on government
programs develop actionable risk mitigation strategies and monitoring metrics, monitor
implementation of risk mitigation plans to ensure successful project and program completion,
collaborate with the government team in conducting risk reviews across projects and
programs, and analyze metrics to determine ongoing risk status and identify serious risks to
elevate to the sponsor or customer.
Software Reliability
Software Reliability means Operational reliability. It is described as the ability of a system or
component to perform its required functions under static conditions for a specific period.
Software reliability is also defined as the probability that a software system fulfills its assigned
task in a given environment for a predefined number of input cases, assuming that the
hardware and the input are free of error.
Software Reliability is an essential connect of software quality, composed with functionality,
usability, performance, serviceability, capability, installability, maintainability, and
documentation. Software Reliability is hard to achieve because the complexity of software
turn to be high. While any system with a high degree of complexity, containing software, will
be hard to reach a certain level of reliability, system developers tend to push complexity into
the software layer, with the speedy growth of system size and ease of doing so by upgrading
the software.
For example, large next-generation aircraft will have over 1 million source lines of software on-
board; next-generation air traffic control systems will contain between one and two million
lines; the upcoming International Space Station will have over two million lines on-board and
over 10 million lines of ground support software; several significant life-critical defense
systems will have over 5 million source lines of software. While the complexity of software is
inversely associated with software reliability, it is directly related to other vital factors in
software quality, especially functionality, capability, etc.
Estimation of Software Projects
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.

DIWAKAR EDUCATION HUB Page 71

 SOFTWARE ENGINEERING UNIT – 6
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.
 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.

DIWAKAR EDUCATION HUB Page 72

 SOFTWARE ENGINEERING UNIT – 6
 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.
 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.
Software Cost Estimation
For any new software project, it is necessary to know how much it will cost to develop and
how much development time will it take. These estimates are needed before development is
initiated, but how is this done? Several estimation procedures have been developed and are
having the following attributes in common.
1. Project scope must be established in advanced.
2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule
estimates.
6. Acquire one or more automated estimation tools.
Uses of Cost Estimation
1. During the planning stage, one needs to choose how many engineers are required for
the project and to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.
Cost Estimation Models

DIWAKAR EDUCATION HUB Page 73

 SOFTWARE ENGINEERING UNIT – 6
A model may be static or dynamic. In a static model, a single variable is taken as a key element
for calculating cost and time. In a dynamic model, all variable are interdependent, and there is
no basic variable.

Static, Single Variable Models: When a model makes use of single variables to calculate
desired values such as cost, time, efforts, etc. is said to be a single variable model. The most
common equation is:
C=aLb
Where C = Costs
L= size
a and b are constants
The Software Engineering Laboratory established a model called SEL model, for estimating its
software production. This model is an example of the static, single variable model.
E=1.4L0.93
DOC=30.4L0.90
D=4.6L0.26
Where E= Efforts (Person Per Month)
DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code
Static, Multivariable Models: These models are based on method (1), they depend on several
variables describing various aspects of the software development environment. In some
model, several variables are needed to describe the software development process, and
selected equation combined these variables to give the estimate of time & cost. These models
are called multivariable models.
WALSTON and FELIX develop the models at IBM provide the following equation gives a
relationship between lines of source code and effort:
E=5.2L0.91
In the same manner duration of development is given by
D=4.1L0.36
The productivity index uses 29 variables which are found to be highly correlated productivity
as follows:

DIWAKAR EDUCATION HUB Page 74

 SOFTWARE ENGINEERING UNIT – 6

Where Wi is the weight factor for the ithvariable and Xi={-1,0,+1} the estimator gives Xione of
the values -1, 0 or +1 depending on the variable decreases, has no effect or increases the
productivity.
Example: Compare the Walston-Felix Model with the SEL model on a software development
expected to involve 8 person-years of effort.
a. Calculate the number of lines of source code that can be produced.
b. Calculate the duration of the development.
c. Calculate the productivity in LOC/PY
d. Calculate the average manning
Solution:
The amount of manpower involved = 8PY=96persons-months
(a)Number of lines of source code can be obtained by reversing equation to give:

Then
L (SEL) = (96/1.4)1⁄0.93=94264 LOC
L (SEL) = (96/5.2)1⁄0.91=24632 LOC
(b)Duration in months can be calculated by means of equation
D (SEL) = 4.6 (L) 0.26
= 4.6 (94.264)0.26 = 15 months
D (W-F) = 4.1 L0.36
= 4.1 (24.632)0.36 = 13 months
(c) Productivity is the lines of code produced per persons/month (year)

(d)Average manning is the average number of persons required per month in the project

Effort Estimation
Effort estimation represents step 3 of the project planning process.

DIWAKAR EDUCATION HUB Page 75

 SOFTWARE ENGINEERING UNIT – 6

Before we can plan the project schedule we have to estimate effort and duration of all the
work packages of the WBS. Effort estimation will generate a lot more information than only
effort and duration:
 Who will be responsible for each work package?
 What is the work package specification?
 What are the expected results of each work package?
 How is the achievement of the results measured?
 What are the prerequisites for the work package?
 What are the conditions under which the work has to be done?
 What are the required start and end times?
 What and how much material is needed for each work package, at what cost?
 What tools are needed for each work package, at what rates?
Obviously, effort estimation needs expertise on a work package specific level to accomplish
this transition.
There are two categories of estimating the effort of each work package: deductive and
inductive methods.
Deductive or Top-down Methods
Assume the total cost for the project is given. From there we assign the cost, and thus, the
effort of individual work packages based on estimated percentages derived from earlier,
similar projects with similar work packages. The advantage of deductive methods is a simple
and rapid cost allocation, the disadvantage is that they only work for projects that consist of
work packages we already know from earlier, similar projects.
Inductive or Bottom-up Methods
The basic idea of inductive methods is to start effort estimation with the work packages
individually, with support of experts, or knowledge of similar work packages of earlier projects,
and then summarize bottom up, following the structure of the WBS.
(1) Factor Analysis: For a certain work package, we know all the variables or factors, how they
influence the work, and how these factors correlate with each other. Then we can calculate
the effort based on a mathematical formula which reflects that influences and correlations.
Effort = f (influencing variables, correlation coefficients).
For example, the effort of a work package "Develop hardware control unit" is influenced by
the number of people involved, P=4,
the number of interfaces, S=5,
the number of functional blocks, B=10.
DIWAKAR EDUCATION HUB Page 76
 SOFTWARE ENGINEERING UNIT – 6
From earlier projects with similar control units we might know the correlation coefficients. For
example, cP=2.5, cS=2, cB=1.5, cU=2.0. Our formula could look like this
Effort = f(P, S, B) = cP*P + cS*S*S + cB*B =
= 10 + 50 + 15 =
= 75 (working days)
(2) Multiplication Method: If we can divide a work package into a number of equal parts then,
we can estimate the total effort by estimating one part and then multiplying this value by the
number of parts.
Total Effort = Effort of one part * number of parts
(3) Analogy Method: This method again applies the knowledge from similar work packages.
We interpolate or extrapolate the effort for the work package from a similar one. For example,
for the work package “Install electrical wiring in an apartment of 100 sqm” we could guess the
effort by interpolation from similar work for apartments of 150 sqm, 10 working days, and 50
sqm, 6 working days:
Effort(100 sqm) = (10 + 6) / 2 = 8 working days.
(4) Function Point Method: For IT or software design related work packages we can apply the
function point method. The prerequisite is that we need to have a lot of knowledge about the
effort of work packages of similar scope and degree of difficulty, based on observation. Then
the experts compile this knowledge into so called “function curves” which we can use to
estimate effort for new work packages. In the following example we estimate the effort of
work about creating 100, 500, and 800 lines of code. We obtain the effort via the
corresponding function points on the function curve, 5, 16, and 33 working days, respectively.

(5) Delphi Method: For most of our work packages we use the Delphi method. We just ask the
experts for each work package for their best guess, normal guess, and worst guess. Thus we
obtain three figures for the expected effort: E(optimistic), E(normal), and E(pessimistic), then
combine them with this formula:
Effort = (E(optimistic)+4*E(normal)+E(pessimistic))/6.
If we can ask ten or more experts, we could even calculate the mean values and apply
mathematical statistics with the concept of standard deviation.
Usually, we ask all the experts to join an effort estimation workshop which can be combined
with a risk management workshop, of two, three, or more days depending on the number of
work packages that have to be estimated.
DIWAKAR EDUCATION HUB Page 77
 SOFTWARE ENGINEERING UNIT – 6
Cost Estimation Models
Cost estimation simply means a technique that is used to find out the cost estimates. The cost
estimate is the financial spend that is done on the efforts to develop and test software
in Software Engineering. Cost estimation models are some mathematical algorithms or
parametric equations that are used to estimate the cost of a product or a project.
Various techniques or models are available for cost estimation, also known as Cost Estimation
Models as shown below :

1. Empirical Estimation Technique –

Empirical estimation is a technique or model in which empirically derived formulas are
used for predicting the data that are a required and essential part of the software
project planning step. These techniques are usually based on the data that is collected
previously from a project and also based on some guesses, prior experience with the
development of similar types of projects, and assumptions. It uses the size of the
software to estimate the effort.
In this technique, an educated guess of project parameters is made. Hence, these models are
based on common sense. However, as there are many activities involved in empirical
estimation techniques, this technique is formalized. For example Delphi technique and Expert
Judgement technique.
2. Heuristic Technique –
Heuristic word is derived from a Greek word that means “to discover”. The heuristic
technique is a technique or model that is used for solving problems, learning, or
discovery in the practical methods which are used for achieving immediate goals. These
techniques are flexible and simple for taking quick decisions through shortcuts and good
enough calculations, most probably when working with complex data. But the decisions
that are made using this technique are necessary to be optimal.
1. In this technique, the relationship among different project parameters is expressed
using mathematical equations. The popular heuristic technique is given by Constructive
Cost Model (COCOMO). This technique is also used to increase or speed up the analysis
and investment decisions.
2. Analytical Estimation Technique –
Analytical estimation is a type of technique that is used to measure work. In this
technique, firstly the task is divided or broken down into its basic component operations

DIWAKAR EDUCATION HUB Page 78

 SOFTWARE ENGINEERING UNIT – 6
or elements for analyzing. Second, if the standard time is available from some other
source, then these sources are applied to each element or component of work.
Third, if there is no such time available, then the work is estimated based on the experience of
the work. In this technique, results are derived by making certain basic assumptions about the
project. Hence, the analytical estimation technique has some scientific
basis. Halstead’s software science is based on an analytical estimation model.
2. Intermediate Model –
The basic Cocomo model assumes that the effort is only a function of the number of lines of
code and some constants evaluated according to the different software system. However, in
reality, no system’s effort and schedule can be solely calculated on the basis of Lines of Code.
For that, various other factors such as reliability, experience, Capability. These factors are
known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost estimation.
Classification of Cost Drivers and their attributes:
(i) Product attributes –
 Required software reliability extent
 Size of the application database
 The complexity of the product
(ii) Hardware attributes –
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
(iii) Personnel attributes –
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
(iv) Project attributes –
 Use of software tools
 Application of software engineering methods
 Required development schedule;

VERY VERY
COST DRIVERS LOW LOW NOMINAL HIGH HIGH

Product Attributes

Required Software Reliability 0.75 0.88 1.00 1.15 1.40

DIWAKAR EDUCATION HUB Page 79

 SOFTWARE ENGINEERING UNIT – 6

VERY VERY
COST DRIVERS LOW LOW NOMINAL HIGH HIGH

Size of Application Database 0.94 1.00 1.08 1.16

Complexity of The Product 0.70 0.85 1.00 1.15 1.30

Hardware Attributes

Runtime Performance Constraints 1.00 1.11 1.30

Memory Constraints 1.00 1.06 1.21

Volatility of the virtual machine

environment 0.87 1.00 1.15 1.30

Required turnabout time 0.94 1.00 1.07 1.15

Personnel attributes

Analyst capability 1.46 1.19 1.00 0.86 0.71

Applications experience 1.29 1.13 1.00 0.91 0.82

Software engineer capability 1.42 1.17 1.00 0.86 0.70

Virtual machine experience 1.21 1.10 1.00 0.90

Programming language
experience 1.14 1.07 1.00 0.95

Project Attributes

Application of software
engineering methods 1.24 1.10 1.00 0.91 0.82

Use of software tools 1.24 1.10 1.00 0.91 0.83

Required development schedule 1.23 1.08 1.00 1.04 1.10

The project manager is to rate these 15 different parameters for a particular project on a scale
of one to three. Then, depending on these ratings, appropriate cost driver values are taken
DIWAKAR EDUCATION HUB Page 80
 SOFTWARE ENGINEERING UNIT – 6
from the above table. These 15 values are then multiplied to calculate the EAF (Effort
Adjustment Factor). The Intermediate COCOMO formula now takes the form:

The values of a and b in case of the intermediate model are as follows:

SOFTWARE PROJECTS A B

Organic 3.2 1.05

Semi Detached 3.0 1.12

Embeddedc 2.8 1.20

2. Detailed Model –
Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering
process. The detailed model uses different effort multipliers for each cost driver
attribute. In detailed cocomo, the whole software is divided into different modules and
then we apply COCOMO in different modules to estimate effort and then sum the
effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
The effort is calculated as a function of program size and a set of cost drivers are given
according to each phase of the software lifecycle.
Project Staffing
Project staffing - Flexible Staffing Strategy / Solutions
Companies face multiple challenges in this global economy. To remain competitive in this
demanding market, they are constantly adopting latest cutting edge technologies so as to
improve services and increase their bottom-line. This technology drive has created huge
demand for highly talented and skilled resources for implementing mission critical projects. To
improve the profits, these technology initiatives and related projects demand optimum
resourcing / staffing strategies.
IT Managers face tough staffing issues with tight deadlines for deliverables. They have
insufficient staff and most of them may not be able to take up the development using latest
technologies without proper training. This calls for a staffing plan/strategy to support the
flexible demands of the projects during the entire life cycle using outsourced services. The

DIWAKAR EDUCATION HUB Page 81

 SOFTWARE ENGINEERING UNIT – 6
purpose of the staffing plan is to ensure that the project has sufficient resources with the
right skills based on project schedule for successful completion.
When developed as a strategy, flexible project staffing can cut cost, maintain quality and help
accomplish specific goals. Better Minds Consulting has the expertise and capabilities to
support mission critical project staffing needs. Our best practices approach starts off with an
assessment of our client project needs, processes, and technologies. Our team, after careful
evaluation, recommends a staffing plan to support the end-to end needs of the project
implementation. Our staffing solutions offer flexibility, scalability, right mix and competitive
pricing.

Project Staffing Plan

Primary task of our team is to build an effective project staffing plan to identify the following:
1. Skills Matrix - Required skills for each task in the project structure
2. Estimate man hours for each task
3. Resource matrix – required resources (internal and outsourced) - Training of in-house
team, hiring, supplemental staffing using IT staffing vendors, etc. Planned hiring of new
technical staff can help in transition. Critical staff has to be identified and managed
carefully.
4. Resource Deployment Matrix - Resource start date and sign off date (optimum
utilization) – Gradual increase / decrease of resources, rotation and re-deployment
based on project delivery schedules / milestones. Right mix will ensure both internal
staff and outsourced resources are deployed in a blended mode to avoid unexpected
departure or absence of outside consultants.
5. Resource / Risk Management – Manage / monitor resources periodically and avoid
project risks due to resource issues. Absence of skilled resources when required will lead
to project delays and cost escalation. Project staffing needs careful planning as it
involves lead time to source, screen, and successfully deploy the right technical and
management resources. As part of risk and continuity management, full time internal
staff must be allowed to grow during the implementation cycle so that knowledge
gained is not lost.

DIWAKAR EDUCATION HUB Page 82

 SOFTWARE ENGINEERING UNIT – 6
6. A check list with all the above factors will help the program managers / project
managers / HR to plan the internal and outsourcing staffing requirements, manage
critical staff, transition planning, knowledge transfer and deliver projects on time within
budget.
Better Minds Consulting provides end-to-end staffing services for software projects
from “kick-off to sign-off”, also called SDLC (Software Development Life Cycle) as shown
below.

Timeline Chart
A timeline chart is an effective way to visualize a process using chronological order. Since
details are displayed graphically, important points in time can be easy seen and understood.
Often used for managing a project’s schedule, timeline charts function as a sort of calendar of
events within a specific period of time.

DIWAKAR EDUCATION HUB Page 83

 SOFTWARE ENGINEERING UNIT – 6

Timeline Diagrams solution extends ConceptDraw PRO diagramming software with samples,
templates and libraries of specially developed smart vector design elements of timeline bars,
time intervals, milestones, events, today marker, legend, and many other elements with
custom properties, helpful for professional drawing clear and intuitive Timeline Diagrams. Use
it to design simple Timeline Diagrams and designate only the main project stages, or highly
detailed Timeline Diagrams depicting all project tasks, subtasks, milestones, deadlines,
responsible persons and other description information, ideal for applying in presentations,
reports, education materials, and other documentation.
Line Graphs

How to draw a Line Graph with ease? The Line Graphs solution extends the capabilities of
ConceptDraw PRO v10 with professionally designed templates, samples, and a library of vector
stencils for drawing perfect Line Graphs.
Basic Line Graphs

DIWAKAR EDUCATION HUB Page 84

 SOFTWARE ENGINEERING UNIT – 6

This solution extends the capabilities of ConceptDraw PRO v10.3.0 (or later) with templates,
samples and a library of vector stencils for drawing Line Graphs.
Software Engineer Package

How to Create a Timeline Diagram in ConceptDraw PRO

DIWAKAR EDUCATION HUB Page 85

 SOFTWARE ENGINEERING UNIT – 6

A Timeline is a chart which displays a project plan schedule in chronological order. A Timeline
is used in project management to depict project milestones and visualize project phases, and
show project progress. The graphic form of a timeline makes it easy to understand critical
project milestones, such as the progress of a project schedule. Timelines are particularly useful
for project scheduling or project management when accompanied with a Gantt chart. It
captures the main of what the project will accomplish and how it will be done. making a
project timeline is one of the most important skills a project manager needs have. Making
comprehensive, accurate timelines allows you getting every project off in the best way.
ConceptDraw PRO allows you to draw a timeline charts using special library.
Time Series Dashboard
Time series dashboard solution extends ConceptDraw PRO software with templates, samples
and vector stencils libraries with charts, graphs and plots for drawing the visual dashboards
showing data time series.
Basic Area Charts
This solution extends the capabilities of ConceptDraw PRO v10.3.0 (or later) with templates,
samples and a library of vector stencils for drawing Area Charts (area graphs) that visualize
changes in values by filling in the area beneath the line connecting data points.

Software Testing

DIWAKAR EDUCATION HUB Page 86

 SOFTWARE ENGINEERING UNIT – 6
Software testing is widely used technology because it is compulsory to test each and every
software before deployment.
Our Software testing tutorial includes all topics of Software testing such as Methods such as
Black Box Testing, White Box Testing, Visual Box Testing and Gray Box Testing. Levels such as
Unit Testing, Integration Testing, Regression Testing, Functional Testing. System Testing,
Acceptance Testing, Alpha Testing, Beta Testing, Non-Functional testing, Security Testing,
Portability Testing.
Software Testing
Software testing is a process of identifying the correctness of software by considering its all
attributes (Reliability, Scalability, Portability, Re-usability, Usability) and evaluating the
execution of software components to find the software bugs or errors or defects.

Software testing provides an independent view and objective

of the software and gives surety of fitness of the software. It involves testing of all
components under the required services to confirm that whether it is satisfying the specified
requirements or not. The process is also providing the client with information about the
quality of the software.
Testing is mandatory because it will be a dangerous situation if the software fails any of time
due to lack of testing. So, without testing software cannot be deployed to the end user.
DIWAKAR EDUCATION HUB Page 87
 SOFTWARE ENGINEERING UNIT – 6
What is Testing
Testing is a group of techniques to determine the correctness of the application under the
predefined script but, testing cannot find all the defect of application. The main intent of
testing is to detect failures of the application so that failures can be discovered and corrected.
It does not demonstrate that a product functions properly under all conditions but only that it
is not working in some specific conditions.
Testing furnishes comparison that compares the behavior and state of software against
mechanisms because the problem can be recognized by the mechanism. The mechanism may
include past versions of the same specified product, comparable products, and interfaces of
expected purpose, relevant standards, or other criteria but not limited up to these.
Testing includes an examination of code and also the execution of code in various
environments, conditions as well as all the examining aspects of the code. In the current
scenario of software development, a testing team may be separate from the development
team so that Information derived from testing can be used to correct the process of software
development.
The success of software depends upon acceptance of its targeted audience, easy graphical
user interface, strong functionality load test, etc. For example, the audience of banking is
totally different from the audience of a video game. Therefore, when an organization develops
a software product, it can assess whether the software product will be beneficial to its
purchasers and other audience.
Type of Software testing
We have various types of testing available in the market, which are used to test the
application or the software.
With the help of below image, we can easily understand the type of software testing:

DIWAKAR EDUCATION HUB Page 88

 SOFTWARE ENGINEERING UNIT – 6

Manual testing
The process of checking the functionality of an application as per the customer needs without
taking any help of automation tools is known as manual testing. While performing the manual
testing on any application, we do not need any specific knowledge of any testing tool, rather
than have a proper understanding of the product so we can easily prepare the test document.
Manual testing can be further divided into three types of testing, which are as follows:
o White box testing
o Black box testing
o Gray box testing
Automation testing
Automation testing is a process of converting any manual test cases into the test scripts with
the help of automation tools, or any programming language is known as automation testing.
With the help of automation testing, we can enhance the speed of our test execution because
here, we do not require any human efforts. We need to write a test script and execute those
scripts.
Software Testing Principles
Software testing is a procedure of implementing software or the application to identify the
defects or bugs. For testing an application or software, we need to follow some principles to
make our product defects free, and that also helps the test engineers to test the software with
their effort and time. Here, in this section, we are going to learn about the seven essential
principles of software testing.
The seven different testing principles, one by one:
o Testing shows the presence of defects

DIWAKAR EDUCATION HUB Page 89

 SOFTWARE ENGINEERING UNIT – 6
o Exhaustive Testing is not possible
o Early Testing
o Defect Clustering
o Pesticide Paradox
o Testing is context-dependent
o Absence of errors fallacy

Testing shows the presence of defects

The test engineer will test the application to make sure that the application is bug or defects
free. While doing testing, we can only identify that the application or software has any errors.
The primary purpose of doing testing is to identify the numbers of unknown bugs with the
help of various methods and testing techniques because the entire test should be traceable to
the customer requirement, which means that to find any defects that might cause the product
failure to meet the client's needs.
By doing testing on any application, we can decrease the number of bugs, which does not
mean that the application is defect-free because sometimes the software seems to be bug-
free while performing multiple types of testing on it. But at the time of deployment in the
production server, if the end-user encounters those bugs which are not found in the testing
process.
Exhaustive Testing is not possible
Sometimes it seems to be very hard to test all the modules and their features with effective
and non- effective combinations of the inputs data throughout the actual testing process.
Hence, instead of performing the exhaustive testing as it takes boundless determinations and
most of the hard work is unsuccessful. So we can complete this type of variations according to

DIWAKAR EDUCATION HUB Page 90

 SOFTWARE ENGINEERING UNIT – 6
the importance of the modules because the product timelines will not permit us to perform
such type of testing scenarios.
Early Testing
Here early testing means that all the testing activities should start in the early stages of the
software development life cycle's requirement analysis stage to identify the defects because if
we find the bugs at an early stage, it will be fixed in the initial stage itself, which may cost us
very less as compared to those which are identified in the future phase of the testing process.
To perform testing, we will require the requirement specification documents; therefore, if the
requirements are defined incorrectly, then it can be fixed directly rather than fixing them in
another stage, which could be the development phase.
Defect clustering
The defect clustering defined that throughout the testing process, we can detect the numbers
of bugs which are correlated to a small number of modules. We have various reasons for this,
such as the modules could be complicated; the coding part may be complex, and so on.
These types of software or the application will follow the Pareto Principle, which states that
we can identify that approx. Eighty percent of the complication is present in 20 percent of the
modules. With the help of this, we can find the uncertain modules, but this method has its
difficulties if the same tests are performing regularly, hence the same test will not able to
identify the new defects.
Pesticide paradox
This principle defined that if we are executing the same set of test cases again and again over a
particular time, then these kinds of the test will not be able to find the new bugs in the
software or the application. To get over these pesticide paradoxes, it is very significant to
review all the test cases frequently. And the new and different tests are necessary to be
written for the implementation of multiple parts of the application or the software, which
helps us to find more bugs.
Testing is context-dependent
Testing is a context-dependent principle states that we have multiple fields such as e-
commerce websites, commercial websites, and so on are available in the market. There is a
definite way to test the commercial site as well as the e-commerce websites because every
application has its own needs, features, and functionality. To check this type of application, we
will take the help of various kinds of testing, different technique, approaches, and multiple
methods. Therefore, the testing depends on the context of the application.
Absence of errors fallacy
Once the application is completely tested and there are no bugs identified before the release,
so we can say that the application is 99 percent bug-free. But there is the chance when the
application is tested beside the incorrect requirements, identified the flaws, and fixed them on
a given period would not help as testing is done on the wrong specification, which does not
apply to the client's requirements. The absence of error fallacy means identifying and fixing
the bugs would not help if the application is impractical and not able to accomplish the client's
requirements and needs.
Verification testing
DIWAKAR EDUCATION HUB Page 91
 SOFTWARE ENGINEERING UNIT – 6
Verification testing includes different activities such as business requirements, system
requirements, design review, and code walkthrough while developing a product.
It is also known as static testing, where we are ensuring that "we are developing the right
product or not". And it also checks that the developed application fulfilling all the
requirements given by the client.

Validation testing
Validation testing is testing where tester performed functional and non-functional testing.
Here functional testing includes Unit Testing (UT), Integration Testing (IT) and System Testing
(ST), and non-functional testing includes User acceptance testing (UAT).
Validation testing is also known as dynamic testing, where we are ensuring that "we have
developed the product right." And it also checks that the software meets the business needs
of the client.

DIWAKAR EDUCATION HUB Page 92

 SOFTWARE ENGINEERING UNIT – 6

Note: Verification and Validation process are done under the V model of the software
development life cycle.
Difference between verification and validation testing

Verification Validation

We check whether we are developing the We check whether the developed product is
right product or not. right.

Verification is also known as static testing. Validation is also known as dynamic testing.

Verification includes different methods Validation includes testing like functional

like Inspections, Reviews, and testing, system testing, integration, and User
Walkthroughs. acceptance testing.

It is a process of checking the work- It is a process of checking the software during

products (not the final product) of a or at the end of the development cycle to
development cycle to decide whether the decide whether the software follow the
product meets the specified specified business requirements.
requirements.

Quality assurance comes under Quality control comes under validation testing.
verification testing.

The execution of code does not happen in In validation testing, the execution of code
the verification testing. happens.

DIWAKAR EDUCATION HUB Page 93

 SOFTWARE ENGINEERING UNIT – 6

In verification testing, we can find the In the validation testing, we can find those
bugs early in the development phase of bugs, which are not caught in the verification
the product. process.

Verification testing is executed by the Validation testing is executed by the testing

Quality assurance team to make sure that team to test the application.
the product is developed according to
customers' requirements.

Verification is done before the validation After verification testing, validation testing
testing. takes place.

In this type of testing, we can verify that In this type of testing, we can validate that the
the inputs follow the outputs or not. user accepts the product or not.

Defect
Software testing lays down the mechanism for finding defects in an application, product or
system. A Defect is a deviation between the actual and expected outcomes. A mistake in the
source code indicates Error. The error uncovered by a tester becomes a Defect. The defect
recognized by the dev team turns into a Bug. If a product build doesn’t pass the acceptance
criteria, then it proves to be a Failure.
Defect In Manual Testing
A defect is an anomaly which causes a deviation between the expected and actual results. It
could be an error discovered once the application got deployed into production. Some
software could show potential issues with both the internal and external features. Hence, any
variance in the behavior of the functionalities of a product or software got to be a defect in
manual testing.
Defect Vs. Wrong, Miss, Error, Bug, Failure, and Fault
In Software Testing, Defect has many names such as Wrong, Miss, Error, Bug, Failure, and
Fault. Let’s find out what all of these are:
1. Wrong- Wrong indicates the incorrect implementation of the customer requirements. A
manual tester will record it as a defect because of the deviation from the given specification.
2. Miss- Miss shows that one or more customer requirements got missed in the
implementation. It is also a deviation from the original specifications. The tester would also log
it as a defect to
3. Error- An error could arise because of a coding mistake by the developer, he misunderstood,
or the requirement was not clear enough. For example, a developer may misinterpret a design
flow, or he might use an incompatible data type which results in an Error. Some actions like
insufficient array limit, loop getting into the infinite loop or invalid syntax cause to errors. If a
tester catches any of these, then he or she will log a defect for the same.

DIWAKAR EDUCATION HUB Page 94

 SOFTWARE ENGINEERING UNIT – 6
4. Bug- A bug occurs because of some coding error and leads a program to malfunction. It may
also lead to a functional issue in the product. These are fatal errors that could block a
functionality, results in a crash, or cause performance bottlenecks. Such errors got treated as
Bugs in manual testing.
5. Failure- A failure indicates a fatal issue in software or in its module which is making the
system inoperative or unresponsive. Such an error in the software which the end customer
reports are a Failure. The manual testers also discover many failures during the development
cycle.
6. Fault- A fault makes an application behave in a wrong manner.
The problems like an invalid step, lack of resources or inappropriate data definition could
cause a fault in a program. It may happen in software because the developer has not added
the code for fault tolerance.

Integration testing
Integration testing is the second level of the software testing process comes after unit testing.
In this testing, units or individual components of the software are tested in a group. The focus
of the integration testing level is to expose defects at the time of interaction between
integrated components or units.
Unit testing uses modules for testing purpose, and these modules are combined and tested in
integration testing. The Software is developed with a number of software modules that are
coded by different coders or programmers. The goal of integration testing is to check the
correctness of communication among all the modules.

Once all the components or modules are working independently, then we need to check the
data flow between the dependent modules is known as integration testing.
one sample example of a banking application, as we can see in the below image of amount
transfer.

DIWAKAR EDUCATION HUB Page 95

 SOFTWARE ENGINEERING UNIT – 6

o First, we will login as a user P to amount transfer and send Rs200 amount, the
confirmation message should be displayed on the screen as amount transfer
successfully. Now logout as P and login as user Q and go to amount balance page and
check for a balance in that account = Present balance + Received Balance. Therefore, the
integration test is successful.
o Also, we check if the amount of balance has reduced by Rs200 in P user account.
o Click on the transaction, in P and Q, the message should be displayed regarding the data
and time of the amount transfer.
Guidelines for Integration Testing
o We go for the integration testing only after the functional testing is completed on each
module of the application.
o We always do integration testing by picking module by module so that a proper
sequence is followed, and also we don't miss out on any integration scenarios.
o First, determine the test case strategy through which executable test cases can be
prepared according to test data.
o Examine the structure and architecture of the application and identify the crucial
modules to test them first and also identify all possible scenarios.
o Design test cases to verify each interface in detail.
o Choose input data for test case execution. Input data plays a significant role in testing.
o If we find any bugs then communicate the bug reports to developers and fix defects and
retest.
o Perform positive and negative integration testing.
Here positive testing implies that if the total balance is Rs15, 000 and we are transferring
Rs1500 and checking if the amount transfer works fine. If it does, then the test would be a
pass.
And negative testing means, if the total balance is Rs15, 000 and we are transferring Rs20, 000
and check if amount transfer occurs or not, if it does not occur, the test is a pass. If it happens,
then there is a bug in the code, and we will send it to the development team for fixing that
bug.

DIWAKAR EDUCATION HUB Page 96

 SOFTWARE ENGINEERING UNIT – 6
Note: Any application in this world will do functional testing compulsory, whereas integration
testing will be done only if the modules are dependent on each other. Each integration
scenarios should compulsorily have source→ data→destination. Any scenarios can be called as
integration scenario only if the data gets saved in the destination.
For example: In the Gmail application, the Source could be Compose, Data could be Email and
the Destination could be the Inbox.
Example of integration testing
Let us assume that we have a Gmail application where we perform the integration testing.
First, we will do functional testing on the login page, which includes the various components
such as username, password, submit, and cancel button. Then only we can perform
integration testing.
The different integration scenarios are as follows:

Scenarios1:
o First, we login as P users and click on the Compose mail and performing the functional
testing for the specific components.
o Now we click on the Send and also check for Save Drafts.
o After that, we send a mail to Q and verify in the Send Items folder of P to check if the
send mail is there.
o Now, we will log out as P and login as Q and move to the Inbox and verify that if the
mail has reached.
Secanrios2: We also perform the integration testing on Spam folders. If the particular contact
has been marked as spam, then any mail sent by that user should go to the spam folder and
not in the inbox.
Note: We will perform functional testing for all features, such as to send items, inbox, and so
on.

DIWAKAR EDUCATION HUB Page 97

 SOFTWARE ENGINEERING UNIT – 6
As we can see in the below image, we will perform the functional testing for all the text fields
and every feature. Then we will perform integration testing for the related functions. We first
test the add user, list of users, delete user, edit user, and then search user.

Note:
o There are some features, we might be performing only the functional testing, and there
are some features where we are performing both functional and integration
testing based on the feature's requirements.
o Prioritizing is essential, and we should perform it at all the phases, which means we will
open the application and select which feature needs to be tested first. Then go to that
feature and choose which component must be tested first. Go to those components and
determine what values to be entered first.
And don't apply the same rule everywhere because testing logic varies from feature to
feature.
o While performing testing, we should test one feature entirely and then only proceed to
another function.
o Among the two features, we must be performing only positive integrating testing or
both positive and negative integration testing, and this also depends on the features
need.
Reason Behind Integration Testing
Although all modules of software application already tested in unit testing, errors still exist due
to the following reasons:
1. Each module is designed by individual software developer whose programming logic
may differ from developers of other modules so; integration testing becomes essential
to determine the working of software modules.

DIWAKAR EDUCATION HUB Page 98

 SOFTWARE ENGINEERING UNIT – 6
2. To check the interaction of software modules with the database whether it is an
erroneous or not.
3. Requirements can be changed or enhanced at the time of module development. These
new requirements may not be tested at the level of unit testing hence integration
testing becomes mandatory.
4. Incompatibility between modules of software could create errors.
5. To test hardware's compatibility with software.
6. If exception handling is inadequate between modules, it can create bugs.
Integration Testing Techniques
Any testing technique (Blackbox, Whitebox, and Greybox) can be used for Integration Testing;
some are listed below:
Black Box Testing
o State Transition technique
o Decision Table Technique
o Boundary Value Analysis
o All-pairs Testing
o Cause and Effect Graph
o Equivalence Partitioning
o Error Guessing
White Box Testing
o Data flow testing
o Control Flow Testing
o Branch Coverage Testing
o Decision Coverage Testing
Types of Integration Testing
Integration testing can be classified into two parts:
o Incremental integration testing
o Non-incremental integration testing

Incremental Approach

DIWAKAR EDUCATION HUB Page 99

 SOFTWARE ENGINEERING UNIT – 6
In the Incremental Approach, modules are added in ascending order one by one or according
to need. The selected modules must be logically related. Generally, two or more than two
modules are added and tested to determine the correctness of functions. The process
continues until the successful testing of all the modules.
OR
In this type of testing, there is a strong relationship between the dependent modules. Suppose
we take two or more modules and verify that the data flow between them is working fine. If it
is, then add more modules and test again.

For example: Suppose we have a Flipkart application, we will perform incremental integration
testing, and the flow of the application would like this:
Flipkart→ Login→ Home → Search→ Add cart→Payment → Logout
Incremental integration testing is carried out by further methods:
o Top-Down approach
o Bottom-Up approach
Top-Down Approach
The top-down testing strategy deals with the process in which higher level modules are tested
with lower level modules until the successful completion of testing of all the modules. Major
design flaws can be detected and fixed early because critical modules tested first. In this type
of method, we will add the modules incrementally or one by one and check the data flow in
the same order.

DIWAKAR EDUCATION HUB Page 100

 SOFTWARE ENGINEERING UNIT – 6

In the top-down approach, we will be ensuring that the module we are adding is the child of
the previous one like Child C is a child of Child B and so on as we can see in the below image:

Advantages:
o Identification of defect is difficult.
o An early prototype is possible.
Disadvantages:
o Due to the high number of stubs, it gets quite complicated.
o Lower level modules are tested inadequately.
o Critical Modules are tested first so that fewer chances of defects.
Bottom-Up Method
The bottom to up testing strategy deals with the process in which lower level modules are
tested with higher level modules until the successful completion of testing of all the modules.
Top level critical modules are tested at last, so it may cause a defect. Or we can say that we
will be adding the modules from bottom to the top and check the data flow in the same order.

DIWAKAR EDUCATION HUB Page 101

 SOFTWARE ENGINEERING UNIT – 6

In the bottom-up method, we will ensure that the modules we are adding are the parent of
the previous one as we can see in the below image:

Advantages
o Identification of defect is easy.
o Do not need to wait for the development of all the modules as it saves time.
Disadvantages
o Critical modules are tested last due to which the defects can occur.
o There is no possibility of an early prototype.
In this, we have one addition approach which is known as hybrid testing.
Hybrid Testing Method
In this approach, both Top-Down and Bottom-Up approaches are combined for testing. In this
process, top-level modules are tested with lower level modules and lower level modules
tested with high-level modules simultaneously. There is less possibility of occurrence of defect
because each module interface is tested.

DIWAKAR EDUCATION HUB Page 102

 SOFTWARE ENGINEERING UNIT – 6

Advantages
o The hybrid method provides features of both Bottom Up and Top Down methods.
o It is most time reducing method.
o It provides complete testing of all modules.
Disadvantages
o This method needs a higher level of concentration as the process carried out in both
directions simultaneously.
o Complicated method.
Non- incremental integration testing
We will go for this method, when the data flow is very complex and when it is difficult to find
who is a parent and who is a child. And in such case, we will create the data in any module
bang on all other existing modules and check if the data is present. Hence, it is also known as
the Big bang method.

Big Bang Method

In this approach, testing is done via integration of all modules at once. It is convenient for
small software systems, if used for large software systems identification of defects is difficult.

DIWAKAR EDUCATION HUB Page 103

 SOFTWARE ENGINEERING UNIT – 6
Since this testing can be done after completion of all modules due to that testing team has less
time for execution of this process so that internally linked interfaces and high-risk critical
modules can be missed easily.

Advantages:
o It is convenient for small size software systems.
Disadvantages:
o Identification of defects is difficult because finding the error where it came from is a
problem, and we don't know the source of the bug.
o Small modules missed easily.
o Time provided for testing is very less.
o We may miss to test some of the interfaces.
Let us see examples for our better understanding of the non-incremental integrating testing or
big bang method:
Example1
In the below example, the development team develops the application and sends it to the CEO
of the testing team. Then the CEO will log in to the application and generate the username and
password and send a mail to the manager. After that, the CEO will tell them to start testing the
application.
Then the manager manages the username and the password and produces a username and
password and sends it to the test leads. And the test leads will send it to the test
engineers for further testing purposes. This order from the CEO to the test engineer is top-
down incremental integrating testing.
In the same way, when the test engineers are done with testing, they send a report to the test
leads, who then submit a report to the manager, and the manager will send a report to
the CEO. This process is known as Bottom-up incremental integration testing as we can see in
the below image:
Note: The combination incremental integration testing (I.I.T) and non-incremental integration
testing is known as sandwich testing.

DIWAKAR EDUCATION HUB Page 104

 SOFTWARE ENGINEERING UNIT – 6

Example2
The below example demonstrates a home page of Gmail's Inbox, where we click on
the Inbox link, and we are moved to the inbox page. Here we have to do non- incremental
integration testing because there is no parent and child concept.

Note
Stub and driver
The stub is a dummy module that receives the data and creates lots of probable data, but it
performs like a real module. When a data is sent from module P to Stub Q, it receives the data
without confirming and validating it, and produce the estimated outcome for the given data.

DIWAKAR EDUCATION HUB Page 105

 SOFTWARE ENGINEERING UNIT – 6

The function of a driver is used to verify the data from P and sends it to stub and also checks
the expected data from the stub and sends it to P.
The driver is one that sets up the test environments and also takes care of the communication,
evaluates results, and sends the reports. We never use the stub and driver in the testing
process.
In White box testing, bottom-up integration testing is ideal because writing drivers is
accessible. And in black box testing, no preference is given to any testing as it depends on the
application.
White Box Testing
The box testing approach of software testing consists of black box testing and white box
testing. We are discussing here white box testing which also known as glass box is testing,
structural testing, clear box testing, open box testing and transparent box testing. It tests
internal coding and infrastructure of a software focus on checking of predefined inputs against
expected and desired outputs. It is based on inner workings of an application and revolves
around internal structure testing. In this type of testing programming skills are required to
design test cases. The primary goal of white box testing is to focus on the flow of inputs and
outputs through the software and strengthening the security of the software.
The term 'white box' is used because of the internal perspective of the system. The clear box
or white box or transparent box name denote the ability to see through the software's outer
shell into its inner workings.
Developers do white box testing. In this, the developer will test every line of the code of the
program. The developers perform the White-box testing and then send the application or the
software to the testing team, where they will perform the black box testing and verify the
application along with the requirements and identify the bugs and sends it to the developer.
The developer fixes the bugs and does one round of white box testing and sends it to the
testing team. Here, fixing the bugs implies that the bug is deleted, and the particular feature is
working fine on the application.
Here, the test engineers will not include in fixing the defects for the following reasons:
o Fixing the bug might interrupt the other features. Therefore, the test engineer should
always find the bugs, and developers should still be doing the bug fixes.

DIWAKAR EDUCATION HUB Page 106

 SOFTWARE ENGINEERING UNIT – 6
o If the test engineers spend most of the time fixing the defects, then they may be unable
to find the other bugs in the application.
The white box testing contains various tests, which are as follows:
o Path testing
o Loop testing
o Condition testing
o Testing based on the memory perspective
o Test performance of the program
Path testing
In the path testing, we will write the flow graphs and test all independent paths. Here writing
the flow graph implies that flow graphs are representing the flow of the program and also
show how every program is added with one another as we can see in the below image:

And test all the independent paths implies that suppose a path from main() to function G, first
set the parameters and test if the program is correct in that particular path, and in the same
way test all other paths and fix the bugs.
Loop testing
In the loop testing, we will test the loops such as while, for, and do-while, etc. and also check
for ending condition if working correctly and if the size of the conditions is enough.
For example: we have one program where the developers have given about 50,000 loops.
1. {
2. while(50,000)
3. ……
4. ……
5. }
We cannot test this program manually for all the 50,000 loops cycle. So we write a small
program that helps for all 50,000 cycles, as we can see in the below program, that test P is

DIWAKAR EDUCATION HUB Page 107

 SOFTWARE ENGINEERING UNIT – 6
written in the similar language as the source code program, and this is known as a Unit test.
And it is written by the developers only.
1. Test P
2. {
3. ……
4. …… }
As we can see in the below image that, we have various requirements such as 1, 2, 3, 4. And
then, the developer writes the programs such as program 1,2,3,4 for the parallel conditions.
Here the application contains the 100s line of codes.

The developer will do the white box testing, and they will test all the five programs line by line
of code to find the bug. If they found any bug in any of the programs, they will correct it. And
they again have to test the system then this process contains lots of time and effort and slows
down the product release time.
Now, suppose we have another case, where the clients want to modify the requirements, then
the developer will do the required changes and test all four program again, which take lots of
time and efforts.
These issues can be resolved in the following ways:
In this, we will write test for a similar program where the developer writes these test code in
the related language as the source code. Then they execute these test code, which is also
known as unit test programs. These test programs linked to the main program and
implemented as programs.

DIWAKAR EDUCATION HUB Page 108

 SOFTWARE ENGINEERING UNIT – 6

Therefore, if there is any requirement of modification or bug in the code, then the developer
makes the adjustment both in the main program and the test program and then executes the
test program.
Condition testing
In this, we will test all logical conditions for both true and false values; that is, we will verify for
both if and else condition.
For example:
1. if(condition) - true
2. {
3. …..
4. ……
5. ……
6. }
7. else - false
8. {
9. …..
10. ……
11. ……
12. }
The above program will work fine for both the conditions, which means that if the condition is
accurate, and then else should be false and conversely.
Testing based on the memory (size) perspective
The size of the code is increasing for the following reasons:
o The reuse of code is not there: let us take one example, where we have four programs
of the same application, and the first ten lines of the program are similar. We can write
these ten lines as a discrete function, and it should be accessible by the above four

DIWAKAR EDUCATION HUB Page 109

 SOFTWARE ENGINEERING UNIT – 6
programs as well. And also, if any bug is there, we can modify the line of code in the
function rather than the entire code.
o The developers use the logic that might be modified. If one programmer writes code
and the file size is up to 250kb, then another programmer could write a similar code
using the different logic, and the file size is up to 100kb.
o The developer declares so many functions and variables that might never be used in
any portion of the code. Therefore, the size of the program will increase.
For example,
1. Int a=15;
2. Int b=20;
3. String S= "Welcome";
4. ….
5. …..
6. …..
7. ….
8. …..
9. Int p=b;
10. Create user()
11. {
12. ……
13. ……
14. ….. 200's line of code
15. }
In the above code, we can see that the integer a has never been called anywhere in the
program, and also the function Create user has never been called anywhere in the code.
Therefore, it leads us to memory consumption.
We cannot remember this type of mistake manually by verifying the code because of the large
code. So, we have a built-in tool, which helps us to test the needless variables and functions.
And, here we have the tool called Rational purify.

DIWAKAR EDUCATION HUB Page 110

 SOFTWARE ENGINEERING UNIT – 6

Suppose we have three programs such as Program P, Q, and R, which provides the input to S.
And S goes into the programs and verifies the unused variables and then gives the outcome.
After that, the developers will click on several results and call or remove the unnecessary
function and the variables.
This tool is only used for the C programming language and C++ programming language; for
another language, we have other related tools available in the market.
o The developer does not use the available in-built functions; instead they write the full
features using their logic. Therefore, it leads us to waste of time and also postpone the
product releases.
Test the performance (Speed, response time) of the program
The application could be slow for the following reasons:
o When logic is used.
o For the conditional cases, we will use or & and adequately.
o Switch case, which means we cannot use nested if, instead of using a switch case.

DIWAKAR EDUCATION HUB Page 111

 SOFTWARE ENGINEERING UNIT – 6
As we know that the developer is performing white box testing, they understand that the code
is running slow, or the performance of the program is also getting deliberate. And the
developer cannot go manually over the program and verify which line of the code is slowing
the program.
To recover with this condition, we have a tool called Rational Quantify, which resolves these
kinds of issues automatically. Once the entire code is ready, the rational quantify tool will go
through the code and execute it. And we can see the outcome in the result sheet in the form
of thick and thin lines.
Here, the thick line specifies which section of code is time-consuming. When we double-click
on the thick line, the tool will take us to that line or piece of code automatically, which is also
displayed in a different color. We can change that code and again and use this tool. When the
order of lines is all thin, we know that the presentation of the program has enhanced. And the
developers will perform the white box testing automatically because it saves time rather than
performing manually.
Test cases for white box testing are derived from the design phase of the software
development lifecycle. Data flow testing, control flow testing, path testing, branch testing,
statement and decision coverage all these techniques used by white box testing as a guideline
to create an error-free software.

White box testing follows some working steps to make testing manageable and easy to
understand what the next task to do. There are some basic steps to perform white box testing.
Generic steps of white box testing
o Design all test scenarios, test cases and prioritize them according to high priority
number.
o This step involves the study of code at runtime to examine the resource utilization, not
accessed areas of the code, time taken by various methods and operations and so on.
o In this step testing of internal subroutines takes place. Internal subroutines such as
nonpublic methods, interfaces are able to handle all types of data appropriately or not.
o This step focuses on testing of control statements like loops and conditional statements
to check the efficiency and accuracy for different data inputs.
o In the last step white box testing includes security testing to check all possible security
loopholes by looking at how the code handles security.
Reasons for white box testing
o It identifies internal security holes.

DIWAKAR EDUCATION HUB Page 112

 SOFTWARE ENGINEERING UNIT – 6
o To check the way of input inside the code.
o Check the functionality of conditional loops.
o To test function, object, and statement at an individual level.
Advantages of White box testing
o White box testing optimizes code so hidden errors can be identified.
o Test cases of white box testing can be easily automated.
o This testing is more thorough than other testing approaches as it covers all code paths.
o It can be started in the SDLC phase even without GUI.
Disadvantages of White box testing
o White box testing is too much time consuming when it comes to large-scale
programming applications.
o White box testing is much expensive and complex.
o It can lead to production error because it is not detailed by the developers.
o White box testing needs professional programmers who have a detailed knowledge and
understanding of programming language and implementation.
Techniques Used in White Box Testing
Data Flow Data flow testing is a group of testing strategies that examines the control
Testing flow of programs in order to explore the sequence of variables according to
the sequence of events.

Control Flow Control flow testing determines the execution order of statements or
Testing instructions of the program through a control structure. The control
structure of a program is used to develop a test case for the program. In this
technique, a particular part of a large program is selected by the tester to set
the testing path. Test cases represented by the control graph of the
program.

Branch Branch coverage technique is used to cover all branches of the control flow
Testing graph. It covers all the possible outcomes (true and false) of each condition
of decision point at least once.

Statement Statement coverage technique is used to design white box test cases. This
Testing technique involves execution of all statements of the source code at least
once. It is used to calculate the total number of executed statements in the
source code, out of total statements present in the source code.

Decision This technique reports true and false outcomes of Boolean expressions.
Testing Whenever there is a possibility of two or more outcomes from the
statements like do while statement, if statement and case statement
(Control flow statements), it is considered as decision point because there
are two outcomes either true or false.

DIWAKAR EDUCATION HUB Page 113

 SOFTWARE ENGINEERING UNIT – 6
Black box testing
Black box testing is a technique of software testing which examines the functionality of
software without peering into its internal structure or coding. The primary source of black box
testing is a specification of requirements that is stated by the customer.
In this method, tester selects a function and gives input value to examine its functionality, and
checks whether the function is giving expected output or not. If the function produces correct
output, then it is passed in testing, otherwise failed. The test team reports the result to the
development team and then tests the next function. After completing testing of all functions if
there are severe problems, then it is given back to the development team for correction.

Generic steps of black box testing

o The black box test is based on the specification of requirements, so it is examined in the
beginning.
o In the second step, the tester creates a positive test scenario and an adverse test
scenario by selecting valid and invalid input values to check that the software is
processing them correctly or incorrectly.
o In the third step, the tester develops various test cases such as decision table, all pairs
test, equivalent division, error estimation, cause-effect graph, etc.
o The fourth phase includes the execution of all test cases.
o In the fifth step, the tester compares the expected output against the actual output.
o In the sixth and final step, if there is any flaw in the software, then it is cured and tested
again.
Test procedure
The test procedure of black box testing is a kind of process in which the tester has specific
knowledge about the software's work, and it develops test cases to check the accuracy of the
software's functionality.
It does not require programming knowledge of the software. All test cases are designed by
considering the input and output of a particular function.A tester knows about the definite
output of a particular input, but not about how the result is arising. There are various
techniques used in black box testing for testing like decision table technique, boundary value
analysis technique, state transition, All-pair testing, cause-effect graph technique, equivalence
partitioning technique, error guessing technique, use case technique and user story technique.
All these techniques have been explained in detail within the tutorial.
Test cases
Test cases are created considering the specification of the requirements. These test cases are
generally created from working descriptions of the software including requirements, design

DIWAKAR EDUCATION HUB Page 114

 SOFTWARE ENGINEERING UNIT – 6
parameters, and other specifications. For the testing, the test designer selects both positive
test scenario by taking valid input values and adverse test scenario by taking invalid input
values to determine the correct output. Test cases are mainly designed for functional testing
but can also be used for non-functional testing. Test cases are designed by the testing team,
there is not any involvement of the development team of software.
Techniques Used in Black Box Testing
Decision Table Decision Table Technique is a systematic approach where various input
Technique combinations and their respective system behavior are captured in a
tabular form. It is appropriate for the functions that have a logical
relationship between two and more than two inputs.

Boundary Value Boundary Value Technique is used to test boundary values, boundary
Technique values are those that contain the upper and lower limit of a variable. It
tests, while entering boundary value whether the software is producing
correct output or not.

State Transition State Transition Technique is used to capture the behavior of the
Technique software application when different input values are given to the same
function. This applies to those types of applications that provide the
specific number of attempts to access the application.

All-pair Testing All-pair testing Technique is used to test all the possible discrete
Technique combinations of values. This combinational method is used for testing
the application that uses checkbox input, radio button input, list box,
text box, etc.

Cause-Effect Cause-Effect Technique underlines the relationship between a given

Technique result and all the factors affecting the [Link] is based on a collection of
requirements.

Equivalence Equivalence partitioning is a technique of software testing in which

Partitioning input data divided into partitions of valid and invalid values, and it is
Technique mandatory that all partitions must exhibit the same behavior.

Error Guessing Error guessing is a technique in which there is no specific method for
Technique identifying the error. It is based on the experience of the test analyst,
where the tester uses the experience to guess the problematic areas of
the software.

DIWAKAR EDUCATION HUB Page 115

 SOFTWARE ENGINEERING UNIT – 6

Use Case Use case Technique used to identify the test cases from the beginning
Technique to the end of the system as per the usage of the system. By using this
technique, the test team creates a test scenario that can exercise the
entire software based on the functionality of each function from start to
end.

Alpha Testing

Alpha testing is conducted in the organization and tested by a representative group of end-
users at the developer's side and sometimes by an independent team of testers.
Alpha testing is simulated or real operational testing at an in-house site. It comes after the unit
testing, integration testing, etc. Alpha testing used after all the testing are executed.
It can be a white box, or Black-box testing depends on the requirements - particular lab
environment and simulation of the actual environment required for this testing.

What is the alpha testing process?

Alpha testing follows the following process:
1. Requirement Review: Review the design of the specification and functional
requirement
2. Test Development: Test development is base on the outcome of the requirement
review. Develop the test cases and test plan.

DIWAKAR EDUCATION HUB Page 116

 SOFTWARE ENGINEERING UNIT – 6
3. Test case design: Execute the test plan and test cases.
4. Logging Defects: Logging the identified and detected bug found in the application.
5. Bug Fixation: When all the bugs are identified and logged, then there is a need to fix the
bug.
6. Retesting: When all the issues are solved, and fixed retesting is done.

What are the phases of alpha testing?

Alpha testing ensures that the software performs flawlessly and does not impact the
reputation of the organization; the company implements final testing in the form of alpha
testing. This testing executed into two phases.

There are two phases of alpha testing.

First Phase: In-house developers of software engineers do the first phase of testing. In this
phase, the tester used hardware debugger or hardware aided debugger to catches the bugs
quickly. During the alpha testing, a tester finds a lot of bugs, crashes, missing features, and
docs.
Second Phase: The second phase involves the quality assurance staff performs the alpha
testing by involving black box and white box techniques.
When to perform alpha testing?

DIWAKAR EDUCATION HUB Page 117

 SOFTWARE ENGINEERING UNIT – 6

Alpha testing is user acceptance testing. Alpha testing performed once the product has gone
through stages of testing and prepared for release. It is executing before beta testing, which is
also a part of acceptance testing and can define as field testing. During this testing, we can
make changes in the software to improve its quality and functionality. Alpha testing done from
the developer's site where independent developers can monitor and record user experience
and make necessary changes to enhance the performance.
What are the reasons to perform Alpha Testing?
Alpha testing is the final stage of the testing. Alpha testing is an essential and popular testing
technique that helps the team to deliver quality and useful software. This testing performed
before the release of the product. Alpha testing can define as the first round of independent
testing that ensures that the software run as per the requirement plan.
Reasons for alpha testing are:
o Refines the software product by finding and rectifying bugs that weren't discovered
through previous tests.
o Alpha testing allows the team to test the software in a real-world environment.
o One of the reasons to do alpha testing is to ensure the success of the software product.
o Alpha testing validates the quality, functionality of the software, and effectiveness of
the software before it released in the real world.
What are the features of Alpha Testing?
o Alpha testing is a type of acceptance testing.
o Alpha testing is happening at the stage of the completion of the software product.
o Alpha testing is in the labs where we provide a specific and controlled environment.
o Alpha testing is in-house testing, which is performed by the internal developers and
testers within the organization.
o There is not any involvement of the public.
o Alpha testing helps to gain confidence in the user acceptance of the software product.
o With the help of black box and white box technique, we can achieve the alpha testing.

DIWAKAR EDUCATION HUB Page 118

 SOFTWARE ENGINEERING UNIT – 6
o Alpha testing ensures the maximum possible quality of the software before releasing it
to market or client for beta testing.
o Developers perform alpha testing at developer's site; it enables the developer to record
the error with the ease to resolve found bugs quickly.
o Alpha testing is doing after the unit testing, integration testing, system testing but
before the beta testing.
o Alpha testing is for testing the software application, products, and projects.
Advantages of alpha testing are:
o One of the benefits of alpha testing is it reduces the delivery time of the project.
o It provides a complete test plan and test cases.
o Free the team member for another project.
o Every feedback helps to improve software quality.
o It provides a better observation of the software's reliability and accountability.
What are the disadvantages of Alpha Testing?
Disadvantages of alpha testing are:
o Alpha testing does not involve in-depth testing of the software.
o The difference between the tester's tests the data for testing the software and the
customer's data from their perspective may result in the discrepancy in the software
functioning.
o The lab environment is used to simulate the real environment. But still, the lab cannot
furnish all the requirement of the real environment such as multiple conditions, factors,
and circumstances.
Beta Testing
Beta testing is a type of User Acceptance Testing among the most crucial testing, which
performed before the release of the software. Beta Testing is a type of Field Test. This testing
performs at the end of the software testing life cycle. This type of testing can be considered as
external user acceptance testing. It is a type of salient testing. Real users perform this testing.
This testing executed after the alpha testing. In this the new version, beta testing is released to
a limited audience to check the accessibility, usability, and functionality, and more.
Beta testing is the last phase of the testing, which is carried out at the client's or customer's
site.

DIWAKAR EDUCATION HUB Page 119

 SOFTWARE ENGINEERING UNIT – 6

What are the features of beta testing?

Testing of the product performs by the real users of the software application in the real
environment. Beta version of the software is released to a restricted number of end-users to
obtain the feedback of the product quality. Beta testing reduces the risk of failure and
provides the quality of the product through customer validation. It is the final testing before
shipping the product to the customers. Beta testing obtains direct feedback from the
customers. It helps in testing to test the product in the customer's environment.
Features of beta testing are:
o Beta testing used in a real environment at the user's site. Beta testing helps in providing
the actual position of the quality.
o Testing performed by the client, stakeholder, and end-user.
o Beta testing always is done after the alpha testing, and before releasing it into the
market.
o Beta testing is black-box testing.
o Beta testing performs in the absence of tester and the presence of real users
o Beta testing is performed after alpha testing and before the release of the final product.
o Beta testing generally is done for testing software products like utilities, operating
systems, and applications, etc.
What is a beta version of the software?
The beta version of the software is delivered to a restricted number of users to accept their
feedback and suggestions on quality improvement. Hence, there are two types of beta
version:
1) Closed beta version: Closed beta version, also known as a private beta, it is released to a
group of selected and invited people. Those people will test the software and evaluate their
features and specifications. This beta version represents the software which is capable of
delivering value, but it is not ready to be used by everyone. Because it shows the issues like
lack of documentation or missing vital features.

DIWAKAR EDUCATION HUB Page 120

 SOFTWARE ENGINEERING UNIT – 6

2) Open beta version: Open beta is also known as a public beta. The open beta opened to the
public. Any user as a tester can assess the beta version to provide the relevant feedback and
reviews. Open beta version improves the quality of the final release. This version helps to find
the various undetected errors and issues.

The beta testing process orients this beta version.

What is the lifecycle of Beta Testing?
A group of end-users performs beta testing. This process can't execute without any strategy or
test plan. Before the testers, the end-user executes this type of testing.
The process of beta testing follows the following steps:
1. Planning: Like another testing process, beta testing also supports proper planning. In
this stage, the team prepares a testing strategy and defines the goal of testing. In this
case, the team establishes the need of users for testing, duration, and necessary details
related to the process.
2. Participant Recruitment: This is the second stage of the beta process in which the team
recruits a group of selected end-users for testing. This group can change as per the
requirement of the organization and the product.

DIWAKAR EDUCATION HUB Page 121

 SOFTWARE ENGINEERING UNIT – 6
3. Product Launch: When a team of users (testers) recruited. The beta version of the
product is launched or installed at the client or user side, and users will test the product
for quality assurance.
4. Collect and Evaluate Feedback: When the testing finished, developers will collect the
feedback provided by the testers and evaluate it. In the end, based on the feedback,
issues, and bugs are fixed and resolved by the responsible individual team.
5. Closure: When all the problems fixed and the organization meets the exit criteria, beta
testing achieved, and the rewards offered to the testing team.
What are the types of beta testing?
Beta testing has six types. Each type has different aspects of the software. All these help
developers to improve the quality of the software and allow them to deliver a product that
offers excellent user experience. Here are the different types of beta testing:
1. Open Beta Testing: Open beta testing involves testing the software product by a large
number of people before the final release. The organization decides to make a software
product open to the public before releasing the product. Open Beta includes the
extensive participation of the public to use and evaluate software product accordingly.
Users report the bug to the organization, along with a suggestion to improve the quality
of the software.
2. Closed Beta Testing: Opposite to the open beta testing. Closed beta testing performed
by the selective and limited number of persons. The organization recruits these. In this
testing software product is not open to the public.
3. Traditional Beta Testing: In this testing, a software product delivered to the target
market, and the feedback from the users collected. This type of testing assistance the
beta testing, the quality of the software is improved, and developers can make the
changes.
4. Public Beta Testing: This type of testing is similar to open testing. Public beta testing
also allows the product is delivering to the end-users worldwide, with the aid of various
online channels available in the world. From this, the feedback and evaluated data also
collected and based on the requirement changes, and the development team
implements modifications.
5. Technical Beta Testing: Technical beta testing is also an essential type of beta testing.
This testing involves delivering the software product to the internal groups of the
organization. However, the data and feedback provided by the employees of the
organization.
6. Focused Beta Testing: This type of testing focused on monitoring and evaluating a
specific feature or component of the software. In focused beta testing, the software
released to the market and user's experience assessed and collected to make the
required changes.
7. Post-Release Beta Testing: In this testing, the product delivered to the market for the
use of the end-users. Their feedback, reactions, and experience are collect for the future
release of the software.
When to perform Beta Testing?

DIWAKAR EDUCATION HUB Page 122

 SOFTWARE ENGINEERING UNIT – 6
Acceptance testing is the final phase of the testing, which combines both alpha and beta
testing to ensure that the product released flawlessly. Beta testing performed at the user's
end. This testing always performed after the alpha testing, but before the product released to
the market. In this stage, the product is expected to be 90% to 95% completed.
Any product undergoing to beta test should be reviewed for the entire checklist before
launching it.
Some of them are:
o All the component of the product is ready to start this testing.
o Documentation which is going to end-user should be kept ready - Setup, installation,
usage, Uninstallation should be in detail.
o The product management team should review that all the functionality is in good
condition.
o Procedure to collect bugs, feedback, etc. should be identified before publishing it.
What are the stakeholders and participants in the Beta Testing?
The product management, quality management, and user experience teams are the
stakeholder in beta testing, and they closely monitor every move of the phase.
The real users who use the product are the participants.
Beta test strategy
o Business objective for the product.
o Beta test plan
o The testing approach followed by participants.
o Tools used to detect bugs, measure productivity, collect feedback.
o When and how to end this testing phase?
What is a Beta Test plan?
A beta test plan can be written in many ways,
Objective: We should have to mention the aim of the project why there is a need for beta
testing even after performing the internal testing.
Scope: In this plan, we should mention the areas to be tested or not.
Test Approach: We should have to mention clearly that the testing is in the deep, what to
focus on - functionality, UI, response, etc.
Schedule: We have to specify, clearly the start and ending date with time, number of cycles,
and duration per cycle.
Tools: Bug logging tools and the usage of the machines should identify.
Budget: Incentive of the bugs based on the severity.
Feedback: Collecting feedback and evaluating methods.
o Identify and review the entry and exit criteria.
What are the entry criteria for Beta Testing?
o Sign off the document from alpha testing.
o Beta version of the software should ready.
o The environment should be ready to release the software application to the public.

DIWAKAR EDUCATION HUB Page 123

 SOFTWARE ENGINEERING UNIT – 6
o To capture the real-time faults environment should be ready.
What are the exit criteria for Beta Testing?
o All the major and minor issues resolved.
o The feedback report should prepare.
o The delivery of beta test summary report.
Regression testing
Regression testing is a black box testing techniques. It is used to authenticate a code change in
the software does not impact the existing functionality of the product. Regression testing is
making sure that the product works fine with new functionality, bug fixes, or any change in the
existing feature.
Regression testing is a type of software testing. Test cases are re-executed to check the
previous functionality of the application is working fine, and the new changes have not
produced any bugs.
Regression testing can be performed on a new build when there is a significant change in the
original functionality. It ensures that the code still works even when the changes are occurring.
Regression means Re-test those parts of the application, which are unchanged.
Regression tests are also known as the Verification Method. Test cases are often
automated. Test cases are required to execute many times and running the same test case
again and again manually, is time-consuming and tedious too.
Example of Regression testing
Here we are going to take a case to define the regression testing efficiently:
Consider a product Y, in which one of the functionality is to trigger confirmation, acceptance,
and dispatched emails. It also needs to be tested to ensure that the change in the code not
affected them. Regressing testing does not depend on any programming language
like Java, C++, C#, etc. This method is used to test the product for modifications or any updates
done. It ensures that any change in a product does not affect the existing module of the
product. Verify that the bugs fixed and the newly added features not created any problem in
the previous working version of the Software.
When can we perform Regression Testing?
We do regression testing whenever the production code is modified.
We can perform regression testing in the following scenario, these are:
1. When new functionality added to the application.
Example:
A website has a login functionality which allows users to log in only with Email. Now providing
a new feature to do login using Facebook.
2. When there is a Change Requirement.
Example:
Remember password removed from the login page which is applicable previously.
3. When the defect fixed
Example:

DIWAKAR EDUCATION HUB Page 124

 SOFTWARE ENGINEERING UNIT – 6
Assume login button is not working in a login page and a tester reports a bug stating that the
login button is broken. Once the bug fixed by developers, tester tests it to make sure Login
Button is working as per the expected result. Simultaneously, tester tests other functionality
which is related to the login button.
4. When there is a performance issue fix
Example:
Loading of a home page takes 5 seconds, reducing the load time to 2 seconds.
5. When there is an environment change
Example:
When we update the database from MySql to Oracle.
How to perform Regression Testing?
The need for regression testing comes when software maintenance includes enhancements,
error corrections, optimization, and deletion of existing features. These modifications may
affect system functionality. Regression Testing becomes necessary in this case.
Regression testing can be performed using the following techniques:

1. Re-test All:
Re-Test is one of the approaches to do regression testing. In this approach, all the test case
suits should be re-executed. Here we can define re-test as when a test fails, and we determine
the cause of the failure is a software fault. The fault is reported, we can expect a new version
of the software in which defect fixed. In this case, we will need to execute the test again to
confirm that the fault fixed. This is known as re-testing. Some will refer to this as confirmation
testing.
The re-test is very expensive, as it requires enormous time and resources.
2. Regression test Selection:
o In this technique, a selected test-case suit will execute rather than an entire test-case
suit.
o The selected test case suits divided in two cases
1. Reusable Test cases.
2. Obsolete Test cases.
o Reusable test cases can use in succeeding regression cycle.
o Obsolete test cases can't use in succeeding regression cycle.

DIWAKAR EDUCATION HUB Page 125

 SOFTWARE ENGINEERING UNIT – 6
3. Prioritization of test cases:
Prioritize the test case depending on business impact, critical and frequently functionality
used. Selection of test cases will reduce the regression test suite.
What are the Regression Testing tools?
Regression Testing is a vital part of the QA process; while performing the regression we may
face the below challenges:
o Time Consuming
Regression Testing consumes a lot of time to complete. Regression testing involves
existing tests again, so testers are not excited to re-run the test.
o Complex
Regression Testing is complex as well when there is a need to update any product; lists
of the test are also increasing.
o Communicating business rule
Regression Testing ensures the existing product features are still in working order.
Communication about regression testing with a non-technical leader can be a difficult
task. The executive wants to see the product move forward and making a considerable
time investment in regression testing to ensure existing functionality working can be
hard.
o Identify Impact Area
o Test Cases Increases Release by Release
o Less Resources
o No Accuracy
o Repetitive Task
o Monotonous Job
Regression testing process
The regression testing process can be performed across the builds and the releases.
Regression testing across the builds
Whenever the bug fixed, we retest the Bug, and if there is any dependent module, we go for a
Regression Testing.

For example, How we perform the regression testing if we have different builds as Build 1,
Build 2, and Build 3, which having different scenarios.

DIWAKAR EDUCATION HUB Page 126

 SOFTWARE ENGINEERING UNIT – 6
Build1
o Firstly the client will provide the business needs.
o Then the development team starts developing the features.
o After that, the testing team will start writing the test cases; for example, they write 900
test cases for the release#1 of the product.
o And then, they will start implementing the test cases.
o Once the product is released, the customer performs one round of acceptance testing.
o And in the end, the product is moved to the production server.
Build2
o Now, the customer asks for 3-4 extra (new) features to be added and also provides the
requirements for the new features.
o The development team starts developing new features.
o After that, the testing team will start writing the test case for the new features, and they
write about 150 new test cases. Therefore, the total number of the test case written is
1050 for both the releases.
o Now the testing team starts testing the new features using 150 new test cases.
o Once it is done, they will begin testing the old features with the help of 900 test cases to
verify that adding the new feature has damaged the old features or not.
o Here, testing the old features is known as Regression Testing.
o Once all the features (New and Old) have been tested, the product is handed over to the
customer, and then the customer will do the acceptance testing.
o Once the acceptance testing is done, the product is moved to the production server.
Build3
o After the second release, the customer wants to remove one of the features like Sales.
o Then he/she will delete all the test cases which are belonging to the sales module
(about 120 test cases).
o And then, test the other feature for verifying that if all the other features are working
fine after removing the sales module test cases, and this process is done under the
regression testing.
Note:
o Testing the stable features to ensure that it is broken because of the changes. Here
changes imply that the modification, addition, bug fixing, or the deletion.
o Re-execution of the same test cases in the different builds or releases is to ensure that
changes (modification, addition, bug fixing, or the deletion) are not introducing bugs in
stable features.
Regression testing across the release
The regression testing process starts whenever there is a new Release for same project
because the new feature may affect the old elements in the previous releases.
To understand the regression testing process, we will follow the below steps:
Step1

DIWAKAR EDUCATION HUB Page 127

 SOFTWARE ENGINEERING UNIT – 6
There is no regression testing in Release#1 because there is no modification happen in the
Release#1 as the release is new itself.
Step2
The concept of Regression testing starts from Release#2 when the customer gives some new
requirements.
Step3
After getting the new requirements (modifying features) first, they (the developers and test
engineers) will understand the needs before going to the impact analysis.
Step4
After understanding the new requirements, we will perform one round of impact analysis to
avoid the major risk, but here the question arises who will do the Impact analysis?
Step5
The impact analysis is done by the customer based on their business knowledge,
the developer based on their coding knowledge, and most importantly, it is done by the test
engineer because they have the product knowledge.
Note: If a single person does, he/she may not cover all the impact areas, so we include all
persons so that we may cover a maximum impact area, and Impact Analysis should be done at
the early stages of the releases.
Step6
Once we are done with the impact area, then the developer will prepare the impact area
(document), and the customer will also prepare the impact area document so that we can
achieve the maximum coverage of impact analysis.
Step7
After completing the impact analysis, the developer, the customer, and the test engineer will
send the Reports# of the impact area documents to the Test Lead. And in the meantime, the
test engineer and the developer are busy working on the new test case.
Step8
Once the Test lead gets the Reports#, he/she will consolidate the reports and stored in
the test case requirement repository for the release#1.
Note: Test case Repository: Here, we will save all the test case of releases.
Step9
After that, the Test Lead will take the help of RTM and pick the necessary regression test
case from the test case repository, and those files will be placed in the Regression Test Suite.
Note:
o The test lead will store the regression test case in the regression test suite for no further
confusion.
o Regression test suite: Here, we will save all the impact area test documents.
o Regression Test Cases: These are the test cases of the old releases text document which
need to be re-executed as we can see in the below image:

DIWAKAR EDUCATION HUB Page 128

 SOFTWARE ENGINEERING UNIT – 6

Step10
After that, when the test engineer has done working on the new test cases, the test lead
will assign the regression test case to the test engineer.
Step11
When all the regression test cases and the new features are stable and pass, then check
the impact area using the test case until it is durable for old features plus the new features,
and then it will be handed over to the customer.

Types of Regression Testing

The different types of Regression Testing are as follows:
o Unit Regression Testing [URT]
o Regional Regression Testing[RRT]

DIWAKAR EDUCATION HUB Page 129

 SOFTWARE ENGINEERING UNIT – 6
o Full or Complete Regression Testing [FRT]

Unit Regression Testing [URT]

In this, we are going to test only the changed unit, not the impact area, because it may affect
the components of the same module.
Example1
In the below application, and in the first build, the developer develops the Search button that
accepts 1-15 characters. Then the test engineer tests the Search button with the help of
the test case design technique.

Now, the client does some modification in the requirement and also requests that the Search
button can accept the 1-35 characters. The test engineer will test only the Search button to
verify that it takes 1-35 characters and does not check any further feature of the first build.
Example2
Here, we have Build B001, and a defect is identified, and the report is delivered to the
developer. The developer will fix the bug and sends along with some new features which are
developed in the second Build B002. After that, the test engineer will test only after the defect
is fixed.
o The test engineer will identify that clicking on the Submit button goes to the blank page.
o And it is a defect, and it is sent to the developer for fixing it.
o When the new build comes along with the bug fixes, the test engineer will test only the
Submit button.

DIWAKAR EDUCATION HUB Page 130

 SOFTWARE ENGINEERING UNIT – 6
o And here, we are not going to check other features of the first build and move to test
the new features and sent in the second build.
o We are sure that fixing the Submitbutton is not going to affect the other features, so we
test only the fixed bug.

Therefore, we can say that by testing only the changed feature is called the Unit Regression
Testing.
Regional Regression testing [RRT]
In this, we are going to test the modification along with the impact area or regions, are called
the Regional Regression testing. Here, we are testing the impact area because if there are
dependable modules, it will affect the other modules also.
For example:
In the below image as we can see that we have four different modules, such as Module A,
Module B, Module C, and Module D, which are provided by the developers for the testing
during the first build. Now, the test engineer will identify the bugs in Module D. The bug
report is sent to the developers, and the development team fixes those defects and sends the
second build.

DIWAKAR EDUCATION HUB Page 131

 SOFTWARE ENGINEERING UNIT – 6
In the second build, the previous defects are fixed. Now the test engineer understands that
the bug fixing in Module D has impacted some features in Module A and Module C. Hence,
the test engineer first tests the Module D where the bug has been fixed and then checks the
impact areas in Module A and Module C. Therefore, this testing is known as Regional
regression testing.
While performing the regional regression testing, we may face the below problem:
Full Regression testing [FRT]
During the second and the third release of the product, the client asks for adding 3-4 new
features, and also some defects need to be fixed from the previous release. Then the testing
team will do the Impact Analysis and identify that the above modification will lead us to test
the entire product.
Therefore, we can say that testing the modified features and all the remaining (old)
features is called the Full Regression testing.

When we perform Full Regression testing?

We will perform the FRT when we have the following conditions:
o When the modification is happening in the source file of the product. For example, JVM
is the root file of the JAVA application, and if any change is going to happen in JVM, then
the entire JAVA program will be tested.
o When we have to perform n-number of changes.
Note:
The regional regression testing is the ideal approach of regression testing, but the issue is, we
may miss lots of defects while performing the Regional Regression testing.
And here we are going to solve this issue with the help of the following approach:
o When the application is given for the testing, the test engineer will test the first 10-14
cycle, and will do the RRT.
o Then for the 15th cycle, we do FRT. And again, for the next 10-15 cycle, we do Regional
regression testing, and for the 31th cycle, we do the full regression testing, and we will
continue like this.

DIWAKAR EDUCATION HUB Page 132

 SOFTWARE ENGINEERING UNIT – 6
o But for the last ten cycle of the release, we will perform only complete regression
testing.
Therefore, if we follow the above approach, we can get more defects.
The drawback of doing regression testing manually repeatedly:
o Productivity will decrease.
o It is a difficult job to do.
o There is no consistency in test execution.
o And the test execution time is also increased.
Hence, we will go for the automation to get over with these issues; when we have n-number
of the regression test cycle, we will go for the automation regression testing process.
Automated Regression testing process
Generally we go for the automation whenever there are multiple releases or multiple
regression cycle or there is the repetitive task.
The automation regression testing process can be done in the following steps:
Note1:
The process of testing the application by using some tools is known as automation testing.
Suppose if we take one sample example of a Login module, then how we can perform the
regression testing.
Here, the Login can be done in two ways, which are as follows:

Manually: In this, we will perform regression only one and twice.

Automation: In this, we will do the automation multiple times as we have to write the test
scripts and do the execution.
Note2: In real-time, if we have faced some issues such as:

Issues Handle by

New features Manual test engineer

DIWAKAR EDUCATION HUB Page 133

 SOFTWARE ENGINEERING UNIT – 6

Regressing testing features Automation test engineer

Remaining ( 110 feature + Release#1) Manual test engineer

Step1
When the new release starts, we don't go for the automation because there is no concept of
regression testing and regression test case as we understood this in the above process.
Step2
When the new release and the enhancement starts, we have two teams, i.e., manual team and
the automation team.
Step3
The manual team will go through the requirements and also identify the impact area and hand
over the requirement test suite to the automation team.
Step4
Now, the manual team starts working on the new features, and the automation team will start
developing the test script and also start automating the test case, which means that the
regression test cases will be converted into the test script.
Step5
Before they (automation team) start automating the test case, they will also analyze which all
cases can be automated or not.
Step6
Based on the analysis, they will start the automation i.e., converting every regression test
cases into the test script.
Step7
During this process, they will take help of the Regression cases because they don't have
product knowledge as well as the tool and the application.
Step8
Once the test script is ready, they will start the execution of these scripts on the new
application [old feature]. Since, the test script is written with the help of the regression feature
or the old feature.
Step9
Once the execution is completed, we get a different status like Pass/fail.
Step10
If the status is failed, which means it needs to be re-confirmed manually, and if the Bug exists,
then it will report to the concerned developer. When the developer fixes that bug, the Bug
needs to be re-tested along with the Impact area by the manual test engineer, and also the
script needs to be re-executed by the automation test engineer.
Step11

DIWAKAR EDUCATION HUB Page 134

 SOFTWARE ENGINEERING UNIT – 6
This process goes on until all the new features, and the regression feature will be passed.

Benefits of doing regression testing by the automation testing:

o Accuracy always exists because the task is done by the tools and tools never get bored
or tired.
o The test script can be re-used across multiple releases.
o Batch execution is possible using the automation i.e.; all the written test scripts can be
executed parallel or simultaneously.
o Even though the number of regression test case increase release per release, and we
don't have to increase the automation resource since some regression case are already
automated from the previous release.
o It is a time-saving process because the execution is always faster than the manual
method.
How to select test cases for regression testing?
It was found from industry inspection. The several defects reported by the customer were due
to last-minute bug fixes. These creating side effects and hence selecting the Test Case for
regression testing is an art, not an easy task.
Regression test can be done by:
o A test case which has frequent defects
o Functionalities which are more visible to users.
o Test cases verify the core features of the product.
o All integration test cases
o All complex test cases
o Boundary value test cases
o A sample of successful test cases

DIWAKAR EDUCATION HUB Page 135

 SOFTWARE ENGINEERING UNIT – 6
o Failure of test cases
Regression testing tools
If Software undergoes frequent changes, regression testing costs also increase. In those cases,
manual execution of test cases increases test execution time as well as costs. In that case,
automation testing is the best choice. The duration of automation depends on the number of
test cases that remain reusable for successive regression cycles.
Following are the essential tools used for regression testing:
Selenium
Selenium is an open-source tool. This tool used for automated testing of a web application. For
browser-based regression testing, selenium used. Selenium used for UI level regression test
for web-based application.
Ranorex Studio
All in one regression test automation for desktop, web, and mobile apps with built-in Selenium
Web Driver. Ranorex Studio includes full IDE plus tools for codeless automation.
Quick Test Professional (QTP)
QTP is an automated testing tool used for Regression and Functional Testing. It is a Data-
Driven, keyword-based tool. It used VBScript language for automation. If we open the QTP
tool, we see the three buttons which are Record, Play and Stop. These buttons help to record
every click and action performed on the computer system. It records the actions and play it
back.

Rational Functional Tester (RTF)

Rational functional tester is a Java tool used to automate the test cases of software
applications. RTF used for automating regression test cases, and it also integrates with the
rational functional tester.
What are the Regression Testing and Configuration Management?
Configuration Management in the regression testing becomes imperative in Agile
Environments, where a code is continuously modified. To ensure a valid regression test, we
must follow the steps:
o Changes are not allowed in the code during the regression testing phase.
o A regression test case must be unaffected developer changes.

DIWAKAR EDUCATION HUB Page 136

 SOFTWARE ENGINEERING UNIT – 6
o The database used for regression testing must be isolated; changes are not allowed in
the database.
What are the differences between Retesting and Regression Testing?
Re-testing Testing means testing the functionality or bug again to ensure the code fixed. If not
set, defects need not be re-opened. If fixed, the defect closed.
Re-testing is a type of testing which performed to check the test-cases that were unsuccessful
in the final execution are successfully pass after the defects repaired.
Regression Testing means testing the software application when it undergoes a code change
to ensure that new code has not affected other parts of the Software.
Regression testing is a type of testing executed to check whether a code has not changed the
existing functionality of the application.
Advantages of Regression Testing are:
o Regression Testing increases the product's quality.
o It ensures that any bug fix or changes do not impact the existing functionality of the
product.
o Automation tools can be used for regression testing.
o It makes sure the issues fixed do not occur again.
What are the disadvantages of Regression Testing?
There are several advantages of Regression Testing though there are disadvantages as well.
o Regression Testing should be done for small changes in the code because even a slight
change in the code can create issues in the existing functionality.
o If in case automation is not used in the project for testing, it will time consuming and
tedious task to execute the test again and again.
Performance Testing
In this section, we will learn about performance testing, why we need it, types of performance
testing, and the performance testing process.
Following are the topics, which we will understand in this section:
What is performance testing?
It is the most important part of non-functional testing.
Checking the behavior of an application by applying some load is known as performance
testing.
Generally, this testing defines how quickly the server responds to the user's request.
While doing performance testing on the application, we will concentrate on the various factors
like Response time, Load, and Stability of the application.
Response time: Response time is the time taken by the server to respond to the client's
request.
Load: Here, Load means that when N-number of users using the application simultaneously or
sending the request to the server at a time.
Stability: For the stability factor, we can say that, when N-number of users using the
application simultaneously for a particular time.

DIWAKAR EDUCATION HUB Page 137

 SOFTWARE ENGINEERING UNIT – 6
When we use performance testing?
We will do performance testing once the software is stable and moved to the production, and
it may be accessed by the multiple users concurrently, due to this reason, some performance
issues may occur. To avoid these performance issues, the tester performs one round of
performance testing.
Since it is non-functional testing which doesn't mean that we always use performance testing,
we only go for performance testing when the application is functionally stable.
Note: Performance testing cannot be done manually since its costly and accurate result can't
be maintained.
Types of Performance Testing
Following are the types of performance testing:
o Load testing
o Stress testing
o Scalability testing
o Stability testing

discuss one by one to give you a complete understanding of Load, Stress,

Scalability, and Stability performance testing.
Load testing
The load testing is used to check the performance of an application by applying some load
which is either less than or equal to the desired load is known as load testing.
For example: In the below image, 1000 users are the desired load, which is given by the
customer, and 3/second is the goal which we want to achieve while performing a load testing.

DIWAKAR EDUCATION HUB Page 138

 SOFTWARE ENGINEERING UNIT – 6
Stress Testing
The stress testing is testing, which checks the behavior of an application by applying load
greater than the desired load.
For example: If we took the above example and increased the desired load 1000 to 1100
users, and the goal is 4/second. While performing the stress testing in this scenario, it will pass
because the load is greater (100 up) than the actual desired load.

Scalability Testing
Checking the performance of an application by increasing or decreasing the load in particular
scales (no of a user) is known as scalability testing. Upward scalability and downward
scalability testing are called scalability testing.
Scalability testing is divided into two parts which are as follows:
o Upward scalability testing
o Downward scalability testing
Upward scalability testing
It is testing where we increase the number of users on a particular scale until we get a crash
point. We will use upward scalability testing to find the maximum capacity of an application.
Downward scalability testing
The downward scalability testing is used when the load testing is not passed, then
start decreasing the no. of users in a particular interval until the goal is achieved. So that it is
easy to identify the bottleneck (bug).
Stability Testing
Checking the performance of an application by applying the load for a particular duration of
time is known as Stability Testing.
Performance testing example
Let us take one example where we will test the behavior of an application where the desired
load is either less than 1000 or equal to 1000 users.
In the below image, we can see that the 100 up users are increased continuously to check
the maximum load, which is also called upward scalability testing.
o Scenario1: When we have the 1000 users as desired load, and the 2.7/sec is goal time,
these scenarios will pass while performing the load test because in load testing, we will
concentrate on the no. of users, and as per the requirement it is equal to 1000 user.
o Scenario2: In the next scenario, we will increase the desired load by 100 users, and goal
time will go up to 3.5\sec. This scenario will pass if we perform stress testing because
here, the actual load is greater than (1100) the desired load (1000).

DIWAKAR EDUCATION HUB Page 139

 SOFTWARE ENGINEERING UNIT – 6
o Scenario3: In this, if we increase the desired load three times as
1200 → 3.5\sec: [it is not less than or equal to the desired load that's why it will Fail]
1300 → 4\sec: [it is not less than or equal to the desired load. i.e., Fail]
1400 → Crashed

Note1: Volume and soak testing is a type of testing but not performance testing.
Volume testing
Volume testing is testing, which helps us to check the behavior of an application by inserting a
massive volume of the load in terms of data is known as volume testing, and here, we will
concentrate on the number of data rates than the number of users.
Note2:
Volume is a capacity while Load is a quantity, i.e., load testing means no. of users, and volume
testing means amount of data.
Soak testing
In this type of testing, we will check the behavior of an application on the environment, which
is unsupportive for a long duration of time is known as soak testing.
Generally, soak testing is a negative type of testing since we already know that the server or
environment is not supportive.
Performance testing process
The performance testing cannot be done manually since:
o We need a lot of resources, and it became a costlier approach.
o And the accuracy cannot maintain when we track response time manually.
The Performance testing process will be completed in the following steps:
o Identify performance scenarios
o Plan and design performance test script
o Configure the test environment & distribute the load
o Execute test scripts

DIWAKAR EDUCATION HUB Page 140

 SOFTWARE ENGINEERING UNIT – 6
o Result
o Analysis result
o Identify the Bottleneck
o Re-run test

If we perform a positive flow of the performance testing process, it could follow the below
process:
Identify performance scenarios
Firstly, we will identify the performance scenarios based on these below factors:
Most commonly scenarios: It means that we can find the performance scenarios based on the
scenarios, which commonly used like in the Gmail application; we will perform login, inbox,
send items, and compose a mail and logout.
Most critical scenarios: Critical scenarios mean regularly used and important for the business-
like in Gmail application login, compose, inbox, and logout.
Huge data transaction: If we have huge data means that n-number of the users using the
application at the same time.
Once we identify the performance scenarios, we will move to the next step.
Plan and design performance test script
In this step, we will install the tools in the Test Engineer Machine and access the test server
and then we write some script according to the test scenarios and run the tool.
Once we are done with writing the script, we will go to the next step.
Configure the test environment & distribute the load
DIWAKAR EDUCATION HUB Page 141
 SOFTWARE ENGINEERING UNIT – 6
After writing the test scripts, we will arrange the testing environment before the execution.
And also, manage the tools, other resources and distribute the load according to the "Usage
Pattern" or mention the duration and stability.
Execute test scripts
Once we are done with distributing the load, we will execute, validate, and monitor the test
scripts.
Result
After executing the test scripts, we will get the test result. And check that the result meeting
the goal in the given response time or not, and the response time could be maximum, average,
and minimum.
If the response is not meeting the required time response, then we will go for the negative
flow where will perform the below steps:
Analysis result
First, we will analyze the test result whether it meets with the response time or not.
Identify the Bottleneck
After that, we will identify the bottleneck (bug or performance issue). And the bottleneck
could occur because of these aspects like the problem in code, hardware issue (hard disk,
RAM Processor), network issues, and the software issue (operating system). And after finding
the bottleneck, we will perform tuning (fix or adjustment) to resolve this bottleneck.
Re-run test
Once we fix the bottlenecks, re-run the test scripts and checks the result whether it meets the
required goal or not.
The problem occurs in performance testing
While performing performance testing on the application, some problems may occur, and
these problems are also called the performance issue.
The performance issues are as follows:
o Response time issue
o Scalability issue
o Bottleneck
o Speed issue
Response time issue
The response time means how quickly the server respond to the client's request. If the user's
request does not complete in the given response time, it might have possible that the user
may be lost his/her interest in the particular software or application. That's why the
application or software should have a perfect response time for responding user's request
quickly.
Scalability issue
The scalability issues occur when the application cannot take the n-numbers of users and
expected user requests at the same time. That's why we will do upward scalability
testing (check the maximum capacity of the application) and downward scalability
testing (when expected time is not matched with the actual time).
DIWAKAR EDUCATION HUB Page 142
 SOFTWARE ENGINEERING UNIT – 6
Bottleneck
The Bottleneck is the informal name of bug, which occurs when the application is limited by a
single component and creates a bad impact on the system performance.
The main causes of bottlenecking are software issues (issue related to the operating system),
hardware issues (issues related to the hard disk, RAM and the processor), and coding
issue, etc.
Following are the most common performance bottlenecks:
o Memory utilization
o Disk usage
o CPU utilization
o Operating System limitations
o Network utilization
Speed issues
When we perform performance testing on the application, the application should be faster in
speed to get the user's interest and attention because if the application's speed is slow, it may
lose the user interest in the application.
Performance test tools
We have various types of performance testing tools available in the market, where some are
commercial tools and open-source tool.
Software Re-Engineering
Software Re-Engineering is the examination and alteration of a system to reconstitute it in a
new form. The principles of Re-Engineering when applied to the software development
process is called software re-engineering. It affects positively at software cost, quality, service
to the customer and speed of delivery. In Software Re-engineering, we are improving the
software to make it more efficient and effective.
Re-Engineering cost factors:
 The quality of the software to be re-engineered.
 The tool support availability for engineering.
 Extent of the data conversion which is required.
 The availability of expert staff for Re-engineering.

DIWAKAR EDUCATION HUB Page 143

 SOFTWARE ENGINEERING UNIT – 6

Software Re-Engineering Activities:

1. Inventory Analysis: Every software organisation should have an inventory of all the
applications.
 Inventory can be nothing more than a spreadsheet model containing information that
provides a detailed description of every active application.
 By sorting this information according to business criticality, longevity, current
maintainability and other local important criteria, candidates for re-engineering appear.
 Resource can then be allocated to candidate application for re-engineering work.
2. Document reconstructing: Documentation of a system either explains how it operate or
how to use it.
 Documentation must be updated.
 It may not be necessary to fully document an application.
 The system is business critical and must be fully re-documented.
3. Reverse Engineering: Reverse engineering is a process of design recovery. Reverse
engineering tools extracts data, architectural and proccedural design information from an
existing program.
4. Code Reconstructing:
 To accomplish code reconstructing, the source code is analysed using a reconstructing
tool. Violations of structured programming construct are noted and code is then
reconstruct.
 The resultant restructured code is reviewed and tested to ensure that no anomalies
have been introduced.
5. Data Restructuring:
 Data restructuring begins with the reverse engineering activity.
 Current data architecture is dissecred, and necessary data models are defined.
 Data objects and attributes are identified, and existing data structure are reviewed for
quality.
DIWAKAR EDUCATION HUB Page 144
 SOFTWARE ENGINEERING UNIT – 6
6. Forward Engineering: Forward Engineering also called as renovation or reclamation not only
for recovers design information from existing software but uses this information to alter or
reconstitute the existing system in an effort to improve its overall quality.
Software Reverse Engineering
Software Reverse Engineering is a process of recovering the design, requirement
specifications and functions of a product from an analysis of its code. It builds a program
database and generates information from this.
The purpose of reverse engineering is to facilitate the maintenance work by improving the
understandability of a system and to produce the necessary documents for a legacy system.
Reverse Engineering Goals:
 Cope with Complexity.
 Recover lost information.
 Detect side effects.
 Synthesise higher abstraction.
 Facilitate Reuse.

DIWAKAR EDUCATION HUB Page 145

 SOFTWARE ENGINEERING UNIT – 6

Steps of Software Reverse Engineering:

1. Collection Information: This step focuses on collecting all possible information (i.e.,
source design documents etc.) about the software.
2. Examining the information: The information collected in step-1 as studied so as to get
familiar with the system.
3. Extracting the structure: This step concerns with identification of program structure in
the form of structure chart where each node corresponds to some routine.
4. Recording the functionality: During this step processing details of each module of the
structure, charts are recorded using structured language like decision table, etc.
5. Recording data flow: From the information extracted in step-3 and step-4, set of data
flow diagrams are derived to show the flow of data among the processes.
DIWAKAR EDUCATION HUB Page 146
 SOFTWARE ENGINEERING UNIT – 6
6. Recording control flow: High level control structure of the software is recorded.
7. Review extracted design: Design document extracted is reviewed several times to
ensure consistency and correctness. It also ensures that the design represents the
program.
8. Generate documentation: Finally, in this step, the complete documentation including
SRS, design document, history, overview, etc. are recorded for future use.

DIWAKAR EDUCATION HUB Page 147

DIWAKAR EDUCATION HUB

SOFTWARE ENGINEERING
UNIT – 6 MCQs
AS PER UPDATED SYLLABUS
DIWAKAR EDUCATION HUB

THE LEARN WITH EXPERTIES

DIWAKAR EDUCATION HUB Page 1
 SOFTWARE ENGINEERING UNIT – 6 MCQs
1. Build & Fix Model is suitable for Answer: b
programming exercises of ___________ LOC Explanation: A prototyping model generates
(Line of Code). only a working model of a system.
a) 100-200 6. Which of the following statements
b) 200-400 regarding Build & Fix Model is wrong?
c) 400-1000 a) No room for structured design
d) above 1000 b) Code soon becomes unfixable &
Answer: a unchangeable
Explanation: Build & Fix Model is suitable for c) Maintenance is practically not possible
small projects & programming exercises of d) It scales up well to large projects
100 or 200 lines. Answer: d
2. RAD stands for Explanation: Build & Fix Model is suitable for
a) Relative Application Development 100-200 LOC
b) Rapid Application Development 7. RAD Model has
c) Rapid Application Document a) 2 phases
d) None of the mentioned b) 3 phase
Answer: b c) 5 phases
3. Which one of the following models is not d) 6 phases
suitable for accommodating any change? Answer: c
a) Build & Fix Model Explanation: RAD Model consists of five
b) Prototyping Model phases namely:Business modeling,Data
c) RAD Model modeling,Process modeling,Application
d) Waterfall Model generation and Testing & Turnover.
Answer: d 8. What is the major drawback of using RAD
Explanation: Real projects rarely follow the Model?
sequential flow that the Waterfall Model a) Highly specialized & skilled
proposes. developers/designers are required
4. Which is not one of the types of prototype b) Increases reusability of components
of Prototyping Model? c) Encourages customer/client feedback
a) Horizontal Prototype d) Increases reusability of components,
b) Vertical Prototype Highly specialized & skilled
c) Diagonal Prototype developers/designers are required
d) Domain Prototype Answer: d
Answer: c Explanation: The client may create an
Explanation: Their is no such thing as unrealistic product vision leading a team to
Diagonal Prototype whereas other options over or under-develop [Link], the
have their respective definitions. specialized & skilled developers are not easily
5. Which one of the following is not a phase available.
of Prototyping Model? 9. SDLC stands for
a) Quick Design a) Software Development Life Cycle
b) Coding b) System Development Life cycle
c) Prototype Refinement c) Software Design Life Cycle
d) Engineer Product d) System Design Life Cycle
Answer: a

DIWAKAR EDUCATION HUB Page 2

 SOFTWARE ENGINEERING UNIT – 6 MCQs
10. Which model can be selected if user is other models as well like RAD model,hence
involved in all the phases of SDLC? option “d” answers the question.
a) Waterfall Model 14. The spiral model was originally proposed
b) Prototyping Model by
c) RAD Model a) IBM
d) both Prototyping Model & RAD Model b) Barry Boehm
Answer: c c) Pressman
11. Which one of the following is not an d) Royce
Evolutionary Process Model? Answer: b
a) WINWIN Spiral Model 15. The spiral model has two dimensions
b) Incremental Model namely _____________ and ____________
c) Concurrent Development Model a) diagonal, angular
d) All of the mentioned b) radial, perpendicular
Answer: d c) radial, angular
12. The Incremental Model is a result of d) diagonal, perpendicular
combination of elements of which two Answer: c
models? Explanation: The radial dimension of the
a) Build & FIX Model & Waterfall Model model represents the cumulative costs and
b) Linear Model & RAD Model the angular dimension represents the
c) Linear Model & Prototyping Model progress made in completing each cycle. Each
d) Waterfall Model & RAD Model loop of the spiral from X-axis clockwise
Answer: c through 360o represents one phase.
Explanation: Each linear sequence produces 16. How is WINWIN Spiral Model different
a deliverable “increment” of the software from Spiral Model?
and particularly when we have to quickly a) It defines tasks required to define
deliver a limited functionality system. resources, timelines, and other project
13. What is the major advantage of using related information
Incremental Model? b) It defines a set of negotiation activities at
a) Customer can respond to each increment the beginning of each pass around the spiral
b) Easier to test and debug c) It defines tasks required to assess both
c) It is used when there is a need to get a technical and management risks
product to the market early d) It defines tasks required to construct, test,
d) Easier to test and debug & It is used when install, and provide user support
there is a need to get a product to the market Answer: b
early Explanation: Except option “b” all other
Answer: d tasks/activities are present in Spiral Model as
Explanation: Incremental Model is generally well.
easier to test and debug than other methods 17. Identify the disadvantage of Spiral Model.
of software development because relatively a) Doesn’t work well for smaller projects
smaller changes are made during each b) High amount of risk analysis
iteration and is popular particularly when we c) Strong approval and documentation
have to quickly deliver a limited functionality control
[Link], option “a” can be seen in d) Additional Functionality can be added at a
later date

DIWAKAR EDUCATION HUB Page 3

 SOFTWARE ENGINEERING UNIT – 6 MCQs
Answer: a a) Waterfall & RAD
Explanation: All other options are the b) Prototyping & Spiral
advantages of Spiral Model. c) Prototyping & RAD
18. Spiral Model has user involvement in all d) Waterfall & Spiral
its phases. Answer: b
a) True Explanation: Prototyping Model starts with a
b) False requirements analysis phase including
Answer: b techniques like FAST, QFD, [Link]
19. How is Incremental Model different from case of Spiral model the first phase involves
Spiral Model? activities related to customer communication
a) Progress can be measured for Incremental like determining objectives.
Model 23. Which of the following life cycle model
b) Changing requirements can be can be chosen if the development team has
accommodated in Incremental Model less experience on similar projects?
c) Users can see the system early in a) Spiral
Incremental Model b) Waterfall
d) All of the mentioned c) RAD
Answer: a d) Iterative Enhancement Model
20. If you were to create client/server Answer: a
applications, which model would you go for? Explanation: Relying on risk
a) WINWIN Spiral Model assessment/analysis provides more flexibility
b) Spiral Model than required for many applications which
c) Concurrent Model overcomes the criteria of less experienced
d) Incremental Model developers.
Answer: c 24. If you were a lead developer of a software
Explanation: When applied to client/server company and you are asked to submit a
applications, the concurrent process model project/product within a stipulated time-
defines activities in two dimensions: a system frame with no cost barriers, which model
dimension and a component [Link] would you select?
Concurrency is achieved by system and a) Waterfall
component activities occurring b) Spiral
simultaneously and can be modeled using the c) RAD
state-oriented approach. d) Incremental
21. Selection of a model is based on Answer: c
a) Requirements Explanation: RAD model is inapplicable to
b) Development team & Users develop cheaper products/software/projects
c) Project type and associated risk as the cost of modeling, hiring highly skilled
d) All of the mentioned developers/designers and automated code
Answer: d generation is very [Link] here the cost is
Explanation: Each model has to have some not an issue, so one can select this model as
requirements, a team of developers, users it reduces development time.
and the risk involved in developing a project. 25. Which two of the following models will
22. Which two models doesn’t allow defining not be able to give the desired outcome if
requirements early in the cycle? user’s participation is not involved?

DIWAKAR EDUCATION HUB Page 4

 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Waterfall & Spiral 30. RAD Model has high reliability
b) RAD & Spiral requirements.
c) RAD & Waterfall a) True
d) RAD & Prototyping b) False
Answer: d Answer: b
Explanation: Active Participation of user is 31. Identify a fourth generation
involved in all the four phases of RAD model language(4GL) from the given below.
and in case of the Prototyping model we a) FORTRAN
need user’s presence/involvement every time b) COBOL
a new prototype is build or designed. c) Unix shell
26. A company is developing an advance d) C++
version of their current software available in Answer: c
the market, what model approach would Explanation: Rest all are third generation
they prefer ? languages(3GL).
a) RAD 32. Arrange the following activities for
b) Iterative Enhancement making a software product using 4GT.
c) Both RAD & Iterative Enhancement i. Design strategy
d) Spiral ii. Transformation into product
Answer: c iii. Implementation
27. One can choose Waterfall Model if the iv. Requirement gathering
project development schedule is tight. a) 1, 4, 3, 2
a) True b) 4, 3, 1, 2
b) False c) 4, 1, 3, 2
Answer: b d) 1, 3, 4, 2
Explanation: Real projects rarely follow the Answer: c
sequential flow and iterations in this model Explanation: The sequence of activities
are handled indirectly. This changes can mentioned in option c represents the Fourth
cause confusion as the project proceeds Generation Techniques(4GT)Model.
thereby delaying the delivery date. 33. 4GL is an example of ______________
28. Choose the correct option from given processing.
below: a) White Box
a) Prototyping Model facilitates reusability of b) Black Box
components c) Functional
b) RAD Model Model facilitates reusability of d) Both Black Box & Functional
components Answer: d
c) Both RAD & Prototyping Model facilitates Explanation: Functional processing/testing is
reusability of components also referred to as black box testing in which
d) None contents of the black box are not
Answer: c [Link] anything might be referred to
29. Spiral Model has high reliability as a black box:an algorithm or the human
requirements. [Link] of the black box is
a) True understood in terms of its inputs and
b) False outputs.
Answer: a
DIWAKAR EDUCATION HUB Page 5
 SOFTWARE ENGINEERING UNIT – 6 MCQs
34. The 4GT Model is a package of b) PROLOG
______________ c) C
a) CASE Tools d) JAVA
b) Software tools Answer: a
c) Software Programs Explanation: C & JAVA are third generation
d) None of the mentioned languages(3GLs) whereas PROLOG is a 5GL.
Answer: b 39. What is a major advantage of using a 4GT
Explanation: 4GT encompasses a broad array Model for producing small scale products,
of software tools enabling the software applications or programs ?
engineer to specify the characteristics at a a) Improved productivity of software
high level leading to an automatically engineers
generated source code based on these b) Reduction in software development time
specifications. c) 4GT helped by CASE tools and code
35. Which of the following is not a type of a generators offers a credible solution to many
4GL? One originating ______________ software problems
a) on Lisp machine d) None of the mentioned
b) on report generators Answer: b
c) from database query languages Explanation: Since automated coding is done
d) from GUI creators using CASE tools & code generators
Answer: a proponents claim a dramatic reduction in
Explanation: Fifth-generation programming software development time.
language are built on LISP. 40. Which of the following model has a major
36. In 4GT, we can specify the user disadvantage in terms of the coding phase of
requirements in graphic notation or small a software life cycle model ?
abbreviated language form. a) Spiral Model
a) True b) Waterfall Model
b) False c) Rad Model
Answer: a d) 4GT Model
37. Productivity of software engineers is Answer: d
reduced in using a 4GT. Explanation: Since coding phase is eliminated
a) True in 4GT Model,more expertise is required for
b) False analysis,design and testing activities.
Answer: b 41. Which one of the following is not a
Explanation: 4GLs are more programmer- software process quality?
friendly and enhance programming efficiency a) Productivity
with usage of English-like words and phrases, b) Portability
thereby increasing the productivity of c) Timeliness
professionals able to engage in software d) Visibility
development. Answer: b
38. Which of the following 4GLs invented at Explanation: Portability is a software product
IBM and subsequently adopted by ANSI and quality which means software can run on
ISO as the standard language for managing different hardware platforms or software
structured data? environments.
a) SQL

DIWAKAR EDUCATION HUB Page 6

 SOFTWARE ENGINEERING UNIT – 6 MCQs
42. _____________&_____________ are two i. support
kinds of software products. ii. development
a) CAD, CAM iii. definition
b) Firmware, Embedded a) 1, 2, 3
c) Generic, Customised b) 2, 1, 3
d) None of the mentioned c) 3, 2, 1
Answer: c d) 3, 1, 2
Explanation: rest all are sub Answer: c
categories/applications of option c. 47. Which of the following activities of a
43. Software costs more to maintain than it Generic Process framework provides a
does to develop. feedback report?
a) True a) Communication
b) False b) Planning
Answer: a c) Modeling & Construction
Explanation: For systems with a long life, d) Deployment
maintenance costs may be several times Answer: d
development costs. Explanation: In Deployment the product is
44. Which one of the following is not an delivered to the customer who evaluates the
application of embedded software product? product and provides feedback based on the
a) keypad control of a security system evaluation.
b) pattern recognition game playing 48. Process adopted for one project is same
c) digital function of dashboard display in a as the process adopted from another project.
car a) True
d) none of the mentioned b) False
Answer: b Answer: b
Explanation: Pattern recognition uses Explanation: the overall flow of activities,
Artificial Intelligence (AI) software. actions,tasks,the level of autonomy given to
45. Purpose of process is to deliver software the software team and the inter
a) in time dependencies among two process can never
b) with acceptable quality be the same.
c) that is cost efficient 49. Which one of the following is not an
d) both in time & with acceptable quality Umbrella Activity that complements the five
Answer: d process framework activities and help team
Explanation: Cost of a software is a manage and control progress, quality,
management issue & is not related to process change, and risk.
activities. a) Reusability management
46. The work associated with software b) Risk management
engineering can be categorized into three c) Measurement
generic phases,regardless of application area, d) User Reviews
project size, or complexity namely Answer: d
the__________ phase which focuses 50. Four types of change are encountered
on what, the_________ phase which focuses during the support [Link] one of the
on how and the_________ phase which following is not one that falls into such
focuses on change. category?

DIWAKAR EDUCATION HUB Page 7

 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Translation 55. The only deliverable work product for a
b) Correction successful project is the working program.
c) Adaptation a) True
d) Prevention b) False
Answer: a Answer: b
Explanation: Translation is done in the Explanation: A working program is only one
development phase. part of a software configuration that includes
51. If a software production gets behind many elements. Documentation provides a
schedule, one can add more programmers foundation for successful engineering and,
and catch up. more important, guidance for software
a) True support.
b) False 56. Which phase of the RUP is used to
Answer: b establish a business case for the system ?
Explanation: As new people are added, a) Transition
people who were working must spend time b) Elaboration
educating the newcomers, thereby reducing c) Construction
the amount of time spent on productive d) Inception
development effort. Answer: d
52. Choose an internal software quality from 57. Which one of the following is not a
given below: fundamental activity for software processes
a) scalability in software engineering ?
b) usability a) Software Verification
c) reusability b) Software Validation
d) reliability c) Software design and implementation
Answer: c d) Software evolution
Explanation: rest all are external qualities Answer: a
which are visible to the user. Explanation: Software Verification is
53. RUP stands for____________ created by accounted for in implementation & testing
a division of ____________ activity.
a) Rational Unified Program, IBM 58. A general statement of objectives is the
b) Rational Unified Process, Infosys major cause of failed software efforts.
c) Rational Unified Process, Microsoft a) True
d) Rational Unified Process, IBM b) False
Answer: d Answer: a
54. The RUP is normally described from three Explanation: A formal and detailed
perspectives-dynamic, static & [Link] description of the information domain,
does static perspective do ? function, behavior, performance, interfaces,
a) It shows the process activities that are design constraints and validation criteria is
enacted essential which can be determined only after
b) It suggests good practices to be used thorough communication between customer
during the process and developer.
c) It shows the phases of the model over time 59. The longer a fault exists in software
d) All of the mentioned a) the more tedious its removal becomes
Answer: a b) the more costly it is to detect and correct

DIWAKAR EDUCATION HUB Page 8

 SOFTWARE ENGINEERING UNIT – 6 MCQs
c) the less likely it is to be properly corrected They are iterative because they work on one
d) All of the mentioned iteration followed by improvements in next
Answer: d iteration
60. Component-based Software Engineering 64. Which on of the following is not an agile
allows faster delivery. method?
a) True a) XP
b) False b) 4GT
Answer: a c) AUP
Explanation: Due to using previously tested d) All of the mentioned
components they produce more reliable Answer: b
system at a faster rate. Explanation: The 4GT approach does not
61. Arrange the following steps to form a incorporate iteration and the continuous
basic/general Engineering Process Model. feedback,which is the fundamental aspect of
i. Test an agile method.
ii. Design 65. Agility is defined as the ability of a project
iii. Install team to respond rapidly to a change.
iv. Specification a) True
v. Manufacture b) False
vi. Maintain Answer: b
a) 2, 4, 5, 1, 6, 3 Explanation: The aim of agile methods is to
b) 4, 2, 5, 1, 3, 6 reduce overheads in the software process
c) 2, 4, 5, 1, 3, 6 and to be able to respond quickly to changing
d) 4, 2, 5, 1, 6, 3 requirements without excessive rework.
Answer: b 66. How is plan driven development different
62. Select the option that suits the Manifesto from agile development ?
for Agile Software Development a) Outputs are decided through a process of
a) Individuals and interactions negotiation during the software development
b) Working software process
c) Customer collaboration b) Specification, design, implementation and
d) All of the mentioned testing are interleaved
Answer: d c) Iteration occurs within activities
63. Agile Software Development is based on d) All of the mentioned
a) Incremental Development Answer: c
b) Iterative Development Explanation: A plan-driven approach to
c) Linear Development software engineering is based around
d) Both Incremental and Iterative separate development stages with the
Development outputs to be produced at each of these
Answer: d stages planned in advance.
Explanation: The software is developed in 67. How many phases are there in Scrum ?
increments with the customer specifying the a) Two
requirements to be included in each b) Three
increment and the highest priority is to c) Four
satisfy the customer through early and d) Scrum is an agile method which means it
continuous delivery of valuable software. does not have phases

DIWAKAR EDUCATION HUB Page 9

 SOFTWARE ENGINEERING UNIT – 6 MCQs
Answer: b Answer: b
Explanation: There are three phases in Explanation: Incremental development is
[Link] initial phase is an outline planning supported through small, frequent system
phase followed by a series of sprint cycles releases.
and project closure phase. 73. In XP, as soon as the work on a task is
68. Agile methods seem to work best when complete, it is integrated into the whole
team members have a relatively high skill system.
level. a) True
a) True b) False
b) False Answer: a
Answer: a Explanation: XP follows a continuous
69. Which of the following does not apply to integration [Link] any such
agility to a software process? integration, all the unit tests in the system
a) Uses incremental product delivery strategy must pass.
b) Only essential work products are produced 74. In XP Increments are delivered to
c) Eliminate the use of project planning and customers every _______ weeks.
testing a) One
d) All of the mentioned b) Two
Answer: c c) Three
Explanation: Testing is a major part of each d) Four
software development process which can’t Answer: b
be avoided. Explanation: Extreme Programming (XP)
70. Which three framework activities are takes an ‘extreme’ approach to iterative
present in Adaptive Software [Link] versions may be built
Development(ASD) ? several times per day, hence delivering the
a) analysis, design, coding increment for approval every 2nd week after
b) requirements gathering, adaptive cycle testing the new version.
planning, iterative development 75. User requirements are expressed as
c) speculation, collaboration, learning __________ in Extreme Programming.
d) all of the mentioned a) implementation tasks
Answer: c b) functionalities
71. In agile development it is more important c) scenarios
to build software that meets the customers’ d) none of the mentioned
needs today than worry about features that Answer: c
might be needed in the future. Explanation: User requirements are
a) True expressed as scenarios or user [Link]
b) False are written on cards and the development
Answer: a team break them down into implementation
72. Incremental development in Extreme tasks. These tasks are the basis of schedule
Programming (XP) is supported through a and cost estimates.
system release once every month. 76. Is a customer involved test development
a) True and validation in XP ?
b) False a) Yes
b) No

DIWAKAR EDUCATION HUB Page 10

 SOFTWARE ENGINEERING UNIT – 6 MCQs
c) It may vary from Customer to Customer Answer: a
d) None of the mentioned Explanation: XP follows Test-first
Answer: c development approach.
Explanation: The role of the customer in the 80. Developers work individually on a release
testing process is to help develop acceptance and they compare their results with other
tests for the stories that are to be developers before forwarding that release to
implemented in the next release of the customers.
[Link], people adopting the a) True
customer role have limited time available and b) False
so cannot work full-time with the Answer: b
development team. They may feel that Explanation: XP follows the principle of pair
providing the requirements was enough of a programming which means developers work
contribution and so may be reluctant to get in pairs, checking each other’s work and
involved in the testing process. providing the support to always do a good
77. Programmers prefer programming to job.
testing and sometimes they take shortcuts 81. Which four framework activities are
when writing tests. For example, they may found in the Extreme Programming(XP) ?
write incomplete tests that do not check for a) analysis, design, coding, testing
all possible exceptions that may occur. b) planning, analysis, design, coding
a) True c) planning, design, coding, testing
b) False d) planning, analysis, coding, testing
Answer: a Answer: c
Explanation: In XP Some tests can be very Explanation: XP involves the mentioned four
difficult to write [Link] example, activities, and in the same in order.
in a complex user interface, it is often difficult 82. What are the types of requirements ?
to write unit tests for the code that a) Availability
implements the ‘display logic’ and workflow b) Reliability
between screens. c) Usability
78. Tests are automated in Extreme d) All of the mentioned
Programming. Answer: d
a) True Explanation: All the mentioned traits are
b) False beneficial for an effective product to be
Answer: a developed.
Explanation: Automated test harnesses are 83. Select the developer-specific requirement
used to run all component tests each time ?
that a new release is built. a) Portability
79. In XP an automated unit test framework is b) Maintainability
used to write tests for a new piece of c) Availability
functionality before that functionality itself is d) Both Portability and Maintainability
implemented. Answer: d
a) True Explanation: Availability is user specific
b) False requirement.
84. Which one of the following is not a step
of requirement engineering?
DIWAKAR EDUCATION HUB Page 11
 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) elicitation describe interactions the users will have with
b) design the software.
c) analysis 89. A stakeholder is anyone who will
d) documentation purchase the completed software system
Answer: b under development.
Explanation: Requirement Elicitation, a) True
Requirement Analysis, Requirement b) False
Documentation and Requirement Review are Answer: b
the four crucial process steps of requirement Explanation: Stakeholders are anyone who
[Link] is in itself a different has an interest in the project. Project
phase of Software Engineering. stakeholders are individuals and
85. FAST stands for organizations that are actively involved in the
a) Functional Application Specification project, or whose interests may be affected
Technique as a result of project execution or project
b) Fast Application Specification Technique completion.
c) Facilitated Application Specification 90. Conflicting requirements are common in
Technique Requirement Engineering, with each client
d) None of the mentioned proposing his or her version is the right one.
Answer: c a) True
86. QFD stands for b) False
a) quality function design Answer: a
b) quality function development Explanation: This situation is seen in every
c) quality function deployment field of work as each professional has his/her
d) none of the mentioned way of looking onto things & would argue to
Answer: c get his/her point approved.
87. A Use-case actor is always a person 91. Which is one of the most important
having a role that different people may play. stakeholder from the following ?
a) True a) Entry level personnel
b) False b) Middle level stakeholder
Answer: b c) Managers
Explanation: Use-case Actor is anything that d) Users of the software
needs to interact with the system, be it a Answer: d
person or another (external) system. Explanation: Users are always the most
88. The user system requirements are the important [Link] all, without
parts of which document ? users or customers, what’s the point of being
a) SDD in business?.
b) SRS 92. Which one of the following is a functional
c) DDD requirement ?
d) SRD a) Maintainability
Answer: b b) Portability
Explanation: Software requirements c) Robustness
specification (SRS), is a complete description d) None of the mentioned
of the behaviour of a system to be developed Answer: d
and may include a set of use cases that Explanation: All are non-functional

DIWAKAR EDUCATION HUB Page 12

 SOFTWARE ENGINEERING UNIT – 6 MCQs
requirements representing quality of the a) True
system. Functional requirements describe b) False
what the software has to do. Answer: a
93. Which one of the following is a Explanation: The behavior of functional
requirement that fits in a developer’s module requirements may be expressed as services,
? tasks or functions the system is required to
a) Availability perform.
b) Testability 97. Choose the incorrect statement with
c) Usability respect to Non-Functional Requirement(NFR).
d) Flexibility a) Product-oriented Approach – Focus on
Answer: b system (or software) quality
Explanation: A developer needs to test his b) Process-oriented Approach – Focus on how
product before launching it into the market. NFRs can be used in the design process
94. “Consider a system where, a heat sensor c) Quantitative Approach – Find measurable
detects an intrusion and alerts the security scales for the functionality attributes
company.” What kind of a requirement the d) Qualitative Approach – Study various
system is providing ? relationships between quality goals
a) Functional Answer: c
b) Non-Functional Explanation: Quantitative Approaches in
c) Known Requirement NFRs are used to find measurable scales for
d) None of the mentioned the quality attributes like efficiency,
Answer: a flexibility, integrity, usability etc.
Explanation: Functional requirements 98. How many classification schemes have
describe what the software has to do. been developed for NFRs ?
95. Which of the following statements a) Two
explains portability in non-functional b) Three
requirements? c) Four
a) It is a degree to which software running on d) Five
one platform can easily be converted to run Answer: d
on another platform Explanation: Software Quality Tree [Boehm
b) It cannot be enhanced by using languages, 1976], Roman [IEEE Computer 1985],
OS’ and tools that are universally available Process-Product-External considerations
and standardized [Sommerville 1992], Mc Call’s NFR list and
c) The ability of the system to behave Dimensions of Quality–Components of
consistently in a user-acceptable manner FURPS+ are the five classification schemes for
when operating within the environment for NFRs.
which the system was intended 99. According to components of FURPS+,
d) None of the mentioned which of the following does not belong to S ?
Answer: a a) Testability
Explanation: Option c is termed as reliability b) Speed Efficiency
and option e refers to efficiency. c) Serviceability
96. Functional requirements capture the d) Installability
intended behavior of the system.

DIWAKAR EDUCATION HUB Page 13

 SOFTWARE ENGINEERING UNIT – 6 MCQs
Answer: b 104. Starting from least to most important,
Explanation: Speed Efficiency belong to choose the order of stakeholder.
Performance (P) in FURPS+ . i. Managers
100. Does software wear & tear by ii. Entry level Personnel
decomposition ? iii. Users
a) Yes iv. Middle level stakeholder
b) No a) i, ii, iv, iii
Answer: b b) i, ii, iii, iv
Explanation: Unlike hardware, software is c) ii, iv, i, iii
reliable. d) All of the mentioned
101. What are the four dimensions of Answer: c
Dependability ? Explanation: Users are your customers, they
a) Usability, Reliability, Security, Flexibility will be using your product, thus making them
b) Availability, Reliability, Maintainability, most important of all.
Security 105. Arrange the tasks involved in
c) Availability, Reliability, Security, Safety requirements elicitation in an appropriate
d) Security, Safety, Testability, Usability manner.
Answer: c i. Consolidation
Explanation: All the traits of option c sync ii. Prioritization
with dependability. iii. Requirements Gathering
102. Choose the correct statement on how iv. Evaluation
NFRs integrates with Rational Unified Process a) iii, i, ii, iv
? b) iii, iv, ii, i
a) System responds within 4 seconds on c) iii, ii, iv, i
average to local user requests and changes in d) ii, iii, iv, i
the environment Answer: b
b) System responds within 4 seconds on Explanation: Requirements gathering
average to remote user requests and changes captures viewpoint from different users
in the environment followed by evaluation of those view
c) All of the mentioned [Link] comes the task of checking the
d) None of the mentioned relative importance of the requirements and
Answer: b finally to consolidate or bind together the
Explanation: System response to a local user information collected.
is 2 seconds on average 106. What are the types of requirement in
103. What is the first step of requirement Quality Function Deployment(QFD) ?
elicitation ? a) Known, Unknown, Undreamed
a) Identifying Stakeholder b) User, Developer
b) Listing out Requirements c) Functional, Non-Functional
c) Requirements Gathering d) Normal, Expected, Exciting
d) All of the mentioned Answer: d
Answer: a Explanation: According to QFD, Normal,
Explanation: Stakeholders are the one who Expected and Exciting requirements
will invest in and use the product, so its maximizes customer satisfaction from the
essential to chalk out stakeholders first. Software Engineering Process.

DIWAKAR EDUCATION HUB Page 14

 SOFTWARE ENGINEERING UNIT – 6 MCQs
107. What kind of approach was introduced a) JAD
for elicitation and modelling to give a b) Traceability
functional view of the system ? c) FAST
a) Object Oriented Design (by Booch) d) Both JAD and Traceability
b) Use Cases (by Jacobson) Answer: d
c) Fusion (by Coleman) Explanation: Joint application design (JAD) is
d) Object Modeling Technique (by a process used to collect business
Rumbaugh) requirements while developing new
Answer: b information systems for a company.
Explanation: Use Case captures who does Requirements traceability is concerned with
what with the system, for what purpose, documenting the life of a requirement and
without dealing with system internals. providing bi-directional traceability between
108. What are the kinds of actors used in various associated requirements.
OOSE ? 111. Requirements elicitation is a cyclic
a) Primary process
b) Secondary a) True
c) Ternary b) False
d) Both Primary and Secondary Answer: a
Answer: d Explanation: Requirements traceability
Explanation: A primary actor is one having a provides bi-directional traceability between
goal requiring the assistance of the system various associated requirements.
whereas, a secondary actor is one from which 112. How many Scenarios are there in
system needs [Link] is no such elicitation activities ?
thing as ternary actor in Software a) One
Engineering. b) Two
109. Why is Requirements Elicitation a c) Three
difficult task ? d) Four
a) Problem of scope Answer: d
b) Problem of understanding Explanation: As-is Scenario, Visionary
c) Problem of volatility Scenario, Evaluation Scenario and Training
d) All of the mentioned Scenario are the four scenarios in
Answer: d requirement elicitation activities.
Explanation: Users specify unnecessary 113. Which of the following elicitation
technical detail that may confuse, rather than techniques is a viewpoint based method?
clarify overall system [Link], the a) FODA
customers/users are not completely sure of b) QFD
what is needed, have a poor understanding c) CORE
of the capabilities and limitations of their d) IBIS
computing environment and they do not Answer: c
understand that the requirements change Explanation: Controlled Requirements
over time. Expression(CORE) says that any system can
110. What requirement gathering method be viewed from a number of view points and
developed at IBM in 1970s is used for that a complete picture of system
managing requirement elicitation ?

DIWAKAR EDUCATION HUB Page 15

 SOFTWARE ENGINEERING UNIT – 6 MCQs
requirements can only emerge by putting each view point to structure the view point
together the various viewpoints. and to check consistency from within and
114. ___________ and ____________ are the outside the viewpoints.
two view points discussed in Controlled 118. Which of the following Requirement
Requirements Expression (CORE). Elicitation Techniques removes the poor
a) Functional, Non-Functional understanding of application domain and lack
b) User, Developer of common terminology between the users
c) Known, Unknown and the analysts ?
d) All of the mentioned a) FODA
Answer: a b) CORE
Explanation: The CORE sessions includes the c) IBIS
discussion of functional and non-functional d) Prototyping
requirements. Answer: a
115. What is the major drawback of CORE ? Explanation: Feature Oriented Domain
a) Requirements are comprehensive Analysis (FODA) is defined as the process of
b) NFRs are not given enough importance identifying, collecting, organizing and
c) Role of analyst is passive representing relevant information in a
d) All of the mentioned domain .
Answer: c 119. How many steps are involved in Feature
Explanation: In CORE the requirement Oriented Domain Analysis (FODA) ?
specification are put together by all users, a) Two
customers and analysts, so a passive analyst b) Three
will not get the requirements properly. c) Four
116. Choose a framework that corresponds to d) Five
Issue Based Information System (IBIS). Answer: b
a) Idea -> Question -> Argument Explanation: Context Analysis, Domain
b) Question -> Idea -> Argument Modeling and Architecture Modeling are the
c) Issue -> Position -> Justification three steps involved in Feature Oriented
d) Both Question -> Idea -> Argument and Domain Analysis (FODA).
Issue -> Position -> Justification 120. IBIS is a more structured approach than
Answer: d CORE.
Explanation: IBIS is a simple and non- a) True
intrusive method that provides a framework b) False
for resolving issues and gathering Answer: a
requirements. Explanation: IBIS is a more structured
117. How is CORE different from IBIS ? approach as it captures information which is
a) Iterative in nature consistent and [Link] the other hand
b) Redundancies are removed CORE gives importance to every view point
c) It is simple and an easier method to use even if it is obsolete.
d) Consistency problems are addressed in 121. Which one of the following is not an
CORE actor in JAD sessions ?
Answer: d a) User
Explanation: Preliminary data collection is b) Tester
done in CORE to get some broad level data on

DIWAKAR EDUCATION HUB Page 16

 SOFTWARE ENGINEERING UNIT – 6 MCQs
c) Scribe a) Ease of software installation
d) Sponsor b) Overall operational correctness and
Answer: b reliability
Explanation: A Tester’s role is seen in after c) Specific system functions
coding phase rather than in elicitation phase. d) Quality graphical display
122. What of the following is not an output of Answer: c
a JAD session ? Explanation: Expected requirements are so
a) Context Diagrams fundamental that a customer does not
b) DFDs explicitly state [Link] functions comes
c) ER model under the category of Normal requirements
d) UML diagrams in QFD which is compulsory to be
Answer: d defined,hence is not an expected
Explanation: Unified Modeling Language requirement.
(UML) diagrams are constructed during the 126. QFD works best if it has management
design phase of the SDLC. commitment.
123. How is brainstorming different from JAD a) True
? Brainstorming sessions b) False
a) last for about 2-3 hours Answer: a
b) last for about 2-3 days Explanation: QFD involves heavy investment
c) cover the technology used for the in initial stages, thus bounding the
development management to provide appropriate funding
d) all of the mentioned for the development process .
Answer: a 127. Which of the following Requirement
Explanation: Brainstorming is a group or Elicitation Techniques is applicable to messy,
individual creativity technique by which changing and ill-defined problem situations ?
efforts are made to find a conclusion for a a) Quality Function Deployment (QFD)
specific problem by gathering a list of ideas b) Prototyping
spontaneously contributed by its c) Soft Systems Methodology (SSM)
member(s).The idea is to quickly reach to an d) Controlled Requirements Expression
approved solution ASAP. (CORE)
124. How is throwaway prototype different Answer: c
from evolutionary prototype ? Explanation: Soft systems methodology
a) It involves successive steps (SSM) is a systemic approach for tackling real-
b) It involves just one task world problematic [Link] is a common
c) The prototype is built with the idea that it misunderstanding that SSM is a methodology
will eventually be converted into final system for dealing solely with ‘soft problems’
d) It has a shorter development time (problems which involve psychological, social,
Answer: b and cultural elements). SSM does not
Explanation: Except option b all other differentiate between ‘soft’ and ‘hard’
options represent the characteristics of an problems, it merely provides a different way
evolutionary prototype. of dealing with situations perceived as
125. Keeping the requirements of QFD in problematic.
mind which of the following is not an 128. To ensure that a given root definition is
example of an Expected Requirement ? rigorous and comprehensive, The Lancaster

DIWAKAR EDUCATION HUB Page 17

 SOFTWARE ENGINEERING UNIT – 6 MCQs
team proposed several criteria that are the FAST [Link] role is to ensure that
summarized in the mnemonic CATWOE in the meeting is productive.
Soft Systems Methodology (SSM).Which of 132. Arrange the steps in order to represent
the following alphabet is representing an the conducting of Wideband Delphi
entirely different meaning to SSM ? Technique.
a) C – Customer i. Conduct a group discussion
b) A – Actor ii. Conduct another group discussion
c) T – Transformation iii. Present experts with a problem
d) E – ER Model iv. Collect expert opinion anonymously
Answer: d v. Iterate until consensus is reached
Explanation: ‘E’ in CATWOE stands for vi. Feedback a summary of result to each
Environmental constraints. expert
129. Choose the disadvantage of using SSM a) i, iii, ii, iv, v, vi
as an elicitation technique. b) iii, i, ii, iv, v, vi
a) It incorporates human element into design c) i, ii, iii, iv, vi, v
b) SSM is in its infant stage d) iii, i, iv, vi, ii, v
c) SSM is suitable for new systems Answer: d
d) Standard methodologies like Role Explanation: The sequence represents the
Exploration, Issue Resolution and working steps of a Wideband Delphi
Reorganization support SSM technique .
Answer: b 133. Which of the following is not a diagram
Explanation: SSM is still in its [Link] is studied in Requirement Analysis ?
evolving and its industrial usage is low. a) Use Cases
130. How many phases are there in b) Entity Relationship Diagram
Brainstorming ? c) State Transition Diagram
a) Two d) Activity Diagram
b) Three Answer: d
c) Four Explanation: Activity Diagram comes under
d) All of the mentioned the design phase of SDLC.
Answer: b 134. How many feasibility studies is
Explanation: Preparation, Execution and conducted in Requirement Analysis ?
Follow up are the three phases to be a) Two
achieved for a successful brainstorming b) Three
session. c) Four
131. Who controls the FAST (Facilitated d) None of the mentioned
Application Specification Techniques) Answer: b
meeting ? Explanation: Economic feasibility
a) System Analyst (cost/benefit analysis), Technical feasibility
b) Scribe (hardware/software/people, etc.) and Legal
c) Facilitator feasibility studies are done in Requirement
d) Manager Analysis.
Answer: c 135. How many phases are there in
Explanation: A Facilitator (a Requirement Analysis ?
customer/developer/an outsider) controls a) Three

DIWAKAR EDUCATION HUB Page 18

 SOFTWARE ENGINEERING UNIT – 6 MCQs
b) Four [Link] is that perspective or view ?
c) Five a) Developer
d) Six b) User
Answer: c c) Non-Functional
Explanation: Problem Recognition, d) Physical
Evaluation and Synthesis (focus is on what Answer: d
not how), Modeling, Specification and Review Explanation: The perspectives or views have
are the five phases. been described as the Operational,
136. Traceability is not considered in Functional, and Physical [Link] three are
Requirement Analysis. necessary and must be coordinated to fully
a) True understand the customers’ needs and
b) False objectives.
Answer: b 140. Requirements Analysis is an Iterative
Explanation: Requirements traceability is Process.
concerned with documenting the life of a a) True
requirement and providing bi-directional b) False
traceability between various associated Answer: a
requirements, hence requirements must be Explanation: Requirements analysis is
traceable. conducted iteratively with functional analysis
137. Requirements analysis is critical to the to optimize performance requirements for
success of a development project. identified functions, and to verify that
a) True synthesized solutions can satisfy customer
b) False requirements.
c) Depends upon the size of project 141. Coad and Yourdon suggested _______
d) None of the mentioned selection characteristics that should be used
Answer: a as an analyst considers each potential object
Explanation: Requirements must be for inclusion in the requirement analysis
actionable, measurable, testable, related to model.
identified business needs or opportunities, a) Three
and defined to a level of detail sufficient for b) Four
system design. c) Five
138. _________ and _________ are the two d) Six
issues of Requirement Analysis. Answer: d
a) Performance, Design Explanation: Retained information, Needed
b) Stakeholder, Developer services, Multiple attributes, Common
c) Functional, Non-Functional attributes, Common operations and Essential
d) None of the mentioned requirements are the six criterion mentioned
Answer: b by Coad and Yourdon.
Explanation: Option a and c are the types of 142. Requirements should specify ‘what’ but
requirements and not the issues of not ‘how’.
requirement analysis.. a) True
139. The requirements that result from b) False
requirements analysis are typically expressed Answer: a
from one of three perspectives or Explanation: ‘What’ refers to a system’s

DIWAKAR EDUCATION HUB Page 19

 SOFTWARE ENGINEERING UNIT – 6 MCQs
purpose, while ‘How’ refers to a system’s ii. SRS is written by a developer
structure and behavior. iii. SRS serves as a contract between
143. Which of the following property does customer and developer
not correspond to a good Software a) Only i is true
Requirements Specification (SRS) ? b) Both ii and iii are true
a) Verifiable c) All are true
b) Ambiguous d) None of the mentioned
c) Complete Answer: c
d) Traceable Explanation: The SRS acts as a
Answer: b communication media between the
Explanation: The SRS should be unambiguous Customer, Analyst, system developers,
in nature which means each sentence in SRS maintainers etc. Thus it is a contract between
should have a unique interpretation. Purchaser and Supplier. It is essentially
144. Which of the following property of SRS is written by a developer on the basis of
depicted by the statement : “Conformity to a customer’ need but in some cases it may be
standard is maintained” ? written by a customer as well.
a) Correct 147. The SRS document is also known as
b) Complete _____________ specification.
c) Consistent a) black-box
d) Modifiable b) white-box
Answer: b c) grey-box
Explanation: The SRS is complete full labeling d) none of the mentioned
and referencing of all figures, tables etc. and Answer: a
definition of all terms and units of measure is Explanation: The system is considered as a
defined. black box whose internal details are not
145. The SRS is said to be consistent if and known that is, only its visible external
only if (input/output) behavior is documented.
a) its structure and style are such that any 148. Which of the following is included in SRS
changes to the requirements can be made ?
easily while retaining the style and structure a) Cost
b) every requirement stated therein is one b) Design Constraints
that the software shall meet c) Staffing
c) every requirement stated therein is d) Delivery Schedule
verifiable Answer: b
d) no subset of individual requirements Explanation: Design constraints include
described in it conflict with each other standards to be incorporated in the software,
Answer: d implementation language, resource limits,
Explanation: Real world object may conflict operating environment etc.
with each other for example one requirement 149. Which of the following is not included in
says that all lights should be red while the SRS ?
other states that all lights should green. a) Performance
146. Which of the following statements about b) Functionality
SRS is/are true ? c) Design solutions
i. SRS is written by customer d) External Interfaces

DIWAKAR EDUCATION HUB Page 20

 SOFTWARE ENGINEERING UNIT – 6 MCQs
Answer: c only one unique interpretation. The given
Explanation: The SRS document concentrates statement does not answer the question:
on:”what needs to be done” and carefully “which data set will have an end of file
avoids the solution (“how to do”) aspects. character ?”.
150. Arrange the given sequence to form a 153. Consider the following Statement: “The
SRS Prototype outline as per IEEE SRS product should have a good human
Standard. interface.”What characteristic of SRS is being
i. General description depicted here ?
ii. Introduction a) Consistent
iii. Index b) Non-Verifiable
iv. Appendices c) Correct
v. Specific Requirements d) Ambiguous
a) iii, i, ii,v, iv Answer: b
b) iii, ii, i, v, iv Explanation: An SRS is verifiable, if and only
c) ii, i, v, iv, iii if, every requirement stated therein is
d) iii, i, ii verifiable. The statement can only be
Answer: c answered on completion of the software and
Explanation: The given sequence correctly customer evaluation but still human interface
resemble a standard SRS prototype as per will vary from person to person.
IEEE. 154. Narrative essay is one of the best types
151. Consider the following Statement: “The of specification document ?
output of a program shall be given within 10 a) True
secs of event X 10% of the time.”What b) False
characteristic of SRS is being depicted here ? Answer: b
a) Consistent Explanation: Narrative essay is one of the
b) Verifiable worst types of specification document as it is
c) Non-verifiable difficult to change, difficult to be precise, has
d) Correct scope for contradictions, etc.
Answer: b 155. Which two requirements are given
Explanation: An SRS is verifiable, if and only priority during Requirement Management of
if, every requirement stated therein is a product ?
[Link] the given condition can be a) User and Developer
verified during testing phase. b) Functional and Non-functional
152. Consider the following Statement: “The c) Enduring and Volatile
data set will contain an end of file d) All of the mentioned
character.”What characteristic of SRS is being Answer: c
depicted here ? Explanation: Enduring requirements are core
a) Consistent requirements & are related to main activity
b) Non-verifiable of the organization while volatile
c) Correct requirements are likely to change during
d) Ambiguous software development life cycle or after
Answer: b delivery of the product.
Explanation: An SRS is unambiguous if and 156. Considering the example of issue/return
only if, every requirement stated therein has of a book, cataloging etc. in a library

DIWAKAR EDUCATION HUB Page 21

 SOFTWARE ENGINEERING UNIT – 6 MCQs
[Link] type of management backwards direction. Requirements can be
requirement is being depicted here? traced from its origins, through its
a) Enduring development and specification, to its
b) Volatile subsequent deployment and use, and
c) Both Enduring & Volatile through periods of ongoing refinement and
d) All of the mentioned iteration in any of these phases.
Answer: a 160. Requirements Management has a high
Explanation: For library management system initial start-up cost but does not need
issue/return of a book, cataloging etc. are ongoing funding throughout a project.
core activities and are stable for any system. a) True
157. Why is Requirements Management b) False
Important ? It is due to the changes Answer: b
a) to the environment Explanation: Requirements Management
b) in technology needs continued funding throughout a
c) in customer’s expectations [Link] funding is often limited at the
d) in all of the mentioned. onset of a project, restricted to those aspects
Answer: d of the project which are tangible and visible,
Explanation: Systems continue to be built as and subsequently allocated in a phase-by-
the advancement of new products being phase manner.
launched in the market and so does the 161. Which of the following is not a
market changes, the technology and in turn Requirement Management workbench tool ?
customer’s expectation. a) RTM
158. Requirements Management is a b) DOORS
prerequisite for Quality-Oriented c) Rational Suite
Development. d) RDD 100
a) True Answer: c
b) False Explanation: Rational Suite is an environment
Answer: a tool for requirement management.
Explanation: Quality makes no sense without 162. Which of the following is a requirement
reference to requirements, which means management activity ?
quality-oriented development is a) Investigation
requirements-driven development, thus b) Design
requirements management is a prerequisite c) Construction and Test
for quality-oriented development. d) All of the mentioned
159. Requirements traceability is one of the Answer: d
most important part requirement Explanation: All the options are the activities
management. It may also be referred to as of requirement management.
the heart of requirement management. 163. What functionality of Requirement
a) True Management Tool (RMT) is depicted by the
b) False statement: “the tool should be able to
Answer: a automatically detect relations between
Explanation: Requirements traceability refers artifacts. For example information retrieval
to the ability to describe and follow the life of techniques, monitoring of change history,
a requirement in both forwards and naming schemas or model transformations.”

DIWAKAR EDUCATION HUB Page 22

 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Automatic Link Detection 167. Which system model is being depicted
b) Documentation Support by the ATM operations shown below:
c) Graphical Representation
d) Automatic Link Creation and Change
Answer: a
Explanation: DOORS is one such tool that
supports Automatic Link Detection.
164. According to a statistical report: “over
30% of all software projects are cancelled
before completion and over 70% of the
remainder fail to deliver expected features”.
What must be the reason for such a situation
? a) Structural model
a) Poor change management b) Context model
b) Poor requirements management c) Behavioral model
c) Poor quality control d) Interaction model
d) All of the mentioned Answer: b
Answer: b Explanation: Context models are used to
Explanation: Fundamental to the problem illustrate the operational context of a
mentioned in the statistical report is poor [Link] show what lies outside the
requirements management. Option a and c system boundaries.
are its sub parts. 168. Activity diagrams are used to model the
165. Which model in system modelling processing of data.
depicts the static nature of the system ? a) True
a) Behavioral Model b) False
b) Context Model Answer: a
c) Data Model Explanation: The statement mentioned is
d) Structural Model true and each activity represents one process
Answer: d step.
Explanation: Structural models show the 169. Model-driven engineering is just a
organization and architecture of a system. theoretical concept. It cannot be converted
These are used to define the static structure into a working/executable code.
of classes in a system and their associations. a) True
166. Which perspective in system modelling b) False
shows the system or data architecture. Answer: b
a) Structural perspective Explanation: Model-driven engineering is an
b) Behavioral perspective approach to software development in which
c) External perspective a system is represented as a set of models
d) All of the mentioned that can be automatically transformed to
Answer: a executable code.
Explanation: Structural perspective is used to 170. Which of the following diagram is not
define the static structure of classes in a supported by UML considering Data-driven
system and their associations. modeling ?
a) Activity
DIWAKAR EDUCATION HUB Page 23
 SOFTWARE ENGINEERING UNIT – 6 MCQs
b) Data Flow Diagram (DFD) 174. Identify the correct statement with
c) State Chart respect to Evolutionary development:
d) Component a) Evolutionary development usually has two
Answer: b flavors; exploratory development, and throw-
Explanation: DFDs focus on system functions away prototyping
and do not recognize system objects. b) Very large projects are usually done using
171. The two dimensions of spiral model are evolutionary development based approach
a) diagonal, angular c) It facilitates easy project management,
b) radial, perpendicular through the high volume of documentation it
c) radial, angular generates
d) diagonal, perpendicular d) Sometimes the construction of a throw-
Answer: c away prototype is not followed by a re-
Explanation: The radial dimension depicts the implementation of the software system using
cumulative costs and the angular dimension a more structured approach
depicts the progress made in completing Answer: a
each cycle. Each loop of the spiral model Explanation: Evolutionary development
represents a phase. usually has two flavors; exploratory
172. The Incremental Model is combination development, and
of elements of throw-away prototyping.
a) Build & FIX Model & Waterfall Model 175. Spiral model was developed by
b) Linear Model & RAD Model a) Victor Bisili
c) Linear Model & Prototyping Model b) Berry Boehm
d) Waterfall Model & RAD Model c) Bev Littlewood
Answer: c d) Roger Pressman
Explanation: Each linear sequence produces Answer: b
a deliverable “increment” of the software Explanation: Berry Boehm in 1986 in his
system, particularly needed in case of quick Article “A spiral model of software
delivery of a limited functionality system.. development and enhancement”.
173. Model preferred to create client/server 176. Software evolution does not comprises:
applications is a) Development activities
a) WINWIN Spiral Model b) Negotiating with client
b) Spiral Model c) Maintenance activities
c) Concurrent Model d) Re-engineering activities
d) Incremental Model Answer: b
Answer: c Explanation: Software evolution refers to the
Explanation: In case of client/server study and management of the process of
applications, the concurrent process model making changes to software over time. Thus
specifies activities in two dimensions: a it comprises rest three options.
system dimension and a component 177. Processes for evolving a software
dimension. Hence Concurrency is achieved by product depend on:
these two activities occurring simultaneously a) Type of software to be maintained
and can be modeled using the state-oriented b) Development processes used
approach. c) Skills and experience of the people

DIWAKAR EDUCATION HUB Page 24

 SOFTWARE ENGINEERING UNIT – 6 MCQs
involved and specification problems, thereby
d) All of the mentioned increasing the cost.
Answer: d 182. A characteristic of a software system
Explanation: Processes used for software that can lead to a system error is known as?
evolution depend on all these factors. a) Human error or mistake
178. Which technique is applied to ensure b) System fault
the continued evolution of legacy systems ? c) System error
a) Forward engineering d) System failure
b) Reverse Engineering Answer: b
c) Reengineering 183. An erroneous system state that can lead
d) Reverse Engineering and Reengineering to system behavior that is unexpected by
Answer: d system users is known as?
Explanation: Processes used for software a) Human error or mistake
evolution depend rely on these two b) System fault
techniques. c) System error
179. Program modularization and Source d) System failure
code translation are the activities Answer: c
of_____________ 184. An event that occurs at some point in
a) Forward engineering time when the system does not deliver a
b) Reverse Engineering service as expected by its users is called
c) Reengineering _____________
d) Reverse Engineering and Reengineering a) Human error or mistake
Answer: c b) System fault
Explanation: Reengineering is the c) System error
examination and alteration of a subject d) System failure
system to reconstitute it in a new form and Answer: d
the subsequent implementation of the new
form. 185. A chemical plant system may detect
180. Reverse engineering is the last activity in excessive pressure and open a relief valve to
a reengineering project. reduce these pressures before an explosion
a) True occurs. What kind of dependability and
b) False security issue the example states?
Answer: b a) Hazard avoidance
Explanation: Reverse engineering is often the b) Damage limitation
initial activity in a reengineering project. c) Hazard detection
181. The cost of re-engineering is often d) Hazard detection and removal
significantly less than the costs of developing Answer: d
new software. Explanation: The system is designed so that
a) True hazards are detected and removed before
b) False they result in an accident.
Answer: a 186. An aircraft engine normally includes
Explanation: There is a high risk in new automatic fire [Link] kind of
software development. There may be dependability and security issue the example
development problems, staffing problems states?
DIWAKAR EDUCATION HUB Page 25
 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Hazard avoidance a) True
b) Damage limitation b) False
c) Hazard detection Answer: a
d) Hazard detection and removal Explanation: In preliminary risk analysis
Answer: b stage, decisions on the detailed system
Explanation: The system may include requirements, the system design, or the
protection features that minimize the implementation technology have not been
damage that may result from an accident. made.
187. Which reliability metric sets out the 191. At which stage of risk analysis
probable number of system failures that are specification, the additional security
likely to be observed relative to a certain time requirements take account of the
period? technologies used in building the system and
a) POFOD system design and implementation
b) ROCOF decisions?
c) AVAIL a) Preliminary risk analysis
d) None of the mentioned b) Life-cycle risk analysis
Answer: b c) Operational risk analysis
Explanation: Rate of occurrence of failures d) All of the mentioned
(ROCOF) sets out the probable number of Answer: b
system failures that are likely to be observed Explanation: This risk assessment takes place
relative to the number of system executions. during the system development life cycle
188. Which of the following is not a after design choices have been made..
functional reliability requirement for a 192. Which reliability requirements are
system? concerned with maintaining copies of the
a) Checking requirements system?
b) Recovery requirements a) Checking requirements
c) Redundancy requirements b) Recovery requirements
d) Ambiguous requirements c) Redundancy requirements
Answer: d d) Ambiguous requirements
Explanation: All the options are correct Answer: b
except option d. Explanation: These requirements are geared
189. To specify security requirements, one to helping the system recover after a failure
should identify the risks that are to be dealt has occurred.
with. 193. What are security controls ?
a) True a) Controls that are intended to ensure that
b) False attacks are unsuccessful
Answer: b b) Controls that are intended to detect and
Explanation: To specify security repel attacks
requirements, one should identify the assets c) Controls that are intended to support
that are to be dealt with. recovery from problems
190. The aim of preliminary risk analysis and d) All of the mentioned
assessment process is to derive security Answer: d
requirements for the system as a whole. Explanation: All the options define a security
control property.

DIWAKAR EDUCATION HUB Page 26

 SOFTWARE ENGINEERING UNIT – 6 MCQs
194. Controls that are intended to repel verification of small to medium sized critical
attacks is analogous to ____________ in systems.
dependability engineering. 198. Which is the first step in the software
a) Fault avoidance development life cycle ?
b) Fault tolerance a) Analysis
c) Fault detection b) Design
d) None of the mentioned c) Problem/Opportunity Identification
Answer: b d) Development and Documentation
Explanation: Here the system is designed so Answer: c
that faults in the delivered software do not 199. Which tool is use for structured
result in system failure. designing ?
195. Controls that are intended to ensure a) Program flowchart
that attacks are unsuccessful is analogous to b) Structure chart
____________ in dependability engineering. c) Data-flow diagram
a) Fault avoidance d) Module
b) Fault tolerance Answer: b
c) Fault detection Explanation: A Structure Chart (SC) in
d) Fault Recovery software engineering and organizational
Answer: a theory, is a chart which shows the breakdown
Explanation: In Fault avoidance the system is of a system to its lowest manageable levels.
developed in such a way that human error is 200. A step by step instruction used to solve a
avoided and thus system faults are problem is known as
minimised. a) Sequential structure
196. What is Life cycle risk assessment ? b) A List
a) Risk assessment before the system has c) A plan
been deployed d) An Algorithm
b) Risk assessment while the system is being Answer: d
developed 201. In the Analysis phase, the development
c) All of the mentioned of the ____________ occurs, which is a clear
d) None of the mentioned statement of the goals and objectives of the
Answer: c project.
197. Which of the following is incorrect with a) documentation
respect to Model Checking? b) flowchart
a) Model checking is particularly valuable for c) program specification
verifying concurrent systems d) design
b) Model checking is computationally very Answer: c
inexpensive Explanation: Program specification is the
c) The model checker explores all possible definition of what a computer program is
paths through the model expected to do.
d) All of the mentioned 202. Actual programming of software code is
Answer: b done during the ____________ step in the
Explanation: Model checking is very SDLC.
[Link] is only practical to use it in the a) Maintenance and Evaluation
b) Design
DIWAKAR EDUCATION HUB Page 27
 SOFTWARE ENGINEERING UNIT – 6 MCQs
c) Analysis c) Interface
d) Development and Documentation d) All of the mentioned
Answer: d Answer: d
Explanation: The developer has to find in the Explanation: Part of the design phase is to
technical documentation enough information create structural and behavioral models of
to start coding. the system which is covered by architecture,
203. Who designs and implement database data and the interface of the product.
structures. 207. The importance of software design can
a) Programmers be summarized in a single word which is:
b) Project managers a) Efficiency
c) Technical writers b) Accuracy
d) Database administrators c) Quality
Answer: d d) Complexity
Explanation: The role of database Answer: c
administrators includes the development and Explanation: Software functional quality
design of database strategies, system reflects how well it complies with or
monitoring and improving database conforms to a given design, based on
performance and capacity, and planning for functional requirements or specifications.
future expansion requirements. 208. Cohesion is a qualitative indication of
204. ____________ is the process of the degree to which a module
translating a task into a series of commands a) can be written more compactly
that a computer will use to perform that task. b) focuses on just one thing
a) Project design c) is able to complete its function in a timely
b) Installation manner
c) Systems analysis d) is connected to other modules and the
d) Programming outside world
Answer: d Answer: b
205. Debugging is: Explanation: Cohesion of a single
a) creating program code module/component is the degree to which its
b) finding and correcting errors in the responsibilities form a meaningful unit.
program code 209. Coupling is a qualitative indication of the
c) identifying the task to be computerized degree to which a module
d) creating the algorithm a) can be written more compactly
Answer: b b) focuses on just one thing
Explanation: Debugging is a methodical c) is able to complete its function in a timely
process of finding and reducing the number manner
of bugs, or defects, in a computer program or d) is connected to other modules and the
a piece of electronic hardware, thus making it outside world
behave as expected. Answer: d
206. In Design phase, which is the primary Explanation: Coupling between
area of concern ? modules/components is their degree of
a) Architecture mutual interdependence.
b) Data 210. Java packages and Fortran subroutine
are examples of__________

DIWAKAR EDUCATION HUB Page 28

 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Functions a) Control Coupling
b) Modules b) Stamp Coupling
c) Classes c) External Coupling
d) Sub procedures d) Content Coupling
Answer: b Answer: c
Explanation: A modular system consist of Explanation: Content coupling occurs when
well defined manageable units with well module A changes data of module B or when
defined interfaces among the units. control is passed from one module to the
211. Which of the property of software middle of another.
modularity is incorrect with respect to 215. Which of the following is the worst type
benefits software modularity? of module cohesion?
a) Modules are robust a) Logical Cohesion
b) Module can use other modules b) Temporal Cohesion
c) Modules Can be separately compiled and c) Functional Cohesion
stored in a library d) Coincidental Cohesion
d) Modules are mostly dependent Answer: d
Answer: d Explanation: Coincidental cohesion exists in
Explanation: Modularity cannot bring modules that contain instructions that have
benefits unless the modules are autonomous little or no relationship to one another.
or independent. 216. Which of the following is the best type
212. _______________ is a measure of the of module cohesion?
degree of interdependence between a) Functional Cohesion
modules. b) Temporal Cohesion
a) Cohesion c) Functional Cohesion
b) Coupling d) Sequential Cohesion
c) None of the mentioned Answer: a
d) All of the mentioned Explanation: Functional Cohesion is a type of
Answer: b cohesion in which the tasks performed by a
Explanation: Coupling or dependency is the software module all contribute to the
degree to which each program module relies performance of a single function.
on each one of the other modules. 217. A software engineer must design the
213. Which of the following is the best type modules with the goal of high cohesion and
of module coupling? low coupling.
a) Control Coupling a) True
b) Stamp Coupling b) False
c) Data Coupling Answer: a
d) Content Coupling Explanation: If the software is not properly
Answer: c modularized, a host of seemingly trivial
Explanation: The dependency between enhancement or changes will result into
module A and B is said to be data coupled if death of the project.
their dependency is based on the fact they 218. In what type of coupling, the complete
communicate by only passing of data. data structure is passed from one module to
214. Which of the following is the worst type another?
of module coupling? a) Control Coupling

DIWAKAR EDUCATION HUB Page 29

 SOFTWARE ENGINEERING UNIT – 6 MCQs
b) Stamp Coupling b) Divide and conquer principle
c) External Coupling c) Graphical representation of results using
d) Content Coupling DFDs
Answer: b d) All of the mentioned
219. If all tasks must be executed in the same Answer: d
time-span, what type of cohesion is being 224. Which of the following is/are true with
exhibited? respect to functions ?
a) Functional Cohesion a) A function such as “search-book” is
b) Temporal Cohesion represented using a circle
c) Functional Cohesion b) Functions represent some activity
d) Sequential Cohesion c) Function symbol is known as a process
Answer: b symbol or a bubble in DFD
Explanation: A Module exhibits temporal d) All of the mentioned
cohesion when it contains tasks that are Answer: d
related by the fact that all tasks must be Explanation: All the options are correct with
executed in the same time-span. respect to Function Oriented Software
220. Choose the option that does not define Design.
Function Oriented Software Design. 225. Which of the following is not a use of a
a) It consists of module definitions CASE tool ?
b) Modules represent data abstraction a) Support structured analysis and design
c) Modules support functional abstraction (SA/SD)
d) None of the mentioned b) Maintains the data dictionary
Answer: b c) Checks whether DFDs are balanced or not
Explanation: Option b defines an Object d) It complies with the available system
Oriented Design. Answer: d
221. Which of the following is a Explanation: It takes long time to establish
complementary approach to function- the system in order to comply with the
oriented approach ? available system.
a) Object oriented analysis 226. What DFD notation is represented by
b) Object oriented design the Rectangle?
c) Structured approach a) Transform
d) Both Object oriented analysis and design b) Data Store
Answer: d c) Function
222. Function-oriented design techniques d) None of the mentioned
starts with functional requirements specified Answer: b
in 227. Structural decomposition is concerned
a) SDD with function calls.
b) SRS a) True
c) All of the mentioned b) False
d) None of the mentioned Answer: a
Answer: b Explanation: Structural decomposition is
223. Structured Analysis is based on the concerned with developing a model of the
principles of design which shows the dynamic structure.
a) Top-down decomposition approach
DIWAKAR EDUCATION HUB Page 30
 SOFTWARE ENGINEERING UNIT – 6 MCQs
228. A function-oriented design focuses on a) True
the entities in the system rather than the b) False
data processing activities. Answer: a
a) True Explanation: The results of structured
b) False analysis directly represents customer’s
Answer: b perception of the problem and uses
Explanation: It is an object oriented design customer’s terminology for naming different
which focus on entities. functions and data.
229. In DFDs, user interactions with the 234. Structured Analysis is based on the
system is denoted by principle of Bottom-Up Approach.
a) Circle a) True
b) Arrow b) False
c) Rectangle Answer: b
d) Triangle Explanation: Structured Analysis follows uses
Answer: a decomposition approach.
230. SA/SD features are obtained from which 235. The context diagram is also known as
of the methodologies? a) Level-0 DFD
a) Constantine and Yourdon methodology b) Level-1 DFD
b) DeMarco and Yourdon methodology c) Level-2 DFD
c) Gane and Sarson methodology d) All of the mentioned
d) All of the mentioned Answer: a
Answer: d Explanation: Context diagram captures the
231. Which of the following is not an activity various entities external to the system
of Structured Analysis (SA) ? interacting with it and data flow occurring
a) Functional decomposition between the system and the external
b) Transformation of a textual problem entities.
description into a graphic model 236. A directed arc or line in DFD represents
c) All the functions represented in the DFD a) Data Store
are mapped to a module structure b) Data Process
d) All of the mentioned c) Data Flow
Answer: c d) All of the mentioned
Explanation: The module structure is the Answer: c
software architecture. Explanation: It resembles data flow in the
232. To arrive at a form which is suitable for direction of the arrow.
implementation in some programming 237. A DFD is always accompanied by a data
language is the purpose of dictionary.
a) Structured Analysis (SA) a) True
b) Structured Design (SD) b) False
c) Detailed Design (DD) Answer: a
d) None of the mentioned Explanation: A data dictionary lists all data
Answer: b items appearing in a DFD including definition
233. The results of structured analysis can be and data names.
easily understood by ordinary customers. 238. Which of the following is a function of
CASE Tool?
DIWAKAR EDUCATION HUB Page 31
 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Supporting Structured analysis and design 243. Inherited object classes are self-
(SA/SD) contained.
b) Maintaining the data dictionary a) True
c) Checking whether DFDs are balanced or b) False
not Answer: b
d) All of the mentioned Explanation: Inherited object classes are not
Answer: a self-contained. They cannot be understood
239. Data Store Symbol in DFD represents a without reference to their super-classes.
a) Physical file 244. Which of the following points related to
b) Data Structure Object-oriented development (OOD) is true?
c) Logical file a) OOA is concerned with developing an
d) All of the mentioned object model of the application domain
Answer: d b) OOD is concerned with developing an
Explanation: A logical file can be a data object-oriented system model to implement
structure or a physical file on disk. requirements
240. Choose the incorrect statement in terms c) All of the mentioned
of Objects. d) None of the mentioned
a) Objects are abstractions of real-world Answer: c
b) Objects can’t manage themselves Explanation: The answer is in support with
c) Objects encapsulate state and the OOD.
representation information 245. How is generalization implemented in
d) All of the mentioned Object Oriented programming languages?
Answer: b a) Inheritance
Explanation: Objects are independent. b) Polymorphism
241. What encapsulates both data and data c) Encapsulation
manipulation functions ? d) Abstract Classes
a) Object Answer: a
b) Class 246. Which of the following is a disadvantage
c) Super Class of OOD ?
d) Sub Class a) Easier maintenance
Answer: a b) Objects may be
242. Which of the following is a mechanism understood as stand-alone entities
that allows several objects in an class c) Objects are potentially reusable
hierarchy to have different methods with the components
same name? d) None of the mentioned
a) Aggregation Answer: d
b) Polymorphism Explanation: All the options define the
c) Inheritance characteristics of OOD.
d) All of the mentioned 247. Which of the following describes”Is-a-
Answer: b Relationship” ?
Explanation: In polymorphism instances of a) Aggregation
each subclass will be free to respond to b) Inheritance
messages by calling their own version of the c) Dependency
method. d) All of the mentioned

DIWAKAR EDUCATION HUB Page 32

 SOFTWARE ENGINEERING UNIT – 6 MCQs
Answer: b d) operations that monitor an object for the
248. Object that collects data on request occurrence of a controlling event
rather than autonomously is known as Answer: c
a) Active Object Explanation: Operations that check for syntax
b) Passive Object errors is concerned with the programming
c) Multiple instance language used, so it will be handled by the
d) None of the mentioned compiler.
Answer: b 253. Throughout the OOD process, a software
Explanation: A passive object holds data, but engineer should look for every opportunity
does not initiate control. for creating new design process.
249. Objects are executed a) True
a) sequentially b) False
b) in Parallel Answer: b
c) sequentially & Parallel Explanation: A software engineer should look
d) none of the mentioned for every opportunity to reuse existing design
Answer: c patterns whenever they meet the needs of
Explanation: Objects may be distributed and the design rather than creating new ones.
may execute 254. The user has no control over the
sequentially or in parallel. contents of a static web page.
250. How many layers are present in the OO a) True
design pyramid? b) False
a) three Answer: a
b) four Explanation: Static web pages are just for
c) five information purposes.
d) one 255. Which metric gives the idea about the
Answer: b contents on a web page ?
Explanation: The four layers are: Subsystem a) Word Token
layer, class and object layer, message layer b) Word Count
and responsibilities layer c) Word Size
251. A design description in OOD includes d) Word Length
a) Protocol Description Answer: b
b) Implementation Description Explanation: The word count metric gives the
c) Type Description total number of words on a web page.
d) both Protocol and Implementation 256. How is the complexity of a web page
Description related to link count ?
Answer: d a) Directly
b) Indirectly
252. Which of the following is not an c) No relation
operation as per OOD algorithms and data d) All of the mentioned
structures? Answer: a
a) operations that manipulate data in some Explanation: If link count is more, complexity
way will be more.
b) operations that perform a computation 256. It is expected to have less number of
c) operations that check for syntax errors connections for a good web application.
DIWAKAR EDUCATION HUB Page 33
 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) True 261. Which of the following is not a web
b) False engineering project metric ?
Answer: a a) Number of Static Content Objects
Explanation: More the link count, more the b) Number of Dynamic Content Objects
complexity and the web page dependence c) Number of Inherited Objects
factor will increase. d) Word Count
257. Number of dynamic web pages provides Answer: c
an idea about________ for a web page that is Explanation: There is no such metric as an
to be built. inherited object’s count.
a) size 262. Which of the following is not project
b) complexity management goal?
c) effort a) Keeping overall costs within budget
d) all of the mentioned b) Delivering the software to the customer at
Answer: d the agreed time
258. Which of the following web engineering c) Maintaining a happy and well-functioning
metric measures the extent of relatedness development team
between two or more web pages ? d) Avoiding customer complaints
a) Number of Static Content Objects Answer: d
b) Number of Dynamic Content Objects Explanation: Projects need to be managed
c) Web Page Similarity because professional software engineering is
d) Number of Internal Page Links always subject to organizational budget and
Answer: c schedule constraints.
259. Which of the following is not a 263. Project managers have to assess the
classification of the web engineering metric, risks that may affect a project.
Web Page Similarity ? a) True
a) Content based b) False
b) Link based Answer: b
c) Usage based Explanation: Risk management involves
d) Traffic based anticipating risks that might affect the project
Answer: d schedule or the quality of the software being
Explanation: Similarity between two web developed, and then taking action to avoid
pages is not judged upon its traffic activity. these risks.
260. Link based measures rely on 264. Which of the following is not considered
___________ structure of a web graph to as a risk in project management?
obtain related pages. a) Specification delays
a) Embedded b) Product competition
b) Hyperlink c) Testing
c) Dynamic d) Staff turnover
d) All of the mentioned Answer: c
Answer: b Explanation: Testing is a part of project, thus
Explanation: Only option b answers the it can’t be categorized as risk.
blank, rest are not in accordance to the 265. The process each manager follows
question. during the life of a project is known as
a) Project Management

DIWAKAR EDUCATION HUB Page 34

 SOFTWARE ENGINEERING UNIT – 6 MCQs
b) Manager life cycle efficacy of estimates?
c) Project Management Life Cycle a) Project size
d) All of the mentioned b) Planning process
Answer: c c) Project complexity
Explanation: A proven methodical life cycle is d) Degree of structural uncertainty
necessary to repeatedly implement and Answer: a
manage projects successfully. Explanation: As size increases, the
266. Quality planning is the process of interdependence among various elements of
developing a quality plan for the software grows rapidly.
a) team 270. What describes the data and control to
b) project be processed?
c) customers a) Planning process
d) project manager b) Software scope
Answer: b c) External hardware
Explanation: The quality plan should set out d) Project complexity
the desired software qualities and describe Answer: b
how these are to be assessed. Explanation: Functions described in the
267. Which of the following is incorrect statement of scope are evaluated and in
activity for the configuration management of some cases refined to provide more detail
a software system? prior to the beginning of estimation.
a) Internship management 271. A number of independent investigators
b) Change management have developed a team-oriented approach to
c) Version management requirements gathering that can be applied
d) System management to establish the scope of a project called
Answer: a a) JAD
Explanation: Configuration management b) CLASS
policies and processes define how to record c) FAST
and process proposed system changes, how d) None of the mentioned
to decide what system components to Answer: c
change, how to manage different versions of Explanation: Facilitated application
the system and its components, and how to specification techniques
distribute changes to customers. (FAST), this approach encourages the
268. Identify the sub-process of process creation of a joint team of customers
improvement and developers who work together to
a) Process introduction identify the problem, propose elements
b) Process analysis of the solution, negotiate different
c) De-processification approaches, and specify a preliminary set of
d) Process distribution requirements.
Answer: b 272. The project planner examines the
Explanation: The current process is assessed, statement of scope and extracts all important
and process weaknesses and bottlenecks are software functions which is known as
identified. a) Association
269. Which of the following is an important b) Decomposition
factor that can affect the accuracy and

DIWAKAR EDUCATION HUB Page 35

 SOFTWARE ENGINEERING UNIT – 6 MCQs
c) Planning process Answer: d
d) All of the mentioned Explanation: All these are accounted for in
Answer: b estimating a software development cost.
Explanation: None 277. Which of the following costs is not part
273. Which of the following is not an option of the total effort cost?
to achieve reliable cost and effort estimate? a) Costs of networking and communications
a) Base estimates on similar projects that b) Costs of providing heating and lighting
have already been completed office space
b) Use one or more empirical models for c) Costs of lunch time food
software cost and effort estimation d) Costs of support staff
c) Use relatively simple decomposition Answer: c
techniques to generate project cost and Explanation: This is a incurred by the
effort estimates employees.
d) The ability to translate the size estimate 278. It is often difficult to estimate size at an
into human effort, calendar time, and dollars early stage in a project when only a
Answer: d specification is available
274. What can be used to complement a) True
decomposition techniques and offer a b) False
potentially valuable estimation approach in Answer: a
their own right? Explanation: Function-point and object-point
a) Automated estimation tools estimates are easier to produce than
b) Empirical estimation models estimates of code size but are often still
c) Decomposition techniques inaccurate.
d) Both Automated estimation tools and 279. Which technique is applicable when
Empirical estimation models other projects in the same analogy
Answer: b application domain have been completed?
Explanation: An estimation model for a) Algorithmic cost modelling
computer software uses empirically derived b) Expert judgement
formulas to predict effort as a function of c) Estimation by analogy
LOC or FP. d) Parkinson’s Law
275. Software project estimation can never Answer: c
be an exact science, but a combination of Explanation: The cost of a new project is
good historical data and systematic estimated by analogy with these completed
techniques can improve estimation accuracy. projects.
a) True 280. Which model assumes that systems are
b) False created from reusable components, scripting
Answer: a or database programming?
176. Which of the following are parameters a) An application-composition model
involved in computing the total cost of a b) A post-architecture model
software development project? c) A reuse model
a) Hardware and software costs d) An early design model
b) Effort costs Answer: a
c) Travel and training costs Explanation: It is designed to make estimates
d) All of the mentioned of prototype development.

DIWAKAR EDUCATION HUB Page 36

 SOFTWARE ENGINEERING UNIT – 6 MCQs
281. Which model is used to compute the c) Application composition model
effort required to integrate reusable d) All of the mentioned
components or program code that is Answer: c
automatically generated by design or [Link] was developed initially by
program translation tools? a) [Link]
a) An application-composition model b) Rajiv Gupta
b) A post-architecture model c) [Link]
c) A reuse model d) Gregg Rothermal
d) An early design model Answer: c
Answer: c Explanation: Barry Boehm introduced a
282. The COCOMO model takes into account hierarchy of software estimation models
different approaches to software bearing the name COCOMO, for COnstructive
development, reuse, etc. COst MOdel.
a) True 287. Estimation of size for a project is
b) False dependent on
Answer: b a) Cost
Explanation: Its the COCOMO-2 model. b) Time
COCOMO 2 incorporates a range of sub- c) Schedule
models that produce increasingly detailed d) None of the mentioned
software estimates. Answer: d
283. COCOMO stands for Explanation: Estimation depends on factors
a) Constructive cost model such as Function points and LOC.
b) Comprehensive cost model 288. COCOMO-II was developed at
c) Constructive cost estimation model a) University of Texas
d) Complete cost estimation model b) University of Southern California
Answer: a c) MIT
284. Which version of COCOMO states that d) IIT-Kanpur
once requirements have been stabilized, the Answer: b
basic software architecture has been 289. Which one is not a stage of COCOMO-II?
established? a) Early design estimation model
a) Early design stage model b) Application Composition estimation model
b) Post-architecture-stage model c) Comprehensive cost estimation model
c) Application composition model d) Post architecture estimation model
d) All of the mentioned Answer: a
Answer: a Explanation: It was a part of COCOMO.
285. Which model was used during the early 290. Size and Complexity are a part of
stages of software engineering, when a) Product Metrics
prototyping of user interfaces, consideration b) Process Metrics
of software and system interaction, c) Project Metrics
assessment of performance, and evaluation d) All of the mentioned
of technology maturity were paramount. Answer: a
a) Early design stage model Explanation: Product Metrics describe the
b) Post-architecture-stage model characteristics of product.

DIWAKAR EDUCATION HUB Page 37

 SOFTWARE ENGINEERING UNIT – 6 MCQs
291. Cost and schedule are a part of Answer: b
a) Product Metrics 297. MTTC falls the the category of
b) Process Metrics a) correctness
c) Project Metrics b) integrity
d) All of the mentioned c) maintainability
Answer: c d) all of the mentioned
Explanation: Project Metrics describe the View Answer
project characteristics and execution. 298. Identify the correct option with
292. Number of errors found per person reference to Software Quality Metrics.
hours expended is an example of a a) Integrity = [Sigma(1 – threat)] * (1 –
a) measurement security)
b) measure b) Integrity = [1 – Sigma(threat)] * (1 –
c) metric security)
d) all of the mentioned c) Integrity = [1 – threat * Sigma(1 –
Answer: c security)].
Explanation: Metric is a quantitative measure d) Integrity = Sigma[1 – threat * (1 –
of the degree to which a system, component, security)].
or process possesses a given attribute. Answer: d
293. Which of the following is not categorized 299. Which one is not a risk management
under Product Operation of McCall’s activity?
Software Quality Factors? a) Risk assessment
a) Flexibility b) Risk generation
b) Reliability c) Risk control
c) Usability d) None of the mentioned
d) Integrity Answer: b
Answer: a Explanation: Risk management activities
Explanation: Flexibility is a part of Product would never want a new risk to be generated.
revision as per McCall’s Software Quality 300. Risk management is one of the most
Factors. important jobs for a
195. Which of the following is not categorized a) Client
under Component-Level Design Metrics? b) Investor
a) Complexity Metrics c) Production team
b) Cohesion Metrics d) Project manager
c) Morphology Metrics Answer: d
d) Coupling Metrics Explanation: Risk management involves
Answer: c anticipating risks that might affect the project
Explanation: Morphology metrics are a part schedule or the quality of the software being
of High level design metrics. developed, and then taking action to avoid
296. Percentage of modules that were these risks.
inspected is a part of 301. Which of the following risk is the failure
a) Product Metrics of a purchased component to perform as
b) Process Metrics expected?
c) Project Metrics a) Product risk
d) All of the mentioned b) Project risk

DIWAKAR EDUCATION HUB Page 38

 SOFTWARE ENGINEERING UNIT – 6 MCQs
c) Business risk 306. Which of the following strategies means
d) Programming risk that the impact of the risk will be reduced?
Answer: a a) Avoidance strategies
Explanation: Risks that affect the quality or b) Minimization strategies
performance of the software being c) Contingency plans
developed. d) All of the mentioned
302. Which of the following term is best Answer: b
defined by the statement: “There will be a 307. Risk management is now recognized as
change of organizational management with one of the most important project
different priorities.”? management tasks.
a) Staff turnover a) True
b) Technology change b) False
c) Management change Answer: a
d) Product competition 308. Why is decomposition technique
Answer: c required?
303. What assess the risk and your plans for a) Software project estimation is a form of
risk mitigation and revise these when you problem solving
learn more about the risk? b) Developing a cost and effort estimate for a
a) Risk monitoring software project is too complex
b) Risk planning c) All of the mentioned
c) Risk analysis d) None of the mentioned
d) Risk identification Answer: c
Answer: a Explanation: For these reasons, we
304. Which of the following risks are derived decompose the problem, re-characterizing it
from the organizational environment where as a set of smaller problems.
the software is being developed? 309. Cost and effort estimation of a software
a) People risks uses only one forms of decomposition, either
b) Technology risks decomposition of the problem or
c) Estimation risks decomposition of the process.
d) Organizational risks a) True
Answer: d b) False
Explanation: These risks are at management Answer: b
level. Explanation: Estimation uses one or both
305. Which of the following risks are derived forms of partitioning.
from the software or hardware technologies 310. If a Direct approach to software project
that are used to develop the system? sizing is taken, size can be measured in
a) Managerial risks a) LOC
b) Technology risks b) FP
c) Estimation risks c) LOC and FP
d) Organizational risks d) None of the mentioned
Answer: b Answer: a
Explanation: The risks associated with Explanation: LOC or Line of Code is a direct
technology might affect the product measure to estimate project size.
development.
DIWAKAR EDUCATION HUB Page 39
 SOFTWARE ENGINEERING UNIT – 6 MCQs
311. Which software project sizing approach b) “Full-experience” or “Partial-experience”
develop estimates of the information domain software components should be used
characteristics? c) Customer-built software should be
a) Function point sizing developed
b) Change sizing d) All of the mentioned
c) Standard component sizing Answer: d
d) Fuzzy logic sizing 316. Which of the following is not one of the
Answer: a five information domain characteristics of
312. The expected value for the estimation Function Point (FP) decomposition?
variable (size), S, can be computed as a a) External inputs
weighted average of the optimistic(Sopt), b) External outputs
most likely (Sm), and pessimistic (Spess) c) External process
estimates given as d) External inquiries
a) EV = (Sopt + 4Sm + Spess)/4 Answer: c
b) EV = (Sopt + 4Sm + Spess)/6 Explanation: External inputs, external
c) EV = (Sopt + 2Sm + Spess)/6 outputs, external inquiries, internal logical
d) EV = (Sopt + 2Sm + Spess)/4 files, external interface files are the five
Answer: b domains.
Explanation: This assumes that there is a very 317. The project planner must reconcile the
small probability that the actual size result estimates based on decomposition
will fall outside the optimistic or pessimistic techniques to produce a single estimate of
values. effort.
313. How many forms exists of Barry Boehm’s a) True
COCOMO Model? b) False
a) Two Answer: b
b) Three Explanation: The planner must determine the
c) Four cause of divergence and then reconcile the
d) No form exists estimates.
Answer: b 318. Programming language experience is a
Explanation: The three forms include the part of which factor of COCOMO cost drivers?
basic, intermediate and advanced COCOMO a) Personnel Factor
model. b) Product Factor
314. In many cases, it is often more cost- c) Platform Factor
effective to acquire, rather than develop, d) Project Factor
computer software. Answer: a
a) True 319. If an Indirect approach is taken, then the
b) False sizing approach is represented as
Answer: a a) LOC
Explanation: Managers are faced with a b) FP
make-buy decision in such situations. c) Fuzzy Logic
315. A make-buy decision is based on d) LOC and FP
whether Answer: b
a) The software may be purchased off-the- Explanation: A function point (FP) is a unit of
shelf measurement to express the amount of
DIWAKAR EDUCATION HUB Page 40
 SOFTWARE ENGINEERING UNIT – 6 MCQs
business functionality an information system c) CMM
provides to a user. d) Both PERT and CPM
320. Ensuring that no more than the Answer: d
allocated number of people are allocated at Explanation: Program evaluation and review
any given time in Software Scheduling is technique (PERT) and critical path method
known as (CPM) are two project scheduling methods
a) Time Allocation that can be applied to software development.
b) Effort Validation 325. A technique for performing quantitative
c) Defined Milestone analysis of progress is known as
d) Effort Distribution a) BCWS
Answer: b b) EVA
321. What is used to determine the c) BAC
recommended degree of rigor with which the d) CBSE
software process should be applied on a Answer: b
project? Explanation: The earned value system
a) Degree of Rigor provides a common value scale for every
b) Adaptation criteria task, regardless of the type of work being
c) Task Set performed. The total hours to do the whole
d) Both degree of Rigor and adaptation project are estimated, and every task is given
criteria an earned value based on its estimated
Answer: b percentage of the total.
Explanation: Four different degrees of rigor 326. What is the recommended distribution
are: casual, structured, strict, and quick of effort for a project?
reaction. a) 40-20-40
322. What evaluates the risk associated with b) 50-20-30
the technology to be implemented as part of c) 30-40-30
project scope? d) 50-30-20
a) Concept scoping Answer: a
b) Preliminary concept planning Explanation: A recommended distribution of
c) Technology risk assessment effort across the software process is 40%
d) Customer reaction to the concept (analysis and design), 20% (coding), and 40%
Answer: b (testing).
323. Which of the following is not an 327. A project usually has a timeline chart
adaptation criteria for software projects? which was developed by
a) Size of the project a) Henry Gantt
b) Customers Complaints b) Barry Boehm
c) Project staff c) Ivar Jacabson
d) Mission criticality d) None of the mentioned
324. Which of the following is a project Answer: a
scheduling method that can be applied to Explanation: Timeline chart, also called a
software development? Gantt chart was invented by Henry Gantt, an
a) PERT industrial engineer in 1917 .
b) CPM 328. Which of the following is not needed to
develop a system design from concept to

DIWAKAR EDUCATION HUB Page 41

 SOFTWARE ENGINEERING UNIT – 6 MCQs
detailed object-oriented design? b) Subsystem model
a) Designing system architecture c) Dynamic model
b) Developing design models d) Both Sequence and Dynamic model
c) Specifying interfaces Answer: a
d) Developing a debugging system Explanation: Sequence model are
Answer: d represented using a UML sequence or a
Explanation: The debugging system is a part collaboration diagram and are dynamic
of testing phase. models.
329. Which of the following come under 333. If the system state is Shutdown then it
system control? can respond to which of the following
a) Reconfigure message?
b) Shutdown a) restart()
c) Powersave b) reconfigure()
d) All of the mentioned c) powerSave()
Answer: d d) all of the mentioned
Explanation: Functionalities are governed by Answer: d
the system. Explanation: A restart() message causes a
330. We use _________ where various parts transition to normal operation. Both the
of system use are identified and analyzed in powerSave() and reconfigure() messages
turn. cause a transition to a state in which the
a) tangible entities system reconfigures itself.
b) scenario-based analysis 334. Which message is received so that the
c) design-based analysis system moves to the Testing state, then the
d) none of the mentioned Transmitting state, before returning to the
Answer: b Running state?
Explanation: Use a scenario-based analysis a) signalStatus()
where various scenarios of system use are b) remoteControl()
identified and analyzed in turn. c) reconfigure()
331. Which model describes the static d) reportStatus()
structure of the system using object classes Answer: d
and their relationships? 335. Which of the following is not a
a) Sequence model construct?
b) Subsystem model a) sequence
c) Dynamic model b) condition
d) Structural model c) repetition
Answer: d d) selection
Explanation: Important relationships that Answer: d
may be documented at this stage are Explanation: Sequence implements
generalization (inheritance) relationships, processing steps that are essential in the
uses/used-by relationships, and composition specification of any algorithm. Condition
relationships. provides the facility for selected processing
332. Which model shows the flow of object based on some logical occurrence, and
interactions? repetition allows for looping.
a) Sequence model

DIWAKAR EDUCATION HUB Page 42

 SOFTWARE ENGINEERING UNIT – 6 MCQs
336. Which of the following term is best c) Show technical internals from the casual
defined by the statement:”The ability to user
represent local and global data is an essential d) Design for direct interaction with objects
element of component-level design.”? that appear on the screen
a) Data representation Answer: c
b) Logic verification Explanation: The user interface should move
c) “Code-to” ability the user into the virtual world of the
d) Automatic processing application.
Answer: a 341. Which of the following is not a user
337. A software component interface design process?
a) Implements some functionality a) User, task, and environment analysis and
b) Has explicit dependencies through modeling
provides and required interfaces b) Interface design
c) Communicates through its interfaces only c) Knowledgeable, frequent users
d) All of the mentioned d) Interface validation
Answer: d Answer: c
Explanation: All the options identify with Explanation: These are the end user for
features of a software component. whom the product is being built.
338. Which diagram evolved from a desire to 342. When users are involved in complex
develop a procedural design representation tasks, the demand on __________ can be
that would not allow violation of the significant.
structured constructs? a) short-term memory
a) State transition diagram b) shortcuts
b) Box diagram c) objects that appear on the screen
c) ER diagram d) all of the mentioned
d) None of the mentioned Answer: a
Answer: b Explanation: The interface should be
339. Which of the following is golden rule for designed to reduce the requirement to
interface design? remember past actions and results.
a) Place the user in control 343. Which of the following option is not
b) Reduce the user’s memory load considered by the Interface design?
c) Make the interface consistent a) the design of interfaces between software
d) All of the mentioned components
Answer: d b) the design of interfaces between the
Explanation: These golden rules actually form software and human producers and
the basis for a set of user interface design consumers of information
principles that guide this important software c) the design of the interface between two
design activity. computers
340. Which of the following is not a design d) all of the mentioned
principle that allow the user to maintain Answer: c
control? Explanation: None
a) Provide for flexible interaction 344. A software might allow a user to interact
b) Allow user interaction to be interrupt-able via
and undo-able a) keyboard commands

DIWAKAR EDUCATION HUB Page 43

 SOFTWARE ENGINEERING UNIT – 6 MCQs
b) mouse movement Answer: c
c) voice recognition commands Explanation: V&V generally refers to any
d) all of the mentioned activity that attempts to ensure that the
Answer: d software will function as required.
Explanation: All the mentioned input 349. In static test techniques, behavioral and
mediums are available today. performance properties of the program are
345. A software engineer designs the user observed.
interface by applying an iterative process that a) True
draws on predefined design principles. b) False
a) True Answer: b
b) False Explanation: Static Analysis Techniques are
Answer: a based solely on the (manual or automated)
Explanation: The statement is true. examination of project documentation of
346. What incorporates data, architectural, software models and code.
interface, and procedural representations of 350. Which granularity level of testing checks
the software? the behavior of module cooperation?
a) design model a) Unit Testing
b) user’s model b) Integration Testing
c) mental image c) Acceptance Testing
d) system image d) Regression Testing
Answer: a Answer: b
Explanation: The requirements specification Explanation: Integration testing is the phase
may establish certain constraints that help to in software testing in which individual
define the user of the system, but the software modules are combined and tested
interface design is often only incidental to the as a group.
design model. 351. Which test refers to the retesting of a
347. What establishes the profile of end- unit, integration and system after
users of the system? modification, in order to ascertain that the
a) design model change has not introduced new faults?
b) user’s model a) Regression Test
c) mental image b) Smoke Test
d) system image c) Alpha Test
Answer: b d) Beta Test
Explanation: To build an effective user Answer: a
interface, all design should begin with an Explanation: Regression test seeks to
understanding of the intended users, uncover new software bugs in existing
including their profiles of their age, physical functional and non-functional areas of a
abilities, education, etc. system after changes have been made to
348. What do you understand by V&V in them.
software testing? 352. Which of the following is a black box
a) Verified Version testing strategy?
b) Version Validation a) All Statements Coverage
c) Verification and Validation b) Control Structure Coverage
d) Version Verification

DIWAKAR EDUCATION HUB Page 44

 SOFTWARE ENGINEERING UNIT – 6 MCQs
c) Cause-Effect Graphs Answer: b
d) All Paths Coverage Explanation: They are a part of requirements
Answer: c engineering, while integration & unit test
Explanation: Rest are test strategies of white planning come under architectural design.
box testing. 358. PRD stands for
353. A set of inputs, execution preconditions a) Product Requirement Document
and expected outcomes is known as a b) Project Requirement Document
a) Test plan c) Product Restrictions Document
b) Test case d) None of the mentioned
c) Test document Answer: a
d) Test Suite Explanation: A product requirements
Answer: b document (PRD) is a document written by a
354. When does the testing process stops? company that defines a product they are
a) When resources (time and budget) are making, or the requirements for one or more
over new features for an existing product.
b) When some coverage is reached 359. Which mechanism is applied to use a
c) When quality criterion is reached design pattern in an OO system?
d) Testing never ends a) Inheritance
Answer: c b) Composition
Explanation: As software testing is an c) All of the mentioned
exhaustive process, when the quality d) None of the mentioned
assurance is established and the product is Answer: c
ready to be delivered, testing is stopped. Explanation: Using inheritance, an existing
355. Which of the following is not a part of a design pattern becomes a template for a new
test design document? [Link] is a concept that leads
a) Test Plan to aggregate objects.
b) Test Design Specification 360. Design patterns does not follow the
c) Test Case Specification concept of software reuse.
d) Test Log a) True
Answer: d b) False
Explanation: Test log is a part of testing Answer: b
result document. Explanation: Design patterns allow the
356. Specifying a set of test cases or test designer to create the system architecture by
paths for each item to be tested at that level integrating reusable components.
is known as 361. The use of design patterns for the
a) Test case generation development of object-oriented software has
b) Test case design important implications for
c) ALL of the mentioned a) Component-based software engineering
d) None of the mentioned b) Reusability in general
Answer: c c) All of the mentioned
357. Acceptance & system test planning are a d) None of the mentioned
part of architectural design. Answer: c
a) True 362. Which of the following is a design
b) False pattern?
DIWAKAR EDUCATION HUB Page 45
 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Behavioral Answer: a
b) Structural Explanation: Each design pattern has a name
c) Abstract Factory and use of each pattern has consequences.
d) All of the mentioned 367. Which pattern prevents one from
Answer: d creating more than one instance of a
Explanation: All the options are design variable?
patterns so option d. a) Factory Method
363. You want to minimize development cost b) Singleton
by reusing methods? Which design pattern c) Observer
would you choose? d) None of the mentioned
a) Adapter Pattern Answer: b
b) Singleton Pattern Explanation: In singleton pattern, the class
c) Delegation pattern itself is made responsible for keeping track of
d) Immutable Pattern its [Link] it ensures that no more than
Answer: c one instance is created.
Explanation: The delegation pattern is a 368. Facade pattern promotes weak coupling
design pattern in OOP where an object, between subsystem and its clients.
instead of performing one of its stated tasks, a) True
delegates that task to an associated helper b) False
object. Answer: a
364. You want to avoid multiple inheritance. Explanation: It is one of the patterns
Which design pattern would you choose? [Link] facade pattern shields clients
a) Abstraction-Occurrence Pattern from subsystem classes and reduces the
b) Player-Role Pattern number of objects that clients deal with.
c) General Hierarchy Pattern 369. Which design pattern defines one-to-
d) Singleton Pattern many dependency among objects?
Answer: b a) Singleton pattern
Explanation: The answer is self-explanatory. b) Facade Pattern
365. The recurring aspects of designs are c) Observer pattern
called design d) Factory method pattern
a) patterns Answer: c
b) documents Explanation: Observer pattern defines one-
c) structures to-many dependency among objects so that
d) methods when one object changes its state, all its
Answer: a dependents are notified.
Explanation: A pattern is the outline of a 370. Facade pattern couples a subsystem
reusable solution to a general problem from its clients.
encountered in a particular context. a) True
366. Design pattern is a solution to a problem b) False
that occurs repeatedly in a variety of Answer: b
contexts. Explanation: A facade can be a single entry
a) True point to each subsystem level. It decouples
b) False the subsystem.

DIWAKAR EDUCATION HUB Page 46

 SOFTWARE ENGINEERING UNIT – 6 MCQs
371. In factory method pattern, the Answer: b
framework must instantiate classes but it Explanation: Components of an application,
only knows about the abstract classes, which ranging in size from subsystems to single
it cannot initiate. How would one solve this objects, may be reused.
problem? 376. COTS product reuse means
a) encapsulating the knowledge of which a) Class and function libraries that implement
document subclass to is to be created and commonly used abstractions are available for
b) moving this knowledge out of the reuse
framework b) Shared components are woven into an
c) instantiating the application specific application at different places when the
documents without knowing their class program is compiled
d) all of the mentioned c) Large-scale systems that encapsulate
Answer: d generic business functionality and rules are
Explanation: Following all the options in configured for an organization
order will solve the factory method problem. d) Systems are developed by configuring and
372. Reuse-based software engineering is a integrating existing application systems
software engineering strategy where the Answer: d
development process is geared to reusing 377. .NET are specific to which platform?
existing software. a) Java
a) True b) Mac-OS
b) False c) Microsoft
Answer: a d) LINUX
373. The open source movement has meant Answer: c
that there is a huge reusable code base Explanation: NET Framework (pronounced
available at dot net) is a software framework developed
a) free of cost by Microsoft that runs primarily on Microsoft
b) low cost Windows.
c) high cost 378. Which of the following is a generic
d) short period of time structure that is extended to create a more
Answer: b specific subsystem or application?
Explanation: The open source movement has a) Software reuse
meant that there is a huge reusable code b) Object-oriented programming language
base available at low cost. This may be in the c) Framework
form of program libraries or entire d) None of the mentioned
applications. Answer: c
374. Consider the example and categorize it Explanation: Frameworks are implemented
accordingly, “A pattern-matching system as a collection of concrete and abstract
developed as part of a text-processing system object classes in an object-oriented
may be reused in a database management programming language.
system”. 379. “An ordering system may be adapted to
a) Application system reuse cope with a centralized ordering process in
b) Component reuse one company and a distributed process in
c) Object and function reuse another.” Which category the example
d) None of the mentioned belong to?

DIWAKAR EDUCATION HUB Page 47

 SOFTWARE ENGINEERING UNIT – 6 MCQs
a) Process specialization the commonly used object-oriented
b) Platform specialization programming languages.
c) Environment specialization 384. Which frameworks support the
d) Functional specialization development of system infrastructures such
Answer: a as communications, user interfaces, and
Explanation: In process specialization, the compilers?
system is adapted to cope with specific a) Middleware integration frameworks
business processes. b) System infrastructure framework
380. Which of the following is not an c) Enterprise application frameworks
advantages of software reuse? d) Web application frameworks
a) lower costs Answer: b
b) faster software development 385. The MVC pattern was originally
c) high effectiveness proposed in the 1980s as an approach to
d) lower risks a) Web application frameworks
Answer: c b) Middleware integration frameworks
Explanation: Effectiveness depends on how c) Web application frameworks
one reuses the existing product. d) GUI design
381. Which framework class include Answer: d
standards and classes that support Explanation: The MVC pattern was originally
component communication and information proposed in the 1980s as an approach to GUI
exchange? design that allowed for multiple
a) System infrastructure frameworks presentations of an object and separate
b) Middleware integration frameworks styles of interaction with each of these
c) Enterprise application frameworks presentations.
d) MVC 386. MVC framework includes
Answer: b a) Observer pattern
382. Which of the following is not a benefit of b) Strategy pattern
software reuse? c) Composite pattern
a) Standards compliance d) All of the mentioned
b) Increased Reliability Answer: d
c) Reduced Process risk Explanation: MVC framework includes the
d) Maintaining a component library Observer pattern, the Strategy pattern, the
Answer: c Composite pattern, and a number of others .
Explanation: There can be thousands of 387. Which category the following statement
components in a frameworks whose belongs,”Classes to create and manage
maintenance is quite difficult. sessions are usually part of a WAF”?
383. In which of the following language the a) Session management
frameworks will not work? b) Security
a) C# c) User interaction
b) Ruby d) Database support
c) PHP Answer: a
d) Java 388. Which framework’s applications are
Answer: c difficult to deal with?
Explanation: Frameworks available in all of a) MVC pattern
DIWAKAR EDUCATION HUB Page 48
 SOFTWARE ENGINEERING UNIT – 6 MCQs
b) Web application frameworks 392. Service Oriented Architecture (SOA) is
c) Debugging framework a) Strongly Coupled
d) None of the mentioned b) Loosely Coupled
Answer: c c) Strongly Cohesive
Explanation: Debugging framework based d) Loosely Cohesive
applications is difficult because you may not Answer: b
understand how the framework methods Explanation: SOA is the architectural style
interact. This is a general problem with that supports loosely coupled services to
reusable software . enable business flexibility.
389. Which of the following option is not 393. Which of the following is an essential
provided by formal methods? principle of an architecture?
a) providing frameworks a) Consistency
b) verifying systems b) Reliability
c) provide investors c) Scalability
d) both providing frameworks and verifying d) All of the mentioned
systems Answer: d
Answer: d Explanation: Architecture implies a
Explanation: A method is formal if it has a consistent and coherent design approach.
sound mathematical basis, typically given by 394. Which of the following is not a phase of
a formal specification language. “bathtub curve” of hardware reliability?
390. Which of the following provides a a) Useful Life
concise, unambiguous, and consistent b) Burn-in
method for documenting system c) Wear-out
requirements? d) Time
a) CMM Answer: d
b) ISO-9001 Explanation: Time is the horizontal
c) CASE tools dimension on which the bathtub curve is built
d) Formal methods and not the phase.
Answer: d 395. How is reliability and failure intensity
Explanation: Formal methods provide a related to each other?
concise, unambiguous, and consistent a) direct relation
method for documenting system b) inverse relation
requirements. c) no relation
391. It is generally not necessary to apply d) none of the mentioned
formal methods to every aspect of a major Answer: b
system. Explanation: As the reliability increases,
a) True failure intensity decreases.
b) False 396. How many product quality factors are
Answer: a proposed in McCall quality model?
Explanation: Those components that are a) 2
safety critical are first choices, followed by b) 3
components whose failure cannot be c) 11
tolerated. d) 8

DIWAKAR EDUCATION HUB Page 49

 SOFTWARE ENGINEERING UNIT – 6 MCQs
Answer: b the software is being engineered, which is
Explanation: McCall quality model has three functionality.
product quality factors namely: Product 401. Time Behavior and Resource Behavior
revision, Product operation, Product fall under which quality attribute of ISO 9126
Transition . ?
397. Which one of the following is not a a) Reliability
software quality model? b) Efficiency
a) ISO 9000 c) Functionality
b) McCall model d) Usability
c) Boehm model Answer: b
d) ISO 9126 Explanation: The Characteristics mentioned
Answer: a in the question are related to the relationship
Explanation: ISO-9000 series of standards is a between the level of performance of the
set of document dealing with quality systems software and the amount of resources used,
that can be used for quality assurance under stated conditions.
purposes. 402. NHPP stands for
398. What is MTTF ? a) Non Homogeneous Poisson Product
a) Maximum time to failure b) Non-Hetrogeneous Poisson Product
b) Mean time to failure c) Non-Hetrogeneous Poisson Process
c) Minimum time to failure d) Non Homogeneous Poisson Process
d) None of the mentioned Answer: d
Answer: b 403. The CMM model is a technique to
399. How is software reliability defined? a) automatically maintain the software
a) time reliability
b) efficiency b) improve the software process.
c) test the software
c) quality
d) all of the mentioned
d) speed
Answer: b
Answer: a
Explanation: Capability Maturity Model (CMM)
Explanation: Software Reliability mainly
is a strategy for improving the software
concerned with the time component. It can
process, irrespective of the actual life cycle
be seen in various models like Basic Execution model used.
Time Model and Logarithmic Poisson
404. Software Testing with real data in real
Execution Time Model.
environment is known as
400. Suitability, Accuracy, Interoperability, a) alpha testing
and security are what type quality attribute b) beta testing
of ISO 9126 ? c) regression testing
a) Reliability d) none of the mentioned
b) Efficiency Answer: b
c) Functionality Explanation: Beta testing is the last stage of
d) Usability testing, and normally can involve sending the
Answer: c product to beta test sites outside the company
Explanation: All the Characteristics for real-world exposure or offering the product
mentioned in the question are related to for a free trial download over the Internet.
achievement of the basic purpose for which

DIWAKAR EDUCATION HUB Page 50