Bringing Software Quality to the Enterprise

The CASEM Project - Operational Concept Description

Introduction

One of the perpetual problems faced by software engineering teams today is how to effectively manage the processes and procedures by which software is created. Although this is by no means a new issue, it has become more significant in an environment of Rapid Application Development (RAD) technologies, and decreased time-to-market demands. The Computer Aided Software Engineering Management (CASEM) tools have been designed with this problem in mind.

For all their obvious advantages, RAD environments in particular, while not actually discouraging the use of formal methods, have tended to make it easier to neglect them. This is evident even in experienced engineers, but RAD tools have also made powerful software development available to untrained and inexperienced developers, who have little or no knowledge of formal methodologies.

This is not to make the rather elitist suggestion that inexperienced developers should not use RAD tools. In fact, it is partly a justification for creating CASEM. One of the goals of the CASEM tools is to make it easy to learn and use formal software engineering methodologies. When used with formal methodologies, RAD tools become an extremely powerful way to write high-quality software. The speed and efficiency of the RAD environment is combined with the quality assurance of managed processes.

Of course, RAD environments are not the only software engineering context in which formal methodologies are required. Before RAD environments were commonly available, formal processes and procedures were the only way in which the complexities of software development could be managed to produce an acceptable result. In this context, the CASEM tools offer nothing particularly new or innovative.

As part of the qPrise Software Development System (qSDS), CASEM is designed to implement, enable and assist the core software engineering process and associated procedures. Essentially, it is a toolset for managing:

	Documentation and other project-specific assets
	Requirements in analysis
	Solution design
	Test procedures, execution and results
	Reviews and audits
	Traceability

In this overall context, this document explains the operational concepts of the CASEM project, including:

	The system architecture
	A model for the information it handles
	The software architecture
	Some notes on implementation technologies

This document does not replace a formal analysis or design exercise, but it does give a framework for subsequent effort in these areas.

CASEM Overview

The intent of CASEM is that it should assist people working in the following roles (which are defined in the qSDS Software Engineering Process):

	Engineering Managers
	Project Managers
	Software Engineers
	Quality Managers
	Quality Representatives

Of course, these roles are not always assigned to distinct people, but it is clear that CASEM must operate in a multi-user environment. This, in turn, suggests a client-server architecture.

CASEM is designed to handle the following information entities:

	Projects
	Requirements (as individual statements of functionality, performance, reliability or safety)
	Design elements, in an abstract form
	Test procedures
	Test results
	Documents

The following is a high-level entity/relationship model of this information:

CASEM Entity/Relationship Diagram

CASEM is not designed to handle:

	Project management (schedules, resources, tasks or effort); a number of excellent tools already exist for this purpose
	Source-code management - again, a number of tools for this purpose, such as CVS, already exist

The CASEM server will function similarly to a database server, handling following functions:

	Servicing client requests
	Information storage, retrieval and maintenance
	Concurrency resolution
	Access control

A number of distinct CASEM clients are envisaged, with separate information-handling roles:

	Requirements Client - for use during the analysis phase, for maintaining the requirements list
	Design Client - for use during the design phase, for maintaining the list of design elements
	Test Client - for use during formulation and execution of tests

CASEM System Architecture Diagram

Detailed Information Model

As stated in the previous section, CASEM will handle six basic data entities - Projects, Requirements, Design Elements, Test Procedures and Test Results. Naturally, a formal analysis will highlight a more refined information model than that presented here. The purpose of this discussion is to create a framework for further discussion and ideas.

Data Element: Project

The Project entity represents the basic unit of work in the qSDS. The qSDS Software Engineering Process document defines this term precisely, but in CASEM, a project is used for grouping all other information in the database. A project entity has the following attributes:

ID (32-bit integer, mandatory): A unique identifier for the project, assigned by the system
Name (string, mandatory): A human-readable string identifying the project
ExternalID (string, optional): An identifier for the project that is relevant to the external environment; the organisation may have a specific numbering or nomenclature system not controlled by CASEM
Description (string, optional): A synopsis of the project's basic purpose
Customer (string, optional): The name of the customer for whom the work is being done (if applicable)
RootPath (string, mandatory): The file system path to the root directory of the project; all files related to the project are kept under this directory, with a simple convention for specifying standard directory tree structures
DocumentationPath (string, mandatory): The file system path to the directory in which documentation for the project is kept; this is specified relative to the RootPath attribute

Data Element: Document

The Document entity encapsulates information about a document related to the project. It has the following attributes:

ProjectID (32-bit integer, mandatory): A reference to the project to which this document belongs
ID (32-bit integer, mandatory): An identifier for the document, assigned by the system, and unique within the context of the project
Title (string, mandatory): The named title of the document, usually displayed at the top or on the cover of the printed work
Subtitle (string, optional): An optional subtitle for the document
Type (string, optional): An arbitrary code for the document, denoting the type of content; CASEM generates documents with specific type codes such as 'SRS' (Software Requirements Specification), 'SDD' (Software Design Description) and 'STD' (Software Test Description).
FileName (string, mandatory): The name of the file (without path information); this is assumed to be in the directory specified in the DocumentationPath attribute of the associated Project record

Data Element: Requirement

The Requirement entity encapsulates a single requirement in the specification for the project. Detailed definitions of requirements and how they are characterised in the qSDS methodology are specified elsewhere. For this document, it is sufficient to define a requirement as the statement of a condition that a system must meet for it to be accepted into the production environment.

Requirements are a key element in a quality system. All work is evaluated against them, either in review or in testing.

Note that a list of requirements in this form would not constitute the entire requirements documentation. Such documentation normally includes a great deal of explanatory information from the analysis exercise.

ProjectID (32-bit integer, mandatory): A reference to the project to which this requirement belongs
ID (32-bit integer, mandatory): An identifier for the requirement, assigned by the system, and unique within the context of the project
ExternalID (string, optional): An identifier for the requirement that is relevant to the external environment; the organisation may have a specific numbering or nomenclature system not controlled by CASEM
SponsorID (string, optional): An identifier for the requirement that has been assigned by the sponsor (often the customer)
DocReference (string, optional): A reference to a page or paragraph in documentation from which this requirement is drawn
Version (string, optional): An identifier for the version of the software to which this requirement applies
Name (string, mandatory): A human-readable string, identifying the requirement with a brief statement; note that this is not to be taken as the statement of the requirement itself
Statement (string, mandatory): The text of the requirement statement
TypeID (8-bit integer, mandatory): An ID for the type of requirement: 0 = functional, 1 = performance, 2 = reliability, 3 = safety
CriticalityID (8-bit integer, optional, default=1): An ID for the criticality of the requirement: 0 = mandatory, 1 = important, 2 = desirable; see the qSDS Software Engineering Process for more information on the definitions of these criticality ratings

Note that the Requirement entity has a many-to-many relationship with the Design Element and Test Procedure entities.

Data Element: Design Element

A Design Element entity encapsulates any part, module, class or object in the system that may be regarded as atomic for the purposes of traceability. Naturally, such entities are subject to very fine levels of decomposition in design and implementation, but traceability requires a level of abstraction such that design elements correspond to requirements.

Note that the list of design elements does not replace design documentation. Rather, it is derived from it as part of the traceability system.

A Design Element entity has the following attributes:

ProjectID (32-bit integer, mandatory): A reference to the project to which this design element belongs
ID (32-bit, mandatory): An identifier for the design element, assigned by the system, and unique within the context of the project.
ExternalID (32-bit integer, optional): An identifier for the design element that is relevant to the external environment; the organisation may have a specific numbering or nomenclature system not controlled by CASEM
SponsorID (string, optional): An identifier for the design element that has been assigned by the sponsor (often the customer)
DocReference (string, optional): A reference to a page or paragraph in documentation from which this design element is drawn
Version (string, optional): An identifier for the version of the software to which this design element applies
Name (string, mandatory): A human-readable string, identifying the design element with a brief statement
Summary (string, optional): A brief explanation of the design element

Test Procedure

The Test Procedure entity encapsulates a single test, executed to verify the conformance of the system to one or more requirements. It includes the following attributes:

ProjectID (32-bit integer, mandatory): A reference to the project to which this test procedure belongs
ID (32-bit, mandatory): An identifier for the test procedure, assigned by the system, and unique within the context of the project.
ExternalID (32-bit integer, optional): An identifier for the test procedure that is relevant to the external environment; the organisation may have a specific numbering or nomenclature system not controlled by CASEM
SponsorID (string, optional): An identifier for the test procedure that has been assigned by the sponsor (often the customer)
DocReference (string, optional): A reference to a page or paragraph in documentation from which this test procedure is drawn
Version (string, optional): An identifier for the version of the software to which this test procedure applies
Name (string, mandatory): A human-readable string, identifying the test procedure with a brief statement
Summary (string, optional): A summary of test procedure and the system characteristics it is intended to demonstrate
RequirementsTested (list of 32-bit integers, mandatory): A list of references to the requirements that are tested by this procedure; note that a single test may not demonstrate a linked requirement entirely
PreparationSteps (list of ActionSteps, optional): A sequence of steps to be taken prior to the commencement of the test; note that the ActionSteps entity is not defined in this document; briefly, it is simply a description of a single action to be taken, with an optional expected result
TestSteps (list of ActionSteps, mandatory): The sequence of steps to be taken to execute the test; note that the ActionSteps entity is not defined in this document; briefly, it is simply a description of a single action to be taken, with an optional expected result
ShutdownSteps (list of ActionSteps, optional): The sequence of steps to be taken after the completion of the test procedure to shut down the system in an orderly fashion; note that the ActionSteps entity is not defined in this document; briefly, it is simply a description of a single action to be taken, with an optional expected result

Key Technologies and Methods

This section discusses some of the technologies and techniques that may be used in the design and implementation of CASEM.

Object Oriented Methods

Although OO techniques are currently popular in the information industry, there is explicitly no intent to endorse this in qSDS over the alternatives. However, OO methodologies are viewed as appropriate for the execution of the CASEM project.

Java

To make the qSDS truly generic, the CASEM tools must operate on as wide a variety of platforms as possible. For this reason, Java will most likely be the implementation language. This will allow CASEM to be deployed and used across multiple platforms without significant redevelopment effort.

Traditionally, Java has been known to suffer from performance penalties imposed by its run-time environment. This is not viewed as significant for CASEM, since it is not a performance-intensive application. This issue is further mitigated by the

XML

CASEM requires a standard for characterising its information, both in client / server communications and in storage. Ideally, such a standard would be:

	Open - to promote development in multiple streams
	Flexible - for easy manipulation and handling
	Extensible - to allow for changes and improvements

XML fits these requirements admirably. Being a text-based standard, it is not as compact as a binary protocol would be, but the information volumes being communicated are not great, and the commonly available capacity for storage and processing is easily equal to the task of handling information in this form. Also, information in XML is easily viewed and manipulated in ordinary text-based tools.

Thus, the CASEM project will define an XML-based standard for software project information. This will be used in client-server communications, and for information storage.

Further Work

The next step in the development of CASEM is a formal analysis exercise to determine a set of requirements. No schedule exists for this work at the moment.

This site is under construction. Please check back with us again soon. In the meantime, enquiries may be directed to enquiries@qprise.com.