DOCSLIB.ORG

Devops and Other Software Development Practices in a Web Application Implementation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Devops and Other Software Development Practices in a Web Application Implementation Aalto University School of Science Master's Programme in Computer, Communication and Information Sciences Ilkka Malassu DevOps and other software development practices in a web application implementation Master's Thesis Espoo, December 29, 2020 Supervisor: Professor Petri Vuorimaa, Aalto University Advisor: Jani Koski M.Sc. (Tech.) Aalto University School of Science Master's Programme in Computer, Communication and ABSTRACT OF Information Sciences MASTER'S THESIS Author: Ilkka Malassu Title: DevOps and other software development practices in a web application implementation Date: December 29, 2020 Pages: viii + 57 Major: Computer Science Code: SCI3042 Supervisor: Professor Petri Vuorimaa Advisor: Jani Koski M.Sc. (Tech.) DevOps aims to streamline the process of implementing and delivering new soft- ware by merging the traditionally separate functions of software development and operations into a unified model. Continuous practices of DevOps implement pipelines as processes that take software from development to production with as much automation as possible, while maintaining high quality. Choosing the right software development approaches and practices is important in ensuring end user satisfaction, software quality and profitability in a business context. This thesis conducts a case study on a DevOps environment established in the corporate context of the telecommunications company Nokia. This environ- ment is evaluated by observing it's ability to support the continuous development of a web-based application. The goal of this research is to describe how the DevOps environment established within Nokia implements the main functionali- ties of DevOps, compare it with current literature and studies and provide ideas for future discussion and improvements. As a result, the studied DevOps platform successfully supported the continuous development of the web service implemented for the purposes of this thesis. In the future, standardization of pipeline implementations and other configurations could be discussed. A possibility of a migration from using two CI/CD pipeline tools to using only one could also be evaluated. Keywords: DevOps, web, software development Language: English ii Aalto-yliopisto Perustieteiden korkeakoulu DIPLOMITYON¨ Tieto-, tietoliikenne- ja informaatiotekniikan maisteriohjelma TIIVISTELMA¨ Tekij¨a: Ilkka Malassu Ty¨on nimi: DevOps ja muut ohjelmistokehitysk¨ayt¨ann¨ot verkkopalvelun toteutuksessa P¨aiv¨ays: 29. joulukuuta 2020 Sivum¨a¨ar¨a: viii + 57 P¨a¨aaine: Tietotekniikka Koodi: SCI3042 Valvoja: Professori Petri Vuorimaa Ohjaaja: Diplomi-insin¨o¨ori Jani Koski DevOps-mallin tavoitteena on virtaviivaista ohjelmistojen kehitys- ja julkaisupro- sessi. P¨a¨aasiallisesti t¨am¨a toteutetaan sulauttamalla perinteisesti erilliset ohjel- mistojen kehitys- ja yll¨apitovastuut yhten¨aiseksi toiminnoksi. Jatkuvan integraa- tion ja k¨aytt¨o¨onotton periaatteet t¨aht¨a¨av¨at ohjelmistojen viemiseen kehityksest¨a tuotantoon mahdollisimman automaattisesti, samalla taaten korkean laadun. Oikeiden l¨ahestymistapojen ja k¨ayt¨ant¨ojen valitseminen ohjelmistokehityksess¨a on t¨arke¨a¨a loppuk¨aytt¨ajien tyytyv¨aisyyden sek¨a ohjelmistojen laadun ja tuotta- vuuden takaamiseksi. T¨ass¨a diplomity¨oss¨a raportoidaan tapaustutkimus, jonka kohteena oli tietoliikenneyhti¨o Nokian sis¨ainen DevOps-ymp¨arist¨o. T¨am¨a diplo- mity¨o tutkii sen kyky¨a tukea verkkopalveluprojektin jatkuvaa kehityst¨a ja in- tegraatiota. Tutkimuksen tavoitteena on kuvata kuinka ymp¨arist¨oss¨a toteutuu DevOpsin p¨a¨aperiaatteet, verrata sit¨a nykykirjallisuuteen ja tutkimuksiin sek¨a tarjota ideoita tulevaisuuden kehityskohteiksi. Arvioitu DevOps-malli tarjosi onnistuneesti tuen verkkopalvelun kehitysprojektil- le. Jatkuvan integraation, k¨aytt¨o¨onoton ja konfiguraatioiden standardisointi sek¨a siirtyminen kahdesta jatkuvan integraation ty¨okalusta yhteen voidaan arvioida tulevaisuuden kehityskohteina. Asiasanat: DevOps, verkko, ohjelmistokehitys Kieli: Englanti iii Acknowledgements I would like to thank my supervisor Petri Vuorimaa and Nokia for making this thesis possible. Espoo, December 29, 2020 Ilkka Malassu iv Abbreviations and Acronyms CD Continuous Delivery CDP Continuous Delivery Pipeline CI Continuous Integration CM Continuous Monitoring DevOps Development and operations OS Operating system QA Quality assurance REST Representational State Transfer Protocol SCM Source Code Management SDLC Software Development Life Cycle SOA Service-Oriented Architecture TDD Test-Driven Development UAT User Acceptance Test VM Virtual machine WSDL Web Service Description Language v Contents Abbreviations and Acronyms v 1 Introduction 1 1.1 Background and Motivation . .2 1.2 Research questions . .2 1.3 Structure of the Thesis . .2 2 Current literature 4 2.1 Defining DevOps . .4 2.2 An overview of DevOps . .7 2.2.1 Values and goals . .7 2.2.2 Processes . .8 2.3 DevOps software management . .8 2.3.1 Code reviews . .9 2.3.2 Source code management . .9 2.3.3 Build management . .9 2.3.4 Release management . 10 2.3.5 Automation . 10 2.4 Continuous Integration . 10 2.4.1 Unit tests . 11 2.4.2 Pre-checks . 11 2.5 Continuous Delivery . 12 2.5.1 Testing . 12 2.5.2 Coding metrics . 12 2.5.3 Infrastructure-as-Code . 13 2.6 Continuous Deployment . 13 2.6.1 Deployment types . 14 2.7 Studies on continuous practices . 14 2.7.1 Existing literature reviews . 14 2.7.2 Continuous practices: available tools and approaches . 15 2.7.3 Tools for CDP design and implementation . 16 vi 2.7.4 Challenges in migrating to continuous practices . 16 2.8 Adopting DevOps: a case study . 17 2.8.1 Background . 17 2.8.2 Starting the transformation . 18 2.8.3 DevOps adoption methods . 18 2.8.4 Conclusion . 19 2.9 Test-Driven Development . 20 2.9.1 Defining TDD . 20 2.9.2 Studies on TDD . 21 2.10 Web service choreographies with TDD . 23 2.10.1 Choreography development . 23 2.10.2 RESTful Web services and SOAP . 24 2.10.3 Integrating choreographies and TDD . 25 2.11 Microservices and DevOps . 27 2.11.1 Defining microservices . 28 2.11.2 Microservices and DevOps . 28 2.11.3 Migrating to microservices . 28 2.11.4 Challenges with microservices . 30 2.11.5 Related tools . 30 2.12 Chaos engineering . 31 2.12.1 Origins of chaos engineering . 31 2.12.2 Chaos engineering principles . 32 3 Environment 33 3.1 Software management . 33 3.1.1 Source code management . 33 3.1.2 Build and release management . 33 3.2 Software development processes . 34 3.3 The implementation environment . 35 3.4 The web service . 35 4 Methods 37 4.1 Case studies in software engineering . 37 4.2 Case study research methodology . 37 4.2.1 Characteristics . 37 4.2.2 Research process . 38 4.3 The case study of this thesis . 38 4.3.1 Research objectives . 38 4.3.2 Collecting data . 39 vii 5 Implementation 40 5.1 Use cases . 40 5.2 Initial steps . 40 5.3 Build and release management . 41 5.4 Building a CI/CD pipeline . 41 5.4.1 Merge request deployments . 42 5.5 Implementing features . 43 5.5.1 Initial application . 43 5.5.2 First deployment . 43 5.5.3 Incremental improvements . 44 5.5.4 Result pages . 45 6 Evaluation 47 6.1 Build and release configurations . 47 6.2 Writing software code . 47 6.3 CI/CD tools . 48 6.4 Web service implementation . 50 6.5 Summary . 51 7 Conclusion 52 viii Chapter 1 Introduction In a world that is increasingly driven by computer code, the processes and practices of developing software are growing in importance. Decreasing the time it takes to deploy software into production and streamlining the delivery process is essential in an environment where the end users are demanding new features and improvements to their services at an increasing rate. DevOps is a set of practices aimed at merging the responsibilities of soft- ware development and operations teams to decrease the lead times of soft- ware projects. In addition to organizational structuring, DevOps includes all the technological choices that aid in achieving this goal. DevOps and other contemporary software development practices can provide help for problems faced with traditional software delivery processes, which include: inconsis- tency across development and operations environments, risk of failures caused by manual interventions, difficult software configuration and version manage- ment and high costs [1]. This thesis conducts a case study on a DevOps environment implemented in the corporate context of Nokia. The research is done by following the implementation of a web-based service and observing the DevOps platform's ability to support this continuous development process. The observations made during this project are compared with the theoretical framework pro- vided by current studies and literature on DevOps and other software development practices. The goal of the research is to describe how the DevOps envi- ronment established within Nokia implements the main functionalities of DevOps and provide ideas for future discussion and improvements. 1 CHAPTER 1. INTRODUCTION 2 1.1 Background and Motivation DevOps and related software development practices can aid in achieving business goals in the highly competitive domain of IT. This is pursued by breaking down organizational silos and facilitating continuous engagement between the teams of development and operations. Different industries are willing to adopt DevOps due to the advantages it can provide, which leads to a globally increased demand of DevOps professionals. Organisations that have employed these professionals are experiencing better returns compared to businesses that are still utilizing more traditional software development approaches. Continuous Integration and other properties of DevOps have created success stories across different software-related industries, which con- tributes to the increased trendiness of these subjects in the domain of IT. [2] Continuous practices have the goal of accelerating the rate of software deliveries while maintaining a high standard of quality. Evaluating these practices and the related tools is important in identifying challenges and classifying different approaches. [3] 1.2 Research questions This thesis conducts a case study that is centred around the topics of DevOps and CI/CD. The research is guided by two research questions, which are presented below.
Load more

Recommended publications
  • 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............................................
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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).
    [Show full text]
  • 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
    [Show full text]
  • Chapter2: Testing Throughout Lifecycle
    ISTQB Certification Preparation Guide: Chapter 1 – Testing Through Lifecycle Chapter2: Testing throughout Lifecycle "What is clear from the Inquiry Team's investigations is that neither the Computer Aided Dispatch (CAD) system itself, nor its users, were ready for full implementation on 26th October 1992. The CAD software was not complete, not properly tuned, and not fully tested. The resilience of the hardware under a full load had not been tested. The fall back option to the second file server had certainly not been tested." Extract from the main conclusions of the official report into the failure of the London Ambulance Service's Computer Systems on October 26th and 27th 1992. 2.1 OVERVIEW This module covers all of the different testing activities that take place throughout the project lifecycle. We introduce various models for testing, discuss the economics of testing and then describe in detail component, integration, system and acceptance testing. We conclude with a brief look at maintenance testing. After completing this module you will: 2.2 OBJECTIVES Ø Understand the difference between verification and validation testing activities Ø Understand what benefits the V model offers over other models. Ø Be aware of other models in order to compare and contrast. Ø Understand the cost of fixing faults increases as you move the product towards live use. Ø Understand what constitutes a master test plan. Ø Understand the meaning of each testing stage. http://www.softwaretestinggenius.com/ Page 1 of 22 ISTQB Certification Preparation Guide: Chapter 1 – Testing Through Lifecycle 2.3 Models for Testing This section will discuss various models for testing.
    [Show full text]
  • Source Code Security Analysis Tool Functional Specification Version 1.0
    Special Publication 500-268 Source Code Security Analysis Tool Functional Specification Version 1.0 Paul E. Black Michael Kass Michael Koo Software Diagnostics and Conformance Testing Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 May 2007 U.S. Department of Commerce Carlos M. Gutierrez, Secretary Technology Administration Robert Cresanti, Under Secretary of Commerce for Technology National Institute of Standards and Technology William Jeffrey, Director Abstract: Software assurance tools are a fundamental resource for providing an assurance argument for today’s software applications throughout the software development lifecycle. Some tools analyze software requirements, design models, source code, or executable code to help determine if an application is secure. This document specifies the behavior of one class of software assurance tool: the source code security analyzer. Because many software security weaknesses today are introduced at the implementation phase, using a source code security analyzer should help assure that software doesn’t have many security vulnerabilities. This specification defines a minimum capability to help software professionals understand how a tool will meet their software security assurance needs. Keywords: Homeland security; software assurance tools; source code analysis; vulnerability. Errata to this version: None Any commercial product mentioned is for information only. It does not imply recommendation or endorsement by NIST nor does it imply
    [Show full text]
  • What Is a Requirement?
    What is a requirement? • May range from – a high-level abstract statement of a service or – a statement of a system constraint to a Software Requirements detailed mathematical functional specification • Requirements may be used for – a bid for a contract Descriptions and specifications • must be open to interpretation of a system – the basis for the contract itself • must be defined in detail • Both the above statements may be called requirements Example Example …… 4.A.5 The database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name. …… 1 Types of requirements User requirements readers • Written for customers • Client managers – User requirements • Statements in natural language plus diagrams of the • System end-users services the system provides and its operational constraints. • Client engineers • Written as a contract between client and • Contractor managers contractor – System requirements • System architects • A structured document setting out detailed descriptions of the system services. • Written for developers – Software specification • A detailed software description which can serve as a basis for a design or implementation. System requirements readers Software specification readers • System end-users • Client engineers (maybe) • Client engineers • System architects • System architects • Software developers • Software developers 2 Functional requirements • Statements of services the system should provide, how the system We will come back to user should react to particular inputs and system requirements and how the system should behave in particular situations. Examples of functional Functional requirements requirements • Describe functionality or system services 1.
    [Show full text]
  • Requirements Engineering
    Requirements Engineering Week 5 Agenda (Lecture) • Requirement engineering Agenda (Lab) • Create a software requirement and specification document (Lab Assignment #5) for your group project. • Weekly progress report • Submit the ppgrogress report and SRS by the end of the Wednesday lab session. Team Lab Assignment #5 • Create a software requirement and specification document (a.k.a. SRS) for your group project. Refer to the sample at www.csun.edu/~twang/380/Slides/SRS‐Sample.pdf. • Due date – The end of the 2/23 lab session ‐Successful Software Development, Donaldson and Siegel, 2001 5 ‐Successful Software Development, Donaldson and Siegel, 2001 6 That happens! • “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant.” 7 Requirements engineering • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. • The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. What is a requirement? • It may range from a high‐level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. • This is inevitable as requirements may serve a dldual function – May be the basis for a bid for a contract ‐ therefore must be open to interpretation; – May be the basis for the contract itself ‐ therefore must be defined in detail; – Both these statements may be called requirements. Requirements abstraction (Davis) “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined.
    [Show full text]
  • D3.2 Functional Specification
    ADVENTURE WP 3 D3.2 Functional Specification D3.2 Functional Specification Authors: INESC (Lead), UVI, TUDA, UVA, ASC, TIE, ISOFT Delivery Date: Due Date: Dissemination Level: 2012-06-06 2012-04-30 Public This document contains the functional specification of the ADVENTURE platform. It defines the functionalities of the platform and shows, from a user perspective, how its components fit together in order to provide and intuitive and user-friendly interface for the management of the virtual factories. It also shows, from a process perspective, how the components of the platform interact in order to execute, orchestrate, monitor, forecast and adapt the dynamic manufacturing processes of the virtual factories. D32_Functional_Specification_v2.0 Authors: INESC and Partners Date: 2012-06-08 Page: 1 / 240 Copyright © ADVENTURE Project Consortium. All Rights Reserved. ADVENTURE WP 3 D3.2 Functional Specification Document History V0.1, INESC, November 16 th , 2011 V0.2, INESC, March 16 th , 2012 V0.3, INESC, March 18 th , 2012 V0.4, INESC, March 20 th , 2012 V0.5, INESC, March 29 th , 2012 V0.6, INESC, April 1 st , 2012 V0.7, INESC, May 2 nd , 2012 V0.8, INESC, TIE, UVA, TUDA, May 3 rd , 2012 V0.9, INESC, TIE, ISOFT, ASC, TUDA, UVA, May 11th , 2012 V1.0, INESC, TIE, ISOFT, ASC, TUDA, UVA, UVI, May 23 th , 2012 Draft Version V1.1, INESC, TIE, ISOFT, ASC, TUDA, UVA, UVI, May, 24 th , 2012 V1.2, INESC, May, 25 th , 2012 V1.3, INESC, May, 28 th , 2012 V1.4, INESC, May, 29 th , 2012 V1.5, INESC, May, 29 th , 2012 V1.6, INESC, May, 29 th , 2012 V1.7,
    [Show full text]
  • Guide to the Software Requirements Definition Phase
    ESA PSS-05-03 Issue 1 Revision 1 March 1995 Guide to the software requirements definition phase Prepared by: ESA Board for Software Standardisation and Control (BSSC) european space agency / agence spatiale européenne 8-10, rue Mario-Nikis, 75738 PARIS CEDEX, France ii ESA PSS-05-03 Issue 1 Revision 1 (March 1995)) DOCUMENT STATUS SHEET DOCUMENT STATUS SHEET DOCUMENT STATUS SHEET 1. DOCUMENT TITLE: ESA PSS-05-03 Guide to the software requirements definition phase 2. ISSUE 3. REVISION 4. DATE 5. REASON FOR CHANGE 1 0 1991 First issue 1 1 1995 Minor revisions for publication Issue 1 Revision 1 approved, May 1995 Board for Software Standardisation and Control M. Jones and U. Mortensen, co-chairmen Issue 1 approved 1st February 1992 Telematics Supervisory Board Issue 1 approved by: The Inspector General, ESA Published by ESA Publications Division, ESTEC, Noordwijk, The Netherlands. Printed in the Netherlands. ESA Price code: E1 ISSN 0379-4059 Copyright © 1995 by European Space Agency ESA PSS-05-03 Issue 1 Revision 1 (March 1995)) iii TABLE OF CONTENTS TABLE OF CONTENTS CHAPTER 1 INTRODUCTION..................................................................................1 1.1 PURPOSE .................................................................................................................1 1.2 OVERVIEW................................................................................................................1 CHAPTER 2 THE SOFTWARE REQUIREMENTS DEFINITION PHASE ................3 2.1 INTRODUCTION.......................................................................................................3
    [Show full text]