Kwestia komunikacji

W zależności od stopnia wdrożenia użytkownika w metodologię projektowania systemów informatycznych pomocne jest zastosowanie standardów oferowanych przez narzędzia CASE (Computer Aided Software Engineering), np. notacji "use case". Rolę bufora w komunikacji pomiędzy użytkownikami oraz informatykami pełnią tzw. analitycy biznesowi, którzy potrafią zrozumieć potrzeby użytkowników, w odpowiedni sposób je udokumentować, a następnie przełożyć na informacje niezbędne do przygotowania projektu technicznego, który z kolei będzie specyfikacją szczegółowych wymagań do implementacji.

Poziom szczegółowości specyfikacji zależy od tego, w jakim zakresie można pozostawić dowolność rozwiązania projektantom systemu, a na ile szczegółowo musi o nim zadecydować użytkownik. W przypadku gdy implementacja rozwiązania opiera się na predefiniowanych obiektach systemu narzędziowego, wręcz nie jest wskazane, aby użytkownik określał wymagania w zakresie narzuconych już elementów funkcjonalnych, ponieważ zmiana w standardowych rozwiązaniach generuje dodatkowe koszty, zwiększa ryzyko wystąpienia błędów, a także rodzi problemy w utrzymaniu systemu. Jeśli dla użytkownika istotny jest dostęp do określonej funkcji, na przykład wyświetlenie informacji (zawierających ściśle określone dane) o kontrahentach, którzy zalegają z płatnością, nie musi on definiować, w jaki sposób dana funkcja ma być wywoływana w systemie, jak będzie wyglądał ekran zawierający te dane, ponieważ decyzję w tym zakresie należy pozostawić projektantom. W tym przypadku można użytkownikowi pozostawić jedynie wybór alternatywnych predefiniowanych rozwiązań, np. różne formy prezentacji wykresów, symboli czy innych elementów interfejsu użytkownika.

Z definiowaniem potrzeb użytkowników łączy się także zarządzanie zmianą ich wymagań w trakcie tworzenia oprogramowania. Zmiany te nie są spowodowane niezdecydowaniem użytkowników, lecz są naturalną konsekwencją zmian w otoczeniu biznesowym. Jednak zazwyczaj nie występują one z dnia na dzień, dlatego ważne, by przed rozpoczęciem prac nad rozwiązaniem informatycznym upewnić się, czy firma planuje zmiany, które mogą wpływać na rozwiązanie informatyczne. Innym rozwiązaniem służącym zarządzaniu zmianą jest planowanie budowania rozwiązań informatycznych w sposób modułowy, przyrostowy, aby proces ich realizacji trwał nie dłużej niż cykl wprowadzania zmian w organizacji - np. ok. 6 miesięcy.

W przypadku podejścia modułowego już na etapie początkowym planuje się podstawowe założenia do funkcjonalności pełnego rozwiązania informatycznego, które następnie są uszczegóławiane oraz korygowane o zaistniałe zmiany przed rozpoczęciem prac w kolejnych modułach. Sposób wprowadzania zmian do wymagań powinien zostać ustalony przed rozpoczęciem prac projektowych i poddany określonej procedurze. Podejmowaniu decyzji o wprowadzeniu zmiany powinna towarzyszyć analiza jej wpływu na koszt oraz harmonogram projektu. Zakładając ograniczony budżet i harmonogram realizacji, nierzadko na etapie definiowania potrzeb wymagane jest określenie priorytetów potrzeb oraz podjęcie na tej podstawie z użytkownikami kompromisu dotyczącego sposobu opracowania rozwiązań, rezygnacji z pewnej funkcjonalności lub jej uproszczonej realizacji.

Po opracowaniu wymagań do systemu, kolejne etapy w procesie tworzenia programowania są realizowane przy niewielkim udziale użytkowników na zapleczu projektowym (o ile specyfikacja wymagań została opisana w sposób kompletny). Do uniknięcia ryzyka niespójności pomiędzy różnymi elementami systemu, które realizują poszczególni członkowie zespołu, ważne jest ustalenie wzajemnych powiązań między tymi elementami, by wprowadzenie zmiany w jednym miejscu w projekcie mogło być uwzględnione jednocześnie w innym, powiązanym obszarze. Zarówno dla efektywności implementacji, jak i utrzymania systemu ważne jest korzystanie w jak największym stopniu ze wspólnych zbiorów obiektów i modułów. Czynnikiem, który ma w tym przypadku niewątpliwe znaczenie dla jakości oprogramowania, jest ustalenie koncepcji budowy systemu, zasad wewnętrznej komunikacji w zespole oraz przestrzeganie przyjętych standardów realizacji oraz dokumentowania prac. Istotną rolę na tym etapie odgrywa kontroler jakości pełniący także funkcję koordynatora spinającego pojedyncze elementy w spójną całość, który weryfikując produkty prac sprawdza ich kompletność, wewnętrzną zgodność, poprawność i stosowanie przyjętych standardów.

W zależności od złożoności projektu, do zespołu projektowego może zostać włączony kontroler zewnętrzny (reprezentujący odbiorcę oprogramowania) lub wewnętrzny dla całego projektu lub jego poszczególnych obszarów. Kontrolerzy podlegają bezpośrednio sponsorowi projektu (kontroler zewnętrzny) lub kierownikowi projektu (kontroler wewnętrzny). Niekiedy kontrolerzy jakości zaangażowani w różne obszary tworzą dodatkowy zespół roboczy raportujący do kierownika lub sponsora projektu.

Testy naoczne

Prezentacja prototypu oraz testów rzeczywistego oprogramowania to etap konfrontacji wymagań użytkowników z uzyskanym produktem. Prototyp ułatwia weryfikację potrzeb użytkowników, gdy nie są one sprecyzowane na tyle dokładnie, aby na ich podstawie przygotować gotowe oprogramowanie. Jest to efektywne narzędzie weryfikacji potrzeb, w przypadku gdy system narzędziowy jest zbudowany z elementów, które względnie niewielkim nakładem pracy można dostosować do potrzeb użytkowników. Przygotowanie prototypu jest alternatywą dla szczegółowej specyfikacji wymagań użytkowników. W zależności od systemu narzędziowego może to być bardziej efektywny i tańszy sposób niż opracowanie szczegółowej dokumentacji.

Faza testów to etap, w którym jest identyfikowanych najwięcej błędów, często będących kumulacją błędów powstałych we wcześniejszych fazach prac nad systemem. Problemem, na który często napotykają użytkownicy przy realizacji testów, jest niska jakość komponentów przekazywanych do przetestowania. Zespół projektowy najczęściej pod presją czasu przenosi ciężar sprawdzenia elementarnej poprawności (np. sprawdzenie, czy z poziomu formatki ekranowej można uruchomić określone funkcje) na użytkowników. To powoduje, że występują podstawowe błędy, które uniemożliwiają przeprowadzenie testów użytkowników wg zakładanego scenariusza. W konsekwencji liczba iteracji związanych z przeprowadzeniem testów i wprowadzeniem korekt znacznie się zwiększa, przez co oprogramowanie nie może być zakończone w przewidywanym czasie oraz zaplanowanym budżecie.

W realizacji testów dla monitorowania jakości oprogramowania pomocne jest prowadzenie rejestru przeprowadzonych testów oraz zidentyfikowanych błędów, opisujących priorytet błędu, krytyczność jego usunięcia, działania, które należy wykonać w celu jego naprawienia oraz potwierdzenie jego rozwiązania. Dzięki takiej rejestracji powtarzane scenariusze testów można ograniczyć tylko do wybranych elementów, wymagających sprawdzenia, co znacznie oszczędza czas testowania oprogramowania.

Jakość oprogramowania jest integralnie powiązana z budżetem oraz harmonogramem projektu. Z tego względu brak odpowiedniego zarządzania jakością przekłada się na zwiększenie kosztów dostarczenia oprogramowania oraz wydłużenie czasu jego realizacji. Jakość ta jest także istotnym czynnikiem mającym wpływ na zwrot z kapitału zainwestowanego w jego budowę i wdrożenie. Zwrot jest tym większy, im większe są korzyści, które firma uzyskuje w wyniku zastosowania rozwiązania informatycznego, a więc im wyższa jakość oprogramowania. W przypadku, gdy oprogramowanie nie dochodzi do fazy wdrożenia lub gdy po wdrożeniu nie jest ono wykorzystywane, nakłady związane z jego wytworzeniem są zmarnowane praktycznie całkowicie.

Na zarządzanie jakością oprogramowania należy więc spojrzeć pod kątem rachunku ekonomicznego. Z jednej strony przynosi ono oszczędności związane ze zwiększeniem efektywności dostarczania rozwiązania informatycznego, a z drugiej, wymaga dodatkowych działań, a więc wydłuża czas i generuje dodatkowe koszty.

Nie ma jednej reguły określającej, jaki jest słuszny kompromis w odpowiednim wyważeniu tych dwóch aspektów. Spotyka się dwa skrajne poglądy dotyczące tego zagadnienia. Niektórzy twierdzą, że jakość nic nie kosztuje, argumentując, że korzyści uzyskane po wdrożeniu właściwego zarządzania jakością zawsze przewyższają jego koszty. Inni natomiast wyznają pogląd, że nie można dążyć do uzyskania wysokiej jakości za wszelką cenę, ponieważ może to zachwiać równowagę w realizacji innych celów projektu związanych z czasem oraz budżetem.