Rapid Development

Szybkie tworzenie oprogramowania
(Rapid Development)

Kamil Jaśkiewicz

Politechnika Wrocławska
Wydział Elektroniki
Inżynieria Systemów Informatycznych

9 czerwca 2010

Wstęp
Klasyczne błędy
Najlepsze praktyki
Podsumowanie i literatura

Agenda

Agenda:
Wstęp
Charakterystyka klasycznych błędów
Wybór najlepszych praktyk

Kamil Jaśkiewicz Szybkie tworzenie oprogramowania

Wstęp
Klasyczne błędy
Najlepsze praktyki

Wstęp

Deﬁnicja:
Szybkie tworzenie oprogramowania (Rapid
development) to przede wszystkim krótsze
od nominalnych harmonogramy oraz
tworzenie oprogramowania szybciej niż
robimy to teraz.


Wstęp
Klasyczne błędy
Najlepsze praktyki

Wstęp

Ogólna strategia szybkiego tworzenia oprogramowania:
Unikanie klasycznych błędów
Stosowanie podstaw inżynierii oprogramowania
Zarządzanie ryzykiem
Praktyki zorientowane na harmonogram


Wstęp
Klasyczne błędy
Najlepsze praktyki

Cztery ﬁlary szybkiego tworzenia oprogramowania


Wstęp
Klasyczne błędy
Najlepsze praktyki

Techniki zorientowane na harmonogram nie wystarczą


Wstęp
Klasyczne błędy
Najlepsze praktyki

Najczęściej popełniane błędy


Wstęp
Klasyczne błędy
Najlepsze praktyki

Błędy związane z ludźmi

Źle dobrany zespół:
zatrudnianie osób, które mogąc zacząć “od zaraz”
brak weryﬁkacji umiejętności

“Problematyczni”pracownicy:
stwarzanie konﬂiktów w zespole
spadek motywacji pozostałych członków zespołu
ponowne wykonywanie pracy wykonanej przez takiego
pracownika


Wstęp
Klasyczne błędy
Najlepsze praktyki


Dodawanie nowych osób do opóźnionego projektu:
dolewanie benzyny do ognia
zmniejszanie produktywności członków zespołu
potencjalne konﬂikty

Nierealne oczekiwania:
zbyt optymistyczne estymacje
sprawianie wrażenia zbyt długo trwających projektów


Wstęp
Klasyczne błędy
Najlepsze praktyki



Wstęp
Klasyczne błędy
Najlepsze praktyki

Błędy związane z procesem

Porzucenie planu:
dotyczy projektów realizowanych pod presją
nieskoordynowana praca

Pomijanie zadań w estymacjach:
umykanie uwadze mało widocznych zadań
brak śledzenia poprzednich projektów i wykonywanych
tam zadań
pominięte zadania dodają średnio 20-30% czasu do
harmonogramu (Michiel van Genuchten)


Wstęp
Klasyczne błędy
Najlepsze praktyki


Skrócenie analizy oraz planowania:
“nie marnujmy czasu, zacznijmy od razu programować”
- jumping into coding
tworzenie “haków”i konieczność ich późniejszego
poprawiania


Wstęp
Klasyczne błędy
Najlepsze praktyki



Wstęp
Klasyczne błędy
Najlepsze praktyki

Błędy związane z produktem

Zmiana zakresu funkcjonalności:
przeciętny projekt doświadcza zmiany 25% wymagań w
czasie jego trwania
konsekwencja: wydłużenie harmonogramu

Negocjacje typu “push-me, pull-me”:
zaakceptowanie przez managera opóźnienia w
harmonogramie
dodanie dodatkowych zadań/wymagań


Wstęp
Klasyczne błędy
Najlepsze praktyki

Błędy związane z technologią

Syndrom “srebnego pocisku”:
zakładanie lepszej od rzeczywistości produktywności po
zastosowaniu nowych narzędzi
niska produktywność w początkowych fazach używania
nowej techonologii
niewielkie skrócenie czasu harmonogramu

Niestosowanie systemów kontroli wersji:
nadpisywanie wyników pracy innych osób
przesyłanie plików poprzez pocztę e-mail lub w inny
sposób


Wstęp
Klasyczne błędy
Najlepsze praktyki

Codzienna kompilacja oraz testy
Daily Build and Smoke Test

Skuteczność:
Potencjalne skrócenie nominalnego planu: Dobre
Poprawienie widoczności postępu projektu: Dobre
Szansa sukcesu w założonym terminie: Bardzo dobra

Ryzyko:
presja na zbyt częste dostarczanie wersji pośrednich.


Wstęp
Klasyczne błędy
Najlepsze praktyki

Miniaturyzacja kamieni milowych
Miniature Milestones

Skuteczność:
Potencjalne skrócenie nominalnego planu: Zadawalające
Poprawienie widoczności postępu projektu: Bardzo dobre
Szansa sukcesu w założonym terminie: Dobra

Ryzyko:
brak


Wstęp
Klasyczne błędy
Najlepsze praktyki

Wykorzystywanie języków wysokiego poziomu
Rapid-Development Languages (RDLs)

Skuteczność:
Poprawienie widoczności postępu projektu: Dobre

Ryzyko:
syndrom “srebrnego pocisku” oraz przeszacowanych
oszczędności.


Wstęp
Klasyczne błędy
Najlepsze praktyki

Wykorzystywanie języków wysokiego poziomu
Rapid-Development Languages (RDLs)

Liczba linii kodu
Liczba
punktów
funkcyjnych Assembler C C++ C# Oracle
1 203 107 53 59 11
100 20,300 10,700 5,300 5,900 1,100
500 101,500 53,500 26,500 29,500 5,500
1,000 203,000 100,7000 53,000 59,000 11,000
5,000 1,015,000 535,000 265,000 295,000 55,000


Wstęp
Klasyczne błędy
Najlepsze praktyki

Realizacja przyrostowa
Evolutionary Delivery

Skuteczność:
Poprawienie widoczności postępu projektu: Bardzo dobre

Ryzyko:
częsta zmiana wymagań
nierealistyczny harmonogram i oczekiwania budżetowe
nieefektywne wykorzystanie czasu pracy programistów


Wstęp
Klasyczne błędy
Najlepsze praktyki

Outsourcing

Skuteczność:
Potencjalne skrócenie nominalnego planu: Bardzo Dobre
Poprawienie widoczności postępu projektu: Brak

Ryzyko:
utrata widoczności postępu i kontroli
wypływ doświadczenia poza ﬁrmę


Wstęp
Klasyczne błędy
Najlepsze praktyki

Podsumowanie

Unikajmy klasycznych błędów (stwórzmy ich własną listę)
Stosujmy dobre praktyki:
zmiejszenie ryzyka
zwiększenie prawdopodobieństwa sukcesu (projekt wykonany w
założonym czasie i kosztach)


Wstęp
Klasyczne błędy
Najlepsze praktyki

Literatura

Steve McConnell Rapid Development. Microsoft Press, 1996
Function Point Languages Table,
http://www.qsm.com/?q=resources/function-point-languages-
table/index.html
Michiel van Genuchten Why is Software Late? An Empirical
Study of Reasons for Delay in Software Development. IEEE
Transactions on Software Engineering, 1991


Wstęp
Klasyczne błędy
Najlepsze praktyki

Pytania

Pytania


Rapid Development

Recommended

Recommended

More Related Content

Featured

Featured (20)

Rapid Development