napisane przez Michał Wolski | w kategorii agile, teksty, zwinne modelowanie
środa 16 cze 2010
Iteracyjny model wytwarzania oprogramowania by był bardziej skuteczny wymaga kilku zabiegów. Chodzi oto by w ujęciu agile być rozważnym i skutecznym. Stosuję je podczas zwinnego modelowania. Oto kilka z nich:
- Krócej znaczy lepiej. Iteracja nie powinna być dłuższa niż 4 tygodnie, w przeciwnym wypadku możesz wpaść w styl tworzenia oprogramowania mini-waterfall. Osobiście preferuję jedno lub dwutygodniowe iteracje. Dzięki temu tempo tworzenia oprogramowania jest stałe, jako że regularne dostarczasz nowe funkcjonalności.
- Zacznij od niekomfortowego okresu czasu. Kiedy zmieniasz tradycyjną organizację na ewolucyjne (iteracyjne i przyrostowe) podejście do tworzenia oprogramowania spróbuj określić okres czasu, który będzie odpowiedni (np. 8 tygodni) i odejmij tydzień lub dwa (np. zacznij od 6-tygodniowej iteracji) aby zmusić ich do zmniejszenia biurokracji. Zrób kilka takich iteracji, a następnie skracaj długość iteracji dopóki nie dojdziesz do sensownego okresu czasu (np. mniej niż 4 tygodnie).
- Zignoruj kalendarz. Jeśli Twoja iteracja została zaplanowana na tydzień, zrób ją od środy do wtorku. Iteracje trwające od poniedziałku do piątku zazwyczaj cierpią przez to, że w piątek skupienie i energia dramatycznie zmniejszają się, ponieważ jest to koniec iteracji i koniec tygodnia. Ten zbieg okoliczności zmniejsza produktywność.
- Stwórz coś użytecznego. Zasadniczo iteracja powinna być na tyle długa, abyś był w stanie zrobić coś pożytecznego w jej trakcie. Niektóre zespoły robią jednodniowe iteracje.
- Przeprowadź tyle iteracji, ile potrzebujesz. Wymagania zmieniają się, co oznacza, że czas potrzebny na wdrożenie systemu też musi się zmienić, aby to odzwierciedlić.
- Cały czas możesz mieć stałą datę ukończenia oprogramowania. Jeśli potrzebujesz mieć stałą datę ukończenia oprogramowania, to po prostu ustal tą datę i do tego czasu ukończ tworzenie oprogramowania. Aż do czasu, w którym musisz oddać oprogramowanie, prowadź iteracje dotyczące tworzenia oprogramowania. Jeśli stale wdrażasz wymagania o najwyższym priorytecie, a wtedy to, co do dostarczysz, będzie miało najwyższą możliwą wartość.
napisane przez Michał Wolski | w kategorii agile, teksty, zarządzanie wymaganiami, zwinne modelowanie
czwartek 15 kwi 2010
Właściwym podejściem do definiowania przypadków 
użycia dla tworzenia oprogramowania przy użyciu metody agile to zacząć od definicji zakresu. Definicje zakresu można opisać za pomocą diagramów WPA (Wysokiego Poziomu Abstrakcji)
Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane do harmonogramu projektu.
Co pewien czas warto także dokonywać refaktoryzacji przypadków użycia, w miarę potrzeb konsolidując i definiując podrzędne przypadki użycia, oraz definiując, jeśli zachodzi taka potrzeba, rozszerzeń przypadków użycia.
napisane przez Michał Wolski | w kategorii teksty, zarządzanie wymaganiami
poniedziałek 12 kwi 2010
Wiele mówi się o tym co dają przypadki użycia dla wymagań na system. Warto jest tez wiedzieć iż przypadki użycia pozwalają, zwłaszcza w projektach agile, na określenie celu i zakresu projektu.
Zasadniczo bez przypadków użycia:
- Projektanci nie mają pojęcia, jaki cel ma użytkownik.
- Zespół nie zostaje poinformowany odpowiednio wcześnie o zakresie projektu.
- Różne zachowania użytkowników nie są zdefiniowane przed zobowiązaniem do dostarczenia.
Zastosowanie przypadków użycia pozwala na zapanowanie na tymi ?bolączkami? po przez określenie kontekstu i zakresu.
Kontekst
Nawet w projektach agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Cele te widać w każdym ustrukturyzowanym podejściu. Takim podejściem, są przepadki użycia, które dostarczają także kontekst ? czyli cel determinujący powstanie aplikacji.
Zasada jest taką, że każdy cel ma przypisany minimum jeden przypadek użycia. W ten oto sposób można się odnieść do tych celów za pomocą scenariuszy i/lub user stories.
Zakres
Z politycznego punktu widzenia największym problemem z uruchomieniem projektu agile w organizacjach typu waterfall są niewłaściwe ustalenie oczekiwań. Ustalenie oczekiwań i w ten sposób zabezpieczenie zarówno finansowania jak i wsparcia dla projektu może być ważniejsze niż samo wykonanie.
Aby ustalić, jakie są oczekiwania trzeba koniecznie zidentyfikować zakres projektu. Ustalanie zakresu polega ogólnie na zarządzaniu stronami zainteresowanymi oraz ustalaniu priorytetów celów osób zainteresowanych.
Kluczem jest tutaj dokonanie wpierw przeglądu zakresu, a potem jego dokładne zrozumienie poprzez przeprowadzanie iteracji.
napisane przez Michał Wolski | w kategorii Enterprise Architect, o inżynierii oprogramowania, teksty
piątek 2 paź 2009
Warto wiedzieć, że istnieją na rynku narzędzia CASE, które wspierają inżynierów oprogramowania nie tylko w zarządzaniu wymaganiami, modelowaniu, projektowaniu systemów informatycznych, generowaniu kodu aplikacji, ale również w szacowaniu pracochłonności ich wytworzenia. Jednym z nich jest Enterprise Architect firmy Sparx System, który wspiera estymację pracochłonności wykonania sytemu informatycznego metodą punktów przypadków użycia.
W celu skorzystania z funkcjonalności związanej z szacowaniem pracochłonności, należy podczas tworzenia modelu systemu informatycznego konsekwentnie definiować istotne z punktu widzenia metody punktów przypadków użycia parametry wybranych komponentów, z których składa się model oraz zdefiniowania odpowiednich wartości parametrów dla tej metody.
Rysunek 1. Przeglądarka projektu narzędzia Enterprise Architect i widoczne elementy modelu systemu oceny pracowników: aktorzy systemu i przypadki użycia.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii Enterprise Architect, o inżynierii oprogramowania, teksty
piątek 2 paź 2009
W tekście Szacowanie projektu w Enterprise Architect cz. 1 zdefiniowałem czynniki złożoności technicznej i środowiskowej. Teraz należy doprecyzować pozostałe parametry.
Po pierwsze możemy ustawić wartość dla parametru zwanego współczynnikiem produktywności PF (ang. Productivity Factor). Pamiętamy, współczynnik produktywności przekształca nam jeden punkt przypadku użycia na ilość godzin pracy człowieka, autor metody UCP proponował wartość tego parametru na poziomie 20. W narzędziu Enterprise Architect na zakładce Default Hour Rate okna Estimation factors (patrz rysunek 1) wartość tą wprowadza się do pola nazwanego Duration.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
czwartek 1 paź 2009
Metoda punktów przypadków użycia (ang. Use Case Points ) w skrócie UCP posiada podobny mechanizm do tego jaki zastosowano w metodzie punktów funkcyjnych (Metoda punktów funkcyjnych), jednak zrezygnowano z wykorzystania ekranów i architektury. Dlaczego pominięto ekrany i architekturę? Otóż wyobraźmy sobie sytuację, w której klient zadaje pytanie o czas realizacji projektu na etapie specyfikowania wymagań. Jak się okazuje w tej sytuacji metoda punktów funkcyjnych jest nieużyteczna, gdyż nie posiadamy jeszcze zdefiniowanej architektury, czy też propozycji ekranów. Należy więc zastanowić się czy wymagania systemu mogą być podstawą do estymacji pracochłonności realizacji systemu informatycznego. Twierdząco na tak postawione pytanie odpowiedział w 1993r. Gustaw Karner – twórca metody punktów przypadków użycia. Wymienił on architekturę i ekrany na specyfikację wymagań zapisaną w postaci specyfikacji przypadków użycia. Ponadto zasugerował, że należy zwrócić uwagę na tak zwane czynniki złożoności środowiska opisujące w dużej mierze organizację, która wytwarza oprogramowanie, czynniki złożoności technicznej opisujące własności produktu oraz przyszłych aktorów systemu.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
czwartek 1 paź 2009
Początki Use Case Points sięgają innej znanej metody służącej do szacowania rozmiaru oprogramowania, a mianowicie metody punktów funkcyjnych. Metoda ta zaproponowana przez Allana Albrechta (IBM) w 1979 bazowała na projektach ekranów oraz architekturze systemu. Była to próba przezwyciężenia problemów związanych z użyciem liczby linii kodu (która nie jest znana na etapie definicji wymagań a była podstawą do estymacji) jako miary wielkości oprogramowania i jednocześnie próba opracowania metody przewidzenia wysiłku związanego z produkcją oprogramowania. W metodzie tej występowało pięć głównych klas atrybutów produktywności, które charakteryzowały system:
- zewnętrzne wejścia (ang. External Inputs)
- zewnętrzne wyjścia (ang. External Outputs)
- zewnętrzne zapytania (ang. External Inquires)
- pliki wewnętrzne (ang. Internal Logical Files)
- pliki zewnętrzne (ang. External Interface Files)
Dla każdej kategorii zdefiniowane były trzy stopnie złożoności: prosty, średni i złożony. Z kolei z każdym stopniem złożoności były związane ustalone wartości wag.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty, zwinne modelowanie
poniedziałek 28 wrz 2009
Z racji tego, że publikacja odnośnie zwinnego podejścia w zakresie modelowania procesów biznesowych (WMB) ?pisałem o tym kilka dni temu w tekście pt ?Krajowa Konferencja Inżynierii Oprogramowania?- ukazała się w limitowanej edycji 150 egzemplarzy pozwalam sobie na publikację skanu tego tekstu.
napisane przez Michał Wolski | w kategorii teksty, zarządzanie wymaganiami
piątek 26 cze 2009
Jakiś czas temu na stronie Pana Kowalczykiewicza http://www.cs.put.poznan.pl/kkowalczykiewicz/ był ciekawy tekst na temat dobrych praktyk w inżynierii wymagań. Obecnie ta strona jest wyłączona. Z tego też powodu pozwalam sobie na publikację tego tekstu, który (co mnie zadziwia) miałem w swoim archiwum. Tekst ten został odrobinę przeformatowany.
Ian Sommerville i Pete Sawyer zaproponowali ciekawą metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na wyodrębnieniu dobrych praktyk, czyli czynności będących pożądanymi elementami wzorcowego procesu inżynierii wymagań. Autorzy starali się przy tym objąć całość problematyki inżynierii wymagań. Dobre praktyki reprezentują więc następujące obszary działalności:
- dokument specyfikacji wymagań,
- pozyskiwanie wymagań,
- analiza i negocjacja wymagań,
- opisywanie wymagań,
- modelowanie systemu,
- weryfikacja wymagań,
- zarządzanie wymaganiami,
- systemy krytyczne.
Biorąc pod uwagę te kryteria wyodrębniony został podział praktyk na trzy grupy wg zaawansowania powiązanego z tymi kosztami i poziomem skomplikowania:
Dobre praktyki stanowią podstawę do oceny poziomu dojrzałości procesów inżynierii wymagań w organizacji. Zakres wspomnianych dobrych praktyk opisałem w poniższych punktach:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, teksty, zwinne modelowanie
niedziela 21 cze 2009
Każdy sprint kończy się Spotkaniem Przeglądowym Sprintu (ang. Sprint Review Meeting), gdzie zespół pokazuje potencjalnie wykonalne przyrosty produktu.
Na końcu każdego sprintu odbywa się Spotkanie Przeglądowe Sprintu. W trakcie spotkania Zespół Scrum pokazuje, co osiągnął podczas sprintu. Na ogół przybiera to formę demonstracji nowych cech. Uczestnicy Przeglądu Sprintu to zazwyczaj Właściciel Produktu, Zespół Scrum, Mistrz Scrum, kierownictwo, klienci a także inżynierowie z innych projektów. Podczas przeglądu sprintu ocenia się projekt względem celu sprintu ustalonego na Spotkaniu dot. Planowania Sprintu. Sytuacją pożądaną jest, aby zespół wykonał każdą pozycję Product Backloga przeniesioną do sprintu, ale ważniejsze jest, aby osiągnąć ogólny cel sprintu.
Spotkanie przeglądowe sprintu jest celowo bardzo nieformalne, na ogół zakazuje się stosowania slajdów w PowerPoincie i daje się nie więcej niż dwie godziny czasu na przygotowanie do tego spotkania. Spotkanie przeglądowe sprintu nie powinno przerodzić się w zakłócenie uwagi czy drogę okrężną dla zespołu; powinno być ono raczej naturalnym rezultatem sprintu.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
czwartek 7 maj 2009
Architektura zorientowana na usługi to naturalny krok ewolucyjny od podejść zorientowanych obiektowo (OO), proceduralnych oraz dano-centrycznych stosowanych we wdrażaniu rozwiązań.
Fundamentalnymi zasadami rządzącymi SOA są:
-
Wiadomości wymieniane pomiędzy uczestniczącymi systemami muszą być opisowe a nie instruktażowe, ponieważ system informatyczny świadczący usługę odpowiedzialny jest za wszelkie problemy. Komunikaty opisowe podają informacje o usłudze oraz o powiązanych z nią danych wejściowych i wyjściowych. Usługodawcy odpowiedzialni są za wskazówki; stąd też potrzeba na komunikaty instruktażowe nie istnieje.
-
Słownik oraz struktura komunikatów muszą być zrozumiałe przez wszystkie strony. To powszechne zrozumienie przez wszystkie strony wymaga ograniczenia słownictwa oraz struktury komunikatów, ale jest koniecznością dla skutecznego komunikowania.
-
Struktura komunikatu powinna być rozszerzalna.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii Enterprise Architect, teksty, zarządzanie wymaganiami
poniedziałek 4 maj 2009
Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny.
W projektach dla mnie ważne jest to jak wymagania są mapowane na konkretne przypadki użycia (PU). Pozwala to stwierdzić, które PU są bardziej złożone, wymagają większej uwagi i są ważniejsze dla klienta. Aby to stwierdzić trzeba zmapować PU z konkretnymi wymaganiami. W tym celu dodaję wymagania na diagram i łączę asocjacja z PU a jeśli diagram jest nieczytelny to związki dodaje w macierzy. Wygenerowanie macierzy?
przeczytaj pozostałą część »
