rect
You are viewing an archived version of CBSE 1999. This page has been archived via the Internet Archive Wayback Machine for the ICSA conference series history. Some links on this page might not work.
← return to the ICSA homepage.
General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
engineering graphic
Engineering Practices
Welcome
Architecture Tradeoff Analysis
CERT Coordination Center
COTS-Based Systems
Overview
Activity Areas
Products and Services
CBS Team
References
Events
What's New
Opportunities to work with us
Briefings, Courses, and Workshops
Spiral Development Workshops
CURE (COTS Usage Risk Evaluation)
COTS-Based Systems Monographs
COTS_Spot Column
Little Red Book
Dependable System Upgrade
Information Repositories
Personal & Team Software Process
Product Line Practice
Software Engineering Measurement & Analysis (SEMA)
Complete Technical Project List
Common Acronyms
Featured Publications
Technical Initiatives
Courses
Conferences
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
Rollover Popup Hints for Topic Navigation Buttons above
Transition from Conventional to Component-Based Development


Goran Grahn (it.gorang@memo.volvo.se)
Senior Consultant
Volvo Information Technology
Dept 9712, HC1N
SE - 405 08 Gothenborg, Sweden  

 

1. Introduction

During fall 1998, I was leading a pre-study on "Introduction of an Enterprise-level Reuse Program" within Volvo Information Technology. The objective of the study was to establish a common understanding of what is needed to make the introduction of such a program successful, and to propose the way ahead. This paper is an extract of the pre-study report.

Volvo IT is organised in a number of Business Process Units (BPU's), each one supporting one of the main processes of the companies in the Volvo Group. These main processes are:

  • Product Development
  • Sales to Order
  • Order to Delivery
  • Delivery to Repurchase
  • Business Administration

Each BPU contains a number of Application Areas, which is equal to one or more Domains.

The proposed program to transition from conventional to component-based development

describes activities on the Enterprise, BPU and Application Area / Domain levels, split into the following three phases:

  • Initiate Reuse Program, where information on reuse concepts is presented as a basis for identifying reuse potential and establishing reuse ambition and plan within each BPU
  • Preliminary Reuse process, where training starts, new roles are staffed and an initial architecture is developed as a basis for performing pilot projects. In this phase also Component Catalog tools are evaluated.
  • Establish Reuse process, where the reuse process is formalized, the large-scale implementation of the reuse process is planned, and component provisioning and application assembly as the approach for software delivery is established.

2. Initiate Reuse Program

2.1 Enterprise level

2.1.1 Inform on Reuse Concepts

The purpose of this step is to present the basic concepts of Software Reuse to the organization, as a basis for initial activities at the BPU level.

2.2 BPU level

2.2.1 Identify Resue potential within each BPU

In this step a group of people representing the Application Areas and / or the major projects within the BPU is established, to start working reuse issues. Input for this activity could be:

  • Existing Business Process models
  • Data and Process Models from existing applications
  • External sources of reusable components that may be used by the BPU

This step would identify the potential for reuse from two aspects

  • What is the potential for reuse from an architectural, long term perspective
  • What is the potential for reusing pieces of existing applications, considering aspects like functionality, interfaces, reliability and the technical environment where it is implemented

2.2.2 Establish Reuse ambition and plan within each BPU

The purpose of this step is to establish management support of Reuse. This includes the selection of which Application Areas are best suited for performing pilot projects, where concepts and process guidelines can be refined.

For areas selected the next phase is planned, where a preliminary process will be defined, new roles are to be staffed and an initial architecture established as a basis for the pilot.

3. Preliminary Reuse Process

3.1 Enterprise level

3.1.1 Upgrade Application Development Process to supporting reuse

The AD process currently used is architecture-driven, and based on an object oriented approach, but lacks specific activities pointing out at which point in each development phase the opportunity to satisfy requirements using existing components, or to harvest newly developed components are analyzed. Such activities supporting reuse must be added to the AD process.

3.1.2 Build Reuse skills

This step includes developing a training plan, and presenting classes to people at the enterprise and BPU levels responsible for the reuse program.

3.1.3 Staff new roles

At the enterprise level the following new roles are staffed:

  • Component Provisioner, responsible for providing technical and business infrastructure components
  • Reuse Support, responsible for supporting developers in the use of the catalog, and in the utilization of infrastructure components

3.1.4 Define Reuse Metrics

Reuse Metrics are defined, and a process for measuring them is put in place.

3.1.5 Evaluate Component Catalog Tools

In this step, available tools in the Component Catalog market are evaluated, and a recommendation on which tool is best suited to the needs of the enterprise is given.

3.2 BPU level

3.2.1 Start Reuse Awareness and Training process

The purpose of this step is to present the basic concepts of Software Reuse to the organization, as a basis for pilot activities at the BPU level.

3.2.2 Staff new role

The role of BPU Reuse Manager is staffed. This role is responsible for coordinating the application architecture within the BPU.

3.2.3 Establish funding of pilot projects

Methods for funding reusable components of the pilot projects are put in place.

3.3 Application Area level

3.3.1 Establish Application Area Architects

This step includes selecting individuals for the role of Application Area Architect. The architects should have some background in the Application Area and be familiar with model-based methods. The introduction of the architects involves establishing working relationships with the Business Process Owner, with Enterprise Architects and support groups, and with project leaders of current projects.

3.3.2 Develop High Level Application Area Models

Based on Business Process Models, Business Data Models or Class Diagrams and the existing System Architectures, the Application Area Architect develop high level Application Area Models and Plans regarding support for new or changed business processes, Plans for new systems or major enhancements, and Plans regarding move to new technologies.

3.3.3 Establish Application Area Architecture

In this step, the Application Area Models and Plans are reviewed with the stakeholders, which include:

  • Business Process Owner
  • BPU Strategy group
  • Enterprise Architects

3.3.4 Staff new roles

The roles of Component Provisioner and Application Developer for the pilot projects are staffed.

3.3.5 Perform Pilot Projects

Pilot projects are prepared, executed and concluded.

4. Establish Reuse Process

4.1 Enterprise level

4.1.1 Formalize Reuse Process

Based on experience from pilot projects, the Reuse Management Process is adjusted, documented and established.

4.1.2 Introduce Component Catalog

The catalog tool recommended in step 3.1.5 is introduced. This step includes negotiating a contract with the vendor, installation of the tool, setting up standards and procedures for using the catalog and training the catalog administrator and users.

4.1.3 Wrap / Acquire / Build Common Reusable Components

Based on the Enterprise Architecture and Application Area Architectures, common Technical and Business Infrastructure components are identified. For each component is decided whether to make it available by wrapping part of an existing system, buy it from outside or develop it inhouse. Once the components are available they are documented for use in the Component Catalog.

4.2 BPU level

4.2.1 Plan Implementation of Reuse Process

This step involves planning the large-scale implementation of the reuse process, and includes extending the high-level models and expanding the training and support resources.

4.2.2 Establish funding of reusable components

Methods for funding reusable components of all software delivery projects are put in place.

4.3 Application Area level

4.3.1 Extend High Level Application Area Models

The High Level Application Area Models and Plans regarding support for new or changed business processes, Plans for new systems or major enhancements, and Plans regarding move to new technologies initiated in step 3.3.2 are extended in scope and level of detail.

4.3.2 Wrap / Acquire / Build Reusable Components

Based on the Application Area Architecture, Business Process Components are identified. For each component is decided whether to make it available by wrapping part of an existing system, buy it from outside or develop it inhouse. Once the components are available they are documented for use in the Component Catalog.

Conclusion

This paper is an attempt to describe the transition from conventional to component-based development. At Volvo this is still theory, since our efforts currently is stopped due to changes in our business following the deal to sell Volvo Cars to Ford Motor Company. However, we firmly believe that Component-Based Development is the way ahead!

Acknowledgements

This paper draws on a paper titled "Integration on Software Process Maturity and Domain Engineering to facilitate Reuse within the Enterprise" presented at the Reuse '97 conference in Morgantown, West Virginia, USA by Kevin T. Shea at The Boeing Company.
 

 

 

 

download the PDF file
contact the organizers


The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Copyright 2001 by Carnegie Mellon University
URL: http://www.sei.cmu.edu/papers/22/22.htm
Last Modified: 27 September 2000