EduSET: Educational Software Engineering Tool Page 1

Ben Livson

Information & Software Technology, Vol 30 No 4, May 1988.

Why are freshmen computer science graduates almost useless as

software engineers? Why must companies invest in massive retraining of

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

solution is attempted by the Educational Software Engineering Tool

EduSET project. The EduSET interface to software tool information and

demonstration is specified. EduSET architecture is outlined.

Submission and cooperative information for parties interested in EduSET

is given.

KEYWORDS Software Engineering, Education, Development Management System

DMS, EduSET, Software Quality Assurance SQA, Configuration Management.

I N T R O D U C T I O N

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 and 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 can 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 a framework for controlled access,

with each user category having its own privileges. EduSET will enable

the CS course software engineering lecturer to define a class project

with students participating in the different roles. EduSET supports

experiment with life-cycle paradigms.

A CS student does not qualify as a software engineer before

developing software under (simulated) real life circumstances. EduSET

will support software development in a natural environment. Every

software development tool or utility must be executable via EduSET.

EduSET will be a software environment driver that permits the use of

all other software products.

EduSET will support the whole life-cycle. EduSET shall

enforce a disciplined software engineering approach under configuration

management. Configuration identification, control and status reporting

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

EduSET, providing a full range of IEEE CS software engineering standard

checklists and templates.

EduSET: Educational Software Engineering Tool Page 2

EduSET A R C H I T E C T U R E

EduSET architecture is based on the DMS Development

Management System [1] software environment driver as a kernel, a

software tools information layer, and components to be provided by

theEduSET user community. The basic features of the DMS kernel are:

* Software Environment Driver

* Integrated Meta-Information Handler and Execution System

* 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

* Computerization of the TRW Unit Development Folder Concept

* Support for Implementing IEEE Software Engineering Standards

* Traceability of Testing to Requirements Supported

* Software Environment Kernel Functions Library

* Callable Interface

* Portable: Digital Equipment VAX/VMS, AT&T Bell UNIX and Microsoft DOS

* Life-Cycle Paradigm Generator

DMS LIFE-CYCLE PARADIGM SUPPORT

The most unusual DMS feature is its life-cycle paradigm

generation to support experiment on software processes.

Software development (life-cycle) paradigms are the

techniques of phasing software development (life-cycle) into a

controlled software engineering process with milestones, deliverable

items and reviews. Four different paradigms are discussed in [2]:

- Conventional "Waterfall" Software Development Model

- Prototyping

- Operational Specification

- Transformational Implementation

The default DMS conventional life-cycle paradigm supports a

hierarchy of configuration items, and supports one-to-one, one-to-many

and many-to-one hierarchy in development, namely the split of a joint

specification into configuration items and the subsequent integration

of these items. DMS forces development to start from requirements but

does not enforce the separation of external system behavior (the "what"

of requirements specification) from internal structure (the "how" of

design). Intertwining of "what" and "how" is enabled [4]. The

Operational Specification is encouraged to separate development into

problem oriented and implementation oriented phases. DMS development

paradigm is made flexible enough for conventional, prototyping and

operational specifications, and hybrid paradigms. The DMS paradigm

definition facility is explained below.

EduSET: Educational Software Engineering Tool Page 3

A key feature is the DMS automation of all low level

configuration management operations to form a process parallel to the

development process. This is critical to both prototyping and

operational paradigms that usually are less controlled and much more

dynamic than conventional development.

DMS treats verification, validation and testing as a process

parallel to the development process. Testing can be done both by the

development organization and independently by an independent

verification validation and testing contractor. The administrative and

behavioral issues can be experimented by EduSET lecturers and students.

Testing may start immediately after the start of requirements, and a

background AI component makes a cross between development phases,

milestones and deliverable items to analyze the semantics of the

development process. A flavor of DMS anomaly analyses is shown by the

following list of anomalies produced by the AI component:

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

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

The DMS testing phase follows the IEEE CS standard on test

documentation:

EduSET: Educational Software Engineering Tool Page 4

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

DMS automatically maintains traceability matrices between

test cases and requirements, and the reversed requirements test cases

matrices.

DMS support for IEEE CS standards is built-in. Optional

support for military and corporate standards is enabled by the DMS

template interface. Also, DMS has a callable interface to drive a

software engineering environment and to provide a kernel of library

functions for future environments.

DMS includes special privileges for SQA:

SQA Information Menu

0 - Verification and Validation Plan (IEEE Std 1012-1986)

1 - SQA Plan (IEEE Std 730-1984)

2 - Configuration Management Plan (IEEE Std 828-1983)

3 - SQA Checklist

All DMS phases make across between meta-information about

files development phases, and provide a unified file-utilities access

interface that automatically triggers configuration management:

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

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

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

EduSET: Educational Software Engineering Tool Page 5

EduSET CONFOGURATION MANAGEMENT SUPPORT

A thorough understanding of configuration management is a key

element in the evolution of a software engineer. This subject is

hardly glamorous for a CS student, but in real life it is more

important than any other issue in the author's opinion. Configuration

management cannot be learned by reading books or articles. Neither can

it be learned by using a configuration management tool off-line. The

only way to learn this discipline is to be in the main stream of

software development and support. The question is: "Do you have to

learn configuration management at the expense of a project before

growing to a software engineer?". The greatest EduSET contribution is

to provide a tool that integrates configuration management with

software development as a parallel real time process for education.

Configuration management support can be grouped according to:

a. Identification, see requirements 1, 2 and 3.

b. Control, see requirements 4, 5 and 6.

c. Auditing requirement will be part of the work procedures.

d. Status accounting, see requirement 7.

A set of technical requirements is numbered as 8-21.

1. Identification.

1.1 Unit Identification.

Identification has to identify the location of the unit within

the whole software structure. This means that a hierarchical structure

has to be supported.

1.2 GenerationMZ† YÿÿA€ç‑omprised the software development effort may be a

member of various networks and not only be a member in a tree

hierarchy. A routine is, of course, a part of a larger program. This is

the main tree structure that contains it. But it is also a part of

'Invocation Network' - the network that describes the CALLING paths. It

is also connected to its specification, to its creator, to its

maintaining group, to change requests, to change implementation, to a

test file or test procedure, and so on.

EduSET: Educational Software Engineering Tool Page 6

It is necessary that all these networks will be recorded and

various functions have to be able to access or modify them using this

information or being constrained by it.

3. Naming Options.

- Synonyms for abbreviations intended or for adaptation to

different environments.

- Names that are numbers only. (to facilitate retrieval of

documents that are known only by their serial numbers)

- Long names.

- Qualified names. This enable the usage of identical names in

different environments.

4. Change control.

4.1 Entering change request according to a predefined form. The

change has to include also information about the other units that may

be influenced by the change and about milestones for implementing the

change.

4.2 Decryption of the change after it has been implemented.

4.3 Marking each line in a unit according to the change that

originated it.

4.4 Possibility of retrieving a previous generation.

4.5 Organizing a variant out of pieces from various structures and

generations.

5. Release Control.

5.1 Autoregression Testing.

A process of autoregression testing will be supported. In

this process, a run of the program is executed and the results are

compared to standard results or to previous results. Reports of the

results are sent to the interested parties according to a special list.

5.2 Release Information Distribution.

Information concerning the release must be distributed

according to a special list and also according to certain criteria,

such as all those who use the unit released. This service is also

connected to automatic mailing.

5.3 Approvals and Signatures.

The release of the unit must be acompanied by approvals.

These approvals are signed within the system and the system checks that

this is being done.

A request for such approval may be sent through the mailing

services, and a note of this request will be recorded in the data base.

EduSET: Educational Software Engineering Tool Page 7

6. Protection.

Protection from unauthorized changes or access is necessary in an

environment were a lot of people are working on shared material.

6.1 Network of access.

A network of access permission can be envisioned, where a

user will be granted access according to user position in a network.

Thus, a manager will have access to the information held by employees.

A manager will have access also to functions of the system according to

his or her position.

6.2 Encryption.

Encryption and other safety measures will be provided by EduSET.

7. Status Reports.

7.1 History of Changes.

Each change is keyed to a generation, according to the lines it

affected. For each generation (or variant) there has to be a link to

the appropriate documentation that requested it and the documentation

that describes its implementation. This documentation can be retrieved

at will. The documentation can be requested to be written in a

standard way and additional documents linked to it - and later

retrieved.

7.2 Status of Implementation of a Change.

A report of the status of a requested change can be produced.

This status is reported or deduced from the operation upon the material

in the Development Library. Another report can be produced which will

contain comparisons of intended targets and implemented ones.

ADDITIONAL REQUIREMENTS FOR CONFIGURATION MANAGEMENT SOFTWARE TOOLS

___________________________________________________________________

8. Screen editor.

9. Connection to Word Processor and Forms Manager.

This connection will assure standard reporting and standard

documents. The standardization may be used by the system for eliciting

'link' information and linking the document to other documents. The

other documents can be retrieved at will and incorporated into each

other. Also a trace of information can be established. For example -

for each paragraph of a specification document the source of that

paragraph in the requirement document may be recorded and later

retrieved.

EduSET: Educational Software Engineering Tool Page 8

10. Shared Data Management.

10.1 Special Protection

Shared data requires special protection including authorization

to modify it and additional approvals for releasing it. EduSET is

planned tp provide the protection.

10.2 Special Analysis.

Special analysis may be necessary for all the parties using the

shared data. Some assertions may have to be provided that those tests

and checks have really been done. These assertions shall be provided by

EduSET configuration manager.

10.3 Message Switching.

Automatic messages to the parties which may be influenced by a

change to shared data have to be sent. The determination of these

parties can be done according to a predefined list and also according

to an analysis of the type of change.

10.4 'INCLUDE' Facility.

Automatic inclusion of shared data into texts has to be

provided. This inclusion releases the engineer from tedious repetitive

tasks, and also assures the uniformity of the shared data.

10.5 'INCLUDE' with Modifications.

Some inclusions may have to be modified with appropriate

parameters as to make them comply with the special demands of the unit

they are included into. In that respect it may be thought of as a MACRO

facility. But this macro is intended to operate within a unit and not

on the level of the system alone.

10.6 Examples of Common Data.

- Program unit interfaces.

- File descriptions.

- Common tables.

- Global variables.

- Data Base descriptions.

- Common paragraphs of documents.

11. Mailing.

11.1 Recipient Lists.

A means of automatic mail (inclusion in the directory of a

user of a document or a note concerning him) has to be provided. The

mailing list may be prepared in advance or in special cases may be

provided by a EduSET analysis of the networks concerning message being

requested.

EduSET: Educational Software Engineering Tool Page 9

11.2 Check for Receipt.

In order to assure that some attention was granted to

important messages, an answer might be requested within a certain

period of time. Automatic checking of this answer including the very

fact that it was indeed sent can be done.

12. The Objects to be Managed.

12.1 Types.

- Documents.

- Source code.

- Test files.

- Object modules.

- Data files

- Computer procedures.

- Libraries

- Other types readable by machine or by man.

12.2 Coordination of Objects.

Some of the objects have to be coordinated. An object module

has to be coordinated with the appropriate version of the source. Some

of the objects have to be coordinated to external objects such as

compilers, operating systems versions or equipment. Appropriate

information has to be held and any change to such an object has to be

checked for consistency and appropriate messages sent.

13. Easy User Interface.

The users may be of various levels: a user who uses the

system only sometimes, or a user who uses it permanently - so the user

interface has to be able to adapt to these various needs.

14. Macros and Command files.

For repeating tasks or complicated tasks, a macro facility has to

be provided. This macro is composed of system commands that can be

changed for any specific request according to parameters.

15. Statistics Gathering.

Automated statistics gathering to support quantitative

software models such as software reliability measures, quality metrics,

complexity measures and cost evaluation are crucial. User control over

what statistics are gathered has to be determined.

16. Functions that operate on structures.

As mentioned earlier a network support has to be provided.

This means - functions like 'COPY', 'DELETE', and other operations have

to be able to operate collectively upon a group of units according to

various access criteria.

EduSET: Educational Software Engineering Tool Page 10

17. Central Data Dictionary.

The items handled in the development effort can have standard

definitions and names. This standardization can enhance communication

and facilitate a cross reference of the location where these items are

used.

18. Compression.

19. Difference Report.

A report describing the difference between two texts is required.

This report describes the difference in terms of lines that are deleted

or added to one text in order to produce the other. Special effort

will placed on intelligent comparators [5].

20. Backup Facility.

The Central Development Library holds the result of the whole

development effort. Therefore special care has to be given to

preserving it. Also in the case of accidental deletion or modifications

of the library on the disk in a way that the standard rollback facility

can not remedy (by reverting to a previous generation), a version of

the library held elsewhere (probably on tape) can be used.

21. Graphic Output.

Business graphics of statistics gathered will be provided by EduSET.

EduSET SOFTWARE QUALITY ASSURANCE FUNCTIONS

Software quality assurance is a separate EduSET category with

privileges to define, check and approve milestones, and conduct the

auditing function for configuration management. A template facility is

given for quality assurance to define its checklist. A default DMS

checklist is shown, see also [3]:

EduSET: Educational Software Engineering Tool Page 11

SQA AUDIT CHECKLIST

____________________

State Yes/No for the correctness of:

No: Criteria : Y/

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

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 Standards compliance (IEEE Std 1016-1987) :

3. Testing

Compliance to IEEE Std 829-1983 for Software Test Documentation:

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

EduSET: Educational Software Engineering Tool Page 12

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 P1063) :

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-1987 for Measures to Produce Reliable Software :

11. IEEE P1061 Standard for Software Quality Metrics Analysis :

EduSET ARCHITECTURE LAYER II: SOFTWARE TOOLS INFORMATION

EduSET Educational Software Engineering Tools is a commercial

project to produce and mass distribute a book and a software tool 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 will be without cost or obligation. The media is

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

explaining its contents. All commercial information will 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 will be a unique combination of two characters: $x.

Interested parties may request a sample diskette.

Observe: Software tools may run on any computer or operating system.

However, the information submission format is IBM PC DOS floppy

diskettes.

EduSET: Educational Software Engineering Tool Page 13

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, Future Software Development Management System Concepts,

ACM SIGSOFT Software Engineering Notes, vol 12 no 3, July 1987.

2 William W. Agresti, New Paradigms for Software Development, IEEE

Computer Society Order Number 707, 1986.

The Institute of Electrical and Electronic Engineers, Inc

345 East 47th Street, New York, NY 10017, USA.

4 W. Swartout and R. Balzer, On the Inevitable Intertwining of

Specification and Implementation, Communications of the ACM,

July 1982, pages 438-434.

5 W.F. Tidy, The string-to-string connection problem with block

moves, ACM Transactions on Computer Systems, 2-4 November 1984,

pages 309-321.

PUBLICATIONS THAT HAVE INFLUENCED EduSET

6 R. Hurst,"CASE System Near Fruition", Computerworld Focus, July 1987

7 S. Kolodziej, "User Interface Management System", Computerworld

Focus, July 1987.

8 R. Poston, "Charter for the IEEE Computer Society's Task Force on

Professional Tools", IEEE CS Software Engineering Standards

Subcommittee status report, August 14, 1987.

9 VAX/VMS Software, Language and Tools Handbook, Digital Equipment

Corporation 1987.

10 W.R. Cowell and W.C. Miller, "The TOOLPACK Prospectus", Argonne

National Laboratory, TM 341, September 1979.

11 M. Dowson, "ISTAR - An Integrated Project Support Environment", ACM

SIGPLAN Notices, vol. 22 no. 1, January 1987.

12 IEEE P1074 Standard for Software Life Cycle Processes, to be

balloted in 1989.

EduSET: Educational Software Engineering Tool Page 14

AUTHOR BIOGRAPHY

Dr. Ben Livson is the co-founder and president of Ultraware

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

services and develops software tools with special emphasis on software

quality assurance, testing and configuration management.

Ben Livson was brought to Israel in 1977 by Israel Aircraft

Industries Ltd to establish the first software quality assurance group

for computer embedded systems, a group that he managed until 1986.

Ben 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 air force 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.