DOCSLIB.ORG

A Software Architecture Framework for Quality-Aware Devops

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

A Software Architecture Framework for Quality-Aware DevOps Elisabetta Di Nitto Pooyan Jamshidi Michele Guerriero Politecnico di Milano Imperial College London Politecnico di Milano Milan, Italy London, UK Milan, Italy [email protected] [email protected] [email protected] Ilias Spais Damian A. Tamburri ATC Politecnico di Milano Athens, Greece Milan, Italy [email protected] [email protected] ABSTRACT Technology) departments are struggling to accelerate the de- DevOps is an emerging software engineering strategy entail- livery of applications and services while preserving produc- ing the joined efforts of development and operations people, tion and operations stability [6]. On one hand, ICT opera- their concerns and best practices with the purpose of realis- tors lack understanding of the application internals including ing a coherent working group for increased software develop- system architecture and the design decisions behind archi- ment and operations speed. To allow software architecture tectural components [2, 4]. On the other hand, development practitioners to enrich and properly elaborate their archi- teams are not aware of operation details including the infras- tecture specifications in a manner which is consistent with tructure, its limitations and benefits. In response to these DevOps, we surveyed a number of DevOps stakeholders. We challenges, DevOps emerges as a set of software engineering studied concerns and challenges to be tackled with respect strategies to create a more cohesive working group inter- to preparing a software architecture which is DevOps-ready, mixing development and operations people, concerns and i.e., described in all details needed to enact DevOps sce- approaches with the aim of increasing the speed to which a narios. Subsequently, we introduce SQUID, that stands for design changes reaches operational software within specified Specification Quality In DevOps. SQUID is a software archi- quality constraints [2]. tecture framework that supports the model-based documen- In this paper we aim at enriching the state of the art in tation of software architectures and their quality properties DevOps with an architecture framework called SQUID, that in DevOps scenarios with the goal of providing DevOps- stands for \Specification Quality In Devops". The SQUID ready software architecture descriptions. We illustrate our framework shows the following key features: (a) is based on framework in a case-study in the Big Data domain. the empirical investigation of software architecture stake- holders, concerns [1] and challenges around specifying and using software architectures in DevOps scenarios; (b) allows CCS Concepts the functional and non-functional specification of software •Software and its engineering ! Software notations architectures in a manner which is most consistent with De- and tools; Designing software; System description lan- vOps scenarios; (c) extends a well known software architec- guages; ture framework, i.e., Philippe Kruchten's original 4+1 Views [9]; (d) conforms to the standard conceptual overview pre- sented in the ISO / IEC 42010 standard for architecture Keywords description [8]. Architecture Frameworks, Model-Driven Design, QoS, QoD Illustrating SQUID we observed that it does indeed pro- vide a valuable starting point to elaborate strategic software 1. INTRODUCTION architecture descriptions within DevOps scenarios -these de- scriptions are in fact, DevOps-ready, i.e., they provide full Today, most organizations face high market pressure, and details concerning the architectural aspects and properties their supporting ICT (i.e., Information and Communication needed in DevOps scenarios. Nevertheless, using SQUID in action as part of a Big Data application description fea- turing DevOps, we also observed that much work still lies ahead around several challenges, such as: (a) using SQUID descriptions as recipes in DevOps-based refactoring; (b) us- ing SQUID descriptions for DevOps-based coordination and division of work; (c) provide appropriate DevOps tooling for the proposed architecture framework. The rest of this paper is structured as follows. Section 2 elaborates on our investigation of the DevOps architecture landscape. Sections 3 and 4 outline the original 4+1 frame- improve the architecture based on performance bot- work and how it is augmented towards elaborating SQUID tlenecks and reliability issues that have been detected while Section 5 applies SQUID to elaborate a Big-Data ap- based on monitoring of the system on real platforms. plication description from a real-life industrial scenario. Fi- nally, Section 6 concludes the paper hinting to future work. 3. Lack of tools and methods adaptable to hetero- geneous DevOps maturity in industry: Devel- 2. DEVOPS PEOPLE AND THEIR ISSUES oping and maintaining modern IT applications (e.g., data-intensive applications) is key to IT market diver- By means of market-scanning and Business-Model Can- sity, spanning from big industrial players and small- vas modelling [5] within the DICE EU H2020 project con- /medium-enterprises. However, there exists a huge sortium's industrial partners we observed several key stake- variety of software processes in this diversity. Such holders, concerns and challenges in the DevOps context - diversity is seldom taken into account from a method- we argue that understanding and covering these is critical ological and technological standpoint. For example, to DevOps success. To understand the DevOps dimensions very few evaluations show the applicability of certain inherent in our scenario, we carried out over 30+ interviews data-intensive design methods within IT companies as well as 3 focus-groups with DICE industrial partners consistent with CMMI (Capability Maturity Model In- concerning what are the practical requirements to support tegration) Level 4 (Quantitatively Managed) or level 2 DevOps-based software development and operations for big (Managed), yet, the industrial adoption of those design data applications. We analysed results through coding and methods may depend greatly on such evaluations. scenario analysis. The results of this exercise are outlined as follows. 4. Lack of Continuous Analytics Frameworks for 2.1 Relevant Stakeholders and Concerns Business Needs and Technical QoS: All types of organizations need to move fast, and need to align IT Table 1 outlines the stakeholders that play a key role in assets to their needs (create new assets or adapt ex- specifying and using software architectures within DevOps isting ones). Therefore, ICT departments need to as- scenarios according to our investigation. Column 1 names sure that their ICT platforms and infrastructures are the stakeholder while Columns 2 and 3 outline a brief de- flexible enough to adopt business changes, regardless scription of the stakeholder's role in the context of DevOps of the type of IT infrastructures used to create those and the concerns this role entails. data intensive applications, whether they are built us- The table essentially shows how the stakeholders and roles ing open-source software or data services offered by typically involved in software engineering [13] are accompa- public cloud providers. In other words, they should nied by a number of stakeholders (e.g., Middleware commu- avoid technological lock-in as much as possible. nities or standardization bodies) that do not have a direct relation to the product but account for the product's or- 5. Lack of Explicit Support for Continuous Ar- ganizational stability, e.g., so that the DevOps cycle may chitecture Refactoring: The tenets behind DevOps be enacted in a long-lived fashion and without hindrance. entail producing actionable architectures that can be Conversely, imagine a scenario where a product is being de- operated and monitored as soon as possible so that as- veloped in a DevOps fashion but software architects and pects such as efficiency, reliability and safety of appli- product owners do not account for standards or middleware cations can be improved incrementally in testing and providers / communities. In this same scenario, proceeding production environments, with metrics and data that without measurement or quantification of the middleware feedback directly and quickly to development teams for community health may lead to community failure and mid- faster testing, improvement and adjustment to meet dleware discontinuation. service level goals. 2.2 DevOps: Industrial Challenges 6. Continuous Fine-Grained Application Monitor- The following key challenges were elicited as part of our ing and Anomaly Detection: Access to live data investigation: gathered by monitoring engines should also provide 1. Lack of automated tools for quality-aware De- performance and reliability data for observed appli- vOps: industries recognise the lack of development cations in production to gauge the need for identifying and continuous delivery of products that has been ver- outliers and detecting any anomaly that may harm ified in terms of quality assurance. In other words, continuous business processes that are dependent to there exists many different frameworks that software such data intensive applications. Moreover, such mon- vendors can adopt in order to develop their applica- itoring data should assist application architects and tions. However, there is no automated mechanism to developers in building toward an optimized target in- enable them to verify software quality across such dif- frastructure. ferent technological stack
Recommended publications
  • Functional Specification for Integrated Document and Records Management Solutions

    Functional Specification for Integrated Document and Records Management Solutions

    FUNCTIONAL SPECIFICATION FOR INTEGRATED DOCUMENT AND RECORDS MANAGEMENT SOLUTIONS APRIL 2004 National Archives and Records Service of South Africa Department of Arts and Culture draft National Archives and Records Service of South Africa Private Bag X236 PRETORIA 0001 Version 1, April 2004 The information contained in this publication was, with the kind permission of the UK National Archives, for the most part derived from their Functional Requirements for Electronic Records Management Systems {http://www.pro.gov.uk/recordsmanagement/erecords/2002reqs/} The information contained in this publication may be re-used provided that proper acknowledgement is given to the specific publication and to the National Archives and Records Service of South Africa. draft CONTENT 1. INTRODUCTION...................................................................................................... 1 2. KEY TERMINOLOGY .............................................................................................. 3 3. FUNCTIONAL REQUIREMENTS........................................................................ 11 A CORE REQUIREMENTS............................................................................................. 11 A1: DOCUMENT MANAGEMENT ................................................................................................. 11 A2: RECORDS MANAGEMENT ..................................................................................................... 14 A3: RECORD CAPTURE, DECLARATION AND MANAGEMENT............................................
  • Software Architecture and Agility

    Software Architecture and Agility

    Agility and Architecture May 18 2010 Agility and Architecture: An Oxymoron? Philippe Kruchten Saturn May 18, 2010 Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of So)ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering University of BriIsh Columbia Vancouver, BC Canada [email protected] Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected] Philippe Kruchten 1 Agility and Architecture May 18 2010 Agile & Architecture? Oil & Water? • Paradox • Oxymoron • Conflict • IncompaIbility Outline • Agility?? • SoSware architecture? • A story • Seven viewpoints on a single problem • The zipper model • A clash of two cultures • Summary Philippe Kruchten 2 Agility and Architecture May 18 2010 Agility • A definiIon – Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Jim Highsmith (2002) • CharacterisIcs – IteraIve and incremental – Small release – Collocaon – Release plan/ feature backlog – IteraIon plan/task backlog Sanjiv AugusIne (2004) Agile Values: the Agile Manifesto We have come to value: • Individuals and interacIons over process and tools, • Working soSware over comprehensive documents, • Customer collaboraIon over contract negoIaIon, • Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the leS more Source: hp://www.agilemanifesto.org/ Philippe Kruchten 3 Agility and Architecture May 18 2010 Geng at the Essence of Agility • SoSware development is a knowledge acIvity – Not producIon, manufacturing, administraIon… • The “machines” are humans • Dealing with uncertainty, unknowns, fear, distrust • Feedback loop -> – reflect on business, requirements, risks, process, people, technology • CommunicaIon and collaboraIon -> – Building trust Named Agile Methods • XP = eXtreme Programming (K.
  • Reflections on Software Architecture Linda Northrop SEI Fellow

    Reflections on Software Architecture Linda Northrop SEI Fellow

    Reflections on Software Architecture Linda Northrop SEI Fellow Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 © 2016 Carnegie Mellon University Distribution Statement A: Approved for Public Release; Distribution is Unlimited Notices Copyright 2016 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. Carnegie Mellon® and CERT® are registered marks of Carnegie Mellon University.
  • PEATS Functional Specification 1 2 Architecture Overview of PEATS

    PEATS Functional Specification 1 2 Architecture Overview of PEATS

    ApTest PowerPC EABI TEST SUITE (PEATS) Functional Specification Version 1.0 April 8, 1996 Applied Testing and Technology, Inc. Release Date Area Modifications 1.0 April 8, 1996 Initial release Copyright 1996 Applied Testing and Technology Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior permission of the copyright holder. Applied Testing and Technology, Inc. 59 North Santa Cruz Avenue, Suite U Los Gatos, CA 95030 USA Voice: 408-399-1930 Fax: 408-399-1931 [email protected] PowerPC is a trademark of IBM. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. Windows is a trademark of Microsoft Corporation. X/Open is a trademark of X/Open Company Limited. ii PEATS Programmer’s Guide Version 1.0 Applied Testing and Technology, Inc. CONTENTS CONTENTS 1Overview1 Document objective 1 Document scope 1 Associated references 1 2 Architecture 2 Overview of PEATS 2 TCL test logic 3 Analysis programs 3 C test programs 4 Installation and configuration tools and methods 4 General framework for static testing of EABI files 5 DejaGNU framework 5 Organization of directories 5 Use of trusted objects 5 Supplemental testing using run-time validation 6 Extensibility of PEATS 7 Adding test programs 7 Adding test variables 7 Testing other tools 7 3 Testing Logic 8 Framework 8 Testing steps 8 Testing choices 9 Exception handling 10 4 Coverage 11 What is tested 11 What is not tested 11 Methods used to obtain broad coverage 11 Checks on coverage 12 5User Interface13 Installation and configuration 13 Building Test Suite components 13 Editing configuration files 13 Runtest command line 14 Basic syntax 14 Applied Testing and Technology, Inc.
  • Kruchten Frog Octopus JSS V6

    Kruchten Frog Octopus JSS V6

    Paper submitted to the Journal of Software and Systems, July 2011, resubmitted November 2011. The frog and the octopus: a conceptual model of software development Philippe Kruchten University of British Columbia 2332 Main Mall Vancouver BC V6N2T9 Canada email: [email protected] phone: +1 (604) 827-5654 fax: +1 (604) 822-5949 Abstract We propose a conceptual model of software development that encompasses all approaches: traditional or agile, light and heavy, for large and small development efforts. The model identifies both the common aspects in all software development, i.e., elements found in some form or another in each and every software development project (Intent, Product, People, Work, Time, Quality, Risk, Cost, Value), as well as the variable part, i.e., the main factors that cause the very wide variations we can find in the software development world (Size, Age, Criticality, Architecture stability, Business model, Governance, Rate of change, Geographic distribution). We show how the model can be used as an explanatory theory of software development, as a tool for analysis of practices, techniques, processes, as the basis for curriculum design or for software process adoption and improvement, and to support empirical research on software development methods. This model is also proposed as a way to depolarize the debate on agile methods versus the rest-of-the-world: a unified model. Keywords: software development, conceptual model, ontology, method, software development process, software engineering, theory Visual abstract for JSS: !"#$%& !"#$%& '()*& '()*& Alternate visual abstract for JSS: Authorʼs bio: Philippe Kruchten is professor of software engineering at the University of British Columbia, Vancouver, Canada.
  • Understanding Architectural Assets

    Understanding Architectural Assets

    ® IBM Software Group Understanding Architectural Assets Peter Eeles [email protected] © 2008 IBM Corporation IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 2 IBM Software Group | Rational software Inputs into this Presentation Working IEEE/IFIP Conference on Software Architecture (WICSA) 2008 18 – 22 February 2008, Vancouver, BC, Canada Working session: Architectural Knowledge IBM Asset Architecture Board Reusable Asset Specification Rational Asset Manager RUP for Asset-based Development © 2006 Tourism Vancouver 3 IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 4 IBM Software Group | Rational software Sources of Architecture Theft From a previous system or from technical literature Method An approach to deriving the architecture from the requirements Intuition The experience of the architect From “Mommy, Where Do Software Architectures Come From?”, Philippe Kruchten 1st International Workshop on Architectures for Software Systems, Seattle, 1995 5 IBM Software Group | Rational software Agenda Introduction Sources of architecture Types of architectural asset Characterizing architectural assets Automating asset reuse Conclusion 6 IBM Software Group | Rational software What Types of Architectural Asset are there? Reference Design Architecture
  • The Software Architect -And the Software Architecture Team

    The Software Architect -And the Software Architecture Team

    The Software Architect -and the Software Architecture Team Philippe Kruchten Rational Software, 650 West 41st Avenue #638, Vancouver, B.C., V5Z 2M9 Canada pbk@ rational. com Key words: Architecture, architect, team, process Abstract: Much has been written recently about software architecture, how to represent it, and where design fits in the software development process. In this article I will focus on the people who drive this effort: the architect or a team of architects-the software architecture team. Who are they, what special skills do they have, how do they organise themselves, and where do they fit in the project or the organisation? 1. AN ARCHITECT OR AN ARCHITECTURE TEAM In his wonderful book The Mythical Man-Month, Fred Brooks wrote that a challenging project must have one architect and only one. But more recently, he agreed that "Conceptual integrity is the vital property of a software product. It can be achieved by a single builder, or a pair. But that is too slow for big products, which are built by teams."' Others concur: "The greatest architectures are the product of a single mind or, at least, of a very small, carefully structured team."2 More precisely: "Every project should have exactly one identifiable architect, although for larger projects, the principal architect should be backed up by an architecture team of modest size."3 1 Keynote address, ICSE-17, Seattle, April1995 2 Rechtin 1991 , p. 22 3 Booch 1996, p. 196 The original version of this chapter was revised: The copyright line was incorrect. This has been corrected. The Erratum to this chapter is available at DOI: 10.1007/978-0-387-35563-4 35 P.
  • Agile Project Management with Scrum: Extension Points

    Agile Project Management with Scrum: Extension Points

    International Conference on challenges in IT, Engineering and Technology (ICCIET’2014) July 17-18, 2014 Phuket (Thailand) Agile Project Management with Scrum: Extension Points Roland Petrasch a few rules and roles that make it easier to understand and Abstract—The introduction of an agile project management apply: approach for the development of software in practice is still a challenge. Scrum is one of the most popular project management 1) Three roles: Team, Scrum Master and Product framework for IT projects, however the individual and project Owner. The team is responsible for the development specific environment and scope of a project requires customizations. of the product, the Scrum Master ensures that the This paper presents some basic considerations regarding process Scrum process is correctly used and the Product models and discusses some extensions and modifications that can be Owner. helpful when Scrum is applied in real life projects: The focus is on 2) Few rules and techniques, e.g. daily (stand-up the specifics of interactive media software projects in order to give a meeting), planning poker, sprint (time-boxing), concrete example. This a done by defining extension points to the requirements (product backlog), monitoring (burn- role model and the artifacts, so that the customization of a Scrum- based project management approach is easier. down-chart) 3) Lightweight process: Sprint planning, sprint Keywords— Agile project management, customization of project (iteration), sprint demo (product review) and management, IT projects, process model, Scrum retrospective (process-oriented quality assurance). The Scrum process model consists of several time-boxes I. INTRODUCTION that allocate a fixed time period.
  • 110707 What Colours Is Your Backlog Boston 2Up.Pptx

    110707 What Colours Is Your Backlog Boston 2Up.Pptx

    Agile New England July 2011 Agility and Architecture or: What colours is your backlog? Philippe Kruchten July 7, 2011 Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of So*ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering University of BriLsh Columbia Vancouver, BC Canada [email protected] Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected] Co founder and past-chair Copyright © 2011 Philippe Kruchten 2 Copyright © 2011 Philippe Kruchten 1 Agile New England July 2011 Outline 1. The frog and the octopus 2. Architecture and agility 3. Release planning 4. Technical debt 5. Architecture, agility,… revisited Copyright © 2011 Philippe Kruchten 5 A Conceptual Model of SoYware Development 4 key concepts, 5 key aributes . Intent . Time . Product . Value . Quality . Work . Cost . Risk . People Copyright © 2011 Philippe Kruchten 8 Copyright © 2011 Philippe Kruchten 2 Agile New England July 2011 Intent, Work, People, Product Copyright © 2011 Philippe Kruchten 9 Frog: “All projects are the same” Value Value Cost Cost Copyright © 2011 Philippe Kruchten 10 Copyright © 2011 Philippe Kruchten 3 Agile New England July 2011 Copyright © 2011 Philippe Kruchten 11 Octopus: “All projects are different!” Size Domain, Age of Degree of Industry the CriLcality Innovaon system Rate of Business change Context model Gover Stable architec nance Corporate & Team ture Organizaonal Naonal Culture distribu Maturity on Copyright © 2011 Philippe Kruchten 12 Copyright © 2011 Philippe Kruchten 4 Agile New England July 2011 SW Dev. Project: Tension between Intent and Product Intent Work V Product Copyright © 2011 Philippe Kruchten T 13 Iteraons Copyright © 2011 Philippe Kruchten 14 Copyright © 2011 Philippe Kruchten 5 Agile New England July 2011 Outline 1.
  • Understanding Document for Software Project

    Understanding Document for Software Project

    Understanding Document For Software Project Sax burls his lambda fidged inseparably or respectively after Dryke fleeces and bobbles luxuriously, pleased and perispomenon. Laird is Confucian and sleet geometrically while unquiet Isador prise and semaphore. Dryke is doltish and round devilish as gyrational Marshall paraffin modestly and toot unofficially. How we Write better Software Requirement Specification SRS. Project Initiation Documents Project Management from. How plenty you punch an understanding document for custom project? Core Practices for AgileLean Documentation Agile Modeling. It projects include more project specification and understanding of different business analysts to understand. Explaining restrictions or constraints within the requirements document will escape further. FUNCTIONAL and TECHNICAL REQUIREMENTS DOCUMENT. Anyone preparing a technical requirement document should heed what. Most software makers adhere in a formal development process similar leaving the one described. Developers who begin programming a crazy system without saying this document to hand. Functional specification documents project impact through. Documentation in software engineering is that umbrella course that encompasses all written documents and materials dealing with open software product's development and use. Nonfunctional Requirements Scaled Agile Framework. We understand software project, she can also prefer to understanding! The project for understanding of course that already understand the ability to decompose a formal text can dive deep into a route plan which are the. Adopted for large mouth small mistake and proprietary documentation projects. Design Document provides a description of stable system architecture software. Process Documentation Guide read How to Document. Of hostile software Understanding how they project is contribute probably the. The architecture interaction and data structures need explaining as does around database.
  • V-Model and Process Analysis

    V-Model and Process Analysis

    www.pegasusprojekt.de REQUIREMENTS AND CONDITIONS – Booth No. 03 V-MODEL AND PROCESS ANALYSIS Analysis of established processes regarding automated driving In which steps do the established development and safety processes need to be extended to enable the development and safeguarding of automated driving functions? The V-model is a process model originating from software development that has been established for the development of complex safe-critical systems in the avionics and the automotive domain. Requirements Acceptance Tests Vehicle Level Vehicle Level The first step is to specify the For the final approval it is examined requirements for the complete product whether the complete product (which is the vehicle here) from the satisfies the requirements of the perspective of the stakeholders. stakeholders. System Design System Tests The remaining part of the left branch of the V covers the design of the system on multiple levels of abstraction finally resulting in a technical implementation. Subsystem Design Integration Tests The right branch of the V describes the verification and validation of the developed system. For this purpose for each abstraction level test obligations are defined that need to be satisfied for a successful product development. Component Component Design Tests V Model Technical Implementation www.pegasusprojekt.de REQUIREMENTS AND CONDITIONS – Booth No. 03 V-MODEL AND PROCESS ANALYSIS The ISO 26262 is a standard for safeguarding electric and electronic (E/E) systems in passenger cars. Based on the V-model the standard defines a process to ensure the functional safety of such systems before putting them into operation. This process has been and still is successfully applied for vehicles that are exclusively operated by human drivers and for vehicles equipped with advanced driver assistance systems (ADAS).
  • Deliverable D4.1 Initial Requirements for the SP-Devops Concept, Universal Node Capabilities and Proposed Tools

    Deliverable D4.1 Initial Requirements for the SP-Devops Concept, Universal Node Capabilities and Proposed Tools

    Deliverable D4.1 Initial requirements for the SP-DevOps concept, Universal Node capabilities and proposed tools Dissemination level PU Version 1.1 Due date 30.06.2014 Version date 10.02.2015 This project is co-funded by the European Union Document information Editors and Authors: Editors: Wolfgang John and Catalin Meirosu (EAB) Contributing Partners and Authors: ACREO Pontus Sköldström BME Felician Nemeth, Andras Gulyas DTAG Mario Kind EAB Wolfgang John, Catalin Meirosu iMinds Sachin Sharma OTE Ioanna Papafili, George Agapiou POLITO Guido Marchetto, Riccardo Sisto SICS Rebecca Steinert, Per Kreuger, Henrik Abrahamsson TI Antonio Manzalini TUB Nadi Sarrar Project Coordinator Dr. András Császár Ericsson Magyarország Kommunikációs Rendszerek Kft. (ETH) AB KONYVES KALMAN KORUT 11 B EP 1097 BUDAPEST, HUNGARY Fax: +36 (1) 437-7467 Email: [email protected] Project funding 7th Framework Programme FP7-ICT-2013-11 Collaborative project Grant Agreement No. 619609 Legal Disclaimer The information in this document is provided ‘as is’, and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. © 2013 - 2015 Participants of project UNIFY (as specified in the Partner and Author list above, on page ii) ii Deliverable D4.1 10.02.2015