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

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

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

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

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

Inżynieria wymagań. Inżynieria wymagań 1/1

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

Wykład 1 Inżynieria Oprogramowania

Zasady organizacji projektów informatycznych

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

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

Inżynieria Programowania Inżynieria wymagań

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

Wykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014

Proces Inżynierii Wymagań

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

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

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

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Egzamin / zaliczenie na ocenę*

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Modelowanie i analiza systemów informatycznych

problem w określonym kontekście siły istotę jego rozwiązania

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

Podstawy programowania III WYKŁAD 4

PRZEWODNIK PO PRZEDMIOCIE

UML w Visual Studio. Michał Ciećwierz

Inżynieria oprogramowania. Wykład 6 Analiza i specyfikowanie wymagań

Inżynieria oprogramowania

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

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Faza analizy (modelowania) Faza projektowania

E-1IZ s2. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Inżynieria oprogramowania (Software Engineering)

Przedsięwzięcia Informatyczne w Zarządzaniu

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

Diagramy przypadków użycia

E-I2SG-2010-s1. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

Inżynieria oprogramowania II

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Modelowanie i Programowanie Obiektowe

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Inżynieria Programowania - Projektowanie architektoniczne

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

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES)

Grupy pytań na egzamin inżynierski na kierunku Informatyka

Opis metodyki i procesu produkcji oprogramowania

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Diagramy przepływu danych II model środowiskowy, diagram odpowiedzi na zdarzenia KI AE PSI

Podrozdziały te powinny zawierać informacje istotne z punktu widzenia przyjętego celu pracy

WPROWADZENIE DO UML-a

KIERUNKOWE EFEKTY KSZTAŁCENIA

Modelowanie i analiza systemów informatycznych

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

PROLOG WSTĘP DO INFORMATYKI. Akademia Górniczo-Hutnicza. Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej.

KARTA MODUŁU KSZTAŁCENIA

Technologia programowania

Narzędzia CASE dla.net. Łukasz Popiel

Główne składowe przedsiębiorstwa: procesy,technologia, ludzie, organizacja.

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

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Jarosław Żeliński analityk biznesowy, projektant systemów

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

Jarosław Żeliński analityk biznesowy, projektant systemów

Podejście obiektowe - podstawowe pojęcia

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

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Modelowanie i analiza systemów informatycznych

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA

MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM.

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

PRZEWODNIK PO PRZEDMIOCIE

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

zna metody matematyczne w zakresie niezbędnym do formalnego i ilościowego opisu, zrozumienia i modelowania problemów z różnych

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp Podziękowania...

Diagram przypadków użycia

poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS

Inżynieria Oprogramowania. Robert Szmurło

Projektowanie oprogramowania

KARTA PRZEDMIOTU. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI Ogólne umiejętności posługiwania się komputerem

Cykle życia systemu informatycznego

Inżynieria Programowania Zarządzanie projektem

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

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

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

IO - inżynieria oprogramowania. dr inż. M. Żabińska, zabinska@agh.edu.pl

Analiza biznesowa a metody agile owe

Inżynieria oprogramowania

Analityk i współczesna analiza

Transkrypt:

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

Agenda 1 2 3 4 5 3.2

Czynności w czasie produkcji. Inżynieria stara się zidentyfikować i opisać podstawowe fazy tworzenia i funkcjonowania, a także wskazać model optymalnego przebiegu tych faz. Co można robić w czasie tworzenia? Planowanie (w tym opracowanie wymagań). Implementacja. Testowanie. Dokumentowanie. Wdrożenie. Utrzymanie (konserwacja). 3.3

Ogólny schemat. 3.4

funkcjonalne i niefunkcjonalne. funkcjonalne Sa stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. Opisuja funkcjonalność lub usługi, które system powinien oferować. niefunkcjonalne Ograniczenia usług i funkcji systemu. Obejmuja ograniczenia czasowe, ograniczenia procesu tworzenia, standardy itd. Moga być zwiazane z właściwościami systemu (niezawodność, czas reakcji, zajętość pamięci itd.), definiować ograniczenia systemu itp. Nie dotycza bezpośrednio funkcji systemu. dziedzinowe. Pochodza z dziedziny zastosowania systemu i odzwierciedlaja jej charakterystykę. Moga moga być funkcjonalne lub niefunkcjonalne. 3.5

użytkownika. użytkownika Wyrażanie w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać. dość wysoki poziom abstrakcji nie powinny z góry definiować rozwiazań powinno dać się spełnić takie wymagania korzystajac z różnych podejść wymagaja uściślenia 3.6

systemowe. systemowe Szczegółowo ustalaja usługi systemu i ograniczenia. Dokumentacja wymagań systemowych (specyfikacja funkcjonalna) powinna być precyzyjna. Może służyć jako kontrakt między nabywca systemu a wytwórca. Specyfikacja projektu. Abstrakcyjny opis projektu, który jest podstawa bardziej szczegółowego projektu i implementacji. Poszerza specyfikację wymagań systemowych. 3.7

Dokumentacja wymagań (IEEE/ANSI 830-1993) 1 Wstęp. 2 Ogólny opis. 1 Wizja produktu. 2 Funkcje produktu. 3 Charakterystyka użytkowników. 4 Ogólne ograniczenia. 5 Założenia i zależności. 3 Szczegółowe wymagania. funkcjonalne, niefunkcjonalne, interfejsy etc. Najbardziej istotna części dokumentu. Definicja jak powinna wygladać ta część nie jest zalecana, ponieważ mocno zależy do praktyki w firmie i dziedziny zagadnień. 4 Dodatki. 5 Skorowidz. 3.8

.. Proces, który obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych. 4 główne czynności: 1 Studium wykonalności. 2 Określenie i analizowanie wymagań. 3 Specyfikowania i dokumentowanie wymagań. 4 Zatwierdzanie wymagań. 3.9

Studium wykonalności. Studium wykonalności. Krótki, skumulowane opracowanie, w którym staramy się odpowiedzieć na pytania: 1 Czy system przyczyni się do realizacji ogólnych celów (przedsiębiorstwa)? 2 Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? 3 Czy system może być zintegrowany z istniej acymi systemami, które już zainstalowano? 3.10

Określenie i analiza wymagań. Rozpoznanie dziedziny Analitycy musza zrozumieć dziedzinę zastosowania. Zbieranie wymagań Proces interakcji z uczestnikami systemu, którego celem jest ujawnienie wymagań. Klasyfikacja Podział na grupy. Usuwanie sprzeczności podane przez różne grupy nieuchronnie będzie zawierać sprzeczności. Nadawanie priorytetów Interakcja z uczestnikami w celu wskazania najważniejszych wymagań w grupie. Sprawdzanie wymagań Czy wymagania sa spójne i zgodne z tym czego uczestnicy chca od systemu. 3.11

Zatwierdzanie wymagań. Czy wymagania naprawdę definiuja system, którego chce użytkownik? 1 Sprawdzenie ważności. 2 Sprawdzenie niesprzeczności. 3 Sprawdzenie kompletności. 4 Sprawdzenie realności. 5 Możliwość weryfikacji. Metody sprawdzania wymagań: Przeglad wymagań.. Generowanie testów. Zautomatyzowane sprawdzanie niesprzeczności. 3.12

Zarzadzanie wymaganiami. Zmiany gospodarcze, organizacyjne i technologiczne nieuchronnie prowadza do zmian wymagań stawianych. Zarzadzanie wymaganiami to proces kierowania i panowania nad tymi zmianami. Proces zarzadzania wymaganiami obejmuje: 1 planowanie, w trakcie którego specyfikuje się proces zarzadzania i zarzadzanie zmianami 1 Analiza problemu u specyfikacja zmiany. 2 Analiza zmiany i ocena kosztów. 3 Implementacja zmiany. 2 zarz adzanie zmianami, które polega na analizowaniu zmian i szacowaniu ich wpływu 3.13

Co to sa? Model systemu Graficzna reprezentacja na której przedstawia się, problem do rozwiazania i system do zbudowania. bardziej zrozumiałe niż szczegółowy opis wymagań etap pośredni między analiza a projektowaniem służa wypracowaniu lepszego zrozumienia systemu moga służyć do zobrazowania systemu z różnych punktów widzenia: 1 Zewnętrznego (modeluje się kontekst lub środowisko systemu). 2 Zachowania (modeluje się zachowanie systemu). 3 Strukturalnego (architektura systemu lub struktura danych). 3.14

Modele kontekstowe. należy ustalić granice systemu rozróżnić co jest systemem a co jego środowiskiem należy opracować prosty model architektoniczny opisuje się środowisko systemu, nie współpracę system-otoczenie 3.15

Modele kontekstowe. 3.16

Modele zachowania. Model przepływu danych. pokazuja jak dane przepływaja w sekwencji kroków przetwarzania jak dane podlegaja przekształceniu w modelu analitycznym "kroki"to przetwarzanie przez ludzi i komputery w dokumentacji projektowej"kroki"to funkcje/metody programu Model maszyn stanowych. służa do opisywania zachowania systemu jak reaguje na zewnętrzne i wewnętrzne bodźce zawiera stany(1) i zdarzenia (2), które powoduja przejścia z jednego stanu do drugiego nie obejmuje przepływu danych w ramach systemu 3.17

Diagram przepływu danych. 3.18

Diagram stanów. 3.19

Modele obiektowe. moga przedstawiać sam system (diagramy struktur) jak i jego działanie(diagramy zachowań) posługuja się pojęciem klasy i obiektu. Klasa obiektu. Abstrakcja zbioru obiektów, która identyfikuje ich wspólne atrybuty (w znaczeniu modelu danych) oraz usługi i operacje oferowane przez te obiekty. Obiekt Wykonywalna encja, posiadajaca atrybuty i operacje klasy. Egzemplarz klasy obiektów. Wiele obiektów może powstać z tej samej klasy. na ogół analityczne sa poświęcone klasom obiektów i ich zwiazkom 3.20

Modele obiektowe. Diagram hierarchii klas. 3.21

Modele obiektowe. Diagram agregacji klas. 3.22

Modele obiektowe. Diagram sekwencji. 3.23

CASE. Narzędzia CASE. Narzędzia Computer Aided Software Engineering to zbiór narzędzi, które wspomagaja konkretny etap procesu tworzenia. Często łaczone w jeden zestaw narzędzi (warsztat). Zestaw narzędzi CASE do analizy i projektowania, zawiera: Edytory diagramów. Narzędzia do analizy i sprawdzania projektu. Języki zapytań do repozytorium. Słownik danych. Narzędzia do definiowania i generowania raportów. Narzędzia do definiowania formularzy. Udogodnienia do importu i eksportu. Generatory kodu. 3.24

w procesie tworzenie. ewolucyjne. Celem jest dostarczenie użytkownikowi działajacego systemu. Zaczyna się od tych wymagań, które sa najlepiej rozpoznane i maja najwyższy priorytet. mniej jasne lub o mniejszym priorytecie sa implementowane tylko gdy zażadaj a tego użytkownicy. z porzuceniem. Celem jest zatwierdzenie lub dostarczenie wymagań systemowych. Zaczyna się od tych wymagań, które nie sa dobrze rozpoznane, aby dowiedzieć się więcej. oczywiste nie musza podlegać prototypowaniu. 3.25

Metody błyskawicznego prototypowania. Metody błyskawicznego prototypowania. Metody tworzenia, których przeznaczeniem jest skrócenie czasu dostarczania, a nie poprawa właściwości systemu (efektywności, niezawodności itd...) Istnieja trzy główne metody błyskawicznego prototypowania: 1 Tworzenie za pomoca dynamicznych języków wysokiego poziomu. 2 Programowanie baz danych. 3 Scalanie komponentów i programów użytkowych. 3.26

interfejsu użytkownika. 3.27