Inżynieria wymagań jest pierwszym etapem projektów informatycznych i ma decydujące znaczenie dla ich powodzenia. Inżynieria wymagań określa wszystkich interesariuszy projektu i jego zakres. Im staranniej określa się wymagania, tym mniej błędów powstaje w trakcie projektu. To truizm, który jest znany. Co więcej każdy (lub prawie każdy) uczestnik projektu to potwierdzi. Samo zebranie wymagań to ważny […]
Inżynieria wymagań – certyfikat Czytaj dalej »
Jedną z bardziej żmudnych czynności realizowanych w fazie wymagań jest analiza aktów normatywnych. W mojej ocenie dużym błędem jest wskazanie w wymaganiach na system iż ma on być zgodny np. z ustawą X. Moim zdaniem, niestety trzeba rozbić każdy (mający wpływ na system) paragraf i podpunkt na oddzielne wymaganie. Poniżej krótki opis mojego “sposobu” na
Akty normatywne a wymagania Czytaj dalej »
Planując pracę swoją czy też swojego zespołu staram się przestrzegać kilku zasad. Oto one: Plan szczegółowy buduję jedynie dla najbliższych zadań. Moim zadaniem użyteczne są plany na kilka najbliższych dni, tygodni, ale nie na kilka najbliższych miesięcy. Nie przepadam za wykresami Gantta. Coraz częściej dochodzę do wniosku, że wykresy Gantta mają małą wartość dla projektów
Planowanie w projekcie w nurcie Agile Czytaj dalej »
Lubię pracować z Enterprise Architectem. Mój ulubiony klawisz to F8 – generowanie dokumentacji. Wysyłam ją do klienta i po pewnym czasie wraca dokument kilkoma lub kilkudziesięcioma uwagami. Kilkaset do dużego dokumentu też nie jest czymś dziwnym. I tu zaczyna się mały dramat – zgodnie z dobrymi praktykami wszystkie te uwagi należy (przynajmniej ja tak robię)
Komentarze z MS Word w Enterprise Architect Czytaj dalej »
W trakcie prac projektowych lub analitycznych wielokrotnie powstaje potrzeba policzenia parametrów procesu biznesowego lub szacowania złożoności budowanego oprogramowania. Większość metod formalnych wymaga bardzo często dość trudnych obliczeń. Z drugiej strony w trakcie prac analitycznych lub projektowych powstaje zazwyczaj diagram aktywności, który w sposób naturalny prezentuje składowe procesu biznesowego lub elementy scenariusza przypadku użycia. W artykule
Szacowanie procesów biznesowych metodą diagramów aktywności Czytaj dalej »
W ostatnich kilku projektach spotkałem się z tym, że poświęca się masę czasu na budowę modeli zaniedbując wymagania. Oto kilka dobrych rad dla zespołów stosujących zwinne modele 1. "Oprogramowanie musi być oparte na wymaganiach”. Jeśli nie ma wymagań, nie ma czego budować. Celem Tworzenia Oprogramowania jest zbudowanie działającego oprogramowania, które spełnia wymogi udziałowców projektu. Jeśli
Sześć myśli na temat zwinnych wymagań Czytaj dalej »
Jedną z trudności, z jakimi spotykam się w EA to zarządzanie zmianą a dokładniej przyczyną zmiany. Na co dzień używam TORMIGO i tam problem ten został rozwiązany. TORMIGO monitoruje zmianę i ją odnotowuje wymuszając na mnie jakikolwiek opis. Film demo pokazałem w tekście: Automatyczne wersjonowanie wymagań. Nie wszyscy używają tej aplikacji jak w takim razie
Banalne zarządzanie informacją o zmianie w Enterprise Architect Czytaj dalej »
Praca grupowa w chmurze to bardzo wygodne rozwiązanie. Kto raz spróbował pisać tekst z inną osobą lub osobami w tym samym czasie w aplikacjach takich jak Google Docs, ten wie jak skuteczne i wartościowe są to rozwiązania. Dzięki takim produktom jak wspomniane Google Docs praca grupowa nabrała innego wymiaru. Wydaje się być celowym aby korzyści
Zarządzanie wymaganiami w Enterprise Architect z wykorzystaniem Google Docs Czytaj dalej »
Czy czas może być aktorem czy też nie oto jest pytanie? Jak zamodelować w konkretnym czasie aplikacji działanie? I inne tego typu pytania często są bolączką osób modelujących. Otóż jest opinia, że, można traktować czas jako aktora. Wówczas aktor reprezentujący czas może przykładowo rozpoczynać przypadek użycia odpowiadający za przygotowanie informacji o zarobkach, raportu lub rozesłanie
Czy czas może być aktorem? Czytaj dalej »
Opisując przypadki użycia stosuję kilka poziomów ich opisu. Najpierw identyfikuję aktorów i przypadki użycia potem dla każdego przypadku użycia opisuje punkty końcowe i początkowe by pomiędzy tymi punktami umieścić scenariusze. Jakiś czas temu wynotowałem z jakiejś publikacji taki oto zakres działania Aktorzy i cele. Wypisz aktorów i ich cele, których realizację system będzie wspomagał. Sprawdź
Jak opisywać przypadki użycia? Czytaj dalej »
