• Aktualności • Zleć napisanie programu • Gotowe produkty - sklep • Kontakt • Strona główna

Specyfikacja zamówienia



Przystępując do pracy, na samym początku należy określić problem i jego zasięg, oraz wymagany rezultat jaki musi spełnić projektowany system. Z tego względu konieczne jest określenie specyfikacji zamówienia, by móc je poprawnie zrealizować.
Ponieważ preferujemy jawne i czytelne ustalenie warunków pracy i zlecenia, oraz praw przysługujących obu stronom, specyfikacja dostarczana przez klienta powinna być wystarczająco jasna i czytelna, uściślająca założenia projektu. Założenia ta opisaliśmy na poniższej stronie w punktach.

W poniższym tekście będzie odniesienie do specyfikacji projektu informatycznego (oprogramowania).

Po pierwsze: Specyfikacja powinna być uporządkowana.

Trudno o efektywne podejście do realizacji zlecenia, jeśli na samym początku nie ma zdefiniowanych jasnych reguł i następują mniej lub bardziej udane próby ustalenia "o co chodzi klientowi". Aby móc opracować profesjonalne rozwiązanie, należy posiadać wystaraczająco szczegółowy, logiczny i spójny spis wymagań (żądanych funkcji). Oczywiście nie chodzi tutaj o dostarczanie tomów dokumentacji, lecz zwykły spis wymaganych funkcjonalności w punktach, a w przypadku większej ich ilości podział na sensowne działy i przyporządkowane do nich listy punktów.

Jeśli klient nie jest w stanie (z różnych powodów) określić takiej specyfikacji - możemy podjąć się zlecenia opracowania stosownego dokumentu. Jednakże usługa ta wymaga określenia problemu jaki trzeba rozwiązać oraz dobrania sposobu i metodologii jego rozwiązania. Ponieważ jest to proces wymagający prac analitycznych, pochłaniający czas projektanta, z tego względu taka usługa jest płatna.

Po drugie: Precyzja opisów - nie zostawiać miejsca na domysły.

W przypadku pojawienia się domysłów, projektant bądź programista musi zdecydować w jaki sposób zakodować dane rozwiązanie. Zwykle wdrożone w ten sposób rozwiązanie zadowala potrzeby klienta. Jednak nie ma 100% gwarancji, iż zastosowane rozwiązanie będzie na pewno odpowiadać klientowi. Dlatego też jeśli specyfikacja obejmuje i opisuje sposoby rozwiązywania napotkanych po drodze problemów - nie ma miejsca na domysły i wiadome jest w jaki sposób ma działać programowana funkcjonalność. Z oczywistych względów oszczędzi to klientowi rozczarowań w przypadku korzystania z wdrażanych rozwiązań. Z drugiej strony, im więcej dana funkcjonalność ma wymagań, tym kosztowniejsze jest jej wprowadzenie i testowanie, w szczególności, w przypadku gdy użytkownik chce zakupić rozwiązanie z gwarancją (która musi wtedy objąć wszystkie szczegółowe opisane działania).

Należy pamiętać, iż w przypadku gdy użytkownik zdecyduje się uogólnić działanie funkcjonalności (np. ukrywając szczegóły, które mogą wpłynąć na działanie funkcji, aby zmniejszyć koszt wyceny), wszelkie reklamacje odnośnie uogólnionych funkcjonalności będą rozpatrywane na naszą korzyść. Może się wówczas okazać, iż użytkownik będzie musiał dopłacić dodatkowo za wprowadzenie poprawek, by rozwiązanie pracowało pod konkretnymi szczególnymi warunkami, skoro nie zostały one doprecyzowane wcześniej.

Należy także pamiętać, iż powoływanie się na wszelkie zewnętrzne instrukcje bądź normy, jeśli nie są one załączane do specyfikacji, również może nie być uwzględniane przy realizacji zamówienia. Wszelkie zewnętrzne materiały muszą być również dostępne dla nas, abyśmy mogli zapoznać się ze szczegółami zlecenia.

Oczywistą sprawą jest też fakt, iż podstawą do opracowania zlecenia napisania oprogramowania jest jego konkretna specyfikacja. Nawet jeśli w tej specyfikacji nastąpi powołanie się na konkretne normy bądź instrukcje, istotne jest to, czy dana funkcjonalność, oparta o normę/instrukcję, jest opisana w specyfikacji. Jedynym i najistotniejszym dokumentem będącym podstawą do realizacji zamówienia jest właśnie specyfikacja, a nie inne zewnętrzne wytyczne. Pomimo, iż wygodne jest opisane w instrukcji: "funkcjonalność zgodna z punktem X.Y normy/wytycznej", jednakże nie jest to prawidłowo opisana funkcjonalność, ponieważ zewnętrzna norma/instrukcja wcale nie musi szczegółowo tego typu funkcjonalności opisywać, ani też opisywać jej wpływu na inne elementy projektowanego systemu.

Po trzecie: brak sprzeczności i realizm zakładanych rozwiązań

Dobra specyfikacja sama w sobie powinna być spójna, nie zostawiać miejsca na domysły. Co za tym idzie - poszczególne jej punkty nie powinny być sprzeczne ze sobą. Jeśli klient określił technologię wykonania, powinna ona być możliwa do wdrożenia dla danego problemu. W przeciwnym wypadku (brak technicznych możliwości) specyfikacja będzie tylko listą niewykonalnych życzeń, która w oczywisty sposób nie zostanie uwzględniona w zamówieniu. Jeśli klient nie jest w stanie określić realizmu stosowanych rozwiązań - możemy się podjąć (odpłatnej) ich analizy, bądź w odpowiedzi na zamówienie nakreślić z grubsza ograniczenia danej technologii.


Na koniec: opisać żądaną jakość wykonania, zakres gwarancji, opieki serwisowej, terminy, prawa

Sama specyfikacja niekoniecznie musi określać zakres gwarancji oraz opieki serwisowej. Dlatego też na jej końcu, bądź też w zamówieniu należy sprecyzować:
  • jakiej gwarancji oczekuje klient - czy produkt ma mieć pełną gwarancję (poprawki lub aktualizacje lub modernizacje), czy też poprawki, aktualizacje lub modernizacje mają być świadczone w ramach nowych, odrębnych zleceń? Z reguły im większy zakres gwarancji, tym większy koszt danego rozwiązania. Z kolei rezygnacja z gwarancji - będzie najtańszym rozwiązaniem, lecz wszelkie aktualizacje będą traktowane jako nowe i dodatkowo odpłatne zlecenia.
  • jakiej opieki serwisowej oczekuje klient - opieka serwisowa to element posprzedażowy, który może integrować obsługę telefoniczną bądź elektroniczną użytkownika końcowego (np. helpdesk). Może to być np. pomoc przez telefon lub mail, z gwarantowanym czasem lub jakością obsługi. Opieka serwisowa może też obejmować wprowadzanie doraźnych dodatkowych rozwiązań, które nie będą dodatkowo płatne.
    Podobnie jak w przypadku gwarancji, im większy poziom opieki serwisowej tym większe koszty finalnego rozwiązania.
  • jakiej jakości oczekuje klient - jest oczywiste, że klient zawsze będzie oczekiwał najwyższej jakości i oczywiście w miarę możliwości ta jakość będzie przez nas oferowana i zapewniana. Jest jednak pewne, iż wysoką jakość wykonania (a także serwisowania) można zapewnić tylko przy odpowiednich nakładach, co skutkuje oczywiście większym kosztem systemu i dłuższym czasem jego powstawania. W tym przypadku klient nie powinien pisać "wysoka jakość wykonania", lecz opisać co rozumie pod pojęciem "wysoka jakość". Tylko wtedy będziemy mogli wczuć się w potrzebę klienta i dobrać odpowiednie techniki pracy do zlecenia i tę jakość zapewnić.
  • ramy czasowe - czyli popularny deadline, który nie może być przekroczony. Innymi słowy klient musi określić czas, jaki chce przeznaczyć na rozwój rozwiązania i jego przyszłe serwisowanie. W przypadku większych systemów czas musi być odpowiednio dłuższy, aby było możliwe fizyczne wykonanie projektu.
  • prawa - np. w zakresie praw autorskich majątkowych - czy jeśli życzy sobie dedykowanego rozwiązania, czy życzy sobie, aby rozwiązanie było dostępne tylko dla niego, czy też może być sprzedawane innym podmiotom. Domyślnie zakupując system informatyczny, użytkownik otrzymuje licencję, uprawniającą go do wykorzystania oprogramowania zgodnie z określonymi prawami i zasadami, na określonym polu eksploatacji. Licencja ta jednak nie pozwala na przeniesienie praw, wynikających z licencji. Pomimo, iż jest możliwe uzgodnienie z nami indywidualnej treści docelowej licencji (także wyłącznej), zwiększa to w oczywisty sposób koszt finalnego rozwiązania.

Należy pamiętać, iż specyfikacja w pewnym momencie zostanie zamknięta - i nie będzie można dodać do niej dodatkowych rzeczy (chyba że za dodatkową opłatą). Dopiero na podstawie zamkniętej i zaakceptowanej przez nas specyfikacji będzie możliwe wykonanie systemu. w przypadku dosyłania fragmentów specyfikacji, za dzień zamknięcia specyfikacji zostanie uznana data przesłania ostatniego fragmentu specyfikacji. Także zmiany lub uszczegółowienia wcześniej przesłanych punktów będą traktowane jako fragmenty (zmian) specyfikacji. Ich przesłanie po etapie zamknięcia specyfikacji nie będzie skutkować ich uwzględnieniem, bądź też zostaną one poddane dodatkowej wycenie.
© 2011-2018 SkyRaster Blog firmowy. Wszystkie prawa zastrzeżone. Korzystanie ze strony lub produktów oznacza akceptację regulaminu i polityki prywatności.