Model Systemu Do Serwisowania Laptpów

Model systemu w języku UML jest odpowiednikiem modeli wykonanych w skali i zarazem blueprintów w budownictwie. Każdy model systemu jest podzielony na perspektywy, a w obrębie każdej perspektywy wyróżniamy poziomy szczegółowości. Taki model powinien być utrzymany w stanie aktualnym przez cały projekt. Wszystkie zmiany nanoszone są najpierw na model, a wszystkie zależności są od razu widoczne na modelu. Zmniejsza się w ten sposób prawdopodobieństwo wprowadzenia niekontrolowanych zmian, które powodują kłopoty z działaniem na pierwszy rzut oka zupełnie przypadkowych komponentów systemu.

Zarządzanie zmianami. Zmienność rzeczywistości jest jednym z najbardziej oczywistych jej właściwości. Zatem nigdy nie ma gwarancji, że za tydzień, miesiąc czy rok coś się nie zmieni, że klient nie zmieni swoich wymagań, że programista nie zoptymalizuje działania modułu lub architekt nie wprowadzi usprawnień na poziomie architektury systemu. Wszystkie zmiany powinny być pieczołowicie naniesione i opisane. Powinna być możliwość cofnięcia się do dowolnej wersji dowolnego artefaktu.

Wprowadzenie praktyki zarządzania zmianami w Zaltronik laptopy skutkuje wprowadzeniem tabeli zmian w każdym dokumencie projektowym, podłączeniem do systemu wersjonowania nie tylko kodu, ale również diagramów, dokumentów i dokumentacji. Wpływa to również na wybór narzędzi wspomagających modelowanie i dokumentację. Owszem, jest możliwość wpisywania opisu zmian tylko w tabeli zmian w dokumentach, ale utrzymywanie wszystkich wersji dokumentów wraz ze wszystkimi wersjami poprawek literówek jest bardzo czasochłonne i niewydajne. Oznacza to, że najlepszym rozwiązaniem co do technologii prowadzenia dokumentacji, może być jedna z technologii, oparta o tekstowe formaty plików.

Najlepiej jednak trzymać wszystkie diagramy, dokumenty i dokumentacje w jednym narzędziu. Wtedy zmiany, wprowadzone w jednym miejscu (np. diagramie), zostaną również zaktualizowane we wszystkich dokumentach pokrewnych oraz we wszystkich perspektywach zależnych. Jest to zdecydowanie lepsze rozwiązanie. Wadą jest to, że jest to typowa kompetencja narzędzia CASE. Narzędzia CASE z reguły są względnie drogie. Natomiast niosą za sobą dodatkowe korzyści. Z reguły narzędzia CASE potrafią również wygenerować kod, przynajmniej w postaci szkieletu klas, wygenerować scenariusze testowe lub testy jednostkowe. Oznacza to znaczne przyspieszenie i automatyzację prac projektowych. Tak więc koszta te bez problemu zwracają się po pierwszym większym projekcie.

Iteracyjne wytwarzanie oprogramowania. Jedną z niezawodnych rad, co do sposobu wytwarzania oprogramowania, z pewnością jest rada typu iterować, iterować i jeszcze raz iterować. Radę tę twórcy RUP wzięli sobie do serca. Co więcej, nie jestem pewien, czy nie są przypadkiem autorami tej rady. Iteracyjne podejście przejawia się w RUP na każdym poziomie: fazy są podzielone na iteracje, projekt jest podzielony na cykle, powstają rozwojowe wersje dokumentów, system powstaje iteracyjnie. Wszystko w RUP powstaje w sposób przyrostowy. Niczym kula śnieżna kolejne wersje artefaktów i systemu rozpędzają się, dążąc coraz bardziej do celu.