Changes between Version 29 and Version 30 of DeveloperGuidelines/Quality

Timestamp:

12/29/13 22:34:50 (11 years ago)

Author:

Dominic König

Comment:

--

DeveloperGuidelines/Quality

@@ -84 +84 @@
 ==== Consistent ====
 
+  ''Maintaining Conceptual Integrity across the Application''
+
   * The solution applies the application framework appropriately and correctly
 
@@ -91 +93 @@
 
   * The solution applies the application's global design and style guidelines
+
+==== Robust ====
+
+  * The solution delivers consistent behavior, results and performance for all valid configurations
+
+  * The solution handles invalid input data, unexpected user actions and irregular system conditions appropriately and consistently for all valid configurations
+
+  * The solution detects invalid configurations and prevents any inadvertent effects that could result from them
+
 ==== Configurable ====
 
@@ -98 +109 @@
 
   * Processing parameters, behavior and/or appearance of the solution can be adapted to requirements variations using configuration patterns separate from its core code
-==== Robust ====
 
-  * The solution delivers consistent behavior, results and performance for all valid configurations
-
-  * The solution handles invalid input data, unexpected user actions and irregular system conditions appropriately and consistently for all valid configurations
-
-  * The solution detects invalid configurations and prevents any inadvertent effects that could result from them
 === Level 4: Optimal ===
 
@@ -142 +147 @@
 == Advanced Criteria ==
 
-The following ''advanced'' quality criteria that can be used to compare different solutions, or to define quality roadmaps for particular feature sets beyond the standard criteria.
+''Advanced'' quality criteria can be used to compare different solutions, or to define quality roadmaps for particular feature sets beyond the standard criteria.
 
-Advanced quality criteria do not apply equally in all use-cases - in certain cases they may even constitute anti-patterns.
+Advanced quality criteria do not apply equally for all use-cases - in certain cases they may even constitute anti-patterns.
 
-In any case, advanced criteria do not enhance the general quality level of a solution: a level-3 solution is still of better quality than a level-2 solution - regardless how many advanced criteria the level-2 solution meets.
+Advanced quality criteria do not enhance the general quality level of a solution: a level-3 solution is still of better quality than a level-2 solution - regardless how many advanced criteria the level-2 solution meets.
 
-=== Appealing ===
+=== Stability ===
 
+  A solution is ''stable'' when its black-box model rarely changes, and it maintains backwards-compatibility and/or easy migration paths. Stable solutions are required for all critical dependencies, so that they can be built upon without risk for frequent regression issues or need for constant migration. Stability is especially critical in shared data models (i.e. where data are shared between different modules within the application or even across applications), and in authorization frameworks.
 
-=== Stable ===
-=== Flexible ===
-=== Standardized ===
-=== Extensible ===
-=== Generic ===
-=== Customizable ===
+  Stability is typically perceived as a sign of maturity, but can actually be taken into account already during the initial solution design. Pragmatic approaches (e.g. integrated migration, or enforced backwards-compatibility) can create stability early on without limiting or obstructing further development.
 
+=== Generalization ===
+
+  Generalizable solutions are designed and/or implemented in a way that they can be generalized. Typically, they separate their core patterns/algorithms from the use-case specifics through parametrization and/or configuration patterns. This can be defined as a quality requirement for a solution.
+
+  Generalization means to modify and/or extend the core patterns/algorithms of the solution in a way that they can be re-used in other solutions which involve the same or similar functional requirements, thereby reducing future development efforts. There is a wide range of quality attributes - "flexible", "customizable", "re-usable", "extensible", just to name a few - all of which involve different degrees of and approaches to generalization.
+
+  Generalization is though not always the right thing to do:
+
+  - Generalization is generally seen as anti-pattern in isolated use-cases
+  - Generalization can require massively more development effort than the development of the solution itself, and can therefore be inefficient (low value/effort ratio)
+  - The impact of and the necessary effort to correct defects and especially design flaws in generic solutions get multiplied by the (intended) re-use of the solution
+  - Parametrization and introspection add additional processing efforts which can reduce efficiency and scalability below acceptable levels
+  - Generalization can add additional possible points of failure (additional risk)
+
+  Apart from that, generalization can make maintenance more difficult: developers who do not recognize/understand the general case can (and often do) re-introduce use-case specifics into generic code, thereby reducing its efficiency and flexibility, potentially causing side effects on other solution, and complicating maintenance.
+
+=== Standards ===
+