Dobór metodyki pozyskiwania wymagań i analizy uwarunkowań
procesu specyfikacji
Burza mózgów: Technika polegająca na wspólnym tworzeniu i silver i golden release. Jednym z produktów mogą być w tym przypadku scenariusze i przypadki testowe oraz raporty z realizacji iteracji testów.
analizowaniu pomysłów podczas grupowego spotkania.
Uczestnicy dostarczają pomysłów na rozwiązanie danego problemu,
pomysły te spisuje się, analizuje, po czym wybiera
rozwiązanie akceptowane przez ogół.
Burza mózgów znajduje zastosowanie zwłaszcza
wtedy, kiedy pojawia się problem związany z wymaganiami
– wymagania dostarczone przez różnych przedstawicieli
biznesu wzajemnie się wykluczają lub wymagają uszczegółowienia,
doprecyzowania, przeanalizowania względem
możliwości implementacji, etc.
Analiza dokumentacji: Polega na przeglądaniu istniejącej w organizacji
dokumentacji w celu identyfikacji wymagań obecnych i potencjalnych.
Technika stosowana zwłaszcza wtedy, kiedy pojawia się potrzeba określenia
istniejących zasad biznesowych, elementów i atrybutów, które należy
uwzględnić w nowym systemie lub które będą musiały być zmodyfikowane
na skutek wdrażania nowego systemu. Metoda może być również wykorzystywana
w przypadku, gdy eksperci danej dziedziny biznesowej nie są
dostępni dla konsultacji analitycznych i analityk musi samodzielnie
poznawać określone zagadnienie.
Analiza interfejsów: Analiza zewnętrznych interfejsów polega na identyfikacji
i badaniu zarówno interfejsu użytkownika, jak i interfejsów do/z zewnętrznych
systemów lub urządzeń. Analiza taka pomaga określić granice systemu oraz
stwierdzić, jakie dane i jakie funkcje przepływają pomiędzy systemami.
Analiza interfejsów powinna dać w wyniku dokument słownika danych,
który gromadzi wszystkie dane wymieniane pomiędzy systemami w sposób
spójny i umożliwiający ich kontrolowanie oraz utrzymywanie w aktualnym stanie.
Analiza interfejsów powinna być wykonywana jako uzupełnienie pozyskiwania
wymagań funkcjonalnych oraz niefunkcjonalnych.
Wywiad: Technika polegająca na zadawaniu pytań dotyczących określonego
obszaru działania danej osoby, procesu czy problemu. Wywiad przeprowadzany
jest przez analityka, zaś osobą pytaną jest ekspert dziedzinowy, przedstawiciel
biznesu czy wręcz użytkownik końcowy projektowanego rozwiązania. Wywiad
może być zarówno ustrukturyzowany – kiedy analityk posiada przygotowany
wcześniej zestaw pytań; lub nie ustrukturyzowany – polegający na dyskusji
dotyczącej oczekiwań wobec projektowanego rozwiązania. Ustalenia i
wnioski z wywiadu powinny być udokumentowane oraz przekazane
pytanemu do wglądu i ewentualnej korekty/sprostowania.
Obserwacja: Technika ta polega na wyciąganiu wniosków na podstawie
obserwacji pracy ludzi wykonujących swoje zadania. Umożliwia dokładne
poznanie przebiegu określonego procesu, procedur, czynności,
produktów oraz nieformalnych zwyczajów, zwykle nie umieszczanych w
dokumentacji przedsiębiorstwa a wpływających na przebieg pracy.
Obserwacja może być pasywna - kiedy analityk jedynie obserwuje osobę
wykonującą swoja pracę, bez zadawania dodatkowych pytań; lub aktywna – polegająca
na obserwacji połączonej z dyskusją z pracownikiem i omawianiem bieżących czynności.
Wnioski i obserwacje poczynione w trakcie realizowania tej techniki należy
na bieżąco notować (niektórzy analitycy posuwają się o krok dalej i nawet na
bieżąco modelują i dokumentują procesy biznesowe, które obserwują).
Prototypowanie: Prototypowanie – zastosowane jako technika pozyskiwania wymagań
– umożliwia dokładną identyfikację wymagań dotyczących UI systemu oraz pożądanego
przebiegu (nawigacji) funkcji jeszcze przed oficjalnym rozpoczęciem prac implementacyjnych.
Prototypy aplikacji (tworzone np. jako statyczne lub dynamiczne strony HTML) pozwalają
na wizualizację wstępnego projektu analityka i weryfikację rozwiązania przez przedstawicieli klienta
. Klient może sprawdzić, czy bieżący projekt spełnia jego oczekiwania, dodać nowe pomysły
i rozwiązania, itp. Zwykle w trakcie pracy z prototypem zostają odkryte nowe
wymagania (np. dotyczące użyteczności, ergonomii), które zostają uszczegółowione bądź
w kolejnej wersji prototypu (prototypowanie ewolucyjne), bądź włączone bezpośrednio
do specyfikacji analitycznej.Prototypy aplikacji mogą być statyczne – czyli pojedyncze ekrany
bez nawigacji pomiędzy poszczególnymi ekranami, bez żadnych dodatkowych akcji; lub dynamiczne
– umożliwiające zaprezentowanie nawigacji pomiędzy ekranami czy formatami,
zachowanie aplikacji po wywołaniu wybranych akcji, etc.
Warsztaty: Warsztaty wymagań stanowią ustrukturyzowaną metodę pozyskiwania wymagań.
Warsztaty służą do określania zakresu, identyfikacji, szczegółowego definiowania i ustalania
priorytetów wymagań projektowanego systemu. Dobrze zorganizowany warsztat to jedna z
najlepszych technik określania wymagań – ponieważ oznacza dobrą komunikację i
porozumienie pomiędzy udziałowcami projektu (decyzje podjęte
podczas warsztatów są dyskutowane i akceptowane przez wszystkich członków).
Kontrola jakości, testy oprogramowania i ich rodzaje.
Poziomy testów:
1. Testy modułowe (unit/component testing)
2. Testy integracyjne (integration testing)
3. Testy systemowe (system testing)
4. Testy akceptacyjne (acceptance testing)
Na każdym z poziomów stosowane są różne typy testów:
1. Testy modułowe
– analiza ścieżek (path analysis)
– użycie klas równoważności (equivalence partition)
– testowanie wartości brzegowych
– testowanie składniowe
2a. Testy integracyjne pomiędzy modułami
– funkcjonalne
– wydajnościowe
2b. Testy integracyjne pomiędzy systemami
– funkcjonalne
– wydajnościowe
– regresywne
3. Testy systemowe
– instalacyjne
– funkcjonalne
– interfejsu (użyteczności)
– wydajnościowe
– regresywne
– bezpieczeństwa
4. Testy akceptacyjne
– funkcjonalne
– wydajnościowe
– bezpieczeństwa
Uwarunkowania i sposoby zapewnienia jakości oprogramowania.
Zarządzanie jakością oprogramowania może być realizowane w różny
sposób w zależności od organizacji i rodzaju realizowanego projektu,
ale powinno wspierać cały proces rozwoju oprogramowania,
tj.:Projektowanie rozwiązania – głównie pod kątem zaplanowania procesu testowego,
tj. rodzaju planowanych testów, sposobu realizacji tych testów np. poprzez zdefiniowanie środowisk
testowych oraz sposobu pozyskania danych testowych. Jednym z produktów
może być w tym przypadku plan testów zawierający harmonogram testów.
Kodowanie rozwiązania – poprzez bieżące tworzenie i realizacje scenariuszy i przypadków
testowych oraz rejestrację defektów i ich sukcesywne rozwiązywanie. Oprogramowanie
w trakcie poszczególnych iteracji może np. otrzymywać status alfa, beta, release candidate,
Zarządzanie zmianami – poprzez weryfikację w jaki sposób planowane zmiany mogą wpłynąć na jakość tworzonego rozwiązania i zaplanowanie środków i sposobu zapewnienia jakości po realizacji zmiany. Jednym z produktów mogą być w tym przypadku zmiany planu testów oraz zmiany scenariuszy i przypadków testowych.
Zamknięcie projektu – poprzez realizację szeregu dedykowanych rodzajów testów mających na celu kompleksową weryfikację jakości tworzonego rozwiązania. Mogą to być przykładowo testy integracyjne (ang. System Integration Tests), testy akceptacyjne (ang. User Acceptance Tests) oraz testy operacyjne (ang. Operational Acceptance Tests). Jednym z produktów może być w tym przypadku rekomendacja dotycząca produkcyjnego uruchomienia systemu.
Wpływ różnych modeli cyklu życia oprogramowania na jego proces walidacji i weryfikacji.
Cykl życia programu – seria kolejnych zmian programu, w trakcie których sukcesywnie odbywa się dodawanie nowych funkcji oraz usuwanie powstających w trakcie rozwoju błędów (tzw. bugów).
Zasadniczo cykl życia kolejnych wersji programu można podzielić na następujące etapy:
wersja niestabilna (testowa) – seria wydań, podczas której dodawane są przede wszystkim nowe możliwości:
wersja robocza (pre-alpha) – dostępna zazwyczaj tylko dla twórców programu w postaci repozytorium kodu źródłowego (np. CVS, SVN, GIT), kiedy implementowany jest algorytm programu, tworzony jest interfejs i dodawane są nowe funkcje;
wersja alfa (pre-beta) – autorzy doprowadzają do rzeczywistego działania programu, nawet w ograniczonym zakresie;
wersja beta – kiedy program ma już pierwszych użytkowników, zwanych często beta testerami, wyłapywane są błędy związane z różnymi środowiskami i warunkami pracy programu
RC (ang. Release Candidate, czyli kandydat do wydania) – wydanie kandydujące, których może być nawet kilka, ale jeżeli nie zostanie w nim znalezione żadne istotne odstępstwo od planu wersji, zmienia się jedynie numer wersji na wyższy i uznaje wersję za stabilną.wersja stabilna (wersja produkcyjna) – wersja nadająca się do użytkowania zgodnie z założeniami autorów
RTM (ang. Release To Manufacture, Ready To Manufacture lub Ready To Market czyli gotowy do wydania) – produkt uznany za stabilny i gotowy do wypuszczenia na rynek; nie jest dostępny publicznie do czasu premiery;wersje stabilne z poprawkami bezpieczeństwa lub innych błędów.starzenie moralne programu – zwykle ostatni etap polegający na porzuceniu programu przez autorów, co zwykle kończy jego życie; w przypadku kodu na licencjach FLOSS ten stan może w dowolnym momencie ponownie przejść do fazy aktywnego rozwoju, jeśli tylko znajdą się chętni do przejęcia opieki nad nim lub wykorzystają fragmenty kodu w innej aplikacji.

Budżet, ryzyko i koszty związane ze zmianami w trakcie realizacji projektu programistycznego
Zarządzanie ryzykiem w projekcie kosztuje, mozemy mowic o nast. rodzajach kosztow zwiazanych z ryzykiem
-koszty zarzadzania ryzykiem a wiec identyfikowanie, analizowanie, monitorowanie i planowanie reakcji na ryzyko,
-koszty wykonywania akcji zwiazanych z ryzykiem,
-koszty obslugi ryzyka operacyjnego wynikajacego z bledow szacowania na etapie planowania.
Wszystkie powyższe rodzaje kosztów związane z niepewnością można obsługiwać w projekcie. Poniżej
przedstawiony zostanie jeden ze sposób odpowiedniego przydzielenia pieniędzy na obsługę ryzyka
w projekcie.
Kazdy 1$ wydany w fazie definicji wymagan to 5$ zaoszczedzonych w fazie implementacji, oznacza to, że należy jak najwcześniej analizować problematykę i likwidować najwięcej zagrożen jak najwcześniej, badz sie na nie przygotowac.
Koszty zmian w trakcie realizacji sa duzo wieksze niz zmiany przed nia.

Zasady skutecznego zarządzania zespołem programistycznym.

Bądź proaktywny - Proaktywność to ODPOWIEDZIALNOŚĆ, za podejmowanie działania.

-Proaktywność wymaga zrozumienia, że w ogólności mamy do

czynienia z 3 rodzajami problemów. Są problemy, na które mamy bezpośredni wpływ i ich rozwiązanie oznacza nasze osobiste zwycięstwo. Przykładem może być rzucenie palenia albo dążenie do własnej punktualności. Są też problemy, na które mamy wpływ, ale tylko pośredni.

No i oczywiście są takie problemy, na które nie mamy wpływu – i to też

trzeba umieć zaakceptować. Cała sztuka polega na umiejętności

rozróżnienia problemów, na które ma się wpływ od tych, na które wpływu się nie ma.

-Zaczynaj mając koniec na względzie

Przywództwo polega na określaniu celów i stawianiu zadań. Tylko myśląc o końcu przedsięwzięcia i jego konsekwencjach (zarówno pozytywnych, jak i negatywnych) jesteśmy w stanie podjąć racjonalną decyzję.

-Aby rzeczy pierwsze były pierwsze

Jesteśmy zalewani informacją. Różną informacją. Trzeba czytać książki i

obserwować strony www, bo informatyka zmienia się bardzo szybko i

technologie sprzed pięciu lat mają już znacznie efektywniejszych

konkurentów. W tym względzie dobrą praktyką zarządzania czasem jest wybiórcze czytanie. Musimy przed przystąpieniem do czytania zdać sobie sprawę, jakiej informacji potrzebujemy i potem tej informacji w książce lub na stronie www poszukiwać. Inaczej mówiąc, rzeczy pierwsze względem ważności powinno się robić najpierw – rzeczy mniej ważne mogą poczekać. Wydaje się to proste. Ale sprawę komplikuje fakt, że oprócz ważności jest jeszcze pilność spraw.

-Myśl o obopólnej korzyści

w życiu najbardziej popłaca mentalność Win/Win: jest to dążenie do wzajemnej korzyści. Mój sukces nie wyklucza Twojego. Jest to

nastawienie na poszukiwanie rozwiązania, które będzie pożyteczne dla obu stron. Oczywiście, nie zawsze jest to możliwe. Gdy natrafimy na kogoś z osobowością Win/Lose strategia Win/Win będzie najprawdopodobniej nie do zrealizowania. Jeśli widzimy, że ułożenie relacji z drugą stroną na zasadzie Win/Win nie jest możliwe, to powinniśmy odstąpić od wspólnego przedsięwzięcia – po angielsku nazywa się to „No deal” (żadnej transakcji, żadnego interesu). Zatem pełne brzmienie zasady, której powinniśmy się trzymać w kontaktach z innymi osobami brzmi: Win/Win or no deal, czyli albo obopólna korzyść albo rezygnujemy ze wspólnego interesu.

-Najpierw staraj się zrozumieć

Najpierw staraj się zrozumieć, a dopiero potem oczekuj, że będziesz zrozumiany

-Dbaj o synergię

Synergia jest to budowanie na silnych cechach członków zespołu i kompensowanie słabości członków zespołu

-Ostrz piłę

Ostatnia, siódma, zasada dotyczy ciągłego doskonalenia.

Potrzebna jest równowaga między dbaniem o produkcję a dbaniem o

zdolności produkcyjne. Musi być czas zarówno na pracę zawodową, jak i na dbanie o zdrowie i zapoznawanie się z nowymi technologiami.