Inżynieria Oprogramowania Wykład 01 - Wprowadzenie

Transkrypt

1 Inżynieria Oprogramowania Wykład 01 - Wprowadzenie MIS s MIO s MIS n Kazimierz Michalik Wydział Inżynierii Metali i Informatyki Przemysłowej Katedra Informatyki Stosowanej i Modelowania Kraków

2 Pojęcie podstawowe Oprogramowanie (software) pojęcie podstawowe (do oprogramowania włącza się niekiedy, oprócz plików binarnych i i z kodem źródłowym, także dokumentację, pliki konfiguracyjne, przykładowe dane itp..) Inżynieria oprogramowania (Software Engineering) dziedzina inżynierii związana z wytwarzaniem oprogramowania we wszystkich jego fazach cyklu życia. Jako dziedzina inżynierii, IO IO rozważa w kontekście praktycznym rozmaite aspekty wytwarzania oprogramowania (techniczny, organizacyjny, finansowy itp..)

3 Cele inżynierii oprogramowania Cel Cel podstawowy: podstawowy: Dostarczenie Dostarczenie zasad zasad organizacji organizacji procesu procesu wytwarzania wytwarzania oprogramowania oprogramowania (sofware (sofware development) development) w oparciu oparciu o istniejące istniejące teorie, teorie, modele, modele, metody metody i i narzędzia narzędzia (formalne (formalne lub lub nieformalne). nieformalne). W końcowym końcowym efekcie efekcie proces proces wytwarzania wytwarzania oprogramowania oprogramowania ma ma w sposób sposób efektywny efektywny doprowadzić doprowadzić do do powstania powstania produktu produktu wysokiej wysokiej jakości jakości Inżynieria Inżynieria oprogramowania oprogramowania jest jest częścią częścią szerszej szerszej dyscypliny: dyscypliny: inżynierii inżynierii systemów systemów (system (system engineering), engineering), w jej jej aspekcie aspekcie dotyczącym dotyczącym oprogramowania. oprogramowania.

4 Problemy inżynierii oprogramowania Złożoność programów Złożoność systemów, w ramach ramach których których funkcjonują programy programy (ludzie, (ludzie, sprzęt, sprzęt, instytucje, procesy procesy produkcyjne etc.) etc.) Zmienność systemów Złożoność procesów procesów składających się się na na wytwarzanie oprogramowania (( w przeciwieństwie do do prostoty prostoty pisania pisania samego samego kodu) kodu) Łatwość Łatwość i i praktyczna nieuniknioność popełniania błędów błędów przy przy wytwarzaniu oprogramowania

5 Cechy dobrego oprogramowania Wg. Wg. Sommerville'a: Poprawność, zgodność zgodność z wymaganiami użytkowników Łatwość Łatwość pielęgnacji (konserwacji) i i dokonywania zmian zmian Niezawodność (dostępność i i pewność) pewność) Bezpieczeństwo (w (w obu obu znaczeniach safety, safety, security) security) Wydajność, efektywne korzystanie z zasobów zasobów Łatwość Łatwość stosowania, ergonomiczność

6 Historia Inżynierii Oprogramowania: Prehistoria. II wojna światowa. ABC (us.), Electronic Numerical Integrator And Computer(us.), Colossus(uk.), Konrad Zuse(de.) Nowe komputery (architekturalnie) pojawiają się w odstępach paru lat. Całe oprogramowanie musi być przepisane/napisane na nowo dla nowych maszyn Czasy kart perforowanych i wydruków z wynikami. Program = Algorytm. 1945: Architektura von Neumanna

7 Historia Inżynierii Oprogramowania: Prehistoria. II wojna światowa.

8 Historia Inżynierii Oprogramowania: : Narodziny Język Język programowania: programowania: Komputery, Komputery, wraz wraz z z oprogramowaniem, oprogramowaniem, są są stworzone stworzone do do konkretnych konkretnych celów celów i i rodzaju rodzaju obliczeń. obliczeń. Ciągła Ciągła potrzeba potrzeba przepisywania przepisywania programów programów doprowadza doprowadza do do powstania powstania języków języków programowania programowania Oprogramowanie Oprogramowanie było było darmowe darmowe Era Era freeware: freeware: Wydawcy Wydawcy tworzyli tworzyli otwarte otwarte repozytoria z oprogramowaniem Na Na uniwersytetach nie nie istnieje istnieje taki taki przedmiot przedmiot jak jak Informatyka (Inżynieria Oprogramowania też też oczywiście oczywiście nie) nie)

9 Historia Inżynierii Oprogramowania: : Kryzys oprogramowania Przekraczanie budżetu o miliony dolarów (OS/360) Przekraczanie czasu na przykład 10 lat Uszkodzenie mienia w wyniku błędów programu (Mariner 1) Zagrożenie zdrowia i życia np.: śmierć w wyniku napromieniowania (Therac-25), błędu systemu kierowania ogniem (MIM-104 Patriot)

10 Historia Inżynierii Oprogramowania: : Software engineering Software Software Engineering: Report Report of of a conference sponsored by by the the NATO NATO Science Science Committee,, Garmisch, Germany: Scientific Scientific Affairs Affairs Division, Division, NATO. NATO. E.W. E.W. Dijkastra Dijkastra Go Go To To Statement Considered Harmful Harmful 1969: 1969: Termin Termin Inżynieria Inżynieria Oprogramowania ujrzał ujrzał światło światło dzienne dzienne Wczesne Wczesne lata lata '80: '80: Inżynieria Inżynieria Oprogramowania staje staje się się wyróżnialnym zawodem zawodem plasującym się się między między informatyką a Inżynierią Inżynierią

11 Historia Inżynierii Oprogramowania: : Wciąż kryzys oprogramowania 1972: D.Parnas On the Criteria To Be Used in Decomposing Systems into Modules Programowanie modułowe i abstrakcyjne typy danych były już używane. Późne lata '80: Koszty utrzymania oprogramowania 2x wyższe niż koszt stworzenia nowego. Wczesne lata '90: Koszty utrzymania nadal wzrastają o kolejne 30% 1995: 50% programów uznawanych za porażkę, mimo teoretycznie poprawnego działania Przeciętny projekt przekracza wyznaczony czas o 50%!

12 Historia Inżynierii Oprogramowania: : Brak panaceum Propozycje rozwiązania problemów: Narzędzia: różne sposoby programowania (strukturalne, OO), CASE, dokumentacja, standardy Dyscyplina pracy programistów. Metody formalne z inżynierii. Proces wytwarzania oprogramowania ( Capability Maturity Model) Etyka pracy, licencje, profesjonalizm. 1986, 1986, Fred Fred Brooks, Brooks, No No Silver Silver Bullet Bullet Brak Brak cudownego cudownego leku, leku, ale ale Inżynieria Inżynieria Oprogramowania ma ma sens! sens!

13 Historia Inżynierii Oprogramowania: : Orientowane Obiektowo Intensywne użytkownie CASE Projektowanie O.O. Narzędzia do inżynierii wymagań Wzrost popularności architektur rozproszonych Universal Markup Language (UML) Java

14 Historia Inżynierii Oprogramowania: : Współczesność Zintegrowane środowiska programistyczne (IDE) UML 2.0 Lekkie języki skryptowe Metodologie lekkie Zaawansowane metodologie hybrydowe Nowe platformy i języki: C# etc.

15 Czynności w czasie produkcji oprogramowania Inżynieria oprogramowania stara się zidentyfikować i opisać podstawowe fazy tworzenia i funkcjonowania oprogramowania, a także wskazać model optymalnego przebiegu tych faz. Co Co można można robić robić w czasie czasie tworzenia tworzenia oprogramowania? Planowanie Implementacja Testowanie Dokumentowanie Wdrożenie Utrzymanie (konserwacja).

16 Warto przeczytać Sommerville I.: Inżynieria oprogramowania 8-th ed., Addison-Wesley, 2006 (wyd.6, WNT, 2003) Hunt A., Thomas D.: The Pragmatic Programmer: From Journeyman to Master Yourdon, E.: Marsz ku klęsce. Poradnik dla projektantów systemów. WNT, 2007 Booch G., Jacobson I., Rumbaugh J.: UML przewodnik użytkownika WNT 2002 Gamma E., Helm R., Johnson R., Vlissides J.: Wzorce projektowe. Elementy programowania obiektowego wielokrotnego użytku, WNT 2005 Sacha K.: Inżynieria oprogramowania, Wydawnictwo Naukowe PWN, 2010 Steve McConnel: Kod doskonały. Jak tworzy c oprogramowanie pozbawione błędów. Wydanie II Martin Fowler: UML Distilled Brooks, Mityczny osobomiesiąc: eseje o inżynierii oprogramowania. WNT,

17 Warunki zaliczenia przedmiotu (1) Sposób obliczania oceny końcowej: Średnia ważona ocen z egzaminu (66%) i projektu (34%) po uzyskaniu co najmniej 3.0 z każdej z nich Wymagania wstępne i dodatkowe: Programowanie w języku obiektowym Nakład pracy studenta (bilans punktów ECTS): Udział w wykładach Udział w ćwiczeniach projektowych Przygotowanie do zajęć Wykonanie projektu Samodzielne studiowanie tematyki zajęć Sumaryczne obciążenie pracą studenta Punkty ECTS za moduł 30 godz 30 godz 30 godz 30 godz 30 godz 150 godz 6 ECTS WARUNKI UZYSKANIA ZALICZENIA: (Regulamin studiów 13, pkt 1:) % bardzo dobry (5.0); 81 90% plus dobry (4.5); 71 80% dobry (4.0); 61 70% plus dostateczny (3.5); 50 60% dostateczny (3.0); poniżej 50% niedostateczny (2.0). PUNKTACJA: nominalnie jest do zdobycia 100 punktów

18 Warunki zaliczenia projektu (2) PUNKTACJA: nominalnie jest do zdobycia 100 punktów Wykłady: (DODATKOWO!) Wykład Semestr za aktywne uczestnictwo w wykładzie 1 pkt 15 pkt Zajęcia projektowe: Zajęcia Semestr za poprawne przygotowanie do zajęć 0 do 2 pkt 30 pkt za punktualną obecność i wykonywanie zadań 0 do 1 pkt 15 pkt (albo za spóźnienie do 15tu minut i wykonywanie zadań 0 do 0,5 pkt 7,5 pkt) za poprawne i samodzielne ukończenie zadań na zajęciach 0 do 2 pkt 30 pkt rozliczanie projektów na koniec listopada 0 do 10 pkt 10 pkt rozliczanie projektów na koniec semestru 0 do 15 pkt 15 pkt W SUMIE 100 pkt

19 Warunki zaliczenia projektu (3) Terminy poprawkowe: Termin W sumie Przysługują tylko tym, którzy: - nie uzyskali zaliczenia w poprzednim terminie i -- byli na przynajmniej 7 zajęciach w semestrze lub -- przedłożyli w wymaganym terminie usprawiedliwienie większej ilości nieobecności. I popr. II popr. za wykonanie zadań z tematów, w których student nie wykazał się wiedzą w czasie semestru za wykonanie zadań z tematów, w których student nie wykazał się wiedzą w czasie semestru i I terminu poprawkowego. 25 pkt 25 pkt W SUMIE DODATKOWO 50 pkt

20 Warunki zaliczenia egzaminu (4) Warunkiem przystąpienia do egzaminu jest pozytywna ocena z zajęć projektowych. Egzamin trzeba po prostu zdać (50%+). Jeżeli w czasie semestru ktoś zdobędzie więcej niż 100 pkt, to dodatkowe punkty są doliczane do wyniku egzaminu. Jakie Jakie jest jest absolutne absolutne minimum, minimum, żeby żeby zdać zdać egzamin egzamin na na 50%? 50%? W każdym każdym wykładzie, wykładzie, treści treści absolutnie absolutnie wymagane wymagane do do zdania zdania egzaminu egzaminu na na będą będą wyróżnione wyróżnione w ramkach ramkach koloru koloru czerwonego. czerwonego. (Technicznie (Technicznie jest jest to to odcień odcień bladopomarańczowego, bladopomarańczowego, ale ale jestem jestem pewien, pewien, że że zorientujecie zorientujecie się się które które to to są są ramki.) ramki.)

21 Dziękuję za uwagę W przypadku sugestii, pytań lub spostrzeżenia błędów: kontakt mailowy to kamich@agh.edu.pl