- Zanim zaczniemy
- Podstawy
- Rozwiązywany problem i cel aplikacji
- Opis sytuacji
- Wymagania
- Kontekst biznesowy
- Skutki nie rozwiązania problemu ?
- Użytkownicy, grupa docelowa aplikacji
- Rodzaje aplikacji i dopasowanie rozwiązania do problemu
- Rodzaje aplikacji biznesowych
- Rodzaje “klientów aplikacji”
- Podsumowanie
- Zebranie wymagań i potrzeb
- Zakres aplikacji
- Funkcjonalności aplikacji
- Widoki
- Integracje
- Infrastruktura
- Szybkość, wydajność i skalowanie
Zanim zaczniemy
Aplikacja webowa = aplikacja internetowa
Aplikacja ≠ Strona
Podstawy
Rozwiązywany problem i cel aplikacji
Każdy pomysł na aplikację powinien zaczynać się od konkretnego problemu, który chcemy rozwiązać. Tutaj technologia odchodzi na bok i porozmawiamy o tym później.
Jasno określony cel zbudowania aplikacji i dotarcie do sedna problemu ułatwia ogólną perspektywę na aplikację. Dotarcie do sedna problemu sprawia, że unikamy kosztów na pomyłki i tworzenia zbędnych funkcjonalności.
Przykładowe problemy, które możemy rozwiązać to:
- zautomatyzowanie procesu sprzedaży, zarządzania, logistyki czy magazynu
- zarządzanie projektami, zasobami ludzkimi, relacją z klientem
- zarządzanie zasobami fizycznymi: magazyn
- wizualizacja zebranych danych i łatwiejsze podejmowanie decyzji w oparciu o dane
- zbudowanie platformy dla klientów, w której mogą podejmować akcje w biznesie
- analiza danych, których nie jesteśmy w stanie obsłużyć sami
… i milion innych
Opis sytuacji
Aby zbudować aplikację trzeba opisać sytuację. Nadać lepszy kontekst. Krótka charakteryzacja w jasny i precyzyjny sposób. Istotne jest zrozumieć o co chodzi pomysłodawcy aplikacji.
Wymagania
Informacja na temat tego jakie wymagania powinna spełniać aplikacja webowa. Ile ma mieć użytkowników, jakich użytkowników, łatwość używania, ilość przetworzonych danych, pochodzenie serwera.
Kontekst biznesowy
Lepsze poznanie użytkowników systemu i biznesu, dla którego budujemy ułatwia zaprojektowanie aplikacji. Poznanie użytkowników końcowych, ich preferencji, wieku, pochodzenia, ułatwi zrozumienie potrzeby użytkowników, którzy będą korzystać z aplikacji.
Skutki nie rozwiązania problemu ?
Co się stanie jeśli nie rozwiążemy problemu ? Może to nadać lepszego kontekstu w budowaniu aplikacji i dotarcia do sedna problem. Negatywny skutek nie rozwiązania problemu prowadzi do lepszego rozwiązania.
Użytkownicy, grupa docelowa aplikacji
W każdej aplikacji jest użytkownik. Rodzaj użytkownika nazywany jest Aktorem.
Poznanie użytkownika ułatwia projektowanie aplikacji w kontekście funkcjonalności, użyteczności, interfejsu użytkownika, komunikacji z nim i przyszłego rozwoju.
Co dobrze wiedzieć o użytkownikach systemu ?
To jakie narzędzia dobierzemy, jest drugorzędne. Najważniejsza jest istota problemu 🙂
Rodzaje aplikacji i dopasowanie rozwiązania do problemu
Aplikacja webowa to bardzo ogólne stwierdzenie rodzaju aplikacji otwieranej w przeglądarce. Na ogół charakteryzuje się tym, że przechowuje, wyświetla i zapisuje dane . Użytkownik może wchodzi z nią w interakcję np. dodawać/edytować/usuwać dane.
Rodzaje aplikacji biznesowych
Aplikacje biznesowe to aplikacje, które realizujące cele biznesowe, automatyzują procesy biznesowe czy pomagają w prowadzeniu i zarządzaniu biznesem.
Główne rodzaje aplikacji biznesowych to:
- Aplikacja “in house” - realizuje specyficzny proces operacyjny biznesu
- Platforma - aplikacja do tworzenia aplikacji
- Sklep internetowy / ecommerce - gdy chcemy sprzedawać produkty
- Aplikacja e-learning / nauka online
- Aplikacja społecznościowa
- Aplikacja marketplace - aplikacja z kilkoma stronami rynku
- Aplikacja SaaS - aplikacja, która może być replikowana dla kilku podmiotów
- API, algorytm, serwis backendowy - aplikacja, która chodzi w tle i realizuje jakiś algorytm, kalkulator i przetwarza dane
- są też inne tj. IoT, VR, AR, blockchainowe, gry, ale to temat na inny moment
Rodzaje “klientów aplikacji”
“Klient aplikacji” to sposób interakcji użytkownika z aplikacją. Inaczej mówiąc interfejs.
Popularne rodzaje klientów aplikacji to:
- aplikacja desktop (okienkowa)
- aplikacja mobilna
- aplikacja na tablet
- aplikacja webowa uruchamiana w przeglądarce
- API - sposób na interakcję z aplikacją ”od kuchni” za pomocą komend i kodu
Podsumowanie
Mamy już zdefiniowane potrzeby, cele i wymagania. Znamy kontekst i opis sytuacji.
Wiemy kto będzie korzystał z naszej aplikacji i po co chcemy budować aplikację.
Znamy także wstępny sposób na rozwiązanie problemu poprzez wybranie typu aplikacji i klienta aplikacji (interfejs).
Możemy przejść do zbierania szczegółowych wymagań i potrzeb, które ma spełnia.
Zebranie wymagań i potrzeb
Gdy określony jest problem i cel aplikacji można przejść do szczegółowego zbierania wymagań nt. zakresu aplikacji, o sposobach interakcji użytkowników, ich praw dostępu i tematach związanych z wydajnością i dostępnością aplikacji.
Zakres aplikacji
Funkcjonalności aplikacji
Aplikacja przede wszystkim ma spełniać wymagania użytkowników. Możemy zatem zdefiniować funkcjonalności.
Możliwości jest tutaj nieskończoność. Przykładowe funkcjonalności to:
- Przechowywanie danych (a więc dodawanie, edytowanie, wyświetlanie, usuwanie)
- Automatyczne zbieranie danych nt. firmy
- Komunikacja aplikacji ze światem i z użytkownikami poprzez: powiadomienia, notyfikacje, wysyłanie emaili, smsów
- Automatyzacja konkretnego procesu.
- Możliwość śledzenia ruchu użytkownika i analityka jego zachowań i akcji, które są wykonywane.
- Praca na danych: wizualizowanie, agregowanie i analiza danych.
- Przetwarzanie dużej ilości ruchu z internetu i sposób jej obsługi.
- Przetwarzanie płatności, rozdzielanie płatności, naliczanie prowizji.
- Składanie zamówienia i obsługa procesu logistyki
… i wiele wiele innych co tylko sobie zażyczysz 🙂
Widoki
W tym kroku projektujemy konkretne strony aplikacji, w których użytkownik będzie wchodził w interakcję z użytkownikami.
Plan stron/widoku/widoków i ich wzajemna relacja nazywa się makieta i dobrze gdy pokazuje z czego ma składać się dany widok oraz jak konkretny komponent strony wpływa na działanie systemu i wyświetlanie innych stron.
Inaczej mówiąc plan i makiety pokazuje relacje stron i przechodzenie między stronami w obrębie całej aplikacji i systemu.
Integracje
Aplikacja może mieć potrzebę łączenia się z zewnętrznymi usługami w celu pobrania potrzebnych informacji “ze świata” / z zewnątrz np. pogoda, ceny akcji, wykonania konkretnej akcji, wysłania pakietu danych, otrzymania danych z innego systemu.
Integracje przeważnie wykonywane są poprzez API i mogą dotyczyć praktycznie każdego aspektu wymagania i zadania. Niemożliwe jest wymienienie ich wszystkich, bo to zależy od funkcji, którą ma spełniać dana integracja w ramach aplikacji
Infrastruktura
Aplikacja to jedna ze składowych całego systemu. Innym klockiem jest np. baza danych albo inna aplikacja, z którą się komunikujemy.
Wszystkie składowe systemu tworzą całość i są uruchamiane w konkretnej infrastrukturze i środowisku.
Rodzaj infrastruktury to np. serwer fizyczny, serwer wirtualny, chmura prywatna i publiczna lub serverless
Warto dopasować infrastrukturę do faktycznego zapotrzebowania i zależne jest to od wielu czynników tj.:
- ruch na stronie albo możliwy “nagły ruch na stronie” tzw “peak”
- bezpieczeństwo i prywatność danych
- koszty infrastruktury
- ilość zużywanych zasobów zarówno jednorazowo jak i wolumenowo (zsumowane wykorzystanie zasobów)
Szybkość, wydajność i skalowanie
Problem przeważnie dotyczy aplikacji o większej ilości danych. Oczywiście nawet małe aplikacje z powodu złej optymalizacji i np. ciężkich plików (grafik) mogą być wolne.
Jeśli liczba obiektów, którą przetwarzamy jest między 1, a 1000 czy 10000 (w praktyce cięzko określić granicę w liczbie) to jest to nadal stosunkowo niewielka liczba, którą system ma obsłużyć.
Wyzwanie zaczyna się w momencie gdy liczba użytkowników i ilość obiektów w bazie danych rośnie.
Są sposoby na optymalną i wydajną pracę aplikacji, a w skład tego wchodzi dobre zaprojektowanie i przemyślana
- baza danych: indeksowanie, relacje, zwracanie tylko potrzebnych informacji, normalizacja, optymalne zapytania, a nawet partycje
- paginacja( w sytuacji gdy pobieramy dane na interfejs aplikacji). Jest to pobieranie tylko istotnej grupy obiektów w porcjach np. po 50, 100 a nie całości.
- pliki statyczne(skrypty, style, grafiki, zdjęcia, obrazki, miniaturki, czcionki, audio, video)