Specyfikacje funkcjonalne

Jak się nie ma, co się lubi – to się lubi, co się ma… Narzędzia wspomagające tworzenie specyfikacji funkcjonalnych mogą prowadzić do osiągnięcia sukcesu podczas implementacji projektów związanych z automatyzacją.
Jeżeli nie wiesz, jasno nie określisz, czego potrzebujesz i nie udokumentujesz tego, wtedy ktoś dostarczy ci to, czego według niego potrzebujesz – niekoniecznie to, o co ci naprawdę chodzi. Inżynierowie procesu czasami błędnie uważają, że inżynierowie sterowania będą w stanie opracować projekt automatyzacji/sterowania dyskretnego na bazie diagramów „struktury obiektów i oprzyrządowania” (z angielskiego: piping and instrumentation diagrams P&ID – schematów „rurowych” i oprzyrządowania). Na szczęście istnieją narzędzia wspomagające budowę specyfikacji funkcjonalnych – jasne opracowania dla celów tworzenia oprogramowania zarówno automatyzacji, jak i dodatkowego.
Bardziej szczegółowo specyfikacje funkcjonalne pomagają rozpocząć i przeprowadzić projekt od fazy początkowej, poprzez testy, symulacje, konstrukcję, trening obsługi, uruchomienie i konfigurację, działanie, obsługę, aktualizacje i ulepszenia oraz ewentualnie rozmontowywanie. Dzięki swej modułowej formie mogą oszczędzać czas, tworząc podstawy do opracowania nowych projektów (każdy bowiem ma pewne elementy, które powtarzają się, nawet jeżeli podobieństwo jest zaledwie częściowe). 

 Specyfikacje funkcjonalne mogą służyć jako szczegółowe przewodniki dla celów opracowywania oprogramowania dla automatyzacji oraz oprogramowania dodatkowego – wspomagającego. W swojej najpopularniejszej formie są budowane w sposób modułowy, zawierający elementy, przydatne również w innych implementacjach 
 Zapobieganie ograniczeniu funkcjonalności
Specyfikacje funkcjonalne pomagają uruchamiać wewnętrzne projekty w łatwy sposób. Jeżeli konieczna jest pomoc z zewnątrz, niektórzy dostawcy są w stanie zaoferować znacznie krótszy czas dostawy – zależnie od poziomu nietypowości wymaganego elementu. Jasne określenie właściwości elementów projektu pomaga zapobiegać późniejszym zmianom, zwanym „ograniczeniu właściwości” (z ang. feature creep) – zmiany te bowiem powodują, że efekt finalny projektu odbiega właściwościami od zakładanych na samym początku. Oczywistym jest, że zjawisko takie jest niekorzystne dla całości projektu.
Z drugiej jednak strony zbyt wiele szczegółów wcale nie ułatwia pracy podczas realizacji etapów projektu. Podobnie jak sam projekt może znacznie wykroczyć poza początkowe ramy, tak i sama specyfikacja funkcjonalna może nam się „wymknąć spod kontroli”. Electric Power Research Institute (EPRI) zaleca definiowanie problemów składowych projektu w następujący sposób. Według EPRI specyfikacja funkcjonalna powinna zawierać specyficzne informacje na temat każdego wymogu funkcjonalności oprogramowania oraz opis dla każdego tego wymogu:
cel – jaka funkcja powinna być przez dany element realizowana;
wejście – jakie wejścia będą dopuszczalne, w jakiej formie zostaną dostarczone; jakie jest ich źródło, inne informacje uzupełniające;
proces – kroki wykonywane przez program, algorytmy, formuły lub wykorzystane techniki (nie zawiera się tutaj szczegółów, dotyczących implementacji programowej);
wyjścia – wymagane do komunikacji z innymi elementami informacje wyjściowe; forma informacji wyjściowej (tzw. report layout); cel dla informacji wyjściowej (dokąd zostanie wysłana); wartości oraz czas, co jaki informacja wyjściowa będzie aktualizowana; obsługa procedur związanych z sytuacjami błędnymi;jednostki, w jakich wystawiane są wyjścia z poszczególnych modułów.
Użyteczność oprogramowania powinna być uwzględniana podczas tworzenia specyfikacji funkcjonalnej. Według firmy EPRI przykładem mogą być jasne komunikaty o błędach, sprawdzanie zakresu wielkości wejściowych podczas wprowadzania danych do systemu oraz kolejność wyborów opcji i ekranów systemu zależnie od preferencji danego użytkownika. 
Standardowa modularyzacja
W budowaniu specyfikacji funkcjonalnych bardzo przydatne są takie standardy, jak ISA-88 (dla sterowania wsadowego – użyteczny również do innych celów) oraz ISA-95 (Enterprise-Control System Integration – norma dotycząca integracji warstw zarządzania przedsiębiorstwa z systemami sterowania).
Dzięki nim możliwe są:

  • uproszczenie definiowania elementów projektu,
  • wspomaganie określenia głównych celów automatyzacji,
  • modularyzacja fizycznych i proceduralnych elementów procesu,
  • dostarczenie do realizacji modułów znacznie bardziej elastycznych, umożliwiających dalszą ewentualną rozbudowę systemu,
  • zastosowanie rozwiązań w dowolnym środowisku automatyzacji (nie tylko w sterowaniu ciągłym/wsadowym),
  • uproszczenie i ujednolicenie głównych terminów/ właściwości dla celów polepszenia komunikacji w całym projekcie.

Podczas sprawdzania specyfikacji należy najpierw przyjrzeć się pewnym kluczowym punktom, jak twierdzi David Longstreet z firmy Longstreet Consulting w swoim artykule „How to Read a Functional Specification”. Sugeruje w nim mianowicie, aby odpowiedzieć na kilka podstawowych pytań:

  • W jakim stanie znajduje się aplikacja na początku specyfikacji funkcjonalnej i jak przetwarzana jest informacja?
  • Czy harmonogram prac (workflow) zawiera logiczne grupy informacji (pojedyncze lub wielokrotne zdarzenia/stany)?
  • Czy informacje będą importowane, przechowywane, przetwarzane i eksportowane – jeżeli tak, to w jaki sposób?
  • Czy specyfikacja opisuje algorytmy i obliczenia?
  • Czy wszystkie funkcje są opisane i czy wszystkie wymagania zostały sprawdzone?
  • Czy wszystkie scenariusze działania i przykłady są zgodne ze schematem przepływowym projektu, od początku do końca? 

Narzędzia wspomagające
Tworzenie specyfikacji funkcjonalnej nie musi być wcale procesem tworzenia wszystkiego od nowa. Obecnie na rynku dostępne są różnego rodzaju narzędzia programistyczne, pozwalające na generowanie, zarządzanie oraz modyfikacje specyfikacji funkcjonalnych.
Przykładowo, oprogramowanie Microsoft Visio może być wykorzystywane do tworzenia schematów przepływowych wysokiego poziomu, mapowania procesów fizycznych oraz tworzenia specyfikacji funkcjonalnych, dzięki informacjom wprowadzonym za pomocą diagramów elektrycznych i „rurowych” programu Visio.
Oprogramowanie Spec-Soft SpecPFS-Definition służy do tworzenia specyfikacji funkcjonalnych oraz dokumentacji, mając jednocześnie rozszerzone możliwości symulacyjne. Oprogramowanie to ma cały zestaw narzędzi inżynierskich wykorzystywanych do specyfikacji oraz symulacji procedur automatyzacji wsadowej, zgodnie z normą ISA-88. Generuje różnorodne standardy dla wyposażenia i procedur, pozwala na zarządzanie zmianami w projektach i specyfikacjach, pozwala na tworzenie całej gamy różnorodnych dokumentów, związanych z tworzoną specyfikacją. Oprogramowanie Spec-Soft SpecPFS-Definition pozwala na:
1) tworzenie klas sprzętu i oprogramowania, zawierając standardy, szablony; budowanie bloków, definiujących poszczególne moduły sterujące, moduły sprzętowe, klasy poszczególnych elementów (z własną, wewnętrzną logiką); budowanie elementów z użyciem procedur wysokiego rzędu oraz wykorzystaniem systemu receptur;
2) tworzenie modelu fizycznego zgodnego z normą ISA-88 poprzez importowanie danych z plików P&ID, arkuszy, baz danych – wszystko to dla celów opracowania modułowego modelu procesu;
3) opracowywanie szczegółowego programu logicznego z użyciem języka SFC (Sequential Function Chart); definiowanie warunków aktywacji, alarmów i wymogów; wizualizację ścieżek przepływu sygnałów na diagramach P&ID; zdefiniowanie i późniejszą edycję warunków, równań czy pętli sterowania;
4) tworzenie receptur, formuł, sekwencji (S88.02 PFCs); definiowanie interakcji proceduralnych, takich jak: synchronizacja, alokowanie, parowanie oraz inne; tworzenie diagramów Gantta dla receptur oraz opracowywania różnych strategii działania; Dodatkowo wspomaga:
5) wprowadzanie zmian w już wykorzystywanej specyfikacji;
6) rozszerzenie wykorzystania procesu; pozwala lepiej przyjrzeć się konfliktom oraz interakcjom, lepiej uszeregować zadania oraz dokonać przeglądu głównych zasad, obowiązujących w specyfikacji;
7) generowanie i zarządzanie dokumentami specyfikacji w oprogramowaniu Microsoft Word, poprzez powiązanie z bazami danych, przy użyciu systemu pomocy;
8) tworzenie i śledzenie interfejsów dla związanych ze specyfikacją dokumentów i oprogramowania.
Poza samą pomocą szczegółowo opracowana specyfikacja funkcjonalna pozwoli na opracowanie dodatkowego oprogramowania wspomagającego, dzięki któremu zostanie zredukowany do minimum czas uruchomienia i oprogramowania systemu – wszystko to przyczyni się do obniżenia kosztów oraz skrócenia czasu pojawienia się produktu na rynku. Pomoże to z pewnością na podniesienie wydajności właśnie dzięki skróceniu czasów programowania i obsługi projektowanego systemu.
ce
Artykuł pod redakcją
Krzysztofa Pietrusewicza,
Politechnika Szczecińska


Tworzenie specyfikacji funkcjonalnej

Przejrzystość jest ważnym czynnikiem specyfikacji funkcjonalnej; według tego, co podaje firma Spec-Soft, specyfikacja funkcjonalna powinna zawierać:

  • każdy nowy typ zmiennej/urządzenia/przyrządu,
  • połączenia pomiędzy punktami sieci (zmiennych/ urządzeń/ przyrządów),
  • moduły wyposażenia,
  • jednostki oraz związane z nimi funkcje przejścia pomiędzy stanami procesu,
  • procesy (tranzycje pomiędzy stanami procesu, fazy/etapy, oraz związane z nimi obiekty),
  • moduły zarządzające,
  • procedury, warunki działania oraz warunki blokowania/ zatrzymania.