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

29
[email protected] , attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis, Synthesis, and Performance Mid-Term & Final Deliverable Guidance: Presented during class School of Systems and Enterprises Stevens Institute of Technology, USA

Upload: silvester-glenn

Post on 26-Dec-2015

223 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:1 [email protected], attributed copies permitted

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

Mid-Term & Final Deliverable Guidance: Presented during class

School of Systems and EnterprisesStevens Institute of Technology, USA

Page 2: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:2 [email protected], attributed copies permitted

Some Term Project Ideas(must be relevant to your professional employment)

Agile Systems Integration Laboratory – Architecture and OperationService Oriented Architecture (eg, supporting Agile Enterprise)

Agile Aircraft Depot Maintenance HD&L OperationsJoint Tactical Radio System (eg, Interoperability)

Agile Enterprise Practices for QRC ResponseAn Agile Aircraft xxx System Utilizing COTS

Agile Systems-Engineering (eg, for QRC)Agile Concepts for Outsourcing Support

Team WikiSpeed Modified for Work-Related ProcessApplying Agile Systems Concepts in the Workplace

Agile System Integration, Verification, and Validation ProcessAn agile migration process from status quo to a more agile operation

Agile Development-Infrastructure Concepts for Other-Than-Software Projects(e.g., software development uses Object-Oriented development platform)

Should decide on a topic before Unit 6 – For Approval

Page 3: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:3 [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 deliverableThree-element response ability model: relevance

and clarity of key concepts in RS Analysis, RRS Principles, and Architectural Concept Pattern diagram.

Two-page operational story: clear evidence of an agile system in operation demonstrated with response objectives, requirements, values, response enabling principles, and operational/integrity management.

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 (9Mar)

due nlt Monday 6 weeks after class (4May)

Page 4: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:4 [email protected], attributed copies permitted

Minimum: 80 Hrs Outside-of-Class Work10-20 Hrs reading the text book30-20 Hrs researching and noodling40 Hrs composing and writing

You are Graduate StudentsA – Thoughtfully engaged with demonstrated application-design understandingB – Read, followed instructions, applied tools, demonstrated utility understanding C – Any of: blew it off, no understanding of basic concepts demonstrated, didn’t

complete the closure matrix and discussion or other basic project steps.

---- This is about: how your system addresses surprises (primary) not about what your system does functionally (secondary)Key: When it clicks…that drag-and-drop, plug-and-play (operational activity)is enabled by “encapsulated” modules and “evolving” frameworks, and that you have this all around you in your life…and you already know it well:• Providing dinner for surprise guests• Assembling a team for a task• Appreciating your football team in action• Reconfiguring your home entertainment system or your PC

Strawman budget

Page 5: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:5 [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

Page 6: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:6 [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

Page 7: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:7 [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)

Page 8: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:8 [email protected], attributed copies permitted

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

REVIEW

Page 9: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:9 [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 in resources-employed might need made as the system is used?• 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 “quantity-based” elastic-capacity needs on resources/output/activity/other?• 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)

Page 10: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:10 [email protected], attributed copies permitted

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

RRS Principles for Tassimo Brewbot In-Operation System

Items here generally address issues on RS Analysis directly and indirectly

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 modules 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

• RFID reader

Page 11: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:11 [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

(D1 Page 5: Replace example elements or use an appropriate form tool like it)

Disc holder, RFID placementRFID scan contentConsumer product regsIgnoredOwners manual

Sockets Signals Safety Security Service

Page 12: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:12 [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)

Page 13: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:13 [email protected], attributed copies permitted

RS Analysis for System ____________________

Correction

Variation

Reconfigu-ration

Expansion(and

Contractionof Capacity)

Migration

Improvement

Modification(Add/Sub

Capability)

Creation(and

Elimination)

Pro

ac

tiv

eR

ea

cti

ve

Change Domain General Issues

What types of resource relationship configurations will need changed during operation?• ?• ?• ?

What performance characteristics will the system be expected to improve operational life cycle?• ?• ?• ?

What must the system be creating in the course of its operational activity?• ?• ? Use as many bullet points as appropriate• ?

What major event coming down the road will require a change in the system infrastructure?• ?• ?• ? What modifications in resources-employed might need made as the system is used?• ?• ?• ?

What can go wrong that will need an automatic systemic detection and response?• ?• ?• ?

What process variables will range across what values and need accommodation?• ?• ?• ? What are “quantity-based” elastic-capacity needs on resources/output/activity/other?• ?• ?• ?

with [t,c,q,s] metric-priorities for each issue, t = time of change, c = cost of change, q = quality of change, s = scope of change

Page 14: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:14 [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 modules 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: ________________________

Page 15: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:15 [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

Graphic template for your modification into your system AAP.General approach – needs creative touch in icon and configuration depictions

Your System Name Here

Refer to file: TemplatesArchitectureConceptPatterns.ppt for many examples

ddd

Page 16: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:16 [email protected], attributed copies permitted

HH

PNM Agile Substation-Design System

engineers switchgeartransformers terminationstructures

low-voltagefeeders

stationsteel

Infrastructure evolution

System assembly

Component evolution

Component readiness

System rules manualTransformer standards

Infrastructure

H Station Fly-Thru StationT Station

Components

Rules/Standards

IntegrityManagement

Active

Passive

chief engineer

design engineer

DASL program mgr

min/max purchaser

T T H H H

DASL design tool

TT

Architectural Concept Pattern Diagram

H-pad standardsFly-pad standards

T-pad standards

www.parshift.com/Files/PsiDocs/Pap080404Cser2008DevOpsMigration.pdf

Page 17: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:17 [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

Page 18: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:18 [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- 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

Page 19: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:19 [email protected], attributed copies permitted

System: __________________________

Strategic Values/ObjectivesFunctional Activity

Strategic Activity Web

Change the lines and bubbles,this is not a fill-in-the-blank model

Page 20: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:20 [email protected], attributed copies permitted

Reality Factors

Organizational Behavior – Survival rules rule, nobody's in control...• ?

Human Behavior – Human error, whimsy, expediency, arrogance...• ?

Technology Pace – Accelerating vulnerability-introductions, sparse testing...• ?

System Complexity – Incomprehensible, highly networked, unintended consequences, emergence...• ?

Globalization – Partners with different ethics, values, infrastructures...• ?

Other?• ?

Agile Adversaries – Distributed, collaborative, self organizing, proactive...• ?

Creeping Agile Practices – Outsourcing, webservices, transparency, COTS, SOA...• x

System: _______________________

Page 21: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:21 [email protected], attributed copies permitted

Integrity Management Responsibilities forSystem _______________________

Module Mix/Evolution (who decides/specifies/adds which new types of modules,

excises old useless modules):

• ?• ?• ?

Module Inventory Mgmnt (who maintains serviceability/readiness and quantity

on hand of which modules):

• ?• ?• ?

Real-Time Configuration (who assembles/configures/reconfigures the systems): • ?• ?

Infrastructure Evolution (who reviews and modifies the various infrastructure elements):

• ?• ?• ?• ?

Page 22: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:22 [email protected], attributed copies permitted

Sel

f Con

tain

ed U

nits

Plu

g C

ompa

tibili

ty

Fac

ilita

ted

Re-

Use

Pee

r-P

eer

Inte

ract

ion

Def

erre

d C

omm

itmen

t

Dis

trib

uted

Con

trol

& In

fo

Sel

f Org

aniz

ing

Fle

xibl

e C

apac

ity

Uni

t Red

unda

ncy

Evo

lvin

g S

tand

ards

Issues Principle-Based Activities and Issues Served

Activities

R

ea

cti

ve

Pro

ac

tiv

e

??

??

??

??

??

??

??

??

??

??

??

??

?? 1

?? 2

?? 3

?? 4

?? 5

?? 6

?? 7

RRS Principles<your system>

Excel template version(a different template file)

may be easier to use

Page 23: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:23 [email protected], attributed copies permitted

Creating Conceptual Design Closure

The closure tool is where design thought gets deep. Here the preliminary issues, principles, and activities are sifted for relevance and related for synergy. The tool is first used to specify which activities will address which issues, and why; and to verify (in the mind of the designer) that the set of issues and the set of activities are necessary and sufficient. It is a time to step back from the preliminary, somewhat brainstormed, formulation of the problem and the solution-architecture, and do a sanity check before specifying design-principle employment. Not explored further here, Chapter 7 of the text book can assist. The real work with the closure tool is generally on the employment and purpose of principles - the ones that would compromise potential if they are not employed as design elements.

Issue-Focused, Principle-Based Design – Discussion

1)Pick an activity, and describe its general process sequence steps.

2)Do a paragraph for each issue that the chosen activity addresses, and show in that paragraph how the principles are employed to address the issue.

3)The chosen activity must have enough issues and principles to demonstrate your understanding, else pick a second activity and do that as well.

4)See chapter 7 in the text book for an example of what is expected.

Page 24: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:24 [email protected], attributed copies permitted

Chicago Style Citationswww.lib.berkeley.edu/instruct/guides/chicago-turabianstyle.pdf

Chicago style allows you to choose between two systems of providing references: 1. Notes and bibliography: numbered footnotes or endnotes in your text, with Bibliography or Works Cited list at the end of the paper, listing alphabetically the sources in your notes. 2. In-text author-date citations and reference list: in your text, brief parenthetical references consisting of the author's last name, publication year, and page(s) referred to, with an alphabetized Reference List at the end of your paper providing complete entries for works cited in parenthetical references.

----------

Use Chicago Style for Term Paper: http://wwwlib.murdoch.edu.au/find/citation/chicago.htmls

http://www.chicagomanualofstyle.org/tools_citationguide.html

Page 25: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:25 [email protected], attributed copies permitted

On Writing Papers

Understand how to convey the value and purpose of your work. Understand correct use and form of references and citations.Understand the need and purpose of a literature review.Understand the purpose and nature of an abstract.Understand the various kinds of plagiarism.Understand your reviewer’s criteria.

Read peer-reviewed published papers and note how they deal with these issues.

Term papers are expected to be near conference quality.Master’s paper’s are expected to be peer-reviewed conference/journal-quality.

For a good tutorial (40-60 minutes) on academic and Journal-quality papers, see INCOSE Webinar #7 by Brian Sauser at www.incose.org/practice/webinars.aspx

Page 26: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:26 [email protected], attributed copies permitted

Avoid This Final-Project Feedback1) Everything noted in the 4-week deliverable things to avoid applies to 10-week

deliverable.2) Comments made in the 4-week deliverable feedback were not addressed.3) Activities sound like things (nouns) rather than processes (verbs).4) Closure Matrix Discussion: You didn’t do it like it was asked for: pick one

single activity, detail it’s process steps, then do a paragraph for each issue that the chosen activity addresses and show in that paragraph how the principles are employed to address the issue. The chosen activity must have enough issues and principles to demonstrate your understanding, else pick a second activity as well. See chapter 7 in the text book.

5) Closure Matrix: Your issues are very specific features/solutions rather than generally stated response problems that the “activities” address with the employment of ‘principles’. There is a hierarchy in the closure matrix concept: On one extreme, issues are totally general. On the other extreme, the employment of principles is very specific. Activities are the intermediate “mechanism” for applying engineering principles in the specific solution of a general problem.

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

Page 27: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:27 [email protected], attributed copies permitted

Avoid This Final-Project Feedback6) Your final deliverable does not include one or more of the following:

- Operational story- RA Analysis of proactive and reactive operational-response issues- RRS Principles in bulleted application- Architectural Concept Pattern diagram- ConOps Strategic Objectives and Activities web- Reality Factors- Integrity Management Discussion of four responsibilities- Closure Matrix relating activities, issues, and principles – with discussion.- Conclusion

7) You are confused about the differences between, and proper use and form of, references, footnotes/endnotes, and bibliographies.

8) This is supposed to be graduate-level work. You need to have someone proof your work for intelligible use of English and/or excessive typos.

9) All tables with bulleted items are to be explained in the text so the concept referred to by the bullets are understandable by the reader.

10)You ignored proper and consistent reference and/or citation format.

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

Page 28: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:28 [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

Page 29: 11:1 rick.dove@stevens.edurick.dove@stevens.edu, attributed copies permitted ES/SDOE 678 Reconfigurable Agile Systems and Enterprises Fundamentals of Analysis,

11:29 [email protected], attributed copies permitted

"Make no little plans; they have no magic to stir men's blood and probably will themselves not be realized.

Make big plans; aim high in hope and work, remembering that a noble, logical diagram

once recorded will not die, but long after we are gone will be a living thing, asserting itself with ever-growing insistency"

[Daniel Burnham, architect].

Explore the Possible for Your System