WYDZIAŁ ZARZĄDZANIA Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie

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

Download "WYDZIAŁ ZARZĄDZANIA Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie"

Transkrypt

1 WYDZIAŁ ZARZĄDZANIA Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Studia Podyplomowe ZARZĄDZANIE PROJEKTAMI KWALIFIKACJE PROJECT MANAGERA edycja 2013/2014 Praca podyplomowa ZARZĄDZANIE JAKOŚCIĄ W PROJEKTACH WYTWARZANIA OPROGRAMOWANIA NA PRZYKŁADZIE PROGRAMOWANIA EKSTREMALNEGO Autor: Robert Pająk Kraków, Czerwiec 2014

2 SPIS TREŚCI WSTĘP... 3 JAKOŚĆ W PROJEKTACH WYTWARZANIA OPROGRAMOWANIA... 5 Definicja jakości... 5 Jakość oprogramowania... 5 Składowe jakości... 6 ZARZĄDZANIE JAKOŚCIĄ... 9 Planowanie jakości Usprawnianie procesów Pomiary i miary jakości Zapewnianie jakości Kontrola jakości Weryfikacja i zatwierdzanie Testowanie Przeglądy PROGRAMOWANIE EKSTREMALNE JAKO METODYKA SKONCENTROWANA NA JAKOŚCI Wartości Zasady Praktyki Zarządzanie jakością Planowanie jakości Zapewnienie jakości Kontrola jakości Doskonalenie jakości PODSUMOWANIE BIBLIOGRAFIA

3 WSTĘP Jakość oprogramowania to wieloaspektowe zagadnienie. W rzeczywistości spojrzenie na jakość z kilku perspektyw jednocześnie jest kluczowe do zrozumienia i wytworzenia wartościowego produktu oraz zaspokojenia jawnych i ukrytych potrzeb klienta. Często można usłyszeć, że zagadnienia związane z jakością w świecie oprogramowania są inne niż w przypadku innych produktów, jednak nie jest to do końca prawdą. Ogólnie mówiąc zasady, systemy i metodyki jakościowe stosowane w produkcji są równie prawidłowe w przypadku oprogramowania i innych dóbr czy usług. Jednak oprogramowanie charakteryzuje się specyficznym środowiskiem projektowania i rozwoju. W celu efektywnego zarządzania jakością oprogramowania, należy poznać typowe wyzwania wynikające z abstrakcyjnej natury systemów cyfrowych oraz poziomu złożoności wielu aplikacji. Ponadto należy wziąć pod uwagę innowacyjność i trudność zadań, do których rozwiązania zostały zaprojektowane. W projektach wytwarzania oprogramowania problemy z jakością występują niemal zawsze. Najczęściej wynikają one z pewnych braków poznawczych potrzeb klienta. Wymagania związane z oprogramowaniem ulegają bardzo częstym zmianom. Jako odpowiedź na ten problem zaczęto stosować podejście adaptacyjne, które wyewoluowało do tzw. metodyk zwinnych. Jedną z pierwszych jest programowanie ekstremalne, które do dnia dzisiejszego cieszy się uznaniem wśród inżynierów oprogramowania. Ta metodyka w szczególny sposób kładzie nacisk na tworzenie oprogramowania wysokiej jakości w warunkach wysokiego ryzyka i częstych zmian. Celem niniejszej pracy jest przedstawienie problematyki związanej z jakością oprogramowania. Oprócz opisu podstawowych sposobów zarządzania jakością w projektach wytwarzania oprogramowania przedstawiona została metodyka programowania ekstremalnego, która podchodzi do jakości w bardzo kompleksowy sposób. Unikatowym elementem pracy jest analiza zarządzania jakością wprowadzanego przez metodykę. W pierwszym rozdziale przedstawione zostały najważniejsze informacje związane z jakością w projektach wytwarzania oprogramowania. W szczególności został przedstawiony model jakości oprogramowania według normy ISO/IEC 9126 oraz wymienione parametry jakości zgodnie z normą ISO/IEC

4 Kolejny rozdział omawia tematykę zarządzania jakością w projektach, ze szczególnym uwzględnieniem projektów wytwarzania oprogramowania. Treść powstała na podstawie najbardziej wpływowej literatury związanej z tą tematyką (m.in. ISO 9000, Software Engineering autorstwa Iana Sommervilla) oraz najpopularniejszych metodyk zarządzania projektami PMBOK oraz PRINCE2. Ostatni rozdział przestawia zwięźle metodykę programowania ekstremalnego. Ponadto obrazuje jak wygląda zarządzanie jakością w projektach rozwijanych zgodnie z tą metodyką. Kolejnym planowanym etapem rozwoju omawianej problematyki jest analiza problemów związanych z programowaniem ekstremalnym. W szczególności próba wyjaśnienia powodów, dla których programowanie ekstremalne nie jest szeroko stosowane. 4

5 ROZDZIAŁ I JAKOŚĆ W PROJEKTACH WYTWARZANIA OPROGRAMOWANIA 1. Definicja jakości Jakość jest pojęciem względnym, które w zależności od kontekstu, kultury, środowiska może być różnie rozumiane. Przeważanie kryje się pod nim wszystko co ma związek z pewnymi cechami produktu lub usługi, mającymi wpływ na jego postrzeganie przez klienta. Termin jakości już od starożytności był definiowany na wiele sposobów. Najbardziej znaną starożytną definicją jest zaproponowana przez Platona jako "pewien stopień doskonałości". Współcześnie możemy spotkać wiele pojęć jakości, które się wzajemnie uzupełniają. W słownikach języka polskiego można znaleźć następujące definicje jakości: "wartość czegoś" (Słownik języka polskiego PWN, 2006); "zespół cech decydujących o ocenie danego wyrobu" (Uniwersalny słownik języka polskiego, 2007). Obecna norma ISO definiuje jakość jako "stopień, w jakim zbiór inherentnych cech spełnia wymagania" (ISO 9000:2005). Współcześnie w biznesie jakość definiuje się głównie jako spełnienie lub przekroczenie oczekiwań, wymagań oraz potrzeb klienta (Governica, Jakość). 2. Jakość oprogramowania Jakość oprogramowania, podobnie jak jakość dowolnego produktu, to wieloaspektowe zagadnienie. Stworzenie oprogramowania wysokiej jakości wymaga spojrzenia na jakość z kilku perspektyw (ISO/IEC :2000) (rys. 1). Jakość procesu (ang. process quality) - obejmuje cechy związane z procesem wytwarzania oprogramowania. Jakość wewnętrzna (ang. internal quality; alt. jakość strukturalna: ang. structural quality) - obejmuje cechy oprogramowania, które są widoczne przez wykonawców, ale nie przez użytkownika. 5

6 Jakość zewnętrzną (ang. external quality; alt. jakość funkcjonalna: ang. functional quality) - obejmuje cechy związane z działającym oprogramowaniem. Jakość użytkowania (ang. quality in use) - obejmuje cechy określające stopień spełnienia potrzeb użytkownika. Rysunek 1. Model jakości w procesie wytwarzania oprogramowania Oprogramowanie Efekty stosowania oprogramowania Jakość procesu Jakość wewnętrzna Jakość zewnętrzna Jakość użytkowania Metryki procesowe Metryki wewnętrzne Metryki zewnętrzne Metryki jakości użytkownika Źródło: Sacha, 2010, s.306 Zgodnie z przedstawionym modelem jakość danej perspektywy wpływa na jakość pozostałych perspektyw znajdujących się na rysunku po jej prawej stronie. Wymagania dotyczące jakości oprogramowania zwykle uwzględniają kryteria oceny jego jakości wewnętrznej, zewnętrznej oraz użytkowania, aby zaspokoić potrzeby programistów, klientów oraz użytkowników końcowych. Z przedstawionego modelu wynika, że sama zgodność oprogramowania ze specyfikacją wymagań, która zawiera się w perspektywie zewnętrznej nie jest wystarczająca, aby oprogramowanie było wysokiej jakości. 3. Składowe jakości Norma ISO/IEC 25010:2011 wyróżnia oddzielnie charakterystyki jakości oprogramowania (wewnętrzna i zewnętrzna) oraz charakterystyki jakości użytkowej oprogramowania. Model jakości użytkowania składa się z pięciu charakterystyk, które odnoszą się do wyniku interakcji, gdy system jest używany w określonym kontekście użycia. 6

7 Skuteczność (ang. effectiveness) - dokładność i kompletność, z którym użytkownicy osiągają określone cele. Efektywność (ang. efficiency) - zasoby wydatkowane w relacji do dokładności i kompletności, z którym użytkownicy osiągają celów. Satysfakcja (ang. satisfaction) - stopień, w jakim potrzeby użytkownika są spełnione, gdy system jest używany w określonym kontekście użycia. Wolność od zagrożeń (ang. freedom from risk) - stopień, w jakim system ogranicza zagrożenia. Pokrycie kontekstu (ang. context coverage) - stopień, w jakim system może być skutecznie i efektywnie używany z wolnością od zagrożeń i satysfakcją w określonych kontekstach użycia. Aby móc uzyskać wysoką jakość użytkowania koniecznie jest poznanie potrzeb klienta, które mają zostać zaspokojone przez oprogramowanie. Model jakości oprogramowania składa się z ośmiu charakterystyk odnoszących się do właściwości statycznych (strukturalnych) oraz dynamicznych (funkcjonalnych) oprogramowania: Przydatność funkcjonalna (ang. functional suitability) - stopień, w jakim oprogramowanie oferuje funkcje, które spełniają określone wymagania, kiedy jest stosowany w określonych warunkach. Niezawodność (ang. reliability) - stopień, w jakim system wykonuje konkretne funkcje w określonych warunkach, w zadanym okresie czasu. Skalowalność (ang. performance efficiency) - wydajność w stosunku do ilości zasobów wykorzystywanych w określonych warunkach. Operacyjność (ang. operability) - stopień, w jakim system może być skutecznie i efektywnie używany z satysfakcją w określonym kontekście użycia. Zabezpieczenie (ang. security) - stopień, w jakim system chroni informacje i dane, tak aby osoby lub inne produkty lub systemy miały odpowiedni dla nich stopień dostępu i poziom autoryzacji. Kompatybilność (ang. compatibility) - stopień, w jakim system może wymieniać informacje z systemami oraz wykonywać wymagane funkcje w obrębie tego samego sprzętu lub środowiska oprogramowania. 7

8 Łatwość utrzymania (ang. maintainability) - stopień skuteczności i efektywności, z jaką system może być modyfikowany. Przenośność (ang. portability) - stopień skuteczności i efektywności, z jaką system może być przenoszony z jednego sprzętu, oprogramowania lub środowiska operacyjnego bądź użytkowania na inny. Zdaniem Consortium of IT Software Quality najważniejszymi charakterystykami oprogramowania wymaganymi do dostarczania wartości biznesowej są niezawodność, skalowalność, zabezpieczenie oraz łatwość utrzymania (CISQ TR ). Istotną cechą jakości oprogramowania jest relacja pomiędzy jakością wewnętrzną a zewnętrzną. Otóż w oprogramowaniu często istnieje możliwość takiej zmiany, która zwiększa jakość zewnętrzną jednocześnie pogarszając wewnętrzną. Jednak takie podejście jest bardzo ryzykowne i kosztowne, ponieważ powstaje tzw. dług technologiczny (ang. technical dept). Jakość wewnętrzna ma wpływ na jakość zewnętrzną i ostatecznie powoduje, że dalsze modyfikowanie oprogramowania jest coraz bardziej utrudnione (McConnell, 2004) (Fowler, Tradable Quality Hypothesis). Często charakterystyki mają obszary wspólne oraz są wzajemnie powiązane. Z tego powodu usprawnienia określonej charakterystyki mogą wpływać, zarówno negatywnie jak i pozytywnie, na pozostałe (McConnell, 2004). 8

9 ROZDZIAŁ II ZARZĄDZANIA JAKOŚCIĄ Norma ISO 9000:2005 definiuje zarządzanie jakością jako "skoordynowane działania dotyczące kierowania organizacją i jej nadzorowania w odniesieniu do jakości". Należy zaznaczyć, iż termin "organizacji" znajdujący się w normie dotyczy również projektów. Przyjęte założenie jest zgodne z definicją projektu zawartą w ramach metodyki PRINCE2 - "Projekt to organizacja czasowa powołana w celu dostarczenia jednego lub więcej produktów biznesowych według uzgodnionego Uzasadnienia Biznesowego". Obecna norma dzieli również zarządzanie jakością na cztery części: planowanie jakości (ang. quality planning), zapewnienie jakości (ang. quality planning), kontrola jakości (ang. quality control), doskonalenie jakości (ang. quality assurance). Podział ten jest zgodny z cyklem PDCA (Plan-Do-Check-Act, alt. koło Deminga) (Moen, Norman, Evolution of the PDCA cycle). W przypadku zarządzania projektami (również wytwarzania oprogramowania) zwykle nie wyróżnia się oddzielnie części doskonalenia jakości jako oddzielnego procesu (rys. 2). Wskazują one, że zarządzanie jakością powinno się skupiać na ciągłym doskonaleniu, w którym każda część powinna być zaangażowana w doskonalenie jakości. W szczególności podczas planowania jakości planuje się usprawnienia procesów (PMI, 2013) (OGC, 2009) (Sommerville, 2010). Rysunek 2. Typowa struktura procesów zarządzania jakością projektu Zarządzanie jakością Planowanie jakości Zapewnianie jakości Kontrola jakości Źródło: Opracowanie własne 9

10 1. Planowanie jakości Proces planowania jakości skupia się na ustaleniu celów jakościowych (m.in. wymagań) oraz określaniu procesów operacyjnych, technik i związanych z nimi zasobów niezbędnych do ich spełnienia (ISO 9000:2005). Powinno się również zaplanować, w jaki sposób projekt będzie wykazywał zgodność z celami jakościowymi. W ramach planowania jakości można wyróżnić takie czynności jak: określanie i uprawnianie procesów, dobór technik i narzędzi, ustalanie metryk, formułowanie standardów, tworzenie list kontrolnych, definiowanie przeglądów i aktualizowanie dokumentacji projektowej (PMI, 2013). Podczas planowania powinno się uwzględniać wszystkie perspektywy jakości związane z wytwarzaniem oprogramowania Usprawnianie procesów Bardzo wiele korzyści przynosi wykorzystywanie istniejących praktyk. Popularnymi uniwersalnymi praktykami, które znajdują również szerokie zastosowanie w projektach wytwarzania oprogramowania są: Total Quality Management (TQM) (Ishikawa, 1988) (Feigenbaum, 1991), Lean, Kaizen, 5S, Kanban (Gilpatrick, Furlong, 2006) (Poppendieck, 2003), P7 (ang. 7QC - Seven Basic Tools of Quality), poka-yoke, 7 ZP ang. (7M - Seven Management and Planning Tools), Quality Function Deployment (QFD) (Ishikawa, 1988) (Jayaswal, Patton, 2006). Ponadto istnieją jeszcze metodyki, które są charakterystyczne dla projektów wytwarzania oprogramowania. Obecnie największym uznaniem cieszą się metodyki oraz praktyki zwinne (ang. Agile) takie jak: programowanie ekstremalne (szerzej omówione w rozdziale 3), Scrum, Acceptance Test-Driven Development, Continuous Integration, Domain-Driven Design, SOLID, Timeboxing (Manifesto for Agile Software Development) (Fowler, The New Methodology) (Martin, 2006). Do doskonalenia można również stosować modele dojrzałości (ang. maturity models) jako narzędzie do oceny procesów. Najpopularniejszym modelem dojrzałości stosowanym przy wytwarzaniu oprogramowania jest Capability Maturity Model Integration (CMMI) (West, 2004). ISO/IEC jest standardem, który również definiuje model dojrzałości 10

11 SPICE (Software Process Improvement and Capability Determination), jednak obecnie cieszy się on mniejszą popularnością. Bardzo ważnym aspektem jest właściwa integracja procesów. Szczególnie pożądane jest, aby procesy występujące w projekcie wzajemnie się uzupełniały oraz jednocześnie, aby nie dochodziło pomiędzy nimi do konfliktów (Kerzner, 2004). W roku 2010 Forrester Research opublikowało raport opisujący siedem praktyk doskonalących jakość tworzonego oprogramowania (Visitacion, Gualtieri, 2010): zdefiniuj jakość do twoich potrzeb, rozgłaszaj proste metryki jakości, dostrajaj indywidualne/zespołowe cele, aby wprowadzały jakość, pozyskuj prawidłowe wymagania, testuj sprytniej, aby testować mniej, projektuj oprogramowanie, aby zmniejszyć ryzyko błędów, optymalizuj wykorzystanie narzędzi do testowania Pomiary i metryki jakości Pomiary, jako jeden z elementów monitowania, stanowią bardzo ważne narzędzie zarządzania. McConnell twierdzi nawet, że "negowanie korzyści z pomiarów to twierdzenie, że lepiej nie wiedzieć co się dzieje w projekcie" (McConnell, 2004). Dla każdego atrybutu projektu można znaleźć metrykę oraz metodę jej pomiaru (Glib, 2005). Znane jest twierdzenie: "Co zostaje zmierzone zostanie zrobione" (ang. What gets measured gets done), na podstawie którego rozwinęło się podejście zarządzania przez cele. Jednak pomiary mają również negatywne skutki, ponieważ koncentracja na tym co jest mierzone prowadzi często do pogorszenia jakości innych aspektów projektu. Nie oznacza to jednak, aby nie stosować metryk, ale żeby ich dobór był bardzo staranny i nieustannie optymalizowany (Deming, 2000) (Kua, An Appropriate Use of Metrics). W procesie doboru metryk bardzo dobrą opinią cieszy się wykorzystywanie metody GQM (Goal, Question, Metric). W projektach wytwarzania oprogramowania metryki jakości użytkowania i metryki zewnętrzne są bardziej przydatne niż metryki wewnętrzne i procesowe (Sacha, 2010) (rys. 1). 11

12 2. Zapewnianie jakości Według większości źródeł zapewnienie jakości (zwane również "nadzorem jakości") polega na audytowaniu jakości ustawionych procesów. Zapewnienie jakości jest ściśle związane z ciągłym doskonaleniem procesów i jest ukierunkowane na zapewnieniu zaufania, że wymagania dotyczące jakości będą spełnione (PMI, 2013) (OGC, 2009) (ISO 9000:2005) (Sommerville, 2010) (Cunningham & Cunningham, Quality Assurance). Zapewnienie jakości jest pojęciem wieloznacznym oraz posiadających wiele definicji. Z tego powodu jest ono obecnie bardzo różnie rozumiane w środowisku wytwarzania oprogramowania. W przemyśle oprogramowania bardzo często w ramach zapewniania jakości klasyfikuje się również weryfikację oraz zatwierdzanie (kontrolę jakości), ponieważ termin kontroli jakości nie jest popularny (Sommerville, 2010) (Cunningham & Cunningham, Quality Assurance Is Not Quality Control). Z tego powodu można wyróżnić różne implementacje roli odpowiedzialnej za zapewnianie jakości: niezależna od zespołu rola w organizacji, który służy audytowaniu procesów występujących w projekcie oraz ustanawiająca określone procedury i standardy, rola w zespole, która jest odpowiedzialna za jakość procesową, rola w zespole odpowiedzialna za testowanie oraz monitorowanie jakości oprogramowania. 3. Kontrola jakości Również termin kontrolowania jakości cechuje różnorodność interpretacji (Hamrol, Mantura, 2002). W literaturze polskiej termin anglojęzyczny quality control tłumaczy się na kontrolę jakości oraz sterowanie jakością. Korzystając z tych dwóch terminów można wyróżnić następujące definicje: sterowanie jakością - zbiór czynności ukierunkowany na spełnienie wymagań dotyczących jakości (ISO 9000:2005) (OGC, 2009), kontrola jakości - zbiór czynności weryfikujących i zatwierdzających wymagania dotyczące jakości (PMI, 2013) (Cunningham & Cunningham, Quality Control). Głównym zadaniem kontroli jakości jest wykrywanie wszelkich niezgodności, które występują w każdym etapie i każdym rodzaju prac. Defekty wykrywane w późniejszych etapach charakteryzują się większym kosztem ich usuwania. Ponadto z danych 12

13 empirycznych wynika, że usuwanie defektów jest najbardziej kosztowną i czasochłonną czynnością w projektach wytwarzania oprogramowania. Dlatego dobrą praktyką jest planowanie kontroli jakości na samym początku prac oraz jak najczęstsze weryfikowanie oraz zatwierdzanie (McConnell, 2004). Bardzo ważnym elementem zarządzania jakością jest analiza rezultatów powstałych w wyniku kontroli jakości (PMI, 2013) Weryfikacja i zatwierdzanie Jak wspominano w podrozdziale 2. termin kontroli jakości nie jest popularny w przemyśle oprogramowania w przeciwieństwie do weryfikacji (ang. verification) oraz zatwierdzenia (ang. validation), z których składa się kontrola jakości. Weryfikacja jest to proces sprawdzania czy oprogramowanie jest zgodne z wymaganiami. Zatwierdzanie służy sprawdzaniu czy oprogramowanie oraz wymagania spełniają potrzeby i oczekiwania klienta. Podstawowymi metodami weryfikacji oraz zatwierdzania są testowanie (ang. testing) oraz przeglądy (ang. reviews) (Sommerville, 2010). Rysunek 3. Weryfikacja oraz zatwierdzanie w modelu jakości oprogramowania Potrzeby użytkownika Zatwierdzanie Jakość użytkowania Specyfikacja (wymagania jakości zewnętrznej) Weryfikacja i zatwierdzanie Jakość zewnętrzna Wymagania jakości wewnętrznej Weryfikacja Jakość wewnętrzna Źródło: Opracowanie własne 13

14 3.2. Testowanie Testowanie jest metodą sprawdzania jakości oprogramowania poprzez jego próbne wykonanie. Głównym celem testowania jest wykrywanie defektów. W procesie testowania oprogramowania można wyróżnić cztery poziomy testów: testy jednostkowe (ang. unit testing) - testowanie indywidualnych jednostek oprogramowania, testy integracyjne (ang. integration testing) - testowanie pewnego zbioru współdziałających jednostek, testy systemowe (ang. system testing) - testowanie całości oprogramowania, testy akceptacyjne (ang. acceptance testing) - sprawdzanie zgodności z wymaganiami oraz oczekiwaniami klienta. Model V (rys. 4) przedstawia zależności pomiędzy poszczególnymi fazami wytwarzania oprogramowania a związanymi z nimi poziomami testowania. Praktyka wykazuje, iż bardzo dobre efekty daje opracowywanie testów już w momencie rozważania określonych aspektów oprogramowania, ponieważ sprzyja to ich lepszemu zrozumieniu oraz daje możliwość natychmiastowej weryfikacji (Sacha, 2010). Rysunek 4. Model V procesu testowania oprogramowania Specyfikacja wymagań opracowanie testów Testy akceptacyjne Specyfikacja systemu Testy systemowe Architektura systemu Testy integracyjne Implementacja Testy jednoskowe Źródło: Opracowanie własne Metody testowania najczęściej dzieli się na następujące kategorie: testy strukturalne (biało-skrzynkowe) - opracowywane na podstawie znajomości wewnętrznej struktury oprogramowania głównie w celu znalezienia błędów związanych z implementacją, 14

15 testy niestrukturalne (czarno-skrzynkowe) - opracowane bez analizy struktury oprogramowania m.in. w celu znalezienia niezgodności z wymaganiami jakościowymi, testy użytkownika (ang. user tests, live tests) - testowanie oprogramowania dokonywane przy pomocy użytkowników oprogramowania (testy alfa, beta, akceptacyjne użytkownika) (Black, 2009). Oprócz wymienionych rodzajów występuje jeszcze bardzo wiele typów testów, z których warto wymienić: funkcjonalne, wydajnościowe, dymne, regresyjne, eksploracyjne, bezpieczeństwa, użyteczności, kompatybilności, współbieżności. Skuteczne testowanie w dużej mierze zależy od odpowiedniego dobranego procesu testowania. Przykładowy cykl testowania może składać się z następujących faz: planowanie testów - opracowanie planu testowania na podstawie wymagań oraz projektu oprogramowania, projektowanie testów - konfigurowanie środowiska testowego i tworzenie testów, wykonanie testów - uruchamianie testów, zapis statusów testów, raportowanie wyników, retesty defektów - wykonywanie testów, które zakończyły się niepowodzeniem, po wprowadzeniu korekt, testowanie regresyjne - wykonanie testów, które były wykonane bezbłędnie przed rozpoczęciem usuwania defektów. Podczas testowania bardzo pomocne jest wykorzystywanie narzędzi, spośród których można wyróżnić narzędzia do zarządzania testami, wykonywania testów, wstrzykiwania błędów, testowania wydajności oraz symulatory, emulatory, a nawet języki skryptowe (Black, 2009). W procesie testowania oprogramowania bardzo istotną rolę pełnią testy automatyczne. Automatyzowanie testów jest najpraktyczniejszym sposobem na zwiększenie efektywności testów regresyjnych. Jedynie właściwe wykorzystanie testów automatycznych umożliwia utrzymanie stałego czasu testowania przy rosnącej funkcjonalności i złożoności oprogramowania (McConnell, 2004). Popularną w ostatnich czasach praktyką jest stosowanie testów automatycznych jako wykonywalną specyfikację oprogramowania, dzięki czemu unikamy problemów związanych z aktualizowaniem dokumentacji 15

16 projektowej (Adzic, 2011). Dzięki temu, że testy automatyczne mogą być uruchamiana w dowolnym momencie w celu sprawdzenia poprawności oprogramowania, są one jednym z najbardziej istotnych elementów ciągłej integracji, ponieważ zwiększają szanse na szybkie wykrycie błędów podczas wprowadzania zmian w oprogramowaniu (Fowler, Continuous Integration) Przeglądy Przeglądy są aktywnościami mającymi na celu ocenę jakości stanu prac (np. testowania) lub produktów wykonywanych (np. specyfikacji wymagań, projektu architektury, kodu programu) w procesie wytwarzania oprogramowania. W czasie przeglądu grupa ludzi sprawdza podmiot poddawany przeglądowi szukając potencjalnych problemów i niezgodności z przyjętymi standardami. Przykładowymi sposobami dokonywania przeglądów są: oględziny (nieformalne przeglądy), inspekcje (formalne przeglądy), audyty zewnętrzne, praca zespołowa (np. programowanie w parach) (Sacha, 2010) (McConnell, 2004). Wiele badań potwierdza, że inspekcje są znacznie tańsze niż testowanie. Pozwalają na szybsze wykrywanie defektów, dzięki czemu nie tylko koszt znalezienia, ale również ich usuwania jest znacznie niższy (McConnell, 2004). 16

17 ROZDZIAŁ III PROGRAMOWANIE EKSTREMALNE JAKO METODYKA SKONCENTROWANA NA JAKOŚCI Programowanie ekstremalne (ang. Extreme Programming, akr. XP) (Beck, Andres, 2004) jest metodyką zwinną autorstwa Kenta Becka powstałą w latach dziewięćdziesiątych podczas prac nad projektem Chrysler Comprehensive Compensation System (akr. C3). Metoda powstała w odpowiedzi na projekty, w których wymagania często ulegają zmianom oraz charakteryzują się wysokim ryzykiem. Głównym jej celem jest zwiększenie jakości wytwarzanego oprogramowania oraz szybkości reakcji na zmiany wymagań klienta. Programowanie ekstremalne jest metodyką adaptacyjną, która próbuje obniżyć koszty zmiany wymagań poprzez stosowanie tygodniowych iteracji, w których oprogramowanie jest rozwijane w sposób inkrementalny. Zmiany są elementem naturalnym, nieuniknionym, a nawet pożądanym i powinny być na bieżąco planowane, zamiast posiadania odgórnie zdefiniowanego, stabilnego zestawu wymagań. Programowanie ekstremalne jest oparte na wartościach, zasadach i praktykach doprowadzonych do ekstremalnych poziomów. 1. Wartości Fundamentem programowania ekstremalnego jest pięć wartości, które według jej autora są niezwykle istotne, aby projekt wytwarzania oprogramowania zakończył się sukcesem, czyli spełniał wymagania jakościowe klienta. Komunikacja (ang. communication) - większość problemów i błędów jest spowodowanych brakiem komunikacji. Jej najskuteczniejszą formą jest komunikacja bezpośrednia, interpersonalna. Artefakty projektowe muszą być aktualne oraz czytelne. Prostota (ang. simplicity) - "Zrób najprostszą rzecz, która może działać". Jednak tworzenie prostego oprogramowania wymaga doświadczenia, pomysłu i ciężkiej pracy. Prostota sprzyja komunikacji, zmniejsza złożoność oraz poprawia jakość. Dzięki prostocie implementacja nowej funkcjonalności jest prostsza. Ponadto jednym z założeń jest brak przedwczesnego planowania. 17

18 Informacje zwrotne (ang. feedback) - z powodu częstych zmian konieczne jest posiadanie efektywnych środków informujących o statusie projektu. Podstawowymi narzędziami zwrotnymi są bliski kontakt z klientem i dostępności zestawu zautomatyzowanych testów, które zostały opracowane razem z oprogramowaniem. Sprzężenie zwrotne jest ściśle związane z komunikacją. Należy się komunikować, aby uzyskać informacje zwrotne oraz należy posiadać wyniki informacji zwrotnej, aby kontynuować dalszą komunikację. Dzięki informacjom zwrotnym łatwiej jest otrzymać prostotę, która często jest uzyskiwana za pomocą metody prób i błędów. Ponadto, im prostszy system, tym łatwiej jest uzyskać informacje na jego temat. Odwaga (ang. courage) - wszystkie metodyki i procesy są narzędziami służącymi zmniejszaniu naszych obaw. Komunikacja, prostota i informacje zwrotne pozwalają na bezpieczne dokonywanie nawet dużych zmian wymagań i znacznej refaktoryzacji (zmiana wewnętrznej struktury oprogramowania, zwiększającą przejrzystość oprogramowania jednocześnie nie wpływając na jego obserwowalne zachowanie). Odwaga bez pozostałych wartości jest niebezpieczna. Jednak dzięki pozostałym wartościom jest potężnym narzędziem do dokonywania zmian. Szacunek (ang. respect) - członkowie zespołu muszą dbać o siebie i swoją pracę. Należy mieć szacunek do pracy, organizacji i osób, których dotyczy rozwijane oprogramowanie. Programowanie ekstremalne nie będzie funkcjonowało bez szacunku. 2. Zasady Wymienione wartości nie dają konkretnych porad na temat zarządzania projektem oraz tworzenia oprogramowania. W tym celu potrzebne są praktyki, które oparte są na ściśle określonych zasadach. Człowieczeństwo (ang. humanity) - czynniki ludzkie mają bardzo duży wypływ na rozwijane oprogramowanie i są głównym kluczem do dostarczania oprogramowania wysokiej jakości. Twórca metodyki zwraca szczególną uwagę, aby zadbać o poczucie bezpieczeństwa, możliwość realizacji i zaspokajać potrzebę przynależności, rozwoju oraz intymności. Ekonomia (ang. economics) - głównym celem oprogramowania jest przynoszenie korzyści biznesowych. Programowanie ekstremalne wyróżnia dwa aspekty ekonomiczne: wartość 18

19 pieniądza w czasie oraz wartość opcji systemów i zespołów. Pierwszy mówi, że im szybciej dostarczy się oprogramowanie, tym szybciej zacznie przynosić korzyści. Ponadto dzięki przyrostowemu wytwarzaniu oprogramowania koszty projektowe są odraczane do ostatniego możliwego momentu. Innym źródłem wartości ekonomicznej w rozwoju oprogramowania jest jego wartość jako opcje na przyszłość, uzyskanej dzięki łatwości wprowadzania zmian. Wzajemna korzyść (ang. mutual benefit) - każda działalność powinna dawać korzyść wszystkim powiązanym osobom i organizacjom. Zawsze istnieją łatwe rozwiązania, przez które jedni zyskują a inni tracą. Jednak ostatecznie są one czystą stratą, ponieważ zaburzają relacje i pogarszają środowisko pracy. Z tego powodu trzeba stosować praktyki, z których korzysta zarówno zespół jak i klient Samo-podobieństwo (ang. self-similarity) - natura nieustannie wykorzystuje struktury fraktalne, które są do siebie podobne w różnych skalach. Ta sama zasada sprawdza się podczas tworzenia oprogramowania. Wielokrotne wykorzystanie podobnych rozwiązań, w różnych kontekstach, porządkuje projekt. Doskonalenie (ang. improvement) - ciągłe doskonalenie jest kluczowym aspektem programowania ekstremalnego. Należy nie tylko codziennie starać się działać jak najlepiej, ale również trzeba myśleć o tym, co zrobić, aby lepiej pracować następnego dnia. Doskonalenie ma na celu eliminowanie długów technologicznych oraz procesowych. Różnorodność (ang. diversity) - zespoły, w których każdy jest podobny nie są skuteczne. Zespół powinien obejmować różne dziedziny wiedzy, umiejętności i osobowości, aby móc rozpoznawać i rozwiązywać problemy Posiadanie różnych opinii i propozycji wielu rozwiązań jest bardzo przydatne w rozwoju oprogramowania, pod warunkiem skutecznego zarządzania konfliktami oraz umiejętności wyboru właściwych decyzji. Refleksja (ang. reflection) - skuteczny zespół nie tylko wykonuje swoją pracę, ale również zastanawia się w jaki sposób działa i dlaczego. Istotna jest analiza sukcesów i porażek. Podczas każdej iteracji należy znaleźć czas na refleksje na temat stanu projektu i możliwych udoskonaleń. Przepływ (ang. flow) - programowanie ekstremalne jest ukierunkowane w kierunku ciągłego przepływu wartościowego oprogramowania, poprzez wykonywanie razem wszystkich aktywności rozwojowych, a nie posiadania dyskretnych faz. Ciągły przepływ 19

20 umożliwia informację zwrotną w celu zapewnienia, że system ewoluuje we właściwym kierunku oraz pozwala uniknąć problemów związanych z tzw. integracją wielkiego wybuchu (ang. Big Bang). Możliwości (ang. opportunity) - problemy należy postrzegać jako szansę na poprawę. Problemy występują zawsze. Dlatego nie należy ich jedynie rozwiązywać, ale także wykorzystać do nauki oraz doskonalenia. Redundancja (ang. redundancy) - krytyczne i trudne problemy powinny być rozwiązywane na kilka różnych sposobów. Jeśli jedno rozwiązanie zawiedzie, inne mogą zapobiec awarii. W takich przypadkach koszt redundancji szybko się spłaca. Defektów oprogramowania należy szukać, znajdywać i naprawiać na wiele sposobów. Jednak nie należy wprowadzać praktyk, które nie wnoszą żadnych dodatkowych korzyści. Niepowodzenie (ang. failure) - jeśli nie wiesz jak dokonać zmiany - spróbuj i najwyżej zawiedź. Porażki mogą być bardzo pouczające. Zawsze lepiej jest próbować niż zbyt długo opóźniać konieczne działanie. Lepiej jest wcześniej ponosić koszty związane z ryzykiem. Jakość (ang. quality) - jakość musi być zawsze maksymalna. Przyjmując niższą jakość nie przynosi się ani oszczędności, ani szybszego rozwoju. Z kolei ulepszanie ogólnej jakości często wiąże się z poprawą innych cech projektu takich jak produktywność i efektywność. Jakość nie jest jedynie czynnikiem ekonomicznym. Członkowie zespołu muszą być dumni ze swojej pracy, ponieważ poprawia to ich poczucie własnej wartości oraz skuteczność. Nie można mylić jakości z perfekcjonizmem. Opóźnianie działań przez dążenie do doskonałości, nie promuje jakości. Raczej należy próbować i osiągać porażki, aby następnie udoskonalać istniejące rozwiązania. Dziecięce kroki (ang. baby steps) - duże zmiany, przygotowane w długim okresie czasu, które są ewaluowane w jednym momencie, są niebezpieczne. Lepiej jest stosować możliwie krótkie iteracje, które dokonują weryfikacji przyjętego kierunku i rozwiązania. Akceptowana odpowiedzialność (ang. accepted responsibility) - odpowiedzialność musi być przyjęta, a nie przypisana. Najczęściej wydawanie poleceń jest nieskuteczne, ponieważ niszczy kreatywność. 20

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

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

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

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

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

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

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia 1. Cel szkolenia m szkolenia jest nauczenie uczestników stosowania standardu PRINCE2 do Zarządzania Projektami Informatycznymi. Metodyka PRINCE2 jest jednym z najbardziej znanych na świecie standardów

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

Podejście zwinne do zarządzania projektami

Podejście zwinne do zarządzania projektami Podejście zwinne do zarządzania projektami na przykładach projektów wytwarzania oprogramowania Wojciech Czujowski, Łukasz Sienkiewicz Tieto Poland Agenda CZĘŚĆ I-sza: Kilka słów o Tieto SCRUM w organizacji

Bardziej szczegółowo

Metodyki zwinne wytwarzania oprogramowania

Metodyki zwinne wytwarzania oprogramowania Metodyki zwinne wytwarzania oprogramowania Wykład 1 Marcin Młotkowski 7 października 2014 Plan wykładu Sprawy organizacyjne Organizacja pracowni 1 Sprawy organizacyjne Organizacja pracowni 2 3 Marcin Młotkowski

Bardziej szczegółowo

Zarządzanie projektami a zarządzanie ryzykiem

Zarządzanie projektami a zarządzanie ryzykiem Ewa Szczepańska Zarządzanie projektami a zarządzanie ryzykiem Warszawa, dnia 9 kwietnia 2013 r. Agenda Definicje Wytyczne dla zarządzania projektami Wytyczne dla zarządzania ryzykiem Miejsce ryzyka w zarządzaniu

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

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

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

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie Wykład 2 MIS-1-505-n Inżynieria Marzec 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 2.1 Agenda 1 2 3 4 5 6 2.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować

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

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

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

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja

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

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

DLA SEKTORA INFORMATYCZNEGO W POLSCE

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

Bardziej szczegółowo

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

Wsparcie narzędziowe zarządzania ryzykiem w projektach

Wsparcie narzędziowe zarządzania ryzykiem w projektach Wsparcie narzędziowe zarządzania ryzykiem w projektach Spotkanie 1 Zbigniew Misiak (BOC IT Consulting) Podyplomowe Studia Menedżerskie Zarządzanie projektami informatycznymi Czym się będziemy zajmować?

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

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Metodyki programowania Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Wybrane metodyki zwinne TRADYCYJNE: RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments)

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering) Wykład 1

Inżynieria oprogramowania (Software Engineering) Wykład 1 Inżynieria oprogramowania (Software Engineering) Wykład 1 Wprowadzenie do inżynierii oprogramowania Zarządzanie przedmiotem Wydział: WEiI Katedra: KIK Web site: http://moskit.weii.tu.koszalin.pl/~swalover/

Bardziej szczegół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

Planowanie i realizacja zadań w zespole Scrum

Planowanie i realizacja zadań w zespole Scrum MetaPack IT Academy Uniwersytet Zielonogórski Planowanie i realizacja zadań w zespole Scrum Paweł Przybyła Professional Scrum Master (www.scrum.org) Planowanie i realizacja zadań w zespole Scrum Agenda:

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

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

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

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

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

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa Budowa systemu wspomagającego podejmowanie decyzji Metodyka projektowo wdrożeniowa Agenda Systemy wspomagające decyzje Business Intelligence (BI) Rodzaje systemów BI Korzyści z wdrożeń BI Zagrożenia dla

Bardziej szczegółowo

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

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz

Bardziej szczegółowo

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Autor: Kinga Lewandowska Promotor: dr inż. Szymon Supernak Zakres pracy CZĘŚĆ TEORETYCZNA Przegląd

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

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

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl Dobre wdrożenia IT cz. I Business Case Wprowadzenie Czy wiesz: jak często po wdrożeniu oprogramowania okazuje się, że nie spełnia ono wielu wymagań? jak często decyzja o wdrożeniu systemu informatycznego

Bardziej szczegółowo

Leszno 14.03.2013. Jakie są i będą oczekiwania biznesu wobec IT?

Leszno 14.03.2013. Jakie są i będą oczekiwania biznesu wobec IT? Leszno 14.03.2013 Jakie są i będą oczekiwania biznesu wobec IT? Banki stoją w obliczu zmian Uwarunkowania ekonomiczne Regulacje prawne Trendy społeczne Nowe technologie Dzisiaj otoczenie oczekuje innego

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

Scaling Scrum with SAFe. Małgorzata Czerwińska

Scaling Scrum with SAFe. Małgorzata Czerwińska Scaling Scrum with SAFe Małgorzata Czerwińska Agenda 1. Wstęp 2. Współpraca zespołów scrumowych 3. Zarządzanie Programem 4. Podsumowanie Wstęp Skuteczność zespołów developerskich, realizujących projekty

Bardziej szczegółowo

Compuware Changepoint. Portfolio Management Tool

Compuware Changepoint. Portfolio Management Tool Compuware Changepoint Portfolio Management Tool Compuware Changepoint Zintegrowane Zarządzanie Portfelem IT W dzisiejszym świecie czołowi użytkownicy IT podejmują inicjatywy dopasowania IT do strategii

Bardziej szczegółowo

WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends

WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji dr inż. Bolesław Szomański Wydział Zarządzania Politechnika Warszawska b.szomański@wz.pw.edu.pl Plan Prezentacji

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

UPEDU: Testowanie (ang. Testing discipline)

UPEDU: Testowanie (ang. Testing discipline) Wydział Informatyki PB Wprowadzenie Inżynieria oprogramowania II Marek Krętowski e-mail: mkret@wi.pb.edu.pl http://aragorn.pb.bialystok.pl/~mkret Wykład 9: UPEDU: Testowanie (ang. Testing discipline) Dwa

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

Agile Project Management WHITEPAPER

Agile Project Management WHITEPAPER 1 Wstęp... 2 Historia... 2 DSDM ATERN... 3 Agile w zarządzaniu projektami... 4 Szkolenia i certyfikacja... 6 Certyfikaty Agile Project Management Foundation i Practitioner... 6 Szkolenie Agile Project

Bardziej szczegółowo

Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000

Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000 Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000 Normy ISO serii 9000 Zostały uznane za podstawę wyznaczania standardów zarządzania jakością Opublikowane po raz

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

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie Projektami zgodnie z PRINCE2 Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Foundation Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Foundation Terminy szkolenia 23-25 wrzesień 2015r., Warszawa - Akademia Szybkiej Nauki 7-9 październik 2015r., Warszawa

Bardziej szczegółowo

Cykle życia systemu informatycznego

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

Bardziej szczegółowo

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

Scrum. Zwinna metodyka prowadzenia projektów

Scrum. Zwinna metodyka prowadzenia projektów Scrum Zwinna metodyka prowadzenia projektów Plan prezentacji 1. Ogólna idea 2. Najważniejsze elementy 3. Role 4. Czynności 5. Artefakty 6. Wnioski 7. Literatura Źródło ilustracji: http://commons.wikimedia.org/wiki/file:scrum.jpg

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

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

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl Testowanie według modelu (MBT) Bogdan Bereza, Victo MBT testowanie z modelu wersja 2.1 A 1 (48) Pozdrawiam Best regards Med vänliga hälsningar Bogdan Bereza bogdan.bereza@victo.eu +48 519 152 106 Skype:

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

SKUTECZNE ZARZĄDZANIE PROJEKTAMI. Przeznaczenie zajęć, podstawowe cele i korzyści dla studentów:

SKUTECZNE ZARZĄDZANIE PROJEKTAMI. Przeznaczenie zajęć, podstawowe cele i korzyści dla studentów: SKUTECZNE ZARZĄDZANIE PROJEKTAMI Przeznaczenie zajęć, podstawowe cele i korzyści dla studentów: Celem cyklu wykładów i ćwiczeń jest opanowanie wiedzy i praktycznych umiejętności w zakresie zarządzania

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

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

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

Bardziej szczegółowo

Projekt. Prince2 PRoject. IN Controlled Environments PROCESY KOMPONENTY TECHNIKI

Projekt. Prince2 PRoject. IN Controlled Environments PROCESY KOMPONENTY TECHNIKI 4 Kilka słów o metodyce Prince2 Do czego słuŝy? 5 Kilka słów o metodyce Prince2 Skąd się wzięła? Prince2 PRoject IN Controlled Environments Metodyka zarządzania projektem, nie realizacji projektu!!! Projekty

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

Zarządzanie ryzykiem teoria i praktyka. Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r.

Zarządzanie ryzykiem teoria i praktyka. Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r. Zarządzanie ryzykiem teoria i praktyka Ewa Szczepańska Centrum Projektów Informatycznych Warszawa, dnia 31 stycznia 2012 r. Zarządzanie ryzykiem - agenda Zarządzanie ryzykiem - definicje Ryzyko - niepewne

Bardziej szczegółowo

PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ

PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ Wykład 4. PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ 1 1.Ogólna charakterystyka koncepcji zarządzania jakością i kierunki ich zmian w czasie: W historycznym podejściu do zarządzania jako- ścią można wyróżnić

Bardziej szczegółowo

Szkolenie 1. Zarządzanie projektami

Szkolenie 1. Zarządzanie projektami 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

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

Testowanie oprogramowania w środowisku IBM Rational Software Architect

Testowanie oprogramowania w środowisku IBM Rational Software Architect Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development 2008 Michał Wolski m.wolski@modesto.pl szkolenia: inżynierii oprogramowania zarządzania projektami usługi doradcze

Bardziej szczegółowo

CZYNNIKI SUKCESU PPG

CZYNNIKI SUKCESU PPG CZYNNIKI SUKCESU PPG STOSOWANIE UMIEJĘTNOŚCI ZAWODOWYCH Wiedza o biznesie Wiedza specjalistyczna Wiedza o produktach i usługach Wiedza przemysłowa ZARZĄDZANIE REALIZACJĄ ZADAŃ Działanie w perspektywie

Bardziej szczegółowo

Przypadki bez przypadków. Jak dobierać scenariusze testowe.

Przypadki bez przypadków. Jak dobierać scenariusze testowe. Przypadki bez przypadków. Jak dobierać scenariusze testowe. Konferencja SQAM 2008 Warszawa, 29. kwietnia Wojciech Pająk 29 kwietnia 2008 Warszawa Zagadnienia prezentacji 1. Wprowadzenie 2. Definicje przypadków

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 Jakość w projekcie informatycznym - normy

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy Wykład 5 (1) Jakość w projekcie informatycznym - normy ISO: Ogólne dot. jakości: ISO 8402 - terminologia ISO 9000 - wytyczne dotyczące wyboru modelu ISO 9001/3 - modele systemu jakości Dot. oprogramowania:

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

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r. Nie o narzędziach a o rezultatach czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT Władysławowo, 6 października 2011 r. Dlaczego taki temat? Ci którzy wykorzystują technologie informacyjne

Bardziej szczegółowo

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów

Bardziej szczegółowo

Proces projektowania i wdrożenia serwisu internetowego

Proces projektowania i wdrożenia serwisu internetowego Proces projektowania i wdrożenia serwisu internetowego Kluczowe etapy projektu 9 1 Rozwój i optymalizacja Analiza celów, potrzeb i konkurencji 8 Szkolenie IMPROVE THINK Wireframe i prototyp (UX) 2 7 Testy

Bardziej szczegółowo

Menedżerskie studia podyplomowe Zarządzanie firmą. Instrumentarium współczesnego menedżera

Menedżerskie studia podyplomowe Zarządzanie firmą. Instrumentarium współczesnego menedżera Menedżerskie studia podyplomowe Zarządzanie firmą. Instrumentarium współczesnego menedżera Zarządzanie projektami najlepsze światowe praktyki mgr Marcin Gałuszka Zajęcia 2 - Wrocław, 28.01.2012 AGENDA

Bardziej szczegółowo

KLIENCI KIENCI. Wprowadzenie normy ZADOWOLE NIE WYRÓB. Pomiary analiza i doskonalenie. Odpowiedzialnoś ć kierownictwa. Zarządzanie zasobami

KLIENCI KIENCI. Wprowadzenie normy ZADOWOLE NIE WYRÓB. Pomiary analiza i doskonalenie. Odpowiedzialnoś ć kierownictwa. Zarządzanie zasobami SYSTEM ZARZĄDZANIA JAKOŚCIĄ ISO Jakość samą w sobie trudno jest zdefiniować, tak naprawdę pod tym pojęciem kryje się wszystko to co ma związek z pewnymi cechami - wyrobu lub usługi - mającymi wpływ na

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

know 5 W, : filary wzrostu WHAT WHEN WHO WHY WHERE model biznesowy

know 5 W, : filary wzrostu WHAT WHEN WHO WHY WHERE model biznesowy nasza misja model biznesowy 5 W, : filary wzrostu know WHAT WHEN WHO WHY WHERE zwinne oprogramowanie, oparte o wybór właściwej technologii, outsourcing specjalistów odpowiednia strategia, wyprzedzanie

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

Ś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

OFERTA SZKOLEŃ BIZNESOWYCH

OFERTA SZKOLEŃ BIZNESOWYCH OFERTA SZKOLEŃ BIZNESOWYCH Przywództwo i zarządzanie zespołem Szkolenie z zakresu przywództwa, kompetencji liderskich i zarządzania zespołem. Podniesienie kompetencji zarządczych w zakresie przywództwa,

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

Programowanie zwinne - wprowadzenie. Programowanie ekstremalne. Wstęp Reguły i praktyki SCRUM. Wprowadzenie Role Zdarzenia Artefakty

Programowanie zwinne - wprowadzenie. Programowanie ekstremalne. Wstęp Reguły i praktyki SCRUM. Wprowadzenie Role Zdarzenia Artefakty Anna Kulig Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty Agile Manifesto 2001 rok, Snowbird w stanie Utah w USA Najważniejsi

Bardziej szczegółowo

Testowanie w procesie Scrum

Testowanie w procesie Scrum Tilo Linz Testowanie w procesie Scrum Przewodnik po zarządzaniu jakością oprogramowania w świecie programowania zwinnego Przekład: Jakub Niedźwiedź APN Promise, Warszawa 2014 v 1 Wprowadzenie........................................1

Bardziej szczegółowo

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

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

Bardziej szczegółowo

EMSE00_BR371A_PL.QXP 20.02.2007 14:12 Seite 1

EMSE00_BR371A_PL.QXP 20.02.2007 14:12 Seite 1 EMSE00_BR371A_PL.QXP 20.02.2007 14:12 Seite 1 Publikacja EMSE00-BR371A-PL-E Kwiecień 2006 Copyright 2006 Rockwell Automation, Inc. Wszelkie prawa zastrzeżone. Wydrukowano w USA. EMSE00_BR371A_PL.QXP 20.02.2007

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

MODEL KOMPETENCYJNY DYREKTORA

MODEL KOMPETENCYJNY DYREKTORA MODEL KOMPETENCYJNY DYREKTORA JAKO NARZĘDZIE WSPOMAGAJĄCE ZARZĄDZANIE PLACÓWKĄ ZARZĄDZANIE PO WROCŁAWSKU prof. UWr Kinga Lachowicz-Tabaczek Instytut Psychologii Uniwersytetu Wrocławskiego, HR Projekt Wrocław

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

Rozpoczęcie, inicjacja (ang. inception

Rozpoczęcie, inicjacja (ang. inception Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl

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

dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska

dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska , e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 [ISO 9000] Jakość jest określana jako ogół cech i właściwości wyrobu lub usługi wymaganych do zaspokojenia stwierdzonych lub przewidywanych

Bardziej szczegółowo