Usługi programistyczne w modelu outsourcingu - etapy i rozliczenie

Zlecenie tworzenia oprogramowania zewnętrznemu zespołowi różni się od outsourcingu utrzymania infrastruktury: efektem nie jest stała usługa, tylko działająca aplikacja, którą firma odbiera etapami. SoftwareStudio podejmuje się projektów informatycznych na różnych poziomach zaawansowania, od małych narzędzi po rozbudowane systemy. Ten tekst opisuje, jak taki model wygląda od strony umowy oraz odbioru prac.

Usługi programistyczne w modelu outsourcingu - na czym polegają

W modelu outsourcingu programistycznego firma opisuje potrzebę biznesową, a dostawca przejmuje analizę i projekt aplikacji. Później prowadzi kodowanie z testami oraz wdrożenie. Firma zachowuje wiedzę o własnych procesach i decyzje o priorytetach. Dostawca dostarcza zespół i metodykę pracy. Podział odpowiedzialności zapisuje się w umowie, bo od niego zależy, kto odpowiada za błąd w wymaganiach, a kto za błąd w kodzie.

Oprogramowanie na zamówienie powstaje od podstaw i uwzględnia wymagania konkretnej firmy, dlatego proces jest elastyczny: zmiany zgłoszone w trakcie realizacji da się wprowadzić bez rozpoczynania projektu od nowa. Warunkiem jest kontrola zakresu. Każda zmiana ma opis, wycenę wpływu na termin i decyzję zamawiającego. Szersze omówienie tego podejścia znajduje się w artykułach o oprogramowaniu na zamówienie oraz o oprogramowaniu na zamówienie w Poznaniu.

Drugi z tych modeli, czyli obsługa infrastruktury, ma osobny opis w tekście o zakresie usługi i umowie SLA w outsourcingu IT w Poznaniu.

Kiedy zlecić projekt na zewnątrz

Zewnętrzny zespół jest korzystny, gdy projekt jest jednorazowy, gdy firma potrzebuje specjalistycznej wiedzy tylko przez pewien czas albo gdy chce uniknąć kosztów stałego zespołu przy zmiennym obciążeniu pracą. Własny zespół ma przewagę tam, gdzie oprogramowanie jest głównym produktem firmy i wymaga zmian każdego dnia.

Częsty układ pośredni polega na tym, że firma zatrudnia analityka lub kierownika produktu, który zna procesy, a programistów zapewnia dostawca. Analityk pisze wymagania i odbiera etapy, a dostawca odpowiada za jakość kodu i terminy. Taki podział ogranicza koszt stałego zespołu i zachowuje w firmie wiedzę o tym, jak system ma działać.

Specyfikacja projektowa i podział na moduły

Pierwszym priorytetowym krokiem jest specyfikacja projektowa. Opisuje moduły systemu oraz odpowiedzialność każdego z nich, dzięki czemu zakres i funkcje aplikacji da się określić, zanim powstanie pierwszy wiersz kodu. Analizę wymagań poprzedza często analiza przedwdrożeniowa, która zbiera informacje o procesach i ich ograniczeniach.

Funkcje porządkuje się priorytetami, na przykład metodą MoSCoW, w której pozycje dzieli się na konieczne i ważne oraz na pożądane i świadomie odłożone. Taki podział pozwala zmieścić pierwsze wydanie w budżecie i zostawić resztę na kolejne etapy, bez przeglądania całej listy przy każdej zmianie terminu.

Dobra specyfikacja zawiera kryteria akceptacji: zdania, które da się sprawdzić testem. Zapis „system ma być szybki” nie spełnia tego warunku, natomiast „lista 500 zamówień otwiera się w czasie poniżej dwóch sekund” tak. Ta sama zasada dotyczy reguł biznesowych, które przenosi się do kodu i do bazy danych.

Reguły biznesowe warto zapisywać w dwóch miejscach. Baza chroni spójność danych niezależnie od aplikacji, a kod wyraża logikę procesu. Poniższy przykład (nazwy tabel są umowne) pokazuje ograniczenie statusu w SQL Server, opisane w dokumentacji ograniczeń CHECK na Microsoft Learn.

CREATE TABLE dbo.Zamowienie (
    Id            INT IDENTITY(1,1) PRIMARY KEY,
    Numer         NVARCHAR(30) NOT NULL UNIQUE,
    Status        TINYINT NOT NULL
        CONSTRAINT CK_Zamowienie_Status CHECK (Status BETWEEN 1 AND 4),
    UtworzonoUtc  DATETIME2(0) NOT NULL DEFAULT SYSUTCDATETIME()
);

Po stronie aplikacji ten sam status opisuje wyliczenie i funkcja dozwolonych przejść. Zestaw przejść jest krótki, więc zmiana reguły oznacza edycję jednej funkcji, a nie przegląd całego systemu.

public enum StatusZamowienia { Nowe = 1, WRealizacji = 2, Zrealizowane = 3, Anulowane = 4 }

public static bool CzyDozwolonaZmiana(StatusZamowienia z, StatusZamowienia na) =>
    (z, na) switch
    {
        (StatusZamowienia.Nowe, StatusZamowienia.WRealizacji) => true,
        (StatusZamowienia.Nowe, StatusZamowienia.Anulowane) => true,
        (StatusZamowienia.WRealizacji, StatusZamowienia.Zrealizowane) => true,
        _ => false
    };

Reguła: specyfikacja bez kryteriów akceptacji przenosi spór o zakres na dzień odbioru. Każdy moduł powinien mieć co najmniej jeden test, który zamawiający potrafi wykonać sam.

Etapy realizacji i odbiór prac

Oprogramowanie na zamówienie warto planować etapami. Każdy etap kończy się wersją, którą zamawiający może obejrzeć i sprawdzić na własnych danych, więc rozbieżność między oczekiwaniem a wykonaniem wychodzi po kilku tygodniach, a nie po kilku miesiącach. Metodyki iteracyjne omawia artykuł o zwinnym zarządzaniu projektami IT na zamówienie.

• Analiza wymagań - rozmowy z użytkownikami i opis procesu wraz z listą funkcji o ustalonych priorytetach.
• Projekt i specyfikacja - podział na moduły i model danych z kryteriami akceptacji.
• Programowanie i testy - implementacja modułów w kolejności ustalonej z zamawiającym, testy po każdym module.
• Wdrożenie i wsparcie - instalacja na środowisku produkcyjnym i szkolenie użytkowników, a potem obsługa zgłoszeń.

Odbiór etapu polega na sprawdzeniu kryteriów akceptacji z protokołem. Zamawiający zgłasza uwagi w ustalonym terminie, a wykonawca usuwa te, które dotyczą niespełnionego kryterium. Uwagi rozszerzające zakres trafiają na listę zmian z osobną wyceną.

Środowisko deweloperskie oddziela się od testowego, a testowe od produkcyjnego. Wersję z testów odbiera zamawiający, a na produkcję trafia dokładnie ta sama paczka, którą sprawdzono, bez ręcznych poprawek po drodze. Uruchomienie systemu w firmie opisuje szerzej strona o wdrożeniu oprogramowania w Poznaniu.

Ryczałt czy czas pracy - modele rozliczenia

Rozliczenie ryczałtowe ustala cenę za zakres opisany w specyfikacji. Model sprawdza się, gdy wymagania są stabilne, bo ryzyko przekroczenia pracochłonności ponosi wykonawca. Rozliczenie za czas pracy zespołu przenosi to ryzyko na zamawiającego, ale daje swobodę zmian priorytetów bez renegocjowania umowy.

Przykład z umownymi liczbami: moduł raportów oszacowano na 80 godzin pracy, a faktycznie zajął 100. Przy ryczałcie zamawiający płaci ustaloną kwotę, a różnicę pokrywa wykonawca. Przy rozliczeniu za czas płaci za 100 godzin. Zamawiający, który zna zakres i chce stałego budżetu, wybiera ryczałt, a ten, który spodziewa się zmian, wybiera czas pracy z miesięcznym limitem godzin.

Wycenę SoftwareStudio przygotowuje indywidualnie, po analizie zakresu. Koszt zależy od liczby funkcji, integracji z innymi systemami i wymaganego terminu, dlatego odpowiedź na pytanie o cenę bez specyfikacji jest z natury szacunkiem. Informacje o ofercie udostępnia strona usług SoftwareStudio.

Praca w siedzibie klienta i zdalnie

Bieżące wsparcie techniczne bywa świadczone w siedzibie klienta lub zdalnie, co daje dostęp do specjalistów bez względu na lokalizację firmy. Przy pracy zdalnej zespół potrzebuje repozytorium kodu i środowiska testowego dostępnego przez bezpieczne połączenie. Dokumentacja usług Azure Repos na Microsoft Learn opisuje przykład repozytorium z historią zmian i przeglądem kodu.

Przegląd kodu polega na tym, że drugi programista ogląda zmianę przed jej włączeniem do głównej gałęzi. Łapie błędy logiczne, sprawdza zgodność z przyjętymi konwencjami i rozprasza wiedzę o kodzie w zespole. Dla zamawiającego oznacza to, że odejście jednego programisty nie zatrzymuje projektu.

Reguła: programista nie potrzebuje danych produkcyjnych. Środowisko testowe zasila się kopią z zamaskowanymi danymi osobowymi, a dostęp do niego odbywa się przez VPN z kontami imiennymi zamiast wspólnego hasła.

Praca w siedzibie klienta ma sens w dwóch sytuacjach: przy analizie procesu, który trzeba zobaczyć na miejscu, oraz przy uruchomieniu systemu. Pozostałe czynności, w tym kodowanie i testy, dobrze wykonuje się zdalnie. Integrację z innymi systemami firmy omawia tekst o integracji systemów informatycznych.

Kod i dokumentacja przy przekazaniu projektu

Umowa powinna rozstrzygać, kto po odbiorze ma prawa do kodu źródłowego i w jakim zakresie może go zmieniać. Warunki przeniesienia praw autorskich ustala się indywidualnie, a niejasność w tym punkcie ujawnia się zwykle dopiero przy zmianie dostawcy. Zamawiający powinien mieć dostęp do repozytorium, do instrukcji uruchomienia i do opisu bazy danych.

Osobną kwestią są biblioteki osób trzecich. Aplikacja zwykle korzysta z komponentów na licencjach otwartych lub komercyjnych, a lista takich komponentów z wersjami i warunkami licencji trafia do dokumentacji. Dzięki temu firma wie, które zależności musi aktualizować i które warunki licencyjne dotyczą dalszej dystrybucji aplikacji.

Dokumentacja techniczna ma kilka warstw. Najważniejsza jest instrukcja wdrożenia, czyli opis kroków potrzebnych do postawienia aplikacji na czystym serwerze. Kolejna to opis modelu danych i interfejsów, a ostatnia to instrukcja dla użytkowników. Bez pierwszej dwie pozostałe nie ratują projektu w razie awarii.

Reguła: aplikację, której nie da się zbudować z repozytorium na czystej maszynie, uznaje się za nieprzekazaną. Odbiór końcowy obejmuje próbę takiego wdrożenia.

Testy i utrzymanie aplikacji po wdrożeniu

Testy automatyczne reguł biznesowych

Test automatyczny uruchamia funkcję z zadanymi danymi i porównuje wynik z oczekiwanym. Testy reguł przejść statusów są tanie w napisaniu, a chronią przed regresją, czyli sytuacją, w której zmiana w jednym module psuje działanie drugiego. Poniższy przykład zakłada, że funkcja z wcześniejszego fragmentu znajduje się w klasie Zamowienia.

public class StatusZamowieniaTests
{
    [Theory]
    [InlineData(StatusZamowienia.Nowe, StatusZamowienia.WRealizacji, true)]
    [InlineData(StatusZamowienia.Zrealizowane, StatusZamowienia.Nowe, false)]
    public void Przejscia_sa_zgodne_ze_specyfikacja(
        StatusZamowienia z, StatusZamowienia na, bool oczekiwany)
    {
        Assert.Equal(oczekiwany, Zamowienia.CzyDozwolonaZmiana(z, na));
    }
}

Zestaw takich testów uruchamia się przy każdym włączeniu zmiany do głównej gałęzi. Jeżeli test nie przechodzi, zmiana nie trafia do wydania. Dla zamawiającego jest to gwarancja mierzalna, bo raport z testów można pokazać przy odbiorze etapu.

Utrzymanie aplikacji po wdrożeniu

Zgłoszenia po wdrożeniu dzielą się na dwie grupy: błędy, które usuwa się w ramach gwarancji lub abonamentu, oraz zmiany i nowe funkcje, które wymagają wyceny. Rozróżnienie trzeba zapisać w umowie, bo granica między błędem a nową funkcją bywa przedmiotem sporów.

Każde wydanie ma swoją procedurę: kopię bazy danych przed wdrożeniem, skrypty migracji schematu i plan wycofania na wypadek błędu. Aktualizacje bibliotek, na których opiera się aplikacja, wykonuje się cyklicznie, bo nieaktualna biblioteka bywa najczęstszą drogą do incydentu bezpieczeństwa. Aplikacje z ASP.NET działają na serwerach Windows Server, więc utrzymanie kodu i środowiska warto powierzyć jednemu zespołowi.

Dedykowany system i praca użytkowników

System dostosowany do specyfiki firmy zwiększa zaangażowanie pracowników z konkretnego powodu: używa słownika i kolejności czynności, które znają z własnej pracy. Formularz zawiera tylko pola potrzebne na danym stanowisku, a rola użytkownika ukrywa funkcje, do których nie ma uprawnień. Mniej kliknięć i mniej wyjątków oznacza mniej błędów przy wprowadzaniu danych.

Wdrożenie kończy się szkoleniem, ale efekt szkolenia zależy od tego, czy w firmie jest osoba, która zna aplikację lepiej niż reszta zespołu. Taki opiekun aplikacji odpowiada za zbieranie uwag i za pierwszą linię pomocy. Zgłoszenia od niego trafiają do dostawcy już opisane i odtwarzalne, co skraca czas poprawki.

Dedykowana aplikacja nie zastępuje gotowego produktu we wszystkich przypadkach. Gdy proces jest standardowy, gotowy system bywa szybszy we wdrożeniu, a dedykowany rozwój zostaje zarezerwowany dla obszarów, które wyróżniają firmę. Podejście łączące własne produkty z rozwojem na zamówienie opisują artykuły o dedykowanych aplikacjach webowych i o software house, a szczegóły technologii aplikacji internetowych - tekst o tworzeniu aplikacji webowych.