Category Archives zarządzanie projektami

Bardzo często zdarza się, że chcemy mieć informację o tych elementach, które nie zostały zmapowane na inne elementy. Przykładowo możemy szukać tych wymagań, które nie realizują żadnych przypadków użycia. Inny przykład to poszukujemy tych elementów procesu biznesowego, który nie wspierają usługi aplikacyjne. Innymi słowy szukamy samotnych elementów. Enterprise Architect wspiera możliwość raportowania takich osieroconych elementów. Są dwa sposoby na szukanie.…

Dzisiejszy wpis poświęcony jest Software & Systems Process Engineering Meta-Model Specification (SPEM). Co to jest SPEM? SPEM to zaproponowany przez OMG (ang. Object Management Group), który został pomyślany jako spójny zestaw pojęć do opisu procesu inżynierii oprogramowania. Co oferuje SPEM? Cytując artykuł “SPEM/UML w specyfikacji procesów zarządzania projektem” (Iwona Dubielewicz, Jerzy Sas, e-Informatica Software Engineering Journal/ “Problemy i metody inżynierii…

Dziś przyszedł moment, w którym podjąłem decyzję o napisaniu ostrzegawczego posta. Przed czym ostrzegam? Otóż na jesieni 2013 roku prowadziłem prace doradcze dla konsorcjum firm realizujących projekt w dla m. st. Warszawy.  Zlecenia na piśmie były od jednego z konsorcjantów a zadania od wszystkich. Efekt prac. Wszystkie prace zostały odebrane. Nie otrzymałem ani jednej uwagi. Problem jest niestety taki iż…

Tadeusza Golonkę spotkałem prowadząc wykłady na Politechnice Warszawskiej. Na jednym studium podyplomowym PW prowadziliśmy równolegle zajęcia. Ja miałem zajęcia z projektowania systemów informatycznych a Tadeusz - autorski wykład nt. dobrych praktyk w zarządzaniu projektami (w oderwaniu od metodyk) i warsztaty w oparciu grę edukacyjną „Wieża Eiffla – Zarządzanie Projektami Informatycznymi”. To też autorski warsztat, który jak miałem się okazję ostatnio…

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 etap. Schody zaczynają się jednak dalej. Trzeba zweryfikować pozyskane wymagania, uszczegółowić, nadać priorytety. Gdzie te schody? Otóż co analityk to inne kompetencje, inne doświadczenia. Choćby ostatnio w jednym z projektów gdzie reprezentuję interesy zamawiającego prowadzę ożywioną dyskusję z analitykiem dostawcy oprogramowania o sposobach i technikach dokumentowania czy też zarządzania wymaganiami i przypadkami użycia. Nasze podejścia choć w wielu obszarach zbieżne to niestety w wielu bardzo różne. Po długich dyskusjach udało nam się uzyskać konsensus choć w momencie gdy pisze te słowa (posty piszę ze sporym wyprzedzeniem w stosunku do daty publikacji) nadal mam kilka tematów zaparkowanych.

Dlaczego dla mnie te ustalenia są ważne?

W wielu projektach zdarza się , że dokument wygenerowany z Enterprise Architect musi przeczytać i skomentować kilka czasem (znam skrajny przypadek)kilkanaście osób. Sekwencyjne wysyłanie dokumentów do opiniowania jest raczej mało sensowne a na pewno czasochłonne.  W takiej sytuacji staram się używać Google Docs. Zapisanie artefaktu w Google Docs ma dwie zalety. Plik jest od razu zapisany w chmurze (co jest modne ale też wygodne) i mogę wysłać do współpracowników  link z zaproszeniem do komentowania – i taką też opcją w uprawnieniach. Nie zapycham poczty plikami. Wszystkie komentarze są automatycznie widoczne dla wszystkich innych komentujących i nie problemu ze scaleniem tych treści.  Oczywiście nie ma róży bez kolcy…

MS Project jest jednym z najbardziej znanych narzędzi do budowy harmonogramów projektów. W swojej pracy wykorzystuję jednak inne narzędzie, które wspomaga mnie  w zarządzaniu projektem. Tym narzędziem jest OpenProj. OpenProj jest kompletną aplikacją przeznaczoną do zarządzania projektami. Użytkownik ma możliwość dodawania zadań, edytowania ich na wykresie Gantt'a, dodawania zasobów i wiele innych. Interfejs oraz pewne funkcje posiadają podobne działanie do…

Dużym problem przy projektowaniu jest porównanie i znalezienie zmian. Tego problemu chyba nie trzeba nikomu przedstawiać. Sam korzystam z wielu mechanizmów w tym z Baseline. Sama idea mechanizmu baseline nie jest zła, tylko, mówiąc delikatnie, trochę obciąża bazę danych. Problem jest także z porównaniem zapamiętanej wersji z obecną. By było mi łatwiej stosuję pomocnicze narzędzie, które opisałem tutaj: Tormigo i mechanizm Baseline. Enterprise Architect w wersji 9.2 zawiera w sobie także mechanizm porównania zmian na diagramach w oparciu o baseline. Jak to działa?

12
Close