Inżynieria oprogramowania

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.

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

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.

Struktura organizacyjna projektu

• WARSTWY ZARZĄDZANIA PROJEKTEM

• zarząd organizacji

• wypracowanie strategii

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

• wyznaczenie rady projektu do działania w ustalonych ograniczeniach

• rada projektu

• kierowanie całością projektu,

• odpowiedzialność za wyniki prac,

• mianowanie i rozliczanie kierowników projektu,

• zatwierdzanie zmian,

• przyjmowanie wyników projektu.

Podejmowanie decyzji w zakresie:

• oceny zrozumienia przez kierownika projektu oczekiwań

• oceny sposobu gospodarowania finansami

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

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

• ustalenie płatnika za główne zmiany

• oceny przygotowania organizacji do akceptacji produktu oferowanego przez kierownika projektu

• ocena speł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 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

• znaczenia przedsięwzięcia

• dostępności personelu

Podstawowe role w przedsięwzięciu informatycznym

• sponsor/klient

• użytkownik

• kierownik przedsięwzięcia/zespołu

• specjalista ds. jakości, ryzyka

• analityk

• projektant

• programista

• administrator

• dokumentalista

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

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

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

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

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

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

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

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

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

• 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

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

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

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

• 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

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

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

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

Krytyczne czynniki powodzenia cyklu życia projektu

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

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ń

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

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

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

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

Metoda łańcucha krytycznego

• 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

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

• 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

• 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

• 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

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

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

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)

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

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)

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

1. 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

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

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ść

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

Metoda Function Point (FP)

POZIOMY STOSOWANIA METODY

• System tworzony od początku

• System modyfikowany

• System działający

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 oraz EQ

• 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