BIT III: PU Compiled By: GIRIJA 1

Unit 6: System Implementation [6 Hrs.]

a. Introduction to system implementation
b. System installation and its types
c. System quality, Software quality assurance ( Formal Technical Review,
Walkthrough, Inspections)
d. System maintenance, types of maintenance, and process of system maintenance
e. System testing

A. Introduction to system implementation

 System implementation refers to the process of putting a designed system into operation
in a real-world environment. It's the phase where the theoretical plans and designs from
earlier stages are translated into a functioning system. This process involves various steps
and considerations to ensure a smooth transition and successful system adoption.
 The purpose of system implementation is to build a properly working system, install it in
organization, replace old systems, prepare system and user documentation and train
users.

Terminology:

No Word Definition
1 Coding A process whereby the physical specifications
created in the previous phases are turned
into working computer codes by the
programmer team.
2 Installation the process of moving from the current
system to the new or enhanced system.
3 Integration testing A testing where it involves two or more
modules that link each other.
4 System A development, installation and testing of
implementation system components and delivery of that
system into production.
5 System testing A testing where it involves the integration of
the whole programs into a system.
6 Unit testing A testing done at the individual level of
program or module.
 BIT III: PU Compiled By: GIRIJA 2

7 User Written or visual information about system;

documentation on how it works, and how to use it.

System implementation has several major activities. There are five major tasks in this phase;
coding, testing, installation, documentation and training as in the given figure. The purpose of
this phase is to convert the physical system specifications into working and reliable software and
hardware, document the work that has been done and provide help for current and future users.

Figure 1.1: Five Activities in the System Implementation Phase

1. Coding
Coding is the process whereby the physical specifications created in the previous phases
are turned into working computer codes by the programmer team. Coding is an activity
where all the designs during the previous phases will be programmed using software that
BIT III: PU Compiled By: GIRIJA 3

have been defined before. This is a time where most of the programmers will sit in front
of computers and do coding.

2. Testing
After coding, a programmer must conduct a test. Each program will be tested in order to
make sure it functions correctly. Later, programs are tested in groups, followed by testing
with the entire system. The first step in testing is to compile the program to detect any
syntax errors. If there is an error, the programmers need to correct it until the program
executes correctly. Then, the next step is to do testing, including unit testing, integration
testing and system testing.

2.1. Unit testing

Unit testing is testing done at the individual level of a program or module. Sometimes, it
refers to module testing. The purpose of unit testing is to identify and reduce execution
errors that cause the program to terminate abnormally, and logic errors that could have
been missed during desk checking. During unit testing, programmers must check
programs that interact with other programs and files individually. But, since the modules
exist and work together with other modules in the system, they must be tested together
in a larger group. This is referred to as integration testing.

2.2. Integration Testing

After finishing the unit testing, the programmer will do the integration testing. Integration
testing is a testing where it involves two or more modules that link each other. It’s a
process of bringing together all of the modules that a program comprises for testing
purposes. First, we need to test the root module and only one of the subordinates. After
that, we need to test another two subordinate modules from the same level. The same
process goes until the next level. We continued this testing until the whole system is
tested as a unit. This is referred to as system testing.

2.3. System Testing

After completing the integration testing, we must perform system testing, which involves
the entire system. It’s similar to integration testing. The difference is, in system testing,
we integrate programs into the system. After the system testing is completed, we can
assume that the system is fully tested and are free of any errors or bugs. So, now, it’s
ready to be installed in the organizations.
 BIT III: PU Compiled By: GIRIJA 4

B. System installation and its types

Installation is the process of moving from the current system to the new or enhanced system.
This also refers to conversion activity; converting an old system to a new system. At this stage,
all users must give up their reliance on the current system and begin to rely on a new system.
There are four approaches of installation; direct, parallel, single-location and phased installation.
Which approaches will be used depends on the organizations and the system’s scope and
complexity.

Direct Installation
 Direct installation, also known as abrupt cut-over installation, involves turning off the old
system and turning on the new system (Figure 1.2).
 It is a high-risk approach as potential major problems may only surface once the new
system is in operation.
 Errors from the new system can directly impact users, affecting their ability to perform
their jobs.
 If the new system fails on the specified date, delays may occur until the issues are
resolved.
 This approach is necessary when there is a business policy effective on a specific date,
and the system must align with it.
 Organizations opting for direct installation should ensure a successful system
implementation to minimize risks.
 Despite its known risks, direct installation may offer cost reduction benefits.

Figure 1.2: Direct Installation

Parallel Installation
 Parallel Installation: Both old and new systems operate simultaneously until management
decides to turn off the old system (Figure 1.3).
 Considered a riskless approach as major problems are resolved before discontinuing the
old system.
 BIT III: PU Compiled By: GIRIJA 5

 Opposite of direct installation in terms of risk mitigation strategy.

 Involves higher costs as the organization runs and maintains two systems simultaneously.
 Expenses include employee salaries and maintenance costs for two similar systems
operating concurrently.
 Users may experience confusion dealing with two systems simultaneously during the
transition period.

Figure 1.3: Parallel Installation

Single-location Installation
 Also known as location or pilot installation.
 Involves trying out a new system at one location to gather experience and inform
deployment decisions for the entire organization (Figure 1.4).
 Can be either direct installation or parallel installation at the selected site.
 Considered a middle-of-the-road approach compared to direct and parallel installations.
 The single location can be a branch office or one department.
 Once the location approves the system, it may be installed at other locations.
 Installation at another site may be direct installation if major errors are fixed at the initial
test location.
 Advantages include minimizing potential damage and costs, as success is determined at
the first site.
 Disadvantage: Installation of the whole system may take a longer period.
 BIT III: PU Compiled By: GIRIJA 6

Figure 1.4: Single-location Installation

Phased Installation
 Similar to single-location installation but involves installing the new system in functional
components.
 An incremental approach where the new system is introduced module by module.
 Different modules of the new and old systems are used together until the entire system
is installed.
 Aims to minimize installation-related risks, similar to the single-location approach.
 Resembles releasing a sequence of system versions.
 Requires careful version control, repeated conversion at each phase, and an extended
period of change.
 Potential drawbacks include user frustration and confusion during the phased
implementation process.

Figure 1.5: Phased installation

 BIT III: PU Compiled By: GIRIJA 7

Installation may also require a system acceptance test plan. System acceptance test is a final
opportunity where end users, management and information system operation decide either to
use or reject the system. System acceptance test is a test performed on the final system wherein
users conduct verification, validation and audit tests. It covers three levels of acceptance testing:

● Verification testing
Verification testing also refers to alpha testing. This testing runs the system in a simulated
environment using simulated data. It’s looking for errors and omissions regarding end
users and design specifications that were specified in the earlier phase of testing.

● Validation testing
Validation testing also refers to beta testing. This testing runs the system in a live
environment using real data. A number of items tested during this testing such as:
o System performance,
o Peak workload processing performance,
o Human engineering test,
o Methods and procedures test,
o Backup and recovery testing.

● Audit testing
Audit testing is a test performed to ensure that the system is free from any errors and
ready to be placed at the real location.

Documenting the system

Every system development is unique and needs unique documentation. There are two basic types
of documentation; system documentation and user documentation.

System Documentation
System documentation records detailed information about system’s design specification,
its internal workings and its functionality (Hoffer et. al., 2005). System documentation is
prepared for maintenance personnel who will be in charge of the system operating in the
future. System documentation can be divided into internal and external documentation.
o Internal documentation: Internal documentation is part of the program source
code or is generated at compile time
o External documentation: External documentation is a system documentation that
includes the outcome of structured diagramming techniques such as data flow and
 BIT III: PU Compiled By: GIRIJA 8

entity-relationship diagrams. Although it don’t cover the code itself, but it can
provide useful information to the primary users of system documentation-
maintenance programmer.

User Documentation
As stated earlier, system documentation is intended for system maintenance
programmers; user documentation is intended for system users. User documentation
consists of written and visual information about the system, such as what its function is,
how its function and how to use it. There are few types of user documentations;
i. Reference guide - consist of exhaustive list of system functions and
commands
ii. Quick reference guide - provide essential information about operating a
system in a short, concise format
iii. User’s guide - provide information on how users can use a computer
system to perform specific tasks.

Training
Although the documentation is prepared to assist users throughout the system’s life cycle, it's
important to train users with the new system. Normally, the team uses the documentation
prepared to assist them in training sessions. Converting from old to new system necessitates that
the system users be trained and provided with documentation that guide them through the new
system. Training can be one to one; however training a group of people is preferred. Group
training can reduce the time and cost spent to conduct the training, and also encourage the group
participants and feedback towards the system. There are few things that need to be considered
during the training session. The content of the training session should be an introduction to the
system, and system manual.

C. System quality, Software quality assurance (Formal Technical Review,

Walkthrough, Inspections)
System 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, etc. for software products, "fitness of purpose" is not a wholly
satisfactory definition of quality.
 BIT III: PU Compiled By: GIRIJA 9

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

● Software Quality Management System contains the methods that are used by the
authorities to develop products having the desired quality.
● Quality system management involves the responsibility of ensuring that the processes,
products and services involved in your business are meeting or exceeding your standards.

Quality management process includes all of the following:

o Quality planning: Quality planning involves examining where your quality is now,
where you would like it to be, what standards you want to you, how you will improve
quality and how you will measure your progress.

o Quality policies: Your quality policies are written into a document that covers how
you handle quality at every level of manufacturing, packaging and marketing. This
includes how you handle customer quality concerns, your warranties and customer
care procedures.

o Quality assurance: Quality assurance involves inspiring confidence that your quality
policies and standards will be upheld internally and externally.

o Quality control: Quality control involves inspection and oversight that backs up your
quality policies and assurance. This could mean inspecting products for defects or
 BIT III: PU Compiled By: GIRIJA 10

testing them for the presence of harmful substances. Money spent on quality control
can decrease as an effective QMS is implemented on every level of your company.

o Quality improvement: Quality improvement is the process of continually refining your

quality management process so that it is more and more efficient and cost-effective.
Continued quality improvement can edge you ahead of the competition to help you
gain market share and grow the bottom line.

Software Quality Assurance

Software Quality Assurance (SQA) is a process that ensures software products meet specified
requirements and are fit for their intended use. It involves various activities to improve the
quality of software, including formal technical reviews.

SQA Includes:
o A quality management approach
o Effective Software engineering technology (methods and tools)
o Formal technical reviews that are tested throughout the software process
o A multitier testing strategy
o Control of software documentation and the changes made to it.
o A procedure to ensure compliances with software development standards
o Measuring and reporting mechanisms.

Following activities are performed by an independent SQA group:

1. Prepares SQA Plan:
 Develops an SQA plan during project planning, reviewed by stakeholders.
 Governs quality assurance activities for the software engineering team.
 Identifies calculations, audits, reviews, standards, error reporting techniques,
documents, and feedback for the project.
2. Participates in Software Process Description:
 Reviews the software team's selected process for compliance with policies and
standards.
 Ensures alignment with organizational policy, internal standards, and external
standards like ISO-9001.
3. Reviews Engineering Activities for Compliance:
 Identifies, reports, and tracks deviations from the defined software process.
 Verifies corrections have been made to ensure compliance.
 BIT III: PU Compiled By: GIRIJA 11

4. Audits Software Work Products:

 Reviews selected work products, documenting and tracking deviations.
 Verifies corrections have been implemented and reports results periodically to the
project manager.
5. Handles Deviations:
 Ensures deviations in software work and work products are documented.
 Follows a documented procedure for handling deviations in the project method,
process description, standards, or technical work products.
6. Records and Reports Noncompliance:
 Tracks non-compliance items until resolution.
 Records and reports noncompliance to senior management.

Benefits of Software Quality Assurance (SQA):

1. SQA produces 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 a 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.
8. It cuts maintenance costs. Get the release right the first time, and your company can
forget about it and move on to the next big thing. Release a product with chronic issues,
and your business bogs down in a costly, time-consuming, never-ending cycle of repairs.

Formal Technical Review

A formal technical review is a structured process where software components are inspected and
evaluated by a team of experts to identify and address issues related to quality, functionality,
and compliance with standards and requirements.

Objectives of formal technical review (FTR)

 Detect Identification: Identify defects in technical objects by finding and fixing mistakes,
inconsistencies, and deviations.
 Quality Assurance: To ensure high-quality deliverables, and confirm compliance with
project specifications and standards.
 Risk Mitigation: To stop risks from getting worse, proactively identify and manage
possible threats.
 BIT III: PU Compiled By: GIRIJA 12

 Knowledge Sharing: Encourage team members to work together and build a common
knowledge base.
 Consistency and Compliance: Verify that all procedures, coding standards, and policies
are followed.
 Learning and Training: Give team members the chance to improve their abilities
through learning opportunities.

Key Components of a Formal Technical Review

1. Review Objectives:
Clearly defining the objectives of the review is crucial. This includes identifying the specific areas
to be reviewed, such as design, code, documentation, and testing processes.

2. Review Team:
The review team should consist of experts in the relevant areas of the software being reviewed.
This team is responsible for conducting the review, identifying issues, and suggesting
improvements.

3. Review Process:
The review process involves a structured approach to examining the software components. This
can include reviewing design documents, code, and test plans, as well as conducting
walkthroughs or presentations to gain a deeper understanding of the software.

4. Review Tools and Techniques:

Various tools and techniques can be used during the review process, such as static code analysis
tools, dynamic analysis tools, and code review tools. Techniques may include inspection,
walkthroughs, and discussions.

5. Review Findings and Report:

The review team documents their findings, including identified issues, suggestions for
improvement, and any deviations from standards or requirements. A comprehensive review
report is prepared, which outlines the review's objectives, process, findings, and
recommendations for addressing the identified issues.

6. Action Items and Follow-Up:

Based on the review findings, action items are identified for addressing the issues. These may
include changes to the design, code, or documentation, as well as additional testing or validation
activities. A follow-up process is established to monitor the implementation of the
recommendations and ensure that the issues have been adequately addressed.
 BIT III: PU Compiled By: GIRIJA 13

Benefits of Formal Technical Review

Improves Quality:
By identifying and addressing issues early in the development process, formal technical reviews
help improve the overall quality of the software.
Enhances Understanding:
The review process enhances the team's understanding of the software, leading to better
design and implementation decisions.

Ensures Compliance:
Formal technical reviews help ensure that the software complies with relevant standards,
regulations, and requirements.

Facilitates Communication:
The review process facilitates communication among team members, stakeholders, and
experts, leading to a better understanding of the software's requirements and design.

Reduces Risks:
By identifying and addressing potential issues early, formal technical reviews help reduce risks
associated with software quality and performance.

Implementing a Formal Technical Review

Implementing a formal technical review involves several steps:
1. Planning: Define the objectives, scope, and schedule of the review. Identify the review team
and establish the review process.
2. Preparation: Ensure that all necessary documentation, code, and test plans are prepared and
available for review.
3. Execution: Conduct the review according to the established process, using the appropriate
tools and techniques.
4. Reporting: Prepare a comprehensive review report based on the findings and
recommendations.
5. Action and Follow-Up: Implement the recommended actions and establish a follow-up
process to monitor the implementation and ensure that the issues have been adequately
addressed.
 BIT III: PU Compiled By: GIRIJA 14

Let's consider a simple example of a software project for a basic calculator application. This
example will illustrate how a formal technical review might be conducted for this project.
Project Overview
Project Name: Simple Calculator
Objective: Develop a basic calculator application that can perform addition, subtraction,
multiplication, and division.
Scope: The application will be developed using Python and will have a simple graphical user
interface (GUI) for user input.

Formal Technical Review Process

1. Review Objectives
● Objective: To review the design, code, and documentation of the Simple Calculator
application to ensure it meets the specified requirements and follows best practices.
● Scope: The review will cover the application's design documents, source code, and test
plans.

2. Review Team
● Members:
○ Software Architect: Responsible for reviewing the overall design and architecture
of the application.
○ Senior Developer: Focuses on the code quality, adherence to coding standards,
and potential performance issues.
○ Quality Assurance Engineer: Ensures the application meets the specified
requirements and has adequate test coverage.

3. Review Process
● Design Document Review: The team reviews the application's design documents to
ensure they are clear, complete, and aligned with the project objectives.
● Code Review: The team conducts a thorough review of the source code, focusing on
code quality, readability, and adherence to coding standards.
● Test Plan Review: The team reviews the test plans to ensure they are comprehensive
and cover all aspects of the application's functionality.

4. Review Tools and Techniques

● Code Review Tools: Tools like SonarQube or PyLint are used to automatically analyze the
code for potential issues.
● Static Analysis: Static code analysis tools are used to identify potential bugs, security
vulnerabilities, and code quality issues.
 BIT III: PU Compiled By: GIRIJA 15

5. Review Findings and Report

● Findings:
○ The design document is clear but lacks a detailed explanation of the error
handling mechanism.
○ The code is generally well-written but contains a few instances of magic
numbers.
○ The test plan covers all specified functionalities but lacks tests for edge cases.
● Recommendations:
○ Improve the design document by adding a detailed explanation of the error
handling mechanism.
○ Refactor the code to replace magic numbers with named constants.
○ Enhance the test plan by adding tests for edge cases.

6. Action Items and Follow-Up

● Action Items:
○ Update the design document with a detailed explanation of the error handling
mechanism.
○ Refactor the code to replace magic numbers with named constants.
○ Add edge case tests to the test plan.
● Follow-Up:
○ Schedule a follow-up review after the recommended actions have been
implemented to ensure that the issues have been adequately addressed.

Walkthrough
A software quality assurance (SQA) walkthrough is a process used to review and ensure the
quality of software. It involves a group of individuals, including developers, testers, and other
stakeholders, walking through various aspects of the software to identify issues, ensure
compliance with standards, and improve overall quality. Here's a step-by-step guide for a typical
SQA walkthrough:
Define Objectives:
Clearly define the objectives of the walkthrough. This could include finding defects, ensuring
compliance with requirements, reviewing coding standards, or verifying adherence to design
specifications.

Select Participants:
Assemble a diverse group of participants, including developers, testers, business analysts, and
other relevant stakeholders. Having a mix of perspectives can uncover different types of issues.
 BIT III: PU Compiled By: GIRIJA 16

Preparation:
Ensure that all participants are familiar with the software or system under review. Provide them
with any necessary documentation, such as requirements, design specifications, and test plans.

Schedule and Notify:

Schedule the walkthrough in advance and notify all participants of the date, time, and location.
Ensure that everyone has enough time to prepare for the session.

Start with Overview:

Begin the walkthrough with an overview of the software's purpose, features, and functionality.
This helps participants understand the context of the review.

Step-by-Step Examination:
Walk through the software step by step, focusing on different aspects like code, design,
documentation, and test cases. Discuss each component thoroughly, and encourage participants
to ask questions and provide feedback.

Check for Compliance:

Ensure that the software complies with established standards, coding guidelines, and best
practices. This could include checking for proper naming conventions, coding styles, and
documentation standards.

Verify Requirements:
Verify that the software meets the specified requirements. Cross-reference the implemented
features with the documented requirements and check for any inconsistencies.

Identify Defects:
Actively search for defects, bugs, or issues within the software. Encourage participants to share
their observations and concerns. Document all identified defects.

Documentation Review:
Review the documentation associated with the software, such as user manuals, technical
documentation, and release notes. Ensure that the documentation is accurate and up-to-date.

Collaborative Discussion:
Facilitate open and constructive discussions among participants. Encourage collaboration and the
exchange of ideas to address issues and improve the overall quality of the software.
 BIT III: PU Compiled By: GIRIJA 17

Action Items:
Document action items, including identified defects, areas for improvement, and any necessary
follow-up tasks. Assign responsibilities for addressing these items.

Feedback and Improvements:

Gather feedback from participants on the walkthrough process itself. Use this input to
continuously improve the SQA walkthrough process for future software releases.

Follow-Up:
Schedule follow-up meetings or activities to track the resolution of identified issues and ensure
that improvements are implemented.

Advantages and Objectives of Walkthrough:

Following are some of the objectives of the walkthrough.
 To detect defects in developed software products.
 To fully understand and learn the development of software products.
 To properly explain and discuss the information present in the document.
 To verify the validity of the proposed system.
 To give suggestions and report them appropriately with new solutions and ideas.
 To provide an early “proof of concept”.

Difference between walkthroughs and Formal Technical Reviews:

Aspect Walkthroughs Formal Technical Reviews

Formality Informal Formal

Participants include Specific roles like moderator,

Roles and
developers, testers, and presenter, and reviewers with defined
Responsibilities
stakeholders. responsibilities.
 BIT III: PU Compiled By: GIRIJA 18

Emphasis on understanding, Focus on finding defects, ensuring

Purpose knowledge transfer, and issue compliance, and verifying
identification. requirements.

Comprehensive documentation,
Minimal documentation, with including a formal review report
Documentation
a focus on discussion. detailing the process and identified
issues.

Can occur iteratively during Typically planned at specific milestones

Timing
the development process. in the development lifecycle.

More flexible in terms of Follows a structured and predefined

Flexibility
timing and participants. process.

Emphasis Learning and collaboration. Quality assurance and compliance.

Inspections
Software inspections are a formalized process for reviewing and assessing work products such as
requirements, design documents, code, and test plans. The primary goal of inspections is to
identify and correct defects early in the software development process, improving overall
product quality. The process involves a group of individuals who systematically examine the work
product with the aim of finding issues and ensuring that it adheres to established standards and
specifications.

Objectives of Inspection:
Following are some of the objectives of Inspection.
 To efficiently improve the quality of a software or product.
 To create common understanding between individuals who are been involved in the
inspection.
 To remove defects and errors as early as possible.
 BIT III: PU Compiled By: GIRIJA 19

 To learn and improve from defects which are been found during inspection.
 Helping author to improve and increase the quality of product which is been developed.

Here are the key steps involved in a typical software inspection process:
 Planning:
o Define the objectives and scope of the inspection.
o Identify the participants, including moderators, reviewers, and authors. Schedule
the inspection, considering the availability of team members.

 Overview Meeting:
o Conduct a meeting to provide an overview of the work product being inspected.
o Discuss the purpose, goals, and expected outcomes of the inspection.
o Clarify any questions or concerns team members may have.

 Preparation:
o Distribute the work product to be inspected well in advance.
o Ask participants to individually review the work product and note potential
issues.
o Encourage participants to prepare for the inspection meeting.

 Inspection Meeting:
o Bring participants together for a collaborative inspection meeting.
o Follow a structured agenda, with the moderator guiding the discussion.
o Review the work product section by section, allowing participants to raise
concerns or suggestions.

 Defect Recording:
o Document all identified defects, issues, and concerns during the inspection.
o Classify the severity of each defect and note potential solutions or
recommendations.

 Follow-Up:
o Share the recorded defects with the author of the work product.
o Collaborate on resolutions for identified issues.
o Update the work product based on the feedback and resolutions.
 BIT III: PU Compiled By: GIRIJA 20

 Re-Inspection (Optional):
o In some cases, a re-inspection may be conducted to verify that identified issues
have been addressed.
o The re-inspection focuses specifically on the previously identified defects.

 Documentation:
o Maintain detailed records of the inspection process, including meeting minutes,
identified defects, resolutions, and any follow-up actions.

 Feedback and Improvement:

o Gather feedback from participants regarding the inspection process itself.
o Use insights from the inspection to improve future inspections and overall
development processes.

 Metrics and Reporting:

o Track metrics related to the inspection, such as the number and severity of
defects found.
o Generate reports to summarize inspection outcomes and improvements.

Difference between Inspection and Walkthroughs.

Aspect Inspections Walkthroughs

Formal process with predefined Generally less formal and more

Formality
roles and checklists. collaborative.

Specific roles (moderator, Participants include developers,

Roles and
author, reviewer) with defined testers, and stakeholders without
Responsibilities
responsibilities. predefined roles.

Primary goal is defect detection Emphasis on knowledge transfer,

Objectives
and prevention. learning, and understanding.
 BIT III: PU Compiled By: GIRIJA 21

Follows a predefined and

More flexible and may not follow a
Process formalized process with specific
strict process.
steps.

Comprehensive documentation,
Documentation may be less formal,
Documentation including a formal inspection
focusing more on discussion.
report.

Typically planned at specific

More flexible timing, adaptable to
Timing milestones in the development
the team's needs.
process.

Defect detection and prevention Knowledge transfer, understanding,

Focus
are the main focus. and open discussion are primary.

D. System maintenance, types of maintenance, and process of system

maintenance
The results obtained from the evaluation process help the organization to determine whether
its information systems are effective and efficient or otherwise. The process of monitoring,
evaluating, and modifying existing information systems to make required or desirable
improvements may be termed as System Maintenance.
Thus, maintenance changes the existing system, enhancement adds features to the existing
system, and development replaces the existing system. It is an important part of system
development that includes the activities which corrects errors in system design and
implementation, updates the documents, and tests the data.
 BIT III: PU Compiled By: GIRIJA 22

Several Key Aspects of Software Maintenance

1. Bug Fixing: The process of finding and fixing errors and problems in the software.
2. Enhancements: The process of adding new features or improving existing features to
meet the evolving needs of the users.
3. Performance Optimization: The process of improving the speed, efficiency, and
reliability of the software.
4. Porting and Migration: The process of adapting the software to run on new hardware or
software platforms.
5. Re-Engineering: The process of improving the design and architecture of the software to
make it more maintainable and scalable.
6. Documentation: The process of creating, updating, and maintaining the documentation
for the software, including user manuals, technical specifications, and design documents.

Need for Maintenance

Software Maintenance must be performed in order to:
 Correct faults.

 Improve the design.

 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system features, and
telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.
 Requirement of user changes.
 Run the code fast

Types of maintenance
There are 4 types of sofware maintenance:
i. Adaptive
ii. Corrective
iii. Preventive
iv. Perfective
 BIT III: PU Compiled By: GIRIJA 23

Corrective Maintenance:

 Corrective maintenance is mainly performed in order to fix the error in the operational
system. Corrective maintenance starts with identification of errors and ends with
correction of errors in an operational system.
 Best approach to corrective maintenance is scaled-down version of the SDLC. In which
investigation, analysis, design and testing is performed before system implementation.
 During corrective maintenance any new updates are first checked for in test
environment and then updated in the operational system.
Examples:

 Suppose a system is generating errors during authenticating login of employee whose

already are already been verified such errors are corrected during corrective
maintenance.
 An error in a program that results in wrong output is debugged and corrected under
corrective maintenance.

Adaptive maintenance:

 Adaptive maintenance is mainly performed to add new functions or features to the

operational system which enhances its operability.
 Main scenario which leads to adaptive maintenance are changes in the procedure, goals
and security needs of the
Examples:

 Adding new voice-based search features in the operational system.

 Adding new user interface to operational system.
 BIT III: PU Compiled By: GIRIJA 24

Perfective maintenance:
• Perfective maintenance is mainly perfomed to improve the efficiency, reliability and
maintainability of the operational system.
• Perfective maintenance is performed depending on the requests from the users. When
users generate any issues regarding performance of the system, requests should be
evaluated to determine if perfective maintenance can help in resolving the issue or not.
• Software engineering is used by analysts to during perfective maintenance to identify
potential quality and performance improvements.
Examples:

 Conversion of command line system to graphical user interface.

 Upgrading wireless network.

Preventive maintenance:

 The activity done to prevent system failure by bringing changes to software for the
system safe future and easy maintenance comes under preventive maintenance.
 Preventive maintenance is mainly performed so that future failure or faults related to
system functionality can be avoided or reduced.
 It helps is providing satisfaction to the user, decrease in downtime and reduced total cost
of ownership (TCO) and directly affect the success or the organization.
Examples:

 Installing new antivirus software.

 Implement regular defragmentation process.

Software Maintenance Models

 Quick-fix Model
The quick-fix model is an ad hoc approach used for maintaining the software system. The
objective of this model is to identify the problem and then fix it as quickly as possible.
The advantage is that it performs its work quickly and at a low cost. This model is an
approach to modify the software code with little consideration for its impact on the
overall structure of the software system.
 BIT III: PU Compiled By: GIRIJA 25

Objectives of Quick-fix Model:

1. Resolving Serious Issues: The quick-fix model might try to quickly find and address
serious problems or defects that are seriously impairing system functionality or the user
experience.
2. Reducing Unavailable Time: The quick-fix model aims to minimize downtime by offering
prompt solutions to restart a system that is experiencing downtime as a result of a major
issue.
3. Keeping Data Safe: When there is a chance of data loss or corruption, the quick-fix model
seeks to put temporary fixes in place so that problems can be avoided or resolved.
4. Reducing High-Impact Problems: One of the main objectives of the quick-fix approach is
to identify and mitigate issues that have a significant impact on revenue, user
satisfaction or other vital business factors.

Iterative Enhancement Model

The iterative enhancement model, which was originally proposed as a process model, can
be easily adapted for maintaining a software system. It considers that the changes made to
the software system are iterative in nature. The iterative enhancement model comprises
three stages, namely, analysis of software system, classification of requested modifications,
and implementation of requested modifications.
 BIT III: PU Compiled By: GIRIJA 26

In the analysis stage, the requirements are analyzed to begin the software maintenance
process. After analysis, the requested modifications are classified according to the
complexity, technical issues, and identification of modules that will be affected. At the end,
the software is modified to implement the modification request. At each stage, the
documentation is updated to accommodate changes of requirements analysis, design,
coding, and testing phases.

Reuse-oriented Model
 The reuse-oriented model assumes that the existing program components can be reused
to perform maintenance.
 Reuse Oriented Model (ROM), also known as reuse-oriented development (ROD), it can
be steps of the software development for specific duration in which software is
redesigned through creating a sequence of prototypes known as models, every system is
derived from the previous one with constant series of defined rules.
 BIT III: PU Compiled By: GIRIJA 27

It consists of the following steps.

■ Identifying the components of the old system which can be reused
■ Understanding these components
■ Modifying the old system components so that they can be used in the new system
■ Integrating the modified components into the new system.

E. System Testing
System testing is a type of software testing that evaluates the overall functionality and
performance of a complete and fully integrated software solution. It tests if the system meets
the specified requirements and if it is suitable for delivery to the end-users. This type of testing
is performed after the integration testing and before the acceptance testing.

The software is tested at different levels. Initially, the individual units are tested arid once they
are tested, they are integrated and checked for interfaces established between them. After this,
the entire software is tested to ensure that the output produced is according to user
requirements. There are four levels of software testing, namely, unit testing, integration testing,
system testing, and acceptance testing.

Principles of Testing
 All the tests should meet the customer’s requirements.
 To make our software testing should be performed by a third party.
 Exhaustive testing is not possible. As we need the optimal amount of testing based on the
risk assessment of the application.
 All the tests to be conducted should be planned before implementing it
 It follows the Pareto rule (80/20 rule) which states that 80% of errors come from 20% of
program components.
 Start testing with small parts and extend it to large parts.

Advantages of Software Testing

 Improved software quality and reliability.
 Early identification and fixing of defects.
 Improved customer satisfaction.
 Increased stakeholder confidence.
 Reduced maintenance costs.
 BIT III: PU Compiled By: GIRIJA 28

Types of Software Testing

Now, we are going to understand the various types of software testing, which can be used at the
time of the Software Development Life Cycle.

Fig: Types of Testing

Classification of Manual Testing

In software testing, manual testing can be further classified into three different types of
testing, which are as follows:

o White Box Testing

o Black Box Testing
o Grey Box Testing
 BIT III: PU Compiled By: GIRIJA 29

White Box Testing

In white-box testing, the developer will inspect every line of code before handing it over to the
testing team or the concerned test engineers. This type of software testing evaluates and verifies the
‘source code’, or the internal workings of a software system, such as its code and infrastructure. Some of
the software code of the following are tested by this method –
1. Internal security holes
2. Poorly structures paths
3. Specific input flow
4. Expected output
5. Conditional loop functionality

Black Box Testing

Also known as Behavioral Testing, Black box testing is a software testing technique where the
application is tested without the knowledge of its internal code structure. The name only depicts
that the software program is not perceived through the tester’s eyes. This type of testing
commonly focuses on only the input and output of the software system.
Some of the errors tested by this method are –
1. Function errors
2. Interfacing errors
3. Database errors
4. Performance errors
5. Initialization errors

Black Box Testing Techniques include:

 Information Gathering: Extracts application knowledge from external sources using
Search Engine Discovery/Reconnaissance and Web App Fingerprint.
 Configuration and Deploy Management Testing: Assesses weaknesses in application
configuration management and hunts for sensitive information in backups and old files.
 Data Validation Testing: Utilizes techniques like Reflected Cross-Site Scripting, Stored
Cross-site Scripting, and SQL Injections to check the validity and completeness of provided
data.
 Cryptography: Inspects unencrypted channels, weak SSL/TLS ciphers, and the protection
of the application's transport layer for sensitive information transmission.
 BIT III: PU Compiled By: GIRIJA 30

Gray Box Testing

Grey Box Testing is a combination of Black Box Testing and White Box Testing techniques. In Black
Box, the tester is not aware of the internal workings of the application being tested, while White
Box Testing allows the tester to have that knowledge freely. Grey Box Testing grants a partial
information of the internal structure to the tester, including the access to internal data and
design for the purpose of creating test cases.

Grey Box Testing Techniques include:

1. Identity Management Testing: Evaluates Role Definitions, User Registration Process,
and Account Provisioning Process for vulnerabilities.
2. Authentication Testing: Examines components like Default Credentials, Weak Lock Out
Mechanism, Bypass Authentication Schema, and encrypted credential transport.
3. Authorization Testing: Tests Authorization Mechanism through Directory Transversal
File Include, Bypass Authorization Schema, and Privilege Escalation.
4. Session Management Testing: Analyzes Cookie Attributes, Session Fixation, and Session
Hijacking.
5. Input Validation Testing: Highlights vulnerabilities through Injection attacks like SQL
Injection, XML Injection, SSI Injection, and Cross-site Scripting attacks.

Differences between Black Box Testing vs White Box Testing:

Black Box Testing White Box Testing

It is a way of software testing in which the It is a way of testing the software in which the
internal structure or the program or the tester has knowledge about the internal
code is hidden and nothing is known about structure or the code or the program of the
it. software.
 BIT III: PU Compiled By: GIRIJA 31

Black Box Testing White Box Testing

Implementation of code is not needed for Code implementation is necessary for white
black box testing. box testing.

It is mostly done by software testers. It is mostly done by software developers.

No knowledge of implementation is
Knowledge of implementation is required.
needed.

It can be referred to as outer or external

It is the inner or the internal software testing.
software testing.

It is a functional test of the software. It is a structural test of the software.

It is mandatory to have knowledge of

No knowledge of programming is required.
programming.

It is the behavior testing of the software. It is the logic testing of the software.

It is applicable to the higher levels of testing It is generally applicable to the lower levels of
of software. software testing.

It is also called closed testing. It is also called as clear box testing.

It is least time consuming. It is most time consuming.

It is not suitable or preferred for algorithm

It is suitable for algorithm testing.
testing.

Can be done by trial and error ways and Data domains along with inner or internal
methods. boundaries can be better tested.

Example: Search something on google by

Example: By input to check and verify loops
using keywords
 BIT III: PU Compiled By: GIRIJA 32

Functional Software Testing

Functional software testing type’s help testers validate that the features of the software being
developed are working as expected using the following methods.
1. Unit Testing
 Unit testing is one of the core functional testing types that provides the foundation for
verifying software behavior.
 To elaborate, unit testing focuses on testing the functionality of individual units or
components of code in isolation to verify each part operates correctly on its own.
 Compared to other types of testing, the scope of unit tests is quite small and focuses
mostly on validating things like
o Correctness of a single function or method
o Individual classes meet the requirements
o Logic within a specific module

Developers usually do unit testing by writing various test cases to test their code. It helps them
catch bugs early during coding before issues can multiply, saving the time and effort of dedicated
software testers.
Example:
Scenario: Testing an “Email Validation” feature for a website’s sign-up page.
 Input: Giving different email addresses where valid emails are accepted and invalid ones
are rejected.
 Execution: Run the feature with each email address.
 Verification: Check if the valid emails are accepted and failed ones are rejected.
Purpose: This example demonstrates integration testing by focusing on how different system
components (the e-commerce platform and the payment gateway) work together.

2. Integration Testing
 Unlike unit testing, integration testing helps testers determine whether different modules
or services work together harmoniously as intended.
 That means after developers have conducted and verified that individual units are
working properly, software testers combine those units and perform integration tests to
test them as a group.
 Specifically, integration testing helps check if the interface connections between units are
working and verify that the integrated system meets the requirements.
 This process helps to confirm that the units tested by developers independently are
operating together when integrated.
 BIT III: PU Compiled By: GIRIJA 33

Example:
Scenario: Testing the integration of an online payment gateway of an e-commerce website.
 Input: Adding products to the cart and making the payment through the payment
gateway.
 Execution: Perform a complete transaction from selecting a product to completing
payment.
 Verification: Ensure that the e-commerce platform correctly communicates with the
payment gateway and the transaction is processed smoothly without any issues.

3. System Testing
 System testing, as the name suggests, basically helps to evaluate the entire system and
checks that it meets the overall functional requirements of the software application.
 To verify this, this software testing method focuses on end-to-end business processes and
workflows to test and confirm that the system is functioning as expected and intended.
 To perform a system test, software testers need to perform the following:
o Testing system functionality using actual production-like data
o End-to-end testing of transactions and data flows
o Testing of reporting features and data validation
o Testing integrations with external systems/interfaces
o Testing system performance under load close to production
o Security testing at a system level
After performing these tests, system testing finally gives testers the confidence that the overall
solution will function as needed when it is finally deployed in the live environment.

Example:
Scenario: Testing the complete functionality of an airline reservation system.
 Input: Execute a series of actions – searching & selecting a flight, entering passenger
details, making a payment, and receiving a booking confirmation.
 Execution: Run through the entire process from start to finish, simulating a real user’s
experience.
 Verification: Check that the flight search, booking process, payment gateway, and
confirmation system work together seamlessly and the entire process is completed
without errors.
Purpose: This example illustrates system testing by focusing on the entire airline reservation
system. It assesses the system’s overall functionality, ensuring it meets its intended
requirements and specifications.
 BIT III: PU Compiled By: GIRIJA 34

4. Acceptance Testing
 Acceptance testing helps software testers confirm that the software meets all agreed
business and user requirements and is acceptable for delivery.
 This is done by testing the software application with the following three acceptance
testing sub-types:
a. Alpha Testing
Alpha testing is a type of acceptance testing performed by the team in an
organization to find as many defects as possible before releasing software to
customers

b. Beta Testing
Beta Testing is a type of software testing which is carried out by the
clients/customers. It is performed in the Real Environment before releasing
the product to the market for the actual end-users.

c. Operational acceptance testing (OAT)

Operational acceptance testing of the system is performed by operations or
system administration staff in the production environment. The purpose of
operational acceptance testing is to make sure that the system administrators can
keep the system working properly for the users in a real-time environment.

Unlike other functional testing types, acceptance testing is usually conducted in a production-like
environment to thoroughly examine whether the software meets all validation criteria and is
ready for go-live.

Example:
Scenario: Testing a new corporate project management software.
 Input: Key users from the company, such as project managers and team members, use
the software to manage a mock project. This includes creating projects, assigning tasks,
tracking progress, and generating reports.
 Execution: The users perform all the functions they typically use daily, assessing the
software’s usability, features, and performance.
 Verification: Gather feedback from these users to determine if the software meets their
needs and expectations and if it’s ready for deployment in the work environment.
Purpose: This example demonstrates acceptance testing by focusing on how the end-users
interact with the software and whether it fulfills their requirements and expectations.
 BIT III: PU Compiled By: GIRIJA 35

How to Write Test Cases

Steps to Create Test Cases in Manual Testing
Let’s create a Test Case for the scenario: Check Login Functionality:
Step 1) A simple test case to explain the scenario would be
Test Case Test Case Description
1 Check response when valid email and password is entered

Step 2) Test the Data.

In order to execute the test case, you would need Test Data. Adding it below
Test Case Test Case Description Test Data
1 Check response when valid email and Email: [email protected]
password is entered Password: lNf9^Oti7^2h

Identifying test data can be time-consuming and may sometimes require creating test data
afresh. The reason it needs to be documented.

Step 3) Perform actions.

In order to execute a test case, a tester needs to perform a specific set of actions on the AUT.
This is documented as below:
Test Case Test Case Description Test Steps Test Data
1 Check response when valid 1) Enter Email Address Email: [email protected]
email and password is entered 2) Enter Password Password: lNf9^Oti7^2h
3) Click Sign in

Many times the Test Steps are not simple as above, hence they need documentation. Also, the
author of the test case may leave the organization or go on a vacation or is sick and off duty or is
very busy with other critical tasks. A recently hire may be asked to execute the test case.
Documented steps will help him and also facilitate reviews by other stakeholders.

Step 4) Check behavior of the AUT (Application Under Test).

The goal of test cases in software testing is to check behavior of the AUT for an expected result.
This needs to be documented as below
Test Test Case Description Test Data Expected Result
Case #
1 Check response when valid email Email: [email protected] Login should be
and password is entered Password: lNf9^Oti7^2h successful
 BIT III: PU Compiled By: GIRIJA 36

During test execution time, the tester will check expected results against actual results and
assign a pass or fail status

Test Test Case Test Data Expected Actual Pass/Fail

Case Description Result Result
1 Check response Email: [email protected] Login should Login was Pass
when valid email Password: lNf9^Oti7^2h be successful successful
and password is
entered

Step 5) That apart your test case -may have a field like,
Pre – Condition which specifies things that must be in place before the test can run. For our test
case, a pre-condition would be to have a browser installed to have access to the site under test.
A test case may also include Post – Conditions which specifies anything that applies after the
test case completes. For our test case, a post condition would be time & date of login is stored
in the database