• 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
• Dostępność
• Użytkownicy
• Rodzaj użytkowników tzw. aktorzy aplikacji
• User stories
• Role i dostępy
• Sposób logowania
• Koszty czasowe i cenowe
• Czas
• Koszt
• Development
• Wybór narzędzi
• Na co zwrócić uwagę wybierając narzędzia ?
• No Code, Low Code czy Full Code ?
• Wybór narzędzia
• Przegląd narzędzi programistycznych
• Narzędzia do tworzenia logiki i backend’u używając kodu
• Narzędzia do frontend’u używając kodu
• Bazy danych
• Przegląd narzędzi No Code
• Podział aplikacji nocode ze względu na zastosowanie:
• Infrastruktura aplikacji fullcode
• Infrastruktura aplikacji nocode
• Tworzenie aplikacji
• Backend:
• Frontend:
• Integracja frontend ↔ backend
• Bezpieczeństwo
• Testy
• Wdrożenie aplikacji
• Dokumentacja
• Proces późniejszego wdrażania
• Proces utrzymania
• Proces rozwoju oprogramowania
• Komunikacja przy tworzeniu aplikacji
• QA
• Słownik

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)
• asynchroniczna praca aplikacji
• asynchroniczne generowanie i zaczytywanie plików

Jednak problem adresuje się w momencie wystąpienia potrzeby. Tutaj chcę uspokoić, że możliwości na optymalizację jest dużo także tematem warto się zainteresować gdy pojawi się potrzeba.

Dostępność

Warto zdefiniować jakie są wymagania odnośnie dostępności aplikacji.

Czy aplikacja ma być dostępna głównie w godzinach pracy tj. 8-17, czy 24/7/365 (system płatniczy.

W zależności od potrzeby na dostępność aplikacji dopasowuje się odpowiednią infrastrukturę, w której wybieramy np. sposób wdrażania aplikacji ze środowiska testowego na środowisko produkcyjne.

Użytkownicy

Rodzaj użytkowników tzw. aktorzy aplikacji

Naturalne, że z aplikacji będą korzystać użytkownicy. Przeważnie są różne rodzaje użytkownika i ich możliwości interakcji z systemem.

Rodzaj użytkownika nazywa się “aktor” i jest to zdefiniowanie użytkowników i ich wpływu i praw dostępu do danych zasobów w aplikacji.

Jeśli w systemie mamy np. pracownika, klienta i managera to:

• pracownik może widzieć wszystkich klientów i nimi zarządzać np. dodawać, edytować i usuwać
• klient może widzieć tylko swoje dane, ale nie widzi danych innych klientów
• manager może zarządzać zarówno klientami ale i pracownikami, może mieć dostęp do podsumowań, których nie widzi pracownik

To tylko prosty przykład, ale może zobrazować kim są aktorzy w systemie i jaka jest ich wzajemna

User stories

User story (historia użytkownika) to proste i zrozumiałe wyrażenie potrzeb użytkownika w kontekście jego interakcji z aplikacją.

User story opisuje, kim jest użytkownik, co chce osiągnąć i dlaczego.

Opisuje się to w formie zwięzłego zdanie lub krótkiego opisu, który koncentruje się na wartości dla użytkownika.

Przykładowo:

• "Jako klient, chcę móc wyszukiwać produkty na stronie, aby łatwo znaleźć interesujący mnie produkt"
• "Jako klient, chcę móc zobaczyć swoje dane adresowe"
• “Jako manager chcę mieć możliwość wyświetlenia wszystkich pracowników”
• “Jako pracownik chcę mieć możliwość wyświetlenia wszystkich klientów firmy”

Po zdefiniowaniu user stories łatwo określić sposób interakcji użytkownika z systemem.

User stories opisuje się dzięki wywiadom z użytkownikami, obserwacja użytkowników, warsztaty, burze mózgów lub analizy i badania.

Role i dostępy

Jeśli wiemy jacy aktorzy (rodzaje użytkowników) poruszają się po systemie oraz jakie funkcjonalności chcemy w systemie możemy zdefiniować role i dostępy.

Polega to na tym, że określamy jaki aktor (rodzaj użytkownika) należy do jakiej roli (grupa użytkowników) oraz jakie dostępy mają te role.

Uprawnienia nadawane grupowo ułatwiają przydzielanie każdemu użytkownikami osobnej roli. Znacznie łatwiej jest przydzielić użytkownika do grupy, a dopiero grupie nadać konkretne dostępy.

Nadawanie dostępu dla konkretnej roli nazywane jest również Autoryzacją.

Sposób logowania

Każdy użytkownik powinien zobaczyć zasoby z aplikacji dopiero wtedy gdy potwierdzimy jego tożsamość i potwierdzimy to, że dany użytkownik może zobaczyć konkretne dane (zasoby aplikacji.

Proces ten nazywa się Autentykacją, w której sprawdzamy autentyczność i zgodność danych.

Przykładowe rodzaje autentykacji to:

• formularze - użytkownik podaje swój login i hasło, a system weryfikuje poprawność danych.
• tokeny - użytkownik komunikuje się z systemem za pośrednictwem unikalnego klucza. klucz ten jest unikalny dla danego użytkownika i dzięki temu kluczowi użytkownik wchodzi w interakcję z systemem nie ujawniając loginu i hasła.
• OTP - one time password - autentykacja zachodzi poprzez kliknięcie w konkretny link (tzw. magic link) np. wysyłany na email powiązany z kontem użytkownika w aplikacji
• OAuth - umożliwia dostęp do zasobów bez konieczności podawania hasła w systemie, do którego chcemy uzyskać dostęp. Dostęp odbywa się poprzez np. konta i platformy społecznościowe tj. Google, Facebook czy Github
• 2FA ( 2 factor authentication ) - użytkownik musi przejść przez 2 etapy autentykacji np. formularz i kod z telefonu

Koszty czasowe i cenowe

Na koszty aplikacji wpływa kilka składowych i jest to:

• analiza biznesowa: ustalenia, planowanie, złożoność zadań
• komunikacja i organizacja projektowa między interesariuszami aplikacji
• development i tworzenie rozwiązania zarówno ze strony projektowania interfejsu użytkownika jak i backendu
• praca nad infrastrukturą, na której stawiamy aplikację w tym wdrażanie rozwiązania na środowisko produkcyjne i architektura finalnego rozwiązania i elementów aplikacji
• utrzymanie aplikacji: praca nad optymalizacją, wydajnością i pojawiającymi się błędami
• testowanie aplikacji
• dokumentacja. stworzenie dokumentu, który jest instrukcją i opisem nt. tworzonej aplikacji

Czas

W praktyce ciężko dokładnie określić ile zajmie stworzenie aplikacji szytej na miarę i jest to bardziej szacowanie. Jednak im bardziej powtarzalny problem do rozwiązania tym łatwiej jest celniej to określić.

Czas, który zajmie aplikacja zależy jest od:

• komunikacji i organizacji projektowej
• developmentu
• pracą nad infrastrukturą

w obu powyższych wpływa na to: ilość i złożoności wymagań od systemu, ilości User Stories, rodzaju użytkowników i ich wzajemnej relacji ze sobą

• utrzymanie aplikacji: ilość powstałych błędów, czas potrzebny na optymalizowania działania i wydajność aplikacji

W praktyce szacując czas warto rozbić każdy z elementów na mniejsze części. Po wydzieleniu i rozbiciu wszystkich wymagań na małe, jednostkowe problemy łatwiej jest oszacować. Wszystko jest zależne od wielkości projektu.

Koszt

Koszt aplikacji zależny jest od:

• stawki godzinowej specjalisty wykonującego projekt. Może to być deweloper, designer, architekt, analityk.
• złożoności i unikalności rozwiązywanego problemu
• ilości wzajemnych relacji w systemie tj. user stories, funkcjonalności i aktorów w systemie
• złożoności infrastruktury czyli potrzebie zaprojektowania infrastruktury, która spełnia założenia biznesowe w aplikacji
• specyfiki zadania
• wartości i wielkości projektu. Im większy jest projekt całościowo tym więcej zasobów i kosztów on poniesie
• priorytet i pilność projektu. Praca w presji różni się od spokojnej pracy i czasu. Im wyższy priorytet tym koszt może być wyższy.

Typowe zadania i rozwiązania (np. strona internetowa albo prosta aplikacja) są przeważnie łatwiejsze do zrealizowania i jest więcej osób, które mogą je zrealizować.

Specyficzne zadania wymagają z kolei pracy eksperckiej i użycia konkretnych technologii.

Na konkretną technologię i umiejętność potrzebny jest specjalista/ekspert w danej technologii. O finalnym koszcie decyduje więc rynek: popyt i podaż ekspertów na dane zadanie.

Im bardziej złożoność aplikacji webowej czy systemu rośnie tym większy jest całkowity koszt.

Development

Teraz wiemy co konkretnie chcemy zbudować, jaki będzie ruch, jacy użytkownicy i jakie funkcjonalności konkretny użytkownik będzie wykonywał. Czas zbudować aplikację!

Wybór narzędzi

Narzędzia zwane też często technologią są wybierane do budowy systemu. W praktyce wyobraź sobie, że tworzenie aplikacji to tworzenie działającego systemu spośród wielu dostępnych klocków i sprawianie, że w całości spełniają wymaganie i potrzebę biznesową.

Grałeś w Lego ? to takie Lego w świecie informatyki. Świetna zabawa gwarantowana 🙂

Na co zwrócić uwagę wybierając narzędzia ?

Narzędzi jest mnóstwo i codziennie dochodzą nowe. Sztuka jest dobrać odpowiednie narzędzia do problemu.

Wybierając narzędzia należy zwrócić uwagę na:

• korzystny stosunek jakości działania do kosztów
• czy spełniają nasze oczekiwania i wymagania biznesowe
• stabilność narzędzi czyli pewność, że narzędzie będzie długoterminowo rozwijane. dobrze tutaj zwrócić uwagę na Social Media tj. zespół tworzący (linkedIn) w przypadku produktu, albo profil na GitHub w przypadku biblioteki (wtyczki) programistycznej
• czy łatwo się z nimi integrować np. poprzez łatwe i rozbudowane API
• czy koszt jest w zakresie naszego budżetu

No Code, Low Code czy Full Code ?

No Code to podejście, z których korzystamy przez interfejs graficzny / API i kod, który jest pod spodem jest “opakowany” w przyjazne komponenty np. Drag & Drop

Low Code to podejście, których można używać minimalnie używając kodu

Full Code to podejście, w którym posługujemy się kodem i programujemy aplikację. W praktyce większości współczesnych frameworkom(szablonom) bliżej do podejście Low Code. Chyba, że tworzymy bardzo specyficzną aplikację, którą nie da się ubrać w żadne ramy i użyć szablonu (framework)

Wybór narzędzia

W praktyce wybór narzędzia zależy od wymagań i funkcjonalności przyszłej aplikacji.

Kombinacji i możliwości użycia narzędzi jest nieskończoność. Można łączyć ze sobą tylko aplikacje NoCode, można używać Full Code we wsparciu z No Code, można używać głównie No Code ze wsparciem małego skryptu (tzw. funkcja).

Wybór narzędzia jest zadaniem autora rozwiązania (full code deweloper, no code deweloper).

Przegląd narzędzi programistycznych

Narzędzia do tworzenia logiki i backend’u używając kodu

Narzędzia do frontend’u używając kodu

Frontend tworzy się w języku Javascript (przeważnie) korzystając z różnych frameworków tj.:

React.js, Angular, Vue.js, Ember.js, Svelt, next.js, gatsby.js i setki innych

Bazy danych

Bazy danych, uwaga… przechowują dane! Możemy wybrać wiele różnych technologii bazodanowych.

Główny podział to bazy relacyjne (SQL) i nierelacyjne (NoSQL). Jest więcej rodzajów, jednak nie będziemy wchodzić w szczegóły i różnice między tymi technologiami bazami danych.

Wystarczy, że będziesz wiedział, że w większości narzędzi, z których na co dzień korzystamy są opakowane w przyjazne interfejsy, które umożliwiają wyświetlanie, dodawanie, edytowanie, usuwanie danych.

Każda aplikacja webowa z założenia łączy się z bazą danych i operuje na danych, które w tej bazie przechowujemy.

Przegląd narzędzi No Code

Z aplikacjami No Code jest trochę inaczej niż z Full Code.

Różni się to tym, że narzędzia No Code przeważnie realizują jedną funkcjonalność, a system możemy zbudować łącząc ze sobą kilka narzędzi w jedno dzięki intefrejsom API.

Podział aplikacji nocode ze względu na zastosowanie:

Integratory: Make.com, zapier.com, ifttt.com, n8n.io

Bazy danych: Airtable.com,

Formularze: Tally.so, typeform.com,

Strony internetowe: Webflow.io, card.co, framer.com

Aplikacje webowe: bubble.io, softr.io, bildr.io

Aplikacje mobilne: flutterflow.io, adalo.com, glideapps.com,

Narzędzia internal: retool.com

System mailowe transakcyjne: sendgrid.com,

Systemy mailowe marketingowe: mailerlite.com

… i tysiące innych

Infrastruktura aplikacji fullcode

Aplikacje, które powstały przy użyciu kodu zazwyczaj są uruchomione na: serwerze fizycznych, prywatnym, w chmurze.

W ramach danej infrastruktury aplikacja łączy się z bazą danych i innymi serwisami, którze w całości tworzą system.

Infrastruktura aplikacji nocode

Każde z narzędzi nocode jest zbudowane na jakiejś infrastrukturze. Bez tego nie mielibyśmy dostępu i możliwości użycia. Jednak do użytku jest to na innym poziomie abstrakcji, tak, aby ułatwić korzystanie końcowemu użytkownikowi.

Także w przypadku No Code powiemy o “wysoko poziomowej” infrastrukturze nie wchodząc w szczegóły na czym oparta jest dana infrastruktura konkretnego narzędzia.

W przypadku tworzenia aplikacji w No Code głównym punktem interakcji jest jedno z: strona internetowa, aplikacja webowa albo aplikacja mobilna.

W wyniku interakcji użytkownika z aplikacją dzieją się różne akcje, które możemy integrować:

• z wbudowanym workflow(lista kroków/procedura po stronie platformy np. Bubble ) w ramach tej platformy. Jest to wystarczające gdy funkcje oferowane przez daną platforme NoCode są wystarczające. Wtedy nie potrzebujemy integrować się z innymi narzędziami, bo jedna platforma nam wystarcza.
• z integracja z innymi narzędziami dzięki integratorom tj. make.com albo zapier.com. Wówczas aplikacja (np. Bubble) komunikuje się z zewnętrznym systemem (np. mailowym albo płatnościami) za pomocą integratorów (np. Make.com) dzięki intefrejsowi API (z odpowiednią autoryzacją). Wówczas możemy ułożyć dowolny workflow, który spełnia oczekiwania biznesowe

Tworzenie aplikacji

Zatem jak w praktyce wygląda tworzenie aplikacji ? Składa się z kilku kroków

Backend:

Backend to to co dzieje się ”od kuchni”. Na backend przeważnie składają się aspekty tj.:

1. Baza danych

Podstawą każdego systemu i aplikacji są dane. dane przechowujemy w bazie danych.

Zatem potrzebne będzie dobre zaprojektowanie bazy danych i relacji tych danych ze sobą.

Tworzymy więc modele z danymi atrybutami np. Użytkownik(imię, nazwisko, płeć).

Na podstawie modeli tworzymy obiekty (np. Rafał Dołęga mężczyzna)

Obiekty przechowujemy w tabelach. (np. użytkownicy naszej aplikacji)

Dobrze zaprojektowana baza danych ułatwia trzymanie danych i pracę na nich

2. Logika biznesowa

Znając funkcjonalności, które nasza aplikacja ma realizować możemy ułożyć procedurę, która załatwia jakiś konkretny problem biznesowy.

W skrócie jest to nic innego jak rozpoczęcie procedury (trigger), wzięcie danych z bazy danych i podjęcie jakiegoś działania z tymi danymi.

W praktyce zależy to od potrzeby biznesowej jednak przybliżam tu ogólny sposób działania.

3. Integracje

Aplikacja może integrować się z zewnętrznymi usługami i narzędziami aby realizować jakieś założenia.

Np. zamiast pisać system mailingowy od początku możemy stworzyć integrację, w której możemy “oddać odpowiedzialność” za wysłanie emaila temu systemowi.

Nasz system mówi jedynie do systemu mailingowego

wyślij wiadomość do “xyz” o danej treści

system mailingowy może potwierdzić, że otrzymał to zadanie, co z kolei możemy zapisać w naszym systemie

Frontend:

Frontend to to co widzisz na interfejsie użytkownika np. w przeglądarce albo aplikacji mobilnej.

Frontend składa się z szaty strony (pliki HTML), stylów (CSS) i skryptów (JS). Strony które się wyświetlają pobierają dane z backendu oraz zapisują dane do backendu.

Na frontend przeważnie składają się aspekty tj.:

1. Interfejs użytkownika: projektowanie strony/Widoków i

Widoki to rodzaj strony, w której użytkownik wchodzi w interakcję i podejmuje jakieś działanie.

Typowe rodzaje widoków to:

1. Widok logowania, rejestracji, zmiany hasła
2. Widok listy danych obiektów
3. Widok szczegółowy danego obiektu
4. Strona home dashboard
5. Formularz do dodawania, edycji
6. Multi formularz
7. Popup
8. I wiele, wiele innych (w rzeczywistości zależy to od wymagań aplikacji webowych)

Widoki budowane są z komponentów m.in pole tekstowe, pole formularza, text, grafika, przyciski, alerty, komunikaty, menu i wiele innych

2. UX - user experience

Jest to doświadczenie użytkownika w korzystaniu z aplikacji. Jest to oddzielna dziedzina tworzenia interfejsów.

Wystarczy jednak, że będziesz wiedział, że zależy tutaj na intuicyjnym i przejrzystym interfejsie, który jest łatwy do użycia przez końcowego użytkownika.

3. Design - na design wpływa połączenie kolorystyki, czcionek, stylów i brandbook’a.

Ma to większe znaczenie dla aplikacji produktowych, w których prezentujemy spójny styl i komunikację na zewnątrz. Obejmuje to wspólny i jednolity styl dla aplikacji, strony internetowej, emaili, grafik, banerów czy komunikacji w Social Media.

Integracja frontend ↔ backend

Frontend komunikuje się z backendem za pomocą API albo zaczytywania szablonu HTML.

W skrócie Frontend wysyła zapytanie o konkretne dane do Backend’u za pomocą API. Backend zwraca te dane po czym Frontend wyświetla je dla użytkownika.

W momencie interakcji użytkownika ze stroną i np. kliknięcie przycisku “Wyślij”. Frontend wysyła do Backendu informację “Użytkownik xyz wysłał takie o to dane więc zapisz je w bazie danych”

Bezpieczeństwo

Współczesne frameworki dbają o dobre zabezpieczenia danych osobowych np. haseł. Jak również aplikacje webowe są “nakładką” na bazę danych i użytkownik nie ma bezpośredniego dostępu do bazy danych.

Jednak tworząc system trzeba zadbać o zabezpieczenie z poziomu konfiguracji aplikacji i danych, które udostępniamy za pomocą API oraz zabezpieczyć sposób w jaki użytkownik wchodzi w interakcję z aplikacją.

Główne aspekty, na które należy zwrócić uwagę to:

• brak walidacji danych wejściowych w formularzach aplikacji
• zarządzanie sesją i uwierzytelnianiem, aby np. atakujący nie mógł przejąć sesji użytkownika w aplikacji. innym przykładem jest to, żeby sesja wygasała, a nie trwała w nieskończoność.
• zarządzanie uprawnieniami i rolami, aby system nadawał odpowiednie uprawnienia odpowiednim grupom.
• niezabezpieczona komunikacja (http vs https), aby atakujący nie mógł przechwycić danych wrażliwych
• konfiguracja środowiska, aby użytkownik nie mógł “wejść do aplikacji” “od kuchni” albo co gorsze uzyskać dostęp do serwera, na którym dana aplikacja jest uruchomiona
• nieaktualizowanie oprogramowania i bibliotek, aby mieć pewność, że aktualne oprogramowanie i biblioteki są wspierane, a więc zapewniają najnowsze sposoby zabezpieczenia

Testy

Po skończonym kamieniu milowym aplikacji aplikację trzeba przetestować.

Testowanie to niezbędny etap zanim aplikacja może zostać uruchomiona na środowisku produkcyjnym i obsłużyć realnych użytkowników.

Są różne sposoby testowania aplikacji na wielu różnych poziomach.

1. jednostkowe: testujemy jeden rodzaj komponentu, jedną funkcjonalność w jednym czasie
2. integracyjne: różne komponenty aplikacji zintegrowane ze sobą działają prawidłowo
3. systemowe: całościowo działa poprawnie, spełnia oczekiwania klienta
4. akceptacyjne: aplikacja spełnia oczekiwania i wymagania biznesowe ustalone na początku tworzenia aplikacji
5. wydajnościowe: aplikacja jest przetestowana w obliczu zwiększonego ruchu na stronie uzyskując pewność, że jest w stanie obsłużyć taką ilość ruchu na środowisku produkcyjnym
6. bezpieczeństwa: testujemy czy aplikacja jest zabezpieczona przed atakami i czy dane są bezpieczne. testujemy zarówno aplikację jak i infrastrukturę jeśli sami ją tworzyliśmy.

Wykryte błędy należy zgłosić programiście w odpowiedni sposób wykorzystując np. tablicę zadań ze zgłoszeniami błędów oraz priorytetem wykonania.

Wdrożenie aplikacji

jest dostępna dla użytkowników

zadbanie o proces wdrożenia

• technicznie: automatyzacje, rzeczy do zadbania,
• biznesowo: poinformowanie użytkowników o zmianach,

Dokumentacja

Proces późniejszego wdrażania

Proces utrzymania

Proces rozwoju oprogramowania

Komunikacja przy tworzeniu aplikacji

QA

• Strona vs aplikacja

Prosta strona to głównie prezentowanie danych. Strona nie ma interakcji i służy głównie w celu informacji, zostawienia danych kontaktowych. Np. landing page, wizytówka, home, portfolio

Strony informacyjne - Są to proste strony internetowe, które służą głównie do prezentacji informacji. Ich celem jest dostarczenie użytkownikom informacji o firmie, produktach lub usługach, a nie interakcja z użytkownikami.

Słownik

• No Code
• Low Code
• Full Code
• Aplikacja vs strona vs system vs infrastruktura
• Framework
• Widok aplikacji
• Aktor systemu
• Interesariusz systemu