Inżynieria oprogramowania
Inżynieria oprogramowania
Wykład wprowadzający
Aleksander Jarzębowicz
Katedra Inżynierii Oprogramowania
Wydział ETI, Politechnika Gdańska
slajd: 1
Inżynieria oprogramowania
Informacje kontaktowe
dr inż. Aleksander Jarzębowicz
Katedra Inżynierii Oprogramowania
pokój 648 gmach ETI
e-mail: [e-mail]
tel. 1464
konsultacje:
wtorek 13:15  14:00
czwartek 12:15  13:00
slajd: 2
Inżynieria oprogramowania
Zespół przedmiotu
Katedra Inżynierii Oprogramowania WETI
 wykład: dr inż. Aleksander Jarzębowicz
dr inż. Anna Bobkowska
 zajęcia laboratoryjne: dr inż. Anna Bobkowska
dr inż. Agnieszka Janczulewicz (Inż. Biomed.)
dr inż. Aleksander Jarzębowicz
mgr inż. Katarzyna A
ukasiewicz
mgr inż. Alan Turower
 udział w opr. slajdów: mgr inż. Maciej Piechówka
dr inż. Stanisław Szejko
slajd: 3
Inżynieria oprogramowania
Zaliczenie
Jedna ocena końcowa z przedmiotu
 50 % punkty z egzaminu i 50 % punkty z laboratorium
 dopuszczenie do egzaminu pod warunkiem zaliczenia laboratorium
Egzamin  część teoretyczna (materiał z wykładów) i część zadaniowa
(modelowanie w UML, zakres pokrywający się z laboratorium),
2 terminy.
Laboratorium  Udział punktów: 60% za zadania, 40% za sprawdziany, wymagane
jest uzyskanie min. 50% punktów, w tym pozytywnej oceny
każdego z zadań.
Przypadki szczególne:
" powtarzanie przedmiotu
" awanse (IOS)
" osoby spoza list
slajd: 4
Inżynieria oprogramowania
Organizacja - wykład
" Materiały w postaci slajdów wykładowych
dostępne, przekazywane przed wykładem
(Moodle)
" Alternatywny kanał  maile do starostów,
publikacja informacji na forum
" Cały zakres wiadomości wymaganych na
egzaminie będzie prezentowany na wykładach...
" ... co nie znaczy, że każda istotna informacja musi
być zapisana na slajdach wykładowych
slajd: 5
Inżynieria oprogramowania
Organizacja - laboratoria (1)
" Harmonogram zajęć laboratorium, wraz z terminami oddania
poszczególnych ćwiczeń i punktacją jest dostępny na stronie
przedmiotu na witrynie ETI
" Aktywizujący tryb pracy w postaci cykli:
 informacje na wykładzie
 sprawdzian na laboratorium
 omówienie przykładu
 samodzielne zadanie
" Oddawanie zadań po terminie powoduje obniżenie oceny (punkty
karne)
" Sprawdziany krótkie (5 min) na początku zajęć, nie przewiduje się
poprawek, ani dodatkowych terminów (poza sytuacjami
usprawiedliwionej nieobecności)
slajd: 6
Inżynieria oprogramowania
Organizacja - laboratoria (2)
" Terminy laboratoriów:
 Informatyka i Inżynieria Biomedyczna osobno
 Każda grupa dziekańska ma 2 dostępne terminy
 Równomierny podział pomiędzy tymi terminami
 Studenci spoza grupy mogą uczestniczyć w przypadku dostępności
miejsc i uzyskania zgody prowadzącego zajęcia laboratoryjne
 Ewentualnie zamiana 1:1
" Kwestia obecności...
" Więcej informacji od prowadzących poszczególne
terminy laboratoryjne
slajd: 7
Inżynieria oprogramowania
Ale o co chodzi?
" Kto to jest inżynier?
" Inżynieria (def. słown.) - nauka wykorzystująca
matematykę, technologię i praktyczne doświadczenie do
projektowania, produkowania i kontrolowania obiektów
bądz
procesów służących człowiekowi
" Inżynieria (def. prakt.) - oznacza działania podlegające
planowaniu oraz bazujące na technikach systematycznych
i powtarzalnych
" Po co inżynier przy budowie systemu informatycznego?
" A po co inżynier przy budowie domu albo mostu?
slajd: 8
Inżynieria oprogramowania
Zderzenie perspektyw
Student II-III roku Praktyka przemysłowa
" Brak doświadczeń zawodowych lub " Profesjonalna działalność w obszarze
w niewielkim zakresie wytwarzania oprogramowania
" Niewielki rozmiar tworzonego " Złożone systemy (mikro: do 10PM,
oprogramowania małe: 10-100PM, duże:>1000PM)
" Praca indywidualna, ewentualnie z " Zespoły kilku (-nasto, -dziesięcio, -
kolegą set) osobowe
" Brak rzeczywistego klienta (praca " Rzeczywisty klient mający określone
dla siebie albo dla wykładowcy) potrzeby i wymagający!
" Problemy skoncentrowane wokół " Problemy skoncentrowane wokół
technologii lub zagadnień zastosowań, potrzeb biznesowych.
akademickich Technologia jako środek do celu
" Brak konieczności utrzymania " Produkt utrzymywany, rozwijany
produktu nierzadko przez lata
slajd: 9
Inżynieria oprogramowania
Przedsięwzięcia inżynierskie - analogie
" Analogia projektu informatycznego do przedsięwzięcia
budowlanego
" Problem skali  budowa altanki na działce a budowa
centrum handlowego
" Nie tylko bezpośrednie prace konstrukcyjne, inne obszary
do uwzględnienia to np.:
 Negocjacje z klientem, komunikacja
 Planowanie przedsięwzięcia, harmonogram, przydział zasobów
 Pozyskanie wymagań
 Zaprojektowanie budowli (plany, modele, obliczenia)
 Zarządzanie przedsięwzięciem (bieżący nadzór, reagowanie na problemy)
 Zapewnienie jakości (niezawodność, spełnienie norm)
 Kwalifikacje pracowników, uprawnienia, szkolenia
 Narzędzia i technologie
slajd: 10
Inżynieria oprogramowania
Dodatkowy czynnik - specyfika
" Kwestia skali i złożoności każdego przedsięwzięcia
konstrukcyjnego wymuszającego podejście
inżynierskie w różnych dziedzinach
 budownictwo
 mechanika
 elektronika
 przemysł chemiczny
 ...
" Kwestia dodatkowa  specyfika oprogramowania ...
slajd: 11
Inżynieria oprogramowania
Na czym polega specyfika
oprogramowania? (1)
" zdominowane przez proces projektowania
 pomijalne nakłady na produkcję, większość wysiłku skierowana
na projektowanie; niedojrzała technologia, kompetencje ?
" trudności w wizualizacji
 oprogramowanie to  niematerialny wytwór intelektu ; trudności
w obserwacji wcześniejszych form (specyfikacji wymagań, projektu,
...), wąskie perspektywy takich form (np. projekt GUI, algorytm)
" nie zużywa się
 nie zużywa się; wadliwe działanie wynika z niedopasowania do
środowiska, z błędów konstrukcji, często ujawniających się bardzo
póz
no
" duża złożoność
 trudno znalez
ć standardy projektowe, trudno prześledzić wszystkie
sytuacje, wypuścić produkt pozbawiony błędów
slajd: 12
Inżynieria oprogramowania
Specyfika oprogramowania (2)
" dowolność struktury
 zwykle niewielkie ograniczenia i duże pole do popisu projektantów -
złożoność, nieregularność, niezrozumiałość struktury - trudności
modyfikacji i pielęgnacji
" zależność elementów
 niejawne zależności pomiędzy elementami prowadzą do trudności
konstrukcyjnych, błędnych ocen poprawności oprogramowania,
stwarzają problemy modyfikacji i pielęgnacji
" brak ograniczeń (np. prawami fizyki)
 nieznaczna zmiana może spowodować duże odchylenie;  mała
modyfikacja ?  przybliżona analiza ?
" łatwość zmian
 łatwość dokonywania zmian prowadzi do chaosu, błędów i
bylejakości
" profil wytwórcy
 produkcja wymaga wysokich kwalifikacji i umiejętności, czasem
jednak trudno ograniczyć dowolność
slajd: 13
Inżynieria oprogramowania
Specyfika oprogramowania (3)
" Przykład specyfiki:
" Pytanie - Co zrobić kiedy przedsięwzięcie jest
opóz
nione i widać, że nie  wyrabiamy się na
uzgodniony termin?
" Odpowiedz
(typowa)  Zaangażować większą liczbę
ludzi!
" Brutalna rzeczywistość  w projekcie
informatycznym prawdopodobnie jeszcze pogorszy
to sytuację
slajd: 14
Inżynieria oprogramowania
Specyfika oprogramowania (4)
" Kolejny przykład specyfiki:
" Pytanie  Jak oszacować postęp przedsięwzięcia?
" Odpowiedz
(typowa)  Zapytać wykonawcę o
stopień zaawansowania!
" Brutalna rzeczywistość  typowy projekt
informatyczny szacowany w ten sposób jest
ukończony w 90% przez 90% czasu jego trwania
slajd: 15
Inżynieria oprogramowania
Efekt ?
Główne problemy:
niepełna funkcjonalność, kiepska użytkowość,
słaba możliwość dostosowania do potrzeb
za długo trwa przygotowanie oprogramowania
za dużo kosztuje
slajd: 16
Inżynieria oprogramowania
Przykładowy projekt...
slajd: 17
Inżynieria oprogramowania
Wyniki przedsięwzięć informatycznych
 Chaos Report grupy Standish, rok 2009 1994: 16S 53C 31F
2006: 35S 45C 19F
Failed
24%
Successful
Why projects fail so often?
32%
* Unrealistic or unarticulated project goals
* Inaccurate estimates of needed resources
* Badly defined system requirements
* Poor reporting of the project's status
* Unmanaged risks
* Poor communication among customers,
developers, and users
* Use of immature technology
* Inability to handle the project's complexity
* Sloppy development practices
* Poor project management
* Stakeholder politics
* Commercial pressures
Charette Robert N. Why software fails,
Challenged
IEEE Spectrum, Sept 2005
44%
slajd: 18
Inżynieria oprogramowania
Procentowy rozkład błędów
popełnianych przy konstrukcji systemów
slajd: 19
Inżynieria oprogramowania
Koszt defektów w czasie (reguła 1:10)
K
Użytkowanie
o
i Pielęgnacja
s
z
t
J. Górski
100-1000x
D
Budowa
e
f
Definicja
e
10-100x
k 1x
t
Faza usunięcia defektu
u
Analogia do defektów w innych dziedzinach inżynierskich&
WNIOSEK: lekceważenie wczesnych etapów projektu informatycznego
to ryzyko nadmiarowej pracy!
slajd: 20
Inżynieria oprogramowania
Geneza problemu
" Zamierzchłe czasy  2 połowa lat 60
" Rozwój sprzętu i języków programowania
" Oprogramowanie użytkowe, interaktywne,
wspomagające procesy (zamiast czystych obliczeń,
przetwarzania wsadowego)
" Wzrost rozmiaru i złożoności tworzonego
oprogramowania
" Obserwacja: Rozwój technik budowy
oprogramowania nie nadąża za rozwojem
technologicznym
slajd: 23
Inżynieria oprogramowania
A kilkadziesiąt lat póz
niej...
" Rewolucja informacyjna - zastosowania informatyki
 transport, produkcja, obsługa pieniądza, ochrona zdrowia, administracja,
rozrywka, telekomunikacja, ...
" Oczekiwania (głównie jakościowe)
 wysoce niezawodne, bezpieczne
 użyteczne, łatwe w użyciu, trudne do użycia w sposób niewłaściwy
 tanie, dostępne, . . .
" Dynamika zmian (biznes, usługi, oferta) -> odzwierciedlenie w systemach inf.
Zastosowania
Oczekiwania
Technologie
Procesy
Metody
wytwarzania
slajd: 24
Inżynieria oprogramowania
Wnioski
" Analogia pokazuje, że w przypadku przedsięwzięć
inżynierskich większej skali potrzebny jest szereg
metodycznych działań umożliwiających ich skuteczną
realizację
" Istnieje jednak dodatkowa specyfika oprogramowania
i co za tym idzie projektów informatycznych, która
generuje dodatkowe problemy i wymaga znacznie
bardziej (w stosunku do innych obszarów
inżynierskich) zaawansowanych metod radzenia sobie
z tymi problemami.
slajd: 25
Inżynieria oprogramowania
Potrzeby  wymagania dot. kształcenia
" Postulowane programy nauczania
informatyki (curricula)  ACM,
IEEE
" Programy nauczania IO:
 SWEBOK (Software Engineering Body
of Knowledge)
 GSwERC / GSwE2009 (Graduate
Software Engineering)
 Polskie normy MNiSzW
slajd: 26
Inżynieria oprogramowania
Potrzeby  oczekiwania pracodawców
" Informacje zwrotne od pracodawców (większe firmy) nt.
absolwentów studiów informatycznych:
 Zwykle dobrze przygotowani od strony technologii, ale...
 Trudność pracy zespołowej
 Trudności w dostosowaniu się do wymogów procesu,
standardów pracy
 Problemy z komunikacją (szczególnie zewnętrzną, z klientem)
 Trudność w analizie problemu (zbyt szybkie skupienie na
rozwiązaniu)
 Radzą sobie z tworzeniem oprogramowania od podstaw, dużo
gorzej z rozwojem/utrzymaniem istniejących systemów
slajd: 27
Inżynieria oprogramowania
Perspektywy kariery
" Na szeregowym programiście świat się nie kończy...
" Analityk, projektant, quality assurance, kierownik projektu, ...
slajd: 28
Inżynieria oprogramowania
Wykład
Cele wykładu:
" Przekazanie wiedzy nt. budowy rzeczywistych
systemów informatycznych i metodycznego
wytwarzania oprogramowania
" Przybliżenie obszarów praktyki wytwarzania
oprogramowania innych niż implementacja
(kodowanie)
" Nauka tworzenia abstrakcyjnych modeli
systemów, w szczególności modeli tworzonych za
pomocą obiektowej notacji UML (Unified
Modeling Language)
slajd: 29
Inżynieria oprogramowania
Laboratorium
Cele laboratorium:
Ćwiczenia:
" Praktyczna nauka posługiwania się " Przygotowanie założeń
wstępnych budowy systemu;
notacją UML
tworzenie Wzbogaconego
" Zapoznanie z narzędziami CASE
Wizerunku
" Nabycie umiejętności analizy
" Modelowanie za pomocą
postawionego problemu i
przypadków użycia (use-
udokumentowania tego w postaci cases)
odpowiednich modeli UML
" Budowa modelu klas
" Nauka przejścia od modeli
" Modelowanie zachowania
analitycznych w kierunku projektu (dynamiki systemu)
systemu i implementacji
" Weryfikacja modeli
" Projektowanie
slajd: 30
Inżynieria oprogramowania
Ścieżka kształcenia  Informatyka WETI
Pojęcia
Techniki
Metody
Inżynieria Oprogramowania
Narzędzia
Modelowanie
Wybrane metodyki
Realizacja Projektu Informatycznego
RUP
Scrum
XP
Mini-przedsięwzięcie
Zespołowy Projekt Inżynierski
w praktyce
slajd: 31
Inżynieria oprogramowania
Literatura
" Sommerville I., Software Engineering, 9th edition, 2010 (wydanie
polskie WNT 2003)
" Pressman R., Software Engineering: a Practitioner s Approach,
McGraw-Hill, 7th edition, 2010 (wydanie polskie WNT 2004)
" Górski J. (red.): Inżynieria oprogramowania w projekcie
informatycznym, MIKOM, 2000
" Booch G., Rumbaugh J., Jacobsen I.: UML przewodnik
użytkownika, WNT, 2001
" Fowler M., Scott K.: UML w kropelce 2.0 (ang. UML distilled), Lupus
2005.
" Maciaszek L.: Requirements analysis and system design, Addison-
Wesley, 2007
" McLaughlin B., Pollice G., West D., Head First: Object-Oriented
Analysis and Design, Edycja polska (Rusz głową!), Helion, 2008
slajd: 32