Fedorov po polsku

Przyczyny opóź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óź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 ludź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:

M

S

A

Eff

B

*

*

=

, 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

PM = 2.4 (KDSI)

1.05

×

M

Zrozumiałe programy użytkowe
tworzone przez małe zespoły.

Ś

redni

PM = 3.0 (KDSI)

1.12

×

M

Bardziej złożone przedsięwzięcia,
w których członkowie zespołu
mogą

mieć

ograniczone

doświadczenie.

Trudny

PM = 3.6 (KDSI)

1.20

×

M

Skomplikowane przedsięwzięcia,
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

systemowych

RUSE

Wymagany odsetek komponentów
użycia wielokrotnego

DOCU

Zakres

wymaganej

dokumentacji

Atrybuty komputera

TIME

Ograniczenia

na

czas

działania

STOR

Ograniczenia pamięciowe

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
w dziedzinie przedsięwzięcia

LTEX

Doświadczenie

w

stosowaniu

języków i narzędzi

Atrybuty przedsięwzięcia

TOOL

Użycie

narzędzi

programowych

SITE

Stopień rozproszenia pracy i jakość
komunikacji

SCED

Kompresja harmonogramu
tworzenia