EduSET: Educational Software Engineering Tool Page 1
Information & Software Technology, Vol 30 No 4, May 1988.
© Copyright 1988-2006 Ben.Livson@bal.com.au. All rights reserved.
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
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  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 :
- Conventional "Waterfall" Software Development Model
- 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 . 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
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
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.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
- 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
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
4.2 Decryption of the change after it has been implemented.
4.3 Marking each line in a unit according to the change that
4.4 Possibility of retrieving a previous generation.
4.5 Organizing a variant out of pieces from various structures and
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
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.
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
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
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.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
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.
- Source code.
- Test files.
- Object modules.
- Data files
- Computer procedures.
- 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
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 .
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 :
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) :
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
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.
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.
3 IEEE Software Engineering Standards, (C) Copyright 1987 by
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,
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
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
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
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
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.