Tworzenie oprogramowania nie jest sprawą
|
|
- Miłosz Dobrowolski
- 8 lat temu
- Przeglądów:
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: rafal.kasprzyk@wat.edu.pl 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 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
Etapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegół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ół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ół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ół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 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ół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ółowoSYSTEMY INFORMATYCZNE ćwiczenia praktyczne
SYSTEMY INFORMATYCZNE ćwiczenia praktyczne 12.03.2019 Piotr Łukasik p. 373 email: plukasik@agh.edu.pl / lukasik.pio@gmail.com www.lukasikpiotr.com Zakres tematyczny implementacji projektu informatycznego
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ół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ół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ółowoWaterfall 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ół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ół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ółowoWszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k.
Wszystkie problemy leżą w testach O czym będziemy rozmawiać Coś nie wyszło Jak wygląda proces wytwórczy Każdy widzi to inaczej Jakie wnioski wyciągamy z testów Analiza problemów Możliwe rozwiązania O czym
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ółowoZarzą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ółowoSVN. 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ółowoCzynniki 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ół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ół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ółowoUsługa: Audyt kodu źródłowego
Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności
Bardziej szczegółowoKOMPUTEROWE 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ółowoPriorytetyzacja przypadków testowych za pomocą macierzy
Priorytetyzacja przypadków testowych za pomocą macierzy W niniejszym artykule przedstawiony został problem przyporządkowania priorytetów do przypadków testowych przed rozpoczęciem testów oprogramowania.
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ółowoEgzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
Bardziej szczegółowoProjektowanie 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ółowoZarzą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ół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ół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ółowoLaunch. 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ółowoDarmowy 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ółowo4. 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ół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ółowoMODELE CYKLU śycia OPROGRAMOWANIA
MODELE CYKLU śycia OPROGRAMOWANIA Plan prezentacji: Definicja procesu i procesu programowego Model buduj i poprawiaj Model kaskadowy (czysty i z nawrotami) Modele ewolucyjne (spiralny i przyrostowy) Prototypowanie
Bardziej szczegółowoAgile 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ół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ółowoInż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ółowoPodstawy 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ółowoSpis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08
Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.
Bardziej szczegółowoGłówne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)
Extreme programming Główne założenia XP Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness) Praktyki Planowanie: Planowanie releasu Planowanie iteracji
Bardziej szczegółowoProgramowanie Zespołowe
Programowanie Zespołowe Programowanie zwinne dr Rafał Skinderowicz mgr inż. Michał Maliszewski Programowanie zwinne Grupa metodyk wytwarzania oprogramowania oparta na modelu iteracyjno-obiektowym Powstała
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ółowoDwie szkoły oceny 360 stopni. Sprawdź różnicę pomiędzy klasycznym a nowoczesnym podejściem
Sprawdź różnicę pomiędzy klasycznym a nowoczesnym podejściem Czy stosowanie tradycyjnego podejścia do metody 360 stopni jest jedynym rozwiązaniem? Poznaj dwa podejścia do przeprowadzania procesu oceny
Bardziej szczegółowoDwuwymiarowy sposób na podróbki > 34
TEMAT NUMERU I Bezpieczeństwo WIELE WYMIARÓW BEZPIECZEŃSTWA I zapobieganie zanieczyszczeniom krzyżowym I walka z fałszowaniem leków I walidacja rozwiązań chmurowych Maszyny rozwoju > 20 Dwuwymiarowy sposób
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ół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ółowoOD JAKOŚCI DO TRWAŁOŚCI REZULTATÓW W PROJEKTACH ERASMUS+
OD JAKOŚCI DO TRWAŁOŚCI REZULTATÓW W PROJEKTACH ERASMUS+ Zapewnienie jakości Anna Bielecka Agnieszka Włodarczyk Warszawa, 30 października 2017 r. CZYM JEST JAKOŚĆ? JAKOŚĆ NIE JEST POJĘCIEM CAŁKOWICIE
Bardziej szczegółowoZarzą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ółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.
Bardziej szczegółowoTemat: 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ółowoMetody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31
Metody wytwarzania oprogramowania Metody wytwarzania oprogramowania 1/31 Metody wytwarzania oprogramowania 2/31 Wprowadzenie Syndrom LOOP Late Późno Over budget Przekroczono budżet Overtime nadgodziny
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ółowoRyzyko i zarządzanie ryzykiem w projektach
Wykład objęty jest prawami autorskimi Prof.dr hab. Małgorzata Duczkowska-Piasecka Przedmiot: Zarządzanie projektami biznesowymi Ryzyko i zarządzanie ryzykiem w projektach Ryzyko może być definiowane jako
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński programowanie.siminskionline.pl. Cykl życia systemu informatycznego
systemów informatycznych Roman Simiński roman.siminski@us.edu.pl programowanie.siminskionline.pl Cykl życia systemu informatycznego Trochę wprowadzenia... engineering co to oznacza? Oprogramowanie w sensie
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ółowoOPTYMALIZACJA HARMONOGRAMOWANIA MONTAŻU SAMOCHODÓW Z ZASTOSOWANIEM PROGRAMOWANIA W LOGICE Z OGRANICZENIAMI
Autoreferat do rozprawy doktorskiej OPTYMALIZACJA HARMONOGRAMOWANIA MONTAŻU SAMOCHODÓW Z ZASTOSOWANIEM PROGRAMOWANIA W LOGICE Z OGRANICZENIAMI Michał Mazur Gliwice 2016 1 2 Montaż samochodów na linii w
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ółowoZarzą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ółowoNarzę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ółowoInż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ółowoProjektowanie 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ół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ółowoISO 9000/9001. Jarosław Kuchta Jakość Oprogramowania
ISO 9000/9001 Jarosław Kuchta Jakość Oprogramowania Co to jest ISO International Organization for Standardization największa międzynarodowa organizacja opracowująca standardy 13700 standardów zrzesza narodowe
Bardziej szczegółowoTematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 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 x 1 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoUsprawnienie 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Ć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ółowoProjektowanie 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ółowoZmiany 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ółowoZarządzanie jakością w logistyce ćw. Artur Olejniczak
ćw. artur.olejniczak@wsl.com.pl Plan spotkań Data Godziny Rodzaj 18.03.2012 4 godziny ćw. 14:30-15:30 dyżur 14.04.2012 4 godziny ćw. 28.04.2012 4 godziny ćw. 14:30-15:30 dyżur 19.05.2012 4 godziny ćw.
Bardziej szczegółowoAgile 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ółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Studium wykonalności
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Studium wykonalności Główne procesy w realizacji projektu informatycznego Studium wykonalności (ang. feasibility
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ółowoWprowadzenie w tematykę zarządzania projektami/przedsięwzięciami
Wprowadzenie w tematykę zarządzania projektami/przedsięwzięciami punkt 2 planu zajęć dr inż. Agata Klaus-Rosińska 1 DEFINICJA PROJEKTU Zbiór działań podejmowanych dla zrealizowania określonego celu i uzyskania
Bardziej szczegółowoMetoda lean start-up
Metoda lean start-up Autorzy Steve Blank Bob Dorf Eric Ries Start-up Tymczasowa organizacja stworzona w celu znalezienia powtarzalnego i skalowalnego modelu biznesowego. Przedsiębiorcy odnoszący sukces
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoModelowanie jako sposób opisu rzeczywistości. Katedra Mikroelektroniki i Technik Informatycznych Politechnika Łódzka
Modelowanie jako sposób opisu rzeczywistości Katedra Mikroelektroniki i Technik Informatycznych Politechnika Łódzka 2015 Wprowadzenie: Modelowanie i symulacja PROBLEM: Podstawowy problem z opisem otaczającej
Bardziej szczegółowoMSF. 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ółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy
Bardziej szczegółowoModel referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami
Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary
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ółowoInżynieria oprogramowania. Część 8: Metoda szacowania ryzyka - PERT
UNIWERSYTET RZESZOWSKI KATEDRA INFORMATYKI Opracował: mgr inż. Przemysław Pardel v1.01 2010 Inżynieria oprogramowania Część 8: Metoda szacowania ryzyka - PERT ZAGADNIENIA DO ZREALIZOWANIA (3H) PERT...
Bardziej szczegółowoSpis 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ółowoZarzą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ół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ółowoTestowanie oprogramowania. Testowanie oprogramowania 1/34
Testowanie oprogramowania Testowanie oprogramowania 1/34 Testowanie oprogramowania 2/34 Cele testowania testowanie polega na uruchamianiu oprogramowania w celu wykrycia błędów, dobry test to taki, który
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ółowoKlasyczna 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ółowoCele 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ół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 hab. inż. Krzysztof Bartecki, prof. PO www.k.bartecki.po.opole.pl Egzamin: część teoretyczna Test jednokrotnego
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ółowoRAPORT 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ółowoTematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 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. x 3 2. Jaki wpływ na ludzi, komunikację
Bardziej szczegółowoDesign thinking zaprojektuj, zbuduj i przetestuj swoje pomysły
Design thinking zaprojektuj, zbuduj i przetestuj swoje pomysły Cel szkolenia: Termin: 26.11.2016 r. Design thinking jest metodą, która pozwala na bardzo szybkie tworzenie innowacyjnych produktów lub usług,
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ółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
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ółowoOptymalizacja 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ółowoSzkolenie 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ółowoWdroż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