= Code Quality Evaluation Guidelines =
[[TOC]]

== General Requirements ==

The general quality requirements are defined here as attributes of the solution that is to be evaluated ("The solution must be ...").

These attributes are grouped in four quality "levels" - a higher level representing a higher quality standard. 

In order to pass a level, all criteria of this level and all previous levels must be fulfilled.

||=Level=||=Priority (MoSCoW)=||=Key Attributes=||=Description=||
||1 - '''Minimal'''||Must||valid, correct, safe||minimum standard that must be met by any solution to be considered a "solution" at all||
||2 - '''Appropriate'''||Should||usable, maintainable, secure||minimum standard for production use||
||3 - '''Good'''||Can||integrated, configurable, robust||goals of long-term development||
||4 - '''Optimal'''||Want||efficient, scalable, interoperable||goals of optimization efforts||

Projects can refer to these levels to define minimum quality goals, to prioritize certain quality aspects vs. other requirements, or to define an iterative approach of continuous quality improvement.

=== Level 1: Minimal ===

==== Valid ====

''"Writing the right code"''

  * The specified solution solves the targeted problem and meets the minimum functional requirements
          
  * The required input data are available in the target scenario
        
  * The user actions required to apply and/or use the solution or its responses are ''possible'' in the target scenario
          
  * All dependencies of the feature set are resolvable, and hardware and infrastructure requirements can be met in the target scenario

==== Correct ====

''"Writing the code right"''

  * Processing does not fail for any valid input data or user action.
          
  * All responses are correct for the respective input data or user actions according to the specification

==== Safe ====


  * The solution does not break functionality of the application (except for functionality it replaces)
          
  * All processing always ends with a valid database status regardless whether it succeeds or fails

  * All failed processes are effectively removed from the system and their transactions properly rolled back
          
  * The solution effectively prevents uncontrolled indefinite object or process proliferation

  * The solution always returns to a defined system status after a failure so that the application remains accessible

=== Level 2: Appropriate ===

==== Secure ====

  * The solution applies all relevant system configurations for authentication, authorization and accounting (AAA) appropriately and correctly.

  * The solution does not allow the user to perform actions or initiate processes beyond the intended functionality.

==== Usable ====
==== Maintainable ====

=== Level 3: Good ===

==== Integrated ====
==== Configurable ====
==== Robust ====

=== Level 4: Optimal ===

==== Efficient ====
==== Scalable ====
==== Interoperable ====

== Advanced Criteria ==

The following ''advanced'' quality criteria that can be used to compare different solutions, or to define quality roadmaps beyond the standard criteria.

However, these ''advanced'' criteria do not enhance the general quality levels: a level-2 solution is still of lower quality than a level-3 solution - regardless how many advanced criteria the level-2 solution fulfills.

=== Stable ===
=== Appealing ===
=== Flexible ===
=== Standardized ===
=== Extensible ===
=== Generic ===
=== Customizable ===