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.