JTAMS PRE-MILESTONE B ANALYSIS

Slides:



Advertisements
Similar presentations
Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13
Advertisements

TITLE OF PROJECT PROPOSAL NUMBER Principal Investigator PI’s Organization ESTCP Selection Meeting DATE.
SE 555 Software Requirements & Specification Requirements Management.
Fundamentals of Information Systems, Second Edition
Secure System Administration & Certification DITSCAP Manual (Chapter 6) Phase 4 Post Accreditation Stephen I. Khan Ted Chapman University of Tulsa Department.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
COMP8130 and 4130Adrian Marshall 8130 and 4130 Test Management Adrian Marshall.
Acquiring Information Systems and Applications
Chapter 2: Overview of Essentials ISE 443 / ETM 543 Fall 2013.
NIST Special Publication Revision 1
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Configuration Management Non Government Std: EIA Standard-649 “A management process for establishing and maintaining consistency of a product’s performance,
IRM304 CDR Course Manager: Denny Involved Competency Leads: 26 (Cybersecurity)-Denman, 19 (Measurement)-Denny, 7 (DBS)-Corcoran [Capability Planning],
Presenter’s Name June 17, Directions for this Template  Use the Slide Master to make universal changes to the presentation, including inserting.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
Chapter 6: THE EIGHT STEP PROCESS FOCUS: This chapter provides a description of the application of customer-driven project management.
Evaluate Phase Pertemuan Matakuliah: A0774/Information Technology Capital Budgeting Tahun: 2009.
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
Prof. Shrikant M. Harle.  The Project Life Cycle refers to a logical sequence of activities to accomplish the project’s goals or objectives.  Regardless.
Principal Investigator ESTCP Selection Meeting
ISA 201 Intermediate Information Systems Acquisition
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
DoD Template for Application of TLCSM and PBL
ITIL: Service Transition
CLE Introduction to Agile Software Acquisition
Supportability Design Considerations
Life Cycle Logistics.
JTAMS PRE-CDR IT/SIS ANALYSIS
Software Project Configuration Management
ISA 201 Intermediate Information Systems Acquisition
MDD to Milestone A Requirements Management Activities
ISA 201 Intermediate Information Systems Acquisition
JTAMS MILESTONE A ANALYSIS
ISA201 Version June 2017 Deployment Overview
Lesson 5 Materiel Solution Analysis (MSA) Exercise Team#
Software Configuration Management
Lesson 10 Risk Management
Principal Investigator ESTCP Selection Meeting
Milestone A to Milestone B Requirements Management Activities
JTAMS MILESTONE A ANALYSIS
Identify the Risk of Not Doing BA
Coverage of exercise tasking and quality of solution (30 Points)
JTAMS POST-CDR IT/SIS ISSUES
JTAMS PRE-CDR IT/SIS ANALYSIS
ISA 201 Intermediate Information Systems Acquisition
JTAMS POST-CDR IT/SIS ISSUES
AMRU Release 2 Release Report
JTAMS MILESTONE A ANALYSIS
TechStambha PMP Certification Training
ISA 201 Intermediate Information Systems Acquisition
Product Support BCA Exercise – JRATS/JTAMS
ISA 201 Intermediate Information Systems Acquisition
JTAMS PRE-MILESTONE B ANALYSIS
JTAMS PRE-MILESTONE B ANALYSIS
MDD to Milestone A Requirements Management Activities
Description of Revision
Defining the Activities
JTAMS PRE-CDR ANALYSIS
Engineering Processes
Project Management Process Groups
Principal Investigator ESTCP Selection Meeting
Engineering Processes
JTAMS Post-Milestone C Analysis
Executive Project Kickoff
Principal Investigator ESTCP Selection Meeting
{Project Name} Organizational Chart, Roles and Responsibilities
JTAMS PRE-MILESTONE B ANALYSIS
Radiopharmaceutical Production
JTAMS PRE-CDR ANALYSIS
JTAMS PRE-MILESTONE B ANALYSIS
Presentation transcript:

JTAMS PRE-MILESTONE B ANALYSIS PRACTICUM 2 JTAMS PRE-MILESTONE B ANALYSIS 23 September FY 1 TEAM # PM: (Insert Student Name Here) DPM: (Insert Student Name Here) Presentation Intro/Overview JTAMS PDSS Risk Analysis Risk Mitigation Analysis Measures Update Analysis CR-IPT Requirements Analysis Revised Cost Analysis Program Protection Plan Analysis Security Control Analysis PRACTICUM 2 Student Instructions: Each team will develop the practicum solution slide package using the templated slides provided, the given scenario, the artifacts to include those provided in the Job Aids folder. All slides will be submitted to the instructors electronically (Blackboard/Shared Drive) and hard copy (printed 2 slides per page and double sided) Each team will designate a PM and Deputy PM to present the results of the analysis prepared by the team. You will have 1.5 hours for research and development of the practicum solution. The PM and Deputy PM will have 5 minutes to present their designated slides. Instructor Notes: The 5 teams will each brief the selected slides and the instructor will grade the individual briefers for an individual “PM” grade according to the rubric. Each team will have 2 briefers per practicum. Instructors will also grade the entire package for the team grade according to the rubric – this will be done after the presentation time. All practicums are followed by in-class homework time for the students so the instructors can take that 30 minutes to execute the team and individual grading. The 5 teams will be divided up so that both instructors will take briefings – since there are 5 teams and normally 2 instructors, one instructor will take 3 teams (6 briefers) and the other instructor will take 2 teams (4 briefers). I recommend the instructor taking the 3 teams stay in the classroom and condense their feedback during the actual session. The instructor taking the 2 teams can use the required “team room” and can take that opportunity to elaborate on the major takeaways and other learning points. There is no penalty IAW the rubric for students exceeding the 5 minutes per brief – however, it is important for the instructors to enforce this time limit especially if you do not have a separate team room and/or a 2d instructor. There is sufficient time in the schedule to conduct all briefings in one classroom. Additionally, there is the option of not having some students brief – if you elect this option, you can designate the students that did not brief P1-P3 to brief during P4 or grade the student during the Discussion Panel brief (the DP option should be the option of last resort) Summary/ Recommendations – PM and DPM PRACTICUM 2

Software Spec Review (SSR) Define the purpose of a Software Specification Review (SSR)? Reviews and evaluates the maturity of software requirements Validates software related Item Performance Specifications Establishes software specific requirements to be included in the Allocated baseline Examines Software Requirements and Interface Requirements Specifications Examines the Operations Concept Document Where is the review normally held and who usually runs the review? Contractor site but run by the government Is this a mandatory review? No – only PDR and CDR are mandatory Juggernaut, V-Robotics and Robots-R-Us were awarded contracts to build design documentation for the SSR; CPAF contracts stipulates that SSR must be held by Dec FY2. Should we hold the SSR as scheduled or delay it? RECOMMENDATION: Do a Hybrid Approach; Hold Pre-SSR on-time, in Dec FY2 and Final SSR when software events have been accomplished (event driven). Why? We want to keep Contractor’s feet to the fire without jeopardizing their confidence; people work to milestones. We are not prepared to do a SSR by Dec FY2 since key FUAV and JCCS interfaces are not defined. We can not completely build the IRS, a pre-requisite of the SSR. We are not prepared to do a SSR by Dec FY2 since the Software Requirements Specification (SRS) can not be 100% completed due to new requirement changes in the Firebird. PRACTICUM 2 See: See: Job Aids\Technical Reviews – External sources are needed to further define SSR’s - Also need to analyze the SSR impacts based on the scenario. See: “Information On Technical Reviews.doc” located in the TECHNICAL REVIEWS Directory Analyze the advantages and disadvantages (with reference to the overall JTAMS program) for the timing of this SSR. Should we hold to the scheduled date or wait until completion of appropriate key SSR entrance/exit criteria (See Job Aids) In your analysis, ensure that you address at least three (3) factors that could drive the success or failure of the SSR, including lifecycle review entry and exit criteria. The three (3) factors should support your recommendation .

CR-IPT Requirements Analysis (Summary of Changes and Impact on JTAMS) Identify JTAMS requirements that have changed from the DRAFT CDD to the new Final DRAFT CDD CDD Changes Impacts Status Reporting: allowed PM JTAMS to show the sub-system(s) causing the most problems so an operator analysis could be done manually vice automatic logistics prediction of mission success in Inc 1 Decreases JTAMS requirements for Increment #1; Saves on cost and schedule for increment 1. Video Replay: Had replay of robot video feeds in Increment 1. Moved to Increment 2. Decreases JTAMS requirements for Increment #1; saves on cost and schedule for increment 1 Secure Transmission: Added security measures for transmitting JTAMS data - Secure data link and secure data tagging required between FUAV, JUGV and JCCS/JTAMS. Increases JTAMS requirements for Increment #1; increases cost and schedule Open Architecture. Open Architecture requirement created as a KPP. Increases JTAMS requirements for Increment #1 but should decrease Life-Cycle costs. Security (KPP). - transaction Security: JTAMS must ensure that JRATS provides a secure system for moving logistical transactions between the robots and JCCS/JTAMS; this is now a KPP. Increases JTAMS costs for all Increments – could also impact schedule and performance Life-Cycle Logistics Support Data. JTAMS must purchase supporting Data from supporting contractors. Increases JTAMS costs for all Increments PRACTICUM 2 See: Job Aids/Joint Capabilities Integration Development System (JCIDS) Your CR-IPT is focused on understanding the full requirements for the JTAMS project. Analyze the requirements and capabilities documents to better understand JTAMS requirements. These documents include the ICD and the DRAFT CDD. You have some friends at the J-8 who just sent you what they are calling a “Final Draft” CDD which has not been formally released.   Your task is to identify those JTAMS capabilities and requirements that have changed from the DRAFT CDD to this new Final DRAFT CDD. Explain the impact/trade-off made of these changes on the JTAMS program? Note: see student slide template for Practicum 2 See: ‘JRATS_JTAMS_FINAL_DRAFT_CDD_Inc_1_Ver 1 0.doc’ in directory ‘JCIDS DOCUMENTS’ and review the CDD from Practicum 1 ANSWER: Must put DRAFT CDD next to FINAL DRAFT CDD to see deltas These are DIRECTLY out of the CDDs—EASY to FIND and EASY to see the DELTAS; This gives them PRACTICE in READING requirements and understanding typical Tradeoffs. REFERENCES:

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 (all related to areas involving software development and support) Identify a mitigation strategy for the identified risks Summarize cost and schedule implications Risk Statement #1 (PAMS): If PAMS SW is not modified into a modern, more supportable language, then PDSS costs will be high to fix or change Risk Statement #2 (OBD): If OBD reuse code used as is (without addressing the existing patches), then it will be very complex/difficult to maintain with cost and schedule implications. Risk Statement #3 (Juggernaut): If Juggernaut design and coding quality is not followed closely, then we may end up with a hard to support product line during software sustainment costing us time and money PRACTICUM 2 See: Lesson 9 Practicum 2 Scenario Update located in Practicum 2 Folder REFERENCES:

JTAMS PDSS Risk Assessment and Mitigation Plans (RISK #1) PAMS Risk Identification and mitigation (Background: Army TAMS/PAMS code was built in an obsolete programming language.) Risk Statement: If PAMS SW is not modified into a modern, more supportable language, then PDSS costs will be high to fix or change Risk Mitigation Strategy Choose a Modern Language, like C++ or JAVA, and mandate the migration of all code to this modern, more supportable language. Summarize any cost and schedule implications: Students should identify that there will be potentially significant cost and schedule implications that will need to be analyzed. Risk Analysis Overview PRACTICUM 2 See: Lesson 9 Practicum 2 Scenario Update located in Practicum 2 Folder I Initial F Final P C S Adjust Risk Matrix Expectation consistent with Mitigation Planning

JTAMS PRE-MILESTONE B ANALYSIS PRACTICUM 2 JTAMS PRE-MILESTONE B ANALYSIS 23 September FY 1 TEAM # PM: (Insert Student Name Here) DPM: (Insert Student Name Here) Presentation Intro/Overview JTAMS PDSS Risk Analysis Risk Mitigation Analysis Measures Update Analysis CR-IPT Requirements Analysis Revised Cost Analysis Program Protection Plan Analysis Security Control Analysis PRACTICUM 2 Student Instructions: Each team will develop the practicum solution slide package using the templated slides provided, the given scenario, and the artifacts provided in the Job Aids folder. All slides will be submitted to the instructors electronically (Blackboard/Shared Drive) and hard copy (printed 2 slides per page and double sided) Each team will designate a PM and Deputy PM to present the results of the analysis prepared by the team. You will have 1.5 hours for research and development of the practicum solution. The PM and Deputy PM will have 8 minutes to present their designated slides. Instructor Notes: The 5 teams will each brief the selected slides and the instructor will grade the individual briefers for an individual “PM” grade according to the rubric. Each team will have 2 briefers per practicum. Instructors will also grade the entire package for the team grade according to the rubric – this will be done after the presentation time. All practicums are followed by in-class homework time for the students so the instructors can take that 30 minutes to execute the team and individual grading. The 5 teams will be divided up so that both instructors will take briefings – since there are 5 teams and normally 2 instructors, one instructor will take 3 teams (6 briefers) and the other instructor will take 2 teams (4 briefers). I recommend the instructor taking the 3 teams stay in the classroom and condense their feedback during the actual session. The instructor taking the 2 teams can use the required “team room” and can take that opportunity to elaborate on the major takeaways and other learning points. There is no penalty IAW the rubric for students exceeding the 8 minutes per brief – however, it is important for the instructors to enforce this time limit especially if you do not have a separate team room and/or a 2d instructor. There is sufficient time in the schedule to conduct all briefings in one classroom. Additionally, there is the option of not having some students brief – if you elect this option, you can designate the students that did not brief P1-P3 to brief during P4 or grade the student during the Discussion Panel brief (the DP option should be the option of last resort) Summary/ Recommendations – PM and DPM PRACTICUM 2

Measurement Analysis Information Need Description Measurable Concept Identify information needs for the TMRR Phase For one information need, Identify a measurable concept, the base measure, and the measurement methods Information Need Rationale Is the project or service meeting scheduled milestones (PDR and SSR)? Actual versus planned milestones Is there enough staff with the required skills? Looking at the number of staff by skill level, number of staff on project and projected staff, and staff that has been added, removed, or quit. How many patches need to be made for the OBD application within TAMS? Depending on the number of patches not applied will determine system vulnerabilities. What is the estimated completion date for defining the key interfaces for the FUAV/JUGV, JTAMS, and the JCCS systems? A delay in defining the key interfaces will impact the completion of the PDR. Information Need Description Information Need Is JTAMS on track to meet schedule? Information Category Schedule and Progress Measurable Concept Work Unit Progress Base Measure Specification Base Measures Number of Open Problem Reports Number of Closed Problem Reports Measurement Methods Count the cumulative number of problem reports open Count the cumulative number of problem reports closed PRACTICUM 2 See: Lesson 9 Practicum 2 Scenario Update located in Practicum 2 Folder AND Job Aids/Measures Identify appropriate information needs for this stage of development. The students should use the information from the Measures folder in the Job Aids. Again, as in Practicum 1, their information needs will differ from yours. These answers are the school solution but the students solution may be as “correct”. This slide represents some additional Information needs – the students do not need to develop more than one slide – this is for the instructor only and meant only to provide additional examples REFERENCES:

Revised Cost Analysis (EMD) Compute the EMD costs for MRES and update the total JTAMS cost V-Robotics Cost Estimate is Overall SW Development Cost for the JTAMS is $17.2M SW O&S for JTAMS for 15 years is $15.7M JTAMS Life Cycle Costs are $32.9M Robots-R-Us Cost Estimate is Overall SW Development Cost for JTAMS is $21.8M SW O&S for JTAMS for 15 years is $34.5M JTAMS Life Cycle Costs are $56.3M Recommendation: V-Robotics Why? V-Robotics has lower Life-Cycle Costs (LCC) LCC is lower because v-Robotics uses an Open Architecture approach with a less complex software architecture V-Robotics is a CMMI Level 5 software developer Robots-R-Us uses many COTS products and their software architecture does not emphasize Open; Also, their software algorithms for mapping the earth are complex and will be hard to support over the life-cycle. PRACTICUM 2 See: Job Aids/Budget Documents/SOFTWARE DEVELOPMENT SITUATION ANSWER: ***LOAD THE “JTAMS with VROBOTICS Answer v<Date>.COCOMOII FILE” into the DAU Cost Estimator*** The students may come up with some different numbers – this is expected and should be based on their assessments of the scenario. Note that the maintenance costs come from the cost estimator – use the “view Maintenance Calculation”

Program Protection Plan Analysis Identify the key players in the development and sustainment of the PPP: The JTAMS PO is responsible for the JTAMS PPP. The JTAMS PO Security Manager is responsible for implementing security countermeasures Project Office (PO) JTAMS is the update authority Program Executive Officer JRATS is the approval authority What is the final assessment regarding CPI and CF? No Organic CPI has been identified for JTAMS FUAV’s and JUGV’s. The JTAMS PO identified some components as Government Furnished Equipment (GFE) in various JTAMS systems to be assessed for possible inherited CPI. The JTAMS PO determined that the JTAMS has no CF Priority Level 1 (Catastrophic). All CF Priority Level 2 are mitigated through various means to ensure that the risk of failure of any one component is reduced to a marginal level. This assessment is based on system design elements built into the FUAV’s and JUGV’s design. Alternative capabilities and redundant design utilizing separate and distinct technologies/components reduce the vulnerability to any single adversarial attack methodology. JTAMS FUAV’s and JUGV’s are so configured so that none of the identified CF Level 2 is a single point of failure for a system. PRACTICUM 2 The students should use the information from the Program Protection folder in the Job Aids. JTAMS now has a program protection plan. All of the answers come directly from the PPP in the Job Aids. CFI: (1) Derive and display FUAV state information; the mitigated risk to this CF is assessed as low. This assessment is based on system design elements built into the UAV design. Alternative capabilities and redundant design utilizing separate and distinct technologies/components reduce the vulnerability to any single adversarial attack methodology, see Figure 7.0-1: Program Risk Matrix. (2) Providing threat identification, classification, and location information, derived from hosted ASE and displayed through the same critical components (existing mitigations, as well as, a redundant stand-alone display).

Security Control Analysis Explain the role and importance of Security Controls: 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 Describe Control AC-6: 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. Provide an overview of Needlines 5 and 6: Which AC-6 controls should be implemented? Explain how implementation of these controls may improve the security posture of JTAMS (1) LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS Ensures only privileged users/processes have access to the security functions needed to perform their required JTAMS mission. Related controls: AC-17, AC-18, AC-19. (2) LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY FUNCTIONS Ensures non-privileged users/processes only use non-privileged accounts or roles when accessing non-security functions. Maintains a distinction between privileged and non-privileged accounts. Related control: PL-4. (5) LEAST PRIVILEGE | PRIVILEGED ACCOUNTS Restricts privileged accounts on JTAMS to assigned personnel/roles, such as System Admins/Privileged Users. Related control: CM-6. (9) LEAST PRIVILEGE | AUDITING USE OF PRIVILEGED FUNCTIONS Provides access for only auditing the execution of privileged user/process functions. Related control: AU-2. (10) LEAST PRIVILEGE | PROHIBIT NON-PRIVILEGED USERS FROM EXECUTING PRIVILEGED FUNCTIONS Prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. NL_5 and NL_6 - Parts requisitions, parts status, maintenance records, etc P1 LOW Not Selected MOD AC-6(1) (2) (5) (9) (10) HIGH AC-6(1) (2) (3) (5) (9) (10) PRACTICUM 2 NIST Special Publication 800-53 Revision 4: Security and Privacy Controls for Federal Information Systems and Organizations: APPENDIX F, SECURITY CONTROL CATALOG: SECURITY CONTROLS, ENHANCEMENTS, AND SUPPLEMENTAL GUIDANCE (Page 157) Explain the role and importance of Security Controls Describe control AC-6 and the role of the related controls identified with AC-6 Given the OV-2 NL’s (need lines) developed during the Architecture Exercise, explain how implementing AC-6 and the related controls could be important to the overall security architecture of JTAMS. NOTE: The OV-1 may also be helpful in discussing the various aspects of the AC-6 Control. There could be a variety of answers and rationale for the various controls and the chosen needlines. AC-6 is described below. This provides an opportunity to discuss the importance of the controls and the relationship between the OV-2 (architecture document) and the selection of security controls. 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. 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.

Summary of Readiness for Milestone B Readiness for SFR, SSR, PDR and Milestone B? SSS-1? YES CDD-1 Validation? NOT approved yet. RFP Decision? No PDR-A INC 1? Not Yet RDP and Capability Drops Identified? Yes PPP updated? Yes Recommendation? Not Ready to Proceed to MS B, Move SSS under Gov’t CM, Validate CDD, Release RFP, Complete PDR PRACTICUM 2 Whatever their answer here will work…as long as they have justification. Much of the answer can be obtained from the scenario. Some potential discussion points: SSS-1: Completed; needs to be moved under Gov’t CM CDD-1 Validation: Proposed Final CDD Developed (07 Oct FY1); needs validation RFP Decision: awaiting CDD-V PDR-A INC 1: Six months out in schedule RDP: Approved 01 Apr FY1 PPP: Approved Recommendation: Not ready for MS-B Move SSS under Gov’t CM Validate CDD Release RFP Complete PDR

BACK-UP PRACTICUM 2

Measurement Information Needs Review and present the information needs identified in Practicum 1 Information Need Rationale Are stakeholder issues identified, tracked and resolved? Given the joint nature of JTAMS, stakeholder engagement must be managed effectively. Are interface requirements defined? Is there an effective interface change management process? JTAMS is part of a system of systems. Interfaces internal to JTAMS must be effectively managed as well as interfaces to other JRATS systems. Are software assurance requirements defined? Both PAMS and OBD present high security risks. How will we know that the two MRES prototypes are maturing technically? Have technical readiness levels been defined for MRES? MRES is an unprecedented capability and presents high development risk. Will JTAMS operate effectively and seamlessly as part of JRATS? Interface errors as well as errors internal to JTAMS will provide a window into system quality. PRACTICUM 2 The students should use the information from the Measures folder in the Job Aids This is the school solution for the information needs the students were to have developed in Practicum 1. They will have this slide in their template. This is an opportunity for the instructor to highlight these information needs and discuss the rationale. What are the information needs for the JTAMS sub-systems? You will have to identify the information needs as you refer the practicum materials. Write down the questions that you want the measures to answer. JOB AIDS: Measurement ICM table (see columns “information categories” and “questions”) This is a set of information needs – there are many others that can be listed.

Risk Burn Down Plan (optional – for planning) HIGH MED-HIGH Calendar Months LOW-MED 1 Current Assessment: 2 3 n 4 TIME NOW Action Who 1 2 3 4 5 This slide does not have to be presented – it is provided for student use – students can use it to elaborate on their risk analysis planning LOW Place actions on Burn Down Chart consistent with Mitigation Planning

PRACTICUM 1 LO’S: LSN LO ELO DESCRIPTION SLIDE Also assessed in: LSN 7 TLO 2.1.1   Given a Department of Defense (DoD) Information Technology (IT) acquisition scenario, create appropriate acquisition strategies to promote the most effective technical and business solution. 2-12 P2-P4    ELO 7.1.1.4 Given a description of an IT acquisition need, assess documentation to ensure specific information provides a clear understanding of the intended IT acquisition objectives from program outset. 2 – 4, 10 ELO 6.1.1.1 Given an IT/SIS acquisition program, apply a cost estimation methodology to recommend appropriate strategies for budget execution within the legislation and guidance of PPBE. 5, 6, 9 P2 ELO 6.1.1.2 Apply a cost estimation methodology to the analysis of an acquisition program to determine the status of budget execution throughout the acquisition life cycle, 9 ELO 6.1.1.4 Determine the impact of COTS and other Cost Drivers on achieving an accurate estimation of Program costs. 6, 9 ELO 27.1.1.6 Given an acquisition program, analyze a work breakdown structure (WBS) 8 ELO 1.1.1.5 Discuss the impact of Title 40/CCA on acquisition of Information Technology (IT). 10 N/A ELO 1.1.1.6 Apply the eleven (11) compliancy requirements of Title 40/CCA to a given DoD IT System. ELO 2.1.1.12 Given an Acquisition scenario, select the appropriate Acquisition model. 5 ELO 18.1.1.3 Identify relevant considerations that influence the acquisition lifecycle of a software-reliant system. 6, 7 ELO 1.1.1.10 Given a DoD acquisition scenario, apply laws and DoD directives to ensure successful IT systems management throughout the acquisition life cycle. ELO 19.1.2.1 Given a scenario, identify program IT decision information requirements. 11

PRACTICUM 2 LO’S: LSN LO ELO DESCRIPTION SLIDE 11 TLO 2.1.1   Given a Department of Defense (DoD) Information Technology (IT) acquisition scenario, create appropriate acquisition strategies to promote the most effective technical and business solution. ELO 6.1.1.1 Given an IT/SIS acquisition program, apply a cost estimation methodology to recommend appropriate strategies for budget execution within the legislation and guidance of PPBE. 8 ELO 6.1.1.2 Apply a cost estimation methodology to the analysis of an acquisition program to determine the status of budget execution throughout the acquisition life cycle, ELO 27.1.1.1 Explain the DoD Systems Engineering Process in the context of an IT/SW Development. 2 ELO 1.1.1.10 Given a DoD acquisition scenario, apply laws and DoD directives to ensure successful IT systems management throughout the acquisition life cycle. 3, 11 ELO 7.1.1.4 Given a description of an IT acquisition need, assess documentation to ensure specific information provides a clear understanding of the intended IT acquisition objectives from program outset. 3 ELO 18.1.1.3 Identify relevant considerations that influence the acquisition lifecycle of a software-reliant system. 4, 5, 2, 8 ELO 19.1.2.1 Given a scenario, identify program IT decision information requirements. 7 ELO 19.1.2.2 Create a set of program IT measures that are linked to the program decision information requirements. ELO 19.1.2.3 Apply the measurement results to support IT program decisions. ELO 20.1.1.4 Identify risks inherent to Information Technology (IT) system acquisition. 4, 5 ELO 20.1.1.5 Apply the five components of the DoD Risk Management Process Model to a given IT acquisition scenario ELO 26.1.1.9 Apply the Program Protection Plan to an IT Acquisition Scenario. 9 ELO 26.1.1.8 Given an IT acquisition scenario, choose the appropriate controls for a system based on confidentiality, integrity, or availability requirements. 10 PRACTICUM 2