Term Project D1 Retrospective L3: 180502 Class High Concept: drag-and-drop plug-and-play modular options to deal with an ever surprising situational environment. Mental Preparation (Operational Story) BEGIN WITH THE END IN MIND: you live in the operational environment, you see a variety of surprises, you can configure an appropriate response for each. You are the architect/designer, and I am the person who will implement your system based on what you send me as D1/D2. Thus, CURVE, Op Story, RSA, RRS, and AAP should instruct me in what you want implemented (Op Story and AAP), how you want it implemented (AAP and RRS), and why (CURVE, Op Story and RSA). What you send me is your plan that you want me to understand and implement as you intend – so make it a clear complete communication. D1 is a preliminary plan – and my comments on D1 are my confusions, questions, suggestions, and attempts to decipher what you really meant that wasn’t communicated effectively. “Good” comments on RSA/RRS/AAP slide areas mean “appropriate” for the tool element intent, does not mean sufficient for your system description. Effective communication of your plan is the objective of D2.

Justifying Your Solution Proposition If you can’t articulate the problem, any solution looks okay. Tools that characterize the problem Space: CURVE (high level problem space characterization) Reality Factors (influences RSA issue identification) Response Situation Analysis (addresses the CURVE) Characterizing the problem space provides the reasons, justification, and traceability for what you propose and design as a solution. It also reveals the extent of what you are considering and not considering. Even if your solution can’t address the full problem space, it is useful to know how much of the problem space can be addressed, and what must be prioritized for subsequent solution-space evolution. Note that D2 effectiveness hinges on the closure matrix – which relates your operational-time activities to your operational-time response issues. If you confused design-time objectives as operational-time response issues you will have to fix this.

Understand the Dynamics of the Environment

Getting Your Head Together What’s the problem you want to solve? Do you really have one? Explain why it is a problem worth solving. Is it caused principally by a CURVE environment? If not, find another problem to solve. If so, of what type? What are the costly surprises? Where isn’t CURVE dealt with in the current systems approach? Could you redesign/replace the current system with a modular, drag-and-drop, plug-and-pay approach to deal with the CURVE environment better? Is an agile adaptable-system approach necessary, or beneficial? In what way? Step away from your favored solution, and understand the problem to be solved.

Pro forma only – not comprehensive CURVE High-Level Response-Needs of Concern Example: System Engineering Process Caprice: unknowable situations Obsolescence of solution approach before completion Requirements additions and changes Uncertainty: randomness with unknowable probabilities Feasibility of solution design Continuous political and funding support Risk: randomness with knowable probabilities Unacceptable cost increases Failure to meet necessary schedule Variation: knowable variables and variance range Critical test facility availability Multiple COTS-source performance differences Evolution: gradual (relatively) successive developments Continuous incremental change in targeted operating environment Alternative technology improvement curves (Moore’s law effect) Pro forma only – not comprehensive

Restrooms Deferred Commitment TOMORROW – One of the greatest labor saving devices of today. Signs to be hung in various places as sign-hanger walks around Restrooms Orientation deferred until time and location of placement. No advanced planning required

Case Example: Electric Distribution Substation Design Substation Designs in 6 Hours – (normally 6 months) Why was this approach needed? PNM’s Second Standard Substation Design DASL provides common framework and common equipment modules Gene Wolf , P.E. T& D World Conference, 2004 Details: www.tdworld.com/mag/power_pointandclick_substation_matures/index.html

CURVE: PNM Electric Substation Design Accurate and rapid designs with low-experience engineers, under: Capricious time to gain construction permits Uncertain availability of competent design engineers Uncertain cost and schedule of transformer delivery Risk of canceled substation need Variable engineer substation-design experience Evolving power-capacity requirements for substation (Note: above only shows reactive CURVE elements, need proactive also) Reputation Goals: Easy, rapid, predictable design Accurate costing Predictable installation completion Low spares-inventory costs Construction exactly as shown in city/county permit approval Case: Public Service New Mexico (PNM)

RF: PNM Electric Substation Design Reality Factors Human Behavior – Human error, whimsy, expediency, arrogance... Engineers aren’t schooled in power engineering. Engineers want to make custom designs. Arrogant less experienced engineers not seeking the advice of more experience engineers. Organizational Behavior – Survival rules rule, nobody's in control... Permitting agencies don’t believe the actual design will match the design submitted for approval. Company wants quicker designs. Company wants reduced spares inventory (cost). Technology Pace – Accelerating vulnerability-introductions, sparse testing, new agile SE methods... Transformer technology-advances requires knowledge-current engineers. New emphasis on smart and internet technologies System Complexity – Incomprehensible, highly networked, unintended consequences, emergence... High knowledge/experience required. Level of complexity increasing with smart grid technologies. Globalization – Partners/customers/employees with different ethics, values, infrastructures, culture... Differing cultural beliefs and values among customers. Increasing foreign cultural background among employes. Partially Agile Enterprise (Faddish Practices) – Outsourcing, web services, SOA, process and progress transparency, COTS policies and affects... Outsourcing substation design occasionally. Agile Adversaries/Competitors/Customers – Distributed, collaborative, impatient, innovative... Grid attacks on the increase. Customer needs change constantly.

RSA: PNM Electric Substation Design Response Domain Response Situation Analysis Proactive Reactive Creation (and Elimination) Substation design (tp) Bill of materials (tp) Construction permit approval (tp) Improvement Time to permit approval (ts) Time to construction completion (s) Cost of spares inventory (ts) Migration High voltage H configurations (cp) Transmission right-of-way fly-through configurations (cp) Modification (of Capability) Upgraded transformer incorporation (tc) Engineer substation-experience maturity (t) Correction Wrong capacity requirement (tc) Inadequate engineer (tp) Transformer delivery too far out (tc) Variation Expertise and skill levels among engineers (ps) Time allowed to complete the project (ps) Expansion (of Capacity) Power capacity range to 9x over base capacity (tp) Reconfiguration Substation power capacity (tcs) Inventory spare transformers used in new construction (t)

RRS: PNM Electric Substation Design Reconfigurable Scalable Reusable Encapsulated Resources Resources are encapsulated independent units loosely coupled through the passive infrastructure. engineers, transformers, switchgear, transmission termination structures, low-voltage feeder circuits, station steel Evolving Infrastructure Standards Resource interface and interaction standards and rules that evolve slowly. DASL design tool ConOps DASL module interconnects, Construction policies/regs Facilitated Interfacing (Pluggable) Resources & infrastructure have features facilitating easy resource insertion/removal. Drag and Drop DASL operation DASL flags improper module-mating Redundancy and Diversity Duplicate resources provide fail-soft & capacity options; diversity provides functional options. Multiple engineers capable of designing Experience of engineers can vary Facilitated Reuse Resources are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules. Drop-down menus for selecting modules Elastic Capacity Resource populations & functional capacity may be increased and decreased widely within the existing infrastructure. Peak design-time activity can employ many easily-qualified design-engineers Peer-Peer Interaction Resources communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. Designers communicate directly with permitting agency to secure approvals Designers communicate directly with inventory management to ensure availability Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. Transformer designers work independent of substation designers, maintaining interconnect standards Deferred Commitment Resource relationships are transient when possible; decisions & fixed bindings are postponed until necessary. Quick design time enables design commitment at last responsible moment Self-Organization Resource relationships are self-determined; and component interaction is self-adjusting or negotiated. Trust relationship between designers and permitting agency is self-organized evolution

AAP: PNM Electric Substation Design Resources T T H H H Integrity Management engineers transformers switchgear termination structures low-voltage feeders station steel Situational awareness Resource mix evolution Resource readiness Activity assembly Infrastructure evolution DASL program mgr min/max purchaser project & chief engineer design engineer chief engineer Active Infrastructure TT HH Passive T Station H Station Fly-Thru Station Sockets Signals Safety Security Service DASL module interconnects Substation requirements Construction policies/regs No development customization DASL design tool ConOps Rules/Standards H-pad standards Fly-pad standards

BACKUP

The CURVE Environment Drives the Response Need Agile systems are defined in counterpoint to their operating environments. Words used to describe the general nature of the target environment often include and combine dynamic, unpredictable, uncertain, risky, variable, and changing, with little attention to clear distinction among them. To design and develop a system that can deal effectively with changing environments it is useful to articulate the nature of changes that should be considered. Agile systems have effective situational response options, within mission, under: Caprice: randomness among unknowable possibilities. Uncertainty: randomness among known possibilities with unknowable probabilities. Risk: randomness among known possibilities with knowable probabilities. Variation: randomness among knowable variables and knowable variance ranges. Evolution: gradual (relatively) successive developments. The difference between risk and variation in this framework is that risk is viewed as the possible occurrence of a discrete event (a strike keeps all employees away), while variation is viewed as the intensity of a possible event (absenteeism varies with the season).

Pro forma only – not comprehensive CURVE High-Level Response-Needs of Concern Example: System Engineering Process Caprice: unknowable situations Obsolescence of solution approach before completion Requirements additions and changes Uncertainty: randomness with unknowable probabilities Feasibility of solution design Continuous political and funding support Risk: randomness with knowable probabilities Unacceptable cost increases Failure to meet necessary schedule Variation: knowable variables and variance range Critical test facility availability Multiple COTS-source performance differences Evolution: gradual (relatively) successive developments Continuous incremental change in targeted operating environment Alternative technology improvement curves (Moore’s law effect) Pro forma only – not comprehensive

Proactive Response: Agile Systems-Engineering Creation: project management strategy (t); project team (t, c); system requirements (t, p); V&V/test plans (t); team collective understanding and learning (t, p); product development [software code, hardware build documentation] (t, c, p). system architecture (t, s); system design (t, c, p); development activity plans (t); Improvement activity effort estimating (p); activity completion to plan (t, c, p); reducing uncertainty and risk (t, p, s). Migration compelling new technology availability (t, c, s); project scope change (s); lean process principles (p). Capability added team member unfamiliar/uncomfortable with management strategy (t); new environmental dynamics (t, c, p, s). Pro forma only – not comprehensive

Reactive Response: Agile Systems-Engineering Correction wrong requirement (t); inadequate developer (t); failed V&V/test (t, c); non-compliant supplier (t, c). Variation expertise and skill levels among team members (p); grace period on schedule (t, c); deliverable performance range (p); availability, interaction, and expertise of customer involvement (s). Capacity 2x project scope change (t, c, p, s); team-size changes of x-y engineers distributed across n-m locations (t, s). Reconfiguration unanticipated expertise requirement (t); development activity-sequence priority change (t). Pro forma only – not comprehensive

Pro forma only – not comprehensive Example: Scrum Agile Architecture Pattern (AAP) Details in www.parshift.com/s/140630IS14-AgileSystemsEngineering-Part1&2.pdf Modules/Components Integrity Management Developers/ Testers Product Owners Scrum Masters Product Backlog Stakeholders Resource mix evolution PO with Team Collaboration Resource readiness Scrum Master, Developers/Testers Situational awareness Everybody Activity assembly Self Organizing Infrastructure evolution Product Owner (PO) Active Infrastructure Passive Scrum Meeting Sprint n Sprint Retrospective Sockets Signals Security Safety Service Peer-Peer Interaction Daily Scrum Info Trustworthy Transparency Collaborative Review Process Rules & ConOps Rules/Standards Retrospective Change Pro forma only – not comprehensive