Mi piace molto la risposta di William Pietri (+1), ma credo che debba essere aggiunto. Persino presumendo che ciò che intendi per sistema comprenda esclusivamente software.
Ma prima di andare nella carne, non conosco un libro per aiutare. Tutto ciò che segue, ho imparato dall'esperienza (intendendo i tre punti che William ha fatto).
Di cosa stai parlando si estende in almeno quattro ruoli generali. A volte una persona può ricoprire tutti quei ruoli, per progetti di piccole e medie dimensioni, ma quando inizi su progetti di grandi dimensioni devi almeno separare un po 'quei ruoli. È difficile per chiunque essere esperto in tutti in modo significativo.
Analista di affari
Questa è la persona che parla con il cliente e traduce le sue esigenze in qualcosa che un architetto può dare un senso. Fondamentalmente un elenco di requisiti adeguatamente formulati. Ciò include gli ovvi requisiti funzionali (cosa deve fornire questo sistema?), Ma anche i requisiti non funzionali (quali sono le caratteristiche generali che il sistema deve soddisfare? Ciò può includere sicurezza, affidabilità, disponibilità, resilienza, capacità, prestazioni, robustezza e altri requisiti di questo tipo dal punto di vista dell'utente).
Questo è il primo passo per ciò che il sistema deve fare, l'inizio del pensiero serio.
Architetto di sistema
Questa persona produce il quadro tecnico di alto livello all'interno del quale lavorare. Danno il piano di abbinamento del profilo. Gli strumenti generali, le tecniche, i costrutti. Rompono l'intero sistema in componenti più piccoli, come si adattano l'uno all'altro, come si adattano al mondo esterno ...
Questo aiuta in molti modi a perfezionare ciò a cui bisogna pensare. Molto spesso in quella fase verranno scoperti problemi relativi ai requisiti scritti dall'analista aziendale. Torniamo a loro per alcune iterazioni per migliorare la loro comprensione di ciò che vogliono e la loro espressione.
Progettista di sistema
Questo ruolo riguarda come far funzionare tutto. Questo potrebbe essere più lavoro di gruppo di uno spettacolo individuale. Ma è probabile che un lead designer sovrintenda alla progettazione dell'intero sistema. Questa persona deve scavare nei dettagli e assicurarsi che la vista dell'architetto sia qualcosa che può essere effettivamente costruito.
Aspettati un ulteriore perfezionamento dell'architettura del sistema e quindi potenzialmente dell'analisi aziendale.
Responsabile dei test
Questo ruolo è molto spesso dimenticato. Ma alla fine della giornata, se non puoi provarlo, come puoi provare che puoi costruirlo? Deve esserci una revisione dei risultati di tutte le fasi: analisi di business, architettura e progettazione da parte di qualcuno competente nei test che sarà in grado di evidenziare le carenze e quindi consentire correzioni anticipate, molto prima che venga scritto qualsiasi codice.
Questo è un breve riassunto.
Quei ragazzi / ragazze sono solo la corsa generale dei mulini della catena per pensare a cosa bisogna pensare.
Per progetti complessi come le grandi applicazioni bancarie o spaziali solo per fare due esempi (pensate da molte centinaia a molte migliaia di giorni-uomo), ci sono molti esperti in materia mentre li chiamiamo per rivedere e supportare progetti in ogni fase. Questi ruoli includono analisi della sicurezza, dimensionamento del sistema, capacità, prestazioni, database, clustering e molte altre aree di competenza così ristrette, comprese aree di business precise. La varietà dei ruoli dipende dalle dimensioni e dalla complessità dei sistemi.
Tutto ciò per dire che non dovresti provare a sapere tutto, non lo farai. Puoi comunque avere una visione d'insieme del quadro e su piccoli progetti puoi approfondire molto più che su grandi progetti, semplicemente perché il livello di complessità ti consente di essere più arrotondato.
Se vuoi sapere come progettare i sistemi, allora devi iniziare a fare domande pensando fuori dagli schemi. Mettiti abbastanza nei panni del cliente e prova a pensare a cosa potrebbe andare storto, a cosa bisogna testare. Quindi si incontrano con un cliente reale e li spingono a spiegare le estensioni e i limiti del sistema che immaginano di aver bisogno. Inoltre ogni volta che dico "cliente", devi capire che questo comprende molte persone molto diverse. C'è la persona che usa il sistema giorno dopo giorno per quello per cui è stata progettata. C'è l'operatore, il supporto tecnico, il manager che ha bisogno di un rapporto o altro, il revisore, il team dell'infrastruttura, il portatore di interessi che lo ha pagato, il responsabile della qualità che ha bisogno di mezzi per testare il sistema ... Chiedi a tutti (e se sono una persona, chiedi loro di indossare tutti questi cappelli uno alla volta), quindi chiedi loro tutto ciò di cui hanno bisogno e avrai un buon inizio per sapere quali sono i tuoi requisiti di sistema. Da lì è possibile ricavare l'architettura e da lì il design.
Per i sistemi complessi (sia software che da integrare con l'hardware nel senso più generico) non solo una persona non è sufficiente per ciascuno dei quattro ruoli che ho elencato sopra, ma è necessario gestire il progetto anche la definizione di ciò che il sistema deve fare, figuriamoci le altre fasi.
HPH, asm.