Analiza/Inżynieria wymagań

Wielkość: px
Rozpocząć pokaz od strony:

Download "Analiza/Inżynieria wymagań"

Transkrypt

1 Znaczenie inżynierii wymagań Analiza/Inżynieria wymagań In nearly every software project which fails to meet performance and cost goals, requirements inadequacies play a major and expensive role in project failure, Alford and Lawson Development of requirements specification in many cases seems trivial, but it is probably the part of the process which leads to more failures than any other, Schwartz Definicja Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software intensive technologies. Definicja inżynierii Engineering is the development of costeffective solutions to practical problems, through the application of scientific knowledge Co to są wymagania Podstawowe zasady Warto rozróżniać sformułowanie problemu od jego rozwiązania Pełna separacja nie jest możliwa rozwiązanie zmienia oryginalny problem Źródła trudności Klient z reguły nie wie dokładanie w jaki sposób osiągnąć założone cele. Cele te można osiągnąć na wiele sposobów. Duże systemy są wykorzystywane przez wielu użytkowników. Ich cele są często sprzeczne. Różni użytkownicy mogą posługiwać się inną terminologia mówiąc o tych samych problemach. Zleceniodawcy i użytkownicy to często inne osoby. 1

2 Problemy w zbieraniu wymagań Rozproszenie wiedzy dziedzinowej Nikt nie wie wszystkiego (co jest nam potrzebne) Niejawna wiedza Wiem, ale nie umiem wytłumaczyć Trudne obserwacje Czas Obserwator zmienia zachowanie Ukierunkowanie (bias) Nie mogę powiedzieć Nie chcę powiedzieć Cele przedsięwzięcia Klienta, np. Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Użytkownicy, nabywcy, różni partnerzy biznesowi mogą mieć różne cele Wykonawcy Biznesowe Techniczne Priorytety! Rozwiązywany problem Cele warto też formułować w kategoriach rozwiązywania pewnych problemów Koszty są zbyt wysokie Jest zbyt wiele błędów Nie można tego zrobić w sposób tradycyjny Kontekst systemu Użytkownicy role Istniejące oprogramowanie Specyficzny sprzęt Planner tras komunikacją miejską Użytkownicy Cele: szybko i wygodnie sprawdzić jak gdzieś dojechać, czy można/warto dojechać, o której wyjść Problemy: brak znajomości rozkładów, trudne planowanie trasy na podstawie rozkładów Przewoźnicy Cel: pozyskać użytkowników Problem: użytkownicy nie wiedzą czy i jak skorzystać z komunikacji miejskiej Planner tras komunikacją miejską Kontekst Systemy przewoźników Urządzeni z usługą lokalizacji 2

3 Internetowy system planowania wyjazdów (wycieczek) turystycznych Użytkownicy Indywidualni turyści Biura podróży Konsultanci np. pracownicy biura informacji turystycznej Problem: planowanie wycieczki jest żmudne, a efekty często niezadowalające Cele: wygodne, szybkie planowanie udanych wyjazdów turystycznych Edytorzy Administratorzy Internetowy system planowania wyjazdów turystycznych Klienci Nabywcy operatorzy instancji systemu Cele: osiągnięcie zysku, zdobycie dużej liczby użytkowników i partnerów biznesowych Partnerzy biznesowi nabywców pośredni użytkownicy właściciele atrakcji turystycznych, hotele, przewoźnicy, operatorzy systemów rezerwacji, biura podróży, biura promocji turystyki Cel: uzyskanie klientów dla swoich usług Internetowy system planowania wyjazdów turystycznych Kontekst (poza użytkownikami) Istniejący system optymalizacji wycieczek Istniejące systemy rezerwacji hoteli i biletów Istniejące systemy promocji turystyki Elektroniczny rynek usług transportowych Użytkownicy Zleceniodawcy przewozów (to mogą być te same firmy) Problemy: wysokie koszty realizacji jednorazowych, zwłaszcza niewielkich zleceń, trudność znalezienia przewoźnika Cele: obniżenie kosztów, zapewnienie wysokiej jakości realizacji zleceń Firmy przewozowe Problemy: nieprzewidywalność zleceń - nadmiar lub brak zleceń Cele: zdobycie opłacalnych zleceń zapewniających dobre wykorzystanie zasobów Administratorzy Elektroniczny rynek usług transportowych Klienci operatorzy systemu (wirtualna firma transportowa) Cele: osiągnięcie zysku zdobycie wielu klientów Kontekst istniejące systemy informatyczne przewoźników i zleceniodawców Analiza SWOT Siły i słabości wewnątrz organizacji: Strengths silne strony Weaknesses słabe strony Czynniki zewnętrzne Opportunities szanse Threats zagrożenia zewnętrzne ryzyka 3

4 SWOT - Elektroniczny rynek usług transportowych Strengths Dobra znajomość i kontakty na rynku przewoźników Sprawność w zakresie wytwarzania oprogramowania Opportunities Rosnąca konkurencja na rynku przewozów Duże rozdrobnienie rynku przewoźników Postępująca informatyzacja zleceniodawców i przewoźników Weaknesses Słaba znajomość rynku zleceniodawców Brak doświadczenia na rynku pośrednictwa w zakresie przewozów Threats Konkurencyjne systemy ogłoszeniowe Niezbędny efekt skali Potrzebna integracja z dużą liczbą różnych systemów informatycznych Określanie wymagań Współpraca klienta i wykonawcy! Źródła: Wywiady z przedstawicielami klienta Analiza materiałów dostarczonych przez klienta, przepisów prawnych Porównanie z innymi systemami Techniki zbierania wymagań Wywiady Tradycyjne Introspekcja Analiza istniejących dokumentów Analiza danych Wywiady Otwarte Ustruktaralizowane Ankiety Spotkania Zespołowe Techniki grupowe (np. burze mózgów) JAD/RAD Prototypowanie Participatory design Kognitywne Analiza zadań Techniki zbierania wiedzy Kontekstowe Techniki etnograficzne Analiza dyskusji Socjotechniczne Soft systems analysis Zalety Duża ilość informacji Możliwość głębokiej analizy kontynuacja ciekawych wątków Wady Dużo nieuporządkowanych informacji jakościowych Trudne porównywanie odpowiedzi różnych osób Wymaga umiejętności i doświadczenia Uważaj na: Wiedzę niejawną Brak kontekstu Nastawienie rozmówcy Wskazówki dotyczące wywiadów Początek Zacznij od ogólnych uwag rozluźniających atmosferę Pogoda, fotografia na biurku Zapytaj czy możesz nagrywać rozmowę Umieść urządzenie w widocznym miejscu Powiedz, że rozmówca może zawsze wyłączyć nagrywanie Zacznij od łatwych pytań Kontynuuj interesujące wątki Zostaw otwarte pytania na koniec Czy chciałby Pan coś jeszcze dodać? Ankiety Zalety Szybkie źródło dużych ilości informacji Mogą być zbierane zdalnie Dostarczają informacji o nastawieniu, przekonaniach, charakterystykach Wady Ograniczone, uproszczone Uważaj na Dobór próby ankietowanych Małe próby Otwarte pytania trudne do analizy Pytania sugerujące odpowiedź Ankietę należy prototypować i testować 4

5 Techniki grupowe Zalety Bardziej naturalne niż formalne wywiady Wykorzystanie dodatkowych pomocy (tablica ) Wady Sztuczne grupy Myślenie grupowe Wymaga dobrego moderatora Uważaj na Zły dobór grupy Zależności (służbowe) pomiędzy uczestnikami Rodzaje wymagań Wymagania funkcjonalne funkcje wspomagane przez oprogramowania - przypadki użycia (use cases) Wymagania niefunkcjonalne ograniczenia Diagramy przypadków użycia use case diagrams Użytkownik, klasa użytkowników, system zewnętrzny (ang. actor) Grupa użytkowników wykorzystujących system w podobny sposób Diagramy przypadków użycia use case diagrams Korzystanie z funkcji (ang. actor flow) Przypadek użycia, wymaganie funkcjonalne, funckja (ang. use case) Związki używania (use)) i rozszerzania (extend) Dodawanie kategorii pojazdow Uzywane sporadycznie, podczas dodawania pojazdu, jezeli nie ma jeszcze danej kategorii Przykład i związek generalizacji (generalization) Uzytkownik «extend» Przewoznik Wydawanie opinii Zleceniodawca «use» Edycja pojazdów «use» Dodawanie pojazdu Zarzadzanie pojazdami Optymalizacja Zarzadzanie uzytkownikami Zarzadzanie ladunkami Przewoznik «use» Usuwanie pojazdow Edycja pojazdu Administrator 5

6 Przykład: Hierarchia wymagań funkcjonalnych Ewidencja klientów Dodawanie klienta Edycja danych klienta Usuwanie klienta Wyszukiwanie klientów Wyszukiwanie proste Wyszukiwanie złożone Sposoby poszukiwania wymagań funkcjonalnych Wykorzystanie hierarchii wymagań Z góry na dół Z dołu do góry Podejście mieszane Wykorzystanie informacji o rolach użytkowników Śledzenie procesów biznesowych Analiza scenariuszy Z góry na dół Z dołu do góry Metoda mieszana Wykorzystanie informacji o rolach użytkowników f4 f2 Kierownik f1 Ksiegowy f3 f6 f5 f9 f7 f8 Kasjer Magazynier 6

7 Zalety Cechy System może być stosunkowo prosty z punktu widzenia większości użytkowników Wady Punkty widzenia użytkowników mogą być niespójne Potrzeba integracji Śledzenie procesów biznesowych Proces zbiór czynności wykonywanych przez różne osoby i działy organizacji scharakteryzowany przez: Wejście Wyjście (wynik) Cele Zadania Proces biznesowy proces, którego wynik ma wartość biznesową Śledzenie procesów biznesowych U1 f3 f1 f2 U2 f5 f4 U3 f8 f6 f7 Proces obsługi klienta pół- hurtowego 1. Dział sprzedaży wybór produktów, sformułowanie zamówienia połączone z weryfikacją dostępności produktów 2. Magazyn ponowna weryfikacja, skompletowanie zamówienia 3. Księgowość wystawienie faktury, rozliczenie finansowe 4. Magazyn wydanie towarów Business process modeling notation - BPMN Standard OMG De facto standard przemysłowy BPMN przykład Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, kierunek Informatyka 7

8 Analiza scenariuszy Scenariusz słowny opis przykładowego sposobu (scenariusza) korzystania z systemu Z reguły obejmuje wiele funkcji Analiza scenariuszy - przykład Użytkownik podaje podstawowe informacje o planowanym wyjeździe. Chce odwiedzić Polskę, spędzić tam tydzień, wjedzie i wyjedzie od strony Czech. Interesują go ciekawe miasta, wykopaliska archeologiczne i wydarzenia muzyczne (muzyka klasyczna). Określa ograniczenia finansowe. System generuje proponowany plan podróży biorąc pod uwagę podane preferencje i ograniczenia. Analiza scenariuszy przykład c. d. Użytkownik może szczegółowo przeglądać proponowaną trasę korzystając m. in. z prezentacji multimedialnych System proponuje użytkownikowi potencjalne modyfikacje trasy, biorąc pod uwagę położenie geograficzne poszczególnych atrakcji oraz wybory innych użytkowników o podobnych preferencjach Analiza scenariuszy przykład c. d. Użytkownik modyfikuje trasę dodając do niej wizytę w Biskupinie i rezygnując z wizyty w Gnieźnie Użytkownik akceptuje trasę i otrzymuje jej szczegółowy opis (wydruk, plik) Użytkownik wybiera funkcję rezerwacji hoteli. Po dokonaniu niewielkiej opłaty system współpracując z zewnętrznym systemem rezerwacji hotelowej dokonuje odpowiednich rezerwacji Funkcje wynikające ze scenariusza Definiowanie ograniczeń i preferencji Generowanie planu podróży Przeglądanie trasy Wizualizacja geograficzna Prezentacja harmonogramu trasy Multimedialne prezentacje atrakcji Generowanie i prezentacja proponowanych zmian Funkcje wynikające ze scenariusza Modyfikowanie trasy Akceptowanie trasy Przygotowanie szczegółowego opisu trasy Rezerwacja hoteli Pobieranie opłaty Rezerwacja hotelu 8

9 Analiza scenariuszy Użytkownik wchodzi na naszą stronę i ponieważ korzystał z niej już wcześniej wybiera od razu opcję wyszukiwania. Najpierw określa kraj, który go interesuje Szwajcaria, a następnie miasto Zurich. Użytkownik wybiera rodzaj oferty turystycznej narty. Ponieważ uprawianie narciarstwa w samym Zurichu nie jest możliwe otrzymuje listę kilku pobliskich stacji narciarskich. Użytkownik zapoznaje się z informacjami o kilku stacjach narciarskich trasy, wyciągi, ceny, możliwość wypożyczenia sprzętu oraz aktualne warunki śniegowe. Użytkownik sprawdza możliwość dojazdu z Zurichu do stacji narciarskiej Flumsberg. Sprawdza też możliwości zakwaterowania w (pobliżu) Flumsbergu. Ostatecznie dokonuje rezerwacji biletu rail&ski i pokoju w pensjonacie we Flumsbergu. Funkcje wynikające ze scenariusza Wybór obszaru zainteresowania Wybór kraju Wybór miasta Wybór rodzaju oferty turystycznej Przeglądanie ofert stacji narciarskich Wyszukiwanie możliwości dojazdu Wyszukiwanie możliwości zakwaterowania Rezerwacja Rezerwacja biletów Rezerwacja miejsc noclegowych Analiza scenariuszy Do magazynu zgłasza się klient, który złożył zamówienie w dziale sprzedaży. Klient podaje numer zamówienia, lub inną informację identyfikującą klienta. Magazynier odszukuje zamówienie w systemie i weryfikuje czy zamówiony towar został już zablokowany dla potrzeb klienta. Jeżeli tak, to potwierdza przyjęcie zamówienia do realizacji i prosi klienta o przejście do księgowości. Magazynier otrzymuje listę towarów do wydania wraz z ich lokalizacjami. Po skompletowaniu zamówienia potwierdza ten fakt w systemie. Po wydaniu towaru klientowi potwierdza ten fakt w systemie. Funkcje wynikające ze scenariusza Realizacja zamówienia Identyfikacja zamówienia Weryfikacja zablokowania towaru Potwierdzenie przyjęcia zamówienia do realizacji Potwierdzenie skompletowania zamówienia Potwierdzenie wydania towaru Zalety Cechy Naturalne dla użytkowników Przydatne w wyjaśnianiu znaczenia systemu/funkcji Podstawa testów akceptacyjnych i dokumentacji użytkowej Wady Niepełne Niespójne Specyfikacja wymagań Język naturalny 79% Metody formalne 5% Formularze 16% 9

10 Elementy specyfikacji wymagań Nazwa Opis Dane wejściowe i ich źródła Wynik Warunki początkowe i końcowe Efekty uboczne Wyjątki Priorytet Źródło wymagania Wymagania powiązane Uzasadnienie Wymagania niefunkcjonalne Ograniczenia dotyczące Produktu Procesu Współpracy z systemami zewnętrznymi Problem specyfikacji wymagań niefunkcjonalnych w sposób weryfikowalny Specyfikacja wymagań niefunkcjonalnych w sposób weryfikowalny Wydajność Liczba transakcji obsłużonych w ciągu sekundy Czas odpowiedzi Szybkość odświeżania ekranu Rozmiar Wymagana pamięć RAM Wymagana pamięć dyskowa Łatwość użytkowania Czas niezbędny dla przeszkolenia użytkowników Liczba stron dokumentacji Zgodność ze standardami Ostrzezenie Wykonanie tej operacji spowoduje utrate wszystkich wyników obliczen. Czy chcesz kontynuowac? Nie Tak Specyfikacja wymagań niefunkcjonalnych w sposób weryfikowalny Niezawodność Prawdopodobieństwo błędnego wykonania podczas realizacji transakcji Częstotliwość występowania błędnych wykonań Średni czas pomiędzy błędnymi wykonaniami Dostępność (procent czasu, w którym system jest dostępny) Odporność (ang. robustness) Czas restartu po awarii systemu Prawdopodobieństwo zniszczenia danych w przypadku awarii Przenośność Procent kodu zależnego od platformy docelowej Liczba platform docelowych Koszt przeniesienia na nową platformę Zestaw praktyk Sommerville a, Sawyera Dokument opisujący wymagania Zbieranie wymagań (requirements elicitation) Analiza i negocjowanie wymagań Opis wymagań Modelowanie systemu Atestowanie wymagań (requirements validation) Zarządzanie wymaganiami 10

11 Dokument opisujący wymagania - praktyki Ustandaryzuj strukturę dokumentu Wyjaśnij jak korzystać z dokumentu Dodaj podsumowanie wymagań Uzasadnij wartość biznesową systemu Zdefiniuj specjalistyczne terminy Zorganizuj dokument w czytelny sposób Pomóż czytelnikom znaleźć informacje Uczyń dokument łatwym z zmianach Zalety: Ustandaryzuj strukturę dokumentu Lepsza czytelność Pomoc w opracowywaniu dokumentu Możliwość automatyzacji Standard powinien dopuszczać różne warianty Struktura wg. IEEE/ANSI Introduction 1.1 Purpose of the requirements document 1.2 Scope of the product 1.3 Definitions, acronyms, abbreviations 1.4 References 1.5 Overview of the reminder of the document 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User charactristics 2.4 General characteristics 2.5 Assumptions and dependencies 3. Specific requirement Appendices Index Wyjaśnij jak korzystać z dokumentu Dołącz sekcję jak korzystać z dokumentu Przede wszystkim w jaki sposób powinni z niego korzystać różni czytelnicy użytkownicy, analitycy, wykonawcy, kierownicy Dodaj podsumowanie wymagań Sekcja Overview cel, założenia główne wymagania Uzasadnij wartość biznesową systemu Odpowiednia sekcja w dokumencie 11

12 Zdefiniuj specjalistyczne terminy Np. sekcja glossary Także terminy używane w ramach dokumentu w zawężonym, specyficznym znaczeniu Np. printer Zorganizuj dokument w czytelny sposób Dokument opisujący wymagania jest często czytany Ogólne zasady czytelności tekstu Krótkie akapity Krótkie zdania Podział na sekcje Wyróżniki, wyliczenia Wykorzystanie prostych diagramów wraz z dobrymi wyjaśnieniami Pomóż czytelnikom znaleźć informacje Indeks Czytelna organizacja Najlepsza forma elektroniczna - wyszukiwanie Uczyń dokument łatwym z zmianach Wymagania będą się zmieniać Łatwiejsze w formie elektronicznej Zbieranie wymagań (requirements elicitation) - praktyki Oceń wykonalność systemu Weź pod uwagę względy organizacyjne i polityczne Zidentyfikuj i skonsultuj zainteresowane strony Zapisuj źródła wymagań Zdefiniuj środowisko pracy Kieruj procesem poszukiwania wymagań biorąc pod uwagę względy biznesowe Szukaj ograniczeń dziedzinowych Zbieranie wymagań (requirements elicitation) - praktyki Zapisuj uzasadnienia wymagań Zbieraj wymagania z różnych punktów widzenia Prototypuj źle rozumiane wymagania Używaj scenariuszy do zbierania wymagań Zdefiniuj procesy, w których będzie wykorzystywany system Ponownie wykorzystuj wymagania 12

13 Oceń wykonalność systemu Studium wykonalności powinno zawsze poprzedzać intensywniejsze inwestycje w pracę nad systemem, w tym zbieranie szczegółowych wymagań Zarówno kwestie techniczne, jak i biznesowe Weź pod uwagę względy organizacyjne i polityczne Czynniki organizacyjne i polityczne (często niejawne) mogą wpływać (np. utrudniać) proces zbierania wymagań Lęk przed utratą wpływów/pracy Konfliktowe cele Kultura współzawodnictwa Różne sposoby pracy Zidentyfikuj i skonsultuj zainteresowane strony Zainteresowane strony (stakeholders): Użytkownicy końcowi (różne klasy) Zarząd Klienci Wykonawcy Administratorzy Ciała zewnętrzne urzędy, organizacje certyfikujące Zalety Pełniejszy zestaw wymagań Przekonanie do systemu wszystkich zainteresowanych stron Zapisuj źródła wymagań Osoba, grupa organizacja, od której pochodzi wymaganie Inne źródła standardy, dokumenty, raporty W wielu wypadkach niezbędne okazuje się wyjaśnienie wątpliwości dotyczących wymagań Czasem sama informacja o źródle wyjaśnia te wątpliwości Zdefiniuj środowisko pracy Platforma sprzętowa i programowa Interfejsy z innymi systemami Zależność od innych programów (np. założenie, że użytkownik ma dostęp do maila nawet jeżeli nasz system nie łączy się z nim bezpośrednio)..., np. rozmieszczenie fizyczne Należy brać pod uwagę zmiany środowiska Kieruj procesem poszukiwania wymagań biorąc pod uwagę względy biznesowe Względy biznesowe (business concerns) ogólne biznesowe cele klienta Użyteczny system musi wspomagać realizację biznesowych celów klienta Wpływają na priorytet celów szczegółowych i wymagań 13

14 Szukaj ograniczeń dziedzinowych Ograniczenia, które występują obiektywnie (niezależnie od naszego systemu) w dziedzinie problemu Np. ograniczenia związane z bankowością, podatkami, itd. Generują wymagania niefunkcjonalne Wykazanie zgodności z tymi wymaganiami może być niezbędne do wdrożenia systemu Zapisuj uzasadnienia wymagań Powinno być specyfikowane przez osobę (grupę) będąca źródłem wymagań Ułatwia zrozumienie wymagań Ułatwia nadawanie priorytetów Zbieraj wymagania z różnych punktów widzenia Punkty widzenia (i zbiory wymagań) zainteresowanych strony, w tym różnych klas użytkowników Zalety Ułatwia proces zbierania wymagań Zapewnia pełniejszy obraz systemu Ułatwia nadawanie priorytetów wymagania istotne dla wielu stron są z reguły ważniejsze Rodzaje punktów widzenia Interaktorów (interactors) użytkownicy, inne systemy Zainteresowanych stron nie będących bezpośrednimi użytkownikami Dziedziny problemu wymagania wynikające z samej dziedziny problemu, a nie pochodzące od konkretnych osób lub organizacji Bardzo ważna jest krosowe sprawdzenie (cross checking) wymagań i ich integracja Prototypuj źle rozumiane wymagania Ułatwia zrozumienie (efektu) wymagań Bardzo efektywne w przypadku wymagań związanych z interfejsem użytkownika Czasami pozwala zaniechać realizacji niepotrzebnego/niewykonalnego systemu Czasami prototyp może mieć dodatkowe zastosowania: Może być w jakimś stopniu wykorzystywany przez użytkownika Może zostać częściowo wykorzystany w pełnym systemie (choć z założenia jest porzucany) Może służyć do szkoleń, dalszych demonstracji Techniki prototypowania Cel szybko, tanio osiągnąć cel prototypowania Papier Czarodziej z Oz Programowanie Nie wszystkie wymagania można prototypować np. efektywność, niezawodność 14

15 Używaj scenariuszy do zbierania wymagań Stosunkowo łatwe dla użytkownika Pozwala odkryć nowe wymagania Ma wiele zalet podobnych do prototypowania Z reguły nie opisują systemu w pełni Większe systemy mogą wymagać dużej liczby scenariuszy kilkadziesiąt, kilkaset Opis scenariusza Stan systemu przed rozpoczęciem scenariusza Normalny przebieg wydarzeń Możliwe wyjątki Informacje o innych czynnościach, które mogą zachodzić w tym samym czasie Opis systemu po zakończeniu scenariusza Zwykle 3-4 strony + tabele, rysunki Często pewne części scenariuszy mogą być ponownie wykorzystane Zdefiniuj procesy, w których będzie wykorzystywany system Przeznaczenie systemu można często opisać jako wspomaganie jednego lub wielu procesów biznesowych Pozwala zidentyfikować: Role użytkowników i zainteresowanych stron Procesy często będą już opisane: Modele biznesowe Modele dla systemów workflow Procesy są często bardzo skomplikowane, ich tworzenie od podstaw może być bardzo kosztowne Ponownie wykorzystuj wymagania W podobnych systemach nawet 80% wymagań może być ponownie wykorzystane Zalety Redukcja kosztów Redukcja ryzyka Może prowadzić do ponownego wykorzystania modelu, projektu, kodu i testów Sposoby wykorzystania wymagań Bezpośredni przeniesienie wymagań Często niemożliwe Kwestia praw do wymagań Pośredni wykorzystanie w procesie zbierania wymagań Np. poddanie krytyce istniejących wymagań dla podobnego systemu Analiza i negocjowanie wymagań Cel ustalenie kompletnego, niesprzecznego zbioru wymagań akceptowanego przez wszystkie zainteresowane strony Wykrycie brakujących wymagań Wykrycie konfliktowych wymagań Wykrycie niejasnych wymagań Wykrycie wymagań zachodzących na siebie Wykrycie nierealistycznych wymagań Analiza i negocjowanie przeplata się ze zbieraniem wymagań 15

16 Analiza i negocjowanie wymagań Zdefiniuj granice systemu Wykorzystaj listę kontrolną do analizy wymagań Wykorzystaj narzędzia wspomagające negocjacje Planując weź pod uwagę konflikty i ich rozwiązywanie Określ priorytety wymagań Stwórz wielowymiarową klasyfikację wymagań Wykorzystaj tablice interakcji (interaction matrices) ) do znalezienia konfliktów i nakładających się wymagań Oceń ryzyko wymagań Zdefiniuj granice systemu Część wstępnie określonych wymagań może nie dotyczyć systemu lecz jego otoczenia Granice systemu powinny być określone już na podstawie ogólnych wymagań Przykłady wymagań spoza granic systemu Wymagania związane z podejmowaniem decyzji trudnych do zamodelowania Wymagania wymagające informacje niedostępnych systemowi Wymagania nieistotne z punktu widzenia głównych celów systemu Wymagania dotyczą funkcjonalności lub ograniczeń wobec zewnętrznych programów lub sprzętu Wykorzystaj listę kontrolną do analizy wymagań Zestaw punktów/pytań, pod kątem których analizowane jest każde wymaganie Około 10 punktów Nie jest (pełną) weryfikacją jakości Ryzyko zbytniego skupienia się na liście i niedostrzegania innych problemów Przykładowa lista Czy wymaganie wprowadza zbyt szybkich założeń co do projektu? Czy wymaganie nie powinno być rozbite na kilka oddzielnych? Czy wymaganie jest potrzebne? Czy wymaganie wymaga niestandardowego sprzętu? Czy wymaganie jest zrozumiałe/jednoznaczne? Czy wymaganie jest realistyczne? Czy wymaganie jest weryfikowalne/testowalne? Wykorzystaj narzędzia wspomagające negocjacje Podstawowe narzędzia , komunikatory, listy dyskusyjne, programy konferencyjne Zaawansowane wspierające negocjacje raczej etap badawczy Zalety Redukcja kosztu Redukcja barier osobowych Szybkie wyjaśnienie prostych wątpliwości 16

17 Planując weź pod uwagę konflikty i ich rozwiązywanie Poważne wątpliwości i konflikty powinny być rozwiązywane podczas poświęconych temu spotkań Pojawienie się konfliktów nie jest błędem lecz sytuacja typową Określ priorytety wymagań Wspomaga wybór wymagań do realizacji Ułatwia rozwiązywanie konfliktów Ułatwia projektowanie Priorytety powinny być nadawane wtedy, kiedy znany jest w miarę kompletny zestaw wymagań Różne zainteresowane strony mogą inaczej widzieć priorytety wymagań Określ priorytety wymagań Niewielka liczba klas, np.: Niezbędne Użyteczne Przydatne Przydatne pytania: Co jeżeli implementacja tego wymagania podwoi koszty systemu? Co jeżeli implementacja tego wymagania uniemożliwi realizacja wymagania XYZ? Zalety: Stwórz wielowymiarową klasyfikację wymagań Wykrycie związków pomiędzy wymaganiami, w tym sprzeczności i nakładania się Ułatwia śledzenie (traceability)) wymagań i wprowadzanie zmian Ułatwia wykrycie brakujących wymagań Przykładowe klasy Systemowe wydajność, niezawodność Interfejs użytkownika Baza danych Komunikacja (z zewnętrznymi systemami) Bezpieczeństwo Wykorzystaj tablice interakcji (interaction matrices) ) do znalezienia konfliktów i nakładających się wymagań Może być trudne dla dużej liczby wymagań 17

18 Oceń ryzyko wymagań Dla każdego wymagania lub grupy wymagań: Potencjalne problemy Prawdopodobieństwo ich wystąpienia Możliwe efekty Pozwala przewidzieć problemy jakie mogą się pojawić w trakcie realizacji systemu Często prowadzi do wykrycia źle, np. niekompletnie opisanych wymagań Przykłady ryzyk Wydajność Bezpieczeństwo Ochrona Proces konieczność zmian w procesie wytwarzania oprogramowania Technologia realizacji Baza danych np. duże, niestrukturalne zbiory danych Harmonogram Ryzyka zewnętrzne np. konieczność współpracy z zewnętrznymi kooperantami Stabilność/zmienność Opis wymagań - praktyki Zdefiniuj szablony dla opisu wymagań Pisz prosto, spójnie i krótko Używaj diagramów w miarę potrzeb Uzupełniaj opis słowny dodatkowymi formami opisu Specyfikuj wymagania w sposób ilościowy Zdefiniuj szablony dla opisu wymagań Zalety Ułatwiają zbieranie informacji służą jako lista kontrolna Zwiększają przejrzystość opisu Usprawniają proces opisywania wymagań skracają czas, zmniejszają liczbę błędów Wymagania są czytane częściej niż pisane Pisz prosto, spójnie i krótko Skraca czas czytania Zwiększa zbiór odbiorców wymagania Unikać: Długich, złożonych zdań Długich akapitów Skomplikowanej terminologii Zalecenia Krótkie zdania Nigdy nie zamieszczać więcej niż jednego wymagania w jednym zdaniu System ma... i... Unikać specjalistycznego żargonu Np. CASE w zarządzaniu to studium przypadku Krótkie akapity Listy, tabele Spójne użycie terminologii Wyraźne rozróżnianie tego co konieczne od tego co pożądane 18

19 Zalecenia Unikaj zagnieżdżonych wyrażeń warunkowych Np. jeżeli X, to jeżeli Y to R1a, w przeciwnym wypadku jeżeli Z, to R1b, a w przeciwnym wypadku R1c (kiedy R1c?) Jeżeli jest to niezbędne lepiej zastosować inny zapis niż język naturalny formalizm matematyczny, diagram Unikaj opisu skomplikowanych zaleźności w języku naturalnym stosuj np. diagramy Forma aktywna Unikaj anonimowych odwołań do innych sekcji dokumentu, innych wymagań, rysunków, tabel I oczywiście dbaj o poprawność Używaj diagramów w miarę potrzeb Diagramy ilustrujące Strukturę Zależności Sekwencje, np. zdarzeń, zadań Wykresy pokazujące zależności liczbowe Z reguły należy unikać stosowania specjalistycznych notacji Ostrożne używanie kolorów i ikon Diagramy są bardzo przydatne w prezentacjach dla klienta Uzupełniaj! opis słowny dodatkowymi formami opisu Przykłady Tablice decyzyjne Kod, pseudokod Zapis algebraiczny Diagramy przepływu danych Wykresy Gantt a UML Notacje stosowane w ramach dziedziny problemu Zalety: Większa precyzja Mniej błędów w zapisie i interpretacji Specyfikuj wymagania w sposób ilościowy Dotyczy zwłaszcza wymagań niefunkcjonalnych Ważną sprawą jest dobór odpowiednich metryk Modelowanie systemu Zbuduj model systemu Zamodeluj otoczenie systemu Zamodeluj architekturę systemu Wykorzystuj metodykę modelowania Wykorzystuj słownik danych Dokumentuj powiązania pomiedzy wymaganiami a elementami modelu Atestowanie wymagań (requirements validation) - praktyki Zweryfikuj czy dokument wymagań jest zgodny ze standardami Zorganizuj formalne przeglądy wymagań Używaj specjalistów z różnych dziedzin do przeglądów wymagań Zdefiniuj listy kontrolne atestowania Używaj prototypów do animacji wymagań Napisz draft podręcznika użytkownika Zaproponuj przypadki testowe Opisz słownie model systemu 19

20 Cele Analiza dotyczy roboczych wersji wymagań Atestowanie dotyczy prawie gotowego dokumentu (final draft) Nie istnieje obiektywna informacja, względem której można weryfikować wymagania Zweryfikuj czy dokument wymagań jest zgodny ze standardami Szybkie sprawdzenie poprzedzające ogólny przegląd jedna osoba Ułatwia i skraca czas ogólnego przeglądu Zorganizuj formalne przeglądy wymagań Formalne przeglądy techniczne dotyczące wymagań W odróżnieniu od innych przeglądów technicznych często obejmują dyskusję nad rozwiązaniem problemów Typowe problemy: Niejasności Brakujące informacje Konflikty Nierealistyczne wymagania 40 wymagań / h? Używaj specjalistów z różnych dziedzin do przeglądów wymagań Użytkownicy Przedstawiciele klienta Eksperci dziedzinowi Inżynierowie Zdefiniuj listy kontrolne atestowania Pozwalają skupić uwagę recenzentów na najważniejszych sprawach Wprowadzają strukturę do procesu oceny Wspomagają naukę osób początkujących Elementy listy kontrolnej Czy wymagania są kompletne (jako całość, cała grupa)? Czy wymagania są spójne, zgodne? Czy wymagania są zrozumiałe? Czy wymagania są niejednoznaczne? Czy opis wymagań ma odpowiednią strukturę (np. powiązania, grupowanie)? Czy można śledzić powiązania? Czy opis poszczególnych wymagań i cały dokument jest zgodny ze standardami? 20

21 Używaj prototypów do animacji wymagań Eksperymentalne sprawdzenie wymagań Atestowanie wymaga pełniejszego prototypu niż analiza. Powinien obejmować wszystkie wymagania Użytkownicy powinni pracować samodzielnie Odpowiedni dobór użytkowników Wskazówki dotyczące oceny, np. raport błędów Zalety Napisz draft podręcznika użytkownika Wymusza dokładną analizę wymagań Przydatne dla osób oceniających prototyp Podstawa ostatecznej dokumentacji użytkowej Nie zastępuje dokumentu wymagań Zaproponuj przypadki testowe Dla każdego wymagania zaproponuj jeden lub kilka testów Zalety Ułatwia wykrycie problemów. Trudność w zaproponowaniu przypadków testowych często wynika z problemów z samymi wymaganiami. Podstawa przyszłych testów systemu. Pytania Jakie scenariusze mogą być przydatne przy opracowywaniu testów? Czy opis danego wymagania zawiera wystarczające informacje do opracowania testów? Może wskazywać na istotne powiązania pomiędzy wymaganiami. Czy potrzebnych jest jeden czy wiele testów? Czy możne zreformułować wymaganie, aby ułatwić jego testowanie. Opisz słownie model systemu Notacje graficzne, np. UML nie są zrozumiałe dla większości zaangażowanych stron użytkowników, ekspertów dziedzinowych Zarządzanie wymaganiami (requirements management) - praktyki Jednoznacznie zidentyfikuj każde wymaganie Zdefiniuj zasady (policy)) zarządzania wymaganiami Zdefiniuj zasady śledzenia powiązań (traceability) Utrzymuj podręcznik śledzenia powiązań (traceability manual) Korzystaj z bazy danych wymagań Zdefiniuj zasady modyfikowania wymagań Zidentyfikuj globalne wymagania systemu Zidentyfikuj wymagania zmienne (volatile) Zachowuj odrzucone wymagania 21

22 Zarządzanie wymaganiami Główne zagadnienia Zarządzanie zmianami Błędy, nieporozumienia, zmiany w otoczeniu Zarządzanie powiązań pomiędzy wymaganiami Zarządzanie powiązań pomiędzy wymaganiami a innymi artefaktami przedsięwzięcia Zapewnienie realizacji wymagań Ocena kosztów proponowanych zmian Jednoznacznie zidentyfikuj każde wymaganie Niezbędne przy wprowadzaniu powiązań pomiędzy wymaganiami Pozwala śledzić wymagania, których opis się zmienił Naturalne w systemach elektronicznych Zdefiniuj zasady (policy) zarządzania wymaganiami Cele zarządzania wymaganiami Standardy i procedury postępowania Część systemu zapewniania jakości firmy Zasady (policy)) mówią co należy zrobić, standardy i procedury mówią jak to zrobić w konkretnych sytuacjach Elementy zasad zarządzania wymaganiami Cele i ich uzasadnienie Niezbędne raporty Niezbędne standardy Zasady zarządzania zmianami i kontroli realizacji wymagań Zasady przeglądów i atestowania wymagań Powiązania pomiędzy zasadami zarządzania wymaganiami a innymi obszarami zarządzania Zasady śledzenia powiązań Warunki, w których te zasady mogą zostać zaniechane Zdefiniuj zasady śledzenia powiązań (traceability) Przykłady powiązań: Wymagania- źródła Wymagania uzasadnienia Wymagania wymagania Wymagania składowe architektury Wymagania składowe projektu Wymagania interfejsy (do zewnętrznych systemów) Przykładowe typy powiązań Wymaga Jest wymagany przez Specyfikuje 22

23 Zasady śledzenia powiązań Jakie powiązania powinny być zapamietywane? Jak je reprezentować? Kiedy wprowadzać powiązania? Sytuacje wyjątkowe możliwość zaniechania zasad Utrzymuj podręcznik śledzenia powiązań (traceability manual) Dodatek do dokumentu wymagań Specyficzne zasady śledzenia powiązań obowiązujące w danym projekcie Najlepiej, jeżeli jest dostępny ogólnie w formie elektronicznej Specyficzne czynniki dotyczące projektu brane pod uwagę Liczba wymagań Szacowany czas budowy i ewolucji systemu Poziom dojrzałości organizacji Rozmiar i skład zespołu Typ systemu Korzystaj z bazy danych wymagań Ogólnie korzystanie z narzędzi wspomagających zarządzanie wymaganiami Zalety: łatwiejsze przechowywanie powiązań pomiędzy wymaganiami oraz pomiędzy wymaganiami i innymi artefaktami praca równoległa przetwarzanie, np. raporty Zdefiniuj zasady modyfikowania wymagań Zasady proponowania, oceny, przeglądów i wprowadzania zmian Główne zalety: całościowa ocena wpływu zmian lepsza kontrola kosztów możliwość śledzenia ewolucji wymagań możliwość proponowania zmian przez wszystkie zainteresowane strony Zidentyfikuj globalne wymagania systemu Wymagania globalne: definiują pożądane lub niezbędne wymagania wobec całego systemu nie dotyczą poszczególnych fragmentów systemu Zmiany w wymaganiach globalnych mogą być bardzo trudne/kosztowne do wprowadzenia. Wymagają w związku z tym szczególnej uwagi. 23

24 Identyfikacja wymagań globalnych Czy jest wyrażone w bardzo ogólny sposób? np. dane w bazie danych muszą zawsze pozostawać poprawne Czy wyraża ogólną, niefunkcjonalną własność systemu? system musi obsługiwać N transakcji na sekundę Czy jest to ogólne wymaganie dotyczące interfejsu użytkownika? Odpowiedzi tak wskazują na wymagania globalne Identyfikacja wymagań globalnych Czy wymaganie dotyczy konkretne funkcji/usługi systemu? Czy wymaganie można powiązać z konkretnym fragmentem systemu? Czy wymaganie można powiązać z konkretnymi danymi w systemie? Odpowiedzi nie wskazują na wymagania globalne Zidentyfikuj wymagania zmienne (volatile) Należy identyfikować i w miarę możliwości przewidywać zmienne wymagania Zalety: zmienność wymagań można uwzględnić projektując system zmienność tych wymagań można uwzględnić w planie przedsięwzięcia Rodzaje zmiennych wymagań Mutujące (mutable) zmienne w wyniku częstych zian w otoczeniu systemu Pojawiające/rozwijające się (emergent) nie mogą być w pełni zdefiniowane na początku przedsięwzięcia Wynikowe (consequential) wynikają z pewnych założeń co do sposobu korzystania z systemu, które mogą okazać się niewłaściwe Związane ze zgodnością (compatibility) zależą od zewnętrznych systemów (oprogramowanie, sprzęt) Zachowuj odrzucone wymagania Odrzucone wymagania często pojawiają się ponownie może to oznaczać, że istnieją poważne powody, aby takie wymaganie jednak wprowadzić może to oznaczać, że ponownie proponowane wymagania można odrzucić ze znanych już powodów Odrzucone wymagania mogą być przydatne w innych systemach 24

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams Cele przedsięwzięcia Określanie wymagań Klienta, np. Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Wykonawcy Biznesowe Techniczne Priorytety! Kontekst przedsięwzięcia Użytkownicy

Bardziej szczegółowo

Cele przedsięwzięcia

Cele przedsięwzięcia Określanie wymagań Cele przedsięwzięcia Klienta, np. Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Wykonawcy Biznesowe Techniczne Priorytety! Kontekst przedsięwzięcia Użytkownicy

Bardziej szczegółowo

Faza Określania Wymagań

Faza Określania Wymagań Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie

Bardziej szczegółowo

Inżynieria oprogramowania wykład IV Faza określenia wymagań

Inżynieria oprogramowania wykład IV Faza określenia wymagań Inżynieria oprogramowania wykład IV Faza określenia wymagań prowadzący: dr inż. Krzysztof Bartecki Faza określenia wymagań Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza

Bardziej szczegółowo

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

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.

Bardziej szczegółowo

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

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań Wstęp Inżynieria wymagań Schemat procesu pozyskiwania wymagań identyfikacja źródeł wymagań Organizacja i Zarządzanie Projektem Informatycznym pozyskiwanie pozyskiwanie pozyskiwanie Jarosław Francik marzec

Bardziej szczegółowo

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl http://home.agh.edu.pl/~zabinska/

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl http://home.agh.edu.pl/~zabinska/ IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl http://home.agh.edu.pl/~zabinska/ Faza określania wymagań (1) Cel fazy określania wymagań dokładne ustalenie wymagań klienta

Bardziej szczegółowo

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

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie

Bardziej szczegółowo

Inżynieria Programowania Inżynieria wymagań

Inżynieria Programowania Inżynieria wymagań Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 11 marca 2017 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Projektowanie BAZY DANYCH

Projektowanie BAZY DANYCH Projektowanie BAZY DANYCH Podstawowe pojęcia Encją jest każdy przedmiot, zjawisko, stan lub pojęcie, czyli każdy obiekt, który potrafimy odróżnić od innych obiektów ( np. pies, rower,upał). Encje podobne

Bardziej szczegółowo

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

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura

Bardziej szczegółowo

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

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

Inżynieria oprogramowania II

Inżynieria oprogramowania II Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś

Bardziej szczegółowo

UPEDU: Rozpoznanie wymagań (ang. requirements discipline)

UPEDU: Rozpoznanie wymagań (ang. requirements discipline) Inżynieria oprogramowania II Marek Krętowski e-mail: mkret@wi.pb.edu.pl http://aragorn.pb.bialystok.pl/~mkret Wykład 5: UPEDU: Rozpoznanie wymagań (ang. requirements discipline) Na podstawie podręcznika:

Bardziej szczegółowo

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Regulamin usługi Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Projekt realizowany jest w ramach Działania 5.2 Wsparcie

Bardziej szczegółowo

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

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Faza strategiczna. Synteza. Analiza. Instalacja. Faza strategiczna. Dokumentacja. kodowanie implementacja. produkt konserwacja

Faza strategiczna. Synteza. Analiza. Instalacja. Faza strategiczna. Dokumentacja. kodowanie implementacja. produkt konserwacja Faza strategiczna określenie wymagań specyfikowanie projektowanie kodowanie implementacja testowanie produkt konserwacja Faza strategiczna Analiza Synteza Dokumentacja Instalacja Faza strategiczna (ang.

Bardziej szczegółowo

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

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło LATO 2007 Projektowanie Graficznych Interfejsów Użytkownika 1 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

Etapy życia oprogramowania

Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano

Bardziej szczegółowo

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

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:

Bardziej szczegółowo

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego

Bardziej szczegółowo

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu

Bardziej szczegółowo

Diagram przypadków użycia

Diagram przypadków użycia Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

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

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0> Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą

Bardziej szczegółowo

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),

Bardziej szczegółowo

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,

Bardziej szczegółowo

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

Bardziej szczegółowo

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

Inżynieria wymagań. Inżynieria wymagań 1/1 Inżynieria wymagań Inżynieria wymagań 1/1 Inżynieria wymagań 2/1 Wymagania stawiane oprogramowaniu Opisy usług i ograniczeń są wymaganiami stawianymi systemowi. Proces wynajdowania, analizowania, dokumentowania

Bardziej szczegółowo

Opis metodyki i procesu produkcji oprogramowania

Opis metodyki i procesu produkcji oprogramowania Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

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

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Projektowanie systemów informatycznych. Diagramy przypadków użycia

Projektowanie systemów informatycznych. Diagramy przypadków użycia Informacje ogólne i przykłady Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski jako narzędzie modelowania wymagań Nazwa use case diagrams. Cel stosowania Określenie wymagań

Bardziej szczegółowo

Jak powstaje model biznesowy? Co to jest? Modelowanie biznesowe. Model biznesowy. Jak powstaje model biznesowy? Jak firma generuje przychody?

Jak powstaje model biznesowy? Co to jest? Modelowanie biznesowe. Model biznesowy. Jak powstaje model biznesowy? Jak firma generuje przychody? Modelowanie biznesowe Wprowadzenie (część 1) Co to jest? Każdy model jest błędny. Niektóre modele są użyteczne. George E. P. Box Jak firma generuje przychody? Model biznesowy Sposób generowania przychodów

Bardziej szczegółowo

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

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

Kod doskonały : jak tworzyć oprogramowanie pozbawione błędów / Steve McConnell. Gliwice, cop Spis treści. Wstęp 15.

Kod doskonały : jak tworzyć oprogramowanie pozbawione błędów / Steve McConnell. Gliwice, cop Spis treści. Wstęp 15. Kod doskonały : jak tworzyć oprogramowanie pozbawione błędów / Steve McConnell. Gliwice, cop. 2017 Spis treści Wstęp 15 Podziękowania 23 Listy kontrolne 25 Tabele 27 Rysunki 29 Część I Proces budowy oprogramowania

Bardziej szczegółowo

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl Dobre wdrożenia IT cz. I Business Case Wprowadzenie Czy wiesz: jak często po wdrożeniu oprogramowania okazuje się, że nie spełnia ono wielu wymagań? jak często decyzja o wdrożeniu systemu informatycznego

Bardziej szczegółowo

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo

KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA

KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA Nazwa kierunku studiów: Informatyczne Techniki Zarządzania Ścieżka kształcenia: IT Project Manager, Administrator Bezpieczeństwa

Bardziej szczegółowo

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

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

FAZA STRATEGICZNA. Podstawowe hasło: Nie skupiać się na szczegółach! (na razie) Czynności w fazie strategicznej: Decyzje strategiczne:

FAZA STRATEGICZNA. Podstawowe hasło: Nie skupiać się na szczegółach! (na razie) Czynności w fazie strategicznej: Decyzje strategiczne: FAZA STRATEGICZNA Faza strategiczna jest wykonywana zanim podejmowana jest decyzja o realizacji przedsięwzięcia. Jej zadaniem jest określenie celów tworzonego systemu oraz wymagań odnośnie szczegółów jego

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management

Bardziej szczegółowo

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),

Bardziej szczegółowo

Zarządzanie inicjatywami i wymaganiami w projektach IT

Zarządzanie inicjatywami i wymaganiami w projektach IT Zarządzanie inicjatywami i wymaganiami w projektach IT Spotkanie 2 Zbigniew Misiak zbigniew.misiak@gmail.com Czym się będziemy zajmować? Co już było: 1. Zarządzanie wymaganiami 2. Przegląd oprogramowania

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)

Bardziej szczegółowo

Rozdział 5: Zarządzanie testowaniem. Pytanie 1

Rozdział 5: Zarządzanie testowaniem. Pytanie 1 Pytanie 1 Dlaczego niezależne testowanie jest ważne: A) Niezależne testowanie jest w zasadzie tańsze niż testowanie własnej pracy B) Niezależne testowanie jest bardziej efektywne w znajdywaniu defektów

Bardziej szczegółowo

Programowanie zespołowe

Programowanie zespołowe Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof

Bardziej szczegółowo

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

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia

Bardziej szczegółowo

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

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Zarządzanie projektami e-commerce, Meblini.pl, UE we Wrocławiu Wrocław, 11-03-2018 1. Cykl życia projektu 2. Pomysł / Planowanie 3. Analiza

Bardziej szczegółowo

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

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:

Bardziej szczegółowo

Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek

Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC Jarosław Świerczek Punkty funkcyjne Punkt funkcyjny to metryka złożoności oprogramowania wyznaczana w oparciu o określające to oprogramowanie

Bardziej szczegółowo

CRM VISION FUNKCJE SYSTEMU

CRM VISION FUNKCJE SYSTEMU www.crmvision.pl CRM VISION FUNKCJE SYSTEMU www.crmvision.pl CRM VISION FUNKCJE SYSTEMU CRM Vision to nowoczesne, bezpieczne oprogramowanie wspomagające zarządzanie firmą poprzez usprawnienie przepływu

Bardziej szczegółowo

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

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Egzamin / zaliczenie na ocenę*

Egzamin / zaliczenie na ocenę* WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli

Bardziej szczegółowo

Usługa: Audyt kodu źródłowego

Usługa: Audyt kodu źródłowego Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności

Bardziej szczegółowo

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Konfiguracja modelowania w procesie wytwarzania oprogramowania

Konfiguracja modelowania w procesie wytwarzania oprogramowania Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na

Bardziej szczegółowo

Analiza biznesowa a metody agile owe

Analiza biznesowa a metody agile owe Analiza biznesowa a metody agile owe P6S_WG01 ma wiedzę w zakresie metodyk zwinnych P6S_WG02 ma wiedzę w zakresie zwinnego gromadzenia i zarządzania wymaganiami P6S_WG03 zna i rozumie proces wytwarzania

Bardziej szczegółowo

Inżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Inżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Inżynieria wymagań Jarosław Kuchta Cele inżynierii wymagań Określenie celu biznesowego projektu Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji Identyfikacja wymagań

Bardziej szczegółowo

JAK TO DOBRZE ZROBIĆ 5-06-2013

JAK TO DOBRZE ZROBIĆ 5-06-2013 WDROŻENIA ROZWIĄZAŃ PROCESOWYCH: JAK TO DOBRZE ZROBIĆ 5-06-2013 Syndatis 2013 PLAN PREZENTACJI Trochę o Syndatis. Intensywność występujących zagrożeń w projekcie Wdrożenie rozwiązań procesowych - to nie

Bardziej szczegółowo

CRM. moduł zarządzania relacjami z klientami. Poradnik dla użytkowników systemu FIRMA 1/1

CRM. moduł zarządzania relacjami z klientami. Poradnik dla użytkowników systemu FIRMA 1/1 CRM moduł zarządzania relacjami z klientami Poradnik dla użytkowników systemu FIRMA 1/1 1. Wprowadzenie CRM Zarządzanie relacjami z klientami to nowy produkt firmy SOFT EKSPERT. Prosty, intuicyjny i czytelny

Bardziej szczegółowo

Diagramy przypadków użycia

Diagramy przypadków użycia Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy

Bardziej szczegółowo

SCENARIUSZ LEKCJI. Streszczenie. Czas realizacji. Podstawa programowa

SCENARIUSZ LEKCJI. Streszczenie. Czas realizacji. Podstawa programowa Autorzy scenariusza: SCENARIUSZ LEKCJI OPRACOWANY W RAMACH PROJEKTU: INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA. PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE Ważne pojęcia (I) Warunek testowy (test condition) to element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków

Bardziej szczegółowo

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

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Inżyniera wymagań Wymagania w projektowaniu systemów informatycznych Istnieją różne definicje wymagań dla

Bardziej szczegółowo

Szybkie prototypowanie w projektowaniu mechatronicznym

Szybkie prototypowanie w projektowaniu mechatronicznym Szybkie prototypowanie w projektowaniu mechatronicznym Systemy wbudowane (Embedded Systems) Systemy wbudowane (ang. Embedded Systems) są to dedykowane architektury komputerowe, które są integralną częścią

Bardziej szczegółowo

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

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language) Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu

Bardziej szczegółowo

www.omec.pl 1 Konferencja "Bezpieczny Projekt" Wrocław 22 czerwca 2010

www.omec.pl 1 Konferencja Bezpieczny Projekt Wrocław 22 czerwca 2010 Od kartki i ołówka do systemu informatycznego, czyli jak wdrażano zarządzanie projektami u klienta Rinf Sp. z o.o. www.omec.pl 1 Co my rozumiemy pod pojęciem: PROJEKT Projekt: Ciąg zadań nastawionych na

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 9 Narzędzie do wyliczania wskaźników statystycznych Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 31 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa

Bardziej szczegółowo

WPROWADZENIE DO UML-a

WPROWADZENIE DO UML-a WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

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

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 CSIOZ-WZP.65.48.20 Część I - Załącznik nr 7 do SIWZ Warszawa. 20r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA Wykonawca oświadcza, że do realizacji zamówienia

Bardziej szczegółowo

Projektowanie interakcji

Projektowanie interakcji Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director

Bardziej szczegółowo

osobowe pracowników laboratorium SecLab EMAG w rozumieniu przepisów Kodeksu Pracy, konsultantów, stażystów oraz inne osoby i instytucje mające dostęp

osobowe pracowników laboratorium SecLab EMAG w rozumieniu przepisów Kodeksu Pracy, konsultantów, stażystów oraz inne osoby i instytucje mające dostęp Bezpieczeństwo danych projektowych w środowisku według ISO/IEC 27001 oraz ciągłość procesów wytwarzania i utrzymania w środowisku według BS 25999 warsztaty z wykorzystaniem specjalistycznego narzędzia

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

Dlaczego testowanie jest ważne?

Dlaczego testowanie jest ważne? Testowanie Dlaczego testowanie jest ważne? Oprogramowanie które nie działa poprawnie może doprowadzić do: straty czasu, pieniędzy utraty reputacji uszkodzeń ciała a nawet śmierci Definicja błędu Oprogramowanie

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

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

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08 Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.

Bardziej szczegółowo

Jak zostać dobrym analitykiem? Wpisany przez RR Nie, 21 paź 2012

Jak zostać dobrym analitykiem? Wpisany przez RR Nie, 21 paź 2012 Analityk systemów informatycznych to zawód cieszący się w ostatnich latach rosnącą popularnością. Młodych ludzi zachęcają liczne oferty pracy, perspektywa wysokich zarobków i możliwość podnoszenia kwalifikacji.

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

ZARZĄDZANIE DOKUMENTACJĄ. Tomasz Jarmuszczak PCC Polska

ZARZĄDZANIE DOKUMENTACJĄ. Tomasz Jarmuszczak PCC Polska ZARZĄDZANIE DOKUMENTACJĄ Tomasz Jarmuszczak PCC Polska Problemy z zarządzaniem dokumentacją Jak znaleźć potrzebny dokument? Gdzie znaleźć wcześniejszą wersję? Która wersja jest właściwa? Czy projekt został

Bardziej szczegółowo

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa Budowa systemu wspomagającego podejmowanie decyzji Metodyka projektowo wdrożeniowa Agenda Systemy wspomagające decyzje Business Intelligence (BI) Rodzaje systemów BI Korzyści z wdrożeń BI Zagrożenia dla

Bardziej szczegółowo

Rady i porady użytkowe

Rady i porady użytkowe Rady i porady użytkowe Dział Eksploatacji CONTROLLING SYSTEMS sp. z o.o. Rady i porady - źródło prezentacji: Najczęstsze problemy zgłaszane przez Klientów na etapie eksploatacji systemu Spostrzeżenia konsultantów

Bardziej szczegółowo

KIERUNKOWE EFEKTY KSZTAŁCENIA

KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina

Bardziej szczegółowo

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków

Bardziej szczegółowo