Kiedy myślimy o tworzeniu oprogramowania, wielu z nas wyobraża sobie zespół programistów, którzy siedzą przy komputerach i po prostu “piszą kod”. W rzeczywistości zanim powstanie pierwsza linijka kodu – dzieje się bardzo wiele, a samo fizyczne “kodowanie” to tylko mały fragment pracy.
Profesjonalne wytwarzanie oprogramowania to przede wszystkim proces. Powtarzalny, przemyślany i zaplanowany tak, by ograniczać ryzyko i dostarczać odbiorcy programu realną korzyść. Podobnie jak przy budowie domu: najpierw trzeba dobrze zrozumieć, czego potrzebuje zamawiający, potem przygotować i zatwierdzić projekt architektoniczny, następnie zaś przejść do budowania. Zbudowany program jest następnie odbierany i oddawany do użytku, po czym zaczyna się faza jego utrzymania (czyli cyklicznych aktualizacji, rozwoju i napraw serwisowych).
1. Zrozumienie i udokumentowanie potrzeb
Profesjonalny proces tworzenia dedykowanego oprogramowania zaczyna się nie od technologii, lecz od rozmowy i słuchania. Ten etap nazywa się analizą wymagań. W praktyce oznacza dokładne zbadanie przez zespół realizujący projekt: co dany system ma robić, dla kogo, w jakich sytuacjach i po co. Brzmi to prosto, ale jest to często najtrudniejsza część całego przedsięwzięcia. Klient zwykle wie, jaki ma problem, ale niekoniecznie potrafi go opisać w sposób, który da się bezpośrednio przełożyć na działający program. Zadaniem zespołu projektowego jest zadawanie właściwych pytań: co dokładnie chcemy osiągnąć? Jak obecnie wygląda ten proces? Kto będzie z programu korzystał? Które funkcje programu są niezbędne, a które jedynie mile widziane (ang. “nice to have-s”).
Dobrą ilustracją jest tu klasyczna anegdota: klient prosi o “szybszego konia”, podczas gdy w rzeczywistości najlepszym rozwiązaniem może okazać się np. telefon, który pozwoli szybciej przekazywać informacje z miejsca na miejsce. Rolą analityka nie jest bezmyślne spełnianie każdego życzenia klienta, lecz dotarcie do prawdziwej potrzeby, która się za nim kryje. Często najcenniejsze, co można zrobić dla klienta, to zaproponować rozwiązanie, o którym klient sam nie pomyślał.
Efektem tego etapu w procesie tworzenia dedykowanego oprogramowania najczęściej jest dokument opisujący to, co dokładnie ma powstać. Dokument taki może zawierać np. listę funkcji, projekty graficzne poszczególnych ekranów aplikacji czy też tak zwane “historie użytkowników” (ang. “user stories”). To krótkie opisy typu “jako klient chcę móc anulować zamówienie, aby odzyskać pieniądze za produkt, którego już nie potrzebuję”. Nieważne, jaką formę to przyjmie; ważne, by obie strony – zamawiający i wykonawca oprogramowania – rozumiały dokładnie tak samo, co jest celem przedsięwzięcia.
Ten etap jest kluczowy dla sukcesu całego projektu. Koszt poprawiania nieporozumień lub niedomówień powstałych w fazie analizy rośnie lawinowo wraz z postępem prac technicznych. Zmiana ustalenia na etapie wstępnej rozmowy kosztuje tyle, ile zmiana kilku zdań w dokumentacji. Ta sama zmiana wprowadzona, gdy system jest już budowany, może oznaczać tygodnie pracy i przeróbkę wielu elementów technicznych i realne pieniądze. Podobnie jak w przypadku budowy domu: przesunięcie ściany na projekcie to kilka kresek ołówkiem; przesunięcie jej, gdy dom już stoi, to wyburzanie i budowanie od nowa.
2. Projektowanie
Gdy wiadomo już co dokładnie ma powstać, przychodzi czas na decyzję jak to zbudować. To etap projektowania. Decyzje podejmowane na tym etapie są wyjątkowo ważne, ponieważ będą wpływać na wszystko co wydarzy się później. Dobry projekt sprawi, że system będzie działał sprawnie, przez lata i będzie dało się go łatwo rozwijać. Zły projekt zaś może doprowadzić do sytuacji w której nawet drobne zmiany staną się ogromnym wyzwaniem.
Poniżej opisane zostały najważniejsze elementy, które składają się na ten etap.
2.1. Projektowanie interfejsu użytkownika oraz UX
Jednym z najważniejszych elementów projektowania oprogramowania jest projektowanie tzw. interfejsu użytkownika (ang. “user interface”). Dobrze zaprojektowany interfejs użytkownika sprawia, że korzystanie z systemu jest przyjemne i intuicyjne. Użytkownik nie musi się zastanawiać, gdzie kliknąć i co zrobić dalej, lecz płynnie osiąga swój cel w każdym z modułów lub funkcjonalności aplikacji. To także projektowanie ścieżek: jak wygląda cały proces od wejścia w moduł zamówień, przez wybór produktów i sfinalizowania zakupu: ile kroków wymaga, gdzie użytkownik może się zgubić, itp. Ten szerszy kontekst projektowania – nie tylko ułożenia przycisków i formularzy na ekranie – często nazywa się projektowaniem UX czyli projektowaniem doświadczeń użytkownika z aplikacją (“user experience design”). To niezwykle ważny aspekt projektowania oprogramowania i obecnie właśnie od niego zaczyna się pracę nad nowym programem. Poszczególne ekrany i ścieżki łatwo skonsultować z zamawiającym oraz realnymi odbiorcami programu, pozwala to wychwycić wiele błędów na wczesnym etapie. W końcu nawet najlepiej zbudowany “silnik oprogramowania” na nic się nie zda, jeśli jego obsługa będzie myląca lub niewygodna.
2.2. Architektura systemu i schemat bazy danych
Sercem większości systemów informatycznych są dane. Produkty, zamówienia, faktury, dane odbiorców, wiadomości, historia płatności – to wszystko trzeba gdzieś przechowywać w sposób uporządkowany, tak by dało się szybko odnaleźć właściwą informację i mieć pewność, że jest ona spójna. Do tego służy baza danych, a sposób jej zaprojektowania (tak zwany schemat bazy danych) będzie miał wpływ na sposób działania całego systemu. Zaprojektowanie tzw. struktury tabel i relacji między nimi to jedna z najważniejszych decyzji w całym projekcie. Dobrze przemyślana struktura sprawia, że system działał będzie sprawnie i przewidywalnie nawet po wielu latach i przy milionach rekordów. Struktura przygotowana naprędce, bez głębszej analizy i bez próby przewidzenia kierunków rozwoju systemu, sprawi że dane zamienią się z czasem w plątaninę, z której trudno będzie wygodnie korzystać i wprowadzać kolejne modyfikacje. Architektura systemu to pojęcie szersze niż sama baza danych – to ogólny plan tego, z jakich technologii i części będzie się składał system oraz tego jak te części będą ze sobą współpracować.
2.3. API i integracje
Współczesne oprogramowanie rzadko jest “samotną wyspą”. Zwykle składa się z wielu części, które muszą się między sobą porozumiewać, a często musi też współpracować z zupełnie odrębnymi systemami np. płatnościami online, systemami firm kurierskich, księgowymi, itp. Do tego, by te systemy mogły się między sobą komunikować służą tzw. API. API to coś co program może (nie musi) oferować odbiorcom. Najprostsza metafora: API to trochę jak kelner w restauracji. Składamy zamówienie kelnerowi, który zna dokładnie zasady: co można zamówić, w jakiej formie i czego się spodziewać w odpowiedzi. Kelner przekazuje zamówienie do kuchni i przynosi gotowe danie. API działa dokładnie tak samo: to umówiony, ściśle określony sposób, w jaki jeden program prosi drugi o wykonanie czegoś lub o udostępnienie informacji, nie musząc wiedzieć, co dzieje się “w kuchni” po drugiej stronie. Dzięki temu różne systemy (często napisane w zupełnie różnych technologiach) mogą się ze sobą komunikować. Analiza tego, z jakimi systemami trzeba się połączyć i jak dokładnie ma wyglądać ta wymiana informacji, to istotna część etapu projektowania oprogramowania. Dobrze zaprojektowane integracje oraz własne API systemu sprawią, że rozwój systemu w przyszłości będzie szybszy i stabilniejszy.
2.4. Komponenty i usługi zewnętrzne
Jedną z ważniejszych decyzji na etapie projektowania jest odpowiedź na pytanie: czy dany element systemu zbudować samodzielnie, czy skorzystać z gotowego rozwiązania dostępnego na rynku? W świecie software’u istnieje ogromna liczba wyspecjalizowanych usług, nazywanych często usługami SaaS (czyli “oprogramowanie jako usługa”) lub usługami chmurowymi (ang. “cloud services”), które za opłatą zrobią dokładnie tę rzecz, której nasz program potrzebuje. Np. prawie każdy system musi wysyłać e-maile – powiadomienia, potwierdzenia, przypomnienia. Można próbować zbudować własny mechanizm ich wysyłki, ale wiąże się to z ogromem pracy i szczegółów technicznych. Tymczasem na rynku istnieją wyspecjalizowane usługi i oferują gotową funkcjonalność za ułamek kosztu samodzielnej budowy takiego rozwiązania. Podobnie jest z wysyłką SMS-ów czy np. obsługą płatności online. Często znacznie rozsądniej jest skorzystać z zaufanego, wyspecjalizowanego dostawcy, niż próbować budować wszystko samemu od zera. Decyzja “budować czy kupić” sprowadza się do analizy kilku aspektów m.in. celów strategicznych firmy, kosztów, czasu i aspektów szeroko rozumianego bezpieczeństwa. Budowanie od zera daje pełną kontrolę, ale kosztuje czas i pieniądze, a odpowiedzialność za jakość i bezpieczeństwo spoczywa w całości na nas. Korzystanie z gotowych usług pozwala szybciej zbudować system, obniża koszty i przerzuca część odpowiedzialności na wyspecjalizowanego partnera. Odbywa się to jednak kosztem pewnej zależności od niego. Profesjonalny zespół nie buduje wszystkiego od podstaw, buduje samodzielnie to, co stanowi o wyjątkowości produktu, a resztę składa z dobrze dobranych, gotowych elementów. To trochę jak przy budowie domu – nikt rozsądny nie produkuje własnych cegieł ani nie projektuje od nowa pieca, kupuje sprawdzone komponenty i skupia energię na tym, co ma uczynić budowany dom naprawdę wyjątkowym.
3. Prace techniczne
Dopiero wtedy gdy wiadomo już, co i jak ma powstać, zaczyna się to, co potocznie kojarzymy z “tworzeniem oprogramowania” – czyli fizyczne programowanie. Współczesne wytwarzanie oprogramowania to jednak przede wszystkim praca zespołowa, a sposób jej organizacji jest równie ważny, jak sama umiejętność pisania kodu. W firmach zajmujących się profesjonalnym tworzeniem oprogramowania dla biznesu dominuje obecnie tzw. “podejście zwinne” (ang. “agile”). Jedną z jego najpopularniejszych odmian jest tzw. “Scrum”. Istota tego podejścia do pracy jest prosta i zdroworozsądkowa: zamiast budować całość programu naraz przez wiele miesięcy, pracuje się w krótkich cyklach – zwykle jedno- lub dwutygodniowych – podczas których powstaje działający, niewielki, fragment oprogramowania. Ten fragment można pokazać, sprawdzić, przetestować z prawdziwymi użytkownikami i na tej podstawie zdecydować, co robić dalej. Zaletą takiego podejścia jest to, że błędy i nieporozumienia wychodzą na jaw szybko, a nie np. po roku pracy. Klient zamawiający dany program regularnie widzi postępy i może na bieżąco korygować kierunek. Zespół uczy się i dostosowuje w trakcie, zamiast trzymać się kurczowo planu, który mógł się zdezaktualizować.
Pracując w metodyce zwinnej najczęściej bazuje się na liście zadań do wykonania, uporządkowanej według ważności. Na początku każdego cyklu pracy (ang. “sprint”) zespół wybiera z listy tyle, ile realnie jest w stanie zrobić, i skupia się na dostarczeniu tego w działającej postaci. Krótkie, codzienne spotkania zespołowe pozwalają wszystkim wiedzieć, kto nad czym pracuje. Na końcu cyklu zaś zespół pokazuje efekty pracy i wspólnie zastanawia się, co poszło dobrze, a co można usprawnić następnym razem. Ta regularna “refleksja nad własną pracą” to jeden z fundamentów podejścia zwinnego.
W celu zapewnienia odpowiedniej jakości powstającego kodu używa się tzw. “przeglądów kodu” (ang. “code review”). Polega to na tym, że gdy programista skończy tworzyć jakiś fragment kodu, zanim zostanie on włączony do kodu źródłowego całego programu, jest on najpierw sprawdzany pod względem technicznym przez innego członka zespołu. Taki przegląd daje kilka korzyści m.in. pozwala wychwytywać błędy i niedopatrzenia, zanim staną się problemem. Ponadto więcej niż jedna osoba rozumie, jak działa dany fragment systemu. Pomaga także zachować spójność i porządek w kodzie źródłowym całego systemu. Jest to inwestycja, która procentuje przez cały okres życia systemu. Dobrze ustrukturyzowany, czytelny kod źródłowy sprawia, że program łatwiej będzie w przyszłości serwisować i rozbudowywać.
4. Testowanie i zapewnienie jakości
Wiele osób sądzi, że testowanie oprogramowania to “sprawdzenie na końcu, czy wszystko działa”. W profesjonalnym procesie wytwórczym jest zupełnie inaczej: testowanie to osobna, poważna dyscyplina, która towarzyszy pisaniu kodu przez cały czas. Podstawowa zasada brzmi: im wcześniej wykryjemy błąd, tym taniej go naprawimy. Błąd znaleziony przez programistę w chwili pisania kosztuje minuty. Ten sam błąd znaleziony przez klienta po wdrożeniu może kosztować utraconą reputację, pieniądze, a czasem coś znacznie poważniejszego.
Istnieje wiele rodzajów testów oprogramowania, jednak co najważniejsze w profesjonalnym procesie wytwórczym “testowanie” odbywa się również poprzez programowanie. To znaczy tworzone są specjalne, automatyczne testy, które uruchamiają i testują działanie programu. Część z tych testów sprawdza pojedyncze, najmniejsze elementy systemu tzn. to czy dana funkcja działa poprawnie. Inne sprawdzają, czy różne elementy dobrze współpracują ze sobą po połączeniu, bo bywa, że każda część z osobna działa, a razem już niekoniecznie. Jeszcze inne testy sprawdzają cały system z perspektywy użytkownika, przechodząc przez typowe scenariusze użycia od początku do końca, jak gdyby klient sam je wykonywał. Dzięki temu, że stosuje się testy zautomatyzowane, raz przygotowane testy mogą być wykorzystane wielokrotnie, np. do powtórnej weryfikacji gdy coś w systemie się zmienia. Jest to bardzo ważne z perspektywy zapewnienia stabilności działania oprogramowania.
5. Wdrożenie i utrzymanie
Gdy program jest gotowy i przetestowany, następuje wdrożenie i udostępnienie go użytkownikom. Często ta faza poprzedzona jest szkoleniami personelu lub finalnymi “beta testami”. Jednak najważniejsze w tej fazie jest zrozumienie, że moment uruchomienia programu to nie koniec, lecz początek jego cyklu życia.
Działający system trzeba monitorować, by wychwytywać ewentualne błędy lub problemy. Trzeba go aktualizować i rozwijać w odpowiedzi na zmieniające się potrzeby biznesu oraz użytkowników. Trzeba także dbać o jego bezpieczeństwo, bo zagrożenia nieustannie ewoluują. Każde poważne oprogramowanie, z którego korzystamy na co dzień, jest w rzeczywistości nieustannie doskonalone, choć zwykle tego nie widzimy. Wracając do analogii domu, na działający program należy patrzeć bardziej jak na “żywy organizm” wymagający opieki, niż na raz postawiony i zapomniany budynek.
Podsumowanie
Profesjonalne wytwarzanie oprogramowania nie sprowadza się do zręcznego napisania jego kodu, stanowi raczej uporządkowany i przewidywalny proces, którego celem jest ograniczanie ryzyka i dostarczanie realnej wartości.
Wszystko zaczyna się od dokładnego zrozumienia i udokumentowania potrzeb. Następnie przez staranne zaprojektowanie fundamentów (m.in. struktur danych, sposobu komunikacji między systemami i rozsądnych decyzji o tym, co zbudować, a co kupić). Dopiero potem przychodzi czas na realizację, za którą stoi zgrany zespół, pracujący małymi krokami i dbający na każdym kroku o jakość. Testowanie towarzyszy pracy przez cały czas i ma charakter zautomatyzowany, specjalne testy uruchamiane automatycznie weryfikują przygotowywane oprogramowanie i jego prawidłową pracę.
Gdy z wdrożonego programu zaczynają korzystać użytkownicy – program zaczyna żyć. Jednak nie oznacza to końca wydatków z nim związanych. Pojawiają się koszty związane m.in. z utrzymaniem serwerów, usług chmurowych, zapewnienia wsparcia technicznego, cyklicznych przeglądów, itp. Ilość i wysokość tych wydatków może być zaskoczeniem. Dlatego gdy firma staje przed wyzwaniem zbudowania własnej aplikacji web czy też systemu, warto rozważyć skorzystanie z usług wyspecjalizowanych podmiotów takich jak www.aplikacjeweb.pl, dostarczających dedykowane aplikacje biznesowe w formie elastycznych usług, płatnych abonamentowo. Dzięki temu firma może zyskać działający program, dostosowany do jej specyficznych potrzeb, szybciej i taniej.
Niezależnie od wybranej drogi, znajomość profesjonalnego procesu wytwórczego pozwala świadomie rozmawiać z zespołem, który tworzy dla nas oprogramowanie – zadawać właściwe pytania, rozumieć, dlaczego pewne etapy zajmują tyle czasu, i odróżnić rzetelne podejście od chodzenia na skróty. Wiele z opisanych tu zasad dotyczących wytwarzania oprogramowania to po prostu zdrowy rozsądek, który znamy z zupełnie innych dziedzin życia (np. budownictwa). I to jest chyba najważniejszy wniosek: świat tworzenia oprogramowania, mimo swojej technicznej otoczki, rządzi się logiką znacznie bliższą naszej codziennej intuicji, niż mogłoby się na pierwszy rzut oka wydawać.
Artykuł sponsorowany.
