środa, 8 sierpnia 2012

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

Brak komentarzy:

Prześlij komentarz