Bringing Software Quality to the Enterprise

The qSDS Software Engineering Process

Introduction

This document describes a process for the work of creating and deploying software. As such, it is one of the most important parts of the qPrise Software Development System (qSDS).

As a process description, this document is quite general in its scope. It does not include step-by-step procedures, or specific instructions. It is intended to be applicable to a diverse range of technologies and techniques. This document includes a number of definitions for terms that have a specific meaning in this context, and also defines the roles of personnel involved in the process.

In creating this document, it is assumed that the reader has a basic understanding of software engineering.

Definitions

The following terms have specific meanings in the context of this process.

allowable deviation: A non-conformance that does not preclude the passage of the system into the production environment
change: An issue that arises during development that invalidates some part of the requirements or design after these phases are complete
criticality: A measure of the importance of a requirement in deciding whether or not to accept it into the production environment
development environment: The environment in which the system is developed and the work of software engineering is done, as distinct from the production environment.)
duration: The length of time taken to complete a task or project - essentially, the amount of time between the beginning and the end
effort: A measure of the amount of work involved in completing a task or project - usually measured in 'person-time' (i.e. person-hours, person days etc)
fault: A non-conformance that precludes the passage of the system into the production environment
non-conformance: A characteristic of a system (usually under testing) that violates one or more requirements
production environment: The environment in which the completed system is made available to the end-user (as distinct from the development environment); in the case of a contracted project, this may be the installed customer environment; with consumer software, it usually means the packaging and dispatch part of the organisation
project: A sequence of work with a well-defined beginning and end; a project has definite completion objectives and usually has clearly stated constraints of time and resources
requirement: A stated behaviour that a system should exhibit
resource: Any person, object or material used in the execution of a task or project
task: A unit of work in a project; in project management, a task is considered to be atomic and indivisible
traceability: A mechanism for mapping the relationship between requirements, design elements and test procedures;

Process Overview

Sequence of Work

The software development process is executed in five distinct phases, executed sequentially:

	Analysis - determining the requirements for the output system
	Design - proposing a solution to the requirements
	Implementation - executing the design
	Testing - formally validating the implementation against the requirements
	Deployment - moving the completed system from the development environment to the production environment

Process Sequence Diagram

Each of these phases builds on the output of the previous phases, and must be consistent with them. Traceability is the work of ensuring that all parts of the work are consistent and valid in the context of the stated requirements. This is a key quality assurance technique.

Roles

There are a number of distinct personnel roles or parties in the software engineering process:

	Project Sponsor - The Project Sponsor is the party with an interest in the completed result of the project. This is often a customer or a product manager (in the case of product creation), but may also be another part of the organisation. A representative is usually appointed to represent the interests of the Project Sponsor.
	Engineering Manager - The Engineering Manager has overall responsibility for software engineering in the organisation. He or she works with the Quality Manager to set and implement the software engineering process.
	Project Manager - The Project Manager is responsible to the Engineering Manager for the successful execution of the project. He or she interacts with the Project Sponsor, plans the work, and manages its execution. Where project management duties are not heavy, the Project Manager often doubles as a Software Engineer.
	Software Engineer - One or more Software Engineers execute the tasks of the project as assigned by the Project Manager. They follow the directives of the Project Manager, and work within the framework of the software engineering process and its procedures.
	Quality Manager - The Quality Manager has the responsibility of maintaining quality assurance in the organisation. In a process management model, this is done by creating and implementing various documented processes for all activities. The software engineering process is conceived and implemented by the Quality Manager and the Engineering Manager.
	Quality Representative - Every project has a quality representative assigned to it. His or her role is to ensure that the project work complies with the organisation's software engineering process and relevant procedures. The Quality Representative answers to the Quality Manager for this, not the Project Manager. This makes the Quality Representative an 'independent observer' for the work done on the project.

Analysis

In software engineering, analysis is the work of determining and formally defining what is required of the end result of the project. It is beyond the scope of this document to discuss the multiplicity of approaches and methodologies for analysis that exist, but the overall result must be a set of requirements that:

	Are formally defined, in a way that is objective and clear to all parties in the project
	Are readily testable and capable of being demonstrated
	Minimally define the required behaviour of the system to be built

This means that everyone should be able to understand the requirements, that conformance to them can be easily demonstrated, and that there is no redundancy.

Ideally, the list of requirements should be formed such that if the system demonstrates every behaviour specified, it may be passed into the production environment, and that if one or more behaviours are not demonstrated, it may not be passed into the production environment. In practice, this is rarely achievable - specifications often include features that are 'nice to have', or requirements that, if violated individually, might not cause the rejection of the system, but when taken with a number of other failures, might cause the system to be rejected.

Thus, requirements are assigned a criticality as follows:

	Mandatory - Non-conformance to any Mandatory requirement invariably causes the system to be rejected
	Important - Non-conformance to an Important requirement may or may not cause the system to be rejected. Non-conformance to a 'large number' of Important requirements would normally cause the system to be rejected.
	Desirable - Desirable requirements describe behaviour that is non-essential. Non-conformance to such requirements would not normally cause the system to be rejected.

The list of requirements comprises the first part of the traceability matrix. Consult the section on traceability for more information.

The Project Sponsor must ratify the list of requirements, confirming that they do, in fact, describe the system to be built.

Design

The design phase is essentially for proposing a solution to the requirements determined in analysis. All decisions of how the system is to be implemented (that are not mandated by requirements) are made during this phase. These normally include:

	System architecture
	Hardware platforms
	Software architecture
	Development tools
	Standards, methodologies, procedures and rules
	Tasks, resources, effort and schedule

In practice, certain decisions are sometimes deferred to the implementation phase. Of course, the qSDS development philosophy promotes a predictive understanding of software engineering, which means that the nature of a problem and its solution should be thoroughly understood before it is executed, but it is recognised that in the 'real world' this is sometimes not practical. However, a real effort should be made to keep such situations to a minimum.

The system design must be clearly communicated (normally through the medium of documentation) to all participants in the project. It is reviewed against the requirements as part of the traceability activity. The design is finally ratified by the Project Manager, who is ultimately responsible for ensuring that it is internally consistent and both conforms to and covers the requirements.

During the design phase, changes to requirements must be handled using the change management procedures.

Implementation

Ideally, the implementation phase is simply the work of executing the design. As stated above, all major implementation decisions should have been made during the design phase, making implementation a 'paint by the numbers' exercise. In practice, issues do arise during implementation that invalidate elements of the design, or even the requirements. These must be handled using formal change management procedures.

Normal implementation activities include:

	Setting up of development environments and tools
	Setting up of runtime environments for informal testing
	Coding

The implementation is reviewed against the design as part of the traceability activity. This may take the form of code inspections and informal testing (including unit testing). Naturally, this does not replace, or mitigate the need for, a formal testing phase. The Project Manager takes overall responsibility for the conformance of the implementation to the design.

Testing

Testing is the work of formally verifying and demonstrating that an implemented solution conforms to its requirements. This is the final stage of the traceability activity. The first part of this phase is to create the test procedures. This can actually done after the requirements have been determined, but it is often useful to understand the design and implementation of the system when creating tests. Compliance with every requirement from the analysis phase must be demonstrated in at least one test procedure, and tests that do not exercise a requirement should be avoided.

Test procedures should include the following information:

	A statement of the requirements being tested (for traceability)
	Any steps necessary to prepare the system for the test
	The steps for performing the test
	The steps necessary to shut down the system after the test
	The expected results and the criteria by which the results demonstrate the conformance (or lack it) to system requirements

The Project Manager and Project Sponsor must both ratify the test procedures, agreeing that:

	The test procedures exercise and demonstrate the entire set of requirements fairly and objectively
	If the system passes the entire set of tests, it may be accepted for deployment

In the second part of testing (execution), the test procedures are executed as specified. It is important to take an objective and dispassionate approach to this exercise, to obtain an accurate demonstration of the system's conformance to requirements.

The third part of testing is to analyse the test results. Assuming traceability has been fully maintained between test procedures and requirements, it is reasonable to assert that the system conforms to all requirements if it passes all tests.

If the system does not pass all tests, the traceability information can be used to isolate the exact area of non-conformance. Non-conformances may be handled in one of two ways:

The non-conformance may be judged an allowable deviation, in which case it does not preclude passage into the production environment. Allowable deviations are usually non-conformances related only to requirements with a criticality of 'Desirable'.
The non-conformance may be judged a fault, in which case further action is required before the system may be passed into the production environment.

In the event of non-conformances being evaluated as faults, further action must be taken to address these faults. To ensure that repairs have not introduced new non-conformances, the entire set of test procedures must be executed again. This exercise is called Regression Testing.

Acceptance Testing is the execution of test procedures in the presence of the Project Sponsor, as a demonstration of conformance. Factory Acceptance Testing is acceptance testing executed in the development environment. Site Acceptance Testing is acceptance testing executed after deployment, in the production environment.

Acceptance testing is not necessarily mandated in all situations. However, the Project Sponsor must ratify the test results, and participate in and ratify the analysis of the test results.

Deployment

In the deployment phase, the completed system is moved from the development environment to the production environment. Depending on the complexity of the system, this work can take many different forms.

In general, systems developed for a specific end-user are simpler to deploy, because the production environment is the single environment in which the system will actually be used. By way of contrast, systems developed for mass distribution will be used in a wide range of environments, and so require more effort in deployment.

An extended discussion of these issues is beyond the scope of this document, and will be addressed in specific procedural documentation.

Ancillary Issues

The following sub-sections discuss a number of issues ancillary to the software engineering process.

Traceability

Traceability is the mechanism or activity of linking the various aspects of software development work to core requirements. During the work of analysis, requirements are isolated in a formal and objective way. Traceability links these requirements to two other specific pieces of information:

	Design elements
	Test procedures

The following benefits are derived:

	The traceability activity reveals whether or not all requirements are 'covered' by the design, and whether or not any design element violates a required constraint.
	Test failures can be easily characterised as non-conformances to requirements, which readily exposes the implications of test failure, and what aspects of the design or implementation may require attention.

Traceability activities will be outlined in specific procedural documentation.

Documentation

The software engineering process requires that a great deal of information be communicated and understood between people in various roles. For example, the Project Sponsor, the Project Manager and all Software Engineers must have a common understanding of the system requirements.

The most common mechanism by which this communication is achieved is through documentation, and although this process does not mandate documentation as the means of communication, it is highly recommended. Documentation may be in any form or medium that complies with the basic requirements of being commonly accessible and persistent.

Change Management

One of the biggest threats to the integral quality of an engineered solution is unmanaged or poorly managed changes to requirements or design during the development process. Having said this, most projects are subject to such changes, and the software engineering process must allow for them in a formal way.

Changes are managed by a careful integration process that first analyses the highest level at which the change must be effected. That is, the most 'primitive' information affected by the change must be isolated. The traceability information is then used to the implied changes in dependent information.

For example, a change that invalidates a requirement must first be integrated into the body of requirements, followed by corresponding changes to design and test procedures, whereas a change that affects the design but not the requirements may be integrated directly into the design.

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