Software Development Process Manual
(QMS-ISPL-M-SDP)
|
Version No |
V20 |
Prepared by |
|
|
Date |
30-01-2015 |
Name |
Sai Prasad Koneru |
|
Signature |
|
||
|
Date |
30-01-2015 |
||
|
Copy No |
|
Approved by |
|
|
Issued to |
|
Name |
Thomas
Glass |
|
Signature |
|
||
|
Date |
30-01-2015 |
||
Document Amendment Record
A-
A-
Added,
M- Modified, D- Deleted
|
Sl.No |
Date |
Version No |
Page No |
Change Mode(A/M/D) |
Brief description of change |
|
1 |
|
V01 |
N/A |
A |
Initial Release |
|
2 |
|
V02 |
N/A |
A |
Included
section 3
- Records |
|
3 |
06-06-2012 |
V02 |
N/A |
D |
The Company address information is
removed from the Footer |
|
4 |
30-01-2015 |
V20 |
N/A |
N/A |
Reviewed and base lined |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
2 Software development life cycle phases
2.1 Requirements analysis process
2.4 Coding and unit testing process
2.5 Integration testing process
2.6 Installation and acceptance process
This manual is used as a reference
document for defining the software development life cycle phases related to
quality management system in software development process.
The expected users of this manual
are:
Ø
Project managers.
Ø
Project leaders.
Ø
Programmers.
Ø
Team members.
Ø
Quality assurance team.
Software development process is the
process by which user requirements are elicited and software satisfying these requirements
are designed, coded, tested and delivered to the customer. The software
development process is used when a new application is being developed or a
major enhancement is being done for an existing application. This is applicable
for developing a project/product for market or a project/product for a specific
customer.
1.1 Terms
and definitions
|
Abbreviations/Terms |
Description |
|
ISO |
International
Organization for Standardization |
|
QMS |
Quality
Management System |
|
STP |
Software Test Plan |
|
SRS |
Software Requirements Specification |
|
SSAD |
Structured
System Analysis and Design |
|
UML |
Unified
Modeling Language |
|
OOAD |
Object
Oriented Analysis and Design |
|
UTP |
Unit
Test Plan |
|
DFIN |
Design
Final |
|
PMP |
Project
Management Plan |
|
DDD |
Detail
Design Document |
|
HLD |
High
Level Design |
2
Software development life
cycle phases
This section describes in detail all
the processes or phases of the software development life cycle.
All the processes mentioned in this section may not be
followed sequentially. Processes to be followed and their order are depending
on the type of the software development life cycle model that is chosen from
the software development methodology process manual of the company. The project
manager in consultation with customer, wherever required, will select software
development life cycle model suitable to the project/ product.
The
various processes used are as follows: -
1)
Requirements analysis process.
2)
High level design process.
3)
Detail design process or DFIN
template.
4)
Coding and unit testing process.
5)
Integration testing process.
6)
Installation and acceptance process.
7)
Warranty
2.1
Requirements
analysis process
2.1.1
Process overview
This process is applicable for all
the software projects/products (both internal and external) undertaken by Inooga Solutions. Proposal and contract is the foremost
process in requirements analysis phase that covers the steps right from the
time of customer contract till the contract finalization and sign off. Project
acquisition is the second phase that covers the feasibility studies and the
effort estimation. The activities that are involved under the feasibility study
are:
Ø Requirements analysis phase fully covers the elicitation of
the detailed requirements from the customer or getting the requirements from
the customer, understanding the same, documenting the same in the form of
software requirements specification and the corresponding sign off.
Ø The objective of this process is to establish a common
understanding between Inooga Solutions and the
customer to undertake changes to the requirements. These requirements are
documented in such a way that they become the basis for design, development and
validation activities.
Ø In this phase of the software development life cycle, the
information is gathered from the users of the proposed system to gather their
business and functional requirements including operating environment and
external interfaces (if any).
Ø Requirements analysis can be broadly classified as
functional, performance and operating environment requirements. It also
involves identifying the acceptance criteria that need to be fulfilled for the
customer to accept the software. Requirements management is focused on the
management of changes to requirements during development. This involves:
Ø Documenting the changes.
Ø
Impact analysis of the changes.
Ø
Approval/rejection of the changes.
Ø
Implementation of the changes on all
impacted work products.
Ø
Verification of changes that are
implemented.
2.1.2
Responsibility
Project
manager.
Project
leader.
Analysis
team.
Review team.
2.1.3
Entry criteria
Issue of
approved project initiation note.
Sign off of the approved contract
(optional).
2.1.4
Inputs
Proposal.
Project
initiation note.
2.1.5
Activities
Ø Identifying requirements: - Identification and analysis of all the requirements for the
successful completion and implementation of the project/product.
Ø
Gathering and analyzing requirements
analysis: - Information is gathered from the
users of the proposed system to analyze their business and
functional requirements including operating
environment and external interfaces (if any).
Ø Studying the
functionality of the existing system:-
In many cases, there may not be any documentation available from the
customer, under these cases existing code is studied, limitation of the system
are found along with the type of the users using the system and moving to the
new system.
Ø
Studying
the document supplied by the customers:-
·
The customer supplied documents are studied to understand the
requirements like statement of work, or any architecture document etc.
·
If the user document is provided by the customer then the same
is reviewed in accordance with the company’s review process (QMS-ISPL-M-REV).
Ø
Examining: - The project/product team examines the existing system and
documents it by means of conducting interviews with the users or customers and
keep the records of the minutes of the meeting that is held. The activities
include:
·
Preparation of the checklist for
eliciting user requirements.
·
Identification of the objectives of
having the new system and its success criteria.
· Finding out the constraints of the users/customer.
· Collecting any samples, reports, documents etc from customer that are
preserved for lateral references in the project.
· Involvement in the activities by business development groups
representative as he may be familiar with all the activities and can understand
the preliminary requirements due to earlier interaction with the customers.
Ø
Preparing
and identifying the data dictionary, business entities and rules:-
· The data dictionary is the collection of the commonly used
business terms, entities, and attributes where legacy system exists, it may be
the collection of important data items in the system or the documents that are
used for previous projects and any other new attributes/processes, that are
analyzed and can be incorporated in the future projects.
· The data dictionary along with the business rules and business
entities is used in deriving the ER model in the software requirements phase.
· Based on the customer interview and feasibility study done,
important business entities are identified for deriving logical ER model.
· The key business rules are identified, which are applicable for
the complete system. Some low level validations are derived from this in the
next phase.
· Identifying the use cases and their details which form the basis of
acceptance test plan later.
· Preparation of the context diagram of the system.
Ø
Preparation of software requirements
specification : -
Project/product team based on the user requirements and the solutions, prepares
the software requirements specification. This document covers scope, operational
requirements, security requirements, quality requirements and functionality of
the proposed system, logical model, user interface and limitations.
Ø
Review of software requirements
specification by the company: -
The review team does the review of the software requirements specification as
per the company’s review process (QMS-ISPL-M-REV).
Ø
Review of software requirements
specification by the customer: -
Review of software requirements specification by the customer (if required as
per contract/ agreement).
Ø
Internal approval: - Approval of software requirements specification internally
by Inooga Solutions.
Ø
External approval: - Approval of software requirements specification by the
customer after the acceptance test is done. (if
required as per contract /agreement).
Ø
Submission: - Submission of the software requirements specification to
the customer.
Ø
Requirements traceability matrix: - Preparation of the requirements traceability matrix form.
2.1.6
Exit criteria
Internally
approved SRS or customer sign off.
2.1.7
Outputs
Software
requirements specification (SRS).
Minutes of
the meeting with customer.
Software test plan (STP).
Review records of SRS.
Requirements
traceability matrix report.
2.1.8
Measurements
Effort required in the preparation of draft of SRS.
Effort required in the review of the SRS draft.
Effort required in the rework of SRS.
Effort required in the elimination of defects of SRS.
2.1.9
References
Software test plan(QMS-ISPL-T-STP)
Software
requirements specification checklist(QMS-ISPL-C-SRS
(SUW))
Software
requirements specification template (SSAD based) (QMS-ISPL-T-SRS
(S))
Or
Software
requirements specification template (UML based) (QMS-ISPL-T-SRS
(U))
Or
Software requirements
specification template (WEB based) (QMS-ISPL-T-SRS (W))
2.2.1
Process overview
In this phase, the high level design
document is prepared for each of the modules after identifying the major
modules in the software. Both can be combined into one integrated design phase
if needed, based on the customer requirements.
The functionality and design documents are prepared for each
of the major modules. The interdependencies among the modules are defined and
the integration plan is prepared.
This
phase covers modularization of software, preparation, review and approval of
high level design documentation along with updating software test plan.
2.2.2
Responsibility
Project
leader.
Design team.
Project
manager (for approval of HLD & STP).
Review team (HLD Review).
Customer review (Optional).
2.2.3
Entry criteria
Availability of approved SRS and project management plan.
2.2.4
Inputs
Software requirements specification
(SRS).
High level design (HLD).
2.2.5
Activities
Ø
Preparation of high level design
document: - By identifying the internal and external
interfaces and showing the data and control flow between the components, the
high level design document (HLD) is prepared.
Ø
Review of high level design
document: - The review team does review of the
high level design document as per the company’s review process manual (QMS-ISPL-M-REV).
Ø
Updating software test plan: - For
integrating all the modules, software test plan (STP) is updated.
Ø
Review of STP: - The review team reviews the software test plan (STP) as per
the company’s review process (QMS-ISPL-M-REV).
Ø
Updating requirements traceability
matrix: - The requirements traceability matrix
report is updated at the completion of approval of HLD.
2.2.6
Exit criteria
Reviewed and approved high level design document.
Updated software test plan.
2.2.7
Outputs
High level design document.
Updated software test plan.
Completed review records of high level design document.
Completed review records of software test plan.
Updated requirements traceability
matrix report.
2.2.8
Measurements
Effort required in the preparation of draft of high level
design
Effort required in the preparation of integration test plan.
Effort required in the elimination of the defects of high
level design.
Effort required in the elimination of the defects of
integration test plan.
2.2.9
References
Requirement
traceability matrix form (QMS-ISPL-F-RTM).
High
level design template (QMS-ISPL-T-HLD).
Software
test plan template (QMS-ISPL-T-STP).
High
level design checklist (QMS-ISPL-C-HLD).
Software
test plan checklist (QMS-ISPL-C-STP).
Review record (QMS-ISPL-R-REV).
2.3.1
Process overview
In this phase, each module is
segregated into simple units and design specifications are prepared for each unit.
Design is prepared for the logic of every code. Unit test plan and test cases
are prepared for each of these units.
Depending on the customer’s
specified design methodology one of the following templates can be used for
designing by Inooga Solutions.
The detail design phases are:
Ø Identifying common routines and programs.
Ø Data migration programs.
Ø Development of tools and utilities.
Ø Preparation of pseudo code.
Ø Identification and implementation of reusable codes.
2.3.2
Responsibility
Project leader.
Design team.
Project manager.
Review team.
2.3.3
Entry criteria
Availability of approved software
requirements specification document.
Availability of approved high level design document.
2.3.4
Inputs
High level design document.
Detail design template
(SSAD/OOAD/UML).
DFIN
template.
2.3.5
Activities
Ø
Preparation of detail design: -The detail
design is prepared as per the project / product requirements either by
following SSAD or OOAD or UML methodology.
Ø
Review of detail design: - Review of the detail design is done as per the company’s review
process (QMS-ISPL-M-REV) by
the review team and any discrepancies if found are eliminated.
Ø
Preparation and review of DFIN: - DFIN is a user
specific document. It is prepared and reviewed based on the customer
requirements.
Ø
Preparation of UTP: - Preparation of the unit test plan (UTP) is done by the
project / product team by granulizing the modules into simple units.
Ø
Review of UTP: - Review of the unit test plan is done by the review team as per the company’s review
process (QMS-ISPL-M-REV) and
any discrepancies if found are eliminated.
Ø
Update requirements traceability
matrix: - The requirements traceability
matrix report is updated.
2.3.6
Exit criteria
Completion of review of the detail
design.
2.3.7
Outputs
Detail design document
(OOAD/SSAD/UML).
DFIN
document.
Unit test plan (UTP).
Review records of DDD
(OOAD/SSAD/UML)
Review of DFIN document.
Review records of UTP.
Updated
requirements traceability matrix report.
2.3.8
Measurements
Effort required in the preparation of draft of detail
design.
Effort required in the preparation of unit test plan.
Effort required in the identification of the size of the
code.
Effort required in the review of the code that is written.
Effort required in the identification and elimination of the
defects in the code.
2.3.9
References
DFIN
Template (QMS-ISPL-T-DFN).
Detail design
checklist (QMS-ISPL-C-DDD (OSU)).
Software test plan (QMS-ISPL-T-STP).
Software
test plan checklist (QMS-ISPL-C-STP).
Requirement
traceability matrix form (QMS-ISPL-F-RTM).
Review record (QMS-ISPL-R-REV).
Detail Design
Template (OOAD) (QMS-ISPL-T-DDD (O)).
Detail Design
Template (SSAD) (QMS-ISPL-T-DDD (S)).
Detail Design
Template (UML) (QMS-ISPL-T-DDD (U)).
2.4
Coding
and unit testing process
2.4.1
Process overview
The coding and unit testing process is
used to produce the required software in the specified programming language
during development. The various phases in this process consist of:
Ø Setting up of the development environment.
Ø
Training in customer development
standards.
Ø
Template and sample program
generation.
Ø
Development of common routine/ data
structures.
Ø
Coding/modification.
Ø
In-line documentation.
Ø
Compilation.
Ø Review of code.
Ø
Unit testing.
In this phase the project manager
ensures that suitable development environment in place are reviewed, before
commencement of the other steps they are documented in the project management
plan. The output produced therefore is the source code, executables and test
data. The coders/programmers ensure that the coding standards are followed
strictly. These outputs serve as the first complete representation of the
software project /product.
2.4.2
Responsibility
Project manager.
Project leader.
Team members.
2.4.3
Entry criteria
Availability of approved SRS.
Availability of approved DDD/DFIN.
Availability of approved PMP.
2.4.4
Inputs
Coding specifications.
Detail design documents/DFIN document.
Naming and coding standards/conventions.
Unit test plan.
Utilities and tools.
2.4.5
Activities
Ø Generation of the code: -
The code is constructed strictly following the naming conventions and coding
standards of the software language that is used.
Ø Coding programs: - Each
program is given a unique code for easy identification.
Ø Conducting code reviews or walkthroughs: - Code reviews or walkthroughs are conducted to avoid
inconsistency and also to identify the reusability of the code if any.
Ø Conducting self-testing of the codes: - Adequate comments are provided in the constructed code by
means of self-testing.
Ø Specification of the components:-The components specification document refers to the
technical description of the component developed by the individual. The
component specification focuses only on description of the functionality of all
the components it is prepared during the development of component and likely to
be finished before the component is delivered for testing. The component specification
is documented using component specification master and component specification
sub document templates.
Ø Unit testing of the code: - Each unit code is tested and the ambiguity and
discrepancies if any are removed.
Ø Removal of bugs or defects: -All the defects or bugs that are encountered in the coding
phase are eliminated.
Ø Close reported defects: -
All the reported bugs are removed.
Ø Update requirements traceability matrix: - The requirements traceability matrix report is updated.
2.4.6
Exit Criteria
Successful
execution of updated software test cases.
2.4.7
Outputs
Source code.
Executable code.
Review records of code.
Software test cases.
Software test records.
2.4.8
Measurements
Effort spent on coding.
Effort required in the identification of the size of the
code that is created.
Effort required in the identification and elimination of the
defects in the code.
2.4.9
References
STP
checklist (QMS-ISPL-C-STP).
Component
specification master template (QMS-ISPL-T-CSM).
Component
specification sub document template (QMS-ISPL-T-CSS).
2.5
Integration
testing process
2.5.1
Process overview
Integration is the process of
aggregating components or modules to create larger components these components
are tested individually during unit testing. Once these components perform
satisfactorily, their interface with each other is tested through the process
of integration testing. Some example of integration problems are:
Ø
Configuration/version control.
Ø I/O format, protocol mismatches.
Ø
Conflicting data views/usages.
Ø
Data integrity violation.
Ø
Wrong call order/ wrong parameters.
Ø
Missing/ overlapping functions.
Ø
Resources problems (memory, etc.).
The integration test plan is
prepared as per the software test plan and reviewed before the commencement of
the integration testing. The integration test plan undergoes review by a
designated reviewer identified by the project manager in accordance with the
company’s review process. If the integration test plan is supplied by the
customer the same is reviewed and issues are sent onsite/customer as applicable
for further clarification.
The integration testing is carried
in accordance to the software test plan prepared for the component. The defects
found during the integration testing are recorded using the defect log form.
Defects are tracked to closure before the integrated application is released.
The software product uses a
systematic approach by means of integration of the unit-tested modules. The
phases in the integration of the modules are:
Ø
Integration planning.
Ø
Integration testing.
2.5.2
Responsibility
Team members (Integrated testing).
Team members (Close defects).
QA representative (Testing and
review).
2.5.3
Entry criteria
Availability
of the approved STP.
2.5.4
Inputs
High level design document.
Detail design document.
DFIN document.
Updated software test plan.
2.5.5
Activities
Ø
Identifying integration environment:
- Identification of the integrated
environment like the operating system, configuration of the system etc. is
done.
Ø
Developing integration plan: - Before the integration of all the modules is done, a plan
is made on how to go about it.
Ø
Setting up integration environment: - After the plan is made and the environment is identified,
the integrated environment is set up.
Ø
Integration:-Integration of all the components/modules based on a proper
flow is done.
Ø
Conducting integration testing: -
Integrated testing is done based on the test cases and the test data.
Ø
Removal of bugs or defects: - All the defects or bugs that are encountered in the coding
phase are eliminated.
Ø
Close all reported defects: - All the bugs are removed.
2.5.6
Exit criteria
Successful updating of software test
plan.
Execution of software test plan.
2.5.7
Outputs
Software test cases.
Integrated and base lined product.
Software test records.
Review records of the code.
2.5.8
Measurements
Effort required for integration of the components/modules.
Effort required in the identification and elimination of the
defects in the integration test.
Effort required in the system tested software.
2.5.9
References
Software test plan (QMS-ISPL-T-STP)
Software test plan
checklist (QMS-ISPL-C-STP)
Software test
cases (QMS-ISPL-F-STC)
Work
Horse Tool
Work
Horse Tool at Inooga Solutions can also be used for
preparation of Design documents, Test Plans, defect tracking, test results
tracker of projects that are assigned to employees of the company working at
the Software Development center at various levels with appropriate reporting
and security features at each level.
2.6
Installation
and acceptance process
2.6.1
Process overview
Copies of the documents and programs
to be delivered to the customer are made by the project team to meet the replication
requirements mentioned in the contract (If any).
The software and number of copies to
be delivered by Inooga Solutions depends on the
contractual requirements and are mentioned in the project management plan of
the specific project.
The specific mode of delivery
software product for any project is mentioned in its PMP based on the
contractual requirements. The following modes are used for delivering the
identified deliverables:
Ø Through file transfer via satellite links.
Ø On magnetic media such as tapes, floppies.
Ø
Allow customer access to the
development machine so that customer can affect the file transfer.
Ø When the activity takes place on the customer machine, move from
development library/ directory to delivery library/ directory.
Ø Moving from development machine into production when specifically
authorized.
Deliverables included in the
delivery are recorded in the delivery note and sent along with the
deliverables. The project manager follows up with the customer for the
acknowledgement of delivery and feed back (if any) through email or phone calls
in which case the same is recorded through suitable means.
Installation process consists of
delivery and installation of the software at the premises of the customer.
Delivery includes checking the contents of the replicated software being sent
to the customer, either physical delivery or uploading the software to the
customer’s environment. Installation includes the preparations required to
install the software to the customer’s computer system and installation.
Acceptance process consists of
formally testing the software by the customer/customer representative as per
the terms of the contract unless contractual requirements specify Inooga Solutions to be responsible for this activity and by
means of acceptance test plan or customer supplied template. Acceptance may be
done prior to delivery or after the installation at the customers’ premises.
Acceptance testing aims at uncovering “implied requirements” and certifying
that software is fit for use. Depending on the contract/agreement of the order
in which installation and acceptance is done. Acceptance test planning is done
in the early stages of the development. If the acceptance test plan is prepared
by the customer/ customer representative the same is reviewed and issues are
resolved by the project manager. If the acceptance is prepared by the project
team then it is reviewed according to the company’s review process. The defects
found during this process are intimated to the project manager by email/ fax.
The project manager logs the defects reported using system discrepancies form (QMS-ISPL-F-SDF).
System discrepancies raised are tracked to closure before release of the next
baseline. In case of maintaining customer system or to provide post delivery
warranty
2.6.2
Responsibility
Project manager.
Project leader (delivery).
Customer and project leader
(acceptance and testing).
Team members and project leader (Review and closure of
defects).
Network administrator (backup of the
project).
2.6.3
Entry Criteria
Integrated
product.
2.6.4
Inputs
Contractual terms of software test
plan (STP).
2.6.5
Activities
Ø Preparation of STP: -The
software test plan is prepared by the project manager as per the contract /
agreement between the customer and Inooga Solutions.
Ø Review and approval of software test plan: - The ambiguities are eliminated if any from the STP. The
customer and project manager would approve after testing with test cases and
test data.
Ø Delivery of the software product: - The finished software product is delivered to the customer.
Ø Installation: -The
software product is ready for installation.
Ø Prepare the installation environment: -The installation environment is setup at the customer’s
premises.
Ø Installation of the software product on the designated
computer: - Once the systems are configured as
per the environment of the installation, the product is installed in the
designated systems.
Ø Verification on the installed software product: - Once the product is installed, the verification of the
product is done on the basis of performance.
Ø Participation in the acceptance testing along with the
customer: - Once the project/product is handed
over to the customer, the acceptance test begins and the project / product team
is present in the customer’s premises while performing acceptance testing.
Ø Closure of reported defects: - All the reported defects are eliminated.
Ø Obtaining acceptance certificate from customer: - Once the product’s performance is successful then Inooga Solutions obtains an acceptance certificate from the
customer.
Ø Conducting customer training (optional): - Inooga Solutions conducts customer training (if needed based up on
the customer requirements).
2.6.6 Exit Criteria
Acceptance certificate is obtained
from the customer.
2.6.7
Outputs
Software test cases.
Software test record.
Installed and accepted software product.
2.6.8
Measurements
Effort required in the installation/acceptance.
Effort required in the identification and elimination of the
defects/discrepancies in the acceptance test.
Effort required in the review and rework of the acceptance
test.
2.6.9
References
Software
test plan checklist (QMS-ISPL-C-STP).
Acceptance test
report (QMS-ISPL-R-ACT).
Acceptance
certificate (QMS-ISPL-F-PAC).
System discrepancy
form (QMS-ISPL-F-SDF).
Maintenance
Request Form (QMS-ISPL-F-MRF).
2.7.1
Process overview
Warranty
2.7.2
Responsibility
Project manager.
Project leader (delivery).
Team members.
2.7.3
Entry criteria
Implementation
of the software project/product.
2.7.4
Inputs
Installed software product.
User manuals / documents.
Customer feedback on problems.
2.7.5
Activities
Ø Reporting of the software problem by the customer: - The customer reports about the problems faced while using
the installed project/product.
Ø Fixing the problems reported by the customer: - The project leader ensures that the problems that are
reported by the customer are fixed.
Ø Validation of the corrected code: - In case where the validations done in the code are not up to
the expectations of the customer, they are corrected appropriately.
Ø Providing solution to the customer: - Problem statements are noted and the customer is provided
with adequate solutions.
2.7.6
Exit criteria
Customer
problems solved and the warranty period is closed.
2.7.7
Outputs
Rectifications if any from problems
encountered in the product.
2.7.8
Measurements
Effort required in the warranty
Effort required in the elimination of the defects in the
warranty
2.7.9
References
Nil
|
|
||||
|
Sl.
No |
Required
Record |
Custodian |
Retention
Period |
Record
ID |
|
1. |
SRS
(SSAD/UML/WEB BASED) |
Project
Manager/Coordinator |
Till
the end of the Project/Contract |
|
|
2. |
Requirements
Traceability matrix |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|
|
3. |
High
Level Design Document |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|
|
4. |
Detail
Design (OOAD/SSAD/UML) |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|
|
5. |
Delivery
Note |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|
|
6. |
Acceptance
Certificate |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|
|
7. |
Software
Test Plan |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|
|
8. |
Software
Test Cases |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|
|
9. |
Defect
Log |
Project
Manager/Coordinator |
Till
the end of the project/Contract |
|