Dokumentacne materialy vyskumnej skupiny MONICA

Dokumentacna struktura

• Dokumentacia BM (bmIDS, IPA, ...)
  • manualove stranky (P)(K)
  • integrovana napoveda (P)(K)
  • propagacny material (P)(C)
  • instalacny manual (P)(C)
  • pouzivatelska prirucka (P)(C)
  • systemova prirucka (V)(C)
  • changelog (P,V)(K,C)
  • komentovany zdrojovy kod (V),(K,C)

P - pre pouzivatela, V - pre vyvojara, C - o celoku, K - o komponente

• Zaverecne prace
• Publikacie
• Anual report
  • interny
  • verejny
• Pracovna dokumentacia
• MONICA propagacny material
• Metodicke materialy
• Kniznica informacnych zdrojov (neverejna - len pre clenov MONICA)

Manualove stranky

• Ucel: Dokumentovat pouzivanie daneho objektu.
• Objekt: Aplikacia vyvijaneho softveru s konzolovym rozhranim.
• Obsah: Strucny opis funkcie objektu, syntax prikazu pre spustenie, vyznam jednotlivych prepinacov, opis vstupov, opis vystupov, autor, referencie, licencia, (vid existujuce manualove stranky inych programov a debian documentation policy).
• Forma: Manualova stranka.
• Pokyny pre vytvorenie:

Manualove stranky su zoskupene do niekolkych skupin:

Skupina	Opis
1	Používateľské príkazy
2	Systémové volania
3	Funkcie, knižnice jazyka C
4	Špeciálne súbory (nachádzajúce sa v /dev) a ovládače
5	Formáty konfiguračných súborov a všeobecné zásady (napr. etc/passwd)
6	Hry a sporiče obrazoviek
7	Rôzne
8	Príkazy systémovej administrácie (obvykle len pre root)

Niektore systemy maju naviac aj tieto sekcie

Skupina	Opis
0	Hlavičkové súbory knižnice jazyka C
9	Štandardné programy jadra (Kernel)
n	Klúčové slová Tcl/Tk
x	X Window system

Format manualovych strankok

Meno zdrojoveho suboru manualovej stranky je meno prikazu, funkcie alebo suboru za nim nasleduje bodka a potom cislo sekcie, do ktorej dana stranka patri. Ked mame vybrate meno stranky, potrebujeme sa rozhodnut kam dany zdrojovy subor bude umiestneny. V Linuxe su vsetky manualove stranky rozdelene podla umiestnenia do zoznamu v premennej MANPATH. MANPATH ma ten isty format ako PATH, rozdiel je v tom, ze MANPATH netoleruje prazdne miesta a relativnu cestu, podporuje len absolutnu cestu. Ak nie je MANPATH nastaveny je pouzity /usr/man adresar.

Nasledujucim prikazom otvorime nenaformatovanu manualovu stranku:

$ groff -Tascii -man foo.man | more.

-Tascii prikaze groff produkovat ASCII vystup manualovej stranky, ktory mozeme editovat. Ak chceme spravit manualovu stranku pristupnu pre inych pouzivatelov systemu, teda vyrobit manualovu stranku alebo ju aktualizovat po editacii pouzijeme prikaz:

$ cp foo.man /usr/man/man1/foo.1.

Tento prikaz nainstaluje manualovu stranku do /usr/man, kde bude pristupna vsetkym pouzivatelom systemu a bude sa dat zobrazit prikazom - man foo.

Mozme pouzivat priame operatory zmenu fontov ako \fB, \fP. Ale je lepsie pouzit makra. Tymto sa vyhneme zabudaniu zmeny fontu na konci slova. Makra na zmenu fontov pozname:

• • .B Tucne.
  • .BI Tucne a zmena na sikme.
  • .BR Tucne a zmena na normalne (Roman).
  • .I Sikme.
  • .IB SIkme a zmena na tucne.
  • .IR Sikme a zmena na normalne (Roman).
  • .RB Normalne (Roman) a zmena na tucne.
  • .RI Normalne (Roman) a zmena na sikme.
  • .SM Male (9/10 z normalnej velkosti).
  • .SB Velke tucne (Nie male a zmena na tucne).

X zmena na Y znamena, ze pre neparne argumenty plati Makro X a pre parne Y.

Napr. - .BI "Arg 1 je tucne, " "Arg 2 je sikme, " "a tucne, " "a sikme."

Dvojite uvodzovky su potrebne pre zahrnutie medzery (white space) do argumentu, bez nich nebude medzera medzi jednotlivymi rozlicnymi typmi pisma. Vacsinou su ale dvojite makra pouzivane prave tam kde nechceme biele miesta medzi argumentami ale plynuly prechod na iny typ pisma resp. font.

Ine Makra na pisanie manualovych stranok.

• • .TH - nastavit hlavicku manualovej stranky. Napr.: .TH FOO 1 "MARCH 1995" Linux "User Manuals"
  • .SH - sa pouziva pri zacati novej sekcie. Napr.: .SH NAME
  • .TP - za prvym argumentom bude nasledovat volne miesto a za nim text.
  • .PP - novy odstavec, pouziva sa casto na zacatie noveho riadku.
  • ." - komentar.

Existencia niekolko stovak manualov definovala standardy pre pisanie manualovych stranok.

• • Pre funkcie plati ze argumenty si vzdy sikme, aj v sekcii SYNOPSIS kde je zvysok funkcie napisany tucnym fontom.
  • Mena suborov su stale sikme okrem sekcie SYNOPSIS kde su napisane tucne.
  • Akykolvek odkaz na inu manualovu stranku je tucnym pismom, avsak cislo do akej sekcie stranka patri je pisane normalnym pismom.
  • Skratky vyzeraju lepsie ak su napisane malym typom pisma (.SM).

Sekcie manualovej stranky

NAME sekcia

Jedina nutna sekcia. Manualova stranka bez mena je zbytocna. Obsahuje meno programu alebo funkcie, dalej pomlcka a za nou kratky popis funkcionality programu (funkcie alebo suboru). Ak pouzivame groff zapiseme to takto.

.SH NAME foo \- frobnicate the bar library

\- lomitko je potrebne k odliseniu pomlcky, od pomlciek ktore rozdeluju slova a mozu sa objavit ci v mene programu alebo funkcie alebo v nasledujucom popise.

SYNOPSIS sekcia

Pre prikaz je tu presny opis toho ako sa spusta a ake ma moznosti, pre funkcie je to presny zoznam parametrov a prislusny hlavickovy subor.

DESCRIPTION sekcia

Opis fungovania prikazu alebo funkcie. Tato sekcia ma byt zdrojom spolahlivych a detailnych informacii. (Vysvetlit naco su argumenty, format suboru ...)

OPTIONS sekcia

Opis toho ako jednotlive moznosti ovplyvnuju spravanie programu

FILES sekcia

Vypis suborov, ktore program alebo funkcia pouziva (napr. - konfiguracne subory, startup subory a subory, s ktorymi program pracuje). Je dobre zadat plnu cestu k suborom. Moze nasledovat aj strucny opis.

ENVIRONMENT sekcia

lists all environment variables that affect your program or function and tells how, of course. Most commonly the variables will hold pathnames, filenames or default options.

DIAGNOSTICS sekcia

Ma poskytovat prehlad najviac vyskytovanych chybovych sprav a moznosti ako sa s nimi vysporiadat. Nie je potrebne vysvetlovat systemove chybove hlasenia (perror(3)) alebo fatal signaly (psignal(3)) ak sa objavuju v priebehu vykonavania programu.

BUGS sekcia

Idealne by nemala existovat. Opisuju sa ti zname chyby, limity programu alebo funkcie, neprijemnosti, ktore moze program ci funkcia vyvolat.

AUTHOR sekcia

Autor a jeho mail pre pripadne kontaktovanie.

SEE ALSO sekcia

Zoznam manualovych stranok, ktore suvisia s vytvaranou manualovou strankou. Tradicne je to posledna sekcia. Je tu aj volnost vytvorit si vlastnu sekciu v pripade, ze ziadna z doterajsich nie je vhodna.

Ako by mala vyzerat formatovana manualova stranka:

FOO(1) User Manuals FOO(1)

NAME

foo - frobnicate the bar library

SYNOPSIS

foo [-bar] [-c config-file ] file ...

DESCRIPTION

foo frobnicates the bar library by tweaking internal symbol tables. By default it parses all baz segments and rearranges them in reverse order by time for the xyzzy (1) linker to find them. The symdef entry is then compressed using the WBG (Whiz-Bang-Gizmo) algorithm. All files are processed in the order specified.

OPTIONS

-b Do not write `busy' to stdout while processing.

-c config-file

Use the alternate system wide config-file instead of /etc/foo.conf. This overrides any FOOCONF environment variable.

-a In addition to the baz segments, also parse the blurfl headers.

-r Recursive mode. Operates as fast as lightning at the expense of a megabyte of virtual memory.

FILES

/etc/foo.conf

The system wide configuration file. See foo (5) for fur- ther details. ~/.foorc

Per user configuration file. See foo (5) for further details.

ENVIRONMENT

FOOCONF

If non-null the full pathname for an alternate system wide foo.conf. Overridden by the -c option.

DIAGNOSTICS

The following diagnostics may be issued on stderr:

Bad magic number. The input file does not look like an archive file. Old style baz segments. foo can only handle new style baz segments. COBOL object libraries are not supported in this version.

BUGS

The command name should have been chosen more carefully to reflect its purpose.

AUTHOR

Jens Schweikhardt

SEE ALSO

bar (1), foo (5), xyzzy (1)

Linux Last change: MARCH 1995 2

---

Je viacero sposobov ako vytvorit manualovu stranku. V linuxe su to sposoby pre spracovanie textu - troff, nroff, groff. Nasledujuca ukazka je typu groff.

Ako vyzera nenaformatovana manualova stranka z predchadzajuceho prikladu

.\" Process this file with
.\" groff -man -Tascii foo.1
.\"
.TH FOO 1 "MARCH 1995" Linux "User Manuals"
.SH NAME
foo \- frobnicate the bar library
.SH SYNOPSIS
.B foo [-bar] [-c
.I config-file
.B ]
.I file
.B ...
.SH DESCRIPTION
.B foo
frobnicates the bar library by tweaking internal
symbol tables. By default it parses all baz segments
and rearranges them in reverse order by time for the
.BR xyzzy (1)
linker to find them. The symdef entry is then compressed
using the WBG (Whiz-Bang-Gizmo) algorithm.
All files are processed in the order specified.
.SH OPTIONS
.IP -b
Do not write `busy' to stdout while processing.
.IP "-c config-file"
Use the alternate system wide
.I config-file
instead of
.IR /etc/foo.conf .
This overrides any
.B FOOCONF
environment variable.
.IP -a
In addition to the baz segments, also parse the
blurfl headers.
.IP -r
Recursive mode. Operates as fast as lightning
at the expense of a megabyte of virtual memory.
.SH FILES
.I /etc/foo.conf
.RS
The system wide configuration file. See
.BR foo (5)
for further details.
.RE
.I ~/.foorc
.RS
Per user configuration file. See
.BR foo (5)
for further details.
.SH ENVIRONMENT
.IP FOOCONF
If non-null the full pathname for an alternate system wide
.IR foo.conf .
Overridden by the
.B -c
option.
.SH DIAGNOSTICS
The following diagnostics may be issued on stderr:
Bad magic number.
.RS
The input file does not look like an archive file.
.RE
Old style baz segments.
.RS
.B foo
can only handle new style baz segments. COBOL
object libraries are not supported in this version.
.SH BUGS
The command name should have been chosen more carefully
to reflect its purpose.
.SH AUTHOR
Jens Schweikhardt <howto at schweikhardt dot net>
.SH "SEE ALSO"
.BR bar (1)
.BR foo (5),
.BR xyzzy (1)

Postup vytvorenia stranky

*Zvolime si meno stranky a taktiez jej umiestnenie do jednej zo zakladnych skupin. *Vyberieme potrebne sekcie a navrhneme ich obsah. *Za pomoci makier a standardov uvedenych v sekcii format manualovych stranok vytvarame nenaformatovanu manualovu stranku.

---

• Zodpovedna osoba: Veduci pracovnej skupiny v ramci ktorej dany objekt vznikol.
• Autori: Vyvojari, ktori objekt vytvorili.
• Okolnosti vzniku/aktualizacie: Pri vzniku objektu alebo jeho novej verzie.
• Umiestnenie: Manualova stranka je sucastou instalacneho balika daneho objektu.
• Dostupnost: Pouzivatel daneho objektu.

Integrovana napoveda

• Ucel: Dokumentovat pouzivanie daneho objektu.
• Objekt: Aplikacia vyvijaneho softveru s GUI.
• Obsah: Navod na pouzivanie softveru. Strucny opis funkcie objektu, autor, referencie, licencia, (vid existujuce napovedy inych programov).
• Forma: Komponent GUI.
• Pokyny pre vytvorenie:
  • Skompletizovat navod na pouzivanie softveru, funckie objektu a jednotlivych casti.
  • Navrhnut aplikaciu.
  • Implementovat navhrnutu aplikaciu.
  • Overit, kompletnost navodu, ktory aplikacia ponuka. (Napoveda musi poskytovat informacie k vsetkym moznym situaciam a funkciam softveru).
• Zodpovedna osoba: Veduci pracovnej skupiny v ramci ktorej dany objekt vznikol.
• Autori: Vyvojari, ktori objekt vytvorili.
• Okolnosti vzniku/aktualizacie: Pri vzniku objektu alebo jeho novej verzie.
• Umiestnenie: Integrovana napoveda je sucastou GUI.
• Dostupnost: Pouzivatel daneho objektu.

Propagacny material

• Ucel: Propagovat vyvijany softver.
• Objekt: Vyvijany softver.
• Obsah: Velmi strucny opis funckie softveru, prinos softveru pre zakaznika, kontaktne informacie na skupinu vyvijajucu softver, logo softveru.
• Forma: WEB stranka, letak (white paper, data sheet ... ), buletin, poster, prezentacne slajdy.
• Pokyny pre vytvorenie:
  • Zhromazdit informacie uvedene v obsahu.
  • Navrhnut material
  • Pred oficialnym vydanim konzultovat navrh so zodpovednou osobou
• Zodpovedna osoba: Veduci projektu a/alebo veduci pracovnych skupin.
• Autori: Osoba poverena vytvorenim materialu.
• Okolnosti vzniku/aktualizacie: Pri vzniku objektu alebo jeho novej verzie.
• Umiestnenie: Elektronicka podoba - WEB stranka projektu (oficialna verzia), svn (pracovna aj oficialna verzia). Tlacena podoba - podla potreby.
• Dostupnost: Verejnost, potencialni pouzivatelia softveru.

Instalacny manual

• Ucel: Dokumentovat instalaciu daneho softveru.
• Objekt: Vyvijany softver.
• Obsah: Navod na instalaciu objektu. Strucny opis funkcie objektu, autor, referencie, licencia, (vid existujuce instalacne manualy inych programov).
• Forma: PDF, TXT, Latex, wiki stranka.
• Pokyny pre vytvorenie:
  • Vytvorit na wiki stranke navod, ktory zahrna vsetko z obsahu.
  • Vytvorit podobny navod, ale vo formate TXT.
  • Z wiki stranky ziskat Latex a zneho vytvorit PDF.
• Zodpovedna osoba: Za kazdy osobitny komponent veduci pracovnej skupiny v ramci ktorej dany komponent objektu vznikol.
• Autori: Vyvojari daneho objektu.
• Okolnosti vzniku/aktualizacie: Vznik softveru alebo jeho novej verzie.
• Umiestnenie: Sucast instalacneho media objektu, sucast pouzivatelskej prirucky, wiki, svn, WEB stranka projektu.
• Dostupnost: Pouzivatel daneho objektu.

Pouzivatelska prirucka

• Ucel: Dokumentovat pouzivanie softveru.
• Objekt: Vyvijany softver.
• Obsah: Identifikacne data (obalka, titulna strana), obsah, zoznam obrazkov a tabuliek, slovnik terminov, informacie o pouzivani softveru ( instalacia, odinstalovanie, pouzivanie samotneho programu alebo jeho casti, priklad pouzitia, scenare pouzivania), chybove hlasenia, index (odporuca sa pri dokumentoch, ktore maju 40 a viac stran).
• Forma: PDF, TXT, Latex, wiki.
• Pokyny pre vytvorenie:
  • Vytvorit v Latexu prirucku, ktora zahrna vsetko z obsahu.
  • Vygenerovat PDF z Latexu.
• Zodpovedna osoba: Veduci projektu a veduci pracovnych skupin.
• Autori: Osoba poverena vytvorenim pouzivatelskej prirucky (moze a nemusi byt vyvojar objektu).
• Okolnosti vzniku/aktualizacie: Vznik softveru alebo jeho novej verzie.
• Umiestnenie: Sucast instalacneho media objektu, wiki, svn, WEB stranka projektu.
• Dostupnost: Pouzivatel daneho objektu.

Systemova prirucka

• Ucel: Dokumentovat objekt pre potreby dalsieho vyvoja.
• Objekt: Vyvijany softver.
• Obsah: Opis funkcionality pre objekt a pre kazdy komponent objektu, analyza a navrh riesenia, opis architektury systemu a architektury kazdeho jeho komponentu, opis tried a metod (napr. JavaDoc ), validacny dokument (opis ako bol kazdy a jeden program validovany a opis ako tato validacia koresponduje s poziadavkami), opis udrzby systemu.
• Forma: PDF, TXT, Latex, wiki.
• Pokyny pre vytvorenie:
  • Vytvorit v Latexu prirucku, ktora zahrna vsetko z obsahu.
  • Vygenerovat PDF z Latexu.
• Zodpovedna osoba: Veduci projektu a veduci pracovnych skupin.
• Autori: Vyvojari daneho objektu.
• Okolnosti vzniku/aktualizacie: Vznik pri navrhu objektu. Aktualizacia pri kazdej zmene navrhu.
• Umiestnenie: Wiki, svn, spolu so zdrojovym kodom.
• Dostupnost: Vyvojari.

Changelog

• Ucel: Dokumentovat zmeny aktualnej verzie oproti predchadzajucim verziam.
• Objekt: Vyvijany softver a jeho komponenty.
• Obsah: Vsetky zmeny funkcionality a nasledneho pouzivania objektu.
• Forma: TXT, wiki.
• Pokyny pre vytvorenie:
  • Organizovany do odsekov, ktore definuju zmenu vo funkcionalite alebo subore.
  • V hlavicke je datum zmeny a verzia produktu na ktorom je zmena vykonana.
  • Hlavna cast changelogu ma takyto tvar:
    • Kratky komentar, k danej verzii alebo zmenam.
    • Exporter
      • Pridane -
      • Vylepsene -
      • Opravene -
    • Kolektor
      • Pridane -
      • Vylepsene -
      • Opravene -
    • Analyzer
      • Pridane -
      • Vylepsene -
      • Opravene -

Changelog vytvarame ako jednoduchy TXT subor, alebo prispevok na wiki za predpokladu dodrzania obsahu a formy uvedenych vyssie.

• Zodpovedna osoba: Veduci projektu a veduci pracovnych skupin.
• Autori: Osoba, ktora vytvara zmeny.
• Okolnosti vzniku/aktualizacie: Zmeny v objekte.
• Umiestnenie: Sucastou instalacneho media objektu, wiki.
• Dostupnost: Pouzivatelia.

Komentovany zdrojovy kod

• Ucel: Napomahat lepsiemu porozumeniu zdrojoveho kodu pre vyvojarov.
• Objekt: Vyvijany softver a jeho komponenty.
• Obsah: Riadne okomentovany zdrojovy kod.
• Forma: Okomentovany zdrojovy kod podla Doxygen, JavaDoc .
• Pokyny pre vytvorenie:
  • Komentujeme - triedu ako celok, premenne, metody, konstruktory.
  • Kazdy koment zaciname vetou, ktora strucne ale uplne opisuje danu polozku. Napriklad:

         /** 
          * Konstruktor triedy
          */
        foo() {
}

• • Tagy ktore pouziavme pri komentovani zoradene podla poradia, v ktorom maju byt pouzivane
    • @author (triedy a rozhrania, potrebne)
    • @version (triedy a rozhrania, potrebne)
    • @param (iba pre metody a konstruktory)
    • @return (iba pre metody)
    • @exception (@throws je synonymum pridane v Javadoc 1.2)
    • @see (odkazy na ine polozky, ktore je potrebne alebo vhodne preskumat)
    • @since (opis od akej verzie Java platformy bola polozka pridana)
    • @serial (alebo @serialField, @serialData)
    • @deprecated (ako a preco danu polozku odmieta dana verzia softveru. )

• • Pouzivanie viacnasobnych tagov
    • Viacnasoby @author tag ma byt zoradene chronologicky. Autor triedy na vrchu zoznamu..
    • Viacnasobny @param tag ma byt zoradeny podla poradia deklaracie arugmentov.
    • Viacnasobny @throws tag (tiez znamy ako @exception) ma byt zoradeny abecedne podla pomenovania vynimiek
    • Viacnasobne @see tagy by mali byt zoradene podla poradia od polozky, ktora je najblizsie az po najvzdialenejsu. Cize od premennej, konstroktor, metodu, triedu, balicky. Ak sa vyskytne viac metod zoradene su podla abecedy, pri rovnakom nazve zalezi poradie od poctu premennych.
  • Dokumentovanie vynimiek. @throws tag oznacuje aku vynimku programator chce alebo moze odchytavat. Komentuju sa

vsetky znamen vynimky ktore musime odchytit a nezname vynimky, ktore kvoli nejakemu dovodu chceme odchytit.

• • Komentare zvykneme pisat v tretej osobe.
  • Komentare metod zvykneme zacinat slovesom.
  • Triedy, rozhrania a premenne je dobre komentovat vynechanim subjetku. Napr.: Lepsie je pouzit komentar "Pocet zakaznikov" ako

komentar "Tato premenna predstavuje pocet zakaznikov".

• • Neopisovat len co to je ale ponuknut aj jemny opis funkcie danej premennej.
  • Pri komentovani premennych, ktore su parametrami metod, je vhodne poskytnut opis ako s danou premennou metoda pracuje.
  • Vyhybat sa skratkam.
  • Komentare za pomoci tagou piseme do zdrojoveho kodu.

/**
 *
 */

tento blok vyuzivame na pisanie komentarov.

• Zodpovedna osoba: Veduci pracovnych skupin.
• Autori: Vyvojar objektu.
• Okolnosti vzniku/aktualizacie: Vznik objektu alebo zasah do zdrojoveho kodu.
• Umiestnenie: svn.
• Dostupnost: Vyvojari.

Zaverecne prace

• Ucel: Opisat vlastnu pracu na projekte.
• Objekt: Objekt zaverecnej prace
• Obsah: Kazda praca ma svoj obsah, ktory zavisi od jej objektu.
• Forma: pdf, hotove vytlacene a zviazane dokumenty.
• Pokyny pre vytvorenie: Dane v zadavacom liste zaverecnej prace.
• Zodpovedna osoba: Veduci zaverecnej prace a konzultant.
• Autori: Autor zaverecnej prace.
• Okolnosti vzniku/aktualizacie: Ukoncenie bakalarskeho alebo inzinierskeho studia na vysokej skole.
• Umiestnenie: Kniznica TUKE
• Dostupnost: Clenovia vyskumnej skupiny.

Anual report (interny)

• Ucel: Sprava o aktivitach vyskumnej skupiny za posledny rok.
• Objekt: Zahrnute su tu vsetky aktivity vyvijane vyskumnou skupinou.
• Obsah: Sprava o aktivitach - veduceho vyskumnej skupiny, vedenia skupiny, veducich jednotlivych pracovnych skupin. Stav vyskumu, progres oproti poslednemu anual reportu, financny stav (prijmy, vydaje).
• Forma: pdf, doc.
• Pokyny pre vytvorenie:
• Zodpovedna osoba: Veduci vyskumnej skupiny.
• Autori: Osoba poverena vytvorenim Anual reportu.
• Okolnosti vzniku/aktualizacie: Opakovane za urcite casove obdobie (zvycajne jeden rok).
• Umiestnenie: Interne tak aby informacie nevysli na verejnost. (napriklad mailinglist)
• Dostupnost: Clenovia vyskumnej skupiny.

Anual report (verejny)

• Ucel: Sprava o aktivitach vyskumnej skupiny za posledny rok.
• Objekt: Zahrnute su tu vsetky aktivity vyvijane vyskumnou skupinou.
• Obsah: Sprava o aktivitach - vyskumnej skupiny, jednotlivych pracovnych skupin. Stav vyskumu, progres oproti poslednemu anual reportu.
• Forma: pdf, doc.
• Pokyny pre vytvorenie:
• Zodpovedna osoba: Veduci vyskumnej skupiny.
• Autori: Osoba poverena vytvorenim Anual reportu.
• Okolnosti vzniku/aktualizacie: Opakovane za urcite casove obdobie (zvycajne jeden rok).
• Umiestnenie: Web, verejnost.
• Dostupnost: Verejnost.

Pracovna dokumentacia

• Ucel: Zaznemenat planovanie, rozvrh, organizaciu a projektove standardy.
• Objekt: Zahrnute su tu vsetky aktivity vyvijane vyskumnou skupinou.
• Obsah: Niekolko roznych dokumentov - plany, rozvrhy, oznamenia, standardy, working papers, e mail.
• Forma: pdf, doc, WEB, e mail.
• Pokyny pre vytvorenie:
  • Rozanalyzovat veci, ktore je potrebne spravit za najblizsie casove obdobie.
  • Rozdelit pracu medzi tym.
  • Zapisat to do rozvrhu a ten umiestnit na wiki a vypisat tickety na traci.
• Zodpovedna osoba: Veduci pracovnych skupin.
• Autori: Planovanie maju na starosti veduci pracovnych skupin, working papers su uz dielom samotneho vyvojara daneho objektu.
• Okolnosti vzniku/aktualizacie:
• Umiestnenie: WEB (wiki).
• Dostupnost: Verejnost.

MONICA propagacny material

• Ucel: Propagovat pracovnu skupinu
• Objekt: Pracovna skupina
• Obsah: Velim strucny opis skupiny, prinos skupiny pre spolocnost, propagacia skupiny, kontaktne informacie na skupinu, logo.
• Forma: WEB stranka, letak (white paper, data sheet ... ), buletin, poster, prezentacne slajdy.
• Pokyny pre vytvorenie:
  • Zhromazdit informacie uvedene v obsahu
  • Navrhnut material
  • Pred oficialnym vydanim konzultovat navrh so zodpovednou osobou
• Zodpovedna osoba: Veduci projektu a/alebo veduci pracovnych skupin.
• Autori: Osoba poverena vytvorenim propagacneho materialu.
• Okolnosti vzniku/aktualizacie: Vznik pracovnej skupiny/vazne zmeny v pracovnej skupine (zmena nazvu, loga, vedenia skupiny).
• Umiestnenie: Elektronicka podoba - WEB stranka projektu (oficialna verzia), svn (pracovna aj oficialna verzia). Tlacena podoba - podla potreby.
• Dostupnost: Verejnost. Potencialni pouzivatelia softverov vydanych skupinov.

Metodicke materialy

• Ucel: Uviesť návod ako písať jednotlivé dokumenty.
• Objekt: Vyvijany softver alebo jeho komponenty.
• Obsah: Návody, príručky, manuály, postupy.
• Forma: wiki.
• Pokyny pre vytvorenie:
  • Zhromazdit potrebne informacie
  • Zanalyzovat sucasne uz vytvorene dokumenty
  • Navrhnut material
  • Pred oficialnym vydanim konzultovat navrh so zodpovednou osobou
• Zodpovedna osoba: Veduci pracovnych skupin.
• Autori: Osoba poverena vytvorenim metodickeho materialu.
• Okolnosti vzniku/aktualizacie:
• Umiestnenie: Wiki.
• Dostupnost: Clenovia vyskumnej skupiny.

-- MarianJarembinsky - 26 Feb 2010