Tworzenie programów dla firm - od analizy do kosztów utrzymania

Program dla firmy powstaje w odrębnych fazach, a każda z nich zostawia wynik, który można sprawdzić: dokument wymagań, prototyp, wersję testową, protokół odbioru. Ten tekst opisuje tworzenie programów dla firm od analizy po wieloletnie utrzymanie. Największą część kosztu zwykle generuje okres po wdrożeniu, dlatego dalej podany jest wzór, który pozwala policzyć go jeszcze przed podpisaniem zlecenia.

SoftwareStudio realizuje programy na zamówienie w postaci aplikacji internetowych oraz aplikacji na telefon i tablet z systemem Android. Opisany tu cykl dotyczy obu form, a różnice widać głównie w fazie testów i wdrożenia.

Tworzenie programów dla firm - etapy i wyniki

Tworzenie programów dla firm dzieli się na sześć etapów. Każdy kończy się artefaktem, który akceptuje konkretna osoba po stronie zamawiającego. Bez takiego podziału odbiór sprowadza się do ogólnego wrażenia, a spory o zakres wychodzą dopiero przy fakturze końcowej.

Reguła: etap uznaje się za zamknięty dopiero wtedy, gdy jego artefakt ma akceptację w formie pisemnej, także mailowej.

Kolejność nie jest w pełni liniowa. Testy wracają do wytworzenia, a nowe wymagania z wdrożenia trafiają do analizy następnej wersji. Ważne jest jedynie to, aby każda zmiana zakresu przechodziła przez ten sam obieg, w którym zmianę się opisuje i wycenia, a dopiero potem akceptuje.

Analiza wymagań i zakres pierwszej wersji

Analiza zaczyna się od procesu, a nie od ekranów. Analityk obserwuje, jak pracują ludzie: jakie dokumenty krążą, gdzie dane są przepisywane ręcznie i w którym miejscu proces zatrzymuje się na oczekiwaniu. Z tego powstaje lista wymagań, w której każdy punkt ma właściciela i priorytet.

Wywiady i obserwacja pracy

Wywiad z kierownikiem daje obraz oczekiwań, a obserwacja stanowiska pokazuje, jak proces działa naprawdę. Różnice bywają duże. Formularz uznany za obowiązkowy okazuje się pomijany, a arkusz kalkulacyjny prowadzony przez jedną osobę przechowuje dane, których nie ma w żadnym systemie. Analiza przedwdrożeniowa opisana w tekście o analizie przedwdrożeniowej systematyzuje ten etap.

Kryteria akceptacji wymagań

Wymaganie bez kryterium akceptacji jest tylko życzeniem. Zapis „program generuje raport sprzedaży" nie mówi, dla jakiego zakresu dat, w jakim czasie i z jakiego źródła danych. Poprawny zapis podaje wejście i oczekiwany wynik, na przykład: raport za dowolny miesiąc otwiera się w czasie uzgodnionym w umowie, a sumy zgadzają się z zestawieniem w księgowości.

Kryteria spisuje się razem z wymaganiami, a nie w dniu odbioru. Po stronie wykonawcy stają się scenariuszami testowymi, po stronie zamawiającego podstawą do podpisania protokołu.

Zakres wersji 1.0

Pierwsza wersja obejmuje tylko to, bez czego proces nie zadziała. Reszta trafia do rejestru zmian z oszacowaniem pracochłonności. Pomaga w tym prosty podział wymagań na dwie grupy.

• Wymagania obowiązkowe - bez nich program nie może wejść na produkcję, na przykład rejestracja dokumentu i kontrola uprawnień.
• Wymagania odroczone - usprawnienia, które można dodać w kolejnym wydaniu bez zmiany modelu danych.

Architektura i technologia programu

Architektura wynika z miejsca pracy użytkowników. Program używany przy biurku najlepiej działa jako aplikacja webowa, bo wymaga tylko przeglądarki i nie wymaga instalacji na stacjach. Praca w ruchu, na przykład przy skanowaniu towaru, wymaga aplikacji na Androida, która komunikuje się z serwerem przez ten sam interfejs. Przykład takiego podziału opisuje tekst o aplikacji magazynowej na Androida.

Dane trafiają do bazy SQL Server (zasady projektowania opisuje tekst o programowaniu baz danych), a logika biznesowa działa w warstwie serwerowej napisanej w C#. Interfejs korzysta z JavaScriptu i jQuery do wywołań asynchronicznych. Taki układ jest zgodny ze stosem, w którym SoftwareStudio wytwarza własne systemy logistyczne. Gdy program musi wymieniać dane z innym systemem, w projekcie pojawia się osobna lista integracji z formatem wymiany i częstotliwością synchronizacji.

Hosting i środowiska

Program potrzebuje co najmniej dwóch środowisk: testowego i produkcyjnego. Trzecie, przejściowe, przydaje się przy większych zmianach. Środowisko produkcyjne może działać u zamawiającego albo w chmurze prywatnej; sposób opisuje tekst o magazynie w chmurze. Wybór wpływa na koszty utrzymania, co widać w dalszej części.

Integracje z innymi systemami

Integracja z systemem księgowym lub ERP najczęściej działa przyrostowo. Program pobiera tylko rekordy zmienione od ostatniej synchronizacji, a znacznik czasu ostatniego przebiegu zapisuje w tabeli konfiguracyjnej. Poniższy fragment C# z przykładowym adresem pokazuje takie wywołanie interfejsu REST.

using var client = new HttpClient
{
    BaseAddress = new Uri("https://erp.example.local/api/")
};
var odpowiedz = await client.GetAsync("kontrahenci?zmieniono_od=2026-01-01");
odpowiedz.EnsureSuccessStatusCode();
var json = await odpowiedz.Content.ReadAsStringAsync();

Wywołanie obejmuje się obsługą błędów sieciowych i ponawianiem z rosnącym odstępem, bo interfejs sąsiedniego systemu bywa niedostępny w oknach serwisowych. Jeśli projekt tego nie uwzględni, koszt wróci później jako składnik poprawek we wzorze. Zasady łączenia programów opisuje tekst o integrowaniu aplikacji webowych.

Testy odbiorowe i migracja danych

Testy akceptacyjne wykonują użytkownicy według scenariuszy spisanych w fazie analizy. Scenariusz zawiera dane wejściowe i oczekiwany wynik, a każdy krok jest ponumerowany, dzięki czemu wynik jest porównywalny między testerami. Błędy dzieli się na krytyczne, blokujące pracę, oraz drobne, które nie zatrzymują odbioru, ale trafiają na listę poprawek.

Migracja danych z poprzedniego systemu jest osobnym podprojektem. Dane przechodzą przez tabelę pośrednią, w której da się je zweryfikować przed wczytaniem do właściwego modelu. Poniższy fragment T-SQL, w przykładowym schemacie, wyszukuje w imporcie kontrahentów zduplikowane numery NIP.

SELECT NIP, COUNT(*) AS Ile
FROM stg.Kontrahenci
GROUP BY NIP
HAVING COUNT(*) > 1
ORDER BY Ile DESC;

Zapytanie zwraca wiersze do ręcznego rozstrzygnięcia przed wczytaniem. Zwykle kilkanaście minut analizy na tym etapie oszczędza dni poprawek po uruchomieniu produkcyjnym.

Reguła: na produkcję trafia program, dla którego wykonano pełną kopię bazy testowej i sprawdzono, że da się ją odtworzyć.

Okno przełączenia na produkcję

Przełączenie ze starego systemu na nowy planuje się jako okno o ustalonej godzinie rozpoczęcia i zakończenia, najlepiej poza szczytem pracy. W tym czasie użytkownicy nie wprowadzają danych do starego systemu, wykonuje się ostatni import różnicowy, a potem test dymny, czyli krótki zestaw scenariuszy potwierdzających, że najważniejsze ścieżki działają.

• Przed oknem - kopia bazy testowej odtworzona próbnie oraz uzgodniona godzina decyzji o przełączeniu.
• W oknie - zamrożenie starego systemu i import różnicowy, a potem test dymny wykonany przez użytkowników.
• Po oknie - zwiększona gotowość zespołu wsparcia i dzienny przegląd zgłoszeń przez pierwszy tydzień.
• Wycofanie - powrót do starego systemu, jeśli test dymny nie przejdzie do ustalonej godziny, bez utraty danych.

Bez planu wycofania problem z importem kończy się pracą na dwóch niezgodnych zbiorach danych, co jest droższe niż przesunięcie wdrożenia o kilka dni.

Koszty utrzymania programu - wzór

Całkowity koszt posiadania programu składa się z ceny wytworzenia i sumy rocznych kosztów utrzymania. Wzór jest prosty, ale wymusza policzenie składników, które w ofercie zwykle nie występują.

Wzór: koszt całkowity po n latach = koszt wytworzenia + n x (licencje + hosting + poprawki błędów + zmiany wymagań).

Dwa ostatnie składniki najtrudniej przewidzieć, ale da się je zmierzyć. Wystarczy rejestrować zgłoszenia w tabeli i raz na kwartał zsumować godziny według typu, na przykład raportem zbudowanym w SQL Report Builderze. Poniższe zapytanie, na przykładowej tabeli zgłoszeń, pokazuje udział poprawek i zmian w rocznym nakładzie.

SELECT YEAR(Zgloszono) AS Rok,
       Typ,               -- 'BLAD' albo 'ZMIANA'
       SUM(Godziny)       AS Godziny
FROM dbo.ZgloszeniaUtrzymania
GROUP BY YEAR(Zgloszono), Typ
ORDER BY Rok, Typ;

Jeśli udział poprawek błędów maleje z roku na rok, program dojrzewa. Jeśli rośnie, przyczyna leży zwykle w niskiej jakości testów albo w długu technicznym, który narasta przy każdej szybkiej zmianie. Warto porównać ten trend z założeniami oferty, bo na jego podstawie da się wynegocjować zakres umowy serwisowej.

Jak czytać wzór przy różnych horyzontach

Przy krótkim horyzoncie, na przykład dwóch lat, dominuje koszt wytworzenia. Przy pięciu latach i dłużej składnik n razy suma roczna zaczyna go przewyższać, bo rośnie liniowo z czasem, a cena wytworzenia jest jednorazowa. Dwie oferty trzeba więc zestawiać przy tym samym n, a nie tylko według ceny wdrożenia.

Oferta z niską ceną wytworzenia bywa droższa w utrzymaniu, jeśli oszczędzono na testach albo dokumentacji. Droższe wdrożenie z pełnym pakietem testów automatycznych obniża składnik poprawek. Wzór nie rozstrzyga, która oferta jest lepsza, ale pokazuje, jakie założenia trzeba uzyskać od dostawcy na piśmie.

Utrzymanie w praktyce - kopie i monitoring

Utrzymanie składa się głównie z czynności powtarzalnych, a dopiero potem z poprawek. Kopie zapasowe bazy wykonuje się według wymagań RPO, czyli dopuszczalnego okna utraty danych. Do przywracania stosuje się RTO, czyli maksymalny czas przerwy. Obie wartości ustala zamawiający, a wykonawca dobiera częstotliwość kopii pełnych i różnicowych oraz dziennika transakcji tak, aby je spełnić.

BACKUP DATABASE Firma
TO DISK = N'D:\Kopie\Firma_pelna.bak'
WITH CHECKSUM, COMPRESSION, INIT;

RESTORE VERIFYONLY
FROM DISK = N'D:\Kopie\Firma_pelna.bak'
WITH CHECKSUM;

Sama kopia nie wystarcza, dopóki nikt nie sprawdził, że da się z niej odtworzyć bazę. Opcja CHECKSUM wykrywa uszkodzenie strony podczas zapisu, a RESTORE VERIFYONLY potwierdza czytelność pliku. Pełne opisy poleceń i strategii kopii zawiera dokumentacja Microsoft Learn o kopiach zapasowych SQL Server. Regularny test odtworzenia na środowisku testowym daje jedyną pewność, że plan awaryjny działa.

Monitoring i aktualizacje

Monitoring obejmuje dwie warstwy. Pierwsza to zasoby serwera, czyli miejsce na dysku i obciążenie procesora. Druga to zachowanie samego programu: czas odpowiedzi najważniejszych ekranów i liczba błędów w logu aplikacji. Aktualizacje systemu i SQL Server wdraża się najpierw na środowisku testowym, bo zmiana wersji potrafi zmienić plany wykonania zapytań.

Osobną kategorią są kwestie bezpieczeństwa serwerów. Ochronę serwerów opisuje oferta ESET Server Security w ofercie SoftwareStudio, a zarządzanie infrastrukturą jako całością tekst o outsourcingu IT w Poznaniu.

Kiedy rozwijać program, a kiedy go zastąpić

Program dla firmy nie starzeje się tylko przez wiek kodu. Przestaje pasować, gdy proces zmienia się szybciej niż tempo wprowadzania zmian albo gdy platforma techniczna wychodzi z okresu wsparcia. Decyzję ułatwia lista kryteriów przeglądu, wykonywanego raz w roku.

• Udział zmian w nakładzie - jeśli większość godzin idzie na poprawki starych funkcji, a nie na nowe wymagania, rachunek przemawia za refaktoryzacją modułu.
• Okres wsparcia platformy - wersja systemu lub SQL Server poza wsparciem producenta oznacza brak poprawek bezpieczeństwa i wymusza migrację.
• Koszt integracji - jeśli każda zmiana w sąsiednim systemie wymaga poprawek w programie, warto przeprojektować interfejs wymiany danych.
• Znajomość kodu - brak dokumentacji i osób, które rozumieją program, podnosi koszt każdej zmiany i jest sygnałem do uporządkowania dokumentacji.

Rozwój oznacza wymianę pojedynczych modułów przy zachowaniu modelu danych, a zastąpienie wymaga migracji danych i nowego wdrożenia. Zasady wyboru dostawcy opisuje tekst o oprogramowaniu na zamówienie, a szerszy obraz projektu i jego etapów pokazuje strona proces tworzenia oprogramowania dla firm. Zakres i warunki współpracy można omówić z zespołem SoftwareStudio przez stronę usług.

Przekazanie wiedzy i niezależność od wykonawcy

Niezależność od wykonawcy zapewniają dwie rzeczy: kod źródłowy w repozytorium zamawiającego oraz dokumentacja pozwalająca odtworzyć środowisko od zera. Umowa powinna wskazywać, kto jest właścicielem kodu i w jakim terminie wykonawca przekazuje aktualną dokumentację po każdym wydaniu.

Przy przekazaniu przydaje się próba: osoba niezwiązana z projektem stawia środowisko testowe według instrukcji. Każde miejsce, w którym instrukcja zawodzi, jest brakiem w dokumentacji, który taniej poprawić teraz niż podczas awarii.