Modelo de ciclo de vida adecuado para resolver el problema

1. SELECCIONAR EL PROCESO Y LAS ACTIVIDADES A REALIZAR

1. MODELO DE CICLO DE VIDA ADECUADO PARA RESOLVER EL PROBLEMA

El ciclo de vida del software elegido para tratar con los problemas que actualmente tiene ENACO es el modelo de ciclo de vida del software en V:[pic 1]

Utilizamos el modelo de ciclo de vida en V, fue porque en el modelo tradicional (cascada) los defectos son encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del proyecto. El modelo en V dice que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra que las pruebas no son sólo una actividad basada en la ejecución. Hay una variedad de actividades que se han de realizar antes del fin de la fase de codificación. Estas actividades deberían ser llevadas a cabo en paralelo con las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar con los desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y tareas y producir una serie de entregables de pruebas.

El modelo en V es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser producidos durante el desarrollo del producto. La parte izquierda de la v representa la descomposición de los requisitos y la creación de las especificaciones del sistema. El lado derecho de la v representa la integración de partes y su verificación. V significa “Validación y Verificación”.

1. PROCESOS NECESARIOS PARA EL PROYECTO

1. PRACTICAS[pic 2]

La corriente de especificación (parte izquierda, Project definition) consiste principalmente de:

• Conceptos de operaciones: qué debe hacer el sistema a grandes rasgos.
• Requisitos del sistema y arquitectura del mismo.
• Diseño detallado.

La corriente de pruebas (parte derecha, Project test and integration), por su parte, suele consistir de:

• Integración de las distintas partes, prueba y verificación de las mismas.
• Verificación y validación del sistema en conjunto.
• Mantenimiento del sistema.

La corriente de desarrollo puede consistir (depende del tipo de sistema y del alcance del desarrollo) en personalización, configuración o codificación.

                Las fases que componen el modelo en V son las siguientes:

• Fase #1: Está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se componen del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.
• Fase #2: Se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.
• Fase #3: Define los componentes es la fase de hardware y software implementación, en la del sistema final, cuyo conjunto se denomina arquitectura del sistema.
• Fase #4: En la fase de implementación que se desarrolla los elementos unitarios o módulos del programa.

1. RESPONSABILIDADES

• Fase #1 Especialista I: Encargado de recoger los requerimientos y de realizar las revisiones con el cliente.
• Fase #2 Analista de programación: Encargado de las pruebas del sistema, entradas salidas e interfaces.
• Fase #3 Especialista I: Encargado de evaluar y verificar la arquitectura del sistema.
• Fase #4 Soporte técnico: Encargado de evaluar los componentes de forma individual y de validar la arquitectura del sistema.

1. PRODUCTOS

• Sistema de información de gestión de notificaciones de problemas concernientes al área de TI.
• Dispositivo para la gestión de registro de asistencia automatizada por medios tecnológicos para el área de Recursos Humanos.
• Programa de capacitación para mejorar el desempeño laboral del personal del área de TI.

1. NECESIDADES DE CAPACITACIÓN DEL EQUIPO DE PROYECTO

El equipo del proyecto debe recibir una capacitación en lo que respecta al modelo ITIL v4, y sus buenas prácticas. Así como también en el compromiso y la importancia de las pruebas que no solo buscan errores en el producto final, si no que buscan la prevención y corrección de los mismos.

1. CRITERIOS DE ACEPTACIÓN PARA LOS COMPONENTES DEL PRODUCTO DE SOFTWARE Y SERVICIO A ENTREGAR

• Sistema de información de gestión de notificaciones de problemas concernientes al área de TI.

• Que el sistema permita la actualización, gestión y cambios de estado de los problemas.
• Que el sistema sea capaz de soportar consultas y edición de las notificaciones.
• Que los empleados deban llenar los campos necesarios obligatorios para completar la notificación.

• Dispositivo biométrico para la gestión de registro de asistencia automatizada por medios tecnológicos para el área de Recursos Humanos.

• Los dispositivos deben responder y reconocer las huellas biométricas de forma rápida y segura.

• Programa de capacitación para mejorar el desempeño laboral del personal del área de TI.

• Los empleados de la empresa deben ser capaces de entender y conocer los conceptos de calidad concernientes a ITIL.
• Cada empleado del área de sistemas debe tener y asumir las responsabilidades de acuerdo al rol en el cual se encuentran, con respecto a la guía de buenas prácticas ITIL.

1. PROCESOS PARA ASEGURAR LA CALIDAD DEL SOFTWARE

1. ACTIVIDADES DE VERIFICACIÓN Y VALIDACIÓN

El diagrama V plantea que en todo este proceso se debe llevar a cabo la verificación y validación y se realiza como se menciona a continuación. Cada nivel de desarrollo se verifica con el nivel anterior, es decir, se comprueba si los requisitos y definiciones de niveles previos han sido implementados de correcta. La validación se refiere a la corrección de cada nivel de desarrollo, de esta manera se comprueba lo adecuado de los resultados de un nivel de desarrollo. De esta manera podemos observar que el proceso de pruebas comienza antes que la ejecución de las mismas, tan   pronto   comienza   el   desarrollo   se   puede   comenzar   la   preparación   de   las   pruebas correspondientes, como es el caso de la revisión de documentos.

1. MECANISMOS PARA RESOLVER LOS PROBLEMAS QUE SURJAN A LO LARGO DEL PROYECTO

• Comunicación eficaz. Es necesario transmitir de forma efectiva todos los objetivos del proyecto en concreto, además de los recursos a utilizar, el perfil de los clientes y otros detalles.
• Asignación de roles. Un aspecto importante para que los profesionales no tengan ninguna confusión sobre sus labores y cuáles son sus límites.
• Designar a una persona con liderazgo y autoridad. El líder del proyecto debe ser capaz de brindar soluciones y conciliar al equipo en cualquier circunstancia. Con inteligencia emocional y habilidades de comunicación, su papel también será prever conflictos que tengan como causa las personalidades de los participantes.
• Entendimiento total de los problemas. Jamás debe evitarse o intentar solucionar un conflicto mediante prohibiciones, obligaciones o maltratos. Es necesario entender las causas, puesto que podrían ser externas y -de no ser manejadas- se repetirían constantemente.

1. DETECCIÓN Y DOCUMENTACIÓN PARA LA IMPLEMENTACIÓN

1. ESTÁNDARES

2. ESPECIFICACIONES DE PRUEBAS

• Las pruebas se realizan en cuatro etapas:

• Prueba de unidades (prueba de métodos y clases)

• Se prueba cada método y clase de forma independiente
• Es importante mencionar que estas pruebas las ejecuta el desarrollador verificando que su código cumple con lo solicitado y no ha violado ningún estándar que ponga en riesgo la estabilidad del sistema. Las pruebas de componente podrán comprobar características funcionales y no funcionales de un sistema.

• Prueba integrales

• Las pruebas integrales también son conocidas como pruebas de interfaz, ya que comprueban la interacción entre componentes. Las pruebas de integración asumen que los módulos ya han sido probados de manera individual (pruebas unitarias). Implican una progresión ordenada de pruebas que van desde los componentes o módulos y que culminan en el sistema completo. El orden de integración elegido afecta a diversos factores como los siguientes:

• La forma de preparar casos
• Las herramientas necesarias
• El orden de codificar y probar los módulos
• El costo de la depuración
• El costo de preparación de casos

• Prueba de sistema

• Se prueba el sistema como un todo.
• Las pruebas de sistema se llevan a cabo cuando todo el desarrollo ha sido culminado y tenemos una versión preliminar del sistema que saldrá a producción. Esta etapa de pruebas consiste en probar un sistema integrado con el objeto de comprobar el cumplimiento de requisitos especificados. Las pruebas se hacen con un enfoque desde el punto de vista del usuario.
• Las pruebas de sistema se desarrollan utilizando casos de prueba funcionales y no funcionales. Las pruebas funcionales confirman que los requisitos para un uso específico previsto han sido cumplidos (validación).

• Prueba de validación (o de aceptación)

• El objetivo en este nivel de prueba es obtener el visto bueno del cliente, no se deberían encontrar defectos funcionales graves en el sistema. Es por ello que las pruebas de aceptación son realizadas por el usuario. Se puede decir que las pruebas de aceptación son las pruebas de sistema por parte del cliente. Existen dos tipos de pruebas de aceptación:
• Pruebas Alfa. El cliente utiliza el software para hacer el tratamiento de sus procesos de negocio en las dependencias del proveedor.
• Pruebas Beta. Estas se ejecutan en las dependencias del cliente.

El descubrimiento de un defecto en una etapa requerirá la repetición de las etapas de prueba anteriores.

1. USO DE HERRAMIENTAS PARA SOPORTE DE PROCESO DE SOFTWARE

...