Me gusta mucho la respuesta de William Pietri (+1), pero creo que es necesario agregarla. Incluso suponiendo que lo que quiere decir con sistemas comprende únicamente software.
Pero antes de entrar en detalles, no conozco un libro para ayudar. Todo lo que sigue, lo aprendí por experiencia (es decir, los tres puntos que William hizo).
De lo que está hablando abarca un mínimo de cuatro roles generales. A veces, una persona puede llenar todos esos roles, para proyectos pequeños a medianos, pero cuando comienza en proyectos grandes, necesita al menos separar esos roles. Es difícil para alguien ser experto en todos ellos de manera significativa.
Analista de negocios
Esa es la persona que habla con el cliente y traduce sus requisitos en algo que un arquitecto puede tener sentido. Básicamente una lista de requisitos formulados adecuadamente. Esto incluye los requisitos funcionales obvios (¿qué debe ofrecer este sistema?), Pero también los requisitos no funcionales (¿cuáles son las características generales que debe cumplir el sistema? Esto puede incluir seguridad, confiabilidad, disponibilidad, resistencia, capacidad, rendimiento, solidez y otros requisitos similares desde el punto de vista del usuario).
Este es el primer paso de lo que debe hacer el sistema, el comienzo de un pensamiento serio.
Sistema arquitecto
Esta persona produce el marco técnico de alto nivel dentro del cual trabajar. Dan el esquema del plan de coincidencia. Las herramientas generales, técnicas, construcciones. Desglosan todo el sistema en componentes más pequeños, cómo encajan entre sí, cómo encajan con el mundo exterior ...
Esto ayuda de muchas maneras a refinar lo que se debe pensar. Muy a menudo se descubrirán problemas en esa etapa sobre los requisitos tal como los escribió el analista de negocios. Vuelva a ellos para algunas iteraciones para mejorar su comprensión de lo que quieren y su expresión de ello.
Diseñador de sistemas
Este rol trata sobre cómo hacer que todo funcione. Esto podría ser más trabajo en equipo que un espectáculo individual. Pero es probable que haya un diseñador líder para supervisar todo el diseño del sistema. Esta persona debe profundizar en los detalles y asegurarse de que la vista del arquitecto sea algo que realmente se pueda construir.
Espere un mayor refinamiento de la arquitectura del sistema y, por lo tanto, potencialmente del análisis comercial.
Gerente de pruebas
Este papel a menudo se olvida. Pero al final del día, si no puede probarlo, ¿cómo puede probar que puede construirlo? Debe haber una revisión de los resultados de todas las etapas: análisis comercial, arquitectura y diseño por parte de alguien competente en pruebas que pueda resaltar deficiencias y, por lo tanto, permitir correcciones tempranas, mucho antes de que se escriba cualquier código.
Ese es un breve resumen.
Esos muchachos / chicas son solo la corrida general de la gente del molino en la cadena para pensar en lo que se debe pensar.
Para proyectos complejos, como grandes aplicaciones bancarias o espaciales, solo para tomar dos ejemplos (piense entre cientos y miles de días-hombre), hay muchos expertos en la materia que los llamamos para revisar y apoyar proyectos en cada etapa. Estas funciones incluyen análisis de seguridad, dimensionamiento del sistema, capacidad, rendimiento, bases de datos, agrupación en clúster y muchas otras áreas de especialización tan estrechas, incluidas áreas comerciales precisas. La variedad de roles depende del tamaño y la complejidad de los sistemas.
Todo eso para decir que no debes intentar y saberlo todo, no lo harás. Sin embargo, puede obtener una idea general de la imagen y en proyectos pequeños puede profundizar mucho más que en proyectos grandes, simplemente porque el nivel de complejidad le permite ser más completo.
Si desea saber cómo diseñar sistemas, debe comenzar a hacer preguntas pensando de manera innovadora. Póngase lo suficiente en el lugar del cliente e intente pensar qué podría salir mal, qué debe probarse. Luego, reúnanse con un cliente real y pídales que expliquen las extensiones y los límites del sistema que imaginan que necesitan. Además, cada vez que digo "cliente", debe comprender que esto abarca a varias personas muy diferentes. Está la persona que usa el sistema día a día para lo que fue diseñado para hacer. Están el operador, el soporte técnico, el gerente que necesita algún informe u otro, el auditor, el equipo de infraestructura, la parte interesada que lo pagó, el gerente de calidad que necesita medios para probar su sistema ... Pregúnteles a todos (y si son una persona pídales que se pongan todos estos sombreros uno a la vez), así que pregúnteles a todos lo que necesitan y tendrá un buen comienzo para saber cuáles son los requisitos de su sistema. A partir de ahí puede derivar la arquitectura, y desde allí el diseño.
Para sistemas complejos (ya sea solo software o para integrarse con hardware en el sentido más genérico), no solo una persona no es suficiente para cada uno de los cuatro roles que enumeré anteriormente, sino que debe gestionar el proyecto incluso la definición de lo que el sistema debe hacer, y mucho menos las otras fases.
HPH, asm.