Firmy programistyczne Wrocław - jak zlecić i odebrać projekt

Zlecenie prac firmie programistycznej kończy się dobrze wtedy, gdy obie strony opisały ten sam wynik. Firmy programistyczne Wrocław wyceniają i realizują to, co da się sprawdzić w dokumencie: listę funkcji z kryteriami odbioru oraz terminy etapów. Reszta zostaje w sferze deklaracji handlowych.

Strona porządkuje decyzje zamawiającego w kolejności, w jakiej zapadają. Najpierw zakres, potem umowa z rozliczeniem, następnie osobny wątek aplikacji mobilnych. Na końcu przekazanie kodu i dokumentacji, bez którego zamawiający zostaje zależny od jednego wykonawcy. Przykłady pochodzą ze stosu, w którym pracuje SoftwareStudio: C# po stronie serwera i T-SQL w bazie SQL Server.

Firmy programistyczne Wrocław i zakres zlecenia

Do zakresu zlecenia obie strony wracają w każdym sporze. Jeśli mówi tylko o funkcjach, wykonawca wyceni funkcje, a zamawiający oczekiwał procesu. Dobry zakres opisuje sześć obszarów, a przy każdym pytanie kontrolne, na które da się odpowiedzieć bez interpretacji.

Różnicę między stroną firmową a systemem widać dopiero w tej tabeli. Aplikacja webowa przetwarza dane i pilnuje uprawnień, więc każdy z sześciu obszarów kosztuje czas analizy. Strona wizytówkowa nie ma ról ani migracji, dlatego ta sama stawka godzinowa daje w obu przypadkach zupełnie inny wynik.

Reguła: zakres bez zdania o tym, co jest poza zakresem, jest niepełny. Każda funkcja niewymieniona z nazwy wraca później jako wycena zmiany.

Pierwszą pracą wykonawcy jest zwykle analiza, w której zakres dostaje wersję do akceptacji. Jak taka analiza wygląda i co z niej zostaje w dokumentach, opisuje strona o analizie przedwdrożeniowej. Zamawiający, który przychodzi z gotową listą sześciu obszarów, skraca ten etap i dostaje dokładniejszą wycenę.

Specyfikacja i kryteria odbioru

Kryterium odbioru musi dać się potwierdzić albo obalić testem. Sformułowania ogólne przenoszą spór na koniec projektu, więc trzeba je zastąpić warunkami mierzalnymi jeszcze przed programowaniem.

Kryterium importu pokazuje, jak łatwo o rozbieżność: „poprawny” dla zamawiającego oznacza brak pominiętych klientów, a dla wykonawcy brak błędów wczytania. Zapytanie kontrolne zamienia to w liczbę. Nazwy tabel poniżej są przykładowe, a nie schematem konkretnego produktu.

-- kontrola migracji: porównanie zbioru źródłowego z docelowym
SELECT
    (SELECT COUNT(*) FROM stary.Klient) AS wiersze_zrodlo,
    (SELECT COUNT(*) FROM dbo.Klient)   AS wiersze_cel,
    (SELECT COUNT(*)
       FROM stary.Klient AS s
      WHERE NOT EXISTS (SELECT 1 FROM dbo.Klient AS k WHERE k.NIP = s.NIP)) AS brak_w_celu;

Kryterium brzmi wtedy: kolumna brak_w_celu ma wartość zero, a różnica w liczbie wierszy ma pokrycie w liście duplikatów zatwierdzonej przez zamawiającego. Szerzej o odbiorze po migracji pisze artykuł o wdrożeniu oprogramowania.

Etapy projektu i odbiory częściowe

Projekt dzielony na etapy pozwala wykryć rozbieżność oczekiwań wtedy, gdy poprawka kosztuje godziny, a nie tygodnie. Każdy etap kończy się wersją uruchomioną na środowisku testowym oraz krótkim protokołem: co sprawdzono, jakie usterki zgłoszono, co zostaje do poprawy.

• Etap analityczny - wynikiem jest zakres zatwierdzony przez zamawiającego, z listą funkcji i kryteriów odbioru.
• Etap wytwórczy - wynikiem są wersje pokazowe co kilka tygodni, aby użytkownicy widzieli aplikację przed końcem prac.
• Etap testów odbiorowych - zamawiający wykonuje scenariusze na kopii danych, a wykonawca usuwa usterki w uzgodnionej liczbie rund.
• Etap wdrożenia - aplikacja trafia na produkcję, a wykonawca prowadzi szkolenie i przyjmuje pierwsze zgłoszenia.

Testy odbiorowe zamawiającego mogą mieć formę scenariuszy wykonywanych ręcznie, ale reguły biznesowe warto dodatkowo zapisać jako testy automatyczne. Wykonawca uruchamia je przy każdej zmianie, więc regresja wychodzi od razu, a nie po tygodniu użytkowania. Poniższy test jest przykładem reguły, którą zamawiający potrafi opisać jednym zdaniem.

// przykładowy test reguły biznesowej (xUnit, nazwy przykładowe)
[Fact]
public void Zamowienie_powyzej_limitu_wymaga_akceptacji()
{
    var zamowienie = new Zamowienie(wartosc: 12000m);
    var polityka = new PolitykaAkceptacji(limit: 10000m);

    Assert.True(polityka.WymagaAkceptacji(zamowienie));
}

Test pełni dwie role. Dla wykonawcy jest siatką bezpieczeństwa przy zmianach, a dla zamawiającego wykonywalnym zapisem uzgodnionej reguły, który zostaje w repozytorium po zakończeniu projektu. Podział prac testowych i rolę testera opisano przy okazji procesu tworzenia aplikacji biznesowych.

Umowa i model rozliczenia prac

Model rozliczenia rozkłada ryzyko między strony. Stała cena przenosi na wykonawcę ryzyko niedoszacowania, rozliczenie godzinowe przenosi je na zamawiającego. Żaden z modeli nie jest lepszy sam w sobie, a wybór zależy od tego, jak stabilny jest zakres.

Umowa techniczna obejmuje więcej niż cenę. Strony powinny uzgodnić liczbę rund poprawek po odbiorze oraz definicję usterki w odróżnieniu od zmiany. Więcej o tym, jak rozliczane są usługi programistyczne, opisano na osobnej stronie.

Reguła: tryb zmian zakresu zapisuje się przed pierwszą zmianą. Późniejsze negocjacje odbywają się już pod presją terminu.

Zapisy o prawach autorskich i o odpowiedzialności wykonawcy należą do prawnika, a nie do tej strony. Zamawiający może natomiast przygotować listę pytań technicznych, którą prawnik przełoży na język umowy. Kryteria oceny wykonawcy zebrano w artykule o wyborze dostawcy oprogramowania na zamówienie.

Aplikacje mobilne w zleceniu

Zlecenie aplikacji mobilnej wymaga jednej decyzji więcej niż zlecenie aplikacji webowej: czy program działa w przeglądarce telefonu, czy jest instalowany jako pakiet na urządzeniu. Wybór zależy od tego, czego oczekuje się od sprzętu, a nie od mody technologicznej.

Wymagania sprzętowe w zleceniu

Zlecenie aplikacji instalowanej wskazuje minimalną wersję Androida oraz sposób odczytu kodów. Terminal z wbudowanym skanerem zachowuje się inaczej niż telefon z aparatem, a różnica wychodzi dopiero na hali, przy zabrudzonych etykietach. Zamawiający powinien więc dołączyć do zlecenia listę urządzeń, na których wykonawca przeprowadzi testy odbiorowe.

Praca bez zasięgu

Magazyn i hala produkcyjna mają miejsca bez sieci. Aplikacja, która w takich miejscach ma nadal przyjmować dane, zapisuje je lokalnie i wysyła później. Na Androidzie służy do tego lokalna baza, na przykład Room opisany w dokumentacji Androida. W zleceniu trzeba zapisać, jak długo dane mogą czekać na wysłanie i co się dzieje, gdy serwer je odrzuci.

Ponowna wysyłka rodzi ryzyko dubletu, jeśli pierwsza próba doszła do serwera, a odpowiedź zginęła po drodze. Rozwiązaniem jest klucz idempotentności: identyfikator nadany na urządzeniu, który serwer traktuje jako znacznik jednej operacji.

var kolejka = [];

// przykładowa wysyłka skanu z kluczem idempotentności
function wyslijSkan(skan) {
  $.ajax({
    url: '/api/skany',
    type: 'POST',
    contentType: 'application/json',
    headers: { 'Idempotency-Key': skan.id },
    data: JSON.stringify(skan)
  }).fail(function () {
    kolejka.push(skan); // ponowna próba po odzyskaniu zasięgu
  });
}

Serwer zapisuje klucz razem z operacją i przy powtórzeniu zwraca poprzedni wynik zamiast tworzyć drugi rekord. Ten mechanizm należy do kryteriów odbioru aplikacji mobilnej, tak samo jak test odcięcia sieci w trakcie wysyłki.

Publikacja i aktualizacje aplikacji

Pakiet aplikacji trafia na urządzenia firmowe innym kanałem niż na telefony prywatne, a zlecenie powinno wskazywać, który z nich obowiązuje. Przykład programu magazynowego w wersji webowej i na Androida opisano w artykule o aplikacji magazynowej na Androida, a wybór między podejściem natywnym a webowym porównano w tekście o tworzeniu aplikacji mobilnych.

Przekazanie kodu i dokumentacji

Przekazanie kodu jest zdarzeniem z listą kontrolną, a nie deklaracją w umowie. Zamawiający sprawdza, czy z przekazanych materiałów da się odtworzyć działającą aplikację bez udziału autorów.

Najprostszy test kompletności repozytorium to wykonanie kopii lustrzanej i sprawdzenie, czy wszystkie wersje wydań są w niej widoczne. Polecenia poniżej działają na dowolnym serwerze Git, a adres jest przykładowy.

git clone --mirror https://serwer.example/projekt.git projekt-kopia.git
cd projekt-kopia.git
git tag --list "v*"
git log --oneline -5

Pusta lista znaczników oznacza, że wydania nie były oznaczane, więc nie da się wskazać kodu, który działał w danym dniu na produkcji. Praktyki wykonawcy, jak przeglądy kodu i testy przed wydaniem, opisano w artykule o firmie programistycznej od strony warsztatu. Kwestie licencji i praw do kodu rozdziela strona o licencji i gwarancji producenta programów.

Reguła: odbiór końcowy obejmuje odtworzenie aplikacji z przekazanych materiałów. Jeśli wymaga pomocy autora, przekazanie jest niepełne.

Współpraca lokalna i zdalna

Lokalizacja wykonawcy wpływa na sposób prowadzenia projektu, a nie na jakość kodu. Warsztaty analityczne i szkolenie użytkowników łatwiej przeprowadzić na miejscu, natomiast programowanie i testy przebiegają tak samo niezależnie od odległości. Dostawcy z Wrocławia, jak i z innych miast, realizują projekty dla firm z całej Polski.

• Spotkania na miejscu - skracają warsztaty procesowe, bo wykonawca widzi stanowiska pracy i dokumenty obiegające w firmie.
• Praca zdalna - wymaga jasnego harmonogramu, stałych raportów z postępu i wspólnego środowiska testowego dostępnego z sieci.

SoftwareStudio działa na rynku od 2008 roku i według opisu firmy prowadzi administrację systemami i wsparcie techniczne dla użytkowników po stronie zamawiającego, a także tworzy oprogramowanie dedykowane i zarządza danymi. Informacje o firmie znajdują się na stronie o firmie. Ogólne pojęcie wykonawcy tego typu wyjaśnia artykuł o tym, czym jest software house.

Wsparcie po odbiorze aplikacji

Odbiór nie zamyka współpracy, bo aplikacja biznesowa zmienia się razem z firmą. Zlecenie powinno więc wskazywać, kto przyjmuje zgłoszenia po odbiorze, w jakim czasie reaguje i jak rozlicza poprawki. Czas reakcji i czas naprawy to dwie różne liczby: pierwsza mówi, kiedy ktoś zacznie pracę, druga, kiedy usterka zostanie usunięta.

Umowa serwisowa, najczęściej w formie SLA, zawiera klasy priorytetów usterek i przypisane im czasy. Zakres takiego utrzymania, w tym kopie zapasowe bazy i aktualizacje, opisuje artykuł o utrzymaniu dedykowanych aplikacji webowych. Zamawiający, który chce rozwijać aplikację u innego wykonawcy, potrzebuje kompletnego przekazania z poprzedniej sekcji, bo tylko ono pozwala nowemu zespołowi zacząć pracę od czytania kodu, a nie od jego rekonstrukcji.