TFG-1835-RODRIGO

Vista previa del material en texto

e Equation Chapter 1 Section 1 
Trabajo Fin de Grado 
Grado en Ingeniería de las Tecnologías de 
Telecomunicación 
Proceso de Calidad en Ingeniería del Software 
Autor: Antonio Marco Rodrigo Jiménez 
Tutora: Isabel Román Martínez 
Dpto. Ingeniería Telemática 
Escuela Técnica Superior de Ingeniería 
Universidad de Sevilla 
 Sevilla, 2018 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Trabajo Fin de Grado 
G.I.T.T. 
 
 
 
 
 
Proceso de Calidad en Ingeniería del Software 
 
 
Autor: 
Antonio Marco Rodrigo Jiménez 
 
 
Tutora: 
Isabel Román Martínez 
Profesora colaboradora 
 
 
 
Dpto. de Ingeniería Telemática 
Escuela Técnica Superior de Ingeniería 
Universidad de Sevilla 
Sevilla, 2018 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Trabajo Fin de Grado: Proceso de Calidad en Ingeniería del Software 
 
 
 
 
 
Autor: Antonio Marco Rodrigo Jiménez 
Tutora: Isabel Román Martínez 
 
 
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: 
Presidente: 
 
 
 
Vocales: 
 
 
 
 
Secretario: 
 
 
 
 
Acuerdan otorgarle la calificación de: 
 
Sevilla, 2018 
 
 
 
El Secretario del Tribunal 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Agradecimientos 
A Antonio Luna, Cata, Dylan, Kico, Javi, Lourdes y el Señor de IT 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Resumen 
Este proyecto tiene como objetivo realizar un estudio teórico de un proceso de calidad en el ámbito del 
desarrollo software. Se describirán todas las partes de un modelo software en cascada, destacando el papel y la 
intervención del departamento de calidad en las diferentes secciones. 
Se ha elegido un modelo en cascada porque es el modelo software que se utiliza en ciertos proyectos dentro de 
everis. La labor en dichos proyectos consiste en formar parte de la OAC (Oficina del Aseguramiento de la 
Calidad), que realiza revisiones técnicas a los proyectos software para el cliente: CAPDER (Consejería de 
Agricultura, Pesca y Desarrollo Rural), de la Junta de Andalucía. 
En este proyecto se explicarán todas las posibles situaciones y casos dentro del ámbito del desarrollo software, 
y se detallará cómo actúa la OAC en cada una de ellas. No obstante, se desarrollarán con más detalle aquellas 
situaciones y casos que coincidan con las funciones directas de un técnico de calidad. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Abstract 
The main purpose of this project is to elaborate a theoretical essay about a quality process, regarding software 
development. Every part of a cascade software model will be described, focusing on the role and tasks of the 
quality department through the different sections. 
A cascade software model has been chosen because it is the software model used in some project inside everis. 
The main task in such projects consisted on being part of the QAD (Quality Assurance Department), which 
performs technical reviews to CAPDER software projects (Consejería de Agricultura, Pesca y Desarrollo 
Rural), from the Junta de Andalucía. 
In this project, all possible situations will be taken into account regarding software development, and the main 
purpose of the QAD will be detailed in each. However, those situations related to being a quality technician 
will be furtherly developed in detail. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Índice 
Agradecimientos 9 
Resumen 11 
Abstract 13 
Índice 14 
Índice de Tablas 17 
Índice de Figuras 20 
1 Descripción general del sistema 1 
1.1 Modelo 1 
1.2 Definición de entidades 2 
1.2.1 Calidad / OAC (Oficina del Aseguramiento de la Calidad) 2 
1.2.2 Cliente 2 
1.2.3 Equipo de Desarrollo 3 
1.2.4 Despliegue 4 
1.2.5 DP (Dirección de Proyecto) 4 
1.2.6 JP (Jefe de Proyecto) 4 
1.2.7 Comité de seguimiento 4 
1.3 Interacción entre entidades 5 
1.4 Definición de Entornos 7 
1.5 Diagrama de flujo del proceso software 8 
1.6 Detalle Del Proceso 9 
2 Descripción específica del sistema 11 
2.1 Introducción 11 
2.2 Comienzo Del Proyecto 11 
2.2.1 Análisis de la Realidad 11 
2.2.2 Adjudicación 14 
2.3 Definición Del Proyecto 27 
2.4 Diseño Del Proyecto 31 
2.4.1 DAO (Diseño de Arquitectura Orientado a Objetos) 31 
2.5 Codificación Del Proyecto 35 
2.5.1 Preparación Del Entorno de Construcción 36 
2.5.2 Generación de Código 36 
2.5.3 MIC (Manual básico de Instalación y Configuración) 36 
2.5.4 MUS (Manual de Usuario) 38 
2.5.5 Elaboración del PP (Plan de Pruebas) 40 
2.6 Control de Calidad 44 
2.6.1 Pruebas 45 
2.6.2 Incidencias 50 
2.6.3 Informes de Revisión Técnica (IRT) 64 
2.6.4 Informes de Calidad 66 
2.7 Pruebas de Usuario 72 
2.7.1 Pruebas Alfa 72 
2.7.2 Pruebas Beta 72 
2.8 Despliegue 73 
2.9 Finalización Del Proyecto 76 
2.9.1 Mantenimiento 76 
2.9.2 Histórico de Proyecto 77 
2.9.3 Informe de Fin de Proyecto 78 
2.9.4 Cierre 79 
3 Herramientas CASE 80 
3.1 Herramientas CASE para la ingeniería de requisitos 80 
3.2 Herramientas CASE para el diseño 80 
3.3 Herramientas CASE para la codificación 81 
3.4 Herramientas CASE para el aseguramiento de la calidad 81 
3.4.1 JIRA 81 
3.4.2 QM 82 
3.4.3 Mantis 83 
3.4.4 TOAD Oracle 83 
3.4.5 Jenkins y Sonarqube 84 
3.4.6 SoapUI 84 
3.4.7 KeePass 85 
3.4.8 Notepad++ 85 
3.4.9 DiffPDF 85 
3.4.10 VirtualBox 85 
4 Conclusiones 86 
Referencias 87 
Glosario 90 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Índice de Tablas 16 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ÍNDICE DE TABLAS 
 
Tabla 1. Modelo en Cascada 1 
Tabla 2. Entornos 7 
Tabla 3. Extracto de cuestionario de satisfacción del usuario con el software que utiliza 12 
Tabla 4. Contenidos típicos de un Pliego de prescripciones técnicas 16 
Tabla 5. Contenidos típicos de una Oferta 21 
Tabla 6. Entregables de un Proyecto Software 22 
Tabla 7. Matriz de Evaluación de Alternativas 25 
Tabla 8. Tipos de Requisitos 28 
Tabla 9. Estructura de un DAO 32 
Tabla 10. Tareas DSI y CSI de Desarrollo 35 
Tabla 11. Estructura de un MIC 36 
Tabla 12. Estructura de un MUS 38 
Tabla 13. Estructura del PP 40 
Tabla 14. Estructura de un PPF 41 
Tabla 15. Estructura de un Caso de Prueba 42 
Tabla 16. Ejemplo de Caso de Prueba 42 
Tabla 17. Tipos de Pruebas 48 
Tabla 18. Tipos de Incidencias según su gravedad 50 
Tabla 19. Certificación DDR 51 
Tabla 20. Certificación DAO 52 
Tabla 21. Certificación MIC 53 
Tabla 22. Certificación MUS 54 
Tabla 23. Certificación PP 55 
Tabla 24. Defectos genéricos en documentos 56 
Tabla 25. Certificación SCR de base de datos 58 
Tabla 26. Certificación SFW 59 
 
 Índice de Tablas 18 
Tabla 27. Defectos genéricos en código 61 
Tabla 28. Resultado de evaluación de un entregable 64 
Tabla 29. Estructura de un IPC 68 
Tabla 30. Lista final de entregables 70 
Tabla 31. Tareas de Despliegue 74 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ÍNDICE DE FIGURAS 
 
Figura 1. Diagrama de flujo del proceso software 8 
Figura 2. Diagrama de Flujo Concurso Público 15 
Figura 3. Ejemplo de Pliego 17 
Figura 4. Diagrama de Flujo Evaluación de Oportunidad 19 
Figura 5. Esquema Evaluación Oportunidad 20 
Figura 6. Ejemplode Diagrama WBS 24 
Figura 7. Ejemplo de Matriz de Trazabilidad 29 
Figura 8. Ejemplo de Informe de Fin de Proyecto 78 
 
 
 
 
 
 
 
 
 
 
 
 
 
file:///D:/EXHOUL/Desktop/TFG/TFG%20SUP.docx%23_Toc517894872
file:///D:/EXHOUL/Desktop/TFG/TFG%20SUP.docx%23_Toc517894873
file:///D:/EXHOUL/Desktop/TFG/TFG%20SUP.docx%23_Toc517894874
 
 
 
 
 
 
 
 
 
 
1 
 
 
1 DESCRIPCIÓN GENERAL DEL SISTEMA 
1.1 Modelo 
ara el proceso software que vamos a explicar en este TFG, hemos elegido un modelo en cascada, 
que es el que se usa en mis prácticas de empresa. 
El modelo en cascada (basándonos en la publicación de Winston Royce, 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 
Alto nivel de satisfacción del cliente 
Todos los requisitos deben quedar recogidos al inicio, 
impidiendo la definición de nuevos requisitos durante el 
desarrollo del proyecto 
Permite suplir pérdidas en el equipo de desarrollo 
con bastante facilidad 
Las pruebas se realizan muy tarde, provocando que los 
errores tarden en identificarse y corregirse 
Todos los aspectos del proyecto están bien claros 
y definidos desde el principio 
Si hay problemas, tendrán un alto coste en tiempo y dinero 
Es un modelo fácilmente comprensible e 
implementable 
La creación del software tarda mucho tiempo 
Permite que lo realice un equipo con poca 
experiencia en el desarrollo software debido a su 
simplicidad 
Las etapas necesitan esperar a que acabe la anterior 
Estas características del modelo en cascada hacen que sea especialmente efectivo en proyectos estáticos, 
bien definidos desde el principio en los que sea muy poco probable la introducción de cambios durante el 
desarrollo del software (En adelante SFW). Se beneficiarán de este modelo empresas que: 
1) Cuenten con un gran capital, que se puedan permitir el coste en tiempo y dinero ante la aparición 
de problemas y errores. A costa de este gasto, garantizarán la satisfacción del cliente, 
aumentando las posibilidades de trabajar juntos en el futuro. 
2) Tengan una plantilla extensa y renovable, la cual dará lugar a equipos humanos poco 
experimentados. El modelo en cascada es el más fácil para dichos equipos. 
En resumen, este TFG propondrá un modelo de proceso software idóneo para grandes empresas que 
contraten nuevos empleados regularmente, especializada en proyectos estáticos bien definidos al inicio. 
 
1 ‘Managing the Development of Large Software Systems’, Winston Royce, 1970, creador del modelo de desarrollo software en cascada, m{s 
tarde avalado por las publicaciones: ‘Software Engineering Economics’, Barry Boehm, 1981 y ‘Software Engineering’, Ian Sommerville, 1985 
P 
 
 Descripción general del sistema 
 
 
2 
1.2 Definición de entidades 
A continuación vamos a detallar las diferentes entidades, personas, o grupos de personas que van a 
participar en el proceso software, y en el proceso de calidad. Definiremos quién forma cada entidad, qué 
función tiene dentro del proceso software y cómo se relacionan entre ellas. Realizaremos dicha definición 
de entidades basándonos en el estándar MÉTRICA v.3. 
MÉTRICA es un estándar de desarrollo software, realizado por el Gobierno de España, cuya última 
versión (versión 3) se publicó en 2001. Durante mis prácticas de empresa se utilizaba como referencia 
este estándar (en adelante MÉTRICA V.3) y es el que utiliza el SAC (Sistema de Aseguramiento de la 
Calidad) dentro del departamento de calidad como guía y normativa. 
MÉTRICA v.3 está basada en los estándares internacionales: ISO/IEC 12207 (Information Technology - 
Software Life Cycle Processes) y ISO/IEC 15504 SPICE (Software Process Improvement and Assurance 
Standards Capability Determination)
2
. 
1.2.1 Calidad / OAC (Oficina del Aseguramiento de la Calidad) 
El departamento de calidad o OAC tiene como misión garantizar la calidad del producto software como 
tal, asociado a un proyecto de desarrollo, encargándose de la ejecución de las pruebas tanto funcionales 
como técnicas, detección de incidencias tanto de los documentos como del software generados por el 
resto de entidades y elaboración de informes con el resultado de las pruebas llevadas a cabo. 
También es el órgano encargado de la supervisión y de la evaluación de los proyectos, del cumplimiento 
de la metodología definida. Participa en la revisión de los productos seleccionados para determinar si son 
conformes o no a los procedimientos, normas o criterios especificados, comprobando que se han llevado a 
cabo las medidas preventivas o correctoras necesarias. Durante todas las etapas del proceso software, la 
OAC realizará el número de revisiones técnicas necesario hasta que el entregable en cuestión supere 
dichas revisiones satisfactoriamente. 
La OAC también será aquella figura encargada de la validación de los modelos de datos conceptual, 
lógico y físico, generados durante el análisis y diseño del software, en cuanto a nomenclatura, 
normalización, rendimiento, etc. 
El departamento de calidad será la sección a la que prestaremos especial atención en este documento, en 
la que profundizaremos en la sección 2.6 Control de Calidad. 
1.2.2 Cliente 
El cliente es aquella persona, física o jurídica, que comienza el proceso software. El cliente es aquel que, 
tras un análisis de la realidad de su entorno, encuentra una carencia, problema, o posible mejora de su 
sistema o entorno. Dividiremos al cliente en 2 tipos: 
 Persona física: Cliente formado por una única persona, la cual realizará el análisis de realidad de 
su entorno, y decidirá si necesita o no ayuda externa para llevar a cabo la tarea a realizar. 
 Persona jurídica: Cliente consistente en una empresa, organismo o asociación. 
o Empresas que no recurren a un concurso: Este cliente buscará soluciones por su 
cuenta a los problemas o carencias analizados, o buscará ayuda de un tercero 
específicamente seleccionado, ya sea una ayuda gratuita personalizada, o la venta de un 
servicio. 
o Empresas que recurren a un concurso: Este cliente es en el que nos centraremos en 
este documento. Consiste en una empresa, organismo o asociación, que para solucionar 
los problemas analizados, publica un pliego de prescripciones técnicas, y, a través de un 
 
2 A falta de disposición a texto completo de las normas ISO mencionadas, utilizaremos como referencia la norma UNE 71044 – 1999 
(AENOR), equivalente a la norma ISO/IEC 12207:1995. 
 
3 
 
3 Proceso de Calidad en Ingeniería del Software 
 
concurso, otras empresas, organismos o asociaciones presentarán sus ofertas para cubrir 
lo mejor posible las necesidades del cliente al precio más razonable. El cliente elegirá 
qué empresa llevará a cabo su proyecto basándose en la reputación, confianza, 
efectividad y presupuesto. 
La empresa cliente designará a un RAU (Responsable del Área Usuaria), que será el interlocutor 
representativo de la empresa cliente durante todo el proceso software en adelante. Toda comunicación 
entre las diferentes entidades con el cliente se gestionará a través del RAU. 
El RAU se encargará de realizar y/o gestionar la realización de las pruebas alfa y beta del software una 
vez esté codificado por el equipo de desarrollo y revisado y probado por el departamento de calidad. Las 
pruebas alfa las realizará en el entorno de certificación, sin que sea necesarioel despliegue final de la 
aplicación. Las pruebas beta las realizará una vez la aplicación ya haya sido desplegada por el equipo de 
despliegue, en su propio entorno de cliente. En ambas pruebas, comunicará al departamento de calidad las 
incidencias o problemas que encuentre, para que éste las revise y, a su vez, dé parte al equipo 
correspondiente para que las corrija. 
1.2.3 Equipo de Desarrollo 
Figura encargada del desarrollo del software, en todo su alcance, desde su inicio hasta su mantenimiento. 
Es el encargado de analizar las necesidades del software, modelarlo, diseñarlo y construirlo, realizando 
los planes de pruebas necesarios para generar productos de calidad que satisfagan las necesidades 
planteadas inicialmente. Es el encargado de elaborar la documentación asociada al proceso de desarrollo y 
de revisarla y actualizarla, si fuese necesario. 
Está formado por dos entidades bien diferenciadas: 
1.2.3.1 Diseño 
El equipo de diseño es la entidad encargada de elaborar el documento de diseño del software. Este equipo 
analizará los requisitos exigidos por el cliente, para encontrar la manera óptima de organizar y codificar el 
software, y que éste cumpla dichos requisitos de la manera más eficiente posible. 
El documento que elabore el equipo de diseño deberá ser sometido a una revisión técnica por el 
departamento de calidad. A medida que el departamento de calidad revise los documentos de diseño y 
encuentre incidencias, el equipo de diseño deberá ir corrigiéndolas, reelaborando el documento si es 
necesario y reentregarlo al departamento de calidad para que lo revise de nuevo. 
Una vez revisado, el documento de diseño se entregará al equipo de codificación para que codifique el 
software siguiendo sus pautas. 
1.2.3.2 Codificación 
El equipo de codificación será la entidad que codifique el software creando así la aplicación deseada por 
el cliente, o actualizando y mejorando una entrega anterior. Utilizará la arquitectura establecida por el 
equipo de diseño, y seguirá todas las pautas del documento de diseño elaborado por dicho equipo para 
organizar y codificar el software. 
Este equipo elaborará los ficheros de software, scripts si se necesitaran, el documento de plan de pruebas 
y los documentos de manual de usuario y manual de instalación, que deberán ser revisados por el 
departamento de calidad. 
A medida que el departamento de calidad pruebe el software y detecte las incidencias en éste, o en los 
documentos elaborados, el equipo de codificación tendrá que ir corrigiendo dichas incidencias, reelaborar 
el software y/o los documentos si es necesario, y reentregarlos al departamento de calidad para que revise 
de nuevo. 
 
 Descripción general del sistema 
 
 
4 
1.2.4 Despliegue 
El equipo de despliegue sera el encargado de la creación de los distintos entornos (definidos en la sección 
1.4 Definición de entornos) donde se llevarán a cabo las tareas del proceso software. Si ya estaban 
creados con anterioridad, este equipo se encargará de actualizarlos para el proyecto software actual y 
prepararlos para operar en ellos. 
Por otro lado, este equipo es la entidad que desplegará la aplicación en el entorno de certificación una vez 
codificada para que la OAC la pruebe, y en el entorno de cliente una vez ha sido totalmente revisada y 
probada por el departamento de calidad, y el cliente haya realizado las pruebas alfa en el entorno de 
certificación. Esto engloba el conjunto de acciones necesarias para que la aplicación sea accesible, se 
conecte con todos los subsistemas que necesite y tenga acceso a todos sus datos y registros, entre otras 
tareas. 
La OAC revisará el despliegue del software y llevará a cabo una segunda ejecución de las pruebas de 
sistema y de las pruebas de despliegue cuando el equipo de despliegue implante la aplicación en el 
entorno de cliente. Si la OAC detecta incidencias durante las pruebas de sistema o despliegue, se las 
comunicará al equipo de despliegue para que las corrija y vuelva a implantar el software en el entorno de 
cliente, repitiéndose el proceso tantas veces como sea necesario hasta que las pruebas de sistema y 
despliegue no generen ningún error. 
 
1.2.5 DP (Dirección de Proyecto) 
Figura encargada de la gestión y supervisión del proyecto objeto de desarrollo, siendo el interlocutor 
representativo del proyecto de cara al resto de áreas. El Director de Proyecto tendrá como misión 
supervisar la realización de los entregables, dando soporte al equipo de desarrollo en su elaboración y 
realizar la revisión técnica de los entregables, en los casos que proceda, junto con la OAC. 
Tiene como funciones comunicarse o reunirse con el RAU para elaborar una planificación temporal y 
presupuestaria, definir los objetivos que necesita que se cubran, y llevar el seguimiento del proyecto a 
través de todas sus etapas en todo momento. 
El RAU y una representación de los usuarios finales del cliente facilitarán las pautas para que DP elabore 
el documento DDR (Definición Detallada de Requisitos), que será revisado por el departamento de 
calidad. 
1.2.6 JP (Jefe de Proyecto) 
Responsable del Equipo de Desarrollo, y por tanto, responsable de todas las entregas que este deban 
realizar. JP pertenece al Equipo de Desarrollo y será el interlocutor representativo de los equipos de 
diseño y codificación. 
1.2.7 Comité de seguimiento3 
Esta figura se encarga de realizar el seguimiento del proyecto, contribuye en la definición del proyecto y 
emprende las acciones correctoras que se estimen oportunas, para obtener productos que se adecuen a las 
necesidades de la organización. El Comité de Seguimiento se encargará de seguir la evolución del proyecto y 
participar en su definición, y marcar las pautas técnicas de desarrollo (normativas, entornos…). 
El comité de seguimiento velará por la entrega eficaz y a tiempo de todos los entregables que conforman 
el proyecto, y controlará a los equipos de diseño, codificación, calidad, y despliegue. 
Según el alcance del proyecto, el comité de seguimiento estará típicamente formado por DP, JP y RAU. 
 
3 Definición de entidades basada en ‘SAC-Definición_de_roles’ MÉTRICA V.3 
 
5 
 
5 Proceso de Calidad en Ingeniería del Software 
 
1.3 Interacción entre entidades 
Según la MÉTRICA v.3 „SAC-Definición-de-roles‟, las entidades anteriormente descritas pueden pertenecer o 
no a diferentes empresas. Es recomendable que las entidades pertenezcan a empresas diferentes
4
, 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 útilespara 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 son
5
: Collabtive, GanttProject, iceScrum, Redbooth, Sinnaps, 
TaskJuggler, Wrike y JIRA
6
, 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 
https://www.lancetalent.com/blog/8-herramientas-para-la-gestion-de-proyectos-profesionales/
https://www.atlassian.com/software/jira
 
 Descripción general del sistema 
 
 
6 
2) Herramientas para la transferencia de archivos y control de versiones: Se trata de herramientas 
orientadas a la interacción entre DP, el Equipo de Desarrollo y la OAC. Son aplicaciones en las cuales 
cada entidad puede acceder a su sección asignada (por DP) y subir o bajar ficheros, código, 
documentos, paquetes, etc de forma reglada y ordenada, llevando un seguimiento de las versiones de 
cada entregable. El Equipo de Desarrollo usará estas herramientas para subir los documentos y 
ficheros de código elaborados para que la OAC los revise, de la misma manera en la que la OAC 
subirá los informes de revisión técnica elaborados, las incidencias y el resultado de las pruebas para 
que el Equipo de Desarrollo, DP, el equipo de despliegue o la entidad pertinente los corrija. 
Estas herramientas ofrecen funciones de nomenclatura asistida para los entregables subidos, 
facilitando así el control de versiones. Siempre se mostrarán visibles las distintas versiones que han 
sido subidas, señalando la última versión, tanto de un entregable subido por el equipo de Desarrollo 
como de un informe de revisión técnica subido por la OAC. 
De esta manera, por ejemplo, un miembro del equipo de desarrollo (o el JP) puede subir un 
documento de diseño que acabe de elaborar. Este documento se llamará, por ejemplo: “DAO-01”. Un 
miembro de la OAC accederá a la herramienta y descargará el documento. La OAC realizará un 
informe de revisión técnica tras revisar el documento, y subirá dicho informe a la sección de calidad 
de la herramienta, asociada al entregable del documento de diseño, con el nombre “Informe_DAO-
01”. El equipo de Desarrollo descargará el informe para comprobar las incidencias encontradas y 
corregirá el documento de diseño. Una vez hecho, subirá la nueva versión a la herramienta para que la 
OAC pueda descargarla y revisarla de nuevo, con el nombre “DAO-02” y así sucesivamente. 
Un ejemplo de este tipo de herramientas lo constituye QM
7
 software, (Quality Management) del 
Estado, que es el que utilizábamos en mis prácticas de empresa. 
 
3) Herramientas de comunicación directa: Se trata de herramientas de comunicación directa que 
agilizan las tareas. No son más que aplicaciones de chat de texto, voz, correo electrónico, etc, que 
facilitan la comunicación entre cualquier miembro de cualquier entidad, en especial la OAC. Útiles 
para avisar de cambios realizados, entregas subidas o modificaciones pequeñas. 
Destacando ejemplos de estas herramientas tenemos: Outlook, gmail, Skype, Pidgin o Spark, las 
cuales utilizábamos en mis prácticas de empresa. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 QM: https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp, url accesible desde un proxy 
con acceso a la Junta de Andalucía 
https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp
 
7 
 
7 Proceso de Calidad en Ingeniería del Software 
 
1.4 Definición de Entornos 
Durante el proceso software, se necesitará crear entornos (o usarlos si ya estaban creados) optimizados para 
cada tarea. El equipo de despliegue será el encargado de crear estos entornos, o mantenerlos y actualizarlos si 
ya se habían creado con anterioridad. 
Procedemos a explicar los diferentes entornos durante el proceso software, según el modelo SAC MÉTRICA 
v.3
8
: 
 
Tabla 2. Entornos 
ENTORNOS 
TIPO DESCRIPCIÓN 
Entorno de Desarrollo 
Creado por el equipo de despliegue, diseñado para diseñar, 
codificar y depurar el software. Utilizado por el equipo de 
desarrollo. 
Entorno de Integración 
Creado por el equipo de despliegue, diseñado para probar la 
relación del software con otros sistemas y la integración de 
distintos módulos. Utilizado por el equipo de desarrollo 
Entorno de Certificación 
Creado por el equipo de despliegue, diseñado para realizar 
las revisiones técnicas al software a través de las pruebas 
funcionales y no funcionales. Utilizado por el departamento 
de calidad OAC 
Entorno de Cliente 
Se trata del entorno donde el cliente se encuentra, entorno 
donde implantar el software definitivo, para que el usuario 
final pueda usarlo sin preocupaciones 
 
 
8 Bas{ndonos en la sección 3. ‚Descripción de Actividades, creación de entornos‛, del documento: 
‘SAC005P_CON_Plan_de_Configuracion_0100’, Normativa Técnica, MÉTRICA v.3 
 
 Descripción general del sistema 
 
 
8 
1.5 Diagrama de flujo del proceso software 
 
 
Figura 1. Diagrama de flujo del proceso software 
 
9 
 
9 Proceso de Calidad en Ingeniería del Software 
 
1.6 Detalle Del Proceso 
Esta sección tiene como objetivo resumir de manera breve el contenido expuesto en el diagrama de flujo 
de la Figura 1, destacando los procesos principales que se llevan a cabo desde el inicio del Proceso de 
Calidad y comienzo del proyecto hasta el final del mismo. 
La descripción, orden y motivación de las siguientes tareas se basa en la normativa descrita por la ISO
9
, 
tanto en el diagrama de flujo previamente descrito como en la sección que ahora desarrollaremos. 
 
1) El cliente realiza un análisis de la realidad de su entorno, y descubre problemas o carencias, que 
pueden ser resueltas implementando una nueva aplicación. O, si ya tenían un software previo, el 
cliente descubre aspectos a mejorar en éste, debido al uso del mismo y descubrimiento de fallos o 
elementos ampliables. 
2) Cuando el cliente ya tiene claro lo que necesita, elabora un pliego de prescripciones técnicas, 
presentándolo a un concurso en el cual varias empresas competirán para encargarse de 
proporcionarle una solución al cliente. Estas empresas deberán preparar una oferta, que consiste 
en explicar cómo piensan ayudar al cliente y cubrir sus necesidades, ofrecer una planificación 
temporal, y una estimación de costes. 
3) Una vez todas las empresas han presentado sus ofertas, el cliente seleccionará una de ellas para 
que se lleve a cabo (ganador del concurso), y se firmará un contrato en el cual el cliente contrata 
al adjudicatario seleccionado. 
4) El RAU se reunirá con el equipo de Dirección de Proyectos (DP) y con una representación de los 
usuarios finales del software para realizar una labor de indagación de requisitos. Posteriormente a 
esta reunión o reuniones en caso de haber varias, DP elaboraráel documento de Definición 
Detallada de Requisitos (DDR). En este documento, RAU, usuarios finales y DP dejan plasmados 
los objetivos exactos a alcanzar en el desarrollo del software, cubriendo distintos campos. Una 
vez elaborado el DDR, el departamento de calidad efectuará una revisión técnica del mismo, para 
asegurarse de que los requisitos especificados son coherentes y verificables. 
5) El DP contacta con el equipo de diseño para que comience la planificación, diseño y análisis del 
software. El equipo de diseño planeará y elaborará el siguiente documento: Diseño de 
Arquitectura Orientado a Objetos (DAO). El DAO es un documento cuyo propósito es definir la 
arquitectura del sistema, diseñar los casos de uso reales, diseñar las clases y el modelo físico de 
datos. Una vez elaborado el documento de diseño, el departamento de calidad efectuará una 
revisión técnica del mismo. 
6) El equipo de codificación codificará el software según las pautas elaboradas por el equipo de 
diseño. Como resultado final, elaborará todos los ficheros que conformen la aplicación, 
correctamente organizados. Paralelamente a la codificación del SFW, el equipo de Desarrollo irá 
ejecutando las pruebas de unidad (véase sección 2.6.1 Pruebas). Además, elaborará los siguientes 
documentos: Manual Básico de Instalación y Configuración (MIC), Manual de Usuario (MUS) y 
Plan de Pruebas (PP). Una vez elaborados, el departamento de calidad efectuará una revisión 
técnica de los mismos. 
7) La OAC llevará a cabo todas las pruebas descritas en el PP (excepto las pruebas unitarias ya 
realizadas por Desarrollo, y las de aceptación que serán realizadas por los usuarios finales del 
Cliente), y realizará un informe con el resultado de todas las pruebas para notificar al equipo 
correspondiente de los errores encontrados y que los corrija. 
8) En cualquier momento del proceso si la OAC detecta incidencias, se lo comunicará al equipo 
correspondiente, y éste corregirá dichas incidencias y enviará el producto completo de nuevo a la 
OAC para que ejecute una nueva revisión, repitiéndose el proceso las veces que sea necesario 
hasta superar con éxito las revisiones técnicas de la OAC. 
 
9 Bas{ndonos en la sección 5.Procesos principales del ciclo de vida, UNE 71044-1999 (ISO/IEC 12207:1995) 
 
 Descripción general del sistema 
 
 
10 
9) Cuando el software y documentos elaborados estén definitivamente corregidos y revisados por la 
OAC, tras superar satisfactoriamente todas las pruebas, se le comunicará a DP, de manera que el 
producto estará listo para las posteriores pruebas de usuario. 
10) El usuario realizará las pruebas alfa al software, dentro del entorno de certificación, y decidirá si 
el resultado final se adapta a las características que exigía en el DDR. Si no es así, lo devolverá a 
la OAC para que revise de nuevo los entregables pertinentes, y se decida o no enviarlos al equipo 
correspondiente para que los corrija. 
11) Si el cliente está satisfecho, la aplicación pasará al equipo de despliegue para que la implante y 
realice todos los procesos necesarios para que funcione correctamente en el entorno de cliente. La 
OAC revisará el despliegue y realizará de nuevo las pruebas de despliegue y las pruebas de 
sistema en el entorno de Cliente. Si se detectan incidencias, el equipo de despliegue realizará las 
correcciones oportunas y volverá a implantar el software en el entorno de Cliente. 
12) El usuario cliente realizará las pruebas beta al software, en su propio entorno. Si detecta 
incidencias, tendrá la oportunidad de devolverlo a la OAC las veces que sea necesario para que se 
encargue de las revisiones pertinentes. Si todo va bien, la entrega se considerará finalizada, y 
cliente cerrará el proyecto con el adjudicatario. 
 
 
 
11 
 
 
2 DESCRIPCIÓN ESPECÍFICA DEL SISTEMA 
2.1 Introducción 
ara la realización de esta sección, se ha hecho uso de la normativa definida por la ISO, al igual que en el 
apartado anterior: UNE 71044-1999 (ISO/IEC 12207:1995), norma que describe los procesos principales 
del ciclo de vida del software, los procesos de apoyo y los procesos organizativos. Seguiremos el orden 
que dictan tanto la normativa como el modelo en cascada. 
2.2 Comienzo Del Proyecto10 
Primera fase del proceso, en la cual, el Cliente estudia su entorno y lleva a cabo un análisis de la realidad 
para descubrir las carencias del software que se utiliza, para decidir si hace falta una mejora o 
actualización del mismo, o la codificación de un nuevo software para cubrir una necesidad encontrada 
diferente. Del mismo modo, una vez realizado este análisis, el Cliente llevará a cabo un proceso de 
adjudicación para su proyecto en vistas a elegir a la entidad (física o jurídica) que llevará a cabo el 
proyecto software que cubra las necesidades analizadas. 
Esta sección se apoyará en: 
La sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 12207:1995) 
La norma UNE-EN 16271:2013 Gestión del Valor. Expresión funcional de necesidades y pliego de 
especificaciones funcionales. Requisitos para la expresión y validación de las necesidades a satisfacer por 
un producto en el proceso de adquisición u obtención del mismo. (Correspondencia con la Norma 
Europea EN 16271:2012) 
 
*Nota: El comienzo del proyecto es la única parte del proceso software en la cual la OAC no desempeña 
funciones directas, pero se explicará de manera necesaria para comprender el resto de partes del proceso 
software en las que sí interviene Calidad. 
 
2.2.1 Análisis de la Realidad 
2.2.1.1 Sin Software previo11 
Este es el caso en el que la empresa parte de cero, no posee software inicial. La empresa deberá evaluar su 
entorno para reunir los requisitos necesarios que tendrá que tener la aplicación a desarrollar. Los analistas 
de la empresa jugarán un papel fundamental en este caso. La clave para reunir la información necesaria es 
dividir los procesos de negocio de la empresa en 3 grupos: 
 Procesos de negocio que actualmente se realizan y se deben seguir realizando o actualizar 
 Procesos de negocio que actualmente se realizan y no se deben seguir realizando 
 Procesos de negocio que actualmente no se realizan y se deberían realizar 
 
10 Basado en la sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 12207:1995) 
11 Basado en el est{ndar ISO 21500:2012, Guidance on Project Management, apoyado por referencias a: 
https://www.gestiopolis.com/metodologia-para-evaluacion-diagnostico-y-diseno-de-procesos/ 
P 
https://www.gestiopolis.com/metodologia-para-evaluacion-diagnostico-y-diseno-de-procesos/
 
 Descripción específica del sistema 
12 
 
12 
Con el primer grupo de procesos, los analistas elaborarán un prototipo de requisitos funcionales acerca de 
las funciones fundamentales que deberá realizar el software como base del funcionamiento. Constituyen 
la acción principal de la empresa (o sección de la empresa) y necesitan automatizarse de una manera 
rápida y cómoda haciendo uso de módulos software. 
Con los procesos que actualmente se realizan y no se deben seguir realizando, se pretende evitar todas las 
tareas innecesarias o irrelevantes. A la hora de elaborar los requisitos, los analistas discernirán qué 
procesos se deberían evitar en el nuevo software a crear, delimitando así el alcance de los requisitos. 
Todos los requisitos que se definan estarán destinados a solicitar las funcionalidades estrictamente 
necesarias. 
Con los procesos que actualmente no se realizan y se deberían realizar, se pretende confeccionar un 
prototipo con todos los módulos del software posibles que ayuden a la consecución de las tareas 
principales. De esta manera, los procesos de negocio que se necesitan llevar a cabo serán realizados por 
dicho prototipo, mejorando así el rendimiento de la empresa. 
2.2.1.2 Con Software previo12 
Este es el caso enel 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 software
13
: 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 utiliza
14
 
CUESTIONARIO SOFTWARE 
Muy en 
desacuerdo 
En 
desacuerdo 
De 
acuerdo 
Muy de 
acuerdo 
Se ejecuta lentamente X 
Recomendaría el software a mis colegas X 
Se ha detenido inesperadamente en algún 
 
12 Basado en el est{ndar ISO 21500:2012, Guidance on Project Management, apoyado por referencias a: 
https://www.emprendepyme.net/tecnicas-e-instrumentos-para-detectar-las-necesidades-de-capacitacion.html, 
13 Apoyado en https://es.surveymonkey.com/mp/employee-satisfaction-surveys/ 
14 Basada en https://www.survio.com/plantilla-de-encuesta/evaluacion-de-software y respaldado por: 
https://www.monografias.com/docs/Ejemplo-encuesta-de-satisfacci%C3%B3n-para-usuario-de-FKZ3RNCMY 
https://www.emprendepyme.net/tecnicas-e-instrumentos-para-detectar-las-necesidades-de-capacitacion.html
https://es.surveymonkey.com/mp/employee-satisfaction-surveys/
https://www.survio.com/plantilla-de-encuesta/evaluacion-de-software
https://www.monografias.com/docs/Ejemplo-encuesta-de-satisfacci%C3%B3n-para-usuario-de-FKZ3RNCMY
 
13 
 
13 Proceso de Calidad en Ingeniería del Software 
 
CUESTIONARIO SOFTWARE 
Muy en 
desacuerdo 
En 
desacuerdo 
De 
acuerdo 
Muy de 
acuerdo 
momento 
Es complicado de usar X 
A veces en algunos puntos, no sé cómo continuar X 
Disfruto su manejo X 
La información de ayuda que brinda no me resulta 
útil 
 X 
Si el software termina es difícil reiniciarlo X 
Aprender los comandos me tomó mucho tiempo X 
La manera en que presenta la información es clara 
y entendible 
 X 
2) Entrevista: El Cliente concreta reuniones presenciales con los empleados de la empresa, y 
prepara una serie de preguntas acerca de los flujos de trabajo que se llevan a cabo. El Cliente 
toma nota en el momento de las opiniones de los distintos usuarios sobre el modo de 
conseguir las metas de los procesos de la empresa, y finalmente elabora un baremo con las 
evaluaciones de todos. 
La entrevista deberá ser familiar, cercana y 
amigable. Se deberá evitar el tono demasiado 
formal para promover la honestidad de los 
entrevistados. En un ambiente cómodo, los 
usuarios son más propensos a decir lo que 
piensan y a dar opiniones más veraces. 
Si existía software previo, el usuario tendrá una 
opinión formada para responder al entrevistador, 
ya que normalmente, usa el software evaluado 
con periodicidad, y es el más indicado para dar 
una evaluación fiable y honesta. 
 
3) Observación: Los analistas observarán el funcionamiento de la empresa, y analizarán cómo 
se consiguen las metas de las diferentes actividades y tareas. En el caso de que existiese 
software previo, se comparará la conducta de los usuarios con el patrón de satisfacción y 
rendimiento esperado, y de esta manera, se detectarán las incidencias a mejorar. En el caso de 
que no existiera, se comprobará de qué manera se podrían mejorar las labores de la empresa, 
traduciéndolas en requisitos funcionales para la aplicación deseada. 
4) Agentes externos: Una opción es contratar a consultores externos dotados de gran capacidad 
de análisis y expertos en detectar necesidades de capacitación. 
 
Una vez el Cliente ha recopilado (por cualquiera de las vías) todas las necesidades e incidencias de su 
empresa y, si lo hubiera, software previo, elaborará un documento que veremos en la siguiente sección, y 
estará listo para comenzar con la tarea de la adjudicación. 
 
 Descripción específica del sistema 
14 
 
14 
2.2.2 Adjudicación 
La adjudicación se refiere al proceso mediante el cual el Cliente selecciona qué entidad (física o jurídica) 
se va a encargar de dar solución a las necesidades previamente estudiadas y detectadas. Según el análisis 
y el tipo de Cliente, hay dos formas de proceder claramente diferenciadas: con y sin lanzar un concurso 
público. 
Esta sección usa como referencias la sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 
12207:1995) y los apuntes de Proyectos de Telemática, asignatura de 4to del Grado de Ingeniería de 
Telecomunicaciones.
15
 
2.2.2.1 Sin concurso 
Este es el caso en el que el Cliente selecciona al adjudicatario que resolverá sus necesidades sin lanzar un 
concurso público. Se basará en el presupuesto que ofrezcan empresas o autónomos (según la envergadura 
del proyecto), y contratará el servicio según el RGCE.
16
 
Este es el caso de empresas y proyectos de menor envergadura en cuanto a tiempo y dinero, que solicitan 
el desarrollo directamente al adjudicatario. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
15 Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf 
16 La contratación de trabajos y suministros por parte de la Administración Española est{ regulada por la Ley 13/1995, de 18 de mayo, de 
Contratos de las Administraciones Públicas, y por el Reglamento General de la Contratación del Estado(Decreto 3410/1975, de 25 de 
noviembre) 
 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
 
15 
 
15 Proceso de Calidad en Ingeniería del Software 
 
2.2.2.2 Con concurso 
En este caso, el Cliente decide lanzar un concurso público para que se presenten empresas con sus 
respectivas Ofertas que compitan por convertirse en la empresa adjudicataria encargada dar solución a 
las necesidades del Cliente. Es el caso típico de empresas y proyectos de gran envergadura, tiempo y 
dinero. Será el caso en el que nos centraremos en este TFG y que tomaremos como base. El siguiente 
diagrama de flujo resume el proceso básico desde que el Cliente decide lanzar el concurso hasta que elige 
a una empresa adjudicataria satisfactoria que cumpla con sus necesidades: 
17
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
17 Figura extraída directamente de: Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf 
 
Figura 2. Diagrama de Flujo Concurso Público 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
 
 Descripción específica del sistema 
16 
 
16 
2.2.2.2.1 Preparacio n del Pliego de PrescripcionesTe cnicas 
El cliente dará a conocer sus necesidades al público mediante un documento. Este documento además recogerá 
todos los requisitos técnicos a los que deberá dar solución el nuevo proyecto, identificados en el previo análisis 
de la realidad. Este documento es el denominado: Pliego de prescripciones técnicas 
 
 
Tabla 4. Contenidos típicos de un Pliego de prescripciones técnicas
18
 
CONTENIDOS DESCRIPCIÓN 
TÉCNICOS 
 
(Todas aquellas carencias recogidas en el 
previo análisis de la realidad) 
Descripción de los trabajos 
Objetivos generales 
Requisitos de planificación y organización del equipo de trabajo 
ADMINISTRATIVOS 
 
(Todos aquellos requisitos requeridos para 
la formalización del proyecto) 
Régimen jurídico: quién contrata y bajo qué forma jurídica 
Requisitos de las ofertas: 
-Documentación a presentar 
-Forma, lugar y plazo 
Criterios de valoración 
Procedimiento y forma de adjudicación 
Requisitos de las empresas ofertantes: 
-Tipo de actividad 
-Solvencia económica 
-Experiencia previa 
-Certificados de calidad 
Formalización del contrato: 
-Cómo se adjudica 
-Fecha de la firma 
-Avales necesarios 
ECONÓMICOS 
Presupuesto máximo 
Forma de pago 
 
 
 
 
 
18 Basado en el Trabajo Final Proyectos de Telem{tica, realizado por mí, Antonio Marco Rodrigo Jiménez, y corregido por el profesor titular 
(PDI del Departamento de Telem{tica) Rafael Estepa. 
 
17 
 
17 Proceso de Calidad en Ingeniería del Software 
 
Ejemplo de un Pliego (Incluyendo en partes diferenciadas el Pliego de Prescripciones Técnicas y el Pliego de 
Cláusulas administrativas):
19
 
 
 
 
 
 
 
 
 
 
 
 
 
 
19 Pliego extraído como ejemplo directamente de la web de contratación del estado: 
https://contrataciondelestado.es/wps/wcm/connect/62c67958-52c9-4ef5-b30e-cd3b1566aef2/DOC_CD2012-382658.pdf?MOD=AJPERES 
Figura 3. Ejemplo de Pliego 
https://contrataciondelestado.es/wps/wcm/connect/62c67958-52c9-4ef5-b30e-cd3b1566aef2/DOC_CD2012-382658.pdf?MOD=AJPERES
 
 Descripción específica del sistema 
18 
 
18 
 
2.2.2.2.2 Publicidad del Pliego20 
Existen 3 maneras mediante las cuales el cliente puede publicar su pliego de prescripciones técnicas una vez 
elaborado: 
 
1) Procedimiento abierto: Cualquier empresa, asociación u organización tendrá acceso a este pliego y 
será libre de presentarse al concurso. 
 
2) Procedimiento restringido: El Cliente elegirá a unos cuantos contratistas por selección previa. Sólo 
estos invitados podrán presentarse al concurso. 
 
3) Procedimiento negociado: Este modo es más bien una reunión en la que el Cliente convoca a unos 
pocos contratistas, con los que negocia las condiciones del proyecto. 
 
Si el cliente se trata de la Administración Pública, las plataformas online donde publicará sus pliegos 
serán: 
 https://contrataciondelestado.es 
 http://www.juntadeandalucia.es/contratación 
 
Si el cliente se trata de una empresa privada y sigue un procedimiento abierto, distinguimos diferentes maneras 
de publicidad del pliego: 
 Televisión 
 Radio 
 Prensa 
 Internet 
 Exterior 
 
En los casos de procedimiento restringido o negociado, típicamente se notificará a los contratistas por vía 
privada (correo, teléfono, etc). 
 
 
 
 
 
 
 
 
 
20 Basado en Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf 
 
https://contrataciondelestado.es/
https://contrataciondelestado.es/
http://www.juntadeandalucia.es/contratacion
http://www.juntadeandalucia.es/contratacion
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
 
19 
 
19 Proceso de Calidad en Ingeniería del Software 
 
2.2.2.2.3 Evaluacio n de un Pliego 
Una vez publicado el Pliego de prescripciones técnicas, (por cualquier vía), las empresas tendrán acceso al 
mismo para comprobar los requisitos. Este es el momento en el que cada empresa valora la posibilidad y la 
rentabilidad de llevar a cabo un Proyecto Software que cumpla los requisitos del Pliego publicado, 
respondiendo a las siguientes preguntas: 
 
- ¿Está alineado con la estrategia de la empresa? 
- Tipo de trabajo 
- Coste y tiempo 
 
21
 
Figura 4. Diagrama de Flujo Evaluación de Oportunidad 
 
 
 
 
21 Figura extraída directamente de: Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf 
 
 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
 
 Descripción específica del sistema 
20 
 
20 
 
22
 
Figura 5. Esquema Evaluación Oportunidad 
 
 
 
La empresa se hará las siguientes preguntas: 
 
 ¿Disponemos de conocimientos necesarios? Si no, ¿tenemos tiempo de adquirirlos? 
 ¿Disponemos de recursos (materiales y humanos)? Si no, ¿tenemos tiempo de adquirirlos? 
 ¿Podemos ofrecer, al menos, lo mismo que otros competidores? 
 ¿Tiene el cliente un candidato “favorito”? Si es así, ¿podemos “ganarle”? 
 ¿Obtendremos beneficios considerables? 
 ¿Coste de oportunidad? = ¿nos impedirá atender a otros clientes? 
 ¿Dotaría a la empresa de una mejora competitiva (nuevos conocimientos, mejora de la reputación, 
etc.)? 
 
Si la respuesta a estas preguntas es SÍ, como se ve en el diagrama de flujo de arriba, la empresa está interesada 
en llevar a cabo el Proyecto Software que cubre las necesidades del Pliego publicado por la empresa Cliente. 
 
 
 
 
22 Figura extraída directamente de: Documento ‘Introducción a los Proyectos’, Departamento de Ingeniería Telem{tica, 2017-2018: 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf 
 
 
https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf
 
21 
 
21 Proceso de Calidad en Ingeniería del Software 
 
2.2.2.2.4 Elaboracio n de la Oferta 
Una vez la empresa contratista se ha decidido a proponerse para el concurso público, deberá elaborar una 
Oferta lo más atractiva posible para el Cliente, ya que tendrá que competir con otras empresas que 
también desean ganar el concurso. 
Los contenidos típicos de un documento de Oferta son los representados en la siguiente tabla: 
Tabla 5. Contenidos típicos de una Oferta 
CONTENIDO DESCRIPCIÓN 
Alcance 
Describe todos los entregables, añadiendo una breve descripción de cada uno. Resume 
todo lo que la empresa contratista va a ofrecer al Cliente si es elegida. 
El alcance también define el ámbito y las responsabilidades de adjudicatario y Cliente. 
Esto sirve para delimitar las responsabilidades de ambas partes, y quién se encarga de 
conseguir determinados aspectos en el proyecto. Es importante para evitar futuros 
problemas de responsabilidad legal, se describen aspectos como: 
-Quién facilita lugares o entornos de ejecución necesarios 
-Quién se encarga de conseguir permisos legales 
-Si se requerirá suministro ilimitado de red eléctrica u otros recursos, etc 
Recursos Humanos 
Describe el personal que va a participar en el proyecto, pasando por los Directores de 
Proyecto (DP), Jefes de Equipo, Desarrolladores, OAC, Programadores, Técnicos, 
Diseñadores, Documentadores, etc. También incluye su titulación, certificación, 
experiencia y salario. 
Planificación 
Temporal 
Describe la temporalización y calendarización de las tareas que se van a realizar desde el 
comienzo hasta el final delproyecto. (Siempre respetando la fecha máxima de entrega 
designada por el Cliente en el Pliego) 
Se suele usar un diagrama de Gantt para diseñar la planificación temporal de manera 
gráfica y comprensible. 
Presupuestos 
Detalla los costes que va a tener la aplicación (siempre respetando el presupuesto máximo 
designado por el Cliente en el Pliego), desglosando los gastos: Salario de los trabajadores, 
gastos generales, instalaciones, etc. 
Análisis de Riesgo 
En esta sección se plasma el resultado de un estudio previo de los posibles problemas que 
puedan ocurrir durante el desarrollo del proyecto. Se detalla la probabilidad de que dichos 
problemas ocurran, su prioridad y urgencia, y las soluciones planteadas ante los mismos. 
Control y 
Seguimiento del 
Proyecto 
Se describe cómo se llevará a cabo la comunicación entre Cliente y adjudicatario. Se 
detalla la vía y frecuencia de comunicación, las fechas de las reuniones y se define la 
estructura de los Informes de Seguimiento: documentos que DP presentará al cliente en 
cada reunión indicando los puntos clave de la evolución del proyecto. 
Plan de Calidad 
En esta sección se describe cómo se va a llevar a cabo el control de calidad por parte de la 
OAC durante el proyecto, se define quién forma la OAC y los recursos disponibles para 
dicha tarea. También se explica la metodología de revisiones técnicas y ejecución de 
pruebas que la OAC va a utilizar. 
Plan de Negocio 
Se calculan parámetros para comprobar la rentabilidad del proyecto. Se detalla la visión 
de futuro del proyecto, la posibilidad de seguir trabajando para el mismo Cliente, y se 
calculan los flujos de caja (Cash Flow) anuales, actualizando los costes y beneficios. 
Anexos 
En caso de que existan, se suele tratar de leyes y normativas, planos generales, guías de 
usuario de interfaces o documentos de diseño extra. 
La cantidad y tipo de anexos variarán en gran medida según el tipo de proyecto/SFW. 
 
 Descripción específica del sistema 
22 
 
22 
A continuación mostramos los entregables típicos que incluye un Proyecto Software de este tipo si la empresa 
resulta elegida como ganadora del concurso, y le es adjudicado el Proyecto.: 
La información para esta sección del TFG se apoya como referencia en el Trabajo Final para la 
asignatura: Proyectos de Telemática, realizado por mí: Antonio Marco Rodrigo Jiménez, y corregido por 
el profesor titular (PDI del Departamento de Telemática) Rafael Estepa. 
 
Tabla 6. Entregables de un Proyecto Software 
ENTREGABLES DESCRIPCIÓN 
DDR 
(Definición Detallada de 
Requisitos) 
La Definición Detallada de Requisitos es un documento cuyo objetivo es recoger todos 
los requisitos del Cliente para su aplicación, elaborado por DP. 
Aquí se detallan cuáles son las funciones que tiene que cubrir el software (Requisitos 
funcionales) y otros aspectos relacionados con la usabilidad, la velocidad del software, la 
seguridad, y otros requisitos técnicos (Requisitos no funcionales). 
Más información en la sección 2.3 Definición del Proyecto 
DAO 
(Diseño de Arquitectura 
Orientado a Objetos) 
El objetivo principal de este documento es describir el diseño de la arquitectura del 
sistema, definir todas las clases, atributos, operaciones y relaciones entre ellas, así como 
el diseño de las interfaces gráficas de usuario, de acuerdo con las normas establecidas en 
los Reglamentos Técnicos y los requisitos del DDR. Este documento lo elabora el equipo 
de diseño, marcando las pautas bajo las cuales codificará el SFW el equipo de 
codificación. 
Más información en la sección 2.4 Diseño del Proyecto 
SCR 
(Scripts) 
Se trata de ficheros codificados por el equipo de codificación, necesarios para el correcto 
funcionamiento de la aplicación final. 
Realizan tareas como creación de sinónimos públicos, creación o eliminación de usuarios 
y roles, creación de tablas de datos (o actualización de las mismas), o acciones 
relacionadas con BBDD. El orden y método de ejecución de los scripts se detalla en el 
MIC. 
PP 
(Plan de Pruebas) 
El Plan de Pruebas es el documento elaborado por el equipo de Desarrollo que reúne 
todos los planes de pruebas. Los planes de pruebas describen las pruebas que se tendrán 
que realizar a la aplicación para comprobar su correcto funcionamiento. 
En él se aporta toda la información necesaria para que se pruebe la aplicación, y se 
compruebe así que se cumplen todos los requisitos descritos en el DDR. 
Más información en las secciones 2.5.5 Elaboración del PP, y sección 2.6.1 Pruebas 
MUS 
(Manual de Usuario) 
El Manual de Usuario se trata de un documento que ilustra cómo utilizar la 
aplicación, elaborado por el equipo de desarrollo. Consiste en un manual 
categorizado que explica de forma sencilla todas las funcionalidades de la 
aplicación. 
Está dirigido al usuario final que utiliza la aplicación, así que está escrito de forma 
sencilla y comprensible. 
Más información en la sección 2.5.4 MUS 
MIC 
(Manual básico de 
Instalación y 
El Manual Básico de Instalación y Configuración es un documento que resume 
cómo instalar la aplicación elaborado por el equipo de desarrollo. 
Detalla rigurosamente los pasos a seguir para instalar el SFW, ejecutar los SCR 
pertinentes, realizar modificaciones en registros, BBDD, y distintos parámetros. 
 
23 
 
23 Proceso de Calidad en Ingeniería del Software 
 
Configuración) También detalla cómo hacer un backup del entorno y cómo hacer una “marcha atrás” 
utilizando dicho backup, necesario por si algo falla en la instalación para que no 
afecte al entorno anterior. 
Más información en la sección 2.5.3 MIC 
SFW 
(Software) 
Son los ficheros de software de la aplicación codificados por el equipo de 
codificación. Pueden variar en lenguaje de programación, estructura y arquitectura 
según el tipo de aplicación. En nuestro caso siempre serán ficheros Java o tipo 
“form”. Se trata de los ficheros que constituyen la aplicación final. 
IPC 
(Informe de Pruebas de 
Certificación) 
El Informe de Pruebas de Certificación es un documento elaborado por la OAC que 
recoge el resultado de todas las pruebas dinámicas y estáticas realizadas a la 
aplicación. En el informe se adjunta un análisis del modelo de datos de los scripts 
utilizados, un informe de pruebas estáticas del software, el resultado de las pruebas 
descritas en el PP, y el resultado de la instalación de la aplicación en los diferentes 
entornos. 
Más información en la sección 2.6.4 Informes de Calidad 
IPA 
(Informe de Pruebas de 
Aceptación) 
El Informe de Pruebas de Aceptación detalla el resultado de las pruebas de usuario. 
En él, la OAC plasmará la información recogida por el usuario acerca de la 
aplicación, tras haber realizado las pruebas alfa y las pruebas beta. 
Más información en la sección 2.6.4 Informes de Calidad 
Garantía 
Si aplica, la empresa añade una garantía de funcionamiento de la aplicación, 
ofreciéndose a rehacerla o corregir cualquier problema de instalación, bugs o 
errores. 
Se detalla la duración de la garantía y las condiciones para que se lleve a cabo. Se 
especifica qué aspectos están dispuestos a cubrir y cuáles no. 
Asistencia Técnica 
La empresa ofrece correos y números de contacto para ayudar a los usuarios cuando 
estén utilizando el software instalado. En caso de que tengan dudas o no sepan 
hacer algo, la empresa se compromete a brindar asistencia técnica (presencial o 
remota) a los usuarios. 
Formación Presencial 
Complementando el MUS, hay ocasiones en las que la empresa ofrecerá un pequeño 
curso de formación en vivo a los usuarios que vayan a usar el Software (o a 
representantes que luego a su vez les enseñen). 
Se detalla la duración y contenidos del mismo, así como su calendarización y 
duración en horas. 
 
 
 
 
 
 
 
 
 
 
 
 
 Descripción específica del sistema 
24 
 
24 
Los entregables arriba descritos vienen recogidos en lo que se denominaun diagrama WBS (Work Breakdown 
Structure „Estructura de Descomposición del Trabajo‟). Se trata de una representación gráfica de los 
entregables finales al Cliente, divididos por categorías. Se encarga de recoger de manera visual todos los 
entregables una vez aceptado el proyecto. Aquí mostramos un ejemplo genérico: 
 
Figura 6. Ejemplo de Diagrama WBS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
25 
 
25 Proceso de Calidad en Ingeniería del Software 
 
2.2.2.2.5 Eleccio n de Propuesta23 
Una vez que las empresas contendientes han elaborado sus Ofertas y las han enviado o presentado al Cliente 
dentro del plazo límite, el Cliente valorará las propuestas recibidas y dará su veredicto. 
El Cliente comparará las distintas propuestas en función de varios parámetros: 
 Coherencia entre la propuesta ofertada por la empresa adjudicataria y los requisitos del Cliente 
 Experiencia del contratista o proveedor en proyectos similares 
 Experiencia del personal clave asignado al proyecto 
 Salud financiera de la empresa 
 Capacidad de respuesta considerando al equipo de trabajo que posea, maquinaria, equipos, etc. 
 Tiempo de ejecución, que la propuesta sea realista en función al trabajo, a los recursos asignados y a 
los requisitos del cliente 
 Propuesta económica global y a detalle, revisando que todas las fuentes de ingresos y gastos estén 
contempladas 
El método de elección depende de cada Cliente y Proyecto, el proceso de decisión se puede llevar a cabo de 
muchas maneras distintas, entre las que destacan: 
1) Descartar primero todas aquellas propuestas que no cumplan los requisitos de presupuesto o fecha de 
finalización, y después decidir entre los restantes 
2) Descartar primero todas aquellas propuestas que no cumplan los requisitos de formación, experiencia 
en el sector o conocimiento técnico, y después decidir entre los restantes 
3) Realización de una Matriz de Evaluación de Alternativas, en la cual se plasman los criterios 
ponderados según su importancia, y a cada propuesta se le puntúa en cada uno de los parámetros. 
Aquella propuesta que reúna más puntos en total es aquella que mejor cubre todos los criterios 
planteados (como los citados anteriormente). A continuación se muestra un ejemplo de la misma: 
 
Tabla 7. Matriz de Evaluación de Alternativas 
MATRIZ DE EVALUACIÓN DE ALTERNATIVAS 
Puntuación: 
0-10 
Criterios (Bajo cada criterio se muestra el porcentaje de importancia en la decisión, para 
ponderar el resultado en consecuencia) 
 
Coste 
(80%) 
Tiempo 
(60%) 
Experiencia 
(90%) 
Fiabilidad (fama) 
(85%) 
Salud financiera 
(65%) 
Propuesta 1 8 5 2 8 6 
Propuesta 2 5 5 5 5 5 
Propuesta 3 4 3 9 8 2 
Propuesta 4 7 2 1 10 0 
Propuesta 5 6 7 6 4 1 
De este modo, la propuesta ganadora será la que obtenga una puntuación más alta, habiendo obtenido muchos 
puntos en los parámetros de más grado de importancia. 
En este ejemplo, si una de las propuestas es muy fiable y se habla mucho de ella, y además tiene mucha 
experiencia, (como la Propuesta 3), es propensa a ganar el concurso, ya que estos son dos de los parámetros 
que más ponderan. 
 
23 Información basada en http://ccapsa.com/2013/10/02/ 
http://ccapsa.com/2013/10/02/
 
 Descripción específica del sistema 
26 
 
26 
La propuesta o empresa ganadora, se reunirá con el RAU de nuevo para aclarar los términos del alcance. Un 
alcance bien definido marcará las pautas de trabajo a seguir entre el Cliente y la empresa contratista. Al fin y al 
cabo, no deja de ser un proceso de venta: la empresa contratista le ofrece un servicio al Cliente, y el Cliente le 
va a remunerar por ello. Así, tienen que quedar bien delimitados los límites y responsabilidades de cada parte, 
para evitar confusiones, conflictos y problemas en el futuro. Mientras más transparente y claro sea este 
contrato, mejor, por ello es muy importante ser profesional en este sentido. Esto generará una situación de 
confianza mutua entre Cliente y adjudicatario, y se abre la posibilidad de seguir colaborando y trabajando 
juntos en el futuro. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
27 
 
27 Proceso de Calidad en Ingeniería del Software 
 
2.3 Definición Del Proyecto 
Para la realización de esta sección nos hemos basado fundamentalmente en la norma UNE-ISO/IEC 
90003-200, ISO 9001-2000 y MÉTRICA v.3, Modelo SAC: „SAC007P_DDR_Definicion Detallada 
Requisitos_0100‟, añadiendo a pie de página referencias más específicas referentes a cada parte de la 
sección de definición del proyecto. 
Llegados a este punto, el Cliente ya ha elegido a su empresa contratista que va a realizar el Proyecto 
Software que cubrirá sus necesidades. Ahora que ya están dispuestos a trabajar juntos, y se ha firmado el 
contrato, la comunicación entre Cliente y contratista será indispensable. De esta necesidad surge la figura 
de DP (Dirección de Proyectos). El director o la directora de proyectos será aquella persona responsable 
de ponerse en contacto con el Cliente para todo lo relacionado con el proyecto. 
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 
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/408
 
 Descripción específica del sistema 
28 
 
28 
Tabla 8. Tipos de Requisitos 
TIPOS DE REQUISITOS 
TIPO SUBTIPO SIGLAS DESCRIPCIÓN 
FUNCIONALES 
(RF) 
CASOS DE USO CU 
Especifican el comportamiento del sistema. 
Describen lo que el sistemadebe hacer, qué 
funcionalidades debe incorporar la aplicación, 
y qué acciones debe ser capaz de realizar, 
describiendo las interacciones entre sistema y 
usuarios. 
REGLAS DE 
NEGOCIO 
RN 
Especifican las normas del negocio que el 
software tendrá que respetar y seguir. 
DE CONDUCTA RC 
Especifican aquellas tareas relacionadas con 
otros usuarios o sistemas, cuando el software 
resulta necesario para la consecución de los 
objetivos de estos últimos. 
DE INFORMACIÓN RIN 
Especifica la información y los datos que el 
software deberá gestionar para funcionar 
correctamente. 
NO 
FUNCIONALES 
(O TÉCNICOS) 
(RNF) 
DE ENTORNO 
TECNOLÓGICO 
RE 
Describen el ambiente operativo en el que se 
debe desenvolver el sistema. 
DE SEGURIDAD RS 
Garantizan la seguridad de tecnología de 
información, seguridad de datos, seguridad 
lógica, control de acceso a información 
(restricciones de acceso), autenticidad de la 
información, privacidad, entre otros aspectos. 
DE FIABILIDAD RFI 
Describen la tolerancia a fallos del software y 
su respuesta bajo condiciones específicas 
DE USABILIDAD RU 
Describen todos aquellos aspectos 
relacionados con la interacción directa 
software-cliente, como su facilidad de uso, su 
comprensión, etc. 
DE 
MANTENIBILIDAD 
RM 
Describen la capacidad o facilidad del 
software para ser actualizado, analizado y 
corregido en el futuro una vez implantado. 
DE INTERFAZ RI 
Describen la comunicación con sistemas 
externos, y cómo debe ser esa comunicación. 
DE RENDIMIENTO 
Y DISPONIBILIDAD 
RR 
Describen la disposición del sistema para 
brindar servicio correctamente y garantizar 
una velocidad, tiempo de respuesta y consumo 
de recursos óptimos, entre otros. 
OTROS RO 
Derivados del entorno organizacional, entre 
los que se incluyen aspectos éticos, 
seguimiento de estándares y plantillas, y 
requerimientos legales y regulatorios. 
 
29 
 
29 Proceso de Calidad en Ingeniería del Software 
 
El DDR, además de la definición de todos los requisitos deseados para la aplicación, incluye una Matriz 
de Trazabilidad. Se trata de una tabla que reúne todos los requisitos descritos y muestra varios 
parámetros acerca de los mismos, como son su: 
 Origen 
 Verificabilidad 
 Prioridad 
 Importancia 
 Relaciones con otros de los requisitos 
 
La Matriz de Trazabilidad
27
 es una herramienta fundamental para la Ingeniería del Proyecto. Dicha 
matriz es la pieza clave que nos ayuda a llevar un seguimiento de los requisitos de la aplicación, y supone 
la diferencia entre una buena o mala ejecución que no diste mucho de la planificación. Está dirigida al 
comité de seguimiento, y aporta varios beneficios al proyecto. 
Esta matriz es muy importante debido a que permite controlar el ciclo de vida de los requisitos. A medida 
que se van validando los requisitos, se actualizará esta Matriz de Trazabilidad, al tratarse de una tabla 
dinámica. De esta manera el comité de seguimiento es capaz de controlar qué requisitos han sido 
validados, cuáles están pendientes o cuáles han sido rechazados, en cualquier etapa. 
Por otro lado, al mostrar las relaciones de los requisitos entre ellos, identifica dependencias críticas y 
detecta rápidamente inconsistencias entre dos o más requisitos. Así, cuando se introduce un cambio para 
un requisito, podemos ver en la Matriz de Trazabilidad a qué otros requisitos afecta este cambio, y 
comprobarlos o modificarlos si es necesario rápidamente. También, si se detecta un fallo referente a un 
requisito, se acude a la tabla para comprobar a qué otros requisitos puede afectar dicho fallo. 
 
 
Figura 7. Ejemplo de Matriz de Trazabilidad 
 
 
27 Según la Norma ISO 10007-1997, ‘Directrices para la gestión de la configuración’ 
 
 Descripción específica del sistema 
30 
 
30 
Por otro lado, como tarea de esta sección del proceso software, la labor de la OAC también incluye la 
realización del PPA (Plan de Pruebas de Aceptación). Este es el primer plan de pruebas que se elabora, sin 
embargo, las pruebas de aceptación serán de las últimas que se ejecuten (consultar sección 2.6.1 Pruebas 
para más detalles). La OAC, una vez realice la revisión técnica al DDR, elaborará este plan de pruebas, el 
cual servirá de guía a los usuarios finales en la realización de las pruebas que verifiquen los requisitos 
funcionales solicitados, en cuyo caso se aceptará el sistema. 
El Plan de Pruebas de Aceptación (PPA) desarrolla las pruebas de Aceptación, las cuales se realizarán o 
supervisarán por el RAU, cuyos detalles describiremos en la sección 2.6.1 Pruebas, y en la sección 2.7 
Pruebas de Usuario. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
31 
 
31 Proceso de Calidad en Ingeniería del Software 
 
2.4 Diseño Del Proyecto 
En este punto, el DDR ha sido elaborado y satisfactoriamente revisado por la OAC. Así, DP se lo pasará 
al equipo de Diseño, finalizando de esta manera la fase ASI y comenzando la fase DSI (Diseño del 
Sistema de Información). 
El objetivo del proceso de Diseño del Sistema de Información (DSI), según MÉTRICA v.3, modelo SAC: 
„DSI Procedimiento Global‟
28
 es la definición de la arquitectura del sistema y del entorno tecnológico que 
le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. 
El DSI consta de varios entregables que el equipo de Desarrollo tendrá que elaborar, incluyendo, entre 
otros, el documento de Diseño. En esta sección, nos centraremos en este último, el cual será elaborado 
concretamente por el equipo de Diseño. 
El equipo de Diseño elaborará el documento de diseño del sistema que mejor se adapte a los requisitos 
especificados en el DDR, y que constituya la base para desarrollar el sistema de la forma más eficiente y 
óptima en cuanto a tiempo, simplicidad y funcionalidad. 
El buen trabajo del equipo de Diseño se reflejará en la definición de una arquitectura estructurada, 
organizada y sencilla de entender e implementar. El equipo de Codificación será el principal destinatario 
de los documentos que elabore el equipo de Diseño, ya que seguirán las pautas indicadas en sus 
documentos. 
A continuación, describiremos detalladamente el documento que Diseño tendrá que elaborar, basándonos 
en MÉTRICA v.3, modelo SAC: „SAC007P_DAO_Diseño Arquitectura OO_0100‟. 
2.4.1 DAO (Diseño de Arquitectura Orientado a Objetos) 
Los objetivos de este entregable son, por un lado, definir el particionamiento físico del sistema, especificar en 
detalle el entorno tecnológico y sus requisitos de operación, administración, seguridad, auditorías y control de 
acceso. Y por otro lado, el diseño detallado del Sistema, el cual comprende un conjunto de actividades cuyo 
alcance se resume a continuación: 
 Diseño de Casos de Uso Reales, con el diseño detallado del comportamiento del sistema para los 
casos de uso y el diseño de la interfaz de usuario. 
 Diseño de Clases, con el diseño detallado de cada una de las clases que forman parte del sistema, sus 
atributos, operaciones, relaciones y métodos, y la estructura jerárquica del mismo. 
 Diseño Físico de Datos que incluye el diseño y optimización de las estructuras de datos del sistema. 
El DAO incluye trazas a los requisitos, de manera que con la elaboración del documento se puede comprobar 
qué requisitos van a ser validados, en especial en la sección de Casos de Uso, los cuales representan cómo se 
va a dar solución a los requisitos funcionales, y en la sección de descripción del entorno tecnológico, la cual 
incluirá trazas para los requisitos de entorno tecnológico y otros requisitos no funcionales. 
A continuación, describiremos en detalle la estructura de un DAO elaborado por Diseño: 
 
 
 
 
 
 
 
 
28 Apoyado en la norma ISO 9001-2000, sección 7.3: „Diseño y Desarrollo‟ y en la norma ISO/IEC