Bartosz Chrabski Karolina Zmitrowicz

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

Download "Bartosz Chrabski Karolina Zmitrowicz"

Transkrypt

1

2 Bartosz Chrabski Specjalista IT pracujący w grupie oprogramowania IBM Polska. Zajmuje się projektowaniem i wdrażaniem systemów zarządzania pracą zespołów programistów, testerów analityków oraz technincznym wsparciem sprzedaży rozwiązań z rodziny IBM Rational. Autor kilkunastu publikacji z obszaru inżynierii oprogramowania, zarządzania projektami oraz prelegent licznych konferencji międzynarodowych. Karolina Zmitrowicz W branży IT niemal 10 lat. Posiada doświadczenie w zakresie analizy biznesowej i inżynierii wymagań, zarządzania jakością i zarządzania projektami: pracowała dla wiodących organizacji finansowych w Republice Południowej Afryki, Holandii, Austrii, Słowacji, Włoszech i w Polsce. Podczas swojej kariery pełniła różne role, od testera, przez technical writera, po kierownika projektów R&D, co umożliwiło jej poznanie wielu aspektów realizacji projektów IT i nauczyło postrzegania podejmowanych tematów z różnych punktów widzenia. Praca w międzynarodowych, wielokulturowych zespołach projektowych wykształciła w Karolinie nie tylko umiejętności efektywnego planowania i koordynacji złożonych działań, ale i doskonałe umiejętności interpersonalne. W pracy analityka wykorzystuje doświadczenie zdobyte podczas kilku lat pracy w obszarze zapewnienia i kontroli jakości, by stale ulepszać jakość produktów swoich prac, jak i samego procesu ich powstawania. W latach Karolina zaangażowała się we wsparcie i doskonalenie systemu certyfikacji inżynierów wymagań REQB oraz była główną autorką programu IQBBA. Była także założycielką i redaktorem naczelnym magazynu c0re - kwartalnika dla testerów oprogramowania. Obecnie kontynuuje pracę redaktorską w Quale, kwartalniku traktującym o szeroko pojętej jakości w IT. W dalszym ciągu jest aktywnym członkiem kilku międzynarodowych organizacji mających na celu zwiększanie wiedzy i dojrzałości zawodowej testerów oprogramowania oraz inżynierów wymagań, wspiera również najważniejsze wydarzenia związane z jakością oprogramowania w Polsce i za granicą. Obecnie pracuje jako niezależny konsultant IT i trener w obszarze inżynierii wymagań i zarządzania jakością pomagając klientom usprawniać procesy inżynierii oprogramowania a tym samym osiągać lepsze wyniki biznesowe. Uważa, że podstawą do osiągnięcia jakości są efektywne procesy i odpowiednie podejście ludzi, a nie tymczasowe rozwiązania i modne trendy. Jest autorką szeregu specjalistycznych publikacji oraz książki obejmującej program certyfikacji w obszarze inżynierii wymagań, która wkrótce ukaże się nakładem wydawnictwa PWN.

3 SPIS TREŚ CI Od Autorów Wprowadzenie do inżynierii wymagań Wyzwania związane z projektami IT Cele i wizja Złe planowanie projektu Słaba komunikacja Złe zarządzanie oczekiwaniami interesariuszy Problemy z wymaganiami i ich zakresem Brak umiejętności miękkich Nierealistyczne oczekiwania Brak zasobów ludzkich Brak odpowiedniego wsparcia narzędziowego i metodycznego Podstawowe definicje oraz klasyfikacje Wymagania biznesowe Wymagania interesariuszy Wymagania rozwiązania Wymagania przejścia Atrybuty wymagań Kryteria jakości wymagań Wymagania w procesie zapewnienia jakości oprogramowania Inżynieria wymagań oraz jej znaczenie w projekcie Podstawowe role w procesie inżynierii wymagań Koncepcja interesariuszy Standardy oraz normy ISO ISO/IEC Software Engineering Software product Quality Requirements and Evaluation (SQuaRE) Guide to SQuaRE ISO ISO 31000: Risk Management v IEEE 610:1990: Standard Glossary of Software Engineering Terminology IEEE : Standard for Configuration Management in Systems and Software Engineering IEEE : Recommended Practice for Software Requirements Specifications IEEE : Guide for Developing of System Requirements Specifications IEEE : Guide for Information Technology System Definition Concept of Operations (ConOps) Document IEEE Systems and software engineering Life cycle processes Requirements engineering IEEE 1028:2008 Standard for Software Reviews and Audits

4 6 SPIS TREŚCI SWEBOK: The Guide to the Software Engineering Body of Knowledge (ISO Technical Report 19759) CMMI BABOK A Guide to the Business Analysis Body of Knowledge Słowniki Proces inżynierii wymagań Definicja procesu Inżynieria wymagań a analiza biznesowa Zasady tworzenia udanych wymagań Zrozum krytyczne cele najwyższego poziomu Koncentruj się na dostarczeniu wartości Zdefiniuj wymaganie jako stan końcowy o wartości dla interesariusza Wyrażaj wymagania ilościowo Nie mieszaj środków z celami Skup się na pożądanej jakości systemu, nie tylko na jego funkcjonalności Zapewnij bogatą specyfikację Wykonuj kontrolę jakości specyfikacji Uznaj, że wymagania się zmieniają Inżynieria wymagań a inne procesy Zarządzanie projektem Zarządzanie ryzykiem Testowanie i zapewnienie jakości Wpływ wymagań na inne artefakty projektu Inżynieria wymagań w procesach tworzenia oprogramowania Model V jako przykład kaskadowego wytwarzania systemów IBM Rational Unified Process Zarządzania wymaganiami w IBM Rational Unified Process Przepływ prac dla wymagań w IBM Rational Unified Process Role i artefakty w IBM Rational Unified Process Zwinne metodyki w zarządzaniu wymaganiami Programowanie ekstremalne Scrum (według Scrum.org) Rejestr produktowy, czyli metoda na zorganizowanie wymagań Wyzwania związane z migracją do Scrum Disciplined Agile Delivery Przypadek biznesowy Informacja o firmie i sytuacja rynkowa Potrzeba Rozwiązanie Zyski Identyfikacja wymagań Źródła wymagań Wizja oraz cel projektu Identyfikacja interesariuszy projektu Techniki identyfikacji wymagań Warsztat wymagań Wywiad

5 SPIS TREŚCI Ankieta kwestionariusz Samodzielna rejestracja Reprezentant klienta po stronie dostawcy Identyfikacja na podstawie istniejących dokumentów Ponowne użycie specyfikacji Obserwacja w terenie Mentorowanie/praktykowanie Burza mózgów Prototypowanie Przypadki użycia Scenorys Wymagania funkcjonalne i niefunkcjonalne Analiza wymagań Analiza problemu biznesowego Oganizacja wymagań Powiązania i zależności między wymaganiami Usuwanie konfliktów i duplikatów wymagań Kontrola jakości Szacowanie wysiłku Techniki bazujące na algorytmach Techniki bazujące na przybliżeniach Priorytetyzacja wymagań Modelowanie rozwiązania Model dziedziny Diagram przepływu danych (ang. Data Flow Diagram) Diagram związków encji (ang. Entity Relationship Diagram) Modelowanie interfejsu użytkownika Unified Modeling Language (UML) System Modeling Lanuage (SysML) Inne notacje do modelowania Akceptacja wymagań Specyfikacja wymagań Pojęcie specyfikacji Rodzaje specyfikacji Specyfikacja wymagań Specyfikacja rozwiązania Specyfikacja techniczna Szablony dla specyfikacji wymagań (na podstawie IEEE 830) IEEE Wzorzec Volere Historyjki użytkownika Przypadki użycia jako sposób na wymagania funkcjonalne Jakość specyfikacji wymagań Rozdział 8. Zarządzanie wymaganiami Śledzenie wymagań Zarządzanie Konfiguracją Zarządzanie Zmianą Zarządzanie wymaganiami dotyczącymi projektu oraz systemu Plan Zarządzania Wymaganiami

6 8 SPIS TREŚCI 8.6. Przypadek biznesowy wdrożenie procesu zarządzania wymaganiami Informacja o firmie i sytuacja rynkowa Potrzeba Rozwiązanie Zyski Wymagania a zarządzanie jakością Planowanie jakości Kontrola jakości Przeglądy Inspekcje Listy kontrolne Miary jakości wymagań Doskonalenie procesu Narzędzia wspierające proces inżynierii wymagań Narzędzia w zarządzaniu wymaganiami IBM Rational Requirements Composer Borland Caliber RM Serene Dimensions Rational DOORS (Dynamic Object Oriented Requirements System) Blueprint Requirements Center Open Source Requirements Management Tool/aNimble Platform Cechy dobrego narzędzia do zarządzania wymaganiami Wdrożenie narzędzia do zarządzania wymaganiami Czynniki mające znaczenie przy doborze odpowiednich narzędzi Narzędzia w obszarze modelowaniu wymagań Sparx Enterprise Architect IBM Rational Software Architect StarUML Narzędzia w obszarze modelowania procesów biznesowych Boc Group Adonis igrafx Process BizAgi Process Modeler Rational System Architect Narzędzia wsparcia dla zarządzania konfiguracją GIT Subversion IBM ClearCase Narzędzia wsparcia dla zarządzania zmianami Atlassian Jira IBM Rational Team Concert Zarządzanie procesem testowania oprogramowania HP Quality Center IBM Rational Quality Manager Testia Tarantula Requirements Testing Hub TestLink Ryzyko związane ze złym zakupem narzędzia Podsumowanie

7 SPIS TREŚCI 9 Przypadki biznesowe Projekt 1 - Wdrażanie procesu inżynierii wymagań Informacja o firmie i sytuacja rynkowa Potrzeba Rozwiązanie Zyski Projekt 2 Integracja narzędzi w procesie wytwarzania Informacja o firmie i sytuacja rynkowa Potrzeba Rozwiązanie Etap 1 Integracja wymagań z procesem zarządzania testami Etap 2 Integracja wymagań z zarządzaniem konfiguracją Etap 3 Integracja wymagań z zarządzaniem zmianami Zyski Projekt 3 Kontrola jakości wymagań na wczesnych etapach projektu Informacja o firmie i sytuacja rynkowa Potrzeba Skutek Przyczyna Rozwiązanie Projekt 4 Zarządzanie wymaganiami przy użyciu historyjek użytkownika Informacja o firmie i sytuacja rynkowa Potrzeba Rozwiązanie Zyski Bibliografia Spis rysunków Spis tabel Indeks

8 W rozdziale wprowadzającym przedstawimy podstawowe informacje dotyczące wymagań i różnych związanych z nimi aspektów. Oprócz zestawu pojęć i zagadnienień teoretycznych niezbędnych do zrozumienia istoty dziedziny inżynierii wymagań, opiszemy również tematy poboczne, umożliwiające zrozumienie znaczenia tej dziedziny dla sukcesu przedsięwzięcia. Zacznijmy od problemów, których przynajmniej częściowe rozwiązanie zależy od jakości procesów mniej lub bardziej związanych z wymaganiami Wyzwania związane z projektami IT Problemy w realizacji projektów informatycznych są nieustannie wdzięcznym tematem do dyskusji omawia się je na konferencjach, szkoleniach, w prasie i innych publikacjach. Szczególnie medialne i interesujące są spektakularne porażki, odbijające się szerokim echem w środowisku IT. Ilu z nas, najczęściej po fakcie, zadaje sobie pytanie, dlaczego projekty informatyczne tak często się nie udają? Ilu z nas deklaruje, że następnym razem będzie lepiej... a następny raz okazuje się jeszcze gorszy... W zasadzie wiadomo, co robimy nie tak. Badaniem przyczyn porażek projektowych zajmują się organizacje uznane na całym świecie (m.in. Standish Group i jej słynny już Chaos Report). Informują one, że głównymi powodami problemów są m.in. niekompletne wymagania, niedostateczne zaangażowanie użytkowników, brak zasobów i wsparcia kierownictwa, nierealistyczne oczekiwania, niedoszacowane estymacje oraz problemy z planowaniem. Czynniki te nie zmieniają się praktycznie od lat. Badania innych organizacji (w tym Gartnera) również wskazują część z tych czynników jako wywierające największy negatywny wpływ na powodzenie projektów IT 1. Analizując statystyki i dostępną dokumentację, można wyciągnąć wniosek, że większość problemów występujących podczas realizacji projektów IT jest związana z samym zarządzaniem projektem. Czynniki technologiczne obciążone, zdawałoby się, najwyższym ryzykiem to zaledwie niewielki odsetek przyczyn niepowodzeń projektów. Skąd taka rozbieżność? Dziedzina zarządzania projektem istnieje w IT od wielu lat nie jest ani nowa, ani nieusystematyzowana. Istnieje wiele wytycznych, praktyk i standardów opisujących reguły dobrego zarządzania projektem. Dlaczego więc od lat tak wiele problemów występujących podczas realizacji projektów IT wynika z faktu zarządzania nimi? Czyżby odpowiedź brzmiała: ponieważ nie uczymy się na błędach? Może przyczyny problemów są wciąż te same, ponieważ nigdy poważnie ich nie zbadaliśmy. Często widzimy tylko skutki i w panice próbujemy gasić pożar, kiedy już wybuchnie, nie zastanawiając się, dlaczego pożary występują tak często i co je powoduje. Może lepiej nie budować kolejnego domu ze słomy i papieru, zamiast dziwić się, że znowu nie wytrzymał najmniejszej próby ognia? Podsumowując informacje z różnych źródeł i statystyk, można wskazać kilkanaście notorycznie powtarzających się czynników ryzyka. 1

9 16 WPROWADZENIE DO INŻYNIERII WYMAGAŃ Cele i wizja Projektów nie realizujemy po to, żeby wyprodukować dany produkt. Z biznesowego punktu widzenia wyprodukowanie produktu nie jest celem samym w sobie realizacji projektu, projekty mają dostarczyć klientowi konkretną wartość. Produkt jest jedynie środkiem do osiągnięcia celu, jakim jest wartość. Niestety w praktyce znaczna liczba projektów charakteryzuje się kompletnym brakiem przygotowania biznesowego projekty inicjowane są bez uprzedniego zdefiniowania i analizy potrzeb, celów biznesowych oraz ryzyk. W wielu przypadkach brakuje planowania strategicznego, które pozwoliłoby organizacji określić cele i zaplanować ich realizację dzięki odpowiednim, często współzależnym projektom. Skutek? Klient nie wie, co chce osiągnąć za pomocą danego rozwiązania i jakim celom biznesowym ma ono służyć. Bardzo często projekty są realizowane po to, by wytworzyć jakiś system, choć celem projektu informatycznego nie jest sam system, ale korzyści, jakie ma dostarczać, i cele biznesowe, które ma realizować. Te cele i korzyści powinny stanowić podstawę do zainicjowania projektu, ponieważ to właśnie one determinują przyczynę, dla której klient podejmuje się wytworzenia produktu informatycznego. Klient zamawia system po to, by zrealizować konkretne cele biznesowe optymalizację jakiegoś procesu biznesowego, zwiększenie sprzedaży, czy redukcję pracowników administracyjnych. Te cele niestety bardzo często nie zostają zdefiniowane. Zarówno klient, jak i dostawca, skupia się zatem na funkcjach i usługach produktu, nie zastanawiając się, czemu mają one służyć. W efekcie klient dostaje produkt o określonych funkcjach, dostawca otrzymuje wynagrodzenie za swe usługi, ale produkt nie realizuje żadnych istotnych celów biznesowych lub realizuje je w stopniu dla klienta niewystarczającym. Czy taki projekt dostarczony w czasie, z funkcjami, jakie zostały zamówione, jedynie nie realizujący celów biznesowych można określić jako udany? Jednym z podstawowych problemów z projektami IT jest brak zrozumienia rzeczywistych potrzeb biznesowych organizacji zamawiającego. Podstawowe pytanie, jakie powinniśmy sobie zadać przy organizacji jakiegokolwiek projektu, brzmi: co chcemy osiągnąć, nie jaki produkt wytworzyć. Produkt, nawet zgodny z udokumentowanymi wymaganiami, niekoniecznie spełni potrzeby klienta. Wspomniane wyżej co chcemy osiągnąć wyjaśnia, dlaczego będziemy realizować dany projekt. To dlaczego jest wizją projektu, którą powinniśmy udokumentować w postaci określonego dokumentu (niektóre metodyki nazywają go po prostu dokumentem wizji), aby służył jako wysokopoziomowa deklaracja celu projektu. Nie wystarczy posiadać dokument wizji i listę celów biznesowych. Dokumenty te powinny być używane podczas realizacji projektu i służyć jako wskazówki przy podejmowaniu dalszych decyzji, chociażby tych związanych z zakresem projektu prace niesłużące spełnieniu wizji i celów projektowych można potencjalnie uważać za zbędne, jako że nie dostarczają żadnej wartości. Dobrą praktyką realizacji projektów jest dopasowanie celów projektu do ogólnych celów biznesowych i strategii organizacji Złe planowanie projektu Kolejnym grzechem jest całkowite zaniechanie planowania. Niektóre, najczęściej niedojrzałe organizacje w usilnym dążeniu do jak najszybszego wytworzenia pro-

10 1.1. Wyzwania związane z projektami IT 17 duktu (bo przecież rynek czeka...) zapominają, że podstawą realizacji jakiegokolwiek projektu jest planowanie. Jeśli nie opracowano planu, nie można go później realizować (co ukierunkowuje prace) ani monitorować. Oznacza to brak możliwości wykrycia potencjalnych problemów czy ryzyk na wczesnym etapie i odpowiedniego zareagowania, zanim problemy skumulują się do tego stopnia, że jedyną możliwą reakcją będzie już tylko gaszenie pożaru. Następny błąd popełniany jest na tyle często, że powinien zdobyć miejsce na podium w konkursie na klasyczny błąd planowania. Niedoszacowanie złożoności zakładamy, że prace związane z realizacją produktu albo i sam produkt są prostsze, niż okazuje się w rzeczywistości. Skąd to wynika? Zasadniczo można wyróżnić trzy przyczyny: Brak wiedzy na temat realnej złożoności problemu. W przypadku projektów czy produktów innowacyjnych lub takich, w których obszarze zespół projektowy nie ma doświadczenia, nie zawsze wiadomo, jak szacować złożoność. Przyjmuje się pewne założenia, bardzo często niedoszacowując. Kłania się stara zasada szacowania projektów: wynik szacowania należy pomnożyć przez 2 i dodać 50% buforu na możliwe problemy. Niestety, w obecnych warunkach rynkowych zasada ta jest często niemożliwa do zastosowania, ponieważ skutecznie zmniejszyłaby szanse producenta na realizację danego projektu. Brak konsultacji ze specjalistami. Niektórzy kierownicy projektu zbyt mocno wierzą we własne siły i próbują szacować projekt samodzielnie, bez konsultacji z zespołem projektowym czy ekspertami dziedzinowymi. Skutki są łatwe do przewidzenia. Problem ten może wynikać z błędnego postrzegania kierownika projektu jako jedynej osoby odpowiedzialnej za jego planowanie i szacowanie, choć zgodnie ze sztuką jest to zadaniem zespołu gdyż któż lepiej zaplanuje i wyceni np. testowanie w projekcie niż osoba odpowiedzialna za planowanie i realizację testów, czyli lider testów? Świadome niedoszacowanie w celu obniżenia łącznego kosztu projektu. Praktyka ta jest spotykana dość często, zwłaszcza w sektorze administracji publicznej, gdzie kryterium wygrania przetargu na projekt jest cena. Cóż więc ma zrobić producent, któremu zależy na wygranej? Obniżyć koszty, najczęściej przyjmując założenia, że pewne elementy da się zrobić szybciej i łatwiej, niż wskazują na to wyliczenia. O efektach takich założeń możemy często poczytać w prasie. Kolejnym bardzo poważnym błędem popełnianym podczas planowania projektu jest brak zarządzania oczekiwaniami klientów czy ogólnie interesariuszy. W praktyce przejawia się on brakiem zaplanowanych spotkań z interesariuszami, na których można omówić i zweryfikować wyniki już wykonanych prac, czyli upewnić się, czy podążamy w dobrym kierunku. Brak zaplanowania zaangażowania klienta i innych istotnych interesariuszy może skutkować problemami z wymaganiami, które okazują się być niekompletne czy nieprawidłowe (nie odzwierciedlają realnych potrzeb klientów), ponieważ zabrakło walidacji i komunikacji na bieżąco. Jeśli już mowa o komunikacji ten aspekt planowania również przysparza wielu kłopotów. Praktyka wskazuje, że w wielu projektach zaniedbuje się opracowanie planu komunikacji definiującego podstawowe zasady dzielenia się informacją w projekcie oraz określającego role i odpowiedzialności poszczególnych członków

11 18 WPROWADZENIE DO INŻYNIERII WYMAGAŃ zespołu. Brak planu komunikacji i określenia odpowiedzialności skutkuje najczęściej chaosem informacyjnym i problemami w realizacji podstawowych zadań. Rozważmy prosty przykład co zrobi tester, jeśli nie wie, komu zgłosić błąd zauważony w specyfikacji wymagań podczas przygotowywania przypadków testowych? 1. Poinformuje kierownika projektu, od którego dobrej woli i kompetencji będzie zależało przekazanie problemu do rozwiązania odpowiednim osobom. 2. Skonsultuje się z kolegą i wspólnie ustalą własną interpretację wymagań. 3. Zignoruje problem, na przykład wychodząc z założenia, że zgłoszenie błędu w wymaganiu i jego konsekwencje będą go kosztować dodatkową pracę. Złe zaplanowanie projektu często skutkuje nadmiernym, stałym lub czasowym, obciążeniem niektórych jego wykonawców, podczas gdy inne osoby (czy zespoły) są w tym samym czasie niemalże wolne. Przykładowo, projekty są często dzielone na etapy. Na etapie analizy i dokumentacji wymagań obciążeni są głównie analitycy (a nawet przeciążeni, ponieważ zwykle na analizę zakłada się zbyt mało czasu w stosunku do realnych potrzeb). W tym czasie testerzy i programiści są bezczynni albo pracują przy innym projekcie. Opcja druga z pozoru wydaje się całkiem rozsądna, jednakże w wyniku jej zastosowania po zakończeniu prac analitycznych testerzy i programiści rozpoczynają pracę nad projektem bez przygotowania i znajomości kontekstu. Powstają opóźnienia spowodowane faktem, że muszą się oni zapoznać z założeniami projektu i specyfikacjami produktu, zrozumieć, co mają do zrobienia, po czym dopiero zacząć pracę. Jak więc rozwiązać ten problem? Bardzo prosto programiści i testerzy są częścią zespołu projektowego, czyż nie? Celem zespołu jest dostarczenie produktu odpowiedniej jakości przy określonych założeniach (choćby czasowych). Członkowie zespołu powinni więc angażować się nie tylko w swoje zadania, jak na przykład samo kodowanie, lecz także wnosić wkład do czynności powiązanych z zadaniami, które będą realizować. Bardzo dobrym sposobem wykorzystania potencjału programistów i testerów jest zaangażowanie ich do przeglądów wymagań i specyfikacji produktu. Testerzy znakomicie zweryfikują, czy wymagania i projekty będą testowalne; programiści sprawdzą możliwości implementacji i doradzą optymalne sposoby spełnienia wymagań przy zastosowaniu dostępnych możliwości technicznych. Warto również dodać, że wiele problemów związanych z planowaniem wynika z przyczyn pośrednich. Przykładowo, źle wdrożony proces inżynierii wymagań może skutkować zaniedbaniem ustalenia priorytetów wymagań, co w konsekwencji może sprawić, że zespół skoncentruje się na wymaganiach mało istotnych, zamiast w pierwszej kolejności zająć się tymi najważniejszymi, które wprowadzają największe ryzyko projektowe. Innym błędem często spotykanym w obszarze inżynierii wymagań jest pomijanie pewnych czynności. Czasami producent pomija analizę biznesową wymagań i przechodzi od razu do projektowania rozwiązania. Przyczyn takiego stanu jest wiele najczęściej presja czasu (wynikająca zazwyczaj z niedoszacowania projektu) oraz nieświadomość faktu, że analiza biznesowa jest koniecznym etapem wytwarzania rozwiązań informatycznych. Bez pełnej analizy biznesowej pojawia się ryzyko zmian projektu systemu w późniejszych etapach projektu (np. podczas implementacji i testów) zostaną wykryte błędy, luki, brakujące funkcje czy ograniczenia, które zostałyby przewidziane na etapie analizy biznesowej.

12 1.1. Wyzwania związane z projektami IT 19 Kwestia zarządzania zmianami jest innym dowodem na to, że na problemy w planowaniu mogą się składać czynniki pośrednie. Wszelkie modyfikacje wnoszone do zakresu lub treści projektu powinny być obsługiwane za pomocą procesu zarządzania zmianami, którego częścią jest analiza wpływu. Bez niej nie jesteśmy w stanie określić ryzyka implementacji danej zmiany i przewidzieć wpływu, jaki wywrze ona na różne elementy produktu oraz na sam projekt nie wiemy na przykład, czy wdrożenie zmiany nie zepsuje dotychczas stabilnego produktu, co wpłynie na przebieg realizacji projektu, generując opóźnienia. Z tego powodu ważnym elementem planowania projektu jest nie tylko ustalenie etapów, obciążenia zasobów itp., ale również przewidywanie przebiegu samych procesów składających się na wytworzenie projektu produktu (np. analiza wymagań, implementacja, testowanie) oraz procesów pomocniczych, jak wspomniane już zarządzanie zmianą czy równie istotne zarządzanie konfiguracją Słaba komunikacja Projekty informatyczne są realizowane przez ludzi, a sukces przedsięwzięcia w dużym stopniu zależy od ich umiejętności współpracy. Czynnikami niezbędnymi do osiągnięcia sukcesu są świadomość i zrozumienie celów, zadań, odpowiedzialności, oczekiwań, problemów, ryzyk. Za uzyskanie i utrzymanie tej świadomości odpowiada komunikacja. Komunikacja to nie tylko dyskusje to również wszelkiego typu dokumenty, procedury, raporty i inne elementy umożliwiające dzielenie się informacją. Aby skutecznie zaplanować projekt i dalej go realizować, niezbędny jest częsty kontakt ze sponsorami i użytkownikami biznesowymi oraz końcowymi, gdyż tylko w taki sposób możemy poznać ich oczekiwania i potrzeby, jak również na bieżąco sprawdzać, czy wyniki realizowanych prac dążą do ich spełnienia. Raporty statusu i spotkania zarządcze nie są zbędną biurokracją, ale środkiem umożliwiającym monitorowanie postępów projektu i szybką reakcję na potencjalne problemy. Bez nich nie byłoby wiadomo, czy projekt podąża w dobrym kierunku i czy wszystko przebiega zgodnie z planem nie jesteśmy w stanie bowiem rozwiązać problemu, nie mając świadomości jego istnienia. Kolejny ważny element komunikacji to spotkania. Dojrzałe zespoły i organizacje nie organizują spotkań dla zasady, lecz w celu wymiany informacji i wyjaśnienia wszystkim członkom spotkania stanu spraw, problemów, szans, statusu prac oraz dalszych czynności. Zebrania dają możliwość nie tylko zrozumienia celu i przebiegu projektu, ale i szansę wyjaśnienia na bieżąco wszelkich wątpliwości czy zareagowania na problemy. Spotkania są ważne, istotna jest jednak również umiejętność ich organizowania. Dość powszechna niechęć do uczestnictwa we wszelkiego rodzaju spotkaniach często wynika z faktu ich fatalnej organizacji i realizacji braku planu, moderacji, podsumowania co skutkuje poczuciem straconego czasu. Organizację spotkania należy zacząć od opracowania i przekazania uczestnikom agendy, która wyszczególnia kwestie podejmowane na spotkaniu, pozwala też kontrolować przebieg i zakres dyskusji. Samo spotkanie powinno być moderowane, aby uniknąć schodzenia z zaplanowanych wątków i zapewnić dyscyplinę dyskusji. W trakcie spotkania wyznaczona osoba (sekretarz) powinna notować główne

13 20 WPROWADZENIE DO INŻYNIERII WYMAGAŃ decyzje, ustalenia, elementy dyskusji, które posłużą do opracowania notatki ze spotkania. Notatka ta powinna podsumowywać przebieg spotkania, decyzje (co ustalono), kwestie otwarte (czego nie ustalono), dalsze kroki i podział odpowiedzialności. Notatkę należy przesłać uczestnikom spotkania do akceptacji, a po jej uzyskaniu przekazać szerszemu gronu odbiorców. Ważnym elementem komunikacji, w tym także spotkań, są prezentacje i demonstracje wymagań, rozwiązań, produktu lub jego części. Ta forma komunikacji nie tylko znakomicie ułatwia przekazywanie wiedzy, lecz także ponieważ wykorzystujemy wizualizacje, które są łatwiejsze do przyswojenia niż tekst, umożliwia uzyskanie cennej informacji zwrotnej na temat prezentowanych obiektów. W celu przedstawienia alternatywnych sposobów implementacji ich wymagań i wyboru optymalnej opcji można prezentować interesariuszom koncepcje rozwiązań czy prototyp produktu. Przedmiotem prezentacji mogą być same wymagania, co umożliwia ich walidację i zaakceptowanie przez wybraną grupę interesariuszy, a tym samym obniża ryzyko niepowodzenia projektu spowodowanego wytworzeniem produktu na podstawie błędnie udokumentowanych lub niezrozumianych wymagań. Jak widać, opcji skutecznej komunikacji jest wiele wystarczy jedynie je poznać i wdrożyć jako stały element każdego przedsięwzięcia informatycznego Złe zarządzanie oczekiwaniami interesariuszy Bardzo ważnym czynnikiem powodzenia projektu jest zbudowanie wzajemnego zaufania i porozumienia między interesariuszami odnośnie do celów i pożądanych wyników przedsięwzięcia. Jest to szczególnie istotne w przypadku, gdy interesariusze pochodzący z różnych organizacji mają sprzeczne oczekiwania i interesy co, jak wiadomo, ma miejsce w większości projektów komercyjnych, mających na celu wytworzenie produktu przez dostawcę na życzenie zewnętrznego klienta. Aby osiągnąć sukces i wytworzyć produkt spełniający oczekiwania interesariuszy, należy po pierwsze znać ich oraz ich potrzeby. Po drugie, należy zbudować świadomość dążenia do wspólnego celu, niezależnie od organizacji, z której pochodzi dany interesariusz. Pierwszy warunek, mimo że pozornie oczywisty i prosty, w praktyce może nastręczać sporych problemów. Identyfikacja interesariuszy i ich potrzeb zasadniczy warunek początkowy dla czynności określania wymagań w wielu projektach jest wykonywana nieprawidłowo. Ze względu na presję czasu, brak świadomości, a czasem zwyczajną ignorancję, zaniedbuje się pełną identyfikację interesariuszy, ograniczając się jedynie do tych znanych i najbardziej oczywistych jak sponsor, kierownik projektu, biznes itp. Skutkiem takiej beztroski są często luki w analizie, gdyż każdy pominięty interesariusz oznacza ryzyko pominiętego wymagania czy ograniczenia, które może w zasadniczy sposób wpłynąć na koncepcję produktu lub samego projektu (chociażby kwestia wymaganej dokumentacji projektowej, która może być różnie postrzegana przez różnych interesariuszy).

14 1.1. Wyzwania związane z projektami IT 21 Kolejnym problemem jest samo zarządzanie oczekiwaniami interesariuszy. Wspomniano już, że różne grupy interesariuszy mają różne wymagania i potrzeby. Klasycznym przykładem jest różnica interesów na linii biznes użytkownicy końcowi. Biznes żąda spełnienia wszelkich procedur i wymagań wynikających z dziedziny biznesowej (często kosztem użyteczności produktu), natomiast użytkownicy z reguły pragną najprostszego rozwiązania. Nierozwiązane konflikty interesów między interesariuszami mogą sprawić, że gotowy produkt nie będzie spełniać oczekiwań określonej grupy czy grup odbiorców. W sytuacjach ekstremalnych producent może wytworzyć produkt kompletnie nieprzydatny użytkownikom końcowym lub niezgodny z wymaganiami biznesu Problemy z wymaganiami i ich zakresem Wymagania tworzą podstawy dla organizacji i planowania projektu IT oraz opracowania produktu; stanowią one jeden z najważniejszych czynników sukcesu lub porażki projektu. Słabe wymagania mają niejednoznaczny zakres, co przekłada się na słaby projekt produktu, w efekcie na słaby produkt. Wyzwania związane z wymaganiami nieprecyzyjnymi, niemierzalnymi, niepełnymi czy niemożliwymi do implementacji w danych warunkach biznesowych i technologicznych to już klasyczny problem podczas realizacji większości projektów IT. Najbardziej typowym błędem jest brak precyzji i niemierzalność wymagań. Pojawia się on zazwyczaj już na samym początku projektu. Ileż to razy doświadczalnie przekonaliśmy się, że klient nie umie sformułować swoich potrzeb? Jak często wymagania opisane są stwierdzeniami: system powinien być użyteczny, system ma umożliwiać zarządzanie raportami itp.? Klientowi (zamawiającemu) często brakuje kompetencji i wiedzy, jak przedstawić wymagania w sposób zrozumiały dla wykonawcy, aby jednocześnie były one precyzyjnymi kryteriami odbioru gotowego produktu. Doprecyzowanie wymagań leży w interesie dostawcy, gdyż pozostawienie ich bez wyjaśnienia spowoduje, że planowanie projektu zostanie wykonane na bardzo niedokładnych założeniach. Jak wygląda praktyka? Z różnych przyczyn, w tym z powodu błędów procesowych lub braku wiedzy, ale i w wyniku świadomego działania, dostawca często nie precyzuje wymagań przed podjęciem się realizacji danego projektu. Z nieprecyzyjnym opisem wymagań trudno realistycznie i wiarygodnie oszacować wysiłek, zakres i koszt projektu. Takie projekty są najczęściej niedoszacowane (ponieważ zakłada się mniej pracy, niż należy wykonać w rzeczywistości) albo przeszacowane (dodanie pewnego bufora na zapas ). Ponadto, przy takim sformułowaniu wymagań niemal niemożliwe staje się stwierdzenie, kiedy i czy w ogóle wymaganie zostało zaimplementowane. Brak mierzalności i kryteriów akceptacji powoduje, że odbiór gotowego rozwiązania opiera się na wierze, nie faktach. Początkowe problemy z wymaganiami skutkują często dalszymi konsekwencjami. Wstępnie ustalone harmonogramy projektów oszacowanych i zaplanowanych na

15 22 WPROWADZENIE DO INŻYNIERII WYMAGAŃ podstawie nieprecyzyjnych wymagań są zazwyczaj niemożliwe do realizacji. Brakuje czasu na wykonanie wszystkich czynności związanych z poprawnym wytworzeniem produktu. Jaki jest skutek? Próbuje się oszczędzić nieco czasu, maksymalnie skracając pewne etapy procesu wytwórczego. Jak można się domyślić, z reguły skraca się czas przeznaczony na szczegółową analizę wymagań lub/i testy, ponieważ w obiegowej, aczkolwiek całkowicie błędnej opinii procesy te mają najmniejszą wartość dodaną dla wytworzenia produktu. Analiza nie tworzy przecież kodu, czyż nie? Skracanie czasu analizy oznacza ryzyko pominięcia wymagań, ważnych ograniczeń czy reguł biznesowych, a w konsekwencji nieprawidłowy lub niepełny projekt rozwiązania. Idąc dalej poważne problemy przy odbiorze produktu, ponieważ, co jest całkowicie uzasadnione, klient nie wyrazi zgody na odbiór systemu i zapłatę za jego dostarczenie, jeżeli produkt nie spełni jego oczekiwań. Warto dodać, że w takim przypadku jedynym rozsądnym rozwiązaniem jest poprawienie produktu zgodnie z zastrzeżeniami klienta czyli wprowadzenie zmian w wytworzonym, stabilnym oprogramowaniu. Skutki późnych zmian są oczywiste wysokie ryzyko destabilizacji systemu i związana z nim konieczność wzmożonych testów regresyjnych i poprawek Brak umiejętności miękkich Komunikacja w zespole i dobrze dobrane kompetencje jego członków są zazwyczaj podstawą sukcesu przedsięwzięcia, jednak ich brak bywa równie często przyczyną klęski. Kompetencje miękkie, często określane w ogłoszeniach o pracę jako umiejętność pracy zespołowej, stanowią podstawę do zrozumienia, dialogu, budowania zaufania podczas realizacji projektu oraz na etapie jego utrzymania. Brak umiejętności nawiązywania kontaktu, odpowiedniego zadawania pytań czy wzbudzania zaufania może skutecznie utrudniać budowanie relacji z klientem, a w rezultacie tak istotną komunikację w projekcie. Jej zaniedbanie możemy utożsamiać z jednoczesnym odcięciem od informacji na temat tego, co dzieje się u naszego klienta, albo sposobu, w jaki postrzega on realizację samego projektu. Przykładem problemu z nawiązywaniem kontaktu mogą być zespoły handlowe, których podstawowym zadaniem jest poszukiwanie klientów. Jeśli sprzedawca przyklei na komputerze kartkę z napisam Zadzwoń do klienta jutro, po dwóch tygodniach zadanie często nadal nie jest wykonane bo karteczka przecież mówi jutro. Często kierują nami lęki, odruchy i przyzwyczajenia, w tym przypadku strach przed podniesieniem słuchawki i kontaktem z nieznaną osobą. Kompetencje te należy wykształcić. W zespole, który jest silnie ukierunkowany na zadania techniczne, często nie są one ćwiczone lub wyuczone. Stała techniczna praca z komputerem zamyka nas w małym świecie, w którym koncentrujemy się na realizacji zadania, skutecznie odcinając się od ludzi, którzy nas otaczają. Rezultatem tego są stereotypy informatyków, którzy głównie programują lub wykonują inną pracę na komputerze, jednak nie są w stanie nawiązać relacji z innymi ludźmi. W wielu krajach system edukacji nie obejmuje przemawiania, nawiązywania kontaktu, dyplomacji czy dyskusji. Polska nie odbiega pod tym względem od światowej średniej. Cierpimy na tym później, kiedy stajemy przed zarządem firmy

16 1.1. Wyzwania związane z projektami IT 23 i prezentujemy korzyści z wdrożenia naszego rozwiązania, wiedząc, że od jakości wystąpienia zależy kontrakt lub jego brak. Bez odpowiedniego przygotowania staje się to nie lada wyzwaniem. Istotnym składnikiem poprawnej komunikacji są spotkania, prowadzenie rozmów czy zwykłe zadawanie pytań w celu otrzymania informacji, które z perspektywy realizacji projektu interesują nas najbardziej. W wielu projektach znajdujemy niejasne wymagania typu system ma być ładny i zachodzimy w głowę, co autor miał na myśli. Zawsze możemy przyjąć, że wiemy lepiej i zrealizować zadanie zgodnie z naszą najlepszą wiedzą. Praktyka wskazuje jednak, że najpewniej nie uda nam się stworzyć dokładnie tego, co miał na myśli klient. Z pomocą przychodzą nam kompetencje miękkie, które pomagają zadawać odpowiednie pytania precyzujące: Dlaczego system ma być ładny (powód problemu z wyglądem)? Po co system ma być ładny (jak ma wygląd pomóc w dalszej pracy)? Jak wyobrażasz sobie idealne rozwiązanie tego problemu (zmusza klienta do myślenia o szczegółach)? Po takiej serii pytań może się okazać, że stary interfejs systemu był mało czytelny, klientowi zależy głównie na poprawieniu jego przejrzystości i użyteczności, a chce to zrealizować za pomocą dynamicznie generowanych tabel. Jeśli nie zadajemy pytań lub nie wiemy, o co pytać, stajemy przed wyzwaniem zdobycia szczytu góry, zdając się na ślepy los. Zwiększamy w ten sposób ryzyko, liczba niewiadomych rośnie niewiarygodnie, a wymarzony szczyt się oddala. Analogia ta sprawdza się we wszystkich dziedzinach, które wymagają współpracy z innymi ludźmi, nie tylko w projektach IT. Istnieje wiele technik miękkich i należy pamiętać, że często odgrywają one dużą rolę w projektach. Liczą się nie tylko kompetencje techniczne, ale często także forma przekazania lub pozyskania informacji oraz utrzymanie relacji z klientem. Brak takich umiejętności może skutecznie utrudnić pracę nad projektem i zdobywanie informacji, które mogą pomóc w jego efektywniejszej realizacji. Jeżeli jednak uda się nam zrealizować go z sukcesem, utrzymanie dobrych relacji i zrozumienie klienta to klucz do następnych kontraktów i zleceń Nierealistyczne oczekiwania Wszystkie realizowane projekty wykorzystują pewne wstępne wyobrażenia gotowych produktów oraz założenia, jakie przyjmujemy na początku ich realizacji. W oczach zamawiającego gotowy produkt jest często bliski ideału i wykracza daleko poza realne możliwości technologiczne lub oczekiwania rynku. Warunki przyjęte podczas realizowanych projektów często wymykają się spod kontroli, a od klienta słyszymy to jest to, czego chcieliśmy, ale. Co gorsza mogą one generować koszty nieadekwatne do wartości wytwarzanego rozwiązania. Podczas pracy nad projektami możemy spotkać osoby, które stawiają nierealistyczne wymagania bez uzasadnionej przesłanki biznesowej lub wybiegają z oczekiwaniami daleko w przyszłość. Oczywiście wszystko jest kwestią środków przeznaczonych na realizację projektów, jednak z praktyki wynika, że budżet projektu jest zawsze jest za mały, ponieważ projekty często są niedoszacowane.

17 24 WPROWADZENIE DO INŻYNIERII WYMAGAŃ Doświadczenie wskazuje, że nie istnieją projekty, w których przy ustalonym zakresie prac możemy dowolnie zmniejszyć budżet lub wymagać dużo większej jakości. Jak w anegdocie o szewcu, usługa może zostać wykonana: szybko i dobrze, ale nie tanio, tanio i szybko, ale jakości próżno się doszukiwać, tanio i dobrze, jednak w bardzo długim czasie. Z przedstawionych refleksji wyłania się problem ustalenia realnych priorytetów w projektach i przypisania ich do zebranych wymagań. W projektach wewnętrznych często można spotkać sytuację, w której wszystkie wymagania mają zostać zrealizowane, a nikt nie jest w stanie wskazać najważniejszych z nich. Przykładem może być przygotowanie prototypu produktu na konferencję, podczas gdy z góry wiadomo, że nie jesteśmy w stanie przygotować pełnej funkcjonalności na podany termin. Dyrektor naciska, zespół informuje, że produkt będzie gotowy w kwietniu roku następnego, a konferencja ma odbyć w grudniu. Sytuacja patowa bez podjęcia odpowiednich kroków i decyzji, co pokazać i realnie wykonać, strata zaistnieje zarówno po stronie biznesowej, jak i technicznej dla samego zespołu rozwoju, który dostanie zadanie nie do wykonania. Bez podjęcia działań spotkamy się z typowym marszem ku klęsce zespół będzie pracował nad produktem dnie i noce, choć z góry wiadomo, że nie wywiąże się z realizacji zadania. Nierealne wymagania są często formułowane jako oczekiwania. Niestety na wczesnym etapie projektu nie są one weryfikowane, ponieważ często nie ma takiej możliwości, a następnie generują wysokie koszty realizacji projektu lub tworzą niepotrzebne opóźnienia i utrudnienia. Najczęściej dotyczy to wymagań niefunkcjonalnych, których natura uniemożliwia ich łatwe opisanie. Stanowią one najtrudniejszą w realizacji część projektów. Praktyka pokazuje, że w takich sytuacjach musimy przedyskutować priorytety w projekcie z klientem oraz przedstawić mu obiektywne zalety oraz wady decyzji. Stała współpraca z biznesem ma znaczący wpływ na powodzenie projektu i należy ją doceniać. Szczególny nacisk na obecność interesariuszy możemy zaobserwować w popularnych metodykach zwinnych, np. Scrum, gdzie do reprezentowania biznesu klienta dedykowana jest odrębna rola o pełnej dostępności dla dostawcy Brak zasobów ludzkich Trudno jest znaleźć osobę z wymaganymi kompetencjami, a jednocześnie odpowiednio zmotywowaną do wykonywania aktywności związanych z realizacją projektu informatycznego. Ponieważ w obszarze testowania problem kadrowy jest dużym wyzwaniem, stanowiska często są obsadzane przez osoby z kwalifikacjami odbiegającymi od wymaganych, co skutkuje nieodpowiednim lub nieefektywnym prowadzeniem projektów. Ostatnie badania przeprowadzone wśród dyrektorów IT w Polsce wykazały, że największymi problemami, z jakimi spotykają się podczas wykonywa-

18 1.1. Wyzwania związane z projektami IT 25 nia codziennych zadań, są brak odpowiednich środków finansowych oraz zasobów ludzkich 2. W dzisiejszych czasach projekt obejmuje wiele systemów w zróżnicowanych technologiach i wymaga od zespołu różnego rodzaju kompetencji. Nie jest możliwe pokrycie całego zakresu kompetencji jedną osobą lub małym interdyscyplinarnym zespołem to najlepsza droga do dalszego zmniejszenia dostępnych zasobów. Mimo popularności metodyk zwinnych wykorzystujących małe interdyscyplinarne zespoły realizacja przez taki zespół wszystkich możliwych zadań w organizacji nie jest możliwa. Skalując takie zespoły i metodyki w organizacji, zyskujemy wymieszanie kompetencji i doświadczeń, jednak nie zawsze umożliwamy zespołom specjalizację, ponieważ nie idzie ona w parze z metodykami zwinnymi, jak np. Scrum. Aby określić szacowane koszty realizacji projektu, zasoby w projekcie powinny być zapewnione już na etapie powołania i definiowania wymagań. Niedoszacowanie kosztów zasobów to taki sam błąd jak pominięte wymagania czy brak odpowiednich środków finansowych na zakup wymaganych licencji na oprogramowanie. Specyficzne wymagania, normy lub metodyki mogą generować potrzebę zatrudnienia lub wynajęcia specjalisty. Sytuacja komplikuje się, jeżeli jego kompetencje są tak unikalne, że zasobów musimy szukać w innym kraju lub wręcz na innym kontynencie. Brak zasobów może przejawiać się jako różne typy potrzeb, czasem może wymagać dużej liczby osób do wykonania prostych prac, np. przeklikania scenariuszy testowych, lub częściej zadań wymagających specjalistycznych kompetencji metodycznych lub technologicznych. Brak specjalistów w zespole brak osób o kompetencjach potrzebnych do realizacji konkretnych zadań lub elementów wymaganych w projekcie. Zatrudnienie odpowiedniej osoby w ramach kontraktu Fixed-Term jest bardzo kosztowne, ponieważ wąska specjalizacja będzie generować wysokie koszty. Z pomocą przychodzą płatne usługi firm specjalizujących się w realizacji wykwalifikowanych zadań. Brak zasobów ludzkich do realizacji prac brak osób do realizacji zbyt dużej liczby zadań niekoniecznie wymagających wyspecjalizowanych kompetencji. Szczęśliwie na rynku istnieje wiele firm specjalizujących się w usługach typu body leasing, w których możemy wynajmować osoby do wykonywania dużej liczby zadań, ponosząc relatywnie niewysokie koszty. Należy pamiętać że zwiększenie liczby pracowników nie zawsze przyśpieszy wykonywanie pewnych czynności, a wręcz może je czasem skomplikować i wydłużyć czas realizacji. Przykładem ze świata przyrody może być ciąża u słonic, która trwa 2 III Krajowa Konferencja Inżynierii Oprogramowania Inżynieria oprogramowania w procesach integracji systemów informatycznych Cezary Orłowski, Paweł Madej, Łukasz Szczygielski, Bartosz Chrabski Zarządzanie przedsięwzięciami informatycznymi z wykorzystaniem centrów kompetencyjnych dużych firm informatycznych (12 15 września 2011).

19 26 WPROWADZENIE DO INŻYNIERII WYMAGAŃ 22 miesiące. Jeżeli dodamy kolejnych 21 słonic, nie uzyskamy małego słonia w miesiąc. Niektóre procesy w organizacji zajmują określony czas i z perspektywy zasobów nie mamy większego wpływu na ich przyspieszenie. W tym obszarze możemy jednak wpłynąć na jakość zasobów, które wykonują dla nas pracę, aby zapewnić odpowiednią realizację tego procesu. Odpowiednie zasoby i ich kompetencje są istotne dla projektu, ponieważ to właśnie pracownicy tworzą produkt dla klienta. Są one jednak zależne od pozostałych elementów ważnych dla projektu komunikacji w projekcie, oczekiwań czy zakresu, mając na nie znaczący wpływ. Dobór osób do projektu powinien zawsze być zdeterminowany przez ich kompetencje, wartość, jaką wnoszą, i doświadczenia z wcześniejszych projektów Brak odpowiedniego wsparcia narzędziowego i metodycznego Podstawą opracowania procesu prowadzenia projektów dopasowanego do organizacji są odpowiednio dobrane dobre praktyki, metody zarządzania oraz efektywne narzędzia wspierające. Ich wybór dla wielu organizacji stanowi wyzwanie i poważny problem. Analizując środowiska, w których obecnie prowadzone są projekty, możemy stwierdzić, że zespoły analityków, programistów i testerów zwykle nie komunikują się ze sobą w sposób efektywny, co negatywnie wpływa na wydajność pracy, koszty i jakość finalnego produktu. Powszechnie używane narzędzia wspierające prowadzenie projektu nie potrafią wymieniać informacji między sobą, co prowadzi do powielania funkcjonalności i konieczności żmudnego i narażonego na błędy przenoszenia danych między nimi. Wybór narzędzi dokonywany jest zwykle pod kątem zaspokojenia potrzeb każdego zespołu z osobna, co z czasem całkowicie blokuje rozwój strategii departamentu odpowiedzialnego za rozwój IT. Oczywistym wnioskiem jest konieczność dążenia do konsolidacji dyscyplin w ramach projektu na poziomie integracji repozytoriów danych i ujednolicenia narzędzi, przy jednoczesnej eliminacji powielania ich podstawowych funkcji. Zgodnie z tą koncepcją, efektywne narzędzia wspierające pracę zespołów projektowych powinny obsługiwać cały zintegrowany cykl produkcyjny (ang. Application Lifecycle Management skrót ALM). ALM ma za zadanie zintegrować najważniejsze dyscypliny projektowe, jak zarządzanie wymaganiami, zarządzanie zmianami i konfiguracjami oraz zarządzanie procesami zapewnienia jakości. Dla osiągnięcia jak najlepszych efektów, narzędzia ALM powinny wspierać się na solidnych fundamentach, które zapewnią możliwość pomiaru efektywności procesów wytwarzania oraz współpracy między wszystkimi uczestnikami projektu. Każda organizacja profesjonalnie zajmująca się wytwarzaniem oprogramowania lub systemów pracuje według ustalonych procesów. Mogą być one dokumentowane w postaci metodyk, jak Scrum, OpenUP, EclipseWay, T-Map Next czy Rational Unified Process, lub przyjęte jako nieformalne zbiory dobrych praktyk. Adaptacja posiadanych narzędzi do przyjętych procesów jest wyzwaniem dla wielu organizacji, szczególnie gdy procesy te są nowe lub specyficzne dla dziedziny przedsięwzięcia. Wybierając narzędzie, zawsze powinniśmy się kierować jego wsparciem dla aktu-

20 1.2. Podstawowe definicje oraz klasyfikacje 27 alnych lub przyszłych procesów używanych w organizacji. W idealnej sytuacji producent udostępnia w narzędziu różne szablony metodyk, jak również umożliwia ich edycję i tworzenie własnych szablonów od podstaw. Ocena aktualnego stanu projektu, zarządzanie ryzykiem czy budżetem są poważnym wyzwaniem w każdym przedsięwzięciu. Dzięki opcji wglądu w rzeczywiste dane projektowe możliwe jest wczesne podejmowanie decyzji pozwalających ograniczyć wiele ryzyk. Z perspektywy kadry zarządzającej czy kierownika projektu szczególnie istotny staje się element raportowania i planowania prac z uwzględnieniem bieżących danych z przebiegu prac, ewentualnych opóźnień czy danych historycznych z zakończonych wcześniej projektów. Wszelkie zmiany w wymaganiach, problemy technologiczne, odstępstwa od planu, urlopy, przeciągające się zadania czy rozwiązania błędów zgłoszonych przez klientów powinny być możliwe do śledzenia i weryfikowania w czasie rzeczywistym. Wyciągane wniosków ze zrealizowanych projektów pomaga znacznie obniżyć koszty i zwiększać produktywność. Narzędzia powinny gromadzić ważne dane projektowe i wspierać kadrę zarządzającą w procesie ich analizy. Oczywistym przykładem zastosowania takich informacji jest weryfikacja poprawności szacowania pracochłonności. Innym przykładem użycia danych archiwalnych do retrospekcji jest analiza głównych źródeł błędów i problemów napotkanych w projektach. Większość organizacji korzysta już z różnego rodzaju narzędzi wspierających różne dyscypliny procesu tworzenia oprogramowania rozwiązujące specyficzne potrzeby organizacji. Rezygnacja z nich wiązałaby sie ze stratami jakości obsługi procesów, dlatego narzędzia takie powinny być zintegrowane, aby cały proces wytwarzania był efektywny, mierzalny i przewidywalny. Podsumowując czynniki wpływające na sukces projektu, można pokusić się o stwierdzenie, że spora część z nich w mniejszym lub większym stopniu dotyczy inżynierii wymagań. Potwierdzają to przeróżne statystyki opracowywane przez organizacje profesjonalnie zajmujące się badaniami rynku, na przykład Standish Group czy Gartner. Ich opracowania od lat wskazują w przybliżeniu te same przyczyny niepowodzeń projektów, wśród których niezmiennie czołowe pozycje zajmują zagadnienia związane z wymaganiami i celami biznesowymi Podstawowe definicje oraz klasyfikacje Punktem startowym dla inżynierii wymagań jest tak zwany problem biznesowy. Opisuje on potrzebę czy cel biznesowy, które będą rozwiązane przez docelowy produkt. Problem biznesowy jak nazwa wskazuje w ujęciu biznesowym opisuje, co chcemy osiągnąć. Na tym etapie nie ma mowy o szczegółach planowanego produktu czy aspektach Premiera implementacyjnych. książki Koncentrujemy - listopad się na potrzebie Przykładem problemu biznesowego jest potrzeba optymalizacji procesu obsługi klienta. Problem biznesowy jest likwidowany przez tak zwane rozwiązanie. Jest nim dowolny produkt, usługa czy proces lub ich elementy umożliwiające spełnienie wymagań związanych z realizacją danego problemu biznesowego. Rozwiązanie definiowane jest jako zmiana w obecnym stanie organizacji wykonana w celu osią-

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

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

Bardziej szczegółowo

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

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

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

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

Zarządzanie projektami IT

Zarządzanie projektami IT Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie

Bardziej szczegółowo

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

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

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

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

Katalog rozwiązań informatycznych dla firm produkcyjnych

Katalog rozwiązań informatycznych dla firm produkcyjnych Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

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

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

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

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

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

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

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

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

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

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

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology

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

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Wdrożenie systemu planowania zasobów przedsiębiorstwa pomimo wielu korzyści często też wiąże się

Bardziej szczegółowo

SZKOLENIE BADANIE SATYSFAKCJI KLIENTA I ZARZĄDZANIE SATYSFAKCJĄ KLIENTA W PRZEDSIĘBIORSTWIE

SZKOLENIE BADANIE SATYSFAKCJI KLIENTA I ZARZĄDZANIE SATYSFAKCJĄ KLIENTA W PRZEDSIĘBIORSTWIE SZKOLENIE ROZWIĄZANIA W ZAKRESIE ROZWOJU KAPITAŁU LUDZKIEGO PRZEDSIĘBIORSTW BADANIE SATYSFAKCJI KLIENTA I ZARZĄDZANIE SATYSFAKCJĄ KLIENTA W WPROWADZENIE W dobie silnej konkurencji oraz wzrastającej świadomości

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

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management

Bardziej szczegółowo

KARTA OCENY MERYTORYCZNEJ. Kryterium Czy warunek został spełniony? Okres realizacji projektu jest zgodny z okresem wskazanym w regulaminie

KARTA OCENY MERYTORYCZNEJ. Kryterium Czy warunek został spełniony? Okres realizacji projektu jest zgodny z okresem wskazanym w regulaminie KARTA OCENY MERYTORYCZNEJ Część I: Kryteria formalne podlegające weryfikacji na etapie oceny merytorycznej Kryterium Czy warunek został spełniony? Okres realizacji projektu jest zgodny z okresem wskazanym

Bardziej szczegółowo

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE OFERTA WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE W TWORZENIU MODELU AS-IS /Jest to przykład (wzór) oferty treść jest wypełniana na podstawie nie zobowiązujących rozmów i spotkań z Klientem, pracownikami

Bardziej szczegółowo

www.omec.pl 1 Konferencja "Bezpieczny Projekt" Wrocław 22 czerwca 2010

www.omec.pl 1 Konferencja Bezpieczny Projekt Wrocław 22 czerwca 2010 Od kartki i ołówka do systemu informatycznego, czyli jak wdrażano zarządzanie projektami u klienta Rinf Sp. z o.o. www.omec.pl 1 Co my rozumiemy pod pojęciem: PROJEKT Projekt: Ciąg zadań nastawionych na

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

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

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

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

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

Bardziej szczegółowo

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

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

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

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

6. Zarządzanie Projektami

6. Zarządzanie Projektami 6. Zarządzanie Projektami Wersja ucznia Wstęp 1. Proces Zarządzania Projektami 2. Zarządzanie ryzykiem "Zarządzanie projektami jest o wyznaczaniu jasnych celów, zarządzaniu czasem, zasobami, ludźmi i kosztami

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

Zasady organizacji projektów informatycznych

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

Bardziej szczegółowo

RAPORT Z POLSKIEGO BADANIA PROJEKTÓW IT 2010

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

Bardziej szczegółowo

Projekt 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

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia

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

Popularyzacja podpisu elektronicznego w Polsce

Popularyzacja podpisu elektronicznego w Polsce Popularyzacja podpisu elektronicznego w Polsce Rola administracji w budowaniu gospodarki elektronicznej Warszawa, 25 września 2006 r. Poruszane tematy Wprowadzenie i kontekst prezentacji Rola administracji

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

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

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

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Projekt: Szansa drzemie w zmianie nowoczesne ZZL

Projekt: Szansa drzemie w zmianie nowoczesne ZZL Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego Projekt: Szansa drzemie w zmianie nowoczesne ZZL Opis szkoleń planowanych do realizacji w ramach projektu

Bardziej szczegółowo

6 kroków do skutecznego planowania na postawie wskaźników KPI

6 kroków do skutecznego planowania na postawie wskaźników KPI 6 kroków do skutecznego planowania na postawie wskaźników KPI Urzeczywistnianie celów biznesowych w praktyce Planowanie i optymalizacja łańcucha dostaw Odkryj brakujące połączenie pomiędzy celami biznesowymi

Bardziej szczegółowo

Launch. przygotowanie i wprowadzanie nowych produktów na rynek

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

Bardziej szczegółowo

Organizacyjny aspekt projektu

Organizacyjny aspekt projektu Organizacyjny aspekt projektu Zarządzanie funkcjonalne Zarządzanie między funkcjonalne Osiąganie celów poprzez kierowanie bieżącymi działaniami Odpowiedzialność spoczywa na kierownikach funkcyjnych Efektywność

Bardziej szczegółowo

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing ZARZĄDZANIE MARKĄ Doradztwo i outsourcing Pomagamy zwiększać wartość marek i maksymalizować zysk. Prowadzimy projekty w zakresie szeroko rozumianego doskonalenia organizacji i wzmacniania wartości marki:

Bardziej szczegółowo

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy Zespół Testów

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

Ś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

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

BPM vs. Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów

BPM vs. Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów BPM vs. Content Management Jarosław Żeliński analityk biznesowy, projektant systemów Cel prezentacji Celem prezentacji jest zwrócenie uwagi na istotne różnice pomiędzy tym co nazywamy: zarzadzaniem dokumentami,

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

Wprowadzenie do systemów informacyjnych

Wprowadzenie do systemów informacyjnych Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Wartość audytu wewnętrznego dla organizacji. Warszawa, 11.03.2013

Wartość audytu wewnętrznego dla organizacji. Warszawa, 11.03.2013 Wartość audytu wewnętrznego dla organizacji Warszawa, 11.03.2013 Informacje o Grupie MDDP Kim jesteśmy Jedna z największych polskich firm świadczących kompleksowe usługi doradcze 6 wyspecjalizowanych linii

Bardziej szczegółowo

Kompleksowe rozwiązanie dla organizacji,

Kompleksowe rozwiązanie dla organizacji, Kompleksowe rozwiązanie dla organizacji, W KTÓRYCH REALIZOWANE SĄ PRZEDSIĘWZIĘCIA PROJEKTOWE 0 801 2727 24 (22 654 09 35) Kompleksowe wsparcie realizacji projektu Czy w Twojej organizacji realizowane są

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

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem.

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem. Kryteria merytoryczne wyboru projektów dla poddziałania 2.3.1 Cyfrowe udostępnianie informacji sektora publicznego (ISP) ze źródeł administracyjnych oraz zasobów nauki Programu Operacyjnego Polska Cyfrowa

Bardziej szczegółowo

ERP przyspiesza Kontrolę Jakości

ERP przyspiesza Kontrolę Jakości ERP przyspiesza Kontrolę Jakości Jedną z priorytetowych wartości, najszybciej rozwijających się przedsiębiorstw produkcyjnych jest: Kontrola Jakości. Przedsiębiorcy zwiększają konkurencyjność swoich firm,

Bardziej szczegółowo

Budowanie skutecznych systemów zarządzania opartych na normach ISO

Budowanie skutecznych systemów zarządzania opartych na normach ISO UKatalog Szkoleń: Budowanie skutecznych systemów zarządzania opartych na normach ISO UBlok I Podejście procesowe: Zarządzanie procesowe (2 dni) Definicje procesu, zarządzanie procesami, podział i identyfikowanie

Bardziej szczegółowo

PRINCE2. Metodyka zarządzania projektami. Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak

PRINCE2. Metodyka zarządzania projektami. Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak PRINCE2 Metodyka zarządzania projektami Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak Metodyka PRINCE2 PRINCE2 Project IN Controlled Environments v.2 Określa: Co należy zrobić Dlaczego

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

Katalog rozwiązań informatycznych dla firm produkcyjnych

Katalog rozwiązań informatycznych dla firm produkcyjnych Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

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

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

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

Katalog szkoleń certyfikowanych Testowanie Oprogramowania

Katalog szkoleń certyfikowanych Testowanie Oprogramowania Katalog szkoleń certyfikowanych Testowanie Oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

Bardziej szczegółowo

Przedmowa... 7 1. System zarządzania jakością w przygotowaniu projektów informatycznych...11

Przedmowa... 7 1. System zarządzania jakością w przygotowaniu projektów informatycznych...11 Spis treści Przedmowa... 7 1. System zarządzania jakością w przygotowaniu projektów informatycznych...11 1.1. Wprowadzenie...11 1.2. System zarządzania jakością...11 1.3. Standardy jakości w projekcie

Bardziej szczegółowo

Szkolenie Scrum w projektach IT (Agile)

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

Bardziej szczegółowo

Zarządzanie projektów

Zarządzanie projektów Zarządzanie projektów Część 3 Etapy projektów Rozpoczęcie projektu Planowanie projektu Współpraca z zarządem Tworzenie budżetu Organizacja zespołu projektowego Tworzenie planu projektu Optymalizacja projektu

Bardziej szczegółowo

KOMPLEKSOWE ZARZĄDZANIE JAKOŚCIĄ MODELOWANIE PROCESÓW

KOMPLEKSOWE ZARZĄDZANIE JAKOŚCIĄ MODELOWANIE PROCESÓW KOMPLEKSOWE ZARZĄDZANIE JAKOŚCIĄ MODELOWANIE PROCESÓW Cel szkolenia: Przekazanie wiedzy na temat kompleksowego zarządzania jakością w tym modelowania procesów. Podnoszenie kompetencji i umiejętności związanych

Bardziej szczegółowo

Program Poprawy Efektywności Zakupów. Jak kupować, aby poprawiać rentowność?

Program Poprawy Efektywności Zakupów. Jak kupować, aby poprawiać rentowność? Program Poprawy Efektywności Zakupów Jak kupować, aby poprawiać rentowność? Oferta Zakupy Celem każdej firmy jest zdobycie dominującej pozycji na rynku, która przekłada się na poziom obrotów i zysków firmy.

Bardziej szczegółowo

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A. Leszek Dziubiński Damian Joniec Elżbieta Gęborek Computer Plus Kraków S.A. Wykorzystanie Microsoft Project Server w procesie zarządzania projektami Kompetencje partnerskie Gold: Portals and Collaboration

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

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

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

Wprowadzenie do zarządzania projektami

Wprowadzenie do zarządzania projektami Wprowadzenie do zarządzania projektami Project Management dr Marek Wąsowicz Katedra Projektowania Systemów Zarządzania, UE Wrocław Wrocław, 23 października 2012 r. Zawartość modułu (4h): wskazanie możliwości

Bardziej szczegółowo

PROPONOWANE MODUŁY SZKOLENIOWE - TEMATYKA. przedstawienie się;

PROPONOWANE MODUŁY SZKOLENIOWE - TEMATYKA. przedstawienie się; I DZIEŃ COACHING ZESPOŁU PROPONOWANE MODUŁY SZKOLENIOWE - TEMATYKA MODUŁ TEMATYKA ZAJĘĆ przedstawienie się; SESJA WSTĘPNA przedstawienie celów i programu szkoleniowego; analiza SWOT moja rola w organizacji

Bardziej szczegółowo

Streszczenie dla klienta/wstęp do zintegrowanego projektowania

Streszczenie dla klienta/wstęp do zintegrowanego projektowania Streszczenie dla klienta/wstęp do zintegrowanego projektowania Zleceniodawca: European Commission Executive Agency for Competitiveness and Innovation Projekt: 530256 MaTrID Data: 2013-08-07 Autor: Tłumaczenie:

Bardziej szczegółowo

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium Kryteria merytoryczne wyboru projektów dla poddziałania 2.3.2 Cyfrowe udostępnienie zasobów kultury Programu Operacyjnego Polska Cyfrowa na lata 2014-2020 Typ projektu Cyfrowe udostępnienie zasobów kultury

Bardziej szczegółowo

Skuteczna Strategia CRM - wyzwanie dla organizacji. Artur Kowalski Prometriq

Skuteczna Strategia CRM - wyzwanie dla organizacji. Artur Kowalski Prometriq Skuteczna Strategia CRM - wyzwanie dla organizacji Artur Kowalski Prometriq Wrocław, 19-11-2009 Jest tylko jedna strategia sukcesu Polega ona na precyzyjnym zdefiniowaniu docelowego odbiorcy i zaoferowaniu

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

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

Kluczowe aspekty wdrażania narzędzi do zarządzania projektami

Kluczowe aspekty wdrażania narzędzi do zarządzania projektami Kluczowe aspekty wdrażania narzędzi do zarządzania projektami Narzędzia IT do zarządzania projektami są tylko tak dobre, jak ludzie z nich korzystający i sposób w jaki są wykorzystywane. Mając na uwadze

Bardziej szczegółowo

Raport oceny kompetencji

Raport oceny kompetencji Symulacje oceniające kompetencje Raport oceny kompetencji Rut Paweł 08-01-2015 Kompetencje sprzedażowe dla efactor Sp. z o.o. Dane osobowe Rut Paweł CEO pawel.rut@efactor.pl more-than-manager.com 2 z 13

Bardziej szczegółowo