exercise 3 (quality attribute tradeoff) complete, please check
This commit is contained in:
parent
8ad9db31c7
commit
12e7ad711e
1 changed files with 16 additions and 0 deletions
|
@ -382,9 +382,25 @@ Exceed: >2 trade-offs
|
||||||
|
|
||||||
}
|
}
|
||||||
|
|
||||||
|
<!--
|
||||||
## Portability vs. Performance (Example)
|
## Portability vs. Performance (Example)
|
||||||
|
|
||||||
Developing an app natively for each OS is expensive and time consuming, but it benefits from a good performance. Choosing a cross-platform environment on the other hand simplify the development process, making it faster and cheaper, but it might suffer in performance.
|
Developing an app natively for each OS is expensive and time consuming, but it benefits from a good performance. Choosing a cross-platform environment on the other hand simplify the development process, making it faster and cheaper, but it might suffer in performance.
|
||||||
|
-->
|
||||||
|
|
||||||
|
## Feasibility vs. Configurability
|
||||||
|
|
||||||
|
Developing an highly configurable product may be beneficial as the product may be easily reusable (e.g. via white labelling), but it may be more expensive or time consuming than building an ad hoc solution. Developing an product with less configuration options may be more feasible w.r.t. deliverability to the first client. However, since configurability is impacted, future requests from that customer or other customers wishing to use the same product may be more costly and/or time consuming.
|
||||||
|
|
||||||
|
## Ease of support vs. Portability
|
||||||
|
|
||||||
|
An highily portable product is inherently more difficult to provide support for due to the possible differences between the supported platforms. In turn, a
|
||||||
|
product with high ease of support may have official documentation procedures and troubleshooting domain knowledge bound to a particular platform only because
|
||||||
|
customers typically use that platform or that platform is the only one officially supported "by contract".
|
||||||
|
|
||||||
|
## Performance vs. Modularity
|
||||||
|
|
||||||
|
An highly modular system may have lower performance than an equivalent monolith implementation due to the cost that the interfaces between microservices pose (e.g., if microservices communicate via HTTP, a monolith may be more performant than the equivalent microservice architecture due to the absence of these calls). Conversely, an highly performant architecture may be optimized in such a way that may impact modularity (e.g. functionally distinct components and abstractions may be combined for the sake of performance, even if the resulting code is less modular and more difficult to maintain - consider C++ friend classes).
|
||||||
|
|
||||||
# Ex - Feature Modeling
|
# Ex - Feature Modeling
|
||||||
|
|
||||||
|
|
Reference in a new issue