Osh summit talk_v1.5

Editor's Notes

1. Jim Barkley & Sam Sayer work for The MITRE Corporation, which is a Systems Engineering company our backgrounds in CSCI so we basically have no idea what we’re doing in this hardware business, which hasn’t stopped us from being opinionated about where it’s headed20s
2. Born out of 40s and 50s when weapons systems and aerospace grew beyond scope & tools of separate engineering disciplines Focus is on total system being engineered, such as a missile or an airplane Means a lot of focus is on integration of various engineering teams developing subsystems, team coordination, design & management issues Attempts to encompass a broad range of factors in system development, for instance cost/schedule/planning management, as well as engineering S.E. was always intended to be a practical, real-world approach The joke that goes around about systems engineering is that nobody actually knows what it is This actually not true. S.E. today is well-defined and has been codified in a number of standards, processes, documents and other artifacts Here are just a few juicy references for you of the many that exist Don’t have time to go too deep into S.E., but let’s show you a couple of function-following-forms
3. Systems Engineering is notorious for these kinds of diagrams Heavyweight processes for controlling risk as you take a full system through it’s life from concept development all the way to sustainmentThis is just one small piece in the larger SE Fundamentals guidebook from DAU20s
4. This is a “SEMP”, a Systems Engineering Management Plan, which is another diagram that shows up from time to time. There is even an eclipse plugin for Open Source Systems Engineering that tries to bring agile techniques to this particular process model. Again we can see phases like Concept of Operations, Requirements, Subsystem development, subsystem testing, system integration and verification, validation, O&M, etc.30s
5. - Here’s an example from a real DoD program just to give you something a little more tacit This is only the 13 Elements in First Level of WBS A WBS is a way to define and group the engineering tasks which need to be done In this case, they are clearly driven by the S.E. processes underlying big system acquisition. And remember that S.E. was always intended to be a pragmatic, engineering approach to driving down risk and producing value in real, operational systems.25s
6. This is how the government buys and builds new things it’s everyone’s favorite whipping boy I’ll grant that it is in many ways not particularly conducive to agile engineering, and it is one of many artifacts of a 50-year engagement with a fixed threat. However, we have to respect for what it is and the history behind it. When scrutinized, it is clear that this thing is intended to drive down risk in oh so many dimensions, and is driven by many underlying S.E. principles If you think this is unique to the USG, think again. How about other major system manufacturers, for instance from the auto industry? Toyota has one bad recall for gas pedal stickage in how many decades of good business? And as a result, the Toyota brand promise of quality is in serious jeopardy. In the case of the DOD the cost of failure can mean huge taxpayer burden and possibly risk lives In both cases, that amount of risk leads to this level of complexity. We have to respect those roots.90s
7. What does Open Systems Engineering look like?Being born out of a hobbyist community, this has taken the form of kits. There is where we get the name of our talk, almost ready to fly print, some assembly required.
8. What does agile systems engineering look like.Like agile software methods, we’re changing how hardware and systems are developed.Less focus on rigid process and more on rapid iteration
9. In the early 90’s agile software processes started to emerge Following on the heels of Open Source software Open Hardware is emerging now Already seeing “agile systems engineering
10. There is ongoing research into advancing traditional systems engineering to deal better with today’s adaptive, complex, and highly dynamic environments But another evolution of systems engineering is also coming from a more surprising place Open community models of development, which emerge organically But what makes open models so valuable? By the time an end user purchases a project for operational use (not research, development, or education) it matters little to them that it is open hardware, software, or architecture. As system developers, what’s valuable about open models is that it allows us to develop better products faster Therefore, it’s not the end product but rather the path through which that product is achieved What is it about these methods of development that allows open projects to rapidly ascend this disruptive curve?30s
11. - A big part of it, is the ability to innovate.This is a paraphrase from Eric Von Hippel on community innovation. What it says is that user communities innovate better because they know what they want. We hear this all the time at MITRE in the software world. - But what’s so great about innovation? Maybe that coffee cup factory is a better investment…30s
12. - A big part of it, is the ability to innovate.This is a paraphrase from Eric Von Hippel on community innovation. What it says is that user communities innovate better because they know what they want. We hear this all the time at MITRE in the software world. - But what’s so great about innovation? Maybe that coffee cup factory is a better investment…30s
13. We’re really good at systems requirements analysis, design and development.Our strengths draw from being our own end users. We know what we want, and we have a passion for building it and making it better because it makes our own lives better.
14. Some areas for improvement.Operations & Maintenance – We’re struggling to support the project in the post-define phase. While we’re really good at developing & designing open systems, we need to improve the phases that follow. System Integration is responsibility of the end user, not part of design. “Heroes” integrate separate systems in interesting ways.
15. RMA = Reliability, Maintainability, and AvailabilityThese are things that are not easy to do, but also not easy to win at. One small mistake here can cause large problems, as Jim mentioned about Toyota. Currently we’re utilizing an “opt-in” model, we acknowledge these shortcomings and are awarRMA and Safety Engineering are considered whole fields of technical specialty in the Systems Engineering ecosystem.