Wykład
4
Dlatego metodologia jego projektowania musi być jasna, konsekwentna i efektywna
Proces projektowania systemu
informacyjnego
Model kaskadowy jest
czytelny, przejrzysty, ale w istocie niepraktyczny.
Do zmiany sposobu myślenia o projektowaniu systemów informacyjnych zmusił informatyków kryzys oprogramowania.
Kryzys oprogramowania - symptomy (1)
- (IEEE Software Development,
Aug 94, p.65)
Utrzymanie 10 mld. linii istniejących programów kosztuje 70 mld. $ rocznie
- (PC Week, 16 Jan 95, p.68)
31% nowych projektów jest anulowane przed zakończeniem; koszt 81 mld. $
- Failed technology projects in Investor’s Business Daily,
31% projektów jest anulowane jeszcze w trakcie konstrukcji
53% projektów jest kończone z przekroczeniem zaplanowanego czasu, budżetu
i z ograniczeniem planowanego zbioru funkcji systemu
Zaledwie 16% projektów jest kończone w zaplanowanym czasie, bez przekroczenia budżetu i okrajania funkcjonalności
Kryzys oprogramowania - symptomy (2)
- (Ed Yourdon’s Guerilla
Programmer, Jul 95)
Średnia wydajność wykonawców oprogramowania spadła o 13% w ciągu dwóch lat;
stosunek najlepszej wydajności do najgorszej od 1990 r. rozszerzył się
od 4:1 do 600:1.
a
Uzależnienie
organizacji od systemów komputerowych i
przyjętych technologii przetwarzania informacji, które nie są
stabilne w długim horyzoncie czasowym.
a
Problemy
współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach
integracyjnych.
a
Problemy
przystosowania już istniejących i działających systemów do nowych wymagań,
tendencji i platform sprzętowo-programowych.
a
Frustracje
informatyków wynikające ze zbyt
szybkiego postępu w zakresie narzędzi
i metod wytwarzania oraz uciążliwości i długotrwałości procesów produkcji i pielęgnacji oprogramowania. Znaczące zmiany w
przemyśle informatycznym następują co 5-7 miesięcy w porównaniu do 5-7 lat w innych dziedzinach.
Kryzys oprogramowania – przyczyny
- Konflikt pomiędzy odpowiedzialnością, jaka spoczywa na współczesnych SI, a ich zawodnością wynikającą ze złożoności i ciągle niedojrzałych metod tworzenia i weryfikacji oprogramowania.
- Długi
i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo
niepowodzenia projektu programistycznego.
- Niska
kultura ponownego użycia wytworzonych
komponentów projektów
i oprogramowania (reuse); niski stopień powtarzalności poszczególnych przedsięwzięć. - Długi
i kosztowny cykl życia SI, wymagający stałych (często globalnych) zmian.
- Eklektyczne,
niesystematyczne narzędzia i języki programowania.
Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania.
Strukturalizacja oprogramowania
Korzyści jakie
przynosi strukturalizacja
oprogramowania:
- Jeśli wystarczy jedynie rozpoznać interface do komponentu, a nie jego szczegółową implementację, musi to zaowocować większą wydajnością pracy.
- Jeśli można bezpiecznie zignorować niektóre aspekty systemu (objęte przez wykorzystywany komponent) to większą uwagę można przyłożyć do swojej pracy, przez co mniej błędów wprowadza się do systemu.
- Dzięki strukturalizacji oprogramowania łatwiej znajduje się błędy (zarówno w trakcie budowania, jak i konserwacji systemu); nie wszystkie moduły muszą być testowane przy usuwaniu konkretnego błędu.
- Dobrze przetestowany, udokumentowany komponent może być wielokrotnie wykorzystywany (ponowne użycie).
- Modularna budowa ułatwia podział pracy.
“Nawet ubogi interface do źle
skonstruowanego komponentu może uczynić system
( jako całość) łatwiejszym do zrozumienia, a przez to
do modyfikacji.”
Ze strukturalizacją
oprogramowania związane są dwa, opisane dalej, pojęcia: kohezja
i skojarzenia.
Kohezja i skojarzenia
Kohezja (cohesion)
oznacza zwartość, spoistość. Terminu
tego używa się np.
w odniesieniu do komponentu
oprogramowania (klasy, modułu,
itp.) na
oznaczenie wzajemnego zintegrowania jego elementów składowych. Duża kohezja oznacza silną interakcję wewnątrz i
relatywnie słabszą interakcję z zewnętrzem. Komponenty powinna cechować duża kohezja, co oznacza,
że komponent stanowi dobrą, intuicyjną abstrakcję “czegoś”, czyli posiada precyzyjnie określoną semantykę, jest dobrze wyizolowany z kontekstu
(maksymalnie od niego niezależny) oraz posiada dobrze zdefiniowany interface.
Skojarzenie (coupling) określa stopień powiązania między komponentami, np. dla klas: jak często obiekty jednej klasy występują razem z obiektami innych klas, jak często obiekty jednej klasy wysyłają komunikaty do obiektów innej klasy, itp. Możliwe są skojarzenia silne, słabe czy w ogóle brak skojarzenia. Duża ilość silnych skojarzeń miedzy elementami składowymi (high coupling) jest tym, czego powinno się unikać.
Analiza stopnia kohezji i wzajemnych skojarzeń stanowi podstawę do
konstruowania architektury systemu, czyli wyróżniania elementów składowych
systemu, określania ich wzajemnych
interakcji oraz sposobów przesyłania
między nimi danych.
Zadania inżynierii oprogramowania
Zadania stojące przed inżynierią oprogramowania w walce z narastającą
złożonością oprogramowania:
- Redukcja złożoności oprogramowania;
- Propagowanie
wykorzystywania technik i narzędzi ułatwiających pracę nad złożonymi
systemami;
- Upowszechnianie
metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych
doświadczeń;
- Usystematyzowanie
procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i
monitorowanie;
- Wytworzenie
wśród producentów i nabywców przekonania, że budowa dużego systemu
wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia.
Jedną z zasadniczych kwestii jest dobra współpraca z użytkownikiem na
etapie analizy problemu i tworzenia podstaw projektu.
Kluczową sprawą jest właściwe zebranie danych na etapie analizy. Napotyka
to jednak na specyficzne przeszkody.
Zasady przeprowadzania rozmów z przyszłymi użytkownikami:
- Nie należy przeprowadzać rozmów równocześnie ze zbyt liczną grupą osób, najlepiej dwu lub trzyosobową.
- Należy starannie dobrać osoby, z którymi będą przeprowadzane rozmowy, najbardziej wartościowymi rozmówcami są osoby z największym doświadczeniem w danej dziedzinie.
- Osoby,
z którymi będą przeprowadzane rozmowy powinny zostać wcześniej
poinformowane,
czego analityk chciałby się dowiedzieć, dobrze jest sporządzić w pisemnej formie listę głównych pytań.
Zasady przeprowadzania rozmów z przyszłymi użytkownikami:
- Powinno się unikać pytań "jak?", skupiając się na pytaniu "co?".
- W pierwszych rozmowach należy dowiedzieć się, jakie jest przeznaczenie systemu oraz jakie powinny być jego zasadnicze funkcje.
- Należy dążyć do ograniczenia niejednoznaczności wymagań do minimum tak, aby umożliwić utworzenie projektu maksymalnie zgodnego z oczekiwaniami.
- Należy dotrzeć do szczegółów wiążących się z poszczególnymi wymaganiami.
Zasady przeprowadzania rozmów z przyszłymi użytkownikami:
- Należy pamiętać, że to przyszli użytkownicy są kluczem do dobrego projektu.
- Dobrze jest zapewnić sobie pomoc w sporządzaniu notatek z rozmów, aby lepiej skoncentrować się na wypowiedziach rozmówcy.
- Rozmowy
nie powinny być przedłużane, a jednocześnie wszystkie zagadnienia powinny
zostać omówione.
Dlatego też w razie konieczności należy umówić się na dodatkowe spotkanie. - Zaraz po przeprowadzonej rozmowie użytkownicy powinni otrzymać szczegółowe notatki z przebiegu spotkania w celu opatrzenia ich komentarzem, co do kwestii spornych.
Klasyczne podejście do projektowania systemów informatycznych dla zarządzania było technocentryczne:
Wkładano wiele troskliwego wysiłku w tworzenie i optymalizowanie coraz doskonalszych systemów komputerowych. Natomiast ludzie byli tylko dodatkiem do mądrych maszyn i musieli się do nich dostosować.
Przy podejściu technocentrycznym możemy mieć doskonałe informacje i na ich podstawie podejmować nietrafne i nieskuteczne działania.
Tymczasem do sprawnego zarządzania i do podejmowania trafnych decyzji nie są tak naprawdę potrzebne informacje, które mogą być szybko i sprawnie przetwarzane przez komputery, ale wiedza, a nawet mądrość, która może się zrodzić wyłącznie w umyśle człowieka.
Dlatego punktem wyjścia w projektowaniu nowoczesnych skomputeryzowanych systemów zarządzania musi być człowiek: jego predyspozycje, preferencje, możliwości i ograniczenia.
Trzeba dążyć do tego, aby systemy informatyczne były coraz doskonalsze, ale nie można dopuścić do tego, żeby człowiek stał się dodatkiem do komputera.
I nie chodzi tu bynajmniej wyłącznie o realizację szczytnych idei humanistycznych. Tak jest po prostu sprawniej i efektywniej!
Na tym właśnie polega antropocentryczny sposób projektowania systemów informatycznych.
Najpierw ludzie i ich potrzeby, a dopiero potem systemy techniczne i ich parametry!
Przy podejściu antropocentrycznym komputer nie zastępuje ludzi, ale wspomaga ich twórcze myślenie.
Podstawowa wskazówka metodologiczna dotycząca projektowania
systemów informatycznych:
Jeśli to tylko jest możliwe, to lepiej jest wybrać gotowy system informatyczny
niż projektować i budować od podstaw nowy.
Podejście antropocentryczne ma zastosowanie także w przypadku wyboru gotowego systemu!
Wybór gotowego systemu dobrze jest prowadzić zgodnie z przemyślanym schematem metodycznym!
Zarówno do zadania wyboru systemu jak i do jego zaprojektowania trzeba zbudować odpowiedni zespół fachowców.
Jeśli dla rozważanego zagadnienia nie da się dobrać systemu gotowego to trzeba go zaprojektować.
Jeśli zachodzi potrzeba zaprojektowania systemu informacyjnego, to większą część pracy staramy się wykonać przy użyciu różnych rysunków i diagramów, bo taka forma jest bardzie czytelna dla ludzi.
Powstające obrazki pozwalają dobrze sobie wyobrazić, jak będą ze sobą współdziałać ludzie i elementy techniczne systemu.
Przy projektowaniu systemów informatycznych
trzeba koniecznie brać pod uwagę
tzw. „Prawa Murphy’ego”
- Jeśli coś może się nie udać – nie uda się na pewno
- Jeśli myślisz, że wszystko idzie dobrze – na pewno o czymś nie wiesz
- Trudne problemy pozostawione same sobie staną się jeszcze trudniejsze
- Jeśli udoskonalasz coś dostatecznie długo – na pewno to zepsujesz
- Niemożliwe jest zbudowanie systemu niezawodnego – głupcy są zbyt pomysłowi
- Aby oszacować czas potrzebny do stworzenia systemu – należy przewidywany czas pomnożyć przez dwa i podać go w jednostkach wyższego rzędu (np. w tygodniach, zamiast w dniach)
- Prawdopodobieństwo każdego zdarzenia jest odwrotnie proporcjonalne do stopnia, w jakim jest ono pożądane
- To, czego szukasz, znajdziesz w ostatnim z możliwych miejsc
- Nie ma rzeczy niemożliwych dla kogoś, kto nie musi ich sam robić
- Wszyscy kłamią, nie ma to jednak znaczenia, bo i tak nikt nikomu nie wierzy
- Logika jest absolutnie pewną metodą dochodzenia do niepewnych wniosków
- Wszystko co dobre, jest niemoralne, nielegalne, albo powoduje tycie