Perché fare tutto con un progetto software è sbagliato? [chiuso]

Question

Perché fare tutto con un progetto software è sbagliato? [chiuso]

#1 da (9 voti)
#2 da (3 voti)

2

Sono appena assunto da un'azienda. Dopo un paio di settimane, ho sentito molto tempo che c'è un grande progetto che la maggior parte dei programmatori sta lavorando su di esso. Lo chiamano qualcosa come Managing Everything Software. Poi, in qualche modo ho ottenuto il documento che definiscono ciò che farà il MES. Il documento stesso era di 60 pagine ma contiene solo su ciò che fa, non come fa .

Il documento descrive semplicemente le proprietà di questi software:

Enterprise Resource Planning (ERP),
Sistema di gestione delle risorse umane (HRMS),
Content Management System (CMS),
Learning Content Management System (LCMS),
Piattaforma social aziendale,
Sistema di gestione del flusso di lavoro e dei documenti,
Sistema di gestione file che può cercare su qualsiasi tipo di file come PDF, Word, ecc. (come la ricerca elastica)
Autenticazione e autorizzazione basate su LDAP

Non solo, tutti questi saranno collegati tra loro.

Potrebbe sembrare che si tratti di progetti software diversi, ma non lo sono. Il progetto è, per fare tutto questo con un unico grande software:

Molti di voi già conoscono il metodo divide and conquer da applicare allo sviluppo del software. Se fosse io, dividerei questi compiti in piccoli pezzi. Quindi definire le tabelle del database per ogni pezzo. Ogni pezzo sarebbe responsabile per i propri dati. Nessun'altra parte avrebbe accesso diretto a quei tavoli che appartengono a un altro pezzo di programma. Se hanno bisogno di accedervi, chiedono al programma responsabile di farlo. Questa è praticamente un'architettura della SOA. Ma il modo in cui questo grande progetto è scritto, non menziona mai quei pezzi né come saranno i collegamenti tra loro. Secondo la documentazione, ogni parte può vedere o modificare qualsiasi tabella (se autorizzata).

Dato che le persone sono così coinvolte in ciò che il software raggiungerà, sembrano praticamente in una posizione che hanno ridotto la visione. Il progetto si riflette come una pallottola d'argento per tutti i problemi. Devo dire loro che dovremmo suddividere il progetto in piccoli e collegarli come in SOA e questo renderà tutto molto più facile. Ma il problema è che non so come convincerli che il loro approccio non è il modo migliore per farlo. Devo fornire prove solide, fonti, libri, link e forse video per convincerli che questo non funzionerà.

Non sono riuscito a trovare alcun documento per supportarmi (dal momento che il mio inglese non è così bello per cercare su Internet cose non tecniche). Puoi fornire qualsiasi informazione sul perché fare tutto con un progetto software è sbagliato?

design software soa

posta Ramazan Polat 17.08.2015 - 16:51

fonte

2 risposte

Leggi altre domande sui tag design software soa

Utilizzo di più lingue Le cache a livello di applicazione appartengono ai server Web?

score 9 · Answer 1

Non sono sicuro di cosa intendi con "un solo ed unico software!" ma penso che potresti leggere troppo in questo documento. Poiché parla di cosa non come , suona molto più come un documento dei requisiti di alto livello per un sistema e non una singola applicazione. Questo è in realtà un documento molto importante per qualsiasi grande progetto. Sono sicuro che se dovessi esaminare i documenti equivalenti per SAP o Oracle o MS Windows, sarebbero più grandi e più complessi, ma questi erano progetti di successo, quindi non è sbagliato.

Diamo un'occhiata al problema in un modo diverso. Se tutte queste funzionalità sono necessarie per aiutare l'azienda a funzionare in modo efficiente, non ha senso disporre di un documento che elenchi tutte queste parti, in modo che non siano tutte compilate separatamente e quindi non lavorino insieme?

Spetta al tuo team decomporre cosa in come . Sei sulla strada giusta se ritieni che questi non dovrebbero essere tutti parte di un singolo eseguibile dell'applicazione. Non c'è motivo di credere che questo non possa essere fatto sulla base delle informazioni che abbiamo finora. Finché le persone riconoscono la dimensione dello sforzo e le risorse richieste, sembra che avrai un lavoro (un lavoro) per un po '. Buona fortuna!

score 3 · Answer 2

Sei un po 'confuso da come viene sviluppata la documentazione del software.

Quello che leggi è il documento dei requisiti . Ci sono interi libri scritti a lungo su come progettare e documentare i requisiti, ma tutto ciò che devi sapere è che il documento dei requisiti specifica cosa il software dovrebbe fare. Non fa menzione di come, dal momento che questi documenti sono generalmente condivisi con il management, che hanno poca comprensione (solitamente) del modo in cui il software è costruito. C'è molto poco o nessun gergo tecnico scritto in questo documento.

Come raggiungere i requisiti dipende da te - lo sviluppatore - capire. Di solito prima che il codice venga scritto per un progetto di grandi dimensioni, viene scritto un documento di progettazione che spiega il come al cosa. Questo è scritto per il team di sviluppo in modo che il progetto possa essere costruito e, cosa più importante, mantenuto !. Qui è dove metti i diagrammi fantasiosi, le lingue / tecnologie che userai, i metodi di test, ecc. Se lavori per una buona compagnia, di solito permetteranno agli sviluppatori di scegliere quali tecnologie e lingue sono più adatte per il lavoro. / p>

Essenzialmente, capire come il codice dovrebbe soddisfare i requisiti è l'ingegneria del software!

P.S. Detto questo, se ritieni che i requisiti siano impossibili (i miei professori chiamavano queste "ali su una macchina"), allora è tua responsabilità portarlo al tuo Project Manager. Lavoreranno poi con il cliente per modificare i requisiti per renderlo più ragionevole, o farti fare lo stesso. Sfortunatamente, di solito finisce per essere quest'ultimo.