Czym jest SSADM

1. Strukturalna metoda analizy i projektowania systemów (Structured Systems Analysis and Design Methodology - SSADM) jest standardową metodą przyjętą przez rząd Wielkiej Brytanii.

2. Metodyka dzieli pracę nad projektem na pojedyncze jednostki.

3. Metoda jest elastyczna i może być zastosowana do szerokiej klasy problemów.

Czym jest SSADM

Metodą organizacji pracy przy analizie istniejącego systemu informacyjnego w celu pomocy w projektowaniu i wytworzeniu docelowego systemu informatycznego, tj. systemu informacyjnego bazującego na komputerach.

Metoda dostarcza przewodnika osobom zajmującym się tworzeniem systemów. W szczególności pozwala na :

1. Określenie jakiej pomocy od systemu oczekują potencjalni użytkownicy w przyszłości

2. Zaprojektowanie żądanego systemu

SSADM nie zajmuje się bezpośrednio zarządzaniem projektem ani programowaniem ani też fizyczną konstrukcją systemów informatycznych.

SSADM składa się z działań i produktów.

Działania opisuje się w metodyce SSADM na dwa sposoby :

- kiedy coś ma być zrobione tzn. model strukturalny

- jak to coś ma być zrobione, czyli opis techniczny

Produkty są tym, co wykonuje działania i są wynikiem metodyki SSADM.

Interfejs z otoczeniem

Moduły

Fazy Kiedy

Kroki

Zadania

Techniki Jak

Produkty Co

rys. 1.1. Trzy aspekty metodyki SSADM

MODUŁ FAZA CYKL ŻYCIA

Planowanie strategiczne

Konstrukcja i testy

Wykonanie Produkcja

rys. 1.2. Pięć głównych modułów metodyki SSADM

Pięć modułów metodyki SSADM

1. Studium wykonalności (FS)

Ten moduł jest jedynie częścią większej pracy wykonywanej przy ocenie możliwości wykonania określonego projektu. Zawierają się w nim nie-SSADM'owskie: analiza kosztów/zysków, uwarunkowania socjalne i inne.

2. Analiza wymagań (RA)

Koncentruje się na opisie informacyjnych wymagań systemu, najlepiej jakościowych, w terminach zrozumiałych dla użytkownika. Są dwie fazy tego modułu. Pierwsza faza polega na opisie stanu zastanego z użyciem modelu danych i modelu przepływu danych. Druga faza (opcje biznesowe systemu) określa możliwe warianty „rozwiązań” znalezionych „problemów”. Na tej podstawie decydenci wybierają ostateczny wariant systemu, koszt i inne parametry systemu i projektu.

3. Specyfikacja wymagań

W jednej fazie tego modułu dokonuje się „przepisania” uzyskanych w poprzednich etapach opisów systemu (w powiązaniu z wybranymi opcjami dla biznesu). Używa się takich metod jak relacyjna analiza danych i modele encja/zdarzenie. Redefiniuje się i uszczegóławia model przepływu danych (DFM) i model logiczny danych (LDM). Praca koncentruje się wokół definicji funkcji (funkcje określa się teraz, ale dla potrzeb później tworzonych procesów). Efektem jest utworzenie możliwej do sprawdzenia specyfikacji systemu.

4. Specyfikacja systemu logicznego (LS)

Moduł ma dwie fazy. W jednej (faza 4) determinuje się i pozwala dokonać decydentom wyboru jednego z możliwych wariantu technicznego (zazwyczaj pod kątem spełniania wymagań i ekonomii kosztów). W fazie 5 określa się dialogi, aktualizację i dostęp do danych w nieproceduralnej formie (aby być niezależnym od metody implementacji).

5. Projekt fizyczny (PD)

Jest ostatnim modułem opisywanym przez metodykę SSADM (poza metodyką zostaje etap wdrażania i inne). Opracowaną logiczną specyfikację systemu w poprzednich modułach łączy z informacjami o docelowym hardwarze, softwarze i uwarunkowaniami organizacyjnymi. Rezultatem fazy 6 jest ogólny fizyczny projekt. Zakłada się, że dodatkową pomoc przy konstrukcji systemu zaoferują dostawcy sprzętu i oprogramowania. Praktyczna realizacja projektu fizycznego powinna wziąć pod uwagę możliwości oferowane przez aktualny software.

Trochę historii

1. przed 1980 r. - Pojawienie się metody LBMS (Learmontha i Burchetta)

2. ok. 1980 r.     - Sformułowanie własności pożądanej metody Projektowania Systemów Informatycznych przez CCTA:

- samo testująca

- używająca znanych i przetestowanych metod

- łatwa do dopasowania

- łatwa do nauczenia się

3. styczeń 1981 - akceptacja metody przez CCTA

4. styczeń 1983 - przyjęcie metody za oficjalną przez rząd Wielkiej Brytanii

5. jesień    1987 - współpraca CCTA z British Standards Institute w celu opracowania standardu metodyki SSADM

6.              1989 - włączenie do metodyki narzędzi CASE

7. aktualnie        - oficjalna metodyka Irlandii, Malty, Izraela.

Metodyki współpracujące

9 Project Procedures

1. Zarządzanie projektem jest głównym „interfejsem” z menadżmentem i zwykle następuje po podejściu PRINCE

2. Gwarancja jakości jest odpowiedzialna za upewnienie się, że produkty SSADM są właściwie ukończone

3. Analiza ryzyka może być dokonana za pomocą metody CRAMM używanej przez CCTA (CCTA Riska Analysis and Menagement Method)

4. Planowanie CAPACITY zawiera metody identyfikacji wąskich gardeł i sprawdzania poziomu wymaganej obsługi

5. Testowanie nie jest bezpośrednio zawarte w metodyce SSADM ale pośrednio w każdym produkcie metodyki

6. Za organizację szkolenia odpowiadają mengerowie

7. Implementacja (albo wdrożenie) związana jest z przygotowaniem i przystosowaniem się do

nowego systemu

Część pierwsza wprowadza SSADM opisując jej strukturę i jej związek z innymi działaniami w czasie organizacji i pracy nad projektem.

Część druga "Framework" opisuje szczegółowo standardowe "frameworki" SSADM. Dzieli się projektowanie na: moduły, fazy, kroki i zadania (modules, stage, steps, tasks). Opisuje się także produkty, które są używane, zmieniane lub tworzone przez zadanie. Rozdział kończy się przeglądem projektowania kluczowych aspektów systemów informacyjnych poprzez prześledzenie ich drogi poprzez SSADM.

Cześć trzecia "Techniki" opisuje techniki definiowane przez SSADM. Tam gdzie to jest możliwe techniki wprowadza się w pojęciach ogólnych. Pozwala to na użycie książki jako podręcznika nie tylko dla specjalistów SSADM.

Część czwarta "Aplikacje" porusza wiele aktywności, jakie muszą być p0djęte zanim organizacja potrafi zaprojektować system. W tym zawiera się SSADM'owski "projekt procedur" który prowadzi do zdefiniowania organizacyjnego interfejsu dla projektu.

Część piąta spogląda na szerszy kontekst w którym projekt ma miejsce. Wybrano kilka kluczowych tematów, które oddziaływają na projekt systemu informacyjnego. W rozdziale porusza się zarówno problemy konkretne jak i abstrakcyjne. Szeroka gama nie-SSADM'owskiego podejścia zostało opisane włączając w to metody zarządzania polityką projektu, opis problemów i wymagań, projektowanie systemu biurowego (z pomocą CCTA COMAPACT) i planowanie strategiczne. Ten rozdział może być przydatny dla zaawansowanych kursów, które chcą mieć szersze spojrzenie na swoją pracę (craft).

Dokument

Inicjujący

Procedura Projekt 010

Projektowa Przygotowanie do

studium wykonalności

Diagram kontekstowy

Poziom 1 DFD

Przegląd LDS

Katalog wymagań

020 Procedura

Definiowanie problemu projektowa

Ustalenia definiujące Raport

Opis aktualnej sytuacji 040

Opis docelowej sytuacji Redakcja raportu

Katalog wymagań o wykonalności

Katalog użytkownika

Plan

akcji Plan wprowadzenia

opcji wykonalności

030

Wybór opcji

wykonalności

rys. 2.1 Wykonalność - faza 0

130

Procedura Badanie aktualnego

Projektowa przetwarzania

Dokument

Inicjujący

Diagram kontekstowy Diagram kontekstowy Katalog

Poziom 1 DFD Aktualny model fizyczny użytkownika Opis aktualnych

usług

Katalog

Studium Raport Katalog Katalog wymagań Faza 2

wykonalności o wykonal- 110 wymagań 120 Badanie wymagań 150 Spojrzenie 160 Zebranie Katalog Opcje

ności Określenie ram i definiowanie na aktualne usługi rezultatów badania użytk. Systemu

analizy wymagań

Przegląd Aktualne środowisko LDS/Encje

Logical Data Stores Model logiczny danych Model logiczny przepływu danych

Model logiczny danych

Katalog wymagań

140 Diagram kontekstowy

Badanie danych

aktualnych

Procedura

projektowa

rys. 2.7. Badanie aktualnego środowiska - faza 1

Wymagany DFM

Role użytkown.

310 330 Definicja funkcji 370

Definicja wymaganego Tworzenie funkcji Zatwierdzenie syst.

przetwarzania systemowych ustaleń

Definicja funkcji

Wymagany LDM

Definicja funkcji Wymagany LDM

360

Struktura Tworzenie specyfikacji

We/Wy przetwarzania (procesów)

Role użytkowników Diagram zdarzeń Faza 4

Macierz funkcji Ścieżki dostępu ELH

Faza 1

Badanie Specyfikacja

aktualnego Wymagany 380 wymagań

środowiska systemowy Zebranie specyfikacji

Opis aktualnych usług LDN wymagań

i wybranej opcji BSO

a

Faza 5

Faza 2

Wybór

opcji systemu 340

BSO Rozszerzony wymagany

Model Danych

.

Menu

Wymagany i struktura komend

systemowy

LDM

320

Tworzenie

Procedura wymaganego LDM 350 Raport o prototypach Projekt

projektowa modelu danych Prototypy interfejsów procedur

We/Wy

rys. 2.7. Definicja wymagań - faza 3

Procedura

Projektowa Poradnik instalatora

Dokument

Inicjujący

Projekt

Opis środowiska techn.

Faza 2 Wybrana BSO 410 TSO 420 Poradnik aplikanta Faza5

Definiowanie opcji Wybór opcji

technicznych systemu technicznych

Wybrana opcja TSO

Katalog wymagań

Procedura

Faza 3 Projektowa

rys. 2.28 Techniczne opcje systemu - faza 4

Poziom pomocy dialogu

510 Struktura dialogu

Faza 4 Definicja dialogów Tablice kontroli

użytkownika dialogu

Menu i struktura

komend

Poradnik stylu

aplikacji

i specyfikacja

wymagań 520 ELH

Definicja procesu Opis encji Faza 6

Faza 3 - aktualizacji Modele procesów

aktualizacji

Opis encji

ELH

530

Definicja procesu Projekt

szukania logiczny

Modele procesów

wyszukiwania

540

Projektowanie

logiczne

rys. 2.31 Projektowanie logiczne - faza 5

---