inżynieria oprogramowania
DESCRIPTION
Inżynieria oprogramowania. Wprowadzenie Kryzys oprogramowania. 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óry skazana na niepowodzenie !. =. - PowerPoint PPT PresentationTRANSCRIPT
Wydział Inżynieryjno-Ekonomiczny Transportu
Inżynieria oprogramowania
WprowadzenieKryzys oprogramowania
Wydział Inżynieryjno-Ekonomiczny Transportu
Pytanie na początek
Jaki procent dużych projektów informatycznych
kończy się SUKCESEM?
Wydział Inżynieryjno-Ekonomiczny Transportu
Marsz ku klęsce!!!Zdecydowana większość dużych
projektów informatycznych jest z góryskazana na niepowodzenie!
=
Wydział Inżynieryjno-Ekonomiczny Transportu
Polskie przykłady
Informatyzacja PZU Informatyzacja ZUS System POJAZD Informatyzacja urzędów skarbowych
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
Udany projektZakres
Czas
Koszty
Udany projektProdukt końcowy
TerminKoszty realizacji
Wydział Inżynieryjno-Ekonomiczny Transportu
Wydatki na projekty SI
250300
260275
255
220 240 260 280 300Wydatki w mld USD
Rok20022000199819961994
200 tys. projektów
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
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%
Wydział Inżynieryjno-Ekonomiczny Transportu
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%
Wydział Inżynieryjno-Ekonomiczny Transportu
Wnioski z badań
Chaos w obszarze projektowania SI spowodowany jest
błędami ludzkimi, a nietechnologicznymi
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
Źródła złożoności oprogramowania
Software
Złożoność technologicz
na
Złożoność dziedzinowa
Złożoność psychologiczna
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
Metody projektowaniaCiągle niedoskonałe metody i narzędzia tworzenia i weryfikacji oprogramowania.
UML
DFDERD
XP
SADT
PSL/PSA
RSL/REVS
HELP!
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
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
Wydział Inżynieryjno-Ekonomiczny Transportu
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”
Wydział Inżynieryjno-Ekonomiczny Transportu
Dziękuję za uwagę
Zapraszam za tydzień