Complex systems are no longer mysterious.Complex systems are no longer mysterious. We have a broad consensus aboutWe have a broad consensus about –what.

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

Kellan Hilscher. Definition Different perspectives on the components, behavioral specifications, and interactions that make up a software system Importance.
©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.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Not a mystery any more. Complex Systems Engineering Not a mystery any more. It’s time to put complex systems to work.
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.
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.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
1 SWE Introduction to Software Engineering Lecture 5.
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.
Quantum Computation and Quantum Information – Lecture 2 Part 1 of CS406 – Research Directions in Computing Dr. Rajagopal Nagarajan Assistant: Nick Papanikolaou.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 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.
Chapter 7 Designing Classes. Class Design When we are developing a piece of software, we want to design the software We don’t want to just sit down and.
Petter Nielsen Information Systems/IFI/UiO 1 Software Prototyping.
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
CSE 303 – Software Design and Architecture
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Software Processes (Chapter 3)
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
11 Chapter 11 Object-Oriented Databases Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.
Vienna Conference on Consciousness Part I "What is the neural basis of consciousness? Where is it in the brain?" Contribution by Michael L. Berger (Center.
Verification and Validation in the Context of Domain-Specific Modelling Janne Merilinna.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 4310: Software Engineering Lecture 4 System Modeling The Analysis Stage.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
An Introduction to Software Engineering
Software Design: Principles, Process, and Concepts Getting Started with Design.
The Rational Unified Process 1 EECS810: Software Engineering.
Systems Analysis and Design in a Changing World, 6th Edition
® IBM Software Group © 2004 IBM Corporation Developing an SOA with RUP and UML 2.0 Giles Davies.
Object-Oriented Principles Applications to Programming.
1 Database Systems Entity Relationship (E-R) Modeling.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Making the System Operational Implementation & Deployment
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
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.
Object Oriented Analysis and Design Introduction to Rational Rose.
Service-Oriented Architectures Peter Varhol Product Manager, Compuware Columnist, Java Pro June 7, 2004.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 SYS366 Week 2 - Lecture Visual Modeling and Process.
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.
Chapter 8 Analysis & Modeling
Software Processes.
Java Messaging Service (JMS)
Java Messaging Service (JMS)
Making the System Operational Implementation & Deployment
Software Design Lecture : 8
CS310 Software Engineering Lecturer Dr.Doaa Sami
Software Analysis.
Presentation transcript:

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 mean by a complex system, –what their properties are, and –(broadly) how they work. It’s time to put complex systems to work.It’s time to put complex systems to work.

Multi-scalar, i.e., multiple levels of abstraction –IT systems involve quantum physics, solid-state electronics, gates & logic, software (often many levels), strategies, CONOPs, users, … –Prone to phase transitions/chaos: small change → big effect. –Each level illustrates emergence. 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 when implemented in software. Allows for creative new uses, “emergence.” Includes “loosely coupled” components with a certain degree of autonomy, e.g., agents.

Entangled with its environment. –Built to act on its environment—to do something in the world. –Can often be controlled/manipulated by modifying its environment. Often a multi-sided platform. –An operating system, a browser, a shopping center, a standard. –Whoever owns it controls it! (See governance below.) Boundaries are deliberately permeable and indistinct. –Exchanges energy and materials with its environment: eats & excretes. –Must extract energy from its environment to persist. (Far from equilibrium.) –System of systems; the operator goes home; a new president is elected. Must adapt to a continually changing environment. –Always under development/evolving, e.g., version x.y. –Is simultaneously deployed and under development, e.g., Wikipedia. –Must be understood more broadly than as “a deliverable.” –A “social entity” that also includes its users and its developers. –Requires a well thought out governance structure.

To refine, clarify, and formalize these concepts. To make them intuitive, commonplace, and everyday. To make them operational. –To adapt them to practice in building real systems. –To define development processes based on these perspectives. –To build tools to allow anyone to use them.