Tworzenie oprogramowania nie jest sprawą

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

Download "Tworzenie oprogramowania nie jest sprawą"

Transkrypt

1 Inżynieria oprogramowania Rafał Kasprzyk Przegląd modeli cyklu życia oprogramowania Tworzenie oprogramowania nie jest sprawą prostą i nikogo, kto brał udział w dużym projekcie, nie trzeba o tym przekonywać. Czasy, kiedy jedna osoba zajmowała się zbieraniem wymagań, analizą, projektowaniem, programowaniem, testowaniem i wdrażaniem produktu informatycznego dawno już się skończyły. Programowanie odkrywcze nie jest obecnie dobrym sposobem budowy jakichkolwiek systemów informatycznych. Tworzone dziś systemy są po prostu zbyt skomplikowane, aby przez cały cykl życia tych systemów mogła nad nimi panować jedna osoba. Trudności w budowaniu dużych systemów wymusiły, już wiele lat temu, konieczność usystematyzowania procesu wytwarzania systemów informatycznych. Stworzono więc modele porządkujące podejmowane działania i stany w jakich znajduje się produkt informatyczny. Obecnie zbiór modeli cykli życia oprogramowania jest niezwykle bogaty. Oczywiście wystarczy poznać tylko kilka kluczowych modeli, pozostałe są najczęściej hybrydami tych podstawowych. Pojęcie modelu cyklu życia systemu informatycznego Czym właściwie jest model cyklu życia systemu informatycznego (oprogramowania)? To szereg wzajemnie zależnych od siebie etapów, w których podejmowane są działania, począwszy od ujawnienia potrzeby budowy systemu informatycznego, prezentacji jego idei, konstrukcję, użytkowanie, przystosowane do ewentualnych zmian funkcjonowania (wynikających najczęściej ze względu na zmieniające się warunki otoczenia), a kończąc na wycofaniu z eksploatacji. Będziemy zajmować się tylko tą częścią cyklu życia oprogramowania, która związana jest z procesem wytwórczym i w związku z tym nazywana jest cyklem wytwarzania oprogramowania. Każdy model cyklu życia oprogramowania ma na celu przedstawienie procesu wytwarzania oprogramowania, który prowadzi do stworzenia działającego systemu spełniającego oczekiwania klienta. Autor jest absolwentem Wydziale Cybernetyki Wojskowej Akademii Technicznej, gdzie od roku zajmuje stanowisko asystenta w Instytucie Systemów Informatycznych. Pracuje w firmie ISOLUTION będąc odpowiedzialnym za przygotowywanie, prowadzenie i audyt szkoleń obejmujących analizę i projektowanie systemów informatycznych z użyciem notacji UML. Kontakt z autorem: Rysunek 1. Programowanie odkrywcze Popularne modele cyklu życia systemu informatycznego Najczęściej wymienianym procesem wytwarzania oprogramowania jest model kaskadowy (zwany również modelem wodospadu, ang. waterfall) i model iteracyjny. Terminy te często są nie do końca poprawnie rozumiane. Bardzo często można się spotkać z przekonaniem, że proces kaskadowy jest procesem przestarzałym, a jedynie słusznym podejściem jest proces iteracyjny. Osobiście ostrożnie podchodzę do takiej oceny tych dwóch najpopularniejszych modeli wytwarzania oprogramowania. Uważam, że wybór procesu w znacznym stopniu zależy od charakteru projektu, a tym samym nie ma jednego słusznego modelu cyklu życia oprogramowania. Co więcej, najczęściej okazuje się, że w praktyce najlepiej radzą sobie modele, które są modyfikacjami lub hybrydami procesów podstawowych. Przyczyna ich powstania związana jest bądź to z wadami bądź trudnościami w adaptacji do rzeczywistych warunków wytwarzania systemów informatycznych modelu kaskadowego. Zauważmy, że sam proces iteracyjny stanowi swego rodzaju modyfikację procesu kaskadowego. Inne znane i popularne modele cyklu życia oprogramowania to model spiralny, model V, prototypowanie, i wiele innych. Model kaskadowy Najstarszym i prawdopodobnie najlepiej znanym cyklem życia oprogramowania jest model wodospadu. Najpowszechniej spotykanym argumentem zachęcającym do użycia tego modelu jest fakt, iż jest on dla człowieka najbardziej naturalnym sposobem rozwiązywania wszelkich problemów. W modelu kaskadowym, aby zbudować system informatyczny należy przejść przez kolejne etapy, których realizacja ma zapewnić zakończenie projektu. Etapy na jakie dzielony jest proces wytwarzania to: zbieranie wymagań, analiza, projektowanie, implementacja, testowanie i wdrożenie systemu. W modelu wodospadu wyjście z jednego etapu jest równocześnie wejściem w kolejny, bez możliwo- 52 Software Developer s Journal 10/2006

2 Przegląd modeli cyklu życia oprogramowania Rysunek 2. Model kaskadowy ści powrotu. Zostaje zatem utworzona sztywno narzucona kolejność poszczególnych etapów. Analityk po stworzeniu modelu dziedziny problemu przekazuje wyniki swojej pracy projektantowi. Projektant, po stworzeniu projektu oprogramowania, w oparciu o wyniki etapu analizy, przekazuje go w ręce programisty, którego zadaniem jest jego implementacja. Następnie w celu zapewnienia wysokiej jakości produktu, kod jest testowany, a dopiero na samym końcu jest przekazywany klientowi. W procesie kaskadowym bardzo istotna jest forma przekazywania wyników z jednego etapu do drugiego. Niekiedy pojawiają się powroty, ale możliwość wystąpienia takiej sytuacji powinna być minimalizowana. Oczywistym jest przecież, że na przykład podczas implementacji może wystąpić jakiś problem, który zmusi zespół do powrotu do projektu lub co gorsza powtórnej analizy. Weryfikacja wyników poszczególnych etapów jest więc nieunikniona. Podstawowe cechy modelu kaskadowego niestety pokazują jednocześnie jego wady: Uzyskanie produktu spełniającego oczekiwania klienta niezwykle silnie zależy od stabilności wymagań, która jest przecież trudna do uzyskania. Weryfikacja zgodności produktu z wymaganiami i jego użyteczności następuje dopiero w końcowych krokach. Próba dopasowania produktu do zmieniających się wymagań, powoduje znaczący wzrostu kosztów budowy systemu. Kolejności wykonywania prac muszą być ściśle przestrzegane, co niekoniecznie trzeba uważać za wadę. Warto jednak zauważyć, że większość osób preferuje znacznie mniej rygorystyczne procesy wytwarzania oprogramowania. Wysoki koszt błędów popełnionych we wstępnych etapach jest bardzo charakterystyczną właściwością modelu kaskadowego. Przecież błędy popełnione na etapie zbierania lub analizy wymagań mogą być wykryte dopiero na etapie testów akceptacyjnych, bądź eksploatacji, a ich koszt o kilka rzędów wielkości przewyższać koszt błędów popełnionych podczas implementacji. Częstym argumentem podnoszonym przeciwko modelowi liniowemu jest zmarginalizowanie roli klienta w procesie wytwarzania oprogramowania. Długa przerwa w kontaktach z klientem, z którym ściśle współpracuje się podczas określania wymagań, pociąga za sobą ryzyko zmniejszenia zainteresowania klienta produktem, podczas gdy nie bierze on udziału w procesie wytwórczym. Klient przypomina sobie o systemie, który w końcu był przez niego zamawiany, na etapie wdrażania, kiedy to jego wizja na temat funkcjonalności, jaką system powinien zapewniać, może ulec istotnej zmianie. Warto nadmienić, że model kaskadowy mimo swych licznych wad, w nieco zmodyfikowanej postaci, stał się standardem, zalecanym przez Departament Obrony Narodowej Stanów Zjednoczonych (DOD STD 2167), stosowanym przy wytwarzaniu systemów informatycznych dla wojska. Standard ten jest ścisłą realizacją modelu kaskadowego kierowaną dokumentami. Na czym owa modyfikacja polega? Po prostu, każdy etap kończy się opracowaniem szeregu dokumentów, które z założenia są wystarczającą podstawą do realizacji kolejnych etapów. Dopiero akceptacja przez klienta dokumentacji zrealizowanego etapu pozwala na rozpoczęcie kolejnego. Rysunek 3. Model iteracyjny Software Developer s Journal 10/

3 Inżynieria oprogramowania Rysunek 4. Model V Model iteracyjny W modelu iteracyjnym wymagania są porządkowane i dzielone na mniejsze podzbiory. Każdy taki podzbiór wymaganej funkcjonalności wymaga przejścia przez etapy, o których była mowa w modelu kaskadowym. Po zakończeniu każdej iteracji wybierany jest kolejny podzbiór wymagań do realizacji i ponownie przechodzimy przez wszystkie etapy wytwarzania oprogramowania. Zauważmy, że takie podejście pozwala na szybką implementację przynajmniej części wymaganej funkcjonalności (tej o najwyższym priorytecie, lub też stanowiącej najwyższe ryzyko niepowodzenia realizacji). Model iteracyjny pozwala więc na bardzo szybką weryfikację realizowalności wytwarzanego systemu i informację zwrotną od klienta, czy to, czego potrzebuje, jest tym, co otrzyma jako produkt procesu wytwórczego. Praktyka stosowania procesu iteracyjnego zaleca przed rozpoczęciem rzeczywistych iteracji przeprowadzenie swego rodzaju rozpoznania wymagań, w celu uzyskania ogólnego obrazu i zakresu projektu. Celem, jaki przyświeca tym działaniom, jest podział wymagań na właściwe iteracje. Takie wstępne działania polegają najczęściej na stworzeniu ogólnej architektury systemu, a niekiedy nawet jego prototypu. Ciekawą i moim zdaniem niezwykle pożądaną odmianą procesu iteracyjnego jest możliwość przekazania systemu do wdrożenia, gdy tylko jakiś rozsądny podzbiór wymagań zostanie zaimplementowany i przetestowany. Jest to korzystne, co najmniej z dwóch powodów: wcześniej można uzyskać pewne korzyści (nie ma co ukrywać, że chodzi tu o korzyści finansowe) z wdrożenia systemu, ale również, co w dłuższej perspektywie jest ważniejsze, można uzyskać w pełni obiektywne opinie na temat jego działania w rzeczywistych warunkach. W takich sytuacjach system można wypuszczać w kolejnych wydaniach, z których każde podzielone jest na pewną liczbę iteracji. Rysunek 5. Model spiralny 54 Software Developer s Journal 10/2006

4 Przegląd modeli cyklu życia oprogramowania Bardzo często można spotkać się z pojęciem procesu przyrostowego, ewolucyjnego lub spiralnego, które w praktyce są tym samym, co proces iteracyjny. Oczywiście na gruncie teoretycznym rozważa się różnice pomiędzy tymi procesami, ale nie są one wyraźne. W dalszej części artykułu przedstawiony jednak zostanie model spiralny, ze względu na częste odwołania się do niego w literaturze dotyczącej omawianego tematu. Model kaskadowy i model iteracyjny możliwe scalenie Przedstawiony opis modelu kaskadowego i iteracyjnego został znacząco uproszczony, aby czytelnik uchwycił podstawową różnicę pomiędzy tymi procesami. Praktyka pokazuje, że oba procesy mogą podlegać bardzo wielu zaburzeniom, co nie oznacza oczywiście, że wówczas system jest realizowany niemetodycznie. Często proponowanym rodzajem procesu jest tzw. etapowy cykl tworzenia oprogramowania, które stanowi scalenie modelu kaskadowego i modelu iteracyjnego. Proponuje się w nim dokonać według modelu kaskadowego zbierania wymagań, analizy i projektowania, a implementację i testowanie podzielić następnie na iteracje. Wdrożenia można natomiast dokonać po zaimplementowaniu i przetestowaniu całości wymagań ponownie według modelu kaskadowego lub też może to polegać na instalacji kolejnych wydań systemu, co zależy oczywiście od charakteru projektu i uzgodnień z klientem. Oczywistym jest, co już zostało wspomniane, że to drugie podejście wydaje się być z różnych przyczyn korzystniejsze zarówno dla twórców, jak i odbiorców systemu. Można śmiało postawić tezę, że jednym z głównych powodów modyfikacji modelu kaskadowego elementami charakterystycznymi dla procesu iteracyjnego są względy finansowe, a nie jak by się mogło wydawać oczywiste zalety iteracyjnego podejścia do wytwarzania oprogramowania. Zauważmy, że wykonawca żąda pieniędzy za każdy wykonany etap. Z kolei klient, płacąc za wykonany etap, żąda wyników, które jest wstanie ocenić pod względem zgodności z wymaganiami (a często niestety mało precyzyjnymi wyobrażeniami). Model V Rozwinięciem modelu wodospadu jest model V, charakteryzujący się rozbudowaną fazą testów. Model V jest jednym z najpopularniejszych podejść do procesu testowania. Testy mają na celu weryfikację i walidację poprawności wykonania każdego etapu stanowiącego cykl życia oprogramowania. Dzięki rozbudowaniu sekwencji etapów wytwórczych o testowanie otrzymujemy produkt o najwyższej jakości, spełniający wymagania klienta. Model V podobnie jak klasyczny model kaskadowy stwarza bardzo duże niebezpieczeństwo. Oczywistym jest przecież, że im później zostanie wykryty błąd lub niezgodność z wymaganiami, tym kosztowniejsza będzie naprawa. Dzięki temu, że każdy z etapów wytwórczych kończy się różnego rodzaju przeglądami i inspekcjami prawdopodobieństwo pojawienia się błędu lub niezgodności z wymaganiami przy wdrożeniu i eksploatacji jest dużo mniejsze niż w modelu klasycznym. Powoduje to znaczące obniżenie kosztów pielęgnacji systemu. Dodatkowo wynikiem każdego etapu wytwórczego są plany testów, które po zakończeniu zstępującego cyklu produkcyjnego (lewe ramię litery V) realizowane są wstępująco (prawe ramię litery V). Model spiralny Model spiralny jest w pewnym sensie próbą formalizacji podejścia iteracyjnego do wytwarzania oprogramowania. Główną cechą tego modelu jest analiza ryzyka występująca w każdej iteracji. Ciągłe monitorowanie i pomiar zmian, które poddawane są krytycznemu spojrzeniu użytkownika, umożliwiają dokonanie analizy ryzyka. Pierwszą czynnością, która nie jest przedstawiona na rysunku obrazującym model spiralny, jest analiza wymagań wstępnych. Jeżeli wymagania wydają się być realizowalne w założonym czasie, budżecie i przy dostęp- R E K L A M A

5 Inżynieria oprogramowania ocena przez klienta walidacja wydania i jego ocena z możliwością modyfikacji wymagań na system (możliwość wystąpienia modyfikacji wymagań powinna być minimalizowana). Główne zalety modelu spiralnego to próba minimalizacji ryzyka niepowodzenia przedsięwzięcia oraz ciągła weryfikacja produktu przez użytkownika, co ma na celu wytworzenie produktu w pełni satysfakcjonującego klienta. Rysunek 6. Model prototypowania nych zasobach (tzw. zasad trójkąta) można przejść do planowania projektu i pierwszej iteracji. Właściwie kolejne iteracje mają postać małych wodospadów. Po każdej takiej pełnej iteracji dokonuje się przeglądu systemu. Jeżeli dane przedsięwzięcie wymaga dalszych prac wówczas należy zaplanować kolejną iterację, a następnie przeprowadzić analizę ryzyka realizacji kolejnego wydania. Model spiralny stanowi więc obudowaną wersję modelu wodospadu opartą o bieżącą analizę ryzyka. Model spiralny można postrzegać jako cyklicznie powtarzane cztery czynności: planowanie na podstawie wymagań i celów wyznaczonych przez klienta, dokonuje się określenia alternatyw i ograniczeń oraz planowania iteracji przy każdorazowym rozpoczęciu kolejnego cyklu spirali. analiza ryzyka sprowadza się do oceny rozwiązań alternatywnych oraz próby identyfikacji i analizy ryzyka związanego z każdą z możliwych alternatyw konstrukcji nowego wydania. konstrukcja ma postać małego wodospadu, a jej celem jest wytworzenie kolejnego wydania systemu. Prototypowanie Model prototypowania jest kolejną próbą radzenia sobie z problemem identyfikacji i braku stabilności wymagań. Prototypowanie polega na budowaniu kolejnych przybliżeń systemu do momentu aż prototyp stanie się dobrym odzwierciedleniem wymagań. Oceny prototypów i kolejne wersje owych prototypów, w sposób bardzo naturalny prowadzą do identyfikacji wymagań. Zauważmy, że prototypowanie w tym przypadku pokrywa etap analizy wymagań i stąd często przedstawiany model określa się jako prototypowanie wymagań. Cechą charakterystyczną prototypowania wymagań jest budowa szybkiego projektu bez dbałości o jego jakość i dostosowanie do środowiska docelowego. Oczywiście możliwe jest szersze spojrzenie na prototypowanie tak, aby obejmowało ono również etap projektowania w celu weryfikacji efektywności przyjętych rozwiązań. Ten rodzaj prototypowania określany jest mianem prototypowania wytwórczego. Gdy mamy już pewność, że wszystkie wymagania zostały zidentyfikowane, wówczas można przystąpić do konstrukcji właściwego produktu zgodnie z modelem klasycznym wytwarzania oprogramowania, rozpoczynając od etapu projektowania. Tego typu podejście może niekiedy spotkać się z niezrozumieniem ze strony klienta, bądź też pojawić się na wyższych szczeblach zarządzania firmą wykonawcy. Często pojawiają się pytania typu: Dlaczego trzeba zaczynać wszystko od nowa jeśli już prawie wszystko zrobiono? Kolejną wadą prototypowania jest możliwość przyzwyczajenia się klienta do funkcjonalności oferowanej przez prototyp, a która nie wynika z przyjętych wymagań. Również projektant może przyzwyczaić się do rozwiązań zastosowanych w prototypie. Reasumując, model prototypowy musi być dobrze rozumiany przez obie strony tj. zarówno twórcę systemu informatycznego, jak i klienta. Planowanie predykcyjne i adaptacyjne Wybór procesu wytwarzania oprogramowania bardzo silnie zależeć będzie od stabilności wymagań. Również sposób planowania jest uzależniony od stabilności wymagań. Przy założeniu, że wymagania, które zostały zebrane nie będą już się zmieniały, jak również klient nie będzie dodawał nowych, za- Literatura [1] Marin Fowler UML Distilled: A Brief Guide To The Standard Object Modeling Language, Pearson Education, Inc., 2004; [2] Stanisław Szejko Metody wytwarzania oprogramowania, MIKOM, Warszawa 2002; [3] Graham I. Inżynieria oprogramowania metody obiektowe w teorii i praktyce, WNT, Warszawa Software Developer s Journal 10/2006

6 Przegląd modeli cyklu życia oprogramowania leca się planowanie predykcyjne. Planowanie predykcyjne jest bardzo często narzucone w projektach rządowych i dla wojska. Trudno wyobrazić sobie tutaj inny sposób planowania, ponieważ mamy najczęściej sztywną datę zakończenia i kwotę budżetu. Ustalenia pomiędzy twórcą systemu i zamawiającym muszą jednoznacznie precyzować, co właściwie jest do zrobienia, ile produkt finalny będzie kosztował i kiedy zostanie ukończony. To dlatego w tego typu projektach możliwe jest wykorzystania procesu kaskadowego. Dla administracji nic przecież nie jest bardziej kłopotliwe niż brak jasnej wizji kosztu wytworzenia jakiegoś produktu i czasu jego realizacji. Powstaje jednak pytanie, czy projekty informatyczne mogą być w ogóle przewidywalne. Bez wątpienia w większości projektów można się spotkać z chaosem wymagań. Chaos polega na wprowadzaniu zmian do wymagań w późniejszych etapach cyklu życia oprogramowania. Zmiany takie praktycznie zawsze powodują konieczność przebudowy pierwotnie stworzonego planu projektu. Oczywiście można próbować walczyć z taką sytuacją. Powszechnie stosowanym sposobem radzenia sobie ze zmianami życzeń klienta jest zamrożenie na pewnym etapie zbioru wymagań. Powstaje jednak pewien problem. Zamrożenie wymagań powoduje ryzyko stworzenia produktu, który właściwie nie jest potrzebny klientowi już w chwili wdrażania. Można jednak inaczej próbować podejść do problemu zmieniających się wymagań. Zakładamy mianowicie, że chaos wymagań jest zjawiskiem nieuniknionym, a pełna przewidywalność to iluzja. Doskonale sprawdza się wówczas planowanie adaptacyjne, które traktuje zmiany jako coś zupełnie naturalnego. Zmiany muszą być oczywiście kontrolowane. Ciekawą rzeczą jest fakt, że w przypadku planowania adaptacyjnego ciężko powiedzieć, że system jako całość rozwija się zgodnie z planem, a to dlatego, że taki plan ulega ciągłej modyfikacji. Oznacza to tyle, że plan służy raczej do możliwości oszacowania konsekwencji wprowadzenia zmian niż do przewidywania, kiedy system zostania oddany w ręce klienta. W przypadku planowania adaptacyjnego można oczywiście na stałe określić budżet przewidziany na projekt i czas jego zakończenia, jednak nie można przewidzieć zakresu wymagań, które zostaną zrealizowane. Planowanie adaptacyjne wymaga ścisłej permanentnej współpracy zespołu projektowego z klientem, a zbiór wymagań może być dość elastycznie modyfikowany, rozszerzany, a niekiedy zawężany, oczywiście wszystko za porozumieniem obu stron. W tego typu projektach zastosowanie modelu kaskadowego z góry skazane jest na niepowodzenie. Plan adaptacyjny możliwy jest do zastosowania jedynie w przypadku zastosowania procesu iteracyjnego i jego licznych modyfikacji, z których niektóre przedstawione zostały w artykule. Podsumowanie Badania prowadzone w Stanach Zjednoczonych wykazały, że ponad 2/3 wszystkich projektów informatycznych kończą się niepowodzeniem. Niepowodzenie było najczęściej rezultatem braku środków finansowych na kontynuowanie projektu (niedoszacowanie kosztów), stworzenie produktu, który nie spełnia wymagań klienta lub zakończenie procesu wytwarzania z bliżej nieokreślonych względów (często politycznych). Powodów porażki może być wiele, ale najczęściej wskazywanymi były: brak większego zaangażowania ze strony klienta; zbyt ogólnie sformułowane wymagania lub ich modyfikacja; brak właściciela projektu; brak planu działania. Wydaje się więc, że rozważania na temat procesu wytwarzania oprogramowania są potrzebne, ponieważ twórcom systemów informatycznych zależy na tym, aby sukces jednego projektu przekładał się na następny, aby był powtarzalny. Takie podejście daje możliwość doskonalenia procesu wytwarzania oprogramowania poprzez dokonywanie pomiarów i oszacowań, a to z kolei wpływa na polepszenie jakości produktu i zadowolenie klienta. Nie wolno zapominać, że proces wytwarzania oprogramowania powinien być wspomagany przez narzędzia CASE, które oczywiście wymagają odpowiedniej konfiguracji na potrzeby danego projektu. Umiejętność wykorzystania tego typu narzędzi jest praktycznie warunkiem koniecznym powodzenia każdego większego przedsięwzięcia informatycznego. R E K L A M A

Cykle życia systemu informatycznego

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Przedsięwzięcia Informatyczne w Zarządzaniu

Przedsię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ółowo

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

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

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

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

Bardziej szczegółowo

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10.

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10. Bez celu ani rusz Karolina Zmitrowicz Niepowodzenia projektów informatycznych to nieustannie wdzięczny temat pojawia się na konferencjach, szkoleniach, w prasie i innych publikacjach. Badaniem przyczyn

Bardziej szczegółowo

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

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

Bardziej szczegółowo

Zarządzanie projektami IT

Zarzą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ółowo

KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA

KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA Wykład 9 Cykl życia systemu informatycznego Dr inż. Mariusz Makuchowski Cykl życia systemu informatycznego Przez cykl życia systemu informatycznego należy rozumieć określoną

Bardziej szczegółowo

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:

Komputerowe 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ółowo

Projektowanie systemów informatycznych. wykład 6

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

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Zarządzanie projektami w NGO

Zarządzanie projektami w NGO Zarządzanie projektami w NGO Warsztaty dla Grupy Nowe Technologie Federacja Organizacji Służebnych MAZOWIA 4 września 2012 Projekt współfinansowany jest ze środków Unii Europejskiej w ramach Europejskiego

Bardziej szczegółowo

SVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1

SVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1 SVN 10 października 2011 Instalacja Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację uruchamiany ponownie komputer Rysunek 1: Instalacja - krok 1 Rysunek 2: Instalacja - krok 2

Bardziej szczegółowo

Inżynieria oprogramowania I

Inżynieria oprogramowania I Kontakt Inżynieria I Andrzej Jaszkiewicz Andrzej Jaszkiewicz p. 424y, Piotrowo 3a tel. 66 52 371 jaszkiewicz@cs.put.poznan.pl www-idss.cs.put.poznan.pl/~jaszkiewicz Literatura A. Jaszkiewicz, Inżynieria,

Bardziej szczegółowo

Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015

Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015 Zarządzanie zmianą - rozwój zarządzania procesowego wg ISO 9001:2015 ZAPEWNIAMY BEZPIECZEŃSTWO Piotr Błoński, Warszawa, 17.03.2016 r. Program 1. Zarządzanie zmianą - zmiany w normie ISO 9001:2015 2. Zarządzanie

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

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

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres 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ółowo

Feature Driven Development

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

Bardziej szczegółowo

Launch. przygotowanie i wprowadzanie nowych produktów na rynek

Launch. przygotowanie i wprowadzanie nowych produktów na rynek Z przyjemnością odpowiemy na wszystkie pytania. Prosimy o kontakt: e-mail: kontakt@mr-db.pl tel. +48 606 356 999 www.mr-db.pl MRDB Szkolenie otwarte: Launch przygotowanie i wprowadzanie nowych produktów

Bardziej szczegółowo

Inżynieria Oprogramowania. Inżynieria Oprogramowania 1/36

Inżynieria Oprogramowania. Inżynieria Oprogramowania 1/36 Inżynieria Oprogramowania Inżynieria Oprogramowania 1/36 Inżynieria Oprogramowania 2/36 Literatura 1. Gamma E. i in.: Wzorce projektowe, WNT, Warszawa 2005 2. Jaszkiewicz A.: Inżynieria oprogramowania,

Bardziej szczegółowo

ZASADY TWORZENIA OPROGRAMOWANIA

ZASADY 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

Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16

Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: 06-07 marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Cena: 980 zł netto (1 osoba / 2 dni

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

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

Bardziej szczegółowo

Projektowanie systemów informatycznych

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

Bardziej szczegółowo

Wprowadzenie do systemów informacyjnych

Wprowadzenie 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ółowo

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

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

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

Agile Project Management

Agile Project Management Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...

Bardziej szczegółowo

Projektowanie zorientowane na uŝytkownika

Projektowanie zorientowane na uŝytkownika Uniwersytet Jagielloński Interfejsy graficzne Wykład 2 Projektowanie zorientowane na uŝytkownika Barbara Strug 2011 Hall of shame Hall of shame Model wodospad Feedback Problem z modelem waterfall Projektowanie

Bardziej szczegółowo

MSF. Microsoft Solution Framework

MSF. Microsoft Solution Framework MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie

Bardziej szczegółowo

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

Bardziej szczegółowo

Darmowy fragment www.bezkartek.pl

Darmowy fragment www.bezkartek.pl Wszelkie prawa zastrzeżone. Rozpowszechnianie całości lub fragmentów niniejszej publikacji w jakiejkolwiek postaci bez zgody wydawcy zabronione. Autor oraz wydawca dołożyli wszelkich starań aby zawarte

Bardziej szczegółowo

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie.

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie. Inżynieria I Andrzej Jaszkiewicz Kontakt Andrzej Jaszkiewicz p. 8, CW Berdychowo tel. 66 52 933 ajaszkiewicz@cs.put.poznan.pl Rynek 2008 Świat 304 miliardy $ (451 miliardów 2013F) Bez wytwarzanego na własne

Bardziej szczegółowo

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka Zmiany w standardzie ISO 9001 dr inż. Ilona Błaszczyk Politechnika Łódzka 1 W prezentacji przedstawiono zmiany w normie ISO 9001 w oparciu o projekt komitetu. 2 3 4 5 6 Zmiany w zakresie terminów używanych

Bardziej szczegółowo

4. Wprowadzanie Scruma w ImmobilienScout24 4.1. Opis sytuacji

4. Wprowadzanie Scruma w ImmobilienScout24 4.1. Opis sytuacji Spis treści Przedmowa 1. Wstęp 1.1. Jak czytać tę książkę 1.2. Studia projektów 1.3. Dodatek 2. Zwinny projekt to nie bułka z masłem 2.1. Pobudka 2.2. Zespół się formuje 2.3. Właściwe zlecenie 2.4. Od

Bardziej szczegółowo

Spis treści. 00 Red. Spis tresci. Wstep..indd 5 2009 12 02 10:52:08

Spis treści. 00 Red. Spis tresci. Wstep..indd 5 2009 12 02 10:52:08 Spis treści Wstęp 9 Rozdział 1. Wprowadzenie do zarządzania projektami 11 1.1. Istota projektu 11 1.2. Zarządzanie projektami 19 1.3. Cykl życia projektu 22 1.3.1. Cykl projektowo realizacyjny 22 1.3.2.

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

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

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarządzanie testowaniem wspierane narzędziem HP Quality Center Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe

Bardziej szczegółowo

Klasyczna organizacja też może być zwinna! Zarządzaj zwinnie projektami!

Klasyczna organizacja też może być zwinna! Zarządzaj zwinnie projektami! Klasyczna organizacja też może być zwinna! Dynamika zmian w dzisiejszym świecie IT wymaga niezwykłej elastyczności i błyskawicznego adaptowania się do nowych warunków. Klasyczne techniki zarządzania projektami

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania (IO) Wykłady: mgr inż. Sławomir Wróblewski Godziny przyjęć: wtorki 10-11, środy 15-16 pokój nr 19 (6 piętro) Katedra Mikroelektroniki i Technik informatycznych Politechniki Łódzkiej,

Bardziej szczegółowo

Optymalizacja Automatycznych Testów Regresywnych

Optymalizacja Automatycznych Testów Regresywnych Optymalizacja Automatycznych Testów Regresywnych W Organizacji Transformującej do Agile Adam Marciszewski adam.marciszewski@tieto.com Agenda Kontekst projektu Typowe podejście Wyzwania Cel Założenia Opis

Bardziej szczegółowo

Cele oraz techniki tworzenia prototypów systemów infromatycznych. Inżynieria Oprogramowania

Cele oraz techniki tworzenia prototypów systemów infromatycznych. Inżynieria Oprogramowania Cele oraz techniki tworzenia prototypów systemów infromatycznych Zagadnienia Rola oraz umiejscowienie prototypowania w procesie tworzenia oprogramowania Rola prototypu w procesie walidacji wymagań systemowych

Bardziej szczegółowo

Metoda 5-WHY. Metoda 5-WHY. Wydanie 1. Zbigniew Huber. Maj 2006. Artykuł dostępny na stronie autora: http://www.huber.pl.

Metoda 5-WHY. Metoda 5-WHY. Wydanie 1. Zbigniew Huber. Maj 2006. Artykuł dostępny na stronie autora: http://www.huber.pl. Metoda 5-WHY Wydanie 1 Zbigniew Huber Maj 2006 Artykuł dostępny na stronie autora: http://www.huber.pl Copyright by Zbigniew Huber Strona 1 z 6 Wstęp Rozwiązanie jakiegoś problemu i wprowadzenie skutecznego

Bardziej szczegółowo

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM 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ółowo

Projekt Kompetencyjny - założenia

Projekt Kompetencyjny - założenia Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu

Bardziej szczegółowo

Zagadnienia. Inżynieria Oprogramowania

Zagadnienia. 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ółowo

Wykład 1 Inżynieria Oprogramowania

Wykł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ółowo

"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".

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ółowo

Metodyka projektowania komputerowych systemów sterowania

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

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

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

Bardziej szczegółowo

Lean management w procesie obsługi klienta

Lean management w procesie obsługi klienta Lean management w procesie obsługi klienta Lean Management oznacza sprawne a zarazem efektywne kosztowe wykonywanie wszystkich działań w firmie przy założeniu minimalizacji strat, minimalizacji stanów

Bardziej szczegółowo

Testujemy dedykowanymi zasobami (ang. agile testers)

Testujemy 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ółowo

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

Zarządzanie projektami. Porównanie podstawowych metodyk

Zarządzanie projektami. Porównanie podstawowych metodyk Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

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

Bardziej szczegółowo

PROSKAR KREATYWNA INŻYNIERIA

PROSKAR KREATYWNA INŻYNIERIA PROSKAR KREATYWNA INŻYNIERIA Siedlce, 2013 O firmie Proskar jest firmą informatyczną specjalizującą się w wytwarzaniu oprogramowania Specjalizujemy się w wytwarzaniu dedykowanego oprogramowania w technologii

Bardziej szczegółowo

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV Metodyka wdrożenia Bartosz Szczęch Starszy Konsultant MS Dynamics NAV bartosz.szczech@it.integro.pl Wyróżniamy następujące etapy wdrożenia rozwiązania ERP: Analiza Projekt Budowa Uruchomienie Działanie

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

INŻ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ółowo

Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16. Miejsce: Eureka Technology Park, Innowatorów 8

Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16. Miejsce: Eureka Technology Park, Innowatorów 8 Szkolenie Scrum w projektach IT (Agile) METRYCZKA: Szkolenie Scrum Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Temat: Zwinne Zarządzanie

Bardziej szczegółowo

Szkolenie Scrum w projektach IT (Agile)

Szkolenie Scrum w projektach IT (Agile) METRYCZKA: Szkolenie Scrum Szkolenie Scrum w projektach IT (Agile) Data: 06-07 marzec 2014 r. (2 dni, czwartek-piątek), godz. 9-16 Miejsce: Eureka Technology Park, Innowatorów 8 Temat: Zwinne Zarządzanie

Bardziej szczegółowo

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010 Odpowiada na pytania: Jaka część projektów IT kończy się w Polsce sukcesem? Jak wiele projektów sponsorowanych jest przez instytucje publiczne? Czy kończą się

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Lekkie metodyki. tworzenia oprogramowania

Lekkie metodyki. tworzenia oprogramowania Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz

Bardziej szczegółowo

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu

Zarządzanie ryzykiem w projektach informatycznych. Marcin Krysiński marcin@krysinski.eu Zarządzanie ryzykiem w projektach informatycznych Marcin Krysiński marcin@krysinski.eu O czym będziemy mówić? Zarządzanie ryzykiem Co to jest ryzyko Planowanie zarządzania ryzykiem Identyfikacja czynników

Bardziej szczegółowo

Szkolenie 2. Zarządzanie programami

Szkolenie 2. Zarządzanie programami UNIWERSYTET MARII CURIE-SKŁODOWSKIEJ W LUBLINIE Projekt Nowoczesny model zarządzania w UMCS umowa nr UDA-POKL.04.01.01-00-036/11-00 Pl. Marii Curie-Skłodowskiej 5, 20-031 Lublin, www.nowoczesny.umcs.lublin.pl

Bardziej szczegółowo

ROLA DORADCY. Proces realizacji przedsięwzięć Partnerstwa Publiczno-Prywatnego

ROLA DORADCY. Proces realizacji przedsięwzięć Partnerstwa Publiczno-Prywatnego ROLA DORADCY Proces realizacji przedsięwzięć Partnerstwa Publiczno-Prywatnego Agenda Wprowadzenie Doradca Techniczny Doradca Finansowo-Ekonomiczny Doradca Prawny Podsumowanie 3P Partnerstwo Publiczno-Prywatne

Bardziej szczegółowo

ĆWICZENIE Lody na drodze Ent-teach Rozdział 6 Zarządzanie Projektami

ĆWICZENIE Lody na drodze Ent-teach Rozdział 6 Zarządzanie Projektami ĆWICZENIE Lody na drodze Ent-teach Rozdział 6 Zarządzanie Projektami Opis ćwiczenia W poniższym zadaniu, uczestnicy muszą zaplanować tydzień sprzedaży lodów na ulicy w ich rodzinnym mieście (centrum).

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO

Bardziej szczegółowo

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

Organizacja 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ółowo

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

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

Bardziej szczegółowo

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk dr T Bartosz Kalinowski 17 19 września 2008, Wisła IV Sympozjum Klubu Paragraf 34 1 Informacja a system zarządzania Informacja

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Załącznik Nr 3 do Zarządzenia Nr 52/2014 Rektora UMCS INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Spis treści Słownik pojęć... 1 Wprowadzenie... 2 Kroki zarządzania ryzykiem

Bardziej szczegółowo

Wdrożenie strategii zarządzania wiedzą i kreowania innowacyjności wewnątrz organizacji

Wdrożenie strategii zarządzania wiedzą i kreowania innowacyjności wewnątrz organizacji CASE STUDY: Wdrożenie strategii zarządzania wiedzą i kreowania innowacyjności wewnątrz organizacji Autor: Jacek Wach Redakcja: Dominik Noworól Spis treści Geneza / 03 Idea / 04 Wizja / 05 Rozwiązanie /

Bardziej szczegółowo

Korzyści wynikające z wdrożenia systemu zarządzania jakością w usługach medycznych.

Korzyści wynikające z wdrożenia systemu zarządzania jakością w usługach medycznych. Norma PN-EN ISO 9001:2009 System Zarządzania Jakością w usługach medycznych Korzyści wynikające z wdrożenia systemu zarządzania jakością w usługach medycznych. www.isomed.pl Grzegorz Dobrakowski Uwarunkowania

Bardziej szczegółowo

INFORMACJE O OFERENCIE

INFORMACJE O OFERENCIE INFORMACJE O OFERENCIE Doradztwo i Szkolenia Europejskie 91-426 Łódź, ul. Wierzbowa 4/20 Telefon/fax: (+42) 678 57 34, Telefon komórkowy: 604 477 754 e-mail: m.feter@dise.com.pl www: www.dise.com.pl Działalność

Bardziej szczegółowo

Jakość przed jakością

Jakość przed jakością Jakość przed jakością Oprogramowanie naprawdę przydatne (2) Robert Ganowski II Krajowa Konferencja Jakości Systemów Informatycznych, Warszawa, 21-22 czerwca 2005 r. 1 Teoria prawdy*

Bardziej szczegółowo

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Opis Progress Project zaprasza do zapoznania się z programem szkolenia organizowanego przez partnera szkoleniowego,

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Skuteczność => Efekty => Sukces

Skuteczność => Efekty => Sukces O HBC Współczesne otoczenie biznesowe jest wyjątkowo nieprzewidywalne. Stała w nim jest tylko nieustająca zmiana. Ciągłe doskonalenie się poprzez reorganizację procesów to podstawy współczesnego zarządzania.

Bardziej szczegółowo

Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK

Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK Zarządzanie projektami - narzędzia, software, dokumentacja, metodyka PMBOK Opis Szkolenie realizowane w ramach: Oferowane zajęcia umożliwiają uczestnikom poznanie najlepszych metod i narzędzi stosowanych

Bardziej szczegółowo

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

Analityk i współczesna analiza

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

Bardziej szczegółowo

SYSTEM ZARZĄDZANIA RYZYKIEM W DZIAŁALNOŚCI POLITECHNIKI WARSZAWSKIEJ FILII w PŁOCKU

SYSTEM ZARZĄDZANIA RYZYKIEM W DZIAŁALNOŚCI POLITECHNIKI WARSZAWSKIEJ FILII w PŁOCKU P OLITECHNIK A W AR S Z AWSKA FILIA W PŁOCKU ul. Łukasiewicza 17, 09-400 Płock SYSTEM ZARZĄDZANIA RYZYKIEM W DZIAŁALNOŚCI POLITECHNIKI WARSZAWSKIEJ FILII w PŁOCKU Opracowano na podstawie załącznika do

Bardziej szczegółowo

ŚCIEŻKA: Zarządzanie projektami

ŚCIEŻKA: Zarządzanie projektami ŚCIEŻKA: Zarządzanie projektami Ścieżka dedykowana jest każdej osobie, która chce rozwijać siebie i swoją organizację - w szczególności: Kadrze menedżerskiej i kierowniczej przedsiębiorstw Kierownikom

Bardziej szczegółowo

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM. Hubert Wawrzyniak Grupa Allegro

PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM. Hubert Wawrzyniak Grupa Allegro PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM Hubert Wawrzyniak Grupa Allegro PLAN PREZENTACJI 1. Projektowanie zorientowane na użytkownika 2. Model kaskadowy 3. Metodyka scrum 4. UCD w scrumie

Bardziej szczegółowo

Plan zarządzania projektem

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

Bardziej szczegółowo

Projektowanie interakcji

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

Bardziej szczegółowo

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny mgr inż. Kajetan Kurus 15 kwietnia 2014 1 Dostępne techniki programowania Tworząc program należy

Bardziej szczegółowo

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004. Zofia Kruczkiewicz

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004. Zofia Kruczkiewicz Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie 2. Jaki wpływ na ludzi, komunikację

Bardziej szczegółowo

Testowanie modeli predykcyjnych

Testowanie modeli predykcyjnych Testowanie modeli predykcyjnych Wstęp Podczas budowy modelu, którego celem jest przewidywanie pewnych wartości na podstawie zbioru danych uczących poważnym problemem jest ocena jakości uczenia i zdolności

Bardziej szczegółowo