WYKŁAD 1

• Inżynieria oprogramowania (IEEE - Instytut Inżynierii Elektryków i Elektroników)

Dziedzina wiedzy zajmująca się badaniem procesu i opracowywaniem metod i narzędzi wytwarzania oprogramowania komputerowego.

• Zastosowanie:

• systematycznego,

• zdyscyplinowanego,

• poddającego się ocenie ilościowej

• podejścia do

• wytwarzania,

• użytkowania,

• i pielęgnacji oprogramowania.

• Warstwy inżynierii oprogramowania

• Zapewnienie jakości

• Proces wystwórczy

• Metody

• Narzędzia

• Podstawowe cechy projektu

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 przyczyny dla której rozpoczęto projekt

Stopniowe doprecyzowywanie - 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

• Projekt a przedsięwzięcie

Projekt - przedsięwzięcie podejmowane w celu wytworzenia unikalnego produktu lub dostarczenia unikalnej usługi

Projekt [PMI] - tymczasowe postanowienie działania w kierunku tworzenia unikalnego produktu lub usługi z określonym początkiem i końcem, powtarzalnymi operacjami i wymaganym, postępującym opracowywaniem odpowiednich charakterystyk

• Projekt a działalność operacyjna

• Różnice

• 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

• Cechy wspólne

• podlegają planowaniu, realizacji i kontroli

• wykonywane przez ludzi

• ograniczony limit dostępnych zasobów

• Przedsięwzięciem informatycznym może być:

Zamierzenie tworzenia/ rozwoju/ wdrożenia systemu informatycznego.

• Produkt informatyczny

• dedykowany klientowi wraz z dokumentacją, która opisuje, jak go zainstalować i jak go używać

• wyrób niematerialny, traktowany jako wytwór intelektualny

• Zarządzanie projektami

• Jako dziedzina wiedzy dotycząca

• zasad, metod i technik efektywnego planowania, harmonogramowania, kontrolowania i śledzenia prowadzonych prac,

• które pomagają w zapewnieniu uzyskania historycznych, solidnych podstaw do planowania przyszłych projektów.

• Jako działalność polega na

• stosowaniu wiedzy, umiejętności, metod i narzędzi podczas realizacji zadań projektu, ukierunkowanych na oczekiwane wyniki.

• Zarządzanie projektami [Kerzner]

• Planowanie

• organizowanie

• kierowanie

• kontrolowanie

zasobów organizacji przydzielonych do konkretnego projektu dla zapewnienia osiągnięcia jego celów.

• Struktura organizacyjna projektu

• WARSTWY ZARZĄDZANIA PROJEKTEM

• zarząd organizacji (organizacja lub zarząd)

• wypracowanie strategii

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

• wyznaczenie rady projektu do działania w ustalonych ograniczeniach

• rada projektu / komitet sterujący PRINCE

• 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łnienia wymagań przez produkt

• kierownik projektu

• planowanie, monitorowanie, kontrola

• w większych projektach podejmowanie decyzji:

• finansowych,

• w zakresie specyfikacji wymagań, zasobów, akceptacji produktów

• kierownik (realizacyjny) 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:

• rozproszenie geograficzne personelu

• duża liczba osób

• różne etapy prac, osoby z różnymi umiejętnościami

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

• LICZBA WARSTW I ZESPOŁÓW ZALEŻY OD:

• wielkości i kosztu przedsięwzięcia

• technicznej złożoności produktu (trudności)

• znaczenia przedsięwzięcia

• dostępności personelu

• Kierownik komitetu klientów

• współorganizacja projektu,

• prowadzenie i gromadzenie dokumentacji,

• zapewnienie warunków pracy zespołów realizacyjnych,

• realizacja zatwierdzonych zmian,

• zgłaszanie problemów

• przyjęcie produktu do użytkowania

• Podstawowe role w przedsięwzięciu informatycznym

• sponsor/klient

• użytkownik

• kierownik przedsięwzięcia/zespołu

• specjalista ds. jakości, ryzyka

• Role techniczne:

1. analityk

2. projektant

3. programista

4. administrator

5. dokumentalista

• Sponsor

• 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

• 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

• Biuro Projektu

• Role BP: „policjant”, „asystent”, „doradca”

• Kto potrzebuje BP

• zarząd

• jednostki organizujące audyty, kontrole wewnętrzne

• sponsor projektu

• kierownik projektu

• kierownik jednostki organizacyjnej

• Interesariusze (udziałowcy) projektu

Osoby i organizacje aktywnie zaangażowane lub powiązane z realizacją lub zakończeniem projektu

- sponsor (gestor) - właściciel projektu

- kierownik projektu - odpowiedzialność za osiągnięcie celów i codzienne zarządzanie

- klient, użytkownik

- organizacja realizująca projekt

- członkowie zespołu realizującego projekt

- inni: dostawcy, instytucje rządowe, stowarzyszenia, ...

• 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

• projektant wraz z analitykiem generuje projekt systemu

• budowa porozumienia między analitykami i programistami:

- na wejściu projektant otrzymuje wyniki analizy

- wyniki projektowania stanowią wejście dla programisty

• wprowadzenie zmian projektowych w wyniku zidentyfikowanych potrzeb zmian

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

• Programista

• pisanie programu w określonym języku (dokładna implementacja specyfikacji wymagań)

• wstępne testowanie

• implementacja ustalonych zmian

• Tester

• Sprawdzenie działania systemu w odniesieniu do specyfikacji wymagań

- weryfikacja kompletności

- weryfikacja zgodności

• Poziomy testowania

- testowanie jednostki

- testowanie integracji

- testowanie systemu

• Zapewnienie poprawności działania systemu na dotychczasowym poziomie po wprowadzeniu zmian

• Szkoleniowiec

• Prezentacja działania systemu

• Szkolenie w zakresie korzystania z systemu

• Szkolenie w zakresie wprowadzonych zmian do systemu

• Dokumentalista

• Przygotowanie i przechowywanie dokumentów wykorzystywanych podczas cyklu życia systemu

- Specyfikacja wymagań

- Opis projektu

- Dokumentacja programu

- Podręcznik szkoleniowy

- Plany testów

- Współpraca z zespołem zarządzania konfiguracją

• Zespoły zadaniowe

• Kluczowe

- analityków

- projektantów

- programistów

• Wspierające

- ds. jakości

- kontroli zmian

- zarządzania konfiguracją

- szkoleń

- akceptacyjny

-administracyjny

• Macierz podziału obowiązków:

U - uczestnik, O - odpowiedzialny, W - weryfikujący, E - ekspert, Z - zatwierdzający

• Składniki zintegrowanego planu projektu

• karta projektu

• deklaracja zakresu projektu

• struktura podziału pracy

• szacowane koszty

• plany bazowe

• kamienie milowe

• kluczowy personel

• plan zarządzania ryzykiem, zakresem, harmonogramem, kosztami ...

• otwarte kwestie

• dane uzupełniające

• Zakres produktu i 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

• Planowanie zakresu projektu

• Proces stopniowego (iteracyjnego) uszczegóławiania i dokumentowania prac projektu prowadzących do wytworzenia wyniku projektu - produktu końcowego

• Doprecyzowanie zakresu - podział głównych produktów cząstkowych, pośrednich na mniejsze

(struktura WBS)

• WBS (Work Breakdown Structure)

• Struktura podziału pracy definiuje pracę do wykonania w celu ukończenia projektu

• Stanowi zestawienie składników projektu ze względu na jego główne produkty cząstkowe

• Podstawa do

• szacowania kosztów

• planowania zasobów

• definiowania zadań

• zarządzania ryzykiem

• Podejście do tworzenia WBS

• zstępujące: od uogólnienia do szczegółów, od celu projektu do pojedynczych zadań

• wstępujące: od szczegółów do uogólnienia, od zadań do celu

• Pojęcia WBS

• składnik pracy - dyskretny wynik pracy (produkt lub usługa) lub agregacja logicznie

zgrupowanych wyników

• poziom WBS - lokalizacja składnika pracy w hierarchicznej strukturze, unikalny numeryczny kod składnika pracy

• pakiet roboczy - wynik pracy na najniższym poziomie WBS, główny punkt zarządzania WBS (np. planowanie zasobów, zapewnianie jakości)

• konto kosztowe - sumaryczny składnik pracy o jeden poziom wyżej niż pakiet (jeden lub kilka pakietów), określany jako punkt kontrolny

• gałąź - wszystkie składniki pracy poniżej poziomu 0, gałęzie mogą mieć różne długości

• Rodzaje WBS

• Kryterium definiowania pierwszego poziomu

- cykl życia projektu - fazowy

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

- lokalizacja wykonawców - organizacyjny

- poziom sprawozdawczości - kontraktowy

• W praktyce istnieją mieszane rodzaje, nawet na tym samym poziomie (kultura, przyzwyczajenie)

• Dekompozycja WBS

• Zasada dekompozycji: zachowanie kontekstu rzeczywistej struktury organizacyjnej projektu oraz metod prowadzenia prac w projekcie

• Pierwszy poziom mogą stanowić fazy cyklu życia, wówczas „zarządzanie projektem” jako jedna z faz

• Drugi poziom - określenie głównych produktów cząstkowych dla każdej fazy

• Trzeci poziom - określenie elementów składowych głównych produktów cząstkowych za pomocą dekompozycji

• Podział do poziomu umożliwiającego szacowanie czasu trwania i kosztów

• Poziomy WBS

• Liczba poziomów - określona przez liczbę pakietów roboczych

• Pakiet roboczy najniższego poziomu

- możliwy do wykonania w ciągu 8 do 80 godzin

- możliwy do przydzielenia jednej lub kilku osobom

• 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

• Podstawy tworzenia WBS

• Zakres projektu: lista głównych produktów i ich opis

• Przepływ pracy: sekwencja wykonywania produktów

• Dostępne zasoby

• Oczekiwania klienta (szybkość realizacji, podwykonawcy)

• Położenie projektu: niezależność albo priorytet w grupie projektów

• WYKŁAD 2

• Cykl życia projektu i produktu

• Cykl życia projektu - zbiór etapów projektu przeprowadzanych w określonym porządku, od pomysłu na projekt aż do jego zakończenia

• Cykl życia produktu - zbiór etapów produktu przeprowadzanych w określonym porządku, od pomysłu na produkt do jego wykonania wraz z jego eksploatacją, aż do jej zaniechania

• Relacje cykli życia

Cykl życia projektu zawiera się w cyklu życia produktu. Ten z kolei zawiera się w cyklu życia organizacji.

• Fazy cyklu życia tworzenia oprogramowania

1. Identyfikacja problemów i celów

2. Określenie wymagań informacyjnych

3. Analiza potrzeb systemowych

4. Projektowanie rekomendowanego systemu

5. Tworzenie i dokumentowanie oprogramowania

6. Testowanie i utrzymanie systemu

7. Wdrożenie i ewaluacja systemu

• Cykl życia procesu wytwóczego oprogramowania

• Podstawowe fazy cyklu życia oprogramowania

- definiowanie wymagań

- projektowanie

- budowa i testowanie

- wdrożenie

• Modele procesu wytwarzania oprogramowania

- sekwencyjne

- ewolucyjne

• Podział projektu na etapy (fazy)

• Podział cyklu życia projektu na etapy ze względu na usprawnienie zarządzania

• Każdy etap wyznaczony przez ukończenie jednego lub kilku produktów pośrednich

• Produkt pośredni - wymierny, konkretny i sprawdzalny rezultat lub przedmiot, np.. studium wykonalności, dokumentacja techniczna, prototyp

• Produkty pośrednie i etapy tworzą logiczną sekwencję prowadzącą do produktu końcowego

• Model kaskady

Analiza i definiowanie wymagań --> Projektowanie systemu i oprogramowania --> Programowanie i testowanie jednostek (implementacja) --> Integracja i testowanie systemu --> Instalacja i utrzymanie systemu

• Zalety i wady modelu kaskadowego

• Zalety:

• Podejście sekwencyjne

• Dzieli złożony proces na kilka kroków

• Ułatwia śledzenie i kontrolę postępów: każdy krok posiada kryteria przyjęcia i przejścia do następnego kroku

• Zapewnia komplet dokumentów

• Ogniskuje uwagę na produktach pośrednich

• Odpowiedni dla krótko trwających procesów

• 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ń na początku prac - eliminuje model z zastosowania do procesu o nieznanych na początku wymaganiach

• Nie można przejść do następnej fazy przed zakończeniem poprzedniej

• Zalety i wady modelu V

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

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

• Podejście iteracyjne

• Wymagania i projekt są modyfikowane poprzez serie iteracji prowadzących do otrzymania systemu satysfakcjonującego rozwijające się potrzeby klienta

• Sesje „sprzężenia zwrotnego” i zasada wzajemnego uczenia się

• Zwiększenie zrozumienia definicji wymagań

• Łatwiejsze zarządzanie zmianami

• Umożliwienie rozpoczęcia tworzenia aplikacji dla podzbioru wymagań - analiza dla każdego produktu częściowego

• Wczesna neutralizacja zagrożeń

• Zwiększenie możliwości ponownego użycia kodu

• Łatwiejsze dostosowanie końcowego produktu do zmieniających się wymagań

• Podejście ewolucyjne

• powtarzalność faz procesu, umożliwiająca uzyskanie w kolejnych wersjach kompletnego oprogramowania

• uzyskanie działającego produktu w każdej wersji rozszerzenia począwszy od rdzenia

• uwzględnienie częstych zmian wymagań - ewolucyjna natura oprogramowania

• umożliwia zrozumienie trudnych szczegółów wymagań

• umożliwia wydanie ograniczonej wersji produktu w przypadku presji czasu, niedostatecznej liczby pracowników

• Podejście prototypowania

• Metoda identyfikowania wymagań stawianych oprogramowaniu

• Prototyp jest częściową implementacją systemu, wyrażoną logicznie lub fizycznie, prezentowany za pomocą zewnętrznego interfejsu

• Może składać się z ekranów, raportów i menu systemu, faktycznie nie wykonuje wszystkich funkcji systemu

Zalety:

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

• Na etapie projektowania wspomaga podjęcie decyzji projektowych

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ń

• Zalety i wady modelu spiralnego

• Model ewolucyjny, powtarzalność oparta na prototypowaniu

• Zastosowanie - do dużych projektów

• Każde okrążenie dotyczy jednego elementu produktu: koncepcja, wymagania, projekt, kod

• Umożliwia zmiany w rozwoju produktu - zarządzanie zmianami

• Konieczność zarządzania ryzykiem

• Wczesna eliminacja błędów

• Powtórne wykorzystanie wcześniej wykonanych części

• Każdy cykl zakończony przeglądem wykonanym przez kluczowych członków zespołu

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

• Trudności w opracowaniu i kontroli kontraktu

• Wielokrotne powtarzanie ekspertyz analizy ryzyka

• Model przyrostowy

Wielokrotne wykonywanie liniowych procesów

• Model komponentowy

Komponent

• jednostka programistyczna wykonywalna, która jest niezależnie:

• produkowana

• sprzedawana

• rozbudowywana

• posiadająca określone interfejsy i jawne zależności kontekstowe

• odpowiada klasie lub zbiorowi kilku klas w programowaniu obiektowym

Składanie z powtarzalnych komponentów

• Technika zakłada istnienie gotowych części systemu, nazywanych komponentami

• Wykorzystanie podobieństwa tworzonego oprogramowanie do posiadanych komponentów

• Możliwość zastosowania na etapie analizy i projektowania narzędzi CASE, a szczególnie na etapie implementacji

• Zmniejszenie w znacznym stopniu ryzyka

• Zapewnienie standardów

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

• Konieczność rozwiązywania problemów integracji

Fazy etapu tworzenia w modelu komponentowym

1. Identyfikacja odpowiednich komponentów

2. sprawdzenie dostępności komponentów

3. Wybór dostępnych komponentów

4. Wytworzenie niedostępnych komponentów

5. Dodanie nowych komponentów do biblioteki

6. Konstrukcja n-tej iteracji systemu

• RAD

• szybkie wytworzenie kompletnego produktu

• podejście liniowe z iteracją, możliwość wykorzystania prototypowania

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

• Fazy RAD

• Modelowanie działalności - opis procesu biznesowego

• Modelowanie danych - szczegółowy opis danych

• Modelowanie procesów - opracowanie procedur tworzenia, modyfikowania i usuwania obiektów

• Generowanie aplikacji - zastosowanie technik czwartej generacji

• Testowanie i wdrożenie - testowanie nowych komponentów

• Zastosowanie i wymagania RAD

• Zastosowanie

• szybko zmieniające się wymagania

• ograniczony czas wykonania

• do wybranych części aplikacji

• Nie należy stosować do przedsięwzięć

• związanych z dużym ryzykiem technicznym, np. nowa technologia,

• z wymaganiem wysokiej efektywności

• Wymagania

• modułowość systemu

• zastosowanie narzędzi CASE, gotowych komponentów wielokrotnego użycia

• zwiększenie produktywności zespołu

• wysoka jakość zasobów

• duże zaangażowanie użytkownika w przeglądy

• Techniki czwartej generacji (4GL)

• Narzędzia programistyczne umożliwiające definiowanie różnych cech oprogramowania na wysokim poziomie abstrakcji w celu późniejszego automatycznego wygenerowania

- kodu programu

- struktury bazy danych

- okienkowych systemów interakcji

- dokumentacji

• Pozwalają na skrócenie procesu wytwórczego i zwiększenie wydajności programistów

• Trudne w użyciu

• Niska efektywność automatycznie wygenerowanego kodu

• Formalna transformacja

• Wykonanie specyfikacji wymagań systemu w języku formalnym

• Automatyczne przekształcenie formalnej specyfikacji do postaci pseudokodu, a następnie kodu programu w określonym języku programowania

• Poszczególne etapy cyklu życia są realizowane w sposób indywidualny, zależny od złożoności obliczeniowej problemu

• Język formalny

• symbol - obiekt abstrakcyjny, np. litera, cyfra, znak graficzny

• alfabet - skończony zbiór symboli (Σ)

• łańcuch (słowo) - skończony ciąg symboli

• język (formalny) - zbiór łańcuchów złożonych z symboli jakiegoś jednego alfabetu (Σ*)

• Przykład

jeżeli Σ = {a}, to Σ* = {e, a, aa, aaa, ...}, gdzie e - słowo puste

• Zalety i wady formalnej transformacji

• Wysoka niezawodność pod warunkiem bezbłędnej specyfikacji (brak sprzeczności)

• Przeniesienie trudności programowania na etap specyfikacji wymagań

• Prawdopodobna mała efektywność uzyskanego kodu

• Brak uniwersalnych języków formalnej specyfikacji

• Zwinne zarządzanie projektami

• Zwinne zarządzanie projektami (ang. Agile Project Management, APD) - zbiór różnych metodyk, określanych jako zwinne bądź lekkie, oraz narzędzi stosowanych w zarządzaniu złożonymi i innowacyjnymi projektami - głównie informatycznymi

• Należą do nich między innymi: metody adaptacyjne, Crystal, SCRUM, eXtreme programming …

• Dokument „Manifesto for Agile Software Development” (2001) zainicjował głębokie przemiany w środowiskach programistycznych, przyjętych też w innych obszarach zarządzania projektami

• Powstanie APD było reakcją na mało elastyczne metody zarządzania projektami informatycznymi, uważane za zbyt sformalizowane i mało efektywne

• 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ąca 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

• Porównanie typów cykli życia projektu




• Wybór modelu procesu wytwórczego

• 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

• Na różnych etapach projektu może być zastosowany inny model

• Produkty etapu analizy [CASE*Method]

• Model konceptualny danych

• Diagram hierarchii funkcji

• Tabele powiązań funkcja/encja, funkcja/jednostka, funkcja/cel

• Model przepływu danych, model zależności funkcji, diagram stanów i przejść

• Wymagania wydajnościowe, kontroli i bezpieczeństwa

• Kryteria akceptacji oprogramowania przez użytkownika

• Wstępne parametry sprzętowe

• Wstępna strategia wdrożenia systemu

• Uzgodnione podejście do etapu projektowania i budowy

• Skorygowany plan rozwoju systemu

• Założenia i ograniczenia (koszty, personel, metody i styl pracy, regulacje prawne …)

• Produkty etapu projektowania [CASE*Method]

• Architektura systemu

• Projekt modułów

• Schematy logiczne i fizyczne

• Projekt bazy danych i plików danych

• Szczegółowe wymagania sprzętowe

• Specyfikacje programów

• Szkic instrukcji użytkownika

• Uzgodniona strategia przeniesienia systemu: plan dostarczenia i odbioru, szkolenia, transformacja danych, odejście od starego systemu

• Plan testowania systemu

• Szkic dokumentacji systemu

• Skorygowany plan rozwoju systemu

• Produkty etapu budowy i testowania [CASE*Method]

• Projekt programów

• Dostrojona baza danych

• Działające, przetestowane programy

• Skorygowana strategia przeniesienia systemu

• Wyniki testów systemu

• Zainstalowany sprzęt i oprogramowania, pierwsze oceny wydajności systemu

• Produkty etapu dokumentowania [CASE*Method]

• Dokumentacja użytkownika

• Dokumentacja operatorska

• Produkty etapu wdrożenia [CASE*Method]

• Materiały szkoleniowe

• Przeszkoleni użytkownicy i operatorzy

• Zainstalowany i w pełni działający system

• Przeniesione dane

• Raporty o błędach w działaniu systemu

• Przeglądowe sprawozdanie po wdrożeniu

• Urządzenia wsparcia technicznego

• Kompletna dokumentacja systemu

• Produkty etapu użytkowania [CASE*Method]

• Zbiory danych zapasowe, archiwalne i do odzyskiwania danych

• Raport kontrolny zmian

• Raport o błędach

• Uzupełnienia do systemu

• Statystyka wydajności systemu

• Nowe wymagania

• Wyniki przeglądów systemu

Wykład 3

• Zasada siedmiu pytań Boehma

• Dlaczego powstaje taki projekt?

• Co trzeba zrobić?

• Na kiedy?

• Kto jest odpowiedzialny za poszczególne funkcje produktu?

• Gdzie znajdują się ludzie związani z projektem?

• Jak powstanie produkt i jak będą przebiegać prace?

• Ile będzie potrzebnych zasobów?

• Karta projektu

• Oficjalna nazwa projektu

• Sponsor projektu

• Kierownik projektu

• Cel projektu

• Uzasadnienie biznesowe realizacji projektu

• Opis wyników na poziomie ogólnym

• Opis organizacji zespołu

• Ramowy terminarz prac

• Zasoby (budżet, personel, dostawcy)

• 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ładowe cele projektu:

1. Wdrożenie i udostępnienie do użytkowania programu do końca Iego kwartału przyszłego roku.

2. Przeszkolenie 1000 osób.

• Uzasadnienie biznesowe projektu

• opis i ocena spodziewanych korzyści

- oszczędności wynikające z zatrudnienia

- poprawa wizerunku firmy

- poprawa jakości pracy

• koszty - zakup sprzętu, obsługa systemu, zakłócenia w pracy

• ryzyko związane z realizacją i zaniechaniem

• skutki finansowe - ocena inwestycji

• Kontekst biznesowy projektu

• Analiza strategii organizacji

• Analiza SWOT

• Umiejscowienie projektu w planach organizacji

• Oszacowanie wpływu proponowanego rozwiązania na jej działalność (na bazie studium wykonalności), metoda, np. NPV (Net Present Value)

• Metody oceny opłaca lności projektu

• Proste metody oceny finansowej

- okres zwrotu nakładów

- analiza progu rentowności

- analiza wrażliwości

• Dyskontowe metody rachunku ekonomicznego

- metoda wartości zaktualizowanej netto (NPV)

• metoda wewnętrznej stopy zwrotu (IRR)

• Metoda NPV: metoda wartości zaktualizowanej netto

Cel - określenie aktualnej wartości wpływów i wydatków związanych z projektem

• 
  Zastosowanie metody NPV

• Podjęcie decyzji: realizować projekt czy nie:

• Projekt jest opłacalny, jeżeli NPV>=0

• Ustalenie rankingu ofert wykonania projektu z punktu widzenia opłacalności projektu

• Warianty projektu są identyczne wartościowo i identyczny rozkład w czasie nakładów kapitałowych

• Najbardziej opłacalny, gdy wartość NPV jest największa

• Warianty projektu różnią się wartościowo lub mają różny rozkład wartości w czasie

• Najbardziej opłacalny, gdy wartość NPVR jest największa, gdzie:

• NPVR = NPV/PVI,

• PVI - zaktualizowana wartość nakładów inwestycyjnych na projekt

• Podsumowanie uzasadnienia biznesowego

• Obowiązkowy dokument niezależnie od rodzaju projektu

• Opis przyczyn i powodów uruchomienia projektu

• Analiza możliwych wariantów rozwiązań

• Definicja jakościowych wymagań klienta wraz z kryteriami akceptacji

• Definicja problemów klienta do rozwiązania

• Definicja wymagań końcowych wraz z kryteriami akceptacji

• Oczekiwane korzyści (zgodność z prawem, korzyści finansowe, lepsze warunki pracy …)

• Analiza ryzyka

• Analiza kosztów

• Ocena opłacalności inwestycji

• Sukces projektu

Jednoczesne spełnienie całego zbioru wymagań i ograniczeń utożsamianych z oczekiwaniami kierownictwa i związanymi z przedsięwzięciem

• Zagrożenia (ryzyko) projektu

• Zagrożenia

• bezpośrednie - możliwe do skutecznego opanowania

• pośrednie - słabe lub żadne panowanie

• Cechy zagrożeń

• prawdopodobieństwo wystąpienia ryzyka (powszechność)

• wpływ na projekt (dotkliwość)

• Zarządzanie ryzykiem projektu

• unikanie zagrożenia

• przeniesienie zagrożenia

• przyjęcie zagrożenia

• neutralizacja zagrożenia

• opracowanie planu alarmowego

• Klasyfikacja zagrożeń

• Źródło zagrożeń

• P - projektowe (terminy, budżet, zasoby, komunikacja z klientem, wielkość i złożoność)

• T - techniczne (trudności wykonawcze)

• E - ekonomiczne (produkt niepotrzebny, nieodpowiedni, brak zainteresowania, ograniczenie budżetu)

• Przewidywalność

• znane (wykrywane na podstawie analizy planu i środowiska)

• przewidywalne (odgadywane na podstawie analizy poprzednich projektów)

• nieprzewidywalne: zdarzenia losowe

• Klasyfikacja ryzyk wg Boehma

• Funkcjonalność - niepewność spełnienia przez produkt stawianych wymagań

• Koszt - możliwość przekroczenia budżetu projektu

• Pielęgnacja - niepewność związana z możliwością poprawiania, rozszerzania i dostosowania do zmieniających się warunków

• Harmonogram - możliwość niedotrzymania zaplanowanych terminów

• Zagrożenia wg R. Charette

• Zmiana

- wymagań klienta

- stosowanych technologii

- docelowego środowiska komputerowego i innych elementów związanych z przedsięwzięciem

• Przykłady zagrożeń i rozwiązań

• Brak zrozumienia wymagań - zastosuj prototypowanie

• Nieznany sposób integracji z istniejącym systemem - zastosuj prototypowanie i zatrudnij „eksperta”

• Brak doświadczenia w tworzeniu oprogramowania dla platformy .NET - szkolenia

• Duża zmienność wymagań - możliwie szybka budowa architektury wykonywalnej, model ewolucyjny

• Rotacja personelu - szczegółowe dokumentowanie realizacji prac projektowych, motywowanie pracowników

• Postępowanie z zagrożeniami

• Wybór strategii: akcji albo reakcji

• Strategia akcji

• Identyfikowanie zagrożeń - opracowanie listy kontrolnej zagrożeń

• Szacowanie stopnia zagrożenia projektu

• Szacowanie skutków zagrożeń

• Ocena ryzyka

• Uściślanie zagrożeń

• Opracowanie planu zapobiegania, monitorowania i kontrolowania zagrożeń

• Opracowanie planów awaryjnych w przypadku fiaska działań zapobiegawczych

• Ocena zagrożeń

• Ustal średnie prawdopodobieństwo wystąpienia zagrożenia

• Ustal wpływ zagrożenia na każdy składnik ryzyka wg klasyfikacji ryzyk (skutki)

• Sporządź (uzupełnij) tabelę zagrożeń

• Oblicz podatność na zagrożenie [E. Hall]: R = P * C, gdzie:

R - podatność na zagrożenie

C - koszt strat poniesionych w wyniku wystąpienia zagrożenia

P - prawdopodobieństwo wystąpienia zagrożenia

• Krytyczne czynniki powodzenia cyklu życia projektu wg etapów metodyki CASE*Method

STRATEGIA

• 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

ANALIZA

• zaangażowany użytkownik

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

• identyfikacja wszystkich kluczowych wyników i założeń dla projektu i wdrożenia

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

• sterowanie dla utrzymania postępu prac (tempa), ustalenie szczegółów, utrzymanie skupienia się zespołu na założeniach, dotrzymywanie terminów z harmonogramu prac

• dotrzymanie warunków (ustalić znaczenie słowa „wystarczający”

PROJEKTOWANIE

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

• zrozumienie potrzeb organizacji

• podjęcie decyzji handlowych

• identyfikacja i rozwiązanie potencjalnych problemów

BUDOWA

• zapewnienie jakości i utrzymanie się w harmonogramie

• wykonanie rzeczy według wcześniejszych wskazówek (przygotowanie środowiska implementacji)

• strojenie bazy danych lub programów

• testowanie ograniczeń i wyjątków

DOKUMENTOWANIE

• odpowiednia i faktyczna dokumentacja

• zadowolenie użytkowników i operatów

• akceptacja testów

WDROŻENIE

• odpowiednie szkolenie

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

• koordynacja czasowa wdrożenia

• dostępna dokumentacja pozwalająca zrozumieć system, jak diagnozować problemy, co robić w przypadku awarii systemu czy sprzętu

• zaplanowanie wdrożenia zgodnego z wymaganiami biznesu i zapewnienie dostępności kluczowych użytkowników, twórców i serwisu

• zapewnienie integracji lub współdziałania z istniejącym systemem

EKSPLOATACJA

• wysoki poziom serwisu

• terminowe odpowiedzi na pytania użytkowników

• poprawne sterowanie zmianami

• Wykład 4

• Proces PN-EN ISO 9000

• Zbiór działań wzajemnie powiązanych lub wzajemnie oddziałujących, które przekształcają wejścia w wyjścia

• Rodzaje procesów w organizacji

• procesy kluczowe (podstawowe),

• procesy zarządcze,

• procesy wspierające (pomocnicze).

• Procesy w projekcie

• Procesy ukierunkowane na produkt - definiują i umożliwiają tworzenie produktów projektu określonych przez cykl życia w zależności od dziedziny przedmiotowej (produkty programistyczne są definiowane przez odpowiednie metody inżynierii oprogramowania)

• Procesy zarządzania projektami - opisują, systematyzują i umożliwiają wykonanie prac prowadzonych w projektach (produkty zarządcze są definiowane przez metody zarządzania projektami)

• Grupy procesów zarządzania projektami (PMBOK)

• rozpoczęcia (inicjowania) - formalne zatwierdzenie projektu lub jego etapu do realizacji (karta projektu)

• planowania - określenie i precyzowanie celów projektu, wybór najlepszego z dostępnych sposobów działania prowadzącego do realizacji celów

• realizacji - koordynacja ludzi i innych zasobów w celu wykonania przyjętego planu

• kontroli - systematyczne monitorowanie i mierzenie wykonania projektu, umożliwiające wykrywanie odchyleń od planu

• zakończenia - formalna akceptacja otrzymanych wyników projektu lub etapu projektu oraz zamknięcie projektu

• Procesy rozpoczęcia projektu

• Poprzedzenie procesu rozpoczęcia

- oceną potrzeb,

- studium wykonalności,

- wstępnym planem.

• Czynniki decydujące o zatwierdzeniu do realizacji

- oczekiwania rynku,

- potrzeby firmy,

- zamówienie klienta,

- postęp technologiczny,

- wymagania prawne,

- potrzeby społeczne.

• Materiały wejściowe do procesu rozpoczęcia projektu

• ogólny opis cech charakterystycznych produktu,

• plan strategiczny organizacji,

• kryteria wyboru projektu,

• dane historyczne projektów podejmowanych w przeszłości.

• Rezultaty (wyjścia) procesu rozpoczęcia projektu

• karta projektu/podpisany kontrakt - dokument inicjujący projekt

• wybór/mianowanie kierownika projektu

• ograniczenia limitujące możliwe opcje realizacji

• założenia, jako czynniki pewne dla opracowywania planu: cele, zakres, uzasadnienie biznesowe, organizacja zespołu zarządzania, sposób dostarczenia wyników

• Obszary wiedzy o zarządzaniu projektami [PMBOK]

1. Integracja projektu

2. Zakres projektu

3. Czas w projekcie

4. Koszty projektu

5. Jakość w projekcie

6. Zasoby ludzkie w projekcie

7. Komunikacja w projekcie

8. Ryzyko w projekcie

9. Zamówienia w projekcie

• Procesy planowania - kluczowe [PMI]

• planowanie zakresu (2)

• doprecyzowywanie zakresu (2)

• identyfikacja działań (3)

• określenie kolejności działań

• szacowanie czasu trwania działań (3)

• opracowanie harmonogramu (3)

• planowanie zarządzania ryzykiem (8)

• planowanie zasobów (4)

• szacowanie kosztów (4)

• budżetowanie kosztów (4)

• opracowywanie planu projektu (1)

• Wspierające procesy planowania

• planowanie jakości (5)

• planowanie organizacyjne (6)

• pozyskiwanie personelu (6)

• planowanie komunikacji (7)

• identyfikacja ryzyk (8)

• jakościowa analiza ryzyk (8)

• ilościowa analiza ryzyk (8)

• planowanie reakcji na ryzyka (8)

• planowanie zamówień (9)

• planowanie zapytań (9)

• Składniki zintegrowanego planu projektu

• karta projektu

• deklaracja zakresu projektu

• struktura podziału pracy

• szacowane koszty

• plany bazowe

• kamienie milowe

• kluczowy personel

• plan zarządzania ryzykiem, zakresem, harmonogramem, kosztami ...

• otwarte kwestie

• dane uzupełniające

• Zarządzanie czasem w projekcie - procesy planowania i kontroli

• Główne procesy związane z opracowaniem harmonogramu

• Identyfikacja działań (WBS)

• Określenie kolejności działań (diagram następstw)

• Estymacja czasu trwania działań

• Opracowanie harmonogramu

• Kontrola harmonogramu

• Kolejność działań

• Środkiem do aranżacji kolejności działań jest logiczna sieć działań i ich następstwa

• Podstawa - wiedza o naturze i przepływie pracy

• Reguła - znajomość wyjścia (wyniku) poprzedzającego działania, które staje się wejściem działania następującego

• Brak zachowania reguł - spodziewane przerwy w pracy, powtarzanie działań

• Narzędzia i techniki określania kolejności działań

• metoda diagramów następstw (działania przedstawione za pomocą prostokąta i połączone strzałkami (diagram węzłowy AON))

• metoda diagramów strzałkowych (działania przedstawione za pomocą strzałek połączonych w węzłach (diagram strzałkowy AOA))

• metoda diagramów warunkowych (umożliwia stosowanie pętli i zależności warunkowych)

• szablony diagramów sieciowych (wykorzystywanie standardowych sieci zależności)

• Czas trwania działań

• Czas trwania - liczba jednostek czasu (godzina, dzień, miesiąc) od rozpoczęcia do zakończenia działania

• Składniki rzeczywistego czasu trwania

• liczba jednostek czasu pracy

• liczba jednostek czasu przerwy

• ustawowe dni i godziny wolne od pracy

• szkolenia

• choroby

• komunikowanie się między członkami zespołu

• przeglądy

• przejścia między zadaniami

• Metody i narzędzia budowy harmonogramu

• Metoda CPM (Critical Path Method)

• Metoda PERT (Program Evaluation and Review Technique)

• Wykres GERT (Grafical Evaluation and Review Technique)

• Symulacja: analiza Monte Carlo, analiza wielowariantowa

• Optymalizacja poziomu wykorzystania zasobów, np. Metoda odwrotnej alokacji zasobów, metoda łańcucha krytycznego

• Oprogramowanie wspomagające zarządzanie projektami

• Metoda budowy harmonogramu CPM (Critical Path Method)

• Przedstawienie produktów/zadań za pomocą sieci w formacie:

• AON - diagram następstw (węzeł)

• AOA - diagram sieciowy (krawędź)

• Podstawy

• Zakres projektu

• Odpowiedzialność

• Dostępne zasoby

• System zarządzania harmonogramem

• Konstrukcja diagramu CPM (zasady)

• Określenie poziomu szczegółowości i identyfikacja działań (np..na podstawie WBS)

• Liczba elementów zależy od wielkości zadań - wystarczająca do monitorowania postępu i zrozumienia podziału pracy przez wykonawców

• Ustalenie sekwencji działań na podstawie

• znajomości technologii wykonywania prac

• doświadczenia

• preferencji

• dostępności kluczowych zasobów

• Oszacowanie czasu trwania każdego zadania na podstawie identyfikacji zasobów ludzkich i materialnych koniecznych do jego zakończenia (na podstawie metod szacowania: metody ilościowe, porównawcze i inne)

• Ustalenie kalendarza dni pracy

• Ustalenie dostępności zasobów dzielonych między różnymi projektami

• Metoda CPM

Procedura przejścia „w przód”

• Założenia

- ustalona data rozpoczęcia projektu

- dla każdego działania istnieje najwcześniejszy termin startu

• Obliczanie terminu najwcześniejszego zakończenia: EF = ES + t, gdzie

- ES - najwcześniejszy termin startu działania, jednocześnie jest

najpóźniejszym terminem EF dla bezpośredniego poprzednika

- EF - najwcześniejszy termin zakończenia działania

- t - czas na wykonanie pojedynczego działania

• Termin zakończenia projektu wynika z EF

Procedura przejścia „w tył”

Przyjmujemy

• Ustalona data zakończenia projektu

• LF - najpóźniejsze zakończenie działania

• LS - najpóźniejszy start działania

• t - czas trwania działania

to LS= LF - t

Wykonując przejście „w tył” dla każdego działania ustalamy

• LF - jako min LS wszystkich bezpośrednich następników

• Jeżeli projekt powinien zakończyć się bez opóźnień to LF = EF

Zapas całkowity (Zc) - maksymalne możliwe opóźnienie wczesnego startu działania bez opóźnienia terminu zakończenia projekt

Zapas swobodny (Zs) - możliwe opóźnienie działania bez opóźnienia wczesnego startu innego, bezpośrednio następującego zadania

• Formy prezentacji harmonogramu

• Diagramy sieciowe

• Diagramy paskowe

• Wykresy kamieni milowych

• Harmonogram hierarchiczny

• Wykres Gantta (1917)

• Przedstawienie czasu realizacji zadań na

poziomej skali czasu

• Podstawy

- Zakres projektu

- Odpowiedzialność

- Dostępne zasoby

• System zarządzania harmonogramem

• Wykres kamieni milowych

• Przedstawienie kluczowych zdarzeń na poziomej skali czasu definiowanych jako

- punkt w czasie

- punkt kulminacyjny dla wielu zbieżnych zależności

• Podstawy

- Zakres projektu

- Odpowiedzialność

- System zarządzania harmonogramem

• Harmonogram projektu z uwzględnionymi zależnościami działań

• Przykłady rozkładu nakładu pracy w czasie

• Reguła 40-20-40

- analiza i projektowanie,

- kodowanie,

- testowanie

• Przedziałowy rozkład

- planowanie: 2-3%

- analiza wymagań: 10-25%

- projektowanie: 20-25%

- kodowanie: 15-20%

- testowanie i usuwanie błędów: 30-40%

• Metoda łańcucha krytycznego (CCS)

• 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

• Czasy trwania działań szacuje się z 50% prawdopodobieństwem (są znacznie krótsze niż w innych metodach)

• Bufory do zabezpieczenia łańcucha krytycznego w trakcie implementacji projektu

• Wymaga zespołu dedykowanego do projektu

• Identyfikacja działań w CCS

• Liczba działań w CCS zależy od ich rozmiaru (2-4 tygodni)

• Ważniejsze zapewnienie pełnej listy działań niż dokładne wyznaczenie czasów trwania

• Przydzielanie zasobów i szacowanie czasów trwania

• Ludzie i zasoby materiałowe narzucają czas trwania działania

• Termin startu działania zależy od ustalenia, jakie zasoby są konieczne do jego zakończenia

• Sporządzenie imiennej listy zasobów i czasu pracy każdego z nich (np.. 100 godzin pracy programisty)

• Charakterystyczna dla CCS technika szacowania czasu trwania - wyklucza uwzględnianie nieprzewidzianych wypadków

• Wymagane jest ustalenie kalendarza pracy: liczba dni w tygodniu, liczba godzin w dniu pracy

• Bufory zasobów CCS

• Zasoby są przydzielane do najdłuższej ścieżki na podstawie analizy zależności między nimi

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

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

• Bufor projektu CCS

• Zabezpieczenie przed nieterminowym zakończeniem projektu

• Bufor projektu dodawany na końcu CC

• Czas trwania bufora projektu: np. 50% czasu trwania CC

• Do bufora nie jest przydzielana żadna praca

• Bufory zasilające CCS

• Bufor zasilający - 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 (bezpośrednia zależność)

• Wielkość bufora zasilającego - np.. 50% sumy czasu trwania działań poprzedzających bufor

• Do buforów nie jest przydzielana żadna praca

• Harmonogram hierarchiczny (HH)

• Harmonogram wielopoziomowy ze zmieniającymi się poziomami szczegółowości

• Każde działanie wyższego poziomu jest podzielone na kilka działań

• Harmonogramy z różnych poziomów są połączone głównymi kamieniami milowymi lub zdarzeniami

• WBS - szkielet budowy harmonogramu hierarchicznego

• Konstrukcja HH

• Podstawy

- Zakres projektu

- Odpowiedzialność

- Dostępne zasoby

- System zarządzania harmonogramem

• Reguły budowy zależą od wybranego typu

- wykres Gantta

- wykres kamieni milowych

- diagram sieciowy

• Liczba poziomów zależy od wielkości projektu

Poziom 1. HH

• Sumaryczny harmonogram całego projektu

• Narzędzie raportowania postępów całego projektu

• Wszystkie elementy harmonogramu są bardzo przybliżone

• Stosowany do prezentacji definicji projektu i wyboru alternatywnych rozwiązań

• Każdy element pracy przeważnie kończy się kamieniem milowym

Poziom 2. HH - funkcjonalny

• Stanowi rozwinięcie działań poziomu pierwszego

• Umożliwia identyfikację priorytetów

• Określa ścieżki krytyczne i bliskie krytycznym

• Umożliwia kontrole spójności między działaniami

Poziom 3. HH - pakiety pracy

• Stanowi rozwinięcie działań poziomu drugiego

• Przedstawiany najczęściej w postaci wykresu Gantta

• Możliwe podejścia do wykonania poziomu 3

- Opracowanie zintegrowanego harmonogramu dla całego projektu

- Budowa harmonogramu dla każdego działania/produktu poziomu 2.

- Konstrukcja oddzielnych, szczegółowych harmonogramów dla każdej fazy, jako rozwinięcia projektu połączone poprzez poziom 2.

- Tworzenie szczegółowego harmonogramu dla każdego uczestnika projektu, dla działań z poziomu 2., za które jest on odpowiedzialny

• Korygowanie harmonogramu

• przyspieszanie zadań - równoległe wykonywanie zadań sekwencyjnych (zmiana zależności FS na SS)

• zmiana przydziału zadań

• obciążanie zadań - przydzielenie dodatkowych pracowników do pracochłonnych zadań

• rozbijanie zadań - wprowadzenie czasu oczekiwania

• Podsumowanie - kroki budowy harmonogramu projektu

• Sformułowanie WBS (produkty techniczne - zakres merytoryczny, produkty zarządcze - związane z rozpoczęciem, organizacją, kierowaniem, monitorowaniem i kontrolą oraz zakończeniem projektu)

• Konstrukcja wykresu Gantta

• Zdefiniowanie kamieni milowych

• Oszacowanie zasobów

• Przydzielenie zasobów do zadań

• Ustalenie ograniczeń na podstawie ścieżki krytycznej

• Wykład 5

• Kontrola postępu prac - metoda EV

• tradycyjne podejście

• różnica miedzy wartością kosztów rzeczywistych i wartością kosztów planowych

• nowe podejście

- wycena wartości prac zrealizowanych do momentu t (wartość produktów, usług)

• Metoda wartości uzyskanej projektu Earned Value

• standard do pomiaru wydajności projektów

• kontrola realizacji projektu przez porównywanie zrealizowanego do chwili t

• zakresu projektu,

• czasu,

• poniesionych kosztów

z przyjętymi wartościami harmonogramu i budżetu w planie bazowym

• Warunki zastosowania metody

• zakres projektu (działania podzielone na wystarczająco małe jednostki)

• harmonogram

• planowany budżet

• stosowane jednostki miary: godziny, kwoty, liczba pakietów roboczych

!!! Metoda EV nie odnosi się do zadań zarządzania projektem!!!

• Odchylenia

• kosztowe

CV(t) = EV(t) - AC(t)

EV(t) - wartość uzyskana w momencie t

AC(t) - koszty rzeczywiste w t

• harmonogramowe

SV(t) = EV(t) - PV(t)

PV(t) - koszty planowane w t

• Wskaźniki efektywności

• wskaźnik wykonania kosztów

CPI = EV(t)/AC(t)

• wskaźnik wykonania harmonogramu

SPI = EV(t)/PV(t)

• Wartości estymowane projektu

• estymacja kosztu zakończenia

EAC = BAC/CPI

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

• estymacja czasu trwania

SAC = BAS/SPI

BAS - planowany czas trwania (wartość skumulowana)

• Założenia do szacowania metodą EV wwersji (0:100)

• wartość uzyskana

• zadanie zakończone stanowi wartość 100% kosztu planowanego

• zadanie rozpoczęte i nierozpoczęte stanowi wartość 0

• koszt rzeczywisty AC może stanowić wartość równą, mniejszą lub większą od kosztu planowanego PV, dla uproszczenia przyjęto AC=PV

• Założenia do szacowania metodą EV w wersji 50:50

• wartość uzyskana

• wykonanie zadania oszacowane na połowę lub więcej stanowi wartość 50% kosztu planowanego zadania

• wykonanie zadania oszacowane na mniej niż 50% kosztu planowanego stanowi wartość 0

• zadanie zakończone stanowi wartość 100% planowanego kosztu zadania

• koszt rzeczywisty AC może stanowić wartość równą, mniejszą lub większą od kosztu planowanego PV, dla uproszczenia przyjęto AC=PV

• Założenia do szacowania metodą EV - wersja szczegółowa

• wartość uzyskana liczona wg oceny procentowej planowanej wartości zadania (jako % planowanego kosztu)

• koszt rzeczywisty AC może stanowić wartość równą, mniejszą lub większą od kosztu

• Wykład 6-7

• Aspekty mierzenia wielkości oprogramowania

• długość - aspekt fizyczny

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

• złożoność - aspekt budowy i użytkowy: strukturalny, obliczeniowy, semantyczny,

• Definicja pomiaru i miary atrybutu

• Pomiar jest procesem, w którym liczby lub symbole są przydzielane do atrybutów wybranego elementu świata rzeczywistego w sposób wyraźnie zdefiniowany za pomocą odpowiedniej reguły

• Miara jest empirycznie i obiektywnie wyznaczoną liczbą lub symbolem przypisanym do elementu, charakteryzowanego specyficznym atrybutem

• Miary bezpośrednie i pośrednie

• Miara bezpośrednia - mierzenie atrybutu nie zależy od miary innego atrybutu: długość kodu źródłowego - LOC, funkcjonalność - liczba funkcji, czas trwania procesu - liczba godzin

• Miara pośrednia - mierzenia atrybutu wymaga odwołania się do miary jednego lub kilku innych atrybutów, a nawet innego obiektu: wydajność programisty - LOC/dzień, efektywność testowania - liczba odkrytych błędów/liczba testowanych pozycji

• Atrybuty wewnętrzne i zewnętrzne

• Atrybuty wewnętrzne - cechy procesu, produktu, zasobów mierzone bezpośrednio względem danego obiektu: wielkość programu, złożoność programu

• Atrybuty zewnętrzne - cechy procesu, produktu, zasobów mierzone pośrednio, względem relacji danego obiektu ze środowiskiem: wydajność programisty, niezawodność programu, użyteczność

• Klasy mierzonych obiektów projektu

• Proces: określone działanie lub zbiór powiązanych działań

• Produkt: artefakty; dokumenty, jako wyniki działań procesu; produkty pośrednie; produkt finalny

• Zasoby: każdy element niezbędny do wykonywania działań procesu

• Miary długości

• liczba linii kodu programu LOC (lines of code): LOC = NCLOC + CLOC

CLOC (commented lines of code) - linie komentarza programu

NCLOC (noncommented lines of code) - linie kodu nie komentarzowe

• liczba linii kodu efektywnego, tj. bez linii komentarza: ELOC

ELOC (effective lines of code) - linie efektywne kodu

• liczba instrukcji źródłowych programu: DSI

DSI (delivered source instructions) - liczona bez linii komentarza, ale z deklaracjami i nagłówkami

• liczba bajtów (znaków)

• liczba stron dokumentacji

• teoretyczna miara Halsteada

• Miary funkcjonalności

• miara Bang DeMarco

• liczba punktów funkcyjnych FP (Function Points) - Albrecht i Symons

• liczba UCP (Use Case Points)

• liczba funkcji wykonywanych przez program

• liczba elementów struktury funkcjonalnej

• liczba elementów struktury informacyjnej

• odpowiedniość zbioru funkcji w odniesieniu do celów i zadań użytkownika

• dokładność otrzymywanych wyników

• Miary złożoności

• liczba cyklomatyczna McCabe

• obiektywna miara złożoności Hendersona - Sellersa

• zestaw miar Chidambera i Kemerera

• miary modułowe - Henry i Kafura

• METODA FUNCTION POINT (FP)

Poziomy stosowania metody

• System tworzony od początku

• System modyfikowany

• System działający

• 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 zapytanie

• Typy składników informacyjnych

• Dane - zbiory zdarzeń lub obiektów pamiętanych i pielęgnowanych, w przypadku ILF wewnątrz aplikacji, w przypadku EIF przez inną aplikację (dostawca, odbiorca, towar, faktura)

• Informacje sterujące - dane wykorzystywane przez aplikację do oddziaływania na elementarny proces/funkcję. Są to reguły lub parametry pamiętane i pielęgnowane, w przypadku ILF wewnątrz aplikacji, w przypadku EIF przez inną aplikację

• Dane i informacje sterujące są zidentyfikowane jako wymagania użytkownika

• Składniki informacyjne systemu: ILF oraz EIF

• ILF - grupa logicznie powiązanych danych lub informacji sterujących, pielęgnowanych (C, U, D,) przez elementarny proces/funkcję należący do zakresu aplikacji

• EIF - grupa logicznie powiązanych danych lub informacji sterujących, do których odwołania (R) są realizowane za pomocą elementarnego procesu/funkcji z zakresu danej aplikacji, ale pielęgnowanych przez elementarny proces/funkcję należący do innej aplikacji

• Na modelu ILF oraz EIF odpowiadają typom obiektów (DOZ) lub magazynom danych (DPD)

• Składniki funkcyjne systemu: EI, EO

• EI - elementarny proces/funkcja aplikacji, który przetwarza dane lub informacje sterujące wprowadzane z otoczenia aplikacji przez użytkownika lub inną aplikację

• EO - elementarny proces/funkcja aplikacji, który generuje dane lub informacje sterujące do otoczenia aplikacji: do użytkownika lub innej aplikacji

EQ - elementarny proces/funkcja aplikacji, któ ry wyprowadza dane do użytkownika. Stanowi kombinację wejść i wyjść:

• Wejście - informacja sterująca, która określa rodzaj i sposób pozyskiwania danych z ILF, EIF

• Wyjście - nieprzetworzone dane odczytane z ILF, EIF

• Etapy w metodzie FP

1. Obliczanie „niedopasowanych” punktów funkcyjnych

2. Obliczanie wskaźnika poziomu technicznej złożoności

3. Obliczanie wielkości systemu za pomocą liczby punktów funkcyjnych

• 1. Obliczanie „niedopasowanych” punktów funkcyjnych

a) Wyznaczenie granicy aplikacji

b) Klasyfikacja składowych systemu wg typów funkcyjnych

c) Ustalenie poziomu złożoności dla każdego składnika danego typu funkcyjnego na podstawie macierzy złożoności

a) Obliczenie UFP według wzoru


z_ij - liczba składników i - tego typu j - tej złożoności

w_ij - waga składnika z_ij; i = 1, ...,5; j = 1, 2, 3

• Wagi typów funkcyjnych

• 
  Elementy składowe typów składników systemu

• DET - dana elementarna

• RET - logiczny plik danych

• FTR - logiczny plik referencyjny

• 2. Obliczanie wskaźnika technicznej złożoności

a) Ustalenie poziomu i liczby stopni wpływu każdej charakterystyki na podstawie tabeli reguł

b) Obliczenie całkowitego stopnia wpływu DI = å c_i; i = 1, ...,14

c) Obliczenie wskaźnika technicznej złożoności: TCF = 0.65 + 0.01DI

• 3. Obliczanie wielkości systemu w punktach funkcyjnych

FP = UFP * TCF

Wykład 8-9

• Zasady transformacji modelu DOZ do projektu tabel bazy danych [na podstawie Barker R. CASE*Method]

A. Obiekty proste

B. Obiekty z podtypami

C. Związki rozłączne

• A. Projektowanie - obiekty proste - reguły

Krok 1.

• Przekształć każdy prosty obiekt (nie jest podtypem i nie zawiera podtypów) w tabelę.

• Nazwij tabelę stosując liczbę mnogą nazwy obiektu.

Krok 2.

• Przekształć każdy atrybut w kolumnę o tej samej nazwie, sprecyzowanym formacie i długości

• Atrybuty opcjonalne przechodzą w kolumny null, atrybuty obowiązkowe w kolumny not-null

Krok 3.

• Składowe unikalnego identyfikatora obiektu - klucz główny (pierwotny) tabeli

• Jeżeli obiekt jest identyfikowany przez uczestnictwo w związku, dołącz do tabeli kopie składowych unikalnego identyfikatora obiektu, który jest na drugim końcu związku (może to być proces rekurencyjny)

• W nazwach dołączonych kolumn wykorzystaj nazwy obiektów i/lub związków, dodając je do nazw atrybutów

Krok 4.

• Związki N:1 oraz 1:1 stają się kluczami obcymi (zewnętrznymi)

• Należy dołączyć do odpowiedniej tabeli kopie składowych unikalnego identyfikatora obiektu znajdującego się po stronie końca „1” tego związku

• Związki opcjonalne tworzą kolumny null.

• Związki obowiązkowe tworzą kolumny not-null.

• Reguły dla więzów integralności

• integralność atrybutu - wszystkie wartości atrybutów tego samego typu należą do tej samej dziedziny

• integralność encji - żaden z elementów składowych klucza pierwotnego nie może zawierać wartości pustej

• integralność referencyjna - każdej, niepustej wartości klucza obcego musi odpowiadać wartość klucza pierwotnego z tej samej dziedziny. Może istnieć wartość „null”.

• Definicja perspektywy

Perspektywa (relacja wirtualna) jest strukturą logiczną umożliwiającą dostęp do podzbioru jednej lub wielu tabel, umożliwiającym tratowanie jej jako odrębnej tabeli (ale bez indeksów)

• Zastosowanie perspektyw

• Autoryzacja dostępu do danych

• Ułatwienie dostępu do danych

• Prezentacja tych samych danych w różny sposób (w definicji mogą wystąpić wyrażenia arytmetyczne operujące na danych z tabel, zmiana formatu do prezentacji)

• Dodatkowy poziom ograniczeń integralnościowych

• Tworzenie perspektywy

Podstawowe operatory relacji:

• selekcja

• projekcja

• złączenie

• unia

• przecięcie

• różnica

• B. Projektowanie z podtypami - reguły

I. Jedna tabela

Proces projektowania należy przeprowadzić dla każdego podtypu, wszystkich podtypów każdego podtypu itd..

1. Utwórz tabelę tylko dla zewnętrznego nadtypu i opcjonalne perspektywy relacyjne dla każdego podtypu, które umożliwią przetwarzanie tylko danych należących do danego podtypu.

2. Dołącz do tabeli kolumny dla atrybutów i związków nadtypu (patrz A. 1,2,3,4).

3. Dołącz kolumny utworzone dla atrybutów i związków podtypów, wszystkie są null. Warunek spójności powinien być dodany albo w oprogramowaniu albo w definicji perspektywy

4. Dołącz dodatkową kolumnę not-null, jako część klucza głównego tabeli, w celu wskazania rodzaju podtypu

II. Tabele dla podtypów

1. Utwórz tabelę dla każdego podtypu. W przypadku kilku poziomów tabele są zwykle tworzone tylko dla pierwszego poziomu, a niższe poziomy są obsługiwane przez perspektywy.

2. Dołącz kolumny do każdej tabeli według postępowania A.1, 2, 3, 4.

3. Gdy podtyp jest równocześnie nadtypem tworzone są opcjonalne kolumny dla każdego

jego podtypu (patrz B.3, 4)

4. Zdefiniuj perspektywę UNION dla potrzeb przetwarzania wszystkich danych należących do nadtypu.

• C. Związki rozłączne - reguły

I. Wspólna dziedzina: jeżeli wszystkie klucze obce mają tą samą dziedzinę (identyczny format i długość). Utwórz dwie kolumny w tabeli odpowiadającej obiektowi po stronie łuku w związku:

• identyfikator obiektu - przechowuje wartość unikalnego identyfikatora obiektu na drugim końcu tego związku

• identyfikator związku - rozróżnia związki w łuku

II. Jawny klucz obcy - klucze obce nie mają tej samej dziedziny.

• Utwórz kolumny null jawnego klucza obcego dla każdego związku objętego tym łukiem.

• Kod aplikacji musi zapewnić warunek spójności: wprowadzana jest tylko jedna wartość i wartość ta jest na pewno wprowadzona w przypadku związków obowiązkowych.

• Indeks

• Środek dostępu do jednego lub kilku wierszy tabeli.

• Implementowany za pomocą struktury B-tree.

• Może składać się z jednej lub kilku kolumn.

• Projekt indeksów

Utwórz indeksy dla:

• klucza głównego - indeks jednoznaczny

• klucza obcego - indeks wieloznaczny

• kluczy ustalonych na podstawie macierzy powiązań

• Funkcja/Atrybut

• Klucz główny jak i obcy może składać się z więcej niż jednej kolumny - indeks wielokolumnowy

• Wynikiem szczegółowej analizy definicji funkcji może być użycie innych atrybutów dla potrzeb warunków selekcji, najczęściej używane powinny być zdefiniowane jako indeksy

• Projekt i projektowanie

• Projekt - techniczna reprezentacja budowanego systemu.

• Wynik projektowania - specyfikacja projektu.

• Jakość oprogramowania zależy głównie od decyzji projektowych

• Projektowanie - iteracyjny proces tłumaczenia specyfikacji wymagań na specyfikację projektu.

• Poziomy projektowania

• Projektowanie logiczne

• definicja zakresu systemu

• opracowanie struktury systemu

• opracowanie architektury systemu

• Projektowanie fizyczne

• wybór środków fizycznej implementacji

• projekt interfejsu użytkownika

• projekt formularzy papierowych

• projekt raportów

CELE SYSTEMU INFORMATYCZNEGO

• wykonywanie zdefiniowanych funkcji przedsiębiorstwa

• wykonywanie funkcji koniecznych do zapewnienia sprawnego działania systemu

• Zakres systemu

1. Procesy (moduły) obejmujące podzbiór zdefiniowanych funkcji, określony ze względu na:

• cele systemu

• priorytety (częstość, pilność, znaczenie dla celów)

• możliwości (technologiczne)

• ograniczenia (zasoby czasowe, finansowe, ludzkie, istniejące systemy, preferencje)

przy zapewnieniu

• kompletnej obsługi zdefiniowanej sekwencji funkcji (wynikającej z odpowiedzi na zdarzenie)

• przeniesienia funkcji elementarnych na procesy elementarne

2. Procesy (moduły) obsługujące system - administracyjne

• instalacja systemu i aktualizacja wersji

• konwersja i współdziałanie z istniejącymi systemami

• monitorowanie działania i sporządzanie statystyk

• zabezpieczenie i kontrola dostępu

• tworzenie i odtwarzanie kopii zapasowych

• usuwanie niepotrzebnych danych

• Struktura systemu

Grupowanie funkcji elementarnych w procesy (moduły)

• jedna funkcja - jeden proces

• wszystkie funkcje - jeden proces

• wybrane funkcje - jeden proces

Czynniki grupowania

• sekwencje zależności funkcji

• role użytkowników

• jednostki organizacyjne

• możliwe sposoby realizacyjne

• równowaga miedzy złożonością składników a:

• łatwością zrozumienia

• 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 samych atrybutach dokładnie w ten sam sposób

• Preferencje użytkownika

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

• Kategorie realizacyjne procesów

• Ekranowy - operowanie na danych (C, U, D, R) i natychmiastowy czas odpowiedzi

• Wydawniczy - użycie tabel typu R i opóźniony czas odpowiedzi

• Operatorski - brak manipulowania danymi i opóźniony czas odpowiedzi

• Ręczny - brak odwołania do tabel

• Transformacja modelu analitycznego na projekt systemu

• Projekt struktury danych: Diagram związków encji, Opis obiektów danych, Słownik danych.

• Projekt architektury systemu: Diagram przepływu danych.

• Projekt interfejsu użytkownika: Diagram przepływu danych, Specyfikacja przepływu sterowania, Diagram stanów i przejść.

• Projekt procedur: Specyfikacja przepływu sterowania, Specyfikacja procedury, Diagram stanów i przejść.

• Logika procesu (modułu/procedury) -specyfikacja projektowa

• Przeniesienie logiki zdefiniowanych funkcji elementarnych

• Opracowanie logiki procesów dodanych

• Wyszukiwanie identycznych procedur przetwarzania

• Projekt funkcji wydawniczych

• 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

• Specyfikacja funkcji wydawniczej:

- kryteria wyboru danych

- lista przeszukiwanych tabel i relacji

- sposób sortowania wyszukanych danych

- algorytm otrzymywania danych pochodnych

• układ i format danych

• Projekt modułów

• Moduł - nazwany, oddzielny składnik (komponent) programu

- może być implementacją w postaci jednego programu

- spełnia wymagania logicznej lub funkcjonalnej części systemu

- jest niezależny od pozostałej części systemu, z wyjątkiem interfejsów

• Moduły wymagają integracji w jedną całość - system

• Hierarchia modułów - opis powiązań między modułami

• Moduł nadrzędny - wywołuje inny moduł

• Moduł podrzędny - moduł wywoływany przez inny moduł

• Architektura systemu

• Określa sprzętowe i programowe środowisko docelowe dla gotowej aplikacji oraz środowisko do budowy i testowania aplikacji

Diagram powiązania podsystemów i ich wzajemnej zależności w realizacji usług:

• geograficzna lokalizacja jednostek organizacji (mapa)

• sposoby i zasady komunikacji między odległymi jednostkami

• lokalizacja podsystemów i sprzętu komputerowego

• połączenia programowe i sprzętowe między podsystemami

• Architektura trójwarstwowa oprogramowania

• warstwa pierwsza - interfejs użytkownika: prezentowanie danych i przekazywanie danych do drugiej warstwy (i odwrotnie)

• warstwa druga - funkcje systemu: zaimplementowane funkcje przetwarzające dane

• warstwa trzecia - zarządzanie danymi: magazynowanie danych i fizyczne przetwarzanie

• Projektowanie struktury danych

• Kategorie wg żywotności danych

- trwałe

- tymczasowe

• Opracowanie struktury danych

- określenie sposobu ich organizacji

- metod dostępu

- powiązań

- sposobów przetwarzania elementów danych

• Rodzaje struktur danych

- na poziomie modułów i procedur: skalary, wektory, tablice, listy

- na poziomie aplikacji: baza danych: hierarchiczna, sieciowa, relacyjna, obiektowa

- na poziomie organizacji: hurtownia danych

• Podstawa projektu struktury danych

• diagram związków encji (DOZ)

• słownik danych

• Projektowanie procedur programu

• Procedura - nazwany ciąg rozkazów, które wykonuje konkretne i ograniczone zadanie

- opis sposobu przetwarzania informacji

• kolejność wykonywania działań

• wskazanie miejsc decyzyjnych,

• wskazanie powtarzanych czynności,

• opis używanych struktur danych.

• Metody opisu projektu procedur (programu)

• notacja graficzna: schematy blokowe, ramkowe

• notacja tablicowa,

• pseudokod.

• Szczegółowy projekt programu

• Dekompozycja

• Identyfikacja powtarzalnych działań (procedury)

• Klasyfikacja wyrażeń

- sekwencja

- warunek

- wybór (kolejno sprawdzane warunki)

- powtórzenia

• pętla „dopóki”

• „powtarzaj aż”

• Zagnieżdżanie wyrażeń

• Pseudokody

• Język projektowania programów

• Stanowi kombinację słownictwa języka naturalnego i składni języka programowania

• Podstawowa składnia pseudokodu

• definiowanie i wywoływanie podprogramów

• deklarowanie danych

• podział na zagnieżdżone bloki

• konstruowanie wyrażeń

• opis wejść/wyjść

• Interakcja człowiek - komputer

• Przetwarzanie wsadowe a interakcyjne

• Podejście do projektowania interfejsu ukierunkowane na użytkownika

- Analiza użytkowników i ich charakterystyka

- Dobór odpowiedniego stylu interakcji

- Wybór odpowiednich urządzeń interakcji

- Uwzględnienie standardów

- Prototypowanie i ocena

• Klasyfikacja użytkowników

• Doświadczenie

- Użytkownik nowy - brak doświadczenia w pracy z systemami komputerowymi

- Użytkownik nowy, ale z doświadczeniem w pracy z innymi systemami komputerowymi

- Użytkownik doświadczony w pracy z projektowanym systemem

- Ekspert - użytkownik doświadczony w pracy z projektowanym systemem, posiadający semantyczną i składniową wiedzę o systemach komputerowych

• Kontakt

- bezpośredni (końcowy)

- pośredni

• Projekt interfejsów

• Opis sposobów wymiany informacji

- między różnymi częściami oprogramowania,

- z innymi systemami,

- z użytkownikami.

• Każdy interfejs odpowiada

- przepływom danych,

- przepływom sterowania,

- specyficznym zachowaniom systemu.

• Style interakcji użytkownika

• Pytania i odpowiedzi (bankomat)

• Język poleceń (DOS)

• Wypełnianie formularzy (ekranowy formularz)

• Menu (wybór opcji zależy od urządzenia, grupowanie funkcjonalne, alfabetyczne, częstościowe, …)

• Bezpośrednie operowanie danymi: wizualna prezentacja obiektów, działanie, informacja zwrotna (okna, ikony, menu, wskaźniki)

• Język naturalny

• Styl mieszany - graficzny interfejs użytkownika (GUI)

• Urządzenia interakcji

• Urządzenia wejściowe do wprowadzania danych lub ustawiania wskaźnika

- Klawiatura

- Mysz

- Optyczny czytnik znaków

- Czytnik kodów paskowych

- Ekran dotykowy

- Manipulator kulkowy lub drążkowy

- Rękawica cyfrowa

- Identyfikator mowy

- Urządzenie śledzące ruch gałki ocznej

• Projekt funkcji interakcji

• Funkcje umożliwiające dodawanie, usuwanie i modyfikację wystąpień tabel bazy danych - może być użyta ta sama definicja formularza

• Funkcje realizujące odpowiedzi na zapytania

• Specyfikacja definicji formularza ekranowego

- rozmieszczenie danych na ekranie

- koordynacja bloków ekranu: główny/szczegółowy

- kryteria poprawności i integralności danych

- sposoby nawigacji (diagram projektu dialogu): przejścia między blokami, stronami, formularzami, pola z listami wyboru

- operacje dostępne z poziomu formularza i ich szczegóły

• 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: rodzaj, rozmiar, kolor)

• 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

• 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

• Formularze samokopiujące

• Unikanie zbędnych pytań

• Ogólne zasady projektowania interfejsu użytkownika

• Minimalizacja interakcji

• Zachowanie stylu interakcji systemów używanych i akceptowanych przez użytkownika

• Możliwość wyboru kolejności wykonania operacji lub anulowania

• Pomoc: wartości domyślne, znana użytkownikowi terminologia, tytuły ekranów, znaki zachęty, podpowiedzi (najlepiej kontekstowe)

• Obsługa błędów:

- zachowanie reguł integralności przedsiębiorstwa (transakcja, wyłączność, równoległe systemy),

- pomoc użytkownikowi w naprawie błędu lub kontynuacja działania (komunikat o błędzie i podpowiedź dalszego działania)

Wykład 10

• Jednostki umowne

• Złożoność funkcjonalna

- punkty funkcyjne

- punkty przypadków użycia

- pełne punkty funkcyjne

- punkty charakterystyczne

- punkty internetowe

- punkty „historyjek” w metodyce Scrum

• Złożoność konstrukcyjna

- liczba Mc Cabe

- liczba przepływów między modułami

- punkty obiektowe

• Metoda UCP (Use Case Points) [Karner G. 1993]

Metoda stosowana do obliczania wielkości aplikacji tworzonej metodami obiektowymi i z użyciem pojęć języka UML

1. Obliczanie niedopasowanych punktów UUCP (Unadjusted Use Case Point)

2. Obliczanie czynnika złożoności technicznej TCF

3. Obliczanie czynnika złożoności środowiskowej EF

4. Obliczenie końcowych punktów przypadków użycia UCP

• 1. Obliczanie niedopasowanych punktów UUCP

• Realizacja etapu w dwóch krokach: A - aktorzy i B - przypadki użycia

• Poziomy złożoności każdego składnika ustalane wg kryteriów podanych w tabelach współczynników wagowych

A. Sumowanie aktorów wg oceny ich złożoności: UUCP(A) = Σ zij * Wi

A. Sumowanie przypadków użycia wg rodzaju transakcji albo klasy oraz oceny ich złożoności

Transakcje: UUCP(UCT) = Σ zij * Wi

Klasy: UUCP(UCC) = Σ zij * Wi

• Obliczanie niedopasowanych punktów przypadków użycia

UUCP = UUCP(A) + UUCP(UCT) albo UUCP = UUCP(A) + UUCP(UCC)

• 2. Obliczanie czynnika złożoności technicznej TCF

1. W pierwszym kroku analiza znaczenia czynnika dla projektu i ocena w skali od 0 do 5. 0 - nie ma znaczenia, 5 - krytyczny.

2. W drugim kroku standaryzacja czynnika za pomocą liczby wagowej z tabeli.

3. W trzecim kroku obliczenie TCF za pomocą wzoru: TCF = 0,6 + 0.01 * Σ Fi * wi

• 3. Obliczanie czynnika złożoności środowiskowej EF

1. W pierwszym kroku analiza znaczenia czynnika dla projektu i ocena w skali od 0 do 5.

Przykładowo: dla czynnika F3 brak doświadczenia - 0, ekspert - 5, a przeciętna znajomość tematu - 3.

2. W drugim kroku standaryzacja czynnika za pomocą liczby wagowej z tabeli

3. W trzecim kroku obliczenie TCF za pomocą wzoru: EF = 1,4 + (-0.03) * Σ Fi * wi

4. Obliczenie końcowych punktów przypadków użycia UCP: UCP = UUCP * TCF * EF

• Zestaw 6 - ciu metryk Chidambera i Kemerera (C&K) dla podejścia obiektowego

* Miary wielkości drzewa hierarchii

- DIT (depth of inheritance tree) wysokość drzewa dziedziczenia

- NOC (number of children) rozpiętość drzewa dziedziczenia

* Miary wielkości klasy

- WMC (weighted methods per class) suma ważonych złożoności metod dla klasy

- CBO (coupling between object classes) liczba powiązań dla klasy

- RFC (response for a class) liczba odpowiedzi dla klasy (fan-out)

* Miara spójności proceduralnej

- LCOM ( lack of cohesion of methods) liczba par metod, których podobieństwo jest równe 0

• Model COSMIC: FFP i CFP

• COSMIC - Common Software Measurement International Consortium

• Rozpoczęcie prac nad modelem 1998 - projekt z udziałem 10 państw

• Ogłoszenie koncepcji nowej miary funkcjonalności COSMIC-FFP -1999

• Metoda COSMIC-FFP została przyjęta jako międzynarodowa norma ISO/IEC 19761:2003

• Nowa wersja COSMIC - CFP (COSMIC Function Point)- 2007

• Wymagania tzw. niefunkcjonalne, dotyczące środków implementacji systemu, jego cech jakościowych, takich jak wydajność czy przenośność, nie są przedmiotem pomiarów i nie wpływają na wielkość oprogramowania wyrażoną w jednostkach COSMIC.

• FFP - pełny punkt funkcyjny

• FFP - zawiera rozszerzenie definicji użytkownika z metody FP: “Użytkownikiem mogą być nie tylko osoby (specyfikujące FUR), ale też oprogramowanie i urządzenia mechaniczne wchodzące w interakcje z mierzonym oprogramowaniem.”

• Kategorie BFC - Podstawowego składnika funkcjonalnego

- E (Entry)

- X (Exit)

- R (Read)

- W (Write)

• Fazy procesu obliczania CFP

I. Strategia mierzenia: cel i zakres mierzenia

II. Mapowanie wymagań funkcjonalnych do wzorca modelu miary CFP

III. Mierzenie FUR (Functional User Requirements) - obliczanie CFP

• Faza mapowania

• Ustalanie wielkości składników aplikacji - liczba komponentów

• Identyfikacja procesów funkcjonalnych

• Identyfikacja obiektów zainteresowania, grup danych i przesłań danych

• Logiczny model danych

• Wejście, wyjście, przetwarzanie dla każdego procesu funkcjonalnego

• Warunki konieczne do kwalifikacji elementarnej części FUR jako procesu funkcjonalnego

• niezależność wykonania

• wywołanie przez zdarzenie w świecie użytkownika funkcjonalnego

• wykonanie wszystkiego co było wymagane w odpowiedzi na zdarzenie wywołujące

• Zastosowanie CFP

• Odpowiednia dla:

- Aplikacje biznesowe - których złożoność wynika z konieczności zarządzania dużą ilością danych;

- Systemów czasu rzeczywistego - realizujących sterowanie zdarzeniami

- Systemów hybrydowych (łączących cechy w/w), np. Systemy rezerwacji w czasie rzeczywistym hoteli, lotów

• Nie sprawdza się w przypadku:

- SI o złożonych algorytmach matematycznych lub innych wyspecjalizowanych regułach działania, np. systemy eksperckie, symulacyjne, wspomagające prognozowanie pogody;

- SI przetwarzających zmienne ciągłe: dźwięki audio lub obrazy wideo, np. gry komputerowe

• Miara Bang [DeMarco 1982]

• Miara szacowania wielkości oprogramowania na podstawie modelu

• Wyróżniono 6 podstawowych elementów modelu

- Podstawowe elementy funkcjonalne PEF

- Elementy danych ED

- Obiekty danych OD

- Związki między obiektami danych ZE

- Stany ST

- Przejścia między stanami PR

Wyróżniono także 6 dalszych elementów modelu

- modyfikowane ręcznie podstawowe elementy funkcjonalne MRPEF

- elementy danych wejściowych EDWe

- elementy danych wyjściowych EDWy

- elementy danych przechowywanych EDP

- znaczniki danych ZDi (elementy danych w interfejsach i-tej procedury)

- lokalne związki ZWi (związki między i-tym obiektem a innymi z modelu)

• Przepływ informacji między modułami

• Lokalny przepływ bezpośredni

- jeden moduł wywołuje drugi i przekazuje doń informacje

- wywołany moduł zwraca wynik do modułu wywołującego

• Lokalny przepływ pośredni

- wywołany moduł zwraca informację, która jest przekazywana do innego wywołanego modułu

• Globalny przepływ

- informacja przepływa z jednego modułu do drugiego przez globalną strukturę danych

• Przepływy fan-in, fan-out

• Fan-in(M) - liczba lokalnych przepływów wchodzących do M oraz liczba struktur danych, z których informacja jest pozyskiwana przez M

• Fan-out(M) - liczba lokalnych przepływów wychodzących z M oraz liczba struktur danych, które są aktualizowane przez M

Ogólna reguła: „minimalizacja liczby modułów z wysoką liczbą fan-out”

• Miara spójności modułu

współczynnik spójności = liczba modułów spójnych funkcjonalnie całkowita liczba modułów

Kategorie spójności:

- Funkcjonalna (6): zdefiniowana jedna funkcja

- Sekwencyjna (5): więcej niż jedna funkcja, wykonywane w kolejności wynikającej ze specyfikacji

- Komunikacyjna (4): wiele funkcji na tej samej dziedzinie danych

- Proceduralna (3): więcej niż jedna funkcja, powiązane ogólną procedurą programową

- Tymczasowa (2): więcej niż jedna funkcja, powiązane przez konieczność wystąpienia w tym samym czasie

- Logiczna (1): więcej niż jedna funkcja, powiązane logicznie

- Zgodnościowa (0): więcej niż jedna funkcja, brak powiązań

• Kryteria „dobrej” miary [Stutzke R.D., Estmating Software-Intensive Systems, s.91]

• 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

• Aktualność - otrzymanie wartości mierzonej charakterystyki w czasie mierzenia

• Opłacalność - wartość informacji o mierzonej wielkości nie powinna przekraczać kosztu jej otrzymania

• Przewidywalność - możliwość prognozowania przyszłych wielkości

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

Wykład 11i 12

• Szacowane wielkości projektu IT

• Wymiary projektu podlegające szacowaniu

- czas

- zasoby

- produkty

• Czynniki szacowania wymiarów projektu

- wielkość zadania projektowego: rozmiar, złożoność, rodzaj, ...)

- ludzkie: wiedza, doświadczenie, styl pracy, organizacja projektu, zdolności, zaangażowanie

- metody i narzędzia projektowe

- warunki pracy: sprzęt komputerowy i komunikacyjny, oprogramowanie, miejsce pracy

• Kategorie oceny sukcesu projektu IT według Standish Group

• Trzy kategorie w ocenie zakończenia projektu

- pełny sukces - projekt zakończony w planowanym czasie i budżecie, wszystkie właściwości i funkcje zgodne ze specyfikacją

- porażka - projekt przerwany przed zakończeniem lub nigdy nie wdrożony

- kwestionowany - projekt zakończony i produkt działający, ale opóźniony, budżet przekroczony, bez niektórych właściwości i funkcji specyfikowanych na początku

• Statystyczny rozkład rezultatów projektów IT

• Rezultaty projektów IT nie posiadają rozkładu Gaussa

• Nie są rozmieszczone symetrycznie względem wielkości średniej

• Rezultat nominalny: 50% szans na to, że projekt zakończy się lepiej niż zakładano i 50% szans na to, że zakończy się gorzej jest przesunięty na prawo ze względu na [McConnel S.

Szacowanie oprogramowania]:

- istniejące ograniczenie na sposób dobrego wykonania,

- brak ograniczenia na liczbę problemów, jakie mogą się pojawić

• Rozkład rezultatów projektów IT przedstawia się za pomocą funkcji Nordena/Rayleigha

• 
  Funkcja nakładu pracy Nordena/Rayleigha

gdzie: y - wielkość nakładów pracy w czasie t, K - pole pod krzywą od t=0 do nieskończoności, przedstawia nominalny nakład pracy cyklu życia mierzony w osobolatach, td- czas, w którym nakład pracy osiąga maksimum, t - czas, zmienna niezależna

• Nakład pracy (pracochłonność)

• Nakład - miara procesu, jako funkcja miar bezpośrednich lub pośrednich rozmiaru produktu

• Wielkość nakładów nie jest równomiernym rozkładem w cyklu życia przedsięwzięcia

• Jednostka miary nakładu pracy

• osobogodzina, osobodzień, osobomiesiąc

- Liczba jednostek (godzin, dni, miesięcy) potrzebnych na wykonanie zadania przez jedną

osobę

• Zamienność ludzi i miesięcy

- wielkość nakładu: 3 osobomiesiące

- czy poprawne jest przeliczenie: 3 osoby - 1 miesiąc ?

• Tylko w przypadku możliwości podziału pracy na niezależne części - brak potrzeby komunikacji między wykonawcami

• Nieekonomiczność skali wielkości projektu IT

• W przypadku oprogramowania im większy system tym większy koszt jednostkowy

• Znacznie szybsze niż przeciętne pogarszanie się wydajności na skutek wzrostu wielkości projektu - nieliniowy wzrost pracochłonności

• Szacowanie i planowanie

• Szacowanie stanowi podstawę planowania

• Szacowanie jest obiektywnym procesem analitycznym

• Planowanie jest ukierunkowanym na cel - rezultat procesem poszukiwania sposobu na jego osiągnięcie

• Elementy planowania uzależnione częściowo od dokładności szacowania

- szczegółowy harmonogram

- ścieżka krytyczna

- struktura WBS

• podział projektu na iteracje

• Trzy grupy czynników uwzględniane w szacowaniu nakładów projektu IT

1. wielkość oprogramowania jako produktu, określona za pomocą odpowiednio dobranej jednostki miary

2. ogólna charakterystyka oprogramowania, często nazywana czynnikiem technicznej złożoności, odzwierciedlającej wpływ wyróżnionych arbitralnie czynników,

3. ogólna charakterystyka środowiska projektu, nazywana czynnikiem złożoności środowiska, przeważnie ustalanym na podstawie oceny ryzyka realizacji przedsięwzięcia, a

wynikającym z kwalifikacji i doświadczenia zespołu projektowego, jak też metod i narzędzi używanych przez ten zespół.

• Model nakładów z wyróżnieniem czynnika dominującego

N = f (S,m(X )), gdzie S - wielkość produktu w określonych jednostkach miary, np. LOC, FP,

wyróżniona spośród zbioru współczynników X nakładu ze względu na jego dominująca rolę w kształtowaniu nakładów, m(X) - czynnik dopasowania nakładu, złożony ze zbioru

współczynników x1, …xn, należących do drugiej lub trzeciej z wymienionych wyżej grup czynników nakładu, N - wielkość nakładu pracy w jednostkach czasu, odpowiednio osobogodziny, osobo-miesiące itd., f - postać analityczna funkcji zmiennych, liniowa albo nieliniowa

• Uproszczone metody szacowania rozmiaru oprogramowania

• orzekająca

• ekstrapolacyjna

• próbkowania

• „przedwczesnego zapłonu”

• uśredniania

• Metoda orzekająca NESMA

• Wielkość orzekająca UFP obliczana na podstawie liczby ILF i EIF z metody FP:

oUFP = 35 x ILF + 15 x EIF

• Metoda ekstrapolacyjna szacowania FP [model ILF Tichenora Ch.]

• Ekstrapolacja rozmiaru na podstawie wybranego elementu systemu - ILF

• Krok 1: UFP = liczba ILF * a, gdzie a = 11,01 system plikowy; = 14,93 system transakcyjny

• Krok 2: FP = 1,0163*(UFP*TCF)^1,0024

• Metoda „przedwczesnego zapłonu”. Szacowanie FP na podstawie relacji między liczbą typów encji a liczbą FP

FP = liczba typów encji * a * b * c

• a - 0.8, ponieważ średnio 20% encji podlega grupowaniu

• b - 33, suma składników typu ILF, EI, EO, EQ wg wagi średniej złożoności:

33 = 1*10(ILF)+3*4(C/U/D)+0.5*4(EI)+1*5(EO)+1*4(EQ)

• c - 1.25, ponieważ średnio tylko 75% wymagań jest znanych na początku

• Metoda prognozy „trzech punktów” - wartości oczekiwanej [Putnam i Myers] (1)

- opracowanie prognoz dla trzech scenariuszy: optymistyczny (max), najbardziej prawdopodobny (npd), pesymistyczny (min)

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

• Prognozowanie FP metodą „trzech punktów” (2)

• Szacowanie aspektów dziedziny informacyjnej

- oszacować przedziały wartości zmiennych prognostycznych - składniki UFP,

- oszacować wartości: optymistyczną, najbardziej prawdopodobną, pesymistyczną

- obliczyć wartości oczekiwane każdej zmiennej, np. dla rozkładu beta

S = (sop+4*sm+sp)/6

- porównać otrzymane wartości oczekiwane z danymi historycznymi mierzonymi za pomocą FP

• Uśrednione szacowanie nakładu za pomocą FP (4)

• Szacowanie współczynnika TCF na poziomie średnim TCF = 1

• Szacowanie FP na podstawie np.. metody trzech punktów FP = 318*1,0 = 318

• Zastosowanie wskaźników otrzymanych przy podobnych przedsięwzięciach, np.:

• średnia wydajność - 26,5 PF/om

• koszt - 800 zł/PF

• Oszacowanie wielkości projektowych:

• nakład = 318/26,5 = 12 osobo-miesięcy

• koszt = 318 * 800 = 254 400 zł

• Szacowanie nakładu na podstawie UCP

• Średnia pracochłonność 20 osobo-godz na 1 UCP (Kerner)

• Pełny zakres od 15 do 30 osobo-godz/UCP (publikowane zastosowania)

• zakres może być zwiększony do 36 osobogodzin (Schneider i Winters)

• Steve Sparks podpowiada, że bezpośrednie przeliczanie jest wątpliwe

• Szacowanie nakładu na podstawie LOC

• Zbudować szczegółowy opis zakresu działania programu

• Zidentyfikować główne funkcje programu

• Ustalić prognozę wartości miary LOC dla każdej funkcji (np. na podstawie analizy przedziałowej i prognozy wartości oczekiwanej)

• Na podstawie danych historycznych ustalić

- średnią wydajność pracy LOC/osobomiesiąc

- średni koszt pracy 1 pracownika na miesiąc [zł]/miesiąc]

• średni koszt opracowania 1 linii kodu [zł]/LOC

• Klasyfikacja modeli i metod szacowania nakładów

• Modele szacowania ze względu na podejście

- doświadczalne

- teoretyczne

- statyczne: równomierny rozkład nakładu pracy w trakcie cyklu życia przedsięwzięcia

- dynamiczne: zmienny rozkład

• Metody szacowania

- modele algorytmiczne

- zasada analogii

- opinia eksperta

- połączenie różnych sposobów

• Algorytmiczne liniowe metody szacowania nakładów pracy

E = c0+Σcixi, gdzie: E - nakład pracy, xi - miary atrybutów produktu i procesu, c0, ci - stałe wyprowadzone doświadczalnie

• Algorytmiczne nieliniowe metody szacowania nakładów pracy

E = a (S)^b, gdzie: E - nakład pracy mierzony w osobogodzinach, dniach, miesiącach

S - oszacowana wielkość produktu, a, b - stałe wyprowadzone doświadczalnie

• Nieliniowy, teoretyczny model nakładów Halsteada (1)

Zauważono, że istnieje zależność N = kSs (1) gdzie

N - wielkość programu jako całkowita liczba operatorów i operandów

n - słownik programu, jako liczba unikalnych operatorów i operandów

S - oszacowany rozmiar programu w LOC

k - stała, jako średnia liczba operatorów i operandów przypadająca na linię kodu w danym języku programowania (np..Fortran: 7, PL/S: 5)

• Metoda COCOMO'81

• COnstructive COst Model

• Narzędzie programowe BYL (Before You Leap)

• Model hybrydowy: łączy metody doświadczalne z elementami wnioskowania statystycznego

• Występuje w postaciach zależnych od

- fazy cyklu życia: wstępna, wczesnego projektowania, zaawansowana faza cyklu

- typu systemu: autonomiczny, częściowo wbudowany, wbudowany

• Nakład pracy (np..osobo-miesiące)

E = a(S)^b*m(X), gdzie: S - prognozowana wielkość systemu (KDSI, KLOC), m(X) - współczynnik wnioskowania, jako sterownik kosztowy, a, b - parametry zależne od typu systemu

• Prognoza czasu realizacji przedsięwzięcia

T = a(E)^b, gdzie: E - prognoza całkowitego nakładu pracy potrzebnego na realizację

całego przedsięwzięcia w osobomiesiącach a, b - parametry

• Metoda COCOMO II - trzy warianty modelu

1. Model kompozycji/wczesnego prototypowania - najwcześniejsza faza cyklu, model odpowiedni dla projektów, w których stosowane są narzędzia GUI, podejście prototypowania oraz rozległego ponownego użycia (ang. reuse), stosowane są punkty obiektowe i prosta formuła nakładów.

2. Model wczesnego projektowania - faza cyklu po uzgodnieniu wymagań, ale przed zdefiniowaniem całej architektury, najczęściej stosowane są punkty funkcyjne transponowane na SLOC.

3. Model po - architekturowy - po utworzeniu architektury i podczas budowy oprogramowania, posiada nowe sterowniki kosztowe i nowe reguły obliczania linii kodu

(SLOC).

• Ocena eksperta w grupach

• Technika grupowej oceny eksperta jest stosowana w początkowej fazie projektu

• Recenzje grupowe - techniki niestrukturalne

• Technika Wideband Delphi - technika strukturalna

• Recenzje grupowe

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

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

• Obliczenie średniej wielkości oszacowań

• Wielkość średnia oszacowania lub przedziały wielkości muszą być przedyskutowane

• Konieczne jest uzyskanie consensusu - wypracowanie wspólnego oszacowania, akceptowanego przez całą grupę

• Uwaga! Nie należy mechanicznie przyjmować wielkości średniej

• Metoda orzeczenia eksperta - Wideband Delphi (1)

1. Koordynator prezentuje każdemu ekspertowi projekt oraz inne znaczące informacje (np. dane o zrealizowanych podobnych projektach) oraz formularz szacowania.

2. Każdy z ekspertów przygotowuje wstępne oszacowania, przeważnie są to wartości przedziałowe.

3. Grupa ekspertów spotyka się z koordynatorem. Eksperci zadają pytania i dyskutują nad problemami z oszacowaniem wielkości projektu.

4. Eksperci dostarczają koordynatorowi anonimowo swoje indywidualne oszacowania

5. Koordynator przygotowuje podsumowujący raport z wyszczególnieniem indywidualnych estymacji w układzie tabelarycznym, oblicza średnią i przekazuje ekspertom.

Później: 1. Eksperci spotykają się ponownie i dyskutują nad różniącymi się ocenami, które w dalszym ciągu są anonimowe.

2. Eksperci głosują anonimowo nad akceptacją średniego oszacowania. Jeżeli jeden z ekspertów głosuje na „nie”, kroki od 3-7 są powtarzane do czasu, gdy grupa zdecyduje, że

wielkość średnia jest reprezentatywna i satysfakcjonująca.

• Podsumowanie metody Wideband Delphi

• Końcowe oszacowanie jest jednopunktowym oszacowaniem albo jest to przedział wyznaczony podczas wspólnej dyskusji.

• Metoda zmniejsza średni błąd oszacowania recenzji grupowej z 290% do 170%

• Stosuje się do szacowania wielkości projektu („rzędu wielkości”)

- w początkowej fazie, kiedy nie są ustalone wszystkie wymagania,

- z nieznanej dziedziny biznesu,

- nowy rodzaj oprogramowania,

- potrzeby zastosowania nowej technologii.

• Warunki stosowania metod na zasadzie analogii (wielkość oprogramowania, nakład)

• Istnienie dokumentacji innych produktów z tej samej dziedziny (dane historyczne)

• Ustalenie kluczowych charakterystyk dla produktów z tej dziedziny

• Zdefiniowanie różnic i podobieństw nowego produktu z poprzednimi na podstawie kluczowych charakterystyk

• Oszacowanie wielkości nakładu za pomocą liniowej zależności

• Przykład metody analogii strukturalnej [Cadle, Yeates]

• Szacowanie nakładów na podstawie

- wstępnie oszacowanej liczby funkcji

- zidentyfikowanych szczegółów niektórych funkcji

- wiedzy i doświadczenia

- statystyk z wykonania wcześniej podobnych funkcji

- uproszczonego schematu cyklu życia projektu

• analiza wymagań

• projektowanie

• kodowanie i testowanie jednostek

• łączenie jednostek i testowanie integracji

• Kryteria porównawcze - czynniki

Oszacowanie trzech kluczowych czynników:

- rozmiar (S) w odniesieniu do zespołu

- znajomość tematyki (F) w odniesieniu do typu wykonanych prac i środowiska technicznego

- złożoność (C) w odniesieniu do problemów technicznych

• Czynnik S

• Wg liczby osób w zespole

- 1 - jednoosobowy

- 2 - do 4 osób (mały projekt)

- 3 - do 12 osób (średni)

- 4 - do 30 (duży)

- 5 - powyżej 30 (bardzo duży)

- 6 - trudno określić w tym czasie

• Czynnik F

• Podobieństwo doświadczenia i wiedzy zespołu

- 1 - wszystkie czynniki znane

- 2 - aplikacja lub techniki znane wykonawcom, nieznany: sprzęt, język, so

- 3 - aplikacja lub techniki znane tylko kilku osobom, które prawdopodobnie nie będą zaangażowane

- 4 - aplikacja lub techniki nieznane, ale typowe w IT, znany sprzęt …

- 5 - aplikacja lub techniki nieznane, ale standardowe w IT, nieznany sprzęt …

- 6 - duża część projektu o charakterze innowacyjnym

- 9 - stopień znajomości tematu trudny do oszacowania w tym czasie

• Czynnik C

• Prawdopodobne problemy technicznej złożoności

- 1 - proste algorytmy, proste struktury danych, pliki danych, interakcje

- 2 - jeden z powyższych czynników nieprawdziwy

- 3 - dwa lub więcej z powyższych czynników nieprawdziwe

- 4 - ustalone ograniczenia pamięci, czasu i efektywności

- 5 - złożoność trudna do oszacowania w tym czasie

• Techniki nieformalne

• Zasada Parkinsona - Koszt określany poprzez posiadane zasoby a nie oszacowaną wielkość systemu.

• Zasada „wygrywa cena” - Manipulacja kosztem według możliwości klienta a nie wielkości systemu.

• Sprawdzenie oszacowania

• Wykonanie obliczeń za pomocą przynajmniej dwóch metod

• Porównanie otrzymanych wyników

• W przypadku dużych rozbieżności ustalenie wiarygodności przyjętych założeń

• Przyczyny rozbieżności wyników prognozy

- zbyt ogólny opis zakresu działania programu

- błędna interpretacja zakresu działania

- nieodpowiednie dane historyczne: przestarzałe, nieporównywalne produkty, błędy w zastosowaniu metody

• Czynniki dokładności oszacowania wielkości projektu

• 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

• Standardowa procedura szacowania projektów oprogramowania

• Wyraźnie określony proces tworzenia oszacowań, obowiązujący na poziomie organizacji

• Standardowa procedura nie pozwala

- na zgadywanie i szacowanie bez przygotowania

- wprowadzanie zmiany oszacowań bez uzasadnienia

• Standardowa procedura sprzyja

- zachowywaniu spójności procesu szacowania

- pozwala na śledzenie wykonanych działań, szczególnie istotne w przypadku błędnych oszacowań

- poprawianiu i doskonaleniu procesu szacowania (procedury)

• Typowe elementy standardowej procedury szacowania projektów oprogramowania

• Stosowanie obliczeń zamiast subiektywnej oceny

• Stosowanie kilku metod szacowania i porównywanie ich wyników

• Planowane powtórki szacowania w predefiniowanych miejscach projektu

• Określenie potrzeb zmiany wymaganej metody szacowania w trakcie realizacji projektu

• Opis dokładności szacowania

• Określenie warunków dla zastosowania wyników szacowania do ustalenia budżetu projektu

• Wymagania archiwizacji danych procesu szacowania i weryfikowania skuteczności procedury

• Szczegóły standardowych procedur są zróżnicowane ze względu na rodzaj projektu

• wielkość: mały, średni, duży

• model realizacji oprogramowania: sekwencyjny, iteracyjny

• Przykład standardowej procedury szacowania dla sekwencyjnych projektów oprogramowania - krok I

Oszacowanie rozpoznawcze - zatwierdzona definicja produktu

- Wykonanie co najmniej jednego oszacowania przy użyciu każdej z następujących metod:

• Metoda wstępująca przy użyciu WBS

• Metoda zstępująca, przy zastosowaniu podobieństwa do analogicznych projektów

• Metoda przy użyciu składników standardowych: strony WWW, tabele baz danych, reguły biznesowe, ekrany, okna dialogowe, raporty …

- Uzyskanie jednopunktowego oszacowania wielkości nominalnej metodą Wideband Delphi, np.. nakład o wielkości N

- Oszacowanie powinno być przedstawione w postaci przedziału od minus 50% do plus 100% (0.5N do 2N)

• Jednopunktowe oszacowanie nominalne nie powinno być ujawniane

• Oszacowanie to nie powinno być wykorzystywane do ustalania budżetu ani podejmowania zewnętrznych zobowiązań

• Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania - krok II

Oszacowanie budżetu - zakończone projektowanie produktu

- Wykonanie nowego oszacowania przy użyciu dwóch metod:

• Metoda wstępująca przy użyciu WBS

• Metoda przy użyciu składników standardowych

- Wykonanie oszacowania punktów funkcyjnych

• Obliczyć punkty funkcyjne na podstawie specyfikacji wymagań

• Skalibrować otrzymane obliczenia na podstawie danych historycznych

• Oszacować nominalny nakład pracy i harmonogram przy użyciu oprogramowania do szacowania

- Powtarzanie oszacowania do uzyskania zbieżności wszystkich wyników w granicach 5%. Użycie wielkości średniej z tych oszacowań jako oszacowanej wielkości nominalnej N

- Obliczenie nowego przedziału oszacowań jako 0.8N do 1.25N

• Podstawą budżetu powinna być wielkość 1N

• Rezerwa budżetowa 0.25N

• Ujawnić tylko górną granicę 1.25N

• Nie używać tego oszacowania do zewnętrznych zobowiązań

• Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania - krok III

Wstępne oszacowanie zobowiązań - po drugim wydaniu tymczasowym

- Wykonanie nowego oszacowania przy użyciu metody wstępującej

• Utworzenie szczegółowej listy zadań

• Oszacowanie potrzebnego nakładu pracy przez programistów i testerów i innych przy użyciu rozkładu beta (metoda trzech punktów)

• Obliczenie sumy nominalnych oszacowań

- Porównanie otrzymanego wyniku z wynikiem z poprzedniego wydania (krok II).

• Obliczenie nominalnego oszacowania za pomocą wzoru:

(2xgórne oszacowanie +dolne oszacowanie)/3

- Obliczenie nowego przedziału oszacowania jako 1.0N do 1.1N

• Górna granica przedziału może być ujawniona na zewnątrz i użyta do zobowiązań zewnętrznych

• Przedział 1.0N do 1.1N można ujawniać wewnątrz firmy

• Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania - krok IV

Końcowe oszacowanie zobowiązań - po trzecim wydaniu tymczasowym

- Porównanie szacowanego wyniku z faktycznym wynikiem z poprzedniego wydania (krok III).

• Obliczenie poprawionego oszacowania nominalnego za pomocą wzoru: pozostały nakład pracy = planowany pozostały nakład pracy/(faktyczny dotychczasowy nakład pracy/planowany dotychczasowy nakład pracy)

• Dodanie wszystkich zadań pominiętych w kroku III

- Użycie sumy powyższych dwóch składników jako nowego nominalnego nakładu pracy N

• Wartość nominalna 1.0N może być ujawniona na zewnątrz

• Zewnętrzne zobowiązania mogą być ustalone na 1.0N

• Przedział od 0.9N do 1.1N może być podany do użytku wewnętrznego (plus/minus 10%)

• Standardowa procedura szacowania dla sekwencyjnych projektów oprogramowania - krok V i VI

• Ponowne oszacowanie projektu - w trakcie realizacji w odpowiedzi na duże zmiany w jego założeniach

• Zakończenie projektu

- Zebranie i archiwizacja danych o faktycznych rezultatach projektu

- Sprawdzenie dokładności każdego oszacowania

• Analiza głównych przyczyn wszystkich poważnych błędów

• Ocena możliwości uzyskania takiej samej dokładności oszacowań mniejszym wysiłkiem

• Propozycje zmian w standardowej procedurze szacowania

• Przykładowe profile rozkładu nakładów pracy w czasie

• Reguła 40-20-40

- analiza i projektowanie,

- kodowanie,

- testowanie

• Przedziałowy rozkład

- planowanie: 2-3%

- analiza wymagań: 10-25%

- projektowanie: 20-25%

- kodowanie: 15-20%

- testowanie i usuwanie błędów: 30-40%

Wykład 13 i 14

• Przyczyny i zakres zmian

• w samej organizacji: struktura, profil działania, lepsze zrozumienie systemu

• w otoczeniu prawnym

• na rynku działania firmy

• postęp techniczny

• problemy z zasobami

• błędy wykonania

• problemy z podwykonawcami i dostawcami

• Zakres zmian

• Czas: harmonogram

• Budżet: zestawienie kosztów, alokacja zasobów

• Produkty: baza danych, oprogramowanie, dokumentacja, sprzęt, procedury, szkolenia, serwis

• Prawo zgłaszania zmian - wykonawca i klient

• Klasyfikacje zmian

• Zagadnienia projektowe

- zauważone wady w produktach projektu

- niemożliwość spełnienia wymagań

- niespójność między elementami konfiguracji

- pomysły na ulepszenie

- możliwości większych korzyści

- problemy zarządcze

• Odstępstwa

- wynik projektu nie spełnia określonej specyfikacji

- Ze względu na zakres projektu: wpływające na zakres, bez wpływu na zakres projektu

• Znaczenie zmian

• Występują w każdym projekcie - należy przygotować się do ich obsługi

• Nie są patologią lecz rzeczywistością, nie należy szukać winnych lecz rozwiązań i sposobów

zapobiegania problemom

• Dokumentowanie zmian

1. Wniosek o zmianę

- osoba zgłaszająca i data

- rodzaj zmiany

- nazwa i opis żądanej zmiany

- opis powodu wprowadzenia zmiany

2. Raport o zmianie

- osoba analizująca zmianę i data

- rodzaj zmiany

- opis wykonania zmiany

- korzyści z wprowadzenia zmiany

- ocena trudności

- oszacowana pracochłonność

3. Polecenie wykonania zmiany

- osoba odpowiedzialna za wprowadzenie zmiany i data przekazania polecenia

- składnik konfiguracji podlegający zmianie

- szczegółowy opis techniczny wprowadzenia zmiany

- opis warunków do przeprowadzenia zmiany

- data wykonania zmiany

• Kontrola zmian

• Cel

- zachowanie kontroli nad projektem w każdym momencie jego trwania

• Mechanizm kontroli zmian

- zespół kontroli zmian (ZKZ)

- procedury kontroli zmian

- zarządzanie konfiguracją

- mierzenie wykonania

- dodatkowe procesy planowania

• Proces kontroli zmian

• Ustalenie linii bazowej (punkt odniesienia) - wszystko co nastąpi później jest zmianą

• Rodzaje linii bazowych

- funkcjonalna (przed rozpoczęciem realizacji projektu)

- alokacji zasobów (podczas realizacji procesu)

- produktu (po zbudowaniu i przetestowaniu produktu)

• Uzgodnienie procedury KZ i formularza Wniosku o zmianę

- identyfikacja i opis zmiany,

- uzasadnienie i priorytet,

- oszacowanie wpływu zmiany,

- propozycje sposobu rozwiązania problemu

• Wybór członków ZKZ

• Ustalenie sposobu pracy

• Obsługa zgłaszanych zmian

• Sprawozdania ze zmian

• Zadania ZKZ

• uzgodnienie procedury kontroli zmian

• stworzenie skutecznych mechanizmów rozstrzygania sporów

• uzgodnienie kryteriów przyjmowania zmian

• wnoszenie wniosków o zmianę

• rozpatrywanie wniosków o zmianę

• podejmowanie decyzji

• kontrola realizacji przyjętej zmiany

• Wersja oprogramowania

• Źródła powstawania nowych wersji

- różna funkcjonalność

- różne wykonanie

- usunięte usterki

- różne konfiguracje oprogramowania

- różne platformy sprzętowe

• Przykłady atrybutów identyfikacji wersji

- klient

- status wykonania

- platforma sprzętowa

- data utworzenia

• Obszar Zarządzania komunikacją [PMBOK]

• Procesy podstawowe

• Metody i techniki

• Procesy podstawowe [PMBOK]

- planowanie komunikacji - kto potrzebuje informacji, kiedy, w jaki sposób ma je otrzymać

- dystrybucja informacji - terminowe udostępnianie informacji interesariuszom projektu

• dokumenty projektu (korespondencja, notatki, dokumenty opisujące projekt)

• raporty z projektu (stan realizacji, problemy)

• prezentacje projektu

- sprawozdawczość wyników

- zamknięcie administracyjne - wytworzenie, zebranie i rozprowadzenie informacji umożliwiających formalne zakończenie etapu lub projektu

• dokumentacja pomiarów wykonania

• dokumentacja produktu

• pozostałe dokumenty projektu

• Sprawozdawczość wyników

• gromadzenie i przekazywanie informacji dotyczących wyników uzyskiwanych w projekcie

• zakres projektu

• harmonogram

• koszty

• jakość

• ryzyko

• zamówienia

• pomiary zaawansowania prac: raporty o stanie projektu

• prognozowanie postępów

• żądania zmian

• raporty z wykonania projektu

• Dokumentacja projektu

• Rodzaje

- plany

- protokoły

- raporty

- specyfikacje

- dokumentacja projektowa

- standardy, instrukcje, procedury

• Każdy rodzaj dokumentu wymaga

- metody jednoznacznej identyfikacji

- systemu numerowania

- przypisania odpowiedzialności

- procedury wprowadzania zmian

- metody zapewniania jakości

• Metody komunikowania

• Wymiary komunikacji

- pisemna, ustna

- wewnętrzna, zewnętrzna

- formalna, nieformalna

- pionowa, pozioma

• Modele nadawca - odbiorca

• Wybór medium komunikacji

• Styl komunikatu (struktura zdań, forma zwracania się, dobór słownictwa)

• Techniki prezentacji

• Techniki zarządzania spotkaniami

• Odbiorcy raportów kierownika przedsięwzięcia

• klient/sponsor

• użytkownik

• zarząd działu IT lub zarząd firmy

• komórka kontroli jakości

• zespoły realizacyjne

• Interakcje wewnątrz systemu

I = E(E-1)/2, gdzie E - liczba elementów, I - liczba interakcji




• Trójkąt zarządzania projektem [PMI] - ograniczenia




Kluczowe praktyki

• zarządzania projektem IT [zespół ekspertów Airlie Council]

• Planuj koszty i terminy

• Zarządzaj ludźmi

• Zarządzaj ryzykiem

• Zarządzanie oprzyj na miarach

• Śledź wartość uzyskaną

• Śledź błędy w celu zapewniania jakości

• Co to jest RUP?

• RUP jako podejście do tworzenia oprogramowania

• RUP jako proces inżynierii oprogramowania

• RUP jako produkt

• RUP jako podejście

• Dbałość o dostarczenie klientowi wartościowego produktu

• Skupienie uwagi na tworzeniu oprogramowania wykonywalnego

• Rozwiązywanie głównych zagrożeń jak najwcześniej

• Uwzględnianie zmian już we wczesnych fazach przedsięwzięcia

• Dążenie do możliwie wczesnego opracowania architektury wykonywalnej

• Budowa systemu z komponentów

• Współpraca - stworzenie zespołu

• Zapewnienie jakości na „co dzień”

• RUP - podejście iteracyjne

• Przystosowanie do zmieniających się wymagań

• Stopniowe i ciągłe scalanie części oprogramowania

• Ułatwienie ponownego użycia wspólnych części

• Znajdowanie i naprawianie błędów podczas kilku iteracji

• Lepsze wykorzystanie personelu

• Ciągłe uczenie się zespołu

• Ulepszanie i doskonalenie procesu podczas trwania całego przedsięwzięcia

• RUP jako proces inżynierii oprogramowania

• Dwuwymiarowa struktura

- dynamiczna (wymiar poziomy): dotyczy okresu trwania projektu: cykle, etapy, iteracje, kamienie milowe

- statyczna (wymiar pionowy): dotyczy sposobu logicznego grupowania elementów procesu: czynności, artefaktów i ról w podstawowe dyscypliny procesu

• Struktura statyczna - dyscypliny

• Dyscypliny inżynierskie

- Modelowanie działalności

- Zarządzanie wymaganiami

- Analiza i projektowanie

- Implementacja

- Wdrożenie

- Testowanie

• Dyscypliny wspierające

- Zarządzanie przedsięwzięciem

- Zarządzanie zmianami i konfiguracją

- Środowisko

• Kluczowe elementy procesu RUP jako składniki dyscyplin

• Rola (kto), produkt (co), zadanie (jak)

• Artefakty - elementy wytwarzane w ramach projektu lub używane do wytworzenia produktu końcowego, inaczej: informacje na wejściu albo wyjściu czynności:

- modele

- elementy modelu

- dokumenty

- kod źródłowy

- oprogramowanie wykonywalne

• Czynności (zadania) - jednostki pracy, dzielą się na kroki:

- myślowe

- wykonawcze

- przeglądowe

• Przepływy czynności - sekwencja czynności prowadzących do uzyskania wyniku

• Struktura dynamiczna - wymiar poziomy

• Rozpoczęcie (R)

• Opracowanie (O)

• Budowa (B)

• Przekazanie (P)

• Główne cele i kamienie milowe etapów projektu




• Elementy uzupełniające proces RUP

• Wskazówki - reguły, zalecenia, metody

• Szablony dotyczące artefaktów

• Poradniki użytkowania narzędzi

• Pojęcia

• Przewodniki

• Definicja architektury systemu informatycznego [M.Shaw, D. Garlan]

• Zbiór istotnych decyzji dotyczących:

- Organizacji systemu oprogramowania

- Wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany

- Składania tych elementów w coraz większe podsystemy

- Stylu architektonicznego, wg którego tworzy się konstrukcję systemu

• RUP jako produkt

• Biblioteka najlepszych rozwiązań praktycznych, opracowanych przez IBM Software i partnerów

• Narzędzia do udostępniania procesu (MyRUP)

• Narzędzia do konfiguracji RUP

• Narzędzia do autorskiego przygotowania procesu (RPW)

• Społeczność (rynek) - on-line sieć twórców oprogramowania

• Przykładowe artefakty RUP

• Modelowanie działalności

- Wizja działalności

- Słownik działalności

- Zasady działalności

- Dokumentacja architektury działalności

- Model analizy działalności

• Wymagania

- Słownik

- Wizja

- Model przypadków użycia

- Atrybuty wymagań

- Dokumentacja architektury oprogramowania

• Analiza i projektowanie

- Dokumentacja architektury oprogramowania

- Projekt pakietu

- Klasa projektu

- Model danych

- Model projektu

- Prototyp interfejsu użytkownika

- Model wdrożenia

• Implementacja

- Dokumentacja architektury oprogramowania

- Model implementacji

- Plan scalania wyrobów

- Wyrób

- Wyniki testowania

• Testowanie

- Plan testowania

- Strategia testowania

- Scenariusz testowania

- Zestaw testów

- Dane testowe

- Wyniki testowania

- Wytyczne dla przedsięwzięcia

• Wdrożenie

- Plan wdrożenia

- Spis inwentarza

- Materiały szkoleniowe

- Informacje o wyrobie

- Jednostka wdrożenia

- Artefakty instalacji

- Żądania zmian

• Zarządzanie przedsięwzięciem

- Zapis recenzji

- Spis zagrożeń

- Przypadek działalności

- Plan tworzenia oprogramowania

- Plan pomiarów

- Plan zapewnienia jakości

- Plan iteracji

- Ocena stanu

• Środowisko

- Proces tworzenia

- Przypadek tworzenia

- Wytyczne dla przedsięwzięcia

- Szablony dla przedsięwzięcia

- Narzędzia

- Infrastruktura tworzenia

• Porównanie metodyki PMI z metodyką PRINCE2

• Grupy procesów zarządzania projektami [PMBOK]

• rozpoczęcia (inicjowania) - formalne zatwierdzenie projektu lub jego etapu do realizacji (karta projektu)

• planowania - określenie i precyzowanie celów projektu, wybór najlepszego z dostępnych sposobów działania prowadzącego do realizacji celów

• realizacji - koordynacja ludzi i innych zasobów w celu wykonania przyjętego planu

• kontroli - systematyczne monitorowanie i mierzenie wykonania projektu, umożliwiające wykrywanie odchyleń od planu

• zakończenia - formalna akceptacja otrzymanych wyników projektu lub etapu projektu oraz zamknięcie projektu

• Obszary wiedzy o zarządzaniu projektami [PMBOK]

1. Integracja projektu

2. Zakres projektu

3. Czas w projekcie

4. Koszty projektu

5. Jakość w projekcie

6. Zasoby ludzkie w projekcie

7. Komunikacja w projekcie

8. Ryzyko w projekcie

9. Zamówienia w projekcie

• Mapowanie procesów zarządzania projektami i obszarów wiedzy

• liczba obszarów wiedzy - 9

• liczba grup procesów zarządzania projektami - 5

• liczba wszystkich procesów - 39

• Procesy planowania - kluczowe i obszary wiedzy

• planowanie zakresu (2)

• doprecyzowywanie zakresu (2)

• identyfikacja działań (3)

• określenie kolejności działań

• szacowanie czasu trwania działań (3)

• opracowanie harmonogramu (3)

• planowanie zarządzania ryzykiem (8)

• planowanie zasobów (4)

• szacowanie kosztów (4)

• budżetowanie kosztów (4)

• opracowywanie planu projektu (1)

• Wspierające procesy planowania i obszary wiedzy

• planowanie jakości (5)

• planowanie organizacyjne (6)

• pozyskiwanie personelu (6)

• planowanie komunikacji (7)

• identyfikacja ryzyk (8)

• jakościowa analiza ryzyk (8)

• ilościowa analiza ryzyk (8)

• planowanie reakcji na ryzyka (8)

• planowanie zamówień (9)

• planowanie zapytań (9)

• Procesy realizacji i obszary wiedzy

• realizacja planu projektu (1)

• zapewnianie jakości (5)

• kształtowanie zespołu (6)

• dystrybucja informacji (7)

• zebranie ofert (9)

• wybór dostawców (9)

• administrowanie kontraktem (9)

• Przykładowy proces - realizacja planu projektu

• wprowadzenie w życie planu projektu poprzez realizację działań

• proces w największym stopniu zależny od obszaru zastosowań, w którym powstaje produkt projektu

• Rezultaty procesu

- wyniki prac: rezultaty wykonywanych działań

• wyniki wymierne: produkty cząstkowe, produkty pośrednie

• wyniki niewymierne: wykwalifikowany personel

- żądania zmian

• zmiany zakresu

• modyfikacja oszacowanych kosztów

• modyfikacja harmonogramu

• Proces zapewniania jakości

• planowane i regularnie prowadzane działania, mające na celu spełnianie odpowiednich norm jakości

• Materiały wejściowe

- plan zarządzania jakością

- wyniki pomiaru kontroli jakości

- definicje operacyjne: precyzyjne sformułowania obiektu i sposobu mierzenia

• Wyniki

- doskonalenie jakości

• Proces kształtowania zespołu

• doskonalenie indywidualnych umiejętności

• doskonalenie zachowań (rozwiązywanie konfliktów)

• doskonalenie kompetencji

• Procesy zakończenia

• zamknięcie administracyjne (7)

- cel: uzyskanie formalnej akceptacji sponsora lub klienta po osiągnięciu zakładanego celu lub przerwaniu projektu/etapu,

- udokumentowanie rezultatów projektu,

- archiwizacja informacji.

• zamknięcie kontraktu (9)

- skompletowanie uporządkowanej dokumentacji,

- pisemne zawiadomienia o zakończeniu kontraktu.

• Metodyka PRINCE

• Projects IN Controlled Environments [PRINCE]

• Metodyka wprowadzona w 1989 r. na bazie metodyki PROMPT (Project Resource, Organisation, Management & Planning Technique - połowa lat 70-tych)

• od 1982 r. licencja wykupiona przez Rząd W. B.

• wersja PRINCE2 od 1996 r. stosowana w wielu branżach i różnej wielkości projektów

• Struktura metodyki PRINCE2

- procesy,

- komponenty,

- techniki.

• Grupy procesów w PRINCE2

• Strategiczne zarządzanie projektem

• Przygotowanie założeń projektu

• Inicjowanie projektu

• Planowanie

• Sterowanie etapem

• Zarządzanie wytwarzaniem produktów

• Zarządzanie przejściem do następnego etapu

• Zamykanie projektu

• Komponenty

• Uzasadnienie biznesowe: wymierne korzyści

• Organizacja projektu: struktura i opis ról

• Plany: produkty, działania, zasoby

• Elementy kontroli

• Jakość w środowisku projektu

• Zarządzanie ryzykiem

• Sterowanie zmianami

• Zarządzanie konfiguracją

• Techniki

• WBS

• Diagram następstw

• Planowanie ukierunkowane produktowo

• Przeglądy jakości

• Rejestr zmian

• Analiza wpływu proponowanych zmian

• Podstawowe założenia projektu (PZP)

• Składniki przygotowania do rozpoczęcia projektu

- tło, cele, zakres

- ograniczenia

- główne produkty/wyniki

- zarys uzasadnienia biznesowego

- oczekiwania jakościowe klienta

- kryteria akceptacji

- znane ryzyka

• Zainicjowanie projektu: Dokument Inicjujący Projekt (DIP) powstaje w wyniku dwóch procesów: Przygotowanie projektu i Inicjowanie projektu, stanowi punkt odniesienia dla całego projektu - zawiera rozbudowane w/w składniki

• Poziomy w strukturze zarządzania organizacji wg PRINCE2

• Czteropoziomowa struktura zarządzania

- Zarząd lub Kierownictwo programu - strategiczne zarządzanie organizacją

- Zespół Zarządzania Projektem:

• Komitet sterujący

• Kierownik projektu

• Kierownik(-cy) zespołów

• Zespoły zadaniowe - nie objęte w strukturze zarządzania przez PRINCE2

• Struktura organizacyjna PRINCE2




• Standardowa struktura organizacyjna PRINCE2

• Kierownictwo organizacji lub programu

• Komitet sterujący: Przewodniczący, Główny dostawca, Główny Użytkownik

• Nadzór projektu (niezależny od Kierownika projektu, należy do odpowiedzialności Komitetu sterującego)

• Kierownik projektu

• Kierownik(-cy) Zespołu (opcjonalnie)

• Wsparcie projektu (opcjonalnie)

• Wymagane trzy role: Biznes, Użytkownik, Dostawca

• Poziomy raportowania wg PRINCE

• inicjowanie przedsięwzięcia

• koniec etapu

• środek etapu

• raport sytuacyjny

• punkt kontrolny

• zamknięcie przedsięwzięcia

• Zwinne zarządzanie projektami

• Zwinne zarządzanie projektami (ang. Agile Project Management) - zbiór różnych metodyk, określanych jako zwinne bądź lekkie, oraz narzędzi stosowanych w zarządzaniu złożonymi i innowacyjnymi projektami - głównie informatycznymi

• Dokument „Manifesto for Agile Software Development” (2001) zainicjował głębokie przemiany w środowiskach programistycznych, przyjętych też w innych obszarach zarządzania projektami

• Powstanie APM było reakcją na mało elastyczne metody zarządzania projektami informatycznymi, uważane za zbyt sformalizowane i mało efektywne

• Niektóre założenia zawarte w Agile Manifesto

• Osiąganie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania

• Działające oprogramowanie jest dostarczane w częściach, okresowo: co tydzień, co miesiąc

• Podstawową miarą postępu jest działające oprogramowanie

• Codzienna współpraca między biznesem i wytwarzaniem

• Bezpośredni kontakt jest najlepszą formą komunikacji w zespole i poza nim

• Projekty są budowane poprzez zmotywowane indywidualności, które posiadają pełne zaufanie

• Zespoły realizacyjne są samoorganizujące

• Ciągła uwaga jest skupiona na aspektach technicznych i dobrym projektowaniu

• Regularna adaptacja do zmieniających się wymagań

• Cechy charakterystyczne metodyk zwinnych

• ograniczenie liczby dokumentów

• planowanie w krótszej perspektywie czasowej

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

• otwartość na zmiany

• niewielkie zespoły projektowe

• brak wydzielania faz projektowych

• Etapy projektu przy podejściu metodyk zwinnych

1. Budżetowanie

2. Inicjowanie projektu

3. Iteracyjne wytwarzanie

4. Szkolenie

5. Wodowanie - wdrożenie w środowisku użytkownika

6. Strojenie - rozwiązywanie problemów

7. Oficjalne zamknięcie projektu

8. Pielęgnowanie

• Przykłady metodyk adaptacyjnych

• Programowanie ekstremalne (eXtreme Programming (XP))

• Scrum, Crystal, Lean Development

• Adaptive Software Development

• Feature Driven Development

• Behavior Driven Development

• Modyfikacje do podejścia zwinnego: Prince II, RUP, XPrince

• Metoda Scrum

Podstawowe założenia:

• iteracje - najczęściej 30-dniowe przedziały czasowe - sprint

• przyrostowe tworzenie oprogramowania

• empiryczna kontrola procesu: przejrzystość, kontrola, adaptacja

• samorganizujący się zespół projektowy

Narzędzia: SpiraPlan® - Scrum Project Management

• Role w Scrum

Właściciel produktu

• Jest właścicielem definicji sukcesu.

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

• Zarządza wskaźnikiem ROI (return on investment) 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 wielu szefów, różnych opinii i zakłóceń.

Mistrz

• Jedna osoba z zespołu wciela się w rolę mistrza ułatwiającego codzienną pracę zespołu. Mistrz nie robi nic innego, całe jego obciążenie to pełnienie roli Mistrza w pełnym wymiarze czasu pracy.

• 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 są zgłaszane 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 projektem.

Członek zespołu projektowego - tzw. „świnki”

• Właściciel produktu

• Mistrz

• Wykonawcy: architekt, programista, analityk, tester, ekspert …

Pozostali interesariusze projektu - tzw. „kurczaki”,

• nie posiadają formalnej odpowiedzialności

• są zainteresowani projektem,

• biorą udział w spotkaniach przeglądu sprintu,

• podczas spotkań nie mogą mówić, co zespół powinien zrobić

• Artefakty Scrum

BACKLOG (lista zaległości) produktu - rejestr produktowy

• Lista wymagań funkcjonalnych i niefunkcjonalnych projektu, ułożonych według priorytetów z przewidywanym czasem na ich zakończenie i wdrożenie.

• Szacunki są podawane w dniach i są bardziej precyzyjne dla wyższych pozycji w kolejce zaległości produktu.

• Priorytety pozycji powinny być ustalone na podstawie największej wartości dla firmy, obliczone za pomocą metody ROI.

• Ta lista w trakcie realizacji rozwija się i zmienia.

BACKLOG sprintu - rejestr zaległości sprintu

• Rejestr zadań, które zespół Scrum zobowiązuje się wykonać całkowicie w bieżącym sprincie.

• Pozycje zaległości sprintu pochodzą z rejestru zaległości produktu.

• Zespół kieruje się priorytetami ustalonymi przez właściciela produktu i swoimi oszacowaniami dotyczącymi czasu ich wykonania.

• Krytyczne jest to, że to sam zespół wybiera pozycje z listy zaległości, ponieważ to zespół zobowiązuje się do zakończenia tych zadań.

• Iteracja w Scrum - sprint

Sprint

• Sprint jest to czas przeznaczony na opracowanie jednego przyrostu produktu. Jest to metoda „time boxing: czas, koszt i zakres, ważniejszy jest zakres niż poślizg w dacie zakończenia.

• Sprint obejmuje projektowanie, programowanie, testowanie i dokumentowanie.

• Tylko po rozpoczęciu sprintu zespół może dodawać lub usuwać elementy z rejestru zaległości sprintu.

• Jeżeli osiągnięcie celu sprintu nie ma sensu, to następuje tzw. Nadzwyczajne zakończenie sprintu.

Sprint wydania

• Wydanie oprogramowania do działania (produkcji) wymaga specjalnego sprintu, nazywanego „sprintem wydania”.

• Do tego sprintu jest dedykowany zespół sprintu wydania

Spotkanie planowania sprintu

• Celem jest ustalenie rejestru zaległości sprintu

• Właściciel produktu opisuje właściwości o najwyższym priorytecie, a zespół decyduje, do czego może się zobowiązać i co może dostarczyć w danym sprincie. Odbywa się to w ciągu dwóch kolejnych spotkań (4 godziny),

• Zespół planuje zadania do wykonania, których zbiór tworzy rejestr zaległości sprintu

• Codzienny Scrum

• Codzienne spotkanie trwające 15 minut, ważne jest aby odbywało się codziennie w tym samym miejscu i czasie.

• Podczas spotkania zespół siedzi w kręgu naprzeciwko siebie i każdego członka zespołu dotyczą następujące trzy pytania:

1. Co zrobiłeś od ostatniego spotkania?

2. Co będziesz robił od teraz do następnego spotkania?

3. Jakie problemy przeszkadzają Ci w wykonywaniu pracy?

• Przegląd sprintu

• Na koniec każdego sprintu odbywa się spotkanie przeglądowe sprintu. Podczas tego spotkania zespół Scrum demonstruje, co zostało zakończone w fazie tego sprintu. Zwykle jest to forma prezentacji nowych funkcji.

• Zaleca się, aby spotkania przeglądowe sprintu było nieformalne, z zasady zakazuje się slajdów programu PowerPoint i pozwala na poświęcenie nie więcej niż dwie godziny czasu na przygotowanie

się do tego spotkania. Spotkania nie mogą stać się uciążliwe dla zespołu, powinny być naturalnym wynikiem sprintu.

• Uczestnicy spotkania przeglądowego sprint: właściciel produktu, zespół Scrum, mistrz, zarząd, klienci i inżynierowie z innych projektów.

• Podczas tego spotkania projekt jest porównywany z celem sprintu ustalonym podczas spotkania planowanie sprintu. Najlepiej jest, gdy zespół zakończy każdą pozycję z rejestru produktów dla tego

sprintu, ale ważniejsze jest osiągnięcie celu sprintu.

• Retrospektywa sprintu

• To spotkanie jest wykorzystywane przez mistrza do omówienia zakończonego Sprintu i ma na celu określenie, co można zmienić w następnym Sprincie, by praca była przyjemniejsza i bardziej

produktywna.

• Dyskusja może dotyczyć wszystkiego, co wpływa na pracę zespołu: procesy, praktyki, komunikację, środowisko, narzędzia.

• Retrospektywa Sprint jest ważnym narzędziem, które pozwala zespołowi na ciągłą poprawę w całym cyklu życia projektu.

• Scrum powinien być postrzegany jako ramy, które powinny być odpowiednio dostosowane do danego projektu, zespołu i konkretnej sytuacji.

• Korzyści z zastosowania metody Scrum

• Zapewnia najwyższe wartości firmy na wczesnym etapie projektu, unikając jednocześnie nierealistycznych wymagań i niepotrzebnej pracy

• Poprawia satysfakcję klienta

• Dostarcza podejścia kierowanego przez klienta

• Skupia się na szybkości dostawy

• Zapewnia otwartość i przejrzystość dla klientów

• Usuwa przeszkody w sposób priorytetowy i systematyczny

• Poprawia utrzymanie pracowników przez umożliwienie oraz promowanie samorządności, komunikacji w zespole, naukę i rozwój

• Efekty firmy Microsoft ze Scrum: czterokrotny wzrost średniej wydajności i dwanaście razy lepsza jakość

• Podstawowe różnice w podejściu tradycyjnym i Scrum

• Kaskadowy model zarządzania projektem bazuje na dokładnie zdefiniowanej metodyce, najpierw z góry określone wymagania, logiczny podział pracy, estymacja, planowanie, a następnie rozpoczęcie realizacji, w której ogranicza się zmiany, jako zagrożenie dla planu

• W Scrum oczekuje się zmian, co oznacza, że końcowy wynik będzie produktem, który w większym stopniu spełni potrzeby klientów na zakończenie projektu.

• W Scrum zakłada się, że nastąpią znaczące zmiany linii bazowej w trakcie realizacji projektu.

• Jest to nieprzewidywalne środowisko zarządzania projektami, do którego zaleca się wykorzystywanie metod empirycznych, a nie deterministycznych.

• Modele jakości oprogramowania

• Przyczyny wzrostu wymagań jakościowych

• Tendencje w gospodarce światowej

• Nowe uregulowania prawne

• Wzrost oczekiwań klientów

• Istotne cele przedsiębiorstwa

• Interesariusze jakości projektu IT

Kto ma być usatysfakcjonowany ?

• Klient/sponsor

• Użytkownik

• Wytwórca/obsługa serwisowa

W celu ich usatysfakcjonowania program powinien odpowiadać ich potrzebom

• Definicje jakości

1. Jakość jest tym, czego brak oznacza straty dla wszystkich [G. Taguchi]

2. Prawdziwa jakość jest jak duch, o którym każdy mówi, ale którego nikt nie widział [F. Duc de la Rochefouccauld]

3. Pełne zaspokojenie określonych potrzeb klienta przy minimalnych kosztach własnych [J. Bank]

4. Zbiorcza charakterystyka produktu i serwisu z uwzględnieniem marketingu, projektu, wykonania i utrzymania, która powoduje, że dany produkt i serwis spełniają oczekiwania użytkownika [A.V. Feigenbaum]

• Definicja jakości [PN-EN ISO 9000]

• Jakość to stopień w jakim zbiór inherentnych właściwości spełnia wymagania.

• Właściwość inherentna: stałą właściwość wyrobu, procesu lub systemu, która istnieje sama w sobie.

• Wymagania: potrzeby lub oczekiwania, które zostały

• ustalone,

• przyjęte zwyczajowo,

• są obowiązkowe.

• Klasy właściwości [PN - ISO]

• Fizyczne: mechaniczne, elektryczne, chemiczne.

• Odbierane zmysłami: zapach, dotyk, smak, wygląd, dźwięk.

• Behawioralne: uczciwość, uprzejmość, prawdomówność.

• Czasowe: punktualność, wydajność, dostępność.

• Ergonomiczne: fizjologiczne, związane z bezpieczeństwem człowieka.

• Funkcjonalne: np. czynności robota domowego.

• Jakość produktu informatycznego [IEEE]

• Stopień zrozumienia i odkrycia potrzeb w trakcie definicji wymagań

• Stopień przekształcenia definicji wymagań w produkt informatyczny

• Stopień wspierania produktu

• Stopień, w jakim produkt odpowiada wymaganiom sprecyzowanym i domniemanym

• Jakość produktu informatycznego [ISO/IEC 14598-1:1999]

Zbiór charakterystyk pozwalających na stwierdzenie zadowolenia w odniesieniu do wywnioskowanych potrzeb.

• Model jakości oprogramowania

Zbiór charakterystyk i relacji między nimi, które stanowią podstawę dla specyfikacji wymagań jakości

i oceny jakości.

• Przykłady modeli jakości oprogramowania

Podejście hierarchiczne

• McCalla

• Boehma

• FURPS

• ISO 9126

• Dromeya

Podejście wielowymiarowe

• Ortega, Perez, Rojas

• Zasada budowy modeli jakości oprogramowania




Nie ma rysunków ze slajdów 90 - 92

• FURPS [Grady i Caswell HP 1987]

• Funkcjonalność

• Łatwość użytkowania

• Niezawodność

• Wydajność

• Łatwość wspierania

• Model Dromeya

Trzy modele wyróżnione ze względu na etapy cyklu życia:

• model wymagań

• model projektu

• model implementacji

Wprowadza dodatkową charakterystykę:

• dojrzałość procesu

• Model i norma ISO/IEC 9126

Jako konsensus między różnymi modelami na podstawie modelu McCalla

Trzy poziomy

• charakterystyki

• podcharakterystyki

• metryki

• Koncepcja modelu jakości




• Składniki normy jakości PI [ISO/IEC 9126]

9126 - 1: model jakości

9126 - 2: metryki zewnętrzne

9126 - 3: metryki wewnętrzne

9126 - 4: metryki jakości użytkowej

• Definicja jakości wewnętrznej [ISO/IEC 9126-1]

• Jakość wewnętrzna to ogół cech oprogramowania z wewnętrznego punktu widzenia.

• Jest mierzona i oceniana podczas projektowania i kodowania w stosunku do wymagań określonych w specyfikacji wymagań (modele statyczne i dynamiczne) i kodzie źródłowym programu, przy użyciu metryk wewnętrznych.

• Metryki wewnętrzne

• Miara ilościowa, stosowana do mierzenia atrybutu lub charakterystyki produktu informatycznego, wyprowadzonej pośrednio lub bezpośrednio z produktu

• Stosowana do produktu w postaci źródłowej, podczas projektowania i kodowania na wczesnym etapie rozwoju

• Definicja jakości zewnętrznej [ISO/IEC 9126-1]

• Jakość zewnętrzna to ogół cech oprogramowania z zewnętrznego punktu widzenia.

• Mierzona i oceniana względem uruchamianego programu podczas testowania w środowisku symulowanym i na danych testowych, przy użyciu metryk zewnętrznych.

• Podczas testowania większość usterek powinna być wykryta i usunięta, jednak niektóre błędy, po zakończeniu testowania, nadal mogą zostać.

• Metryki zewnętrzne

• Miara ilościowa, stosowana do mierzenia atrybutu lub charakterystyki produktu informatycznego, wyprowadzonej z zachowania całego systemu lub jego części

• Stosowana do produktu w postaci wykonywalnej, podczas testowania lub działania, w późniejszym etapie rozwoju lub po wprowadzeniu do procesu eksploatacji

• Definicja jakości użytkowej [ISO/IEC 9126-1]

Zdolność produktu do umożliwienia określonym użytkownikom osiągnięcia wyspecyfikowanych celów w zakresie

• efektywności,

• produktywności,

• bezpieczeństwa,

• satysfakcji

w specyficznym kontekście użycia.




• Funkcjonalność

Zdolność PI do dostarczania funkcji ustalonych i implikowanych potrzebami, podczas użycia programu

przy ustalonych warunkach.

Odpowiedniość - obecność i trafność zbioru funkcji dla wyspecyfikowanych zadań

Dokładność - spełnienie warunków zgodności wyników

Otwartość - współdziałanie z konkretnymi systemami

Zgodność - ze standardami, zasadami, regulacjami prawnymi i innymi założeniami

Bezpieczeństwo - zapobieganie nieuprawnionemu dostępowi do programów i danych

• Niezawodność

Zdolność PI do utrzymania ustalonego poziomu wydajności podczas jego użycia przy ustalonych warunkach.

Dojrzałość - częstość awarii w wyniku błędów oprogramowania

Tolerancja na błędy - możliwość utrzymania ustalonego poziomu wykonania w przypadku awarii oprogramowania lub naruszenia jego interfejsu

Odtwarzalność po awarii - zdolność do odtworzenia poziomu wykonania i odzyskania danych spowodowanych awarią oraz nakład potrzebny na to odtworzenie

• Użytkowalność

Zdolność PI do bycia zrozumiałym, nauczalnym i atrakcyjnym dla użytkownika podczas jego użycia przy ustalonych warunkach.

Zrozumiałość - nakład poniesiony na rozpoznanie koncepcji i jej zastosowanie

Łatwość uczenia się - nakład poniesiony na naukę posługiwania się aplikacją

Obsługiwalność - nakład użytkownika związany z działaniem i kontrolą działania oprogramowania

• Wydajność

Zdolność PI do dostarczenia odpowiedniej wydajności w relacji do liczby zużywanych zasobów przy

ustalonych warunkach.

• W odniesieniu do czasu

• W odniesieniu do zasobów

• Pielęgnowalność

Zdolność PI do jego modyfikacji. Modyfikacja może dotyczyć korekty, usprawniania lub adaptacji programu do zmian w środowisku, zmian w wymaganiach i specyfikacji funkcji.

Możliwość analizy - nakład potrzebny do wykonania diagnozy braków, błędów lub identyfikacji części programu do zmiany.

Modyfikowalność - nakład potrzebny do wykonania modyfikacji, usunięcia błędów lub zmian środowiskowych.

Stabilność - ryzyko nieoczekiwanych efektów zmian.

Testowalność - nakład potrzebny do wykonania walidacji zmodyfikowanego oprogramowania.

• Przenośność

Zdolność PI do przenoszenia programu z jednego środowiska do innego

Adaptacyjność - zdolność do adaptacji w określonych środowiskach bez wykonania dodatkowych czynności lub do adaptacji przy środkach ustalonych do jej przeprowadzenia

Instalowalność - nakład potrzebny do instalacji oprogramowania w określonym środowisku

Dostosowalność - nakład na dostosowanie oprogramowania do standardów lub konwencji związanych z wymaganiami przenośności

Zastępowalność - atrybuty oprogramowania określające jego zdolność i wielkość nakładów potrzebnych na użycie innego, ustalonego oprogramowania w jego środowisku

• Charakterystyki jakości użytkowej [ISO/IEC 9126]

• Efektywność (Sprawność)

• Produktywność

• Bezpieczeństwo

• Satysfakcja

• Podsumowanie wykładu 2010/2011

1. Wprowadzenie do zarządzania projektami. Warstwy zarządzania i role w projekcie. WBS.

2. Modele cyklu życia produktu i projektu. Kluczowe produkty etapów przedsięwzięcia

informatycznego.

3. Proces rozpoczęcia projektu: karta projektu, uzasadnienie biznesowe. Zagrożenia i krytyczne

czynniki powodzenia projektu.

4. Planowanie realizacji projektu informatycznego: CPM, CCS. Kontrola realizacji

przedsięwzięcia informatycznego (metoda EVM). Narzędzie Project.

5. Miary i metryki oprogramowania.

6. Metody FP i UCP - przykłady zastosowania do szacowania wielkości oprogramowania.

7. Wybrane aspekty projektowania: menu aplikacji, projekt raportu, reguły projektowania

relacyjnej bazy danych. Zasady projektowania interfejsu użytkownika.

8. Modele szacowania wymiarów projektu: metoda Albrechta, Halsteada, COCOMO, metody

uproszczone. Rzetelność oszacowania. Standardowa procedura szacowania.

9. Zarządzanie zmianami w projekcie. Komunikacja i dokumentacja projektu.

10. Metodyki tradycyjne w zarządzaniu projektami (PMI, PRINCE, RUP).

11. Metodyki adaptacyjne: metoda Scrum.

12. Jakość i modele jakości produktu informatycznego

1

---