Cechy producenta oprogramowania dla biznesu - lista kontrolna z weryfikacją

Cechy producenta oprogramowania dla biznesu i sposób ich sprawdzenia

Cechy producenta oprogramowania dla biznesu widać w sposobie pracy, a nie w opisie oferty. Producent, który zna dziedzinę klienta, odzwierciedla ją w modelu danych. Producent dbający o jakość pokazuje testy i historię wydań. Ten artykuł zbiera takie cechy i przy każdej podaje sposób sprawdzenia, który nie wymaga zaufania do deklaracji.

Podział producentów na pakiety standardowe oraz produkty branżowe i systemy na zamówienie omawia osobny tekst o typach producentów programów dla firm. Tutaj punkt ciężkości leży na tym, co odróżnia dobrego wytwórcę od przeciętnego, niezależnie od typu.

Reguła: cechę producenta można uznać za potwierdzoną dopiero wtedy, gdy istnieje dokument, zapis w umowie albo działający przykład.

Szerszy opis roli wytwórcy w projekcie zawiera artykuł o producencie oprogramowania.

Znajomość procesów branży w modelu danych

Producent oprogramowania biznesowego rozumie różnice między firmami: skalę operacji, liczbę oddziałów, sposób pracy zmian. Rozumienie nie kończy się na rozmowie, bo widać je w produkcie. W systemie magazynowym pisanym przez kogoś z doświadczeniem w magazynie lokalizacje i partie oraz statusy ruchu są osobnymi pojęciami. System zbudowany przez kogoś, kto magazynu nie widział, sprowadza wszystko do listy pozycji z ilością.

Ta cecha ma skutki praktyczne. Gdy proces firmy zmienia się, na przykład dochodzi drugi magazyn albo kontrola daty ważności, produkt oparty na właściwym modelu przyjmuje zmianę parametrem. Produkt oparty na uproszczonym modelu wymaga przebudowy tabel. Przykłady rozwiązań branżowych, w których model danych odzwierciedla procesy, opisuje artykuł o aplikacjach WMS.

Skala firmy i wydajność rozwiązania

Firma z kilkoma użytkownikami i firma z kilkuset stanowiskami potrzebują tego samego procesu, ale innego zaplecza technicznego. Producent, który zna obie skale, wie, że przy dużej liczbie jednoczesnych operacji o wydajności decydują indeksy w bazie, a nie moc serwera. Lista dokumentów przeglądana przez wielu użytkowników musi korzystać z indeksu na kolumnach, po których się ją filtruje.

CREATE INDEX IX_Documents_Status_Date
  ON dbo.Documents (Status, DocDate)
  INCLUDE (DocNumber, CustomerId);

Przykład jest poglądowy, a nazwy obiektów są przykładowe. Indeks pokrywający zapytanie o dokumenty w danym statusie i przedziale dat pozwala bazie odpowiedzieć bez czytania całej tabeli. Producent wie o tym z praktyki, ponieważ widział, jak ta sama lista zachowuje się przy tysiącu i przy milionie rekordów.

Jak sprawdzić znajomość branży

Najprostszy test polega na przedstawieniu producentowi trudnego przypadku z własnej firmy i obserwacji, jak go opisuje. Producent z doświadczeniem zada pytania o wyjątki: co dzieje się, gdy towar wraca po awizacji, kto zatwierdza korektę stanu, jak system traktuje partię po terminie ważności. Producent bez doświadczenia odpowie ogólnikiem o elastyczności.

Praktyki inżynierskie widoczne w produkcie

Jakość oprogramowania jest wynikiem procesu, który klient może zobaczyć od zewnątrz. Kod przechowuje się w systemie kontroli wersji, zmiany przechodzą przegląd drugiej osoby, a testy automatyczne uruchamiają się przed każdym wydaniem. Pełny opis etapów wytwarzania zawiera artykuł o procesie tworzenia aplikacji biznesowych.

Testy automatyczne chronią przede wszystkim reguły biznesowe. Reguła typu „nie można zarezerwować więcej, niż jest na stanie” zapisuje się jako test, który uruchamia się po każdej zmianie kodu. Poniższy przykład w języku C# jest poglądowy, a nazwy klas są przykładowe.

public class StockService
{
    public bool TryReserve(int available, int requested)
        => requested > 0 && requested <= available;
}

public class StockServiceTests
{
    [Fact]
    public void Reservation_above_available_is_rejected()
    {
        var service = new StockService();
        Assert.False(service.TryReserve(available: 5, requested: 6));
    }
}

Klient nie musi czytać takiego kodu. Wystarczy, że producent potrafi pokazać, że reguły istotne dla procesu mają testy, i że wydanie z nieprzechodzącym testem nie trafia do klienta.

Środowiska i proces wydania

Dojrzały producent utrzymuje co najmniej dwa środowiska: testowe i produkcyjne. Nowa wersja trafia najpierw do testowego, gdzie sprawdzają ją użytkownicy odpowiedzialni za proces. Dopiero po ich akceptacji zespół wykonuje kopię bazy produkcyjnej i wdraża wersję. Ta kolejność wydaje się oczywista, ale przy małych firmach bywa pomijana, a wtedy pierwszy test wykonują pracownicy na żywych dokumentach.

Warto zapytać, jak wygląda wycofanie zmiany. Producent, który przygotował procedurę powrotu do poprzedniej wersji, potrafi wskazać czas jej trwania i warunki, w których się ją uruchamia. Ten czas wchodzi w plan okna serwisowego.

Reguła: wydanie, które nie przeszło testów, nie trafia do klienta, nawet gdy termin umowny jest bliski.

Bezpieczeństwo aplikacji jako cecha producenta

Dostępność aplikacji z przeglądarki nie oznacza, że każdy może zobaczyć dane firmy. Producent odpowiada za mechanizmy autoryzacji i szyfrowanie połączeń oraz za ochronę przed typowymi atakami na aplikacje internetowe. Wymagania techniczne dla takich zabezpieczeń zebrano w projekcie OWASP Application Security Verification Standard, który służy zarówno do testowania aplikacji, jak i jako lista wymagań dla programistów.

W rozmowie z producentem warto odróżnić deklarację od praktyki. Deklaracja brzmi „stosujemy najlepsze zabezpieczenia”. Praktyka to odpowiedź na konkretne pytanie: jak przechowywane są hasła, jak długo ważna jest sesja użytkownika, jak zapisuje się zmiany w uprawnieniach i kto może je przeglądać.

Ważna jest także reakcja na zgłoszoną lukę. Producent powinien mieć wskazany kanał, przez który klient lub badacz przekazuje informację o podatności, oraz zasadę, że poprawka trafia do wszystkich klientów, a nie tylko do tego, który zgłosił problem. Bez takiego kanału informacja o luce krąży nieformalnie.

• Uprawnienia - role przypisane do funkcji, z zapisem, kto i kiedy zmienił dostęp do danych.
• Ślad audytowy - historia zmian w dokumentach wraz z użytkownikiem i czasem operacji.

Na poziomie bazy danych ma znaczenie sposób przechowywania haseł. Program nie zapisuje hasła w postaci jawnej, tylko wynik funkcji skrótu z dodatkiem losowej soli, więc wyciek tabeli użytkowników nie ujawnia haseł. Komunikacja między przeglądarką a serwerem odbywa się przez połączenie szyfrowane, a kopie zapasowe bazy przechowuje się w miejscu odrębnym od serwera produkcyjnego.

Osobną kategorią jest zgodność z przepisami o ochronie danych osobowych. Producent nie odpowiada za politykę firmy klienta, ale system powinien umożliwiać wykonanie obowiązków, na przykład usunięcie lub anonimizację danych na żądanie i ograniczenie dostępu do nich. Jeżeli producent dodaje funkcje oparte na sztucznej inteligencji, powinien opisać, gdzie przetwarzane są dane; ogólne zasady omawia artykuł o sztucznej inteligencji w firmie.

Wdrożenie i wsparcie po uruchomieniu

Producent oprogramowania biznesowego nie kończy pracy na dostawie programu. Do zakresu należą wdrożenie i szkolenie pracowników oraz pomoc techniczna po starcie. Przebieg wdrożenia w magazynie, wraz z podziałem odpowiedzialności, opisuje tekst o wdrożeniu systemu WMS.

Wsparcie ocenia się po tym, jak producent klasyfikuje zgłoszenia. Awaria zatrzymująca pracę stanowiska powinna mieć inny priorytet niż prośba o zmianę wyglądu wydruku. Klasyfikacja i czasy reakcji oraz kanały kontaktu trafiają do umowy, żeby nie zależały od dobrej woli w danym tygodniu.

Konkretne czasy reakcji zależą od umowy i nie wynikają z tabeli, która pokazuje tylko sposób podziału. Ważne, żeby producent w ogóle stosował taki podział i żeby zgłoszenie miało numer i historię oraz osobę odpowiedzialną. Szkolenia są kolejnym sprawdzianem: dobry producent uczy procedur firmy klienta, a nie samych funkcji menu.

Szkolenia oparte na procedurach klienta

Szkolenie z listy funkcji uczy, gdzie leży przycisk, ale nie uczy pracy. Skuteczniejsze jest szkolenie prowadzone według procedur firmy: przyjęcie dostawy, wydanie narzędzia, obsługa zwrotu. Uczestnik wykonuje całą ścieżkę na bazie testowej, a prowadzący zwraca uwagę na miejsca, w których procedura firmy różni się od domyślnej konfiguracji.

Po szkoleniu wyznacza się w firmie osobę, która zna system najlepiej i przyjmuje pierwsze pytania pracowników. Rozwiązanie skraca kolejkę zgłoszeń do producenta, bo część spraw okazuje się kwestią obsługi, a nie błędem programu.

Analiza biznesowa i specyfikacja wymagań

Producent, który pracuje odpowiedzialnie, zaczyna od analizy. Zbiera wymagania funkcjonalne, czyli opis tego, co system ma robić, oraz niefunkcjonalne, na przykład liczbę użytkowników i czas odpowiedzi. Wynik trafia do specyfikacji, którą klient akceptuje przed rozpoczęciem programowania. Dzięki temu obie strony rozumieją zakres, a zmiany w trakcie projektu są rozliczane jako jawne rozszerzenie. Zakres analizy porządkuje artykuł o analizie przedwdrożeniowej, a doradztwo przy budowie systemów opisuje tekst o doradztwie przy tworzeniu systemów IT.

Ta sama dokumentacja bywa potrzebna przy ubieganiu się o dofinansowanie. Wniosek o fundusze unijne wymaga opisu projektu w języku wymagań technicznych, a oceniający sprawdzają, czy rozwiązanie jest wykonalne i uzasadnione ekonomicznie. Producent, który potrafi przygotować specyfikację i analizę wykonalności, skraca ten etap. Kryteria formalne zawsze wynikają z dokumentacji konkretnego naboru, więc trzeba je sprawdzić przed rozpoczęciem prac.

Reguła: specyfikacja pisana do wniosku o dotację musi być zgodna z dokumentacją naboru, a nie z ogólnym wzorem znalezionym w Internecie.

Co powinna zawierać specyfikacja

Dobra specyfikacja jest krótka i jednoznaczna. Opisuje procesy i role oraz dokumenty i integracje, a każde wymaganie ma kryterium odbioru, czyli sposób stwierdzenia, że zostało spełnione. Wymaganie typu „system ma być szybki” nie ma kryterium, a wymaganie „lista dokumentów otwiera się poniżej dwóch sekund przy dziesięciu tysiącach rekordów” je ma. Liczby w specyfikacji ustala się z klientem na podstawie jego danych, a nie przejmuje z wzorca.

Zmiany zakresu w trakcie projektu są zjawiskiem normalnym, więc producent powinien mieć procedurę ich obsługi. Zmiana otrzymuje opis, wycenę wpływu na harmonogram i akceptację klienta, a dopiero potem trafia do realizacji. Bez takiej procedury rozliczenie końcowe staje się sporem o to, co było w zakresie, a co dopisano ustnie.

Cechy producenta w działaniu SoftwareStudio

SoftwareStudio z Poznania tworzy aplikacje internetowe i mobilne na zamówienie oraz systemy branżowe, a klienci mogą porównać podejście producenta z opisanymi wyżej cechami. Firma doradza na kolejnych etapach projektu, pomaga w określeniu założeń i pisaniu specyfikacji oraz wykonuje analizy biznesowe. Ofertę zbiera portal SoftwareHouse Poznań, a zakres prac na zamówienie opisuje strona oprogramowanie na zamówienie.

W obszarze logistyki producent oferuje systemy WMS oraz ERP, które obsługują między innymi przyjęcie towaru do magazynu i kontrolę stanów. Do obsługi posprzedażowej służy Studio RMA.net, program do reklamacji, w którym rejestruje się zgłoszenia i monitoruje status sprawy. Zwroty i naprawy przechodzą w nim przez ustalone etapy. System opisuje artykuł o systemie RMA online.

Opisane cechy da się porównać z tym, co producent pokazuje w demonstracji. Zestawienia i wydruki w produktach SoftwareStudio powstają w narzędziach opisanych w artykule o SQL Report Builder. Rozwiązania pokazuje też demo online, które pozwala sprawdzić opisane cechy na działającym przykładzie, jeszcze przed rozmową o wdrożeniu.