Changes between Version 29 and Version 30 of DeveloperGuidelines/Quality


Ignore:
Timestamp:
12/29/13 22:34:50 (8 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelines/Quality

    v29 v30  
    8484==== Consistent ====
    8585
     86  ''Maintaining Conceptual Integrity across the Application''
     87
    8688  * The solution applies the application framework appropriately and correctly
    8789
     
    9193
    9294  * The solution applies the application's global design and style guidelines
     95
     96==== Robust ====
     97
     98  * The solution delivers consistent behavior, results and performance for all valid configurations
     99
     100  * The solution handles invalid input data, unexpected user actions and irregular system conditions appropriately and consistently for all valid configurations
     101
     102  * The solution detects invalid configurations and prevents any inadvertent effects that could result from them
     103
    93104==== Configurable ====
    94105
     
    98109
    99110  * Processing parameters, behavior and/or appearance of the solution can be adapted to requirements variations using configuration patterns separate from its core code
    100 ==== Robust ====
    101111
    102   * The solution delivers consistent behavior, results and performance for all valid configurations
    103 
    104   * The solution handles invalid input data, unexpected user actions and irregular system conditions appropriately and consistently for all valid configurations
    105 
    106   * The solution detects invalid configurations and prevents any inadvertent effects that could result from them
    107112=== Level 4: Optimal ===
    108113
     
    142147== Advanced Criteria ==
    143148
    144 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.
     149''Advanced'' quality criteria can be used to compare different solutions, or to define quality roadmaps for particular feature sets beyond the standard criteria.
    145150
    146 Advanced quality criteria do not apply equally in all use-cases - in certain cases they may even constitute anti-patterns.
     151Advanced quality criteria do not apply equally for all use-cases - in certain cases they may even constitute anti-patterns.
    147152
    148 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.
     153Advanced 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.
    149154
    150 === Appealing ===
     155=== Stability ===
    151156
     157  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.
    152158
    153 === Stable ===
    154 === Flexible ===
    155 === Standardized ===
    156 === Extensible ===
    157 === Generic ===
    158 === Customizable ===
     159  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.
    159160
     161=== Generalization ===
     162
     163  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.
     164
     165  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.
     166
     167  Generalization is though not always the right thing to do:
     168
     169  - Generalization is generally seen as anti-pattern in isolated use-cases
     170  - Generalization can require massively more development effort than the development of the solution itself, and can therefore be inefficient (low value/effort ratio)
     171  - 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
     172  - Parametrization and introspection add additional processing efforts which can reduce efficiency and scalability below acceptable levels
     173  - Generalization can add additional possible points of failure (additional risk)
     174
     175  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.
     176
     177=== Standards ===
     178