|
Wprowadzenie
Zakres dokumentu
Znakowanie pojęć
Mikrostandardy
Zaawansowane: model rodzajów
pojęć
Podsumowanie
Za tekst techniczno–zarządczy
można uważać każdy produkt lub półprodukt powstający w trakcie produkcji
systemów, nie będący kodem programu ani innym produktem przeznaczonym do wykonania.
Przykładem półproduktu nie będącego opracowaniem technicznym i jednocześnie
nie będącego kodem programu jest specyfikacja scenariuszy testowych.
Przykładami tekstów techniczno – zarządczych są: oferta opisująca system
przeznaczony na sprzedaż, plan projektu, specyfikacja systemu (na poziomie
biznesowym lub technicznym), projekt architekturalny, czy plan testów.
Wytworzenie opracowania techniczno-zarządczego wymaga
zastosowania wiedzy z różnych obszarów. Istnieją trzy zasadnicze obszary
wiedzy, konieczne do wykorzystania przy tworzeniu opracowania technicznego:
·
Wiedza dziedzinowa,
·
Metodologia tworzenia systemów,
·
Umiejętność tworzenia tekstów technicznych.
Wiedza dziedzinowa to opis obiektów, zdarzeń, stwierdzeń
należących do dziedziny, w której system ma działać. W przypadku tworzenia
systemu paszportyzacji dla ZEB elementami wiedzy dziedzinowej są takie
pojęcia jak „napięcie elektryczne”, „słup”, „transformator”, „przesył
energii” czy „naprawa urządzenia”.
Metodologia tworzenia systemów opisuje sposób
przetwarzania zestawu wiedzy początkowej („wymagań”) w działający, wdrożony
system. Metodologia składa się z zestawu technik, na przykład dotyczących
sposobu kierowania projektem, sposobu wykonywania analizy, sposobu
projektowania systemu, sposobu zbierania danych w terenie (w przypadku ZEB)
czy sposobu opracowywania procedur działania systemu. Pojęciami
występującymi w dziedzinie metodologii są na przykład: „harmonogram”,
„zasób”, „klasa”, „obiekt”, „system”, „moduł”, „procedura”, „baza danych”,
„tabela”, „scenariusz testowy”.
Umiejętność tworzenia tekstów technicznych pozwala
zebrać uzyskaną wiedzę dziedzinową i wypracowaną metodę tworzenia systemu i
zaprezentować ją w sposób spójny i zrozumiały dla czytelnika. Podstawowym
pojęciem z obszaru tworzenia opracowań technicznych jest „zapis”, czyli
dowolny fakt z obszaru wiedzy dziedzinowej lub metodologii tworzenia
systemów, który jest zapisywany w tworzonym tekście. Innymi pojęciami z
tego obszaru mogą być „model pojęć”, „oznaczenie zapisu”, „składowa zapisu”.
Żeby tekst techniczny był zrozumiały dla czytelnika,
musi on spełniać kilka warunków. Po pierwsze musi on być uporządkowany i
wewnętrznie niesprzeczny. Niniejsze opracowanie poświęcone jest wybranym
metodom wspomagającym tworzenie uporządkowanych i wewnętrznie
niesprzecznych opracowań techniczno-zarządczych.
Metody te to:
- Znakowanie
pojęć
- Mikrostandardy
- Utworzenie
modelu rodzajów pojęć (zaawansowane)
Zastosowanie tych trzech metod nie gwarantuje
wytworzenia czytelnego opracowania technicznego. Muszą one być uzupełnione
przede wszystkim o umiejętność prostego, zrozumiałego i jednoznacznego
formułowania myśli przez autorów. Jednak sprawne stosowanie zalecanych
metod zawsze znacznie poprawia jakość wytworzonego produktu.
Model typów pojęć występujących w tekście technicznym,
sposób znakowania zapisów oraz stosowane mikrostandardy
powinny być przygotowane przez głównego autora opracowania i powinny być
podstawą do opracowania szablonu opracowania.
Zadaniem dokumentu techniczno–zarządczego
jest zakomunikowanie podjętych decyzji oraz przekazanie uzasadnienia tych
decyzji. Zadaniem takiego dokumentu nie jest krzewienie wiedzy dziedzinowej
czy wiedzy z zakresu metodologii tworzenia systemu. Jeśli autor uważa, że
wiedza taka jest potrzebna, to powinien rozważyć umieszczenie odpowiedniego
załącznika. Prezentowanie wiedzy w dokumencie techniczno-zarządczym zwykle
zaburza tok lektury i utrudnia zrozumienie jego właściwej treści, czyli
podjętych decyzji.
Opracowanie techniczne powinno mieć swój system
znakowania pojęć. Celem tworzenia systemu znakowania jest umożliwienie
łatwego odwoływania się do istniejących zapisów.
Zwykle system znakowania zapisów opiera się na
wprowadzeniu dwóch składowych:
Numer jest wykorzystywany do numerowania pojęć wewnątrz
ich rodzajów. Numer składa się zwykle z krótkiego prefiksu i kolejnej
liczby.
Krótka nazwa powinna składać się z nie więcej niż trzech
słów i powinna bardzo zwięźle opisywać znaczenie pojęcia.
Tabela
1
pokazuje przykłady znakowania kilku pojęć związanych z ofertą na system
paszportyzacji infrastruktury dla ZEB.
Tabela
1. Przykłady znakowania pojęć
|
Rodzaj pojęcia
|
Prefix
|
Przykłady
|
|
Numer
|
Krótka nazwa
|
|
Cel Biznesowy
|
CB
|
CB_001
|
Przewaga konkurencyjna
|
|
|
CB_002
|
Sprawna obsługa klienta
|
|
|
CB_003
|
|
|
Wymaganie
|
WM
|
WM_001
|
Pełna ewidencja infrastruktury
|
|
|
WM_002
|
Uzyskiwanie warstw map
|
|
Funkcja
|
FN
|
FN_001
|
Wyliczanie obciążeń
|
|
|
FN_002
|
Prezentacja graficzna
|
|
Moduł
|
MD
|
MD_001
|
Inwentaryzacja Danych
|
|
|
MD_002
|
Prezentacja Danych
|
|
|
MD_003
|
Obliczenia Eksploatacyjne
|
Sposób znakowania pojęć może uwzględniać strukturę systemu.
Często spotykanymi uzupełnieniami systemu znakowania jest uwzględnienie
podziału systemu na moduły lub uwzględnienie autora zapisów w jego numerze.
Na przykład moduły mogą mieć następujące skróty:
MD001 Inwentaryzacja
Danych ID
MD002 Prezentacja
Danych PD
MD003 Obliczenia
Eksploatacyjne OE
Przy takich oznaczeniach modułów funkcje mogą mieć
nadawane numery w postaci FN_ID_001, FN_OE_001 i td.
Proponowany tu system znakowania pojęć jest niezbyt
rygorystyczny. Istnieją systemy o wiele bardziej sformalizowane: na
przykład w opisie modelu CMMI (http://www.sei.cmu.edu/cmmi/)
osobny identyfikator ma każdy akapit tekstu.
Sposób znakowania pojęć powinien być opracowany przez
osobę odpowiedzialną za wyprodukowanie opracowania i powinien być
załącznikiem do szablonu opracowywanego dokumentu.
Mikrostandardy
Każdy rodzaj pojęcia ma zestaw informacji, który
powinien być wykorzystywany do opisywania pojęć tego rodzaju. Jeśli chcemy,
żeby wszystkie osoby uczestniczące w procesie tworzenia opracowania
technicznego zbierały wszystkie wymagane informacje dotyczące danego
rodzaju pojęć, to musimy ten zestaw informacji jednoznacznie zdefiniować.
Jeśli do tworzenia opracowania wykorzystujemy narzędzia
typu CASE, to pełny zestaw informacji stosowalnych do opisu pojęcia, jest
zwykle wbudowany w dane narzędzie. Na przykład w diagramerze
VISIO do opisu pojęcia „class” mogą być stosowane
pola Name, Stereotype,
Documentation, Visibility,
IsRoot, IsLeaf, IsAbstract, IsActive, Attributes, Operations, Receptions...
i wiele innych. W tej sytuacji mamy dwa problemy. Po pierwsze należy
określić, które z powyższych informacji są rzeczywiście potrzebne przy
tworzeniu naszego opracowania. Możemy na przykład zawęzić opis klasy do
wykazu atrybutów, wykazu funkcji oraz słownego opisu. Drugi problem to
zestaw informacji, które muszą być zawarte w polach nie mających postaci
doprecyzowanej przez autora narzędzia typu CASE. Najczęściej spotykanymi
polami tego rodzaju są pola typu „opis” (w VISIO pole to nazywa się „Documentation”). Dla takiego
pola należy określić mikrostandard,
precyzujący jaką strukturę ma mieć to pole przy opisie każdego pojęcia. Na
przykład możemy wymagać, żeby pole „Documentation”
w specyfikacji pojęcia „klasa” zawsze zawierało następujące segmenty:
·
Pierwsze zdanie
musi mieć postać: „<nazwa klasy> jest to....”.
Na podstawie takiego zdania musi istnieć możliwość stwierdzenia, czy coś
jest czy nie jest instancją (egzemplarzem, wcieleniem) klasy (obiektem
należącym do klasy).
·
Następne zdania
powinny opisywać inne zasadnicze własności klasy.
·
Sekcja DYNAMIKA
KLASY powinna zawierać informacje o tym, w jakiej sytuacji biznesowej
obiekt należący do klasy jest tworzony; kiedy jest modyfikowany i
ewentualnie usuwany.
·
Sekcja ŹRÓDŁO
INFORMACJI powinna zawierać odniesienie do dokumentu lub osoby, która
przekazała informacje będące podstawą do wyspecyfikowania klasy.
Jeżeli przy tworzeniu dokumentu nie wykorzystujemy
narzędzi typu CASE, to zadanie określenia mikrostandardu
ulega rozszerzeniu. Należy wskazać (a nie wybrać z predefiniowanego
zestawu) zestaw informacji opisujących dane pojęcie. Części opisu pojęć,
które, w przypadku korzystania z narzędzi typu CASE, są umieszczane w
ogólnych polach opisowych, mogą stać się samodzielnymi sekcjami opisu.
Podsumowaniem krótkiego opisu (meta)pojęcia „mikrostandard” może być stwierdzenie: musimy wiedzieć,
jakie informacje o każdym pojęcie analityk (autor dokumentu) powinien zebrać
i w jaki sposób powinien je zapisać.
Mikrostandardy opisów każdego
pojęcia powinien być częścią szablonu przygotowywanego dokumentu.
Rodzaj pojęcia jest to zbiór pojęć pełniących taką samą
rolę w opracowaniu technicznym. Przykładami rodzajów pojęć mogą być:
- Faza
projektu
- Element
WBS
- Założenie
- Cel
biznesowy
- Cel
systemowy
- Wymaganie
- Funkcja
- Moduł
- Klasa
- Tabela
danych
- Etap
projektu
- Test
modułu
- ....
Pomiędzy rodzajami pojęć zachodzą relacje. Przykładami
relacji zachodzących pomiędzy rodzajami pojęć są na przykład:
- Cel
biznesowy generuje wymaganie
- Cel
systemowy zapewnia osiągnięcie celu biznesowego
- Założenie
wpływa na moduł
- Funkcja
wynika z wymagania
- Moduł
realizuje funkcję
- Moduł
jest wytwarzany w etapie projektu
- Tabela
danych należy do modułu
- Test
modułu działa na moduł
- Funkcja
jest sprawdzana przez test modułu
- ......
Rysunek 1.
Fragment przykładowego metamodelu
Diagram metamodelu może być wytworzony za pomocą
dowolnego narzędzia służącego do graficznego modelowania danych; może to
być narzędzie zarówno wykorzystujące techniki obiektowe jak i strukturalne.
Opis metamodelu, zawierający:
·
nazwy rodzajów pojęć występujących w
opracowaniu,
·
nazwy związków zachodzących pomiędzy
rodzajami pojęć,
·
diagram metamodelu (jeżeli jest utworzony)
powinien być załącznikiem do szablonu opracowywanego
dokumentu.
Celem utworzenia metamodelu jest określenie podstawowej
struktury tworzonego opracowania. Każdy zapis, każde pojęcie i każdy rodzaj
pojęcia powinien mieć ściśle określone znaczenie w dokumencie. Jeśli nie
wiemy, jaka może być relacja danego pojęcia z innymi pojęciami w
dokumencie, to nie warto takiego pojęcia zapisywać.
W mniejszych dokumentach nie jest konieczne jawne
tworzenie metamodelu. W
PMI PMBoK często używane jest stwierdzenie typu „<An item> may be formal or informal, higly detailed or broadly framed based on the needs of
the project.” Takie samo stwierdzenie może się odnosić do
metamodelu. Ale metamodel – czyli opis pojęć i ich ról w dokumencie - musi
istnieć zawsze, niezależnie od formy jego przekazywania. Ma on zasadnicze
znaczenie porządkujące dla tworzonego dokumentu technicznego.
Metamodel opisuje główne pojęcia występujące w
dokumencie oraz zachodzące pomiędzy nimi związki. Mikrostandardy
mówią, w jaki sposób należy opisywać każdy rodzaj pojęcia występujący w
opracowaniu. Te dwa elementy zapewniają, że tworzone opracowanie będzie
zawierało wyłącznie informacje rzeczywiście potrzebne dla uzyskania celu,
jaki jest stawiany przed dokumentem oraz, że będą
zawierać tylko potrzebne informacje. Utworzenie spójnego metamodelu w
szczególności powinno gwarantować możliwość śledzenia spójności pomiędzy
informacjami wejściowymi, czy też początkowymi (np. wymagania na system) a
celami stawianymi przed opracowaniem (np. wskazanie właściwości modułów
implementujących system).
Wprowadzenie systemu znakowania pojęć ułatwia
odwoływanie się do stwierdzeń zawartych w dokumencie. W szczególności
stwierdzeniami takimi są opisy związków pomiędzy występującymi pojęciami.
Na przykład przy definiowaniu testów, wykorzystanie systemu oznaczeń
znacznie ułatwia wskazywanie wymagań, które są weryfikowane przez konkretne
testy.
Stosowanie opisanych tu metod tworzenia opracowań
technicznych jest znacznie ułatwione, jeśli do ich tworzenia wykorzystywane
są narzędzia typu CASE, gdyż, jak wspomniano wyżej, podstawą projektowania
narzędzi CASE są właśnie modele pojęć stosowanych w procesie tworzenia
systemów.
Podjęcie decyzji realizujących przedstawione metody
tworzenia tekstów technicznych należy zawsze do głównego autora
opracowania. Jego obowiązkiem jest przekazanie odpowiednich zaleceń
pozostałym współautorom i zapewnienie, że zalecenia te są właściwie
zrozumiane przez pozostałych autorów.
|
