Software Project Management Plan (SPMP) - Southern Polytechnic ...

Software Project 

Management Plan (SPMP) 

For the Test Management 

Tool (TMT)

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

Page 2 of 60 

Test Management Tool (TMT) 

Software Project Management Plan (SPMP) 

TMT-SPMP-1.2 

27-Sep-2010

SIGNATURE PAGE 

Page 3 of 60 




27-Sep-2010 

This page shows signatures of applicable team members indicating that the content of this 

document has been carefully reviewed and concurred. 

_________________________________ __________________ 

Jagati Vempaty Date 

Lead Requirements Analyst 

_________________________________ __________________ 

Harish C. Sreenivas Date 

Lead Architect/Designer 

_________________________________ __________________ 

Adam Scott Date 

Lead Developer 

_________________________________ __________________ 

Seth Zaah Date 

Lead QA / Tester 

_________________________________ __________________ 

Tom Q. Le Date 

Project Manager 

_________________________________ __________________ 

Frank Tsui Date 

Project Advisor


Page 4 of 60 




27-Sep-2010

REVISION HISTORY 

Page 5 of 60 




27-Sep-2010 

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 CRN 

1.0 08-Sep-2010 A Initial Draft N/A 

1.1 20-Sep-2010 A,M Baseline N/A 

1.2 27-Sep-2010 M Baseline updated after peer review N/A


Page 6 of 60 




27-Sep-2010

PREFACE 

Page 7 of 60 




27-Sep-2010 

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: 

POMA 

POMA 

POMA 

POMA 

POMA 

POMA 

POMA 

Software Project Management Plan 

(TMT-SPMP) 

Software Requirements Specification 

(TMT-SRS) 

Software Design Description 

(TMT-SDD) 

Software Test Plan 

(TMT-STP) 

Software Test Description 

(TMT-STD) 

Software Test Report 

(TMT-STR) 

Software Version Description 

(TMT-SVD) 

Software User Manual 

(TMT-SUM) 

Software Development Status Report 

(TMT-SDSR) 

Figure 1.1-1: Project Document Tree


Page 8 of 60 




27-Sep-2010

TABLE OF CONTENTS 

Page 9 of 60 




27-Sep-2010 

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 10 of 60 




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 11 of 60 




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

LIST OF FIGURES 

Page 12 of 60 




27-Sep-2010 

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

LIST OF TABLES 

Page 13 of 60 




27-Sep-2010 

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 14 of 60 




27-Sep-2010

1.1. Project Summary 

1. OVERVIEW 

Page 15 of 60 




27-Sep-2010 

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 

Test Analyst 

Defines test 

model 

Updates 

test cases 

SPSU Testing System (STS) 

Test Case 

Generation Tool 

Test reports 

Generate 

test reports 

Test cases 

Lead Tester 

Test result info 

Test Management 

Tool 

Test Execution 

Tool 

Errors Test cases 

Queries 

test info 

Test info 

Assigns 

test cases 

Get test cases 

Test case 

assignments 

Figure 1.1-1: System Context Diagram 

Run test cases 

Testers

1.1.1. Purpose, Scope, and Objectives 

Page 16 of 60 




27-Sep-2010 

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.

1.1.3. Project Deliverables 

The TMT Team is responsible for the following deliverables: 

Table 1.1-1: Project Deliverables 

Page 17 of 60 




27-Sep-2010 

Item Date Quantity Acquirer Media 

Plans (i.e., SPMP & STP) 28-Nov-2010 2 SPSU Document 

Requirements (i.e., SRS) 28-Nov-2010 1 SPSU Document 

High-Level design (i.e., SDD) 28-Nov-2010 1 SPSU Document 

Source codes & executable 28-Nov-2010 1 SPSU DVD-ROM 

Test info (i.e., STD & STR) 28-Nov-2010 2 SPSU Document 

Code listing and version (i.e., SVD) 28-Nov-2010 1 SPSU Document 

Install/user guide (i.e., SUM) 28-Nov-2010 1 SPSU Document 

Project status data (i.e., SDSR) 28-Nov-2010 1 SPSU Document 

EV presentations Weekly 14 SPSU Power Point 

IAB presentations 28-Nov-2010 10 SPSU 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 Team’s 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 Build Description 

20-Sep-2010 Increment 01 Demo of overall system architecture & design. 

27-Sep-2010 Increment 02 Demo of Test Case Management Feature. 

04-Oct-2010 Increment 03 Demo of TGT & TMT Integration #1. 

11-Oct-2010 Increment 04 Demo of Req. Info. Management Feature. 

18-Oct-2010 Increment 05 Demo of TGT & TMT Integration #2. 

25-Oct-2010 Increment 06 Demo of Test Resource Management Feature. 

01-Nov-2010 Increment 07 Demo of Test Result Management Feature. 

08-Nov-2010 Increment 08 Demo of Report Generation Feature. 

15-Nov-2010 Increment 09 Demo of Data Query Feature. 

22-Nov-2010 Increment 10 Demo of TMT full functionality. 

29-Nov-2010 Increment 11 Final integration of full functionality for TMT & TGT into STS. 

06-Dec-2010 Increment 12 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 18 of 60 




27-Sep-2010 

Date Budget Description 

27-Sep-2010 10,000.00 Increment 02: Test Case Management Feature. 

04-Oct-2010 10,000.00 Increment 03: TGT & TMT Integration #1. 

11-Oct-2010 10,000.00 Increment 04: Req. Info. Management Feature. 

18-Oct-2010 10,000.00 Increment 05: TGT & TMT Integration #2. 

25-Oct-2010 10,000.00 Increment 06: Test Resource Management Feature. 

01-Nov-2010 10,000.00 Increment 07: Test Result Management Feature. 

08-Nov-2010 10,000.00 Increment 08: Report Generation Feature. 

15-Nov-2010 10,000.00 Increment 09: Data Query Feature. 

22-Nov-2010 10,000.00 Increment 10: TMT full functionality. 

29-Nov-2010 10,000.00 Increment 11: Final integration of full functionality for TMT & TGT 

into STS. 

06-Dec-2010 15,000.00 Increment 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 Team’s 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.

1.3. Document Overview 

This plan is organized as follows: 

Page 19 of 60 




27-Sep-2010 

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 20 of 60 




27-Sep-2010

2. REFERENCES 

2.1. Standards, Documents, and Other Material 

The standards and documents listed below are referenced in this document: 

Page 21 of 60 




27-Sep-2010 

[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 22 of 60 




27-Sep-2010

3. DEFINITIONS 

Page 23 of 60 




27-Sep-2010 

The abbreviations, acronyms, and terminologies used throughout this document are listed below: 

Term Definition 

ACWP Actual Cost of Work Performed 

A/M/D Added/Modified/Deleted 

ASP Active Server Page 

BCWP Budgeted Cost of Work Performed 

BCWS Budgeted Cost of Work Scheduled 

CRN Change Request Number 

CSS Cascade Style Sheet 

EDR Effectiveness of Defect Removal 

EV Earned Value 

GQM Goal Question Measurement 

HTML Hyper-Text Markup Language 

IAB Industrial Advisory Board 

IDE Integrated Development Environment 

IE Internet Explorer 

IEEE Electrical and Electronics Engineers 

IIS Internet Information Service 

MS Microsoft 

MTBF Mean Time Between Failures 

N/A Not Applicable 

PM Project Manager 

POMA Plan, Organize, Monitor, Adjust 

QA Quality Assurance 

SDD Software Design Description 

SDLC Software Development Life Cycle 

SDSR Software Development Status Report 

SPMP Software Project Management Plan 

SPSU Southern Polytechnic State University 

SQL Structural Query Language 

SRS Software Requirements Specification 

STD Software Test Description 

STP Software Test Plan 

STR Software Test Report 

STS SPSU Testing System 

SUM Software User Manual 

SVD Software Version Description 

SWE Software Engineering 

TBD To be decided 

TET Test Execution Tool 

TGT Test Generation Tool 

TMT Test Management Tool

Term Definition 

T-SQL Transact-Structural Query Language 

WBS Work Breakdown Structure 

Page 24 of 60 




27-Sep-2010

4.1. External Interfaces 

4. PROJECT ORGANIZATION 

Page 25 of 60 




27-Sep-2010 

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-SWE- 

7903 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 Roles/Responsibilities 

SPSU Software Engineering Project Review Board to provide final review on the 

Department 

completion of the project. 

Project Advisor (Dr. Frank Tsui) Project advisor to professional consultant to the 

development processes and audits the progress of 

the project. 

Test Generation Tool Team A team of 8 undergraduates to develop the TGT. 

Test Management Tool Team A team of 5 graduates to develop the TMT and 

integration of the STS for demos. 

TGT Project Manager (Stephen E. 

Fyffe) 

To lead the development effort of the TGT team. 

TMT Project Manager (Tom Q. Le) To lead the development effort of the TMT team.

4.2. Internal Structure 

Page 26 of 60 




27-Sep-2010 

The TMT project team organizational structure is defined in the following figure: 

4.3. Roles and Responsibilities 

Figure 4.2-1: Project Internal Organization Structure 

Table 4.3-1: Project Roles and Responsibilities 


TMT Project Manager 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. 

TMT Project Manager - Deputy Assist and be TMT PM's backup. 

TMT Requirements Lead 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 27 of 60 




27-Sep-2010 


TMT Requirements Lead - Backup 

cases. 

Assist and be the Requirements Lead's backup. 

TMT Requirements Engineers Involve in requirements elicitations, prototyping, 

modeling, specification, and review. 

TMT Design Lead 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. 

TMT Design Lead - Backup Assist and be the TMT Design Lead's backup. 

TMT Designers Involve in designs, modeling, and reviewing 

designs, and codes. 

TMT Development Lead 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. 

TMT Development Lead - Backup Assist and be the TMT Development Lead's 

backup. 

TMT Developers Involve in coding and other reviews. 

TMT Test Lead 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. 

TMT Test Lead - Backup Assist and be the TMT Test Lead's backup. 

TMT Testers Involve in developing test cases in executing test 

cases and collect test results. 

Involve in other software reviews.


Page 28 of 60 




27-Sep-2010

5.1. Start-up Plan 

5.1.1. Estimation Plan 

5. MANAGERIAL PROCESS PLANS 

Page 29 of 60 




27-Sep-2010 

The TMT project estimation is based on the detailed work break structure defined in the TMT 

Team’s 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:

Table 5.1-1: TMT Team Member Skill Levels 

Page 30 of 60 




27-Sep-2010 

Team Member Skill Level 

Adam Scott 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. 

Harish Sreenivas No work experience but involved in school projects. Good at 

designs, UML, and requirements. Available 20 hours per week. 

Jagati Vempaty 4 months internship as business analyst and data warehouse 

designer. Available 25 hours per week. 

Seth Zaah 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). 

Tom Le 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 Date Cost 

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. 

30-Aug-2010 $4.95/month 

Paid by Tom

Page 31 of 60 




27-Sep-2010 

Description Date Cost 

MS Visual Studio 2010, an IDE. 30-Aug-2010 Free 

Configuration Management Tool (at 

http://adam.404.unfuddle.com). 

20-Sep-2010 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 Team’s 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 Team’s 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 Team’s 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 Team’s Metric Program for the TMT 

project. Microsoft Office 2007 software is used to document the plans. The plans are then

Page 32 of 60 




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 Team’s 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 Team’s 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 Team’s 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 Team’s 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 Team’s 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.

5.3.2.3. Schedule Reviews 

Page 33 of 60 




27-Sep-2010 

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 Team’s 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 Team’s Metric Program. Deviations that are beyond 

the PM’s capabilities to resolve (e.g., member drop outs, non-productive or poor performance, 

etc.) are brought to the Project Advisor’s 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 Team’s 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.

5.3.5. Reporting Plan 

5.3.5.1. Status Reporting 

Page 34 of 60 




27-Sep-2010 

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 Team’s 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 Team’s 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 Team’s 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 Email Phone Comment 

Adam Scott ascott4@spsu.edu 770-940-0988 Busy on Wednesdays. 

Harish Sreenivas hsreenivas@spsu.edu 678-896-0727 Work at SPSU Mon – Wed, 

11:00 – 5:00.

Page 35 of 60 




27-Sep-2010 

Name Email Phone Comment 

Jagati Vempaty jvempaty@spsu.edu 404-751-7896 N/A. 

Seth Zaah sethzaah@yahoo.co.uk 678-485-8014 Work at Client Support/Real 

Estate, 9:00 AM - 7:00 PM, 

Mon - Sat. 

Tom Le tomle75@comcast.net 404-791-3816 Work at LM Aero Mon – Fri, 

9:00 – 3:00. 

5.3.6. Metrics Collection Plan 

The TMT Team’s metric program follows the Goal-Question-Measurement (GQM) approach to 

establish team’s 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 Metric Name Purpose 

Cost per Unit To project future cost estimation. 

MTBF To collect the mean time between failures to 

project product availability. 

Product Metrics Product Size To provide future effort estimation. 

Performance To provide product performance assessment 

since it is an online service. 

Quality Level To assess the product quality level. 

Phase-based Effort To assess the effort by various development 

phases (i.e., requirements, design, code, 

test, and documentation). 

EDR per Phase To assess the effectiveness of defect 

removal per phase. 

Process Metrics Response Time of Fix To assess responses to fixes, future effort 

estimations, and early risk mitigations. 

Fix Backlog To assess future workloads and schedule 

risks. 

Fix Quality To assess rework. 

Defect Density To assess defects per product size. 

Schedule To identify root causes for schedule slippage 

and work under-estimates. 

Project Metrics Cost To identify cost variance and task allocation. 

Productivity To assess productivity and task reallocation. 

Scope 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 Team’s strategy is to follow the steps below:

Page 36 of 60 




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 Team’s Metric Program. 

3. PM and technical leads analyze risks, determine resolution, and implement resolution. 

4. PM and technical leads provide follow-ups on risk’s resolution results. 

5.5. Closeout Plan 

The TMT aims to complete the project 2 week earlier than the assigned deadline (i.e., 12-Dec- 

2010). 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. Requirements. 

2. Designs. 

3. Test Results. 

4. Code/Product Demo. 

5. Development Status.

6.1. Process Model 

6. TECHNICAL PROCESS PLANS 

Page 37 of 60 




27-Sep-2010 

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: 

Initial Development 

Increment # 1 

. . . 

Increment # 12 

Activity Output/Artifact 

Planning 

Requirements 

Design 

Code 

Test 

Install/Support 

Status Report 

Documents, 

Reviews 

Documents, 

Reviews 

Documents, 

Reviews 

Documents, 

Reviews 

Documents, 

Reviews 

Documents, 

Reviews 

Documents, 

Reviews 

SDSR 

SUM 

STD & STR 

SVD & Demo 

Figure 6.1-1: TMT Software Development Life Cycle (SDLC) 

SDD 

SRS 

SPMP & STP 

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. A complete project plans (=> SPMP & STP). 

2. Requirements specification for the overall system framework => SRS). 

3. Overall system architectural and high-level component designs (=> SDD). 

4. Source codes for the system architecture and framework (=> SVD). 

5. Test cases, procedures, and results for the framework (=> STD & STR). 

6. A draft installation and user manual (=> SUM). 

7. A draft development status report (=> SDSR). 

Source code listing and versions 

Software user manual 

Reports the overall development status 

Test procedures and results as planned

Page 38 of 60 




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: 

6.2.2. Design Models 

Figure 6.2-1: TMT Requirements Process Flow 

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:

Table 6.2-1: TMT Programming Languages 

Page 39 of 60 




27-Sep-2010 

Language Version Description 

C# 4.0 Used to implement business rules and data access logics. 

ASP.NET 4.0 Used to implement web-based user interfaces. 

T-SQL 2008 Used to implement database stored procedures, functions, 

and database queries. 

HTML 4.0 Used in parallel with ASP.NET to implement web pages. 

CSS 2.0 Used to control user interface looks and feel. 

JavaScript 1.1 Used to implement client-side codes. 

Silverlight 2.0 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 Version Description 

MS Visual Studio 2010 Pro An Integrated Development Environment (IDE) used for 

development and software builds. 

MS SQL Server 2008 Pro A RDBM system used to develop and test the database 

scripts, stored procedures, and user-defined functions. 

Microsoft Office 2007 Pro i.e., Word, Excel, Visio, Power Point, and Outlook used for 

documents, metrics, designs, presentations, and 

communication respectively. 

MS IE Browser 7.0 Used to test the system. 

MS Firefox 8.0 Used to test the system. 

Project Manager 2010 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 40 of 60 




27-Sep-2010

7. SUPPORTING PROCESS PLANS 

7.1. Configuration Management Plan 

Page 41 of 60 




27-Sep-2010 

All software artifacts generated by the TMT Team need to be uploaded to the Team’s 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.

7.3. Documentation Plan 

Page 42 of 60 




27-Sep-2010 

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 Estimated 

Page 

Count 

Review Type 

Project Management Plan 50 Peer Review 

Test Plan 50 Peer Review 

Requirements Specification 50 Walkthrough 

Design Descriptions 50 Walkthrough 

Test Descriptions 50 Peer Review 

Test Report 50 Peer Review 

Version Description 50 Peer Review 

Development Status Report 50 Peer Review 

User Manual 50 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 43 of 60 




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. 

Author 

Notifies 

Completes 

Updates 

Project Manager 

Work Product 

Find defects 

Initiates review 

Moderates & closes review 

Figure 7.4-2: Walkthrough Review Process 

Reviewers 

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 Work Product Type of Review Purpose 

Documentation SPMP Peer Review To agree and follow the plans

Page 44 of 60 




27-Sep-2010 

Product Type Work Product Type of Review Purpose 

and established processes. 

Requirements SRS Walkthrough See appendix A. 

Test STP Peer Review See appendix D. 

Design SDD Walkthrough See appendix B. 

Code Source Code Peer Review See appendix C. 

Test STD Peer Review See appendix D. 

Test STR Peer Review See appendix D. 

Documentation SVD Peer Review To assure that all source codes 

produced properly listed. 

Documentation SDSR Peer Review To assure that the report 

properly reflect the development 

statuses. 

Documentation SUM Peer Review 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.

There are no other addition plans. 

8. ADDITIONAL PLANS 

Page 45 of 60 




27-Sep-2010


Page 46 of 60 




27-Sep-2010

APPENDIXES 

Appendix A: Requirements Review Checklist 

Page 47 of 60 




27-Sep-2010 

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?

Appendix B: Design Review Checklist 

Page 48 of 60 




27-Sep-2010 


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? 


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 

tool’s 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?

Appendix C: Code Review Checklist 

Page 49 of 60 




27-Sep-2010 


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 

tool’s syntactic and semantic checks? 

Does it compile cleanly? 


 

 

 

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?

Appendix D: Test Review Checklist 

Page 50 of 60 




27-Sep-2010 


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?

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 




27-Sep-2010

Appendix F: Review Kickoff Form 

Use this form to kick off a new review. 

Review type: 



Author: 

Moderator: 

Reviewers: 

Date: 

Purpose: 

File names: 

Page 52 of 60 




27-Sep-2010

Appendix G: Review Closeout Form 

Use this form to close out a review. 

Review type: 



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 




27-Sep-2010

Appendix H: Defect Resolution Form 

Use this form to record resolution for findings. 

Review type: 



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 




27-Sep-2010

Appendix I: Data Collection Point 

Code Data Collection Point 

1 Phase - Business Acquisition and Planning 

1a Activity - Supply Process 

2 Phase - Requirements 

2a Activity - System Requirements Analysis 

2b Activity - System Architectural Design 

2c Activity - Software Requirements Analysis 

2c1 Informal Software Requirements 

2c2 Formal Software Requirements 

3 Phase - Design 

3a Activity - Software Architectural Design 

3b Activity - Detailed Design 

3b1 Detailed Design Informal 

3b2 Detailed Design Formal 

4 Phase - Implementation 

4a Activity - Software Coding and Testing 

4a1 Software Coding Informal 

4a2 Software Coding Formal 

5 Phase - Integration and Test 

5a Activity - Software Integration 

5a1 Documentation 

5b Activity - Software Qualification Testing 

5c Activity - System Integration 

5d Activity - System Qualification Testing 

6 Phase - Transition to Customer 

6a Activity - Software Installation 

6b Activity - Software Acceptance Support 

7 External to the Software Product 

Page 55 of 60 




27-Sep-2010

Appendix K: Defect Severity Levels 

Page 56 of 60 




27-Sep-2010 

Code Defect Description Level 

0 No defect found or comment. None 

1 Prevents the accomplishment of an operational or mission 

essential capability 

Major 

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. 

2 Adversely affects the accomplishment of an operational or 

mission essential capability and no work-around solution is 

known 

Major 

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. 

3 Adversely affects the accomplishment of an operational or 

mission essential capability, but a work-around solution is 

known 

Major 

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. 

4 Results in user/operator inconvenience or annoyance, but does 

not affect a required operational or mission essential capability 

Minor 

Results in inconvenience or annoyance for development or 

support personnel, but does not prevent the accomplishment of 

those responsibilities. This is a MINOR defect. 

5 Any other effect not described above. Projects may define and 

assign sub-codes for this priority. This is a MINOR defect. 

Minor

Appendix L: Defect Types 

Page 57 of 60 




27-Sep-2010 

Code Defect Type Description 

1a Functionality The definition of a functional capability desired by 

the customer was not clear and unambiguous, or 

was misinterpreted. 

1b GFE/BFE/CFE/Subcontractor 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. 

1c Software Engineering 

Environment (SEE) 

The SEE, as specified, is deficient in supporting the 

software engineering process; incompatibilities 

exist between SEE tools. 

1d Programmatic Requirements Conflicting contractual requirements; problems 

relating to security requirements; problems 

relating to teaming with other companies. 

1e Test 

The test equipment/environment, as specified, is 

Equipment/Environment deficient to support system operation. 

1f Support 

The support equipment/environment, as specified, 

Equipment/Environment is deficient to support system operation. 

1z Documentation Documentation does not accurately/adequately 

describe the planning, and categories 1a through 

1f are not appropriate. 

2a Subsystem/Software 

Requirements 

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. 

2b Physical Interface An error in the definition or specification of a 

physical (hardware) interface. 

2c Functional 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. 

2d User Interface Incorrect/incomplete specification of the software 

interaction with the user. 

2e System Requirements 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. 

2z Documentation 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. 

3a Physical Interface Incorrect/incomplete design of the software 

interaction with hardware.

Page 58 of 60 




27-Sep-2010 


3b Subsystem Interface Incorrect/incomplete design of the functional 

interaction or communication of data with other 

subsystems or processes, and categories 3a and 3c 

are not appropriate. 

3c User Interface Incorrect/incomplete design of the software 

interaction with the user. 

3d Inter-process 

Communication 

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. 

3e Data Definition Incorrect/incomplete design of the data structures 

to be used in the product, e.g., defects associated 

with data precision/accuracy and data units. 

3f Unit/Procedure Design 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. 

3g Error Handling The checks for error detection/isolation were not 

adequate, or the response to detected error 

conditions was not correct. 

3h Standards Violations of design standards that do not cause a 

defect in the functional operation of the product. 

This does not include documentation standards. 

3i Traceability 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 



4a Logic 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. 

4b Computations Incorrect/incomplete mathematical or arithmetic 

operations cause the product not to implement the 

full intent of the design. 

4c Data Handling 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. 

4d Unit Interface Problems related to the calling, parameter

Page 59 of 60 




27-Sep-2010 


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. 

4e Standards Violations of programming standards, incorrect use 

of the programming language, typographical errors 

during code/text entry for source code and test 

procedures, etc. 

4f Build/Configuration 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. 

5z Documentation 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. 

6z Documentation 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. 

7a GFE/BFE A problem caused by GFE/BFE not operating in 

accordance with its specification. 

7b CFE/Subcontractor 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. 

7c SEE 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. 

7d Other Other external problem, and no other external 

category is appropriate. This does not include 

internally maintained reused assets. 

7e Test The product under test is operating correctly, yet

Page 60 of 60 




27-Sep-2010 


Equipment/Environment the test equipment/environment is operating 

incorrectly. This does not include internally 


7f Support 

Equipment/Environment 

The product under test is operating correctly, yet 

the support equipment/environment is operating 

incorrectly. This does not include internally 


0 Comment This Finding is only a comment and does not 

document a defect or a candidate for a defect.

Software Project Management Plan (SPMP) - Southern Polytechnic ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?