University of Southern California Center for Systems and Software Engineering Expedite Systems Engineering Annual Research Review 2012 March 6, 2012 University of Southern California Center for Systems and Software Engineering Outline • • • • The power of “now” What do we need? Current findings Brainstorming 03/06/2012 © 2012 USC-CSSE 2 University of Southern California Center for Systems and Software Engineering “Urgent” is a new “normal” • Various rapid-reaction programs • Urgent needs expedite the solutions • Driven by “time to market” rather than “complete satisfaction of static requirements” 03/06/2012 © 2012 USC-CSSE 3 University of Southern California Center for Systems and Software Engineering No comprehensive guidance • Use yesterday’s solutions • Overlap in roles and responsibilities responding to urgent requests for similar capabilities, resulting in potential effort duplication • On point solutions – Cumbersome adaptation – Impractical 03/06/2012 © 2012 USC-CSSE 4 University of Southern California Center for Systems and Software Engineering Processes and practices for urgent needs • Add value – not require excessive bureaucratic tasks to implement • Address, understand, manage risks – Know where to include, truncate or eliminate, streamline • Rapid, suitable, and flexible • Capabilities with urgent needs will be more effective, efficient and longer lasting in the field 03/06/2012 © 2012 USC-CSSE 5 University of Southern California Center for Systems and Software Engineering Expedition Opportunities • Product factors – Architecture, Design • Process – Activities, Collaboration • People – Organization, Governance • Project / Program – Locations, tools 03/06/2012 © 2012 USC-CSSE 6 University of Southern California Center for Systems and Software Engineering CORADMO Rapid Application Development Opportunity tree Reducing Time Per Task •Business process reengineering •Development process reengineering •Reusing assets •Application generation •Design-to-schedule Reducing Single-Point Failure Risks •Tools and automation •Work streamlining •Increasing parallelism Eliminating Tasks •Reducing failures •Reducing their effects Reducing Backtracking •Early error elimination •Process anchor points •Improving process maturity •Collaboration efficiency Activity Network Streamlining •Minimizing task dependencies •Avoiding high fan-in, fan-out •Reducing task variance •Removing tasks from critical path Increasing Effective Workweek •Prepositioning resources •Nightly builds, testing •Weekend warriors, 24*7 development Better People and Incentives Transition to Learning Organization Product; Process; People; Project 03/06/2012 © 2012 USC-CSSE 7 University of Southern California Center for Systems and Software Engineering 03/06/2012 © 2012 USC-CSSE RT 34 Progress 8 University of Southern California Center for Systems and Software Engineering CSF for Rapid, Innovative Solutions (Jo Ann Lane, et.al, ICSP’10) • Early concept exploration and feasibility Assessment – – – – Investment in innovation environment Root cause analysis for customer problem Reality Confrontation Customer or sponsor commitment and participation • Value-adding tools • The right people – Empower the best – Enable holistic concurrency – Identify a keeper of the holy vision • Supportive Work Environment Product; Process; People; Project 03/06/2012 © 2012 USC-CSSE 9 University of Southern California Center for Systems and Software Engineering Workshop • Identify system engineering expedition enabler (methods, tools, strategies) based on the following categories – – – – 03/06/2012 Product Process People Project © 2012 USC-CSSE 10 University of Southern California Center for Systems and Software Engineering Expedition enablers: Product Enablers Large Small Reuse/Leverage legacy architectures and components Y Y Separation of concerns (coupling/interfaces/parallel effort) Y Y Focus on Integration of mature technologies/systems/components Y Y Balance between cost, schedule, functionality, quality, stakeholder, and risk Difference in product outcome based on (expedited) process What is considered to be: core data, access to core, value-added capabilities, maverick applications (float above architecture)? - Jeanne Ross - Stable core architecture. Less stable, more flexible, value-added capabilities surround the core. Emergent systems (unknown future, competitors) Standards (but flexible?) for digital dinosaurs, immigrants, kids, new age (Apple generation). -GUI (language), controls, functions, dictionary -Fault tolerance -HCI Data store (database, files). -Create scripts -Ease and flexibility for retrieving, storing information 03/06/2012 © 2012 USC-CSSE 11 University of Southern California Center for Systems and Software Engineering Expedition enablers: Product Enablers Large Small Lessons documented vs. lessons learned Training How integration strategy affects programs? Configuration systems - Customize system to work in different domains, target group Make it an app. Start small. - Covers 85% of people’s needs with an app. Disconnect between systems engineering -Meeting requirements = life or death -Managing technical requirements Commercial -Business = life or death Are requirements treated equal? Commercial process -Cultural mismatch between people, engineers Tolerate faults due to availability of functionalities -Microsoft products Mismanaged and growing requirements Fixed vs. free parameters 03/06/2012 © 2012 USC-CSSE 12 University of Southern California Center for Systems and Software Engineering Expedition enablers: Product Enablers Large Small Deferrables - What can you do without? Can’t separate people from the product. Send a “tool smith” along with tools that are not 100% ready Highest failure rate is due to interoperability with the core infrastructure Phone sex -Communication -Experience spread Norming, storming (not brainstorming), forming, performing, adjourning. Highest risk areas in domain aspects, not technical -Operators -Facility person -Who is important to bring along? Maintainer, logistics -Understanding people’s thought process Data on how risks differ in expedited product/process. - What if you integrate the processes overtime? Total cost of ownership, invention 03/06/2012 © 2012 USC-CSSE 13 University of Southern California Center for Systems and Software Engineering Expedition enablers: Process Enablers Large Small Early Stakeholder Requirements collaboration/refinement. Scope requirements down Y Y Assess Technology Readiness Levels Y Y Stakeholder value modeling/understand trade space Y Y Open methodology -People start picking parts of processes when things get tight -New vs. Old -Agree on important things Tailor up vs. tailor down -Financial tradeoff Trust in project manager to -Reduce risk -Get the job done Rainbow teams -Red -blue: advisory team - Gold team: leveled up blue Most problematic systems start with architecture - Architecture team to review stability of architecture CXO need to be trained to know about: - Computer contracts and development 03/06/2012 © 2012 USC-CSSE 14 University of Southern California Center for Systems and Software Engineering Expedition enablers: Process Enablers Large Small Small peer reviews at the architecture and subsystem levels - Perform peer review at system level Y Y Architecture, technology, and idea transfer -On both contractors and government side -Tell the difference between good vs. junk Y Y Prisoner exchange -No conflict of interests -Common mindset between the two universes Y Y Government RFP process -System engineer RFP’s -Perceived fairness EDR (SRR?), PDR, CDR RFP to pick companies that will do implementation -Match company with product to produce -Government is the agent, not customer Presence of competition and fairness -Missing of trust -Government: business decisions vs. government (political) decisions 03/06/2012 © 2012 USC-CSSE 15 University of Southern California Center for Systems and Software Engineering Expedition enablers: People Enablers Large Small Hands-on experiences important to grow engineers Y Y Diversity (checks and balances within team dynamics) Y Y People with depth and breadth of knowledge -Team must grow to cover loss in personnel Y Y 03/06/2012 © 2012 USC-CSSE 16 University of Southern California Center for Systems and Software Engineering Expedition enablers: Project Enablers 03/06/2012 © 2012 USC-CSSE Large Small Y Y Y Y Y Y 17 University of Southern California Expedition enablers: Final Words Center for Systems and Software Engineering Enablers Large Small Expedite reuse If you want to kill your program, reuse! -Reuse = cost more -Failure = mis-reused something Knowing the history of industry - Broader understanding of where system fits into the business You can’t educate a systems engineer. They need to be brought up in a domain -Apprenticeship 03/06/2012 © 2012 USC-CSSE 18 University of Southern California Center for Systems and Software Engineering Backup 03/06/2012 © 2012 USC-CSSE 19 University of Southern California Center for Systems and Software Engineering Workshop • Identify system engineering expedition enabler (methods, tools, strategies) for each life cycle phase – – – – – 03/06/2012 Exploration Valuation Foundations Development Operations © 2012 USC-CSSE 20