Useresti UML se impediva alle parti interessate di richiedere modifiche frequenti? [chiuso]

Il tuo problema è una mancanza di comunicazione tra te e i tuoi manager / stakeholder.

Non capiscono i problemi che possono causare cambiamenti frequenti, anche se hai un processo agile in atto.

Ma allo stesso modo gli sviluppatori non capiscono la necessità che il programma sia progettato per risolvere o il processo aziendale come dovresti.

Perché dico questo?

Se i manager avevano familiarità con il processo di sviluppo, allora sapevano quando era il momento opportuno per richiedere le modifiche - prima dell'inizio del prossimo sprint, o quando il documento di progettazione per la fase successiva veniva scritto ecc.

Se gli sviluppatori hanno capito meglio il problema, il prodotto sarebbe più vicino alle esigenze degli stakeholder.

Devi affrontare il problema di comunicazione e mettere in atto procedure per gestire la modifica, perché la modifica avverrà .

Nascondersi dietro i diagrammi UML (o le specifiche, o anche le story card) non risolverà il problema.

In termini gernerali, se le modifiche minori richiedevano aggiornamenti ai diagrammi UML, considererei i diagrammi troppo dettagliati. Ho trovato che il miglior uso dei diagrammi UML è quello di trasmettere in modo succinto il progetto di un sistema. È incredibilmente utile poter guardare un diagramma di classe o un diagramma di distribuzione e avere un'idea del software rispetto a navigare attraverso il codice o cercare di succhiare l'informazione da altri sviluppatori distratti.

Penso che l'errore che molte persone fanno - incluso me quando ho iniziato a fare la modella - sia pensare che il modello debba essere completo al 100%. Ad esempio, i diagrammi delle classi possono diventare molto ingombranti se includono ogni singola classe in un grande progetto, ma spesso ci sono molte classi di utilità per la registrazione, caricamento delle impostazioni di configurazione ecc. Che non aggiungono molto all'immagine e possono essere omesso.

Tuttavia ci sono anche casi in cui possono essere utili diagrammi UML più dettagliati. In particolare i diagrammi di attività o di stato possono aiutare a chiarire come funziona una parte particolarmente delicata della logica aziendale. In questi casi è una buona idea cambiare il diagramma per ogni piccola modifica come un modo per tenere traccia del processo aziendale.

UML e modellazione sono un atto di bilanciamento. Se incorporare i cambiamenti che il tuo manager sta facendo nei diagrammi li rende più utili, allora aggiungili. Se d'altro canto ci vuole più tempo per apportare le modifiche ai modelli di quanto non faccia per scrivere il codice, allora forse il tuo UML è troppo basso.

Penso che l'OP stia confondendo UML (un linguaggio per la modellazione) con la gestione dei requisiti (un processo). La modellazione del proprio sistema in UML non impedirà agli utenti di richiedere i requisiti. Usi UML per acquisire la tua architettura e mappare i requisiti alle risorse. Una modifica del requisito rappresenterebbe invariabilmente un cambiamento nel tuo modello.

Questi sono problemi sistemici che non si "UML fuori" . Ci sono cose da considerare qui:

Cambia ambito: Troppo grande di una modifica, quindi la richiesta è di disturbo, o il tuo UML non si riferisce al sistema attuale, o il tuo sistema ha un'architettura inflessibile.

Modifica del tasso di variazione Le modifiche troppo frequenti causano tu a 1) l'aggiornamento del modello e 2) l'invio. Quindi, senza un processo di gestione dei requisiti, andrai a far morire te stesso UML, riducendo così il tasso di produzione dei risultati.

Potresti dire che la tua produttività è inversamente proporzionale al tasso di variazione del requisito moltiplicato per un fattore che rappresenta la "crosta" UML aggiunta artificialmente a un processo.

Suggerirei di ottenere un libro sulla gestione dei requisiti e di imparare un po 'come Scrum gestisce i requisiti. Diciamo che in precedenza avevi un requisito R, e ora l'utente vuole una modifica su R, diciamo R '. Quindi tratti R 'come nuovo requisito con la sua nuova timeline. Devi comunicare agli utenti che le modifiche ai requisiti hanno costi associati.

Inoltre, ti piacerebbe studiare un po 'di ingegneria dei sistemi e il concetto di requisiti come:

1. atomica.
2. preciso.
3. non ambiguo.
4. testabile / verificabile.
5. fattibile.
6. È una richiesta di modifica su un requisito un difetto sul requisito. Così, crea un nuovo requisito, e mette l'onere sull'originatore (in genere il cliente.)

Esiste un requisito non valido. Una richiesta di requisito che non soddisfa nessuno di questi requisiti è un requisito non valido. E in un buon processo, il team di sviluppo ha il diritto di rifiutare un requisito.

Voglio dire, chiedi a un architetto di progettare una casa senza finestre, lui se ne andrà. Oppure chiedi al riparatore di riparare il tuo tetto con del nastro adesivo, ti darà il dito e andrà via. Chiedi a un dentista di rimuovere un dente da te usando un paio di tronchesi per bulloni, ti colpirà e ti butterà fuori.

Solo nel software vedi questa nozione che tutti i requisiti sono validi e che devono essere implementati a qualsiasi costo.

Recentemente ho dato una risposta a una domanda correlata, sulla gestione dei requisiti e sull'ingegneria. Forse potresti voler dare un'occhiata a questo. Spero che lo trovi utile

Come gestisci i requisiti in evoluzione?

I motivi per cui gli utenti accetteranno di negare una richiesta di modifica:

1. Costerà più soldi, ma devono sentire l'impatto (in realtà sono i loro soldi o provengono dal loro budget o devono essere approvati).
2. Ritarderà il progetto.
3. Dovranno rinunciare ad un'altra funzionalità.
4. Devono essere coinvolti di più / spendere più del loro tempo con l'approvazione, il test, la richiesta di scrittura ecc.
5. Qualcuno li ha convinti che farà del male o peggiorerà l'applicazione.

Se sono coinvolti nella creazione, modifica, revisione / approvazione di UML, possono pensare due volte a una richiesta poiché dovranno "ripetere tutto ciò". Questo non è diverso dal fatto che devono scrivere una richiesta formale, aggiornare la documentazione / i materiali di formazione, impegnarsi a testare / rivedere / approvare, ecc. Questi tipi di cose sono più tangibili rispetto al codice.

Penso che lo sviluppo guidato dal modello sia il vero problema e certamente non la notazione grafica UML che è conosciuta e accettata da milioni di utenti. UML non è un requisito ma potrebbe essere esteso usando i profili e quindi se modellerai e avresti un tipo di unione dei modelli per ogni iterazione tra codice e modello, sarebbe possibile modellare se i requisiti si evolvono !!

Uso Omondo perché il mio progetto è sviluppato in Java e devo ammettere che questo strumento è l'unico che ho trovato in grado di unire codice e modello in qualsiasi momento. I miei requisiti cambiano a volte ogni settimana, la documentazione del mio progetto è sempre aggiornata e il mio modello UML è accurato :-) Posso anche tracciare i requisiti all'interno del metamodel UML e interrogare xmi che è anche il mio modello. Tecnologia semplicemente incredibile !!

Cambiare i requisiti è qualcosa che devi affrontare nel processo, e le tecniche dai metodi agili aiutano in questo. Per quanto riguarda UML, o qualsiasi altro diagramma o documento prodotto, lo scopo è quello di documentare il sistema. C'è pochissima relazione tra la gestione del cambiamento e la documentazione del sistema, a parte il fatto che avere una documentazione accurata e utile facilita la comprensione del sistema, analizza la richiesta di modifica e fornisce stime sul lavoro da svolgere.

A seconda della struttura organizzativa, i manager aziendali probabilmente non si preoccupano dei dettagli di progettazione o implementazione del sistema (e quindi non si preoccupano di avere UML o qualsiasi tipo di documentazione di progettazione). Vedono richieste di funzionalità e rapporti sui difetti e valutano il valore aggiunto al sistema risolvendo questi difetti o aggiungendo tali caratteristiche e dando la priorità in base agli obiettivi aziendali. I responsabili tecnici potrebbero essere più interessati all'architettura del sistema, alla progettazione e ad alcuni dettagli di implementazione in quanto influiscono sull'utilizzo e sull'assegnazione degli ingegneri.

In genere, dovrebbe esserci una sorta di processo di controllo delle modifiche che coinvolge i membri del team responsabili della gestione aziendale / di progetto, della gestione tecnica e della garanzia della qualità. Non importa ciò che usano per prendere decisioni, ma il business manager / project manager dovrebbe dare la priorità alle richieste basate sul valore aggiunto / esigenze di marketing, il responsabile tecnico dovrebbe essere spingendo indietro sulle richieste che non sono fattibili a causa di vincoli di ingegneria (design attuale , implementazione, le persone sono già assegnate a compiti con priorità più alta, mancanza di risorse).

In tale scenario, avere una notazione formale e coerente del design (come UML) aiuterebbe il responsabile tecnico (e forse gli ingegneri della qualità del software) a capire il sistema ed essere in grado di presentare le loro argomentazioni e le motivazioni per respingere le modifiche , ma non mostrerebbero i modelli UML alle parti interessate non tecniche. Consiglierei l'uso di UML e altre tecniche di modellazione standardizzate per semplificare e semplificare la comunicazione tra gli stakeholder tecnici e all'interno del team, ma mostrare UML a stakeholder aziendali e non tecnici è molto probabilmente futile.

Uso Topcased . È in grado di generare codice dai diagrammi UML e conserva le modifiche apportate al codice generato quando si genera una seconda volta.