e Equation Chapter 1 Section 1
Trabajo Fin de Grado
Grado en Ingeniería de las Tecnologías de
Telecomunicación
Proceso de Calidad en Ingeniería del Software
Autor: Antonio Marco Rodrigo Jiménez
Tutora: Isabel Román Martínez
Dpto. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
Trabajo Fin de Grado
G.I.T.T.
Proceso de Calidad en Ingeniería del Software
Autor:
Antonio Marco Rodrigo Jiménez
Tutora:
Isabel Román Martínez
Profesora colaboradora
Dpto. de Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
Trabajo Fin de Grado: Proceso de Calidad en Ingeniería del Software
Autor: Antonio Marco Rodrigo Jiménez
Tutora: Isabel Román Martínez
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2018
El Secretario del Tribunal
Agradecimientos
A Antonio Luna, Cata, Dylan, Kico, Javi, Lourdes y el Señor de IT
Resumen
Este proyecto tiene como objetivo realizar un estudio teórico de un proceso de calidad en el ámbito del
desarrollo software. Se describirán todas las partes de un modelo software en cascada, destacando el papel y la intervención del departamento de calidad en las diferentes secciones.
Se ha elegido un modelo en cascada porque es el modelo software que se utiliza en ciertos proyectos dentro de
everis. La labor en dichos proyectos consiste en formar parte de la OAC (Oficina del Aseguramiento de la
Calidad), que realiza revisiones técnicas a los proyectos software para el cliente: CAPDER (Consejería de Agricultura, Pesca y Desarrollo Rural), de la Junta de Andalucía.
En este proyecto se explicarán todas las posibles situaciones y casos dentro del ámbito del desarrollo software,
y se detallará cómo actúa la OAC en cada una de ellas. No obstante, se desarrollarán con más detalle aquellas situaciones y casos que coincidan con las funciones directas de un técnico de calidad.
Abstract
The main purpose of this project is to elaborate a theoretical essay about a quality process, regarding software
development. Every part of a cascade software model will be described, focusing on the role and tasks of the
quality department through the different sections.
A cascade software model has been chosen because it is the software model used in some project inside everis. The main task in such projects consisted on being part of the QAD (Quality Assurance Department), which
performs technical reviews to CAPDER software projects (Consejería de Agricultura, Pesca y Desarrollo
Rural), from the Junta de Andalucía.
In this project, all possible situations will be taken into account regarding software development, and the main
purpose of the QAD will be detailed in each. However, those situations related to being a quality technician
will be furtherly developed in detail.
Índice
Agradecimientos 9
Resumen 11
Abstract 13
Índice 14
Índice de Tablas 17
Índice de Figuras 20
1 Descripción general del sistema 1 1.1 Modelo 1 1.2 Definición de entidades 2
1.2.1 Calidad / OAC (Oficina del Aseguramiento de la Calidad) 2 1.2.2 Cliente 2 1.2.3 Equipo de Desarrollo 3 1.2.4 Despliegue 4 1.2.5 DP (Dirección de Proyecto) 4 1.2.6 JP (Jefe de Proyecto) 4 1.2.7 Comité de seguimiento 4
1.3 Interacción entre entidades 5 1.4 Definición de Entornos 7 1.5 Diagrama de flujo del proceso software 8 1.6 Detalle Del Proceso 9
2 Descripción específica del sistema 11 2.1 Introducción 11 2.2 Comienzo Del Proyecto 11
2.2.1 Análisis de la Realidad 11 2.2.2 Adjudicación 14
2.3 Definición Del Proyecto 27 2.4 Diseño Del Proyecto 31
2.4.1 DAO (Diseño de Arquitectura Orientado a Objetos) 31 2.5 Codificación Del Proyecto 35
2.5.1 Preparación Del Entorno de Construcción 36 2.5.2 Generación de Código 36
2.5.3 MIC (Manual básico de Instalación y Configuración) 36 2.5.4 MUS (Manual de Usuario) 38 2.5.5 Elaboración del PP (Plan de Pruebas) 40
2.6 Control de Calidad 44 2.6.1 Pruebas 45 2.6.2 Incidencias 50 2.6.3 Informes de Revisión Técnica (IRT) 64 2.6.4 Informes de Calidad 66
2.7 Pruebas de Usuario 72 2.7.1 Pruebas Alfa 72 2.7.2 Pruebas Beta 72
2.8 Despliegue 73 2.9 Finalización Del Proyecto 76
2.9.1 Mantenimiento 76 2.9.2 Histórico de Proyecto 77 2.9.3 Informe de Fin de Proyecto 78 2.9.4 Cierre 79
3 Herramientas CASE 80 3.1 Herramientas CASE para la ingeniería de requisitos 80 3.2 Herramientas CASE para el diseño 80 3.3 Herramientas CASE para la codificación 81 3.4 Herramientas CASE para el aseguramiento de la calidad 81
3.4.1 JIRA 81 3.4.2 QM 82 3.4.3 Mantis 83 3.4.4 TOAD Oracle 83 3.4.5 Jenkins y Sonarqube 84 3.4.6 SoapUI 84 3.4.7 KeePass 85 3.4.8 Notepad++ 85 3.4.9 DiffPDF 85 3.4.10 VirtualBox 85
4 Conclusiones 86
Referencias 87
Glosario 90
Índice de Tablas 16
ÍNDICE DE TABLAS
Tabla 1. Modelo en Cascada 1
Tabla 2. Entornos 7
Tabla 3. Extracto de cuestionario de satisfacción del usuario con el software que utiliza 12
Tabla 4. Contenidos típicos de un Pliego de prescripciones técnicas 16
Tabla 5. Contenidos típicos de una Oferta 21
Tabla 6. Entregables de un Proyecto Software 22
Tabla 7. Matriz de Evaluación de Alternativas 25
Tabla 8. Tipos de Requisitos 28
Tabla 9. Estructura de un DAO 32
Tabla 10. Tareas DSI y CSI de Desarrollo 35
Tabla 11. Estructura de un MIC 36
Tabla 12. Estructura de un MUS 38
Tabla 13. Estructura del PP 40
Tabla 14. Estructura de un PPF 41
Tabla 15. Estructura de un Caso de Prueba 42
Tabla 16. Ejemplo de Caso de Prueba 42
Tabla 17. Tipos de Pruebas 48
Tabla 18. Tipos de Incidencias según su gravedad 50
Tabla 19. Certificación DDR 51
Tabla 20. Certificación DAO 52
Tabla 21. Certificación MIC 53
Tabla 22. Certificación MUS 54
Tabla 23. Certificación PP 55
Tabla 24. Defectos genéricos en documentos 56
Tabla 25. Certificación SCR de base de datos 58
Tabla 26. Certificación SFW 59
Índice de Tablas 18
Tabla 27. Defectos genéricos en código 61
Tabla 28. Resultado de evaluación de un entregable 64
Tabla 29. Estructura de un IPC 68
Tabla 30. Lista final de entregables 70
Tabla 31. Tareas de Despliegue 74
ÍNDICE DE FIGURAS
Figura 1. Diagrama de flujo del proceso software 8
Figura 2. Diagrama de Flujo Concurso Público 15
Figura 3. Ejemplo de Pliego 17
Figura 4. Diagrama de Flujo Evaluación de Oportunidad 19
Figura 5. Esquema Evaluación Oportunidad 20
Figura 6. Ejemplo de Diagrama WBS 24
Figura 7. Ejemplo de Matriz de Trazabilidad 29
Figura 8. Ejemplo de Informe de Fin de Proyecto 78
1
1 DESCRIPCIÓN GENERAL DEL SISTEMA
1.1 Modelo
ara el proceso software que vamos a explicar en este TFG, hemos elegido un modelo en cascada, que es el que se usa en mis prácticas de empresa.
El modelo en cascada (basándonos en la publicación de Winston Royce, 19701), se caracteriza por
seguir un orden secuencial en las tareas del desarrollo software, no se empieza una tarea hasta que no se acaba la anterior. De esta manera, primero se realizará el análisis y definición de requisitos, seguida del
diseño, codificación, pruebas y despliegue. Este modelo presenta una serie de ventajas e inconvenientes
sobre el resto de modelos, las cuales presentamos a continuación:
Tabla 1. Modelo en Cascada
MODELO EN CASCADA
VENTAJAS INCONVENIENTES
Planificación óptima de tiempo y dinero Es muy complicado introducir cambios en cualquier etapa
Alto nivel de satisfacción del cliente
Todos los requisitos deben quedar recogidos al inicio,
impidiendo la definición de nuevos requisitos durante el
desarrollo del proyecto
Permite suplir pérdidas en el equipo de desarrollo
con bastante facilidad
Las pruebas se realizan muy tarde, provocando que los
errores tarden en identificarse y corregirse
Todos los aspectos del proyecto están bien claros
y definidos desde el principio Si hay problemas, tendrán un alto coste en tiempo y dinero
Es un modelo fácilmente comprensible e
implementable La creación del software tarda mucho tiempo
Permite que lo realice un equipo con poca
experiencia en el desarrollo software debido a su
simplicidad
Las etapas necesitan esperar a que acabe la anterior
Estas características del modelo en cascada hacen que sea especialmente efectivo en proyectos estáticos, bien definidos desde el principio en los que sea muy poco probable la introducción de cambios durante el
desarrollo del software (En adelante SFW). Se beneficiarán de este modelo empresas que:
1) Cuenten con un gran capital, que se puedan permitir el coste en tiempo y dinero ante la aparición de problemas y errores. A costa de este gasto, garantizarán la satisfacción del cliente,
aumentando las posibilidades de trabajar juntos en el futuro.
2) Tengan una plantilla extensa y renovable, la cual dará lugar a equipos humanos poco
experimentados. El modelo en cascada es el más fácil para dichos equipos.
En resumen, este TFG propondrá un modelo de proceso software idóneo para grandes empresas que
contraten nuevos empleados regularmente, especializada en proyectos estáticos bien definidos al inicio.
1 ‘Managing the Development of Large Software Systems’, Winston Royce, 1970, creador del modelo de desarrollo software en cascada, m{s
tarde avalado por las publicaciones: ‘Software Engineering Economics’, Barry Boehm, 1981 y ‘Software Engineering’, Ian Sommerville, 1985
P
Descripción general del sistema
2
1.2 Definición de entidades
A continuación vamos a detallar las diferentes entidades, personas, o grupos de personas que van a
participar en el proceso software, y en el proceso de calidad. Definiremos quién forma cada entidad, qué
función tiene dentro del proceso software y cómo se relacionan entre ellas. Realizaremos dicha definición de entidades basándonos en el estándar MÉTRICA v.3.
MÉTRICA es un estándar de desarrollo software, realizado por el Gobierno de España, cuya última
versión (versión 3) se publicó en 2001. Durante mis prácticas de empresa se utilizaba como referencia
este estándar (en adelante MÉTRICA V.3) y es el que utiliza el SAC (Sistema de Aseguramiento de la Calidad) dentro del departamento de calidad como guía y normativa.
MÉTRICA v.3 está basada en los estándares internacionales: ISO/IEC 12207 (Information Technology -
Software Life Cycle Processes) y ISO/IEC 15504 SPICE (Software Process Improvement and Assurance Standards Capability Determination)
2.
1.2.1 Calidad / OAC (Oficina del Aseguramiento de la Calidad)
El departamento de calidad o OAC tiene como misión garantizar la calidad del producto software como
tal, asociado a un proyecto de desarrollo, encargándose de la ejecución de las pruebas tanto funcionales
como técnicas, detección de incidencias tanto de los documentos como del software generados por el
resto de entidades y elaboración de informes con el resultado de las pruebas llevadas a cabo.
También es el órgano encargado de la supervisión y de la evaluación de los proyectos, del cumplimiento
de la metodología definida. Participa en la revisión de los productos seleccionados para determinar si son
conformes o no a los procedimientos, normas o criterios especificados, comprobando que se han llevado a cabo las medidas preventivas o correctoras necesarias. Durante todas las etapas del proceso software, la
OAC realizará el número de revisiones técnicas necesario hasta que el entregable en cuestión supere
dichas revisiones satisfactoriamente.
La OAC también será aquella figura encargada de la validación de los modelos de datos conceptual, lógico y físico, generados durante el análisis y diseño del software, en cuanto a nomenclatura,
normalización, rendimiento, etc.
El departamento de calidad será la sección a la que prestaremos especial atención en este documento, en la que profundizaremos en la sección 2.6 Control de Calidad.
1.2.2 Cliente
El cliente es aquella persona, física o jurídica, que comienza el proceso software. El cliente es aquel que,
tras un análisis de la realidad de su entorno, encuentra una carencia, problema, o posible mejora de su sistema o entorno. Dividiremos al cliente en 2 tipos:
Persona física: Cliente formado por una única persona, la cual realizará el análisis de realidad de
su entorno, y decidirá si necesita o no ayuda externa para llevar a cabo la tarea a realizar.
Persona jurídica: Cliente consistente en una empresa, organismo o asociación.
o Empresas que no recurren a un concurso: Este cliente buscará soluciones por su
cuenta a los problemas o carencias analizados, o buscará ayuda de un tercero específicamente seleccionado, ya sea una ayuda gratuita personalizada, o la venta de un
servicio.
o Empresas que recurren a un concurso: Este cliente es en el que nos centraremos en este documento. Consiste en una empresa, organismo o asociación, que para solucionar
los problemas analizados, publica un pliego de prescripciones técnicas, y, a través de un
2 A falta de disposición a texto completo de las normas ISO mencionadas, utilizaremos como referencia la norma UNE 71044 – 1999
(AENOR), equivalente a la norma ISO/IEC 12207:1995.
3
3 Proceso de Calidad en Ingeniería del Software
concurso, otras empresas, organismos o asociaciones presentarán sus ofertas para cubrir
lo mejor posible las necesidades del cliente al precio más razonable. El cliente elegirá
qué empresa llevará a cabo su proyecto basándose en la reputación, confianza,
efectividad y presupuesto.
La empresa cliente designará a un RAU (Responsable del Área Usuaria), que será el interlocutor
representativo de la empresa cliente durante todo el proceso software en adelante. Toda comunicación
entre las diferentes entidades con el cliente se gestionará a través del RAU.
El RAU se encargará de realizar y/o gestionar la realización de las pruebas alfa y beta del software una
vez esté codificado por el equipo de desarrollo y revisado y probado por el departamento de calidad. Las
pruebas alfa las realizará en el entorno de certificación, sin que sea necesario el despliegue final de la aplicación. Las pruebas beta las realizará una vez la aplicación ya haya sido desplegada por el equipo de
despliegue, en su propio entorno de cliente. En ambas pruebas, comunicará al departamento de calidad las
incidencias o problemas que encuentre, para que éste las revise y, a su vez, dé parte al equipo
correspondiente para que las corrija.
1.2.3 Equipo de Desarrollo
Figura encargada del desarrollo del software, en todo su alcance, desde su inicio hasta su mantenimiento. Es el encargado de analizar las necesidades del software, modelarlo, diseñarlo y construirlo, realizando
los planes de pruebas necesarios para generar productos de calidad que satisfagan las necesidades
planteadas inicialmente. Es el encargado de elaborar la documentación asociada al proceso de desarrollo y de revisarla y actualizarla, si fuese necesario.
Está formado por dos entidades bien diferenciadas:
1.2.3.1 Diseño
El equipo de diseño es la entidad encargada de elaborar el documento de diseño del software. Este equipo
analizará los requisitos exigidos por el cliente, para encontrar la manera óptima de organizar y codificar el
software, y que éste cumpla dichos requisitos de la manera más eficiente posible.
El documento que elabore el equipo de diseño deberá ser sometido a una revisión técnica por el
departamento de calidad. A medida que el departamento de calidad revise los documentos de diseño y
encuentre incidencias, el equipo de diseño deberá ir corrigiéndolas, reelaborando el documento si es necesario y reentregarlo al departamento de calidad para que lo revise de nuevo.
Una vez revisado, el documento de diseño se entregará al equipo de codificación para que codifique el
software siguiendo sus pautas.
1.2.3.2 Codificación
El equipo de codificación será la entidad que codifique el software creando así la aplicación deseada por el cliente, o actualizando y mejorando una entrega anterior. Utilizará la arquitectura establecida por el
equipo de diseño, y seguirá todas las pautas del documento de diseño elaborado por dicho equipo para
organizar y codificar el software.
Este equipo elaborará los ficheros de software, scripts si se necesitaran, el documento de plan de pruebas y los documentos de manual de usuario y manual de instalación, que deberán ser revisados por el
departamento de calidad.
A medida que el departamento de calidad pruebe el software y detecte las incidencias en éste, o en los documentos elaborados, el equipo de codificación tendrá que ir corrigiendo dichas incidencias, reelaborar
el software y/o los documentos si es necesario, y reentregarlos al departamento de calidad para que revise
de nuevo.
Descripción general del sistema
4
1.2.4 Despliegue
El equipo de despliegue sera el encargado de la creación de los distintos entornos (definidos en la sección 1.4 Definición de entornos) donde se llevarán a cabo las tareas del proceso software. Si ya estaban
creados con anterioridad, este equipo se encargará de actualizarlos para el proyecto software actual y
prepararlos para operar en ellos.
Por otro lado, este equipo es la entidad que desplegará la aplicación en el entorno de certificación una vez codificada para que la OAC la pruebe, y en el entorno de cliente una vez ha sido totalmente revisada y
probada por el departamento de calidad, y el cliente haya realizado las pruebas alfa en el entorno de
certificación. Esto engloba el conjunto de acciones necesarias para que la aplicación sea accesible, se conecte con todos los subsistemas que necesite y tenga acceso a todos sus datos y registros, entre otras
tareas.
La OAC revisará el despliegue del software y llevará a cabo una segunda ejecución de las pruebas de
sistema y de las pruebas de despliegue cuando el equipo de despliegue implante la aplicación en el entorno de cliente. Si la OAC detecta incidencias durante las pruebas de sistema o despliegue, se las
comunicará al equipo de despliegue para que las corrija y vuelva a implantar el software en el entorno de
cliente, repitiéndose el proceso tantas veces como sea necesario hasta que las pruebas de sistema y despliegue no generen ningún error.
1.2.5 DP (Dirección de Proyecto)
Figura encargada de la gestión y supervisión del proyecto objeto de desarrollo, siendo el interlocutor representativo del proyecto de cara al resto de áreas. El Director de Proyecto tendrá como misión
supervisar la realización de los entregables, dando soporte al equipo de desarrollo en su elaboración y
realizar la revisión técnica de los entregables, en los casos que proceda, junto con la OAC.
Tiene como funciones comunicarse o reunirse con el RAU para elaborar una planificación temporal y
presupuestaria, definir los objetivos que necesita que se cubran, y llevar el seguimiento del proyecto a
través de todas sus etapas en todo momento.
El RAU y una representación de los usuarios finales del cliente facilitarán las pautas para que DP elabore
el documento DDR (Definición Detallada de Requisitos), que será revisado por el departamento de
calidad.
1.2.6 JP (Jefe de Proyecto)
Responsable del Equipo de Desarrollo, y por tanto, responsable de todas las entregas que este deban
realizar. JP pertenece al Equipo de Desarrollo y será el interlocutor representativo de los equipos de diseño y codificación.
1.2.7 Comité de seguimiento3
Esta figura se encarga de realizar el seguimiento del proyecto, contribuye en la definición del proyecto y
emprende las acciones correctoras que se estimen oportunas, para obtener productos que se adecuen a las
necesidades de la organización. El Comité de Seguimiento se encargará de seguir la evolución del proyecto y participar en su definición, y marcar las pautas técnicas de desarrollo (normativas, entornos…).
El comité de seguimiento velará por la entrega eficaz y a tiempo de todos los entregables que conforman
el proyecto, y controlará a los equipos de diseño, codificación, calidad, y despliegue.
Según el alcance del proyecto, el comité de seguimiento estará típicamente formado por DP, JP y RAU.
3 Definición de entidades basada en ‘SAC-Definición_de_roles’ MÉTRICA V.3
5
5 Proceso de Calidad en Ingeniería del Software
1.3 Interacción entre entidades
Según la MÉTRICA v.3 „SAC-Definición-de-roles‟, las entidades anteriormente descritas pueden pertenecer o
no a diferentes empresas. Es recomendable que las entidades pertenezcan a empresas diferentes4, en especial el
departamento de calidad, ya que para ser imparcial se necesita libertad organizativa y autoridad respecto a las personas directamente responsables del desarrollo del producto software. Las revisiones técnicas tienen un
mayor éxito de esta manera, teniendo en cuenta que en el modelo en cascada las revisiones técnicas se hacen
en cada una de las fases antes de pasar a la siguiente. La OAC necesita coordinarse y comunicarse con todas
las entidades en todo momento del proceso software, ya que sólo cuando la OAC da el visto bueno, se puede avanzar en el flujo.
Durante mis prácticas de empresa, las entidades participantes del proceso software pertenecían a las siguientes
empresas:
Cliente: Junta de Andalucía (CAPDER)
Equipo de Desarrollo (Diseño y Codificación): Tecnoabi - Tragsatec
JP: Tecnoabi - Tragsatec
DP: CAPDER - Emergya
Equipo de Despliegue: CAPDER - Fujitsu
OAC: everis
Durante este TFG supondremos una metodología de este estilo: en la cual las empresas de las que forman parte las distintas entidades sean diferentes.
Al tratarse de empresas diferentes, la comunicación supondrá un tema crucial para el éxito del control de la
calidad. Para ello se hará uso de determinadas herramientas software que faciliten el trabajo (para más información consultar la sección 3.Herramientas CASE):
1) Herramientas para la gestión de proyectos: Se trata de aplicaciones especialmente útiles para la
OAC y, sobre todo, para el comité de seguimiento. Son aplicaciones en las cuales se define el
proyecto y todas sus partes y entregables, y cada entidad tendrá libre acceso a cada una de las partes para imputar tiempo trabajado, reflejar las tareas realizadas e informar del estado en el que se ha
dejado una tarea.
De esta manera, por ejemplo, un miembro de la OAC puede comenzar a revisar un documento de diseño, parar a la mitad y detectar varias incidencias. Así, el próximo miembro de la OAC que entre
en la aplicación, verá que un compañero ya ha revisado la mitad de un documento de diseño, el
tiempo que ha invertido en ello, y podrá comprobar las incidencias que ha encontrado, permitiendo la finalización de la revisión técnica del documento añadiendo las posibles incidencias encontradas en la
segunda mitad.
Ejemplos de estas herramientas son5: Collabtive, GanttProject, iceScrum, Redbooth, Sinnaps,
TaskJuggler, Wrike y JIRA6, que es el que utilizábamos en mis prácticas de empresa.
4 Como se indica el apartado 6.3 Proceso de Aseguramiento de la Calidad, UNE 71044:1999 (ISO/IEC 12207:1995) 5 Ejemplos encontrados en https://www.lancetalent.com/blog/8-herramientas-para-la-gestion-de-proyectos-profesionales/ 6 JIRA: https://www.atlassian.com/software/jira
Descripción general del sistema
6
2) Herramientas para la transferencia de archivos y control de versiones: Se trata de herramientas
orientadas a la interacción entre DP, el Equipo de Desarrollo y la OAC. Son aplicaciones en las cuales
cada entidad puede acceder a su sección asignada (por DP) y subir o bajar ficheros, código,
documentos, paquetes, etc de forma reglada y ordenada, llevando un seguimiento de las versiones de cada entregable. El Equipo de Desarrollo usará estas herramientas para subir los documentos y
ficheros de código elaborados para que la OAC los revise, de la misma manera en la que la OAC
subirá los informes de revisión técnica elaborados, las incidencias y el resultado de las pruebas para que el Equipo de Desarrollo, DP, el equipo de despliegue o la entidad pertinente los corrija.
Estas herramientas ofrecen funciones de nomenclatura asistida para los entregables subidos,
facilitando así el control de versiones. Siempre se mostrarán visibles las distintas versiones que han sido subidas, señalando la última versión, tanto de un entregable subido por el equipo de Desarrollo
como de un informe de revisión técnica subido por la OAC.
De esta manera, por ejemplo, un miembro del equipo de desarrollo (o el JP) puede subir un
documento de diseño que acabe de elaborar. Este documento se llamará, por ejemplo: “DAO-01”. Un miembro de la OAC accederá a la herramienta y descargará el documento. La OAC realizará un
informe de revisión técnica tras revisar el documento, y subirá dicho informe a la sección de calidad
de la herramienta, asociada al entregable del documento de diseño, con el nombre “Informe_DAO-01”. El equipo de Desarrollo descargará el informe para comprobar las incidencias encontradas y
corregirá el documento de diseño. Una vez hecho, subirá la nueva versión a la herramienta para que la
OAC pueda descargarla y revisarla de nuevo, con el nombre “DAO-02” y así sucesivamente.
Un ejemplo de este tipo de herramientas lo constituye QM7 software, (Quality Management) del
Estado, que es el que utilizábamos en mis prácticas de empresa.
3) Herramientas de comunicación directa: Se trata de herramientas de comunicación directa que agilizan las tareas. No son más que aplicaciones de chat de texto, voz, correo electrónico, etc, que
facilitan la comunicación entre cualquier miembro de cualquier entidad, en especial la OAC. Útiles
para avisar de cambios realizados, entregas subidas o modificaciones pequeñas.
Destacando ejemplos de estas herramientas tenemos: Outlook, gmail, Skype, Pidgin o Spark, las
cuales utilizábamos en mis prácticas de empresa.
7 QM: https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp, url accesible desde un proxy
con acceso a la Junta de Andalucía
7
7 Proceso de Calidad en Ingeniería del Software
1.4 Definición de Entornos
Durante el proceso software, se necesitará crear entornos (o usarlos si ya estaban creados) optimizados para
cada tarea. El equipo de despliegue será el encargado de crear estos entornos, o mantenerlos y actualizarlos si
ya se habían creado con anterioridad.
Procedemos a explicar los diferentes entornos durante el proceso software, según el modelo SAC MÉTRICA
v.38:
Tabla 2. Entornos
ENTORNOS
TIPO DESCRIPCIÓN
Entorno de Desarrollo Creado por el equipo de despliegue, diseñado para diseñar,
codificar y depurar el software. Utilizado por el equipo de
desarrollo.
Entorno de Integración Creado por el equipo de despliegue, diseñado para probar la
relación del software con otros sistemas y la integración de
distintos módulos. Utilizado por el equipo de desarrollo
Entorno de Certificación
Creado por el equipo de despliegue, diseñado para realizar
las revisiones técnicas al software a través de las pruebas
funcionales y no funcionales. Utilizado por el departamento
de calidad OAC
Entorno de Cliente Se trata del entorno donde el cliente se encuentra, entorno donde implantar el software definitivo, para que el usuario
final pueda usarlo sin preocupaciones
8 Bas{ndonos en la sección 3. ‚Descripción de Actividades, creación de entornos‛, del documento:
‘SAC005P_CON_Plan_de_Configuracion_0100’, Normativa Técnica, MÉTRICA v.3
Descripción general del sistema
8
1.5 Diagrama de flujo del proceso software
Figura 1. Diagrama de flujo del proceso software
9
9 Proceso de Calidad en Ingeniería del Software
1.6 Detalle Del Proceso
Esta sección tiene como objetivo resumir de manera breve el contenido expuesto en el diagrama de flujo
de la Figura 1, destacando los procesos principales que se llevan a cabo desde el inicio del Proceso de
Calidad y comienzo del proyecto hasta el final del mismo.
La descripción, orden y motivación de las siguientes tareas se basa en la normativa descrita por la ISO9,
tanto en el diagrama de flujo previamente descrito como en la sección que ahora desarrollaremos.
1) El cliente realiza un análisis de la realidad de su entorno, y descubre problemas o carencias, que pueden ser resueltas implementando una nueva aplicación. O, si ya tenían un software previo, el
cliente descubre aspectos a mejorar en éste, debido al uso del mismo y descubrimiento de fallos o
elementos ampliables.
2) Cuando el cliente ya tiene claro lo que necesita, elabora un pliego de prescripciones técnicas,
presentándolo a un concurso en el cual varias empresas competirán para encargarse de
proporcionarle una solución al cliente. Estas empresas deberán preparar una oferta, que consiste
en explicar cómo piensan ayudar al cliente y cubrir sus necesidades, ofrecer una planificación temporal, y una estimación de costes.
3) Una vez todas las empresas han presentado sus ofertas, el cliente seleccionará una de ellas para
que se lleve a cabo (ganador del concurso), y se firmará un contrato en el cual el cliente contrata al adjudicatario seleccionado.
4) El RAU se reunirá con el equipo de Dirección de Proyectos (DP) y con una representación de los
usuarios finales del software para realizar una labor de indagación de requisitos. Posteriormente a esta reunión o reuniones en caso de haber varias, DP elaborará el documento de Definición
Detallada de Requisitos (DDR). En este documento, RAU, usuarios finales y DP dejan plasmados
los objetivos exactos a alcanzar en el desarrollo del software, cubriendo distintos campos. Una
vez elaborado el DDR, el departamento de calidad efectuará una revisión técnica del mismo, para asegurarse de que los requisitos especificados son coherentes y verificables.
5) El DP contacta con el equipo de diseño para que comience la planificación, diseño y análisis del
software. El equipo de diseño planeará y elaborará el siguiente documento: Diseño de Arquitectura Orientado a Objetos (DAO). El DAO es un documento cuyo propósito es definir la
arquitectura del sistema, diseñar los casos de uso reales, diseñar las clases y el modelo físico de
datos. Una vez elaborado el documento de diseño, el departamento de calidad efectuará una revisión técnica del mismo.
6) El equipo de codificación codificará el software según las pautas elaboradas por el equipo de
diseño. Como resultado final, elaborará todos los ficheros que conformen la aplicación,
correctamente organizados. Paralelamente a la codificación del SFW, el equipo de Desarrollo irá ejecutando las pruebas de unidad (véase sección 2.6.1 Pruebas). Además, elaborará los siguientes
documentos: Manual Básico de Instalación y Configuración (MIC), Manual de Usuario (MUS) y
Plan de Pruebas (PP). Una vez elaborados, el departamento de calidad efectuará una revisión técnica de los mismos.
7) La OAC llevará a cabo todas las pruebas descritas en el PP (excepto las pruebas unitarias ya
realizadas por Desarrollo, y las de aceptación que serán realizadas por los usuarios finales del
Cliente), y realizará un informe con el resultado de todas las pruebas para notificar al equipo correspondiente de los errores encontrados y que los corrija.
8) En cualquier momento del proceso si la OAC detecta incidencias, se lo comunicará al equipo
correspondiente, y éste corregirá dichas incidencias y enviará el producto completo de nuevo a la OAC para que ejecute una nueva revisión, repitiéndose el proceso las veces que sea necesario
hasta superar con éxito las revisiones técnicas de la OAC.
9 Bas{ndonos en la sección 5.Procesos principales del ciclo de vida, UNE 71044-1999 (ISO/IEC 12207:1995)
Descripción general del sistema
10
9) Cuando el software y documentos elaborados estén definitivamente corregidos y revisados por la
OAC, tras superar satisfactoriamente todas las pruebas, se le comunicará a DP, de manera que el
producto estará listo para las posteriores pruebas de usuario.
10) El usuario realizará las pruebas alfa al software, dentro del entorno de certificación, y decidirá si el resultado final se adapta a las características que exigía en el DDR. Si no es así, lo devolverá a
la OAC para que revise de nuevo los entregables pertinentes, y se decida o no enviarlos al equipo
correspondiente para que los corrija.
11) Si el cliente está satisfecho, la aplicación pasará al equipo de despliegue para que la implante y
realice todos los procesos necesarios para que funcione correctamente en el entorno de cliente. La
OAC revisará el despliegue y realizará de nuevo las pruebas de despliegue y las pruebas de sistema en el entorno de Cliente. Si se detectan incidencias, el equipo de despliegue realizará las
correcciones oportunas y volverá a implantar el software en el entorno de Cliente.
12) El usuario cliente realizará las pruebas beta al software, en su propio entorno. Si detecta
incidencias, tendrá la oportunidad de devolverlo a la OAC las veces que sea necesario para que se encargue de las revisiones pertinentes. Si todo va bien, la entrega se considerará finalizada, y
cliente cerrará el proyecto con el adjudicatario.
11
2 DESCRIPCIÓN ESPECÍFICA DEL SISTEMA
2.1 Introducción
ara la realización de esta sección, se ha hecho uso de la normativa definida por la ISO, al igual que en el apartado anterior: UNE 71044-1999 (ISO/IEC 12207:1995), norma que describe los procesos principales
del ciclo de vida del software, los procesos de apoyo y los procesos organizativos. Seguiremos el orden
que dictan tanto la normativa como el modelo en cascada.
2.2 Comienzo Del Proyecto10
Primera fase del proceso, en la cual, el Cliente estudia su entorno y lleva a cabo un análisis de la realidad para descubrir las carencias del software que se utiliza, para decidir si hace falta una mejora o
actualización del mismo, o la codificación de un nuevo software para cubrir una necesidad encontrada
diferente. Del mismo modo, una vez realizado este análisis, el Cliente llevará a cabo un proceso de adjudicación para su proyecto en vistas a elegir a la entidad (física o jurídica) que llevará a cabo el
proyecto software que cubra las necesidades analizadas.
Esta sección se apoyará en:
La sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 12207:1995)
La norma UNE-EN 16271:2013 Gestión del Valor. Expresión funcional de necesidades y pliego de
especificaciones funcionales. Requisitos para la expresión y validación de las necesidades a satisfacer por
un producto en el proceso de adquisición u obtención del mismo. (Correspondencia con la Norma Europea EN 16271:2012)
*Nota: El comienzo del proyecto es la única parte del proceso software en la cual la OAC no desempeña funciones directas, pero se explicará de manera necesaria para comprender el resto de partes del proceso
software en las que sí interviene Calidad.
2.2.1 Análisis de la Realidad
2.2.1.1 Sin Software previo11
Este es el caso en el que la empresa parte de cero, no posee software inicial. La empresa deberá evaluar su
entorno para reunir los requisitos necesarios que tendrá que tener la aplicación a desarrollar. Los analistas
de la empresa jugarán un papel fundamental en este caso. La clave para reunir la información necesaria es
dividir los procesos de negocio de la empresa en 3 grupos:
Procesos de negocio que actualmente se realizan y se deben seguir realizando o actualizar
Procesos de negocio que actualmente se realizan y no se deben seguir realizando
Procesos de negocio que actualmente no se realizan y se deberían realizar
10 Basado en la sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 12207:1995) 11 Basado en el est{ndar ISO 21500:2012, Guidance on Project Management, apoyado por referencias a:
https://www.gestiopolis.com/metodologia-para-evaluacion-diagnostico-y-diseno-de-procesos/
P
Descripción específica del sistema
12
12
Con el primer grupo de procesos, los analistas elaborarán un prototipo de requisitos funcionales acerca de las funciones fundamentales que deberá realizar el software como base del funcionamiento. Constituyen
la acción principal de la empresa (o sección de la empresa) y necesitan automatizarse de una manera
rápida y cómoda haciendo uso de módulos software.
Con los procesos que actualmente se realizan y no se deben seguir realizando, se pretende evitar todas las
tareas innecesarias o irrelevantes. A la hora de elaborar los requisitos, los analistas discernirán qué
procesos se deberían evitar en el nuevo software a crear, delimitando así el alcance de los requisitos.
Todos los requisitos que se definan estarán destinados a solicitar las funcionalidades estrictamente necesarias.
Con los procesos que actualmente no se realizan y se deberían realizar, se pretende confeccionar un
prototipo con todos los módulos del software posibles que ayuden a la consecución de las tareas principales. De esta manera, los procesos de negocio que se necesitan llevar a cabo serán realizados por
dicho prototipo, mejorando así el rendimiento de la empresa.
2.2.1.2 Con Software previo12
Este es el caso en el que la empresa parte ya con una aplicación parecida a la que quiere solicitar, que
cubrirá (en mayor o menor medida) los requisitos de la empresa. La motivación de solicitar una nueva
aplicación capaz de mejorar o sustituir a la anterior surge de la evaluación exhaustiva de dicho software, en la cual se detectan carencias, incidencias, aspectos a mejorar, y nuevas funcionalidades que los
usuarios finales echan de menos en la aplicación.
El Cliente puede llevar a cabo el análisis de la realidad haciendo uso de diversas técnicas:
1) Encuestas de software13
: El Cliente prepara un cuestionario con preguntas diseñadas previamente para los usuarios del software a evaluar. Los usuarios rellenarán el cuestionario
por escrito. En este tipo de cuestionarios normalmente se valora si la aplicación cumple
correctamente con las necesidades de las actividades de la empresa, si la forma de llevar a cabo los procesos es la idónea, o si se podría enfocar de otra forma. También se hace una
recopilación de aspectos más técnicos del software, para mejorar este apartado con la nueva
aplicación:
-El software es fácil de usar
-Cubre todos los aspectos necesarios en el desempeño laboral
-Se echa de menos alguna funcionalidad
-Responde rápidamente
-Se bloquea a menudo
Tabla 3. Extracto de cuestionario de satisfacción del usuario con el software que utiliza14
CUESTIONARIO SOFTWARE Muy en
desacuerdo
En
desacuerdo
De
acuerdo
Muy de
acuerdo
Se ejecuta lentamente X
Recomendaría el software a mis colegas X
Se ha detenido inesperadamente en algún
12 Basado en el est{ndar ISO 21500:2012, Guidance on Project Management, apoyado por referencias a:
https://www.emprendepyme.net/tecnicas-e-instrumentos-para-detectar-las-necesidades-de-capacitacion.html, 13 Apoyado en https://es.surveymonkey.com/mp/employee-satisfaction-surveys/ 14 Basada en https://www.survio.com/plantilla-de-encuesta/evaluacion-de-software y respaldado por:
https://www.monografias.com/docs/Ejemplo-encuesta-de-satisfacci%C3%B3n-para-usuario-de-FKZ3RNCMY
13
13 Proceso de Calidad en Ingeniería del Software
CUESTIONARIO SOFTWARE Muy en
desacuerdo En
desacuerdo De
acuerdo Muy de acuerdo
momento
Es complicado de usar X
A veces en algunos puntos, no sé cómo continuar X
Disfruto su manejo X
La información de ayuda que brinda no me resulta útil
X
Si el software termina es difícil reiniciarlo X
Aprender los comandos me tomó mucho tiempo X
La manera en que presenta la información es clara y entendible
X
2) Entrevista: El Cliente concreta reuniones presenciales con los empleados de la empresa, y
prepara una serie de preguntas acerca de los flujos de trabajo que se llevan a cabo. El Cliente
toma nota en el momento de las opiniones de los distintos usuarios sobre el modo de conseguir las metas de los procesos de la empresa, y finalmente elabora un baremo con las
evaluaciones de todos.
La entrevista deberá ser familiar, cercana y
amigable. Se deberá evitar el tono demasiado formal para promover la honestidad de los
entrevistados. En un ambiente cómodo, los
usuarios son más propensos a decir lo que piensan y a dar opiniones más veraces.
Si existía software previo, el usuario tendrá una
opinión formada para responder al entrevistador, ya que normalmente, usa el software evaluado
con periodicidad, y es el más indicado para dar
una evaluación fiable y honesta.
3) Observación: Los analistas observarán el funcionamiento de la empresa, y analizarán cómo
se consiguen las metas de las diferentes actividades y tareas. En el caso de que existiese
software previo, se comparará la conducta de los usuarios con el patrón de satisfacción y rendimiento esperado, y de esta manera, se detectarán las incidencias a mejorar. En el caso de
que no existiera, se comprobará de qué manera se podrían mejorar las labores de la empresa,
traduciéndolas en requisitos funcionales para la aplicación deseada.
4) Agentes externos: Una opción es contratar a consultores externos dotados de gran capacidad
de análisis y expertos en detectar necesidades de capacitación.
Una vez el Cliente ha recopilado (por cualquiera de las vías) todas las necesidades e incidencias de su empresa y, si lo hubiera, software previo, elaborará un documento que veremos en la siguiente sección, y
estará listo para comenzar con la tarea de la adjudicación.
Descripción específica del sistema
14
14
2.2.2 Adjudicación
La adjudicación se refiere al proceso mediante el cual el Cliente selecciona qué entidad (física o jurídica)
se va a encargar de dar solución a las necesidades previamente estudiadas y detectadas. Según el análisis y el tipo de Cliente, hay dos formas de proceder claramente diferenciadas: con y sin lanzar un concurso
público.
Esta sección usa como referencias la sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 12207:1995) y los apuntes de Proyectos de Telemática, asignatura de 4to del Grado de Ingeniería de
Telecomunicaciones.15
2.2.2.1 Sin concurso
Este es el caso en el que el Cliente selecciona al adjudicatario que resolverá sus necesidades sin lanzar un
concurso público. Se basará en el presupuesto que ofrezcan empresas o autónomos (según la envergadura
del proyecto), y contratará el servicio según el RGCE.16
Este es el caso de empresas y proyectos de menor envergadura en cuanto a tiempo y dinero, que solicitan
el desarrollo directamente al adjudicatario.
15 Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf 16 La contratación de trabajos y suministros por parte de la Administración Española est{ regulada por la Ley 13/1995, de 18 de mayo, de
Contratos de las Administraciones Públicas, y por el Reglamento General de la Contratación del Estado(Decreto 3410/1975, de 25 de noviembre)
15
15 Proceso de Calidad en Ingeniería del Software
2.2.2.2 Con concurso
En este caso, el Cliente decide lanzar un concurso público para que se presenten empresas con sus
respectivas Ofertas que compitan por convertirse en la empresa adjudicataria encargada dar solución a las necesidades del Cliente. Es el caso típico de empresas y proyectos de gran envergadura, tiempo y
dinero. Será el caso en el que nos centraremos en este TFG y que tomaremos como base. El siguiente
diagrama de flujo resume el proceso básico desde que el Cliente decide lanzar el concurso hasta que elige a una empresa adjudicataria satisfactoria que cumpla con sus necesidades:
17
17 Figura extraída directamente de: Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
Figura 2. Diagrama de Flujo Concurso Público
Descripción específica del sistema
16
16
2.2.2.2.1 Preparacio n del Pliego de Prescripciones Te cnicas
El cliente dará a conocer sus necesidades al público mediante un documento. Este documento además recogerá
todos los requisitos técnicos a los que deberá dar solución el nuevo proyecto, identificados en el previo análisis
de la realidad. Este documento es el denominado: Pliego de prescripciones técnicas
Tabla 4. Contenidos típicos de un Pliego de prescripciones técnicas18
CONTENIDOS DESCRIPCIÓN
TÉCNICOS
(Todas aquellas carencias recogidas en el
previo análisis de la realidad)
Descripción de los trabajos
Objetivos generales
Requisitos de planificación y organización del equipo de trabajo
ADMINISTRATIVOS
(Todos aquellos requisitos requeridos para
la formalización del proyecto)
Régimen jurídico: quién contrata y bajo qué forma jurídica
Requisitos de las ofertas:
-Documentación a presentar
-Forma, lugar y plazo
Criterios de valoración
Procedimiento y forma de adjudicación
Requisitos de las empresas ofertantes:
-Tipo de actividad
-Solvencia económica
-Experiencia previa
-Certificados de calidad
Formalización del contrato:
-Cómo se adjudica
-Fecha de la firma
-Avales necesarios
ECONÓMICOS
Presupuesto máximo
Forma de pago
18 Basado en el Trabajo Final Proyectos de Telem{tica, realizado por mí, Antonio Marco Rodrigo Jiménez, y corregido por el profesor titular
(PDI del Departamento de Telem{tica) Rafael Estepa.
17
17 Proceso de Calidad en Ingeniería del Software
Ejemplo de un Pliego (Incluyendo en partes diferenciadas el Pliego de Prescripciones Técnicas y el Pliego de Cláusulas administrativas):
19
19 Pliego extraído como ejemplo directamente de la web de contratación del estado:
https://contrataciondelestado.es/wps/wcm/connect/62c67958-52c9-4ef5-b30e-cd3b1566aef2/DOC_CD2012-382658.pdf?MOD=AJPERES
Figura 3. Ejemplo de Pliego
Descripción específica del sistema
18
18
2.2.2.2.2 Publicidad del Pliego20
Existen 3 maneras mediante las cuales el cliente puede publicar su pliego de prescripciones técnicas una vez
elaborado:
1) Procedimiento abierto: Cualquier empresa, asociación u organización tendrá acceso a este pliego y
será libre de presentarse al concurso.
2) Procedimiento restringido: El Cliente elegirá a unos cuantos contratistas por selección previa. Sólo
estos invitados podrán presentarse al concurso.
3) Procedimiento negociado: Este modo es más bien una reunión en la que el Cliente convoca a unos
pocos contratistas, con los que negocia las condiciones del proyecto.
Si el cliente se trata de la Administración Pública, las plataformas online donde publicará sus pliegos
serán:
https://contrataciondelestado.es
http://www.juntadeandalucia.es/contratación
Si el cliente se trata de una empresa privada y sigue un procedimiento abierto, distinguimos diferentes maneras de publicidad del pliego:
Televisión
Radio
Prensa
Internet
Exterior
En los casos de procedimiento restringido o negociado, típicamente se notificará a los contratistas por vía privada (correo, teléfono, etc).
20 Basado en Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
19
19 Proceso de Calidad en Ingeniería del Software
2.2.2.2.3 Evaluacio n de un Pliego
Una vez publicado el Pliego de prescripciones técnicas, (por cualquier vía), las empresas tendrán acceso al
mismo para comprobar los requisitos. Este es el momento en el que cada empresa valora la posibilidad y la
rentabilidad de llevar a cabo un Proyecto Software que cumpla los requisitos del Pliego publicado, respondiendo a las siguientes preguntas:
- ¿Está alineado con la estrategia de la empresa?
- Tipo de trabajo
- Coste y tiempo
21
Figura 4. Diagrama de Flujo Evaluación de Oportunidad
21 Figura extraída directamente de: Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018:
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
Descripción específica del sistema
20
20
22
Figura 5. Esquema Evaluación Oportunidad
La empresa se hará las siguientes preguntas:
¿Disponemos de conocimientos necesarios? Si no, ¿tenemos tiempo de adquirirlos?
¿Disponemos de recursos (materiales y humanos)? Si no, ¿tenemos tiempo de adquirirlos?
¿Podemos ofrecer, al menos, lo mismo que otros competidores?
¿Tiene el cliente un candidato “favorito”? Si es así, ¿podemos “ganarle”?
¿Obtendremos beneficios considerables?
¿Coste de oportunidad? = ¿nos impedirá atender a otros clientes?
¿Dotaría a la empresa de una mejora competitiva (nuevos conocimientos, mejora de la reputación,
etc.)?
Si la respuesta a estas preguntas es SÍ, como se ve en el diagrama de flujo de arriba, la empresa está interesada
en llevar a cabo el Proyecto Software que cubre las necesidades del Pliego publicado por la empresa Cliente.
22 Figura extraída directamente de: Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018:
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
21
21 Proceso de Calidad en Ingeniería del Software
2.2.2.2.4 Elaboracio n de la Oferta
Una vez la empresa contratista se ha decidido a proponerse para el concurso público, deberá elaborar una
Oferta lo más atractiva posible para el Cliente, ya que tendrá que competir con otras empresas que
también desean ganar el concurso.
Los contenidos típicos de un documento de Oferta son los representados en la siguiente tabla:
Tabla 5. Contenidos típicos de una Oferta
CONTENIDO DESCRIPCIÓN
Alcance
Describe todos los entregables, añadiendo una breve descripción de cada uno. Resume
todo lo que la empresa contratista va a ofrecer al Cliente si es elegida.
El alcance también define el ámbito y las responsabilidades de adjudicatario y Cliente.
Esto sirve para delimitar las responsabilidades de ambas partes, y quién se encarga de
conseguir determinados aspectos en el proyecto. Es importante para evitar futuros
problemas de responsabilidad legal, se describen aspectos como:
-Quién facilita lugares o entornos de ejecución necesarios
-Quién se encarga de conseguir permisos legales
-Si se requerirá suministro ilimitado de red eléctrica u otros recursos, etc
Recursos Humanos
Describe el personal que va a participar en el proyecto, pasando por los Directores de Proyecto (DP), Jefes de Equipo, Desarrolladores, OAC, Programadores, Técnicos,
Diseñadores, Documentadores, etc. También incluye su titulación, certificación,
experiencia y salario.
Planificación
Temporal
Describe la temporalización y calendarización de las tareas que se van a realizar desde el
comienzo hasta el final del proyecto. (Siempre respetando la fecha máxima de entrega
designada por el Cliente en el Pliego)
Se suele usar un diagrama de Gantt para diseñar la planificación temporal de manera
gráfica y comprensible.
Presupuestos Detalla los costes que va a tener la aplicación (siempre respetando el presupuesto máximo
designado por el Cliente en el Pliego), desglosando los gastos: Salario de los trabajadores,
gastos generales, instalaciones, etc.
Análisis de Riesgo En esta sección se plasma el resultado de un estudio previo de los posibles problemas que
puedan ocurrir durante el desarrollo del proyecto. Se detalla la probabilidad de que dichos
problemas ocurran, su prioridad y urgencia, y las soluciones planteadas ante los mismos.
Control y
Seguimiento del
Proyecto
Se describe cómo se llevará a cabo la comunicación entre Cliente y adjudicatario. Se detalla la vía y frecuencia de comunicación, las fechas de las reuniones y se define la
estructura de los Informes de Seguimiento: documentos que DP presentará al cliente en
cada reunión indicando los puntos clave de la evolución del proyecto.
Plan de Calidad
En esta sección se describe cómo se va a llevar a cabo el control de calidad por parte de la
OAC durante el proyecto, se define quién forma la OAC y los recursos disponibles para
dicha tarea. También se explica la metodología de revisiones técnicas y ejecución de
pruebas que la OAC va a utilizar.
Plan de Negocio Se calculan parámetros para comprobar la rentabilidad del proyecto. Se detalla la visión
de futuro del proyecto, la posibilidad de seguir trabajando para el mismo Cliente, y se
calculan los flujos de caja (Cash Flow) anuales, actualizando los costes y beneficios.
Anexos
En caso de que existan, se suele tratar de leyes y normativas, planos generales, guías de
usuario de interfaces o documentos de diseño extra.
La cantidad y tipo de anexos variarán en gran medida según el tipo de proyecto/SFW.
Descripción específica del sistema
22
22
A continuación mostramos los entregables típicos que incluye un Proyecto Software de este tipo si la empresa resulta elegida como ganadora del concurso, y le es adjudicado el Proyecto.:
La información para esta sección del TFG se apoya como referencia en el Trabajo Final para la
asignatura: Proyectos de Telemática, realizado por mí: Antonio Marco Rodrigo Jiménez, y corregido por el profesor titular (PDI del Departamento de Telemática) Rafael Estepa.
Tabla 6. Entregables de un Proyecto Software
ENTREGABLES DESCRIPCIÓN
DDR
(Definición Detallada de
Requisitos)
La Definición Detallada de Requisitos es un documento cuyo objetivo es recoger todos
los requisitos del Cliente para su aplicación, elaborado por DP.
Aquí se detallan cuáles son las funciones que tiene que cubrir el software (Requisitos
funcionales) y otros aspectos relacionados con la usabilidad, la velocidad del software, la
seguridad, y otros requisitos técnicos (Requisitos no funcionales).
Más información en la sección 2.3 Definición del Proyecto
DAO
(Diseño de Arquitectura
Orientado a Objetos)
El objetivo principal de este documento es describir el diseño de la arquitectura del
sistema, definir todas las clases, atributos, operaciones y relaciones entre ellas, así como el diseño de las interfaces gráficas de usuario, de acuerdo con las normas establecidas en
los Reglamentos Técnicos y los requisitos del DDR. Este documento lo elabora el equipo
de diseño, marcando las pautas bajo las cuales codificará el SFW el equipo de
codificación.
Más información en la sección 2.4 Diseño del Proyecto
SCR
(Scripts)
Se trata de ficheros codificados por el equipo de codificación, necesarios para el correcto
funcionamiento de la aplicación final.
Realizan tareas como creación de sinónimos públicos, creación o eliminación de usuarios
y roles, creación de tablas de datos (o actualización de las mismas), o acciones
relacionadas con BBDD. El orden y método de ejecución de los scripts se detalla en el
MIC.
PP
(Plan de Pruebas)
El Plan de Pruebas es el documento elaborado por el equipo de Desarrollo que reúne
todos los planes de pruebas. Los planes de pruebas describen las pruebas que se tendrán
que realizar a la aplicación para comprobar su correcto funcionamiento.
En él se aporta toda la información necesaria para que se pruebe la aplicación, y se
compruebe así que se cumplen todos los requisitos descritos en el DDR.
Más información en las secciones 2.5.5 Elaboración del PP, y sección 2.6.1 Pruebas
MUS
(Manual de Usuario)
El Manual de Usuario se trata de un documento que ilustra cómo utilizar la
aplicación, elaborado por el equipo de desarrollo. Consiste en un manual
categorizado que explica de forma sencilla todas las funcionalidades de la
aplicación.
Está dirigido al usuario final que utiliza la aplicación, así que está escrito de forma
sencilla y comprensible.
Más información en la sección 2.5.4 MUS
MIC
(Manual básico de
Instalación y
El Manual Básico de Instalación y Configuración es un documento que resume
cómo instalar la aplicación elaborado por el equipo de desarrollo.
Detalla rigurosamente los pasos a seguir para instalar el SFW, ejecutar los SCR
pertinentes, realizar modificaciones en registros, BBDD, y distintos parámetros.
23
23 Proceso de Calidad en Ingeniería del Software
Configuración) También detalla cómo hacer un backup del entorno y cómo hacer una “marcha atrás”
utilizando dicho backup, necesario por si algo falla en la instalación para que no
afecte al entorno anterior.
Más información en la sección 2.5.3 MIC
SFW
(Software)
Son los ficheros de software de la aplicación codificados por el equipo de
codificación. Pueden variar en lenguaje de programación, estructura y arquitectura
según el tipo de aplicación. En nuestro caso siempre serán ficheros Java o tipo
“form”. Se trata de los ficheros que constituyen la aplicación final.
IPC
(Informe de Pruebas de
Certificación)
El Informe de Pruebas de Certificación es un documento elaborado por la OAC que
recoge el resultado de todas las pruebas dinámicas y estáticas realizadas a la
aplicación. En el informe se adjunta un análisis del modelo de datos de los scripts
utilizados, un informe de pruebas estáticas del software, el resultado de las pruebas
descritas en el PP, y el resultado de la instalación de la aplicación en los diferentes
entornos.
Más información en la sección 2.6.4 Informes de Calidad
IPA
(Informe de Pruebas de
Aceptación)
El Informe de Pruebas de Aceptación detalla el resultado de las pruebas de usuario.
En él, la OAC plasmará la información recogida por el usuario acerca de la
aplicación, tras haber realizado las pruebas alfa y las pruebas beta.
Más información en la sección 2.6.4 Informes de Calidad
Garantía
Si aplica, la empresa añade una garantía de funcionamiento de la aplicación, ofreciéndose a rehacerla o corregir cualquier problema de instalación, bugs o
errores.
Se detalla la duración de la garantía y las condiciones para que se lleve a cabo. Se
especifica qué aspectos están dispuestos a cubrir y cuáles no.
Asistencia Técnica
La empresa ofrece correos y números de contacto para ayudar a los usuarios cuando
estén utilizando el software instalado. En caso de que tengan dudas o no sepan
hacer algo, la empresa se compromete a brindar asistencia técnica (presencial o
remota) a los usuarios.
Formación Presencial
Complementando el MUS, hay ocasiones en las que la empresa ofrecerá un pequeño
curso de formación en vivo a los usuarios que vayan a usar el Software (o a
representantes que luego a su vez les enseñen).
Se detalla la duración y contenidos del mismo, así como su calendarización y
duración en horas.
Descripción específica del sistema
24
24
Los entregables arriba descritos vienen recogidos en lo que se denomina un diagrama WBS (Work Breakdown Structure „Estructura de Descomposición del Trabajo‟). Se trata de una representación gráfica de los
entregables finales al Cliente, divididos por categorías. Se encarga de recoger de manera visual todos los
entregables una vez aceptado el proyecto. Aquí mostramos un ejemplo genérico:
Figura 6. Ejemplo de Diagrama WBS
25
25 Proceso de Calidad en Ingeniería del Software
2.2.2.2.5 Eleccio n de Propuesta23
Una vez que las empresas contendientes han elaborado sus Ofertas y las han enviado o presentado al Cliente
dentro del plazo límite, el Cliente valorará las propuestas recibidas y dará su veredicto.
El Cliente comparará las distintas propuestas en función de varios parámetros:
Coherencia entre la propuesta ofertada por la empresa adjudicataria y los requisitos del Cliente
Experiencia del contratista o proveedor en proyectos similares
Experiencia del personal clave asignado al proyecto
Salud financiera de la empresa Capacidad de respuesta considerando al equipo de trabajo que posea, maquinaria, equipos, etc.
Tiempo de ejecución, que la propuesta sea realista en función al trabajo, a los recursos asignados y a
los requisitos del cliente Propuesta económica global y a detalle, revisando que todas las fuentes de ingresos y gastos estén
contempladas
El método de elección depende de cada Cliente y Proyecto, el proceso de decisión se puede llevar a cabo de muchas maneras distintas, entre las que destacan:
1) Descartar primero todas aquellas propuestas que no cumplan los requisitos de presupuesto o fecha de
finalización, y después decidir entre los restantes
2) Descartar primero todas aquellas propuestas que no cumplan los requisitos de formación, experiencia en el sector o conocimiento técnico, y después decidir entre los restantes
3) Realización de una Matriz de Evaluación de Alternativas, en la cual se plasman los criterios
ponderados según su importancia, y a cada propuesta se le puntúa en cada uno de los parámetros. Aquella propuesta que reúna más puntos en total es aquella que mejor cubre todos los criterios
planteados (como los citados anteriormente). A continuación se muestra un ejemplo de la misma:
Tabla 7. Matriz de Evaluación de Alternativas
MATRIZ DE EVALUACIÓN DE ALTERNATIVAS
Puntuación:
0-10
Criterios (Bajo cada criterio se muestra el porcentaje de importancia en la decisión, para
ponderar el resultado en consecuencia)
Coste
(80%)
Tiempo
(60%)
Experiencia
(90%)
Fiabilidad (fama)
(85%)
Salud financiera
(65%)
Propuesta 1 8 5 2 8 6
Propuesta 2 5 5 5 5 5
Propuesta 3 4 3 9 8 2
Propuesta 4 7 2 1 10 0
Propuesta 5 6 7 6 4 1
De este modo, la propuesta ganadora será la que obtenga una puntuación más alta, habiendo obtenido muchos
puntos en los parámetros de más grado de importancia.
En este ejemplo, si una de las propuestas es muy fiable y se habla mucho de ella, y además tiene mucha experiencia, (como la Propuesta 3), es propensa a ganar el concurso, ya que estos son dos de los parámetros
que más ponderan.
23 Información basada en http://ccapsa.com/2013/10/02/
Descripción específica del sistema
26
26
La propuesta o empresa ganadora, se reunirá con el RAU de nuevo para aclarar los términos del alcance. Un alcance bien definido marcará las pautas de trabajo a seguir entre el Cliente y la empresa contratista. Al fin y al
cabo, no deja de ser un proceso de venta: la empresa contratista le ofrece un servicio al Cliente, y el Cliente le
va a remunerar por ello. Así, tienen que quedar bien delimitados los límites y responsabilidades de cada parte, para evitar confusiones, conflictos y problemas en el futuro. Mientras más transparente y claro sea este
contrato, mejor, por ello es muy importante ser profesional en este sentido. Esto generará una situación de
confianza mutua entre Cliente y adjudicatario, y se abre la posibilidad de seguir colaborando y trabajando
juntos en el futuro.
27
27 Proceso de Calidad en Ingeniería del Software
2.3 Definición Del Proyecto
Para la realización de esta sección nos hemos basado fundamentalmente en la norma UNE-ISO/IEC 90003-200, ISO 9001-2000 y MÉTRICA v.3, Modelo SAC: „SAC007P_DDR_Definicion Detallada
Requisitos_0100‟, añadiendo a pie de página referencias más específicas referentes a cada parte de la
sección de definición del proyecto.
Llegados a este punto, el Cliente ya ha elegido a su empresa contratista que va a realizar el Proyecto
Software que cubrirá sus necesidades. Ahora que ya están dispuestos a trabajar juntos, y se ha firmado el
contrato, la comunicación entre Cliente y contratista será indispensable. De esta necesidad surge la figura de DP (Dirección de Proyectos). El director o la directora de proyectos será aquella persona responsable
de ponerse en contacto con el Cliente para todo lo relacionado con el proyecto.
24RAU, DP y una representación del usuario final de la aplicación de la empresa cliente, llevarán a cabo
una primera reunión en la cual pondrán en común toda la información posible para elaborar el DDR, atendiendo a las necesidades del Pliego de Prescripciones Técnicas propuesto por el cliente, y al alcance
propuesto en la Oferta de la empresa contratista para dar solución a dichas necesidades. Dado que el
Cliente ha elegido a la empresa ganadora, es previsible que las necesidades del Cliente y lo que ofrece la empresa sean idénticas o muy parecidas, o que al menos se cubra la mayoría de las necesidades
requeridas.
Se llevarán a cabo varias reuniones de puesta en común, hasta que DP reúna todos los requisitos solicitados por RAU y los usuarios finales. (La labor de la OAC en esta sección será la de realizar una
revisión técnica al DDR antes de continuar a la siguiente fase, cuyos detalles veremos más adelante en el
apartado: 2.5 Control de Calidad).
25Es importante convocar tantas reuniones como sea necesario para asegurarse de que absolutamente
todos los requisitos que Cliente solicita queden correctamente recogidos por DP. Con el modelo en
cascada que estamos usando para este caso, es imprescindible que este paso sea perfecto y sin errores o
ambigüedades, ya que un fallo al comienzo de un proceso en cascada, acarrea problemas en todas las etapas siguientes.
El documento que elaborará DP incluyendo todos los requisitos recogidos en estas reuniones es el
denominado DDR (Definición Detallada de Requisitos), enmarcado según MÉTRICA v.3 en la fase de
Análisis del Sistema de Información (ASI).
El DDR tiene como objetivo recoger todos los requisitos del cliente para su aplicación. Normalmente, los
participantes implicados en su elaboración son el Jefe de Proyecto del Proveedor, el Jefe de Proyecto del Cliente, y analistas.
Hay distintos tipos de requisitos, según el recurso de referencia 0408 de MADEJA (Marco de Desarrollo
de la Junta de Andalucía)26
y la norma ISO/IEC 9126 „Software engineering - Product quality‟ clasificados según la naturaleza de los mismos:
24 Apoyado por la Norma ISO/IEC 14764:1999, apartado 7.3.3 (directrices para un plan de mantenimiento). 25 Apoyado por la Norma ISO/IEC 12207:1995/Amd.1:2002, apartados F.1.3.1, F.1.3.2, F.1.3.4, 5.2.1, 5.2.6, 6.4.2.1, 6.6 y F3.1.5 26 Subsistemas de Ingeniería, RECU-0408, http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/408
Descripción específica del sistema
28
28
Tabla 8. Tipos de Requisitos
TIPOS DE REQUISITOS
TIPO SUBTIPO SIGLAS DESCRIPCIÓN
FUNCIONALES
(RF)
CASOS DE USO CU
Especifican el comportamiento del sistema.
Describen lo que el sistema debe hacer, qué
funcionalidades debe incorporar la aplicación,
y qué acciones debe ser capaz de realizar,
describiendo las interacciones entre sistema y
usuarios.
REGLAS DE NEGOCIO
RN Especifican las normas del negocio que el
software tendrá que respetar y seguir.
DE CONDUCTA RC
Especifican aquellas tareas relacionadas con
otros usuarios o sistemas, cuando el software
resulta necesario para la consecución de los
objetivos de estos últimos.
DE INFORMACIÓN RIN Especifica la información y los datos que el
software deberá gestionar para funcionar
correctamente.
NO
FUNCIONALES
(O TÉCNICOS)
(RNF)
DE ENTORNO
TECNOLÓGICO RE
Describen el ambiente operativo en el que se
debe desenvolver el sistema.
DE SEGURIDAD RS
Garantizan la seguridad de tecnología de
información, seguridad de datos, seguridad
lógica, control de acceso a información
(restricciones de acceso), autenticidad de la
información, privacidad, entre otros aspectos.
DE FIABILIDAD RFI Describen la tolerancia a fallos del software y
su respuesta bajo condiciones específicas
DE USABILIDAD RU
Describen todos aquellos aspectos
relacionados con la interacción directa
software-cliente, como su facilidad de uso, su
comprensión, etc.
DE
MANTENIBILIDAD RM
Describen la capacidad o facilidad del
software para ser actualizado, analizado y
corregido en el futuro una vez implantado.
DE INTERFAZ RI Describen la comunicación con sistemas
externos, y cómo debe ser esa comunicación.
DE RENDIMIENTO Y DISPONIBILIDAD
RR
Describen la disposición del sistema para
brindar servicio correctamente y garantizar una velocidad, tiempo de respuesta y consumo
de recursos óptimos, entre otros.
OTROS RO
Derivados del entorno organizacional, entre
los que se incluyen aspectos éticos,
seguimiento de estándares y plantillas, y
requerimientos legales y regulatorios.
29
29 Proceso de Calidad en Ingeniería del Software
El DDR, además de la definición de todos los requisitos deseados para la aplicación, incluye una Matriz
de Trazabilidad. Se trata de una tabla que reúne todos los requisitos descritos y muestra varios
parámetros acerca de los mismos, como son su:
Origen
Verificabilidad
Prioridad
Importancia
Relaciones con otros de los requisitos
La Matriz de Trazabilidad27
es una herramienta fundamental para la Ingeniería del Proyecto. Dicha
matriz es la pieza clave que nos ayuda a llevar un seguimiento de los requisitos de la aplicación, y supone
la diferencia entre una buena o mala ejecución que no diste mucho de la planificación. Está dirigida al comité de seguimiento, y aporta varios beneficios al proyecto.
Esta matriz es muy importante debido a que permite controlar el ciclo de vida de los requisitos. A medida
que se van validando los requisitos, se actualizará esta Matriz de Trazabilidad, al tratarse de una tabla
dinámica. De esta manera el comité de seguimiento es capaz de controlar qué requisitos han sido validados, cuáles están pendientes o cuáles han sido rechazados, en cualquier etapa.
Por otro lado, al mostrar las relaciones de los requisitos entre ellos, identifica dependencias críticas y
detecta rápidamente inconsistencias entre dos o más requisitos. Así, cuando se introduce un cambio para un requisito, podemos ver en la Matriz de Trazabilidad a qué otros requisitos afecta este cambio, y
comprobarlos o modificarlos si es necesario rápidamente. También, si se detecta un fallo referente a un
requisito, se acude a la tabla para comprobar a qué otros requisitos puede afectar dicho fallo.
Figura 7. Ejemplo de Matriz de Trazabilidad
27 Según la Norma ISO 10007-1997, ‘Directrices para la gestión de la configuración’
Descripción específica del sistema
30
30
Por otro lado, como tarea de esta sección del proceso software, la labor de la OAC también incluye la realización del PPA (Plan de Pruebas de Aceptación). Este es el primer plan de pruebas que se elabora, sin
embargo, las pruebas de aceptación serán de las últimas que se ejecuten (consultar sección 2.6.1 Pruebas
para más detalles). La OAC, una vez realice la revisión técnica al DDR, elaborará este plan de pruebas, el cual servirá de guía a los usuarios finales en la realización de las pruebas que verifiquen los requisitos
funcionales solicitados, en cuyo caso se aceptará el sistema.
El Plan de Pruebas de Aceptación (PPA) desarrolla las pruebas de Aceptación, las cuales se realizarán o
supervisarán por el RAU, cuyos detalles describiremos en la sección 2.6.1 Pruebas, y en la sección 2.7 Pruebas de Usuario.
31
31 Proceso de Calidad en Ingeniería del Software
2.4 Diseño Del Proyecto
En este punto, el DDR ha sido elaborado y satisfactoriamente revisado por la OAC. Así, DP se lo pasará al equipo de Diseño, finalizando de esta manera la fase ASI y comenzando la fase DSI (Diseño del
Sistema de Información).
El objetivo del proceso de Diseño del Sistema de Información (DSI), según MÉTRICA v.3, modelo SAC: „DSI Procedimiento Global‟
28 es la definición de la arquitectura del sistema y del entorno tecnológico que
le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información.
El DSI consta de varios entregables que el equipo de Desarrollo tendrá que elaborar, incluyendo, entre otros, el documento de Diseño. En esta sección, nos centraremos en este último, el cual será elaborado
concretamente por el equipo de Diseño.
El equipo de Diseño elaborará el documento de diseño del sistema que mejor se adapte a los requisitos
especificados en el DDR, y que constituya la base para desarrollar el sistema de la forma más eficiente y óptima en cuanto a tiempo, simplicidad y funcionalidad.
El buen trabajo del equipo de Diseño se reflejará en la definición de una arquitectura estructurada,
organizada y sencilla de entender e implementar. El equipo de Codificación será el principal destinatario de los documentos que elabore el equipo de Diseño, ya que seguirán las pautas indicadas en sus
documentos.
A continuación, describiremos detalladamente el documento que Diseño tendrá que elaborar, basándonos en MÉTRICA v.3, modelo SAC: „SAC007P_DAO_Diseño Arquitectura OO_0100‟.
2.4.1 DAO (Diseño de Arquitectura Orientado a Objetos)
Los objetivos de este entregable son, por un lado, definir el particionamiento físico del sistema, especificar en detalle el entorno tecnológico y sus requisitos de operación, administración, seguridad, auditorías y control de
acceso. Y por otro lado, el diseño detallado del Sistema, el cual comprende un conjunto de actividades cuyo
alcance se resume a continuación:
Diseño de Casos de Uso Reales, con el diseño detallado del comportamiento del sistema para los
casos de uso y el diseño de la interfaz de usuario.
Diseño de Clases, con el diseño detallado de cada una de las clases que forman parte del sistema, sus atributos, operaciones, relaciones y métodos, y la estructura jerárquica del mismo.
Diseño Físico de Datos que incluye el diseño y optimización de las estructuras de datos del sistema.
El DAO incluye trazas a los requisitos, de manera que con la elaboración del documento se puede comprobar
qué requisitos van a ser validados, en especial en la sección de Casos de Uso, los cuales representan cómo se
va a dar solución a los requisitos funcionales, y en la sección de descripción del entorno tecnológico, la cual incluirá trazas para los requisitos de entorno tecnológico y otros requisitos no funcionales.
A continuación, describiremos en detalle la estructura de un DAO elaborado por Diseño:
28 Apoyado en la norma ISO 9001-2000, sección 7.3: „Diseño y Desarrollo‟ y en la norma ISO/IEC 12207, sección: „Development‟
Descripción específica del sistema
32
32
Tabla 9. Estructura de un DAO
DAO
SECCIÓN DESCRIPCIÓN
1. INTRODUCCIÓN
Subsecciones:
1.1 Objeto
1.2 Alcance
1.1 Objeto Se describe el propósito del documento de Diseño de Arquitectura Orientado a Objetos del Sistema para la entrega específica.
1.2 Alcance Se describen las unidades organizativas y responsabilidades a las que va
dirigida el DAO y que participan en su generación, validación y registro.
2. DESCRIPCIÓN DEL
ENTORNO
TECNOLÓGICO
En esta sección se consideran fundamentalmente los RE. Se describen en las
subsecciones aspectos como la capacidad de almacenamiento requerida,
software quue se va a utilizar, etc de manera aproximada y orientativa, para
guiar al equipo de Codificación. (Siempre bajo las necesidades o limitaciones
definidas en los RE). Subsecciones:
2.1 Elementos de la infraestructura
2.2 Restricciones Técnicas
2.3 Planificación de Capacidades
2.1 Elementos de la
infraestructura
Descripción de la infraestructura tecnológica agrupándola en los siguientes
conceptos:
Hardware: procesadores, unidades de almacenamiento, estaciones de trabajo, etc. necesarios para explotar el sistema.
Software: sistemas operativos, sistemas gestores de base de datos,
middleware, sistemas de ficheros, software de base, herramientas y utilidades
de gestión del sistema, etc.
Comunicaciones: diseño de la topología de red, protocolos, nodos de red,
etc.
En este punto, también se deberán detallar las medidas de seguridad que se
tomarán en el sistema.
2.2 Restricciones Técnicas En base a la infraestructura tecnológica del sistema, se procederá a identificar
y describir las restricciones técnicas derivadas de la utilización de la
tecnología seleccionada y que afecten al diseño o construcción del software.
2.3 Planificación de
Capacidades
Se describen los requisitos mínimos de hardware que deberán tener los
equipos finales para lanzar correctamente la aplicación, especificando los parámetros de explotación precisados para su realización, indicando las
necesidades de:
Almacenamiento: espacio en disco, espacio en memoria, pautas de
crecimiento y evolución estimada del sistema de información, etc.
Procesamiento: número y tipo de Procesadores, memoria, etc.
Comunicaciones: líneas, caudal, capacidades de elementos de red, etc.
Para la realización de la planificación de las capacidades será necesario tener
en cuenta entre otros el Modelo Físico de Datos.
3. ARQUITECTURA DE Subsecciones:
33
33 Proceso de Calidad en Ingeniería del Software
CLASES DEL SISTEMA 3.1 Definición de Niveles de Arquitectura del Sistema
3.2 Diseño de Casos de Uso
3.3 Modelo de Clases de Diseño
3.1 Definición de Niveles de
Arquitectura del Sistema
Se describen los niveles de la arquitectura software, mediante la definición de
las principales particiones físicas del sistema de información, representadas
como nodos (partes del sistema) y comunicaciones entre nodos (interfaces
entre las partes del sistema).
3.2 Diseño de Casos de Uso
Se especifica el comportamiento del sistema para cada caso de uso. Por ello
será necesario identificar las clases que intervienen en cada caso de uso,
teniendo en cuenta las clases adicionales que surgen como consecuencia del
diseño. Una vez identificadas las clases participantes dentro de un caso de
uso es necesario completar los escenarios que se recogen del análisis,
incluyendo las clases de diseño que correspondan y teniendo en cuenta las
restricciones del entorno tecnológico. Es necesario analizar los
comportamientos de excepción para dicho escenarios.
3.3 Modelo de Clases de
Diseño
Se describen las clases que va a tener el sistema, así como sus atributos,
métodos y relaciones entre ellas. Se deberá detallar toda la información mencionada para cada clase, así como elaborar un diagrama de clases que
muestre los atributos, métodos y relaciones más importantes entre las clases
definidas, que representará los aspectos estáticos del sistema.
4. DISEÑO DE
INTERFACES DEL
SISTEMA
Subsecciones:
4.1 Diseño de interfaz de usuario
4.2 Diseño de interfaces con otros sistemas
4.1 Diseño de interfaz de
usuario
El objeto de esta sección es realizar el diseño detallado del comportamiento
de la interfaz de usuario de acuerdo con el entorno tecnológico definido. En
el caso de que existiese un prototipo de la interfaz de usuario se tomaría
como punto de partida para el diseño. Se deben incluir, además, las ventanas
o pantallas o elementos de diseño surgidos como consecuencia del diseño de
los escenarios definidos en los casos de uso.
4.2 Diseño de interfaces con
otros sistemas
El objetivo de esta sección es describir cada caso de uso en términos de los
sistemas externos que participan en el caso de uso y de las interfaces que se requieren entre ellos.
Para cada caso de uso hay que definir, además de los sistemas exteriores y los
actores que intervienen en el mismo, los mensajes que se intercambian entre
el sistema en desarrollo con el resto de sistemas.
5. MODELO FÍSICO DE
DATOS
El objetivo de esta actividad, es definir la estructura física de los datos que
utilizará el sistema, a partir del modelo lógico de datos normalizado teniendo
en cuenta el entorno tecnológico que albergará el nuevo sistema. El diseño
del modelo físico de datos puede englobar clases, bases de datos, ficheros a
utilizar, etc.
6. ANEXOS Este punto contendrá toda aquella información de interés para la elaboración
y validación del documento de Diseño de Arquitectura Orientado a Objetos.
7. GLOSARIO Este punto contendrá la definición de todos los términos utilizados en el
documento Diseño de Arquitectura Orientado a Objetos del Sistema y que
formará parte del diccionario de la aplicación.
8. BIBLIOGRAFÍA Y
REFERENCIAS
En este punto se incluirán las referencias a la documentación utilizada para la elaboración de dicho documento.
Descripción específica del sistema
34
34
Una vez elaborado el documento, el diseño de la aplicación se da por finalizado, y se enviará al departamento de calidad. La labor de la OAC en esta sección será la de realizar una revisión técnica al
DAO antes de continuar a la siguiente fase, cuyos detalles veremos más adelante en el apartado: 2.5
Control de Calidad. Una vez que el DAO supere satisfactoriamente la revisión técnica realizada por Calidad, se pasará a la siguiente fase: La codificación del software.
Por otro aldo, al tener ya realizado el diseño de la aplicación, es posible ver de qué manera se puede
probar el software, en sus aspectos tanto funcionales como técnicos. Es por eso que en esta fase se
elaborarán diversos planes de prueba, los cuales describirán las pruebas que tendrá que realizar la OAC para garantizar el correcto funcionamiento del software.
Concretamente, en esta fase, el equipo de Desarrollo elaborará:
PPU (Plan de Pruebas Unitarias)
PPI (Plan de Pruebas de Integración)
PPS (Plan de Pruebas de Sistema)
PPF (Plan de Pruebas Funcionales)
PPNF (Plan de Pruebas No Funcionales)
*Nota: El Plan de Pruebas No Funcionales se completará en la fase de Codificación, una vez se tenga
generado el software. En la mayoría de casos, gran parte de las pruebas descritas en el PPNF forman parte
de las pruebas de Sistema, y se incluyen también en el PPS.
*Nota: Se ha realizado esta clasificación de los planes de prueba según el modo de operación seguido
bajo nuestra experiencia en la OAC en everis. Al igual que ocurre con el PPNF y PPS, el PPF y el PPA
pueden compartir muchas pruebas o ser casi idénticos según el caso. La diferencia principal es que el PPF está dirigido a la OAC, mientras que en el PPA las pruebas están dirigidas al usuario final, y están
descritas de una manera diferente, más enfocadas a la perspectiva del Cliente.
35
35 Proceso de Calidad en Ingeniería del Software
2.5 Codificación Del Proyecto
En el punto intermedio del proceso software en el que nos encontramos, le llega el turno al equipo de Codificación. En este punto, el equipo de Diseño habrá elaborado satisfactoriamente el DAO, y el equipo
de Codificación tendrá que seguirlo para codificar el software de la aplicación, dando lugar a la fase CSI
(Construcción del Sistema de Información), cuyas tareas (junto con las restantes de la fase DSI) y sus responsables se resumen en:
Tabla 10. Tareas DSI y CSI de Desarrollo
TAREAS DSI Y CSI DE DESARROLLO
FASE TAREA RESPONSABLE
DSI
(Diseño del Sistema de
Información)
Elaboración de la mayor parte del PP
total: PPU, PPI, PPS, PPF y una parte
del PPNF.
Desarrollo
Codificación de Scripts (SCR) Desarrollo
(Equipo de Codificación)
CSI
(Construcción del Sistema
de Información)
Preparación del Entorno de
Construcción Equipo de Despliegue
Generación del Código de los Componentes y Procedimientos
(Software SFW)
Desarrollo
(Equipo de Codificación)
Elaboración de la parte restante del PPNF, completando así el PP total
Desarrollo
Elaboración del MUS
(Manual de Usuario)
Elaboración del MIC
(Manual Básico de Instalación y Configuración)
(Tabla realizada según 29
MÉTRICA v.3, modelo SAC: „DSI Procedimiento Global‟)
El buen trabajo de esta fase se reflejará en la codificación de una aplicación que se adapte al diseño
elaborado previamente, que cumpla todos los requisitos del DDR y que esté bien documentada para
facilitar su corrección tras posibles incidencias halladas por la OAC. Cualquier miembro del equipo de Codificación debería ser capaz de continuar con la codificación en cualquier momento antes de
terminarla, así como de encargarse de su corrección tras una revisión técnica de la OAC. Esto es lo que
marcará un resultado satisfactorio por parte de este equipo.
29 Apoyado en la norma ISO 9001-2000, sección 7.3: „Diseño y Desarrollo‟ y en la norma ISO/IEC 12207, sección: „Development‟
Descripción específica del sistema
36
36
2.5.1 Preparación Del Entorno de Construcción
En primer lugar, el Equipo de Despliegue se encargará de crear (o preparar si ya existía previamente) el entorno de Desarrollo y de Integración. (Más detalles en la sección 2.8 Despliegue).
El resultado de esta tarea es que el equipo de Despliegue dejará listo el entorno de Desarrollo y de
Integración para la codificación del software, dando paso a la siguiente tarea.
2.5.2 Generación de Código
Una vez listo el entorno de Desarrollo e Integración, el equipo de Codificación junto con el JP generará el
código de los componentes del sistema de información identificados en los procesos previos de ASI y
DSI. La base, por tanto, para su codificación deben ser las especificaciones de construcción obtenidas del
DAO en el proceso de DSI.
El SFW codificado necesitará en ocasiones de ciertos scripts (SCR) sql que afectan a diferentes Bases de
Datos (BBDD) requeridas por la aplicación. Será tarea a su vez del equipo de Codificación el codificar
dichos SCR respetando la normativa técnica. Tanto el SFW como los SCR si los hay, serán sometidos a revisiones técnicas y probado según el Plan de Pruebas por la OAC.
Por otro lado, la labor de Desarrollo incluye además la elaboración de 3 documentos: un manual de
instalación de la aplicación, un manual de uso de la aplicación, y un plan de pruebas que facilite la
revisión técnica de la aplicación.
A continuación, describiremos detalladamente los documentos que Desarrollo tendrá que elaborar.
2.5.3 MIC (Manual básico de Instalación y Configuración)
El MIC es un documento cuyo objetivo es indicar de manera detallada cómo instalar y configurar la
aplicación por primera vez (ya sea en el entorno de certificación de la OAC, o en el entorno de cliente del
usuario final).
Este procedimiento reúne los recursos básicos para la instalación (humanos, hardware y software), detalla
los requisitos previos a la instalación y los pasos de la misma, incluyendo la ejecución de los SCR (si los
hubiera) en qué instancia de BBDD, la edición (en caso de necesitarla) de los ficheros de configuración
del SFW, y la compilación de todos los objetos, entre otros.
En algunos casos, el MIC describe el procedimiento para instalar el software un escenario tipo sandbox
antes del despliegue en el escenario real. Al instalar el software en un escenario tipo sandbox (con el uso
de un software o máquina virtual a tal efecto) se comprueba que todo funcione correctamente antes del despliegue en el escenario real sin afectar a éste, ya que cualquier acción en el entorno sandbox estará
aislada.
También incluye la realización de un backup o copia de seguridad del entorno actual del equipo antes de instalar la aplicación, en caso de que hubiera algún problema, poder volver atrás al punto de restauración
previo. Se detalla a su vez cómo realizar esta marcha atrás, indicando los pasos necesarios de borrado o
ejecución de SCR automáticos codificados por el equipo de Desarrollo.
A continuación, veremos de qué partes consta típicamente un MIC elaborado por Desarrollo, según MÉTRICA v.3, modelo SAC: „SAC007P_MIC_Manual_Instalacion_Configuracion_0100‟.
Tabla 11. Estructura de un MIC
MIC
SECCIÓN DESCRIPCIÓN
1. DESCRIPCIÓN DEL
PROBLEMA/CAMBIO Y
En este apartado se describirá el motivo que originó el desarrollo de la
entrega. Ésta puede venir originada por una incidencia detectada o para
37
37 Proceso de Calidad en Ingeniería del Software
SOLUCIÓN ADOPTADA añadir o modificar cierta funcionalidad del sistema. Así mismo, se describirá
la solución técnica adoptada a grandes rasgos.
2. RECURSOS
EXTRAORDINARIOS
Se describen los recursos necesarios para la instalación, incluyendo:
Recursos humanos: Administradores de sistemas en los diferentes entornos, y
los usuarios finales.
Software: Compiladores, versiones de determinados programas o interfaces,
necesarios para instalar e interactuar con la aplicación desarrollada
Hardware: Requerimientos extra de CPU, espacio en disco, etc.
3. INSTALACIÓN Y
CONFIGURACIÓN DEL
SISTEMA
Subsecciones:
3.1 Requisitos previos
3.2 Procedimiento de instalación
3.1 Requisitos previos
Se detallan prerrequisitos necesarios para que la aplicación se pueda instalar
satisfactoriamente. Plantea cuestiones relacionadas con la conexión y
desconexión de usuarios antes de comenzar la instalación, el acceso a la
aplicación, si se debe coordinar la instalación con la de otro SFW para que
funcione sin problemas o si es necesario salvaguardar un punto de
restauración y realizar backups del esquema, entre otros.
3.2 Procedimiento de
instalación
Este constituye el punto clave del documento. En él se describen detalladamente los pasos necesarios para instalar la aplicación en el entorno
de pruebas o el entorno de usuario final. Para cada tarea se indicarán los
siguientes datos:
Número del paso (secuencial)
Tipo de tarea: Especificando si es una de las siguientes:
-CON: Configuración de archivos
-PAR: Configuración de parámetros propios de la
aplicación en BBDD
-SCR: Ejecución de scripts de BBDD
-SFW: Compilación/Ejecución de software. Se deben
indicar las librerías de las que se hace uso.
-IMP: Import de datos, indicando las sentencias completas
con todos sus parámetros
Descripción: Lo más detallada posible, ya que no se sabe quién va a
ser la persona encargada de instalar la aplicación
4. MARCHA ATRÁS
En este apartado se indicarán las instrucciones necesarias para realizar la
marcha atrás de la entrega, dejando el sistema en el mismo estado estable en
el que se encontraba antes de comenzar la instalación. Si es necesaria la
ejecución de scripts de marcha atrás para dejar el esquema de base de datos
en la situación consistente anterior, éstos se deben incrustar comprimidos en
ZIP. Posteriormente, se describe el procedimiento utilizando dichos scripts.
5. ANEXOS Este punto contendrá toda aquella información de interés para la elaboración
y validación del presente documento
6. GLOSARIO Este punto contendrá la definición de todos los términos y acrónimos
utilizados en el documento
7. BIBLIOGRAFÍA Y
REFERENCIAS
En este punto se incluirán las referencias a la documentación utilizada para la elaboración del documento.
Descripción específica del sistema
38
38
2.5.4 MUS (Manual de Usuario)
El objetivo del MUS es explicar al usuario final cómo utilizar todas las funcionalidades de la aplicación
desarrollada. Resulta esencial que el manual esté escrito de forma clara y comprensible.
El MUS incluirá un mapa del sistema, para que el usuario aprenda a navegar a través de las diferentes
secciones de la misma. Por cada ventana/sección del programa, el MUS incluirá una descripción de todas
las funcionalidades, botones, menús y desplegables existentes, detallando qué hace cada uno de estos elementos. Adjuntará a su vez pantallazos o capturas del programa para facilitar la comprensión y la
navegación.
Por último, el documento anexará bastante información de utilidad, como los requisitos y procesos que
cubre cada sección o funcionalidad de la aplicación, incidencias frecuentes, mensajes de error, y una sección de FAQ (Frequently Asked Questions o PP.FF Preguntas Frecuentes).
A continuación, veremos de qué partes consta típicamente un MUS elaborado por Desarrollo:
Tabla 12. Estructura de un MUS
MUS
SECCIÓN DESCRIPCIÓN
1. DESCRIPCIÓN DEL
SISTEMA
Subsecciones:
1.1 Objeto
1.2 Alcance
1.3 Funcionalidad
1.3.1 Funcionalidad sustituida
1.3.2 Funcionalidad aportada
1.4 Mapa del sistema
1.1 Objeto En este apartado se detallará cual es el objeto o función global del sistema
dentro de la organización.
1.2 Alcance
En este apartado se detallará cual es el alcance del sistema dentro de la
organización, a qué unidades afecta de forma activa y a cuales de forma
pasiva. Es decir, qué unidades dentro de la organización participan o usan el
sistema de forma activa y qué unidades se ven afectadas por el mismo de
forma pasiva o sin tener contacto con él.
1.3.1 Funcionalidad sustituida Detalla cuáles son las diferencias funcionales entre los anteriores procesos si
los hubiera y el nuevo sistema.
1.3.2 Funcionalidad aportada En este apartado se describirá la funcionalidad que el nuevo sistema
implementa y aporta a la organización.
1.4 Mapa del sistema
En este apartado se hará una descripción del sistema. Se comenzará
describiendo el sistema en su entorno, se continuará con una descomposición lógica del sistema por módulos, a continuación se describirá cada módulo,
etc. El límite inferior lo pondrá el autor del documento.
Es altamente recomendable que para sistemas con una interfaz de
ventanas/pantallas se describa, también, la navegación a través de un grafo de
ventanas. En este diagrama se representarán todas las ventanas del sistema y
mediante flechas todas las posibles navegaciones entre las mismas.
39
39 Proceso de Calidad en Ingeniería del Software
2. OPERATIVA DEL
SISTEMA
Esta es la sección clave del documento. En ella se describirá la aplicación
entera, parte por parte, describiendo todas las funcionalidades aportadas. Se describirán todas las ventanas del programa, orientado a explicar el sistema a
través de la interfaz gráfica de usuario. Se explicarán las acciones permitidas
en cada ventana, y se adjuntarán capturas o pantallazos para guiar al usuario
en todo momento.
3. ANEXOS
Subsecciones:
3.1 Ref Proceso / Requisito
3.2 Ref Proceso / Validación
3.3 Incidencias frecuentes
3.4 Mensajes de error
3.5 Términos y acrónimos
3.6 FAQ
3.7 Ayudas
3.1 Ref Proceso / Requisito En este apartado se ofrecerá una referencia cruzada entre los requisitos
recogidos al inicio del proyecto y los procesos que componen el sistema. Se marcarán los procesos que resuelven un requisito y viceversa.
3.2 Ref Proceso / Validación Se enumerarán todas las validaciones que el sistema realiza y se relacionarán
con los procesos que lo componen.
3.3 Incidencias Frecuentes En este apartado se enumerarán las incidencias más frecuentes que se pueden
encontrar durante el uso de la aplicación y, junto a cada una de ellas, se
ofrecerá una solución.
3.4 Mensajes de error Se ofrecerá una lista con todos los mensajes de error que el sistema ofrece al
usuario, bien sea a través de ventanas o de ficheros de log, y se adjuntará una
descripción más extensa para cada uno de ellos.
3.5 Términos y acrónimos En este apartado se ofrecerá una lista de términos y acrónimos usados en el
programa y una definición para cada uno de ellos.
3.6 FAQ Se ofrecerá una lista de las preguntas o dudas más frecuentes que pueden
surgirle a un usuario del sistema junto a una explicación para cada una de
ellas.
3.7 Ayudas En caso de que el sistema tenga un sistema de ayuda, se ofrecerá una breve
guía de uso sobre el mismo.
4. GLOSARIO Este punto contendrá la definición de todos los términos y acrónimos
utilizados en el documento
5. BIBLIOGRAFÍA Y
REFERENCIAS
En este punto se incluirán las referencias a la documentación utilizada para la elaboración del documento.
Descripción específica del sistema
40
40
2.5.5 Elaboración del PP (Plan de Pruebas)
El PP (Plan de Pruebas) es un documento que tiene como objetivo aportar pruebas para verificar y validar
la aplicación. Generalmente este documento está dirigido a la OAC (Oficina de Aseguramiento de Calidad), ya que Calidad será responsable de realizar la mayoría de las pruebas descritas en dicho PP, las
cuales son pruebas de integración, de sistema, de regresión, de humo, de despliegue, y todas las pruebas
no funcionales. Por otro lado, Desarrollo realizará las pruebas unitarias y el usuario final realizará las pruebas de aceptación.
El PP está formado por varios planes de prueba distintos. Un Plan de Pruebas es un documento en el que
se resumen las pruebas de un determinado tipo, cuyo objetivo es comprobar un aspecto específico del
software, ya sea funcional o técnico.
Describiremos detalladamente las diferentes pruebas detalladas en los planes de prueba en la sección
2.6.2 Pruebas.
En la siguiente tabla mostramos de qué Planes de Prueba diferentes consta un PP completo:
Tabla 13. Estructura del PP
PP
PLAN DESCRIPCIÓN CREADOR EJECUTOR
PPA (Plan de Pruebas de Aceptación)
Plan de pruebas que describe las
pruebas de aceptación. Elaborado en la fase ASI, tras la realización del DDR.
OAC Usuario final
PPU
(Plan de Pruebas Unitarias)
Plan de pruebas que describe las
pruebas unitarias. Elaborado en la fase
de Diseño, tras la realización del DAO.
Desarrollo
Desarrollo
PPI
(Plan de Pruebas de Integración)
Plan de pruebas que describe las
pruebas de integración. Elaborado en la
fase de Diseño, tras la realización del
DAO.
OAC
PPS
(Plan de Pruebas de Sistema)
Plan de pruebas que describe las
pruebas de sistema. Elaborado en la
fase de Diseño, tras la realización del
DAO.
PPF
(Plan de Pruebas Funcionales)
Plan de pruebas que describe las
pruebas funcionales. Elaborado en la
fase de Diseño, tras la realización del
DAO.
PPNF
(Plan de Pruebas No Funcionales)
Plan de pruebas que describe las
pruebas no funcionales. Elaborado en primer lugar en la fase de Diseño tras
la realización del DAO, y completado
en la fase de Codificación, tras
codificar el software.
Desarrollo
Como al codificar el software se completa el PPNF, el PP estará completo en este punto, y listo para ser
enviado a la OAC para que comience con la ejecución de todas las pruebas descritas en el documento.
41
41 Proceso de Calidad en Ingeniería del Software
Los diferentes Planes de Prueba tienen una estructura común, la cual se basa en describir el entorno general de las pruebas, y los casos de prueba a realizar. Un Caso de Prueba comprende la realización de la
prueba de un ascpecto específico dentro del Plan de Pruebas. Por ello, cada Plan de Pruebas estará
formado por varios Casos de Prueba diferentes.
Como ejemplificación aclaradora, usaremos el PPF para mostrar la estructura que deben tener los
diferentes planes de prueba.
A continuación, veremos de qué partes consta típicamente un PPF elaborado por Desarrollo:
Tabla 14. Estructura de un PPF
PPF
SECCIÓN DESCRIPCIÓN
1. DESCRIPCIÓN
GENERAL
En esta sección se numeran los Casos de Prueba definidos en el documento y
qué RF del DDR testea cada uno.
También se añade una breve descripción de qué es la funcionalidad que se va
a probar y cómo se va a probar.
2. ENTORNO DE PRUEBAS
Se indican los requisitos hardware y software necesarios para llevar a cabo
los diferentes Casos de Prueba. Se indican entre otros:
-Versiones compatibles
-Entornos de prueba admitidos
-Si hacen falta herramientas auxiliares
-Tecnología de la aplicación
3. CASOS GENERALES
La función general de este apartado es definir a los usuarios de prueba. Se
indica qué tipo de usuarios deberán entrar en la aplicación para probarla, y se
añaden los pasos para dotar a dichos usuarios de los roles y permisos
necesarios.
*Nota: Cada Caso de Prueba puede necesitar de un usuario de pruebas distinto, en función de los RF que se quieran probar, necesitando así de dotar
a los usuarios de distintos roles o privilegios.
4. CASOS DE PRUEBA
(CP)
Este es el apartado clave del documento. En él se definen los diferentes Casos
de Prueba (CP) que tendrá que ejecutar la OAC para testear correctamente la
aplicación. Cada CP consta de las siguientes subsecciones:
1) RF testeado: Indica qué RF del DDR se prueba con este CP.
2) Descripción: Se describe qué funcionalidad se va a probar
exactamente y cómo se va a probar.
3) Prerrequisitos: Si aplica, se indican los pasos previos necesarios
antes de comenzar a probar el CP. (Dotación de roles, creación de
tablas sql, etc).
4) Roles del usuario de pruebas: Indica qué usuario de pruebas se
debe usar en este CP y qué roles y privilegios debe poseer.
5) Tiempo necesario de ejecución: (en minutos)
6) Secuencia de ejecución
7) CASO DE PRUEBA
5. ANEXOS Se incluyen los anexos necesarios (si aplica) para la ejecución de las pruebas.
Si no es texto, deberá indicarse cómo se llaman los archivos anexos, y
deberán ir adjuntos al PPF comprimidos en un .zip .rar etc.
Descripción específica del sistema
42
42
Los CP definidos en el PPF deben estar detalladamente explicados, describirse paso por paso y estar enfocados a la OAC, los cuales no han desarrollado la aplicación. Esto quiere decir que Desarrollo debe
tener cuidado a la hora de redactar los CP, porque no puede esperar que otros asuman información que
para ellos es obvia (ya que ellos han desarrollado el SFW de la aplicación).
La siguiente es la estructura típica de los Casos de Prueba:
Tabla 15. Estructura de un Caso de Prueba
CASOS DE PRUEBA (CP)
PASO DESCRIPCIÓN PROGRAMA / VENTANA
DATOS DE ENTRADA
SALIDA ESPERADA
OBSERVACIONES
Número
del paso
de
ejecución
.
Instrucciones: qué
es lo que tiene
que hacer el
tester.
Ventana de la
aplicación en la
que debería
encontrarse en
este paso.
En caso de que
en este paso se
tengan que
introducir datos
de entrada,
detalla cuáles
son.
Reacción
esperada del
programa. Si
la ejecución
cumple lo
descrito aquí,
se da por
verificado este
paso.
Si se considera
necesario, aquí se
describen aclaraciones,
consejos,
recomendaciones y
avisos.
En ocasiones, los Casos de Prueba se dividen en Ciclos. Los ciclos se usan cuando hay que realizar
ciertas pruebas previas a otras en una misma sección / ventana de la aplicación para probar una
funcionalidad completa. Mostramos a continuación un ejemplo de Caso de Prueba:
Tabla 16. Ejemplo de Caso de Prueba
CASOS DE PRUEBA (CP)
PASO DESCRIPCIÓN PROGRAMA
/ VENTANA
DATOS DE
ENTRADA
SALIDA
ESPERADA OBSERVACIONES
1 Entra en la
sección: Pruebas Menú principal
Acceso a la sección:
Pruebas
2 Pulsa el botón de:
“Subir fichero” Menú principal
/ Pruebas
Ventana de selección de fichero
del disco duro local
Se mostrará el último directorio accedido por
la aplicación
3
Selecciona el
fichero deseado
del disco duro
local
Menú principal
/ Pruebas /
Ventana de
selección de
ficheros
Fichero
deseado
Se carga el fichero
deseado en la
ventana de
selección de
ficheros
4
Rellenar la fecha
de subida y pulsar
el botón
“Guardar”
Menú principal
/ Pruebas /
Ventana de
selección de
ficheros
Fecha:
Fecha actual
Se guarda el
fichero, se actualiza
la fecha de carga y
se vuelve al menú
de Pruebas
5 Salir de la
aplicación
Menú principal
/ Pruebas
Sale de la
aplicación
Puede tardar unos
segundos en completar
la acción
43
43 Proceso de Calidad en Ingeniería del Software
La labor de la OAC en esta sección del proceso será la de realizar revisiones técnicas a cada uno de los entregables generados por Desarrollo, además de ejecutar las pruebas descritas en el plan de pruebas.
Explicaremos en detalle la ejecución de las pruebas y el proceso de revisiones técnicas en el siguiente
apartado 2.5 Control de Calidad.
DP llevará el seguimiento de la entrega, y será el intermediario entre el Cliente, los equipos y las
revisones técnicas de la OAC.
La OAC irá detectando incidencias (en el código o en los documentos) y se las irá enviando al equipo
correspondiente para que las vaya corrigiendo. Los equipos responsables reentregarán los ficheros y documentos corregidos para que la OAC vuelva a revisarlos.
Típicamente, se utilizará una plataforma de subida y descarga de archivos, en la cual se señalizará el
estado de cada entregable: diferenciando si está pendiente de revisión, revisado, reentregado, rechazado, en progreso, etc. De esta manera, el tráfico de archivos entre la OAC y el resto de equipos será más
fluido, y si es necesario comunicar algo de más envergadura, se usarán plataformas como el correo
electrónico o chats internos.
En el siguiente apartado describiremos el cierre de la fase CSI (la ejecución de las pruebas) y toda la fase
CEI (Certificación e Implantación del Sistema), también conocida como IAS (Implantacion y Aceptacion
del Sistema), en la cual se describen las revisiones técnicas que la OAC ha ido realizando durante todas
las partes del proceso software.
Descripción específica del sistema
44
44
2.6 Control de Calidad
En esta sección, se describirá mayoritariamente la fase CEI / IAS, en la cual se certificará, implantará y validará la aplicación. La mayor parte de las labores de la fase CEI las realiza la OAC. La OAC ha estado
realizando tareas de certificación y revisiones técnicas durante las etapas anteriores del proceso, todas
ellas pertenecen a la fase CEI.
Según la ISO 9000:2000, la calidad se define como “grado en que un conjunto de características
inherentes cumple con unos requisitos”. El Aseguramiento de la Calidad pretende dar confianza en que el
producto reúne las características necesarias para satisfacer todos los requisitos del Software.
Una organización orientada a la calidad promueve una cultura que da como resultado comportamientos,
actitudes, y actividades y procesos para proporcionar valor mediante el cumplimiento de las necesidades
y expectativas del Cliente.30
La calidad de los entregables y servicios de una organización está determinada por la capacidad para satisfacer al Cliente, y no sólo incluye su función y desempeño previstos, sino también su valor percibido
y el beneficio para el Cliente.
Para asegurar la calidad de los entregables resultantes la OAC deberá realizar un conjunto de actividades que servirán para:
31
- Reducir, eliminar y lo más importante, prevenir las incidencias de calidad de los entregables a obtener.
- Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario queden satisfechas.
El grupo de aseguramiento de calidad participa en la revisión de los productos seleccionados para
determinar si son conformes o no a los procedimientos, normas o criterios especificados, siendo
totalmente independiente del equipo de desarrollo. Las actividades a realizar por la OAC vienen gobernadas por el plan de calidad descrito en la oferta. Sus funciones están dirigidas a:
- Identificar las posibles desviaciones en los estándares aplicados, así como en los requisitos y
procedimientos especificados.
- Comprobar que se han llevado a cabo las medidas preventivas o correctoras necesarias.
Las revisiones son una de las actividades más importantes del aseguramiento de la calidad, debido a que
permiten eliminar defectos lo más pronto posible, cuando son menos costosos de corregir.
Para revisar cualquier entregable, la OAC crea una serie de “Plantillas”, a las cuales deberán adaptarse los entregables recibidos. Estas plantillas reflejan lo que debería ser un “entregable perfecto”. Además,
con su creación, se acelera el proceso de certificación para posteriores entregas, ya que deberán adaptarse
a la misma plantilla.32
El objetivo principal de la fase CEI es certificar la entrega. Una entrega certificada es aquella que, tras
superar satisfactoriamente las revisiones técnicas de la OAC ha quedado completamente validada y
verificada. Una entrega certificada por Calidad es apta para su uso.
30 Referencia a la norma UNE EN ISO 9000 2015 31 Referencia a la norma METRICA V.3, ‘Aseguramiento de la Calidad’ 32 Basado en MÉTRICA v.3, modelo SAC, Objetivos del Sistema de Aseguramiento de la Calidad
45
45 Proceso de Calidad en Ingeniería del Software
2.6.1 Pruebas
Un elemento clave de la certificación de Calidad es la ejecución de pruebas. Las pruebas, según la ISO
IEC IEEE 2911933
, son actividades mediante las cuales se verifica y valida el software en todos sus aspectos, comprobando que se cumplan todos los requisitos de la fase ASI.
La información de este apartado toma como referencias los apuntes de la asignatura „Ingeniería de
Software‟, la norma ISO IEC IEEE 29119 con sus 5 partes, la normativa de MADEJA y MÉTRICA v.3, modelo SAC „Proceso de pruebas‟. Debido a la aún presente disconformidad de nomenclatura y
definiciones en conflicto referentes a las pruebas según las anteriores referencias y las normas IEEE 829,
IEEE 1008, BSI 7925-1 y 7925-2, ISO/IEC 12207 y ISO/IEC 15289, he optado por seguir la
nomenclatura de las pruebas y la definición y momento de ejecución de cada tipo de prueba según como se hacía en nuestro equipo OAC de departamento de Calidad en everis.
Según MADEJA34
, en cada una de las fases anteriores se ha ido elaborando el plan de pruebas específico
que se corresponde con la sección en la que se elabora. De manera que:
En la sección de Definición del Proyecto y realización del DDR se habrá elaborado el Plan de Pruebas de
Aceptación, que servirá como guía a los usuarios finales para probrar las funcionalidades.
En la sección de Diseño y Codificación, se habrá elaborado el Plan de Pruebas Unitarias, Plan de Pruebas
de Integración, Plan de Pruebas Funcionales y Plan de Pruebas No Funcionales, los cuales marcarán las pautas para probar el software en los distintos niveles de prueba.
Los niveles de prueba definen el grado en el que se prueba la aplicación. Como el proceso de pruebas se
define como un proceso donde se va probando inicialmente lo de más bajo nivel y se van integrando y probando paulatinamente componentes hasta lograr un sistema completo, hallaremos 3 niveles de pruebas
bien diferenciados:
Nivel de Unidad, (Pruebas de Unidad), en el cual se verifica el diseño y la programación correcta,
y el correcto funcionamiento de cada componente de código por separado. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado.
Nivel de Integración, (Pruebas de Integración), en el cual los componentes y módulos separados
se ensamblan y se prueban como un conjunto. Se deberán definir los casos de pruebas que
comprueben la integración entre los módulos del sistema, especificando la relación de los
componentes a probar, así como lo datos de entrada y la salida esperada.
Nivel de Sistema, (Pruebas de Sistema), en el cual se prueba la aplicación como un todo. Serán
las pruebas que validan las funcionalidades finales descritas en el DDR, una vez todo el software
y todos los componentes del sistema han sido probados y se intregran juntos.
La OAC será la encargada de realizar la mayoría de las pruebas, exceptuando las de aceptación y las unitarias, y, en el caso de que detecte incidencias, se lo comunicará al equipo correspondiente para que las
corrija. Para ello, hará uso de varias herramientas CASE (consultar sección 3.Herramientas CASE).
Encontramos 2 tipos de pruebas según la ejecución o no del software:35
33 La ISO IEC IEEE 29119 consta de 5 partes, publicadas en 2013, 2015 y 2016. 34 Apoyado por la información de MADEJA, Junta de Andalucía, ‘Creación y Evolución de Sistemas’ en:
http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/creacion-y-evolucion-sistemas y http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/227 35 Información basada en Wikipedia https://es.wikipedia.org/wiki/Pruebas_de_software y en la ISO IEC IEEE 29119
Descripción específica del sistema
46
46
2.6.1.1 Pruebas Estáticas
Para realizar las pruebas estáticas no se necesita ejecutar la aplicación. Estas pruebas se refieren a la
revisión técnica documental que la OAC debe realizar con cada documento y fichero de código de cada una de las fases del proceso software.
Las pruebas estáticas que realiza la OAC se resumen por un lado en la revisión técnica del DDR (en la
fase ASI), del DAO y PP (en la fase DSI) y del MIC y MUS (en la fase CSI).
Por otro lado, se resumen en la corrección formal de los ficheros de código, ya sean de SFW o de SCR.
Es decir, se comprueba (ya sea manualmente o con el uso de herramientas que analizan el código) que la
codificación sigue la normativa establecida y responde ante indicadores de calidad y de programación ordenada, entre otros, dando lugar a un código limpio, comprensible y reutilizable.
Una herramienta útil utilizada por mi equipo en el departamento de Calidad es Mantis Bug Tracker36
(Para más información, consultar sección 3.Herramientas CASE). Mantis es una herramienta que permite
llevar un control y seguimiento compartido entre OAC, DP y Desarrollo de las incidencias encontradas durante las pruebas estáticas. La OAC sube a la plataforma de Mantis las incidencias, organizadas por
códigos y denominadas según la gravedad, el documento o fichero al que hacen referencia y la versión del
entregable en el que se encuentran y/o corrigen. El equipo pertinente accede a Mantis, encuentra la incidencia que le afecta, y la corrige, notificando a la OAC de la corrección realizada y enviándole de
nuevo el documento o fichero.
En la sección 2.6.2 Incidencias, se describe detalladamente cada uno de los indicadores de calidad que la
OAC tendrá que comprobar que se cumplen en los documentos realizados, así como los ficheros codificados, con su correspondiente incidencia y grado de gravedad.
2.6.1.2 Pruebas Dinámicas37
Las pruebas dinámicas son aquellas en las cuales es necesario ejecutar la aplicación. Podemos dividir las
pruebas dinámicas en 2 grandes grupos según el aspecto que verifican:
Pruebas funcionales: Son las pruebas que comprueban que se cumplan los requisitos funcionales
definidos en la fase ASI en la aplicación. Es decir, se comprobará que todas las funcionalidades
de la aplicación exigidas en el DDR están presentes en la aplicación, y todos los casos de uso definidos en las fases anteriores existen y se corroboran.
Pruebas no funcionales: Son las pruebas que comprueban que se cumplan los requisitos no
funcionales definidos en la fase ASI en la aplicación. Existirá un tipo de prueba por cada tipo de
requisito no funcional definido, de manera que las pruebas de seguridad comprobarán que se cumplen los requisitos de seguridad, las pruebas de usabilidad comprobarán que se cumplen los
requisitos de usabilidad, etc.
Como resultado de las pruebas dinámicas, la OAC elaborará un informe que describiremos en detalle en la sección 2.6.4 Informes de Calidad. Todas las pruebas las realizará la OAC exceptuando las de
Aceptación (Alfa y Beta), que serán ejecutadas por el RAU o los usuarios finales, y las unitarias, que
serán ejecutadas por Desarrollo en paralelo a la codificación.
36 Web de la herramienta Mantis Bug Tracker: https://www.mantisbt.org/ 37 Basado en la información dada por MÉTRICA v.3, modelo SAC, ‘SAC002I_GCP-GESTIÓN DE LA CALIDAD_0200’
47
47 Proceso de Calidad en Ingeniería del Software
Algunas herramientas software útiles para la realización de las pruebas dinámicas usadas en mi empresa son: SoapUI, WinSCP, TOAD y Notepad++ para la edición de texto.
38 (Para más información, consultar
sección 3.Herramientas CASE).
A continuación, describimos detalladamente todos los tipos de pruebas.
38 Web de las herramientas de testing,
SoapUI: https://www.soapui.org/
WinSCP: https://winscp.net/eng/index.php TOAD: https://www.toadworld.com/downloads
Notepadd++: https://notepad-plus-plus.org/
Descripción específica del sistema
48
48
Tabla 17. Tipos de Pruebas39
TIPOS DE PRUEBAS
TIPO NOMBRE
REQUISITOS
QUE
PRUEBAN
DESCRIPCIÓN
FUNCIONAL
DE UNIDAD CU
Se encargan de probar los módulos de código por
separado (en el caso de java, probar las distintas clases
individualmente), garantizando el correcto
funcionamiento de cada uno sin integrarse con el resto.
DE INTEGRACIÓN CU
Prueban los diferentes módulos de la aplicación
integrados. La necesidad de realizar las pruebas de
integración viene dada por el hecho de que los módulos
que forman un programa suelen fallar cuando trabajan
de forma conjunta, aunque previamente se haya
demostrado que funcionan correctamente
individualmente en las pruebas de unidad.
DE SISTEMA
TODO TIPO
DE
REQUISITOS
Las pruebas de sistema son aquellas que prueban el
sistema por completo como un todo, ya sea a nivel de
funcionalidades y de que se cumplan los casos de uso,
como a nivel técnico y que se cumplan todos los requisitos no funcionales.
*Gran parte de las pruebas no funcionales se realizan
como parte de las pruebas de sistema.
DE REGRESIÓN CU
Se trata de pruebas que se repiten al introducir alguna
actualización o cambio al software. Una mala gestión
del control de versiones, puede llevar a que la
modificación de un aspecto de la aplicación pueda
provocar fallos en partes donde antes no los había. El
objetivo de estas pruebas es volver a probar aspectos
que ya se habían probado anteriormente para descubrir
posibles fallos al introducir modificaciones.
DE HUMO CU
Pruebas rápidas y sencillas a nivel superficial que se
encargan de localizar las incidencias que afectan de
manera más directa al correcto funcionamiento de la aplicación y/o que impiden la correcta realización de
otras pruebas.
DE ACEPTACIÓN (ALFA)
CU
Primera fase de las pruebas de usuario, se trata de
pruebas que el usuario realiza en el entorno de
certificación mientras se realizan el resto de pruebas,
en caso de que el usuario detecte elementos que
necesita que se cambien a un nivel temprano de la fase
de pruebas y se pueda corregir pronto antes de seguir.
DE ACEPTACIÓN (BETA)
CU
Segunda fase de las pruebas de usuario, en la cual los
usuarios finales prueban la aplicación en el entorno de
Cliente, en un escenario más real y fiel al uso que se va
a hacer del software.
39 Información contrastada entre nuestra experiencia en everis, normativas ISO, IEEE y BSI anteriormente comentadas, apuntes de
Ingeniería de Software y enlaces a Wikipedia y MADEJA, Junta de Andalucía.
49
49 Proceso de Calidad en Ingeniería del Software
DE DESPLIEGUE RE Y RF
Comprueban que el software implantado en un
determinado entorno funciona correctamente a nivel de
ambiente operativo.
NO FUNCIONAL
DE SEGURIDAD RS
Verifican que las medidas de seguridad implantadas en el software funcionan frente a ataques reales,
sometiendo a la aplicación a diferentes amenazas
controladas.
DE MANTENIBILIDAD
RM
Verifican que la aplicación se pueda actualizar de
manera sencilla cuando surja la necesidad de realizar
cambios en ella, se necesiten añadir funcionalidades
surgidas de nuevas necesidades del Cliente o modificar
aspectos en el futuro en nuevas entregas.
DE INTERFAZ RI
Verifican que la comunicación con sistemas externos
sea adecuada y sin errores (diferenciando bien los
factores que afectan a nuestra aplicación y no los de las
aplicaciones terceras con las que necesite
comunicarse).
DE USABILIDAD RU
Verifican que las necesidades de accesibilidad,
facilidad de uso de la aplicación y la interacción
software-cliente sean óptimas y se ajusten a las definidas en los Requisitos de Usabilidad.
DE ESFUERZO O ESTRÉS
RR
Pruebas que fuerzan el sistema al máximo de sus
capacidades software y hardware, para comprobar si la
respuesta esperada es la correcta o descubrir posibles
situaciones que causen estabilidad que no se hubieran
descubierto de otro modo.
DE RENDIMIENTO
Pruebas que verifican que el sistema tiene un tiempo de
respuesta y consumo de recursos óptimos, probando
con todas las combinaciones posibles asegurando el
nivel de servicio esperado.
DE FIABILIDAD
RFI
Verifican la tolerancia a fallos del software y su
correcto comportamiento ante diferentes situaciones,
esperado según las necesidades descritas en los
Requisitos de Fiabilidad.
DE
RECUPERACIÓN
Provoca el fallo del sistema de todas las maneras
posibles, para garantizar que la recuperación de la
aplicación se corresponde con lo definido en los Requisitos de Fiabilidad.
Descripción específica del sistema
50
50
2.6.2 Incidencias
Un elemento clave de la certificación de Calidad es la detección de incidencias. Esta parte se corresponde
con la ejecución de las Pruebas Estáticas, ya que se resumen en la corrección formal de documentos y ficheros de código, como explicaremos más adelante. Dichas incidencias pueden clasificarse
resumidamente según su gravedad:
Tabla 18. Tipos de Incidencias según su gravedad
TIPOS DE INCIDENCIAS SEGÚN LA GRAVEDAD
BAJA MEDIA ALTA
Incidencias ligeras, que no cumplen
algún parámetro de calidad menor.
Pueden admitirse sin afectar a la
correcta funcionalidad de la
aplicación o la comprensión de los
documentos.
Suelen consistir en no respetar el
formato de los documentos, líneas
confusas en el código o comportamientos inesperados, pero
sin importancia, en la aplicación.
Incidencias que dificultan la
correcta funcionalidad de la
entrega. Un entregable con 3 (u otra
cifra convenida por la OAC) o
menos incidencias medias puede
superar satisfactoriamente las
revisiones técnicas de la OAC.
Suelen consistir en warnings en la
compilación, o pequeña alteración de algún RF, faltas de secciones en
los documentos, etc
Incidencias que impiden el
correcto funcionamiento de la
entrega, y necesitan ser
obligatoriamente corregidas.
Suelen ser fallos de código, el no
cumplimiento de algún RF,
documentos erróneos o vacíos, y
fallos en la aplicación
Las referencias de esta sección de incidencias pertenecen en su mayoría a MÉTRICA v.3.40
Estas incidencias quedarán registradas en una plataforma compartida entre los diferentes equipos y
Calidad, a la que todos tendrán acceso para solventarlas de la manera más eficiente. Habrá ocasiones en las cuales dichas incidencias tengan que ser solucionadas por Diseño, Desarrollo, DP, despliegue o
incluso por Cliente.
A continuación veremos los patrones de Calidad que tienen que cumplir los documentos y los entregables uno por uno, prestando especial atención a las incidencias altas.
40 MÉTRICA v.3, modelo SAC, Normativa Técnica, Indicadores de Certificación.
51
51 Proceso de Calidad en Ingeniería del Software
2.6.2.1 Documentos
2.6.2.1.1 DDR
Tabla 19. Certificación DDR
CERTIFICACIÓN DDR
SECCIÓN
DEL
DOCUMENTO
INDICADOR DE CALIDAD GRAVEDAD
2.1 Objetivos El objetivo del sistema describe el alcance o propósito del mismo (qué es
y para qué sirve), aunque sin llegar a detallar sus funciones generales. ALTA
2.2 Características
Principales
La descripción de funciones generales del sistema es completa, se cubren
todas las necesidades del cliente que hayan sido identificadas. ALTA
Se describe la funcionalidad del Sistema sin entrar en detalles de bajo
nivel ALTA
La descripción de funcionalidad debe cubrir las necesidades y
expectativas de los usuarios finales. ALTA
Si se incluye la descripción global de la arquitectura, se justifican las
razones para su selección ALTA
La descripción de funcionalidad general o descripción global de la arquitectura identifica las relaciones del sistema con otros sistemas.
ALTA
2.3 Restricciones Generales
Si existen restricciones, suposiciones o dependencias importantes que puedan condicionar las soluciones de diseño del sistema están incluidas.
ALTA
3. Requisitos del
Sistema
La descripción de los requisitos no es ambigua. ALTA
Todos los requisitos están codificados según un mismo estándar de
nomenclatura ALTA
Las fuentes de información que hayan contribuido a la especificación de
requisitos están claramente identificadas. BAJA
Dentro del apartado 'Requisitos de Seguridad' debe indicarse si la
aplicación debe estar sujeta a la LOPD (Ley Orgánica de Protección de
Datos) o LSSI (Ley de Servicios de la Sociedad de la Información).
ALTA
En los requisitos (preferentemente en RE o RI) deben quedar claramente
descritos todos los sistemas con los que la aplicación se relaciona y en
qué forma.
ALTA
Los requisitos funcionales no hacen referencia a cuestiones técnicas de
diseño, salvo que realmente se consideren como condicionantes. BAJA
Los requisitos se encuentra correctamente codificados y clasificados
según su categoría ALTA
No hay dos requisitos distintos con un mismo código. ALTA
Se describen los niveles de seguridad que deben aplicarse al sistema. BAJA
Descripción específica del sistema
52
52
4. Matrices de
Trazabilidad
Se ha representado la matriz de trazabilidad incluyendo todos los
requisitos descritos en el documento. ALTA
Al menos el 90% de los requisitos pueden ser validados. ALTA
Se indican claramente aquellos requisitos de igual o distinta categoría
que estén relacionados entre sí (p.e.: un requisito operativo que afecta a
varios requisitos funcionales).
ALTA
2.6.2.1.2 DAO
Tabla 20. Certificación DAO
CERTIFICACIÓN DAO
SECCIÓN
DEL
DOCUMENTO
INDICADOR DE CALIDAD GRAVEDAD
2.1 Elementos de la infraestructura
Se describen los elementos de la infraestructura del sistema relativos al
hardware, software y comunicaciones necesarios para explotar el
sistema
MEDIA
Se detallan las medidas de seguridad MEDIA
2.2 Restricciones
Técnicas
Si aplica, se describen las restricciones técnicas en base a la
infraestructura tecnológica del sistema MEDIA
2.3 Planificación
de Capacidades
Se describen la planificación de capacidad necesaria para
almacenamiento, procesamiento y comunicaciones. MEDIA
3.1 Niveles de
Arquitectura
En el caso de que se haya dividido el sistema, se han identificado
claramente las diferentes partes del mismo, presentando un diagrama y
detallando las interfaces que les afectan.
ALTA
En el caso de que se haya dividido el sistema, se han identificado los
objetos comunes. MEDIA
En el caso de que se haya dividido el sistema, las representaciones
gráficas de las partes del mismo siguen todas un mismo formato. MEDIA
En el caso de que se haya dividido el sistema, cada parte del sistema se
ha identificado debidamente. MEDIA
3.2 Casos de Uso Se describen los casos de uso en base a los requisitos establecidos por el
usuario. MEDIA
3.3 Clases
El diseño esta realizado en coherencia con la información del sistema concebido en la fase de Análisis.
ALTA
Los gráficos del Diagrama de Clases contienen un conjunto de gráficos encadenados que recogen las relaciones de diseño entre las clases del
sistema.
MEDIA
El diseño de Clases incluye interfaces de comunicación con los sistemas
externos al sistema en estudio. MEDIA
53
53 Proceso de Calidad en Ingeniería del Software
El diagrama de clases refleja la relación con la Base de Datos y la
interfaz gráfica. MEDIA
Se han identificado los componentes ya existentes y reutilizables. BAJA
Se ha documentado detalladamente cada una de las Clases indicando la
descripción de la clase, su tipo, herencia e información relevante sobre
ella (interfaz, componente reutilizado, etc.)
ALTA
Para cada clase se ha documentado detalladamente sus atributos más significativos indicando su descripción, tipo y restricciones.
MEDIA
Para cada clase se ha documentado detalladamente cada uno de sus métodos indicando su descripción, tipo, restricciones, visibilidad y
lógica.
MEDIA
Se definen las interfaces con otros sistemas y entre los subsistemas de
la aplicación. ALTA
4.1 Interfaz de Usuario
Cada caso de uso se presenta con un gráfico de navegación de las
interfaces gráficas de usuario, conectadas por flujos de navegación, un
inventario de los objetos que contiene el diagrama y una descripción de
la navegación.
MEDIA
Para cada una de las interfaces gráficas de usuario representadas, se
muestra su diseño mediante un prototipo de interfaz de pantalla gráfica.
Se incluirán informes, mensajes de error y otro tipo de información
relevante.
MEDIA
Se presenta un catálogo de controles y elementos de diseño de la interfaz
del sistema, donde se recoge la operatividad de la misma. BAJA
Cuando proceda, por cada informe definido, se presenta el formato de
impresión, conteniendo el tipo y tamaño de letra a utilizar y tipos de
impresora a usar.
BAJA
4.2 Interfaz con
otros Sistemas
Se detallará la interfaces con otros sistemas, indicando los datos y el
formatos de los mismos que se van a transferir entre los sistemas. MEDIA
5. Modelo Físico
de Datos
Si se representa, el modelo Físico deberá coincidir con la descripción de
sus elementos. (Los elementos pueden haberse descrito a continuación o ser adjuntados en un archivo).
MEDIA
2.6.2.1.3 MIC
Tabla 21. Certificación MIC
CERTIFICACIÓN MIC
SECCIÓN
DEL
DOCUMENTO
INDICADOR DE CALIDAD GRAVEDAD
1. Descripción del
cambio/problema
Se ha introducido una descripción de alto nivel de los
problemas/cambios junto con la solución adoptada. MEDIA
Descripción específica del sistema
54
54
2. Recursos
Extraordinarios
Si existen recursos extraordinarios para la instalación de la entrega, éstos
se han especificado de forma clara y concisa. ALTA
3.1 Requisitos Previos
Si es necesario coordinar la instalación de la entrega con alguna otra,
ésta se ha identificado de forma clara y concisa. ALTA
Se indica si es necesario desconectar a los usuarios para realizar la
instalación. ALTA
Se indica si es necesario realizar un backup del esquema de la aplicación previo al proceso de instalación.
ALTA
Se indica si es necesario realizar un backup del software de la aplicación previo al proceso de instalación.
ALTA
Si es necesario salvaguardar datos de la configuración actual de la
aplicación para utilizarlos posteriormente en el proceso de instalación,
éstos han sido especificados de forma clara y concisa.
ALTA
3.2 Procedimiento
de Instalación
Los pasos del procedimiento de instalación se identifican mediante un
secuencial único y la tabla está ordenada por dicho campo. ALTA
El tipo de tarea se ha especificado correctamente. MEDIA
La descripción de las tareas a realizar es clara y concisa, sin presuponer
conocimientos previos de la aplicación por parte del técnico que realiza
la instalación.
ALTA
4. Marcha Atrás
Si es necesario eliminar sinónimos públicos para realizar la marcha atrás,
se han indicado sus identificadores de forma correcta. ALTA
Si es necesario eliminar roles para realizar la marcha atrás, se han
indicado sus identificadores de forma correcta. ALTA
Se indica si es necesario restaurar el esquema de base de datos para
realizar la marcha atrás. ALTA
Se indica si es necesario restaurar el software anterior para realizar la
marcha atrás. ALTA
Los scripts a ejecutar para la marcha atrás se han incrustado en el
apartado correspondiente. ALTA
Los pasos de la marcha atrás se encuentran numerados secuencialmente ALTA
Los pasos de la marcha atrás se han especificado de forma clara. ALTA
2.6.2.1.4 MUS
Tabla 22. Certificación MUS
CERTIFICACIÓN MUS
SECCIÓN DEL
DOCUMENTO INDICADOR DE CALIDAD GRAVEDAD
1.1 Objeto Proporciona información suficiente para que el lector pueda BAJA
55
55 Proceso de Calidad en Ingeniería del Software
comprender la función global del sistema dentro de la organización.
1.3 Funcionalidad
En caso de que la aplicación sustituya otros procesos existentes en la
organización, proporciona información suficiente para que el lector
pueda comprender los procesos sustituidos y las diferencias funcionales del nuevo sistema.
MEDIA
Se describen todas las funcionalidades aportadas por el sistema y los procesos involucrados en ella.
ALTA
1.4 Mapa del
Sistema
Se proporciona un resumen general mediante diagramas de formato libre
de la composición del sistema, módulos, entorno, etc que permite al
usuario tener un conocimiento a alto nivel del sistema descrito.
MEDIA
2. Operativa del
Sistema
Se describen todos los procesos (o ventanas) incidiendo en su
descripción y qué acciones permite el sistema realizar con el proceso (o
ventana) descrito.
MEDIA
3.3 Incidencias
Frecuentes
Se enumeran las incidencias más frecuentes y, junto a cada una de ellas,
se ofrece una solución. BAJA
3.4 Mensajes de
Error
Se ofrece una lista con todos los mensajes de error que el sistema ofrece
al usuario, bien sea a través de ventanas o de ficheros de log, y se adjunta
una descripción más extensa para cada uno de ellos.
MEDIA
General El manual está escrito de forma clara y comprensible ALTA
2.6.2.1.5 PP
Tabla 23. Certificación PP
CERTIFICACIÓN PP
SECCIÓN
DEL
DOCUMENTO
INDICADOR DE CALIDAD GRAVEDAD
1. Descripción
General
Se ha realizado una descripción de la funcionalidad completa del sistema, así
del correctivo y/o evolutivo que incluya la entrega ALTA
Se han descrito y codificado claramente los casos de pruebas a ejecutar,
distinguiendo si se corresponden con un correctivo o evolutivo. ALTA
Se han identificado los requisitos asociados a los casos de pruebas.
(Obligatorio en evolutivos y mantenimientos) ALTA
2. Entorno de
Pruebas
Se ha identificado claramente el entorno de prueba necesario, completando
todos los apartados de la plantilla. (Si alguno no aplica, indicar N/A y
explicar la razón)
ALTA
3. Casos
Generales
Se incluyen aquellos casos de prueba que no se corresponden con el objetivo
de la entrega, pero sirven para fijar prerrequisitos u otros. ALTA
Se describe la creación de los usuarios que serán necesarios en los casos de
prueba del documento. ALTA
Descripción específica del sistema
56
56
4. Casos de Prueba
La información de cada caso de prueba especifica con claridad todos los
aspectos necesarios para su realización. ALTA
Se incluye una descripción del caso de prueba. ALTA
Se incluyen los prerrequisitos necesarios para realizar cada caso de prueba. ALTA
Se describen los roles necesarios para ejecutar cada caso de prueba. ALTA
Se incluyen los datos de pruebas necesarios para ejecutar las pruebas ALTA
Si la prueba incluye algún elemento especial, se debe especificar. ALTA
Se indica el tiempo necesario para ejecutar la totalidad del caso de prueba.
(Expresado en minutos) MEDIA
Para cada caso de prueba que se divida en ciclos de prueba, se explicará cada
uno de los ciclos de prueba de forma ordenada por separado. ALTA
Se indica el requisito (o requisitos) que se testea en cada caso de pruebas. Se
debe corresponder con los requisitos del DDR indicados en el apartado de
descripción general.
ALTA
Para cada caso de pruebas se debe especificar el orden de ejecución. Si el
orden es correlativo, se debe indicar como 'Secuencial'. ALTA
2.6.2.1.6 Defectos gene ricos en documentos
Tabla 24. Defectos genéricos en documentos
CERTIFICACIÓN DE LOS DOCUMENTOS EN GENERAL
SECCIÓN
DEL
DOCUMENTO
INDICADOR DE CALIDAD GRAVEDAD
N/A
Ha de comprobarse la coherencia del nombre identificativo del entregable. MEDIA
Ha de comprobarse la coherencia del versionado del entregable. MEDIA
Se han de cumplimentar correctamente todos los campos de la Hoja de
Control. MEDIA
El entregable debe adaptarse a la plantilla definida para el resto de
documentos MEDIA
57
57 Proceso de Calidad en Ingeniería del Software
Se han de respetar todos los estilos definidos en el documento, utilizándolos
en los casos en que sea necesario y sin modificar el formato de los mismos.
En los documentos que se necesite un formato específico se indicará explícitamente.
BAJA
No se deben de realizar modificaciones en el formato del texto, a excepción
de la utilización de negrita y cursiva cuando se desee resaltar alguna palabra
o frase.
BAJA
Cuando un documento anexe información adicional (por ejemplo, el modelo
del análisis realizado con una herramienta CASE), la entrega del documento
ser realizará en un fichero comprimido ZIP que contendrá el documento y el
resto de ficheros organizados en subdirectorios.
BAJA
El índice del documento se encuentra correcto y actualizado en cuanto a
números de páginas. BAJA
Existen descripciones de las convenciones notacionales o acrónimos
empleados. BAJA
Todo documento externo al entregable utilizado para la realización del
mismo debe indicarse correctamente en el apartado de Referencias. BAJA
Cuando un documento no se refiera a la totalidad del sistema, en la
introducción deberá aclararse a qué parte del sistema afecta. BAJA
Descripción específica del sistema
58
58
2.6.2.2 Ficheros de código
2.6.2.2.1 SCR de base de datos
(Nos centraremos en los SCR de base de datos, ya que la revisión técnica del resto de SCR se realizará en las
pruebas de despliegue, sistema, o cuando corresponda).
Tabla 25. Certificación SCR de base de datos
CERTIFICACIÓN SCR DE BASE DE DATOS
INDICADOR DE CALIDAD GRAVEDAD
Los nombres de los scripts deben respetar el formato <nnn>_<nombre>.<ext>, tal como se define
en la normativa técnica correspondiente. Siempre, aunque sea un solo Script. ALTA
Las sentencias para la creación de sinónimos públicos, los cuales permiten el acceso a un objeto
por parte de cualquier usuario (siempre que se tengan los permisos necesarios) se entregan dentro
de archivos con extensión ".syn".
ALTA
Los sinónimos públicos se crean mediante la orden "CREATE" y nunca con "CREATE OR
REPLACE". ALTA
No se permite la concesión del permiso GRANT CREATE SESSION en los scripts, sino que debe
estar convenientemente documentado en el Manual de Instalación y Configuración. ALTA
Ningún script que forme parte de una entrega llama o ejecuta otro script SQL almacenado en
archivo. ALTA
Los scripts entregados deben ejecutarse correctamente en entornos UNIX desde línea de comando
mediante SQLPLUS. ALTA
No se permite la petición de parámetros durante la ejecución de los scripts de base de datos. ALTA
Se deben generar los mensajes informativos mediante la utilización de PROMPT o
dbms_output.put_llne suficientes en la salida estándar durante la ejecución de los scripts, que
indiquen qué operación se va a realizar a continuación, conforme a lo descrito en la normativa
técnica.
MEDIA
Se debe utilizar de forma adecuada el valor del parámetro INITIAL en la creación de las tablas e índices, para aquellas entidades sobre las que se conozca su tamaño inicial aproximado,
especialmente cuando existe un proceso de migración que cargará los datos.
ALTA
En las cargas y migraciones masivas de datos, deben desactivarse previamente los índices sobre las
tablas en las que se van a introducir los datos. ALTA
En las cargas y migraciones masivas de datos, se introducen los COMMIT necesarios para no
generar transacciones anormalmente grandes que sobrecarguen el segmento de ROLLBACK de la
base de datos.
ALTA
Las sentencias para la eliminación de sinónimos públicos se entregan únicamente dentro del MIC ALTA
59
59 Proceso de Calidad en Ingeniería del Software
2.6.2.2.2 SFW
(El software consiste en ficheros Java, que constituyen aplicaciones completas o web services „servicios web‟).
Tabla 26. Certificación SFW
CERTIFICACIÓN SFW
INDICADOR DE CALIDAD GRAVEDAD
Aplicaciones en 3 capas: Presentación, Negocio y Datos MEDIA
El desarrollo de una aplicación debe ser independiente del sistema operativo. ALTA
El software debe ser independiente de la arquitectura de ejecución de tal manera que no requiere ningún tipo de configuración para su instalación
ALTA
La integración entre varias aplicaciones web ha de implementarse mediante servicios web. MEDIA
Se recomienda el uso de Hibernate para la conexión a BBDD o en su defecto cap.webcap.sql.ConnectionFactory
BAJA
La información interna de la aplicación, como los datos que maneja, usuarios, etc, se almacena en BBDD y no en ficheros
ALTA
Las conexiones realizadas a BBDD deben cerrarse
automaticamente apenas dejen de usarse. No se pueden quedar conexiones abiertas. ALTA
No se admite el uso de Applet MEDIA
Como criterio de diseño se recomienda utilizar interfaces en vez de clases BAJA
Evitar definir funciones JavaScript en una página web. MEDIA
Evitar JSP que usen directamente tablas de BBDD ALTA
Evitar JSP que usen directamente procedimientos o funciones de BBDD.
ALTA
Evitar el uso de paquetes no estándares de Java (sun.*) BAJA
En el mismo paquete solo se puede heredar de clases de nivel superior BAJA
Las SuperClases no deben conocer nada de las SubClases. MEDIA
Los paquetes no deben presentar un exceso o defecto de clases/interfaces BAJA
Evitar clases que implementan demasiadas interfaces. BAJA
Evitar sobreescribir métodos estáticos. BAJA
Evitar sobreescribir atributos. BAJA
Evitar clases que directamente heredan de java.lang.throwable. BAJA
Proporcionar accesos para los campos privados de la clase. BAJA
Evitar clases que hacen referencia a objetos de la BBDD. MEDIA
Descripción específica del sistema
60
60
Una clase no debe tener atributos públicos a menos que sean declarados como final o static final. BAJA
Empaquetado de ficheros Java: Todos los componentes Java que contiene una aplicación se deben
empaquetar por aplicación utilizando la directiva package MEDIA
La funcionalidad de las JSPs utilizada sólo incluirá la capa de presentación de la aplicación MEDIA
No se debe utilizar el código JavaScript para realizar tareas de presentación, sino únicamente como
mecanismo de validación de datos (fechas, tipos de datos, etc.). MEDIA
La aplicación consta de 2 usuarios a nivel de BBDD, uno es el propietario del esquema y el otro es
el usuario que se utiliza para acceder. ALTA
Encapsular la seguridad en una sola clase Java BAJA
No confiar las medidas de seguridad en código ejecutado en cliente (JavaScript, VBScript) ALTA
No utilizar los campos ocultos de un HTML para programar criterios de seguridad MEDIA
No utilizar el metodo GET para enviar información sensible como por ejemplo contraseñas, utilizar
el método POST MEDIA
Convertir todas las salidas generadas según la codificación HTML apropiada:
- > en >
- < en < - etc.
MEDIA
Mantener actualizados los servidores web y programas relacionados (PHP, librerías gráficas, etc.) MEDIA
No habilitar servicios innecesarios MEDIA
Minimizar los datos almacenados en cada sesión MEDIA
Los usuarios de BD de la aplicación deben tener los permisos necesarios ALTA
Mostrar al usuario información utíl en los mensajes de error, no mostrando información innecesaria MEDIA
Se debe registrar de forma interna los errores producidos para detectar posibles ataques BAJA
No proporcionar acceso total a todo el directorio de publicación web. MEDIA
No permitir objetos con alto Fan-In.(Objetos java que referencian a más de 5 parámetros) MEDIA
No permitir clases con una gran falta de cohesión MEDIA
No permitir objetos con alto Fan-Out.(Objetos Java que son referenciados por más de 5
parámetros) MEDIA
No permitir un alto acoplamiento entre clases MEDIA
Evitar demasiada respuesta para una clase MEDIA
Evitar objetos con una alta complejidad de integración MEDIA
Evitar clases con una alta carencia de cohesión 2 MEDIA
Evitar clases con un alto número de hijas MEDIA
61
61 Proceso de Calidad en Ingeniería del Software
Evitar clases un alto Ratio de Public Data MEDIA
El software debe contener únicamente las librerías propias de la aplicación, excluyendo las librerías
de JAVA y del intérprete de compilación. ALTA
No deben existir clases duplicadas en el CLASSPATH MEDIA
La configuración de carga de clases en el servidor debe estar definida en un archivo y su
comportamiento debe estar documentado. ALTA
No se utilizarán procedimientos almacenados java en Oracle ALTA
2.6.2.2.3 Defectos gene ricos en co digo
Tabla 27. Defectos genéricos en código
CERTIFICACIÓN DEL CÓDIGO EN GENERAL
INDICADOR DE CALIDAD GRAVEDAD
La función que llama a un Form debe estar centralizada. BAJA
Evitar las Querys en las que participan demasiadas tablas. MEDIA
Evitar tener Joins con demasiadas tablas MEDIA
Evitar tener código PL/Sql en los triggers llamados "pre-record". MEDIA
Evitar los triggers de ratón, timer. Las validaciones en Forms debe realizarse a nivel de bloque de
datos. MEDIA
El uso conjunto de Distinct y Group by es redundante. MEDIA
Evitar el Uso de Rownum para limitar el número de registro en la consulta
o cursores. MEDIA
Recorrer colecciones utilizando FIRST, LAST, NEXT MEDIA
Evitar el uso de NULL o NOT NULL en las condiciones de las consultas ya que desactivan los
índices y hacen más lenta la consulta. MEDIA
No utilizar funciones sobre las columnas indexadas, ya que inhabilita el indice. MEDIA
Uso de Exist e IN de forma eficiente. MEDIA
Descripción específica del sistema
62
62
No se permite el uso de funciones de agrupación: MAX, MIN, COUNT, SUM BAJA
La funcionalidad de los FORMS debería estár en el servidor para la mejora del rendimiento
(Paquetes, Procedimientos, etc.). Al ejecutar las funciones el servidor, la aplicación es más
eficiente.
MEDIA
Evitar el uso de GOTO en Pl/Sql. ALTA
Los Triggers no deben acceder a tablas directamente,
solo a través de procedimiento. MEDIA
Los Triggers no deben modificar los datos de una tabla. MEDIA
Para realizar la conexión a la BBDD de la aplicación no debe existir un único usuario. MEDIA
La aplicación debe gestionar los roles de usuarios. MEDIA
Todos los sinónimos de BBDD deben ser públicos MEDIA
No asignar a los usuarios más permisos de los necesarios. ALTA
Mostrar al usuario información útil en los mensajes de error, no mostrando información innecesaria BAJA
Registrar de forma interna los errores producidos para detectar posibles ataques BAJA
El almacenamiento de la seguridad se debe cifrar mediante algoritmos hash BAJA
Cambiar contraseña cada cierto tiempo. Para realizar el cambio de contraseña debe solicitar la que
está vigente MEDIA
Se debe requerir autentificación entre componentes. MEDIA
No definir los usuarios y contraseñas por defecto MEDIA
Encapsular la seguridad en un solo paquete o procedimiento pl-sql. BAJA
Evitar usar más de una instrucción por línea. BAJA
Las funciones no deben tener demasiadas líneas de código. BAJA
63
63 Proceso de Calidad en Ingeniería del Software
La cláusula WHEN OTHERS debe estar presente en las excepciones. ALTA
Evitar tener demasiadas columnas por tabla. MEDIA
Usar el tipo VACHAR2 en vez de Char o Varchar, siempre que no conozcamos la longitud exacta
del char BAJA
Evitar usar EXECUTE. MEDIA
Evitar usar columnas del tipo LONG o LONG RAW. MEDIA
Evitar usar Funciones que no sean referenciadas. ALTA
Evitar las tablas que no son referenciadas. ALTA
Utilizar %TYPE o %ROWTYPE para definir variables asociadas a
columnas de tablas. MEDIA
Utilizar ELSIF o CASE en vez de varios IF anidados BAJA
Evitar uso de EXIT y RETURN en bucles MEDIA
No utilizar Select * MEDIA
No declarar el índice en bucle FOR BAJA
Utilización de la función NVL siempre que sea posible para evitar futuros errores en las querys MEDIA
Evitar objetos con alta complejidad cyclomática BAJA
Evitar objetos con alta complejidad esencial BAJA
Evitar objetos con alta profundidad en el código BAJA
Evitar objetos con demasiados parámetros BAJA
Evitar objetos con líneas que tengan demasiados caracteres BAJA
Descripción específica del sistema
64
64
2.6.3 Informes de Revisión Técnica (IRT)
A la hora de realizar las revisiones técnicas a los entregables y detectar incidencias, antes de describirlas
en una plataforma compartida (como por ejemplo QM, como veremos más adelante en la sección 3.Herramientas CASE), para hacerle llegar la información a los equipos, será necesario que la OAC
elabore unos documentos denominados Informes de Revisión Técnica (IRT).41
Estos informes tienen como objetivo mostrar las incidencias a corregir de un documento o fichero de una forma ordenada, clara y comprensible. De este modo, cuando la OAC anexe los IRT a la plataforma
compartida de incidencias, el equipo responsable tan solo tendrá que leer dichos informes para localizar
rápidamente las incidencias, y optimizar el proceso de corrección del entregable en cuestión.
Todos y cada uno de los documentos y ficheros de código sometidos a inspección de calidad serán acompañados de su correspondiente IRT. En los IRT, además, se indicará el estado del entregable según el
número y gravedad de las incidencias encontradas, lo cual explicaremos en la siguiente tabla:
Tabla 28. Resultado de evaluación de un entregable
RESULTADO DE LA EVALUACIÓN DE UN ENTREGABLE
SEVERIDAD CANTIDAD RESULTADO DESCRIPCIÓN
Baja 0 - ∞
ACEPTADO
Por muchas incidencias bajas que
se encuentren, el entregable se
considera válido a todos los
efectos.
Se recomienda corregir las
incidencias bajas para optimizar
el resultado final del entregable
Media 0 - 3
Media 3 - ∞ ACEPTADO CON
RESERVAS
Si hay 3 o más incidencias
medias, el entregable se considera
válido.
Sin embargo, la no corrección de
dichas incidencias puede conducir a confusión en el cliente, o a
problemas futuros de categoría
menor.
Alta 1 - ∞ RECHAZADO
Si hay una sola incidencia alta, el
entregable no se considera válido,
y tendrá que ser modificado, y
reentregado de nuevo a la OAC.
41 Bas{ndonos en MÉTRICA v.3, modelo SAC, ‘SAC002P_RDP_Revisión de Documentos_0800’
65
65 Proceso de Calidad en Ingeniería del Software
Cuando un equipo equipo lea el IRT de un entregable, comprobará rápidamente si el entregable está Aceptado, Aceptado con Reservas o Rechazado, y verá las incidencias encontradas clasificadas según la
severidad rápidamente.
En el caso de que un entregable haya sido rechazado, y el equipo responsable haya tenido que corregirlo y reentregarlo a la OAC, esta última elaborará un segundo IRT para el mismo entregable, en el que reflejará
si las incidencias anteriores han sido debidamente corregidas, pudiendo aceptar o aceptar con reservas el
entregable, o rechazarlo de nuevo tantas veces como sea necesario. El resultado final de todos los
entregables siempre deberá ser Aceptado, o como mínimo, Aceptado con Reservas.
Nota*: Cuando un entregable se deja como Aceptado con Reservas, significa que ha habido una
comunicación previa entre RAU, DP y OAC, en la cual el Cliente acepta dicho entregable con las incidencias medias encontradas. Aún así, la OAC siempre velará por la perfección del entregable y
luchará por no detectar ninguna incidencia, sin importar el grado de gravedad.
Además del resultado de la evaluación del entregable y de las incidencias encontradas, un IRT contendrá
típicamente cierta información de control, incluyendo:
Nombre de la aplicación a la que pertenece el entregable
Tipo de entregable revisado
Autor del IRT
Número de versión
Causa del cambio (en caso de haber más de una versión)
Fecha de versión
Responsables de Proyecto
Nombre de DP
Observaciones, otros
Descripción específica del sistema
66
66
2.6.4 Informes de Calidad
Tras revisar todos los entregables, detectar sus incidencias y elaborar sus respectivos IRT, y ejecutar todas
las pruebas, la OAC deberá realizar varios informes, los cuales se añadirán a los entregables finales para el Cliente. Estos informes tienen como objetivo resumir cómo han ido las pruebas, las incidencias que se
han encontrado tanto en SCR como en SFW, y que se pueda tener un resumen rápido de la evaluación de
los ficheros de código. Se entregarán al Equipo de Desarrollo para que corrijan los posibles errores que hayan podido aparecer durante la ejecución de las pruebas dinámicas o estáticas, y envién una nueva
versión a la OAC con las correcciones y pueda probar de nuevo.
Estos informes también pueden resultar de utilidad al Cliente, bien por su posible interés en las pruebas
llevadas a cabo, o curiosidad por la detección de incidencias en una primera instancia por parte de la OAC (Un gran número de incidencias en la primera entrega puede decir mucho del equipo responsable).
A continuación, explicaremos los distintos informes que elaborará la OAC:
2.6.4.1 Informe de Modelo de Datos (MOD)
El MOD es un Informe que se realiza exclusivamente para los SCR. Si una entrega no tiene scripts, la
OAC no realizará este informe. Su objetivo es asegurar que la base de datos cumple con las reglas
establecidas en la normativa técnica vigente. Dicho de otra manera, comprueba que los scripts ejecutados
de la aplicación sigan una serie de requisitos de calidad, orden, numeración, eficiencia, etc.
Para realizar el MOD, se hace uso de varias herramientas de comprobación y análisis de código sql,
lenguaje de programación en el que suelen ir codificados los scripts. Entre los parámetros fundamentales a evaluar, destacamos:
La existencia de objetos inválidos
La comparación entre esquemas de diferentes entornos
Detección de sinónimos inválidos
Cumplimiento de normas técnicas de codificación del script
Como dato extra, se suelen anexar al MOD los logs generados por las herramientas utilizadas, siendo así
de interés para el que reciba este informe y use dichas herramientas.
*Nota: El MOD formará parte del IPC, así que no va a consistir en un entregable final por sí mismo.
67
67 Proceso de Calidad en Ingeniería del Software
2.6.4.2 Informe de Pruebas Estáticas (PES)
El PES es un Informe que se realiza como resultado de las pruebas estáticas al software. Su objetivo es
comprobar que el SFW utilizado cumple con las normas de codificación pertinentes, y que se ha llevado a
cabo una programación ordenada, limpia y comprensible, con vistas a que el código sea revisado y reutilizado con facilidad.
Para elaborar el informe se hace uso de una herramienta llamada Jenkins42
. Jenkins revisa y prueba el
SFW de diversas maneras atendiendo a diferentes criterios, elaborando un informe final de SonarQube. SonarQube es otra herramienta asociada que muestra el número de archivos corruptos e incidencias de
distinta categoría (para más información, consultar sección 3.Herramientas CASE). En el informe se
detallan con precisión todas las incidencias encontradas.
*Nota: El PES formará parte del IPC, así que no va a consistir en un entregable final por sí mismo.
42 Web de referencia de las herramientas software: Jenkins: https://jenkins.io/
SonarQube: https://www.sonarqube.org/
Descripción específica del sistema
68
68
2.6.4.3 Informe de Pruebas de Certificación (IPC)
El IPC es un informe extenso cuyo objetivo es recoger en un único documento todas las pruebas
dinámicas realizadas por parte de la OAC.
Detallamos a continuación la estructura básica del documento IPC:
Tabla 29. Estructura de un IPC
IPC (Informe de Pruebas de Certificación)
SECCIÓN DESCRIPCIÓN
1. INFORMACIÓN
GENERAL
En esta sección se aportan datos generales de la certificación, como pueden
ser el nombre del proyecto, su anagrama, la versión, las fechas de entrega,
reclamación y verificación, y la persona responsable de la certificación.
2. CERTIFICACIÓN DE LA
APLICACIÓN
Apartado que resume las pruebas realizadas por la OAC para la entrega en
cuestión, y el resultado de cada una de ellas.
3. ENTORNO DE PRUEBAS
DE CERTIFICACIÓN
Se indica qué tecnología se ha usado para realizar las pruebas, las versiones
de software y las características principales de hardware, y otros aspectos
técnicos.
4. RESUMEN DE
ENTREGABLES Y
REVISIONES
Pequeña lista de entregables revisados por la OAC, y de entregables realizados por la OAC (se incluye el propio IPC). Se añade el estado de la
revisión y el resultado final de la misma, (si está aceptado, rechazado, o
aceptado con reservas).
5. Pruebas de Despliegue
Las pruebas de despliegue constatan si es posible realizar una instalación
correcta de la entrega a partir de los scripts, software y manual de instalación,
suministrados por la empresa. En definitiva, si se ha podido instalar la
aplicación en el entorno de certificación siguiendo el MIC sin problemas.
En este apartado se recoge el resultado de dichas pruebas, la fecha de
instalación y la persona responsable.
Se realizará una segunda fase de pruebas de despliegue cuando se implante la
aplicación en el entorno de Cliente.
6. Pruebas Funcionales
Esta sección recoge el resultado de la realización de las pruebas funcionales
definidas en los CP del PPF. Se añade de nuevo la fecha de finalización de las pruebas funcionales y la persona responsable.
Se verifica si se cumplen los RF. Se añade también el nombre del PPF
utilizado.
7. Modelo de Datos
Se incluye el MOD generado por la OAC y los logs generados por las
herramientas utilizadas. Se añade una breve enumeración de los objetos
inválidos encontrados y la comparación de los esquemas de desarrollo y de
certificación. Se añade la fecha de realización del MOD y la persona
responsable.
8. Pruebas Estáticas del
Software
Se incluye el PES generado por la OAC y el informe SonarQube generado
por la herramienta Jenkins. Se añade una breve enumeración de los archivos
con incidencias, y errores totales encontrados en los ficheros de código Java.
9. Pruebas de Unidad Esta sección recoge el resultado de la realización de las pruebas de unidad
definidas en en PPU.
69
69 Proceso de Calidad en Ingeniería del Software
10. Pruebas de Integración Esta sección recoge el resultado de la realización de las pruebas de
integración definidas en en PPI.
11. Pruebas de Sistema
Esta sección recoge el resultado de la realización de las pruebas de sistema definidas en en PPS.
Se realizará una segunda fase de pruebas de sistema cuando se implante la
aplicación en el entorno de Cliente.
12. Pruebas de Regresión Describe el resultado de las pruebas de regresión, en especial cuando el
software ya ha sido revisado una primera vez, y se vuelven a probar módulos
que estaban bien que ahora podrían fallar.
13. Pruebas de Humo
Describe el resultado de las pruebas de humo. Este apartado adquiere vital
importancia cuando ha habido fallos bloqueantes en alguna versión del
software entregado a la OAC, ya que en esos casos sólo se realiza un IRT y
no se realiza este IPC. Sin embargo, cuando se elabora el IPC tras la
corrección de los fallos bloqueantes, se enumeran aquí, así como el resultado
de las pruebas de humo ejecutadas para localizarlos.
14. Pruebas No Funcionales
Esta sección recoge el resultado de la realización de las pruebas no
funcionales definidas en el PPNF. Esto incluye el resultado de:
Pruebas de Seguridad
Pruebas de Mantenibilidad
Pruebas de Interfaz
Pruebas de Usabilidad
Pruebas de Esfuerzo / Estrés
Pruebas de Rendimiento
Pruebas de Fiabilidad
Pruebas de Recuperación
15. ANEXOS Se incluyen los anexos necesarios (si aplica) para la ejecución de las pruebas.
Si no es texto, deberá indicarse cómo se llaman los archivos anexos, y
deberán ir adjuntos al IPC comprimidos en un .zip .rar etc.
16. GLOSARIO Sección en la que se definen los anagramas usados y se explican los
acrónimos utilizados.
17. BIBLIOGRAFÍA Y
REFERENCIAS
Apartado en el que consta la información externa utilizada en las pruebas, o documentos de los que ha dependido parte de la certificación.
Este documento IPC43
se anexará a los informes generados (como el MOD y el PES) en un archivo
comprimido (zip, rar, etc), constituyendo un entregable completo para la entrega final realizado enteramente por la OAC. Cuando el equipo de Desarrollo lea este IPC, sabrá instantáneamente dónde se
encuentran las incidencias localizadas por la OAC referentes a todas las pruebas dinámicas. El IPC
también constituye un entregable para el Cliente.
43 Para la definición de la estructura del IPC nos hemos basado en la información aportada por MÉTRICA v.3, modelo SAC,
‘SAC007P_IPC_Informe_de_Pruebas_Certificación_0100’
Descripción específica del sistema
70
70
2.6.4.4 Informe de Pruebas de Aceptación (IPA)
El IPA es un breve informe algo particular, que realiza la OAC después de las pruebas Alfa y Beta de
usuario. El usuario realizará las pruebas alfa y beta a la aplicación (detalladas más adelante) en el entorno
de certificación y en el de cliente. El resultado de estas pruebas se remitirá de nuevo a la OAC para que conste en el denominado IPA.
El IPA incluirá información de la persona responsable que ejecutó las pruebas de usuario, RAU, la fecha,
y el resultado final de las mismas. Este informe se anexará a la documentación pertinente generada por el usuario cliente, o la comunicación establecida entre usuario y OAC para apoyar los resultados de las
pruebas de usuario.
Habiendo realizado todos estos informes, se completa la lista final de entregables resumidos en la
siguiente tabla y clasificados según la fase a la que pertenecen:
Tabla 30. Lista final de entregables
ENTREGABLES
FASE ENTREGABLE CREADOR DESTINATARIO
ASI DDR DP Desarrollo,
OAC y Cliente
DSI
DAO Desarrollo (Diseño) Desarrollo (Codificación),
OAC y Cliente
PP Desarrollo OAC y Cliente
SCR Desarrollo
(Codificación) OAC y Cliente
CSI
MIC
Desarrollo OAC y Cliente
MUS
SFW Desarrollo
(Codificación) OAC y Cliente
CEI
IPC
OAC Desarrollo y Cliente
IPA
71
71 Proceso de Calidad en Ingeniería del Software
Según la norma UNE/ISO/IEC 90003:2005
44, una vez codificado el software y enviado a la OAC, la
OAC realizará todas las pruebas descritas en el PP (exceptuando las de aceptación y unitarias), y generará
el IPC. El IPC se enviará al equipo de Desarrollo y a DP, para que comprueben los errores que han tenido
lugar durante la realización de las pruebas o los aspectos que no se han cumplido, y puedan ponerle solución y mandarle una nueva versión de la aplicación corregida a la OAC.
*Nota: En el caso de que el resultado de las pruebas de humo realizadas por la OAC contenga un error
bloqueante que impida la correcta consecución del resto de pruebas, la OAC lo notificará al equipo de
Desarrollo para que lo corrija. En este caso no se esperará a generar el IPC, sino que se generará un solo IRT con el error localizado.
En el momento en que todas las pruebas del PP se ejecuten satisfactoriamente por la OAC, se dará por finalizadas las pruebas dinámicas por parte de la OAC.
Asimismo, en el momento en que todos los documentos y ficheros de código se encuentran correctos y
han superado satisfactoriamente las revisiones técnicas de la OAC, se dará por finalizadas las pruebas estáticas por parte de la OAC.
En este momento en el que las pruebas estáticas y dinámicas están superadas, el Cliente dispondrá de todo
lo necesario para probar por sí mismo el resultado final de la aplicación a nivel de usuario, dando paso a las
Pruebas de Aceptación.
44 Contrastando a su vez con’ METRICA_V3_Aseguramiento_de_la_Calidad ‘y MÉTRICA v.3, modelo SAC, ‘SAC002P_IAS_Implantacion
y Aceptacion de Sistemas_1300’
Descripción específica del sistema
72
72
2.7 Pruebas de Usuario
Basándonos en la norma ISO/IEC/IEEE 29119 y UNE45
, tras las pruebas de certificación, el RAU debe validar que el software cumple los requisitos funcionales definidos al inicio del proyecto con el fin de
validar su correcto funcionamiento.
En este punto del proceso software, la OAC ya habrá realizado todas las pruebas a la aplicación, tanto dinámicas como estáticas. Ahora le llega el turno al usuario de realizar las pruebas de aceptación,
descritas en el PPA elaborado por la OAC en la fase de definición del proyecto.
Las pruebas de aceptación son aquellas que realizan los usuarios finales pertenecientes a la empresa Cliente, aquellos que utilizarán la aplicación en el entorno Cliente una vez implantada. Su propósito es
verificar los requisitos definidos en el DDR desde el punto de vista de Cliente en lugar de la OAC.
Las pruebas de aceptación se dividen en dos:
2.7.1 Pruebas Alfa
Las pruebas Alfa son aquellas que una representación del usuario final realiza en el entorno de certificación siguiendo el PPA. Durante su ejecución, al ser en el entorno de certificación, la OAC y parte
de otros equipos supervisa dicha ejecución, para recoger los problemas y errores de primera mano del
Cliente en caso de que los detecte.
Según MÉTRICA v.346
, el propósito de estas pruebas es comprobar que la aplicación resulta de agrado
para el usuario final, que cumple con todas las necesidades desde su punto de vista y tomar nota en el
momento de los cambios o modificaciones que el usuario vaya pidiendo durante la ejecución de las
pruebas.
2.7.2 Pruebas Beta
Las pruebas Beta son aquellas que una representación del usuario final realiza en el entorno de Cliente.
Para ello, será necesario que el equipo de despliegue implante la aplicación en el entorno de Cliente,
como se describe en la sección 2.8 Despliegue. Las pruebas Beta se realizan como última comprobación final del software, una vez que las pruebas Alfa han tenido éxito y se han corregido los fallos detectados
durante las misma, o actualizado el software según las necesidades encontradas.
Según MÉTRICA v.3, como en las pruebas Alfa ya el usuario ha probado y dado su punto de vista para introducir modificaciones y validar las funcionalidades, el propósito de las pruebas Beta es comprobar
que la aplicación funciona correctamente en el entorno de Cliente. El entorno de Cliente tiene el hardware
y software reales sobre los que se va a instalar la aplicación, y se deberán repetir las pruebas de sistema y
de despliegue para comprobar que el software funciona como un todo, ofreciendo los resultados funcionales y técnicos esperados.
Al tratarse de un entorno real, el software va a usar unas entradas reales, proporcionando salidas útiles
para el desempeño de los procesos de la empresa Cliente. Es aquí cuando el usuario final prueba finalmente la aplicación en el ambiente en el cual va a usarse en el futuro, dando lugar a una completa
fidelidad de los resultados según unos datos reales.
Normalmente, al tratarse de un cambio frente a la aplicación utilizada anteriormente en el entorno de
Cliente, o el caso de constituir una aplicación para cumplir una tarea donde antes no había ningún tipo de software, se recompensará el uso de la versión Beta de dicha aplicación. Se motivará a los usuarios
finales para que realicen las pruebas beta sin la presencia de OAC o desarrolladores, los cuales aportarán
los resultados de las mismas a la OAC para terminar de elaborar el IPA (contendedor del resultado de las pruebas Alfa y Beta). Esta tarea normalmente se hará mediante el uso de encuestas de satisfacción y de
forma planificada por la OAC, (más detalles en la sección 2.2.1 Análisis de la realidad), para llevar un
control de los resultados formal y ordenado.
45 UNE 71044 1999 46 MÉTRICA v.3, Modelo SAC, ‘IAS Procedimiento Global’, Sección 3, IAS 3 Pruebas de Acpetcaión del Sistema
73
73 Proceso de Calidad en Ingeniería del Software
2.8 Despliegue
La labor del equipo de Despliegue es, como describimos en la sección 1.2 Definición de entidades, la de crear o preparar los diferentes entornos, e implantar la aplicación en cada uno de ellos. Según MÉTRICA
v.347
, para realizar estas tareas, el equipo de Despliegue realizará diversas tareas:
En concreto, se crearán los elementos del sistema gestor de BBDD o del sistema de ficheros si estos no existen, se reservará el espacio de almacenamiento necesario y se inicializará la BBDD con datos o
ficheros si fuese necesario. En tal caso, se utilizarán los script de creación o modificación de la BBDD.
Para la creación/preparación de los entornos de Desarrollo e Integración, el equipo de Desarrollo, basándose en el DAO y en la fase ASI de análisis, expresará al equipo de Despliegue sus necesidades,
tales como:
Bibliotecas o librerías que hay que incluir
Herramientas software para el desarrollo (compiladores, depuradores, etc.)
Configuración de puestos de trabajo
La infraestructura tecnológica necesaria para realizar la codificación y las pruebas unitarias de
los distintos componentes
Asimismo, para la creación/preparación del entorno de Certificación, la OAC expresará al equipo de Despliegue sus necesidades, tales como:
Bibliotecas o librerías que haya que incluir
Herramientas software para las pruebas y la certificación (automatización de pruebas,
comparadores, etc)
Configuración de puestos de trabajo
La infraestructura tecnológica para realizar la certificación y las pruebas a los distintos
componentes
Una vez el equipo de Despliegue reúne dichas necesidades, dejará listo los entornos de Desarrollo,
Integración y Certificación cuando sea necesario en la fase correspondiente del proceso software. Por
orden, mostramos las tareas del equipo de Despliegue durante el proceso:
47 MÉTRICA v.3, Modelo SAC, ‘SAC007P_PIM_Plan de Implantacion_0100’
Descripción específica del sistema
74
74
Tabla 31. Tareas de Despliegue
TAREAS DE DESPLIEGUE
FASE TAREA DESCRIPCIÓN
Previo a la
codificación del software
Creación o preparación de
los entornos de Desarrollo e Integración
El equipo de Despliegue creará o preparará en caso de que existiera previamente el entorno de
Desarrollo y el de Producción. Tarea necesaria
para que el equipo de Codificación codifique el software en un entorno optimizado para ello, así
como un entorno para probar las relaciones del
software con otros sistemas de información.
Tras la codificación
del software y
previo a su certificación por la
OAC
Despliegue de la aplicación en los entornos de
Desarrollo e Integración
No es necesario ya que el software se ha creado en
dichos entornos.
Creación o preparación del
entorno de Certificación
El equipo de Despliegue creará o preparará en
caso de que existiera previamente el entorno de Certificación. El propósito es brindar a la OAC un
entorno optimizado para la certificación de la
aplicación recién codificada por Desarrollo, donde puedan ejecutar todas las pruebas sin problemas.
Despliegue de la aplicación
en el entorno de
Certificación
El equipo de Despliegue implanta la aplicación en
el entorno de Certificación para que la OAC
pueda comenzar las pruebas. Comenzará con las pruebas de despliegue para comprobar la
estabilidad de la aplicación en un entorno
diferente del cual se creó.
Tras la certificación del software por la
OAC
Creación o preparación del
entorno de Cliente
Operaciones mediante las cuales prepara el entorno de Cliente para que pueda soportar la
aplicación en todos sus ámbitos.
Despliegue de la aplicación
en el entorno de Cliente
Supone la última tarea del equipo de Despliegue
durante el proceso software. Se implantará la aplicación ya certificada por la OAC en el entorno
Cliente para que los usuarios realicen las pruebas
Beta, y, en caso de éxito de las mismas, tener listo el software instalado para usarlo en el futuro sin
problemas.
Al implantarse en este útimo entorno, la OAC realizará una vez más las pruebas de despliegue y
de sistema, para garantizar la estabilidad de la
aplicación en el nuevo entorno.48
48 Tabla realizada bas{ndonos en la norma UNE/ISO/IEC 90003 2005 y en MÉTRICA v.3, Modelo SAC, ‘SAC002P_IAS_Implantacion y
Aceptacion de Sistemas_1300’
75
75 Proceso de Calidad en Ingeniería del Software
49
Continuando con el proceso software, tras la realización de las pruebas Alfa de Aceptación por parte del usuario, el equipo de despliegue implantará la aplicación en el entorno Cliente. Una vez hecho esto, es
necesario certificar o aprobar la correcta implantación del mismo, mediante una última ejecución de las
pruebas de despliegue y las pruebas de sistema. De ello se debe encargar la OAC.
La OAC debe realizar sobre el software implantado dichas pruebas, que no conllevan la actualización,
inserción o eliminación de datos. El objeto de estas pruebas no es, por tanto, la de certificar que la
funcionalidad requerida funciona correctamente, sino de comprobar que el software es estable.
Siempre que las incidencias superen el umbral de rechazo preestablecido, será necesario aplicar la marcha atrás especificada en el MIC, y el software no quedará implantado en el entorno de Cliente. Si dicho umbral no
se supera, la OAC dará el visto bueno para que el software quede implantado en el entorno.
De cualquier modo, será necesario subsanar los errores detectados, aunque el software quede implantado en el entorno de Cliente. Para ello se han de documentar todas las incidencias detectadas durante la tarea de
implantación.
Tras la realización de las pruebas de despliegue y de sistema, en caso de que se hayan detectado incidencias, se ha de realizar un análisis de las mismas. Así, el jefe del Equipo de Certificación debe realizar un exhaustivo
análisis y valoración de las incidencias detectadas.
En el análisis se ha de valorar si los errores detectados provocan un mal funcionamiento del software en alguna
de sus funcionalidades o hacen que este sea total o parcialmente inservible. Se ha de medir, también, el riesgo de corrupción de datos que provocan los errores detectados.
En caso de que la OAC encontrase anomalías de suficiente envergadura podrá, a través de su responsable,
ordenar la marcha atrás de la instalación para que el software vuelva al estado en el que se encontraba antes de la implantación en el entorno Cliente.
Por tanto, en base al estudio de las incidencias detectadas, la OAC ha de tomar la decisión de:
Ordenar la marcha atrás de la implantación.
Dar el visto bueno a la implantación a pesar de las incidencias detectadas.
En el caso de que la OAC decida dar el visto bueno, la aplicación quedará instalada en el entorno Cliente y el usuario final podrá realizar las pruebas beta. Una vez las pruebas beta tengan éxito, se podrá seguir con la
última fase del proceso software, explicada en la siguiente sección.
49 Información extraída de MÉTRICA v.3, Modelo SAC, ‘SAC002P_IAS_Implantacion y Aceptacion de Sistemas_1300’
Descripción específica del sistema
76
76
2.9 Finalización Del Proyecto
Tras la realización de las pruebas de aceptación por parte del usuario final y de la redacción del Informe de Pruebas de Aceptación donde se detallan y valoran todas las incidencias detectadas y registradas, es
necesario que el Cliente dé el visto bueno a la implantación del software en el entorno Cliente. Esta
decisión debe ser valorada y tomada en base al Informe de Pruebas de Aceptación elaborado tras las pruebas.
En caso de que la decisión sea negativa, el Equipo de Desarrollo tendrá que realizar una nueva entrega, en
la que se hayan corregido los errores detectados en las pruebas de aceptación, y que han llevado al RAU a desestimar el despliegue final del software en el entorno Cliente, volviéndose a tener que realizar la
actividad de certificación de implantación y funcional del Sistema.
En caso contrario, el RAU habrá dado el visto bueno a la implantación del software en el entorno Cliente
y se llevará a cabo dicha tarea para que el usuario cliente finalmente pueda hacer uso de la aplicación sin ningún problema.
De esta manera se da por concluida la fase CEI / IAS, el Cliente tendrá la aplicación lista para su uso en
su entorno y, si fue definido en el proyecto software, comienza el mantenimiento de la aplicación.
2.9.1 Mantenimiento
En caso de que se ofreciera al Cliente un mantenimiento del software una vez instalado, será necesario
elaborar un Plan de Mantenimiento. El Plan de Mantenimiento sienta las bases del futuro mantenimiento del
proyecto. Su elaboración es responsabilidad del DP, que requerirá la necesaria colaboración del RAU.
Tomando como referencia MÉTRICA v.350
y la normativa ISO51
, El resultado es un plan donde se especifica cómo será el mantenimiento del proyecto y cómo estará compuesto el equipo que realizará dicha labor.
Sólo en el caso de proyectos cuyo alcance sea el mantenimiento en sí, de un sistema ya implantado, será
opcional la elaboración de dicho documento. El mantenimiento deberá incluir los siguientes factores:
Alcance
Identificación del estado inicial de la aplicación y los elementos de mantenimiento
Las organizaciones de apoyo y acuerdos
Las actividades de mantenimiento, incluyendo la resolución de problemas, soporte a usuarios, soporte
hardware y seguimiento del sistema para detectar fallos
Modificaciones de interfaz que puede ser requerido cuando se hacen adiciones o cambios al sistema
hardware o componentes, controlados por software
Las actividades de gestión de la configuración, pruebas y aseguramiento de la calidad
El calendario de liberaciones propuesto
Cómo se van a llevar a cabo la expansión funcional y mejora de las prestaciones
Registros e informes de mantenimiento
El resultado de los informes de mantenimiento se utilizará para la evaluación y mejora del producto software,
ya sea para una nueva entrega correspondiente a la misma aplicación de funcionalidad expandida en un futuro,
o bien para la subsanación de incidencias que se vayan encontrando durante su uso.
50 MÉTRICA v.3, Modelo SAC, ‘SAC002P_GES_Gestión de Proyectos_0500’, sección GES 14: Elaboración Plan de Mantenimiento 51 UNE ISO IEC 90003 2005, sección 7.5.1.7 Mantenimiento
77
77 Proceso de Calidad en Ingeniería del Software
2.9.2 Histórico de Proyecto52
El objetivo del documento Histórico de Proyecto es concluir el Proyecto comprobando el cumplimiento de los objetivos y recibiendo la conformidad del resultado. Para ello, el DP junto con el procedimiento de elaboración
del Histórico de Proyecto:
Realizará el balance final del proyecto indicando si quedan aspectos pendientes y el acuerdo para su
finalización.
Hará una recapitulación de todos los entregables generados.
Evaluará el desarrollo del proyecto, haciendo hincapié en los obstáculos encontrados y como se han
superado.
Este proceso puede aplicarse con alguna modificación a las entregas de cada fase o versión del producto final.
De hecho, es importante el cierre formal de las fases para prevenir la pérdida de información importante y
preparar correctamente la próxima.
53Una vez recibido el documento del Histórico de Proyecto de parte del Director de Proyecto, se procederá a la
validación de su contenido por parte del Responsable del Área Usuaria.
Éste no realizará una revisión del documento en base a los procedimientos de revisión de documentos definidos en esta metodología. La revisión que se realiza sobre el Histórico de Proyecto debe estar orientada a
verificar su completitud y comprobar que el contenido se ajusta a la realidad del proyecto.
Si se da la conformidad al documento se dará paso a la actividad de archivo del mismo. En caso de que no se haya validado el documento del Histórico de Proyecto se requerirá al DP su corrección. Éste corregirá aquellas
cosas que el responsable de la validación le indique y volverá a remitirle el documento para su validación.
En la medida que los proyectos concluyen con el cumplimiento de los objetivos previstos, se hace
imprescindible la incorporación del Histórico de Proyecto a la base de datos o aplicación corporativa de proyectos, con los siguientes objetivos:
Almacenamiento de la experiencia de proyectos en un formato de fácil acceso para los usuarios.
Para el desarrollo de nuevos proyectos es recomendable revisar los proyectos terminados y tomar los módulos de éxito ya diseñados para reutilizarlos en los nuevos proyectos con el objetivo de hacer uso
del conocimiento ya elaborado y aplicado con los ajustes que la práctica determinó. Ejemplos de
módulos pueden ser los procedimientos repetitivos, normas, formas de contratos, procesamientos estadísticos y evaluación de calidad entre otros.
Es una base de información de conocimiento para todos los DP.
Permite analizar la información, estudiar las regularidades y ganar en calidad en los próximos
proyectos.
El área de planificación puede analizar como se cumplieron los plazos y detectar las irregularidades con el objetivo de facilitar el trabajo de los DP y evaluar el impacto de los mismos.
Posibilidad de desarrollar programas ajustados a las necesidades reales a partir de los resultados de los proyectos ejecutados.
52 Bas{ndonos en MÉTRICA v.3, Modelo SAC, ‘SAC002P_GES_Gestión de Proyectos_0500’, sección GES 15: Elaboración Histórico de Proyecto 53 Según MÉTRICA v.3, Modelo SAC, ‘SAC007P_IHP_Histórico_de_Proyecto_0100’
Descripción específica del sistema
78
78
2.9.3 Informe de Fin de Proyecto
Según MÉTRICA v.354
, el informe de finalización de proyecto se concibe como un documento que certifica el fin de los trabajos planificados en el ámbito de un proyecto independientemente de su tipología.
Dicho informe será elaborado por el JP siguiendo la plantilla confeccionada con tal finalidad (Figura 8 –
Informe de Fin de Proyecto). Una vez elaborado el informe, quedará a la espera que tanto DP como RAU aprueben dicho entregable.
Además de su aprobación, será necesario el archivado del documento debidamente cumplimentado por cada
uno de los implicados en su validación.
55
Figura 8. Ejemplo de Informe de Fin de Proyecto
54 Bas{ndonos en MÉTRICA v.3, Modelo SAC, ‘SAC002P_GES_Gestión de Proyectos_0500’, sección GES 16: Elaboración del Informe de Fin de Proyecto 55 Imagen extraída de MÉTRICA v.3, Modelo SAC, Finalización y Cierre del proyecto, ‘IFP Plantilla’
79
79 Proceso de Calidad en Ingeniería del Software
2.9.4 Cierre56
Nos encontramos en la situación en la cual
El Cliente tiene la aplicación instalada en su entorno lista para funcionar
El Cliente ha recibido todos los entregables
Las tareas de mantenimiento (si las hay) se han iniciado y permanecerán activas durante todo su
alcance
Los documentos de cierre han sido firmados
El cierre del proyecto supone la finalización oficial de todos los compromisos de todas las entidades
implicadas. Además, afirma que la empresa adjudicataria ha cumplido con el alcance propuesto al Cliente, lo que significa que cualquier petición del Cliente a partir de este momento será tratada como un nuevo proyecto.
Por otro lado, el cierre del proyecto libera tanto a DP como al resto de equipos, por lo que pueden asumir
proyectos nuevos.
En este momento, la empresa adjudicataria facturará el proyecto, o la parte ligada a la entrega final. También se realizará la facturación de las entidades pertenecientes a distintas empresas, como el equipo de Desarrollo,
la OAC, el equipo de Despliegue, etc. Todos cerrarán sus contratos con el Proyecto llevado a cabo y facturarán
su parte.
De esta manera, Cliente y empresa adjudicataria habrán terminado el contrato y finalizado el Proyecto
software. Un buen desarrollo del proceso software provocará un buen entendimiento entre las dos partes, el
cual motivará futuras peticiones y entregas si el resultado ha sido positivo.
56 Apoyado en la web: https://www.recursosenprojectmanagement.com/cierre_del_proyecto/
Herramientas CASE
80
80
3 HERRAMIENTAS CASE
n esta sección se describirán las herramientas CASE (Computer Aided Software Engineering „Ingeniería
de Software Asistida por Ordenador‟) más comunes utilizadas durante todas las fases del proceso
software descritas en el capítulo anterior. Nos centraremos sobre todo en las herramientas CASE utilizadas por la OAC, en especial, las que se usaban en everis durante nuestra experiencia en su departamento
de calidad. Estas herramientas son aplicaciones que facilitan el desarrollo software en todas sus fases,
constituyendo una ayuda software que optimiza todo el proceso en términos de tiempo y dinero.
Las herramientas CASE se pueden dividir en 3 grupos según la fase del proceso software que cubren:
U-CASE (Upper): Usadas para las fases de análisis de la realidad, planificación del proyecto y
definición de requisitos
M-CASE (Middle): Usadas para las fases de análisis y diseño del software
L-CASE (Lower): Usadas para las fases de codificación y control de calidad, depuración y pruebas
A continuación explicaremos las herramientas CASE más comunes utilizadas en cada fase:
3.1 Herramientas CASE para la ingeniería de requisitos
Son herramientas que facilitan el análisis de la realidad de la empresa, ayudan a encontrar las necesidades y a
definir los requisitos, además de llevar el seguimiento y trazabilidad de los mismos a lo largo de todo el ciclo de vida software. Muchas de estas herramientas, además, proporcionan medios de comunicación entre Cliente,
DP y los diferentes equipos que participan en el proceso software.
Algunos ejemplos de herramientas CASE para esta fase son: Rambutan, Controla, Reto, SoftREQ, IBM Rational RequisitePro, Jeremia, Irqa 4 o Gatherspace.
3.2 Herramientas CASE para el diseño
Son herramientas que facilitan el diseño del software, ayudan a la representación visual de los diferentes
componentes, y, en su mayoría, sirven para crear diagramas UML (Unified Modeling Language „Lenguaje Unificado de Modelado‟). Los diagramas UML son la forma de visualizar, construir y representar un sistema
más conocida y utilizada en la actualidad, por lo tanto, diseñar el software mediante diagramas UML facilita
su comprensión por parte de todos. En el DAO el uso de estos diagramas resulta imprescindible. Por este
motivo existen diversas herramientas CASE que facilitan el diseño con la creación intuitiva de diagramas UML.
Algunos ejemplos de herramientas CASE para esta fase son: HotGloo, Protoshare, invision, yUML, gliffy,
gennymodel, lucidchart, editor jsuml2 o MagicDraw.
E
81
81 Proceso de Calidad en Ingeniería del Software
3.3 Herramientas CASE para la codificación
Son herramientas CASE que facilitan la codificación del software. La mayoría de herramientas CASE de esta fase la conforman las denominadas IDE (Integrated Development Environment „Entorno de Desarrollo
Integrado‟). Las IDE están constituidas por editores de código fuente, herramientas de construcción
automáticas y depuradores. Para facilitar la codificación, los IDE suelen ofrecer opciones para autocompletar las líneas, resaltar el comienzo y el final de paréntesis, corchetes y llaves o colorear el texto según su
funcionalidad (función, variable, constante, operador, etc). Asimisno, los IDE pueden incluir un compilador o
un intérprete.
Algunos ejemplos de herramientas CASE para esta fase o IDE son: Java Netbeans, Eclipse, Visual Studio,
JetBrain, Codelite, PyCharm, Xcode o Komodo.
3.4 Herramientas CASE para el aseguramiento de la calidad
Son herramientas CASE que facilitan el control de calidad del proyecto software en todos sus ámbitos, incluyendo la realización de pruebas estáticas y dinámicas, herramientas para el control de versiones,
seguimiento del proyecto, revisión documental, gestión de BBDD, administración de usuarios y contraseñas,
gestión de incidencias y transferencia de archivos.
A continuación explicaremos en detalle las herramientas más importantes que utilizamos en la oficina de aseguramiento de la calidad en everis, y el funcionamiento detallado de las mismas.
Nota*: Las herramientas que a continuación se detallan son un ejemplo, lo cual no quiere decir que sean las
mejores ni que haya muchas otras diferentes que realicen las mismas funciones o parecidas.
3.4.1 JIRA
JIRA es una herramienta CASE para la gestión y seguimiento de proyectos software, especialmente útil para la
OAC y para el comité de seguimiento. Se trata de una herramienta que permite ordenar los proyectos que lleva
una empresa, diferenciando entre los distintos clientes, equipos de desarrollo, oficinas de calidad, etc. Centrándonos en un único proyecto software de una empresa para un Cliente, JIRA mostrará el estado del
proyecto en todo momento, qué tareas se han hecho y qué tareas quedan por hacer. También mostrará el estado
de los diferentes entregables, y especificará si ya han sido o no sometidos a una revisión técnica por parte de la OAC.
JIRA define una nomenclatura estándar para las diferentes entregas. Usará el siguiente formato:
XXXYYYEZZ, en el cual los 3 caracteres XXX representarán el anagrama alfabético de la aplicación en cuestión. Los caracteres YYY serán numéricos y representarán el código de proyecto dentro de la misma
aplicación. Por último, los caracteres ZZ representarán la versión de la entrega dentro del proyecto dentro de la
aplicación. De esta manera, si nos encontramos en la versión 8 del proyecto 4 de la aplicación „Cargos‟, el
nombre de la entrega en JIRA sería: „CAR004E08‟.
Por otro lado, para cada entrega se muestra el estado en el que se encuentra y quién es la entidad responsable
de continuar. Los diferentes estados en los que puede encontrarse una entrega según JIRA son:
Preparado: La entrega se acaba de crear y subir a JIRA, y todavía no ha comenzado su certificación.
En este estado pueden estar completadas o no las fases de definición de requisitos, diseño y codificación.
En progreso: La entrega se está certificando por la OAC, de manera que está sometiéndose a pruebas
estáticas o dinámicas o a revisiones técnicas.
Bloqueada: La OAC ha encontrado alguna incidencia bloqueante que impide la correcta consecución
del resto de pruebas. En este caso, el equipo responsable de corregir la incidencia notificará a la OAC
cuando lo haya hecho, y la entrega pasará de nuevo al estado „En Progreso‟.
Herramientas CASE
82
82
Rechazada: Un entregable no ha superado satisfactoriamente las revisiones técnicas de la OAC y ha
sido devuelto al equipo responsable de su corrección, junto con su respectivo IRT. Una vez el equipo reponsable haya corregido las incidencias descritas en el IRT, devolverá la nueva versión del
entregable a la OAC y el estado pasará de nuevo a „En progreso‟.
Aceptación Previa: La entrega ha sido certificada por la OAC y ha superado satisfactoriamente las
pruebas y las revisiones técnicas.
Cerrada: La entrega ha superado satisfactoriamente las pruebas de aceptación, y tanto Cliente como
OAC han dado su visto bueno para terminar y cerrar la entrega, con la aplicación lista para usarse en
el entorno Cliente.
En JIRA, cada entrega se divide por los entregables que contiene (descritos en la Tabla 32. Lista final de entregables, sección 2.6.4). Para cada entregable, la entidad que haya trabajado en él dispone de una sección
para indicar qué tareas ha realizado sobre el entregable en cuestión, quién ha sido la persona responsable y
cuánto tiempo ha invertido en dichas tareas. Cada entregable a su vez se puede encontrar en cada uno de los
estados descritos anteriormente (preparado, en progreso, bloqueado, rechazado, en aceptación previa y cerrado). De esta manera, el comité de seguimiento puede comprobar instantáneamente cuál es el estado de
cada uno de los entregables, quién es responsable de continuar con cada uno y cuánto tiempo se ha invertido
en cada tarea, convirtiéndose así en una herramienta CASE fundamental para el seguimiento del proyecto software.
3.4.2 QM
QM (Quality Management) es una herramienta CASE para el control de versiones y la transferencia de
archivos entre diferentes entidades. Constituye el medio principal de subida, descarga y envío de archivos
entre los diferentes equipos que participan en el proceso software. Se trata de una plataforma web compartida dividida por las diferentes entregas existentes, siguiendo la nomenclatura XXXYYYEZZ definida por JIRA.
Una vez completadas las fases de definición de requisitos, diseño y codificación, los diferentes equipos subirán
los entregables generados a QM, para que la OAC pueda descargarlos y comenzar con las revisiones técnicas y las pruebas. LA OAC a su vez subirá a QM los IRT y los informes de calidad generados para que los equipos
correspondientes puedan descargarlos para conocer las incidencias encontradas.
QM define una nomenclatura estándar para el control de versiones de los entregables. Usará el formato: „XXXYYYE_VVV_Nombre del entregable_ZZWW‟.
XXX representará el anagrama alfabético de la aplicación en cuestión, igual que en JIRA
YYY representará el código numérico del proyecto dentro de la misma aplicación, igual que en JIRA
VVV representará el anagrama del entregable en cuestión
ZZ representará el código numérico de la versión de la entrega dentro del proyecto dentro de la misma
aplicación, igual que en JIRA
WW representará el intento de corrección (comenzando por 0), siendo el número de veces que ha sido
sometido a las revisiones técnicas de la OAC
De manera que, siguiendo con el ejemplo de JIRA, la versión 8 del proyecto 4 de la aplicación „Cargos‟, supongamos que el MUS ha sido rechazado 2 veces por la OAC y el equipo de Desarrollo ha subido a QM el
tercer intento. El nombre del entregable sería: „CAR004E_MUS_Manual de Usuario_0802‟.
De igual manera, cuando la OAC realice la revisión técnica de este entregable, sea el resultado aceptado o rechazado, subirá el IRT en la sección de QM correspondiente a dicho entregable, con el nombre:
„CAR004E_IRT_Informe de Revisión Técnica_0802‟.
Con esta nomenclatura, se asegura un correcto control de versiones durante todo el proceso de certificación,
tarea fundamental por parte de la OAC en esta fase.
Por otro lado, los archivos entregables estarán accesibles para cualquier equipo que necesite descargarlos, y, a
su lado, se especificará su estado, si está aceptado, rechazado, o pendiente de revisión.
83
83 Proceso de Calidad en Ingeniería del Software
3.4.3 Mantis
Mantis es una herramienta CASE para la gestión de las incidencias detectadas por la OAC en los diferentes entregables durante las revisiones técnicas y las pruebas estáticas y dinámicas. Se trata de una plataforma web
a la cual pueden acceder la OAC y DP, para llevar un seguimiento de las incidencias, ordenadas según las
entregas (siguiendo la nomenclatura de JIRA y QM) y de cada uno de los entregables.
Mantis es una herramienta fundamental para la OAC ya que recoge todas las incidencias de una entrega de una
forma ordenada, incluyendo la versión del entregable en cuestión, la gravedad de la incidencia y la posibilidad
de anexar archivos adjuntos, tales como capturas de pantalla o resultados en formato texto de diversas pruebas
para apoyar las incidencias. Además, incorpora una funcionalidad que, mediante diversos filtros según nombre del entregable, fecha, versión, etc, permite exportar todas las incidencias encontradas en un entregable
directamente al IRT correspondiente a dicho entregable, automatizando así el proceso de elaboración de
informes de calidad.
Mantis almacena en su Base de Datos todos los criterios de certificación descritos en la sección 2.6.2
Incidencias, manteniendo su descripción y su gravedad, de forma que es más fácil e intuitivo registrar las
incidencias más frecuentes. A la misma vez, permite la generación de una nueva incidencia que no pertenezca a ningún criterio de certificación previo, o incluirlacomo defecto genérico si resulta ambiguo clasificar dicha
incidencia.
Esta herramienta también añade la posibilidad de diferenciar los defectos encontrados corregidos y sin
corregir, junto con la versión del entregable en la que se encuentra la incidencia y en la que se corrige. De esta manera, es más cómodo decidir el resultado de una revisión técnica al observar en un mismo sitio las
incidencias corregidas y no corregidas.
3.4.4 TOAD Oracle
TOAD Oracle es una herramienta CASE que permite a la OAC acceder a cualquier BBDD necesaria para la certificación de una aplicación, además de la modificación de los elementos necesarios en dichas BBDD. Esto
es necesario cuando la OAC necesita ejecutar SCR de BBDD o actualizar elementos, ya sea para la instalación
y configuración inicial de la aplicación, modificación de tablas de datos, creación o eliminación manual de
sinónimos públicos, roles y privilegios, usuarios, o introducción y eliminación de información interna de la aplicación para ejecutar diferentes pruebas.
TOAD permite el acceso a cualquier BBDD siempre que se tenga conexión a la misma y se disponga del
usuario administrador de la misma y su contraseña. Dispone de un modo que permite lanzar sentencias sql directamente, afectando de inmediato a las BBDD deseadas, así como un modo gráfico que permite recorrer
las diferentes tablas de un esquema y modificar los datos en modo ventana, sin necesidad de lanzar una sola
línea sql.
Esta herramienta incluye diversas opciones para facilitar la, a veces, abrumadora cantidad de información que
podemos encontrar en un esquema de aplicación. Estas opciones incluyen, entre otras:
Filtros de búsqueda para las diferentes tablas
Rastreador por filas y columnas
Buscador de palabras clave
Varios criterios de ordenación de las filas en cada tabla (según el identificador unitario, alfabético,
numérico, según las columnas con más o menos datos, fecha, etc)
Funciones de búsqueda de una cadena de texto
Funciones de reemplazo de una cadena de texto por otra
TOAD tiene un modo de editor de texto que permite importar y ejecutar SCR de BBDD directamente, con todos los permisos de lectura, escritura y ejecución. Esto es útil para la OAC por si desea realizar pruebas más
complejas sobre los SCR de BBDD con total libertad de modificación o agilizar pruebas funcionales.
Herramientas CASE
84
84
3.4.5 Jenkins y Sonarqube
Jenkins es una compleja herramienta que ofrece un método simple para configurar un entorno de integración continua para cualquier combinación de lenguages de programación y repositorios, a la vez que es capaz de
automatizar tareas rutinarias de desarrollo. A día de hoy, Jenkins constituye uno de los servidores de software
libre para automatización de tareas de desarrollo software más importantes y más utilizados.
Entre las muchas funciones que ofrece esta potente herramienta, nuestro equipo de aseguramiento de la calidad
utilizaba, mayoritariamente, su análisis de código estático, gracias a la cual la tarea de pasar las pruebas
estáticas a los ficheros software resulta automática. Esta función es la resultante de instalar el plugin de
Sonarqube en Jenkins.
Sonarqube es una herramienta CASE que realiza análisis de código estático, es decir, analiza los ficheros de
código sin necesidad de ejecutarlos. Jenkins permite la integración del plugin Sonarqube, con el cual se podrán
realizar dichos análisis de código estático directamente desde una entrega en Jenkins.
Esta función consiste en crear una entrega en el servidor Jenkins, respetando la nomenclatura de JIRA para la
misma, y adjuntarle todos los ficheros SFW que conforman la entrega correctamente ordenados en un sistema
de directorios. El plugin Sonarqube analizará directorio por directorio, cada uno de los ficheros SFW que conforman una entrega, y generará un informe Sonarqube. Este informe contiene el resultado de las pruebas
estáticas a los ficheros SFW, y es lo que constituirá el PES (detallado en la sección 2.6.4 Informes de Calidad).
El análisis estático que nos brinda el informe de Sonarqube permite mejorar el código detectando errores de
programación y estándares para la programación estructurada que no han sido respetados en la codificación. Asimismo, detectamos problemas de diseño al analizar las dependencias entre clases o incoherencias en la
arquitectura, duplicidad de código, para reestruturar ciertos módulos y así poder reutilizar código en la medida
de lo posible, y detectamos vulnerabilidades en la seguridad, para prevenir ciertos ataques, como SQL Injection en la recogida de parámetros entre otros.
El informe de Sonarqube se añadirá al IPC que elaborará la OAC tras la realización de todas las pruebas.
3.4.6 SoapUI
Soap UI es una herramienta CASE que nos permite probar los web services (o servicios web). En ocasiones,
las entregas constituirán un web service, que no es más que un software que permite el intercambio de datos entre dos o más aplicaciones a través de una red, privada o pública, sin importar el entorno, plataforma o
lenguaje de programación en el que se encuentren.
SOAP UI nos permitirá probar web services de forma ágil, en formato WSDL (Web Services Description Language „Lenguage de Descripción de Servicios Web‟), mediante el estándar SOAP (Simple Object Access
Protocol „Protocolo de Acceso a Objetos Simples‟).
El funcionamiento de SOAP UI es simple. Para probar un web service, la OAC crea un proyecto SOAP y especifica, entre otros parámetros, la url donde se encuentra el descriptor del servicio web en cuestión. De este
modo, SOAP UI se encuentra con acceso al web service que queremos probar. Una vez configurado, será
necesario crear diferentes peticiones para invocar a los métodos deseados del webservice. Esta tarea la puede
realizar la OAC desde cero, o, por el contrario, las peticiones pueden venir creadas de antemano por Desarrollo, estando incluidas en el PP para probar así el web service más eficientemente. Una vez creadas las
peticiones, se lanzarán con SOAP UI, de manera similar a como se accede a una página web, y el web service
retornará una respuesta según la petición realizada.
Nuestro equipo de aseguramiento de calidad, entre las muchas funciones que ofrece SOAP UI, utiliza
mayoritariamente la generación de pruebas funcionales. Es el caso en el que se comprueba que el web service
cumple con las funcionalidades descritas en los RF, cuyos casos de prueba pueden ser directamente creados
por la OAC, permitiendo la modificación de todos los parámetros que se desee. En estos casos de prueba, se comprueba la salida devuelta por el web service y se corrobora que los datos de salida son los esperados.
Además de pruebas funcionales, SOAP UI permite la realización de pruebas no funcionales, como por
ejemplo pruebas de rendimiento del web service.
85
85 Proceso de Calidad en Ingeniería del Software
3.4.7 KeePass
KeePass es una herramienta CASE que permite el almacenamiento seguro de usuarios y contraseñas. A la hora de certificar entregas, es muy posible que la OAC necesite memorizar una gran cantidad de usuarios y
contraseñas para acceder a los distintos esquemas de BBDD, entrar a las aplicaciones en modo administrador,
acceder a los datos ocultos, etc. KeePass ofrece una forma sencilla de organizar todos los usuarios y contraseña que se necesiten de una manera eficaz y segura.
3.4.8 Notepad++
Se trata de un editor de texto sencillo pero potente, útil para modificar ficheros de texto. La OAC utilizará el
Notepad++ cuando sea necesario modificar algún fichero de configuración de SFW para adaptarlo al entorno
de certificación, actualizar las rutas de los ficheros o modificar nombres de usuarios, contraseñas, fechas, entre otros.
3.4.9 DiffPDF
Herramienta que permite comparar dos ficheros pdf. Con el fin de realizar un análisis estático documental más
profundo, nuestro equipo de aseguramiento de calidad opta por una herramienta como esta, que simplemente posiciona los dos ficheros pdf en la pantalla uno al lado del otro, y marca las diferencias en un color distinto.
Al no tratarse de una herramienta que realice análisis documental automático, el personal de la OAC puede
leer los ficheros PDF con atención para detectar cualquier posible incidencia.
3.4.10 VirtualBox
Herramienta CASE de virtualización. Permite accede a máquinas virtuales y a entornos sandbox para la ejecución de diversas pruebas o la instalación de la aplicación. Nuestro equipo de calidad, a la hora de realizar
las pruebas funcionales de una aplicación, ejecuta dicha aplicación en una máquina virtual, gestionada por
VirtualBox, para prevenir que los fallos afecten al equipo directamente, y poder realizar una marcha atrás sin preocupaciones. Para realizar las pruebas funcionales, la OAC va ejecutando uno por uno los CP especificados
en el PPF, y va comprobando que las salidas generadas por la aplicación son las esperadas según el PPF.
Conclusiones
86
86
4 CONCLUSIONES
n este apartado se recogen las conclusiones personales con respecto a este TFG. El objetivo del TFG era
realizar un estudio teórico de un proceso de calidad en el ámbito del desarrollo software. Apoyándonos
en los diferentes estándares existentes al respecto, en los conocimientos adquiridos en la carrera relacionados con el tema y en la experiencia laboral como técnico de calidad en la empresa everis, hemos
conseguido realizar un estudio amplio acerca del ciclo de vida software y el aseguramiento de la calidad del
mismo.
Durante este TFG hemos utilizado, de entre todos los que existen, un modelo en cascada de desarrollo
software, y hemos seguido casos específicos en más de una ocasión. Con respecto al proceso software, al
tratarse de un tema tan amplio y extenso, nos ha sido imposible recoger en un único trabajo todos los casos y
situaciones posibles, teniendo que realizar para tal efecto un estudio diferente para cada uno de los modelos de desarrollo software, o teniendo en cuenta todas las posibles metodologías a seguir, o incluso utilizando
diferentes herramientas CASE de entre todas las que existen. Aún así, hemos conseguido desarrollar un
método para el control de calidad que se puede extrapolar (en mayor o menor medida según lo diferente que sea el proyecto software del prototipo que en este documento se estudia) a otro tipo de proyectos, a modo de
guía para empresas o personas que quieran reunir información acerca del proceso software y qué pasos seguir
para llevar a cabo un aseguramiento de la calidad básico.
Este TFG se puede expandir bastante en la sección de herramientas CASE por ejemplo, ya que nos hemos
centrado en explicar las que hemos usado bajo nuestra experiencia laboral. Con una mayor experiencia laboral
y habiendo probado más herramientas, podríamos haber incorporado una sección de comparación de
herramientas CASE, y determinar las ventajas e inconvenientes de cada una para cada aspecto del control de calidad. También se puede expandir en el ámbito de herramientas CASE en las fases que no son el control de
calidad, ya que al no haber participado activamente de estas actividades, la información acerca de las
herramientas CASE que se pueden utilizar es muy ampliable.
Hemos tratado de recoger muchos criterios de certificación, pero esta información también se podría expandir
al tratar con aplicaciones que no utilicen java como código fuente, o que sigan otros estándares para
certificarse. En la sección de criterios de certificación documentales sí hemos conseguido aportar mucha
información relevante, que se puede extrapolar fácilmente a cualquier documento del mismo tipo en cualquier proyecto software.
En resumen, se podría haber realizado un trabajo mucho más extenso, capaz de contener todas y cada una de
las situaciones posibles en el ámbito del desarrollo software, pero al tratarse de un estudio teórico, la información de este TFG se puede extrapolar, y utilizar fácilmente como guía de control de calidad durante el
ciclo de vida software de cualquier proyecto.
E
87
87 Proceso de Calidad en Ingeniería del Software
REFERENCIAS
[1] „Managing the Development of Large Software Systems’, Winston Royce, 1970
[2] „Software Engineering Economics‟, Barry Boehm, 1981
[3] „Software Engineering‟, Ian Sommerville, 1985
[4] ISO/IEC 12207:1995 (Information Technology - Software Life Cycle Processes)
[5] ISO/IEC-15504 SPICE (Software Process Improvement and Assurance Standards Capability
Determination
[6] MÉTRICA V.3, 2001
[7] UNE 71044 – 1999
[8] MÉTRICA v.3, Modelo SAC, „SAC-Definición_de_roles‟
[9] https://www.lancetalent.com/blog/8-herramientas-para-la-gestion-de-proyectos-profesionales/
[10] https://www.atlassian.com/software/jira
[11] https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp
[12] „SAC005P_CON_Plan_de_Configuracion_0100‟, Normativa Técnica, MÉTRICA v.3
[13] UNE-EN 16271:2013
[14] ISO 21500:2012
[15] https://www.gestiopolis.com/metodologia-para-evaluacion-diagnostico-y-diseno-de-procesos/
[16] https://www.emprendepyme.net/tecnicas-e-instrumentos-para-detectar-las-necesidades-de-
capacitacion.html,
[17] https://es.surveymonkey.com/mp/employee-satisfaction-surveys/
[18] https://www.survio.com/plantilla-de-encuesta/evaluacion-de-software
[19] https://www.monografias.com/docs/Ejemplo-encuesta-de-satisfacci%C3%B3n-para-usuario-de-
FKZ3RNCMY
[20] Apuntes de Proyectos de Telemática
*21+ „Introducción a los Proyectos‟, Departamento de Ingeniería Telemática, 2017-2018: https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
[22] Trabajo Final Proyectos de Telemática
[23] https://contrataciondelestado.es/wps/wcm/connect/62c67958-52c9-4ef5-b30e-
cd3b1566aef2/DOC_CD2012-382658.pdf?MOD=AJPERES
[24] http://ccapsa.com/2013/10/02/
[25] UNE-ISO/IEC 90003-2005
[26] ISO 9001-2000
[27] MÉTRICA v.3, Modelo SAC, „SAC007P_DDR_Definicion Detallada Requisitos_0100‟
[28] ISO/IEC 14764:1999
Referencias
88
88
[29] ISO/IEC 12207:1995
[30] http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/408
[31] ISO 10007-1997
[32] MÉTRICA v.3, modelo SAC: „SAC007P_DAO_Diseño Arquitectura OO_0100‟
[33] MÉTRICA v.3, modelo SAC: „DSI Procedimiento Global‟
[34] MÉTRICA v.3, modelo SAC: „SAC007P_MIC_Manual_Instalacion_Configuracion_0100‟
[35] METRICA V.3, „Aseguramiento de la Calidad‟
[36] MÉTRICA v.3, modelo SAC, „Objetivos del Sistema de Aseguramiento de la Calidad‟
[37] ISO/IEC/IEEE 29119
[38] IEEE 829
[39] IEEE 1008
[40] BSI 7925-1
[41] BSI 7925-2
[42] ISO/IEC 15289
[43] MADEJA: http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/creacion-
y-evolucion-sistemas
[44] http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/227
[45] https://es.wikipedia.org/wiki/Pruebas_de_software
[46] https://www.mantisbt.org/
[47] MÉTRICA v.3, modelo SAC, „SAC002I_GCP-GESTIÓN DE LA CALIDAD_0200‟
[48] https://www.soapui.org/
[49] https://winscp.net/eng/index.php
[50] https://www.toadworld.com/downloads
[51] https://notepad-plus-plus.org/
[52] MÉTRICA v.3, modelo SAC, Normativa Técnica, Indicadores de Certificación.
[53] MÉTRICA v.3, modelo SAC, „SAC002P_RDP_Revisión de Documentos_0800‟
[54] https://jenkins.io/
[55] https://www.sonarqube.org/
[56] MÉTRICA v.3, modelo SAC, „SAC007P_IPC_Informe_de_Pruebas_Certificación_0100‟ [57] MÉTRICA v.3, modelo SAC, „SAC002P_IAS_Implantacion y Aceptacion de Sistemas_1300‟
[58] MÉTRICA v.3, Modelo SAC, „IAS Procedimiento Global‟
[59] MÉTRICA v.3, Modelo SAC, „SAC007P_PIM_Plan de Implantacion_0100‟
[60] MÉTRICA v.3, Modelo SAC, „SAC002P_GES_Gestión de Proyectos_0500‟
[61] MÉTRICA v.3, Modelo SAC, „SAC007P_IHP_Histórico_de_Proyecto_0100‟
[62] MÉTRICA v.3, Modelo SAC, Finalización y Cierre del proyecto, „IFP Plantilla‟
[63] https://www.recursosenprojectmanagement.com/cierre_del_proyecto/
89
89 Proceso de Calidad en Ingeniería del Software
Glosario
90
90
GLOSARIO
AENOR: Asociación Española de Normalización y Certificación 2
ASI: Análisis del Sistema de Información 27
BSI: British Standards Institution 45, 88
CAPDER: Consejería de Agricultura, Pesca y Desarrollo Rural 5
CASE: Computer Aided Software Engineering 'Ingeniería de Software Asistida por Ordenador' 80
CEI: Certificación e Implantación del Sistema 43
CP: Caso de Prueba 41
CSI: Construcción del Sistema de Información 35
CU: Caso de Uso 28
DAO: Diseño de Arquitectura Orientado a Objetos 9
DDR: Definición Detallada de Requisitos 4
DP: Dirección de Proyectos 4
DSI: Diseño del Sistema de Información 31
FAQ: Frequently Asked Questions 38
IAS: Implantación y Aceptación del Sistema 43
IDE: Integrated Development Environment „Entorno de Desarrollo Integrado‟ 81
IEC: International Electrotechnical Commission 2, 87
IEEE: Institute of Electrical and Electronics Engineers 45
IPA: Informe de Pruebas de Aceptación 70
IPC: Informe de Pruebas de Certificación 68
IRT: Informe de Revisión Técnica 64
ISO: International Organization for Standardization 2, 87
JP: Jefe de Proyecto 4
LOPD: Ley Orgánica de Protección de Datos 51
LSSI: Ley de Servicios de la Sociedad de la Información 51
MADEJA: Marco de Desarrollo de la Junta de Andalucía 27
MÉTRICA: Estándar de Desarrollo software del Gobierno de España 2
MIC: Manual Básico de Instalación y Configuración 9
MOD: Informe de Modelo de Datos 66
MUS: Manual de Usuario 9
91
91 Proceso de Calidad en Ingeniería del Software
OAC: Oficina de Aseguramiento de la Calidad 2
PDI: Personal Docente e Investigador 22
PES: Informe de Pruebas Estáticas 67
PP.FF: Preguntas Frecuentes 38
PP: Plan de Pruebas 9
PPA: Plan de Pruebas de Aceptación 30
PPF: Plan de Pruebas Funcionales 34
PPI: Plan de Pruebas de Integración 34
PPNF: Plan de Pruebas No Funcionales 34
PPS: Plan de Pruebas de Sistema 34
PPU: Plan de Pruebas Unitarias 34
RAU: Responsable del Área Usuaria 3
RC: Requisito de Conducta 28
RE: Requisito de Entorno Tecnológico 28
RF: Requisito Funcional 28
RFI: Requisito de Fiabilidad 28
RGCE: Reglamento General de la Contratación del Estado 14
RI: Requisito de Interfaz 28
RIN: Requisito de Información 28
RM: Requisito de Mantenibilidad 28
RN: Regla de Negocio 28
RNF: Requisito No Funcional / Técnico 28
RO: Otros Requisitos 28
RR: Requisito de Rendimiento y Disponibilidad 28
RS: Requisito de Seguridad 28
RU: Requisito de Usabilidad 28
SAC: Sistema de Aseguramiento de la Calidad 2
SCR: Scripts 35
SFW: Software 1
SOAP: Simple Object Access Protocol „Protocolo de Acceso a Objetos Simples‟). 84
TFG: Trabajo de Fin de Grado 1
UML: Unified Modeling Language „Lenguaje Unificado de Modelado‟). 80
UNE: Una Norma Española 2, 87
WSDL: Web Services Description Language „Lenguage de Descripción de Servicios Web‟ 84
Glosario
92
92