Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training Copyright © 2009, David Emery & D&S Consultants,

Slides:



Advertisements
Similar presentations
Kellan Hilscher. Definition Different perspectives on the components, behavioral specifications, and interactions that make up a software system Importance.
Advertisements

Object-Oriented Software Development CS 3331 Fall 2009.
Virtual University - Human Computer Interaction 1 © Imran Hussain | UMT Imran Hussain University of Management and Technology (UMT) Lecture 16 HCI PROCESS.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Chapter 2 The Software Process
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
ITIL: Service Transition
COBIT - II.
By Collin Smith COBIT Introduction By Collin Smith
SE 555 Software Requirements & Specification Requirements Management.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
200209–CSSA0001 – 16/27/ :25 PM CSSA Cepeda Systems & Software Analysis, Inc. GENERIC.
Course Technology Chapter 3: Project Integration Management.
Iterative development and The Unified process
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Object Oriented Analysis and Design Using the UML
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
Enterprise Architecture
Credits: Adopted from Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright Agile.
Chapter 6– Artifacts of the process
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
What is Business Analysis Planning & Monitoring?
Developing Enterprise Architecture
Chapter : Software Process
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Documenting Software Architectures
S/W Project Management
Introduction to Software Quality Assurance (SQA)
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
The Challenge of IT-Business Alignment
CEN rd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Phases of Software.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
BSBPMG505A Manage Project Quality Manage Project Quality Project Quality Processes Diploma of Project Management Qualification Code BSB51507 Unit.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Rational Unified Process Fundamentals Module 5: Implementing RUP.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Software Design Process
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
1 EMS Fundamentals An Introduction to the EMS Process Roadmap AASHTO EMS Workshop.
BSBPMG404A Apply Quality Management Techniques Apply Quality Management Techniques Project Quality Processes C ertificate IV in Project Management
CSE 303 – Software Design and Architecture
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
Software Engineering (CSI 321) Software Process: A Generic View 1.
Rational Unified Process Fundamentals Module 5: Implementing Rational Unified Process Rational Unified Process Fundamentals Module 5: Implementing Rational.
The Systems Engineering Context
Software Engineering (CSI 321)
Systems Engineering Tool for Intelligent Transportation
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
Chapter 3: Project Integration Management
EA Framework TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture.
Software Verification and Validation
SRS : Software Requirement Specification. How to Write a Software Requirements Specification (SRS Document)  A software requirements specification (SRS)
Presentation transcript:

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info The Metamodel

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -2 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info 4 ‘Big Ideas’ from the Standard 0. Architecture /= Architecture Description 1. Architectures exist for systems (including software-only systems) to satisfy known concerns from stakeholders - This ensures the architecture, and its description, are relevant - Stakeholder concerns, often non-functional, drive the architecture 2. Architecture Descriptions are inherently multi-view - No single view addresses all concerns - A view should cover the entire system (with respect to the concerns of interest) 3. Viewpoints (‘what to describe’) are separate from Views (‘this description’) - Represents current practices with ‘viewpoint sets’ such as Kruchten’s “4+1” - Ensures consistency and repeatability, particularly when evaluating alternative architectures

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -3 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Irrelevant architecture  Common problems - Architecture effort focused on the wrong problems - Architecture effort producing the wrong information - Architecture arriving too late  Applying the Standard - Use Stakeholders and Concerns to identify the most critical problems Hold a Stakeholders & Concerns review early, to get buy-in (e.g. Software Engineering Institute’s “Quality Attribute Workshop”) - Use Viewpoints to make sure the architecture products meet stakeholder expectations Ensure the Viewpoint has the right notations and content Ensure the Viewpoint supports analysis and reviews - Consider 2 ‘quality gate’ reviews Stakeholders, Concerns, Frameworks, Viewpoints, Tools, Schedule, etc View/Model Content

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -4 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info D oing ‘too much architecture’ - Focusing an architecture effort  Common problems - Architecture content not relevant (see previous solutions) - Architecture deliveries poorly understood - Architecture deliveries have wrong content - Architecture content not integrated into other project life cycle activities and repositories  Applying the Standard - Viewpoints provide the ‘document descriptions’ for architecture content Viewpoints should trace to identified Stakeholder Concerns (relevance) Viewpoints should define model content and modeling techniques, including tool usage and evaluation/review/qualification - Views and Models provide a basis for estimating architecture effort Viewpoint tells you what will be in the View and how to produce it This facilitates planning the effort - Prioritizing Stakeholder Concerns and Models help size the architecture effort

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -5 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Making the (architecture) solution ‘fit for purpose’  Common problems - Requirements and operational context/environment for the system not understood or captured - No early representation of the entire system to use for analysis, review or even ‘walkthroughs’ - Non-functional requirements not considered/not considered early enough  Applying the Standard - Stakeholder Concerns should include ‘how does the system fit in its environment?’ Includes identifying driving non-functional requirements Viewpoints should define appropriate analysis/review of non-functional aspects of the architecture, e.g. end-to-end performance models as part of a Performance Viewpoint - Scenario-based evaluation methods such as SEI’s Architecture Trade-Off Assessment Method (ATAM tm ) should be part of the architecture process Viewpoint/Model content should include enough detail for informal walkthroughs of system functions - Connect View content to formal requirements/specifications - Provide appropriate View Correspondence Rules to integrate architecture content

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -6 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Using the Standard to improve architecture practices  Define an Architecture Framework - Capture typical Stakeholders and Concerns in its domain - Identify Viewpoints against those concerns - Identify Models, including content, tool support, evaluation approaches - Identify cross-Model linkages, including how these links are established and maintained - Provide training and maintenance for the organization’s Architecture Framework  Tie the Architecture Framework into the overall development process - Establish an architecture planning process based on Prioritizing Stakeholders & Concerns Estimating resources for producing Views, given Viewpoint descriptions and an understanding of the system of interest - Establish architecture reviews - Establish linkages (including tool support) between architecture work products and other process artifacts/deliverables  Provide for maintenance of the architecture over the system life-cycle

Systems Engineering Simulation Modeling Maintenance Analysis Availability Research Repair Testing Training -7 Copyright © 2009, David Emery & D&S Consultants, inc. See title page for copyright info Sample application of the Standard: Product Lines  Product Lines can/should share a common Architecture Framework  Each product within the Product Line should be a separate (ISO conforming) Architecture Description  The Architecture Framework can define Models that are shared among all product line instances  The conformance points in the standard are defined in terms of a ‘single system in a point in time when conformance is claimed ’ -Consider the ‘architecture’ of each vehicle (built on a common chassis):