Organizacja - - klucz Moodle IO1902 witryna.mimuw.edu.pl - projekty tworzone na wydziale

Transkrypt

1 Inżynieria oprogramowania Strona 1 Organizacja 19 lutego :01 1) 2) 3) klucz Moodle IO1902 witryna.mimuw.edu.pl projekty tworzone na wydziale Laboratoria zespoły mniej więcej 4 osobowe projekt i kompilowany szkielet / prototyp projekt systemu a. wizja b. specyfikacja c. koncepcja d. plan jakości e. plan projektu zarządzanie komunikacją szkielet / prototyp (kompilowalny, uruchamialny) Egzamin pytania testowe wielokrotnego wyboru z punktami ujemnymi uzupełnianie projektowanie ocena koocowa to (~50%) ocena z laba + ocena egzaminu (~50%)

2 Inżynieria oprogramowania Strona 2 Wstęp 19 lutego :36 Inżynieria oprogramowania zastosowanie systematycznego zdyscyplinowanego ilościowego podejście do rozwoju, eksploatacji, utrzymywania oprogramowania inżynieria oprogramowania: wymagania projektowanie walidacja ewolucja procesy Zarządzanie narzędzia API metody formalne systemy specjalne komponenty niezawodnośd dalej: Zarządzanie Projektami Informatycznymi (monograf) Wytwarzanie Systemów Informatycznych (seminarium) Model wodospadowy zadziała przy produkcji sterownika, nie zadziała przy banku internetowym model dobry przy dokładnej specyfikacji smoke test prosty test uruchomieniowy Model prototypowany

3 Inżynieria oprogramowania Strona 3 nadaje się do większych projektów Model przyrostowy ERP Enterprise Rosource Planning iterujemy tworząc kolejne wersje duży projekt składa się z wielu małych model bezpieczny coś będzie działad może nie wszystko, ale jakieś składniki Model ewolucyjny zbieramy wymagania, produkujemy za jakiś czas znów zbieramy wymagania i znów produkujemy kolejną wersję w oparciu o wcześniejsze doświadczenia Model spiralny

4 Inżynieria oprogramowania Strona 4 budżet rośnie z czasem, tworzymy kolejne wersje zgodnie z napływającymi wymaganiami de facto Agile Model V analiza i projektowanie, później testowanie i integracja, testy i integracja silnie związane z powstawaniem wymagao Model UP (Unified Process)

5 Inżynieria oprogramowania Strona 5 Rational planowanie wstępne, iteracje analizy, zbierania wymagao i produkcji, wersja ostateczna filozofia jest taka, że cały czas zajmujemy się wszystkim, ale z różnym natężeniem cały czas utrzymujemy skompilowany system, testy itd. nightly build projekt cały czas się kompiluje Model CMMI (Capability Maturity Model Integration) model porównywania dostawców na każdym poziomie znajdują się praktyki, które są realizowane przez dostawcę Model XP (extreme Programming) klient wymienia cechy oprogramowania programista ustala zadania i pracochłonnośd programiści programują w parach Przygotowują testy jednostkowe Dodają funkcjonalnośd sprawdzając testy jednostkowe Naprawiają błędy jeśli testy są spełnione później integracja i produkcja klient ustala zadania do zrealizowania w najbliższym wydaniu klient prowadzi testy akceptacyjne programiści uaktualniają model szacowania pracochłonności na podstawie zebranych

6 Inżynieria oprogramowania Strona 6 programiści uaktualniają model szacowania pracochłonności na podstawie zebranych doświadczeo Esencja

7 Inżynieria oprogramowania Strona 7 Specyfikacje 26 lutego :45 Model a metodyka model ma za zadanie upraszczad diagram bardzo ogólny model to nie programowanie wizualne metodyka zbiór dobrych praktyk Podejście abstrakcja dekompozycja Analiza i projektowanie analiza znajdowanie i opisywanie bytów / pojęd z dziedzin problemu projektowanie definiowanie elementów oprogramowania i sposób, w jaki b ędą współpracowad w celu spełnienia wymagao specyfikacja odpowiada na pytanie "co" definicja problemu umowa pomiędzy dostawcą a zamawiającym projekt odpowiada na pytanie "jak" definicja rozwiązania czego chcemy uniknąd optimist of yought: We can do it over the weekend Marine Corps mentality: Real programmers don't need sleep metodyki o różnym poziomie formalizmu lekkie (small scale projects, 3 6 osób, 3 6 miesięcy) Agile Software Development (metodyka adaptacyjne) zasady dostosowywane w trakcie średnie(medium scale projects, osób, 1 2 lata) Unified Process ciężkie (large scale projects, osób, 3 5 lat) Capability Maturity Model Integration projekt jest dostosowywany do metodyki Agile Software Development wymaganie będą się zmieniad trzeba pracowad ze zamawiającymi softwarem miarą postępu w projekcie jest działający software jakośd zapewniana poprzez prostotę projektu Capability Maturity Moodel Integration bardzo formalnie dokładne opisy procesu decyzyjnego Unified Process

8 Inżynieria oprogramowania Strona 8 Unified Process 1) 2) 3) business modeling dobre rozpoznanie rzeczywistości requirements rozpoznanie wymagao software należy robid iteracyjnie configuration & change managemt konfiguracja czy pasuje do siebie kompilator, system i kod oprogramowanie należy dzielid na komponenty implementacje <> interfejsy implementacja komunikują się ze sobą tylko za pomocą interfejsów projektowanie wizualne Specyfikacja forma kontraktu pomiędzy producentem a klientem pomiędzy zarządzającymi a programistami pomiędzy architektami a programistami jest potrzebna gdy: istnieje niebezpieczeostwo niezrozumienie się gdy realizujemy potrzeby więcej niż jednej osoby gdy więcej niż jedna osoba pracuje nad projektem staramy się unikad założeo niejawnych i ogólników (duży ekran) scenariusze Przykład dobrej praktyki budujemy drzewo wizja powinna byd definiowana czasem, który chcemy przeznaczyd na jej tworzenie np. spisujemy to, o wymyślimy przez tydzieo procesy biznesowe czynności poza systemem automatyzacja przypadki użycia aktorzy scenariusz główny scenariusze alternatywne modele zależności Modle a metodyka model > co?

9 Inżynieria oprogramowania Strona 9 1) 2) 3) Modle a metodyka model > co? metodyka > jak? problem kompletności oprogramowania czy zrobiliśmy wszystko, co trzeba czy programiści napiszą to, co trzeba Budowa wizji podejście wszerz, a nie wgłąb wymagania systemowe funkcjonalne pozafunkcjonalne słownikowe ograniczenia wymagania zamawiającego wizja systemu Wizja problem możliwe rozwiązania wybranie rozwiązania budowa systemu IT opis działania organizacji za pomocą procesów biznesowych przykłady wymagao pozafunkcjonalnych wersje językowe przyjaznośd użytkownikowi zdarzenia losowe niezawodnośd wydajnośd wymagania powinny zostad zdefiniowane w sposób weryfikowalny Inżynieria wymagao etapy: 1) wydobywanie wymagao w oparciu o model biznesu 2) analiza i negocjacja wymagao 3) zatwierdzanie wymagao 4) zarządzanie zmianami wymagao Specyfikacja specyfikacja jest rodzajem kontraktu oprogramowanie musi byd wyspecyfikowane gdy: istnieje niebezpieczeostwo niezrozumienia lub zapomnienia o potrzebach klienta reprezentowane są potrzeby więcej niż jednej osoby więcej niż jedna osoba wytwarza oprogramowanie kolejnośd działao: 1) wizja 2) procesy biznesowe 3) przypadki użycia 2 i 3 opisują funkcjonalnośd poza tym należy jeszcze pomyśled o wymaganiach pozafunkcjonalnych Proces biznesowy ludzki opis procedury musi wynikad z wizji scenariusz wykonywania systemu z punktu widzenia firmy Przypadek użycia powinien wynikad z procesu biznesowego scenariusz wykonania z punktu widzenia systemu

10 Inżynieria oprogramowania Strona 10 scenariusz wykonania z punktu widzenia systemu niekiedy zdarzenia prowadząc w różnych kierunkach (w zależności od decyzji użytkownika) scenariusz to jedno z wystąpieo przypadku użycia scenariusz główny podstawowy przebieg przypadku użycia scenariusze alternatywny inne przebiegi przypadku użycia budowa dobrego przypadku użycia fraza czasownikowa w nazwie aktor, scenariusz, rozszerzenia nadrzędny cel czytelnośd scenariusz główny najbardziej prawdopodobna ścieżka alternatywne scenariusze kiedy coś pójdzie nie tak obojętnośd technologiczna Wizja składniki: 1) postawienie problemu 2) motto dla systemu 3) osoby zainteresowane, kluczowi użytkownicy 4) główne cechy oprogramowania 5) główne ograniczenia środowiska FURPS: wymagania funkcjonalne functionality usability wymagania pozafunkcjonalne reliability performance security Functionality Feature set, Capabilities, Generality, Security Usability Human factors, Aesthetics, Consistency, Documentation Reliability Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure Performance Speed, Efficiency, Resource consumption, Throughput, Response time Supportability Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability Wymagania pozafunkcjonalne przenośnośd efektywnośd komunikatywnośd ustrukturyzowanie wydajnośd odpornośd na błędy modularnośd Dobra specyfikacja poprawnośd czy tak ma działad system czy są to faktyczne wymagania jednoznacznośd czy wymagania mają tylko jedną interpretację każde stwierdzenie może byd odczytane dokładnie w jeden sposób pojęcia mylące definiowane są w słowniku jest przejrzysta (zrozumiała dla nieinformatyków) kompletnośd czy zamieszczono wszystkie wymagania funkcjonalne i pozafunkcjonalne brak elementów wymagających uzupełnienia (kompletnośd strukturalna) określa wszystkie rzeczy, które system ma robid oraz wszystkie rzeczy, których robid nie ma koniecznośd

11 Inżynieria oprogramowania Strona 11 a) b) 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) koniecznośd czy zawiera wszystkie elementy istotne dla zamawiającego czy nie zawiera elementów niepotrzebnych spójnośd czy wymagania zamawiającego są zgodne z wizją i niesprzeczne ze sobą czy nie przeczy sobie jednolicie korzysta z pojęd możliwośd porządkowania (priorytetyzacja) atrybuty umożliwiające określenie wagi i znaczenia weryfikowalnośd czy każde wymaganie ma przyporządkowane kryterium jakości istnieje procedura pozwalająca przetestowanie każdego z wymagao każde wymaganie jest opisane deklaratywnie modyfikowalnośd czy można w łatwy sposób wprowadzad zmiany do specyfikacji wymagao dobrze zorganizowana minimalna redundancja możliwośd śledzenia coupling factor współczynnik zależności pomiędzy modułami utrzymywanie śladu zachowywanie zależności z wcześniej otrzymanymi fragmentami dokumentacji specyfikacja wynika z przypadków użycia Jeden system różne perspektywy struktura 1) model logiczny 2) kod wynikowy 3) warstwa fizyczna zachowanie 1) przypadki użycia 2) algorytmy działania 3) interakcje między obiektami 4) maszyny stanowe rozłączne tworzenie specyfikacji i projektu pozwala na późniejszą weryfikację całości Co jest najważniejsze dla sukcesu projektu? Wiarygodne oszacowanie Jasne cele biznesowe Doświadczony menedżer Wykwalifikowany zespół Zaangażowanie użytkowników Stałe ograniczenie zakresu Formalna metodyka Zaangażowanie użytkowników Elastyczne podejście do wymagao Standardowa architektura model trójwarstwowy: model warstwa składowania widok warstwa prezentacji kontroler logika systemu Abstrakcja i dekompozycja abstrakcja upraszcza problem analogie ukrywanie szczegółów nie rozwiązuje problemu dekompozyjca podproblemu podobnej wielkości podproblemy można rozwiązywad niezależnie

12 Inżynieria oprogramowania Strona 12 podproblemu podobnej wielkości podproblemy można rozwiązywad niezależnie ze składania rozwiązao podproblemów otrzymuje się rozwiązanie problemu Zalety można przypisad podzadania różnym osobom podzadania można rozwiązywad równolegle łatwo utrzymywad system w przyszłości można ukryd nieistotne szczegóły Wady scalanie podrozwiązao może stanowid problem problem źle zrozumiany nie da się dobrze zdekomponowad ukrywanie szczegółów nie rozwiązuje problemu Perspektywy UML diagram pakietów diagram klas i diagram obiektów diagram struktur złożonych diagram komponentów diagram wdrożenia diagram przypadków uzycia diagram czynności diagram maszyny stanowej diagramy interakcji (sekwencji, komunikacji, przeglądu interakcji) diagram uwarunkowao czasowych

13 Inżynieria oprogramowania Strona 13

14 Przypadki użycia Inżynieria oprogramowania Strona 14

15 Inżynieria oprogramowania Strona 15 Przypadki użycia Model dziedzinowy / klas / interfejsów / danych

16 Inżynieria oprogramowania Strona 16 UML definiuje 4 poziomy widoczności cech i metod + publiczny element jest widoczny z każdego miejsca w systemie # chroniony element jest widoczny we własnej klasie i jej podklasach prywatny element jest widoczny tylko we własnej klasie ~ publiczny wewnątrz pakietu element jest widoczny tylko wewnątrz własnego pakietu Maszyna stanowa

17 Inżynieria oprogramowania Strona 17 Maszyna stanowa Interakcje

18 Aktywnośd Inżynieria oprogramowania Strona 18

19 Komponenty, wdrożenie Inżynieria oprogramowania Strona 19

20 Warstwy Inżynieria oprogramowania Strona 20

21 Inżynieria oprogramowania Strona 21

22 Inżynieria oprogramowania Strona 22 Architektury 19 marca :33 1) 2) 3) 1) 2) 3) 4) 5) 6) MTBF Mean Time Between Failures Edgar Dijkstra how software is partitioned and structured is important not merely simply programming a correct solution Fred Brooks System Architecture by the architecture of the system I mean the complete and detailed specification of the user interface the architect of a system, like the architect of a building, is the user s agent David Parnas information hiding as the basis of decomposition for ease of maintenance and reuse the separation of interface from implementation of components observations on the separate character of different program elements the uses relationship for controlling the connectivity between components principles for the detection and handling of errors, i.e. exceptions identifying commonalities in families of systems to provide coarsegrained, stable common structures recognition that structure influences nonfunctional qualities of a system Przetwarzanie potokowe (pipe and filter) kolekcja programów ułożona w łaocuch przykład: Latex Klient serwer logika i większośd obliczeo jest realizowana u klienta przykład: gry sieciowe, Outlook Peer to Peer sied zestawiana adhoc Architektura trójwarstwowa (3 tier) warstwa danych warstwa logiki warstwa prezentacji Architektura wielowarstwowa (n tier) prezentacja a. okienka UI b. HTML, XML, JSP, Javascript aplikacja a. workflow, stan sesji, zmiana stron / okien b. obsługuje żądania warstwy prezentacji dziedzina (biznes, usługi biznesowe, model) a. obsługuje zadania warstwy aplikacji b. usługi dziedziny (Kasa, Magazyn) c. może byd wykorzystywana przez kilka aplikacji infrastruktura biznesowa (niskopoziomowe usługi biznesowe) a. niskopoziomowe usługi biznesowe wykorzystywane w wielu dziedzinach usługi techniczne a. bezpieczeostwo, utrwalanie b. wysokopoziomowe usługi techniczne podstawy a. struktury danych, obsługa wątków b. niskopoziomowe usługi techniczne Perspektywa historyczna

23 Inżynieria oprogramowania Strona 23 Perspektywa historyczna Sevice oriented architecture functionality ważniejsze od connectivity ery architektury 1) mainframe 2) klient serwer 3) Web 4) SOA osiągamy przełom technologiczny pomiędzy mocą obliczeniową a możliwością łączności SOA składanie usług zaawansowanych z rozproszonych usług sieciowych Usługa usługi tworzą rozróżnialne poprzez standaryzację klasy abstrakcji katalogi dobrze zdefiniowane samowystarczalne zawsze i łatwo dostępne niezależne od kontekstu konsumenta nie jest istotne, kto jest klientem bardzo konkurencyjne konkurowanie zakresem a nie sposobem implementacji można łączyd EDI elektroniczny obieg dokumentów BPM business process managing (procesy biznesowe) WS web services Workflow obieg informacji, obieg zadao podobne klocki składa się w nowe narzędzia Aktorzy konsument wyraża zamiar dostawca udostępnia ofertę broker znajduje najlepszą ofertę reklamuje oferty na różne sposoby

24 Inżynieria oprogramowania Strona 24 znajduje najlepszą ofertę reklamuje oferty na różne sposoby odpowiadające różnym zamiarom zapewnia usługę katalogową ("yellow pages") podejście dawne wywalamy istniejące systemy i budujemy jeden super system podejście współczesne tworzymy rejestr usług na bazie istniejących systemów aplikacje klienckie odwołują się do rejestru usług, a dopiero później do konkretnych systemów poprzez XML'a autentykacja ustalenie tożsamości autoryzacja ustalenie praw dostępu SOAP simple object acces protocol protokół zdalnego wywoływania objektów dawne rozwiązanie WS* web services* aktualne rozwiązanie służące się do łączenia z web servisami MVC SOA vs Komunikaty usługami sterują komunikaty ważna jest treśd komunikatu, a nie warstwy transportowe różne struktury komunikatów pytanie, czy dopuszczamy utratę komunikatów: komunikaty idempotentne (kilkukrotne wywołanie nie skutkuje niczym negatywnym) komunikacja niezawodna SOA vs Web Services otwarty standard oferowanych usług możliwośd wymiany dokumentów strukturalnych różne zestawy informacji metadane luźne powiązania niewielkie nakłady na konsumpcję usługi przyjmowanie komunikatów nie w pełni rozumianych XML, WSDL późnie wiązanie lokalizacja niezależna od mechanizmu wywołania + katalogi usług możliwe interakcje peertopeer request / response niewydajny i ograniczający model interakcji wzrost poziomu gradualności zacierają się granice między klientem a serwerem SOA vs ESB kręgosłup SOA działa jak broker komunikatów

25 Inżynieria oprogramowania Strona 25 działa jak broker komunikatów zapewnia system kolejkowania komunikatów MQ message queue proste kolejkowanie MB message brocker potrafi również zarządzad komunikatami potrafi zmieniad format komunikatów, tłumaczyd jedne na drugie standard przemysłowy wymiany komunikatów np. SOA lub JMS zapewnia współpracę aplikacji wysokopoziomowych z niskopoziomowymi poprzez standardowe adaptery i interfejsy dawniej architektura spagetti, teraz szyny Otwarty standard oferowania usług Możliwośd wymiany dokumentów strukturalnych Różny zestaw informacji, metadane (informacje o informacji) Luźne powiązanie Niewielkie nakłady na konsumpcję usługi Przyjmowanie komunikatów nie w pełni rozumianych XML, WSDL Późne wiązanie Lokalizacja niezależna od mechanizmu wołania + katalogi usług Możliwe interakcje peertopeer Request / response Niewydajny i ograniczający model interakcji Wzrost poziomu granularności Zacierają się granice między klientem a serwerem SOA vs BPM BPM bussines process modeling SOA konstruowanie komponentów oprogramowania komponenty mogą byd reużuywane w nieznanym w momencie projketowania kontekście kompozycja vs rozszerzanie (OO) BPM zdolnośd do precyzyjnego modelowania zmiany kontekstu w którym komponenty (przedsiębiorstwa) są wykorzystywane Przejście na architekturę zorientowaną usługowo

26 Inżynieria oprogramowania Strona 26 Przejście na architekturę zorientowaną usługowo Dotarcie do SOA Osiągnięcie przez organizację kontroli nad zasobami IT Zorganizowanie logiki biznesowej w sposób niezależny od kontekstu jej wykorzystania Ponowna implementacja warstwy kontrolera Wykorzystanie technologii koordynacji Orkiestracja Choreografia Stworzenie nowej warstwy widoku Problemy Wymagane dobre rozumienie własnego biznesu Jest to inwestycja (usług >= procesów) Może byd dużym narzutem dla małych przedsiębiorstw Kiedy nie warto wdrażad SOA? Stabilne, homogeniczne środowiska IT SOA może nie byd istotne SOA może byd nieefektywne kosztowo Organizacja nie oferuje i nie wykorzystuje usług opartych na IT Nie ma potrzeby zapewnienia elastyczności Systemy czasu rzeczywistego SOA bazuje na luźno powiązanej komunikacji asynchronicznej Podsumowanie zorientowanie na usługi to nowy paradygmat obliczeniowy koncepcja konstrukcji oprogramowania SOA wymusza postrzeganie oprogramowania przez pryzmat: Większej ilości konsumentów Nieznanego kontekstu SOA jest ciągle przed nami: ewolucja, nie rewolucja Podnosi poziom abstrakcji i reużywalnośd systemów IT Możemy oczekiwad trendu do posiadania i publikowania usług Już się zaznacza (np. Google) Dotknie szczególnie aplikacji Mainframe i Klient/Serwer (ERP, CRM, ) Oprogramowanie będzie bogatsze i sprytniejsze Może stad się koszmarem, jeśli uwzględnimy ryzyka bezpieczeostwa Nie wszystkie technologie są dojrzałe Potrzeba zapewnienia zbieżności standardów

27 Inżynieria oprogramowania Strona 27

28 Inżynieria oprogramowania Strona 28 Jakośd 9 kwietnia :40 zestrzelenie Airbusa śmierd pacjentów chorych na raka, pentium floating point, 1994 rakieta Ariane 5, 1996 Czym jest jakośd? jak można zmierzyd jakośd mierzenie jakości w trakcie produkcji związek jakości produktu z jakością procesu wytwórczego jak można porównywad jakośd poszczególnych dostawców normy i standardy jakości dojrzałośd firm wytwarzających oprogramowanie w USA najbardziej zainteresowane jakością jest wojsko mierzenie jakości krzesła jakośd konstrukcji wartośd estetyczna zgodnośd z oczekiwaniami wszystkie miary jakości są względne jeśli nawet uda się ustalid, co jest lepsze, to i tak ciężko stwierdzid, o ile lepsze mierzenie jakości oprogramowania jakośd konstrukcji oprogramowanie nie powstaje w procesie manufaktury wartości estetyczne zdecydowana większośd napisanego oprogramowania jest niewidoczna wartośd estetyczna ma znaczenie w przypadku interfejsu użytkownika, ale jest to element marginalny z punktu widzenia jakości zgodnośd z oczekiwaniami wymagałoby prawdziwego zrozumienia przeznaczenia systemu Klasyczne podejście oprogramowanie jest dobrej jakości jeśli jest dopasowane do potrzeb robi to, co trzeba da się je rozszerzad działa niezawodnie działa szybko jest bezpieczne jest ergonomiczne jest w odpowiedniej cenie Jakośd trzeba mierzyd potrzeba zamienienia nieprecyzyjnych pomysłów w konkretne miary koncepcje jakości pojęcia abstrakcyjne pojęcia mierzalne definicje metryk co mierzyd pobranie pomiarów realizacja metryk jak mierzyd?

29 Inżynieria oprogramowania Strona 29 jak mierzyd? reliability mean time to failure? run it and count crashes per hour complexity information flow between modules? count procedure calls usability time taken to leran how to use? minutes taken for some user task? Cztery najważniejsze elementy? niezawodnośd projektant musi przewidzied jak się system zachowa kompletnośd czy robi wszystko co trzeba? czy obsługuje wszystkie dane wejściowe? spójnośd czy zawsze zachowuje się zgodnie z oczekiwaniami? odpornośd czy dobrze zachowuje się w warunkach niestandardowych? wydajnośd wykorzystanie zasobów takich jak czas procesora, pamięd, przepustowośd sieci w większości przypadków jest to mniej istotne niż niezawodnośd pielęgnowalnośd jak łatwo można będzie w przyszłości modyfikowad oprogramowanie? działania doskonalące, adaptujące, naprawcze użytecznośd jak łatwe jest w użyciu Jakośd jakośd trzeba przewidywad jakośd jest miarą relacji pomiędzy oprogramowaniem a dziedziną zastosowao może nie da się mierzyd jakości przed ostatecznym uruchomieniem systemu jakośd może się różnid zależnie od środowiska podczas projektowania musi byd możliwe przewidywanie jakości należy rozumied potrzeby (inżynieria wymagao) należy szukad wyznaczników jakości Generalnie dwa najważniejsze elementy kontrola jakości zapewnianie jakości dodatkowo mała i duża skala projektu Kontrola jakości walidacja czy budujemy właściwy system subiektywne trudno to stwierdzid zestaw przypadków testowych (najlepiej jak najwcześniej zdefiniowanych) weryfikacja czy budujemy system prawidłowo

30 Inżynieria oprogramowania Strona 30 czy budujemy system prawidłowo może byd obiektywne techniki kontroli jakości porównywanie oprogramowania ze specyfikacją weryfikacja (jeśli specyfikacja jest techniczna, to byd może da się to zrobid automatycznie) porównanie oprogramowania ze światem walidacja Przypadek testowy pochodna przypadku użycia prawie jeden do jednego względem scenariuszy w przypadkach testowych scenariusze testowe pochodne przypadków biznesowych trzeba byd w stanie śledzid zależności pomiędzy przypadkami użycia, procesami biznesowymi i przypadkami testowymi konieczne jest opisanie stanu systemu Walidacja czy system realizuje to, co trzeba? świat> analiza > projekt > system subiektywne Weryfikacja czy oprogramowanie jest zgodne ze specyfikacją może byd obiektywne zależy od jakości specyfikacji walidacja i weryfikacja muszą byd wykonywane przez cały czas realizacji projektu cele: wykrycie błędów w systemie sprawdzanie, czy system się do czegoś nadaje Trzy sposoby kontroli testowanie system jest uruchamiany z danymi testowymi inspekcje (review) analiza statycznej reprezentacji systemu w celu wykrycia problemów metody formalne Testowanie kto ma testowad jak testowad co poddawad testom nietestowanie może mied sens gdy kary za opóźnienie są o wiele większe od kar za błędy gdy system ma byd odpalony tylko raz decyzję na temat jakości należy podjąd na samym początku losowe testy nie wystarczą Podejście systematyczne systematyczne testowanie opera sie na partycjonowanmiu podziel zachowania systemu na grupy dla każdej grupy wybierz reprezentatywne próbki upewnij się, że uwzględniono wszystkie grupy jak zidentyfikowad dobry podział?

31 Inżynieria oprogramowania Strona 31 jak zidentyfikowad dobry podział? metody wyboru przypadków testowych czarna skrzynka (black box) przezroczysta skrzynka (white box) Przypadek testowy dane wejściowe stan wstępny zaobserwowane wyjście migawki maszyny wirtualnej zrzuty bazy danych i plików konfiguracyjnych skrypty zapełniające / czyszczące dane programu istnieją narzędzia półautomatyczne Czarna skrzynka generowane na podstawie specyfikacji nie patrzymy na kod programu zalety: unikanie przyjmowania tych samych założeo, co programista dane testowe są niezależne od implementacji wyniki można interpretowad bez wnikania w szczegóły systemy sugestie wyboru przypadków ścieżki specyfikacji pokrywają klauzule "wymaga, modyfikuje, wpływa na" warunki brzegowe Szukaj błędów w aliasach (dwa parametry odnoszące się do tego samego obiektu) przypadki nienormalne niepoprawne dane wejściowe Przezroczysta skrzynka badanie kodu i testowanie ścieżek w kodzie czarna skrzynka może nie spowodowad wykonania całego kodu kompletnośd instrukcji zestaw testów pokrywa komplet instrukcji jeśli każda instrukcja w kodzie jest wykonywana co najmniej raz w zestawie testów kompletnośd ścieżek zestaw testów pokrywa komplet ścieżek, jeśli każda ścieżka w kodzie jest wykonywana co najmniej raz w zestawie testów Pokrycie pokrycie instrukcji (statement coverage) pokrycie gałęzi instrukcja warunkowa musi byd przynajmniej raz prawdziwa i przynajmniej raz fałszywa Atrybuty procesu testowania powtarzalne systematyczne trzeba wybierad zestawy testów pokrywające cały zakres działania programu należy wybierad testy które są reprezentatywne dla rzeczywistych zastosowao dokumentowane Testy jednostkowe pisz test, nim napiszesz moduł przypadek użycia > przypadek testowy każda jednostka / moduł testowany jest oddzielnie

32 Inżynieria oprogramowania Strona 32 każda jednostka / moduł testowany jest oddzielnie czy spełnia specyfikację nie ma modułu bez testu extreme programming Testy integracji czy moduły współpracują ze sobą podejścia: bottom up (po odwróconym grafie) top down (stubs) coupling factor współczynnik powiązao pomiędzy systemami chcemy go minimalizowad na tym polega architektura komponentowa często wykrywają błędy specyfikacji a nie błędy integracji Testy systemowe na poziomie całej aplikacji testowanie funkcjonalności Testy pozafunkcjonalne facility testing Czy system zapewnia wszystkie wymagane funkcje? volume testing Czy system radzi sobie z dużą ilością danych? stress testing Czy system radzi sobie z dużym obciążeniem? endurance testing Czy system zachowuje parametry w długim okresie? usability testing Czy system jest łatwy w użyciu? security testing Czy system wytrzymuje ataki? performance testing Jak dobry jest czas reakcji systemu? storage testing Czy pojawiają się problemy ze składowaniem danych? configuration testing Czy system działa na wszystkich platformach? installability testing Czy da się skutecznie zainstalowad system? reliability testing Jak zmienia się niezawodnośd systemu w czasie? recovery testing Jak skutecznie system podnosi się po awarii? serviceability testing Czy daje się pielęgnowad system? documentation testing Czy dokumentacja jest dokładna? Adekwatna? operations testing Czy instrukcje operatorów są poprawne? Test regresji ponowne wykonanie opracowanych wcześniej testów Test uruchomieniowy (smoke test) czy program się uruchamia wersja minimalna testowania regresywnego JUnit testy jednostkowe Testowanie a debugowanie testowanie koncentruje się na znajdowaniu błędów debugowanie zajmuje się lokalizacją i usuwaniem błędów Inspekcje znaczenie zmniejszają liczbę błędów poprawianie kodu podczas inspekcji jest taosze, niż podczas debugowania lub już po wydaniu koszty naprawy danych są bardzo wysokie wpływ na morale zespołu, mniejsza rotacja lepsze rozpoznanie możliwości zespołu

33 Inżynieria oprogramowania Strona 33 Ograniczenia inspekcji dobry zespół max 6 osób min 3, max 7 osób podczas inspekcji czas max 2 godziny (spada koncentracja) wyniki wszyscy muszą się zgadzad podsumowanie (raport szczegółowa lista zagadnieo) skupiamy się na małym fragmencie 150 LOC / h harmonogram nie za wcześnie autor świadom błędów nie za późni nic to już nie da przegląd po zakooczeniu prac autora Wytyczne inspekcji przed spotkaniem należy jasno zdefiniowad cel i oczekiwane efekty niezbędny lider fakt inspekcji należy zapisad uczestnicy powinni móc przygotowad się do inspekcji

34 Inżynieria oprogramowania Strona 34 Zarządzanie konfiguracją 23 kwietnia :56 opisuje zależności pomiędzy różnymi komponentami gałęzie przy zarządzaniu wersjami bazowa przed wydaniem dla zadao można zdad się na integratorów zarządzanie konfiguracją kontrola wersji zarządzanie zmianą budowanie wydao zmiany w makefile'u wprowadza tylko jedna osoba sposób na ograniczenie coupling factoru dodanie zależności od kolejnej biblioteki wymaga uzgodnieo co powstaje przy produkcji oprogramowania: Specyfikacja (funkcjonalna, pozafunkcjonalna) Projekt, model Prototyp Kod źródłowy Testy (jednostkowe, użytkownika) Wydania (binaria) Instrukcja instalacji Lista zmian (w stosunku do wydania poprzedniego) Lista znanych błędów Podręczniki (użytkownika, administratora) Harmonogram Notatki robocze zespołu 1) 2) 3) Wyzwania: równoległa praca nad różnymi fragmentami kodu identyfikacja i przechowywanie różnych wersji dokumentów wersje dokumentów a wersje produktów analizowanie histori kto, kiedy, jaka zmiana praca nad nową wersją systemu i poprawianie błędów w starej Zarządzanie konfiguracją kontrola wersji zarządzanie zmianą budowanie wydao Kontrola wersji komunikacja z centralnym systemem kopia lokalna repozytorium i wprowadzanie zmian w centralnym repozytorium na żądanie etykiety gałęzie bazowa przed wydaniem dla zadao

35 Inżynieria oprogramowania Strona 35 Pytania do systemu zarządzania konfiguracją Jaka platforma jest wymagana dla danej wersji systemu? Które wersje systemu są zależne od zmiany danego komponentu? Ile błędów zgłoszono do danej wersji? Jakie komponenty zmodyfikowano przy realizacji danej zmiany? Budowanie wydao dobre praktyki Przyrostowa zmiana systemu jaka może byd włączona do nowego wydania jest w przybliżeniu stałego rozmiaru Jeśli zbyt wiele nowych cech zostanie włączonych razem z poprawkami błędów, wówczas koszt przygotowania nowego wydania znacząco wzrasta Jeśli do wydania włączono wiele zmian, musi nastąpid po nim wydanie poprawiające błędy wynikające ze zmian wprowadzonych w pierwszym wydaniu Plan zarządzania konfiguracja definiuje artefakty podlegających zarządzaniu konfiguracją standardy nazewnictwa role odpowiedzialne za tworzenie linii bazowych procedury kontroli zmian i wersjonowania zasady wglądu klienta w rejestry opisuje narzędzia wspierające zarządzanie konfiguracją system kontroli wersji system śledzenia zmian system budowania wydao konfigurację narzędzi odpowiadającą przyjętej procedurze uprawnienia użytkowników w systemie Narzędzia kontroli wersji Identyfikacja wersji i wydao systemu System przydziela identyfikatory automatycznie podczas zgłaszania nowej wersji pliku do systemu Kontrolowanie zmian Tylko jedna wersja w danej chwili może podlegad zmianie. Można równolegle pracowad nad różnymi wersjami. Zarządzanie przestrzenią dyskową Przechowywanie różnid a nie pełnych nowych wersji Dla danych tekstowych jak też binarnych Rejestrowanie historii zmian Zapamiętuje uzasadnienia wprowadzenia zmian Narzędzia budowania systemu problemy czy uwzględniono wszystkie wymagane komponenty? czy wskazano właściwą wersję komponentu? czy wszystkie pliki z danymi są dostępne? czy odwołania do plików / komponentów są poprawne? czy system jest budowany na właściwą platformę? czy wykorzystywana jest właściwa wersja kompilatora i narzędzi deweloperskich? Narzędzia śledzenia zmian Głównym zadaniem śledzenie statusów zgłoszonych zmian/błędów Automatycznie zapewnia że zmiany są przekierowywane do właściwych osób (np. do właścicieli komponentów, których zmiany dotyczą) Organizuje współpracę w ramach zespołu

36 Inżynieria oprogramowania Strona 36 właścicieli komponentów, których zmiany dotyczą) Organizuje współpracę w ramach zespołu Integracja z pocztą elektroniczną zapewnia powiadamiania i eskalację problemów Zarządzanie zmianą

37 Inżynieria oprogramowania Strona 37 Planowanie 30 kwietnia :39 1) 2) 3) 4) 1) 2) 3) Podstawowe pytania ile potrzeba pracy jaki jest całkowity koszt ile dni kalendarzowych jest potrzebne jaki zespół jest potrzebny Oszacowanie pracochłonności sposoby metryki a. metoda punktów funkcyjnych b. metoda punktów obiektowych ekspertyzy a. struktura podziału pracy b. diagram sieciowy c. zrównoważenie zasobów inne a. szacowanie na podstawie wielkości kodu źródłowego Metoda punktów funkcyjnych bazujemy na opisie funkcjonalności uwzględniamy aspekty technologiczne wybór języka środowiskowe rodzaj zespołu funkcjonalne przypadki użycia aktorzy Aspekt technologiczny Aspekt środowiskowy

38 Inżynieria oprogramowania Strona 38 Przypadki użycia Aktorzy

39 Inżynieria oprogramowania Strona 39 Wynik Struktura podziału pracy (WBS) Work Breakdown Structure definicja zakresu projektu hierarchiczna list czynności drzewo co jest częścią czego tworzona w oparciu o podstawowe techniki abstrakcja dekompozycja jakośd bazuje na jakości ekspertów stopieo szczegółowości (dla każdego liścia) kto jest odpowiedzialny ile czasu potrwa realizacja ile będzie kosztowad?

40 Inżynieria oprogramowania Strona 40 Diagram sieciowy (diagram projektu) co zależy od czego w jakiej kolejności należy budowad jedno źródło, jedno ujście ustalenie logiki ścieżka krytyczna najdłuższa (z wagami) ścieżka od startu do zakooczenia jest to długośd projektu dla każdej czynności najwcześniejsze rozpoczęcia najpóźniejsze zakooczenie wynikiem jest graf zależności jedno źródło i jedno ujście ścieżki w grafie, ścieżka krytyczna niepewnośd oszacowania zapas zadania najpóźniejsze zakooczenie najwcześniejsze zakooczenie czynnośd na ścieżce krytycznej ma zapas zerowy wolny zapas całkowity zapas ścieżka krytyczna najdłuższa (z wagami) ścieżka od źródła do ujścia