Analisi del sistema all'inizio del progetto

Il concetto pertinente è "progettazione evolutiva" ed è un elemento chiave dello sviluppo Agile. L'idea è che tu conosca il minimo assoluto di un sistema quando avvii il progetto, quindi perché bloccare tutte le tue false ipotesi all'inizio?

Ciò di cui hai bisogno è un processo che ti permetta di incoraggiare il cambiamento e l'incorporazione di nuove conoscenze nel tuo progetto mentre procedi attraverso lo sviluppo. Un'altra cosa che vuoi fare è tenere a bada tutti i processi decisionali fino all'ultimo momento, quando hai più informazioni.

Potresti scoprire che un approccio iterativo funziona meglio. Costruisci parte del sistema, fermati e dai un'occhiata a ciò che hai costruito e ciò che hai imparato sul sistema. Pensa a come il tuo design dovrebbe cambiare per essere migliore e come lo farai. Costruisci ancora e ripeti.

È quasi sempre impossibile progettare un UML per qualsiasi progetto non banale che mapperà correttamente il prodotto finale. Perché dovresti voler trattare il tuo UML con un riguardo più alto del progetto stesso. Le specifiche cambiano sempre, quindi il tuo progetto dovrebbe. Un UML, se ne hai uno, dovrebbe essere un documento vivente che cambia con le esigenze del progetto. Questo è il motivo per cui molti li trovano inutili, dal momento che non sono molto più che descrizioni ridondanti della struttura del progetto che devono essere mantenute continuamente.

Rispondendo alla seconda domanda separatamente:

Non solo è bene fare una rielaborazione di una nuova idea prima di arrivare all'implementazione, è anche da aspettarsi che il sistema sia completato (una sorta di) e messo in produzione.

Non esistono software finiti. Ogni progetto di software vivente (web o desktop) è un work in progress costante. Pianifichi la versione successiva mentre sviluppi quella attuale, ascolti il feedback degli utenti e adotti le cose di conseguenza, guardi il mercato e i concorrenti e reagisci a loro, sempre, ovunque sia necessario. Questo è l'unico modo per trasformare il tuo software in qualcosa che gli utenti desiderano veramente . Se non lo fai, i tuoi utenti saranno incazzati e se ne andranno. I concorrenti sono sempre lì a raccogliere dove hai lasciato cadere anche.

Sono d'accordo con @Developer Art. UML è usato raramente nei moderni negozi di sviluppo. Il modo migliore che ho trovato per specificare un progetto è una solida suite di test. Se non hai familiarità con lo Sviluppo guidato dai test , in questa metodologia, i tuoi test sono la fonte di ogni verità nel tuo progetto. Per prima cosa scrivi dei test che descrivono il "codice che desideri avere", per soddisfare le tue specifiche. Quindi scrivi il codice che fa passare quei test. Quindi tu refactoring.

UML è un pio desiderio. I test unitari sono una prova. Finché i test soddisfano le specifiche, devi solo passare i test. Se i requisiti cambiano, si modificano i test e si effettua il refactoring del codice fino a quando non superano i nuovi requisiti. Non è una panacea, ma è un modo MOLTO migliore di fare le cose rispetto alla riproduzione della logica di alcuni diagrammi UML costruiti in un ideale platonico dello sviluppo del software.

Penso che non ci sia nulla di sbagliato nella modifica di un programma durante lo sviluppo. Con il passare del tempo, si sviluppa una migliore comprensione del problema, inoltre è possibile rendersi conto che un approccio all'interfaccia utente può essere migliorato. I programmi sono come organismi viventi e il cambiamento attraverso il loro intero ciclo di vita. Puoi sempre trovare soluzioni migliori ai problemi. Il tuo compito è giudicare il tempo che valgono o meno.

Penso che l'approccio sia sbagliato. L'obiettivo non è un esercizio di disciplina (seguendo un design non importa quale), o vedere se riesci a sognare qualcosa di perfetto la prima volta. L'obiettivo è quello di creare qualcosa che sia utile, e che si spera possa fare un po 'di soldi.

Il punto principale è definire correttamente il tuo obiettivo. Ci sono molte aziende che hanno cessato l'attività perché non hanno definito correttamente la loro attività. Ad esempio le società di navigazione a vapore che si definivano società "a vapore", non aziende "di trasporto".

Non rimanere così concentrato su attaccare ciecamente a qualcosa articialmente . Adatta, innovare.

Cambiare idea, cambiare rotta, adattarsi, tutti i grandi pensatori e attivisti del mondo non hanno avuto alcuna complicazione nel cambiare idea e nel modificare il loro corso (Lincolm, Ghandi, Malcom X, ecc.!)

Molte persone hanno trovato una soluzione diversa a questo problema. Hanno abbandonato UML. Molti anni fa.

Ad oggi è utilizzato in due scenari:

• Uno strumento nel mondo accademico

• Un modo per descrivere alcuni elementi di architettura di progetti molto stabili

Non è assolutamente uno strumento di prototipazione.

Usa invece le tecniche di mind mapping, la semplice descrizione testuale dei momenti chiave e qualsiasi altra cosa che trovi utile e che funzioni per te. Un'altra cosa da considerare è che la modellazione non è davvero così essenziale. In effetti, scoprirai che puoi fare solo uno dei due: o hai passato la maggior parte del tuo tempo a modellare o hai fatto il vero lavoro di sviluppo. Le persone con inclinazione accademica come la modellizzazione, i professionisti la mantengono al minimo (ma non necessariamente la evitano del tutto).