o modelowaniu procesów i systemów 

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

Kilka dni temu w tekście: Zwinne modelowanie w Visual Studio 2010 pisałem o możliwości modelowanie za pomocą UML w VS 2010. Teraz czas na drugą z mojego punktu widzenia ważna zmianę. Otóż w MSF for Agile Software Development v5.0 jaki towarzyszy VS 2010 uwzględniono zwinne modele a proces wytwórczy kodu oparto o SCRUM. Więcej informacji pod adresem:

http://msdn.microsoft.com/en-us/library/dd380647.aspx

Szczególnie polecam rozdział 4.4 Use Models in Agile Development.

Jest rewolucja. I to nie mała. Otóż firma Microsoft w ramach Visual Studio z premedytacją omijała aspekt wizualnego projektowania sytemu przy użyciu UML. Aż do teraz.

W nowej wersji VS 2010 jest VS2010 Visualization and Modeling Feature Pack (http://msdn.microsoft.com/en-gb/vstudio/ff655021.aspx), dzięki któremu można wytwarzać modele na różnym poziomie abstrakcji i w konsekwencji synchronizować je z kodem aplikacji.

Przełom jest tym większy, że Microsoft proponuje tylko te techniki modelowania, które są uważane za składniki zwinnego modelowania (ang. Agile Modeling). 

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)

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

przeczytaj pozostałą część »

W przypadku gdy modyfikujemy model możemy zamrozić jego wersję. Opcja ta  w Enterprise Architect nazywa się Baseline. 

Jak ona działa? Otóż przykładowo w pakiecie diagram aktywności mam przykładowy diagram.

Następnie zapamiętuję wersję poprzez wybranie w menu kontekstowym: Package Control ->Manage BaseLines

przeczytaj pozostałą część »

W Enterprise Architect gdy chcemy zmieć status lub wersję wszystkich elementów zawartych w danym pakiecie to wystarczy wybrać w menu kontekstowym wybrać Package Control i na samym dole Update Package Status…

Następnie należy określić parametry zmiany i sprawa jest zakończona.

Iteracyjny model wytwarzania oprogramowania by był bardziej skuteczny wymaga kilku zabiegów. Chodzi oto by w ujęciu agile być rozważnym i skutecznym. Stosuję je podczas zwinnego modelowania. Oto kilka z nich:

1. Krócej znaczy lepiej. Iteracja nie powinna być dłuższa niż 4 tygodnie, w przeciwnym wypadku możesz wpaść w styl tworzenia oprogramowania mini-waterfall. Osobiście preferuję jedno lub dwutygodniowe iteracje. Dzięki temu tempo tworzenia oprogramowania jest stałe, jako że regularne dostarczasz nowe funkcjonalności.
2. Zacznij od niekomfortowego okresu czasu. Kiedy zmieniasz tradycyjną organizację na ewolucyjne (iteracyjne i przyrostowe) podejście do tworzenia oprogramowania spróbuj określić okres czasu, który będzie odpowiedni (np. 8 tygodni) i odejmij tydzień lub dwa (np. zacznij od 6-tygodniowej iteracji) aby zmusić ich do zmniejszenia biurokracji. Zrób kilka takich iteracji, a następnie skracaj długość iteracji dopóki nie dojdziesz do sensownego okresu czasu (np. mniej niż 4 tygodnie).
3. Zignoruj kalendarz. Jeśli Twoja iteracja została zaplanowana na tydzień, zrób ją od środy do wtorku. Iteracje trwające od poniedziałku do piątku zazwyczaj cierpią przez to, że w piątek skupienie i energia dramatycznie zmniejszają się, ponieważ jest to koniec iteracji i koniec tygodnia. Ten zbieg okoliczności zmniejsza produktywność.
4. Stwórz coś użytecznego. Zasadniczo iteracja powinna być na tyle długa, abyś był w stanie zrobić coś pożytecznego w jej trakcie. Niektóre zespoły robią jednodniowe iteracje.
5. Przeprowadź tyle iteracji, ile potrzebujesz. Wymagania zmieniają się, co oznacza, że czas potrzebny na wdrożenie systemu też musi się zmienić, aby to odzwierciedlić.
6. Cały czas możesz mieć stałą datę ukończenia oprogramowania. Jeśli potrzebujesz mieć stałą datę ukończenia oprogramowania, to po prostu ustal tą datę i do tego czasu ukończ tworzenie oprogramowania. Aż do czasu, w którym musisz oddać oprogramowanie, prowadź iteracje dotyczące tworzenia oprogramowania. Jeśli stale wdrażasz wymagania o najwyższym priorytecie,  a wtedy to, co do dostarczysz, będzie miało najwyższą możliwą wartość.

Kilka dni temu pisałem (w tekście: Automatyczne generowanie diagramów aktywności w Enterprise Architect) o wsparciu dla półautomatycznego tworzenia diagramów aktywności. Teraz dodam iż na podstawie tych samych scenariuszy można utworzyć przypadki testowe

przeczytaj pozostałą część »

Gdy zachodzi potrzeba zrobienia raportu zawierającego listę elementów znajdujących się wewnątrz partycji, tak jak to ma miejsce na poniższym rysunku, nie można bazować na gotowych rozwiązaniach gdyż takich w EA nie ma.

Budowa raportu to kilka kroków. Przedstawiam je poniżej.

1. Należy zbudować raport (zakładka template w raportach EA) o zawartości:

przeczytaj pozostałą część »

Enterprise Architect w wersji 8 ma świetną funkcję – automat do budowy diagramów aktywności

  Z premedytacją pisze automat gdyż wczytuje on tekst ze schowka systemowego dzieląc wklejany tekst na kroki na podstawie zdań lub znaków końca linii. REWELACJA.

przeczytaj pozostałą część »

Jedna z praktyk zwinnego modelowania to Zastosowanie Standardów Modelowania. Podstawową jej ideą jest to, że programiści są bardziej efektywni, jeśli pracują według powszechnego zestawu standardów i wskazówek, nawet, jeśli te wskazówki nie są doskonałe. To tak jakby rozmawiać w tym samym języku – łatwiej jest zrozumieć i utrzymać modele stworzone na podstawie skutecznych wskazówek i posiadające powszechnie stosowane opisy. Modele zbudowane według tych samych reguł poprawiają komunikację wewnętrzną- w zespole i zewnętrzną – z partnerami i klientami, przez co redukują możliwość wystąpienia kosztownych nieporozumień. Wskazówki dotyczące modelowania zaoszczędzają także czas poprzez ograniczanie wyborów stylistycznych, pozwalając skupić się na tworzeniu oprogramowania. Zestaw takich wskazówek opublikował swego czasu na swoich stronach internetowych Scott Ambler. Oto one:

1. Unikaj przecinających się linii. Dwie linie przecinające się na diagramie mogą zostać źle odczytane. Jeśli nie jesteś w stanie uniknąć przecięcia się linii, narysuj jedną z nich tak, aby „przeskakiwała nad” drugą w taki sposób, żeby różnica między nimi była wyraźnie widoczna.

2. Unikaj ukośnych lub zakrzywionych linii. Proste linie, narysowane poziomo lub pionowo, jest łatwiej śledzić wizualnie. Umieszczenie baniek na diagramie w taki sposób, jak gdyby ich centrum znajdowało się w punkcie siatki, wbudowana funkcja wielu narzędzi do modelowania, sprawia, że łatwiej jest połączyć bańki jedynie za pomocą poziomych i pionowych linii.

przeczytaj pozostałą część »

Dziś okazało się, że mój blog odnotował awarię. Autoaktualizacja jednej z wtyczek spowodowała iż stał się on nieczytelny. Teraz już wszystko wróciło do normy. Przepraszam za dyskomfort.