• kreowanie i utrzymywanie przyszłej wspólnej wizji składającej się z biznesu i technologii informatycznej, współosiowość biznesu i technologii informatycznej,
• utworzenie całościowego – od początku do końca – procesu architektury przedsiębiorstwa, który odpowiednio odzwierciedla strategię biznesu przedsiębiorstwa,
• zbudowanie zwrotności poprzez uproszczenie struktury, dokonanie odpowiednich przemian,
• rozwinięcie pro-aktywnej organizacji, zdolnej do spełnienia wymagań konsumenta, wyprzedzenia konkurencji, i wprowadzania innowacji,
• zredukowanie ryzyka i przygotowanie przedsiębiorstwa do nagłych nieplanowanych zmian,
• unikanie pułapek funkcjonowania jednostek informatycznych biznesu działających sprzecznie ze sobą,
• ustanowienie programu progresywnego udoskonalania technologii,
• odblokowanie siły informacji, unifikowanie informacji, które zawierają inicjatywy strukturalne takie jak zarządzanie relacjami konsumenta i biznesu elektronicznego,
• eliminacja duplikujących się i zachodzących na siebie technologii, zmniejszanie kosztów wsparcia,
• skrócenie czasu wprowadzania rozwiązań oraz kosztów rozwoju poprzez maksymalizację wykorzystania technologii, informacji i aplikacji biznesowych.

Punkty ważne dla mnie zaznaczyłem inną czcionką.

Posty o podobnej tematyce:

1. Architektura korporacyjna – zalety
2. Architektura korporacyjna
3. Architektura modelu procesów biznesowych

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

Posty o podobnej tematyce:

1. Mały sekret reverse i forward engineering w Enterprise Architect
2. Pisanie kodu w Enterprise Architect
3. Zarządzanie wymaganiami w Enterprise Architect – mapowanie wymagań na przypadki użycia

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

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

Posty o podobnej tematyce:

1. Zwinne modelowanie w Visual Studio 2010
2. Projektowanie systemów informatycznych w ujęciu Agile
3. Agile w krzywym zwierciadle

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). 

Posty o podobnej tematyce:

1. Integracja środowiska Rational z Visual Studio 2008
2. MSF for Agile Software Development v5.0
3. Zwinne modelowanie w SCRUM

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

Rozwiązanie 1 – wersja

Celem odfiltrowania elementów, których dotyczy zmiana należy na raporcie np.: szablon maintaince nałożyć filtr dotyczący numeru wersji

Raport zawierać będzie tylko elementy ze wskazaną wersją.

Rozwiązanie 2 – stereotyp

Każdy z elementów otrzymuje stereotyp z numerem wersji planowanego wydania

Do każdego z elementów „podpinam” za pomocą realizacji wymaganie, które wprowadza zmianę

A następnie robie raport tak jak poprzednio z tym, że filtr ustawiony jest stereotyp

Wynik raportu z listą wymagań

Posty o podobnej tematyce:

1. Śledzenie zmian w Enterprise Architect
2. Raport z zawartości partycji w Enterprise Architect
3. Już jest: Enterprise Architect wersja 8.0

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

Po wybraniu przycisku New Baseline otrzymuję zarchiwizowany pakiet.

Następnie dna potrzeby tego wpisu zmodyfikowałem diagram dodając aktywność

Po naciśnięciu przycisku Show Differences (otwarta zakładka Manage Baselines) pojawia się lista elementów wraz z porównaniem zmian (podświetlone na zielono).

Zachęcam do samodzielnego testowania tej funkcjonalności.

Posty o podobnej tematyce:

1. Raportowanie zmian w modelu w Enterprise Architect
2. Już jest: Enterprise Architect wersja 8.0
3. Mały sekret reverse i forward engineering w Enterprise Architect

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

Posty o podobnej tematyce:

1. Już jest: Enterprise Architect wersja 8.0
2. Enterprise Architect w wersji 7.5
3. Szacowanie projektu w Enterprise Architect

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ść.

Posty o podobnej tematyce:

1. Wielkość i długość iteracji
2. Agile a tworzenie przypadków użycia
3. MSF for Agile Software Development v5.0

EA informuje gdzie zapisany zostanie przypadek testowy

W samym przypadku testowym nie ma treści dot. testów. Natomiast w widoku testu View->Testing

Odnajdujemy wszystkie scenariusze elegancko pogrupowane w scenariusze testowe. Dla mnie REWELACJA, gdyż teraz będę mógł “pisać” testy odrobinę szybciej.

Posty o podobnej tematyce:

1. Automatyczne generowanie diagramów aktywności w Enterprise Architect
2. Zarządzanie wymaganiami w Enterprise Architect – mapowanie wymagań na przypadki użycia
3. Szacowanie projektu w Enterprise Architect

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

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

2. Następnie wstawiamy filtr na elementy, które chcemy odfiltrować  tzn. zaznaczam wszystko poza Activity, ActivitiPartition, Object:

3. Generuję raport, którego wynikiem jest:

To najszybszy sposób by z całej listy elementów otrzymać dość zgrabną zawartość do dalszej obróbki.

Należy zauważyć iż partycja może być obiektem i wtedy na raporcie zamiast ActivityPartition pojawia się słowo Instance

Lepszy wariant to na bazie tego samego szablonu:

1. Na diagramie klikamy na element – partycję z której chcemy uzyskać raport

2. Następnie klikamy :Element ->Rich Text Format (RTF) Report

3. I wykonujemy raport na tym samym template co wcześniej

4. Wynik raportu:

Oczywiście ten rodzaj raportu także można odpowiednio odfiltrować z niechcianych elementów.

Posty o podobnej tematyce:

1. Słownik w Enterprise Architect
2. Raportowanie zmian w modelu w Enterprise Architect
3. Szacowanie projektu w Enterprise Architect cz. 2