Ciclo di vita dello sviluppo del software nel settore

Le pratiche e gli SDLC all'interno del settore variano molto da un'azienda all'altra (o persino da una squadra all'altra all'interno della stessa azienda). Dalla tua descrizione sembra che l'SDLC come insegnato nella tua università sia un processo più formale, pesante, non- agile . Ci sono molti progetti che seguono questi processi (utilizzando termini, strumenti e artefatti diversi, ad esempio alcuni producono lunghi documenti Word come risultato dell'analisi, contengono testo puro, altri usano alcuni diagrammi UML, altri ancora diagrammi in un sistema di notazione completamente diverso. .). Ci sono anche lotti con un livello quasi nullo di processi formalizzati. E qualsiasi cosa tra questi due estremi.

Quindi la linea di fondo è, non c'è sicuramente un unico modo giusto per farlo. Una volta che inizi a lavorare in un team di progetto concreto, imparerai e aderirai alle loro convenzioni e processi locali comunque (il che, probabilmente, sarà molto diverso da quello che ti è stato insegnato all'università).

Ma se hai la possibilità di scegliere / modellare il tuo SDLC, ti suggerisco di essere pragmatico. Usa ciò che funziona per te (team r), rifletti regolarmente sui problemi / problemi che vedi e adattare di conseguenza i tuoi processi / strumenti. Come punto di partenza, ti consiglio di investigare su alcuni dei metodi Agile orientati agli sviluppatori e a bassa cerimonia.

In queste, le varie fasi non sono strettamente separate: si riconosce che non è possibile creare i requisiti / design perfetti in anticipo. Come accennato, in pratica penserai in anticipo ai possibili progetti per il tuo modello di dominio e alle possibili implementazioni del tuo progetto, e potresti persino creare un prototipo rapido per verificare alcune ipotesi all'inizio. Inoltre, durante la progettazione riceverai nuove domande e approfondimenti sui requisiti, e durante l'implementazione otterrai nuove realizzazioni che cambieranno e perfezioneranno il tuo design.

Queste sono solo le mie esperienze: non ho mai lavorato per un'azienda che ha seguito rigorosamente un SDLC. Ho lavorato per molte aziende che hanno un SDLC, ma mai uno che l'abbia seguito neanche lontanamente.

I gruppi IT tendono a crescere organicamente con il business, rilasciando rapidamente il software e rispondendo alla domanda dei clienti. Alla fine, l'IT diventa "abbastanza grande" per avere più livelli di gestione e un CTO (l'IT è "importante" ora).

Poi qualcosa va storto: sotto la pressione dei clienti, l'IT spedisce una versione buggy di un'importante applicazione e la linea di fondo è influenzata. Il business più ampio reagisce: "Come hai potuto permettere che ciò accadesse?"

Dopo aver risolto il problema, l'IT deve essere considerato come rispondente per assicurarsi che non accada mai più. Quindi introducono politiche e burocrazie e gli SDLC sono documentati. L'SDLC non è in realtà inteso a migliorare la capacità dell'IT di fornire software di qualità in tempo, ma a placare i CXO alla prossima riunione del consiglio. Quindi è pieno di spavalderia e pompa progettata per impressionare il CFO e il CMO e qualsiasi analista esterno che qualcuno decide di introdurre. Tutti coloro che sono coinvolti sanno che è una finta perdita di tempo e che non saranno seguiti, ma vanno d'accordo come i test di bogan il vino in un ristorante ("mm ... è rosso!").

Gli sviluppatori, naturalmente, tornano a lavorare in modo agile, costruendo cose che gli utenti chiedono e tagliando la burocrazia laddove possibile. Alcune parti dell'SDLC sono seguite - ad esempio, per gli accordi di rilascio - ma la maggior parte viene fatta semplicemente perché questa è La politica e l'interrogatorio è troppo politicamente sensibile.

Gli sviluppatori tendono a disegnare diagrammi e progettare modelli di oggetti, ma accadono molto organicamente e, se necessario, non strettamente come parte di una fase, a meno che non si tratti di The Policy, nel qual caso di solito si precipita solo per toglierlo di mezzo così il vero lavoro può iniziare.

Di seguito è la mia visione delle cose. È basato sulla mia esperienza come qualcuno che ha lavorato in un'azienda che ha avuto un SDLC di successo molto tempo fa. Divertente, ho lasciato un'altra grande azienda, perché la loro mancanza di utilizzo di SDLC! Non posso dire che tutto ciò che è qui è attualmente valido nelle metodologie e nelle tecniche odierne.

Concettualmente SDLC è un insieme di processi coerenti e integrati per fornire un prodotto. Gli obiettivi principali di una metodologia sono:

1 - Definisci le fasi di lavoro e le deliverable in modo che la gestione del progetto diventi possibile.

2 - Definire una piattaforma concettuale che l'organizzazione potrebbe migliorare man mano che cresce utilizzando le best practice del settore.

3 - Fermare l'organizzazione dal reinventare la ruota con ogni progetto identificando gli input e gli output di ogni attività / stage

4 - Ridurre al minimo lo stato di caos nel processo di sviluppo minimizzare la dipendenza da un singolo o un gruppo specifico di persone nell'organizzazione per sapere tutto - Questo è ottenuto con una buona documentazione e coinvolgendo diversi livelli nel processo

5 - Migliora la comunicazione tra lo sviluppo del prodotto, la gestione e le altre parti nell'organizzazione stabilendo una serie di termini, KPI e strumenti di comunicazione concordati.

L'SDLC raggiunge i suoi obiettivi utilizzando le migliori pratiche e strumenti adatti a ciascuno dei suoi processi.

L'impostazione / scelta di un SDLC non è banale e l'esecuzione delle attività SDLC è preziosa.

UML non è SDLC e viceversa. UML è uno degli strumenti che possono essere adottati da un determinato SDLC per produrre prodotti software, ma poi potrebbe non farlo. Ad esempio, non troverai troppi sviluppatori Mainframe CICS che utilizzano UML.

secondo il tuo punto:

Blockquote For example, will a domain class diagram, an not anything extra (from design class), be strictly the output from Analysis or Discovery phase? I'm sure many times you will think a bit about the technical implementation too? Else you might end up with a design class diagram later that is very different from the original domain class diagram? Blockquote

Hai ragione in questo. Un dominio mdoel non è necessariamente un modello di progettazione. La differenza tra i due è che un modello di dominio (chiamato cose diverse a seconda della metodologia che si utilizza) dovrebbe raccogliere importanti fatti e regole per le imprese durante la fase di analisi del business. Il concetto di un oggetto in analisi è molto ampio. L'obiettivo di tale modello sarebbe quello di memorizzare le informazioni raccolte in una forma che può essere utilizzata dai progettisti. Di solito è costruito dagli analisti, quindi se i due diagrammi delle classi sembrano simili, allora il soggetto è banale o ha solo una soluzione. Gli obiettivi del modello tecnico sono diversi. Esso eredita le regole, i dati e gli obiettivi di business dal modello di analisi, ma lo modella verso la generazione del codice, i requisiti specifici del database e le prestazioni. È completato da ingegneri del software e non analisti. Di conseguenza è diverso. Ad esempio, un numero cliente può essere una buona chiave per l'Enitty del cliente in analisi, ma nel database finisce per essere implementato come una colonna con indice univoco e viene invece utilizzato un numero di sequenza. Inoltre, non è raro vedere la classe cliente convertita in una classe astratta e diversi tipi di clienti ricevono le proprie classi (o viceversa)!

Riguardo alla tua domanda:

I also find it hard to remember what diagrams are from Initiation, Discovery, Design etc etc. Plus these phases vary from SDLC to SDLC, I believe? So I usually will create a diagram when I think will be useful. Is it the wrong way?

La metodologia dovrebbe definire le fasi del processo di sviluppo e quali diagrammi dovrebbero essere prodotti da quali professionisti e quali strumenti utilizzare per farlo.

Ad esempio, le sessioni di analisi dovrebbero includere pagine Web prototipate? Una pagina web prototipata non è sicuramente un diagramma UML! In generale, devi definire e perfezionare il tuo:

Usa diagrammi dei casi

Class Diagrams

Diagrammi delle attività

Diagrammi macchina dello stato

Ciascuno dei diagrammi precedenti ha uno scopo. Se studi bene gli scopi, ti sarà chiaro quando usarlo.

e non dimenticare il diagramma del modello di dati (ERD) - Ma ERD non fa parte di UML. Ancora una volta, UML non è abbastanza, almeno, quasi sempre non è abbastanza. Hai bisogno di strumenti integrati e di una metodologia e soprattutto di persone per portare a termine il lavoro.

Quindi, si crea un diagramma quando è utile, ma se si sta lavorando in un team con una metodologia è necessario seguirlo e non dimenticare di allocare il tempo per esso anche in un piano di progetto.

Alla fine di tutto questo, si prega di distinguere tra SDLC, UML, Project Management - Sono cose diverse (almeno per me!).

Buona fortuna.