Projekty

Linki

Polecam


MANEA – Mantis Bug Trucker i Enterprise Architect

poniedziałek 16 sie 2010

MANEA jest to dodatek (plugin) do MANTIS BUG TRUCKER, który pozwala na dwukierunkową synchronizację wybranych wpisów z systemu MANTIS BT z repozytorium wymagań znajdujących się w Enterprise Architect firmy Sparx.

MANEA cechy:

  • mapowanie, za pomocą Enterprise Architecta, wpisów i zgłoszeń na konkretne artefakty modelu aplikacji
  • prowadzenie w systemie MANTIS dyskusji nad wymaganiami zapisanymi w Enterprise Architect
  • umożliwienie szerokiemu gronu osób zgłaszania propozycji wymagań – tylko administrator wstawiając odpowiedni wskaźnik – tag EA-MANTIS może zezwolić na integracje wpisu z Enterprise Architectem
  • możliwość zarządzania zgłoszeniami o błędach w oparciu o model wykonany w języku uml
  • łatwość instalacji w systemie MANTIS gdyż MANEA to standardowy plugin,
  • wsparcie dla repozytoriów błędów i modeli gromadzonych za pomocą bazy danych mysql

Wersja demo jest do pobrania ze strony www.manea.info


Raportowanie zmian w modelu w Enterprise Architect

piątek 16 lip 2010

Zmiany w oprogramowaniu i modelach są nieuniknione. Poniżej kilka słów na temat jak je przedstawić w EA i jak je raportować.

Przyjąłem, że zmiany dotyczą zmian w istniejącym już oprogramowaniu.

Zmiana jest zgłoszona w dowolnej formie przyjętej w organizacji natomiast w Enterprise Architect jest reprezentowane jako wymaganie, zmiana lub defekt (problem)

clip_image002

Wszystkie wymagania i elementy, które mają znaleźć się w kolejnym wydaniu powinny dostać odpowiedni numer wersji, np.: 1.1

przeczytaj pozostałą część »


Wymagania a narzędzia CASE

sobota 15 maj 2010

Wybór narzędzia CASE wspomagającego proces akwizycji i zarządzania wymaganiami jest trudny. Poniżej zamieszczam link do zestawienia cech wybranych narzędzi.

Zestawienie narzędzi do zarządzania wymaganiami - wersja 1.0

Zestawienie to jest tłumaczeniem badań jakie zostały opublikowane przez The International Council on Systems Engineering (INCOSE). Na stronach tej organizacji można znaleźć oryginał z bogatszą listą produktów.


Złote reguły towarzyszące przypadkom użycia

wtorek 16 mar 2010

?Złote reguły? to nic innego jak wykaz punktów, które zazwyczaj kontroluję podczas tworzenia przypadków użycia. Gdy mam już narysowany przypadek użycia sprawdzam czy:

  • przypadek użycia zapewnia wartość aktorom,
  • krótki opis zwięźle opisuje cel przypadku użycia,
  • przypadek użycia jest kompletny i sensowny,
  • wydarzenie rozpoczynające przypadek użycia jest jasne,
  • sposób i czas zakończenia przypadku użycia jest jasny,
  • stosowana terminologia jest jasna, a istotne terminy zdefiniowane w słowniczku lub podobnym,
  • rozpoczęcie i zakończenie przepływu alternatywnego
    jest jasne a każdy przepływ alternatywny posiada jasne
    odniesienie do sposobu, w jaki się zaczyna i dokąd zawrócona jest kontrola po tym jak zostanie wykonany,
  • przypadek użycia jest możliwy do zweryfikowania,
  • wszystkie kroki są indywidualnie ponumerowane,
  • aby uprościć długie i złożone przepływy zdarzeń, wykorzystywane są podprzepływy w postaci dekompozycji aktywności

Powyższy dekalog sprawdzanych parametrów pozwala na utrzymywanie w repozytorium projektu w miarę sensownych przypadków użycia.


o wymaganiach

poniedziałek 11 sty 2010

W sieci pojawił się nowy blog o wymaganiach (http://owymaganiach.pl/). Cieszy mnie ta inicjatywa, Pana Jakuba Jurkiewicza – doktoranta na Politechnice Poznańskiej, gdyż w sieci jest mało zasobów na temat inżynierii oprogramowania a te zapowiadają się sensownie.    Z pierwszych wpisów polecam teksty o przypadkach użycia. Powodzenia :)


Alternatywna prezentacja wymagań

sobota 9 sty 2010

W Enterprise Architect jest dedykowany do gromadzenia wymagań element zwany ?Requirement?

image

Jest to bardzo komfortowa sytuacja, ale co zrobić gdy nie ma takiego elementu w danym narzędziu CASE?

przeczytaj pozostałą część »


Z nowym rokiem

sobota 2 sty 2010

Z nowym rokiem uzupełniłem kilka wpisów, które były niedokończone a które miały się ukazać w grudniu. Pierwsze dwa tygodnie były dość pracowite dla mnie.  Jedno z zadań z jakiego myślę, że wywiązałem należycie się to autorskie szkolenie zakresu gromadzenia i zarządzania wymaganiami w Enterprise Architect.  Dlaczego myślę, że wywiązałem się należycie. W testach z wiedzy przed i po szkoleniu widać progres u każdego z uczestników szkolenia. Ponadto w ankietach oceniających szkolenie otrzymałem dobre i bardzo dobre noty. Innym ciekawym przedsięwzięciem w jakim mogłem uczestniczyć to współpraca z polskim instytutem badawczym. Pomagałem im, i mam nadzieję, że w nowym roku także będę to robił,  w zakresie budowy architektury złożonego systemu (sprzęt + oprogramowanie) oraz zarządzaniem wymaganiami na ten system. Zadanie to jest tym bardziej ciekawe, że jest to jeden z ostatnich polskich instytutów z polską myślą inżynierską. To rzadkość  na polskim rynku, a dla mnie satysfakcja z pracy z rewelacyjnymi polskimi inżynierami, specjalistami w swojej dziedzinie, praktykami w każdym calu. W tym instytucie tworzą się na prawdę innowacyjne polskie produkty.

Przymiotnik polski powtórzyłem celowo kilka razy.


Wspólne słownictwo

środa 19 sie 2009

image W trakcie szkicowania procesów biznesowych należy zdefiniować wspólne słownictwo, przy użyciu najpopularniejszych terminów i wyrażeń w zakresie problemu. Następnie należy konsekwentnie wykorzystywać wspólne słownictwo we wszystkich tekstowych opisach biznesu. W ten sposób, utrzymują Państwo spójne opisy tekstowe i unika się nieporozumień wśród członków projektu dot. stosowania i znaczenia terminów. Słownictwo powinno mieć formę słownika.

Aby znaleźć wspólne terminy w zakresie problemu, należy uwzględnić terminy stosowane w trakcie rozmowy, o co chodzi w biznesie. Warto skupić się na terminach opisujących następujące koncepcje:

  • Obiekty biznesowe reprezentujące koncepcje stosowane w codziennej pracy organizacji. W wielu przypadkach, już istnieje wykaz tego rodzaju koncepcji.
  • Obiekty świata rzeczywistego, których istnienia przedsiębiorstwo musi być świadome. Te obiekty występują w naturalny sposób i obejmują takie rzeczy jak: samochód, psa, butelkę, samolot, pasażera, rezerwację, bądź fakturę.

Każdym termin jest na ogół opisywany jako rzeczownik wraz z definicją. Terminy powinny być podane w liczbie pojedynczej, "zamówienie" oraz "zadanie", a nie "zamówienia" czy "zadania".

I na koniec oczywiste i najważniejsze: wszystkie zainteresowane strony powinny porozumieć się co do zdefiniowania terminów.


Dobre praktyki inżynierii wymagań

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:

Podstawowe dobre praktyki inżynierii wymagań
Średniozaawansowane dobre praktyki inżynierii wymagań
Zaawansowane dobre praktyki inżynierii wymagań

 

Technorati Tagi:

Słownik w Enterprise Architect

piątek 19 cze 2009

Każdy inżynier oprogramowania dobrze wie jak ważnym dokumentem jest Słownik w trakcie procesu wytwórczego oprogramowania a szczególnie w jego pierwszych fazach. Bez zrozumienia pojęć czy skrótów, którymi posługuje się klient z na pewno nie rozwiążemy jego problemu.

Enterprise Architect (EA) udostępnia nam funkcjonalność związaną z budową Słownika (menu Project > Documentation > Glossary?). W okienku możesz definiować listę terminów używanych w projekcie i kojarzyć z nimi opisy ich znaczenia jak również generować prosty raport zwany Słownikiem.

Jednak użytkownik tworzący model w EA z reguły korzysta z podręcznego elementu Notes do opisu znaczenia definiowanych elementów modelu. Jest on zwykle widoczny w trakcie pracy w EA i kojarzony z każdym elementem modelu a więc poręczniejszy niż okienko Słownika.

Jak więc wygenerować raport odpowiadający Słownikowi z notatek modelu? Jak się okazuje nie jest to trudne w EA. Rozważmy przypadek, że chcemy wygenerować Słownik z notatek wszystkich Aktorów w postaci: nazwa aktora i jego opis. W tym celu:

przeczytaj pozostałą część »


Zarządzanie wymaganiami w Enterprise Architect – mapowanie wymagań na przypadki użycia

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ęść »


Skuteczne i wydajne narzędzie do zarządzania wymaganiami

poniedziałek 23 lut 2009

W zeszłym tygodniu na jednym ze spotkań dotyczącego projektu o dość sporej wartości dostałem pytanie: Dlaczego do większych projektów do zarządzania wymaganiami rekomenduję IBM Rational RequisitePro? Oponent argumentował, że to drogi produkt a wejście w niego ?spycha? w dość kosztowną platformę Rational. Pozornie miał rację. Otóż w przypadku małych firm i niewielkich projektów wystarczą narzędzia konkrecyjne takiej jak choćby plug-in do jednego z najbardziej popularnych narzędzi CASE Enterprise Architecta o nazwie RaQuest. Niestety wydajność i możliwości wspomnianego tandemu (EA i RaQuest) są dość ograniczone (co wiem z praktyki).

Osobiście lubię stosować RequistePro zwłaszcza przy większych projektach gdyż pozwala on na :

  • zbieranie wymagań w Word, szybką ich akwizycję w repozytorium opartym na bazie danych (wizardy, pełna integracja z Word),
  • możliwość pracy grupowej dzięki składowaniu wymagań w bazie danych (IBM DB2, Oracle, MS SQL Server),
  • nadawanie priorytetów i powiązań pomiędzy wymaganiami,
  • nadawanie atrybutów takich jak priorytet, status, stopień trudności, odpowiedzialność,
  • poprawienie wymagań w Word (nawet przez osoby, które nie mają zainstalowanego narzędzia), które wymusza  podczas synchronizacji wymagań (już na jednoste z dostępem do RequistePro) do obligatoryjnego wersjonowania zmian,
  • filtrowanie, sortowanie i porządkowanie wymagań,
  • pełną integrację z narzędziami do modelowania (np.: Rational Software Modeler, Rational Software Architect) bez konieczności przełączania się pomiędzy narzędziami,
  • szybkie i wydajne raportowanie (czasem z potrzebne jest narzędzie do raportowania: Rational SODA),
  • zarządzanie wymaganiami także za pomocą interfejsu WWW (łącznie z raportowaniem),
  • integrację z ClearQuest co pozwala na jeszcze bardzie skuteczne wersjonowanie wymagań (także tych które powinny znaleźć się w kolejnej wersji produktu) – co jest istotne z punktu widzenia kierowników projektu
  • integrację z narzędziami do testowania takimi jak Rational TestManager – co jest istotne z punktu widzenia testerów
  • i chyba jedno z ważniejszych: wsparcie techniczne i merytoryczne IBM lub jej partnerów ? co pozwala zaoszczędzić czas

Oczywiście narzędzie może nie jest tanie, ale daje tyle wartości dodanej i pomaga uniknąć tylu trudności, że wydane pieniądze zwracają się wielokrotnie. Zdaje się, że wyszła mi przesłodzona laurka. Na szczęście dla mnie to prawdziwe cechy aplikacji (sprawdzone osobiście w projektach). Jeśli ktoś chciałby się przekonać w praktyce ?na własne oczy? proszę o kontakt ? mogę zrobić prezentację możliwości narzędzia lub szkolenie.


Najczęściej czytane

Kategorie

  • agile
  • architektura korporacyjna
  • Enterprise Architect
  • literatura
  • metodyki
  • modelowanie biznesowe
  • o inżynierii oprogramowania
  • ogólne
  • SCRUM
  • StarUML
  • szkolenia
  • teksty
  • WMB
  • wydarzenia
  • zarządzanie wymaganiami
  • zwinne modelowanie
  • Słowa kluczowe

    agile agile modeling aktor biznesowy aplikacje webowe ASP.NET biznesowy przypadek użycia byt biznesowy diagram aktywności diagramy Enterprise Architect Extreme Programming IBM Rational Software Modeler inżynieria oprogramowania konsultacje metoda punktów przypadków użycia metodyki wytwarzania oprogramowania model analizy biznesowej model biznesowych przypadków użycia modelowanie modelowanie biznesowe modelowanie procesów biznesowych modelowanie systemów informatycznych narzędzia CASE pracownik biznesowy proces wytwórczy oprogramowania procesy biznesowe projektowanie systemów informatycznych przypadki użycia Rational Software Architect Rational Unified Process RUP scenariusze procesów biznesowych SCRUM Service Oriented Architecture SOA StarUML szacowanie oprogramowania szkolenie testowanie UML Unified Modeling Language wymagania na system XP zarządzanie wymaganiami zwinne modelowanie

    Archiwum