ES 678 Engineering of Agile Systems and Enterprises Team Members: Brian Andrews Craig Kerr John Parker.

Slides:



Advertisements
Similar presentations
A new Network Concept for transporting and storing digital video…………
Advertisements

Presentation begins at 6:30 p.m.
7-1 INTRODUCTION: SoA Introduced SoA in Chapter 6 Service-oriented architecture (SoA) - perspective that focuses on the development, use, and reuse of.
Eric Bryant Joe Brooks Matt Delgadillo.  The RCT is a mobile training platform designed in response to the need for modular and interactive training.
T-FLEX DOCs PLM, Document and Workflow Management.
Shared Learning Services : Key Learnings Session 102 November 9, 2009.
Azad Madni Professor Director, SAE Program Viterbi School of Engineering Platform-based Engineering: Rapid, Risk-mitigated Development.
ENTERPRISE SOFTWARE.
Course Instructor: Aisha Azeem
Agile Process: Overview n Agile software engineering represents a reasonable compromise to conventional software engineering for certain classes of software.
Team: Juan Pablo Pods System:Modular Aircraft Exterior Pods Strategic Values/Objectives Inexpensive Low Certification Costs Quick Reaction Capable Universal.
MS DYNAMICS. MS DYNAMICS ERP  Microsoft Dynamics ERP is software that allows companies of all sizes to manage their entire business organizations, including.
Team: AlphaDroners System: Alpha Drone 1 Strategic Values/Objectives: Unmanned Reconfigurable Adaptable Safe Autonomous/Manual Descriptive Statement: The.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse 2.
Team: AlphaDroners System: Team WikiSpeed Descriptive Statement: To build a street legal vehicle that gets at least 100 miles per gallon, is capable of.
Agile Systems and Enterprises Response Ability Tool Templates Robert Douglas Gault Randy Hosier.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
1 CMPT 275 Software Engineering Software life cycle.
Chapter 2 The process Process, Methods, and Tools
Dr. Tom WayCSC Software Processes CSC 4700 Software Engineering.
Agile Software Development Chapter 3 – Lecture 1 Adrián Susinos.
Team: Juan Pablo Pods System:Team WikiSpeed Strategic Values/Objectives High Fuel Efficiency (Green Design) 5 Star Crash Safety Customizable design Uses.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
The Eyeblaster ACM Advertising Campaign Management.
Agile Systems and Enterprises Response Ability Tool Templates Randy Hosier Robert Douglas Gault.
7-1 Management Information Systems for the Information Age Copyright 2004 The McGraw-Hill Companies, Inc. All rights reserved Chapter 7 IT Infrastructures.
Agile Systems and Enterprises Response Ability Tool Templates.
Chapter 6 Architectural Design.
Service Oriented Architecture (SOA) Dennis Schwarz November 21, 2008.
Team: _Island Breeze_____________ System:_WikiSpeed________________ Strategic Values/Objectives Flexibility Iterative Timelines Efficient Boundless Descriptive.
Catawba County Board of Commissioners Retreat June 11, 2007 It is a great time to be an innovator 2007 Technology Strategic Plan *
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
LESSON 3. Properties of Well-Engineered Software The attributes or properties of a software product are characteristics displayed by the product once.
Software Maintenance Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
Marv Adams Chief Information Officer November 29, 2001.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Lectures 2 & 3: Software Process Models Neelam Gupta.
1 Acquisition Automation – Challenges and Pitfalls Breakout Session # E11 Name: Jim Hargrove and Allen Edgar Date: Tuesday, July 31, 2012 Time: 2:30 pm-3:45.
Team Name: Team 1 Modular Test Unit (MTU)
Drone D-Fence EMP Based Drone Defense System
Team Name: Team 1 Agile Engineering Process
PLM, Document and Workflow Management
System: Team WikiSpeed Process
Team Name: OCD Solutions
EIN 6133 Enterprise Engineering
Team: Three Maintainers and a *ing Op System: Team WikiSpeed
Agile Trainers – AEP Analysis
“Right Side” Technology Systems
“Right Side” Technology Systems
Introduction to Software Engineering
ES 678 Agile Systems Pat Bullock Brian Dodds Mike Leonard
Team: _____JAR_________________ System: ____Agile Bid System (ABS)_
Team: ______Houston Euler________
Team: Jeff Olvera Ron Palmer Alli Roland
Agile Process: Overview
Team Name: OCD Solutions
Descriptive statement
School of Systems and Enterprises Stevens Institute of Technology, USA
Team: ______Houston Euler________ System:_____WikiSpeed___________
WikiSpeed Work Team: Car Riders Team members: Dmitry Retunski
ES 678 Agile Systems Pat Bullock Brian Dodds Mike Leonard
Team: Remote Site Team: Virtual System Integration Lab (VSIL)
Descriptive Statement
School of Systems and Enterprises Stevens Institute of Technology, USA
Team: __Remote Site_____________ System: ___TWS__________________
WikiSpeed Process Team Pest Control Mike McMahon Justin Petersen
Team: Whirlybird System: Adaptive Multi-Rotor UAV Platform
T-FLEX DOCs PLM, Document and Workflow Management.
Presentation transcript:

ES 678 Engineering of Agile Systems and Enterprises Team Members: Brian Andrews Craig Kerr John Parker

 Strategic Values/Objectives > 100MPG vehicle Street legal Five Star safety rating Uses less stuff Aesthetically pleasing Reconfigurable Descriptive Statement ?

Correction Variation Reconfigu- ration Expansion (and Contraction of Capacity) Migration Improvement Modification (Add/Sub Capability) Creation (and Elimination) Proactive Reactive Change Domain What performance characteristics will the system be expected to improve during operational life cycle? Reduce Change cycle time Reduce Cost of change What must the system be creating or eliminating in the course of its operational activity? Vehicle Development Team Eliminate wasted tool search time High morale What major events coming down the road will require a change in the system infrastructure? Changing Safety Requirements Commercialization – designs and prototypes are not products Team member quality – production team is different from development team What modifications in resources-employed might need made as the system is used? Module management – which modules must be created and why? Strategic product planning ability - What can go wrong that will need an automatic systemic detection and response? Liability/ legal issues Development of system firmware patches and upgrades What process variables will range across what values and need accommodation? Supply chain relationships issues Unanticipated material changes What are “quantity-based” elastic-capacity needs on resources/output/activity/other? Production capacity Optional module development Change management What types of resource relationship configurations will need changed during operation? Manage/restrict module options and interface contracts Certification issues with flexible configurations Customer interface/website Change/Response Issue

Reconfigurable Scalable Reusable Encapsulated Modules Modules are encapsulated independent units loosely coupled through the passive infrastructure. Team leadersModule Designs DevelopersCommunications Processes Tests Facilitated Interfacing (Pluggable) Modules & infrastructure have features facilitating easy module insertion/removal. Communication Standards Process Standards Training/Orientation Facilitated Reuse Modules are reusable and/or replicable; with supporting facilitation for finding and employing appropriate modules. Change pairing Peer-Peer Interaction Modules communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored. Online communications media (social media) Deferred Commitment Module relationships are transient when possible; decisions & fixed bindings are postponed until necessary. Use of stubs Build to order Evolving Infrastructure Standards Module interface and interaction standards and rules that evolve slowly. Process updates Group communications updates Team skill needs Evolving goals Redundancy and Diversity Duplicate modules provide fail-soft & capacity options; diversity provides functional options. Pair working teams Volunteer based workforce Online consultation with deep nerds Elastic Capacity Module populations & functional capacity may be increased and decreased widely within the existing infrastructure. Quick, documentation free introduction of new team members Distributed workplaces Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally. Distributed teams Online documentation (google docs, video) Self-Organization Module relationships are self-determined; and component interaction is self-adjusting or negotiated. Team Swarming SCRUM

developers/ engineers communicationsteam leadersprocesses tests designs Infrastructure evolution System assembly Component mix evolution Component inventory readiness Self organizing Incremental delivery Iterative convergence Emergent requirements Infrastructure X-prize Team Distributed TeamsJoe Justice Components Rules/Standards Integrity Management Active Passive Time Emergent and team Team/Process TL and volunteer emergent Team leaders (key core practices detailed in a process manual) Agile WIKISpeed Development Process Group communications updates Team skill needs Process updates Evolving goals

Correction Variation Reconfigu- ration Expansion (and Contraction of Capacity) Migration Improvement Modification (Add/Sub Capability) Creation (and Elimination) Proactive Reactive Change Domain What performance characteristics will the system be expected to improve during operational life cycle? Change cycle time Cost of change What must the system be creating or eliminating in the course of its operational activity? High fuel efficiency vehicle Adaptability to multiple, complete changes in track layout What major events coming down the road will require a change in the system infrastructure? Safety Requirements Commercialization Team member quality What modifications in resources-employed might need made as the system is used? Module management Strategic product planning What can go wrong that will need an automatic systemic detection and response? Liability/ legal issues Development of system firmware patches and upgrades What process variables will range across what values and need accommodation? Supply chain relationships Material changes What are “quantity-based” elastic-capacity needs on resources/output/activity/other? Production capacity Optional module development Change management What types of resource relationship configurations will need changed during operation? Manage/restrict module options and interface contracts Certification issues with flexible configurations Customer interface/website Change/Response Issue

Correction Variation Reconfigu- ration Expansion (and Contraction of Capacity) Migration Improvement Modification (Add/Sub Capability) Creation (and Elimination) Proactive Reactive Change Domain What performance characteristics will the system be expected to improve during operational life cycle? Ergonomics Air bags Performance What must the system be creating or eliminating in the course of its operational activity? High fuel efficiency Adaptability to multiple, complete changes in track layout Customer satisfaction What major events coming down the road will require a change in the system infrastructure? Safety Requirements Auto-driving What modifications in resources-employed might need made as the system is used? Additional modules to support different driving styles (multiple aeroshells) Creature comforts (air conditioning, cup holders, GPS, radio, etc.) What can go wrong that will need an automatic systemic detection and response? Replacement and repair parts System firmware patches and upgrades What process variables will range across what values and need accommodation? Fuel efficiency with different modules Color offerings What are “quantity-based” elastic-capacity needs on resources/output/activity/other? Production capacity Passengers and payload Optional modules What types of resource relationship configurations will need changed during operation? Restrict module combinations Certification issues with different module combinations Customer interface/website Change/Response Issue