MARC is a remote command and control system for PABX communications networks. MARC began as a remote supervision system for a particular PABX, but has evolved to become a general product for the supervision and control of computerized systems, to which commands can be given. MARC is a multi user system; the users connect to the controlled systems via the telephone or Datex network. When logged in, users gain access to databases, fault histories, mail functions, and dialogue functions for the system being controlled. The dialogue function for example, enables users to connect from a portable PC to the supervised system via MARC.

MARC Development

The system development took place in several stages:

1. In 1984, MARC 1a was produced for retrieving and analyzing the error message buffer from the A345/SL1 exchange. The system was run on a APN 167 computer.
2. In June of 1986, MARC 1bc was delivered. This version handles three additional PABX's and receives hardware alarms for alarm transmitters in the supervised systems. MARC 1bc was run on a DEC MicroVAX computer. Mr. Ingemar Haggstrom , the MARC project manager, notes that the transition from APN to VAX was easily made, because the software was written in Ada.
3. In summer of 1988, MARC 2 was delivered; the delivery marked the evolution to a general system for supervision and control. MARC2 is comprised of a platform on which various applications are constructed; it handles up to fifteen simultaneous users and up to ten simultaneous connections to supervised systems.
4. In late 1988, MARC2 was supplemented with a prototype for automatic fault correction. In an environment comprising an expert systems shell, users could create " service directives" based on common error types to be handled automatically. A service directive is activated when MARC rings up the systems and executes automatic fault correction, according to the service directive.
5. In 1990, a Netview interface was developed for MARC (Netview is IBM's Network Management Software).
6. Additional features are currently under development that will make the system as user-friendly and efficient as possible.

Ada’s Role in System Development

Engineers chose the Ada programming language for the development in the Fall of 1983, during the first development stage of MARC, making the system one of the very first Ada applications in Sweden. Although, as Haggstrom points out, Ada was still very new and immature in 1983, it developed through the course of the project: “development has been rapid and now, five years later, Ada is beginning to live up to the high expectations.”

Ada is still the project engineers’ language of choice and system development continues in Ada. The experience gained on MARC indicates that Ada provides:

• Lower development costs: For an individual project such as MARC2, productivity proved to be 31% higher than for the standard project, according to a calibrated COCOMO model.
• Higher quality: During the first two years of MARC 1bc operation, fault corrections have required work costs amounting to less than 1% of the development costs.
• A system architecture that reduces the costs for introducing new functions: Ada provides a successful object oriented design so that functions can be logically collected in objects; these objects can then be implemented in one or more Ada packages.

Cost Analysis

Cost analysis based on Barry Boehm's COCOMO cost model was used as a planning tool for the MARC 1bc and MARC2 projects. An estimate was for the program volume of each system; since each Ada instruction is terminated with a semicolon, semicolon counting is a generally accepted means for measuring the size of Ada programs. About 15 COCOMO cost parameters were set, including:

• the capacity of the project group (people skills and experience);
• the quality of the development environment;
• the project's prerequisites; and
• the type of system being developed and how critical it is (i.e., a prototype for demonstration purposes or a nuclear power control station).

All of the input data was entered into the COCOMO model, and a proposal for a time schedule and manpower plan was generated. The time consumption estimates, broken down by development phases, were:

• PR= Planning and function specification
• PD= Product design
• DD= Detailed design
• CUT= Programming and unit test
• IT= Integration and system test

Through a comparison between three COCOMO runs and the actual results from the MARC 2 project, two conclusions can be drawn:

• Productivity for the MARC2 project was 31% higher than for a standard project.
• Integration required far less work in MARC2 than in a standard project.

Through a comparison of productivity between the various MARC projects, two major conclusions can be given:

• Ada projects do not seem to follow "Brook's Law". (Brook's Law states that resource consumption increases exponentially when the program size increases, due to increased administration and increased internal communications.)
• The first Ada project should have had a 10 15% lower productivity metric, due to learning factors; a comparison between MARC 1bc and MARC 2 indicates that the learning effect for Ada is greater than that.

The Ada Marc 2 system totals more than 100,000 lines of code. According to the information from Haggstrom, Ada offers three attractive features for projects such as MARC:

• Ada packages
  The ability to separate the interface and the implementation parts of a package is very useful to developers. It means that a package can only be called from another package via a correct package interface; also, it supports object oriented programming, enabling the "encapsulation" of objects.
• Generic packages (a "re utilizable" component that is designed to suit a whole range of problems/applications):

  Generic software components can be more expensive per code line than non generic, since the algorithm must be tested to ensure its functionality for a series of different uses. The gains offered by generic packages are obtained when the package is used several times in the project or when the package is reused in other projects. Using generic packages in the MARC project was a positive experience; engineers feel that generic packages should have been used to an even greater extent. (An analysis of where generic packages can be used and an inventory of what can be reused from previous projects, or pulled from a library of reusable components, can be carried out as early as in the design phase of a software project.)
  

• Tasking (a task is an activity which works in parallel with other activities):
  In MARC, tasks are used for the following:
  • Parallel activities: A task that the terminal is not left inactive, while another task checks that the modem connection is not broken.
  • Distribution of work: A number of subordinate tasks deal with connection, session, and disconnection to the PABX.; when a controller receives information indicating that a free modem port is available, a job is allocated to the free port.
  • Waiting for external events: An alarm task waits to read alarm messages from the computer port, which receives them from alarm transmitters.

The MARC2 project required 13 percent less effort and 3,000 fewer staff hours in the integration phase than the COCOMO model predicted. In defiance of Brook's Law, Swedish Telecom's administration costs decreased with the larger projects. Engineers attribute the savings to being able to compile Ada components separately, thereby saving on the cost of constant and close communications among development teams.

Developing the MARC system in Ada, according to Mr. Haggstrom, has resulted in a better quality product. During the last four years of operation, correcting system errors has cost Swedish Telecom only around 1.5 percent of the total development costs per year.

For further information, contact:

Mr. Bengt Conradi
Alsys AB
Utsiktsvagen 10
Box 2014
S 149 02 Nynashamn
Sweden
Phone: + 46 852 069 010
Fax: + 46 852 020 965

Reprinted with permission from Alsys, Inc.
Produced in cooperation with the AdaIC, Ada Software Alliance, and ACMSIGAda.