Configuration Management in Software Product Lines
|
|
- Robyn Moore
- 7 years ago
- Views:
Transcription
1 Configuration Management in Software Product Lines Asim Rahman & Rashid Awan Department Of Systems and Software Engineering, School of Engineering, Blekinge Institute of Technology, SE Ronneby, Sweden. Abstract Software Configuration Management (SCM) is now recognized by the Software Engineering world as important aspect of software development especially for large and complex software systems. It has also become a vital part of the most widely used software process improvement frameworks. Software Product Line is a new phenomenon that has gained considerable attention during the last decade as an effective was of reuse within the organization. In this document, we present the overview of SCM activities necessary for software product line organization. [Keywords: Configuration Management, Software Product Lines (SPL)] 1. Introduction Software Configuration Management (SCM) is a disciplined approach used to manage the evolution of large and complex software systems through well defined process and control mechanisms [4] [5]. The importance of SCM has been recognized by many researcher and organizations [3] [6] [7]. The most widely used CM practices come from standards defined by Institute of Electrical and Electronics Engineers (IEEE) [6] The International Organization of Standardization (ISO) [3] and Software Engineering Institute (SEI ) [7]. This report analyzes the configuration management activities required for software product lines, a new reuse approach that has emerged in the last decade; the goal remains the same, decreas ing time and effort. The approach is particularly useful when making large and complex software. Section 1 gives an introduction into the Software Product Lines, brief overview of typical SCM activities and the research questions that the report attempts to answer. In section 2, the importance of CM activities in Product Lines is discussed. Section 3 presents dissimilarities between of CM practices in single products and the software product lines. Section 4 of the report discusses the core CM practices for product line organizations. Section 5 presents a case study of a Philips, an organization that has adopted the product line approach; their experiences with the CM practices are outlined. We present the conclusions of our study in the end. In order to proceed further we must first convey our understanding of a software product line Software Product Line (SPL) As the software sizes and complexity grow, more and more organizations realize that they cannot afford to develop multiple software products one at a time [1] [2] [9]. They are required to add new functionality to existing products as well as introduce newer products at a rapid pace to be able to compete in the market. Achieving component based software reuse assumes (or is intended for) a world-wide market divided into component producer, component consumer and the market place [9, p.1]. However, the shift from world-wide reuse of components to organization-wide reuse has proved this to be over ambitious [9, p.1]. This has given birth to a new philosophy of software reuse known as software product lines. The overall objective of a software product line is to reduce the overall engineering effort by first deriving and later managing the commonalities and variability of the similar systems [8]. The commonalties derived in the products are designed and implemented in such a way that all products can utilize those work products. To further clarify the idea of product line let consider the example of consumer electronics. Televisions (TVs), Video Recorders (VCRs), Set-Top Boxes (STBs), Compact Disks (CDs), Digital Versatile Disk (DVDs) are some of the products. As the technology in hardware improves, the software that runs the hardware becomes more and more complex. Companies in the business such as Philips have adopted the product line approach to cope with the diversity within a TV or VCR [10]. Moreover, the product line approach not only helps deliver products faster, it also facilitates in integrating combinations of these products (TV, VCR etc.) into variety of products by managing the commonalities and variabilities that exist amongst them [10] Overview of SCM activities
2 This section presents an overview of typical SCM activities in software development life cycle. The literature [4][5][6][7] groups SCM activities into four categories: configuration identification, configuration control, status accounting, and configuration audits and review. The configuration identification activities mainly identify the items that are to be controlled; these items are identified, named and their other physical characteristics recorded [6]. Moreover, procedure for defining baselines (and changes to it) for the Configuration Items (CI) are documented. In case of subcontracted software, special identification and labeling schemes may be needed. Configuration control activities define how changes to the CIs are requested, evaluated, approved or disapproved and implemented. It defines the sequence of steps that are to be followed to incorporate a change into a CI [5][6]. The configuration status accounting activities determine things such as what elements are to be tracked for changes to the CI and baselines, the type and frequency of reports, how the information is to be collected, stored, processed and reported etc[6][7]. The configuration audits and review activities (as the name itself suggest) are the audits and reviews to be carried out for the project; their objective, the CI and the persons involved, schedule and process, approval criteria etc are planned[6]. Activities that coordinate changes to interfacing item (hardware or support software) are also identified. In case of sub-contracted software (or third party software e.g. COTS), these activities include incorporation of subcontracted as well as acquired software (CIs) into the developed software. Other SCM activities include agreement and monitoring mechanism to check process compliance, audits and reviews of the subcontracted CIs, pro cedures to verify, validate and merge subcontracted software, security of information and traceability of ownership and the change process of the subcontracted CIs [7]. All the above mentioned activities are planned, scheduled and their sequence of occurrence defined with in the project. Moreover, resources are explicitly allocated to perform these activities. Resources include personnel, tools, techniques, equipment, training etc Research Questions In this report we try to analyze the purpose and benefits of configuration management activities in software product lines. Below we list our research question that we will attempt to answer: 1. Why CM is important in SPL? 2. Delta between CM activities in Product Development and Product Family development? 3. What activities should CM support in product lines? 2. Importance of CM in SPL The goals of configuration management are to eliminate confusion and errors due to different versions of artifacts. Plan it or plan to be overwhelmed by it [11]. Introducing a CM procedure into software development cycle would help in establishing and maintaining integrity of products throughout the whole lifecycle. Configuration management is particularly important during development of the products but also extremely important when handling maintenance of the software [11]. Figure 1 Configuration Management and Software Product Lines [1] In general, developing a product line involves core asset development and product development. Both require ascetic technical and organizational management [1]. These concepts are presented in pictorial form in figure1. Each rotating circle represents one of the essential activities. The three circles are linked together showing that they are linked, iterative and can occur in any order. The core asset and product development can occur in any order depending upon the approach the organization adopts (top down or bottom up). Either new products are built from core assets or core assets are extracted from existing products [1] [14]. The rotating arrows in the figure show that not only the core assets are used to develop products, but also new revisions of existing core assets and new core assets might evolve out of product development. However, more often than not, core asset and product development is coordinated effort [1] [14]. The figure above also shows the multidimensional role of CM in software product lines. As core asset in a software product line represents the most reusable artefacts that constitute a product line; therefore managing their configurations holds immense importance. From
3 these core assets various products are derived comprising of these core assets as well as some product specific assets. The management of these core assets must be coordinate under a single process [1]. One important aspect of the Product Line (as mentioned earlier) is managing variability. So what do we mean by variability that needs to be managed. Variability. Steffen Thiel and Andreas Hein [12] define variability as the difference between single products. Svahnberg [13] describes variability as the ability to change or customize the system. Variable software architecture implies that the changes in the architecture have been anticipated and facilitated with the introduction of variation points. These variation points in fact help in delaying certain design decision. A generic design decision is taken for the moment till a more specific one is made at a later stage. Variability can be introduced at various levels of abstraction [13]. The introduction of variation points in architecture implies that the architecture is evolution supportive (at least that is the aim). By evolution supportive we mean that the future changes in the architecture are anticipated and hence the evolution is gracefully [13]. Hence, proper management of variability required a unified process. Since a product line would normally consist of a number of products, having various versions that are in turn building upon different versions of components. Therefore, a CM process for product line strongly revolves around tools that make this possible. To further increase our understanding of what CM activities should be supported by product line, below we draw dissimilarities between the CM practices of product line in comparison with single systems. 3. Dissimilarities in CM practices: Single Systems vs. Product Lines CM for product lines is more complex than for the single systems. Below we present a brief comparison between the how single product development and product line differ in CM practices. Configuration of system vs. products: Configuration for single systems maintains versions of configuration items that constitute a particular version of the product [1]. On the other hand, a CM for product lines maintains such configuration for each version of every product. CM Process: In single product development, each version of the product may be managed separately. Since products within a product line are built upon shared (core) assets, the product line is usually managed through a unified CM process [1]. Control of Core Assets: Since core assets are written by one team but used by many, controlling the configuration of core assets is extremely important [1]. Tool Support: Only selective tools can be used for product line domain. A configuration management tool should support capture the commonality and variabilities of the products in the product line at different level firstly during the initial phases of the development of product line (scoping, feature pla nning, architectural design, assessment and transformation to component specification) to the actual product instantiation [2]. 4. Configuration Management Activities in Software Product Lines Configuration management process for software product lines should possess certain characteristics to fulfill the requirements of software product line as discussed above. In the following sections, each such capability is briefly described which software product lines CM should support Parallel development Different teams or persons work on the same items for different purposes. This fact requires two functionalities from the CM tool. First, there should not be any conflict between the teams while they are working on the same artifact. Second, the tool must support or facilitate the process of merging [14] [15]. So, the selected tool should have branch and join capabilities to support the above mentioned requirements. Several other branching/merging strategies are present in the literature for example [17]. Support of parallel development should be such that the same item of different products is available for different team members [18] Distributed engineering Organizations working on product line may be located on different development or maintenance site. In addition, those teams may be working on different development environment. Due to those reason, CM should not only support consistency of replication of configuration items but also should support heterogeneous development environments with import/export features [14] [15]. Support for distributed should be such that the integrity of the multiple libraries of the same configuration item is in control even when teams are not located on same place [18] Build and release management
4 Build and release manageme nt is important in software product line context. Build management is referred to creation of a version of product, for the purpose of integration or testing. Release management is referred to build final customer solution. For product lines, release management is often referred to release of core assets for product developers [14]. CM tool must support both build and release management when dealing with product lines Change Management During development, a change request may come from product development teams and core asset development teams. Company must define a defined change management mechanism to propose and analyze all the requested changes. An authorize group should also be assigned, often called Configuration Control Board (CCB) [15][16], to analyze and approve the proposed changes. The impact of changes in core assets on the whole product line should be analyzed Configuration and workspace management Individual information about each artifact should also be managed regardless the tool that are used supports it or not [14]. Configuration and workspace management information is all about what configuration is including testing and support environment and how users can create their own workspaces while using a configuration Configuration Status Accounting All essential and important information should be distributed to the involved staff through an efficient configuration status accounting system [17]. CSA solutions have to include World Wide Web publishing to offer reporting mechanisms to teams on multiple sites. To accomplish this, solution has to overcome the problem that may occur due to company s firewall [17] Configuration Audits Due to numerous numbers of artifacts from core assets and product development, regular and planned configuration audits and reviews should be organized to analyze configuration items. Perform configuration audits to maintain the integrity of the configuration baseline [18]. One thing which is more important in product line and distributed parallel development is to make sure whether all the CIs are present and available in the baselines [17]. A wrong baseline has an effect of a greater magnitude in PLs as more than one products will be affected. Absence of any single CI may lead to misleading results in the coming future which may affect related documents in both care asset and product development Process Management A defined and mature process of configuration management for the whole product life cycle in product lines development is essential. The processes about how to define configuration items and baselines including authorization policies for change management. This process should also be maintainable and must be continuously improved as product line development matures [14]. Typical processes are Life Cycle Management Each configuration item is carefully handled and life cycle for each configuration item is defined. Changes in any item must be analyzed, authorized, planned, implemented, documented, reviewed, tracked and communicated. In addition, following information should also be included. list of possible actions (which will be occurred when dealing with an individual item) change authorization policies closure rules (defined when an item will close) Role and Responsibilities Roles and responsibilities of each person participating in configuration management should be explicitly defined. Typical roles may be a list of persons who can issue a change, the person who will be responsible of auditing or taking backups etc Configuration Item Identification and Attributes A global nomenclature should be used to assign unique names. The names of same configuration item should be different for core assets components and product-specific components [14]. Attributes can also be assigned along with unique names due to various reasons. A typical example of an attribute may be has a proxy. CM system must support assigning these kinds of attributes Repository Management CM system should support the storage of configuration management with version management and branching. In addition, it should support an extensive of retrieving relevant information from that repository [14]. 5. Considerations while implementing CM activities for Software Product Lines Some important considerations should be kept in mind while introducing or using configuration management activities for software product lines [4]. All ongoing and opened change requests should be regularly checked along with their status. Change management process should be described in CM plan specially the information about when
5 changes are finished i.e. closed when dealing with distributed development. A generic CM plan should be prepared when relocated projects have their own CM plan. That generic CM plan can be referred for example at the time of release or merging components built on different locations. It is better to have a single central database for same kinds of change requests rather than to have separate databases and also project leaders should not have separate lists except database. 6. Practice Risks Several risks are involved if proper configuration management practices are not introduced right from the beginning of the product line development. Configuration management requires adequate control over unmanageable and numerous of a big number of artifacts, comes from core assets and product specific resources. Here are some practice risks which were mentioned by SEI [1] Process not sufficiently robust Due to the complexity of CM for product line as compared to single systems, while planning configuration management, extra considerations should be given and a robust CM process should be defined [1]. Without introduction a robust process, CM will fail and product line approach will become less efficient CM occurs too late CM practices should be introduced well before launching the first product from product lines otherwise building new versions of the product or rebuilding shipped versions will be very time consuming and expensive which is totally against the idea of software product lines [1] Multiple core asset evolution paths Core assets may evolve to different directions what was not planned before. It may happen due to two reasons, either due to enabling design of core asset for supporting different environments or by accident when core asset evolves within a specific product [1]. Both cases should not be avoided which may results in increasing the complexity of CM process Tool support not sufficiently robust Due to high importance and complexity of CM practices within product line, it would be relatively hard to handle this with out proper tool support. Even though several tool vendors declare that it is supported in their tool but a specific person should be assigned to evaluate those tools [1]. This evaluation requires good understanding of evaluator in both subjects i.e. product line and configuration management. 7. Case Study: Philips In this section, we present the configuration management approach used to realize a consumer electronics product population at Philips presented in [10]. Although a Product Population differs from a software product line, the CM process, tools and techniques used are the same. Product Population: Similar to a product line/family, a product population contains a set of products with many similarities. However, unlike product family, the products also have significant differences Architecture Philips has adopted a composition approach where they create products by plugging various combinations of components together. The product population is build upon reusable components based on the Koala Component Model. Each Koala component have required and provided interfaces through which it interacts with external environment. Products can be created by following steps: 1. Selecting a set of appropriate packages. Packages comprise of components and interface definitions 2. Instantiating the relevant components 3. Binding all type of interfaces 7.2. CM Aspects Philips addressed five issues in the configuration management domain Version Management of Files and Packages A conventional version management system is used to maintain the version history of the software assets (e.g. C headers and source files etc.) related with a package. The package team is responsible for formal releases for the package. Each version is assigned an identification number, consisting of a major number, a minor number and a patch letter e.g. 1.1b. The patch number identifies a bug fix where as the major and minor numbers indicate regular releases. Before releasing a package, all components are compiled, build and checked for errors. Only formal releases are available to the customers who maintain their own local configuration of the package. These packages are available to the customers through internet. Each release of the package is checked for backward compatibility Temporary Variation for Bug Fixes and feature enhancements
6 Philips recognized two kind of temporary variation: small and large. Small temporary variation, arises when one developer ties to fix a bug where as the other is adding feature to a component. In this scenario, they have developer specific branches in CM system which ensures that the changes one developer makes are not visible to other until the time of integration. Temporary variation at large arises before the release of package (product). As the package is utilized by many products, a branch in the package version is created before the release. All bug fixes are tagged to this release and no additional feature can be added here. Such kind of branches may live for a number of weeks but are finally closed when it becomes stable. All products are derived from the main branches of the packages Permanent Variation For permanent variation, Philips relies on the component technology. The reasons behind that are: first they are able to handle variation at architecture level rather than at CM level; second, it allows them to make later decision with the added advantage of flexibility; and third, it allows to exercise diversity outside the CM tool [10]. It is important to explain what they mean by diversity. Koala components contain diversity interfaces that contain a set of parameters that can be used to configure a component. The Koala component model believes in heavily parameterization of the interfaces in order to make the component more reusable. This parameter can be provided in forms of expressions that are later, evaluated and translated by the Koala compiler into compile time diversity (#ifdefs statements in C) Build Support separated from CM Philips maintains a build environment separate from the CM system for three reasons. First, the organization cannot agree upon one standard CM tool to be used by all the teams. Secondly, they focus on buying the best solution for the problems each team may have. Resorting to their own build system that utilizes Koala compiler, various C compilers and a makefile, it allows each team to choose the solution that suits them the best. The third argument (although not very compelling) is that they would like to compile and link products in dependent of the CM system, at any place and at anytime. It allows them to play with the code anywhere Distributed Development Many commercial CM tools provide support to distribute the CM databases anywhere in the world. Philips are not with the idea for the following reasons: Firstly, this will ensure a standard CM tool to be used for the whole organization. Secondly, they want their software to remain independent of any CM tool. Lastly, they want to their packages to remain vendor independent and therefore adopt a small company s approach for the development of their packages. 8. Discussion In the Philips case study, we have observed that Philips does not follow some of the CM activities specific for the Product Line organization. In this section, we try to find out the possible reasons behind it. The main surprise is that Philips does not use any standardize tool for managing CM related activities; the reason being that they want to give the teams a certain amount of independence to choose the tool that best suits their needs. SEI on the other hand proposes that a company should have a standardized CM tool [1]. Philips product line use component based upon the Koala component model. Component configuration is controlled through the mechanism provided by the Koala component model. This means that a major functionality of a CM tool is not utilized. Moreover, Philips does not use the build environment of the CM tool a well. The reason behind this is the same; limitations of the component technology used. Hence, looking at the Philips case study we can conclude that although tool support should be imperative for CM process in PLs, conventional methods are preferred due to limitations of the underlying technology that the PL builds upon. We also infer from the case study that commercial tool support for PLs might not be available and organizations are left with no other choice than to use conventional CM techniques. 9. Conclusions Managing the configuration of the components that constitute a product line is extremely important. The aim is to eliminate confusion and errors that may arise due to different versions of artifacts. We presented a case study of Philips, an organization who has adopted the product line approach. We discussed various CM activities in practice. We found that they have developed their CM process independent of any CM tool. The main reason behind their decision was that different development teams had varying requirements, which are hard to find in one tool. Secondly, even if one tool supported all the activities, it would be infeasible for the organization to buy it and later use it, for economic as well as functional reasons. In the report, we concluded answers of research questions that were raised at the start of the report. Importance of CM in SPL is related to different factors. Two important aspects which increase the importance of CM in product lines were found. Firstly, product line comprises of care asset development and
7 product development. Secondly, the concept of variability and commonalities make things complex. There are major differences in the CM process between single product and product family development. When talking about CM for single product, it means we have to maintain versions of configuration items while in the case of product family, CM maintains configuration for each version of the product in the product family. CM process can be carried out differently for each version of product while a unified process is required for all versions when dealing with product family. In product line, core assets are written by different persons while used by others so configuration of core assets is extremely important. Selecting a tool when dealing with product family requires different consideration for example tool must support variability and commonalities in the case of product line. There are certain CM activities which must be carried out when dealing with software product lines. It is realized that most of the CM activities are to some extent similar to normal product development. But SCM activities require more attention when dealing with software product line due to the inclusion of core asset development, product development and COTS concepts. In addition, it may lead to unrecoverable situations if not carefully handled from the start. The CM Activities for a product line should facilitate parallel development, heterogeneous development environment, build and release management, an institutionalized change management process, along with reporting and audits to ensure better control. References [1] Paul Clements and Linda Northrop, Software Product Lines Practices and Patterns, Addison-Wesley, [2]Jan Bosch, Design and Use of Software Architectures, Addison-Wesley, [3] The TickIT Guide: TickIT Executive Overview, Issure 5.0, Jan [4] Reidar Conradi and Bernhard Westfechtel, Version Models for Software Configuration Management, ACM Computing Surveys (CSUR), Vol. 30 Issue 2, June [5] Hong Mei, Lu Zhang, Fuqing Yang, A Software Configuration Management Model for Supporting Component-Based Software Development, ACM SIGSOFT Software Engineering Notes, Vol. 26, Issue 2, March Plans.MasterToC.html [8] C. W. Krueger, Software Product Line Reuse in Practice, Proceeding of the 3 rd IEEE Symposium of Application-Specific Systems and Software Engineering Technology (ASSET 00) [9] Jan Bosch, Software Product Lines: Organizational Alternatives, University of Groningen, [10] Rob van Ommering, Configuration Management in Component Based Product Populations, [11] Jelte Johnson, Presentation on CM and Risk Management, Idenet (pad008), [12] Steffen Thiel and Andreas Hein, Systematic Integration of Variability into Product Line Architecture Design, SPLC2. LNCS 2379, pp , [13] Mikael Svahnberg, Supporting Software Architecture Evolution-Architecture Selection and Variability, PhD. Thesis at Blekinge Institute of Technology [14] A framework for Software Product Line Practice version 4.2, May [15] Experiences: Distributed Development and Software Configuration Management, Ulf Asklund, Boris Magnusson, and Annita Persson, 9 th International Symposiium, SCM-9 Toulouse, France, September 1999 Proceedings. [16] CMMI [17] A Branching/Merging Strategy for Parallel Software Development, Jim Buffenbarger and Kirk Gruell, 9 th International Symposiium, SCM-9 Toulouse, France, September 1999 Proceedings. [18] Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice, Lawrence G. Jones and Albert L. Soule, July 2002 Product Line Practice Initiative [6] IEEE standard board, IEEE Standard for Software Configuration Management Plans, [7] Nadine M. Bounds, Susan Dart, CM Plans: The Beginning to your CM Solution, 1995.
Configuration Management
83 Chapter 6 Configuration Management Published as: Configuration Management in Component Based Product Populations, Rob van Ommering, 10th International Workshop on Software Configuration Management,
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2007 Vol. 6, No. 1, January-February 2007 CM Configuration Change Management John D.
More informationCONFIGURATION MANAGEMENT PLAN GUIDELINES
I-680 SMART CARPOOL LANE PROJECT SYSTEM ENGINEERING MANAGEMENT PLAN CONFIGURATION MANAGEMENT PLAN GUIDELINE SECTIONS: PLAN GUIDELINES 1. GENERAL 2. ROLES AND RESPONSIBILITIES 3. CONFIGURATION MANAGEMENT
More informationSoftware Configuration. Management Issues in Product Development
Software Configuration Management Issues in Product Development A Annie Ibrahim, Muhammad Waseem (National University of Computer and Emerging Sciences, Lahore) Abstract After more than 20 years of research
More informationCHAPTER 7 Software Configuration Management
CHAPTER 7 Software Configuration Management ACRONYMS CCB CM FCA MTBF PCA SCCB SCI SCM SCMP SCR SCSA SEI/CMMI SQA SRS USNRC INTRODUCTION Configuration Control Board Configuration Management Functional Configuration
More informationA Configuration Management Model for Software Product Line
A Configuration Management Model for Software Product Line Liguo Yu 1 and Srini Ramaswamy 2 1 Computer Science and Informatics Indiana University South Bend South Bend, IN 46634, USA ligyu@iusb.edu 2 Computer
More informationManaging Variability in Software Architectures 1 Felix Bachmann*
Managing Variability in Software Architectures Felix Bachmann* Carnegie Bosch Institute Carnegie Mellon University Pittsburgh, Pa 523, USA fb@sei.cmu.edu Len Bass Software Engineering Institute Carnegie
More informationDifferent Approaches used in Software Product Families
Different Approaches used in Software Product Families Rafia Inam Mälardalens University. Rafia.inam@mdh.se Abstract The use of software in consumer products is growing tremendously in current era. Further
More informationSoftware Configuration Management. Wingsze Seaman COMP250SA February 27, 2008
Software Configuration Management Wingsze Seaman COMP250SA February 27, 2008 Outline CM and SCM Definitions SCM History CMMI and SCM SCM Tools SCM/Dynamic Systems SCM/Software Architecture Resources 2
More informationCertified Professional in Configuration Management Glossary of Terms
Certified Professional in Configuration Management Glossary of terms used in Configuration Management Issue 2007.07 Association of the International Certified Configuration Manager e.v. Copyright 2007,
More informationThe Configuration Management process area involves the following:
CONFIGURATION MANAGEMENT A Support Process Area at Maturity Level 2 Purpose The purpose of is to establish and maintain the integrity of work products using configuration identification, configuration
More informationYour Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.
INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing
More informationCMS Policy for Configuration Management
Chief Information Officer Centers for Medicare & Medicaid Services CMS Policy for Configuration April 2012 Document Number: CMS-CIO-POL-MGT01-01 TABLE OF CONTENTS 1. PURPOSE...1 2. BACKGROUND...1 3. CONFIGURATION
More informationReuse and Capitalization of Software Components in the GSN Project
Experiences with certification of reusable components in the GSN project in Ericsson, Norway Parastoo Mohagheghi (Ph.D. Student, NTNU) Reidar Conradi Ericsson AS, Grimstad, Dept. Computer and Information
More informationKeywords: - Software Product Lines (SPLs), Product Line Engineering (PLE), Core Assets, Software Product Line Development.
Volume 4, Issue 1, January 2014 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Systematic Review
More informationAgile SPL-SCM: Agile Software Product Line Configuration and Release Management
Agile SPL-SCM: Agile Software Product Line Configuration and Release Management APLE 2006 Workshop SPLC 2006, Baltimore, MD Reto.Kurmann@phonak.com Phonak Hearing Systems Presentation Roadmap 1. Introduction
More informationReaching CMM Levels 2 and 3 with the Rational Unified Process
Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP174 Table of Contents INTRODUCTION... 1 LEVEL-2, REPEATABLE... 3 Requirements Management... 3 Software Project
More informationConfiguration & Build Management
Object-Oriented Software Engineering Using UML, Patterns, and Java Configuration & Build Management Outline of the Lecture Purpose of Software Configuration Management (SCM) Some Terminology Software Configuration
More informationAn Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications
An Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications Germán Harvey Alférez Salinas Department of Computer Information Systems, Mission College,
More informationA Framework for Software Product Line Engineering
Günter Böckle Klaus Pohl Frank van der Linden 2 A Framework for Software Product Line Engineering In this chapter you will learn: o The principles of software product line subsumed by our software product
More informationWhat Are Software Developers Facing?
Configuration Management Tuotteenhallinta ohjelmistoprojektissa 1. Objectives 2. Problems & Motivation 3. CM Concept 4. Making CM system to work 5. Present CM Standards and Terms 6. CM Benefits and Summary
More informationSoftware Configuration Management (SCM)
Software Configuration Management (SCM) SCM actually consists of several separate yet cumulative disciplines. Version Management is an entry point for SCM T M Abstract : Software Configuration Management
More informationSoftware Configuration Management Plan
For Database Applications Document ID: Version: 2.0c Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 22 Copyright 2000-2005 Digital Publications LLC.
More informationPage 1. Outline of the Lecture. What is Software Configuration Management? Why Software Configuration Management?
Books: Software Configuration Management 1. B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering: Using UML, Patterns, and Java (Chapter 13) Outline of the Lecture Purpose of Software Configuration
More informationSoftware Configuration Management
Software Engineering Courses (University of Kansas, Spring 2004) Slide 1 Software Configuration Management Software Configuration: All items that constitute the software while under the development (e.g.,
More informationWhat Is Software Configuration Management?
C H A P T E R 1 What Is Software Configuration Management? The title of this chapter asks such a simple question, the answer to which, one would think, ought to be known by anyone with any kind of record
More information15 Jahre Software-Produktlinien: Einführung und aktueller Stand
Software Systems Engineering 15 Jahre Software-Produktlinien: Einführung und aktueller Stand Mini-Tutorial Dr. Andreas Birk (Software.Process.Management), Prof. Dr. Klaus Schmid (Universität Hildesheim)
More informationSoftware Process Improvement Framework for Software Outsourcing Based On CMMI Master of Science Thesis in Software Engineering and Management
Software Process Improvement Framework for Software Outsourcing Based On CMMI Master of Science Thesis in Software Engineering and Management ZAHOOR UL ISLAM XIANZHONG ZHOU University of Gothenburg Chalmers
More informationThe role of integrated requirements management in software delivery.
Software development White paper October 2007 The role of integrated requirements Jim Heumann, requirements evangelist, IBM Rational 2 Contents 2 Introduction 2 What is integrated requirements management?
More informationConfiguration Management
Configuration Management Co Al Florence This presenter s affiliation with the MITRE Corporation is provided for identification purposes only and is not intended to convey or imply MITRE s concurrence with
More informationThe purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements.
CAPACITY AND AVAILABILITY MANAGEMENT A Project Management Process Area at Maturity Level 3 Purpose The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision
More informationSOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK
Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost
More informationConfiguration Management
Chapter 9 Configuration Management CONTENTS 9.1 INTRODUCTION...3 9.1.1 ROLE OF CHANGE...3 9.1.2 CONFIGURATION MANAGEMENT (CM)...3 9.2 PROCESS DESCRIPTION...4 9.2.1 FUNCTIONS OF CONFIGURATION MANAGEMENT...4
More informationManaging Software Product Line
* F 2 - Rules for Qualification of Developing and Managing Software Product Line F. Ahmed Electrical & Computer Engineering University of Western Ontario London Ontario, Canada, N5A5B9 sgraha5@uwo.ca L.F.
More informationConfiguration Management in Software Development Life Cycle
13 Configuration Management in Software Development Life Cycle Tejinder Kaur Sanjay Bhatnagar Deepali StudentComputer Application Associate Prof. Computer Assistant Prof. Computer Department, GZS PTU Applications
More informationElite: A New Component-Based Software Development Model
Elite: A New Component-Based Software Development Model Lata Nautiyal Umesh Kumar Tiwari Sushil Chandra Dimri Shivani Bahuguna Assistant Professor- Assistant Professor- Professor- Assistant Professor-
More informationComparing Practices for Reuse in Integration-oriented Software Product Lines and Large Open Source Software Projects
Comparing Practices for Reuse in Integration-oriented Software Product Lines and Large Open Source Software Projects Jilles van Gurp, Christian Prehofer, Nokia [jilles.vangurp christian.prehofer]@nokia.com
More information5 FAH-5 H-510 CONFIGURATION MANAGEMENT
5 FAH-5 H-500 CONFIGURATION MANAGEMENT 5 FAH-5 H-510 PROJECT DEVELOPMENT AND CHANGE CONTROL (CT:ITS-4; 06-21-2012) (Office of Origin: IRM/BMP/GRP/GP) (Updated only to revise Office of Origin) 5 FAH-5 H-511
More informationMKS Integrity & CMMI. July, 2007
& CMMI July, 2007 Why the drive for CMMI? Missed commitments Spiralling costs Late delivery to the market Last minute crunches Inadequate management visibility Too many surprises Quality problems Customer
More informationTheme 1 Software Processes. Software Configuration Management
Theme 1 Software Processes Software Configuration Management 1 Roadmap Software Configuration Management Software configuration management goals SCM Activities Configuration Management Plans Configuration
More informationProduct Line Development - Seite 8/42 Strategy
Controlling Software Product Line Evolution An infrastructure on top of configuration management Michalis Anastasopoulos michalis.anastasopoulos@iese.fraunhofer.de Outline Foundations Problem Statement
More informationFamily Evaluation Framework overview & introduction
A Family Evaluation Framework overview & introduction P B Frank van der Linden O Partner: Philips Medical Systems Veenpluis 4-6 5684 PC Best, the Netherlands Date: 29 August, 2005 Number: PH-0503-01 Version:
More informationOrganizing for Software Product Lines
Organizing for Software Product Lines Jan Bosch University of Karlskrona/Ronneby Department of Software Engineering and Computer Science SoftCenter, S-372 25, Ronneby, Sweden Jan.Bosch@ipd.hk-r.se Abstract
More informationIntroduction to Software Configuration Management. CprE 556 Electrical and Computer Engineering Department Iowa State University
Introduction to Software Configuration Management CprE 556 Electrical and Computer Engineering Department Iowa State University 1 Example Initially, implementation is in Modula-2 on a Mac. A11 B11 A12
More informationUsing Rational Software Solutions to Achieve CMMI Level 2
Copyright Rational Software 2003 http://www.therationaledge.com/content/jan_03/f_cmmi_rr.jsp Using Rational Software Solutions to Achieve CMMI Level 2 by Rolf W. Reitzig Founder, Cognence, Inc. Over the
More informationMaturity and Evolution in Software Product Lines: Approaches, Artefacts and Organization
Maturity and Evolution in Software Product Lines: Approaches, Artefacts and Organization Jan Bosch University of Groningen Department of Computing Science PO Box 800, 9700 AV, Groningen The Netherlands
More informationSoftware Configuration Management. Addendum zu Kapitel 13
Software Configuration Management Addendum zu Kapitel 13 Outline Purpose of Software Configuration Management (SCM) Motivation: Why software configuration management? Definition: What is software configuration
More informationSTSG Methodologies and Support Structure
STSG Methodologies and Support Structure STSG Application Life Cycle Management STSG utilizes comprehensive lifecycle tools that are fully integrated and provide capabilities for most of the roles in its
More informationSoftware Process Improvement Software Business. Casper Lassenius
Software Process Improvement Software Business Casper Lassenius Topics covered ² The process process ² Process measurement ² Process analysis ² Process change ² The CMMI process framework 2 Process ² Many
More informationSuccessfully managing geographically distributed development
IBM Rational SCM solutions for distributed development August 2004 Successfully managing geographically distributed development Karen Wade SCM Product Marketing Manager IBM Software Group Page 2 Contents
More informationSelect the right configuration management database to establish a platform for effective service management.
Service management solutions Buyer s guide: purchasing criteria Select the right configuration management database to establish a platform for effective service management. All business activities rely
More informationSOPLE-DE: An Approach to Design Service-Oriented Product Line Architectures
SOPLE-DE: An Approach to Design -Oriented Product Line Architectures Flávio M. Medeiros, Eduardo S. de Almeida 2, and Silvio R.L. Meira Federal University of Pernambuco (UFPE) 2 Federal University of Bahia
More informationSoftware Configuration Management. Visiting Lecture Tero Kojo
Software Configuration Management Visiting Lecture Tero 1 About the lecturer Lectured Software Configuration Management for three years at TKK T-76.614 SCM Also a year as the course assistant Practical
More informationHow Rational Configuration and Change Management Products Support the Software Engineering Institute's Software Capability Maturity Model
How Rational Configuration and Change Management Products Support the Software Engineering Institute's Software Capability Maturity Model by Bill Cottrell and John Viehweg Software Engineering Specialists
More informationArchitecture of a Software Configuration Management System for Globally Distributed Software Development Teams
Architecture of a Software Configuration Management System for Globally Distributed Software Development Teams Muhammad Wasim Bhatti Engineering Management Department CASE, Center for Advanced Studies
More informationProduct Derivation Process and Agile Approaches: Exploring the Integration Potential
Product Derivation Process and Agile Approaches: Exploring the Integration Potential Padraig O Leary, Muhammad Ali Babar, Steffen Thiel, Ita Richardson Lero, the Irish Software Engineering Research Centre,
More informationConfiguration Management Practices
Safety Critical Software Management Practices Linda Westfall Westfall Team, Inc. International Conference on Software Quality ICSQ 2011 Copyright 1999-2010 Westfall Team, Inc. All Rights Reserved. Management
More informationRun-time Variability Issues in Software Product Lines
Run-time Variability Issues in Software Product Lines Alexandre Bragança 1 and Ricardo J. Machado 2 1 Dep. I&D, I2S Informática Sistemas e Serviços SA, Porto, Portugal, alexandre.braganca@i2s.pt 2 Dep.
More informationSoftware Engineering. Introduction. Software Costs. Software is Expensive [Boehm] ... Columbus set sail for India. He ended up in the Bahamas...
Software Engineering Introduction... Columbus set sail for India. He ended up in the Bahamas... The economies of ALL developed nations are dependent on software More and more systems are software controlled
More informationConfiguration Management Models in Commercial Environments
Technical Report CMU/SEI-91-TR-7 ESD-9-TR-7 Configuration Management Models in Commercial Environments Peter H. Feiler March 1991 Technical Report CMU/SEI-91-TR-7 ESD-91-TR-7 March 1991 Configuration Management
More informationSoftware Architecture
Cairo University Faculty of Computers and Information Computer Science Department Premasters Studies Software Architecture Report on Software Product Line Submitted to: Dr. Hany Ammar Submitted by: Hadeel
More informationA Variability Viewpoint for Enterprise Software Systems
2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture A Variability Viewpoint for Enterprise Software Systems Matthias Galster University of Groningen,
More informationImproving Decision Making in Software Product Lines Product Plan Management
Improving Decision Making in Software Product Lines Product Plan Management Pablo Trinidad, David Benavides, and Antonio Ruiz-Cortés Dpto. de Lenguajes y Sistemas Informáticos University of Seville Av.
More information19 Configuration Management
TIMe TIMe Electronic Textbook 19 Configuration Management Introduction.......................................................2 What...................................................................2 Why
More informationHow To Achieve Continuous Delivery
White Paper Overcoming Jenkins Sprawl: Going from CI to CD with ElectricFlow Software is everywhere. And accelerating the delivery and quality of that software can mean the difference between merely surviving,
More informationConfiguration Management Patterns
Configuration Management Patterns Steve Berczuk Optimax Systems Corporation 201 Broadway Cambridge MA 02139 berczuk@optimax.com Configuration management is an important aspect of an efficient development
More informationA Return on Investment Model for Software Configuration Management
Master s Thesis A Return on Investment Model for Software Configuration Management Lorenzo Borraci Erasmus Department of Computer Science Lund Institute of Technology Lund University, 2005 ISSN 1650-2884
More informationCHAPTER 7 SOFTWARE CONFIGURATION MANAGEMENT
CHAPTER 7 SOFTWARE CONFIGURATION MANAGEMENT John A. Scott and David Nisse Lawrence Livermore National Laboratory 7000 East Avenue P.O. Box 808, L-632 Livermore, CA 94550, USA (925) 423-7655 scott7@llnl.gov
More information2. Encourage the private sector to develop ITIL-related services and products (training, consultancy and tools).
ITIL Primer [ITIL understanding and implementing - A guide] ITIL - The Framework ITIL is the IT Infrastructure Library, a set of publications providing descriptive (i.e., what to do, for what purpose and
More informationTEST MANAGEMENT SOLUTION Buyer s Guide WHITEPAPER. Real-Time Test Management
TEST MANAGEMENT SOLUTION Buyer s Guide WHITEPAPER Real-Time Test Management How to Select the Best Test Management Vendor? The implementation of a Test Management system to automate business processes
More informationChapter 13 Configuration Management
Chapter 13 Configuration Management Using UML, Patterns, and Java Object-Oriented Software Engineering Outline of the Lecture Purpose of Software Configuration Management (SCM)! Motivation: Why software
More informationA Methodological Approach to Domain Engineering for Software Variability Enhancement
A Methodological Approach to Domain Engineering for Software Variability Enhancement Alexandre Bragança 1,2 and Ricardo J. Machado 3 1 Dep. I&D, I2S Informática Sistemas e Serviços SA, Porto, Portugal,
More informationTowards Software Configuration Management for Test-Driven Development
Towards Software Configuration Management for Test-Driven Development Tammo Freese OFFIS, Escherweg 2, 26121 Oldenburg, Germany tammo.freese@offis.de Abstract. Test-Driven Development is a technique where
More informationApplying 4+1 View Architecture with UML 2. White Paper
Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was
More informationThe 7 Attributes of a Good Software Configuration Management System
Software Development Best Practices The 7 Attributes of a Good Software Configuration Management System Robert Kennedy IBM Rational software Benefits of Business Driven Development GOVERNANCE DASHBOARD
More informationThe Impact of Global Software Development on Software Configuration Management. Kaisa Uotila
The Impact of Global Software Development on Software Configuration Management Kaisa Uotila University of Tampere Department of Information Sciences Master of Science Thesis May 2003 ii University of Tampere
More informationFundamentals of Measurements
Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role
More informationLecture 20: Software Evolution
Lecture 20: Software Evolution Basics of Software Evolution Laws of software evolution Requirements Growth Software Aging Basics of Change Management Baselines, Change Requests and Configuration Management
More informationCENG492 SENIOR DESIGN PROJECT AND SEMINAR II SOFTWARE CONFIGURATION MANAGEMENT PLAN
CENG492 SENIOR DESIGN PROJECT AND SEMINAR II SOFTWARE CONFIGURATION MANAGEMENT PLAN by Group LaPaix Subject on COMPUTERIZED READING SYSTEM FOR BLINDS DEPARTMENT OF COMPUTER ENGINEERING METU ANKARA 28.03.2003
More informationUniversiteit Leiden. ICT in Business. Leiden Institute of Advanced Computer Science (LIACS) Capability Maturity Model for Software Usage
Universiteit Leiden ICT in Business Capability Maturity Model for Software Usage Name: Yunwei Huang Student-no: s1101005 Date: 16/06/2014 1st supervisor: Dr. Luuk Groenewegen 2nd supervisor: Dr. Nelleke
More informationSTAR JPSS Algorithms Integration Team Configuration Management Plan Version 1.2
STAR JPSS Algorithms Integration Team Version 1.2 NOAA Center for Weather and Climate Prediction (NCWCP) NOAA/NESDIS/STAR 5830 University Research Ct College Park, MD 20740 Revisions Version Description
More informationSoftware Configuration Management. Context. Learning Objectives
Software Configuration Management Wolfgang Emmerich Professor of Distributed Computing University College London http://sse.cs.ucl.ac.uk Context Requirements Inception Elaboration Construction Transition
More information1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software...
1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand
More informationSoftware Configuration Management
Steven J Zeil March 17, 2013 Contents 1 Problems 2 2 Common Practices 6 1 1 Problems Software Configuration Management Over time, a software system can exist in many versions: revisions created as developers
More informationRealizing CMMI using Enterprise Architect and UML for Process Improvement
Realizing CMMI using Enterprise Architect and UML for Process Improvement Jack Hunnicutt, Anteon Corporation www.anteon.com Ramsay Millar, integrate IT architects LLC www.integrateitarchitects.com Introduction
More informationStandards Initiatives for Software Product Line Engineering and Management within the International Organization for Standardization
Standards Initiatives for Software Product Line Engineering and within the International Organization for Standardization Timo Käkölä University of Jyväskylä 40014 University of Jyväskylä, Finland timokk@jyu.fi
More informationArchitecture Centric Development in Software Product Lines
Architecture Centric Development in Software Product Lines Aurangzeb Khan DCE, College of E & ME National University of Science and Technology (NUST), Pakistan Farooque Azam DCE, College of E & ME National
More informationConfiguration management. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1
Configuration management Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1 Objectives To explain the importance of software configuration management (CM) To describe key CM activities
More informationEnabling Continuous Delivery by Leveraging the Deployment Pipeline
Enabling Continuous Delivery by Leveraging the Deployment Pipeline Jason Carter Principal (972) 689-6402 Jason.carter@parivedasolutions.com Pariveda Solutions, Inc. Dallas,TX Table of Contents Matching
More informationAgile Based Software Development Model : Benefits & Challenges
Agile Based Software Development Model : Benefits & Challenges Tajinder Kumar Assistant Professor, IT Department JMIT Radaur, Haryana Vipul Gupta Assistant Professor, IT Department JMIT Radaur, Haryana
More informationF15. Towards a More Mature Test Process. Anne Mette-Hass. P r e s e n t a t i o n
Towards a More Mature Test Process Anne Mette-Hass International Conference On Software Testing, Analysis & Review November 19-23 Stockholm, Sweden P r e s e n t a t i o n F15 Friday 23rd November, 2001
More information2. MOTIVATING SCENARIOS 1. INTRODUCTION
Multiple Dimensions of Concern in Software Testing Stanley M. Sutton, Jr. EC Cubed, Inc. 15 River Road, Suite 310 Wilton, Connecticut 06897 ssutton@eccubed.com 1. INTRODUCTION Software testing is an area
More informationUsing CMM with DO-178B/ED-12B for Airborne System Development
Using CMM with DO-178B/ED-12B for Airborne System Development WHITE PAPER Author : Narasimha Swamy (Project Manager, Avionics Practice) Most aircraft companies develop onboard systems software for civilian
More informationConfiguration Management One Bite At A Time
Configuration Management One Bite At A Time By Kai Holthaus, ITIL v3 Expert and Director for Third Sky, Inc. Implementing Configuration Management can be a daunting challenge. While the potential payback
More informationConfiguration Management. Software Configuration Management. Example of System Families. Configuration Management
Configuration Management Software Configuration Management New versions of software systems are created as they change: For different machines/os; Offering different functionality; Tailored for particular
More informationVariation Management for Software Production Lines 1
Variation Management for Software Production Lines 1 Charles W. Krueger BigLever Software, Inc. 10500 Laurel Hill Cove Austin TX 78730 USA ckrueger@biglever.com Abstract. Variation in a software product
More informationINTRODUCTION PROCESS KNOWLEDGE CONNIE MOORE VICE PRESIDENT, GIGA INFORMATION GROUP
INTRODUCTION PROCESS KNOWLEDGE CONNIE MOORE VICE PRESIDENT, GIGA INFORMATION GROUP OVERVIEW Throughout the next decade, organizations work practices and IT systems will shift profoundly as the economy
More informationChap 1. Introduction to Software Architecture
Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)
More informationUniversity of Calgary Schulich School of Engineering Department of Electrical and Computer Engineering
University of Calgary Schulich School of Engineering Department of Electrical and Computer Engineering Research Area: Software Engineering Thesis Topics proposed by Dr. Dietmar Pfahl, Assistant Professor
More informationJohannes Sametinger. C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz A-4040 Linz, Austria
OBJECT-ORIENTED DOCUMENTATION C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz A-4040 Linz, Austria Abstract Object-oriented programming improves the reusability of software
More information