Quality
Quality Class Diagram D0001
Quality is a set of characteristics of a product. These characteritics can be concretized to quality attributes (measureable properties of the product).
To achieve quality at development and during operation, one can set up processes to ensure that each development or operation step implements mechanisms to reach a defined level of quality.
Also, the developed and operated product has to encompass technical measures to provide expected quality characteristics.
Copyright 2019-2025 Andreas Warnke
License: Choose either Apache-2.0 or Creative Commons Attribution (BY) Licence
Quality
Process Quality Block C0001
Process quality can be measured by analyzing the reports and other workproducts
that have been created during different phases at engineering and during operation.
activities implement measures --> Product Quality Control Flow R0138
Quality, Product Quality
Product Quality Block C0002
Product quality refers to characteristics that can be measured
by analyzing the product that was created and that is in use.
ISO/IEC 25010:2011 Property F0004
see Bibliography
measures are checked --> Process Quality Control Flow R0137
Quality
How to create? Comment C0115
Process quality is defined by
a set of rules
how to create a product.
··> Process Quality Dependency R0131
Quality
What characteristics? Comment C0116
Product quality is defined by
a set of characteristics
of the product to be created.
··> Product Quality Dependency R0132
Product Quality
Product Quality Component Diagram D0002
Some attributes of a product can be measured when analyzing the artifacts produced during development or when analyzing the finally created product. For example the existance of a firewall for security or the startup-time.
Some attributes can only be measured when the product is operated - by analyzing e.g. user-feedback or maintenance-duration.
Product Quality, Quality Characteristics
Ext/Int Product Quality Package C0003
Product quality are internal and externally visible qualities,
such as memory consumption or startup timings.
This category of product quality was introduced in ISO/IEC 9126-1 and extended in ISO-25010:2011.
Product quality influences quality-in-use ··> Quality in Use Dependency R0139
Product Quality, Quality Characteristics
Quality in Use Package C0004
Quality in use can be measured when the product is already in use,
e.g. the percentage of satisfied customers can be determined.
This category was proposed in ISO/IEC 9126-4 and extended by context coverage in ISO-25010:2011
Quality-in-use requires product quality ··> Ext/Int Product Quality Dependency R0140
Quality, Product Quality
Product Quality Block C0002
Product quality refers to characteristics that can be measured
by analyzing the product that was created and that is in use.
ISO/IEC 25010:2011 Property F0004
see Bibliography
+-- Ext/Int Product Quality Containment R0268
+-- Quality in Use Containment R0269
Domains
Domains Use Case Diagram D0005
The "Quality in Use" depends on the domain.
Measures to improve and to validate software quality are often domain-specific.
Some domains are more focusing on tests, some on formal proves,
some on reaction times till deploying software updates.
Domains
Aerospace Actor C0051
Domains
Automotive Actor C0052
Domains
Defense Actor C0053
Domains
Avionics Actor C0054
Domains
Industrial Machinery Actor C0055
Domains
Medical Actor C0056
Domains
Backend Server / Cloud / AI Actor C0057
Domains
Finance Actor C0105
Domains
Tele- communication Actor C0106
Domains
Rail Actor C0107
Domains
Energy Actor C0110
Domains
Transport and Logistics Actor C0111
Domains
Government Actor C0112
Domains
Travel / Tourism Actor C0119
Domains
Media/Press/Publishing Actor C0120
Domains
Entertainment, Sports Actor C0145
Domains
Home Automation Actor C0146
Construction / Home Automation
Domains
Education Actor C0147
Domains
Agriculture Actor C0221
Domains
Mobile Devices / Wearables Actor C0222
Clothes / Wearables
Product Quality Taxonomy
Product Quality Taxonomy Class Diagram D0021
This diagram shows some terms in the context of product quality and their relationships. (Domain Model)
This picture is composed of ideas from 1) Software Architecture in Practice (C0165), 2) ISO/IEC 9126 (C0166), 3) arc42 (C0168), see Bibliography.
Product Quality Taxonomy
Quality Characteristic Class C0156
A characteristic is a set of subcharacteristics.
has a set of o-- Quality Subcharacteristic Aggregation R0158
Product Quality Taxonomy
Quality Subcharacteristic Class C0157
A subcharacterstic is a
property of a system
that expresses
how well it fits to a quality expectation.
Product Quality Taxonomy
Quality Attribute Class C0158
An attribute is an internal property of an entity (e.g. software).
Product Quality Taxonomy
Quality Measure Element verification Class C0159
A measurement value.
It can be objectively measured
but may possibly need interpretation
to state if the measured value is sutable
to support a subcharacteristic.
measurement --> Quality Attribute Association R0200
Further Glossary Terms, Product Quality Taxonomy
Tactic solution space Class C0160
A tactic is a method to influence a system to inherit a subcharacteristic.
It is a precise, detailed action plan that produces an outcome. The outcome may be a step in a overarching strategy.
See: Software Architecture in Practice (C0165) in Bibliography.
Further Glossary Terms, Product Quality Taxonomy
Quality Scenario problem space Class C0161
A quality scenario is a use case in which one or more quality subcharacteristics are an important outcome.
Scenarios as linking elements between a quality tree and requirements are described in arc42 (C0168), see Bibliography.
defines expectations ··> Quality Subcharacteristic Dependency R0165
Further Glossary Terms, Product Quality Taxonomy
Solution Strategy Class C0162
A strategy is a plan to reach a long-term goal. The plan consists of high-level steps. These high-level steps shall produce expected outcomes and need to be broken further down into tactics.
selects (1:n) o-- Tactic Aggregation R0163
influences (n:m) ··> Quality Subcharacteristic Dependency R0164
Product Quality Taxonomy
Topic/Group (Quality tree) Class C0163
A quality tree starts at the quality characteristics as the main branches and ends at detailed quality requirements as the leaves.
The detailed quality requirements then may refer to quality scenarios where these are of significance.
refers to (n:m) o-- Quality Scenario Aggregation R0162
refines ··> Quality Subcharacteristic Dependency R0166
groups o-- Quality Requirement Aggregation R0249
Product Quality Taxonomy
entity Component C0190
Entity is some system element of which some quality is expected.
It exhibits one or more quality attributes.
+-- Quality Attribute Containment R0199
Product Quality Taxonomy
Quality Measure verification Class C0191
A quality measure is a metric based on a set of observed values indicating the qualiity of an entity.
indicates quality ··> Quality Subcharacteristic Dependency R0201
base measurement (1:n) o-- Quality Measure Element Aggregation R0202
Further Glossary Terms, Product Quality Taxonomy
Design Pattern solution space Class C0208
Design patterns are design parts that are recurring in multiple different software designs. These typically answer one or more design questions and realize a couple of tactics to achieve product quality.
See: Software Architecture in Practice (C0165) in Bibliography.
realizes (0..n) ··|> Tactic Realization R0247
Further Glossary Terms, Product Quality Taxonomy
Quality Requirement Class C0209
··> Quality Scenario Refinement R0248
Further Glossary Terms
Further Glossary Terms Class Diagram D0048
Further Glossary Terms, Product Quality Taxonomy
Quality Scenario problem space Class C0161
A quality scenario is a use case in which one or more quality subcharacteristics are an important outcome.
Scenarios as linking elements between a quality tree and requirements are described in arc42 (C0168), see Bibliography.
--|> Use Case Generalization R0342
Further Glossary Terms, Product Quality Taxonomy
Quality Requirement Class C0209
··> Quality Scenario Refinement R0248
Further Glossary Terms, Product Quality Taxonomy
Tactic solution space Class C0160
A tactic is a method to influence a system to inherit a subcharacteristic.
It is a precise, detailed action plan that produces an outcome. The outcome may be a step in a overarching strategy.
See: Software Architecture in Practice (C0165) in Bibliography.
Further Glossary Terms, Product Quality Taxonomy
Design Pattern solution space Class C0208
Design patterns are design parts that are recurring in multiple different software designs. These typically answer one or more design questions and realize a couple of tactics to achieve product quality.
See: Software Architecture in Practice (C0165) in Bibliography.
realizes (0..n) ··|> Tactic Realization R0247
--|> concept Generalization R0341
Further Glossary Terms, Product Quality Taxonomy
Solution Strategy Class C0162
A strategy is a plan to reach a long-term goal. The plan consists of high-level steps. These high-level steps shall produce expected outcomes and need to be broken further down into tactics.
selects (1:n) o-- Tactic Aggregation R0163
Further Glossary Terms
concept Stereotype C0288
A concept is an abstraction for a recurring structural and/or behavioural pattern.
In contrast to a tactic and a strategy, it does not define a clear goal - its purpose depends on the context in which it is used.
<path stroke="#555555" fill="#aaddff"
d="M 26,12 l -1.5,0.25 l -0.4375,2.375 l 1.3125,0.75 l 0.6875,1 l -0.8125,1.5 l -1.1875,-0 l -1.375,-0.6875 l -1.75,1.6875 l 0.625,1.375 l -0,1.1875 l -1.5625,0.75 l -0.9375,-0.6875 l -0.6875,-1.375 l -2.375,0.3125 l -0.3125,1.5 l -0.75,0.9375 l -1.6875,-0.3125 l -0.375,-1.125 l 0.1875,-1.5 l -2.125,-1.125 l -1.125,1 l -1.125,0.375 l -1.1875,-1.25 l 0.375,-1.125 l 1.0625,-1.125 l -1.0625,-2.125 l -1.5,0.1875 l -1.125,-0.375 l -0.25,-1.6875 l 1,-0.6875 l 1.5,-0.25 l 0.4375,-2.375 l -1.3125,-0.75 l -0.6875,-1 l 0.8125,-1.5 l 1.1875,0 l 1.375,0.6875 l 1.75,-1.6875 l -0.625,-1.375 l 0,-1.1875 l 1.5625,-0.75 l 0.9375,0.6875 l 0.6875,1.375 l 2.375,-0.3125 l 0.3125,-1.5 l 0.75,-0.9375 l 1.6875,0.3125 l 0.375,1.125 l -0.1875,1.5 l 2.125,1.125 l 1.125,-1 l 1.125,-0.375 l 1.1875,1.25 l -0.375,1.125 l -1.0625,1.125 l 1.0625,2.125 l 1.5,-0.1875 l 1.125,0.375 l 0.25,1.6875 l -1,0.6875 "
/>
<path stroke="none" fill="#7f7f7f"
d="M 14,12 C 14,10.875 14.875,10 16,10 S 18,10.875 18,12 S 17.125,14 16,14 S 14,13.125 14,12 "
/>
o-- concept-img Aggregation R0343
may follow 1..n ··> principle Dependency R0344
Further Glossary Terms
Use Case Class C0289
A use case is a description of the usage of a system.
The described usage is restricted to one or few concrete scenarios, it does not try to describe all possible interactions.
A use case consists of
- one or more actors
- pre-conditions
- one or few scenarios which describe the sequence of interactions
- post-conditions
Further Glossary Terms
concept-img concept Image C0290
Further Glossary Terms
principle Stereotype C0291
A principle is a guideline to adhere when performing a task or when evaluating the result of a task.
<path fill="#ccffcc" stroke="none" d="m 2,2 28,0 0,28 -28,0 z" />
<path d="m 8,12 l -4,7 1,1 6,0 1,-1 -4,-7 l 8,-4 9,0 l -4,7 1,1 6,0 1,-1 -4,-7 " />
<path d="m 15,5 l 1,3 m 0,2 l 0,17 " />
o-- principle-img Aggregation R0345
Further Glossary Terms
principle-img principle Image C0292
Quality Characteristics
Quality Characteristics Box Overview D0015
Charactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Note that there is a newer version of that standard (2023). One may check if this is an improvement.
Functional Suitability Subcharacteristics, Quality Characteristics
Functional Suitability Requirement C0015
Quality Characteristics, Compatibility Subcharacteristics
Compatibility Requirement C0022
Reliability Subcharacteristics, Quality Characteristics
Reliability Requirement C0021
Portability Subcharacteristics, Quality Characteristics
Portability Requirement C0020
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Quality Characteristics
Performance Efficiency Requirement C0023
Usability Subcharacteristics, Quality Characteristics
Usability Requirement C0017
Quality Characteristics, Maintainability Subcharacteristics
Maintainability Requirement C0012
Quality Characteristics, Security Subcharacteristics
Security Requirement C0018
Quality Characteristics, Quality in Use Subcharacteristics
Satisfaction Requirement C0180
Quality Characteristics, Quality in Use Subcharacteristics
Context Coverage Requirement C0182
Quality Characteristics, Quality in Use Subcharacteristics
Freedom from Risk Requirement C0181
Quality Characteristics, Quality in Use Subcharacteristics
Effectiveness Requirement C0178
Quality Characteristics, Quality in Use Subcharacteristics
Efficiency Requirement C0179
Product Quality, Quality Characteristics
Ext/Int Product Quality Package C0003
Product quality are internal and externally visible qualities,
such as memory consumption or startup timings.
This category of product quality was introduced in ISO/IEC 9126-1 and extended in ISO-25010:2011.
Product Quality, Quality Characteristics
Quality in Use Package C0004
Quality in use can be measured when the product is already in use,
e.g. the percentage of satisfied customers can be determined.
This category was proposed in ISO/IEC 9126-4 and extended by context coverage in ISO-25010:2011
Functional Suitability Subcharacteristics
Functional Suitability Subcharacteristics Requirement Diagram D0045
Functional Suitability Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Functional Suitability Subcharacteristics, Quality Characteristics
Functional Suitability Requirement C0015
+-- Correctness Containment R0337
+-- Appropriateness Containment R0338
+-- Completeness Containment R0339
Functional Suitability Subcharacteristics
Correctness Class C0014
Functional Suitability Subcharacteristics
Appropriateness Class C0013
Functional Suitability Subcharacteristics
Completeness Class C0016
Usability Subcharacteristics
Usability Subcharacteristics Requirement Diagram D0004
Usability Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Usability Subcharacteristics, Quality Characteristics
Usability Requirement C0017
+-- Recogni-zability Containment R0071
+-- Learnability Containment R0072
+-- Operability Containment R0073
+-- User Error Protection Containment R0074
+-- Aesthetics Containment R0075
+-- Accessibility Containment R0076
Usability Subcharacteristics
Operability Class C0024
Usability Subcharacteristics
Accessibility Class C0029
Usability Subcharacteristics
Recogni-zability Class C0030
Usability Subcharacteristics
Aesthetics Class C0031
Usability Subcharacteristics
Learnability Class C0032
Usability Subcharacteristics
User Error Protection Class C0033
Portability Subcharacteristics
Portability Subcharacteristics Requirement Diagram D0043
Portability Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Portability Subcharacteristics, Quality Characteristics
Portability Requirement C0020
+-- Adaptability Containment R0155
+-- Replaceability Containment R0156
+-- Installability Containment R0157
Portability Subcharacteristics
Replaceability Class C0153
Portability Subcharacteristics
Adaptability Class C0152
Portability Subcharacteristics
Installability Class C0154
Reliability Subcharacteristics
Reliability Subcharacteristics Requirement Diagram D0049
Reliability Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Tactics for Maturity, Strategies for Reliability/Maturity, Reliability Subcharacteristics
Maturity Class C0035
Strategies for Reliability/A.+F.T.+R., Reliability Subcharacteristics
Availability Class C0034
Strategies for Reliability/A.+F.T.+R., Tactics for Error Handling, Reliability Subcharacteristics
Recoverability Class C0037
Strategies for Reliability/A.+F.T.+R., Reliability Subcharacteristics
Fault Tolerance Class C0036
Reliability Subcharacteristics, Quality Characteristics
Reliability Requirement C0021
+-- Maturity Containment R0062
+-- Availability Containment R0063
+-- Fault Tolerance Containment R0064
+-- Recoverability Containment R0065
Strategies for Reliability/A.+F.T.+R.
Strategies for Reliability/A.+F.T.+R. Component Diagram D0008
This diagram shows examples - not aiming for completeness.
Strategies for Reliability/A.+F.T.+R., Tactics for Error Handling, Reliability Subcharacteristics
Recoverability Class C0037
Strategies for Reliability/A.+F.T.+R., Reliability Subcharacteristics
Fault Tolerance Class C0036
Strategies for Reliability/A.+F.T.+R., Reliability Subcharacteristics
Availability Class C0034
Strategies for Reliability/A.+F.T.+R.
Fault injection Tests concept Block C0063
improves --> Fault Tolerance Association R0041
Strategies for Reliability/A.+F.T.+R., Strategies for Safety Risk Mitigation, Tactics for Safety II
Redundancy concept Class C0074
2 of 3 voter Property F0025
duo-duplex Property F0026
duo-duplex is a concept that consists of 4 independant parts: Two functions (F1 and F2) and two monitors (M1 and M2).
- M1 supervises F1.
In case F1 fails, M1 ensures that F1 has no effect.
- M2 supervises F2.
In case F2 fails, M2 ensures that F2 has no effect.
As long as (F1/M1) produces output, (F2/M2) is ignored.
limp home Property F0027
function migration Property F0028
enhances --> Availability Association R0055
Strategies for Reliability/A.+F.T.+R., Tactics for Safety I, Strategies for Security/Integrity
Input Signal Validation concept Block C0083
Precondition is a specification of valid input signals.
This can be implemented by different means, e.g.
- assert() statements
as declared in assert.h
- if(COND) {...} else {...} statements
where the else-path logs the error
For Security: Check input signals already at the gate, not later.
-- Fault Tolerance Communication Path R0128
Strategies for Reliability/A.+F.T.+R., Tactics for Partitioning, Tactics for Safety I, Strategies for Safety Risk Mitigation, Strategies for Security/Integrity
Partitioning concept Block C0075
synonym for Compartments
see Tactics for Partitioning.
-- Fault Tolerance Communication Path R0129
-- Recoverability Communication Path R0130
Strategies for Reliability/A.+F.T.+R., Tactics for Error Handling
Error Handling Concept concept Class C0220
An error handling concept
1) defines which and how faults
and anomalies are detected,
2) which faults and anomalies
are treated as errors,
3) how errors are propagated
from the point of occurrence
to a point where these are handled,
e.g. throw/raise of exceptions or
passing on error codes,
4) by which categories errors are classified,
5) which category is handled in which way,
6) who shall be informed on which way,
e.g. a user by a popup-window,
an operator by an error log,
7) if and how to resume operation.
supports --> Recoverability Association R0267
Tactics for Error Handling
Tactics for Error Handling Class Diagram D0031
Strategies for Reliability/A.+F.T.+R., Tactics for Error Handling
Error Handling Concept concept Class C0220
An error handling concept
1) defines which and how faults
and anomalies are detected,
2) which faults and anomalies
are treated as errors,
3) how errors are propagated
from the point of occurrence
to a point where these are handled,
e.g. throw/raise of exceptions or
passing on error codes,
4) by which categories errors are classified,
5) which category is handled in which way,
6) who shall be informed on which way,
e.g. a user by a popup-window,
an operator by an error log,
7) if and how to resume operation.
supports --> Recoverability Association R0267
Strategies for Reliability/A.+F.T.+R., Tactics for Error Handling, Reliability Subcharacteristics
Recoverability Class C0037
Tactics for Error Handling
Error Handling Example Activity C0224
+-- detect and interpret Containment R0272
+-- propagate and re-interpret Containment R0273
+-- detect multiple errors and interpret Containment R0280
+-- inform stakeholder Containment R0276
+-- abort, degrade, retry or continue Containment R0278
example ··> Error Handling Concept Dependency R0275
Tactics for Error Handling
detect and interpret Activity C0225
--> propagate and re-interpret Control Flow R0274
Tactics for Error Handling
propagate and re-interpret Activity C0226
re-interpretation is necessary when
higher-level functions know how to
interpret errors reported by lower level
functions.
E.g. a search function may fail to find a
record. The caller may be able to decide
if this is intended or if this is a severe error.
--> inform stakeholder Control Flow R0277
Tactics for Error Handling
inform stakeholder Activity C0227
stakeholders may be:
- developer
- operator
- user
--> abort, degrade, retry or continue Control Flow R0279
Tactics for Error Handling
abort, degrade, retry or continue Activity C0228
Tactics for Error Handling
detect multiple errors and interpret optional Activity C0229
--> propagate and re-interpret Control Flow R0281
Strategies for Reliability/Maturity
Strategies for Reliability/Maturity Class Diagram D0040
Strategies for Reliability/Maturity
Code Generation concept Block C0087
An understandable model and a small code generator
allow to generate mature software.
supports --> Maturity Association R0100
Strategies for Reliability/Maturity
Layered Architecture concept Block C0061
improves --> Maturity Association R0039
Strategies for Reliability/Maturity
Static Code Analysis concept Block C0086
enhances --> Maturity Association R0099
Strategies for Reliability/Maturity
Mature Platform concept Block C0109
OS provides resource limits+guarantees Property F0061
OS does not swap, does not overcommit Property F0062
OS has mature peripheral-drivers Property F0063
HW provides supervision Property F0070
E.g.
- timer trigger OS-interrupts
- access violations trigger OS-interrupts
--> Maturity Association R0124
Strategies for Maintainability, Strategies for Reliability/Maturity
automated Tests concept Block C0118
Requirements Coverage Property F0069
Code Coverage Property F0068
Variant Coverage Property F0080
HW variants, Feature Variants, Compiler/OS Variants
--> Maturity Association R0136
Tactics for Maturity, Strategies for Reliability/Maturity, Reliability Subcharacteristics
Maturity Class C0035
Strategies for Reliability/Maturity
Control and Manage Resources strategy Class C0175
--> Maturity Association R0173
Tactics for Maturity, Strategies for Reliability/Maturity
Coding Guidelines concept Block C0062
Coding guidelines define how to get reproducible behavior of software.
Managing system resources is a key factor.
static thread model Property F0010
Execution threads shall not be started/stopped dynamically
no endless loops Property F0008
Every loop shall have a counter to ensures that
after a predefined maximum value the loop is definitely quit
consistent error handling Property F0009
Inconsistencies in error handling make
bugs in error handling more likely
valid Memory Addresses Property F0007
Only valid memory addresses may be read/written.
- Java solves this by prohibiting pointers,
- In C, check pointers and array indices before usage,
- In C++, use std::shared_ptr and std::vector,
- Kotlin even distinguishes between nullable references and non-null references.
no dynamic Memory Property F0006
When the program is running,
- it must not fail due to
- memory fragmentation (virtual addresses/physical pages)
- out of memory situations
- it shall have a defined timing (which new/malloc cannot provide)
no recursion: avoid Stack overflow Property F0005
lock critical sections Property F0024
Always lock critical sections.
single point of return: simple control flow Property F0023
Simple control flow is key to understandable code
improves --> Maturity Association R0040
Tactics for Maturity
Tactics for Maturity Class Diagram D0026
Tactics for Maturity, Strategies for Reliability/Maturity, Reliability Subcharacteristics
Maturity Class C0035
Tactics for Maturity, Strategies for Reliability/Maturity
Coding Guidelines concept Block C0062
Coding guidelines define how to get reproducible behavior of software.
Managing system resources is a key factor.
static thread model Property F0010
Execution threads shall not be started/stopped dynamically
no endless loops Property F0008
Every loop shall have a counter to ensures that
after a predefined maximum value the loop is definitely quit
consistent error handling Property F0009
Inconsistencies in error handling make
bugs in error handling more likely
valid Memory Addresses Property F0007
Only valid memory addresses may be read/written.
- Java solves this by prohibiting pointers,
- In C, check pointers and array indices before usage,
- In C++, use std::shared_ptr and std::vector,
- Kotlin even distinguishes between nullable references and non-null references.
no dynamic Memory Property F0006
When the program is running,
- it must not fail due to
- memory fragmentation (virtual addresses/physical pages)
- out of memory situations
- it shall have a defined timing (which new/malloc cannot provide)
no recursion: avoid Stack overflow Property F0005
lock critical sections Property F0024
Always lock critical sections.
single point of return: simple control flow Property F0023
Simple control flow is key to understandable code
improves --> Maturity Association R0040
Tactics for Maturity
Example Guidelines Block C0176
Spark/ADA: Avionics Property F0076
see C0173#name
Power of Ten: NASA Property F0077
SecureC Property F0078
MISRA-C/C++: automotive Property F0079
implements ··|> Coding Guidelines Realization R0174
Performance Efficiency Subcharacteristics
Performance Efficiency Subcharacteristics Requirement Diagram D0046
Performance Efficiency Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Quality Characteristics
Performance Efficiency Requirement C0023
+-- Time Behaviour Containment R0059
+-- Resource Utilization Containment R0060
+-- Capacity Containment R0061
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Resource Utilization Class C0019
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Time Behaviour Class C0025
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Capacity Class C0026
Quality Tree for Performance Efficiency
Quality Tree for Performance Efficiency Component Diagram D0028
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Quality Characteristics
Performance Efficiency Requirement C0023
+-- Time Behaviour Containment R0059
+-- Resource Utilization Containment R0060
+-- Capacity Containment R0061
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Time Behaviour Class C0025
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Resource Utilization Class C0019
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Capacity Class C0026
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Preallocate Memory concept Requirement C0202
For dedicated use cases and functions, the software shall access required memory within 1 usec.
··> Time Behaviour Trace R0237
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Sufficient Memory concept Requirement C0203
For dedicated use cases and functions, the software shall be able to access sufficient memory.
··> Resource Utilization Trace R0233
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Delay Function concept Requirement C0204
For dedicated use cases and functions, the software shall delay processing till enough memory is available.
··> Time Behaviour Trace R0232
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Degrade Result concept Requirement C0205
For dedicated use cases and functions, the software shall calculate a result where accuracy may degrade if memory is sparse.
··> Resource Utilization Trace R0234
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Stop and Restart Later concept Requirement C0206
In case of insufficient amount of memory, the software shall stop operating and be started again at a later point in time.
··> Time Behaviour Trace R0236
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Abort Function concept Requirement C0207
In case of insufficient memory, the software shall abort the function.
··> Time Behaviour Trace R0238
Scenarios relating to Performance Efficiency
Scenarios relating to Performance Efficiency Component Diagram D0024
Scenarios relating to Performance Efficiency
Background-Fkt Use-Case2 problem space Use Case C0184
This use case is a proxy for use cases
that can be delayed if resources are sparse,
e.g. polling for software updates or
performing data backups.
Scenarios relating to Performance Efficiency
Dynamic-Fkt Use-Case problem space Use Case C0185
This use case is a proxy for use cases that
allow to produce degraded or no results
if memory gets low.
E.g. A list of search results may be truncated,
an undo-history may have limited size,
the number of simultaneously open windows may be limited by the available memory.
Scenarios relating to Performance Efficiency
Reliable-Fkt Use-Case problem space Use Case C0186
This use case is a proxy for use cases that shall always work (available and reliable).
Scenarios relating to Performance Efficiency
Bounded-Fkt Use-Case problem space Use Case C0187
This use case is a proxy for use cases that
allow to produce degraded results
if memory gets low or an upper boundary
of resource-consumption is reached.
This is use-ful e.g. to enhance security
when processing input data of unknown size
or to prevent stealing resources from higher-priority dynamic functions.
Scenarios relating to Performance Efficiency
Quality expectations depend on use cases problem space Comment C0188
A program/application typically solves
several use cases with
different quality expectations.
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Sufficient Memory concept Requirement C0203
For dedicated use cases and functions, the software shall be able to access sufficient memory.
··> Reliable-Fkt Use-Case Trace R0240
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Preallocate Memory concept Requirement C0202
For dedicated use cases and functions, the software shall access required memory within 1 usec.
··> Reliable-Fkt Use-Case Trace R0239
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Stop and Restart Later concept Requirement C0206
In case of insufficient amount of memory, the software shall stop operating and be started again at a later point in time.
··> Dynamic-Fkt Use-Case Trace R0244
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Delay Function concept Requirement C0204
For dedicated use cases and functions, the software shall delay processing till enough memory is available.
··> Background-Fkt Use-Case2 Trace R0243
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Degrade Result concept Requirement C0205
For dedicated use cases and functions, the software shall calculate a result where accuracy may degrade if memory is sparse.
··> Bounded-Fkt Use-Case Trace R0242
··> Dynamic-Fkt Use-Case Trace R0246
Quality Tree for Performance Efficiency, Scenarios relating to Performance Efficiency
Abort Function concept Requirement C0207
In case of insufficient memory, the software shall abort the function.
··> Bounded-Fkt Use-Case Trace R0241
··> Dynamic-Fkt Use-Case Trace R0245
Strategies for Performance Efficiency
Strategies for Performance Efficiency Class Diagram D0022
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Resource Utilization Class C0019
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Time Behaviour Class C0025
Quality Tree for Performance Efficiency, Performance Efficiency Subcharacteristics, Strategies for Performance Efficiency
Capacity Class C0026
Strategies for Performance Efficiency
Memory problem space Comment C0164
On one hand, main memory is cheap,
and there is plenty of it.
On the other hand, there are limits.
When reaching these,
suitable concepts need to be in place
that support the defined quality goals.
··> Resource Utilization Dependency R0167
··> Control Resource Command Dependency R0211
··> Manage Resources Dependency R0212
Memory Controlling Patterns/Tactics, Strategies for Performance Efficiency
Control Resource Command strategy Class C0169
For detailed tactics, see Memory Controlling Patterns/Tactics.
Source: Software Architecture in Practice (C0165) in Bibliography.
control -- Resource Utilization Communication Path R0171
Memory Management Patterns/Tactics, Strategies for Performance Efficiency
Manage Resources strategy Class C0170
For detailed tactics, see Memory Management Patterns/Tactics.
Source: Software Architecture in Practice (C0165) in Bibliography.
handle -- Resource Utilization Communication Path R0170
Strategies for Performance Efficiency
Resource Competition solution space Comment C0201
There are two main strategies
to solve resource contention:
control (plan) in advance vs.
manage (handle) on the fly.
··> Control Resource Command Dependency R0230
··> Manage Resources Dependency R0231
Memory Controlling Patterns/Tactics
Memory Controlling Patterns/Tactics Class Diagram D0019
This diagram shows patterns
to control memory
in a way that guarantees availability.
Concept is that software components
have a guarantee for a minimal amount
of memory that they need to operate.
Memory Controlling Patterns/Tactics
Schedule tasks concept Class C0148
- Schedule tasks that require memory
to prevent contention
E.g. only one memory-intensive task may run at a time
Memory Controlling Patterns/Tactics
Region based Memory Management concept Class C0149
A region/arena/stack is valid while performing
one operation/thread.
It provides single-threaded access only.
It is either used stack-like
or cleaned up when the operation/thread is finished.
This concept allows to fast allocate
and completely release memory arenas.
It prevents fragementation within the stack.
It supports NUMA architectures.
It may be faster than concurrent access to single heap.
It allows to reserve appropriate memory arenas for more important tasks
see https://en.wikipedia.org/wiki
/Region-based_memory_management
Implementation support by e.g.
polymorphic_allocator and memory_resource(C++17/20)
rust allocator: https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.html
Memory Controlling Patterns/Tactics
Static Allocation concept Class C0150
All memory is statically allocated
except for stacks.
The number of threads is static.
Example implementations:
- classic AUTOSAR, MISRA-C, MISRA-C++,
- Ada-Spark,
- NASA Power-of-Ten
- crystal_facet_uml (except gtk3+sqlite3)
- GPSd deamon (see the_architecture_of
_open_source_applications__volume_ii.pdf)
Memory Controlling Patterns/Tactics
Object Pools concept Class C0151
Pools of same-type objects
are pre-allocated.
This concept guarantees
a predefined amount of memory
and prevents fragmentation
Examples:
synchronized_pool_resource(C++17)
unsynchronized_pool_resource(C++17)
Memory Controlling Patterns/Tactics
Streaming/Static Size Buffering concept Class C0194
- Windowing concept
- Streaming with buffering
- Caching with re-fetching data at misses
Memory Controlling Patterns/Tactics
Concepts to plan and control memory usage Package C0197
+-- Stacks Containment R0228
+-- Static Allocation Containment R0215
+-- Streaming/Static Size Buffering Containment R0216
+-- Schedule tasks Containment R0217
+-- Object Pools Containment R0218
+-- Region based Memory Management Containment R0219
··|> Control Resource Command Realization R0227
Memory Controlling Patterns/Tactics, Strategies for Performance Efficiency
Control Resource Command strategy Class C0169
For detailed tactics, see Memory Controlling Patterns/Tactics.
Source: Software Architecture in Practice (C0165) in Bibliography.
Memory Controlling Patterns/Tactics
Stacks concept Class C0199
A stack deallocates memory only in the reverse order as it was allocated before.
Variant:
monotonic_buffer_resource(C++17)
Memory Management Patterns/Tactics
Memory Management Patterns/Tactics Class Diagram D0013
This diagram shows patterns
that manage memory
in a way that whoever needs memory
gets unused memory if available.
Concept is, that every software component
only allocates memory that it really needs;
if no memory is left, something will fail anyhow.
Memory Management Patterns/Tactics
Dynamic Allocation accepting controlled death concept Class C0123
- Accept memory fragmentation
(physical pages as well as virtual addresses)
- Swap memory pages to flash
- End a process if no memory available
Memory Management Patterns/Tactics
Weak Pointers / Caches concept Class C0125
- There are managed data structures
(hashmaps, caches) that hold data
as long as much memory is available
and that drop data
when memory becomes sparse
Example implementations:
Java Weak Hashmap, sqlite,
OS file system caches
Challenge: The cache needs to know
when memory is needed elsewhere.
Memory Management Patterns/Tactics
Moving Memory Objects concept Class C0126
Some instance manages memory (e.g. OS)
while another instance uses it (e.g. App).
This mamagement may reduce/fix fragmentation issues.
Examples:
- The java virtual machine can move objects
while a java application runs
- The classic MacOS7-9 could move memory
while the application holds a handle
(pointer to a pointer)
- Todays processors convert virtual
to physical addresses on the fly
(reallocations via e.g. sbrk, mmap)
Memory Management Patterns/Tactics
Dynamic Allocation accepting degradation concept Class C0155
Continue working, accept that some requested functionality
- cannot be performed at current point in time
- with expected precision
- within expected timeframe
Memory Management Patterns/Tactics
Remote Execution concept Class C0195
Required memory may be provided
on a different hardware, e.g. Cloud
Memory Management Patterns/Tactics
Dynamic Allocation accepting sudden death concept Class C0196
- Linux overcommit
- Compress memory pages
- End any process if page-fault by r/w operation
to overcommitted memory
Example Implementations:
Android App Management
(see low memory killer daemon: lmkd)
Linux OOM-Killer
--|> Dynamic Allocation accepting controlled death Generalization R0214
Memory Management Patterns/Tactics
Concepts to manage memory on the fly Package C0198
+-- Memory Estimation Containment R0229
+-- Weak Pointers / Caches Containment R0220
+-- Dynamic Allocation accepting degradation Containment R0221
+-- Remote Execution Containment R0222
+-- Moving Memory Objects Containment R0223
+-- Dynamic Allocation accepting controlled death Containment R0224
+-- Dynamic Allocation accepting sudden death Containment R0225
··|> Manage Resources Realization R0226
Memory Management Patterns/Tactics, Strategies for Performance Efficiency
Manage Resources strategy Class C0170
For detailed tactics, see Memory Management Patterns/Tactics.
Source: Software Architecture in Practice (C0165) in Bibliography.
Memory Management Patterns/Tactics
Memory Estimation concept Class C0200
Estimate required memory,
expected fragmentation overhead and
additional buffer
to prevent out-of-memory situations.
Compatibility Subcharacteristics
Compatibility Subcharacteristics Requirement Diagram D0044
Compatibility Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Compatibility Subcharacteristics
Inter-operability Class C0028
Compatibility Subcharacteristics
Co-existence Class C0027
Quality Characteristics, Compatibility Subcharacteristics
Compatibility Requirement C0022
+-- Co-existence Containment R0066
+-- Inter-operability Containment R0067
Maintainability Subcharacteristics
Maintainability Subcharacteristics Requirement Diagram D0038
Maintainability Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Quality Characteristics, Maintainability Subcharacteristics
Maintainability Requirement C0012
+-- Testability Containment R0077
+-- Modifyability Containment R0078
+-- Analyzability Containment R0079
+-- Reusability Containment R0080
+-- Modularity Containment R0081
Strategies for Maintainability, Maintainability Subcharacteristics
Reusability Class C0044
To be able to re-use the solution in another operational context
Strategies for Maintainability, Maintainability Subcharacteristics
Testability Class C0047
To determine a level of quality of a product
Strategies for Maintainability, Maintainability Subcharacteristics
Analyzability Class C0045
To find a cause of an observed (unwanted) behavior
Strategies for Maintainability, Maintainability Subcharacteristics
Modularity Class C0043
To keep effects of changes local to few components/functions
Strategies for Maintainability, Maintainability Subcharacteristics
Modifyability Class C0046
To be able to adapt the software/system to changed requirements
Strategies for Maintainability
Strategies for Maintainability Component Diagram D0007
This diagram shows examples - not aiming for completeness.
Strategies for Maintainability, Maintainability Subcharacteristics
Testability Class C0047
To determine a level of quality of a product
Strategies for Maintainability, Maintainability Subcharacteristics
Modifyability Class C0046
To be able to adapt the software/system to changed requirements
Strategies for Maintainability, Maintainability Subcharacteristics
Analyzability Class C0045
To find a cause of an observed (unwanted) behavior
Strategies for Maintainability, Maintainability Subcharacteristics
Reusability Class C0044
To be able to re-use the solution in another operational context
Strategies for Maintainability, Maintainability Subcharacteristics
Modularity Class C0043
To keep effects of changes local to few components/functions
Strategies for Maintainability, SOLID Principles
SOLID principle Block C0096
supports --> Modularity Association R0111
Strategies for Maintainability, Simplicity Terms
Simplicity principle Package C0098
supports ··> Modifyability Refinement R0109
supports ··> Reusability Refinement R0110
Strategies for Maintainability
Loose Coupling principle Block C0101
split an entity that consists of multiple loosely coupled parts
supports --> Modularity Association R0114
Strategies for Maintainability
Information Hiding principle Block C0102
A sofware component shall hide its implementation details and
make information accessible only via defined interfaces
enables --> Reusability Association R0115
supports --> Modularity Association R0116
simplifies --> Testability Association R0117
simplifies --> Analyzability Association R0118
Strategies for Maintainability
Least Astonishment principle Block C0103
A reader shall not be surprised when looking at the design.
Conformity of style and concepts Property F0066
Clear semantics of names Property F0067
Module names, Interface names, Message names, Port names:
The name shall state what the data/function represents.
The name shall be short and as concrete as possible.
Strategies for Maintainability
Strong Cohesion principle Block C0104
influences ··> Modularity Dependency R0119
Strategies for Maintainability, Strategies for Reliability/Maturity
automated Tests concept Block C0118
Requirements Coverage Property F0069
Code Coverage Property F0068
Variant Coverage Property F0080
HW variants, Feature Variants, Compiler/OS Variants
limit risks at changes --> Modifyability Association R0135
Simplicity Terms
Simplicity Terms Component Diagram D0012
Strategies for Maintainability, Simplicity Terms
Simplicity principle Package C0098
+-- KISS Containment R0106
+-- YAGNI Containment R0107
+-- Occam's razor Containment R0108
Simplicity Terms
KISS principle Block C0094
Keep it simple and stupid
Simplicity Terms
Occam's razor principle Class C0097
Among competing hypotheses, the one with the fewest assumptions should be selected
Simplicity Terms
YAGNI principle Block C0095
You aren't gonna need it
SOLID Principles
SOLID Principles Component Diagram D0016
Strategies for Maintainability, SOLID Principles
SOLID principle Block C0096
+-- Interface Segregation Containment R0101
+-- Liskov Substitution Containment R0102
+-- Dependency Inversion Containment R0103
+-- Open/Closed Containment R0104
+-- Single Responsability Containment R0105
SOLID Principles
Single Responsability principle Block C0089
A software component shall be responsible for one topic only
SOLID Principles
Open/Closed principle Block C0090
Open for extension, closed for modification
SOLID Principles
Interface Segregation principle Block C0092
Avoid general purpose interfaces,
design multiple interfaces specific to the needs of different users/clients
SOLID Principles
Liskov Substitution principle Block C0091
An implementation of an interface can be replaced
by another implementation of the same interface.
In object oriented design, types can be replaced by subtypes.
SOLID Principles
Dependency Inversion principle Block C0093
A software component shall depend on abstractions, not on concrete implementations
use Abstractions Operation F0046
Security Subcharacteristics
Security Subcharacteristics Requirement Diagram D0020
Security Subcharactersitics of Ext/Int Product Quality
according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Quality Characteristics, Security Subcharacteristics
Security Requirement C0018
+-- Resistence Containment R0340
+-- Authenticity Containment R0082
+-- Non-Repudiation Containment R0083
+-- Accountability Containment R0084
+-- Integrity Containment R0085
+-- Confidentiality Containment R0086
Strategies for Security w/o Integr., Security Subcharacteristics
Confidentiality Class C0039
Tactics for Integrity, Security Subcharacteristics, Strategies for Security/Integrity
Integrity Class C0040
Strategies for Security w/o Integr., Security Subcharacteristics
Accountability Class C0041
Strategies for Security w/o Integr., Security Subcharacteristics
Authenticity Class C0042
Strategies for Security w/o Integr., Security Subcharacteristics
Non-Repudiation Class C0038
Non-Repudiation is a proof:
which person(enitiy) authorized an action (at which time, based on what input)
Strategies for Security w/o Integr., Security Subcharacteristics
Resistence Requirement C0287
Keep functionality while under attack
Strategies for Security w/o Integr.
Strategies for Security w/o Integr. Class Diagram D0010
Functional safety and security are different goals
but have common mechanisms to support these.
The diagram is not meant to be complete,
it just shows some technical mechanisms support quality goals.
Especially for safety and security, selecting
the right set of the appropriate mechanisms is crucial.
Strategies for Security w/o Integr., Security Subcharacteristics
Confidentiality Class C0039
Strategies for Security w/o Integr., Security Subcharacteristics
Authenticity Class C0042
Strategies for Security w/o Integr., Tactics for Safety I
Cryptographic Signatures concept Block C0079
asymmetric Property F0038
shared key (symmetric) Property F0039
supports --> Authenticity Association R0091
may support -- Non-Repudiation Communication Path R0120
support --> Secure Boot Association R0123
Strategies for Security w/o Integr.
Encryption concept Block C0080
public/private Property F0037
symmetric Property F0036
supports --> Confidentiality Association R0092
Strategies for Security w/o Integr., Strategies for Security/Integrity
Least Priviledge principle Block C0099
Entities shall have only the access rights they need for their purpose
supports --> Accountability Association R0112
Strategies for Security w/o Integr., Security Subcharacteristics
Non-Repudiation Class C0038
Non-Repudiation is a proof:
which person(enitiy) authorized an action (at which time, based on what input)
Strategies for Security w/o Integr., Security Subcharacteristics
Accountability Class C0041
Strategies for Security w/o Integr., Strategies for Security/Integrity
Secure Boot concept Class C0108
--> Authenticity Association R0122
Strategies for Security w/o Integr.
Groups concept Block C0113
Grouping Clients/Actors/Users and
grouping Services
helps in administration of access rights
support --> Accountability Association R0125
Strategies for Security w/o Integr.
Certificates concept Block C0114
chain of certificates Property F0064
use --> Cryptographic Signatures Association R0126
divide and manage --> Accountability Association R0127
Strategies for Security w/o Integr.
Fail Secure principle Class C0133
Do not expose data or system details when a fault occurs.
Strategies for Security w/o Integr.
Secure Defaults concept Class C0135
The default settings/configuratoin of a system shall be tuned for security.
helps --> Fail Secure Association R0146
Strategies for Security w/o Integr., Security Subcharacteristics
Resistence Requirement C0287
Keep functionality while under attack
Tactics for Public/Private Keys
Tactics for Public/Private Keys Class Diagram D0047
Tactics for Public/Private Keys
Factorization based Class C0284
These cryptographic algorithms are based on the difficulty to calculate the prime factors of a given large number.
RSA Operation F0098
Tactics for Public/Private Keys
Discrete Logarithm based Class C0285
These cryptographic algorithms are based on the difficulty to calculate the discrete logathithm of a given large number.
Elliptic Curves (EC) Operation F0099
Tactics for Public/Private Keys
Post Quantum Cryptography Class C0286
Starting in 2016, NIST searches for new alternatives that are not vulnerable to the possibilities of quantum computers
Strategies for Security/Integrity
Strategies for Security/Integrity Class Diagram D0042
Tactics for Integrity, Security Subcharacteristics, Strategies for Security/Integrity
Integrity Class C0040
Strategies for Security/Integrity
Over-the-Air Updates concept Block C0078
Security Updates in Time Operation F0035
supports --> Integrity Association R0090
Strategies for Reliability/A.+F.T.+R., Tactics for Partitioning, Tactics for Safety I, Strategies for Safety Risk Mitigation, Strategies for Security/Integrity
Partitioning concept Block C0075
synonym for Compartments
see Tactics for Partitioning.
supports --> Integrity Association R0089
Strategies for Security w/o Integr., Strategies for Security/Integrity
Secure Boot concept Class C0108
--> Integrity Association R0121
Strategies for Reliability/A.+F.T.+R., Tactics for Safety I, Strategies for Security/Integrity
Input Signal Validation concept Block C0083
Precondition is a specification of valid input signals.
This can be implemented by different means, e.g.
- assert() statements
as declared in assert.h
- if(COND) {...} else {...} statements
where the else-path logs the error
For Security: Check input signals already at the gate, not later.
supports -- Integrity Communication Path R0333
Strategies for Security/Integrity
Reduce Attack Surface principle Class C0136
Remove unused functions
supports --> Integrity Association R0334
implements --> Least Priviledge Association R0336
Strategies for Security/Integrity
Secure Weakest Link principle Class C0134
supports --> Integrity Association R0335
Strategies for Security w/o Integr., Strategies for Security/Integrity
Least Priviledge principle Block C0099
Entities shall have only the access rights they need for their purpose
Tactics for Integrity
Tactics for Integrity Class Diagram D0030
Tactics for Integrity
TOCTOU Class C0223
Design and use interfaces in a way that time of check (TOC) (e.g. access rights, existance, ...) is not different from the time of use (TOU)
supports ··> Integrity Dependency R0271
Tactics for Integrity, Security Subcharacteristics, Strategies for Security/Integrity
Integrity Class C0040
Tactics for Partitioning
Tactics for Partitioning Class Diagram D0017
Strategies for Reliability/A.+F.T.+R., Tactics for Partitioning, Tactics for Safety I, Strategies for Safety Risk Mitigation, Strategies for Security/Integrity
Partitioning concept Block C0075
synonym for Compartments
see Tactics for Partitioning.
Tactics for Partitioning
SoC HW Partitions Block C0121
The HW provides e.g.
- a trusted execution environment
for cryptographic computations
- a separated monitoring CPU
to supervise the functional CPUs
Isolated Monitoring CPU Property F0071
Hardware security module/environment Property F0090
Trusted Execution Environment Property F0072
implements ··|> Partitioning Realization R0141
Tactics for Partitioning
Network Partitioniong Block C0076
Network Zones (VLANs) Property F0029
Gateways/Firewalls/Proxies Property F0030
implements ··|> Partitioning Realization R0087
Tactics for Partitioning
SW Partitions Block C0077
Hypervisor Partitions Property F0031
OS-Process Boundaries Property F0032
Microkernel OS Property F0033
for Device Driver Partitioning
Containers Property F0034
Linux-Containers,
QNX-Partitions,
Address-space separation
implements ··|> Partitioning Realization R0088
Tactics for Partitioning
Trust Levels concept Class C0132
Create a Multi-Layer security,
where elements of one layer mistrust these of other layers.
If one layer is compromized, the next still holds up.
Examples:
1) Internet - DMZ - Intranet
2) OS-Process (user), root-acess, OS(kernel-space), Hypervisor, Trusted Execution Environment of SoC
require ··> Partitioning Dependency R0144
Quality in Use Subcharacteristics
Quality in Use Subcharacteristics Class Diagram D0027
Subcharactersitics of quality in use according to ISO/IEC 25010:2011 (C0167), see Bibliography.
Quality Characteristics, Quality in Use Subcharacteristics
Effectiveness Requirement C0178
Quality Characteristics, Quality in Use Subcharacteristics
Efficiency Requirement C0179
Quality Characteristics, Quality in Use Subcharacteristics
Freedom from Risk Requirement C0181
+-- Economic risk mitigation Containment R0285
+-- Health and safety risk mitigation Containment R0286
+-- Environmental risk mitigation Containment R0287
Quality Characteristics, Quality in Use Subcharacteristics
Context Coverage Requirement C0182
+-- Flexibility Containment R0288
+-- Context completeness Containment R0289
Quality Characteristics, Quality in Use Subcharacteristics
Satisfaction Requirement C0180
+-- Usefulness Containment R0290
+-- Comfort Containment R0293
+-- Pleasure Containment R0292
+-- Trust Containment R0291
Quality in Use Subcharacteristics
Economic risk mitigation Class C0234
Quality in Use Subcharacteristics
Health and safety risk mitigation Class C0235
Quality in Use Subcharacteristics
Environmental risk mitigation Class C0236
Quality in Use Subcharacteristics
Flexibility Class C0237
Quality in Use Subcharacteristics
Context completeness Class C0238
Quality in Use Subcharacteristics
Usefulness Class C0239
Quality in Use Subcharacteristics
Trust Class C0240
Quality in Use Subcharacteristics
Pleasure Class C0241
Quality in Use Subcharacteristics
Comfort Class C0242
Strategies for Safety Risk Mitigation
Strategies for Safety Risk Mitigation Component Diagram D0025
Strategies for Reliability/A.+F.T.+R., Tactics for Partitioning, Tactics for Safety I, Strategies for Safety Risk Mitigation, Strategies for Security/Integrity
Partitioning concept Block C0075
synonym for Compartments
see Tactics for Partitioning.
may support a claim --> Functional Safety Association R0096
Tactics for Safety I, Strategies for Safety Risk Mitigation, Tactics for Safety II
Functional Safety Class C0081
Tactics for Safety I, Strategies for Safety Risk Mitigation
Monitoring concept Block C0084
Function Monitoring (L2) Operation F0040
System Monitoring (L3) Operation F0041
- alive Monitoring Operation F0059
- control flow supervision Operation F0060
- self test Operation F0087
may support a claim --> Functional Safety Association R0093
Tactics for Safety I, Strategies for Safety Risk Mitigation
Real Time Execution concept Block C0085
Guaranteed Calculation Time Operation F0044
Real Time Clock Operation F0045
may support a claim --> Functional Safety Association R0098
Strategies for Reliability/A.+F.T.+R., Strategies for Safety Risk Mitigation, Tactics for Safety II
Redundancy concept Class C0074
2 of 3 voter Property F0025
duo-duplex Property F0026
duo-duplex is a concept that consists of 4 independant parts: Two functions (F1 and F2) and two monitors (M1 and M2).
- M1 supervises F1.
In case F1 fails, M1 ensures that F1 has no effect.
- M2 supervises F2.
In case F2 fails, M2 ensures that F2 has no effect.
As long as (F1/M1) produces output, (F2/M2) is ignored.
limp home Property F0027
function migration Property F0028
may support a claim --> Functional Safety Association R0315
Tactics for Safety I
Tactics for Safety I Component Diagram D0011
This diagram shows examples for measures
- not aiming for completeness.
Especially for safety and security, selecting
the right set of the appropriate mechanisms is crucial.
Tactics for Safety I, Strategies for Safety Risk Mitigation, Tactics for Safety II
Functional Safety Class C0081
Tactics for Safety I, Strategies for Safety Risk Mitigation
Monitoring concept Block C0084
Function Monitoring (L2) Operation F0040
System Monitoring (L3) Operation F0041
- alive Monitoring Operation F0059
- control flow supervision Operation F0060
- self test Operation F0087
may support a claim --> Functional Safety Association R0093
Strategies for Reliability/A.+F.T.+R., Tactics for Safety I, Strategies for Security/Integrity
Input Signal Validation concept Block C0083
Precondition is a specification of valid input signals.
This can be implemented by different means, e.g.
- assert() statements
as declared in assert.h
- if(COND) {...} else {...} statements
where the else-path logs the error
For Security: Check input signals already at the gate, not later.
may support a claim --> Functional Safety Association R0095
Tactics for Safety I, Strategies for Safety Risk Mitigation
Real Time Execution concept Block C0085
Guaranteed Calculation Time Operation F0044
Real Time Clock Operation F0045
may support a claim --> Functional Safety Association R0098
Tactics for Safety I
Trusted Data Paths concept Block C0082
Dual Data Paths Operation F0042
End to End Protection Operation F0043
may support a claim --> Functional Safety Association R0094
Strategies for Security w/o Integr., Tactics for Safety I
Cryptographic Signatures concept Block C0079
asymmetric Property F0038
shared key (symmetric) Property F0039
may support --> Trusted Data Paths Association R0097
Strategies for Reliability/A.+F.T.+R., Tactics for Partitioning, Tactics for Safety I, Strategies for Safety Risk Mitigation, Strategies for Security/Integrity
Partitioning concept Block C0075
synonym for Compartments
see Tactics for Partitioning.
may support a claim --> Functional Safety Association R0096
Tactics for Safety I
freedom from interference (FFI) principle Class C0233
temporal freedom from interference Property F0085
spacial freedom from interference Property F0086
supports --> Partitioning Association R0284
Tactics for Safety II
Tactics for Safety II Component Diagram D0035
Strategies for Reliability/A.+F.T.+R., Strategies for Safety Risk Mitigation, Tactics for Safety II
Redundancy concept Class C0074
2 of 3 voter Property F0025
duo-duplex Property F0026
duo-duplex is a concept that consists of 4 independant parts: Two functions (F1 and F2) and two monitors (M1 and M2).
- M1 supervises F1.
In case F1 fails, M1 ensures that F1 has no effect.
- M2 supervises F2.
In case F2 fails, M2 ensures that F2 has no effect.
As long as (F1/M1) produces output, (F2/M2) is ignored.
limp home Property F0027
function migration Property F0028
may support a claim --> Functional Safety Association R0315
Tactics for Safety I, Strategies for Safety Risk Mitigation, Tactics for Safety II
Functional Safety Class C0081
Tactics for Safety II
Lockstep CPUs concept Class C0260
Two CPUs execute the same program with the same input data at the same time.
A deviation in the result is detected.
--|> Redundancy Generalization R0316
Tactics for Safety II
ECC on memory concept Class C0261
Error correction codes on volatile or persistant storages allow to correct one or two bitflips and to detect if more bitflips occurred.
Main causes for bitflips may be x-rays and cosmic rays; also reading nearby cells may cause bitflips in physically-close cells.
--|> Redundancy Generalization R0317
Process Quality
Process Quality Activity Diagram D0003
The turtle diagram shows the elements of a process.
Process Quality
Process process Class C0005
Name Property F0011
Description Property F0012
creates #--> Output Object Flow R0002
Process Quality
With What Class C0006
Tools Property F0050
Resources Property F0051
enables ··> Process Dependency R0003
Process Quality
Output Class C0007
Process output,
Evidence on performed process
Software/Documentation Property F0055
Evidence/Reports Property F0056
Process Quality
How Class C0008
Guidelines, Checklists,
Templates
Guidelines/Templates Property F0052
Tutorials Property F0065
enables ··> Process Dependency R0005
Process Quality
What Results Class C0009
Metrics Property F0053
Definition of Done Property F0054
controls ··> Process Dependency R0006
Process Quality
Who Class C0010
Roles,
Skills, Knowledge,
Trainings
Roles + Responsibilities Property F0048
Knowledge/Skills Property F0049
enables ··> Process Dependency R0004
Process Quality
Input Class C0011
Requirements/Design Property F0057
Software/Data Property F0058
is precondition for #--> Process Object Flow R0001
Standard Process Models
Standard Process Models Component Diagram D0006
Process Models that focus on Software Development
Standard Process Models
CMMI process Block C0058
Standard Process Models
Medical SPICE process Block C0060
Standard Process Models
Automotive SPICE process Block C0219
ISO/IEC 33001:2015 Property F0082
V Model
V Model Activity Diagram D0009
V Model
Requirements Definition process Activity C0064
System Requirements Definition consists of
- elicitating requirements
- baselining requirements
- analyzing requirements
elicitation Operation F0083
analysis Operation F0084
is basis for --> System Architecture Control Flow R0042
defines ··> System Qualification Test Dependency R0050
is basis for --> Requirements Refinement Control Flow R0322
V Model
System Architecture process Activity C0065
is basis for --> Requirements Refinement Control Flow R0043
defines ··> System Integration and Test Dependency R0051
V Model
Requirements Refinement process Activity C0066
Software Requirements Refinement
- refines system requirements so that only the parts that shall be implemented in software are addressed
- states requirements in a form that these are testable by software/qualification tests
- distinguishes functional requirements
- quality/non-functional requirements
- non-requirements (what must not happen)
- process requirements
is basis for --> Software Architecture Control Flow R0044
defines ··> Software Qualification Test Dependency R0052
V Model
Software Architecture process Activity C0067
Template: arc42, see Bibliography.
Method to check quality: ATAM, see C0165.
defines ··> Software Integration and Test Dependency R0053
The Software Architecture defines the modules, interfaces and relations
needed to integrate and test the system.
is basis for --> Construction Control Flow R0045
The Software Architecture defines the modules, interfaces and relations
needed to create the system parts.
V Model
Construction process Activity C0068
This process group consists of
- detailed design
- creating source code (implementation)
- integrating 3rd party software
--> Unit Test Control Flow R0133
V Model
Software Integration and Test process Activity C0069
Software integration consists of
- integration (building, linking, packaging, ...)
- integration test checks compliance to software architecture
feeds --> Software Qualification Test Control Flow R0047
V Model
Software Qualification Test process Activity C0070
feeds --> System Integration and Test Control Flow R0048
V Model
System Integration and Test process Activity C0071
System integration consists of
- installing software and configuration to devices
- managing versions (upgrade/downgrade/cross-variant-grade)
- integration test checks compliance to system architecture
feeds --> System Qualification Test Control Flow R0049
V Model
System Qualification Test process Activity C0072
validation Operation F0089
verification Operation F0088
V Model
Unit Test process Activity C0117
feeds --> Software Integration and Test Control Flow R0134
Standard Methods
Standard Methods List D0014
This diagram lists methods to ensure quality.
Outcome of these methods is either a list of requirements/actions that needs to be implemented or a risk list that needs to be assessed and mitigations defined.
Standard Methods
FMEA (Technical Risk Management) Object C0129
Failure Mode and Effects Analysis is performed later during project development and checks if the requirements defined by the HARA are met during the development process.
see https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis
Standard Methods
TARA (Security Analysis) Object C0130
Threat and Risk Analysis
Standard Methods
Safety Case (Goal Structured Notation) Object C0131
A safety case is an argument within a concrete project to provide evidence that a safety requirement is met in scope of the project context. This argument may be visualized using the Goal Structured Notation (GSN)
Standard Methods
ATAM (Architecture Tradeoff Analysis) Object C0177
Architecture Tradeoff Analysis
see C0165 at Bibliography.
Standard Methods
HARA (Hazard and Risk Analysis) Object C0258
A HARA is performed at project start, classifies the risks and defines the requirements towards the development process.
Security Analysis
Security Analysis Activity Diagram D0018
see Internet Security (C0172) in Bibliography.
Security Analysis
start analysis Initial Node C0137
--> Define Assets to Protect Control Flow R0147
Security Analysis
Define Assets to Protect Activity C0138
This step
- defines which assets to protect
- determines risks for the case these are spied, modified, etc.
--> Define System Context Control Flow R0151
Security Analysis
Define System Context Activity C0139
--> Show Locations of Assets Control Flow R0152
Security Analysis
Show Locations of Assets Activity C0140
Show the components where assets are located
and network lines where the assets pass along.
--> Define Trust Boundaries Control Flow R0251
Security Analysis
Define Attack Vectors Activity C0141
Define attack vectors, likelihoods and impacts. Based on this criticality, the mitigations are defined.
a good checklist for attack vectors is the stride model:
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
--> Define Mitigations Control Flow R0150
Security Analysis
Define Mitigations Activity C0142
security requirements Output Port F0081
--> Re-evaluate Risks Control Flow R0153
Security Analysis
Re-evaluate Risks Activity C0143
--> finish analysis Control Flow R0154
Security Analysis
finish analysis Final Node C0144
Security Analysis
security analysis process Activity C0192
+-- Define Trust Boundaries Containment R0250
+-- start analysis Containment R0203
+-- finish analysis Containment R0204
+-- Define Assets to Protect Containment R0205
+-- Re-evaluate Risks Containment R0206
+-- Define System Context Containment R0207
+-- Define Mitigations Containment R0208
+-- Show Locations of Assets Containment R0209
+-- Define Attack Vectors Containment R0210
Security Analysis
Define Trust Boundaries Activity C0210
Trust boundaries are measures to keep attackers out.
--> Define Attack Vectors Control Flow R0252
Security Incident Management
Security Incident Management Activity Diagram D0029
see also ISO 27001
Security Incident Management
start planning Initial Node C0211
--> par Control Flow R0253
Security Incident Management
Define activities to observe the operation Activity C0212
Plan to actively identify events and weaknesses.
--> end par Control Flow R0258
Security Incident Management
par Fork C0213
--> Define activities to observe the operation Control Flow R0254
--> Define rating for observed events Control Flow R0255
Security Incident Management
Define rating for observed events Activity C0214
Plan analysis and assessment of events.
--> Define reactions based on rating Control Flow R0256
Security Incident Management
Define reactions based on rating Activity C0215
Plan corrective measures.
--> end par Control Flow R0257
Security Incident Management
end par Join C0216
--> start operation Control Flow R0259
Security Incident Management
start operation Final Node C0217
Security Incident Management
incident management process Activity C0218
+-- start planning Containment R0260
+-- par Containment R0261
+-- Define activities to observe the operation Containment R0262
+-- Define rating for observed events Containment R0263
+-- Define reactions based on rating Containment R0264
+-- end par Containment R0265
+-- start operation Containment R0266
FMEA
FMEA Activity Diagram D0036
FMEA
List all system elements (hierarchical) Activity C0270
--> List the functions of each system element Control Flow R0324
FMEA
List the functions of each system element Activity C0271
--> Analyze all failures of system elements Control Flow R0325
FMEA
List system functions and severities of failure Activity C0272
--> List all system elements (hierarchical) Control Flow R0323
FMEA
Analyze all failures of system elements Activity C0273
--> Define effects on system and severity Control Flow R0326
FMEA
Define effects on system and severity Activity C0274
--> Define mitigations Control Flow R0327
FMEA
Define mitigations Activity C0275
Structure of FMEA
Structure of FMEA Class Diagram D0037
Structure of FMEA
Function of System abstract Class C0262
A functionality of the system
Structure of FMEA
Logical Block abstract Class C0263
An abstract system element that organizes functionalities.
This is the result of the "form follows function" principle.
*-- Function of System Composition R0014
Structure of FMEA
Port abstract Class C0264
A port/connector/pin of an abstract system element.
--|> Logical Block Generalization R0013
Structure of FMEA
Physical Element Class C0265
Any concrete system element like hardware, configuration data or software.
··|> Logical Block Realization R0015
*-- Function of Element Composition R0018
Structure of FMEA
Function of Element Class C0266
A functionality of a concrete physical system element.
Structure of FMEA
Risk Class C0267
A risk describes a situation that
Failure Mode Property F0094
What happend and what is wrong
Occurrence Property F0097
How likely/how often does the failure mode occur
Effect Property F0095
What is the consequence
Severity Property F0093
How severe is the effect for the system
occurs at --> Function of Element Association R0019
effects --> Function of System Association R0020
*-- Cause Composition R0022
Structure of FMEA
Cause Class C0268
The fault or failure mechanism that caused the failure mode.
*-- Mitigation Composition R0021
Structure of FMEA
Mitigation Class C0269
An action to mitigate or to reduce a risk.
preventive Property F0003
A preventive action is a solution in the design that mitigates or reduces the risk.
detection Property F0096
Mitigation of a risk by detection is possible if
a) the risk is sporadic and
b) a system reaction for detecting a failure is defined.
Create a System Architecture
Create a System Architecture Activity Diagram D0039
This diagram shows an approach to systems engineering, following ideas from several sources (see Bibliography)
Create a System Architecture
Understand Stakeholder Requirements Activity C0278
This process may produce use cases that show usage scenarios.
--> Derive System Requirements Control Flow R0328
Create a System Architecture
Derive System Requirements Activity C0279
--> Create functional view Control Flow R0329
Create a System Architecture
Create functional view Activity C0280
--> Create Logical View Control Flow R0330
Create a System Architecture
Create Logical View Activity C0281
--> Create Physical View Control Flow R0331
Create a System Architecture
Create Physical View Activity C0282
--> Review Test Cases Control Flow R0332
Create a System Architecture
Review Test Cases Activity C0283
Process Documentation
Process Documentation Class Diagram D0033
Process Documentation
term: Goal concept Class C0244
What to achieve? A goal should be
- a desired result
- realistic
- measurable
Process Documentation
term: Objective concept Class C0245
An objective is a step towards a goal.
It may be a goal broken down to
- short-term objectives
- responsible team
- partial results
··> term: Goal Refinement R0294
Process Documentation
term: Strategy concept Class C0246
Process Documentation
term: Tactic concept Class C0247
Tactic
··> term: Strategy Refinement R0300
Process Documentation
term: What Class C0248
+-- term: Goal Containment R0295
+-- term: Objective Containment R0296
Process Documentation
term: How Class C0249
+-- term: Strategy Containment R0297
+-- term: Tactic Containment R0298
··> term: What Trace R0321
Process Documentation
Project Execution Plan Class C0250
A plan/strategy document that explains how a project shall be executed.
··|> term: Strategy Realization R0301
o-- Plan of Artifacts Aggregation R0318
Process Documentation
Plan of Artifacts Class C0251
A plan document that defines workflow, tools, needed skills, review and approval processes.
RASIC Property F0091
··|> term: Tactic Realization R0302
o-- Template Aggregation R0319
o-- Guidelines Aggregation R0320
Process Documentation
Artifact (e.g. Document) Class C0252
··> Plan of Artifacts Trace R0303
··|> Template Realization R0304
Process Documentation
Template Class C0253
Process Documentation
Guidelines Class C0254
Process Documentation
Report on Results Class C0255
For example review reports or test results
provide evidence ··> Artifact (e.g. Document) Trace R0306
Process Documentation
How-To Class C0256
··> Guidelines Refinement R0307
Process Documentation
foreach artifact type Class C0257
+-- Plan of Artifacts Containment R0308
+-- Report on Results Containment R0309
+-- Template Containment R0310
+-- Artifact (e.g. Document) Containment R0311
+-- Guidelines Containment R0312
+-- How-To Containment R0313
Bibliography
Bibliography List D0023
Bibliography
Software Architecture in Practice Object C0165
Software Architecture in Practice (3rd Edition)
by Len Bass, Paul Clements, and Rick Kazman.
Addison Wesley / Pearson, 2013.
ISBN 978-0-321-81573-6
Bibliography
ISO/IEC 9126 Object C0166
ISO/IEC 9126 Software engineering — Product quality
Bibliography
ISO/IEC 25010:2011 Object C0167
ISO/IEC 25010:2011
Bibliography
arc42 Object C0168
https://arc42.org
Bibliography
Software Estimation Object C0171
Software Estimation - Demystifying the Black Art
by Steve McConnell,
Microsoft Press, 2006.
ISBN:0735605351
Bibliography
Internet Security Object C0172
Internet-Security aus Software-Sicht
by Kriha/Schmitz
Springer, 2008.
ISBN 978-3-540-22223-1
Bibliography
High Integrity Software Object C0173
High Integrity Software - The Spark Approach to Saftey and Security
by John Barnes
Addison Wesley / Pearson, 2003.
ISBN 978-0-321-13616-0
Bibliography
Engineering a Safer World Object C0174
Engineering a Safer World - Systems Thinking Applied to Safety
by Nancy G. Leveson
MIT Press, 2011.
ISBN: 9780262016629
Bibliography
Software Quality Engineering Object C0189
Software Quality Engineering - A practitioners approach by
Witold Suryn
Wiley, 2014
ISBN 978-1-118-59249-6
Bibliography
Adaptive AUTOSAR Coding Guidelines Object C0259
Guidelines for the use of the
C++14 language in critical and
safety-related systems
https://www.autosar.org/fileadmin/standards/R18-10/AP/AUTOSAR_RS_CPP14Guidelines.pdf
Bibliography
Systems Engineering Handbook Object C0276
Systems Engineering Handbook, 5th Edition
by INCOSE
Wiley, 2023
ISBN: 978-1-119-81429-0
Bibliography
SEBoK Object C0277
Guide to the Systems Engineering Body of Knowledge (SEBoK)
Lead Editor: Nicole Hutchison
SEBoK v. 2.11, released 25 November 2024
https://sebokwiki.org/
Notation
Notation Profile Diagram D0032
Notation
Class Metaclass Stereotype C0230
Notation
process Stereotype C0231
<path d="
M 0 5
L 2 4.5
L 3 3.5
l -1 -1 0 -1 1 0.5 1 0.75
c 2 -0.5 3 -1 5 0.25
l -1 -1 0 -1 2 1.5 0 1.5
l 1 0 0.5 -0.5 1.5 1.5
M 0 5
L 2 5.5
L 3 6.5
l -1 1 0 1 1 -0.5 1 -0.75
c 2 0.5 3 1 5 -0.25
l -1 1 0 1 2 -1.5 0 -1.5
l 1 0 0.5 0.5 1.5 -1.5
"/>
--|> Class Generalization R0282
*-- turtle Composition R0283
Notation
turtle process Image C0232
Internet Articles
Internet Articles Box Overview D0034
Internet Articles
Principles of technical documentation Comment C0243
https://www.innoq.com/en/articles/2022/01/principles-of-technical-documentation/