Inżynieria Oprogramowania - PDF

Fakty Gospodarki wszystkich rozwiniętych krajów zależą od oprogramowania. Coraz więcej systemów wymaga niezawodnego oprogramowania. Obecnie wytwarzanie oprogramowania jest poważną gałęzią gospodarki narodowej rozwiniętego kraju. W Polsce wg stanu na 2020 roku sektor ICT generował 8% PKB...

Fakty Gospodarki wszystkich rozwiniętych krajów zależą od oprogramowania. Coraz więcej systemów wymaga niezawodnego oprogramowania. Obecnie wytwarzanie oprogramowania jest poważną gałęzią gospodarki narodowej rozwiniętego kraju. W Polsce wg stanu na 2020 roku sektor ICT generował 8% PKB Inżynieria oprogramowania zajmuje się teorią, metodami i narzędziami związanymi z wytwarzaniem oprogramowania 1  Fakty Koszty oprogramowania są często dominującym składnikiem kosztów całego systemu. Zdarza się, że koszt oprogramowania znacznie przekracza samą wartość sprzętu komputerowego np. komputera osobistego. Koszt utrzymania i konserwacji oprogramowania jest większy niż koszt jego wytworzenia. Wieloletnia konserwacja oprogramowania może kosztować wielokrotnie więcej niż jego zakup. Inżynieria oprogramowania zajmuje się efektywnymi metodami wytwarzania i implementowania oprogramowania. 2  Geneza inżynierii oprogramowania Początki inżynierii oprogramowania sięgają połowy lat 60-tych XX w. Była odpowiedzią na „kryzys oprogramowania” Kryzys oprogramowania Pojawił się wraz z rozbudowanymi systemami informatycznymi Wiele projektów nie kończyło się sukcesem Stworzenie systemu wymagało współpracy wielu osób Twórca systemu i użytkownik systemu oddalają się od siebie Przyczyny kryzysu wskazywane w latach 60-tych XX w. Duża złożoność systemów informatycznych Niepowtarzalność poszczególnych przedsięwzięć Nieprzejrzystość procesu budowy oprogramowania Pozorna łatwość wytwarzania i dokonywania poprawek w oprogramowaniu. Uważa się, że kryzys trwa do dziś. Błędy w oprogramowaniu są nieuniknione. 3 Pojęcia podstawowe 4  Oprogramowanie Oprogramowanie to programy komputerowe, cała związana z nimi dokumentacja i dane konfiguracyjne. Rodzaje produktów oprogramowania Powszechne (generic products) – kierowane do wielu odbiorców; o funkcjonalności systemu decyduje jego twórca. Dostosowane (customized products) - na zamówienie dla konkretnego odbiorcy; funkcjonalność wynika z potrzeb odbiorcy. 5  Właściwości dobrego oprogramowania Konkretny zbiór właściwości zależy od zastosowania Można podać ogólny zbiór właściwości: Zdolność do pielęgnacji (maintainability) - zdolność do ewolucji zgodnie z potrzebami klientów Niezawodność (dependability and security) – szerokie pojęcie, uwzględniające to czy oprogramowanie realizuje swoje funkcje w sposób niezakłócony i bezpieczny Efektywność (efficiency) - nie powinno marnotrawić zasobów systemu takich jak pamięć czy czas procesora Użyteczność (acceptability) - powinno być użyteczne, bez zbędnego wysiłku ze strony użytkownika 6  Inżynieria oprogramowania Inżynieria oprogramowania to dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji. Zajmuje się teorią, metodami i narzędziami związanymi z wytwarzaniem oprogramowania. Inżynierowie oprogramowania pracują w sposób systematyczny i uporządkowany ponieważ jest to najskuteczniejszy sposób tworzenia oprogramowania wysokiej jakości. 7  Inżynieria oprogramowania - dziedzina wiedzy Informatyka Inżynieria systemów Informatyka ekonomiczna Inżynieria oprogramowania 8  Informatyka Informatyka (computer science, computing science) to ogół dyscyplin naukowych i technicznych zajmujących się informacją, a w szczególności jej komputerowym przetwarzaniem (za: W.M. TURSKI Propedeutyka informatyki, Warszawa 1989). Obejmuje: teorie informatyczne, budowę systemów informatycznych (w tym programowanie), budowę i działanie sprzętu komputerowego, zastosowania metod informatycznych w różnych dziedzinach działalności ludzkiej. 9  Informatyka ekonomiczna Informatyka ekonomiczna (management information systems, MIS, informatics) zajmuje się systemami informatycznymi w organizacjach, głównie gospodarczych i administracyjnych. Obszary zainteresowań: inżynieria oprogramowania, systemy klasy ERP, SCM, CRM, WFM, Business Intelligence, biznes elektroniczny. 10  Inżynieria oprogramowania vs informatyka Zasadniczo informatyka obejmuje teorie i podstawowe zasady działania komputerów. Inżynieria oprogramowania obejmuje praktyczne problemy związane z tworzeniem oprogramowania. Byłoby dobrze gdyby inżynier programowania znał teorie informatyczne, z drugiej strony nie zawsze przystają one do rzeczywistości. 11  Inżynieria oprogramowania vs inżynieria systemów Inżynieria systemów komputerowych obejmuje wszystkie aspekty tworzenia i ewolucji systemów komputerowych. Dotyczy sprzętu, oprogramowania, procesów. Inżynierowie systemów biorą udział w specyfikacji systemu i definiowania jego ogólnej architektury. 12  Proces tworzenia oprogramowania Czynności w procesie tworzenia oprogramowania (niezależnie od przyjętej metodyki) Specyfikacja oprogramowania Tworzenie oprogramowania Zatwierdzenie oprogramowania Ewolucja oprogramowania 13  Model procesu tworzenia oprogramowania Jest to uproszczona prezentacja procesu tworzenia oprogramowania. Modele ze swej natury są uproszczeniami. Przykłady ogólnych modeli (paradygmatów) tworzenia oprogramowania Model kaskadowy Tworzenie ewolucyjne Formalne przekształcenia Składanie systemu z komponentów ponownego użycia 14  Koszty inżynierii oprogramowania Koszty wytworzenia oprogramowania możne być zbliżony do kosztów jego testowania. Ewolucja oprogramowania może przewyższyć koszty jego wytworzenia. Koszty zmian oprogramowania użytkowanego przez długi okres czasu mogą kilkukrotnie przekroczyć koszty jego wytworzenia. Koszty zależą od stosowanego modelu. 15  CASE Computer-Aided Software Engineering CASE obejmuje rożne programy wykorzystane do wspomagania czynności procesu tworzenia oprogramowania (np. edytory notacji, generatory kodów) Upper-CASE Związane z początkowymi fazami tworzenia oprogramowania Lower-CASE Wspomagają implementowanie i testowanie 16 Wyzwania dla inżynierów oprogramowania 17  Wyzwania dla inżynierów oprogramowania Wyzwanie dziedzictwa Pielęgnacja i modyfikacji działających dużych systemów, pełniących poważne funkcje gospodarcze. 18  Wyzwania dla inżynierów oprogramowania Wyzwanie różnorodności Wymóg działania oprogramowania w systemach rozproszonych przy rożnych typach komputerów i systemów wspomagających. 19  Wyzwania dla inżynierów oprogramowania Wyzwanie doręczenia Wymóg dostarczanie gotowego programowania w skróconym czasie bez utraty jakości. 20  Wyzwania dla inżynierów oprogramowania Zmienność otoczenia Oprogramowanie musi być dostosowywane do ciągle zmieniającego się otoczenia biznesowego i społecznego. 21  Wyzwania dla inżynierów oprogramowania Potrzeba zaufania Oprogramowanie jest powiązane z wieloma aspektami naszego życia, co generuje potrzeba tworzenia rozwiązań godnych zaufania. 22  Wyzwania dla inżynierów oprogramowania Skalowalność Oprogramowania tworzone jest dla przedsięwzięć o bardzo różnorodnej skali (od systemów wbudowanych do globalnych systemów w chmurze) 23 Odpowiedzialność i etyka 24  Odpowiedzialność etyczna i zawodowa Inżynierowie oprogramowania muszą zaakceptować fakt, że ponoszą znacznie większą odpowiedzialność niż tylko wynikająca z ich technicznych umiejętności. Muszą postępować etycznie i moralnie, jeśli chcą być uważani za profesjonalistów. Zachowywać się etycznie, to więcej niż tylko przestrzegać obowiązujące prawo. 25  Zasady zawodowej odpowiedzialności Zachowywanie tajemnicy Inżynierowie powinni zawsze dochowywać tajemnic powierzonych przez pracodawców i klientów, niezależnie od tego czy podpisano formalną umowę o ochronie tajemnicy. Kompetencje Inżynierowie nie powinni zawyżać poziomu swoich kompetencji. Nie powinni świadomie przyjmować prac, które przekraczają 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ści swoich pracodawców i klientów. Niewłaściwe użycie komputera Inżynierowie oprogramowania nie powinni używać swoich umiejętności do niewłaściwego używania cudzych komputerów. Niewłaściwe użycie może być dość banalne (np. granie na maszynie pracodawcy) lub skrajnie poważne (rozsiewanie wirusów). 26  Kodeks etyki i zawodowej praktyki (wersja skrócona) 1. Społeczeństwo Inżynierowie oprogramowania powinni działać dla dobra społeczeństwa. „Kto jest elitą - szewc czy informatyk?” 2. Klient i pracodawca Inżynierowie oprogramowania powinni postępować zgodnie z interesami swojego klienta lub pracodawcy zgodnymi z dobrem społeczeństwa. 3. Produkt Inżynierowie oprogramowania powinni zapewnić, że ich produkty i związane z nimi zmiany spełniają najwyższe standardy profesjonalizmu. 4. Rozsądek Inżynierowie oprogramowania powinni zachowywać rozsądek i niezależność swoich sądów. 27  Kodeks etyki i zawodowej praktyki (wersja skrócona) 5. Zarządzanie Zarządzający inżynierami oprogramowania i zwierzchnicy powinni przyjąć i promować etykę w zarządzaniu tworzeniem i pielęgnacją oprogramowania. 6. Profesja Inżynierowie oprogramowania powinni podnosić wiarygodność i reputację profesji zgodnie z dobrem społeczeństwa. 7. Koleżeństwo Inżynierowie oprogramowania powinni być uczciwi i chętni do pomocy swoim kolegom. 8. Ja sam Inżynierowie oprogramowania powinni brać udział w długofalowej nauce praktyki swojego zawodu. Powinni także promować etyczne działania w praktyce swojej profesji. 28  System System jest celową kolekcją powiązanych ze sobą komponentów, które współpracują, aby osiągnąć pewien cel. Bardzo prosty system, na przykład pióro, jest zrobiony z trzech lub czterech komponentów sprzętowych. System kontroli lotów składa się z tysięcy komponentów programowych i sprzętowych oraz użytkowników, którzy podejmują decyzje na podstawie informacji otrzymanej z systemu. 29  Zależności pomiędzy komponentami systemów Systemy charakteryzują się tym, że właściwości i zachowania ich komponentów są nierozerwalnie ze sobą splecione. Poprawne działanie każdego z komponentów systemu zależy od funkcjonowania kilku innych komponentów. Złożone zależności między komponentami systemu oznaczają, że system jest czymś więcej niż tylko sumą swoich części. Te pojawiające się właściwości nie mogą być przypisane żadnej części systemu. 30  Właściwości systemu Właściwości niefunkcjonalne takie jak niezawodność, efektywność, bezpieczeństwo i zabezpieczenia są związane z zachowaniem systemu w jego środowisku pracy często są zasadnicze dla systemów komputerowych, ponieważ niepowodzenie w osiągnięciu pewnego zdefiniowanego minimalnego ich poziomu może sprawić, że system będzie bezużyteczny Właściwości funkcjonalne są widoczne, gdy wszystkie części systemu współpracują, aby osiągnąć pewien cel Przykład: Rower ma cechę funkcjonalną bycia środkiem transportu, gdy scali się go z jego części. 31  Niezawodność systemu Niezawodność jest złożonym pojęciem, które zawsze należy badać na poziomie systemu, a nie jego poszczególnych komponentów. Komponenty w systemie są od siebie zależne, a zatem awarie w jednym z nich mogą przenosić się na cały system i mieć wpływ na operacje innych systemów. Często projektanci systemu nie są w stanie przewidzieć, jak konsekwencje dla całego systemu będzie miała awarii. Nie mogą zatem podać wiarygodnych oszacowań niezawodności systemu. 32  Czynniki wpływające na niezawodność systemu Niezawodność sprzętu Jakie jest prawdopodobieństwo awarii komponentu sprzętowego i jak długi jest czas jego naprawy? Niezawodność oprogramowania Jakie jest prawdopodobieństwo wytworzenia przez komponent programowy błędnych danych wyjściowych? Awarie oprogramowania istotnie różnią się od awarii sprzętu, ponieważ oprogramowanie nie zużywa się. Niezawodność operatora Jakie jest prawdopodobieństwo błędu operatora systemu? 33  Efektywność i użyteczność, bezpieczeństwo i zabezpieczenia Efektywność i użyteczność są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu. Bezpieczeństwo i zabezpieczenia: mamy tutaj do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowaniem systemu, które nie powinno mieć miejsca. Np. system zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych. 34  Systemy i ich środowiska Systemy nie są niezależnymi bytami, ale istnieją w pewnym środowisku. Środowisko to ma wpływ na funkcjonowanie i efektywność systemu. Czasami środowisko można uważać za system sam w sobie - składa się z pewnej liczby oddziałujących na siebie systemów. 35  Modelowanie systemu W trakcie czynności spisywania wymagań i projektowania musi powstać model systemu jako zbioru komponentów i związków między nimi. Architektura systemu jest zwykle prezentowana jako diagram blokowy, obrazujący najważniejsze podsystemy i połączenia między nimi. Każdy podsystem jest rysowany w postaci prostokąta na diagramie blokowym. 36  Kontekst systemu bankomatu System System księgowy zabezpieczeń Baza danych oddziału kont System bankomatu System Baza danych obsługi o użytkowaniu oddziału System konserwacji 37  Komponenty funkcjonalne systemu Komponenty detektorowe Zbierają informacje ze środowiska systemu. Przykładami takich komponentów są radary w systemie kontroli lotów, detektory papieru w drukarkach laserowych. Komponenty efektorowe (uruchamiające) Powodują zmiany w środowisku systemu. Przykładami takich komponentów są: zawory, które otwierają się i zamykają, aby zwiększyć lub zmniejszyć przepływ cieczy w rurze; stateczniki samolotu, które wyznaczają kierunek lotu; mechanizm wciągania papieru do drukarki, który przesuwa papier za detektor papieru. Komponenty obliczeniowe Pobierają dane wejściowe, wykonują na nich pewne obliczenia i wytwarzają wyniki. Przykładem takiego komponentu jest procesor zmiennopozycyjny, który wykonuje obliczenia na liczbach rzeczywistych. 38  Komponenty funkcjonalne systemu Komponenty komunikacyjne Umożliwiają komunikację innym komponentom systemu. Przykładem takiego komponentu jest sieć łącząca różne komputery wewnątrz budynku. Komponenty koordynujące Koordynują operacje innych komponentów. Np. w układach czasu rzeczywistego jest to komponent szeregujący zadania. Komponenty interfejsu Przetwarzają dane w reprezentacji używanej przez jedne komponenty na reprezentacje używane przez inne komponenty. Przykładem może być komponent interfejsu do komunikacji z człowiekiem, który pobiera pewien model systemu i wyświetla go operatorowi. Innym przykładem jest przetwornik analogowo-cyfrowy, który zamienia wejście analogowe na wyjście cyfrowe. 39  Proces inżynierii systemów Definicja Projektowanie Tworzenie Integracja Instalacja Ewolucja Likwidacja wymagań podsystemów podsystemów podsystemów systemu systemu systemu 40 Modele cyklu życia oprogramowania 41  Proces vs model procesu Proces tworzenia oprogramowania - zbiór czynności i związanych z nimi wyników, które zmierzają do opracowania produktu programistycznego. Model procesu tworzenia oprogramowania (inaczej model cyklu życia oprogramowania) - uproszczona prezentacja procesu tworzenia oprogramowania. Określa: Fazy życia oprogramowania Czynności wykonywane w poszczególnych fazach Kolejność wykonywania faz 42  Zasadnicze czynności w procesie tworzenia oprogramowania Specyfikacja oprogramowania Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane. Tworzenie oprogramowania Projektowanie i implementowanie oprogramowania, które spełnia specyfikację. Zatwierdzenie oprogramowania Wytworzone oprogramowanie musi spełniać oczekiwania klienta. Ewolucja oprogramowania Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników. 43  Modele cyklu życia oprogramowania Model kaskadowy (waterfall) Metody iteracyjne / Tworzenie ewolucyjne Tworzenie formalne systemu / Formalne przekształcenia Tworzenie z użyciem wielokrotnym / Składanie systemu z komponentów ponownego użycia 44 Model kaskadowy 45  Model kaskadowy Określenie wymagań Projektowanie Implementacja i testy jednostkowe Integracja i testy systemowe Konserwacja 46  Fazy w modelu kaskadowym Określenie wymagań (Requirements analysis and definition) – określenie celów i szczegółowych wymagań wobec systemu Projektowanie (System and software design) – szczegółowy projekt systemu spełniającego wymagania Implementacja i testy jednostkowe (Implementation and unit testing) – implementacja (kodowanie) projektu w określonym środowisku programistycznym oraz poszczególnych programów Integracja i testy systemowe (Integration and system testing) – integracja poszczególnych programów i testy całości Konserwacja (Operation and maintenance) – wdrożenie i konserwacja oprogramowania 47  Dodatkowe fazy w modelu kaskadowym Określenie Implementacja Integracja Projektowanie Konserwacja wymagań i testy jednostkowe i testy systemowe Faza Analiza Instalacja strategiczna Dokumentacja 48  Dodatkowe fazy w modelu kaskadowym Faza strategiczna (Strategy) – przed formalną decyzją o rozpoczęciu przedsięwzięcia. Ma na celu podjęcie decyzji o sposobie i zakresie prowadzenia dalszych prac. Analiza (Analysis) – budowa logicznego modelu systemu Dokumentacja (Documentation) – przygotowanie dokumentacji użytkownika Instalacja (Installation) – przekazanie systemu użytkownikowi 49  Zalety modelu kaskadowego Łatwość zarządzania (planowanie, harmonogramowanie, monitorowanie) przedsięwzięciem. 50  Problemy modelu kaskadowego Następnej fazy nie powinno się rozpoczynać, jeśli poprzednia się nie zakończy. Nieelastyczny podział na rozłączne etapy. Wysoki koszt błędów popełnionych we wczesnych fazach. Długi cykl produkcyjny -> długo czeka się na efekty prac -> długa przerwa w kontaktach z klientem. Koszty opracowania i akceptacji dokumentów są wysokie i dlatego iteracje są również kosztowne oraz wymagają powtarzania wielu prac. Powinien być używany jedynie wówczas, gdy wymagania są jasne i zrozumiałe. 51  Praktyka Określenie wymagań Projektowanie Implementacja i testy jednostkowe Integracja i testy systemowe Konserwacja 52 Metody iteracyjne 53  Metody iteracyjne Równoległe czynności Wersja Specyfikacja początkowa Opis Tworzenie Wersje ogólny pośrednie Wersja Zatwierdzanie końcowa 54  Metody iteracyjne Prototypowanie Tworzenie badawcze Tworzenie przyrostowe Tworzenie spiralne 55  Prototypowanie z porzuceniem (prototyping) Celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań stawianych systemowi. Budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne. Po uzyskaniu akceptowalnej wersji jest ona porzucana. Proces tworzenia właściwej wersji może przebiegać na przykład zgodnie z modelem kaskadowym. Można użyć narzędzi do szybkiego tworzenia oprogramowania (np. RAD - Rapid Application Development) Zalety Możliwość szybkiej demonstracji systemu Klient poznaje system przed jego wykonaniem Wady Wydłużenie czasu i dodatkowy koszt Poczucie zmarnowania środków na produkcję zbędnego elementu (prototypu) 56  Tworzenie badawcze (exploratory programming) Stosowany, gdy bardzo trudno określić wymagania względem systemu Pracuje się z klientem, bada się jego wymagania i tworzy kolejne wersje systemy na podstawie coraz dokładniejszych specyfikacji wymagań Tworzenie rozpoczyna się od ogólnego określenia wymagań Tworzy się kolejne wersje systemu na podstawie kolejnych wersji wymagań. Nowa wersja oprogramowania powstaje na podstawie poprzedniej wersji. Po każdej iteracji, klient określa czy system spełnia oczekiwania Zalety Do użycia przy trudnościach w uzyskaniu jasnej specyfikacji wymagań Wady Trudność w utrzymaniu poprawnej struktury programu Duży nakład pracy użytkownika (w weryfikację kolejnych wersji) 57 Tworzenie przyrostowe (incremental development) Zaproponowane jako sposób na ograniczenie powtarzania prac w procesie tworzenia oraz danie klientom pewnych możliwości odkładania decyzji o szczegółowych wymaganiach do czasu, aż zdobędą pewne doświadczenia w pracy z systemem. Klienci identyfikują w zarysie usługi, które system ma oferować. Wskazują, które z nich są dla nich najważniejsze, a które najmniej ważne. Definiuje się następnie pewną liczbę przyrostów, które maja być dostarczone. Gdy przyrost jest już gotowy i dostarczony, klienci mogą go uruchomić. Oznacza to, że szybko otrzymują część funkcjonalności systemu 58  Model przyrostowy Określenie wymagań Projekt ogólny Wybór podzbioru funkcji Iteracja Szczegółowy projekt, implementacja i testy Dostarczenie zrealizowanej części systemu 59  Tworzenie przyrostowe Zalety Klienci nie muszą czekać na dostarczenie całego systemu, zanim zaczną czerpać z niego korzyść. Klienci mogą używać wstępnych przyrostów jako rodzaju prototypu i zdobywać doświadczenia, które inspirują wymagania wobec późniejszych przyrostów. Ryzyko całkowitej porażki przedsięwzięcia jest mniejsze. Usługi o najwyższym priorytecie będą dostarczane jako pierwsze. Wady Dodatkowy koszt na obsługę iteracji Trudność w wyborze niezależnego podzbioru funkcji. Może wymagać tworzenia dodatkowych „zaślepek”. 60  Tworzenie spiralne (spiral model) Ma charakter ogólny - można z niego wyprowadzić inne modele tworzenia oprogramowania Przedstawiany jako spirala, Określenie celu Rozpoznanie i redukcja zagrożeń której każda pętla (iteracja) (analiza ryzyka) odpowiada jednej fazie procesu tworzenia oprogramowania (analiza strategiczna, definiowane wymagań, …) Można też każdą pętlę traktować jako kolejną edycję oprogramowania Tworzenie i testy Planowanie (konstrukcja) 61  Fazy tworzenia spiralnego Każda pętla spirali jest podzielona na cztery sektory: Określenie celu - Definiuje się konkretne cele tej fazy przedsięwzięcia. Identyfikuje się ograniczenia, którym podlega proces i produkt. Rozpoznanie i redukcja zagrożeń - Przeprowadza się szczegółową analizę każdego z rozpoznanych zagrożeń przedsięwzięcia. Może obejmować budowę prototypu Tworzenie i testy – może (ale nie musi) być realizowane modelem kaskadowym Planowanie - Recenzuje się przedsięwzięcie i podejmuje decyzję, czy rozpoczynać następną pętlę spirali. 62 Tworzenie spiralne 63 Tworzenie formalne systemu 64  Tworzenie formalne systemów Tworzenie formalne systemów jest podejściem, które ma wiele wspólnego z modelem kaskadowym. Proces tworzenia jest tu jednak oparty na matematycznych przekształceniach specyfikacji systemu w program wykonywalny. W procesie przekształcania formalna matematyczna reprezentacja systemu jest metodycznie przekształcana w bardziej szczegółowe, ale wciąż matematycznie poprawne reprezentacje systemu. Podejście z przekształceniem złożone z ciągu małych kroków jest łatwiejsze w użyciu. Wybór, które przekształcenie zastosować, wymaga jednak dużych umiejętności. Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom, pierwotnie opracowany przez IBM (Proces Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy formalnie wykonuje się każdy krok i dowodzi jego poprawności.) 65  Problemy i stosowalność Oprócz specjalistycznych dziedzin procesy oparte na przekształceniach formalnych są używane rzadko. Wymagają specjalistycznej wiedzy i w praktyce okazuje się, że w wypadku większości systemów nie powodują zmniejszenia kosztów lub polepszenia jakości w porównaniu z innymi podejściami. Interakcje systemów nie poddają się łatwo specyfikowaniu formalnemu. 66 Tworzenie z użyciem wielokrotnym 67  Tworzenie z użyciem wielokrotnym Polega na składaniu systemu z gotowych komponentów (komponentów użycia wielokrotnego) Wykorzystuje się podobieństwo tworzonego oprogramowania do innych, wcześniej tworzonych, rozwiązań 68  Tworzenie z użyciem wielokrotnym Naszkicuj Poszukaj Na podstawie wyników wymagania komponentów użycia poszukiwań zmień systemowe wielokrotnego wymagania Zaprojektuj system Poszukaj korzystając Projektowanie komponentów użycia z komponentów architektoniczne wielokrotnego użycia wielokrotnego 69  Źródła dodatkowe Szacowanie pracochłonności: https://wazniak.mimuw.edu.pl/images/3/30/Zio-13-wyk.pdf 70  Fazy cyklu życia oprogramowania Określenie Implementacja Integracja Projektowanie Konserwacja wymagań i testy jednostkowe i testy systemowe Faza Analiza Instalacja strategiczna Dokumentacja 71  Faza strategiczna strategy phase Alternatywna nazwa: studium wykonalności (feasibility study) Wykonywana przed podjęciem decyzji o realizacji przedsięwzięcia Wynikiem powinien być raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu 72  Faza strategiczna W zależności od rodzaju przedsięwzięcia, faza może obejmować: Określenie celów przedsięwzięcia Określenie zakresu przedsięwzięcia Określenie kontekstu (otoczenia) systemu Określenie wstępnych wymagań Przegląd rynku Oszacowanie kosztów przedsięwzięcia Analiza make-or-buy Negocjacje z klientem / dostawcą Przeprowadzenie przetargu Określenie wstępnego harmonogramu Określenie standardów realizacji przedsięwzięcia 73  Przykładowe pytania Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? Jak firma poradziłaby sobie, jeśli system nie byłby zaimplementowany? Czy system może być zaimplementowany w ramach ustalonego budżetu i ograniczeń czasowych? Czy system wymaga technologii, których wcześniej w firmie nie stosowano? Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano? Czy można przekazywać informacje do i z innych systemów przedsiębiorstwa? Jakie problemy występują w obecnie przyjętych procesach i jak nowy system ma pomóc w ich eliminacji? Co system musi wspomagać, a czego nie musi? 74  Przykładowe cele przedsięwzięcia Przyspieszenie obsługi klienta Zmniejszenie ryzyka operacyjnego (popełnienia błędu przez pracownika) Udostępnienie nowego produktu klientom firmy Zwiększenie konkurencyjności oferty Dostosowanie do wymogów prawnych 75  Zakres przedsięwzięcia Zakres przedsięwzięcia może być określany przez: Funkcje systemu Kontekst systemu, czyli jego otoczenie Systemy informatyczne Grupy użytkowników 76  Porównanie rozwiązań W fazie strategicznej często konieczne jest porównanie dostępnych rozwiązań. Jako rozwiązanie można rozumieć na przykład oferty w ramach przetargu produkty dostępne na rynku podejścia do prowadzenia przedsięwzięcia Porównanie utrudnione jest z powodu: wielości kryteriów oceny (np. cena, czas realizacji, niezawodność, wydajność, skalowalność, renoma dostawcy, ergonomia, możliwość parametryzacji) braku pełnej wiedzy dotyczącej rozwiązania występowanie kryteriów trudno mierzalnych 77  Metoda scoringowa Metoda scoringowej (ważona punktowa). Polega na nadaniu wag dla poszczególnych kryteriów oceny a następnie ocenie punktowej stopnia realizacji celu dla poszczególnych kryteriów w każdym rozwiązaniu. Porównywane są sumy iloczynów waga * punkty. Kryterium Waga Rozwiązanie 1 Rozwiązanie 2 Punkty Punkty Koszt 0,50 4 3 Czas 0,30 2 3 Gwarancje 0,15 2 3 Renoma 0,05 5 2 Suma (waga * punkty): 3,15 2,95 78  Określenie kosztów oprogramowania Składniki kosztów: sprzęt niezbędny do wykonania oprogramowania szkolenia narzędzia nakład pracy i związane z nim wynagrodzenia pracowników Najtrudniej określić nakłady pracy 79  Techniki oceny nakładów pracy Prawo Parkinsona – zakłada wykorzystanie całości zasobów przeznaczonych na realizację zadania Pricing to win – wycena uwzględnia realia rynkowe („ile da konkurencja”) a nie spodziewane nakłady pracy Metoda ekspercka Ocena przez analogię Szacowanie wstępujące Modele algorytmiczne 80  Metoda ekspercka Metoda heurystyczna (wykorzystanie twórczego myślenia, aby zrekompensować niedostatek informacji) Bazuje na doświadczeniu ekspertów Przykładem jest metoda deflicka Gromadzi się grupę ekspertów Otrzymują oni dokumentację projektu do zapoznania się Eksperci wymieniają uwagi odnośnie projektu Eksperci anonimowo wyceniają pracochłonność Eksperci ponownie omawiają projekt i wskazują czynniki, które wzięli pod uwagę w swoich ocenach Wycena i omawianie jest ponawiane aż do uzyskania zadowalająco zbieżnych wyników Inny przykład to „poker planning” w podejściu Scrum 81  Formuła PERT Używana w technikach wyceny eksperckiej Ekspert określa 3 terminy zadania: Optymistyczny (O) – minimalny czas na realizację zadania Pesymistyczny (P) - maksymalny czas na realizację zadania Realistyczny (R) - najbardziej prawdopodobny czas realizacji zadania Oczekiwany czas realizacji jest liczony ze wzoru PERT = (O + 4*R + N) / 6 Można zastosować do czasu realizacji, pracochłonności 82  Ocena przez analogię Polega na porównaniu szacowanego projektu z innymi zrealizowanymi projektami Metoda wymaga zgromadzenia danych o zrealizowanych projektach 83  Szacowanie wstępujące Bottom-up Polega na dekompozycji projektu aż do poziomu pojedynczych zadań Metoda angażuje pracowników, którzy będę wykonywali prace Pracownicy pełnią rolę ekspertów w szacowaniu swoich zadań cząstkowych Szacunek elementu nadrzędnego jest sumą szacunków elementów podrzędnych 84  Modele algorytmiczne Opis przedsięwzięcia przy pomocy atrybutów liczbowy a następnie użycie określonych formuł matematycznych do przeliczenia tych atrybutów na nakład pracy. Stosowane atrybuty Liczba instrukcji kodu źródłowego Punkty funkcyjne Przypadki użycia 85  Model COCOMO COnstructive COst MOdel Ocena złożoności systemu następuje przez zliczenie liczby instrukcji kodu (KDSI = thousands of delivered source code instructions) i określenie klasy przedsięwzięcia. Klasy przedsięwzięcia: Łatwe (organic projects) – małe zespoły o jednolitym poziomie umiejętności; dobrze znana dziedzina; znane metody i narzędzia. Średnie (semi-detached projects) – zróżnicowany zespół; część dziedziny, metod i narzędzi nie jest dobrze znana. Trudny (embeded projects) – bardzo złożone projekty; dziedzina, metody i narzędzia w dużej mierze nie są znane; zespół nie ma doświadczenia. Nakład pracy jest wyliczany ze wzoru: nakład = A * KDSI ^ b, gdzie A i b to stałe uzależnione od klasy przedsięwzięcia. Analogiczne wzory opisują czas realizacji przedsięwzięcia i liczbę osób niezbędnych do realizacji projektu. Np.: nakład pracy dla łatwego przedsięwzięcia o wielkości 10.000 linii kodu = 2,4 * 10 ^ 1,05 = 27 osobomiesięcy. Czas realizacji to 8 miesięcy przy 3,4 osoby w zespole. 86  Metoda punktów funkcyjnych Function Point Analysis Ocena złożoności systemu następuje przez ocenę „ilości” funkcjonalności dostarczonej użytkownikowi przez system Identyfikuje się elementy składowe oprogramowania i określa stopień ich złożoności Rozważane elementy oprogramowania dane wchodzące do systemu (np. ekran wprowadzania danych) dane wychodzące z systemu (np. generowany raport) Zapytania (odczytu danych bez ich modyfikacji) wewnętrzne pliki danych (np. tabela w bazie danych) interfejsy zewnętrzne (wymiana danych z innym systemem) Każdy zidentyfikowany element jest klasyfikowany pod względem jego złożoności (niski / średni / wysoki) Rodzaj elementu, w zależności od stopnia złożoności, jest przeliczany na określoną liczbę punktów funkcyjnych. Punkty funkcyjne, w zależności od przyjętej technologii tworzenia oprogramowania, jest przeliczany na godziny pracy. 87  Metoda Use Case Points Analogiczna do metody punktów funkcyjnych Elementy uwzględniane w tej metodzie Czynniki złożoności środowiska – opisują organizację, która wytwarza oprogramowanie (np. zaznajomienie z projektem, doświadczenie, umiejętności, motywacja, stabilność wymagań, forma zatrudnienia, trudność języka) Czynniki złożoności technicznej – opisują własności produktu (np. czy system rozproszony, wymagana wydajność, użycie zaawansowanych algorytmów, potrzeba re-używalności itp.) Aktorzy i ich sposób komunikacji z klientem Przypadki użycia i ich złożoność Każdy rodzaj elementu jest przeliczany na podstawie określonych wag. Ostatecznie uzyskuje się miarę UCP (Use Case Points). Przemnożenie UCP przez współczynnik produktywności (oryginalnie, przez autora metody szacowany na 20) daje pracochłonność wyrażoną w osobodniach. 88  Analiza make-or-buy Make-or-buy (MOB) Analiza mająca rozstrzygnąć czy przedsięwzięcie ma być wykonane samodzielnie (make), czy komuś zlecone (buy). 89  Fazy cyklu życia oprogramowania Określenie Implementacja Integracja Projektowanie Konserwacja wymagań i testy jednostkowe i testy systemowe Faza Analiza Instalacja strategiczna Dokumentacja 90  Określanie wymagań W tej fazie określane są wymagań klienta wobec tworzonego systemu Wymagania mają być tak zdefiniowane, żeby realizować cele klienta Cel klienta Wymagania System Klient nie jest w stanie sam zdefiniować wymagań. Pomaga mu w tym analityk biznesowy. Faza wymaga dużego zaangażowania klienta 91  Oczekiwane cechy KLIENT ANALITYK Zna cele Ma warsztat analityczny Rozumie cele Myślenie analityczne Zaangażowany Komunikatywność Zna praktykę stosowania Dociekliwość (spojrzenie użytkownika) Cierpliwość Decyzyjność Empatia Odpowiedzialność Zna dziedzinę zastosowań 92  Wymaganie Wymagania mogą mieć różny charakter, na przykład mogą być ogólnym określeniem usług, które system powinien oferować określeniem ograniczenia działania systemu szczegółową, matematycznie formalną definicja funkcji systemu (np. wzory matematyczne) 93  Klasyfikacja przedmiotowa (czego dotyczą) Wymagania funkcjonalne opisują funkcjonalność lub usługi, które system powinien oferować Wymagania niefunkcjonalne określają ograniczenia, przy których system ma realizować swoje funkcje Wymagania dziedzinowe pochodzą z dziedziny zastosowania systemu; mogą być funkcjonalne lub niefunkcjonalne Co robić Ograniczenia Z dziedziny Od klienta 94  Wymagania funkcjonalne Opisują funkcjonalność lub usługi, które system powinien oferować Określają jakie usługi ma oferować system np. system ma pozwalać na wygenerowanie potwierdzenia wykonania przelewu jak system ma reagować na określone dane wejściowe np. jeżeli użytkownik próbuje wykonać przelew na kwotę przekraczającą dostępne środki, … jak system ma się zachowywać w określonych sytuacjach np. jeżeli przelew został wykonany z opcją natychmiastowego potwierdzenia, ma być wyświetlany z ikoną zamkniętej kłódki w niektórych wypadkach, czego system nie powinien robić np. system nie może pozwolić na wygenerowanie potwierdzenia wykonania przelewu, jeżeli przelew jest zlecony, ale niezrealizowany Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania 95  Wymagania niefunkcjonalne Ograniczenia, przy których system ma realizować swoje funkcje Mogą wynikać z potrzeb użytkownika np. generacja potwierdzenia ma trwać maksymalnie 2 sekundy ograniczeń budżetowych np. projekt nie może przekroczyć 1 mln złotych strategii firmy interfejs użytkownika ma spełniać założenia koncepcji omnichannel standardów stosowanych w firmie wraz z systemem ma być dostarczona dokumentacja w języku norwskim konieczności współpracy z innymi systemami wymiana komunikatów z NBP ma być wykonywane zgodnie ze standardem SWIFT czynników zewnętrznych system musi przejść certyfikację Krajowej Izby Clearingowej 96  Klasyfikacja wymagań niefunkcjonalnych Wymagania produktowe Określają zachowanie produktu. Przykładami są wymagania efektywnościowe dotyczące szybkości działania systemu i jego zapotrzebowania na pamięć, wymagania niezawodności. Wymagania organizacyjne Wynikają ze strategii i procedur w firmie klienta i w firmie wytwórcy. Wymagania zewnętrzne Ta szeroka kategoria mieści wszystkie wymagania wynikające z czynników zewnętrznych. Obejmują m.in. wymagania współpracy, które definiują interakcje systemu z systemami innych firm i wymagania prawne. 97  Typy wymagań niefunkcjonalnych Wymagania niefunkcjonalne Wymagania Wymagania Wymagania produktowe organizacyjne zewnętrzne Wymagania Wymagania Wymagania Wymagania Wymagania sprawnościowe niezawodności przenośności współpracy etyczne Wymagania Wymagania Wymagania Wymagania Wymagania prawne użyteczności dostawy implementacyjne standardów Wymagania Wymagania Wymagania Wymagania efektywnościowe pamięciowe ochrony zabezpieczeń prywatności 98  Problemy z wymaganiami niefunkcjonalnymi Zostawiają duży margines do interpretacji Czasem trudno je zweryfikować np. ekran ma być czytelny Mogą być zapisywane w sposób odzwierciedlający ogólne dążenia klienta, takie jak łatwość użycia, zdolność do naprawy awarii i szybka reakcja na działania użytkownika Klienci mogą nie być w stanie przetłumaczyć swoich celów na wymagania ilościowe Wymagania niefunkcjonalne mogą być powiązane z wymaganiami funkcjonalnymi. Mogą być też sprzeczne z funkcjonalnymi. Czasami trudno odróżnić wymagania funkcjonalne i niefunkcjonalne np. klienta ma mieć możliwość generowania potwierdzenia przelewu w formie pliku PDF 99  Miary wymagań niefunkcjonalnych Właściwość Miara Szybkość Liczba przetworzonych transakcji na sekundę Czas reakcji na zdarzenie wywołane przez użytkownika Czas odświeżenia ekranu Rozmiar Kilobajty Liczba układów pamięci Łatwość użycia Czas szkolenia Liczba okien pomocy Niezawodność Średni czas bez awarii Prawdopodobieństwo niedostępności Częstość błędów Dostępność Solidność Czas uruchamiania po awarii Ułamek zdarzeń powodujących awarie Prawdopodobieństwo zniszczenia danych po awarii Przenośność Procent poleceń zależnych od platformy Liczba docelowych systemów 100  Wymagania dziedzinowe Wynikają bardziej z dziedziny zastosowania systemu niż z konkretnych potrzeb użytkowników. Mogą między innymi być nowymi wymaganiami funkcjonalnymi np. Klient ma mieć możliwość odwołania zgody RODO ograniczać istniejące wymagania funkcjonalne np. nie można modyfikować wystawionej faktury ustalać sposób wykonywania konkretnych obliczeń odsetki od kredytu są liczone jako saldo * oprocentowanie roczne / liczba dni Wymagania dziedzinowe są istotne, ponieważ odzwierciedlają podstawy dziedziny zastosowania. Jeśli nie są spełnione, to system nie może działać w sposób zadowalający. 101  Problemy z wymaganiami dziedzinowymi Są one wyrażone za pomocą języka specyficznego dla dziedziny zastosowania, co sprawia, że inżynierowie oprogramowania często ich nie rozumieją. Eksperci z danych dziedzin często mogli pominąć te informację, ponieważ po prostu jest dla nich oczywista. Może nie być jednak oczywista dla twórców systemu, którzy mogą to wymaganie zaimplementować w sposób niesatysfakcjonujący. 102  Klasyfikacja podmiotowa (dla kogo?) Wymagania użytkownika / definicja wymagań (requirement definition) To wyrażenia w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać. Wymagania systemowe / specyfikacja wymagań (requirements specification Szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja wymagań systemowych, zwana czasem specyfikacją funkcjonalną, powinna być precyzyjna. Specyfikacja oprogramowania (software specification) W pełni formalny, abstrakcyjny opis oprogramowania, który jest podstawą do bardziej szczegółowego projektu i implementacji. 103 Czytelnicy różnych rodzajów specyfikacji Wymagania Menedżerowie użytkownika Użytkownicy Inżynierowie Wymagania Użytkownicy systemowe Projektanci Programiści Specyfikacja Projektanci oprogramowania Programiści 104  Wymagania użytkownika Powinny określać wymagania funkcjonalne i niefunkcjonalne tak, aby były zrozumiałe dla użytkowników systemu, którzy nie mają szczegółowej wiedzy technicznej. Należy je zapisywać w języku naturalnym, używając formularzy i prostych intuicyjnych diagramów. 105  Problemy z językiem naturalnym Brak jasności Czasem trudno jest wyrażać się w języku naturalnym precyzyjnie i jednoznacznie bez czynienia dokumentów gadatliwymi i nieczytelnymi. Sprzeczność wymagań Trudno jest jasno rozgraniczać wymagania funkcjonalne, wymagania niefunkcjonalne, cele systemu i elementy projektu. Łączenie wymagań Kilka różnych wymagań może być zapisanych razem jako jedno wymaganie. 106  Dobre praktyki Opracuj standardowy format i spraw, aby wszystkie definicje wymagań były z nim zgodne Konsekwentnie używaj terminów językowych Stosuj wyróżnienia (wytłuszczenia, kursywy) do zaznaczania głównych części wymagania Unikaj żargonu informatycznego Zostaw swobodę projektantom - jeśli wymagania użytkownika zawierają zbyt wiele informacji, to ograniczają wolność twórców systemu w wyborze innowacyjnych rozwiązań oraz utrudniają zrozumienie wymagań Dodawaj uzasadnienia związane z wymaganiami - pomagają wytwórcom i konserwatorom systemu w zrozumieniu, dlaczego takie wymaganie się pojawiło i w ocenie wpływu zmiany tego wymagania 107  Wymagania systemowe Wymagania systemowe są bardziej szczegółowymi opisami wymagań użytkownika. Mogą być podstawą kontraktu na implementacje systemu, powinny być zatem pełną i niesprzeczną specyfikacją całego systemu. Są traktowane przez inżynierów oprogramowania jako punkt wyjścia do projektowania systemu. 108  Strukturalny język naturalny Strukturalny język naturalny jest ograniczoną postacią języka naturalnego, przeznaczoną do zapisywania wymagań systemowych. Zaleta tego podejścia jest to, że zachowując wyrazistość i zrozumiałość języka naturalnego potrafi zapewnić jednolitość specyfikacji. Notacje oparte na języku strukturalnym mogą ograniczać używaną terminologię i obejmować szablony do specyfikowania wymagań systemowych. Zawierają zwykle konstrukcje sterujące podobne do spotykanych w językach oprogramowania i graficzne wyróżnienia do podziału specyfikacji. 109  Formularz opisu wymagań https://medium.com/omarelgabrys-blog/requirements-engineering-elicitation-analysis-part-5-2dd9cffafae8 110  Dokumentacja wymagań Dokumentacja wymagań stawianych oprogramowaniu ( Software Requirements Specification, SRS) jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu. Powinna zawierać zarówno wymagania użytkownika stawiane systemowi, jak i szczegółową specyfikacje wymagań systemowych Nie jest projektem. Powinna opisywać co system ma robić, a nie jak to robić. 111  Użytkownicy dokumentacji wymagań Klienci systemu Określają wymagania i czytają je, aby sprawdzić, czy odpowiadają ich potrzebom. Określają także zmiany wymagań. Menadżerowie Używają dokumentacji wymagań do planowania oferty budowy systemu i do planowania procesu jego tworzenia. Inżynierowie systemu Używają wymagań, aby zrozumieć, jaki system ma być zbudowany. Inżynierowie Używają wymagań, aby opracować testy zatwierdzające testów systemu system. Inżynierowie Używają wymagań jako pomocy w zrozumieniu systemu pielęgnacji systemów i związków między jego częściami. 112 Inżynieria wymagań 113  Inżynieria wymagań Proces wynajdowania, analizowania, dokumentowania oraz sprawdzania usług i ograniczeń nosi nazwę inżynierii wymagań. Istnieją ogólne czynności wysokiego poziomu w procesie inżynierii wymagań: studium wykonalności (faza strategiczna) określenie i analizowanie wymagań specyfikowanie i dokumentowanie wymagań zatwierdzanie wymagań zarządzanie wymaganiami 114  Proces inżynierii wymagań Studium Określanie wykonalności i analizowanie Specyfikowanie wymagań wymagań Zatwierdzanie wymagań Raport o wykonalności Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań 115  Określanie i analizowanie wymagań Po wstępnych studiach wykonalności następną fazą inżynierii wymagań jest określanie i analizowanie wymagań. Analizowanie wymagań to proces iteracyjny, który obejmuje rozpoznanie dziedziny, zbieranie wymagań, klasyfikację, strukturalizację, nadawanie priorytetów i sprawdzanie wymagań. W trakcie tej czynności twórcy oprogramowania pracują z klientem i użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować, pożądanej efektywności, ograniczeniach sprzętowych itd. W określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych stanowisk w firmie. Pojęcie uczestnik odnosi się do każdego, kto powinien mieć pewien pośredni lub bezpośredni wpływ na wymagania systemowe. 116  Proces określania i analizowania wymagań Specyfikacja wymagań Sprawdzenie wymagań Początek procesu Nadawanie Dokumentacja Rozpoznanie priorytetów wymagań dziedziny Usuwanie Zbieranie sprzeczności wymagań Klasyfikacja 117  Problemy analizy wymagań Uczestnicy często nie wiedzą, czego tak naprawdę oczekują od systemu komputerowego. Uczestnicy systemu w naturalny sposób wyrażają wymagania za pomocą własnych pojęć. Różni uczestnicy mogą stawiać różne wymagania. Czynniki polityczne mogą mieć wpływ na system Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest dynamiczne. Nieuchronnie zmienia się w trakcie procesu analizy. 118  Zbieranie wymagań Przykładowe metody Etnografia Scenariusze 119  Etnografia To metoda obserwacji, która może służyć do rozpoznawania wymagań społecznych i organizacyjnych. Analityk pogrąża się w środowisku pracy, w którym system będzie używany. Obserwuje codzienną pracę i odnotowuje podstawowe zadania wykonywane przez pracowników. Zaleta etnografii jest to, że pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie. Wadą etnografii jest to, że bada ona istniejące zachowania, które mogą mieć jakieś historyczne podłoże, które nie jest już odpowiednie. 120  Scenariusze Ludzie zwykle wolą przykłady wzięte z życia niż abstrakcyjne opisy Inżynierowie wymagań mogą skorzystać z informacji zebranych w trakcie dyskusji do formułowania rzeczywistych wymagań systemowych. Scenariusze są szczególnie użyteczne przy uszczegóławianiu przeglądowego opisu wymagań. Są opisami przykładowych sesji interakcyjnych. Każdy scenariusz obejmuje jedną lub najwyżej kilka możliwych interakcji. 121  Elementy scenariusza Opis stanu systemu na początku scenariusza. Klient ma aktywny rachunek ROR prowadzony w PLN Klient chce wykonać szybki przelew Opis normalnego następstwa zdarzeń scenariusza. Klient rejestruje przelew, w tym podaje kwotę przelewu, numer rachunku odbiorcy, tytuł przelew i wskazuje, że ma to być przelew szybki (ExpressElixir) Klient zleca wysłanie przelewu System wyświetla podsumowanie i prosi o zatwierdzenie przelewu Klient zatwierdza przelew Opis tego, co może pójść źle i jak to jest obsługiwane. Podany numer rachunku odbiorcy jest niezgodny z formatem NRB – dyspozycja przelewu zostaje odrzucona; komunikat dla klienta Bank odbiorcy nie obsługuje przelewów szybkich – dyspozycja przelewu zostaje odrzucona; komunikat dla klienta Jest po godzinach pracy systemu ExpressElixir – system proponuje zmianę na zwykły przelew Informacje o innych czynnościach, które można wykonywać w tym samym czasie. Klient może poprosić o wysłanie potwierdzenia przelewu Opis stanu systemu po zakończeniu scenariusza. Saldo rachunku pomniejszone o kwotę przelewu Informacja o przelewie jest w historii operacji na rachunku Przelew został wysłany do EkspressElixir 122  Sprawdzenie wymagań Ważność Użytkownik musi być przekonany, że system powinien spełniać pewne funkcje Niesprzeczność Wymagania zapisane w dokumentacji nie powinny być sprzeczne Kompletność Dokumentacja wymagań powinna zawierać wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia zamierzone przez użytkownika systemu Realność Znając obecną wiedze techniczną, należy sprawdzić, czy wymagania mogą być naprawę zaimplementowane Weryfikowalność Czy wymaganie wyrażono tak, aby można je praktycznie sprawdzić? Zrozumiałość Czy klienci i użytkownicy systemu właściwie zrozumieli wymaganie? Pochodzenie Czy jawnie zaznaczono źródło, z którego pochodzi wymaganie? Giętkość Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe? 123  Zatwierdzanie wymagań Zatwierdzanie wymagań polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik. Ponieważ błędy w dokumentacji wymagań mogą przyczynić się do poważnych kosztów powtarzania prac po sukcesywnym wykrywaniu tych błędów w trakcie tworzenia lub nawet po rozpoczęciu korzystania z systemu. 124  Modele zatwierdzania wymagań Przeglądy wymagań Zespół recenzentów systematycznie analizuje wymagania. Prototypowanie W tym podejściu do zatwierdzania przedstawia się użytkownikom i klientom wykonywalny model systemu. Generowanie testów Idealnie byłoby, aby wymagania dało się testować. Zautomatyzowane sprawdzanie sprzeczności Jeśli wymagania wyrażono w modelu systemu za pomocą strukturalnej lub formalnej notacji, to narzędzia CASE mogą sprawdzić niesprzeczność systemu. 125  Zarządzanie wymaganiami Wymagania stawiane wielkim systemom oprogramowania zawsze się zmieniają. W trakcie procesu tworzenia oprogramowania stopień zrozumienia problemu stale się zmienia, a zmiany te mają zwrotny wpływ na wymagania. 126  Wymagania stałe i zmienne Wymagania stałe to względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu. W szpitalu zawsze będą wymagania dotyczące pacjentów, lekarzy, pielęgniarek, terapii, itp. Wymagania zmienne to wymagania, które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkowania. Takimi wymaganiami są na przykład wymagania, które wynikają z polityki zdrowotnej rządu. 127  Planowanie zarządzania wymaganiami W trakcie tej fazy zarządzania wymaganiami należy podjąć decyzje dotyczące następujących zagadnień: Oznakowanie wymagań Każde wymaganie musi być unikatowo oznakowane tak, aby można było robić do niego odnośniki z innych wymagań i używać tego wymagania przy ocenianiu pochodzenia. Proces zarządzania zmianami Jest to zbiór czynności szacowania wpływu i kosztu zmian. Strategia śledzenia pochodzenia Te strategie definiują zależności między wymaganiami i projektem systemu, które należy odnotowywać. Użycie narzędzi CASE Zarządzanie wymaganiami polega na przetwarzaniu ogromnych ilości informacji o wymaganiach. 128  Korzystanie z narzędzi CASE w zarządzaniu wymaganiami Przechowywania wymagań Wymagania należy gromadzić w zabezpieczonej i administrowanej składnicy danych, która jest dostępna dla wszystkich biorących udział w procesie inżynierii wymagań. Zarządzania zmianami Proces zarządzania zmianami jest znacznie prostszy, gdy aktywnie korzysta się ze wspomagania narzędzi. Zarządzania zależnościami Wspomaganie narzędzi przy śledzeniu zależności umożliwia wykrywanie powiązanych wymagań. 129  Zarządzanie zmianami wymagań Zarządzanie zmianami wymagań należy zastosować do wszystkich postulowanych zmian wymagań. Trzy podstawowe kroki: Analiza problemu i specyfikacja zmiany. Proces rozpoczyna się od rozpoznania problemu z wymaganiem lub czasem od konkretnej propozycji zmiany. Analiza zmiany i ocena kosztów. Korzystając z informacji o uzależnieniu i ogólnej wiedzy o wymaganiach systemowych, ocenia się wpływ proponowanej zmiany. Implementacja zmiany. Modyfikuje się dokumentacje wymagań oraz, jeśli zachodzi taka potrzeba, również projekt i implementacje systemu. 130  Modele kontekstowe We wczesnej fazie procesu określania i analizowania wymagań należy ustalić granice systemu. W niektórych wypadkach granica między systemem, a jego środowiskiem jest dość czytelna. Granice między systemem a jego środowiskiem należy ustalić w trakcie procesu inżynierii wymagań. 131  Kontekst systemu bankomatu System System księgowy zabezpieczeń Baza danych oddziału kont System bankomatu System Baza danych obsługi o użytkowaniu oddziału System konserwacji 132  Fazy cyklu życia oprogramowania Określenie Implementacja Integracja Projektowanie Konserwacja wymagań i testy jednostkowe i testy systemowe Faza Analiza Instalacja strategiczna Dokumentacja 133  Faza analizy Inaczej: faza modelowania Celem fazy analizy jest określenie jak system ma działać, ale bez określenia szczegółów implementacyjnych. Wynikiem analizy jest model logiczny systemu, opisujący sposób realizacji postawionych wymagań. Z jednej strony modelowanie ma pomóc w analizie wymagań stawianych systemom. Z drugiej model jest podstawą do stworzenia projektu w kolejnej fazie cyklu życia systemu. 134  Faza analizy W fazie analizy stosowane są: język naturalny notacje graficzne Wyniki analizy służą jako: materiał wspomagający uzgodnienie wymagań podstawa do wykonania projektu technicznego podstawa do testów systemu element dokumentacji systemu 135  Metody analizy Wyróżniamy dwie grupy metod analizy metody strukturalne (analiza strukturalna) od lat 60-tych wyróżniane są dwa typy składowych systemu pasywne do przechowania danych aktywne wykonujące operacje metody obiektowe (analiza obiektowa) od lat 80-tych dominujące, nadal rozwijane wyróżniają składowe systemu, które łączą możliwość przechowania danych i wykonywania operacji 136 Analiza strukturalna 137  Analiza strukturalna structured analysis Definiuje się dwa modele Model danych – dotyczy pasywnej części systemu Model funkcji – dotyczy aktywnej części systemu Następnie oba modele są integrowane przez model przepływów danych 138 138  Wady analizy strukturalnej Niewystarczająco wspomagają rozpoznawanie i modelowanie niefunkcjonalnych wymagań systemowych. Są ogólne pod tym względem, że zwykle nie zawierają wskazówek pomagających użytkownikom w podjęciu decyzji, czy konkretna metoda jest odpowiednia dla określonego problemu, czy nie. Często nie obejmują porad, jak przystosować wybraną metodę do ustalonego środowiska. Prowadzą zwykle do utworzenia zbyt obszernej dokumentacji. Istota wymagań systemowych może być ukryta w masie zapisanych szczegółów. Opracowane modele są bardzo szczegółowe i użytkownikom trudno jest je zrozumieć. Tacy użytkownicy mają problem z oceną poprawności modelu. 139  Modelowanie danych Opis modelu logicznego danych jest najczęściej realizowany przy pomocy diagramu związków encji (Entity Relationship Diagram – ERD) ERD obejmuje: Encje (ang. entity) Atrybuty encji (ang. attribute) Związki (ang. relationship) 140  Encja Obiekt rzeczywisty lub niematerialny mający znaczenie dla organizacji, o którym informacje muszą być przechowywane. Każda encja musi być jednoznacznie identyfikowalna (rozróżnialna względem pozostałych encji). Np. OSOBA, STUDENT, RODZIC, DZIECKO, ADRES, MIASTO 141  Atrybut encji Właściwość encji Może służyć do identyfikacji encji klasyfikacji encji wyrażenia stanu encji Wartości jakie mogą przyjmować atrybuty są ograniczone przez typ, wielkość i zbiór wartości dopuszczalnych (dziedzina atrybutu). Np. Atrybuty encji OSOBA: Identyfikator Płeć PESEL Imię Nazwisko stan cywilny status w systemie 142  Związki Nazwane, istotne powiązanie między encjami. Związek może być opisany przez nazwę oraz cechy związku: stopień związku – określa liczbę łączonych encji typ asocjacji / kardynalność / liczebność – określa liczbę wystąpień jednej encji z liczbą wystąpień encji powiązanej typ związku – określa, czy do identyfikacji encji podrzędnej konieczna jest znajomość cech encji nadrzędnej istnienie związku / wymagalność – określa czy przy wystąpieniu encji nadrzędnej musi występować encji podrzędna. Np. związek między encjami OSOBA i ADRES 143  Tworzenie modelu danych Możliwe podejścia: Od ogółu do szczegółu / dekompozycja (top-down) – najpierw identyfikujemy encje a potem rozpoznajemy jakie powinna mieć atrybuty pracownik: osoba osoba: zespół: -lokalizacja -Imię -Nazwa -przełożony zespół -Nazwisko -pensja -pensja pracownik -email -początek pracy Od szczegółu do ogółu / synteza (bottom-up) – najpierw szukamy danych atomowych (przyszłych atrybutów encji) a potem łączymy je w encje imię nazwisko imię nazwisko email zespół data startu email data startu lokalizacja przełożony pensja pensja lokalizacja przełożony zespół 144  Notacje ERD Notacja - specyfikacja określająca sposób opisu modelu danych przy wykorzystaniu umownych znaków i symboli graficznych. Wybór notacji może zależeć od przeznaczenia projektowanego modelu praktyki zespołu projektowego posiadanych narzędzi CASE Notacje stosowane w ERD http://pl.wikipedia.org/ 145  Notacja Chen’a Historycznie pierwsza Zawiera Encja jako prostokąt z nazwą encji Atrybuty jako owale połączone z encją, z oznaczeniem atrybutów identyfikujących Związki jako romby z nazwą związku połączone liniami z encjami z oznaczeniem stopnia związku 146  Notacja Crow’s Foot Encja jako prostokąt z nazwą encji Atrybuty z oznaczeniem opcjonalności, przynależności do klucza Związki jako linia łącząca encje 147  ERD – notacja Crow’s Foot Linia opisująca związek zawiera dodatkowe oznaczenia typ asocjacji / kardynalność / liczebność – (oznaczenie zewnętrzne): jeden (kreska) / wiele („krucza stopa”) istnienie związku / wymagalność (oznaczenie wewnętrzne): wymagalne (kreska) / opcjonalne (kółko) Identyfikowalność (ciągłość linii) – identyfikujący (ciągła) / nieidentyfikujący (przerywana) nazwy związku Możliwe kombinacje wymagalności i liczebności związku Jeden i tylko jeden: || Jeden lub brak: O| Jeden lub wiele: |< Zero, jeden lub wiele: O< 148  Modelowanie funkcji systemu Służy zrozumieniu, co organizacja robi lub powinna robić dla osiągnięcia swoich celów oraz do dokumentowania tego w sposób nadający się do przekazania innym osobom. Odpowiada gromadzeniu wymagań funkcjonalnych Stosowane techniki Diagram Hierarchii Funkcji szczegółowa specyfikacja funkcji 149  Diagram Hierarchii Funkcji Functional Hierarchy Diagram Alternatywna nazwa: drzewo hierarchii funkcji Przy tworzeniu stosujemy podejście zstępujące: od góry (ogółu) do dołu (szczegółu) Etapy określamy funkcję najwyższego poziomu, która definiuje najogólniejszy cel organizacji doprecyzowujemy funkcję nadrzędną poprzez określenie funkcji podrzędnych potrzebnych do realizacji funkcji nadrzędnej schodzimy w ten sposób w dół hierarchii, aż do żądanego poziomu szczegółowości sprawdzenie drzewa i ewentualna jego przebudowa 150 Diagram hierarchii funkcji 151  Sprawdzenie diagramu hierarchii funkcji Sprawdzenie polega na odpowiedzi na pytania: Czy jest jeszcze coś co jest konieczne do realizacji funkcji nadrzędnej? Czy jest coś co nie jest konieczne do realizacji funkcji nadrzędnej? Czy każda funkcja przyczynia się do realizacji jakiegoś celu organizacji? Czy sformułowania są zgodne z terminami stosowanymi w organizacji? 152  Techniki Pomocne techniki: Analiza cyklu życia encji Analogie do innych, dobrze nam znanych dziedzin, które wydają nam się częściowo (nie całkowicie) podobne Określenie listy zdarzeń możliwych do wystąpienia i określenie, przez które funkcje będą obsługiwane Stawienie siebie jako obiektu przetwarzanego w systemie 153  Specyfikacja funkcji Na etapie analizy systemu, specyfikacja funkcji może mieć formę opisu w formie formularza Identyfikator F#1.1.1 Nazwa funkcji Dodanie użytkownika innego niż pracownik Banku funkcji. Przeznaczenie Funkcjonalność służy do dodania do systemu użytkownika, który nie jest funkcji pracownikiem Banku. Uprawnienia Operacja może być wykonywana przez użytkowników o rolach: Administrator aplikacyjny Dane wejściowe Imię Nazwisko Telefon Email Firma Dział Dane wyjściowe Identyfikator użytkownika Ogólny opis funkcji Funkcjonalność dostępna dla administratora aplikacji. System pozwala na dodawanie użytkowników, nie będących pracownikami Banku. Pracownicy Banku rejestrowani są w LDAP/AC. Administrator uruchamia funkcjonalność dodawania nowego użytkownika, uzupełnia dane użytkownika na dedykowanym formularzu, akceptuje wprowadzone dane. System generuje identyfikator użytkownika i tworzy nowego użytkownika o statucie Aktywny. 154  Modele przepływu danych Przedstawiają, jak dane są przetwarzane przez system. Notacje używane w tych modelach służą do przedstawiania przetwarzania funkcjonalnego, magazynów danych i przekazywania danych między funkcjami. 155  Diagram przepływu danych DFD (data flow diagram) Przedstawia przepływy danych między elementami systemu Nie definiuje kolejności wykonywanych czynności Elementy diagramu DFD proces (funkcja) - funkcja realizowana w systemie, przekształcająca dane wejściowe na wyjściowe; nazwa procesu powinna wyrażać czynność wykonywaną na określonych danych przepływ danych – powiązanie pomiędzy procesami i innymi elementami; przepływy mają również nazwę; nazwy nie są wymagane dla przepływów do i ze składnic, chyba że są to dane specyficzne składnica danych (zbiór, magazyn) – kolekcja danych przechowywanych przez pewien czas w systemie; składnica powinna być użytkowana przez przynajmniej dwa procesy terminator (obiekt zewnętrzny; interfejs; input/output) – źródło lub przeznaczanie danych – zewnętrzne obiekty, z którymi system się komunikuje – osoby, działy, jednostki org. 156  Notacje DFD Notacja Yourdon/DeMarco Notacja Gane’a-Sarsona (zaimpelementowan w MS Visio) 157 Diagram przepływu danych DFD dla obsługi zamówień 158  DFD możliwe przepływy Nie może być przepływu pomiędzy składnicami lub pomiędzy składnicą z obiektem zewnętrznym Możliwe przepływy: proces – proces proces – składnica danych proces – obiekt zewnętrzny 159  Poziomy DFD Tworzy się kilka poziomów diagramów: Diagram kontekstowy – definiuje zakres i granice systemu; przedstawia pojedynczy proces (rozumiany jako cały system) i jego powiązania z otoczeniem Diagram zerowy (systemowy) – cały system rozpisany na procesy Procesy elementarne – diagramy uszczegóławiające określony proces z diagramu nadrzędnego 160  Analiza obiektowa Object-oriented methods Powstała w latach 80-tych Nadal rozwijana Obecnie dominująca Wyróżniane są składowe systemu, które łączą możliwość przechowania danych i wykonywania operacji. Efektem jest obiektowy model systemu 161  Model obiektowy Wyobrażenie systemu jako oddziałujących na siebie obiektów. Tworząc taki model, nie myśli się w kategoriach operacji i funkcji (jak w analizie strukturalnej) tylko w kategoriach „bytów” (obiektów). Jest naturalnym sposobem odzwierciedlania encji pochodzących ze świata rzeczywistego, które są przetwarzane przez system. Jest to szczególnie widoczne, gdy system przetwarza informacje o konkretnych encjach, które mają łatwe do zidentyfikowania atrybuty. Takimi encjami są np. osoby, samochody, książki. Modele obiektowe opracowywane w trakcie analizy wymagań upraszczają przejście do projektowania i programowania obiektowego. 162  Paradygmaty obiektowości Obiekt Obiekt – „wszystko jest obiektem” – zbiór danych i procedur opisujący konkretny element rzeczywistości opisywanej przez system. Dane są przechowywane jako obiekty. Obiekt ma swój identyfikator niezależny od danych obiektu. Obiekt może składać się z innych obiektów. Każdy obiekt zawiera strukturę (atrybuty) i zachowanie (metody). obiekt metodaA metodaB atrybut1 metodaC atrybut2 metodaD atrybut3 163  Paradygmaty obiektowości Klasa Obiekty o takiej samej strukturze grupowane są w klasy. Obiekt jest instancją jednej klasy. Klasa – abstrakcyjny zbiór obiektów, który identyfikuje ich wspólne atrybuty oraz usługi i operacje oferowane przez te obiekty. Klasa to „typ” obiektu opisujący obiekt atrybuty – „zmienne” klasy metodaA metodaB metody – „funkcje” klasy obiekt metodaA atrybut1 metodaB obiekt Klasa metodaC atrybut2 metodaA obiektmetodaD atrybut1 metodaB Atrybut1 Atrybut2 metodaC atrybut3 metodaAatrybut2 atrybut1 metodaB metodaD Atrybut3 atrybut3 metodaC atrybut2 atrybut1 metodaD MetodaA MetodaB metodaC atrybut3 atrybut2 metodaD MetodaC MetodaD atrybut3 164  Paradygmaty obiektowości Dziedziczenie Klasy zorganizowane są w hierarchę, gdzie klasy podrzędne dziedziczą cechy klas nadrzędnych. Dziedziczenie – jeżeli obiekty klasy X dziedziczy z klasy Y, to dla obiektu klasy X można korzystać ze wszystkich cech klasy Y. Klasa OSOBA Obiekt klasy STUDENT atrybut: Imię atrybut: Imię atrybut: Nazwisko atrybut: Nazwisko metoda: ZmieńNazwisko() atrybut: NrIndeksu metoda: ZmieńNazwisko() Klasa STUDET metoda: DajNrIndeksu() atrybut: NrIndeksu metoda: DajNrIndeksu() 165  Paradygmaty obiektowości Enkapsulacja Enkapsulacja (hermetyzacja) – struktura wewnętrzna obiektu nie jest widziana na zewnątrz obiektu. Dostęp do stanu obiektu jest realizowany przez przekazywanie komunikatów pomiędzy obiektami. obiekt metodaA metodaB atrybut1 metodaC atrybut2 metodaD atrybut3 166  Paradygmaty obiektowości Polimorfizm Klasa podrzędna może redefiniować odziedziczone cechy. Polimorfizm – można stosować metodę o tej samej nazwie do obiektów różnych klas. Klasa OSOBA Obiekt klasy OSOBA atrybut: Imię atrybut: Imię atrybut: Nazwisko atrybut: Nazwisko Jan Kowalski metoda: DajNazwę() metoda: DajNazwę() Obiekt klasy STUDENT Klasa STUDET atrybut: Imię atrybut: NrIndeksu atrybut: Nazwisko metoda: DajNazwę() atrybut: NrIndeksu Jan Kowalski metoda: DajNazwę() (325425) 167  Komunikacja pomiędzy obiektami Obiekty porozumiewają się przez żądania usług (wywołania metod) od innych obiektów, i jeśli trzeba, wymianę informacji niezbędnych do realizacji usługi. Informacje potrzebne do wykonania usługi i wyniki jej wykonania są przekazywane jako parametry. Obiekt odbiorca analizuje składniowo komunikat, rozpoznaje usługę i przekazane dane, a następnie realizuje żądaną usługę. Przykłady komunikacji w językach programowania: nazwa = osoba.DajNazwę() student.ZmieńNazwisko(’Nowak’) 168 UML 169  UML Zunifikowany język modelowania (Unified Modeling Language) Rozwijany przez Object Management Group (OMG) Źródło: http://www.uml.org/ Język graficzny UML jest zbudowany z elementów i przypisanych im symboli, które poprzez graficzną reprezentację są wiązane ze sobą na diagramach. Definiuje zestaw diagramów Najnowsza wersja specyfikacji: OMG UML 2.5 https://www.omg.org/spec/UML/2.5.1/PDF Objęty standaryzacją ISO Standard ISO 19505 170  UML Geneza UML powstał jako synteza trzech metodyk/notacji: OMT (James Rumbaugh): metodyka ta była dobra do modelowania dziedziny przedmiotowej. Nie pokrywała jednak dostatecznie dokładnie zarówno aspektu użytkowników systemu jak i aspektu implementacji/konstrukcji. OOSE (Ivar Jacobson): metodyka ta dobrze podchodziła do kwestii modelowania użytkowników i cyklu życia systemu. Nie przykrywała jednak dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji/konstrukcji. OOAD (Grandy Booch): metodyka dobrze podchodziła do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywała jednak dostatecznie dobrze fazy analizy i rozpoznania wymagań użytkowników. „3 amigos” 171  Historia metod i notacji obiektowych Geneza UML Źródło: https://en.wikipedia.org/wiki/Unified_Modeling_Language 172  Przeznaczenie UML Ogólnie do modelowania systemów Ale nie tylko do modelowania systemów informatycznych Również do: modelowania procesów biznesowych inżynierii systemów reprezentowania struktur organizacyjnych 173  UML vs metodyka UML nie jest metodyką – nie określa w jaki sposób wykorzystać diagramy Dostarcza tylko elementy wykorzystywane w metodykach Podręczniki UML mogą sugerować metodykę, ale konstrukcja i idea języka UML jej nie narzuca. W ramach metodyki konieczne jest określenie: Które diagramy i w jakim zakresie będą wykorzystywane? Jaka będzie kolejność tworzenia diagramów? 174  UML - widoki Widoki pokazują różne właściwości tworzonego systemu, pozwalają spojrzeć na niego z wielu stron. Widoki są abstrakcyjnymi strukturami, które przedstawia się za pomocą zestawu diagramów. Każdy system jest opisywany za pomocą kilku widoków, z których każdy przedstawia inny jego aspekt. 175  UML – widoki Model widoku 4+1 Filipa Kruchtena Widok Widok komponentów logiczny Widok (deployment (logical view) przypadków view) użycia (use case view / Widok Widok scenarios) organizacji procesów (process fizycznej view) (physical view) Oryginalny artykuł: https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf 176  UML - widok przypadków użycia Przedstawia system z punktu widzenia użytkownika, zwanego aktorem. Obrazuje funkcjonalność systemu jakiej aktor oczekuje. Aktor współdziała z systemem, wymienia z nim informacje. Widok jest opisany przede wszystkim przez diagramy przypadków użycia. Widok użytkownika jest kluczowy dla systemu, gdyż przedstawia on to, co system ma wykonywać. 177  UML - widok logiczny Opisuje sposób, w jaki funkcjonalność systemu jest realizowana. W przeciwieństwie do widoku użytkownika, widok logiczny pokazuje wewnętrzną strukturę systemu. Widok ten przedstawia struktur