CASE Afternoon Primer Session Topics of Discussion July 22, 2013 FINAL DRAFT.

Slides:



Advertisements
Similar presentations
Dr. Rogelio Dávila Pérez
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Unit 2. Software Lifecycle
Chapter 2 Software Processes (1/2) Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
Chapter 2 – Software Processes Lecture 1 1Chapter 2 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA Dennis Smith, David Carney and Ed Morris DEAS.
CMMI – Continuous as well as staged model CMMI capability levels – Incomplete, performed, managed, defined, quantitatively managed, optimized Example.
Systems Engineering in a System of Systems Context
Soft. Eng. I, Spring 07Dr Driss Kettani, from I. Sommerville1 CSC-3324: Chapter 5 Requirements Engineering Reading: Chap. 6, 7 + annex.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
© Copyright Eliyahu Brutman Programming Techniques Course.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 10: Architectural Design
Systems Dynamics and Equilibrium
Chapter 10 Architectural Design
UML - Development Process 1 Software Development Process Using UML (2)
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1.
An Introduction to Software 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)
Lecture 9: Chapter 9 Architectural Design
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific.
Lecture 3 Software Engineering Models (Cont.)
Chapter 13 Architectural Design
Lecture 7: Requirements Engineering
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
1 | 2010 Lecture 1: Systems – what and why?. Covered in this lecture Systems and systems thinking Why we use Systems Engineering Systems from “cradle.
An Introduction to Software Engineering
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Lesson Objectives All of you should be able to: Identify the parts of any given system. Most of you will be able to: Describe all elements of any given.
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Chapter 10 요구사항 모델링 : 클래스 기반 방법론 Requirements Modeling: Class-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for.
20CC Ltd Independent Consultants © 20CC Ltd Systems Thinking Overview Sources from The Open University acknowledged.
Smart Home Technologies
Mahmut Ali GÖKÇEIndustrial Systems IEU Introduction to System Engineering ISE 102 Spring 2007 Notes & Course Materials Asst. Prof. Dr. Mahmut.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 9: Design Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Chapter 13 설계 개념 Architectural Design 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for the book “Software Engineering: A Practitioner’s.
Engr 691 Special Topics in Engineering Science Software Architecture Spring Semester 2004 Lecture Notes.
Software Engineering Lecture 10: System Engineering.
1 SYS366 Week 2 - Lecture Visual Modeling and Process.
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
Chapter3:Software Processes
UML Diagrams: Class Diagrams The Static Analysis Model
Chapter 13 Architectural Design
Architectural Design.
Chapter 13 Architectural Design
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
CIS 375 Bruce R. Maxim UM-Dearborn
Object-Oriented Analysis
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Chapter 9 Architectural Design
Chapter 13 Architectural Design
An Introduction to Software Architecture
Chapter 9 Architectural Design.
Automated Analysis and Code Generation for Domain-Specific Models
Software Analysis.
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

CASE Afternoon Primer Session Topics of Discussion July 22, 2013 FINAL DRAFT

Topics for Primer Discussion: Attributes of Complexity Subset* 1. Interactions: Multiplicity of interactions and feedback – relationships between one part of the system and some other entity, along which information or influence may flow  Evolving or self-organizing interfaces – Change during the course of operation and evolve  Openness – Boundary interactions with the environment 2. Emergence: System behaviors or qualities not directly traceable to the system's components, but rather to how those components interact  Only exists at the system level and is not exhibited within isolation at the subsystem levels.  Scaling doesn’t work  emergent behavior changes the system * This is NOT a comprehensive list of the attributes of complexity; these are isolated topics for CASE Primer discussion. 2 FINAL DRAFT

Some Candidate Complexity Approaches for Engineering and Development Extracted from ‘A Complexity Primer for Systems Engineers’ ‡ 3 Requirements Elicitation and Derivation Trade StudiesSolution Architecture and Design Development Process Intricate and evolving / self- organizing interactions with the environment Include requirements for the system to provide adaptive local control, rather than strong, deterministic control Trade end-to-end system performance and behavior against problem space complexity. Think hierarchy rather than flat networks. Early implantation (or at least prototyping) of external interfaces Early deployment of system functionality with feedback to developers Emergent properties or behaviors in solution system Maximize description of emergent properties in scenarios and mission definition Elicit requirements from multiple perspectives and at multiple levels of aggregation; ensure requirements and constraints at all relevant levels are understood Understand the real value of predictability at different levels; encourage the definition of requirements at higher “essential value” levels Employ modeling and experimentation to ensure relevant effective trades are explored at different levels of aggregation Build in feedback mechanisms to enable the system elements to adapt to the environment and each other in effect ways. Acknowledge the limits to the value of decomposition-based methods; emergence is a collective phenomenon that requires aggregation – emergence will not be discovered until the system is considered as a whole Conduct development activities always within context of the whole Employ collaborative development processes so that information about design decisions are visible throughout the project Prototyping and holistic testing are critical to explore and check for the manifestation of emergent behavior ‡ Sheard, Cook, Honour, Hybertson, Krupa, McEver, McKinney, Ondrus, Ryan, Scheurer, Singer, and Sparber A complexity Primer for Systems Engineers. INCOSE Complex Systems Working Group. FINAL DRAFT

4