Use Case – Page 4 – JZ IT Consulting Ltd

Udziałowcy projektu czyli który diagram UML …

Post author:Jaroslaw Zelinski
Post published:12 November 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu. UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań. Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią "korzeń" modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.

Po co dokumentować – wnioski po dyskusji na forum

Post author:Jaroslaw Zelinski
Post published:26 November 2010
Post category:Analizy biznesowa i projektowanie oprogramowania

Dokumentacja stanowi także element zarządzania wiedzą. Gdy nie ma dokumentacji nowy człowiek w zespole zajmuje czas kolegów, którzy muszą mu "opowiedzieć" o projekcie, jak jest dokumentacja, czyta ją sam nie obniżając efektywność pracy kolegów. Tak więc dla jasności: nie neguję typowej dla SCRUM czy XP wersji postępowania, a tylko wskazuje na sytuacje gdy preferowane są inne. Co do Agile podsumuję moje podejście: PMI czy Prince2 to dla mnie raczej formalny spis treści "projektu" ale dla każdego rzeczywistego projektu sam dobieram te elementy tego spisu, które mi pomogą i tak pojmuję zwinność projektową.

źródło: http://www.geotor.pl/przemysl.htm

User story – kłopoty

Post author:Jaroslaw Zelinski
Post published:8 November 2010
Post category:Analizy biznesowa i projektowanie oprogramowania

Tak więc wymagania na oprogramowanie powinny być określone przez dialog biznesowy zaś specyfikacja oprogramowania przez dialog technologiczny. I tu łyżka dziegciu: wiele razy byłem świadkiem gdy to zamawiający psuł projekt uważając, że wie lepiej jak się tworzy oprogramowanie. Zjawisko to (tu bardzo niebezpieczne dla życia ludzi) także zna inżynieria budowlana dlatego prawo budowlane wymaga projektu architekta a jego projekt chroni nie tylko prawo budowlane ale także i autorskie.

Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Post author:Jaroslaw Zelinski
Post published:24 May 2008
Post category:Analizy biznesowa i projektowanie oprogramowania

Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj "szczególnie klienta biznesowego". Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?

Przypadki użycia i UML: jak modelować

Post author:Jaroslaw Zelinski
Post published:28 April 2006
Post category:Analizy biznesowa i projektowanie oprogramowania

Tworzę model procesów (używam notacji i metodyki BPMN ale w prostszych przypadkach może to być np. diagram czynności UML), od którego proponuję zacząć. Potem wskazuję (wybieram) te czynności, które będą "komputeryzowane" (bo nie koniecznie wszystkie). W metodyce którą stosuję jest pojęcie czarnej skrzynki. Jest to np. projektowany jeszcze hipotetyczny system. Tworząc model procesów łączę czarną skrzynkę z wybranymi czynnościami (procesami) i optymalizuje tak powstały model.