UNIVERSIDAD CENTRAL DEL ECUADOR … · administración pública con criterios de calidad y excelencia, con la aplicación de buenas prácticas y con la adopción de estándares internacionales”

QUITO - MAYO 2016

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA DE INGENIERIA INFORMÁTICA

SISTEMA INFORMÁTICO DE GESTIÓN DE CALIDAD PARA LA EMPRESA

ELÉCTRICA QUITO

TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE

INGENIERO INFORMÁTICO

AUTORES: MORALES ALMEIDA NELSON DAVID

TIERRA JIMÉNEZ JOSÉ VINICIO

TUTOR: ING. MORALES CARDOSO JORGE ARTURO

ii

AGRADECIMIENTOS

A nuestros padres, a quienes les debemos este logro, quienes siempre nos apoyaron

desde el inicio de nuestras carreras, tanto en lo económico como en lo moral, a nuestros

seres queridos que están en el cielo que sabemos que desde ahí, han visto y apoyado

cada uno de nuestros pasos.

A nuestros compañeros de universidad y compañeros de trabajo, tutor, amigos y todas

las personas que han creído en nosotros, y que de una u otra forma han ayudado a la

culminación de este trabajo.

iii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL

Nosotros, Nelson David Morales Almeida y José Vinicio Tierra Jiménez en calidad de

autores del proyecto integrador: Sistema Informático de Gestión de Calidad para la

Empresa Eléctrica Quito, autorizamos a la Universidad Central del Ecuador hacer uso

de todos los contenidos que nos pertenecen o parte de los que contiene esta obra, con

fines estrictamente académicos o de investigación.

Los derechos que como autores nos corresponden, con excepción de la presente

autorización, seguirán vigentes a nuestro favor, de conformidad con lo establecido en

los artículos 5, 6, 8, 19 y demás pertinentes de la Ley de Propiedad Intelectual y su

Reglamento.

Quito, 6 de Mayo de 2016

Morales Almeida Nelson David

C.C.: 1719566083

Teléf.: 0995585914

C. E.: [email protected]

Quito, 6 de Mayo de 2016

Tierra Jiménez José Vinicio

C.C.: 1717735169

Teléf.: 0995664030

C. E.: [email protected]

iv

APROBACIÓN DEL TUTOR DEL TRABAJO DE TITULACIÓN

Yo, Ingeniero Jorge Arturo Morales Cardoso en calidad de tutor del trabajo de titulación

Sistema Informático de Gestión de Calidad para la Empresa Eléctrica Quito, elaborado

por los estudiantes Nelson David Morales Almeida y José Vinicio Tierra Jiménez de la

Carrera de Ingeniería Informática, Facultad de Ingeniería, Ciencias Físicas y Matemática

de la Universidad Central del Ecuador, considero que el mismo reúne los requisitos y

méritos necesarios en el campo metodológico y en el campo epistemológico, para ser

sometido a la evaluación por parte del jurado examinador que se designe, por lo que lo

APRUEBO, a fin de que el proyecto integrador sea habilitado para continuar con el

proceso de titulación determinado por la Universidad Central del Ecuador.

En la ciudad de Quito, a los treinta días del mes Marzo de 2016.

Ing. Jorge Arturo Morales Cardoso

C.C. 1705094784

v

RESULTADOS DE REVISIÓN

vi

vii

CONTENIDO

pág.

LISTA DE TABLAS ...................................................................................................... xi

LISTA DE FIGURAS ................................................................................................... xiv

LISTA DE ANEXOS ................................................................................................... xvii

RESUMEN ................................................................................................................ xviii

ABSTRACT ................................................................................................................ xix

INTRODUCCIÓN .......................................................................................................... 1

1. MARCO CONCEPTUAL ........................................................................................... 3

1.1 Aplicación Web ....................................................................................................... 3

1.2 Evolución de las aplicaciones web .......................................................................... 3

1.3 Ventajas de las aplicaciones web ........................................................................... 6

1.4 El patrón Modelo-Vista-Controlador (MVC) ............................................................. 6

1.4.1 Modelo ................................................................................................................. 6

1.4.2 Vista ..................................................................................................................... 6

1.4.3 Controlador .......................................................................................................... 6

1.5 Funcionamiento del patrón MVC ............................................................................. 7

viii

1.6 Spring 1.3 ............................................................................................................... 8

1.6.1 Servicios enterprise ............................................................................................. 9

1.6.2 Estereotipos configurables ................................................................................... 9

1.6.3 Inyección de dependencias .................................................................................. 9

1.7 Herramientas utilizadas en el desarrollo ................................................................. 9

1.7.1 Java JDK 1.7 ..................................................................................................... 10

1.7.2 JBoss EAP6 ....................................................................................................... 10

1.7.3 Hibernate 2.1 ..................................................................................................... 11

1.7.4 Maven 3.0 .......................................................................................................... 11

1.7.5 PrimeFaces 5.3 .................................................................................................. 12

1.7.6 Oracle Database 11G ........................................................................................ 12

1.7.7 Spring Tool Suite 3.7.3 ....................................................................................... 13

1.7.8 Toad for Oracle 12 ............................................................................................. 13

1.7.9 Enterprise Architect 11 ....................................................................................... 14

1.7.10 Bizagi Process Modeler 2.7 .............................................................................. 14

1.7.11 Business Intelligence and Reporting Tools 4.5 ................................................. 14

2. SISTEMA DE GESTIÓN DE CALIDAD ................................................................... 15

2.1 Sistema de Gestión de la Calidad Norma ISO 9001 .............................................. 16

2.2 Sistema Informático de Gestión de Calidad en la Empresa Eléctrica Quito ........... 17

ix

3. PROCESO RACIONAL UNIFICADO RUP .............................................................. 19

3.1 Dimensiones ......................................................................................................... 19

3.2 Principios de desarrollo ......................................................................................... 20

3.3 Principales características .................................................................................... 21

3.4 Fases .................................................................................................................... 22

3.4.1 Fase de Inicio .................................................................................................... 22

3.4.2 Fase de Elaboración .......................................................................................... 22

3.4.3 Fase de Desarrollo ............................................................................................. 22

3.4.4 Fase de Transición (cierre) ................................................................................ 23

3.5 Ciclo de vida ......................................................................................................... 23

3.6 Artefactos ............................................................................................................. 23

3.6.1 Especificación de Requisitos .............................................................................. 24

3.6.2 Diagramas de caso de uso ................................................................................ 28

3.6.3 Mapa de procesos modulo procesos .................................................................. 64

3.6.4 Mapa de procesos módulo control de documentos ............................................ 65

3.6.5 Modelo de dominio ............................................................................................. 66

3.6.6 Diagrama de clases ........................................................................................... 67

3.6.7 Modelo E-R ........................................................................................................ 68

3.6.8 Arquitectura de la aplicación. ............................................................................. 69

x

3.7 Ventajas ................................................................................................................ 70

3.8 Desventajas .......................................................................................................... 70

4. CONCLUSIONES ................................................................................................... 71

5. RECOMENDACIONES ........................................................................................... 73

BIBLIOGRAFÍA ........................................................................................................... 74

ANEXOS ..................................................................................................................... 75

xi

LISTA DE TABLAS

pág.

Tabla 1. Reglas de negocio ........................................................................................ 24

Tabla 2. Requisitos no funcionales ............................................................................. 24

Tabla 3. Requisitos funcionales gestión catálogos ...................................................... 25

Tabla 4. Requisitos funcionales gestión de procesos .................................................. 25

Tabla 5. Requisitos funcionales gestión de documentos ............................................. 26

Tabla 6. Requisitos funcionales gestión de reportes ................................................... 28

Tabla 7. Especificaciones iniciar sesión ...................................................................... 30

Tabla 8. Especificaciones cerrar sesión ...................................................................... 31

Tabla 9. Especificaciones recuperar contraseña ......................................................... 32

Tabla 10. Especificaciones gestionar catálogo procesos y subprocesos..................... 33

Tabla 11. Especificaciones consultar proceso / subproceso ....................................... 34

Tabla 12. Especificaciones crear proceso ................................................................... 35

Tabla 13. Especificaciones crear subproceso ............................................................. 36

Tabla 14. Especificaciones editar proceso / subproceso ............................................. 37

Tabla 15. Especificaciones desactivar proceso / subproceso ...................................... 38

Tabla 16. Especificaciones gestionar proceso ............................................................ 40

xii

Tabla 17. Especificaciones consultar proceso (matriz de caracterización) .................. 41

Tabla 18. Especificaciones crear matriz de caracterización ........................................ 41

Tabla 19. Especificaciones editar proceso (matriz de caracterización) ....................... 43

Tabla 20. Especificaciones desactivar proceso (matriz de caracterización) ................ 44

Tabla 21. Especificaciones revisar proceso (revisor) .................................................. 45

Tabla 22. Especificaciones revisar proceso (dpto. sistemas de calidad) ..................... 46

Tabla 23. Especificaciones aprobar proceso (matriz de caracterización) .................... 47

Tabla 24. Especificaciones gestionar documentos ...................................................... 49

Tabla 25. Especificaciones consultar documentos internos ........................................ 50

Tabla 26. Especificaciones crear documento interno .................................................. 50

Tabla 27. Especificaciones editar documento interno ................................................. 52

Tabla 28. Especificaciones desactivar documento interno .......................................... 53

Tabla 29. Especificaciones revisar documento interno (revisor) .................................. 54

Tabla 30. Especificaciones revisar documento interno ................................................ 55

Tabla 31. Especificaciones aprobar documento interno .............................................. 56

Tabla 32. Especificaciones consultar documentos externos ....................................... 58

Tabla 33. Especificaciones crear documento externo ................................................. 59

Tabla 34. Especificaciones editar documento externo ................................................ 60

Tabla 35. Especificaciones desactivar documentos externos ...................................... 61

xiii

Tabla 36. Especificaciones consultar documentos aprobados .................................... 63

xiv

LISTA DE FIGURAS

pág.

Figura 1. HTML estático ................................................................................................ 4

Figura 2. Aplicaciones web ........................................................................................... 5

Figura 3. Funcionamiento del patrón modelo-vista-controlador ..................................... 7

Figura 4. Logo framework Spring .................................................................................. 8

Figura 5. Logo Java .................................................................................................... 10

Figura 6. Logo JBoss .................................................................................................. 10

Figura 7. Logo Hibernate ............................................................................................ 11

Figura 8. Logo Maven ................................................................................................. 11

Figura 9. Logo PrimeFaces ......................................................................................... 12

Figura 10. Logo Oracle Database ............................................................................... 13

Figura 11. Logo Spring Tool Suite............................................................................... 13

Figura 12. Logo Toad.................................................................................................. 13

Figura 13. Logo Enterprise Architect ........................................................................... 14

Figura 14. Logo Bizagi Modeler .................................................................................. 14

Figura 15. Logo SNAP ................................................................................................ 15

Figura 16. Logo ISO 9001 ........................................................................................... 15

xv

Figura 17. Modelo de un sistema de gestión de la calidad basado en procesos ......... 16

Figura 18. Diagrama de contexto SIGC ...................................................................... 17

Figura 19. Logo UML y RUP ....................................................................................... 19

Figura 20. Esquema RUP ........................................................................................... 20

Figura 21. Caso de uso 1 sesiones ............................................................................. 32

Figura 22. Interfaz 1 sesiones ..................................................................................... 32

Figura 23. Caso de uso 2 catálogos ............................................................................ 39

Figura 24. Caso de uso 3 listas ................................................................................... 39

Figura 25. Caso de uso 4 crear proceso - subproceso ................................................ 39

Figura 26. Caso de uso 5 desactivar proceso - subproceso ........................................ 39

Figura 27. Interfaz 2 gestionar catálogos .................................................................... 39

Figura 28. Caso de uso 6 gestionar matriz de caracterización .................................... 48

Figura 29. Caso de uso 7 listado matriz de caracterización ....................................... 48

Figura 30. Caso de uso 8 revisar matriz de caracterización ........................................ 48

Figura 31. Caso de uso 9 aprobar matriz de caracterización ...................................... 48

Figura 32. Interfaz 3 gestionar matriz de caracterización ............................................ 48

Figura 33. Caso de uso 10 gestionar documentos internos......................................... 57

Figura 34. Caso de uso 11 listado documentos internos ............................................. 57

Figura 35. Caso de uso 12 revisar documentos internos ............................................ 57

xvi

Figura 36. Caso de uso 13 aprobar documentos internos ........................................... 57

Figura 37. Interfaz 4 gestionar documentos internos .................................................. 57

Figura 38. Caso de uso 14 gestionar documentos externos........................................ 62

Figura 39. Interfaz 5 gestionar documentos externos.................................................. 62

Figura 40. Caso de uso 15 generar reportes ............................................................... 63

Figura 43. Mapa de procesos módulo de procesos SIGC ........................................... 64

Figura 44. Mapa de procesos modulo control de documentos SIGC .......................... 65

Figura 45. Modelo de dominio SIGC ........................................................................... 66

Figura 41. Diagrama de clases SIGC .......................................................................... 67

Figura 42. Modelo entidad relación SIGC ................................................................... 68

Figura 46. Arquitectura de la aplicación SIGC............................................................ 69

xvii

LISTA DE ANEXOS

pág.

Anexo A ...................................................................................................................... 76

Anexo B ...................................................................................................................... 81

xviii

RESUMEN

SISTEMA INFORMÁTICO DE GESTIÓN DE CALIDAD PARA LA EMPRESA

ELÉCTRICA QUITO

Autores: Morales Almeida Nelson David


Tutor: Ing. Morales Cardoso Jorge Arturo

La implementación del Sistema Informático de Gestión de Calidad ha permitido obtener

un mejoramiento en el proceso que conlleva la gestión de calidad, para lo cual se ha

utilizado la metodología de desarrollo RUP, que ha hecho un importante aporte puesto

que el análisis y diseño de la aplicación mencionada anteriormente fue realizada de una

forma estructurada y apropiada para obtener resultados exitosos los mismos que

describen el sistema desde diferentes perspectivas orientadas a los diferentes

involucrados en un proyecto. Y una de las mayores ventajas de utilizar esta metodología

de desarrollo es la reducción de riesgos, la garantía de calidad y la integración entre el

desarrollo y mantenimiento del software (a base de ir iterando en cada fase,

combinando actividades de uno y otro tipo).

PALABRAS CLAVES: SISTEMA INFORMÁTICO / SISTEMA DE CALIDAD /

METODOLOGÍA RUP / REDUCCIÓN DE RIESGOS / ESTRUCTURA DE SOFTWARE

/ DESARROLLO DE SOFTWARE / MANTENIMIENTO DE SOFTWARE

xix

ABSTRACT

COMPUTER SYSTEM QUALITY MANAGEMENT FOR EMPRESA ELÉCTRICA

QUITO

Authors: Morales Almeida Nelson David


Tutor: Ing. Morales Cardoso Jorge Arturo

The implementation of the Computer System Quality Management has allowed us to

obtain an improvement in the process that involves the management of quality, and has

used the RUP development methodology, this has made an important contribution since

the analysis and design of the application mentioned above it was carried out in a

structured way and appropriate to obtain successful results, which describe the system

from different perspectives aimed at the different stakeholders in a project. And one of

the biggest advantages of using this methodology of development is the reduction of risk,

the guarantee of quality and the integration between the development and maintenance

of the software (on the basis of going to iterate at each stage, combining activities of both

types).

KEYWORDS: COMPUTER SYSTEM / QUALITY SYSTEM / METHODOLOGY RUP /

RISK REDUCTION / STRUCTURE OF SOFTWARE / SOFTWARE DEVELOPMENT /

SOFTWARE MAINTENANCE

I CERTIFY that the above and foregoing is a true and correct translation of the original

document in Spanish.

___________________________

Ponce Pinargote Diana Elizabeth

Certified Translator

ID: 1304881327 (1009-02-212581)

1

INTRODUCCIÓN

Desde el año 2007 se ha procurado sistematizar el proceso de gestión de la calidad,

proyecto que por diferentes motivos no ha logrado concretarse. El Sistema de Gestión

de la Calidad en la actualidad es un requerimiento del Plan Nacional para el Buen Vivir

2013 - 2017 que en el Objetivo 1, se refiere a Consolidar el Estado democrático y la

construcción del poder popular, establece políticas y lineamientos estratégicos; en el

literal 1.5 se refiere a Afianzar una gestión pública inclusiva, oportuna, eficiente, eficaz

y de excelencia, en el literal b) señala que se debe: “Estandarizar procedimientos en la

administración pública con criterios de calidad y excelencia, con la aplicación de buenas

prácticas y con la adopción de estándares internacionales”. En ese mismo contexto en

el literal c) determina que se debe: “Implementar y mantener sistemas de gestión de la

calidad y la excelencia basados en normativas reconocidas internacionalmente”.

En la actualidad toda la información del Sistema de Gestión de la Calidad relacionada

con el control operacional, de las diferentes actividades significativas de procesos que

se desarrollan en la Empresa Eléctrica Quito (EEQ) están desarrolladas bajo el esquema

de procedimientos e instructivos, éstos se deben actualizar cada vez que se producen

cambios significativos en aspectos administrativos, técnicos, tecnológicos entre otros.

Estos documentos deben pasar por las etapas de elaboración, revisión y aprobación por

diferentes niveles de autoridades de la Empresa, en forma impresa y tramitada vía

conserjería, provocando dificultades y pérdida de recursos que estas acciones generan

en la actualidad. Lo señalado se podría optimizar a través del desarrollo de un software

que se adapte a las características de la documentación del Sistema de Gestión de la

Calidad (SGC) de la Institución y en forma específica del control operacional de los

procesos y subprocesos.

Cabe señalar que en la actualidad varios procedimientos e instructivos se están

actualizando para cumplir con los requerimientos del Esquema Gubernamental de

Seguridad de la Información (EGSI) que tiene relación con el Sistema de Gobierno por

Resultados (GPR).

2

El Sistema de Gestión de la Calidad debe ser evaluado en forma periódica y el estándar

nacional e internacional que se utiliza con este propósito son las Auditorías Internas de

la Calidad, que es un proceso sistemático, independiente y documentado para obtener

evidencias y evaluarlas de manera objetiva, con el fin de determinar el grado de

cumplimiento de los requisitos normativos, legales y reglamentarios. Como productos

de la Auditoría Interna del Sistema de Gestión de la Calidad (SGC) se generan Informes,

que contienen no conformidades y observaciones.

La planificación, ejecución y seguimiento de las Auditorías Internas y el tratamiento de

las no conformidades y observaciones, son gestionadas por el personal del

Departamento de Sistema de Calidad a través de documentos impresos y archivados

en forma física en lugares destinados para el efecto, lo que genera ciertos riesgos como

pérdida de documentos, protección adecuada y recuperación de los mismos. Lo que

ocasiona inconvenientes y el desperdicio de recursos que se podrían eliminar a través

del uso de un software que se adapte a los requerimientos del Sistema de Gestión de

la Calidad de la EEQ.

Considerando que lo señalado son elementos que justifican la necesidad de desarrollar

un software que ayude a la optimización de recursos y sistematice el proceso de Gestión

de la Calidad, tomando en cuenta además el tiempo transcurrido y la información

generada en los proyectos anteriores de sistematización del sistema de gestión de la

calidad.

De acuerdo a lo mencionado anteriormente el Sistema Informático de Gestión de

Calidad constara de seis módulos que se establecieron mediante análisis de la

documentación y entrevistas realizadas con los usuarios, los cuales son Módulo de

Procesos, Módulo de Control de Documentos, Módulo de Control de Registros, Módulo

de Acciones Correctivas y Mejora, Módulo de Auditoria y Módulo de Revisión por la

Dirección. En el presente trabajo se presenta el desarrollo de los dos primeros módulos

respectivamente, en los cuales se abarca el análisis, diseño e implementación mediante

realización de casos de uso, diagramas de flujo, modelos de negocio; utilizando

metodología RUP para lograr construir un software de alta calidad que satisfaga las

necesidades de sus usuarios finales dentro de un presupuesto y tiempo predecibles,

logrando así una correcta sistematización del proceso de gestión de calidad.

3

1. MARCO CONCEPTUAL

1.1 Aplicación Web

Hoy en día, resulta bastante común implementar la interfaz de una aplicación utilizando

páginas web en vez de las ventanas y los controles específicos de un sistema operativo

concreto. En lugar de escribir una aplicación para un sistema operativo concreto, como

puede ser Windows, en muchas situaciones es preferible crear aplicaciones web a las

que se accede a través de Internet.

Se denominan aplicaciones web a aquellas aplicaciones cuya interfaz se construye a

partir de páginas web. Las páginas web no son más que ficheros de texto en un formato

estándar denominado HTML1. Estos ficheros se almacenan en un servidor web al cual

se accede utilizando por ejemplo el protocolo HTTP2, uno de los protocolos de Internet.

El usuario podrá acceder a nuestra aplicación desde cualquier plataforma y nosotros

podremos implementarla utilizando todos los recursos disponibles en la plataforma que

elijamos para albergarla, sin restricciones innecesarias

1.2 Evolución de las aplicaciones web

Inicialmente la web era simplemente una colección de páginas estáticas, documentos,

etc., que podían consultarse o descargarse. El siguiente paso en su evolución fue la

inclusión de un método para confeccionar páginas dinámicas que permitiesen que lo

mostrado fuese dinámico (generado o calculado a partir de los datos de la petición.

Inicialmente, las páginas web se limitaban a contener documentos almacenados en

formato HTML. Dichos documentos no son más que ficheros de texto a los que se le

añaden una serie de etiquetas. Dichas etiquetas delimitan fragmentos del texto que han

de aparecer en un formato determinado y también sirven para crear enlaces de un

1 HyperText Markup Language (lenguaje de marcas de hipertexto) 2 HyperText Transfer Protocol (protocolo de transferencia de hipertexto)

4

documento a otro (o, incluso, de una parte de un documento a otra parte del mismo

documento).

Con unos conocimientos mínimos de HTML, crear un sitio web resulta relativamente

sencillo. Sólo hay que preparar los documentos HTML tal y como queramos que los

visualicen los visitantes de nuestra página. Cuando podemos predecir con antelación

cuál es la información que tenemos que mostrarle al usuario, crear una página web

estática resulta la opción más sencilla.

Si bien esta forma de construir un sitio web puede ser suficiente para muchas

aplicaciones, en ocasiones necesitaremos que el contenido de nuestra página web se

genere dinámicamente en función de las necesidades y deseos de nuestros usuarios.

Cuando nos interesa algo más que mostrar siempre los mismos datos de la misma

forma, tener que actualizar periódicamente los ficheros HTML no siempre es una buena

idea. El inconveniente de utilizar simples ficheros HTML es que estos ficheros son

estáticos y, mientras no los actualicemos de forma manual o automática, mostrarán

siempre la misma información independientemente de quién acceda a nuestra página.

Por ejemplo, si lo que queremos es construir una página web cuyo contenido cambie en

función del usuario que la visite y de la tarea que desee realizar, la solución pasa

ineludiblemente por generar dinámicamente los documentos HTML cada vez que le

llega una solicitud a nuestro servidor HTTP. Éste es el principio de funcionamiento de

las aplicaciones web.

Configuración típica de una "aplicación web" que se limita a ofrecer la información

almacenada en páginas HTML a las que el usuario final accede desde su navegador

web utilizando el protocolo HTTP. Ver Figura 1.

Figura 1. HTML estático (Berzal, 2005)

Aunque la utilización de documentos HTML estáticos puede ser la solución más

adecuada cuando nuestra página web se limite a ofrecer siempre la misma información

5

o podamos automatizar la realización de actualizaciones de los documentos HTML que

la constituyen, la naturaleza dinámica de la web y las expectativas que ha creado en la

actualidad hacen necesaria la implementación de aplicaciones web que generen

dinámicamente el contenido que finalmente se les ofrece a los usuarios. De esta forma

podemos seleccionar, filtrar, ordenar y presentar la información de la forma más

adecuada en función de las necesidades de cada momento. Si bien esto se podría

conseguir con páginas HTML estáticas si dispusiésemos de espacio suficiente en disco

(y, de hecho, esta es una estrategia que se utiliza para disminuir la carga de la CPU3 de

los servidores), las aplicaciones web nos permiten ofrecer la información más actual de

la que disponemos al poder acceder directamente a las bases de datos que contienen

los datos operativos de una empresa.

La creación de aplicaciones web, en consecuencia, requiere la existencia de software

ejecutándose en el servidor que genere automáticamente los ficheros HTML que se

visualizan en el navegador del usuario. Exactamente igual que cuando utilizábamos

páginas estáticas en formato HTML, la comunicación entre el cliente y el servidor se

sigue realizando a través del protocolo HTTP. La única diferencia consiste en que,

ahora, el servidor HTTP delega en otros módulos la generación dinámica de las páginas

HTML que se envían al cliente. Ya que, desde el punto de vista del cliente, la conexión

se realiza de la misma forma y él sigue recibiendo páginas HTML estándar (aunque

éstas hayan sido generadas dinámicamente en el servidor), el navegador del cliente es

independiente de la tecnología que se utilice en el servidor para generar dichas páginas

de forma dinámica.

El contenido que se le muestra al usuario se genera dinámicamente para cada solicitud

proveniente del navegador web instalado en la máquina cliente. Ver Figura 2.

Figura 2. Aplicaciones web (Berzal, 2005)

3 Central Processing Unit (unidad central de procesamiento)

6

1.3 Ventajas de las aplicaciones web

Las aplicaciones web tienen varias ventajas sobre las aplicaciones tradicionales:

Compatibilidad

o Las aplicaciones web utilizan el navegador del cliente como interfaz de

usuario

o El lenguaje HTML garantiza la compatibilidad en distintas plataformas

Accesibilidad

o Los dispositivos móviles están generalmente soportados

o Hay muchas soluciones a nivel de navegador para personas con

discapacidad:

Lectores automáticos de texto

Gran variedad de dispositivos de entrada (teclados, ratones)

Tamaños y colores de texto ajustables

1.4 El patrón Modelo-Vista-Controlador (MVC)

El patrón MVC es un patrón de arquitectura de software encargado de separar la lógica

de negocio de la interfaz del usuario y es el más utilizado en aplicaciones Web, ya que

facilita la funcionalidad, mantenimiento y escalabilidad del sistema, de forma simple y

sencilla, a la vez que permite “no mezclar lenguajes de programación en el mismo

código”.

MVC divide las aplicaciones en tres niveles de abstracción:

1.4.1 Modelo

Representa la lógica de negocios. Es el encargado de acceder de forma directa a los

datos actuando como “intermediario” con la base de datos.

1.4.2 Vista

Es la encargada de mostrar la información al usuario de forma gráfica y legible.

1.4.3 Controlador

Es el intermediario entre la vista y el modelo. Es quien controla las interacciones del

usuario solicitando los datos al modelo y entregándolos a la vista para que ésta, lo

presente al usuario, de forma legible.

7

1.5 Funcionamiento del patrón MVC

El funcionamiento básico del patrón MVC (Figura 3.), puede resumirse en:

El usuario realiza una petición

El controlador captura el evento

Hace la llamada al modelo/modelos correspondientes efectuando las

modificaciones pertinentes sobre el modelo

El modelo será el encargado de interactuar con la base de datos, ya sea en forma

directa, con una capa de abstracción para ello, un Web Service4, etc. Y retornará

esta información al controlador

El controlador recibe la información y la envía a la vista

La vista, procesa esta información, creando una capa de abstracción para la

lógica (quien se encargará de procesar los datos) y otra para el diseño de la

interfaz gráfica o GUI.

Figura 3. Funcionamiento del patrón modelo-vista-controlador (Berzal, 2005)

4 Un servicio web es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.

8

1.6 Spring 1.3

Spring es un framework5 alternativo al stack6 de tecnologías estándar en aplicaciones

JavaEE7. Nació en una época en la que las tecnologías estándar JavaEE y la visión

"oficial" de lo que debía ser una aplicación Java Enterprise tenían todavía muchas

aristas por pulir. Los servidores de aplicaciones eran monstruosos devoradores de

recursos y los EJB eran pesados, inflexibles y era demasiado complejo trabajar con

ellos. En ese contexto, Spring popularizó ideas como la inyección de dependencias o el

uso de objetos convencionales (POJOs) como objetos de negocio, que suponían un

soplo de aire fresco. Estas ideas permitían un desarrollo más sencillo y rápido y unas

aplicaciones más ligeras. Eso posibilitó que de ser un framework inicialmente diseñado

para la capa de negocio pasara a ser un completo stack de tecnologías para todas las

capas de la aplicación.

Figura 4. Logo framework Spring

Las ideas "innovadoras" que en su día popularizó Spring se han incorporado en la

actualidad a las tecnologías y herramientas estándar. Así, ahora mismo no hay una gran

diferencia entre el desarrollo con Spring y el desarrollo JavaEE "estándar", o al menos

no tanta como hubo en su día. No obstante, Spring ha logrado aglutinar una importante

comunidad de desarrolladores en torno a sus tecnologías y hoy por hoy sigue

constituyendo una importante alternativa al estándar que merece la pena conocer. En la

actualidad, las aportaciones más novedosas de Spring se centran en los campos de Big

Data/NoSQL, HTML5/móviles y aplicaciones sociales.

5 Entorno o ambiente de trabajo para desarrollo 6 Pila de cosas o apilamiento 7 La plataforma Java Enterprise Edition son un conjunto de especificaciones que facilitan el desarrollo y despliegue de aplicaciones empresariales multi-capa.

9

Las tecnologías JavaEE más sofisticadas requieren del uso de un servidor de

aplicaciones, ya que los APIs los implementa el propio servidor, mientras que Spring no

es más que un conjunto de librerías portables entre servidores. En otras palabras,

usando JavaEE estándar, nos atamos al servidor de aplicaciones y usando Spring nos

atamos a sus APIs.

Desde un punto de vista genérico, Spring se puede ver como un soporte que nos

proporciona tres elementos básicos:

1.6.1 Servicios enterprise

Podemos hacer de manera sencilla que un objeto sea transaccional, o que su acceso

esté restringido a ciertos roles, o que sea accesible de manera remota y transparente

para el desarrollador, o acceder a otros muchos servicios más, sin tener que escribir el

código de manera manual. En la mayoría de los casos solo es necesario anotar el objeto.

1.6.2 Estereotipos configurables

Para los objetos de nuestra aplicación: podemos anotar nuestras clases indicando por

ejemplo que pertenecen a la capa de negocio o de acceso a datos. Se dice que son

configurables porque podemos definir nuestros propios estereotipos "a medida": por

ejemplo podríamos definir un nuevo estereotipo que indicara un objeto de negocio que

además sería cacheable8 automáticamente y con acceso restringido a usuarios con

determinado rol.

1.6.3 Inyección de dependencias

La inyección de dependencias nos permite solucionar de forma sencilla y elegante cómo

proporcionar a un objeto cliente acceso a un objeto que da un servicio que este necesita.

Por ejemplo, que un objeto de la capa de presentación se pueda comunicar con uno de

negocio. En Spring las dependencias se pueden definir con anotaciones o con XML9.

1.7 Herramientas utilizadas en el desarrollo

Para el desarrollo de la aplicación se ha utilizado un conjunto de herramientas que

permite utilizar todo el potencial de las tecnologías antes mencionadas

8 Almacenable en la memoria caché 9 Lenguaje de Etiquetado Extensible

10

1.7.1 Java JDK 1.7

Java es un lenguaje de programación de propósito general, concurrente, orientado a

objetos que fue diseñado específicamente para tener tan pocas dependencias de

implementación como fuera posible. Su intención es permitir que los desarrolladores de

aplicaciones escriban el programa una vez y lo ejecuten en cualquier dispositivo, lo que

quiere decir que el código que es ejecutado en una plataforma no tiene que ser

recompilado para correr en otra. Java es, a partir de 2012, uno de los lenguajes de

programación más populares en uso, particularmente para aplicaciones de cliente-

servidor de web, con unos 10 millones de usuarios reportados.

Figura 5. Logo Java

1.7.2 JBoss EAP6

JBoss Enterprise Application Platform es un servidor de aplicaciones Java EE de código

abierto implementado en Java puro. Al estar basado en Java, JBoss puede ser utilizado

en cualquier sistema operativo para el que esté disponible la máquina virtual de Java.

La Plataforma de Aplicaciones JBoss Enterprise está certificada para su ejecución en

múltiples máquinas virtuales y sistemas operativos incluyendo Red Hat Enterprise

Linux, otras distribuciones Linux, Unix, y Windows, y es compatible con las bases de

datos más utilizadas de la industria. La Plataforma de Aplicaciones JBoss Enterprise

está integrada y preparada para un mayor rendimiento desde el principio, para

ambientes de producción crítica de las empresas. Al integrar tecnologías Java EE y

Web 2.0 como Hibernate y Seam en el servidor JBoss Application Server, la Plataforma

de Aplicaciones JBoss Enterprise es la solución completa para aplicaciones Java.

Figura 6. Logo JBoss

11

1.7.3 Hibernate 2.1

La tecnología líder en persistencia y mapeo relacional-objeto (ORM) Hibernate

soluciona las complicaciones ORM directamente, proporcionando la capacidad de

mapear la representación de datos de un modelo de objetos a un modelo de datos

relacional y correspondiendo con los esquemas de la base de datos.

Figura 7. Logo Hibernate

Hibernate no sólo ofrece la posibilidad de mapear Java a tablas de bases de datos, y de

datos Java a datos SQL10, sino que también proporciona funcionalidades de consulta y

recuperación de datos que reducen significativamente el tiempo de desarrollo.

Hibernate libera a los desarrolladores de aplicaciones de las comunes tareas de

programación de persistencia de datos, eliminando la necesidad de procesamiento de

datos manual mediante el uso de SQL y JDBC11.

1.7.4 Maven 3.0

Es una herramienta de gestión de proyectos. Se basa en un fichero central, pom.xml,

donde se define todo lo que necesita un proyecto. Maven maneja las dependencias del

proyecto, compila, empaqueta y ejecuta los test. Mediante plugins, permite hacer mucho

más, como por ejemplo generar los mapas de Hibernate a partir de una base de datos,

desplegar la aplicación, etc.

Figura 8. Logo Maven

10 (Structured Query Language) es un lenguaje de programación diseñado para almacenar, manipular y recuperar datos almacenados en bases de datos relacionales. 11 (Java Database Connectivity) es una interface de acceso a bases de datos estándar SQL que proporciona un acceso uniforme a una gran variedad de bases de datos relacionales.

12

1.7.5 PrimeFaces 5.3

Es una librería de componentes para Java Server Faces (JSF) de código abierto que

cuenta con un conjunto de componentes enriquecidos que facilitan la creación de las

aplicaciones web. Primefaces está bajo la licencia de Apache License V2. Una de las

ventajas de utilizar Primefaces, es que permite la integración con otros componentes.

Figura 9. Logo PrimeFaces

Cuenta con las siguientes propiedades:

Conjunto de componentes ricos (Editor de HTML, autocompletar, cartas, gráficas

o paneles, entre otros).

Soporte de ajax12 con despliegue parcial, lo que permite controlar qué

componentes de la página actual se actualizarán y cuáles no.

25 temas prediseñados

Componente para desarrollar aplicaciones web para teléfonos móviles,

especiales para iPhones, Palm, Android y teléfonos móviles Nokia.

En cuanto a la experiencia de los usuarios finales los componentes de Primefaces son

amigables al usuario además que cuentan con un diseño innovador. Pero en lo que

respecta al programador, es que sus desarrolladores no respetan un principio básico del

desarrollo de componentes: la compatibilidad hacia atrás, es decir, un componente de

una nueva versión de Primefaces por lo general no es compatible al 100% con una

aplicación desarrollada con la versión previa a la misma

1.7.6 Oracle Database 11G

Oracle Database es un sistema de gestión de base de datos de tipo objeto-relacional

(ORDBMS, por el acrónimo en inglés de Object-Relational Data Base Management

System), desarrollado por Oracle Corporation.

12 Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas.

13

Figura 10. Logo Oracle Database

Considerado como uno de los sistemas de bases de datos más completos, destacando:

soporte de transacciones, estabilidad, escalabilidad, y soporte multiplataforma.

1.7.7 Spring Tool Suite 3.7.3

Es un entorno de desarrollo basado en Eclipse13 que se personaliza para desarrollar

aplicaciones Spring.

Figura 11. Logo Spring Tool Suite

Soporta el despliegue de aplicaciones tanto en servidores locales, virtuales y en la nube.

De código abierto y licenciada bajo los términos de la Licencia Pública Eclipse.

1.7.8 Toad for Oracle 12

Es una aplicación informática de desarrollo SQL y administración de base de datos,

considerada una herramienta útil para los Oracle DBAs (administradores de base de

datos). Actualmente está disponible para las siguientes bases de datos: Oracle

Database, Microsoft SQL Server, IBM DB2, y MySQL.

Figura 12. Logo Toad

13 Plataforma de software compuesto por un conjunto de herramientas de programación de código abierto multiplataforma.

14

1.7.9 Enterprise Architect 11

Provee modelado del ciclo de vida completo para:

Sistemas de negocio e IT

Ingeniería de software y sistemas

Desarrollo en tiempo real y embebido

Figura 13. Logo Enterprise Architect

Con capacidades de gestión de requisitos, Enterprise Architect ayuda a trazar

especificaciones de alto nivel a modelos de análisis, diseño, implementación, pruebas y

mantenimiento, usando UML14,SysML15, BPMN16 y otros estándares abiertos para

modelado. Enterprise Architect es una herramienta gráfica multiusuario diseñada para

ayudar a construir sistemas robustos y mantenibles.

1.7.10 Bizagi Process Modeler 2.7

Bizagi Process Modeler es un Freeware17 utilizado para diagramar, documentar y

simular procesos usando la notación estándar BPMN.

Figura 14. Logo Bizagi Modeler

1.7.11 Business Intelligence and Reporting Tools 4.5

El proyecto Tools (BIRT) (en español, Inteligencia de negocio y herramientas de

informes) es un proyecto de software de código abierto que proporciona capacidades

de creación de informes y de inteligencia de negocio para clientes pesados (fat clients)

y aplicaciones web, especialmente aquellas basadas en Java y Java EE.

14 Lenguaje Unificado de Modelado. 15 Lenguaje de modelado de dominio específico para aplicaciones de ingeniería de sistemas. 16 Business Process Modeling Notation es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. 17 Software de aplicación propietario que es distribuido de forma gratuita.

15

2. SISTEMA DE GESTIÓN DE CALIDAD

La Norma Técnica de Administración por Procesos – SNAP 18– 2013 dice “Es una serie

de actividades coordinadas que se llevan a cabo sobre un conjunto de elementos

(recursos, procedimientos, documentos, estructura organizacional, políticas y

estrategias) para incrementar la calidad de los productos o servicios que se ofrecen al

ciudadano, beneficiario o usuario, es decir, planear, controlar y mejorar aquellos

elementos de una institución que influyen en la satisfacción del ciudadano, beneficiario

o usuario y en el logro de los resultados deseados por la organización”.

Figura 15. Logo SNAP

La Norma ISO19 9000:2005 menciona “Conjunto de elementos mutuamente

relacionados o que interactúan para establecer la política y los objetivos y para lograr

dichos objetivos para dirigir y controlar una organización con respecto al grado en el que

un conjunto de características inherentes cumple con las necesidades o expectativas

establecidas, generalmente implícita u obligatoria”.

Figura 16. Logo ISO 9001

18 Secretaría Nacional de la Administración Pública 19 Organización Internacional de Normalización

16

2.1Sistema de Gestión de la Calidad Norma ISO 9001

La Norma Internacional ISO 9001 tiene un enfoque de procesos y especifica los

requisitos mínimos que una organización debe cumplir para implementar un Sistema de

Gestión de la Calidad:

Necesita demostrar su capacidad para proporcionar regularmente productos

que satisfagan los requisitos del cliente y los legales y reglamentos aplicables.

Aspira a aumentar la satisfacción del cliente a través de la aplicación eficaz del

sistema, incluidos los procesos para la mejora continua del sistema y el

aseguramiento de la conformidad con los requisitos del cliente y los legales y

reglamentos aplicables. Ver figura 17.

Figura 17. Modelo de un sistema de gestión de la calidad basado en procesos

(Empresa Eléctrica Quito, 2015)

17

2.2 Sistema Informático de Gestión de Calidad en la Empresa Eléctrica Quito

Para automatizar la administración de ciertos requisitos de un Sistema de Gestión de la

Calidad orientado a los lineamientos de las Normas ISO 9001, se ha establecido varios

módulos, que facilitan la implementación y administración de documentos

principalmente en la elaboración, actualización y aprobación; la creación o modificación

de procesos, subprocesos y actividades; gestión de acciones correctivas y de mejora,

en especial el análisis de las causas, la evaluación de soluciones, su implementación,

seguimiento y aprobación; elaboración del programa y planes de auditorías; y revisiones

por la dirección, contempladas en un Sistema de Gestión de Calidad y que están

incluidos en los siguientes módulos:

Módulo de Procesos

Módulo de Control de Documentos

Módulo de Control de Registros

Módulo de Acciones correctivas y de mejora

Módulo de Auditoria

Módulo de Revisión por la Dirección

Figura 18. Diagrama de contexto SIGC

18

Para el presente trabajo se realizara el análisis diseño e implementación de los

siguientes módulos del SIGC20:

Módulo de Procesos: Permite crear, modificar o eliminar matrices de

caracterización asociadas a los procesos, subprocesos y actividades definidas

en la organización. Las matrices de caracterización deben pasar un proceso de

revisión previa su aprobación y publicación.

Módulo de Control de Documentos: Permite crear, modificar o eliminar

documentos internos y externos asociados a procesos y subprocesos definidos

en la organización. En los documentos externos existe la posibilidad de adjuntar

diferentes tipos de archivos de texto o imágenes. Los documentos internos

deben pasar un proceso de revisión previa su aprobación y publicación.

20 Sistema Informático de Gestión de Calidad

19

3. PROCESO RACIONAL UNIFICADO RUP

Las siglas RUP en ingles significa Rational Unified Process (Proceso Racional

Unificado) es un producto del proceso de ingeniería de software que proporciona un

enfoque disciplinado para asignar tareas y responsabilidades dentro de una

organización del desarrollo. Su meta es asegurar la producción del software de alta

calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo

establecidos.

Figura 19. Logo UML y RUP

Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar

más utilizada para el análisis, implementación y documentación de sistemas orientados

a objetos.

3.1 Dimensiones

El RUP tiene dos dimensiones:

El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida

del proceso.

El eje vertical representa las disciplinas, que agrupan actividades definidas

lógicamente por la naturaleza.

La primera dimensión representa el aspecto dinámico del proceso y se expresa en

términos de fases, de iteraciones, y la finalización de las fases. La segunda dimensión

20

representa el aspecto estático del proceso: cómo se describe en términos de

componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los

artefactos, y los roles.

En la Figura 20 se puede observar como varía el énfasis de cada disciplina en un cierto

plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteraciones

tempranas, pasamos más tiempo en requerimientos, y en las últimas iteraciones

pasamos más tiempo en poner en práctica la realización del proyecto en sí.

Figura 20. Esquema RUP (Flores, 2002)

3.2 Principios de desarrollo

El RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso: El proceso deberá adaptarse a las necesidades del cliente

ya que es muy importante interactuar con él.

Equilibrar prioridades: Los requisitos de los diversos participantes pueden ser

diferentes, contradictorios o disputarse recursos limitados.

21

Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un

modo interno, en etapas iteradas.

Colaboración entre equipos: El desarrollo de software no lo hace una única

persona sino múltiples equipos.

Elevar el nivel de abstracción: Este principio dominante motiva el uso de

conceptos reutilizables tales como patrón del software, marcos de referencia

(frameworks) por nombrar algunos.

Enfocarse en la calidad: El control de calidad no debe realizarse al final de

cada iteración, sino en todos los aspectos de la producción.

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado

ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza

las tareas en fases e iteraciones.

3.3 Principales características

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,

cuándo y cómo)

Pretende implementar las mejores prácticas en Ingeniería de Software

Desarrollo iterativo

Administración de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificación de la calidad del software

El RUP es un producto de IBM. Se caracteriza por ser iterativo e incremental, estar

centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son

los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el

código fuente, etc.) y roles (papel que desempeña una persona en un determinado

momento, una persona puede desempeñar distintos roles a lo largo del proceso).

22

3.4 Fases

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

Proceso:

o Modelado de negocio

o Requisitos

o Análisis y Diseño

o Implementación

o Pruebas

o Despliegue

Soporte

o Gestión del cambio y configuraciones

o Gestión del proyecto

o Entorno

La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo

fundamentalmente iterativo, y en esta parte se ven inmersas 4 fases:

3.4.1 Fase de Inicio

Esta fase tiene como propósito definir y acordar el alcance del proyecto con los

patrocinadores, identificar los riesgos asociados al proyecto, producir el plan de las fases

y el de iteraciones posteriores. “detalles muy generales de la arquitectura de software”.

3.4.2 Fase de Elaboración

En la fase de elaboración se diseña la solución preliminar, se seleccionan los casos de

uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase,

y el primer análisis del dominio del problema.

3.4.3 Fase de Desarrollo

El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben

clarificar los requisitos pendientes, administrar los cambios de acuerdo a las

evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

23

3.4.4 Fase de Transición (cierre)

El propósito de esta fase es asegurar que el software esté disponible para los usuarios

finales, ajustar los errores y defectos encontrados en las pruebas de aceptación,

capacitar a los usuarios y proveer el soporte técnico necesario.

3.5 Ciclo de vida

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la

comprensión del problema y la tecnología (durante la fase de inicio las iteraciones hacen

mayor énfasis en actividades de modelado del negocio y de requisitos).

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline21 de la

arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios

(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline

de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de

una serie de iteraciones. (Para cada iteración se seleccionan algunos Casos de Uso)

En la fase de transición se pretende garantizar que se tiene un producto preparado para

su entrega a la comunidad de usuarios.

3.6 Artefactos

RUP en cada una de sus fases realiza una serie de artefactos que sirven para

comprender mejor tanto el análisis como el diseño del sistema.

Inicio:

o Especificación de Requisitos

Elaboración:

o Diagramas de caso de uso

21 Plan original más todos los cambios negociados con los patrocinadores y aprobados como parte del proyecto.

24

Construcción:

o Vista Lógica

Diagrama de clases

Modelo E-R

Mapa de procesos

o Vista Conceptual

Modelo de dominio

o Vista física

Mapa de comportamiento a nivel de hardware.

3.6.1 Especificación de Requisitos

a) Reglas de negocio

Tabla 1. Reglas de negocio

Código Descripción

RN-001 Automatizar la administración de ciertos requisitos de un Sistema de

Gestión de Calidad orientado a los lineamientos de las normas ISO 9001

b) Requisitos no funcionales

Tabla 2. Requisitos no funcionales


RNF-001 Disponibilidad: El sistema debe funcionar en horario continuo, 7x24

RNF-002 Se debe contar con una conexión permanente y confiable a Internet

RNF-003 La aplicación deberá funcionar en la web y con compatibilidad con los

browser de mayor uso (Mozilla Firefox, Google Chrome, Microsoft Edge)

RNF-004 El sistema tiene que integrarse a un LDAP para la Autenticación de

usuarios

RNF-005 El sistema debe integrarse con los sistemas de recursos humanos de la

empresa

25

c) Requisitos funcionales

Tabla 3. Requisitos funcionales gestión catálogos


RF-001 Permitir gestionar listado de procesos y subprocesos

RF-001-01 Permitir crear un proceso o subproceso

RF-001-02 Permitir editar un proceso o subproceso

RF-001-03 Permitir desactivar un proceso o subproceso

Tabla 4. Requisitos funcionales gestión de procesos


RF-001 Permitir gestionar los listados de las matrices de caracterización

de los procesos o subprocesos

RF-001-01 Permitir crear la matriz de caracterización de un proceso o

subproceso

RF-001-02 Permitir editar la matriz de caracterización de un proceso o

subproceso y registrar los cambios realizados

RF-001-03 Permitir desactivar una matriz de caracterización de un proceso o

subproceso

RF-001-03-01 Permitir enviar solicitud para desactivar la matriz de

caracterización

RF-001-03-02 Permitir quitar una matriz de caracterización en estado de

"Borrador"

RF-002 Permitir la revisión de una matriz de caracterización de un

proceso o subproceso antes de su aprobación

RF-002-01 Permitir registrar observaciones de cambios

RF-002-02 Permitir aprobar revisión o rechazar y enviar correo con la

decisión.

RF-002-02-01 Enviar correo al responsable de la revisión de la matriz de

caracterización

RF-002-02-02 Enviar correo al Elaborador para realizar los cambios sugeridos

en la matriz de caracterización

RF-003 Permitir la revisión de una matriz de caracterización de un

proceso previo a su aprobación

26

Tabla 4. (Continuación)



decisión

RF-003-02-01 Enviar correo al responsable de aprobación de la matriz de

caracterización

RF-003-02-02 Enviar correo al Elaborador para realizar los cambios

RF-004 Permitir la aprobación de una matriz de caracterización de un

proceso o subproceso


RF-004-02 Permitir aprobar o rechazar la matriz de caracterización

RF-004-02-01 Enviar correo general al personal de la empresa con la nueva

estructura del proceso o subprocesos

RF-004-02-02 Enviar correo al Revisor para realizar los cambios sugeridos por

el Aprobador

RF-004-03 Permitir aprobar o rechazar solicitud para desactivar una matriz

de caracterización de un proceso o subproceso

Tabla 5. Requisitos funcionales gestión de documentos


RF-001 Permitir gestionar los listados de documentos internos asociados

a un proceso o subproceso

RF-001-01 Permitir crear un documento interno asociado a un proceso o

subproceso

RF-001-02 Permitir editar un documento interno y registrar los cambios

realizados

RF-001-03 Permitir desactivar un documento interno asociado a un proceso

o subproceso

RF-001-03-01 Permitir enviar solicitud para desactivar un documento interno

RF-001-03-02 Permitir quitar un documento interno en estado de "Borrador"

RF-002 Permitir la revisión de documento interno de un proceso o

subproceso antes de su aprobación


27



decisión.

RF-002-02-01 Enviar correo al responsable de la revisión del documento interno


en el documento interno

RF-003 Permitir la revisión de un documento interno de un proceso previo

a su aprobación



decisión

RF-003-02-01 Enviar correo al responsable de aprobación del documento

interno


en el documento interno

RF-004 Permitir la aprobación de un documento interno de un proceso o

subproceso


RF-004-02 Permitir aprobar o rechazar el documento interno

RF-004-02-01 Enviar correo general al personal de la empresa con el nuevo

contenido de documento interno

RF-004-02-02 Enviar correo al Revisor para realizar los cambios sugeridos por

el Aprobador

RF-004-03 Permitir aprobar o rechazar solicitud para desactivar un

documento interno de un proceso o subproceso

RF-005 Permitir gestionar los listados de documentos externos asociados

de un proceso o subproceso

RF-005-01 Permitir crear un documento externo

RF-005-01-01 Permitir adjuntar archivos en formatos Word, Excel, PDF

RF-005-02 Permitir editar un documento externo y registrar los cambios

realizados

RF-005-03 Permitir desactivar un documento externo

28

Tabla 6. Requisitos funcionales gestión de reportes


RF-001 Permitir visualizar documento interno, externo, matriz de

caracterización y listados de los mismos

RF-002 Permitir generar PDF de la matriz de caracterización y documento

interno

3.6.2 Diagramas de caso de uso

Especificación de Casos de Uso

Con el presente documento se pretende documentar los casos de uso especificados

para el proyecto SIGC. En la primera sección se muestra una breve explicación de los

campos que se utilizarán para su especificación.

Definición de Casos de Uso

Actores: Entidad externa al sistema que se especifica y que interactúa con él.

Actores diferentes suelen representar clases de usuario distintas, roles, etc.

Disparador: Identifica el evento que inicializa el caso de uso. Puede ser una

causa externa o un estado del sistema lo que lo provoque que se inicie. Se

considera el primer paso del flujo normal.

Descripción: Proporciona una razón que justifica la existencia de este UC, con

un nivel medio-alto de descripción de la secuencia de acciones y la salida

producida como resultado de su ejecución.

Pre condiciones: Lista cualquier actividad que tiene que ocurrir antes de que el

caso de uso comience.

Post condiciones: Describe el estado del sistema al finalizar la ejecución del

caso de uso.

Flujo normal: Proporciona una descripción detallada de las elecciones del

usuario y las respuestas del sistema que tienen lugar bajo unas condiciones

normales de ejecución.

29

Flujo alternativo: Tiene en cuenta los posibles escenarios. Describe diferencias

en la secuencia de pasos del flujo normal.

Excepciones: Describe cualquier condición de error que pueda ocurrir durante

la ejecución del UC y define de qué forma el sistema responde a ellas. También

describe el comportamiento del sistema si el caso de uso falla su ejecución por

alguna razón no contemplada.

Inclusiones: Lista otros casos de uso a los que pueda hacer uso el mismo que

se describe. Funcionalidades que aparecen en varios casos de uso se agrupan

en un caso de uso que sea llamado o incluido por otros que requieran de esa

funcionalidad común.

Prioridad: Indica la importancia relativa de su implementación. Esencial, Alta,

Deseada, Opcional

Frecuencia de uso: Estima, de manera cualitativa, el número de veces que será

realizado por unidad de tiempo. Siempre, A menudo, A veces, Raramente, Una

vez

Reglas de negocio: Lista cualquier regla de negocio que pueda influir en el caso

de uso. Las reglas de negocios (o las directivas empresariales) definen y

controlan la estructura, el funcionamiento y la estrategia de una organización.

Pueden estar formalmente definidas en manuales de procedimiento, contratos o

acuerdos, o bien pueden existir como conocimiento o experiencia que tienen los

empleados.

Requisitos especiales: Identifica cualquier requisito adicional no funcional, que

necesite el caso de uso durante su ejecución, o diseño. Puede incluir requisitos

de realización u otros atributos cualitativos.

Asunciones: Lista cualquier condición que debe cumplirse, necesaria para

aceptar el caso de uso y su descripción.

Notas: Lista cualquier comentario adicional sobre el caso de uso u otras

cuestiones que se dejen abiertas para ser resueltas más adelante.

30

a) Gestionar Sesiones

Este paquete contiene casos de uso que definen cómo un actor interactúa con el sistema

propuesto para iniciar y finalizar sesiones de trabajo en el mismo.

Tabla 7. Especificaciones iniciar sesión

Nombre Iniciar Sesión

Paquete Gestionar Sesiones

Creado por José Tierra Actualizado por Nelson Morales

Fecha de creación 16/01/2016 Última actualización 23/01/2016

Actores Usuario

Descripción Inicia una sesión de trabajo del usuario en el sistema

Disparador

Pre condiciones El usuario debe estar registrado en el sistema por lo que debe

tener datos de acceso (usuario, contraseña)

Post condiciones

Flujo Normal

1. Ingresa a la página web del sistema

2. El usuario ingresa sus datos de acceso

3. El sistema lo valida

4. Inicia una sesión de trabajo en el sistema

Flujo Alternativo

1. El usuario es inválido

2. El sistema lanza un mensaje (Usuario o contraseña

incorrecto)

Excepciones El usuario no ha sido registrado en el sistema, comunicarse

con el administrador del sistema.

Inclusiones

Prioridad Esencial

Frecuencias de uso Siempre

Reglas de negocio

Requisitos

especiales Integración a un LDAP para la Autenticación de usuarios

Asunciones

Notas

El usuario puede olvidar los datos de acceso al sistema.

Puede pedir al administrador del sistema restablecer la

misma.

31

Tabla 8. Especificaciones cerrar sesión

Nombre Cerrar Sesión


Creado por Nelson Morales

José Tierra Actualizado por

Nelson Morales

José Tierra


Actores Usuario

Descripción Finaliza la sesión de trabajo del usuario en el sistema

Disparador

Pre condiciones Que el usuario haya iniciado un sesión de trabajo en el

sistema

Post condiciones

Flujo Normal

1. El usuario da clic en salir

2. El sistema eliminara la sesión

3. El sistema redirige a la pantalla de inicio

Flujo Alternativo

Excepciones En un determinado tiempo de no usarse el sistema la sesión

caducara y debe realizarse nuevamente el caso anterior

Inclusiones

Prioridad Esencial

Frecuencias de uso Siempre

Reglas de negocio

Requisitos

especiales

Asunciones

Notas

32

Tabla 9. Especificaciones recuperar contraseña

Nombre Recuperar Contraseña


Creado por José Tierra Actualizado por Nelson Morales


Actores Operador

Descripción Permite al usuario recuperar su contraseña

Disparador Cuando no puede iniciar sesión en el sistema y sale un

mensaje de error de contraseña.

Pre condiciones

Post condiciones

Flujo Normal

1. El usuario da clic en ¿Has olvidado la contraseña?

2. Ingresar e-mail

3. Se envía un correo con su contraseña

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Esencial

Frecuencias de uso Raramente

Reglas de negocio

Requisitos

especiales

Asunciones

Notas

Figura 21. Caso de uso 1 sesiones

Figura 22. Interfaz 1 sesiones

33

b) Gestionar Catálogos

Este paquete contiene casos de uso que definen como un actor interactúa con el sistema

propuesto para gestionar catálogos de procesos, subprocesos, tipo de registros,

localidad, etc.

Tabla 10. Especificaciones gestionar catálogo procesos y subprocesos

Nombre Gestionar catálogo Procesos y Subprocesos

Paquete Gestionar Catálogos



Nelson Morales

José Tierra


Actores Administrador

Descripción

Permite al usuario con rol de Administrador gestionar los

catálogos de los procesos y subprocesos establecidos en la

empresa, (Crear, Editar, Eliminar)

Disparador

Pre condiciones Debe existir una sesión activa

Post condiciones

Flujo Normal 1. Ingresa al listado de catálogos

2. Seleccionar la opción Procesos / subprocesos

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Alta

Frecuencias de uso A menudo

Reglas de negocio

Requisitos

especiales

Asunciones

Notas

34

Tabla 11. Especificaciones consultar proceso / subproceso

Nombre Consultar Proceso / Subproceso




Nelson Morales

José Tierra



Descripción Permite a un usuario con rol de Administrador consultar un

Proceso o Subproceso registrado en el sistema.

Disparador

Pre condiciones Debe existir una sesión activa

Post condiciones

Flujo Normal 1. Elegir entre las opciones (Procesos / subprocesos)

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Opcional


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

35

Tabla 12. Especificaciones crear proceso

Nombre Crear Proceso




Nelson Morales

José Tierra



Descripción Permite a un usuario con el rol de Administrador crear un

nuevo Proceso

Disparador Nuevo proceso establecido en la empresa

Pre condiciones Debe existir una sesión activa con permisos de administrador

Post condiciones Crear una matriz de caracterización para el proceso creado.

Flujo Normal

1. Ingresar Descripción del proceso

2. Identificar mnemónico

3. Guardar los datos

Flujo Alternativo

Excepciones

Inclusiones Identificar Mnemónico

Prioridad Esencial

Frecuencias de uso A veces

Reglas de negocio

Requisitos

especiales

Asunciones

Notas

36

Tabla 13. Especificaciones crear subproceso

Nombre Crear Subproceso




Nelson Morales

José Tierra



Descripción Permite a un usuario con el rol de Administrador crear un

nuevo Proceso

Disparador Nuevo proceso establecido en la empresa


Crear el proceso a cual se van asociar los subprocesos

Post condiciones Crear una matriz de caracterización para el subproceso

creado.

Flujo Normal

1. Elegir proceso a cual pertenece el subproceso

2. Ingresar descripción del subproceso

3. Identificar Mnemónico

4. Guardar los datos

Flujo Alternativo

Excepciones

Inclusiones Identificar Mnemónico

Asociar Mnemónico

Prioridad Esencial

Frecuencias de uso A veces

Reglas de negocio

Requisitos

especiales

Asunciones

Notas

37

Tabla 14. Especificaciones editar proceso / subproceso

Nombre Editar Proceso / Subproceso




Nelson Morales

José Tierra



Descripción Permite a un usuario con el rol de Administrador editar un

Proceso o Subproceso

Disparador Cuando se necesita realizar algún cambio en la descripción o

los mnemónicos del proceso o subproceso


Verificar si existe el proceso o subproceso a editar

Post condiciones Verificar si se va a realizar cambios en la matriz de

caracterización del proceso o subproceso involucrado

Flujo Normal

1. Seleccionar el proceso o subproceso a editar

2. Realzar cambios en los campos establecidos.

3. Guardar datos

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Esencial


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

38

Tabla 15. Especificaciones desactivar proceso / subproceso

Nombre Desactivar Proceso / Subproceso




Nelson Morales

José Tierra



Descripción Permite a un usuario con el rol de Administrador dar

desactivar un proceso o subproceso obsoleto.

Disparador Un proceso que este obsoleto

Pre condiciones Verificar que el proceso o subproceso no este asociado a una

matriz de caracterización

Post condiciones

Flujo Normal

1. Seleccionar proceso a desactivar

2. Verificar si no está asociado a una matriz de

caracterización

3. Registrar cambio de estado

4. Guardar cambios

Flujo Alternativo 1. Mensaje del sistema “No se puede desactivar el

proceso o subproceso porque se encuentra en uso”

Excepciones

Inclusiones Verificar relación

Prioridad Deseada


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

39

Figura 23. Caso de uso 2 catálogos

Figura 24. Caso de uso 3 listas

Figura 25. Caso de uso 4 crear

proceso - subproceso

Figura 26. Caso de uso 5 desactivar

proceso - subproceso

Figura 27. Interfaz 2 gestionar catálogos

40

c) Gestionar Procesos (matriz de caracterización)

Este paquete contiene casos de uso que definen como los actores con los roles de

elaborador, revisor y aprobador interactúa con el sistema propuesto para elaborar,

revisar aprobar, un documento.

Tabla 16. Especificaciones gestionar proceso

Nombre Gestionar proceso

Paquete Gestionar procesos

Creado por Nelson Morales Actualizado por Nelson Morales


Actores Elaborador

Descripción

Permite a un usuario con rol de Elaborador consultar, crear,

editar, eliminar un proceso o subproceso registrado en el

sistema.

Disparador

Pre condiciones Debe existir una sesión activa con permisos de elaborador

Post condiciones

Flujo Normal

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Esencial


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

41

Tabla 17. Especificaciones consultar proceso (matriz de caracterización)

Nombre Consultar Proceso (matriz de caracterización)

Paquete Gestionar Procesos



Actores Elaborador

Descripción Permite a un usuario con rol de Elaborador consultar un

proceso o subproceso registrado en el sistema.

Disparador

Pre condiciones

Post condiciones

Flujo Normal Seleccionar entre las opciones (proceso o subproceso)

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Opcional


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

Tabla 18. Especificaciones crear matriz de caracterización

Nombre Crear matriz de caracterización




Actores Elaborador, Dpto. Recursos Humanos

42


Descripción

Permite a un usuario con el rol de elaborador crear una matriz

de caracterización de un proceso o sub proceso en el sistema.

Deja el documento en estado de "Borrador"

Ingresando como primera entrada en su historial de cambios.

Disparador Cuando se crea un nuevo descripción de proceso o subproceso


Post condiciones Enviar correo de notificación a su revisor

Flujo Normal

1. Identificar proceso o subproceso

2. Identificar cabecera

3. Identificar objetivos operativos

4. Identificar responsables (elaborador, revisor y

aprobador)

5. Identificar recursos

6. Identificar entradas y salidas

7. Guardar datos

8. Enviar notificación a su revisor

Flujo Alternativo 1. Volver a crear un proceso o subproceso.

2. Comunicarse con recursos Humanos

Excepciones

Inclusiones

Identificar proceso o subproceso

Identificar cabecera

Identificar objetivos operativos

Identificar responsables (elaborador, revisor y aprobador)

Identificar recursos

Identificar entradas y salidas

Prioridad Esencial


Reglas de negocio Asegurara el cumplimiento de los lineamientos de las normas

ISO 9001

Requisitos

especiales

El sistema debe integrarse con el sistema de recursos humanos

El sistema debe integrarse con el sistema de bienes

Asunciones Establecer y dar a conocer el procedimiento a seguir para el

proceso o subproceso establecido en la empresa

Notas El usuario debe elegir cuando enviar a su revisión

43

Tabla 19. Especificaciones editar proceso (matriz de caracterización)

Nombre Editar Proceso (matriz de caracterización)




Actores Elaborador

Descripción

Permite a un usuario con el rol de elaborador editar un proceso

o subproceso para que posteriormente pueda ser revisada y

aprobada.


Ingresando como primera entrada en su historial de cambios de

una nueva versión de la matriz.

Disparador Realizar cambios sugeridos en la matriz de caracterización



Flujo Normal

1. Revisar el contenido de la matriz

2. Realizar cambios en la matriz de caracterización

3. Registrar cambios establecidos

4. Guardar datos


Flujo Alternativo

Excepciones

Inclusiones

Prioridad Alta


Reglas de negocio Asegurara el cumplimiento de los lineamientos de las normas

ISO 9001

Requisitos

especiales

El sistema debe integrarse con el sistema de recursos humanos

El sistema debe integrarse con el sistema de bienes

Asunciones Establecer y dar a conocer el procedimiento a seguir para el

proceso o subproceso establecido en la empresa

Notas

44

Tabla 20. Especificaciones desactivar proceso (matriz de caracterización)

Nombre Desactivar Proceso (matriz de caracterización)




Actores Aprobador, Elaborador

Descripción

Permite a un usuario con el rol de elaborador enviar una solicitud

para desactivar un proceso o subproceso.

Si la solicitud es aprobada el documento registrara un estado de

"Inactivo"

Disparador


Post condiciones Notificar al aprobador el estado de la matriz de caracterización

del proceso o subproceso

Flujo Normal

1. Crear solicitud para desactivar matriz de

caracterización

2. Registrar motivos de la solicitud

3. Registrar cambio de estado “Inactivo”

1. Aprobar solicitud para desactivar

2. Registrar cambio de estado “Histórico”

Flujo Alternativo Mensaje del sistema la “Su solicitud ha sido rechazada ”

Excepciones

Inclusiones Registrar cambio de estado

Prioridad Alta


Reglas de negocio

Requisitos

especiales Envió de correo automático

Asunciones

Notas

45

Tabla 21. Especificaciones revisar proceso (revisor)

Nombre Revisar proceso (Revisor)




Actores Revisor

Descripción

Permite a un usuario con rol de Revisor consultar, y revisar un

proceso o subproceso.

El usuario podrá aprobar o rechazar la revisión, en caso de

aprobar la revisión el estado del documento será "Por Aprobar"

Disparador Se ha notificado por parte del revisor que una matriz de

caracterización fue creada o editada

Pre condiciones Notificación del elaborador

Post condiciones Enviar correo de notificación al elaborador o revisor asignado en

el departamento de Sistema de Calidad según sea el caso

Flujo Normal

1. Abrir matriz de caracterización

2. Revisar contenido de la matriz

3. Aprobar revisión

4. Registrar cambio de estado “Pro Aprobar”

5. Enviar notificación a Sistemas de Calidad para su

revisión

Flujo Alternativo

1. Ingresar Observaciones de cambios

2. Enviar notificación a su elaborador que establezca los

cambios sugeridos

Excepciones

Inclusiones Registrar cambios matriz de caracterización

Prioridad Esencial


Reglas de negocio

Requisitos

especiales Envió de correo automático las dos alternativas

Asunciones

Notas

46

Tabla 22. Especificaciones revisar proceso (dpto. sistemas de calidad)

Nombre Revisar proceso (Dpto. Sistemas de Calidad)





Descripción

Permite a un usuario con rol de Administrador consultar, y

revisar un proceso o subproceso.


aprobar la revisión el estado del documento será "Por Aprobar"

Disparador Se ha notificado por parte del revisor que una matriz de

caracterización fue creada o editada


Post condiciones Enviar correo de notificación al Revisor o Aprobador según sea

el caso

Flujo Normal




4. Registrar cambio de estado “Pro Aprobar”


revisión

Flujo Alternativo


2. Enviar notificación a su Revisor que establezca los

cambios sugeridos

Excepciones


Prioridad Esencial


Reglas de negocio

Requisitos


Asunciones

Notas

47

Tabla 23. Especificaciones aprobar proceso (matriz de caracterización)

Nombre Aprobar proceso (Matriz de caracterización)




Actores Aprobador

Descripción

Permite a un usuario con rol de Aprobador consultar, y aprueba

un proceso o subproceso.

El usuario podrá aprobar o rechazar el documento, en caso de

aprobación el estado del documento será "Aprobado"

Disparador Se ha notificado por parte del revisor (Dpto. Sistema de Calidad)

que una matriz de caracterización fue revisada

Pre condiciones Notificación del Revisor

Post condiciones Publicación de la nueva matriz de caracterización del proceso o

subproceso y notificación al personal de la empresa

Flujo Normal




4. Registrar cambio de estado “Aprobado”

5. Publicación en la intranet de la empresa

6. Notificación al personal de la empresa de la nueva

matriz de caracterización del proceso o subproceso

Flujo Alternativo



cambios sugeridos

Excepciones


Prioridad Esencial


Reglas de negocio

Requisitos


Asunciones

Notas

48

Figura 28. Caso de uso 6 gestionar


Figura 29. Caso de uso 7 listado


Figura 30. Caso de uso 8 revisar matriz

de caracterización

Figura 31. Caso de uso 9 aprobar


Figura 32. Interfaz 3 gestionar matriz de caracterización

49

d) Gestionar Documentos


propuesto para elaborar, revisar aprobar, listar documentos internos y externos

asociados a un proceso o subproceso.

Tabla 24. Especificaciones gestionar documentos

Nombre Gestionar Documentos

Paquete Gestionar Documentos

Creado por José Tierra Actualizado por José Tierra


Actores Elaborador

Descripción Permite a un usuario con rol de Elaborador consultar, crear,

editar, eliminar un documento interno registrado en el sistema.

Disparador


Post condiciones

Flujo Normal

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Esencial


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

50

Tabla 25. Especificaciones consultar documentos internos

Nombre Consultar Documentos internos




Actores Elaborador


documento interno registrado en el sistema.

Disparador

Pre condiciones

Post condiciones

Flujo Normal 1. Seleccionar entre las opciones

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Opcional


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

Tabla 26. Especificaciones crear documento interno

Nombre: Crear documento interno

Paquete: Gestionar Documentos

Creado por: José Tierra Actualizado por: José Tierra

Fecha de creación: 16/01/2016 Última actualización: 23/01/2016

Actores Elaborador, Dpto. Recursos Humanos

51


Descripción

Permite a un usuario con el rol de Elaborador crear un

documento interno en el sistema.


Ingresando como primera entrada en su historial de cambios.

Disparador Cuando se crea un nuevo descripción de proceso o

subproceso



Flujo Normal

1. Identificar proceso o subproceso

2. Identificar cabecera

3. Identificar objetivos operativos

4. Identificar responsables (elaborador, revisor y

aprobador)

5. Identificar localidad

6. Guardar datos


Flujo Alternativo

1. Volver a crear un proceso o subproceso.

2. Comunicarse con recursos Humanos

3. Crear una localidad si esta no está disponible

Excepciones

Inclusiones

Identificar proceso o subproceso

Identificar cabecera

Identificar objetivos operativos

Identificar responsables (elaborador, revisor y aprobador)

Identificar localidad

Prioridad Esencial


Reglas de negocio Asegurara el cumplimiento de los lineamientos de las

normas ISO 9001

Requisitos

especiales

El sistema debe integrarse con el sistema de recursos

humanos

Asunciones Establecer y dar a conocer los documentos asociados a un


Notas El usuario debe elegir cuando enviar a su revisión

52

Tabla 27. Especificaciones editar documento interno

Nombre Editar Documento interno




Actores Elaborador

Descripción

Permite a un usuario con el rol de elaborador editar

un documento interno para que posteriormente pueda ser

revisada y aprobada.


Ingresando como primera entrada en su historial de cambios

de una nueva versión del documento.

Disparador Realizar cambios sugeridos en el documento



Flujo Normal

1. Revisar el contenido del documento

2. Realizar cambios en el documento

3. Registrar cambios establecidos

4. Guardar datos


Flujo Alternativo

Excepciones

Inclusiones

Prioridad Alta


Reglas de negocio Asegurara el cumplimiento de los lineamientos de las

normas ISO 9001

Requisitos

especiales

El sistema debe integrarse con el sistema de recursos

humanos



Notas

53

Tabla 28. Especificaciones desactivar documento interno

Nombre Desactivar Documento interno




Actores Aprobador, Elaborador

Descripción

Permite a un usuario con el rol de elaborador enviar una

solicitud para desactivar un documento interno.

Si la solicitud es aprobada el documento registrara un estado

de "Inactivo"

Disparador


Post condiciones Notificar al aprobador el estado del documento interno del


Flujo Normal

1. Crear solicitud para desactivar matriz de

caracterización

2. Registrar motivos de la solicitud

3. Registrar cambio de estado “Inactivo”

4. Aprobar solicitud para desactivar

5. Registrar cambio de estado “Histórico”

Flujo Alternativo Mensaje del sistema la “Su solicitud ha sido rechazada ”

Excepciones

Inclusiones Registrar cambio de estado

Prioridad Alta


Reglas de negocio

Requisitos


Asunciones

Notas

54

Tabla 29. Especificaciones revisar documento interno (revisor)

Nombre Revisar documento interno (Revisor)




Actores Revisor

Descripción

Permite a un usuario con rol de Revisor consultar, y revisar un

documento interno asociado a un proceso o subproceso


aprobar la revisión el estado del documento será "Por

Aprobar"

Disparador Se ha notificado por parte del revisor que un documento

interno fue creado o editado


Post condiciones Enviar correo de notificación al elaborador o revisor asignado

en el departamento de Sistema de Calidad según sea el caso

Flujo Normal

1. Abrir documento interno

2. Revisar contenido del documento interno


4. Registrar cambio de estado “Por Aprobar”


revisión

Flujo Alternativo


2. Enviar notificación a su elaborador que establezca los

cambios sugeridos

Excepciones

Inclusiones Registrar cambios documento interno

Prioridad Esencial


Reglas de negocio

Requisitos


Asunciones

Notas

55

Tabla 30. Especificaciones revisar documento interno

Nombre Revisar documento interno (Dpto. Sistemas de Calidad)





Descripción

Permite a un usuario con rol de Administrador consultar, y

revisar un proceso o subproceso.


aprobar la revisión el estado del documento será "Por

Aprobar"

Disparador Se ha notificado por parte del revisor que un documento

interno fue creado o editado

Pre condiciones Notificación del revisor

Post condiciones Enviar correo de notificación al Revisor o Aprobador según

sea el caso

Flujo Normal


2. Revisar contenido del documento interno


4. Registrar cambio de estado “Por Aprobar”


revisión

Flujo Alternativo



cambios sugeridos

Excepciones


Prioridad Esencial


Reglas de negocio

Requisitos


Asunciones

Notas

56

Tabla 31. Especificaciones aprobar documento interno

Nombre Aprobar documento interno




Actores Aprobador

Descripción

Permite a un usuario con rol de Aprobador consultar, y

aprobar un documento asociado a un proceso o subproceso.

El usuario podrá aprobar o rechazar el documento, en caso

de aprobación el estado del documento será "Aprobado"

Disparador Se ha notificado por parte del revisor (Dpto. Sistema de

Calidad) que un documento interno fue revisado

Pre condiciones Notificación del Revisor

Post condiciones Publicación del nuevo documento interno del proceso o

subproceso y notificación al personal de la empresa

Flujo Normal


2. Revisar contenido del documento


4. Registrar cambio de estado “Aprobado”

5. Publicación en la intranet de la empresa

6. Notificación al personal de la empresa de un

documento interno del proceso o subproceso

Flujo Alternativo



cambios sugeridos

Excepciones


Prioridad Esencial


Reglas de negocio

Requisitos


Asunciones

Notas

57

Figura 33. Caso de uso 10 gestionar

documentos internos

Figura 34. Caso de uso 11 listado

documentos internos

Figura 35. Caso de uso 12 revisar

documentos internos

Figura 36. Caso de uso 13 aprobar

documentos internos

Figura 37. Interfaz 4 gestionar documentos internos

58

Tabla 32. Especificaciones consultar documentos externos

Nombre Consultar documentos externos




Actores Elaborador


documento externo registrado en el sistema.

Disparador

Pre condiciones

Post condiciones

Flujo Normal 1. Seleccionar entre las opciones

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Opcional


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

59

Tabla 33. Especificaciones crear documento externo

Nombre Crear documento externo




Actores Elaborador

Descripción Permite a un usuario con el rol de elaborador crear un

documento externo asociado a un proceso o subproceso

Disparador Cuando se crea un nuevo descripción de proceso o

subproceso


Post condiciones Revisar matriz de caracterización donde aparece los

documentos externos asociados

Flujo Normal

1. Identificar proceso o subproceso asociado

2. Identificar datos generales

3. Adjuntar archivo

4. Guardar datos.

Flujo Alternativo 1. Regresar a crear un proceso o subproceso según sea

el caso.

Excepciones

Inclusiones

Identificar proceso / subproceso

Identificar datos generales

Adjuntar enlace o documento

Prioridad Esencial


Reglas de negocio

Requisitos

especiales



Notas Verificar la matriz de caracterización del proceso o

subproceso involucrado

60

Tabla 34. Especificaciones editar documento externo

Nombre Editar documento externo




Actores Elaborador

Descripción Permite a un usuario con el rol de elaborador editar un

documento externo asociado a un proceso o subproceso

Disparador Realizar cambios sugeridos en el enlace o documento adjunto




Flujo Normal

1. Abrir documento externo

2. Realizar cambios en el enlace

3. Registrar cambios realizados

4. Guardar datos

Flujo Alternativo

Excepciones

Inclusiones

Prioridad Alta


Reglas de negocio

Requisitos

especiales



Notas Verificar la matriz de caracterización del proceso o

subproceso involucrado

61

Tabla 35. Especificaciones desactivar documentos externos

Nombre Desactivar documentos externos




Actores Elaborador

Descripción Permite al usuario con rol de Elaborador desactivar un

documento externo asociado a un proceso o subproceso.

Disparador Revisión de una matriz de caracterización de un proceso o

subproceso




Flujo Normal

1. Abrir documento externo

2. Registrar motivos

3. Registrar cambio de estado

4. Guardar datos

Flujo Alternativo

Excepciones

Inclusiones Registrar motivos

Registrar cambios de estado

Prioridad Alta


Reglas de negocio

Requisitos


Asunciones

Notas

62

Figura 38. Caso de uso 14 gestionar documentos externos

Figura 39. Interfaz 5 gestionar documentos externos

63

e) Gestionar Reportes


propuesto para generar documentos físicos.

Tabla 36. Especificaciones consultar documentos aprobados

Nombre Consultar documentos aprobados

Paquete Gestionar Reportes

Creado por Nelson Morales Actualizado por José Tierra


Actores Usuarios

Descripción Permite al usuario generar un documento físico.

Disparador Necesidad de tener el documento físico

Pre condiciones

Post condiciones

Flujo Normal 1. Generar PDF

Flujo Alternativo

Excepciones

Inclusiones Generar PDF

Prioridad Esencial


Reglas de negocio

Requisitos

especiales

Asunciones

Notas

Figura 40. Caso de uso 15 generar reportes

64

3.6.3 Mapa de procesos modulo procesos

Figura 43. Mapa de procesos módulo de procesos SIGC

65

3.6.4 Mapa de procesos módulo control de documentos

Figura 44. Mapa de procesos modulo control de documentos SIGC

El Mapa de Procesos es la representación gráfica de los procesos que están presentes

en una organización, mostrando la relación entre ellos y sus relaciones con el exterior.

Una organización que pretenda una gestión sólida y bien orientada hacia sus objetivos

estratégicos y sus resultados clave, requiere de una perspectiva global y transversal que

sólo puede darse mediante una visión de procesos.

66

3.6.5 Modelo de dominio

Figura 45. Modelo de dominio SIGC

Puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo

análisis como paso previo al diseño de un sistema. El modelo de dominio puede ser

tomado como el punto de partida para el diseño del sistema. Cuando se realiza la

programación orientada a objetos, el funcionamiento interno del software va a imitar en

alguna medida a la realidad, por lo que el mapa de conceptos del modelo de dominio

constituye una primera versión del sistema.

67

3.6.6 Diagrama de clases

Figura 41. Diagrama de clases SIGC

Este diagrama de clases es una representación gráfica que sirve para representar la

estructura del sistema que será implementado utilizando un lenguaje orientado a

objetos. Los diagramas de clases se realizan en la fase de diseño del software después

de la fase de requisitos. La idea de este diagrama es representar las clases que tendrá

el sistema así como su contenido y sus relaciones con otras clases. La implementación

de sistemas medianamente grandes no sería abordable sin este tipo de diagramas, y

aunque fuera abordable se tardaría mucho más y sería más fácil cometer errores.

68

3.6.7 Modelo E-R

Figura 42. Modelo entidad relación SIGC

69

Un diagrama o modelo entidad-relación (a veces denominado por sus siglas en inglés,

E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una

herramienta para el modelado de datos que permite representar las entidades

relevantes de un sistema de información así como sus interrelaciones y propiedades.

3.6.8 Arquitectura de la aplicación.

Figura 46. Arquitectura de la aplicación SIGC (Empresa Eléctrica Quito, 2015)

Capa de presentación: Se encarga de crear la presentación que rende rizará la

capa de cliente. Actúa como un puente entre la capa de cliente y la capa de

lógica de negocio. En Java, esta capa se implementa típicamente utilizando

componentes Servlets22 / JSP23.

22 Son módulos escritos en Java que se utilizan en un servidor, para extender sus capacidades de respuesta a los clientes al utilizar las potencialidades de Java. 23 JavaServer Pages es una tecnología que ayuda a los desarrolladores de software a crear páginas web dinámicas basadas en HTML, XML, entre otros tipos de documentos.

70

Capa de lógica de negocio: Esta capa contiene a todos nuestros objetos de

negocio y servicios de procesado de la lógica de negocio. Suelen representar

una vista objetual de la información presente en la base de datos. En Java, esta

capa se suele implementar con EJBs (Enterprise JavaBeans24) aunque pueden

utilizarse también otras tecnologías más ligeras como el uso directo de objetos

planos.

Capa de integración: En esta capa suelen colocarse clases u objetos que

automaticen el acceso a base de datos.

Capa de datos: Representa los sistemas de información empresarial de nuestra

organización. Suele estar formada por bases de datos, servidores de sockets25,

sistemas legacy26, etc. La capa de integración nos ayuda a acceder a estos

sistemas heterogéneos de la forma más transparente posible.

3.7 Ventajas

Está basada totalmente en mejoras prácticas de la metodología:

Reduce riesgos del proyecto.

Incorpora fielmente el objetivo de calidad.

Integra desarrollo con mantenimiento.

3.8 Desventajas

Pretende prever y tener todo el control de antemano:

Modelo genera trabajo adicional.

Genera muchos costos.

24 Componentes usados para encapsular varios objetos en un único objeto (la vaina o Bean en inglés), para hacer uso de un solo objeto en lugar de varios más simples. 25 Un socket es un mecanismo que permite la conexión entre distintos procesos. 26 istema informático que ha quedado anticuado pero continúa siendo utilizado por el usuario y no se quiere o no se puede reemplazar o actualizar de forma sencilla.

71

4. CONCLUSIONES

La elaboración de distintos diagramas y artefactos siguiendo la metodología

RUP proveen una fácil ejecución del proceso de elaboración de una aplicación,

ya que describen como está estructurado el sistema desde diferentes

perspectivas orientadas a los diferentes involucrados en un proyecto.

Se puede reducir el tiempo de desarrollo de una aplicación, empleando la

metodología RUP y UML ya que permite lograr de una manera fiable y rápida el

desarrollo del sistema deseado.

Las ventajas de utilizar RUP son la reducción de riesgos en el proyecto, la

garantía de calidad y la integración entre el desarrollo y mantenimiento del

software (a base de ir iterando en cada fase, combinando actividades de uno y

otro tipo).

El tener todo el procedimiento de desarrollo de una aplicación, es una

herramienta necesaria y efectiva para administrarla, y así contar con una visión

unificada de todo el proceso, con lo que se facilita la implementación del mismo.

La aplicación permitirá tener un manejo más consciente y efectivo del Sistema

de Gestión de la Calidad, lo cual causará una disminución en los costos,

especialmente, de producción.

La aplicación provocará que los períodos de creación de procesos y documentos

de la empresa sean menores. Además, el acceso rápido a la información evitará

que se pierda tiempo recopilando información que podría pertenecer a otro

sector de la empresa.

La aplicación tendrá la capacidad de crecer al mismo ritmo que la empresa, se

adaptará a las necesidades y los requerimientos del negocio y resulta muy

sencillo incorporar innovaciones.

72

El sistema informático nos permite tener un control más efectivo y eficiente de

los procesos de la empresa y de cómo se están utilizando los recursos de la

misma.

Mediante la aplicación la información estará disponible en tiempo real para todos

los usuarios y la calidad de esta información será mucho mayor. Además, el

acceso constante a la información facilitará a los empleados que alcancen los

objetivos de la compañía.

73

5. RECOMENDACIONES

Para contar con un enfoque disciplinado en la asignación de tareas y

responsabilidades dentro de una organización, es necesaria la aplicación de una

metodología, la cual nos lleva al cumplimiento de uno de los objetivos que se

sigue, el cual es la producción de software de alta calidad que satisfaga las

necesidades de sus usuarios finales dentro de un presupuesto y tiempo

predecibles.

Para obtener un máximo control de variables que conlleva un desarrollo de

aplicaciones y poder mantener una ordenada implementación de éstas, es

importante seguir metodologías y estándares que nos lleven a estar en

competitividad en todo momento.

Al implementar un desarrollo rápido de aplicaciones, es importante la utilización

de patrones, los cuales ya tienen una funcionalidad general y han sido

predefinidos, y así contar con una base consistente y previamente elaborada

para la implementación del software.

Para utilizar RUP se requiere una gran previsión sobre lo que va a ocurrir (para

poder controlarlo) y que genera abundante trabajo adicional (y costes asociados)

de documentación y comunicación, con lo que no se recomienda su utilización

para proyectos pequeños.

Antes de empezar a cargar la información a la aplicación se recomienda disponer

de un delegado por parte de la organización para que haga una revisión de los

datos a ingresar para no tener a futuro inconvenientes y estar haciendo muchas

modificaciones, esto evitará pérdida de tiempo y recursos lo cual perjudica tanto

a la organización como al desarrollador del proyecto.

74

BIBLIOGRAFÍA

1. GRUPO ISAIAS CARRILLOS PEREZ. (2008). Metodología del desarrollo de

software. New York: Editorial Edit and write

2. SCHMULLER, Joseph. (2000). Aprendiendo UML en 24 horas. México: Editorial

Prentice Hall.

3. ITSA (2008). Metodologías De Desarrollo De Software. Canadá: Editorial

Canadá Pen.

4. RUP/Easy. (2004). Guía metodológica de desarrollo de sistemas

5. MUSCIANO, C.; KENNEDY, B. (2000). HTML & XHTML: The Definitive Guide.

O’Reilly.

6. RAGGETT, D.; LAM, J.; KMIEC, M. (1998). Raggett on HTML 4. Addison

Wesley Longman Limited. Obtenido de:

http://www.w3.org/People/Raggett/book4/ch02.html.

7. HIBERNATE (2010) Hibernate Annotations. Obtenido de:

https://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/

8. PROGRAMACION .NET (2013) Catálogo de patrones de diseño J2EE. I.- Capa

de presentación. Obtenido de: http://www.programacion.com/tutorial/patrones/

9. PRIMEFACES (2015) Ultimate UI Framework for Java EE. Obtenido de:

http://www.primefaces.org/

75

ANEXOS

76

Anexo A

Cumplimiento de requerimientos funcionales SIGC

Tabla A1. Gestionar catálogos

Código Requisito Funcional Caso de Uso

RF-001 Permitir gestionar listado de

procesos y subprocesos

Gestionar Catálogo Procesos /

Subprocesos

RF-001-01 Permitir crear un proceso o

subproceso Crear Proceso / Subproceso

RF-001-02 Permitir editar un proceso o

subproceso Editar Proceso / Subproceso

RF-001-03 Permitir desactivar un proceso o

subproceso

Desactivar Proceso /

Subproceso

Tabla A2. Gestionar reportes


RF-001

Permitir visualizar documento interno,

externo, matriz de caracterización y listados

de los mismos

Consultar

Documentos

Aprobados

RF-002 Permitir generar PDF de la matriz de

caracterización y documento interno Generar Reporte

77

Tabla A3. Gestionar procesos


RF-001

Permitir gestionar los listados de las

matrices de caracterización de los

procesos o subprocesos

Consultar Proceso

RF-001-01

Permitir crear la matriz de

caracterización de un proceso o

subproceso

Crear proceso

RF-001-02

Permitir editar la matriz de


subproceso y registrar los cambios

realizados

Editar proceso

RF-001-03

Permitir desactivar una matriz de


subproceso

Desactivar proceso

RF-001-03-01

Permitir enviar solicitud para

desactivar la matriz de

caracterización

Crear solicitud

desactivar

RF-001-03-02

Permitir quitar una matriz de

caracterización en estado de

"Borrador"

Consultar Proceso

RF-002

Permitir la revisión de una matriz de


subproceso antes de su aprobación

Revisar proceso

RF-002-01 Permitir registrar observaciones de

cambios

Registrar cambios

matriz de

caracterización

RF-002-02 Permitir aprobar revisión o rechazar y

enviar correo con la decisión.

Registrar cambio de

estado

RF-002-02-01

Enviar correo al responsable de la

revisión de la matriz de

caracterización

Revisar proceso

78

Tabla A3. (Continuación)

RF-002-02-02

Enviar correo al Elaborador para

realizar los cambios sugeridos en la


Revisar proceso

RF-003

Permitir la revisión de una matriz de

caracterización de un proceso previo

a su aprobación

Revisar proceso


cambios

Registrar cambios

matriz de

caracterización


enviar correo con la decisión

Registrar cambio de

estado

RF-003-02-01

Enviar correo al responsable de

aprobación de la matriz de

caracterización

Revisar proceso

RF-003-02-02 Enviar correo al Elaborador para

realizar los cambios Revisar proceso

RF-004

Permitir la aprobación de una matriz

de caracterización de un proceso o

subproceso

Aprobar proceso


cambios

Registrar cambios

matriz de

caracterización

RF-004-02 Permitir aprobar o rechazar la matriz

de caracterización

Registrar cambio de

estado

RF-004-02-01

Enviar correo general al personal de

la empresa con la nueva estructura

del proceso o subprocesos

Aprobar proceso

RF-004-02-02

Enviar correo al Revisor para realizar

los cambios sugeridos por el

Aprobador

Aprobar proceso

RF-004-03

Permitir aprobar o rechazar solicitud

para desactivar una matriz de


subproceso

Aprobar solicitud

79

Tabla A4. Gestionar documentos


RF-001

Permitir gestionar los listados de

documentos internos asociados a un


Consultar

documentos Internos

RF-001-01 Permitir crear un documento interno

asociado a un proceso o subproceso

Crear documento

interno

RF-001-02 Permitir editar un documento interno y

registrar los cambios realizados

Editar documento

interno

RF-001-03

Permitir desactivar un documento

interno asociado a un proceso o

subproceso

Desactivar

documento interno

RF-001-03-01 Permitir enviar solicitud para desactivar

un documento interno

Crear solicitud

desactivar

RF-001-03-02 Permitir quitar un documento interno en

estado de "Borrador"

Consultar

documentos Internos

RF-002

Permitir la revisión de documento

interno de un proceso o subproceso

antes de su aprobación

Revisar documentos


cambios

Registrar cambios

documento interno


enviar correo con la decisión.

Registrar cambio de

estado

RF-002-02-01 Enviar correo al responsable de la

revisión del documento interno Revisar documentos

RF-002-02-02

Enviar correo al Elaborador para realizar

los cambios sugeridos en el documento

interno

Revisar documentos

RF-003

Permitir la revisión de un documento

interno de un proceso previo a su

aprobación

Revisar documentos


cambios

Registrar cambios

documento interno

80

Tabla A4. (Continuación)


enviar correo con la decisión

Registrar cambio de

estado

RF-003-02-01 Enviar correo al responsable de

aprobación del documento interno Revisar documentos

RF-003-02-02

Enviar correo al Elaborador para realizar

los cambios sugeridos en el documento

interno

Revisar documentos

RF-004 Permitir la aprobación de un documento

interno de un proceso o subproceso Aprobar documentos


cambios

Registrar cambios

documento interno

RF-004-02 Permitir aprobar o rechazar el

documento interno

Registrar cambio de

estado

RF-004-02-01

Enviar correo general al personal de la

empresa con el nuevo contenido de

documento interno

Aprobar documentos

RF-004-02-02 Enviar correo al Revisor para realizar los

cambios sugeridos por el Aprobador Aprobar documentos

RF-004-03

Permitir aprobar o rechazar solicitud

para desactivar un documento interno

de un proceso o subproceso

Aprobar solicitud

RF-005

Permitir gestionar los listados de

documentos externos asociados de un


Consultar

documentos

Externos

RF-005-01 Permitir crear un documento externo Crear documento

externo

RF-005-01-01 Permitir adjuntar archivos en formatos

Word, Excel, PDF

Adjuntar enlace/

archivo

RF-005-02 Permitir editar un documento externo y

registrar los cambios realizados

Editar documento

externo

RF-005-03 Permitir desactivar un documento

externo

Desactivar

documento externo

81

Anexo B

Plan de pruebas SIGC

Objetivos.

El plan de pruebas de Software se elabora con el fin de especificar qué elementos o

componentes se van a probar para que el grupo de trabajo pueda realizar el proceso de

validación y verificación de los requerimientos funcionales y no funcionales del Sistema

Informático de Gestión de la Calidad.

Además, a través del plan de pruebas se puede continuar con la trazabilidad de los

requerimientos, con lo cual el grupo de trabajo, identificar el porcentaje de avance que

se ha logrado hasta cierto momento.

Al desarrollar el plan de pruebas, se puede obtener información sobre los errores,

defectos o fallas que tiene el sistema, así se realizan las correcciones pertinentes, según

el caso y se asegura la calidad del producto que se está entregando al cliente. El plan

de pruebas se aplica sobre el producto, es decir, el código fuente de Sistema Informático

de Gestión de la Calidad.

Estrategia de Pruebas

A través de los diferentes documentos que se han realizado, se pretende retomar

información directamente relacionada con las pruebas, para asegurar la calidad de estas

y del producto. Además le permite al responsable de las pruebas saber exactamente los

criterios que se deben tener en cuenta para probar cada elemento del sistema. A

continuación se explica brevemente el aporte de cada documento con respecto al plan

de pruebas.

82

Alcance

Teniendo en cuenta los documentos hechos anteriormente, el grupo de trabajo pretende

realizar las pruebas, de manera incremental, por módulo. Para una mejor comprensión.

Figura B1. Diagrama de alcance de pruebas

•Priorización: se escogen los requerimientos de mayor priorización para poder aplicar las pruebas correspondientes. Ver documento de Especificacion de Requerimientos

•Trazabilidad: le permite al responsable de la prueba saber el estado de requerimiento. Ver documento de Especificación de Requerimientos.

Especificación de Requerimientos de Softawre.

•Diagrama de Componentes: La separación del sistema por componentes permite la clasificación de las pruebas según la funcionalidad del módulo.

•Diagrama de CU: Permite una mejor visualización de los diferentes escenarios para realizar las pruebas de sistema.

•Vista Física: Prueba de los componentes de Hardware que tiene la aplicación.

Descripción del Software del Diseño

Pruebas unitarias (Pruebas Frontera)

Pruebas de Integracion

Pruebas de Sistema

83

Artefactos De Prueba

Módulos del Programa

En esta sección se muestran los dos módulos a ser probados, los cuales son:

Tabla B1. Módulos y pruebas

Modulo Pruebas Descripción

GUI

Facilidad de

uso

La facilidad de uso consiste en que siempre tengan

el conocimiento sobre qué pueden o qué deberían

hacer los usuarios en cada momento y cómo

hacerlo.

Look & feel Look & feel es la apariencia que se proporciona al

usuario

Lógica de

Negocio Funcionalidad

El sistema debe poder realizar todo los

requerimientos establecidos con el cliente, este

módulo será guiado por los diferentes tipos de

requerimientos que se han manejado durante el

proyecto

DAO Persistencia

El sistema debe ser capaz de guardar datos para ser

usados en otro momento, además de tener acceso

a ellos sin tener ningún problema de consistencia e

integridad.

NO

funcionales

No

funcionales

El sistema debe cumplir con los requerimientos no

funcionales que se han especificado en la

Especificación de Requerimientos S teniendo en

cuenta el diseño.

Procedimientos de Usuario

Para utilizar el sistema de manera adecuada se necesitan guías o manuales que sean

claros, correctos, completos y coherentes, para que el usuario pueda manejar la

herramienta de forma correcta y pueda comprender los conceptos tras la funcionalidad.

A continuación se muestran los diferentes atributos de calidad de estos procedimientos:

Clara: las instrucciones proporcionadas en el documento, deben ser lo

suficientemente explicitas para que el usuario pueda desenvolverse dentro del

entorno de la herramienta.

84

Correcta: No existen errores semánticos, sintácticos, ortográficos ni de enlace

dentro de la documentación proporcionada al usuario.

Completa: la información debe estar completa, desde la parte técnica hasta la

parte funcional.

Coherente: no existen ambigüedades, ni incongruencias dentro del documento

que puedan confundir al usuario.

Características a ser probadas

En esta sección se encuentran las características del sistema a ser probadas con

un caso de estudio específico.

Tabla B2. Características a probar

Característica Descripción Módulo

Requerimientos

Funcionales

Se debe tener en cuenta el criterio de

aceptación y dependencias, para realizar

pruebas en los módulos. Además se debe

utilizar el documento de casos de uso para

tener claro los casos de éxito y fallo, y si la

herramienta cumple con ellos.

Los módulos

donde se puede

probar esta

característica son:

Lógica de Negocio

DAO

Requerimientos

No Funcionales

Se debe tener en cuenta el criterio de

aceptación y lo que exige el requerimiento

para su cumplimiento, especificado en el

documento de especificación de

requerimientos.

El módulo donde

se puede probar

esta característica

es:

No funcionales

85

Características que no serán probadas

En esta sección se encuentran las características de la herramienta a ser probadas con

un caso de estudio específico

Tabla B3. Características que no serán probadas

Característica Descripción Módulo

Procedimientos de

Usuario

No serán probados, debido a que no se

cuenta con el tiempo suficiente para

probar los diferentes criterios,

relacionados con los procedimientos, ya

que se necesitan usuarios con

conocimiento en las áreas de Ingeniería

de software y que conozca el proceso

que se aplica en la asignatura.

Procedimientos de

Usuario

GUI

Debido a que el tiempo es insuficiente, y

no está dentro del alcance del proyecto,

las pruebas de éste módulo no se

realizaran.

El módulo donde

se puede probar

esta característica

son:

GUI

Envío Mail

No será probado él envió de

notificaciones por correo electrónico

utilizando la función sendmail.

Envío de correos

Validación de

credenciales

(usuario y

password)

No será probado debido a que el

sistema estará integrado con el sistema

externo CAS, la configuración del CAS

se la realiza cuando el sistema está

puesto en producción, el CAS maneja

las sesiones de todas las aplicaciones

de la EEQ.

Módulo de

Usuarios.

Aproximación

En esta sección se expone los tipos de pruebas a utilizar para el sistema, cada una de

ellas presenta un formato, el cual se va registrar los resultados.

86

Pruebas Unitarias

Pruebas por cada unidad, en este caso una unidad es equivalente a un requerimiento.

El requerimiento es aprobado y aprobado si este cumple con el estado escrito en la

especificación de requerimientos.

Tabla B4. Pruebas unitarias

NOMBRE Pruebas Unitarias IDENTIFICADOR UT01

ACTIVIDADES Análisis de requerimientos del sistema

TIEMPO ESTIMADO 15 –30 minutos por unidad

MÉTODOS O

HERRAMIENTAS Eclipse STS

ENTREGABLES Lista de chequeo sobre el cumplimiento del requerimiento,

¿realiza lo que el requerimiento describe?

Pruebas de Frontera

Pruebas frontera, son las que toman en cuenta valores límite, para verificar el

comportamiento del sistema en esos casos.

Tabla B5. Pruebas de frontera

NOMBRE Pruebas de Frontera IDENTIFICADOR LT01

ACTIVIDADES Se realizaran las distintas pruebas con los valores límites y

mínimos que debe recibir el programa.

TIEMPO ESTIMADO 15 minutos por prueba

MÉTODOS O


En cuanto a los entregables se debe entregar llena esta tabla:

Tabla B6. Modelo de entregables.

Nombre Identificador T01

Valor máximo Valor mínimo

Resultado esperado

Resultados obtenidos

Estado Funciona: No funciona:

Comentarios

87

Pruebas de Integración

Las pruebas de integración, como su nombre lo indica, son pruebas hechas a un

conjunto de requerimientos, en este caso se distribuyen en los tipos de requerimientos

que se definieron en el documento SRS.

Tabla B7. Pruebas de integración

NOMBRE Pruebas de Integración IDENTIFICADOR IT01

ACTIVIDADES Validación de requerimientos

TIEMPO

ESTIMADO 15 minutos por pruebas

MÉTODOS O


ENTREGABLES Informe generado en donde se indica si se tiene un correcto

funcionamiento o no.

Tabla B8. Modelo de entregables.

Id Grupo de requerimientos Resultados de la prueba

Grupo de requerimientos que están relacionados

dentro del grafo de dependencias Resultado de la prueba.

Pruebas de Sistema

Las pruebas de sistema son pruebas realizadas a la herramienta como un conjunto, que

casos de uso cumple a cabalidad, con rutas de éxito y fallo, que han sido definidas en

el documento de Casos de Uso.

Tabla B9. Pruebas de sistema

NOMBRE Pruebas sistemas IDENTIFICADOR ST01

ACTIVIDADES Se realizaran pruebas funcionales y No funcionales

TIEMPO

ESTIMADO 15 minutos por prueba

MÉTODOS O


ENTREGABLES Informe generado por el responsable de esta prueba el cual

informara si se tiene un correcto funcionamiento o no.

88

Tabla B10. Modelo entregable

Id Caso de uso Resultados de la prueba

Grupo de requerimientos que están

relacionados dentro del grafo de dependencias

Resultado de la prueba.

Proceso de Pruebas

En esta sección se presentan los casos de pruebas generales para usarlos con el

sistema. Cada cuadro está asociado a un caso de Uso, desde ahí se desglosa en los

diferentes módulos involucrados para el funcionamiento y se evalúa el resultado

obtenido. En las siguientes tablas, se muestran los casos de pruebas a realizar

Tabla B11. Caso de pruebas P1

NOMBRE Gestionar Sesiones PRUEBAS P1

PROPÓSITO Verificar el inicio de sesión y el control de acceso

PRERREQUISITOS El usuario debe estar registrado en el sistema

El usuario debe tener un perfil asignado

UBICACIÓN Pantalla de inicio de sesión

ENTRADA El usuario debe ingresar los datos de inicio de sesión

(usuario y contraseña)

RESULTADO

ESPERADO

Inicio de sesión de trabajo y disponible las opciones

asignadas de acuerdo a su perfil

PASOS 1. Ingresar datos de inicio de sesión

2. Pulsar el botón iniciar

MÓDULOS

ASOCIADOS Módulo CAS

89

Figura B3. Inicio del sistema

Figura B4. Home del sistema

90

Tabla B12. Caso de prueba P2

NOMBRE Gestionar Catálogo

Procesos y Subprocesos PRUEBAS P2

PROPÓSITO Verificar la gestión de procesos y subprocesos (nuevo, editar,

eliminar y consultar)

PRERREQUISITOS

Debe existir un sesión activa

Tener los permisos necesarios para realizar dicha

acción.

UBICACIÓN Menú > Administración > Procesos

ENTRADA Datos del proceso o subproceso

RESULTADO

ESPERADO Registro de los datos ingresados, procesos y subprocesos.

PASOS

1. Pulsar proceso o subproceso

2. Ingresar los datos requeridos

3. Pulsar botón Guardar

4. Verificar si los datos se registraron correctamente

MÓDULOS

ASOCIADOS Módulo de administración

Figura B5. Mapa de procesos

91

Figura B6. Crear Proceso

92


NOMBRE Elaborar matriz de

caracterización PRUEBAS P3

PROPÓSITO Verificar la creación y edición de un matriz de caracterización

PRERREQUISITOS


Tener los permisos necesarios para realizar esta

gestión

Registrar todos los datos necesarios (procesos,

responsables, revisores, aprobadores)

UBICACIÓN Menú > Módulos > Procesos > Elaborar - Editar

ENTRADA Datos de la matriz de caracterización

RESULTADO

ESPERADO

Creación de una matriz de caracterización para un proceso o

subproceso.

PASOS

1. Ingresar los datos generales de la matriz de

caracterización entre ellos seleccionar el proceso o

subproceso asociado.

2. Ingresar las entradas y salidas de la matriz de

caracterización

3. Ingresar los recursos

4. Ingresar Objetivos operativos

5. Ingresar riesgos y observaciones

6. Ingresar responsables de la misma (revisores y

aprobador)

7. Verificar los datos ingresados

8. Finalizar para iniciar el proceso de revisión de la


MÓDULOS

ASOCIADOS Módulo de Procesos

93

Figura B7. Elaborar matriz de caracterización

Figura B8. Lista de matrices en estado borrador

94


NOMBRE Revisar matriz de


PROPÓSITO

Verificar las notificaciones del sistema y verificar el flujo de la

matriz que en este caso el proceso de revisión en primera

instancia será por el Sistema de Calidad y luego pasara a sus

revisores asignados.

PRERREQUISITOS Debe existir un sesión activa

Permisos necesarios para realizar la gestión asignada

UBICACIÓN Menú > Módulos > Procesos > Revisar

ENTRADA Decisión sobre el contenido de la matriz de

caracterización

RESULTADO

ESPERADO

Registrar Aprobación o rechazo de la matriz de

caracterización.

En caso de aprobación la matriz continuara con su proceso

normal, caso contrario la matriz regresara a su elaborador

para realizar los cambios sugeridos.

Cuando la matriz registra más de un revisor, únicamente

seguirá con el proceso normal cuando todos sus revisores

hayan aprobado la misma caso contrario regresara a su

elaborador.

PASOS

1. Área de notificaciones

2. Clic en la matriz en cuestión

3. Verificar datos

4. Registrar Aprobación o Rechazo de la matriz (en caso

de rechazo la matriz regresara a su elaborador para

realizar cambios sugeridos)

MÓDULOS


95

Figura B9. Notificaciones de revisión del sistema

Figura B10. Revisión de una matriz de caracterización

96


NOMBRE Aprobar matriz de


PROPÓSITO Verificar las notificaciones del sistema y verificar el flujo de la

matriz que en este caso el proceso de aprobación.



UBICACIÓN Menú > Módulos > Procesos > Aprobar

ENTRADA Decisión sobre el contenido de la matriz de

caracterización

RESULTADO

ESPERADO

Registrar Aprobación o rechazo de la matriz de

caracterización

Aprobar matriz de caracterización, verificar versión de la

misma

PASOS


2. Clic matriz en cuestión

3. Verificar datos

4. Registrar Aprobación o Rechazo de la matriz

MÓDULOS


Figura B11. Notificaciones de aprobación del sistema

97

Figura B12. Aprobación de una matriz de caracterización


NOMBRE Elaborar documento externo PRUEBAS P6

PROPÓSITO Verificar la gestión de un documento externo (nuevo, editar,

consultar y eliminar)



UBICACIÓN Menú > Módulos > Documentos > Externos > Elaborar

ENTRADA Datos del documento externo

RESULTADO

ESPERADO

Registrar los datos ingresados de un documento externo

asociado a un proceso y subproceso

PASOS

1. Ingresar a elaborar documento externo

2. Ingresar datos requeridos

3. Clic en el botón guardar

4. Verificar el si los datos se guardaron correctamente

MÓDULOS

ASOCIADOS Módulo de Documentos

98

Figura B13. Elaborar documento externo

Figura B14. Listado documentos externos creados

99


NOMBRE Elaborar documento interno PRUEBAS P7

PROPÓSITO Verificar la creación y edición de un matriz de caracterización

PRERREQUISITOS


Tener los permisos necesarios para realizar esta

gestión

Registrar todos los datos necesarios (procesos,

responsables, revisores, aprobadores)

UBICACIÓN Menú > Módulos > Documentos > Interno > Elaborar - Editar

ENTRADA Datos del documento interno

RESULTADO

ESPERADO

Creación de un documento interno asociado a un proceso o

subproceso

PASOS

1. Ingresar los datos generales del documento interno

entre ellos seleccionar el proceso o subproceso

asociado.

2. Ingresar el contenido del documento interno de

acuerdo al tipo seleccionado en el anterior paso

3. Ingresar responsables de la misma (revisores y

aprobador)

4. Verificar los datos ingresados

5. Finalizar para iniciar el proceso de revisión del

documento interno

MÓDULOS


100

Figura B15. Elaboración documento interno

Figura B16. Listado documentos internos en estado borrador

101


NOMBRE Revisar documento interno PRUEBAS P8

PROPÓSITO

Verificar las notificaciones del sistema y verificar el flujo del

documento que en este caso el proceso de revisión en

primera instancia será por el Sistema de Calidad y luego

pasara a sus revisores asignados.



UBICACIÓN Menú > Módulos > Documentos > Interno > Revisar

ENTRADA Decisión sobre el contenido del documento interno

RESULTADO

ESPERADO

Registrar Aprobación o rechazo del documento interno

En caso de aprobación el documento continua con su proceso

normal, caso contrario el documento regresara a su

elaborador para realizar los cambios sugeridos.

Cuando el documento registra más de un revisor, únicamente

seguirá con el proceso normal cuando todos sus revisores

hayan aprobado el mismo caso contrario regresara a su

elaborador

PASOS


2. Clic en el documento en cuestión

3. Verificar datos

4. Registrar Aprobación o Rechazo del documento (en

caso de rechazo el documento regresara a su

elaborador para realizar cambios sugeridos)

MÓDULOS


102

Figura B17. Notificaciones de revisión de documentos internos

Figura B18. Revisión documento interno

103


NOMBRE Aprobar documento interno PRUEBAS P9

PROPÓSITO Verificar las notificaciones del sistema y verificar el flujo del

documento, que en este caso el proceso de aprobación.



UBICACIÓN Menú > Módulos > Documentos > Interno > Aprobar

ENTRADA Decisión sobre el contenido del documento interno

RESULTADO

ESPERADO

Registrar Aprobación o rechazo del documento interno

Aprobar documento, verificar versión del mismo

PASOS


2. Clic documento en cuestión

3. Verificar datos

4. Registrar Aprobación o del documento

MÓDULOS


Figura B19. Notificaciones de aprobación documento interno

104

Figura B20. Aprobación documento interno

Documents

UNIVERSIDAD CENTRAL DEL ECUADOR … · administración pública con criterios de calidad y excelencia, con la aplicación de buenas prácticas y con la adopción de estándares internacionales”