Analiza wymagań funkcjonalnych. Po wykonaniu identyfikacji wymagań (patrz: Techniki pozyskiwania wymagań) należy przeprowadzić ich analizę celem uszczegółowienia, ewentualnego odrzucenia wymagań sprzecznych lub nieprawidłowych oraz określenia priorytetu i ryzyka. Analiza wymagań funkcjonalnych umożliwia zidentyfikowanie i opisanie pożądanego zachowania systemu. Zgodnie z jedną z definicji, wymaganie funkcjonalne to „stwierdzenie, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić”. Szczegółowe wymagania funkcjonalne muszą opisywać możliwości systemu w zakresie zachowania oraz dostępnych operacji (czynności wykonywane przez system, odpowiedzi na akcje użytkownika).
Wymagania funkcjonalne powinny opisywać: Dobra dokumentacja wymagań nie powinna nadmiernie ograniczać projektu aplikacji, to znaczy narzucać konkretnego rozwiązania architektonicznego. Zarządzanie wymaganiami. Zarządzanie wymaganiami – jest dziedziną zajmującą się działaniami mającymi na celu przełożenie potrzeb lub oczekiwań użytkowników w stosunku do konstruowanej, fizycznej realizacji produktu końcowego. Pojęcie zarządzania wymaganiami w szerokim kontekście odnosi się do metod specyfikowania użytecznych cech wszelkiego rodzaju produktów (np. umów handlowych, budowli, cech urządzeń itp.).
Podczas zbierania wymagań dotyczących produktu należy odpowiednio rozdzielić je pomiędzy dostępne klasy. Dobrze zaprojektowane systemy gromadzą wymagania w każdej z tych pięciu grup, nie powodując zbyt jednoznacznego nastawienia na jedną z nich. W zarządzaniu wymaganiami może być zastosowany osobny język do projektowania graficznego SysML, bazujący na standardach UML. Etapy wytwarzania oprogramowania[edytuj | edytuj kod] Realizacja zadań związanych z zarządzaniem wymaganiami w dużej mierze zależy od etapu, w jakim jest realizacja projektu.
Etap rozpoznawania (investigation)[edytuj | edytuj kod] Przypadek użycia. Historia[edytuj | edytuj kod] W 1986 Ivar Jacobson, informatyk zaangażowany w tworzenie Unified Modeling Language (UML) oraz Rational Unified Process (RUP) opisał technikę do specyfikowania przypadków użycia. Z początku używał określeń: scenariusz użytkowania (usage scenarios) i przypadki użytkowania (usage case). W latach 90. przypadki użycia stały się powszechnie stosowanym sposobem opisu wymagań funkcjonalnych. Opis ogólny[edytuj | edytuj kod] Ta sekcja jest niekompletna. Jeśli możesz, rozbuduj ją. Przypadek użycia powinien: Pisanie przypadków użycia[edytuj | edytuj kod] Poziom szczegółowości[edytuj | edytuj kod] Alistair Cockburn w swojej książce Writing Effective Use Cases[1] wyróżnia 3 poziomy szczegółowości przypadków użycia: nieformalny opis – kilka luźnych zdań ogólnie opisujących przypadekformalny opis – kilka paragrafów, podsumowaniepełen opis – formalny dokument Nazewnictwo[edytuj | edytuj kod] Zaleca się, aby przypadki użycia posiadały nazwy odpowiadające czynnościom, które opisują.
Wymaganie. Ten artykuł dotyczy inżynierii. Zobacz też: Potrzeba.. Wymaganie w inżynierii, jest pojedynczą, udokumentowaną potrzebą określonego produktu czy usługi, albo sposobu ich działania. Formalnie jest to wykorzystywane powszechniej w inżynierii systemów lub w inżynierii oprogramowania. Jest to stwierdzenie identyfikujące potrzebne cechy, możliwości, charakterystyki lub jakość systemu, aby był on wartościowy i pożyteczny dla użytkownika. W klasycznej inżynierii, zbiór wymagań jest wykorzystywany w fazie projektowania nowego produktu. Wymagania pokazują, jakie elementy i funkcje są niezbędne w konkretnym projekcie. Projekty są podmiotem trzech rodzajów wymagań. Wymagania produktowe i procesowe są ściśle powiązane. W inżynierii systemów wymaganie może być opisem tego co system musi wykonywać w postaci wymagania funkcjonalnego. Zbiór wymagań definiuje charakterystyki lub cechy oczekiwanego systemu.
Wymagania są dzielone na następujące kategorie: Wszystkie wymagania powinny być weryfikowalne. ERD | Diagram związków encji. Przykłady diagramów ERD w różnych notacjach Diagram związków encji lub Diagram ERD (od ang. Entity-Relationship Diagram) – rodzaj graficznego przedstawienia związków pomiędzy encjami używany w projektowaniu systemów informacyjnych do przedstawienia konceptualnych modeli danych używanych w systemie.
Systemy CASE, które wspierają tworzenia tych diagramów, mogą na ich podstawie automatycznie tworzyć bazy danych odpowiadające relacjom na diagramie. Diagram pokazuje logiczne związki pomiędzy różnymi encjami, związki te mają dwie cechy: Opcjonalność – która mówi o tym, czy każda encja musi, czy też może wystąpić równocześnie z inną. Np. TOWAR musi zostać zakupiony przez co najmniej jednego KLIENTA, ale KLIENT może być nabywcą TOWARU. 1:1 ("jeden do jeden") – encji odpowiada dokładnie jedna encja,1:N ("jeden do wielu") – encji odpowiada jedna lub więcej encji,M:N ("wiele do wielu") – jednej lub więcej encjom odpowiada jedna lub więcej encji.
UML. Przykładowe diagramy UML Format otwarty UML (ang. Unified Modeling Language, czyli Zunifikowany Język Modelowania) – język formalny wykorzystywany do modelowania różnego rodzaju systemów, stworzony przez Grady Boocha, Jamesa Rumbaugha oraz Ivara Jacobsona, obecnie rozwijany przez Object Management Group[1]. UML jest oficjalnie zdefiniowany przez Object Management Group (OMG) w tzw. metamodelu UML – Meta-Object Facility (MOF). Jak inne specyfikacje bazujące na Meta-Object Facility, metamodel UML i modele UML mogą być serializowane (zapisywane) w języku XML Metadata Interchange (XMI), opartym na standardzie XML.
Choć UML był zaprojektowany, by definiować, wizualizować, konstruować i dokumentować systemy kładące nacisk na oprogramowanie, nie jest on ograniczony do modelowania oprogramowania. UML jest używany także do modelowania procesów biznesowych, inżynierii systemów i reprezentowania struktur organizacyjnych. Historia UML[edytuj | edytuj kod] Metody[edytuj | edytuj kod] Lista narzędzi UML. UML tools for software development and modelling - Enterprise Architect UML modeling tool. Proces biznesowy. Proces biznesowy lub metoda biznesowa – seria powiązanych ze sobą działań lub zadań, które rozwiązują określony problem lub prowadzą do osiągnięcia określonego efektu. Proces biznesowy często jest opisywany schematem blokowym.
Typy procesów biznesowych Proces zarządczy, który kieruje działaniem systemu. Typowym przykładem może być proces zarządzania przedsiębiorstwem lub zarządzania strategicznego.Proces operacyjny, który stanowi istotę biznesu i jest pierwotnym źródłem wartości dodanej, np: zaopatrzenie, produkcja, marketing, sprzedaż.Proces pomocniczy, który wspiera procesy główne, np: księgowość, rekrutacja, wsparcie techniczne. Proces biznesowy wynika z potrzeb klientów, a jego wynikiem jest zaspokojenie tych potrzeb. W organizacji zorientowanej procesowo powinny przełamywać bariery jednostek organizacyjnych i zapobiegać funkcjonalnym silosom. Proces biznesowy można podzielić na podprocesy o własnych atrybutach, które dają wkład w rezultat procesu nadrzędnego. Workflow. Workflow (ang. work flow – przepływ pracy) – w sensie szerszym, pojęcie określające sposób przepływu informacji pomiędzy rozmaitymi obiektami biorącymi udział w jej przetwarzaniu.
W węższym sensie jest to określenie sposobu przepływu dokumentów pomiędzy pracownikami wykonującymi pewien zalgorytmizowany zespół czynności. Według koalicji WFMC (ang. WorkFlow Management Coalition) workflow to: "automatyzacja procesów biznesowych, w całości lub w części, podczas której dokumenty, informacje lub zadania są przekazywane od jednego uczestnika do następnego, według odpowiednich procedur zarządczych". Pojęcie workflow jest używane w odniesieniu do oprogramowania, zwłaszcza służącego wspomaganiu pracy grupowej. Oprogramowanie takie pozwala na określenie jakie role w przetwarzaniu dokumentów pełnią osoby uczestniczące w wykonywaniu danej czynności oraz jakie są stany pośrednie dokumentów.
Struktura Podziału Pracy | The Work Breakdown Structure (WBS) Wiele projektów- szczególnie na początku – wydaje się być zbyt złożonymi. Zastanawiamy się, jak zacząć. The Work Breakdown Structure (WBS) jest specjalną techniką szkicowania tego, co jest zakresem przedsięwzięcia za pomocą hierarchicznej struktury drzewa. WBS jest szczególnie przydatny do planowania projektu i odpowiada na pytanie CO? Projekt dostarcza (produkty lub usługi wspierające) a nie JAK? KIEDY? DLACZEGO? KTO? Dlaczego warto na początku realizacji projektu stworzyć WBS? Pomaga wszystkim zrozumieć zakres projektu, jest podstawą do określenia wszystkich przyszłych działań w projekcie, jest przydatny do estymowania czasu realizacji projektu, jest przydatny do przypisania odpowiedzialności za poszczególne zdekomponowane elementy, jest przydatny do mierzenia postępu podczas realizacji projektu, możemy go wykorzystać jako odniesienie (szablon) do przyszłych projektów. kto jest odbiorcą projektu, będzie korzystał z jego efektów?
Jakie są ograniczenia, założenia? MS Excel MS Visio Przykład: Diagram Przypadków Użycia. Przypadek użycia Jest przypadkiem, w którym dany system jest używany w celu spełniania jednego lub większej liczby wymagań użytkowników.Wychwytuje fragment funkcji udostępnianych przez system.Określają wymagania funkcjonalne systemu. Przypadki użycia Przypadki użycia dotykają każdej innej części projektu systemu.Przypadki użycia nie określają wymagań niefunkcjonalnych systemu Wychwytywanie przypadków użycia Analiza opisu systemu z punktu widzenia przyszłego użytkownika.Wymagania konieczne (bez nich system nie będzie funkcjonował).Wymagania opcjonalne (pożądane, mogą być porzucone jako pierwsze w chwili napotkania nieprzewidzianych trudności w chwili napotkania nieprzewidzianych trudności w realizacji systemu.Których funkcji aktor oczekuje od systemu? Czy aktor musi czytać, modyfikować, tworzyć lub likwidować pewne informacje w systemie?
Aktorzy Aktorzy mogą być: Rozpoznawanie aktorów Kto będzie używał podstawowych funkcji? Notacja Zależności między przypadkami użycia Dziedziczenie przypadków użycia. DFD | Diagram przepływu danych. Diagram przepływu danych (DPD lub z ang. DFD – Data Flow Diagram) – graficzna prezentacja przepływu danych w procesie. Na proces składają się następujące elementy: Funkcje — (procesy) realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje, wówczas nosi ona nazwę elementarnej.Magazyny danych – trwałe lub tymczasowe składnice danych, które są argumentami dla funkcji.Terminatory – obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub argumentów funkcji.Przepływy – elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..).
DFD obrazuje za pomocą przepływów kierunek przepływu danych pomiędzy funkcjami, magazynami i obiektami zewnętrznymi. DFD mogą być prezentowane na różnych stopniach szczegółowości, mówimy o: SOA | Architektura zorientowana na usługi. Architektura oparta na usługach (ang. Service-Oriented Architecture, SOA) – koncepcja tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie usług, które spełnią wymagania użytkownika. Pojęcie SOA obejmuje zestaw metod organizacyjnych i technicznych mający na celu lepsze powiązanie biznesowej strony organizacji z jej zasobami informatycznymi.
Do modelowania procesów biznesowych realizowanych w SOA można wykorzystywać notację BPMN przygotowaną m.in. do opisu tej klasy zagadnień. W modelach takich komunikacja z usługami jest modelowana jako zdarzenia typu wyślij/odbierz wiadomość (komunikat) zawierająca odpowiednie dane wysłane/pobierane do/od usługi. BPMN | Business Process Modeling Notation. Business Process Model and Notation, BPMN (Notacja i Model Procesu biznesowego) – graficzna notacja służąca do opisywania procesów biznesowych. Jest zgodna z koncepcją architektury SOA. Powstała w ramach Business Process Management Initiative, obecnie jest utrzymywana przez konsorcjum Object Management Group.
Aktualna wersja standardu to 2.0. We wcześniejszych wersjach nazwa BPMN była rozwijana jako Business Process Modeling Notation. Dużą zaletą tej notacji jest jej jednoznaczność, przydatność zarówno do opisów procesów na potrzeby oprogramowania klasy ERP, jak i Workflow oraz to, że wspiera ją ponad 70 narzędzi. Notację tę obsługują m.in. narzędzia iGrafx, ADONIS, Borland, DYSANT i IBM. iGrafx oferuje również możliwość przejścia z modelu BPMN na model BPEL.
Metodą wymiany danych pomiędzy narzędziami BPMN są XPDL i BPMN XML. BPMN opisuje dwa typy relacji procesów: Złożone struktury choreografii można zapisać diagramem: Konwersacji – „Conversation” Połączenia: Miejsca realizacji procesu: BPEL | Business Process Execution Language. BPEL (ang. Business Process Execution Language for Web Services, pełna nazwa Web Services Business Process Execution Language, WS-BPEL) – oparty na XML język do definiowania procesów biznesowych opartych o usługi sieciowe, będący standardem OASIS. Każdy proces biznesowy zdefiniowany w BPEL również jest usługą sieciową i może wchodzić w skład innych procesów. Koncepcja[edytuj | edytuj kod] Interakcje między usługami sieciowymi mogą być rozpatrywane w dwóch kategoriach: abstrakcyjnych procesów oraz wykonywalnych procesów. Rola języka WS-BPEL rozpoczyna się tam, gdzie kończy WSDL, który opisuje interfejs pojedynczej usługi. Historia[edytuj | edytuj kod] IBM oraz Microsoft rozwijały początkowo swoje własne języki do programowania wielkoskalowego, dość podobne do siebie: WSFL oraz XLANG.
Zasada działania[edytuj | edytuj kod] Założenia projektowe[edytuj | edytuj kod] BPEL posiada dziesięć głównych założeń projektowych: Język BPEL[edytuj | edytuj kod] Narzędzia[edytuj | edytuj kod] BPML | Business Process Modeling Language. Business Process Modeling Language (BPML) – konkurencyjny do BPEL XMLowy język do opisu procesów. Właścicielem tego standardu jest Business Process Management Initiative. Ciekawostką jest to, że BPMN również opracowany przez BPMI pozwala na automatyczne tłumaczenie postaci graficznej do kodu konkurencyjnego języka BPEL. Linki zewnętrzne[edytuj | edytuj kod]