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

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

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

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

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

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

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

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

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

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

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

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

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

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Wdrożenie systemu planowania zasobów przedsiębiorstwa pomimo wielu korzyści często też wiąże się

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

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

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

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

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

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

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

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

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

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ń. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

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

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

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

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą Załącznik nr 8 do SIWZ Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 3-CPI-WZP-44/13 Lp. Zakres wykonywanych czynności Liczba osób Imiona i nazwiska osób, którymi dysponuje wykonawca

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

Bardziej szczegółowo

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej

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

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Znajdowanie przypadków użycia

Bardziej szczegółowo

Opis wymagań i program szkoleń dla użytkowników i administratorów

Opis wymagań i program szkoleń dla użytkowników i administratorów Załącznik nr 3 do OPZ Opis wymagań i program szkoleń dla użytkowników i administratorów Spis treści Wprowadzenie...2 1. Typ i zakres szkoleń...2 2. Grupy użytkowników...2 3. Warunki ogólne szkoleń...3

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

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

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

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

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

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

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

KARTA MODUŁU KSZTAŁCENIA KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator

Bardziej szczegółowo

Cykle życia systemu informatycznego

Cykle życia systemu informatycznego Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów

Bardziej szczegółowo

BPM vs. Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów

BPM vs. Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów BPM vs. Content Management Jarosław Żeliński analityk biznesowy, projektant systemów Cel prezentacji Celem prezentacji jest zwrócenie uwagi na istotne różnice pomiędzy tym co nazywamy: zarzadzaniem dokumentami,

Bardziej szczegółowo

dr Stanisław Gasik s.gasik@vistula.edu.pl www.sybena.pl/uv/2014-wyklad-eko-zp-9-pl/wyklad4.pdf Podstawy konkurencyjności w projektach Koszt Wartość

dr Stanisław Gasik s.gasik@vistula.edu.pl www.sybena.pl/uv/2014-wyklad-eko-zp-9-pl/wyklad4.pdf Podstawy konkurencyjności w projektach Koszt Wartość Wykład Zarządzanie projektami Zajęcia 4 Zarządzanie jakością w projekcie dr Stanisław Gasik s.gasik@vistula.edu.pl www.sybena.pl/uv/2014-wyklad-eko-zp-9-pl/wyklad4.pdf Podstawy konkurencyjności w projektach

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

Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej.

Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej. Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej. Dział Zagadnienia Wymagania podstawowe Wymagania ponadpodstawowe Arkusz kalkulacyjny (Microsoft Excel i OpenOffice) Uruchomienie

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

Definicje. Algorytm to:

Definicje. Algorytm to: Algorytmy Definicje Algorytm to: skończony ciąg operacji na obiektach, ze ściśle ustalonym porządkiem wykonania, dający możliwość realizacji zadania określonej klasy pewien ciąg czynności, który prowadzi

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

Inżynieria Programowania Zarządzanie projektem

Inżynieria Programowania Zarządzanie projektem Inżynieria Programowania Zarządzanie projektem Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 12 października 2015 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4

Bardziej szczegółowo

Plan zarządzania projektem

Plan zarządzania projektem Plan zarządzania projektem Opracował: Zatwierdził: Podpis: Podpis: Spis treści: 1. Wst p... 2 1.1 Cel... 2 1.2 Zakres... 2 1.3 Przeznaczenie dokumentu... 2 1.4 Organizacja dokumentu... 2 1.5 Dokumenty

Bardziej szczegółowo

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

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki. Inżynieria Programowania Zarządzanie projektem Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 3 października 2013 Plan wykładu 1. Wstęp 2. Czynności zarządzania 3.

Bardziej szczegółowo

Tytuł: Identyfikacja procesu. Przedmiot: Zarządzanie procesami transportowo-logistycznymi Specjalność: Logistyka transportu Wersja: 2014.10.

Tytuł: Identyfikacja procesu. Przedmiot: Zarządzanie procesami transportowo-logistycznymi Specjalność: Logistyka transportu Wersja: 2014.10. Tytuł: Identyfikacja Autor: Piotr SAWICKI Zakład Systemów Transportowych WMRiT PP piotr.sawicki@put.poznan.pl www.put.poznan.pl/~piotr.sawicki www.facebook.com/piotr.sawicki.put Przedmiot: Zarządzanie

Bardziej szczegółowo

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements

Bardziej szczegółowo

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk Waterfall model (iteracyjny model kaskadowy) Marcin Wilk Iteracyjny model kaskadowy jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany w inżynierii oprogramowania. Jego nazwa wprowadzona

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

Od pomysłu do podpisania umowy. Izabela Adamska

Od pomysłu do podpisania umowy. Izabela Adamska Od pomysłu do podpisania umowy Izabela Adamska Restauracja Czy jest równowaga pomiędzy tym ile klient zapłaci, a tym co otrzyma w zamian? =? Sprawdźmy czy to jest proste? Wymagania telefonu komórkowego:

Bardziej szczegółowo

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

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2 Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy

Bardziej szczegółowo

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania dr inż. Marcin Szlenk Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Wprowadzenie O mnie dr inż. Marcin

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

Zagadnienia (1/3) Inżynieria Oprogramowania

Zagadnienia (1/3) Inżynieria Oprogramowania Zagadnienia (1/3) Pozyskiwanie i analiza Reprezentacje na poszczególnych etapach projektu Najczęściej pojawiające się problemy podczas pozyskiwania oraz metody ich rozwiązywania Reprezentacja z punktu

Bardziej szczegółowo

Co to jest usability?

Co to jest usability? Co to jest usability? Użyteczność produktów interaktywnych stron internetowych, programów komputerowych, telefonów komórkowych to odczuwana przez użytkowników prostota i wygoda, naturalność wykonywania

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0

ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0 ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0 Przeznaczenie Sylabusa Dokument ten zawiera szczegółowy Sylabus dla modułu ECDL/ICDL Użytkowanie baz danych. Sylabus opisuje zakres wiedzy

Bardziej szczegółowo

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

Bardziej szczegółowo

Projektowanie bazy danych przykład

Projektowanie bazy danych przykład Projektowanie bazy danych przykład Pierwszą fazą tworzenia projektu bazy danych jest postawienie definicji celu, założeń wstępnych i określenie podstawowych funkcji aplikacji. Każda baza danych jest projektowana

Bardziej szczegółowo

Modelowanie testów. czyli po co testerowi znajomość UML

Modelowanie testów. czyli po co testerowi znajomość UML Modelowanie testów czyli po co testerowi znajomość UML Paweł Dudzik październik 2015 Naturalny opis świata Powstaje pytanie, jak opisać ten świat, aby opis był jak najbardziej zbliżony do rzeczywistości,

Bardziej szczegółowo

CRM w logistyce. Justyna Jakubowska. CRM7 Specjalista Marketingu

CRM w logistyce. Justyna Jakubowska. CRM7 Specjalista Marketingu CRM w logistyce Justyna Jakubowska CRM7 Specjalista Marketingu CRM w logistyce Prezentacja firm more7 Polska dostawca systemu CRM Autor i producent systemu do zarządzania relacjami z klientem CRM7; Integrator

Bardziej szczegółowo

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między

Bardziej szczegółowo

Projektowanie systemów informatycznych

Projektowanie systemów informatycznych Projektowanie systemów informatycznych Zarządzanie projektem Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski Główne procesy w realizacji projektu informatycznego (ang. feasibility

Bardziej szczegółowo

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

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20 Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:

Bardziej szczegółowo

Spis treści. Analiza Ryzyka Instrukcja Użytkowania

Spis treści. Analiza Ryzyka Instrukcja Użytkowania Maj 2013 Spis treści 1. Wprowadzenie... 3 2. Podstawy prawne... 4 3. Zasada działania programu... 6 4. Zgodność z analizą zagrożeń... 7 5. Opis programu... 8 5.1. Menu Górne... 9 5.2. Status... 10 5.3.

Bardziej szczegółowo

RELACYJNE BAZY DANYCH

RELACYJNE BAZY DANYCH RELACYJNE BAZY DANYCH Aleksander Łuczyk Bielsko-Biała, 15 kwiecień 2015 r. Ludzie używają baz danych każdego dnia. Książka telefoniczna, zbiór wizytówek przypiętych nad biurkiem, encyklopedia czy chociażby

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

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

Projekt systemu informatycznego

Projekt systemu informatycznego Projekt systemu informatycznego Kod przedmiotu: PSIo Rodzaj przedmiotu: specjalnościowy ; obieralny Wydział: Informatyki Kierunek: Informatyka Specjalność (specjalizacja): Inżynieria Systemów Informatycznych

Bardziej szczegółowo

Karta Prezentacji Projektu

Karta Prezentacji Projektu Karta Prezentacji Projektu Karta Prezentacji Projektu powinna być uzupełniona z perspektywy osoby będącej uczestnikiem projektu bądź liderem projektu. Nazwa projektu: Usprawnienie procesu udzielenia kredytu

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM SZKOŁA GŁÓWNA HANDLOWA w Warszawie STUDIUM MAGISTERSKIE Kierunek: Metody ilościowe w ekonomii i systemy informacyjne Karol Walędzik Nr albumu: 26353 Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem

Bardziej szczegółowo

SHAREPOINT SHAREPOINT QM SHAREPOINT DESINGER SHAREPOINT SERWER. Opr. Barbara Gałkowska

SHAREPOINT SHAREPOINT QM SHAREPOINT DESINGER SHAREPOINT SERWER. Opr. Barbara Gałkowska SHAREPOINT SHAREPOINT QM SHAREPOINT DESINGER SHAREPOINT SERWER Opr. Barbara Gałkowska Microsoft SharePoint Microsoft SharePoint znany jest również pod nazwą Microsoft SharePoint Products and Technologies

Bardziej szczegółowo