Software

Design, Testing
& Maintenance
Software Design
 Design is ‘‘the process of applying various techniques and principles for
the purpose of defining a device, a process, or a system in sufficient
detail to permit its physical realization.’’
 The design process converts the ‘‘what’’ of the requirements to the
‘‘how’’ of the design. The results of the design phase should be a
document that has sufficient detail to allow the system to be
implemented without further interaction with either the specifier or the
user.
 When tools are integrated so that information created by one tool can be
used by another, a system for the support of software development,
called computer-aided software engineering(CASE), is established.
 CASE combines software, hardware, and a software engineering database
(a repository containing important information about analysis, design,
program construction, and testing) to create a software engineering
environment analogous to CAD/CAE (computer-aided design/engineering)
for hardware.
 CASE (Computer-Aided Software Engineering) tools are software applications that provide automated support
for various phases of software development, including software testing. These tools enhance the efficiency,
effectiveness, and quality of testing processes. Here’s how CASE tools are used in software testing:
 1. Test Planning and Management
• Test Plan Creation: CASE tools help in creating detailed test plans by providing templates and guidelines.
They ensure all necessary aspects of testing are covered.
• Test Case Management: They offer features to design, organize, and manage test cases. This includes
maintaining a repository of test cases, which can be reused across different projects.
• Scheduling: CASE tools assist in scheduling tests, assigning tasks to team members, and tracking progress.
• Resource Allocation: They help in identifying the resources required for testing and allocate them
effectively.
 2. Automated Test Case Generation
• Test Script Generation: CASE tools can automatically generate test scripts based on the code or models of
the system. This saves time and ensures comprehensive coverage.
• Regression Test Suites: They help create and maintain regression test suites, ensuring that new changes
do not break existing functionality.
 3. Test Execution
• Automated Testing: CASE tools support the automation of test execution. They can run test scripts
automatically, compare actual outcomes with expected results, and generate reports.
• Simulators and Emulators: Some CASE tools provide simulators and emulators for testing software in
different environments without the need for actual hardware.
Phases of Design Process

 Data design—This phase produces the data structures.

 Architectural design—This phase produces the structural units
(classes).
 Interface design—This phase specifies the interfaces between the
units.
 Procedural design—This phase specifies the algorithms of each
method.
Design Concepts

 Refinement—This design approach develops the design by

successively refining levels of detail. Sometimes this is called
‘‘top-down’’ design.
 Modularity—This is a structuring approach that divides the
software into smaller pieces. All the pieces can be integrated to
achieve the problem requirements.
ATTRIBUTES OF DESIGN
 Abstraction- Abstraction in software design tries to let the designer
focus on the essential issues without regard to unnecessary low-level
details. Good abstraction hides the unnecessary details.
 Cohesion—A material is cohesive if it sticks together. A procedure is
cohesive if all the statements in the procedure are related to every
output. A class is cohesive if all the attributes in the class are used by
every method. That is, cohesion in a module is achieved if everything is
related. High cohesion is generally considered desirable.
 Coupling—Coupling is a measure of how interconnected modules are.
Two modules are coupled if a change to a variable in one module may
require changes in the other module. Usually the lowest coupling is
desirable.
Control Flow Graphs

 A control flow graph describes the sequence in which the

different instructions of a program get executed.
 In other words, a control flow graph describes how the control
flows through the program.
 Use of Control Flow Graph in System Testing

 A control flow graph (CFG) is a graphical representation of all paths that might be traversed
through a program during its execution. It is a vital tool in system testing for several reasons:
 1. Understanding Program Logic
• Visualization: A CFG helps testers and developers visualize the flow of control within the
software. It displays the sequence in which statements, instructions, or functions are executed,
making it easier to understand complex program logic.
• Decision Points: It clearly marks decision points (such as loops and conditionals) and the
possible paths through the program, helping testers grasp the logic behind the software's
behavior.
 2. Test Case Design
• Path Coverage: Testers can use the CFG to identify all possible paths through the code, which
is essential for path coverage testing. This ensures that all paths, including edge cases, are
tested.
• Branch Coverage: CFG is useful for branch coverage testing. Testers can ensure that each
branch (decision point) in the code has been executed at least once, improving the
thoroughness of the tests.
• Basis Path Testing: It aids in basis path testing by identifying independent paths through the
program. These are the minimum number of paths that, when tested, will cover every
statement and condition in the program at least once.
 Regression Testing
• Impact Analysis: When changes are made to the code, CFG helps in
identifying the affected paths. Testers can focus their regression tests on
these paths to ensure that changes do not introduce new bugs.
• Test Case Prioritization: CFG helps prioritize test cases based on the
critical paths in the program, ensuring that the most important
functionality is tested first.
 5. Bug Detection
• Path Testing: CFG facilitates path testing, which can uncover bugs that
might not be detected by other testing methods. By ensuring all paths
are tested, hidden bugs are more likely to be discovered.
• Data Flow Analysis: CFG can be used in conjunction with data flow
analysis to track how data moves through the program, helping to detect
anomalies such as data misuse, uninitialized variables, and potential
security vulnerabilities.
Control Flow Graphs

 The following are rules for correct control flow diagrams:

 1. There must be one start node.
 2. From the start node, there must be a path to each node.
 3. From each node, there must be a path to a halt node.
Software Testing

 Software testing is the execution of the software with actual test

data. Sometimes it is called dynamic software testing to
distinguish it from static analysis
 which is sometimes called static testing. Static analysis involves
analyzing the source code to identify problems.
System Testing
 Exhaustive testing is the execution of every possible test case. Rarely can
we do exhaustive testing. Even simple systems have too many possible
test cases.
 Two basic concerns in software testing are
 (1) what test cases to use (test case selection)
 (2) how many test cases are necessary (stopping criterion).
 Test case selection can be based on either the specifications (functional),
the structure of the code (structural), the flow of data (data flow), or
random selection of test cases.
Unit Testing

 Unit testing compromises the set of tests performed by an

individual programmer prior to integration of the unit into a
larger system.
 The situation is illustrated as follows:
Coding and debugging ------>Unit Testing ------>Integration
Testing
• Unit Testing can include the following
 Functional test- cases involve exercising the code with
nominal input values for which the expected results are known,
as well as boundary values (minimum values, maximum values,
and values on and just outside the functional boundaries)
 Performances testing- determines the amount of execution
time spend in various parts of the unit, program throughout,
response time, and device utilization by the program unit.
 Stress tests - are those tests designed to intentionally break
the unit. Through this testing we can learn about the strengths
and limitations of a program by examining the manner in which
a program unit breaks.
 Structure tests- are concerned with exercising the internal
logic part of a program and traversing particular execution
paths. (White box Testing)
Integration Testing
 After tested each module individually, integrated testing phase is
proceeded.
 Testing approach can be either top-up or bottom-up.
 Bottom-up integration is the traditional strategy to integrate the
components of a software system into a functioning whole.
 Bottom-up integration consists of unit testing, which is followed
by subsystem testing, followed by testing of the entire system.
 Unit testing has the goal of discovering errors in the individual
modules of the system.
Regression Testing

 When some errors occur in a program then these are rectified.

 For rectification of these errors, changes are made to the
program. Due to these changes some other errors may be
incorporated in the program. Therefore, all the previous test
cases are tested again.
 This type of testing is called regression testing.
Art of Debugging

 Debugging means fixing the error. It is carried by the

development team with intentionally removed of the error.
 Debugging is a necessary process in almost any new software or
hardware development process, whether a commercial product
or an enterprise or personal application program.
 Software Quality Assurance

 Software Quality
 Schulmeyer and McManus have defined software quality as “the fitness
for use of the total software product”. A good quality software does
exactly what it is supposed to do and is interpreted in terms of
satisfaction of the requirement specification laid down by the user.

 Quality Assurance
 Software quality assurance is a methodology that determines the extent
to which a software product is fit for use. The activities that are included
for determining software quality are:
 Auditing
 Development of standards and guidelines
 Production of reports
 Review of quality system
 Quality Factors
 Correctness : Correctness determines whether the software
requirements are appropriately met.
 Usability : Usability determines whether the software can
be used by different categories of users (beginners, non-
technical, and experts).
 Portability : Portability determines whether the software
can operate in different platforms with different hardware
devices.
 Maintainability : Maintainability determines the ease at
which errors can be corrected and modules can be updated.
 Reusability : Reusability determines whether the modules
and classes can be reused for developing other software
products.
Software maintenance task:
 Corrective:
 Corrective maintenance of a software product is necessary to rectify the
bugs observed while the system is in use.
 Adaptive:
 A software product might need maintenance when the customers need
the product to run on new platforms, on new operating systems, or when
they need the product to interface with new hardware or software.
 Perfective:
 A software product needs maintenance to support the new features that
users want it to support, to change different functionalities of the system
according to customer demands, or to enhance the performance of the
system.
Software Maintenance

 Software maintenance is the modification of a software

product after delivery to correct faults, to improve performance
or other attributes .
 A common perception of maintenance is that it merely involves
fixing defects.
Problems associated with software
maintenance
 Software maintenance work typically is much more expensive than what
it should be and takes more time than required.
 In software organizations, maintenance work is mostly carried out using
adhoc techniques. (no formal planning)
 There are no systematic and planned activities for maintaining software.
 Software maintenance has a very poor image in industry. Therefore, an
organization often cannot employ bright engineers to carry out
maintenance work.
 Even though maintenance suffers from a poor image, the work involved is
often more challenging than development work.
 During maintenance it is necessary to thoroughly understand someone
else’s work and then carry out the required modifications and extensions.
 Another problem associated with maintenance work is that the majority
of software products needing maintenance are legacy products.
Legacy software products

 A legacy system is hard to maintain. The typical problems

associated with legacy systems are poor documentation,
unstructured (spaghetti code with ugly control structure), and
lack of personnel knowledgeable in the product.
 Many of the legacy systems were developed long time back. But,
it is possible that a recently developed system having poor
design and documentation can be considered to be a legacy
system.
Software Reverse Engineering

 Software reverse engineering is the process of recovering the

design and the requirements specification of a product from an
analysis of its code.
 The purpose of reverse engineering is to facilitate maintenance
work by improving the understand ability of a system and to
produce the necessary documents for a legacy system.
 Code-- module specification --design -- requirement
specification
Concept of Software Reliability
 Most important and dynamic characteristic of software is its reliability
 The reliability of a software system is a measure of how well it provides
the services expected of it by its users
 Users do not consider all services to be of equal importance and a system
might be viewed as unreliable if it ever fails to provide some critical
service.
 Reliability is a dynamic system characteristic, which is a function of the
number of software failures.
Error, Fault and Failure

 error refers to the difference between the actual output of a

software and the correct output.
 In this interpretation, error is essentially a measure of the
difference between the actual and the ideal.
 term error to refer to problems in requirements, design, or code.
Error, Fault and Failure

 Fault is a condition that causes a system to fail in performing its

required function. A fault is the basic reason for software
malfunction and is synonymous with the commonly used term
bug.
 Failure is the inability of a system or component to perform a
required function, according to its specifications. A software
failure occurs if the behavior of the software is different from the
specified behavior.
Reliability metrics

 The reliability requirements for different categories of software

products may be different.
 For this reason, it is necessary that the level of reliability required
for a software product should be specified in the SRS (software
requirements specification) document.
There are six reliability
metrics which can be used to quantify the reliability of
software products.
 Rate of occurrence of failure (ROCOF).
 ROCOF measures the frequency of occurrence of unexpected behavior
(i.e. failures).
 Mean Time To Failure (MTTF).
 MTTF is the average time between two successive failures, observed over
a large number of failures.
 Mean Time To Repair (MTTR).
 MTTR measures the average time it takes to track the errors causing the
failure and to fix them.
 Mean Time Between Failure (MTBF).
 · MTTF and MTTR can be combined to get the MTBF metric: MTBF = MTTF
+ MTTR.
 Probability of Failure on Demand (POFOD).
 POFOD measures the likelihood of the system failing when a service
request is made.
 For example, a POFOD of 0.001would mean that 1 out of every 1000
service requests would result in a failure.
 Availability.
 Availability of a system is a measure of how likely shall the system be
available for use over a given period of time.
 This metric not only considers the number of failures occurring during a
time interval, but also takes into account the repair time (down time) of a
system when a failure occurs.
 This metric is important for systems such as telecommunication systems,
and operating systems, which are supposed to be never down and where
repair and restart time are significant and loss of service during that time
is important.