• hjem
  •  > 
  • Nyttige ting om Windows 10
  •  > 
  • Utarbeiding og design av brukermanual for et programvareprodukt. Gi brukerne tilgjengelige og forståelige instruksjoner

Utarbeiding og design av brukermanual for et programvareprodukt. Gi brukerne tilgjengelige og forståelige instruksjoner

I avsnittet Kilder brukt i utviklingen, angi en liste over vitenskapelige og tekniske publikasjoner, regulatoriske og tekniske dokumenter og annet vitenskapelig og teknisk materiale som det refereres til i kildeteksten.

Det forklarende notatet er satt sammen av fagfolk innen utvikling programvare og for spesialister på samme ferdighetsnivå. Derfor er det hensiktsmessig å bruke spesiell terminologi, henvise til spesiallitteratur osv.

11.3. Brukerhåndboken

Som nevnt ovenfor, brukes for tiden ofte et annet driftsdokument, som delvis inkluderer veiledning av systemprogrammereren, programmereren og operatøren. Dette dokumentet kalles brukerveiledningen. Utseendet til et slikt dokument var en konsekvens av den omfattende spredningen personlige datamaskiner, arbeider med hvilke brukere som kombinerer de tre spesifiserte spesialistene.

Utarbeidelse av dokumentasjon for brukere har sine egne kjennetegn på grunn av at brukeren som regel ikke er profesjonell innen programvareutvikling. Boken til S. J. Grimm gir anbefalinger for å skrive slik programdokumentasjon:

ta hensyn til brukernes interesser - håndboken må inneholde alle nødvendige instruksjoner for brukeren;

være tydelig og bruke korte setninger;

unngå teknisk sjargong og høyt spesialisert terminologi; hvis det fortsatt er nødvendig å bruke noen begreper, bør de forklares;

vær presis og rasjonell - lange og forvirrende manualer leses vanligvis ikke av noen, for eksempel er det bedre å gi en tegning av et skjema enn å beskrive det i lengden.

Brukerhåndboken inneholder vanligvis følgende avsnitt:

generell informasjon om programvareproduktet;

installasjonsbeskrivelse;

lanseringsbeskrivelse;

bruksanvisning (eller brukergrensesnittbeskrivelse);

meldinger til brukeren.

Kapittel Generell informasjon Om programmet inneholder vanligvis navnet programvareprodukt, Kort beskrivelse dens funksjoner, implementerte metoder og mulige bruksområder.

Installasjonsdelen inneholder vanligvis Detaljert beskrivelse handlinger for å installere programvareproduktet og meldinger som kan mottas.

Lanseringsdelen beskriver som regel trinnene for å starte programvareproduktet og meldingene som kan mottas.

Kapittel Bruksanvisningen inneholder vanligvis en beskrivelse av driftsmoduser, input/output formater og mulige innstillinger.

Kapittel Meldinger til brukeren må inneholde en liste mulige meldinger, en beskrivelse av innholdet deres og handlinger som må iverksettes som svar på disse meldingene.

11.4. Systemprogrammeringsveiledning

I henhold til GOST 19.503-79 må systemprogrammererens manual inneholde all nødvendig informasjon for å installere programvaren, konfigurere den og teste funksjonaliteten. I tillegg, som nevnt ovenfor, inkluderer den ofte en beskrivelse av nødvendig vedlikehold, som tidligere ble gitt i brukerhåndboken (GOST 19.505-79) og/eller håndboken vedlikehold(GOST 19.508-79). For tiden dette diagrammet brukes til å kompilere en systemadministratorveiledning.

Systemprogrammererens manual bør inneholde følgende avsnitt:

Generell informasjon om programvareproduktet,

struktur,

innstilling,

undersøkelse,

tilleggsfunksjoner,

meldinger til systemprogrammereren.

Generell informasjon om programmet bør inneholde en beskrivelse av formålet med og funksjonene til programmet, samt informasjon om teknisk og programvare som sikrer kjøringen av dette programmet (for eksempel volumet tilfeldig tilgangsminne, krav til sammensetning og parametere eksterne enheter, programvarekrav osv.).

I kapittel Programstruktur informasjon om strukturen til programmet må gis,

henne komponenter, forbindelser mellom komponenter og om forbindelser med andre programmer.

Avsnittet Sette opp programmet bør inneholde en beskrivelse av trinnene for å sette opp programmet for forholdene for praktisk bruk.

Avsnittet Testing av programmet bør inneholde en beskrivelse av måter å kontrollere funksjonaliteten til programmet på, for eksempel testeksempler.

I kapittel Tilleggsfunksjoner en beskrivelse må gis tilleggsfunksjoner programmer og måter å få tilgang til dem på.

I kapittel Meldinger til systemprogrammereren Tekstene til meldinger utstedt under konfigurasjon og testing av programmet, samt under utførelse av det, må angis en beskrivelse av innholdet og handlingene som må iverksettes som svar på disse meldingene.

11.5. Grunnleggende regler for utarbeidelse av programvaredokumentasjon

Ved utforming av tekst og grafisk materiale inkludert i programvaredokumentasjon gjeldende standarder må følges. Noen bestemmelser i disse standardene er gitt nedenfor.

Design av tekst og grafisk materiale. Tekstdokumenter tegnes på ark i A4-størrelse, mens grafisk banning kan presenteres på ark i A3-størrelse. Marginene på arket bestemmes i samsvar med de generelle kravene: venstre - minst 30, høyre - minst 10, topp - minst 15, og bunn - minst 20 mm. I tekstredigerere for utforming av et notat, er sideparametere sortert avhengig av utskriftsenheten. Når du fyller ut dokumenter manuelt, velges sideparametere for enkelhets skyld.

Alle sidene nummereres fortløpende. Tallet er angitt øverst til høyre med et arabisk tall. Sidene inkluderer både ark med tekst og bilder, og ark med applikasjoner. Den første siden anses å være tittelsiden. Sidenummer på tittelside De legger det ikke fra seg.

Navnene på seksjonene er skrevet med store bokstaver midt på linjen. Avstanden mellom overskrifter og tekst, samt mellom seksjons- og underavsnittsoverskrifter, skal være lik:

når du utfører et dokument ved å skrive - to intervaller;

når det er ferdig håndskrevet - 10 mm;

når du bruker tekstredigerere - bestemt av evnene til redaktøren. Navnene på underseksjoner og avsnitt skal plasseres med avsnittsinnrykk og skrive ut

ute av funksjon med stor bokstav, uten understreking og uten punktum på slutten. Avstand mellom siste linje teksten i forrige seksjon og den påfølgende overskriften, når de er plassert på én side, skal være lik:

når du utfører et dokument ved å skrive - tre intervaller;

når det er gjort håndskrevet - minst 15 mm;

når du bruker tekstredigerere - bestemt av evnene til redaktøren.

Seksjoner og underseksjoner er nummerert med arabiske tall med en prikk. Seksjoner skal ha løpenummer 1, 2 osv. Underseksjonsnummeret inkluderer seksjonsnummer og serienummer underseksjon inkludert i denne seksjonen, atskilt med en prikk. For eksempel: 2.1, 3.5. Henvisninger til avsnitt, seksjoner og underavsnitt indikerer, ved å bruke serienummeret til seksjonen eller avsnittet,

eksempel "i Sect. 4", "i klausul 3.3.4".

Teksten til avsnitt skrives ut med 1,5-2 intervaller. Ved bruk av tekstredigering skal høyden på bokstaver og tall være minst 1,8 mm (skrift nr. 11-12).

Oppføringer skal nummereres med arabiske tall med en parentes, for eksempel: 2), 3) osv. - med et avsnittsinnrykk. Det er tillatt å markere en opplisting ved å sette en bindestrek foran et tekstelement eller et symbol som erstatter det i tekstredigering.

Design av tegninger, algoritmediagrammer, tabeller og formler. I samsvar med GOST 2.105-79 " Generelle Krav til tekstdokumenter»-illustrasjoner (grafer, diagrammer, diagrammer) kan gis både i hovedteksten og i vedlegg. Alle illustrasjoner kalles tegninger. Alle figurer, tabeller og formler er nummerert sekvensielt med arabiske tall ( kontinuerlig nummerering) eller innenfor en seksjon (relativ nummerering). I søknaden - i søknaden.

Hver tegning må ha en bildetekst - en tittel plassert under tegningen, for eksempel:

Fig. 12. Hovedmeny vindu form

Alle figurer, tabeller og formler i notatet skal ha lenker i formen: «(fig. 12)» eller «formen til hovedmenyvinduet er vist i fig. 12".

Hvis plassen tillater det, bør figurer og tabeller plasseres umiddelbart etter avsnittet de først er nevnt i, eller så nært som mulig avsnittet på de etterfølgende sidene.

Hvis en tegning opptar mer enn én side, er alle sidene unntatt den første merket med tegningsnummeret og ordet «Fortsettelse». For eksempel:

Ris. 12. Fortsettelse

Figurer bør plasseres slik at de kan sees uten å bla. Hvis slik plassering ikke er mulig, bør bildene plasseres slik at siden må roteres med klokken. I dette tilfellet er den øvre kanten den venstre kanten av siden. Plasseringen og størrelsen på feltene er bevart.

Algoritmediagrammer skal lages i henhold til ESPD-standarden. Tykkelsen på den heltrukne linjen ved tegning av algoritmediagrammer skal være fra 0,6 ... 1,5 mm. Inskripsjoner på diagrammer skal gjøres med tegneskrift, høyden på bokstaver og tall skal være minst 3,5 mm.

Tabellnummeret er plassert til høyre øverste hjørne eller før tabelloverskriften, hvis det er en. Tittelen, bortsett fra den første bokstaven, er skrevet med små bokstaver.

Testresultatene er vist i tabell. 4.

Formelnummeret er plassert på høyre side av siden i parentes på formelnivå. For eksempel:

z: =sin (x)+In (y);

Design av applikasjoner. Hver søknad må starte med ny side angir ordene «SØKNAD» med store bokstaver og har en tematisk overskrift i høyre hjørne. Hvis det er mer enn én applikasjon, er de alle nummerert med arabiske tall: APPENDIKS 1, APPENDIKS 2 osv. For eksempel:

VEDLEGG 2

Forlikets tittelside og forklarende notat

Figurer og tabeller plassert i vedlegget er nummerert med arabiske tall innenfor hvert vedlegg med tillegg av bokstaven "P". For eksempel:

Ris. Sak 12 - 12. tegning av søknaden; Ris. Sh.2 - 2. bilde av 1. vedlegg.

Hvis applikasjonen inneholder teksten til programmet, er hver fil utformet som en tegning med navnet på filen og dens formål, for eksempel:

Ris. P2.4. Fil menuran.pasprogram for markørbevegelse av hovedmenyen.

Lage en referanseliste. Litteraturlisten skal inneholde alle kilder som brukes. Informasjon om bøker (monografier, lærebøker, manualer, oppslagsverk osv.) skal inneholde: forfatterens etternavn og initialer, tittel på bok, utgivelsessted, forlag, utgivelsesår. Hvis det er tre eller flere forfattere, er det tillatt å angi etternavnet og initialene til bare den første av dem med ordene "osv." Forlaget må siteres i sin helhet i nominativ tilfelle: forkortelse av navnet på bare to byer er tillatt: Moskva (M.) og St. Petersburg

Informasjon om en artikkel fra et tidsskrift må inneholde: forfatterens etternavn og initialer, navnet på artikkelen, publikasjon (magasin), serie (hvis noen), utgivelsesår, volum (hvis noen), nummer på publikasjonen ( magasin) og sidetall som artikkelen er plassert på.

11.6. Regler for utarbeidelse av beregning og forklarende notater for kursutforming

Når du utarbeider forklarende notater, bør du følge GOST 7.32-91 (ISO 596682) "Rapport om forskningsarbeid. Struktur og designregler." I samsvar med denne standarden må et tekstdokument av denne typen inneholde:

tittelside,

abstrakt,

innhold,

introduksjon,

hoveddelen,

konklusjon,

liste over kilder som er brukt, inkludert litteratur,

applikasjoner.

Tittelsiden er utarbeidet i samsvar med GOST 19.104-78 "Unified system of program documentation. Grunnleggende inskripsjoner" (Fig. 11.1).

Den andre siden er et sammendrag eller sammendrag av programvareproduktet som utvikles. Sammendraget i komprimert form bør inneholde informasjon om dokumentets volum, antall illustrasjoner, vedleggstabeller etc., samt en liste over nøkkelord og hovedbestemmelsene i dokumentet. For eksempel for en rapport om forskningsarbeid: beskrivelse av forskningsobjektet, mål for arbeidet, forskningsmetoder og utstyr, oppnådde resultater, anbefalinger for gjennomføring osv. Merknaden beskriver også kort formål og trekk ved utviklingen, men den inneholder vanligvis ikke informasjon om volum osv.

Tredje side - innhold, inkludert: introduksjon, navn på alle seksjoner, underavsnitt, avsnitt, konklusjon, referanselister og bruksområder angir sidetall. Verken merknaden eller abstraktet eller selve innholdet er nevnt i innholdsfortegnelsen.

Deretter følger delene av dokumentet i rekkefølgen bestemt av logikken i presentasjonen av materialet. Dette kan etterfølges av vedlegg som inneholder materiale som ikke er inkludert i dokumentet på grunn av dets begrensede volum, men interessant for en dypere forståelse av materialet som presenteres.

Som et eksempel, se innholdsfortegnelsen i forklarende notat for prosjektet for kurset "Programmeringsteknologi".

Introduksjon................................................. ...................................................... ............................................................ ..........

1.Valg av teknologi, språk og programmeringsmiljø......................................... ............................................

2.Analyse og avklaring av krav til programvareproduktet.................................. ............................

2.1.Analyse av og valg av strukturer

data for lagring ........................................................ ...................................................... ............................

2.2.Valg av metoder og utvikling av grunnleggende algoritmer for å løse problemet...................................

3.Utvikling blokkdiagram programvareprodukt ................................................... ............................

4. Utforming av brukergrensesnitt......................................... ......................................................

4.1.Konstruksjon av en dialoggraf........................................... ............................................................ ............... .......

4.2.Utvikling av informasjon input-output skjemaer......................................... ............................................

5. Utforming av domeneklasser................................................... ............................................................... .....

5.1.Konstruere et klassediagram......................................................... ........................................................ .........

5.2 Avklaring av strukturen til domeneklasser

og utvikling av metodealgoritmer......................................... ................................................................ ...........

6.Valg av teststrategi og testutvikling......................................... ........................................

Konklusjon................................................. ................................................................ ........................................................

Bibliografi................................................ . ................................................................ ............................................

Vedlegg 1. Tekniske spesifikasjoner.................................................. ...................................................... ............ ..

Vedlegg 2. Brukerveiledning.................................................. ......................................................

Kontrollspørsmål

1. Nevn hovedtypene programvaredokumentasjon. Beskriv hver av dem. I hvilke tilfeller brukes de?

2.Hva skal beskrives i forklaringen? Hvem er den beregnet på? Hvorfor beskriver et forklarende notat vanligvis ikke bare beslutninger tatt, men også avviste alternativer?

3.Hvem er brukerveiledningen ment for? Hva skal den inneholde? I hvilke situasjoner leser du bruksanvisningen? Tenk tilbake på brukermanualene du har lest. Hva likte du ikke med dem?

APPLIKASJON

Unified Modeling Language (UML) notasjonssystem

Unified Modeling Language UML – faktisk standard middel beskrivelser av prosjekter laget ved hjelp av en objektorientert tilnærming. Programvareprosjektmodellen, som ment av språkforfatterne, kan inkludere et stort nummer av diagrammer forskjellige typer ved hjelp av enhetlig system notasjon. Blant diagrammene er de mest brukte:

bruk kasusdiagrammer eller presedenser (bruker case-diagrammer) - viser hovedfunksjonene til systemet for hver type bruker;

klassediagrammer(klassediagrammer): kontekstuelle, beskrivelser av grensesnitt og implementeringer - demonstrere relasjonene mellom klasser med hverandre;

aktivitetsdiagrammer(aktivitetsdiagrammer) - representerer et diagram over kontrollflyter for å løse en bestemt oppgave ved hjelp av individuelle handlinger; de tillater tilstedeværelsen av parallelle og/eller alternative handlinger;

interaksjonsdiagrammer(interaksjonsdiagrammer) av to alternative typer:

a) sekvensdiagrammer (sekvensdiagrammer) - vis den tidsordnede interaksjonen til objekter under utførelsen av en brukssak,

b) samarbeidsdiagrammer(samarbeidsdiagrammer) - gi samme informasjon som sekvensdiagrammer, men i en form som lar deg bedre representere klassenes ansvar som helhet;

objekttilstandsdiagrammer(statechart-diagrammer) - viser tilstandene til et objekt og betingelsene for overganger fra en tilstand til en annen;

pakkediagrammer(pakkediagrammer) - demonstrere forholdet mellom sett med klasser kombinert til pakker;

komponentdiagrammer(komponentdiagrammer) - vis hvilke programvarekomponenter programvaren består av og hvordan disse komponentene er sammenkoblet;

plasseringsdiagrammer(distribusjonsdiagrammer) - lar deg koble til programvare- og maskinvarekomponenter i systemet.

Tillegg til diagrammene er formaliserte og uformelle tekstbeskrivelser, kommentarer og ordbøker.

Når du konstruerer disse og andre diagrammer, brukes et enhetlig notasjonssystem. Betegnelsene til presedensdiagrammene er gitt i tabell. Punkt 1, klasse- og pakkeskjemaer - i tabell. Punkt 2, interaksjonsdiagrammer - i tabell. P3, diagrammer over aktiviteter og tilstander til objektet - i tabell. Punkt 4, diagram over komponenter og plassering - i tabell. S.5. Om nødvendig er det tillatt å bruke betegnelsene til noen diagrammer på andre.

For mange programvareutviklere er det ikke det å lage teknisk dokumentasjon enkel oppgave. Først og fremst fordi det innebærer møysommelig og kjedelig arbeid som kan vare i ukevis. For å beskrive en applikasjon, må du nøye gå gjennom funksjonene, ta mange skjermbilder, lime dem inn i et tekstdokument, legge til beskrivelser, forklaringer, forklaringer og merknader, jobbe med strukturen...

Hva trenger du for å lage en hjelpefil? De fleste bruker PrntScr-knappen for dette og tekstredigerer. Men faktisk kan du nekte begge deler. Det er programmer og webtjenester som mange utviklere (og til og med forfattere av teknisk dokumentasjon) rett og slett ikke er klar over eksisterer. Spesialiserte løsninger for å lage manualer, brukerveiledninger og andre lignende dokumenter kombinerer som regel en tekstredigerer med minimumssett funksjoner, et program for å lage skjermbilder, samt verktøy for eksport til populære dokumentformater. Dessuten gjør noen av disse programmene mesteparten av jobben for brukeren, og arrangerer uavhengig skjermbilder i ønsket rekkefølge og til og med legger til beskrivelser. La oss se på de fem mest vellykkede, etter vår mening.

⇡ Clarify 2.0.5 - hurtighåndbøker uten ekstra programvare

  • Utvikler: Blue Mango Learning Systems.
  • operativsystem: Windows/Mac.
  • Distribusjon: shareware, $30.
  • Russisk grensesnitt: nei.

I vid forstand er Clarify en lett tekstredigerer som legger til verktøy for rask opprettelse skjermbilder Denne enkle setningen skjuler imidlertid mange timers tid som kan lagres av tekniske dokumentforfattere. Med Clarify trenger du ikke hele tiden å bytte mellom to apper eller kaste bort tid på å sette inn skjermbilder – alt er på ett sted.

Programvinduet er delt inn i to deler: til venstre arbeid pågår med overskrifter, og til høyre - med innholdet i manualen. Hver overskrift kalles her et "trinn". Så snart forfatteren oppretter en ny tittel, ber programmet deg umiddelbart om å lage et skjermbilde for den og legge til tilhørende tekst. Hver ny overskrift blir automatisk nummerert, og du kan enkelt lage underoverskrifter, også nummererte. Men hvis du ikke trenger seksjonsnumre i dokumentet ditt, kan du ganske enkelt deaktivere denne funksjonen. Ved hjelp av hurtigtaster kan overskrifter raskt flyttes mellom seksjoner.

For å legge til et skjermbilde hvor som helst i dokumentasjonen, bare velg ønsket tittel og klikk på skjermbildeknappen. Hvis skjermbilder ble opprettet tidligere, kan du legge dem til dokumentet ved å spesifisere banen til dem på disken. Du kan ta et skjermbilde enten umiddelbart eller med en kort forsinkelse (opptil fem sekunder), noe som kan være praktisk hvis du trenger å ta et skjermbilde av en rullegardinmeny eller et annet grensesnittelement som ikke alltid vises på skjermen. Ved å trykke på mellomromstasten kan du bytte mellom å ta hele skjermen eller det gjeldende vinduet. I tillegg er det hurtigtaster for å slå på/av markørvisningen og for å fange et område av samme størrelse som forrige skjermbilde. Den siste funksjonen er veldig praktisk hvis du trenger å ta dusinvis av samme type skjermbilder, siden det sparer tid på å velge ønsket område.

Det resulterende skjermbildet settes umiddelbart inn i dokumentasjonselementet som ble uthevet. Det som er interessant: I navigasjonslinjen er elementer som allerede er lagt til skjermbilder visuelt merket for. Takket være dette kan du umiddelbart finne ut hvilke seksjoner som fortsatt trenger arbeid.

Formatet som skjermbildet skal lagres i, bestemmes i applikasjonsinnstillingene. Programmet kan automatisk generere ALT-tagger for bilder, skalere dem når de settes inn i et dokument opp til riktig størrelse(den originale kopien er også lagret), legg til en ramme, rund kantene.

Clarify har grunnleggende verktøy for å jobbe med bilder og tekst. Dermed kan bilder roteres, beskjæres, legges til tekst eller kommentarer, piler, rektangler og andre. grafiske objekter, som kan være nyttig for visuelt å fremheve områder i et skjermbilde.

Når du jobber med tekst kan du bruke nummererte og punktlister, innsetting av kode, hyperkoblinger, innrykk. For noen språk fungerer grammatikkkontroll mens du skriver, og det er et søk og erstatning av data i dokumentet.

Du kan samarbeide om Clarify-prosjekter med andre brukere. For å gjøre dette må du lage regnskap på Clarify-it.com. I tillegg støtter programmet Dropbox og Evernote-tjenester, og gjør det mulig å eksportere prosjekter til PDF-, Word-, HTML- og WordPress-sider. Hvis du ønsker det, kan du også ganske enkelt kopiere hele teksten i dokumentet (eller tekst med bilder) til utklippstavlen.

Når du eksporterer, kan du velge et designtema, legge til topptekster og bunntekster og administrere ulike visningsparametere (avhengig av formatet). For eksempel er tre temaer tilgjengelige for eksport til Word, og ferdig dokument presentert som en perfekt formatert fil, med stiler, overskrifter, lister, hyperkoblinger. Dette er en fornøyelse å jobbe med, spesielt hvis du husker hvor mye tid du trenger å bruke manuelt på å gjøre denne formateringen i Word.

Også interessant er funksjonen til å eksportere alle skjermbilder til en mappe. Når du gjør dette, lagrer Clarify alle bildene som brukes i dokumentet i en gitt mappe og gir hver fil et navn som samsvarer med tittelen på seksjonen den er knyttet til.

⇡ Dr.Forklar 5.3 - halvautomatiske veiledninger med ferdige merknader

  • Utvikler: Indigo Byte Systems.
  • Distribusjon: shareware, fra 7500 rubler.
  • Russisk grensesnitt: ja.

Dr.Explain har ikke et så moderne grensesnitt som Clarify, men dette programmet har sine egne unike funksjoner. Det viktigste er kanskje automatiseringen av prosessen med å lage teknisk dokumentasjon. Bare spesifiser programvinduet eller tjenestenettsiden du vil beskrive, og Dr.Explain vil uavhengig lage et skjermbilde, analysere alle grensesnittelementer, legge til bildetekster og til og med merke dem der det er mulig.

Hvis det er en meny i grensesnittet til den fangede applikasjonen, vil Dr.Explain definitivt utvide den, ta et øyeblikksbilde av alle undermenynivåer og legge til bildetekster for hvert element. Dessuten vil alle skjermbilder bli plassert i Dr.Explain-prosjektet mens strukturen til dokumentet opprettholdes (det vil si at hovedvinduet vil være i seksjon 1, den utvidede menyen vil være 1.1, og undermenyelementene vil være 1.1. 1, 1.1.2 og så videre). Dermed er alt kjedelig og monotont arbeid utført i automatisk modus, og brukeren trenger bare å legge til en beskrivelse av alle grensesnittelementer. Det er tydelig at strukturen til dokumentet kan endres ved å flytte elementer, legge til nye og slette unødvendige.

Selv før du tar skjermbilder, kan du konfigurere mange innstillinger relatert til bilder. For eksempel er det mulig å angi plasseringen av bildetekster, stilen på merknader, og bestemme alternativet for å generere filnavn (i samsvar med seksjonsoverskrifter eller deres nummer).

Har du tidligere jobbet med dokumentasjon i en annen applikasjon, kan du enkelt importere prosjektet og programmet. Dr.Explain støtter import av CHM, Word, HTML, HLP, RTF, TXT, XML-dokumenter.

Samarbeid om dokumentasjon er organisert gjennom Tiwri.com-tjenesten, laget spesielt for datautveksling mellom Dr.Explain-brukere. Fra programvinduet kan du laste opp det gjeldende prosjektet til serveren, sende endringer, tilbakestille redigeringer og spore historikk.

CHM, Word, HTML og PDF-formater er tilgjengelige for eksport av ferdig dokumentasjon. Dessuten, selv før du eksporterer, kan du se hvordan manualen vil se ut i et av disse formatene. Før du eksporterer, må du huske å gå til prosjektinnstillingene og angi Ekstra alternativer. For eksempel, når du lagrer et dokument til PDF, kan du spesifisere søkeord, forfatter, tittel, emne og format, tilpass topp- og bunntekst og sidenummerering, og lag bokmerker for seksjoner. Ved eksport til HTML er det mulig å tilpasse nettstedskartet, legge til kommentarer for Facebook-brukere og Disqus, aktiver visning av knappepanelet sosiale nettverk, spesifiser detaljene for FTP-serveren som prosjektet skal lastes opp til.

Til slutt er det verdt å ta hensyn til det faktum at Dr.Explain er et produkt fra innenlandske utviklere, så det er ganske forventet at du kan finne full støtte for det russiske språket i det.

⇡ Manula - overføring av manualer online

  • Utvikler: Bitz & Pixelz.
  • Operativsystem: alle.
  • Distribusjon: ved abonnement (fra $10 per måned).
  • Russisk grensesnitt: nei.

Tidlig i 2009 bestemte Alwin Hoogerdijk, skaperen av Collectorz.com-familien av applikasjoner for samlingsadministrasjon, å lage online hjelp for programmene sine. Han var lei av at han ofte måtte utsette utgivelsen av nye versjoner av programmer på grunn av at endringer i programvaren ennå ikke var klare. brukerdokumentasjon, eller omvendt, gjør nye utgivelser tilgjengelige for nedlasting med utdaterte hjelpefiler, og slipp deretter nye versjoner der bare håndbøkene er oppdatert.

For å gjøre prosessen med å legge til dokumentasjon mer praktisk for utviklere, og få tilgang til den raskere for brukere, ønsket Alvin å flytte alt på nettet. Han begynte å søke etter et spesialisert innholdsstyringssystem for å lage teknisk dokumentasjon. Og da det viste seg at ingenting slikt eksisterte, skapte utvikleren eget system for din familie av applikasjoner. Det ble senere utviklet til et mer allsidig kommersielt produkt, Manula.com.

Manula.com lar deg lage og oppdatere manualer i nettleseren din, uten behov for skrivebordsapplikasjoner. Den største fordelen med en online manual er umiddelbar oppdatering. Så snart utviklerne har gjort endringer i den, er de oppdaterte hjelpefilene allerede tilgjengelige for brukere - det er ikke nødvendig å eksportere noe hvor som helst, laste opp HTML-filer til serveren, og så videre. Samtidig ser manualer like bra ut på alle enheter – på store skjermer, nettbrett eller smarttelefoner. Tjenesten tilpasser seg automatisk skjermstørrelsen.

Og hvis brukeren ønsker å få en kopi av manualen for offline visning, er dette ikke vanskelig i det hele tatt. Manula tilbyr praktisk nedlasting av manualer laget på plattformen i PDF-format.

Manula har også innebygde verktøy for å spore endringer og motta tilbakemeldinger fra brukere. De blir bedt om å vurdere spesifikke temaer i referansedokumentasjonen. For utviklere er det visuell statistikk over rangeringer og antall besøk ulike seksjoner Håndbok. Takket være dette kan du alltid forstå hvor manualen må forbedres, gjøres mer detaljert eller kobles til andre seksjoner.

Håndbøker laget med Manula har et integrert søkesystem - seksjonsoverskrifter, dokumentasjonsinnhold og nøkkelord spesifisert av utvikleren tas i betraktning. Tjenesten lagrer historikk søk og viser det til utviklerne populære spørsmål, noe som gjør det enkelt å gjøre endringer i titler og søkeord.

En av interessante funksjoner Manula - Emnedeling-funksjon. Hvis et selskap har flere lignende produkter, kan individuelle hjelpefragmenter gjøres felles for dem. Hovedforskjellen fra å kopiere ferdige fragmenter av dokumentasjon er at når du bruker funksjonen for emnedeling, trenger du bare å gjøre endringer på ett sted. I dette tilfellet vil dokumentasjonen bli oppdatert automatisk i alle applikasjoner. Variabler (for eksempel (APPNAME)), som er konfigurert separat for hver brukerhåndbok, bidrar til å automatisere prosessen ytterligere.

Vanlige hjelpebiter kan også brukes til å lage separat dokumentasjon for ulike versjoner av en applikasjon. For å forhindre at brukere kaster bort tid på å søke etter funksjoner de ikke har, kan du lage separate manualer for hver versjon. I dette tilfellet vil hoveddelen av hjelpen administreres ved hjelp av funksjonen for emnedeling.

Det er ikke noe innebygd verktøy for å ta skjermbilder i Manula - du må laste ned ferdige bilder til bildebiblioteket (det er felles for alle prosjekter) og lim det deretter inn på de nødvendige stedene i dokumentasjonen. Å legge til tekst gjøres også i nettredaktøren, og her kunne tjenesteutviklerne finne på noe interessant. Sammen med å bruke visuell redaktør Det anbefales å jobbe med tekstilkoder for å fremskynde formateringsprosessen. Disse kodene gjør det mulig å formatere tekst uten å måtte ha tilgang til redigeringsknappene. For eksempel, hvis tekst må utheves, må den bare omsluttes av to stjerner (*som dette*), og for å lage en overskrift på første nivå, skriver du bare h1- på begynnelsen av linjen.

⇡ StepShot - vil ta bilder, ordne dem i rekkefølge og signere dem

  • Utvikler: StepShot.
  • Operativsystem: Windows.
  • Distribusjon: ved abonnement ($29 per måned). Det er en fullt funksjonell prøveversjon i 14 dager, som deretter blir begrenset.
  • Russisk grensesnitt: nei.

Nesten hver brukerveiledning inneholder nødvendigvis instruksjoner som forklarer hvilke skritt som må tas for å oppnå et gitt resultat. Å lese slike guider, der hvert trinn er ledsaget av et skjermbilde og forklaring, er en fornøyelse, men det tar ofte lange timer. Noen tekniske skribenter skriver teksten først og tar deretter alle skjermbildene og limer dem inn på de riktige stedene, andre foretrekker å ta skjermbilder ett om gangen, lime dem inn i manualen og umiddelbart legge til en beskrivelse. Det viser seg uansett å være ganske arbeidskrevende.

StepShot- flott program, noe som bidrar til å fremskynde opprettelsen betydelig trinnvise instruksjoner. Det hjelper deg raskt å ta alle skjermbildene, uten å bli distrahert av å lagre og lime inn, og plasserer dem i i riktig rekkefølge, hjelper deg å legge til beskrivelser og merknader, og deretter publisere i et av de populære formatene.

Arbeid i StepShot er bygget i form av en veiviser. Trenger å lage nytt prosjekt, og start deretter fangstprosessen og begynn å utføre de handlingene som er underlagt dokumentasjon. Hver gang du klikker med musen, vil programmet lage et skjermbilde og lagre det. Samtidig er StepShot-panelet konstant på skjermen, som du kan stoppe opptaksprosessen med og endre modusen for å ta skjermbilder (hele skjermen, aktivt vindu, valgt rektangulært område).

Dette panelet er selvfølgelig ikke synlig i skjermbildene. Avhengig av innstillingene, kan fangsten bare skje når du klikker mens du holder nede CTRL (eller en annen praktisk tast) eller omvendt i alle tilfeller bortsett fra når brukeren holder nede den angitte tasten. I programinnstillingene kan du også stille inn forsinkelsen mellom klikket og opprettelsen av skjermbildet.

Når er fullført, vil alle resulterende bilder åpnes i StepShot-vinduet. Til venstre er et navigasjonspanel med miniatyrbilder av bilder, til høyre er et skjermbilde det jobbes med, samt et område for å legge til en beskrivelse. Skjermbildene er allerede ordnet i den rekkefølgen de ble tatt, men om nødvendig kan de omorganiseres ved å dra musen. I tillegg kan hvert trinn (skjermbilde med beskrivelse) kopieres eller slettes, eller du kan også legge til et tomt trinn foran det, som du for eksempel kan importere et bilde fra disk.

Hvis instruksjonen er lang, er det fornuftig å dele den opp i seksjoner ved å legge til separatorer på de riktige stedene. For hver seksjon er det mulig å sette et navn. Basert på avsnittene vil det automatisk bli generert en innholdsfortegnelse, som vil bli plassert i begynnelsen av manualen.

Vanligvis, når du lager opplæringsprogrammer, brukes mye tid på å markere området der markøren er plassert i skjermbildet (vanligvis stedet der du må klikke). StepShot gjør det mulig å automatisere denne rutinehandlingen også. Grensesnittelementet som klikkes på kan automatisk fremheves med et rødt rektangel eller en gul sirkel. I tillegg kan programmet automatisk jevne ut kantene på skjermbilder.

På stadiet med redigering av de mottatte skjermbildene - allerede inne manuell innstilling- du kan legge til piler, infomeldinger eller andre grafiske elementer og fremhev visse områder av bildet med farger. Og hvis du trenger å trekke leserens oppmerksomhet til flere områder i ett skjermbilde, kan du bruke sekvensverktøyet. Dette lager linjer med tall på slutten. Bare plasser dem på de riktige stedene i bildet og legg til en beskrivelse.

Å legge til beskrivelser er også så automatisert som mulig. Siden de samme setningene oftest brukes når du skriver teknisk dokumentasjon, gir programmet skjermbilder med beskrivelser som "Klikk på "Skype"-knappen." For å gjøre dette, fanger den opp navnene på grensesnittelementer, gjenkjenner dem og legger dem deretter til bildeteksten under bildet. Dette fungerer imidlertid bare for engelsk og et par andre europeiske språk, og kompilatorene av russiskspråklig dokumentasjon må legge til alle beskrivelsene manuelt.

Formateringsalternativer i StepShop er grunnleggende - du kan endre skriftstørrelsen for skjermdumptitler og beskrivelser, markere tekst i fet, kursiv eller understreket, kontrollere innrykk og sette inn hyperkoblinger. Ikke glem at du kan legge til en beskrivelse og forfatter for prosjektet ditt før du eksporterer.

Når du er ferdig med å lage guiden, kan du eksportere den til ett av flere støttede formater: Word-dokument, PDF, HTML, DITA eller XML. Det finnes imidlertid flere forskjellige maler tilgjengelig for Word.

Det er også direkte publisering til Wordpress og Confluence, og alle bilder som brukes i prosjektet foreslås lagret i én mappe. Dessverre kan du kun kontrollere kvaliteten på bildene, men du kan ikke endre navnene. Skjermbilder lagres med navn som image0001.jpg, image0002.jpg, noe som ikke alltid er praktisk (det ville vært fint om det var mulig å navngi bilder basert på titler i prosjektet).

Til tross for at StepShot distribueres på betalt basis, kan du jobbe med programmet gratis hvis du er villig til å tåle et vannmerke på de resulterende bildene. I tillegg, gratis versjon lar deg opprette opptil fem eksporterte prosjekter per måned.

⇡ iorad - analogStepShot, men i nettleseren

  • Utvikler: iorad inc.
  • Operativsystem: alle.
  • Distribusjon: ved abonnement ($90 per måned). Det er en begrenset gratisversjon.
  • Russisk grensesnitt: nei.

For å komme i gang med iorad må du installere utvidelsen for Google Chrome og åpne en nettside der handlingene skal dokumenteres. Etter dette må forfatteren klikke på utvidelsesknappen. Nettjenesten iorad bruker samme tilnærming som StepShot (forfatteren av instruksjonene utfører alle trinnene, tjenesten lagrer dem, deler dem ned i trinn, som deretter kan redigeres og publiseres som en leksjon). Imidlertid fungerer iorad som en nettleserutvidelse, og all behandling, redigering og publisering av trinnvise instruksjoner gjøres på serveren. På den ene siden er dette praktisk, siden tjenesten er tilgjengelig på enhver plattform, men det er en irriterende begrensning - ved å bruke iorad kan du bare registrere handlinger utført i nettleseren. Det vil si at tjenesten kun egner seg for å lage manualer for webapplikasjoner, og er ikke egnet for skrivebordsprogrammer.

Når den er trykket, vil iorad gi tre sekunder på seg til å forberede seg før opptaket begynner. Tjenesten gjenkjenner og lagrer alle handlinger - museklikk, Dobbeltklikk, rulle et vindu, skrive og så videre. Når registreringen av instruksjonene er fullført, trenger du bare å klikke på utvidelsesknappen igjen Krompaneler. Prosessen kan også settes på pause en stund og deretter gjenopptas.

Når opptaket er fullført, vil iorad gjenopprette alle brukerhandlinger og dele opp instruksjonene i trinn. Alle grensesnittelementer som ble aktivert vil bli uthevet (for eksempel en knapp som må klikkes). I tillegg legger iorad automatisk til enkelt tekstinstruksjoner for hvert trinn.

Hver leksjon begynner med setningen "Det første trinnet er å åpne [navn på nettsiden]" og slutter med uttrykket "Det er det". Du er ferdig." Til tross for at beskrivelser automatisk kun kompileres på engelsk, er det i de ferdige instruksjonene mulig å se dem på andre språk på grunn av integrasjon med Google Oversetter. Hvis du ikke legger til lange beskrivelser, men begrenser deg til enkle fraser, fungerer en slik oversettelse tålelig.

Men hvis du bruker litt tid, kan du umiddelbart legge til en beskrivelse på morsmålet ditt. Det er imidlertid verdt å huske at lengden på beskrivelsen er begrenset til 250 tegn. Den kan brukes forskjellige varianter skriftstil, samt hyperkoblinger. I tillegg kan du legge til opptil ett minutt med lydinstruksjoner for hvert trinn. Det kan tas opp direkte i nettapplikasjonsgrensesnittet eller lastes ned fra filer tilgjengelig på datamaskinen din.

Når det gjelder verktøy for å redigere skjermbilder, har skaperne av iorad fortsatt litt arbeid å gjøre. Alt brukeren kan gjøre er å gjøre en del av bildet uskarpt og endre størrelsen og plasseringen av utvalgsrammen.

Ferdige instruksjoner kan lagres som filer Word Doc, PowerPoint og PDF, og innebygd på nettsteder eller vist i en nettleser på hvilken som helst plattform, skrivebord eller mobil. Ved å bruke de to siste alternativene kan du sette pris på hovedfordelen med iorad - interaktivitet. Instruksjonene mottatt ved hjelp av tjenesten lanseres i en spesiell spiller. Brukeren kan velge ett av alternativene for å jobbe med det: vise eller uavhengig gjenta alle trinnene.

I det første tilfellet vises alle skjermbilder og beskrivelser for dem på én side, og du kan ganske enkelt lese hva du skal gjøre. I det andre tilfellet blir brukeren bedt om å gjenta alle handlingene til forfatteren for å oppnå ønsket resultat. Det vil si at han leser beskrivelsen av skjermbildet, utfører handlingen, og først etter det går han videre til neste trinn. Perfekt løsning for å sikre at brukeren faktisk forstår hva de må gjøre.

⇡ Konklusjon

Spesialiserte programmer for å lage manualer kan øke hastigheten på opprettelsen av teknisk dokumentasjon betydelig. Hvor klar, detaljert og strukturert hjelpefilen vil være, avhenger imidlertid helt av kompilatorene.

Når du arbeider med dokumentasjon, er det alltid verdt å huske "Goldilocks-prinsippet": brukeren skal ikke gis for mye informasjon, ikke for lite, men nøyaktig så mye som er nødvendig for å fullføre oppgavene. God dokumentasjon skal fungere som en navigator: når brukeren har vist hvor han er (hvilket problem han har støtt på), bør han umiddelbart bruke hjelpefilen for å finne riktig vei (løsning på problemet). Og selvfølgelig, ikke glem om hyperkoblinger, som du må gi fri bevegelse bruker i henhold til manualen. Hvis i hendene hans detaljert PDF 100 sider lang, hvor det ikke er referanser, kan kvaliteten på slik dokumentasjon vanskelig vurderes av andre enn kompilatoren.

Derimot, moderne virkemidler for å skape referanseguider er så mangfoldige og multifunksjonelle at det ikke er vanskelig i det hele tatt å lage detaljert, forståelig og godt utformet dokumentasjon med deres hjelp.

Programvarekomponent i et kompleks eller system

Mål og målsettinger

Brukerhåndboken er en av de viktigste programdokumenter. Det er umulig å forestille seg noe komplekst applikasjonsprogramvareprodukt som ikke ville være utstyrt med det i en eller annen form.

Hovedmålet med dokumentet er å gi brukerne muligheten til selvstendig å løse alle hovedoppgavene som programmet er rettet mot.

Brukerhåndboken inneholder fullstendig beskrivelse av programmet ut fra dets tiltenkte bruk. Brukerhåndboken skal beskrive:

  • formålet med programmet;
  • hovedutfordringer og muligheter;
  • måte å reflektere fagområdet i programmet på;
  • brukergrensesnitt programmer;
  • prosedyre for å løse grunnleggende brukeroppgaver;
  • alle funksjoner i programmet og rekkefølgen av deres bruk;
  • tilpassede programinnstillinger;
  • problemer under bruk og måter å løse dem på.

Ved dokumentering av små programmer inneholder brukermanualen ofte instruksjoner for installasjon, konfigurering, administrering, oppdatering og på annen måte vedlikehold av programmet.

Brukerhåndboken blir aldri, eller nesten aldri, betraktet som læremiddel etter fagområde.

Metodikk og presentasjonsstil

Avhengig av funksjonene i programmet og målgruppen, kan brukermanualen i måten materialet presenteres på ligge nær en lærebok eller omvendt en oppslagsbok. Rekkefølgen for presentasjon av materiale i brukerhåndboken bestemmes brukerperspektiv programmer.

Hvis programmet er et verktøy som lar deg løse praktiske problemer fra et bestemt begrenset sett gir håndboken standardprosedyrer for å løse hver av dem. For eksempel bruker e-postklient du trenger å vite hvordan du skriver og sender en melding, hvordan du laster ned nye meldinger fra serveren, hvordan du svarer på en melding osv. Hver av disse handlingene kan deles opp i påfølgende elementære trinn, i det minste for typiske situasjoner. I et stort program som brukeroppgaver det kan være mange, men ikke uendelig mange. Brukerhåndboken, bygget på prinsippet om brukeroppgaver, ligner en lærebok, selv om den som regel mangler det metodiske apparatet som er iboende i lærebøker: testoppgaver, spørsmål, øvelser.

Hvis programmet representerer et miljø der brukeren kan løse problemer tildelt av ham selvstendig, bør brukerhåndboken være nærmere en oppslagsbok. Den må konsekvent og systematisk beskrive alle funksjonene til programmet og rekkefølgen på deres bruk. Hva de skal gjøre med dem, hva de skal henvise dem til, vil brukeren tenke selv (eller registrere seg for opplæringskurs). Så i brukerhåndboken for den grafiske editoren finner vi en beskrivelse av alle grafiske primitiver, verktøy, filtre, men det vil ikke direkte si hvordan man skal skildre en bygning, en bil eller for eksempel en hund. Brukeren vet enten hvordan han skal tegne eller ikke.

Andre brukerperspektiver er mulige. Det er programmer der brukeren kontrollerer tilstanden til et bestemt objekt, for eksempel en industriell installasjon. Deretter er brukermanualen bygget på prinsippet om en tabell: programmeldingen - reaksjonen eller mulige reaksjoner fra brukeren.

Hvis brukeren bruker programmet til å løse problemer i ikke-trivielt fagområder, anbefales det sterkt å inkludere en konseptdel i brukerhåndboken. Den skal beskrive måten programmet implementerer representasjon av virkelige objekter, slik at brukeren har en god forståelse av hvilke av dem og på hvilket abstraksjonsnivå han kan arbeide.

Typisk struktur

På grunn av den store variasjonen av programmer, er det vanskelig å forestille seg en universell brukermanualstruktur. I hvert enkelt tilfelle vil det hovedsakelig bestemmes av funksjonene til programmet som beskrives. Strukturen til brukerhåndboken er imidlertid vanligvis lik den nedenfor.

  1. Generell informasjon.
  2. Installasjon og innledende oppsett.
  3. Grunnleggende begreper og definisjoner.
  4. Brukergrensesnitt.
  5. Arbeider med programmet.
  6. Egendefinert innstilling.
  7. Feilmeldinger.

En enkelt seksjon "Arbeide med programmet" erstattes ofte av flere påfølgende seksjoner som beskriver store grupper av brukeroppgaver eller funksjoner.

Egendommer

På grunn av en historisk hendelse er brukerhåndboken ikke gitt av nasjonale standarder for programvaredokumentasjon (ESPD). Av de som er beskrevet i ESPD, er dokumentet nærmest det i formål og innhold brukermanualen. Det må imidlertid forstås at operatøren, som er ment i ESPD, har lite til felles med brukeren i den nåværende forståelsen.

Eh... dette er "livet"!

Jeg ble overbevist av et personlig eksempel om at å skrive brukermanualer ikke er en så lett oppgave... Spesielt hvis du ikke kjenner programvareproduktet det må kompileres for!

Så hvordan skriver du en brukermanual?

For ikke lenge siden fikk jeg jobb ny jobb til et selskap som er engasjert i utvikling og implementering av et programvareprodukt... alt ville være bra.. men jeg snublet allerede på mitt første oppdrag..

Jeg fikk i oppgave å skrive en brukermanual for et program som jeg aldri hadde sett før (det virker som noe fra regnskap, som jeg ikke er så god på). Ingen gamle versjoner av brukermanualer, ingen eksempler... bare meg og programmet... I prosessen med arbeidet møtte jeg noen fallgruver, som jeg skal prøve å beskrive i denne artikkelen.

Det ser ut til at det kan være vanskelig! Det er et program... litt idédugnad- og alt er gjort!!! Selvfølgelig er det mest ideelle alternativet hvis brukerhåndboken er skrevet av utvikleren av "naturens mirakel" selv, eller i det minste av en bruker som har jobbet i systemet som er beskrevet i lang tid.

Hva skal man gjøre hvis dette ikke er tilfelle?! Det første trinnet er å løpe til utvikleren og virkelig "sitte på nakken" slik at han "tygger" sitt "hjernebarn" fra begynnelsen til det helt ekstreme nivået!!! I slike tilfeller er det bedre å forestille seg deg selv som en "Hvorfor" og gå til bunnen av de minste detaljene. Dessverre vil ikke programmererens nerver sette pris på en slik impuls! Men her er valget enkelt, heller god guide, eller utveksle hyggelige ting og bare...

I alle fall må du se på programmet "fra utsiden" gjennom øynene til en pioner! Etter tidligere å ha identifisert funksjonsmodulene og modulen som er av størst interesse for sluttbrukeren (det er best beskrevet i detalj!), er det nødvendig å bestemme detaljnivået til den utformede håndboken. Vanligvis diskuteres dette problemet med ledelsen i utviklerorganisasjonen, men det kan gjøres etter eget skjønn.

Etter min erfaring er det bedre å bruke litt tid på design når du skriver en brukermanual generell struktur forklarende notat, enn deretter skrive for hver funksjonell modul separate manualer. Faktum er at jo mer standardisert (strukturert) manualen er, jo lettere er det for brukeren å navigere og jo lettere er det å beskrive! Med en gjennomtenkt beskrivelsesstruktur, sannsynligheten for å "glemme" å vise noen nøkkel øyeblikk betydelig redusert!

Det finnes også en slik godt poeng- Dette er GOST-standarder! For å beskrive brukermanualer er det en så fantastisk GOST som GOST 19.505-79 ( for beskrivelse se delen av nettstedet).

Slik skriver du en brukermanual:

Hovedretningslinjen for å skrive håndboken er følgende beskrivelse:

  • formålet med programmet (hvorfor trengs det i det hele tatt, hvem er det rettet mot osv.);
  • meldinger til operatøren (beskrivelse mulige feil, brukermeldinger osv.).
  • programutførelsesbetingelser (min. og maks. krav til maskinvare og programvare);
  • programutførelse (beskrivelse av programfunksjonalitet, sekvens av operatørhandlinger, etc.);

Som et eksempel kan jeg tilby min egen metode for å beskrive programutførelse. Først må du analysere hele programvareproduktet som beskrives og bestemme inndelingen i individuelle moduler (seksjoner osv.).

Samtidig må du definere menyfunksjoner, repeterende feltnavn og annen funksjonalitet som er standard gjennom hele modulen, delen av programvareproduktet osv.

1. Kort beskrivelse

2. Modul A

  • Undermodul A.1
  • Undermodul A.2

3. Modul B

  • Undermodul B.1
  • Undermodul B.2

"Kort beskrivelse"-delen inneholder en kort beskrivelse av modulene A og B, og beskriver også de gjentatte menyelementene, feltnavnene osv. som er karakteristiske for begge modulene. Videre i beskrivelsen av selve modulen/delmodulen er det beskrevet kort algoritme arbeider med en modul/undermodul (laster ned, viser, legger til, redigerer, sletter, genererer rapporter osv.), hvoretter det gis en mer detaljert beskrivelse av all funksjonalitet og alle tilgjengelige felt.. Alt er med andre ord i detaljene !

Spesifikasjonene til feltene er beskrevet, hvilke operasjoner som er involvert i å fylle dem ut, hvilke verdier som tildeles automatisk, i hvilke tilfeller vises feltene i det hele tatt, typene felt, alle knappene, avmerkingsbokser.. Generelt, her kan du beskrive ad infinitum!!!

Hvis en modul inneholder undermoduler, er det bedre å beskrive alt i en streng rekkefølge. Dvs. i begynnelsen, beskriv selve modulen (fra start til slutt), mens du lager en lenke til den tilsvarende undermodulen, og nedenfor - beskriv hele undermodulen i detalj! Det viser seg nok Fint bilde! Brukeren trenger ikke å hoppe fra en del av dokumentet til en annen og tilbake.

Og slik er hele programvareproduktet beskrevet. Til slutt kan du skrive en liste over forkortelser som brukes når du beskriver brukermanualen.

Det er ingen tvil om at denne teknikken er generalisert! Men fra min erfaring kan jeg si sikkert, det er veldig praktisk! Praktisk for brukeren, praktisk for utvikleren av brukerhåndboken! Alle er fornøyde.. 😉

Men som de sier, det er ingen venn etter smak! Vi kan bare ønske deg vellykket utvikling!

Se relaterte artikler