Usługi informatyczne dla firm - wdrożenia i migracje

Usługi informatyczne dla firm jako projekt, nie abonament

Usługi informatyczne dla firm dzielą się na dwie grupy o odmiennej logice. Obsługa bieżąca trwa bez końca i rozlicza się z dostępności środowiska. Projekt ma początek i koniec oraz z góry uzgodniony budżet, a jego wynik to konkretny system albo przeniesione środowisko. Ten tekst dotyczy drugiej grupy, czyli wdrożeń aplikacji i migracji środowisk.

Projekty realizuje często software house, czyli firma tworząca oprogramowanie na zamówienie. Taki dostawca projektuje i wdraża aplikacje wspierające konkretne procesy biznesowe klienta, a nie sprzedaje gotowego pudełka. SoftwareStudio prowadzi tego rodzaju prace w Poznaniu, a także w Gorzowie Wielkopolskim i Wrocławiu, łącząc lokalny kontakt z zapleczem zespołu programistów.

Reguła: projekt bez zapisanych kryteriów odbioru nie ma momentu, w którym można go uznać za zakończony.

Analiza potrzeb i zakres projektu

Pierwszy etap decyduje o kosztach całego przedsięwzięcia. Zespół poznaje cele biznesowe i zakres funkcji oraz ustala ograniczenia techniczne po stronie klienta. Wynikiem jest dokument, który opisuje procesy w stanie obecnym i oczekiwanym oraz wskazuje obszary wymagające integracji. Metodykę takiej analizy przedstawia materiał o analizie przedwdrożeniowej.

Przed porównywaniem ofert dobrze jest spisać systemy, z którymi nowa aplikacja musi się połączyć. Dostawca dostaje wtedy pełny obraz zadania i może wycenić je trafnie, a etap analizy się skraca. Lista integracji podaje nazwę systemu oraz kierunek wymiany danych. Osobna kolumna opisuje sposób komunikacji, na przykład interfejs REST albo plik wymiany.

Wymagania funkcjonalne i pozafunkcjonalne

Wymagania funkcjonalne opisują, co system robi, na przykład jakie dokumenty tworzy i jakie raporty zwraca. Wymagania pozafunkcjonalne określają jakość działania, czyli wydajność i dostępność oraz poziom zabezpieczeń. Pominięcie drugiej grupy jest częstą przyczyną sporów przy odbiorze, ponieważ aplikacja może spełniać wszystkie funkcje i mimo to działać zbyt wolno przy realnym obciążeniu.

Wdrożenie aplikacji webowej - etapy realizacji

Dobrze prowadzony projekt aplikacji webowej przebiega przez powtarzalne etapy. Ich znajomość pozwala ocenić, czy oferta jest realistyczna, czy pomija ważne czynności kosztem szybszej wyceny. Realistyczny harmonogram jest lepszym wskaźnikiem doświadczenia dostawcy niż deklaracja liczby lat na rynku.

Pominięcie któregoś z tych etapów zwykle odbija się na jakości wyniku. Wykonawcy, którzy skracają fazę analizy, częściej dostarczają aplikacje wymagające kosztownych poprawek po uruchomieniu. Praktyczne zasady budowy takich programów opisują materiały o tworzeniu aplikacji webowych oraz o wdrożeniu oprogramowania w Poznaniu.

Iteracje i demonstracje

Praca w krótkich iteracjach zamienia odbiór końcowy w serię małych odbiorów. Po każdej iteracji zespół pokazuje działającą część systemu, a klient zgłasza uwagi, zanim błąd zdąży się rozrosnąć. Efektem ubocznym jest lista zmian zgłoszonych w trakcie prac, która posłuży później do rozmowy o zakresie i budżecie.

Iteracje wymagają obecności osoby decyzyjnej po stronie klienta. Jeśli uwagi z demonstracji czekają na akceptację kilka tygodni, harmonogram przesuwa się bez winy wykonawcy, dlatego umowa powinna określać czas odpowiedzi na zgłoszone pytania.

Środowiska testowe i produkcyjne

Aplikacja przechodzi przez co najmniej dwa środowiska. Na środowisku testowym zespół sprawdza zmiany na kopii danych, a na produkcyjnym pracują użytkownicy. Wdrożenie z jednego do drugiego wykonuje skrypt, a nie ręczne kopiowanie plików, ponieważ skrypt jest powtarzalny i zostawia ślad w rejestrze zmian. Zmiany struktury bazy zapisuje się w transakcji, aby błąd w połowie skryptu nie zostawił bazy w stanie pośrednim.

BEGIN TRY
    BEGIN TRANSACTION;
    ALTER TABLE dbo.Zamowienie ADD KanalSprzedazy NVARCHAR(30) NULL;
    EXEC (N'UPDATE dbo.Zamowienie SET KanalSprzedazy = N''www'' WHERE KanalSprzedazy IS NULL');
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
    THROW;
END CATCH;

Przykład dodaje kolumnę i uzupełnia ją wartością początkową w jednej transakcji. Polecenie UPDATE jest wykonane dynamicznie, ponieważ nowa kolumna nie istnieje w chwili kompilacji partii. Nazwy tabeli i kolumny są przykładowe.

Migracja systemów i danych

Migracja jest drugim typowym projektem IT. Firma przenosi serwer, bazę danych albo całą aplikację na nową platformę, na przykład ze starego serwera na maszynę wirtualną lub do chmury. Zadanie wygląda prosto, dopóki nie trzeba zachować ciągłości pracy: użytkownicy oczekują, że w poniedziałek rano system działa tak samo jak w piątek.

Migrację do chmury Microsoft Azure wspiera usługa Azure Migrate, która pomaga ocenić gotowość i koszt hostowania obciążeń oraz przeprowadzić samo przeniesienie. Przegląd możliwości chmury od strony biznesowej znajduje się w tekście o wykorzystaniu chmury obliczeniowej, a ofertę SoftwareStudio w tym obszarze opisuje strona o oprogramowaniu w chmurze.

Serwer plików i uprawnienia

Przy przenoszeniu zasobów plikowych liczą się dwie rzeczy: kompletność plików i zachowanie list uprawnień. Narzędzie Robocopy z systemu Windows kopiuje dane wraz z informacją o zabezpieczeniach, a pierwsze uruchomienie wykonuje się w trybie listy, bez zapisu.

robocopy \\STARY\Dane D:\Dane /MIR /COPYALL /R:2 /W:5 /L /LOG:C:\Logi\migracja-dane.log

Przełącznik /L pokazuje, co zostałoby skopiowane. Po sprawdzeniu dziennika uruchamia się polecenie bez tego przełącznika. Warto pamiętać, że /MIR usuwa w miejscu docelowym pliki nieobecne w źródle, więc katalog docelowy musi być pusty albo przeznaczony wyłącznie do tej kopii.

Weryfikacja danych po przeniesieniu

Po przeniesieniu bazy porównuje się źródło z celem. Najprostsza kontrola liczy wiersze i sumę kontrolną dla każdej ważnej tabeli, a zapytanie uruchamia się na obu serwerach. Różnica w którejkolwiek wartości zatrzymuje przełączenie użytkowników.

SELECT COUNT(*)                       AS Wiersze,
       CHECKSUM_AGG(CHECKSUM(*))     AS SumaKontrolna
FROM dbo.Faktura;

Suma kontrolna nie zastępuje testów biznesowych, ale wychwytuje różnice, których nie widać w liczbie rekordów, na przykład zmienioną wartość w jednej kolumnie. Kolejnym krokiem jest przejście przez scenariusze pracy użytkowników na nowym środowisku.

Plan przełączenia i wycofania

Przełączenie użytkowników na nowe środowisko planuje się jako osobne zadanie, z godziną startu i osobami odpowiedzialnymi. Równolegle powstaje plan wycofania, który mówi, po jakich objawach wracamy do starego serwera i ile trwa ten powrót. Stary system pozostaje dostępny w trybie odczytu przez uzgodniony czas, żeby sprawdzić dane w razie wątpliwości.

Reguła: punkt wycofania określa się przed przełączeniem, a nie po pierwszej awarii.

Stare wersje bazy wymagają dodatkowej ostrożności. Dla wersji SQL Server, których wsparcie producenta się zakończyło, projekt migracji obejmuje też aktualizację silnika bazy, a sytuację opisuje dokument Microsoft o końcu wsparcia SQL Server. Kolejnym elementem jest test aplikacji, która korzysta z bazy, na nowej wersji silnika.

Model rozliczenia projektu

Sposób rozliczenia wpływa na to, kto ponosi ryzyko zmian zakresu. Przy ryczałcie za etap ryzyko ponosi głównie wykonawca, dopóki zakres pozostaje niezmienny. Przy stawce godzinowej ryzyko jest po stronie klienta, który płaci za faktyczny czas pracy. Model mieszany zestawia oba podejścia.

Przy zmianie zakresu obowiązuje procedura, która opisuje, kto zgłasza zmianę i kto ją wycenia. Każda zmiana ma wpis z zakresem i skutkiem dla terminu, a klient akceptuje go pisemnie. Bez takiej procedury wycena początkowa traci znaczenie po kilku tygodniach.

Rezerwa budżetowa i harmonogram

Rzetelna oferta zawiera rezerwę na ryzyka, których nie da się wyliczyć na etapie analizy, na przykład na niedokumentowany interfejs starego systemu. Rezerwę zapisuje się jawnie, razem z kwotą i zasadami jej wykorzystania. Podobnie harmonogram ma zapas na odpowiedzi klienta, ponieważ czas oczekiwania na decyzję jest równie realnym składnikiem projektu jak czas programowania.

Odbiór prac i przekazanie do utrzymania

Odbiór końcowy opiera się na scenariuszach testowych uzgodnionych na początku projektu. Klient wykonuje je na środowisku testowym, a wynik zapisuje w protokole z podziałem na błędy blokujące i uwagi drobne. Błąd blokujący wstrzymuje odbiór, uwaga drobna trafia na listę poprawek po uruchomieniu.

Do odbioru należy dokumentacja. Rzetelny wykonawca opisuje architekturę i decyzje technologiczne oraz sposób integracji z systemami zewnętrznymi w formie zrozumiałej także dla osób spoza działu IT. Taka dokumentacja ułatwia dalszy rozwój aplikacji, nawet jeśli w przyszłości zmieni się dostawca.

Opieka powdrożeniowa

Po uruchomieniu wykonawca monitoruje działanie aplikacji i usuwa błędy, a następnie rozwija kolejne funkcje zgodnie z potrzebami firmy. Zasady rozdziału zadań między rozwój a utrzymanie opisuje tekst o dedykowanych aplikacjach webowych a obsłudze IT. Warto od razu ustalić, czy poprawki w okresie po wdrożeniu są objęte ceną projektu, i jak długo.

Dostęp do danych w trakcie projektu

Wykonawca projektu ma wgląd w dane firmy, w tym w informacje o klientach. Zasady tego dostępu i zakres uprawnień poszczególnych osób spisuje się w umowie razem z terminem odebrania dostępów po zakończeniu prac. Rejestr operacji administracyjnych, z informacją o tym, kto i kiedy logował się na konto uprzywilejowane, bywa potrzebny przy wyjaśnianiu zdarzeń i nie oznacza nieufności wobec wykonawcy.

Wybór dostawcy projektu IT

Wybór dostawcy opiera się często na cenie i lokalizacji, choć o jakości współpracy decydują zapisy o sposobie pracy i zakresie odpowiedzialności. Bliskość biura ułatwia warsztaty na etapie analizy, ale nie zastępuje doświadczenia w budowie systemów klasy biznesowej. Oferty porównuje się więc według zrealizowanych projektów, a nie odległości od siedziby.

• Portfolio i referencje - przykłady projektów podobnych do planowanego oraz możliwość rozmowy z klientem, dla którego je wykonano.
• Elastyczność technologiczna - gotowość do pracy z systemami już działającymi w firmie oraz z ich interfejsami.

Ofertę SoftwareStudio w zakresie tworzenia systemów na zamówienie opisuje strona o oprogramowaniu na zamówienie. Uzupełnieniem są materiały o producencie aplikacji www i o integrowaniu aplikacji webowych, które pokazują, jak dostawca powinien opisywać zakres integracji.