Not a mystery any more. Complex Systems Engineering Not a mystery any more. It’s time to put complex systems to work.

Slides:



Advertisements
Similar presentations
[ §4 : 1 ] 4. Requirements Processes I Overview 4.1Fundamentals 4.2Elicitation 4.3Specification 4.4Verification 4.5Validation Requirements Definition Document.
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Multimedia Specification Design and Production 2013 / Semester 1 / week 7 Lecturer: Dr. Nikos Gazepidis
Unit 2. Software Lifecycle
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA Dennis Smith, David Carney and Ed Morris DEAS.
CSCU 411 Software Engineering Chapter 2 Introduction to Software Engineering Management.
Design & Decision Support Systems for Architectural Design and Urban Planning Prof.dr.ir B. de Vries M.A. Orzechowski, Msc.
Software Engineering COMP 201
Complex Systems CoP Complex System Engineering R. Abbott Corporate Chief Architect/Engineer Division (Rotation) 19 April 2007.
January 11, 2007Russ Abbott Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 2 Software Processes.
January 11, 2007Russ Abbott Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a.
We have a broad consensus about what we mean by a c omplex system.We have a broad consensus about what we mean by a c omplex system. They are not a mystery.
1 California State University, Fullerton Chapter 13 Developing and Managing Information Systems.
January 11, 2007Russ Abbott Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a.
January 11, 2007Russ Abbott Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a.
Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a broad consensus about –what.
1 SWE Introduction to Software Engineering Lecture 5.
Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a broad consensus about –what.
We have a broad consensus about what we mean by a c omplex system.We have a broad consensus about what we mean by a c omplex system. They are not a mystery.
We have a broad consensus about what we mean by a c omplex system.We have a broad consensus about what we mean by a c omplex system. They are not a mystery.
Course Introduction and Overview of Software Engineering Richard N. Taylor ICS 221 Fall 2002.
Lead Black Slide. © 2001 Business & Information Systems 2/e2 Chapter 13 Developing and Managing Information Systems.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
January 11, 2007Russ Abbott Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a.
Katanosh Morovat.   This concept is a formal approach for identifying the rules that encapsulate the structure, constraint, and control of the operation.
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
© 2001 Business & Information Systems 2/e1 Chapter 13 Developing and Managing Information Systems.
University of Utah SoCCS Lecture 61 Architecture – An Introduction CS Lecture 6 Nathan Dykman.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 2: Software Process Omar Meqdadi SE 2730 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Ch:10 Component Level Design Unit 4. What is Component? A component is a modular building block for computer software Because components reside within.
Knowledge Technologies March 2001 DataChannel, Inc Preserving Process Hyperlink-Based Workflow Representation W. Eliot Kimber, DataChannel, Inc.
Database System Development Lifecycle 1.  Main components of the Infn System  What is Database System Development Life Cycle (DSDLC)  Phases of the.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 4310: Software Engineering Lecture 4 System Modeling The Analysis Stage.
Develop a Safety Assurance approach for Complex Systems (Problem Definition) Supervisors: Tim Kelly, Rob Alexander Chris Leong HISE Group Giving a Presentation.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 1 Chapter 13 Finalizing Design Specifications.
An Introduction to Software Engineering
Example: object diagram for Scheduler, v What is wrong with this diagram? Seems like a lot of similarity between Task and UnplannedTask Can use.
The Rational Unified Process 1 EECS810: Software Engineering.
Systems Analysis and Design in a Changing World, 6th Edition
University of Southern California Center for Systems and Software Engineering Approaching the Design Stages Pongtip Aroonvatanaporn CSCI577 Fall 2010 November.
Object-Oriented Principles Applications to Programming.
Agent Overview. Topics Agent and its characteristics Architectures Agent Management.
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with IBM Rational Software Architect V7.5 Module 17: Team Modeling.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Making the System Operational Implementation & Deployment
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
Service-Oriented Architectures Peter Varhol Product Manager, Compuware Columnist, Java Pro June 7, 2004.
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
Concepts of Engineering Module 2 Test Review. Review Questions Design problems are broken down into sub- problems because smaller problems must be solved.
1 Process activities. 2 Software specification Software design and implementation Software validation Software evolution.
Software Engineering Lecture 4 System Modeling The Analysis Stage.
Common Design Patterns
Coupling and Cohesion 1.
Software Life Cycle “What happens in the ‘life’ of software”
Software Process Models
Making the System Operational Implementation & Deployment
Software Design Lecture : 8
Copyright 2007 Oxford Consulting, Ltd
Software Analysis.
Logical Architecture & UML Package Diagrams
Presentation transcript:

Not a mystery any more. Complex Systems Engineering Not a mystery any more. It’s time to put complex systems to work.

Characteristics - structure Multi-scalar –Multiple levels of abstraction (not self-similar). IT systems involve quantum physics, solid-state electronics, gates and gate logic, software, business strategies, … Vulnerable to phase transitions: small change → big effect. –If the system involves real physical stuff … No feasibly simulatable bottom level. Quarks? Strings? –E.g., an evolutionary arms race. The different levels cannot be completely isolated from each other — or we would have magic –except for levels implemented in software. –Allows creative new uses, “emergence.” –Includes “loosely coupled” components with a certain degree of autonomy, e.g., agents. Multi-disciplinary (see levels of abstraction)

Characteristics - environment Entangled with its environment. –Systems are often built to act on their environments—to do something in the world. –Systems are (often) controlled/manipulated by modifying the environments within which they exist. Boundaries are not always clear. –System of systems. The operator goes home at night. Often a multi-sided platform. –Internet, Windows/Mac/Linux OS, game platform, shopping center. Must extract energy from its environment to persist. –“Far from equilibrium.” Requires continual adaptation to a changing environment. –Always under development/evolving, e.g., version x.y. –Is simultaneously deployed and under development, e.g., a wiki. –Must be understood more broadly than as “a deliverable” but as a social entity that also includes its developers and its users.

Our task Clarify and formalize these concepts. Make them intuitive and commonplace. Make them operational. –Adapt them to practice in building real systems. –Build tools to allow anyone to use them.