Wszystko płynie. Każdy informatyk dobrze o tym wie. Jeżeli jego środowisko pracy jest w przybliżeniu takie, jakim opisują je statystyki, to co dwa lata warsztat ten przechodzi gruntowne przeobrażenie. I choć z jednej strony marzymy o stabilności swoich narzędzi i klniemy na czym świat stoi, ilekroć po ich uaktualnieniu musimy się uczyć od nowa skrótów klawiaturowych i oswajać z nowym rozplanowaniem okien, to jednak wiemy, że ignorując nowości odcielibyśmy się od postępu w informatyce. Dlatego, chcąc nie chcąc, musimy zmieniać środowisko swojej pracy.

Budowniczy dziesięciopiętrowego bloku nigdy nie zaakceptowałby faktu, że na wysokości trzeciego piętra technologia jest zmieniana z wielkiej płyty na stalowe dźwigary, a przy budowie siódmego architekt zmienił koncepcję parteru i pierwszego piętra. Tak jednak dzieje się w informatyce i nic na to nie poradzimy. Postęp w naszej dziedzinie jest jej immanentną cechą i musimy za tym postępem nadążać. Tak jak twórca kompilatora, który stosujemy, co pewien czas wprowadza jego nową wersję, tak samo klient oczekuje, że co jakiś czas dostarczymy mu nowy, lepszy produkt.

Zmiana nie jest niczym strasznym, jest normalnym etapem funkcjonowania systemu informatycznego. Przygotowując się do zmiany, należy rozważyć następujące jej aspekty:

Czy zmiana nie jest na tyle poważna, że bardziej opłaca się stworzyć nowy produkt?

Czy lepiej zmienić istniejące fragmenty systemu, czy też dobudować nowy moduł, komponent?

Czy zmiana ma dotyczyć wszystkich klientów korzystających z systemu, czy jedynie ich części, a więc czy z jednego produktu robią się dwa produkty?

Jak zmiana wpłynie na wydajność systemu: poprawi ją, pogorszy czy pozostawi bez zmian?

Jaki jest konieczny zakres modyfikacji elementów towarzyszących programowi, a więc w dokumentacji technicznej, w dokumentacji użytkowej, w programach szkoleń itp.?

Rodzaje zmian wymagań

1. Zmiana prawa

W pewnych dziedzinach (np. w księgowości lub sprzedaży) tworzy się oprogramowanie wg konkretnych przepisów obowiązujących w danym momencie. Ich zmiana sprawia, że klient po prostu nie może stosować starego programu, bo nie może ryzykować, że będzie miał kłopoty w razie kontroli. Vacatio legis, które ustawodawca w takiej sytuacji przewiduje, musi wystarczyć, żeby zmiany wprowadzić, przetestować i wdrożyć. Zmiany te muszą być zgodne z nowymi przepisami i eliminować poprzedni sposób rozwiązania tego samego problemu. Jeżeli nie wywiązano się z tych trzech czynności w przewidzianym terminie, to lepiej było w ogóle nie sprzedawać poprzedniej wersji. Klienci takie opinie przekazują sobie z ust do ust i można być spokojnym, że nikt od takiego dostawcy już nic nie kupi.

2. Rozszerzenie wymagań ilościowych

Załóżmy, że klient na tyle dobrze prowadzi biznes, iż znacznie wzrosły jego potrzeby. Na przykład, w związku z zakorkowaniem się miasta, sklep rowerowy, dla którego stworzono aplikację, zwiększył swoją sprzedaż kilkakrotnie. Taka zmiana może wymusić uaktualnienie bazy danych, aby pola odpowiadające kwotom mogły pomieścić większą liczbę cyfr, rozszerzyć szerokość pól formatek ekranowych, wprowadzić dodatkowe zestawienie i statystyki itp. Generalnie zmiana wymagań ilościowych jest najprostszą zmianą. W rozdziale Implementacja napisałem, że powinno dokonać się sprawdzenia skalowalności swojej aplikacji - jeżeli zrobiono to rzetelnie, zmiana wymagań ilościowych nie powinna być trudna do przeprowadzenia. Należy pamiętać, że ulepszenie "potencjału" aplikacji odbywa się z korzyścią nie tylko dla tego konkretnego klienta, którego wymagania zmieniły się, ale dla wszystkich potencjalnych klientów.

3. Zmiana profilu lub funkcjonalności

Nasz klient nieco zmienił profil działalnoś-ci i teraz chce, żeby funkcjonalność (bądź tylko akcenty) w aplikacji były przesunięte nieco inaczej. Jeżeli ten klient jest jedynym, który używa tego programu, można taką zmianę wykonać. Natomiast jeżeli miałoby to rykoszetem uderzyć w innych użytkowników tej aplikacji, to należy raczej klientowi zaproponować wykonanie nowego programu. Zmiana profilu aplikacji zwykle wymusza przebudowę jej modeli danych i algorytmów. To zawsze wymaga nowej tury testowania, tak samo wyczerpującej, jak działo się to przed jej wprowadzeniem na rynek. Generalnie zmiana profilu jest najtrudniejszą ze zmian i - zanim się na nią zgodzimy - należy dokładnie poznać konsekwencje, jakie będzie to miało dla całości produktu.