Cykl życia elementu

Inżynieria oprogramowania traktuje oprogramowanie jako produkt, który ma spełniać określone potrzeby głównie w aspektach technicznych i ekonomicznych. Definiuje w tym kontekście pojęcie cyklu życia oprogramowania oraz skupia się na narzędziach wspierających proces wytwarzania i utrzymania oprogramowania we wszystkich fazach życia produktu.





Podstawowe fazy cyklu życia, które przewijają się w różnych modelach cyklu życia to:

• Analiza (bądź specyfikacja produktu) - określenie i ustalenie wymagań,
• Projektowanie - ustalenie ogólnej architektury systemu,
• Implementacja - realizacja ustalonej architektury, czyli implementacja elementów składowych i ich połączenie,
• Integracja (bądź testowanie) - zintegrowanie poszczególnych elementów składowych w jeden systemu oraz testowanie całości rozwiązania,
• Wdrożenie - uruchomienie produkcyjne systemu,
• Utrzymanie systemu - usuwanie błędów produkcyjnych oraz rozwój systemu.

Enterprise Architect jest jednym z takich narzędzi wspierających. Element w EA posiada również zestaw atrybutów, który służy do określenia momentu w życia produktu. Są to:

• wersja (patrz: Wersjonowanie elementów),
• faza,
• status (patrz: Własny zestaw statusów).

Ponadto dużym ułatwieniem w zarządzaniu informacjami o cyklu życiu jest możliwość grupowej aktualizacji informacji, patrz: Cykl życia elementów - grupowa aktualizacja.
Zatem wskazane jest, aby ogólnie przyjęte zasady w stosowanych metodykach wytwarzania oprogramowania związane z cyklem życia produktu zastosować również w Enterprise Architect, który wspiera wytwarzanie oprogramowania. Sparx, producent Enterprise Architect nie narzuca jednak w tej kwestii żadnych reguł i daje swobodę użytkownikom. Ja osobiście określiłbym to następującym oksymoronem: "zaleta granicząca z wadą". Swoboda w definiowaniu reguł dotyczących wersjonowaniu skutkuje brakiem reguł w projekcie.
Zazwyczaj natłok zadań projektowych i napięte terminy skutkują tym, że wytworzony model jest najlepszy, jaki udało się stworzyć w ograniczonym czasie - czyli innymi słowy - daleki od doskonałości.

W tym celu zasadne wydaje się wprowadzenie projektowych zasad wersjonowania. Nie sposób sformułować uniwersalnych zasad w tej kwestii, gdyż każdy projekt jest określany jako specyficzny i posiada swoiste potrzeby i ograniczenia. W tym miejscu możliwe jest tylko wymienienie określonych przesłanek, które należy rozważyć już na etapie startu projektu. Są to:

• wyszukiwanie określonych elementów w modelu w zależności od ich wersji, etapu projektu i statusu,
• filtrowanie zawartości generowanej dokumentacji w zależności od wersji, etapu projektu i statusu,
• zakres danych niezbędny do wypełnienia wymagań dotyczących dokumentacji,
• raportowanie zmian w modelu w perspektywie czasowej (w przedziale czasu)  lub projektowej (w ramach określonej modyfikacji),
• zastosowanie mechanizmu Diagram Filters, np. do zobrazowania różnic pomiędzy stanem bazowym (AS-IS) oraz stanem docelowym (TO-BE),
• utrzymywanie i rozwój modelu przedsięwzięcia w dłuższej perspektywie czasu,
• unifikacja zasad wersjonowania produktów i artefaktów tworzonych bez użycia Enterprise Architecta, 
• potrzeba przesyłania całego modelu lub jego części pomiędzy różnymi osobami, które mogą nanosić zmiany w modelu, w sytuacji, gdy nie jest wykorzystywane współdzielone repozytorium,
• potrzeba wykorzystania mechanizmów typu Workflow do implementacji zasad projektowych,
• organizacja zawartości modelu w hierarchii pakietów,
• ograniczony czas na opracowanie modelu,
• brak możliwości wpływania na zakres wprowadzanych modeli przez członków zespołu pochodzących z innych organizacji.