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 6

1. Reguły i preferencje grupowania funkcji (ze powstają procesy który działają w trybie interakcji – ekranowe)

Czynniki grupowania:

• sekwencje zależności funkcji

• role użytkowników

• jednostki organizacyjne

• możliwe sposoby realizacyjne

• równowaga pomiędzy złożonością składników a łatwością zrozumienia i możliwościami wdrożenia

Reguły preferencyjne grupowania funkcji w procesy (moduły)

• preferencje ogólne

  • funkcje wykonywane przez jedną jednostkę organizacyjną

  • funkcje przetwarzające te same obiekty i/lub atrybuty

  • funkcje o tym samym wymaganym czasie odpowiedzi

• poziomy preferencji

  • funkcje działające na tych samych obiektach

  • funkcje działające na tych samych obiektach i w ten sam sposób (C,R,U,D,A)

  • funkcje działające na tych samych obiektach i tych samym atrybutach, dokładnie w ten sam sposób

• preferencje użytkownika

  • reguły sterujące działaniami przedsiębiorstwa

Kategorie realizacyjne procesów:

• ekranowy

• wydawniczy

• operatorski

• ręczny

1. Zasady projektowania ekranu

• podział okna na sekcje funkcjonalne

• zależność tematyczna między wywołującymi się oknami

• zasady prezentacji tekstu

  • grupowanie informacji wg zadanego kryterium (tytuły)

  • wyodrębnianie tekstu (wybór czcionki)

• elementy graficzne: obramowania, różne kolory tła (unikać deseni), ikony

• dźwięk do ostrzegania i potwierdzania

• unikanie złożonych elementów graficznych (np. ruchomych)

• przestrzeganie standardowych konwencji kolorowania

1. Projektowanie formularzy papierowych

• kolory – podkreślenie ważności niektórych danych i poprawa czytelności

• dostateczna ilość miejsca w polu

• pola wyboru

• instrukcje wypełniania pól

• ustalenie kolejności i grupowanie pól

• unikanie zbędnych pytań

• formularze samokopiujące

1. Projekt funkcji wydawniczej

• funkcje wyszukujące i przekształcające informacje z bazy danych w celu dostarczenia wiedzy użytkownikowi

• postać raportu zależy od: rodzaju użytkownika, przeznaczenia danych, sposobu korzystania z danych

1. Zasady tworzenia raportu

Podstawowe składniki raportu:

• dane identyfikacyjne: nazwa, krótki opis, data sporządzenia, numer wersji

• prezentowane dane, np. układ tabelaryczny, wykresy, komentarze

• stronicowanie, kontynuacja strony

• zakończenie raportu

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

1. Liczba cyklomatyczna McCaba

2. Miary Halsteada

3. Kryteria dobrej miary

• stosowność – związek z badaną charakterystyką

• dokładność – wierne przedstawienie ilości lub stopnia badanej charakterystyki

• precyzja – wymagany poziom szczegółowości

• rzetelność – zachowanie konsekwencji reguł matematycznych

• opłacalność – wartość informacji nie powinna przekraczać kosztu jej uzyskania

• przewidywalność – możliwość prognozowania przyszłych wielkości

• możliwość kontroli – podejmowane działania mają wpływ na mierzoną wielkość

1. Czynniki wpływające na wielkość nakładów

• wielkość oprogramowania jako produktu

• ogólna charakterystyka oprogramowania, często nazywana czynnikiem technicznej złożoności

• ogólna charakterystyka środowiska projektu, nazywana czynnikiem złożoności środowiska

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. Rodzaje sterowników (atrybuty produktu, komputera, personelu)

• atrybuty produktu

  • RELY – wymagana niezawodność oprogramowania

  • DATA – wielkość bazy danych

  • CPLX – złożoność systemu

• atrybuty komputera

  • TIME – ograniczenie czasu wykonania

  • STOR – ograniczenie pamięci

  • VIRT – wirtualność

  • TURN – czas odpowiedzi

• atrybuty personelu

  • ACAP – kwalifikacje analityków i projektantów

  • AEXP – doświadczenie aplikacyjne

  • PCAP – kwalifikacje programistów

  • VEXP = doświadczenie sprzętowe

  • LEXP doświadczenie w programowaniu

• atrybuty przedsięwzięcia

  • MODP – praktyka w stosowaniu nowego oprogramowania

  • TOOL – stosowanie narzędzi CASE

  • SCED – harmonogramowanie prac

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

1. Czym się charakteryzuje recenzja grupowa

• każdy członek zespołu samodzielnie szacuje fragmenty projektu

• spotkanie grupy w celu omówienia i dyskutowania oszacowań

• obliczenie średniej wielkości oszacowań

• przedyskutowanie wielkości średniej lub przedziałów wielkości

• uzyskanie consensusu – wypracowanie wspólnego oszacowania

1. Czym się charakteryzuje metoda Delphi

Moderator prezentuje każdemu ekspertowi projekt oraz inne znaczące informacje oraz formularz oszacowań. Każdy z ekspertów przygotowuje wstępne oszacowania (przeważnie wartości przedziałowe). Na spotkaniu ekspertów z moderatorem eksperci zadają pytania i dyskutują nad problemami. Następnie eksperci oddają anonimowo swoje indywidualne oszacowania. Moderator przygotowuje z nich podsumowujący raport z wyszczególnieniem indywidualnych estymacji w układzie tabelarycznym, oblicza średnią i przekazuje ekspertom. Eksperci spotykają się i dyskutują nad różniącymi się, anonimowymi oszacowaniami. Eksperci głosują anonimowo nad akceptacją średniego oszacowania. Gdy choć jeden ekspert zagłosuje na „nie” to procedura się powtarza aż grupa dojdzie do consensusu

Końcowe oszacowanie może być jednopunktowe lub przedziałem liczbowym

1. Ocena dokładności metod szacowania

• średnia wielkość błędu względnego

• ocena rzetelności danej metody

1. Czynniki dokładności szacowania nakładów

• dokładność oszacowania wielkości produktu końcowego

• zmienność wymagań wobec produktu

• znajomość metod obliczania kosztów, terminów i nakładów pracy

• uwzględnienie kwalifikacji wykonawców projektu

• stabilność środowiska projektu

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

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

1. Lista zaległości

2. Historyjki użytkownika