Unit-4

1. Explain integration testing and system testing.

a) Integration testing
Integration testing is carried out after all (or at least some of) the modules
have been unit tested.
• The objective of integration testing is to detect the errors at the module
interfaces (call parameters).
• Thus, the primary objective of integration testing is to test the module
interfaces, i.e., there are no errors in parameter passing, when one module
invokes the functionality of another module.
• During integration testing, different modules of a system are integrated in a
planned manner using an integration plan.
• We can develop an integration plan by examining the structure chart or
module dependency graph.
Any one (or a mixture) of the following approaches can be used to develop the
test plan:
▪ Big-bang approach to integration testing
▪ Top-down approach to integration testing
▪ Bottom-up approach to integration testing
▪ Mixed (also called sandwiched ) approach to integration testing
Big-bang approach to integration testing
In this approach, all the modules making up a system are integrated in a single
step.In simple words, all the unit tested modules of the system are simply
linked together and tested. This technique can meaningfully be used only for
very small systems.
Bottom-up approach to integration testing
• Large software products are often made up of several subsystems. In bottom-
up integration testing, first the modules for the each subsystem are integrated.
• In a pure bottom-up testing no stubs are required, and only test-drivers are
required.
Top-down approach to integration testing
Top-down integration testing starts with the root module in the structure chart
and one or two subordinate modules of the root module.Top-down integration
testing approach requires the use of program stubs to simulate the effect of
lower-level routines that are called by the routines undertest.
Mixed approach to integration testing
• The mixed (also called sandwiched) integration testing follows a combination
of top-down and bottom-up testing approaches.
• In the mixed testing approach, testing can start as and when modules
become available after unit testing.In this approach, both stubs and drivers are
required to be designed.
SYSTEM TESTING
• System tests are designed to validate a fully developed system to assure that
it meets its requirements. The test cases are therefore designed solely based
on the SRS document
• The system testing procedures are the same for both object-oriented and
procedural programs, since system test cases are designed solely based on the
SRS document and the actual implementation (procedural or object- oriented)
is immaterial.
• There are essentially three main kinds of system testing depending on who
carries out testing:
1. Alpha Testing: Alpha testing refers to the system testing carried out by the
test team within the developing organization.
2. Beta Testing: Beta testing is the system testing performed by a select group
of friendly customers.
3. Acceptance Testing: Acceptance testing is the system testing performed by
the customer to determine whether to accept the delivery of the system.
• With respect to test case design system testing can be classified as functional
testing(smoke testing) and Performance testing
Smoke Testing
• Smoke testing is done to check whether at least the main functionalities of
the software are working properly.
• For example, for a library automation system, the smoke tests may check
whether books can be created and deleted, whether member records can be
created and deleted, and whether books can be loaned and returned.
Performance Testing
• Performance testing is carried out to check whether the system meets the
non- functional requirements identified in the SRS document.

2.explain the basic concepts and terminologies in testing.

a) Basic Concepts and Terminologies
• The tester has been shown as a stick icon, which inputs several test data to
the system and observes the outputs produced by it to check if the system fails
on some specific inputs.
Unless the conditions under which a software fails are noted down, it becomes
difficult for the developers to reproduce a failure observed by the testers
Terminologies
IEEE Standard Glossary of Software Engineering Terminology [IEEE90]
• A mistake is essentially any programmer action that later shows up as an
incorrect result during program execution. For example, during coding a
programmer might commit the mistake of not initializing a certain variable.
• An error is the result of a mistake committed by a developer in any of
thedevelopment activities.
• The terms error, fault, bug, and defect are considered to be synonyms in the
area of program testing.
Example:-Can a designer’s mistake give rise to a program error? Give an
example of a designer’s mistake and the corresponding program error.
Answer: Yes, a designer’s mistake give rise to a program error. For example, a
requirement might be overlooked by the designer, which can lead to it being
overlooked in the code as well.
• A failure of a program essentially denotes an incorrect behavior exhibited by
the program during its execution.
• Software failure can be traced to some bug.
 A test case is a triplet [I ,S,R], where I is the data input to the program
undertest, S is the state of the program at which the data is to be input, and
R is the result expected to be produced by the program.
• An example of a test case for text editor is—[input: “abc”, state: edit, result:
abc isdisplayed]
• A test scenario is an abstract test case in the sense that it only identifies the
aspects of the program that are to be tested without identifying the input,
state, or output.
• A test script is an encoding of a test case as a shortprogram.
• A test case is said to be a positive test case if it is designed to test whether
the software correctly performs a required functionality.
• A test case is said to be negative test case, if it is designed to test whether the
software carries out something that is not required of the system.
• A test suite is the set of all test that have been designed by a tester to test a
given program
• Testability of a requirement denotes the extent to which it is possible to
determine whether an implementation of the requirement conforms to it in
both functionality and performance
• A failure mode of software denotes an observable way in which it canfail.
• Equivalent faults denote two or more bugs that result in the system failing in
the same failure mode.
3a.Distinguish between white box testing and black box testing.
a)
3b.what are the principles of coding.
a) • Coding is undertaken once the design phase is complete and the design
documents have been successfully reviewed.
• In the coding phase, every module specified in the design document is coded
and unit tested.
• The objective of the coding phase is to transform the design of a system into
code in a high-level language, and then to unit test this code.
• A coding standard gives a uniform appearance to the codes written by
different engineers
• It facilitates code understanding and code reuse
• It promotes good programming practices.
Representative coding guidelines.
• Do not use a coding style that is too clever or too difficult to understand
• Avoid obscure side effects
• modifications to the parameters passed by reference, modification of global
variables, and I/O operations
• Do not use an identifier for multiple purposes
• Each variable should be given a descriptive name indicating its purpose
• Use of variables for multiple purposes usually makes future enhancements
more difficult.
• Code should be well-documented
• Length of any function should not exceed 10 source lines
• Do not use GO TO statements
4.what are levels of testing?explain in detail.
a) Software Testing is an activity performed to identify errors so that errors can
be removed to obtain a product with greater quality. To assure and maintain
the quality of software and to represent the ultimate review of specification,
design, and coding, Software testing is required. There are different levels of
testing :
 Unit Testing: In this type of testing, errors are detected individually from
every component or unit by individually testing the components or units of
software to ensure that they are fit for use by the developers. It is the
smallest testable part of the software.
 Integration Testing: In this testing, two or more modules which are unit
tested are integrated to test i.e., technique interacting components, and are
then verified if these integrated modules work as per the expectation or
not, and interface errors are also detected.
 System Testing: In system testing, complete and integrated Softwares are
tested i.e., all the system elements forming the system are tested as a whole
to meet the requirements of the system.
 Acceptance Testing: This is a kind of testing conducted to ensure that the
requirements of the users are fulfilled before its delivery and that the
software works correctly in the user’s working environment.
These tests can be conducted at various stages of software development. The
levels of testing along with the corresponding software development phase are
shown in the following diagram:

Unit-5
1.Discuss about common modelling techniques of use case diagrams.
a) Use case diagrams are a popular technique for analyzing and modeling
system requirements by focusing on the interactions between users (actors)
and the system. There are several common modeling techniques used for
developing use case diagrams, including:
1. System boundary: The system boundary defines what is included in the
system and what is external to the system. This boundary is represented by a
rectangle enclosing all the use cases and actors under consideration.
2. Actors: Actors are external entities that interact with the system. They may
represent users or other systems. Actors are represented by stick figures and
are placed outside the system boundary.
3. Use cases: Use cases represent the functions or tasks an actor performs with
the system. They are represented by ovals and can be named after the action
the actor takes. Use cases are often organized into logical groupings, such as
registration, payment, or search.
4. Relationships: Relationships are used to define the connections between
actors and use cases. There are three main types of relationships used in use
case diagrams:
 Association: An association represents a simple or passive interaction
between an actor and use case, where the actor is connected to the use
case by a straight line.
 Generalization: A generalization indicates a hierarchical relationship
between two or more use cases or actors. This is represented by an
inheritance arrow.
 Extension: An extension shows a variant of the primary use case
triggered under specific circumstances. It is represented by a dashed
arrow that extends from the primary use case.
5. Use case descriptions: Once the use case diagram is complete, the use cases
can be described in more detail using textual descriptions.
2. what is the importance of modelling. Explain principles of modelling.
a) Importance of modelling:
Modeling is a proven and well-accepted engineering technique. We build
architectural models of houses and high rises to help their users visualize the
final product.
Modeling is not only limited to the construction industry. Modeling is applied
in the fields of aeronautics, automobile, picture, sociology, economics,
software development and many more. We build models so that we can
validate our theories or try out new ones with minimal risk and cost.
A model is a simplification of reality.
A good model includes those elements that have broad effect and omits those
minor elements that are not relevant to the given level of abstraction. A model
may be structural, emphasizing the organization of the system, or it may be
behavioral, emphasizing the dynamics of the system.
We build models so that we can better understand the system we are
developing.
Through modeling, we achieve four aims:

 Models help us to visualize a system as it is or as we want it to be.

 Models permit us to specify the structure or behavior of a system.
 Models gives us a template that guides us in constructing a system.
 Models document the decisions we have made.

The larger and more complex the system becomes, the more important
modeling becomes, for one very simple reason:
We build models of complex systems because we cannot comprehend such a
system in its entirety.
Every project can benefit from modeling. Modeling can help the development
team better visualize the plan of their system and allow them to develop more
rapidly by helping them build the right thing. The more complex your project,
the more likely it is that you will fail or that you will build the wrong thing if
you do on modeling at all.
Principles of modelling:
Modeling has rich history in all the engineering disciplines. That experience
suggests four basic principles of modeling.
First principle of modeling:
The choice of what models to create has a profound influence on how a
problem is attacked and how a solution is shaped.
Choose your models well. The right models will highlight the most nasty
development problems. Wrong models will mislead you, causing you to focus
on irrelevant issues.
Second principle of modeling:
Every model may be expressed at different levels of precision.
Sometimes, a quick and simple executable model of the user interface is
exactly what you need. At other times, you have to get down to complex details
such as cross-system interfaces or networking issues etc.
In any case, the best kinds of models are those that let you choose your degree
of detail, depending on who is viewing it. An analyst or an end user will want to
focus on issues of what and a developer will want to focus on issues of how.
Third principle of modeling:
The best models are connected to reality.
In software, the gap between the analysis model and the system’s design
model must be less. Failing to bridge this gap causes the system to diverge over
time. In object-oriented systems, it is possible to connect all the nearly
independent views of a system into one whole.
Fourth principle of modeling:
No single model is sufficient. Every non-trivial system is best approached
through a small set of nearly independent models.
In the case of a building, you can study electrical plans in isolation, but you can
also see their mapping to the floor plan and perhaps even their interaction
with the routing of pipes in the plumbing plan.
The same is true of object-oriented systems. To understand the architecture of
such a system, you need several complementary and interlocking views: a use
case view , a design view , a process view , an implementation view and a
deployment view . Depending on the nature of the system, some models may
be more important than others.
3.Explain about conceptual model of the UML.
a) The conceptual model of the UML forms the foundation for understanding
how to use this powerful visual language for software design. It consists of
three main parts:
Building Blocks: These are the basic elements that you'll use to construct UML
diagrams. The most fundamental ones are:
 Things: These represent real-world entities or concepts that are relevant
to your software system. In UML, things are typically shown as classes,
objects, components, and actors.
 Relationships: These define how the things interact with each other. In
UML diagrams, relationships are depicted using arrows or lines
connecting the relevant elements.
Rules: These govern how you can put the building blocks together to create
well-formed and meaningful UML diagrams. Here are some key aspects
covered by the rules:
 Semantics: This refers to the meaning associated with the elements and
their relationships. The UML rules ensure that the diagrams are
consistent and unambiguous.
 Structure: The rules dictate how elements can be combined to form valid
diagrams. For example, there are specific ways to show inheritance
between classes.
  Completeness: A well-formed model should provide a comprehensive
picture of the system, capturing all the essential elements and their
interactions.
Understanding these building blocks and rules is crucial for effectively using
UML diagrams to design software systems. Think of it like learning the
alphabet and grammar before you can write a sentence.
Here are some additional points to consider:
Diagrams: While not strictly part of the conceptual model itself, UML utilizes
various diagrams like class diagrams, sequence diagrams, and use case
diagrams to represent different aspects of the system. These diagrams all
adhere to the core principles of the conceptual model.
Object-Oriented Focus: The UML is heavily influenced by object-oriented
programming principles. Building blocks like classes and objects are central to
the UML framework.
By grasping the conceptual model, you'll be well on your way to creating UML
diagrams that effectively communicate your software design ideas.
4. Explain about class diagram and sequence diagram with suitable example.
a) Class Diagram:--
A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. These diagrams are the most common diagram found in
modeling object-oriented systems. Class diagrams address the static design
view of a system. Class diagrams that include active classes address the static
process view of a system.
Sequence diagram:
A sequence diagram is an interaction diagram that emphasizes the
timeordering of messages.Sequence diagrams, commonly used by developers,
model the interactions between objects in a single use case. They illustrate
how the different parts of a system interact with each other to carry out a
function, and the order in which the interactions occur when a particular use
case is executed.

Unit-6
1.Breifly explain software configuration management.

a) Software configuration management (SCM) is all about keeping track of

changes made to software throughout its development and lifecycle. Here's a
quick rundown:

 Think Version Control: Imagine multiple people working on a document.

SCM ensures everyone has the right version, tracks edits, and lets you
revert to previous versions if needed.
 More Than Code: It applies to all aspects of the software, including source
code, documentation, configurations, and more.
 Key Goals:
o Maintain control: Ensure authorized changes are made and tracked.
o Improve collaboration: Enable teams to work together effectively.
o Facilitate troubleshooting: Pinpoint the source of issues if something
goes wrong.
o Manage deployments: Control how and when software updates are
rolled out.
 Tools of the Trade: Version control systems like Git are popular SCM tools.
They store all versions of files, allowing you to see the history of changes
and revert to earlier states.

In essence, SCM keeps your software development organized, efficient, and

less prone to errors. It's a vital practice for any software project.

2a.What are software quality factors.

a) Software quality factors are a set of characteristics that define how good a
software product is. These factors help us measure and ensure that the
software meets the needs of its users and functions as intended. There are
many different quality factors, but some of the most important ones can be
grouped into three categories according to McCall's Quality Model:

1. Product Operation Factors:

 Correctness: This ensures the software delivers the expected results

according to its specifications. Does it do what it's supposed to do?
 Reliability: This refers to the software's ability to perform consistently
and avoid failures. Can you count on it to work when you need it?
 Efficiency: This measures how well the software utilizes resources like
memory and processing power. Does it run smoothly without wasting
resources?
 Integrity: This focuses on the software's security features and its ability
to protect data from unauthorized access. Is your data safe and secure?
 Usability: This is all about how easy it is for users to learn, operate, and
navigate the software. Is it user-friendly and intuitive?

2. Product Revision Factors:

 Maintainability: This reflects how easy it is to modify and fix the

software after it's been deployed. Can changes be made efficiently?
 Flexibility: This refers to the software's ability to adapt to new
requirements or changing environments. Can it accommodate future
needs?
 Testability: This is how easy it is to test the software and identify
potential bugs or issues. Can you effectively ensure it works correctly?

3. Product Transition Factors:

  Portability: This measures how easily the software can be transferred to
different operating systems or hardware platforms. Can it run on
different devices?
 Reusability: This refers to the ability to reuse code modules or
components in other software projects. Can parts of this software be
used to build something new?
 Interoperability: This is the software's capacity to work seamlessly with
other systems and exchange data effectively. Can it play well with
others?

2b.What are the maintenance process model.

a) Software maintenance process models provide a structured approach to

keeping software functional, reliable, and efficient throughout its lifecycle.
Here's a breakdown of some common models:

1. Corrective Maintenance Model: This reactive approach focuses on fixing

bugs and errors after they occur. It typically involves these steps:
o Identify the problem.
o Analyze the cause of the issue.
o Design and implement a fix.
o Test the fix and deploy the update.
2. Adaptive Maintenance Model: This model addresses changes in the
software's environment or new user requirements. It involves:
o Identifying the need for modification.
o Analyzing the impact of the change.
o Adapting the software to accommodate the changes.
o Testing and deploying the modified version.
3. Perfective Maintenance Model: This proactive approach aims to improve
the software's non-functional aspects like performance, usability, or
security. It might involve:
o Identifying areas for improvement.
o Analyzing potential enhancements.
o Designing and implementing improvements.
o Testing and deploying the optimized software.
4. Preventive Maintenance Model: This proactive approach focuses on
preventing problems before they arise. It involves activities like:
o Code reviews to identify potential issues.
o Refactoring code to improve maintainability.
o Updating documentation to reflect changes.
o Unit testing to catch bugs early on.
5. Boehm's Model: This economic model emphasizes cost-effectiveness in
maintenance. It involves a feedback loop where changes are proposed,
evaluated for cost and impact, and then implemented or rejected.

These models are not mutually exclusive. In practice, a combination of these

approaches might be used to maintain software effectively.

3.What is software maintenance?Explain in detail.

a) Software maintenance denotes any changes made to a software product
after it has been delivered to the customer.
Maintenance is inevitable for almost any kind of product. However, most
products(hardware) need maintenance due to the wear and tear caused by
use. On the other hand, software products do not need maintenance on this
count, but need maintenance to correct errors, enhance features, port to new
platforms, etc.
IEEE defines, “software maintenance is the process of modifying a software
system or component after delivery to correct faults, improve performances, or
other attributes; or adapt to a changed environment”
CHARACTERISTICS OF SOFTWARE MAINTENANCE
 Software maintenance is becoming an important activity of a large number
of organizations due to the rate at which hard- ware becoming outdated,
the demand of the user community to see the existing software products
run on newer platforms, run in newer environments, and/or with enhanced
features.
 Every software product continues to evolve after its development through
maintenance efforts.
Special Problems Associated with Software Maintenance
 Software maintenance is one of the most neglected areas of software
engineering
 Software maintenance has a very poor image in industry. Therefore, an
organization often cannot employ bright engi- neers to carry out
maintenance work.
 majority of software products needing maintenance are legacy products
4a.What is software reuse.
a) Software Reuse
 Software products are expensive.
 A possible way to reduce development cost is to reuse parts from previously
developed software.
 The reused product ensure quality.
 Software development with reuse is very similar to a modern hardware
engineer building an electronic circuit by using standard types of ICs and
other components.
 Software reuse is the process of producing software systems from existing
software systems rather than building soft- ware from scratch.
 Reusability is the degree to which a reuse entity can be reused. It has two
major aspects, namely, usability and useful- ness.
 Usability is the degree to which an asset is easy to use in the sense of the
amount of effort that is needed to use an as- set.
 It involves comprehensibility, compliance with standards, ease of
development, etc. Usefulness is the frequency of suit- ability for use.
WHAT CAN BE REUSED?
 Almost all artifacts associated with software development, including project
plan and test plan can be reused.
 However, the prominent items that can be effectively reused are:
o Requirements specification
o Design
o Code
o Test cases
o Knowledge
 Knowledge is the most abstract development artifact that can be reused.
 Out of all the reuse artifacts, reuse of knowledge occurs automatically
without any conscious effort.
 An unplanned reuse of knowledge can assign a developer experienced in
one type of product might be included in a team developing a different type
of software. Also, it is difficult to remember the details of the potentially
reusable de- velopment knowledge.
 A planned reuse of knowledge can increase the effectiveness of reuse. For
this, the reusable knowledge should be sys- tematically extracted and
documented. But, it is usually very difficult to extract and document
reusable knowledge.
4b.Explain reuse at organization level with example.
a) Achieving organization-level reuse requires adoption of the following steps:
o Assess of an item’s potential for reuse.
o Refine the item for greater reusability.
o Enter the product in the reuse repository.
Assessing a product’s potential for reuse
A sample questionnaire to assess a component’s reusability is the following:
 Is the component’s functionality required for implementation of systems in
the future?
 How common is the component’s function within its domain?
 Would there be a duplication of functions within the domain if the
component is taken up?
 Is the component hardware dependent?
 Is the design of the component optimized enough?
 If the component is non-reusable, then can it be decomposed to yield some
reusable components?
 Can we parametrize a non-reusable component so that it becomes
reusable?

Example: Reusing a Login Module Across Projects

Imagine an organization developing various software applications, each

requiring a user login functionality. Here's how reuse can benefit them:

 Develop a Secure and Well-Tested Login Module: A centralized team can

create a robust login module with features like user authentication,
password encryption, and session management.
 Integrate the Login Module into Different Applications: Each development
team can easily integrate this pre-built, secure login module into their
projects, saving time and effort.
 Maintain the Login Module Centrally: Any updates, bug fixes, or security
enhancements to the login module can be done centrally, ensuring all
applications benefit from the changes.

This example demonstrates how organizational-level reuse can streamline

development, improve security, and ensure consistency across various
projects.