Configuration Management Consulting for Software Development

Introduction

Thanks to their experience in implementing Software Configuration Management Suites, ARCAD Software consultants have developed in-depth expertise in this field. Using consulting services as a lead-in to choosing and implementing tool-supported solutions allows definition of an overall Software Configuration Management methods framework adapted to each company's needs and limitations.

Objectives

SCM norms are implemented to maintain your system coherence, completeness, readability and traceability during the development and operation phases. Effective SCM should provide immediate responses to the following questions:

• What changes were made?
• Why were the changes made?
• Where are the modified items?
• Who made the changes?
• When were the changes made?

Areas of Application

This methodological framework applies to changes made by in-house information services teams. The primary element is the source component manipulated by developers.

Implementation

This methodology has three implementation phases:
Identifying elements to be included in the perimeter:

• Software components (software packages, specified software publisher developments, customized in-house developments, associated items such as interfaces, infocenter databases, etc.)
• Documents (technical and functional software specifications, technical documentation, version documents, user requests, test documents, etc.)
• Related software applications outside the perimeter that can affect system stability
• Functional teams (users, domain managers, testers) and technical teams (developers, architects, operators, testers, etc.)
• Hardware that supports software components.

These elements are collected in a repository that will serve as a management base for all later developments.

Defining front-end changes: The Change Control Board.

• Accounting for external factors that will impact the system (change requests, error notices, supplier deliveries, hardware upgrades, etc.)
• Definition of risks and impact
• Priority allocation
• Allocation of versions that will include changes
• Change authorization.

Defining how back-end changes will be implemented: The Configuration Control Board.

• Change validation and verification: Document change monitoring, check for follow-up files on changes performed, unit tests executed, etc.
• Integration phase: Test space definition, authorization lists, backtracking process, status definition,
• Repository updates,
• Delivery procedures for production sites.

Configuration Management Consulting for Software Integration

Introduction

Today there are a number of tools that functionally integrate applications (both in-house developments and software packages) into the information system and allow applications to communicate with other software components. At the same time, ensuring technical integration is key: installing a product or receiving a new version should not destabilize the system. This is where ARCAD Software consultants' expertise comes into play.
Consulting services allow definition of the overall methodological framework for software configuration management, adapted not just for software changes but also for software component integration.

Objectives

Specialized integration SCM norms are applied to maintain your system coherence, completeness, readability and traceability during the software suite implementation phase. Effective SCM should provide the following:

• Architecture organization for implementing the initial version;
• Reception management;
• Technical qualification;
• Integration impact analysis;
• Integration into the overall application framework.

This procedure makes possible a transition from a situation in which a company undergoes delivery-related changes to a more pro-active scenario in which changes are anticipated.

Areas of Application

This methodological framework applies to all the change phases in a software configuration - not at the unit level for each modified source component, but for the entire set of modifications grouped within a function or version.

Implementation

This methodology involves three phases:
Identifying elements to be included in the perimeter:

• Software components (software packages, certain software publisher developments, customized in-house developments, transverse items such as interfaces, infocenter databases, etc.);
• Documents (technical and functional software specifications, technical documentation, version documents, user requests, test documents, etc.);
• Related software applications outside the perimeter that can affect system stability;
• Functional teams (users, domain managers, testers, etc.) and technical teams (developers, architects, operators, testers, etc.);
• Hardware that supports software components.

These elements are collected in a repository that will serve as a management base for all current and future developments.
Normalizing relations with a supplier (in-house or external).

Changes are not made based on information in the repository environment; instead, they are delivered from an outside source and must be integrated. Reception must be carefully monitored, including:

• In repository environments, identification of supplier components;
• Definition of information that should accompany deliveries;
• Definition of delivery unit checkouts;
• Definition of delivery integrity checkouts;
• Definition of integration impact analyses;
• Definition of transfer-to-test criteria.