Construye uno para tirar contra el efecto del segundo sistema

Por un lado, hay un consejo que dice "Construye uno para tirar". Solo después de terminar un sistema de software y ver el producto final nos damos cuenta de lo que salió mal en la fase de diseño y entendemos cómo deberíamos haberlo hecho realmente.

Por otro lado, está el "efecto del segundo sistema" que dice que el segundo sistema del mismo tipo que está diseñado es generalmente peor que el primero; Hay muchas características que no encajaban en el primer proyecto y se introdujeron en la segunda versión, lo que generalmente conduce a un diseño demasiado complejo y excesivo.

¿No hay alguna contradicción entre estos principios? ¿Cuál es la visión correcta sobre los problemas y dónde está la frontera entre estos dos?

Creo que estas "buenas prácticas" fueron promovidas en primer lugar en el libro seminal The Mythical Man-Month de Fred Brooks.

Sé que algunos de estos problemas se resuelven mediante metodologías ágiles, pero en el fondo, el problema sigue siendo los principios; por ejemplo, no haríamos cambios importantes en el diseño 3 sprints antes de lanzarlo.

Construir uno para tirar viene de "no saber lo que no sabes" al principio, por lo que aprendes sobre la marcha lo que deberías haber hecho al principio.

El segundo efecto del sistema proviene de "saber ahora lo que no sabías, pero no saber lo que aún no sabes", es decir, el segundo efecto del sistema proviene de tratar de construir un sistema más grande, brillante y complejo que el primero, sin el conocimiento necesario al inicio: suena muy parecido a lo que sucede con el primer sistema.

Por lo tanto, el segundo efecto del sistema no es contradicción. Construir un segundo sistema con la misma funcionalidad que el primero nunca (que yo sepa) nunca se hace. El segundo sistema siempre tiene que ser "mejor", por lo tanto, más complejo, por lo tanto, se esperan problemas sustancialmente similares al primer sistema, que deben desecharse.

Así que construya uno para tirar, tírelo y vuélvalo a construir sin ampliación de alcance, y no tendrá un segundo problema del sistema. (Esto suele hacerse con mayor frecuencia en planetas con cielos morados, mares rosados ​​y cerdos voladores).

El problema al que se refiere significa que se omitieron varias cosas, por lo tanto, el sistema resultante salió mal. Permítanme describir algunos de los pasos que faltan:

Gestión de calidad: ¡hazlo bien la primera vez! Nunca use hacks temporales o compromisos temporales. No se necesitará retrabajo. Todos los recursos se utilizan de manera eficiente y todo lo que hace es una contribución adecuada al proyecto.

Análisis de viabilidad: descubra las necesidades comerciales. Cree un caso de negocio para el proyecto.

Plan de proyecto: defina claramente su alcance inicial, planifique cómo se entregará la solución, cree una línea de base y cumpla con el plan. No pierdas tiempo en nada que no esté en el camino crítico.

Ingeniería de requisitos: obtenga requisitos comerciales (es decir, capture los procesos comerciales y determine qué operaciones comerciales deben ser compatibles con el sistema computarizado, traduzca las operaciones comerciales 1: 1 a los casos de uso del sistema). Validar y verificar! (¿Estamos construyendo lo correcto? ¿Estamos construyendo lo correcto?) Todos los requisitos deben estar vinculados a la necesidad comercial original.

Diseño de software: traduzca casos de uso y modelo de dominio en diseño de componentes y arquitectura de soluciones. Todos los componentes deben estar vinculados a los requisitos de RE.

Implementación: codifique el software como en el diseño. Todo el código debe estar vinculado a los componentes de SD.

Validación - Pruebas unitarias, pruebas de integración, rendimiento, ... (todos los casos de uso de RE ahora deberán ser probados)

Estos son algunos aspectos clave de un proceso de software. Las actividades mencionadas son parte de la Ingeniería de Software. Así es como se construye la solución de software adecuada para las necesidades comerciales reales, y se construye a tiempo, dentro del presupuesto y según las especificaciones.

Busque estos términos para crear un mejor software y hacerlo bien la primera vez:

• Análisis de viabilidad (especialmente cómo construir un Business Case)
• Gestión de proyectos (especialmente plan de proyectos y registro de riesgos con mitigación de riesgos)
• Ingeniería de requisitos (obtención, análisis, especificación, validación)
• Diseño de software (UML e ingeniería de software basada en componentes)
• Construcción de software (patrones de diseño, marcos, programación defensiva)
• Validación de software (pruebas unitarias, UAT, etc.)