trabajo fin de grado - servidor de la biblioteca de...

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

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


Tabla 27. Defectos genéricos en código 61

Tabla 28. Resultado de evaluación de un entregable 64

Tabla 29. Estructura de un IPC 68

Tabla 30. Lista final de entregables 70

Tabla 31. Tareas de Despliegue 74

ÍNDICE DE FIGURAS

Figura 1. Diagrama de flujo del proceso software 8

Figura 2. Diagrama de Flujo Concurso Público 15

Figura 3. Ejemplo de Pliego 17

Figura 4. Diagrama de Flujo Evaluación de Oportunidad 19

Figura 5. Esquema Evaluación Oportunidad 20

Figura 6. Ejemplo de Diagrama WBS 24

Figura 7. Ejemplo de Matriz de Trazabilidad 29

Figura 8. Ejemplo de Informe de Fin de Proyecto 78

1

1 DESCRIPCIÓN GENERAL DEL SISTEMA

1.1 Modelo

ara el proceso software que vamos a explicar en este TFG, hemos elegido un modelo en cascada, que es el que se usa en mis prácticas de empresa.

El modelo en cascada (basándonos en la publicación de Winston Royce, 19701), se caracteriza por

seguir un orden secuencial en las tareas del desarrollo software, no se empieza una tarea hasta que no se acaba la anterior. De esta manera, primero se realizará el análisis y definición de requisitos, seguida del

diseño, codificación, pruebas y despliegue. Este modelo presenta una serie de ventajas e inconvenientes

sobre el resto de modelos, las cuales presentamos a continuación:

Tabla 1. Modelo en Cascada

MODELO EN CASCADA

VENTAJAS INCONVENIENTES

Planificación óptima de tiempo y dinero Es muy complicado introducir cambios en cualquier etapa

Alto nivel de satisfacción del cliente

Todos los requisitos deben quedar recogidos al inicio,

impidiendo la definición de nuevos requisitos durante el

desarrollo del proyecto

Permite suplir pérdidas en el equipo de desarrollo

con bastante facilidad

Las pruebas se realizan muy tarde, provocando que los

errores tarden en identificarse y corregirse

Todos los aspectos del proyecto están bien claros

y definidos desde el principio Si hay problemas, tendrán un alto coste en tiempo y dinero

Es un modelo fácilmente comprensible e

implementable La creación del software tarda mucho tiempo

Permite que lo realice un equipo con poca

experiencia en el desarrollo software debido a su

simplicidad

Las etapas necesitan esperar a que acabe la anterior

Estas características del modelo en cascada hacen que sea especialmente efectivo en proyectos estáticos, bien definidos desde el principio en los que sea muy poco probable la introducción de cambios durante el

desarrollo del software (En adelante SFW). Se beneficiarán de este modelo empresas que:

1) Cuenten con un gran capital, que se puedan permitir el coste en tiempo y dinero ante la aparición de problemas y errores. A costa de este gasto, garantizarán la satisfacción del cliente,

aumentando las posibilidades de trabajar juntos en el futuro.

2) Tengan una plantilla extensa y renovable, la cual dará lugar a equipos humanos poco

experimentados. El modelo en cascada es el más fácil para dichos equipos.

En resumen, este TFG propondrá un modelo de proceso software idóneo para grandes empresas que

contraten nuevos empleados regularmente, especializada en proyectos estáticos bien definidos al inicio.

1 ‘Managing the Development of Large Software Systems’, Winston Royce, 1970, creador del modelo de desarrollo software en cascada, m{s

tarde avalado por las publicaciones: ‘Software Engineering Economics’, Barry Boehm, 1981 y ‘Software Engineering’, Ian Sommerville, 1985

P

Descripción general del sistema

2

1.2 Definición de entidades

A continuación vamos a detallar las diferentes entidades, personas, o grupos de personas que van a

participar en el proceso software, y en el proceso de calidad. Definiremos quién forma cada entidad, qué

función tiene dentro del proceso software y cómo se relacionan entre ellas. Realizaremos dicha definición de entidades basándonos en el estándar MÉTRICA v.3.

MÉTRICA es un estándar de desarrollo software, realizado por el Gobierno de España, cuya última

versión (versión 3) se publicó en 2001. Durante mis prácticas de empresa se utilizaba como referencia

este estándar (en adelante MÉTRICA V.3) y es el que utiliza el SAC (Sistema de Aseguramiento de la Calidad) dentro del departamento de calidad como guía y normativa.

MÉTRICA v.3 está basada en los estándares internacionales: ISO/IEC 12207 (Information Technology -

Software Life Cycle Processes) y ISO/IEC 15504 SPICE (Software Process Improvement and Assurance Standards Capability Determination)

2.

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

El departamento de calidad o OAC tiene como misión garantizar la calidad del producto software como

tal, asociado a un proyecto de desarrollo, encargándose de la ejecución de las pruebas tanto funcionales

como técnicas, detección de incidencias tanto de los documentos como del software generados por el

resto de entidades y elaboración de informes con el resultado de las pruebas llevadas a cabo.

También es el órgano encargado de la supervisión y de la evaluación de los proyectos, del cumplimiento

de la metodología definida. Participa en la revisión de los productos seleccionados para determinar si son

conformes o no a los procedimientos, normas o criterios especificados, comprobando que se han llevado a cabo las medidas preventivas o correctoras necesarias. Durante todas las etapas del proceso software, la

OAC realizará el número de revisiones técnicas necesario hasta que el entregable en cuestión supere

dichas revisiones satisfactoriamente.

La OAC también será aquella figura encargada de la validación de los modelos de datos conceptual, lógico y físico, generados durante el análisis y diseño del software, en cuanto a nomenclatura,

normalización, rendimiento, etc.

El departamento de calidad será la sección a la que prestaremos especial atención en este documento, en la que profundizaremos en la sección 2.6 Control de Calidad.

1.2.2 Cliente

El cliente es aquella persona, física o jurídica, que comienza el proceso software. El cliente es aquel que,

tras un análisis de la realidad de su entorno, encuentra una carencia, problema, o posible mejora de su sistema o entorno. Dividiremos al cliente en 2 tipos:

Persona física: Cliente formado por una única persona, la cual realizará el análisis de realidad de

su entorno, y decidirá si necesita o no ayuda externa para llevar a cabo la tarea a realizar.

Persona jurídica: Cliente consistente en una empresa, organismo o asociación.

o Empresas que no recurren a un concurso: Este cliente buscará soluciones por su

cuenta a los problemas o carencias analizados, o buscará ayuda de un tercero específicamente seleccionado, ya sea una ayuda gratuita personalizada, o la venta de un

servicio.

o Empresas que recurren a un concurso: Este cliente es en el que nos centraremos en este documento. Consiste en una empresa, organismo o asociación, que para solucionar

los problemas analizados, publica un pliego de prescripciones técnicas, y, a través de un

2 A falta de disposición a texto completo de las normas ISO mencionadas, utilizaremos como referencia la norma UNE 71044 – 1999

(AENOR), equivalente a la norma ISO/IEC 12207:1995.

3

3 Proceso de Calidad en Ingeniería del Software

concurso, otras empresas, organismos o asociaciones presentarán sus ofertas para cubrir

lo mejor posible las necesidades del cliente al precio más razonable. El cliente elegirá

qué empresa llevará a cabo su proyecto basándose en la reputación, confianza,

efectividad y presupuesto.

La empresa cliente designará a un RAU (Responsable del Área Usuaria), que será el interlocutor

representativo de la empresa cliente durante todo el proceso software en adelante. Toda comunicación

entre las diferentes entidades con el cliente se gestionará a través del RAU.

El RAU se encargará de realizar y/o gestionar la realización de las pruebas alfa y beta del software una

vez esté codificado por el equipo de desarrollo y revisado y probado por el departamento de calidad. Las

pruebas alfa las realizará en el entorno de certificación, sin que sea necesario el despliegue final de la aplicación. Las pruebas beta las realizará una vez la aplicación ya haya sido desplegada por el equipo de

despliegue, en su propio entorno de cliente. En ambas pruebas, comunicará al departamento de calidad las

incidencias o problemas que encuentre, para que éste las revise y, a su vez, dé parte al equipo

correspondiente para que las corrija.

1.2.3 Equipo de Desarrollo

Figura encargada del desarrollo del software, en todo su alcance, desde su inicio hasta su mantenimiento. Es el encargado de analizar las necesidades del software, modelarlo, diseñarlo y construirlo, realizando

los planes de pruebas necesarios para generar productos de calidad que satisfagan las necesidades

planteadas inicialmente. Es el encargado de elaborar la documentación asociada al proceso de desarrollo y de revisarla y actualizarla, si fuese necesario.

Está formado por dos entidades bien diferenciadas:

1.2.3.1 Diseño

El equipo de diseño es la entidad encargada de elaborar el documento de diseño del software. Este equipo

analizará los requisitos exigidos por el cliente, para encontrar la manera óptima de organizar y codificar el

software, y que éste cumpla dichos requisitos de la manera más eficiente posible.

El documento que elabore el equipo de diseño deberá ser sometido a una revisión técnica por el

departamento de calidad. A medida que el departamento de calidad revise los documentos de diseño y

encuentre incidencias, el equipo de diseño deberá ir corrigiéndolas, reelaborando el documento si es necesario y reentregarlo al departamento de calidad para que lo revise de nuevo.

Una vez revisado, el documento de diseño se entregará al equipo de codificación para que codifique el

software siguiendo sus pautas.

1.2.3.2 Codificación

El equipo de codificación será la entidad que codifique el software creando así la aplicación deseada por el cliente, o actualizando y mejorando una entrega anterior. Utilizará la arquitectura establecida por el

equipo de diseño, y seguirá todas las pautas del documento de diseño elaborado por dicho equipo para

organizar y codificar el software.

Este equipo elaborará los ficheros de software, scripts si se necesitaran, el documento de plan de pruebas y los documentos de manual de usuario y manual de instalación, que deberán ser revisados por el

departamento de calidad.

A medida que el departamento de calidad pruebe el software y detecte las incidencias en éste, o en los documentos elaborados, el equipo de codificación tendrá que ir corrigiendo dichas incidencias, reelaborar

el software y/o los documentos si es necesario, y reentregarlos al departamento de calidad para que revise

de nuevo.


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


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

https://www.lancetalent.com/blog/8-herramientas-para-la-gestion-de-proyectos-profesionales/

https://www.atlassian.com/software/jira


6

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

orientadas a la interacción entre DP, el Equipo de Desarrollo y la OAC. Son aplicaciones en las cuales

cada entidad puede acceder a su sección asignada (por DP) y subir o bajar ficheros, código,

documentos, paquetes, etc de forma reglada y ordenada, llevando un seguimiento de las versiones de cada entregable. El Equipo de Desarrollo usará estas herramientas para subir los documentos y

ficheros de código elaborados para que la OAC los revise, de la misma manera en la que la OAC

subirá los informes de revisión técnica elaborados, las incidencias y el resultado de las pruebas para que el Equipo de Desarrollo, DP, el equipo de despliegue o la entidad pertinente los corrija.

Estas herramientas ofrecen funciones de nomenclatura asistida para los entregables subidos,

facilitando así el control de versiones. Siempre se mostrarán visibles las distintas versiones que han sido subidas, señalando la última versión, tanto de un entregable subido por el equipo de Desarrollo

como de un informe de revisión técnica subido por la OAC.

De esta manera, por ejemplo, un miembro del equipo de desarrollo (o el JP) puede subir un

documento de diseño que acabe de elaborar. Este documento se llamará, por ejemplo: “DAO-01”. Un miembro de la OAC accederá a la herramienta y descargará el documento. La OAC realizará un

informe de revisión técnica tras revisar el documento, y subirá dicho informe a la sección de calidad

de la herramienta, asociada al entregable del documento de diseño, con el nombre “Informe_DAO-01”. El equipo de Desarrollo descargará el informe para comprobar las incidencias encontradas y

corregirá el documento de diseño. Una vez hecho, subirá la nueva versión a la herramienta para que la

OAC pueda descargarla y revisarla de nuevo, con el nombre “DAO-02” y así sucesivamente.

Un ejemplo de este tipo de herramientas lo constituye QM7 software, (Quality Management) del

Estado, que es el que utilizábamos en mis prácticas de empresa.

3) Herramientas de comunicación directa: Se trata de herramientas de comunicación directa que agilizan las tareas. No son más que aplicaciones de chat de texto, voz, correo electrónico, etc, que

facilitan la comunicación entre cualquier miembro de cualquier entidad, en especial la OAC. Útiles

para avisar de cambios realizados, entregas subidas o modificaciones pequeñas.

Destacando ejemplos de estas herramientas tenemos: Outlook, gmail, Skype, Pidgin o Spark, las

cuales utilizábamos en mis prácticas de empresa.

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

con acceso a la Junta de Andalucía

https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp

7


1.4 Definición de Entornos

Durante el proceso software, se necesitará crear entornos (o usarlos si ya estaban creados) optimizados para

cada tarea. El equipo de despliegue será el encargado de crear estos entornos, o mantenerlos y actualizarlos si

ya se habían creado con anterioridad.

Procedemos a explicar los diferentes entornos durante el proceso software, según el modelo SAC MÉTRICA

v.38:

Tabla 2. Entornos

ENTORNOS

TIPO DESCRIPCIÓN

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

codificar y depurar el software. Utilizado por el equipo de

desarrollo.

Entorno de Integración Creado por el equipo de despliegue, diseñado para probar la

relación del software con otros sistemas y la integración de

distintos módulos. Utilizado por el equipo de desarrollo

Entorno de Certificación

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

las revisiones técnicas al software a través de las pruebas

funcionales y no funcionales. Utilizado por el departamento

de calidad OAC

Entorno de Cliente Se trata del entorno donde el cliente se encuentra, entorno donde implantar el software definitivo, para que el usuario

final pueda usarlo sin preocupaciones

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

‘SAC005P_CON_Plan_de_Configuracion_0100’, Normativa Técnica, MÉTRICA v.3


8

1.5 Diagrama de flujo del proceso software

Figura 1. Diagrama de flujo del proceso software

9


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)


10

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

OAC, tras superar satisfactoriamente todas las pruebas, se le comunicará a DP, de manera que el

producto estará listo para las posteriores pruebas de usuario.

10) El usuario realizará las pruebas alfa al software, dentro del entorno de certificación, y decidirá si el resultado final se adapta a las características que exigía en el DDR. Si no es así, lo devolverá a

la OAC para que revise de nuevo los entregables pertinentes, y se decida o no enviarlos al equipo

correspondiente para que los corrija.

11) Si el cliente está satisfecho, la aplicación pasará al equipo de despliegue para que la implante y

realice todos los procesos necesarios para que funcione correctamente en el entorno de cliente. La

OAC revisará el despliegue y realizará de nuevo las pruebas de despliegue y las pruebas de sistema en el entorno de Cliente. Si se detectan incidencias, el equipo de despliegue realizará las

correcciones oportunas y volverá a implantar el software en el entorno de Cliente.

12) El usuario cliente realizará las pruebas beta al software, en su propio entorno. Si detecta

incidencias, tendrá la oportunidad de devolverlo a la OAC las veces que sea necesario para que se encargue de las revisiones pertinentes. Si todo va bien, la entrega se considerará finalizada, y

cliente cerrará el proyecto con el adjudicatario.

11

2 DESCRIPCIÓN ESPECÍFICA DEL SISTEMA

2.1 Introducción

ara la realización de esta sección, se ha hecho uso de la normativa definida por la ISO, al igual que en el apartado anterior: UNE 71044-1999 (ISO/IEC 12207:1995), norma que describe los procesos principales

del ciclo de vida del software, los procesos de apoyo y los procesos organizativos. Seguiremos el orden

que dictan tanto la normativa como el modelo en cascada.

2.2 Comienzo Del Proyecto10

Primera fase del proceso, en la cual, el Cliente estudia su entorno y lleva a cabo un análisis de la realidad para descubrir las carencias del software que se utiliza, para decidir si hace falta una mejora o

actualización del mismo, o la codificación de un nuevo software para cubrir una necesidad encontrada

diferente. Del mismo modo, una vez realizado este análisis, el Cliente llevará a cabo un proceso de adjudicación para su proyecto en vistas a elegir a la entidad (física o jurídica) que llevará a cabo el

proyecto software que cubra las necesidades analizadas.

Esta sección se apoyará en:

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

La norma UNE-EN 16271:2013 Gestión del Valor. Expresión funcional de necesidades y pliego de

especificaciones funcionales. Requisitos para la expresión y validación de las necesidades a satisfacer por

un producto en el proceso de adquisición u obtención del mismo. (Correspondencia con la Norma Europea EN 16271:2012)

*Nota: El comienzo del proyecto es la única parte del proceso software en la cual la OAC no desempeña funciones directas, pero se explicará de manera necesaria para comprender el resto de partes del proceso

software en las que sí interviene Calidad.

2.2.1 Análisis de la Realidad

2.2.1.1 Sin Software previo11

Este es el caso en el que la empresa parte de cero, no posee software inicial. La empresa deberá evaluar su

entorno para reunir los requisitos necesarios que tendrá que tener la aplicación a desarrollar. Los analistas

de la empresa jugarán un papel fundamental en este caso. La clave para reunir la información necesaria es

dividir los procesos de negocio de la empresa en 3 grupos:

Procesos de negocio que actualmente se realizan y se deben seguir realizando o actualizar

Procesos de negocio que actualmente se realizan y no se deben seguir realizando

Procesos de negocio que actualmente no se realizan y se deberían realizar

10 Basado en la sección 5.1 Proceso de Adquisición, UNE 71044-1999 (ISO/IEC 12207:1995) 11 Basado en el est{ndar ISO 21500:2012, Guidance on Project Management, apoyado por referencias a:

https://www.gestiopolis.com/metodologia-para-evaluacion-diagnostico-y-diseno-de-procesos/

P


Descripción específica del sistema

12

12

Con el primer grupo de procesos, los analistas elaborarán un prototipo de requisitos funcionales acerca de las funciones fundamentales que deberá realizar el software como base del funcionamiento. Constituyen

la acción principal de la empresa (o sección de la empresa) y necesitan automatizarse de una manera

rápida y cómoda haciendo uso de módulos software.

Con los procesos que actualmente se realizan y no se deben seguir realizando, se pretende evitar todas las

tareas innecesarias o irrelevantes. A la hora de elaborar los requisitos, los analistas discernirán qué

procesos se deberían evitar en el nuevo software a crear, delimitando así el alcance de los requisitos.

Todos los requisitos que se definan estarán destinados a solicitar las funcionalidades estrictamente necesarias.

Con los procesos que actualmente no se realizan y se deberían realizar, se pretende confeccionar un

prototipo con todos los módulos del software posibles que ayuden a la consecución de las tareas principales. De esta manera, los procesos de negocio que se necesitan llevar a cabo serán realizados por

dicho prototipo, mejorando así el rendimiento de la empresa.

2.2.1.2 Con Software previo12

Este es el caso en el que la empresa parte ya con una aplicación parecida a la que quiere solicitar, que

cubrirá (en mayor o menor medida) los requisitos de la empresa. La motivación de solicitar una nueva

aplicación capaz de mejorar o sustituir a la anterior surge de la evaluación exhaustiva de dicho software, en la cual se detectan carencias, incidencias, aspectos a mejorar, y nuevas funcionalidades que los

usuarios finales echan de menos en la aplicación.

El Cliente puede llevar a cabo el análisis de la realidad haciendo uso de diversas técnicas:

1) Encuestas de software13

: El Cliente prepara un cuestionario con preguntas diseñadas previamente para los usuarios del software a evaluar. Los usuarios rellenarán el cuestionario

por escrito. En este tipo de cuestionarios normalmente se valora si la aplicación cumple

correctamente con las necesidades de las actividades de la empresa, si la forma de llevar a cabo los procesos es la idónea, o si se podría enfocar de otra forma. También se hace una

recopilación de aspectos más técnicos del software, para mejorar este apartado con la nueva

aplicación:

-El software es fácil de usar

-Cubre todos los aspectos necesarios en el desempeño laboral

-Se echa de menos alguna funcionalidad

-Responde rápidamente

-Se bloquea a menudo

Tabla 3. Extracto de cuestionario de satisfacción del usuario con el software que utiliza14

CUESTIONARIO SOFTWARE Muy en

desacuerdo

En

desacuerdo

De

acuerdo

Muy de

acuerdo

Se ejecuta lentamente X

Recomendaría el software a mis colegas X

Se ha detenido inesperadamente en algún

12 Basado en el est{ndar ISO 21500:2012, Guidance on Project Management, apoyado por referencias a:

https://www.emprendepyme.net/tecnicas-e-instrumentos-para-detectar-las-necesidades-de-capacitacion.html, 13 Apoyado en https://es.surveymonkey.com/mp/employee-satisfaction-surveys/ 14 Basada en https://www.survio.com/plantilla-de-encuesta/evaluacion-de-software y respaldado por:

https://www.monografias.com/docs/Ejemplo-encuesta-de-satisfacci%C3%B3n-para-usuario-de-FKZ3RNCMY

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


13


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.


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


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



16

16

2.2.2.2.1 Preparacio n del Pliego de Prescripciones Te cnicas

El cliente dará a conocer sus necesidades al público mediante un documento. Este documento además recogerá

todos los requisitos técnicos a los que deberá dar solución el nuevo proyecto, identificados en el previo análisis

de la realidad. Este documento es el denominado: Pliego de prescripciones técnicas

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

CONTENIDOS DESCRIPCIÓN

TÉCNICOS

(Todas aquellas carencias recogidas en el

previo análisis de la realidad)

Descripción de los trabajos

Objetivos generales

Requisitos de planificación y organización del equipo de trabajo

ADMINISTRATIVOS

(Todos aquellos requisitos requeridos para

la formalización del proyecto)

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

Requisitos de las ofertas:

-Documentación a presentar

-Forma, lugar y plazo

Criterios de valoración

Procedimiento y forma de adjudicación

Requisitos de las empresas ofertantes:

-Tipo de actividad

-Solvencia económica

-Experiencia previa

-Certificados de calidad

Formalización del contrato:

-Cómo se adjudica

-Fecha de la firma

-Avales necesarios

ECONÓMICOS

Presupuesto máximo

Forma de pago

18 Basado en el Trabajo Final Proyectos de Telem{tica, realizado por mí, Antonio Marco Rodrigo Jiménez, y corregido por el profesor titular

(PDI del Departamento de Telem{tica) Rafael Estepa.

17


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



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


19


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:




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:



21


2.2.2.2.4 Elaboracio n de la Oferta

Una vez la empresa contratista se ha decidido a proponerse para el concurso público, deberá elaborar una

Oferta lo más atractiva posible para el Cliente, ya que tendrá que competir con otras empresas que

también desean ganar el concurso.

Los contenidos típicos de un documento de Oferta son los representados en la siguiente tabla:

Tabla 5. Contenidos típicos de una Oferta

CONTENIDO DESCRIPCIÓN

Alcance

Describe todos los entregables, añadiendo una breve descripción de cada uno. Resume

todo lo que la empresa contratista va a ofrecer al Cliente si es elegida.

El alcance también define el ámbito y las responsabilidades de adjudicatario y Cliente.

Esto sirve para delimitar las responsabilidades de ambas partes, y quién se encarga de

conseguir determinados aspectos en el proyecto. Es importante para evitar futuros

problemas de responsabilidad legal, se describen aspectos como:

-Quién facilita lugares o entornos de ejecución necesarios

-Quién se encarga de conseguir permisos legales

-Si se requerirá suministro ilimitado de red eléctrica u otros recursos, etc

Recursos Humanos

Describe el personal que va a participar en el proyecto, pasando por los Directores de Proyecto (DP), Jefes de Equipo, Desarrolladores, OAC, Programadores, Técnicos,

Diseñadores, Documentadores, etc. También incluye su titulación, certificación,

experiencia y salario.

Planificación

Temporal

Describe la temporalización y calendarización de las tareas que se van a realizar desde el

comienzo hasta el final del proyecto. (Siempre respetando la fecha máxima de entrega

designada por el Cliente en el Pliego)

Se suele usar un diagrama de Gantt para diseñar la planificación temporal de manera

gráfica y comprensible.

Presupuestos Detalla los costes que va a tener la aplicación (siempre respetando el presupuesto máximo

designado por el Cliente en el Pliego), desglosando los gastos: Salario de los trabajadores,

gastos generales, instalaciones, etc.

Análisis de Riesgo En esta sección se plasma el resultado de un estudio previo de los posibles problemas que

puedan ocurrir durante el desarrollo del proyecto. Se detalla la probabilidad de que dichos

problemas ocurran, su prioridad y urgencia, y las soluciones planteadas ante los mismos.

Control y

Seguimiento del

Proyecto

Se describe cómo se llevará a cabo la comunicación entre Cliente y adjudicatario. Se detalla la vía y frecuencia de comunicación, las fechas de las reuniones y se define la

estructura de los Informes de Seguimiento: documentos que DP presentará al cliente en

cada reunión indicando los puntos clave de la evolución del proyecto.

Plan de Calidad

En esta sección se describe cómo se va a llevar a cabo el control de calidad por parte de la

OAC durante el proyecto, se define quién forma la OAC y los recursos disponibles para

dicha tarea. También se explica la metodología de revisiones técnicas y ejecución de

pruebas que la OAC va a utilizar.

Plan de Negocio Se calculan parámetros para comprobar la rentabilidad del proyecto. Se detalla la visión

de futuro del proyecto, la posibilidad de seguir trabajando para el mismo Cliente, y se

calculan los flujos de caja (Cash Flow) anuales, actualizando los costes y beneficios.

Anexos

En caso de que existan, se suele tratar de leyes y normativas, planos generales, guías de

usuario de interfaces o documentos de diseño extra.

La cantidad y tipo de anexos variarán en gran medida según el tipo de proyecto/SFW.


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


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.


24

24

Los entregables arriba descritos vienen recogidos en lo que se denomina un diagrama WBS (Work Breakdown Structure „Estructura de Descomposición del Trabajo‟). Se trata de una representación gráfica de los

entregables finales al Cliente, divididos por categorías. Se encarga de recoger de manera visual todos los

entregables una vez aceptado el proyecto. Aquí mostramos un ejemplo genérico:

Figura 6. Ejemplo de Diagrama WBS

25


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





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/


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


2.3 Definición Del Proyecto

Para la realización de esta sección nos hemos basado fundamentalmente en la norma UNE-ISO/IEC 90003-200, ISO 9001-2000 y MÉTRICA v.3, Modelo SAC: „SAC007P_DDR_Definicion Detallada

Requisitos_0100‟, añadiendo a pie de página referencias más específicas referentes a cada parte de la

sección de definición del proyecto.

Llegados a este punto, el Cliente ya ha elegido a su empresa contratista que va a realizar el Proyecto

Software que cubrirá sus necesidades. Ahora que ya están dispuestos a trabajar juntos, y se ha firmado el

contrato, la comunicación entre Cliente y contratista será indispensable. De esta necesidad surge la figura de DP (Dirección de Proyectos). El director o la directora de proyectos será aquella persona responsable

de ponerse en contacto con el Cliente para todo lo relacionado con el proyecto.

24RAU, DP y una representación del usuario final de la aplicación de la empresa cliente, llevarán a cabo

una primera reunión en la cual pondrán en común toda la información posible para elaborar el DDR, atendiendo a las necesidades del Pliego de Prescripciones Técnicas propuesto por el cliente, y al alcance

propuesto en la Oferta de la empresa contratista para dar solución a dichas necesidades. Dado que el

Cliente ha elegido a la empresa ganadora, es previsible que las necesidades del Cliente y lo que ofrece la empresa sean idénticas o muy parecidas, o que al menos se cubra la mayoría de las necesidades

requeridas.

Se llevarán a cabo varias reuniones de puesta en común, hasta que DP reúna todos los requisitos solicitados por RAU y los usuarios finales. (La labor de la OAC en esta sección será la de realizar una

revisión técnica al DDR antes de continuar a la siguiente fase, cuyos detalles veremos más adelante en el

apartado: 2.5 Control de Calidad).

25Es importante convocar tantas reuniones como sea necesario para asegurarse de que absolutamente

todos los requisitos que Cliente solicita queden correctamente recogidos por DP. Con el modelo en

cascada que estamos usando para este caso, es imprescindible que este paso sea perfecto y sin errores o

ambigüedades, ya que un fallo al comienzo de un proceso en cascada, acarrea problemas en todas las etapas siguientes.

El documento que elaborará DP incluyendo todos los requisitos recogidos en estas reuniones es el

denominado DDR (Definición Detallada de Requisitos), enmarcado según MÉTRICA v.3 en la fase de

Análisis del Sistema de Información (ASI).

El DDR tiene como objetivo recoger todos los requisitos del cliente para su aplicación. Normalmente, los

participantes implicados en su elaboración son el Jefe de Proyecto del Proveedor, el Jefe de Proyecto del Cliente, y analistas.

Hay distintos tipos de requisitos, según el recurso de referencia 0408 de MADEJA (Marco de Desarrollo

de la Junta de Andalucía)26

y la norma ISO/IEC 9126 „Software engineering - Product quality‟ clasificados según la naturaleza de los mismos:

24 Apoyado por la Norma ISO/IEC 14764:1999, apartado 7.3.3 (directrices para un plan de mantenimiento). 25 Apoyado por la Norma ISO/IEC 12207:1995/Amd.1:2002, apartados F.1.3.1, F.1.3.2, F.1.3.4, 5.2.1, 5.2.6, 6.4.2.1, 6.6 y F3.1.5 26 Subsistemas de Ingeniería, RECU-0408, http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/408

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/408


28

28

Tabla 8. Tipos de Requisitos

TIPOS DE REQUISITOS

TIPO SUBTIPO SIGLAS DESCRIPCIÓN

FUNCIONALES

(RF)

CASOS DE USO CU

Especifican el comportamiento del sistema.

Describen lo que el sistema debe hacer, qué

funcionalidades debe incorporar la aplicación,

y qué acciones debe ser capaz de realizar,

describiendo las interacciones entre sistema y

usuarios.

REGLAS DE NEGOCIO

RN Especifican las normas del negocio que el

software tendrá que respetar y seguir.

DE CONDUCTA RC

Especifican aquellas tareas relacionadas con

otros usuarios o sistemas, cuando el software

resulta necesario para la consecución de los

objetivos de estos últimos.

DE INFORMACIÓN RIN Especifica la información y los datos que el

software deberá gestionar para funcionar

correctamente.

NO

FUNCIONALES

(O TÉCNICOS)

(RNF)

DE ENTORNO

TECNOLÓGICO RE

Describen el ambiente operativo en el que se

debe desenvolver el sistema.

DE SEGURIDAD RS

Garantizan la seguridad de tecnología de

información, seguridad de datos, seguridad

lógica, control de acceso a información

(restricciones de acceso), autenticidad de la

información, privacidad, entre otros aspectos.

DE FIABILIDAD RFI Describen la tolerancia a fallos del software y

su respuesta bajo condiciones específicas

DE USABILIDAD RU

Describen todos aquellos aspectos

relacionados con la interacción directa

software-cliente, como su facilidad de uso, su

comprensión, etc.

DE

MANTENIBILIDAD RM

Describen la capacidad o facilidad del

software para ser actualizado, analizado y

corregido en el futuro una vez implantado.

DE INTERFAZ RI Describen la comunicación con sistemas

externos, y cómo debe ser esa comunicación.

DE RENDIMIENTO Y DISPONIBILIDAD

RR

Describen la disposición del sistema para

brindar servicio correctamente y garantizar una velocidad, tiempo de respuesta y consumo

de recursos óptimos, entre otros.

OTROS RO

Derivados del entorno organizacional, entre

los que se incluyen aspectos éticos,

seguimiento de estándares y plantillas, y

requerimientos legales y regulatorios.

29


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’


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


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‟


32

32

Tabla 9. Estructura de un DAO

DAO

SECCIÓN DESCRIPCIÓN

1. INTRODUCCIÓN

Subsecciones:

1.1 Objeto

1.2 Alcance

1.1 Objeto Se describe el propósito del documento de Diseño de Arquitectura Orientado a Objetos del Sistema para la entrega específica.

1.2 Alcance Se describen las unidades organizativas y responsabilidades a las que va

dirigida el DAO y que participan en su generación, validación y registro.

2. DESCRIPCIÓN DEL

ENTORNO

TECNOLÓGICO

En esta sección se consideran fundamentalmente los RE. Se describen en las

subsecciones aspectos como la capacidad de almacenamiento requerida,

software quue se va a utilizar, etc de manera aproximada y orientativa, para

guiar al equipo de Codificación. (Siempre bajo las necesidades o limitaciones

definidas en los RE). Subsecciones:

2.1 Elementos de la infraestructura

2.2 Restricciones Técnicas

2.3 Planificación de Capacidades

2.1 Elementos de la

infraestructura

Descripción de la infraestructura tecnológica agrupándola en los siguientes

conceptos:

Hardware: procesadores, unidades de almacenamiento, estaciones de trabajo, etc. necesarios para explotar el sistema.

Software: sistemas operativos, sistemas gestores de base de datos,

middleware, sistemas de ficheros, software de base, herramientas y utilidades

de gestión del sistema, etc.

Comunicaciones: diseño de la topología de red, protocolos, nodos de red,

etc.

En este punto, también se deberán detallar las medidas de seguridad que se

tomarán en el sistema.

2.2 Restricciones Técnicas En base a la infraestructura tecnológica del sistema, se procederá a identificar

y describir las restricciones técnicas derivadas de la utilización de la

tecnología seleccionada y que afecten al diseño o construcción del software.

2.3 Planificación de

Capacidades

Se describen los requisitos mínimos de hardware que deberán tener los

equipos finales para lanzar correctamente la aplicación, especificando los parámetros de explotación precisados para su realización, indicando las

necesidades de:

Almacenamiento: espacio en disco, espacio en memoria, pautas de

crecimiento y evolución estimada del sistema de información, etc.

Procesamiento: número y tipo de Procesadores, memoria, etc.

Comunicaciones: líneas, caudal, capacidades de elementos de red, etc.

Para la realización de la planificación de las capacidades será necesario tener

en cuenta entre otros el Modelo Físico de Datos.

3. ARQUITECTURA DE Subsecciones:

33


CLASES DEL SISTEMA 3.1 Definición de Niveles de Arquitectura del Sistema

3.2 Diseño de Casos de Uso

3.3 Modelo de Clases de Diseño

3.1 Definición de Niveles de

Arquitectura del Sistema

Se describen los niveles de la arquitectura software, mediante la definición de

las principales particiones físicas del sistema de información, representadas

como nodos (partes del sistema) y comunicaciones entre nodos (interfaces

entre las partes del sistema).

3.2 Diseño de Casos de Uso

Se especifica el comportamiento del sistema para cada caso de uso. Por ello

será necesario identificar las clases que intervienen en cada caso de uso,

teniendo en cuenta las clases adicionales que surgen como consecuencia del

diseño. Una vez identificadas las clases participantes dentro de un caso de

uso es necesario completar los escenarios que se recogen del análisis,

incluyendo las clases de diseño que correspondan y teniendo en cuenta las

restricciones del entorno tecnológico. Es necesario analizar los

comportamientos de excepción para dicho escenarios.

3.3 Modelo de Clases de

Diseño

Se describen las clases que va a tener el sistema, así como sus atributos,

métodos y relaciones entre ellas. Se deberá detallar toda la información mencionada para cada clase, así como elaborar un diagrama de clases que

muestre los atributos, métodos y relaciones más importantes entre las clases

definidas, que representará los aspectos estáticos del sistema.

4. DISEÑO DE

INTERFACES DEL

SISTEMA

Subsecciones:

4.1 Diseño de interfaz de usuario

4.2 Diseño de interfaces con otros sistemas

4.1 Diseño de interfaz de

usuario

El objeto de esta sección es realizar el diseño detallado del comportamiento

de la interfaz de usuario de acuerdo con el entorno tecnológico definido. En

el caso de que existiese un prototipo de la interfaz de usuario se tomaría

como punto de partida para el diseño. Se deben incluir, además, las ventanas

o pantallas o elementos de diseño surgidos como consecuencia del diseño de

los escenarios definidos en los casos de uso.

4.2 Diseño de interfaces con

otros sistemas

El objetivo de esta sección es describir cada caso de uso en términos de los

sistemas externos que participan en el caso de uso y de las interfaces que se requieren entre ellos.

Para cada caso de uso hay que definir, además de los sistemas exteriores y los

actores que intervienen en el mismo, los mensajes que se intercambian entre

el sistema en desarrollo con el resto de sistemas.

5. MODELO FÍSICO DE

DATOS

El objetivo de esta actividad, es definir la estructura física de los datos que

utilizará el sistema, a partir del modelo lógico de datos normalizado teniendo

en cuenta el entorno tecnológico que albergará el nuevo sistema. El diseño

del modelo físico de datos puede englobar clases, bases de datos, ficheros a

utilizar, etc.

6. ANEXOS Este punto contendrá toda aquella información de interés para la elaboración

y validación del documento de Diseño de Arquitectura Orientado a Objetos.

7. GLOSARIO Este punto contendrá la definición de todos los términos utilizados en el

documento Diseño de Arquitectura Orientado a Objetos del Sistema y que

formará parte del diccionario de la aplicación.

8. BIBLIOGRAFÍA Y

REFERENCIAS

En este punto se incluirán las referencias a la documentación utilizada para la elaboración de dicho documento.


34

34

Una vez elaborado el documento, el diseño de la aplicación se da por finalizado, y se enviará al departamento de calidad. La labor de la OAC en esta sección será la de realizar una revisión técnica al

DAO antes de continuar a la siguiente fase, cuyos detalles veremos más adelante en el apartado: 2.5

Control de Calidad. Una vez que el DAO supere satisfactoriamente la revisión técnica realizada por Calidad, se pasará a la siguiente fase: La codificación del software.

Por otro aldo, al tener ya realizado el diseño de la aplicación, es posible ver de qué manera se puede

probar el software, en sus aspectos tanto funcionales como técnicos. Es por eso que en esta fase se

elaborarán diversos planes de prueba, los cuales describirán las pruebas que tendrá que realizar la OAC para garantizar el correcto funcionamiento del software.

Concretamente, en esta fase, el equipo de Desarrollo elaborará:

PPU (Plan de Pruebas Unitarias)

PPI (Plan de Pruebas de Integración)

PPS (Plan de Pruebas de Sistema)

PPF (Plan de Pruebas Funcionales)

PPNF (Plan de Pruebas No Funcionales)

*Nota: El Plan de Pruebas No Funcionales se completará en la fase de Codificación, una vez se tenga

generado el software. En la mayoría de casos, gran parte de las pruebas descritas en el PPNF forman parte

de las pruebas de Sistema, y se incluyen también en el PPS.

*Nota: Se ha realizado esta clasificación de los planes de prueba según el modo de operación seguido

bajo nuestra experiencia en la OAC en everis. Al igual que ocurre con el PPNF y PPS, el PPF y el PPA

pueden compartir muchas pruebas o ser casi idénticos según el caso. La diferencia principal es que el PPF está dirigido a la OAC, mientras que en el PPA las pruebas están dirigidas al usuario final, y están

descritas de una manera diferente, más enfocadas a la perspectiva del Cliente.

35


2.5 Codificación Del Proyecto

En el punto intermedio del proceso software en el que nos encontramos, le llega el turno al equipo de Codificación. En este punto, el equipo de Diseño habrá elaborado satisfactoriamente el DAO, y el equipo

de Codificación tendrá que seguirlo para codificar el software de la aplicación, dando lugar a la fase CSI

(Construcción del Sistema de Información), cuyas tareas (junto con las restantes de la fase DSI) y sus responsables se resumen en:

Tabla 10. Tareas DSI y CSI de Desarrollo

TAREAS DSI Y CSI DE DESARROLLO

FASE TAREA RESPONSABLE

DSI

(Diseño del Sistema de

Información)

Elaboración de la mayor parte del PP

total: PPU, PPI, PPS, PPF y una parte

del PPNF.

Desarrollo

Codificación de Scripts (SCR) Desarrollo

(Equipo de Codificación)

CSI

(Construcción del Sistema

de Información)

Preparación del Entorno de

Construcción Equipo de Despliegue

Generación del Código de los Componentes y Procedimientos

(Software SFW)

Desarrollo

(Equipo de Codificación)

Elaboración de la parte restante del PPNF, completando así el PP total

Desarrollo

Elaboración del MUS

(Manual de Usuario)

Elaboración del MIC

(Manual Básico de Instalación y Configuración)

(Tabla realizada según 29

MÉTRICA v.3, modelo SAC: „DSI Procedimiento Global‟)

El buen trabajo de esta fase se reflejará en la codificación de una aplicación que se adapte al diseño

elaborado previamente, que cumpla todos los requisitos del DDR y que esté bien documentada para

facilitar su corrección tras posibles incidencias halladas por la OAC. Cualquier miembro del equipo de Codificación debería ser capaz de continuar con la codificación en cualquier momento antes de

terminarla, así como de encargarse de su corrección tras una revisión técnica de la OAC. Esto es lo que

marcará un resultado satisfactorio por parte de este equipo.

29 Apoyado en la norma ISO 9001-2000, sección 7.3: „Diseño y Desarrollo‟ y en la norma ISO/IEC 12207, sección: „Development‟


36

36

2.5.1 Preparación Del Entorno de Construcción

En primer lugar, el Equipo de Despliegue se encargará de crear (o preparar si ya existía previamente) el entorno de Desarrollo y de Integración. (Más detalles en la sección 2.8 Despliegue).

El resultado de esta tarea es que el equipo de Despliegue dejará listo el entorno de Desarrollo y de

Integración para la codificación del software, dando paso a la siguiente tarea.

2.5.2 Generación de Código

Una vez listo el entorno de Desarrollo e Integración, el equipo de Codificación junto con el JP generará el

código de los componentes del sistema de información identificados en los procesos previos de ASI y

DSI. La base, por tanto, para su codificación deben ser las especificaciones de construcción obtenidas del

DAO en el proceso de DSI.

El SFW codificado necesitará en ocasiones de ciertos scripts (SCR) sql que afectan a diferentes Bases de

Datos (BBDD) requeridas por la aplicación. Será tarea a su vez del equipo de Codificación el codificar

dichos SCR respetando la normativa técnica. Tanto el SFW como los SCR si los hay, serán sometidos a revisiones técnicas y probado según el Plan de Pruebas por la OAC.

Por otro lado, la labor de Desarrollo incluye además la elaboración de 3 documentos: un manual de

instalación de la aplicación, un manual de uso de la aplicación, y un plan de pruebas que facilite la

revisión técnica de la aplicación.

A continuación, describiremos detalladamente los documentos que Desarrollo tendrá que elaborar.

2.5.3 MIC (Manual básico de Instalación y Configuración)

El MIC es un documento cuyo objetivo es indicar de manera detallada cómo instalar y configurar la

aplicación por primera vez (ya sea en el entorno de certificación de la OAC, o en el entorno de cliente del

usuario final).

Este procedimiento reúne los recursos básicos para la instalación (humanos, hardware y software), detalla

los requisitos previos a la instalación y los pasos de la misma, incluyendo la ejecución de los SCR (si los

hubiera) en qué instancia de BBDD, la edición (en caso de necesitarla) de los ficheros de configuración

del SFW, y la compilación de todos los objetos, entre otros.

En algunos casos, el MIC describe el procedimiento para instalar el software un escenario tipo sandbox

antes del despliegue en el escenario real. Al instalar el software en un escenario tipo sandbox (con el uso

de un software o máquina virtual a tal efecto) se comprueba que todo funcione correctamente antes del despliegue en el escenario real sin afectar a éste, ya que cualquier acción en el entorno sandbox estará

aislada.

También incluye la realización de un backup o copia de seguridad del entorno actual del equipo antes de instalar la aplicación, en caso de que hubiera algún problema, poder volver atrás al punto de restauración

previo. Se detalla a su vez cómo realizar esta marcha atrás, indicando los pasos necesarios de borrado o

ejecución de SCR automáticos codificados por el equipo de Desarrollo.

A continuación, veremos de qué partes consta típicamente un MIC elaborado por Desarrollo, según MÉTRICA v.3, modelo SAC: „SAC007P_MIC_Manual_Instalacion_Configuracion_0100‟.

Tabla 11. Estructura de un MIC

MIC


1. DESCRIPCIÓN DEL

PROBLEMA/CAMBIO Y

En este apartado se describirá el motivo que originó el desarrollo de la

entrega. Ésta puede venir originada por una incidencia detectada o para

37


SOLUCIÓN ADOPTADA añadir o modificar cierta funcionalidad del sistema. Así mismo, se describirá

la solución técnica adoptada a grandes rasgos.

2. RECURSOS

EXTRAORDINARIOS

Se describen los recursos necesarios para la instalación, incluyendo:

Recursos humanos: Administradores de sistemas en los diferentes entornos, y

los usuarios finales.

Software: Compiladores, versiones de determinados programas o interfaces,

necesarios para instalar e interactuar con la aplicación desarrollada

Hardware: Requerimientos extra de CPU, espacio en disco, etc.

3. INSTALACIÓN Y

CONFIGURACIÓN DEL

SISTEMA

Subsecciones:

3.1 Requisitos previos

3.2 Procedimiento de instalación

3.1 Requisitos previos

Se detallan prerrequisitos necesarios para que la aplicación se pueda instalar

satisfactoriamente. Plantea cuestiones relacionadas con la conexión y

desconexión de usuarios antes de comenzar la instalación, el acceso a la

aplicación, si se debe coordinar la instalación con la de otro SFW para que

funcione sin problemas o si es necesario salvaguardar un punto de

restauración y realizar backups del esquema, entre otros.

3.2 Procedimiento de

instalación

Este constituye el punto clave del documento. En él se describen detalladamente los pasos necesarios para instalar la aplicación en el entorno

de pruebas o el entorno de usuario final. Para cada tarea se indicarán los

siguientes datos:

Número del paso (secuencial)

Tipo de tarea: Especificando si es una de las siguientes:

-CON: Configuración de archivos

-PAR: Configuración de parámetros propios de la

aplicación en BBDD

-SCR: Ejecución de scripts de BBDD

-SFW: Compilación/Ejecución de software. Se deben

indicar las librerías de las que se hace uso.

-IMP: Import de datos, indicando las sentencias completas

con todos sus parámetros

Descripción: Lo más detallada posible, ya que no se sabe quién va a

ser la persona encargada de instalar la aplicación

4. MARCHA ATRÁS

En este apartado se indicarán las instrucciones necesarias para realizar la

marcha atrás de la entrega, dejando el sistema en el mismo estado estable en

el que se encontraba antes de comenzar la instalación. Si es necesaria la

ejecución de scripts de marcha atrás para dejar el esquema de base de datos

en la situación consistente anterior, éstos se deben incrustar comprimidos en

ZIP. Posteriormente, se describe el procedimiento utilizando dichos scripts.

5. ANEXOS Este punto contendrá toda aquella información de interés para la elaboración

y validación del presente documento

6. GLOSARIO Este punto contendrá la definición de todos los términos y acrónimos

utilizados en el documento

7. BIBLIOGRAFÍA Y

REFERENCIAS

En este punto se incluirán las referencias a la documentación utilizada para la elaboración del documento.


38

38

2.5.4 MUS (Manual de Usuario)

El objetivo del MUS es explicar al usuario final cómo utilizar todas las funcionalidades de la aplicación

desarrollada. Resulta esencial que el manual esté escrito de forma clara y comprensible.

El MUS incluirá un mapa del sistema, para que el usuario aprenda a navegar a través de las diferentes

secciones de la misma. Por cada ventana/sección del programa, el MUS incluirá una descripción de todas

las funcionalidades, botones, menús y desplegables existentes, detallando qué hace cada uno de estos elementos. Adjuntará a su vez pantallazos o capturas del programa para facilitar la comprensión y la

navegación.

Por último, el documento anexará bastante información de utilidad, como los requisitos y procesos que

cubre cada sección o funcionalidad de la aplicación, incidencias frecuentes, mensajes de error, y una sección de FAQ (Frequently Asked Questions o PP.FF Preguntas Frecuentes).

A continuación, veremos de qué partes consta típicamente un MUS elaborado por Desarrollo:

Tabla 12. Estructura de un MUS

MUS


1. DESCRIPCIÓN DEL

SISTEMA

Subsecciones:

1.1 Objeto

1.2 Alcance

1.3 Funcionalidad

1.3.1 Funcionalidad sustituida

1.3.2 Funcionalidad aportada

1.4 Mapa del sistema

1.1 Objeto En este apartado se detallará cual es el objeto o función global del sistema

dentro de la organización.

1.2 Alcance

En este apartado se detallará cual es el alcance del sistema dentro de la

organización, a qué unidades afecta de forma activa y a cuales de forma

pasiva. Es decir, qué unidades dentro de la organización participan o usan el

sistema de forma activa y qué unidades se ven afectadas por el mismo de

forma pasiva o sin tener contacto con él.

1.3.1 Funcionalidad sustituida Detalla cuáles son las diferencias funcionales entre los anteriores procesos si

los hubiera y el nuevo sistema.

1.3.2 Funcionalidad aportada En este apartado se describirá la funcionalidad que el nuevo sistema

implementa y aporta a la organización.

1.4 Mapa del sistema

En este apartado se hará una descripción del sistema. Se comenzará

describiendo el sistema en su entorno, se continuará con una descomposición lógica del sistema por módulos, a continuación se describirá cada módulo,

etc. El límite inferior lo pondrá el autor del documento.

Es altamente recomendable que para sistemas con una interfaz de

ventanas/pantallas se describa, también, la navegación a través de un grafo de

ventanas. En este diagrama se representarán todas las ventanas del sistema y

mediante flechas todas las posibles navegaciones entre las mismas.

39


2. OPERATIVA DEL

SISTEMA

Esta es la sección clave del documento. En ella se describirá la aplicación

entera, parte por parte, describiendo todas las funcionalidades aportadas. Se describirán todas las ventanas del programa, orientado a explicar el sistema a

través de la interfaz gráfica de usuario. Se explicarán las acciones permitidas

en cada ventana, y se adjuntarán capturas o pantallazos para guiar al usuario

en todo momento.

3. ANEXOS

Subsecciones:

3.1 Ref Proceso / Requisito

3.2 Ref Proceso / Validación

3.3 Incidencias frecuentes

3.4 Mensajes de error

3.5 Términos y acrónimos

3.6 FAQ

3.7 Ayudas

3.1 Ref Proceso / Requisito En este apartado se ofrecerá una referencia cruzada entre los requisitos

recogidos al inicio del proyecto y los procesos que componen el sistema. Se marcarán los procesos que resuelven un requisito y viceversa.

3.2 Ref Proceso / Validación Se enumerarán todas las validaciones que el sistema realiza y se relacionarán

con los procesos que lo componen.

3.3 Incidencias Frecuentes En este apartado se enumerarán las incidencias más frecuentes que se pueden

encontrar durante el uso de la aplicación y, junto a cada una de ellas, se

ofrecerá una solución.

3.4 Mensajes de error Se ofrecerá una lista con todos los mensajes de error que el sistema ofrece al

usuario, bien sea a través de ventanas o de ficheros de log, y se adjuntará una

descripción más extensa para cada uno de ellos.

3.5 Términos y acrónimos En este apartado se ofrecerá una lista de términos y acrónimos usados en el

programa y una definición para cada uno de ellos.

3.6 FAQ Se ofrecerá una lista de las preguntas o dudas más frecuentes que pueden

surgirle a un usuario del sistema junto a una explicación para cada una de

ellas.

3.7 Ayudas En caso de que el sistema tenga un sistema de ayuda, se ofrecerá una breve

guía de uso sobre el mismo.

4. GLOSARIO Este punto contendrá la definición de todos los términos y acrónimos

utilizados en el documento

5. BIBLIOGRAFÍA Y

REFERENCIAS

En este punto se incluirán las referencias a la documentación utilizada para la elaboración del documento.


40

40

2.5.5 Elaboración del PP (Plan de Pruebas)

El PP (Plan de Pruebas) es un documento que tiene como objetivo aportar pruebas para verificar y validar

la aplicación. Generalmente este documento está dirigido a la OAC (Oficina de Aseguramiento de Calidad), ya que Calidad será responsable de realizar la mayoría de las pruebas descritas en dicho PP, las

cuales son pruebas de integración, de sistema, de regresión, de humo, de despliegue, y todas las pruebas

no funcionales. Por otro lado, Desarrollo realizará las pruebas unitarias y el usuario final realizará las pruebas de aceptación.

El PP está formado por varios planes de prueba distintos. Un Plan de Pruebas es un documento en el que

se resumen las pruebas de un determinado tipo, cuyo objetivo es comprobar un aspecto específico del

software, ya sea funcional o técnico.

Describiremos detalladamente las diferentes pruebas detalladas en los planes de prueba en la sección

2.6.2 Pruebas.

En la siguiente tabla mostramos de qué Planes de Prueba diferentes consta un PP completo:

Tabla 13. Estructura del PP

PP

PLAN DESCRIPCIÓN CREADOR EJECUTOR

PPA (Plan de Pruebas de Aceptación)

Plan de pruebas que describe las

pruebas de aceptación. Elaborado en la fase ASI, tras la realización del DDR.

OAC Usuario final

PPU

(Plan de Pruebas Unitarias)


pruebas unitarias. Elaborado en la fase

de Diseño, tras la realización del DAO.

Desarrollo

Desarrollo

PPI

(Plan de Pruebas de Integración)


pruebas de integración. Elaborado en la

fase de Diseño, tras la realización del

DAO.

OAC

PPS

(Plan de Pruebas de Sistema)


pruebas de sistema. Elaborado en la


DAO.

PPF

(Plan de Pruebas Funcionales)


pruebas funcionales. Elaborado en la


DAO.

PPNF

(Plan de Pruebas No Funcionales)


pruebas no funcionales. Elaborado en primer lugar en la fase de Diseño tras

la realización del DAO, y completado

en la fase de Codificación, tras

codificar el software.

Desarrollo

Como al codificar el software se completa el PPNF, el PP estará completo en este punto, y listo para ser

enviado a la OAC para que comience con la ejecución de todas las pruebas descritas en el documento.

41


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


1. DESCRIPCIÓN

GENERAL

En esta sección se numeran los Casos de Prueba definidos en el documento y

qué RF del DDR testea cada uno.

También se añade una breve descripción de qué es la funcionalidad que se va

a probar y cómo se va a probar.

2. ENTORNO DE PRUEBAS

Se indican los requisitos hardware y software necesarios para llevar a cabo

los diferentes Casos de Prueba. Se indican entre otros:

-Versiones compatibles

-Entornos de prueba admitidos

-Si hacen falta herramientas auxiliares

-Tecnología de la aplicación

3. CASOS GENERALES

La función general de este apartado es definir a los usuarios de prueba. Se

indica qué tipo de usuarios deberán entrar en la aplicación para probarla, y se

añaden los pasos para dotar a dichos usuarios de los roles y permisos

necesarios.

*Nota: Cada Caso de Prueba puede necesitar de un usuario de pruebas distinto, en función de los RF que se quieran probar, necesitando así de dotar

a los usuarios de distintos roles o privilegios.

4. CASOS DE PRUEBA

(CP)

Este es el apartado clave del documento. En él se definen los diferentes Casos

de Prueba (CP) que tendrá que ejecutar la OAC para testear correctamente la

aplicación. Cada CP consta de las siguientes subsecciones:

1) RF testeado: Indica qué RF del DDR se prueba con este CP.

2) Descripción: Se describe qué funcionalidad se va a probar

exactamente y cómo se va a probar.

3) Prerrequisitos: Si aplica, se indican los pasos previos necesarios

antes de comenzar a probar el CP. (Dotación de roles, creación de

tablas sql, etc).

4) Roles del usuario de pruebas: Indica qué usuario de pruebas se

debe usar en este CP y qué roles y privilegios debe poseer.

5) Tiempo necesario de ejecución: (en minutos)

6) Secuencia de ejecución

7) CASO DE PRUEBA

5. ANEXOS Se incluyen los anexos necesarios (si aplica) para la ejecución de las pruebas.

Si no es texto, deberá indicarse cómo se llaman los archivos anexos, y

deberán ir adjuntos al PPF comprimidos en un .zip .rar etc.


42

42

Los CP definidos en el PPF deben estar detalladamente explicados, describirse paso por paso y estar enfocados a la OAC, los cuales no han desarrollado la aplicación. Esto quiere decir que Desarrollo debe

tener cuidado a la hora de redactar los CP, porque no puede esperar que otros asuman información que

para ellos es obvia (ya que ellos han desarrollado el SFW de la aplicación).

La siguiente es la estructura típica de los Casos de Prueba:

Tabla 15. Estructura de un Caso de Prueba

CASOS DE PRUEBA (CP)

PASO DESCRIPCIÓN PROGRAMA / VENTANA

DATOS DE ENTRADA

SALIDA ESPERADA

OBSERVACIONES

Número

del paso

de

ejecución

.

Instrucciones: qué

es lo que tiene

que hacer el

tester.

Ventana de la

aplicación en la

que debería

encontrarse en

este paso.

En caso de que

en este paso se

tengan que

introducir datos

de entrada,

detalla cuáles

son.

Reacción

esperada del

programa. Si

la ejecución

cumple lo

descrito aquí,

se da por

verificado este

paso.

Si se considera

necesario, aquí se

describen aclaraciones,

consejos,

recomendaciones y

avisos.

En ocasiones, los Casos de Prueba se dividen en Ciclos. Los ciclos se usan cuando hay que realizar

ciertas pruebas previas a otras en una misma sección / ventana de la aplicación para probar una

funcionalidad completa. Mostramos a continuación un ejemplo de Caso de Prueba:

Tabla 16. Ejemplo de Caso de Prueba

CASOS DE PRUEBA (CP)

PASO DESCRIPCIÓN PROGRAMA

/ VENTANA

DATOS DE

ENTRADA

SALIDA

ESPERADA OBSERVACIONES

1 Entra en la

sección: Pruebas Menú principal

Acceso a la sección:

Pruebas

2 Pulsa el botón de:

“Subir fichero” Menú principal

/ Pruebas

Ventana de selección de fichero

del disco duro local

Se mostrará el último directorio accedido por

la aplicación

3

Selecciona el

fichero deseado

del disco duro

local

Menú principal

/ Pruebas /

Ventana de

selección de

ficheros

Fichero

deseado

Se carga el fichero

deseado en la

ventana de

selección de

ficheros

4

Rellenar la fecha

de subida y pulsar

el botón

“Guardar”

Menú principal

/ Pruebas /

Ventana de

selección de

ficheros

Fecha:

Fecha actual

Se guarda el

fichero, se actualiza

la fecha de carga y

se vuelve al menú

de Pruebas

5 Salir de la

aplicación

Menú principal

/ Pruebas

Sale de la

aplicación

Puede tardar unos

segundos en completar

la acción

43


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.


44

44

2.6 Control de Calidad

En esta sección, se describirá mayoritariamente la fase CEI / IAS, en la cual se certificará, implantará y validará la aplicación. La mayor parte de las labores de la fase CEI las realiza la OAC. La OAC ha estado

realizando tareas de certificación y revisiones técnicas durante las etapas anteriores del proceso, todas

ellas pertenecen a la fase CEI.

Según la ISO 9000:2000, la calidad se define como “grado en que un conjunto de características

inherentes cumple con unos requisitos”. El Aseguramiento de la Calidad pretende dar confianza en que el

producto reúne las características necesarias para satisfacer todos los requisitos del Software.

Una organización orientada a la calidad promueve una cultura que da como resultado comportamientos,

actitudes, y actividades y procesos para proporcionar valor mediante el cumplimiento de las necesidades

y expectativas del Cliente.30

La calidad de los entregables y servicios de una organización está determinada por la capacidad para satisfacer al Cliente, y no sólo incluye su función y desempeño previstos, sino también su valor percibido

y el beneficio para el Cliente.

Para asegurar la calidad de los entregables resultantes la OAC deberá realizar un conjunto de actividades que servirán para:

31

- Reducir, eliminar y lo más importante, prevenir las incidencias de calidad de los entregables a obtener.

- Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario queden satisfechas.

El grupo de aseguramiento de calidad participa en la revisión de los productos seleccionados para

determinar si son conformes o no a los procedimientos, normas o criterios especificados, siendo

totalmente independiente del equipo de desarrollo. Las actividades a realizar por la OAC vienen gobernadas por el plan de calidad descrito en la oferta. Sus funciones están dirigidas a:

- Identificar las posibles desviaciones en los estándares aplicados, así como en los requisitos y

procedimientos especificados.

- Comprobar que se han llevado a cabo las medidas preventivas o correctoras necesarias.

Las revisiones son una de las actividades más importantes del aseguramiento de la calidad, debido a que

permiten eliminar defectos lo más pronto posible, cuando son menos costosos de corregir.

Para revisar cualquier entregable, la OAC crea una serie de “Plantillas”, a las cuales deberán adaptarse los entregables recibidos. Estas plantillas reflejan lo que debería ser un “entregable perfecto”. Además,

con su creación, se acelera el proceso de certificación para posteriores entregas, ya que deberán adaptarse

a la misma plantilla.32

El objetivo principal de la fase CEI es certificar la entrega. Una entrega certificada es aquella que, tras

superar satisfactoriamente las revisiones técnicas de la OAC ha quedado completamente validada y

verificada. Una entrega certificada por Calidad es apta para su uso.

30 Referencia a la norma UNE EN ISO 9000 2015 31 Referencia a la norma METRICA V.3, ‘Aseguramiento de la Calidad’ 32 Basado en MÉTRICA v.3, modelo SAC, Objetivos del Sistema de Aseguramiento de la Calidad

45


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

http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/creacion-y-evolucion-sistemas

http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/227

https://es.wikipedia.org/wiki/Pruebas_de_software


46

46

2.6.1.1 Pruebas Estáticas

Para realizar las pruebas estáticas no se necesita ejecutar la aplicación. Estas pruebas se refieren a la

revisión técnica documental que la OAC debe realizar con cada documento y fichero de código de cada una de las fases del proceso software.

Las pruebas estáticas que realiza la OAC se resumen por un lado en la revisión técnica del DDR (en la

fase ASI), del DAO y PP (en la fase DSI) y del MIC y MUS (en la fase CSI).

Por otro lado, se resumen en la corrección formal de los ficheros de código, ya sean de SFW o de SCR.

Es decir, se comprueba (ya sea manualmente o con el uso de herramientas que analizan el código) que la

codificación sigue la normativa establecida y responde ante indicadores de calidad y de programación ordenada, entre otros, dando lugar a un código limpio, comprensible y reutilizable.

Una herramienta útil utilizada por mi equipo en el departamento de Calidad es Mantis Bug Tracker36

(Para más información, consultar sección 3.Herramientas CASE). Mantis es una herramienta que permite

llevar un control y seguimiento compartido entre OAC, DP y Desarrollo de las incidencias encontradas durante las pruebas estáticas. La OAC sube a la plataforma de Mantis las incidencias, organizadas por

códigos y denominadas según la gravedad, el documento o fichero al que hacen referencia y la versión del

entregable en el que se encuentran y/o corrigen. El equipo pertinente accede a Mantis, encuentra la incidencia que le afecta, y la corrige, notificando a la OAC de la corrección realizada y enviándole de

nuevo el documento o fichero.

En la sección 2.6.2 Incidencias, se describe detalladamente cada uno de los indicadores de calidad que la

OAC tendrá que comprobar que se cumplen en los documentos realizados, así como los ficheros codificados, con su correspondiente incidencia y grado de gravedad.

2.6.1.2 Pruebas Dinámicas37

Las pruebas dinámicas son aquellas en las cuales es necesario ejecutar la aplicación. Podemos dividir las

pruebas dinámicas en 2 grandes grupos según el aspecto que verifican:

Pruebas funcionales: Son las pruebas que comprueban que se cumplan los requisitos funcionales

definidos en la fase ASI en la aplicación. Es decir, se comprobará que todas las funcionalidades

de la aplicación exigidas en el DDR están presentes en la aplicación, y todos los casos de uso definidos en las fases anteriores existen y se corroboran.

Pruebas no funcionales: Son las pruebas que comprueban que se cumplan los requisitos no

funcionales definidos en la fase ASI en la aplicación. Existirá un tipo de prueba por cada tipo de

requisito no funcional definido, de manera que las pruebas de seguridad comprobarán que se cumplen los requisitos de seguridad, las pruebas de usabilidad comprobarán que se cumplen los

requisitos de usabilidad, etc.

Como resultado de las pruebas dinámicas, la OAC elaborará un informe que describiremos en detalle en la sección 2.6.4 Informes de Calidad. Todas las pruebas las realizará la OAC exceptuando las de

Aceptación (Alfa y Beta), que serán ejecutadas por el RAU o los usuarios finales, y las unitarias, que

serán ejecutadas por Desarrollo en paralelo a la codificación.

36 Web de la herramienta Mantis Bug Tracker: https://www.mantisbt.org/ 37 Basado en la información dada por MÉTRICA v.3, modelo SAC, ‘SAC002I_GCP-GESTIÓN DE LA CALIDAD_0200’

https://www.mantisbt.org/

47


Algunas herramientas software útiles para la realización de las pruebas dinámicas usadas en mi empresa son: SoapUI, WinSCP, TOAD y Notepad++ para la edición de texto.

38 (Para más información, consultar

sección 3.Herramientas CASE).

A continuación, describimos detalladamente todos los tipos de pruebas.

38 Web de las herramientas de testing,

SoapUI: https://www.soapui.org/

WinSCP: https://winscp.net/eng/index.php TOAD: https://www.toadworld.com/downloads

Notepadd++: https://notepad-plus-plus.org/

https://www.soapui.org/

https://winscp.net/eng/index.php

https://www.toadworld.com/downloads

https://notepad-plus-plus.org/


48

48

Tabla 17. Tipos de Pruebas39

TIPOS DE PRUEBAS

TIPO NOMBRE

REQUISITOS

QUE

PRUEBAN

DESCRIPCIÓN

FUNCIONAL

DE UNIDAD CU

Se encargan de probar los módulos de código por

separado (en el caso de java, probar las distintas clases

individualmente), garantizando el correcto

funcionamiento de cada uno sin integrarse con el resto.

DE INTEGRACIÓN CU

Prueban los diferentes módulos de la aplicación

integrados. La necesidad de realizar las pruebas de

integración viene dada por el hecho de que los módulos

que forman un programa suelen fallar cuando trabajan

de forma conjunta, aunque previamente se haya

demostrado que funcionan correctamente

individualmente en las pruebas de unidad.

DE SISTEMA

TODO TIPO

DE

REQUISITOS

Las pruebas de sistema son aquellas que prueban el

sistema por completo como un todo, ya sea a nivel de

funcionalidades y de que se cumplan los casos de uso,

como a nivel técnico y que se cumplan todos los requisitos no funcionales.

*Gran parte de las pruebas no funcionales se realizan

como parte de las pruebas de sistema.

DE REGRESIÓN CU

Se trata de pruebas que se repiten al introducir alguna

actualización o cambio al software. Una mala gestión

del control de versiones, puede llevar a que la

modificación de un aspecto de la aplicación pueda

provocar fallos en partes donde antes no los había. El

objetivo de estas pruebas es volver a probar aspectos

que ya se habían probado anteriormente para descubrir

posibles fallos al introducir modificaciones.

DE HUMO CU

Pruebas rápidas y sencillas a nivel superficial que se

encargan de localizar las incidencias que afectan de

manera más directa al correcto funcionamiento de la aplicación y/o que impiden la correcta realización de

otras pruebas.

DE ACEPTACIÓN (ALFA)

CU

Primera fase de las pruebas de usuario, se trata de

pruebas que el usuario realiza en el entorno de

certificación mientras se realizan el resto de pruebas,

en caso de que el usuario detecte elementos que

necesita que se cambien a un nivel temprano de la fase

de pruebas y se pueda corregir pronto antes de seguir.

DE ACEPTACIÓN (BETA)

CU

Segunda fase de las pruebas de usuario, en la cual los

usuarios finales prueban la aplicación en el entorno de

Cliente, en un escenario más real y fiel al uso que se va

a hacer del software.

39 Información contrastada entre nuestra experiencia en everis, normativas ISO, IEEE y BSI anteriormente comentadas, apuntes de

Ingeniería de Software y enlaces a Wikipedia y MADEJA, Junta de Andalucía.

49


DE DESPLIEGUE RE Y RF

Comprueban que el software implantado en un

determinado entorno funciona correctamente a nivel de

ambiente operativo.

NO FUNCIONAL

DE SEGURIDAD RS

Verifican que las medidas de seguridad implantadas en el software funcionan frente a ataques reales,

sometiendo a la aplicación a diferentes amenazas

controladas.

DE MANTENIBILIDAD

RM

Verifican que la aplicación se pueda actualizar de

manera sencilla cuando surja la necesidad de realizar

cambios en ella, se necesiten añadir funcionalidades

surgidas de nuevas necesidades del Cliente o modificar

aspectos en el futuro en nuevas entregas.

DE INTERFAZ RI

Verifican que la comunicación con sistemas externos

sea adecuada y sin errores (diferenciando bien los

factores que afectan a nuestra aplicación y no los de las

aplicaciones terceras con las que necesite

comunicarse).

DE USABILIDAD RU

Verifican que las necesidades de accesibilidad,

facilidad de uso de la aplicación y la interacción

software-cliente sean óptimas y se ajusten a las definidas en los Requisitos de Usabilidad.

DE ESFUERZO O ESTRÉS

RR

Pruebas que fuerzan el sistema al máximo de sus

capacidades software y hardware, para comprobar si la

respuesta esperada es la correcta o descubrir posibles

situaciones que causen estabilidad que no se hubieran

descubierto de otro modo.

DE RENDIMIENTO

Pruebas que verifican que el sistema tiene un tiempo de

respuesta y consumo de recursos óptimos, probando

con todas las combinaciones posibles asegurando el

nivel de servicio esperado.

DE FIABILIDAD

RFI

Verifican la tolerancia a fallos del software y su

correcto comportamiento ante diferentes situaciones,

esperado según las necesidades descritas en los

Requisitos de Fiabilidad.

DE

RECUPERACIÓN

Provoca el fallo del sistema de todas las maneras

posibles, para garantizar que la recuperación de la

aplicación se corresponde con lo definido en los Requisitos de Fiabilidad.


50

50

2.6.2 Incidencias

Un elemento clave de la certificación de Calidad es la detección de incidencias. Esta parte se corresponde

con la ejecución de las Pruebas Estáticas, ya que se resumen en la corrección formal de documentos y ficheros de código, como explicaremos más adelante. Dichas incidencias pueden clasificarse

resumidamente según su gravedad:

Tabla 18. Tipos de Incidencias según su gravedad

TIPOS DE INCIDENCIAS SEGÚN LA GRAVEDAD

BAJA MEDIA ALTA

Incidencias ligeras, que no cumplen

algún parámetro de calidad menor.

Pueden admitirse sin afectar a la

correcta funcionalidad de la

aplicación o la comprensión de los

documentos.

Suelen consistir en no respetar el

formato de los documentos, líneas

confusas en el código o comportamientos inesperados, pero

sin importancia, en la aplicación.

Incidencias que dificultan la

correcta funcionalidad de la

entrega. Un entregable con 3 (u otra

cifra convenida por la OAC) o

menos incidencias medias puede

superar satisfactoriamente las

revisiones técnicas de la OAC.

Suelen consistir en warnings en la

compilación, o pequeña alteración de algún RF, faltas de secciones en

los documentos, etc

Incidencias que impiden el

correcto funcionamiento de la

entrega, y necesitan ser

obligatoriamente corregidas.

Suelen ser fallos de código, el no

cumplimiento de algún RF,

documentos erróneos o vacíos, y

fallos en la aplicación

Las referencias de esta sección de incidencias pertenecen en su mayoría a MÉTRICA v.3.40

Estas incidencias quedarán registradas en una plataforma compartida entre los diferentes equipos y

Calidad, a la que todos tendrán acceso para solventarlas de la manera más eficiente. Habrá ocasiones en las cuales dichas incidencias tengan que ser solucionadas por Diseño, Desarrollo, DP, despliegue o

incluso por Cliente.

A continuación veremos los patrones de Calidad que tienen que cumplir los documentos y los entregables uno por uno, prestando especial atención a las incidencias altas.

40 MÉTRICA v.3, modelo SAC, Normativa Técnica, Indicadores de Certificación.

51


2.6.2.1 Documentos

2.6.2.1.1 DDR

Tabla 19. Certificación DDR

CERTIFICACIÓN DDR

SECCIÓN

DEL

DOCUMENTO

INDICADOR DE CALIDAD GRAVEDAD

2.1 Objetivos El objetivo del sistema describe el alcance o propósito del mismo (qué es

y para qué sirve), aunque sin llegar a detallar sus funciones generales. ALTA

2.2 Características

Principales

La descripción de funciones generales del sistema es completa, se cubren

todas las necesidades del cliente que hayan sido identificadas. ALTA

Se describe la funcionalidad del Sistema sin entrar en detalles de bajo

nivel ALTA

La descripción de funcionalidad debe cubrir las necesidades y

expectativas de los usuarios finales. ALTA

Si se incluye la descripción global de la arquitectura, se justifican las

razones para su selección ALTA

La descripción de funcionalidad general o descripción global de la arquitectura identifica las relaciones del sistema con otros sistemas.

ALTA

2.3 Restricciones Generales

Si existen restricciones, suposiciones o dependencias importantes que puedan condicionar las soluciones de diseño del sistema están incluidas.

ALTA

3. Requisitos del

Sistema

La descripción de los requisitos no es ambigua. ALTA

Todos los requisitos están codificados según un mismo estándar de

nomenclatura ALTA

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

requisitos están claramente identificadas. BAJA

Dentro del apartado 'Requisitos de Seguridad' debe indicarse si la

aplicación debe estar sujeta a la LOPD (Ley Orgánica de Protección de

Datos) o LSSI (Ley de Servicios de la Sociedad de la Información).

ALTA

En los requisitos (preferentemente en RE o RI) deben quedar claramente

descritos todos los sistemas con los que la aplicación se relaciona y en

qué forma.

ALTA

Los requisitos funcionales no hacen referencia a cuestiones técnicas de

diseño, salvo que realmente se consideren como condicionantes. BAJA

Los requisitos se encuentra correctamente codificados y clasificados

según su categoría ALTA

No hay dos requisitos distintos con un mismo código. ALTA

Se describen los niveles de seguridad que deben aplicarse al sistema. BAJA


52

52

4. Matrices de

Trazabilidad

Se ha representado la matriz de trazabilidad incluyendo todos los

requisitos descritos en el documento. ALTA

Al menos el 90% de los requisitos pueden ser validados. ALTA

Se indican claramente aquellos requisitos de igual o distinta categoría

que estén relacionados entre sí (p.e.: un requisito operativo que afecta a

varios requisitos funcionales).

ALTA

2.6.2.1.2 DAO

Tabla 20. Certificación DAO

CERTIFICACIÓN DAO

SECCIÓN

DEL

DOCUMENTO


2.1 Elementos de la infraestructura

Se describen los elementos de la infraestructura del sistema relativos al

hardware, software y comunicaciones necesarios para explotar el

sistema

MEDIA

Se detallan las medidas de seguridad MEDIA

2.2 Restricciones

Técnicas

Si aplica, se describen las restricciones técnicas en base a la

infraestructura tecnológica del sistema MEDIA

2.3 Planificación

de Capacidades

Se describen la planificación de capacidad necesaria para

almacenamiento, procesamiento y comunicaciones. MEDIA

3.1 Niveles de

Arquitectura

En el caso de que se haya dividido el sistema, se han identificado

claramente las diferentes partes del mismo, presentando un diagrama y

detallando las interfaces que les afectan.

ALTA

En el caso de que se haya dividido el sistema, se han identificado los

objetos comunes. MEDIA

En el caso de que se haya dividido el sistema, las representaciones

gráficas de las partes del mismo siguen todas un mismo formato. MEDIA

En el caso de que se haya dividido el sistema, cada parte del sistema se

ha identificado debidamente. MEDIA

3.2 Casos de Uso Se describen los casos de uso en base a los requisitos establecidos por el

usuario. MEDIA

3.3 Clases

El diseño esta realizado en coherencia con la información del sistema concebido en la fase de Análisis.

ALTA

Los gráficos del Diagrama de Clases contienen un conjunto de gráficos encadenados que recogen las relaciones de diseño entre las clases del

sistema.

MEDIA

El diseño de Clases incluye interfaces de comunicación con los sistemas

externos al sistema en estudio. MEDIA

53


El diagrama de clases refleja la relación con la Base de Datos y la

interfaz gráfica. MEDIA

Se han identificado los componentes ya existentes y reutilizables. BAJA

Se ha documentado detalladamente cada una de las Clases indicando la

descripción de la clase, su tipo, herencia e información relevante sobre

ella (interfaz, componente reutilizado, etc.)

ALTA

Para cada clase se ha documentado detalladamente sus atributos más significativos indicando su descripción, tipo y restricciones.

MEDIA

Para cada clase se ha documentado detalladamente cada uno de sus métodos indicando su descripción, tipo, restricciones, visibilidad y

lógica.

MEDIA

Se definen las interfaces con otros sistemas y entre los subsistemas de

la aplicación. ALTA

4.1 Interfaz de Usuario

Cada caso de uso se presenta con un gráfico de navegación de las

interfaces gráficas de usuario, conectadas por flujos de navegación, un

inventario de los objetos que contiene el diagrama y una descripción de

la navegación.

MEDIA

Para cada una de las interfaces gráficas de usuario representadas, se

muestra su diseño mediante un prototipo de interfaz de pantalla gráfica.

Se incluirán informes, mensajes de error y otro tipo de información

relevante.

MEDIA

Se presenta un catálogo de controles y elementos de diseño de la interfaz

del sistema, donde se recoge la operatividad de la misma. BAJA

Cuando proceda, por cada informe definido, se presenta el formato de

impresión, conteniendo el tipo y tamaño de letra a utilizar y tipos de

impresora a usar.

BAJA

4.2 Interfaz con

otros Sistemas

Se detallará la interfaces con otros sistemas, indicando los datos y el

formatos de los mismos que se van a transferir entre los sistemas. MEDIA

5. Modelo Físico

de Datos

Si se representa, el modelo Físico deberá coincidir con la descripción de

sus elementos. (Los elementos pueden haberse descrito a continuación o ser adjuntados en un archivo).

MEDIA

2.6.2.1.3 MIC

Tabla 21. Certificación MIC

CERTIFICACIÓN MIC

SECCIÓN

DEL

DOCUMENTO


1. Descripción del

cambio/problema

Se ha introducido una descripción de alto nivel de los

problemas/cambios junto con la solución adoptada. MEDIA


54

54

2. Recursos

Extraordinarios

Si existen recursos extraordinarios para la instalación de la entrega, éstos

se han especificado de forma clara y concisa. ALTA

3.1 Requisitos Previos

Si es necesario coordinar la instalación de la entrega con alguna otra,

ésta se ha identificado de forma clara y concisa. ALTA

Se indica si es necesario desconectar a los usuarios para realizar la

instalación. ALTA

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

ALTA

Se indica si es necesario realizar un backup del software de la aplicación previo al proceso de instalación.

ALTA

Si es necesario salvaguardar datos de la configuración actual de la

aplicación para utilizarlos posteriormente en el proceso de instalación,

éstos han sido especificados de forma clara y concisa.

ALTA

3.2 Procedimiento

de Instalación

Los pasos del procedimiento de instalación se identifican mediante un

secuencial único y la tabla está ordenada por dicho campo. ALTA

El tipo de tarea se ha especificado correctamente. MEDIA

La descripción de las tareas a realizar es clara y concisa, sin presuponer

conocimientos previos de la aplicación por parte del técnico que realiza

la instalación.

ALTA

4. Marcha Atrás

Si es necesario eliminar sinónimos públicos para realizar la marcha atrás,

se han indicado sus identificadores de forma correcta. ALTA

Si es necesario eliminar roles para realizar la marcha atrás, se han

indicado sus identificadores de forma correcta. ALTA

Se indica si es necesario restaurar el esquema de base de datos para

realizar la marcha atrás. ALTA

Se indica si es necesario restaurar el software anterior para realizar la

marcha atrás. ALTA

Los scripts a ejecutar para la marcha atrás se han incrustado en el

apartado correspondiente. ALTA

Los pasos de la marcha atrás se encuentran numerados secuencialmente ALTA

Los pasos de la marcha atrás se han especificado de forma clara. ALTA

2.6.2.1.4 MUS

Tabla 22. Certificación MUS

CERTIFICACIÓN MUS

SECCIÓN DEL

DOCUMENTO INDICADOR DE CALIDAD GRAVEDAD

1.1 Objeto Proporciona información suficiente para que el lector pueda BAJA

55


comprender la función global del sistema dentro de la organización.

1.3 Funcionalidad

En caso de que la aplicación sustituya otros procesos existentes en la

organización, proporciona información suficiente para que el lector

pueda comprender los procesos sustituidos y las diferencias funcionales del nuevo sistema.

MEDIA

Se describen todas las funcionalidades aportadas por el sistema y los procesos involucrados en ella.

ALTA

1.4 Mapa del

Sistema

Se proporciona un resumen general mediante diagramas de formato libre

de la composición del sistema, módulos, entorno, etc que permite al

usuario tener un conocimiento a alto nivel del sistema descrito.

MEDIA

2. Operativa del

Sistema

Se describen todos los procesos (o ventanas) incidiendo en su

descripción y qué acciones permite el sistema realizar con el proceso (o

ventana) descrito.

MEDIA

3.3 Incidencias

Frecuentes

Se enumeran las incidencias más frecuentes y, junto a cada una de ellas,

se ofrece una solución. BAJA

3.4 Mensajes de

Error

Se ofrece una lista con todos los mensajes de error que el sistema ofrece

al usuario, bien sea a través de ventanas o de ficheros de log, y se adjunta

una descripción más extensa para cada uno de ellos.

MEDIA

General El manual está escrito de forma clara y comprensible ALTA

2.6.2.1.5 PP

Tabla 23. Certificación PP

CERTIFICACIÓN PP

SECCIÓN

DEL

DOCUMENTO


1. Descripción

General

Se ha realizado una descripción de la funcionalidad completa del sistema, así

del correctivo y/o evolutivo que incluya la entrega ALTA

Se han descrito y codificado claramente los casos de pruebas a ejecutar,

distinguiendo si se corresponden con un correctivo o evolutivo. ALTA

Se han identificado los requisitos asociados a los casos de pruebas.

(Obligatorio en evolutivos y mantenimientos) ALTA

2. Entorno de

Pruebas

Se ha identificado claramente el entorno de prueba necesario, completando

todos los apartados de la plantilla. (Si alguno no aplica, indicar N/A y

explicar la razón)

ALTA

3. Casos

Generales

Se incluyen aquellos casos de prueba que no se corresponden con el objetivo

de la entrega, pero sirven para fijar prerrequisitos u otros. ALTA

Se describe la creación de los usuarios que serán necesarios en los casos de

prueba del documento. ALTA


56

56

4. Casos de Prueba

La información de cada caso de prueba especifica con claridad todos los

aspectos necesarios para su realización. ALTA

Se incluye una descripción del caso de prueba. ALTA

Se incluyen los prerrequisitos necesarios para realizar cada caso de prueba. ALTA

Se describen los roles necesarios para ejecutar cada caso de prueba. ALTA

Se incluyen los datos de pruebas necesarios para ejecutar las pruebas ALTA

Si la prueba incluye algún elemento especial, se debe especificar. ALTA

Se indica el tiempo necesario para ejecutar la totalidad del caso de prueba.

(Expresado en minutos) MEDIA

Para cada caso de prueba que se divida en ciclos de prueba, se explicará cada

uno de los ciclos de prueba de forma ordenada por separado. ALTA

Se indica el requisito (o requisitos) que se testea en cada caso de pruebas. Se

debe corresponder con los requisitos del DDR indicados en el apartado de

descripción general.

ALTA

Para cada caso de pruebas se debe especificar el orden de ejecución. Si el

orden es correlativo, se debe indicar como 'Secuencial'. ALTA

2.6.2.1.6 Defectos gene ricos en documentos

Tabla 24. Defectos genéricos en documentos

CERTIFICACIÓN DE LOS DOCUMENTOS EN GENERAL

SECCIÓN

DEL

DOCUMENTO


N/A

Ha de comprobarse la coherencia del nombre identificativo del entregable. MEDIA

Ha de comprobarse la coherencia del versionado del entregable. MEDIA

Se han de cumplimentar correctamente todos los campos de la Hoja de

Control. MEDIA

El entregable debe adaptarse a la plantilla definida para el resto de

documentos MEDIA

57


Se han de respetar todos los estilos definidos en el documento, utilizándolos

en los casos en que sea necesario y sin modificar el formato de los mismos.

En los documentos que se necesite un formato específico se indicará explícitamente.

BAJA

No se deben de realizar modificaciones en el formato del texto, a excepción

de la utilización de negrita y cursiva cuando se desee resaltar alguna palabra

o frase.

BAJA

Cuando un documento anexe información adicional (por ejemplo, el modelo

del análisis realizado con una herramienta CASE), la entrega del documento

ser realizará en un fichero comprimido ZIP que contendrá el documento y el

resto de ficheros organizados en subdirectorios.

BAJA

El índice del documento se encuentra correcto y actualizado en cuanto a

números de páginas. BAJA

Existen descripciones de las convenciones notacionales o acrónimos

empleados. BAJA

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

mismo debe indicarse correctamente en el apartado de Referencias. BAJA

Cuando un documento no se refiera a la totalidad del sistema, en la

introducción deberá aclararse a qué parte del sistema afecta. BAJA


58

58

2.6.2.2 Ficheros de código

2.6.2.2.1 SCR de base de datos

(Nos centraremos en los SCR de base de datos, ya que la revisión técnica del resto de SCR se realizará en las

pruebas de despliegue, sistema, o cuando corresponda).

Tabla 25. Certificación SCR de base de datos

CERTIFICACIÓN SCR DE BASE DE DATOS


Los nombres de los scripts deben respetar el formato <nnn>_<nombre>.<ext>, tal como se define

en la normativa técnica correspondiente. Siempre, aunque sea un solo Script. ALTA

Las sentencias para la creación de sinónimos públicos, los cuales permiten el acceso a un objeto

por parte de cualquier usuario (siempre que se tengan los permisos necesarios) se entregan dentro

de archivos con extensión ".syn".

ALTA

Los sinónimos públicos se crean mediante la orden "CREATE" y nunca con "CREATE OR

REPLACE". ALTA

No se permite la concesión del permiso GRANT CREATE SESSION en los scripts, sino que debe

estar convenientemente documentado en el Manual de Instalación y Configuración. ALTA

Ningún script que forme parte de una entrega llama o ejecuta otro script SQL almacenado en

archivo. ALTA

Los scripts entregados deben ejecutarse correctamente en entornos UNIX desde línea de comando

mediante SQLPLUS. ALTA

No se permite la petición de parámetros durante la ejecución de los scripts de base de datos. ALTA

Se deben generar los mensajes informativos mediante la utilización de PROMPT o

dbms_output.put_llne suficientes en la salida estándar durante la ejecución de los scripts, que

indiquen qué operación se va a realizar a continuación, conforme a lo descrito en la normativa

técnica.

MEDIA

Se debe utilizar de forma adecuada el valor del parámetro INITIAL en la creación de las tablas e índices, para aquellas entidades sobre las que se conozca su tamaño inicial aproximado,

especialmente cuando existe un proceso de migración que cargará los datos.

ALTA

En las cargas y migraciones masivas de datos, deben desactivarse previamente los índices sobre las

tablas en las que se van a introducir los datos. ALTA

En las cargas y migraciones masivas de datos, se introducen los COMMIT necesarios para no

generar transacciones anormalmente grandes que sobrecarguen el segmento de ROLLBACK de la

base de datos.

ALTA

Las sentencias para la eliminación de sinónimos públicos se entregan únicamente dentro del MIC ALTA

59


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 ningún tipo de configuración para su instalación

ALTA

La integración entre varias aplicaciones web ha de implementarse mediante servicios web. MEDIA

Se recomienda el uso de Hibernate para la conexión a BBDD o en su defecto cap.webcap.sql.ConnectionFactory

BAJA

La información interna de la aplicación, como los datos que maneja, usuarios, etc, se almacena en BBDD y no en ficheros

ALTA

Las conexiones realizadas a BBDD deben cerrarse

automaticamente apenas dejen de usarse. No se pueden quedar conexiones abiertas. ALTA

No se admite el uso de Applet MEDIA

Como criterio de diseño se recomienda utilizar interfaces en vez de clases BAJA

Evitar definir funciones JavaScript en una página web. MEDIA

Evitar JSP que usen directamente tablas de BBDD ALTA

Evitar JSP que usen directamente procedimientos o funciones de BBDD.

ALTA

Evitar el uso de paquetes no estándares de Java (sun.*) BAJA

En el mismo paquete solo se puede heredar de clases de nivel superior BAJA

Las SuperClases no deben conocer nada de las SubClases. MEDIA

Los paquetes no deben presentar un exceso o defecto de clases/interfaces BAJA

Evitar clases que implementan demasiadas interfaces. BAJA

Evitar sobreescribir métodos estáticos. BAJA

Evitar sobreescribir atributos. BAJA

Evitar clases que directamente heredan de java.lang.throwable. BAJA

Proporcionar accesos para los campos privados de la clase. BAJA

Evitar clases que hacen referencia a objetos de la BBDD. MEDIA


60

60

Una clase no debe tener atributos públicos a menos que sean declarados como final o static final. BAJA

Empaquetado de ficheros Java: Todos los componentes Java que contiene una aplicación se deben

empaquetar por aplicación utilizando la directiva package MEDIA

La funcionalidad de las JSPs utilizada sólo incluirá la capa de presentación de la aplicación MEDIA

No se debe utilizar el código JavaScript para realizar tareas de presentación, sino únicamente como

mecanismo de validación de datos (fechas, tipos de datos, etc.). MEDIA

La aplicación consta de 2 usuarios a nivel de BBDD, uno es el propietario del esquema y el otro es

el usuario que se utiliza para acceder. ALTA

Encapsular la seguridad en una sola clase Java BAJA

No confiar las medidas de seguridad en código ejecutado en cliente (JavaScript, VBScript) ALTA

No utilizar los campos ocultos de un HTML para programar criterios de seguridad MEDIA

No utilizar el metodo GET para enviar información sensible como por ejemplo contraseñas, utilizar

el método POST MEDIA

Convertir todas las salidas generadas según la codificación HTML apropiada:

- > en >

- < en < - etc.

MEDIA

Mantener actualizados los servidores web y programas relacionados (PHP, librerías gráficas, etc.) MEDIA

No habilitar servicios innecesarios MEDIA

Minimizar los datos almacenados en cada sesión MEDIA

Los usuarios de BD de la aplicación deben tener los permisos necesarios ALTA

Mostrar al usuario información utíl en los mensajes de error, no mostrando información innecesaria MEDIA

Se debe registrar de forma interna los errores producidos para detectar posibles ataques BAJA

No proporcionar acceso total a todo el directorio de publicación web. MEDIA

No permitir objetos con alto Fan-In.(Objetos java que referencian a más de 5 parámetros) MEDIA

No permitir clases con una gran falta de cohesión MEDIA

No permitir objetos con alto Fan-Out.(Objetos Java que son referenciados por más de 5

parámetros) MEDIA

No permitir un alto acoplamiento entre clases MEDIA

Evitar demasiada respuesta para una clase MEDIA

Evitar objetos con una alta complejidad de integración MEDIA

Evitar clases con una alta carencia de cohesión 2 MEDIA

Evitar clases con un alto número de hijas MEDIA

61


Evitar clases un alto Ratio de Public Data MEDIA

El software debe contener únicamente las librerías propias de la aplicación, excluyendo las librerías

de JAVA y del intérprete de compilación. ALTA

No deben existir clases duplicadas en el CLASSPATH MEDIA

La configuración de carga de clases en el servidor debe estar definida en un archivo y su

comportamiento debe estar documentado. ALTA

No se utilizarán procedimientos almacenados java en Oracle ALTA

2.6.2.2.3 Defectos gene ricos en co digo

Tabla 27. Defectos genéricos en código

CERTIFICACIÓN DEL CÓDIGO EN GENERAL


La función que llama a un Form debe estar centralizada. BAJA

Evitar las Querys en las que participan demasiadas tablas. MEDIA

Evitar tener Joins con demasiadas tablas MEDIA

Evitar tener código PL/Sql en los triggers llamados "pre-record". MEDIA

Evitar los triggers de ratón, timer. Las validaciones en Forms debe realizarse a nivel de bloque de

datos. MEDIA

El uso conjunto de Distinct y Group by es redundante. MEDIA

Evitar el Uso de Rownum para limitar el número de registro en la consulta

o cursores. MEDIA

Recorrer colecciones utilizando FIRST, LAST, NEXT MEDIA

Evitar el uso de NULL o NOT NULL en las condiciones de las consultas ya que desactivan los

índices y hacen más lenta la consulta. MEDIA

No utilizar funciones sobre las columnas indexadas, ya que inhabilita el indice. MEDIA

Uso de Exist e IN de forma eficiente. MEDIA


62

62

No se permite el uso de funciones de agrupación: MAX, MIN, COUNT, SUM BAJA

La funcionalidad de los FORMS debería estár en el servidor para la mejora del rendimiento

(Paquetes, Procedimientos, etc.). Al ejecutar las funciones el servidor, la aplicación es más

eficiente.

MEDIA

Evitar el uso de GOTO en Pl/Sql. ALTA

Los Triggers no deben acceder a tablas directamente,

solo a través de procedimiento. MEDIA

Los Triggers no deben modificar los datos de una tabla. MEDIA

Para realizar la conexión a la BBDD de la aplicación no debe existir un único usuario. MEDIA

La aplicación debe gestionar los roles de usuarios. MEDIA

Todos los sinónimos de BBDD deben ser públicos MEDIA

No asignar a los usuarios más permisos de los necesarios. ALTA

Mostrar al usuario información útil en los mensajes de error, no mostrando información innecesaria BAJA

Registrar de forma interna los errores producidos para detectar posibles ataques BAJA

El almacenamiento de la seguridad se debe cifrar mediante algoritmos hash BAJA

Cambiar contraseña cada cierto tiempo. Para realizar el cambio de contraseña debe solicitar la que

está vigente MEDIA

Se debe requerir autentificación entre componentes. MEDIA

No definir los usuarios y contraseñas por defecto MEDIA

Encapsular la seguridad en un solo paquete o procedimiento pl-sql. BAJA

Evitar usar más de una instrucción por línea. BAJA

Las funciones no deben tener demasiadas líneas de código. BAJA

63


La cláusula WHEN OTHERS debe estar presente en las excepciones. ALTA

Evitar tener demasiadas columnas por tabla. MEDIA

Usar el tipo VACHAR2 en vez de Char o Varchar, siempre que no conozcamos la longitud exacta

del char BAJA

Evitar usar EXECUTE. MEDIA

Evitar usar columnas del tipo LONG o LONG RAW. MEDIA

Evitar usar Funciones que no sean referenciadas. ALTA

Evitar las tablas que no son referenciadas. ALTA

Utilizar %TYPE o %ROWTYPE para definir variables asociadas a

columnas de tablas. MEDIA

Utilizar ELSIF o CASE en vez de varios IF anidados BAJA

Evitar uso de EXIT y RETURN en bucles MEDIA

No utilizar Select * MEDIA

No declarar el índice en bucle FOR BAJA

Utilización de la función NVL siempre que sea posible para evitar futuros errores en las querys MEDIA

Evitar objetos con alta complejidad cyclomática BAJA

Evitar objetos con alta complejidad esencial BAJA

Evitar objetos con alta profundidad en el código BAJA

Evitar objetos con demasiados parámetros BAJA

Evitar objetos con líneas que tengan demasiados caracteres BAJA


64

64

2.6.3 Informes de Revisión Técnica (IRT)

A la hora de realizar las revisiones técnicas a los entregables y detectar incidencias, antes de describirlas

en una plataforma compartida (como por ejemplo QM, como veremos más adelante en la sección 3.Herramientas CASE), para hacerle llegar la información a los equipos, será necesario que la OAC

elabore unos documentos denominados Informes de Revisión Técnica (IRT).41

Estos informes tienen como objetivo mostrar las incidencias a corregir de un documento o fichero de una forma ordenada, clara y comprensible. De este modo, cuando la OAC anexe los IRT a la plataforma

compartida de incidencias, el equipo responsable tan solo tendrá que leer dichos informes para localizar

rápidamente las incidencias, y optimizar el proceso de corrección del entregable en cuestión.

Todos y cada uno de los documentos y ficheros de código sometidos a inspección de calidad serán acompañados de su correspondiente IRT. En los IRT, además, se indicará el estado del entregable según el

número y gravedad de las incidencias encontradas, lo cual explicaremos en la siguiente tabla:

Tabla 28. Resultado de evaluación de un entregable

RESULTADO DE LA EVALUACIÓN DE UN ENTREGABLE

SEVERIDAD CANTIDAD RESULTADO DESCRIPCIÓN

Baja 0 - ∞

ACEPTADO

Por muchas incidencias bajas que

se encuentren, el entregable se

considera válido a todos los

efectos.

Se recomienda corregir las

incidencias bajas para optimizar

el resultado final del entregable

Media 0 - 3

Media 3 - ∞ ACEPTADO CON

RESERVAS

Si hay 3 o más incidencias

medias, el entregable se considera

válido.

Sin embargo, la no corrección de

dichas incidencias puede conducir a confusión en el cliente, o a

problemas futuros de categoría

menor.

Alta 1 - ∞ RECHAZADO

Si hay una sola incidencia alta, el

entregable no se considera válido,

y tendrá que ser modificado, y

reentregado de nuevo a la OAC.

41 Bas{ndonos en MÉTRICA v.3, modelo SAC, ‘SAC002P_RDP_Revisión de Documentos_0800’

65


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


66

66

2.6.4 Informes de Calidad

Tras revisar todos los entregables, detectar sus incidencias y elaborar sus respectivos IRT, y ejecutar todas

las pruebas, la OAC deberá realizar varios informes, los cuales se añadirán a los entregables finales para el Cliente. Estos informes tienen como objetivo resumir cómo han ido las pruebas, las incidencias que se

han encontrado tanto en SCR como en SFW, y que se pueda tener un resumen rápido de la evaluación de

los ficheros de código. Se entregarán al Equipo de Desarrollo para que corrijan los posibles errores que hayan podido aparecer durante la ejecución de las pruebas dinámicas o estáticas, y envién una nueva

versión a la OAC con las correcciones y pueda probar de nuevo.

Estos informes también pueden resultar de utilidad al Cliente, bien por su posible interés en las pruebas

llevadas a cabo, o curiosidad por la detección de incidencias en una primera instancia por parte de la OAC (Un gran número de incidencias en la primera entrega puede decir mucho del equipo responsable).

A continuación, explicaremos los distintos informes que elaborará la OAC:

2.6.4.1 Informe de Modelo de Datos (MOD)

El MOD es un Informe que se realiza exclusivamente para los SCR. Si una entrega no tiene scripts, la

OAC no realizará este informe. Su objetivo es asegurar que la base de datos cumple con las reglas

establecidas en la normativa técnica vigente. Dicho de otra manera, comprueba que los scripts ejecutados

de la aplicación sigan una serie de requisitos de calidad, orden, numeración, eficiencia, etc.

Para realizar el MOD, se hace uso de varias herramientas de comprobación y análisis de código sql,

lenguaje de programación en el que suelen ir codificados los scripts. Entre los parámetros fundamentales a evaluar, destacamos:

La existencia de objetos inválidos

La comparación entre esquemas de diferentes entornos

Detección de sinónimos inválidos

Cumplimiento de normas técnicas de codificación del script

Como dato extra, se suelen anexar al MOD los logs generados por las herramientas utilizadas, siendo así

de interés para el que reciba este informe y use dichas herramientas.

*Nota: El MOD formará parte del IPC, así que no va a consistir en un entregable final por sí mismo.

67


2.6.4.2 Informe de Pruebas Estáticas (PES)

El PES es un Informe que se realiza como resultado de las pruebas estáticas al software. Su objetivo es

comprobar que el SFW utilizado cumple con las normas de codificación pertinentes, y que se ha llevado a

cabo una programación ordenada, limpia y comprensible, con vistas a que el código sea revisado y reutilizado con facilidad.

Para elaborar el informe se hace uso de una herramienta llamada Jenkins42

. Jenkins revisa y prueba el

SFW de diversas maneras atendiendo a diferentes criterios, elaborando un informe final de SonarQube. SonarQube es otra herramienta asociada que muestra el número de archivos corruptos e incidencias de

distinta categoría (para más información, consultar sección 3.Herramientas CASE). En el informe se

detallan con precisión todas las incidencias encontradas.

*Nota: El PES formará parte del IPC, así que no va a consistir en un entregable final por sí mismo.

42 Web de referencia de las herramientas software: Jenkins: https://jenkins.io/

SonarQube: https://www.sonarqube.org/

https://jenkins.io/

https://www.sonarqube.org/


68

68

2.6.4.3 Informe de Pruebas de Certificación (IPC)

El IPC es un informe extenso cuyo objetivo es recoger en un único documento todas las pruebas

dinámicas realizadas por parte de la OAC.

Detallamos a continuación la estructura básica del documento IPC:

Tabla 29. Estructura de un IPC

IPC (Informe de Pruebas de Certificación)


1. INFORMACIÓN

GENERAL

En esta sección se aportan datos generales de la certificación, como pueden

ser el nombre del proyecto, su anagrama, la versión, las fechas de entrega,

reclamación y verificación, y la persona responsable de la certificación.

2. CERTIFICACIÓN DE LA

APLICACIÓN

Apartado que resume las pruebas realizadas por la OAC para la entrega en

cuestión, y el resultado de cada una de ellas.

3. ENTORNO DE PRUEBAS

DE CERTIFICACIÓN

Se indica qué tecnología se ha usado para realizar las pruebas, las versiones

de software y las características principales de hardware, y otros aspectos

técnicos.

4. RESUMEN DE

ENTREGABLES Y

REVISIONES

Pequeña lista de entregables revisados por la OAC, y de entregables realizados por la OAC (se incluye el propio IPC). Se añade el estado de la

revisión y el resultado final de la misma, (si está aceptado, rechazado, o

aceptado con reservas).

5. Pruebas de Despliegue

Las pruebas de despliegue constatan si es posible realizar una instalación

correcta de la entrega a partir de los scripts, software y manual de instalación,

suministrados por la empresa. En definitiva, si se ha podido instalar la

aplicación en el entorno de certificación siguiendo el MIC sin problemas.

En este apartado se recoge el resultado de dichas pruebas, la fecha de

instalación y la persona responsable.

Se realizará una segunda fase de pruebas de despliegue cuando se implante la

aplicación en el entorno de Cliente.

6. Pruebas Funcionales

Esta sección recoge el resultado de la realización de las pruebas funcionales

definidas en los CP del PPF. Se añade de nuevo la fecha de finalización de las pruebas funcionales y la persona responsable.

Se verifica si se cumplen los RF. Se añade también el nombre del PPF

utilizado.

7. Modelo de Datos

Se incluye el MOD generado por la OAC y los logs generados por las

herramientas utilizadas. Se añade una breve enumeración de los objetos

inválidos encontrados y la comparación de los esquemas de desarrollo y de

certificación. Se añade la fecha de realización del MOD y la persona

responsable.

8. Pruebas Estáticas del

Software

Se incluye el PES generado por la OAC y el informe SonarQube generado

por la herramienta Jenkins. Se añade una breve enumeración de los archivos

con incidencias, y errores totales encontrados en los ficheros de código Java.

9. Pruebas de Unidad Esta sección recoge el resultado de la realización de las pruebas de unidad

definidas en en PPU.

69


10. Pruebas de Integración Esta sección recoge el resultado de la realización de las pruebas de

integración definidas en en PPI.

11. Pruebas de Sistema

Esta sección recoge el resultado de la realización de las pruebas de sistema definidas en en PPS.

Se realizará una segunda fase de pruebas de sistema cuando se implante la

aplicación en el entorno de Cliente.

12. Pruebas de Regresión Describe el resultado de las pruebas de regresión, en especial cuando el

software ya ha sido revisado una primera vez, y se vuelven a probar módulos

que estaban bien que ahora podrían fallar.

13. Pruebas de Humo

Describe el resultado de las pruebas de humo. Este apartado adquiere vital

importancia cuando ha habido fallos bloqueantes en alguna versión del

software entregado a la OAC, ya que en esos casos sólo se realiza un IRT y

no se realiza este IPC. Sin embargo, cuando se elabora el IPC tras la

corrección de los fallos bloqueantes, se enumeran aquí, así como el resultado

de las pruebas de humo ejecutadas para localizarlos.

14. Pruebas No Funcionales

Esta sección recoge el resultado de la realización de las pruebas no

funcionales definidas en el PPNF. Esto incluye el resultado de:

Pruebas de Seguridad

Pruebas de Mantenibilidad

Pruebas de Interfaz

Pruebas de Usabilidad

Pruebas de Esfuerzo / Estrés

Pruebas de Rendimiento

Pruebas de Fiabilidad

Pruebas de Recuperación

15. ANEXOS Se incluyen los anexos necesarios (si aplica) para la ejecución de las pruebas.

Si no es texto, deberá indicarse cómo se llaman los archivos anexos, y

deberán ir adjuntos al IPC comprimidos en un .zip .rar etc.

16. GLOSARIO Sección en la que se definen los anagramas usados y se explican los

acrónimos utilizados.

17. BIBLIOGRAFÍA Y

REFERENCIAS

Apartado en el que consta la información externa utilizada en las pruebas, o documentos de los que ha dependido parte de la certificación.

Este documento IPC43

se anexará a los informes generados (como el MOD y el PES) en un archivo

comprimido (zip, rar, etc), constituyendo un entregable completo para la entrega final realizado enteramente por la OAC. Cuando el equipo de Desarrollo lea este IPC, sabrá instantáneamente dónde se

encuentran las incidencias localizadas por la OAC referentes a todas las pruebas dinámicas. El IPC

también constituye un entregable para el Cliente.

43 Para la definición de la estructura del IPC nos hemos basado en la información aportada por MÉTRICA v.3, modelo SAC,

‘SAC007P_IPC_Informe_de_Pruebas_Certificación_0100’


70

70

2.6.4.4 Informe de Pruebas de Aceptación (IPA)

El IPA es un breve informe algo particular, que realiza la OAC después de las pruebas Alfa y Beta de

usuario. El usuario realizará las pruebas alfa y beta a la aplicación (detalladas más adelante) en el entorno

de certificación y en el de cliente. El resultado de estas pruebas se remitirá de nuevo a la OAC para que conste en el denominado IPA.

El IPA incluirá información de la persona responsable que ejecutó las pruebas de usuario, RAU, la fecha,

y el resultado final de las mismas. Este informe se anexará a la documentación pertinente generada por el usuario cliente, o la comunicación establecida entre usuario y OAC para apoyar los resultados de las

pruebas de usuario.

Habiendo realizado todos estos informes, se completa la lista final de entregables resumidos en la

siguiente tabla y clasificados según la fase a la que pertenecen:

Tabla 30. Lista final de entregables

ENTREGABLES

FASE ENTREGABLE CREADOR DESTINATARIO

ASI DDR DP Desarrollo,

OAC y Cliente

DSI

DAO Desarrollo (Diseño) Desarrollo (Codificación),

OAC y Cliente

PP Desarrollo OAC y Cliente

SCR Desarrollo

(Codificación) OAC y Cliente

CSI

MIC

Desarrollo OAC y Cliente

MUS

SFW Desarrollo

(Codificación) OAC y Cliente

CEI

IPC

OAC Desarrollo y Cliente

IPA

71


Según la norma UNE/ISO/IEC 90003:2005

44, una vez codificado el software y enviado a la OAC, la

OAC realizará todas las pruebas descritas en el PP (exceptuando las de aceptación y unitarias), y generará

el IPC. El IPC se enviará al equipo de Desarrollo y a DP, para que comprueben los errores que han tenido

lugar durante la realización de las pruebas o los aspectos que no se han cumplido, y puedan ponerle solución y mandarle una nueva versión de la aplicación corregida a la OAC.

*Nota: En el caso de que el resultado de las pruebas de humo realizadas por la OAC contenga un error

bloqueante que impida la correcta consecución del resto de pruebas, la OAC lo notificará al equipo de

Desarrollo para que lo corrija. En este caso no se esperará a generar el IPC, sino que se generará un solo IRT con el error localizado.

En el momento en que todas las pruebas del PP se ejecuten satisfactoriamente por la OAC, se dará por finalizadas las pruebas dinámicas por parte de la OAC.

Asimismo, en el momento en que todos los documentos y ficheros de código se encuentran correctos y

han superado satisfactoriamente las revisiones técnicas de la OAC, se dará por finalizadas las pruebas estáticas por parte de la OAC.

En este momento en el que las pruebas estáticas y dinámicas están superadas, el Cliente dispondrá de todo

lo necesario para probar por sí mismo el resultado final de la aplicación a nivel de usuario, dando paso a las

Pruebas de Aceptación.

44 Contrastando a su vez con’ METRICA_V3_Aseguramiento_de_la_Calidad ‘y MÉTRICA v.3, modelo SAC, ‘SAC002P_IAS_Implantacion

y Aceptacion de Sistemas_1300’


72

72

2.7 Pruebas de Usuario

Basándonos en la norma ISO/IEC/IEEE 29119 y UNE45

, tras las pruebas de certificación, el RAU debe validar que el software cumple los requisitos funcionales definidos al inicio del proyecto con el fin de

validar su correcto funcionamiento.

En este punto del proceso software, la OAC ya habrá realizado todas las pruebas a la aplicación, tanto dinámicas como estáticas. Ahora le llega el turno al usuario de realizar las pruebas de aceptación,

descritas en el PPA elaborado por la OAC en la fase de definición del proyecto.

Las pruebas de aceptación son aquellas que realizan los usuarios finales pertenecientes a la empresa Cliente, aquellos que utilizarán la aplicación en el entorno Cliente una vez implantada. Su propósito es

verificar los requisitos definidos en el DDR desde el punto de vista de Cliente en lugar de la OAC.

Las pruebas de aceptación se dividen en dos:

2.7.1 Pruebas Alfa

Las pruebas Alfa son aquellas que una representación del usuario final realiza en el entorno de certificación siguiendo el PPA. Durante su ejecución, al ser en el entorno de certificación, la OAC y parte

de otros equipos supervisa dicha ejecución, para recoger los problemas y errores de primera mano del

Cliente en caso de que los detecte.

Según MÉTRICA v.346

, el propósito de estas pruebas es comprobar que la aplicación resulta de agrado

para el usuario final, que cumple con todas las necesidades desde su punto de vista y tomar nota en el

momento de los cambios o modificaciones que el usuario vaya pidiendo durante la ejecución de las

pruebas.

2.7.2 Pruebas Beta

Las pruebas Beta son aquellas que una representación del usuario final realiza en el entorno de Cliente.

Para ello, será necesario que el equipo de despliegue implante la aplicación en el entorno de Cliente,

como se describe en la sección 2.8 Despliegue. Las pruebas Beta se realizan como última comprobación final del software, una vez que las pruebas Alfa han tenido éxito y se han corregido los fallos detectados

durante las misma, o actualizado el software según las necesidades encontradas.

Según MÉTRICA v.3, como en las pruebas Alfa ya el usuario ha probado y dado su punto de vista para introducir modificaciones y validar las funcionalidades, el propósito de las pruebas Beta es comprobar

que la aplicación funciona correctamente en el entorno de Cliente. El entorno de Cliente tiene el hardware

y software reales sobre los que se va a instalar la aplicación, y se deberán repetir las pruebas de sistema y

de despliegue para comprobar que el software funciona como un todo, ofreciendo los resultados funcionales y técnicos esperados.

Al tratarse de un entorno real, el software va a usar unas entradas reales, proporcionando salidas útiles

para el desempeño de los procesos de la empresa Cliente. Es aquí cuando el usuario final prueba finalmente la aplicación en el ambiente en el cual va a usarse en el futuro, dando lugar a una completa

fidelidad de los resultados según unos datos reales.

Normalmente, al tratarse de un cambio frente a la aplicación utilizada anteriormente en el entorno de

Cliente, o el caso de constituir una aplicación para cumplir una tarea donde antes no había ningún tipo de software, se recompensará el uso de la versión Beta de dicha aplicación. Se motivará a los usuarios

finales para que realicen las pruebas beta sin la presencia de OAC o desarrolladores, los cuales aportarán

los resultados de las mismas a la OAC para terminar de elaborar el IPA (contendedor del resultado de las pruebas Alfa y Beta). Esta tarea normalmente se hará mediante el uso de encuestas de satisfacción y de

forma planificada por la OAC, (más detalles en la sección 2.2.1 Análisis de la realidad), para llevar un

control de los resultados formal y ordenado.

45 UNE 71044 1999 46 MÉTRICA v.3, Modelo SAC, ‘IAS Procedimiento Global’, Sección 3, IAS 3 Pruebas de Acpetcaión del Sistema

73


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’


74

74

Tabla 31. Tareas de Despliegue

TAREAS DE DESPLIEGUE

FASE TAREA DESCRIPCIÓN

Previo a la

codificación del software

Creación o preparación de

los entornos de Desarrollo e Integración

El equipo de Despliegue creará o preparará en caso de que existiera previamente el entorno de

Desarrollo y el de Producción. Tarea necesaria

para que el equipo de Codificación codifique el software en un entorno optimizado para ello, así

como un entorno para probar las relaciones del

software con otros sistemas de información.

Tras la codificación

del software y

previo a su certificación por la

OAC

Despliegue de la aplicación en los entornos de

Desarrollo e Integración

No es necesario ya que el software se ha creado en

dichos entornos.

Creación o preparación del

entorno de Certificación

El equipo de Despliegue creará o preparará en

caso de que existiera previamente el entorno de Certificación. El propósito es brindar a la OAC un

entorno optimizado para la certificación de la

aplicación recién codificada por Desarrollo, donde puedan ejecutar todas las pruebas sin problemas.

Despliegue de la aplicación

en el entorno de

Certificación

El equipo de Despliegue implanta la aplicación en

el entorno de Certificación para que la OAC

pueda comenzar las pruebas. Comenzará con las pruebas de despliegue para comprobar la

estabilidad de la aplicación en un entorno

diferente del cual se creó.

Tras la certificación del software por la

OAC

Creación o preparación del

entorno de Cliente

Operaciones mediante las cuales prepara el entorno de Cliente para que pueda soportar la

aplicación en todos sus ámbitos.

Despliegue de la aplicación

en el entorno de Cliente

Supone la última tarea del equipo de Despliegue

durante el proceso software. Se implantará la aplicación ya certificada por la OAC en el entorno

Cliente para que los usuarios realicen las pruebas

Beta, y, en caso de éxito de las mismas, tener listo el software instalado para usarlo en el futuro sin

problemas.

Al implantarse en este útimo entorno, la OAC realizará una vez más las pruebas de despliegue y

de sistema, para garantizar la estabilidad de la

aplicación en el nuevo entorno.48

48 Tabla realizada bas{ndonos en la norma UNE/ISO/IEC 90003 2005 y en MÉTRICA v.3, Modelo SAC, ‘SAC002P_IAS_Implantacion y

Aceptacion de Sistemas_1300’

75


49

Continuando con el proceso software, tras la realización de las pruebas Alfa de Aceptación por parte del usuario, el equipo de despliegue implantará la aplicación en el entorno Cliente. Una vez hecho esto, es

necesario certificar o aprobar la correcta implantación del mismo, mediante una última ejecución de las

pruebas de despliegue y las pruebas de sistema. De ello se debe encargar la OAC.

La OAC debe realizar sobre el software implantado dichas pruebas, que no conllevan la actualización,

inserción o eliminación de datos. El objeto de estas pruebas no es, por tanto, la de certificar que la

funcionalidad requerida funciona correctamente, sino de comprobar que el software es estable.

Siempre que las incidencias superen el umbral de rechazo preestablecido, será necesario aplicar la marcha atrás especificada en el MIC, y el software no quedará implantado en el entorno de Cliente. Si dicho umbral no

se supera, la OAC dará el visto bueno para que el software quede implantado en el entorno.

De cualquier modo, será necesario subsanar los errores detectados, aunque el software quede implantado en el entorno de Cliente. Para ello se han de documentar todas las incidencias detectadas durante la tarea de

implantación.

Tras la realización de las pruebas de despliegue y de sistema, en caso de que se hayan detectado incidencias, se ha de realizar un análisis de las mismas. Así, el jefe del Equipo de Certificación debe realizar un exhaustivo

análisis y valoración de las incidencias detectadas.

En el análisis se ha de valorar si los errores detectados provocan un mal funcionamiento del software en alguna

de sus funcionalidades o hacen que este sea total o parcialmente inservible. Se ha de medir, también, el riesgo de corrupción de datos que provocan los errores detectados.

En caso de que la OAC encontrase anomalías de suficiente envergadura podrá, a través de su responsable,

ordenar la marcha atrás de la instalación para que el software vuelva al estado en el que se encontraba antes de la implantación en el entorno Cliente.

Por tanto, en base al estudio de las incidencias detectadas, la OAC ha de tomar la decisión de:

Ordenar la marcha atrás de la implantación.

Dar el visto bueno a la implantación a pesar de las incidencias detectadas.

En el caso de que la OAC decida dar el visto bueno, la aplicación quedará instalada en el entorno Cliente y el usuario final podrá realizar las pruebas beta. Una vez las pruebas beta tengan éxito, se podrá seguir con la

última fase del proceso software, explicada en la siguiente sección.

49 Información extraída de MÉTRICA v.3, Modelo SAC, ‘SAC002P_IAS_Implantacion y Aceptacion de Sistemas_1300’


76

76

2.9 Finalización Del Proyecto

Tras la realización de las pruebas de aceptación por parte del usuario final y de la redacción del Informe de Pruebas de Aceptación donde se detallan y valoran todas las incidencias detectadas y registradas, es

necesario que el Cliente dé el visto bueno a la implantación del software en el entorno Cliente. Esta

decisión debe ser valorada y tomada en base al Informe de Pruebas de Aceptación elaborado tras las pruebas.

En caso de que la decisión sea negativa, el Equipo de Desarrollo tendrá que realizar una nueva entrega, en

la que se hayan corregido los errores detectados en las pruebas de aceptación, y que han llevado al RAU a desestimar el despliegue final del software en el entorno Cliente, volviéndose a tener que realizar la

actividad de certificación de implantación y funcional del Sistema.

En caso contrario, el RAU habrá dado el visto bueno a la implantación del software en el entorno Cliente

y se llevará a cabo dicha tarea para que el usuario cliente finalmente pueda hacer uso de la aplicación sin ningún problema.

De esta manera se da por concluida la fase CEI / IAS, el Cliente tendrá la aplicación lista para su uso en

su entorno y, si fue definido en el proyecto software, comienza el mantenimiento de la aplicación.

2.9.1 Mantenimiento

En caso de que se ofreciera al Cliente un mantenimiento del software una vez instalado, será necesario

elaborar un Plan de Mantenimiento. El Plan de Mantenimiento sienta las bases del futuro mantenimiento del

proyecto. Su elaboración es responsabilidad del DP, que requerirá la necesaria colaboración del RAU.

Tomando como referencia MÉTRICA v.350

y la normativa ISO51

, El resultado es un plan donde se especifica cómo será el mantenimiento del proyecto y cómo estará compuesto el equipo que realizará dicha labor.

Sólo en el caso de proyectos cuyo alcance sea el mantenimiento en sí, de un sistema ya implantado, será

opcional la elaboración de dicho documento. El mantenimiento deberá incluir los siguientes factores:

Alcance

Identificación del estado inicial de la aplicación y los elementos de mantenimiento

Las organizaciones de apoyo y acuerdos

Las actividades de mantenimiento, incluyendo la resolución de problemas, soporte a usuarios, soporte

hardware y seguimiento del sistema para detectar fallos

Modificaciones de interfaz que puede ser requerido cuando se hacen adiciones o cambios al sistema

hardware o componentes, controlados por software

Las actividades de gestión de la configuración, pruebas y aseguramiento de la calidad

El calendario de liberaciones propuesto

Cómo se van a llevar a cabo la expansión funcional y mejora de las prestaciones

Registros e informes de mantenimiento

El resultado de los informes de mantenimiento se utilizará para la evaluación y mejora del producto software,

ya sea para una nueva entrega correspondiente a la misma aplicación de funcionalidad expandida en un futuro,

o bien para la subsanación de incidencias que se vayan encontrando durante su uso.

50 MÉTRICA v.3, Modelo SAC, ‘SAC002P_GES_Gestión de Proyectos_0500’, sección GES 14: Elaboración Plan de Mantenimiento 51 UNE ISO IEC 90003 2005, sección 7.5.1.7 Mantenimiento

77


2.9.2 Histórico de Proyecto52

El objetivo del documento Histórico de Proyecto es concluir el Proyecto comprobando el cumplimiento de los objetivos y recibiendo la conformidad del resultado. Para ello, el DP junto con el procedimiento de elaboración

del Histórico de Proyecto:

Realizará el balance final del proyecto indicando si quedan aspectos pendientes y el acuerdo para su

finalización.

Hará una recapitulación de todos los entregables generados.

Evaluará el desarrollo del proyecto, haciendo hincapié en los obstáculos encontrados y como se han

superado.

Este proceso puede aplicarse con alguna modificación a las entregas de cada fase o versión del producto final.

De hecho, es importante el cierre formal de las fases para prevenir la pérdida de información importante y

preparar correctamente la próxima.

53Una vez recibido el documento del Histórico de Proyecto de parte del Director de Proyecto, se procederá a la

validación de su contenido por parte del Responsable del Área Usuaria.

Éste no realizará una revisión del documento en base a los procedimientos de revisión de documentos definidos en esta metodología. La revisión que se realiza sobre el Histórico de Proyecto debe estar orientada a

verificar su completitud y comprobar que el contenido se ajusta a la realidad del proyecto.

Si se da la conformidad al documento se dará paso a la actividad de archivo del mismo. En caso de que no se haya validado el documento del Histórico de Proyecto se requerirá al DP su corrección. Éste corregirá aquellas

cosas que el responsable de la validación le indique y volverá a remitirle el documento para su validación.

En la medida que los proyectos concluyen con el cumplimiento de los objetivos previstos, se hace

imprescindible la incorporación del Histórico de Proyecto a la base de datos o aplicación corporativa de proyectos, con los siguientes objetivos:

Almacenamiento de la experiencia de proyectos en un formato de fácil acceso para los usuarios.

Para el desarrollo de nuevos proyectos es recomendable revisar los proyectos terminados y tomar los módulos de éxito ya diseñados para reutilizarlos en los nuevos proyectos con el objetivo de hacer uso

del conocimiento ya elaborado y aplicado con los ajustes que la práctica determinó. Ejemplos de

módulos pueden ser los procedimientos repetitivos, normas, formas de contratos, procesamientos estadísticos y evaluación de calidad entre otros.

Es una base de información de conocimiento para todos los DP.

Permite analizar la información, estudiar las regularidades y ganar en calidad en los próximos

proyectos.

El área de planificación puede analizar como se cumplieron los plazos y detectar las irregularidades con el objetivo de facilitar el trabajo de los DP y evaluar el impacto de los mismos.

Posibilidad de desarrollar programas ajustados a las necesidades reales a partir de los resultados de los proyectos ejecutados.

52 Bas{ndonos en MÉTRICA v.3, Modelo SAC, ‘SAC002P_GES_Gestión de Proyectos_0500’, sección GES 15: Elaboración Histórico de Proyecto 53 Según MÉTRICA v.3, Modelo SAC, ‘SAC007P_IHP_Histórico_de_Proyecto_0100’


78

78

2.9.3 Informe de Fin de Proyecto

Según MÉTRICA v.354

, el informe de finalización de proyecto se concibe como un documento que certifica el fin de los trabajos planificados en el ámbito de un proyecto independientemente de su tipología.

Dicho informe será elaborado por el JP siguiendo la plantilla confeccionada con tal finalidad (Figura 8 –

Informe de Fin de Proyecto). Una vez elaborado el informe, quedará a la espera que tanto DP como RAU aprueben dicho entregable.

Además de su aprobación, será necesario el archivado del documento debidamente cumplimentado por cada

uno de los implicados en su validación.

55

Figura 8. Ejemplo de Informe de Fin de Proyecto

54 Bas{ndonos en MÉTRICA v.3, Modelo SAC, ‘SAC002P_GES_Gestión de Proyectos_0500’, sección GES 16: Elaboración del Informe de Fin de Proyecto 55 Imagen extraída de MÉTRICA v.3, Modelo SAC, Finalización y Cierre del proyecto, ‘IFP Plantilla’

79


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/

https://www.recursosenprojectmanagement.com/cierre_del_proyecto/

Herramientas CASE

80

80

3 HERRAMIENTAS CASE

n esta sección se describirán las herramientas CASE (Computer Aided Software Engineering „Ingeniería

de Software Asistida por Ordenador‟) más comunes utilizadas durante todas las fases del proceso

software descritas en el capítulo anterior. Nos centraremos sobre todo en las herramientas CASE utilizadas por la OAC, en especial, las que se usaban en everis durante nuestra experiencia en su departamento

de calidad. Estas herramientas son aplicaciones que facilitan el desarrollo software en todas sus fases,

constituyendo una ayuda software que optimiza todo el proceso en términos de tiempo y dinero.

Las herramientas CASE se pueden dividir en 3 grupos según la fase del proceso software que cubren:

U-CASE (Upper): Usadas para las fases de análisis de la realidad, planificación del proyecto y

definición de requisitos

M-CASE (Middle): Usadas para las fases de análisis y diseño del software

L-CASE (Lower): Usadas para las fases de codificación y control de calidad, depuración y pruebas

A continuación explicaremos las herramientas CASE más comunes utilizadas en cada fase:

3.1 Herramientas CASE para la ingeniería de requisitos

Son herramientas que facilitan el análisis de la realidad de la empresa, ayudan a encontrar las necesidades y a

definir los requisitos, además de llevar el seguimiento y trazabilidad de los mismos a lo largo de todo el ciclo de vida software. Muchas de estas herramientas, además, proporcionan medios de comunicación entre Cliente,

DP y los diferentes equipos que participan en el proceso software.

Algunos ejemplos de herramientas CASE para esta fase son: Rambutan, Controla, Reto, SoftREQ, IBM Rational RequisitePro, Jeremia, Irqa 4 o Gatherspace.

3.2 Herramientas CASE para el diseño

Son herramientas que facilitan el diseño del software, ayudan a la representación visual de los diferentes

componentes, y, en su mayoría, sirven para crear diagramas UML (Unified Modeling Language „Lenguaje Unificado de Modelado‟). Los diagramas UML son la forma de visualizar, construir y representar un sistema

más conocida y utilizada en la actualidad, por lo tanto, diseñar el software mediante diagramas UML facilita

su comprensión por parte de todos. En el DAO el uso de estos diagramas resulta imprescindible. Por este

motivo existen diversas herramientas CASE que facilitan el diseño con la creación intuitiva de diagramas UML.

Algunos ejemplos de herramientas CASE para esta fase son: HotGloo, Protoshare, invision, yUML, gliffy,

gennymodel, lucidchart, editor jsuml2 o MagicDraw.

E

81


3.3 Herramientas CASE para la codificación

Son herramientas CASE que facilitan la codificación del software. La mayoría de herramientas CASE de esta fase la conforman las denominadas IDE (Integrated Development Environment „Entorno de Desarrollo

Integrado‟). Las IDE están constituidas por editores de código fuente, herramientas de construcción

automáticas y depuradores. Para facilitar la codificación, los IDE suelen ofrecer opciones para autocompletar las líneas, resaltar el comienzo y el final de paréntesis, corchetes y llaves o colorear el texto según su

funcionalidad (función, variable, constante, operador, etc). Asimisno, los IDE pueden incluir un compilador o

un intérprete.

Algunos ejemplos de herramientas CASE para esta fase o IDE son: Java Netbeans, Eclipse, Visual Studio,

JetBrain, Codelite, PyCharm, Xcode o Komodo.

3.4 Herramientas CASE para el aseguramiento de la calidad

Son herramientas CASE que facilitan el control de calidad del proyecto software en todos sus ámbitos, incluyendo la realización de pruebas estáticas y dinámicas, herramientas para el control de versiones,

seguimiento del proyecto, revisión documental, gestión de BBDD, administración de usuarios y contraseñas,

gestión de incidencias y transferencia de archivos.

A continuación explicaremos en detalle las herramientas más importantes que utilizamos en la oficina de aseguramiento de la calidad en everis, y el funcionamiento detallado de las mismas.

Nota*: Las herramientas que a continuación se detallan son un ejemplo, lo cual no quiere decir que sean las

mejores ni que haya muchas otras diferentes que realicen las mismas funciones o parecidas.

3.4.1 JIRA

JIRA es una herramienta CASE para la gestión y seguimiento de proyectos software, especialmente útil para la

OAC y para el comité de seguimiento. Se trata de una herramienta que permite ordenar los proyectos que lleva

una empresa, diferenciando entre los distintos clientes, equipos de desarrollo, oficinas de calidad, etc. Centrándonos en un único proyecto software de una empresa para un Cliente, JIRA mostrará el estado del

proyecto en todo momento, qué tareas se han hecho y qué tareas quedan por hacer. También mostrará el estado

de los diferentes entregables, y especificará si ya han sido o no sometidos a una revisión técnica por parte de la OAC.

JIRA define una nomenclatura estándar para las diferentes entregas. Usará el siguiente formato:

XXXYYYEZZ, en el cual los 3 caracteres XXX representarán el anagrama alfabético de la aplicación en cuestión. Los caracteres YYY serán numéricos y representarán el código de proyecto dentro de la misma

aplicación. Por último, los caracteres ZZ representarán la versión de la entrega dentro del proyecto dentro de la

aplicación. De esta manera, si nos encontramos en la versión 8 del proyecto 4 de la aplicación „Cargos‟, el

nombre de la entrega en JIRA sería: „CAR004E08‟.

Por otro lado, para cada entrega se muestra el estado en el que se encuentra y quién es la entidad responsable

de continuar. Los diferentes estados en los que puede encontrarse una entrega según JIRA son:

Preparado: La entrega se acaba de crear y subir a JIRA, y todavía no ha comenzado su certificación.

En este estado pueden estar completadas o no las fases de definición de requisitos, diseño y codificación.

En progreso: La entrega se está certificando por la OAC, de manera que está sometiéndose a pruebas

estáticas o dinámicas o a revisiones técnicas.

Bloqueada: La OAC ha encontrado alguna incidencia bloqueante que impide la correcta consecución

del resto de pruebas. En este caso, el equipo responsable de corregir la incidencia notificará a la OAC

cuando lo haya hecho, y la entrega pasará de nuevo al estado „En Progreso‟.

Herramientas CASE

82

82

Rechazada: Un entregable no ha superado satisfactoriamente las revisiones técnicas de la OAC y ha

sido devuelto al equipo responsable de su corrección, junto con su respectivo IRT. Una vez el equipo reponsable haya corregido las incidencias descritas en el IRT, devolverá la nueva versión del

entregable a la OAC y el estado pasará de nuevo a „En progreso‟.

Aceptación Previa: La entrega ha sido certificada por la OAC y ha superado satisfactoriamente las

pruebas y las revisiones técnicas.

Cerrada: La entrega ha superado satisfactoriamente las pruebas de aceptación, y tanto Cliente como

OAC han dado su visto bueno para terminar y cerrar la entrega, con la aplicación lista para usarse en

el entorno Cliente.

En JIRA, cada entrega se divide por los entregables que contiene (descritos en la Tabla 32. Lista final de entregables, sección 2.6.4). Para cada entregable, la entidad que haya trabajado en él dispone de una sección

para indicar qué tareas ha realizado sobre el entregable en cuestión, quién ha sido la persona responsable y

cuánto tiempo ha invertido en dichas tareas. Cada entregable a su vez se puede encontrar en cada uno de los

estados descritos anteriormente (preparado, en progreso, bloqueado, rechazado, en aceptación previa y cerrado). De esta manera, el comité de seguimiento puede comprobar instantáneamente cuál es el estado de

cada uno de los entregables, quién es responsable de continuar con cada uno y cuánto tiempo se ha invertido

en cada tarea, convirtiéndose así en una herramienta CASE fundamental para el seguimiento del proyecto software.

3.4.2 QM

QM (Quality Management) es una herramienta CASE para el control de versiones y la transferencia de

archivos entre diferentes entidades. Constituye el medio principal de subida, descarga y envío de archivos

entre los diferentes equipos que participan en el proceso software. Se trata de una plataforma web compartida dividida por las diferentes entregas existentes, siguiendo la nomenclatura XXXYYYEZZ definida por JIRA.

Una vez completadas las fases de definición de requisitos, diseño y codificación, los diferentes equipos subirán

los entregables generados a QM, para que la OAC pueda descargarlos y comenzar con las revisiones técnicas y las pruebas. LA OAC a su vez subirá a QM los IRT y los informes de calidad generados para que los equipos

correspondientes puedan descargarlos para conocer las incidencias encontradas.

QM define una nomenclatura estándar para el control de versiones de los entregables. Usará el formato: „XXXYYYE_VVV_Nombre del entregable_ZZWW‟.

XXX representará el anagrama alfabético de la aplicación en cuestión, igual que en JIRA

YYY representará el código numérico del proyecto dentro de la misma aplicación, igual que en JIRA

VVV representará el anagrama del entregable en cuestión

ZZ representará el código numérico de la versión de la entrega dentro del proyecto dentro de la misma

aplicación, igual que en JIRA

WW representará el intento de corrección (comenzando por 0), siendo el número de veces que ha sido

sometido a las revisiones técnicas de la OAC

De manera que, siguiendo con el ejemplo de JIRA, la versión 8 del proyecto 4 de la aplicación „Cargos‟, supongamos que el MUS ha sido rechazado 2 veces por la OAC y el equipo de Desarrollo ha subido a QM el

tercer intento. El nombre del entregable sería: „CAR004E_MUS_Manual de Usuario_0802‟.

De igual manera, cuando la OAC realice la revisión técnica de este entregable, sea el resultado aceptado o rechazado, subirá el IRT en la sección de QM correspondiente a dicho entregable, con el nombre:

„CAR004E_IRT_Informe de Revisión Técnica_0802‟.

Con esta nomenclatura, se asegura un correcto control de versiones durante todo el proceso de certificación,

tarea fundamental por parte de la OAC en esta fase.

Por otro lado, los archivos entregables estarán accesibles para cualquier equipo que necesite descargarlos, y, a

su lado, se especificará su estado, si está aceptado, rechazado, o pendiente de revisión.

83


3.4.3 Mantis

Mantis es una herramienta CASE para la gestión de las incidencias detectadas por la OAC en los diferentes entregables durante las revisiones técnicas y las pruebas estáticas y dinámicas. Se trata de una plataforma web

a la cual pueden acceder la OAC y DP, para llevar un seguimiento de las incidencias, ordenadas según las

entregas (siguiendo la nomenclatura de JIRA y QM) y de cada uno de los entregables.

Mantis es una herramienta fundamental para la OAC ya que recoge todas las incidencias de una entrega de una

forma ordenada, incluyendo la versión del entregable en cuestión, la gravedad de la incidencia y la posibilidad

de anexar archivos adjuntos, tales como capturas de pantalla o resultados en formato texto de diversas pruebas

para apoyar las incidencias. Además, incorpora una funcionalidad que, mediante diversos filtros según nombre del entregable, fecha, versión, etc, permite exportar todas las incidencias encontradas en un entregable

directamente al IRT correspondiente a dicho entregable, automatizando así el proceso de elaboración de

informes de calidad.

Mantis almacena en su Base de Datos todos los criterios de certificación descritos en la sección 2.6.2

Incidencias, manteniendo su descripción y su gravedad, de forma que es más fácil e intuitivo registrar las

incidencias más frecuentes. A la misma vez, permite la generación de una nueva incidencia que no pertenezca a ningún criterio de certificación previo, o incluirlacomo defecto genérico si resulta ambiguo clasificar dicha

incidencia.

Esta herramienta también añade la posibilidad de diferenciar los defectos encontrados corregidos y sin

corregir, junto con la versión del entregable en la que se encuentra la incidencia y en la que se corrige. De esta manera, es más cómodo decidir el resultado de una revisión técnica al observar en un mismo sitio las

incidencias corregidas y no corregidas.

3.4.4 TOAD Oracle

TOAD Oracle es una herramienta CASE que permite a la OAC acceder a cualquier BBDD necesaria para la certificación de una aplicación, además de la modificación de los elementos necesarios en dichas BBDD. Esto

es necesario cuando la OAC necesita ejecutar SCR de BBDD o actualizar elementos, ya sea para la instalación

y configuración inicial de la aplicación, modificación de tablas de datos, creación o eliminación manual de

sinónimos públicos, roles y privilegios, usuarios, o introducción y eliminación de información interna de la aplicación para ejecutar diferentes pruebas.

TOAD permite el acceso a cualquier BBDD siempre que se tenga conexión a la misma y se disponga del

usuario administrador de la misma y su contraseña. Dispone de un modo que permite lanzar sentencias sql directamente, afectando de inmediato a las BBDD deseadas, así como un modo gráfico que permite recorrer

las diferentes tablas de un esquema y modificar los datos en modo ventana, sin necesidad de lanzar una sola

línea sql.

Esta herramienta incluye diversas opciones para facilitar la, a veces, abrumadora cantidad de información que

podemos encontrar en un esquema de aplicación. Estas opciones incluyen, entre otras:

Filtros de búsqueda para las diferentes tablas

Rastreador por filas y columnas

Buscador de palabras clave

Varios criterios de ordenación de las filas en cada tabla (según el identificador unitario, alfabético,

numérico, según las columnas con más o menos datos, fecha, etc)

Funciones de búsqueda de una cadena de texto

Funciones de reemplazo de una cadena de texto por otra

TOAD tiene un modo de editor de texto que permite importar y ejecutar SCR de BBDD directamente, con todos los permisos de lectura, escritura y ejecución. Esto es útil para la OAC por si desea realizar pruebas más

complejas sobre los SCR de BBDD con total libertad de modificación o agilizar pruebas funcionales.

Herramientas CASE

84

84

3.4.5 Jenkins y Sonarqube

Jenkins es una compleja herramienta que ofrece un método simple para configurar un entorno de integración continua para cualquier combinación de lenguages de programación y repositorios, a la vez que es capaz de

automatizar tareas rutinarias de desarrollo. A día de hoy, Jenkins constituye uno de los servidores de software

libre para automatización de tareas de desarrollo software más importantes y más utilizados.

Entre las muchas funciones que ofrece esta potente herramienta, nuestro equipo de aseguramiento de la calidad

utilizaba, mayoritariamente, su análisis de código estático, gracias a la cual la tarea de pasar las pruebas

estáticas a los ficheros software resulta automática. Esta función es la resultante de instalar el plugin de

Sonarqube en Jenkins.

Sonarqube es una herramienta CASE que realiza análisis de código estático, es decir, analiza los ficheros de

código sin necesidad de ejecutarlos. Jenkins permite la integración del plugin Sonarqube, con el cual se podrán

realizar dichos análisis de código estático directamente desde una entrega en Jenkins.

Esta función consiste en crear una entrega en el servidor Jenkins, respetando la nomenclatura de JIRA para la

misma, y adjuntarle todos los ficheros SFW que conforman la entrega correctamente ordenados en un sistema

de directorios. El plugin Sonarqube analizará directorio por directorio, cada uno de los ficheros SFW que conforman una entrega, y generará un informe Sonarqube. Este informe contiene el resultado de las pruebas

estáticas a los ficheros SFW, y es lo que constituirá el PES (detallado en la sección 2.6.4 Informes de Calidad).

El análisis estático que nos brinda el informe de Sonarqube permite mejorar el código detectando errores de

programación y estándares para la programación estructurada que no han sido respetados en la codificación. Asimismo, detectamos problemas de diseño al analizar las dependencias entre clases o incoherencias en la

arquitectura, duplicidad de código, para reestruturar ciertos módulos y así poder reutilizar código en la medida

de lo posible, y detectamos vulnerabilidades en la seguridad, para prevenir ciertos ataques, como SQL Injection en la recogida de parámetros entre otros.

El informe de Sonarqube se añadirá al IPC que elaborará la OAC tras la realización de todas las pruebas.

3.4.6 SoapUI

Soap UI es una herramienta CASE que nos permite probar los web services (o servicios web). En ocasiones,

las entregas constituirán un web service, que no es más que un software que permite el intercambio de datos entre dos o más aplicaciones a través de una red, privada o pública, sin importar el entorno, plataforma o

lenguaje de programación en el que se encuentren.

SOAP UI nos permitirá probar web services de forma ágil, en formato WSDL (Web Services Description Language „Lenguage de Descripción de Servicios Web‟), mediante el estándar SOAP (Simple Object Access

Protocol „Protocolo de Acceso a Objetos Simples‟).

El funcionamiento de SOAP UI es simple. Para probar un web service, la OAC crea un proyecto SOAP y especifica, entre otros parámetros, la url donde se encuentra el descriptor del servicio web en cuestión. De este

modo, SOAP UI se encuentra con acceso al web service que queremos probar. Una vez configurado, será

necesario crear diferentes peticiones para invocar a los métodos deseados del webservice. Esta tarea la puede

realizar la OAC desde cero, o, por el contrario, las peticiones pueden venir creadas de antemano por Desarrollo, estando incluidas en el PP para probar así el web service más eficientemente. Una vez creadas las

peticiones, se lanzarán con SOAP UI, de manera similar a como se accede a una página web, y el web service

retornará una respuesta según la petición realizada.

Nuestro equipo de aseguramiento de calidad, entre las muchas funciones que ofrece SOAP UI, utiliza

mayoritariamente la generación de pruebas funcionales. Es el caso en el que se comprueba que el web service

cumple con las funcionalidades descritas en los RF, cuyos casos de prueba pueden ser directamente creados

por la OAC, permitiendo la modificación de todos los parámetros que se desee. En estos casos de prueba, se comprueba la salida devuelta por el web service y se corrobora que los datos de salida son los esperados.

Además de pruebas funcionales, SOAP UI permite la realización de pruebas no funcionales, como por

ejemplo pruebas de rendimiento del web service.

85


3.4.7 KeePass

KeePass es una herramienta CASE que permite el almacenamiento seguro de usuarios y contraseñas. A la hora de certificar entregas, es muy posible que la OAC necesite memorizar una gran cantidad de usuarios y

contraseñas para acceder a los distintos esquemas de BBDD, entrar a las aplicaciones en modo administrador,

acceder a los datos ocultos, etc. KeePass ofrece una forma sencilla de organizar todos los usuarios y contraseña que se necesiten de una manera eficaz y segura.

3.4.8 Notepad++

Se trata de un editor de texto sencillo pero potente, útil para modificar ficheros de texto. La OAC utilizará el

Notepad++ cuando sea necesario modificar algún fichero de configuración de SFW para adaptarlo al entorno

de certificación, actualizar las rutas de los ficheros o modificar nombres de usuarios, contraseñas, fechas, entre otros.

3.4.9 DiffPDF

Herramienta que permite comparar dos ficheros pdf. Con el fin de realizar un análisis estático documental más

profundo, nuestro equipo de aseguramiento de calidad opta por una herramienta como esta, que simplemente posiciona los dos ficheros pdf en la pantalla uno al lado del otro, y marca las diferencias en un color distinto.

Al no tratarse de una herramienta que realice análisis documental automático, el personal de la OAC puede

leer los ficheros PDF con atención para detectar cualquier posible incidencia.

3.4.10 VirtualBox

Herramienta CASE de virtualización. Permite accede a máquinas virtuales y a entornos sandbox para la ejecución de diversas pruebas o la instalación de la aplicación. Nuestro equipo de calidad, a la hora de realizar

las pruebas funcionales de una aplicación, ejecuta dicha aplicación en una máquina virtual, gestionada por

VirtualBox, para prevenir que los fallos afecten al equipo directamente, y poder realizar una marcha atrás sin preocupaciones. Para realizar las pruebas funcionales, la OAC va ejecutando uno por uno los CP especificados

en el PPF, y va comprobando que las salidas generadas por la aplicación son las esperadas según el PPF.

Conclusiones

86

86

4 CONCLUSIONES

n este apartado se recogen las conclusiones personales con respecto a este TFG. El objetivo del TFG era

realizar un estudio teórico de un proceso de calidad en el ámbito del desarrollo software. Apoyándonos

en los diferentes estándares existentes al respecto, en los conocimientos adquiridos en la carrera relacionados con el tema y en la experiencia laboral como técnico de calidad en la empresa everis, hemos

conseguido realizar un estudio amplio acerca del ciclo de vida software y el aseguramiento de la calidad del

mismo.

Durante este TFG hemos utilizado, de entre todos los que existen, un modelo en cascada de desarrollo

software, y hemos seguido casos específicos en más de una ocasión. Con respecto al proceso software, al

tratarse de un tema tan amplio y extenso, nos ha sido imposible recoger en un único trabajo todos los casos y

situaciones posibles, teniendo que realizar para tal efecto un estudio diferente para cada uno de los modelos de desarrollo software, o teniendo en cuenta todas las posibles metodologías a seguir, o incluso utilizando

diferentes herramientas CASE de entre todas las que existen. Aún así, hemos conseguido desarrollar un

método para el control de calidad que se puede extrapolar (en mayor o menor medida según lo diferente que sea el proyecto software del prototipo que en este documento se estudia) a otro tipo de proyectos, a modo de

guía para empresas o personas que quieran reunir información acerca del proceso software y qué pasos seguir

para llevar a cabo un aseguramiento de la calidad básico.

Este TFG se puede expandir bastante en la sección de herramientas CASE por ejemplo, ya que nos hemos

centrado en explicar las que hemos usado bajo nuestra experiencia laboral. Con una mayor experiencia laboral

y habiendo probado más herramientas, podríamos haber incorporado una sección de comparación de

herramientas CASE, y determinar las ventajas e inconvenientes de cada una para cada aspecto del control de calidad. También se puede expandir en el ámbito de herramientas CASE en las fases que no son el control de

calidad, ya que al no haber participado activamente de estas actividades, la información acerca de las

herramientas CASE que se pueden utilizar es muy ampliable.

Hemos tratado de recoger muchos criterios de certificación, pero esta información también se podría expandir

al tratar con aplicaciones que no utilicen java como código fuente, o que sigan otros estándares para

certificarse. En la sección de criterios de certificación documentales sí hemos conseguido aportar mucha

información relevante, que se puede extrapolar fácilmente a cualquier documento del mismo tipo en cualquier proyecto software.

En resumen, se podría haber realizado un trabajo mucho más extenso, capaz de contener todas y cada una de

las situaciones posibles en el ámbito del desarrollo software, pero al tratarse de un estudio teórico, la información de este TFG se puede extrapolar, y utilizar fácilmente como guía de control de calidad durante el

ciclo de vida software de cualquier proyecto.

E

87


REFERENCIAS

[1] „Managing the Development of Large Software Systems’, Winston Royce, 1970

[2] „Software Engineering Economics‟, Barry Boehm, 1981

[3] „Software Engineering‟, Ian Sommerville, 1985

[4] ISO/IEC 12207:1995 (Information Technology - Software Life Cycle Processes)

[5] ISO/IEC-15504 SPICE (Software Process Improvement and Assurance Standards Capability

Determination

[6] MÉTRICA V.3, 2001

[7] UNE 71044 – 1999

[8] MÉTRICA v.3, Modelo SAC, „SAC-Definición_de_roles‟

[9] https://www.lancetalent.com/blog/8-herramientas-para-la-gestion-de-proyectos-profesionales/

[10] https://www.atlassian.com/software/jira

[11] https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp

[12] „SAC005P_CON_Plan_de_Configuracion_0100‟, Normativa Técnica, MÉTRICA v.3

[13] UNE-EN 16271:2013

[14] ISO 21500:2012

[15] https://www.gestiopolis.com/metodologia-para-evaluacion-diagnostico-y-diseno-de-procesos/

[16] https://www.emprendepyme.net/tecnicas-e-instrumentos-para-detectar-las-necesidades-de-

capacitacion.html,

[17] https://es.surveymonkey.com/mp/employee-satisfaction-surveys/

[18] https://www.survio.com/plantilla-de-encuesta/evaluacion-de-software

[19] https://www.monografias.com/docs/Ejemplo-encuesta-de-satisfacci%C3%B3n-para-usuario-de-

FKZ3RNCMY

[20] Apuntes de Proyectos de Telemática

*21+ „Introducción a los Proyectos‟, Departamento de Ingeniería Telemática, 2017-2018: https://ev.us.es/bbcswebdav/pid-2439180-dt-content-rid-8100833_1/courses/201718-1990061-199-EC/Proyectos-tema01.pdf

[22] Trabajo Final Proyectos de Telemática

[23] https://contrataciondelestado.es/wps/wcm/connect/62c67958-52c9-4ef5-b30e-

cd3b1566aef2/DOC_CD2012-382658.pdf?MOD=AJPERES

[24] http://ccapsa.com/2013/10/02/

[25] UNE-ISO/IEC 90003-2005

[26] ISO 9001-2000

[27] MÉTRICA v.3, Modelo SAC, „SAC007P_DDR_Definicion Detallada Requisitos_0100‟

[28] ISO/IEC 14764:1999

https://www.lancetalent.com/blog/8-herramientas-para-la-gestion-de-proyectos-profesionales/

https://www.atlassian.com/software/jira

https://ws142.juntadeandalucia.es/agriculturaypesca/qm/qm/principal/jsp/qm_pr_pri_presentacion.jsp




https://es.surveymonkey.com/mp/employee-satisfaction-surveys/

https://www.survio.com/plantilla-de-encuesta/evaluacion-de-software







http://ccapsa.com/2013/10/02/

Referencias

88

88

[29] ISO/IEC 12207:1995

[30] http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/408

[31] ISO 10007-1997

[32] MÉTRICA v.3, modelo SAC: „SAC007P_DAO_Diseño Arquitectura OO_0100‟

[33] MÉTRICA v.3, modelo SAC: „DSI Procedimiento Global‟

[34] MÉTRICA v.3, modelo SAC: „SAC007P_MIC_Manual_Instalacion_Configuracion_0100‟

[35] METRICA V.3, „Aseguramiento de la Calidad‟

[36] MÉTRICA v.3, modelo SAC, „Objetivos del Sistema de Aseguramiento de la Calidad‟

[37] ISO/IEC/IEEE 29119

[38] IEEE 829

[39] IEEE 1008

[40] BSI 7925-1

[41] BSI 7925-2

[42] ISO/IEC 15289

[43] MADEJA: http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/ingenieria/creacion-

y-evolucion-sistemas

[44] http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/227

[45] https://es.wikipedia.org/wiki/Pruebas_de_software

[46] https://www.mantisbt.org/

[47] MÉTRICA v.3, modelo SAC, „SAC002I_GCP-GESTIÓN DE LA CALIDAD_0200‟

[48] https://www.soapui.org/

[49] https://winscp.net/eng/index.php

[50] https://www.toadworld.com/downloads

[51] https://notepad-plus-plus.org/

[52] MÉTRICA v.3, modelo SAC, Normativa Técnica, Indicadores de Certificación.

[53] MÉTRICA v.3, modelo SAC, „SAC002P_RDP_Revisión de Documentos_0800‟

[54] https://jenkins.io/

[55] https://www.sonarqube.org/

[56] MÉTRICA v.3, modelo SAC, „SAC007P_IPC_Informe_de_Pruebas_Certificación_0100‟ [57] MÉTRICA v.3, modelo SAC, „SAC002P_IAS_Implantacion y Aceptacion de Sistemas_1300‟

[58] MÉTRICA v.3, Modelo SAC, „IAS Procedimiento Global‟

[59] MÉTRICA v.3, Modelo SAC, „SAC007P_PIM_Plan de Implantacion_0100‟

[60] MÉTRICA v.3, Modelo SAC, „SAC002P_GES_Gestión de Proyectos_0500‟

[61] MÉTRICA v.3, Modelo SAC, „SAC007P_IHP_Histórico_de_Proyecto_0100‟

[62] MÉTRICA v.3, Modelo SAC, Finalización y Cierre del proyecto, „IFP Plantilla‟

[63] https://www.recursosenprojectmanagement.com/cierre_del_proyecto/

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/408



http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/227

https://es.wikipedia.org/wiki/Pruebas_de_software

https://www.mantisbt.org/

https://www.soapui.org/

https://winscp.net/eng/index.php

https://www.toadworld.com/downloads

https://notepad-plus-plus.org/

https://jenkins.io/

https://www.sonarqube.org/

https://www.recursosenprojectmanagement.com/cierre_del_proyecto/

89


Glosario

90

90

GLOSARIO

AENOR: Asociación Española de Normalización y Certificación 2

ASI: Análisis del Sistema de Información 27

BSI: British Standards Institution 45, 88

CAPDER: Consejería de Agricultura, Pesca y Desarrollo Rural 5

CASE: Computer Aided Software Engineering 'Ingeniería de Software Asistida por Ordenador' 80

CEI: Certificación e Implantación del Sistema 43

CP: Caso de Prueba 41

CSI: Construcción del Sistema de Información 35

CU: Caso de Uso 28

DAO: Diseño de Arquitectura Orientado a Objetos 9

DDR: Definición Detallada de Requisitos 4

DP: Dirección de Proyectos 4

DSI: Diseño del Sistema de Información 31

FAQ: Frequently Asked Questions 38

IAS: Implantación y Aceptación del Sistema 43

IDE: Integrated Development Environment „Entorno de Desarrollo Integrado‟ 81

IEC: International Electrotechnical Commission 2, 87

IEEE: Institute of Electrical and Electronics Engineers 45

IPA: Informe de Pruebas de Aceptación 70

IPC: Informe de Pruebas de Certificación 68

IRT: Informe de Revisión Técnica 64

ISO: International Organization for Standardization 2, 87

JP: Jefe de Proyecto 4

LOPD: Ley Orgánica de Protección de Datos 51

LSSI: Ley de Servicios de la Sociedad de la Información 51

MADEJA: Marco de Desarrollo de la Junta de Andalucía 27

MÉTRICA: Estándar de Desarrollo software del Gobierno de España 2

MIC: Manual Básico de Instalación y Configuración 9

MOD: Informe de Modelo de Datos 66

MUS: Manual de Usuario 9

91


OAC: Oficina de Aseguramiento de la Calidad 2

PDI: Personal Docente e Investigador 22

PES: Informe de Pruebas Estáticas 67

PP.FF: Preguntas Frecuentes 38

PP: Plan de Pruebas 9

PPA: Plan de Pruebas de Aceptación 30

PPF: Plan de Pruebas Funcionales 34

PPI: Plan de Pruebas de Integración 34

PPNF: Plan de Pruebas No Funcionales 34

PPS: Plan de Pruebas de Sistema 34

PPU: Plan de Pruebas Unitarias 34

RAU: Responsable del Área Usuaria 3

RC: Requisito de Conducta 28

RE: Requisito de Entorno Tecnológico 28

RF: Requisito Funcional 28

RFI: Requisito de Fiabilidad 28

RGCE: Reglamento General de la Contratación del Estado 14

RI: Requisito de Interfaz 28

RIN: Requisito de Información 28

RM: Requisito de Mantenibilidad 28

RN: Regla de Negocio 28

RNF: Requisito No Funcional / Técnico 28

RO: Otros Requisitos 28

RR: Requisito de Rendimiento y Disponibilidad 28

RS: Requisito de Seguridad 28

RU: Requisito de Usabilidad 28

SAC: Sistema de Aseguramiento de la Calidad 2

SCR: Scripts 35

SFW: Software 1

SOAP: Simple Object Access Protocol „Protocolo de Acceso a Objetos Simples‟). 84

TFG: Trabajo de Fin de Grado 1

UML: Unified Modeling Language „Lenguaje Unificado de Modelado‟). 80

UNE: Una Norma Española 2, 87

WSDL: Web Services Description Language „Lenguage de Descripción de Servicios Web‟ 84

Glosario

92

92

trabajo fin de grado - servidor de la biblioteca de...

Documents