O budowaniu słowników i SBVR

O analizie pojęciowej pisałem nie raz, chyba pierwszy raz w krótkim artykule Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych. Niestety nadal problemem większości  dokumentów, takich jak analizy i specyfikacje, jest ich niespójność i niejednoznaczność. W niedawnym artykule SBVR czyli reguły biznesowe i słownik pisałem o diagramie faktów, o regułach i o słowniku pojęć, dzisiaj co nieco o pojęciach (tych ze słownika pojęć ;)). Ostatnia wersja specyfikacji SBVR v.1.3. z maja tego roku, zawiera rozszerzony rozdział:  8 Linguistic Foundations, 8.1 Things, Meanings, and Expressions, 8.1.1 Semiotic/Semantic Triangle in SBVR Terms rozpoczynający się tak: This sub…

Czytaj dalejO budowaniu słowników i SBVR

Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie

Istnieje coś takiego jak zasada SOLID projektowania oprogramowania (jedna z kluczowych cech dobrych projektów oprogramowania). Cóż to jest SOLID? To rozwinięcie od ang. Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion (więcej na stronie SOLID (object-oriented design) - Wikipedia, the free encyclopedia). Dzisiaj tylko o skutkach zaniedbania jednej, kluczowej chyba własności, która dotyczy całej aplikacji: Open-Close, która oznacza: aplikacja powinna być zamknięta na zmiany i otwarta na rozbudowę. Dla wielu na początku ta zasada brzmi wręcz kuriozalnie ale ona jak najbardziej jest możliwa do realizacji. Proszę zwrócić uwagę, że takie własnie są dobrze zarządzane firmy, nie ma w nich rewolucji organizacyjnej co roku, one się rozwijają a nie zmieniają. Oprogramowanie, jeżeli w wyniku analizy wymagań opracowano nie tylko raport z wywiadów ale także model logiki działania, też spełni te zasadę. Czym grozi jej niespełnienie w stosunku do oprogramowania? A tym, do czego przyznał się jeden z programistów podczas pewnej dyskusji na forum: kilka razy doświadczyłem sytuacji, że aby spełnić nowe proste wymaganie trzeba było się namęczyć zarówno z modelem danych jak i aplikacją, Oczywiście można w takiej sytuacji zarzucić, że system był źle zaprojektowany, nieskalowalny, nie przestrzegał SOLIDów, nie korzystał z wzorców itd ale to już jest inna bajka. Na co ja odpowiedziałem: nie, to jest właśnie ta bajka o nazwie analiza wymagań i projektowanie, które powinny być zrozumieniem a nie tylko stenogramem. Wtedy nowe funkcjonalności oprogramowania można dodawać bez potrzeby przebudowy jego wewnętrznej struktury. Nie raz jest z powodu tych kosztów po protu niemożliwy jest rozwój systemu. Oceńcie teraz Państwo sami, Ci którzy tego doświadczyli, skutki wdrożenia np. systemu ERP z kastomizacją.... niestety ogromna większość tego oprogramowania nie spełnia zasady SOLID. Dlaczego? Bo model relacyjny baz danych, jeżeli obejmuje wszystkie dane systemu, niestety nie spełnia tej zasady z założenia. A dostawcy tych systemów wręcz cieszą się z tego reklamując się: "nasz system jest w pełni zintegrowany poprzez pracę na wspólnej bazie danych".... Jak to przeczytasz, nie kupuj tego...

Czytaj dalejAnaliza wymagań na oprogramowanie czyli opisanie czy zrozumienie

Koniec treści

Nie ma więcej stron do załadowania