Systemowo o rentowności czyli właściwe granice systemu

Wyznaczenie granicy (pod)systemu to rola analityka i architekta systemów. Szkoda, że tak rzadko się korzysta z tej specjalności. Być może nie zlikwidowany by tak wielu lokalnych połączeń kolejowych uznając, że stanowią one razem system a w pojedynkę są niesamodzielne. Pewnie uznanie, że nie sam Zakład Komunikacji Miejskiej a właśnie miasto i jego infrastruktura razem stanowi system, który należy oceniać i rozwijać. "Darmowe autobusy mają pomóc odkorkować Bełchatów" czyli może jednak łączymy jakimś związkiem w jeden system dostępność komunikacji miejskiej, liczbę prywatnych samochodów osobowych, koszty zanieczyszczenia atmosfery, koszt budowy parkingów i poszerzania ulic. [...]

Wykorzystanie dokumentów wymagań

W trakcie trwania projektu dokumentacja wymagań stanowi podstawę dla różnych zadań: Planowanie: Specyfikacja wymagań stanowi podstawę dla planowania pracy i punktów milowych w procesie tworzenia oprogramowania. Projektowanie architektury: Szczegółowy dokument wymagań, zawierający opis ograniczeń, stanowi podstawę dla projektowania architektury systemu...

Różne perspektywy wymagań

Nie powinniśmy zapominać, że model Kruchtena to połowa lat 90-tych, szczyt rozkwitu metod strukturalnych i raczkujące metody i narzędzia obiektowe. To stare systemy i ich relacyjne bazy danych wymusiły stosowanie [[mapowania ORM]] i takich narzędzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tamtej pory minęło 20 lat. Nie musimy się cofać do początków inżynierii oprogramowania w wersji obiektowej. Coś takiego jak perspektywa danych to anachronizm. Podejście to w 100% zostały już dawno zastąpione przez MDA. [...]

Perspektywy wymagań

Wymagania na system specyfikują system z różnych perspektyw. Z moich doświadczeń wynika, że warto jest dokumentować wymagania z trzech perspektyw. Perspektywa danych: W tej pespektywie dokumentowana jest struktura danych wejściowych/wyjściowych do/z systemu, a także statyczna struktura danych wykorzystywanych w systemie...

Agile Modeling. Effective Practices for Modeling and Documentation

Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć [...]

Software Architecture in Practice

Jednym z moich niedawnych nabytków jest bardzo wartościowa książka, jednak nie jest to podręcznik analizy i modelowania, a opis wieloletnich doświadczeń autorów w tworzeniu i dokumentowaniu architektury oprogramowania.

The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in [...]

Dokumentacja wymagań w oparciu o przypadki użycia

Przypadki użycia służą do dokumentacji funkcjonalności systemu i bazują na dwóch wspólnie wykorzystywanych koncepcjach: Diagramach przypadków użycia Specyfikacjach przypadków użycia Obiekty: Przypadek użycia (PU): Przypadek użycia reprezentuję funkcję systemu, która reprezentuję osiągnięcie jakiegoś celu w systemie. Nazwa przypadku użycia powinna...

Systemowo o ekonomi czyli modele biznesowe

Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje: - sama struktura to nie model, - tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury, - dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]), - bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.

Krzywe i koszty… architektury

Niestety wiele systemów ERP i i nie tylko, powstało w latach 90'tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i "nad nią" funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie - jak to zachwalają ich dostawcy - zaletą...