¿Por qué molestarse con especificaciones detalladas?

Al escribir software, ¿cuál es el punto de escribir una especificación formal y detallada de árbol muerto? Para aclarar, una especificación de alto nivel algo informal para personas que no quieren leer el código tiene sentido para mí. Sin embargo, una implementación de referencia en un código fuente legible y bien comentado trata sobre la especificación más inequívoca de todo lo que va a obtener, ya que una computadora tiene que poder ejecutarlo. Las especificaciones formales son a menudo tan difíciles de leer y casi tan difíciles de escribir como el código.

Qué beneficios ofrece una especificación formal sobre una implementación de referencia más una pequeña documentación sobre qué comportamiento está indefinido / definido por la implementación, independientemente de cómo funcione en la implementación de referencia.

Editar: Alternativamente, ¿qué tiene de malo que las pruebas sean la especificación formal?

¿Cómo puedes saber que has terminado, si no sabes cómo se supone que se verá cuando esté hecho?

El arrastre de características te atrapará. Intentará entregar para un cliente y, a medida que se acerca el tiempo de finalización, descubrirán 10,000 pequeñas cosas que absolutamente deben tener .

Para que te paguen, para que tu jefe se salga de tu espalda cuando se venza el plazo, debes poder extraer la especificación y decir: "Todo mi tiempo y costos estimados fueron para esta cosa, no para esta nueva cosa que todos han decidido que quieren ".

Las especificaciones le permiten reflexionar sobre las cosas sin haber escrito mucho código por adelantado que tendría que cambiar, si la especificación cambia. Considere que está entre la pizarra y la codificación real

También es una muy buena idea hacerlo cuando varias partes independientes escriben componentes que necesitan ir juntos.

Además de algunas de las otras muy buenas razones ya mencionadas, tener una especificación formal te permite CYA - Cover Your Ass! Si los gerentes / analistas / evaluadores dicen que no construiste algo correctamente, puedes señalar la especificación y decir "¡Lo construí tal como lo querías!". Esto incluye cosas de bajo nivel como "Todos los datos persistentes en la tabla AXX_RGV deben estar en MAYÚSCULAS", "Los formularios web con menos de 3 campos de entrada deben tener el botón Enviar en la esquina inferior izquierda", etc.

También para cuando las personas se olvidan de cosas en un proyecto muy largo y grande, tener una especificación detallada para hacer referencia puede ser muy útil. Solo recuerde que la especificación debe ser un documento vivo, y si los requisitos cambian (a través de lo que es de esperar un proceso documentado y formal), también debe hacerlo la especificación. Sí, esto puede llevar más tiempo. En mi experiencia, vale la pena (si se hace bien).

Se necesita una especificación formal de los requisitos de un programa porque el ingeniero de software necesita saber qué implementar; El ingeniero de control de calidad necesita saber qué probar y el cliente debe saber qué esperar.

Tener una especificación le permite saber cuándo ha terminado la programación.

Uno de los principales beneficios puede ser la seguridad. No me gustaría volar en un avión donde la especificación de los sistemas de control era una implementación de referencia. Realmente quiero que alguien especifique lo que los sistemas deben hacer de una manera que alguien que no esté familiarizado con el software pueda entender. Esperaría que cada requisito se haya verificado completamente mediante pruebas.

Para sistemas menos críticos de seguridad, las especificaciones son herramientas de comunicación. Deben detallar lo que el sistema necesita hacer con suficiente detalle para construir y probar el sistema. La forma en que el sistema hace esto es responsabilidad del código. Los detalles requeridos variarán según la experiencia en el dominio del equipo de desarrollo y el acceso a expertos en el dominio.

Las especificaciones siempre deben coincidir con los sistemas implementados. Si se encuentran errores en la especificación, la especificación debe actualizarse.

El error causa que las estimaciones que he visto indican que las fallas en las pruebas se dividen de manera relativamente equitativa entre los errores en las especificaciones, el código y las pruebas.

Creo que esta pregunta es el quid de la pregunta del ciclo de vida ágil frente a la cascada.

Si lo está haciendo ágilmente, una premisa básica es que el código junto con la estrecha interacción del desarrollador es mejor y más rápido que la especificación detallada. El equipo prioriza el lanzamiento de nuevas funciones y alta calidad sobre otras cosas, como los mecanismos formales de comunicación, como las especificaciones detalladas de diseño. Pero hay un intercambio aquí: debe tener canales de comunicación entre los miembros del equipo que les permitan preguntar sobre los matices y la intención detallada del diseño cuando lo necesiten.

Si está haciendo una cascada, está asumiendo que el trabajo de completar el código bajo el diseño detallado y luego probarlo es significativo. Y desea brindar a los interesados ​​una visión temprana de cómo procederá este trabajo y cómo será cuando esté terminado. Eso puede estar examinando el diseño con el cliente para asegurarse de que haya explorado las características que tienen sentido. También puede ser examinarlo con expertos en otros ámbitos, como revisiones de seguridad, revisiones de seguridad y revisiones de miembros del equipo que deben integrarse con su código. La suposición es que estas revisiones ahorrarán tiempo a largo plazo porque le evitarán investigar una gran cantidad de tiempo en el desarrollo de algo incorrecto.

Últimamente, he visto una gran fusión entre diseños detallados y herramientas de comentarios de código, por ejemplo, JavaDoc. Como los diseños más detallados son huellas del código y explicaciones breves de lo que hará, esto es más o menos lo mismo que esperarías de los comentarios del código. Por lo tanto, tener una herramienta que transformará los comentarios de código en una especificación de diseño detallada es excelente, una forma mucho mejor de mantenerlo actualizado que hacerlo a mano.

Creo que la evaluación inexacta de cuán detallado debe ser el diseño para el proyecto es un factor importante en el crecimiento de los costos. La peor parte es que estás condenado si lo haces y maldito si no lo haces:

• Si su diseño es demasiado detallado para el tamaño del equipo, la complejidad del trabajo y los requisitos de las puertas que debe atravesar (revisiones de seguridad, revisiones de seguridad, etc.), entonces ha perdido un tiempo y dinero valioso en un artefacto que nunca usarás.
• Si su diseño no es lo suficientemente detallado, desperdiciará dinero ya que los miembros del equipo hacen suposiciones incorrectas que conducen a problemas de integración, y corre el riesgo de volver a trabajar cuando una auditoría final de seguridad o seguridad descubre problemas que podrían haberse solucionado de manera temprana y económica si hubieran sido aspectos claros del diseño antes de la implementación.

No creo que sea una carcasa en blanco y negro: puede haber muchas veces en que algunos componentes son "lo suficientemente buenos" si están diseñados a un alto nivel, mientras que otros necesitan un trabajo riguroso y detallado. Y los entornos cambiantes de equipo o proyecto pueden dictar nuevas necesidades de diseño a medida que el proyecto evoluciona.

Trabajando en un gran proyecto en este momento. Hasta ahora, la especificación ha ayudado al control de calidad a identificar qué probar, nos ha permitido cobrar más al cliente (significativamente como en millones) cuando en las pruebas de usuario, decidieron que lo que habían acordado no era lo que realmente querían, permitieron a las personas hacer una revisión del código para ver si el código cumplía con el requisito, permitía a los desarrolladores tener una base para verificar si estaban terminados y señalar la especificación para resolver disputas sobre lo que debería contener el módulo. También nos permitió identificar a los desarrolladores que no estaban produciendo lo que el cliente requería antes de que el cliente viera el producto y eso terminó como una base para deshacerse de algunas personas que no podían seguir las especificaciones de manera constante. La complejidad de nuestra especificación ayudó al cliente a darse cuenta de que no estábamos siendo escandalosos en nuestras estimaciones de costo y tiempo.

Quería agregar, he trabajado en proyectos con buenas especificaciones, con malas especificaciones y sin especificaciones. Los que terminaron siendo los peores fueron los que no tenían especificaciones porque el equipo de desarrollo y el cliente siempre tuvieron una visión interna diferente del resultado final. Estos son los proyectos en los que andas murmurando, "¿dónde puedo obtener un módulo de lectura de la mente?" Adivinar lo que el cliente podría desear es una experiencia horrible. Las malas especificaciones no son mucho mejores, pero al menos puede refinar a medida que avanza y decir: "No estoy seguro de lo que quiso decir aquí". para obtener más información antes de perder el tiempo construyendo algo incorrecto. El gran proyecto en el que estoy ahora tiene especificaciones sorprendentemente buenas, ha hecho la vida más fácil y mucho menos estresante.

Personalmente, creo que las especificaciones detalladas están sobrevaloradas.

En mi experiencia, lo que los clientes necesitan y lo que los clientes piensan que necesitan a menudo son dos cosas diferentes. Si congelas los requisitos desde el principio, estás construyendo lo que creen que necesitan, no lo que realmente necesitan. Legalmente, está en el lado seguro y le pagarán, pero no tendrá un cliente satisfecho.

Por otro lado, si acepta que el desarrollo de software es hasta cierto punto una actividad exploratoria, intentará mantener los requisitos abiertos durante el mayor tiempo posible. Discuta con los usuarios lo que necesita saber para la iteración actual , ni más ni menos. Y sepa que a veces, tendrá que revisar estas decisiones en una iteración posterior. Lo más importante: tenga en cuenta que si eso sucede, no es culpa del cliente. A menos que sus usuarios también sean desarrolladores de software, la recopilación de requisitos no es parte de la descripción de su trabajo. Es parte de la descripción de tu trabajo.

Entonces, ¿cómo se previene el arrastre de características? Idealmente, tener un gerente de producto sensato que esté a cargo de aceptar o rechazar solicitudes de funciones y que nadie más pueda anular.

Agile tiene más de 10 años, por lo que este no es un fenómeno nuevo.

Espero que las especificaciones sean mucho más cortas que el código, por lo que no sé cuántos detalles necesita. Debería haber suficiente para mantener a los miembros del equipo informados. ¿Es práctico / necesario leer todos los códigos del otro?

De acuerdo, no hay necesidad de documentos muertos. Prefiero acercarme a una base de código desconocida sin documentación que documentación incorrecta.

Y si la computadora es tan buena ejecutando su código, ¿por qué no deja que haga sus propios cambios? Seguir la receta en el reverso de la caja no te convierte en un chef.