Modellazione della struttura del progetto per la gestione

4

Il progetto in cui sono stato inserito è terribile. :-) Main Problem è un'architettura mancante e una linea guida mancante su come organizzare i progetti. In questo caso ho realizzato un'architettura di progetto di esempio con diagrammi di classi e componenti UML e diagrammi di livello. Il problema principale è che devo presentare questa architettura alla gestione. Ma la gestione non ha familiarità con UML o Layer Diagrams e per la maggior parte di essi non è possibile capire la logica dietro di esso.

In questo caso voglio presentare al management una struttura di progetto visualizzata con una facile comprensione. Ho cercato alcune risorse ed esempi con visualizzazioni di facile comprensione, ma non sono riuscito a trovarne uno.

Quindi la mia domanda è come visualizzeresti la tua architettura software per la gestione, quali tecniche utilizzi?

Piccola nota: è un progetto di sharepoint molto grande con oltre 50 sottoprogetti.

    
posta Smokefoot 13.03.2012 - 12:46
fonte

2 risposte

3

UML è un ottimo modo per comunicare il design alle risorse tecniche di un progetto, sebbene nella mia esperienza, la maggior parte delle risorse di progetto non tecnico si perda con esso. UML richiede infatti un livello minimo di allenamento per comprenderlo pienamente o formularlo. Alcuni peer non tecnici possono essere esperti nei diagrammi di Use Case, ma quando vedono un diagramma di componenti potrebbe anche essere scritto in kanji.

Trovo che conoscere il pubblico per il diagramma sia importante prima di iniziare a disegnare. I peer non tecnici in genere hanno una comprensione del tempo più semplice e seguono i diagrammi del diagramma di flusso piuttosto che i diagrammi di attività o sequenza. Potrebbero anche voler solo caselle e frecce etichettate invece di un diagramma componente o diagramma di implementazione UML completo. A volte eseguirò due serie di documenti, uno semplificato per i peer non tecnici e uno in UML per i peer tecnici. Altre volte, se sono in ritardo sul tempo, non mi preoccupo nemmeno dei diagrammi UML perché la maggior parte delle volte la persona tecnica può in generale capire le complessità del diagramma semplificato.

Un'altra importante domanda che devi porci è perché il tuo manager non tecnico trova importanti questi documenti? È perché il progetto sta incontrando dei problemi e la voglia di micro-gestione sta iniziando? Serve ad assistere un addetto alle vendite quasi tecnico per spiegare meglio i vantaggi del software e dell'architettura ai potenziali clienti? Potrebbe essere così superficiale come un manager che vuole appuntare diagrammi dall'aspetto complicato nel suo ufficio o nell'area tecnica per cercare di impressionare i visitatori che porta in ufficio (storia vera). La linea di fondo è conoscere il tuo pubblico e conoscerlo bene.

    
risposta data 13.03.2012 - 13:53
fonte
1

Main Problem is a missing architecture

Quale problema risolve la tua architettura? Anche l'applicazione più mal progettata ha un'architettura, quindi, a meno che non si stia iniziando da zero, ne esiste una. Nel tuo caso, forse nessuno si è preso la briga di documentarlo. Il management vuole sapere che ne hai uno che offre al progetto una sorta di vantaggio (ad esempio prestazioni, facilità di manutenzione, riutilizzo del codice, standard accettati, ecc.).

missing guidline how to organize projects.

Si sentiranno più a loro agio se non sembra che tu stia lavorando nel caos. Dare priorità ai 50 sottoprogetti. Designare qualcuno che sta monitorando i progressi. Mostra loro di avere un sistema, quindi sai che gli sviluppatori stanno facendo le cose. Puoi mostrare che l'architettura è favorevole a questo tipo di progetto?

Sfortunatamente, vogliono davvero sapere: quanto tempo? e quanto costa? Dovresti essere in grado di rispondere a queste domande, ma potrebbe non essere accurato come vogliono.

    
risposta data 13.03.2012 - 14:12
fonte

Leggi altre domande sui tag