Analiza/Inżynieria wymagań
|
|
- Patrycja Małecka
- 8 lat temu
- Przeglądów:
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
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ółowoCele 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ółowoFaza 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ółowoInż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ółowoAnaliza 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ółowoREQB 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ółowoModelowanie 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ółowoWstę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ółowoIO - 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ółowoInż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ółowoInż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ółowoProjekt 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ółowoProjektowanie 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ółowoBłę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ółowoCo 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ółowoInż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ółowoUPEDU: 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ółowoWdroż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ółowoInż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ółowoZasady 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ółowoPLAN 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ółowoAnalityk 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ółowoFaza 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ółowoProjektowanie 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ółowoTom 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ółowoEtapy ż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ółowoWprowadzenie 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ółowoModelowanie 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ółowoMiASI. 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ółowoJarosł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ółowoDiagram 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ółowoInż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ółowoProcesowa 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>
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ółowoInstrukcja 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ółowoKATEDRA 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ółowoZarzą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ółowoInż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ółowoOpis 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ółowoPRZEWODNIK 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ółowoSpis 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ółowoPRZEWODNIK 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ółowoProjektowanie 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ółowoJak 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ółowoProjekt: 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ółowoKod 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ółowoDobre 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ółowoHP 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ółowoKIERUNKOWE 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ółowoEtapy ż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ółowoInformatyzacja 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ółowoFAZA 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ółowoInż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ółowoMonitoring 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ółowoInstrukcja 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ółowoZarzą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ółowoJę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ółowoRozdział 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ółowoProgramowanie 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ółowo1. 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ółowoNarzę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ółowoNazwa 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ółowoPraktyczne 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ółowoCRM 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ółowoKomputerowe 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ółowoEgzamin / 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ółowoUsł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ółowoInż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ółowoKarta 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ółowoKonfiguracja 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ółowoAnaliza 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ółowoInż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ółowoJAK 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ółowoCRM. 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ółowoDiagramy 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ółowoSCENARIUSZ 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ółowoINŻ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ółowoProjektowanie 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ółowoSzybkie 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ółowoZagadnienia (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ółowowww.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ółowoTom 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ółowoWPROWADZENIE 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ółowoTester 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ółowoCzęść 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ółowoProjektowanie 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ółowoosobowe 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ółowoREFERAT 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ółowoDlaczego 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ółowoMetodyka 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ółowoSpis 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ółowoJak 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ółowoTom 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ółowoZARZĄ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ółowoBudowa 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ółowoRady 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ółowoKIERUNKOWE 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ółowoInż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