HFS500

1. HFS500 System Concepts, Theories, and Tools Instructor: Dr. Kelly Neville

2. Foot Stompers for this Class • Don’t become dependent on tools and techniques • Don’t lose sight of the ‘whole’ when working on the parts. • Don’t neglect the connections and relationships, e.g., • Reverberation • Stigmergy • Boundaries • Competition • Cooperation and synergy • If complexity is part of the system, don’t remove it. • Complexity management doesn’t equal complexity removal.

3. Win! Fill your toolbox. Think about system resilience.

4. Two contrasting but equally limited views of a system.

5. Ludwig von Bertalanffy, originator of General Systems Theory Dave Snowden on matching work processes to type of work system: http://www.youtube.com/watch?v=Miwb92eZaJg

6. Technology-Centered Design User-Centered Design Resilient-System-Centered Design

7. Complex System • A web of interdependent elements in which elements change unpredictably and the effect of one element on another can change from moment to moment. • Interdependency • unpredictability • Nonlinearity • Can produce large events (e.g., “black swans”; tipping points) • Tend to be able to withstand large events (are resilient) • Produce emergent phenomenon • Capable of producing great novelty and increasing variety • Adapt/Evolve

8. User-Centered Design Resilient-Systems-Centered Design Technology-Centered Design Dave Snowden’s Cynafin Matrix

9. Modern systems tend to be complex. These two sets of methods make different assumptions about the nature of systems User-Centered Design Resilient-Systems-Centered Design Technology-Centered Design Many methods may be ill-suited for engineering today’s complex systems. Dave Snowden’s Cynafin Matrix

10. User-Centered Design Resilient-Systems-Centered Design Technology-Centered Design Myth #1: Systems development is a ‘simple’ endeavor. Myth #2: Systems development is a ‘complicated’ endeavor.

11. Myths and Mismatches in Systems Engineering • System development is a linear process—e.g., analyzedesignbuildtest. • System requirements are to be identified early and then frozen. • The requirements are knowable in advance of the system’s implementation. • Users can tell you what the system needs to do, i.e., the system requirements. You just have to be persistent to get it out of them. • But not too persistent because you have to give them exactly what they specify. • Make sure they sign off on these requirements so they don’t try to introduce costly changes mid-effort. • Systems engineering involves developing technology solutions. Technology = system.

12. Myths and Mismatches in Systems Engineering • Human factors people are needed to help determine the system’s requirements from the users’ perspective. (Period.) • Analysis = Decomposition • Decomposition and functional allocation = Design. • Success means achieving stated customer requirements within budget and on time. • Systems development can be described and understood in the language of one’s own discipline. • There is a right way to engineer a system. There is a right way to run a systems development project. • Systems engineering tools and procedures are more important than research, data, feedback, and experience.