Future Software Development Management System Prototype

 

                  16th ACM Conference, Atlanta, Georgia 1988

 

                  Initial  work  during  the  last  ten  years for defining and

        prototyping software  Development Management  Systems has  prepared the

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

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

        2000 concepts and current  DMS prototype implementation are  discussed.

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

        Engineering Tool, is outlined.

 

 

 

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

 

 

                             DMS PRODUCT EVOLUTION

 

 

                  DMS tool development started by computerizing the modest, but

        initially   successful   TRW    Unit   Development   Folder    concept.

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

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

        support avionics  and dynamic  simulation software  development in  the

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

        lack  of  configuration  management  services  and  lack of support for

        project management.  Bad  synchronization between software  development

        and the often delayed preparation  of the unit development folders  was

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

        management problem was  how to cross  milestones and deliverable  items

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

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

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

        The  most   radical  departure   from  the   original  canned  software

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

        generator to support organizational adaption of the DMS tool.

 

 

 

 

                   DEVELOPMENT MANAGEMENT SYSTEM DMS FEATURES

 

 

        * Software Environment Driver

        * Educational Software Engineering Tool

        * Integrated Meta-Information Handler and Execution System

        * Computerization of the TRW Unit Development Folder Concept

        * Complete Life-Cycle and Configuration Management Support

        * Automatic Background Processing for Version Control

        * AI Component for Analyzing Software Engineering Process

        * Data Sharing and Human Communications

        * Controlled Access by User Category

        * Natural Software Engineering Environment

        * Maximal Management Visibility

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

        * Support for Implementing IEEE Software Engineering Standards

        * Traceability of Testing to Requirements Supported

        * User Interface Management Library and Generator

        * Callable Interface

        * Life-Cycle Paradigm Generator

        * Portable: VAX/VMS, UNIX and MS DOS

 

        1988 ACM Sixteenth Annual Computer Science Conference Proceedings

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


 

 

           Future Software Development Management System Prototype  Page 2

 

 

 

                 PRESENT DMS APPROACH, CONCEPTS AND PHILOSOPHY

 

 

                  The DMS is tailored to the files management of your  computer

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

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

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

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

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

        import operations are needed  to communicate between the  container and

        the  natural  file  system.   The  container tools cause a considerable

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

        compel  users  to  learn  additional  command  syntax.   The   separate

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

        considerable  burden  to  users.   Perhaps  the most severe drawback of

        container  type  tools  is  that  low  level  configuration  management

        operations  are   done  manually   off-line  from   the  main  software

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

        all  low  level  configuration  management operations are automatically

        executed  in  parallel  to   the  software  engineering  process.    In

        particular,  version  control  is  automatically  synchronized  to  the

        software engineering process and is not a separate delayed process.

 

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

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

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

        automatically execute low level configuration management commands  such

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

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

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

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

        captures files and file access utilities information from users.  Users

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

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

        minimized   by   the    DMS   system.    Basically,    all   additional

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

        providing greater management control and visibility.

 

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

        any specific software engineering method.  It does offer  comprehensive

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

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

        However,  considerable  semantic  analysis  is  done  by the background

        housekeeping  functions  about  the  reasonableness  of  the   software

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

        to  detect  anomalies  such  as  insufficient  effort  in requirements,

        testing  or  SQA;  deliverable  items  not  implemented  for   approved

        milestones;  discrepancies  between  milestone  data  and  the   actual

        software process.

 

                  The aim is to guide  DMS users to devote considerable  effort

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

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

        requirements definition.  It is only a software engineering environment

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

        DMS system.

 


 

 

           Future Software Development Management System Prototype  Page 3

 

 

 

                  Future  directions  of  the  DMS  system  are  not  aimed  at

        providing support to any specific software engineering methodology, see

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

        autoregression   test   support,   document   trace   tools  to support

        verification,  and  IEEE  software  engineering  and  military standard

        templates.   Components  for  software  cost estimation and reliability

        measures will be included.

 

                  DMS  paradigm  definition  facility  enables  experimental or

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

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

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

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

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

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

 

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

        major  operating  systems.   Software  development  in  a heterogeneous

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

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

        AT&T Bell  Laboratories UNIX  V compatible  implementations are nearing

        completion.

 

 

 

 

                         FUTURE YEAR 2000 DMS CONCEPTS

 

 

                  'Future    Generation    Development    Management     System

        Requirements' was initially displayed at the Tools Presentation  Track,

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

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

        diskette may be obtained from the author.

 

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

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

        software engineering  methods are  likely to  continue to  do more harm

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

        formalized  executable  requirements  are  not  enough.  The problem of

        capturing requirements still remains  the classic problem of  developer

        and  customer  understanding  each   other.   The  automation  of   the

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

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

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

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

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

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

        2000.

 

 


 

 

           Future Software Development Management System Prototype  Page 4

 

 

 

                DMS 2000 ARCHITECTURE: THE PRIMARY SUBSYSTEMS

 

 

        - Standard Relational Database Architecture

        - Natural Language Interface

        - Execution Engine

        - AI Component with Software Engineering Rules Base

 

 

        Standard Relational Information Architecture Supports:

 

        - Automatic creation of test cases from requirements

        - Traceability

        - Interfaces control definition

        - Incremental development

        - Reusability

        - Configuration management

        - Contract management

        - Management visibility

        - Distributed project environment

 

 

                  Natural Language  Interface to  DMS Information  Architecture

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

        syntax  for  data  retrieval  or  entry is necessary.  Natural language

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

        characteristic many (most?) projects.

 

 

                          DMS Execution Engine Requirements

 

 

                  DMS  execution  engine  shall  serve  as an interface between

        software  engineers  and  operating  system  in  the  natural   working

        environment.  The  DMS engine  shall automatically  link the relational

        information architecture with the  operating system.  The engine  shall

        capture  software  engineering  data  and  enter  it to the information

        architecture,  thus  minimizing  manual  data  entry requirements.  The

        engine  shall  do  parallel  processing  of all low level configuration

        management operations without user intervention.

 

 

                 DMS AI Component for Analyzing the Software Process

 

                  The DMS shall have a  software engineering rules base and  an

        AI component capable of verifying  compliance to the rules by  matching

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

        adherence both to life-cycle and to contractual constraints.


 

 

           Future Software Development Management System Prototype  Page 5

 

 

 

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

 

                  The current trend of  integrating tool fragment ..  utilities

        into  packages  is  useful  only  for  the  implementation  phase  that

        approaches  the  'completely  understood  and  stable  domain'   stage.

        Examples of  successful implementation  phase packages  are: UNIX,  VAX

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

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

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

        database architecture,  natural language  front end,  and background AI

        component.

 

 

              Standard Computer Vendor Solutions For DMS Implementation

 

                  DMS  relational  information  architecture  shall be based on

        computer vendor standard.  Also,  the natural language interface  shall

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

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

 

 

              Stage of Current DMS Implementation versus DMS 2000

 

              Information Architecture   -- Yes, but not flexible

              Natural Language Interface -- None

              DMS Execution Engine       -- Powerful

              AI Background Component    -- Yes, but not flexible

 

 

 

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

 

 

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

 

 

                Invocation by User Category

                Creating a New DMS Directory

                Main Menu Functions

                  Configuration Management Functions

                    Interface to Make

                    Backup to Private Magnetic Media

                    Create Configuration Management Form

                    Configuration Log

                    Milestones

                    Query Configuration Management Forms

                    Time Dependent Events Control Facility

                    Disable/Enable Automatic Version Control

                    Baseline Generation

                  Available File Operations

                    Add File

                    Copy . Delete . Modify . Read . Update File

                    Fetch Version and View Version

                    Mechanisms for File Operations

                      Life-Cycle Enforcement

                      DMS File Encryption

                      DMS File Title Information

                      Editor .. Utilities Menu

                      DMS Anomalies Report


 

 

           Future Software Development Management System Prototype  Page 6

 

 

 

                  DMS Information Menu Functions

                    Management Information

                    SQA Information

                    Mail Facility

                  DMS Services

                    Print Menu

                    Global Operations By DMS Manager

                    Shared Files

                    Link to Operating System

                  Special Services

                  Housekeeping Functions

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

 

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

 

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

 

 

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

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

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

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

          Error: illegal original date for milestone msno

          Error: illegal revised date for milestone msno

          Warning: Developer approval of milestone msno

                   without SQA approval of msno-1

          Warning: Developer approval of milestone msno

                   without Manager approval of msno-1

          Warning: SQA approval of milestone msno

                   without Manager approval of msno-1

          Error: illegal Developer approval date for milestone msno

          Error: illegal SQA approval date for milestone msno

          Error: illegal Manager approval date for milestone msno

          Warning: SQA approval without Developer approval of milestone msno

          Warning: Manager approval without SQA approval of milestone msno

          Warning: Manager approval without Developer approval of milestone msno

          Warning: Overdue Manager Approval of milestone msno

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

 

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

 

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

 

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

                Paradigm Definition Facility.

                (C) Copyright Ben Livson, 1987

 

                A - Add

                C - Confirm Completion of Paradigm Phase

                D - Delete

                G - Generate Paradigm Source File

                S - Show

                U - Update

 

                ? Select Option. <Return> = Exit from Menu

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


 

 

           Future Software Development Management System Prototype  Page 7

 

                  Functions  Add,  Delete  and   Update  are  used  to   define

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

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

        create  a  DMS  image  with  burnt  in  paradigm  definition.   Confirm

        Completion of  Paradigm Phase  is the  only function  that affects  the

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

        the life-cycle process.

 

               Work procedure for paradigm definition facility use is:

 

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

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

        direct  access  file.   Each  paradigm  record  has  the following five

        fields:

 

                  1 Phase number.  Phases numbers are in increasing order  with

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

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

        defined.

 

                  2   Paradigm   activity   confirmation   status   is  YES, if

        confirmation is required before  the next phase development  may start.

        In any case start of previous phase activities is automatically imposed

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

        confirmation status  YES, DMS  MANAGER approval  is imposed  before the

        next phase development starts.

 

                  3  Paradigm  menu  option   initial.   The  initial  may   be

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

        initials of  all previously  defined paradigm  activities.  Lower  case

        letters  are  automatically  converted  to  upper  case.   Each initial

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

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

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

        belonging to a given activity.

 

                  4  Program  unit  invoked  by  paradigm menu option.  Default

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

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

        subroutine  TEST.   Observe  that  default  program  units afo and test

        invoke  configuration  management  operations.   If  you do not use the

        defaults,  you  must   have  a  complete   understanding  of  the   DMS

        configuration management mechanism.

 

                  5  Paradigm menu title.

 

                     Default built-in DMS life-cycle paradigm is:

 

        Phase No.  Confirmation Status  Initial  Program Unit  Menu Title

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

           0              No               R        AFO(C)     Requirements

           1              No               D        AFO(C)     Design

           1              No               T        TEST       Testing

           2              No               I        AFO(C)     Implementation

 

                  Thus,  existence  of  at  least  one  requirements  file   is

        compulsory  before  design  or  testing  may  start,  but completion of

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

        testing  may  commence.   Design  and  testing are parallel activities.

        Implementation may start only after all previous activities have files.

        Write down on paper your paradigm table.


 

 

           Future Software Development Management System Prototype  Page 8

 

 

 

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

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

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

        errors.

 

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

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

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

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

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

        and USER, and DMS.EXE image.

 

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

 

 

 

                EduSET: Educational Software Engineering Tool Project

 

 

                  Why are freshmen computer science graduates almost useless as

        software engineers?  Why must companies invest in massive retraining of

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

        solution  is  attempted  by  the  Educational Software Engineering Tool

        EduSET  project.   EduSET  interface  to  software tool information and

        demonstration is specified.

 

                  Software engineering tools are supposed to aid, formalize  or

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

        process  called  software  engineering.   This  process  is  by  nature

        distributed, cooperative and  heterogeneous.  Interacting with  project

        management,  configuration  management,  software  quality   assurance,

        customer independent verification and validation is a most complicated,

        costly  and  painful  process  even  for experienced professionals.  CS

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

        life  problems.    EduSET  enables   to  simulate   the  real   working

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

        quality assurance,  configuration and  project management  and customer

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

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

        software engineering lecturer to  define a class project  with students

        participating in the different roles.  EduSET supports  experimentation

        of life-cycle paradigms.

 

                  A CS student does not  qualify as a software engineer  before

        developing software under (simulated) real life circumstances.   EduSET

        shall  enable  software  development  in  a natural environment.  Every

        software  development  tool  or  utility  must  executable  via EduSET.

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

        other software products.

 

                  EduSET  shall  support  the  whole  life-cycle.  EduSET shall

        enforce a disciplined software engineering approach under configuration

        management.  Configuration identification, control and status reporting

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

        EduSET providing a full range of IEEE CS software engineering  standard

        checklists and templates.


 

 

           Future Software Development Management System Prototype  Page 9

 

 

                  EduSET Educational Software Engineering Tools is a commercial

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

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

        information and canned demonstrations of software engineering tools and

        supporting methodologies.   CASE vendors  and other  interested parties

        are invited to make submissions:

 

                  Submissions shall be without  cost or obligation.  The  media

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

        explaining  its   contents.   All   commercial  information   shall  be

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

        cleaned   from   word   processing   symbols   and   special  files for

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

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

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

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

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

        sample diskette.

 

                  Companies or individuals interested in making a submission to

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

 

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

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

 

 

 

                                   REFERENCES

 

 

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

            Manual", Proceedings of the Fifth International Conference

            of the Israel Society for Quality Assurance, October 1984.

 

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

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

 

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

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

 

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

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

 

        [5] IEEE Transactions on Software Engineering, January 1977

            issue of the first software specification methodologies.

 

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

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

            July 1987.

 

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

            IEEE Computer Society Order Number 707, 1986.

 


 

 

           Future Software Development Management System Prototype  Page 10

 

 

 

                                   AUTHOR BIOGRAPHY

 

                  Dr. Ben Livson is  consultant software engineer in  Ultraware

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

        services and developes software tools with special emphases on software

        quality assurance, testing and configuration management.

 

                  Ben  Livson  was  brought  to  Israel  in  1977 by the Israel

        Aircraft  Industries  Ltd  to  establish  the  first  software  quality

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

        until 1986.

 

                  Dr.  Livson  has   fifteen  years  of   software  engineering

        experience including major assignments as:

 

                  1.  SQA  manager of  operational flight  programs and dynamic

        simulation and integration projects.

 

                  2.   Manager  of  software  testing  projects  for   computer

        embedded systems communications software and operating system.

 

                  3.  Developer of a  computerized unit development folder  and

        configuration management tools.

 

 

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

        the  software  quality  assurance  sessions  of  the  fourth  and fifth

        international  Israeli  Quality  Assurance  Conferences,  and  he   has

        published over twenty papers.