6:1 [email protected]@stevens.edu, attributed copies permitted es/sdoe 678...

42
[email protected] , attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis, Synthesis, and Performance Session 6 – Synthesis: Design Exercise and Strategy Refinement School of Systems and Enterprises Stevens Institute of Technology, USA

Upload: josephine-sharp

Post on 26-Dec-2015

217 views

Category:

Documents


0 download

TRANSCRIPT

6:1 [email protected], attributed copies permitted

ES/SDOE 678Reconfigurable Agile Systems and EnterprisesFundamentals of Analysis, Synthesis, and Performance

Session 6 – Synthesis: Design Exercise and Strategy Refinement

School of Systems and EnterprisesStevens Institute of Technology, USA

6:2 [email protected], attributed copies permitted

FEEDBACK REVIEW

The last exercise you completed will not be reviewed until you have a chance to

take a second pass through it later.

To prepare for that second pass, we will look at an agile development processand then do a practice run (team trial).

6:3 [email protected], attributed copies permitted

Guest Speaker: Joe Justice Hallway Open Q&A

Recorded at Agile2012 Dallas, TX, 13-17Aug2012

TX, 13-17Aug.Keynote Speaker Joe Justice brought his very first,100 MPG WIKISPEED X PRIZE race-car with him to Agile2012! This is the X PRIZE competition race-car that a volunteer team from around the world built, using agile methods and practices, free collaborative tools, and the driving motivation of a much greater humanitarian dream.In a fun and engaging hallway Q & A -- Joe meets with attendees in a casual unscripted hour of sharing practical Agile knowledge, pointers, and experience. He uses the x-prize car as a case study in excellence, and his experience as an agile coach to speak in practical agile terms across both hardware and software industries. The result is an awesomely insightful and engaging dialogue. You'll find actionable insights you can use to build successful teams for software, or hardware -- for applications or automobiles.

Video at: www.agilealliance.org/resources/learning-center/wikispeed-q-and-aTranscript at: www.parshift.com/s/JusticeJoe-Agile2012HallwayQandA-50-60min-Transcript.pdf

File50-60Transcript

6:4 [email protected], attributed copies permitted

Joe’s WikiSpeed Concept Base16-18 May 2011 Global Scrum Gathering, Seattle, Our Process, Video: http://bcove.me/zcryseb7

Interfaces for modules were specified up front – physical location of bolt holes for instance – no welding.Could evolve all the systems independently of each other.Iterations on designs until test requirements are met.Distributed collaborative team – some working that never had face-to-face contact.

From common sense to manufacturing to software and back to manufacturing.

Agile: reducing cost to make changes. Iterative development.

TDD: clear success criteria and rapid course change.

XP: Pairing and swarming.

Scrum: clearly defined roles and responsibilities.

OOP: clearly defined modules and interfaces.

Kanban: work in progress limits (make sure someone’s not overloaded).

6:5 [email protected], attributed copies permitted

Principles of Joe’s WikiSpeed Approach16-18 May 2011 Global Scrum Gathering, Seattle, Our Process, Video: http://bcove.me/zcryseb7

1. By minimizing cost to make changes we innovate quickly – changes in team members (new member with new skills), tooling, materials, components, even goals (which kept changing as to the type of competition track to be driven to win).

2. By loosely coupling modules we make changes in parallel (many people working on alternate approaches to modules).

3. By working collaboratively in shared space we unblock quickly (you see another person get blocked through body language, a pair starts getting quieter, team sees this and “swarms” early to help).

4. By first automating tests we quickly know if we have improved (regression tests, test driven, metrics are important with measures of success criteria – red/green light).

5. Tests are the success criteria.6. Team morale is a multiplier for velocity (large part of progress success).7. Iterations and stubs (temporary stand-ins that occupy the space a future

module will need so people can work around it instead of waiting for it to materialize) make for constant successes (ask intelligent questions on-line to solve and attracted “deep nerds” with solutions).

6:6 [email protected], attributed copies permitted

Joe: What Are We Giving UP?16-18 May 2011 Global Scrum Gathering, Seattle, Our Process, Video: http://bcove.me/zcryseb7

By eliminating cost to make changes we innovate quickly, changing components and even goals when appropriate:

• We add time and cost to design coupling points and make that time back each time we change a module.

By loosely coupling modules we make changes in parallel: • Requires multiple people with project manager skills.

By working collaboratively in shared space we unblock quickly:• Some folks think it will be distracting, we found dramatically increased velocity.

By first automating tests we quickly know if we’ve improved:• We add time and cost to design before we even start work and solving problems. We get that time back by killing work that is damaging our success metrics, and it also boosts morale which boosts velocity.

Tests are success criteria:• No downside.

Team morale is multiplier for velocity:• No downside.

Iterations and stubs make for constant successes:• Folks might see rapidly replaced modules as waste. Actually less waste and less delaying of an enhancement until the next vehicle build.

6:7 [email protected], attributed copies permitted

ObservationsAgile development people are focused on brand-specific procedurals.Many people are trying to reach “accommodation” between CMMI and Agile.CMMI measured by repeatability of the process.Agile development is measured by speed and quality of the result.How to migrate to Agile Development is a major & critical issue for many.

Reality: Requirements uncertainty on the increase? Deadlines coming sooner? Systems complexity on the increase? Management wants plan-driven predictability, but need agile-driven quality? Govt customers want plan-driven predictability, but need agile-driven quality?

Questions:What are your specific issues with plan-driven vs agile-driven,

for customer, management, supervisor, yourself?Are CMMI and Agile Development

compatible, complimentary, anathema?Is Agile Development dependent on human skills of team leadership?

6:8 [email protected], attributed copies permitted

Deferred Commitment

“Real Options" Underlie Agile [Software Development] Practices

Whether people realize it or not, "freedom to choose" is the underlying principle behind many of the agile practices. We call this principle Real Options. An understanding of Real Options allows us to develop and refine new agile practices and take agile into directions it hasn't gone before. Real Options also help us understand why some people resist some of the practices.To use a familiar phrase, Real Options is about "deferring decisions to the last responsible moment," which is an explicit principle in the Lean Software approach. By avoiding early commitments, you gain flexibility in the choices you have later.

Chris and Olav have collaborated on a book about Real Options and how they really work.

“Real Options” Underlie Agile Practices, Chris Matts and Olav Maassen, Jun 08,2007, http://www.infoq.com/articles/real-options-enhance-agility

6:9 [email protected], attributed copies permitted

Deferred CommitmentViewing Agile [SW] Engineering Processes through Real Options

Real Options are everywhere in agile practices. To illustrate this let's look at some agile practices and point out where commitments are avoided as long as possible. These are just a few examples. Once you become aware of Real Options you will discover a lot more.Behaviour Driven Development and Test Driven Development provide many options, especially "the option to change the software, knowing when you have broken it." Without test driven development, there would be no refactoring. In other words, test driven development removes the need for design commitments, the choice of design can be deferred until after the coding has started. More subtly, Test Driven Development allows the developer to know with certainty that they have finished, instead of determining beforehand when the programming is done. Test driven development requires no decision at all, simply stop coding when all the tests are green. Similarly mock objects allow the developer to defer the decision on how to implement a class until a later time when they have more information on what is required from the class. They also create a nice recursive implementation pattern.XP and Scrum defer the decision about which story to develop until just before the coding starts. This allows the team to incorporate information that arrives at the last moment, such as a new client request. The Scrum Backlog provides a forum where any idea for functionality can be recorded without requiring an immediate commitment to build it.At the project Chris is working on, the development is prioritized based on client requests. In effect, sales drive the prioritisation process by stating the relative importance of a client. The team doesn't start working on a feature until the clients have requested it. "Strategy" meetings were cancelled several months ago because they were just crystal ball gazing about the features the team thought the clients liked. Now the team waits to see what the clients actually request.By delaying commitment on the features built, the team is able to reduce time-to-market for new features requested. When the client requests a feature the team is free to act, because they are not tied up working on unwanted features. This is only possible with short iterations and a fast turnaround on regression testing.

“Real Options” Underlie Agile Practices, Chris Matts and Olav Maassen , Jun 08, 2007, http://www.infoq.com/articles/real-options-enhance-agility

Not said: avoid investment in

work that won’t be used

6:10 [email protected], attributed copies permitted

Class Warm-ups Team Trials Team ProjectUnit 2

Unit 3

Unit 4

Unit 5

Unit 6

Unit 7

Unit 8Unit 9

Unit 10

In-Class Tool Applications

ConOps: Objectives

Reactive/Proactive

RS Analysis

Framework/Modules

RRS

RA Analysis: TWS

RRS Analysis

Reality Factors

RA Analysis: Case

RRS Analysis: Case

Reality + Activities

Integrity: TWS Closure

Team

WikiS

peed

AAP Analysis: Case

6:11 [email protected], attributed copies permitted

Exercise – RRS Analysis of Agile Engineering Process

Continuing from yesterday’s analysis of response issues for managing the Team WikiSpeed (TWS) agile engineering process, you will now show the use of RRS principles to address those issues with an agile management solution. Your knowledge base is the Joe Justice videos. If you have additional appropriate knowledge, from any domain, that’s a plus and should be brought to bear, but it isn’t necessary. You will have to think about the principles that Joe doesn’t articulate.

1. Discuss what you saw in the videos and compare notes amongst your team. 2. Generate:

Slide 1: Drag and Drop AAPSlide 2: RRS Framework Analyses: 10 Principles

Add these slides to your work file: ExAEP-teamname.pptx (or ppt).

Two slidesfor brief out

This exercise is about the principle-based solutions that must address the issues previously identified for a distributed development project which occurs in an unpredictable and uncertain environment – where project requirements, goals, budget, and time may be discovered and may change during the development effort.You are identifying fundamental RRS-based solution elements that your agile process must employ.

6:12 [email protected], attributed copies permitted

aaa cccbbb eee fff

Infrastructure evolution

System assembly

Module mix evolution

Module inventory readiness

Infrastructure

Components/Modules

Rules/Standards

IntegrityManagement

Active

Passive

who

who

who

who

Next Gen Addition?

SocketsSignalsSecuritySafetyService

Config 2 Config nConfig 1

Agile Engineering Process

Graphic template for your modification into your system AAP.Get creative – try some meaningful system configurations and module icons.

ddd

6:13 [email protected], attributed copies permitted

Reconfigurable

Sca

lab

leR

eusab

le

Encapsulated Modules Modules are encapsulated independent units loosely coupled through the passive infrastructure.?

Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal.?

Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.?

Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. ?

Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary.?

Evolving Infrastructure Standards Module interface and interaction standards and rules that evolve slowly.?

Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options.?

Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure.?

Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.?

Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. ?

(Think: Plug-and-Play, Drag-and-drop)RRS Principles for System: ________________________

6:14 [email protected], attributed copies permitted

BREAK

FEEDBACK REVIEW

6:16 [email protected], attributed copies permitted

“Facilitated” Re-Usewww.wikispeed.com/wikispeed-team-blog/what-do-we-mean-by-modular

22Mar2012 posting on WikiSpeed blog:“Here's a 4 minute video of a Jeep getting torn down and reassembled: http://www.wimp.com/rebuildjeep/ Sent in by Team WIKISPEED member Bob Stuart. He titled the post "Historic Modularity".This is awesome, and good to see the evidence of how modularity has evolved. The module contracts in software are broad, so as many types of devices/software can connect to them as responsible. Think USB - it isn't just keyboards, but printers, Christmas trees, Nerf missile batteries. If the jeep suspension allowed tank treads or many types of articulated legs to be attached without changing the rest of the jeep - then it would be modular. As it sits- what Willys did in 1941 was amazing - they maximized the speed and efficiency to swap interchangeable parts.

File4.0

6:17 [email protected], attributed copies permitted

Midterm Homework Prep

Important – You are responsible for:1. Reading the Project Guide and following its instructions2. Emailing completed mid-term homework to the Instructor

by Monday 2 weeks after this class session

6:18 [email protected], attributed copies permitted

You Are There – Inside The System Looking Out

678 Operational Story, Oct. 2007

Nicole LongVince Tur Rojos

6:19 [email protected], attributed copies permitted

Tour-guide us through your system

Carnegie Mellon Engineering, Spring 2006

Describeyour system

during responsivere-configuration

6:20 [email protected], attributed copies permittedIllustration by Christopher Brand

Put your mindin the future.

Imagine your system in operation.

Watch it respond to unexpected circumstances.

Dream about it – then

write about it.

6:21 [email protected], attributed copies permitted

The Value of Thought Frameworksin Creativity (Design) and Communication (Engineering)

“…perhaps ‘creativity’ can be taught. Perhaps even novices with no creative experience — could produce better ideas if they understood the templates. The Israeli researchers, curious about the ability to teach creativity, decided to see just how far a template could take someone.They brought in three Groups of novices and gave each group some background information about three products: a shampoo, a diet-food item, and a sneaker. One group received the background information on the products and immediately started generating ads, with no training. An experienced creative director, who didn't know how the group had been trained, selected its top fifteen ads. Then those ads were tested by consumers. Consumers rated them as ‘annoying.’

A second group was trained for two hours by an experienced creativity instructor who showed the participants how to use a free association brainstorming method. This technique is a standard method for teaching creativity; it's supposed to broaden associations, spark unexpected connections, and get lots of creative ideas on the table so that people can select the very best. If you've ever sat in a class on brainstorming great ideas, this method is probably the one you were taught.Again, the fifteen best ads were selected by the same creative director, who didn't know how the group had been trained, and the ads were then tested by consumers. This group's ads were rated as less annoying than those of the untrained group but no more creative.The final group was trained for two hours on how to use the six creative templates. Once again, the fifteen best ads were selected by the creative director and tested with consumers. Suddenly these novices sprouted creativity. Their ads were rated as 50 percent more creative and produced a 55 percent more positive attitude toward the products advertised. This is a stunning improvement for a two-hour investment in learning a few basic templates! It appears that there are indeed systematic ways to produce creative ideas.

Random House, 2007

www.madetostick.com/thebook/

6:22 [email protected], attributed copies permitted

The Curse of Knowledge “In 1990, Elizabeth Newton earned a Ph.D. in psychology at Stanford by studying a simple game in which she assigned people to one of two roles: "tappers" or "listeners." Tappers received a list of twenty-five well-known songs, such as "Happy Birthday to You" and "The Star Spangled Banner." Each tapper was asked to pick a song and tap out the rhythm to a listener (by knocking on a table). The listener's job was to guess the song, based on the rhythm being tapped. The listener's job in this game is quite difficult. Over the course of Newton's experiment, 120 songs were tapped out. Listeners guessed only 2.5 percent of the songs: 3 out of 120.But here's what made the result worthy of a dissertation in psychology. Before the listeners guessed the name of the song, Newton asked the tappers to predict the odds that the listeners would guess correctly. They predicted that the odds were 50 percent. The tappers got their message across 1 time in 40, but they thought they were getting their message across 1 time in 2. Why?When a tapper taps, she is hearing the song in her head. Go ahead and try it for yourself — tap out "The Star-Spangled Banner." It's impossible to avoid hearing the tune in your head. Meanwhile, the listeners can't hear that tune — all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code.In the experiment, tappers are flabbergasted at how hard the listeners seem to be working to pick up the tune. Isn't the song obvious? The tappers' expressions, when a listener guesses "Happy Birthday to You" for "The Star-Spangled Banner," are priceless: How could you be so stupid?It's hard to be a tapper. The problem is that tappers have been given knowledge (the song title) that makes it impossible for them to imagine what it's like to lack that knowledge. When they're tapping, they can't imagine what it's like for the listeners to hear isolated taps rather than a song. This is the Curse of Knowledge. Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has "cursed" us. And it becomes difficult for us to share our knowledge with others, because we can't readily re-create our listeners' state of mind.

Random House, 2007

www.madetostick.com/thebook/

6:23 [email protected], attributed copies permitted

Your Operational Story Should be Sticky

Simplicity: the idea must be stripped to its core, and the most important concepts should jump out.

Unexpectedness: the idea must destroy preconceived notions about something. This forces people to stop, think, and remember.

Concreteness: avoid statistics, use real-world analogies to help people understand complex ideas.

Credibility: if people don't trust you, they'll ignore you. In some cases, they will be openly hostile, which means they'll actively try to dispute your message!

Emotional: information makes people think, but emotion makes them act. Appeal to emotional needs, sometimes even way up on Maslow's hierarchy.

Stories: telling a story [gets] people into paying closer attention, and feeling more connected. Remember the Jared Subway commercials?

www.madetostick.com/thebook/

Random House, 2007

6:24 [email protected], attributed copies permitted

Unforgettable StoriesA friend of mine is a frequent business traveler. Let's call him Dave. A few years ago Dave was in Atlantic City for an important meeting with clients. Afterward, he had some time to kill before his flight, so he went to a local bar for a drink. He'd just finished one drink when an attractive woman approached and asked if she could buy him another. He was surprised but flattered. Sure, he said. The woman walked to the bar and brought back two more drinks — one for her and one for him. He thanked her and took a sip. And that was the last thing he remembered.Rather, that was the last thing he remembered until he woke up, disoriented, lying in a hotel bathtub, his body submerged in ice. He looked around frantically, trying to figure out where he was and how he got there. Then he spotted the note: don't move. call 911.A cell phone rested on a small table beside the bathtub. He picked it up and called 911, his fingers numb and clumsy from the ice. The operator seemed oddly familiar with his situation. She said, "Sir, I want you to reach behind you, slowly and carefully. Is there a tube protruding from your lower back?"Anxious, he felt around behind him. Sure enough, there was a tube. The operator said, "Sir, don't panic, but one of your kidneys has been harvested. There's a ring of organ thieves operating in this city, and they got to you. Paramedics are on their way. Don't move until they arrive.“

From: Made to Stick, Chip Heath and Dan Heath, Random House, 2007, pg 3, http://www.madetostick.com/thebook/

6:25 [email protected], attributed copies permitted

Grading (For-Credit Students)

10% on class participation:Peer review presentations: demonstration of

relevant knowledge application.Peer review contributions: collaborative

engagement with projects of others.Evidence of study: knowledgeable reference to

the readings.

30% on operational model – Midterm deliverableTwo-page operational story: clear evidence of an

agile system in operation demonstrated with response objectives, requirements, values, response enabling principles, and operational/integrity management.

Three-element response ability model: relevance and clarity of key concepts in RS Analysis, RRS Principles, and Agile Architectural Pattern diagram.

Evidence of study: knowledgeable reference to the literature and readings.

60% on conceptual design report – Final deliverableArticulate a comprehensive new conceptual

design, or analysis of an existing design: response objectives, issues with metrics, and enabling principles; strategic themes and activity web; closure matrix with descriptions; and operational management and responsibilities – see 678 Project Guidance document for the definitive word.

Evidence of study: knowledgeable reference to the literature and readings.

Reality: The first deliverable is key. Your true understanding of necessary fundamentals is illuminated here. Feedback on this will put your train back on the rails.

due nlt Monday 2 weeks after class

due nlt Monday 6 weeks after class

6:26 [email protected], attributed copies permitted

Course Project (For-Credit Students)(always refer to www.parshift.com/AgileSysAndEnt/ProjGuide/678ProjGuideCurrent.pdf for current requirements)

A newly built

custom assembly

line for each and

every small-batch

run, every time, just

in time.

Life with System X – Agility in ActionBy Rick Dove, Paradigm Shift International, e-mail: [email protected], 505-586-1536, Senior Fellow, Agility Forum

Look through Fred Mauck's eyes for a moment. You work in a GM stamping plant outside of Pittsburgh that specializes in after-model-year body parts. Your principal customer is GM's Service Parts Organization. They might order '73 Chevelle hoods quantity 50, '84 Chevy Impala right fenders quantity 100, or '89 Cutlass Supreme right front doors quantity 300. Your plant stamps the sheet metal and then assembles a deliverable product. Small lots, high variety, hard-to-make-a-buck stuff.

Every new part that the plant takes on came from a production process at an OEM plant that occupied some thousands of square feet on the average; and the part was made with specialized equipment optimized for high volume runs and custom built for that part geometry. To stamp a new deck lid (trunk door) part you bring in a new die set - maybe six or seven dies, each the size of a full grown automobile, but weighing considerably more. And you bring in assembly equipment from an OEM line that

might consist of a

hemmer to fold edges of the metal, perhaps a pre-hemmer for a two-stage process, dedicated welding

apparatus for joining the

inner lid to the

outer lid, adhesive

equipment for

applying mastic at part-specific locations, piercer units for part-specific holes, and automated custom material handling equipment for moving work between process workstations.

You got a call a few weeks ago that said your plant will start making the Celebrity deck lids, and production has to start in 21 days. Not too bad - sometimes you only have four days. For new business like this your job is to get the necessary assembly equipment from the OEM plant, reconfigure the equipment and process to fit your plant, and have people ready to produce quality parts in the next three weeks. Others are responsible for the die sets and stamping end of the production process.

In the last 12 months this happened 300 times. In the last five years you've recycled some 800,000 square feet of floor space in OEM plants for new model production. At this point you have assembly equipment and process for some 1000 different parts - but no extra floor space ever came with any of it.

high-variety production - in a business that is traditionally based on high volume economics - and you've learned to do it without the usual capital budget. Eight years at this has evolved some pretty unique techniques - and a pretty unique culture as well.

You don't do this by yourself - you're a team leader that may use almost anyone from anywhere in the plant. At this point almost everyone is qualified to help bring in new work - surviving under these conditions has developed a can-do/let-me-at-it attitude almost everywhere, and a shared understanding of how to do it.

Eight years ago the plant went to a single job classification in production, cross training everyone on everything - a press operator one day might change dies as well, the next day work in the assembly area building hoods in the morning and fenders in the afternoon - and the following day go off to another plant to review a piece of equipment or part for how to bring it back.

For this new business Jim Lesniewski wanted to do the initial recon. He went on the last trip too, experimenting with his video camera. Now he thinks he's ready to do a perfect taping job. He got the idea himself while trying to bring several jobs at once back from another GM facility. This environment encourages self initiative.

In addition to taping the operational assembly process he added close-ups of key equipment pieces this time. In the debrief review everyone saw the same thing at the same time - there was almost no debate over what to bring back and what to ignore - and you got a jump on the equipment modifications by seeing what was needed in advance. Some time ago the value of having a good cross section represented in these reviews became evident: nobody gets surprised, everyone shares their knowledge, and when the eqchine, two welding robots, the welding fixtures, two press piercers, the shuttles, the press welders, and the three automated material handling fixtures. Basically bringing back a foot print of 200 square feet from a process that covered 2500 square feet. The rest will go to salvage disposition while the hemmer goes to "hemmer heaven" - that place in your plant where some 200 different hemmers hang out until needed.

That you only need the hemmer is where a key part of the plant's unique core competency comes to play. Rather than build a growing variety of product on some

• Problem/Opportunity• Response Objectives• Response Issues/Metrics• Strategic Activity Web• Architecture & Integrity• Applied Principles• Closure Matrix• Conclusion & References

DetailedConceptual Design

Documentation----------------

Comprehensiveto one

Skilled in the Arts

Response Ability Model3 MS PowerPoint Slides

5 Page Operational Model - Due as deliverable #1

Operational Story~ 2 MS Word Pages

~ 20-30 PagesDue as Deliverable #2

Includes strategic objectives/themes

Operational Story

RSA - JIT Assembly Lines

RRS - JIT Assembly Lines

ACP - JIT Assembly LinesAAP

6:27 [email protected], attributed copies permitted

D1 Pages 1-2: Operational StoryNote: All D1 pages 1-5 are about the system IN OPERATION. You MUST tell an after-deployment operational story or your RS Analysis (page 3) will probably be WRONG. This will then make your Closure Matrix (in the final) also WRONG. Note: Unlike the older examples of operational stories – start your 2-page story with a one paragraph System Description, that clearly shows the system objectives, which address uncertain situations, and does so through reconfiguration while deployed.

<system name><authors name>

<system description paragraph> xxxx xxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx.

<system environment UURVE>

<operational story> xxxx xxxxxxx xxxxxxx xxxxx xxxxxxxxxxx xxxxxxxx xxetc

xxxx xxxxxxx xxx xxxxx xxxxxxx xxxxxxx xxxxx xxxxxxxxxxx xxxxxxxx xxetc

6:28 [email protected], attributed copies permitted

Example: UURVE High-Level Response-Needs of Concern

Agile systems have effective situational response under, e.g.: Unpredictability: unknowable situations

Obsolescence of solution approach before completion Critical supplier disappearance

Uncertainty: randomness with unknowable probabilities Feasibility of solution design Continuous political and funding support

Risk: randomness with knowable probabilities Lose in-progress competitive evaluation runoff 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)

6:29 [email protected], attributed copies permitted

Nov2011: www.tassimodirect.com/home-brewing-machines/hot-beverage-brewers

REVIEW

6:30 [email protected], attributed copies permitted

Response IssuesRSA for Tassimo BrewBot In-Operation System

Response Type

Correction

Variation

Reconfig-uration

Expansion(Capacity)

Migration

Improve-ment

Modification(Capability)

Creation

Re

ac

tiv

e

Response Situations

What must the system be creating in the course of its operational activity?• Make different types of hot coffee and tea drinks (t,q,s)

What performance characteristics will the system be expected to improve during operational life cycle?• Match drink flavor to user taste (t,s)

What major events coming down the road will require a change in the system infrastructure?• Multi-lingual display text option (c,s)• Larger size water container capacity option (t,s)

What modifications/evolutions in modules might be needed during the operational life cycle?• Accommodate new drink discs (t,q,s)• Accommodate new drink brewing recipes ((t,q,s)• User wants manual recipe capability (q,s)What can go wrong that will need an automatic systemic detection and response?• Available disc selection not satisfactory to user (t)• Improperly place disc and/or RFID registration (q)

What process variables will range across what values and need accommodation?• Amount of water called for by recipe (t,q)• Pressure of water called for by recipe (q,s)• Temperature of water called for by recipe (t,q,s)

What are the key resource and/or performance bounds on necessary system response?• Small to large drink quantity (t,q,s)• Cup size physically accommodated (t,c,s)

What types of resource relationship configurations will need changed during operation?• Recipe brewing steps and sequence (t)• Multiple discs for a single drink (t,q)

Pro

ac

tiv

e

• Water filtration option (c)• Cold drinks?

• User intelligence (q,s)

(D1 Page 3: Remove example bullets and use this tool form or one exactly like it)

6:31 [email protected], attributed copies permitted

Reconfigurable

Sca

lab

leR

eusab

le

Self-Contained Units (Modules) Modules are encapsulated independent units loosely coupled through the passive infrastructure.• Base units• Flavor discs• Display language• Recipes

Plug Compatibility (Facilitated Interfacing) Modules & infrastructure have features facilitating easy module insertion/removal.• RFID recipe designator on bottom of disc

Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.• Foolproof easy in-and-out of discs• Product mktng mgr responsible for module inventory

Flat Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored.

•Recipes drive brew subsystems directly step by step

Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary.• Brew is determined by disc-inserted RFID recipe

Evolving Standards (Infrastructure) Module interface and interaction standards and rules that evolve slowly.• Brewing sub-systems• Water quality standards• Recipe code• Product eng mgr responsible for evolution

Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options.• Many different types of discs• User inventories as many duplicates as desired

Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure.• Recipe designates small to large amount of water• Cup size is adjustable with base elevator• No limit to variety of discs• Alternate base unit capabilities may be added

Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.• Control is in each RFID recipe, not in the base unit

Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. • Recipe reorganizes brewing steps

(D1 Page 4: Remove example bullets and use this tool form or one exactly like it)RRS Principles for Tassimo Brewbot In-Operation System

• RFID reader

Items here generally address issues on RS Analysis directly and indirectly

• Product eng mgr responsible for module evolution

6:32 [email protected], attributed copies permitted

AAP for Tassimo BrewBot In-Operation System

base units brew stepsdiscs

Infrastructure evolution

System assembly

Component evolution

Component readiness

Infrastructure

Components

Rules/Standards

IntegrityManagement

Active

Passive

Prod eng mgr

Automated recipe

Product eng mgr

Product mktng mgr

recipes display text

2-step lattechocolate

espressocrème

multilingual display

Disc holder, RFID placementRFID scan contentConsumer product regsIgnoredOwners manual

Sockets Signals Safety Security Service

Nov2011: www.tassimodirect.com/home-brewing-machines/hot-beverage-brewers

(D1 Page 5: Remove this example’s detail, or use an appropriate form-tool like it)

6:33 [email protected], attributed copies permitted

MotorsGears/Pulleys

Infrastructure evolution

System assembly

Module mix evolution

Module readiness

Infrastructure

Helicopter Mobile RadarPlane

Modules/Components

IntegrityManagement

Active

Passive

Product Manager

Owner/Builder

Product System Eng.

Retail Distribution Process

Wheels Structural MaterialJoiners, Axles,

Small PartsTools

Agile Architecture Pattern (AAP)

Rules/Standards Radio Control Standards

Control ProtocolParts Interconnect StandardsSockets

SignalsSecuritySafetyService

(None)Harm-Proofing StandardsProcess Rules & ConOps

(D1 Page 5: another example)

6:34 [email protected], attributed copies permitted

"When I am working on a problem,I never think about beauty, but when I have finished, if the solution is not beautiful, I know it is wrong."-- R. Buckminster Fuller

“Quality is practical, and factories and airlines and hospital labs must be practical. But it is also moral and aesthetic. And it is also perceptual and subjective.”-- Tom Peters

First Pass: 12 O'clock Clockwise (if comfortable)Then Think-Across Until Consistent & Complete

ProjectedOperational

Story

ArchitecturalConcept

& Integrity

ResponseSituation Analysis

RRSPrinciples Synthesis

ConOpsObjectives& Activities

Reality Factors

Identified

ClosureMatrix

(Design)

QualityEvaluation

Response AbilityTools & Process

6:35 [email protected], attributed copies permitted

Avoid This Mid-Term Feedback

1) The Operational Story: Imagine yourself as the person who IS DOING the dragging-and-dropping to make the system respond to all manner of interesting “issues” in real time. Imagine you are a playing an instrument. You are the musician. Make some music – and describe how the instrument responds!2) The Reactive and Proactive issues you listed are not from the operational-system point of view, but rather from the system-design point-of-view. You have listed the issues you will deal with as the designer rather than the issues the system will deal with in operation. What will the system have to create, for instance, not what you the designer has to create.3) The Proactive and Reactive issues (problems) you listed are in fact solutions you expect to be using. This will become a problem when your closure matrix discussion describes how the application of "RRS principles" solves an "issue" (problem) within an "activity" – that discussion should be viewing these "issues" as things that have to be responded to, on the fly in an uncertain environment.4) Migration issues are anticipated or likely changes to the infrastructure (framework) that will permit next-generation capability. Thus, anticipating IPv6 Internet protocol as an eventual replacement for IPv4 is proper, whereas anticipating a new type of node on the Internet is not, unless that new node type will also require a new infrastructure rule/protocol/standard for the Internet. 5) Your topic appears irrelevant to systems of interest in your professional employment.

IF THIS IS CONFUSING…NOW IS THE TIME TO CLEAR IT UP

6:36 [email protected], attributed copies permitted

Avoid This Mid-Term Feedback

6) You forgot to show the metrics (tcqs) on your proactive/reactive issues.7) The metrics you show for the “improvement” issues are simply a repeat of the improvement that has to be made. Page 74+ in the Text Book describes metrics as applying to the act of change, rather than the performance to be improved. Perhaps the cost of your process does have to be improved, but the metric to show on that issue is more likely time (t), if it has to be improved fast because you are bleeding dollars, or maybe scope (s), because your costs are 3x tolerable, or quality (q), because it has to be no more than 50% of the fixed-fee you will receive.8) Your deliverable does not include one or more of the following:- Operational story – with strategic themes/objectives clearly stated- RS Analysis- RRS Principles applied- Architectural Concept PatternUseful feedback cannot be given without all of these present. Please complete the missing parts and resubmit asap.9) You’ve got a mixed systems focus here and a confused picture emerges of what is being analyzed in the tools. The tools should analyze the system in the story, and the story should be clear about bounded system mission and methods. 10) You appear to have taken the quick and dirty rout – winging it on remembered or forgotten class hours and the words in the templates, with no real understanding of what they mean – study of the text book is expected, but apparently you’ve chosen to postpone that?

IF THIS IS CONFUSING…NOW IS THE TIME TO CLEAR IT UP

6:37 [email protected], attributed copies permitted

From L3 Student

Thanks again for the great class.It took a couple of days, but it finally occurred to me what agility was all about with regard to systems engineering.I realized that when your developing an agile system, you’re really developing the “erector set” that can be assembled into a Farris wheel, as opposed to just building a Farris wheel.

----------------You should think of design of an agile system as a design of a Lego set or erector set so that a user can assemble whatever they need whenever they need to, in response to whatever the current situation requires.

6:38 [email protected], attributed copies permitted

Getting it Right

Download Unit 11, linked on your class page, and read it – it is a small collection of the slides from the 10 class units that pertain to the expectations for mid-term and final deliverables.

Read the Project Guidance document, linked on your class page, before you start your mid-term and final project, and again before you submit your mid-term and final project.

6:39 [email protected], attributed copies permitted

4 Integrity Management Responsibilities(Agile Software Engineering Process Example)

The “active” (governance) part of the infrastructure

Module Mix/Evolution: New module addition and upgrade as new capabilities are needed (new developer skills, newly developed code modules, new test suites for new code, new procedures as indicated by a changing situation, user representatives intimate with next stage feature development needs, etc).

System assembly: configure modules into on-demand system configurations suitable for changing response needs (successive iterations in the development process).

Module Inventory Readiness: Maintaining sufficient inventory of modules ready for use (development people, team leaders, engagement procedures, reusable code modules, reusable test suites, etc).

Infrastructure evolution: improvements to existing rules and standards, new rules and standards.

Paper at: www.parshift.com/Files/PsiDocs/Pap080614GloGift08-LifeCycleMigration.pdf

6:40 [email protected], attributed copies permitted

In-Class Tool Applications

Class Warm-ups Team Trials Team ProjectUnit 2

Unit 3

Unit 4

Unit 5

Unit 6

Unit 7

Unit 8

Unit 9

Unit 10

ConOps: Objectives

Reactive/Proactive

RS Analysis

Framework/Modules

RRS + Integrity

RA Analysis: TWS

RRS Analysis: TWS

Reality Factors: Case

RA Analysis: Case

RRS Analysis: Case

Reality + Activities

Integrity: TWS Closure

AAP Analysis: Case

6:41 [email protected], attributed copies permitted

Exercise

Make ready for presentation start of next session

Generate one new slide, refine another1)Ideas for how the 10 RRS

principles might be employedon your team project.

2)Refine previous architectural concept diagram andadd 4 integrity management responsibilities.

6:42 [email protected], attributed copies permitted

Reconfigurable

Sca

lab

leR

eusab

le

Encapsulated Modules Modules are encapsulated independent units loosely coupled through the passive infrastructure.?

Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal.?

Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules.?

Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. ?

Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary.?

Evolving Infrastructure Standards Module interface and interaction standards and rules that evolve slowly.?

Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options.?

Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure.?

Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.?

Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. ?

(Think: Plug-and-Play, Drag-and-drop)RRS Principles for System: ________________________