Documentazione tecnica e documentazione di progettazione del software

2

Sto cercando di avviare una documentazione su una libreria di classi che è già stata completata / sviluppata.

Lo scopo della documentazione deve essere utilizzato da altri sviluppatori per capire quale tipo di metodi sono inclusi in questa libreria di classi e come usarli. Più in particolare documentazione come lo strumento Javadoc che fornisce in base ai commenti XML per ogni metodo e attributo di classi.

Finora ho letto sul tipo di documentazione e sembra che le specifiche tecniche e la documentazione di progettazione del software siano quelle che forniscono tali informazioni.

Ma sono confuso su di loro perché non riesco a vedere molte differenze sulla base di alcune letture che ho già fatto.

Ad esempio qui , si dice che La documentazione di progettazione del software viene utilizzata per fornire una guida generale al team di sviluppo del software all'architettura del progetto software . E qui dice che Documentazione tecnica viene utilizzata per un nuovo sviluppatore che si unisce a un progetto software. Che tipo di informazioni sarebbero utili per essere introdotti nel progetto?

Da questo punto di vista, sembra che quella documentazione provi a far conoscere a uno sviluppatore di software ciò che è stato sviluppato finora. Ma qual è la differenza e quale usare per il mio scopo?

    
posta MrRobot 01.07.2018 - 21:45
fonte

2 risposte

5

Che cos'è una documentazione tecnica?

La vera definizione: Documentazione tecnica indica qualsiasi documento che i comuni mortali non capiscono a causa di alcune conoscenze specialistiche richieste.

La cattiva notizia è che non ti aiuterà a determinare cosa mettere dentro. La buona notizia è che da ora in poi puoi usare te stesso il concetto per qualificare tutto ciò che non capisci: "Uh! Queste linee guida contabili sembrano essere un documento molto tecnico" (e tutti, tranne i ragionieri, annunceranno, in silenzio concordando con tu).

Qual è l'obiettivo della tua documentazione?

La vera domanda: per la scrittura tecnica, come per qualsiasi scrittura, la prima domanda è sapere qual è il pubblico di destinazione e quale è lo scopo principale di questa documentazione:

  • È per i nuovi membri del team ? La cosa più importante è fornire una panoramica (ad es. Architettura e livelli, componenti principali), un modello di dominio di alto livello (ad esempio mappa contestuale ), nonché alcune informazioni sulle mani (ad es. struttura delle directory, set di strumenti utilizzato, convenzione di denominazione, link ad altri documenti importanti da leggere). I dettagli saranno comunque nel codice sia in codice pulito autoesplicativo o commenti utili.
  • È per utenti della biblioteca ? Javadoc o doxygen genereranno un'adeguata documentazione di riferimento in base ai commenti incorporati nel codice (quindi, si spera, facili da mantenere). Sfortunatamente, queste informazioni dettagliate non permetteranno di comprendere facilmente il design della tua biblioteca. Ancora una volta, è necessario fornire una panoramica di alto livello sull'architettura della libreria e su come i suoi diversi componenti interagiscono e dipendono l'uno dall'altro. Questo tipo di documentazione è DEVE AVERE se la tua biblioteca è un prodotto commerciale venduto da solo.

Un'ipotesi fatale sarebbe pensare che si possa fare una "documentazione tecnica" che copra qualsiasi necessità tecnica. Il livello di dettagli che deve essere compreso dal team (che deve conoscere gli interni) e gli utenti (che devono comprendere i casi d'uso e l'interfaccia) sono spesso molto diversi.

Alcuni consigli

Grady Booch ha esposto nel suo libro "Analisi orientata agli oggetti e tecnica di progettazione", il contenuto di una documentazione software desiderata:

  • High-level system architecture
  • Key abstractions and mechanisms in the architecture
  • Scenarios that illustrate the as-built behavior of key aspects of the system

Ha inoltre fatto un punto molto specifico:

It is far better to document these higher-level structures, which can be expressed in diagrams of the notation but have no direct linguistic expression in the programming language, and then refer developers to the interfaces of certain important classes for tactical details.

    
risposta data 01.07.2018 - 23:41
fonte
3

Esistono due tipi di documentazione di base: guida per l'utente e documentazione di riferimento .

(Alcune aziende riconoscono anche la panoramica come un tipo separato, vedi sotto).

Documentazione di riferimento elenca, diligentemente e accuratamente, l'intera interfaccia pubblica del prodotto: cosa significano ciascun parametro e parametro, quale input è considerato valido e cosa viene restituito in ogni caso ecc.

  • Nota la parola interfaccia pubblica : il suo obiettivo principale è specificare quali dettagli del comportamento osservato sono ufficialmente garantiti e quindi possono essere utilizzati. (Affermando o sottintendendo per omissione che tutto il resto è dettagli dell'implementazione, soggetto a modifiche e interruzione senza preavviso.)
  • Nota anche la parola "interezza". Il punto vendita principale di un riferimento è la sua completezza. Se non è nel riferimento, non esiste (ufficialmente). Se ho letto un riferimento su un argomento, posso essere certo che ora so tutto su quell'argomento e non ci saranno brutte sorprese.
    • Quindi, anche se un riferimento può essere utilizzato come materiale didattico, il suo caso d'uso principale è quello di colmare le lacune.

Poiché i principi di progettazione si manifestano direttamente nella struttura e nell'organizzazione dell'interfaccia pubblica, una documentazione di riferimento può contenere sezioni di panoramica su parti e aspetti dell'interfaccia e comportamento del prodotto prima di elencarne i dettagli (se non altro per evitare di ripeterle nelle voci per singole API).

  • Anche in questo caso, l'attenzione è rivolta all'interfaccia pubblica, quindi le spiegazioni si concentreranno sui dettagli visibili all'utente, fondamentali per comprendere l'organizzazione e il comportamento del prodotto, e i tecnicismi non importanti possono essere omessi o fatti a mano.
Lo scopo di

A Guida per l'utente è piuttosto quello di dimostrare come gli autori del prodotto prevedono l'utilizzo dell'interfaccia pubblica per risolvere problemi pratici e / o loro classi: schemi di utilizzo previsti, problemi generali tipici e soluzioni proposte (problemi locali ad API specifiche sembra piuttosto appartenere alle loro voci di riferimento).

Una guida per l'utente è intenzionalmente incompleta, fornendo solo la "grande immagine" e i puntatori chiave e lasciandola al riferimento per elaborare i dettagli.

La guida per l'utente può anche avere un testo di panoramica, ma il punto focale della panoramica qui è il pattern di utilizzo: che cosa è supposto essere chiamato dopo quello che, da quali posti ecc.

  • nota la parola supposto . Questa è una raccomandazione: "Questo è il modo in cui intendiamo essere il preferito". Che può (o non può) essere chiamato da dove il dominio della documentazione di riferimento è diretto.

Alcune società, ad es. Microsoft, segrega la panoramica di più alto livello in un tipo separato di documentazione. In molti posti in MSDN, vedresti una sezione su X divisa in: "Informazioni su X", "Uso di X" e "Riferimento X".

Come puoi vedere, la guida e il riferimento di un utente si completano a vicenda, coprono argomenti diversi e spiegano le cose da diversi punti di vista. Sebbene la guida sia più utile per l'utente nel breve periodo mentre la documentazione di riferimento a lungo termine.

  • Poiché il riferimento è completo, è "superiore" alla guida di un utente in quanto qualsiasi informazione che sarebbe presente in quest'ultimo può essere dedotta da esso, anche se a costo di una curva di apprendimento più ripida.

  • La guida per l'utente di OTOH è molto, molto più piccola e meno gravosa da mantenere, specialmente se l'interfaccia cambia rapidamente. Il rovescio della medaglia è che i tuoi utenti non sono mai sicuri se quello che stanno cercando di fare, a parte i pochi esempi che hai dato funzionino o no, quale sintassi è permessa dove ecc. - con conseguente enorme spreco del loro tempo.

man pages è un classico esempio di documentazione di riferimento. Alcuni autori della pagina man (ad esempio rsync ) hanno provato ad aggiungere sezioni guida dell'utente e, facendo ciò, hanno reso più difficile trovare le sezioni di riferimento necessarie.

    
risposta data 02.07.2018 - 00:57
fonte

Leggi altre domande sui tag