020 ANALIZA WYMAGAŃ. Prof. dr hab. Marek Wisła
|
|
- Amalia Żurek
- 6 lat temu
- Przeglądów:
Transkrypt
1 020 ANALIZA WYMAGAŃ Prof. dr hab. Marek Wisła
2 Wymagania Wymaganie (ang. requirement) - pojęcie wymagania jest różnie interpretowane przez różne organizacje zajmujące się produkcją oprogramowania. Może oznaczać zarówno bardzo zgrubny, abstrakcyjny opis funkcji jakie powinien realizować system informatyczny lub ograniczeń jakim może podlegać, jak również może być matematyczną formułą, bardzo precyzyjnie określającą jego funkcjonalność Wymagania w wielu przypadkach mogą spełniać różne, wydawałoby się przeciwstawne, funkcje: mogą stanowić podstawę dla ofert na realizację systemu - powinny być otwarte, tak aby nie narzucać formy realizacji systemu mogą (a właściwie powinny) stanowić podstawę kontraktu na realizację systemu - powinny zatem być: dokładne, kompletne, spójne, realizowalne i weryfikowalne
3 Inżynieria wymagań Inżynieria wymagań - proces identyfikacji wymagań jakich spełnienia oczekują użytkownicy systemu oraz ograniczeń nakładanych na jego realizację i użytkowanie.
4 Proces (uproszczony) inżynierii wymagań
5 Analiza realizowalności Analiza realizowalności zebranie zasadniczych (podstawowych) wymagań klienta i określenie czy te wymagania mogą zostać spełnione w założonym budżecie i przy wykorzystaniu wymaganych lub dostępnych rozwiązań technologicznych. Zwykle za ten etap klient nie jest obciążany kosztami. Jednak w przypadku dużych, złożonych projektów analiza realizowalności może być płatna.
6 Analiza wymagań Analiza wymagań analiza aktualnego środowiska pracy użytkowników systemu, określenie celów systemu i jego ograniczeń. Analiza wymagań jest zwykle wykonywana w środowisku klienta na podstawie bezpośrednich rozmów z decydentami i użytkownikami systemu. Analiza wymagań powinna być przeprowadzana kilkukrotnie w celu usunięcia zauważonych nieścisłości i ostatecznego uzgodnienia listy wymagań. Na podstawie przeprowadzonej analizy powstaje dokument definicja wymagań, który w formie przejrzystej i zrozumiałej przez przyszłych użytkowników systemu przedstawia zebrane wymagania i ograniczenia. Ten dokument powinien zostać zaakceptowany przez klienta.
7 Specyfikacja wymagań systemowych Specyfikacja Wymagań Systemowych (SWS, ang, System Requirements Specification - SRS) to dokument, w którym są uszczegółowiane wymagania dotyczące przyszłego systemu. Specyfikacja wymagań powinna stanowić podstawę kontraktu (wycena, termin realizacji) pomiędzy klientem i wykonawcą, jak również stanowi punkt startowy dla dokumentów określających architekturę systemu oraz jego implementację. Więcej o dokumentach SWS w dalszej części wykładu.
8 Przykład definicji i specyfikacji Definicja wymagania Oprogramowanie powinno w łatwy, intuicyjny sposób umożliwiać dostęp do zewnętrznych plików tworzonych przez inne programy. Specyfikacja wymagań 1.1 Użytkownik ma mieć możliwość definiowania typów plików zewnętrznych 1.2 Każdy zdefiniowany przez użytkownika typ pliku zewnętrznego musi mieć związane z nim oprogramowanie, które może zostać użyte do edycji plików tego typu. 1.3 Każdy plik zewnętrzny będzie reprezentowany w systemie przez ikonę. 1.4 Użytkownik ma mieć możliwość tworzenia i przypisywania ikon do typów plików zewnętrznych. 1.5 W wyniku kliknięcia myszą na ikonie reprezentującej plik zewnętrzny oprogramowanie związane z typem tego pliku ma zostać użyte do prezentacji zawartości tego pliku.
9 POZYSKIWANIE WYMAGAŃ
10 Pozyskiwanie wymagań Celem fazy pozyskiwania wymagań jest zebranie wymagań klienta wobec tworzonego systemu. Zbieranie wymagań to proces w którym klient łącznie z przedstawicielami producenta systemu konstruuje zbiór wymagań wobec systemu zgodnie z postawionymi celami i przyjętym zakresem. Zebrane wymagania dokumentowane są w Specyfikacji Wymagań Systemowych SWS (ang. SRS System Requirements Specification).
11 Inżynieria wymagań Inżynieria wymagań (ang. Requirements engineering) to całość działań związanych z pozyskiwaniem, reprezentowaniem, analizą i zarządzaniem wymaganiami. Etap zbierania wymagań jest traktowany jako jeden z najtrudniejszych w całym procesie produkcji oprogramowania. Osiągnięcie całkowicie poprawnej i pełnej specyfikacji wymagań jest niezwykle trudne ze względu na ciągłą ewolucję każdego systemu informatycznego.
12 Trzy metody pozyskiwania wymagań 1. Wywiady 2. Studia istniejących systemów 3. Prototypowanie
13 1. Wywiady Mają być przygotowane w postaci listy pytań i podzielone na odrębne zagadnienia. Mają umożliwić użytkownikowi zrozumienie konsekwencji wyborów i ich wpływ na ostateczną postać systemu Mają doprowadzić do szerokiej zgody i akceptacji projektu.
14 2. Studia istniejących systemów Są rozpatrywane w sytuacji gdy nowe oprogramowanie zastępuje stare. Mają ustalić wszystkie dobre i złe strony starego oprogramowania. Mają ustalić wymagania wobec nowego systemu, które zwykle związane są z usunięciem złych stron starego systemu, zachowaniem dobrych strony starego systemu, dodaniem nowych możliwości nieobecnych w starym systemie.
15 3. Prototypowanie Zbudowanie prototypu systemu działającego w mniejszej skali z uproszczonymi interfejsami. Na podstawie prototypu zebranie listy wymagań zwykle dotyczących: rozwinięcia funkcjonalności, poprawienia efektywności (np. szybszej pracy systemu), zmian w interfejsie (np. poprawy ergonomii). Budowa prototypu jest najbardziej kosztownym sposobem zbierania/uściślania wymagań.
16 Rodzaje wymagań Trzy podstawowe rodzaje wymagań: Wymagania funkcjonalne opisują one funkcje (czynności, operacje), które mają być wykonywane przez system, dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem. Wymagania niefunkcjonalne opisują ograniczenia (sprzętowe, prawne), przy zachowaniu których system ma realizować swoje funkcje. Wymagania przejściowe opisują ograniczenia o określonym czasie występowania, np. związane z migracją ze starego systemu do nowego.
17 Ważność fazy pozyskiwania wymagań Zbieranie wymagań jest fazą w której niezbędna jest najbardziej staranna weryfikacja i walidacja. Rozwijanie aplikacji w oparciu o niepoprawne wymagania może w skrajnym przypadku doprowadzić do wytworzenia nieodpowiedniego lub niepotrzebnego oprogramowania! Koszt naprawy błędów w specyfikacji wymagań rośnie zgodnie z zasadą 1:10, tzn. naprawa błędu specyfikacji wymagań kosztuje: 10 razy więcej na etapie projektowania, 100 razy więcej na etapie kodowania, 1000 razy więcej na etapie użytkowania i konserwacji niż na etapie specyfikacji.
18 Kto? Ustalenie interesariuszy projektu Zarządzający (cele biznesowe) Kontroler finansowy (koszty) Kierownik IT (szczególne wymagania funkcjonalne, niezawodność, dostępność, testowalność) Użytkownicy końcowi (wymagania funkcjonalne) Kierownik marketingu (cechy marketingowe) Kierownik ochrony (bezpieczeństwo) Dobrą praktyką jest ograniczanie liczby interesariuszy biorących udział w bezpośrednim opracowywaniu listy (definicji) wymagań (np. do kierowników działów, brygadzistów itp.). Jednak nie zwalnia to z obowiązku przeprowadzenia wywiadu na bezpośrednich stanowiskach pracy użytkowników.
19 Kto? Ustalenie interesariuszy Każda osoba zainteresowana może występować w kilku rolach (np. administrator może też być użytkownikiem końcowym). Z każdą rolą jest związany określony punkt widzenia. Każde urządzenie lub system współpracujący z projektowanym systemem również może mieć swoje wymagania i w tym sensie również jest udziałowcem projektu. Punkty widzenia różnych interesariuszy są różne. Wszystkie punkty widzenia interesariuszy są ważne, chociaż nie wszystkie w tym samym stopniu. Wszystkie punkty widzenia powinny zostać wzięte pod uwagę. Wszystkie punkty widzenia powinny zostać przeanalizowane. Pojawiające się konflikty powinny zostać rozstrzygnięte.
20 Kto? Ustalenie klienta Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy kontrakt. Klient powinien należeć do interesariuszy projektu. W przeciwnym przypadku nie jest on zainteresowany wprowadzeniem systemu, a wtedy szanse zrealizowania projektu są minimalne. W organizacji klienta musi być wyznaczona osoba (kierownik projektu) odpowiedzialna za realizację projektu i reprezentująca klienta. Osoba ta musi mieć odpowiednią władzę nad innymi interesariuszami, aby zapewnić ich współpracę w fazie formułowania wymagań. W przypadku klienta szerokiego (produktu przeznaczonego dla masowego odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących interesariuszy (najczęściej użytkowników końcowych) i od nich pozyskiwać wymagania.
21 Zrozumienie
22 Każdy słyszy to, co chce usłyszeć
23 Co? Cztery etapy pozyskiwania wymagań 1. Uświadomienie sobie przez interesariuszy ich potrzeb. 2. Sformułowanie potrzeb. 3. Transformowanie potrzeb na wymagania względem systemu. 4. Zdobycie uzupełniających informacji potrzebnych do zrozumienia wymagań.
24 1. Uświadamianie potrzeb Interesariusz może nie czuć potrzeby wprowadzenia systemu, a jedynie kierować się odgórnymi nakazami czy trendami (fatalna sytuacja!). Interesariusz może być na tyle przyzwyczajony do dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian, które nastąpią po wprowadzeniu nowego systemu. Interesariusz prawie na pewno nie uświadamia sobie wszystkich swoich potrzeb. W przypadku, gdy Interesariusz jest urządzeniem lub systemem, jego wymagania może reprezentować osoba eksperta lub mogą być one zapisane w dokumentacji, do której trzeba dotrzeć.
25 2. Formułowanie potrzeb Interesariusz może mieć kłopoty z formułowaniem jasnych wypowiedzi. Interesariusz może być niechętny do formułowania pewnych potrzeb, gdyż może uznać je za słabość swoją lub swojej organizacji i wstydzić się tej słabości. Interesariusz może uznać pewne swoje potrzeby za oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny może ich nie znać (fatalnie!).
26 3. Zamiana potrzeb na wymagania Nie każdą potrzebę jest w stanie zaspokoić system informatyczny. Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji. Wymagania mogą być funkcjonalne, niefunkcjonalne i przejściowe. Istnieje konieczność klasyfikacji wymagań. Wymagania powinny określać, co system ma robić, a nie w jaki sposób ma to robić. Różne potrzeby mogą prowadzić do sprzecznych wymagań. Istnieje konieczność określenia priorytetów ważności wymagań.
27 4. Uzyskanie informacji potrzebnych do zrozumienia wymagań Informacje mogą być przechowywane w głowach pewnych osób, które mogą nie być zainteresowane w dzieleniu się nimi (bierny opór). Informacje mogą być zapisane w trudno dostępnej dokumentacji. Informacje mogą być niekompletne. Informacje mogą być sprzeczne. Informacje mogą być mylące.
28 Trudność fazy pozyskiwania wymagań (1) Klient z reguły nie wie dokładnie w jaki sposób osiągnąć założone cele. Cele klienta mogą być osiągnięte 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ą terminologią mówiąc o tych samych problemach.
29 Trudność fazy pozyskiwania wymagań (2) Zleceniodawcy, sponsorzy i użytkownicy to często inne osoby. Głos zleceniodawców może być w tej fazie decydujący, chociaż nie zawsze potrafią oni właściwie przewidzieć potrzeby przyszłych użytkowników. W większości organizacji związanych z produkcją i eksploatacją oprogramowania jakość procesów inżynierii wymagań jest bardzo niska. Znaczenie tej fazy jest umniejszane, bardzo szybko przechodzi się do faz związanych bezpośrednio z produkcją (projektowanie, implementacja)
30 Zagrożenia w procesie pozyskiwania wymagań Wymagania muszą być zbierane w procesie iteracyjnym aż do uzyskania pewności, że pozyskana lista wymagań jest kompletna i poprawnie sformułowana. W wielu sytuacjach proces ten jest przerywany (np. z powodu kosztów, upływających terminów) w wyniku czego specyfikacja wymagań nie jest wystarczająco precyzyjna.
31 Zagrożenia w procesie pozyskiwania wymagań Przyczyny uzyskania specyfikacji wymagań nie w pełni kompletnej: Brak przeznaczenia wystarczających zasobów na realizację tego procesu. Pozyskane wymagania wydają się pozornie prawdziwe, lecz nie przeprowadzono dostatecznej ich analizy oraz ich kompletności i poprawności. Wykonano jedynie jedną iterację, a zespół zbierający wymagania nie jest wystarczający świadomy tego, że ponowny kontakt z klientem może wnieść nowe informacje co do ostatecznej postaci systemu.
Inżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Inżynieria wymagań Jarosław Kuchta Cele inżynierii wymagań Określenie celu biznesowego projektu Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji Identyfikacja wymagań
Bardziej szczegółowoZagadnienia (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ółowoOd 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ół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ół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ół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ółowoMODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś
OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś (często stosowany w praktyce do projektów o niewielkiej złożoności) wymagania specyfikowanie kodowanie
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ółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
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ół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ółowoCykle ż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ółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
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ół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ółowoPryncypia architektury korporacyjnej
Pryncypia architektury korporacyjnej Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH E-mail: sobczak@sgh.waw.pl Plan prezentacji Czym
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ół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ółowoGry społecznościowe. wykład 0. Joanna Kołodziejczyk. 24 lutego Joanna Kołodziejczyk Gry społecznościowe 24 lutego / 11
Gry społecznościowe wykład 0 Joanna Kołodziejczyk 24 lutego 2017 Joanna Kołodziejczyk Gry społecznościowe 24 lutego 2017 1 / 11 Program przedmiotu Dwie formy zajęć: 1 Wykład studia stacjonarne (15h) 2
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ółowoOrganizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią
Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje
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ół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ół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ółowoModelowanie 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ół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ół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ół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ół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ół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ółowoWprowadzenie do systemów informacyjnych
Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj
Bardziej szczegółowoProjekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka
Warszawa dnia 25 lutego 2013 r. Szanowni Państwo,, z siedzibą w Warszawie przy ul. Wolność 3A, zwraca się z prośbą o przedstawienie oferty cenowej na usługę analizy przedwdrożeniowej i wdrożenia dla aplikacji
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ółowoTestujemy dedykowanymi zasobami (ang. agile testers)
Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania
Bardziej szczegółowoKARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Inżynieria oprogramowania, C12
KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia: Profil kształcenia: Forma studiów:
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
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ół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ółowoKARTA 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ół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ółowoWykład 8. Testowanie w JEE 5.0 (1) Autor: Zofia Kruczkiewicz. Zofia Kruczkiewicz
Wykład 8 Testowanie w JEE 5.0 (1) Autor: 1. Rola testowania w tworzeniu oprogramowania Kluczową rolę w powstawaniu oprogramowania stanowi proces usuwania błędów w kolejnych fazach rozwoju oprogramowania
Bardziej szczegółowoPrzedsięwzięcia Informatyczne w Zarządzaniu
Przedsięwzięcia Informatyczne w Zarządzaniu 2005/06 dr inż. Grażyna Hołodnik-Janczura GHJ 1 LITERATURA 1. Praca zbiorowa p.r. Górski J., Inżynieria oprogramowania, MIKOM, W-wa, 2000 2. Jaszkiewicz A.,
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ół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ółowoMaciej 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ółowoSzczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna
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ół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ół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 (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ółowoZarządzanie projektami. Wykład 2 Zarządzanie projektem
Zarządzanie projektami Wykład 2 Zarządzanie projektem Plan wykładu Definicja zarzadzania projektami Typy podejść do zarządzania projektami Cykl życia projektu/cykl zarządzania projektem Grupy procesów
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ółowoTestowanie wymagań KAROLINA ZMITROWICZ, RADOSŁAW SMILGIN
Testowanie wymagań KAROLINA ZMITROWICZ, RADOSŁAW SMILGIN Poznajmy Prowadzących Uczestników I oczekiwania. Agenda Wymagania Różne poziomy wymagań Kryteria jakości dla wymagań Specyfikacje http://edu.ittraining.pl/szkolenie/tworzenie_i_ocena_specyfikacji_wymaga
Bardziej szczegółowoWOJSKOWA AKADEMIA TECHNICZNA
WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko
Bardziej szczegółowoZakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
Bardziej szczegółowoKomputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:
Rozdział pochodzi z książki: Zarządzanie projektami badawczo-rozwojowymi. Tytuł rozdziału 6: Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście adaptacyjne
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ółowoGoBiz System platforma współpracy marektingowej
GoBiz System platforma współpracy marektingowej Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel platformy... 2 3. Główni odbiorcy systemu... 2 4. Przedmiot zamówienia...
Bardziej szczegółowoZARZĄDZANIE I INŻYNIERIA PRODUKCJI
ZARZĄDZANIE I INŻYNIERIA PRODUKCJI STUDIA PIERWSZEGO STOPNIA PROFIL OGÓLNOAKADEMICKI Załącznik nr 2 Odniesienie efektów kierunkowych do efektów obszarowych i odwrotnie Załącznik nr 2a - Tabela odniesienia
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ółowoWprowadzenie w tematykę zarządzania przedsięwzięciami/projektami. dr inż. Agata Klaus-Rosińska
Wprowadzenie w tematykę zarządzania przedsięwzięciami/projektami dr inż. Agata Klaus-Rosińska 1 DEFINICJA PROJEKTU Zbiór działań podejmowanych dla zrealizowania określonego celu i uzyskania konkretnego,
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ół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ółowoSystem epon Dokumentacja użytkownika
System epon Dokumentacja użytkownika Prawa autorskie tego opracowania należą do MakoLab S.A. Dokument ten, jako całość, ani żadna jego część, nie może być reprodukowana lub rozpowszechniana w jakiejkolwiek
Bardziej szczegółowoAutomatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.
Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.pl Obsługa wniosków kredytowych Potrzeba elastyczności
Bardziej szczegółowoInżynieria Oprogramowania w Praktyce
Inżynieria Oprogramowania w Praktyce Ogólna prezentacja kierunku Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego. www.aict.pjwstk.edu.pl 1 Kogo chcemy
Bardziej szczegółowoEfekty kształcenia. Tabela efektów kształcenia
Efekty kształcenia Tabela efektów kształcenia W opisie efektów kierunkowych uwzględniono wszystkie efekty kształcenia występujące w obszarze kształcenia w zakresie nauk technicznych. Objaśnienie oznaczeń:
Bardziej szczegółowoMiary funkcjonalne i co można z nimi zrobić fakty i mity. Warszawa, 7-8 czerwca 2017
Miary funkcjonalne i co można z nimi zrobić fakty i mity Warszawa, 7-8 czerwca 2017 300 D&C w swojej działalności od lat promuje miary funkcjonalne wymiarujemy i szacujemy szkolimy: metody wymiarowania,
Bardziej szczegółowoJak kupować usługi full service? Dialog Branżowy Reklamodawca-Agencja
Przed przejściem do punktów Agendy zdefiniowano usługi FULL SERVICE w reklamie. Przyjęto następującą definicję na potrzeby pracy: FULL SERVICE dotyczy zakresu prac Reklamodawcy oraz takich kompetencji
Bardziej szczegółowoSCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny
SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów
Bardziej szczegółowoZarządzanie projektami IT
Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie
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ółowoRUP. Rational Unified Process
RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną
Bardziej szczegółowoWykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
Bardziej szczegółowoJakość w procesie wytwarzania oprogramowania
Jarosław Kuchta Jakość Oprogramowania http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc/ J.Kuchta@eti.pg.gda.pl Względny koszt wprowadzania zmian w zależności od fazy realizacji projektu
Bardziej szczegółowoWarsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni
Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Warsztaty FRAME I. Cel Zapoznanie uczestników z możliwościami wykorzystania Europejskiej Ramowej Architektury ITS FRAME (zwanej dalej FRAME ) oraz jej narzędzi
Bardziej szczegółowoProjekty 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ół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ółowoIn ż 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ółowoTabela odniesień efektów kierunkowych do efektów obszarowych (tabele odniesień efektów kształcenia)
Załącznik nr 7 do uchwały nr 514 Senatu Uniwersytetu Zielonogórskiego z dnia 25 kwietnia 2012 r. w sprawie określenia efektów kształcenia dla kierunków studiów pierwszego i drugiego stopnia prowadzonych
Bardziej szczegółowoNie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.
Nie o narzędziach a o rezultatach czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT Władysławowo, 6 października 2011 r. Dlaczego taki temat? Ci którzy wykorzystują technologie informacyjne
Bardziej szczegółowoProcesy 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ółowoFaza analizy (modelowania) Faza projektowania
Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań
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ół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ółowo"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".
"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny". CZYNNIKI PROJEKTU Cel (zakres) projektu: wyznacza ramy przedsięwzięcia, a tym samym zadania
Bardziej szczegółowoZarządzanie usługami IT
Zarządzanie usługami IT Koncepcja usługowej organizacji IT oraz cykl życia usługi IT dr Remigiusz Orzechowski Instytut Zarządzania Wartością Kolegium Nauk o Przedsiębiorstwie Szkoła Główna Handlowa w Warszawie
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ółowoKARTA PRZEDMIOTU. Systemy czasu rzeczywistego: D1_9
KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom : Profil : Forma studiów: Obszar : Dziedzina:
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny
Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie
Bardziej szczegółowoEfekt kształcenia. Wiedza
Efekty dla studiów drugiego stopnia profil ogólnoakademicki na kierunku Informatyka na specjalności Przetwarzanie i analiza danych, na Wydziale Matematyki i Nauk Informacyjnych, gdzie: * Odniesienie oznacza
Bardziej szczegółowoZarządzanie projektami. Wykład 2 dr inż. Agata Klaus-Rosińska
Zarządzanie projektami Wykład 2 dr inż. Agata Klaus-Rosińska 1 Etapy/fazy zarządzania projektem Rozpoczęcie (uruchomienie) projektu Planowanie projektu Realizacja projektu Zamknięcie projektu Rozpoczęcie
Bardziej szczegółowoProwadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska. Miedzeszyn, wrzesień 2010
Jak nie stracić efektów synergii usługi systemów krajowych i globalnych Prowadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska Miedzeszyn, wrzesień 2010 Bartosz Górczyński Prezes Zarządu CTPartners
Bardziej szczegółowoZagadnienia. Inżynieria Oprogramowania
Zagadnienia Co to jest extreme Programming (XP) Czym charakteryzują się tzw. lekkie metodyki zarządzania procesem produkcji oprogramowania Reguły i praktyki XP Dlaczego i kiedy można a w jakich przypadkach
Bardziej szczegółowoZASADY TWORZENIA OPROGRAMOWANIA
ZASADY TWORZENIA OPROGRAMOWANIA 1. Tylko złożone oprogramowanie wymaga inżynierii (cykl życia składający się z modelowania i testowania oraz sprzężenia zwrotnego prosty problem, zajęcia z programowania)
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ółowoInżynieria oprogramowania (Software Engineering) Wykład 1
Inżynieria oprogramowania (Software Engineering) Wykład 1 Wprowadzenie do inżynierii oprogramowania Zarządzanie przedmiotem Wydział: WEiI Katedra: KIK Web site: http://moskit.weii.tu.koszalin.pl/~swalover/
Bardziej szczegółowoFeature 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