DOCSLIB.ORG

Održavanje Softvera

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Održavanje Softvera ODRŽAVANJE SOFTVERA DEFINICIJA “The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment” • 40-90% of the software life cycle cost Osnovne faze razvoja softvera: Uloga odrzavanja u celom zivotnom ciklusu softvera: TIPOVI ODRZAVANJA: Faze razvoja i elementi održavanja u agilnom razvoju softvera: Grupe aktivnosti u održavanju softvera (izvor: Alain April, Jane Huffman Hayes, Alain Abran, and Reiner Dumke: Software Maintenance Maturity Model (SMmm): The software maintenance process model) (izvor: http://www.klariti.com/technical-writing/2011/08/26/software-maintenance-plan/) There are two sides to Software Maintenance Plans – management and technical. Management issues include aligning with customer priorities, resources, setting up maintenance teams, and costs. Technical issues include impact analysis, testing, maintainability measurement. Software Maintenance includes ten activities: 1. Preparation – Describe software preparation and transition activities including the conception and creation of the maintenance plan; describe how to handle problems identified during development and configuration management. 2. Modification – After the application has become the responsibility of the maintenance team, explain how to analyze each request; confirm and check validity; investigate and propose solutions; document the proposal and get the required authorizations to apply the modifications. 3. Implementation – Describe the process for considering the implementation of the modification itself. 4. Acceptance – Describe how the modification is accepted by the maintenance team. 5. Migration – Describe any migration tasks that need to be executed. If the software needs to be moved to another system, outline the steps to do so without impacting its functionality. 6. Transition – Document the sequence of activities to transition the system from Development to Maintenance. 7. Service Level Agreements – Document SLAs and maintenance contracts negotiated by Maintenance. 8. Change Request – Outline the problem-handling process to prioritize, documents and route change and maintenance requests. 9. Modification Request acceptance/rejection – Describe the request including details of the size/effort/complexity. If this is too complex to resolve, outline the steps to route the issue back to the software team. 10. Retirement – This is the final stage in the lifecycle. Describe how to retire the software and the steps to archive any data that may be a by-product of the system. MODELI ODRZAVANJA SOFTVERA: QUICK – FIX – je zapravo ad-hoc pristup, čekanje da problem nastupi i korekcija Boemov model 1983.godine – zasnovan na ekonomskim principima (cost-benefit analiza zahteva za izmenama, izmene su povezane sa resursima koji su potrebni za realizaciju) OZBORNOV MODEL – zasniva se na mogućnosti da sve nije idealno, tj. da nisu na raspolaganju svi potrebni podaci, dokumentacija i specifikacije, vec se iterativno realizuje odrzavanje, omogucavajuci pojedinim segmentima da budu izmenjeni. Iterativni model unapređenja softvera – iterativni razvoj softvera uz nedovoljno jasne specifikacije koje se novim iteracijama razjasnjavaju I detaljnije opisuju, svaka iteracije radi UPDATE svih dokumenata I svih artefakta (REQUIREMENTS, DESIGN, CODING, TESTING). Reuse-oriented model – u okviru održavanja naglasak je na korišćenju gotovih komponenti, tj. prerađivanje starog dela softvera radi ponovnog korišćenja. SERVICE LEVEL AGREEMENT (SLA) (izvor: https://www.paloaltonetworks.com/cyberpedia/what-is-a-service-level-agreement-sla) A service level agreement (SLA) is a contract between a service provider (either internal or external) and the end user that defines the level of service expected from the service provider. SLAs are output-based in that their purpose is specifically to define what the customer will receive. SLAs do not define how the service itself is provided or delivered. The SLA an Internet Service Provider (ISP) will provide its customers is a basic example of an SLA from an external service provider. The metrics that define levels of service for an ISP should aim to guarantee: A description of the service being provided– maintenance of areas such as network connectivity, domain name servers, dynamic host configuration protocol servers Reliability – when the service is available (percentage uptime) and the limits outages can be expected to stay within Responsiveness – the punctuality of services to be performed in response to requests and scheduled service dates Procedure for reporting problems – who can be contacted, how problems will be reported, procedure for escalation, and what other steps are taken to resolve the problem efficiently Monitoring and reporting service level – who will monitor performance, what data will be collected and how often as well as how much access the customer is given to performance statistics Consequences for not meeting service obligations – may include credit or reimbursement to customers, or enabling the customer to terminate the relationship. Escape clauses or constraints – circumstances under which the level of service promised does not apply. An example could be an exemption from meeting uptime requirements in circumstance that floods, fires or other hazardous situations damage the ISP’s equipment. Though the exact metrics for each SLA vary depending on the service provider, the areas covered are uniform: volume and quality of work (including precision and accuracy), speed, responsiveness, and efficiency. In covering these areas, the document aims to establish a mutual understanding of services, areas prioritized, responsibilities, guarantees, and warranties provided by the service provider. The level of service definitions should be specific and measureable in each area. This allows the quality of service to be benchmarked and, if stipulated by the agreement, rewarded or penalized accordingly. An SLA will commonly use technical definitions that quantify the level of service such as mean time between failures (MTBF) or mean time to recovery, response, or resolution (MTTR), which specifies a “target” (average) or “minimum” value for service level performance. SLAs are also very popular among internal departments in larger organizations. For example, the use of a SLA by an IT helpdesk with other departments (the customer) allows their performance to be defined and benchmarked. The use of SLAs is also common in outsourcing, cloud computing, and other areas where the responsibility of an organization is transferred out to another supplier. REINŽENJERING SOFTVERA (izvor: http://www.cs.toronto.edu/~yijun/ece450h/handouts/lecture2.pdf) UPRAVLJANJE KONFIGURACIJOM SOFTVERA DEFINICIJA (izvor: https://www.techopedia.com/definition/24583/software-configuration-management-scm) Software configuration management (SCM) is a software engineering discipline consisting of standard processes and techniques often used by organizations to manage the changes introduced to its software products. SCM helps in identifying individual elements and configurations, tracking changes, and version selection, control, and baselining. SCM is also known as software control management. SCM aims to control changes introduced to large complex software systems through reliable version selection and version control. SOFTVERSKI ALATI ZA PRAĆENJE VERZIJA SOFTVERA (Version control softver) POSTOJI NEKOLIKO MODELA: Model sa lokalnim podacima - In the local-only approach, all developers must use the same file system. Klijent-server model - In the client-server model, developers use a shared single repository. DISTRIBUIRANI MODEL - each developer works directly with his or her own local repository, and changes are shared between repositories as a separate step. PRIMERI ALATA: Local data model *********************** Open source --------------- Revision Control System (RCS) – stores the latest version and backward deltas for fastest access to the trunk tip[1][2] compared to SCCS and an improved user interface,[3] at the cost of slow branch tip access and missing support for included/excluded deltas. Source Code Control System (SCCS) – part of UNIX; based on interleaved deltas, can construct versions as arbitrary sets of revisions. Extracting an arbitrary version takes essentially the same time and is thus more useful in environments that rely heavily on branching and merging with multiple "current" and identical versions. Client-server model *********************** Open source --------------- Concurrent Versions System (CVS) – originally built on RCS, licensed under the GPL. CVSNT – cross-platform port of CVS that allows case insensitive file names among other changes OpenCVS – CVS clone under the BSD license, with emphasis put on security and source code correctness Subversion (SVN) – versioning control system inspired by CVS[4] Vesta – build system with a versioning file system and support for distributed repositories Proprietary --------------- Filesentral – GUI based version control aimed primarily at the non - programmers demographic AccuRev – source configuration management tool with integrated issue tracking based on "Streams" that efficiently manages parallel and global development; replication server is also available Autodesk Vault – Version control tool specifically designed for Autodesk applications managing the complex relationships between design files such as AutoCAD and Autodesk Inventor. CADES - Designer productivity
Load more

Recommended publications
  • Jenkins Declarative Pipeline Checkout Scm Example
    Jenkins Declarative Pipeline Checkout Scm Example Thor confab improbably. Permissible Augie usually damnify some corolla or name-drops unalike. Nicholas remains scenic: she depressurize her chessels doctors too straight? How they evaluate Git branch name itself a Jenkins pipeline using. 'checkout scm' is a great single line to add maybe your script that checks out the commute the Jenkinsfile is crisp from. Confirmed that were very similar to us to other useful by jenkins declarative pipeline checkout scm example, and seeing that. Jenkins Pipeline Checkout Scm Example abound on Jenkins comjavahometechmywebblobmasterJenkins-Declarative-GitFor OnlineClassroom trainings and. BRANCHNAME JENKINS-4565 Declarative Pipeline Example. Jenkins Stash Example. I've key a jenkins pipeline and bow is pulling the pipeline script from scm. If necessary files in the example pipeline code. Feature Request Parallel Stage name for Declarative. Pipeline Pipeline stage Pipeline Declarative Checkout SCM Pipeline checkout. Jenkins Beginner Tutorial 14 How to setup DELIVERY PIPELINE in Jenkins Step by. In turkey first step 1 we checkout project from GitHub and then build it with Maven 2. How to Use the Jenkins Scripted Pipeline BlazeMeter. In simple words Jenkins Pipeline is a combination of plugins that block the integration and implementation of continuous delivery pipelines using Jenkins A pipeline has an extensible automation server for creating simple less complex delivery pipelines as code via pipeline DSL Domain-specific Language. The Declarative Pipeline example above contains the minimum necessary. That is why science would awake to steam a border more with Jenkins Pipelines to present. How do I of environment variables in Jenkins pipeline? Nodelabel def myRepo checkout scm def gitCommit myRepo.
    [Show full text]
  • PTC Integrity™ Lifecycle Manager™
    PTC Integrity ™ Lifecycle Manager™ The PTC Integrity product family helps organizations accelerate product innovation by reducing complexity, improving collaboration, and automating best practices for software and systems engi- neering. PTC Integrity Lifecycle Manager, a member of the Integrity family, is a flexible, process-based ALM (Application Lifecycle Management) platform that helps teams deliver higher quality, more innovative software with less risk. In today’s world, the demand for smarter, more With seamless, collaborative management of all activi- connected products is increasingly fulfilled through ties and assets, the PTC Integrity Lifecycle Manager software. Software – whether embedded in a product platform helps software engineering teams achieve or providing supporting functionality – is key to driving greater transparency, better productivity and shorter product differentiation and profitability. PTC Integrity cycle times across the entire development lifecycle. Lifecycle Manager provides a global software devel- opment platform that supports all activities and What Makes Integrity Different? assets associated with the engineering and delivery of applications and embedded software. Business All too often, organizations struggle to gain an end- analysts, architects, engineers, developers, quality to-end view of software assets that span multiple managers, testers, partners/suppliers and other tools, with meta-data stored in multiple, disjointed stakeholders all use PTC Integrity Lifecycle Manager repositories. The result is a lack of visibility and as the means for collaboration and control over the traceability across the lifecycle, higher defects and end-to-end development lifecycle. longer development cycles. Our solution provides a unified, global software development platform that supports all activities and assets associated with the engineering and delivery of applications and products.
    [Show full text]
  • How to Select a Suitable Tool for a Software Development Project
    HowtoSelect aSuitable Tool foraSoftwareDevelopment Project: Three Case Studies and the Lessons Learned Mark Kibanov, Dominik J. Erdmann, Martin Atzmueller Knowledge and Data Engineering Group, University of Kassel, Germany {kibanov, erdmann, atzmueller}@cs.uni-kassel.de Abstract: This paper describes aframework for evaluating and selecting suitable soft- ware tools for asoftware project, which is easily extendable depending on needs of the project. Foranevaluation, we applied the presented framework in three different projects. These projects use different software development methods (from classical models to Scrum) in different environments (industry and academia). We discuss our experiences and the lessons learned. 1Introduction With the growth of the software industry the number of software products (programs, tools, frameworks) with similar functions has also increased. Therefore, the process of selection of the required software has also become more complex. In this paper,weintroduce a general three-step framework for selecting suitable software for the current project and environment. Furthermore, we describe the application of the framework to three different software projects: These use different software development methods and environments. All three case studies showpromising results and indicate the possibility to apply the suggested framework for awide range of different projects. In these contexts, we discuss our experiences and the lessons learned. The rest of the paper is structured as follows: Section 2discusses related work. After that, Section 3presents the framework, its advantages, disadvantages and the three distinct steps of selecting the software tools. Section 4describes three case studies where we applied the framework and the results we obtained during these case studies. 2Related Work Starting in 1980 with [Saa80], Thomas L.
    [Show full text]
  • List of New Applications Added in ARL #2603
    List of New Applications Added in ARL #2603 Application Name Publisher DataConnect 11.5 Actian Source Sans Pro 1.0 Adobe PDF Broker Process for Internet Explorer 21.1 Adobe Creative Suite CS6 Standard Adobe Collaboration Synchronizer 20.1 Adobe Collaboration Synchronizer 21.1 Adobe Connect 2020.12 Adobe AD Group Manager 1.1 Albus Bit AD Group Manager 1.2 Albus Bit Query Reporter 3.3 Allround Automations Monarch 13.0 Classic Altair Engineering IMAGEPro 1.1 AMETEK CrystalControl 2.1 AMETEK NekoHTML 1.9 Andy Clark Sherlock 6.2 Ansys Flash Banner Maker 1.0 Anvsoft Any Video Converter 5.5 Anvsoft TomeePlus 9.0 Apache Software Foundation Falcon 0.1 Apache Software Foundation JaxMe 0.5 Apache Software Foundation A-PDF Split A-PDF.com WealthTrack 9.0 Applied Systems Call Status Report 1.0 Aspect Software Inbound 7.3 Aspect Software CLIQ Web Manager 9.2 ASSA ABLOY CLIQ Web Manager 8.0 ASSA ABLOY Centerprise Data Integrator 7.6 Astera Software Bitbucket 2.0 Atlassian Jira Capture Chrome 1.0 Atlassian AudaEnterprise 4.0 Audatex Encode And Decode Files - Base64 1.0 Automation Anywhere Expert PDF 14.0 Avanquest Software ASG Plugin Avaya Discovery Tool 3.3 AvePoint DocAve 6.6 AvePoint DocAve 6.12 AvePoint DocAve 6.11 AvePoint DocAve 6.3 AvePoint DocAve 6.8 AvePoint DocAve 6.9 AvePoint FLY 4.5 AvePoint Wonderware Application Server Client 2020 AVEVA Group Cloud for Business On-Premises 2.0 Axure Software Solutions Automator 4.5 Axway Convene 5.8 Azeus Zulu 8.50 Azul Systems Zulu 11.35 Azul Systems Zulu 8.48 Azul Systems Zulu 15.28 Azul Systems Zulu
    [Show full text]
  • Command Line Interface
    Command Line Interface Squore 21.0.2 Last updated 2021-08-19 Table of Contents Preface. 1 Foreword. 1 Licence. 1 Warranty . 1 Responsabilities . 2 Contacting Vector Informatik GmbH Product Support. 2 Getting the Latest Version of this Manual . 2 1. Introduction . 3 2. Installing Squore Agent . 4 Prerequisites . 4 Download . 4 Upgrade . 4 Uninstall . 5 3. Using Squore Agent . 6 Command Line Structure . 6 Command Line Reference . 6 Squore Agent Options. 6 Project Build Parameters . 7 Exit Codes. 13 4. Managing Credentials . 14 Saving Credentials . 14 Encrypting Credentials . 15 Migrating Old Credentials Format . 16 5. Advanced Configuration . 17 Defining Server Dependencies . 17 Adding config.xml File . 17 Using Java System Properties. 18 Setting up HTTPS . 18 Appendix A: Repository Connectors . 19 ClearCase . 19 CVS . 19 Folder Path . 20 Folder (use GNATHub). 21 Git. 21 Perforce . 23 PTC Integrity . 25 SVN . 26 Synergy. 28 TFS . 30 Zip Upload . 32 Using Multiple Nodes . 32 Appendix B: Data Providers . 34 AntiC . 34 Automotive Coverage Import . 34 Automotive Tag Import. 35 Axivion. 35 BullseyeCoverage Code Coverage Analyzer. 36 CANoe. 36 Cantata . 38 CheckStyle. ..
    [Show full text]
  • Attachment F – Scope of Services
    ATTACHMENT F – SCOPE OF SERVICES DRAFT STATEMENT of WORK Project Name: Software Configuration Management Implementation & Training Project Location: Driver & Motor Vehicle (DMV) - IS Headquarters Salem Oregon Agency’s System Application Agency’s Project Manager (“APM”) Manager (“SAM”) Name: Name: Address: Address: Phone: Phone: Fax: Fax: Email: Email: A. PROJECT DESCRIPTION and OVERVIEW of SERVICES Agency is contracting for services in connection with the following: implementation, configuration and training of the CA Endevor Software Configuration Management products (collectively “Endevor SCM”) as identified in this Statement of Work (“SOW”). The purpose of this Project is to implement, configure and train Agency personnel on the Endevor SCM products to automate the process of changing, deploying, and restoring software applications (“Project”). This Project will introduce a standardized, automated, regulated discipline of managing, tracking, and configuring most aspects of the application development process for ODOT’s Driver and Motor Vehicles Services Division (DMV). The Contractor shall provide the Project services identified in the SOW which include planning, analysis, implementation, configuration, migration, work process changes, testing, training/knowledge transfer and other activities required to ensure mastery of the products prior to closing the Project. The implementation of Endevor SCM will support and integrate the platforms and architectures to support the existing DMV business systems. The thorough training of administration and development staff is essential to ensure a successful pilot and roll out of Endevor SCM. Endevor SCM supports library management for source control and protection; version control to prevent code overlay; branching and merging capabilities; and will simplify recovery to prior versions of the source. Endevor SCM will automate many processes and reduce manual intervention to move, promote and restore source code.
    [Show full text]
  • Efficient Algorithms for Comparing, Storing, and Sharing
    EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY May 2012 Major Subject: Computer Science EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Approved by: Chair of Committee, Tiffani L. Williams Committee Members, Nancy M. Amato Jennifer L. Welch James B. Woolley Head of Department, Hank W. Walker May 2012 Major Subject: Computer Science iii ABSTRACT Efficient Algorithms for Comparing, Storing, and Sharing Large Collections of Evolutionary Trees. (May 2012) Suzanne Jude Matthews, B.S.; M.S., Rensselaer Polytechnic Institute Chair of Advisory Committee: Dr. Tiffani L. Williams Evolutionary relationships between a group of organisms are commonly summarized in a phylogenetic (or evolutionary) tree. The goal of phylogenetic inference is to infer the best tree structure that represents the relationships between a group of organisms, given a set of observations (e.g. molecular sequences). However, popular heuristics for inferring phylogenies output tens to hundreds of thousands of equally weighted candidate trees. Biologists summarize these trees into a single structure called the consensus tree. The central assumption is that the information discarded has less value than the information retained. But, what if this assumption is not true? In this dissertation, we demonstrate the value of retaining and studying tree collections.
    [Show full text]
  • Codice Plastic
    Francisco Monteverde “The Cadillac of the SCMs” - eWeek CEO Codice Software www.plasticscm.com [email protected] @plasticscm @plasticscm www.plasticscm.com © 2014 Codice Software Computers, Mobile Phones, Tablets, Internet Services, Video Games, Consoles, Financial Services, Telecommunications, Automobiles, Transportation, Healthcare, Commerce, Distribution, Industrial Manufacturing… … TODAY SOFTWARE IS ALMOST EVERYWHERE….AND INCREASING © 2014 Codice Software VERSION CONTROL IS AN ESSENTIAL FUNCTION WITHIN SOFTWARE DEVELOPMENT © 2014 Codice Software The Problem with Software Development: Limited Productivity, Low Quality Code 1. Development in serial mode (not parallel) creates many dependencies and continuous broken builds 2. Developers need to be connected to central server to use the Version Control tool Distributed Version Control Systems (DVCS) © 2014 Codice Software Introducing Plastic SCM Branching and Merging is GOOD! The Only Commercial Enterprise Distributed Version Control Systems (DVCS) for Teams of Any Size, Enabling Parallel and Distributed Development that works Integrated with Polarion ALM: Closing the GAP between Requirements & Code © 2014 Codice Software Polarion ALM & Plastic SCM Working Together • Plastic SCM integrates with Polarion using “branch per task” and “task per cset” • Branches can be created listing the assigned and open tasks • Alternatively, individual changesets can be linked to Polarion tasks • Quick access from Plastic SCM GUI to Polarion info © 2014 Codice Software Codice Software Company Background Some Global Customers: Funded 2005 Products Plastic SCM & Semantic Merge Investors Bullnet Capital (VC): Valladolid (Spain) & Silicon Valley HQ’s Office Distribution US/Canda, EU, Israel, South Korea © 2014 Codice Software Codice Software in US Developer’s Press Jeff Cogswell Adrian Bridgwater Eric Caoili Heavy Refactoring In Parallel? Plastic SCM 4.0 solution for Plastic SCM is the Cadillac No Problem.
    [Show full text]
  • Altova Umodel 2012 User & Reference Manual
    User and Reference Manual Altova UModel 2012 User & Reference Manual All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher. Products that are referred to in this document may be either trademarks and/or registered trademarks of the respective owners. The publisher and the author make no claim to these trademarks. While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly or indirectly by this document. Published: 2012 © 2012 Altova GmbH UML®, OMG™, Object Management Group™, and Unified Modeling Language™ are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries. Table of Contents 1 UModel 3 2 Introducing UModel 6 3 What's new in UModel 8 4 UModel tutorial 14 4.1 Starting UModel................................................................................................................. 16 4.2 Use cases ................................................................................................................
    [Show full text]
  • Bluej Teamwork Repository Configuration
    BlueJ Teamwork Repository Configuration Version 2.0 for BlueJ Version 2.5.0 (and 2.2.x) Davin McCall School of Engineering & IT, Deakin University 1 Introduction This document gives a brief description of how you might set up a version control repository for use with BlueJ’s teamwork features. It is intended mainly as a “quick start” guide and not as a complete reference – for that you should refer to the version control software documentation (i.e. the CVS manual or the Subversion manual) – but it does explain some BlueJ-specific concepts (such as how BlueJ supports the notion of student groups or teams). Setting up a repository usually requires a server to which you have “root” or administrator access. This may mean that you need to ask a Systems Administrator to set up the repository for you. Since BlueJ version 2.5.0, both Subversion and CVS are supported version control systems. BlueJ version 2.2.x supports only CVS. BlueJ versions prior to 2.2.0 did not support teamwork features. Chapters 2 and 3 explain how to set up and test a repository using CVS. Chapter 4 then covers the equivalent steps for using Subversion. 2 Setting up a simple single user CVS repository for testing the BlueJ teamwork features 2.1 Setting up the repository server On Unix / Linux / MacOS X: You must have the CVS software installed on the machine you intend to use as a server. There is a good chance that it is already installed, but if not, your vendor or distribution provider will almost certainly provide packages that can be installed.
    [Show full text]
  • Jenkins Job Builder Documentation Release 3.10.0
    Jenkins Job Builder Documentation Release 3.10.0 Jenkins Job Builder Maintainers Aug 23, 2021 Contents 1 README 1 1.1 Developers................................................1 1.2 Writing a patch..............................................2 1.3 Unit Tests.................................................2 1.4 Installing without setup.py........................................2 2 Contents 5 2.1 Quick Start Guide............................................5 2.1.1 Use Case 1: Test a job definition................................5 2.1.2 Use Case 2: Updating Jenkins Jobs...............................5 2.1.3 Use Case 3: Working with JSON job definitions........................6 2.1.4 Use Case 4: Deleting a job...................................6 2.1.5 Use Case 5: Providing plugins info...............................6 2.2 Installation................................................6 2.2.1 Documentation.........................................7 2.2.2 Unit Tests............................................7 2.2.3 Test Coverage..........................................7 2.3 Configuration File............................................7 2.3.1 job_builder section.......................................8 2.3.2 jenkins section.........................................9 2.3.3 hipchat section.........................................9 2.3.4 stash section...........................................9 2.3.5 __future__ section.......................................9 2.4 Running.................................................9 2.4.1 Test Mode...........................................
    [Show full text]
  • FAKULTÄT FÜR INFORMATIK Leveraging Traceability Between Code and Tasks for Code Reviews and Release Management
    FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master’s Thesis in Informatics Leveraging Traceability between Code and Tasks for Code Reviews and Release Management Jan Finis FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master’s Thesis in Informatics Leveraging Traceability between Code and Tasks for Code Reviews and Release Management Einsatz von Nachvollziehbarkeit zwischen Quellcode und Aufgaben für Code Reviews und Freigabemanagement Author: Jan Finis Supervisor: Prof. Bernd Brügge, Ph.D. Advisors: Maximilian Kögel, Nitesh Narayan Submission Date: May 18, 2011 I assure the single-handed composition of this master’s thesis only supported by declared resources. Sydney, May 10th, 2011 Jan Finis Acknowledgments First, I would like to thank my adviser Maximilian Kögel for actively supporting me with my thesis and being reachable for my frequent issues even at unusual times and even after he left the chair. Furthermore, I would like to thank him for his patience, as the surrounding conditions of my thesis, like me having an industrial internship and finishing my thesis abroad, were sometimes quite impedimental. Second, I want to thank my other adviser Nitesh Narayan for helping out after Max- imilian has left the chair. Since he did not advise me from the start, he had more effort working himself into my topic than any usual adviser being in charge of a thesis from the beginning on. Third, I want to thank the National ICT Australia for providing a workspace, Internet, and library access for me while I was finishing my thesis in Sydney. Finally, my thanks go to my supervisor Professor Bernd Brügge, Ph.D.
    [Show full text]