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               Life-Cycle Enforcement .....................  23               DMS File Encryption ........................  24               DMS File Title Information .................  24               Editor .. Utilities Menu ...................  24               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



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



Audience: Software managers, developers, SQA, SCM and VV&T personnel. DMS is an

educational software engineering tool, and as such has a wide audience.





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


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



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








The first DMS menu after invocation is to select user category



        |Welcome to Development Management System DMS   |

        |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



-  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                                               |





       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


       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)





         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



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 Standard

configuration  management  services  are  automatically invoked in case of file





^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


^ 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





^ 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.


^ 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.


^ 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>   |





^ 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 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



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.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, 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 !!






       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$



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


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.



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



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

DMS install for MS DOS is by a:install. See file readme! for disk space and

memory requirements.






                '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.







        - 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




        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




        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






        [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



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



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



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 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   , 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!


       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


             Deliverable Item


             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

            DMS File Encryption

            DMS File Title Information

            Editor .. Utilities Menu

            DMS Anomalies Report and Appendix-1


       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.4.4!

Mail                         5.3.3


       Mode (Super User)     3, 5.1.5, 5.4.2, 5.5

       Information           5.3.1

Paradigm                     5,, 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