pobrania tutaj [PDF 500kB]

Wspieranie powstania SPECYFIKACJI ISTOTNYCH
WARUNKÓW ZAMÓWIENIA (SIWZ) na wdrożenie i utrzymanie
systemu „Śląska Karta Usług Publicznych”.
CASE STUDY
CEL PROJEKTU
Projekt Śląskiej Karty Usług Publicznych ma na celu wdrożenie
informatycznego systemu ułatwiającego mieszkańcom Aglomeracji
śląskiej podróżowanie, parkowanie, kontakt z administracją,
dokonywanie mikropłatności i dziesiątek innych czynności dzięki
jednej, elektronicznej karcie. Ten projekt to coś więcej niż city card, to
zupełnie nowy standard współpracy między gminami i miastami
regionu. To ułatwienie dla mieszkańców Silesii.
Główną ideą przedsięwzięcia jest zbudowanie zintegrowanego
systemu pobierania i rozliczania płatności bezgotówkowych za usługi świadczone przez instytucje
samorządowe wraz z systemem informacji, pozwalającym na pozyskiwanie danych o popycie na
poszczególne usługi oraz relacjach między nimi zachodzących. Projekt związany będzie
z wprowadzeniem systemu płatności elektronicznych w jednostkach sektora publicznego.
Realizacja Projektu pozwoli na szeroką promocję społeczeństwa informacyjnego poprzez
upowszechnienie płatności bezgotówkowych. Projekt prowadzi i zarządza KZK GOP zwany
w dalszej części Zleceniodawcą
, który w trosce o najwyższą jakość nowego systemu
zaprosił nas do współpracy przy budowaniu SIWZ (Specyfikacja Istotnych Warunków
Zamówienia), a więc, mówiąc językiem informatyków - specyfikacji wymagań. Głównym celem
dokumentu jest wsparcie dla wyłonienia w drodze przetargu Wykonawcy systemu.
Ten współfinansowany z Europejskiego Funduszu Rozwoju Regionalnego projekt w ramach
Regionalnego Programu Operacyjnego Województwa Śląskiego warty jest 130 milionów złotych.
Potrzebuje on możliwie najlepszej specyfikacji, aby w możliwie najkrótszym czasie powstał
możliwie najlepszy produkt.
Należy zaznaczyć, że olbrzymia część specyfikacji została napisana już przez pracowników KZK
GOP, przed naszym zaangażowaniem. Nasza rola polegała na wbudowaniu jakości
oprogramowania i zwróceniu uwagi na błędy czy brak zapisów w SIWZ.
KORZYŚCI
Śląska Karta Usług Publicznych, jako elektroniczny instrument płatniczy, będzie pozwalała na
dokonywanie elektronicznych płatności za usługi publiczne. Karta będzie mogła służyć jako
identyfikator mieszkańca, w zakresie zgodnym z przepisami dotyczącymi ochrony danych
osobowych. Przewiduje się również użycie ŚKUP-u w roli nośnika certyfikatu podpisu
elektronicznego. Dedykowana aplikacja pozwoli na zbieranie danych niezbędnych do sprawnego
zarządzania instytucjami publicznymi, zaangażowanymi w funkcjonowanie systemu. Integralną
częścią Projektu będzie Portal Klienta – elektroniczna platforma udostępniająca i integrująca
usługi publiczne świadczone drogą online. Integracja usług publicznych polegać będzie na
umożliwieniu użytkownikowi systemu skorzystania z oferty instytucji akceptujących kartę ŚKUP
z poziomu Portalu Klienta, bez konieczności wielokrotnego logowania się na różnych stronach
internetowych. Schemat działania systemu prezentuje poniższy rysunek.
ZADANIA:
Zadaniem było zdefiniowanie SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA
(SIWZ) w taki sposób, aby jednocześnie ułatwić wytwórcy wytworzenie wysokiej jakości produktu
oraz z drugiej strony wspomóc zleceniodawców (KZK GOP) w łatwym jej odbiorze, w oparciu
o charakterystyki jakościowe produktu. Ważne było, aby przygotować w możliwie krótkim czasie
specyfikację zamówienia publicznego na dostawę, wdrożenie i utrzymanie systemu „Śląska Karta
Usług Publicznych”, która będzie najwyższej jakości.
METODA:
Ze względu na język naturalny stworzenia specyfikacji postawiono na kluczowe obszary
specyfikacji SIWZ z uwzględnieniem tych wskazanych przez Urząd Zamówień Publicznych
w dokumencie „Udzielanie zamówień publicznych na systemy informatyczne” (2009 rok).
Działania opierały się na serii rozmów z autorami specyfikacji i na wymianie komentarzy na
poziomie rewidowanego dokumentu.
W drodze prac udało się opracować dokument z uwzględnieniem poniższych (kluczowych)
aspektów jakości zarówno samego dokumentu, jak i systemu.
1) Uproszczenie i wyeliminowanie błędów specyfikacji
o Podstawową częścią prac było wyeliminowanie nieprecyzyjnych sformułowań, które
mogły wskazywać, że dane wymaganie jest niewymagane i stanowi jedynie możliwe
usprawnienie. Słowa „powinno”, „jest pożądane” zostały zarekomendowane do
usunięcia.
o Specyfikacja pokrywa szeroki wachlarz zagadnień, od budowy prostych urządzeń
elektronicznych, po aspekty związane z zarządzaniem ruchem w komunikacji
miejskiej. Ważne jest, aby również osoby nie mające doświadczenia w takich
obszarach były w stanie odpowiednio interpretować zapisy. Kluczowe okazało się
wyeliminowanie trudnych do zrozumienia sformułowań technicznych i zastąpienie ich
dużo prostszym językiem potencjalnego użytkownika. Okazało się, że można
o zagadnieniach mocno domenowych pisać przy pomocy tekstu rozumianego
również przez laików.
o W specyfikacji, która zawiera ponad 300 stron i tworzona jest przez wielu autorów,
bardzo trudno znaleźć zapisy sprzeczne. Dzięki prostemu mechanizmowi
wyszukiwania udało się połączyć obszary opisujące te same funkcje systemu, ale przy
pomocy niespójnych zapisów. Ważne jest, aby sami definiujący wymagania mieli
świadomość ważności spójności zapisów.
o Czy zdefiniowany zakres projektu jest wystarczający? Poprzez zadawanie pytań
można znaleźć odpowiedzi. Poważny problem, jaki został zdefiniowany, to to czy
ilość kart określonych jako aktywne w systemie spełni zapotrzebowanie odbiorców.
Rolą pytającego nie jest odpowiedzieć na pytanie, a zasiać niepewność co do zapisów.
Niepewność może pomóc autorom zdefiniować tak podstawowe parametr, jak
skalowalność w projekcie.
o Czy to zdanie jest rzeczywiście wymaganiem? Ze specyfikacji należy wyeliminować
zapisy, które nie są wymaganiami na wytworzenie systemu, a jedynie mało
precyzyjnym opisem lub też opinią na dany temat. Takie zdania wplecione w kontekst
SIWZ powodują więcej pytań niż przynoszą odpowiedzi.
o W wielu wypadkach instytucja zlecająca może zdefiniować wymagania niemożliwe do
implementacji. Rolą konsultanta będzie znalezienie takich zapisów i zasugerowanie
ich wyeliminowania. Chodzi nie tylko o klarowność samej specyfikacji, ale również
o zredukowanie możliwości podważania przez firmy uczestniczące w przetargu
jakości dokumentu. Takie działania z jednej strony dają firmom dłuższy czas na
przygotowanie oferty, a z drugiej - mogą znacząco wydłużyć czas potrzebny na
wyłonienie Wykonawcy.
2) Precyzyjne zapisy dla wymagań niefunkcjonalnych
o W systemie o takie złożoności, gdzie komunikują się dziesiątki różnych urządzeń
a wszystkie dane zapisywane są i sczytywane ze wspólnej bazy danych, kluczowe stają
się charakterystyki niefunkcjonalne. Czy da się zdefiniować czasy zapytań
i odpowiedzi dla każdego urządzenia? Mało prawdopodobne. Jak w takim razie
poradzić sobie z zapewnieniem jakości i wbudowaniem testowalności w specyfikację?
Należy przyjąć perspektywę wysokopoziomową i definiować czasy na poziomie
końcowych użytkowników. Na końcu liczy się jak szybko użytkownik otrzyma od
systemu odpowiedź na swoje, dowolne zapytanie.
o System przechowujący nie tylko dane użytkowników, ale będącego jednocześnie
systemem para bankowym ma duże potrzeby wbudowanego bezpieczeństwa.
Wymagania na bezpieczeństwo wymagają precyzyjnych i jednoznacznych zapisów.
Nie można sobie pozwolić na niedoprecyzowania metody kryptograficznej czy
metody kodowania komunikatów.
o Znalezienie uniwersalnej metody definiowania parametrów niefunkcjonalnych bez
podawania szczegółowych informacji okazało się możliwe dzięki normie ISO 9126
(“Software engineering — Product quality”). Opisane tam charakterystyki
oprogramowania oraz miary umożliwiły w sposób pełny pokryć charakterystykę
niefunkcjonalną oprogramowania.
o Zdefiniowanie wytycznych na PIN wydaje się być oczywiste jeśli nie przeanalizujemy
systemów bankowych i problemów jakie napotykają instytucje kiedy PIN musi być
opisany:
 Jak długi ma być PIN (4 czy może 6 znaków)?
 Czy PIN może zawierać „0000”, „1111” lub „1234”?
 W jaki sposób PIN ma być przekazany użytkownikowi?
 W jaki sposób PIN będzie podawany i jak często będzie to wymagane?
Z pozoru podstawowe zagadnienie bezpieczeństwa staje się tematem, który rozpisany
musi być na wielu stronach dokumentu zamówienia.
o System musi być jednocześnie funkcjonalny, bezpieczny i łatwy w użyciu. Chociaż te
charakterystyki w wielu wypadkach się wykluczają Zlecający przy pomocy konsultanta
podjął wysiłek znalezienie złotego środka. Zapisy SIWZ gwarantują, że system będzie
użyteczny i używalny.
o W wielu przypadkach przyszło nam analizować nie tylko system informatyczny, ale
również aspekty sprzętowe. Skomentowanie takich elementów jak klawiatury
w automatach pozwoliły autorom specyfikacji przyjąć perspektywę użytkownika
i zastanowić się jak poszczególne elementy systemu będą używane.
3) Zdefiniowanie użytkowników systemu
o Zakłada się, że użytkownikami systemu są mieszkańcy aglomeracji śląskiej, ale nie
możemy zapomnieć o setkach pracowników instytucji czy pracowników Zakładów
Komunikacji Miejskiej, którzy w swojej codziennej pracy będą musieli zagwarantować
płynną i bezawaryjną pracę systemu. Każdy element systemu wymaga szczegółów
opisujących zakres szkoleń dla użytkowników systemu od strony zaplecza (back
Office). Muszą one zagwarantować, że obsługa systemu będzie w stanie używać
system płynnie i z pełnym zrozumieniem ich funkcji.
o Dostępność dla osób niepełnosprawnych jest tematem trudnym i w wielu
przypadkach niemożliwym do zrealizowania. Konstytucja gwarantuje każdemu
obywatelowi równe traktowanie bez względu na kolor skóry, wyznanie czy właśnie
niepełnosprawność. Trudno zagwarantować, że system będzie w stanie wspierać
każdego użytkownika bez względu na typ niepełnosprawności. Dzięki specjalnym
zapisom specyfikacja wymusza ułatwienia dla osób z ograniczonym postrzeganiem
czy z niepełnosprawnością ruchową, ale nie jest w stanie opisać każdej sytuacji
i każdego typu niepełnosprawności.
o Kluczem do kontroli przepływu sterowania i zarządzania aplikacją są poziomy
autoryzacji. Wiadomo, że nie każdy użytkownik może wykonać każdą operację.
Ważne jest więc, by świadomie przyznawać prawa użytkownikom, czym gwarantuje
się z jednej strony łatwość użycia systemu, a z drugiej bezpieczeństwo
przechowywanych danych.
4) System w fazie testowania
o Trudno jest zdefiniować, czy i kiedy firma wytwarzająca oprogramowanie ma
kompetencje w danym obszarze informatycznym. Jedyną możliwością weryfikacji jest
z punktu widzenia Zlecającego zdefiniowanie wiedzy i wymaganych certyfikatów
Wykonawcy w zakresie testów oprogramowania. Wiedzy nie da się sprawdzić w
przetargu, certyfikaty tak. Pomimo tego, że staramy się nie promować wiedzy
teoretycznej, to wymuszenie posiadania kompetencji na poziomie certyfikatów wydaje
się być wymagane.
o Użytkownicy systemu wielokrotnie zaskoczą nas swoimi działaniami. Wykonają
czynności, jakich nie bylibyśmy w stanie przewidzieć i doprowadzą system do stanu,
w jakim nigdy nie powinien się znaleźć. Ograniczeniem dla tego poważnego ryzyka
jest odpowiednie zdefiniowanie negatywnych scenariuszy użycia aplikacji. Nie
jesteśmy w stanie wyeliminować wszystkich błędów, ale możemy wyeliminować te,
które wydają się być najbardziej prawdopodobne do znalezienia już w fazie
użytkowania oprogramowania.
o System ma wbudowane procesy wykonywane w punktach obsługi klienta (POK)
i pasażera (POP). Są to gotowe scenariusze testowe na poziomie przypadku
rzeczywistego użycia aplikacji. Te bardzo wartościowe informacje ułatwiają
zrozumienie, jak aplikacja będzie użytkowana na różnych poziomach jej obsługi,
i mogą być podstawą do przypadków testowych
5) System w fazie utrzymania
o W którym momencie i w jakich okolicznościach system może zostać przekazany
Zlecającemu do odbioru i kiedy można uznać, że jest gotowy? Zapisy te są o tyle
ważne, że przed wdrożeniem aplikacja musi ona zostać dobrze przetestowana.
Oznacza to, że kluczową rzeczą są zapisy specyfikujące zarówno procedurę odbioru
jak i kryteria, które muszą zostać spełnione aby system został uznany za gotowy do
wdrożenia. Kryteria te zostały bardzo precyzyjnie opisane na poziomie zamówienia
i charakterystyk jakie oprogramowanie musi spełnić.
o Kluczowy dla tego obszaru wydaje się czas, kiedy nastąpi przekazanie systemu po jego
wstępnej fazie utrzymania. Czy Zlecający zagwarantował sobie w zapisach specyfikacji
odbiór na tyle szczegółowo, że pełny know how zostanie do niego przekazany? Nie
mówimy tu jedynie o kodzie źródłowym, dokumentacji czy architekturze. Mówimy
o ludziach, którzy będą w stanie samodzielnie zarządzać system po przekazaniu.
Proste zapisy w umowie dotyczące miar mają sprawić, że Wytwórca oprogramowania
przeszkoli pracowników Zlecającego (lub inne wskazane przez niego osoby) na
okoliczność wszelkich działań utrzymaniowych.
o Pod znakiem zapytania postawiono audytowalność systemu. Czy odbiorca po
przekazaniu oprogramowania będzie miał łatwość samodzielnego utrzymania kodu?
Niepoprawne zapisy umowy mogą doprowadzić do patologicznej sytuacji, w której
jedynie autorzy oprogramowania będą w stanie go aktualizować i korygować,
uzależniając w ten sposób Zlecającego od siebie.
o Z dużym prawdopodobieństwem można założyć, że system będzie pod ciągłym
atakiem osób pragnących w niepowołany sposób uzyskać dostęp do danych
użytkowników lub do środków zgromadzonych na ich kontach. Nie możemy jednak
założyć, że ataki będą jedynie z zewnątrz. Czy system zabezpieczony jest przed
nadużyciami? Czy dobrze zdefiniowano potencjalne niebezpieczeństwa płynące ze
strony nieuczciwych pracowników obsługujących system?
o Nie można zapomnieć o prostych czynnościach w fazie samego funkcjonowania
oprogramowania. Jest naturalne, że oprogramowanie musi być zabezpieczone przy
pomocy zapasowego Centrum Przetwarzania Danych (patrz poniższy rysunek). Czy
jednak częstotliwość synchronizacji jest wystarczająca? Tu po raz kolejny konsultant
badający wymagania ma za zadanie sformułować pytanie, na które odpowiedź musi
znaleźć autor SWIZ.
o Systemy o dużej liczbie komunikujących się komponentów muszą mieć zdefiniowane
wytyczne na wymianę danych między elementami systemu. Mówimy przede
wszystkim o wspólnym formacie danych, plików, protokołów. Zadaniem konsultanta
było określenie, czy każdy moduł będzie w stanie komunikować się z innym, bez
potrzeby dodatkowych urządzeń tłumaczących czy konwertujących.
o System musi zostać okresowo wyłączony. Czy zlecający przewidział taką potrzebę?
Nie istnieje oprogramowanie niezawodne w 100% i nie ma oprogramowania, które
nie musi podlegać w krótszym, czy też dłuższym okresie czasu, zmianom. Kluczową
sprawą jest więc zdefiniowanie, kiedy, jak i w jaki sposób system będzie wyłączany.
To czy będzie to 2:00 w nocy czy też 15:00 i czy system będzie witał użytkowników
komunikatem o czasowej niedostępności, czy może czarnym ekranem, ma znaczenie.
o Aplikacja zostanie dostarczona przez wykonawcę z błędami, co wynika z praktyki
wytwarzania oprogramowania. Wiedząc, że pojawią się błędy w oprogramowaniu,
należy precyzyjnie zdefiniować jak będą one do Wykonawcy przekazywane i,
w zależności od poziomu krytyczności, jak szybko będą poprawione. Dalszym
aspektem jest to, czy błąd będzie podstawą do odrzucenia całości systemu, czy może
wystarczy wgranie zwykłej poprawki do już zainstalowanej wersji testowej.
REZULTAT
Specyfikacja Istotnych Warunków Zamówienia jest nie tylko specyfikacją wymagań, ale również
dokumentem opisującym współpracę między Wykonawcą i Zlecającym. Ufając, że każdej ze stron
zależy na przygotowaniu możliwie najlepszego rozwiązania, wiarę należy poprzeć dobrze zawartą
umową.
W rezultacie prac powstała specyfikacja, która pozwoli Wykonawcy na przygotowanie wysokiej
klasy oprogramowania, a Zlecającemu - na świadomość kontroli nad jakością produktu.
Dziękując za możliwość współtworzenia Specyfikacji Istotnych Warunków Zamówienia, życzymy
obu stronom zakończenia całego projektu sukcesem.
O autorach
testerzy.pl i wymagania.net to marki należące do firmy 21CN.
wymagania.net świadczą usługi konsultingowe w zakresie procesu identyfikacji
i dokumentowania wymagań, analizy biznesowej, analizy systemowej oraz wyboru narzędzi.
Oferta wymagania.net obejmuje usługi szkoleniowe z zakresu zarządzania wymaganiami, audyt
procesu analizy biznesowej/systemowej oraz coaching.
testerzy.pl działają w obszarze definiowania, oceny i usprawnienia procesu testowego,
automatyzacji, zarządzania ryzykiem, wyboru właściwych narzędzi i wdrożenia ich do organizacji.
W ofercie testerzy.pl znajdują się usługi szkoleniowe z zakresu testowania.
21CN Radosław Smilgin
ul. Sokolska 33/173
40-086 Katowice
kom. 503 074 389; 798 793 289
NIP 583-276-92-97
REGON 241132628
W PRZYGOTOWANIU CASE STUDY UŻYTO:
•
•
•
•
•
•
•
•
•
Materiały ze strony: http://kzkgop.org/skup/
SIWZ dostępny na stronie: http://bip.kzkgop.pl/siwz/2010/skup/siwz__.pdf
Załączniki do SIWZ: http://bip.kzkgop.pl/siwz/2010/skup/zalaczniki_skup.zip
Rekomendacje udzielania zamówień publicznych na systemy informatyczne, Urząd
Zamówień
Publicznych
2009r;
plik:
Rekomendacje_UZP
ws._zamowień_na_systemy_informatyczne.pdf – wersja papierowa i elektroniczna
ISO/IEC 9126 – Analiza modelu jakości produktów programowych – Andrzej
Kobyliński; plik: analiza_ISO9126.pdf – wersja elektroniczna
Systemy komputerowe – Funkcjonalność; Rafał Bartoszewicz, Krzysztof Diduch, Kinga
Frączyk, Joanna Mrożek, Artur Pęczak; Politechnika Wrocławska - Wrocław 2007; plik:
Systemy komputerowe funkcjonalnosc.pdf – wersja elektroniczna
Słownik wyrażeń związanych z testowaniem; plik: slownik-terminow-testowych-2-0-ver-099.pdf – wersja elektroniczna
Standard for Software Component Testing; 27 April 2001; plik: Component Testing.pdf –
wersja elektroniczna
Materiał prasowy:
http://katowice.gazeta.pl/katowice/1,35063,8575872,Ten_projekt_ulatwi_zycie_mieszkan
com_calej_aglomeracji.html