NASA Test and Evaluation Master Plan

SDM 5004 System Engineering and Project Management
Multi-satellite Operations Control Center (MSOCC)

Communications Switching System (MCSS)
Test and Evaluation Master Plan (TEMP)
Revision 01
(SDM5004-TEMP-MSOCC-0000)
May 2011
Division of Engineering & Technology Management (D-ETM)

National University of Singapore
Faculty of Engineering
Block EA, #05-34 (Building EA, Level 5, Room 34)
9 Engineering Drive 1
Singapore 117576
SDM5004-TEMP-MSOCC-0000 REV 01
WBS: 00
SDM 5004 System Engineering and Project Management
MULTI-SATELLITE OPERATIONS CONTROL CENTER (MSOCC)

COMMUNICATIONS SWITCHING SYSTEM (MCSS)
TEST AND EVALUATION MASTER PLAN (TEMP)
Revision 01
May 2011
Submitted by:
02 May 2011 A0000660B
Aditya Nugroho Date Matriculation Number

Project Manager
Approved by:
May 2011
Dr. Joseph E. Kasser Date

Director Operational Test
and Evaluation
ii
RECORD OF CHANGES
*A - ADDED M - MODIFIED D – DELETED
NUMBER OF
A*
VERSION FIGURE, TABLE TITLE OR BRIEF
DATE M AUTHOR
NUMBER OR DESCRIPTION
D
PARAGRAPH
00 18.04.2011 TEMP Paragraph M Knowledge component in the Dr. Joseph E.

D TEMP shall appear in the Kasser
footnotes.
iii
REQUIREMENT TRACEABILITY MATRIX
ID SUMMARY OF REQUIREMENT TYPE SECTION
An introduction to Project Management and

01 Written Section 4 Page 17
Systems Engineering
02 Modern project management Written Section 4 Page 17
03 Project Selection and Strategy Written Section 3 Page 11
04 Project Organisation Written Section 3 Page 8
05 Project Planning Written Section 4 Page 17
06 Scheduling Written Section 4 Page 20
07 Cost Estimating Written Section 4 Page 30
09 Performance Monitoring Written Section 4 Page 35
10 Project Leadership Written Section 3 Page 11
Section 3 Page 12
11 Project Teams Written
Section 4 Page 39
12 Constraint Management Written Section 4 Page 40
14 Project Audit and Closeout Written Section 4 Page 43
Lessons Learned Written Section 5 Page 46
Footnotes the knowledge component Written Appropriate Section
iv
Table of Contents
RECORD OF CHANGES ............................................................................................................. III

REQUIREMENT TRACEABILITY MATRIX ........................................................................... IV
1. INTRODUCTION ................................................................................................................. 1
1.1 Purpose ............................................................................................................................. 1
1.2 Scope ................................................................................................................................ 1
1.3 Assumptions ..................................................................................................................... 1
1.4 References ........................................................................................................................ 2
1.5 Definitions ........................................................................................................................ 3
2. DESCRIPTION ..................................................................................................................... 4
2.1 MCSS Mission Description .............................................................................................. 4
2.2 MCSS System Description ............................................................................................... 4
3. PROGRAM SUMMARY ..................................................................................................... 6
3.1 Test and Evaluation Objectives ........................................................................................ 6
3.2 Test and Evaluation Methodology ................................................................................... 7
3.3 Management Organization and Responsibilities .............................................................. 8
3.3.1 External Interfaces..................................................................................................... 8
3.3.2 Internal Interfaces ...................................................................................................... 9
3.3.3 Project Team Roles and Responsibilities ................................................................ 11
3.3.4 Documentation ........................................................................................................ 13
3.4 Resources Summary ....................................................................................................... 14
3.4.1 Integrated Test Master Schedule and Budget Summary ......................................... 14
3.4.2 Staff Resource Summary ......................................................................................... 15
3.5 Test Location and Equipment ........................................................................................ 16
4. TEST AND EVALUATION PROCESS PLAN................................................................ 17
4.1 Work Planning................................................................................................................ 17
4.1.1 Test and Evaluation Work Breakdown Structure (WBS) ....................................... 17
4.1.2 T&E Schedule Allocation Plan ............................................................................... 20
4.1.3 T&E Staff Resources Allocation Plan ..................................................................... 27
4.1.4 Budget Allocation Plan ........................................................................................... 30
4.2 Test and Evaluation Control Plan................................................................................... 35
4.2.1 Budget and Schedule Control .................................................................................. 36
4.2.2 Quality Control ........................................................................................................ 37
4.2.3 Reporting and Communication ............................................................................... 39
4.3 Risk Management Plan................................................................................................... 40
4.3.1 Risk Identification ................................................................................................... 40
4.3.2 Risk Mitigation........................................................................................................ 40
4.4 Project Closeout Plan ..................................................................................................... 43
4.4.1 Post Performance Analysis...................................................................................... 43
4.4.2 Project Closeout Schedule Allocation ..................................................................... 43
4.4.3 Project Closeout Critical Path ................................................................................. 43
4.4.4 Project Closeout Resource Allocation..................................................................... 44
4.4.5 Project Closeout Budget Allocation ........................................................................ 45
v
5. LESSON LEARNED........................................................................................................... 46
6. BIBLIOGRAPHY ............................................................................................................... 48
7. APPENDIX 1. WORK PACKAGES DESCRIPTION .................................................... 50
APPENDIX A: PRELIMINARY DESIGN (SRR-PDR) .............................................................. 50
APPENDIX B: DETAILED DESIGN (PDR-IRR) ...................................................................... 60
APPENDIX C: DEVELOPMENT AND INTEGRATION (IRR-TRR)....................................... 71
APPENDIX D: QUALIFICATION AND INSTALLATION (TRR-DRR) ................................. 82
APPENDIX E: PROJECT CLOSEOUT ....................................................................................... 92
8. APPENDIX 2. RISKS FACTORS CATEGORIZATION............................................... 98
vi
List of Tables and Figures
Table 1. 1 T&E Assumptions .......................................................................................................... 1

Table 1. 2 Document Reference ...................................................................................................... 2
Table 3. 1 Requirements Verification Matrix ................................................................................. 6

Table 3. 2 T&E Document Deliverables ......................................................................................... 7
Table 3. 3 Roles and Responsibilities of organization team for T&E activities ........................... 12
Table 3. 4 Basic rate of project team cost ..................................................................................... 13
Table 3. 5 T&E Documentation .................................................................................................... 13
Table 3. 6 Total budget allocations ............................................................................................... 14
Table 3. 7 Staff allocations per development phase ...................................................................... 15
Table 4. 1 WBS Dictionary of T&E activities .............................................................................. 19

Table 4. 2 Budget allocation Preliminary Design Phase ............................................................... 31
Table 4. 3 Budget allocation Detailed Design Phase .................................................................... 32
Table 4. 4 Budget allocation Detailed Design Phase .................................................................... 33
Table 4. 5 Budget allocation Qualification and Installation Phase ............................................... 34
Table 4. 6 T&E Management Control System .............................................................................. 36
Table 4. 7 Sub lower level work packages budget and schedule control ...................................... 37
Table 4. 8 Work packages depict the quality control process ....................................................... 38
Table 4. 9 Communication matrix................................................................................................. 39
Table 4. 10 Work packages of risk management plan .................................................................. 40
Table 4. 11 SRR-PDR Initial Risk Identification and Mitigation ................................................. 41
Table 4. 12 PDR-IRR Initial Risk Identification and Mitigation .................................................. 41
Table 4. 13 IRR-TRR Initial Risk Identification and Mitigation .................................................. 42
Table 4. 14 TRR-DRR Initial Risk Identification and Mitigation ................................................ 42
Table 4. 15 Budget allocation Project Closeout Phase.................................................................. 45
Figure 2. 1 Switch configuration ..................................................................................................... 4
Figure 3. 1 MCSS T&E Vee Model ................................................................................................ 8

Figure 3. 2 MCSSRP External Interfaces........................................................................................ 9
Figure 3. 3 MCSSRP Matrix Organization Structure ................................................................... 10
Figure 3. 4 MCSSRP Organization Structure ............................................................................... 10
Figure 3. 5 Integrated T&E Master Schedule ............................................................................... 14
Figure 3. 6 Summary T&E Manpower Cost ................................................................................. 15
Figure 4. 1 Work Breakdown Structure for T&E activities .......................................................... 18

Figure 4. 2 Preliminary Design T&E schedule ............................................................................. 20
Figure 4. 3 Detailed Design T&E schedule................................................................................... 21
Figure 4. 4 Development and Integration T&E schedule.............................................................. 21
Figure 4. 5 Qualification and Installation T&E schedule.............................................................. 22
Figure 4. 6 PERT-CPM Preliminary Design. ................................................................................ 23
Figure 4. 7 PERT-CPM Detailed Design ...................................................................................... 24
Figure 4. 8 PERT-CPM Development and Integration ................................................................. 25
vii
Figure 4. 9 PERT-CPM Qualification and Installation ................................................................. 26
Figure 4. 10 Resource allocation Preliminary Design Phase ........................................................ 27
Figure 4. 11 Resource allocation Detailed Design Phase.............................................................. 28
Figure 4. 12 Resource allocation Development and Integration Phase......................................... 29
Figure 4. 13 Resource allocation Qualification and Installation Phase......................................... 30
Figure 4. 14 Budget accumulative Preliminary Design Phase ...................................................... 32
Figure 4. 15 Budget accumulative Detailed Design Phase ........................................................... 33
Figure 4. 16 Budget accumulative Development and Integration Phase ...................................... 34
Figure 4. 17 Budget accumulative Qualification and Installation Phase ...................................... 35
Figure 4. 18 Project closeout schedule .......................................................................................... 43
Figure 4. 19 PERT-CPM Project Closeout Phase ......................................................................... 44
Figure 4. 20 Resource allocation of Project Closeout Phase......................................................... 44
Figure 4. 21 Budget accumulative Project Closeout Phase ........................................................... 45
viii
1. INTRODUCTION
1.1 Purpose
Test and Evaluation Master Plan (TEMP) describes the program Test and Evaluation (T&E)
objectives, requirements, general methodology (test flow and description of each T&E phase),
responsibilities, and scheduling of test phases for the the Multi Satellite Operations Control
Center (MSOCC) Communications Switching System (MCSS) switch upgrade. This TEMP is
a program-level management planning document for all MCSS T&E activities and as a guide
for developing T&E plans. In the MCSS Systems Engineering Management Plan (SEMP) that
is described the TEMP is subordinate to the program SEMP1.
1.2 Scope
The process described in this TEMP applies to engineering activities associated with the
design, development, and operation of the MCSS over the life cycle of the program. These
activities include the testing of manufactured items. Activities related to items on the T&E
activities will comply with requirements specified in the MCSS System Requirements
Document (SRD) Section 5. Test and evaluation plans which specify actions to be taken in
implementing test and evaluation at the project level, will be prepared by project manager.
1.3 Assumptions
This section lists assumptions that are specific to the test planning.
Table 1. 1 T&E Assumptions
Assumptions ID Description
T&E BA.01 • The project manager will be responsible for reviewing all
Budgeting BA.02 cost/budget changes for this project.
• Sufficient capital will be available to fund the MCSSRP.
1
Test and evaluation is an integral part of the systems engineering process. Key aspects of the systems
engineering process, more fully described in the SEMP, are discussed in this TEMP to illustrate how T&E
supports the overall systems engineering process. Bell, David.W and Brown, David.C. Systems Engineering and
Test and Evaluation—The Integrated Process. ITEA Journal 2010; 31: 57–62
1
T&E TA.01 • The critical path method (CPM) schedule and milestone list that
Schedule TA.02 details the timeframes and deadlines for the completion of T&E
TA.03 activities are given based on fixed time estimation.
• No resource limitations for T&E (i.e, resource personnel) and all the
resources currently available for this project.
• The project will be conducted with resources from a matrixed
organization structure.
T&E Staff SA.01 • Personnel will be properly trained on the tools and techniques
SA.02 needed to support this effort.
• Upon completion of each T&E activities in project phase, staff will
transition to the next phase of the project, return to their previous
work on a full time basis.
Testing QA.01 • Testing environments will be stable during execute the system test
QA.02 • Users will commit adequate resources to User Acceptance Testing
1.4 References
This section lists all the documents referenced in the TEMP.
Table 1. 2 Document Reference
Doc
Document Name
No
An Enhanced Framework for the Management of Information Technology Projects, PPTO-
1 TM-002 Project Plan Template, Chief Information Officer Branch, Treasury Board of
Canada Secretariat January 2000.
2 MSOCC MCSS Systems Engineering Management Plan (SEMP). Presented in Session 8.
Defence Acquisition University Press. Test and Evaluation Management Guide 5th Edition.
3
FORT BELVOIR, VA, January 2005.
NASA/GSFC, Multi-Satellite Operations Control Center (MSOCC) Communications

4
Switching System (MCSS) System Requirements Document, 511-4SRD/0489.
Processes for Engineering a System, Electronic Industries Alliance (EIA) Standard 632,
5
ANSI/EIA-632-1998.
Systems Engineering – System Life Cycle Processes, International Organization for

6 Standardization (ISO)/International Electrotechnical Commission (IEC) 15288, ISO/IEC
15288:2002
2
1.5 Definitions
This section contains definitions for any specific terminology or acronyms used in this plan.
ACRONYM DESCRIPTION
CI Configuration Item
COTS Commercially available Off-The-Shelf
DOD Department of Defense
DRR Delivery Readiness Review
GSFC Goddard Space Flight Center
IRR Implementation Readiness Review
ISO International Organization for Standardization
MCSS MSOCC Communications Switching System
MCSSRP MCSS Replacement Project
MSOCC Multi Satellite Operations Control Center
NASCOM NASA Communications Network
NASA National Aeronautics and Space Administration
PDR Preliminary Design Review
PM Project Manager
QA Quality Assurance
RAM Reliability, Availability and Maintainability
SEMP System Engineering Management Plan
SOW Statement Of Work
SRD System Requirement Document
SRR System Requirement Review
T&E Test and Evaluation
TEMP Test and Evaluation Master Plan
TRR Test Readiness Review
V&V Verification and Validation
3
2. DESCRIPTION
2.1 MCSS Mission Description
The MSOCC uses a switching system to route special synchronous RS-422-A type digital
data within the MSOCC and between the National Aeronautics and Space Administration
(NASA) Communications Network (Nascom) and the computer equipment within MSOCC.
The mission is to replace the data switch that routed signals from multiple low earth orbit
(LEO) satellites to data processing computers without loss of LEO satellite scientific data2.
2.2 MCSS System Description
The need were recognized for a single switch to replace the three existing switches with at
least twice the capability of the three switches combined. The switch will be controlled by the
DOCS, will handle data at rates of up to 6.312 Mbps, and will have a capacity of 255 full-
duplex connections (see Figure 2.1). The new switch system will henceforth be referred to as
MCSS. The MCSS function requirements are grouped into 4 subsystems which are:
1) Switch Matrix
2) Switch Control
3) Timing Generator and
4) Test And Monitoring.
Replace
Figure 2. 1 Switch configuration
2
Kasser, J. E. and Mirchandani, C. J., ―The MSOCC Data Switch Replacement: A Case Study in Elicitating and
Elucidating Requirements‖, proceedings of the 15th International Symposium of the International Council on
Systems Engineering (INCOSE), Rochester, NY, 2005. Page 2-3
4
From the result of the preliminary discussions with potential switch vendors have shown that
many of the MCSS requirements can be met by COTS switch available in the market. The
requirements not met by the purchase would be taken care of by inhouse development.
Therefore, the decision is to purchase a standard industry switch which will be modified to
meet the design requirements. The Timing Generator subsystem and Test and Monitoring
subsystem will be developed in-house.
5
3. PROGRAM SUMMARY
3.1 Test and Evaluation Objectives
Test and evaluation is an integral part of the systems engineering process that is used to attain
system objectives. T&E objectives have been derived to support the systems engineering
process. Two general objectives of the T&E program for MCSS are:
(1) to support system design and development, and
(2) to verify compliance with requirements3.
To ensure conformance with requirements contained in the System Requirements Documents

(SRD), following Table 3.1 described the example of Requirements Verification Matrix for
each subsystems to be performed during test execution.
Table 3. 1 Requirements Verification Matrix
WBS
Req No Description Priority
Reference
5.2 SWITCH MATRIX

5.2.1 The MCSS shall contain 255 ports
5.2.2 The MCSS shall switch binary digital signals
High Q101, Q201
5.2.3 The MCSS shall switch serial signals
5.2.4 This subsystem shall switch Data and Timing as signal pairs
5.3 SWITCH CONTROL
5.3.1 This subsystem shall be the MCSS operator’s control interface
This subsystem shall require the use of passwords to control, assign or
5.3.2
modify switch connections.
High Q301
5.3.3 This subsystem shall perform a self test on the MCSS upon power up
This subsystem shall provide the capacity to allow the control interface to
5.3.4
select the active switch control unit
5.4 TIMING GENERATOR
This subsystem shall contain identical primary and backup Terminal Timing
5.4.1
signal generators
High Q302
This subsystem shall distribute Terminal Timing signals to a minimum of
5.4.2
255 ports
5.5 TEST AND MONITORING
5.5.1 This subsystem shall not affect the signals being monitored
5.5.2 This subsystem shall contain at least 10 NBG’s High Q303
The NGB shall be able to generate predefined valid Nascom blocks at the
5.5.3
timing frequencies identified
3
In the MCSS T&E integration, verification and validation will takes place over the systems engineering
lifecycle to show that the systems meets the objectives of each phase are satisfied. INCOSE., ―System
Engineering Handbook Version 2.0‖, Seattle, 2000
6
3.2 Test and Evaluation Methodology
The approach used to conduct T&E is based on achieving the T&E objectives described
above.Test approach defined in the MCSS SRD will involve Development Team and
Transition Team. Operations personnel, the Development Team and Transition Team will be
involved in testing the MCSS at MSOCC.
Test procedures will develop to perform the test in four categories; factory acceptance test,
site acceptance test, integration acceptance test and final acceptance test. Thus, each of T&E
activity will deliver the documents as described in Table 3.2.
Table 3. 2 T&E Document Deliverables
Phase ID Document Deliverables Due Date
Preliminary
F100 Test Plan Document 31 January 2011
Design
Detailed 28 February
F200 Test Procedures Document
Design 2011
Development
F300 Final Subsystem Test Report 30 March 2011
and Integration
Qualification Final Test Acceptance Report Document

F400 30 April 2011
and Installation (Verification and Validation)
Closeout F500 Project Final Report 14 May 2011
MCSS T&E will start from the subsystems development until the subystem installation is
replace the current MSOCC switching system. The T&E activity except the Purchased Switch
Test is interdependence and can be illustrated by using a Vee model4 in the project lifecycle
as described in Figure 3.1.
As we bought the COTS Industry Switch from the market, those purchase switch should have
immediately test for immediate feedback result and will be served as independent testing. The
4
The Vee model illustrate here is only for the purpose the interdependence testing; not all of the phases in the
Vee-model (especially validation phase) according to the MCSS System Engineering Management Plan would
be partof this document. Vee model was adapted from 1204 Test and Evaluation lecture notes and modified for
MCSS from Forsberg, K., Mooz, H. and Cotterman, H., Visualising Project Management, John Wiley & Sons,
Inc., 3rd edition, 2005. Page 145
7
black box in the Vee model indicated that the phase is already tested in the beginning and will
not be incorporate in this TEMP.
Identify User Needs Demonstarate and

Requirement and Test Concept validate system Handover
specification Document Acceptance capability
Test Plan and
Procedure
Develop Test and Integrate system and
System Evaluation Master Plan verifify to performance Acceptance
specification specifications test
Integration
Test Plan and
Procedure
Expand performance Assemble configuration
Preliminary specifications into item and subsystem and Integration
design ―design-to‖ Subsystem perform verification Test
Subsystem
Test Plan and
Procedure
Evolve ―design-to‖ into Validate components
Detailed documentation and against ―build-to‖ Subsystem
design implementation plan documentation Test
Fabricate, Assemble
and Code to ―build-to‖
documentation
Figure 3. 1 MCSS T&E Vee Model
The Test Pass and Fail criteria for each T&E activity will be develop according to the MCSS
System Requirement Document in Section 4. This Test Pass and Fail criteria will be
explained more detail in the Test Plan work packages following IEEE 829-1998 Standard for
Software Test Documentation5.
3.3 Management Organization and Responsibilities
3.3.1 External Interfaces
This section describe the organizational between the project and external entities6.The
external interfaces for the MCSSRP project would be the members of the project committee
(Computer Sciences Corporation), MCSSRP project manager, Ford Aerospace
(subcontractor) and NASA Goddard Space Flight Center who is the stakeholder for this
project.
5
MCSS T&E Work Packages will adapted the Test Plan format which contain: How the testing will be done,
Who will do it, What will be tested, How long it will take and What the test coverage. IEEE 829-1998 Standard
for Software Test Documentation.
6
With identifying project external interfaces it would covers the significance of stakeholders to project success.
Forsberg, K., Mooz, H. and Cotterman, H., Visualising Project Management, John Wiley & Sons, Inc., 3rd
edition, 2005. Page 12
8
Project Sponsor –
CSC Exec. Mgt External
Vendor of Environment
MCSS
switches
Major
MCSSRP
Project stakeholder –
Manager NASA - GSFC
Sub-contractor -
Ford Aerospace
Project Team
Figure 3. 2 MCSSRP External Interfaces
3.3.2 Internal Interfaces
This section describe the internal structure of the MCSS T&E project organization to include
the interfaces among the units of the development team. The matrix organization7 will be use
to create succesful implementation of the T&E activities and provide efficient project
execution environment with emphasis on the functionality of each discipline8.
The organizational interfaces between the MCSS T&E project and organizational entities that
provide supporting processes, such as quality assurance, and verification and validation, will
be specified in support T&E and system engineering process. Organizational charts in Figure
3.3 and Figure 3.4 described the lines of authority, responsibility, and communication within
the project.
7
As MCCSRP is considered medium tech project with low risk involved, matrix organization would be
appropriate for describe the internal structure of the project. Shenhar, A. J. and Bonen, Z., ―The New Taxonomy
of Systems: Toward an Adaptive Systems Engineering Framework‖, IEEE Transactions on Systems, Man, and
Cybernetics – Part A: Systems and Humans, Vol. 27 (1997), no. 2, 137 – 145
8
Under the matrix organization, all project tasks in WBS are assigned to each discipline through work packages.
This is what we will applied in this TEMP. Ichiro Koshijima and Tomio Umeda. Human Resource Allocation in
Project Management. Management Science Approach.
http://www.sba.muohio.edu/abas/2001/brussels/Koshijima_Koshijima-Umeda.pdf
9
Executive
Management
Administrative
Office
Build &
MCSSRP Project Test & Evaluation Configuration Quality Assurance
Development
Manager Department Department Department
Department
MCSS System and

Development Team
MCSS Test and

Evaluation Team
MCSS
Configuration Team
MCSS Quality
Assurance Team
Figure 3. 3 MCSSRP Matrix Organization Structure
MCSSRP Project
Manager
MCSS System and MCSS Test and MCSS Quality Assurance

Development Team Evaluation Team Configuration Team Team
Requirements Configuration Item Quality Assurance

Librarian
Team Test Team Engineer
Integration Test
Design Team
Team
Implementation
Delivery Team
Team
• System engineer • System engineer

• CM Specialist
• Architecting eng
• Software eng • System eng
• Hardware eng • Senior Test
Engineer
• Test Engineer
• System eng
• Software eng • Logistic engineer
• Hardware eng
Figure 3. 4 MCSSRP Organization Structure
10
3.3.2.1 Project Manager (PM)9
1) Internal responsibilities:
a. Approve all cost and schedule-related planning documents.
b. Approve all organizational work and WBS.
c. Control of all organizational resources.
d. Monitor and report all project performance
e. Evaluate trade-offs prior to major decisions and approve any deviations to approved
plans.
f. Monitor and assure that all corrective actions are completed in the specified time.
2) External responsibilities: The PM is the principal point of contact for maintaining

liaison with the Computer Science Corporation, coordinating and supporting meetings,
conducting program reviews, approving all deliverables and managing all subcontractor
(Ford Aerospace) activity.
3.3.3 Project Team Roles and Responsibilities
This section identify the organizational units or project team that are responsible for T&E
processes and activities. The Maturity Model10 will be use for assessment of competency in
allocating the resources in each work activity. Next table describe the roles and
responsibilities and basic unit rate for each team organization who is responsibles for T&E
activities.
9
Project Manager has roles in three different arena; the customer’s, executive management’s, and the project
team’s. Project Manager is like a conductor of orchestra, providing the guidance for all project teams to achieve
common goal. Forsberg, K., Mooz, H. and Cotterman, H., Visualising Project Management, John Wiley & Sons,
Inc., 3rd edition, 2005. Page181 – 195.
10
The Maturity Model will helps to allocate the human resources more efficient in the MCSSRP project based
on assesment of Type of Engineers (Type I, Type II, Type III, Type IV, and Type V).Joseph E. Kasser and Moti
Frank, 2010. A Maturity Model for the Competency of Systems Engineers. Proceedings of the 20th International
Symposium of the INCOSE, Chicago, IL.
11
Table 3. 3 Roles and Responsibilities of organization team for T&E activities
Type of
Position Roles and Responsibilities Staff and Resources Code WBS Activities Status Organization Unit
Engineers
Provides testing management oversight.

Responsibilities: M101, M102, M201,
MCSSRP Project MCSSRP Project
Project Manager (R1) Type V M202, M301, M302, Full Time
Manager  provide technical direction Manager
M401, M402, M403
 acquire appropriate resources
 provide management reporting
An organizational team, responsible for CI
Q101, Q102, Q103,
and Integration T&E, who reports to the  System Engineer (R2)
 Type II Q104, Q201, Q202,
MCSS Test and Project Manager .  Senior System Engineer (R3) Full Time
Q203, Q204, Q205, Test and Evaluation
Evaluation (T&E)  Senior Test Engineer (R4)  Type III
Responsibilities: Q301, Q302, Q303, Part Time Department
Team  Test Engineer (R5)
 execute tests, log results  Type V Q304, Q305, Q401,
 Logistic Engineer (R6)
 recover from errors, document change Q402, Q403, Q404
requests
Configuration  System Engineer (R2)  Type III Q101, Q103, Q203, Configuration
Engineering staff responsible for CI Testing. Part Time
Item Test Team  Senior System Engineer (R3)  Type V Q205, Q302, Q303 Department
Engineering staff responsible for  Senior Test Engineer (R4)  Type V

Integration Test Test and Evaluation
CI/Hardware Configuration Item (HWCI) Q204, Q304, Q305 Full Time
Team  Test Engineer (R5)  Type III Department
Testing.
Engineering staff responsible for on-site  Test Engineer (R5)  Type III Q401, Q402, Q403, Full Time Test and Evaluation
Delivery Team
deliveries, training, and testing.  Logistic Engineer (R6)  Type II Q404 Part Time Department
An organizational team, responsible for QA

functions, that reports to the Project Q101, Q103, Q203,
Manager. Q205, Q302, Q303,
Quality Assurance Quality Assurance
QA Engineer (R7) Type III Q204, Q304, Q305, Full-Time
(QA) Team Responsibilities: Department
Q401, Q402, Q403,
 decide on the scope of the Q/A testing in
Q404
agreement with Project Manager
 verification and validation
Table 3. 4 Basic rate of project team cost
Resource Unit Rate/Day

Labor Category Type
Code (8 hours)
R1 Project Manager (R1) V $500

R2 System Engineer (R2) III $250
R3 Senior System Engineer (R3) V $350
R4 Senior Test Engineer (R4) V $350
R5 Test Engineer (R5) III $250
R6 Logistic Engineer (R6) II $200
R7 QA Engineer (R7) III $150
3.3.4 Documentation
The MCSS TEMP is the top-level test and evaluation planning document. Project manager
will be responsible for developing test and evaluation plan. Documents11 will be produced by
using microsoft word and spread sheet. Test and evaluation plan documents will identify the
following:
Table 3. 5 T&E Documentation
Documents Section
The methodology to be used for implementing test and evaluation. Section 3 Page 7
The organizational structure and responsibilities for implementing T&E. Section 3 Page 8
An integrated T&E schedule depicting major project milestones and T&E

Section 4 Page 17
activities in support of those milestones.
An basic work packages of each of the major T&E phases including

identification of the subsystem being tested, test objective, and scope of Appendix 1 Page 50-97
the test.
A summary of the T&E resources required for execution of the T&E

Section 3 Page 14-15
program.
Documentation to be developed and maintained, including traceability and

Section 3 Page 6
conformance verification matrices.
11
Good engineering documents are critical to the cost effectiveness of systems engineering. Reducing the cost of
preparing effective documents is an approach that applied in any organization and will reduce the cost of the
SDLC (systems development life cycle). Kasser, J. E., ―Improving the Systems Engineering Documentation
Production Process‖, proceedings of the 5th Annual International Symposium of the INCOSE, 1995, pages 6-9.
3.4 Resources Summary
This section provide a summary of the schedule, budget and staff resources for the T&E
activities.
3.4.1 Integrated Test Master Schedule and Budget Summary
Master Schedule as depicted in Figure 3.5. Budget allocations are contained in Table 3.6 and
Figure 3.5. The supporting Work Breakdown Structure (WBS), cost, schedule, and staffing
requirements for the each increment of the Master Schedule are contained in Section 4.
Week January February March April May

WBS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
SRR PDR IRR TRR DRR Closeout
100
200
300
400
500
Figure 3. 5 Integrated T&E Master Schedule
Table 3. 6 Total budget allocations
1 Labor Cost Unit Rate/Day Working Days Subtotal

Project Manager $500 52 $26,000
System Engineer $250 8 $2,000
Senior System Engineer $350 10 $3,500
Senior Test Engineer $350 12 $4,200
Test Engineer $250 88 $22,000
Logistic Engineer $200 3 $600
QA Engineer $150 44 $6,600
Total Labor Cost $64,900
2 Material Cost Features Quantity
Nascom Block Generator (NBG) MCSS 10 $10,000
Block Error Detector (BED) MCSS 10 $10,000
Oscilloscope MCSS 2 $14,800
Test Rigs Test and Monitoring 5 $5,000
288 Ports Switch Matrix Switch Matrix 1 $360,000
Total Material Cost $399,800
Total Budget $464,700
Fixed Fee Contract (10% ) $46,470
14
MCSS T&E Manpower Cost
$70,000
$60,000
$50,000
$40,000
$30,000
$20,000
$10,000
$0
Project
SRR-PDR PDR-IRR IRR-TRR TRR-DRR
Closeout
Cost $12,950 $12,800 $19,050 $15,100 $5,000
Cumulative Cost $12,950 $25,750 $44,800 $59,900 $64,900
Figure 3. 6 Summary T&E Manpower Cost
The T&E activities total budget cost is $464,700 and fixed fee contract $46,470
3.4.2 Staff Resource Summary
Required staffing allocations by development phase are defined in Table 3.7. The table
provides guidance for staff allocations for the overall T&E activities.
Table 3. 7 Staff allocations per development phase
Development Qualification
Preliminary Detailed
Labor Category and and Closeout
Design Design
Integration Installation
Project Manager 1 1 1 1 1
System Engineer 1 0 0 1 0
Senior System Engineer 1 1 1 1 0
Senior Test Engineer 1 3 0 0 0
Test Engineer 2 2 6 2 0
Logistic Engineer 0 0 0 1 0
QA Engineer 1 1 3 1 0
Subtotals 7 8 11 7 1
15
3.5 Test Location and Equipment
The T&E activity other than Site Acceptance Test will be performed in in–house
Development Lab. The Site Acceptance Test is done at the first delivered location (EDF). The
in-house Development Lab has a sufficient facility and equipment for running the required
Test. However some of the equipment is not available and purchased independently in System
Requirement Phase. The complete listing of the Equipment used in the MCSS T&E is given
below.
 Frequency counters, serial data analyzer, logic analyzer

 Oscilloscope
 Block Error Detector (BED)
 Nascom Block Generator (NBG)
 Test Rigs
 Software test programs
16
4. Test and Evaluation Process Plan
4.1 Work Planning
This section specify specify the work activities, schedule, resources, and budget details for the
MCSS T&E activities. Work packages for each work activity, necessary resources, estimated
duration, work products to be produced, acceptance criteria for the work products, and
predecessor and successor T&E work activities are contained in Appendix 1.
4.1.1 Test and Evaluation Work Breakdown Structure (WBS)
System Life Cycle Processes ISO/IEC 15288 would be adopted in support of WBS T&E
activities. Detail of the phases will describe in next section. The MCSS project phases after
SRR is divided into 5 phases, they are:
1) Preliminary Design (SRR-PDR)
2) Detailed Design (PDR-CDR)
3) Development and Integration (CDR-IRR)
4) Qualification and Installation (IRR-DRR)
5) Project close out phase
The WBS will use the Top-Down approach12 which identifies the needed tasks, resource
allocations, and cost estimates. Figure 4.1 described the WBS of T&E and coding scheme.
4.1.1.1 Work Breakdown Structure Dictionary
To better understand the nature of the work required to satisfy each element, a complete WBS
dictionary13 will be use in MCSS T&E activities. Table 4.1 described the WBS dictionary of
this project.
12
Top-Down approach of work breakdown structure (WBS) will be use to explained the test planning from the
highest level into the lowest level for each phase. By using WBS the Project Manager could identifying the
implications of WBS to budgeting, scheduling, risk assessment, and cost collection during planning of MCSS
T&E activities. Forsberg, K., Mooz, H. and Cotterman, H., Visualising Project Management, John Wiley &
Sons, Inc., 3rd edition, 2005.
13
By using WBS dictionary it will help clarify the distinctions between WBS elements. Practice Standard for
Work Breakdown Structures (Second Edition), published by the Project Management Institute, ISBN
1933890134, page 8
17
MCSS T&E
300 400
100 200 500
Development and Qualification and
Preliminary Design Detailed Design Project closeout
Integration Installation
Management Testing Management Testing Management Testing Management Testing Management
M201 Technical M301 Technical

M101-Technical Q101 Execute Q201 Execute Q401 Final MCSS
direction and direction and Q301 Execute M401 Handing over M501 Perform
direction and purchased switch modified switch subsystem
management management Switch Control test documentation client closeout
acquire resources test matrix test operational test
reporting reporting
M102-Risk Q102 Prepare Q202 Prepare Q302 Execute Q402 Final MCSS M502 Perform
M202 Risk M302 Risk M402 Risk
identification and modified switch modified Switch Timing Generator subsystem factory organizational
management management management
management matrix test plan Control test plan test acceptance test closeout
Q103 Prepare Q203 Prepare M403 Test and Q403 Final MCSS M503 Conduct
Q303 Execute Test
integration test plan Timing Generator Evaluation subsystem site subcontractor
and Monitoring test
and procedure test plan completion review acceptance test closeout
Q204 Prepare Test Q304 Finalize Q404 Final MCSS

Q104 Introductory M504 Write the
and Monitoring test whole subsystem subsystem customer
training project final report
plan integration test acceptance test
Q205 MCSS Q305 MCSS

M505 Conduct team
Subsystem design integration test
closeout
RAM analysis (verified)
Figure 4. 1 Work Breakdown Structure for T&E activities

Table 4. 1 WBS Dictionary of T&E activities
WBS ID Work Package Name Description Milestones

Technical direction and To facilitate a smooth running of T&E activities including required
M101 SRR-PDR
acquire resources resources at SRR-PDR
Risk identification and This element include how to identify and conduct risk management at
M102 SRR-PDR
management each T&E activities at SRR-PDR
Execute purchased Switch
Q101 To test whether Purchased Switch is meet the requirements MCSS SRD SRR-PDR
test
Prepare modified Swith
Q102 Planning the Modified Switch Matrix Test Plan SRR-PDR
Matrix test plan
Prepare integration test
Q103 To provide a MCSS integration test pland and procedure for the tester SRR-PDR
plan and procedure
Implement IntroductoryTo train the manpower who will performed in the T&E with the MCSS
Q104 SRR-PDR
training system to maintain the Test Quality
Technical direction and To facilitate a smooth running of T&E activities including management
M201 PDR-IRR
management reporting report at PDR-IRR
This element include how to conduct risk management at each T&E
M202 Risk management PDR-IRR
activities at PDR-IRR
Execute modified Switch To test whether the Modified Switch Matrix is meet the requirements in
Q201 PDR-IRR
Matrix test System requirements Document Section 5
Prepare modified Switch
Q202 Planning the Modified Switch Control Test Plan PDR-IRR
Control test plan
Prepare Timing Generator
Q203 Planning the Modified Timing Generator Test Plan PDR-IRR
test plan
Prepare Test and
Q204 Planning the Modified Test and Monitoring Test Plan PDR-IRR
Monitoring test plan
MCSS Subsystem RAM Assurance that design maturity is sufficient to begin detailed design and
Q205 PDR-IRR
analysis review the status including achieved results
Technical direction and To facilitate a smooth running of T&E activities including management
M301 IRR-TRR
management reporting report at IRR-TRR
M302 Risk management IRR-TRR
activities at IRR-TRR
To test whether the Modified Switch Control is meet the requirements in
Q301 Execute Switch Control test IRR-TRR
System requirements Document Section 5
Execute Timing Generator To test whether the Modified Timing Generator is meet the requirements
Q302 IRR-TRR
test in System requirements Document Section 5
Execute Test and To test whether the Modified Test and Monitoring Test is meet the
Q303 IRR-TRR
Monitoring test requirements in System requirements Document Section 5
Finalize whole subsystem
Q304 Combined 4 separate review subsystems integration test IRR-TRR
integration test
MCSS subsystem Verified combined 4 separate review subsystems integration test meet
Q305 IRR-TRR
integration test (verified) the requirements
Handing over The purpose of this document is to assist a smooth handover for the
M401 TRR-DRR
documentation customer
M402 Risk management TRR-DRR
activities at TRR-DRR
Test and Evaluation
M403 To review project completion and identify any lesson learnt TRR-DRR
completion review
A Factory Acceptance Test witnessed by the transition test to test
Final MCSS subsystem
Q401 whether each subsystems of the integrated MCSS is meet the requirement TRR-DRR
operational test
in SRD section 5 and can operate as expected by customer
Final MCSS subsystem Review the result of the test documented in the Factory Acceptance Test
Q402 TRR-DRR
factory acceptance test Report for verification and validation of the MCSS
Final MCSS subsystem site To ensure reliable performance of MCSS subsystem and minimum impact
Q403 TRR-DRR
acceptance test to the MSOCC
Final MCSS subsystem To test fully integrated MCSS after being installed but before Final
Q404 TRR-DRR
customer acceptance test Acceptance Test by NASA to be considered fully operational
4.1.2 T&E Schedule Allocation Plan
This section provide scheduling relationships among MCSS T&E work activities. Techniques
will be use for depicting schedule relationships in activities include activity Gantt charts,
critical path networks14, and PERT chart15. Bottom-Up approach16 will be use to estimate the
project time. Thus the schedule plan will follow one iteration of the Waterfall system and
system development lifecycle (SDLC) in T&E activities and fit within a timeline of 16 weeks.
Following section describe of the schedule plan fot each phase.
4.1.2.1 Preliminary Design (SRR-PDR)
The schedule for SRR-PDR phase will be start on 01 January 2011. This phase will cover the
technical direction for T&E activities, risk identification, test plans, resources and
introductory training.
Week 1 Week 2 Week 3 Week 4

TASK
ACTIVITY 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
ID
Technical direction and
M101
acquire resources
Risk identification and
M102
management
Execute purchased Switch
Q101
test
Q102
Matrix test plan
Q103
plan and procedure
Implement introductory
Q104
training
Figure 4. 2 Preliminary Design T&E schedule
14
A good project network is very useful to determine the critical path and slack time, and a good start to project
resource scheduling. Larson,Eriik W, and Gray,Clifford F.,Project Management, McGraw-Hill ., 5th Edition,
2011. Page 188
15
PERT chart can shows the dependencies between the various tasks and activities unlike Gantt Chart. Howard
Eisner, Essentials of Project and Systems Engineering Management, John Wiley & Sons, Inc., 2nd Edition,
2002, Page 91 - 122
16
The Bottom-up (micro) approach is suitable in MCSSRP project, where the cost and time is important
Larson,Eriik W, and Gray,Clifford F.,Project Management, McGraw-Hill ., 5th Edition, 2011. Page 188
20
4.1.2.2 Detailed Design (PDR-IRR)
The schedule for PDR-IRR phase will be start on 01 February 2011. This phase will cover the
management reporting (budget and schedule review), Reliability Avalilability and
Maintainability subsystem designs, test plan and procedures, and execute subsystem test.
TASK
ACTIVITY 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
ID
M201
management reporting
M202 Risk management
Execute modified Switch
Q201
Matrix test
Q202
Control test plan
Q203
test plan
Prepare Test and
Q204
MCSS Subsystem RAM
Q205
analysis
Figure 4. 3 Detailed Design T&E schedule
4.1.2.3 Development and Integration (IRR-TRR)
The schedule for PDR-IRR phase will be start on 01 March 2011. This phase will cover the
management reporting (budget and schedule review), risk management, final design, execute
susbystem test and verified subsystem integration test.
TASK
ACTIVITY 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
ID
M301
Execute Switch Control
Q301
test
Execute Timing Generator
Q302
test
Execute Test and
Q303
Monitoring test
Q304
integration test
MCSS subsystem
Q305
integration test (verified)
Figure 4. 4 Development and Integration T&E schedule
21
4.1.2.4 Qualification and Installation (TRR-DRR)
The schedule for PDR-IRR phase will be start on 01 April 2011. This phase will cover the
handing over documentation, risk management, final MCSS subystem test results and delivery
final MCSS subsystem to the customer.
TASK
ACTIVITY 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
ID
Handing over
M401
documentation
Test and Evaluation
M403
completion review
Q401
operational test
Q402
factory acceptance test
Q403
site acceptance test
Q404
customer acceptance test
Figure 4. 5 Qualification and Installation T&E schedule
22
4.1.2.5 Critical Path Preliminary Design (SRR-PDR)
The T&E Critical Path (CP) 17 during SRR-PDR phase is the longest path of the expected time of the T&E activity. The time metrics is a
week which is 5 working days. Critical Path for SRR-PDR phase = M101+Q101+Q1012+Q103+Q104 = 5+4+3+3+5 = 20 Days
Figure 4. 6 PERT-CPM Preliminary Design.
17
By using the Critical Path analysis, the Project Manager will easy to identify the minimum length of time needed to complete a project and reducing project risk.
Larson,Eriik W, and Gray,Clifford F.,Project Management, McGraw-Hill ., 5th Edition, 2011. Chapter 6-Developing Project Plan.
4.1.2.6 Critical Path Detailed Design (PDR-IRR)
The T&E Critical Path (CP) during PDR-IRR phase is the longest path of the expected time of the T&E activity. The time metrics is a week
which is 5 working days. Critical Path for PDR-IRR phase = M201+Q201+Q203+Q205 = 7+4+3+4 = 18 Days
Figure 4. 7 PERT-CPM Detailed Design
24
4.1.2.7 Critical Path Development and Integration (IRR-TRR)
The T&E Critical Path (CP) during SRR-PDR phase is the longest path of the expected time of the T&E activity. The time metrics is a
week which is 5 working days. Critical Path for IRR-TRR phase = M301+Q302+Q304+Q305 = 7+5+3+5 = 20 Days
Figure 4. 8 PERT-CPM Development and Integration
25
4.1.2.8 Critical Path Qualification and Installation (TRR-DRR)
The T&E Critical Path (CP) during SRR-PDR phase is the longest path of the expected time of the T&E activity. The time metrics is a
week which is 5 working days. Critical Path for TRR-DRR phase = M403+Q401+Q402+Q403 = 5+4+4+4 = 20 Days
Figure 4. 9 PERT-CPM Qualification and Installation
26
4.1.3 T&E Staff Resources Allocation Plan
This section provide a detailed itemization of the resources allocated to each major work
activity in the MCSS T&E work breakdown structure. Resources18 include the numbers and
required skill levels of personnel for each work activity. Required staffing allocations by
development phase are defined in the following section. The tables and figures represents
number of resource required to complete each work package. It shows the types of personnel
by Maturity Model and project roles.
4.1.3.1 Preliminary Design Phase (SRR-PDR)

TASK
ACTIVITY RES DUR ES LF TS 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
ID
M101 1 5 0 5 0 1 1 1 1 1
acquire resources
M102 1 2 0 2 0 1 1
management
Execute purchased
Q101 3 4 5 9 0 3 3 3 3
Switch test
Q102 1 3 9 12 0 1 1 1
Matrix test plan
Q103 1 3 12 15 0 1 1 1
plan and procedure
Implement Introductory
Q104 1 5 15 20 0 1 1 1 1 1
training
Total Resource Load 2 2 1 1 1 3 3 3 3 1 1 1 1 1 1 1 1 1 1 1
SRR-PDR Staff Allocation Engineers Type

4
QA Engineer (R7)
Logistic Engineer (R6)

3
Test Engineer (R5)
Senior Test Engineer (R4) 2
Senior System Engineer (R3)

1
System Engineer (R2)
Project Manager (R1)

0
0 1 2 3 I II III IV V
Figure 4. 10 Resource allocation Preliminary Design Phase
18
In this MCSS T&E activities, scheduling would allocates resources personnel to jobs (tasks) in order to
minimize total lateness. Project Management Institute A Guide to the Project Management Body of Knowledge,
Third Edition, 2004 Project Management Institute, Inc. ISBN 193069945X
4.1.3.2 Detailed Design Phase (PDR-IRR)

TASK
ID
M201 1 7 0 7 0 1 1 1 1 1 1 1
M202 Risk management 1 3 4 7 0 1 1 1
Execute modified Switch
Q201 3 5 7 12 0 3 3 3 3 3
Matrix test
Q202 1 3 12 15 0 1 1 1
Control test plan
Q203 1 3 12 15 0 1 1 1
test plan
Prepare Test and
Q204 1 3 12 15 0 1 1 1
MCSS Subsystem RAM
Q205 1 4 15 19 0 1 1 1 1
analysis
Total Resource Load 1 1 1 1 2 2 2 3 3 3 3 3 3 3 3 1 1 1 1
PDR-IRR Staff Allocation Engineers Type

6
QA Engineer (R7)
5
Logistic Engineer (R6)
Test Engineer (R5) 4
Senior System Engineer (R3) 2
System Engineer (R2)

1
0
0 1 2 3 4 I II III IV V
Figure 4. 11 Resource allocation Detailed Design Phase
28
4.1.3.3 Development and Integration Phase (IRR-TRR)

TASK
ID
M301 1 7 0 7 0 1 1 1 1 1 1 1
Execute Switch Control
Q301 3 5 7 12 0 3 3 3 3 3
test
Execute Timing Generator
Q302 3 5 7 12 0 3 3 3 3 3
test
Execute Test and
Q303 3 5 7 12 0 3 3 3 3 3
Monitoring test
Q304 1 3 12 15 0 1 1 1
integration test
MCSS subsystem
Q305 3 5 15 20 0 3 3 3 3 3
integration test (verified)
IRR-TRR Staff Allocation Engineers Type

10
QA Engineer (R7)
9
Logistic Engineer (R6) 8

7
Test Engineer (R5)
6
4
3
System Engineer (R2) 2
1
0
0 1 2 3 4 5 6 7 I II III IV V
Figure 4. 12 Resource allocation Development and Integration Phase
29

TASK
ID
Handing over
M401 1 3 0 3 0 1 1 1
documentation
Test and Evaluation
M403 1 5 0 5 0 1 1 1 1 1
completion review
Q401 3 4 5 9 0 3 3 3 3
operational test
Q402 3 4 9 13 0 3 3 3 3
factory acceptance test
Q403 3 4 13 17 0 3 3 3 3
site acceptance test
Q404 1 3 17 20 0 1 1 1
customer acceptance test
IRR-TRR Staff Allocation Engineers Type

10
QA Engineer (R7)
9
Logistic Engineer (R6) 8
7
Test Engineer (R5)
6
4
3
System Engineer (R2) 2
1
0
0 1 2 3 4 5 6 7 I II III IV V
Figure 4. 13 Resource allocation Qualification and Installation Phase
4.1.4 Budget Allocation Plan
This section provides a detailed breakdown of necessary resource budgets for each of the
major work activities in the work breakdown structure. The activity budget will estimated the
cost for activity personnel where the type of cost is price contract19. The estimating project
19
In this MCSS, as there is low risk involved (using mostly existing technology), the cost contract for personnel
could be awarded as a fixed price contracts. Howard Eisner, Essentials of Project and Systems Engineering
Management, John Wiley & Sons, Inc., 2nd Edition, 2002, Page 91 - 122
30
cost will use the Bottom-Up approach20 21. Required budget allocations by development phase
are defined in the following section.
4.1.4.1 Preliminary Design Phase (SRR-PDR)
Below is a listing work packages from SRR-PDR. The amount allocated for each is
determined by the daily rate (8 hours), and the number of people assigned to each work
package . Total manpower cost from is $12.950.
Table 4. 2 Budget allocation Preliminary Design Phase
Code Activities Description Manpower resources High level

Working Manpower Cumulative
Unit sub-total
100 Preliminary Design Phase Engineers Type Number days cost cost
Rate/day cost
M101 $6,000 $6,000
acquire resources
M101.1 Resources plan for T&E Project Manager Type V 1 $500 5 $2,500
M101.2 Cost and schedule plan Project Manager Type V 1 $500 5 $2,500
M101.3 Subsystem test direction Project Manager Type V 1 $500 2 $1,000
M102 Project Manager Type V 1 $500 2 $1,000 $1,000 $7,000
management
1) Test Engineer Type III 2 $250 4 $2,000
Q101 Execute purchased Switch test $2,600 $9,600
2) QA Engineer Type III 1 $150 4 $600
Prepare modified Swith Matrix Senior Test
Q102 Type V 1 $350 3 $1,050 $1,050 $10,650
test plan Engineer
Prepare integration test plan Senior System
Q103 Type V 1 $350 3 $1,050 $1,050 $11,700
and procedure Engineer
Implement Introductory
Q104 Systems Engineer Type III 1 $250 5 $1,250 $1,250 $12,950
training
Sub-total $12,950 $12,950
20
In the MCSSRP project, every phase or milestones have applied WBS packages. Which component of WBS
packages has contain, budget, schedule, resource. Bottom-Up approach can serve as a check on cost elements in
the WBS by rolling up the work packages and associated cost accounts to major deliverables at the work package
level. Larson,Eriik W, and Gray,Clifford F.,Project Management, McGraw-Hill ., 5th Edition, 2011. Chapter 5.
Page 126-155
21
In addition Bottom-Up approach could provide accurate estimate of the cost during product life cycle. Hari,
A., Shoval, S. and Kasser, J. E., ―Conceptual Design to Cost: A new systems engineering tool‖, proceedings of
the 18th International Symposium of the INCOSE, Utrecht, Holland, 2008.
31
Preliminary DesignPhase
$14,000
$12,000
$10,000
$8,000
$6,000
$4,000
$2,000
$0
M101 M102 Q101 Q102 Q103 Q104
High level sub-total cost $6,000 $1,000 $2,600 $1,050 $1,050 $1,250
Cumulative cost $6,000 $7,000 $9,600 $10,650 $11,700 $12,950
Figure 4. 14 Budget accumulative Preliminary Design Phase
4.1.4.2 Detailed Design Phase (PDR-IRR)
Below is a listing work packages from PDR-IRR. The amount allocated for each is
determined by the daily rate and the number of people assigned to each work package . Total
manpower cost is $12.800.
Table 4. 3 Budget allocation Detailed Design Phase

Unit sub-total
200 Detailed Design Phase Engineers Type Number days cost cost
Rate/day cost
M201 $3,500 $3,500
M201.1 Resource plan review Project Manager Type V 1 $500 3 $1,500
M201.2 Budget and schedule review Project Manager Type V 1 $500 2 $1,000
Subsystem integration test
M201.3 Project Manager Type V 1 $500 2 $1,000
direction
M202 Risk management Project Manager Type V 1 $500 3 $1,500 $1,500 $5,000
Execute modified Switch Matrix 1) Test Engineer Type III 2 $250 5 $2,500
Q201 $3,250 $8,250
test 2) QA Engineer Type III 1 $150 5 $750
Prepare modified Switch Senior Test
Q202 Type V 1 $350 3 $1,050 $1,050 $9,300
Control test plan Engineer
Prepare Timing Generator test Senior Test
Q203 Type V 1 $350 3 $1,050 $1,050 $10,350
plan Engineer
Prepare Test and Monitoring Senior Test
Q204 Type V 1 $350 3 $1,050 $1,050 $11,400
test plan Engineer
MCSS Subsystem RAM Senior System
Q205 Type V 1 $350 4 $1,400 $1,400 $12,800
analysis Engineer
Sub-total $12,800 $12,800
32
Detailed Design Phase
$14,000
$12,000
$10,000
$8,000
$6,000
$4,000
$2,000
$0
M201 M202 Q201 Q202 Q203 Q204 Q205
High level sub-total cost $3,500 $1,500 $3,250 $1,050 $1,050 $1,050 $1,400
Cumulative cost $3,500 $5,000 $8,250 $9,300 $10,350 $11,400 $12,800
Figure 4. 15 Budget accumulative Detailed Design Phase
4.1.4.3 Development and Integration Phase (IRR-TRR)
Below is a listing work packages from IRR-TRR. The amount allocated for each is
Table 4. 4 Budget allocation Detailed Design Phase

Development and Integration Unit sub-total
300 Engineers Type Number days cost cost
Phase Rate/day cost
M301 $3,500 $3,500
M301.1 Resource plan review Project Manager Type V 1 $500 3 $1,500
MCSS subsystem integration
M301.3 Project Manager Type V 1 $500 2 $1,000
test direction (verified)
Q301 Execute Switch Control test $3,250 $8,250
Q302 Execute Timing Generator test $3,250 $11,500
Execute Test and Monitoring 1) Test Engineer Type III 2 $250 5 $2,500
Q303 $3,250 $14,750
test 2) QA Engineer Type III 1 $150 5 $750
Prepare finalize whole
Senior System
Q304 subsystem integration test Type V 1 $350 3 $1,050 $1,050 $15,800
Engineer
procedure
MCSS subsystem integration 1) Test Engineer Type III 2 $250 5 $2,500
Q305 $3,250 $19,050
test (verified) 2) QA Engineer Type III 1 $150 5 $750
Sub-total $19,050 $19,050
33
Development and Integration Phase
$25,000
$20,000
$15,000
$10,000
$5,000
$0
M301 M302 Q301 Q302 Q303 Q304 Q305
High level sub-total cost $3,500 $1,500 $3,250 $3,250 $3,250 $1,050 $3,250
Cumulative cost $3,500 $5,000 $8,250 $11,500 $14,750 $15,800 $19,050
Figure 4. 16 Budget accumulative Development and Integration Phase
Below is a listing work packages from TRR-DRR. The amount allocated for each is
Table 4. 5 Budget allocation Qualification and Installation Phase

Qualification and Installation Unit sub-total
400 Engineers Type Number days cost cost
Phase Rate/day cost
M401 Handing over documentation System Engineer Type III 1 $250 3 $750 $750 $750
Test and Evaluation
M403 $2,500 $4,750
completion review
M403.2 Project completed review Project Manager Type V 1 $500 2 $1,000
Final MCSS subsystem 1) Test Engineer Type III 2 $250 4 $2,000
Q401 $2,600 $7,350
operational test 2) QA Engineer Type III 1 $150 4 $600
Final MCSS subsystem factory 1) Test Engineer Type III 2 $250 4 $2,000
Q402 $2,600 $9,950
acceptance test 2) QA Engineer Type III 1 $150 4 $600
Final MCSS subsystem site 1) Test Engineer Type III 2 $250 4 $2,000
Q403 $2,600 $12,550
acceptance test 2) QA Engineer Type III 1 $150 4 $600
Logistic Engineer Type II 1 $200 3 $600 $600 $13,150
Q404 1) Test Engineer Type III 2 $250 3 $1,500
customer acceptance test $1,950 $15,100
Sub-total $15,100 $15,100
34
Qualification and Installation Phase
$16,000
$14,000
$12,000
$10,000
$8,000
$6,000
$4,000
$2,000
$0
M401 M402 M403 Q401 Q402 Q403 Q404
High level sub-total cost $750 $1,500 $2,500 $2,600 $2,600 $2,600 $2,550
Cumulative cost $750 $2,250 $4,750 $7,350 $9,950 $12,550 $15,100
Figure 4. 17 Budget accumulative Qualification and Installation Phase
4.2 Test and Evaluation Control Plan
This section will specify the metrics, and control procedures necessary to measure the
requirements, schedule, budget, and the quality of work processes and work products22.
The control plan will place at each project milestones23. Project Manager, will develop
detailed plans based on established work assignments for T&E activities. The Management
Control System (MCS)24 tools will be used to document and track the work against major
program milestones. Table 4-6 identifies the primary tools that support T&E control plan.
22
The purpose of the Control function is to provide adequate visibility into actual project progress to allow
effective management action when the project performance deviates significantly from the plans. Forsberg, K.,
Mooz, H. and Cotterman, H., Visualising Project Management, John Wiley & Sons, Inc., 3rd edition, 2005.
Chapter 14 Project Control Page 254 – 277
23
Project control process should be in place at all level of the project. So that any deviation from planned events
can be quickly corrected. Kezsbom, D. S., Schilling, D. L . and Edward, K.A., Dynamic Project Management. A
practical guide for Managers and engineers, John Willey and Sons, New York, 1989.
24
Management control system is an integrated technique for collecting and using information to evaluate
performance. The MCS tools, supported by the WBS, cost, schedule, requirements and quality to be reviewed at
any T&E activities phase. Horngren, C., Sundem, G. and Stratton, W., 2005. Introduction to Management
Accounting, New Jersey, Pearson. Page 404.
35
Table 4. 6 T&E Management Control System
Tool Description SRR-PDR PDR-IRR IRR-TRR TRR-DRR
Bottom-Up Cost Estimating x x x x
Bottom-Up Time Estimate x x x x
Earned Value Schedule

x x x x
Analysis Control
Earned Value
Budget Control x x x x
Analysis
Verification
Quality Control x x x x
and Validation
Microsoft Reporting and
x x x x
Word Communication
Microsoft
Documentation x x x x
Word
4.2.1 Budget and Schedule Control
Project Manager is responsible for monitoring cost and schedule for the activities and for
estimating cost to complete and schedule completion on a monthly basis. The PM shall take
immediate corrective actions necessary to minimize project deviation from cost and schedule
baselines.
Using Earned Value Analysis (EVA)25 for each product component, the PM generates
variance analysis reports by comparing Actual Cost of Work Performed (ACWP), Budgeted
Cost of Work Scheduled (BCWS), Budgeted Cost of Work Performed (BCWP), and Estimate
at Completion. In addition, the Critical Path Method (CPM) will be used to control the
activities most crucial to completion of the project on-schedule.
The critical path illustrated in the section 4.1.2.5 shall receive special attention with respect to
completion on schedule26. Following Table 4.7 sub lower level work packages depict the
budget and schedule control performed by Project Manager.
25
Earned Value Analysis (EVA) is used to assess the current cost situation as a function of performance to date.
Three cumulative cost curves (budgeted cost of work scheduled – BCWS, budgeted cost of work performed –
BCWP, Actual cost of work performed – ACWP) are shown from project initiation time to current reporting
time. HE: Eisner, H., Essentials of Project and Systems Engineering Management, 3rd Edition Page103
26
Failure to complete these activities within their allotted time will cause slippage of the entire schedule. HE:
Eisner, H., Essentials of Project and Systems Engineering Management, 3rd Edition Page103
36
Table 4. 7 Sub lower level work packages budget and schedule control

Cost and schedule To plan estimating cost tocomplete and schedule completion for the
M101.2 SRR-PDR
plan T&E activities
Cost and schedule To monitor cost and schedule for the activities and for estimating cost
M201.2 PDR-IRR
review to complete and schedule completion on a monthly basis at PDR-IRR
M301.2 IRR-TRR
review to complete and schedule completion on a monthly basis at IRR-TRR
M403.1 TRR-DRR
review to complete and schedule completion on a monthly basis at TRR-DRR
4.2.2 Quality Control
This section specifies the mechanisms to be used to measure and control the quality of the
work processes and the resulting work products. Verification and validation27 will be use as
quality control mechanisms.
The Quality Assurance team under the direction of the QA Manager provides the Project
Manager with the assurance that all quality and control requirements are being accomplished.
In performing these duties, the QA Manager monitors adherence to all processes, procedures,
and plans through the delegation of responsibilities to the QA Team.
Following Table 4.8 work packages depict the quality control mechanism performed by
Quality Assurance team.
27
Verification: proof of compliance with specifications ―Was the solution built right?‖ Validation: proof that the
user(s) is satisfied ―Was the right solution built?‖ This Is a whole life-cycle process - V & V must be applied at
each stage in the system process. Forsberg,K.,Mooz,H., and Cotterman,H., Visualising Project Management,
John Wiley & Sons,Inc., 3rd Edition, 2005. Pages 361
37
Table 4. 8 Work packages depict the quality control process
Verification Responsible
WBS ID Work Package Name Verification and Validation Description Validation Techniques Milestones
Techniques Team
Execute purchased Verification and Validation of preliminary design to ensure it meet Phase reviews with end user to ensure Quality
Q101 Analysis SRR-PDR
Switch test requirements the user satisfaction is achieved Assurance team
Execute modified Switch Verification and Validation of MCSS to ensure the specifications Phase reviews with end user to ensure Quality
Q201 Testing PDR-IRR
Matrix test and requirements of the subsystems entities are met the user satisfaction is achieved Assurance team
Execute Switch Control Verification and Validation of MCSS to ensure the specifications Phase reviews with end user to ensure Quality
Q301 Testing IRR-TRR
test and requirements of the subsystems entities are met the user satisfaction is achieved Assurance team
Execute Timing Generator Verification and Validation of MCSS to ensure the specifications Phase reviews with end user to ensure Quality
test and requirements of the subsystems entities are met the user satisfaction is achieved Assurance team
Execute Test and Verification and Validation of MCSS to ensure the specifications Phase reviews with end user to ensure Quality
Monitoring test and requirements of the subsystems entities are met the user satisfaction is achieved Assurance team
MCSS subsystem Verification and Validation of MCSS to ensure the requirements of Phase reviews with end user to ensure Quality
integration test (verified) the integration of subsystems are met the user satisfaction is achieved Assurance team
Final MCSS subsystem Verification and Validation of MCSS integrated system to ensure Phase reviews with end user to ensure Quality
Q401 Demonstration TRR-DRR
operational test the system requirements are met the user satisfaction is achieved Assurance team
factory acceptance test the system requirements are met the user satisfaction is achieved Assurance team
site acceptance test the system requirements are met the user satisfaction is achieved Assurance team
customer acceptance test the system requirements are met the user satisfaction is achieved Assurance team
4.2.3 Reporting and Communication
This section specifies the reporting mechanisms and information flows to be used in
communicating the status of the project. The methods and techniques of communication will
be specified in this section.
Reporting Plan: The PM provides monthly progress reports to the stakeholders summarizing
work completed, a financial report, issues, and meetings.
Communication Plan28: The PM holds progress reviews at least every week for the purpose
of monitoring internal progress towards milestones, reviewing problems encountered,
presenting proposed resolutions, presenting near-term plans, reviewing risks and mitigation
plans, and presenting a financial review using Earned Value data (performance report).
During project team meeting, STALL29 approach is adopted to regulate matters.
Table 4. 9 Communication matrix
Communication WBS
Objective Frequency Audience Owner Deliverables Reference
Type
Project Team Review status of the Project Minutes M101,M201
Weekly Project Team
Meetings project Manager Meeting M301,M403
Discuss technical problems
Technical Project Minutes
raised in the As needed Project Team M201,M301
design meeting Manager Meeting
implementation
Project status Reports on the status of the Executive Project M101,M201
Monthly
meetings project to the management Management Manager M301,M403
Project Project
Project status Report of the status of the Project M101,M201
Monthly Sponsor, Sub Status
reports project (activities progress) Manager M301,M403
contractor reports
Project
Sponsor, Sub Final project
M501,M502
contractor, Project report
Project closeout Report of the final project Once M503,M504
Executive Manager Signed
M505
Management, acceptance
Project Team
28
To make project communication effective, we go directly to the most likely problem solver, regardless of
organization structure. Project communication can be represented by Participants, Techniques, Environment,
Language = Communications. Project participants encompass a wide array of stakeholders. (e.g. team members,
management, policy makers, contractor, customers, users). Forsberg, K., Mooz, H. and Cotterman, H.,
Visualising Project Management, John Wiley & Sons, Inc., 3rd edition, 2005. Page 48 – 68.
29
STALL is an acronym for (Stay calm, Think, Ask questions and analyse, Listen, Listen). The key element in
bridging the communications gap between systems and software engineers is to use active listening enhanced by
―pattern matching‖ during discussions. Kasser, J. E., A Framework for Understanding Systems Engineering,
Booksurge Ltd, 2007, ISBN 978-1-4196-7315-3. Page 62-70
4.3 Risk Management Plan
This section specify the risk management plan30 for identifying, analyzing, and prioritizing
project risk factors. The PM, in the role of Risk Manager, analyzes risk-related measurements,
reviews individual database entries as needed at weekly status meetings with the project team
members, and holds a review of the database on monthly schedule with the sponsor and other
senior management. Table 4.10 work packages depict the risk management performed by
Project Manager team in overall life cycle phases31.
Table 4. 10 Work packages of risk management plan
Risk identification This element include how to identify and conduct risk management at
M102 SRR-PDR
and management each T&E activities at SRR-PDR
M202 Risk management PDR-IRR
activities at PDR-IRR
M302 Risk management IRR-TRR
activities at IRR-TRR
M402 Risk management TRR-DRR
activities at TRR-DRR
4.3.1 Risk Identification
An identified risk will be categorized in the table format which will be maintained by the
project manager for the duration of the project. This table will list the potential project risks,
and the indicators that determine the rating (High, Medium, Low). The risk categorization
table will produce ―Top 10 Risks‖32 which will be reviewed at monthly project status
meetings (see Appendix II).
4.3.2 Risk Mitigation
The resolution approach, and responsibility assignment will be included in risk mitigation
efforts. Following tables shows the risk identification and mitigation which would be incur on
T&E activities at each life cycle phases.
30
The process will concemed with conducting risk management planning, identification, analysis, responses, and
monitoring and control on a project. A Guide to the Project Management Body of Knowledge (PMBOK" Guide),
Project Management Institute, Upper Darby, PA, 2004
31
Opportunity and risk is ongoing that is we have to perform the risk management activities in every phase of
MCSS T&E. Forsberg, K., Mooz, H. and Cotterman, H., Visualising Project Management, John Wiley & Sons,
Inc., 3rd edition, 2005. Page223 – 253
32
Top 10 risk factor was adapted from the most failure of IT systems development projects. Tesch, Debbie;
Kloppenborg, Timothy J; Frolick, Mark N. IT Project Risk Factors: The Project Management Professionals
Perspective. The Journal of Computer Information Systems. July 1 2007.
40
Table 4. 11 SRR-PDR Initial Risk Identification and Mitigation
Risk Action Overall
WBS ID Work Package Name Risk ID Probability Mitigation Action by
Exposure when Risk
Technical direction and R7, R17, Monitor progress and accelerate agency staff training and other Project
M101 Likely Low (L) As needed
acquire resources R18 support measures as needed. Manager
Execute purchased Switch R14, R16, Medium Evaluate system integrator proposals for ability to address Project As per
Q101 May
test R19, R22 (M) unforeseen problems Manager plan
Plan a staged implementation, seek additional funds, during
Prepare modified Swith R12, R20, Project
Q102 Probably Low (L) system integrator selection consider cost and benefits of off-the- As needed
Matrix test plan R21, R26 Manager Low (L)
shelf solutions
Prepare integration test R12, R20, Project
plan and procedure R21, R26 Manager
shelf solutions
Implement Introductory Medium Arrange staffing and their training well in advance, ensure Project
Q104 R25 May As needed
training (M) concept of operations is realistic. Manager
Table 4. 12 PDR-IRR Initial Risk Identification and Mitigation

Risk Action Overall
Exposure when Risk
management reporting R18 support measures as needed. Manager
Execute modified Switch R14, R16, Medium Evaluate system integrator proposals for ability to address Project As per
Q201 May
Matrix test R19, R22 (M) unforeseen problems Manager plan
Prepare modified Switch R12, R20, Project
Control test plan R21, R26 Manager
shelf solutions
Plan a staged implementation, seek additional funds, during Low (L)
Prepare Timing Generator R12, R20, Project
test plan R21, R26 Manager
shelf solutions
Prepare Test and R12, R20, Project
Monitoring test plan R21, R26 Manager
shelf solutions
MCSS Subsystem RAM Medium Evaluate system for ability to address unforeseen problems, Project As per
Q205 R11 May
analysis (M) coordinate with agencies on plans for systems requirements Manager plan
Table 4. 13 IRR-TRR Initial Risk Identification and Mitigation
Risk Action Overall
Exposure when Risk
management reporting R18 support measures as needed. Manager
R14, R16, Medium Evaluate system integrator proposals for ability to address Project As per
Q301 Execute Switch Control test May
R19, R22 (M) unforeseen problems Manager plan
Execute Timing Generator R14, R16, Medium Evaluate system integrator proposals for ability to address Project As per
Q302 May
test R19, R22 (M) unforeseen problems Manager plan Medium
Execute Test and R14, R16, Medium Evaluate system integrator proposals for ability to address Project As per (M)
Q303 May
Monitoring test R19, R22 (M) unforeseen problems Manager plan
Finalize whole subsystem Medium Evaluate system integrator proposals for stability and delivery Project As per
Q304 R11 Probably
integration test (M) track record. Manager plan
MCSS subsystem Medium Evaluate system integrator proposals for stability and delivery Project As per
Q305 R11 Probably
integration test (verified) (M) track record. Manager plan
Table 4. 14 TRR-DRR Initial Risk Identification and Mitigation

Risk Action Overall
Exposure when Risk
Handing over Project
M401 R8, R13 Likely Low (L) Monitor progress and other support measures as needed. As needed
documentation Manager
Test and Evaluation R7, R17, Project
M403 Likely Low (L) Monitor progress and other support measures as needed. As needed
completion review R18 Manager
Evaluate system for ability to address unforeseen problems,
Final MCSS subsystem R14, R15, Medium Project As per
Q401 May allow time for dealing with the unexpected, have a process ready
operational test R19 (M) Manager plan
for dealing with the unexpected.
Medium
Evaluate system integrator proposals for ability to address
Final MCSS subsystem Medium Project As per (M)
Q402 R14, R23 May unforeseen problems, coordinate with agencies on plans for
factory acceptance test (M) Manager plan
node systems, plan backup communication links.
Evaluate system for ability to address unforeseen problems,
Final MCSS subsystem R14, R15, Medium Project As per
Q403 May allow time for dealing with the unexpected, have a process ready
site acceptance test R19 (M) Manager plan
for dealing with the unexpected.
Final MCSS subsystem Medium Evaluate system for ability to address unforeseen problems, Project As per
Q404 R4, R19 Probably
customer acceptance test (M) coordinate with customer to ensure requirements are met Manager plan
42
4.4 Project Closeout Plan33
This section describes the nature of the activities that will be used to closeout the project when
it is completed. Project Manager will be fully involved in the approval of project closeout.
4.4.1 Post Performance Analysis
Upon termination of the entire project due to the objectives being met, there are a number of
closure activities that will be performed before the project is considered closed. Project
participants will be gathered for the purpose of a Post- Performance Analysis (PPA)34.
4.4.2 Project Closeout Schedule Allocation
The schedule for project close out will be start on 01 May 2011. This closeout cover the client
closeout, organizational closeout, subcontractor closeout, final report and team closeout.
Week 17 Week 18
TASK
ACTIVITY 1 2 3 4 5 1 2 3 4 5
ID
M501 Perform client closeout
Perform organizational
M502
closeout
Conduct subcontractor
M503
closeout
Write the project final
M504
report
M505 Conduct team closeout
Figure 4. 18 Project closeout schedule
4.4.3 Project Closeout Critical Path
The time metrics is a week which is 5 working days. Critical Path for Close out phase =
M501+M502+M503+M504+M505 = 2+2+2+2+2 = 10 Days
33
In this MCSS T&E the closeout work packages to be performed during the execution phase were listed in the
work breakdown structure (WBS) section 4.1.1. The only difference between the usual work packages and the
closeout work packages is that the latter are usually short in duration because they are small in duration. Guy L.
De Furia. Project Management Recipes for Success. CRC Press, December 2008, ISBN 10: 1420078240. Page
207-208
34
The PPA allows data to be gathered about their performance and experiences so that project processes may be
tuned to improve performance on future projects. Robert T. Futrell; Donald F. Shafer; Linda I. Safer. Quality
Software Project Management. Prentice Hall, January 2002, ISBN 10: 0-13-091297-2. Page 1090-1092
Figure 4. 19 PERT-CPM Project Closeout Phase
4.4.4 Project Closeout Resource Allocation
Project Manager will be fully involved in handle project close out. Detailed itemization below
shows of the PM (Type V) allocated to perform major closeout activity in the MCSS T&E
work breakdown structure.35
Week 13 Week 14
TASK
ACTIVITY RES DUR ES LF TS 1 2 3 4 5 1 2 3 4 5
ID
M501 Perform client closeout 1 2 0 2 0 1 1
Perform organizational
M502 1 2 2 4 0 1 1
closeout
M503 1 2 4 6 0 1 1
closeout
Write the project final
M504 1 2 6 8 0 1 1
report
M505 Conduct team closeout 1 2 8 10 0 1 1
Total Resource Load 1 1 1 1 1 1 1 1 1 1
Figure 4. 20 Resource allocation of Project Closeout Phase
35
Since the Project Closeout only perform by Project Manager which is in Management stream activities
therefore, the graph of Engineers Type and Type of Labor not included in this section.
44
4.4.5 Project Closeout Budget Allocation
Total manpower cost is for perform project closeout is $5000.
Table 4. 15 Budget allocation Project Closeout Phase

Unit sub-total
500 Project Closeout Engineers Type Number days cost cost
Rate/day cost
M501 Perform client closeout Project Manager Type V 1 $500 2 $1,000 $1,000 $1,000
M502 Perform organizational closeout Project Manager Type V 1 $500 2 $1,000 $1,000 $2,000
M503 Project Manager Type V 1 $500 2 $1,000 $1,000 $3,000
closeout
M504 Write the project final report Project Manager Type V 1 $500 2 $1,000 $1,000 $4,000
M505 Conduct team closeout Project Manager Type V 1 $500 2 $1,000 $1,000 $5,000
Sub-total $5,000 $5,000
Project Closeout Phase

$6,000
$5,000
$4,000
$3,000
$2,000
$1,000
$0
M501 M502 M503 M504 M505
High level sub-total cost $1,000 $1,000 $1,000 $1,000 $1,000
Cumulative cost $1,000 $2,000 $3,000 $4,000 $5,000
Figure 4. 21 Budget accumulative Project Closeout Phase
45
5. LESSON LEARNED
This section describe and discuss the lessons learned session which incorporate in the TEMP.
ID SESSIONS LESSON LEARNED
 Defined the types of activities performed in the development of

An introduction to Project Management a TEMP
01
and Systems Engineering  Defined the SPARK element as part of Project Plan to
incorporate in the TEMP
 Construct work packages for the processes of TEMP
02 Modern project management  Applied the monitor progress through incorporate in the work
packages.
 Applied the five types of engineer-leaders to allocate the
human resources more efficient in the TEMP process.
 Introduced the difference between a role (job) and an activity
03 Project Selection and Strategy
to be performed in the TEMP
 Used the Waterfall view as the basis for the work performed
between each of the 4 formal major milestones in the TEMP.
 Able to applied and defended choice of matrix organization as
04 Project Organisation
management structure for the MCSSRP TEMP
 Able to applied the essential elements of a project plan
(SPARK) in the TEMP
 Understand how to create and use a Work Breakdown
05 Project Planning
Structure (WBS) by using Top-Down approach which
identifies the needed tasks, resource allocations, and cost
estimates.
 Able to developed scheduling estimates to T&E activities by
using Bottom-Up approach to estimate the project time
06 Scheduling  Able to develop the project network, the critical path and its
importance.
 Applied resource allocation to schedule T&E activities
 Able to applied the methods for estimating project times and
costs. Bottom-Up approach is used in the TEMP.
 Able to applied different types of cost contracts for work
07 Cost Estimating
activities in the work breakdown structure. The activity budget
estimated the cost for activity personnel where the type of cost
is price contract
 Able to applied the project control process tools to incorporate
09 Performance Monitoring
in the work activities to mitigate and prevent project failure
 Able to defined the scope of the project manager for the
10 Project Leadership
TEMP.
46
 Able to defined the human element in the TEMP process and
11 Project Teams managing personnel skills and competencies, conflict and
communications through perform in the work activities.
 Applied risk management process through work activities to
12 Constraint Management
mitigate and prevent project risks.
 Able to applied project closure activities to be performed and
14 Project Audit and Closeout evaluate project personnel by using Post Perfomance Analysis
method.
In overall the TEMP documentation keep the project controlled, standardized the T&E
process and improve the communication and the understanding of the T&E process. Using
Vee model and System Approach for Test and Evaluation can prevent a big loss and improve
the system development, since the failure detected earlier, not after the production of the
MCSS system. Milestone is needed as a correction control across the project and also for
verification and validation of the MCSS system.
47
6. BIBLIOGRAPHY
1. A Guide to the Project Management Body of Knowledge (PMBOK" Guide), Project

Management Institute, Upper Darby, PA, 2004
2. Bell, David.W and Brown, David.C. Systems Engineering and Test and Evaluation—The
Integrated Process. ITEA Journal 2010
rd
3. Eisner, H., Essentials of Project and Systems Engineering Management, 3 Edition,
Wiley Interscience, 2008, ISBN 978-0-470-12933-3
4. Forsberg, K., Mooz, H. and Cotterman, H., Visualising Project Management, John Wiley
& Sons, Inc., 3rd edition, 2005.
5. Gray, C., and Larson, E., Project Management, 4th Edition, McGraw H ill, 2007, ISBN
978-0-07-1228751-7.
6. Gregory S. Parnell, Patrick J. Driscoll, Dale L. Henderson (2011). Decision Making in
Systems Engineering and Management, Second Edition. John Wiley & Sons, Inc.
7. Guy L. De Furia. Project Management Recipes for Success. CRC Press, December 2008,
ISBN 10: 1420078240.
8. Hari, A., Shoval, S. and Kasser, J. E., ―Conceptual Design to Cost: A new systems
engineering tool‖, proceedings of the 18th International Symposium of the INCOSE,
Utrecht, Holland, 2008.
9. Horngren, C., Sundem, G. and Stratton, W., 2005. Introduction to Management
Accounting, New Jersey, Pearson.
10. Ichiro Koshijima and Tomio Umeda. Human Resource Allocation in Project
Management. Management Science Approach.
http://www.sba.muohio.edu/abas/2001/brussels/Koshijima_Koshijima-Umeda.pdf
11. INCOSE., ―System Engineering Handbook Version 2.0‖, Seattle, 2000
12. Kasser, J. E. and Frank, M., ―A Maturity Model for the Competency of Systems
Engineers‖, proceedings of the 20th International Symposium of the INCOSE, Chicago,
IL., 2010.
13. Kasser, J. E. and Hitchins, D. K., ―Unifying the different systems engineering processes‖,
proceedings of Conference on Systems Engineering Research, Hoboken, NJ., 2010.
14. Kasser, J. E. and Mirchandani, C. J., ―The MSOCC Data Switch Replacement: A Case
Study in Elicitating and Elucidating Requirements‖, proceedings of the 15th International
Symposium of the International Council on Systems Engineering (INCOSE), Rochester,
NY, 2005.
15. Kasser, J. E., ―Improving the Systems Engineering Documentation Production Process‖,
proceedings of the 5th Annual International Symposium of the NCOSE, 1995
16. Kasser, J. E., ―The Hitchins-Kasser-Massie (HKM) Framework for Systems
Engineering‖, proceedings of the 17th International Symposium of the INCOSE, San
Diego, CA., 2007.
48
17. Kasser, J. E., A Framework for Understanding Systems Engineering, Booksurge Ltd,
2007, ISBN 978-1-4196-7315-3
18. Kasser, J. E., Applying Total Quality Management to Systems Engineering, Artech
House, Boston, 1995, Chapter 10.
19. Kasser, J. E., Frank, M. and Zhao, Y. Y., ―Assessing the competencies of systems
engineers‖, proceedings of the 7th biannual European Systems Engineering Conference
(EuSEC), Stockholm, Sweden, 2010.
20. Kasser, J. E., Hitchins, D. and Huynh, T. V., ―Reengineering Systems Engineering‖,
proceedings of the 3rd Annual Asia-Pacific Conference on Systems Engineering
(APCOSE), Singapore, 2009.
21. Kezsbom, D. S., Schilling, D. L. and Edward, K. A., Dynamic Project Management. A
practical guide for managers and engineers, John Wiley & Sons, New York, 1989.
22. Kossiakoff, A. & Sweet, W. N. (2003). Systems Engineering Principles and Practice.
Hoboken: John Wiley ISBN: 0-471-23443-5.
23. Practice Standard for Work Breakdown Structures (Second Edition), published by the
Project Management Institute, ISBN 1933890134
24. Project Management Institute A Guide to the Project Management Body of Knowledge,
Third Edition, 2004 Project Management Institute, Inc. ISBN 193069945X
25. Robert T. Futrell; Donald F. Shafer; Linda I. Safer. Quality Software Project
Management. Prentice Hall, January 2002, ISBN 10: 0-13-091297-2.
26. Shenhar, A. J. and Bonen, Z., ―The New Taxonomy of Systems: Toward an Adaptive
Systems Engineering Framework‖, IEEE Transactions on Systems, Man, and Cybernetics
– Part A: Systems and Humans, Vol. 27 (1997), no. 2, 137 – 145.
27. Tesch, Debbie; Kloppenborg, Timothy J; Frolick, Mark N. IT Project Risk Factors: The
Project Management Professionals Perspective. The Journal of Computer Information
Systems. July 1 2007.
49
7. APPENDIX 1. WORK PACKAGES DESCRIPTION
Appendix A: Preliminary Design (SRR-PDR)
Task ID 100
Name of Activity Preliminary Design (SRR-PDR)
Priority High
Start of the project, after requirement has been given and up to when the
Narrative of activity
preliminary design is chosen.
To plan for the testing & evaluation activities of the new MCSS according to
Reason of activity [CONOPS]
the requirement and agreed by stakeholders.
Schedule (+accuracy) 20 days (90% accuracy)
Product F100: Test Plan Document
Acceptance criteria of product Reviewed and approved during customer review meeting
Prerequisites Pre-System Requirement Review (Approved)
Personnel
 R1:Project Manager (Type V) x 1 (Full Time)
 R2:System Engineer (Type III) x 1 (Part Time)
 R3:Senior System Engineer (Type V) x 1 (Part Time)
 R4:Senior Test Engineer (Type V) x 1 (Part Time)
Resources  R5:Test Engineer (Type III) x 2 (Full Time)
 R7:QA Engineer (Type III) x 1 (Full Time)
Equipment
MS Office
MS Project
Estimated cost $12,950
Accuracy of cost estimate -10%, +30% (Bottom up approach)
Risk (probability, mitigation

Probably, Low risk, M101, Q101, Q102, Q103, Q104
WP ID)
Internal key milestones SRR-PDR
Decision points Plan approved by SRR meetings
Assumptions None
Lower level work packages ID M101, M102, Q101, Q102, Q103, Q104
50
Task ID M101
Name of Activity Technical direction and acquire resources
Priority High
To provide a plan for activities to be conducted, assigned required resources

and provide technical direction and guidance for the T&E activities
To facilitate a smooth running of T&E activities including required resources

at SRR-PDR
F101: Resources, Schedule and Cost Plan

Product
F102: Methodology for Testing and Validation
Acceptance criteria of product Reviewed and approved during review meeting
Prerequisites None
Resources
R1:Project Manager (Full Time)
Resources Equipment
MS Office
MS Project
Estimated Cost $6000
Accuracy of Cost Estimate -10%, +30% (Bottom up approach)

Likely and Low risk
WP ID)
Decision points Plan approved by Project Manager
Assumptions BA.01, BA.02, TA.01, TA.02, TA.03, SA.01, SA.02
Lower level work packages ID M101.1, M101.2, M101.3
51
Task ID M101.1
Name of Activity Resources plan for T&E
Priority High
Allocated resources to each major work activity in the T&E work breakdown
Narrative of activity structure. Resources include the numbers and required skill levels of
personnel.
Reason of activity [CONOPS] To assure that the necessary resources are made available when required
Product F101.1 : Resources Plan Document
Acceptance criteria of product Reviewed and approved by PM
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Assumptions TA.02, TA.03, SA.01, SA.02
Lower level work packages ID None
52
Task ID M101.2
Name of Activity Cost and Schedule Plan
Priority High
Plan a detailed breakdown of necessary resource budgets and schedule for

each of the major work activities in the work breakdown structure.
To allocate resource budgets for each of the major work activities in order to
Reason of activity [CONOPS] minimize the over cost during execution of the task and to ensure the
necessary resources schedule are allocate properly.
Product F101.2 : Cost and Schedule Plan Document
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Assumptions BA.01, BA.02, TA.01, TA.02, TA.03
53
Task ID M101.3
Name of Activity Subsystem test direction
Priority High
Planning guidance for subsystem test to be performed in testing stream work

activities.
Reason of activity [CONOPS] To provide detailed planning and direction of the test program are in order36
Product F101.3 : Subsystem Test Guidance
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Assumptions None
36
Subsystem direction planning is needed to encountered the faults during execution of individual subsystem test
which will have greater potential impact on overall program cost and schedule. Kossiakoff, A. & Sweet, W. N.
(2003). Systems Engineering Principles and Practice. Hoboken: John Wiley ISBN: 0-471-23443-5. Chapter 10:
Integration and Evaluation Page 292
54
Task ID M102
Name of Activity Risk identification and management
Priority High
To document initial risk assesment and risk mitigation efforts at major work
activity in the T&E work breakdown structure,
To identify and mitigate risk at major work activity in the T&E work
breakdown structure37.
Product F103: Risk Management Plan
Acceptance criteria of product Approved by Project Manager
Prerequisites None
Resources
Resources Equipment
MS Office

Likely and Low risk
WP ID)
Assumptions Project Manager act as a role of Risk Manager
37
Opportunity and risk is ongoing that is we have to perform the risk management activities in every phase of
MCSS T&E and depicted in the work packages. Forsberg, K., Mooz, H. and Cotterman, H., Visualising Project
Management, John Wiley & Sons, Inc., 3rd edition, 2005. Page223 – 253
55
Task ID Q101
Name of Activity Execute purchased Switch test38
Priority High
The Purchased Switch Test is performed following the Test Procedure

document. Test has to satisfy the Test Pass/Fail criteria defined in the MCSS
SRD including Verification and Validation of preliminary design to ensure it
meet requirements.
To test whether the Purchased Switch is meet the requirements. To learn

if the Purchased Switch exceeds the system requirement.
Product F104: Purchased Switch Test Report
Acceptance criteria of product Test is performed according to the guidance provide by the PM.
Prerequisites M101.3 Subsystem test direction
Resources
 R5:Test Engineer (Type III) x 2 (Full Time)
Resources Equipment
 Test Rigs
 288 Ports Switch Matrix

May and Medium risk
WP ID)
Decision points Test approved by Project Manager
Assumptions QA.01
38
As we bought the COTS Industry Switch from the market, those purchase switch should have immediately test
for immediate feedback result and will be served as independent testing. This decision eliminated a major risk,
and determined that the requirements for the replacement switch would be feasible, and achievable within
budget. Kasser, J. E. and Mirchandani, C. J., ―The MSOCC Data Switch Replacement: A Case Study in
Elicitating and Elucidating Requirements‖, proceedings of the 15th International Symposium of the International
Council on Systems Engineering (INCOSE), Rochester, NY, 2005. Page 7
56
Task ID Q102
Name of Activity Prepare modified Swith Matrix test plan and procedure39
Priority High
Planning the Modified Switch Matrix Test. This is including the Test
Narrative of activity Objective, Test Methodology, and Test Pass/Fail Criteria for the Modified
Switch Matrix
To modify COTS switch components in step by step to meet the requirements

and interface of MCSS to the MSOCC
Product F105: Modified Switch Matrix Test Plan Document
Prerequisites MCSS System Requirement Document
Resources
Resources
R4:Senior Test Engineer (Type V) (PartTime)

Probably and Low risk
WP ID)
Decision points Approved by Project Manager
Assumptions None
39
Before designing the test equipment it is important fully to define the test procedures, so as to avoid later
redesign to achieve compatibility between test equipment and the component or subsystem under test. This again
emphasizes the importance of early and comprehensive test planning. Kossiakoff, A. & Sweet, W. N. (2003).
Systems Engineering Principles and Practice. Hoboken: John Wiley ISBN: 0-471-23443-5. Chapter 10:
Integration and Evaluation Page 283
57
Task ID Q103
Name of Activity Prepare integration test plan and procedure40
Priority High
Planning the MCSS Integration Test Plan and Procedure. This is including the
Narrative of activity Test Objective, Test Methodology, and Test Pass/Fail Criteria for the
Purchased Switch Test.
Reason of activity [CONOPS] To provide a test plan and procedure of MCSS for the tester
Product F106: MCSS Integration Test Plan and Procedure Document
Test Pass/Fail criteria based on MCSS System Requirement Document and

Acceptance criteria of product
the test procedure is according to the Test Plan.
Resources
Resources
R3:Senior System Engineer (Type V) (PartTime)

WP ID)
Assumptions None
40
Integration test plan and procedure is needed to translate requirements into a description of each test even and
to develop detailed test procedure for each event. The integration of a subsystem from its components parts is
normally a stepwise assembly and test process. Kossiakoff, A. & Sweet, W. N. (2003). Systems Engineering
Principles and Practice. Hoboken: John Wiley ISBN: 0-471-23443-5. Chapter 10: Integration and Evaluation
Page 281-288
58
Task ID Q104
Name of Activity Implement Introductory training
Priority High
The System Engineer will be introduced to the MCSS System

Requirement. The Senior Test Engineer will be trained for developing the
test plan and procedure and familiarize with the Test Equipment.
The Test Engineer and Quality Engineer will be trained to perform the
Test in MCSS system and be familiarized with the MCSS nature and
requirement.
To familiarize the manpower who will performed in the T&E with the
Reason of activity [CONOPS] MCSS system, Test Methodology and Test Equipment to maintain the
Test Quality standard and to prevent defect in T&E activity
Product F106: MCSS Integration Test Plan and Procedure Document
Test Pass/Fail criteria based on MCSS System Requirement Document and

the test procedure is according to the Test Plan.
Resources
Resources
R3:System Engineer (Type III) (PartTime)

May and Medium risk
WP ID)
Assumptions SA.01
59
Appendix B: Detailed Design (PDR-IRR)
Task ID 200
Name of Activity Detailed Design (PDR-IRR)
Priority High
Choosing a single preliminary design which has been approved and purchase
the COTS products, the in-house engineering team will build the MCSS and
the test team will plan for the testing & evaluation of the integrated MCSS
and to test the subsystems in a stand-alone manner
To document consensus that a single preliminary design is chosen from a
range of options, document decision to move to construction phase and
moving on to construction phase as well as stand-alone testing of the
subsystems
Product F200: Test Procedures Document
Meet requirement and the MCSS subsystems pass the stand-alone test
requirements
Prerequisites Preliminary Design Review
Personnel
 R4:Senior Test Engineer (Type V) x 1 (Part Time)
Resources  R5:Test Engineer (Type III) x 2 (Full Time)
Equipment
MS Office
MS Project

Probably, Low risk, M201, Q201, Q202, Q203, Q204, Q205
WP ID)
Internal key milestones PDR-IRR
Decision points Plan approved by PDR meetings
Assumptions None
Lower level work packages ID M201, M202, Q201, Q202, Q203, Q204, Q205
60
Task ID M201
Name of Activity Technical direction and management reporting
Priority High
Monitor progress and accelerate agency staff training and other support
measures as needed.
To provides monthly progress reports to the stakeholders summarizing work

completed, a financial report, issues, and meetings.
F201: Resources, Schedule and Cost Review Report

Product
F202: Methodology for Integration Testing
Prerequisites F101 Baseline Schedule, Cost and Resources.
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Decision points Approved by the Stakeholders
61
Task ID M201.1
Name of Activity Resources plan review
Priority High
Allocated resources plan to each major work activity in the T&E work
Narrative of activity breakdown need to be review in monthly. Resources include the numbers and
required skill levels of personnel.
To review allocated resources of each major work activity which has been
Reason of activity [CONOPS] performed in the T&E work breakdown structure to ensure that the resources
are available during execution of the task.
Product F201.1 : Resources Review Plan Document
Acceptance criteria of product Reviewed and approved during project meeting
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
62
Task ID M201.2
Name of Activity Cost and Schedule review
Priority High

Narrative of activity each of the major work activities in the work breakdown structure need to be
review in monthly status.
To monitor cost and schedule for the activities and for estimating cost to
complete and schedule completion on a monthly basis.
Product F201.2 : Cost and Schedule Review Document
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Decision points Plan review approved by Project Manager
63
Task ID M201.3
Name of Activity Subsystem integration test direction
Priority High
Narrative of activity Defining guidance plans for integration and system testing
To provide detailed planning and direction of the integration test program are
in order41
Product F201.3 : Subsystem Test Guidance
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Assumptions None
41
In this MCSS T&E, the PM provides guidance for successful implementation of integration subsystem testing.
The success of the integration is highly dependent on the advance planning and preparation for this effort that
was accomplished during the previous phases. Kossiakoff, A. & Sweet, W. N. (2003). Systems Engineering
Principles and Practice. Hoboken: John Wiley ISBN: 0-471-23443-5. Chapter 10: Integration and Evaluation
Page 273
64
Task ID M202
Name of Activity Risk management
Priority High
To monitor risk assesment and risk mitigation efforts which would be occur
at major work activity in the T&E work breakdown structure.
breakdown structure.
Prerequisites None
Resources
Resources Equipment
MS Office

Likely and Low risk
WP ID)
Decision points Monitor by Project Manager
65
Task ID Q201
Name of Activity Execute modified Switch Matrix test
Priority High
The Modified Switch Matrix Test is performed following the Test

Plan document. Test has to satisfy the Test Pass/Fail criteria defined in the
MCSS SRD including Verification and Validation of MCSS to ensure the
specifications and requirements of the subsystems entities are met.
To test whether the Modified Switch Matrix is meet the requirements in

System requirements Document Section 5.
Product F204: Modified Switch Matrix Report
Prerequisites Q102 Modified Switch Matrix Test Plan and Procedure
Resources
Resources Equipment
 Test Rigs
 Oscilloscope

May and Medium risk
WP ID)
Assumptions QA.01
66
Task ID Q202
Name of Activity Prepare modified Switch Control test plan and procedure
Priority High
Planning the Modified Switch Control Test. This is including the Test
Narrative of activity Objective, Test Methodology, and Test Pass/Fail Criteria for the Modified
Switch Control
To prepare switch control components to meet the requirements and interface

of MCSS to the MSOCC
Product F205: Modified Switch Control Test Plan Document
Resources
Resources

WP ID)
Assumptions None
67
Task ID Q203
Name of Activity Prepare Timing Generator test plan and procedure
Priority High
Planning the Timing Generator Test. This is including the Test Objective,
Narrative of activity Test Methodology, and Test Pass/Fail Criteria for the Modified Switch
Control
To prepare timing generator meet the requirements and interface of MCSS to

the MSOCC
Product F206: Timing Generator Test Plan Document
Resources
Resources

WP ID)
Assumptions None
68
Task ID Q204
Name of Activity Prepare Test and Monitoring test plan and procedure
Priority High
Planning the Test and Monitoring test. This is including the Test Objective,
Narrative of activity Test Methodology, and Test Pass/Fail Criteria for the Modified Switch
Control
To prepare test and monitoring components meet the requirements and

interface of MCSS to the MSOCC
Product F207: Test and Monitoring Test Plan Document
Resources
Resources

WP ID)
Assumptions None
69
Task ID Q205
Name of Activity MCSS Subsystem RAM analysis42
Priority High
The reliability data, in terms of MTBF will be evaluated for each individual
Narrative of activity subsystem. The reliability of the system is refering to MCSS SRD.
Maintainability is defined according to MCSS SRD.
To ensure subsystem design components meet the operational requirements

and interface of MCSS to the MSOCC
Product F208: RAM Analysis Report
Acceptance criteria of product Test is performed according to the MCSS SRD Operational Test
Resources
Resources

May and Medium risk
WP ID)
Decision points Approved by PM
Assumptions QA.01
42
In MCSS T&E, the RAM analysis is performed to ensure the subsystem process operates properly for a
specified amount of time (design life) under stated use conditions without failure. What constitutes failure for a
component, subsystem, system, or process must be clearly defined as the item or process is developed. Gregory
S. Parnell, Patrick J. Driscoll, Dale L. Henderson (2011). Decision Making in Systems Engineering and
Management, Second Edition. John Wiley & Sons, Inc. Chapter 8 Page 228
70
Appendix C: Development and Integration (IRR-TRR)
Task ID 300
Name of Activity Development and Integration (IRR-TRR)
Priority High
To install and integrate the new and tested MCSS into the existing system
and to finalize the final acceptance test plan
To ensure that the MCSS is installed and integrated and to plan for the final
acceptance test
Product F300: Final Subsystem Test Report
The integrated MCSS can function and the Final acceptance test plan will test
the MCSS according to requirement and to the satisfaction of the client
Prerequisites Integration Readiness Review
Personnel
Resources  R7:QA Engineer (Type III) x 3 (Full Time)
Equipment
MS Office
MS Project

May and Medium risk, M301, Q301, Q302, Q303, Q304, Q305
WP ID)
Internal key milestones IRR-TRR
Decision points Plan approved by IRR meetings
Assumptions None
Lower level work packages ID M301, M302, Q301, Q302, Q303, Q304, Q305
71
Task ID M301
Name of Activity Technical direction and management reporting
Priority High
Monitor progress and accelerate agency staff training and other support
measures as needed.
To provides monthly progress reports to the stakeholders summarizing work

completed, a financial report, issues, and meetings.
F301: Resources, Schedule and Cost Review Report

Product
F302: Methodology for Integration Testing
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
72
Task ID M301.1
Name of Activity Resources plan review
Priority High
Allocated resources plan to each major work activity in the T&E work
Narrative of activity breakdown need to be review in monthly. Resources include the numbers and
required skill levels of personnel.
To review allocated resources of each major work activity which has been
Reason of activity [CONOPS] performed in the T&E work breakdown structure to ensure that the resources
are available during execution of the task.
Product F301.1 : Resources Review Plan Document
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
73
Task ID M301.2
Priority High

Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
74
Task ID M301.3
Name of Activity MCSS subsystem integration test direction (verified)
Priority High
Narrative of activity Defining guidance plans for integration overall subsystem testing
To provide detailed planning and direction of the integration test program are
in order
Product F301.3 : MCSS Subsystem Test (Verified) Guidance
Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Assumptions None
75
Task ID M302
Priority High
Prerequisites None
Resources
Resources Equipment
MS Office

Likely and Low risk
WP ID)
76
Task ID Q301
Name of Activity Execute modified Switch Control test
Priority High
The Modified Switch Control Test is performed following the Test

To test whether the Modified Switch Control is meet the requirements in

Product F304: Modified Switch Control Report
Prerequisites Q202 Modified Switch Control Test Plan and Procedure
Resources
Resources Equipment
 Test Rigs
 Oscilloscope

May and Medium risk
WP ID)
Assumptions QA.01
77
Task ID Q302
Name of Activity Execute modified Timing Generator test
Priority High
The Modified Timing Generator Test is performed following the Test

To test whether the Modified Timing Generator is meet the requirements in

Product F305: Modified Timing Generator Report
Prerequisites Q203 Modified Timing Generator Test Plan and Procedure
Resources
Resources Equipment
 Test Rigs
 Oscilloscope

May and Medium risk
WP ID)
Assumptions QA.01
78
Task ID Q303
Name of Activity Execute modified Test and Monitoring test
Priority High
The Modified Test and Monitoring Test is performed following the

Test Plan document. Test has to satisfy the Test Pass/Fail criteria defined in
the MCSS SRD including Verification and Validation of MCSS to ensure the
To test whether the Test and Monitoring is meet the requirements in System
requirements Document Section 5.
Product F306: Test and Monitoring Report
Prerequisites Q204 Modified Test and Monitoring Test Plan and Procedure
Resources
Equipment
Resources  Test Rigs
 Oscilloscope
 NBG
 BED

May and Medium risk
WP ID)
Assumptions QA.01
79
Task ID Q304
Name of Activity Prepare finalize the whole subsystem integration test
Priority High
Finalization preparation of the whole subsystem integration test performed

following the integration Test Plan document.
To test whether the final assembly of whole subsystem is meet the

requirements in System requirements Document Section 5.
Product F307: Assembly Subsystem Integration Test Report
Prerequisites Q103 Subsystem Integration Test Plan and Procedure
Resources
Resources
R3:Senior System Engineer (Type V) x 1 (Part Time)

Probably and Medium risk
WP ID)
Assumptions None
80
Task ID Q305
Name of Activity Final MCSS subsystem integration test (verified)
Priority High
The Final Whole Subsystem Integration Test is performed following the

Assembly Subsystem Integration Plan document. Test has to satisfy the Test
Narrative of activity Pass/Fail criteria defined in the MCSS SRD including Verification and
Validation of MCSS to ensure the specifications and requirements of the
subsystems entities are met.
To test whether the final assembly of whole subsystem is meet the
Reason of activity [CONOPS] requirements in System requirements Document Section 5 and to ensure the
whole final assembly subsystem are verified to be test on on-site test.
Product F308: Final Assembly Subsystem Integration Test Report
Prerequisites Q304 Assembly Subsystem Integration Test
Resources
Equipment
Resources  Test Rigs
 Oscilloscope
 Block Error Detector
 Nascom Block Generator

Probably and Medium risk
WP ID)
Assumptions QA.01
81
Appendix D: Qualification and Installation (TRR-DRR)
Task ID 400
Name of Activity Qualification and Installation (TRR-DRR)
Priority High
To conduct the final acceptance test for the MCSS and to prepare for the
handing over/delivery of the MCSS to the client
To document consensus that the final product is tested, defect free and is
ready to be delivered
Product F400: Final Acceptance Test Report
Acceptance criteria of product Products meet requirements and pass the final acceptance testing
Prerequisites Test Readiness Review
Personnel
 R2:System Engineer (Type V) x 1 (Part Time)
Resources  R6: Logistic Engineer (Type II) x 1 (Part Time)
Equipment
MS Office
MS Project

May and Medium risk, M401, M403, Q401, Q402, Q403, Q404
WP ID)
Internal key milestones TRR-DRR
Decision points Plan approved by TRR meetings
Assumptions None
Lower level work packages ID M401, M402, M403, Q401, Q402, Q403, Q404
82
Task ID M401
Name of Activity Handing over final document
Priority High
Narrative of activity Handing over/delivery of the MCSS document to the client
To document consensus that the final product is tested, defect free and is
ready to be delivered
Product F401: Final MCSS Document Report
Acceptance criteria of product Products meet requirements and pass the final user acceptance testing
Prerequisites None
Personnel
Resources
R2:System Engineer (Type V) x 1 (Part Time)
Estimated cost $750

Likely and Low risk
WP ID)
Decision points Plan approved by TRR meetings
Assumptions None
83
Task ID M402
Priority High
Prerequisites None
Resources
Resources Equipment
MS Office

Likely and Low risk
WP ID)
84
Task ID M403
Name of Activity Test and Evaluation completion review
Priority High
Review the test and evaluation work activities has satisfy the requirements to
indicate project status and schedule
To ensure the test and evaluation work activities performed at the entire
system life cycle.
F403: Schedule and Cost Completion Review Report

Product
F404: Completion Report
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
Lower level work packages ID M403.1, M403.2
85
Task ID M403.1
Priority High

Prerequisites None
Resources
Resources Equipment
MS Office
MS Project

Likely and Low risk
WP ID)
86
Task ID M403.2
Name of Activity Project completion review
Priority High
Project completion review is prepared by Project Manager. Project

completion report finalizes all project activities completed across all phases
of the T&E activities to formally complete the project and transfer the
completed as appropriate.
To assess the project, ensure completion, and derive any lessons learned and
best practices to be applied to future projects.
Product F403.2 : Project Completion Report
Prerequisites None
Resources
Resources Equipment
MS Office
 MS Project

Likely and Low risk
WP ID)
Assumptions SA.02
87
Task ID Q401
Name of Activity Final MCSS subsystem operational test
Priority High
A Factory Acceptance Test witnessed by the transition test to test whether

Narrative of activity each subsystems of the integrated MCSS is meet the requirement in section
5 and can operate as expected in user demanded simulated condition
To assess the project, ensure completion, and derive any lessons learned and
best practices to be applied to future projects.
Product F405: Final MCSS Subsystems Operational Test Report
The 4 subsystem meet the requirement MCSS SRD section 5. The

Acceptance criteria of product subsystem can work as expected in user demanded simulated
condition.
Prerequisites Q304 Final whole subsystem integration test plan and procedure
Resources
Equipment
Resources
 Test Rigs
 Oscilloscope

May and Medium risk
WP ID)
Assumptions QA.01, QA.02
88
Task ID Q402
Name of Activity Final MCSS subsystem factory acceptance test
Priority High
Review the result of the test documented in the Factory Acceptance Test
Report for verification and validation of the MCSS
Test Engineer reviewed the result of the Test to verify and validate the
Reason of activity [CONOPS] MCSS being tested. With this review, an Early faulty/failure can be
detected and reported during the DRR
Product F406: Final MCSS Subsystems Factory Acceptance Test Report

condition.
Resources
Equipment
Resources
 Test Rigs
 Oscilloscope

May and Medium risk
WP ID)
89
Task ID Q403
Name of Activity Final MCSS subsystem site acceptance test
Priority High
The integrated site acceptance test will occur before and after each transition
stage. The transition team will use designated milestone test procedure.
To assured the usability of the MCSS at each of the transition stage during
system installation
Product F407: Final MCSS Subsystems Site Acceptance Test Report

condition.
Resources
Equipment
Resources
 Test Rigs
 Oscilloscope

May and Medium risk
WP ID)
90
Task ID Q404
Name of Activity Final MCSS subsystem customer acceptance test
Priority High
The fully integrated MCSS is tested. Quality Assurance Engineer reviewed

the result of the Test to verify and validate the MCSS being tested in
customer site. Logistic Engineer ensures the reliability of all subsystems and
modifies system design accordingly to achieve customer requirements.
To test the fully integrated MCSS after being installed but before Final
Acceptance Test by NASA to be considered fully operational. Review the
Reason of activity [CONOPS] result of the test documented in the Factory Acceptance Test Report for
verification and validation of the MCSS in the customer site before being
handled to NASA.
Product F407: Final MCSS Subsystems Customer Acceptance Test Report

condition.
Resources
Equipment
Resources
 Test Rigs
 Oscilloscope

May and Medium risk
WP ID)
91
Appendix E: Project Closeout
Task ID 500
Name of Activity Project Closeout
Priority High
A project closeout activity is to end the project in a professional manner one

Narrative of activity that reflects well upon the team, the organization, and especially upon the
project manager.
To assure that the activities will be conducted in an appropriate manner and
Reason of activity [CONOPS] that the resources (people, money, and time) for the activities will also be
available at the end of the project.
Product F500: Project Final Report
Acceptance criteria of product Products meet requirements during the stakeholder meeting
Prerequisites Delivery Readiness Review
Personnel
R1:Project Manager (Type V) x 1 (Full Time)
Resources
Equipment
MS Office
MS Project
Estimated cost $5000

None
WP ID)
Internal key milestones Closeout
Decision points Approved by Stakeholders (NASA GSFC) and Executive Management (CSC)
Assumptions None
Lower level work packages ID M501, M502, M503, M504, M505
92
Task ID M501
Name of Activity Perform client closeout
Priority High
Validate deliverable(s) submission and document that all deliverables were

accepted by the customer: If no documentation exists, write a memo to the
customer with a retained copy indicating that the deliverables were submitted
and the date of the submission.
Reason of activity [CONOPS] To ensure that all deliverables were accepted by the customer.
Product F501: Validation Deliverables of Document
Acceptance criteria of product Products accepted by customer
Prerequisites None
Personnel
Resources
Equipment
MS Office
MS Project

None
WP ID)
Decision points Approved by Stakeholders
Assumptions None
93
Task ID M502
Name of Activity Perform organizational closeout
Priority High
Release the project room by sending a memo to the facilities management

office stating that the room will be vacated by a certain date, and available for
other uses. Finalize financial records and funds by preparing a finance
resolution memo. In it, indicate any outstanding invoices against the project
or invoices expected, plus the balance of money that will remain after these
invoices are paid.
To conclude the team’s use of organizational resources and to make a final

resolution of the remaining resources.
Product F502: Organizational Closeout Document
Acceptance criteria of product Products accepted by Executive Management
Prerequisites None
Personnel
Resources
Equipment
MS Office
MS Project

None
WP ID)
Decision points Approved by Executive Management
Assumptions None
94
Task ID M503
Name of Activity Conduct subcontractor closeout
Priority High
Determine whether subcontractors are finished: Document this in a memo for

Narrative of activity record with a copy to finance so the subcontractor (Ford Aerospace) can be
paid.
To ensure that all subcontractor responsibilities and work have been

completed.
Product F503: Subcontractor Closeout Document
Acceptance criteria of product Products accepted by Subcontractor
Prerequisites None
Personnel
Resources
Equipment
MS Office
MS Project

None
WP ID)
Assumptions None
95
Task ID M504
Name of Activity Write the project final report
Priority High
Write the report as the basis of a briefing. Project manager will be enhanced
by a well-organized and professional final report.
To inform upper management of the completion of the project and to assure

these people that all aspects of the project have been properly closed.
Product F504: Project Final Report
Acceptance criteria of product Products accepted by Executive Management
Prerequisites None
Personnel
Resources
Equipment
MS Office
MS Project

None
WP ID)
Assumptions None
96
Task ID M505
Name of Activity Conduct team closeout
Priority High
Conduct the final lessons learned session43: Something that the team did that
worked should be retained as a lesson learned because the next time the team
is faced with the same problem, it will want to use the action that was
successful in the past.
To release team members back to their functional departmentsand use the
lessons learned to get a sense of the team’s morale and shape behavior. The
result of these sessions will be to highlight, reward, and clarify desired
behavior.
Product F505: Lesson Learned Report
Acceptance criteria of product Products accepted by Project Team meetings
Prerequisites None
Personnel
Resources
Equipment
MS Office
MS Project

None
WP ID)
Assumptions None
43
A lesson learned is an incident of experience that may be used to improve performance or repeat good
performance. Guy L. De Furia. Project Management Recipes for Success. CRC Press, December 2008, ISBN 10:
1420078240. Page 210
97
8. APPENDIX 2. RISKS FACTORS CATEGORIZATION
Risk Risk Factors and
Low Risk (L) Medium Risk (M) High Risk (H)
ID Categories
Organization management factors
More than three key project
Project staff are expected to One or more key project staff
staff are expected to leave
R1 Project team stability stay with for the duration of are expected to leave before
before their accountabilities
the project their accountabilities are met
are met
All project processes are One or more important and More than three important and
R2 Project processes defined and being followed complex project processes not complex project processes not
defined or being followed defined or being followed
Customer factors
End-users are highly End-users have no previous
End-users have experience
experience in similar projects, experience with similar project,
R3 Customer experience with similar project and have
have specific ideas on how unsure of how needs can be
needs in mind
needs can be met met
End-users accept concepts End-users accept most
End-users do not accept any
and details of system, process concepts and details of
R4 Customer acceptance concepts or design details of
is in place for end-user system, process in place for
system
approvals end-user approvals
Budget/cost factors
Cost Variance (CV) shows that Cost Variance (CV) shows that Cost Variance (CV) shows that
R5 Budget fit project is in line with or under project is exceeding budget by project is exceeding budget by
budget 1-5% more than 5%
Cost Performance Indicator Cost Performance Indicator Cost Performance Indicator
R6 Cost performance (CPI) has a value of (CPI) has a value of 0.9 <= CPI (CPI) has a value of 0.9 >
0.95 <= CPI <= 1.1 <= 1.2 CPI > 1.2
R7 Cost controls Well-established, in place System in place, weak in areas System lacking or non-existent
Schedule factors
Unstable, fluctuating
R8 Delivery commitment Stable commitment dates Some uncertain commitments
commitments
Schedule Variance (SV) shows Schedule Variance (SV) shows Schedule Variance (SV) shows
R9 Schedule fit that project is in line with or that project is exceeding that project is exceeding
under schedule schedule by 1-5% schedule by more than 5%
Schedule Performance Schedule Performance Schedule Performance

R10 Schedule performance Indicator (SPI) has a value of Indicator (SPI) has a value of Indicator (SPI) has a value of
0.95 <= SPI <= 1.1 0.9 <= SPI <= 1.2 0.9 >SPI > 1.2
Project content factors
Most or all of the
Software requirements easy to Some requirements hard to
R11 System testability system hard to test, or no
test, planning underway test, or test plans insufficient
planning being done
Some elements of the system No clear plan or schedule for
Clearly defined dependencies
are well-understood and how the whole system will
R12 System dependencies of the software effort and
planned, others are not yet come together
other parts of the system
comprehended
Little chance of getting
Documents will be available on Some documents may be late documents on time, many
R13 Documents stability
time and will contain few errors and contain minor errors corrections and changes
expected
98
Risk Risk Factors and
Low Risk (L) Medium Risk (M) High Risk (H)
ID Categories
Performance factors
Modular design allows for Modular design aids No modular design or ability to
R14 Test capability easy coverage test planning developing test harnesses for easily establish test coverage
and execution unit test planning
Good estimate available, Rough estimate of test time, Poor or no estimate of test
R15 Expected test effort readily fits system acceptance may be a bottleneck in the times, definite chance of
process process bottleneck
Defined software product Defined software product has Defined software product has
R16 Functionality highly functional, meets all good functionality, meets most little functionality, many
customer needs customer needs customer needs not met
Clearly communicates goals Rarely communicates clearly to
Communicates some of the
R17 Communication and status between the team the team or to other who need
information some of the time
and the rest of the organization to be informed of team status
Project manager has no

Project manager very Project manager has moderate
experience with this type of
R18 Project manager experience experienced with similar experience or has experience
project or is new to project
projects with different types of projects
management
Development process factors
Quality assurance QA system established, Procedures established, but No QA process or established
R19
approach followed, effective not well followed or effective procedures
Development process in place,Development process
Use of defined engineering
R20 established, effective, followed
established, but not followed No formal process used
process
by team or is ineffective
Change control process in
Change control for work Formal change control process No change control process
R21 place, not followed, or is
products in place, followed, effective used
ineffective
Development environment factors
Tools invalidated,
Tools available, validated,
Tools in place, documented, proprietary, or major
R22 Tools availability some development needed (or
validated development needed, no
minimal documentation)
documentation
Complete support Adequate support at Little or no
R23 Vendor support at reasonable price and in contracted price, reasonable support, high cost, and/or
needed time frame response time poor response time
Staff factors
Staff in place, no turnover Staff not available, high
Staff available, some turnover
expected, working on assigned turnover expected, many
R24 Staff adherence to task expected, some conflict in time
tasks, few diversions and little members spend much time fire
allocation, some fire fighting
fire fighting fighting
Training not Training for some areas not

Training of team No training plan or training not
R25 required, or training plan in available or training planned
readily available
place and training ongoing for future
All milestones met, Milestones met,
Productivity low, milestones
R26 Team productivity deliverables on time, some delays in deliverables,
not met, delays in deliverables
productivity high productivity acceptable
Maintenance factors
In place, experienced, Missing some areas of Significant discipline or
R27 Support personnel
sufficient in number expertise expertise missing
99

NASA Test and Evaluation Master Plan

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

NASA Test and Evaluation Master Plan

Загружено:

Авторское право:

Доступные форматы

SDM 5004 System Engineering and Project Management

Multi-satellite Operations Control Center (MSOCC)

Division of Engineering & Technology Management (D-ETM)

SDM 5004 System Engineering and Project Management

MULTI-SATELLITE OPERATIONS CONTROL CENTER (MSOCC)

02 May 2011 A0000660B

Aditya Nugroho Date Matriculation Number

Dr. Joseph E. Kasser Date

*A - ADDED M - MODIFIED D – DELETED

00 18.04.2011 TEMP Paragraph M Knowledge component in the Dr. Joseph E.

ID SUMMARY OF REQUIREMENT TYPE SECTION

An introduction to Project Management and

02 Modern project management Written Section 4 Page 17

03 Project Selection and Strategy Written Section 3 Page 11

04 Project Organisation Written Section 3 Page 8

05 Project Planning Written Section 4 Page 17

06 Scheduling Written Section 4 Page 20

07 Cost Estimating Written Section 4 Page 30

09 Performance Monitoring Written Section 4 Page 35

10 Project Leadership Written Section 3 Page 11

12 Constraint Management Written Section 4 Page 40

14 Project Audit and Closeout Written Section 4 Page 43

Lessons Learned Written Section 5 Page 46

Footnotes the knowledge component Written Appropriate Section

RECORD OF CHANGES ............................................................................................................. III

Table 1. 1 T&E Assumptions .......................................................................................................... 1

Table 3. 1 Requirements Verification Matrix ................................................................................. 6

Table 4. 1 WBS Dictionary of T&E activities .............................................................................. 19

Figure 2. 1 Switch configuration ..................................................................................................... 4

Figure 3. 1 MCSS T&E Vee Model ................................................................................................ 8

Figure 4. 1 Work Breakdown Structure for T&E activities .......................................................... 18

This section lists all the documents referenced in the TEMP.

Table 1. 2 Document Reference

2 MSOCC MCSS Systems Engineering Management Plan (SEMP). Presented in Session 8.

NASA/GSFC, Multi-Satellite Operations Control Center (MSOCC) Communications

Systems Engineering – System Life Cycle Processes, International Organization for

2.1 MCSS Mission Description

2.2 MCSS System Description

3.1 Test and Evaluation Objectives

To ensure conformance with requirements contained in the System Requirements Documents

Table 3. 1 Requirements Verification Matrix

5.2 SWITCH MATRIX

Table 3. 2 T&E Document Deliverables

Phase ID Document Deliverables Due Date

Qualification Final Test Acceptance Report Document

Closeout F500 Project Final Report 14 May 2011

Identify User Needs Demonstarate and

Figure 3. 1 MCSS T&E Vee Model

3.3 Management Organization and Responsibilities

3.3.1 External Interfaces

3.3.2 Internal Interfaces

MCSS System and

MCSS Test and

Figure 3. 3 MCSSRP Matrix Organization Structure

MCSS System and MCSS Test and MCSS Quality Assurance

Requirements Configuration Item Quality Assurance

• System engineer • System engineer

Figure 3. 4 MCSSRP Organization Structure

2) External responsibilities: The PM is the principal point of contact for maintaining

3.3.3 Project Team Roles and Responsibilities

Provides testing management oversight.

Engineering staff responsible for  Senior Test Engineer (R4)  Type V

An organizational team, responsible for QA

Resource Unit Rate/Day