Informacja o ciekawym wykładzie:

"IT - branża dla ekonomistów którzy nie lubią się nudzić".

Odbędzie się on 13 listopada o godzinie 10.30 w sali 4 pawilonu S.

System informatyczny jest tworem bardzo złożonym

Dlatego metodologia jego projektowania musi być jasna,

konsekwentna i efektywna

Model kaskadowy jestczytelny, przejrzysty, ale w istocie niepraktyczny

Proces projektowania systemu informacyjnego

Do zmiany sposobu myślenia o projektowaniu systemów

informacyjnych zmusił informatyków

kryzysoprogramowania

Kryzys oprogramowania - symptomy (1)

USA:

(IEEE Software Development, Aug 94, p.65)Utrzymanie 10 mld. linii istniejących programów kosztuje 70 mld. $ rocznie

(Failed technology projects in Investor’s Business Daily, Los Angeles, Jan. 25, 1995, p. A8)

(PC Week, 16 Jan 95, p.68)31% nowych projektów jest anulowane przed zakończeniem; koszt 81 mld. $

Symptomy kryzysu oprogramowania:

31% projektów jest anulowane jeszcze w trakcie konstrukcji

53% projektów jest kończone z przekroczeniem zaplanowanego czasu, budżetui 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.

Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym.

Problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych.

Problemy przystosowania już istniejących i działających systemów do nowych wymagań, tendencji i platform sprzętowo-programowych.

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.

Wszystko to spowodowało, że butni i pewni siebie informatycy musieli

„spuścić z tonu”

Kryzys oprogramowania - przyczynyKonflikt 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.

Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania.

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.

Źródła złożoności oprogramowania

Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji.

Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji.

Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów.

Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów.

Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć,języki, narzędzia, itd.

Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć,języki, narzędzia, itd.

Oprogramowanie

Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

Walka ze złożonością oprogramowania (1)

Złożoność powoduje, że głównym problemem w procesie konstrukcji produktów informatycznych stał się człowiek (analityk, projektant, programista, ...) z jego różnymi uwarunkowaniami fizycznymi, psychologicznymi i mentalnymi.

Wniosek: Technologie komputerowe powinny być bardziej zorientowane na ludzi, niż na maszyny.

Corobić?

Mechanizmy abstrakcji - pozwalają operować jednostkami bez wnikania w ich wewnętrzną strukturę (poprzez pominięcie mniej istotnych elementów, np. poprzez oddzielanie specyfikacji od implementacji), co znacząco ułatwia proces rozumienia; wyodrębnianie cech wspólnych i niezmiennych (inwariantnych) dla pewnego zbioru bytów.

Należy wykorzystywać:

Walka ze złożonością oprogramowania (2)

Ponowne użycie - pozwala na wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd.

Efekty:

można komponować większe jednostki oprogramowania z mniejszych; można dekomponować złożone struktury na fragmenty a następnie rozpatrywać te fragmenty niezależnie od siebie i niezależnie od całości.

Mechanizmy kompozycji i dekompozycji, czyli podział na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji (strukturalizację oprogramowania):

Zasada sprzyjania naturalnym ludzkim własnościom -pozwala na dopasowanie modeli pojęciowych i realizacyjnych systemów do mechanizmów percepcji i rozumienia świata przez ludzi.

Nie tylko wzrost efektywności procesu wytwarzania produktu programistycznego ale też i wzrost jakości oprogramowania, czyli np. poprawności, niezawodności, czytelności, testowalności, skalowalności, łatwej pielęgnacji, współdziałania, przenaszalności, itp.

Strukturalizacja oprogramowania

“Nawet ubogi interface do źle skonstruowanego komponentu może uczynić system ( jako całość) łatwiejszym do zrozumienia, a przez to do modyfikacji.”

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 przetestowny, udokumentowany komponent może być wielokrotnie wykorzystywany (ponowne użycie). Modularna budowa ułatwia podział pracy.

Korzyści jakie przynosi strukturalizacja oprogramowania:

Ze strukturalizacją oprogramowania związane są dwa, opisane dalej, pojęcia: kohezja i skojarzenia.

Kohezja i skojarzeniaKohezja (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

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.

Zadania stojące przed inżynierią oprogramowania w walce z narastającą złożonością oprogramowania:

Redukcja złożoności oprogramowania;

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.

Czasem użytkownicy celowo wprowadzają w błąd zespół projektowy

Najbardziej dobitnie problemy związane z całym projektem informatycznym przedstawia poniższa historyjka

Zasady przeprowadzania rozmów z przyszłymi użytkownikami:

1) Nie należy przeprowadzać rozmów równocześnie ze zbyt liczną grupą osób, najlepiej dwu lub trzyosobową.

2) 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.

3) 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:

4) Powinno się unikać pytań "jak?", skupiając się na pytaniu "co?".

5) W pierwszych rozmowach należy dowiedzieć się, jakie jest przeznaczenie systemu oraz jakie powinny być jego zasadnicze funkcje.

6) Należy dążyć do ograniczenia niejednoznaczności wymagań do minimum tak, aby umożliwić utworzenie projektu maksymalnie zgodnego z oczekiwaniami.

7) Należy dotrzeć do szczegółów wiążących się z poszczególnymi wymaganiami.

Zasady przeprowadzania rozmów z przyszłymi użytkownikami:

8) Należy pamiętać, że to przyszli użytkownicy są kluczem do dobrego projektu.

9) Dobrze jest zapewnić sobie pomoc w sporządzaniu notatek z rozmów, aby lepiej skoncentrować się na wypowiedziach rozmówcy.

10) 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.

11) 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 optymalizowaniecoraz doskonalszych systemów komputerowych

Natomiast ludzie bylitylko dodatkiem do

mądrych maszyni 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.

Informacjeznakomite!

Decyzje mało trafne,

skutek biznesowy opłakany

Tymczasem do sprawnego zarządzania i do podejmowania

trafnych decyzji nie są tak naprawdę potrzebne informacjeinformacje,

które mogą być szybko i sprawnie przetwarzane przez

komputery, ale wiedzawiedza, a nawet mądrośćmądrość, która może się zrodzić wyłącznie w umyśle człowieka.

Dlategopunktem wyjścia w projektowaniu nowoczesnych skomputeryzowanych systemów zarządzania musi być człowiekczł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łowiekczłowiek stał się dodatkiemdodatkiem do komputera.

I nie chodzi tu bynajmniej wyłączniewyłącznie o realizację szczytnych idei humanistycznych.

Tak jest po prostu sprawniej i efektywniej!Tak jest po prostu sprawniej i efektywniej!

Na tym właśnie polega antropocentrycznyantropocentryczny

sposób projektowania systemów informatycznych.

Najpierw ludzie i ichpotrzeby, a dopiero

potem systemytechniczne i ich

parametry!

Przy podejściu antropocentrycznym komputer nie zastępuje ludzi,

ale wspomaga ich twórcze myślenie

Koncepcje

Danei oceny

Noweidee!

Podstawowa wskazówka metodologiczna dotycząca projektowania systemów

informatycznych: Jeśli to tylko jest możliwe, to Jeśli to tylko jest możliwe, to

lepiej jest wybrać gotowy lepiej jest wybrać gotowy system informatyczny niż system informatyczny niż projektować i budować od projektować i budować od

podstaw nowypodstaw nowy

Podejście antropocentryczne ma zastosowanie takżew przypadku wyboru gotowego systemu!

ETAP II

ETAP III

ETAP IV

ETAP V

ETAP VI

ETAP IOcena przedsiębiorstwa pod kątem posiadanej technologii

informatycznej

Zdefiniowanie założeń przedsięwzięcia informatycznego

Opracowanie zapytania ofertowego

Ocena odpowiedzi oferentów

Prezentacje i wizyty referencyjnej

Wybór 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

Zespoły skoncentrowane na zadaniach i na relacjach

Czas

Pro

du

ktyw

noś

ć

Zespoły zorientowanena zadania mają napoczątku większą

produktywność, aleich konflikty osobowe

negatywnie rzutują naprzyszłość

Zespoły zorientowane na relacjerozpoczynają działania trudniej

ale osiągają docelowo więcej

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ówi 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