current situation - practicum#1 (today is 23 sep fy1) · 2019-08-19 · the current jtams contract...

PRACTICUM 1 SITUATION AND ARTIFACTS OCT ‘18

Practicum 1 of 23

PRACTICUM#1 SITUATION – PEO JRATS and PM JTAMS

Background: For program background and historical information see “JRATS and JTAMS

Background Information” in the Job Aids folder

Current Situation - Practicum#1 (Today is 23 Sep FY1)

We passed Milestone A!

The DoD CIO (JTAMS MDA) has issued a MS A ADM. The ADM approved the JTAMS

program’s entry into the Technology Maturation and Risk Reduction (TMRR) phase, approved the

JTAMS Analysis of Alternatives (AoA) preferred system concept and the JTAMS Increment 1

Acquisition Strategy (AS).

Six months later, in accordance with the overall Acquisition Strategy, contracts were awarded for

competitive prototyping of the JTAMS MRES sub-system. Contracts were awarded to Robots-R-

Us and V-Robotics to produce the MRES-based modeling and simulation environment.

During this same time period a contract was awarded to the Juggernaut Corporation, the current

Army LRATS TAMS prime contractor, to be the overall JTAMS systems integrator. In that role

they will produce a draft Systems-Subsystems Specification (SSS) for JTAMS to support the

JRATS-JTAMS joint System Functional Review (SFR). Juggernaut will also ultimately develop a

set of draft Software Requirements Specifications (SRSs) and Interface Requirements

Specifications (IRSs) which encompass the entire envisioned JTAMS as well as ultimately

incorporate the competitive prototype winner. Juggernaut, was chosen because of its prior domain

experience in successfully developing the Army TAMS software.

At the JRATS-JTAMS System SRR, Juggernaut, as well as Robots-R-Us and V-Robotics, were

given the updated JART ICD, Draft JRATS CDD, the IS ICD and the RDP and other associated

documents to include the JTAMS AoA. These documents are some of the key inputs needed by

Juggernaut in order for them to produce a JTAMS SSS, and draft SRSs and IRSs1 for the upcoming

JRATS SFR.

Juggernaut, was originally, an “old line” manufacturing firm with world-class capabilities in

airframe fabrication, manufacturing and integration, but limited in-house software development

expertise until the Army LRATS effort. As a result of the LRATS effort, they built a software

development team called the Juggernaut Software Development Division (JSDD). JSDD is the

Juggernaut organization which will support JTAMS development. After a successful Software

Specification Review (SSR), plans are for JSDD to build the detailed software architecture to

include the Software Units (SU) comprising each JTAMS Software Item (SI) and ultimately code

the system.


Practicum 1 of 23

Juggernaut’s Software Development Division has recently been assessed at Level 2 on the

Capability Maturity Model Integrated for Development (CMMI-DEV) scale. Juggernaut has

embarked on an aggressive internal software process improvement program. According to the

Juggernaut CEO, he expects Juggernaut to be “Level 4 within 6 months”.

By 23 Sep FY1, Juggernaut had created a final draft JTAMS SSS, a Systems Engineering

Management Plan (SEMP) that is aligned with the government’s Systems Engineering Plan (SEP),

a preliminary JTAMS software architecture along with preliminary drafts of the JTAMS SRSs and

IRSs (some interfaces are not final).

Status updates and other information from PM JTAMS (your office):

PM JTAMS has separate project offices managing each of the four JTAMS components.

The JTAMS OBD Project Office is collocated with PM JTAMS and the PEO JRATS, while

the other Project Offices are geographically dispersed.

The Marine Corps Tactical Software Support Agency (MCTSSA) has been tentatively

designated as the JRATS systems and software support activity for JRATS2.

JTAMS has been viewed as a “medium risk” upgrade. Because of this and the growing

threat, an aggressive overall schedule with a JTAMS Initial Operational Capability (IOC)

two years after start of development is strongly desired and, as such, has been briefed by the

PEO to the MDA as well as in Congressional testimony. Supported by service laboratories

and in-house contractors, the plan is for the government to provide Government Furnished

Equipment (GFE) for the FUAV and JUGV systems to the overall JRATS system integrator.

Some existing TAMS software may have reuse potential. However, the JRATS

performance parameters that were allocated to the JTAMS are such that substantial new

software development (more than originally projected) will be necessary (e.g., we need to

build many new interfaces to many different FUAV and JUGV sub-systems)

In their original contract proposal, Juggernaut submitted a draft Software Development Plan

(SDP) that called for "maturing" much of the existing TAMS software, except for MRES

functionality, for use in the final JTAMS. Juggernaut's draft SDP proposals are still under

review by the government.

The current JTAMS contract with Juggernaut requires use of “…best software development

commercial practices equal to or better than ISO/IEEE 12207 (Software Lifecycle

Processes)” and a trade study to evaluate appropriate programming language(s) for project

use.


Practicum 1 of 23

GUIDE TO COMPLETING THE STUDENT TEMPLATE BRIEFING

REQUIREMENTS

(SEE STUDENT TEMPLATE SLIDES FOR THIS PRACTICUM)

Topic TEMPLATE

SLIDE (s) JOB AIDS ARTIFACT DOCUMENT

JTAMS Operational

Concept and AoA 2, 3

2: JCIDS DOCS; AoA and MDM 3: JCIDS Docs IS-ICD

Slide 2: situation and pages 4-6

Slide 3: pp 7-10

IT box 4 4: MRES ICD and JROCM 4: pages 7-13

CCA and CDD Analysis

5, 6 5: Various JCIDS and Program

Documents

6: CDD’s in Job Aids

5: page 14

6: pages 15-16

Affordability and Cost Analysis

7 budget documents folder Page 17, 18

Measures Analysis 8 ICM table and background

document

Review the situation and see

Page 19 Security Control

Analysis 9 NIST 800-53 Pages 20-23

Summary / Recommendation

10 Review documents as

appropriate

Review the situation and job

aids folders

REMEMBER THERE IS INFORMATION IN THE SCENARIO AND REMEMBER TO

LEVERAGE THE LESSON SLIDES FOR LESSONS PRESENTED PRIOR TO THIS

PRACTICUM (AS APPLICABLE)


Practicum 1 of 23

Analysis of Alternatives (AoA) Excerpt (For student slide 2)

Research Questions and Approach

In the AoA for building JTAMS, the main question asked was “What is the most cost-effective

alternative to build the JTAMS? “ This AoA addressed the cost-effectiveness of three (3)

alternatives in the creation of the JTAMS as part of the JRATS system of systems.

(1) Start with the TAMS system and attempt to reuse as many modules as possible (Maximize

Reuse and use COTS or GOTS as needed); In other words, maximize the use of Non-

Developmental Software (NDS) as much as possible.

Note: The current Army TAMS is made up of three (3) software modules (sub-systems): 1)

Onboard Diagnostics System (OBD); 2) Parts Management System (PAMS); and 3) Training and

Help System (THS); These same three sub-systems could be used in JTAMS to support the JART

concept, but they would need to be upgraded to monitor and interface with the JUGV, FUAV and

JCCS systems. And, a new system called the Mission Rehearsal System (MRES) would need to be

added.

(2) Identify a Commercial Off-The Shelf (COTS) Enterprise Resource Planning (ERP) system that

meets most of the JTAMS critical functionality and create additional modules as needed to meet the

missing functionality (ERP COTS);

(3) Initiate a new start for JTAMS using the ideas from TAMS (NEW GOTS).

The most “cost-effective” alternative means precisely the alternative whose effectiveness meets the

military training and maintenance requirements for JTAMS at the lowest cost.

Assessing the Cost-Effectiveness of Alternatives Addressing the most important question of the AoA, research team assessed the cost-effectiveness.

First, the team focused on analyzing the JTAMS functionality that directly transferred from the

TAMS. Here is a summary of their findings.

Discussion: The major benefit of using the working TAMS is that TAMS is a proven success.

However, TAMS functionality is in support of a long range missile system and JTAMS must

support an armed UAV and UGV.

The following is a JTAMS functionality analysis for each of the four migrating TAMS modules:

Parts Maintenance System (PAMS) SI: Alternative 1, Maximum NDS. This software item (SI) can be reused with minor modifications due

to the high use of COTS; Macros and scripts used within COTS products would need modifications.

The STAMIS interface can be reused. Overall, the LRATS TAMS PAMS code is 80% reusable;

Original code size was 15 KSLOC. It is estimated that JTAMS PAMS will be double the code size

of LRATS TAMS PAMS.


Practicum 1 of 23

Alternative 2. ERP COTS. There are new COTS products out that have more capability for less

price and could be substituted for the TAMS PAMS application. GOTS interface code would need

to be developed for the JCCS but the STAMIS interface code can be used completely.

Alternative 3, NEW GOTS. GOTS is being used for all interfaces under TAMS PAMS and all must

be updated at some level in the new JRATS software architecture except for the STAMIS interface.

No reason to use GOTS for the database; we would still use a COTS database but re-write all of the

data elements, scripts and macros.

PAMS Recommendation is Alternative 1, Maximize NDS because the software architecture is

already working with the STAMIS interface. 80% of the original code can be used from LRATS

TAMS can be used. This code will need 25% redesign, 25% recode and 25% retest. With the new

database items from JRATS we project a final code size to be “most likely” twice the size of the

original LRATS TAMS SLOC.

On-Board Diagnostic System (OBD):

Alternative 1, Maximum NDS. Only the GOTS navigation software system has a high enough

reuse potential within this software item (SI). Macros and scripts used within COTS products

would need modifications. Most of the GOTS interfaces can not be reused because we will be

using a different network and different system characteristics. However, using a mix of COTS and

new GOTS along with some old GOTS is the most cost effective.

Alternative 2. ERP COTS. There are some COTS products out that have more capability for less

price in some of the software units but overall, COTS is not the best solution for this application

since none of the commercial robots have the overall requirements of JRATS.

Alternative 3, NEW GOTS. GOTS or rewriting the entire OBD is not a good option because there

are some COTS products that can be used (like the latest commercial NAV applications). GOTS is

being used to interface missile sensors and sub-systems to OBD; FUAV and JUGV have different

sensors and sub-systems. New GOTS will need to be created to accommodate the unique FUAV

and JUGV sub-systems.

OBD Recommendation is Alternative 1, Maximize NDS. Using SOFTEST, 40% of the original

code can be used from LRATS TAMS can be used (this gives us the actual delivered source

instructions (ADSI)). This code will need 35% redesign, 35% recode and 35% retest. With the new

database items from JRATS we project a final code size to be “most likely” twice the size of the

original LRATS TAMS SLOC.

Mission RE-hearsal System (MRES): Alternative 1, Maximum NDS. There are new COTS products out that can provide most of this

capability but not without GOTS to provide additional functionality and interfaces with JCCS,

OBD, PAMS and THS.

Alternative 2. ERP COTS. There are new COTS products out that have similar capabilities.

However, they do not have all of the functionality required by JRATS/JTAMS. Modifications to

these COTS products would no longer provide the government with the best valued solution.

Alternative 3, New GOTS. GOTS or building all code from scratch is not a good option as there are

many COTS products that can account for a majority of the functionality within MRES.

MRES Recommendation is Alternative 1, Maximize NDS. Using SOFTEST, we estimate the “most

likely” size of this new application is 250KSLOC.


Practicum 1 of 23

Training and Help System (THS):

Alternative 1, Maximum NDS. This software item (SI) can be reused with minor modifications due

to the software architecture; Macros and scripts used within the LRATS TAMS THS would need

modifications. Most of the GOTS interfaces must be updated.

Alternative 2. ERP COTS. There are new COTS products out that have more capability for less

price and could be substituted for the TAMS THS application. However, the interfacing to the

unique FUAV and JUGV and JCCS systems would make this cost prohibitive.

Alternative 3, NEW GOTS. To build from scratch would be more costly than leveraging what we

already have with LRATS TAMS THS.

THS Recommendation is Alternative 1, Maximize NDS. Overall, the LRATS TAMS THS code is

90% reusable; Original code size was 10 KSLOC. It is estimated that JTAMS THS will be double

the code size of LRATS TAMS THS (“most likely”). This code will need 10% redesign, 10%

recode and 20% retest

Findings

Cost-Effectiveness of Alternatives

Alternative (1) is to maximize NDS from the LRATS TAMS program, other COTS and GOTS.

The cost estimate for doing this is estimated to be between $55M and $60M depending on the

amount of reused code we actually have to rewrite. There are legacy architectures to deal with

and many IA issues which are cost drivers that impact this estimate. New code development

(GOTS) was based on actual costs from LRATS TAMS development costs. TAMS development

costs were $25M and, with the addition of MRES our costs will be more than double that of

TAMS.

Alternative (2) is to find an ERP solution (all COTS). The cost estimate for doing this is also

between $65M and $80M. Unknown cost drivers of the amount of middleware (gluecode), issues

with data rights and the many IA issues make this alternative a big unknown.

Alternative (3) is to create JTAMS with a new GOTS development. This has been estimated to be

$90M. The main cost driver would be the development of MRES. We would still use a COTS

database, but there would be a cost to re-building all of the data elements, scripts and macros that

would be associated with this new effort. Unknown cost drivers are hiring the right software

developers who are able to deliver the products on time and on budget. Maintaining this system

would be very expensive with the burden on the government to sustain this system. New code

development (GOTS) was based on actual costs from LRATS TAMS development costs.

Conclusion: The most cost-effective alternative for building JTAMS is (1) Maximize NDS,

where we use a balance of reused GOTS, COTS and new GOTS. Estimated costs are $60M to do

alternate 1.


Practicum 1 of 23

Materiel Development Decision (For student slide 2)


Practicum 1 of 23

IS ICD for Student Slides 3, 4

INFORMATION SYSTEMS INITIAL CAPABILITIES DOCUMENT (IS lCD)

for

JOINT TRAINING AND MAINTENANCE SYSTEM (JTAMS)

MISSION REHEARSAL SYSTEM (MRES)

ACAT: III

Sponsoring organization: Joint Staff/J8/Joint Requirements Office for Battle Space Awareness

(JRO-BA)

Date: 27 March 01

Version 1.5

Validation Authority: Joint Capability Board (JCB)

Milestone Decision Authority (MDA): Director, Joint Program Executive Officer for Joint

Reconnaissance And Training System (JPEO-JRATS)

Joint Staffing Designator: JCB Interest

The Joint Training and Maintenance System (JTAMS) will provide the automated logistical support

for JRATS and be displayed through the JCCS. The Joint Autonomous Reconnaissance and

Targeting (JART) Initial Capability Document (ICD) provides the overall vision of unmanned,

robotic warfare capabilities meeting the Chairman, Joint Chief of Staff’s vision of an Automated

Battle Command Integrated (ABCI) battlefield.

The following capabilities are required of JTAMS:

- On-line, timely remote operational diagnostics capabilities must be provided for all JRATS

components to maximize probability of mission success.

- Capabilities are needed to do expert system analysis of mission, weather, terrain, logistics

resources and to make a logistical prediction of mission success.

- Capabilities are needed to track unit-level maintenance activities and supply actions and

interface with supporting in-theater retail supply systems such as the Army’s various

Standard Army Maintenance Information Systems (STAMISs) and ultimately the Global

Combat Support System (GCSS) for timely logistics support.

- Operational training simulator capability for mission rehearsals is required.

- There is a need for an embedded training system to help train operators of this system.

Here is the JTAMS OV-1:


Practicum 1 of 23

FIGURE 1 – JTAMS OV-1

The focus of this JTAMS Mission Rehearsal System (MRES) Information Systems Initial

Capabilities Document (IS lCD) is identification of future JTAMS MRES software capabilities

required by users for a more capable mission rehearsal system. It will guide development and

fielding of future JTAMS MRES software capabilities. Approval of the JTAMS MRES IS lCD by

the Joint Capability Board (JCB) will endorse transition of JTAMS MRES software development

into the Information Technology (IT) Box approach prescribed by JCIDS and delegate oversight of

JTAMS MRES software requirements to the Army lead JTAMS MRES ITMC. Development and

approval of follow on JTAMS MRES Requirements Definition Packages (RDPs) and specific

Capability Drops (CDs) with timelines for fielding their software enhancements will occur after

approval of the JTAMS MRES IS lCD. Use of the IT Box construct will support an agile and

flexible development process to identify and field software capabilities when they are mature and

ready to be fielded. This will result in a faster and more responsive fielding of JTAMS MRES

capabilities desired by the warfighter.

Mission Rehearsal System (MRES): MRES must be able to accurately model the following

missions: Intelligence, Surveillance, Reconnaissance (ISR), Fire Support, Direct Fire and Force

Protection. However, the MRES application itself is unprecedented and no such existing integrated

model-based system exists in the US inventory.

Fire Support, Direct Fire and Force Projection are considered to be the highest risk MRES

capabilities because of the complex models that need to be created and validated or reused from

existing DoD M&S assets.

ISR missions are estimated to be lower risk because of known demonstrated ISR simulation stand-

alone capabilities in other DoD systems but these mission packages and models have not been

integrated with other planned MRES capabilities.

JTAMS MRES requirements identified in this JTAMS MRES IS ICD have been reviewed and endorsed by JRATS stakeholders as capabilities needed to enhance current unmanned system capabilities. Continued modernization and capability enhancements to the current JTAMS MRES software baseline is the most effective, efficient and expeditious means to address current W&R capability shortfalls. Improved software capabilities fielded in JTAMS MRES capabi l i t y drops will also provide the foundation to leverage future anticipated sensor inputs. There are no viable non materiel solutions identified as either a supplement to or a replacement for the JTAMS capabilities provided by JTAMS MRES. Continued development and fielding of the JTAMS MRES materiel solution is required to provide critical training capabilities for the warfighter. Figure 1 below, depicts the four components of the JTAMS MRES IT Box. The JCB assigned oversight body for the JTAMS MRES IS ICD is the Chair of the Battlespace Awareness


Practicum 1 of 23

Functional Capabilities Board (BA FCB). The JTAMS MRES ITMC shall retain authority over JTAMS MRES RDP issues, including designation of JTAMS MRES Key Performance Parameters (KPPs). The JTAMS MRES ITMC will oversee JTAMS MRES software capability issues and to approve the content of all JTAMS MRES COs. Stakeholders have reviewed all original JTAMS MRES requirements and capability gaps. Consistent with JCIDS guidance for framing an IT Box program, five measures of effectiveness will be used to guide development of future JTAMS MRES requirements identified in section 3 of this IS IlCD

FIGURE 2 – JTAMS SOFTWARE ARCHITECTURE


Practicum 1 of 23

The following are JRATS system performance characteristics that are needed to satisfy the operational capability requirements.


Practicum 1 of 23

JOINT REQUIREMENTS

OVERSIGHT COUNCIL

JROCM for

Student Slide 4

THE JOINT STAFF

WASHINGTON, D.C.

20318

JROCM 030-01

18 February FY01

MEMORANDUM FOR: Under Secretary of Defense for Acquisition, Technology, and

Logistics

Subject: Joint Training and Maintenance System (JTAMS) Mission Rehearsal Capability

1. The Joint Requirements Oversight Council (JROC) approves the Joint Training and

Maintenance System (JTAMS) Mission Rehearsal System (MRES) Information System (IS)

Initial Capability Document (ICD) and validates the attached initial key performance parameters

(KPPs). The JROC considers key performance parameters essential to meet the mission need. .

2. The JROC delegates requirements oversight of this program to the Army led JTAMS-MRES

Information Technology Management Council (MRES ITMC) as directed in the enclosure. The

enclosure defines the approved initial KPPs, and the resource constraints placed on this program.

The IT'MC may approve spiral developments of this capability as long as initial KPPs and funding

constraints are not exceeded. Joint staff requirements review of MRES ITMC decisions and

requirements development products will be conducted by the Battle Space Awareness Functional

Capabilities Board (BA FCB) at a minimum of every two years and more often as desired by

either the BA FCB or the MRES ITMC.

3. The ITMC will ensure that the JTAMS-MRES IS ICD is brought back to the JROC if the

funding levels identified in the enclosure are forecast to be exceeded or if an initial minimum KPP

cannot be achieved.

4. Should the Army encounter cost growth exceeding 15 percent of the program development or

full lifecycle costs, they shall return to the JROC prior to reprogramming or budgeting additional

funding into the program.

Ima Thorne Inurside

General, United States Marine Corps

Vice Chairman of the Joint Chiefs of Staff

PRACTICUM 1 SITUATION AND ARTIFACTS JUNE ‘18

Practicum 1 of 23

Enclosure TO JROCM 030-01 (JTAM-MRES ICD IT Box Limits)

1. The Army is directed to establish the ITMC with the Army G6 as lead, to provide oversight

direction and approval to the requirements process; review and approve requirements

prioritization; integrate with PPBE processes, and approve the JTAMS-MRES budget.

2. The ITMC will have the authority to approve updates beyond the initial KPPs and KSAs as

software and hardware technologies evolve (See IS ICD).

3. Funding for the JTAMS-MRES Hardware Refresh and System Enhancements & Integration

limits costs to $26.57M over the projected lifetime (FY 1-15) of the program.

4. Funding for the JTAMS-MRES application and system software development is limited to

$15.3M.

5. The ITMC will return to the JROC if the above funding levels and initial KPPs are not

achieved.


Practicum 1 of 23

Mandatory Title 40/Clinger-Cohen Act (CCA) compliance status:

(For Student slide 6 – Milestone A column – for the Milestone B column, review the

scenario and Job Aids to identify any updates)

1. Make a determination that the acquisition supports core, priority functions of the

Department. We are part of the JRATS ACAT I weapons systems program. However, we

have our own JROC approved documentation.

2. Establish outcome-based performance measures linked to strategic goals. 2 We are part

of the JRATS ACAT I weapons systems program. Our outcome-based performance

measures will be extracted out of the JART ICD and the IS ICD. These will be refined by

capability developers as we develop the RDP and the Draft CDD after MS A.

3. Redesign the processes that the system supports to reduce costs, improve effectiveness

and maximize the use of COTS technology. 2 IAW the Acquisition Strategy (AS), we will

pursue an acquisition strategy to maximize reuse and use of COTS.

4. Determine that no Private Sector or Government source can better support the function.

As a result of our approved Analysis of Alternatives (AoA) and the Acquisition Strategy

(AS) that we created as a result of our AoA, there are no private sector or government

source that can better support this new function. JTAMS has been directed by the MDA to

pursue capability reuse from a very similar Army program. Parts of JTAMS are

unprecedented (the Mission Rehearsal System (MRES)) and must be created from scratch.

5. Conduct an analysis of alternatives. 3 Done, see our approved AoA.

6. Conduct an economic analysis that includes a calculation of the return on investment; or

for non-AIS programs, conduct a Life-cycle Cost Estimate (LCCE). Done, see our budget

documents. We have produced a cost estimate for the MSA Phase. Our cost estimate

includes a LCCE.

7. Develop clearly established measures and accountability for program progress. As part of

our Systems Engineering Plan (SEP), we will produce a metrics program.KPPs. Once the

CDD identifies the KPPs then we will establish Technical Performance Measurements

(TPM) to meet objective performance. The status is “DRAFT on path for success.”

8. 8. Ensure that the acquisition is consistent with the DoD Information Enterprise policies

and architecture, to include relevant standards. As part of our AS, we will be establishing a

connection to the GIG to order and receive parts from the Army STAMIS. Our SEP will

document the GIG profiles required to be designed and developed within the Parts and

Maintenance System (PAMS) of the JTAMS architecture design. The status is “DRAFT on

path for success.”

9. Ensure that the program has a Cybersecurity Strategy that is consistent with DoD

policies, standards and architectures, to include relevant standards. The status is “DRAFT

on path for success.” (See our approved Cyber Security Strategy).

10. Ensure, to the maximum extent practicable, (1) modular contracting has been used, and

(2) the program is being implemented in phased, successive increments, each of which

meets part of the mission need and delivers measurable benefit, independent of future

increments. Part 1 (mod contracting) status is NA at this point; Part 2 status is Done per

the AS.

11. Register Mission-Critical and Mission-Essential systems with the DoD CIO Done,

JTAMS is registered as a Mission-Critical system with the DoD CIO.


Practicum 1 of 23

FINAL DRAFT CDD EXCERPT (for Student slide 7)

(See CDD’s in the Job Aids for additional information)

CAPABILITY DEVELOPMENT DOCUMENT (DRAFT) - EXCERPT

FOR

Joint Reconnaissance and Autonomous Targeting System (JRATS)

Increment 1

ACAT ID

Validation Authority: JROC

Approval Authority: JROC

Milestone Decision Authority: USD(AT&L)

Designation: JROC Interest

Prepared for Milestone B

7 Oct FY01

STUDENT NOTE: The complete Draft and Final Draft CDD’s are in the

Job Aids for reference – below are the changes for use in your analysis – if

you need additional information refer to the Job Aids

YELLOW UNDERLINED HIGHLIGTS MARK THE CHANGES FROM

DRAFT TO FINAL DRAFT e. JTAMS component

(1) Attributes

(a) Instrumentation. The JTAMS, as a sub-system of JCCS and using the

JCCS display, shall provide the operator with alarms and status of all vehicle sub-systems

logistics information. This includes fuel, air pressure, tire wear, tread wear, engine wear, oil

pressure levels, oil freshness levels, cooling system levels, spark plug performance,

ammunition levels, complete vehicle logistical data/status to ensure vehicle reliability,

availability, and maintainability (RAM) (Threshold). JTAMS shall constantly predict the

mission package success of the current mission based on the logistics status of all sub-

systems (Objective- Increment 2). Whatever sub-system is causing the mission to be in

jeopardy shall be clearly shown on the JCCS display (Objective – Increment 1). It is

required that a digital display menu screen show simultaneous logistical status of all

vehicles under the control of a specific JCCS-JTAMS (t/o).

(c) Prior Missions. The JTAMS shall provide the operator the ability to

bring up previously executed missions and replay them within the virtual

Mission Rehearsal system (Increment 2 Capability).


Practicum 1 of 23

(e) JTAMS shall be secured using data link security measures and data

security tagging between all three systems (FUAV, JUGV, JCCS). (t/o)

Attribute Development Threshold Development Objective

Instrumentation Provide operator alarms and

vehicle logistics data/status

complete vehicle logistical

data/status to ensure vehicle

reliability, availability, and

maintainability

Provide operator alarms and

vehicle logistics data/status

complete vehicle logistical

data/status to ensure vehicle

reliability, availability, and

maintainability

On-Board Diagnostics (OBD) Secure data and video

communications link between all

JRATS component systems

Same as threshold

Open Design [KPP] All JTAMS-JRATS interfaces

(100%) shall be designed to

accommodate new system

interfaces with minimal re-design

(when adding new or modified

capabilities). The DoD OSA

approach shall be employed to

identify and manage such key

interfaces.

Same as threshold

Security [KPP] Provide a secure system for all

transactions (99%), based on the

JRATS and DoD approved

technical and security

architectures.

Same as threshold

(d) Life-Cycle Logistics Support. The government requires appropriate levels of

engineering and logistics data necessary to support the JRATS equipment maintenance.

Access to or acquisition of engineering data (drawings, standards, specifications, processes,

etc.) shall ensure long term logistics support over the entire system life cycle. Data for the

JRATS shall be procured to support re-competition of Contractor Logistics Support

(CLS) contracts.


Practicum 1 of 23

PRACTICUM 1 STUDENT INSTRUCTIONS FOR

BUDGET OFFICER (for Student slide 8) 1. Use the Budget folder in the Job Aids – you will find a spreadsheet and a COCOMO file –

remember to use COCOMO from the Practicum Tools folder (you should have placed it on

your desktop from the Student CD or BlackBoard during the Cost Estimating Lesson)

2. Your task is to create two (2) cost estimates; one for V-Robotics and one for Robots-R-Us.

You will compare the two CEs along with their software development environments and

make a recommendation to the PM as to which contractor to select as we move into EMD.

3. Using the “JTAMS_ Pract1<vDATE>.COCOMOII” file as the base file; open the DAU Cost

Estimator and load this file. Note that it already has the four JTAMS software items loaded;

Note that it already has the correct environmental settings for the overall development

environment for JTAMS.

4. Using the software development environment situation, tweak the Mission Rehearsal

System (MRES) SI for the appropriate parameters for V-Robotics and capture your results

using the Excel Spreadsheet provided (JTAMS CE Support Tool for Pract 2 v<DATE>.xlsx)

insert the results for MRES; You are only tweaking MRES EMD since that’s all V-Robotics is

working on and that’s where we are now—EMD. Note that the maintenance costs come

from the cost estimator – use the “view Maintenance Calculation”

5. Do the same for Robots-R-Us.

6. Make your recommendation and fill in the appropriate template slide within the

appropriate Section. Explain your recommendation.

SOFTWARE DEVELOPMENT SITUATION - PRE-MILESTONE B JTAMS

CONTRACTORS

Juggernaut’s Software Development Environment: Juggernaut, as the JTAMS system

integrator, is focused on the OBD, PAMS and THS sub-systems. The Juggernaut Software

Development Division (JSDD) have average design analysts and programmers. With the

Army reuse software and the new software to be built, the complexity of the product is high.

The product they are trying to build here must be reusable and that is rated as high. Since

JSDD is geographically separated and they are the lead for JTAMS, there will be multi-city

collaboration taking place mainly over the phone. The desire for software designed for

reuse within an open architecture framework is high for all JTAMS sub-systems. In

accordance with their role as the JTAMS system integrator, Juggernaut has developed and

base-lined the MRES Software Requirements Specification (SRS) and Interface

Requirements Specification (IRS) which have been provided for implementation to the two

MRES competitive prototype contractors.

V-Robotics Software Development Environment: V-Robotics efforts are focused on the

MRES competitive prototype. They have an extra high emphasize on open architecture in

their design to facilitate software reuse and ease of maintenance. This use of open

architecture gives their development team an extremely high flexibility to make changes.

MRES is an unprecedented application. Because of their emphasis on OA and lack of


Practicum 1 of 23

dependence on COTS products, they have a very high risk reduction plan in place via their

design. Their programming staff is CMMI Level 5 rated with the highest levels of team

cohesion, process maturity and extensive Application experience. They use the most

modern programming practices with the very low software complexity. Due to their

excellent open architecture design, V-Robotics has been able to keep MRES prototype

software complexity simple and very easy to modify. V-Robotics has a very good design

analysts and programmer team. They also have to deal with high requirements volatility

which they do with the Agile software development practices.

Robots-R-Us Software Development Environment: Robots-R-Us efforts are focused on the

MRES competitive prototype. Robots-R-Us design flexibility is very low since there are

numerous COTS products being used. MRES is an unprecedented application. Open

architecture design emphasis is very low because of use of an existing COTS product

coupled with "glue code" to help integrate the various COTS components because of this

reusability is considered nominal (Risk reduction due to architecture is very low). Team

cohesion is high but they are a CMMI Level 3 organization. Because of the lack of open

architecture design, Robots-R-Us have not been able to keep MRES software complexity

simple and easy to modify--many changes are needed to include issues with complex earth

algorithms designed into their COTS product which need to be tailored out or modified to

fully meet the MRES SRS/IRS requirements. The code is extremely complex to change.

Robots-R-Us has very good design analysts and programmers.


Practicum 1 of 23

INFORMATION TO ASSIST IN THE DEVELOPMENT OF

SLIDE 9


Practicum 1 of 23

Information for slide 10

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations (Note this is a small portion of the document for use in the exercise – the entire document is available in the Job Aids.

Abstract

The selection and implementation of security controls for information systems1 and organizations are

important tasks that can have major implications on the operations2 and assets of organizations3 as

well as the welfare of individuals and the Nation. Security controls are the

safeguards/countermeasures prescribed for information systems or organizations that are designed

to: (i) protect the confidentiality, integrity, and availability of information that is processed, stored,

and transmitted by those systems/organizations; and (ii) satisfy a set of defined security

requirements.4 There are several key questions that should be answered by organizations when

addressing the information security considerations for information systems:

• What security controls are needed to satisfy the security requirements and to adequately mitigate

risk incurred by using information and information systems in the execution of organizational

missions and business functions?

• Have the security controls been implemented, or is there an implementation plan in place?

• What is the desired or required level of assurance that the selected security controls, as

implemented, are effective in their application? 5

The answers to these questions are not given in isolation but rather in the context of an effective risk

management process for the organization that identifies, mitigates as deemed necessary, and

monitors on an ongoing basis, risks6 arising from its information and information systems. NIST

Special Publication 800-39 provides guidance on managing information security risk at three distinct

tiers—the organization level, mission/business process level, and information system level. The

security controls defined in this publication and recommended for use by organizations to satisfy

their information security requirements should be employed as part of a well-defined risk

management process that supports organizational information security programs.

Achieving adequate information security for organizations, mission/business processes, and

information systems is a multifaceted undertaking that requires:

• Clearly articulated security requirements and security specifications;

• Well-designed and well-built information technology products based on state-of-the-practice

hardware, firmware, and software development processes;

• Sound systems/security engineering principles and practices to effectively integrate information

technology products into organizational information systems;

• Sound security practices that are well documented and seamlessly integrated into the training

requirements and daily routines of organizational personnel with security responsibilities;

• Continuous monitoring of organizations and information systems to determine the ongoing

effectiveness of deployed security controls, changes in information systems and environments of

operation, and compliance with legislation, directives, policies, and standards;21 and

• Information security planning and system development life cycle management.


Practicum 1 of 23

AC-6 LEAST PRIVILEGE

Control: The organization employs the principle of least privilege, allowing only authorized

accesses for users (or processes acting on behalf of users) which are necessary to accomplish

assigned tasks in accordance with organizational missions and business functions. APPENDIX F-AC PAGE F-18 Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

Supplemental Guidance: Organizations employ least privilege for specific duties and information

systems. The principle of least privilege is also applied to information system processes, ensuring

that the processes operate at privilege levels no higher than necessary to accomplish required

organizational missions/business functions. Organizations consider the creation of additional

processes, roles, and information system accounts as necessary, to achieve least privilege.

Organizations also apply least privilege to the development, implementation, and operation of

organizational information systems. Related controls: AC-2, AC-3, AC-5, CM-6, CM-7, PL-2. Control Enhancements: (1) LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS

The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].

Supplemental Guidance: Security functions include, for example, establishing system accounts,

configuring access authorizations (i.e., permissions, privileges), setting events to be audited,

and setting intrusion detection parameters. Security-relevant information includes, for

example, filtering rules for routers/firewalls, cryptographic key management information,

configuration parameters for security services, and access control lists. Explicitly authorized

personnel include, for example, security administrators, system and network administrators,

system security officers, system maintenance personnel, system programmers, and other

privileged users. Related controls: AC-17, AC-18, AC-19. (2) LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY FUNCTIONS

The organization requires that users of information system accounts, or roles, with access to [Assignment: organization-defined security functions or security-relevant information], use nonprivileged accounts or roles, when accessing nonsecurity functions.

Supplemental Guidance: This control enhancement limits exposure when operating from within

privileged accounts or roles. The inclusion of roles addresses situations where organizations

implement access control policies such as role-based access control and where a change of

role provides the same degree of assurance in the change of access authorizations for both the

user and all processes acting on behalf of the user as would be provided by a change between

a privileged and non-privileged account. Related control: PL-4. (3) LEAST PRIVILEGE | NETWORK ACCESS TO PRIVILEGED COMMANDS

The organization authorizes network access to [Assignment: organization-defined privileged commands] only for [Assignment: organization-defined compelling operational needs] and documents the rationale for such access in the security plan for the information system.

Supplemental Guidance: Network access is any access across a network connection in lieu of

local access (i.e., user being physically present at the device). Related control: AC-17. (4) LEAST PRIVILEGE | SEPARATE PROCESSING DOMAINS

The information system provides separate processing domains to enable finer-grained allocation of user privileges.

Supplemental Guidance: Providing separate processing domains for finer-grained allocation of

user privileges includes, for example: (i) using virtualization techniques to allow additional

privileges within a virtual machine while restricting privileges to other virtual machines or to

the underlying actual machine; (ii) employing hardware and/or software domain separation

mechanisms; and (iii) implementing separate physical domains. Related controls: AC-4, SC-3,

SC-30, SC-32. (5) LEAST PRIVILEGE | PRIVILEGED ACCOUNTS

The organization restricts privileged accounts on the information system to [Assignment: organization-defined personnel or roles].

Supplemental Guidance: Privileged accounts, including super user accounts, are typically

described as system administrator for various types of commercial off-the-shelf operating

systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day

users from having access to privileged information/functions. Organizations may differentiate


Practicum 1 of 23

in the application of this control enhancement between allowed privileges for local accounts

and for domain accounts provided organizations retain the ability to control information APPENDIX F-AC PAGE F-19 Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

system configurations for key security parameters and as otherwise necessary to sufficiently

mitigate risk. Related control: CM-6. (6) LEAST PRIVILEGE | PRIVILEGED ACCESS BY NON-ORGANIZATIONAL USERS

The organization prohibits privileged access to the information system by non-organizational users.

Supplemental Guidance: Related control: IA-8. (7) LEAST PRIVILEGE | REVIEW OF USER PRIVILEGES

The organization: (a) Reviews [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges; and (b) Reassigns or removes privileges, if necessary, to correctly reflect organizational mission/business needs.

Supplemental Guidance: The need for certain assigned user privileges may change over time

reflecting changes in organizational missions/business function, environments of operation,

technologies, or threat. Periodic review of assigned user privileges is necessary to determine if

the rationale for assigning such privileges remains valid. If the need cannot be revalidated,

organizations take appropriate corrective actions. Related control: CA-7. (8) LEAST PRIVILEGE | PRIVILEGE LEVELS FOR CODE EXECUTION

The information system prevents [Assignment: organization-defined software] from executing at higher privilege levels than users executing the software.

Supplemental Guidance: In certain situations, software applications/programs need to execute

with elevated privileges to perform required functions. However, if the privileges required for

execution are at a higher level than the privileges assigned to organizational users invoking

such applications/programs, those users are indirectly provided with greater privileges than

assigned by organizations. (9) LEAST PRIVILEGE | AUDITING USE OF PRIVILEGED FUNCTIONS

The information system audits the execution of privileged functions.

Supplemental Guidance: Misuse of privileged functions, either intentionally or unintentionally

by authorized users, or by unauthorized external entities that have compromised information

system accounts, is a serious and ongoing concern and can have significant adverse impacts

on organizations. Auditing the use of privileged functions is one way to detect such misuse,

and in doing so, help mitigate the risk from insider threats and the advanced persistent threat

(APT). Related control: AU-2. (10) LEAST PRIVILEGE | PROHIBIT NON-PRIVILEGED USERS FROM EXECUTING PRIVILEGED FUNCTIONS

The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

Supplemental Guidance: Privileged functions include, for example, establishing information

system accounts, performing system integrity checks, or administering cryptographic key

management activities. Non-privileged users are individuals that do not possess appropriate

authorizations. Circumventing intrusion detection and prevention mechanisms or malicious

code protection mechanisms are examples of privileged functions that require protection from

non-privileged users.

References: None.


Practicum 1 of 23

The OV-2 depicts the operational performers within JRATS

program, with the JTAMS Operational (Joint Maintenance)

performer as the focus. Army management is an external

performer, depicted in burnt orange oval, while all other

performers are internal to JRATS depicted by light green

ovals.

The Need Lines are used to describe the information needs to

support operations.

NL_1 and NL_2 - Health of JUGV, Location of JUGV, etc.

NL_3 and NL_4 - Operational status (e.g. FMC, PMC, etc.)

of JUGV, FUAV, parts, Estimated Time to Repair (ETR), etc.

NL_5 and NL_6 - Parts requisitions, parts status, maintenance

records, etc

NL_7 and NL_8 - Health of FUAV, Location of FUAV, etc