JTAMS PRE-CDR ANALYSIS 19 October FY 3 - PowerPoint Presentation

Slide1

JTAMS PRE-CDR ANALYSIS

19 October FY 3

PM JTAMS / PM JUGGERNAUT

PRACTICUM 2

PRACTICUM 2

TEAM # ____

Team Members

Each team will develop the

assigned practicum

solution slide package using the templated slides

provided. See the situation and artifacts document and additional information in the Job Aids folder as appropriate.

All

slides will be submitted to the instructors electronically (

Blackboard and Shared

Drive) and hard copy (printed 2 slides per page and double sided)

NOTE: See the last slide (slide 14) for information to assist you in preparing your slides.

JTAMS PDSS Risk Assessment

Conduct a Risk Assessment of the JTAMS software development effort.Identify three(3) Post Deployment Software Support (PDSS) risks. (NOTE: Identify one for PAMS, one for OBD, and one for Juggernaut)Risk Statement #1 (PAMS): Risk Statement #2 (OBD): Risk Statement #3 (Juggernaut):

REFERENCES:

S

C

P

I

Risk Analysis Overview for Risk #1 (PAMS)

Adjust Risk Matrix Expectation consistent with Mitigation Planning

F

Initial

Final

Risk Mitigation Strategy for Risk 1 (PAMS):

P2 Situation and Risk lesson

PAMS Risk Burn Down Plan

LOW

Place actions on Burn Down Chart consistent with Mitigation Planning

HIGH

MED-HIGH

Calendar Months

LOW-MED

1

2

3

n

4

TIME

NOW

Action

1

2

3

4

5

Cost

and schedule implications

P2 Situation and Risk lesson

Program Protection Plan Analysis

What is the final assessment regarding CPI and CF? CPICF

Identify the key players in the development and sustainment of the PPP:

PPP documents (2

);

Artifact (pp 4-7

); Cybersecurity lesson

Award Fee Weights For Period 1 (25 Jun FY2 After SRR)6.1 Risk Management = .4Why? Because this must be done up front6.2 Configuration Management = .2Why? Because this must be done up front6.3 Interface Control = .1Why? We don’t lock in until PDR so not as relevant now6.4 Formal Inspections = 0Why? We have nothing to inspect at this time6.5 End-to-End Requirements Traceability = .3Why? Controlling Requirements is Key to a Successful Program and has a HUGE impact on overall quality!

Award Fee Criteria Analysis (JTAMS)

Award Fee Weights For Period 2 (16 Nov FY3 After PDR)6.1 Risk Management = Why? 6.2 Configuration Management = Why?)6.3 Interface Control = Why? 6.4 Formal Inspections = Why? 6.5? = Why?

Note: for Section H.6.5, identify an Award Fee Area based on Government Software Quality Goals

situation/Artifacts (pp 13-14) and Job Aids (contract)

Real-time Engine Data Rights Analysis

#COACost ($) or H/M/LSchedule (Months or H/M/L)DR (R, GP, U)Risk and Risk level (L, M, H)1Challenge the V-Robotics assertionLowHighGPH potential for cost/schedule2Negotiate for Government Purpose Rights15MN/AGPM (schedule risk)3Develop the Real-time software engine to support MRES4Accept Juggernaut’s assertion and agree to the limited rights associated5Allow another contractor to do the work6Student identified COA

Which option is the best from a Government perspective and why?Which option is best from Juggernaut’s perspective and why?Which option is your recommended option and why?

JTAMS

contract;

Artifact (pp 13-14) and

Situation; Contracting

JTAMS Quality ASSESSMENT

IndicatorInterpretation of measuresProgram ImplicationsJRATS External InterfacesThe total number of Identified External Interfaces has remained fairly steady (with a slight increase). As of May FY2, there were a large number that were Approximated and relatively few that were Approved. The approximated interfaces introduce a huge area of risk in the program. As of Oct FY2, there still remains over 100 Approximated interfaces and only about half of the have been Approved. There are still 42 undefined interfaces. There remains a lot of work to be done to finalize the interfaces, and a lot of risk.From a traditional perspective these measures indicate at best ‘slow’ progress! Significant backlog remains! All external interfaces should be specified (or mostly specified) by CDR time. Current trend indicates that all interfaces will NOT be specified by that time.JTAMS Subsystem InterfacesRequirements VolatilityDrill-Down – Requirements Volatility by SubsystemDefects – Open, Closed, BacklogDefects by Priority

Provide an assessment given the key indicators

Worksheet #1

Practicum 2 JRATS_JTAMS

Measures; Situation; Measures,

Design,

Quality lessons

JTAMS Quality ASSESSMENT

Summarize your analysis

Problems: Summarize the problems in the areas of: JRATS External Interfaces; JTAMS Subsystem Interfaces; Rgmnts Volatility; Defects by Priority. Impacts: Describe the implications for Software Quality.Alternatives: List the alternative courses of action you would consider for this project

Worksheet #2

Practicum 2 JRATS_JTAMS

Measures; Situation; Measures,

Design,

Quality lessons

Agile Measures Analysis

explain

what happened

w/ respect to Release 4identify the work completed, work in progress and the work remaining on 02/01/03.

9

Explanation

Work Complete

In-Progress

Work Remaining

See Job Aids\AMRU Release 4 Status Report

Management metrics relevant to life cycle phase: (Latest Cost Estimate)

Key Software-Related Questions for CDR

CDR Checklist Question

Answer and Discussion

Has the software cost estimate been updated based upon actual measured project software development performance and productivity to date?

There

is no evidence of an updated cost estimate. Identify 3 implications for the JTAMS program (explain your answers):

Has cost of acquiring, licensing and configuring COTS and / or GOTS computer hardware and software been considered?

JTAMS

is being built from TAMS (GOTS SW/HW). Identify 3 implications for the JTAMS program (explain your answers):

What caused a change in the software cost since the beginning of the project, if any?

Based on what we know about the TAMS subsystems and the JTAMS

requirements, Identify 3 factors that would cause changes in SW cost for JTAMS (explain your answers):

Software Development Planning

What concerns does the V-Robotics have concerning their subcontractor AMRU?

Assess AMRU’s Agile development approach and determine which aspects are in keeping with a lean approach. Recommend areas where AMRU might benefit from using additional Lean concepts.

Lean ConceptDescriptionAddressed in AMRU overviewRecommended for AMRU Sw Dev Plan (Describe expected benefit)Inventory in software development. In knowledge work such as software development, we can think of inventory as being maintained in documentation and in non-deployed software. NoEstablish a policy or procedures for documentation; minimize non-deployed SWMotion in software development. Motion in team members is manifested through activities like travel time, walking to meetings, task-switching between projects and work interruptionsWaiting in software development. Examples include waiting for milestone and change request approvals and sign-offs, waiting for clarifications and elaborations from sponsors and analysts, waiting for builds and testing to complete, waiting for your turn in meetings and conference calls, waiting for deployment schedules and architectural and code reviews. Over-production in software development. over-production in software development occurs when we build features that are either 1: never or rarely used or that are 2: deployed prematurelyOver-processing in software development. Over or redundant processing in software includes low and no value meetings and conference calls, duplicative approvals, redundant reporting, redundant specifications, over-engineering code and gold-plating specifications, design and code reviews that don’t result in technical improvementsTransport in software development. waste of translating and handing-off customer requirements through subsequent phases such as functional specifications, UML diagrams, source code and testsDefects in software development. Testing and inspections that do not result in finding bugs are considered defect waste in software development. Other examples are features that were implemented but were never requested, inaccurate specifications, production bugs, and substandard user experience.

Explain AMRU’s expected benefits or rationale for using Agile development:

when-you-are-agile-you-get-lean

Situation, Artifact

p15-19

SW Dev,

CPI lessons

Summary – Are We Ready for CDR?

Completion of the CDR should provide the following:

(1) An established system initial product baseline

Status:

(2) An updated risk assessment for EMD

Status:

(3) An updated CARD (or CARD-like document) based on the system product baseline

Status:

(4) An updated program development schedule

Status:

(5) An approved Life-cycle Sustainment Plan

Status:

Government and Juggernaut Assessment:

Are we ready for CDR?

Template / Reference MapTO GUIDE YOU IN YOUR EFFORT, SEE THE FOLLOWING REFERENCE MATRIX

TEMPLATE SLIDE

JOB AID FILE

Situation/ARTIFACT

LESSON REFERENCE

2-3

N/A

Situation

Risk Management

4

PPP documents (2)

Artifact (pp 4-7)

Cybersecurity

5

JTAMS contract

Artifact (pp

8-12)

and Situation

Contracting

6

Contract

Artifact (pp

13, 14)

and Situation

Contracting

7-8

Practicum 2 JRATS_JTAMS Measures

Situation

Measures; Design

9

AMRU Release 4 Status Report

Situation

SW Dev; Measures

10

N/A

Situation

Cost Est / SW Dev

11

AMRU Release 2 Release Report (Agile); when-you-are-agile-you-get-lean

Situation and Artifact (pp 15-19)

SW Dev, CPI

12

Various documents

Situation

Various

REMEMBER THERE IS INFORMATION IN THE SCENARIO and on the notes page of each slide