El documento de requerimientos es el producto arquitectónico de diseño por defecto en todo procesos de desarrollo de software. Dicho recurso plasma los flujo de información y los requerimientos que fueron analizados en el proceso de análisis. Este artefacto nos da paso a la creación de los los diagramas fundamentales para la construcción del software.
Los diagramas fundamentales para la codificación del software que son productos inmediatos del documento de requerimientos son: El diagrama de clases y el diagrama entidad relación. El primero nos muestra la conexión de las clases (en programación orientada a objetos es un modelo de abstracción de algún objeto) así como sus componentes (métodos y atributos). El siguiente y a juicio de muchos autores la base fundamental de un sistema es el diagrama entidad relación. Este diagrama muestra gráficamente la construcción de la base de datos, a partir de la cual girarán todas las transacciones que haga el sistema en su operación.
Pero existe otro resultado de la creación de este documento tan vital: el diagrama de secuencias. El modelo mencionado es sumamente efectivo si se combina con un proceso llamado ingeniería inversa. El documento de requerimientos en realidad es nuestro diagrama de secuencias, sólo que de manera escrita. Cada punto de los flujos del documento en realidad son las acciones que hace el sistema en un cierto tiempo de vida. Si utilizamos la notación UML para pasar estos puntos al medio grafico, obtendremos sin problemas todos los diagramas de secuencia del sistema.
Con los diagramas de secuencia listos, por medio de herramientas CASE ( Computer Aided Software Engineering ) y el proceso de ingeniería inversa aplicado a dichos diagramas obtendremos el diagrama de clases del sistema. Esto resulta ampliamente beneficioso ya que de un solo documento estamos obteniendo un diagrama de manera automática, en este caso el diagrama de clases.
Hasta este punto contamos con lo siguiente: Diagrama de casos de uso, Documento de Requerimientos, Diagrama de Clases, Diagrama de Secuencias, Diagrama Entidad-Relación y todos los documento de planeación de trabajo del sistema como gráfica de gantt y diagrama de ruta crítica.
Desde el punto de vista de modelos de métodos ágiles se podría decir que es más que suficiente todo este meterial construído; pero desde el punto de vista de modelos tradicionales de desarrollo de software aun no es suficiente todo lo logrado, ya que el documentar hasta los más recondito del sistema es prioridad. En este caso tradicional aun nos falta la creación de varios modelos de UML, como los siguientes: Diagrama de Actividades, Diagrama de Estados, Diagrama de colaboración, Diagrama de componentes, Diagrama de objetos y Diagrama de despliegue.
En este caso no ampliaremos el tema hasta estos diagramas que sólo sirven para reforzar el modelado del sistema basado en los diagramas construídos con anterioridad.
Los diagramas fundamentales para la codificación del software que son productos inmediatos del documento de requerimientos son: El diagrama de clases y el diagrama entidad relación. El primero nos muestra la conexión de las clases (en programación orientada a objetos es un modelo de abstracción de algún objeto) así como sus componentes (métodos y atributos). El siguiente y a juicio de muchos autores la base fundamental de un sistema es el diagrama entidad relación. Este diagrama muestra gráficamente la construcción de la base de datos, a partir de la cual girarán todas las transacciones que haga el sistema en su operación.
Pero existe otro resultado de la creación de este documento tan vital: el diagrama de secuencias. El modelo mencionado es sumamente efectivo si se combina con un proceso llamado ingeniería inversa. El documento de requerimientos en realidad es nuestro diagrama de secuencias, sólo que de manera escrita. Cada punto de los flujos del documento en realidad son las acciones que hace el sistema en un cierto tiempo de vida. Si utilizamos la notación UML para pasar estos puntos al medio grafico, obtendremos sin problemas todos los diagramas de secuencia del sistema.
Con los diagramas de secuencia listos, por medio de herramientas CASE ( Computer Aided Software Engineering ) y el proceso de ingeniería inversa aplicado a dichos diagramas obtendremos el diagrama de clases del sistema. Esto resulta ampliamente beneficioso ya que de un solo documento estamos obteniendo un diagrama de manera automática, en este caso el diagrama de clases.
Hasta este punto contamos con lo siguiente: Diagrama de casos de uso, Documento de Requerimientos, Diagrama de Clases, Diagrama de Secuencias, Diagrama Entidad-Relación y todos los documento de planeación de trabajo del sistema como gráfica de gantt y diagrama de ruta crítica.
Desde el punto de vista de modelos de métodos ágiles se podría decir que es más que suficiente todo este meterial construído; pero desde el punto de vista de modelos tradicionales de desarrollo de software aun no es suficiente todo lo logrado, ya que el documentar hasta los más recondito del sistema es prioridad. En este caso tradicional aun nos falta la creación de varios modelos de UML, como los siguientes: Diagrama de Actividades, Diagrama de Estados, Diagrama de colaboración, Diagrama de componentes, Diagrama de objetos y Diagrama de despliegue.
En este caso no ampliaremos el tema hasta estos diagramas que sólo sirven para reforzar el modelado del sistema basado en los diagramas construídos con anterioridad.
No hay comentarios:
Publicar un comentario