Informacje dotyczące zarządzania wymaganiami
Dostałem dziś pytanie: “..zaczynam procować na EA 7.5. i szukam sposobu żeby zastosować śledzenie zmian w dokumentach. Czy w ogóle jest taka możliwość.?…” Otóż nie wiem jak to jest w wersji 7.5 (nie mam już takowej) ale w wersji 9.3 w dokumencie należy włączyć taką opcję. Menu kontekstowe Edit –> Track Changes –> Enable Tracking […]
Śledzenie zmian w dokumentach w Enterprise Architect Czytaj dalej »
W czasie ostatnich wyborów, jeden z uczestników spotkania wyborczego zapytał: “Jak żyć Panie Premierze?” Przekładając na grunt modelowania często słyszę: “Jak modelować?”. I o ile daleko mi do Premiera i jego problemów dot. rządzenia krajem, tak blisko mi do problemów z modelowaniem. Otóż UML zna już sporo osób. Nieformalnym standardem w zakresie narzędzi jest Enterprise
Jak żyć Panie Premierze? Czytaj dalej »
Jako, że jestem w Polskiej Radzie IREB (International Requirements Engineering Board) pozwolę sobie donieść iż certyfikat CPRE (Certified Professional in Requirements Engineering) uzyskało już ponad 9 000 osób na całym świecie. Ponadto Kilka dni temu opublikowano słownik CPRE. Nowe tłumaczenia słownictwa dotyczą języka polskiego i szwedzkiego. Słownik jest do pobrania: http://www.certified-re.de/fileadmin/IREB/Download/Homepage%20Downloads/IREB_CPRE_Glossary_13.pdf Myślę, że na dniach
IREB 9000 osób ma certyfikat CPRE Czytaj dalej »
Kilka dni temu w poście Inżynieria wymagań – certyfikaty pisałem o problemach w standaryzacji pracy analityka. W tamtym wpisie (być może trochę przydługim) wskazałem potrzebę potwierdzenia swoich kompetencji odpowiednim certyfikatem. Zdaję sobie sprawę, że taki certyfikat to dla wielu osób “kwiatek do kożucha”, ale myślę, że warto by się z przyjrzeć temu kwiatkowi by móc
Certyfikowany inżynier wymagań Czytaj dalej »
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 »
