2 Introduction to the Process Model
The process model defines all aspects of
- Activities and products
as well as
- Product states and logical dependencies between activities and products
during project execution.
The process model consists of four submodels (Figure 2-1). Besides the submodel Project Execution (PE), there are the submodels Quality Assurance (QA), Configuration Management (CM) and Project Management (PM). The quality assurance tasks encompass the definition of requirements like test methods and test criteria and all product testing. Results are reported to project management. The goal of configuration management is to create a product, e.g., a document, that is uniquely identifiable in its functional and exterior characteristics. This identification provides for a systematic control of changes and secures integrity. Project management plans, checks and controls the project’s internal activities. It is also the interface to project external units like other projects. The process model controls the interaction between individual submodels. This allows for an allocation of various tasks to different persons or teams and also guarantees a smooth procedure.
Figure 2-1: The four submodels PE, QA, CM and PM
The submodels Project Management (PM), Configuration Management (CM) and Quality Assurance (QA), which describe accompanying activities in a development project, are the same for all process model classes. Therefore they are described in the following. In contrast, the submodel Project Execution (PE) is gravely different for each process model class. For this reason the submodel PE is described separately for each process model class in the second part of this process manual.
For better differentiation the submodel PE has been given separate names for the individual process model classes. They are:
· Software Development (SWD) for the model for software development projects
· Hardware Development (HWD) for the model for hardware development projects
· System Development (SD) for the model for system development projects
and
· Concept Development (CD) for the model for conceptional projects.
For the process model class Open Model no separate name was given to the submodel PE.
2.1 The Organizational Structure
Figure 2-2 shows the organizational structure of the IAS-PM. A software project (software development model) has been used here as an example.
Figure 2-2: Organizational structure of the IAS-PM
A thesis or any other type of student work is executed as a project. The four submodels of the process model are embedded in the organizational structure of the IAS. For the purpose of education in the area of software technology the student will fulfill exercises in all four submodels. The IAS will support the student in the submodels Project Management (PM), Configuration Management (CM) and Quality Assurance (QA). In the submodel software development (SWD) the student is solely responsible for the complete execution of his task. The student’s project might be integrated in a larger project. In the framework of the student’s project a intermediate task of the major project will also be fulfilled.
2.2 Structure and Content of the Process Model
The basic elements of the process model are the activities and products that are executed and processed during the project execution process.
2.2.1 Activities and Products
An activity is an action which can be exactly described in reference to its results and execution. Activities can consist of a row of defined “intermediate activities”, if each of these intermediate activities has its own defined intermediate results.
A product is either the processed object or the result of an activity. Analog to the subdivision of activities in intermediate activities, products may also be subdivided into “intermediate results” (e.g., individual chapters of a document).
An activity can be
- the creation of a product,
- a change in the state of a product or
- the change of product contents.
These basic elements "activity" and "product" are represented by special symbols (see Figure 2-3).
Figure 2-3: Symbols for products and activities
For each activity there must be an activity description in the form of an operation manual, which is to be adhered to during the execution of the activity. If an activity is subdivided into intermediate activities and logical dependencies between intermediate activities and products must be illustrated then the activity schematics must contain an activity subdivision.
Each product must have a product description which defines the contents of the product. The product description occurs according to a fixed pattern, the product scheme. For documents theses schemes are provided in the form of document templates (Word).
2.2.2 Product States
When processing (intermediate) products in the process model, please note that certain products go through different states during the development process. Products may assume the following states:
"in progress"
The product is being worked on. Either it is in the “private” development area of the developer or it is under the control of the developer within the project library.
"submitted"
From the perspective of the creator the product is finished and has been stored under Configuration Management. A Quality Assurance test is performed on the product. If the product is denied by QA then it will return to the “in progress” state, otherwise it will move forward to the “accepted” state. After the “submitted” state the creator can only perform modifications to the product using sequential version numbers.
"accepted"
The product has been tested and released by QA and may only be changed within a new version.
The states and their legal state transitions are shown in Figure 2-4.
Figure 2-4: States and state transitions of products
2.3 Overview of the IAS Process Model
In the following an overview of the activities and products as well as the responsible persons involved is illustrated. A software project, that was regulated by the software development model, will be used as an example.
The activities are assigned to persons with the following abbreviations:
ID: Institute Director
SM: Scientific Staff Members (advisor or co-advisor)
S: Student
DBM: Data Backup Manager
Activities and products that are indicated with these parentheses [] are optional.
Software Development (SWD)
|
SWD
1.1 Determine and define requirements à System requirements SWD 1.2 Analyze requirements Define user interface à Software system model
-> Definitions review (SM, S, ID only for MT)
SWD 2 Design Phase (S) SWD 2.1 Design software system architecture à Software system architecture SWD 2.2 Design and specify software components à Specification of the software components
-> Design review (ID, SM, S)
SWD 3 Implementation Phase (S) à Source programs with integrated documentation -> Implementation review (SM, S)
SWD 4 Integration and Acceptance Phase (S) SWD 4.1 Integrate and install system à Installed system SWD 4.2 Create user manual à User manual
-> Acceptance review (SM, S)
|
|
|
|
Quality Assurance (QA)
QA 1 Process Test (ID,SM,S) QA 1.1 Planning review (ID, SM) QA 1.2 Definitions review (ID, SM, S) à Definitions review protocol QA 1.3 Design review (ID, SM, S) à Design review protocol QA 1.4 Implementation review (SM, S) à Implementation review protocol QA 1.5 Acceptance review (SM, S) à Acceptance protocol
QA 2 Component and System Test (S) QA 2.1 Create test specification à Test specification QA 2.2 Test system components à Test protocol (components) QA 2.3 Test total installed system à Test protocol (system)
|
|
Configuration Management (CM)
CM 1 Configuration Management (S) à CID (Configuration Identification Document)
CM 2 Data Backup (S, DBM) à Reels, disks, CD media
|
|
Project Management (PM)
PM 1 Planning Phase (SM) à User requirements specification -> Planning review (ID, SM)
PM 2 Project Planning (S) à Project plan
PM 3 Project Advisory (SM, S) à Review protocols (from QA 1)
PM 4 Project Finish (S) à Final project report
|
|
General Documents à Literature à Terminology à Abbreviations
|
2.4 Responsibilities
Figure 2-5 shows the responsibilities for the creation of the individual projects during the development process on the example of a software project.
Figure 2-5: Responsibilities for individual products