Changes between Initial Version and Version 1 of DeveloperGuidelines/Quality

Timestamp:

12/29/13 16:01:36 (11 years ago)

Author:

Dominic König

Comment:

--

DeveloperGuidelines/Quality

@@ +1 @@
+= 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, customizable||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 ===