Projektlaufzeit: 2000-2001
TEAM
Test execution and test management are essentially important for Quality Assurance (QA) purposes. Within the IST-funded project "TEAM - Test Execution and Test Management for Numerical Control Software" this is demonstrated by the example of an open and modular control system of the company Industrielle Steuerungstechnik GmbH (ISG). This so-called “Numerical Control” (NC) is used for machine tools and manufacturing units.
Type of Action: | Take up Action, Best Practice |
Key Words: | Test, Test Management, Quality Assurance |
Objectives
The main technical objectives are the improvement of the NC test execution and the improvement of NC test management. This will result in a process improvement by test process improvement. Due to this improvement the number of errors in released software components will reduce and a large number of errors will be detected in early development phases. The increase of the test effectiveness will increase the test run frequency while the overall test effort will decrease. So higher quality with less effort shall be achieved.
The improvement of the test process will improve the quality of ISG's NC components. This will lead to a higher acceptance of ISG's NC on the market. This will also open up new markets for NC applications. As the test effort becomes a calculable part within the software development process due to the improvement of the test management, ISG expects an improvement for the project management.
Description of work and work plan
The workpackages can be distinguished into three main parts: The organisational Workpackage (WP), technical WPs and accompanying WPs.
The workpackage for project management (WP 1) will include all efforts necessary for the administration and organisation of the TEAM-project's resources. Beside the planning and controlling of efforts one focus within WP 1 will be the co-operation with other actions within a co-ordination framework. Furthermore the activities for writing reports and deliverables are assigned to this workpackage.
The technical WPs are executed one after the other. Beginning with WP 2 (Tailoring) the basis for WP 3 and WP 4 can be formed. After the examination within WP 2 which analytical QA activity are suitable, the chosen analytical QA activities are set up for the baseline project within WP 3. This workpackage will result among other things in first experiences about the effort the different QA activities require. So both, the results of WP 2 as well as the results of WP 3, are relevant for the final definition of the constructive QA activities within WP 4.
For an on-going evaluation of the project the WP measurement activity (WP 5) is included in the workplan. Relevant data, that will be defined in detail within measurement activity 1 (WP 5.1), will be recorded and evaluated. So it is possible to influence the project towards a successful execution at any time.
Within the Training Activities (WP 6) the core team of the TEAM-project (2 software developers) will teach the software developers of ISG involved in development of baseline project components.
To transfer the results of the TEAM-project to an interested target audience ISG will establish a particular workpackage for dissemination activities (WP 7). Presenting the resulting experience on national and international events and publications ISG will address the transferability of the TEAM-project's results.
Milestones and expected results
The project management (WP1) will result in the provision of all reports/deliverables.
Each of the technical WPs (WP2, WP3, WP4) will conclude when the respectively defined objectives will be achieved. This objectives are the conclusion of the Tailoring (WP2), the concluded set up of analytical QA activities (WP3) and the concluded set up of constructive QA activities (WP4).
The accompanying activities (WP5, WP6, WP7) will result in the achievement of specified objectives and deliverables.
Baseline project
As ISG’s software development process is a continuous further incremental development system ISG intends to use the mainbranch of the NC kernel as underlying baseline project for the TEAM-project.
The way of developing NC software components is called ”further incremental development” as the resulting increase of functionality of NC components is mainly realised by functional extensions of the software of existing NC components (Fig. 1). Due to the large scope of the already existing basic functionality of modern NC software (about 200 person-years of development effort), the set-up of a new NC software version is based on the existing basic functionality of previous versions.
This explains, why software development projects at ISG are never projects with complete new software but are always the extension of existing and reused software components. This development is executed at ISG within different project specific branches, that contain the necessary software components for the respective purposes. A project is either executed on behalf of a customer or on behalf of ISG on its own in order to offer new applications on the NC market after completion of the project. All project results are merged into the so-called mainbranch of ISG. Some of ISG’s internal development projects are also directly realised within this mainbranch. This mainbranch is used as origin for new branches at the outset of customer projects.
Choice and justification for the V-Model
ISG decided to apply for the TEAM-project on basis of the V-Model regulations as this regulations describe mature and internationally recognised activities for software development. The structure of the V-Model with the division into the submodels system development, project management, configuration management and quality assurance fits ISG’s understanding of sharing activities and responsibilities. The subdivision of the individual submodels in different activities makes the V-Model manageable and clear. Due to the Tailoring, which is defined within the V-Model’s documentation, it is possible to adapt V-Model’s regulations exactly to the actual requirements of ISG.
A further argument for the use of the V-Model within the TEAM-project is the positive experience, ISG gained within the InCoMM-project, executed as an ESSI-PIE project. In this project ISG introduced a CM model to ISG NC software following the V-Model regulations.
Also during the InCoMM-project it became obvious, that the QA activities described within the V-Model’s regulations will fulfil ISG’s demands. Furthermore the QA activities would exactly complement the already existing CM activities, introduced within the InCoMM-project. Basing on InCoMM’s results the analytical and constructive QA activities can be set up.
The execution of the InCoMM-project according to the V-Model resulted also in a comprehension of ISG’s software developers of the structure and the advantages of the V-Model. Among other things this comprehension could be guaranteed due to the executed training and internal dissemination activities within the InCoMM-project.
The choice for the V-Model was done as it contains regulations for analytical QA activities as well as constructive QA activities. All other test strategies, assessment planning, etc. described within literature mostly consider either the analytical or the constructive QA activities. But ISG expects the main improvement in the field of QA in a parallel improvement of the analytical and constructive QA activities. An improved test execution would not improve the software quality at ISG without an effective use of it. In the same way an improved test management would be ineffective without suitable test methods.
Furthermore ISG was looking for a kind of guideline for the improvement of its QA activities. The QA submodel of the V-Model can be used as a guideline, as the V-Model is established as a lifecycle process model. Other publicly available and originally considered models are either assessment methods (CMM, Bootstrap, SPICE), Norms (ISO900x) or developed for individual software developers (PSP) and therefore not suitable for the process improvement ISG wants to carry out.
Disseminations and cluster activities
Euro SPI 2001:
Dissemation_EuroSPI2001.PDF (141KB, PDF)
Presentation_EuroSPI2001.PDF (407KB, PDF)
Cluster activities:
According to the DOW of the TEAM project dissemination activities within a cluster were executed. For this purpose the cluster, consisting out of the REINDEER project and the TEAM project, executed two presentations. One presentation was performed in Turin at the 16th November 2001 and one presentation was performed in Stuttgart at the 21st February 2001.
The target audience for this presentations were the software developers of the company FIDIA S.p.A. and the software developers of the companies ISG and FISW Steuerungstechnik GmbH. As all software developers of the mentioned companies are dealing with component based software for automation systems, an effective transfer of the project results to the software developers was guaranteed.
Project results
General deliverables D1 | |
General deliverables D5 | |
General deliverables D6 | |
Analytical QA actvities D2.1 | |
Analytical QA actvities D2.2 | |
Constructive QA actvities D3.1 | |
Constructive QA actvities D3.2 | |
(Please contact ISG!) | Restricted Documents (7) |
Reports/Plans DP | |
Reports/Plans IR | |
Reports/Plans TIP | |
Reports/Plans FR | |