Il vostro processo di sviluppo software imprevedibile come il tempo? Il tuo software di gettare un'ombra che causa altre sei settimane di programmazione? Stai utilizzando un documento di marketing requisiti (MRD) o la magia per prevedere il piano di rilascio del software?
All'inizio della mia carriera, ho lavorato in un laboratorio per una società che ha venduto dispositivi a microonde. Sono stato responsabile del sistema di computer HP, che ha eseguito il software utilizzato per la progettazione dei circuiti. Un giorno un tizio del supporto tecnico da parte di HP è venuto da. Ha chiesto quello che abbiamo fatto in laboratorio. Quando gli ho detto "la progettazione di circuiti a microonde", ha detto, "Oh, ho sentito dire che usare un sacco di FM".
Mi fermai e cercai di ricordare se modulazione di frequenza era molto utilizzato in questi circuiti. Prima che potessi rispondere, il ragazzo da HP ha continuato, "Sì, ci vuole un sacco di F ----- g Magic a fare quei lavori circuiti!"
Aveva ragione. Uno dei problemi principali con i circuiti a microonde in quei giorni era li con la creazione di un processo di fabbricazione ad alto rendimento. Troppo spesso non vi era molta sintonia e la messa a punto dei dispositivi individuali con stuzzicadenti e pinzette per fare le date di spedizione.
Da allora ho lavorato su un paio di progetti software in cui è stata richiesta una certa quantità di "FM" per ottenere il software rilasciato.
Come sono i tuoi progetti software? Hanno deriva lungo mai sembrano finire? Saranno necessari gli sforzi eroici di pochi individui per rendere le tue date di spedizione?
Outsourcing in grado di risolvere i problemi della release del software in ritardo di più imponendo sul processo di sviluppo del software - più di processo che viene in genere utilizzata in un'organizzazione in cui tutti stanno lavorando in stretta vicinanza.
fornitori di outsourcing bisogno di avere un processo ben definito e di comunicazione eccellente per avere successo. Lo sviluppo del software è tutto ciò che fanno. L'outsourcing non solo offre il vantaggio di avere il vostro software sviluppato ad un costo minore, ma anche un processo che fornisce una migliore prevedibilità, risultati e il successo.
Ma molti restano timorosi di outsourcing. La prima preoccupazione è di perdere il controllo del processo di sviluppo software.
Un cliente ha espresso in questo modo. "Non posso semplicemente dire che i programmatori che cosa fare in un giorno per giorno. E 'come l'assunzione di un imprenditore di costruire una casa e dicendogli di mettere una finestra laggiù e una porta qui. Devi capire l'impatto che avrà sulla idraulici ed elettrici e la costruzione del resto della casa. "
Ha ragione. È necessario avere qualche idea di architettura e il piano per la costruzione. Lavorando insieme con un paio di programmatori nella stessa stanza a volte può farti fare delle scelte rapide e condividere il piano con la parola informale di bocca. "Basta mettere una finestra pop-up qui."
Fatta eccezione per i progetti di piccole e semplici, questa comunicazione informale non funziona. Hai bisogno di qualche descrizione dei requisiti per il software. Hai bisogno di trovare un modo per comunicare in modo efficiente i requisiti del software in modo da poter andare oltre la fase di "idea" con la visione per il software.
Il primo passo nella creazione di un prodotto software è quello di scrivere un documento Requisiti di marketing o di MRD. Esso contiene una breve descrizione di tutte le caratteristiche, funzioni e vantaggi del prodotto deve avere per avere successo nel mercato.
Alcune aziende fanno una distinzione tra un MRD e PRD - un prodotto Requisiti dei documenti. Il PRD ha maggiori dettagli su quello che il programma dovrebbe fare. Ad esempio, è necessario sia un MRD e PRD durante la creazione di diversi servizi e prodotti. Il MRD descrive la strategia di prodotto, posizionamento di mercato e canali di vendita tenuti a consegnare i prodotti con gruppi specifici di funzionalità al mercato. Il PRD d'altra parte si concentra sui requisiti specifici del software stesso.
Il MRD o PRD devono comprendere l'architettura di base e l'interfaccia utente critici per il software:
* Software architettura
* La piattaforma hardware scelta
* Le specifiche funzionali
* User interface design
* Multiple "casi d'uso" che descrive come gli utenti interagiranno con il software
* Storia di demo board (opzionale)
* Major release milestone calendario
* Controllo qualità
* Documentazione tecnica requisiti
* Programma dettagliato (fino a completamento della prima pietra miliare)
* Costo preventivo per lo sviluppo di costo-efficiente e tempo effettivo di outsourcing
Il documento di commercializzazione requisiti o MRD descrive la funzionalità del prodotto software e come sarà venduto e distribuito. È anche un dispositivo per controllare il processo di sviluppo software, soprattutto se in outsourcing. Altrimenti si corre il rischio di ritardi, scarsa qualità e non solo sapere cosa si sta facendo.
No comments:
Post a Comment