Za estymator złożoności systemu (lub układu systemów) przyjęliśmy liczbę znaczących stanów, w których ten system może się znaleźć. Zmniejszanie złożoności polega więc na zmniejszaniu liczby tych stanów.
Liczba stanów estymuje nam liczbę testów, które trzeba przeprowadzić, estymuje ilość linii kodu, które zawiera program oraz estymuje ilość analizy, którą trzeba przeprowadzić, aby go zrozumieć. Innymi słowy liczba stanów wpływa na koszty rozwoju systemu. W jakim stopniu?
Sessions R. twierdzi, że zależność kosztów rozwoju i utrzymania systemu od jego złożoności jest liniowa. Niestety na poparcie tej tezy nie podaje przekonującego dowodu.
Wg Garnera usunięcie zbędnej złożoności zmniejsza TCO liczone na jednego użytkownika o ok. 50%. Badania nad złożonością w przedsiębiorstwach opublikowane przez MIT CISR podają, że blisko połowa złożoności w przedsiębiorstwie to "zła" złożoność (zła, tzn przynosi więcej trudności dla firmy niż wartości dla klienta). Zestawienie tych dwóch faktów pokrywa się z tezą Session'a.
Gdyby przyjąć, że zależność kosztów rozwoju i utrzymania systemu (biznesowego i/lub informatycznego) od jego złożoności, jest liniowa (przemawia za tym teza Sessions'a oraz badania Gartnera i MIT CISR), to zmniejszenie złożoności systemu o 85% (co jest możliwe - patrz poprzedni wpis nt. złożoności) powinno nam zmniejszyć koszty rozwoju o 85%! Gra jest zatem zdecydowanie warta świeczki!
Źródła:
- Mieritz L., Frameworks that Matter: Using TCO and TVO to Identify, Develop and Drive Business and IT Improvements, 2009, Gartner, s.10.
- Sessions R., A Fundamental Metric for Predicting IT Success, ObjectWatch, Inc., 2012, http://www.objectwatch.com/whitepapers/ComplexityMetricSessions-100.pdf, [2012-07-14].
- Mocker M., Ross J.W., Rethinking Business Complexity, MIT CISR Research Brefing, Volume XIII, Number 2, February 2013, http://cisr.mit.edu/blog/documents/2013_0201_RethinkingBusinessComplexity_MockerRoss.pdf, [2013-05-22].
Brak komentarzy:
Prześlij komentarz