Wywiad na temat oczekiwań zleceniodawcy

Wyobraźmy sobie, że pracujemy w zespole, którego zadaniem jest przygotowanie pewnego programu. Niestety zadanie sformułowane jest bardzo ogólnie, a zależy nam na jak najlepszym spełnieniu oczekiwań klienta, dlatego też przeprowadzamy z nim wywiad. Przedstawiona w tym e‑materiale przykładowa rozmowa została ułożona w taki sposób, aby uzyskać jak najwięcej informacji od zleceniodawcy. Istnieje spore prawdopodobieństwo, że w przyszłości osoba zlecająca ci projekt nie będzie aż tak zainteresowana szczegółami technicznymi. Klienta interesuje zazwyczaj głównie to, by oprogramowanie po prostu działało, natomiast przeważnie sam do końca nie wie, czego oczekuje od programisty. Właśnie dlatego prowadzi się takie rozmowy ze zleceniodawcą.

Przejdźmy więc do samego wywiadu.

To jest już jakaś informacja, choć niezbyt wyczerpująca. Wiemy, że program ma być zbliżony do już istniejącego. Nie wiemy jednak, jaka jest platforma docelowa (telefon, komputer, tablet, smartTV czy komputer pokładowy Tesli). Załóżmy również, że nigdy nie widzieliśmy tego modelu telefonu, do którego odwołał się klient, i nie wiemy, na czym polega ta gra. Musimy zatem o to dopytać.

Znamy już zatem dokładny opis gry. Wiemy dzięki niemu:

• jak ma przebiegać rozrywka,

• co i pod jakimi warunkami ma się w grze wydarzać,

• na jakim systemie i sprzęcie ma działać gra.

Spróbujmy napisać zasady gry w formie pseudokodu:

jeżeli wąż dotyka owoc wykonaj:
	przedłuż(wąż.ogon)
jeżeli wąż dotyka wąż.ogon wykonaj:
	zakończ grę i wyświetl wynik równy...

Pojawia się pytanie: czemu ma być równy wynik? Klient zażyczył sobie, aby wynik był zależny od długości ogona, ale nie sprecyzował żadnego wzoru. Trzeba o to dopytać.

Możemy więc teraz dopisać do naszego pseudokodu wynik punktowy:

jeżeli wąż dotyka owoc wykonaj:
	przedłuż(wąż.ogon)
jeżeli wąż dotyka wąż.ogon wykonaj:
	zakończ grę i wyświetl wynik równy 10 * wąż.ogon

Nie znamy jednak jeszcze zasad sterowania – skoro poruszamy się na komputerze, to korzystamy zapewne z myszy lub klawiatury. A może mamy przyjąć jakiś inny sposób komunikacji z komputerem?

W tym momencie klient dodał nam kolejną informację. Mimo że wcześniej opisał grę bardzo dokładnie, to w trakcie wywiadu pomyślał o pewnej dodatkowej funkcji. Teraz powinniśmy się dowiedzieć, czego dokładnie od nas oczekuje. W zależności od formy spisanej umowy zleceniodawca może mieć prawo dodawać na bieżąco kolejne zmiany do implementacji lub być pozbawiony takiej możliwości (co jednak może być źródłem napięć na linii klient – programista).

W pseudokodzie sterowanie wężem wygląda następująco:

dopóki gra == trwa wykonuj:
	jeżeli wąż dotyka owoc wykonaj:
		przedłuż(wąż.ogon)
	jeżeli wąż dotyka wąż.ogon wykonaj:
		gra = skończ
        wyświetl wynik = 10 * wąż.ogon
    jeżeli wcisnietyPrzycisk == 'D' wykonaj:
    	obrót o 90 stopni w prawo
    w przeciwnym razie jeżeli wcisnietyPrzycisk == 'A' wykonaj:
     	obrót o 90 stopni w lewo
    dopóki wcisnietyPrzycisk == spacja wykonuj:
     	pauza

Dla programisty pseudokod jest zrozumiały. Gdy jednak pokażemy go klientowi, bardzo możliwe, że nie zrozumie on takiego zapisu.

Warto dodać, że dotychczas zleceniodawca przedstawiał głównie wymagania funkcjonalne gry. Nie mówił o oczekiwaniach względem wyglądu interfejsu ani co do formy samego węża i owocu. Nie wiemy także, w jaki sposób ma być wyświetlany wynik punktowy.

Zatem wymagania funkcjonalne opisują, w jaki sposób program ma reagować na dane wejściowe, a więc na naciskanie klawiszy kierunkowych. Natomiast to, jakie konkretne klawisze mają służyć do sterowania programem, możemy już zaliczyć do wymagań niefunkcjonalnych, ponieważ zmiana przycisku na klawiaturze nie wpłynie na sposób działania programu.

Opis słowny wymagań funkcjonalnych nie będzie dokładniejszy, niż to, czego już się dowiedzieliśmy. Zapewne można te wymagania ująć w jakiś bardziej skondensowany sposób, ale nie usprawni nam to pracy. Trzeba natomiast sporządzić formalny opis dokumentacji wymagań.

Dla osób nietechnicznych bardziej przyjazne od pseudokodów są diagramy – w tym przypadku skorzystamy z diagramu przypadków użycia. W takim diagramie zawarta jest jednak tylko informacja o czynnościach, jakie może podjąć dowolny użytkownik, zwany dalej aktorem. Nie ma tu natomiast miejsca na żadne pętle warunkowe czy bardziej złożony opis samej mechaniki rozgrywki, gdyż ta zostanie opisana w kolejnych diagramach.

Diagram przypadków użycia

Diagram przypadków użycia (ang. use case) to graficzny sposób na przedstawienie interakcji między użytkownikiem systemu a samym systemem.

Omawiany tu diagram będzie użyty zgodnie z językiem UMLjęzyk UMLjęzykiem UML.

Elementy używane w tym diagramie to:

• aktor,

• przypadek użycia,

• asocjacja,

• zawieranie i rozszerzanie.

Aktor to ktoś spoza systemu – najczęściej jest to jakiś użytkownik. Przykładowo: w szkołach powszechnie wykorzystywane są programy lub serwisy internetowe, w których zdefiniowanych jest kilka rodzajów użytkowników. Każdy z nich byłby innym aktorem. Podział aktorów w dzienniku elektronicznym mógłby wyglądać następująco:

• uczeń przeglądający swoje oceny z przedmiotów, na które uczęszcza;

• nauczyciel posiadający uprawnienia do przeglądania i aktualizowania ocen każdego ucznia w ramach nauczanego przez siebie przedmiotu, a także odnotowywania obecności uczniów na lekcji;

• rodzic, który ma uprawnienia analogiczne do ucznia;

• wychowawca, który może zamieszczać ogłoszenia dla swojej klasy czy usprawiedliwiać nieobecności uczniów.

Przedstawiony wyżej podział to jedynie przykład, który pomoże nam lepiej zobrazować to zagadnienie.

Kolejnym elementem diagramu jest przypadek użycia, który zapisujemy w elipsie jako daną czynność. Powinna być ona ogólna, bez wdawania się w szczegóły w samym diagramie. W e‑dzienniku przykładową czynnością mogłoby być „wyświetl ocenę” czy „wprowadź ocenę”. Połączenie aktora z przypadkiem użycia nazywa się asocjacją. Na schemacie oznacza się ją za pomocą odcinka łączącego symbol aktora z elipsą przypadku użycia. Istnieje również asocjacja skierowana, pokazująca, w jakim kierunku inicjowane jest działanie. Taką asocjację oznacza się za pomocą strzałki wskazującej ten kierunek.

Zatem tak przedstawiona będzie asocjacja:

RHiVSgVydnk7r

Ilustracja przedstawia ikonę ucznia połączoną z zieloną okręgiem z wpisem: wyświetl ocenę.

a tak asocjacja skierowana:

RYFuC0ybsx8T3

Ilustracja przedstawia ikonę ucznia od którego wychodzi strzałka wskazująca na zielony okrąg z wpisem: wyświetl ocenę.

Uczeń może wyświetlić ocenę – nie mamy tu żadnych wątpliwości. Jednak przedstawiając diagram klientowi, musimy przekazać mu również dokładniejszy opis tej czynności. Chodzi o sprecyzowanie, co w tym kontekście oznacza „wyświetlenie oceny”.

Należy tworzyć diagramy możliwie najprostsze i najogólniejsze. Nie ma potrzeby rozdrabniać ich na najmniejsze, bardziej precyzyjne elementy. Gdy chcemy zadać pytanie, czy nauczyciel, wychowawca, rodzic i uczeń mogą wyświetlać oceny, wystarczy narysować ten diagram w taki sposób:

R1bvP3DtMzTPw

Ilustracja przedstawia diagram.
Od okręgu z wpisem: wyświetl ocenę wychodzą proste do ikon ludzi z podpisami: Wychowawca, nauczyciel, rodzic, uczeń.

Teraz należy zwrócić uwagę na wychowawcę. Jest on pewnym rodzajem nauczyciela, który zarządza sprawami klasowymi, w tym usprawiedliwianiem nieobecności. Dla uproszczenia można narysować schemat UML, uwzględniając, że wychowawca dziedziczy wszystkie funkcjonalności po nauczycielu. W takich sytuacjach stosowane jest dziedziczenie, które działa analogicznie, jak w programowaniu obiektowym. W omawianym przypadku aktor wychowawca dziedziczy po aktorze nauczycielu wszystkie jego cechy, a następnie dodaje własne. Natomiast czynność „usprawiedliw nieobecność” łączymy linią z wychowawcą, bo tylko on (a nie każdy nauczyciel) może uwzględniać usprawiedliwienia.

Rhqi1Tkvj2Mdt

Ilustracja przedstawia diagram.
Od okręgu z wpisem: wyświetl ocenę wychodzą proste do ikon ludzi z podpisami: nauczyciel, rodzic, uczeń.
Z okręgu z wpisem: usprawiedliw nieobecność wychodzi prosta do ikony Wychowawca a następnie do: Nauczyciel.

Załóżmy teraz, że nauczyciel może również w tym systemie dodawać i usuwać oceny. W takiej sytuacji wystarczy stworzyć połączenie pomiędzy nauczycielem a funkcjonalnościami „Usuń Ocenę” oraz „Dodaj Ocenę”.

R182XaCqyMamT

Ilustracja przedstawia diagram.
Od okręgu z wpisem: wyświetl ocenę wychodzą proste do ikon ludzi z podpisami: nauczyciel, rodzic, uczeń.
Z okręgu z wpisem: usprawiedliw nieobecność wychodzi prosta do ikony Wychowawca a następnie do: Nauczyciel.
Od ikony Nauczyciel wychodzą proste do okręgu z wpisem: dodaj ocenę oraz do: usuń ocenę.

W ten sposób dodaliśmy nowe funkcje. Zastanówmy się jednak, czy czynność usuwania oceny nie implikuje najpierw jej wyświetlenia? W takich sytuacjach korzystamy z zawierania oznaczanego zapisem <<include>> na strzałce łączącej elementy. Strzałka skierowana jest od przypadku bazowego, który rozpatrujemy, do przypadku zawieranego, czyli tego, który staje się częścią przypadku bazowego. Schemat wygląda tak:

R1dONEx240hL8

Ilustracja przedstawia dwa zielone okręgi z wpisami: bazowy przypadek oraz: zawierany przypadek.
Okręgi połączone są przerywaną strzałką z podpisem mniejsze mniejsze include większe większe.

W e‑dzienniku mamy sytuację, gdzie „usuń ocenę” jest przypadkiem bazowym, natomiast w czynności tej zawiera się czynność „wyświetl ocenę” (bo przed usunięciem oceny trzeba ją wyświetlić), która jest przypadkiem zawieranym. Schemat wygląda zatem tak:

R1NrWGDCOzt1e

Ilustracja przedstawia diagram.
Od okręgu z wpisem: wyświetl ocenę wychodzą proste do ikon ludzi z podpisami: nauczyciel, rodzic, uczeń.
Z okręgu z wpisem: usprawiedliw nieobecność wychodzi prosta do ikony Wychowawca a następnie do: Nauczyciel.
Od ikony nauczyciel wychodzą proste do okręgu z wpisem: dodaj ocenę oraz do: usuń ocenę.
Od okręgu z wpisem: usuń ocenę wychodzi przerywana strzałka include prowadząca do okręgu z wpisem: wyświetl ocenę.

Diagram przestaje być czytelny, mimo że jest wciąż bardzo prosty i zawiera niewiele treści. Jest to spowodowane tym, że miejsce w tym schemacie zostało bardzo źle rozplanowane. Przede wszystkim warto zwracać uwagę, by linie na rysunku się nie przecinały – wówczas schemat będzie znacznie czytelniejszy. W końcu ma on ułatwiać nam pracę, a nie ją utrudniać.

W celu zwiększenia przejrzystości zmodyfikujemy nasz diagram, przesuwając poszczególne elementy oraz dodając związek rozszerzania. Pozawala on określić taką sytuację, w której występuje pewien przypadek bazowy oraz inny przypadek, będący szczególną odmianą przypadku bazowego, rozszerzający go o jakieś specyficzne cechy. Typowym tego przykładem może być sytuacja, gdy przypadkiem bazowym jest „edytuj”, a jego szczególnymi odmianami – „dodaj” lub „usuń”. Dodawanie i usuwanie to też edycja, ale szczególnego rodzaju.

W schemacie związek rozszerzania przedstawiany jest za pomocą strzałki skierowanej od przypadku rozszerzającego do bazowego, oznaczonej dodatkowo napisem <<extend>>:

R1aEAWoeEqtCM

Ilustracja przedstawia dwa zielone okręgi z wpisami: bazowy przypadek oraz rozszerzający przypadek.
Połączone są przerywaną strzałką podpisaną jako extend.

Do naszego diagramu dodamy funkcję edytowania oceny (jako przypadek bazowy), oraz dwie dodatkowe operacje rozszerzające: usuwanie oraz dodawanie ocen.

Oto diagram po wprowadzeniu powyższych zmian:

R1LVBmzbvFcOd

Ilustracja przedstawia diagram.
Od okręgu z wpisem: wyświetl ocenę wychodzą proste do ikon z podpisami: Uczeń, rodzic, nauczyciel.
Od okręgu z wpisem: usprawiedliw nieobecność wychodzi prosta do ikony z podpisem wychowawca a następnie strzałka prowadzi do ikony podpisanej jako: Nauczyciel.
Od okręgu z wpisem: edytuj ocenę wychodzi prosta do ikony podpisanej jako: Nauczyciel.
Do okręgu z podpisem edytuj ocenę prowadzą dwie przerywane strzałki extend od okręgów z wpisami: dodaj ocenę. usuń ocenę.
Od okręgu usuń ocenę wychodzi przerywana strzałka include do okręgu z wpisem: wyświetl ocenę.

Warto w tym momencie podkreślić, czym w zasadzie różni się include od extend. Najważniejszą różnicą między tymi dwoma związkami jest to, że w przypadku include dołączona operacja (tutaj wyświetlanie oceny) jest konieczna i zawsze wykonywana. Natomiast w przypadku relacji extend mamy do czynienia z operacjami opcjonalnymi, (czyli w naszym diagramie usunięcie i dodanie oceny nie zawsze są wykonywane przy okazji edycji oceny). Należy również wyjaśnić, że czynności usuwania i dodawania oceny nie muszą być wykonywane jednocześnie, tzn. jeżeli dodajemy jakąś ocenę, nie musimy usuwać żadnej innej oceny, a gdy jakąś usuwamy, nie musimy dodawać nowej.

W momencie, gdy mamy diagram w takim kształcie, możemy zauważyć, że rodzic i uczeń mają ten sam przypadek użycia: wyświetlanie oceny. W sytuacji, gdy dwóch aktorów posiada identyczne przypadki użycia, warto się zastanowić, czy na pewno prawidłowo przeanalizowaliśmy nasz system i czy czasem nie pominęliśmy jakiegoś istotnego elementu.

Zarówno uczeń, jak i rodzic są jednak dość istotnymi członkami społeczności szkolnej, dlatego nie należy usuwać żadnego z nich.

Dlatego też, gdybyśmy faktycznie chcieli zrealizować taki system, powinniśmy dopisać kolejne przypadki użycia do poszczególnych aktorów.

Diagram przypadków użycia

Skoro wiemy już, jak się posługiwać diagramem przypadków użycia, możemy zastosować go w praktyce. Naszym aktorem będzie gracz, który może rozpoczynać grę, zatrzymywać ją i uruchamiać ponownie (restartowanie gry oznacza rozpoczęcie nowej rozgrywki), a także sterować wężem i zbierać punkty poprzez zjadanie owoców.

Nasz diagram będzie zatem wyglądał następująco:

Rrv4OJGYBCPBf

Ilustracja przedstawia diagram.
Od ikony podpisanej jako: gracz wychodzą proste do okręgów z wpisami: rozpocznij, zatrzymaj grę na chwilę, uruchom ponownie grę, steruj wężem, zbierz punkty, zrestartuj grę.
Od okręgu z wpisem: zrestartuj grę wychodzi przerywana strzałka include prowadząca do okręgu z wpisem: rozpocznij rozgrywkę.
Od okręgu z wpisem: zbierz punkty wychodzi przerywana strzałka include prowadząca do okręgu z wpisem: zjedz owoc.

Tak rozpisany diagram nie jest imponujący ani też nie wyjaśnia samej mechaniki rozgrywki. Zawiera jednak wszystkie wspomniane przez klienta czynności, jakie może wykonać sam gracz. Na tym etapie powinniśmy więc przedstawić nasz schemat klientowi do akceptacji, by upewnić się, czy to są ostatecznie wszystkie czynności, jakie może podjąć gracz w samej rozgrywce.

Zleceniodawca może sobie teraz przypomnieć o pewnych cechach programu, o których wcześniej nie wspomniał, na przykład:

Na tym etapie klient może zgłosić wiele podobnych uwag i pomysłów. Diagram sporządzamy zarówno po to, żeby klient był zadowolony ze współpracy i otrzymał oczekiwany produkt, jak i po to – co równie ważne – by zoptymalizować proces tworzenia oprogramowania. Modyfikowanie gry na papierze nie stanowi zbyt wielkiej komplikacji. Jeśli jednak tego typu prośba zostanie zgłoszona na etapie, gdy prace nad programem będą już zaawansowane, może się okazać, że potrzebna jest przebudowa znacznej części kodu. Jeżeli zaś klient zatwierdzi projekt lub naniesie poprawki w odpowiednim momencie, wówczas z takim problemem się nie spotkamy.

Musimy również przygotować dokumentację do diagramu oraz spisać – w pewnej skondensowanej formie – podane wcześniej przez zleceniodawcę wymagania. W tym celu skorzystamy z platformy Github, która umożliwia tworzenie takiej dokumentacji. Platforma ta jest przeznaczona dla projektów programistycznych wykorzystujących system kontroli wersji. Gdy w kolejnych e‑materiałach przejdziemy do pisania kodu, omówimy szczegółowo, na czym polega ten system. W podstawowej opcji (plan free) kontrola wersji jest darmowa.

Słownik