Evaluate SE Methods, Processes and Tools Technical Task Plan USC Workshop Los Angeles, CA 29 January 2009.

Slides:



Advertisements
Similar presentations
Roadmap for Sourcing Decision Review Board (DRB)
Advertisements

State of Indiana Business One Stop (BOS) Program Roadmap Updated June 6, 2013 RFI ATTACHMENT D.
Software Quality Assurance Plan
TITLE OF PROJECT PROPOSAL NUMBER Principal Investigator PI’s Organization ESTCP Selection Meeting DATE.
Lecture # 2 : Process Models
Improving Your Business Results Six Sigma Qualtec Six Sigma Qualtec Six Sigma Qualtec – All Rights Reserved June 26, 2002 BEYOND SIX SIGMA: A HOLISTIC.
Systems Engineering in a System of Systems Context
SERC Achievements and Program Direction Art Pyster Deputy Executive Director November, Note by R Peak 12/7/2010: This presentation.
Proposed Way Forward for SERC EM Task Barry Boehm, USC-CSSE 30 January 2009.
1 Introduction to System Engineering G. Nacouzi ME 155B.
SQM - 1DCS - ANULECTURE Software Quality Management Software Quality Management Processes V & V of Critical Software & Systems Ian Hirst.
Adjusting EPLC to your Project Colleen Robinson & Teresa Kinley Friday, February 6, 2009.
Iterative development and The Unified process
1 Software Requirements Specification Lecture 14.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
What is Business Analysis Planning & Monitoring?
S/W Project Management
CC20O7N - Software Engineering 1 CC2007N Software Engineering 1 Requirements Engineering Practices with Techniques.
Chapter 2 The process Process, Methods, and Tools
THE PROTOTYPING MODEL The prototyping model begins with requirements gathering. Developer and customer meet and define the overall objectives for the software.
Do it pro bono. Competitor/Collaborator Analysis Service Grant The Strategy Management Practice is presented by Wells Fargo. The design of the Competitor/Collaborator.
#17 - Involve Users in the Development Model of Multinational Corporations - Is it worth it? Experience Report IRCSE '08: IDT Workshop Friday 31 October.
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
BSBPMG502A Manage Project Scope Manage Project Scope Project Scope Processes Part 1 Diploma of Project Management Qualification Code BSB51507 Unit.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
CEN rd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Phases of Software.
December 14, 2011/Office of the NIH CIO Operational Analysis – What Does It Mean To The Project Manager? NIH Project Management Community of Excellence.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
MD Digital Government Summit, June 26, Maryland Project Management Oversight & System Development Life Cycle (SDLC) Robert Krauss MD Digital Government.
SE Team Agenda Review work being done by Dwayne –Review Sect 4.4.X for DAG – being processed –SEP Guide – being processed; seen as OK –Technical Reviews.
Ahmad Al-Ghoul. Learning Objectives Explain what a project is,, list various attributes of projects. Describe project management, discuss Who uses Project.
1 Designing Effective Programs: –Introduction to Program Design Steps –Organizational Strategic Planning –Approaches and Models –Evaluation, scheduling,
Division Of Early Warning And Assessment MODULE 5: PEER REVIEW.
Systems Analysis and Design in a Changing World, Fourth Edition
Life Cycle Logistics.
Develop Project Charter
Rational Unified Process (RUP) Process Meta-model Inception Phase These notes adopted and slightly modified from “RUP Made Easy”, provided by the IBM Academic.
U.S. Department of Agriculture eGovernment Program January 9, 2002 eGovernment Working Group Chris Niedermayer, USDA eGovernment Executive Barbara LaCour.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
1 EMS Fundamentals An Introduction to the EMS Process Roadmap AASHTO EMS Workshop.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Independent Expert Program Review (IEPR) February 2006.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Evaluate SE Methods, Processes and Tools Technical Task Plan USC Workshop Los Angeles, CA 16 March 2009.
1 3:00 PM, EST. 2 Don Hewitt Vice President, Business Operations OSEHRA Ramina Toy Program Manager Brad Triebwasser.
2050AP Project WP5: “Conclusions” UPM Madrid 11 de Octubre 2013.
1 Week 5 Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam.
Principal Investigator ESTCP Selection Meeting
Process 4 Hours.
DoD Template for Application of TLCSM and PBL
Sample Fit-Gap Kick-off
Life Cycle Logistics.
ISA 201 Intermediate Information Systems Acquisition
Principal Investigator ESTCP Selection Meeting
Identify the Risk of Not Doing BA
TechStambha PMP Certification Training
The Open Group Architecture Framework (TOGAF)
Version 0.1Assessment Method Overview - 1 Process Assessment Method An objective model-independent method to assess the capability of an organization to.
DOD’S PHASED SYSTEM DEVELOPMENT PROCESS
Independent Expert Program Review (IEPR)
Principal Investigator ESTCP Selection Meeting
Define Your IT Strategy
Principal Investigator ESTCP Selection Meeting
Presentation transcript:

Evaluate SE Methods, Processes and Tools Technical Task Plan USC Workshop Los Angeles, CA 29 January 2009

Agenda Overview and changes in the MPT task Near term activities – Sponsor environment Revised schedule Workshop activities

SOW Language Look at current SE methods, processes, and tools (MPTs) as they are applied across the DoD acquisition life cycle focusing on three different development environments: individual weapons systems, SoS, and network-centric systems. Research will be targeted at improving current/identifying new SE MPTs that will better support the practice of SE in these three environments. Specifically, this task will: 1. Define critical attributes of current SE MPTs across the weapons system, SoS, and network-centric services environments; 2. Identify strengths and weaknesses for these current MPTs and any shortcomings in their application across DoD; 3. Recommend, in priority order, MPTs for further study to innovate or create improved or new MPTs to eliminate identified shortcomings; 4. Upon selection by the government of MPTs recommended in sub-task 3 for further study, perform research to innovate or create improved or new MPTs to eliminate identified shortcomings, thereby advancing the state of practice of SE within the community; and 5. For the improvements delivered in sub-task 4 above, propose a methodology for validating the programs.

eWorkshop MPT Sources Select MPTs for Evaluation Describe MPTs Evaluate MPTs MPT Analysis Apply Selection Criteria Complete Detailed Attributes Apply Evaluation Criteria Reports and Recommendations Cumulative MPT Coverage Identified Raw MPTs H H H H M M M M Queue of selected and prioritized MPTs Fully described MPTs to evaluate Evaluated MPTs BPCH Establish Criteria and Validate with Sponsor Repeat H H L L H H H H M M M M H H L L DoD Guideboooks DoD Programs/Reviews Service Repositories Defense Industry Commercial industry To Users Recommended MPTs Improvements Needed Overall Gap Analysis Research Areas MPT Task Overview

Systems Engineering and Level-of-Effort Contracts Dennis Barnabe, SERC PM 21 Nov 2008 SERC Kickoff Meeting

Slippery Slope Logic Mission-card Agility Prototype/Discovery LOE Contract

Relationships to Agility High Low LRequirements DetailH LocalMission SatisfactionBroad LMaintainabilityH H Redundancy RiskL LScalabilityH LComplexity/SizeH LIntegration/InteroperabilityH Project Type PrototypeQRC + O&M LRIP + O&M Prod + O&M Contract Type LOE/T&M/TTO Delivery/Turnkey

SE “Equalizer” Requirements Configuration Management Technical Reviews Technical Documentation Testing Life Cycle Planning Prototype or Discovery

SE “Equalizer” Requirements Configuration Management Technical Reviews Technical Documentation Testing Life Cycle Planning QRC

SE “Equalizer” Requirements Configuration Management Technical Reviews Technical Documentation Testing Life Cycle Planning Development with eye toward sustained Ops

(Usual) LOE SE Implications Requirements lacking Limited (if any) ‘formal’ Reviews – No coordination/insight among related efforts – Interface and duplication risks – No ability to assess technical health Standards application, etc No formal ‘transition’ planning – What if it works? Build to Cost – No actual cost estimate of satisfying mission need – If successful, Operations cuts into Development Deemed ‘tech transfer issue’ Schedule lacking – Inability to coordinate among other efforts “Success” defaults to ‘what is delivered’

eWorkshop MPT Sources Select MPTs for Evaluation Describe MPTs Evaluate MPTs MPT Analysis Apply Selection Criteria Complete Detailed Attributes Apply Evaluation Criteria Reports and Recommendations Cumulative MPT Coverage Identified Raw MPTs H H H H M M M M Queue of selected and prioritized MPTs Fully described MPTs to evaluate Evaluated MPTs BPCH Establish Criteria and Validate with Sponsor Repeat H H L L H H H H M M M M H H L L DoD Guideboooks DoD Programs/Reviews Service Repositories Defense Industry Commercial industry To Users Recommended MPTs Improvements Needed Overall Gap Analysis Research Areas MPT Task Overview Changes Required

Changes to identification process 1 Guidance: – Focus on IC environment (context) changes strategy to initially leverage BPCh Content Provider Network (CPN) – Requires different candidate MPT collection strategy based on IC context and requirements New Strategy: – Extend context attributes of current MPT description to support definition of IC environment – Define and validate IC environment and requirements using a revised MPT description template with extended context attributes – Compare to other environments (contexts) and where similarities are found, mine environment for MPTs

Changes to identification process 2 Tactics: – Develop initial set of context attributes and values that characterize NSA environment based on current understanding – Revise current MPT template to include extended attribute list, MPT requirements, information summary, selection recommendation and support rationale – Validate attributes and practice criteria in requirements interviews with NSA personnel (critical) – Use template for 3-pronged MPT identification efforts 1.Review sources provided in SOW and BPCh CPN 2.Review open literature and web-based sources 3.Capture current applicable NSA MPTs 1 and 2 can begin when initial template is available; 3 depends on sponsor participation and ability to coordinate schedules/access – Adapt selection criteria and process to using the new template

Identify and Mine Comparative Environments for MPTs MPT Task Changes Refine Templates and Select MPTs for Evaluation Initial MPT Candidate Templates Queue of selected and prioritized MPTs Validate Environment and Needs with Sponsor H H H H M M M M H H L L Review sources provided in SoW Establish Preliminary Sponsor Environment and Needs Develop Extended MPT Template Review literature and web Access experts through team Extended environmental attributes Conduct interviews

MPT Identification/selection Activities 1 Establish Preliminary Sponsor Environment and Needs – Develop initial MPT evaluation/characterization template – Revise and extend proposed attribute set Extend context attributes One-page template for candidate identification Validate Environment and Needs – Interview sponsor personnel Describe the type of people to interview Develop interview structure based on the template Revise preliminary attributes, values and needs and capture new ideas – Revise/extend template as needed – Revise evaluation criteria based on needs assessment Italics indicate tasks of the workshop

MPT Identification/selection Activities 2 Gather MPT candidates from broader community based on environmental description – Identify best approach for this – First target is INCOSE Workshop next week Identify comparable environments – Through literature, web and expert inputs, identify development/acquisition/deployment environments that share attribute values with validated sponsor environment Mine comparable environments for candidate MPTs – Review SOW-specified sources – Review comparable environments as they are identified for candidate MPTs

MPT Identification/selection Activities 3 Select MPTs for evaluation – Review candidate templates – Refine and extend template descriptions for promising candidates – Select evaluation candidates

Initial environment description The NSA environment can be described as – A short development cycle to meet quick response needs with lowered quality requirements at initial deployment – Evolutionary deployment strategy that may begin with limited deployment at relatively low-quality and evolve into broader deployment at higher quality – High level of interdependency with existing products “Mashing” and expanding of results from other projects to create new results Providing new results for further processing by others Modifying existing capabilities to meet rapidly changing constraints and/or availability of different data High level of glueware

Original MPT Attributes MPT Attributes – What changes are needed?

Proposed Revised Schedule

MPT Activities during workshop First Session – Clean up environment description (Rich, Ken) Less geek language – more general description Is there a taxonomy to help with completeness? Hopefully discuss with customer – Determine and define attribute changes (including values) (Forrest) – Develop the MPT mining template (Paul?) Second Session – Brainstorm MPT mining activities (Paul) Opportunities, “helper” groups (INCOSE, Redstone SE group, etc.) Methodology – Build necessary instruments for INCOSE (Forrest) Possible extra session after the SERC reception tonight? – Possibly at Radisson or near airport (depending on majority)

Backup

Systems Engineering and Level-of-Effort Contracts Dennis Barnabe, SERC PM 21 Nov 2008 SERC Kickoff Meeting

Slippery Slope Logic Mission-card Agility Prototype/Discovery LOE Contract

Relationships to Agility High Low LRequirements DetailH LocalMission SatisfactionBroad LMaintainabilityH H Redundancy RiskL LScalabilityH LComplexity/SizeH LIntegration/InteroperabilityH Project Type PrototypeQRC + O&M LRIP + O&M Prod + O&M Contract Type LOE/T&M/TTO Delivery/Turnkey

(Usual) LOE SE Implications Requirements lacking Limited (if any) ‘formal’ Reviews – No coordination/insight among related efforts – Interface and duplication risks – No ability to assess technical health Standards application, etc No formal ‘transition’ planning – What if it works? Build to Cost – No actual cost estimate of satisfying mission need – If successful, Operations cuts into Development Deemed ‘tech transfer issue’ Schedule lacking – Inability to coordinate among other efforts “Success” defaults to ‘what is delivered’

Tailoring vice Avoidance Iterative Acquisition Development Discovery Deploy ? QRC Operational Baseline 90 Days 90 Days Deployments

Right Tool for the Job LOE has its niche SE (& Acquisition) approach must evolve as Objective changes – Prototype/Discovery – QRC – Limited Ops – Full Ops – Production

SE “Equalizer” Requirements Configuration Management Technical Reviews Technical Documentation Testing Life Cycle Planning Prototype or Discovery

SE “Equalizer” Requirements Configuration Management Technical Reviews Technical Documentation Testing Life Cycle Planning QRC

SE “Equalizer” Requirements Configuration Management Technical Reviews Technical Documentation Testing Life Cycle Planning Development with eye toward sustained Ops

Possible LOE SE Leverage Points Ensure Standard Inclusions – On contract – Adherence ‘Formal’ Gates for phase transitions – Prototype/PofC QRC Limited Ops Sustained Ops Evolve SE Processes appropriately for given Phase – TTOs must be written to support

Possible new contextual attributes Brainstormed attribute list with values where available – to be refined! – Criticality for meeting requirements (QRC-high, QRC-low, high, medium, low) – Volatility/evolution of requirements (High (>1%/month), Normal(.01- 1%/month), low (<.01%/month) – Level of quality required at deployment (functional, reliable, critical) – Level of security required at deployment (SCI, Classified, Unclassified) – Dependence on other systems for critical data and functionality (Very high, high, medium, low, none) Need to coordinate among other efforts Assessability of technical health (health of data sources required?) – Length/stability of life cycle Stability of life cycle definition (phases) Evolution/stability of required ceremony in response to system life cycle needs – how do I prepare enough ceremony up front to be able to make adjustments easily when system maturity/deployment change – nondeterministic? Breadth of applicability Uniqueness of application (are 3 people already doing this and you don’t know it) Scalability – in function and number of copies deployed Level of transition planning required