INŻYNIERIA OPROGRAMOWANIA INŻYNIERIAOPROGRAMOWANIA

Zagadnienia wstępne

Wykorzystane materiały:• prezentacje J.E. Sienkiewicza • I. Sommerville, Inżynieria oprogramowania, WNT 2003• blogi J. Spolsky’ego, J. Atwooda i inne

Czy to będzie bolesne? O stary, zawsze takie będzie. Będzie potworne.

Studenci znienawidzą to. Zaczną kwestionować to, dlaczego ktoś o

zdrowych zmysłach chciałby pisać oprogramowanie.

Witamy w prawdziwym świecie.J. Atwood, o propozycji rozwijania oprogramowania na uczelniach w warunkach jak najbardziej zbliżonych do tych z prawdziwego świata (tłum. rafek, http://www.devblogi.pl)

Inżynieria (ogólnie) jako nauka INŻYNIERIAOPROGRAMOWANIA

� działalność ludzka

� projektowanie, konstrukcja, modyfikowanie i konserwacja sztucznych systemów

� opiera się o wiedzę naukową i techniczną

� inżynier wykorzystuje swoją wiedzę, wyobraźnię, doświadczenie, umiejętność oceny i rozumowanie

To, co odróżnia inżynierię ogólną

od inżynierii oprogramowania

to PRODUKT i jego specyficzne cechy

Inżynieria oprogramowania jako nauka (1) INŻYNIERIAOPROGRAMOWANIA

� stosunkowo młoda dyscyplina, ciągle się rozwijająca

� narodziny: lata 60-te XX wieku

� definicja według IEEE:

zastosowanie systematycznego, zdyscyplinowanego, ilościowego podejścia do rozwoju, eksploatacji i utrzymania oprogramowania

(oprogramowanie – programy komputerowe, cała związana z nimi dokumentacja i dane konfiguracyjne)

Inżynieria oprogramowania jako nauka (2) INŻYNIERIAOPROGRAMOWANIA

� zajmuje się teorią, metodami i narzędziamizwiązanymi z wytwarzaniem oprogramowania

� obejmuje wszelkie aspekty produkcji oprogramowania: analizę i określenie wymagań, projektowanie, implementację, wdrożenie, ewolucję gotowego produktu

Inżynieria oprogramowania

obejmuje praktyczną stronę informatyki

Znaczenie inżynierii oprogramowania INŻYNIERIAOPROGRAMOWANIA

� gospodarki wszystkich rozwiniętych krajów zależą od oprogramowania

� ponadto, samo wytwarzanie oprogramowania jest też poważną gałęzią gospodarki narodowej każdego rozwiniętego kraju

� coraz więcej i więcej systemów wymaga niezawodnego oprogramowania

� istnieje potrzeba systematyzacji i uporządkowania procesu wytwarzania oprogramowania – ułatwienia tworzenia oprogramowania wysokiej jakości

Inne powody, dla których warto bliżej poznać inżynierię oprogramowania…

INŻYNIERIAOPROGRAMOWANIA

� … bo na rynku istnieje ogromne zapotrzebowanie na kierowników projektów informatycznych

� … bo w projekty informatyczne „pompuje się” coraz więcej pieniędzy

� … bo niektórzy nie lubią kodowania (jest dla nich nudne, monotonne, nie rozwijające) – inżynieria oprogramowania to analiza, projekt, komunikacja interpersonalna, socjologia, prawo, psychologia...

� bo trzeba zdać egzamin z przedmiotu…

� bo pytania z inżynierii oprogramowania często pojawiają się na egzaminie dyplomowym…

Bieżące trendy w inżynierii oprogramowania INŻYNIERIAOPROGRAMOWANIA

� wielokrotne użycie kodu

� zunifikowany opis zachowania się obiektów w różnych, często nietypowych sytuacjach

� problem sprostania wymogowi dostarczania gotowego oprogramowania w skróconym czasie bez utraty jakości –zwinne metodyki, programowanie ekstremalne itp.

� konserwacja systemów spadkowych

� budowa systemów heterogenicznych

� modyfikacja i pielęgnacja dużych systemów, pełniących poważne funkcje gospodarcze

� szukanie i udoskonalanie efektywnych metod testowania oprogramowania (np. TDD, BDD)

Nowoczesna inżynieria oprogramowania INŻYNIERIAOPROGRAMOWANIA

Mimo już ok. 50 lat rozwijania różnych idei inżynierii oprogramowania, bieżące, nowoczesne myślenie o niej opiera się na wymienionych niżej, przełomowych publikacjach i wydarzeniach:

1994 Object-Oriented Design (Booch)

1995 Design Patterns (Gang of Four)

1997 UML Distilled (Fowler)

1999 Extreme Programming Explained (Beck)

1999 Refactoring (Fowler)

2000 powstanie SourceForge (kontrola wersji)

2001 powstanie Agile Alliance

Dlaczego popularyzacja nowych trendów w rozwoju oprogramowania tak długo trwa?

INŻYNIERIAOPROGRAMOWANIA

Technologia informatyczna potrzebuje 15-20 lat od koncepcji do popularyzacji

(M. Shaw, What Makes Good Research in Software Engineering? International Journal of Software Tools for Technology Transfer, 2002)

� Badania wstępne. Zbadanie podstawowych idei i koncepcji, sformułowanie początkowej struktury problemu oraz krytycznych pytań badawczych.

� Formułowanie koncepcji. Nieoficjalny obieg pomysłów, rozwijanie środowiska naukowego, dojrzewanie wspólnej idei, publikowanie rozwiązań określonych podproblemów.

� Rozwój i rozszerzanie. Wstępne zastosowania technologii, wyjaśnienie podstawowych idei, próby generalizowania podejścia.

� Wewnętrzne udoskonalenia i poszukiwania. Rozszerzenie podejścia na inne zagadnienia, wykorzystanie technologii do rzeczywistych problemów, stabilizacja technologii, opracowanie materiałów szkoleniowych, wykazywanie wartości rzeczywistych wyników.

� Zewnętrzne udoskonalenia i poszukiwania. Podobne do wewnętrznego, ale z udziałem szerszej społeczności ludzi, którzy nie byli twórcami technologii, przedstawienie istotnych dowodów wartości technologii i jej zastosowań.

� Popularyzacja. Opracowanie produkcyjnych standardów jakości, supportowanych wersji technologii, komercjalizacja technologii, rozszerzenie społeczności użytkowników.

Z drugiej strony…Inżynieria oprogramowania… martwa?

INŻYNIERIAOPROGRAMOWANIA

� Tom DeMarco (IEEE, Bell Laboratories, The Atlantic Systems Guild): „Powoli dochodzę do wniosku, że inżynieria oprogramowania jest pewną ideą, której czas nadszedł i się skończył. Tworzenie oprogramowania jest i zawsze będzie poniekąd eksperymentalne. W istocie sama konstrukcja oprogramowania niekoniecznie jest eksperymentalna, ale koncepcje za nim stojące są. I to właśnie na to powinniśmy kierować naszą uwagę. To tam nasza uwaga powinna była być skupiona od zawsze.”http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

� Joel Spolsky (Microsoft, Fog Creek Software, Joel on Software, stackoverflow):„Mam całkiem głęboko zakorzenione wizje na temat tego, jak powinno się tworzyć oprogramowanie, ale trzymam je głównie dla siebie. Okazało się to dobrą rzeczą, ponieważ jak tylko organizacja zaczęła nabierać kształtu, wszystkie te zasady zostały porzucone (…) i nic strasznego się nie stało.”http://www.inc.com/magazine/20081101/how-hard-could-it-be-the-unproven-path.html

� Jeff Atwood (Coding Horror, stackoverflow):„Kontrola jest całkowicie iluzoryczna jeśli chodzi o projekty programistyczne. Jeśli chcesz popychać swój projekt do przodu, to jedynym sposobem jest kultywowanie głębokiego poczucia rzemiosła i profesjonalizmu wokół niego.”http://www.codinghorror.com/blog/2009/07/software-engineering-dead.html

Inżynier oprogramowania (software engineer) INŻYNIERIAOPROGRAMOWANIA

� zajęcie wpisane na oficjalną listę zawodów w roku 1990 (za granicą)

� w Polsce – brak oficjalnego rozróżnienia w klasyfikacji zawodów (inżynierowie i pokrewni gdzie indziej niesklasyfikowani)

� według Money Magazine i Salary.com – zawód uznany w 2006 roku za najlepszy w Stanach Zjednoczonych, pod względem możliwości rozwoju, wysokości pensji, poziomu stresu, elastyczności godzin pracy i środowiska pracy

� wg Careecast: 3 miejsce na liście najmniej stresujących zawodów w 2011 r. („spokojna praca przed komputerem z bardzo dobrymi perspektywami zatrudnienia”)

Inżynier oprogramowania – drabina płac INŻYNIERIAOPROGRAMOWANIA

(Dane z 2014 r.: Compass, grafika: Anna Vital)

Odpowiedzialność etyczna i zawodowa INŻYNIERIAOPROGRAMOWANIA

� inżynierowie oprogramowania ponoszą znacznie większą odpowiedzialność niż tylko wynikająca z ich technicznych umiejętności

� profesjonaliści zawsze powinni postępować etycznie i moralnie, przestrzegać kodeksów etycznych i zawodowych

zachowywać się etycznie to więcej, niż tylko przestrzegać obowiązujące prawo

Zasady zawodowej odpowiedzialności INŻYNIERIAOPROGRAMOWANIA

� Zachowywanie tajemnicy. Inżynierowie powinni zawsze dochowywaćtajemnic powierzonych przez pracodawców i klientów, niezależnie odtego czy podpisano formalną umowę o ochronie tajemnicy

� Kompetencje. Inżynierowie nie powinni zawyżać poziomu swoichkompetencji. Nie powinni świadomie przyjmować prac, któreprzekraczają ich możliwości

� Prawo własności intelektualnej. Inżynierowie powinni znaćmiejscowe prawo regulujące korzystanie z własności intelektualnej.Powinni szczególnie dbać o poszanowanie intelektualnej własnościswoich pracodawców i klientów

� Niewłaściwe użycie komputera. Inżynierowie oprogramowania niepowinni używać swoich umiejętności do niewłaściwego używaniacudzych komputerów

Przykład rażącego naruszenia zasad… INŻYNIERIAOPROGRAMOWANIA

Program G-Archiver (służący do tworzenia kopii zapasowej konta Gmail) zawierałw swoim kodzie procedurę, która wysyłała na e-mail twórcy programu dane konta(login/hasło) osoby, która go użyła… Ponieważ do wysłania e-maila potrzebnebyło logowanie na serwer SMTP, dane konta autora również zostały zakodowane wprogramie.

Sprawa została przypadkowo odkryta w 2008 r. przez ciekawskiego programistę, który zdekompilował program.

Twórcy tłumaczyli się, że to pozostałość po testowej wersji programu…

Kodeksy etyczne i zawodowe INŻYNIERIAOPROGRAMOWANIA

� Różne zagraniczne stowarzyszenia zawodowe (np. ACM – Association for Computing Machinery, IEEE – Institute of Electrical and Electronic Engineers, ATIP – Association of Information Technology Professionals) od lat współpracują ze sobą przy publikowaniu kodeksów profesjonalnego zachowania i kodeksów etycznych.

� W Polsce próby stworzenia kodeksu informatyka podjęły PTI – Polskie Towarzystwo Informatyczne i PIIT – Polska Izba Informatyki i Telekomunikacji.

� W roku 1991 w USA Komisja Akredytacyjna Informatyki (Computer

Sciences Accreditation Commission) przyjęła wymóg włączenia istotnego komponentu etyki komputerowej do każdego programu studiów wyższych na kierunku informatycznym, posiadającego akredytację krajową.

„po pierwsze nie szkodzić”

Kodeks etyczny i zawodowy ACM (1) INŻYNIERIAOPROGRAMOWANIA

Jako członek ACM będę:� przyczyniał się do dobrobytu społeczności oraz ludzi,� unikał krzywdy innych,� postępował uczciwie tak, by być godnym zaufania,� unikał dyskryminacji kogokolwiek,� uznawał prawa własności włączając w to prawa autorskie i

patenty,� doceniał własność intelektualną,� respektował prywatność innych,� uznawał poufność.

źródło: http://www.acm.org/about/code-of-ethics

Kodeks etyczny i zawodowy ACM (2) INŻYNIERIAOPROGRAMOWANIA

Jako zawodowy informatyk ACM będę:� dążył do osiągnięcia najwyższej jakości i skuteczności, zarówno w

procesie produkcyjnym jak i w samych produktach pracy zawodowej,� osiągał i utrzymywał wysoki poziom kompetencji zawodowych,� znał istniejące przepisy prawne dotyczące pracy zawodowej i je

przestrzegał,� akceptował uzasadnioną krytykę i sam zapewniał odpowiednie

profesjonalne recenzje innym,� dokonywał kompleksowej i szczegółowej oceny systemów

komputerowych oraz ich wpływu, łącznie z analizą potencjalnych zagrożeń,

� honorował kontrakty, umowy i wykonywał przypisane mi obowiązki,� dążył do poprawy zrozumienia informatyki i jej konsekwencji,� używał dostępu do zasobów obliczeniowych i komunikacyjnych tylko

wtedy, gdy jestem do tego upoważniony.

Kodeks etyczny i zawodowy IEEE INŻYNIERIAOPROGRAMOWANIA

� (…)� Jeśli to tylko możliwe, będę unikał rzeczywistych i

potencjalnych konfliktów interesów� Będę rzetelny i realistyczny w formułowaniu ocen i

szacunków opartych o dostępne dane� (…)

źródłó: http://www.ieee.org/portal/pages/iportals/aboutus/ethics/code.html

Kodeks etyczny i zawodowy AITP INŻYNIERIAOPROGRAMOWANIA

� Czuję się zobowiązany wobec procesu zarządzania, zatem będę promował zrozumienie metod i procedur przetwarzania informacji dla zarządzania używając wszelkich dostępnych mi środków.

� Czuję się zobowiązany wobec moich współpracowników, zatem będę przestrzegał wysokich standardów AITP. Ponadto dołożę starań, aby moja współpraca z kolegami z pracy przebiegała zawsze w atmosferze uczciwości i wzajemnego respektu.

� Czuję się zobowiązany wobec społeczeństwa i postaram się uczestniczyć najlepiej jak potrafię w rozpowszechnianiu wiedzy odnoszącej się do ogólnego rozwoju i zrozumienia przetwarzania informacji. Ponadto, nie będę wykorzystywał informacji poufnych dla korzyści osobistych, ani nie będę naruszał prywatności i poufności powierzonych mi informacji oraz informacji, do których mogę mieć dostęp.

� Czuję się zobowiązany wobec mojej szkoły wyższej, wobec czego będę przestrzegał jej zasad moralnych i etycznych.

� Czuję się zobowiązany wobec swojego pracodawcy, który mi zaufał, zatem dołożę wszelkich starań w wypełnianiu obowiązków najlepiej jak potrafię, będę strzegł interesu mego pracodawcy i doradzał mu z rozwagą i uczciwością.

� Czuję się zobowiązany wobec swojego kraju, zatem w osobistych, biznesowych i towarzyskich kontaktach będę służył narodowi i honorował wybór drogi życiowej moich rodaków.

źródło: http://www.aitp.org/organization/about/ethics/ethics.jsp

Dylematy etyczne INŻYNIERIAOPROGRAMOWANIA

� zasadnicza niezgodność z poglądami przełożonego

� lojalność wobec kierownictwa kontra lojalność wobec dobra publicznego

� nieetyczne postępowanie pracodawcy, np. przy fałszowaniu dzienników kontroli podczas testowania systemu krytycznego

� nieetyczne lub kontrowersyjne wymagania klienta na zamówione oprogramowanie

� uczestnictwo w tworzeniu systemów wojskowych i nuklearnych

Bezpieczeństwo zastosowań informatyki INŻYNIERIAOPROGRAMOWANIA

� Safety-Critical Systems

Systemy, które stanowić mogą zagrożenie dla życia ludzkiego lub mogą prowadzić do katastrofy ekologicznej. Przykład: system wspomagający chirurgów czasie operacji bądź pilotów w sterowaniu samolotem.

� Security-Critical Systems

Systemy, które przechowują, przetwarzają i/lub przesyłają krytyczne dane, które muszą być odporne na zakłócenia z zewnątrz. Przykład:systemy bankowe.

� Privacy-Critical Systems

Systemy, które manipulują, przechowują i/lub przesyłają poufne dane osobowe. Przykład: portale społecznościowe, systemy bankowe, inne systemy wymagające od użytkowników podania informacji o sobie.

na podstawie wykładu „Bezpieczeństwo zastosowań informatyki”, J. Górski, ETI/PG

Inżynieria oprogramowania – FAQ (1) INŻYNIERIAOPROGRAMOWANIA

� Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Informatyka obejmuje teorie i podstawowe zasady działania komputerów, a inżynieria oprogramowania obejmuje praktyczne problemy związane z tworzeniem oprogramowania

Inżynier oprogramowania powinien znać teorie informatyczne (algorytmy, struktury danych itp.), z drugiej strony one nie zawsze bezpośrednio przystają do rzeczywistości

� Co to jest CASE (Computer-Aided Software Engineering)?

CASE obejmuje rożne programy wykorzystywane do wspomagania czynności procesu tworzenia oprogramowania (np. edytory notacji, generatory kodów)

Inżynieria oprogramowania – FAQ (2) INŻYNIERIAOPROGRAMOWANIA

� Na czym polegają metody inżynierii oprogramowania?

Polegają na uporządkowanym podejściu do tworzenia oprogramowania, poprzez:

– opisy modeli systemu (np. modele obiektów, modele przepływu)

– reguły (ograniczenia, którym podlegają modele systemu)

– zalecenia (heurystyki określające dobre zwyczaje projektantów)

– poradnictwo (opisy czynności, które należy wykonać)

� Co to jest UML (Unified Modeling Language)?

Jest to formalny język, służący do opisu świata obiektów w analizie obiektowej oraz programowaniu obiektowym; wykorzystuje reprezentację graficzną – symbole wiązane ze sobą na diagramach

Inżynieria oprogramowania – FAQ (3) INŻYNIERIAOPROGRAMOWANIA

� Jakie właściwości ma dobre oprogramowanie?

Konkretny zbiór właściwości zależy od zastosowania, niemniej można podać ogólny zbiór pożądanych właściwości:

– zdolność do pielęgnacji: zdolność do ewolucji, zgodnie z potrzebami klientów

– niezawodność: nie powinno powodować fizycznych lub ekonomicznych katastrof w przypadku awarii

– efektywność: nie powinno marnotrawić zasobów systemu takich jak pamięć czy czas procesora

– użyteczność: powinno być użyteczne, czyli możliwe do wykorzystania bez zbędnego wysiłku ze strony użytkownika

więcej: cykl wykładów o jakości oprogramowania (VII sem.)

Program zajęć z inżynierii oprogramowania (IO) INŻYNIERIAOPROGRAMOWANIA

VI semestr:

Inżynieria oprogramowania (IO, 2w+2l)

VII semestr:

Oprogramowanie aplikacyjne / projekt grupowy (OA/PG; 1w+3l)

IO – program wykładu INŻYNIERIAOPROGRAMOWANIA

• Zagadnienia wstępne – przedmiot badań inżynierii oprogramowania, inżynier oprogramowania• Inżynieria wymagań• Modelowanie procesu wytwarzania oprogramowania. Modele standardowe oraz miękkie (Agile)• Projektowanie obiektowe i architektoniczne• Język UML• Narzędzia CASE• Zarządzanie przedsięwzięciem informatycznym• Zarządzanie personelem• Szacowanie kosztu wytwarzania oprogramowania• Projektowanie systemów rozproszonych• Projektowanie systemów czasu rzeczywistego• Projektowanie systemów krytycznych• Projektowanie z użyciem wielokrotnym• Metody formalne• Wzorce projektowe• Zarządzanie jakością. Metryki oprogramowania. Weryfikacja i zatwierdzanie• Prototypowanie oprogramowania• Zarządzanie konfiguracją (systemy kontroli wersji)• Testowanie oprogramowania. Automatyzacja procesu testowania. Programowanie sterowane testami

Sem. VI / VII(IO / OA/PG)

IO – program laboratorium (model kaskadowy) INŻYNIERIAOPROGRAMOWANIA

Sem. VI (IO)

� idea

� specyfikacja

� projektowanie

� prototypowanie

� implementacja, testowanie jednostkowe

� integracja

� testowanie akceptacyjne

� wdrożenie

� ewolucjawskazany dla osób nie czujących się zbyt dobrze w programowaniu

Sem. VII(OA/PG)

IO – program laboratorium (model zwinny) INŻYNIERIAOPROGRAMOWANIA

� idea

� proces iteracyjny:

specyfikacja ↔ implementacja wybranych funkcjonalności ↔ testowanie jednostkowe

� projektowanie i prototypowanie są zepchnięte na dalszy plan – najważniejszy jest produkt końcowy

� integracja (zwykle jednak nie jest konieczna)

� testowanie akceptacyjne

� wdrożenie

� ewolucja wskazany dla osób biegłych w programowaniu

Sem. VI / VII(IO / OA/PG)

Studium wykonalności INŻYNIERIAOPROGRAMOWANIA

Studium wykonalności to analiza szans i zagrożeń projektu w kontekście sytuacji ekonomicznej i prawnej oraz potencjału wykonawcy. Analiza ma dać odpowiedź m.in. na poniższe pytania:

� Czy i w jaki sposób system przyczyni się do realizacji ogólnych celów przedsiębiorstwa?

� Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu, ograniczeń czasowych, organizacyjnych oraz prawnych?

� Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano w przedsiębiorstwie?

Studium wykonalności – pytania szczegółowe INŻYNIERIAOPROGRAMOWANIA

� Jak firma poradziłaby sobie, jeśli system nie zostałby zaimplementowany?

� Jakie problemy występują w obecnie przyjętych procesach i jak nowy system ma pomóc w ich eliminacji?

� Jaki byłby bezpośredni wkład systemu w osiąganie celów gospodarczych?

� Czy i w jaki sposób można przekazywać informacje do i z innych systemów przedsiębiorstwa?

� Czy system wymaga technologii, których wcześniej w firmie nie stosowano?

� Co system musi wspomagać, a czego nie musi?

Raport wykonalności to opracowanie podsumowujące przeprowadzoną analizę.

Literatura INŻYNIERIAOPROGRAMOWANIA

Literatura podstawowa:I. Sommerville, Inżynieria oprogramowania, WNT 2003J. Górski (red.), Inżynieria oprogramowania w projekcie informatycznym, Mikom 2002

Literatura uzupełniająca:D. Hamlet, J. Maybee, Podstawy techniczne inżynierii oprogramowania, WNT 2003D. Leffingwell, D. Widrig, Zarządzanie wymaganiami, WNT 2003 M. Śmiałek, Zrozumieć UML 2.0. Metody modelowania obiektowego, Helion 2005D.J. Paulish, Zarządzanie architekturocentrycznym procesem tworzenia oprogramowania, WNT 2007J. Shore, S. Warden, Agile Development. Filozofia programowania zwinnego, Helion 2008R. Patton, Testowanie oprogramowania, Mikom 2002B. Wiszniewski, B. Bereza-Jarociński, Teoria i praktyka testowania programów, PWN 2006 R.V. Binder, Testowanie systemów obiektowych, WNT 2003 J. Bentley, Perełki oprogramowania, WNT 2001