Ważne!

Więcej informacji na temat tego, w jaki  sposób zarządzać projektem informatycznym i z jakich etapów się składa, znajdziesz w e‑materiale Projekt informatyczny: jak nim zarządzać?PT8JpKnHWProjekt informatyczny: jak nim zarządzać?

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.

1

Chcę grę – takiego węża jak w starej Nokii 3030.

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ć.

1

Snake to prosta gra, w której kierujemy wężem na planszy dwuwymiarowej. Wąż przez cały czas się porusza, sterujemy więc jedynie kierunkiem jego ruchu. Na planszy pojawiają się owoce, które zbieramy. Owoc zostaje „zjedzony”, jeżeli wąż dotknie go swoją głową. W momencie zjedzenia owocu wąż wydłuża się o jedną kratkę. Im jest on dłuższy, tym więcej zdobywamy punktów. Jeśli wąż zje swój ogon (a więc jego głowa dotknie ogona), gra się kończy. Celem gracza jest uzbieranie jak największej liczby punktów. Gra ma być przeznaczona na komputery stacjonarne z systemem Windows 10 lub nowszym.

R28x0tV03cu1a
Film nawiązujący do gry o nazwie Snake.

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:

Linia 1. jeżeli wąż dotyka owoc wykonaj dwukropek. Linia 2. przedłuż otwórz nawias okrągły wąż kropka ogon zamknij nawias okrągły. Linia 3. jeżeli wąż dotyka wąż kropka ogon wykonaj dwukropek. Linia 4. zakończ grę i wyświetl wynik równy kropka kropka kropka.

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ć.

1

Wynik niech będzie równy długości ogona (nie licząc głowy) razy dziesięć.

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

Linia 1. jeżeli wąż dotyka owoc wykonaj dwukropek. Linia 2. przedłuż otwórz nawias okrągły wąż kropka ogon zamknij nawias okrągły. Linia 3. jeżeli wąż dotyka wąż kropka ogon wykonaj dwukropek. Linia 4. zakończ grę i wyświetl wynik równy 10 asterysk wąż kropka 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?

1

Na ekranie zmieniamy kierunek ruchu węża, klikając przyciski A i D. Gdy klikamy D, wąż skręci o 90 stopni w prawo, a jeśli A – o 90 stopni w lewo. Gdy klikniemy spację, włącza się pauza.

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:

Linia 1. dopóki gra znak równości znak równości trwa wykonuj dwukropek. Linia 2. jeżeli wąż dotyka owoc wykonaj dwukropek. Linia 3. przedłuż otwórz nawias okrągły wąż kropka ogon zamknij nawias okrągły. Linia 4. jeżeli wąż dotyka wąż kropka ogon wykonaj dwukropek. Linia 5. gra znak równości skończ. Linia 6. wyświetl wynik znak równości 10 asterysk wąż kropka ogon. Linia 7. jeżeli wcisnietyPrzycisk znak równości znak równości apostrof D apostrof wykonaj dwukropek. Linia 8. obrót o 90 stopni w prawo. Linia 9. w przeciwnym razie jeżeli wcisnietyPrzycisk znak równości znak równości apostrof A apostrof wykonaj dwukropek. Linia 10. obrót o 90 stopni w lewo. Linia 11. dopóki wcisnietyPrzycisk znak równości znak równości spacja wykonuj dwukropek. Linia 12. 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.

Ważne!

Wymagania funkcjonalne są opisem tego, „co w programie można robić i kto co robi”. Wymagania niefunkcjonalne są opisem informującym o tym, „jak program ma wyglądać” (do wymagań tych zaliczamy również bezpieczeństwo i niezawodność programu programu, łatwość jego używania i wydajność).

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 zainteresowanych

Podczas zbierania wymagań zalecane jest tworzenie tak zwanych user stories, czyli krótkich opowieści, które tłumaczą, kto i w jakim celu potrzebuje danej funkcjonalności. Przykładowo:
„Jako właściciel restauracji, chcę mieć możliwość sprawdzenia aktualnie realizowanych zamówień, aby mieć kontrolę nad wszystkimi procesami” lub:
„Jako klient zamawiający jedzenie, chcę mieć możliwość sprawdzenia swojego opłaconego zamówienia, aby móc oszacować, jak długo będę jeszcze musiał czekać na dostawę”.

Tak sformułowane opisy mogą teraz zostać zmienione na następujące wymagania funkcjonalne:
„Właściciel restauracji musi mieć możliwość sprawdzenia aktualnych zamówień.”
„Klient zamawiający jedzenie musi mieć możliwość sprawdzenia przewidywanego czasu oczekiwania na dostawę.”
„Klient zamawiający jedzenie musi mieć możliwość sprawdzenia swojego zamówienia po jego opłaceniu.”

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.

Polecenie 1

W przeprowadzonym wywiadzie została pominięta co najmniej jedna kluczowa informacja na temat działania rozgrywki – zostanie ona zidentyfikowana dopiero w kolejnych e‑materiałach z serii. Zastanów się, jakiej informacji brakuje.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

a tak asocjacja skierowana:

RYFuC0ybsx8T3
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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.

Praca domowa

Zastanów się jakie kolejne przypadki użycia pasują do aktorów obecnych w dzienniku elektronicznym. Pamiętaj: jeżeli uznasz, że jakiś aktor jest istotny, a nie został w diagramie umieszczony, nic nie stoi na przeszkodzie, aby go na tym etapie dodać.

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
Źródło: Contentplus.pl Sp. z o.o., licencja: CC BY-SA 3.0.

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:

1

Chcę, żeby można było zapisywać aktualny stan rozgrywki, a po zatrzymaniu gry wrócić do niej i kontynuować z tego samego miejsca.

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.

Ciekawostka

Zakładając konto w serwisie Github, podajemy nazwę użytkownika, czyli username. Pamiętajmy, że to nie imię i nazwisko - te dane wpisujemy na późniejszym etapie konfiguracji. Warto dodać, że podawanie ich nie jest obowiązkowe. Właściciel platformy Steam Gabe Newell znany jest jako „Gaben”, a  programista Markus Persson, twórca gry Minecraft, używa pseudonimu „Notch”.

Ważne!

Dokumentacja projektowa (oprogramowania) powinna zawierać zakres i podział prac oraz ich harmonogram. Może ona obejmować:

  • plany, harmonogramy, szacunki;

  • diagramy, schematy i algorytmy, związane z fazami realizacji zadań,

  • raporty;

  • kod źródłowy;

  • wymianę informacji między członkami zespołu na temat realizacji poszczególnych zadań. Więcej informacji na temat dokumentacji projektu znajdziesz w e‑materiale Dokumentacja projektu (edycja dokumentów)DUZAl2PPCDokumentacja projektu (edycja dokumentów).

Słownik

dokumentacja oprogramowania
dokumentacja oprogramowania

zbiór dokumentacji technicznej i dokumentacji użytkownika stworzonej dla określonego programu komputerowego i jego kodu źródłowego przez jego twórców; często również jako załącznik do umowy, opisujący zakres wykonanych bądź zaplanowanych prac

język UML
język UML

ang. Unified Modeling Language (zunifikowany język modelowania) – język służący do opisywania, modelowania fragmentu istniejącej rzeczywistości; umożliwia tworzenie diagramów, które w sposób formalny opisują struktury, procesy lub wybrane etapy wdrożenia oprogramowania; wyróżnia się wiele różnych diagramów, które wchodzą w skład języka UML

system kontroli wersji
system kontroli wersji

oprogramowanie służące do sprawdzania zmian w kodzie źródłowym danego programu oraz do łączenia (ang. to merge) różnych plików zmodyfikowanych w różnym czasie przez różne osoby, najczęściej na różnych komputerach