UML – Page 26 – JZ IT Consulting Ltd

Korzyści z Architektury Korporacyjnej

Post author:Jaroslaw Zelinski
Post published:30 July 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Od czego należy zacząć? Od zbudowania własnej (lub własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności - Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją (podobnie jak lekarz domowy to raczej nikt z domowników).

Dane są nieważne bo liczy się przede wszystkim mechanizm działania

Post author:Jaroslaw Zelinski
Post published:23 July 2013
Post category:Przykładowe projekty

Często słyszę, że to trudne i pracochłonne (dodatkowe klasy w modelu) ale niestety zbyt prosty projekt potrafi być kosztowniejszy w rozbudowie w porównaniu z pierwotnym wytworzeniem, dlatego jak klient w ramach wymagań wpisuje (a wpisuje coraz częściej): system ma umożliwiać łatwe rozszerzenia funkcjonalności, to należy go tak projektować, w przeciwnym wypadku wymaganie to nie jest spełnione... Druga uwaga: często sami klienci zabijają swoje projekty żądając na samym początku dokumentowania wszystkich szczegółów jakie im do głowy przyjdą nie potrafiąc jednocześnie opisać mechanizmu działania ich organizacji. To niestety często spotykane zjawisko, z którym moim zdaniem należy walczyć. Paradoksalnie złożoność systemów biznesowych tkwi w mechanizmie ich funkcjonownia a nie w danych które zbierają (których nie raz jest po prostu za dużo...)

System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden

System Analysis And Design with UML 2.0

Post author:Jaroslaw Zelinski
Post published:2 July 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Książkę polecam przede wszystkim analitykom do nauki ale także "wyżartym" programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.

Wszystkie drogi prowadzą do Rzymu – zarządzanie jakością

Post author:Jaroslaw Zelinski
Post published:25 June 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

... spotykam się jednak w literaturze z tezami, że wdrożenie jakichkolwiek norm, nie tylko jakości, powinno być także poprzedzone analizą. Innymi słowy normy jakości powinny być wdrażane jako odpowiedź (rozwiązanie) na określone wymagania, a nie dla samego faktu ich wdrażania. Owszem, bywa, że wymaganiem jest np. wymóg przetargowy (oferty mogą składać tylko firmy mające określony certyfikat), jednak moda na jakość, mimo że nie przeminęła całkowicie, powoli przechodzi w racjonalne powody wdrażania norm jakości.

Analiza procesowa a obiektowa czyli niedopasowanie oporu

Post author:Jaroslaw Zelinski
Post published:19 June 2013
Post category:Przykładowe projekty

Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.