Rev.
ECO
Description
Author
Approved
Date
1
37-080
Initial version
Ed Morgan
N/A
04/15/14
A
37-101
Baseline
Ed Morgan
Yes
08/15/14
B
37-227
Update
Cory Heiges/Ed
Morgan
RFGoeke
7/22/15
TESS
POC Software Development Plan
Dwg. No. 37-71002
Revision B
March 20, 2015
37-71002
i
Revision B
Preface
This is the TESS PCOC Software Development Plan. It describes the overall development plan for the TESS Payload
Operations Center software. It follows the guidelines provided by NASA's NPR 7150.2a.
Rev 01 was the initial release.
Revision A- was the version for peer review. Following approval by the Configuration Change Board, it became
version A.
Revision B incorporated comments from the 10 December 2014 informal review with NASA/GSFC software and software
quality. These changes include replacing references to GitLab with references to Trac throughout the document. We added
more Risk Management to alleviate the need for a separate Risk Management Plan. We resolved compliance issues in Appendix B. Changes were made to clarify the configuration management section as suggested by RFA-9 from the POC Engineering Peer Review.
37-71002
ii
Revision B
List of TBDs and TBRs
Topic
Description
.
37-71002
iii
Revision B
Table of Contents
1
Introduction .............................................................................................................................. 1
1.1
1.2
1.3
1.4
1.5
2
3
Purpose ..........................................................................................................................................1
Scope .............................................................................................................................................1
Document Structure........................................................................................................................1
Applicable Documents ....................................................................................................................1
Abbreviations .................................................................................................................................1
Background ............................................................................................................................... 3
Management and Development Plan ......................................................................................... 3
3.1 Organizational Structure (a) ............................................................................................................3
3.1.1 Project Manager (NASA/GSFC)........................................................................................................... 3
3.1.2 Ground Segment Development Manager (NASA/GSFC) .................................................................... 3
3.1.3 Science Operations Center Lead ........................................................................................................ 4
3.1.4 Payload Operations Center Manager ................................................................................................. 4
3.1.5 Project Engineer ................................................................................................................................. 4
3.1.6 Payload Operations Center Developer(s) ........................................................................................... 4
3.1.7 Chief Safety and Mission Assurance Officer (NASA/GSFC) ................................................................. 4
3.1.8 Instrument Project Quality Lead ........................................................................................................ 4
3.1.9 Payload Operations Center Software Quality .................................................................................... 4
3.2 Safety and Criticality Classification (b) .............................................................................................4
3.3 Tailoring Compliance Matrix (c) .......................................................................................................5
3.4 Engineering Environment (d) ...........................................................................................................5
3.4.1 Location and Facilities ........................................................................................................................ 5
3.4.2 Test Hardware/Software .................................................................................................................... 5
3.5 Work Breakdown Structure (e) ........................................................................................................5
3.6 Management of Quality Characteristics (f) .......................................................................................8
3.7 Management of Safety, Security, and Privacy (g) ..............................................................................9
3.7.1 Safety.................................................................................................................................................. 9
3.7.2 Security............................................................................................................................................... 9
3.7.3 Privacy ................................................................................................................................................ 9
3.8 Subcontractor Management (h) .......................................................................................................9
3.9 Verification and Validation (I) ..........................................................................................................9
3.10 NASA Involvement (j) .................................................................................................................. 10
3.11 User Involvement (k) .................................................................................................................. 11
3.12 Risk Management (l) ................................................................................................................... 11
3.13 Security Policy (m) ................................................................................................................................ 11
3.14 Approvals Required (regulatory, certifications, proprietary, etc) (n) .............................................. 11
3.15 Process for Scheduling, Tracking and Reporting (o) ...................................................................... 11
3.16 Training (p) ................................................................................................................................. 12
3.17 Software Life-Cycle Model (q) ..................................................................................................... 12
3.17.1 Overview and Rationale ................................................................................................................. 12
3.17.2 Requirements Definition ................................................................................................................ 12
3.17.3 Preliminary Design ......................................................................................................................... 13
3.17.4 Detailed Design .............................................................................................................................. 13
37-71002
iv
Revision B
3.17.5 Software Development .................................................................................................................. 13
3.17.6 Software Testing ............................................................................................................................. 14
3.17.7 Software Delivery ........................................................................................................................... 14
3.18 Configuration Management (r) .................................................................................................... 14
3.18.1 Project Organization (r.a) ............................................................................................................... 15
3.18.2 Responsibilities (r.b) ....................................................................................................................... 15
3.18.3 Policies and Directives (r.c)............................................................................................................. 15
3.18.4 Functions and Tasks (r.d) ................................................................................................................ 15
3.18.4.1 Part Identification ....................................................................................................................................15
3.18.4.2 Configuration Control ..............................................................................................................................15
3.17.4.3 Status Accounting ........................................................................................................................................16
3.17.4.4 Configuration Audits and Reviews ...............................................................................................................16
3.18.5 Sequence and Coordination (r.e) ................................................................................................... 16
3.18.6 Resources (r.f) ................................................................................................................................ 16
3.18.7 Plan Maintenance (r.g) ................................................................................................................... 16
3.18.8 Release Management and Delivery (r.h) ........................................................................................ 16
3.19 Software Documentation Tree (s) ................................................................................................ 17
3.20 Software Peer Review Process (t) ................................................................................................ 17
3.21 Test requirements affecting design decisions (u) .......................................................................... 18
3.22 Software metrics (v) ................................................................................................................... 18
3.23 Content of software documentation (w) ...................................................................................... 18
3.24 Management approach for COTS, GOTS, MOTS, FLOSS (x) ............................................................ 19
Appendix A
Sample Development Phase Checklists ................................................................... 20
Appendix B
Sample Software Review Checklists ........................................................................ 24
Appendix C
NPR 7150.2a Compliance Matrix............................................................................. 26
Tables
Table 1: Applicable Document List .......................................................................................................... 1
Table 2: Abbreviation Definitions ............................................................................................................. 1
Table 3: Quality Characteristic Management Activities ........................................................................... 8
Table 4: Software Life-cycle V&V Activities ........................................................................................... 9
Figures
Figure 1: Software Documentation Tree .................................................................................................. 17
37-71002
v
Revision B
TESS POC Software Development Plan
22/March/2016
1 Introduction
1.1 Purpose
The purpose of this document is to describe the process and methods to be followed for software development for the
Transiting Exoplanet Survey Satellite (TESS) Payload Operations Center (POC) software, the approach to be followed
for each activity and to outline the software schedule, organization and resources.
1.2 Scope
The scope of this document applies to the TESS POC Software. It does not apply to other ground software, spacecraft
software or ground-support equipment software.
1.3 Document Structure
The structure of this document starts with this introductory section followed by a brief overview. The remainder of the
document structure follows line by line the items listed in 5.1.1.1 of NASA NPR 7150.2A [SWE-102].
1.4 Applicable Documents
Document #
Document
NASA NPR 7150.2A
NASA Software Engineering Requirements
NASA-STD-8739.8
NASA Software Assurance Standard
NASA-STD-8719.13
NASA Software Safety Standard
MKI/37-10001
TESS Mission Assurance Requirement (MAR)
MKI/37-10031
TESS Project Management Plan
MKI/37-11001.11
TESS Configuration Management and Review Process
MKI/37-11502.01
Payload Operations Center Requirements Document
MKI/37-71050
TESS POC IT Risk Assessment
Table 1: Applicable Document List
1.5 Abbreviations
Description
Abbreviation
ADC
AR
Analog-to-Digital Converters
Acceptance Review
ASCII
American Standard Code for Information Interchangee
CASE
Computer-Aided Software Engineering
CCB
Configuration Control Board
CCD
Charge Coupled Device
CDR
Critical Design Review
CMP
Configuration Management Plan
CPU
Central Processing Unit
CSCI
Computer Software Configuration Items
CSO
Chief Safety and Mission Assurance Officer
37-71002
1
Revision B
TESS POC Software Development Plan
22/March/2016
Description
Abbreviation
DHU
Data Handling Unit
EDU
Engineering Development Unit
EEPROM
Electrically Erasable Programmable Read Only Memory
FDIR
Fault Detection Isolation and Recovery
FPGA
Field Programmable Gate Array
FSW
Flight Software
GNU
GNU is not Unix
GOLD
GPL
Goddard Open Learning Design
GNU Public License
GSFC
Goddard Space Flight Center
GSIT
Ground Systems Integration Test
HW
Hardware
ICD
Interface Control Document
IT
JWST
KSLOC
LL
MAESTRO
Information Technology
James Webb Space Telescope
Thousands of Source Lines of Code (i.e. 1 KSLOC == 1000 source lines of code)
Lincoln Laboratory
Mission Adaptive Environment for Spacecraft Test and Real-Time Operations
MAR
Mission Assurance Requirements
MIT
Massachusetts Institute of Technology
NASA
National Aeronautics and Space Agency
NPR
NASA Procedural Requirements
OS
Operating System
PCI
Peripheral Component Interconnect
PDF
Portable Document Format
PDR
Preliminary Design Review
PM
Project Manager
POC
Payload Operations Center
PPBE
Project Planning, Budget, and Execution
PROM
Programmable Read Only Memory
R/W
Read-Write
ROM
Read-Only Memory
SLOC
Source Lines of Code
SMAD
Safety and Mission Assurance Directorate
SRR
SPOC
STD
37-71002
Software Requirements Review
Science Processing Operations Center
Standard
2
Revision B
TESS POC Software Development Plan
22/March/2016
Description
Abbreviation
SVN
Subversion
SW
Software
TBD
To Be Determined
TBR
To Be Reviewed
TESS
Transiting Exoplanet Survey Satellite
TRR
Test Readiness Review
TSO
TESS Science Office
UML
Universal Modeling Language
Table 2: Abbreviation Definitions
2 Background
The Transiting Exoplanet Survey Satellite (TESS) is a two year survey mission that will focus on the discovery of
exoplanets in orbit around the brightest stars in the sky. This first-ever spaceborne all-sky transit survey will identify
planets ranging from Earth-sized to gas giants, around a wide range of stellar types and orbital distances. TESS will
provide prime targets for follow-up observation using the James Webb Space Telescope (JWST), as well as other large
ground-based and space-based telescopes.
The TESS instrument consists of four cameras, each with a Charge Coupled Device (CCD) developed by MIT/Lincoln
Laboratory. The electronics architecture consists of clocking electronics for the CCDs, analog processing chain and
Analog-to-Digital Converters (ADC) for the data from the CCDs, one or more Field Programmable Gate Arrays
(FPGA) to handle high-performance, low-level processing of the CCD data, instrument/satellite communications
logic, a KA-band instrument radio for high-volume downlink, and a Data Handling Unit (DHU) computing element.
At a very high-level, the baseline responsibilities of this software consists of tools to plan, operate, maintain and
process data from the TESS Payload.
After launch the POC will be responsible for the maintenance of the DHU flight software. The Flight Software is
covered under different Development and Maintenance Plans, that will continue to be enforced in the POC. No
additional software will be developed by the POC for FSW maintenance.
3 Management and Development Plan
3.1 Organizational Structure (a)
This section describes the TESS Project organizational structure from the software perspective. For the overall project
organization, refer to the TESS Project Management Plan (MIT/37-10031).
3.1.1 Project Manager (NASA/GSFC)
From the TESS Project Management Plan (MIT/37-10031): “The TESS Project Manager(PM) has overall
responsibility for ensuring the performance of all functions necessary for managing and implementing the project. The
PM is responsible for project-wide planning and evaluation; personnel management; contracts, systems development,
integration and test, reliability, quality assurance; system safety; configuration management of the TESS instrument,
spacecraft, and ground system. The PM is responsible for developing the TESS life cycle costs and yearly Project
Planning, Budget, and Execution (PPBE) operating plan inputs and submitting them to the Explorer Program Office.”
3.1.2 Ground Segment Development Manager (NASA/GSFC)
The TESS Project Management Plan (MIT/37-10031) calls for a Ground Segment Development Manager (GSDM).
The GSDM is responsible to the PM for developing and implementing ground system requirement, flight data
processing/data capture, science data distribution system, ground network/communications in support of flight
37-71002
3
Revision B
TESS POC Software Development Plan
22/March/2016
operations. Before launch, the GSFD is responsible for ensuring that operational requirements have been met,
including the conduct of all tests necessary to verify and validate the operation of the end-to-end TESS ground system.
During the science phase of the TESS mission, the MOM provides the management and programmatic support for the
operations of the mission not including science, and science operations.
3.1.3 Science Operations Center Lead
The TESS Project Management Plan (MIT/37-10031) calls for a Science Operations Center Lead who oversees the
operation of the Payload Operations Center (POC) and the Science Processing Operations Center (SPOC). The
Science Operations Center Lead reports technical issues to the Ground Segment Development Manager.
3.1.4 Payload Operations Center Manager
The Payload Operations Center Lead is tasked with ensuring the successful operation of the instrument. This includes
the generation of the science command load, and working with the MOC to verify command loads prior to upload to
the spacecraft. In addition, the POC Lead oversees the collection and maintenance of calibration data utilized in
pipeline processing, and monitors instrument housekeeping data for instrument state-of-health. The Payload Operation
Center Lead reports to the Science Operations Center Lead.
3.1.5 Project Engineer
The Instrument Project Engineer leads the overall development of the instrument and acts as the instrument systems
engineer. The Project Engineer coordinates the multi-disciplinary engineering team in the specification, design,
construction, test and operation of the TESS cameras and data handling unit.
3.1.6 Payload Operations Center Developer(s)
The Payload Operations developer(s) report to the instrument project engineer, but receive software direction from the
POC Manager. Their responsibilities include software detailed design, implementation, unit test and integration under
the direction of the lead software engineer. They're also responsible for contribution and review to the software
requirements, software architectural design, software test procedures and reports, software version description/release
notes, and defect reports and resolution.
3.1.7 Chief Safety and Mission Assurance Officer (NASA/GSFC)
The Chief Safety and Mission Assurance Officer (CSO) is responsible to the Project Manager (PM) for all flight
assurance disciplines of the project to ensure that the spacecraft, instruments, and ground system equipment will meet
their intended performance objectives. These disciplines include quality assurance, independent design review,
reliability, system safety, and verification testing. The CSO does not administratively report to the PM. In the event
disputes between the PM and the CSO cannot be resolved, the CSO can appeal to the GSFC Director of Safety and
Mission Assurance. The CSO reports to the GSFC Safety and Mission Assurance Directorate (SMAD) and maintains
independence via that office.
3.1.8 Instrument Project Quality Lead
The Instrument Project Quality Engineer is responsible to the CSO for all assurance disciplines of the instrument to
ensure that it meets its intended performance objectives. These include quality assurance, design review, reliability,
system safety and verification.
3.1.9 Payload Operations Center Software Quality
Payload Operations Center Software Quality reports to the Instrument Quality Lead. The software quality role is
responsible for ensuring the POC team maintains quality, reliability and safety standards in the development process
and supports the software verification and validation process as precursor to system integration and test.
3.2 Safety and Criticality Classification (b)
The TESS Mission Assurance Requirements (MAR) (MKI/37-10001) classify the mission as Class C, which flows
37-71002
4
Revision B
TESS POC Software Development Plan
22/March/2016
down to the TESS Project Management Plan (MKI/37-10031) indicating that TESS is categorized as a Category 2
mission with a Class C.
The POC software will consist of the following Computer Software Configuration Items (CSCIs):
•
Telemetry Processing
•
Command Generation
•
Mission Planning
•
Instrument Monitoring and Calibration
The TESS project has classified all POC software as class C.
3.3 Tailoring Compliance Matrix (c)
Appendix C contains the NPR 7150.2a compliance matrix for the POC Software CSCIs.
3.4 Engineering Environment (d)
3.4.1 Location and Facilities
POC software development will primarily occur at MIT's Cambridge campus Kavli Institute offices using MIT-issued
computers and networked via the office and campus networking facilities. Occasionally, non-ITAR related
development may occur off-site (such as during transit, at home, etc.) using MIT-issued or personal computers. ITAR
related development, however, must occur with appropriate safe-guards to prevent transfer of controlled material to
non-US persons.
Software development will utilize standard off-the-shelf computing resources. Software development will occur using
Apple's OS/X or GNU/Linux operating systems.
Plans, requirements, design, and report documents will be authored and edited using developer-selected tools capable
of producing Portable Document Format (PDF) with the stipulation that non-Microsoft Office based documents be
editable using freely available software, such as LibreOffice, Latex, emacs, etc.
Given the anticipated size of the software development effort (< 30K Source Lines of Code (KSLOC) per CSCI), we
don't anticipate a need to use Computer-Aided Software Engineering tools (CASE), such as Rational Rose or
ArgoUML, but instead reserve the right to utilize these tools should the need arise.
The software coding effort will produce ASCII source files, created and edited using developer-selected tools, such as
Eclipse, emacs, or gedit.
The software build tools will consist mainly of open source compilers (gcc, python) although some CSCIs may use
MATLAB or IDL.
The software static analysis tools will be evaluated and selected during the Software Architectural Design phase of the
effort.
3.4.2 Test Hardware/Software
Testing of the Command Generation and Telemetry Processing software requires access to a properly configured
MAESTO station, a S/C simulator, a DHU EDU and a KaBand simulator.
3.5 Work Breakdown Structure (e)
The following is an initial work breakdown structure, with coarse functional element place-holders.
1 Develop and Maintain POC Software
1.1
Plan, Document, and Review Software Development Effort
1.1.1
Document Software Development Plan
1.1.2
Review and Revise Software Development Plan
1.1.3
Document Software Assurance Plan
1.1.4
Review and Revise Software Assurance Plan
37-71002
5
Revision B
TESS POC Software Development Plan
22/March/2016
1.2
Develop and establish development standards, tools, and templates
1.2.1
Develop, Document and Review Architectural Design Standards
1.2.2
Develop, Document and Review Coding Standards and Templates
1.2.3
Develop, Document and Review Software Build Tools/Scripts
1.2.4
Evaluate, Setup and Document Static Analysis Tools
1.2.5
Setup and Document Software Version Control System and Procedures
1.3
Monitor Software Development Effort
1.3.1
Collect, Evaluate and Report Requirements Metrics
1.3.2
Collect, Evaluate and Report Architectural Metrics
1.3.3
Collect, Evaluate and Report Code Metrics
1.3.4
Collect, Evaluate and Report Non-Conformances
1.3.5
Track, Evaluate and Report Progress and Risks
1.3.6
Track, Update and Report Schedule Progress
1.4
Develop Instrument Command Generation Software
1.4.1
Plan, Document, and Review Command Generation Requirements
1.4.2
Develop, Document and Review Command Generation Architectural Design
1.4.3
Develop, Document and Review Command Generation Detailed Design
1.4.4
Build for Ground System Integration Test 1
1.4.4.1 Implement and Unit Test Command Generation
1.4.4.2 Integrate Command Generation with with MAESTRO and DHU
1.4.4.3 Verify Command Generation against Software Requirements
1.4.4.4 Validate Command Generation GSIT 1 Requirements
1.4.5
Build for Ground System Integration Test 2
1.4.5.1 Implement and Unit Test Command Generation
1.4.5.2 Integrate Command Generation with with MAESTRO and DHU
1.4.5.3 Verify Command Generation against Software Requirements
1.4.5.4 Validate Command Generation GSIT 2 Requirements
1.4.6
Build for Ground System Integration Test 3
1.4.6.1 Implement and Unit Test Command Generation
1.4.6.2 Integrate Command Generation with with MAESTRO and DHU
1.4.6.3 Verify Command Generation against Software Requirements
1.4.6.4 Validate Command Generation GSIT 3 Requirements
1.5
Develop Telemetry Processing Software
1.5.1
Plan, Document and Review Telemetry Processing Requirements
1.5.2
Develop, Document and Review Telemetry Processing Architectural Design
1.5.3
Develop, Document and Review Telemetry Processing Detailed Design
1.5.4
Build for GSIT 1
1.5.4.1 Implement, Unit Test and Integrate Telemetry Processing Modules
1.5.4.2 Integrate Telemetry Processing
1.5.4.2.1 Engineering Hardware
1.5.4.2.2 SPOC
1.5.4.2.3 Instrument Monitoring
1.5.4.3 Verify Telemetry Processing against Software Requirements
1.5.4.4 Validate Telemetry Processing GSIT 1 Requirements
1.5.5
Build for GSIT 2
1.5.5.1 Implement, Unit Test and Integrate Telemetry Processing Modules
1.5.5.2 Integrate Telemetry Processing
1.5.5.2.1 Engineering Hardware
1.5.5.2.2 SPOC
1.5.5.2.3 Instrument Monitoring
1.5.5.3 Verify Telemetry Processing against Software Requirements
1.5.5.4 Validate Telemetry Processing GSIT 2 Requirements
1.5.6
Build for GSIT 3
1.5.6.1 Implement, Unit Test and Integrate Telemetry Processing Modules
1.5.6.2 Integrate Telemetry Processing
1.5.6.2.1 Engineering Hardware
37-71002
6
Revision B
TESS POC Software Development Plan
22/March/2016
1.5.6.2.2 SPOC
1.5.6.2.3 Instrument Monitoring
1.5.6.3 Verify Telemetry Processing against Software Requirements
1.5.6.4 Validate Telemetry Processing GSIT 3 Requirements
1.6
Develop Mission Planning Software
1.6.1
Plan, Document and Review Mission Planning Requirements
1.6.2
Develop, Document and Review Mission Planning Architectural Design
1.6.3
Develop, Document and Review Mission Planning Detailed Design
1.6.4
Build for GSIT 1
1.6.4.1 Implement, Unit Test and Integrate Mission Planning Modules
1.6.4.2 Integrate Mission Planning with Command Generation, TSO and SPOC
1.6.4.3 Verify Mission Planning against Software Requirements
1.6.4.4 Validate Mission Planning GSIT 1 Requirements
1.6.5
Build for GSIT 2
1.6.5.1 Implement, Unit Test and Integrate Mission Planning Modules
1.6.5.2 Integrate Mission Planning with Command Generation, TSO and SPOC
1.6.5.3 Verify Mission Planning against Software Requirements
1.6.5.4 Validate Mission Planning GSIT 2 Requirements
1.6.6
Build for GSIT 3
1.6.6.1 Implement, Unit Test and Integrate Mission Planning Modules
1.6.6.2 Integrate Mission Planning with Command Generation, TSO and SPOC
1.6.6.3 Verify Mission Planning against Software Requirements
1.6.6.4 Validate Mission Planning GSIT 3 Requirements
1.7
Develop Instrument Monitoring and Calibration Software
1.7.1
Plan, Document and Review Instrument Monitoring/Calibration Requirements
1.7.2
Develop, Document and Review Monitoring/Calibration Architectural Design
1.7.3
Develop, Document and Review Monitoring/Calibration Detailed Design
1.7.4
Build for GSIT 1
1.7.4.1 Implement, Unit Test and Integrate Monitoring/Calibration Modules
1.7.4.2 Integrate Instrument Monitoring/Calibration
1.7.4.2.1 Telemetry Processing
1.7.4.2.2 SPOC
1.7.4.3 Verify Instrument Monitoring and Calibration against Software Requirements
1.7.4.4 Validate Instrument Monitoring and Calibration GSIT 1 Requirements
1.7.5
Build for GSIT 2
1.7.5.1 Implement, Unit Test and Integrate Monitoring/Calibration Modules
1.7.5.2 Integrate Instrument Monitoring/Calibration
1.7.5.2.1 Telemetry Processing
1.7.5.2.2 SPOC
1.7.5.3 Verify Instrument Monitoring and Calibration against Software Requirements
1.7.5.4 Validate Instrument Monitoring and Calibration GSIT 2 Requirements
1.7.6
Build for GSIT 3
1.7.6.1 Implement, Unit Test and Integrate Monitoring/Calibration Modules
1.7.6.2 Integrate Instrument Monitoring/Calibration
1.7.6.2.1 Telemetry Processing
1.7.6.2.2 SPOC
1.7.6.3 Verify Instrument Monitoring and Calibration against Software Requirements
1.7.6.4 Validate Instrument Monitoring and Calibration GSIT 3 Requirements
1.8
Support Environmental Testing
1.9
Support Spacecraft Integration
1.10 Support Launch, Deployment and Activation
1.11 Commissioning
1.12 POC Software Maintenance
37-71002
7
Revision B
TESS POC Software Development Plan
22/March/2016
3.6 Management of Quality Characteristics (f)
The POC team will manage key software quality characteristics of the POC software, including its reliability,
efficiency, maintainability and size throughout the software development process. The compliance of the POC
software with the TESS POC IT Risk Assessment and TESS POC IT Risk Mitigation plans will monitored.
The team will manage the quality characteristics by development phase (see Section Error! Bookmark not defined.)
as follows:
Phase
Characteristic
Strategy
Reliability
Review requirements for off-nominal behaviors such
as:
- Error conditions and handling
Efficiency
Review requirements for processing throughput
Requirements
Maintainability
Size
Architectural Design
Ensure comprehensive exception handling
Efficiency
Review for and mitigate bottlenecks and critical paths
Maintainability
Review architectural design for algorithm complexity,
design element coupling and cohesion, and design
element re-use.
Inspect design for error handling completeness
Efficiency
Rapid prototype critical paths and bottlenecks
Size
Ensure architectural design elements are clearly
visible within detailed design descriptions. Consider
use of source-file-based documentation (i.e. pydoc)
for generation of detailed design documentation.
Updated function point and SLOC estimates
Reliability
Test for:
- Proper handling of malformed inputs
- Memory Leaks
Efficiency
Where needed increase margin using performance
analyzers and code optimization. Periodically
evaluate actual resource margins.
Implementation/Unit/Integration
Maintainability
Size
In-code documentation reflecting relevant
architectural and detailed design decisions, peer
code reviews, adherence to project coding standards
and naming conventions.
Actual in-progress SLOC, complexity,
implemented/tested Function Points
Reliability
Error injection testing, limits testing
Efficiency
Performance characterization and measurement.
Maintainability
37-71002
Updated function point and SLOC estimates
Reliability
Maintainability
V&V
Perform initial function point and SLOC estimates
Reliability
Size
Detailed Design
Review requirements for clarity, consistency,
completeness and scope
Updated Maintenance Manual; as-built Design
documentation
8
Revision B
TESS POC Software Development Plan
Phase
22/March/2016
Characteristic
Size
Strategy
As-built SLOC, Complexity. Running verified
Function Points.
Table 3: Quality Characteristic Management Activities
3.7 Management of Safety, Security, and Privacy (g)
3.7.1 Safety
As of this writing, no software-related hazards have been identified on the POC software. The POC team will continue
to monitor hazard analyses and will revise this plan should software-related safety attributes arise.
3.7.2 Security
Although there is no NASA requirement for POC security, the POC software will be implemented to be compliant
with the TESS IT Security Risk Mitigation Plan.
3.7.3 Privacy
The TESS POC Software will not contain nor manage anyone's personal information.
Development machines will not ask for or require anyone's personal information and are discouraged for personal use.
3.8 Subcontractor Management (h)
TESS POC Software development does not anticipate use of subcontractors.
If and when subcontractors are employed, all relevant contractual requirements will be flowed down to the
subcontractors. The subcontractors will report to the POC software lead. All products developed and delivered by the
subcontractor under their contract will include source code and be the property of MIT. All products delivered by the
subcontractor will be subject to the same software assurance rules as the software developed at MIT/Kavli.
3.9 Verification and Validation (I)
The POC team performs various verification and validation activities throughout the software lifecycle. These activities are as follows:
Phase
Methods
Work Product(s)
Environments
Results/Records
Verified/Validated
Requirements - Traceability inspection
to higher level
requirements
- Content inspection by
software, systems
engineering, science,
and quality
- Risk-reduction
prototypes
- POC
Requirements
Specification
- Desktop/paper
review and
meeting(s)
- Prototyping
computer
environment
- Updated POC
Requirements
Specification
- Emails
- Review meeting
minutes
- Archived in
software version
control system
Architectural
Design
- Software Design
Description
(Architectural
Design Elements)
- Desktop/paper
review and
meeting(s)
- Prototyping
computer
environment
- Update POC
Design Descriptions
- Updated
Requirements
Traceability
- Emails
37-71002
- Traceability inspection
to software requirements
- Content inspection by
software, systems
engineering, science and
quality
9
Revision B
TESS POC Software Development Plan
Phase
Methods
22/March/2016
Work Product(s)
Environments
Results/Records
Verified/Validated
- Risk-reduction
prototypes of interfaces
and critical algorithms
Detailed
Design
- Traceability inspection
to architectural design
elements and
corresponding software
requirements
- Content inspection by
software, systems
engineering, science and
quality
- Risk-reduction
prototypes
Implementation - Traceability inspection
- Review meeting
minutes
- Archived in
software version
control system
- Software Design
Description
(Detailed Design
Elements)
- Code Stubs
- Desktop/paper
review and
meeting(s)
- Static analysis
- Prototyping
computer
environment
- Update POC
Design Descriptions
- Updated
Requirements
Traceability
- Updated Source
Skeletons
- Emails
- Review meeting
minutes
- Archived in
software version
control system
- Source code
- Desktop/paper
review and meetings
or on-line code
review tool
- Unit testing
- Software
integration testing
- Updated source
code
- Code review
reports
- Unit test reports
including coverage
- Module integration
reports
- Archived in
software version
control system
- Released code
packages
- Integration with
MAESTRO and
other ground system
elements
- Desktop for certain
types of inspection
and/or analysis
- Updated SW
Requirements
Verification Matrix
- SW Test Reports
- SW Inspection
Reports
- Software Problem
Reports
- Engineering
Change Orders
- Archived in the
TESS Configuration
Database
to design elements (via
code review)
- Content inspection by
software, systems
engineering, science and
quality
- Static code analysis
- Unit testing
- Continuous Integration
testing
V&V
- Execution of written
demonstration and/or
test procedures/scripts
- Quality inspection of
design/code
- Paper or numerical
analysis
Table 4: Software Life-cycle V&V Activities
3.10 NASA Involvement (j)
The NASA Goddard Space Flight Center (GSFC) is responsible for project management. The NASA Ames Research
Center is a responsible for the Science Processing Operations Center (SPOC), building on the heritage and expertise
developed for the Kepler mission.
37-71002
10
Revision B
TESS POC Software Development Plan
22/March/2016
NASA personnel will participate in all major software reviews (Requirements, Preliminary Design, Critical Design,
Test Readiness, Release) and will be invited to witness and provide expertise to software peer reviews.
NASA personnel will be granted access to all software requirements, design, code and test artifacts.
3.11 User Involvement (k)
Members of the science team will be intimately involved in the software requirements development, all major
software review, code review and verification activities. Some science team members will also be involved in the
software development in the POC.
Additionally, the science team will participate in validation activities to ensure the data produced by the instrument
meet the scientific objectives of the mission. The SPOC and the TESS Science Office will also be involved in the
Ground Segment Intea
3.12 Risk Management (l)
The POC team is responsible for managing all POC associated risks. The POC manager will maintain the risk
database and report all POC associated risks on a monthly basis to the TESS project and MKI management. Any POC
team member can submit a risk to the risk board (see below), all new risks will be reviewed and either accepted or
rejected. The risk board will meet on a ~monthly basis to review any new risks and status current risks. The POC
manager will be responsible for collecting risk updates from all of the risk owners prior to the risk board meeting.
If a new risk is accepted by the risk board, it will be submitted into the database by the POC manager with the
following information
-
Risk Title
-
Risk Statement
-
Context
-
Impacts
-
Likelihood / Consequence Ranking
-
Mitigation Approach
-
Mitigation Plan
-
Owner
-
Actions
-
Status
The POC risk board will be comprised of the POC Manager, software support staff, and a software assurance
representative. The risk board will review and report risks associated with the software development effort, at a
programmatic level (i.e. cost and schedule), a technical development risk level, and at a deployment and operational
level.
3.13 Security Policy (m)
The POC team will follow the TESS IT Security Risk Mitigation Plan.
All information subject to ITAR restrictions shall be restricted to US-persons only and retrieval will be passwordprotected.
3.14 Approvals Required (regulatory, certifications, proprietary, etc) (n)
As of this writing, no regulatory, certifications or proprietary approvals are required for the POC Software.
3.15 Process for Scheduling, Tracking and Reporting (o)
Software scheduling, tracking and reporting is managed at the instrument project management level, with inputs from
37-71002
11
Revision B
TESS POC Software Development Plan
22/March/2016
the POC team.
These inputs are generated using the following steps:
1. Identify the key tasks and activities related to each phase of the development and maintenance effort (use
module place-holders prior to the architectural design phase)
2. Estimate the time required to perform a given activity based on prior experience
3. Assign resources to the activity
4. Revise the time estimate, as needed, based on the resource(s) assigned
5. Add margin to handle uncertainties in the estimate (the margin will vary depending on the uncertainty)
6. Upon refinement of the architectural design, update the task list and estimates accordingly
7. Present the estimates to instrument team management for integration into the master schedule
Schedule tracking consists of periodic progress updates along each of the key tasks, reporting to instrument team
management for updates to the master schedule. During planning, requirements development and architectural design
stages, these updates will be rough estimates of completion of the related data products. During detailed design,
implementation and test, these estimates will be based on requirements burn-down tracking, scaled against the relative
complexity of the related modules (for example, if we've implemented 5 of 10 requirements but the estimated
complexity of the remaining 5 requirements is twice that of the first five, software would report 33% progress on the
implementation).
The instrument team managers integrate the inputs from the software development team and periodically report the
master schedule to NASA.
3.16 Training (p)
No formal project specific training has been identified or expected beyond the experience and qualifications of the
POC personnel. Informal project-specific equipment training will occur between team members on an as-needed basis.
We do not currently expect to maintain formal records of this training.
In the unlikely event POC personnel are required to come into physical contact with flight hardware (normally, trained
technicians perform all physical operations on flight hardware, including cabling and wiring), the project will provide
proper handling and static-control training and will require this training prior to granting physical access to the flight
hardware. Access to development hardware will require informal one-on-one static-control training and setup by a
qualified technician.
3.17 Software Life-Cycle Model (q)
3.17.1
Overview and Rationale
The software development environment provided by the POC will support a formal software lifecycle from design
through maintenance of maintenance of mature production modules.
The Software Development Methodology will follow an iterative software development cycle with rapid prototyping
of key elements. The software will be released at pre-determined milestones to assess build status and quality. Each
release will build on new functionality of the previous release. The various stages of the software lifecycle are
described in the following subsections.
3.17.2
Requirements Definition
The objective of this phase is to identify and generate meaningful requirements for the specific system being
considered. This phase begins with the decomposition of the relevant TESS Mission Requirements Document (MRD)
and leads to the generation of a Software Requirements Document for the POC.
This phase is typically done once for a system regardless of the number of iterative build cycles it goes through
although the requirements will be reviewed and updated as the TESS Project evolves. In each build cycle, the
37-71002
12
Revision B
TESS POC Software Development Plan
22/March/2016
requirements that are to be satisfied by the software development in that cycle are identified. In situations where the
development in a given build cycle will not fully satisfy the requirement, the level of compliance to the requirement
that is to be expected upon completion of the build cycle will be documented.
3.17.3
Preliminary Design
The objective of this phase is to define the system and software elements from the system requirements. The basic
subsystem and software design elements and requirements are generated and documented during this build phase.
Additionally, a Verification Plan will be developed during this phase. The Preliminary Design phase is completed with
an internal Preliminary Design Review (PDR).
Design artifacts will be captured and documented in the Architectural section of the Software Design Document. The
Software Design Document will be documented and considered “preliminary” by PDR.
3.17.4
Detailed Design
The objective of the Detailed Design phase is to fully define the systems, subsystems and software elements from the
requirements. The system, subsystem and software design elements and descriptions are documented during this
phase. System level test planning will be performed during this phase and a draft system level test plan should be
generated for approval. The Detailed Design phase is completed with an internal Critical Design Review (CDR). Key
elements of the design should be identified and considered for rapid-prototyping.
New CSCIs (not previously released) will utilize both a Preliminary and a Detailed Design phase. The Software
Management Plan (SMP) allows that the Maintenance Release Lifecycle will be utilized for software that has been
previously released.
Software maintenance modifies the software development lifecycle to allow Preliminary and Critical Design Reviews
to be compressed into a single Design Review. This single Design phase is repeated for each build cycle to update the
design based on changing requirements and Software Problem Reports (SPRs) filed on earlier versions of the system.
3.17.5
Software Development
The Software Development phase begins after a Critical Design Review (CDR) for that CSCI has been completed and
the design developed in the Detailed Design phase has been approved. In practice, a significant amount of software
development typically begins in the requirements definition phase to determine the scope of requirements and to
evaluate prototype designs.
This phase includes software development and coding for all relevant Computer Software Configuration Items
(CSCIs) identified in the design. In addition to the software development, the Verification Plan will be finalized and
test procedures for the system will also be developed. The Software Development phase ends with all the subsystem
CSCIs being brought under baseline configuration and ready to begin formal testing as specified in the related test
plans and procedures.
POC software development will be iterative. Builds will be delivered at pre-planned milestones that allow for
incremental testing and verification. Building iteratively allows for the addition of phased functionality built on a
proven prior build.
Software development includes any informal/formal peer review process either prior to code check-in or at code
commit. Scheduled code reviews occur as needed.
Automated builds occur via the Jenkins build system when code is checked-in the source code repository. The
automated build ensures that code components compile, build and pass unit test (aka smoke test). Then an overall
build is smoke tested with a small amount of science data to exercise the build and look for failures.
Defects are logged using the a bug tracking system and go through a standard review, resolution, fix, test, verify, close
workflow.
Builds are identified by a three digit numbering scheme (A.B.C) where A indicates a major release (new requirements,
architecture, functionality), B indicates a minor release (new functionality or some design changes) and C indicates
bug fixes. For example, the first release of the POC software would be identified as POC v1.0.0. Code and builds
identified for release are tagged accordingly in the software repository for SCM purposes.
37-71002
13
Revision B
TESS POC Software Development Plan
22/March/2016
Builds and branches in the software repository go hand-in-hand when maintaining the software and the following
branching strategy is used by the POC:
•
Once development completes for the first release, the release 1.0 branch is created
•
During V&V, fixes are committed to the release 1.0 branch
•
Once V&V completes, the release 1.0.0 tag is created and deployed to ops
•
If a fix is committed to the release 1.0 branch, then the release 1.0.1 tag is created and deployed to ops.
3.17.6
Software Testing
The Software Test phase begins once the development phase has been completed and a development baseline has been
established under configuration management for the CSCI. A Test Readiness Review (TRR) is held to determine that
the CSCI is ready to begin formal testing as outlined in the Verification Plan and Test Procedures. Formal testing
occurs during this phase, tests are performed, data are acquired, discrepancies documented, test results are
documented, results and data are reviewed, and formal test reports are generated. Formal data reviews are also
performed during the software test phase.
If changes to the software are required to correct discrepancies, the following steps shall be accomplished:
1. The modified sections of software shall be documented along with the description of the discrepancy using
the POC software problem reporting system.
2. The affected software shall be re-integrated into the affected system and a new baseline or revision
established.
3. A delta Test Readiness Review (TRR) activity shall be performed to establish the extent that previous testing
has been invalidated, and what regression or new testing is required.
The delta TRR activity should address the reuse of test information, retests required and modifications to the test
methodology. These revisions to the CSCIs and the results of the delta TRR activity shall be documented in the
appropriate locations (design documents, test plans and test reports).
Concerning Unit Testing, each developer performs unit testing of their code before or during the code check-in
process, however no deliverable artifacts from the unit testing are saved. Recording and reporting these results would
result in non-trivial additional efforts. A TRR checklist step to verify that the developer(s) have completed unit testing
may be implemented instead.
As stated earlier, the POC performs unit and smoke tests with each build via the automated build system. Verification
and Validation occurs prior to releasing/deploying the build. This occurs with a subset of the overall science data (as
using a full set requires an extensive amount of time). SQA witnesses all V&V testing events.
Testing and V&V between segments and elements must also occur and is witnessed through TESS Ground Segment
Integration Tests (GSITS) at defined milestones. Again, SQA witnesses all V&V GSIT events.
3.17.7
Software Delivery
The Software Delivery phase consists of preparing the CSCIs, associated documentation, test reports, and other
deliverable software items into media that is ready for distribution and installation. A final review/audit of the system
level documentation package and generation of the Media Release along with bringing the final version of all CSCIs
under Configuration Management shall be preformed during this phase.
Deployment of the software to the POC will follow a defined Standard Operating Procedure managed by the POC.
3.18 Configuration Management (r)
This section describes the software configuration management and how it maps into the overall TESS Configuration
management system, described in the “TESS Configuration Management and Review Process” specification (MKI/3711001.11). It is intended to satisfy the requirements for the Software Configuration Management Plan (CMP) and
follows the overall CMP structure outlined in NPR 7150.2a, Section 5.1.2.1.
37-71002
14
Revision B
TESS POC Software Development Plan
3.18.1
22/March/2016
Project Organization (r.a)
The POC configuration management consists of the Configuration Control Board (CCB) identified in the “TESS
Configuration Management and Review Process” (MKI/37-11001.11), augmented with the lead software engineer, the
responsible developer and software quality representation. This board reviews and approves all POC software
documentation and products prior to release for use outside the development team.
3.18.2
Responsibilities (r.b)
As described in the “TESS Configuration Management and Review Process” (MKI/37-11001.11), the CCB is
responsible for review, discrepancy and comment tracking and disposition, and release of all software products prior to
use.
3.18.3
Policies and Directives (r.c)
The software configuration management is governed by the internal MIT/Kavli configuration management policies
and by the “TESS Mission Assurance Requirements” (MAR) (MKI/37-10001).
3.18.4
Functions and Tasks (r.d)
3.18.4.1
Part Identification
The team will assign a part number of each software item, consistent with the convention outlined in the TESS
Configuration Management and Review Process (MKI/37-11001.11). The team will maintain a file or portion of a
document (such as an Appendix in the POC Software Design Specification) that maps the association between a given
part number and corresponding file, package, etc. Additionally, where appropriate, the part number will be contained
within the relevant document, source file, etc.
3.18.4.2
Configuration Control
During the development process, prior to release to TESS project configuration management, the software
development team will use a software version control system (e.g. git) to manage and maintain in-progress softwarerelated artifacts (i.e. on-line documentation, code, unit tests, build scripts, etc.). Formal configuration management
begins for a software element when a Level 4 requirement is met.
Once the software is prepared for release to TESS project configuration management, it will adhere to the processes
and procedures described in the TESS Configuration Management and Review Process (MKI/37-11001.11). Released
software and software artifacts require the review and approval of the TESS Configuration Control Board. While
versions of the software source artifacts will exist in the configuration management, the POC team will maintain the
build copies in the software version control system.
To this end, the team will utilize branch facilities of the version control system to maintain a record of all committed
edits to software development products as follows (note: additional development and staging branches are allowed as
needed so long as they don't interfere with the names listed below):
master (git) – In-progress development branch, developers have relatively unrestricted permission to commit to this
branch, with the warning that a continuous integration build/test system and automated metrics collection may occur
on this branch and commits that break a build may bring the ire of their co-workers.
GSIT Builds – This acts as a staging branch for candidate POC software releases for the purposes of a Ground
Systems Integration test. Software placed in this branch will have undergone some level of peer review, unit testing
and integration.
Launch Build – Copy of source code, build files and test scripts released to TESS project configuration management.
Software will be placed into this branch only after approval by the CCB via the TESS Configuration Management and
Review Process (MKI/37-11001.11).
Maintenance Builds – Maintenance Builds will be produced in accordance with the POC Software Maintenance Plan.
release_01 through release_99 – Numeric versions of software prior to release to configuration management
37-71002
15
Revision B
TESS POC Software Development Plan
22/March/2016
release_A through release_ZZZ – Letter releases where the letter matches the version maintained in the TESS
Configuration Database.
3.17.4.3 Status Accounting
The instrument project engineer and configuration manager track and provide status information concerning Engineering Change Orders (ECOs) pending review, review schedule, open items from the review, and closure,
release and distribution of the products included in the ECO. Software items released under instrument projectlevel configuration management will be included in the status tracking.
3.17.4.4 Configuration Audits and Reviews
The quality assurance team will perform periodic audits and reviews of the configuration management system
for the project as a whole, typically around major reviews and releases. Software items released under instrument
project-level configuration management will be included in these audits and reviews. Software quality assurance
will perform audits and reviews of pre-released software items with the software version control system on an
ad-hoc basis.
3.18.5
Sequence and Coordination (r.e)
The overall sequence of events during each phase of the effort is as follows:
1. Develop a software element (i.e. requirements spec, design spec, code+unit test, etc)
2. Commit intermediate versions to the electronic version control system
3. When ready, and if not already assigned, request a part number for the element and follow the TESS
Configuration Management and Review Process (MKI/37-11001.11) to release the element.
4. Once approved and if the element is final for a Build, merge into the appropriate Build version control branch
or pre_patch branch.
5. Once a CSCI for a Build has been released, coordinate with systems engineering and science on validating
interfaces with other Ground System or Instrument elements.
3.18.6
Resources (r.f)
The POC team will internally utilize electronic version control system, likely GIT, and an electronic defect tracking
system, likely Trac. This version system will require hosting on an MIT/Kavli server, with password-protected or key
network access. Official, distributed versions of data products are managed in the existing TESS Configuration
Database on the existing database server.
The general procedure is developers periodically commit working copies of software elements to the electronic
version control system, providing log information identifying the reason for the submission. When ready for release
to configuration management, the developer follows the engineering change procedure described in Section 3 of the
“TESS Configuration Management and Review Process” document (MKI/37-11001.11).
3.18.7
Plan Maintenance (r.g)
The POC team will review and revise this and the rest of the development plan as needed, typically around major
system reviews such as PDR and CDR. If changes are warranted, the team will use the review and release described
earlier to submit the updates to the main TESS Configuration Database.
3.18.8
Release Management and Delivery (r.h)
Prior to formal verification and validation testing, the POC team will create a Software Version Description document
and build and distribute a software package. The team will release the package using the standard TESS Configuration
Management and Review Process (MKI/37-11001.11). The distribution package will be maintained in electronic form,
37-71002
16
Revision B
TESS POC Software Development Plan
22/March/2016
in the TESS Configuration Database and/or software version control system.
When ready, the released package will be installed onto the operational TESS POC computers.
3.19 Software Documentation Tree (s)
Figure 1 identifies the planned software documentation for the TESS POC Software. Boxes in blue/gray are nonsoftware documents, green are the planned software documents. Where we plan for separate documents or sections for
each POC CSCI . In cases where multiple documents are planned (such as procedures, reports, etc), the annotation is
redundant and is assumed for all CSCIs.
Figure 1: Software Documentation Tree
3.20 Software Peer Review Process (t)
During the development process, prior to release to TESS project configuration management, the software review
process for documentation, code, tools and test reports will be informal and ad-hoc between developers and other team
members. Early review of documentation, code, tools and tests by non-MIT personnel will be at the discretion of the
37-71002
17
Revision B
TESS POC Software Development Plan
22/March/2016
POC manager.
In preparation for release of software documentation, code, tools, test procedures and reports, the peer review process
follows the procedure outlined by the TESS Configuration Management and Review Process (MKI/37-11001.11).
3.21 Test requirements affecting design decisions (u)
The software and science team will identify any test requirements that drive software design decisions by outlining the
test approach for each functional and interface requirement within the software requirements specification. Part of the
risk reduction strategy during requirements development will involve prototypes of high-risk requirements – this will
apply to identified test strategies within the requirements specification.
3.22 Software metrics (v)
During software requirements elaboration activities, the POC team will attempt to assess requirements volatility by
maintaining a count of the number of software requirements, and at each requirements review, note the number of
requirements that have been added, removed or modified (beyond typographical and editorial changes) since the
previous release. After the initial baseline requirements are under Configuration Management control, when the
number of requirements added, deleted or modified exceeds 33% of the previous release, software requirements
volatility will be flagged as a risk and the engineering, and if needed, science team members will meet to assess
possible causes and corrective actions.
During software architectural design, the team will attempt to measure the design complexity by tracking the number
of modules, number of interfaces provided by each module, and estimate the function points provided by each. The
team will also track the progress against the requirements, tracking the number of requirements addressed scaled by a
complexity estimate for each requirement.
During software detailed design, implementation and unit testing, the team will periodically measure and report, likely
through automated tools, the following:
1. Source lines of code (SLOC)
2. McCabe Complexity (number of paths through any given function)
3. Number of implemented requirements
4. Code coverage percentage from unit tests
5. Number of modules reviewed and released to Configuration Management
6. Estimate of memory usage
7. Estimate Processing time.
8. Estimate of communications bandwidth utilization
During Verification and Validation, following a release, the team will periodically measure and report:
1. Number of verified requirements
2. Number of defects opened
3. Number of defects resolved
4. Number of deferred defects
3.23 Content of software documentation (w)
With minor exceptions, the software documentation content and basic structure will follow the outlines provided in
NASA NPR 7150.2a, Chapter 5.
Exceptions include products not required by the software classification indicated in the TESS Mission Assurance
Requirements (MAR) (MKI/37-10001), and deviations from the “TESS Configuration Management and Review
37-71002
18
Revision B
TESS POC Software Development Plan
22/March/2016
Process” (MKI/37-11001.11), where the TESS plan and Engineering Change Order structure will take precedence over
the structure provided by NPR 7150.2a.
3.24 Management approach for COTS, GOTS, MOTS, FLOSS (x)
For all commercial, government, modified off-the-shelf software, and free/libre open source software included in the
instrument flight software, the POC team and management will:
1. Identify requirements to be met by the acquired software. This will typically be identified in the Software
Design specification.
2. Ensure that sufficient documentation is provided with the software to operate and properly utilize the
acquired software. This will be via references from the Software Design specifications to the relevant product
documentation that describes how one uses the software to achieve the desired behavior.
3. Ensure that proprietary, licensing and usage rights are addressed prior to delivering the software. The
Software Version Description documentation will contain any necessary licensing information and flowdowns (for example, the GNU Public License, GPL, would require all linked software to adhere to the
license).
4. Identify support for the software product through the planned life of the program. When source code is
provided with the product, the support may be through the instrument maintenance activities. If source is not
provided, the Software Version Description documentation will contain contact information for the relevant
support organizations.
5. Ensure that the software is verified and validated to at least the same level of confidence required by the inhouse developed POC software, with the exception of unit testing, code reviews and dead-code removal. This
will be accomplished through acceptance tests of the delivered software and inclusion of the software in the
overall verification and validation activities for the system.
37-71002
19
Revision B
TESS POC Software Development Plan
Appendix A
37-71002
22/March/2016
Sample Development Phase Checklists
20
Revision B
TESS POC Software Development Plan
22/March/2016
TESS POC Software Development Phase Completion Checklist
Originator:
Last Modified
Date:
Reviewer:
Planning
Released POC Software Development Plan
Released POC Software Assurance Plan
Updated Software Elements of Master Schedule
Requirements
Released POC Requirements Specification
Released POC Data Dictionary (initial)
Initial Function Point/SLOC Estimate
Update Resource Margin Estimates
Architectural
Design
Released Command Gen. Design Description (Architectural Design Component)
Released Telemetry Processing (Architectural Design Component)
Released Mission Planning Design Description (Architectural Design Component)
Released Instrument Mon/Calib Description (Architectural Design Component)
Update Function Point/SLOC Estimate
Update Resource Usage Estimates
Released Command Generation Test Plan
Released Telemetry Processing Test Plan
Released Mission Planning Test Plan
Released Instrument Monitoring/Calibration Test Plan
Preliminary Design Review
Detailed Design
Updated Command Generation Design Description and Class/Function Stubs
Updated Telemetry Processing Design Description and Class/Function Stubs
Updated Mission Planning Design Description and Class/Function Stubs
Updated Instrument Mon/Cal Design Description and Class/Function Stubs
Released Maintenance Plan
Update Function Point/SLOC Estimate
Update Resource Usage Estimates
Critical Design Review
37-71002
21
Revision B
TESS POC Software Development Plan
22/March/2016
TESS POC Software Development Phase Completion Checklist
Implementation/Unit/Integration Build1 (repeat for Builds 2 and 3)
Released Build 1 CG Modules and Unit Test Complete
Released Build 1 TP Modules and Unit Test Complete
Released Build 1 MP Modules and Unit Test Complete
Released Build 1 IMC Modules and Unit Test Complete
Build 1 Integration Complete
Released Build 1Verification Procedures/Scripts
Dry-Run Build 1 Verification Passes
Build 1 Validation Procedures Complete
Released Build 1 POC Software User's Guide
Updated Software Metrics Report (includes measured Function Points/SLOC)
Updated Resource Margins
Build 1 Readiness Review
Verification and Validation Build 1 (repeat for Builds 2 and 3)
Released Build 1 CG Test and Inspection Reports
Released Build 1 TP Test and Inspection Reports
Released Build 1 MP Test and Inspection Reports
Released Build 1 IMC Test and Inspection Reports
Release As-Built CG Design Description
Release As-Built TP Design Description
Release As-Built MP Design Description
Release As-Built IMC Design Description
Closed/Resolved/Deferred/Waived Software Problem Reports
Closed/Resolved/Deferred/Waived Software-related Engineering Change Orders
Release Updated Maintenance Manual (if needed)
Build 1 Acceptance Review
Software Maintenance (on-going through decommissioning)
Complete Support of Systems Integration/Environmental Test/Deployment
Release Updated Design Documentation As-Needed
Release Version Description Documents and Patch/Load Images As-Needed
Release Updated User's Guide As-Needed
37-71002
22
Revision B
TESS POC Software Development Plan
22/March/2016
TESS POC Software Development Phase Completion Checklist
Release Updated Maintenance Manual As-Needed
Closed/Resolved/Deferred/Waived Software Problem Reports
Closed/Resolved/Deferred/Waived Software-related Engineering Change Orders
Table 5: Software Development Phase Completion Checklist
37-71002
23
Revision B
TESS POC Software Development Plan
Appendix B
22/March/2016
Sample Software Review Checklists
POC Software Requirements Review Checklist (per CSCI)
CSCI Identifier/Revision:
Checklist Last Modified Date:
Checklist Reviewer:
Reviewers include (at least):
Author(s)
Software
Systems
Digital Electronics
Science
Quality
Traceability:
Trace from S/W to TESS Level 3 Requirements
Trace from S/W to TESS POC Requirements
Trace from S/W to TESS to ICDs (SPOC, MOC)
Matrix Template for TESS POC Design Description
Verification:
Methods (demonstration, test, inspection, analysis)
Approach Description
Check for:
Conformance to NPR 7150.2a
Clarity/Consistency/Completeness
Bounds / Resolution / Precision (where applicable)
Off-Nominal Behaviors
Resource utilization (by resource)
Error Conditions
Risk Management
Risk Identification/Classification/Assessment/Prototypes
POC Software Architectural Design Review Checklist (per CSCI)
CSCI Identifier/Revision:
37-71002
24
Revision B
TESS POC Software Development Plan
22/March/2016
POC Software Architectural Design Review Checklist (per CSCI)
Checklist Last Modified Date:
Checklist Reviewer:
Reviewers include (at least):
Author(s)
Software
Systems
Quality
Traceability:
Trace from Design to CSCI Requirements Specification
Trace from Design to CSCI Data Dictionary
Populated CSCI Requirements to Design Matrix
Matrix Template for Detailed Design Elements
Design Elements
Conformance to NPR 7150.2a
Information and Control Structure and Decomposition
External Interface Descriptions
Exception Handling
Detailed Design Component Identification and Description
Internal Interface Identification/Descriptions
Language(s)/Operating System/Library Selection
Coupling/Cohesion Assessment
Code Preparation
Code Standards and Practices, including style guidelines
Source File Templates
Development File System Layout
Develop Detailed Design Review Checklist
Develop Code Review Checklist
37-71002
25
Revision B
TESS POC Software Development Plan
Appendix C
37-71002
22/March/2016
NPR 7150.2a Compliance Matrix
26
Revision B