Swe7903 TMT-SPMP 9 27 2010

Software Project
Management Plan (SPMP)

For the Test Management
Tool (TMT)
Test Management Tool (TMT)

Software Project Management Plan (SPMP)
TMT-SPMP-1.2
27-Sep-2010
This page is intentionally left blank for double-side printout.
Page 2 of 60

TMT-SPMP-1.2
27-Sep-2010
SIGNATURE PAGE
This page shows signatures of applicable team members indicating that the content of this
document has been carefully reviewed and concurred.
_________________________________
Jagati Vempaty
Lead Requirements Analyst
__________________
Date
_________________________________
Harish C. Sreenivas
Lead Architect/Designer
__________________
Date
_________________________________
Adam Scott
Lead Developer
__________________
Date
_________________________________
Seth Zaah
Lead QA / Tester
__________________
Date
_________________________________
Tom Q. Le
Project Manager
__________________
Date
_________________________________
Frank Tsui
Project Advisor
__________________
Date
Page 3 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 4 of 60

TMT-SPMP-1.2
27-Sep-2010
REVISION HISTORY
The following table lists a history of changes made to this document. When a change is made,
the following attributes are updated: Version, date, A/M/D, description, and CRN. The version
indicates major and minor changes; 9 minor changes make up 1 major. The A/M/D indicates if
the change is a modification, addition, or deletion. The CRN is the change request number, if
applicable. The description briefly describes the changes.
Version
Date
A/M/D
Description
1.0
08-Sep-2010
A
Initial Draft
1.1
20-Sep-2010 A,M Baseline
1.2
27-Sep-2010
M
Baseline updated after peer review
Page 5 of 60
CRN
N/A
N/A
N/A

TMT-SPMP-1.2
27-Sep-2010
Page 6 of 60

TMT-SPMP-1.2
27-Sep-2010
PREFACE
The purpose of this Software Project Management Plan (SPMP) is to provide guidance on the
management of the Test Management Tool (TMT) that is a part of the Southern Polytechnic
State University (SPSU) Testing System (STS) software development project. The template of
this plan conforms to the Institute of Electrical and Electronics Engineers (IEEE) Standard for
Software Project Management Plans, IEEE Std. 1058-1998, for format and content. The template
and its standard were selected as they are flexible and applicable to any type of project, wellknown to and accepted by many software companies, as well as common to the software
engineering department at SPSU. The TMT Project Manager (PM) assumes responsibility for
this document and updates it as required to meet the needs of the project. Updates to this
document are performed in accordance with the configuration management process defined
within this document, reviewed and concurred by applicable team members listed in the
signature page of this document.
This document relates to other documents as depicted in the following project document tree:
Software Project Management Plan
(TMT-SPMP)
POMA
Software Requirements Specification

(TMT-SRS)
POMA
Software Design Description

(TMT-SDD)
POMA
Software Test Plan

(TMT-STP)
POMA
Software Test Description

(TMT-STD)
POMA
Software Test Report

(TMT-STR)
POMA
Software Version Description

(TMT-SVD)
POMA
Software User Manual

(TMT-SUM)
Software Development Status Report
(TMT-SDSR)
Figure 1.1-1: Project Document Tree
Page 7 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 8 of 60

TMT-SPMP-1.2
27-Sep-2010
TABLE OF CONTENTS
SIGNATURE PAGE ...................................................................................................................... 3
LIST OF FIGURES ...................................................................................................................... 12
LIST OF TABLES ........................................................................................................................ 13
1. OVERVIEW ............................................................................................................................. 15
1.1. Project Summary ................................................................................................................ 15
1.1.1. Purpose, Scope, and Objectives .................................................................................. 16
1.1.2. Assumptions and Constraints...................................................................................... 16
1.1.3. Project Deliverables .................................................................................................... 17
1.1.4. Schedule and Budget Summary .................................................................................. 17
1.2. Evolution of the Plan ......................................................................................................... 18
1.3. Document Overview .......................................................................................................... 19
2. REFERENCES ......................................................................................................................... 21
2.1. Standards, Documents, and Other Material ....................................................................... 21
2.2. Deviations and Waivers ..................................................................................................... 21
3. DEFINITIONS.......................................................................................................................... 23
4. PROJECT ORGANIZATION .................................................................................................. 25
4.1. External Interfaces ............................................................................................................. 25
4.2. Internal Structure ............................................................................................................... 26
4.3. Roles and Responsibilities ................................................................................................. 26
5. MANAGERIAL PROCESS PLANS........................................................................................ 29
5.1. Start-up Plan....................................................................................................................... 29
5.1.1. Estimation Plan ........................................................................................................... 29
5.1.2. Staffing Plan................................................................................................................ 29
5.1.3. Resource Acquisition Plan .......................................................................................... 30
5.1.4. Project Staff Training Plan.......................................................................................... 31
5.2. Work Plan .......................................................................................................................... 31
5.2.1. Work Activities ........................................................................................................... 31
5.2.2. Schedule Allocation .................................................................................................... 31
5.2.3. Resource Allocation .................................................................................................... 31
5.2.4. Budget Allocation ....................................................................................................... 31
5.3. Control Plan ....................................................................................................................... 31
5.3.1. Requirements Control Plan ......................................................................................... 32
Page 9 of 60

TMT-SPMP-1.2
27-Sep-2010
5.3.2. Schedule Control Plan................................................................................................. 32

5.3.3. Budget Control Plan .................................................................................................... 33
5.3.4. Quality Control Plan ................................................................................................... 33
5.3.5. Reporting Plan ............................................................................................................ 34
5.3.6. Metrics Collection Plan............................................................................................... 35
5.4. Risk Management Plan ...................................................................................................... 35
5.5. Closeout Plan ..................................................................................................................... 36
6. TECHNICAL PROCESS PLANS ............................................................................................ 37
6.1. Process Model .................................................................................................................... 37
6.2. Methods, Tools, and Techniques ....................................................................................... 38
6.2.1. Requirements Methods & Techniques ........................................................................ 38
6.2.2. Design Models ............................................................................................................ 38
6.2.3. Testing Methods & Techniques .................................................................................. 38
6.2.4. Programming Languages ............................................................................................ 38
6.2.5. Tools ........................................................................................................................... 39
6.3. Infrastructure Plan .............................................................................................................. 39
6.4. Product Acceptance Plan ................................................................................................... 39
7. SUPPORTING PROCESS PLANS .......................................................................................... 41
7.1. Configuration Management Plan ....................................................................................... 41
7.2. Verification and Validation Plan ....................................................................................... 41
7.3. Documentation Plan ........................................................................................................... 42
7.4. Quality Assurance Plan ...................................................................................................... 42
7.5. Reviews and Audits ........................................................................................................... 43
7.6. Problem Resolution Plan.................................................................................................... 44
7.7. Subcontractor Management Plan ....................................................................................... 44
7.8. Process Improvement Plan ................................................................................................. 44
8. ADDITIONAL PLANS ............................................................................................................ 45
APPENDIXES .............................................................................................................................. 47
Appendix A: Requirements Review Checklist ......................................................................... 47
Appendix B: Design Review Checklist .................................................................................... 48
Appendix C: Code Review Checklist ....................................................................................... 49
Appendix D: Test Review Checklist......................................................................................... 50
Appendix E: Defect Report Form ............................................................................................. 51
Page 10 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix F: Review Kickoff Form .......................................................................................... 52

Appendix G: Review Closeout Form ........................................................................................ 53
Appendix H: Defect Resolution Form ...................................................................................... 54
Appendix I: Data Collection Point ............................................................................................ 55
Appendix K: Defect Severity Levels ........................................................................................ 56
Appendix L: Defect Types ........................................................................................................ 57
Page 11 of 60

TMT-SPMP-1.2
27-Sep-2010
LIST OF FIGURES
Figure 1.1-1: Project Document Tree ............................................................................................. 7
Figure 1.1-1: System Context Diagram ........................................................................................ 15
Figure 4.1-1: Project External Organization Interfaces ................................................................ 25
Figure 4.2-1: Project Internal Organization Structure .................................................................. 26
Figure 6.1-1: TMT Software Development Life Cycle (SDLC) .................................................. 37
Figure 6.2-1: TMT Requirements Process Flow........................................................................... 38
Figure 7.1-1: TMT Configuration Management Flow .................................................................. 41
Figure 7.4-1: Peer Review Process ............................................................................................... 42
Figure 7.4-2: Walkthrough Review Process ................................................................................. 43
Page 12 of 60

TMT-SPMP-1.2
27-Sep-2010
LIST OF TABLES
Table 1.1-1: Project Deliverables ................................................................................................. 17
Table 1.1-2: Master Build Schedule ............................................................................................. 17
Table 1.1-3: Project Budget Summary.......................................................................................... 17
Table 4.1-1: Programmatic Roles and Responsibilities ................................................................ 25
Table 4.3-1: Project Roles and Responsibilities ........................................................................... 26
Table 5.1-1: TMT Team Member Skill Levels ............................................................................. 30
Table 5.1-2: Non-Staff Resource Acquisition .............................................................................. 30
Table 5.3-1: TMT Team Member Contact Information ............................................................... 34
Table 5.3-2: TMT Metrics ............................................................................................................ 35
Table 6.2-1: TMT Programming Languages ................................................................................ 39
Page 13 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 14 of 60

TMT-SPMP-1.2
27-Sep-2010
1. OVERVIEW
1.1. Project Summary
The SPSU Testing System (STS) is a suite of software testing tools developed by SPSU students
majoring in Computer Science and/or Software Engineering to provide services to businesses
that need software testing. The STS aims to enhance manual software testing (via better defined
process, automatic test case generation, and improve on test cycle speed), improve test
management and control, and improve software product quality (via early defect detection). The
STS is a web-based system operating on a dedicated server which businesses can register to gain
access to different testing tools as described in the following system context diagram:
Req. Spec.,
Design Spec.,
Or Code
SPSU Testing System (STS)
Defines test
model
Test Case
Generation Tool
Test Execution
Tool
Test result info
Test Analyst
Test cases
Get test cases
Errors
Updates
test cases
Run test cases
Test cases
Test Management
Tool
Queries
test info
Test info
Test reports
Generate
test reports
Test case
assignments
Assigns
test cases
Testers
Lead Tester
Figure 1.1-1: System Context Diagram
Page 15 of 60

TMT-SPMP-1.2
27-Sep-2010
1.1.1. Purpose, Scope, and Objectives

This project involves in the evolutionary development of the STS, a software test suite that
consists of the following test tools:
1. Test Generation Tool (TGT): The purpose of this tool is to provide a test analyst the
capability to define a test model and generate test cases based on the inputs of
requirements specification, design specification, or source code via auto or manual
conversion. The tool converts the inputs into test cases; however, if the conversion fails,
the tool captures the errors. Both test cases and errors are then sent to the Test
Management Tool.
2. Test Management Tool (TMT): The purpose of this tool is to manage test cases, test error
forms, test results, test case assignments, test information queries, and test reports. This
tool also allows the test analyst to update the generated test cases.
3. Test Execution Tool (TET): The purpose of this tool is to allow testers run test cases and
produce test results. The test results are sent to the TMT for review and approval.
The development effort of the STS is divided and distributed to multiple teams (e.g., undergraduates and graduates) at SPSU. The TMT Team is responsible for the development of the
Test Management Tool and integration of other test tools into the STS.
1.1.2. Assumptions and Constraints
This SPMP will state the general plans, policies, and processes applicable to the TMT Team.
Both TGT and TMT tools must be completed and integrated by no later than 28-Nov-2010. This
plan assumes the following:
1. Schedule: 30-Aug-2010 - 12-Dec-2010.
2. Budget: This plan will state cost estimation based on $100.00 per a person-hour, 20
person-hours per week, and team size of 5 persons. The total budget is: $100.00 x 20
person-hours x 5 persons x 14 weeks = $140,000.00.
3. Resources:
a. Staffing: The staffing information in this plan is pre-assigned not by selective hire.
b. Tools: The TMT Team will only be responsible to acquire tools and software
needed for development, testing, and demos. At post-development, SPSU will be
responsible for deployment to production and maintenance.
Page 16 of 60

TMT-SPMP-1.2
27-Sep-2010
1.1.3. Project Deliverables

The TMT Team is responsible for the following deliverables:
Table 1.1-1: Project Deliverables
Item
Plans (i.e., SPMP & STP)
Requirements (i.e., SRS)
High-Level design (i.e., SDD)
Source codes & executable
Test info (i.e., STD & STR)
Code listing and version (i.e., SVD)
Install/user guide (i.e., SUM)
Project status data (i.e., SDSR)
EV presentations
IAB presentations
Date
Quantity Acquirer
28-Nov-2010
2
SPSU
28-Nov-2010
1
SPSU
28-Nov-2010
1
SPSU
28-Nov-2010
1
SPSU
28-Nov-2010
2
SPSU
28-Nov-2010
1
SPSU
28-Nov-2010
1
SPSU
28-Nov-2010
1
SPSU
Weekly
14
SPSU
28-Nov-2010
10
SPSU
Media
Document
Document
Document
DVD-ROM
Document
Document
Document
Document
Power Point
Power Point
***Note: The above deliverables are incrementally delivered for reviews. The date specified is
for the final deliverable.
1.1.4. Schedule and Budget Summary
The TMT Team uses MS Excel (as a part of the TMT Teams Metric Program) to track and
manage tasks, resources, schedule, and budget; therefore, the detail Work Breakdown Structure
(WBS), cost, schedule, and staffing resources are defined there. The following tables show the
high-level master build schedule and program budget summary:
Table 1.1-2: Master Build Schedule
Date
20-Sep-2010
27-Sep-2010
04-Oct-2010
11-Oct-2010
18-Oct-2010
25-Oct-2010
01-Nov-2010
08-Nov-2010
15-Nov-2010
22-Nov-2010
29-Nov-2010
06-Dec-2010
Build
Increment
Increment
Increment
Increment
Increment
Increment
Increment
Increment
Increment
Increment
Increment
Increment
01
02
03
04
05
06
07
08
09
10
11
12
Description
Demo of overall system architecture & design.
Demo of Test Case Management Feature.
Demo of TGT & TMT Integration #1.
Demo of Req. Info. Management Feature.
Demo of TGT & TMT Integration #2.
Demo of Test Resource Management Feature.
Demo of Test Result Management Feature.
Demo of Report Generation Feature.
Demo of Data Query Feature.
Demo of TMT full functionality.
Final integration of full functionality for TMT & TGT into STS.
IAB Demo.
Table 1.1-3: Project Budget Summary
Date
Budget
Description
06-Sep-2010 5000.00 Organize development team and develop project plans.
13-Sep-2010 10,000.00 System analysis and planning.
20-Sep-2010 10,000.00 Increment 01: Overall system architecture & design.
Page 17 of 60

TMT-SPMP-1.2
27-Sep-2010
Date
27-Sep-2010
04-Oct-2010
11-Oct-2010
18-Oct-2010
25-Oct-2010
01-Nov-2010
08-Nov-2010
15-Nov-2010
22-Nov-2010
29-Nov-2010
Budget
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
10,000.00 Increment
into STS.
06-Dec-2010 15,000.00 Increment
02:
03:
04:
05:
06:
07:
08:
09:
10:
11:
Description
Test Case Management Feature.
TGT & TMT Integration #1.
Req. Info. Management Feature.
TGT & TMT Integration #2.
Test Resource Management Feature.
Test Result Management Feature.
Report Generation Feature.
Data Query Feature.
TMT full functionality.
Final integration of full functionality for TMT & TGT
12: IAB Demo.
1.2. Evolution of the Plan

The purpose of this SPMP is to provide a documented plan for the management and control of
the organizational, developmental, and supporting processes necessary to the successful
implementation of the STS project. The development of TMT follows an agile development
methodology and therefore the detailed WBS and schedules can be changed; these changes are
managed separately from this plan (via TMT Teams Metric Program developed in MS Excel).
This document, however, subject to revision based on sudden changes in project or product
requirements, risk events, or unexpected deviation from the planned course of action. The initial
version of this SPMP is placed under configuration management; changes made to this document
will be controlled and tracked section 7.1 of this document.
Page 18 of 60

TMT-SPMP-1.2
27-Sep-2010
1.3. Document Overview

This plan is organized as follows:
1. Section 1: Project Overview. This section provides an overview of the scope and
objectives of the project, project's assumptions and constraints, deliverables, schedule and
budget, and evolution of the plan.
2. Section 2: References. This section provides a list of documents, standards, policies,
templates, processes, and other material referenced within this plan.
3. Section 3: Definitions. This section contains the abbreviations, acronyms, and definitions
of terminologies used within the plan.
4. Section 4: Project Organization. This section identifies interfaces to organizational
entities external to the project, describes the project's internal organization structure, and
defines roles and responsibilities for the project.
5. Section 5: Management Process. This section specifies the project management processes
for the project; i.e., planning, measurement, tracking, reporting, risk control mechanisms,
and project initiation and closeout procedures.
6. Section 6: Technical Process. This section specifies the development process model, the
technical methods, tools, and techniques to be used to develop the various work products,
plans for establishing and maintaining the project infrastructure, and the product
acceptance.
7. Section 7: Supporting Process. This section contains plans for supporting processes that
span the duration of the software project; including, but not limited to, configuration
management, verification and validation, documentation, quality assurance, reviews and
audits, problem resolution, and process improvement.
8. Section 8: Addition Plans. This section contains additional plans required to satisfy
product requirements, safety requirements, privacy and security requirements, as well as
any other plans.
9. Appendixes. This section contains addition material that helps the understanding of this
plan.
Page 19 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 20 of 60

TMT-SPMP-1.2
27-Sep-2010
2. REFERENCES
2.1. Standards, Documents, and Other Material
The standards and documents listed below are referenced in this document:
[1]
Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Project
Management Plans, IEEE Standard 1058-1998, IEEE, December 1998.
[2]
Model-Based Testing - Next Generation Functional Software Testing. STN 12-4 January 2010:
Model-Driven Development, January 2010.
2.2. Deviations and Waivers

N/A
Page 21 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 22 of 60

TMT-SPMP-1.2
27-Sep-2010
3. DEFINITIONS
The abbreviations, acronyms, and terminologies used throughout this document are listed below:
Term
ACWP
A/M/D
ASP
BCWP
BCWS
CRN
CSS
EDR
EV
GQM
HTML
IAB
IDE
IE
IEEE
IIS
MS
MTBF
N/A
PM
POMA
QA
SDD
SDLC
SDSR
SPMP
SPSU
SQL
SRS
STD
STP
STR
STS
SUM
SVD
SWE
TBD
TET
TGT
TMT
Definition
Actual Cost of Work Performed

Added/Modified/Deleted
Active Server Page
Budgeted Cost of Work Performed
Budgeted Cost of Work Scheduled
Change Request Number
Cascade Style Sheet
Effectiveness of Defect Removal
Earned Value
Goal Question Measurement
Hyper-Text Markup Language
Industrial Advisory Board
Integrated Development Environment
Internet Explorer
Electrical and Electronics Engineers
Internet Information Service
Microsoft
Mean Time Between Failures
Not Applicable
Project Manager
Plan, Organize, Monitor, Adjust
Quality Assurance
Software Design Description
Software Development Life Cycle
Software Development Status Report
Software Project Management Plan
Southern Polytechnic State University
Structural Query Language
Software Requirements Specification
Software Test Description
Software Test Plan
Software Test Report
SPSU Testing System
Software User Manual
Software Version Description
Software Engineering
To be decided
Test Execution Tool
Test Generation Tool
Test Management Tool
Page 23 of 60

TMT-SPMP-1.2
27-Sep-2010
Term
T-SQL
WBS
Definition
Transact-Structural Query Language

Work Breakdown Structure
Page 24 of 60

TMT-SPMP-1.2
27-Sep-2010
4. PROJECT ORGANIZATION
4.1. External Interfaces
External organizational interfaces and chain-of-command for the STS project are defined in the
following figure. All organizations defined in the figure are located within the Fall 2010-SWE7903 Capstone Course at SPSU.
Figure 4.1-1: Project External Organization Interfaces
The responsibilities of the organizational entities and key positions shown in figure above are
defined in the following table:
Table 4.1-1: Programmatic Roles and Responsibilities
Position
SPSU Software Engineering
Department
Project Advisor (Dr. Frank Tsui)
Test Generation Tool Team
Test Management Tool Team
TGT Project Manager (Stephen E.
Fyffe)
TMT Project Manager (Tom Q. Le)
Roles/Responsibilities
Project Review Board to provide final review on the
completion of the project.
Project advisor to professional consultant to the
development processes and audits the progress of
the project.
A team of 8 undergraduates to develop the TGT.
A team of 5 graduates to develop the TMT and
integration of the STS for demos.
To lead the development effort of the TGT team.
To lead the development effort of the TMT team.
Page 25 of 60

TMT-SPMP-1.2
27-Sep-2010
4.2. Internal Structure

The TMT project team organizational structure is defined in the following figure:
Figure 4.2-1: Project Internal Organization Structure
4.3. Roles and Responsibilities

Table 4.3-1: Project Roles and Responsibilities
Position
TMT Project Manager
TMT Project Manager - Deputy
TMT Requirements Lead
Organize and manage the project team.
Define project goals and establish measurements.
Develop project plans and processes.
Define, assign, and monitor tasks.
Monitor work progress and report statuses.
Calculate earned values.
Develop, review, and approve all documents.
Coordinate with all team members for risk
management and issue control.
Manage configurations, builds, and releases.
Review and approve requirements, designs,
codes, test scripts, and test reports.
Assist and be TMT PM's backup.
Work in parallel with the TMT PM in understanding
the project scope.
Initiate and lead the requirements elicitation,
prototyping, and specification.
Coordinate with the Design Lead to ensure the
designs satisfy requirements.
Review requirements, designs, codes, and test
Page 26 of 60

TMT-SPMP-1.2
27-Sep-2010
Position
TMT Requirements Lead - Backup

TMT Requirements Engineers
TMT Design Lead
TMT Design Lead - Backup

TMT Designers
TMT Development Lead
TMT Development Lead - Backup
TMT Developers
TMT Test Lead
TMT Test Lead - Backup

TMT Testers
cases.
Assist and be the Requirements Lead's backup.
Involve in requirements elicitations, prototyping,
modeling, specification, and review.
Work in parallel with the TMT Requirements Lead
to design the system architecture and software
designs.
Initiate and lead the design processes.
Coordinate with the TMT Development Lead to
ensure codes satisfy the design and requirements.
Involve in design and code reviews.
Assist and be the TMT Design Lead's backup.
Involve in designs, modeling, and reviewing
designs, and codes.
Work in parallel with the TMT Design Lead to
ensure codes developed in accordance to the
designs.
Initiate and lead the coding efforts.
Coordinate with the developers and testers.
Involve in software reviews.
Assist and be the TMT Development Lead's
backup.
Involve in coding and other reviews.
Work in parallel with the Requirements Lead and
Development Lead to develop test plans and test
cases.
Initiate and lead the test process.
Involve in other software reviews.
Assist and be the TMT Test Lead's backup.
Involve in developing test cases in executing test
cases and collect test results.
Involve in other software reviews.
Page 27 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 28 of 60

TMT-SPMP-1.2
27-Sep-2010
5. MANAGERIAL PROCESS PLANS

5.1. Start-up Plan
5.1.1. Estimation Plan
The TMT project estimation is based on the detailed work break structure defined in the TMT
Teams Metric Program (i.e., in MS Excel). The TMT PM defines the high-level tasks based on
the project scope and high-level requirements and then coordinates with the team leads (i.e.,
Requirements Lead, Design Lead, Development Lead, and Test Lead) to further break each highlevel task down to lower-level tasks. Each low-level task will be defined, assigned, and estimated
as follows:
Task Name:
The project management tasks are defined to develop the development plans and
run the team, including team meetings, status reports, coordination, and team
support. These tasks are mostly assigned to the project team manager.
The test management tool tasks are defined to develop the product that is broken
off into different product features. The project team manager provides the initial
task effort estimation and then assigns to team members based on their skill sets;
i.e., requirements, design, coding, testing, and documentation. On Monday of
each week, all team members get together and re-assess initial effort estimation to
provide more accurate effort estimation based on the previous actual efforts.
The support tasks are defined to do miscellaneous product supports and
maintenance during testing and customer demos.
For each task, the project team manager provides planned task information (i.e., start
date, finish date, duration, effort, and cost); the responsible team members record the
actual information.
Start Date: The date when the work begins.
Finish Date: The date when the work finishes.
Duration: The total number of days the work takes place.
Effort: The total hours it takes to finish the work.
Cost: The total of cost in dollar to complete the work.
Resource: The responsible team member (s) to work the task.
5.1.2. Staffing Plan
The project team consists of 5 graduate students pre-assigned to the team to complete the STS
architectural framework and the TMT tool. The following table summarizes the skill levels of all
team members:
Page 29 of 60

TMT-SPMP-1.2
27-Sep-2010
Table 5.1-1: TMT Team Member Skill Levels

Team Member
Adam Scott
Harish Sreenivas
Jagati Vempaty
Seth Zaah
Tom Le
Skill Level
8 years at Microsoft experienced in software development involving
in:
Windows, UNIX, Linux, Mac, WP7, and Symbian platforms.
Client-Server and stand-alone models.
Visual Studio 2005 - 2010, Net Beans, and Eclipse IDEs.
Java, C/C++, C# 2.0 - 4.0, HTML, Silverlight, J-Query, PHP,
and SQL programming languages.
MS SQL 2005 - 2008, MySQL, DB2, Posgress SQL databases.
Client machines and Windows Server environment.
Available 20 - 30 hours per week.
No work experience but involved in school projects. Good at
designs, UML, and requirements. Available 20 hours per week.
4 months internship as business analyst and data warehouse
designer. Available 25 hours per week.
More than 8 years in Field Service Support, acknowledged in
Windows, Java, C++, Rational Rose, MySQL, PL/SQL, HTML,
Process Improvement. Available 20 - 25 hours per week (Mon - Sat
from 10:00 AM to 7:00 PM).
Currently work at Lockheed Martin Aeronautics with more than 10
years experience in software project leadership and development
involving in:
Windows, Unix, and Embedded platforms.
Client-Server, stand-alone, and web-based models.
Visual Studio 2000 - 2010, J-Borland, C++ Borland, Rational
Apex, Ultra Edit IDEs.
Java, C/C++, C# 1.0 - 4.0, ADA, Visual Basics, HTML,
JavaScript, VBScript, SQL, T-SQL, PL/SQL, ASP, ASP.NET,
and JSP programming languages.
MS SQL 2000 - 2008, Oracle, and Access databases.
IIS, Tomcat, Apache, and desktop environment.
Available 20 - 30 hours per week.
5.1.3. Resource Acquisition Plan

In addition to the team members pre-assigned to the team, the following non-staff resources are
acquired by the project team manager for the development of the TMT product:
Table 5.1-2: Non-Staff Resource Acquisition
Description
Testing Environment (http://www.winhost.com), an
ASP.NET server used to operate the STS system. Needed
technology includes:
Windows 2008 Server.
IIS 7.0.
MS .NET Framework 4.0.
MS ASP.NET 4.0.
MS SQL Server 2008.
Page 30 of 60
Date
30-Aug-2010
Cost
$4.95/month
Paid by Tom

TMT-SPMP-1.2
27-Sep-2010
Description
MS Visual Studio 2010, an IDE.
Configuration Management Tool (at
http://adam.404.unfuddle.com).
Date
30-Aug-2010
20-Sep-2010
Cost
Free
Paid by Adam
5.1.4. Project Staff Training Plan

There is no plan for project staff planning. It is assumed that the team members assigned to the
TMT team have already been well trained in the pre-requisites of the capstone course. Team
members are assigned with responsibilities based on their initial skill levels and re-evaluated
after each development increment as applicable.
5.2. Work Plan

5.2.1. Work Activities
The various work activities to be performed in the project are defined in the TMT Teams Metric
Program. The work activities are decomposed from project management task, support task, and
product features into low-level tasks that expose all project risk factors and allow accurate
estimate of resource requirements and schedule duration for each work activity.
5.2.2. Schedule Allocation
After defining the various work activities, the TMT PM schedules the work activities agreeing
with the Table 1.1-2: Master Build Schedule and Table 1.1-1: Project Deliverables. The specific
schedule allocations for the detailed tasks are defined in the TMT Teams Metric Program.
5.2.3. Resource Allocation
The TMT PM allocates the various work activities to different team members based on their skill
levels and desired roles stated in Figure 4.2-1: Project Internal Organization Structure and Table
4.3-1: Project Roles and Responsibilities. The TMT PM and technical leads re-assesses resource
allocations weekly (i.e., every Monday).
5.2.4. Budget Allocation
The Table 1.1-3: Project Budget Summary shows the budgets allocated to major work activities
in the work breakdown structure. The detailed budget allocated to various tasks as well as other
cost (e.g., travel, meeting, equipments, etc.) are specified in the TMT Teams Metric Program.
5.3. Control Plan

The key factors that contribute to the TMT project management are the processes of planning,
scheduling, performance measurement, risk mitigation, variance analysis, and corrective action.
The TMT PM coordinates with the different technical leads to develop the detailed plans based
on established work assignments defined in the TMT Teams Metric Program for the TMT
project. Microsoft Office 2007 software is used to document the plans. The plans are then
Page 31 of 60

TMT-SPMP-1.2
27-Sep-2010
reviewed by both the Project Advisor and the team members. The approved plans are posted to
the team website at http://cse.spsu.edu/ftsui/SWE7903.html. Periodic reviews, weekly status
reports, and monthly assessments (i.e., earned-value and performance) are conducted to assess
the risks, to initiate risk analysis, to establish risk mitigation as well as to provide corrective
actions to the plans. Corrective action items are documented in the TMT Teams Metric Program
and communicated to the TMT Project Advisor and team members.
5.3.1. Requirements Control Plan
The TMT PM and Requirements Analyst are responsible for the project requirement's process.
The Requirements Team specifies all requirements in the Software Requirements Specification.
The TMT Project Advisor, PM, and all technical leads review the requirements for correctness
and ensure the integrity of the requirements specified by bi-directional traceability matrices built
in for each major document (i.e., SRS, SDD, STP, and STD). As traceability matrices are
produced, the Requirements Team is able to determine whether all requirements for each
increment are met. Any updates to the requirements cause a new revision to the SRS.
***NOTE: If time permits, it is also possible to use the newly developed TMT tool to control the
requirement traceability.
5.3.2. Schedule Control Plan
The TMT Team uses the TMT Teams Metric Program to measure the progress or work
completed at the major and minor project milestones, to compare actual progress to planned
progress, and to implement corrective action when actual progress does not conform to planned
progress. Achievement of schedule milestones are assessed using the objective criteria to
measure the scope and quality of work products completed at each milestone as specified in
section 5.3.6: Metrics Collection Plan of this SPMP.
5.3.2.1. Schedule Tracking
Project progress is charted on a weekly basis using the TMT Teams Metric Program. Schedule
performance data is generated at the task level and compared to the proposed schedule. Reports
are generated that provide data for incremental effort estimation adjustments and projected future
performance. The actual start dates, finish dates, task completion percentages, actual cost, and
resources used on each task are recorded in the TMT Teams Metric Program.
5.3.2.2. Schedule Performance Reports
Project schedule status information is measured against the required/planned dates and reports on
performance up-to-date are extracted from TMT Teams Metric Program and presented to the
weekly status meeting with the TMT Project Advisor every Monday at 7:45 PM. Microsoft
Excel is used to calculate the Actual Cost of Work Performed (ACWP), Budgeted Cost of Work
Scheduled (BCWS), Budgeted Cost of Work Performed (BCWP), and Estimate at Completion.
Page 32 of 60

TMT-SPMP-1.2
27-Sep-2010
5.3.2.3. Schedule Reviews
Schedule reviews are conducted by the TMT Project Advisor, PM, and technical leads on a
weekly basis (i.e., every Mondays or Wednesdays). Applicable schedule updates upon reviews
can be made to the TMT Teams Metric Program; the updates are then notified to the client and
all team members. Schedule reviews are done for at least one incremental release ahead to have
early risk mitigation.
5.3.2.4. Progress Variance Monitoring
Actual progress can differ from the planned progress for many reasons, including but not limited
to inaccurate effort estimation, resource limitation, plan and requirement changes, and etc. The
TMT technical leads are responsible to notify the TMT PM and the PM is responsible to update
the applicable scheduled tasks on the TMT Teams Metric Program. Deviations that are beyond
the PMs capabilities to resolve (e.g., member drop outs, non-productive or poor performance,
etc.) are brought to the Project Advisors attention.
5.3.2.5. Progress Variance Resolution
The TMT PM has the authority to reallocate resources, delegate and reschedule the tasks, or
correct performance problems that are not impacting a major release. Otherwise, consultancies
from the TMT Advisor are recommended.
5.3.2.6. Follow-Up on Corrective Action
The TMT Teams Metric Program is used to identify the initial schedule deviation and to analyze
the corrective action results. Corrective action items are closely monitored to ensure that they are
effectively recovering the schedule variance before milestone or the master build schedule is
jeopardized.
5.3.3. Budget Control Plan
The total cost of the project is $140,000.00 spreading out to 14 weeks as shown in Table 1.1-3:
Project Budget Summary. The project cost is calculated based on $100.00 per person-hour
expended for each task by each assigned resource; i.e., $100.00 * effort hour * resource. Periodic
cost analysis and reviews are conducted to assess performance and provide insight to the future
task assignments.
5.3.4. Quality Control Plan
There is no independent Quality Assurance (QA) Group under the TMT management. Instead,
the TMT PM and Testing Group are responsible for assurance of all quality and production
control requirements are being accomplished. The TMT Test Lead is responsible to conduct
various reviews on project plans, requirements, designs, codes, tests, and all other documents. In
performing these duties, the TMT Test Lead monitors adherence to all applicable policies,
processes, procedures, and plans.
Page 33 of 60

TMT-SPMP-1.2
27-Sep-2010
5.3.5. Reporting Plan

5.3.5.1. Status Reporting
The TMT PM generates and provides weekly project status to the TMT Project Advisor on
Monday at 7:45 PM. There are 12 weekly status reports and the detailed of each status report is
noted in the TMT Teams Metric Program under Project Management Tasks. All team members
are required to be present in all weekly status meetings.
5.3.5.2. Internal Reviews
The TMT Team holds in-progress reviews at least once month for the purpose of monitoring and
adjusting the internal process toward meeting the scheduled milestones, reviewing problems
encountered, presenting proposed resolutions, presenting near-term plans, reviewing risks and
mitigation plans, and individual performance assessments using earned value data extracted from
the TMT Teams Metric Program. The TMT PM is also responsible to provide internal reviews
to each team member based on individual in-progress performance and task assignments.
5.3.5.3. Meetings
As the project progress become more aggressive toward the deliverable deadline, the TMT Team
is more likely to call at least one meeting every Wednesday for the purpose of monitoring
progress, work coordination, issues and resolutions, and etc. as needed.
5.3.5.4. Information Repository
All project information needs to be submitted to the TMT PM for reviews and sign-offs. Source
codes need to be uploaded to the test environment at http://www.winhost.com for sharing
purposes among the team members as well as posted on the TMT Teams website at
http://cse.spsu.edu/ftsui/SWE7903.html.
*** NOTE: An alternative to uploading files to http://www.winhost.com, team members can also
upload files to Google Group; however, it is not recommended to for the purpose of having one
central information repository.
5.3.5.5. Communication
In addition to the aforementioned means of reporting and project communication, the TMT
members are recommended to communicate through email and phones as needed. The following
is the listing of the TMT team members contact information:
Table 5.3-1: TMT Team Member Contact Information
Name
Adam Scott
Harish Sreenivas
Email
ascott4@spsu.edu
hsreenivas@spsu.edu
Phone
770-940-0988
678-896-0727
Page 34 of 60
Comment
Busy on Wednesdays.
Work at SPSU Mon Wed,
11:00 5:00.

TMT-SPMP-1.2
27-Sep-2010
Name
Jagati Vempaty
Seth Zaah
Email
jvempaty@spsu.edu
sethzaah@yahoo.co.uk
Phone
404-751-7896
678-485-8014
Tom Le
tomle75@comcast.net
404-791-3816
Comment
N/A.
Work at Client Support/Real
Estate, 9:00 AM - 7:00 PM,
Mon - Sat.
Work at LM Aero Mon Fri,
9:00 3:00.
5.3.6. Metrics Collection Plan

The TMT Teams metric program follows the Goal-Question-Measurement (GQM) approach to
establish teams goals, define goal-oriented questions, and determine measurements for the
defined goals and questions. The following table shows various metrics the TMT Team needs to
collect and report:
Table 5.3-2: TMT Metrics
Metric Category
Product Metrics
Metric Name
Cost per Unit
MTBF
Product Size
Performance
Quality Level
Phase-based Effort
EDR per Phase
Process Metrics
Response Time of Fix

Fix Backlog
Fix Quality
Defect Density
Schedule
Project Metrics
Cost
Productivity
Scope
Purpose
To project future cost estimation.
To collect the mean time between failures to
project product availability.
To provide future effort estimation.
To provide product performance assessment
since it is an online service.
To assess the product quality level.
To assess the effort by various development
phases (i.e., requirements, design, code,
test, and documentation).
To assess the effectiveness of defect
removal per phase.
To assess responses to fixes, future effort
estimations, and early risk mitigations.
To assess future workloads and schedule
risks.
To assess rework.
To assess defects per product size.
To identify root causes for schedule slippage
and work under-estimates.
To identify cost variance and task allocation.
To assess productivity and task reallocation.
To identify changes to project scope.
***NOTE: The detailed GQM metric program is defined in a separate MS Excel file and posted
on the TMT website at http://www.cse.spsu.edu/ftsui/SWE7903.html.
5.4. Risk Management Plan

To ensure all milestones and work packages delivered on-time, within budget, at product quality,
the TMT Teams strategy is to follow the steps below:
Page 35 of 60

TMT-SPMP-1.2
27-Sep-2010
1. Identify risks a week ahead of current build schedule (i.e., Table 1.1-2: Master Build
Schedule).
2. Enter risks in the TMT Teams Metric Program.
3. PM and technical leads analyze risks, determine resolution, and implement resolution.
4. PM and technical leads provide follow-ups on risks resolution results.
5.5. Closeout Plan

The TMT aims to complete the project 2 week earlier than the assigned deadline (i.e., 12-Dec2010). All work activities need to be finished by 28-Nov-2010. The project closeout occurs on
12-Dec-2010 with a presentation to the Industrial Advisory Board (IAB) referred by the SPSU
Software Engineering Department. Along with the written reports and final documents (i.e.,
Table 1.1-1: Project Deliverables & Figure 1.1-1: Project Document Tree), the TMT Team is
required to present the following information:
1.
2.
3.
4.
5.
Requirements.
Designs.
Test Results.
Code/Product Demo.
Development Status.
Page 36 of 60

TMT-SPMP-1.2
27-Sep-2010
6. TECHNICAL PROCESS PLANS

6.1. Process Model
Due to uncertainties in product requirements (i.e., product functionalities are open for market
competitiveness), small team size, no project historical data, and new product type being
developed, the TMT Team tailors the Agile process model to decompose the high-level work
packages into low-level tasks and group tasks by product feature. Each product feature is
developed, reviewed, demonstrated, and modified in an increment of 2 weeks. This process is
described in the figure below:
Output/Artifact
Activity
Documents,
Reviews
Documents,
Reviews
Code
SVD & Demo
Documents,
Reviews
Test
STD & STR
Documents,
Reviews
Install/Support
Documents,
Reviews
Status Report
Reports the overall development status
Increment # 12
SDD
Software user manual
Documents,
Reviews
Design
Increment # 1
Initial Development
SRS
Test procedures and results as planned
Documents,
Reviews
Requirements
...
SPMP & STP
Source code listing and versions
Planning
SUM
SDSR
Figure 6.1-1: TMT Software Development Life Cycle (SDLC)
The development of the TMT tool is broken into one initial development and 12 incremental
developments. Each incremental development spans through all activities from requirements,
design, code, test, install/support, and status reporting, except the initial development spans from
the planning activity. The purpose of the initial development is to produce the following the
following software artifacts:
1.
2.
3.
4.
5.
6.
7.
A complete project plans (=> SPMP & STP).

Requirements specification for the overall system framework => SRS).
Overall system architectural and high-level component designs (=> SDD).
Source codes for the system architecture and framework (=> SVD).
Test cases, procedures, and results for the framework (=> STD & STR).
A draft installation and user manual (=> SUM).
A draft development status report (=> SDSR).
Page 37 of 60

TMT-SPMP-1.2
27-Sep-2010
In all other incremental developments, steps 2 through 7 are re-iterated and correspondent
documents are updated.
6.2. Methods, Tools, and Techniques

6.2.1. Requirements Methods & Techniques
The TMT Team follows the requirements process described in the figure below:
Figure 6.2-1: TMT Requirements Process Flow
6.2.2. Design Models

The TMT Team models the STS using the client-server system architecture and layers logical
codes using the 3-tier software design pattern. The architectural design diagrams component
descriptions are described in the Software Design Descriptions (SDD).
6.2.3. Testing Methods & Techniques
The TMT Team provides two levels of testing: Functional Test and Integration Test. In
functional tests, the TMT Testing Group develops requirement-based test cases in accordance to
the TMT Software Test Plan. In integration tests, the TMT Testing Group needs to evaluate the
overall operating capability of the TMT and TGT tools as part of the overall STS system. All test
cases and test procedures are described in the Software Test Description (STD). The TMT
Testing Group is also responsible to capture the test results and documents them in the Software
Test Report (STR).
6.2.4. Programming Languages
To implement the TMT tool, the team uses the following programming languages:
Page 38 of 60

TMT-SPMP-1.2
27-Sep-2010
Table 6.2-1: TMT Programming Languages

Language
C#
ASP.NET
T-SQL
HTML
CSS
JavaScript
Silverlight
Version
4.0
4.0
2008
4.0
2.0
1.1
2.0
Description
Used to implement business rules and data access logics.
Used to implement web-based user interfaces.
Used to implement database stored procedures, functions,
and database queries.
Used in parallel with ASP.NET to implement web pages.
Used to control user interface looks and feel.
Used to implement client-side codes.
Used to improve the user interface.
6.2.5. Tools
The TMT Team uses the following tools for the development and testing of the STS overall
framework and the TMT tool:
Tool
MS Visual Studio
Version
2010 Pro
MS SQL Server
2008 Pro
Microsoft Office
2007 Pro
MS IE Browser
MS Firefox
Project Manager
7.0
8.0
2010
Description
An Integrated Development Environment (IDE) used for
development and software builds.
A RDBM system used to develop and test the database
scripts, stored procedures, and user-defined functions.
i.e., Word, Excel, Visio, Power Point, and Outlook used for
documents, metrics, designs, presentations, and
communication respectively.
Used to test the system.
Used to test the system.
An online tool used to manage the work activities.
6.3. Infrastructure Plan

There is no plan for the project infrastructure. The TMT Team makes use of the SPSU facilities
and home offices. The TMT Team uses an online service at http:///www.winhost.com for testing
environment.
6.4. Product Acceptance Plan

There is no plan for the product acceptance; however, the work products generated need to agree
to the planned deliverables and project basic requirements. The TMT Project Advisor has the
opportunities to incrementally evaluate the product features on a weekly basis. Changes in scope
can be negotiated and documented.
Page 39 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 40 of 60

TMT-SPMP-1.2
27-Sep-2010
7. SUPPORTING PROCESS PLANS

7.1. Configuration Management Plan
All software artifacts generated by the TMT Team need to be uploaded to the Teams website at
http://cse.spsu.edu/ftsui/SWE7903.html and at ftp.tqllearning.com. Due to decentralized work
locations of all team members, a remote configuration management is required. The TMT Team
uses http://adam404.unfuddle.com/svn/adam404_capstone/ to share and control versions of all
software product artifacts. The following figure depicts the process of configuration
management:
Figure 7.1-1: TMT Configuration Management Flow
7.2. Verification and Validation Plan

There is no independent verification and validation organization needed for this project. All
verifications and validations are done through peer reviews and walkthroughs. The TMT Project
Advisor plays an important role in verifying and validating the TMT's developmental plans,
processes, schedules, deliverables, and quality of the product before the IAB presentation and
demo. To assure the time for the TMT Project Advisor completing his verification and
validation, the TMT Team provides incremental submissions of project statuses, demos, and
deliverables on the weekly basis as a minimum.
Page 41 of 60

TMT-SPMP-1.2
27-Sep-2010
7.3. Documentation Plan

The Figure 1.1-1: Project Document Tree shows all project documents needed as part of the
deliverables. The following table summarizes the different deliverable documents:
Document Type
Format Standard
Project Management Plan

Test Plan
Requirements Specification
Design Descriptions
Test Descriptions
Test Report
Version Description
Development Status Report
User Manual
Estimated
Page
Count
50
50
50
50
50
50
50
50
50
Review Type
Peer Review
Peer Review
Walkthrough
Walkthrough
Peer Review
Peer Review
Peer Review
Peer Review
Peer Review
7.4. Quality Assurance Plan

To assure that the project fulfills its commitments to the process and the product as specified in
the requirements specification, the document, supporting plans, and any standards, procedures, or
guidelines to which the process or the product must adhere, the TMT PM, all Technical Leads,
and Project Advisor need to review all work products produced by the team. The TMT supports
two types of review: Peer Review and Walkthrough.
Figure 7.4-1: Peer Review Process
Page 42 of 60

TMT-SPMP-1.2
27-Sep-2010
In a Peer Review, when the author completes a work product he/she notifies the project manager
to initiate peer review. The project manager assures that the work product is in configuration,
properly versioned, and ready for review and then initiates the review by assigning various
reviewing activities to different technical expertise. Each reviewer reviews the assigned part of
the work product to find defects and records them. Once completing the assigned review, each
reviewer submits findings/defects to the author of the work product. The author updates the work
product based on the findings submitted, if applicable. The project manager moderates the entire
review process to assure all finding being updated properly and then closes out the review.
Find defects
Work Product
Completes
Updates
Initiates review
Moderates & closes review
Notifies
Reviewers
Author
Project Manager
Figure 7.4-2: Walkthrough Review Process
The process of a Walkthrough Review is similar to the Peer Review, except that all participants;
i.e., project manager, author, and reviewers, are gathering in a meeting and walk through the
work product to find defects and correct them as applicable. This type of review is more
expensive but it produces more product quality.
Appendix A is the checklist for requirements review.
Appendix B is the checklist for design review.
Appendix C is the check list for code review.
Appendix D is the checklist for test procedure/script review.
Appendix E is the template for how to record a defect.
Appendix F is the template for how to plan and kick off a review.
Appendix G is the template for how to close out a review.
Appendix H is the template for how to resolve a finding.
7.5. Reviews and Audits

The following is a listing of all work products and corresponding review types::
Product Type
Documentation
Work Product
SPMP
Type of Review
Peer Review
Page 43 of 60
Purpose
To agree and follow the plans

TMT-SPMP-1.2
27-Sep-2010
Product Type
Work Product
Type of Review
Requirements
Test
Design
Code
Test
Test
Documentation
SRS
STP
SDD
Source Code
STD
STR
SVD
Walkthrough
Peer Review
Walkthrough
Peer Review
Peer Review
Peer Review
Peer Review
Documentation
SDSR
Peer Review
Documentation
SUM
Peer Review
Purpose
and established processes.
See appendix A.
See appendix D.
See appendix B.
See appendix C.
See appendix D.
See appendix D.
To assure that all source codes
produced properly listed.
To assure that the report
properly reflect the development
statuses.
To assure that the manual
clearly explains how to use the
product.
7.6. Problem Resolution Plan

When a defect is found during a peer review or walkthrough, the author of work product being
reviewed is responsible to resolve the problem. If it is a major problem that seriously impact the
delivery, the author needs to consult with the project manager to plan tasks fixes in future
releases. Effort devoted to problem reporting, analysis, and resolution are separately reported and
tracked for rework and process improvement. See appendices E through H for more details.
7.7. Subcontractor Management Plan

There is no plan for subcontractors. The TMT Team will perform all work activities needed to
complete the project.
7.8. Process Improvement Plan

Both the TMT Team and the Project Advisor have the opportunities to review and sign off on all
TMT Project plans. Due to the time constraint of this project, major changes to the plans are not
supported. However, minor changes to improve the effectiveness of project management,
product quality, and productivity are promoted. The TMT PM will analyze the measurement data
collected, status report feedbacks, and then assesses the effectiveness and value of the team
processes in order to suggest and make the changes. Changes will be reviewed and signed off by
all team members and the Project Advisor.
Page 44 of 60

TMT-SPMP-1.2
27-Sep-2010
8. ADDITIONAL PLANS
There are no other addition plans.
Page 45 of 60

TMT-SPMP-1.2
27-Sep-2010
Page 46 of 60

TMT-SPMP-1.2
27-Sep-2010
APPENDIXES
Appendix A: Requirements Review Checklist
Use this symbol to check and use this to uncheck.
Author:
Moderator:
Date:
Purpose:
Review specification quality:
Can each item be implemented and tested?
Is the meaning of each item understood?

Is the specification easy to read?
Review traceability:
Can each item in the requirements specification be traceable to product
features?
Is the traceability backward and forward correct?
Has the traceability been captured in the appropriate tool?
Review for areas of future growth:
Have all areas of uncertainty, incompleteness, or areas of future growth been
considered and identified?
Review error handling:
Have all error handling and recovery requirements been considered?

Review interfaces:
Do interfaces correspond to defined and coordinated interfaces?

Review associated work products updated:
Have all relevant models and specifications been updated?
Page 47 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix B: Design Review Checklist

Author:
Moderator:
Date:
Purpose:
Review anticipated changes:
Is the design flexible enough to allow for anticipated and unanticipated
changes?
Have all reasonable anticipated changes been identified?
Are areas of anticipated changes isolated?
Review design considerations:
Is the design complete?
Have all design views been addressed?
Does it perform the specified function?
Does it promote information hiding and reuse?
Is it highly cohesive/loosely coupled?
Does the data item naming meet standards?

Has persistent data been considered in the design?
Can the design be changed without excessive impact of other items?
Does documentation conform to standards?
Are all assumptions valid?
Are any assumptions missing?
Review error handing:
Have all error handling and recovery impacts been considered?
Are any error conditions missing?
Review interfaces:
Are the interfaces specified?
Are the interface specifications sufficient?
Are they consistent with the interfaces captured in the requirements

specification?
Do they correspond to defined and coordinated interfaces?
Review source product completeness:
Are the current requirements correct?
Are all requirements addressed by the design?

Are there any open action items that might affect the design?
Review syntactic/semantic checks:
If the design work product is too-generated output, does this output pass the
tools syntactic and semantic checks?

If the design is represented in a programming language, does the design
compile cleanly?
Is each item in the design directly traceable to one or more items in the
requirements?
Has this traceability been captured in the design according to standards?
Page 48 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix C: Code Review Checklist

Author:
Moderator:
Date:
Purpose:
Review code considerations:
Is the code complete?
Does it promote information hiding and reuse?
Is it highly cohesive/loosely coupled?
Does the data item meet standards?
Has persistent data been considered in code?

Can it be changed without excessive impact on other items?
Have approved methods been followed?
Does documentation conform to standards?
Does it compile cleanly?
Review auto-generated code:
Is the code work product is too-generated output, does this output pass the
tools syntactic and semantic checks?

Does it compile cleanly?
Review interfaces:
Are the interfaces specified?
Are the interfaces sufficient?

Are they consistent with the interfaces capture in the requirements and design?
Review prologue/comments:
Are comments meaningful and accurate?
Are special cases/conditions described?

Is all code marking requirements satisfied?
Review source product completeness:
Are the current requirements and design correct?
Are all requirements and design aspects addressed by the code?

Are there any open action items that might affect the code?
Review coding standards:
Has the approved method been followed?
Does the documentation conform to standards?

Does the code meet defined standards?
Is each item in the code directly traceable to one or more items in the
requirements and design?

Has this traceability been captured in the coding according to standards?
Page 49 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix D: Test Review Checklist

Author:
Moderator:
Date:
Purpose:
Are all test cases and test procedures described and documented in the STD?
Are the test cases followed the STP?
Have all test results been captured and documented in the STR?
Do all test cases test the requirements?
Page 50 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix E: Defect Report Form

Use this form for each finding submitted.
Review type:
Project:
Data collection point:
Author:
Moderator:
Reviewer:
Date:
Purpose:
File containing finding:
Line in file:
Severity code:
Defect type:
Comments:
Time invested
Page 51 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix F: Review Kickoff Form

Use this form to kick off a new review.
Review type:
Project:
Author:
Moderator:
Reviewers:
Date:
Purpose:
File names:
Page 52 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix G: Review Closeout Form

Use this form to close out a review.
Review type:
Project:
Author:
Moderator:
Reviewer:
Date:
Purpose:
Meeting duration:
Number of people at meeting:
Rework effort (author):
Follow-up effort (moderator):
Action item comments:
Concluding comments:
Page 53 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix H: Defect Resolution Form

Use this form to record resolution for findings.
Review type:
Project:
Author:
Moderator:
Reviewer:
Date:
Purpose:
File containing finding:
Line in file:
Severity code:
Defect type:
Comments:
Time invested
Author comments:
Moderator comments:
Defect resolution:
Page 54 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix I: Data Collection Point

Code
1
1a
2
2a
2b
2c
2c1
2c2
3
3a
3b
3b1
3b2
4
4a
4a1
4a2
5
5a
5a1
5b
5c
5d
6
6a
6b
7
Data Collection Point

Phase - Business Acquisition and Planning
Activity - Supply Process
Phase - Requirements
Activity - System Requirements Analysis
Activity - System Architectural Design
Activity - Software Requirements Analysis
Informal Software Requirements
Formal Software Requirements
Phase - Design
Activity - Software Architectural Design
Activity - Detailed Design
Detailed Design Informal
Detailed Design Formal
Phase - Implementation
Activity - Software Coding and Testing
Software Coding Informal
Software Coding Formal
Phase - Integration and Test
Activity - Software Integration
Documentation
Activity - Software Qualification Testing
Activity - System Integration
Activity - System Qualification Testing
Phase - Transition to Customer
Activity - Software Installation
Activity - Software Acceptance Support
External to the Software Product
Page 55 of 60

TMT-SPMP-1.2
27-Sep-2010
Appendix K: Defect Severity Levels

Code
0
1
Defect Description
No defect found or comment.
Prevents the accomplishment of an operational or mission
essential capability
Jeopardizes safety
Causes significant technical, cost, or schedule risks to the
project or to life cycle support of the system. This is a MAJOR
defect.
Adversely affects the accomplishment of an operational or
mission essential capability and no work-around solution is
known
Adversely affects technical, cost, or schedule risks to the project
or to life cycle support of the system, no work-around solution is
known. This is a MAJOR defect.
Adversely affects the accomplishment of an operational or
mission essential capability, but a work-around solution is
known
Adversely affects technical, cost, or schedule risks to the project
or to life cycle support of the system, but a work-around
solution is known. This is a MAJOR defect.
Results in user/operator inconvenience or annoyance, but does
not affect a required operational or mission essential capability
Results in inconvenience or annoyance for development or
support personnel, but does not prevent the accomplishment of
those responsibilities. This is a MINOR defect.
Any other effect not described above. Projects may define and
assign sub-codes for this priority. This is a MINOR defect.
Page 56 of 60
Level
None
Major
Major
Major
Minor
Minor

TMT-SPMP-1.2
27-Sep-2010
Appendix L: Defect Types

Code
1a
Defect Type
Functionality
1b
GFE/BFE/CFE/Subcontractor
1c
Software Engineering
Environment (SEE)
1d
Programmatic Requirements
1e
Test
Equipment/Environment
Support
Documentation
1f
1z
2a
Subsystem/Software
Requirements
2b
Physical Interface
2c
Functional Interface
2d
User Interface
2e
System Requirements
2z
Documentation
3a
Physical Interface
Description
The definition of a functional capability desired by
the customer was not clear and unambiguous, or
was misinterpreted.
Incompatibilities or deficiencies with specificationcompliant Government Furnished Equipment
(GFE), Buyer Furnished Equipment (BFE),
Contractor Furnished Equipment (CFE), or
subcontractor supplied products in their interaction
with the system.
The SEE, as specified, is deficient in supporting the
software engineering process; incompatibilities
exist between SEE tools.
Conflicting contractual requirements; problems
relating to security requirements; problems
relating to teaming with other companies.
The test equipment/environment, as specified, is
deficient to support system operation.
The support equipment/environment, as specified,
is deficient to support system operation.
Documentation does not accurately/adequately
describe the planning, and categories 1a through
1f are not appropriate.
Incorrect/incomplete translation or specification of
the lower level (subsystem/software) requirements
that was not the result of category 2e. Examples
include: incorrect specification at the SRS level,
subsystem specification incorrect, etc.
An error in the definition or specification of a
physical (hardware) interface.
Incorrect/incomplete specification of the functional
interaction or communication of data with other
processes or subsystems, and categories 2b and
2d are not appropriate.
Incorrect/incomplete specification of the software
interaction with the user.
Incorrect/incomplete translation or specification of
the customer requirements that was not the result
of category 1a. Examples include: incorrect
specification at the SSS level, Air Vehicle
Specification, etc.
Documentation does not accurately describe the
intended requirements, and categories 2a through
2e are not appropriate. Format, documentation
standards, typographical errors, and
understandability are included in this category.
Incorrect/incomplete design of the software
interaction with hardware.
Page 57 of 60

TMT-SPMP-1.2
27-Sep-2010
Code
3b
Defect Type
Subsystem Interface
3c
User Interface
3d
Inter-process
Communication
3e
Data Definition
3f
Unit/Procedure Design
3g
Error Handling
3h
Standards
3i
Traceability
3z
Documentation
4a
Logic
4b
Computations
4c
Data Handling
4d
Unit Interface
Description
Incorrect/incomplete design of the functional
interaction or communication of data with other
subsystems or processes, and categories 3a and 3c
are not appropriate.
Incorrect/incomplete design of the software
interaction with the user.
Incorrect/incomplete interfaces or communications
between processes or components within a
product. Includes timing/scheduling anomalies as
well as parameter passing/ omission and other
inter-process defects.
Incorrect/incomplete design of the data structures
to be used in the product, e.g., defects associated
with data precision/accuracy and data units.
Problem with the control flow and execution within
a unit/procedure. For example, errors in
logic/computations in algorithms,
incorrect/incomplete translation of requirements,
incorrect/incomplete sequence of operations in a
test procedure or installation procedure, etc.
The checks for error detection/isolation were not
adequate, or the response to detected error
conditions was not correct.
Violations of design standards that do not cause a
defect in the functional operation of the product.
This does not include documentation standards.
A known requirement was missed or a non-existing
requirement was introduced into the design.
design or software configuration item (product)
test plans/procedures, and categories 3a through
3i are not appropriate. Format, documentation
Incorrect/incomplete decision logic causes the
product not to implement the full intent of the
design, e.g., invalid "If-Then-Else," loop structures,
case statements, missing "Begin-End," wrong
execution sequence.
Incorrect/incomplete mathematical or arithmetic
operations cause the product not to implement the
full intent of the design.
Incorrect/incomplete definition or use of data
structures in accordance with the design. This
category includes data precision, improper
indexing into arrays or tables, improper scaling or
units of measure, and data incorrectly stored or
accessed.
Problems related to the calling, parameter
Page 58 of 60

TMT-SPMP-1.2
27-Sep-2010
Code
Defect Type
4e
Standards
4f
Build/Configuration
4z
Documentation
5z
Documentation
6z
Documentation
7a
GFE/BFE
7b
CFE/Subcontractor
7c
SEE
7d
Other
7e
Test
Description
definition, and termination of subprocesses. This
category includes incorrect order or number of
parameters passed, ambiguous termination value
for a function, incorrect parameter data types,
inter-process communication problems, and
timing/scheduling anomalies.
Violations of programming standards, incorrect use
of the programming language, typographical errors
during code/text entry for source code and test
procedures, etc.
Incorrect/incomplete software build/configuration,
e.g., missing code, wrong version of code,
incorrect placement in memory, missing test
procedure, etc.
implementation of the design, and categories 4a
through 4f are not appropriate. This category also
includes defects in documentation format or other
documentation standards, typographical errors,
understandability, etc.
Documentation does not accurately reflect test
results. Format, documentation standards,
typographical errors, and understandability are
included in this category. This category does not
include problems with software configuration item
test plans, test cases, or test procedures.
Documentation generated to support the transition
to the customer is in error. Format, documentation
This category does not include problems with
documentation developed in prior phases that are
covered by categories 1z, 2z, ... 5z.
A problem caused by GFE/BFE not operating in
accordance with its specification.
A problem caused by external CFE/subcontracted
equipment/software not operating in accordance
with its specification, e.g., host computer
hardware, firmware, supplier errors, or
performance problems. This does not include
internally maintained reused assets.
A problem caused by the SEE not operating in
accordance with its specification, e.g., compiler
problems, linker problems, interface definition tool
problems, etc. This does not include internally
maintained reused assets.
Other external problem, and no other external
category is appropriate. This does not include
internally maintained reused assets.
The product under test is operating correctly, yet
Page 59 of 60

TMT-SPMP-1.2
27-Sep-2010
Code
Defect Type
7f
Support
Comment
Description
the test equipment/environment is operating
incorrectly. This does not include internally
The product under test is operating correctly, yet
the support equipment/environment is operating
incorrectly. This does not include internally
This Finding is only a comment and does not
document a defect or a candidate for a defect.
Page 60 of 60

Swe7903 TMT-SPMP 9 27 2010

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Swe7903 TMT-SPMP 9 27 2010

Hochgeladen von

Copyright:

Verfügbare Formate

Software Project

Management Plan (SPMP)

Test Management Tool (TMT)

This page is intentionally left blank for double-side printout.

Test Management Tool (TMT)

Test Management Tool (TMT)

This page is intentionally left blank for double-side printout.

Test Management Tool (TMT)

Test Management Tool (TMT)

This page is intentionally left blank for double-side printout.

Test Management Tool (TMT)

Software Requirements Specification

Software Design Description

Software Test Plan

Software Test Description

Software Test Report

Software Version Description

Software User Manual

Test Management Tool (TMT)

This page is intentionally left blank for double-side printout.

Test Management Tool (TMT)

Test Management Tool (TMT)

5.3.2. Schedule Control Plan................................................................................................. 32

Test Management Tool (TMT)

Appendix F: Review Kickoff Form .......................................................................................... 52

Test Management Tool (TMT)

Test Management Tool (TMT)

Test Management Tool (TMT)

This page is intentionally left blank for double-side printout.

Test Management Tool (TMT)

SPSU Testing System (STS)

Get test cases

Run test cases

Figure 1.1-1: System Context Diagram

Test Management Tool (TMT)

1.1.1. Purpose, Scope, and Objectives

Test Management Tool (TMT)

1.1.3. Project Deliverables

Test Management Tool (TMT)

12: IAB Demo.

1.2. Evolution of the Plan

Test Management Tool (TMT)

1.3. Document Overview

Test Management Tool (TMT)

This page is intentionally left blank for double-side printout.

Test Management Tool (TMT)

2.2. Deviations and Waivers

Test Management Tool (TMT)

This page is intentionally left blank for double-side printout.

Test Management Tool (TMT)

Actual Cost of Work Performed

Test Management Tool (TMT)

Transact-Structural Query Language

Test Management Tool (TMT)

Figure 4.1-1: Project External Organization Interfaces

Test Management Tool (TMT)

4.2. Internal Structure

Figure 4.2-1: Project Internal Organization Structure

4.3. Roles and Responsibilities

TMT Project Manager - Deputy

TMT Requirements Lead

Test Management Tool (TMT)

TMT Requirements Lead - Backup