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 […]
Metoda punktów funkcyjnych Czytaj dalej »
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. W M B View more documents from Michał Wolski. Podobne wpisy Zintegrowane środowisko wytwarzania
KKIO 2009 – tekst Czytaj dalej »
Ostatni czwartek i piątek spędziłem wspomagając bardzo ciekawą firmę. Otóż jest to Polska firma pisząca systemy wspierające szerokorozumianą e-administrację. Nasuwa sie pytanie a gdzie są te systemy? Otóż w USA. Tak tak Polskie, niewielkie, firmy mogą pisać oprogramowanie wspierające obywateli innych Państw. A my, obywatele 4,5,6 RP jesteśmy gorsi? Myślę, że nie ale za to
e-administracja w Polsce Czytaj dalej »
W tym miejscu pozwolę sobie zebrać kilka cech, które świadczą o tym, że mamy do czynienia z dobrym modelem biznesowych przypadków użycia. Oto one: Biznesowe przypadki użycia są zrównane ze strategią firmy ? wspierają cele organizacji. Przypadki użycia są zgodne z organizacją, którą opisują. Wszystkie przypadki użycia są znalezione. Po zebraniu, przypadki użycia wykonują wszystkie
Charakterystyka dobrego Modelu Biznesowych Przypadków Użycia Czytaj dalej »
Kilka tygodniu temu (https://wolski.pro/2009/07/kkio-2009/) zapowiedziałem swój udział na Krajowej Inżynierii Oprogramowania. Tak tez się stało. 15 września w trakcie sesji pt: ?Modelowanie systemów? miałem okazję zaprezentować zarys metodyki WMB ( https://wolski.pro/wmb/). Moje wystąpienie na temat ?Zwinnego modelowania wymagań biznesowych w wytwarzaniu oprogramowania? spotkało się się z życzliwym przyjęciem uczestników XI Krajowej Konferencji Inżynierii Oprogramowania, które
Krajowa Konferencja Inżynierii Oprogramowania Czytaj dalej »
Budowanie modeli biznesowych coraz częściej znajduje uznanie wśród projektantów systemów. Wiąże się to z faktem, że modele biznesowe stanowią podstawę całego przedsięwzięcia bowiem pozostałe dyscypliny inżynierii oprogramowania (bazując teraz na dyscyplinach RUP )czerpią z niej w następujący sposób: Dyscyplina Wymagania wykorzystuje biznesowe modele jako istotne dane wejściowe dla zrozumienia wymagań systemu. Dyscyplina Analiza i Projekt
Związki modelowania procesów biznesowych z projektowaniem systemów informatycznych Czytaj dalej »
Celem modelowania biznesu jest: Zrozumienie bieżących problemów w docelowej organizacji i określenie potencjałów udoskonalenia. cena wpływu zmiany organizacyjnej. Zapewnienie, że klienci, użytkownicy, inwestorzy oraz inne strony będą rozumieć organizację w ten sam sposób. Wyprowadzenie wymagań systemu oprogramowania, które jest konieczne, aby wspierać docelową organizację. Zrozumienie jak system oprogramowania, który ma być wykorzystywany w przyszłości, wpasuje
Modelowanie biznesowe – znaczenie Czytaj dalej »
User story to opis celów zorientowanych na użytkownika, jakie jedna lub więcej osób osiągnie za pomocą Twojego produktu. User stories używa się do osiągnięcia celu zawsze wtedy, kiedy jest osoba obsługująca interfejs . User story pisze się w formacie Jako [osoba odgrywająca daną rolę] chcę [wykonać jakąś czynność] aby [osiągnąć jakiś cel]. W ten sam
Pisanie user story i scenariuszy przypadków użycia Czytaj dalej »
Kilka porad odnośnie przypadków użycia i aktorów. Przypadek użycia nie dostarcza funkcjonalności aktorowi Problem: Często oznacza to, że każdy przypadek użycia sam w sobie nie dostarcza wartości aktorowi. Rada: Proszę połączyć fragmentaryczne przypadki użycia w kompletną sekwencję takich fragmentów, które łącznie zapewnią wartość aktorom. Stanowiska pracy jako aktorzy Problem: Powszechnym błędem jest tworzenie aktorów, którzy
Przypadki użycia i aktorzy– kilka rad Czytaj dalej »
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
Wielkość i długość iteracji Czytaj dalej »
