Inżynieria systemów mobilnych
Proces projektowania opisany poniżej jest w wielu aspektach typowy dla inżynierii oprogramowania. Jednak uwzględniono w nim nie tylko dobre praktyki stosowane dotąd przez programistów, ale też postulaty płynące z branży UX. Dotyczy to na przykład wprowadzenia "person" oraz opisu procesu projektowania jako metodologii zwinnej.
Analiza funkcjonalna
Celem analizy funkcjonalnej jest ustalenie wymagań wobec projektowanego systemu oraz przełożenie tych wymagań na jego funkcje.
Pracę tą wykonujemy, korzystając z wcześniejszych ustaleń, wykonanych w trakcie analizy merytorycznej i zawartych we wstępnym projekcie.
Odnosząc się do metod zarządzania projektami, należy uznać, że analiza funkcjonalna rozpoczyna się od ustalenia zakresu projektu, następnie dokonujemy analizy interesariuszy i przechodzimy do ustalenia szczegółowych celów projektu.
Wśród interesariuszy należy wyróżnić aktorów, którzy będą użytkownikami tworzonego systemu. Pojęcie „aktor” ma tu jednak szersze znaczenie, gdyż obejmuje także poza-osobowe elementy systemu (moduły, programy). Stosując podejście oparte na doświadczeniach użytkowników (UX) można wprowadzić wiele "person" - czyli fikcyjnych użytkowników reprezentujących zidentyfikowane typy zachowań.
Posiadając informacje o aktorach i celach, jakie im przyświecają, możemy dokonać analizy oczekiwanych funkcji.
Zakres
Zgodnie z propozycją Cockburna [1], zakres projektu możemy ustalić poprzez stworzenie wykazu tematów (funkcji), jakie zidentyfikowaliśmy w trakcie analizy i podjęcie decyzji, które z nich zostaną ujęte w analizowanym systemie.
Tworzy się w ten sposób tabelkę opisującą zakres funkcjonalny systemu jako zestawienie w/poza:
| Lp | Temat | W | POZA |
|---|---|---|---|
| Zagadnienie 1 | |||
| 1-1 | Temat 1 | X | |
| 1-2 | Temat 2 | X | |
| 1-3 | Temat 3 | X | |
| Zagadnienie 2 | |||
| 2-1 | ... |
Tabela 1. Lista W/POZA
Interesariusze
Aktorzy
Do celów analizy funkcjonalnej musimy ustalić interesariuszy, którzy będą aktywnie uczestniczyć w działaniu systemu. Nazywa się ich aktorami. Aktorów możemy zestawić w tabeli, opisującej także kluczowe potrzeby, jakie system powinien uwzględnić.
| Aktor | Kluczowe potrzeby |
|---|---|
| Aktor1 | Opis potrzeb …. |
| ... | ... |
Tabela 2. Główni aktorzy
Persony
Jeśli analiza funkcjonalna przy pomocy przypadków użycia ma uwzględniać potrzeby użytkowników (UX), to musimy stworzyć „szkice” potencjalnych odbiorców. Nazywa się je personami osób. Persony wyposaża się w konkretne imię, opisuje zwięźle główne cechy i określa potrzeby. Na przykład analiza funkcjonalna Twittera może zawierać opis1:
Imię: Marek.
Zawód: Webdeweloper aplikacji opartych na Ruby on Rails, przedsiębiorca.
Cytat: „Chcę używać Twittera do prowadzenia inteligentnych dyskusji z inteligentnymi ludźmi, a także do promowania moich różnych aplikacji internetowych i zbierania uwag na ich temat. Podczas usuwania błędów odczuwam chęć spytania ludzi na Twitterze o radę”.
Potrzeby: Śledzenie dyskusji; łatwe przeglądanie wielu tweetów.
Pozostali interesariusze
Analiza pozostałych interesariuszy nie ma znaczenia dla samego docelowego projektu, ale jest ważnym elementem zarządzania projektami, który może decydować o jego sukcesie. Analiza taka obejmuje informacje, jakie będzie oddziaływanie projektu na interesariuszy, jaki oni mają wpływ na projekt i jaką wobec nich podjąć strategię. Na przykład zarząd firmy może nie korzystać bezpośrednio z projektowanego systemu, ale ma nań decydujący wpływ (finansowanie) i będą go dotyczyć uzyskiwane efekty. Dlatego należy przyjąć strategię polegającą na informowaniu o oczekiwanych efektach i postępach prac.
| Interesariusz | Oddziaływanie projektu | Wpływ na projekt | Strategia |
|---|---|---|---|
Tabela 3. Analiza interesariuszy
Cele szczegółowe
Główny cel postawiony przed systemem musimy poprzez analizę rozbić na cele szczegółowe, które dotyczą poszczególnych aktorów. Znów można zaproponować tabelę zawierającą listę aktor – cel:
| Lp | Główny aktor | Cel | Priorytet |
|---|---|---|---|
| 1 | Aktor 1 | Cel 1 | wysoki |
| 2 | ... | …. |
Tabela 4. Lista cel – aktor (do uzupełnienia)
Przypadki użycia (use cases)
Przypadki użycia to opisyw jaki sposób system powinien być używanyprzez aktora w celu osiągnięcia konkretnego celu. Opis ten nie zawiera szczegółów dotyczących implementacji oraz interfejsu użytkownika.
Pomimo tego, że przypadki użycia są stosunkowo prostym narzędziem analizy systemów, istnieje wokół nich wiele kontrowersji. W niniejszym opracowaniu wykorzystano podejścieAlistaira Cockburnaopisane w pracy„Writing Effective Use Cases”(polskie tłumaczenie „Jak pisać efektywne przypadki użycia” wydało PWN [1]).
Jednak słuszną wydaje się krytyka Jarosława Żelińskiego, który zarzuca Cokburnowi zbytnie komplikowanie prostego zagadnienia. Podejście jakie tutaj zastosujemy jest czysto pragmatyczne. Wybrane zostaną z propozycji Cokburna te elementy, które ułatwiają osiągnięcie zapisanego na początku celu. Jako nieporozumienie można traktować w związku z tym opisywanie przypadków użycia jako alternatywy dla procesów biznesowych (zob.Łukasz Olek, „Wykorzystanie przypadków użycia do opisywania procesów biznesowych”).
Cockburn proponuje określenie dla każdego przypadku użycia, jaki jest jego zakres i poziom:
| zakres | ang. |
|---|---|
| gospodarczy - opis zewnętrzny | enterprise |
| gospodarczy - szczegóły | system |
| systemowy - opis zewnętrzny | subsystem |
| systemowy - szczegóły | subsystem |
| komponentowy | component |
Tabela 5. Oznaczenia zakresu projektowego
| opis ogólny | very high summary |
|---|---|
| poziom streszczenia | summary |
| poziom użytkownika (niebieski) | user-goal |
| podfunkcje | subfunction |
| poziom najniższy | too low |
Tabela 6. Oznaczenie nazwanych poziomów
Cele wyższego poziomu skupiają się na pytaniu:dlaczego; poziom niższy –jak.
Pomimo kontrowersji wokół potrzeby takiego szczegółowego rozróżnienia, nie sądzę, aby jego stosowanie prowadziło do zaciemnienia projektu, a niekiedy może być przydatne. Dlatego można to traktować jako opcjonalny element analizy (dodatkowe objaśnienie).
Szkice przypadków użycia
Tworzenie przypadków użycia rozpoczynamy od ich zestawienia zawierającego aktora głównego oraz szkic (będący po prostu prostym opisem w języku potocznym celu i sposobu, w jaki ten cel będzie osiągany). Możemy takie zestawienie ująć w tabeli:
| ID | zakres | poziom | Aktor główny | Szkic |
|---|---|---|---|---|
| ... | ... | |||
Tabela 7. Szkice przypadków użycia (do uzupełnienia)
Przypadki użycia
Przypadki użycia należy opisywać w postaci tekstowej, traktując schematy (UML) jako poglądową ilustrację. Zgodnie z propozycją Cockburna, przypadek użycia powinien mieć następującą strukturę:
Cel w kontekście:
Minimalna gwarancja: (co zostaje zrealizowane na pewno)
Główny scenariusz powodzenia: (jak to zostanie zrealizowane)
Rozszerzenia:(dodatkowe/alternatywne działania, wyjątki)
| Warunki rozszerzeń | Obsługa rozszerzeń | |
|---|---|---|
| 1 |
Ponieważ niniejszy tekst zostanie zilustrowany praktycznym przypadkiem analizy, poprzestańmy tutaj na takim pobieżnym opisie.
User Journey Map
Alternatywą lub uzupełnieniem przypadków użycia może być wypracowana przez marketingowców technika „podążania za użytkownikiem”. Polega ona na tym, że „wchodzimy w buty” klienta i opisujemy po kolei co robi, aby zaspokoić swe potrzeby. Nasz produkt powinien w naturalny sposób wspomóc go w tych działaniach.
Zobacz przykłady: http://blog.uxeria.com/10-najciekawszych-przykladow-customer-journey-map/
Literatura:
[1] Alistair Cockburn „Jak pisać efektywne przypadki użycia”, WNT 2004 (Alistair Cockburn: WRITING EFFECTIVE USE CASESAdres URL)
[2] "Identifying and Analyzing Stakeholders and Their Interests"
Proces projektowania
Projekt inżynierski przebiega zgodnie z ustalonymi na podstawie doświadczeń regułami.
Warto zacząć od wypisania czegoś w rodzaju spisu treści – czyli „content inventory”.
Następnym działaniem może być być stworzenie „makiety”- czyli prototypu produktu. Szkieletem (lub makietą) nazywamy prosty – pozbawiony szczegółów „projektanckich” (design) projekt nawigacji (ekranów). Ma on przede wszystkim pozwolić na rozeznanie, gdzie jakie informacje powinny się pojawiać.
Strategiaprzechodzenia od projektu funkcjonalnego w postaci „makiety” do bazy danych i programów ją obsługującychjest działaniem w dużym stopniu rutynowym – zależnym od zastosowanych technologii.
Te trzy działania nakładają się na siebie. W tego typu projektach sprawdza się metodologia „zwinna”. Zwiększa się rola programistów –którzy powinni być członkami zespołu projektowego, a nie jedynie wykonawcami.
Do stworzenia spisu treści może posłużyćzwykłyarkusz kalkulacyjny (np.Excel). tnieje też wiele specjalizowanych narzędzi (videhttps://www.slideshare.net/alinaguzikcom/90-narzdzi-rozwoju-produktu-cz-12). Na przykład
[źródło:http://maadmob.com.au/resources/content_inventory\]
Niezliczona ilość narzędzijest dostępnado projektowaniamakiet. Na przykład http://protostrap.com/dashboard/designer/edit.
Do projektowania baz danych i implementacji obsługujących je programów można wykorzystać klasyczne podejście CASE(http://home.agh.edu.pl/~pioro/dyd/BD2/LR-dbdes.pdf).W przypadku wielu serwisów internetowych sensowne jest jednak rozważenie podejścia opartego o interfejsy (zdefiniowane sposoby przesyłania danych). Dane są przesyłane najczęściej w postaci struktur JSON. W takiej sytuacji sensowne może być pamiętanie danych w takiej samej postaci – na przykład w bazie MongoDB (https://pl.wikipedia.org/wiki/MongoDB).
Metodologia zwinna
Opisane powyżejdziałania nakładają się na siebie.Jeśli są one na dodatek prowadzone w zespole – należy zorganizować pracę tego zespołu tak, aby możliwe było poprawianie projektu w konfrontacji z użytkownikami.W tego typu projektach sprawdzająsię metodologie„zwinne”.
Metodologię taką opracował Google (https://developers.google.com/design-sprint/product/):
Zrozumienie
Pierwsza część tego sprintu wymaga wcześniejszego przygotowania: poproszenie odpowiednich osób do szybkiego udostępniania prezentacji na 5 minut: cele biznesowe, możliwości technologii, potrzeby użytkownika.
Definiowanie
W tej fazie zespół zaczyna opracowywać swoją strategię i metodologię. Celem jest stworzenie głównego scenariusza jaki chcą stworzyć dla użytkowników.
Rozbiór
Często zespoły wybierają pierwszy gotowy pomysł, aby kontynuować. Faza rozbioru zachęca zespół do zrobienia czegoś przeciwnego: najpierw wygeneruj jak najwięcej pomysłów, zanim zdecydujesz się na najlepszą opcję. Na tym etapie wszyscy zachęcani są do pracy indywidualnie w celu szkicowania pomysłów.
Decyzja
W tej sekcji nadszedł czas, aby zespół przeanalizował wszystkie pomysły z fazy Rozbioru i przegłosował najlepsze opcje. Zespół może wybrać 1-3 pomysłów na prototyp i test.
Prototyp
Szybkie prototypowanie pozwala przetestować swoje pomysły bez konieczności inwestowania mnóstwa czasu, pieniędzy lub zasobów. W ten sposób będziesz wiedział wcześniej, jakie aspekty pomysłów są błędne i które mają potencjał.
Sprawdzanie
Ta ostatnia faza to wtedy, kiedy nadszedł czas, aby odpowiedzieć na najtrudniejsze pytanie w projekcie: "Czy ten pomysł jest dobry?" W tym celu zespół powinien zapraszać potencjalnych użytkowników do testowania swoich pomysłów. Obserwują oni interakcje użytkowników z prototypem i robią notatki.