Trabajo Fin Carrera Proceso Calidad

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
e Equation Chapter 1 Section 1
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
16 Índice de Tablas
Í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
18 Índice de Tablas
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 DESCRIPCIÓN GENERAL DEL SISTEMA
1.1 Modelo
P
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, 1970 1), 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
Todos los requisitos deben quedar recogidos al inicio,

Alto nivel de satisfacción del cliente impidiendo la definición de nuevos requisitos durante el
desarrollo del proyecto
Permite suplir pérdidas en el equipo de desarrollo Las pruebas se realizan muy tarde, provocando que los
con bastante facilidad errores tarden en identificarse y corregirse
Todos los aspectos del proyecto están bien claros

Si hay problemas, tendrán un alto coste en tiempo y dinero
y definidos desde el principio
Es un modelo fácilmente comprensible e

La creación del software tarda mucho tiempo
implementable
Permite que lo realice un equipo con poca

experiencia en el desarrollo software debido a su Las etapas necesitan esperar a que acabe la anterior
simplicidad
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
1
2 Descripción general del sistema
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.
Proceso de Calidad en Ingeniería del Software 3
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.
3
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

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
5
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.
7QM: 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
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
Creado por el equipo de despliegue, diseñado para diseñar,

Entorno de Desarrollo codificar y depurar el software. Utilizado por el equipo de
desarrollo.
Creado por el equipo de despliegue, diseñado para probar la

Entorno de Integración relación del software con otros sistemas y la integración de
distintos módulos. Utilizado por el equipo de desarrollo
Creado por el equipo de despliegue, diseñado para realizar

las revisiones técnicas al software a través de las pruebas
Entorno de Certificación funcionales y no funcionales. Utilizado por el departamento
de calidad OAC
Se trata del entorno donde el cliente se encuentra, entorno

Entorno de Cliente 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
7
1.5 Diagrama de flujo del proceso software
Figura 1. Diagrama de flujo del proceso 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)
9
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.
2 DESCRIPCIÓN ESPECÍFICA DEL SISTEMA
2.1 Introducción
P
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 Proyecto 10
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
10Basado 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/
11
12
Descripción específica del sistema
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
Muy en En De Muy de
CUESTIONARIO SOFTWARE
desacuerdo desacuerdo acuerdo 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
12
Muy en En De Muy de
CUESTIONARIO SOFTWARE
desacuerdo desacuerdo acuerdo 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

X
útil
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

X
y entendible
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.
13
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)
14
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
Figura 2. Diagrama de Flujo Concurso Público
17Figura extraída directamente de: Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018:
15
16
2.2.2.2.1 Preparacion del Pliego de Prescripciones Tecnicas

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 Descripción de los trabajos
Objetivos generales
(Todas aquellas carencias recogidas en el
previo análisis de la realidad) Requisitos de planificación y organización del equipo de trabajo
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
ADMINISTRATIVOS Procedimiento y forma de adjudicación
Requisitos de las empresas ofertantes:

(Todos aquellos requisitos requeridos para
-Tipo de actividad
la formalización del proyecto)
-Solvencia económica
-Experiencia previa
-Certificados de calidad
Formalización del contrato:

-Cómo se adjudica
-Fecha de la firma
-Avales necesarios
Presupuesto máximo
ECONÓMICOS
Forma de pago
18Basado 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.
16
Ejemplo de un Pliego (Incluyendo en partes diferenciadas el Pliego de Prescripciones Técnicas y el Pliego de

Cláusulas administrativas):19
Figura 3. Ejemplo de Pliego
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
17
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).
20Basado en Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018:

18
2.2.2.2.3 Evaluacion 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
19
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.
20
2.2.2.2.4 Elaboracion 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
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
Alcance 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
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,
Recursos Humanos Diseñadores, Documentadores, etc. También incluye su titulación, certificación,
experiencia y salario.
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
Planificación designada por el Cliente en el Pliego)
Temporal
Se suele usar un diagrama de Gantt para diseñar la planificación temporal de manera
gráfica y comprensible.
Detalla los costes que va a tener la aplicación (siempre respetando el presupuesto máximo
Presupuestos designado por el Cliente en el Pliego), desglosando los gastos: Salario de los trabajadores,
gastos generales, instalaciones, etc.
En esta sección se plasma el resultado de un estudio previo de los posibles problemas que
Análisis de Riesgo 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 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
Seguimiento del estructura de los Informes de Seguimiento: documentos que DP presentará al cliente en
Proyecto cada reunión indicando los puntos clave de la evolución del proyecto.
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
Plan de Calidad dicha tarea. También se explica la metodología de revisiones técnicas y ejecución de
pruebas que la OAC va a utilizar.
Se calculan parámetros para comprobar la rentabilidad del proyecto. Se detalla la visión

Plan de Negocio 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.
En caso de que existan, se suele tratar de leyes y normativas, planos generales, guías de
Anexos 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.
21
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
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.
DDR
Aquí se detallan cuáles son las funciones que tiene que cubrir el software (Requisitos
(Definición Detallada de funcionales) y otros aspectos relacionados con la usabilidad, la velocidad del software, la
Requisitos) seguridad, y otros requisitos técnicos (Requisitos no funcionales).
Más información en la sección 2.3 Definición del Proyecto
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
DAO 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
(Diseño de Arquitectura de diseño, marcando las pautas bajo las cuales codificará el SFW el equipo de
Orientado a Objetos) codificación.
Más información en la sección 2.4 Diseño del Proyecto
Se trata de ficheros codificados por el equipo de codificación, necesarios para el correcto

funcionamiento de la aplicación final.
SCR
Realizan tareas como creación de sinónimos públicos, creación o eliminación de usuarios
(Scripts) 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.
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
PP que realizar a la aplicación para comprobar su correcto funcionamiento.
(Plan de Pruebas) 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
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
MUS aplicación.
(Manual de Usuario) 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
El Manual Básico de Instalación y Configuración es un documento que resume

MIC
cómo instalar la aplicación elaborado por el equipo de desarrollo.
(Manual básico de Detalla rigurosamente los pasos a seguir para instalar el SFW, ejecutar los SCR
Instalación y pertinentes, realizar modificaciones en registros, BBDD, y distintos parámetros.
22
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
Son los ficheros de software de la aplicación codificados por el equipo de

SFW codificación. Pueden variar en lenguaje de programación, estructura y arquitectura
(Software) 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.
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
IPC 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
(Informe de Pruebas de descritas en el PP, y el resultado de la instalación de la aplicación en los diferentes
Certificación) entornos.
Más información en la sección 2.6.4 Informes de Calidad
El Informe de Pruebas de Aceptación detalla el resultado de las pruebas de usuario.

IPA
En él, la OAC plasmará la información recogida por el usuario acerca de la
(Informe de Pruebas de aplicación, tras haber realizado las pruebas alfa y las pruebas beta.
Aceptación) Más información en la sección 2.6.4 Informes de Calidad
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
Garantía 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.
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
Asistencia Técnica hacer algo, la empresa se compromete a brindar asistencia técnica (presencial o
remota) a los usuarios.
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
Formación Presencial 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.
23
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
24
2.2.2.2.5 Eleccion 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: Criterios (Bajo cada criterio se muestra el porcentaje de importancia en la decisión, para
ponderar el resultado en consecuencia)
0-10
Coste Tiempo Experiencia Fiabilidad (fama) Salud financiera

(80%) (60%) (90%) (85%) (65%)
Propuesta 1 8 5 2 8 6
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/
25
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.
26
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.
24
RAU, 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).
25
Es 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
27
28
Tabla 8. Tipos de Requisitos
TIPOS DE REQUISITOS
TIPO SUBTIPO SIGLAS DESCRIPCIÓN
Especifican el comportamiento del sistema.

Describen lo que el sistema debe hacer, qué
funcionalidades debe incorporar la aplicación,
CASOS DE USO CU
y qué acciones debe ser capaz de realizar,
describiendo las interacciones entre sistema y
usuarios.
REGLAS DE Especifican las normas del negocio que el

FUNCIONALES RN software tendrá que respetar y seguir.
NEGOCIO
(RF)
Especifican aquellas tareas relacionadas con
otros usuarios o sistemas, cuando el software
DE CONDUCTA RC resulta necesario para la consecución de los
objetivos de estos últimos.
Especifica la información y los datos que el

DE INFORMACIÓN RIN software deberá gestionar para funcionar
correctamente.
DE ENTORNO Describen el ambiente operativo en el que se

RE debe desenvolver el sistema.
TECNOLÓGICO
Garantizan la seguridad de tecnología de

información, seguridad de datos, seguridad
DE SEGURIDAD RS lógica, control de acceso a información
(restricciones de acceso), autenticidad de la
información, privacidad, entre otros aspectos.
Describen la tolerancia a fallos del software y

DE FIABILIDAD RFI su respuesta bajo condiciones específicas
Describen todos aquellos aspectos

relacionados con la interacción directa
NO DE USABILIDAD RU software-cliente, como su facilidad de uso, su
FUNCIONALES comprensión, etc.
(O TÉCNICOS)
Describen la capacidad o facilidad del
DE
(RNF) RM software para ser actualizado, analizado y
MANTENIBILIDAD corregido en el futuro una vez implantado.
Describen la comunicación con sistemas

DE INTERFAZ RI
externos, y cómo debe ser esa comunicación.
Describen la disposición del sistema para

DE RENDIMIENTO brindar servicio correctamente y garantizar
RR una velocidad, tiempo de respuesta y consumo
Y DISPONIBILIDAD
de recursos óptimos, entre otros.
Derivados del entorno organizacional, entre

los que se incluyen aspectos éticos,
OTROS RO seguimiento de estándares y plantillas, y
requerimientos legales y regulatorios.
28
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’
29
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.
30
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‟
31
32
Tabla 9. Estructura de un DAO
DAO
SECCIÓN DESCRIPCIÓN
Subsecciones:
1. INTRODUCCIÓN 1.1 Objeto
1.2 Alcance
Se describe el propósito del documento de Diseño de Arquitectura Orientado
1.1 Objeto a Objetos del Sistema para la entrega específica.
Se describen las unidades organizativas y responsabilidades a las que va

1.2 Alcance dirigida el DAO y que participan en su generación, validación y registro.
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
2. DESCRIPCIÓN DEL
definidas en los RE). Subsecciones:
ENTORNO
TECNOLÓGICO 2.1 Elementos de la infraestructura
2.2 Restricciones Técnicas
2.3 Planificación de Capacidades
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.
2.1 Elementos de la Software: sistemas operativos, sistemas gestores de base de datos,

infraestructura 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.
En base a la infraestructura tecnológica del sistema, se procederá a identificar

2.2 Restricciones Técnicas 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.
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
2.3 Planificación de crecimiento y evolución estimada del sistema de información, etc.
Capacidades
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:
32
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
Se describen los niveles de la arquitectura software, mediante la definición de

3.1 Definición de Niveles de las principales particiones físicas del sistema de información, representadas
Arquitectura del Sistema como nodos (partes del sistema) y comunicaciones entre nodos (interfaces
entre las partes del sistema).
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
3.2 Diseño de Casos de Uso 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.
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
3.3 Modelo de Clases de mencionada para cada clase, así como elaborar un diagrama de clases que
Diseño 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 Subsecciones:
INTERFACES DEL 4.1 Diseño de interfaz de usuario
SISTEMA
4.2 Diseño de interfaces con otros sistemas
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
4.1 Diseño de interfaz de el caso de que existiese un prototipo de la interfaz de usuario se tomaría
usuario 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.
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
4.2 Diseño de interfaces con requieren entre ellos.
otros sistemas 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.
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
5. MODELO FÍSICO DE
en cuenta el entorno tecnológico que albergará el nuevo sistema. El diseño
DATOS del modelo físico de datos puede englobar clases, bases de datos, ficheros a
utilizar, etc.
Este punto contendrá toda aquella información de interés para la elaboración

6. ANEXOS y validación del documento de Diseño de Arquitectura Orientado a Objetos.
Este punto contendrá la definición de todos los términos utilizados en el

7. GLOSARIO documento Diseño de Arquitectura Orientado a Objetos del Sistema y que
formará parte del diccionario de la aplicación.
8. BIBLIOGRAFÍA Y En este punto se incluirán las referencias a la documentación utilizada para la

REFERENCIAS elaboración de dicho documento.
33
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.
34
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
Elaboración de la mayor parte del PP

DSI total: PPU, PPI, PPS, PPF y una parte Desarrollo
del PPNF.
(Diseño del Sistema de
Información) Desarrollo
Codificación de Scripts (SCR)
(Equipo de Codificación)
Preparación del Entorno de

Equipo de Despliegue
Construcción
Generación del Código de los

Desarrollo
Componentes y Procedimientos
(Equipo de Codificación)
(Software SFW)
CSI
Elaboración de la parte restante del
(Construcción del Sistema PPNF, completando así el PP total
de Información)
Elaboración del MUS
(Manual de Usuario) Desarrollo
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‟
35
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
1. DESCRIPCIÓN DEL En este apartado se describirá el motivo que originó el desarrollo de la

PROBLEMA/CAMBIO Y entrega. Ésta puede venir originada por una incidencia detectada o para
36
SOLUCIÓN ADOPTADA añadir o modificar cierta funcionalidad del sistema. Así mismo, se describirá
la solución técnica adoptada a grandes rasgos.
Se describen los recursos necesarios para la instalación, incluyendo:

Recursos humanos: Administradores de sistemas en los diferentes entornos, y
2. RECURSOS los usuarios finales.
EXTRAORDINARIOS 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.
Subsecciones:
3. INSTALACIÓN Y
CONFIGURACIÓN DEL 3.1 Requisitos previos
SISTEMA 3.2 Procedimiento de instalación
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
3.1 Requisitos previos 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.
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
3.2 Procedimiento de -PAR: Configuración de parámetros propios de la
instalación 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
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
4. MARCHA ATRÁS 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.
Este punto contendrá toda aquella información de interés para la elaboración

5. ANEXOS y validación del presente documento
Este punto contendrá la definición de todos los términos y acrónimos

6. GLOSARIO utilizados en el documento

REFERENCIAS elaboración del documento.
37
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
Subsecciones:
1.1 Objeto
1.2 Alcance
1. DESCRIPCIÓN DEL
1.3 Funcionalidad
SISTEMA
1.3.1 Funcionalidad sustituida
1.3.2 Funcionalidad aportada
1.4 Mapa del sistema
En este apartado se detallará cual es el objeto o función global del sistema

1.1 Objeto dentro de la organización.
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
1.2 Alcance 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.
Detalla cuáles son las diferencias funcionales entre los anteriores procesos si
1.3.1 Funcionalidad sustituida los hubiera y el nuevo sistema.
En este apartado se describirá la funcionalidad que el nuevo sistema

1.3.2 Funcionalidad aportada implementa y aporta a la organización.
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.
1.4 Mapa del sistema
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.
38
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
2. OPERATIVA DEL describirán todas las ventanas del programa, orientado a explicar el sistema a
SISTEMA 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.
Subsecciones:
3.1 Ref Proceso / Requisito
3.2 Ref Proceso / Validación
3.3 Incidencias frecuentes
3. ANEXOS
3.4 Mensajes de error
3.5 Términos y acrónimos
3.6 FAQ
3.7 Ayudas
En este apartado se ofrecerá una referencia cruzada entre los requisitos

3.1 Ref Proceso / Requisito recogidos al inicio del proyecto y los procesos que componen el sistema. Se
marcarán los procesos que resuelven un requisito y viceversa.
Se enumerarán todas las validaciones que el sistema realiza y se relacionarán

3.2 Ref Proceso / Validación con los procesos que lo componen.
En este apartado se enumerarán las incidencias más frecuentes que se pueden

3.3 Incidencias Frecuentes encontrar durante el uso de la aplicación y, junto a cada una de ellas, se
ofrecerá una solución.
Se ofrecerá una lista con todos los mensajes de error que el sistema ofrece al
3.4 Mensajes de error 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.
En este apartado se ofrecerá una lista de términos y acrónimos usados en el

3.5 Términos y acrónimos programa y una definición para cada uno de ellos.
Se ofrecerá una lista de las preguntas o dudas más frecuentes que pueden
3.6 FAQ surgirle a un usuario del sistema junto a una explicación para cada una de
ellas.
En caso de que el sistema tenga un sistema de ayuda, se ofrecerá una breve

3.7 Ayudas guía de uso sobre el mismo.
Este punto contendrá la definición de todos los términos y acrónimos

4. GLOSARIO utilizados en el documento

REFERENCIAS elaboración del documento.
39
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
Plan de pruebas que describe las

PPA
pruebas de aceptación. Elaborado en la OAC Usuario final
(Plan de Pruebas de Aceptación)
fase ASI, tras la realización del DDR.

PPU
pruebas unitarias. Elaborado en la fase Desarrollo
(Plan de Pruebas Unitarias)
de Diseño, tras la realización del DAO.

PPI pruebas de integración. Elaborado en la
(Plan de Pruebas de Integración) fase de Diseño, tras la realización del
DAO.
Desarrollo
PPS pruebas de sistema. Elaborado en la
(Plan de Pruebas de Sistema) fase de Diseño, tras la realización del
DAO.
Plan de pruebas que describe las OAC

PPF pruebas funcionales. Elaborado en la
(Plan de Pruebas Funcionales) fase de Diseño, tras la realización del
DAO.

pruebas no funcionales. Elaborado en
PPNF primer lugar en la fase de Diseño tras
Desarrollo
(Plan de Pruebas No Funcionales) la realización del DAO, y completado
en la fase de Codificación, tras
codificar el software.
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.
40
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
En esta sección se numeran los Casos de Prueba definidos en el documento y

1. DESCRIPCIÓN qué RF del DDR testea cada uno.
GENERAL 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.
Se indican los requisitos hardware y software necesarios para llevar a cabo

los diferentes Casos de Prueba. Se indican entre otros:
2. ENTORNO DE PRUEBAS -Versiones compatibles

-Entornos de prueba admitidos
-Si hacen falta herramientas auxiliares
-Tecnología de la aplicación
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
3. CASOS GENERALES 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.
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.
4. CASOS DE PRUEBA 3) Prerrequisitos: Si aplica, se indican los pasos previos necesarios
antes de comenzar a probar el CP. (Dotación de roles, creación de
(CP) 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
Se incluyen los anexos necesarios (si aplica) para la ejecución de las pruebas.
5. ANEXOS 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.
41
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)
PROGRAMA DATOS DE SALIDA

PASO DESCRIPCIÓN OBSERVACIONES
/ VENTANA ENTRADA ESPERADA
Reacción
En caso de que esperada del
Si se considera
Número Ventana de la en este paso se programa. Si
Instrucciones: qué necesario, aquí se
del paso aplicación en la tengan que la ejecución
es lo que tiene describen aclaraciones,
de que debería introducir datos cumple lo
que hacer el consejos,
ejecución encontrarse en de entrada, descrito aquí,
tester. recomendaciones y
. este paso. detalla cuáles se da por
avisos.
son. verificado este
paso.
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)
PROGRAMA DATOS DE SALIDA

PASO DESCRIPCIÓN OBSERVACIONES
/ VENTANA ENTRADA ESPERADA
Entra en la Acceso a la sección:

1 Menú principal
sección: Pruebas Pruebas
Ventana de Se mostrará el último

Pulsa el botón de: Menú principal
2 selección de fichero directorio accedido por
“Subir fichero” / Pruebas
del disco duro local la aplicación
Menú principal Se carga el fichero

Selecciona el
/ Pruebas / deseado en la
fichero deseado Fichero
3 Ventana de ventana de
del disco duro deseado
selección de selección de
local
ficheros ficheros
Menú principal Se guarda el

Rellenar la fecha
/ Pruebas / Fecha: fichero, se actualiza
de subida y pulsar
4 Ventana de la fecha de carga y
el botón Fecha actual
selección de se vuelve al menú
“Guardar”
ficheros de Pruebas
Puede tardar unos

Salir de la Menú principal Sale de la
5 segundos en completar
aplicación / Pruebas aplicación
la acción
42
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.
43
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
44
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
45
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 Tracker 36
(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’
46
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.
38Web 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/
47
48
Tabla 17. Tipos de Pruebas39
TIPOS DE PRUEBAS
REQUISITOS
TIPO NOMBRE QUE DESCRIPCIÓN
PRUEBAN
Se encargan de probar los módulos de código por

separado (en el caso de java, probar las distintas clases
DE UNIDAD CU
individualmente), garantizando el correcto
funcionamiento de cada uno sin integrarse con el resto.
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
DE INTEGRACIÓN CU 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.
Las pruebas de sistema son aquellas que prueban el

sistema por completo como un todo, ya sea a nivel de
TODO TIPO funcionalidades y de que se cumplan los casos de uso,
DE SISTEMA DE como a nivel técnico y que se cumplan todos los
REQUISITOS requisitos no funcionales.
*Gran parte de las pruebas no funcionales se realizan
como parte de las pruebas de sistema.
Se trata de pruebas que se repiten al introducir alguna

actualización o cambio al software. Una mala gestión
FUNCIONAL del control de versiones, puede llevar a que la
modificación de un aspecto de la aplicación pueda
DE REGRESIÓN CU
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.
Pruebas rápidas y sencillas a nivel superficial que se

encargan de localizar las incidencias que afectan de
DE HUMO CU manera más directa al correcto funcionamiento de la
aplicación y/o que impiden la correcta realización de
otras pruebas.
Primera fase de las pruebas de usuario, se trata de

pruebas que el usuario realiza en el entorno de
DE ACEPTACIÓN certificación mientras se realizan el resto de pruebas,
CU
(ALFA) 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.
Segunda fase de las pruebas de usuario, en la cual los

DE ACEPTACIÓN usuarios finales prueban la aplicación en el entorno de
(BETA)
CU
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.
48
Comprueban que el software implantado en un

DE DESPLIEGUE RE Y RF determinado entorno funciona correctamente a nivel de
ambiente operativo.
Verifican que las medidas de seguridad implantadas en

el software funcionan frente a ataques reales,
DE SEGURIDAD RS
sometiendo a la aplicación a diferentes amenazas
controladas.
Verifican que la aplicación se pueda actualizar de

manera sencilla cuando surja la necesidad de realizar
DE
RM cambios en ella, se necesiten añadir funcionalidades
MANTENIBILIDAD
surgidas de nuevas necesidades del Cliente o modificar
aspectos en el futuro en nuevas entregas.
Verifican que la comunicación con sistemas externos

sea adecuada y sin errores (diferenciando bien los
DE INTERFAZ RI factores que afectan a nuestra aplicación y no los de las
aplicaciones terceras con las que necesite
comunicarse).
Verifican que las necesidades de accesibilidad,

facilidad de uso de la aplicación y la interacción
DE USABILIDAD RU
software-cliente sean óptimas y se ajusten a las
NO definidas en los Requisitos de Usabilidad.
FUNCIONAL
Pruebas que fuerzan el sistema al máximo de sus
capacidades software y hardware, para comprobar si la
DE ESFUERZO O
respuesta esperada es la correcta o descubrir posibles
ESTRÉS
situaciones que causen estabilidad que no se hubieran
descubierto de otro modo.
RR
Pruebas que verifican que el sistema tiene un tiempo de
respuesta y consumo de recursos óptimos, probando
DE RENDIMIENTO
con todas las combinaciones posibles asegurando el
nivel de servicio esperado.
Verifican la tolerancia a fallos del software y su

correcto comportamiento ante diferentes situaciones,
DE FIABILIDAD
esperado según las necesidades descritas en los
Requisitos de Fiabilidad.
RFI
Provoca el fallo del sistema de todas las maneras
DE posibles, para garantizar que la recuperación de la
RECUPERACIÓN aplicación se corresponde con lo definido en los
Requisitos de Fiabilidad.
49
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 Incidencias que dificultan la

algún parámetro de calidad menor. correcta funcionalidad de la
Incidencias que impiden el
Pueden admitirse sin afectar a la entrega. Un entregable con 3 (u otra
correcto funcionamiento de la
correcta funcionalidad de la cifra convenida por la OAC) o
entrega, y necesitan ser
aplicación o la comprensión de los menos incidencias medias puede
obligatoriamente corregidas.
documentos. superar satisfactoriamente las
revisiones técnicas de la OAC. Suelen ser fallos de código, el no
Suelen consistir en no respetar el
cumplimiento de algún RF,
formato de los documentos, líneas Suelen consistir en warnings en la
documentos erróneos o vacíos, y
confusas en el código o compilación, o pequeña alteración
fallos en la aplicación
comportamientos inesperados, pero de algún RF, faltas de secciones en
sin importancia, en la aplicación. los documentos, etc
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.
50
2.6.2.1 Documentos
2.6.2.1.1 DDR
Tabla 19. Certificación DDR
CERTIFICACIÓN DDR
SECCIÓN
DEL INDICADOR DE CALIDAD GRAVEDAD
DOCUMENTO
El objetivo del sistema describe el alcance o propósito del mismo (qué es

2.1 Objetivos ALTA
y para qué sirve), aunque sin llegar a detallar sus funciones generales.
La descripción de funciones generales del sistema es completa, se cubren

ALTA
todas las necesidades del cliente que hayan sido identificadas.
Se describe la funcionalidad del Sistema sin entrar en detalles de bajo

ALTA
nivel
2.2 Características La descripción de funcionalidad debe cubrir las necesidades y

ALTA
Principales expectativas de los usuarios finales.
Si se incluye la descripción global de la arquitectura, se justifican las

ALTA
razones para su selección
La descripción de funcionalidad general o descripción global de la

ALTA
arquitectura identifica las relaciones del sistema con otros sistemas.
2.3 Restricciones Si existen restricciones, suposiciones o dependencias importantes que

ALTA
Generales puedan condicionar las soluciones de diseño del sistema están incluidas.
La descripción de los requisitos no es ambigua. ALTA
Todos los requisitos están codificados según un mismo estándar de

ALTA
nomenclatura
Las fuentes de información que hayan contribuido a la especificación de

BAJA
requisitos están claramente identificadas.
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 ALTA
Datos) o LSSI (Ley de Servicios de la Sociedad de la Información).
3. Requisitos del
En los requisitos (preferentemente en RE o RI) deben quedar claramente
Sistema
descritos todos los sistemas con los que la aplicación se relaciona y en ALTA
qué forma.
Los requisitos funcionales no hacen referencia a cuestiones técnicas de

BAJA
diseño, salvo que realmente se consideren como condicionantes.
Los requisitos se encuentra correctamente codificados y clasificados

ALTA
según su categoría
No hay dos requisitos distintos con un mismo código. ALTA
Se describen los niveles de seguridad que deben aplicarse al sistema. BAJA
51
52
Se ha representado la matriz de trazabilidad incluyendo todos los

ALTA
requisitos descritos en el documento.
4. Matrices de Al menos el 90% de los requisitos pueden ser validados. ALTA

Trazabilidad
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 ALTA
varios requisitos funcionales).
2.6.2.1.2 DAO
Tabla 20. Certificación DAO
CERTIFICACIÓN DAO
SECCIÓN
DOCUMENTO
Se describen los elementos de la infraestructura del sistema relativos al

hardware, software y comunicaciones necesarios para explotar el MEDIA
2.1 Elementos de
sistema
la infraestructura
Se detallan las medidas de seguridad MEDIA
2.2 Restricciones Si aplica, se describen las restricciones técnicas en base a la

MEDIA
Técnicas infraestructura tecnológica del sistema
2.3 Planificación Se describen la planificación de capacidad necesaria para

MEDIA
de Capacidades almacenamiento, procesamiento y comunicaciones.
En el caso de que se haya dividido el sistema, se han identificado

claramente las diferentes partes del mismo, presentando un diagrama y ALTA
detallando las interfaces que les afectan.
En el caso de que se haya dividido el sistema, se han identificado los

MEDIA
3.1 Niveles de objetos comunes.
Arquitectura
En el caso de que se haya dividido el sistema, las representaciones
MEDIA
gráficas de las partes del mismo siguen todas un mismo formato.
En el caso de que se haya dividido el sistema, cada parte del sistema se

MEDIA
ha identificado debidamente.
Se describen los casos de uso en base a los requisitos establecidos por el

3.2 Casos de Uso MEDIA
usuario.
El diseño esta realizado en coherencia con la información del sistema

ALTA
concebido en la fase de Análisis.
Los gráficos del Diagrama de Clases contienen un conjunto de gráficos

3.3 Clases encadenados que recogen las relaciones de diseño entre las clases del MEDIA
sistema.
El diseño de Clases incluye interfaces de comunicación con los sistemas

MEDIA
externos al sistema en estudio.
52
El diagrama de clases refleja la relación con la Base de Datos y la

MEDIA
interfaz gráfica.
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 ALTA
ella (interfaz, componente reutilizado, etc.)
Para cada clase se ha documentado detalladamente sus atributos más

MEDIA
significativos indicando su descripción, tipo y restricciones.
Para cada clase se ha documentado detalladamente cada uno de sus

métodos indicando su descripción, tipo, restricciones, visibilidad y MEDIA
lógica.
Se definen las interfaces con otros sistemas y entre los subsistemas de

ALTA
la aplicación.
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
MEDIA
inventario de los objetos que contiene el diagrama y una descripción de
la navegación.
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.
MEDIA
4.1 Interfaz de Se incluirán informes, mensajes de error y otro tipo de información
Usuario relevante.
Se presenta un catálogo de controles y elementos de diseño de la interfaz

BAJA
del sistema, donde se recoge la operatividad de la misma.
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 BAJA
impresora a usar.
4.2 Interfaz con Se detallará la interfaces con otros sistemas, indicando los datos y el
MEDIA
otros Sistemas formatos de los mismos que se van a transferir entre los sistemas.
Si se representa, el modelo Físico deberá coincidir con la descripción de

5. Modelo Físico
sus elementos. (Los elementos pueden haberse descrito a continuación o MEDIA
de Datos
ser adjuntados en un archivo).
2.6.2.1.3 MIC
Tabla 21. Certificación MIC
CERTIFICACIÓN MIC
SECCIÓN
DOCUMENTO
1. Descripción del Se ha introducido una descripción de alto nivel de los

MEDIA
cambio/problema problemas/cambios junto con la solución adoptada.
53
54
2. Recursos Si existen recursos extraordinarios para la instalación de la entrega, éstos

ALTA
Extraordinarios se han especificado de forma clara y concisa.
Si es necesario coordinar la instalación de la entrega con alguna otra,

ALTA
ésta se ha identificado de forma clara y concisa.
Se indica si es necesario desconectar a los usuarios para realizar la

ALTA
instalación.
Se indica si es necesario realizar un backup del esquema de la aplicación

3.1 Requisitos ALTA
previo al proceso de instalación.
Previos
Se indica si es necesario realizar un backup del software de la aplicación
ALTA
previo al proceso de instalación.
Si es necesario salvaguardar datos de la configuración actual de la

aplicación para utilizarlos posteriormente en el proceso de instalación, ALTA
éstos han sido especificados de forma clara y concisa.
Los pasos del procedimiento de instalación se identifican mediante un

ALTA
secuencial único y la tabla está ordenada por dicho campo.
3.2 Procedimiento El tipo de tarea se ha especificado correctamente. MEDIA

de Instalación
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 ALTA
la instalación.
Si es necesario eliminar sinónimos públicos para realizar la marcha atrás,

ALTA
se han indicado sus identificadores de forma correcta.
Si es necesario eliminar roles para realizar la marcha atrás, se han

ALTA
indicado sus identificadores de forma correcta.
Se indica si es necesario restaurar el esquema de base de datos para

ALTA
realizar la marcha atrás.
4. Marcha Atrás
Se indica si es necesario restaurar el software anterior para realizar la
ALTA
marcha atrás.
Los scripts a ejecutar para la marcha atrás se han incrustado en el

ALTA
apartado correspondiente.
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
INDICADOR DE CALIDAD GRAVEDAD
DOCUMENTO
1.1 Objeto Proporciona información suficiente para que el lector pueda BAJA
54
comprender la función global del sistema dentro de la organización.
En caso de que la aplicación sustituya otros procesos existentes en la

organización, proporciona información suficiente para que el lector
MEDIA
pueda comprender los procesos sustituidos y las diferencias
1.3 Funcionalidad funcionales del nuevo sistema.
Se describen todas las funcionalidades aportadas por el sistema y los

ALTA
procesos involucrados en ella.
Se proporciona un resumen general mediante diagramas de formato libre

1.4 Mapa del
de la composición del sistema, módulos, entorno, etc que permite al MEDIA
Sistema
usuario tener un conocimiento a alto nivel del sistema descrito.
Se describen todos los procesos (o ventanas) incidiendo en su

2. Operativa del
descripción y qué acciones permite el sistema realizar con el proceso (o MEDIA
Sistema
ventana) descrito.
3.3 Incidencias Se enumeran las incidencias más frecuentes y, junto a cada una de ellas,
BAJA
Frecuentes se ofrece una solución.
Se ofrece una lista con todos los mensajes de error que el sistema ofrece
3.4 Mensajes de
al usuario, bien sea a través de ventanas o de ficheros de log, y se adjunta MEDIA
Error
una descripción más extensa para cada uno de ellos.
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
DOCUMENTO
Se ha realizado una descripción de la funcionalidad completa del sistema, así

ALTA
del correctivo y/o evolutivo que incluya la entrega
1. Descripción Se han descrito y codificado claramente los casos de pruebas a ejecutar,

General ALTA
distinguiendo si se corresponden con un correctivo o evolutivo.
Se han identificado los requisitos asociados a los casos de pruebas.

ALTA
(Obligatorio en evolutivos y mantenimientos)
Se ha identificado claramente el entorno de prueba necesario, completando

2. Entorno de
todos los apartados de la plantilla. (Si alguno no aplica, indicar N/A y ALTA
Pruebas
explicar la razón)
Se incluyen aquellos casos de prueba que no se corresponden con el objetivo

ALTA
de la entrega, pero sirven para fijar prerrequisitos u otros.
3. Casos
Generales
Se describe la creación de los usuarios que serán necesarios en los casos de
ALTA
prueba del documento.
55
56
La información de cada caso de prueba especifica con claridad todos los

ALTA
aspectos necesarios para su realización.
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
4. Casos de Si la prueba incluye algún elemento especial, se debe especificar. ALTA

Prueba
Se indica el tiempo necesario para ejecutar la totalidad del caso de prueba.
MEDIA
(Expresado en minutos)
Para cada caso de prueba que se divida en ciclos de prueba, se explicará cada
ALTA
uno de los ciclos de prueba de forma ordenada por separado.
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 ALTA
descripción general.
Para cada caso de pruebas se debe especificar el orden de ejecución. Si el

ALTA
orden es correlativo, se debe indicar como 'Secuencial'.
2.6.2.1.6 Defectos genericos en documentos

Tabla 24. Defectos genéricos en documentos
CERTIFICACIÓN DE LOS DOCUMENTOS EN GENERAL
SECCIÓN
DOCUMENTO
Ha de comprobarse la coherencia del nombre identificativo del entregable. MEDIA
Ha de comprobarse la coherencia del versionado del entregable. MEDIA

N/A
Se han de cumplimentar correctamente todos los campos de la Hoja de
MEDIA
Control.
El entregable debe adaptarse a la plantilla definida para el resto de

MEDIA
documentos
56
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.
BAJA
En los documentos que se necesite un formato específico se indicará
explícitamente.
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 BAJA
o frase.
Cuando un documento anexe información adicional (por ejemplo, el modelo

del análisis realizado con una herramienta CASE), la entrega del documento
BAJA
ser realizará en un fichero comprimido ZIP que contendrá el documento y el
resto de ficheros organizados en subdirectorios.
El índice del documento se encuentra correcto y actualizado en cuanto a

BAJA
números de páginas.
Existen descripciones de las convenciones notacionales o acrónimos

BAJA
empleados.
Todo documento externo al entregable utilizado para la realización del

BAJA
mismo debe indicarse correctamente en el apartado de Referencias.
Cuando un documento no se refiera a la totalidad del sistema, en la

BAJA
introducción deberá aclararse a qué parte del sistema afecta.
57
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
Los nombres de los scripts deben respetar el formato <nnn>_<nombre>.<ext>, tal como se define
ALTA
en la normativa técnica correspondiente. Siempre, aunque sea un solo Script.
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 ALTA
de archivos con extensión ".syn".
Los sinónimos públicos se crean mediante la orden "CREATE" y nunca con "CREATE OR
ALTA
REPLACE".
No se permite la concesión del permiso GRANT CREATE SESSION en los scripts, sino que debe
ALTA
estar convenientemente documentado en el Manual de Instalación y Configuración.
Ningún script que forme parte de una entrega llama o ejecuta otro script SQL almacenado en
ALTA
archivo.
Los scripts entregados deben ejecutarse correctamente en entornos UNIX desde línea de comando
ALTA
mediante SQLPLUS.
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
MEDIA
indiquen qué operación se va a realizar a continuación, conforme a lo descrito en la normativa
técnica.
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, ALTA
especialmente cuando existe un proceso de migración que cargará los datos.
En las cargas y migraciones masivas de datos, deben desactivarse previamente los índices sobre las
ALTA
tablas en las que se van a introducir los datos.
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 ALTA
base de datos.
Las sentencias para la eliminación de sinónimos públicos se entregan únicamente dentro del MIC ALTA
58
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
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
ALTA
ningún tipo de configuración para su instalación
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

BAJA
cap.webcap.sql.ConnectionFactory
La información interna de la aplicación, como los datos que maneja, usuarios, etc, se almacena en
ALTA
BBDD y no en ficheros
Las conexiones realizadas a BBDD deben cerrarse

ALTA
automaticamente apenas dejen de usarse. No se pueden quedar conexiones abiertas.
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

ALTA
funciones de BBDD.
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
59
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
MEDIA
empaquetar por aplicación utilizando la directiva package
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
MEDIA
mecanismo de validación de datos (fechas, tipos de datos, etc.).
La aplicación consta de 2 usuarios a nivel de BBDD, uno es el propietario del esquema y el otro es
ALTA
el usuario que se utiliza para acceder.
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
MEDIA
el método POST
Convertir todas las salidas generadas según la codificación HTML apropiada:

- > en >
MEDIA
- < en <
- etc.
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
MEDIA
parámetros)
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
60
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
ALTA
de JAVA y del intérprete de compilación.
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

ALTA
comportamiento debe estar documentado.
No se utilizarán procedimientos almacenados java en Oracle ALTA
2.6.2.2.3 Defectos genericos en codigo

Tabla 27. Defectos genéricos en código
CERTIFICACIÓN DEL CÓDIGO EN GENERAL
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
MEDIA
datos.
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

MEDIA
o cursores.
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
MEDIA
índices y hacen más lenta la consulta.
No utilizar funciones sobre las columnas indexadas, ya que inhabilita el indice. MEDIA
Uso de Exist e IN de forma eficiente. MEDIA
61
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 MEDIA
eficiente.
Evitar el uso de GOTO en Pl/Sql. ALTA
Los Triggers no deben acceder a tablas directamente,

MEDIA
solo a través de procedimiento.
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
MEDIA
está vigente
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
62
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
BAJA
del char
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

MEDIA
columnas de tablas.
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
63
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
Por muchas incidencias bajas que

Baja 0-∞ se encuentren, el entregable se
considera válido a todos los
ACEPTADO efectos.
Se recomienda corregir las
Media 0-3 incidencias bajas para optimizar
el resultado final del entregable
Si hay 3 o más incidencias

medias, el entregable se considera
válido.
ACEPTADO CON Sin embargo, la no corrección de
Media 3-∞
RESERVAS dichas incidencias puede conducir
a confusión en el cliente, o a
problemas futuros de categoría
menor.
Si hay una sola incidencia alta, el

entregable no se considera válido,
Alta 1-∞ RECHAZADO 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’
64
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
65
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.
66
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 Jenkins 42. 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.
42Web de referencia de las herramientas software:

Jenkins: https://jenkins.io/
SonarQube: https://www.sonarqube.org/
67
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)
En esta sección se aportan datos generales de la certificación, como pueden

1. INFORMACIÓN ser el nombre del proyecto, su anagrama, la versión, las fechas de entrega,
GENERAL reclamación y verificación, y la persona responsable de la certificación.
Apartado que resume las pruebas realizadas por la OAC para la entrega en
2. CERTIFICACIÓN DE LA cuestión, y el resultado de cada una de ellas.
APLICACIÓN
Se indica qué tecnología se ha usado para realizar las pruebas, las versiones
3. ENTORNO DE PRUEBAS de software y las características principales de hardware, y otros aspectos
DE CERTIFICACIÓN técnicos.
4. RESUMEN DE 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
ENTREGABLES Y revisión y el resultado final de la misma, (si está aceptado, rechazado, o
REVISIONES aceptado con reservas).
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.
5. Pruebas de Despliegue 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.
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
6. Pruebas Funcionales pruebas funcionales y la persona responsable.
Se verifica si se cumplen los RF. Se añade también el nombre del PPF
utilizado.
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
7. Modelo de Datos 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.
Se incluye el PES generado por la OAC y el informe SonarQube generado

8. Pruebas Estáticas del
por la herramienta Jenkins. Se añade una breve enumeración de los archivos
Software con incidencias, y errores totales encontrados en los ficheros de código Java.
Esta sección recoge el resultado de la realización de las pruebas de unidad

9. Pruebas de Unidad definidas en en PPU.
68
Esta sección recoge el resultado de la realización de las pruebas de

10. Pruebas de Integración integración definidas en en PPI.
Esta sección recoge el resultado de la realización de las pruebas de sistema

definidas en en PPS.
11. Pruebas de Sistema
Se realizará una segunda fase de pruebas de sistema cuando se implante la
aplicación en el entorno de Cliente.
Describe el resultado de las pruebas de regresión, en especial cuando el

12. Pruebas de Regresión software ya ha sido revisado una primera vez, y se vuelven a probar módulos
que estaban bien que ahora podrían fallar.
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
13. Pruebas de Humo 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.
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
14. Pruebas No Funcionales  Pruebas de Usabilidad
 Pruebas de Esfuerzo / Estrés
 Pruebas de Rendimiento
 Pruebas de Fiabilidad
 Pruebas de Recuperación
Se incluyen los anexos necesarios (si aplica) para la ejecución de las pruebas.
15. ANEXOS 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.
Sección en la que se definen los anagramas usados y se explican los

16. GLOSARIO acrónimos utilizados.
17. BIBLIOGRAFÍA Y Apartado en el que consta la información externa utilizada en las pruebas, o
REFERENCIAS 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’
69
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
Desarrollo,
ASI DDR DP
OAC y Cliente
Desarrollo (Codificación),
DAO Desarrollo (Diseño)
OAC y Cliente
DSI PP Desarrollo OAC y Cliente
Desarrollo
SCR OAC y Cliente
(Codificación)
MIC
Desarrollo OAC y Cliente
CSI MUS
Desarrollo
SFW OAC y Cliente
(Codificación)
IPC
CEI OAC Desarrollo y Cliente
IPA
70
Según la norma UNE/ISO/IEC 90003:200544, 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.
44Contrastando 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’
71
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
72
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’
73
74
Tabla 31. Tareas de Despliegue
TAREAS DE DESPLIEGUE
FASE TAREA DESCRIPCIÓN
El equipo de Despliegue creará o preparará en

caso de que existiera previamente el entorno de
Previo a la Creación o preparación de Desarrollo y el de Producción. Tarea necesaria
codificación del los entornos de Desarrollo e para que el equipo de Codificación codifique el
software Integración software en un entorno optimizado para ello, así
como un entorno para probar las relaciones del
software con otros sistemas de información.
Despliegue de la aplicación
No es necesario ya que el software se ha creado en
en los entornos de
dichos entornos.
Desarrollo e Integración
El equipo de Despliegue creará o preparará en

caso de que existiera previamente el entorno de
Tras la codificación Creación o preparación del Certificación. El propósito es brindar a la OAC un
del software y entorno de Certificación entorno optimizado para la certificación de la
previo a su aplicación recién codificada por Desarrollo, donde
certificación por la puedan ejecutar todas las pruebas sin problemas.
OAC
El equipo de Despliegue implanta la aplicación en
el entorno de Certificación para que la OAC
Despliegue de la aplicación
pueda comenzar las pruebas. Comenzará con las
en el entorno de
pruebas de despliegue para comprobar la
Certificación
estabilidad de la aplicación en un entorno
diferente del cual se creó.
Operaciones mediante las cuales prepara el

Creación o preparación del
entorno de Cliente para que pueda soportar la
entorno de Cliente
aplicación en todos sus ámbitos.
Supone la última tarea del equipo de Despliegue

durante el proceso software. Se implantará la
Tras la certificación aplicación ya certificada por la OAC en el entorno
del software por la Cliente para que los usuarios realicen las pruebas
OAC Beta, y, en caso de éxito de las mismas, tener listo
Despliegue de la aplicación el software instalado para usarlo en el futuro sin
en el entorno de Cliente 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
48Tabla 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’
74
Continuando con el proceso software, tras la realización de las pruebas Alfa de Aceptación por parte del
49
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’
75
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
76
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.
Una vez recibido el documento del Histórico de Proyecto de parte del Director de Proyecto, se procederá a la
53
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’
77
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’
78
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/
79
80
Herramientas CASE
3 HERRAMIENTAS CASE
E
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.
80
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‟.
81
82
Herramientas CASE
 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.
82
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.
83
84
Herramientas CASE
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.
84
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.
85
86
Conclusiones
4 CONCLUSIONES
E
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.
86
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 alos 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
87
88
Referencias
[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/
88
89
90
Glosario
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
90
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
91
92
Glosario
92

Trabajo Fin Carrera Proceso Calidad

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo Fin Carrera Proceso Calidad

Cargado por

Copyright:

Formatos disponibles

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de

Proceso de Calidad en Ingeniería del Software

Autor: Antonio Marco Rodrigo Jiménez

e Equation Chapter 1 Section 1

Dpto. Ingeniería Telemática

Proceso de Calidad en Ingeniería del Software

Dpto. de Ingeniería Telemática

Autor: Antonio Marco Rodrigo Jiménez

Tutora: Isabel Román Martínez

Acuerdan otorgarle la calificación de:

A Antonio Luna, Cata, Dylan, Kico, Javi, Lourdes y el Señor de IT

Tabla 1. Modelo en Cascada 1

Figura 1. Diagrama de flujo del proceso software 8

Todos los requisitos deben quedar recogidos al inicio,

Todos los aspectos del proyecto están bien claros

Es un modelo fácilmente comprensible e

Permite que lo realice un equipo con poca

1.2 Definición de entidades

1.2.1 Calidad / OAC (Oficina del Aseguramiento de la Calidad)

1.2.3 Equipo de Desarrollo

1.2.5 DP (Dirección de Proyecto)

1.2.6 JP (Jefe de Proyecto)

1.2.7 Comité de seguimiento3

3 Definición de entidades basada en ‘SAC-Definición_de_roles’ MÉTRICA V.3

1.3 Interacción entre entidades

2) Herramientas para la transferencia de archivos y control de versiones: Se trata de herramientas

3) Herramientas de comunicación directa: Se trata de herramientas de comunicación directa que

7QM: https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp, url accesible desde un proxy

1.4 Definición de Entornos

Creado por el equipo de despliegue, diseñado para diseñar,

Creado por el equipo de despliegue, diseñado para probar la

Creado por el equipo de despliegue, diseñado para realizar

Se trata del entorno donde el cliente se encuentra, entorno

8 Bas{ndonos en la sección 3. ‚Descripción de Actividades, creación de entornos‛, del documento:

1.5 Diagrama de flujo del proceso software

Figura 1. Diagrama de flujo del proceso software

1.6 Detalle Del Proceso

1) El cliente realiza un análisis de la realidad de su entorno, y descubre problemas o carencias, que

9) Cuando el software y documentos elaborados estén definitivamente corregidos y revisados por la

2.2 Comienzo Del Proyecto 10

2.2.1 Análisis de la Realidad

2.2.1.1 Sin Software previo11

10Basado en la sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 12207:1995)

2.2.1.2 Con Software previo12

Recomendaría el software a mis colegas X

Se ha detenido inesperadamente en algún

A veces en algunos puntos, no sé cómo continuar X

La información de ayuda que brinda no me resulta

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

2) Entrevista: El Cliente concreta reuniones presenciales con los empleados de la empresa, y

3) Observación: Los analistas observarán el funcionamiento de la empresa, y analizarán cómo

2.2.2.1 Sin concurso

15 Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018:

2.2.2.2 Con concurso

Figura 2. Diagrama de Flujo Concurso Público

2.2.2.2.1 Preparacion del Pliego de Prescripciones Tecnicas

Tabla 4. Contenidos típicos de un Pliego de prescripciones técnicas18

TÉCNICOS Descripción de los trabajos

Régimen jurídico: quién contrata y bajo qué forma jurídica

Requisitos de las ofertas: