specifications - sistema - requerimientos de un proyecto de software
¿Cómo escribir una especificación funcional? (4)
Creo que el mayor desafío con las especificaciones funcionales no es el formato directamente, sino mantenerlas sincronizadas con las cosas que las impulsan (requisitos) y las cosas que se basan en ellas (casos de prueba, documentación).
Por esa razón, prefiero manejar este problema con un enfoque basado en modelos en lugar de uno basado en papel.
Utilizo una herramienta de modelado UML (Enterprise Architect de Sparx Systems, pero muchas herramientas también funcionan) para capturar todos los artefactos del proyecto en un solo lugar y crear trazabilidad entre ellos. En Enterprise Architect, puedo crear trazabilidad desde un artefacto de requisito a un artefacto de diseño (por ejemplo) simplemente colocándolos en el mismo diagrama y creando un conector de uno a otro con solo arrastrar el mouse.
Mi "especificación funcional" es en realidad una colección de diagramas de actividad, uno por caso de uso en el sistema. Cada caso de uso se relaciona con uno o más requisitos que requieren ese caso de uso. Incluso a los usuarios finales les resulta fácil seguir los diagramas de actividad y validarlos (¿qué tan fácil es hacer que los usuarios finales lean, y mucho menos comprendan y validen, una especificación funcional tradicional basada en papel?)
De manera similar, puedo crear trazabilidad desde mis diagramas de actividad (casos de uso) hasta artefactos de diseño específicos como diagramas de clase.
El control de calidad puede modelar casos de prueba y crear trazabilidad desde sus casos de prueba hasta los casos de uso. De esa manera, vemos si hay casos de uso que no tienen casos de prueba (o no tienen suficientes casos de prueba).
Lo bueno de Enterprise Architect como herramienta es que todos estos artefactos se almacenan en una base de datos SQL, por lo que solo puedo ejecutar algunas consultas que he desarrollado a lo largo del tiempo para encontrar artefactos sin rastrear nada de ellos.
Siempre escribimos funciones o clases y su lógica es muy complicada. Si no hay una especificación para estas estructuras, más tarde será difícil incluso para nosotros comprender las ideas.
¿Cómo escribes especificaciones para funciones y clases complicadas?
Por favor, dime algo sobre tu propia experiencia, pero no solo un enlace, gracias.
Debe realizar una investigación sobre los siguientes temas (no necesariamente en orden):
Estos son los enfoques más comunes para la especificación de proyectos de software.
Echa un vistazo a Joel en Software . Y here Y here Incluso hay un example mundo real.
Veo algunas quejas arriba acerca de tener enlaces a las cosas de Joel, en lugar de texto en línea, así que aquí está mi opinión sobre lo que está diciendo.
En los niveles más altos, las especificaciones funcionales deben comunicar lo que el programa pretende hacer al consumidor o cliente. Estoy 100% con Joel en esto: el idioma en inglés (¡bueno, cualquiera!) Usado con rigor es una herramienta muy poderosa en la que todos sus clientes serán expertos en digerir. Los expertos en UML no lo son.
Un documento de especificación funcional de nivel superior (FSD) puede proporcionar un marco lógico que capture los requisitos del sistema dentro de un modelo lógico que las personas puedan entender fácilmente.
Los documentos de requisitos puros, algo que precede a un FSD, son un problema difícil de tratar. Muy pocas personas pueden diferenciar mentalmente lo que es un requisito y lo que forma parte de la solución. Así que es mejor mantener los requisitos a un nivel muy alto y, como analista, centrarse en el FSD.
El FSD debe ser un modelo completo de alto nivel del sistema, y el proceso de diseño subsiguiente para desarrollar una jerarquía de modelos con más detalle. El último nivel de detalle es el código real.
El FSD debería terminar con un conjunto de simples declaraciones en inglés. Use un solo nivel de encabezado en los documentos, mantenga los párrafos a dos oraciones como máximo y numere cada párrafo. Revise los párrafos y asegúrese de que cada uno diga algo útil. Si no, bórralo. Corto es bueno!
Piensa mucho sobre el lenguaje en tu FSD. Tenga definiciones rigurosas de los sustantivos clave en sus párrafos. Estos sustantivos se convierten en tus clases. Los verbos que usas se convierten en tus métodos de clase. ¡Es realmente así de simple!
Como dice Joel, escribe oraciones como las vas a compilar. Por ejemplo, escriba " Si suceden cosas , haga más" en lugar de " Si suceden cosas, haga más" o "haga más cuando suceden cosas".
Este tipo de modelos escritos pueden beneficiarse del uso de diagramas específicos, como los diagramas de estados finitos, pero tenga cuidado al pensar que puede capturar un sistema utilizando un conjunto de diagramas UML. Estas cosas simplemente no son lo suficientemente poderosas, flexibles o rigurosas para actuar como una descripción completa por sí mismas. Es mucho más efectivo comenzar con un esquema escrito en inglés riguroso y complementarlo según sea necesario.
En cuanto a los problemas de iteración, en un mundo ideal, solo debe volver a trabajar en los niveles más bajos del modelo. Si tienes que cambiar los niveles altos, algo grave estaba mal. En cuanto a que las herramientas UML son más rápidas para habilitar la revisión, ¡poppy-cock! La clave es que todas estas descripciones son CORTAS y CONCISE. El inglés es el camino a seguir, porque todos hemos practicado esto durante tanto tiempo.
He visto a personas pasar una tarde tratando de que los diagramas de entidades se vean bonitos en términos de líneas superpuestas. Como por que ¿Es su solución definitiva las cajas y líneas de dos dimensiones? ¡No! Y ese es el problema con UML: los diagramas se convierten en un fin en sí mismos para el analista y lo excluyen del cliente, en lugar de ayudar a la comunicación.