Antes de imprimir este documento piense en el medio ambiente!

Transcripción

1 Versión 2.0 Página 1 de OBJETIVO: Establecer las etapas que se siguen en el desarrollo y mantenimiento evolutivo y adaptativo de sistemas de información, definiendo el flujo de actividades que se ejecutan para la entrega de un sistema de información nuevo o en mantenimiento. 2. ALCANCE: Inicia con la recepción de la solicitud por parte de un contratista o funcionario de la Subdirección de Sistemas Información del ICBF y termina con la entrega de un desarrollo probado y aceptado por un área funcional. Su aplicación es a nivel de la sede de la Dirección General. 3. DESCRIPCIÓN DE ACTIVIDADES No Actividad Responsable Registro 1 Inicio Recibir, categorizar y direccionar las solicitudes o requerimientos Criterio operativo A Realizar análisis de la viabilidad funcional, técnica y operativa del requerimiento Profesional de la Subdirección de Sistemas Información / Contratista F1.PR5.MPA6.Formato de solicitud de requerimiento 2 El requerimiento es viable funcional y técnicamente? No: notificar no viabilidad del requerimiento y finaliza. Profesional responsable del equipo de análisis de la Correo de notificación Si: iniciar planeación del análisis y asignar requerimiento al analista. Criterio operativo B

2 Versión 2.0 Página 2 de 13 No Actividad Responsable Registro Documento ERS F5.PR5.MPA6 Formato caso de uso 3 Realizar la especificación de los requerimientos funcionales. Criterio operativo C Criterio operativo D Analista de Requerimientos de la Subdirección de Sistemas Información/ Contratista F10.PR5.MPA6 Formato Novedades de Sistemas de Información F1.PR3.MPA6.Formato requerimiento de cambio Manual de Usuario Realizar inspección de la especificación del requerimiento y del caso de prueba. 4 El caso de uso/formato de novedades está correcto? No: registrar solicitud de ajuste del caso de uso/formato de novedades. Continúa actividad 3. Profesional de arquitectura/analista de la F3.PR5.MPA6 Lista de Chequeo de Caso de uso 5 Si: registrar solicitud para firma del caso de uso/formato de novedades Registrar especificación del requerimiento y escalar solicitud relacionando la ruta de la documentación elaborada. El requerimiento impacta la arquitectura? No: continuar actividad 9 Profesional responsable equipo de análisis/analista de requerimientos de la Información/ Contratista Share Point Si: continuar actividad 6

3 Versión 2.0 Página 3 de 13 No Actividad Responsable Registro Realizar la especificación de requerimientos no funcionales y elaborar o actualizar el documento de Arquitectura de Software y el caso de prueba no funcional. Criterio operativo E. Realizar la inspección de los documentos de arquitectura de software y caso de prueba no funcional. Los documentos están correctos? No: registrar solicitud de ajuste de los documentos. Continúa actividad 6 Si: continuar actividad 8 Registrar y escalar la solicitud adjuntando la ruta de la documentación elaborada. Recibir los requerimientos y realizar la planeación del desarrollo. Criterio Operativo F. Realizar el análisis de la solución para su desarrollo. La solución implica ajuste del diseño del sistema? No: continuar actividad 12 Si: elaborar o ajustar el diseño Profesional de arquitectura de la Subdirección de la Profesional de arquitectura de la Subdirección de la Profesional de arquitectura de la Profesional responsable del equipo de desarrollo de la Ingeniero desarrollador de la Documento de Arquitectura de Software F8.PR5.MPA6.Formato Ficha Técnica F6.PR5.MPA6. Lista de chequeo caso de prueba F4.PR5.MPA6. Lista de Chequeo SAD (Documento de Arquitectura de Software SAD) Share Point F9.PR5.MPA6. Formato modelo y diccionario de datos

4 Versión 2.0 Página 4 de 13 No Actividad Responsable Registro 11 Realizar inspección de la solución del diseño El diseño esta correcto? No: notificar ajustes del documento. Continúa actividad 10 Profesional de arquitectura/desarrollador de la Subdirección Sistemas F11.PR5.MPA6.Lista de chequeo de Diseño Si: continuar actividad 12 Código fuente 12 Realizar la construcción de los requerimientos solicitados y ejecutar las pruebas unitarias. Ingeniero desarrollador de la Artefactos de desarrollo Readme Pruebas Unitarias Realizar la inspección de código F1.PR3.MPA6.Formato requerimiento de cambio El código esta correcto? No: notificar ajuste del código. Continúa actividad 12 Si: solicitar el despliegue del desarrollo en ambiente de pruebas. Desplegar el desarrollo en el ambiente de pruebas Registrar construcción de requerimientos y escalar la solicitud. Profesional de arquitectura/desarrollador de la Subdirección Sistemas Responsable de configuración de la Subdirección de Sistemas Ingeniero desarrollador de la F12.PR5.MPA6. Lista de chequeo código fuente Share Point 16 Recibir desarrollo y realizar la planeación de las pruebas Profesional responsable del equipo de pruebas

5 Versión 2.0 Página 5 de 13 No Actividad Responsable Registro Ejecutar y documentar las pruebas de los requerimientos construidos. 17 Las pruebas son exitosas? No: remitir las inconsistencias a desarrollo. Continúa actividad 12. Si: solicitar el despliegue del desarrollo en ambiente de soporte. Ingeniero de pruebas de la Criterio operativo G Ejecutar pruebas de aceptación en ambiente de soporte. F7.PR5.MPA6. Formato escenario de prueba 18 Las pruebas son exitosas? No: remitir las inconsistencias a desarrollo. Continúa actividad 12. Si: continuar actividad 19 Ingeniero de pruebas de la F1.PR3.MPA6.Formato requerimiento de cambio F13.PR5.MPA6.Lista de chequeo RFC 19 Criterio operativo H Registrar y escalar la solicitud relacionando la ruta de la documentación elaborada. Recibir y verificar la documentación requerida para la puesta en producción. Profesional responsable del equipo de pruebas/ingeniero de pruebas de la Subdirección de Sistemas Manual de usuario Share Point Está completa la documentación? 20 Si: se activa el instructivo para la puesta en producción de sistemas de información. Encargado de configuración de la Subdirección de Sistemas Información/ Contratista No: escalar al Profesional de la Información responsable de completar la documentación, y se retoma la actividad 20.

6 Versión 2.0 Página 6 de 13 No Actividad Responsable Registro 21 Realizar entrega del desarrollo del requerimiento en producción al usuario funcional Profesional responsable del equipo de análisis de la Criterio Operativo I FIN Nota: las celdas sombreadas corresponden a puntos de control. 4. CRITERIOS OPERATIVOS: Criterio A: F2.PR5.MPA6.Formato acta de aceptación Las solicitudes o requerimientos se reciben a través de la cuenta siatuservicio@icbf.gov.co con el formato de solicitud de requerimiento. Se categorizan y direccionan así: a) Solicitud de generación de reportes y/o cruces con bases de datos se direccionan al responsable de consultas de información de la SSII. b) Requerimientos que implican un desarrollo se direccionan al responsable de los sistemas de información de apoyo o misional según corresponda. Criterio B: Previo levantamiento de requerimientos, se realiza el análisis de la viabilidad funcional, técnica y operativa del requerimiento. Si producto del análisis se identifica que es viable desarrollar los requerimientos solicitados, se realiza la planeación del análisis en la que se estima el esfuerzo, tiempo y asignación de recurso para esta etapa. La estimación de esfuerzos de un sistema de información nuevo o varias funcionalidades se basa en las metodologías puntos función, juicio de expertos e históricos de la herramienta y su resultado se obtiene en la etapa de análisis; la estimación de esfuerzos de ajuste a una funcionalidad existente se basa en juicio de expertos e histórico de la herramienta y su resultado se obtiene cuando se realiza la planeación del desarrollo del caso de uso o formato de novedades firmado. La duración del ciclo del procedimiento puede variar de acuerdo con la complejidad del requerimiento del usuario, su impacto en la arquitectura del (los) sistema(s) de información y necesidades de infraestructura tecnológica para su adecuado desempeño. El resultado del análisis de la viabilidad del requerimiento y el tiempo estimado de su entrega es informado al área solicitante mediante el envío de correo electrónico en dos fases, en la primera se informa acerca de la viabilidad y tiempo estimado del análisis del requerimiento y en la segunda, el tiempo estimado de entrega del desarrollo para pruebas de aceptación de los casos de uso o novedades asociados al requerimiento firmados por el usuario funcional. Los tiempos estimados de análisis y entrega del desarrollo para pruebas de aceptación pueden variar por factores externos a este procedimiento tales como decisiones de la alta Dirección o situaciones no controladas por la Información, las variaciones que se presenten en los tiempos de entrega serán informadas al usuario funcional.

7 Versión 2.0 Página 7 de 13 Criterio C: Para el caso de requerimientos asociados a solicitudes de: - ajustes por errores del sistema, - ajuste por cambios de normatividad, - registro equivocado de información, - modificaciones a una funcionalidad específica ya existente, No se generará el documento ERS (Especificación de Requerimientos del Sistema). En caso que la solicitud abarque cambios en más de una funcionalidad de un sistema, que su alcance genere un versionamiento mayor o se solicite un sistema de información nuevo, se deberá elaborar o actualizar el ERS (Especificación de Requerimientos del Sistema). Para el levantamiento de los requerimientos se utiliza el formato caso de uso que aplica para la especificación de funcionalidades nuevas o el formato de novedades de sistema de información para especificar modificaciones a funcionalidades existentes. Cada vez que se realice el levantamiento de una funcionalidad nueva se actualiza el diagrama de casos de uso, si el levantamiento corresponde a funcionalidades existentes, se actualiza el caso de uso en el que se especificó dicha funcionalidad. El caso de uso y/o formato de novedades se firma cuando el responsable del equipo de análisis de su aval según la inspección que realice al levantamiento del requerimiento. Criterio D: Al culminar la especificación del requerimiento, el analista elabora el caso de prueba en la herramienta Team, este es validado mediante la aplicación de la F6.PR5.MPA6.lista de chequeo caso de prueba y el registro del caso de prueba queda en la herramienta. Si el caso de prueba es correcto se notifica al equipo de pruebas. El formato de requerimiento de cambio para surtir la puesta en producción debe ser diligenciado por los equipos de análisis, desarrollo y pruebas, con el fin de presentarlo para aprobación en el comité de control de cambios. El manual de usuario de un aplicativo nuevo es elaborado por los equipos de análisis y pruebas. Para los casos en que se requiera actualizar el manual existente, el equipo de pruebas realiza dicha actualización. La documentación producto del análisis de requerimientos se almacena en el repositorio de documentos, de acuerdo con las orientaciones brindadas en el IT2 MPA6 instructivo para el cargue de documentación en Microsoft share point V2. 1 Criterio E: Para los casos en que el requerimiento impacta la arquitectura de los sistemas de información, se realiza el levantamiento de requerimientos no funcionales, y se elabora o actualiza el

8 Versión 2.0 Página 8 de 13 documento de Arquitectura de Software y el caso de prueba no funcional, el cual queda registrado en la herramienta Team. La documentación producto del análisis de requerimientos no funcionales se almacena en el repositorio de documentos, de acuerdo con las orientaciones brindadas en el IT2 MPA6 instructivo para el cargue de documentación en Microsoft share point V2. 1 Criterio F: La estimación de esfuerzos de casos de uso y/o formato de novedades que corresponden a un sistema de información nuevo o varias funcionalidades se basa en la metodología puntos de caso de uso, juicio de expertos e históricos de la herramienta; la estimación de esfuerzos de ajuste a una funcionalidad existente se basa en juicio de expertos e histórico de la herramienta. Los tiempos estimados de desarrollo se notifican mediante correo electrónico al usuario funcional. Previo envío del requerimiento desarrollado a pruebas el desarrollador debe verificar la solución en el ambiente pruebas. La documentación producto del desarrollo de requerimientos, se almacena en el repositorio de documentos, de acuerdo con las orientaciones brindadas en el IT2 MPA6 instructivo para el cargue de documentación en Microsoft share point V2. 1 Criterio G: Con el fin de evitar tiempos muertos así como entregas inconsistentes, se ha definido que la actividad 17 del procedimiento se ejecutará hasta tres veces, durante las cuales la curva de inconsistencias debe finalizar con cero defectos. Si al cabo de la tercera ejecución aún se presentan inconsistencias, los profesionales y/o contratistas que participan en las actividades de: especificación de requerimientos de sistemas de información y construcción, deberán realizar sesión de trabajo, con el fin de realizar un análisis de causas, solución de inconsistencias y revisión previa del producto. Una vez se surta esta actividad deberán entregar el desarrollo a la etapa de pruebas y aceptación, garantizando la solución de la totalidad de las inconsistencias presentadas. Criterio H: En caso en que la puesta en Producción del requerimiento aceptado por el usuario funcional requiera el desarrollo de una nueva funcionalidad o de un ajuste a la funcionalidad existente, el usuario funcional debe realizar la solicitud o requerimiento a la SSII a través de la cuenta siatuservicio@icbf.gov.co. 1 La documentación que se almacena en el repositorio de documentos corresponde a: Documento ERS, Formato Caso de uso, Formato Novedades de Sistemas de Información, Formato requerimiento de cambio, Manual de Usuario, Documento de arquitectura de Software, ficha técnica, modelo y diccionario de datos, listas de chequeo, escenario de prueba, acta de aceptación.

9 Versión 2.0 Página 9 de 13 El equipo de Pruebas de la Información realiza la revisión del formato requerimiento de cambio previo envío de la documentación para la puesta en producción del requerimiento, mediante la aplicación de la F13.PR5.MPA6. Lista de chequeo RFC. Antes de realizar el despliegue en el ambiente de producción, el equipo de pruebas realiza la verificación del desarrollo aprobado por el usuario funcional en el ambiente de preproducción. La documentación producto de la ejecución de las pruebas se almacena en el repositorio de documentos, de acuerdo con las orientaciones brindadas en el IT2 MPA6 instructivo para el cargue de documentación en Microsoft share point V2. 1 Criterio I: Si el usuario funcional solicita que no se despliegue en producción el requerimiento que fue desarrollado y aceptado funcionalmente, se debe relacionar en el acta de aceptación funcional las razones por las cuales no se realiza el despliegue, esta acta debe firmarse por el área solicitante y la Subdirección de sistemas Información. 5. DURACIÓN DEL CICLO DEL PROCEDIMIENTO (DÍAS): 140 días Este tiempo corresponde a un estimado, teniendo en cuenta que depende de los criterios operativos que se enuncian en el procedimiento, y de otras circunstancias como: decisiones de alto nivel, re priorización de requerimientos, disponibilidad de los usuarios funcionales que intervienen en la especificación y pruebas, cambios o ajustes de la normatividad o del proceso de operación, solicitudes adicionales a las estipuladas inicialmente. 6. PRODUCTO: Sistema de información especificado, diseñado, desarrollado, probado y aceptado, o sistema de información evolucionado o adaptado. 7. DEFINICIONES: Aplicación: Conjunto de artefactos que responden a las necesidades de negocio del ICBF. Artefacto: una de las formas de resultados tangibles producidos durante el desarrollo de software. Para el presente procedimiento se refiere a los scripts, ejecutables y compilado que se suministran para ser desplegados en un ambiente de pruebas o de producción. Analista de requerimientos: encargado de realizar el enlace con el área usuaria que expresa la necesidad de un desarrollo, transformándolo en entregables que serán el insumo para las etapas de diseño, desarrollo y pruebas del sistema de información. Arquitecto: es la persona encargada de llevar a cabo y verificar el proceso de diseño de un sistema de información o el ajuste a una funcionalidad existente. BD: Base de datos.

10 Versión 2.0 Página 10 de 13 Base de datos: es un conjunto de objetos organizados, tablas, campos, registros, relaciones y restricciones, principalmente, de forma que un sistema de información pueda atender las necesidades de información de un área funcional o un grupo de usuarios. Diccionario de datos: un diccionario de datos es un conjunto de metadatos que describe las características lógicas y puntuales de los objetos que conforman una base de datos, incluyendo nombre, descripción, alias, contenido y organización. ERS: Especificación de Requerimientos de Sistema Ingeniero desarrollador: es el encargado de transformar los requerimientos suministrados en programas y desarrollos que hacen parte de un Sistema de Información. Ingeniero de pruebas: es el encargado de revisar que los productos suministrados por la etapa de desarrollo correspondan a las necesidades documentadas en la etapa de análisis y especificación de requerimientos. Encargado de configuración: tiene a su cargo realizar la administración de los ambientes de pruebas, efectúa el despliegue de los desarrollos en la etapa de pruebas, y gestiona la puesta en producción de los sistemas de información o aplicaciones que se desarrollen. Mantenimiento evolutivo y adaptativo de un sistema de información. Corresponde a modificaciones que se adelantan en respuesta a las necesidades expresadas por los usuarios funcionales de sistemas de información existentes. Sistema de información. Conjunto de aplicaciones que interactúan entre sí para apoyar un área o proceso del ICBF Sistema de información nuevo. Corresponde a los desarrollos que se deban adelantar en respuesta a las necesidades expresada por un proceso o macroproceso del ICBF, y que no puede ser satisfechas por un sistema que se encuentre en operación en el ICBF. Usuario funcional: es el delegado por el área usuaria para participar y dar el aval a los casos de uso y escenarios de prueba. Readme: es un documento de texto que acompaña normalmente a los artefactos de desarrollo, en el cual hay información de relevancia sobre estos en cuanto a su uso, nuevas características, errores (bugs) y requisitos de hardware. En el presente procedimiento se suministra en formato de texto plano. Share Point: también conocido como Microsoft SharePoint Products and Technologies, es una plataforma de colaboración empresarial, formada por productos y elementos de software que incluye, entre una selección cada vez mayor de componentes, funciones de colaboración, basado en el Explorador web, módulos de administración de proceso, módulos de búsqueda y una plataforma de administración de documento.

11 Versión 2.0 Página 11 de 13 SharePoint puede utilizarse para sitios de web host que acceda a espacios de trabajo compartidos, almacenes de información y documentos. En el ICBF se utiliza como repositorio documental. SSII: Información. Versionamiento: El versionamiento de software es el proceso de asignación de un número único a un software para indicar su nivel de desarrollo, que se inicia en durante su etapa de desarrollo y una vez se realiza su puesta en producción se iniciar el conteo a partir de la versión La Dirección de Información y Tecnología del ICBF, tienen establecido que el versionamiento se identificará usando tres números que se van incrementando conforme el desarrollo del software aumente y se requiera la asignación de un nuevo número único. El incremento del número se realiza de acuerdo a las siguientes condiciones: - Mayor: el software sufre grandes cambios y mejoras. La adición de un nuevo módulo al sistema. - Menor: el software sufre pequeños cambios y/o correcciones de errores. La adición de nuevas funcionalidades, cambios de la plataforma o de interface. - Micro: se aplica una corrección al software, y a su vez sufre pocos o ningún cambio. Ajustes pequeños a las funcionalidades, por ejemplo, adicionar un campo, modificar textos, modificar mensajes, entre otros, o solucionar un error que afecté la adecuada ejecución de una funcionalidad. Team : es una herramienta de colaboración que integra las aplicaciones del cliente proveyendo herramientas de administración, información del proyecto y control de código fuente integrado. 8. DOCUMENTOS DE REFERENCIA IT2.MPA6 Instructivo para el cargue de documentación en microsoft share point IT3.MPA6 Instructivo de puesta en producción de aplicaciones y/o sistemas de información G4.MPA6 Guía de Estándares de Desarrollo y de Arquitectura de Sistemas de Información G3.MPA6 Guía de estándares de especificación de requerimientos G2.MPA6 Guía de estimación de esfuerzo para desarrollos nuevos 9. RELACIÓN DE FORMATOS F1.PR5.MPA6 Formato de Solicitud de requerimiento F2.PR5.MPA6 Formato Acta de aceptación. F3.PR5.MPA6 Lista de Chequeo de Caso de uso F4.PR5.MPA6 Lista de chequeo SAD F5.PR5.MPA6.Formato caso de uso. F6.PR5.MPA6 Lista de chequeo caso de prueba F7.PR5.MPA6. Formato Escenario de prueba F8.PR5.MPA6.Formato Ficha Técnica F9.PR5.MPA6. Formato Modelo y diccionario de datos F10.PR5.MPA6 Formato Novedades Sistema de Información F11.PR5.MPA6 Lista de chequeo de Diseño

12 Versión 2.0 Página 12 de 13 F12.PR5.MPA6 Lista de chequeo código fuente F13.PR5.MPA6 Lista de chequeo RFC F1.PR3.MPA6 Formato Requerimiento de Cambio 10. ANEXOS N/A 11. NATURALEZA DE LOS CAMBIOS: Ítem Modif. 3 Nombre del ítem Descripción de actividades Descripción del Cambio Versión inicial Se modificaron los criterios operativos A,B,C,D Se incorporaron los criterios operativos E,F,G,H,I Se incorporaron actividades de análisis de viabilidad de requerimientos, planeación e inspección de las etapas de análisis, diseño, desarrollo y pruebas. Se ajustaron las actividades de análisis, arquitectura, construcción de requerimientos y ejecución de pruebas. Se eliminaron los formatos: F4.PR5.MPA6 Formato Caso de prueba, F4.PR5.MPA6 Formato resultado Ejecución de pruebas, F3.PR5.MPA6.Formato anexo de resultado de pruebas, F6.PR5.MPA6. Formato consolidado de pruebas, F12.PR5.MPA6. Formato guion de pruebas Los formatos documento de diseño y arquitectura aplicaciones y documento de diseño y arquitectura inteligencia de negocios se unificaron en el Documento de Arquitectura de Software. 7 Definiciones 8 Documentos de referencia Se incorporan los formatos: - Solicitud de requerimiento - Lista de Chequeo de Caso de uso - Lista de chequeo caso de prueba - Lista de chequeo SAD - Lista de chequeo de Diseño - Lista de chequeo código fuente - Lista de chequeo RFC Se elimina conceptos Esquemas de bases de datos y Pruebas Funcionales. Se modifica concepto Líder de configuración por Encargado de configuración. Se incorporan los documentos: IT3.MPA6 Instructivo de puesta en producción de

13 Versión 2.0 Página 13 de 13 Ítem Modif. Nombre del ítem 9 Relación de formatos Descripción del Cambio aplicaciones y/o sistemas de información, G3.MPA6 Guía de estándares de especificación de requerimientos, G2.MPA6 Guía de estimación de esfuerzo para desarrollos nuevos Se actualiza listado de los formatos, según lo mencionado en el ítem 3. Descripción de actividades.