Fedorov po polsku
Przyczyny opóz
nień podczas tworzenia oprogramowania:
1. Duża złożoność systemów informatycznych.
2. Niektórych przedsięwzięć nie da się łatwo powtórzyć  np. z powodu zmiany technologii
(zwykle przy unowocześnianiu pewnych projektów)
3. Trudności w ocenie postępu (parę błędów może powodować duże opóz
nienia, nie można
wywnioskować stopnia zaawansowania programu po ilości linijek kodu.
4. Pozorna łatwość tworzenia poprawek.
5. Tworzenie projektu, który przekracza nasze możliwości.
6. Zbytni optymizm w doborze ekipy tworzącej projekt  trzeba mieć na uwadze, że ludzie nigdy
nie stworzą idealnego zespołu.
7. Duża integracja projektu i wiele zależności między poszczególnymi modułami.
8. Wykorzystanie nowych (wiodących) technologii  pracownicy muszą ją najpierw poznać.
9. Tworzenie jakiegoś innowacyjnego oprogramowania  nie ma skąd brać przykładu, np.
oprogramowanie dla banków
10. Oprogramowanie, które tworzymy wymaga częstych aktualizacji.
Przyczyny niepowodzeń:
1. Posiadamy niepełne wymagania (!)
2. Brak uczestnictwa użytkownika w projekcie
3. NiewystarczajÄ…ce zasoby
4. Nierealistyczne oczekiwania
5. Brak wsparcia ze strony kierownictwa
6. Częste zmiany wymagań i specyfikacji
7. Brak planowania
8. Oprogramowanie przestaje być aktualne
9. ZÅ‚e zarzÄ…dzanie
10. Nieznajomość technologii
Sposoby spojrzenia na proces:
1. Sekwencja działań.
2. Przepływ Danych (Data Flow)
3. Nastawione na rolÄ™.
Metody programowania:
" Top-Down (dekompozycja)
" Bottom-Up (kompozycja)
Sposoby realizacji oprogramowania:
" Model kaskadowy (Waterfall):
" Model spiralny.
" Realizacja kierowana dekomentowaniem (?).
" Prototypowanie.
" Podejście ewolucyjne.
" Kampania transformacji.
" Integracja lub montaż gotowych komponentów.
" Integrowany proces Ration Rose:
Modelowanie biznesu.
Określenie wymagań.
Analiza i projektowanie Systemów Informatycznych.
Implementacja i testowanie systemów.
Deployment  fizyczne rozmieszczenie elementów systemu.
Konfiguracja.
Modelowanie RUP (Rational Unified Process):
1. Inseption ogólne określenie problemu, ustalamy tylko najważniejsze cele specyfikacji. Możemy
tu określić zakres działania systemu, co powinien zawierać, a czego nie. Najważniejszą rzeczą jest
wywnioskowanie, czy w ogóle warto tworzyć ten system, na ocenę składają się kwestie:
1. Czy Ta architektura jest zrozumiała.
2. Czy znamy potencjalne ryzyka, jeżeli tak, to czy sobie z nimi poradzimy.
3. Czy projekt będzie dochodowy.
4. Czy damy radę stworzyć całość systemu.
5. Czy wszyscy udziałowcy wykazują chęć tworzenia systemu.
2. Elaboration  po tej fazie architektura powinna być gotowa. Należy rozstrzygnąć kwestie:
1. Czy uzyskaliśmy bazową architekturę całego systemu ?
2. Na ile ta architektura jest elastyczna ?
3. Czy architekturę da się dalej rozwijać ?
4. Czy udało nam się zniwelować wszelkie ryzyko by nie zagrażało systemowi?
5. Czy mamy plan na takim poziomie, by złożyć konkretną biznes-propozycje? (harmonogram,
koszt, czas wytworzenia).
3. Construction - czy dany produkt posiada wszystkie podstawowe funkcjonalności, w tej fazie:
przygotowujemy produkt, jego konkretne warianty.
4. Transition  oddajemy produkt użytkownikowi  tu sprawdzamy, czy sprawdza się w praktyce.
Jest to bardzo czasochłonna i droga faza. Testowanie powinno wykryć wszystkie niedociągnięcia.
Jeśli projekt się nie sprawdził - wracamy do pierwszej fazy cyklu.
Gdy rozpoczynamy projekt:
 Określamy zakres działania systemu.
 Dekomponujemy.
 Wybieramy i dekomponujemy proces (?).
 Planujemy; należy odpowiedzieć na pytania:
co trzeba zrobić?
po co?
na kiedy ?
kto jest za co odpowiedzialny?
skąd wziąć ludzi, udziałowców?
Podstawowe czynności związane z zarządzaniem projektem:
1. Napisanie propozycji zwiÄ…zanej z opracowaniem nowego systemu.
2. Planowanie projektu i harmonizacja.
3. Obliczenie kosztu projektu.
4. Monitoring projektów i przeglądy.
5. Ocena i wybór personelu.
6. Napisanie sprawozdań.
Planowanie  najważniejsze elementy
plan jakości
plan walidacji - zasoby, harmonogram przeprowadzony z walidacjÄ…, testowanie systemu pod
kątem wymagań
zarzÄ…dzanie konfiguracjÄ…
plan pielęgnacji systemu  określenie, jakie problemy mogą się pojawić w systemie,
zarzÄ…dzanie kosztami i pracÄ… zwiÄ…zanÄ… z jego utrzymaniem
plan tworzenia zespołu  ważne tu by opisać doświadczenia zespołu
Powinniśmy stworzyć dokumentację zawierającą:
Wprowadzenie - cechy projektu, ograniczenia.
Organizacja całego projektu - sposób doboru kadry, obowiązki.
Zarządzanie ryzykiem  potencjalne ryzyko i przeciwdziałanie mu.
Opis zasobów sprzętowych i programowych - koszta, harmonogram zakupów.
Jak jest podzielona praca  spodziewane efekty każdego z etapów, planowanie  kamieni
milowych .
Harmonogram  sposób współpracy między ludz
mi.
Monitorowanie, raportowanie  opis mechanizmów kontroli, związanych z projektem, tj.
jak zorganizować projekt dla menadżera projektu, by mógł śledzić jego postępy.
Dla każdego elementu projektu RUP przewiduje szablony:
Raport:
" analiza wymagań - definicja wymagań dla konkretnego projektu
" opracowanie prototypu
" projektowanie systemu informatycznego - wdrożenie architektury
" tworzenie specyfikacji wymagań
Harmonogram:
" Ustalenie zależności pomiędzy poszczególnymi zadaniami
" Oszacowanie zasobów dla każdego zadania
" Przydział ludzi do konkretnych zadań
" Wykresy typu diagram Gantta
" Ustalenie czasu na jedno zadanie (min. tydzień, maks. 8 tygodni)
Paskowe diagramy typu PERT:
Należy określić ścieżkę krytyczną.
Ryzyko  rodzaje:
" wpływające na projekt  zaburzające harmonogram
" wpływające na produkt  psują jakość naszego wytworu
" biznesowe
Radzenie sobie z ryzykiem:
1. Identyfikacja ryzyka.
2. Analiza ryzyka.
3. Prawdopodobieństwo jego wystąpienia.
4. Planowanie przeciwdziałania  określenie jak je zminimalizować.
5. Monitorowanie projektu pod kÄ…tem ryzyka.
Identyfikacja ryzyka:
- technologiczne (sprzęt, nieefektywność wykorzystanej technologii informatycznej)
- zwiÄ…zane z zasobami ludzkimi
- zwiÄ…zane z wymaganiami
- czas
- pieniÄ…dze
Zarządzanie ryzykiem  słownie opisane sposoby postępowania w przypadku zdarzenia
zwiększającego ryzyko, np. kim zastąpić osobę, która zachorowała (zwłaszcza, jeśli jest na
kluczowym stanowisku), jak mobilizować w takiej sytuacji ekipę, by nieobecność nie stwarzała
ryzyka dla projektu.
Monitorowanie  należy bacznie przyglądać się wrażliwym elementom systemu, obserwować pracę
nad nim, przysłuchiwać się opiniom twórców, by wyłowić ewentualne problemy z projektem.
Oceny / pomiary
Rodzaje kosztów:
 sprzęt
 koszty kadry: podróże, delegacje
 koszty wysiłku wkładanego we wdrażanie systemu informatycznego: praca inżynierów
 aktywność ludzi w ramach harmonogramu (trudne do oszacowania)
Czynniki wpływające na koszt produktu:
 firma może obniżyć cenę ze względu na swoją sytuację
 może zaniżyć cenę aby wkręcić się na rynek
 jeśli są niepewności w pewnych sferach możemy cenę podnieść (?)
Szacowanie funkcjonalności produktu
1. Rozmiar projektu. Podstawowe metryki:
" ilość linii kodu, ilość dokumentacji na 1 linię kodu,
" ilość kodu/miesiąc
" ilość ceny/jedną stronę dokumentacji.
Wada: niejednoznaczność, ten sam kod w C zajmuje 10 linii, a w asemblerze 1000.
2. Funkcjonalność  ilość błędów na punkt funkcyjny.
3. Punkty obiektowe  interfejsy, itp. (?)
Wycenianie każdego elementu jest niewygodne, dlatego warto:
- dowiedzieć się, jak wyceniane były podobne projekty w przeszłości
- skonsultować się lekarzem lub farmaceutą ;) ekspertem znaczy
- wyznaczyć cenę w zależności od linii kodu (np. 50gr za 1000 linii ;)
COCOMO  metoda niezależna
Dla punktów funkcyjnych:
" obliczamy podstawowe elementy, które ma zawierać system
" dla każdego takiego elementu ustalamy wagę, w zależności od jego skomplikowania
" wpływ czynników globalnych odpowiada na wiele kwestii (?)
" obliczamy sumę elementów dzielonych na przypadającą im wagę i mnożymy przez mnożnik C
Po ukończeniu projektu wiemy dokładnie ile kosztuje. Wiedzę tę warto przechować na przyszłość.
Wadą rozwiązania jest fakt, że punkty funkcyjne mogą być oceniane subiektywnie  wagi każdy
ocenia wg własnego widzimisię.
COCONA 2  jest to metoda algorytmiczna, bardziej sformalizowana, ale wciąż subiektywna (z
powodu dowolności definiowania wag); założenia:
" w ramach punktów obiektowych zakładamy wagi: 1, 2 lub 3 w zależności od złożoności
" ilość raportów do generowania przez system: 2-8
" ustalenie modułów, które należy stworzyć
Na podstawie tych informacji można oszacować koszt systemu.
Przeciętnie: 40-60 LOC/mies., 4-50 punktów obietkowych
LOC  lines of code
Czynniki wpływające na efektywność:
- application domain experience  doświadczenie domenie skraca czas projektu
- process quality  jakość procesu (?)
- rozmiar projektu
- technologia
Metoda szacowania wysiłków i kosztów:
" metoda algorytmiczna (LOC)  uzależniona od długości kodu i dokumentacji
" metody ekspertów  koszt jest obliczany przez porównanie przedsięwzięcia z podobnymi
przedsięwzięciami z tej samej dziedziny, metoda dokładna jeśli mamy dostęp do koniecznych
danych - nie można jej zastosować jeśli nie mamy z czym porównywać naszego
przedsięwzięcia
" przez analogię  szacujemy na bazie historii innych projektów, wówczas trzeba tworzyć
projekt jak najbardziej zbliżony do wzoru
" prawo Parkinsona   Przedsięwzięcie zużyje wszystkie dostępne zasoby ; Zaleta: Nie
przekroczymy budżetu. Wada: Zazwyczaj nie ukończymy systemu
"  cena pod zwycięstwo  projekt kosztuje tyle, ile może za niego zapłacić klient;
kompromis pomiędzy funkcjonalnością, a kosztem (naszymi możliwościami)
Wkład w stworzenie systemu opisany jest wzorem:
B
Eff = A* S * M
, gdzie:
A  czynnik stały; lokalne zwyczaje w firmie, rodzaj tworzonego oprogramowania (?)
S  rozmiar projektu, można liczyć w ramach punktów funkcyjnych
B  liczba od 1 do 1.5
M  współczynnik uzależniony od rodzaju projektu, zespołu, procesów& (?)
COCOMO 81: Typowe wartości szacowania projektu:
Złożoność Formuła Opis
Prosty Zrozumiałe programy użytkowe
PM = 2.4 (KDSI)1.05 × M
tworzone przez małe zespoły.
Średni Bardziej złożone przedsięwzięcia,
PM = 3.0 (KDSI)1.12 × M
w których członkowie zespołu
mogą mieć ograniczone
doświadczenie.
Trudny Skomplikowane przedsięwzięcia,
PM = 3.6 (KDSI)1.20 × M
w których oprogramowanie jest
częścią silnie powiązanego
sprzętu, oprogramowania,
regulacji i procedur działania.
(!) COCOMO 2 - uwzględnia 3 poziomy oszacowania
" Poziom wczesnego prototypowania
" Gotowe do użycia w fazie prototypowania z dużym wykorzystaniem wielokrotnego
użycia
" Oparte na szacowaniu produktywności programisty w punktach obiektowych na
miesiÄ…c
" Bierze pod uwagę użycie narzędzi CASE
" Formuła wygląda następująco:
PM = ( NOP * (1 - %reuse/100 ) ) / PROD
PM to praca w osobomiesiÄ…cach,
NOP to liczba punktów obiektowych
PROD to produktywność
" Poziom wczesnego projektowania
" Oszacowania można dokonać po uzgodnieniu wymagań
" Oparte jest na standardowej formule
PM = A * Wielkość^B * M + PMm gdzie
M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED
PMm = (ASLOC * (AT/100)) / ATPROD
A = 2.5 jest poczÄ…tkowym oszacowaniem, rozmiar jest liczony w tysiÄ…cach linii kodu,
B waha się od 1.1 do 1.24 w zależności od nowatorstwa przedsięwzięcia,
elastyczności, zarządzania ryzykiem i dojrzałości procesu oraz zespołu
" Poziom post-architektoniczny
" Używa tych samych formuł co poprzedni
" Dokładniejsze szacowanie rozmiaru kodu
" Płynność wymagań. Potrzeba więcej pracy
" Rozszerzenie możliwego użycia wielokrotnego. Trzeba zwiększyć ilość linii kodu, które
w rzeczywistości powstaną
ESLOC = ASLOC * (AA + SU +0.4DM + 0.3CM +0.3IM)/100
ESLOC równoważna liczba wierszy nowego kodu. ASLOC to liczba linii kodu
koniecznych do zmodyfikowania, DM to procent modyfikowanego projektu, CM
to procent modyfikowanego kodu, IM to odsetek pierwotnej pracy
integracyjnej.
SU to czynnik oparty na koszcie zrozumienia kodu, AA to czynnik
odzwierciedlający koszt ustalenia czy oprogramowanie może być użyte
wielokrotnie
Atrybuty produktu
RELY Niezawodność systemu DATA Rozmiar bazy danych
CPLX Złożoność modułów RUSE Wymagany odsetek komponentów
systemowych użycia wielokrotnego
DOCU Zakres wymaganej
dokumentacji
Atrybuty komputera
TIME Ograniczenia na czas STOR Ograniczenia pamięciowe
działania
PVOL Płynność platformy tworzenia
Atrybuty personelu
ACAP Możliwości analityków PCAP Możliwości programistów
PCON Ciągłość zatrudnienia AEXP Doświadczenie analityków w
dziedzinie przedsięwzięcia
PEXP Doświadczenie programistów LTEX Doświadczenie w stosowaniu
w dziedzinie przedsięwzięcia języków i narzędzi
Atrybuty przedsięwzięcia
TOOL Użycie narzędzi SITE Stopień rozproszenia pracy i jakość
programowych komunikacji
SCED Kompresja harmonogramu
tworzenia