o modelowaniu procesów i systemów 

Jako ciekawostkę podam iż Departament Obrony USA (DoD) – właściciel ram architektonicznych DoDAF używa Enterprise Architecta. Poniżej link do modelu Conceptualnego  frameworku  DoDAF.

http://cio-nii.defense.gov/sites/dodaf20/DM2_HTML/index.htm

Wynika z tego, że po EA sięgają coraz to większe instytucje

Za tę informację dziękuję Panu Andrzejowi, z którym ostatnio dyskutujemy o zastosowaniach EA w rozwiązaniach klasy Enterprise.

Planowanie w oparciu o kamienie milowe obejmuje określenie pożądanych wyników projektu i planowania progresji wobec nich poprzez serię kamieni milowych. Można określić dwa typy kamieni milowych:

• Kamienie milowe wypuszczenia – punkty, w których są udostępniane główne produkty wypuszczenia
• Wewnętrzne kamienie milowe – punkty, w których dokonuje się istotnego obiektywnie wymiernego postępu wobec zakończenia rozwiązania.

Każdy kamień milowy jest określony w zakresie celów, które muszą być osiągnięte oraz kryteriów oceny dla obiektywnej oceny, czy zostały osiągnięte. Każdy kamień milowy prezentuje:

• istotny punkt kontrolny projektu
• możliwość oceny dokonanego postępu i ponowną ocenę przyszłych planów
• możliwość dostosowywania się do planów.

Korzystając z techniki kamieni milowych pamiętaj aby zidentyfikować główne produkty kamieni milowych. Pamiętaj także, że granice iteracji zapewniają jasno określone wewnętrzne kamienie milowe dla projektów iteracyjnych.

Długość iteracji i jej wielkości pod względem zasobów musi być skorelowana z celami i pracą, które ma być wykonana. Moje wytyczne:

Wielkość zespołu – większe zespoły wprowadzają większe koszty stałe i tym samym prowadzą do dłuższej iteracji. Następujące wytyczne zapewniają przydatny punkt wyjścia:

• 2 – 15 osób: iteracja 2-4 tygodniowa
• 16 – 30 osób: iteracja 4-6 tygodniowa
• 31 – 50 osób: iteracja 6-8 tygodniowa.

Cele iteracji – niektóre cele wymagają więcej czasu na ukończenie niż inne

Wielkość kosztów stałych – im więcej sprawozdawczości oraz innych przeciążeń administracyjnych, które są nakładane na zespół, tym dłuższe będą musiały być iteracje

Podział zespołu – im bardziej podzielony zespół, tym trudniejsza komunikacja oraz tym więcej czasu zajmie uzgodnienie decyzji prowadzących do zwiększonego poziomu planowania i dokumentowania oraz dłuższych iteracji

Dostępność zasobów – Im mniej czasu, który członkowie zespołu  mają przeznaczyć na projekt, tym więcej czasu upłynie na iteracje

Formalność projektu – niektóre projekty mają bardziej surowe wymogi odnośnie przeglądów formalnych i dokumentacji projektowej, wymagając więcej czasu na te czynności

Obecnie znajdujemy się w dziwnej sytuacji ? są user stores (zwane w języku polskim historyjkami użytkownika) i scenariusze przypadków użycia z czego te ostatnie można podzielić na przypadki użycia formalne i nieformalne a także streszczenia przypadków użycia. Czym one się różnią, a w czym są takie same?

Przypadki użycia, scenariusze przypadków użycia i user stories dokumentują opis tego jak produkt ma być używany. Różnią się one, w kontinuum, pod względem ilości dodatkowych danych wymaganych dla stworzenia każdego z nich.

• Formalne przypadki użycia wymagają najwięcej wysiłku. Panuje w nich przepych i wiele się w nich dzieje, ale opisują wszelkie kombinacje tego, jak różne osoby wykonują tą samą czynność (lub jej odmianę).
• Nieformalne przypadki użycia są mniej więcej takie same- tyle tylko, że są mniej formalne. Wyzwaniem jest dostarczenie odpowiedniego poziomu szczegółowości, bez elementów prowadzących formalnych przypadków użycia, które mają służyć jako przypomnienie.
• Streszczenia przypadków użycia niemalże nie mają dodatkowych danych, ale zawierają takie sama wyzwania ?na ile jest to jest wystarczająco? co nieformalne przypadki użycia, tyle że w większym stopniu.
• User stories mają najmniej dodatkowych danych i dostarczają najmniejszy kontekst.

Scenariusze przypadków użycia to nieco inny przypadek. Podobnie jak user story, scenariusz przypadku użycia opisuje jedną ścieżkę przez wielościeżkowy przypadek użycia. Warto więc połączyć słabość przypadku użycia (wysoka ilość danych dodatkowych) ze słabością user story (ograniczony kontekst) co w konsekwencji da dość spójny i zwinny oraz pomocny artefakt.

Scrum to jedna ze zwinnych metodyk w nurcie Agile, stosowaną w procesie wytwórczym oprogramowania. SCRUM jest ukierunkowany na budowę gotowego kodu. Powstaje jednak pytanie co zrobić, gdy potrzebny jest model, lub specyfikacja projektu?

Jest na to sposób. Można budować modele zgodnie z  metodyką SCRUM. Na stronie: Modelowanie w SCRUM opisałem zarys SCRUM wraz z kilkoma wskazówkami wykorzystania języka UML w tej metodyce.

przeczytaj pozostałą część »

Cleeve Amos zamieścił poniższy obrazek w swojej prezentacji. Kolejny raz jeden obraz znaczy więcej niż setki słów.

Ukazał się nowy The Rational Edge (http://www.ibm.com/developerworks/rational/rationaledge/?S_TACT=105AGX63&S_CMP=DEVCOM), który jak zwykle niesie sporo ciekawych informacji. Mnie najbardziej podobały się artykuły dotyczące skalowalności metodyk zwinnych (Agile) Teksty te to ?Improving software economics: Top 10 principles of achieving agility at scale? , autorstwa Walker Royce?a oraz bardzo ciekawy tekst, który napisał Gary Pollice ?Does Agility scale? Wrong question!?

Miłej lektury

Dla siebie i dla tych co czasem tak jak ja chcą mieć dostęp do metodyk on-line zamieszczam linki pod którymi są one dostępne.

• Scrum
• OpenUP
• Extreme Programming

Miłego korzystania

Niestety nie działają one pod operą

Pod hasłem WMB gromadzić będę zestawy wskazówek pozwalające na dokumentację procesów biznesowych. Celem WMB nie jest tylko ułatwienie budowy modeli biznesowych, ale także rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli.

WMB to:

• aktywności ? jako wskazówki do działania ? zestawy czynności warunkujące osiągnięcie poprawnego modelu
• role  – jako zakres kompetencji dla osób wykonujących model biznesowy,
• notacja UML ? jako rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli,
• rozszerzenia narzędzi CASE -  jako profile pozwalające na budowę modeli biznesowych z wykorzystaniem notacji WMB

przeczytaj pozostałą część »

Bardzo się cieszę, że po kilku latach „ukrywania” w płatnych wersji metodyki Rational Unified Process (RUP) IBM uwolnił ją publikując bezpłatną jej wersję zwaną OpenUP – Open Unified Process.

Open Unified Process (OpenUP) jest częścią szablonu procesów Eclipse’a Eclipse Process Framework (EPF) o którym pisałem kilka dni temu.

Można powiedzieć, że proces OpenUP jest bratem procesu RUP. Z dokumentacji procesu OpenUP  można dowiedzieć się, iż opisywany proces jest iteracyjny, minimalny, kompletny i rozszerzalny. Ponadto podobnie jak w RUP w obrębie procesu występują cztery fazy:

• rozpoczęcie (ang. inception),
• opracowanie (ang. elaboration),
• wytworzenie (ang. construction),
• przekazanie (ang. transition).

W obrębie każdej fazy może występować wiele iteracji. Istotą OpenUP jest podział pracy na niewielkie iteracje, demonstrowanie wyników i ich ocena oraz otrzymywanie „sprzężenia zwrotnego” od odbiorców systemu.

W przeciwieństwie do RUP OpenUp nie wspiera modelowanie biznesowego. Więcej na temat tej metodyki można przeczytać na stronie dotyczącej Eclipse Process Framework.

Na początku lat 90-tych dwaj programiści: Kent Beck i Ward Cunnigham zdefiniowali kilka praktycznych reguł, które miały za zadanie uprościć proces wytwórczy oprogramowania. Tak powstała jedna z najbardziej kontrowersyjnych metodyk: Extreme Programming (XP)

Dla wszystkich zainteresowanych zamieszczam 12 praktyk XP wg Kenta Becka:

przeczytaj pozostałą część »