Rozwój i wdrożenie

Od specyfikacji do integracji: OTOKO® tworzy aplikacje i łączy je z Państwa istniejącymi systemami i procesami.

Niezależnie od tego, czy to aplikacja specjalistyczna, produkt cyfrowy czy narzędzie wewnętrzne: tworzymy oprogramowanie dla procesów, których nie da się sensownie odwzorować w istniejących systemach.

Analiza wymagań z działem biznesowym, model zagrożeń i architektura docelowa zgodnie z modelem C4 Model dziedzinowy, model danych i kontrakty interfejsów przed pierwszą linią kodu Prace programistyczne w krótkich iteracjach, z przeglądami kodu i odbiorami dokonywanymi przez dział biznesowy Bezpieczne wytwarzanie oprogramowania zgodnie z OWASP ASVS, zweryfikowane zależności i podpisane buildy Przekazanie z kodem źródłowym, dokumentacją architektury i podręcznikiem eksploatacji

Działająca aplikacja z kodem źródłowym i pipeline'em budowania Dokumentacja architektury z modelem zagrożeń Podręcznik eksploatacji z runbookami i planem postępowania w sytuacjach awaryjnych

Przykłady obecnych przebiegów pracy i wyjątków Osoby odpowiedzialne za decyzje merytoryczne Istniejące systemy, źródła danych i wymagania eksploatacyjne

Planowanie konserwacji prowadzone jest dotychczas w arkuszach kalkulacyjnych. Aplikacja specjalistyczna łączy instalacje, terminy, zakresy odpowiedzialności i zatwierdzenia. Pierwszy etap rozbudowy obejmuje jedną lokalizację; kolejne lokalizacje zostaną dodane dopiero po merytorycznej weryfikacji procesu.

.NET C# Go Rust TypeScript PostgreSQL

Na początku analizujemy proces pracy, dla którego inwestycja ma się opłacić. Pojęcia, stany i reguły biznesowe modelujemy wspólnie z osobami, które będą później pracować z aplikacją. Zatwierdzenie to na przykład nie tylko przycisk: zastępstwo, uprawnienia, terminy i wycofanie decyzji muszą do siebie pasować. Te reguły stają się częścią modelu danych i testów. Pierwsza wersja koncentruje się na kompletnym, użytecznym procesie. Kolejne funkcje dodajemy na podstawie informacji zwrotnych z użytkowania. W ten sposób powstaje produkt o sprawdzalnej wartości, a nie duży zbiór niedokończonych ekranów.

Technologie dla backendu, interfejsu użytkownika i przechowywania danych wybieramy na podstawie Państwa istniejącego środowiska systemowego i przewidywanego rozwoju. Istniejące kompetencje, interfejsy i wymagania eksploatacyjne mają większe znaczenie niż krótkotrwały trend technologiczny. Obecna oferta obejmuje między innymi .NET, Go i TypeScript; komponenty niskopoziomowe oceniamy odrębnie. Granice modułów i zakresy odpowiedzialności definiujemy tak, aby zmiany pozostawały łatwe do śledzenia. Dane dostępowe nie trafiają do kodu źródłowego, a reguły biznesowe nie znajdują się wyłącznie w interfejsie. Przeglądy kodu, automatyczne kontrole i wersjonowane zmiany bazy danych towarzyszą realizacji od samego początku.

Każda iteracja pokazuje użyteczne funkcje ze znanymi ograniczeniami. Odbiór biznesowy i zatwierdzenie techniczne traktujemy odrębnie: poprawnie obliczone zamówienie może być merytorycznie prawidłowe, choć zachowanie pod obciążeniem lub obsługa błędów nie są jeszcze gotowe do produkcji. Wspólnie ustalamy, jakie dowody są potrzebne dla danego etapu rozbudowy. Do uzgodnionego zakresu dostawy należą kod źródłowy, odtwarzalne buildy i dokumentacja. Przed startem produkcyjnym wyjaśniamy migrację danych, szkolenie, zakresy odpowiedzialności i sposób postępowania w razie awarii. Prawa użytkowania, komponenty zewnętrzne i późniejsze utrzymanie regulujemy przed przekazaniem.

Aplikacja musi działać prawidłowo również wtedy, gdy kilka osób jednocześnie zmienia ten sam stan magazynowy. Dwie rezerwacje nie mogą niezauważenie przydzielić tej samej, ostatniej sztuki towaru. Dlatego określamy, które zmiany muszą zakończyć się sukcesem razem, a które konflikty wymagają komunikatu dla użytkownika na poziomie biznesowym. Ograniczenia bazy danych, transakcje i sprawdzanie wersji mogą rozwiązywać różne części tego zadania; sam interfejs nie zabezpieczy tych reguł. Dłuższe procesy biznesowe natomiast często nie mieszczą się w jednej transakcji. Zamówienie, zewnętrzna usługa płatnicza i zatwierdzenie wysyłki mają własne stany błędów. Proces modelujemy za pomocą przejrzystych stanów i dopuszczalnych przejść między nimi. Ponawiane żądania otrzymują odpowiedni identyfikator operacji, aby zerwanie połączenia nie wywoływało automatycznie podwójnej akcji. W przypadku błędów częściowych potrzebna jest korekta zdefiniowana merytorycznie, na przykład wycofanie zatwierdzenia, a nie ogólny techniczny restart.

Dla produktów SaaS i platform wewnętrznych odróżniamy tożsamość użytkownika od jego uprawnień do konkretnego rekordu. Zalogowany pracownik nie ma automatycznie prawa do odczytu każdej faktury czy każdego zlecenia. Dostępy sprawdzamy w backendzie na poziomie organizacji, roli i operacji. Te granice muszą uwzględniać również eksporty, indeksy wyszukiwania, zadania w tle i zapisane w pamięci podręcznej wyniki. Wspólne tabele z oznaczeniem dzierżawcy, rozdzielone schematy baz danych lub własne bazy danych niosą ze sobą różne wymagania dotyczące izolacji, migracji i odtwarzania. Model wybieramy na podstawie wymaganego poziomu rozdzielenia i sposobu organizacji eksploatacji u Państwa. Testy z wieloma dzierżawcami sprawdzają w szczególności niedozwolone dostępy. Rejestr audytowy dokumentuje istotne merytorycznie zmiany z odpowiednim kontekstem; jakie dane się w nim znajdują i jak długo są dostępne, ustalamy w sposób jednoznaczny.

Struktura danych wynika z zapytań i reguł biznesowych. Analizujemy typowe filtry, sortowania, raporty i operacje zapisu, zanim wprowadzimy dodatkowe technologie przechowywania danych. Nieograniczone listy wyników, powtarzane pojedyncze zapytania i duże transfery danych mogą spowolnić aplikację, choć serwer wydaje się niemal nieobciążony. Pomiary z realistycznymi ilościami danych pokazują, czy pomagają indeksy, zmiany zapytań, paginacja lub inny podział zadań. Buforowanie (caching) jest świadomą decyzją dotyczącą aktualności danych: musi być jasne, kiedy zapisany wynik traci ważność i którzy użytkownicy mogą go zobaczyć. Obszerne obliczenia mogą działać jako zadania w tle, wymagają jednak wskaźnika postępu, możliwości ponownego uruchomienia i stanów błędów. Przy rozszerzeniach oddzielamy reguły biznesowe od technicznych adapterów. Automatyczne testy i wersjonowane zmiany bazy danych zabezpieczają te granice, dzięki czemu nowy kanał lub inny dostawca nie wymusza zmian w każdym module.

Środowisko aplikacyjne, wymagania, ryzyka Dział biznesowy, IT, bezpieczeństwo informacji, architekt oprogramowania OTOKO® Ocenione przedsięwzięcia, inwentaryzacja, wymagania bezpieczeństwa i eksploatacji

Architektura, technologia, model eksploatacji Dział biznesowy, architektura, ochrona danych, bezpieczeństwo informacji Architektura docelowa, model zagrożeń, strategia testów, model eksploatacji, kamienie milowe