Expediting Systems Engineering

advertisement
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
Download