Future Software Development Management System Prototype

16th ACM Conference, Atlanta, Georgia 1988

 

Initial work during the last ten years for defining and

prototyping software Development Management Systems has prepared the

ground for presenting the concepts for the year 2000 DMS. DMS product

evolution, features, 'approach, concepts and philosophy', future year

2000 concepts and current DMS prototype implementation are discussed.

Finally, an offspring of the DMS project, EduSET: Educational Software

Engineering Tool, is outlined.

Copyright 1988-2006 Ben.Livson@bal.com.au. All rights reserved.

DMS PRODUCT EVOLUTION

DMS tool development started by computerizing the modest, but

initially successful TRW Unit Development Folder concept.

Specification of the UDF tool was completed in 1982-1983, the first

prototypes entered use during 1984 and have been in trial use to

support avionics and dynamic simulation software development in the

Israel Aircraft Industries Ltd [1]. Limitations of the UDF tool were

lack of configuration management services and lack of support for

project management. Bad synchronization between software development

and the often delayed preparation of the unit development folders was

perceived as a major problem for the UDF tool. The other major project

management problem was how to cross milestones and deliverable items

with the actual status of the files system. An off-line auxiliary UDF

tool could not provide answers to these problems. This experience led

to the development of the Ultraware Ltd. Development Management System.

The most radical departure from the original canned software

engineering tool concept was the inclusion of a life-cycle paradigm

generator to support organizational adaption of the DMS tool.

DEVELOPMENT MANAGEMENT SYSTEM DMS FEATURES

* Software Environment Driver

* Educational Software Engineering Tool

* Integrated Meta-Information Handler and Execution System

* Computerization of the TRW Unit Development Folder Concept

* Complete Life-Cycle and Configuration Management Support

* Automatic Background Processing for Version Control

* AI Component for Analyzing Software Engineering Process

* Data Sharing and Human Communications

* Controlled Access by User Category

* Natural Software Engineering Environment

* Maximal Management Visibility

* Forms for SCM, SQA, Software Testing, Verification and Validation

* Support for Implementing IEEE Software Engineering Standards

* Traceability of Testing to Requirements Supported

* User Interface Management Library and Generator

* Callable Interface

* Life-Cycle Paradigm Generator

* Portable: VAX/VMS, UNIX and MS DOS

1988 ACM Sixteenth Annual Computer Science Conference Proceedings

Copyright 1988 ACM 0-89791-260-8/88/0002/0047


 

Future Software Development Management System Prototype Page 2

PRESENT DMS APPROACH, CONCEPTS AND PHILOSOPHY

The DMS is tailored to the files management of your computer

system. Its meta-data supports software project organization into the

natural hierarchy of directories and files. The DMS system is an

opposite approach to a number of container type software tools such as

the Unix SCCS [2], VAX DEC/CMS [3] and Softool CCC [4]. The advantage

of the DMS as compared to the container type tools is that no export or

import operations are needed to communicate between the container and

the natural file system. The container tools cause a considerable

overhead both in terms of wasted work time and computer resources, and

compel users to learn additional command syntax. The separate

hierarchy of the container tools is a likely source of confusion and a

considerable burden to users. Perhaps the most severe drawback of

container type tools is that low level configuration management

operations are done manually off-line from the main software

development process. The unique advantage of the DMS system is that

all low level configuration management operations are automatically

executed in parallel to the software engineering process. In

particular, version control is automatically synchronized to the

software engineering process and is not a separate delayed process.

A key issue of the DMS system is to minimize meta-information

requested from users. The minimum requested from users is to state the

names of directories and files. This information is used by the DMS to

automatically execute low level configuration management commands such

as storing file versions, and to provide users an optimized access to

files management: DMS hides all scratch files, eliminates the need to

memorize or to search for files, makes a cross between files and

life-cycle phases, provides universal utilities for viewing files, and

captures files and file access utilities information from users. Users

are relieved from restating directory and file names each time a file

is being accessed. In short, the number of keyboard strokes is

minimized by the DMS system. Basically, all additional

meta-information such as milestone data is voluntary and aimed at

providing greater management control and visibility.

The DMS system is an open access system. It does not force

any specific software engineering method. It does offer comprehensive

life-cycle support but it does not force users to follow any specific

life-cycle model such as the waterfall model or rapid prototyping.

However, considerable semantic analysis is done by the background

housekeeping functions about the reasonableness of the software

engineering process. Meta-data is tied to the files management system

to detect anomalies such as insufficient effort in requirements,

testing or SQA; deliverable items not implemented for approved

milestones; discrepancies between milestone data and the actual

software process.

The aim is to guide DMS users to devote considerable effort

in the conceptual phase of software development. The DMS system does

not address itself to issues such as which method to use in

requirements definition. It is only a software engineering environment

driver. Each organization should use its own methods and tools via the

DMS system.


 

Future Software Development Management System Prototype Page 3

Future directions of the DMS system are not aimed at

providing support to any specific software engineering methodology, see

[5]. The aim is to provide general purpose services such as

autoregression test support, document trace tools to support

verification, and IEEE software engineering and military standard

templates. Components for software cost estimation and reliability

measures will be included.

DMS paradigm definition facility enables experimental or

organizational life-cycle paradigms to be defined. Any number of

paradigm phases may be defined. The phases may be parallel. Paradigm

phase may be enforced in a way that guarantees that the next phase is

not started before completion of the previous phase. The next phase

may be allowed to start after the start of a previous phase or any

logical combination of such conditions. Read [7] for background.

A major effort will be to port the DMS tool to a number of

major operating systems. Software development in a heterogeneous

operating system environment is the next DMS goal. Currently, DMS is

implemented for DEC VAX/VMS, Microsoft DOS for IBM PC/PS, and the first

AT&T Bell Laboratories UNIX V compatible implementations are nearing

completion.

FUTURE YEAR 2000 DMS CONCEPTS

'Future Generation Development Management System

Requirements' was initially displayed at the Tools Presentation Track,

9th ICSE, Monterey, 30.3 - 2.4.87. This was followed by an extended

abstract [6]. The original IBM PC DOS tools track demonstration

diskette may be obtained from the author.

Future DMS will not be based on any of the new paradigms for

software engineering. In my opinion both formal and semi-formal

software engineering methods are likely to continue to do more harm

than good until the year 2000. In most application domains even

formalized executable requirements are not enough. The problem of

capturing requirements still remains the classic problem of developer

and customer understanding each other. The automation of the

implementation phase is gradual but certain. The "final solution", if

ever attained, must come from the AI research of cognitive reasoning.

I do not believe that an AI solution that supports the conceptual phase

will be available before the 2020 - 2050 period. New tools supporting

conceptual phase may be integrated to DMS 2000 open ended architecture.

The focus, however, shall NOT be on external tools integrated to DMS

2000.


 

Future Software Development Management System Prototype Page 4

DMS 2000 ARCHITECTURE: THE PRIMARY SUBSYSTEMS

- Standard Relational Database Architecture

- Natural Language Interface

- Execution Engine

- AI Component with Software Engineering Rules Base

Standard Relational Information Architecture Supports:

- Automatic creation of test cases from requirements

- Traceability

- Interfaces control definition

- Incremental development

- Reusability

- Configuration management

- Contract management

- Management visibility

- Distributed project environment

Natural Language Interface to DMS Information Architecture

shall hide database aspects of DMS 2000. In particular, no language or

syntax for data retrieval or entry is necessary. Natural language

interface is crucial for the DMS to succeed in a hostile environment

characteristic many (most?) projects.

DMS Execution Engine Requirements

DMS execution engine shall serve as an interface between

software engineers and operating system in the natural working

environment. The DMS engine shall automatically link the relational

information architecture with the operating system. The engine shall

capture software engineering data and enter it to the information

architecture, thus minimizing manual data entry requirements. The

engine shall do parallel processing of all low level configuration

management operations without user intervention.

DMS AI Component for Analyzing the Software Process

The DMS shall have a software engineering rules base and an

AI component capable of verifying compliance to the rules by matching

the rules and the relational meta-data. The rules shall cover

adherence both to life-cycle and to contractual constraints.


 

Future Software Development Management System Prototype Page 5

DMS 2000 shall NOT be based on the 'Value Added Approach'

The current trend of integrating tool fragment .. utilities

into packages is useful only for the implementation phase that

approaches the 'completely understood and stable domain' stage.

Examples of successful implementation phase packages are: UNIX, VAX

Set, Toolpack .. APSE ... The value added approach of incrementally

building the DMS 2000 does not work, because the concept is based on

the DMS engine, also called 'software environment driver', relational

database architecture, natural language front end, and background AI

component.

Standard Computer Vendor Solutions For DMS Implementation

DMS relational information architecture shall be based on

computer vendor standard. Also, the natural language interface shall

be supplied by computer vendor. The unique components for the year

2000 DMS shall the DMS engine and the DMS AI component.

Stage of Current DMS Implementation versus DMS 2000

Information Architecture -- Yes, but not flexible

Natural Language Interface -- None

DMS Execution Engine -- Powerful

AI Background Component -- Yes, but not flexible

D M S P R O T O T Y P E I M P L E M E N T A T I O N

P R I M A R Y F U N C T I O N S

Invocation by User Category

Creating a New DMS Directory

Main Menu Functions

Configuration Management Functions

Interface to Make

Backup to Private Magnetic Media

Create Configuration Management Form

Configuration Log

Milestones

Query Configuration Management Forms

Time Dependent Events Control Facility

Disable/Enable Automatic Version Control

Baseline Generation

Available File Operations

Add File

Copy . Delete . Modify . Read . Update File

Fetch Version and View Version

Mechanisms for File Operations

Life-Cycle Enforcement

DMS File Encryption

DMS File Title Information

Editor .. Utilities Menu

DMS Anomalies Report


 

Future Software Development Management System Prototype Page 6

DMS Information Menu Functions

Management Information

SQA Information

Mail Facility

DMS Services

Print Menu

Global Operations By DMS Manager

Shared Files

Link to Operating System

Special Services

Housekeeping Functions

...................................

E X A M P L E O F D M S R E P O R T S

D M S A N O M A L I E S

Warning: Requirements files size = xy.z% <10%

Warning: Design files size = xy.z% <20%

Warning: Testing files size = xy.z% <10%

Warning: SQA files size = xy.z% <10%

Error: illegal original date for milestone msno

Error: illegal revised date for milestone msno

Warning: Developer approval of milestone msno

without SQA approval of msno-1

Warning: Developer approval of milestone msno

without Manager approval of msno-1

Warning: SQA approval of milestone msno

without Manager approval of msno-1

Error: illegal Developer approval date for milestone msno

Error: illegal SQA approval date for milestone msno

Error: illegal Manager approval date for milestone msno

Warning: SQA approval without Developer approval of milestone msno

Warning: Manager approval without SQA approval of milestone msno

Warning: Manager approval without Developer approval of milestone msno

Warning: Overdue Manager Approval of milestone msno

.................................................................

E X A M P L E O F D M S U S E R M A N U A L

D M S P A R A D I G M D E F I N I T I O N F A C I L I T Y

------------------------------------------

Paradigm Definition Facility.

(C) Copyright Ben Livson, 1987

A - Add

C - Confirm Completion of Paradigm Phase

D - Delete

G - Generate Paradigm Source File

S - Show

U - Update

? Select Option. <Return> = Exit from Menu

------------------------------------------


 

Future Software Development Management System Prototype Page 7

Functions Add, Delete and Update are used to define

life-cycle paradigm. Function Show both displays paradigm and checks

against errors. Option G generates paradigm source file to be used to

create a DMS image with burnt in paradigm definition. Confirm

Completion of Paradigm Phase is the only function that affects the

state of a DMS directory and is used by manager to enforce control on

the life-cycle process.

Work procedure for paradigm definition facility use is:

Step-1: Write down on paper all the paradigm definition

activities. Paradigm activities are recorded in \dms_path\paradigm.dms

direct access file. Each paradigm record has the following five

fields:

1 Phase number. Phases numbers are in increasing order with

maximal increment of one. Parallel activities have equal phase number.

Range of phase numbers is 0 .. 9. Up to twenty activities may be

defined.

2 Paradigm activity confirmation status is YES, if

confirmation is required before the next phase development may start.

In any case start of previous phase activities is automatically imposed

before activities of a later phase are permitted. However, by

confirmation status YES, DMS MANAGER approval is imposed before the

next phase development starts.

3 Paradigm menu option initial. The initial may be

alphanumeric. Initials A,C,H,M,S and V are restricted as well as the

initials of all previously defined paradigm activities. Lower case

letters are automatically converted to upper case. Each initial

corresponds both to a DMS Development .. Life-Cycle Menu option and

corresponds to a meta-data file build.%, where % is the menu option

initial. This meta-data file holds information about all files

belonging to a given activity.

4 Program unit invoked by paradigm menu option. Default

program unit is afo(c) with character*1 c parameter denoting menu

option initial. An exception is menu option initial T with default

subroutine TEST. Observe that default program units afo and test

invoke configuration management operations. If you do not use the

defaults, you must have a complete understanding of the DMS

configuration management mechanism.

5 Paradigm menu title.

Default built-in DMS life-cycle paradigm is:

Phase No. Confirmation Status Initial Program Unit Menu Title

--------- ------------------- ------- ------------ ----------

0 No R AFO(C) Requirements

1 No D AFO(C) Design

1 No T TEST Testing

2 No I AFO(C) Implementation

Thus, existence of at least one requirements file is

compulsory before design or testing may start, but completion of

requirements does not have to be confirmed by manager before design or

testing may commence. Design and testing are parallel activities.

Implementation may start only after all previous activities have files.

Write down on paper your paradigm table.


 

Future Software Development Management System Prototype Page 8

Step-3: Enter paradigm activities one by one using the 'Add'

function. If you make mistakes, use 'Update' or 'Delete' functions.

Invoke 'Show' to view your paradigm definition and to check against

errors.

Step-4: Generate paradigm source by option G. Write a stub

main for this routine, compile and link with dms_path object libraries

DMS and USER to test your paradigm source. If your paradigm source

invokes program units not available in the DMS library, add them to the

USER library after thorough testing. Be sure to backup libraries DMS

and USER, and DMS.EXE image.

Step-5: DMS Library and Image Linkage Instructions ...

EduSET: Educational Software Engineering Tool Project

Why are freshmen computer science graduates almost useless as

software engineers? Why must companies invest in massive retraining of

CS graduates? Light to these problems is shed and at a least a partial

solution is attempted by the Educational Software Engineering Tool

EduSET project. EduSET interface to software tool information and

demonstration is specified.

Software engineering tools are supposed to aid, formalize or

support the most difficult of all processes, namely the human reasoning

process called software engineering. This process is by nature

distributed, cooperative and heterogeneous. Interacting with project

management, configuration management, software quality assurance,

customer independent verification and validation is a most complicated,

costly and painful process even for experienced professionals. CS

students in most cases do not have the faintest idea about these real

life problems. EduSET enables to simulate the real working

environment, and lets students act in the roles of developer, software

quality assurance, configuration and project management and customer

end user. EduSET gives the framework for controlled access with each

user category having its privileges. EduSET shall enable the CS course

software engineering lecturer to define a class project with students

participating in the different roles. EduSET supports experimentation

of life-cycle paradigms.

A CS student does not qualify as a software engineer before

developing software under (simulated) real life circumstances. EduSET

shall enable software development in a natural environment. Every

software development tool or utility must executable via EduSET.

EduSET shall be a software environment driver that enables use of all

other software products.

EduSET shall support the whole life-cycle. EduSET shall

enforce a disciplined software engineering approach under configuration

management. Configuration identification, control and status reporting

services shall be part of EduSET. Auditing shall be supported by

EduSET providing a full range of IEEE CS software engineering standard

checklists and templates.


 

Future Software Development Management System Prototype Page 9

EduSET Educational Software Engineering Tools is a commercial

project to produce and mass distribute a book and a set of IBM PC or MS

DOS* 3.x disks with common computer aided instruction interface,

information and canned demonstrations of software engineering tools and

supporting methodologies. CASE vendors and other interested parties

are invited to make submissions:

Submissions shall be without cost or obligation. The media

is 5.25" 360Kb IBM PC floppy disks. A disk shall have read.me file

explaining its contents. All commercial information shall be

restricted to a file named license.doc. Files may be text files

cleaned from word processing symbols and special files for

demonstration. A valid demonstration file is any ASCII file that can

be supported by DOS 3.x ansi.sys device driver and split into 80-column

wide 22-row long pages (2 rows of a 24 line ANSI VDT terminal are

reserved for control). The page separator shall be a unique

combination of two characters: $x. Interested parties may request a

sample diskette.

Companies or individuals interested in making a submission to

EduSET may contact Ben Livson, EduSET author, Ultraware Limited:

+972-3-341366, P.O. Box 367, Kiryat Ono 55102, Israel.

USA Telex: 4900004722 and INC Dialcom E-Mail 05:GLU750.

REFERENCES

[1] Ben Livson, UDF "Computerized Unit Development Folder User

Manual", Proceedings of the Fifth International Conference

of the Israel Society for Quality Assurance, October 1984.

[2] M. J. Rochkind, "Source Code Control System",

IEEE Transactions on Software Engineering, SE-1, 1975.

[3] VAX DEC/CMS "Code Management System" Reference Manual,

Order No. AA-L372B-TE, Digital Equipment Corporation.

[4] Softool CCC "Change and Configuration Control" report

no. F011.1-8-82, April 1984.

[5] IEEE Transactions on Software Engineering, January 1977

issue of the first software specification methodologies.

[6] Ben Livson, "Future Development Management System Concepts",

ACM SIGSOFT Software Engineering Notes, Volume 12, Number 3,

July 1987.

[7] William W. Agresti, New Paradigms for Software Development,

IEEE Computer Society Order Number 707, 1986.


 

Future Software Development Management System Prototype Page 10

AUTHOR BIOGRAPHY

Dr. Ben Livson is consultant software engineer in Ultraware

Ltd, an Israel-based firm that provides training and consulting

services and developes software tools with special emphases on software

quality assurance, testing and configuration management.

Ben Livson was brought to Israel in 1977 by the Israel

Aircraft Industries Ltd to establish the first software quality

assurance group for computer embedded systems, a group that he managed

until 1986.

Dr. Livson has fifteen years of software engineering

experience including major assignments as:

1. SQA manager of operational flight programs and dynamic

simulation and integration projects.

2. Manager of software testing projects for computer

embedded systems communications software and operating system.

3. Developer of a computerized unit development folder and

configuration management tools.

Ben Livson is an IAF and university lecturer. He has chaired

the software quality assurance sessions of the fourth and fifth

international Israeli Quality Assurance Conferences, and he has

published over twenty papers.