Plan de SQA SI-Admin Clinic Sistema de información en ambiente web para administrar la información de la clínica de salud de la ciudad de Bogotá Calidad en el desarrollo de software Plan de SQA Tabla de contenido Propósito ...................................................................................................................................................... 4 Referencias ...................................................................................................................................................... 4 Gestión ......................................................................................................................................................... 5 Organización ................................................................................................................................................... 5 Actividades ...................................................................................................................................................... 9 Ciclo de vida del software cubierto por el Plan .......................................................................................... 9 Actividades de calidad a realizarse ............................................................................................................. 9 Evaluar los requerimientos ................................................................................................................ 10 Evaluar el diseño del software ........................................................................................................... 11 Evaluar las pruebas de módulos implementados ........................................................................... 12 Evaluar el proceso de acciones correctivas ..................................................................................... 13 Evaluar la administración de la configuración ............................................................................... 14 Relaciones entre las actividades de SQA y la planificación ....................................................................... 15 Responsables ................................................................................................................................................. 15 Documentación .......................................................................................................................................... 19 Propósito ....................................................................................................................................................... 19 Documentación mínima requerida ................................................................................................................ 19 Los documentos mencionados en la siguiente tabla deben de estar bajo la administración de la configuración, enviando una petición al administrador de aseguramiento de la calidad cuando se realicen cambios, para que este determine si el documento puede entrar a la línea base. ............. 20 Especificación de requerimientos del software ........................................................................................ 20 Descripción del diseño del software ......................................................................................................... 23 Plan de Verificación & Validación ............................................................................................................. 23 Reporte de verificación y validación ................................................................................................. 24 Documentación de usuario ....................................................................................................................... 24 Plan de Gestión de configuración .................................................................................................................. 25 Propósito................................................................................................................................................... 25 Resumen ................................................................................................................................................... 25 Organización, Responsabilidades ............................................................................................................. 25 Herramientas, Entorno, e Infraestructura ................................................................................................ 26 Forma de trabajo ...................................................................................................................................... 26 Control de Cambios .................................................................................................................................. 26 Reportes y Auditorias ............................................................................................................................... 27 Otros documentos ......................................................................................................................................... 27 Plan del proyecto ........................................................................................................................................ 27 Plan de desarrollo ...................................................................................................................................... 27 Estándares, prácticas, convenciones y métricas .......................................................................................... 27 Objetivos ....................................................................................................................................................... 28 Métricas de proceso ...................................................................................................................................... 28 Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 2 de 39 Plan de SQA Métricas de proyecto .................................................................................................................................... 29 Métricas de producto .................................................................................................................................... 29 Estándar de documentación.......................................................................................................................... 30 Estándar de verificación y prácticas .............................................................................................................. 31 Otros Estándares ........................................................................................................................................... 31 Estándar de documentación en general ........................................................................................................ 31 Estándar de documentación en técnica ........................................................................................................ 32 Estándar de implementación ........................................................................................................................ 32 Revisiones y auditorías ............................................................................................................................... 32 Objetivo ......................................................................................................................................................... 32 Requerimientos mínimos ............................................................................................................................... 32 Revisión de requerimientos ...................................................................................................................... 33 Revisión de diseño preliminar .................................................................................................................. 33 Revisión de diseño crítico ......................................................................................................................... 33 Revisión del plan de verificación & validación .......................................................................................... 33 Auditoría funcional ................................................................................................................................... 33 Auditoría física .......................................................................................................................................... 33 Auditorías internas al proceso .................................................................................................................. 33 Revisiones de gestión ............................................................................................................................... 34 Revisión del Plan de gestión de configuración ......................................................................................... 34 Revisión Post Mortem .............................................................................................................................. 34 Agenda ...................................................................................................................................................... 34 Otras revisiones ............................................................................................................................................. 36 Revisión de documentación de usuario .................................................................................................... 36 Revisiones técnicas formales RTF ............................................................................................................. 36 Verificación ................................................................................................................................................ 37 Reporte de problemas y acciones correctivas ............................................................................................. 37 Herramientas, técnicas y metodologías ...................................................................................................... 37 Gestión de riesgos ...................................................................................................................................... 38 Política de calidad....................................................................................................................................... 38 Anexos........................................................................................................................................................ 39 Formulario de Pedidos y Detección de Cambios ........................................................................................... 39 Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 3 de 39 Plan de SQA Plan de SQA Propósito El propósito de este plan es especificar las actividades que se realizarán para asegurar la calidad del software a construir. En él se detallan los productos que se van a revisar y los estándares, normas o métodos a aplicar; los métodos y procedimientos que se utilizarán para revisar que la elaboración de los productos se realice como lo establece el modelo de ciclo de vida del proyecto; y procedimientos para informar a los responsables de los productos los defectos encontrados y realizar un seguimiento de dichos defectos hasta su corrección. El software a realizar es un sistema de información modular en un ambiente web en el cual se podrá realizar el registro e ingreso u hospitalización de los pacientes de la clínica de salud de la ciudad de Bogotá, que permite gestionar la información de los pacientes, de las habitaciones y camas ocupadas, los materiales y medicamentos utilizados. Calculando el costo de la hospitalización al momento de dar de alta a los pacientes. Además de, permitir consultar las camas y habitaciones disponibles, ocupadas y las características del paciente que ocupa la cama. Con el sistema de información web para la administración de la información de la clínica de salud se quiere lograr: Mejorar la calidad y eficiencia en el control de la información de los pacientes de la clínica. Gestionar de manera más eficiente la información y utensilios de la clínica como las habitaciones, las camas y medicamentos utilizados. Disminuir la carga de trabajo de los administradores. Disminuir el tiempo el cálculo de los costos de la hospitalización al momento de dar de alta a los pacientes. Administrar la información de la infraestructura de la clínica como las habitaciones, camas ocupadas y disponibles, información de medicamentos y las características del paciente que ocupa cada cama. Referencias [ANSI/IEEE Std 730.1-1989, IEEE Standard for Software Quality Assurance Documento Plantilla gestión de riesgos Documento plan de gestión de riesgos Documento plantilla de revisión de SQA Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 4 de 39 Plan de SQA Documento Informe Final de SQA Documento plantilla de Revisión técnica formal SQuaRE, ISO 25000:2005, Quality management systems – Requirements ISO 9001:2008] Gestión En las subsecciones siguientes se especifican los elementos de la organización que tienen influencia sobre la calidad del software, como está conformada la línea de gestión de calidad, y de quien es la autoridad y responsabilidad por la calidad del software, la lista de tareas cubiertas por este plan y las responsabilidades por cada tarea. Organización Primeramente, debemos identificar las siguientes líneas de trabajo, que acompañan a todo el ciclo de vida del proyecto: Gestión de Proyecto Su principal objetivo es proveer la planificación del proyecto, que incluye los objetivos y mecanismos de interacción entre las distintas fases: Inicial, construcción de productos de software, Construcción de productos de Investigación y Presentación. Además, realiza estimaciones, mediciones y analiza la factibilidad del proyecto. Es preciso destacar, que el éxito del proyecto depende en gran medida de una buena Gestión, por lo que se debe prestar especial énfasis en la calidad de esta, destacando un buen seguimiento del proyecto. Gestión de la Configuración y control de Cambios Su principal objetico es identificar, definir y gestionar los elementos del proyecto que deben estar bajo configuración. Es preciso hacer notar, que esta línea de trabajo resulta de gran importancia para el desarrollo del proyecto, dado que debe asegurar que no existan inconsistencias en el sistema desarrollado, como por ejemplo resultante de conflicto de versiones, la no notificación de cambios, así como la realización de ciertos cambios sin la consideración global en este plan. Existen varias líneas de trabajo que influyen en el proyecto para controlar la calidad: Levantamiento de Requerimientos. Diseño del sistema de información web. Gestión del Proyecto establecido. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 5 de 39 Plan de SQA Verificación del proyecto. Administración de Configuración y control de cambios. Gestión de la Calidad del software. Existen algunas dependencias entre las líneas de trabajo antes mencionadas. Los requerimientos no funcionales son necesarios para el diseño de la arquitectura. La gestión del proyecto controla el avance del proyecto garantizando que se cumplan las tareas planificadas en las demás líneas. La gestión de configuración debe entre otras cosas tener un control de los elementos generados por el equipo lo que implica una colaboración de las líneas básicas. Descripción de la estructura organizacional: 1. Administrador del plan SQA: El administrador es el responsable de las siguientes funciones: 1.1. Establecer un programa de calidad para el proyecto. 1.2. Identificar las actividades de SQA que se llevaran a cabo durante el proyecto. 1.3. Revisar y aprobar el plan de SQA del proyecto. 1.4. Resolver los problemas encontrados relacionados con la calidad. 1.5. Realizar la auditoria y el reporte de las funciones SQA para el proyecto. 1.6. Identificar los factores de calidad a ser implementados en el proyecto. 2. Administración de la configuración del software: El administrador de la configuración es responsable de las siguientes funciones: 2.1. Realizar la revisión sobre el plan SQA establecido para el proyecto. 2.2. Implementar los factores de la calidad referentes a los procesos de aseguramiento de la calidad de software, o asegurarse de que están siendo implementados. 2.3. Revisar que los interesados en el proyecto cumplan con el plan SQA para el proyecto. 2.4. Implementar las actividades definidas de calidad acordadas en el plan de SQA. 3. Administración del proyecto: La administración del proyecto es la responsable de las siguientes funciones: Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 6 de 39 Plan de SQA 3.1. Revisar y aprobar el plan SQA del proyecto para el desarrollo de un sistema de información web para administrar la información de la clínica de salud de la ciudad de Bogotá. 3.2. Identificar al personal que realiza las funciones correspondientes del plan SQA. 3.3. Identificar los factores de calidad a ser implementados en el sistema de información web para administrar la información de la clínica de salud. 3.4. Dar seguimiento a cualquier asunto de calidad obtenido por el plan SQA. 3.5. Asegurar que los factores de calidad sean implementados correctamente en el sistema de información web. 3.6. Identificar, desarrollar y mantener los documentos de planeación del proyecto. 4. Área de pruebas: El área de pruebas son los responsables de las siguientes funciones: 4.1. Resolver y dar seguimiento a cualquier asunto de calidad que tenga relación con las pruebas del sistema. 4.2. Implementar las prácticas de pruebas en el sistema de información web, procesos y procedimientos, como se encuentra definido en el documento de pruebas del proyecto. 4.3. Realizar la implementación de la calidad en la realización de las pruebas de acuerdo al plan SQA. 4.4. Comentar acerca del plan SQA. 4.5. Implementar la calidad en las pruebas descuerdo al plan SQA. 5. Área de diseño y codificación: El área de diseño y codificación del sistema son los responsables de las siguientes funciones: 5.1. Realizar con calidad el diseño y la codificación del sistema de información de acuerdo a lo establecido en el plan SQA. 5.2. Resolver y dar seguimiento a cualquier asunto de calidad que tenga relación con el diseño del sistema, su arquitectura y desarrollo. 5.3. Identificar, implementar y evaluar los factores de calidad que serán implementados en el sistema de información. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 7 de 39 Plan de SQA 5.4. Implementar el diseño, la arquitectura, el desarrollo, procesos y procedimientos necesarios para el sistema de información web, siguiendo los documentos de planeación para cada uno de estos. 5.5. Comentar acerca del plan SQA. 6. Administración de los riesgos: La administración de los riesgos es la responsable es el responsable de las siguientes funciones: 6.1. Realizar el seguimiento a los riesgos identificados. 6.2. Buscar medidas de contingencia de los riesgos identificados. 6.3. Realizar comentarios de mejora al plan SQA. 6.4. Notificar a la administración del proyecto cuando un riesgo identificado, se convierta en una amenaza para el proyecto. 7. Administración de los requerimientos: La administración de los requerimientos es la responsable de las siguientes funciones: 7.1. Realizar la especificación de los requerimientos del software a desarrollar. 7.2. Implementar la calidad durante la realización de los requerimientos del software. 7.3. Realizar el debido análisis a los requerimientos establecidos para el proyecto. 7.4. Implementar calidad en la especificación de los requerimientos del software. 7.5. Comentar acerca del plan de aseguramiento de la calidad. 8. Área de métricas: El área de métricas es la responsable de las siguientes funciones: 8.1. Realizar el plan de métricas para el proyecto. 8.2. Evaluar las métricas obtenidas a lo largo del proyecto. 8.3. Realizar la implementación de la calidad al realizar el plan de métricas del proyecto 8.4. Comentar acerca del plan de aseguramiento de la calidad. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 8 de 39 Plan de SQA Actividades Ciclo de vida del software cubierto por el Plan El alcance del Plan SQA cubre desde la fase correspondiente al levantamiento de los requerimientos hasta la fase de implementación del producto final en el cliente. Los productos establecidos que tendrán revisiones son los siguientes: 1. Especificación de los Requerimientos (ERS) 2. Descripción de la Arquitectura del sistema 3. Estándares de Documentación de Usuario 4. Plan de Verificación y Validación 5. Plan del Proyecto 6. Plan de la Configuración 7. Plan de Desarrollo 8. Plan de Implementación 9. Informe final del proyecto Actividades de calidad a realizarse Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar, los estándares a seguir, los productos a revisar, los procedimientos a seguir en la elaboración de los distintos productos y los procedimientos para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su corrección. ACTIVIDAD ENTREGABLE Realizar el plan SQA Plan SQA Identificar las propiedades de calidad Propiedades de calidad Evaluar la calidad de los productos Informe de revisión SQA Revisar el ajuste al proceso Informe de revisión SQA Realizar revisión técnica formal Informe de revisión técnica formal Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 9 de 39 Plan de SQA Evaluar y ajustar el plan SQA Documento de evaluación y ajuste del plan SQA Realizar la entrega semanal Entrega semanal de SQA Realizar evaluación final de SQA Evaluación final SQA Reuniones de apoyo a la calidad No aplica Las actividades que se realizarán para llevar a cabo el proyecto correspondiente al sistema de información web para administrar la información de la clínica de salud de la ciudad de Bogotá son: Evaluar los requerimientos Evaluar el diseño del software Revisar cada producto Revisar el ajuste al proceso Evaluar las pruebas de módulos implementados Evaluar el proceso de acciones correctivas Evaluar la administración de la configuración Realizar Revisión Técnica Formal (RTF) Asegurar que las desviaciones son documentadas. Evaluar los requerimientos El análisis de requerimientos establece un mutuo acuerdo entre el equipo del proyecto de software y el cliente. Se deberá mantener y establecer un acuerdo con el cliente para realizar el análisis de requerimientos del sistema. Es por esto que se debe tener una línea de comunicación abierta y fiable con el cliente, con la cual los requerimientos del software sean acordes a los estándares de calidad y a las expectativas y demandas del cliente. Las actividades del personal de calidad en esta tarea son: 1. Revisar los requerimientos para determinar si son claros y consistentes. 2. Verificar que los cambios en el documento de requerimientos del sistema, sean seguidos, revisados y comunicados al equipo de desarrollo. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 10 de 39 Plan de SQA 3. Verificar que los compromisos con el cliente sean documentados, y comunicados al equipo de desarrollo. 4. Verificar que los procesos descritos para definir, documentar y localizar requerimientos se lleven a cabo. 5. Verificar que los requerimientos están documentados, administrados, controlados y seguidos (de preferencia mediante una matriz de rastreo). El resultado de esta tarea se documentará usando el Formato del proceso de auditoría y se entregará al administrador del proyecto. Las recomendaciones correctivas realizadas por el SQA requieren la disposición del administrador del proyecto. Evaluar el diseño del software El objetivo del proceso de diseño del software es tomar decisiones sobre el comportamiento del diseño del sistema. Se tendrá que tomar en cuenta la arquitectura del sistema dividiendo el sistema en subsistemas. El nivel de detalle del diseño debe ser tal que el código de los módulos pueda ser realizado por otra persona que no sea su diseñador original. Esto con el fin de prever futuras inspecciones y evaluaciones al diseño del software, para que pueda ser manipulado por terceros sin la necesidad de acudir a la persona que lo elaboro en primer lugar. Las actividades del SQA en esta tarea son: 1. Verificar que los procesos de diseño de software sigan los estándares determinados. 2. Verificar que todos los requerimientos estén presentes en el diseño. 3. Verificar que el diseño se encuentre bajo la administración de la configuración. 4. Revisar y auditar el contenido de los documentos de diseño del sistema. 5. Si se encuentran no cumplimientos de los estándares establecidos, determinar las acciones correctivas. El resultado de esta tarea se documentará usando el Formato del proceso de auditoría y se entregará al administrador del proyecto. Las recomendaciones correctivas realizadas por el SQA requieren la disposición del administrador del proyecto. Revisar cada producto En esta actividad se revisan los productos que se definieron como claves para verificar en el Plan de calidad. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 11 de 39 Plan de SQA Se debe verificar que no queden correcciones sin resolver en los informes de revisión previos, si se encuentra alguna no resuelta, debe ser incluida en esta revisión. Se revisan los productos contra los estándares, utilizando la checklist definida para el producto. Se debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar que se hayan realizado las correcciones. Como salida se obtiene el Informe de revisión de SQA, este informe debe ser distribuido a los responsables del producto y se debe asegurar de que son conscientes de desviaciones o discrepancias encontradas. Revisar el ajuste al proceso En esta actividad se revisan los productos que de definieron como claves para verificar el cumplimiento de las actividades definidas en el proceso. Con el fin de asegurar la calidad en el producto final del desarrollo, se deben llevar a cabo revisiones sobre los productos durante todo el ciclo de vida del software. Se debe recoger la información necesaria de cada producto, buscando hacia atrás los productos previos que deberían haberse generado, para poder establecer los criterios de revisión y evaluar si el producto cumple con las especificaciones. Esta información se obtiene de los siguientes documentos: Plan del Proyecto, Plan de la iteración, Plan de Verificación. Antes de comenzar, se debe verificar en los informes de revisión previos que todas las desviaciones fueron corregidas, si no fuese así, las faltantes se incluyen para ser evaluadas. Como salida se obtiene el Informe de revisión de ajuste al Proceso, este informe debe ser distribuido a los responsables de las actividades y se debe asegurar de que son consientes de desviaciones o discrepancias encontradas. Evaluar las pruebas de módulos implementados En esta etapa, las pruebas de integración combinan individualmente componentes ya encontrados, realizando las pruebas pertinentes para garantizar la calidad de los diferentes módulos incorporados en el sistema de información. Garantizando que los procesos que se llevaran a cabo en la aplicación web cumplan con lo establecido, según las especificaciones del cliente y las normas estándar de calidad de software. Los encargados de las pruebas prestarán especial atención a: 1. El buen funcionamiento de las interfaces entre los componentes. 2. El flujo de información a través del sistema. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 12 de 39 Plan de SQA 3. La satisfacción de los requisitos del sistema. 4. Verificar que las discrepancias descubiertas en la integración de software y pruebas de rendimiento son identificadas, analizadas, documentadas, y corregidas. 5. Revisar el Plan de Pruebas de Software y que las descripciones de las pruebas de software cumplan con los requerimientos. 6. Verificar que el software es probado. 7. Monitorear las actividades de pruebas. 8. Verificar que los encargados de las pruebas de unidad se apeguen al plan de pruebas. 9. Confiabilidad al momento de levar a cabo los procesos establecidos, además que se pueda confiar en la información proporcionada por el software. 10. Facilidad de mantenimiento del software según las pruebas realizadas o discrepancias encontradas. Como Resultado de este proceso se obtiene un Informe de revisión de SQA que corresponderá a la evaluación de ajuste al proceso, este informe debe ser distribuido a los responsables de las actividades además del administrador del proyecto y se debe asegurar de que son conscientes de desviaciones y discrepancias encontradas. Evaluar el proceso de acciones correctivas El proceso de acción correctiva cumplirá con los pasos para identificar el problema y la corrección realizada durante el desarrollo del software, reportar el problema a la autoridad apropiada, analizar el problema para proponer medidas de corrección, realizar la corrección oportuna y completamente y registrar y dar seguimiento a cada problema. Los problemas bajo este contexto incluyen errores de documentación, errores de software, no cumplimiento de estándares y procedimientos. Las actividades son las siguientes: 1. Revisar periódicamente el proceso de acción correctiva y sus resultados. 2. Realizar periódicamente correcciones basado en los diferentes resultados obtenidos en los informes. 3. Seguimiento de procesos. 4. Observaciones de auditorías internas y externas. 5. Observaciones de los informes y sugerencias del personal. 6. Quejas del cliente. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 13 de 39 Plan de SQA Como Resultado de este proceso se obtiene un Informe de revisión de SQA que corresponderá a la evaluación de ajuste al proceso, este informe debe ser distribuido a los responsables de las actividades además del administrador del proyecto y se debe asegurar de que son consientes de desviaciones y discrepancias encontradas. Evaluar la administración de la configuración La Administración de la configuración es la responsable de Identificar y documentar la funcionalidad y las características físicas de los ítems de configuración, documentar los cambios de control de los ítems de configuración, registrar y reportar la información necesaria para administrar los ítems de configuración efectivamente, incluyendo el status de los cambios propuestos y los status de implementación de cambios aprobados. Las actividades a realizar son las siguientes: 1. Verificar que la configuración de los ítems de configuración cumplen con los estándares establecidos de titulado, nomenclatura y descripción de los cambios. 2. Verificar que las líneas base ha sido establecida en el tiempo establecido por medio de los estándares y procedimientos 3. Verificar que todos los interesados en el proyecto tengan conocimiento del plan de SQA. 4. Verificar la creación de versiones para el cliente y los usuarios. 5. Verificar el manejo, aprobación y seguimiento de las peticiones de cambio. 6. Verificar las versiones que se pretenden que coexistan. Como Resultado de este proceso se obtiene un Informe de revisión de SQA que corresponderá a la evaluación de ajuste al proceso, este informe debe ser distribuido a los responsables de las actividades además del administrador del proyecto y se debe asegurar de que son conscientes de desviaciones y discrepancias encontradas. Realizar Revisión Técnica Formal (RTF) El objetivo de la RTF es descubrir errores en la función, la lógica ó la implementación de cualquier producto del software, verificar que satisface sus especificaciones, que se ajusta a los estándares establecidos, señalando las posibles desviaciones detectadas. Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Por esta característica se adopta esta práctica para productos que son de especial importancia. En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo. Se debe convocar a la reunión formalmente a los involucrados, informar del material que ellos deben preparar por adelantado, llevar una lista de preguntas y dudas que surgen del estudio del producto a ser revisado. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 14 de 39 Plan de SQA La duración de la reunión no debe ser mayor a dos horas. Como salida se obtiene el Informe de RTF. Asegurar que las desviaciones son documentadas Las desviaciones encontradas en las actividades y en los productos deben ser documentadas y manejadas de acuerdo a un procedimiento establecido. Se debe chequear que los responsables de cada plan los modifiquen cada vez que sea necesario, basados en las desviaciones encontradas. Relaciones entre las actividades de SQA y la planificación Relaciones entre las actividades de SQA y la planificación Actividad Semana Identificación de Propiedades de Calidad 1a5 Revisar la entrega 1 a 14 Elaboración del Plan de Calidad 2y4 Realizar Revisión Técnica Formal 5, 7, 9 y 11 Revisar el ajuste al proceso 3, 5, 7, 9, 11, 13, 14 Evaluación y ajuste del Plan de Calidad 9, 11 Evaluación final de Calidad 14 Responsables Matriz de responsabilidades: Actividades/ Responsables Admón. SQA Admón. proyecto Asegura miento calidad Desarrollo y diseño Pruebas Riesgos Admón. requerimi entos Realizar el plan de aseguramiento de la calidad Desarrollar y documentar el plan SQA X X Revisar plan SQA X X Aprobar plan SQA X X X X X X Revisión de productos de software Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 15 de 39 X Plan de SQA Revisión de los productos X X Aprobar el software X X X X X X X X X X X Evaluar las diferentes herramientas de software Evaluar las herramientas X Resolver recomendaci ones obtenidas por la auditoria X X X X X Planificación y seguimiento del proyecto Documentar el plan de desarrollo Revisar el plan X X X Aprobar el plan X Resolver recomendaci ones obtenidas por la auditoria X X X X Realizar el análisis de los requerimientos del software Documentar los rq X Rq de admón. configuración Revisar rq del sistema X X Aprobar los rq Evaluar el análisis de los rq Resolver recomendaci ones obtenidas por la auditoria X X X X X X X X X Proceso de diseño de software Documentar el diseño del software Calidad en el desarrollo de software ANYELO OBANDO ABRIL X X X Página 16 de 39 Plan de SQA Asegurar la calidad en el diseño X Revisar el diseño X Aprobar el diseño X Evaluar el proceso de diseño X X X Resolver recomendaci ones obtenidas por la auditoria X Implementación del software y pruebas unitarias Correcciones de código Asegurar la calidad en el código X X X Revisar el código Pruebas unitarias X Resolver recomendaci ones obtenidas por la auditoria X X X X X Proceso de entrega de productos finales Documentar entrega Revisar documentaci ón de entrega X X X Aprobar documento de entrega X Resolver recomendaci ones obtenidas por la auditoria X X Proceso de acciones correctivas Seguir proceso de X X Calidad en el desarrollo de software ANYELO OBANDO ABRIL X X X X Página 17 de 39 X Plan de SQA acciones correctivas Evaluar el proceso de acciones correctivas X Resolver recomendaci ones obtenidas por la auditoria X Realizar la administración a la configuración Documentar el plan de aseguramient o de calidad Revisar el plan X X X Aprobar el plan Realizar seguimiento al proceso X X X X X X X X X X X X X X Documentar procedimient os de calidad Evaluar el plan X X X X Resolver recomendaci ones obtenidas por la auditoria X Proceso de auditoría y revisión Realizar auditorias X Evaluar el proceso de auditoria X Resolver recomendaci ones obtenidas por la auditoria X X X Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 18 de 39 Plan de SQA Los responsables de llevar a cabo los controles de calidad serán los mismos encargados de SQA y el Asistente SQA. Luego de las revisiones de cada producto, se solicitará la atención del responsable del mismo para su corrección de las acciones tomadas. Para su corrección y comunicación de las acciones tomadas. Para la puesta en marcha de estas actividades se deberá seguir el siguiente ciclo de prevención: Ejecutar una tarea Realizar un control de revisiones, para decidir la aceptación o necesidad de corrección de dicha tarea. En caso de que en la revisión se presenten errores se realizara un análisis causal para determinar el motivo de estos. Se analiza un determinado error, se establece una hipótesis de su posible causa, se trata de deducir en qué momento se produjo y por qué. Luego se deberá realizar la corrección del mismo y tomar una acción correctiva con el fin de eliminar la causa del problema. El resultado del análisis causal es ingresado a una base de datos para mantener un registro y poder obtener métricas. Se comienza nuevamente el ciclo ejecutando la tarea. Documentación Propósito La documentación que describe el software y el desarrollo de software se creara y actualizara periódicamente en todo el ciclo de desarrollo del software. Los documentos mencionados en a la siguiente tabla deben estar bajo la administración de la configuración, enviando una petición al administrador del proyecto cuando se realicen cambios, para que este determine si el documento puede entrar a la línea base. Documentación mínima requerida La documentación mínima requerida para asegurar que la implementación lograra satisfacer los requerimientos. La documentación que describe el software y el proceso de desarrollo de software se creará y actualizará periódicamente en todo el ciclo de desarrollo del software. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 19 de 39 Plan de SQA Los documentos mencionados en la siguiente tabla deben de estar bajo la administración de la configuración, enviando una petición al administrador de aseguramiento de la calidad cuando se realicen cambios, para que este determine si el documento puede entrar a la línea base. Documento Descripción Especificación de requerimientos del software Describe los requisitos del sistema de información web para administrar la información de la clínica de salud, tanto funcional como no funcional. Plan SQA Describe los planes y roles que adoptara cada uno de los interesados en el desarrollo del sistema de información web para administrar la información de la clínica de salud. Plan de pruebas del software Describe los módulos a ser probados, así como las pruebas que se utilizaran, entradas y salidas esperadas para cada prueba. Administración de la configuración Describe la nomenclatura utilizada en el proyecto, así como la forma en que se determina la línea base. Plan de desarrollo del software Describe lo que se va a implementar, los calendarios, actividades y responsabilidades de los miembros del equipo de desarrollo. Especificación de requerimientos del software El documento de especificación de requerimientos deberá describir, de forma clara y precisa, cada uno de los requerimientos esenciales del software además de las interfaces externas. El cliente deberá obtener como resultado del proyecto una especificación adecuada a sus necesidades en el área de alcance del proyecto, de acuerdo al compromiso inicial del trabajo y a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos que se haya acordado detallar con el cliente. El documento de especificación de requerimientos deberá describir, de forma clara y precisa, cada uno de los requerimientos esenciales del software además de las interfaces externas. El cliente deberá obtener como resultado del proyecto una especificación adecuada a sus necesidades en el área de alcance del proyecto, de acuerdo al compromiso inicial del trabajo y a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos que se haya acordado detallar con el cliente. La especificación debe: Ser completa: a. Externa, respecto al alcance acordado. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 20 de 39 Plan de SQA b. Internamente, no deben existir elementos sin especificar. Ser consistente, no puede haber elementos contradictorios. Ser no ambigua, todo término referido al área de aplicación debe estar definido en un glosario. Ser verificable, debe ser posible verificar siguiendo un método definido, si el producto final cumple o no con cada requerimiento. Estar acompañada de un detalle de los procedimientos adecuados para verificar si el producto cumple o no con los requerimientos. Incluir requerimientos de calidad del producto a construir. 1. Funcionalidad: Asegurar que las personas saben utilizar las funciones del software para cumplir sus objetivos. 1.1. Adecuación a las necesidades: El producto a construir debe satisfacer la necesidad o problemática principal del cliente. Este aspecto debe darse en todos los componentes o partes que constituyan dicho producto. 1.2. Interoperabilidad: El sistema de información manejará una interoperabilidad con otros sistemas por lo que deberá utilizar y proponer interfaces conocidas. 1.3. Preciso: El sistema de información debe ser preciso en cuanto a los resultados esperados. 1.4. Seguridad: El sistema podrá proteger la información contenida en él, además de los datos que las personas o sistemas sin relación alguna puedan obtenerlos y modificarlos. 2. Confiabilidad: Esta sería la habilidad que tiene un sistema o componente de realizar sus funciones requeridas bajo condiciones especificas en periodos de tiempo determinados. 2.1. Tolerancia a fallos: El sistema de información para la clínica de salud debe responder de manera aceptable ante faltas en la programación. Este aspecto debe ser considerado en todos los componentes y partes del sistema. 2.2. Efectividad en sus tareas: el sistema de información deberá cumplir con las tareas que el usuario quiera realizar, cuando el así lo requiera. 3. Usabilidad: Este aspecto se refiere a la calidad de la experiencia que tiene un usuario cuando interactúa con un producto o sistema. 3.1. Comprensible: Desde el punto de vista interno, nos ayudará a lograr los aspectos de calidad la evolución y la verificación. Además, se debe tener especial atención en la interfaz del cliente. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 21 de 39 Plan de SQA 3.2. Operable: El sistema debe ser operable, es decir, las funciones que se especifiquen en el sistema deben funcionar de manera correcta para una mejor usabilidad por parte de los administradores de la clínica. 3.3. Asistencia: El sistema debe plantear la ayuda que se le entrega a los usuarios para apoyarlos cuando deban enfrentar los posibles errores que cometan al usar el sistema. 3.4. Encontrable: los Sitios Web deben ser navegables y permitir que los usuarios puedan encontrar lo que necesitan. 3.5. Creíble: la credibilidad es uno de los factores más importantes de tener en cuenta y por ello se deben revisar los elementos de diseño que afectan la confianza que nos tienen los usuarios. 3.6. Útil: es necesario preguntarnos si nuestros productos y sistemas son útiles, y aplicar nuestro conocimiento para definir soluciones innovadoras que apoyan la utilidad. 4. Mantenibilidad: Este aspecto de calidad es fundamental dado que nuestro producto de software debe ser capaz de que se le realicen modificaciones luego de su entrega para agregarle características que no estaban dentro del alcance del proyecto. Es por ello que se identifican los siguientes atributos que deben involucrarse dentro de la mantenibilidad del sistema: 4.1. Analizable: El software debe ser capas de ser diagnosticado di hay deficiencias o fallos e identificar las partes que deben ser cambiadas. 4.2. Modificable: El sistema de información al ser modificado, este no debe presentar alteraciones en la información y mucho menos en la funcionalidad. 4.3. Estable: El software deberá evitar efectos inesperados debido a modificaciones del software. 4.4. Verificable: El software debe ser valido al momento de realizársele pruebas. 4.5. Estabilidad: Evitar efectos inesperados debido a modificaciones del software. 5. Fiabilidad: Un aspecto en el cual es software debe tener la habilidad para mantenerse funcionando dentro de las condiciones normales. 5.1. Madurez: el sistema de información debe poder evitar fallos como resultado de fallos anteriores en el sistema. 5.2. Recuperable: El sistema de información debe ser capaz de restablecer el nivel de prestaciones especificados y de recuperar datos afectados en el fallo. Estos aspectos deben cuidarse y considerarse en cada uno de los componentes del producto software, prestando atención al código generado. Cada uno de estos atributos debe cumplir con las normas y regulaciones aplicables a cada uno. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 22 de 39 Plan de SQA Descripción del diseño del software El documento de diseño especifica como el software será construido para satisfacer los requerimientos del cliente. Deberá describir los componentes y subcomponentes del diseño del software, incluyendo interfaces internas. Este documento deberá ser elaborado primero como Preliminar y luego será gradualmente extendido hasta llegar a obtener el Detallado. El cliente deberá obtener como resultado del proyecto el diseño de un producto de software que cubra aquellos aspectos que se haya acordado con el cliente incorporar al diseño, en función de la importancia que estos presenten y de sus conexiones lógicas. El diseño debe: Corresponder a los requerimientos a incorporar: a. Todo elemento del diseño debe contribuir a algún requerimiento. b. La implementación de todo requerimiento a incorporar debe estar contemplada en por lo menos un elemento del diseño. c. Describir estructuras que residen dentro del software. d. Uso de características de flujos de información, relacionándolos en un mapeo dentro de la estructura del programa. Ser consistente con la calidad del producto Plan de Verificación & Validación El Plan de verificación y de validación deberá identificar y describir los métodos a ser utilizados en: La verificación de que: a. Los requerimientos descritos en el documento de requerimientos han sido aprobados por una autoridad apropiada. b. El diseño expresado en el documento de diseño esta implementado en código. c. El diseño expresado en el documento de diseño esta implementado en el código. Validar que el código, cuando es ejecutado, se adecua a los requerimientos expresados en el documento de requerimientos. Adicionalmente la validación es para demostrar que el producto lograr satisfacer su uso esperado cuando sea puesto en funcionamiento. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 23 de 39 Plan de SQA Reporte de verificación y validación Estos documentos deben especificar los resultados obtenidos de la ejecución de los procesos descritos en el plan de verificación y validación. Documentación de usuario La documentación de usuario debe especificar y describir los datos y entradas de control requeridos, así como la secuencia de entradas, opciones, limitaciones de programa y otros ítems necesarios para la ejecución exitosa del software. Todos los errores deben ser identificados y las acciones correctivas descritas. Un elemento muy importante de consulta para toda aquella persona que va a usar el programa por primero vez o que trata de saber si el programa servirá a sus objetivos. Igualmente es útil para usuarios que ya realizan un manejo básico y quieren profundizar hacia un conocimiento avanzado. Como resultado del proyecto el cliente obtendrá una documentación para el usuario de acuerdo a los requerimientos específicos del proyecto. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 24 de 39 Plan de SQA Plan de Gestión de configuración El objetivo del SQA en esta área es asegurar que se realizan las actividades de gestión de configuración establecidas en el Plan de Configuración y que se realizan tal como están establecidas en el proceso. El Plan de gestión de configuración debe contener métodos para identificar componentes de software, control e implementación de cambios, y registro y reporte del estado de los cambios implementados. La Gestión de Configuraciones permite controlar el sistema como producto global a lo largo de su creación, obtener informes sobre el estado de desarrollo en que se encuentra y reducir el número de errores durante el mismo, lo que se traduce en un aumento de calidad del proceso de desarrollo y de mejora de la productividad en la organización. La gestión de configuración facilita además el mantenimiento del sistema, aportando información precisa para valorar el impacto de los cambios solicitados y reduciendo el tiempo de implementación de un cambio, tanto evolutivo como correctivo. Propósito Controlar la entrega y el cambio de los elementos a través del ciclo de vida del sistema. Almacenar el estado de los elementos y de las peticiones de cambio. Establece y mantiene la integridad de los productos de software a través del ciclo de vida del proceso de software. Proporcionar además visibilidad sobre los procesos utilizados por el proyecto de software y sobre los productos que genera. Resumen La Gestión de Configuración, en resumen, identifica los elementos de un proyecto de desarrollo de software (especificaciones, requisitos, arquitecturas, código, planes, etc.) proporcionando el control de los elementos identificados y la generación de informes de estado de la configuración, consiguiendo, al mismo tiempo, claridad de gestión, al asignar responsabilidades al personal encargado de las tareas de control a lo largo del ciclo de vida del producto. Esto debido a que es uno de los procesos clave para toda la organización década a la ingeniería del software, posibilitando una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción. Organización, Responsabilidades Se designará a un integrante del grupo para la administración de gestión de versiones, el cual se encargará de administrar y dar los permisos en el gestor. Pudiendo cualquier integrante solicitarle al grupo algún cambio para que el mismo estudie su necesidad. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 25 de 39 Plan de SQA Como parte de las actividades del responsable de SQA se revisarán los productos que se consideren relevantes para la calidad del producto y del proceso. Herramientas, Entorno, e Infraestructura Se utilizará la herramienta de Gestión de Configuraciones (CGS) GitHub y TortoiseSVN. Este maneja ficheros y directorios a lo largo del ciclo de vida del proyecto. Los ficheros se almacenan en un repositorio central, recordando todos los cambios que se hayan realizado, permitiendo a los integrantes del grupo poder recuperar versiones anteriormente guardadas, examinar la historia de cuándo y cómo fueron modificados los datos, quien hizo los mismos y así poder coordinar el trabajo. Siendo la misma especialmente útil para los documentos revisados frecuentemente, como el código fuente, la documentación, etc., como así también llevar un balance histórico de las diferentes versiones del sistema. Forma de trabajo Durante el proceso de gestión de configuración se utilizará la herramienta GitHub para el control de versiones del producto. Cuando algún miembro haga una modificación en el proyecto, deberá acceder al repositorio en donde está alojada esta aplicación para realizar la incorporación de la parte modificada en la rama principal del proyecto, teniendo el resto del equipo de desarrollo la última versión actualizada al realizar la actualización del proyecto desde Git. Esta gestión de acceso al servidor para la actualización se hará mediante la herramienta Tortoise para los documentos y el GitHub de escritorio para el código fuente. Control de Cambios Se efectúa una solicitud de cambio utilizando el Formulario de Pedido y Detección de Cambio. Especifica los procedimientos para solicitar un cambio a una línea base y la documentación necesaria. El mismo contiene: 1. Nombre y versión del Elemento de Configuración de Software a cambiar. 2. Nombre del peticionario. 3. Fecha de petición 4. Necesidad del cambio 5. Descripción del cambio pedido 6. Prioridad 7. Estado 8. Fecha del cambio Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 26 de 39 Plan de SQA Esto deberá ser realizado gracias a los mecanismos para solicitar los cambios, para aprobar o rechazar las solicitudes de cambio, además de el seguimiento de los cambios además de gestión de problemas. Reportes y Auditorias Estas auditorías son para verificar la consistencia del código versus el documento de diseño, especificaciones de interfase, implementaciones de diseño versus requerimientos funcionales, requerimientos funcionales versus descripciones de testeo El personal de calidad reportara el resultado de las auditorias y las recomendaciones proporcionadas. Estos reportes se usan para asegurarse que el proceso: Auditoria Funcional: Cuyo objetivo es comprobar que se han completado todas las pruebas necesarias para el / los ECS auditados, y que, teniendo en cuenta los resultados de los test, se puede afirmar que el / los ECS satisfacen los requisitos que se impusieron sobre él. Revisión formal de certificación: Cuyo objetivo es certificar que el / los ECS se comportan correctamente en su entorno operativo. Otros documentos Plan del proyecto El plan de gestión de proyecto debe describir la planificación de forma completa del proyecto, de manera que pueda desarrollarse de forma controlada. Debe analizar su factibilidad, definir el alcance, describir las actividades de gestión que deben ser llevadas a cabo durante el proceso de desarrollo, definir mecanismos de control y ajuste para las distintas áreas del proyecto, establecer las líneas de trabajo, distribución de recursos humanos juntos con sus responsabilidades y cronograma de trabajo. Además, debe analizar los riesgos del proyecto con estrategias de mitigación, controles y planes de contingencia. Plan de desarrollo El plan de desarrollo debe describir la planificación de forma completa de la fase de desarrollo del Sistema de Software, describiendo las actividades que se realizaran, su duración y quienes son los responsables. Estándares, prácticas, convenciones y métricas Identificar los estándares, prácticas, convenciones y métricas que serán aplicadas. Indicar como será monitoreado y asegurado el cumplimiento con estos ítems: Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 27 de 39 Plan de SQA El IEEE “Standard Glosary of Software Engering Terms” define como métrica: “una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado”. Las métricas son una herramienta poderosa y fundamental para el trabajo en SQA. Su aporte fundamental son las medidas preventivas que pueden surgir a raíz de su estudio. Sin duda aportan conclusiones que muchas veces no se aprecian a simple vista y que ayudan a mejorar la eficiencia del grupo de trabajo y la calidad de los productos. Aportan un caudal de información para hacer controles estadísticos de la calidad. Además, cabe resaltar que nunca debe dejarse de buscar nuevas métricas de acuerdo a las nuevas variaciones y tendencias de las estadísticas. Objetivos Existen dos objetivos importantes que se persiguen dentro del programa de métricas: 1. Documentar las metas a la hora de establecer un programa de métricas. Esto tiene sentido a la hora de decidir exactamente qué debe lograrse antes de gastar recursos estableciendo un programa de este tipo. 2. Identificar la información (la métrica) necesaria para lograr estas metas y establecer el marco de referencia de donde puede ser obtenida. 3. Medir la calidad de análisis y modelos de desafío, el código fuente y los casos de prueba que se han creado al aplicar la ingeniería del software. 4. Identificar y medir los errores y defectos. Estas medidas proporcionan una indicación de la efectividad de las actividades de control y de la garantía de calidad. El cometido de los ocho pasos es crear un proceso a través del cual un programa corriente de métrica puede ser utilizado como una herramienta estratégica de gestión. Métricas de proceso Se recopilan de todos los proyectos y durante un largo periodo de tiempo Caracterizados por: Control y ejecución del proyecto. Medición de tiempos de las fases. Para este proyecto se trabajará con las siguientes métricas del proceso: Costo de remoción de defectos Cantidad de código rehusado Distribución de esfuerzo por fase Efectividad para remover defectos entre fases Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 28 de 39 Plan de SQA Soporte de herramientas para procesos propuestos Métricas de proyecto Permiten evaluar el estado del proyecto. Permiten seguir la pista de los riesgos. Para este proyecto se trabajará con las siguientes métricas del proyecto: Cantidad de puntos de función liberados por unidad de tiempo Costo del desarrollo Costo del soporte Horas trabajadas Tiempo (calendario) transcurrido Distribución del esfuerzo por fase Cambios sobre requerimientos durante el desarrollo Cambio sobre requerimientos en operación Origen de los cambios sobre requerimientos Cronograma Vs Estimado Costo sobre valor agregado Porcentaje de requerimientos implementados por unidad de tiempo Las métricas del proyecto permiten que un gestor del proyecto de software: Valore los riesgos de un proyecto en curso Rastree los riesgos potenciales Descubra las áreas problema Ajuste el flujo de trabajo o las tareas Evalué la habilidad del equipo del proyecto para controlar la calidad de los productos de software. Métricas de producto Se centran en las características del software y no en cómo fue producido. También son productos los artefactos, documentos, modelos, y componentes que conforman el software. Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad, y el esfuerzo Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 29 de 39 Plan de SQA Para este proyecto se trabajará con las siguientes métricas del producto: Puntos de Caso de Uso Puntos de función Complejidad de diseño (acoplamiento) Complejidad de código Métodos por clase Profundidad y ancho de jerarquías Cantidad de objetos y cantidad de relaciones de colaboración diferentes Volatibilidad de componentes Complejidad de despliegue Densidad de defectos Tipo y origen de defectos Cantidad de problemas reportados Tiempo transcurrido entre fallas Tiempo esperado para la siguiente falla Tiempo requerido para reparar SLOC Facilidad de aprendizaje de uso Estándar de documentación Como estándares de documentación se definirán dos documentos: Estándar de documentación técnica Estándar de documentación de usuario. La documentación técnica del producto debe: Ser adecuada para que un grupo independiente del de desarrollo pueda encarar el mantenimiento del producto. Incluir fuentes, Modelos de Casos de Uso, Objetos de diseño. Para la escritura de documentos se han definido plantillas para ser utilizadas en la elaboración de entregables. En estas plantillas se definen: Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 30 de 39 Plan de SQA Encabezado y pie de página. Fuente y tamaño de fuente para estilo normal. Fuente y tamaño de fuente para los títulos a utilizar. Datos mínimos que se deben incluir: fecha, versión y responsables. Estándar de verificación y prácticas Se utilizarán las prácticas definidas en el documento correspondiente al plan de verificación y validación especificado anteriormente. Como estándar se utiliza el documento de: Std 1012-1986 IEEE Standard for Software Verification and Validation Plans. Otros Estándares Estándar de documentación en general Para la elaboración del documento se han definido plantillas para todos los documentos a realizar. En ellos se definen: Fuente: Calibri - Tamaño: 11 - Color: Negro - Estilos: Normal, Titulo1, Titulo2, Titulo3, Titulo4 hasta el nivel que sea necesario. Cada documento debe contar con una carátula al principio que debe contener: a. Título explicativo del contenido del documento. b. Versión del Documento. c. Historial de versiones, que incluye el número de versión, la fecha, Asunto de la modificación, Responsable que la realizó. Se observa, que la versión del documento debe coincidir con el último campo de esta tabla. Índice del contenido del documento y por consiguiente todas las páginas deben estar numeradas. Es deseable, que incluya al comienzo cual es el objetivo del documento. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 31 de 39 Plan de SQA Estándar de documentación en técnica Por documentación Técnica se entiende Modelo de Dominio, Diagrama de Casos de Uso, Diagramas de Sistema en general. En el documento "Estándar de documentación Técnica" se define el programa de software a utilizar y algunas convenciones. Estándar de implementación Como ya hemos mencionado, el producto de software a construir se utilizará como prueba de concepto por parte del cliente, y es de gran importancia su mantenibilidad, compresión, evolución, y aprendizaje. Es por ello, que debemos seguir las recomendaciones de implementación que el Cliente utiliza, para lograr cumplir con estos atributos de calidad. Otro factor de Calidad relevante, como ya mencionamos, es la interoperabilidad, por lo que tal documento define las convenciones necesarias para realizar de forma correcta la comunicación con el Sistema. Las convenciones de implementación se definen en el documento "Estándar de Implementación" y se solicita especial atención del mismo por parte del equipo de desarrolladores. Revisiones y auditorías Objetivo Definición de las revisiones y auditorías técnicas y de gestión que se realizarán, especificando cómo se llevarán a cabo dichas revisiones y auditorías. Requerimientos mínimos Como mínimo deberán revisarse todas las entregas semanales, basado en los estándares definidos anteriormente. Estas revisiones serán realizadas por el responsable del plan SQA y/o el asistente del plan. Se especifican las revisiones y auditorías que deben realizarse como mínimo, así como la agenda para la realización de las mismas, especificación de requerimientos, modelo de diseño y descripción de la arquitectura, plan de verificación y validación, plan de gestión del proyecto, plan de gestión de configuración, diseño vs. Especificación de requerimientos, implementación vs. Diseño, verificación vs. Especificación de requerimientos. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 32 de 39 Plan de SQA Revisión de requerimientos Esta revisión se realiza para asegurar que se ha cumplido con los requerimientos especificados por el Cliente. Revisión de diseño preliminar Esta revisión se realiza para asegurar la consistencia y suficiencia técnica del diseño preliminar del software. Revisión de diseño crítico Esta revisión se realiza para asegurar la consistencia del diseño detallado con la especificación de requerimientos. Revisión del plan de verificación & validación Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados en el plan. Auditoría funcional Esta auditoría se realiza previa a la liberación del software, para verificar que todos los requerimientos especificados en el documento de requerimientos fueron cumplidos. Auditoría física Esta revisión se realiza para verificar que el software y la documentación son consistentes y están aptos para la liberación. Auditorías internas al proceso Estas auditorías sirven para verificar la consistencia: del código versus el documento de diseño, especificaciones de interfase, implementaciones de diseño versus requerimientos funcionales, requerimientos funcionales versus descripciones de testeo. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 33 de 39 Plan de SQA Revisiones de gestión Estas revisiones se realizan periódicamente para asegurar la ejecución de todas las actitudes identificadas en este Plan. Deben realizarse por una persona ajena al grupo de trabajo (en caso de que sea posible). Revisión del Plan de gestión de configuración Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados en el Plan de gestión de configuración. Revisión Post Mortem Esta revisión se realiza al concluir el proyecto para especificar las actividades de desarrollo implementadas durante el proyecto y para proveer recomendaciones. Agenda En esta sección se especifica la agenda para las revisiones y auditorías detalladas correspondientes al proyecto del sistema de información web para la administración de la información de la clínica de salud de la ciudad de Bogotá. El calendario está sujeto a cambios que puedan originarse por desviaciones en el proyecto como se explico anteriormente. Además, se observa que para la fase de construcción de productos de investigación todavía no esta determinado, dado que aun se determino el mecanismo que se seguirá durante la investigación. Fase Iteración Semana Actividad Producto 2 1 8 Revisión RTF Arquitectura Revisión Producto Plan de Proyecto Revisión Producto Revisión plan de gestión de la configuración Elaboración plan de aseguramiento de calidad Calidad en el desarrollo de software ANYELO OBANDO ABRIL Descripción de la Arquitectura Plan de la gestión de la Configuración Plan aseguramiento de la calidad del software Página 34 de 39 Plan de SQA Revisión de requerimientos Documentación levantamiento de requerimientos Plan SQA Revisión de gestión 9 Servicios Avanzados Interfaz de Usuario Revisión RTF Revisión de diseño preliminar Revisión del diseño crítico Revisión de Pruebas Interfaz de Usuario Salida: Informe de Revisión de Pruebas. Evaluar y Ajustar el Plan de Calidad Plan de aseguramiento de la calidad Plan SQA Revisión de gestión 3 1 10 Revisión Producto Revisión plan de gestión de la configuración Revisión Producto Revisión de Pruebas Revisión de gestión 11 Revisión de Pruebas Revisión RTF Revisión de Proceso Revisión Productos 2 12 Manejo del Ambiente Controlado Salida: Informe de Revisión de Pruebas. Plan SQA Salida: Informe de Revisión de Pruebas. Servicios Avanzados Carga Masiva Líneas de Investigación Revisión RTF Interfaz de usuario Revisión de gestión Plan SQA Revisión Productos Líneas de Investigación Revisión de Pruebas Salida: Informe de Revisión de Pruebas. Revisión de Proceso Revisión Producto Calidad en el desarrollo de software ANYELO OBANDO ABRIL Descripción de la Arquitectura Plan de la gestión de la Configuración Carga Masiva Modelo de Casos de Uso Página 35 de 39 Plan de SQA Revisión de gestión Auditoría interna al proceso Auditoria Funcional 13 Revisión de Proceso Revisión de Proceso Revisión de Proceso Revisión Productos Auditoria física 4 1 14 Plan SQA Sistema de información web, documentación y requerimientos funcionales y no funcionales Sistema de información web, requerimientos funcionales y no funcionales Atributos de calidad del sistema de información web Carga Masiva Ambiente modular del sistema de información web Líneas de Investigación Producto software y documentación Revisión Post Mortem Otras revisiones Revisión de documentación de usuario Esta revisión se verifica que la documentación de usuario se encuentre en un nivel de completitud, claridad y aplicación de uso. Aceptable para que, al momento de realizar la entrega de esta a los usuarios finales como los administradores de la clínica, se maneje un estándar universal para los conceptos entre los desarrolladores y le cliente final. Unificando los conceptos que puedan ser mal interpretados por los usuarios, evitando que el mal entendimiento de la documentación técnica y general del proyecto. Revisiones técnicas formales RTF Esta revisión tendrá por objetivo estudiar el desempeño de las pruebas realizadas para así obtener de esa manera una noción de la correctitud del Sistema en base a los errores detectados en las pruebas de una versión anterior. Mecanismo: Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Por esta característica se adopta esta práctica para productos que son de especial importancia. En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 36 de 39 Plan de SQA Se debe convocar a la reunión formalmente a los involucrados, informar del material que ellos deben preparar por adelantado, llevar una lista de preguntas y dudas que surgen del estudio del producto a ser revisado. Como salida se obtiene el Informe de RTF. Verificación La verificación se hará conforme a lo expresado en el documento "Plan de Verificación y Validación", sin embargo, este punto puede seguir modificaciones luego de las revisiones agendadas para la próxima semana. Reporte de problemas y acciones correctivas Luego de tener el Informe de la Revisión se solicitará, mediante el envío de un mail, la atención de los responsables sobre el documento. Además, se les solicitará que comuniquen las discrepancias encontradas en el informe tanto como las correcciones hechas en el producto. Luego, se planifica una nueva revisión para corroborar las acciones correctivas hechas por los responsables del producto. Ante la detección de un error en la documentación se informará a él o los responsables de dicho documento para que sea corregido. Esto se hará mediante el uso del grupo del proyecto. En caso de que el error se repita reiteradas veces se tratara el tema en alguna reunión de grupo, ya sea ordinaria o, en caso que la situación lo amerite, en una reunión extraordinaria. Herramientas, técnicas y metodologías Las técnicas a utilizar se definieron en el punto 3, además se utilizará listas de comprobación como apoyo a estas técnicas. Dichas listas se realizarán para cada revisión y se tomarán como base las definidas en el curso. Utilidades del sistema operativo, documentos de ayuda, checklist, analizadores de estructuras, analizadores de código, auditorias de estándares, monitoreo de rendimiento, software de desarrollo, matrices de seguimiento de software, pruebas de generadores de casos. Como lenguajes de programación: JAVA, HTML, CSS, J2EE. Herramientas de diagramas UML: StartUML, DB Designer Herramientas de bases de datos: MYSQL, Postgres o php myadmin. Herramientas de Casos de Uso: StartUML, lucidchart. Herramienta de procesamiento de texto: Microsoft Word Herramientas de apoyo: Internet, Excel, Photoshop. Herramientas de desarrollo: Netbeans, Dreamweaver, sublime text. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 37 de 39 Plan de SQA Gestión de riesgos Los riesgos identificados, la estrategia de mitigación, monitoreo y plan de contingencia a ser llevados a cabo, están definidos en el documento de "Gestión de Riesgos", con lo cual se podrá hacer referencia a él. Política de calidad Consideramos que el producto esta en un nivel aceptable de calidad si se cumplen el cien por ciento de los atributos de calidad identificados en la pagina 20: “Especificación de requisitos de software”. Utilizando las métricas definidas en la pagina 27: “Estándares, practicas, convenciones y métricas”, de forma tal de medir dichosos atributos, para así tener una noción general de calidad del producto y consecuentemente solicitar las acciones definidas en la pagina 33: “revisiones y auditorias”, según el cronograma definido en la pagina 34: “Agenda”. Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 38 de 39 Plan de SQA Anexos Formulario de Pedidos y Detección de Cambios Formulario de Pedidos y Detección de Cambios Fecha de Petición: Nombre y Elemento Versión del Nombre del Solicitante: Necesidad de Cambio: Descripción pedido: del cambio Prioridad: Estado: Alta: Normal: Baja: Muy Baja: Fecha del cambio: Identificador versión: de la nueva Que fue afectado por este cambio Calidad en el desarrollo de software ANYELO OBANDO ABRIL Página 39 de 39
