Inżynieria Oprogramowania. Robert Szmurło



Podobne dokumenty
Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Wykład 1 Inżynieria Oprogramowania

Inżynieria oprogramowania

KARTA MODUŁU KSZTAŁCENIA

INŻYNIERIA OPROGRAMOWANIA

PRZEWODNIK PO PRZEDMIOCIE

Efekt kształcenia. Ma uporządkowaną, podbudowaną teoretycznie wiedzę ogólną w zakresie algorytmów i ich złożoności obliczeniowej.

Wytwórstwo oprogramowania. michał możdżonek

Egzamin / zaliczenie na ocenę*

Przedsięwzięcia Informatyczne w Zarządzaniu

Zasady organizacji projektów informatycznych

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Podstawy programowania III WYKŁAD 4

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Feature Driven Development

Gry społecznościowe. wykład 0. Joanna Kołodziejczyk. 24 lutego Joanna Kołodziejczyk Gry społecznościowe 24 lutego / 11

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

PRZEWODNIK PO PRZEDMIOCIE

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

Maciej Oleksy Zenon Matuszyk

Projekt systemu informatycznego

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

UCHWAŁA NR 46/2013. Senatu Akademii Marynarki Wojennej im. Bohaterów Westerplatte z dnia 19 września 2013 roku

Uniwersytet Śląski w Katowicach str. 1 Wydział Informatyki i Nauki o Materiałach

Etapy życia oprogramowania

Testowanie oprogramowania

Inżynieria oprogramowania - opis przedmiotu

Narzędzia CASE dla.net. Łukasz Popiel

Faza Określania Wymagań

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Inżynieria Oprogramowania w Praktyce

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś

Efekty kształcenia dla: nazwa kierunku

Cykle życia systemu informatycznego

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Inżynieria oprogramowania (Software Engineering)

DLA SEKTORA INFORMATYCZNEGO W POLSCE

Inżynieria Oprogramowania. Inżynieria Oprogramowania 1/36

Matryca pokrycia efektów kształcenia

Podsumowanie wyników ankiety

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy. Dokumentacja specjalności. Informatyka w systemach produkcyjnych

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Państwowa Wyższa Szkoła Techniczno-Ekonomiczna w Jarosławiu

Odniesienie do efektów kształcenia dla obszaru nauk EFEKTY KSZTAŁCENIA Symbol

SVN. 10 października Instalacja. Wchodzimy na stronę i pobieramy aplikację. Rysunek 1: Instalacja - krok 1

Efekty kształcenia dla kierunku studiów INFORMATYKA, Absolwent studiów I stopnia kierunku Informatyka WIEDZA

Efekty kształcenia dla makrokierunku: INFORMATYKA STOSOWANA Z KOMPUTEROWĄ NAUKĄ O MATERIAŁACH Wydział: MECHANICZNY TECHNOLOGICZNY

Pytania z przedmiotów kierunkowych

Proces tworzenia oprogramowania

Modelowanie i Programowanie Obiektowe

Inżynieria oprogramowania Robert Szmurło

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Spis treúci. 1. Wprowadzenie... 13

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz

PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W NYSIE

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Projektowanie systemów informatycznych. wykład 6

Wstęp. Podstawy inżynierii oprogramowania. Slajdy na podstawie podręcznika: Iana Sommerville a Inżynieria oprogramowania

KIERUNKOWE EFEKTY KSZTAŁCENIA

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

Inżynieria oprogramowania

PRZEWODNIK PO PRZEDMIOCIE

Efekty kształcenia dla studiów I stopnia dla kierunku Informatyka w II UG studia niestacjonarne

PRZEDMIOTY REALIZOWANE W RAMACH KIERUNKU INFORMATYKA I STOPNIA STUDIA STACJONARNE

INŻYNIERIA OPROGRAMOWANIA

Transformacja wiedzy w budowie i eksploatacji maszyn

Załącznik nr 1 do uchwały Senatu PK nr 119/d/12/2017 z dnia 20 grudnia 2017 r.

WPROWADZENIE DO UML-a

PROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem

Kierunek: Informatyka Poziom studiów: Studia I stopnia Forma i tryb studiów: Stacjonarne. Wykład Ćwiczenia

tel. (+48 81) /22 fax (+48 81) Wykład Ćwiczenia Laboratorium Projekt

Efekty kształcenia wymagane do podjęcia studiów 2 stopnia na kierunku Informatyka

Grupa treści kształcenia, w ramach której przedmiot jest realizowany Przedmiot kierunkowy

Efekt kształcenia. Wiedza

Dr Katarzyna Grzesiak-Koped

E-1IZ3-06-s6. Inżynieria Programowania. Informatyka. I stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

Podstawy modelowania programów Kod przedmiotu

Programowanie zespołowe

UCHWAŁA NR 60/2013 Senatu Akademii Marynarki Wojennej im. Bohaterów Westerplatte z dnia 21 listopada 2013 roku

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

Modelowanie i analiza systemów informatycznych

HumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

Informatyczne fundamenty

Kierunkowe efekty kształcenia (wiedza, umiejętności, kompetencje) Kierunek Informatyka

Analiza biznesowa a metody agile owe

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

EFEKTY KSZTAŁCENIA DLA KIERUNKU STUDIÓW INFORMATYKA. STUDIA PIERWSZEGO STOPNIA - PROFIL OGÓLNOAKADEMICKI

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31

Zatwierdzono na Radzie Wydziału w dniu 11 czerwca 2015 r.

Wprowadzenie, podstawowe pojęcia, projekt a produkt Wykład1

Procesowa specyfikacja systemów IT

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig

Transkrypt:

Robert Szmurło 1

Złożoność inżynierii oprogramowania Programowanie komputerowy jest zdecydowanie najbardziej skomplikowanym zadaniem intelektualnym podejmowanym przez człowieka. Kiedykolwiek. Gerald M. Weinberg - Understanding the professional programmer, 1988 Problem: Kod zbudowany jest z wielu tysięcy linii kodu (w przypadku średnich systemów komercyjnych) Instrukcje mogą być pogrupowane w procedury; kod nadal posiada tysiące procedur Procedury są pogrupowane w moduły (klasy, komponenty); kod nadal posiada setki modułów 2

Inżynieria oprogramowania - nie tylko 'kodowanie' Środowisko Klient Programista Model środowiska Oprogramowanie Model oprogramowania 3

Definicja Zastosowanie: systematycznego, zdyscyplinowanego, ilościowego podejścia do rozwoju, eksploatacji, utrzymania oprogramowania. IEEE Std 6 10.12.1990 IEEE Standard Glossary of Software Eng. Terminology 4

Computing Curricula Program nauczania informatyki Struktury dyskretne Podstawy programowania Algorytmy i złożoność Architektura systemów komputerowych Systemy operacyjne Technologie sieciowe Języki i paradygmaty programowania Komunikacja człowiek-komputer Grafika komputerowa Sztuczna inteligencja Bazy danych Problemy społeczne i zawodowe Inżynieria oprogramowania Nauki obliczeniowe 5

Inżynieria oprogramowania - Nauczanie Moduły wchodzące w skład procesu nauczania inżynierii oprogramowania. Obligatoryjne Opcjonalne Wymagania Metody formalne Projektowanie Systemy specjalne Walidacja Komponenty Ewolucja Niezawodność Under auspices of Procesy Zarządzanie Narzędzia API 6

Plan wykładu Wymagania użytkownika i oprogramowania Jakość wymagań oprogramowania Programowanie obiektowe Język UML Statyczne modele architektury Dynamiczne modele architektury Techniki modelowania Zarządzanie (IS) Narzędzia CASE Testowanie oprogramowania Ewolucja oprogramowania 7

Pracodawcy się skarżą Absolwenci nie potrafią się komunikować, Mają niedostateczne przygotowanie do pracy w zespole, Brak im umiejętności skutecznego i produktywnego zarządzania ich pracą indywidualną. 8

Czym jest inżynieria oprogramowania? Inżynieria oprogramowania dotyczy między innymi zarządzania złożonością Złożonością potrzeb klienta Złożonością kodu Złożonością procesu wdrożenia Złożonością procesu ewolucji oprogramowania Inżynieria oprogramowania dotyczy zaspokajania rzeczywistych potrzeb klienta Inżynieria oprogramowania dotyczy organizacji pracy zespołowej Małe zespoły (2-6 osób) Duże zespoły (dziesiątki osób) Rozdzielone zespoły (np. rozwój systemów przez oddziały w różnych krajach) 9

Inżynieria oprogramowania kryterium sukcesu Projekt został wykonany w założonym budżecie Projekt zakończył się w terminie Dostarczony system spełnia rzeczywiste potrzeby klienta System zaspokajający potrzeby Proszę. To są moje potrzeby Projekt systemu informatycznego 10

Kryzys inżynierii oprogramowania Grupa Standish, Chaos Report, 2004 34% - projektów informatycznych zakończonych sukcesem 82% - przekroczenie założonego budżetu 52% - średnia spełnionych wymagań użytkowników Na pierwszej konferencji NATO związanej z inżynierią oprogramowania (1967) stwierdzono: mamy kryzys 11

Typowe objawy choroby projektu Niezadowoleni klienci To nie jest system jakiego oczekiwaliśmy! Żaden z naszych urzędników nie będzie w stanie się nim posługiwać Niezadowoleni dostawcy Czego oni w końcu od nas chcą? Dlaczego oni nieustannie zmieniają zdanie?... ale my odwaliliśmy taki kawał roboty! Konflikty dotyczące zakresu Wymagacie od nas zrealizowania dwa razy większego systemu od tego jaki określiliście w kontrakcie!..., ale te funkcje miały być dotępne dopiero w następnej wersji! Nie dostarczyliście funkcjonalności określonej w paragrafie 7 punkt 8b naszego kontraktu! - Ależ oczywiście, że dostarczyliśmy 12

Typowe objawy choroby projektu Chaotyczna obsługa zmian wymagań koledzy, dodajcie nam tu jeszcze taką małą tabelkę na środku, to was prawie nic nie będzie kosztowało, myśleliśmy, że ta zmiana nie będzie miała dla was istotnego znaczenia Niewyspani programiści poprosimy pizzę pod drzwi o północy i dużo Jolt Coli, dajcie nam dziesięciu nowy programistów Stres pod koniec projektu ten system działa jak żółw, przecież tu brakuje jeszcze funkcji z punktu 10 podpunkt 89 specyfikacji Brak powtarzalności procesu to o ile tym razem przekroczymy budżet? właściwie to jak będziemy tym razem pisać te wymagania? Godzenie się na marsz ku klęsce: musicie ten system zrobić dwa razy szybciej niż konkurencja. OK, damy radę! 13

Typowe przyczyny choroby Niedokładne specyfikowanie wymagań czy ''konto'' oznacza ''konto użytkownika'' czy też ''konto bankowe'', a może ''stan zasobów''? Zła komunikacja to ten formularz jest tak istotny? Brak precyzyjnej architektury to właściwie na której maszynie ma być zainstalowany podsystem wydruków? Brak panowania nad złożonością systemu nasza baza danych ma 1500 tabel, a kod zawiera 2000 klas! Zbyt późne wykrywanie niespójności i dopiero teraz mi mówisz, że ta twoja procedura nie ma parametru Y? Niewystarczające testowanie wygląda na to, że już działa 14

Typowe przyczyny choroby Subiektywizm w ocenach ta specyfikacja jest całkiem dobra Brak kontroli zmian: a właściwie to skąd wynika potrzeba tego nowego formularza? kto grzebał w interfejsie komponentu Z? Niestosowanie narzędzi: nam wystarczy dobre środowisko deweloperskie! Zbyt późna weryfikacja spełnienia wymagań zamawiającego: mogliście się wcześniej zapytać, jaki kolor mają mieć wszystkie ekrany! 15

Lekarstwo na chorobę projektu Jim Johnson, Standish Group Jest coraz lepiej (spójrz na statystyki), ale dlaczego? Ludzie (organizacje zajmujące się rozwojem oprogramowania) zaczynają stosować systematyczne metodyki wytwarzania oprogramowania. Czego więc potrzebujemy? Metodyki! Metodyka grupuje trzy podstawowe elementy w jedną spójną całość: Notacja -język modelowania, za pomocą którego zapisuje się produkty procesu tworzenia oprogramowania (modele). Techniki zbiór sposobów postępowania w celu stworzenia konkretnych elementów modeli (zapisanych za pomocą notacji). Proces techniczny uporządkowanie wytwarzania oprogramowania poprzez wyodrębnienie atomicznych zadań do wykonania (przy użyciu technik) i określenie kolejności oraz zależności między nimi. 16

Notacja dla modelowania wymagań Notacja powinna ograniczać stopień skomplikowania wymagań Notacja powinna być łatwo ulegać transformacji do projektu a następnie kodu Metodyka! Co tworzymy za pomocą notacji? modele, które opisują złożone wymagania użytkownika modele, które pozwalają śledzić złożone zależności między tymi wymaganiami modele, które są zrozumiałe przez użytkowników (rysunek jest wart więcej niż tysiąc słów) modele, które mogą być później użyte przez architektów do projektowania systemu Jaki język pozwala tworzyć takie modele? 17

Notacja redukuje złożoność UML pozwala na abstrakcję pozwala nam skoncentrować się na najbardziej istotnych elementach; pozwala tworzyć ogólne pojęcia definiując je za pomocą mniejszych Miasto Dom Budynek użyteczności publicznej Okno 18

Proces tworzenia oprogramowania Modele procesu tworzenia oprogramowania Iteracja Specyfikowanie oprogramowania Projektowanie i implementowanie oprogramowania Zatwierdzanie oprogramowania Ewolucja oprogramowania Zautomatyzowane wspomaganie procesu 19

Każdy proces uwzglednia Specyfikowanie oprogramowania Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane. Projektowanie i implementowanie oprogramowania Oprogramowanie, które spełnia specyfikację, musi być stworzone. Zatwierdzanie oprogramowania Oprogramowanie musi być zweryfikowane, aby zapewnić, że robi to, czego oczekiwał klient. Ewolucja oprogramowania Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkownika. 20

Modele procesów tworzenia oprogramowania Model kaskadowy W tym modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu takimi jak specyfikowanie wymagań, projektowanie oprogramowania, implementacja, testowanie itd. Tworzenie ewolucyjne (RAD) W tym procesie czynności specyfikowania, projektowania i zatwierdzania przeplatają się. Pierwsza wersja systemu powstaje bardzo szybko na podstawie abstrakcyjnych specyfikacji. Później jest udoskonalana zgodność z informacjami otrzymanymi od klienta. Tworzenie formalne systemu (modelowanie) To podejście jest oparte na budowaniu formalnych matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program za pomocą metod matematycznych. Weryfikacja zgodności komponentów polega na wnioskowaniu matematycznych o ich zgodności ze specyfikacją. Tworzenie z użyciem wielokrotnym (linie produkcyjne) W tym podejściu zakłada się istnienie dużej liczby komponentów zdatnych do ponownego użycia. Proces budowy systemu polega głównie na integrowaniu tych fragmentów, a nie na tworzeniu ich od początku. 21

Model kaskadowy 22

Tworzenie ewolucyjne Równoległe czynności Specyfikacja Ogólny Ogólnyopis opis Tworzenie Zatwierdzanie Wersja początkowa Wersje Wersje Wersje pośrednie pośrednie pośrednie Wersja końcowa 23

Tworzenie formalne Tworzenie formalne systemów Definicja wymagań Specyfikacja formalna Integracja i testowanie systemu Przekształcenia formalne Przekształcenia formalne T1 Specyfikacja formalna T3 R1 P1 T2 R2 P2 T4 Program wykonywalny R3 P3 P4 24

Tworzenie z użyciem wielokrotnym Specyfikacja wymagań Analiza komponentów Modyfikacja wymagań Tworzenie i integracja Projekt systemu z użyciem wielokrotnym Zatwierdzanie systemu 25

Tworzenie spiralne 26

Podstawy modelowania UML Diagram klas Diagram pakietów Diagram komponentów Diagram przypadków użycia Diagram czynności Diagram sekwencji Diagram obiektów Diagram wdrożenia Diagram komunikacji Diagram stanów 27

Diagram klas 28

Diagram pakietów 29

Diagram komponentów 30

Diagram przypadków użycia 31

Diagram czynności 32

Diagram sekwencji 33

Diagram stanów 34

Techniki wyodrębniana oraz specyfikowania wymagań Analiza dokumentów Zapoznanie się z dokumentami dostarczonymi przez klienta w celu odkrycia rzeczywistych potrzeb Podkreślanie rzeczowników i czasowników Określanie niektórych paragrafów jako wymagań Metodyka! Praca bezpośrednio z klientem Spotkania i rozmowy z klientem oraz przyszłymi użytkownikami Praca grupowa Grupowe sesje modelowania wymagań: użytkownicy, analitycy określają i zapisują wymagania za pomocą określonej notacji Burze mózgów 35

Cykl życia podejście inżynierskie Wymagania Projekt Implementacja 36

Inżynieria wymagań Proces: Wymagania 37

Imżynieria wymagań Wymagania Wymagania funkcjonalne Wymagania pozafunkcjonalne 38

Interakcja Dziękuję za uwagę. Chcemy być coraz lepsi! Jeżeli coś cię zainteresowało napisz e-maila: robert@iem.pw.edu.pl Jeżeli coś cię bardzo znudziło napisz e-maila: robert@iem.pw.edu.pl Jeżeli zauważyłeś błąd napisz e-maila: robert@iem.pw.edu.pl 39