Analiza projektowa

(1)

Analiza projektowa

Dr Halina Tańska

Mgr inż. Marek Adamowicz

(2)

Faza określania wymagań

• Celem fazy określenia wymagań jest ustalenie wymagań klienta wobec tworzonego

systemu. Dokonywana jest zamiana celów klienta na konkretne wymagania

zapewniające osiągnięcie tych celów.

• Jest to proces w którym klient wspólnie z

przedstawicielem producenta konstruuje zbiór wymagań zgodnie z postawionymi celami.

Wymaga on dużego zaangażowania ze strony klienta, przyszłych użytkowników systemu i

ekspertów w dziedzinie.

(3)

Trudności określania wymagań

• Klient z reguły nie wie dokładnie, w jaki sposób osiągnąć założone cele (cele klienta mogą być osiągnięte na wiele sposobów).

• Duże systemy są wykorzystywane przez wielu użytkowników. Ich cele są często sprzeczne.

Różni użytkownicy mogą posługiwać się inną

terminologią mówiąc o tych samych problemach.

• Zleceniodawcy i użytkownicy to często inne osoby.

(4)

Poziom ogólności opisu wymagań

• Definicja wymagań to ogólny opis w języku

naturalnym. Opis taki jest rezultatem wstępnych rozmów z klientem.

• Specyfikacja wymagań to częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny, jak i

proste, częściowo przynajmniej sformalizowane notacje.

• Formalna specyfikacja oznacza bardzo dokładne zdekomponowanie wymagań (najlepiej w pewnym

formularzu) na krótkie punkty, których interpretacja nie powinna nastręczać trudności lub prowadzić do

niejednoznaczności. Formalna specyfikacja powinna stanowić podstawę dla fazy testowania.

(5)

Jakość opisu wymagań

Dobry opis wymagań powinien:

• Być kompletny oraz niesprzeczny

• Opisywać zewnętrzne zachowanie się systemu, a nie sposób jego realizacji

• Obejmować ograniczenia, przy jakich musi pracować system

• Być łatwe w modyfikacji

• Brać pod uwagę przyszłe możliwe zmiany wymagań wobec systemu

• Opisywać zachowanie systemu w niepożądanych lub skrajnych sytuacjach.

Uwaga: najbardziej typowy błąd w tej fazie: koncentrowanie się na sytuacjach typowych i pomijanie wyjątków oraz przypadków granicznych.

(6)

Zalecenia dla fazy definicji wymagań

• Wymagania użytkowników powinny być wyjaśniane poprzez krytykę i porównania z istniejącym

oprogramowaniem i prototypami.

• Powinien być uzyskany stan porozumienia pomiędzy projektantami a użytkownikami dotyczący

projektowanego systemu.

• Wiedza i doświadczenie potencjalnej organizacji

podejmującej się rozwoju systemu powinny wspomóc studia nad osiągalnością systemu.

• W wielu przypadkach dużym wspomaganiem jest budowa prototypów.

• Wymagania użytkowników powinny być: jasne,

jednoznaczne, weryfikowalne, kompletne, dokładne, realistyczne, osiągalne.

(7)

Metody rozpoznawania wymagań

• Wywiady i przeglądy – wywiady powinny być

przygotowane (w postaci listy pytań) i podzielone na odrębne zagadnienia (dotyczyć całości tematu i

obejmować reprezentatywną grupę użytkowników).

• Studia nad istniejącym oprogramowaniem –nowe

oprogramowanie zastępuje stare. Należy ustalić dobre i złe strony starego oprogramowania.

• Studia wymagań systemowych – gdy nowy system ma być częścią większego systemu.

• Studia osiągalności – określenie realistycznych celów systemu i metod ich osiągnięcia.

• Prototypowanie – zbudowanie prototypu systemu działającego z uproszczonymi interfejsami.

(8)

Wymagania funkcjonalne

• Opisują funkcje (czynności, operacje) wykonywane przez system.

Funkcje te mogą być także wykonywane przy użyciu systemów zewnętrznych.

• Określenie wymagań funkcjonalnych obejmuje:

• Określenie wszystkich rodzajów użytkowników (interesariuszy), którzy będą korzystać z systemu.

• Określenie wszystkich rodzajów użytkowników, którzy są niezbędni do działania systemu (obsługa, wprowadzanie danych,

administracja).

• Dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z planowanego systemu.

• Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu), które będą wykorzystywane podczas działania systemu.

• Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji itd., które pośrednio lub bezpośrednio

określają funkcje wykonywane przez planowany system.

(9)

Metody specyfikacji wymagań

• Język naturalny

• Formalizm matematyczny

• Język naturalny strukturalny

• Tablice, formularze

• Diagramy blokowe

• Diagramy kontekstowe

• Diagramy przypadków użycia

(10)

Formularz wymagań funkcjonalnych

Nazwa funkcji Edycja dochodów pracownika

Opis Funkcja pozwala edytować łączne dochody podatnika uzyskane w danym roku.

Dane wejściowe Informacje o dochodach pracowników uzyskanych z różnych źródeł:

kwoty przychodów, koszty uzyskania przychodów oraz zapłaconych zaliczek na poczet podatku dochodowego. Informacje o dokumentach opisujących dochody z poszczególnych źródeł.

Źródło danych wejściowych Dokumenty oraz informacje dostarczone przez podatnika.

Wynik Dane wpisane przez pracownika firmy podatkowej.

Warunek wstępny Kwota podatku = kwota przychodu – kwota kosztów (zarówno dla konkretnych dochodów, jak i dla łącznych dochodów podatnika).

Łączne kwoty przychodów, kosztów uzyskania dochodów oraz zapłaconych zaliczek są sumami tych kwot dla dochodów z poszczególnych źródeł.

Warunek końcowy Jak wyżej.

Efekt uboczne Uaktualnienie podstawy opodatkowania.

Powód Funkcja pomaga przyśpieszyć obsługę klientów oraz zmniejszyć ryzyko popełnienia błędów.

W formularzach zapis jest podzielony na konkretne pola, co pozwala na: łatwe stwierdzenie kompletności opisu, jednoznaczną interpretację.

(11)

Porządkowanie wymagań

Hierarchia wymagań funkcjonalnych: z reguły funkcje można rozbić na podfunkcje.

Zaleca się:

• Ten sam poziom szczegółowości na każdym poziomie.

• Kolejność funkcji nie ma znaczenia.

• Niektóre funkcje mogą być wykonywane wielokrotnie.

• Wyszczególniać tylko funkcje widoczne dla użytkowników.

(12)

Hierarchia wymagań funkcjonalnych

W ten sposób można dekomponować funkcje do dowolnego poziomu (podejście top- down). Możliwe jest również podejście odwrotne (bottom-up), kiedy składamy kilka funkcji bardziej elementarnych w jedną funkcję bardziej ogólną.

Funkcja f1

Funkcja f1.1 Funkcja f1.2 Funkcja f1.3

Funkcja f1.1.1

Funkcja f1.1.2

Funkcja f1.1.3

Funkcja f1.2.1

Funkcja f1.2.2

Funkcja f1.2.3 Funkcja f1.3.3 Funkcja f1.3.3 Funkcja f1.3.3

(13)

Przykład: program podatkowy

• Program ułatwia przygotowanie formularzy zeznań podatkowych (PIT-ów) oraz przechowywanie informacji o źródłach przychodów i ulg. Zeznanie może być tworzone przez pojedynczego podatnika lub małżeństwa.

Zeznania mogą obejmować informacje o rocznych przychodach (w przypadku małżeństwa z podziałem na przychody męża i żony) oraz o ulgach podatkowych. Przychody podzielone są na klasy ze względu na źródło uzyskania, np. pozarolnicza działalność gospodarcza, wolny zawód itd. W ramach danej klasy przychodów podatnik mógł osiągnąć szereg przychodów z różnych źródeł.

• Wszystkie przychody opisane są przez kwotę przychodu, kwotę kosztów, kwotę zapłaconych zaliczek oraz kwotę dochodu. Powyższe informacje pozwalają obliczyć należny podatek oraz kwotę do zapłaty lub zwrotu.

Zeznanie zawiera także informacje o podatniku oraz adres urzędu skarbowego.

• System pozwala wydrukować wzorzec zeznania zawierający wszystkie informacje, jakie podatnik musi umieścić w formularzu. Zeznanie można zabezpieczyć przed dalszymi zmianami (po złożeniu w urzędzie

skarbowym. System pozwala na tworzenie listy podatników oraz urzędów skarbowych, które mogą być pomocne przy tworzeniu nowego zeznania.

Przechowuje też informacje o wszystkich złożonych zeznaniach.

(14)

Ewidencja podatników

Ewidencja Urzędów Skarbowych Ewidencja zeznań podatkowych

Dodawanie zeznania Usuwanie zeznania

Zabezpieczanie zeznania Edycja zeznania

Edycja informacji o przychodach Edycja informacji o ulgach

Wyświetlanie rozliczenia Wydruk zeznania

Przeglądanie zeznania (bez możliwości zmiany ) Program podatkowy: hierarchia funkcji

(15)

Przykład: system harmonogramowania zleceń

• Zlecenia dla wydziału przygotowywane są przez dział marketingu.

Zlecenie oznacza konieczność wyprodukowania konkretnej ilości pewnego wyrobu przed upływem konkretnego terminu. Czasami może być określony najwcześniejszy pożądany termin realizacji.

Dział marketingu wykorzystuje własny system informatyczny, w którym między innymi umieszczane są informacje o zleceniach, pożądane jest więc, aby system harmonogramowania zleceń automatycznie odczytywał te informacje.

• Wyprodukowanie danego wyrobu (realizacja zlecenia) wymaga wykonania ciągu operacji. Pewne operacje mogą być wykonywane tylko na jednym urządzeniu; w innych przypadkach możliwe jest wykorzystanie kilku maszyn, które mogą różnić się efektywnością pracy. Po wykonaniu pewnych operacji może być konieczna

przerwa, zanim rozpocznie się realizacja następnych; z drugiej strony taka przerwa może trwać przez ograniczony czas.

Przestawienie maszyn na inne operacje może wymagać czasu. Co pewien czas (np. raz na miesiąc) ustalany jest harmonogram

niezrealizowanych zleceń.

• System powinien opracować harmonogramy w formie łatwej do wykorzystania przez kadrę kierowniczą wydziału oraz

przygotowywać zamówienia do magazynu na półprodukty. Zlecenia wykonane są usuwane ze zbioru niezrealizowanych zleceń.

(16)

Zarządzanie zleceniami (ogólna funkcja systemu)

Edycja zleceń

Przygotowanie zamówień na półprodukty Przygotowanie kart zadań Edycja technologicznego

opisu wydziału Harmonogramowanie zleceń Edycja opisu maszyn

Edycja opisu operacji Edycja opisu wyrobów

Sprawdzanie kompletności opisu

Wydruk informacji technologicznych

Ustalanie harmonogramu Edycja harmonogramu Graficzna prezentacja harmonogramu

Wydruk harmonogramu

Wczytywanie informacji o zleceniach

Wyświetlanie informacji o zleceniach

System harmonogramowania zleceń: funkcje

(17)

Przykład: system informacji geograficznej - SIG

• SIG jest rodzajem mapy komputerowej,

składającej się z tła (np. mapy fizycznej) oraz

szeregu obiektów graficznych umieszczonych na tym tle. Obiekt może być punktem (budynek,

firma), linią (rzeka, kolej) lub obszarem (park, osiedle).

• Każdy obiekt ma swoją nazwę i ewentualny opis, który może być wyświetlony na żądanie

użytkownika. Obiekt można opisać szeregiem słów kluczowych.

• Użytkownik ma możliwość wyświetlenia tylko tych obiektów, które opisano słowami

kluczowymi.

(18)

Zarządzanie SIG (ogólna funkcja systemu)

Przeglądanie SIG Projektowanie SIG

Wyświetlanie mapy (różnych obszarów w różnym powiększeniu

Wybór/pomijanie słów kluczowych Wyświetlanie opisu obiektu

graficznego

Edycja tła

Edycja obiektów graficznych Dodawanie obiektów Edycja obiektów Tworzenie obiektu Edycja słów kluczowych

Dodawanie słowa kluczowego Edycja słowa kluczowego Usuwanie słowa kluczowego Przeglądanie SIG (kopia)

Hierarchia funkcji dla SIG

(19)

uc Use Case M odel

użytkow nik

w yśw ietlenie mapy

w ybór pomij anie słów kluczow ych

w yśw ietlenie opisu obiektu graficznego

proj ektant

edycj a tła

edycj a słów kluczow ych

edycj a obiektów graficznych

dodaw anie obiektu

edycj a obiektu

usuw anie obiektu

dodaw anie słow a kluczow ego

edycj a słow a kluczow ego

usuw anie słow a kluczow ego

«extend» «extend»

«extend»

Diagram przypadków użycia dla SIG

Metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić role wielu aktorów; np. być jednocześnie projektantem i osobą przeglądającą mapę.

(20)

Wymagania niefunkcjonalne

• Opisują ograniczenia, przy których system ma realizować swoje funkcje.

• Wymagania dotyczące produktu

• Wymagania dotyczące procesu

• Wymagania zewnętrzne

(21)

Formularz zapisu wymagań

Nr Data

wprowadzenia Rozmówca Wymaganie Motywacja Uwagi (obligato ryjne/opc jonalne) 1. Należy podać

datę

uzgodnienia wymagania

Należy podać, kto zgłasza wymaganie

Sformułowa nie

wymagania

Dlaczego to

wymaganie jest istotne

(22)

Dokument wymagań

• Wymagania powinny być zebrane w dokumencie – opisie wymagań.

• Dokument ten powinien być podstawą

szczegółowego kontraktu między klientem a producentem oprogramowania.

• Powinien także pozwalać na weryfikację stwierdzającą, czy wykonany system

rzeczywiście spełnia postawione wymagania.

• Powinien to być dokument zrozumiały dla obu stron.

(23)

Uniwersalne techniki prezentacji wyników analizy

• Techniki tradycyjne, tabelaryczne i graficzne przedstawienie analizy, ściśle zorientowane na procedury załatwiania spraw,

• Nowoczesne techniki graficzne;

przedstawianie pewnego postępowania, które przebiega stopniowo, etapami i opisuje albo procedury, albo struktury danych; diagramy przepływów danych, diagram klas.

(24)

Tradycyjne techniki prezentacji

• Dla struktur organizacyjnych: organigramy

• Dla procedur pracy: schematy działań, schematy blokowe, sieci

• Dla opisu przebiegów przetwarzania: schematy blokowe, tablice decyzyjne

• Dla opisu procesów uwarunkowanych czasowo:

schematy sieciowe

• Dla układów ilościowych: tabele, grafiki

• Dla opisu przebiegu procesów biznesowych:

schematy działań, automaty skończone.

(25)

Schemat sieci działań

W tabeli przedstawia się wykaz czynności

(sekwencyjnie), wykaz komórek organizacyjnych, a na ich przecięciu czynności (działania), które podjęto w trakcie obsługi danego procesu biznesowego.

Przedstawiona została pewna procedura obsługi klienta od przyjęcia zlecenia do wystawienia rachunku, łącznie z zaksięgowaniem rachunku. Procedurę tę przedstawiono w układzie czynności do wykonania i komórek

organizacyjnych, które dane czynności wykonują.

Czynność zostaje opisana przez krótko sformułowane zadanie oraz rozstrzygnięcie (T/N). W opisywanym procesie biznesowym współuczestniczą trzy komórki działu zbytu (sprzedawca, sekretarka, fakturzystka), dział spedycji oraz dział księgowości. Na schemacie przedstawiono zadania które te komórki mają do

wykonania.

(26)

Schemat sieci działań

Czynności

ZBYT SPEDYCJA/

WYSYŁKA KSIĘGOWOŚĆ SPRZEDAWCA SEKRET FAKT

1. Przyjęcie zlecenia

2. Możliwa realizacja?

3. NIE:

Pismo odnotowane

4. Napisać pismo

5. TAK:

Dane do rachunku

6. Napisać

rachunek

7. Rozdział kopii

rachunku 1. Kopia + oryginał

8. Kompletacja

przesyłki 2. kopia

9. Zaksięgowanie

rachunku

(27)

Logiczne tablice decyzyjne

Jedna z najstarszych form przedstawiania problemów decyzyjnych w ujęciu schematycznym, z zastosowaniem dwuwartościowej logiki. Analizowaną procedurę

przedstawimy w układzie czterech elementów:

warunków, akcji, reguł, miejsc występowania akcji.

Warunki przedstawiają krótkie pytania do

rozstrzygnięcia. Akcje opisują czynności, które należy wykonać w danej procedurze. Pola reguł opisują

jednoznaczne odpowiedzi – rozstrzygnięcia (T/N). Pola akcji zawierają miejsca określające, gdzie dana akcja wystąpi w zależności od układu pól reguł.

(28)

Schemat funkcjonalny LTD

TABLICA REGUŁY

Warunki Pole reguł

Akcje Pole akcji

(29)

Przykład LTD: prezenty dla klientów

• Na schemacie zostanie przedstawiona tablica LTD opisująca reguły wysyłania upominków noworocznych klientom

pewnej firmy. Zdefiniowano przy tym

pewne warunki, które mają obowiązywać przy wyborze jakiego rodzaju upominek ma zostać wysłany, w zależności od

indywidualnych preferencji klienta.

(30)

Przykład LTD: prezenty dla klientów

WARUNKI R6 R11 R12 R13 R14

0 < OBR < 10T T N N N N

10T < OBR < 20T N T T N N

OBR > 20T N N N T T

PRZECIWN. ALKOHOLU - T N T N

Karta z życzeniami X X X X X

Wino X X

Prezent książkowy X X

Rozmowa telefoniczna X X

(31)

Notacja Martina

• Za pomocą notacji Martina można budować diagramy dekompozycji procedur zarządzania, korzystając w różnych symboli specyficznych dla tej notacji.

• Węzły w układzie „ojciec – syn”, kolejność od lewa do prawa (default). Można określić strzałkami przebieg wykonywania zadań:

- symbol kropka oznacza warunek np. Export (opcjonalnie) , np.

odprawa celna będzie następowała tylko w przypadku towaru eksportowego,

- symbol kurza stópka oznacza wielokrotność występowania danej operacji,

- symbol kreska-kropka-kreska oznacza powiązanie lub, np. w zależności od rodzaju przesyłki (zapakować) może być ona przemieszczana koleją, pocztą, za pośrednictwem spedytora.

(32)

Przykład schematu w notacji Martina

Przygotowanie wysyłki

Przechowywanie

wysyłki odprawa celna zapakować

pobrać produkt

kontrola

poczta kolej spedytor

(33)

Drzewa decyzyjne

• Czasami zachodzi potrzeba przedstawienia struktury

decyzji, szczególnie decyzji rutynowych podejmowanych wielokrotnie według stałego schematu. Bardziej

przejrzystą formą do zaprezentowania takich decyzji są drzewa decyzyjne. Drzewo decyzyjne opisuje zawsze pewną sekwencję decyzji. Pień drzewa przedstawia punkt wyjścia tej sekwencji. Gałęzie reprezentują każdorazowo pewną serię decyzji, które są

podejmowane w kolejności opisanej struktury drzewa.

Liście drzewa reprezentują pewne czynności, które realizowane są kolejności opisanej decyzjami.

(34)

Schemat drzewa decyzyjnego

0 < OBR < 10T

10 < OBR < 20T

OBR > 20T

Karta życzenia Przeciwnik

alkoholu

Nie

Przeciwnik alkoholu

Karta życzenia

Karta życzenia Książka

Wino

Przeciwnik alkoholu

Nie

Przeciwnik alkoholu

Książka Telefon

Wino Telefon

(35)

Faza analizy

• Celem fazy analizy jest ustalenie wszystkich czynników lub warunków w dziedzinie

przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach komputerowych, które mogą

wpłynąć na decyzje projektowe na przebieg procesu projektowego i na realizację

wymagań. Wynikiem jest plan realizacji projektu, opisujący sposób realizacji przez system postawionych wymagań, lecz

abstrahując od szczegółów implementacyjnych.

(36)

Dziedzina problemu Model analityczny

Zakres

odpowiedzialności systemu

Model analityczny

Model analityczny najczęściej wykracza poza zakres odpowiedzialności systemu.

(37)

Cechy modelu analitycznego (logicznego)

• Uproszczony opis systemu

• Hierarchiczna dekompozycja funkcji systemu

• Model logiczny jest opisywany za pomocą notacji zgodnej z pewną konwencją

• Jest on zbudowany przy użyciu dobrze rozpoznanych metod i narzędzi

• Jest on używany do wnioskowania o przyszłym oprogramowaniu.

Model oprogramowania powinien być jego uproszczonym opisem, opisującym wszystkie istotne cechy oprogramowania na wysokim poziomie abstrakcji. Model ten nie zastępuje doświadczenia i

wnikliwości projektantów.

Logiczny model oprogramowania:

• Pokazuje co system musi robić

• Jest zorganizowany hierarchicznie, według poziomów abstrakcji

• Unika terminologii implementacyjnej

• Pozwala na wnioskowanie „od przyczyny do skutku”

(38)

Czynności w fazie analizy

• Rozpoznanie, wyjaśnianie, modelowanie,

specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu

• Ustalenie kontekstu projektu

• Ustalenie wymagań użytkowników

• Ustalenie wymagań organizacyjnych

• Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych itd.

Uwaga: analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych

elementów np. w postaci systemu komputerowego. Jej celem jest rozpoznanie wszystkich tych aspektów

rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu.

(39)

Tematy i techniki analizy

• Budowa statycznego modelu klas

• Analiza funkcji i przypadków użycia

• Weryfikacja klas i obiektów

• Identyfikacja i definiowanie metod oraz komunikatów

• Modelowanie stanów i przejść między stanami

• Modelowanie procesów i przepływów danych

• Modelowanie przepływu sterowania

• Inne

(40)

Wymagania na oprogramowanie

W trakcie analizy wymagania użytkownika są przekształcane w wymagania na oprogramowanie. Mogą one dotyczyć:

• Funkcji systemu

• Wydajności systemu

• Zewnętrznych interfejsów

• Wykonywanych operacji

• Wymaganych zasobów

• Sposobów weryfikacji

• Sposobów testowania

• Dokumentacji

• Ochrony

• Przenośności

• Jakości

• Niezawodności

• Pielęgnacyjności

• Bezpieczeństwa

Uwaga: wymagania niefunkcjonalne powinny być skojarzone z funkcjonalnymi.

(41)

Reguły modelu logicznego

• Funkcje muszą mieć pojedyncze zdefiniowane cele

• Funkcje powinny być zdefiniowane na tym samym poziomie

• Interfejsy do funkcji (wejście i wyjście) powinny być minimalne.

Pozwala to na łatwiejsze oddzielenie poszczególnych funkcji

• Przy dekompozycji funkcji trzymać się zasady „nie więcej niż 7 funkcji podrzędnych”

• Opis funkcji nie powinien odwoływać się do pojęć i terminów implementacyjnych

• Należy podać wskaźniki wydajnościowe funkcji (szybkość, częstość) wszędzie tam, gdzie to możliwe

• Powinny być zidentyfikowane funkcje krytyczne

• Nazwy funkcji powinny odzwierciedlać ich cel i mówić co ma być zrobione, a nie jak ma być zrobione

• Nazwy funkcji powinny mieć charakter deklaracyjny.

(42)

Kluczowe czynniki sukcesu fazy analizy

• Zaangażowanie właściwych osób ze strony klienta

• Kompleksowe i całościowe podejście do problemu, nie koncentrowanie się na partykularnych jego aspektach

• Nieunikanie trudnych problemów (bezpieczeństwo,

skalowalność, szacunki objętości i przyrostu danych itd.)

• Zachowanie przyjętych standardów

• Sprawdzenie poprawności i wzajemnej spójności modelu

• Przejrzystość, logiczny układ i spójność dokumentacji.

(43)

Podstawowe rezultaty fazy analizy

• Poprawiony dokument opisujący wymagania

• Słownik danych zawierający specyfikację modelu

• Dokument opisujący stworzony model, zawierający:

– Diagram klas

– Diagram przypadków użycia

– Diagram sekwencji komunikatów (dla wybranych sytuacji) – Diagram stanów (dla wybranych sytuacji)

– Raport zawierający definicje i opisy klas, atrybutów, związków, metod itp.

• Wstępne przypisanie ludzi i zespołów do zadań.

• Ramowy harmonogram projektu

(44)

Cele i ograniczenia

Definiowanie zadań i pakietów prac

Szacowanie czasu realizacji

Ocena zasobów Sekwencja

zadań

Harmonogram Scalanie planu

Co?

Jak długo?

W jakiej kolejności?

Kto i za ile?

Kto i czym?

Co i kiedy?

Proces planowania

(45)

Struktura podziału prac (Work Breakdown Structure -WBS ):

• Pokazuje na jakie części można podzielić projekt

• Wspomaga proces budowania zespołu

• Pozwala przemyśleć całość projektu

• Jest fundamentem dalszych operacji planistycznych

• Nigdy nie jest prawidłowy lub nieprawidłowy; Nigdy nie jest prawidłowy lub nieprawidłowy;

może być kompletny bądź niekompletny może być kompletny bądź niekompletny

Plan struktury podziału prac Plan struktury podziału prac

projektu projektu

(46)

Cel Projektu

Cel Cząstkowy 1 Kamień milowy

Pakiet roboczy 1.1

Pakiet roboczy 1.2

Pakiet roboczy 3.1

Pakiet roboczy 3.2

Pakiet roboczy 2.1

Pakiet roboczy 2.2

Pakiet roboczy 2.3

Budowa planu struktury WBS Budowa planu struktury WBS

(47)

Informatyzacja firmy ALFA

Wybór

systemu Przygotowanie

wdrożenia Wdrożenie

Ustanowienie kierownictwa

projektu

Zorganizowani e biura projektu

Kompletowanie zespołu

Przygotowanie wymagań funkcjonalnych

Rozstrzygnięcie przetargu

Budowa prototypu

Przygotowanie szczegółowego planu wdrożenia

Zatwierdzenie Planu Wdrożenia

Odbiór prototypu

WBS

(48)

Id. Nazwa zadania

1 Informatyzacja firmy ALFA

2 Wybór systemu

3 Ustanowienie kierownictwa projektu

4 Zorganizowanie Biura Projektu

5 Kompletowanie zespołu

6 Przygotowanie wymagań funkcjonalnych

7 Rozstrzygnięcie przetargu

8 System wybrany

9 Przygotowanie wdrożenia

10 Budowa prototypu

11 Przygotowanie szczegółowego planu wdrożenia

12 Zatwierdzenie planu wdrożenia

13 Odbiór prototypu

14 Wdrożenie przygotowane

15 Wdrażenie

MA

05-03 2 kwartał

WBS katalogowy

(49)

• Estymacja to ilościowe oszacowanie nieznanych parametrów projektu, niezbędnych do planowania

• Do estymacji wykorzystujemy estymatory – są to zwykłe wzory, przedstawiające relacje między pewnymi wielkościami

• Wyniki estymacji (estymaty) są wielkościami obciążonymi niepewnością – błędami oszacowania

• Błędy estymacji ujawniają się dopiero podczas realizacji projektu (ocena expost)

• Źródła błędów estymacji:

– Błędne założenia dotyczące zasobów i zakresu prac – Niewłaściwa metoda estymacji i błędy proceduralne

– Nieprzewidziane okoliczności (złe zarządzanie ryzykiem) – Istotne zmiany w projekcie

– Brak dostatecznych danych historycznych

Estymacja w procesie planowania

(50)

Zastosowanie estymacji

• Pracochłonność zadań (nakłady pracy)

• Czas realizacji zadań

• Parametry zasobów

– Ludzie (ilość, kwalifikacje, dostępność, wydajność) – Sprzęt (ilość, wydajność, dostępność)

– Materiały (ilość, jakość, dostępność)

• Czas nieprodukcyjny

• Koszty

– Bezpośrednie – Pośrednie

Estymacja nie jest wysiłkiem jednorazowym; dokonuje się jej wielokrotnie przez cały cykl życia projektu

(51)

• Analogia z innymi projektami

• Szacunki eksperckie

• Oceny dostawców

• Doświadczenia członków zespołu

• Stanowisko „otoczenia politycznego”

• Posługiwanie się średnią ważoną czasu trwania

Szacowania nakładów pracy Szacowania nakładów pracy

(52)

T=[a+4*m+b]/6

T – czas szacowany

a – najbardziej optymistyczny czas wykonania m – najbardziej prawdopodobny czas wykonania b – najbardziej pesymistyczny czas wykonania

Średnia PERT

(53)

Uwaga na „efekt chiński”

• Jeden pracownik wykopie 1 metr sześcienny ziemi w ciągu 8 godzin

• Dwóch pracowników powinno to zrobić w 4 godziny

• Dwudziestu pracowników wykopie metr sześcienny w 0,4 godziny

• Dwa tysiące zrobi to w 0,004 godziny, czyli w 14,4 sek.

Takie wyniki estymacji można otrzymać posługując się

programami komputerowymi wspomagającymi planowanie projektów, jeżeli nie ustawi się właściwych opcji

Estymacja czasu realizacji

(54)

W D

T P

 *

T – czas realizacji

P – pracochłonność (nakład pracy) D – dostępność zasobu

W – wydajność zasobu

Przykład:

• Oszacowano pracochłonność zadania na 200 godzin

• Do wykonania przydzielono jednego pracownika, który może pracować przy tym zadaniu po 4 godziny w każdym 8 godzinnym dniu pracy. Dostępność pracownika wynosi więc 0,5.

• Wydajność zależną od kwalifikacji oceniono na 80%

T=200/(0,5*0,8)=500 godzin = 62,5 dni roboczych

(55)





W D

T P

min *

dla kilku wykonawców jednocześnie

P – pracochłonność (nakład pracy)

Dmin – dostępność najmniej dostępnego zasobu W – wydajność zasobu

Przykład:

• Do wykonania przydzielono trzech pracowników o dostępności kolejno: 60%, 70%, 40% i wydajności:

80%,90% i 90%

• Pracownicy bardziej dostępni mogą zawsze pracować, gdy może pracować pracownik najmniej dostępny.

T=200/0,4*(0,8+0,9+0,9)=192 godzin = 24 dni robocze

(56)

 





W D

T P

*

dla kilku wykonawców niezależnych

P – pracochłonność (nakład pracy) D – dostępność zasobu

W – wydajność zasobu

Przykład:

• Do wykonania przydzielono trzech pracowników o dostępności kolejno: 60%, 70%, 40% i wydajności: 80%,90% i 90%

T=200/(0,6*0,8+0,7*0,9+0,4*0,9)=136 godzin = 17 dni roboczych

(57)

• W zależności od sposobu podejścia do czasów realizacji zadań ich sekwencji, budowę harmonogramu można prowadzić z

wykorzystaniem kilku metod.

• Klasyczną metodą są harmonogramy Gantta

• Zarządzanie projektami wykorzystuje również metody sieciowe:

– CPM (Critical Path Method)

– MPM/PDM (Metra Potential Methode/Precedence Diagraming Method) – PERT (Program Evoluation and Reviev Technique).

• Coraz częściej wykorzystuje się metody Teorii Ograniczeń (Theory of Constraints).

Analiza czasowa projektu

Czasy realizacji zadań Deterministyczne Losowe

CPM PERT

CCPM

(58)

Id. Nazwa zadania

1 Ustanowienie kierownictwa projektu 2 Zorganizowanie Biura Projektu 3 Kompletowanie zespołu

4 Przygotowanie wymagań funkcjonalnych

5 Wybór sysytemu

6 System wybrany

7 Budowa prototypu

8 Przygotowanie szczegółowego planu wdrożenia 9 Zatwierdzenie planu wdrożenia

10 Odbiór prototypu 11 Wdrożenie przygotowane

12 Wdrażenie

13 System wdrożony

cze lip sie wrz paź lis gru sty lut mar kwi maj cze lip sie wrz paź lis gru sty lut mar kwi maj cze lip sie wrz paź lis gru sty lut 2 kwartał 3 kwartał 4 kwartał 1 kwartał 2 kwartał 3 kwartał 4 kwartał 1 kwartał 2 kwartał 3 kwartał 4 kwartał 1 kwartał

Harmonogram Gantta Harmonogram Gantta