Inżynieria oprogramowania

Wydział Inżynieryjno-Ekonomiczny Transportu

Inżynieria oprogramowania

WprowadzenieKryzys oprogramowania

http://wiet.am.szczecin.pl/info/index.php


Pytanie na początek

Jaki procent dużych projektów informatycznych

kończy się SUKCESEM?



Marsz ku klęsce!!!Zdecydowana większość dużych

projektów informatycznych jest z góryskazana na niepowodzenie!

=



Polskie przykłady

Informatyzacja PZU Informatyzacja ZUS System POJAZD Informatyzacja urzędów skarbowych



The Standish Group

Kolejne raporty: The CHAOS Chronicles I – 1995, The CHAOS Chronicles II – 2001, The CHAOS Chronicles III – 2003.

Amerykańska instytucja badawcza.Działalność: kompleksowa analiza rynku amerykańskiego w zakresie skuteczności realizacji projektów informatycznych.

www.standishgroup.com



Dlaczego CHAOS?

O chaosie w projektowaniu SI decyduje przeważająca liczba przedsięwzięć zakończonych :

niepowodzeniem w sensie ilościowym, czyli: przekroczeniem estymowanego czasu trwania działań

projektowych; przekroczeniem budżetu; porzuceniem z określonych powodów;

niepowodzeniem w sensie jakościowym, kiedy gotowy system wykazuje dużą niezgodność z pierwotną specyfikacją wymagań użytkownika.

Chaos – stan niezorganizowania, zamętu, nieładu



Udany projektZakres

Czas

Koszty

Udany projektProdukt końcowy

TerminKoszty realizacji



Wydatki na projekty SI

250300

260275

255

220 240 260 280 300Wydatki w mld USD

Rok20022000199819961994

200 tys. projektów



Realizacja projektów SI

16 27 26 28 3431

40 28 23 15

5333 46 49 51

0%

20%

40%

60%

80%

100%

1994 1996 1998 2000 2002

Niepowodzenie częścioweNiepowodzenie całkowiteSukces



Realizacja projektów SI

34

8473 74 72 66

1627

2826

0

20

40

60

80

100

1994 1996 1998 2000 2002

SukcesNiepowodzenie całkowiteNiepowodzenie częścioweNiepowodzenie razem



Jakość produktów

Im większy jest tworzony system, tym mniejsza zgodność produktu końcowego z pierwotną specyfikacją wymagań funkcjonalnych, a w związku z tym mniejsze zadowolenie klientów.

1994 2000 2002Zmiana: 2002 do

2000

Zmiana: 2002 do

1994Zgodność produktu ze specyfikacją

61% 67% 51% -16% -10%



Czynniki sukcesuCzynnik 1994 2000Zaangażowanie użytkownika 16% 16%Wsparcie zarządu (kierownictwa, sponsora) 14% 18%Jasne sformułowanie wymagań 13% 6%Właściwe planowanie 10% BrakRealne oczekiwania 8% BrakKrótsze etapy projektowania 8% 10%Kompetentny zespół projektowy 7% BrakJasno określona własność projektu (odpowiedzialność)

5% Brak

Jasna wizja i cele 3% 12%Ciężko pracujący, skupiony na projekcie zespół 2% BrakDoświadczony kierownik zespołu Brak (ew. 7) 14%Formalna metodyka Brak 6%Zastosowanie standardów infrastruktury Brak 8%Wiarygodne oszacowanie Brak (ew. 4) 5%Inne 1% 5%



Wnioski z badań

Chaos w obszarze projektowania SI spowodowany jest

błędami ludzkimi, a nietechnologicznymi



Niewłaściwa interpretacja wymagań klienta Częste i zbyt późne zgłaszanie zmian związanych z

oprogramowaniem Nieprawidłowe oszacowanie czasu realizacji projektu

(opóźnienia czasowe) Nieprawidłowe oszacowanie budżetu i zasobów Problemy w komunikacji pomiędzy członkami zespołu

projektowego Problemy w komunikacji pomiędzy zespołem

projektowym a klientem Duża liczba małych błędów w oprogramowaniu,

wynikająca z nieprawidłowego testowania Problemy wdrożeniowe i brak odpowiedniej pielęgnacji

oprogramowania

Podstawowe problemy



Złożoność oprogramowania

Złożoność oprogramowania (wewnętrzna i wymagana komunikacją z innymi systemami – patrz MS Windows/MS Office)

UNIX – 4 000 000 linii kodu Windows 2000 – 35 000 000

linii kodu Windows XP – około 50 000

000 linii kodu



RokLiczba

użytkowników

Liczba linii kodu

1991

100 10 000

1992

1000 40 000

1993

20 000 100 000

1994

100 000 170 000

1995

500 000 250 000

1996

1 500 000 400 000

1998

7 500 000 1 500 000

Rozwój systemu LINUX:

Złożoność oprogramowania



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

Software

Złożoność technologicz

na

Złożoność dziedzinowa

Złożoność psychologiczna



Windows Zespół programistów

Liczba testerów

NT 3.1 200 osób 140 osóbNT 3.5 300 osób 230 osóbNT 3.51 450 osób 325 osóbNT 4.0 800 osób 700 osóbWin 2000 1400 osób 1700 osób

Wielość współautorów oraz problemy związane z błędami na etapie określania wymagań, projektowania, wykonywania i testowania

Liczebność zespołów projektowych



Metody projektowaniaCiągle niedoskonałe metody i narzędzia tworzenia i weryfikacji oprogramowania.

UML

DFDERD

XP

SADT

PSL/PSA

RSL/REVS

HELP!



Kryzys oprogramowania

Długi i kosztowny cykl tworzenia oprogramowania Długi i kosztowny cykl życia SI, wymagający stałych

zmian Wysokie koszty utrzymania oprogramowania Wysokie prawdopodobieństwo niepowodzenia projektu

programistycznego Sprzeczność pomiędzy odpowiedzialnością współczesnych

systemów informatycznych, a ich zawodnością Problemy współdziałania niezależnie zbudowanego

oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych



Kryzys oprogramowania

Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji (często niestabilnych w długim horyzoncie czasowym)

Dążenie do przystosowania istniejących i działających systemów do nowych wymagań i tendencji oraz platform sprzętowo-programowych

Niski stopień powtarzalności poszczególnych przedsięwzięć

Niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania

Szybki rozwój narzędzi informatycznych



Prawa Murphiego

„główne błędy powstają na styku: klient – firma informatyczna, projektant-programista, programista-komputer”

„jeżeli gdziekolwiek może pojawić się błąd, tam na pewno się pojawi”

„nie ma programów bezbłędnych, są tylko takie w których dotąd nie znaleziono błędu”



Dziękuję za uwagę

Zapraszam za tydzień


Documents

Inżynieria oprogramowania