Veloce e buono: (Requisito - Validazione - Design) per uso personale? [chiuso]

Solo perché lavori da solo non significa che potresti trascurare le tecniche di ingegneria corrette, come sembra che tu abbia già sperimentato per te.

Non è assolutamente possibile evitare di pensare e documentare un'architettura e un design adeguati per i componenti (considerando qualsiasi cosa tranne un componente banale). Dovrai affrontare i cambiamenti, il tuo progetto dovrà evolversi e a un certo punto non riuscirai a farlo se esiste solo da qualche parte tra il tuo cervello e il tuo codice.

Quello che suggerirei nel tuo caso è una sorta di approccio agile. Non è necessario creare la documentazione di qualcosa per averlo documentato perché alcuni processi lo richiedono. Quindi, invece, concentrati su ciò che è veramente importante per te. Solo documento, se pensi che in seguito creerà problemi se lasciato privo di documenti.

Inoltre, non puoi evitare di gestire i tuoi requisiti. Per questo esistono diversi strumenti e dovresti usarne uno che ti permetta di trascorrere il minor tempo possibile per iniziare. Strumenti ti aiuteranno anche nella visualizzazione e verifica (copertura dei test, interdipendenze, ecc.), Ma non ti aiuteranno nella convalida. La convalida è possibile solo se hai un qualche tipo di cliente (chi potrebbe essere il tuo capo nel tuo caso).

Infine, il punto più importante. La tua affermazione " non posso passare molto tempo a fare il corretto SRS o SDD. " è un grosso difetto nel tuo processo di pensiero. Pensa al tempo che sprechi ri-implementando il tuo lavoro. Pensa a tutti i problemi che hai riscontrato che alla fine ti hanno portato a postare qui. Quindi ripensateci, se davvero non siete in grado di dedicare tempo a tecniche di ingegneria adeguate. Se il tuo capo ti dice di non sprecare tempo in questo, allora è tempo che ti siedi per una lunga discussione, perché poi sei sulla buona strada.

C'è sempre un tipico conflitto da bilanciare quando si tratta di un approccio alla documentazione. E vorrei citare le tue parole per dire dov'è -

I can-not spend a lot of time doing proper SRS or SDD.

vs.

I don't want to waste my time coding something that's gonna collapse according to requirement conflict or something !!

Questo è un modello comune che quasi tutte le persone affrontano. E quando rimuovi i criteri secondo cui non ci sono altre persone con cui condividere questo, diventa ancora più inevitabile che noi non andiamo verso la documentazione. Ma hai posto un accenno alla domanda - "come fare documentazione" piuttosto che "se fare documentazione"

Il punto che volevo esprimere era essenzialmente l'equilibrio, tra sforzo e chiarezza. Gli approcci più semplici potrebbero solo aiutare.

1. evitare formalismo inutile - che rende molte persone più veloci. Non è che la digitazione lo renda lento, ma cercare una frase formale da mettere, dà fastidio a molti.

2. metti di più le cose come punti elenco e note - a volte puoi fare più articoli come cose esterne e collegarli.

3. Continua a scaricare tutto il materiale di lettura, i pensieri, le domande in atto e ad evolvere rapidamente in note e poi in argomenti. Continua a organizzare. per esempio inizialmente potresti avere un'idea di quali elementi dovrebbero esserci nel protocollo e in qualche altro nelle classi . nel tempo, raggruppando e mettendo tutti gli elementi relativi al protocollo in una sezione da solo. In questo modo continuerai ad evolvere un documento formale.

4. Continua a notare perché. Il motivo più importante per cui stai documentando (per te stesso) è tornare indietro e controllare perché sono state prese alcune decisioni. Quali alternative hai quando ti serve questo. Questo rende molto importante quando devi metterli in discussione.

5. Ultimo ma più importante, vai nello stesso posto. più spesso non ci preoccupiamo delle note quando arriviamo a una certa velocità con. Cerca di essere te stesso, oltre che formale, ma disciplina.

Se non ti prendi il tempo per un corretto sviluppo, spenderai 10 volte quel tempo per riparare il software in produzione. Peggio ancora, potresti perdere il lavoro e costare alla tua azienda.

La maggior parte dei problemi affrontati dagli sviluppatori può essere attribuita agli impegni presi riguardo ai tempi di consegna di un progetto. Sii chiaro con la tua direzione sulla necessità di tempo.

Se la società non ha risorse, forse potrebbero:

1-Dai priorità alle parti più richieste del sistema e chiedi di fare le migliori nel tempo stabilito 2-Assumere più persone per aiutare 3-Acquista un software pronto che funzioni, anche se non fa tutto il lavoro richiesto

Le tue domande coprono l'intera litratura dell'ingegneria del software e della gestione dei requisiti oltre ad altre parti dello spettro del software, quindi è impossibile darti una risposta completa, ma qui è veloce.

How should I :

1- List out Requirements for myself. (Not an official document) 2- How to verify and validate the requirements ? 3- How to visualize them ? 4- How to design them with minimum effort ? (As its going to be with me only)

Risposta 1: devi rompere l'area di business in quelli più piccoli (se è grande) - inserire i dati di input e le regole aziendali in modo chiaro per ognuno in un linguaggio chiaro e conciso e presentarlo come un elenco leggibile. Prova a creare alcuni casi d'uso per attività critiche.

Risposta 2: i risultati finali della risposta 1 sopra e le domande che ti verranno poste durante il completamento dell'attività sopra descritta ti aiuteranno a chiedere al cliente di lavorare con te per verificare i requisiti.

Risposta 3: Converti i risultati da 1 e 2 in un diagramma di classe e / o ERD, casi d'uso e diagrammi di sequenza o diagrammi BPM.

Risposta 4: utilizza strumenti come ORM, componenti GUI di terze parti e generatori di codice, se possibile.

Devi capire chiaramente:

• Obiettivi di sistema

• Diversi tipi di utenti del tuo sistema e implicazioni sulla sicurezza

• Qual è la migliore piattaforma per la soluzione

• La documentazione non è una perdita di tempo

• La comunicazione dell'utente è un must: coinvolgerli presto

• Il coinvolgimento e la comunicazione della gestione è un must: coinvolgerli presto

• Gli obiettivi e le stime realistici sono obbligatori

Buona fortuna