Wykład 1:

1. Czym się charakteryzuje projekt?

• tymczasowość – każdy projekt ma określone terminy rozpoczęcia i zakończenia, czyli ograniczony czas trwania

• unikalność – produkt lub usługa różnią się pod pewnymi względami od innych produktów lub usług, mogą posiadać cechy powtarzalne

• zakończenie projektu – osiągnięcie jego celów, stwierdzenie niemożliwości realizacji celów, wygaśnięcie przyczyn dla której rozpoczęto projekt

• stopniowe doprecyzowanie – na początku projektu własności wyróżniające produkt określa się w ogólnym zakresie, w miarę postępu badań następuje definiowanie szczegółowych własności

1. Różnica między projektem a działalnością operacyjną

• projekt: tymczasowość i unikalność, podejmuje się w celu osiągnięcia strategicznych celów

• działalność operacyjna: charakter ciągły, powtarzalność, zapewnienie ciągłego funkcjonowania organizacji

1. Struktura warstw zarządzania w projekcie

• warstwa pierwsza - zarząd organizacji

  • wypracowanie strategii

  • koordynacja wszystkich projektów prowadzących do oczekiwanych zmian

  • wyznaczenie rady projektu do działania w ustalonych ograniczeniach

• warstwa druga - rada projektu

  • kierowanie całością projektu

  • odpowiedzialność za wyniki prac

  • mianowanie i rozliczanie kierowników projektu

  • zatwierdzanie zmian

  • przyjmowanie wyników projektu

  • podejmowanie decyzji w zakresie:

    • oceny zrozumienia przez kierownika projektu oczekiwań

    • oceny sposobu gospodarowania finansami

    • zgodności proponowanych rozwiązań ze strategią organizacji

    • kontynuacji lub zamknięcia projektu (przekroczenie ram czasowych i budżetowych)

    • ustalenie płatnika za główne zmiany

    • oceny przygotowania organizacji do akceptacji produktu oferowanego przez kierownika projektu

    • ocena spełniania wymagań przez produkt

• warstwa trzecia - kierownik projektu

  • planowanie, monitorowanie, kontrola

  • w większych projektach podejmowanie decyzji finansowych oraz w zakresie specyfikacji wymagań, zasobów, akceptacji produktów

• kierownik zespołu

  • odpowiedzialność za pracę przydzielonego zespołu realizacyjnego

  • planowanie i kierowanie codziennymi pracami

  • prowadzenie przeglądu prac członków zespołu

  • raportowanie do kierownika projektu

  • powoływany w przypadku:

    • rozproszenia geograficznego personelu

    • dużej liczby osób

    • różnych etapów prac, osób z różnymi umiejętnościami

    • potrzeby zarządzania zespołem osób pochodzących z zewnętrznej firmy

1. Role w projekcie (co to rada projektu, znaczenie biura projektu, umieć powiedzieć po 2 zdania do każdej roli)

Rada projektu – patrz wyżej

Podstawowe role:

• sponsor/klient

  • inicjowanie przedsięwzięć

  • definiowanie biznesowych zamierzeń przedsięwzięcia

  • definiowanie celów przedsięwzięcia i priorytetów

  • określanie minimalnych wymagań dla przedsięwzięcia

  • nadzorowanie postępów prac z biznesowego punktu widzenia

  • informowanie zarządu o postępach

  • ewentualne przerwanie przedsięwzięcia

  • zapewnianie poparcia zarządu dla przedsięwzięcia

• użytkownik

  • określenie wymagań dla produktów

  • określenie kryteriów akceptacji i przygotowanie testów

  • zaplanowanie i wykonanie testów, spisanie uwag i usterek

  • nabycie odpowiedniej wiedzy i umiejętności do korzystania z produktów

  • opracowanie i wprowadzenie niezbędnych zmian w organizacji

  • sporadycznie: przygotowanie danych testowych i napisanie dokumentacji użytkownika końcowego

• kierownik przedsięwzięcia/zespołu

  • osiągnięcie celów w ramach czasu, kosztu i jakości ustalonych przez sponsora

  • planowanie, nadzorowanie i kontrolowanie

  • podejmowanie działań naprawczych

  • wybór, tworzenie i motywowanie zespołu

  • informowanie sponsora i zarządu o postępach oraz zgłaszanie problemów

  • działanie jako główny łącznik między sponsorem, zarządem i uczestnikami przedsięwzięcia

  • wybór i zarządzanie podwykonawcami

• specjalista ds. jakości, ryzyka

• role techniczne

  • analityk

    • definiowanie wymagań użytkownika

    • definiowanie kryteriów akceptacji

    • decydujący udział w opracowaniu dokumentacji użytkownika

    • definiowanie nowych lub zmieniających się wymagań

  • projektant

    • wraz z analitykiem generuje projekt systemu

    • pośrednik pomiędzy analitykami a programistami

    • wprowadzanie zmian projektowych w wyniku zidentyfikowania potrzeb zmian

    • wypracowanie standardów specyficznych dla przedsięwzięcia

  • programista

    • pisanie programu w określonym języku

    • wstępne testowanie

    • implementacja ustalonych zmian

  • tester

  • szkoleniowiec

    • prezentacja działania systemu

    • szkolenie w zakresie korzystania z systemu i wprowadzonych zmian

  • dokumentalista

    • przygotowywanie i przechowywanie dokumentów wykorzystywanych podczas cyklu życia systemu np. specyfikacja wymagań

Biuro projektu ma być wsparciem w sprawach organizacyjnych, komunikacyjnych itp.

Biuro projektów jest stałą komórką w organizacji, której zadaniem jest zachowanie ciągłości w środowisku realizacji ograniczonych w czasie projektów oraz wsparcie zarządzania projektami z punktu widzenia organizacji jako całości poprzez m.in.: koordynację projektów w portfelu, zapewnienie sprawnego obiegu informacji, doskonalenie i rozwój pracowników i kierowników oraz zarządzanie wiedzą projektową

1. Zakres produktu i zakres projektu

Zakres produktu – właściwości oraz funkcje charakteryzujące wyrób lub usługę

Zakres projektu – zbiór zadań do wykonania w celu wytworzenia produktu lub dostarczenia usługi o określonych właściwościach i funkcjach

1. Kategorie definiowania WBS

• fazowy - cykl życia projektu

• produktowy - części systemu (np. formularze ekranowe, raporty, menu)

• organizacyjny – lokalizacja wykonawców

• kontraktowy – poziom sprawozdawczości

1. Zasady tworzenia WBS

• identyfikacja głównych produktów projektu – integracja WBS z zakresem projektu, powiązanie celów organizacji z celami projektu, mapowanie począwszy od głównych produktów do pakietów

• podział głównych produktów do osiągnięcia produktów weryfikowalnych i poziomu szczegółowości zapewniającego zintegrowane planowanie i kontrolę działań

• przedstawienie WBS w postaci drzewa lub tabeli

• zapewnienie produktowego charakteru WBS

• uwzględnienie wszystkich składników pracy

• zapewnienie relatywnej niezależności składników na tym samym poziomie

• zapewnienie podziału pracy na elementy, zgodnego z przyjętą metodą w organizacji

• sprawdzenie, czy WBS zapewnia integrację składników pracy lub oddzielnych poziomów do punktu ich agregacji, równoważnego zakończeniu projektu

Wykład 2:

1. Modele cyklu życia projektu – opisać, cechy pozytywne i negatywne

• model kaskadowy

Jest to typowy model sekwencyjny. Działania są wykonywane jedno po drugim. Występuje relacja poprzednik-następnik (nie można zacząć następnego kroku przed końcem poprzednika). Wygodne podejście dla projektów prostych lub takich, w których produkty można podzielić na części.

Zalety:

• dzieli złożony proces na kilka etapów

• ułatwia śledzenie i kontrolę postępów

• łatwość planowania

Wady

• brak weryfikacji między etapami

• duży odstęp czasu od zakończenia specyfikacji wymagań do wdrożenia

• założenie o wykonaniu poprawnej specyfikacji wymagań

• model V

Model sekwencyjny. Realizacja projektu odbywa się po bokach trójkąta (dlatego model V). Na jednym boku trójkąta są tradycyjne zadania a na drugim etapy kontroli. Do każdego etapu przypisany jest poziom kontroli

Zalety:

• sprzężenie procesów weryfikacji i walidacji z etapami podstawowymi

Wady

• sekwencyjne etapy, których rozpoczęcie zależy od zakończenia poprzedniego

• model prototypowania

Polega na stworzeniu prototypu (szkieletu) oprogramowania. Prototyp jest częścią implementacyjną systemu, wyrażoną logicznie lub fizycznie, prezentowany za pomocą zewnętrznego interfejsu. Może wyglądać jak końcowy produkt (składać się z ekranów, raportów i menu systemu), ale faktycznie nie wykonuje wszystkich funkcji systemu. Wykorzystuje podejście iteracyjne

Zalety:

• na etapie analizy pozwala na ustalenie prawdziwych potrzeb klienta, wspomaga weryfikację specyfikacji wymagań

• na etapie projektowania wspomaga podjęcie decyzji projektowych

• eliminowanie problemu zmienności wymagań

Wady

• trudności w zastosowaniu do dużych systemów lub na poziomie podsystemów

• trudności w określeniu liczby iteracji

• niebezpieczeństwo pozostawienia tymczasowych rozwiązań

• model przyrostowy

Wykorzystuje podejście ewolucyjne. Dzieli produkt na części w ramach, których występuje iteracja. Występuje wielokrotne wykonywanie liniowych procesów-kolejna wersja dostarcza więcej funkcjonalności. Wyróżniamy wersję pierwszą, wersje pośrednie i wersję końcową.

• model RAD

Podejście liniowe z iteracją i możliwością wykorzystania prototypowania wykorzystujące techniki czwartej generacji. Stosowany do systemów modułowych – podział zadań na zespołu.

Zalety

• Przyśpiesza wytworzenie kompletnego produktu.

• Wprowadza do zarządzania projektami powiązania kwalifikacji i motywacji zespołu z celami uzyskiwanymi w określonym czasie.

Wady

• nie nadaje się do przedsięwzięć z dużym ryzykiem technicznym oraz z wymaganiem wysokiej efektywności (kod wygenerowany automatycznie może nie być wydajny)

• wymaga wykwalifikowanego zespołu

• model spiralny

Jest to model ewolucyjny, w którym każda część cyklu musi przejść przez 4 ćwiartki (określenie celów, szacowanie ryzyka, tworzenie produktu następnego poziomu, planowanie następnej fazy). W ten sposób powstaje spirala. Każde okrążenie dotyczy jednego elementu produktu (koncepcja, wymagania, projekt, kod). Każdy taki cykl wiąże się z ponoszeniem kosztów – im więcej cykli tym większa kumulacja kosztów.

Zalety:

• nadaje się do dużych projektów

• podkreśla wagę zagrożeń

• umożliwia zmiany w rozwoju produktu

• wczesna eliminacja błędów

Wady

• wymaga dużej wiedzy i doświadczenia od kierownika procesu

• trudności w opracowaniu i kontroli kontraktu

• model komponentowy

Zakłada istnienie gotowych części systemu (komponentów). Wykorzystuje podobieństwo tworzonego oprogramowania do posiadanych komponentów

Zalety

• zmniejszenie w znacznym stopniu ryzyka

• zapewnienie standardów

• redukcja nakładów, skrócenie procesu wytwórczego

Wady

• konieczność rozwiązywania problemów integracji

• model RUP

Dyscypliny struktury statycznej:

• inżynierskie

  • modelowanie działalności

  • zarządzanie wymaganiami

  • analiza i projektowanie

  • implementacja

  • wdrożenie

  • testowanie

• wspierające

  • zarządzanie przedsięwzięciem

  • zarządzanie zmianami i konfiguracją

  • środowisko

Etapy/wymiary struktury dynamicznej:

• rozpoczęcie (R)

• opracowanie (O)

• budowa (B)

• przekazanie (P)

1. Od czego zależy wybór modelu cyklu życia?

• Wybór modelu odpowiedniego do potrzeb

• Kryteria wyboru modelu

  • ryzyko projektu

  • czas na wykonanie

  • niezawodność produktu

  • klarowność i zmienność wymagań

  • technologia, rozmiar i złożoność

  • interfejs użytkownika

  • priorytety użytkownika

  • spodziewany czas życia systemu

  • interfejsy z istniejącymi lub nowymi systemami

  • potencjalna równoległość działania systemów

• Dostosowanie modelu do konkretnego zespołu wytwórczego

Wykład 3:

1. Cel projektu i cel produktu

Cel projektu – jasno określony wynik projektu, wymierne kryteria które powinien spełniać projekt, aby mógł być uznany za udany, np. wskaźnik kosztowy, jakościowy

Przykład: wdrożenie i udostępnienie do użytkowania programu do końca pierwszego kwartału przyszłego roku

1. Na czym polega uzasadnienie biznesowe?

Uzasadnienie biznesowe polega na opisie i ocenie spodziewanych korzyści i kosztów, określeniu ryzyka związanego z realizacją bądź zaniechaniem projektu oraz określenie skutków finansowych. Jest to więc ocena opłacalności inwestycji

Jest to obowiązkowy dokument niezależnie od rodzaju projektu. Opisuje przyczyny i powody uruchomienia projektu. Prezentuje możliwe rozwiązania. Definiuje jakościowe wymagania klienta wraz z kryteriami akceptacji, problemy klienta do rozwiązania oraz wymagania końcowe wraz z kryteriami akceptacji.

1. Analiza zagrożeń, klasyfikacja

Klasyfikacja zagrożeń:

• wg źródła zagrożenia:

  • projektowe (P): terminy, budżet, zasoby

  • techniczne (T): trudności wykonawcze produktów technicznych

  • ekonomiczne (E): produkt niepotrzebny, nieodpowiedni, ograniczenie budżetu

• wg przewidywalności:

  • znane: wykrywane na podstawie analizy plany i środowiska

  • przewidywalne: odgadywane na podstawie analizy poprzednich projektów

  • nieprzewidywalne: zdarzenia losowe

1. Krytyczne czynniki powodzenia

Przykłady dla etapu:

• strategii:

  • aktywny udział kluczowych wykonawców, opinie liderów, osób reprezentatywnych, tych co rozumieją potrzeby

  • wczesna korekta opinii, pomysłów i modelu organizacji

  • skuteczne sesje zwrotne

• analizy:

  • zaangażowany użytkownik

  • dokładne sprawdzenie kompletności i jakości

  • dokładność informacji ilościowych dla danych i funkcji

• projektowania:

  • poznanie możliwości sprzętu i środków implementacji

  • zrozumienie potrzeb organizacji

  • podjęcie decyzji handlowych

• budowy:

  • zapewnienie jakości i utrzymanie się w harmonogramie

  • wykonanie według wcześniejszych wskazówek

  • strojenie bazy danych lub programów

• dokumentowania:

  • odpowiednia i faktyczna dokumentacja

  • zadowolenie użytkowników i operatorów

  • akceptacja testów

• wdrożenia:

  • odpowiednie szkolenie

  • zadowolenie użytkownika z działania i przyjazności systemu

  • koordynacja czasowa wdrożenia

• eksploatacji:

  • wysoki poziom serwisu

  • terminowe odpowiedzi na pytania użytkowników

  • poprawne sterowanie zmianami

Wykład 4:

1. Kategorie procesów

Rodzaje procesów w organizacji:

• procesy kluczowe (podstawowe)

• procesy zarządcze

• procesy wspierające (pomocnicze)

Rodzaje procesów w projekcie:

• procesy ukierunkowane na produkt

• procesy zarządzania projektami

Grupy procesów zarządzania projektami:

• rozpoczęcia (inicjowania)

• planowania

• realizacji

• kontroli

• zakończenia

1. Metoda łańcucha krytycznego (bufory)

Łańcuch krytyczny:

• diagram sieciowy do harmonogramów z ograniczonymi zasobami

• łańcuch krytyczny – najdłuższa ścieżka zależnych działań i zasobów lub zdarzeń, które nie pozwalają na wcześniejsze zakończenie projektu

• łańcuch krytyczny nie ulega zmianom

• definiowany przez zależności zasobów

Bufory zasobów:

• zasoby są przydzielane do najdłuższej ścieżki

• w przypadku konfliktu zasobów łańcuch zadań krytycznych może być różny od ścieżki krytycznej

• zasób flagowy: nowy zasób na ścieżce CC, wskazuje menadżerowi projektu, kiedy nowy zasób rozpoczyna pracę na CC

• stosuje się różne metody motywacji do wcześniejszego wydania wyników i uzyskania rezerw czasu zasobów

Bufor projektu:

• zabezpieczenie przed nieterminowym zakończeniem projektu

• dodawany na końcu CC

• do bufora nie jest przydzielana żadna praca

Bufory zasilające:

• zabezpieczenie przed ryzykiem działań, które nie są w CC, ale zaangażowanie zasobów może spowodować poślizg działania na CC

• do buforów nie jest przydzielana praca

1. Kroki postępowania przy budowie harmonogramu

Kroki budowy harmonogramu projektu wg CPM:

• Sformułowanie WBS

• Konstrukcja wykresu Gantta

• Zdefiniowanie kamieni milowych

• Oszacowanie zasobów

• Przydzielenie zasobów do zadań

• Ustalenie ograniczeń na podstawie ścieżki krytycznej

1. Wskaźniki metody EV

EV – wartość uzyskana

AC – koszt rzeczywisty

PV – koszt planowany

CV – odchylenie kosztowe CV=EV-AC

SV – odchylenie harmonogramowe SV=EV-PV

CPI – wskaźnik wykonania kosztów CPI=EV/AC

SPI – wskaźnik wykonania harmonogramu SPI=EV/PV

BAC – planowany koszt zakończenia projektu (wartość skumulowana)

SAC – planowany czas trwania projektu (wartość skumulowana)

EAC – estymowany koszt zakończenia EAC=BAC/CPI

SAC – estymowany czas trwania SAC=BAS/SPI

Wykład 5:

1. Aspekty mierzenia oprogramowania (długość, funkcjonalność, złożoność)

• długość – aspekt fizyczny

• funkcjonalność – aspekt użytkowy, efekty otrzymywane przez użytkownika w wyniku działania programu

• złożoność – aspekt dotyczący problemów wytwarzania, jak i użytkowania. Do podstawowych form złożoności zaliczamy:

  • złożoność problemu algorytmu

  • złożoność kodu źródłowego

  • złożoność danych i struktur danych

1. Miara długości (Halsteda, liczby linii kody)

• fizyczne miary długości

  • liczba linii kodu programu LOC (lines of code)

LOC=NCLOC+CLOC

CLOC – linie komentarza programu

NCLOC – linie kodu niekomentarzowe

• liczba linii kodu efektywnego, tj. bez linii komentarza

ELOC – linie efektywne kodu

• liczba bajtów

• liczba stron dokumentacji

• logiczna miara długości

  • liczba instrukcji źródłowych programu

DSI

liczymy bez linii komentarza, ale z deklaracjami i nagłówkami. Może być mniejsza lub większa od LOC

1. Metoda FP

Typy składników systemu:

Informacyjne ILF – wewnętrzny plik logiczny EIF – zewnętrzny plik interfejsu	Funkcyjne EI – zewnętrzne wejście EO – zewnętrzne wyjście EQ – zewnętrzne zapytania

Etapy w metodzie FP:

• obliczanie „niedopasowanych” punktów funkcyjnych

  • wyznaczenie granicy aplikacji

  • klasyfikacja składowych systemu wg typów funkcyjnych

  • ustalenie poziomu złożoności dla każdego składnika danego typu funkcyjnego na podstawie macierzy złożoności

  • obliczenie UFP

• obliczanie wskaźnika poziomu technicznej złożoności

  • ustalenie poziomu i liczby stopni wpływu każdej charakterystyki na podstawie tabeli reguł

  • obliczenie całkowitego stopnia wpływu

DI=Σc_i

i=1,…,14

• obliczenie wskaźnika technicznej złożoności

TCF=0.65+0.01DI

• obliczanie wielkości systemu za pomocą liczby punktów funkcyjnych

FP=UFP*TCF

Wykład 7:

1. Różnica miedzy UCP a FP

• w metodzie UCP mamy dwie grupy czynników złożoności (technicznej i środowiskowej) a w FP tylko jedną (techniczna)

• inne sposoby obliczania poszczególnych elementów

Analizę punktów funkcyjnych można również stosować jako metodę ustalania kosztu testowania systemu informatycznego. Według Capersa^[6] liczba wymaganych przypadków testowych jest równa sumie punktów funkcyjnych podniesionej do potęgi

Punkty funkcyjne liczy się zarówno na etapie tworzenia projektu - dla szacowania czasu wytworzenia oprogramowania, jak również w trakcie realizacji projektu aby można było odpowiednio nim zarządzać.

1. Metoda Albrechta

Założenia metody PF opublikowałam Allan Albrecht w 1979r. Była to próba przezwyciężenia problemów związanych z użyciem liczby linii kody jako miary wielkości oporgramowania i jednocześnie próba opracowania metody przewidzenia wysiłku związanego z produkcją oprogramowania.

Zew. Wejścia
zew. Wyjścia
zew zapytania
pliki wewnętrzne
pliki zewnętrzne

1. Etapy metody COCOMO (nie wzory, ale etapy i który wzór kiedy i od czego zależy)

• oszacowanie nominalnego nakładu ustalonego typu systemu

• obliczenie współczynnika wnioskowania na podstawie ustalonych wielkości współczynników dla każdego z 15-tu sterowników kosztowych

• oszacowanie nakładu pracy w osobomiesiącach

• oszacowanie czasu trwania realizacji

1. Na czym polega metoda trzech punktów (opisać, nie liczyć)

• opracowywanie prognoz dla trzech scenariuszy: optymistyczny, najbardziej prawdopodobny, pesymistyczny

• obliczenie wartości oczekiwanej wg ustalonego rozkładu zmiennej

Wykład 8

1. Cechy charakterystyczne metodyk zwinnych

Cechy:

• ograniczenie liczby dokumentów

• planowanie iteracyjne, w krótszej perspektywie czasowej

• ciągła współpraca z klientem

• otwartość na zmiany

• niewielkie zespoły projektowe

• brak wydzielania faz projektowych

• zdobywanie wymagań za pomocą wykonywalnego kodu

Zalety:

• szybkie wydanie działającego produktu, każda budowa trwa od 2-10 tygodni

• wykonawca i użytkownik bezpośrednio uświadamiają sobie wymagania (kompletność i spójność)

• w dowolnym punkcie procesu tworzenia klient posiada działającą wersję produktu (z ograniczonymi możliwościami)

Nieodpowiednie dla:

• zespołów przekraczających 50 osób

• produktów wykonujących funkcje krytycznego bezpieczeństwa

• kontraktów o ustalonym zakresie

PMI- Project Management Institute (PMI) zaproponował metodykę zarządzania projektami obejmującą dziewięć kluczowych obszarów:

• Zarządzanie integracją projektu

• Zarządzanie zakresem projektu

• Zarządzanie czasem w projekcie

• Zarządzanie kosztami projektu

• Zarządzanie jakością w projekcie

• Zarządzanie ryzykiem projektu

• Zarządzanie zasobami ludzkimi w projekcie

• Zarządzanie komunikacją w projekcie

• Zarządzanie zleceniami w projekcie

PRINCE2 – metodyka zarządzania projektami oparta na produktach. Zastosować ją można do zarządzania i sterowania projektami wszelkiego rodzaju i wszelkiej wielkości.
Właściwości projektu realizowanego według PRINCE2

1. Określony i skończony czas trwania

2. Zdefiniowane i mierzalne produkty biznesowe (wyniki projektu)

3. System działań niezbędnych do budowy produktów biznesowych

4. Określona pula zasobów

5. Struktura organizacyjna z zakresem obowiązków każdej z ról niezbędnej do zarządzania projektem

Normy ISO 9000 są powszechnie uznawane za podstawę budowania systemów zarządzania jakością we wszystkich organizacjach, bez względu na rodzaj ich działalności. Normy te zawierają terminologie, wymagania i wytyczne dotyczące wprowadzania, doskonalenia i kontrolowania systemu zarządzania jakością.

RUP bazuje na zbiorze zasad inżynierii programowania oraz najlepszych praktykach, na przykład:

1. iteracyjnym wytwarzaniu oprogramowania (Iterative Development)

2. zarządzaniu wymaganiami (Requirement Management)

3. używaniu architektury bazującej na komponentach (Component-based architecture)

4. graficznym projektowaniu oprogramowania

5. kontroli jakości oprogramowania (Quality Assurance)

6. procesu kontroli zmian w oprogramowaniu (Change Management)

IEEE: Jest to standard określający formę zbioru 8 dokumentów potrzebnych w każdej z faz testowania oprogramowania. W efekcie każdej z tych faz tworzony jest 1 dokument wynikowy. Standard ten określa dokładnie format dokumentów, jednak nie wymaga, aby wszystkie były wykonane. Nie zawiera także informacji o tym, co dokładnie mają zawierać.

• Test Plan – dokument planowania zarządzania projektem,

• Test Design Specification – szczegóły na temat warunków testowania, oczekiwanych wyników a także kryteriach przejścia testu.

• Test Case Specification – specyfikuje dane testowe do użycia podczas wdrażania warunków testowania określonych w Test Design Specification.

• Test Procedure Specification – zawiera szczegóły na temat przeprowadzenia każdego testu włączając w to założenia oraz poszczególne kroki testów.

• Test Item Transmittal Report – zawiera raporty na temat czasu przejścia testowanych fragmentów oprogramowania między etapami.

• Test Log – zawiera informacje o tym, które przypadki testowania zostały użyte, kto je użył i w jakim porządku oraz informacje o ich powodzeniu.

• Test Incident Report – zawiera informacje o testach zakończonych niepowodzeniem. Informacje o wynikach oraz dlaczego dany test nie powiódł się.

• Test Summary Report – raport ten zawiera wszystkie istotne informacje ujawnione podczas zakończonych testów oraz wyceny jakości procesów testowania, jakości oprogramowania poddanego testowi, a także statystyki uzyskane z Incident Report.
  CRUD – od ang. create, read, update and delete (pol. utwórz, odczytaj, aktualizuj i usuń) - cztery podstawowe funkcje w aplikacjach korzystających z pamięci trwałej, które umożliwiają zarządzanie nią. Niekiedy litera R jest rozwijana jako retrieve (pobierz) zamiast read (odczytaj). Czasem również litera D jest rozwijana jako destroy (zniszcz) zamiast delete (usuń). Skrót ten jest czasem również używany do opisania działań dotyczących oglądania, szukania i zmieniania informacji, często w stosunku do dokumentów elektronicznych.

1. Role w SCRUM

• Właściciel produktu

  • jest właścicielem definicji sukcesu, reprezentuje organizację i interesariuszy projektu

  • kieruje produktem od sprintu do sprintu, aby zapewnić największy zwrot z inwestycji i dostarczyć pewną wartość dla organizacji

  • zarządza ROI poprzez określenie priorytetów oraz publikację planów. Jest jedynym właścicielem zaległości produktu. Określa plan rozwoju projektu poprzez wyznaczanie priorytetów zaległości

  • eliminuje błędy występowania wielu szefów, różnych opinii i zakłóceń

• Mistrz

  • jedna osoba z zespołu wciela się w rolę mistrza – ułatwia codzienną pracę zespołu, nie robi nic innego. Całe jego obciążenie to pełnienie roli Mistrza w pełnym wymiarze czasu

  • Mistrz jest odpowiedzialny za zapewnienie, że zespół żyje wartościami i pracuje zgodnie z regułami metody Scrum

  • jest tarczą zespołu projektowego dla agresywnych klientów, upewniając się, że zespół nie wychodzi ponad zobowiązania aktualnego sprintu

  • mistrz staje się odpowiedzialny za usuwanie wszelkich przeszkód, które zgłaszane są przez zespół podczas spotkań

  • rola mistrza jest zwykle pełniona przez kierownika projektu lub kierownika zespołu technicznego, ale może to być każda osoba z zespołu zarządzania proejktu

• Zespół

  • grupa około 7 interdyscyplinarnych osób, które wykonują prace analityków, projektantów, programistów, testerów …

  • posiada przypisaną odpowiedzialność za dostarczenie produktu

Crystal

Inspiracja pochodziła z metodyk zwinnych, sterowanych planem, a także psychologii i wieloletnich badań autora nad rozwojem organizacji. Twórca (Alistar Cockburn) opisuje ją jako rodzinę metodyk opartych na ludziach, adaptujących się, ultralekkich i dopasowujących się do potrzeb.

Crystal występuje w różnych postaciach w zależności od wielkości zespołu i ryzyka w projekcie. Kryształ (crystal) charakteryzuje kolor i twardość. Każdy z wariantów kolorów (liczba ludzi) ma swoją nazwę:

• Clear,

• Yellow,

• Orange,

• Red.

Warianty twardości (ryzyko) to:

• komfort (Comfort),

• niekluczowe fundusze (Discretionary money),

• kluczowe fundusze (Essential money),

• życie (Life).