DYA|Software, Architecture for mission-critical applications Robert Deckers Xootic v1 20101203.

Slides:



Advertisements
Similar presentations
Connected Health Framework
Advertisements

Planning Reports and Proposals
Software Requirements
Presentation Title | Date | Page 1 Extracting Value from SOA.
international strategic management
© Copyright 2006 FPT Software 1 © FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/3 How to work in Fsoft project Authors: KienNT.
Chapter 1: The Database Environment
Requirements Engineering Process
IS301 – Software Engineering V:
10-1 McGraw-Hill/Irwin Copyright © 2010 by The McGraw-Hill Companies, Inc. All rights reserved.
System Development MIS Chapter 6 Jack G. Zheng May 28 th 2008.
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
18 Copyright © 2005, Oracle. All rights reserved. Distributing Modular Applications: Introduction to Web Services.
Objectives To introduce software project management and to describe its distinctive characteristics To discuss project planning and the planning process.
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Communicating over the Network
Micro Focus Research 1 As far as youre aware, how does your organization plan to drive business growth over the next three years? (Respondents' first choices)
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
Chapter 7 – Design and Implementation
Week 2 The Object-Oriented Approach to Requirements
Configuration management
EMS Checklist (ISO model)
Chapter 5 – Enterprise Analysis
Effectively applying ISO9001:2000 clauses 6 and 7.
Testing Workflow Purpose
ABC Technology Project
Describing Complex Products as Configurations using APL Arrays.
Public Thomas Mejtoft Exjobbsredovisning Teknisk fysik, Umeå universitet
MANAGING INFORMATION TECHNOLOGY 7th EDITION
Software Architecture Lecture 3
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
Software Requirements
Quality Manual for Interoperability Testing Morten Bruun-Rasmussen Presented by Milan Zoric, ETSI.
Chapter 2 Using Information Technology for Competitive Advantage Copyright 2001, Prentice-Hall, Inc. MANAGEMENT INFORMATION SYSTEMS 8/E Raymond McLeod,
1 Functional Strategy – IS & IT Geoff Leese November 2006, revised July 2007, September 2008, August 2009.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 28 Slide 1 Process Improvement 1.
Lecture 1: Software Engineering: Introduction
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software processes 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
Lecture 8: Testing, Verification and Validation
Lecture 6: Software Design (Part I)
Lecture 5: Requirements Engineering
MARKETING MANAGEMENT 13th edition
آزمایشگاه مهندسی نرم افزار
Implementation Architecture
Global Analysis and Distributed Systems Software Architecture Lecture # 5-6.
Lecture 8 Systems Analysis: Concept and Principles
Requirements Analysis 1. 1 Introduction b501.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Introduction.
25 seconds left…...
Systems Analysis and Design in a Changing World, Fifth Edition
We will resume in: 25 Minutes.
Marketing Strategy and the Marketing Plan
Database Administration
Chapter 11: Systems Development and Procurement Copyright © 2013 Pearson Education, Inc. publishing as Prentice Hall Chapter
From Model-based to Model-driven Design of User Interfaces.
Chapter 2 – Software Processes
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Enterprise Architecture
Developing Enterprise Architecture
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
An organizational structure is a mostly hierarchical concept of subordination of entities that collaborate and contribute to serve one common aim... Organizational.
Process 4 Hours.
CS 389 – Software Engineering
Chapter 2 – Software Processes
Presentation transcript:

DYA|Software, Architecture for mission-critical applications Robert Deckers Xootic v

2 Architecture “approaches/techniques” Components Interface specifications view RUP Design by contract Object oriented Model driven Zachmann framework Togaf Use case driven Aspect oriented UML++ Performance budgets Software product family Service oriented What to do?

3 Good architecture is… Technology independent Homogeneous components Cost aware Reliable systems Maitainable systems Modular Flexible Fast systems reusable Enlarge profit Simple Service oriented Future proof User firendly systems predictable projects not always Situation dependent

4 System Architectuur Correct, Consistent, Communicated t ROI Project Software engineer Tester Art functionaliteit Correct : it fits the environment Communicated : everyone knows what he should know Government End user Business manager HRM Program manager Network mgt Component builder Application mgt Consistent : its well engineered Good Architecture takes care of:  Control of architecture activitities  Assessable architecture  Good system

5 Good architecture is correct The architecture is based on validated statements about the environent and the stakeholder concerns in particular. Concerns are prioritized. The architecture forms the right balance between the concerns. Achieved by: Consciously balanced concenrs Enough environment analysis Validated environment information “The system fits its environment”

6 Good architecture is consistent The architecture forms a whole. Architecture statements do not conflict with eachother and in relation to the environment. The system can become reality with the architecture. Achieved by: Consciously managed Demonstrable realizable Verification on contradictions “The system is well constructed”

7 Goede architecture is communicated The stakeholders know their relation with the architecture and what is expected from them. The stakeholders understand how their concenrs are covered in the architecture. A communicated architecture starts with a communicatable architecture description Achieved by: Consciously executed Embedded in the organization Translatable into actions “Everyone knows what he should know.“

8 The way to good architecture Master and manage architecture Balanced decisions Guarantee commonality and facilitate variation Do! T Customer need Application Software system Realization Construction Technology Realization process / organization Bedrijfs- functie ProcesInfrastructuur Medewerker Organisatie Dataobject Bedrijfsobject Applicatie Comp 1 Comp 2 Comp 3 Comp 4 App comp 1 App comp 5 App comp 4 Centrale component Correct Consistent Communicated

Content DYA|Software Vision Software architecture and software architect Architecture Reasoning Model Family architectures Manage and master Tasks of the architect Good Architecture Organization wide Softwarearchitectuur

10 Customer Cliënt Consumer Relation Buyer Software development is a human job

11 Definition Software Architecture Based on DYA (architecture guides development) IEEE-1471 (architecture description serves stakeholders) The software architecture of a system is a set of statements that guide the design, realisation and evolution of the software in its environment The statements are a model of: the fundamental structure of the software elements or the relationship between the elements and the environment, principles that guide the creation of the elements

12 DYA – Architecture Process ◦

13 Working area of the software architect Information analist, Business architect Requirements engineer, \ Programmamanager, Project leader, Development manager Software engineer, designer, Tester, Infrastructure/hardware architect Software architect Planning, Development process, Risks, Expertise/knowledge Business needs, Role in the business proces Functionality, Quality Component, Interface Design pattern, hardware resources

14 What architecture does (should do) Offer Solution direction For the most Important properties that are Difficult to realize Main design : functional, technical, approach Architecture principles Business goals - Unique - Right quality Not standard, What went wrong last time? Multiple departments – disciplines - systems

15 Manage and master

16 T Customer need Application Software system Realization Construction Technology Realization process / organization Different concerns Iterative development Based on open source Phase out old system Service delivered via phone, mail, counter and web Before the competition Build off-shore Complies to standard reliable Components should reusabe Runs on a mobile Fast new procducts Share personnel with other project Green image Specific and prioritized  Focus for architecture decisions Organization alignment

17 Different representations Adjust communication to target audience  support in the organization translation into actions by the target audience

18 Different solutions buy – make – outsource – cloud - open source agile – waterfall - … Conscious descisions  Architecture realizable traceable

19 Architecture Reasoning Model T Realization Construction Technology Realization process organization Customer need Application Approach Function Design Environment Border System programmer hardware architect (technical) designer tester Project leader Program manager Development manager Information analist End user businessarchitect / -manager requirements engineer Environment Border System consistent architecture balanced decisions stakeholders aligned

20 Family: applications with the same genes Component 5 App 6 App 7 App 8App 9 App 1 App 5 App 4 App 3 App 2 Family members App 6 App 7 App 2 App 1 Design/realization patterns Use central component Homogeneous landscape  manageable Reuse  faster and better

21 Family architecture: set up Family scope − Criteria: business, technology, process − Possible members Ownership Proces from family to member and back − Family requirements/goals − Deploy and learn

22 Family architecture: Commonality Fix requirements − Part of project requirements − Acceptance criteria Fix (software)elements − Components − Design patterns − Platform… Fix process/organization − Deliverables and how to’s − People: Roles and knowledge

23 Family architecture: variation Software mechanisms: Composition Inheritance Extension Configuration Type instantiation/parametrization Generation

24 Tasks of the architect Analyze environment and system Define the architecture Convey the architecture

25 Environment analysis Other systems − Part of, consists of, chain, family Developments in the environment Find aspects Select stakeholders − Influence and importance − In time Useful concerns: − goals, tasks, information need Validation

26 Define the architecture Balanced decisions Central concepts − Software components − Services − Software as a service − Guidelines − Functions − COTS − Expertise − Aspect orientation Analyse the impact of changes

27 Convey the architecture Select viewpoints Plan the communication Embed the architecture in the realization − Publish the top-level concerns Support mgt decision. Mgt must be aware of: − Architecture Follows business goals − Changing an existing architecture is not easy − Aimed to be a benefit − The architect makes the architecture

28 For architects (that know dutch)