It Data Consulting - 2017.docx

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.

2.

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. 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 sistema de gestión de calidad SGC

MDC

Procesos

Relación de actividades relacionadas entre sí que transforman elementos de entrada en resultados.

PRC

Instructivo

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

INT

Procedimiento

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

GF

4

Registro

Documento que proporciona 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

JS

Documento obsoleto

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

DOB

Listado Maestro de Documentos y Registros

Listados de los documentos que 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.

LMDR

Actividades coordinadas dentro 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.

SGC

Sistema de Gestión de Calidad

5. 5.1

6.

DOCUMENTOS DE 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 Manual de Procedimientos Certificación de cuenta bancaria Carta de presentación de oferta de servicios

6.1

DISPOSICIONES ESPECÍFICAS 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 incluyendo los documentos anexos y una copia del contrato.

Coordinador de Calidad

Recepción de la solicitud de revisión: Se procede a la recepción del contrato y los documentos anexos adjuntos para luego verificar la documentación detalladamente; si la solicitud cumple con los requisitos se 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 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 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 del servicio, al personal que realizó la solicitud. Finalmente se archiva la solicitud de revisión en una carpeta.

9.1

9.2

9.3

9.4

9.5

10 10.1

REGISTROS Acta contractual

10.2

Acta de reunión

11 11.1

ANEXOS 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 Página

01

02

03

04

Observaciones

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 gestión de calidad SGC

MDC

Procesos

Relación de actividades relacionadas entre sí que transforman elementos de entrada en resultados.

PRC

Instructivo

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

INT

Procedimiento

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

GF

Registro

Documento que proporciona 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

JS

Documento obsoleto

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

DOB

Listado Maestro de Documentos y Registros

Listados de los documentos que 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.

LMDR

9

Sistema de Gestión de Calidad

Actividades coordinadas dentro 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, 7.5.1.7 Mantenimiento

6.

DISPOSICIONES ESPECÍFICAS

6.1 7. 7.1

SGC

No aplica Precondición 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 Calidad

Actúa como representante de la Dirección y tiene la autoridad y la 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

● 1.

Procedimiento de Análisis 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

5.

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.

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 8.

8.1

Especificación del modelo de análisis del contrato

DESARROLLO RESPONSABLE

DESCRIPCIÓN DE LA ACTIVIDAD

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 Casos de Uso

Realización de casos de uso - análisis 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 Componentes

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

14

Paquete de Análisis

Ingeniero de Componentes

8.5

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

<<Se especifica la descripción de la aplicación>>

Descripción: Requerimientos Funcionales

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

Reglas de Negocio:

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

Precondiciones

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

PostCondiciones

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

Flujo Básico de Eventos

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

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

●

1.

20/02/2017

Desarrollo

Procedimiento de Diseño

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 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

y los subsistemas que

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 componentes

Elaboración de clase de diseño 7.1.1 Ciclo de vida del software

7.3

Ingeniero de casos de uso

Elaboración de la Realización de Casos de Uso de diseño 7.1.1 Ciclo de vida del software

7.4

Ingeniero de componentes

Elaboración del Diagrama de Clases 7.1.1 Ciclo de vida del software

7.5

Ingeniero de componentes

- Elaboración del Diagrama de Interacción - 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 componentes

Elaboración de Interfaces 7.1.1 Ciclo de vida del software

7.8

Ingeniero de componentes

Elaboración de Subsistema de Diseño 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 aplicación:

Registrando los cambios al código fuente de los 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 aplicación:

Aplicar un rango de variación a los requerimientos que 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 aplicación:

Registrar una lista (CheckList) con los posibles fallos a 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 aplicación:

Registrar el número de cierres en un rango de tiempo 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.

● ●

● ●

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 software

●

Ejecutables.

Pruebas de software

● ●

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

Implementación

●

Plan de Implementación.

Diseño

●

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

ERP Contrata

Registro de documento

SOL-CU01 Actualizar los documentos

Crear, Modificar, Eliminar, Consultar, documentos

Registro Contabilidad

EXP-CU01 Actualizar_registro contable

Crear, Modificar, Eliminar, registro contable

EXP-CU02 Consultar contabilidad

Realiza consultas al registro contable. Compartido en otros módulos

APO-CU01 Actualizar Factura

Crear, Modificar, Eliminar, Consultar, facturas

Registro Facturación

CASO DE USO

FUNCIONALIDAD

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 por módulo

Plan de Pruebas

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 observaciones

producto

y

registrar

las Líder de pruebas

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 Asignadas

Responsabilidades

Sponsor

CF

Raul Paucar

Revisar estándares, entregables, proponer acciones correctivas, aplicar acciones correctivas.

Jefe de Proyecto (Project Manager)

JP

Johnny Rivera Barzola

Gestionar y conseguir los recursos para 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 Alexander Huaman Blas

Generar los casos de pruebas. Generar data de prueba.

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 Proyecto

Líder de Pruebas

Diseñad or de pruebas

Tester

Líder de desarrollo

Desarrollado r

Documento de Requerimiento s (SRS)

I

I

A/R

C

C

C

C

Alcance del Sistema

I

I

C

C

C

C

C

A/R

C

C

C

C

C

Documento de Riesgos Modelo de Diseño

I

I

C

C

C

C

C

Estándares de patrones de diseño

I

I

C

C

C

C

C

Plan de Gestión del Proyecto

A/R

A/R

C

C

C

C

C

Plan de SQA

I

I

A/R

C

C

C

C

Plan de Verificación y Validación (Pruebas)

I

I

A/R

C

C

C

C

Reporte de pruebas unitarias e integración

I

I

A/R

C

C

C

C

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 Proyecto

Líder de Desarrollo

Analista Funcional

Líder de Pruebas

Elaboración del plan de Verificación y Validación

I

C

R

A

Ejecución del plan de Verificación y Validación

I

C/R

R

A

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 MEDICIÓN

Semanal

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 MEDICIÓN

Semanal

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 MEDICIÓN

Semanal

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 MEDICIÓN

Diario

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. 2. 3. 4. 5. 6. 7. 8.

El Coordinador de calidad solicita el documento de planificación. El Administrador verifica la vigencia del contrato del cliente. El Administrador verifica técnico asignado en el contrato del cliente. El Administrador coordina días de atención con el Cliente. El Cliente indica días de atención. El Administrador genera documento de planificación. El Administrador envía documento de planificación. 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.

2.

3.

El contrato del Cliente no tiene técnico asignado. 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. 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 solicita el documento de la planificación ● El Administrador verifica la vigencia del contrato de cliente

Flujo Normal

Flujo Normal

Flujo Alternativo 1

● El Administrador verifica la asignación de un técnico para el contrato del cliente

Flujo Normal

Flujo Alternativo 2

● El Administrador coordina los días de atención con el cliente

Flujo Normal

● El cliente indica los días de atención

Flujo Normal

● El Administrador genera documento de planificación

Flujo Normal

● El Administrador envía documento de planificación al Coordinador de calidad

Flujo Normal

35

Escenarios de Caso de Prueba Escenarios de Caso de Uso

Flujo Inicial

Alternativo

ES01 – Registro correcto de una planificación

Flujo Normal

ES02

planificación

Flujo Normal

Alternativo 1

ES03 – Planificación no cuenta con técnico

Flujo Normal

Alternativo 2

Flujo Normal

Alternativo 2

–

Contrato

vencido

sin

actualizada

asignado ES04 – No existe técnicos disponibles Casos de Prueba:

CASOS DE PRUEBA ID 1

Escenario Escenario 1

Contrato Técnico Planificación V

V

V

Resultado 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 1

Escenario Escenario 1

Contrato

Técnico

C001

Juan Flores

Planificación

Resultado

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:

Campos 4

Escenario 4

C001

-

“Técnico

asignado

no

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

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. 2. 3. 4. 5. 6. 7. 8. 9. 10.

El Coordinador de calidad solicita contrato al Administrador. El Administrador recibe solicitud y envía contrato. El Coordinador de calidad recepciona contrato. El Coordinador de calidad verifica contrato. El Coordinador genera informe de calificación. El Coordinador genera acta de conformidad. El Coordinador de calidad envía informe de calificación. El Jefe de Servicio recibe documentos. El Jefe de Sistemas verifica el formato correcto del informe de calificación. 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

●

El Coordinador de calidad solicita contrato al Administrador.

Flujo Normal

●

El Administrador recibe solicitud y envía contrato

●

El Coordinador de calidad recepciona contrato.

Flujo Normal

●

El Coordinador de calidad verifica contrato.

Flujo Normal

●

El Coordinador genera informe de calificación.

Flujo Normal

●

El Coordinador genera acta de conformidad.

Flujo Normal

●

El Coordinador de calidad envía informe de calificación. El Jefe de Sistemas recibe documentos.

Flujo Normal

●

El Jefe de Sistemas verifica el formato correcto del informe de calificación.

Flujo Normal

●

El Jefe de Servicio acepta documento de calificación y finaliza caso de uso.

Flujo Normal

Flujo Alternativo

Flujo Normal

●

Flujo Alternativo 1

Flujo Normal Flujo Alternativo 2

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 1

Escenario Escenario 1

Contrato V

Servicio Informe V

V

Resultado 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