Desarrollar el concepto del producto. Asignar requisitos de hardware y software N

Transcripción

1 Fase de Análisis de Requerimientos Desarrollar el concepto del producto. Asignar requisitos de hardware y software. Realizar estudios de mercado. Sugerencia: para saber cuantas instituciones de educacion superior son potencialmente nuestros clientes asi como lo es la UACh para el SUAE Escribir plan de negocios. Buscarlo en wikipedia o google, cualquier sugerencia de un plan de negocios esta correcto Escribir documento del concepto del producto. (se anexa un archivo para identificar QUE es el concepto del producto) Crear RTM (Requirements Traceability Matrix), tabla o matriz donde se contempla (traza el tiempo estimado del proyecto. No el tiempo, sino las coincidencias entre los requisitos funcionales de alto nivel y los requisitos funcionales detallados y requisitos no funcionales como sigue: N X X M Como se puede observar, cada número entero o con un decimal son los requisitos funcionales de alto nivel, por otro lado los números con varios decimales son los requisitos funcionales a detalle o no funcionales. Además se destacan los símbolos y X que indican la coincidencia u obligación de contener un requerimiento al otro y la X indica que no deben coincidir o que no deben llevarse a cabo al mismo tiempo. Por otro lado cabe resaltar que cada número con o sin decimal debe estar detallado en el SRS (Sw requirements specification).

2 Documento del concepto del producto. (que es el mismo que el de las actividades) Plan de negocios. Instrumentos (o mejor dicho Herramientas, software o manuales) Herramientas de seguimiento de requerimientos. Instrumentos de investigación. Especificación de los conceptos (revisado y aprobado) Plan de negocios (revisado y aprobado) RTM (creado). Métricas: (o Indicadores) Horas hombre gastadas por fecha. Número requerimientos probables (que se pueden probar) identificados. Número requerimientos no probables (que NO se pueden probar) identificados. NOTA: como puede Usted observar, no todos los puntos son desarrollables, es decir, solo algunos puntos en las fases se llevan a cabo, por ejemplo, los propósitos de cada fase no son desarrollables, solo nos indican que se va a hacer de manera general. Las Actividades se repiten con los Entregables, a veces con los Criterios y pocas veces con los Indicadores por lo que solo se desarrollan una sola vez Fase de Definición de Requerimientos Definir los requisitos para los que será utilizado el Software. Refinar los requerimientos contenidos en la especificación del Concepto Definir las metáforas de Interfaz de Usuario. NO SE VAN A. Las metáforas se refieren a los deseos o ejemplos que hace el cliente cuando se le entrevista, por mencionar algunos: me gustaria que el SUAE fuera de color rosa, porque, seria interesante que se pudiera hacer una impresión a la hora de Escribir SRS (Software Requirement Specification) con la descripción completa de los requisitos del software. Buscar el archivo IEEE- Std en la web

3 Lineamientos o requisitos de inspección sobre el SRS. NO se va a desarrollar Actualización del RTM. Si es que aplica, es decir, si en la primer fase contemplo N requerimientos y hasta el momento no hay mas requerimientos, entonces no se actualiza el RTM SRS (Software Requirement Specifications) especificación de los requerimientos del software. Metáforas de la interfaz del usuario. NO SE VAN A Plan de desarrollo del software. Sugerencia: una calendarización de las etapas del desarrollo del SUAE Análisis de rendimiento. NO SE VAN A Herramientas de estructura, análisis y modelado de información. NO SE VAN A Herramientas de seguimiento de los requerimientos. NO SE VAN A SRS, plan de desarrollo de software y plan aprobado del software V&V. Solamente el SRS Requerimientos de Inspección planeados para el SRS NO SE VAN A Interfaz de usuario (guía de estilo). NO SE VAN A Indicadores: RTM completo. Número y tipo de errores y defectos encontrados durante los requerimientos de Inspección del SRS. NO SE VAN A Fase de Diseño Desarrollo claro, conciso y diseño consistente. Establecer un ambiente controlado para la fase de codificación. Elaborar la Arquitectura de Software. Solamente indicar que arquitectura se usó o se usa en el SUAE Desarrollar el diseño de software de alto nivel. Sugerencia: Diagrama de paquetes del UML Desarrollar el diseño detallado del software. NO SE VAN A Realizar inspecciones del diseño. NO SE VAN A

4 Desarrollar la arquitectura de software del diseño del software de alto nivel y las especificaciones detalladas del diseño del software. NO SE VAN A Comenzar el desarrollo de los procedimientos de prueba de software de validación basados en el SRS. NO SE VAN A Desarrollar un plan confiable del crecimiento del software. NO SE VAN A Evaluar y seleccionar el SCM (Software configuration Management) Por el momento no lo vamos a desarrollar hasta que veamos el tema Gestión de la Configuración, se enfoca en la administración de entregas, liberaciones, versiones y la forma en general que nosotros como ingenieros de software administramos nuestro producto y nuestros servicios. Y el SPR (Software Problem Report), y herramientas de seguimiento. Seleccionar y evaluar herramientas automatizadas de pruebas de software de validación. NO SE VAN A Actualizar el RTM. Si es que aplica Arquitectura del software, especificaciones del diseño de alto nivel y especificaciones detalladas del diseño. NO SE VAN A Procedimientos de pruebas de validación del software. NO SE VAN A Plan de SCM (Software Configuration Management).NO SE VAN A. Consultar el Estándar IEEE- Std Plan de pruebas de validación de software. NO SE VAN A Plan de crecimiento confiable de software. NO SE VAN A Plan de exámenes alfa y beta.no SE VAN A Herramientas de Información de Modelado de Diseño Estructurado. NO SE VAN A Herramientas de diseño detallados (diagramas, matrices, etc.). UML por ejemplo Herramientas de análisis de rendimiento. NO SE VAN A Herramientas de gestión de configuración. NO SE VAN A Herramientas de validación automatizada de las pruebas de software. NO SE VAN A Herramientas de seguimiento de reportes de problemas de software. Puede ser el Excel Herramientas de seguimiento de requerimientos. RTM Arquitectura de software revisada y aprobada. NO SE VAN A Especificaciones del diseño de software aprobado. NO SE VAN A Diseño de las inspecciones que tengan lugar. NO SE VAN A Plan SCM aprobado. NO SE VAN A Herramientas SCM seleccionadas que se utilizaran. NO SE VAN A Software de validación y plan de pruebas alfa y beta revisado y aprobadas. NO SE VAN A

5 Indicadores: RTM al momento (actualizado). Número y tipo de errores y defectos encontrados la inspección. NO SE VAN A Fase de Codificación (en esta fase vamos a hacer pocas cosas, puesto que en este ejercicio solamente vamos a hacer documentación y no codificación) Escribir código que implemente los requisitos contenidos en el SRS según lo expresado por la lista de arquitectura general y según las especificaciones de diseño. Desarrollar código. NO SE VAN A Realizar inspecciones al código en módulos seleccionados. NO SE VAN A Integrar y realizar pruebas de integración. NO SE VAN A Implementar los procedimientos SCM. NO SE VAN A Implementar el software de reporte de seguimiento de problemas. Crear un procedimiento para llevar a cabo el seguimiento de problemas (por ejemplo una bitacora cuando un usuario reporta un problema del SUAE) Implementar el software de seguimiento de los procesos para la fiabilidad del crecimiento del software. NO SE VAN A Aplicar las métricas de calidad del software a los módulos seleccionados. NO SE VAN A Completar el desarrollo de los procedimientos de pruebas de validación de software basado en el SRS. NO SE VAN A Llevar a cabo procedimientos de inspección de exámenes de validación de software. NO SE VAN A Desarrollar los procedimientos de lanzamiento de software. Crear un procedimiento para llevar a cabo el seguimiento de las liberaciones (por ejemplo una bitacora cuando nosotros le entregamos a la UACh una version o un subsistema y que no firme de recibido, etc) Actualizar la documentación del proyecto (especificación de diseño, SRS, SDD, etc.). Si aplica Realizar la validación de la disposición de la revisión de software. Crear un procedimiento para llevar a cabo el seguimiento de problemas (por ejemplo una bitacora cuando un usuario reporta un problema del SUAE) Actualizar la RTM. Código fuente. NO SE VA A

6 Procedimientos de pruebas de validación de software. NO SE VA A Procedimientos de fiabilidad de criamiento del software. NO SE VA A Procedimientos de validación de software. NO SE VA A Informe de problemas del software. Los procedimientos desarrollados Codificación de las herramientas (compiladores, depuradores, etc.). OK Calidad de las herramientas métricas (complejidad del código). NO SE VA A Herramientas SCM. NO SE VA A Herramientas de seguimiento de informes de errores de software. NO SE VA A Herramientas de exámenes automatizados de validación de software. NO SE VA A Herramientas del seguimiento del crecimiento confiable del software. NO SE VA A Herramientas del seguimiento de requerimientos. Por ejemplo Excel (como el RTM) Codificación (código) completo. NO SE VA A Todos los códigos fuente bajo la configuración del control de gestión. NO SE VA A Reportes de rastreo de problemas de software que tuvieron lugar. NO SE VA A Seguimiento de confiabilidad de crecimiento de software que tuvieron lugar. NO SE VA A Revisión de la disposición de la validación de software que tuvieron lugar. NO SE VA A Procedimientos de exámenes de validación de software aprobados. NO SE VA A Procedimientos de inspección de exámenes (o de exámenes de inspección) que tuvieron lugar. NO SE VA A Todas las pruebas de validación de software ejecutadas al menos una vez. NO SE VA A Indicadores: Número y tipo de errores y defectos observados en el código durante las inspecciones. Se puede elaborar una lista de verificacion (checklist) o un procedimiento Número y tipo de errores y defectos observados en las inspecciones durante los procedimientos de prueba. NO SE VA A Complejidad y métricas de calidad para cada módulo. NO SE VA A Tamaño de cada módulo (líneas del código fuente). NO SE VA A Tamaño del ejecutable (número de bits). NO SE VA A RTM la momento (actualizado). Fase de Pruebas, NO SE VA A IMPLEMENTAR

7 Determinar si el software cumple los requerimientos definidos en el SRS. Ejecutar los procedimientos de las pruebas de validación del software. NO SE VA A Seguir y resolver problemas que se identifiquen como resultado de la ejecución de las pruebas. NO SE VA A Pruebas de rendimiento de regresión que se requieran. NO SE VA A Corregir errores y realizar nuevas versiones para las pruebas de validación. NO SE VA A Reporte de exámenes de validación de software. NO SE VA A Versión final de software para su liberación. NO SE VA A Herramientas automatizadas de pruebas de validación de software. NO SE VA A Herramientas de seguimiento de rastreo de pruebas de software. NO SE VA A Herramientas SCM. NO SE VA A Herramientas de codificación y depuración. NO SE VA A Herramientas de seguimiento de requisitos. NO SE VA A Criterios finales de exámenes de validación de software. NO SE VA A Informe de pruebas de validación de software revisado y aprobado. NO SE VA A Indicadores: Tiempo de búsqueda y corrección de errores. NO SE VA A Medición de la cobertura de pruebas. NO SE VA A Métrica de fiabilidad del crecimiento del software. NO SE VA A Fase de Mantenimiento Proporcionar apoyo continuo al producto después de su liberación.

8 Corregir defectos conocidos. NO SE VA A Hacer cambios al software para corregir deficiencias en el producto. NO SE VA A Arreglar nuevas funciones o mejorar las actuales características. NO SE VA A Realizar numerosas pruebas basadas en los cambios realizados. NO SE VA A Hacer pruebas de regresión.no SE VA A Actualización de la documentación del producto (SRS, SDD, test de procedimientos, etc.). NO SE VA A Nuevas versiones del software. Elaborar una propuesta de un documento para el control de versiones, existen algunas en la web Actualizaciones de la documentación del producto. Las que apliquen hasta el momento Las mismas utilizadas en las fases anteriores para el desarrollo y pruebas del producto. Decisiones que apoyen el producto discontinuo.no SE VA A Indicadores: Número y tipo de errores reportados por los clientes. Elaborar una propuesta de documento para registrar errores, fechas, descripcion, etc Número y tipo de nuevas características solicitadas por los clientes. Elaborar una propuesta de documento para registrar caracteristicas, fechas, descripcion, etc Tiempo de búsqueda y creación de errores. Elaborar una propuesta de documento para registrar errores, fechas, descripcion, tiempo de busqueda y sobre todo tiempo de respuesta