Development Management System DMS 5.3 User Manual
(C) Copyright: Ben Livson, 1987. All rights reserved.
T A B L E O F C O N T E N T S
1 INTRODUCTION ..................................... 2
2 WORK PROCEDURE .. USER INTERFACE ................. 4
3 INVOCATION BY USER CATEGORY ...................... 6
4 CREATING A NEW DMS DIRECTORY ..................... 7
5 MAIN MENU ........................................ 8
5.1 Configuration Management Functions ............. 8
5.1.1 Act Interface to Make ........................ 10
5.1.2 Backup to Private Magnetic Media ............. 13
5.1.3 Create Configuration Management Form ......... 13
5.1.4 Configuration Log ............................ 14
5.1.5 Milestones ................................... 14
5.1.6 Query Configuration Management Forms ......... 16
5.1.7 Time Dependent Events Control Facility ....... 16
5.1.8 Disable/Enable Automatic Version Control ..... 19
5.1.9 Baseline Generation .......................... 19
5.2 Available File Operations ...................... 19
5.2.1 Add File ..................................... 21
5.2.2 Copy . Delete . Modify . Read . Update File .. 22
5.2.3 Fetch Version and View Version ............... 23
5.2.4 Mechanisms for File Operations................ 23
5.2.4.1 Life-Cycle Enforcement ..................... 23
5.2.4.2 DMS File Encryption ........................ 24
5.2.4.3 DMS File Title Information ................. 24
5.2.4.4 Editor .. Utilities Menu ................... 24
5.2.4.5 DMS Anomalies Report ....................... 25
5.3 DMS Information Menu Options ................... 25
5.3.1 Management Information ....................... 25
5.3.2 SQA Information ............................. 26
5.3.3 Mail Facility ................................ 28
5.4 DMS Services .................................. 29
5.4.1 Print Menu ................................... 29
5.4.2 Global Operations By DMS Manager ............. 30
5.4.3 Shared Files ................................. 30
5.4.4 Link to Operating System ..................... 30
5.5 Special Services ............................... 31
5.6 Housekeeping Functions ......................... 32
6 THE DMS TOOL NOTES ............................... 32
6.1 Security ....................................... 32
6.2 Safety ......................................... 32
6.3 Corruption of DMS Meta-information ............. 33
6.4 DMS Demonstration and Product Information....... 33
6.5 Performance .................................... 33
6.6 Operating System Implementation Differences .... 34
Appendix-1 TABLES: Content, System Backup, Test & Anomalies.. 34
Appendix-2 Abbreviations .. Trademarks Used.................. 37
Appendix-3 Error Messages And Corrective Actions ............ 37
Appendix-4 DMS Development Utilities ........................ 38
Appendix-5 Callable Interface .. Programming Support Manual . 39
Appendix-6 Automatic Version Control ........................ 43
Appendix-7 Optional Automatic Link to DEC CMS Version Control 44
Appendix-8 DMS Installation Procedure ....................... 45
Appendix-9 Future Year 2000 DMS Concept ..................... 45
Appendix-10 Paradigm Definition Facility ..................... 48
I N D E X .................................................. 50
This manual = file: \dms_path\manual.dms. Invoke dms by typing dms. Type
dms_demo for DMS demonstration and product information. For further
information, contact Ultraware Ltd:
P.O. Box 367, Kiryat Ono 55102, Israel. 972-3-341366.
^1. INTRODUCTION [References listed at the end of appendix-9]
DMS Objectives Snapshot
Support software systems development, configuration
management and project management for the complete life-cycle;
perform AI type semantic analysis of the software process; trace
development to project planning; maximize management visibility;
automate version control and build; support SQA and IVV&T
standards; trace test cases to requirements; computerize the TRW
unit development folder concept; help human communications, and
data sharing; control access for work safety; provide callable
interface library for customized environments; form a software
environment driver for the planned EduSET Educational Software
Engineering Tool; support corporate life-cycle paradigms.
DMS Approach, Concepts, Philosophy .. Viva la Difference
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 directions of the DMS system are not aimed at providing
support to any specific software engineering methodology. The experience with
these methodologies [5] has been that they cause more harm than good. 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. 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.
Hardware and software required: DMS conforms to ANSI terminal standard. Memory,
disk space, operating system and optional software requirements are stated in
appendix-8 installation procedure. The unique aspects of DMS implementation for
different operating systems are listed in section 6.7.
Readers note: Dialogue with the computer is bracketed or placed in boxes to
make separation from other text clear. DCL command procedure, Unix script and
MS DOS batch file terms are interchangeable. DEC DCL Directory notation
[xx.yy...zz], Unix /xx/../yy/zz and MS DOS \xx\..\yy\zz notation is in mixed
use. Unix and MS DOS root directory corresponds to DCL sys$login logical name.
Section 5 is arranged according to DMS menu hierarchy. Menu subsection titles
are marked by {from 5.x menu option y}. Section numbers are prefixed by ^ to
ease editor searches. Invisible menu options H and Z invoke help and callable
interface.
Audience: Software managers, developers, SQA, SCM and VV&T personnel. DMS is an
educational software engineering tool, and as such has a wide audience.
^2. WORK PROCEDURE .. USER INTERFACE
The DMS tool may be used interactively without any preparations. However, it is
recommended in project environment to have a strategy for using the tool. In
particular, it is important to know what information is requested by the tool
and how to get organized. The first phase is to create a set of DMS directories
to support the conceptual phase. A DMS directory is a complete configuration
item that requires initialization and milestone data. Section 4 details the
data items requested to create a DMS directory. It is worth to provide accurate
meta-data, because this data is later used in DMS forms, print files and AI
analysis of the software engineering process. Also, this information is viewed
by all parties participating in your project. The initial phases covering
functional baseline and preceding allocated baseline usually include
requirements engineering, rapid prototyping, management planning of milestones
and deliverable items, plans for software quality assurance, configuration
management, and verification and validation. The unique benefit of using the
DMS tool is that a project evolution history is automatically logged and
version control is automated. The most critical phase for DMS tool strategy
ends with allocated baseline of DMS directories that is to implement your
project product tree of configuration items. Allocated baseline should not be
approved before you have organized DMS directories into a set of computers and
operating system directory trees with initialization and milestone data.
Optional organizational or project templates, global set of project utilities,
entry and exit procedures, and global DMS procedures should be prepared prior
to allocated baseline by the DMS support personnel. These preparations are not
compulsory, but may greatly enhance DMS use in your working environment.
Define an integration strategy how to transfer DMS developer directories into
project integrator control. You will have to define a procedure for switching
the roles of user categories, say by establishing integration baseline of DMS
directories. It is strongly recommended to start using DMS on a pilot project
or a lead branch of a project to gain the necessary experience for defining a
DMS strategy for your organization or project.
DMS User Interface
User interface is via standard ANSI video display terminal and keyboard. Types
of user interfaces are FIXED MENUS, SCROLL MENUS, FILE ACCESS MECHANISM and
DATA ENTRY. Fixed menus are a set of DMS functions for user selection. Fixed
menus follow a tree hierarchy. Exit from a menu is by carriage return. Scroll
menus are continuously updated meta-data files of user defined entities such as
directories, files, milestones and events. A scroll menu has a menu title, a
page of twenty menu entries numbered from 0,1,..,9,A,B,..,J followed by
function keys for page scroll. The last page may not be full. A special case is
a new meta-data file with just one entry. This entry is automatically fetched
without entering a scroll menu. A scroll menu is displayed as:
0: Entry 1
...........
9: Entry 10
A: Entry 11
...........
J: Entry 20
Page m of n Exit=<Return>, Up=; Down=', [=Top, ]=Bottom, \=Find, /=Record:
Initially, page 1 is displayed. Pages are scrolled by function keys Up ; for
previous page, Down ' for next page, Top [ for first page, Bottom ] for last
page, Find \ prompts for search string. A successful Find \ scrolls to a page
that starts with an entry that conforms to user search string. Record /
prompts record number for random access. Random access record may be given as
an unsigned absolute record number or as a positive or as a negative offset.
Scroll to the desired page and press 0,1..,9,A,..,J to select an entry. In case
you do not want to select an entry, just press carriage return to exit. In
most cases you will have just one page of information and you do not need page
scroll function keys. Only in very rare cases are meta-data files so large that
you need Find \ or Record / keys. The selected entry is used by DMS for some
action, say entering a DMS directory or accessing a file.
DMS has a special mechanism for file access. In restricted user category modes
or when read-only access is selected, you access a file in VIEW mode with the
same function keys as with scroll menu except that there is no Record / key.
The VIEW mechanism is restricted to 80 column wide sequential ASCII files. User
category with update access to files has a special fixed menu of utilities for
file access called 'Editor .. Utilities Menu'. There are special DMS services
for expanding the set of available utilities. You are requested to document
each operation that affects the status of your files management system.
Examples of such operations are creation of a DMS directory and
add/delete/rename/update of a file. Date_time stamp, operation type and your
explanation are automatically appended to the configuration log project history
of a DMS directory.
Finally, Data Entry user interface is either by prompting for input line ended
by carriage return or by requesting a single key choice. Single key choices are
Yes/No (Y/N), type A to abort else continue, or type a number from a set of
three or four numbers.
Error in menu option selection causes a bell ring and an error message to be
displayed. Error count is maintained and available upon request or after exit
from DMS. Failure in selected DMS function sounds the alarm bell and displays
a message for 1.5 seconds after which DMS returns to parent menu preceding
function selection. Examples of function failures are DMS development phases
without entries or generation of an operating system command that cannot be
executed.
Help from any menu is available by H key; user manual section corresponding to
a given menu is accessed using the standard scroll menu mechanism. There is no
need for a user manual hardcopy during regular work with DMS.
The guiding principles of DMS user interface are standard ANSI I/O devices,
minimal user work load -- the number of key presses requested is the
theoretical minimum, help from any menu and no need for user to memorize DMS
use, and error handling with automatic recovery to the point preceding the
error.
^3 INVOCATION BY USER CATEGORY
The first DMS menu after invocation is to select user category
______________________________________________________
|Welcome to Development Management System DMS 5.mn |
|Copyright Ben Livson, 1987. All Rights Reserved. |
| |
|C - Creator of New DMS Directory |
|D - Developer |
|M - Manager |
|S - Software Quality Assurance |
|U - User |
| |
|? Select Option. <Return> = Exit from Menu |
------------------------------------------------------
Creator of new DMS directory adds a files management system directory to the
project tree of DMS directories. A DMS directory is a configuration item that
that has both meta-data and files covering the item life-cycle. Creator of a
DMS directory feeds DMS initialization and milestone data, decides, if the
default for automatic version control is accepted. If no DMS directory exists,
creator mode is automatically selected irrespective to user category.
Selection of a user category [Developer, Manager, SQA or User] invokes scroll
menu of existing DMS directories. Optional user category password is prompted
and given proper password, DMS enters the selected DMS directory.
Failure in DMS creation, invalid password and ordinary exit all cause DMS to
return to default directory prior to invocation.
The DMS allows four groups of users to have various types of access to parts of
DMS directories: 1) Developer, 2) Manager (Super User), 3) User, and 4)
Software Quality Assurance (abbreviated as SQA). The four DMS user group roles
are defined as: Developer may update all DMS directory files except SQA
information and DMS configuration log. The other user groups have read access,
and may receive and send mail. SQA has update access to SQA information. All
users may create configuration management forms (Software Problem Reports,
Change Proposals, and Requests for Deviations and Waivers), and set entry
password to a given DMS directory in their own mode. All user categories may
access operating system via DMS. Global display of DMS initialization and
milestone data is available to all users from any DMS directory. Manager has
special privileges to approve and update configuration milestone information.
Manager may initiate global operations affecting all DMSs. Mail to manager is
concentrated from all DMS directories.
Events like DMS creation or creation of configuration management form generate
automatic notification to manager and manager is given convenient access to any
DMS directory during a session. Manager may delete or rename DMS directories,
define global template files, define global file access utilities, and define
global entry or exit procedures to any DMS directory.
^4. Creating a New DMS Directory
Creation of a new DMS directory is invoked by DMS entry menu option [C]. The
special case of no DMS directory existing causes creator mode to bypass
selection of any other mode. Creation of a DMS directory is a process that
updates the list of DMS directories, determines as to whether the new DMS
directory is linked to automatic version control SMS or CMS, see appendix 6+7.
You are prompted to enter both initialization data and define the initial set
of milestones for the DMS directory. A new DMS directory is a self-contained
configuration item that is part of your project tree of configuration items.
The tree is translated to the directory tree of your operating system. Each
configuration item is a directory with meta data about the development of a
configuration item and the actual files forming the configuration item.
The dialogue for creating a new DMS directory:
[Type optional_path:directory optional_title]
Then the DMS directory to be created according to operating system rules is
displayed and you are prompted: [Type A to abort, else continue: ]. Next:
[C - DEC CMS Link; S - SMS Version Control; Else NO Control: ] DMS VAX/VMS
[Type A to Abort Automatic SMS Version Control: ] DMS PC
For a detailed explanation of the automatic SMS version control see appendix-6.
VAX/VMS DMS directory may be linked to DEC CMS alternatively, see appendix-7.
You may bypass version control, if performance considerations are critical.
Next you are prompted for DMS Initialization Data:
[Project Name]
[Developer surname and first name]
[Security Classication Number: ]
0=Unclassified, 1=Classified, 2=Secret, 3=Top Secret and 4=Yours
Number 4 prompts: [Enter your security classification name: ]
[Configuration Item Identification]
Entering accurate initialization data is important, because this data is
entered into DMS forms and print files.
If a global milestone template to be copied has not been defined by manager,
the next thing is to define milestones. A milestone may have any number of
deliverable items and a deliverable item may have any number of files. The DMS
makes a cross between milestone meta-data and your actual files system to
support project management. The background AI housekeeping functions analyze
the reasonableness of your software engineering process against milestone data.
It is worth defining your milestones in a careful way. The number of
milestones is not restricted. The four default milestones are: 1: Requirements
review, 2: Preliminary Design Review; 3: Critical Design Review and 4: Product
Release Review. You may define additional milestones or bypass the default
definitions. The four default milestones correspond to functional, allocated,
detailed and product baselines.
You are prompted either to accept default milestone or type your milestone.
For each milestone you are prompted to type target date in the MM-DD-YY format.
Example: Type 20 March 1991 as 03-20-91. For each milestone enter:
[Target Date: ]
[Deliverable Item. Exit by plain <Return>: ]
[File. Exit by plain <Return>: ]
[File. Exit by plain <Return>: ]
................................
................................
[File. Exit by plain <Return>: ]
[Deliverable Item. Exit by plain <Return>: ]
............................................
............................................
[Deliverable Item. Exit by plain <Return>: ]
Enter this information for each milestone, and exit by plain <Return>.
The last phase in the creation of a new DMS directory is to provide an optional
explanation about why the new DMS directory was created. This explanation is
entered via the DMS Editor .. Utilities Menu and is automatically appended to
the DMS configuration log. Date_time stamp and operation type are automatically
logged, in addition to your explanation, to be part of a complete project
history file.
^5. Main Menu
Entry: DMS menu is entered after selecting DMS user category, selecting a DMS
directory from a scroll menu of DMS directories, and entering password, if
requested. If there is only one DMS directory, it is automatically selected.
Optional new mail messages are displayed on entry to DMS. Developer, manager
and SQA automatically receive mail about anomaly report summary statistics,
creation of configuration management and SQA forms. Mail messages are displayed
only once and the mail text may be read by entering the DMS mail facility. DMS
manager receives mail upon entering the first DMS directory in a session and in
a concentrated way without having to enter other DMS directories. Automatic
entry procedure may be defined by DMS directory developer. Manager may define a
global DMS directory entry/exit procedure.
Exit: Exit from DMS main menu causes exit from DMS tool for developer, SQA and
user categories. Manager exits from DMS menu into the scroll of DMS
directories, and from there to the DMS entry menu of user categories, see 3.
Exit from DMS tool always causes directory default to be changed to the one
preceding DMS tool invocation. Exit from a DMS menu is by carriage return
unless otherwise mentioned.
Manual section 5 follows DMS main menu hierarchy. Submenu section titles are
marked by {from menu 5.x option y}.
______________________________________________________
| User Mode! Menu DMS Directory | Section
| |
|C - Configuration Management Functions | 5.1
| |
|R - Requirements | 5.2 Standard
|D - Design | 5.2 life-
|T - Testing | 5.2 cycle
|I - Implementation (Coding) | 5.2 paradigm
| |
|M - Management Information | 5.3.1
|S - SQA Information | 5.3.2
|A - Anything Allowed .. Prototyping | 5.2
|F - Facility for Mail | 5.3.3
| |
|L - Link to Operating System | 5.4.4
|G - Global Operation | 5.4.2 manager
|P - Print Menu. | 5.4.1
|V - Shared Read_Only Files | 5.4.3
|X - Special Services | 5.5
| |
|E - Exit with Housekeep | 5.6! developer
| |
|? - Select Option. <Return>= Exit from DMS Directory|
------------------------------------------------------
Options R, D, T and I are the default DMS life-cycle paradigm, see appendix-10,
and may be replaced by corporate 'D - Development .. Life-Cycle Paradigm' menu.
Option G for global operation is restricted to DMS manager.
^5.1. Configuration Management Functions {from main menu option C}
Observe: Configuration Management Services are joint for all DMS user
categories with the following restrictions:
- Backup to magnetic media option is restricted to developer and manager.
- Configuration management file delete/modify/update is restricted to developer.
Other categories may create and retrieve information about CM-forms and read
CM-files.
- User categories have different privileges in accessing configuration item
milestone services with manager being the only category with full privileges.
- Disable/Enable Automatic Version Control is restricted to developer.
Observe that all low level version control operations are automated by DMS.
Each operation that affects the status of files system is both logged in the
configuration log and automatically invokes the version control mechanism.
Appendix-6 documents the universal DMS automatic version control mechanism, and
appendix-7 details the optional automatic link to DEC CMS for the VAX/VMS DMS
version. Global DEC CMS baseline operation is restricted to manager.
DMS management information menu contains additional important CM information
such as table of contents, DMS directory table, global DMS information, test
cases-requirement correlation matrixes and anomalies report.
DMS Configuration Management Functions has the following submenu:
----------------------------------------------
| Configuration Management Functions |
| |
|A - Act Interface to MMS |
|B - Backup To Private Magnetic Media |
|C - Create Configuration Management Form |
|F - Configuration Management Files | 5.2
|L - Configuration Log |
|M - Milestones |
|Q - Query Configuration Management Forms |
|T - Time Dependent Events Control Facility |
|V - Enable/Disable Version Control |
|G - Global DEC CMS Baseline | manager only 5.1.9
| |
|? Select Menu Option. <Return> = Exit |
----------------------------------------------
^5.1.1. Act Interface to MMS {from CM-menu 5.1 option A}
Act interface to Make uses standard DMS file access that restricts non-owner
access to read access. The owner of make files is the DMS directory developer.
Thus, manager, SQA and user have read-only access to make files. Skip to the
next section, if you are not a DMS directory developer.
Act interfaces to UNIX Make and DEC MMS facilities to support preparation and
execution of description files for these utilities. Act interface menu offers
the standard DMS services, see 5.2, to Add file, copy template file, delete,
modify .. rename, read and update make files, and either fetch or view make
file versions. The unique act menu options are:
E - Edit Make .. Batch File
I - Invoke Make Processing
X - Validate Make File
Y - MMS Substitute Facility
Option E provides update access to act command procedure batch file that is
automatically executed as part of the DMS housekeeping functions invoked by
either by management information menu 5.3.1 update option U or main menu exit
5.6 option E. Anything that runs under your operating system command language
interpreter may defined as part of the Act batch file.
Option I spawns standard invocation of the UNIX Make or DEC MMS with
description file selected via the scroll menu interface. DMS PC version assumes
that the Make facility is the Make provided by Microsoft for the MS compilers.
Option X invokes make with options to display the last modification date of
each file as the file is scanned, and to display Make commands without
executing these commands.
Finally, option Y is restricted to the VAX/VMS DMS version and provides a
facility called Act that is similar to UNIX Make and DEC MMS. Skip to the next
section, if you are not using a VAX/VMS version of DMS.
The idea of Act facility is like with DEC/MMS or UNIX/Make to establish a
network of file revision date relations. An action part is executed in case
any pre_file has been revised after a post_file in a given Act. There may be
any number of pre_files, post_files and action DCL statements in a group, and
there may be any number of groups in Act file. A special Act group is the
case, when pre_file and post_file sections are empty. In such a case the
action part is always executed. Act file is always executed as part of DMS
housekeeping functions so that these special act groups can be used to execute
user defined housekeeping functions. It is possible to invoke Act during an
interactive DMS session. Act file is updated by standard edit/edt. Add ACT
Group (A) and Edit ACT file (D) cause automatic check of Act file validity.
There is also an option (C) for Act user to invoke Act file validity check.
Act facility has the following submenu:
------------------------------------------------------------------
| Welcome to Act Facility |
| |
|A - Add ACT Group |
|C - Check ACT file validity (checked in A & E options) |
|D - Edit ACT file |
|H - Help about ACT utility |
|I - Invoke ACT Processing (Included In Housekeeping Functions) |
|E - Exit To Parent Menu |
| |
|? - Select Option |
-----------------------------------------------------------------|
H-Selected:
-------------------------------------------------------
ACT Help (H): ACT file has groups. Each ACT group has:
PRE_files, POST_files & ACTION sections. ACT invocation
runs ACTION section as a DCL procedure, if any PRE_file
has been modified after any POST_file. In case no PRE_
file has been modified after latest revision of a POST_
file, then "No Act Procedure Is Invoked - All is O.K."
Prepare your ACTION section statements as $DCL command
or invoke procedures. Structure of ACT file for edit:
# - Start/End of Act Group followed by PRE_files, one
Filename.typ per line. End of PRE_files section is
marked by a percent sign "%" on a new line column 1.
ACTION statements lines with dollar "$" prefix follow.
Separator marks "#,%, and @" must be on new line col.1.
"Add ACT Group" user dialogue creates proper format.
ACT file syntax checked after editor access (D) option.
Special Case: No PRE_files and no POST_files --> Action
Act Group Example: PRE_files = list of source files.
POST_files = object files. ACTION = compile + link.
-------------------------------------------------------
A-Selected - Add ACT Group User Dialogue:
-------------------------------------------------------
Type PRE_files, one filename.typ per line.
---------
Exit by <RETURN> on column 1 on blank line
In case file does not exist/cannot be opened, then
X - Type Y to add this file, abort by any other key
Type POST_files, one filename.typ per line.
---------
Exit by <RETURN> on column 1 on blank line
In case file does not exist/cannot be opened, then
X - Type Y to add this file, abort by any other key
Type $DCL_statement for ACTION (don't forget $-prefix)
Exit by <Return> on blank line
? Do you want to add yet another ACT group (Y/N)
-------------------------------------------------------
Option C - Check Act file validity may produce output such as:
-------------------------------------------------------
Action Section Is empty
Nonexisting/Illegal/Locked File: kukuriku
Action $DCL_Statement $prefix missing
ACT file has 3 errors !!! To continue Hit Any Key
-------------------------------------------------------
These errors you must correct by editor (D option). You receive error
messages for any remaining errors after exit from editor.
Invoke Act processing (I option) causes a parallel subprocess to be created
without any wait for its completion. It is important to check that your act
process has completed successfully before exit from DMS. Act processing is
automatically invoked by safe exit with housekeeping functions.
^5.1.2. Backup to Private Magnetic Tape {from CM-menu 5.1 option B}
------------------------------------
| Magnetic Media Backup Services |
| |
|A - All DMS Backup | manager only
|C - Current DMS Backup *.*.* |
|T - Total Backup sys$login [...] | manager only
|L - List of Previous Backups |
| |
|? Select Option. <Return> = Exit|
------------------------------------
^5.1.3. Create Configuration Management Form {from CM-menu 5.1 option C}
Dialogue for creating a configuration management form:
[Type form title: ]
Then you are prompted:
[Type urgency: 1=Normal, 2=Urgent and 3=Immediate: ]
[Form Type: 1=Problem Report, 2=Change Proposal and 3=Waiver: ]
[Type Impact: 1=Major, 2=Medium and 3=Minor: ]
Fill CM_Form by selecting you favourite editor .. utility. A form layout is:
----------------------------------------------------------------------------
Project Name: DMS V5 version for IBM PC DOS "DMS Initialization Data"
Security Classification: Unclassified " - "
Configuration Identification: DMS/PC/V5 " - "
Title: "Your input"
File: [...newdmsv5]CM11.FRM "Automatically generated"
Created: 05-20-87 "System clock"
CM_Form Urgency: Normal "Your input"
CM_Form Type: Problem Report "Your input"
CM_Form Impact: Major "Your input"
----------------------------------------------------------------------------
"Fill in this part"
Problem Statement:
Problem Solution:
CM Directives:
CM Data, Procedures and Results Files:
Configuration Management Approval: No "Initial value"
----------------------------------------------------------------------------
All DMS forms start with DMS initialization header, user supplied title, date
and time, system generated file name for form followed by form body of
keywords. It is possible to change form body template. Customization of the DMS
tool is explained in appendix-5. Creation of a CM-form sends a a mail message
to developer, manager and SQA. Any DMS user category is allowed to create
CM-forms. The owner of CM-forms is the DMS directory developer. Project
integrator or configuration manager will transfer or take over DMS directories
with owner priveleges after initial development.
^5.1.4. Configuration Log {from CM-menu 5.1 option L}
Read Configuration Log can be accessed by any DMS user group by choosing the
L-option in the CM-menu. Then the DMS user automatically enters the log in
read-only mode. Each operation affecting the status of files management is
automatically logged with date and time stamp, operation type such as add,
delete, rename or update file, and optional user explanation. The process of
maintaining a project history is automatic and complete provided that you do
not bypass the DMS tool in the software process. Optional user explanation is
prompted for each operation affecting the status of the files system and the
standard editor .. utilities menu is entered to provide this explanation.
Example of log entry
_______________________________________________
|Update file DMS_V5.ATP 06-20-87 08:43|
|---------------------------------------------|
| ........... your explanation ........... |
-----------------------------------------------
^5.1.5. Milestones {from CM-menu 5.1 option M}
A key concept of DMS is to correlate project management data with the actual
status of the files system, and to analyze the reasonablenes of the software
process. Milestone data items maintained are:
Milestone number: Milestone name
Original Target Date: MM-DD-YY Revised Date: MM-DD-YY Defined By: User mode
Approvals! Developer: MM-DD-YY SQA: MM-DD-YY Manager: MM-DD-YY
Deliverable Item: Name
File: ...
File: ...
.........
File: ...
Deliverable Item: Name
......................
Deliverable Item: Name
File: ...
File: ...
.........
File: ...
----------------------
Next milestone data
The number of milestones is not limited. A milestone may have any number of
deliverable items, and a deliverable item may have any number of files. The
four default milestones are: 1: Requirements Review, 2: Preliminary Design
Review; 3: Critical Design Review and 4: Product Release Review.
Definition of milestones starts as part of DMS directory creation, see option T.
Milestone menu user category privileges are:
Privilege User Category(ies)
--------- ------------------
A - Approve Milestone Developer, SQA, Manager
C - Check Milestone Data Validity Developer, SQA, Manager
D - Define (Add) Milestone(s) Developer, SQA, Manager
R - Revise Milestone Target Date Developer, Manager
S - Show Milestone Information All categories
T - Template: Global Milestones Manager only
U - Update Milestone Information Manager only
Each user category has a menu according to the stated privileges. General user
enters directly to show milestone information, as this is the only privilege a
general user has.
A: Type a valid milestone number to approve a milestone. The same milestone
cannot be approved twice. Today is registered as date of approval. Approval by
developer, SQA, and manager in this order is required for each milestone prior
to revised target date, if there is a revised target date, or prior to original
target date, if there is no target date revision. Violations in the milestone
approval process are detected by the housekeeping functions including the
milestone menu C option.
C: Check milestone validity produces either a message "No Anomalies Detected"
or a list of anomalies. Anomalies in milestone data are possible due to
tampering of milestone data file, illegal update action by manager or in case a
filename.typ corresponding to a deliverable item does not exist. Anomalies
related to the reasonableness of the software process are listed in appendix-1.
D: Define (add) milestone(s) dialogue is explained at the end of section 4.
R: Revise milestone date prompts for milestone number, for revised date and
registers it.
S: Show milestone information displays milestones data one milestone at a time
using the standard scrolling menu interface.
T: Template for global milestones frees from data entry at DMS creation.
U: Update milestone information enables manager to update milestone data. The
options for updating milestone data are: Update line, delete line, and insert
line after a selected line. Certain milestone lines are critical and the
manager must type Y to proceed with the update of these lines. The structure of
the milestone data file is explained in appendix-5.
The milestones reported are written into DMS hardcopy, see main menu P-option.
Also, the milestones are displayed for the G-option in management information,
see 5.3.1. globally for any DMS directory requested.
^5.1.6. Query Configuration Management Forms
The options for querying configuration management forms, see 5.1.3, are:
---------------------------------------------------
Configuration Management Form Information Retrieval
D - Forms by Developer
G - Forms by General User
M - Forms by Manager
S - Forms by SQA
1 - Forms with major impact
2 - Forms with medium impact
3 - Forms with minor impact
C - Change Proposals
P - Problem Reports
W - Waivers and deviations
I - Immediate .. top urgent forms
U - Urgent forms
N - Forms with normal urgency
Y - Your search string
L - Link to operating system
? Select Option. <Return> = Exit from Menu
---------------------------------------------------
^5.1.7. Time Dependent Events Control Facility {from CM-menu 5.1 option T}
The idea of time dependent events control facility is to enable DMS user to
specify date_time for the the display of event messages or for the execution of
events as operating system commands or procedures. The implementation of the
events control control facility is specific to each operating system. The DMS
PC version has the minimum functionality:
------------------------------------------
Time Dependent Events
A - Add Event
D - Delete Event
I - Invoke Event Processing
M - Modify Event Information
R - Read Event
? Select Option. <Return> = Exit from Menu
------------------------------------------
Functions are restricted to developer. Other user categories
automatically enter read event list scroll menu.
A: Dialogue for adding event is
[Accept today as event date (Y/N): ]
[Type event date in MM-DD-YY format!] if not today
[Type event hour (0-23)]
[Type event minute (0-59)]
[Type event batch or DOS command]
D: Deleting an event
Select Event for Delete from a scroll menu of events
Type Y to approve:
I: Invoke event processing must be initiated by developer either by
option I of this menu or by invoking housekeeping functions. Events
after execution are deleted from the list of events.
M: Modifying an event
Select Event for Modify from a scroll menu of events
Event selected for modify: xxx
Type A to abort, else continue:
Type modified event:
DMS VAX/VMS version event processing is most sophisticated. The facility is
automatically invoked at login time. Events that relate to current date are
automatically executed. Outdated events are deleted from event list display,
but are retained in history file. Outdated events that failed to execute due
to any reason, say the user was not logged in or the computer failed, are added
to the list of failed events. It is possible to add events via a dialogue as
well as directly edit event list (for experienced users only). It is also
possible manually to invoke the event facility to spawn events defined during
the current session without having to wait until next login.
DMS VAX/VMS time dependent event control facility user menu options are:
------------------------------------------------------
|A - Add Time Dependent Event |
|D - Display Event List |
|F - Display Events that Failed to execute |
|G - Display Event Grand History File |
|S - Spawn Todays Events & Exit (auto spawn at login)|
|X - Edit Event List (for experienced users only) |
|E - Exit To Parent Menu |
------------------------------------------------------
Add (A) Time Dependent Event User Dialogue Is:
--------------------------------------------------------------
[? Do you want explanation (Y/N)]. If you answered Y (yes), then the following
explanation is displayed:
[Let us define time related event. Specify date_time.
Specify message to be displayed or anything that can
be executed under DCL at the specified date_time.
All events are stored in [basedir.DMS]events.doc and
subprocesses for todays events are created at login.
Events older than login date_time are deleted. Note:
The number of events for any given day must be less
your subprocess quota shown by show process/quotas!!
If your quota=8, say, specify at most 4 events for a
day in order to be able to create spare subprocesses
Example -- automatic calendar: An automatic calendar
message is displayed 5 & 2 minutes before event and
at event time. You may spawn procedure for execution
at given time, but use of such general purpose time
related events requires knowledge about how to work
with subprocesses (terminal I/O control).]
Hit <Return> to return. Else hit another key to continue:
Input event date
[? Do you want today (Y/N)]. If you answered N (no), then
Date format mmddyy. Example: Input October 9, 1986 as 100986
Escape back to input event date by pressing only <Return>
[ your date ]
Input event time: hours_minutes_seconds as hhmmss.
Thus, 9.45 o"clock is input as 094500 or 0945 .
Input five o"clock in the afternoon as 17 !
[ your time ]
[? Calendar event (y/n)]. If you answered Y (yes), then
type calendar message
Abort current event add by pressing <Return> on column 1
[your calendar message text]
------------------------------------------------------------
If you answered N (no), then
type procedure event, say @directory_path:myact.com
Abort current event add by pressing <Return> on column 1
[your procedure event]
------------------------------------------------------------
------------------------------------------------------------------------------
The facility checks date_time validity and requests user to correct invalid
date or time. Explanation of other 5.1.7 menu options:
D-option displays all events destined to be executed.
F-option displays all events that failed to execute.
H-option is the list of all events ever defined.
S-option spawns events defined for today and forces exit from DMS.
X-option enables experienced user to edit events file. If X-option is then the
user is prompted: Do you want event list structure explanation (Y/N) ? If the
answer is Y (yes), then the following is displayed:
Column 1: Y=Calendar event and N=DCL executable event
Column 2: #=spawned event and *=event already executed (don't touch)
Column 3-4: month as integer, say October is 10
Column 5-6: day of month as integer
Column 7-8: year as integer, say 85
Column 9: blank as separator
Column 10-11: hour as integer, say 16
Column 12-13: minute as integer, say 30
Column 14-15: second as integer, say 30
Column 16: blank as separator
Column 17-76: event text
^5.1.8. Disable/Enable Automatic Version Control
DMS directories may be created with the SMS automatic version control. Each DMS
operation that affects the state of the files management system causes an
automatic version control operation. Examples of such file operations are add,
delete, rename and update file, see 5.2. It is possible to disable version
control to save system resources for non critical DMS directories or for DMS
directories facing a short periods of very intensive changes, and after
stabilization to enable version control. Similar functions to disconnect or
reconnect a DMS to DEC CMS are available for the DMS VAX/VMS version.
^5.1.9. Baseline Generation
Automatic baseline generation is possible for the DMS VAX/VMS version using the
automatic link to DEC CMS, see appendix-7. Other DMS versions may generate a
baseline by backup of all DMS directories to magnetic media, see 5.1.2 option
A, or by transfering the DMS directory system to a protected computer. The
capability of fetching different baselines from the current DMS directory
system under the standard automatic version control is to be announced.
^5.2. Available File Operations
Main menu options R,D,T,I and A (requirements, design, testing, implementation
and prototyping) in DEVELOPER mode, configuration management files option F in
configuration management functions menu in developer mode , and main menu SQA
information option S in SQA mode invoke:
___________________________________________
|Parent menu selection title: xxxxxxx |
| |
|Available File Operations |
| |
|A - Add File |
|C - Copy Template |
|D - Delete File |
|F - Fetch File Version |
|M - Modify File Information..Rename File |
|R - Read File |
|U - Update File |
|V - View File Version |
| |
|? - Select option. <Return> = Exit |
-------------------------------------------
All other user modes are restricted to the read file operation and
automatically invoke this operation.
All file operations with the exception of add invoke the scroll menu interface
to the DMS phase or section. Example: DMS main menu requirements R selection
causes any of the above file operations, except add, to access the scroll menu
of DMS directory requirements files. The requested operation is then performed
on the file selected.
File operations add, delete, rename and update change the state of the files
management system and cause DMS to invoke automatic version control and to
update configuration log, see 5.1.4 and appendix-6. This process is completely
automatic except that DMS user is entered to the editor .. utilities menu to
provide an optional explanation about the invoked operation.
In case VAX/VMS DMS has been created with automatic link to DEC CMS, then
add/delete/modify/update operations generate and execute CMS commands
automatically to synchronize between DMS and CMS. Automatic link between DMS
directory and AVC and DEC CMS tools are explained in appendices 6 and 7.
Create test, configuration management and SQA forms are special cases of the
add file operation.
File operations are presented as follows:
5.2.1 Add File
5.2.2 Copy . Delete . Modify . Read . Update File
5.2.3 Fetch Version and View Version
5.2.4 Mechanisms for File Operations
Mechanisms for file operations provide information about life-cycle
enforcement, file encryption, file titles, use of editors .. utilities via
DMS, and about anomalies report that states discrepancies between physical
files and DMS file meta-information.
Shared files are explained in 5.4.3.
^5.2.1. Add File {from available file operations menu 5.2 option A}
To add a file select option [A]. The system responds:
__________________________________________________
|Type Optional_path:filename.type optional-title|
|________________________________________________|
Type the file be added to the meta-data of your DMS directory. The default
path is the DMS directory for the physical file to be added. You are entered
into the editor .. utilities menu to create or at least confirm the existence
of this file. File add is rejected, if file the does not exist, or it is a
duplicate entry to DMS directory meta-data, or life-cycle violation is
attempted. Thus, design, testing and implementation files may not precede
requirements .. life-cycle enforcement is explained in 5.2.4. Note that it is
valid to add the same file to more than one DMS phase. Thus, requirements and
testing may share the same file. Sharing of files across DMS directory
boundaries is supported, see 5.4.3 for data sharing information. The optional
file title helps manager, SQA and user modes to fetch the right file for
reading. Titles are entered to DMS table of contents and print files.
Next you are prompted:
______________________________________________
|Do you want file encryption (Y/N), else No: |
----------------------------------------------
Entering [Y] or [y] signifies encryption. Any other key mey means that
encryption is not wanted. Encrypted files are not entered in print file. Thus,
it is important to mark as encrypted executable images .. files that are only
machine readable. Actual encryption facilities must be provided by your
organization to be invoked via the editor .. utilities menu.
DMS VAX/VMS directory linked to DEC CMS prompts for the file to be added:
________________________________________
|Do you want CMS link (Y/N), else Yes: |
----------------------------------------
The optional automatic link to DEC CMS is explained in appendix-7.
Create DMS form is a special case of file add. Configuration management forms
were presented in 5.1.3, SQA forms in 5.3.2, and testing forms follow:
Software Testing Menu (ANSI/IEEE Std 829-1983)
1 - Test Plan
2 - Test-Design Specification
3 - Test-Case Specification
4 - Test-Procedure Specification
5 - Test-Item Transmittal Report
6 - Test Log
7 - Test-Incident Report
8 - Test-Summary Report
These options are followed by the options for standard file operations. Each
test form is automatically created as file TESTn.FRM with default title as
above. You are prompted for additional title information. Forms are entered as
files not encrypted. A form always has a header generated from DMS
initialization data and a body of keywords depending on form type. Test case
specification [option 3] is given as an example:
Requirement Number: R.1,R2.3,R2.4
Project Name: DMS V5 version for IBM PC DOS
Security Classification: Classified
Configuration Identification: DMS/PC/V5
Title: Test-Case Specification
File: [...newdmsv5]TEST8.FRM
Created: 02-27-87 10:23:48
Creator: Developer
Software Test_Case Specification (ANSI/IEEE Std 829-1983)
CONTENTS
1. Test-case-specification identifier
2. Test items
3. Input specifications
4. Output specifications
5. Environmental needs
5.1 Hardware
5.2 Software
5.3 Other
6. Special procedural requirements
7. Interface dependencies
Requirement number (may be alphanumeric) is prompted at test case creation time
and is a list of requirements covered by the test case. Use comma as
requirements separator in this list.
The test case - requirement and requirement - test case matrixes are updated
each time housekeeping functions are invoked. See appendix-1 for these
matrixes.
Finally, add file causes the standard configuration management mechanisms to be
invoked as with any file operation that changes the status of the files
management system.
^5.2.2 Copy . Delete . Modify . Read . Update File {5.2 options C,D,M,R and U}
C: Copy template searches dms_path installation templates for the selected DMS
phase. Ready template files covering military standards are planned for future
DMS releases. Also, template files may be created at organizational or project
level by DMS manager, see DMS special services 5.5. Copy template is an interim
operation usually preceding add or update file operations. The template
selected is copied into DMS directory. DMS meta-data is not affected and
configuration management operations are not invoked by copy template operation.
D: Delete file requests confirmation for the file selected for delete from the
scroll menu of files of the given DMS directory. Standard configuration
management operations are invoked, and the file is deleted both from meta data
and as a physical file.
M: Modify File Information .. Rename File
The modify operation enables changing of file meta-data or renaming of the
physical file. File name, title, encryption status [and optional VAX/VMS DMS
link to DEC CMS] may be viewed and changed by the modify operation. Thus,
modify is the means for correcting any errors inserted during add. You may just
view file information or selectively modify any item of information. Update of
configuration log, optional file rename, and optional file CMS status change
are automatically executed by configuration management process.
R and U: Read .. Update File
To read .. update an existing DMS file select [R] .. [U] in the Available File
Operations menu, respectively. After selecting the file to be read .. updated,
the user selects any editor or utility listed in section 5.2.4.4. Standard
configuration management services are automatically invoked in case of file
update.
^5.2.3 Fetch Version and View Version
DMS directories linked to Automatic Version Control, see appendix-6, enable
both viewing fetching of previous file versions. The process starts by
selecting a file from the scroll menu of the given DMS phase. The scroll menu
of the versions of the selected file is entered. Fetch version operation copies
the selected file version into the DMS directory, whereas the view operation
provides read-only access of the selected file version. Fetching of the file
version is supported by date-time stamps, configuration log explanations, see
5.1.4, and by viewing of versions. The optional VAX/VMS DMS link to DEC CMS
provides a similar mechanism for fetching file versions, see appendix-7.
^5.2.4 Mechanisms for File Operations
^5.2.4.1. Life-Cycle Enforcement
Adding of a file to a DMS life-cycle phase is prevented and an error message is
displayed in case of life-cycle violation:
You cannot deal with Design without Requirements
You cannot deal with Testing without Requirements
You cannot deal with Implementation unless Requirements, Design
and Testing are included.
Life-cycle anomalies with milestone data are listed in appendix-1. DMS main
menu option A 'Anything Allowed .. Prototyping' bypasses the waterfall
life-cycle paradigm. DMS PARADIGM DEFINITION FACILITY, APPENDIX-10, ENABLES YOU
DEFINE CORPORATE LIFE-CYCLE PARADIGM WITH YOUR RULES OF LIFE-CYCLE ENFORCEMENT!
^5.2.4.2. DMS File Encryption
The user may designate a DMS file as encrypted. It is the sole responsibility
of the DMS user to provide the actual encryption service. The DMS tool does
not include encrypted files into DMS hardcopy.
Observe: The user may include in DMS object files or executable images. These
file shall be designated as encrypted so that they will not be printed as part
of the DMS hardcopy.
^5.2.4.3. DMS File Title Information
The user should provide a carefully worded title about a file entry. Each time
housekeeping functions are invoked, the table of contents is updated. Title
documentation is part of DMS print file and helps manager, SQA and user in read
access of DMS files.
^5.2.4.4. Editor .. Utilities Menu
Update and add file operations, and request for configuration management
explanation provide access to the editor .. utilities menu. The menu has a
number of standard utilities as applicable to the DMS operating system version.
These options are followed by utility invocation names defined by manager
globally for all DMS directories and utility invocation names defined by DMS
directory developer, see special services 5.5 for defining file access
utilities. The maximum number of options per editor .. utilities menu is twenty
(full screen). The idea is to access a file by a single key. The standard
options for accessing operating system and for on-the-fly user defined utility
permit file access by any utility available.
The standard editor .. utilities menu for DMS VAX/VMS version is:
---------------------------------------
|EDITOR .. UTILITIES MENU. File: |
| |
|1 - Access to DCL |
|2 - Standard Edit/Edt |
|3 - TPU Eve Editor |
|4 - Language Sensitive Editor LSE |
|5 - User Defined Editor .. Utility |
|6 - View File |
|7 - Type/page |
| |
|? - Select Option. Exit = <Return> |
---------------------------------------
The standard editor .. utilities menu for DMS PC DOS version is:
---------------------------------------
|EDITOR .. UTILITIES MENU. File: |
| |
|1 - Interface to DOS |
|2 - Edlin |
|3 - User Defined Editor .. Utility |
|4 - View File |
|5 - Type file | more |
| |
|? - Select Option. Exit = <Return> |
---------------------------------------
^5.2.4.5 DMS Anomalies Report
Housekeeping functions update DMS anomalies report that lists discrepancies
between meta-data and file system. Developer, SQA and manager receive mail with
anomaly statistics, if any anomaly is observed. Management information menu [A]
option gives read access to anomalies report. Developer menu [E] and
developer/SQA/manager mode management information menu [U] option submit house
keeping functions into batch. See appendix-1 about anomalies report format.
^5.3. DMS Information Menu Options
Reference: Main Menu Options M,S, and F covering management information, SQA
information, anything allowed .. protyping, and facility for mail respectively.
^5.3.1. Management Information {from main menu 5 option M}
___________________________________
| DMS Management Information |
| |
|A - Anomalies Report |
|C - Read Table of Contents |
|D - Read Directory Table |
|G - Read Global Information |
|P - Project Management Plan | Update by Manager
|S - Session Information | Errors .. Time
|T - Read Test Coverage Table |
|U - Update Management Information| Developer, SQA and manager
| |
|? - Select Option. Exit=<Return> |
| |
|Update: DD-MMM-YY HH:MM |
-----------------------------------
Management information A,C,D,T is updated by DMS housekeeper functions that are
invoked by update option [U] or main menu option [E]. Appendix-1 presents an
example of "Table of Contents", "Directory Table", "Test Coverage Table" and
"Anomalies Report". Date-time stamp of last update is displayed. The access to
management information is read-only view access. Table of contents [C]
organizes DMS meta-data about files and file titles according to DMS phases.
Directory table [D] is a cross between DMS directory data and DMS phase
meta-data. Global information [G] provides DMS initialization and milestone
data for DMS directories. You may escape display of this information or skip
display of milestone data for any DMS directory. Session information and exit
from DMS display session login and logout time, and the number of session
errors. Test coverage table [T] shows test cases - requirement and
requirements - test case matrixes.
^5.3.2 SQA Information {from main menu 5 option S}
---------------------------------------------------------
SQA Information Menu
0 - Verification and Validation Plan (IEEE Std 1012-1986)
1 - SQA Plan (IEEE Std 730-1984)
2 - CM Plan (IEEE Std 828-1983)
3 - SQA Checklist
A - Add File
C - Copy Template
D - Delete File
F - Fetch File Version
M - Modify Information .. Rename File
R - Read File
U - Update File
V - View File Version
? Select Option. <Return> = Exit from Menu
---------------------------------------------------------
Manager, developer and user have read-only access to SQA information. Options
A -- V are standard file operations, see 5.2.
Initial selection of options 0-3 causes the respective SQA templates to be
created. In case your company does not follow IEEE standards you may create
your company templates, see appendix-5 III SQA template file list. Subsequent
selection of 0-3 are treated as update operations of the corresponding files.
Developer and manager receive mail messages about initialization of 0-3. SQA
templates 0-3 have DMS initialization data as header. SQA checklist [3] is
given as an example:
Project Name: DMS V5 version for VAX/VMS
Security Classification: Classified
Configuration Identification: DMS/VAX/VMS/V5
Title: CHECK.SQA Software Quality Assurance Check List
File: [...newdmsv5]CHECK.SQA
Created: 02-23-87 18:49:12
Creator: Software Quality Assurance
Software Quality Assurance Engineer:
SQA AUDIT CHECKLIST
State Yes/No for the correctness of:
No: Criteria : Y/N
------------------------------------------------------------------------
DMS Development Phases
----------------------
1. Requirements :
1.1 Functional Requirements :
1.1.1 Inputs/Processing/Outputs :
1.1.2 User/Hardware/Software/Communication Interfaces :
1.1.3 Constraints & Error Handling :
1.2 Performance Requirements :
1.3 Attributes (Security, Maintainability) :
1.4 Other Requirements (Data Base, Operations, Site Adaption) :
1.5 Characteristics of Good Software Requirements :
1.5.1 Complete :
1.5.2 Verifiable :
1.5.3 Consistent :
1.5.4 Modifiable :
1.5.5 Traceable :
1.5.6 Useable During The Operation and Maintenance Phase :
1.6 Standards Compliance (IEEE Std 830-1984) :
2. Design -- Characteristics of Good Design :
2.1 Identification of required resources :
2.2 A baseline for configuration control :
2.3 Means of assessing the impact of requirements changes :
2.4 Means of verifying requirements compliance :
2.5 Means of facilitating maintenance activities :
2.6 A formal description to generate test specifications :
2.7 A baseline design from which to program :
2.8 Means of measuring and quantifying design complexity :
2.9 Rationale of design choices :
2.10 Complies to IEEE Std 1016-1987 :
3. Testing
Conformance to IEEE Std 829-1983 for Software Test Documentation:
Conformance to IEEE Std 1008-1987 for Software Unit Testing :
3.1 Test Plan :
3.2 Test-Design Specification :
3.3 Test-Case Specification :
3.4 Test-Procedure Specification :
3.5 Test-Item Transmittal Report :
3.6 Test Log :
3.7 Test-Incident Report :
3.8 Test-Summary Report :
4. Good Programming Characteristics:
4.1 Top Down Programming :
4.2 Modular Programming (unit size 1-2 pages) :
4.3 Structured Programming :
4.4 Strong Typing Enforced :
4.5 Use of High Level Standard Language :
4.6 Information Hiding (package .. body) :
4.7 Low Program Unit Complexity (McCabe cyclomatic measure<=10):
4.8 Programming Readable/Documentation Sufficient :
4.9 Each Program Unit Implements Single Function :
4.10 No Side-effect Communication Between Program Units :
5. Standards Compliance of User Documentation IEEE Std 1063-1988 :
6. Conforms to Software Quality Assurance Plan, IEEE Std 730-1984 :
7. Conforms to Configuration Management Plan, IEEE Std 828-1983 :
8. Software Verification and Validation Plans, IEEE Std 1012-1986 :
9. Conforms to Software Reviews and Audits Draft Standard, IEEE P1028:
10: IEEE Std 982-1988 Used for Measures to Produce Reliable Software:
11. IEEE P1061 Standard for Software Quality Metrics Analysis :
12. IEEE Std 1058-1988 for Software Project Management Plans :
13. IEEE Std 1044-1988 Classification for Software Errors ... :
^5.3.3. Mail Facility {from main menu 5 option F}
------------------------------------------
DMS Mail Menu
B - Broadcast public mail
C - Read mail catalog
D - Send mail to developer
M - Send mail to manager
P - Read public mail/Free Section
R - Read your mail
S - Send mail to SQA
T - Transmit mail
U - Send mail to user
Send mail options B/D/M/S/U may be
toggled ON/OFF until T is selected.
ON is displayed in reversed video.
? Select Option. <Return> = Exit from Menu
------------------------------------------
New mail messages are displayed at DMS entry. Messages are read by accessing
mail catalog [C] option. Mail messages are sent to user categories according to
send mail A/B/M/S/U combination selected. Broadcast B causes message to be
sent to all users. Manager receives upon entry to any DMS all messages sent
from any DMS. Other users receive messages related to a given DMS. Messages
are ordered chronologically with date_time stamp, sender category, DMS name in
case option M was selected, and mail title. Select [R] to read your mail. DMS
directory creation, configuration management and SQA form creation causes
automatic mail to be sent SQA manager, developer and SQA as applicable.
^5.4. DMS Services
Reference: Main Menu Options P,G,V covering Print Menu, Global operation by
manager, and shared read-only files.
^5.4.1. Print Menu {from main menu 5 option P}
-----------------------------------------------------------
| Print Functions Menu |
| |
|A - Abort Print Function Menu! |
|C - Convert to Hebrew |
|D - Development Phases Selected |
|E - Edit Print Files List |
|H - Insert Header and Pagination |
|P - Print Hardcopy |
|S - Selection of All Options 0-9 |
|X - Show Encryption Status of Files |
| |
|0 - Management Information |
|1 - Configuration Management Files |
|2 - Development Phase: Requirements |
|3 - Development Phase: Design |
|4 - Development Phase: Testing |
|5 - Development Phase: Implementation |
|6 - Software Quality Assurance Data |
|7 - Public Mail/Free Section |
|8 - Anything Allowed .. Prototyping |
|9 - Configuration Log .. Milestones |
| |
|Toggle Options ON/OFF. ON = Reversed Video. |
| |
|? Select Option. <Return> = Invoke Print |
-----------------------------------------------------------
Upon initial entry to print functions all options are OFF. Each key press
toggles option ON/OFF until <Return> is pressed. Options ON are displayed in
reversed video. Key D and S are multifunction keys. In option [C] all text
created by the DMS tool is converted to UPPER case English. In edit [E] option
it is possible to delete or add files to be printed or change the order of
files to be printed. Encrypted files are not printed. Encrypted files are
displayed by option X. Options 2-5 are replaceable by your life-cycle paradigm.
Anything that starts with a blank in column one in the list of print files
edited is treated as a comment. Option [A] paginates from the start of each
file with page number and file name as header. Option [P] invokes default
printer. It is recommended not to select [P] unless you have previously checked
print file print.DMS.
VAX/VMS DMS version may have more than one print job running in parallel with
different print options. Confirmation by <Return> starts a batch job that
creates print file print.DMS. Given [P] option this file is queued to printer.
A user is notified about completion of the batch job. File print.log is listed
under sys$login.
Print file print.DMS is composed of:
- DMS Initialization Data
- List of Print Options Selected
- List of Print Files according to DMS sections selected
- List of Nonexisting/Invalid Files if any
- Listing of each DMS phase selected
^5.4.2. Global Operation By DMS Manager {from main menu 5 option G}
DMS manager may define any operation, say running an image or procedure
invocation, and this operation is executed in batch for all DMS directories.
^5.4.3. Shared Files
DMS development phases .. sections may share files. Different DMS directories
may share files. DMS developer may define both read-shared and write-shared
files. Read-shared files, see DMS main menu 5 option V, definition is strictly
logical. No physical is created or updated. Developer shared file add, delete
and modify .. rename operations affect meta-data of read-shared files, but do
not affect physical files. All user categories have read access to shared
files. Shared files external to DMS are neither entered in DMS directory table
nor listed in DMS print file, but shared files are listed in DMS table of
contents, see appendix-1. DMS developer defines write-shared files via the add
file function, see 5.2.1, in which case DMS developer may create and update
these files.
^5.4.4 Link To Operating System {Main menu 5 option L}
Link to operating system enables execution of operating system commands in a
loop terminated by idle <Return>: Type command. <Return>=Exit
DMS VAX/VMS version brings DMS parameters to DCL:
Use parameters in DCL commands with apostrophe. Example: edit 'p1.
Exit by ctrl/y. Read user manual appendix-4 for DMS development utilities.
File is parameter P1 = optional parameter-1 value
CMS group for DMS is parameter P2 = optional parameter-2 value
CMS library for DMS is parameter P3 = optional parameter-3 value
Your directory is: ]
Ignore message "%DCL-I-SUPERSEDE, previous value of SYS$INPUT has been
superseded" that results from dms_path:dcl.com interface procedure.
^5.5 Special Services
___________________________________________
Special Services Menu
A - Add to DMS Utilities
D - Delete DMS Directory manager
E - Entry DMS Batch Procedure developer
G - Global Entry DMS Batch Procedure manager
I - Initialization Data developer
L - Life-Cycle Paradigm See Appendix-10 ! manager
M - Meta-data Maintenance manager
P - Password Update
R - Rename DMS Directory manager
T - Templates manager
U - User Manual
V - View DMS Demonstration and Information
X - Define .. Update Global Housekeep Batch manager
? Select Option. <Return> = Exit from Menu
-------------------------------------------
A: Add to DMS utilities enables up to fourteen (14) utilities to be added to
the DMS editor .. utilities menu. Add in manager mode causes global add of a
utility for all DMS directories. In other modes the utility invocation name
added is restricted to the current DMS directory.
D: Manager selects DMS directory to be deleted from the scroll menu of DMS
directories. After confirmation the DMS directory is deleted both physically
and from meta-data.
E: Developer may define or update via the editor .. utilities interface a batch
command procedure executed upon entry to the current DMS directory.
G: Manager may define or update via the editor .. utilities interface a batch
command procedure executed globally upon entry to any DMS directory.
I: Developer may update DMS directory initialization data. Other user modes may
view DMS initialization data. See section 4 about initialization data.
M: Manager may add/delete/modify/read records in direct access meta-data files,
export to and import from sequential file, and fix list of DMS directories.
P: Password initialization and update is separate for each user mode. The idea
is that the password of a user category belongs to the person who captures it
first. Passwords are encrypted. Confirmation of existing password, if it
exists, is requested. New or updated password is accepted only after
verification.
R: Manager selects DMS directory to be renamed from the scroll menu of DMS
directories. After confirmation manager enters the new DMS directory path.
Old directory is not deleted as a safety measure!
T: Templates update is restricted to manager. Other categories may view
templates. Each DMS phase may have templates. Select template phase. If you are
not a manager, select from the scroll menu of templates a template for
read-only viewing. A manager may add, delete, rename and update a template.
Templates are joint for all DMS directories. Typical examples are templates for
organizational or military standards.
U: On-line user manual is accessed in read-only view mode.
V: DMS_DEMO product information and demonstration is invoked, see 6.4.
X: Manager may define or update a global housekeeping procedure for all DMS
directories via the editor .. utilities interface.
^5.6. Housekeeping Functions {from main menu option [E] and management menu [U]
The following housekeeping functions are provided:
- Update Table of Contents, See Appendix-1.
- Update Directory Table, See Appendix-1.
- Update Test Cases - Requirement Compatibility Table,
and the reversed Requirements - Test Case Table, see appendix-1.
- Update Anomalies Report, See Appendix-1.
- Optional developer defined exit batch, see 5.1.1 option E.
- Optional manager defined global exit batch, see 5.5 X-option.
Housekeeping functions are invoked by main menu exit option [E] and management
information menu update option [U].
^6. THE DMS TOOL NOTES
^6.1. Security
Security depends on the local arrangements of your computer system (privileges,
directory path and file protection, access list, encryption .. arrangements).
DMS secure environment option with file \dms_path\secure.env enforces passwords
prevents User mode from entry at operating system level, and restricts creation
mode to manager.
^6.2. Safety
The DMS tool is strongly oriented to providing maximum work safety. Problems
start only when a DMS user accesses directly the DMS subdirectory and not via
the DMS tool. It is pointed out that the DMS password mechanism has nothing to
do with security but is just another work safety mechanism. It is stressed
that proper DMS tool usage is possible only on a voluntary basis. There is no
difficulty for a hostile user to break life-cycle controls or to tamper with
the configuration log and so on. The reason for this situation is that the DMS
tool allows user access to the operating system. Thus, there is little use in
placing a system level automatic login procedure to the DMS tool.
^6.3. Corruption of DMS Meta-information
Tampering of DMS meta-data may be caused by direct access to DMS directories
bypassing the DMS tool. DMS anomalies report, see 5.2.4.5, results from safe
exit with housekeeping functions. However, the housekeeping functions detect
only certain types of meta-data corruption, see appendix-3. The consequences of
bypassing the DMS tool may be severe/difficult to detect/difficult to repair.
See 5.5 meta-data maintenance option M that invokes dms_path:direct utility.
^6.4 DMS Demonstration and Product Information
DMS demonstration and product information is accessed via special services menu
option V or by separate dms_demo invocation from operating system level. The
following demonstration and information menu is then invoked:
______________________________________________
DMS Product Demonstration And Information V5.2
Copyright and License Information by Option R.
A - Advanced Application Generator User's Manual
B - Ben Livson's Biography
C - Continuous Display Window Demonstration
D - Development Management System DEMONSTRATION
E - EduSET Educational Software Engineering Tool
F - Future Year 2000 DMS [ACM SIGSOFT July 1987]
G - Grand Evolution .. DMS History
I - ICSE-9 Tools Track Presentation
L - Ultraware Product Licensing
M - DMS User's Manual Subset
O - Development Management System Overview
P - Primary DMS Features
R - Readme! Product Diskette Information
S - Software Engineering CASE and DMS Review
T - Training Course Syllabus
V - Software Development Paradigms Versus DMS
U - Ultraware Corporate Overview.
? Select Option. <Return> = Exit from Menu[0m
----------------------------------------------------
^6.5. Performance
Heavy processing such as housekeeping functions, print file creation, DMS link
to DEC CMS, global DEC CMS baseline of DMS is submitted to batch for the
VAX/VMS DMS version. DMS MS DOS version does not support batch background
processing . DMS meta-data organization is such that almost all operations run
as fast no matter how large the files management system under DMS control.
Thus, for most DMS functions a personnal computer such as IBM PC/AT offers
excellent performance. Spawning of version control subprocesses for VAX/VMS DMS
version is a slows down very rapid changes in files. Version control is may be
disabled, although version control is strongly recommended.
^6.6. Operating System Implementation Differences
DMS operating system implementation differences are hidden to the user to the
maximal possible extent. Both user interface and DMS meta-data is identical for
all DMS systems. DMS VAX/VMS version ACT facility 5.1.1 and and Event Control
Facility 5.1.7 extensions have not been implemented for other versions. Also,
the optional link between DMS and DEC CMS is unique for the DMS VAX/VMS
version. However, this does not mean that similar features could not be
implemented for other operating systems. Neither does this mean that DMS
VAX/VMS version is drastically more advanced than DMS versions for other
operating systems.
^Appendix-1 TABLES: Content, Directory, Test & Anomalies
Update: 23-Jun-87 14:22
Example: Table of Contents
----- -- --------
Filename.typ Title
------------ -----
Configuration Management Files
------------- ---------- -----
...............................................................................
Requirements Files
------------ -----
DMSV5 Version 5 DMS Requirements Specification
...............................................................................
Design Files
------ -----
...............................................................................
Testing Files ! contents example follows
------- -----
DMS.SPR Computerized DMS Software Performance Reports
TEST1.FRM Test_Unit_DMS_MAIN_MENUS
TEST2.FRM Test_Unit_Print_Function
...............................................................................
Coding .. Implementation Files
------------------------ -----
...............................................................................
SQA Files
--- -----
...............................................................................
Anything Allowed .. Prototyping Files
-------------------------------------
...............................................................................
Example: Directory Table
filename type size last update DMS Phase or Section
..................................................................
PLAN SQA 3119 5-17-87 7:47p Software Quality Assurance
TEST2 FRM 758 6-01-87 11:34a Testing
..................................................................
Cumulative Number and Size of Files !DEPENDS ON LIFE-CYCLE PRADIGM!
Size of requirements files: xa units ya.a%
Size of design files: xb units yb.b%
Size of testing files: xc units yc.c%
Size of implementation files: xd units yd.d%
Size of software quality assurance files: xe units ye.e%
Size of configuration management files: xf units yf.f%
Size of anything allowed .. prototyping files: xg units yg.g%
Note: DMS directory table format depends on operating system implementation.
Thus, for instance VAX/VMS units are blocks of 512 bytes and MS DOS units are
bytes. Also, the format and information content varies: VAX/VMS directory data
includes information about creation, update and backup dates. The above example
is for MS DOS. The important feature, however, is that DMS directory table
includes directory data only for files created via DMS tool. Data about
internal DMS meta-data files is not displayed.
Automatic Test Cases - Requirement Compatibility Form
Test Requirement Number
---- ----------- ------
1 3(3.1-3.7),5(5.1-5.3),7.1,7.2
2 7
3 7.2,9,10
......................................
10 ??? Not Recorded
Reversed Requirements - Test Case Table
----------------------------------------
Req-Id: 3(3.1-3.7)
Test-Id: 1
.........................................
Req-Id: ??? Not Recorded
Test-Id: 10
NOTE: Requirements in a test case form have to be separated by COMMA !!
Anomalies Report TO CONTROL ANOMALIES, SEE \DMS_PATH\ANOMALY.DOC
----------------
Total number of anomalies: Mailed to manager, developer & SQA
Anomalies List
--------------
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 msn
Warning: Overdue Manager Approval of milestone msno
Error: SQA approval of Milestone msno without SQA plan!
Warning: SQA approval of Milestone msno without CM plan!
Error: SQA approval of Milestone msno without Requirements!
Error: SQA approval of Milestone msno without Design!
Error: SQA approval of Milestone msno without Testing!
Error: Manager approval of Milestone msno without Requirements!
Error: Manager approval of Milestone msno without Design!
Error: Manager approval of Milestone msno without Testing!
Error: No SQA approval of Milestone 1!
Error: No Manager approval of Milestone 1!
Error: No SQA approval of Milestone 2!
Error: No Manager approval of Milestone 2!
Warning: No SQA approval of Milestone 3!
Warning: No Manager approval of Milestone 3!
Nonexisting milestone file: xxx
Illegal milestone data line syntax: xxx
--------------------------------------------------------------------
List of act file anomalies: ! syntax check - DMS VAX/VMS Version Only!
Error: ACT File Must Begin With #
Error: Second..Group # Must Be Preceded by @
Error: Action Section Is Empty
Error: Post SECTION % Must Be Preceded by #
Error: Action Section @ Must Be Preceded by %
Error: Nonexisting Act File:
Error: Action $DCL_Statement $prefix missing
Error: Action Section Is Empty
^Appendix-2. Abbreviations .. Trademarks Used
AI - Artificial Intelligence
ANSI - American National Standards Institute
AVC - Automatic Version Control
CM - Configuration Management
CMS - DEC Code Management System
DCL - DEC Command Language
DEC - Digital Equipment Corporation
DMS - Development Management System
DOS - Disk Operating System: MS DOS or IBM DOS
EVE - DEC Extensible VAX Editor
IBM - International Business Machines
IEEE - Institute for Electric and Electronic Engineers
LSE - DEC Language Sensitive Editor
MMS - DEC Module Management System
MS - Microsoft Corporation. Used for MS DOS and IBM DOS
SCM - Software Configuration Management
SMS - Stores Management System: DMS alternative to CMS
SQA - Software Quality Assurance
TPU - DEC Text Processing Utility
UNIX - AT&T Bell Lab's Operating System (tm)
VAX - DEC Computer Series
VMS - Virtual Memory System = VAX Operating System
^Appendix-3. Error Messages And Corrective Actions
Create a problem report, preferably by using the DMS create configuration
management form function, see 5.1.3. Try to capture your DMS session as
complete as possible including input/output. Copy your DMS directory. Send the
complete material on magnetic media to Ultraware Ltd. The following description
refers to DMS VAX/VMS version. Use as applicable:
Problem Reporting: $Set Host/Log=DMS.Session, login, $set verify, invoke DMS &
try to repeat your problem !!! Exit from DMS, record your environment by $show
process/all, $show system, $show memory, $show device, $show quota/disk, $show
logical, $show symbol/global/all, $show symbol/local/all, and $show default.
Logout. Set default to your DMS directory and record $dir/full/output=dir.lst.
Backup files DMS.Session, your DMS subdirectory, all global DMS directory files
in sys$login subdirectory [.DMS], and log files hkeep.log, print.log, dcljb.log
,CMSDMS.log and global.log under sys$login as applicable into save_set
my.problem. Try to record any additional information in case you had a problem
with the ACT or AT facilities as explained in sections 5.1.2 and 5.1.7. Send
the save set on a magnetic tape .. media to DMS developer. In case your
installation has customized the DMS tool, see appendix-5, then you should try
to repeat the problem by using the original DMS tool to be sure that the
problem is not related to customization.
Problem Type 1: DMS installation problem. Contact your system manager or the
person that has installed DMS on your system.
Problem Type 2: DMS invocation problem. Check!!! [basedir.dms]list.dms for
correct device type and directory paths. One known problem is, if your default
disk drive is changed. You may fix list.dms file by dms_path:direct option F.
Check [basedir.DMS]logical.names and sys$login:login.com.
Problem Type 3: DEC CMS link problems. Read appendix-7.
Problem Type 4: Batch job completed with warnings or errors. Check the log
files in your login default directory. One known problem is that hard copy
print job crashes in case you do not have sufficient disk quota/free space.
In such a case contact your system manager to increase your disk quota or do a
cleanup in your directories.
Problem Type 5: You exceed your subprocess quota by using the Time Dependent
Events Control Facility, see section 5.1.7. Edit your event file. Make a
hardcopy of all files event.*. Ask your system manager to increase your
subprocess quota. Starting DMS 4.0 error message 'process quota is exceeded'
is displayed.
Problem Type 6: You have a problem with the Act facility, see para 5.1.2. Edit
your Act file to see what has gone wrong. Try to execute Act by setting $set
verify and get a hardcopy to see, if any of the DCL statements in your Action
sections have problems.
Problem Type 7: Anumber of internal files are automatically maintained by DMS
including BUILD.*, CONFIG.LOG, INIT.*, MILESTONE.DAT, MAIL.*, MESSAGES.*, under
each DMS DIRECTORY, and files BACKUP.DMS, LIST.DMS, LIST.UTL, MAIL.*,
MESSAGES.* and TEMPLATE.* under root sys$login subdirectory DMS. Accessing
these file not via DMS may cause severe problems. You may be able to fix
tampering by using DMS direct access file maintenance utility DIRECT.
^Appendix-4. DMS Development Utilities
All DMS utilities including documentation reside under dms_path directory
AAG.DOC documents DMS Advanced Application Generator
DIRECT DMS direct access meta-data file maintenance
DMS VAX/VMS Version Procedures -- Invocation: @dms_path:utility
utility explanation
------- -----------
clock date_time, elapsed time, elapsed CPU_time, %CPU cumulative
stop_clock and %CPU during last time quantumn.
cms_bootstrap bootstraps VMS directory tree into corresponding CMS group tree
cms_status status report of CMS library
cms_update updates CMS group tree to VMS directory tree update
dcl_interface customized DCL interface
fetch fetch CMS group .. elements tree into corresponding VMS tree.
^Appendix-5. Callable Interface .. Programming Support Manual
A callable interface is defined that enables the DMS tool to be used as part of
a customized programming environment. Interface categories supported are:
1: DMS main image may be expanded. The invisible Z_option of each DMS menu
invokes customized software.
2: Customized software may invoke DMS library programming units.
3: Customized software linked with DMS image has access to global DMS variables.
4: Customized software may read DMS meta-data files.
5: DMS data files and procedures may be customized.
DMS installation procedure supports configuration updates of category 1-3
interfaces, whereas category 5 customization cannot be supported. Category 4
configuration management cannot be supported, but the format of DMS meta-data
files is stable and not likely to change. Access to category 3-4 interfaces
shall be restricted to read access only! A customer is responsible for
configuration management of customized software. Read \dms_path\internal.dms !!
I Linkage, Z_routines, DMS libraries and DMS updates
DMS installation path is provided with linkage procedure that enables you to
link your software with DMS libraries to expand the DMS image. Copy libraries,
dms main object module and the linkage procedure into your directory. After
changes to USER object library, relink to create DMS image and test it. After
testing the DMS image, replace the DMS installation DMS image with your image.
If you have a customized USER library, remember after each DMS version upgrade
to relink the DMS image. Build a procedure to do this automatically.
The invisible Z_option of each DMS menu invokes customized software. Stub
Z_routines are stored in object library USER. Stub Z_routines invoke routine
TBD, that displays message 'nameZ to be developed', where name is the program
unit name of the corresponding menu routine. Both Z_routine and its parent menu
routine have the same parameters, if any. Thus, DMS customers may expand DMS
menus and build their software subtrees as part of the DMS call graph. The only
two Z-routines with parameters are:
accesz(myfile) is invoked from editor .. utilities menu with myfile being the
file name to be accessed. Its type is character*64 for MS DOS DMS version.
afoz(buf) is invoked from the menu of available file operations with buf being
the DMS phase (requirements, design ..). Its type is character*64 for MS DOS
DMS version and character*80 for other DMS versions.
User documentation of service routines in the main DMS object library DMS is
considered for future DMS releases.
II Global DMS Variables -- Format Fortran
COMMON /M/MODE ! character*1 mode is DMS user category with
values D,M,S,U denoting developer,manager,SQA and user respectively.
COMMON /ODIR/ORIGINAL_DIRECTORY ! default directory prior to invocation
of the DMS tool. Exit from DMS sets default to original_directory. Note that
MS DOS version has a null character terminator.
COMMON /DDIR/DMS_DIRECTORY ! directory path of DMS selected
Directory variables are declared as character*64 for MS DOS DMS version and
character*80 for VAX/VMS. In fact, VAX/VMS access paths may be *255, but DMS
scrolling mechanism uses *80 wide lines. This internal retriction of DMS may
be bypassed by using logical names. In any case long access names are rare.
COMMON /CERROR/CUMULATIVE_ERRORS, AFTER_RESET_ERRORS
Integer*4 variables count key press errors. Counter is reset after 10 errors.
COMMON /DAYHR/DATE,TIME ! character*10 date,time. See exit from DMS
for date and time format.
COMMON /SMS/SMSYES ! character*1 smsyes value is Y, if DMS directory
is linked to automatic version control, C for VAX/VMS DEC CMS link, else no
link is enabled.
COMMON /PARAD/NEND,OPTION,PHASE ! NEND is number of records in file
\dms_path\paradigm.dms, character option(20) is paradigm menu option array
and character phase(20)*43 is paradigm menu option titles.
COMMON /PDIM/PD ! character pd*60 stores up twenty 3-byte fields of
phase number, activity confirmation status and paradigm menu option initial.
See appendix-10 before using common /parad/ and /pdim/.
VAX/VMS DMS Version Only:
COMMON /BDIR/BASE_DIRECTORY,LENGTH_BDIR ! directory [.DMS] under
sys$login, where global meta-data files such as list of all DMSs are stored.
This common variable is not needed for MS DOS DMS version. The value is fixed as
\dms under root directory.
COMMON /CMS/CMS_GROUP,CMS_DIRECTORY ! DEC CMS group and library for a DMS
linked to CMS. CMS_GROUP by default is the last subdirectory under DMS directory
path. This is always the case for DMS not linked to DEC CMS. Type of CMS_GROUP
is character*39.
III DMS meta-data files
DMS IEEE software engineering standard TEMPLATE files under dms_path are:
CHECK.SQA - SQA Checklist
CM.FRM - Configuration Management Form
PLAN.CM - Configuration Management Plan
PLAN.SQA - Software Quality Assurance Plan
PLAN.VV - Verification and Validation Plan
TEST.PLN - Test plan
TEST.TDS - Test design specification
TEST.TCS - Test case specification
TEST.TPS - Test procedure specification
TEST.TTR - Test transmittal report
TEST.LOG - Test log
TEST.TIR - Test incident report
TEST.TSR - Test summary report
These files are sequential text file that may be changed by text editor.
Observe: DMS version update overwrites any changes made to dms_path!!!
DMS meta-data are direct access files with record length=80. The first record
is the number of records. DMS library routine ctod(line,nrec) converts a
character*80 line to integer nrec for reading number of records, and
dtoc(nrec,line) converts nrec to line for writing number of records. Tool
dms_path:direct enables access to direct access file for maintenance
operations bypassing the DMS tool. This is recommended only, if such a file has
been tampered.
Global meta-data files in subdirectory [.DMS] under sys$login are:
ACT.BAT - Global Act File for Housekeeping Functions, 5.5
EVENT.* - See 5.1.7 about time dependent events control for VAX/VMS
BACKUP.DMS - List of magnetic media backups, see 5.1.2
LIST.DMS - List of DMS directories!
LIST.UTL - List of global manager defined utilities
MAIL.M - Manager mail, 5.3.3
MAIL.PUB - Public Mail, 5.3.3
MESSAGES.M - Manager messages, 5.3.3
MESSAGES.PUB - Public messages, 5.3.3
PSW.M - Manager password, 5.5
TEMPLATE.% - Template files for DMS phases by manager, 5.5
Local meta-data files in each dms_directory are:
ACT.DAT - see 5.1.1
BUILD.% - User defined files in life-cycle order
CMS.NO - CMS group and library for DMS link cut from DEC CMS
CMS.YES - CMS group and library for DMS linked with DEC CMS
CONFIG.LOG - Configuration log
INIT.DMS - DMS initialization data, see 4. Type sequential.
LIST.UTL - List of local utilities for DMS directory
MAIL.D,S,U - Developer, SQA and general user mail, see 5.3.3
MESSAGES.D,S,U - Developer, SQA and general user messages, see 5.3.3
MILESTONE.DAT - Milestone data file, see 5.1.5
PASSWORD.D,S,U - Developer, SQA and user passwords
File build.% types %=A,C,D,E,I,M,R,S,T,V denote anything allowed ..
prototyping, configuration management files, design, event, implementation,
make, requirement, SQA, testing and shared files.
File build.% record fields are:
1: Filename.type preceded by optional access path
2: Optional file title separated by blank character from field-1.
3: Column-79 has null character for file linked to DEC CMS. Optional.
4: Column-80 has null character to mark file as encrypted. Optional.
IV Customization of dms_path data files and procedures
In general, it is not recommended to customize any dms_path installation files,
as this may cause configuration management problems. However, DMS VAX/VMS
procedures listed in DMS development utilities appendix-4 may be customized
without affecting DMS primary image. The same applies to SQA template files
listed above. Release notes of DMS tool updates shall inform about any changes
in existing data files and procedures to enable merging of customized files
with default installation files. User manuals are a specific issue. Observe
that user manual section numbers are burnt in the primary image. It is
recommended that a separate help file is used for customized software.
^Appendix-6 SMS Stores Management System for Automatic Version Control AVC
DMS implementations for different operating systems have the same standard
automatic version control mechanism. DMS version for VAX/VMS systems with DEC
CMS have an alternative mechanism described in the next appendix. DMS AVC works
as follows: If user wants AVC at DMS directory creation time, see section 4, or
later by selecting configuration management menu option V 5.1.8 to enable AVC,
then AVC marker file sms.yes is added to DMS directory, and subdirectory $sms
is created, if it does not exist. Existence of sms.yes is checked upon entry to
DMS directory to determine, if DMS is liked to AVC. DMS create form, add,
delete, rename and update file operations change status of file system and
invoke AVC. Upon create form and add file a meta-data file with name identical
to the created file is added $sms subdirectory. This file stores meta-data
about all versions of the created file for Fetch and View file version
operations, see 5.2.3. The original file is copied to $sms subdirectory under a
new hashed filename. The hashed filename of the original filename is entered
to meta-data with date_time stamp. Each time a file is updated it is copied to
$sms subdirectory under a new hashed name with meta-data update. Rename of DMS
directory file causes rename of $sms subdirectory meta-data file. Delete of DMS
directory file does not affect $sms subdirectory files. Thus, it is always
possible to recover a deleted file. DMS directory rename in manager mode, see
5.5, is transparent to user as far as the AVC mechanism is concerned. DMS
directory delete in manager mode, see 5.5, deletes $sms subdirectory, and is
thus an extreme operation that should be avoided. The scroll menu of file
versions in fetch and view version is chronologically ordered with date_time
stamp. If more information is needed to fetch the right file version, this
information may be found in DMS configuration log that contains for each file a
list of file operations with date_time stamp and optional user explanation of
unrestricted length. The whole AVC process is automatic except for the
voluntary user explanations. However, user is automatically entered to editor
.. utilities menu to provide an explanation each time file system status is
changed.
AVC advantages compared to other version control tools are maximal automation;
view or fetch of a file version without import operation of a container type
tool that has to build a file version backwards from last version or forwards
from first version; immediate access to the last file version always kept in
DMS directory; automatic version update without need for off-line export;
optimal interface for fetching or viewing file versions; minimized use of CPU
time over any other known version control mechanism.
AVC maximizes disk storage requirements. Number of versions stored under $sms
subdirectory is not restricted. It is possible to temporarily disable AVC for a
DMS directory undergoing very rapid changes over a short period and later
enable AVC. The basic philosophy is that secondary disk storage will the
cheapest and most abundant computer resource in future. Thus, version
compression of container type configuration management tools is considered as
an outdated practise.
^Appendix-7 Optional Automatic Link to DEC CMS Version Control
Skip this appendix unless you have a VAX/VMS with DEC Code Management System!
Optional linkage of DMS directory to DEC CMS library is chosen at DMS creation
time. Scrolling menu of DMS directories displays DMSs linked to CMS in
reversed video. DMS is linked to the CMS library set prior to DMS tool
invocation. If no CMS library is set, then default library [.CMSLIB] under
sys$login is set/created. Thus, different DMSs need not be linked to the same
CMS library. Information about the CMS library and the CMS group with the DMS
name is stored so that the link between DMS files management and CMS library
management needs no user intervention. In particular, there is no need to set a
CMS library prior to DMS entry.
Configuration management functions menu, see 5.1, includes three options to
control DMS link to CMS:
X - Cut DMS link to CMS. This function freezes status CMS elements in CMS group
with DMS name.
U - Link DMS to CMS. This function creates CMS group with DMS name, unless such
a group exists. See 'Organization of DMSs as CMS Groups' for details about the
connection between VMS directory hierarchy and CMS group hierarchy. DMS files
are created/replaced as CMS elements. Add and update CMS operations of DMS
files are explained below.
G - Global DEC CMS Baseline for all DMSs. DMS manager may invoke the G-function
that performs the U-function for all DMSs.
Organization of DMSs as CMS Groups
==================================
All DMS files are inserted to the CMS group that has the name of your DMS. DMS
name is defined as the final subdirectory in your dms_path. Thus, if you
created [Your_Basedir.Subdir1.Subdir2. .. .Subdirn], then your CMS group is
called Subdirn. CMS group corresponding to a DMS name is inserted as a CMS
subgroup of the CMS group corresponding to the parent directory. Thus, Subdir2
is inserted in CMS group Subdir1. It is possible to maintain a CMS group
hierarchy of DMSs that is identical to the VMS directory hierarchy of DMSs on
condition that DMS names are unique. A warning message is issued at DMS
creation time in case an attempt is made to link a duplicate DMS name as CMS
group. Also, VMS hierarchy cannot be maintained in case DMSs are not
systematically linked to CMS.
Operations on DMS files as CMS elements
=======================================
In case your DMS has been created with the CMS link option, then the available
DMS File operations add/delete/modify with file rename/update cause the
following CMS operations to be performed automatically for files linked to CMS:
- For each added file, a CMS element comprising that file is created and
inserted in the CMS group that has the name of your DMS. User may prevent link
to CMS of an added file. Note that CMS handles only ASCII files.
- For each deleted file, a CMS element comprising that file is NOT deleted for
from the CMS group that has the name of your DMS!
- For each renamed file a CMS element comprising 'old_file' is NEITHER deleted
NOR removed from the CMS group that has the name of your DMS. The new file is
created as CMS element and inserted in the CMS group of your DMS. Modify file
displays CMS link status of given file, and user may change this status.
- For each updated file the CMS element comprising that file is replaced in
the CMS group that has the name of your DMS.
You do not have to fetch the latest version of a CMS element file, since the
last version is not purged from your DMS directory.
All CMS elements corresponding to DMS files are RESERVED. Do not UNRESERVE
these elements. Automatic CMS operations require elements to be reserved.
CMS operations corresponding to DMS add/modify/update have corresponding remarks
that include the complete VMS directory path.
^Appendix-8 DMS Installation Procedure
DMS install for VAX/VMS is system is by standard VMSINSTAL. See kitinstal.com.
DMS install for MS DOS is by a:install. See file readme! for disk space and
memory requirements.
^Appendix-9. FUTURE YEAR 2000 DMS CONCEPT
'Future Generation Development Management System
Requirements' was initially displayed at the Tools Presentation
Track, 9th ICSE, Monterey, 2 April 1987. Also, see [6].
Future DMS will not be based on any of the new paradigms for
software engineering. 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. We 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.
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 conformance 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.
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 weak
Natural Language Interface -- None
DMS Execution Engine -- Powerful
AI Background Component -- Yes, but weak
REFERENCES: DMS PUBLICATIONS LISTED IN \DMS_PATH\HISTORY.DOC
[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] L.E. Bonani and C.A. Salemi, "Source Code Control System
User's Guide", Bell Laboratories, Piscataway, New Jersey
08854, UNIX documentation.
[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, "Development Management System", 1987 DECUS
Europe Symposium, Rome, Italy, September 1987. See, ACM
SIGSOFT Software Engineering Notes, July 1987 issue.
^Appendix-10: 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
DMS paradigm definition facility is critical software. Read carefully
file \dms_path\paradigm.pdm for theoretic background, and appendix-5 and
file \dms_path\internal.dms for callable interface .. programming
information !!! Define DMS paradigm on corporate bases. Do not change
life-cycle paradigm for ongoing projects !!!
Paradigm definition facility is invoked by DMS Special Services, see user
manual section 5.5, option L in DMS manager mode. Utility PDF may be
invoked externally, but manager password is prompted anyway:
------------------------------------------
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
------------------------------------------
Functions Add, Delete and Update are used to define life-cycle paradigm.
Function Show both displays paradigm and checks against errors. Option G
generates pardigm 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 as follows:
Step-1: Read carefully documentation stated above.
Step-2: 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.
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. Output source file is
paradigm.for. 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]: Insert or replace object module parad.obj in USER library. Then
link/NOD/EXEPACK/SE:400 %1,,,DMS+USER+LLIBC+LLIBFORE (MS DOS)
link dms,dms/library,user/library (VAX/VMS).]
After testing the new DMS image and after notify of all DMS users
transfer dms.exe into \dms_path for MS DOS DMS, and into sys$system for
VAX/VMS DMS version. Observe that any update of \dms_path\paradigm.dms
takes to effect only after successful completion of steps 1-5. What
counts is the DMS image generated.
OBSERVE! Steps 4 and 5 are required only, if you use non-standard program
units to be invoked by paradigm menu options. See field 4 definition.
^I N D E X: Major index entries marked by exclamation
Anomalies Report 5.2.4.5, Appendix-1
Backup Magnetic Media 5.1.2
Callable Interface Appendix-5
CMS 5.1,5.2,appendix-7!
Configuration Management 5.1!
Act Facility 5.1.2
AT Event Control 5.1.7
Backup 5.1.1
Form 5.1.4
Log 5.1.5
Contents 5.3.1, Appendix-1!
DMS
Creation 4!
Directory 3!
Delete 5.5
Entry/Exit 5, 5.5, 5.6
Initialization Data 4!
Rename 5.5
Milestone 4!, 5.1.6
Approval
Deliverable Item
File
Target Date
Passwords 5.5!
Error 2, Appendix-3!
Event 5.1.7!
File Operations 5.2!
Add 5.2.1
Copy, Delete, Modify .. Rename, Read and Update 5.2.2
Fetch .. View Version 5.2.3
Mechanisms 5.2.4
Life-Cycle Enforcement 5.2.4.1
DMS File Encryption 5.2.4.2
DMS File Title Information 5.2.4.3
Editor .. Utilities Menu 5.2.4.4
DMS Anomalies Report 5.2.4.5 and Appendix-1
Global
Baseline 5.1, appendix-7
Information 5.3.1
Operation 5.4.2
Housekeeping Functions 5.6!, 5.1.1, 5.3.1, 5.5
Link to Operating System 5.2.4.4, 5.4.4!
Mail 5.3.3
Management
Mode (Super User) 3, 5.1.5, 5.4.2, 5.5
Information 5.3.1
Paradigm 5, 5.2.4.1, Appendix-10
Print 5.4.1
Scrolling Menu 2!, 3, 5
Shared Files 5.4.3
SQA 3, 5.3.2!
Template 5.2.2, 5.5!
Test Coverage Table Appendix-1
Test Form 5.2.1
User Category/Mode 1, 3!, 5