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 . 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 , VAX DEC/CMS  and Softool CCC . 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
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
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
. 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  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
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 . 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
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
- Interfaces control definition
- Incremental development
- 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
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
Query Configuration Management Forms
Time Dependent Events Control Facility
Disable/Enable Automatic Version Control
Available File Operations
Copy . Delete . Modify . Read . Update File
Fetch Version and View Version
Mechanisms for File Operations
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
Global Operations By DMS Manager
Link to Operating System
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
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
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
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
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.
 Ben Livson, UDF "Computerized Unit Development Folder User
Manual", Proceedings of the Fifth International Conference
of the Israel Society for Quality Assurance, October 1984.
 M. J. Rochkind, "Source Code Control System",
IEEE Transactions on Software Engineering, SE-1, 1975.
 VAX DEC/CMS "Code Management System" Reference Manual,
Order No. AA-L372B-TE, Digital Equipment Corporation.
 Softool CCC "Change and Configuration Control" report
no. F011.1-8-82, April 1984.
 IEEE Transactions on Software Engineering, January 1977
issue of the first software specification methodologies.
 Ben Livson, "Future Development Management System Concepts",
ACM SIGSOFT Software Engineering Notes, Volume 12, Number 3,
 William W. Agresti, New Paradigms for Software Development,
IEEE Computer Society Order Number 707, 1986.
Future Software Development Management System Prototype Page 10
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
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.