Difference between revisions of "UMDQualityCriteria Generic"
Line 1: | Line 1: | ||
== Documentation == | == Documentation == | ||
Line 6: | Line 5: | ||
=== Functional description === | === Functional description === | ||
==== Description ==== | |||
Document with a functional description of the component | |||
==== Verification ==== | |||
Existence and quality of the document | |||
=== User documentation === | === User documentation === | ||
=== Description === | ==== Description ==== | ||
User guide describing the functionality of the software and how to use it | User guide describing the functionality of the software and how to use it | ||
=== Verification === | ==== Verification ==== | ||
Check availability of user guide. Check completeness of user guide. | Check availability of user guide. Check completeness of user guide. | ||
== Man pages == | === Man pages === | ||
=== Description === | ==== Description ==== | ||
Commands must include documentation on its usage and options. It may not be applicable to services without user interface commands | Commands must include documentation on its usage and options. It may not be applicable to services without user interface commands | ||
=== Verification === | ==== Verification ==== | ||
Availability of man pages. | Availability of man pages. | ||
== API Documentation == | === API Documentation === | ||
=== Description === | ==== Description ==== | ||
If service has an API, include documentation of all its functions. | If service has an API, include documentation of all its functions. | ||
=== Verification === | ==== Verification ==== | ||
Availability of API documentation. | Availability of API documentation. | ||
== Administrator Documentation == | === Administrator Documentation === | ||
=== Descrpiton === | ==== Descrpiton ==== | ||
Administrator guide describing installation, configuration and operation of the system | Administrator guide describing installation, configuration and operation of the system | ||
=== Verification === | ==== Verification ==== | ||
Availability and completeness of the guide. | Availability and completeness of the guide. | ||
== Service Reference Card == | === Service Reference Card === | ||
=== Description === | ==== Description ==== | ||
For each of the services that the component runs, include the following documentation: | For each of the services that the component runs, include the following documentation: | ||
Line 68: | Line 67: | ||
|} | |} | ||
= Source Code Quality = | == Source Code Quality == | ||
The source code of each component of the UMD middleware should follow a coherent and clear programming style that helps in the readability of the code and eases maintenance, testing, debugging, fixing, modification and portability of the software. Open source components must publicly offer their source code and the license with the binaries. | The source code of each component of the UMD middleware should follow a coherent and clear programming style that helps in the readability of the code and eases maintenance, testing, debugging, fixing, modification and portability of the software. Open source components must publicly offer their source code and the license with the binaries. | ||
== License == | === License === | ||
=== Description === | ==== Description ==== | ||
All UMD components must have a compatible license for using it in the EGI infrastructure | All UMD components must have a compatible license for using it in the EGI infrastructure | ||
=== Verification === | ==== Verification ==== | ||
Check the component license | Check the component license | ||
== Source Code Availability == | === Source Code Availability === | ||
=== Description === | ==== Description ==== | ||
Open source code must provide pointers to the source | Open source code must provide pointers to the source | ||
=== Verification === | ==== Verification ==== | ||
Existence of source code | Existence of source code | ||
== Build Procedures == | === Build Procedures === | ||
=== Description === | ==== Description ==== | ||
Open Source components should provide a documented and reproducible build procedure | Open Source components should provide a documented and reproducible build procedure | ||
=== Verification === | ==== Verification ==== | ||
Existence of build documentation. Existence of automatic build procedures. | Existence of build documentation. Existence of automatic build procedures. |
Revision as of 17:20, 22 September 2010
Documentation
Services in UMD must include a comprehensive documentation written in a uniform and clear style. All Quality Criteria described below may be met by a single document that contains all the requested sections.
Functional description
Description
Document with a functional description of the component
Verification
Existence and quality of the document
User documentation
Description
User guide describing the functionality of the software and how to use it
Verification
Check availability of user guide. Check completeness of user guide.
Man pages
Description
Commands must include documentation on its usage and options. It may not be applicable to services without user interface commands
Verification
Availability of man pages.
API Documentation
Description
If service has an API, include documentation of all its functions.
Verification
Availability of API documentation.
Administrator Documentation
Descrpiton
Administrator guide describing installation, configuration and operation of the system
Verification
Availability and completeness of the guide.
Service Reference Card
Description
For each of the services that the component runs, include the following documentation:
Service | ServiceName |
---|---|
Description | Description of the service |
Init scripts | List of init scripts for the service, expected run levels |
Daemons | List of daemons needed for the service |
Configuration | List of configuration files used by the service |
Logs | List of log files used by the service |
Open ports | List of ports the service uses |
Cron | List of crons used by the service |
Any other relevant information | Include here any other relevant information about the service |
Source Code Quality
The source code of each component of the UMD middleware should follow a coherent and clear programming style that helps in the readability of the code and eases maintenance, testing, debugging, fixing, modification and portability of the software. Open source components must publicly offer their source code and the license with the binaries.
License
Description
All UMD components must have a compatible license for using it in the EGI infrastructure
Verification
Check the component license
Source Code Availability
Description
Open source code must provide pointers to the source
Verification
Existence of source code
Build Procedures
Description
Open Source components should provide a documented and reproducible build procedure
Verification
Existence of build documentation. Existence of automatic build procedures.