Come posso migliorare nello spiegare i processi software complessi agli sviluppatori? [chiuso]

5

Sono davvero alle prese con le mie specifiche del software. Non sono un programmatore professionista, ma mi diverto a farlo per divertimento e ho creato un software che voglio vendere in seguito, ma non sono soddisfatto della qualità del codice. Quindi volevo assumere un vero sviluppatore per riscrivere il mio software in un modo più professionale, in modo che possa essere gestito da altri sviluppatori in futuro.

Ho letto e trovato alcune specifiche di esempio e ho fatto da me applicando la loro struttura al mio documento e ho voluto che il mio amico sviluppatore lo leggesse e mi desse consigli. Dopo un'ora e mezza ha capito esattamente cosa stavo cercando di fare e come l'ho fatto (i miei algoritmi, stack, ecc.).

Come posso migliorare nello spiegare le cose agli sviluppatori? Aggiungo molti dettagli e spiegazioni per tutto (incluso il codice di lavoro), ma non sono sicuro che il modo migliore per imparare a passare conoscenza dettagliata del dominio (Il mio software applica i big data, l'apprendimento automatico, la teoria dei grafi per finanziare). Il mio obiettivo finale è far capire loro il più possibile dal documento e poi chiedere tutto ciò che non capiscono, ma in questo momento sembra che debbano estrarre molte informazioni da me. Come posso migliorare la comunicazione della conoscenza del dominio agli sviluppatori?

    
posta Lostsoul 06.10.2012 - 16:08
fonte

3 risposte

7

Suggerirei di saperne di più sulle attività a monte nello sviluppo del software, in particolare l'ingegneria dei requisiti e l'architettura del sistema. Queste due attività sono l'interfaccia diretta tra il cliente e le esigenze e l'ambiente dell'utente per la persona o le persone che stanno creando software. Queste attività non derivano direttamente solo dagli input dell'utente e del cliente, ma forniscono anche gli input a livello di sistema e test di accettazione.

Quando mi è stato insegnato ingegneria dei requisiti e progettazione di alto livello, mi è sempre stato insegnato a coinvolgere le parti interessate giuste dall'organizzazione sponsor: il cliente, l'utente, le persone che manterranno il sistema e così via. Queste persone non dovrebbero solo essere coinvolte nel prendere decisioni, ma anche capire come verrà costruito il sistema e cosa sarà necessario da loro per tutto il progetto. Prendere l'iniziativa e apprendere queste aree da solo aiuterebbe ad interfacciarsi con le persone che costruiranno il software.

Se desideri risorse specifiche, Karl Wiegers ha due libri sull'ingegneria dei requisiti - Requisiti software e Ulteriori informazioni sui requisiti software . Posso anche consigliare due libri su come vengono create le architetture e i progetti software: Architettura dei sistemi software: lavorare con le parti interessate usando i punti di vista e le prospettive e Architettura software in pratica .

    
risposta data 06.10.2012 - 16:22
fonte
3

Utilizza metafore .

Da blog di Herbjörn Wilhelmsen :

A metaphor is an analogy between ideas. We use metaphors to explain or understand something in terms of something else...

...Human thinking depends on metaphor. We understand new or complex things in relation to things we already know...

...Metaphor stretches imagination in a way that can create powerful insights...

Il famoso scienziato informatico Fernando J. Corbató ha detto :

The value of metaphors should not be underestimated. Metaphors have the virtue of an expected behavior that is understood by all. Unnecessary communication and misunderstandings are reduced. Learning and education are quicker. In effect metaphors are a way of internalizing and abstracting concepts allowing one's thinking to be on a higher plane and low-level mistakes to be avoided.

Dalla pp. 9-12 di Codice completo di Steve McConnell 2 :

Important developments often arise out of analogies. By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic. This use of metaphor is called "modeling"...

...In general, the power of models is that they're vivid and can be grasped as conceptual wholes. They suggest properties, relationships, and additional areas of inquiry...

...The history of science isn't a series of switches from the "wrong" metaphor to the "right" one. It's a series of changes from "worse" metaphors to "better" ones, from less inclusive to more inclusive, from suggestive in one area to suggestive in another...

...Software development is a younger field than most other sciences. It's not yet mature enough to have a set of standard metaphors. Consequently, it has a profusion of complementary and conflicting metaphors. Some are better than others. Some are worse....

...Over time, though, the person who uses metaphors to illuminate the software-development process will be perceived as someone who has a better understanding of programming and produces better code faster than people who don't use them.

In effetti, McConnell parla direttamente a la tua preoccupazione sull'uso di metafore imperfette o imperfette. [P. 20]

...Because metaphors are heuristic rather than algorithmic, they are not mutually exclusive... Use whatever metaphor or combination of metaphors stimulates your own thinking or communicates well with others or your team.

Using metaphors is a fuzzy business... If you extend them too far or in the wrong direction, they'll mislead you. Just as you can misuse any powerful tool, you can misuse metaphors, but their power makes them a valuable part of your intellectual toolbox.

E dopo aver imparato le metafore, impara come disegnare.

Il libro di Dan Roam intitolato 'Il retro del tovagliolo' illustra come la capacità di disegnare possa rendere chiunque un comunicatore molto potente.

E tu non devi essere Pablo Picasso. Devi solo essere pulito e premuroso.

    
risposta data 07.10.2012 - 03:26
fonte
1

Inizia l'implementazione di RTVM (matrice di verifica della tracciabilità dei requisiti) per il tuo progetto. Può essere un po 'noioso, ma mi ha davvero aiutato a comprendere i diversi aspetti dello sviluppo del software.

Un RTVM sembra essenzialmente un V gigante e ruota essenzialmente attorno a Why | Cosa | Come. Ogni livello inferiore fornisce il Come per i perché e i WHIS dal livello superiore. Sul lato sinistro della V, passerai attraverso i requisiti delle applicazioni in requisiti del modulo in specifiche funzionali. Sul lato destro della V, fornirai modi / mezzi per verificare i requisiti corrispondenti di quel livello.

Alcuni link per aiutarti a iniziare:
Tracciabilità dei requisiti
Matrice di tracciabilità

Cerca su google "Matrice di verifica della tracciabilità dei requisiti" fornirà anche molte risorse.

    
risposta data 06.10.2012 - 20:39
fonte

Leggi altre domande sui tag