Metodologia CASE
Przyczyny użycia narzędzi CASE
• Główną przesłanką użycia narzędzi CASE jest zwiększenie
produktywności i jakości produkowanych systemów. Podnoszenie produktywności i jakości projektowanych systemów z
wykorzystaniem narzędzia CASE odbywa się poprzez:
• Wspomaganie standardowych metod i działań projektowych – proces projektowania jest bardziej zintegrowany.
• Ulepszenie komunikacji między użytkownikami a specjalistami
(projektantami) – duże zespoły i projekty są efektywnie koordynowane.
• Organizowanie i korelowanie komponentów projektu oraz zapewnienie szybkiego do nich dostępu poprzez bazę danych projektowych.
• Automatyzowanie nudnych i błędotwórczych kroków analizy, projektowania i programowania.
• Automatyzowanie testowania i kontroli.
• Integrowanie środowiska wytwarzania systemu ze środowiskiem
eksploatacji.
Przyczyny stosowania CASE
• Większość organizacji stosuje narzędzia CASE aby:
– Zwiększyć jakość projektowanych systemów.
– Zwiększyć szybkość projektowania i konstrukcji systemów.
– Ułatwić i ulepszyć proces testowania dzięki automatycznemu sprawdzaniu.
– Zwiększyć integrację działań projektowych przez stosowanie jednolitego podejścia metodologicznego.
– Zwiększyć jakość i kompletność dokumentacji.
– Pomóc w standaryzacji procesu projektowania.
– Ulepszyć zarządzanie projektami.
– Uprościć utrzymywanie (pielęgnację) oprogramowania.
– Ułatwić i promować ponowne użycie komponentów systemu i dokumentacji.
– Zwiększyć możliwość zastosowania oprogramowania w różnych
branżach.
Bariery stosowania CASE
• Wysoki koszt narzędzi CASE.
• Wysokie koszty szkolenia pracowników.
• Brak wiary ze strony pracowników (organizacji) w
możliwość szybkiego (i w ramach istniejącego budżetu) wdrożenia wysoce specjalistycznej technologii.
• Postrzeganie CASE jako zagrożenia dla bezpieczeństwa pracy.
• Brak zaufania do narzędzi CASE (przekonanie o wyższości własnych umiejętności).
• Brak standardów metodologicznych wewnątrz
organizacji.
Uwarunkowania rozwoju CASE
• Wcześniej czas powstawania systemów był dłuższy; dominowała metoda kaskadowego prowadzenia projektów, w wyniku czego dopiero po kilku miesiącach analizy definiowano wymagania
dotyczące projektu. Ten system nie ułatwiał wprowadzania zmian w trakcie trwania kolejnych etapów, lecz wymagał kolejnych iteracji.
Systemy wykonywane były w jednej wybranej na początku
technologii, co wymagało dokonania, na wstępie, wyboru języka programowania, środowiska systemowego oraz bazy danych z którą system miał działać.
• Dostawca systemu nabywał przeważnie całe środowisko tworzenia systemu u jednego dostawcy, co dawało większe szanse na
powodzenie projektu oraz bezproblemową współpracę narzędzi.
Uwarunkowania rozwoju CASE
• Obecnie systemy wykonywane są w kilku technologiach.
Zdarza się często, że część aplikacji działa jako gruby klient, inna stworzona jest w technologii J2EE, kolejne w technologii .Net, całość zaś współpracuje z wieloma
motorami baz danych.
• Sytuacja ta uwarunkowana jest koniecznością integracji tworzonych systemów z już istniejącą infrastrukturą
informatyczną. W takich przypadkach wymaga się od
narzędzi typu CASE znacznie więcej. Ponadto czas
realizacji systemów uległ znacznemu skróceniu, co
wynika z pojawienia się języka Java i nowych metod
programowania typu XP(Extreme Programming).
CASE - oczekiwania
• Generowanie kodu
• Reverse engineering’u (rewersowania, czyli odtwarzania elementów projektowych na
podstawie istniejącej aplikacji lub bazy danych)
• Wsparcia dla zmiany modelu na różnych poziomach abstrakcji (od analizy do kodu)
• Sprawdzania poprawności modeli
• Synchronizacji modeli z tworzonym kodem
• Wsparcia dla różnych języków programowania, motorów baz danych
• Generowania dokumentacji
Podstawowe ograniczenia stosowania CASE
• Większość współczesnych metodologii zakłada stosowanie technologii CASE w pełnym cyklu życia systemu, we wszystkich możliwych aspektach. Jednak pełne metodyczne wykorzystanie wspomagania komputerowego jest warunkowane
wieloma czynnikami. Wśród podstawowych ograniczeń kompleksowego stosowania narzędzi CASE można wyróżnić:
– Ograniczenia metodologiczne wynikające ze specyfiki procesów projektowania, w których zawsze występują procesy twórcze mało podatne na automatyzację, wspomaganie
komputerowe.
– Ograniczenia ekonomiczne sprowadzające się do tego, że nakłady na wspomaganie komputerowe (zakup sprzętu i oprogramowania, nakłady na szkolenia w zakresie
projektowania wspomaganego) powinny się mieścić w wielkości uzyskiwanych efektów.
– Ograniczenia sprzętowo-programowe polegające na tym, że systemy wspomagania wymagają dużych zasobów komputera, różnorodnych urządzeń zewnętrznych, języków komunikowania się z komputerem, odpowiedniego, otwartego oprogramowania (aspekt ten stopniowo traci na znaczeniu w dobie coraz tańszych systemów mikrokomputerowych, nowoczesnych metod obiektowych programowania czy graficznego interfejsu użytkownika).
– Ograniczenia socjologiczno-psychologiczne związane z trudnościami w przyswojeniu dużych zasobów wiedzy i umiejętności z zakresu analizy i projektowania, stosowaniu zasad metodycznego postępowania, konsekwencji w modelowaniu.
