Autor: Przemek

Zbliżamy się do końca tworzenia naszego projektu internetowego. Jest to dla nas długo wyczekiwany moment, często trwający wiele miesięcy. Jest to moment finalnego rozliczenia projektu z firmą IT, więc organizujemy z naszej strony zasoby, do przetestowania produktu. Autorzy projektów również mocno testują produkt, aby proces odbiorów przeszedł jak najsprawniej.

Po jakimś czasie chcemy rozwinąć projekt o drobne funkcjonalności, z założenia mało istotne jednak usprawniające prace. Nie jest to duże zlecenie, trwające około tygodnia czasu pracy programisty. W tym momencie nie angażujemy już dużych sił do testowania całego serwisu, testujemy jedynie nowo utworzone funkcjonalności. Jest to błędem, ponieważ nowe funkcjonalności mogą uszkodzić stare.

Rozwój aplikacji internetowej wpływa na jej funkcjonowanie

Załóżmy, że posiadamy na stronie moduł przelicznika Walut. Działa on prawidłowo 1 EUR = 4.27 PLN. W kodzie serwisu znajduje się odpowiedni mechanizm przeliczania walut. Jako rozwój naszego projektu mamy zadnie utworzyć moduł wystawiania faktur dla klientów zagranicznych.

Programista wziął pod uwagę, że istnieje już odpowiednia funkcjonalność przelicznika walut, więc ją wykorzystał. Przy odbiorze okazało się jednak, że powinniśmy zaokrąglać przeliczone ceny do pełnych złotówek. Zmiana wydawała się bardzo prosta do wprowadzenia, więc programista zmodyfikował kod mechanizmu przeliczania walut, aby zaokrąglał wartości do liczb całkowitych. Wszyscy przetestowali działanie modułu faktur i projekt został odebrany.

Po pewnym czasie klienci zaczęli nam zgłaszać, że w kalkulatorze walutowym 1 EUR = 4 PLN, wynikło to z modyfikacji zaokrąglania walut do faktur.

Jak sobie radzić z rozwojem aplikacji i unikaniem powstawania nowych błędów?

Rozwiązaniem tego problemu jest stworzenie testów automatycznych, które przy każdej modyfikacji systemu będą uruchamiana i zweryfikują czy całość funkcjonalności, które działały poprzednio funkcjonują również teraz.

Testy automatyczne dzielą się na dwa rodzaje:

• testy kodu źródłowego – testują wszystkie funkcjonalności, które dzieją się po stronie serwera
• testy przeglądarkowe – testują funkcjonalności, które widzimy na ekranie przeglądarki

Odwołując się do naszego przykładu, posiadając testy automatyczne programista od razu wiedziałby, że popełnił błąd, ponieważ zakładanie działanie przelicznika walut różni się od obecnego.

Testy automatyczne dają nam pewność, że aplikacja będzie działała w każdym swoim momencie. Są one szczególnie ważne przy aplikacjach, które są intensywnie rozwijane, szczególnie polecam to startupom, których wizja produktu zmienia się bardzo dynamicznie. Minusem wdrożenia testów automatycznych są koszty, które mogą wynosić nawet 30% wartości całego projektu, jednak prędzej czy później zdamy sobie sprawę z faktu, że są one niezbędne do prawidłowego funkcjonowania aplikacji.

W poprzednim wpisie rozpoczęliśmy cykl na temat dokumentacji projektów IT. Wiemy, dlaczego powinniśmy stworzyć dokumentację przed rozpoczęciem prac produkcyjnych. Jednak jak taka dokumentacja powinna wyglądać? Dokumentacje dużych systemów IT potrafią być bardzo rozbudowane, wykorzystując różne metodyki opisywania danych zagadnień jak np. UML – jest to jednak temat na nie małą książkę, dlatego skupmy się na podstawowych elementach, jakie powinny znaleźć się w dokumentacji.

Określenie docelowego ruchu w serwisie internetowym

Pierwszym pytaniem, jakie zadajemy klientowi podczas projektowanie systemu IT jest wielkość ruchu, jaka będzie obsługiwana przez serwis. Oczywiście ciężko jest z góry założyć precyzyjne liczby, jednak rząd wielkości definiuje od początku technologie, jakie powinniśmy użyć do budowy systemu, co bezpośrednio przekłada się na koszty budowy serwisu internetowego.

Ruch na małym serwisie internetowym

Dla przykładu wyobraźmy sobie, że potrzebujemy systemu rezerwacyjnego, jakiejś niszowej usługi np. rezerwacje sal konferencyjnych w Polsce. Użytkownik może tylko wyszukiwać i rezerwować sale, zakładamy, że nie ma na w tym serwisie żadnych dodatkowych treści. Takich sal nie jest zbyt wiele, załóżmy, że jest ich 10000. Ta liczba mniej więcej jest nam w stanie zobrazować, jaki maksymalny ruch dzienny jesteśmy w stanie wygenerować. Zakładając, że każda sala jest zarezerwowana w każdym dniu oraz że zdobędziemy 50% rynku możemy, a każda saka nam wygeneruje współczynnik odsłon na poziome 5 stron maksymalne obciążenie możemy określić na poziomie 25000 odsłon dziennie.

Jest to stosunkowo mała ilość i spokojnie możemy zrealizować taki projekt używając technologii PHP + MySQL, dzięki czemu znacznie obniżymy koszty stworzenia tego projektu.

Duży serwis internetowy

Załóżmy, że chcemy zbudować jak powyższej system rezerwacyjny, jednak usługi, która jest powszechna, działająca globalnie na całym świecie – rezerwacji biletów lotniczych. Dziennie jest dokonywanych setki milionów rezerwacji biletów lotniczych, także określenie docelowego ruchu jest nie możliwe, ponieważ jest to uzależnione od tego jak nasz biznes się rozwinie. Początkowo ruch będzie wynosił 0 a może się rozwinąć do np. 30mln użytkowników miesięcznie.

W takim wypadku należy przygotować tak kod aplikacji, aby był on skalowalny na wielu serwerach w chmurze. Dzięki takiemu rozwiązaniu, gdy nasz biznes urośnie wystarczy uruchomić dodatkowe moce obliczeniowe, aby obsłużyć ruch, a tak naprawdę może stać się to automatycznie.

Oczywiście taka architektura to wyższe koszty, dlatego odradzam zakładania z góry, że nasz serwis będzie odwiedzany przez miliony. Taniej jest zbudować system dwa razy, a za drugim razem być bogatszym o wiele doświadczeń.

Określenie ruchu podczas godzin szczytu (peak hours)

Jest to element, który jest bezpośrednio powiązany z punktem poprzednim, jednak tu chcemy się skupić na ruchu podczas godzin szczytu. Załóżmy, że chcemy zrobić prostą ankietę zawierającą 10 kroków z odpowiedziami. Ankieta jest zaprojektowana w formie konkursu, pierwsze sto osób otrzyma nagrody i zostanie rozesłana w formie mailingu do kilkunastu tysięcy osób.

W takim wypadku spodziewamy się bardzo dużego ruchu w jednej chwili – każdemu będzie zależało, aby być pierwszym i otrzymać nagrodę. Podstawowa konfiguracja PHP + MySQL jest w stanie obsłużyć od 5 do 40 RPS (request per second), dlatego w takim wypadku należałoby uwzględnić dodatkowe założenia projektowe, które pomogą nam obsłużyć taki ruch np. Load Balancing

Określenie wielkości zbiorów danych

Temat dość niszowy, jednak zdarzyło nam się spotkać z projektami, które przechowują tysiące GB danych. Dobrym przykładem może być tracking GPS pojazdów, gdzie potrzebujemy przechowywać pozycje przez dwa lata, z dokładnością do 5 minut. Taki system wygeneruje potężną ilość danych, dlatego w takim przypadku należy się zastanowić, w jaki sposób te dane przechowywać tak, aby ich przeszukiwanie było szybkie.

Lista podstawowych funkcjonalności

Nazwijmy to umownie spisem treści, który definiuje nam główne założenia projektu na zasadzie moduł logowania, rejestracja klientów, koszyk sklepowy, magazyn etc.

Procesy zachodzące po stronie użytkownika, systemu i administratora

W tym momencie tak naprawdę projektujemy dokładnie system. Opisujemy wszelkie procesy, powiązania pomiędzy poszczególnymi modułami oraz opisujemy algorytmy występujące w serwisie. Jest to bardzo istotny element tworzenia dokumentacji, która będzie podstawowym dokumentem używanym przez zespół podczas prac programistycznych nad systemem.

Procesy powinny posiadać podział na role, które mogą występować w systemie, np. Użytkownik, System oraz Administrator. Przykładowy proces wystawienia faktury może wyglądać następująco:

Wystaw FV -> Wymagaj zatwierdzenia od grupy Administratorzy -[Tak] -> Wyślij FV emailem do klienta

Lista aplikacji zewnętrznych, którą można wykorzystać w projekcie

Powinniśmy poświęcić część czasu na wykonanie reasearchu aplikacji, które już istnieją na rynku i można je wykorzystać w ramach naszego projektu. Pozwoli to na znaczne obniżenie kosztów projektu. Przykładem użycia aplikacji zewnętrznej może być LiveChat, którego koszty stworzenia od podstaw mogłyby przekroczyć budżetowo nie jeden projekt IT.

Wireframe

Wireframe – czyli makiety, projekty naszego serwisu internetowego. Nie należy mylić tego z projektem graficznym, jest to ogólna architektura i schemat rozmieszczenia poszczególnych elementów na danych podstronach. Dobrym porównaniem jest projekt domu jednorodzinnego.

Efektem finalnym są szkice każdej unikalnej podstrony. Projekty wireframe mogą być interaktywne tzn. po kliknięciu w dany element będzie wykonywana akcja (np. otwarcia okna). Jest to bardzo ważny etap przy projektowaniu aplikacji internetowych w tym momencie jesteśmy w stanie minimalnym kosztem modyfikować wygląd naszego serwisu.

Przy bardziej skomplikowanych projektach na tym etapie można przeprowadzić wstępne testy UX na kilkunastoosobowej grupie docelowej, które zweryfikują poprawność bądź nie naszych założeń. Dość oczywiste jest, ze takie testy są tańsze na tym etapie, ponieważ łatwiej jest wprowadzić modyfikacje do naszego projektu.

 

Jeżeli uważacie, że w dokumentacji powinny znaleźć się jakieś dodatkowe elementy – śmiało piszczcie w komentarzach.

 

Co oznacza hasło „dobry system IT”?

Pomińmy kwestię, że musi działać, nikt nie zamawia jakiejkolwiek usługi, z założeniem, która po prostu nie działa. Jednak w świecie IT hasło „działa” może inaczej wyglądać z punktu widzenia klienta oraz zespołu programistycznego. Aby bardziej rozszerzyć tą myśl przyjmijmy założenie, że dobry system IT to taki, który spełnia założenia biznesowe. Użyjmy dość prostego porównania do samochodów, jeżeli firma ma potrzebę przewozić meble, to nie potrzebuje auta osobowego, tylko minimum dostawczego (co również warto byłoby doprecyzować) – jednak zawsze jest to samochód, który nie w każdym przypadku spełni cele biznesowe.

Prosty przykład – program do wystawiania faktur

Spróbujmy przedstawić złożoność tworzenia systemów informatycznych na podstawie projektu, który wydaje się banalnie prosty, tzn. wystawianie faktur. Cała dokumentacja mogłaby się zamknąć w jednej stronie A4, która byłaby niczym innym jak wydrukiem pierwszej z brzegu faktury z obecnego systemu. Jeżeli jest to Twój pierwszy projekt informatyczny jaki zlecasz do realizacji, zapewne wydaje się Tobie, że w zasadzie wszystko jest jasne i nie za wiele więcej można wnieść.

Mało doświadczony zespół wykona wycenę, harmonogram i w zasadzie możemy startować!

Gdzie jest haczyk? Programista nie jest księgowym i wykona zlecenie intuicyjnie – czemu może to zlecenie wykonać źle? O tym w dalszej części wpisu.

Dwie dopuszczalne metody sumowania VAT na fakturze

Ustawodawca umożliwia dwa sposobu sumowania VAT na fakturze:

1. suma vat na dokumencie MUSI być sumą vat we wszystkich pozycjach
2. suma vat na dokumencie MUSI być sumą iloczynów sumy netto w danej stawce i stawki vat na podliczeniu faktury

Jak to wygląda w praktyce? Pierwszy sposób to tak zwane faktury brutto, wykorzystują przedsiębiorcy oferujący usługi firma – osoba fizyczna (rynek B2C) i najprawdopodobniej nasz programista z niego skorzysta – dla niego będzie to intuicyjne i zgodne z fakturami, które otrzymuje w swoim życiu codziennym. Może pokażmy to na przykładzie:

Pierwsza metoda obliczania VAT’u jest podobna do tej, którą znamy, na co dzień ze sklepów, z których korzystamy. Polega ona na doliczeniu VAT’u do pojedynczego produktu i następnie sumowaniu wszystkich cen zawierających podatek VAT. Na powyższym rysunku przykładowa faktura, na której znajduje się 7 kart pamięci. Dla klienta, który widzi w sklepie na półce tabliczkę z ceną widnieje kwota brutto, więc naturalne jest, że za 7 sztuk naszych kart musimy zapłacić 7 * 29,99 PLN

Inaczej ma się w przypadku transakcji B2B, gdzie przedsiębiorstwa patrzą na ceny netto przy zawieraniu transakcji. Na powyższym przykładzie możemy zaobserwować, że na fakturze najpierw są sumowane wszystkie kwoty netto, a następnie jest doliczany VAT.

Jaka jest różnica?

Zapewne wielu z Was zauważyło, że na obu fakturach znajdują się różne kwoty końcowe. W naszym przykładzie różnica wynosi 2 gorsze – będzie jednak ona wyższa, gdy będziemy posiadać więcej pozycji na dokumencie.

Wróćmy do dokumentacji, jak widać nasz programista mógł wykonać to zadanie na dwa różne sposoby i dużym prawdopodobieństwem wykonał to według przykładu pierwszego. Jeżeli wykonywał to zlecenie dla np. przedsiębiorstwa produkcyjnego, najprawdopodobniej klient nie będzie zadowolony z tego rozwiązania.

Czy programista źle wykonał zadanie? Nie – przecież wszystko jest zgodne z prawem i system działa.

Czy klient może być zadowolony z takiego rozwiązania? Nie – nie spełnia to jego założeń biznesowych.

Podsumowanie

W naszym wpisie użyliśmy bardzo prostego przykładu, który jednak obrazuje, że z pozoru łatwe projekty mogą się zakończyć porażką przy braku dobrze zdefiniowanych wymagań. Wyeliminowanie bledów, które pojawiły się z powodu nie zrozumienia na linii klient-firma IT jest z reguły bardzo kosztowne, a czasami może być niemożliwe.

 

 

Informujemy, że od 7 marca 2011 przeprowadziliśmy się do nowej siedziby – przy ulicy Górniczej 43 w Gdyni.

Informujemy, że w marcu przenosimy się do nowej siedziby – przy ulicy Górniczej 43 w Gdyni.

(więcej…)

Z miłą chęcią informujemy, że zostaliśmy zostaliśmy nominowani do otrzymania nagrody Pomorskiej „Gryf Gospodarczy 2010”. Wyniki rywalizacji o statuetki „Gryfa Gospodarczego 2010” zostaną ogłoszone przez Kapitułę podczas Gali Finałowej w Dworze Artusa w Gdańsku 28 maja 2010 roku o godzinie 13:00.

Lista nominowanych firm:

Mikroprzedsiębiorstwo
1. Master Telecom S.J Jacek Tomaszewski i Marcin Prochera – Gdynia
2. Web24.com.pl Koszlak i Broniszewski s.c. – Gdynia
3. Centrum Doskonalenia Kadr „Euro-Partner” sp. z o.o. – Gdynia

Małe przedsiębiorstwo
1. PIKA sp. z o.o. – Gdańsk
2. Biuro Kompleksowej Obsługi Firm J&J s.c. – Malbork
3. Madkom sp. z o.o. – Gdynia

Średnie przedsiębiorstwo
1. PROMiOS Ekomel sp. z o.o – Chojnice
2. Cemet Ltd. sp. z o.o.- Gdańsk
3. Stabilator sp. z o.o. – Gdynia

Duże przedsiębiorstwo
1. Zarząd Morskiego Portu Gdynia SA
2. Nordea Bank Polska SA – Gdynia
3. Drutex SA – Bytów.

Pełny artykuł na stronie dziennika bałtyckiego.

Zatrudniliśmy dwie nowe osoby, co wiązało się z zakupem sprzętu oraz oprogramowania na nowe stanowiska. Przy podłączaniu nowym stanowisk zdaliśmy sobie sprawę, że posiadamy już na tyle dużo oprogramowania co nie jeden sklep komputerowy w swoim magazynie 🙂

Firma WEB24.com.pl zwraca szczególną uwagę na aspekty legalności oprogramowania. Nigdy nie pracowaliśmy na oprogramowaniu nielegalnym nawet w momencie budowy nowego stanowiska pracy. Zdarza się, że realizacja zamówienia oprogramowania trwa nawet do 30 dni roboczych, ale w takich wypadkach zawsze prosimy oficjalnie producenta oprogramowania o zgodę na wykorzystywanie wersji trial w tym okresie.

Dzięki takiej polityce firmy nasi klienci mogą być spokojni na wypadek kontroli legalności pochodzenia oprogramowania wyprodukowanego przez WEB24. Przy okazji wymieniliśmy wszystkie Windowsy XP na nowszą wersje Windows 7, ze względu na zapowiadany brak przeglądarki  Internet Explorer 9 w systemie XP. Zapraszam do obejrzenia małej fotogalerii:

Wystartowaliśmy w konkursie Pomorskiego Gryfa Gospodarczego 2010. Ostatnie dwa tygodnie 5 osób z naszego zespołu zostały zaangażowane w przygotowanie wniosku o udział w konkursie. Prace były dość złożone, poprzez przygotowanie przez księgową danych dotyczących wyników finansowych spółki, grafika do przygotowania oprawy wniosku, copywritera aby wniosek był merytorycznie na jak najwyższym poziomie aż po założycieli WEB24 w celu zebrania najważniejszych informacji o spółce.

Zebraliśmy wiele pozytywnych referencji od naszych klientów między innymi od: Marka Kamińskiego – polarnika i założyciela fundacji, firmy Orlex, z którą współpracujemy już od 5 lat, opinii o projekcie wykonanym dla NSZZ Solidarność, firmy TMC z którą aktualnie pracujemy nad nowym projektem, który może zrobić trochę szumu w polskim internecie, JMB – producenta materacy, dla którego aktualnie prowadzimy szeroką kampanię w internecie z dość sporymi sukcesami, Centrum Nauki i Biznesu Żak dla którego przeprowadziliśmy bezpłatne praktyki dla studentów poparte naszymi doświadczeniami.

Zdobyliśmy również oficjalną rekomendację Gdyńskiego Centrum Innowacji, które było wymagane do wzięcia udziału w konkursie Pomorskiego Gryfa Gospodarczego 2010. Jako ciekawostkę mogę dodać, iż przedstawiciele centrum zainteresowali się naszą firmą i zaproponowali nam członkostwo w Pomorski Parku Naukowo Technologicznym z siedzibą w Gdyni.

Z niecierpliwością czekamy na wyniki konkursu, które będą opublikowane na gali 28 maja 2010 roku.