DIRE DAWA UNIVERSITY

INSTITUTE OF TECHNOLOGY
6/11/2022
SCHOOL OF COMPUTING

SOFTWARE QUALITY ASSURANCE PLAN

DDU STUDENT INFORMATION MANAGEMENT
SYSTEM

Misrak Eshetu

Tihtena Firde

Mezgebu Mulu

Instructor: Tesfu. (Ph.D.)

DDU
Table of Contents
1. INTRODUCTION.................................................................................................................................1

1.1. PURPOSE.........................................................................................................................................1

1.2. Scope................................................................................................................................................1

1.3. Reference Document.......................................................................................................................1

1.4. Overview of the Document.............................................................................................................2

Document Overview..............................................................................................................................2

1.5. Definition acronyms, abbreviation................................................................................................3

2. Management...........................................................................................................................................3

2.1. Organization...................................................................................................................................3

2.2. Task and Responsibility...................................................................................................................7

Software Quality Assurance (SQL) Task and Responsibility.............................................................7

3. Documentation.......................................................................................................................................9

4. SQA program requirement.....................................................................................................................9

4.1. Standard and Metrics...................................................................................................................10

4.1.1. Software standard......................................................................................................................10

4.1.2. Software metrics.........................................................................................................................10

4.2. Software Documentation Audit...................................................................................................12

4.3. Requirement Traceability............................................................................................................13

4.4. Software Development Process....................................................................................................14

4.5. Project Reviews..............................................................................................................................15

4.6. Testing and Quality check............................................................................................................15

i
1. INTRODUCTION
1.1. PURPOSE
The purpose of this plan is to define the DDU SIMS Software Quality Assurance (SQA)
organization, SQA tasks and responsibilities; provide reference documents and guidelines to
perform the SQA activities; provide the standards, practices and conventions used in carrying out
SQA activities; and provide the tools, techniques, and methodologies to support SQA activities,
and SQA reporting.

1.2. Scope
This plan establishes the SQA activities performed throughout the life cycle of the DDU SIMS.,
this SQA Plan will show that the SQA function is in place for this project. It will show that the
SQA group has a reporting channel to senior management that is independent of the project
manager, the project’s software engineering group, and software related groups that includes
Software Configuration Management (SCM), System and Software Test, and Logistics.

The goal of the SQA program is to verify that all software and documentation to be delivered
meet all technical requirements. The SQA procedures defined herein shall be used to examine
all deliverable software and documentation to determine compliance with technical and
performance requirements.

1.3. Reference Document

a. SSC San Diego Software Quality Assurance Policy, Version 1.1, October 1997.

b. IEEE/EIA Standard 12207 Series - Standard for Information Technology – Software life cycle
processes, March 1998.

C .IEEE-Std-730-1998, IEEE Standard for Software Quality Assurance Plans, June 1998.

d. IEEE-Std-730.1-1995, IEEE Guide for Software Quality Assurance Planning, December 1995.

E .DDU SIMS Software Development Plan,

f. DDU SIMS Software Configuration Management Plan,

1
g. Software Engineering Process Policy, SPAWARSYSCEN SAN DIEGO INST 5234.1, July
2000.

i. Software Quality Assurance Process, PR-SQA-02.

1.4. Overview of the Document

Document Overview
This document identifies the organizations and procedures to be used to perform activities
related to the DDU SIMS SQA program as specified in IEEE Std 730-1998, IEEE Standard for
Software Quality Assurance Plans, reference (c) and IEEE Std 730.1-1995, IEEE Guide for SQA
Planning, reference (d).

1 identifies the system to which this SQA Plan applies; provides an overview of the system and
its software functions; summarizes the purpose and contents of the SQA Plan; and describes the
relationship of the SQA Plan to other management plans and lists all documents referenced in
this SQA Plan.

2 describe each major element of the organization that influences the quality of the software.

3. describes the various SQA tasks and responsibility

4. Describe SQA implementation in different phase

5. Lists the baseline documents produced and maintained by the project.

6. Identifies SQA program requirement standards, metrics, software documentation audit

Requirement Traceability

7. Describe Software Development Process

8. Project Reviews

9. Describes SQA involvement in Testing and Quality Check

2
1.5. Definition acronyms, abbreviation
Software Quality Assurance: is a process that assures that all software engineering processes,
methods, activities, and work items are monitored and comply with the defined standards.

DDU SIMS: Dire Dawa Student Information Management System

SQA: Software Quality Assurance

SCM: Software Configuration Management

IEEE: Institute of Electrical and Electronics Engineers

ISO: International Organization for Standard

2. Management
This section describes each major element of the organization that influences the quality of the
software.

2.1. Organization
The SQA group must have some autonomy in order to practice good software. SQA's
independence is one of its major assets. If the product's quality is jeopardized, this possibility
should be reported immediately above the project's level. While this rarely happens in practice
because almost all problems are dealt correctly at the project level, the SQA group's capacity to
reach above the project level allows it to keep many of these problems at the project level.

3
 Program Management
Sponsor

SQA

Project Management

SCM

Software Software TEST System Test

Development

DDU SIMS Organization

A. Program Management/Line Management (Sponsor) is responsible for the following

items:

1. Establishing a quality program by committing the project to implement the Software

Engineering Process Policy, reference (g), and reference (a).

2. Reviewing and approving the DDU SIMS SQA Plan.

4
3. Resolving and following-up on any quality issues raised by SQA.

4. Identifying an individual or group independent from the project to audit and report on the
project’s SQA function.

5. Identifying the quality factors to be implemented in the system and software.

6. Fill-in additional functional responsibilities.

B. Project Management is responsible for:

1. Implementing the quality program in accordance with references (g) and (a).

2. Identifying the SQA activities to be performed by SQA.

3. Reviewing and approving the DDU SIMS SQA Plan.

4. Identifying and funding an individual or group independent from the project to perform the
SQA functions.

5. Resolving and following-up on any quality issues raised by SQA.

6. Identifying and ensuring the quality factors to be implemented in the system and software.

7. Identifying, developing and maintaining planning documents such as the Program

Management Plan, references (e) and (f), Test Plans, and this SQA Plan.

8. Fill-in additional functional responsibilities.

C. System Engineering is responsible for:

1. Reviewing and commenting on the DDU SIMS SQA Plan.

2. Implementing the quality program in accordance with this SQA Plan.

3. Resolving and following-up on any quality issues raised by SQA related to software
engineering activities.

4. Identifying, implementing, and evaluating the quality factors to be implemented in the system
(software and hardware).

5
5. Implementing the engineering practices, processes, and procedures as defined in reference (e)
and other program/project planning documents.

6. Fill-in additional functional responsibilities.

D. Software Design/Development is responsible for:

1. Reviewing and commenting on the DDU SIMS SQA Plan.

2. Implementing the quality program in accordance with this SQA Plan.

3. Resolving and following-up on any quality issues raised by SQA related to software design
and development.

4. Identifying, implementing, and evaluating the quality factors to be implemented in the

software.

5. Implementing the software design/development practices, processes, and procedures as

defined in reference (e) and other program/project planning documents.

E. Software Test is responsible for:

1. Reviewing and commenting on the DDU SIMS SQA Plan.

2. Implementing the quality program in accordance with this SQA Plan.

3. Resolving and following-up on any quality issues raised by SQA related to software test.

4. Verifying the quality factors are implemented in the system, specifically software.

5. Implementing the software test practices, processes, and procedures as defined in reference (e)
and other program/project planning documents.

F. System Test is responsible for:

1. Reviewing and commenting on the DDU SIMS SQA Plan.

2. Implementing the quality program in accordance with this SQA Plan.

3. Resolving and following-up on any quality issues raised by SQA as related to system test.

6
4. Verifying the quality factors are implemented in the system (software and hardware).

5. Implementing the system test practices, processes, and procedures as defined in reference (e)
and other program/project planning documents.

H. Software Configuration Management (SCM) is responsible for:

1. Reviewing and commenting on the DDU SIMS SQA Plan.

2. Implementing the quality program in accordance with this SQA Plan.

3. Resolving and following-up on any quality issues raised by SQA related to SCM.

4. Ensuring the quality factors are implemented in the software related to SCM.

5. Implementing the SCM practices, processes, and procedures as defined in reference (e) and
other program/project planning documents.

2.2. Task and Responsibility

Software Quality Assurance (SQL) Task and Responsibility
SQA task is performed in relationship to what software development activities are taking place.
One or more SQA tasks can be performed concurrently until a task is completed. A task is
considered completed when the required reports are satisfactorily completed or action items have
been closed and the ultimate responsibility for the quality of the DDU SIMS software and
associated documentation rests with the DDU SIMS Software Project Manager.

SQA Task SQA Responsibility

SQA Plan  Develop/Document SQA Plan

 Review SQA Plan

 Approve SQA Plan

Review Software Products  Review products

Evaluate Software Tools  Evaluate tool

7
Evaluate Software Facilities  Evaluate facilities

Project Planning, Tracking & Oversight  Review plans

(PPT&O) Process
 Evaluate PPT&O Process

System Requirements Analysis Process  Review System requirement

 Evaluate/report System Requirement

Analysis Process

System Design Process  Review Sys Design

 Evaluate/report Sys Design Process

Software Design Process  Review Software Design

 Evaluate/report Software Design Process

Software Implementation & Unit  Code review

Testing Process
 Evaluate/report SW Implementation and
Unit Testing Process

Corrective Action Process  Follow Corrective Action Process

 Evaluate/report Corrective Action Process

Configuration Management Process  Review SCM Plan

 Follow SCM processes

 Evaluate/report CM Process

Software Quality Assurance  Assist SQA audits

 Evaluate/report SQA Audit Process

8
  Resolve Audit Findings

3. Documentation
The documentation that describes and supports the DDU SIMS software or the software
development process shall be created and updated periodically throughout the development
cycle. DDU SIMS have 4 supporting document

Charter:

Software development plan document: The main objective of this SPMP document is to
illustrate the requirements of the project Student information System and is intended to help
organization to maintain and manage its student’s personal data.

Risk management plan document: The “Risk Management Plan will be the communication
tool used by the project teams in planning for risk. At the minimum, the execution of the plan
will make visible risks and their impacts to the project so no one is surprised should the risks
occur. The optimum case, of course, is that, through the execution of the plan, the negative
impact of the risk to the project is reduced or eliminated

Software configuration plan document: this document provides details of how the SIMS team
will manage the control of configuration items being developed under each phase. It defines the
policies and procedures for configuration management (CM) and the infrastructure necessary to
implement them throughout the project.

This version of the Configuration Management Plan is applicable to the Redesign Phase of the
SIMS project. It may be modified prior each of the remaining phases depending on the CM
requirements for the phase. All SIMS team members, while working on the SIMS project, will
adhere to the approach outlined in this document.

4. SQA program requirement

To verify the delivery of a fully conforming, high-quality product, every individual assigned to
the project will participate in quality assurance. Reference (e) defines the procedures by which
the software development staff shall verify the quality of the product during the development

9
process. The remainder of this section describes the procedures used by SQA to verify that the
quality assurance provisions of this SQA Plan and applicable standards, and metrics are met.

4.1. Standard and Metrics

4.1.1. Software standard
There are some set of quality standard applicable for the organization involved in software
development defined standard must be met by the organization involve in software development.
some standard organization responsible for giving standard are

 IEEE: Institute of Electrical and Electronics Engineers

 ISO: International Organization for Standard

 EIA: Electronic Industrial Association

 IEC: International Electro Technical Commission

IEEE and ISO are the most widely use standard for computer science. The IEEE has provided
the standard of computer software for software quality metrics. The ISO has provide the standard
and framework technology, for the evaluation of software qualit

4.1.2. Software metrics

Software metric is a measure of software characteristics that are quantifiable or countable.
Software metrics are important for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.

Within the software development process, there are many metrics that are all related to each
other. To measure the performance, planning work items, productivity of DDU SIMS System we
focus on the listed criteria

Criteria Description

10
Lead time Lead time quantifies how long it takes for ideas to be developed and
delivered as software. Lowering lead time is a way to improve how
responsive software developers are to customers.

Cycle time Cycle time describes how long it takes to change the software system
and implement that change in production.

Team velocity Team velocity measures how many software units a team completes in
an iteration or sprint. This is an internal metric that should not be used
to compare software development teams. The definition of
deliverables changes for individual software development teams over
time and the definitions are different for different teams.

Open/close rates Open/close rates are calculated by tracking production issues reported
in a specific time period. It is important to pay attention to how this
software metric trends.

Production Production metrics attempt to measure how much work is done and
determine the efficiency of software development teams. The software
metrics that use speed as a factor are important to managers who want
software delivered as fast as possible

Active days An active day is a measure of how much time a software developer
contributes code to the software development project. This does not
include planning and administrative tasks. The purpose of this
software metric is to assess the hidden costs of interruptions

Assignment scope Assignment scope is the amount of code that a programmer can
maintain and support in a year. This software metric can be used to
plan how many people are needed to support a software system and
compare teams.

11
Code churn Code churn represents the number of lines of code that were modified,
added or deleted in a specified period of time. If code churn increases,
then it could be a sign that the software development project needs
attention

Security metrics Security metrics reflect a measure of software quality. These metrics
need to be tracked over time to show how software development teams
are developing security responses.

4.2. Software Documentation Audit

The software documentation audit is used to record that the process is being followed correctly
and working effectively, being followed but is not working effectively, or not being followed.
Audit documentation refers to records maintained by auditors for a specific audit assignment.

The software documentation audit is directed to the groups listed below:

a. Senior Management - The results of process audits are used in conjunction with other
project status information to guide senior management attention to identify and mitigate
project risks at the organizational level.

b. SEPG - The SEPG utilizes the process audits results, in conjunction with the results of
audits of other projects, to identify process weaknesses and initiate or enhance process
improvement in specific areas. This data becomes part of the process database so that it
is available for future project analysis and use.

c. Project Manager - The project manager utilizes the report in the ways listed below:

1. To provide insight into whether there is compliance with the development process
and its effectiveness in meeting project goals. Where necessary and appropriate, the
project manager may initiate enforcement activities or initiate change to the
established processes using the approved procedures.

12
 2. To indicate agreement, disagreement, or deferral of recommendations cited in the
Process Audit Report. Should the Project Manager indicate disagreement with the
recommendations recorded on the Process Audit Report, the final disposition of
report recommendations is made by the appropriate Project Sponsor as described in
Section

4.3. Requirement Traceability

Requirement Traceability is a document that maps and traces user requirement with test cases. It
captures all requirements proposed by the client and requirement traceability in a single
document, delivered at the conclusion of the Software development life cycle. The main purpose
of Requirement Traceability Matrix is to validate that all requirements are checked via test cases
such that no functionality is unchecked during Software testing. Functional requirement of DDU
SIMS are the following

 register student information

 Add and drop course ,Identifying pass and fail students

 Register department and course

 Generate certificate for graduate students

 Generate unique identification card

 Generate grade report and slip report

 view dormitory placement

 online grade report access

 online register for senior student

 Grade submission

13
4.4. Software Development Process
The DDU SIMS allow to store all the details of the students including their background
information, educational qualifications, personal details, and all the information related to them.
It also supports: handling inquiries from prospective students, handling the student details,
maintaining the student marks details, generating slip reports and generating ID card. So all the
information about a student will be available in a few seconds. Overall, it’ll make Student
Information Management an easier job for the administrator and the student of organization.to
turn an idea for DDU SIMS software product into an actual product we should follow
comprehensive set of rules, practices and steps which is called software development process or
software development life cycle. The activity that involve during our software development
listed below

Software Development Activities

Software Development Activity

Project Planning and Oversight

Software Development Environment

System Requirements Analysis

System Design

Software Requirements Analysis

Software Design

Software Implementation and Unit Testing

Unit Integration and Testing

CI Qualification Testing

14
 CI/Hardware Configuration Item (HWCI)
Integration and Testing

System Qualification Testing

Software Use Preparation

Software Transition Preparation

Life Cycle Maintenance

4.5. Project Reviews

The project intends to develop an automated Student Information Management System that
facilitates the various activities taking place at Dire Dawa University registrar office. The system
will be a dynamic web application. The web application facilitates online registration system,
dormitory placement and general student information. Furthermore that the web application of
the system helps to generate reports, certificate, ID and help students to be registered online,
view grade and dormitory placement.

Generally, the system will reduce cost, reduce man power, avoid conflict between students and
teacher, avoid data loss because of improper data storage and reduce redundancy of data.

4.6. Testing and Quality check

DDU SIMS testing activity includes unit level testing, integration testing, System testing and
client feedback. SQA shall audit the testing activities and shall verify that the software and test
documentation is subject to configuration management control. SQA shall witness the tests and
verify that test results are recorded and evaluated. SQA shall coordinate the maintenance of
Problem/Change Report.

15
Unit testing

Unit testing deals with testing a unit as a whole. It is also referred to as function or module
testing because it would test the interaction of many functions but confine the test within one
unit.

The primary goal of unit testing is to take the smallest piece of testable software in the
application, isolate it from the remainder of the code, and determine whether it behaves exactly
as you expect. Each unit is tested separately before integrating them into modules to test the
interfaces between modules. Unit testing has proven its value in that a large percentage of defects
are identified during its use.

Integration Testing

Integration testing is the activity of software testing in which individual software modules are
combined and tested as a group. It occurs after unit testing and before acceptance testing.

Integration testing is a logical extension of unit testing. In its simplest form, two units that have
already been tested are combined into a component and the interface between them is tested.

This type of testing will take place on integration phase of our model. The objective of this
testing is to build a working version of DDU SIMS system putting the module together in
incremental manner and ensuring that the additional modules work as expected without
disturbing the functionality of the module already put together.

System Testing

The objective of DDU SIMS system level testing is to establish whether an application conforms
to the requirement specified by the customer for the acceptance of a system. A system is said to
be accepted if and only if the user of the system is satisfied.

16
Client feedbacks

The system should be test by a group of clients to make Shure it deliver a high value and
satisfaction for clients or customers of DDU SIMS system. Furthermore, we could have to
collect a feedback that initiates as to do better. Verify that test results are recorded and evaluated

This chart shows the process that followed through the phase of testing.

Test Expecting
Testing
configuration result
Testing result
Test plan, Test
procedure, Test
tool, Test
environment

Evaluation

Error

Correction

17
18