GESTIÓN DE CONTRATOS

1. Datos de la Empresa: IT DATa Consulting

2. Principios y políticas de calidad

IT Data Consulting es una empresa dedicada a desarrollar soluciones informáticas a la

medida de las diversas empresas peruanas dentro de los sectores Banca, Comercio e
Industria, con el fin de satisfacer sus necesidades de negocio.

Nuestro staff de profesionales cuenta con un alto nivel de especialización en las herramientas
de mayor demanda en el mercado actual y está conformado por arquitectos de soluciones,
especialistas en inteligencia de negocios, especialistas en implementación de soluciones en
ERP’s (ORACLE EBS y SAP), plataformas Web y Cliente/Servidor; así como personal para
soporte operativo y soporte técnico, garantizando así la calidad y eficacia de nuestros
servicios.

1.1. Misión

“Trabajar cada día para hacer de nuestros servicios las mejores soluciones en
aplicaciones, actuando como socio estratégico de confianza para nuestros
clientes y colaboradores, diferenciandonos por nuestra excelencia, calidad,
experiencia y compromiso”.

1.2. Visión

“Ser una empresa líder de soluciones tecnológicas innovadoras de alta calidad,

alineando la tecnología a las estrategias de negocios. Logrando el reconocimiento de
nuestros clientes por la calidad en los servicios que ofrecemos y de nuestros
colaboradores como una empresa de alto valor para su desarrollo profesional”.

1.3. Servicios

Los servicios que ofrece IT DATA consulting son :

(Fuente: http://itdata.com.pe/index.php )
 1.3.1. Implementación de ERP’s
El servicio de implementación de sistemas integrados ERP surge gracias al
objetivo de mejorar el control de la información así como facilitar el crecimiento
de la misma.

1.3.2. Actualizaciones y migraciones

El servicio de Actualizaciones y migraciones permite mejorar el control de

negocios a través de actualizaciones de sistemas estables, facilitando la
implementación de soluciones bajo una estructura dinámica, soportada por
metodologías y buenas prácticas, que permiten un mantenimiento rápido y
efectivo de las aplicaciones.

1.3.3. Testing Factory

El servicio Testing Factory tiene por objetivo principal asegurar la calidad de los
entregables de la solución tecnológica de nuestros clientes, gracias a nuestra
metodología de aseguramiento de la calidad.

1.3.4. Desarrollo de Software Web

El servicio de desarrollo de software permite la realización de sistemas

BackOffice que permite a los clientes ser autosuficientes en la administración
de contenidos de sus aplicaciones

Índice

Introducción

El presente trabajo ya sido desarrollado tomando como base las normas de calidad ISO
90003,9126, la norma IEEE 830 así como el libro “El Proceso Unificado de Desarrollo”.
Asimismo, está orientado al control de versiones de documentos y de software del caso de

1
estudio, el cual es el Fondo de Seguro de Retiro y Cesación de la Marina de Guerra del Perú
y como producto a analizar el software SDA que ha sido implementado en dicha institución

Marco Teórico o Estado del Arte

Se pretende crear procedimiento de revisión de contratos que pueda ser aplicado como algo
útil para la administración y desarrollo de un producto dentro de una organización. Es
necesario tener en cuenta que en todo desarrollo de un proyecto es de suma importancia
definir una metodología. Esto permite a las organizaciones seguir alguna especificación en
cada etapa de la revisión de un contrato. Desde los requerimientos del cliente hasta la
aceptación del contrato de manera coherente y clara.

En este capítulo abordaremos las normas de calidad tomados en cuenta durante todo el
proceso de elaboración del contrato. Las normas que a continuación trataremos 7.2.2
Revisión de los requisitos relacionados con el producto y 7.5.1.7 Mantenimiento de la ISO
90003, las cuales darán pautas sobre los estándares utilizados tanto para la elaboración,
verificación y aceptación de un contrato. La re-ingeniería examinará las normas existentes
para actualizarla y mejorarla.

2
 Tabla de Control de Cambios de Documentos

Revisión 02 03 04 05 06 Observaciones
Página

4 13/02/2017 Actualización de
responsable

4 14/02/2017 Descripción de
abreviatura.

5 16/02/2017 Descripción de
procedimiento

3
Desarrollo de Procedimientos
● Procedimiento específico por grupo G. de Contratos

1. OBJETIVO
Definir el procedimiento para la revisión de contratos, con la finalidad de que existan documentos
formales sobre los acuerdos realizado con los clientes para así poder evidenciar los compromisos
pactados por ambas partes.
2. ALCANCE
Aplica a todos los proyectos tanto de desarrollo de software y/o consultoría. Debe permitir el detalle
suficiente para asegurar que todos los acuerdos realizados con el cliente sean entendibles,
aceptados para las partes involucradas.

Este procedimiento no será de cumplimiento obligatorio en caso exista un conflicto con los requisitos
mencionados en el contrato. En este caso se crearán procedimientos al respecto de tal manera se
ajusten en la máxima extensión posible a este documento.

Cuando los requisitos sean modificados. También la documentación debe ser modificada y el
personal involucrado debe estar al tanto de los cambios.

3. RESPONSABLES
3.1 Director General: Es la autoridad máxima dentro la organización además de ser el encargado de la
gestión y dirección administrativa.
3.2 Administrador: Encargado de optimizar los recursos existentes dentro de la organización.
3.3 Coordinador de Calidad: Encargado de verificar que se cumplan y establezcan y mantengan los
procesos necesarios para el sistema de gestión de la calidad.
3.4 Gerente de Finanzas: Encargado de la gestión financiera de la organización además de la
planificación, ejecución y reportes financieros.
3.5 Jefe de Sistemas: Responsable de la organización y control de la implementación de los sistemas
informáticos asimismo de asegurar su correcto funcionamiento.
4. DEFINICIONES Y ABREVIATURAS
4.1
Término Definición Abreviación

Manual de Calidad Documento que especifica el MDC

sistema de gestión de calidad
SGC

Procesos Relación de actividades PRC

relacionadas entre sí que
transforman elementos de entrada
en resultados.

Instructivo Documento que describe el INT

paso a paso del desarrollo de una
actividad en relación con la parte
Operativa.

Procedimiento Documento que provee GF

información detallada sobre la
forma de ejecutar las actividades
y los procesos de una manera
ordenada.

4
 Registro Documento que proporciona JS
evidencia
de las actividades ejecutadas y
de la conformidad de los
requisitos, así como de la
operación del sistema de
gestión de la calidad

Documento obsoleto Documentos que han sido DOB

modificados y
que tienen versiones anteriores y
que ya no están actualizados , ni
son de uso en la actualidad

Listado Maestro de Documentos Listados de los documentos que LMDR

y Registros son parte del SGC . Registra el
número de versiones que tienen
los documentos del SGC, la
última fecha de actualización, la
ubicación, el responsable, el
proceso al cual pertenece, el
acceso, la retención y la
disposición.

Sistema de Gestión de Calidad Actividades coordinadas dentro SGC

una organización orientadas a
obtener y mantener el nivel de
calidad de un producto o servicio
de acuerdo con las necesidades
de un cliente.

5. DOCUMENTOS DE REFERENCIA
5.1 NORMA ISO/IEC 90003:2004,
NORMA ISO 9001 . apartado 7.2.2
7.2.2 Revisión de los requisitos relacionados con el producto
Manual de Procedimientos
Certificación de cuenta bancaria
Carta de presentación de oferta de servicios
6. DISPOSICIONES ESPECÍFICAS
6.1 No aplica
7. Precondición
7.1 Acta de requerimientos.
Documento de cotización de proveedores
Formulario de Inscripción
Declaración jurada del postulante
Documento de bases legales
Cronograma de Convocatoria
Documento de planificación
8. Poscondición
8.1 Acta de Calificación.
Acta de Resultados Finales.
Contrato.
9. DESARROLLO
RESPONSABLE DESCRIPCIÓN DE LA ACTIVIDAD

5
 Administrador Solicitud de revisión: El cliente solicita la revisión de contrato mediante el
formato “Solicitud de revisión de contrato” debidamente llenado
9.1
incluyendo los documentos anexos y una copia del contrato.

Coordinador de Recepción de la solicitud de revisión: Se procede a la recepción del

Calidad contrato y los documentos anexos adjuntos para luego verificar la
documentación detalladamente; si la solicitud cumple con los requisitos se
9.2
procede a darle trámite, caso contrario se devuelve la solicitud con una nota
indicando su rechazo.

Gerente de Finanzas Atención de solicitud de revisión: Se atiende la solicitud de revisión de

contratos, constatando los anexos y revisando los requisitos solicitado por los
usuarios siendo estos necesarios para su cumplimiento además de las
9.3 cláusulas contenidas dentro del contrato para determinar que no hubieran
obligaciones o compromisos que posteriormente no se puedan cumplir por
parte de la organización.

Jefe de Sistemas Remisión de solicitud de revisión: Se procede a la respuesta escrita a la

9.4 solicitud de revisión. El plazo para la respuesta a la solicitud de revisión es de
cinco (5) días hábiles después de la recepción de la solicitud.

Analista Programador Archivar solicitud de revisión: Posterior al envío de respuesta a la solicitud

de revisión de contrato, se procede a recoger la conformidad de satisfacción
9.5
del servicio, al personal que realizó la solicitud. Finalmente se archiva la
solicitud de revisión en una carpeta.
10 REGISTROS
10.1 Acta contractual
10.2 Acta de reunión
11 ANEXOS
11.1 Lista de aprobación de contrato
11.2 Documento de aceptación de contrato

Lista de aprobación de contrato

La lista de comprobación define los criterio y características que se debe cumplir el mismo, y los
aspectos que deben tener en cuenta a la hora de realizar la revisión.

6
Documento de aceptación de contrato
Una vez realizada la revisión, si se cumplen las características deseadas, se debe dejar
evidencia que se realizó la actividad y que el contrato ha sido aceptado.

7
 Tabla de Control de Cambios de Documentos

Revisión de 01 02 03 04 Observaciones
Página

10 19/02/2017 Se agregó el
proceso de
Mantenimiento

11 20/02/2017 Definición de
abreviaturas

12 21/02/2017 Definición de
desarrollo

Procedimiento de Mantenimiento

1. OBJETIVO

Definir el procedimiento que permita el mantenimiento del software para que existan
documentos formales sobre los acuerdos realizados en base al mantenimiento. Esto
establecerá actividades que permitan la revisión y el mantenimiento de lo entregado al
cliente, una vez esto realizado el contrato podrá asegurar la calidad en el mantenimiento
del producto.

2. ALCANCE

Aplica a todos los proyectos de software y/o consultoría de sistemas . El alcance se centra
en detallar en el contrato el mantenimiento del software post instalación y entrega inicial.
Logrando que todo el detalle sean entendido y aceptado por las partes involucradas.

El documento debe asegurar que se tenga un alcance del Mantenimiento, identificación de

un status inicial de los elementos que recibirán el mantenimiento,
Asimismo también se asegura el detalle de actividades de mantenimiento para la
resolución de problemas de soporte de software . Culminando por actividades de gestión
de la configuración, pruebas , registros y reportes de mantenimiento.

8
3. RESPONSABLES

3.1 Director General: Es la autoridad máxima dentro la organización además de ser el

encargado de la gestión y dirección administrativa.

3.2 Administrador: Encargado de optimizar los recursos existentes dentro de la organización.

3.3 Coordinador de Calidad: Encargado de verificar que se cumplan y establezcan y

mantengan los procesos necesarios para el sistema de gestión de la calidad.

3.4 Gerente de Finanzas: Encargado de la gestión financiera de la organización además de la

planificación, ejecución y reportes financieros.

3.5 Jefe de Sistemas: Responsable de la organización y control de la implementación de los

sistemas informáticos asimismo de asegurar su correcto funcionamiento.

4. DEFINICIONES Y ABREVIATURAS

4.1
Término Definición Abreviación

Manual de Calidad Documento que especifica el sistema de MDC

gestión de calidad SGC

Procesos Relación de actividades relacionadas entre sí PRC

que transforman elementos de entrada en
resultados.

Instructivo Documento que describe el paso a paso del INT

desarrollo de una actividad en relación con la
parte Operativa.

Procedimiento Documento que provee información GF

detallada sobre la forma de ejecutar las
actividades y los procesos de una manera
ordenada.

Registro Documento que proporciona evidencia JS

de las actividades ejecutadas y de la
conformidad de los requisitos, así como de la
operación del sistema de gestión de la
calidad

Documento Documentos que han sido modificados y DOB

obsoleto que tienen versiones anteriores y que ya no están
actualizados , ni son de uso en la actualidad

Listado Maestro Listados de los documentos que son parte del LMDR
de Documentos y SGC . Registra el número de versiones que
Registros tienen los documentos del SGC, la última
fecha de actualización, la ubicación, el
responsable, el proceso al cual pertenece, el
acceso, la retención y la disposición.

9
 Sistema de Actividades coordinadas dentro una organización SGC
Gestión de Calidad orientadas a obtener y mantener el nivel de
calidad de un producto o servicio de acuerdo con
las necesidades de un cliente.

5. DOCUMENTOS DE REFERENCIA

5.1 NORMA ISO/IEC 90003:2004, 7.5.1.7 Mantenimiento

6. DISPOSICIONES ESPECÍFICAS

6.1 No aplica

7. Precondición

7.1 Documento de actividades

Documento de empleados participantes
Contrato

8. Poscondición

8.1 Acta de realización del mantenimiento

Guia del Proceso

7. DESARROLLO

RESPONSABLE DESCRIPCIÓN DE LA ACTIVIDAD

7.1 Administrador Responsable de recibir las solicitudes de ofertas, preparar las

ofertas y aprobarlas, recibir los pedidos de solicitudes especiales,
revisar y poner en marcha los planes de calidad y revisar las
instalaciones.

7.2 Coordinador de Actúa como representante de la Dirección y tiene la autoridad y la

Calidad responsabilidad para asegurar que se pone en práctica los
requisitos contenidos en el Manual.

Significa que antes de cada reunión, debe recopilar todos los

datos que cierren periodo:

● Ofertas
● Encuestas
● No conformidades y reclamaciones de los clientes
● Objetivos e indicadores
● Mejoras
● Cambios significativos en la operatividad de la empresa
como puede ser un cambio de sistema informático o de

10
 archivo.
● Supervisa los documentos internos del sistema de calidad y
mantiene los listados actualizados.

7.3 Gerente de Finanzas Responsable de la ejecución e información financiera que se

realice en el los términos del contrato.

7.4 Jefe de Sistemas Encargado de verificar las tecnologías y metodologías

presentadas. Así mismo dará una opinión objetiva respecto al
producto presentado

7.5 Analista Programador Encargado de recibir los requerimientos de los usuarios finales
para su evaluación e implementación. Validación de nuevas
funcionalidades para una mejor optimización del sistema. Además
de verificar e informar el rendimiento del servidor con respecto al
sistema.

8. REGISTROS

8.1 Acta contractual

8.2 Acta de reunión

9.0 ANEXOS

9.1 Documento de aceptación de contrato

11
 Tabla de Control de Cambios de Documentos

Revisión 02 03 04 05 06 Observaciones
Página

14 15/02/2017 Modificación del

objetivo

14 16/02/2017 Definición de
abreviaturas

15 17/02/2017 Descripción de la
actividad

12
 ● Procedimiento de Análisis

1. OBJETIVO

Definir el procedimiento y el proceso para la gestión del análisis basado en RUP

para lograr una compresión y una descripción de los requisitos, por los cuales se
puede mantener y estructurar el sistema en su totalidad.

2. ALCANCE

La documentación del Modelo de Análisis incluye la Descripción de la arquitectura, la

Realización de Casos de Uso, el Modelo de análisis, los Prototipo IGU y las Métricas
de análisis.

3. RESPONSABLES

3.1 Arquitecto: Es el responsable de realizar el Modelo de análisis y la

descripción de la arquitectura.

3.2 Analista de Sistemas: Es el responsable de realizar el análisis de la

Realización de los casos de uso.

3.3 Ingeniero de componentes: Es el responsable de analizar y diagramar las

clases de análisis y los paquetes de análisis.

4. DEFINICIONES Y ABREVIATURAS

4.1 Requisitos: Son los requerimientos del cliente del sistema. Es decir, que debe y
que no debe hacer el sistema. La lista de requisitos es capturada en la
especificación de requisitos.

4.2 RUP (Rational Unified Process): Es el Proceso Unificado de Desarrollo de

Software, el cual se caracteriza por estar dirigido por casos de uso, enfocado en la
arquitectura de software y por ser iterativo e incremental. Además, representa la
unión de metodologías, antes separadas, para el desarrollo de software.

4.3 Actor: Rol que representa a quien inicia y/o se beneficia del caso de uso.

4.4 Caso de Uso: Es una secuencia de acciones que el sistema lleva a cabo para
ofrecer algún resultado de valor para un actor del sistema, quien representa el rol
de quien inicia y/o se beneficia del caso de uso.

4.5 Modelo análisis: Modelo que tiene como propósito refinar los casos de uso con
más detalle y establecer la asignación inicial de funcionalidad del sistema a un
conjunto de objetos que proporcionan el comportamiento.

4.6 Clases de análisis: Mediante el cual se identifica a todo aquello que encapsula un
tipo diferente de comportamiento (funcionalidad).

13
4.7 Paquetes de análisis: Conjuntos de casos de uso, los cuales organizan el modelo
"de análisis en partes más manejables que representan abstracciones de
subsistemas y posiblemente capas completas del diseño del sistema.

5. DOCUMENTOS DE REFERENCIA

5.1 NORMA ISO/IEC 90003:2004

5.2 Proceso Unificado de Desarrollo de Software, Capítulo 7

6. Precondición

6.1 Se debe haber desarrollado el Modelado de Negocio y Requerimientos

7. Poscondición

7.1 Especificación del modelo de análisis del contrato

8. DESARROLLO

RESPONSABLE DESCRIPCIÓN DE LA ACTIVIDAD

8.1 Arquitecto Integridad de modelado de análisis

Se garantiza que la integridad sea correcta, consistente

y legible, estableciendo una base para la creación de
un diseño de software.

8.2 Arquitecto Arquitectura del modelo de análisis

El análisis de la arquitectura se centra en la definición

de una arquitectura candidata y en la restricción de las
técnicas de arquitectura que se van a utilizar en el
sistema

8.3 Ingeniero de Realización de casos de uso - análisis

Casos de Uso
Representa la perspectiva de diseño de un caso de
uso. Además se garantiza que que tanto sus
descripciones y diagramas sean legibles y afines a su
objetivo.

8.4 Ingeniero de Clase de Análisis

Componentes
Representan clases prototípicas del sistema, y son un
primer paso de las abstracciones principales que el
sistema debe manejar.

14
8.5 Ingeniero de Paquete de Análisis
Componentes
Los paquetes del análisis proporcionan un medio para
organizar los artefactos del modelo de análisis.

9. REGISTROS

9.1 Modelo de Análisis

9.2 Descripción de la arquitectura

9.3 Realización de los casos de uso de análisis

9.4 Clases de análisis

10. ANEXOS - MÉTRICAS

10.1 Cantidad de Casos de Uso realizados

Cantidad de Prototipos diseñados
Cantidad de Clases de Análisis
Cantidad de Horas/Hombre consumidas en la actividad.
Cantidad de errores o no conformidades por cada entregable.
Cantidad de no conformidades del cliente con el Modelo de Análisis.

Formato Propuesto
DOCUMENTO DE ANÁLISIS

MDP_PY0001_DA001_Documento de
Especificación
de Análisis

Versión.- 1.0 Fecha: xx/xx/xxxx

Responsable:

Clase de Análisis:

Caso de Uso: <<Se coloca el nombre del caso de uso>>

Actor(es): <<Se coloca al actor u actores asociados al caso de uso>

Propósito: <<Se especifican los botones de acción de la aplicación>>

Iteración <<Se ingresa el número de iteración asociado al caso de uso>>

15
Descripción: <<Se especifica la descripción de la aplicación>>

Requerimientos <<Se especifican los requerimientos funcionales asociados a la aplicación>>

Funcionales

Reglas de <<Se especifican las reglas de negocio asociadas al caso de uso>>

Negocio:

Precondiciones <<Se especifican las precondiciones del caso de uso>>

PostCondiciones <<Se especifican las postcondiciones del caso de uso>>

Flujo Básico de <<Se especifica el flujo básico del caso de uso>>

Eventos

Opciones: <<Se especifican los botones de acción de la aplicación>>

Diagrama de Clases de Análisis

<<Se coloca el diagrama de análisis del caso de uso>>

Diagrama de Colaboración

<<Se coloca el diagrama de análisis del caso de uso>>

Diagrama de Secuencia

<<Se coloca el diagrama de secuencia del caso de uso>>

Diagrama de Clases

<<Se coloca el diagrama de clases>>

Diagrama de Actividades

<<Se coloca el diagrama de actividades del caso de uso>>

Tabla de Control de Cambios de Documentos

Revisión 02 03 04 05 06 Observaciones
Página

19 18/02/2017 Procedimiento de
diseño

20 19/02/2017 Definición de
abreviaturas

16
 21 20/02/2017 Desarrollo

● Procedimiento de Diseño

1. OBJETIVO

Definir el procedimiento y el proceso para la gestión del diseño basado en RUP, con el fin
de lograr una comprensión y proporcionar evidencia que represente el compromiso
realizado con en la gestión de contratos.

2. ALCANCE

Aplica a todos los proyectos de desarrollo de software que se realicen en la organización.

Se debe permitir contar con un detalle suficiente que asegure que los requisitos realizados
por el cliente puedan ser entendibles, aceptados y medibles para brindar la calidad del
contrato.

3. RESPONSABLES

3.1 Arquitecto: Es el responsable de realizar el Modelo de análisis y la descripción de la

arquitectura.

3.2 Analista de Sistemas: Es el responsable de realizar el análisis de la Realización de los

casos de uso.

3.3 Ingeniero de componentes: Es el responsable de analizar y diagramar las clases de

análisis y los paquetes de análisis.

4. DEFINICIONES Y ABREVIATURAS

4.1 Requisitos: Son los requerimientos del cliente del sistema. Es decir, que debe y que no
debe hacer el sistema. La lista de requisitos es capturada en la especificación de
requisitos.

4.2 RUP (Rational Unified Process): Es el Proceso Unificado de Desarrollo de Software, el

cual se caracteriza por estar dirigido por casos de uso, enfocado en la arquitectura de
software y por ser iterativo e incremental. Además, representa la unión de metodologías,
antes separadas, para el desarrollo de software.

4.3 Actor: Rol que representa a quien inicia y/o se beneficia del caso de uso.

17
4.4 Artefactos: Es la especificación de un componente físico de información que es usado o
producido por un proceso de desarrollo de software, o por el desarrollo y operación de un
sistema.

4.5 Caso de Uso: Es una secuencia de acciones que el sistema lleva a cabo para ofrecer
algún resultado de valor para un actor del sistema, quien representa el rol de quien inicia
y/o se beneficia del caso de uso.

4.6 Diagrama de Clases: Es una clase de diseño, sus objetos y los subsistemas que
contienen las clases de diseño

4.7 Modelo análisis: Modelo que tiene como propósito refinar los casos de uso con más
detalle y establecer la asignación inicial de funcionalidad del sistema a un conjunto de
objetos que proporcionan el comportamiento

4.8 Clases de análisis: Mediante el cual se identifica a todo aquello que encapsula un tipo
diferente de comportamiento (funcionalidad).

4.9 Paquetes de análisis: Conjuntos de casos de uso, los cuales organizan el modelo "de
análisis en partes más manejables que representan abstracciones de subsistemas y
posiblemente capas completas del diseño del sistema.

5. DOCUMENTOS DE REFERENCIA

5.1 El Proceso Unificado de desarrollo de software

5.2 NTC-ISO/IEC 90003:2004

6. DISPOSICIONES ESPECÍFICAS

6.1 Los casos de uso deben mantenerse tan independientes unos de otros como sea posible

6.2 Los casos de uso deben describirse utilizando el lenguaje del cliente

6.3 Debe estructurarse cada caso de uso para que forme una especificación de funcionalidad
completa

7. Precondición

7.1 Lista de requisitos del usuario aprobados

7.2 Diagrama de Casos de Uso del Negocio

7.3 Diagrama de Actividad

7.4 Diagrama de Entidades del Negocio

7.5 Diagrama de Trabajadores del Negocio

7.6 Lista de Reglas de Negocio

18
7.7 Modelo de Dominio

8. Poscondición

8.1 Especificación del modelo de análisis del producto aceptado o rechazado

7. DESARROLLO

RESPONSABLE DESCRIPCIÓN DE LA ACTIVIDAD

7.1 Arquitecto Elaboración modelo de diseño, modelo de análisis.

Integra el modelo de análisis.
7.1.1 Ciclo de vida del software

7.2 Ingeniero de Elaboración de clase de diseño

componentes
7.1.1 Ciclo de vida del software

7.3 Ingeniero de Elaboración de la Realización de Casos de Uso de diseño

casos de uso
7.1.1 Ciclo de vida del software

7.4 Ingeniero de Elaboración del Diagrama de Clases

componentes
7.1.1 Ciclo de vida del software

7.5 Ingeniero de - Elaboración del Diagrama de Interacción

componentes - Definir y mantener las responsabilidades, atributos,
relaciones, y requisitos especiales de las clases del análisis
7.1.1 Ciclo de vida del software

7.6 Arquitecto Elaboración del Modelo de Despliegue

7.1.1 Ciclo de vida del software

7.7 Ingeniero de Elaboración de Interfaces

componentes
7.1.1 Ciclo de vida del software

7.8 Ingeniero de Elaboración de Subsistema de Diseño

componentes Mantener la integridad de los paquetes del análisis
7.1.1 Ciclo de vida del software

8. REGISTROS

8.1 Plantilla de Registro de Documento

8.2 Formato - Lista Maestra de Control de Documentos

19
 8.3 Plantilla de Modelo de Análisis

9. ANEXOS

9.1 Anexo 01: Plantilla Registro de Documento

Anexo 02: Formato - Lista Maestra de Control de Documentos

Gestión de Calidad
● Alcances y Objetivos
Objetivos
(Documento drive: definición de objetivos de la calidad)

● Aspectos Organizacionales: Políticas, Organización, Recursos y otros

Políticas:
1. Cumplir con la legislación y normativa peruana.
2. Otorgar un trato de amable y servicial en todo momento.
3. Satisfacer las necesidades del cliente.
4. Buenas prácticas con CMMI Nivel 3 PMI (Project Management Institute, 2004).
5. Medición de los resultados además de una mejora continua.
6. Gestionar los recursos necesarios para apoyar la ejecución, seguimiento y
mejora continua del Sistema de Gestión de la Calidad.

20
 Organización:

Los recursos a utilizar para realizar la Gestión de Calidad al sistema esta conformado de la
siguiente manera.

➢ Gerente de Proyectos
➢ Jefe de Desarrollo
➢ Arquitecto de software
➢ Analista de Negocio
➢ Analista de Sistemas
➢ Programador
➢ Implementador
➢ Analista Tester

● Normas usadas y referencias indicadas

21
● Gestión de Calidad del Producto

○ Objetivo

Obtener información sobre los errores, defectos o fallas que tiene el prototipo, así
realizar las correcciones pertinente según sea el caso y se asegurar la calidad del
producto que se está entregando al cliente.

Para obtener esta información necesitamos elaborar el plan de pruebas que se

aplicará sobre el producto, los resultados de las pruebas son registrados en un
formato denominado Reporte de Pruebas. Las pruebas a implementar son básicas,
esto incluye las pruebas unitarias y de integración que son vitales para la validación
del producto.

Especificación de requerimientos de software

Según la norma ISO 9126 los requerimientos de calidad del producto a construir son
considerados dentro de atributos específicos del software que tienen incidencia sobre
la calidad en el uso y se detallan a continuación:

Confiabilidad
a) Tolerancia a fallos
b) Madurez
c) Recuperabilidad

Usabilidad
a) Aprendible
b) Comprensible
c) Operable
d) Atractivo

Mantenibilidad
a) Modificable
b) Analizable
c) Estable, no se producen efectos inesperados luego de modificaciones
d) Verificable
Funcionalidad
a) seguridad de los datos
b) adecuación a las necesidades

22
 b) precisión de los resultados

Eficiencia
a) comportamiento respecto al tiempo
b) utilización de recursos

De acuerdo a estos principios elaboramos las siguientes métricas:

MÉTRICA DE MANTENIBILIDAD

● MÉTRICA INTERNA DE FACILIDAD PARA EL CAMBIO

Nombre: REGISTRABILIDAD

Propósito: Registrar los cambios específicamente y colocar los

comentarios en el código fuente

Método de Registrando los cambios al código fuente de los

aplicación: módulos.

● MÉTRICA EXTERNA DE FACILIDAD PARA EL CAMBIO

Nombre: EVALUACIÓN DEL CAMBIO

Propósito: Evaluar los cambios requeridos al sistema y verificar

que estén alineados a los objetivos de la organización

Método de Aplicar un rango de variación a los requerimientos que

aplicación: figuran en el contrato.

● MÉTRICA INTERNA DE ESTABILIDAD

Nombre: FRECUENCIA DE FALLOS

Propósito: Registrar adecuadamente cada comportamiento

inesperados que presente el sistema.

Método de Registrar una lista (CheckList) con los posibles fallos a

aplicación: encontrarse y/o encontrados antes/después del
cualquier modificación.

23
 ● MÉTRICA EXTERNA DE ESTABILIDAD

Nombre: FRECUENCIA DE CIERRES INESPERADOS

Propósito: Identificar el número de veces que el sistema por

problemas internos se cierra completamente sin ningún
aviso al usuario.

Método de Registrar el número de cierres en un rango de tiempo

aplicación: por ejemplo 1 hora de uso constante del producto.

MÉTRICA DE EFICIENCIA

● MÉTRICA INTERNA DE COMPORTAMIENTO EN EL TIEMPO

Nombre: Tiempo de respuesta

Propósito: Indicar cuál es el tiempo estimado para completar
una determinada actividad.
Método de Evaluar la eficiencia de la conexión al S.O. con las
aplicación: aplicación en cada operación que realiza un usuario.

● MÉTRICA INTERNA DE COMPORTAMIENTO EN EL TIEMPO

Nombre: Factor de Stress

Propósito: Medir la relación entre el tiempo de respuesta del sistema
para una determinada carga y el tiempo de respuesta
para la carga mínima de información.
Método de Se mide el factor de aumento a medida que la cantidad
aplicación: de información solicitada o cargada al sistema aumenta.

24
PLAN DE PRUEBAS:
Nombre del Proyecto: Versiones de documento y software

Caso N° 1

Nombre Informe del cambio

Ejecutado por Roger Garay

Propósito Probar la funcionalidad de cambio de documentos

Fecha 18/02/2017

Detalle de prueba

Norma ISO 9126

Atributo: Funcionalidad – Seguridad

● Realizar un cambio a un documento

● Guardar el documento y cerrar el archivo
● Dar botón derecho al documento y seleccionar “Actualizar versión”
● El sistema mostrará una ventana para que indique el motivo del cambio
● Se escribe el nombre del cambio y se da clic en el botón guardar
● El sistema debe colocar un ícono de forma circular de color verde al costado
del nombre del archivo indicando que fue sincronizado correctamente.

Resultado esperado

Al hacer el envío del cambio, el sistema debe mostrar una ventana para que indique
el motivo del cambio y luego de ingresar lo solicitado debe ver el cambio reflejado en
el repositorio central virtual de archivos con el nuevo número de versión y el archivo
tendrá un ícono de forma circular de color verde al costado del archivo indicando
que el cambio fue satisfactorio.

Riesgo

No exista conexión de red local

Nombre del Proyecto: Versiones de documento y software

Caso N° 2

Nombre Seguridad en el cambio

Ejecutado por Roger Garay

Propósito Probar la seguridad en el cambio de versión

25
Fecha 18/02/2017

Detalle de prueba

Norma ISO 9126

Atributo: Funcionalidad – Seguridad

● Hacer un cambio a un documento

● Guardar el documento y cerrar el archivo
● Dar botón derecho al documento y seleccionar “Actualizar versión”
● El sistema mostrará una ventana indicando que no tiene acceso a realizar
cambios y el sistema bloqueará el archivo.
● El sistema enviará automáticamente un correo electrónico al administrador
del repositorio central con el detalle de la infracción de acceso que contiene:
- Nombre del equipo del emisor
- Nombre del archivo
- Nombre de inicio de sesión del sistema opera el emisor
- Fecha y hora del incidente

Resultado esperado

Al intentar enviar un cambio el sistema debe rechazar el cambio si es que el usuario

no tiene permisos al mismo por medio de un mensaje de información que indique:
“El archivo no puede modificarse debido a que no tiene acceso a realizar cambios
sobre el mismo”. Luego, el sistema bloqueará el archivo y enviará una alerta al
administrador del repositorio virtual.

● Gestión de Calidad del Proceso

Objetivo
El propósito del presente documento es dar a la Gerencia del IT DATa
Consulting un conjunto de lineamientos necesarios para asegurar la calidad
del documento a consolidar.

Referencia
NORMA ISO/IEC 90003:2004,
NORMA ISO 9001 . apartado 7.2.2
7.2.2 Revisión de los requisitos relacionados con el producto
Organización
NORMA ISO/IEC 90003:2004,
NORMA ISO 9001 . apartado 7.5.1.7
Actividades a realizar
Este documento permite revisar y documentar las etapas del ciclo de vida de

26
 la implementación de los módulos y los servicios en el Sistema de IT DATa
Consulting:
Las etapas antes mencionados son:
● Análisis de la solución
● Diseño de la solución
● Desarrollo de la solución
● Pruebas de la aplicación

El siguiente cuadro nos muestra los productos en cada proceso.

Proceso/Área Producto

Requerimientos ● Especificaciones de requerimientos de software.

● Modelo de caso de uso.

Análisis ● Modelo del dominio de clases o modelo conceptual.

○ Lista y diagrama de actores.
○ Diagrama de paquetes.
○ Diagrama de casos de uso por paquete.
○ Especificación de Casos de Uso de Alto Nivel.
○ Diagrama General de casos de uso.
○ Lista de casos de uso priorizados.
○ Lista de casos de uso que impactan en la
arquitectura.
● Realización de los casos de uso para el análisis.
● Diagrama de máquinas de estado.

Diseño ● Diagrama de casos de uso que impactan en la

arquitectura.
● Diagrama de clases de diseño.
● Diagrama de secuencia de diseño.

Construcción del ● Ejecutables.

software

Pruebas de software ● Plan de Verificación y Validación.

● Plan de Pruebas

Implementación ● Plan de Implementación.

Una vez identificado los productos por cada proceso y el diagrama de proceso del
sistema de ERP Contrata comenzaremos a realizar el control de calidad a dichos
procesos, las tareas a realizar se centrarán en las siguientes secciones de la
aplicación:

27
 ● Módulo de Registro de Documentación
● Módulo de Registro Contabilidad
● Módulo de Registro Facturación

Cuadro de detalle por Sistema/módulo que se integrarán:

SISTEMA MODULO CASO DE USO FUNCIONALIDAD

ERP Registro de SOL-CU01 Actualizar Crear, Modificar, Eliminar,

Contrata documento los documentos Consultar, documentos

Registro EXP-CU01 Crear, Modificar, Eliminar,

Contabilidad Actualizar_registro registro contable
contable

EXP-CU02 Consultar Realiza consultas al

contabilidad registro contable.
Compartido en otros
módulos

Registro APO-CU01 Actualizar Crear, Modificar, Eliminar,

Facturación Factura Consultar, facturas

Y para lograr un control de estas secciones o productos, se deberán revisar y

considerar los siguientes entregables o productos de calidad:

➢ Documento de Requerimientos (SRS).

➢ Alcance del Sistema.
➢ Modelo de Diseño.
➢ Estándares de patrones de diseño.
➢ Plan de Gestión del Proyecto.
➢ Plan de SQA.
➢ Plan de Pruebas.
➢ Reporte de pruebas unitarias e integración.
➢ Estándares de Documentación de Usuario.
➢ Documentación de Usuario.

Una vez definidos los entregables definiremos las tareas a ser llevadas a cabo las
cuales deberán reflejar las evaluaciones, los estándares, los productos a revisar, los
procedimientos en la elaboración de los distintos productos y los procedimientos para
informar de los defectos detectados a sus responsables y realizar el seguimiento de
los mismos hasta su corrección.

Las actividades que se realizarán son:

➢ Revisar cada producto.

➢ Revisar el ajuste al proceso.
➢ Realizar el plan de SQA.

28
➢ Registrar observaciones.
➢ Consolidar observaciones del producto por módulo.
➢ Mapear los mensajes de los servicios.
➢ Mapear el flujo de los procesos.
➢ Identificar datos permitidos y obligatorios.
➢ Evaluar la calidad del producto.
➢ Revisar el avance quincenal.
➢ Realizar evaluación final del SQA.

ACTIVIDAD ENTREGABLE ASOCIADO

Revisar cada producto Documento de

Requerimientos (SRS)
Identificar datos permitidos y obligatorios

Revisar el ajuste al proceso Alcance del Sistema

Mapear el flujo de los procesos

Realizar reuniones internas de apoyo Plan de Gestión del Proyecto

Realizar el plan de SQA Plan de SQA

Registro de observaciones

Consolidar observaciones del producto Plan de Pruebas

por módulo

Realizar evaluación final del SQA

Evaluar la calidad del producto Reporte de pruebas unitarias e

integración

Responsables por tarea

A continuación, se identifican los responsables de cada tarea:

Actividad Responsable

Mapeo de los flujos de procesos Diseñador de Pruebas

Revisión del documento de propuesta funcional Líder de Pruebas

Identificación de estándares y servicios Líder de Pruebas

Desarrollador

Identificación de datos permitidos por cada Diseñador de Pruebas

proceso Desarrollador Técnico

29
 Realizar el plan de SQA Diseñador de Pruebas

Revisión de los casos de prueba Líder de Pruebas Jefe de

proyecto

Revisar cada producto y registrar las Líder de pruebas

observaciones

Consolidar observaciones del módulo Líder de pruebas

Revisar levantamiento de observaciones Líder de Pruebas

Analista Funcional

Reunión interna de observaciones con el jefe Líder de Pruebas Jefe de

de proyecto y analista funcional proyecto Desarrollador
Senior

Realización de pruebas no funcionales por Líder de Pruebas

cada modelo de caso de uso indicado Analista Funcional

Elaboración de informe final de pruebas Líder de Pruebas

A continuación, se presentan las actividades a realizar por cada rol del equipo
de trabajo:

Roles Abrev. Personas Responsabilidades

Asignadas

Sponsor CF Raul Paucar Revisar estándares, entregables,

proponer acciones correctivas, aplicar
acciones correctivas.

Jefe de Proyecto (Project JP Johnny Rivera Gestionar y conseguir los recursos para
Manager) Barzola la ejecución de las pruebas. Decidir
sobre el inicio y fin de la etapa de
pruebas.

Líder de Pruebas LP Hugo Teccsi Elaborar el Plan de Pruebas. Revisar

casos de prueba elaborados. Elaborar
los informes de resultados de los ciclos
de pruebas.

Diseñador de pruebas DP Christian Generar los casos de pruebas. Generar

Alexander data de prueba.
Huaman Blas

Tester T Hugo Teccsi Reconocer la data de prueba necesaria

para la ejecución de las pruebas.
Ejecutar los casos de prueba. Registrar
los resultados.

Líder de desarrollo LD Roger Garay Coordinar y asignar las incidencias

encontradas en los ciclos de prueba.

Desarrollador D Hugo Teccsi Corregir las incidencias encontradas

durante la ejecución de los casos de

30
 prueba.

Líder de despliegue DM Raul Paucar Desplegar en el ambiente de pruebas.

Actividades Sponsor Jefe de Líder de Diseñad Tester Líder de Desarrollado

Proyecto Pruebas or de desarrollo r
pruebas

Documento de I I A/R C C C C
Requerimiento
s (SRS)

Alcance del I I C C C C C
Sistema

Documento de A/R C C C C C
Riesgos

Modelo de I I C C C C C
Diseño

Estándares de I I C C C C C
patrones de
diseño

Plan de A/R A/R C C C C C

Gestión del
Proyecto

Plan de SQA I I A/R C C C C

Plan de I I A/R C C C C
Verificación y
Validación
(Pruebas)

Reporte de I I A/R C C C C
pruebas
unitarias e
integración

Documentación

Objetivo
Identificación de la documentación relativa al análisis, desarrollo, verificación &
validación, uso y mantenimiento de las revisiones.

Documentación mínima requerida

31
 Para el análisis del proceso se necesita la siguiente documentación:
- Plan de proyecto.
- Plan de verificación y validación.
- Diseño del Sistema.
- Mapa de procesos.
- Plan de acciones preventivas y correctivas.

Plan de verificación y validación

Las actividades del Plan de Verificación y Validación, son cumplidos por los
siguientes roles:

ROLES
ACTIVIDADES
Jefe de Líder de Analista Líder de
Proyecto Desarrollo Funcional Pruebas

Elaboración del plan de I C R A

Verificación y Validación

Ejecución del plan de I C/R R A

Verificación y Validación

Seguimiento de incidencias I C/R R A

El cumplimiento de este plan nos generará el documento de Reporte de verificación

y validación.

Para ayuda con el análisis y entendimiento del plan de calidad, se debe de

considerar la siguiente documentación:

● Plan de desarrollo
● Plan de proyecto
● Manual de estándares y procedimientos
● Manual de soporte
● Manual de despliegue

También nos podemos apoyar con el desarrollo de métricas a través del método
OPM (Objetivo, pregunta, Métrica) que nos permitirá controlar el avance del
proyecto a lo largo del ciclo de vida del Software. Si bien las métricas tendrán
diferentes frecuencias de medición, se presentará un informe quincenal al gerente
de proyectos que resuma los resultados de las métricas.

OBJETIVO Verificar el cumplimiento de los requerimientos del

software

32
PREGUNTA ¿Cuál es el porcentaje de requerimientos implementados?

MEDIDAS A = Cantidad de requerimientos desarrollado

B = Cantidad de requerimientos funcionales solicitados.

MÉTRICA X = (A/B) *100%

INDICADOR X > 80%

FRECUENCIA DE Semanal
MEDICIÓN

OBJETIVO Verificar las pruebas exitosas durante el testing

PREGUNTA ¿Cuál es el porcentaje de pruebas exitosas?

MEDIDAS A = Cantidad de casos de prueba exitosos.

B = Cantidad total de casos de prueba planteados.

MÉTRICA X = (A/B) *100%

INDICADOR X > 90%

FRECUENCIA DE Semanal
MEDICIÓN

OBJETIVO Verificar la capacidad de respuesta ante correcciones

PREGUNTA ¿Cuál es el porcentaje de correcciones realizadas?

MEDIDAS A = Cantidad de correcciones implementadas

B = Cantidad total de correcciones solicitadas

MÉTRICA X = (A/B) *100%

INDICADOR X > 95%

FRECUENCIA DE Semanal
MEDICIÓN

OBJETIVO Verificar el esfuerzo de desarrollo total.

PREGUNTA ¿Cuál es el porcentaje de líneas de código con error?

MEDIDAS A = Cantidad de líneas de código con error

B = Cantidad total de líneas de código

MÉTRICA X = (A/B) *100%

INDICADOR X < 10%

FRECUENCIA DE Diario
MEDICIÓN

33
 ● Casos de Uso de Sistema

Especificación de Caso de Uso:

Caso de Uso:
CUN01_Planificar Atenciones
Actores

Administrador
Cliente
Breve Descripción

El caso de uso comienza cuando el Coordinador de calidad solicita el documento de planificación

para la atención del Cliente al Administrador. El caso de uso incluye la verificación de vigencia del
contrato, la asignación del técnico al contrato si lo amerita y la coordinación de días de visita con
el cliente, por parte del Administrador. El caso de uso termina cuando el Administrador genera el
documento de planificación, consolidado de informes de atención o solicitud de contratación de
técnico y los envía al Coordinador de calidad.

Flujo básico
1. El Coordinador de calidad solicita el documento de planificación.
2. El Administrador verifica la vigencia del contrato del cliente.
3. El Administrador verifica técnico asignado en el contrato del cliente.
4. El Administrador coordina días de atención con el Cliente.
5. El Cliente indica días de atención.
6. El Administrador genera documento de planificación.
7. El Administrador envía documento de planificación.
8. El Coordinador de calidad recibe documento de planificación.

Flujo alternativo 1
El contrato del Cliente no está vigente.
1. Si en [2] el Administrador verifica que el cliente NO tiene contrato vigente entonces
el Administrador elabora el consolidado de informes, y lo envía al Coordinador de
calidad quien la recibe y el caso de uso termina.

El contrato del Cliente no tiene técnico asignado.

2. Si en [3] el Administrador verifica que el contrato del cliente NO tiene asignado el
técnico, entonces el Administrador busca un Técnico disponible y lo asigna al
contrato del cliente y el caso de uso continúa en el punto [4].

El contrato del Cliente no tiene técnico asignado y no hay técnicos disponibles.

3. Si en [2] el Administrador verifica que NO hay técnico disponible para asignar al
contrato del cliente, entonces el Administrador genera una solicitud de contratación
de técnico y la envía al Coordinador de calidad quien la recibe y el caso de uso
termina.

Precondiciones

34
 Debe existir un contrato.

Postcondiciones
Documento de Planificación
Se elaborará un documento de Planificación de atención al cliente.

Reporte consolidado
Se ha elaborará un Reporte Consolidado de atenciones al Cliente.

Solicitud de contratación de técnico

Se ha elaborará una Solicitud de Contratación de nuevo técnico.

Escenarios de Casos de Uso:

Escenarios de Caso de Uso

Escenarios de Caso de Uso Flujo Básico Flujo Alternativo

● El Coordinador de calidad Flujo Normal

solicita el documento de la
planificación
● El Administrador verifica la Flujo Normal Flujo Alternativo 1
vigencia del contrato de cliente

● El Administrador verifica la Flujo Normal Flujo Alternativo 2

asignación de un técnico para
el contrato del cliente

● El Administrador coordina los Flujo Normal

días de atención con el cliente
● El cliente indica los días de Flujo Normal
atención
● El Administrador genera Flujo Normal
documento de planificación
● El Administrador envía Flujo Normal
documento de planificación al
Coordinador de calidad

35
 Escenarios de Caso de Prueba

Escenarios de Caso de Uso Flujo Inicial Alternativo

ES01 – Registro correcto de una planificación Flujo Normal

ES02 – Contrato vencido sin planificación Flujo Normal Alternativo 1

actualizada

ES03 – Planificación no cuenta con técnico Flujo Normal Alternativo 2

asignado

ES04 – No existe técnicos disponibles Flujo Normal Alternativo 2

Casos de Prueba:

CASOS DE PRUEBA

ID Escenario Contrato Técnico Planificación Resultado

1 Escenario 1 V V V Mensaje: “Planificación completada

satisfactoriamente”

2 Escenario 2 I V I Mensaje: “Contrato no Vigente”.

3 Escenario 3 V I I Mensaje: “Técnico asignado no posee

asignado días de atención”.

4 Escenario 4 V I I Mensaje : “No existen técnicos

disponibles”

36
Datos de Prueba:

CASOS DE PRUEBA

ID Escenario Contrato Técnico Planificación Resultado

1 Escenario 1 C001 Juan Flores Pla002 Mensaje: “Planificación completada

satisfactoriamente”

2 Escenario 2 C001 Roberto Ríos Pla004 Mensaje: “Contrato no Vigente”.

3 Escenario 3 C001 Alberto Pla006 Mensaje: “Técnico asignado no

Campos posee asignado días de atención”.

4 Escenario 4 C001 - - Mensaje : “No existen técnicos

disponibles”

37
 Caso de prueba: CUN02_Calificar Contrato
Especificación de Caso de Uso:

Caso de Uso: CUN02_Calificar Contrato

Actores

Coordinador de Calidad

Breve Descripción

El caso de uso comienza cuando el coordinador de calidad solicita el contrato al Administrador,

luego de ello procede a verificar. El caso de uso incluye la revisión , calificación y generación del
informe de calificación y el acta de conformidad o rechazo . El caso de uso termina cuando el
informe de calificación es recepcionado por el Jefe de Sistemas.

Flujo básico

1. El Coordinador de calidad solicita contrato al Administrador.

2. El Administrador recibe solicitud y envía contrato.
3. El Coordinador de calidad recepciona contrato.
4. El Coordinador de calidad verifica contrato.
5. El Coordinador genera informe de calificación.
6. El Coordinador genera acta de conformidad.
7. El Coordinador de calidad envía informe de calificación.
8. El Jefe de Servicio recibe documentos.
9. El Jefe de Sistemas verifica el formato correcto del informe de calificación.
10. El Jefe de Sistemas acepta documento de calificación y finaliza caso de uso.

Flujo alterno

Generar acta de Recha.

11. Si en [4] El Coordinador de atención verifica que el informe técnico de calificación
tiene una nota no óptima devuelve el informe al Técnico y el caso de uso continúa
en el punto [7]

Rechazar formato de calificación.

12. Si en [9] El Jefe de Sistemas verifica que el informe técnico de calificación tiene una
no tiene el formato correcto procede a enviar al coordinador el informe y el punto
vuelve al punto [5]

Precondiciones
● Contrato.
Postcondiciones
● Informe de calificación
Se elaboró un documento técnico de calificación

38
● Acta de Conformidad
Se ha elaborado el acta de conforimidad.

Escenarios de Casos de Uso:

Escenarios de Caso de Uso

Escenarios de Caso de Uso Flujo Básico Flujo Alternativo

● El Coordinador de calidad Flujo Normal

solicita contrato al
Administrador.

Flujo Normal
● El Administrador recibe
solicitud y envía contrato

● El Coordinador de calidad Flujo Normal

recepciona contrato.

● El Coordinador de calidad Flujo Normal

verifica contrato.
● El Coordinador genera Flujo Normal Flujo Alternativo 1
informe de calificación.
● El Coordinador genera Flujo Normal
acta de conformidad.
● El Coordinador de calidad Flujo Normal
envía informe de
calificación.
● El Jefe de Sistemas recibe Flujo Normal
documentos.
● El Jefe de Sistemas verifica Flujo Normal Flujo Alternativo 2
el formato correcto del
informe de calificación.

● El Jefe de Servicio acepta Flujo Normal

documento de calificación
y finaliza caso de uso.

39
 Escenarios de Caso de Prueba

Escenarios de Caso de Uso Flujo Inicial Alternativo

ES01 – Verificar calidad contrato. Flujo Normal

ES02 –Generar informe de calificación. Flujo Normal Alternativo 1

ES03 – Verificar formato correcto del informe de Flujo Normal Alternativo 2

calificación.

Casos de Prueba:

CASOS DE PRUEBA

ID Escenario Contrato Servicio Informe Resultado

1 Escenario 1 V V V Mensaje: “El formato ingresado

exitosamente”

2 Escenario 2 V V I Mensaje: “Error en generación de

Informe”.

3 Escenario 3 V I I Mensaje: “El servicio no es válido para

revisiòn del formato”.

CASOS DE PRUEBA

ID Escenario Contrato Servicio Informe Resultado

1 Escenario 1 Pla004 S001 IF001 Mensaje: “Servicio Completado”

2 Escenario 2 Pla005 S002 - Mensaje: “Informe no Generado”.

3 Escenario 3 Pla006 - - Mensaje: “El servicio no es válido para

revisiòn del formato”.

40
Aplicación de la Gestión de Calidad al procedimiento específico del grupo
Conclusiones

Conclusiones

- La Gestión de la Calidad y las herramientas que nos provee nos sirven de base para
determinar si un producto de software tiene o no calidad

- Es importante la implementación de métricas e indicadores ya que ellos nos ayudan a

medir el avance y cumplimiento de la Gestión de Calidad.

- La aplicación las diferentes normas nos ayudan a asegurar un nivel de calidad al

producto de software.

41