Descargar

Proyecto de fortalecimiento para la implementación del sistema de trámite documentario 2014 (página 2)


Partes: 1, 2

Desde el punto de vista de los desarrolladores (Ingenieros de Software), la Metodología Métrica V3, mejora la comprensión del problema, optimiza el proceso y las fases a seguir, se genera facilidad en mantenimiento y se desarrollan algunos criterios sobre reusabilidad. Desde el punto de vista del cliente /usuario final, la Metodología Métrica V3, garantiza en la medida de lo posible la calidad del producto y se genera mayor confianza en el proceso y los resultados por las facilidades de acceso a información y mayor transparencia de la gestión. Las fases y procesos principales de la Metodología Métrica V3, a tomar en cuenta son:

  • Planificación (PSI)

edu.red

  • Estudio de Viabilidad (EVS)

edu.red

  • Análisis (ASI)

edu.red

  • Diseño (DSI)

edu.red

  • Construcción (CSI)

edu.red

  • Implantación y Aceptación (IAS)

edu.red

  • Mantenimiento (MSI)

edu.red

  • PROCESO DE DESARROLLO

El proceso de desarrollo contiene las actividades y tareas del desarrollador. El proceso contiene las actividades para el análisis de los requerimientos, diseño, codificación, integración, pruebas e instalación y aceptación relacionadas con los productos software. Puede contener actividades a nivel de sistema si se estipula en el contrato. El desarrollador lleva a cabo o soporta las actividades de este proceso de acuerdo con el contrato. El desarrollador gestiona el proceso de desarrollo al nivel de proyecto siguiendo el proceso de gestión, que se emplea en este proceso; establece una infraestructura basado en el proceso que se sigue en el proceso de infraestructura adapta el proceso al proyecto siguiendo el proceso de adaptación (Anexo A); y gestiona el proceso a nivel de organización siguiendo el proceso de mejora de proceso y el proceso de recursos humanos. Cuando el desarrollador es el proveedor del producto software desarrollado, el desarrollador lleva a cabo el proceso de suministro.

Lista de actividades: Este proceso consta de las siguientes actividades:

  • a) Implementación del proceso.

  • b) Análisis de los requerimientos del sistema.

  • c) Diseño de la arquitectura del sistema.

  • d) Análisis de los requerimientos software.

  • e) Diseño de la arquitectura del software.

  • f) Diseño detallado del software.

  • g) Codificación y pruebas del software.

  • h) Integración del software.

  • i) Pruebas de calificación del software.

  • j) Integración del sistema.

  • k) Pruebas de calificación del sistema.

  • l) Instalación del software.

  • m) Apoyo a la aceptación del software.

9.2.1. Implementación del proceso:

Esta actividad consta de las siguientes tareas:

9.2.1.1. Si no está estipulado en el contrato, el desarrollador deberá definir o seleccionar un modelo de ciclo de vida apropiado al alcance, magnitud y complejidad del proyecto. Se deberán seleccionar las actividades y tareas del proceso de desarrollo y establecer una correspondencia entre dichas tareas y el modelo de ciclo de vida.

NOTA: Estas actividades y tareas pueden solaparse o interaccionar y pueden ser llevadas a cabo Iterativamente o recursivamente.

9.2.1.2. El desarrollador deberá:

  • a) Documentar las salidas de acuerdo con el proceso de documentación (6.1).

  • b) Poner las salidas basándose en el proceso de gestión de la configuración (6.2) y llevar a cabo el control de los cambios de acuerdo con él.

  • c) Documentar y solucionar los problemas y no conformidades encontradas en los productos software y tareas de acuerdo con el proceso de solución de problemas.

  • d) Llevar a cabo los procesos de apoyo (capítulo 6) tal como se especifique en el contrato.

  • e) Establecer una línea base para cada elemento de la configuración con los elementos apropiados, como los determinados por el adquiriente y el proveedor.

9.2.1.3. El desarrollador deberá seleccionar, adaptar y usar aquellas normas, métodos, herramientas y lenguajes de programación (si no están estipulados en el contrato) que estén documentados, sean pertinentes y estén establecidos por la organización para llevar a cabo las actividades del proceso de desarrollo y de los procesos de apoyo (capítulo 6).

9.2.1.4. El desarrollador deberá preparar planes para realizar las actividades del proceso de desarrollo. Los planes deberían incluir normas específicas, métodos, herramientas, acciones y responsabilidades asociadas con el desarrollo y calificación de todos los requerimientos, incluyendo los de seguridad física y de acceso. Si fuese necesario, se pueden preparar planes separados. Se deberán documentar y ejecutar estos planes.

9.2.1.5. Para el desarrollo y mantenimiento del producto software se pueden emplear elementos no entregables. Sin embargo, se deberá asegurar que la operación y mantenimiento del producto software entregable, luego de entregado al adquiriente, es independiente de dichos elementos, de otra manera se deberán considerar como entregables.

9.2.2. Análisis de los requerimientos del sistema:

Esta actividad consta de las siguientes tareas, que el desarrollador deberá llevar a cabo o proporcionar apoyo, según requiera el contrato:

9.2.2.1. Se deberá analizar el uso específico previsto del sistema a ser desarrollado para especificar los requerimientos del sistema. La especificación de los requerimientos del sistema deberá describir funciones y capacidades del sistema; requerimientos de negocio, organizativos y de usuario; requerimientos de seguridad física y de acceso; requerimientos de ingeniería de factores humanos (ergonomía), interfaces y requerimientos de operación y mantenimiento; limitaciones de diseño y requerimientos de calificación. Se deberá documentar la especificación de los requerimientos del sistema.

9.2.2.2.Se deberán evaluar los requerimientos del sistema teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • a) Trazabilidad hacia las necesidades de la adquisición.

  • b) Consistencia con las necesidades de la adquisición.

  • c) Capacidad para ser probados.

  • d) Viabilidad del diseño de la arquitectura del sistema.

  • e) Viabilidad de la operación y mantenimiento.

9.2.3. Diseño de la arquitectura del sistema:

Esta actividad consta de las siguientes tareas, que el desarrollador deberá llevar a cabo o proporcionar apoyo, según requiere el contrato.

9.2.3.1. Se deberá establecer la arquitectura del sistema a alto nivel. La arquitectura deberá identificar los elementos hardware, software y operaciones manuales. Se deberá asegurar que todos los requerimientos del sistema se distribuyen entre estos elementos. Se deberán identificar posteriormente, los elementos de configuración hardware, elementos de configuración software y las operaciones manuales partiendo de estos elementos. Se deberá documentar la arquitectura del sistema y los requerimientos asignados a cada elemento.

9.2.3.2. Se deberá evaluar la arquitectura del sistema y los requerimientos para los elementos teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • a) Trazabilidad hacia los requerimientos del sistema.

  • b) Consistencia con los requerimientos del sistema.

  • c) Adecuación de las normas y métodos de diseño usados.

  • d) Viabilidad de los elementos software para cumplir con sus requerimientos asignados.

  • e) Viabilidad de la operación y mantenimiento.

9.2.4. Análisis de los requerimientos software:

Para cada elemento software (o para cada elemento de configuración software, si se ha identificado) esta actividad consta de las siguientes tareas:

9.2.4.1. El desarrollador deberá establecer y documentar los requerimientos software descritos a continuación, incluyendo la especificación de las características de calidad. Se pueden encontrar guías para la especificación de las características de calidad en la NTP-ISO/IEC 9126.

  • a) Especificaciones funcionales y de capacidad, incluyendo prestaciones, características físicas y condiciones del entorno en donde el elemento software ha de funcionar.

  • b) Interfaces externas al elemento software.

  • c) Requerimientos de calificación.

  • d) Especificaciones de seguridad física, incluyendo aquellas relacionadas con los métodos de operación y mantenimiento, influencias del entorno y daño a las personas.

  • e) Especificaciones de seguridad de acceso, incluyendo aquellas que comprometen información confidencial.

  • f) Especificaciones relacionadas con ingeniería de factores humanos (ergonomía), incluyendo aquellas relacionadas con las operaciones manuales, interacción hombre-máquina, obligaciones del personal y áreas con necesidad de una especial atención por parte de las personas, debido a su sensibilidad a errores humanos y a la destreza.

  • g) Definición de datos y requerimientos de las bases de datos.

  • h) Requerimientos de instalación y aceptación del producto software entregado, en el lugar o lugares de operación y mantenimiento.

  • i) Documentación de usuario.

  • j) Requerimientos de operación y ejecución por parte del usuario.

  • k) Requerimientos de mantenimiento por parte del usuario.

9.2.4.2. El desarrollador deberá evaluar los requerimientos software teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de la evaluación.

  • a) Trazabilidad hacia los requerimientos del sistema y el diseño del sistema.

  • b) Consistencia externa con los requerimientos del sistema.

  • c) Consistencia interna.

  • d) Capacidad para ser probado.

  • e) Viabilidad del diseño software.

  • f) Viabilidad de la operación y mantenimiento.

9.2.5. Diseño de la arquitectura del software:

Para cada elemento software (o para cada elemento de configuración software, si se ha identificado), esta actividad consta de las siguientes tareas:

9.2.5.1. El desarrollador deberá transformar los requerimientos para el elemento software, en una arquitectura que describa su estructura a alto nivel e identifique los componentes software. Se deberá asegurar que todos los requerimientos para el elemento software se asignan a sus componentes software y se refinan posteriormente para facilitar el diseño detallado. Se deberá documentar la arquitectura del elemento software.

9.2.5.2. El desarrollador deberá desarrollar y documentar un diseño a alto nivel para las interfaces externas al elemento software y para las interfaces entre los componentes software del elemento software.

9.2.5.3. El desarrollador deberá desarrollar y documentar un diseño a alto nivel para la base de datos.

9.2.5.4. Conviene que el desarrollador desarrolle y documente versiones preliminares de la documentación de usuario.

9.2.5.5. El desarrollador deberá definir y documentar los requerimientos preliminares de pruebas y la planificación para la integración del software.

9.2.5.6. El desarrollador deberá evaluar la arquitectura del elemento software y de los diseños de su interfaz y base de datos teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • a) Trazabilidad hacia los requerimientos del elemento software.

  • b) Consistencia externa con los requerimientos del elemento software.

  • c) Consistencia interna entre los componentes software.

  • d) Adecuación de los métodos de diseño y normas usadas.

  • e) Viabilidad del diseño detallado.

  • f) Viabilidad de la operación y mantenimiento.

9.2.6. Diseño detallado del software

Para cada elemento software (o para cada elemento de configuración software, si se ha identificado), esta actividad consta de las siguientes tareas:

9.2.6.1. El desarrollador deberá preparar un diseño detallado para cada componente software del elemento software. Se deberá refinar los componentes software hasta los niveles más bajos, que contienen las unidades software que pueden ser codificadas, compiladas y probadas. Se deberá asegurar que todos los requerimientos software están asignados desde los componentes software hacia las unidades software. Se deberá documentar el diseño detallado.

9.2.6.2. El desarrollador deberá preparar y documentar un diseño detallado de las interfaces externas al elemento software y entre los componentes software y las unidades software. El diseño detallado de las interfaces deberá permitir la codificación sin necesidad de más información.

9.2.6.3. El desarrollador deberá preparar y documentar el diseño detallado para la base de datos.

9.2.6.4. El desarrollador deberá actualizar la documentación de usuario si es necesario.

9.2.6.5. El desarrollador deberá definir y documentar los requerimientos de prueba y planificar la prueba de las unidades. Se deberían incluir en los requerimientos de prueba situaciones que fuercen a las unidades software hasta los límites de los requerimientos del software.

9.2.6.6. El desarrollador deberá actualizar los requerimientos de prueba y el plan para la integración del software.

9.2.6.7. El desarrollador deberá evaluar el diseño detallado del software y los requerimientos de prueba teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de la evaluación.

  • a) Trazabilidad hacia los requerimientos del elemento software.

  • b) Consistencia externa con el diseño de la arquitectura.

  • c) Consistencia interna entre los componentes software y las unidades software.

  • d) Adecuación de los métodos de diseño y normas usadas.

  • e) Viabilidad de las pruebas.

  • f) Viabilidad de la operación y mantenimiento.

9.2.7. Codificación y pruebas del software:

Para cada elemento software (o para cada elemento de configuración software, si se ha identificado), esta actividad consta de las siguientes tareas:

9.2.7.1. El desarrollador deberá desarrollar y documentar lo siguiente:

  • a) Cada unidad software y base de datos.

  • b) Procedimientos de prueba y datos para probar cada unidad software y base de datos.

9.2.7.2. El desarrollador deberá probar cada unidad software y base de datos asegurando que satisfacen sus requerimientos. Se deberán documentar los resultados de las pruebas.

9.2.7.3. El desarrollador deberá actualizar la documentación de usuario, si es necesario.

9.2.7.4. El desarrollador deberá actualizar los requerimientos de prueba y el plan para la integración del software.

9.2.7.5. El desarrollador deberá evaluar el código software y los resultados de las pruebas teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • a) Trazabilidad hacia los requerimientos y el diseño del elemento software.

  • b) Consistencia externa con los requerimientos y el diseño del elemento software.

  • c) Consistencia interna entre los requerimientos de las unidades.

  • d) Cobertura de pruebas de las unidades.

  • e) Adecuación de los métodos de codificación y normas usadas.

  • f) Viabilidad de la integración del software y de las pruebas.

  • g) Viabilidad de la operación y mantenimiento.

9.2.8. Integración del software:

Para cada elemento software (o para cada elemento de configuración de software, si se ha identificado), esta actividad consta de las siguientes tareas:

9.2.8.1. El desarrollador deberá preparar un plan de integración para integrar las unidades software y los componentes software en el elemento software. El plan deberá incluir requerimientos de prueba, procedimientos, datos, responsabilidades y plazos. Se deberá documentar el plan.

9.2.8.2. El desarrollador deberá integrar las unidades software y los componentes software y probarlos a medida que se agrupan de acuerdo con el plan de integración. Se deberá asegurar que cada agrupación satisface los requerimientos del elemento software y que el elemento software está integrado al final de la actividad de integración. Se deberá documentar los resultados de la integración y de las pruebas.

9.2.8.3. El desarrollador deberá actualizar la documentación de usuario, si es necesario.

9.2.8.4. El desarrollador deberá preparar y documentar, para cada requerimiento de calificación del elemento software, un conjunto de pruebas, casos de prueba (entradas, salidas, criterios de prueba) y procedimientos de prueba para llevar a cabo las pruebas de calificación del software. El desarrollador deberá asegurar que el elemento software integrado está listo para las pruebas de calificación del software.

9.2.8.5. El desarrollador deberá evaluar el plan de integración, el diseño, el código, las pruebas, los resultados de las pruebas y la documentación de usuario teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • a) Trazabilidad hacia los requerimientos del sistema.

  • b) Consistencia externa con los requerimientos del sistema.

  • c) Consistencia interna.

  • d) Cobertura de las pruebas de los requerimientos del elemento software.

  • e) Adecuación de las normas de prueba y de los métodos usados.

  • f) Conformidad con los resultados esperados.

  • g) Viabilidad de las pruebas de calificación del software.

  • h) Viabilidad de la operación y mantenimiento.

9.2.9. Pruebas de calificación del software:

Para cada elemento software (o para cada elemento de configuración software, si se ha identificado), esta actividad consta de las siguientes tareas:

9.2.9.1. El desarrollador deberá llevar a cabo pruebas de calificación de acuerdo con los requerimientos de calificación para el elemento software. Se deberá asegurar que se prueba la conformidad de la implementación de cada requerimiento software. Se deberán documentar los resultados de las pruebas de calificación.

9.2.9.2. El desarrollador deberá actualizar la documentación de usuario, si es necesario.

9.2.9.3. El desarrollador deberá evaluar el diseño, el código, las pruebas, los resultados de las pruebas y la documentación de usuario teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • a) Cobertura de las pruebas de los requerimientos del elemento software.

  • b) Conformidad con los resultados esperados.

  • c) Viabilidad de la integración del sistema y las pruebas, si se llevan a cabo.

  • d) Viabilidad de la operación y mantenimiento.

9.2.9.4. Se deberán documentar los resultados de las auditorías. Si el hardware y el software están bajo desarrollo o integración, las auditorías pueden posponerse hasta las pruebas de calificación del sistema.

9.2.9.5. Tras la finalización exitosa de las auditorías, si se llevan a cabo, el desarrollador deberá:

  • a) Actualizar y preparar el producto software entregable para la integración del sistema, pruebas de calificación del sistema, instalación del software o apoyo a la aceptación del software, como proceda.

9.2.10. Integración del sistema:

Esta actividad consta de las siguientes tareas, que el desarrollador deberá llevar a cabo o proporcionar apoyo, tal como requiere el contrato.

9.2.10.1. Los elementos de configuración software se deberán integrar con los elementos de configuración hardware, operaciones manuales y otros sistemas si es necesario, para formar el sistema. Se deberán probar las integraciones frente a sus requerimientos, al mismo tiempo que se desarrollen. Se deberán documentar los resultados de la integración y pruebas.

9.2.10.2. Se deberá desarrollar y documentar para cada requerimiento de calificación del sistema, un conjunto de pruebas, casos de prueba (entradas, salidas, criterios de prueba) procedimientos de prueba para llevar a cabo las pruebas de calificación del sistema. El desarrollador deberá asegurar que el sistema integrado está listo para las pruebas de calificación del sistema.

9.2.10.3. El sistema integrado se deberá evaluar teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • b) Cobertura de las pruebas de los requerimientos del sistema.

  • c) Adecuación de los métodos de prueba y normas usadas.

  • d) Conformidad con los resultados esperados.

  • e) Viabilidad de la prueba de calificación del sistema.

  • f) Viabilidad de la operación y mantenimiento.

9.2.11. Pruebas de calificación del sistema:

Esta actividad consta de las siguientes tareas que el desarrollador deberá llevar a cabo o proporcionar apoyo, tal como requiere el contrato.

9.2.11.1. Las pruebas de calificación del sistema se deberá llevar a cabo de acuerdo con los requerimientos de calificación especificados para el sistema. Se deberá asegurar que se prueba la conformidad de la implementación de cada requerimiento del sistema y que el sistema está listo para su entrega. Se deberán documentar los resultados de las pruebas de calificación.

9.2.11.2. Se deberá evaluar el sistema teniendo en cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.

  • a) Cobertura de las pruebas de los requerimientos del sistema.

  • b) Conformidad con los resultados esperados.

  • c) Viabilidad de la operación y mantenimiento.

9.2.11.3. El desarrollador deberá proporcionar apoyo a las auditorías de acuerdo con el apartado 6.7. Se deberán documentar los resultados de las auditorías.

9.2.11.4. Tras la terminación con éxito de las auditorías, si se han llevado a cabo, el desarrollador deberá:

  • a) Actualizar y preparar el producto software entregable para la instalación del software y el soporte a la aceptación del software.

9.2.12. Instalación del software:

Esta actividad consta de las siguientes tareas:

9.2.12.1. El desarrollador deberá preparar un plan para instalar el producto software en el entorno de destino, tal como se especifica en el contrato. Se deberán determinar y estar disponibles los recursos y la información necesaria para instalar el producto software.

El desarrollador deberá ayudar al adquiriente con las actividades de puesta en marcha tal como se especifique en el contrato. En los casos en que el software instalado reemplace a un sistema existente, el desarrollador deberá proporcionar apoyo a cualquier actividad realizada en paralelo que sea requerida por el contrato. Se deberá documentar el plan de instalación.

9.2.12.2. El desarrollador deberá instalar el producto software de acuerdo con el plan de instalación. Se deberá asegurar que el código software y las bases de datos se inicializan, ejecutan y terminan tal como se especifica en el contrato. Se deberán documentar las incidencias y resultados de la instalación.

9.2.13 Apoyo a la aceptación del software:

Esta actividad consta de las siguientes tareas:

9.2.13.1.El desarrollador deberá proporcionar apoyo a las revisiones y pruebas de aceptación llevadas a cabo por el adquiriente del producto software. Las revisiones y pruebas de aceptación deberán tener en cuenta los resultados de las revisiones conjuntas, auditorías, pruebas de calificación del software y pruebas de calificación del sistema (si se llevan a cabo). Se deberán documentar los resultados de las pruebas y revisiones de aceptación.

9.2.13.2. El desarrollador deberá completar y entregar el producto software tal como se especifica en el contrato.

9.2.13.3. El desarrollador deberá proporcionar formación inicial y continua y dar apoyo al adquiriente tal como se especifica en el contrato.

9.3. PROCESO DE OPERACIÓN

El proceso de operación contiene las actividades y tareas del operador. El proceso cubre la operación del producto software y el apoyo a la operación de los usuarios. Ya que la operación del producto software está integrado a la operación del sistema, las actividades y tareas de este

Lista de actividades. Este proceso consta de las siguientes actividades:

  • b) Implementación del proceso.

  • c) Pruebas de operación.

  • d) Operación del sistema.

  • e) Soporte al usuario.

9.3.1. Implementación del proceso:

Esta actividad consta de las siguientes tareas:

9.3.1.1.El operador debería preparar un plan y establecer un conjunto de normas de operación para llevar a cabo las actividades y tareas de este proceso. Se deberá documentar y ejecutar el plan.

9.3.1.2. El operador deberá establecer procedimientos para recibir, registrar, solucionar y hacer un seguimiento de los problemas y proporcionar información sobre su situación. En cuanto se encuentren problemas, se deberán registrar e introducir en el proceso de solución de problemas.

9.3.1.3.El operador deberá establecer procedimientos para probar el producto software en su entorno de operación, para alimentar con informes de problemas y peticiones de modificaciones al proceso de mantenimiento y para liberar el producto software para el uso en operación.

9.3.2. Pruebas de operación:

Esta actividad consta de las siguientes tareas:

9.3.2.1. Para cada relea se del producto software, el operador deberá llevar a cabo pruebas de operación y tras satisfacerse los criterios especificados, liberar el software para uso en operación.

9.3.2.2.El operador deberá asegurar que el código software y las bases de datos se inicializan, ejecutan y terminan tal como se describe en el plan.

9.3.3. Operación del sistema:

Esta actividad consta de la siguiente tarea:

9.3.3.1.El sistema deberá ser operado en el entorno previsto de acuerdo con la documentación de usuario.

9.3.4. Soporte al usuario:

Esta actividad consta de las siguientes tareas:

9.3.4.1. El operador deberá proporcionar asistencia y consultoría a los usuarios cuando la pidan. Estas peticiones y las acciones subsecuentes se deberán registrar y supervisar.

9.3.4.2. El operador deberá pasar las peticiones del usuario, cuando sea necesario, al proceso de mantenimiento para su solución. Estas peticiones se deberán tramitar y el originador de la petición deberá ser informado de las acciones que se planifiquen y se tomen. Se deberá hacer un seguimiento de todas las decisiones hasta su conclusión.

9.3.4.3. Si un problema reportado tiene una solución temporal, antes de que se pueda liberar una solución permanente, se deberá dar la opción a quien reportó el problema para que la use. Se deberán aplicar al software en operación, usando el proceso de mantenimiento (5.5), las correcciones permanentes, los releases que incluyan funciones o características omitidas anteriormente y las mejoras del sistema.

9.4. PROCESO DE MANTENIMIENTO

El proceso de mantenimiento contiene las actividades y tareas del responsable de mantenimiento. Este proceso se inicia cuando el producto software sufre modificaciones en el código y la documentación asociada, debido a un problema o a la necesidad de mejora o adaptación. El objetivo es modificar el producto software existente preservando su integridad. Este proceso incluye la migración y retirada del producto software. El proceso termina con la retirada del producto software.

Las actividades proporcionadas por esta área son específicas del proceso de mantenimiento; sin embargo, el proceso puede utilizar otros procesos de esta NTP. Si se usa el proceso de desarrollo (9.2), el término desarrollador se deberá interpretar en él como el responsable de mantenimiento.

El responsable de mantenimiento gestiona el proceso de mantenimiento a nivel de proyecto siguiendo el proceso de gestión, que se emplea en este proceso; establece una infraestructura basada en el proceso que se sigue en el proceso de infraestructura:

Adapta el proceso para el proyecto siguiendo el proceso de adaptación; y gestiona el proceso a nivel de organización siguiendo el proceso de mejora de proceso y el proceso de recursos humanos. Cuando el responsable de mantenimiento es el proveedor del servicio de mantenimiento, el responsable de mantenimiento lleva a cabo el proceso de suministro.

Lista de actividades. Este proceso consta de las siguientes actividades:

  • a) Implementación del proceso.

  • b) Análisis de problemas y modificaciones.

  • c) Implementación de las modificaciones.

  • d) Revisión/aceptación del mantenimiento.

  • e) Migración.

  • f) Retirada del software.

9.4.1. Implementación del proceso:

Esta actividad consta de las siguientes tareas:

9.4.1.1. El responsable de mantenimiento deberá preparar, documentar y ejecutar planes y procedimientos para llevar a cabo las actividades y tareas del proceso de mantenimiento.

9.4.1.2. El responsable de mantenimiento deberá establecer procedimientos para recibir, registrar y hacer seguimiento a los informes de problemas y a las peticiones de modificaciones de los usuarios y proporcionar información a los usuarios sobre su situación. En el momento en que se encuentren problemas, se deberán registrar e introducir en el proceso de solución de problemas.

9.4.1.3. El responsable de mantenimiento deberá implementar el proceso de gestión de la configuración (6.2) (o establecer una interfaz con él a nivel organizacional) para gestionar las modificaciones al sistema existente.

9.4.2. Análisis de problemas y modificaciones:

Esta actividad consta de las siguientes tareas:

9.4.2.1. El responsable de mantenimiento deberá analizar el informe del problema o la petición de modificación de acuerdo con su impacto en la organización, el sistema existente y los sistemas con los que interacciona según lo siguiente:

  • a) Tipo; por ejemplo correctivo, mejora, preventivo o adaptativo a un nuevo entorno.

  • b) Alcance; por ejemplo tamaño de la modificación, costo, tiempo para completar la modificación.

  • c) Aspectos críticos; por ejemplo, impacto en las características o seguridad física o de acceso.

9.4.2.2. El responsable de mantenimiento deberá reproducir o comprobar el problema.

9.4.2.3. Basándose en el análisis, el responsable de mantenimiento deberá preparar alternativas para implementar la modificación.

9.4.2.4. El responsable de mantenimiento deberá documentar el problema/petición de modificación, los resultados del análisis y las alternativas de implementación.

9.4.2.5. El responsable de mantenimiento deberá obtener la aprobación para la implementación de la alternativa seleccionada tal como se especifica en el contrato.

9.4.3. Implementación de las modificaciones:

Esta actividad consta de las siguientes tareas.

9.4.3.1. El responsable de mantenimiento deberá llevar a cabo el análisis y determinar qué documentación, unidades software y versiones requieren ser modificadas por esta causa. Se deberá documentar este análisis.

9.4.3.2. El responsable de mantenimiento deberá ejecutar el proceso de desarrollo (5.3) para implementar las modificaciones. Los requerimientos del proceso de desarrollo se deben complementar con lo siguiente:

  • a) Se deberán definir y documentar criterios de prueba y evaluación para probar y evaluar las partes modificadas y no modificadas del sistema (unidades software, componentes y elementos de configuración).

  • b) Se deberá asegurar la implementación completa y correcta de los requerimientos nuevos y modificados. También se deberá asegurar que los requerimientos originales no modificados no han sido afectados. Se deberán documentar los resultados de las pruebas.

9.4.4. Revisión/aceptación del mantenimiento:

Esta actividad consta de las siguientes tareas:

9.4.4.1. El responsable de mantenimiento deberá llevar a cabo revisiones, con la organización que autoriza las modificaciones, para determinar la integridad del sistema modificado.

9.4.4.2.El responsable de mantenimiento deberá obtener aprobación para la finalización satisfactoria de la modificación, tal como se especifica en el contrato.

9.4.5. Migración:

Esta actividad consta de las siguientes tareas:

9.4.5.1. Si se migra el sistema o producto software (incluyendo los datos) de un entorno de operación viejo a uno nuevo, se deberá asegurar que cualquier producto software o datos producidos o modificados durante la migración estén de acuerdo con esta NTP.

9.4.5.2. Se deberá preparar, documentar y ejecutar un plan de migración. Las actividades de planificación deberán incluir a los usuarios. El plan deberá incluir los siguientes elementos:

  • a) Análisis de los requerimientos y definición de la migración.

  • b) Desarrollo de las herramientas de la migración.

  • c) Conversión del producto software y de los datos.

  • d) Ejecución de la migración.

  • e) Verificación de la migración.

  • f) Soporte para el antiguo entorno en el futuro.

9.4.5.3. Se deberá notificar a los usuarios las actividades y planes de la migración.

Las notificaciones deberán incluir lo siguiente:

  • a) Declaración de por qué el antiguo entorno no va a seguir siendo soportado.

  • b) Descripción del nuevo entorno con su fecha de disponibilidad.

  • c) Descripción de otras opciones de soporte, si existen, una vez que ha cesado el soporte al antiguo entorno.

9.4.5.4. Para hacer más fluida la transición al nuevo entorno, se puede llevar a cabola operación en paralelo del antiguo y del nuevo entorno. Durante este periodo se deberá proporcionar la formación necesaria tal como se especifica en el contrato.

9.4.5.5. Cuando llegue el momento previsto de la migración, se deberá notificar a todos los afectados. Se deberá archivar toda la documentación, registros y código del antiguo entorno.

9.4.5.6. Se deberá llevar a cabo una revisión post-operación para evaluar el impacto del cambio al nuevo entorno. Los resultados de la revisión se deberán enviar a las autoridades apropiadas para su conocimiento, guía y actuación.

9.4.5.7. Los datos usados por o asociados al antiguo entorno deberán ser accesibles de acuerdo con los requerimientos del contrato sobre protección de datos y auditorías aplicables.

9.4.6. Retirada del software:

Esta actividad consta de las siguientes tareas:

9.4.6.1. Se deberá preparar y documentar un plan de retirada para el cese del soporte activo por parte de las organizaciones de operación y mantenimiento. Las actividades de planificación deberán incluir a los usuarios. El plan deberá considerar los elementos enumerados a continuación. El plan deberá ser ejecutado.

  • a) Cese total o parcial del soporte tras un cierto periodo de tiempo.

  • b) Archivo del producto software y de su documentación asociada.

  • c) Responsabilidad para cualquier aspecto de soporte residual en el futuro.

  • d) Transición hacia el nuevo producto software, si es aplicable.

  • e) Accesibilidad de las copias archivadas de los datos.

9.4.6.2. Se deberá notificar a los usuarios s los planes y actividades de la retirada.

Las notificaciones deberán incluir lo siguiente:

  • a) Descripción del sustitutivo o mejora, con su fecha de disponibilidad.

  • b) Descripción del por qué el producto software no va a seguir siendo soportado.

  • c) Descripción de otras opciones de soporte disponibles, una vez que el soporte ha cesado.

9.4.6.3. Para facilitar la transición al nuevo sistema, conviene que se lleve a cabo la operación en paralelo del sistema a retirar y del nuevo producto software.

Durante este período, se deberá proporcionar formación a los usuarios, tal como se especifica en el contrato.

9.4.6.4. Cuando llegue la fecha prevista de retirada, se deberá notificar a todos los afectados. Toda la documentación de desarrollo asociada, registros y código se deberán archivar en el momento oportuno.

9.4.6.5. Los datos usados o asociados al producto software retirado deberán ser accesibles de acuerdo con los requerimientos del contrato sobre protección de datos y auditorías aplicables.

  • EL DESARROLLADOR DEBERÁ:

  • a) Documentar las salidas de acuerdo con el proceso de documentación.

  • b) Poner las salidas basándose en el proceso de gestión de la configuración y llevar a cabo el control de los cambios de acuerdo con él.

  • c) Documentar y solucionar los problemas y no conformidades encontradas en los productos software y tareas de acuerdo con el proceso de solución de problemas.

  • d) Llevar a cabo los procesos de apoyo (capítulo 6) tal como se especifique en el contrato.

  • e) Establecer una línea base para cada elemento de la configuración con los elementos apropiados, como los determinados por el adquiriente y el proveedor.

El desarrollador deberá seleccionar, adaptar y usar aquellas normas, métodos, herramientas y lenguajes de programación (si no están estipulados en el contrato) que estén documentados, sean pertinentes y estén establecidos por la organización para llevar a cabo las actividades del proceso de desarrollo y de los procesos de apoyo.

El desarrollador deberá preparar planes para realizar las actividades del proceso de desarrollo. Los planes deberían incluir normas específicas, métodos, herramientas, acciones y responsabilidades asociadas con el desarrollo y calificación de todos los requerimientos, incluyendo los de seguridad física y de acceso. Si fuese necesario, se pueden preparar planes separados. Se deberán documentar y ejecutar estos planes.

Para el desarrollo y mantenimiento del producto software se pueden emplear elementos no entregables. Sin embargo, se deberá asegurar que la operación y mantenimiento del producto software entregable, luego de entregado al adquiriente, es independiente de dichos elementos, de otra manera se deberán considerar como entregables.

  • PLATAFORMA TECNOLÓGICA:

La solución de desarrollo del Sistema deberá ser implementada bajo una arquitectura de 3 capas:

  • Capa de Presentación:

Es la que ve el usuario (también de la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta etapa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario,

  • Capa de Negocio:

Es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y que se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta etapa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación.

  • Capa de Datos:

Es donde residen los datos y es la encargada de acceder a los mismos. Está conformada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocios.

Las ventajas de usar esta arquitectura son las siguientes:

  • El desarrollo se puede llevar a cabo en varios niveles.

  • Desarrollos paralelos (en cada capa).

  • Aplicaciones más robustas debido al encapsulamiento.

  • En caso que sobrevenga algún cambio, solo se ataca al nivel requerido sin tener que revisar ente código mezclado.

  • Mantenimiento y soporte más sencillo (es más sencillo cambiar un componente que modificar un aplicación monolítica).

  • Mayor flexibilidad (se pueden añadir nuevos módulos para dotar al sistema de nueva funcionalidad).

  • Alta escalabilidad. La principal ventaja de un aplicación distribuida bien diseñada es su buen escalamiento, es decir, que puede manejar muchas peticiones con el mismo rendimiento simplemente añadiendo más hardware.

  • El crecimiento es casi lineal y no es necesario añadir más código para conseguir esta escalabilidad.

edu.red

Sistema de hipótesis:

  • Disminución del tiempo promedio en el trámite o atención de un documento, debido a que se eliminan tareas repetitivas, evitando olvidos y/o documentos traspapelados.

  • Aumento en la productividad gracias a la implantación de procesos lógicos para la atención de la documentación.

  • Disminución del uso de papel, reduciendo drásticamente los gastos por este concepto.

Sistema de variables:

  • Variables Independientes:

  • Disminución del tiempo promedio en el trámite.

  • Aumento en la productividad.

  • Disminución del uso de papel.

  • Variables Dependientes:

  • Eliminación de Tareas Repetitivas.

  • Automatización de Procesos Lógicos.

  • Estandarización de la documentación emitida.

Biografia

  • http://www.tiposdeinvestigacion.com/

  • http://www.monografias.com/

  • http://www.unac.edu.pe/

  • Inicio

  • www.municusco.gob.pe

  • www.unamad.edu.pe/

 

 

Autor:

Estudiante: John Paul Moscoso Noriega

Estudiante: Toño Avalos Salinas

Asesor:

Ing. Jaqueline Salas Cente

Doc. Jorge Pinazo Delgado

Partes: 1, 2
 Página anterior Volver al principio del trabajoPágina siguiente