¿Cuáles son los pasos/etapas tradicionales generales para el desarrollo de software, o más específicamente, la escritura de especificaciones?Especificaciones de escritura para un proyecto, ruta tradicional
Conozco conceptos como método de cascada, recopilación de especificaciones, casos de uso, etc. Pero quiero una explicación más formal para todo.
He encontrado empresas en general, ya sea:
No hacer especificaciones.
Tiene una plantilla de especificaciones. Cada especificación se parece a todas las demás (es decir, "estándar"); todas tienen las mismas secciones.
No me gusta ninguno. Cada especificación es diferente. Intentar que se adapte a una plantilla rígida es como escribir un libro en una plantilla: un libro para niños es diferente de un libro para adultos diferente a un libro de cocina. Es diferente a un ...
Algunas especificaciones deben ser incorporadas detalles técnicos (como formatos de archivo), pero otros están bien cuando se presentan desde el punto de vista de los usuarios (un botón que al hacer clic hace x).
Las mejores especificaciones que he visto son las que puedo tomar y hacer lo que es sin tener que hacerle ninguna pregunta al experto en especificaciones. Si tengo que hacer preguntas, considero que la especificación ha fallado. La especificación debe responder todas mis preguntas.
Cuando estoy escribiendo una especificación, siempre la imprimo y la leo (encuentro más errores cuando se imprime). Luego lo dejo por un día y lo leo de nuevo. Si encuentro algún error o pienso en algo que haya pasado por alto, actualizo la especificación, la imprimo y la leo, y la dejo por un día. Sigo haciendo eso hasta que no encuentro nada de malo en ello.
Una especificación debe ser fácil de leer. Una vez me dieron una especificación de 120 páginas sin tabla de contenidos y sin números de página. Le pedí al escritor de especificaciones que incluyera una tabla de contenidos y su respuesta fue "no, quiero que la gente lea las especificaciones para encontrar lo que buscan, ya que luego leerán más". Perdí mucho tiempo buscando en esa especificación buscando cosas. Esa fue una mala especificación.
Sea cual sea el método que utilice para escribir la especificación, no importa; el resultado es lo importante. La especificación debe ser fácil de leer y responder todas las preguntas.
Utilizamos una plantilla básica para nuestras especificaciones, pero tenemos cierta flexibilidad en cuanto a si todas las piezas deben ser incluidas. Normalmente incluyo una tabla de contenidos y, si es necesario, una tabla de figuras (para capturas de pantalla, mensajes de error, etc.).
A veces comenzamos con una característica o mejora, escribimos una especificación completa, luego hacemos la codificación. Otras veces comenzaremos a codificarlo, luego volveremos y desarrollaremos una especificación después del hecho. Ambos enfoques funcionan para nosotros. A menudo, nuestras especificaciones describen cómo funcionará la característica desde la perspectiva del usuario, aunque a veces incluimos detalles técnicos como nuevas definiciones de tabla o cambios a las clases/módulos/formularios existentes.
Estoy de acuerdo con Dan, si el resultado final es útil para quienes lo leen, entonces es una buena especificación. Creo que es bueno tener algún tipo de formato acordado, por lo que puedes encontrar rápidamente ciertos tipos de información cuando miras múltiples especificaciones.
Joel tiene una serie de artículos sobre este topic, su consejo, que estoy de acuerdo, es escribir especificaciones breves y claras para las características importantes y pasarlas a los desarrolladores para trabajar desde.
Lo que no querrás hacer es intentar especificar todo a lo largo de todo el proyecto cuando comiences. Siga las especificaciones de nivel más alto y avance hasta obtener más detalles cuando esté listo para implementar una función. De esta forma, no debería tener la sobrecarga de documentos, y no hay tantas posibilidades de que su especificación se vuelva obsoleta antes del desarrollo (si lo hizo semanas o meses antes).
¿Qué tipo de especificaciones quiere decir? La especificación correcta para su uso dependerá de su equipo, que utilizará la especificación y los requisitos de documentación del proyecto.
Las especificaciones deben adaptarse al público objetivo y deben tener en cuenta la duración esperada del documento. He usado especificaciones funcionales y especificaciones técnicas. Para una especificación funcional, la audiencia principal era el cliente y para la especificación técnica, la audiencia objetivo eran los desarrolladores y el equipo de TI (para la implementación).
La especificación funcional no se mantuvo normalmente después de que comenzó el desarrollo. En general, la especificación funcional se creó antes de que comenzara el proyecto y se usó para evaluar el tamaño del proyecto. Un arquitecto con el que trabajé escribió un tipo de especificación funcional en Power Point. Lo llevó a todas sus reuniones, técnicas y no técnicas. Estaba lleno de diagramas fáciles de leer y páginas con puntos que usamos como una declaración de misión para el proyecto.
La especificación técnica a veces se mantuvo durante todo el proyecto. Si se mantiene actualizado, podría utilizarse como referencia para el mantenimiento.
Estoy de acuerdo con @Dan en que cada especificación es diferente y puede parecer muy diferente. Para mí, lo importante es tener un proceso coherente con el que todos los interesados estén satisfechos, y cualquier herramienta (como plantillas de BRS) que les haga la vida más fácil.
lo siguiente es un truco de un truco de similar question.
Los pasos como lo veo son;
El BRS cubre lo que los problemas de negocio son, y cuáles son los requisitos en torno a las soluciones, las pruebas, la seguridad, la fiabilidad y entrega. Esto define lo que haría una solución exitosa.
Los detalles de especificaciones funcionales lo que se necesita, cómo debe mirar, cómo los campos deben ser largas, etc.
Los detalles de especificaciones técnicas en las que los datos proceden de, cualquier código complicado que puede ser necesario considerar.
El cliente es el propietario de los requisitos. Los desarrolladores poseen las especificaciones técnicas ... y la especificación funcional es un término medio. Las pruebas se realizan contra las especificaciones tecnológicas (por lo general, pruebas unitarias) y luego contra las especificaciones funcionales (generalmente pruebas del sistema) y luego contra los requisitos (UAT).
La parte importante de esto es que los desarrolladores aún deben entregar las especificaciones funcionales, y lo más importante, los requisitos comerciales originales. En realidad, el BRS es dios en todo esto y las especificaciones funcionales y tecnológicas están ahí para mayor claridad.
El artículo de Joel fue muy útil en este sentido, aunque como siempre, a veces me resulta difícil seguir todos sus pasos, pero definitivamente es mi falla. :) – kaybenleroll
Creo que Joel bueno podría beneficiarse de una buena reescritura de URLs también: p – melaos
Sí, no es un enlace bonito. –