Quality Assurance Plan

Release Information

Project Siconos
Internal Release Number: 1.0
Last update: September 15, 2005
Attached Worksheets:
QA plan > Quality Report
Related Documents:
ESA software engineering standards
Process impact: This document specifies quality goals, selects strategies for assuring that those goals have been met, and details a plan of action to carry out those strategies.

Introduction


The purpose of the quality assurance plan is to check that the project is consistent with standards and plans which are defined below. As it is recommended by the ESA software engineering standards to small software projects, the Quality Plan combines the following documents for small projects :
  • The software Project Management Plan.
  • The software Configuration Management Plan.
  • The software Verification and Validation Plan.
References
  • "Guide to applying the ESA software engineering standards to small software projects. ", BSSC(96)2, ESA 1996,
  • "Guide to the software project management ", PSS-05-08, ESA 1995,
  • "Guide to the software configuration management", PSS-05-09, ESA 1995,
  • "Guide to the software verification and validation", PSS-05-10, ESA 1995,
  • "Guide to the software quality assurance", PSS-05-11, ESA 1995,

Project Management Plan

Introduction

Software project management is 'the process of planning, organizing, staffing, monitoring, controlling and leading a software project'. This part is based on the ESA ``guide to the software project management'', PSS-05-08, ESA 1995.

This part defines the project management plan of the siconos platform. The project organization and the major features of the technical process are defined. Finally, a work breakdown structure, a schedule with milestones and the roles and responsibilities are provided.

Actually, only the project management plan, and the technical process for Siconos/Kernel and Siconos/Numerics are detailed.

For the more elaborate part of the platform, which are Siconos/Analysis, Siconos/Control and Siconos/IMSE, separated documents will be provided.

Project Organization

Organizational roles and responsibilities


Due to the number of participants in the software project development, the organization of the project is relatively simple. The Work Package 2 (Numerical Methods and Software development) is led by Vincent ACARY (C01), which is also the project manager of the software design and development.

The teams for the design and the development are defined as follows :

  1. Team INRIA (C01):
    • Vincent Acary (VA) (Team Leader, designer, programmer) Vincent.Acary@inrialpes.fr
    • Roger Pissard-Gibollet (RPG) (Software quality leader)
    • Franck Pérignon (FP) (programmer, test engineer , numerical algorithms)
    Former members:
    • Jean-Baptiste Charlety (JBC) (programmer, test engineer , software librarian) (01/2004 to 04/2005)
    • Jean-Michel Barbier (JMB) (programmer, test engineer, software librarian) (01/2004 to 09/2004)
  1. Team LMGC (AC2):
    • Frédéric Dubois (FD) (Team Leader, designer, programmer)
    • Shéherazade Nineb (SN) (programmer)
    Former members:
    • Jean-Michel Barbier (JMB) (programmer, test engineer, software librarian)(10/2004 to 04/2005)
  1. Team Analysis (CR6,CR4,CR9,AC5,CR7,AC12,CR8),
    1. Key Developpers
      • Gustavo Osorio (GA) gosorio@unina.it
      • Ivan Merillas (IM) merillas@mat.upc.edu
      • Petri Piiroinen (PP) petri.piiroinen@bristol.ac.uk
    2. Developpers
      • Fabiola angulo (FA) fangulo@nevado.manizales.unal.edu.co
      • Alan Champneys (AR) a.r.champneys@bristol.ac.uk
      • Enric Fossas (EF) enric.fossas@upc.edu
      • Gino Ianelli (GI) luigi.iannelli@unisannio.it
      • Arne Nordmark (AN) nordmark@mech.kth.se
      • Gerard Olivar (GO) gerard@mat.upc.edu
    3. Testing team
      • Mario Di Bernardo (MdB) m.dibernardo@bristol.ac.uk
      • Kanat Camlibel (KC) k.camlibel@uvt.nl
      • Ugo Galvenetto (UG) u.galvanetto@imperial.ac.uk
      • Stefania Santini (SS) stsantini@unina.it
      • David Wagg (DW) david.wagg@bristol.ac.uk
      • Nathan van der Vouw (NW) n.v.d.wouw@tue.nl
  1. Team "Control", TBD
  2. Team imse, TBD

The roles and responsibilities are roughly distributed in the table 2.1


Table 2.1: Roles and responsibilities
Role Teams
Siconos/Numerics Team LMGC, Team INRIA
Siconos/Kernel Team INRIA, Team LMGC
Siconos/Front-End
Team INRIA
Siconos/Analysis Team Analysis
Siconos/Control Team Control


Organisational interfaces.


The initiators of the project are the members of the Work Package 2. The end users of the platform are the whole community of SICONOS, at least, for the first release. Then further distributions of the software will take into account the requirements of a wider scientific community, and then, of the industrial partners.

The interfaces between the Work Package 2 and the community of users is under the responsibility of the project manager.


Technical Process for the Siconos/Platform


The section below focuses only on the technical process for the Siconos/Numerics and the Siconos/Kernel of the platform. It should be extended for the analysis, control and the imse.

Process model

Definitions of the phases of the design and the development

Following the ESA standards for small projects ESA-PSS050, the following phases of the design and the development are defined :

  • The UR/SR phase. The UR phase is the ``problem definition phase'' of a software project. The scope of the system must be defined. The user requirements must be captured. The SR phase is the ``analysis'' phase of a software project. A vital part of the analysis activity is the construction of a ``model'' describing what the software has to do, and not how to do it. Building prototypes to clarify the software requirements may be necessary. The principal deliverables of this phase are the User requirements Document (URD) and the Software Requirements document (SRD).
  • The AD phase.The purpose of the AD phase is to define the structure of the software. The model constructed in the SR phase is the starting point.This model is transformed into the architectural design by allocating functions to software components and defining the control and data flow between them. The deliverable item which constitutes the formal output of this phase is the Architectural Design Document (ADD).
  • The DD Phase The purpose of the DD phase is to detail the design of the software, and to code, document and test it. The Detailed Design Document (DDD) and the Software User Manual (SUM) are produced concurrently with coding and testing.
  • The TR Phase The purpose of this phase is to establish that the software fulfills the requirements laid down in the SRD. This is done by installing the software and conducting acceptance tests.
  • The OM Phase Once the software has entered into operation, it should be carefully monitored to confirm that it meets all the requirements defined in the SRD. Some of the requirements, for example those for availability, may take a period of time to validate. When the software has passed all the acceptance tests, it can be finally accepted. This is the OM Phase.
Project planning inputs and outputs

The inputs to software project planning are:

  • User requirements
  • Software requirements specification and design documents according to each phases
  • ESA software standards for products and procedures;
  • time constraints, such as delivery dates;
  • resource constraints, such as the availability of staff;

The outputs to software project planning are:

The Table 2.2 summarizes the software products of each phase as required by ESA PSS-05-0. The timetable for the output deliverables will be given in the part schedule.

Table 2.2: Phase input and output products
Phase Input product Output Product
User & Software Requirements (UR, SR) User requirements elicitation Software requirements specification
Architectural Design (AD) Software requirements specification design
Detailed Design (DD) design code
User Manual
Test and Transfer(TR) Quality assurance plan Quality report
Operations and maintenance (OM) Software requirements specification
Quality assurance plan
Project history document

Because the developing staff is small, and in order to maintain the best consistency as possible in the documentation, the number of project documents is reduced in regard to ESA software engineering guides recommendations :

  • The users requirements and software requirements are joined in a common document for all modules of the platform, the Software requirements specification document
  • Every project management, quality process data, and testing plans are joined in a common document Quality Assurance plan
  • Quality and testing reports are both in the Quality report
Global life cycle

The incremental delivery approach, shown in Figure 2.1, is characterized by splitting the DD, TR and OM phases into a number of more manageable units, once the complete architectural design has been defined. The software is delivered in multiple releases, each with increased functionality and capability. This may occurs when certain functions may need to be in place before others can be effective.

Figure 2.1: Software life-cycle and input/output documents according to each phase of development.
Software Life-Cycle

During each increment, software requirements and architectural design documents are reviewed and may be lightly corrected. Detailed design, user manual and testing plans are completed as the work gradually progresses.

This life-cycle was chosen for this project because the Siconos/Kernel and basic functionnalities of the platform have to be validated before the development of specific plugins or of a smart interface.

First increment : platform prototype

This prototype was realized by four students in computer sciences during their final training course. From January to September 2004, they realized a complete increment cycle and they considered this first increment as a complete project development from user requirements elicitation to acceptance tests. To reach this objective, they used a standard software life-cycle approach illustrated on figure 2.2.

Figure 2.2: Software life-cycle and input/output documents according to each phase of development.
V Life-Cycle



Methods and Models

cocomo

This is a cost model for estimating the number of person-months required to develop software. The model also estimates the development schedule in months and produces an effort and schedule distribution by major phases. This model is based on Barry Boehm's accocomo2.1.Here is what Boehm says about the model: "Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on costs." For more detailed information about cocomo and software cost estimating in general, I strongly recommend reading Software Engineering Economics (1981), by Barry Boehm.

The model estimates cost using one of three different development modes: organic, semidetached and embedded. Here is a summary of how Boehm describes the modes:

  • Organic : In the organic mode, relatively small software teams develop software in a highly familiar, in-house environment. Most people connected with the project have extensive experience in working with related systems within the organization, and have a thorough understanding of how the system under development will contribute to the organizations objectives. Very few organic-mode projects have developed products with more than 50 thousand delivered source instructions (KDSI). .
  • Semidetached: The semidetached mode of software development represents an intermediate stage between the organic and embedded modes. "Intermediate" may mean either of two things: an intermediate level of project characteristic or a mixture of the organic and embedded mode characteristics.The size range of a semidetached mode product generally extends up to 300 KDSI.
  • Embedded : The major distinguishing factor of an embedded-mode software project is a need to operate within tight constraints. The product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures, such as an electronic funds transfer system or an air traffic control system.
Design method SA/SD method and diagram
The sd method is an extension to the sa method. This method is based on the analysis of the data flow to get a first level architecture. Then this architecture is evaluated and restructured. This is performed in the seven steps of the method :
  1. Fundamental diagram
  2. Refinement of the data flow diagram
  3. Determination of the kind of diagram
  4. Plan of the frontier
  5. First level architecture
  6. Systematic building of the architecture
  7. Evaluation and restructuring of the architecture
With this method, one can evaluate the cohesion and the links between modules which is very important for the evolution of the software. This method will help us to determine the global architecture. In that way we will be able to design an architecture which will be progressive. The architecture must have low links between the different modules and have a high cohesion.
The sd diagram is a data flow diagram. It represents the input and output of information. It also shows the functions, the data storages and the data flows.
Models / UML methods and Diagram
To build a good architecture of the platform, we will use various modeling languages and tools. According to the type of information, we want to depict, the appropriate model to formally represent data, functions, and behaviours of our system. Among them, we can cite the following diagrams :
The uml diagrams are numerous and can modelise lots of relations of the platform to define an adapted architecture to this platform.
  • uml diagrams.
    We will use uml tools to create uml diagrams. With uml, we can modelise a big part of the architecture with the numerous uml diagrams we will see further, and with ocl.
    • Sequence diagram
      This diagram shows the links of the different actions we can find in the platform. It represents the interactions between the entities of the system.
    • State diagram
      This diagram aims to represent automatons as state graphs. It shows the changes of state of an object or a module in response to the interactions.
    • Collaboration diagram
      This diagram shows the interactions between the objects (instances of classes and actors). It allows to represent the context of an interaction.
    • Classes diagram
      These diagram are collections of classes which show the structure of a model. We use several diagrams for complex models.
  • ocl
    ocl is a declarative language for describing rules that apply to UML models developed at IBM and now part of the UML standard.
    A formal specification language extension to UML. The Object Constraint Language is a precise text language that provides constraint and object query expressions on an object-oriented model that cannot otherwise be expressed by diagrammatic notation.
    OCL supplements UML by providing expressions that have neither the ambiguities of natural language nor the inherent difficulty of using complex mathematics.

Format, style and tools for documentation and the coding standards

All formats, styles and tools for documentation, and the Coding standards are defined in the Software Developpment Methodology

Work Breakdown structure


TODO: List tasks that will be needed for this project. Keep dividing tasks into subtasks until you feel that you have enough detail to expose risks and make reasonable estimates in ideal engineering hours.

1000 Software Project Management

  • 1100 Siconos/Numerics Management
  • 1200 Siconos/Kernel Management
  • 1300 Siconos/Analysis Management
  • 1400 control Management
  • 1500 imse Management
  • 1600 Existing softwares and modeling environments review
  • 1700 Relation with other project (Geoplex, Hycon, DaVinci, ...)
  • 1800 Studying legal aspects and planning APP deposit

2000Siconos/Numerics Software Production

  • 2100 Software Specification phase SSD (Software Requirement and Architectural Design phase)
    • 2110 First Increment Production
      • 2111 Global requirements elicitation
      • 2112 Partitionning of the whole requirements into sets of functionalities
      • 2113 Definition of the priority between sets and of those indispensable
      • 2114 Definition of some ``minimal'' requirements for a given set
      • 2115 Definition of storage method for matrices
      • 2116 ssd draft
      • 2117 ssd final version
        • 2117.1 Global functionalities of the sets
        • 2117.2 Data input and output
        • 2117.3 Interface with C++
    • 2120 Second Increment Production
      • 2121 Inclusion of new sets
      • 2122 SciLab Toolbox
    • 2130 Third Increment Production
      • 2131 Enhancement of included sets
        • 2131.1 Adding some specific storage method for matrices
        • 2131.2 Adding some specific functionalities
        • 2131.3 Tuning existing functionnalities for computation performance.
      • 2132 Interface with other langages (Fortran9x, Python, ...)
  • 2200 Detailed Design phase
    • 2210 First Increment Production
      • 2211 dddSiconos/Numerics for the first increment sets
        • 2211.1 Data Storage descriptions
        • 2211.2 Detailled interface of functions
        • 2211.3 Linear Algebra pack
        • 2211.4 NSS pack
      • 2212 Interface with C++
      • 2213 Unit Testing
        • 2213.1 Problem examples
      • 2214 sumSiconos/Numerics for the first increment sets
    • 2220 Second Increment Production
      • 2221 Inclusion of new sets: ode pack, root finding
      • 2222 SciLab Toolbox
    • 2230 Third Increment Production
      • 2231 Sparse storage method for matrices
      • 2232 Linear Algebra pack for sparse matrices
      • 2233 Integration of ATLAS
      • 2234 Block Sparse storage method for matrices
      • 2235 NSS pack for block sparse matrices
  • 2300 Transfer phase Acceptance testing
    • 2310 First Increment Acceptance testing
      • 2311 Acceptance test suite
    • 2320 Second Increment Acceptance testing
    • 2330 Third Increment Acceptance testing

3000 Platform kernel: Siconos/Engine Siconos/Front-End Software Production

  • 3100 Software Requirements phase
    • 3110 First Increment Production
      • 3111 Requirements elicitation
      • 3112 Prototyping and Logical Model
      • 3113 srd draft
      • 3114 srd final
    • 3120 Second Increment Production
      • 3121 Update srd according to academical users feedback
    • 3130 Third Increment Production
      • 3131 Update srd according to industrial users feedback
  • 3200 External Specification phase
    • 3210 First Increment Production
      • 3211 Describing software using context
      • 3212 Specifying Interfaces
      • 3213 Input/Output data description
      • 3214 Error Cases
    • 3220 Second Increment Production
      • 3221 Precising using context and the categories of users.
      • 3222 Definition and Specification of user interfaces, and tools for their implementation
        • 3222.1 End-user Interface : Scilab interface
        • 3222.2 Expert-user Interface : Python interface
      • 3223 Precise definition for data input/output
        • 3223.1 XML Input/Output
        • 3223.2 Expert-user Interface for data
    • 3230 Third Increment Production (TBC)
    • 3231 Definition of error interface
      • 3231.1 XML database for error messages
      • 3231.2 Internationalization (?)
      • Linking with existing products
  • 3300 Architectural Design phase
    • 3310 First Increment Production
      • 3311 Prototyping and Physical Model
      • 3312 add draft
      • 3313 add final
        • 3313.1 SA/SD method application
        • 3313.2 Unit descriptions (conceptual class diagrams)
        • 3313.3 Simulation course (general sequence diagrams)
    • 3320 Second Increment Production
      • 3321 Design of user interfaces, and tools for their implementation
        • 3321.1 End-user Interface : Scilab interface
        • 3321.2 Expert-user Interface : Python interface
      • 3322 Design for data input/output
        • 3322.1 XML Input/Output
        • 3322.2 Expert-user Interface for data
    • 3330 Third Increment Production (TBC)
      • 3331 Design for data input/output
        • 3331.1 End-user Interface for data
  • 3400 Detailed Design phase
    • 3410 First Increment Production
      • 3411 ddd draft
        • 3411.1 UML Class Diagram
        • 3411.2 I/O management : XML, "on the fly" nonsmooth dynamical system creation
        • 3411.3 Software Deliverable Architecture
      • 3412 First version of the code
        • 3412.1 Model formalisation Unit
        • 3412.2 Model strategy Unit
        • 3412.3 XML I/O Unit
        • 3412.4 Front-end Unit
        • 3412.5 Numeric tools Unit
      • 3413 Unit Testing
        • 3413.1 CppUnit tests
    • 3420 Second Increment Production
      • 3421 Application Programing Interface
        • 3421.2 Python interface
        • 3421.3 Scilab interface
      • 3422 User Interface Unit
        • 3421.1 Scilab interface
        • 3421.2 Python interface
      • 3423 Model Formalisation Unit Production
      • 3424 Numerical Simulation Unit Production
      • 3425 LMGC90 Unit Production
      • 3426 XML schema 1.1 compliance
    • 3430 Third Increment Production TBD
  • 3500 Transfer phase
    • 3510 automatic configuration (using Autoconf / Automake)
    • 3520 Portability
      • 3521 Linux Platform (OS:Red Hat 9, Fedora Core2)
      • 3522 UNIX Platform (OS:Solaris)
      • 3523 Windows Platform (OS : Windows 2000/XP, Cygwin environment)
    • 3530 Software Transfer Documentation
      • 3531 Completing Software User Manual
      • 3532 Installation documentation
  • 3600 Platform Testing
    • 3610 First Increment Testing
      • 3611 Templates systems and Benchmark definition
      • 3612 Integration and system testing
      • 3613 Acceptance Testing
    • 3620 Second Increment Testing
      • 3621 Templates systems and Benchmark definition
      • 3622 Integration testing
      • 3623 System Testing
      • 3624 Acceptance Testing
    • 3630 Third Increment Testing
      • 3631 Templates systems and Benchmark definition (model plugin library)
      • 3632 Integration testing
      • 3633 System Testing
      • 3634 Acceptance Testing

4000Siconos/Analysis Software Production TBD

  • 4100 Software requirements phase SRD
    • 4110 First Increment Production
      • 4111 Requirements elicitation
      • 4112 Prototyping and Logical Model
      • 4113 Anaylys/SRD draft
    • 4120 Second Increment Production
    • 4130 Third Increment Production
  • 4200 External Specification phase
    • 4210 First Increment Production
      • 4211 Specify software using context
      • 4212 Specify interfaces
      • 4213 Input/Output data description
      • 4214 Error cases
    • 4220 Second Increment Production
    • 4230 Third Increment Production
  • 4300 Architectural Design phase ADD
    • 4310 First Increment Production
      • 4312 Prototyping and Physical Model
      • 4313 Siconos/Analysis/ADD draft
      • 4314 Siconos/Analysis/ADD final
        • 4314.1 SA/SD method application
        • 4313.2 Unit descriptions
        • 4314.3 Simuation course
    • 4320 Second Increment Production
    • 4330 Third Increment Production
  • 4400 Detailed design phase
    • 4410 First Increment Production
      • 4411 First increments of the anlysis/ADD
        • 4411.1 Brute-force Bifurcation diagrams
        • 4411.2 Domain of attraction calculations
      • 4412 First version of the code
    • 4420 Second Increment Production
      • 4421 Addition to the Siconos/Analysis/ADD
        • 4421.1 Location of fixed points
        • 4421.2 Location of limit cycles
        • 4421.3 Continuation of fixed points
        • 4421.4 Continuation of limit cycles
      • 4422 Updated version of the code
    • 4430 Third Increment Production
      • 4431 Addition to the Siconos/Analysis/DDD
        • 4431.1 Location of standard bifurcations of limit cycles
        • 4431.2 Location of nonsmooth bifurcations of limit cycles
        • 4431.3 Continuation of standard bifurcations of limit cycles
        • 4431.4 Continuation of nonsmooth bifurcations of limit cycles
      • 4432 Updated version of the code
  • 4500 Unit testing
    • 4510 First Increment Testing
      • 4511 Template systems and benchmark definitions
      • 4512 Integration Testing
      • 4513 System Testing
      • 4514 Acceptance Testing
    • 4520 Second Increment Testing
      • 4521 Template systems and benchmark definitions
      • 4522 Integration Testing
      • 4523 System Testing
      • 4524 Acceptance Testing
    • 4530 Third Increment Testing
      • 4531 Template systems and benchmark definitions
      • 4532 Integration Testing
      • 4533 System Testing
      • 4534 Acceptance Testing
  • 4600 Transfer phase Acceptance testing
    • 4610 First Increment Testing
    • 4620 Second Increment Testing
    • 4630 Third Increment Testing

5000 Siconos/Control Software ProductionTBD

  • 5100 Software Requirements phase SRD
  • 5200 Architectural Design phase ADD
  • 5300 Detailed Design phase
  • 5400 Unit testing
  • 5500 Transfer phase Acceptance testing

6000 Siconos/Pre-Post Software ProductionTBD

  • 6100 Software Requirements phase SRD
  • 6200 Architectural Design phase ADD
  • 6300 Detailed Design phase
  • 6400 Unit testing
  • 6500 Transfer phase Acceptance testing

Description of the major workpackages


In the section above, six work package has been defined. This first work package, ``1000 Software Project Management'' to the general management of the project. The last three packages are not yet defined in details.

We will described, in the following section, the two major work package which are ``2000 Siconos/Numerics Software Production'' and ``3000 Platform kernel Siconos/Engine Siconos/Front-End Software Production''.

2000Siconos/Numerics Software Production

According to the numbering convention of the functionalities in the srd, the increments of software production must contain :

2310 First Increment Production
Linear algebra pack : F-1.001; F-1.003.1; F-1.003.2; F-1.010.1;
NSS Pack : F-1.011.1; F-1.011.1; F-1.011.2;F-1.011.3;
Numerics API C++ interface : F-1.020.1
2320 Second Increment Production
ODE Pack : F-1.012;
MatLab interface : F-1.020.2
2330 Third Increment Production
Linear algebra pack optimisation : F-1.002
Matrices storage methods : F-1.011.4;
Root finding : F-1.013
Automatic, analytical and numerical differentiation : F-1.014

This work package is realized by the SICONOS/Numerics defined in the Section 2.2. Only S. Nineb, which is a PhD Student hired by the project will work full time for 6 months on this development. With the other participants, the total resources for this work package may be estimated around 10 man.month. These resources are only sufficient for the design and the development of the first increment. For others increments, it must be planned to hire an other person.

3000 Platform kernel Siconos/Engine Siconos/Front-End Software Production

According to the numbering convention of the functionalities in the srd, the increments of software production must contain :

3310 First Increment Production 
API C++ : F-2.000 to F-2.006; PER.00
XML format : F-2.300 to F-2.303;
User Plug-in : F-2.200;
Modeling : F-2.010.1; F-2.010.2; F-2.011.1;F-2.011.3; F-2.012.1; F-2.012.3; F-2.013.1.a;
Simulation : F-2.100; F-2.103 to F-2.106;

3320 Second Increment Production
API C : F-3.001;
Interface between the API C and Scilab TBD
Interface between the API C++ and Python TBD
Modeling : F-2.013.2;
Simulation : F-2.101

3330 Third Increment Production
Output and Trace values: F-2.304
Dedicate Softwares plug-in: F-2.202
The rest of functionalities.TBD


This work package is the core of the platform. It is realized by Frédéric Dubois, Vincent Acary and two software engineers who are hired for 6 month. The total resources for this work package is around 36 man.month. This will be sufficient to carry out the first and the second increments. To carry out the third increment, it is planned to hire a software engineener for the year 2005.

Schedule and Milestones

The two following tables present the general planning of SICONOS/WP2.
Definition of Milestones
ID Desciption of the milestone Schedule



M1.a
  •  numerics: srs draft and NSS pack
March 2004
M1.b
M2.a June 2004
M2.b
  • Documentation and Quality reports
September 2004
M3.a
  • Numerics : first increment complete
  • Kernel 1 : API C and C++
  • Kernel 2 : Numerics integration, Numerical and model formalisation

January 2005
M3.b
  • Numerics : Second increment complete
  • Kernel
    • Python and Scilab interface, portability
    • coupling LMGC90 to the platform
    • First Benchmarks and Demonstation examples
March 2005
M4.a
  •  Kernel :
    • Third Increment production (model and numerical formalization)
    • Model Plugin Library (Benchmarks and Demonstation examples)
  • Analysis : Evaluation of the Kernel and Numerics (T1)
June 2005
M4.b
  • Numerics : Third increment complete
  • Kernel : First distribution version with Scilab and Python Interfaces
  • Analysis : First development increment complete (T2 & T3)
September 2005
M4.c
  •  Analysis : First validation increment complete (E2 & E3)
December 2005
M5
  • Analysis : Second development increment complete (T4 & T5)
  • Control : First increment complete TBC
March 2006
M6
  • Analysis : Second validation increment complete (E4 & E4 & E6)
  • IMSE : Design and implementation TBC
September 2006

Human resources assignment and budget


TODO: Recall the human resources and budget. How it has been used actually ?

Configuration Management Plan

Tool for configuration management : Subversion

We use subversion as a revision control system. Subversion is an open-source revision control system, which aims to be a compelling replacement for CVS.

The following rules have to be respected by all users of siconos SVN server :

  • Write  logs in english
  • Except very particular cases, commit only sources which succesfully compiles (and pass tests for the code). This rule is valid as much for documents as source code.
  • Correct possible conflicts before committing your work.
  • Official documents of WP2 are stored on SVN server.

Documents


The documents concerned by this section are official project documents, such as Software requirements specification and design documents. These documents are written in english and the last validated version must be downloadable on Siconos Gforge web site in a PDF format file. After each major update , a document must be validated by a team leader and its version number increased. The current version of these document is available on SVN project server. To get more details about Documents writing process, see the Software Development Methodology document.


Verification and Validation Plan

Introduction and contents

The Verification and Validation plan is divided into three phases :

  1. Unit testing Plan: In the phase of unit tests, one verify that the software subsystems and components work correctly in isolation, and as specified in the detailed design (see ddd). The set of unit tests are defined for each increment in the section Unit testing Plan.
  2. Integration testing plan: In the phase of integration tests, one verify that the major software components work correctly with the rest of the system, and as specified in the architectural design (see add). The set of integration tests are defined for each increment in the section Integration testing Plan.
  3. System and Acceptance testing plan: In the phase acceptance tests, one verify that the software system meets the user requirements (see srd and esd). The set of acceptance tests are defined for each increment in the section System and Acceptance testing Plan

These verification activities demonstrate compliance specifications. This may be done by showing that the product: performs as specified; contains no defects that prevent it performing as specified.

The results of the verification and validation plan will be found in the qr.

Organisation of the reviews to meet the plan

Reviews and meeting are regularly organized to present the work done. People concerned by these reviews are all the development team members and also the persons in charge of the development team.

That's the group leader who manages reviews and decides the main goal of the review.So call-conference are organised between the inria (Grenoble) and the lmgc (Montpellier). Moreover, meetings are planned in one or the other city.

During these reviews, the accomplished work is presented and present people must have read the new or modified documents.

Unit testing plan

Unit test tools

The tool used to do the unit tests is CppUnit. CppUnit is the C++ port of the famous JUnit framework for unit testing. It allows to make test suites on each independant module which must be tested.

Scope of the Unit test plan

The following module have been included into the unit test plan : For each tested module, the unitary tests have to be performed successfully before validating changes in the software.

Objectives

The aim of these tests is to ensure that all the functions of the tested module are doing that they have to do and that they are doing that in the right way. The tests must show that the behaviour of each function is the one which was expected. The Unitary tests ensures us of the correct functioning of low level operations that will be used at higher level.

Satisfaction criterion

The unitary tests have to ensure :
  • The reliability (right behaviour of the tested functions)
  • The robustness (exception management)
These criterion ensure us that basic functions behave as we expect. With CppUnit, each test suite ends with a summary of the passed and failed tests. To validate the modifications of the source code, it is required that no test failed.

Description of some specific unit tests

SiconosMatrix and SiconosVector unitary tests
  1. Constructors and destructors :
  2. Comparison operator :
  3. Reading and writing in files :
    A vector and a matrix are saved into a file, then they are read and the read values must be equal to the origin values. Binary and ASCII storages are tested.
  4. Add function :
  5. Affectation operator :
  6. "linear solve" function :
  7. Getter and Setter :
  8. Computation operators ( +, -, *, /, ) :
  9. blockMatrixCopy :
    The block matrix must be well copied into the current matrix, wherever it is copied. Exception are rose when the copy would have been overflow.
  10. Exceptions :
XML module unitary tests
  1. Get methods :
    They are the basics operations of the module. For each class of the XML management module, getter functions must be able to read data from an xml DOM tree. The reading of an XML file give us the way to tests getters and setters.
  2. Access to inherited objects :
    The structure of the XML management module uses inheritance and polymorphism. The use of generic classes to store information must allow to grant the access to specific class attributes. Tests are trying to call specific methods of generic pointer using static casting, and polymorphism is tested by calling methods that are not implemented in parent class but only in child class.
  3. Exception management :
    Bad manipulations of data structures have to launch exceptions. Each exception which could be launched has to be tested.
  4. XML toolbox (SiconosDOMTreeTools) :
    Basic XML operations are managed with the SiconosDOMTreeTools "toolbox". Access to the DOM tree containing XML data read from an XML file is given with SiconosDOMTreeTools functions. These low level methods are very important for all the XML management module. Tests consists in manipulating the data of the DOM tree. So test suites are reading/writing in the DOM tree with getter and setter functions. Also the modification, add of new nodes and attributes with specific method are tested, and a tool function which transforms a string into a vector of double numbers. Alle these functions have to be tested unitarily.
Siconos/Numerics
TODO: Add a list and more detailed descriptio of the unit tests actually implemented in the Siconos/Kernel and in Siconos/Numerics

Integration testing plan

Introduction

At first, we must know the software is a scientific computation platform. It's compouned of two main parts. The first part is made of a formalization module and a solving strategy one. This part is the intelligence of the software. In front of that, the second part which manage XML data, has the same structure that the first part.
The selected integration strategy is a progressive integration by subsystem, where the subsystems were these defined during the conception. The first subsystems are the formalization and the solving strategy modules of the platform. Then all the XML management module has been integrated to the growing platform. The plugins were added once the platform was built.

This document aims to present the tests done to validate the integration of the platform. The modules concerned are the formalization, the solving strategy and the XML management.
This plan will highlight the communications between the various modules, to check the good unfolding of the communications.
In this document you will find two main parts :

  • a File part, which defines the development simulation used and the satisfaction criteria.
  • a Result part, which explain the results of the tests and analyze them.



Tests file

These integration tests are done during the development of each module within the assigned time. They began when the API was complete and when the development was enough advanced.
  • Testing simulation
The tests are built to check all the links between modules and that the communications are well done.
  • Satisfaction criterions
The tests are validated by the person in charge for the tests and for quality. They must clearly show that the communication between modules are established, and the good and complete unfolding of all the tests. The test suite must test all the ways of communication between the modules. The XML test file is complete and exhaustive for all the objects the platform manages.
  • Development of the tests
    • Communication tests between simulation an the formalization (Work breakdown structure.3611)
    • With this test, we verify that the communications between each OneStepIntegrator and his DynamicalSystem are well established, and like that each OneStepNSProblem is well associated with his Interactions. This link is one-way, so we will check thatthe objects of the solving strategy module can display the name of the formalization module's object which is associated to it.
    • Communication tests between the XML management module and the remainder of the platform (Work breakdown structure.3611.1, 3611.2, 3611.3) 
    • In this test, we check that the reading of an XML inpt file will create the link between the XML management module's objects and the formalization and solving strategy modules' objects. Indeed, when an XML input file is read, all the XML objects are created, and then, the other object of the platform must be created. The basement of the platform id the "Model" object type. It is a Model that will launch the reading of the XML input file. When the XML objects are created, the Model will begin to create and link the formalization ad simulation objects to the XML objects. We ensure oneself of the exactitude of the result by checking the called functions during the unfolding of the test. All the methods called will print to the screen their name in a log file, so it is easy to see what happen. The resulting data of this test consists in a serie of method call that we can compare with the XML input data.
    • Communication tests between the plateform and the XML management module (Work breakdown structure.3611.3) 
    • In this test, we check that the communications between each object of the platform are well done with the XML object associated to it. In this way of communication, it correspond to the save of the platform data to an XML file. We ensure oneself of the exactitude of the result by checking the method called in the log file. Moreover, the XML output file must be similar to the input file because no computations have been made with the data.
    • Communication tests between the platform and these plugins (Work breakdown structure.3611.4)
    • This test must show tht the platform use the methods given with the plugins. To do that, we check the log file where the functions of the plugins must have made specific outputs.

System and Acceptance testing plan


Introduction

At first, we must know the software is a scientific computation platform. It is composed of two main parts. The first part is made of a formalization module and a solving strategy one. This part is the intelligence of the software. In front of that, the second part which manage XML data, has the same structure that the first part.

This document aims to present the tests done to validate the functioning of the platform.
In this document you will find two main parts :

  • a File part, which defines the development strategy used and the satisfaction criterions.
  • a Result part, which explain the results of the tests and analyze them.

Tests file

The acceptance tests have been realized during the development of the plugin which allowed to simule the fall of a ball on a rigid plan. It is a very simple example, but it allows to validate the stages order of the simulation, the functioning of mechanisms for saving and loading xml data as well as the plugins' mechanism of the platform.
  • Testing simulation
The test takes place in the following way : we read an input data file; file written with the moad, then we do computations on the desired number of steps. The results are validated by the moad.
  • Satisfaction criterions
The acceptance tests are validated by the person in charge for the tests, for the quality and by the moad. The acceptance tests are based on the requirements expressed by the customer in the srd.
The tests detailled in this document are based in the op, which is the milestone until june 2004.
  • Development of the tests (Work breakdown structure.3612) 
    • XML input file (Work breakdown structure.3611.1, 3611.2) 
    • It consists in the description of 2 Lagrangian systems :a ball and a rigid plan. They are represented as Lagrangian Time Invariant Dynamic Systems.
    • Ball simulation test (Work breakdown structure.3612.1)
    • For this test, a plugin : BallPLugin.c, has been developped to calculate specific functions of this problem (calculation of inertia, of the mass and external forces).



Miscellaneous


Why is this QA plan needed?
"Quality" refers to all the good things that we would like to see in our product. We build a quality product and assure its quality by keeping quality in mind all the time and performing the selected activities below. Testing is one QA activity, but it is not the best or only one, other QA activities include the use of style guides and checklists, review meetings, use of analysis tools, and careful quality measurements and estimates. A plan is needed to select and coordinate all the QA activities.