Guía Gestión de Desarrollo - Supersalud · Web viewPruebas de aceptación: Los test de...

PROCESO

PROVISIÓN DE SOLUCIONES TECNOLÓGICAS

CÓDIGO RSGU03

GUÍA GESTIÓN DE DESARROLLO VERSIÓN 2

GUÍAGestión de desarrollo

BOGOTÁ D.C.2016

ELABORÓ: Profesional Oficina de Tecnologías de la Información

REVISÓ: Profesional Oficina de Tecnologías de la Información

APROBÓ: Jefe de Oficina de Tecnologías de la Información

FECHA:19/06/2015

FECHA: 16/07/2015

FECHA: 16/07/2015

PROCESO


CÓDIGO RSGU03


Tabla de Contenido

1. Objetivo..............................................................................................................22. Alcance..............................................................................................................23. Ámbito de Aplicación.........................................................................................24. Requisitos de Calidad Aplicable........................................................................25. Definiciones.......................................................................................................26. Generalidades...................................................................................................36.1 Funciones.......................................................................................................36.2 Control de la unidad.......................................................................................46.3 Puesta en marcha..........................................................................................67. Relación de actividades para la Gestión de desarrollos:...................................6Referencias Bibliográficas:.....................................................................................15

1

PROCESO


CÓDIGO RSGU03


1. Objetivo

La gestión de aplicaciones debe asegurarse que se cumple con el ciclo de vida y el conocimiento técnico requerido para diseñar, construir, aseguramiento de calidad, soportar, operar y gestionar las aplicaciones a través del uso de metodologías referencias CMMI y SCRUM, para entregar productos y servicios de mejor calidad, rápidamente y con uso óptimo de los recursos.

La gestión de aplicaciones debe asegurarse de dar cumplimiento por medio de los documentos de aprobación de cada etapa los diseños aprobados en la actividad No. 4.

2. Alcance

Inicia con las opciones de alternativas de solución, elaboración del diseño, continua con la preparación del ambiente de desarrollo, diseño de los guiones de pruebas y su aplicación y termina con toda la etapa preparación de ambiente de desarrollo de pruebas, guías, la elaboración de manuales, capacitación, plan de migración presentación para aprobación del sistema por parte de los dueños de proceso,

3. Ámbito de Aplicación

La presente guía aplica para todos los procesos del Sistema Integrado de Gestión referente a la gestión de mantenimiento de las soluciones tecnológicas con que cuenta la entidad.

4. Requisitos de Calidad Aplicable

Está guía da cumplimiento a los lineamientos establecidos en la Norma Técnica Colombiana NTCGP – 1000 en especial en el numeral 6.3 Infraestructura, para los literales b) equipo para los procesos, (tanto hardware como software), y c) servicios de apoyo (tales como transporte o comunicación).

2

PROCESO


CÓDIGO RSGU03


5. Definiciones

DISEÑO DE SISTEMAS: se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física.

AMBIENTE DE DESARROLLO: proveer la infraestructura de hardware y software necesaria para realizar la implementación del sistema y la ejecución de pruebas unitarias por parte de cada desarrollador.

CICLO DE VIDA DEL SOFTWARE (SDLC): El ciclo de vida del Software hace referencia al marco usado para estructurar, planear y controlar los procesos de desarrollar sistemas de información.

CMMI (Capability Maturity Model Integration): CMMI es un modelo de referencia que cubre las actividades esenciales para desarrollar productos y servicios, contiene las prácticas necesarias para la gestión de proyectos, administración de proyectos, ingeniería de sistemas, ingeniería de software, y soporte a los procesos usados en el desarrollo y mantenimiento.

SCRUM: Marcos de desarrollo ágiles caracterizados por:

- Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.

- Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados.

- Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

Pruebas unitarias: Las pruebas unitarias son definidas para comprobar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado, en esta sección se definen los módulos o funcionalidades sobre los cuales se deben realizar pruebas unitarias, estos componentes o funcionalidades debe relacionarse en el formato de pruebas unitarias.Pruebas de integración: Las pruebas de integración se definen como las pruebas para evaluar un proceso compuesto por varios componentes o funcionalidades y se deben relacionar con el formato de pruebas de integración.Pruebas de aceptación: Los test de aceptación son aquellos destinados a determinar si los requisitos de cierta funcionalidad han sido cumplidos, como usuarios finales, no tienen por qué preocuparse por los detalles de la

3

PROCESO


CÓDIGO RSGU03


implementación, sino que deberían poder centrarse más en que la parte funcional cumple las expectativas creadas al inicio del Sprint. Pruebas de regresión: Se definen el conjunto de pruebas necesarias para validar que ante eventuales cambios en el software, como parches, ajuste en datos, cambios en la configuración, interfaces, orígenes de datos etc. Las características del software se comporten de manera correcta.Pruebas de rendimiento: Se definen el conjunto de pruebas asociadas al rendimiento del software y los mecanismos por los cuales se realizarán estas pruebas.Pruebas de seguridad: Se definen el conjunto de pruebas asociadas a la seguridad del software y los mecanismos por los cuales se realizarán estas pruebas.

6. Generalidades

6.1Funciones

Mientras la mayoría de equipos/departamentos de Gestión de Aplicaciones se dedican a aplicaciones específicas o conjuntos de ellas, existen ciertas actividades comunes:

Diseñar y desarrollar (aunque no impartir) programas de formación destinada al usuario final. Aunque otros equipos o incluso terceros pueden ser quienes la impartan finalmente, la Gestión de Aplicaciones es responsable de que ésta sea adecuada.

La Gestión de Aplicaciones también se encarga de definir estándares para o Diseñar nuevas arquitecturas, participando además en la definición

de las mismas durante las fases de Estrategia y Diseño.o Las herramientas de Gestión de Eventos y respuestas “modelo” a

ciertos tipos de eventos.o Estándares de rendimiento que luego serán utilizados por la Gestión

de la Disponibilidad y la de la Capacidad.o Además, la Gestión de Aplicaciones es responsable de especificar

las actividades necesarias para mantener dichas aplicaciones.o Pruebas de funcionalidad, rendimiento y manejabilidad de servicios.o La Gestión de Aplicaciones es, a menudo, quien dirige el despliegue

de las nuevas versiones durante la fase de Transición.o En la Mejora Continua, ayudando en la tarea de identificar

oportunidades de mejora.o Colaborar en la actualización de la documentación del sistema,

garantizando que la información está actualizada y es bien conocida por el personal.

4

PROCESO


CÓDIGO RSGU03


o La Gestión de Aplicaciones también contribuye a mantener actualizadas las políticas de configuración de software.

Investigación y desarrollo de soluciones que ayuden a expandir el Portafolio de Servicios o al menos a mejorar la prestación de los mismos.

Proporcionar asesoramiento en riesgos, identificando servicios críticos y dependencias de sistema y definiendo e implementando contramedidas.

Gestión de requerimientos:- Desarrollar un entendimiento de los requerimientos de los

proveedores con el significado del requerimiento.- Obtener compromiso de los participantes del proyecto hacia los

requerimientos.- Gestionar los cambios de los requerimientos a medida que

evolucionan durante el proyecto.- Mantener trazabilidad bidireccional entre los requerimientos y los

productos de trabajo.- Asegurar que el plan de proyecto y los productos de trabajo

permanecen alineados con los requerimientos Gestión de planeación de proyectos:

- Establecer una estructura de alto nivel para estimar el alcance del proyecto

- Establecer y mantener las estimaciones de los atributos de los productos trabajo y de las tareas

- Definir las fases del ciclo de vida sobre las cuales se planifica el alcance del esfuerzo

- Estimar los esfuerzos del proyecto, los costos por productos de trabajo y las tareas basado en una estimación racional.

Monitoreo y control de proyectos:- Monitoreo de los valores actuales de los parámetros de proyecto

contra el plan de proyecto.- Monitoreo de compromisos- Monitoreo de los riesgos del proyecto- Monitoreo de la gestión de la información- Monitoreo del involucramiento de interesados- Monitorear periódicamente el progreso del proyecto, rendimientos e

incidentes- Revisar los logros y los resultados del proyecto en etapas

seleccionadas del proyecto.- Recolectar y analizar las incidencias.- Tomar acciones correctivas sobre las incidencias identificadas- Gestionar las acciones correctivas.

Gestión de configuración:- Identificar los ítems de configuración, componentes y trabajo

relacionado a ser puesto en gestión de la configuración.

5

PROCESO


CÓDIGO RSGU03


- Establecer y mantener un sistema gestión de configuración y gestión de cambios para controlar los documentos de trabajo.

- Crear o publicar los lineamientos bases para uso interno y para entrega a los clientes.

- Realizar seguimiento sobre los cambios en los ítems de configuración.

- Controlar los cambios en los ítems de configuración.- Establecer y mantener registros de los ítems de configuración. - Realizar auditorías para mantener la integridad de los lineamientos

de configuración.

6.2Control de la unidad

Las métricas que reflejan el rendimiento de la Gestión de Aplicaciones dependen de las aplicaciones que se estén gestionando, pero las más típicas son:

Métricas de los entregables acordados. Esto puede incluir: o Capacidad de los usuarios para acceder a la aplicación y sus

funcionalidades.o Reportes y archivos enviados a los usuarios.o Porcentajes de éxito y disponibilidad para determinadas

transacciones críticas para el negocio.o Formación del Centro de Servicios.o Registro de resolución de problemas en el sistema de Gestión del

Conocimiento.o Percepción que los usuarios tienen de la calidad, en comparación

con los requisitos definidos en los SLAs.

6.3Puesta en marcha

Uno de las principales dificultades para la correcta puesta en marcha de la fase de Operación del Servicio reside en el “abismo” existente entre teoría y práctica.

Las fases previas del ciclo de vida de los servicios se han preocupado de diseñar, planificar y desplegar una serie de procesos y servicios que ahora han de ponerse en marcha y es frecuente eso conlleve las habituales dificultades:

Los responsables del diseño no conocen en detalle las complicaciones asociadas a las labores de mantenimiento y tareas recurrentes de la fase de operación con las consiguientes consecuencias indeseables:

o Se toman “atajos” que rompen con las buenas prácticas de gestión.o Se crean resistencias a la aplicación de los protocolos diseñados.

6

http://itilv3.osiatis.es/operacion_servicios_TI/centro_servicios.php

PROCESO


CÓDIGO RSGU03


No se han asignado los recursos necesarios para implementar correctamente la fase de operación y el personal la percibe como una nueva capa “burocrática” que sólo dificulta su trabajo.

Las estructuras de gestión no son lo suficientemente flexibles y por tanto no son capaces de asimilar la complejidad de los nuevos procesos y actividades.

Las métricas definidas se centran en exceso en aspectos “internos” de la organización TI y obvian importantes aspectos “externos” relativos a la percepción de los clientes.

Para impedir que todo esto ocurra es imprescindible:

Involucrar al personal de operación en el diseño de los servicios. Asegurarse una rápida evaluación del impacto de todos los cambios en la

fase de operación. Que el personal a cargo de la fase de operación disponga desde el primer

momento de todas las herramientas y tecnología necesarias para desempeñar correctamente su función según los protocolos preestablecidos.

7. Consideraciones en el desarrollo de aplicaciones

7.1 Estructura básica documental por proyecto en SharePoint

El SharePoint Server será el sistema de información para la administración documental del proyecto, en donde se alojan todos los formatos y documentos establecidos por la metodología. Se maneja el mismo marco de seguridad a TFS donde el acceso se concede solo las personas involucradas por proyecto pueden acceder a los contenidos y a la colaboración de proyectos por medio de asignación de permisos a usuarios registrados en el directorio activo de la Supersalud.La estructura base de directorios por proyecto será la siguiente:

- [NombreProyecto] Actas Manuales Pruebas Requerimientos Anexos Soporte

7

PROCESO


CÓDIGO RSGU03


7.2 Estructura básica de soluciones en el Team Foundation Server

El Team Foundation Server será el sistema de información sobre el cual se gestionará el proyecto, bajo la plantilla Scrum se gestionaran las capacidades, tiempos, requerimientos, desarrollo y pruebas, así como el control de versiones y código fuente, todo esto bajo un marco de seguridad de acceso donde solo las personas involucradas por proyecto pueden acceder a los contenidos y a la colaboración de proyectos por medio de asignación de permisos a usuarios registrados en el directorio activo de la Supersalud.

La estructura basica de soluciones será la siguiente:

- Solución- DataBase

- Scripts- Installers- Libraries- Reports- Services- WebProjects- WebServices

8. DEFINICIÓN DE REQUERIMIENTOS

A partir de los requerimientos generados por el grupo de arquitectura y el análisis realizado por el grupo de aplicaciones se determinarán que tipo de artefactos son requeridos para especificar a bajo nivel las actividades necesarias para el desarrollo o mantenimiento de aplicaciones, dentro de las cuales se plantean dos alternativas de especificaciones que corresponden a historias de usuario y/o casos de uso, sin embargo se considera también que en algunos casos específicos estos artefactos pueden ser complementados por otro tipo de diagrama o plantilla que especifique de manera clara y entendible para los interesados la funcionalidad requerida.

HISTORIA DE USUARIOID <Consecutivo identificación Historia>

Historia<Descripción historia de usuario>

Complejidad<Baja, Media, Alta >

Prioridad<Baja, Media, Alta>

Criterio de Aceptación:<Se describen de manera detallada las condiciones necesarias tanto funcionales como no funcionales para el cumplimiento de la historia, un ejemplo de estos son criterios de seguridad y de rendimiento que no se observan inicialmente en la descripción de la historia.>

8

PROCESO


CÓDIGO RSGU03


CASO DE USOID<Id_Historia>_<Consecutivo>

Nombre:<Nombre Caso de Uso>

Categoría:<Categoría del caso de uso>

Complejidad:<Baja, Media, Alta >

Prioridad:<Baja, Media, Alta >

Objetivo:<Descripción del resultado esperado para el caso de uso >Precondiciones<Lista de precondiciones necesarias, para ejecutar el caso de uso>Flujo de trabajo:<Ejecución normal y exitosa del caso de uso>Validaciones:<Validaciones requeridas dentro del flujo de trabajo>Excepciones:<Definición de flujos de trabajo no esperados que deben manejarse>

PERFILES DE USUARIOID <Consecutivo>

Nombre<Nombre del rol >

Permisos:<Descripción de los permisos requeridos por rol y/o funcionalidad asociada al rol>

9. DISEÑO

DISEÑO DE DATOSCriterios Generales:Se debe describir de qué manera los datos serán gestionados y manipuladosObjetos de datos:Se deben describir los principales objetos de datos y sus principales atributos para tener una visión global del modelo.Relaciones:Las principales relaciones de los objetos de datos deben ser descritas al nivel de detalle necesario para iniciar y desarrollar la construcción del software.Modelo de datos:El modelo Entidad Relación al ser un documento técnico detallado deber ser referenciado en esta sección para tener visibilidad del mismo, la creación y mantenimiento del mismo se realiza por el equipo especializado.

DISEÑO FUNCIONALDescripción interfaces:Se describe el conjunto de interfaces con las cuales el sistema va a interactuar tanto de entrada como de salida.Interfaces de entrada:Se especifica todo el conjunto de interfaces que van a proveer información requerida para el funcionamiento del sistema, tales como archivos, Web Services, Accesos a Bases de datos externas, sistemas, redes etc.Interface de salida:Se especifica todo el conjunto de interfaces que se van a generar en el sistema para proveer información a componentes externos, ya sean Archivos, Servicios, reportes etc.

9

PROCESO


CÓDIGO RSGU03


Interfaces de usuario:Se presenta una visión general de las interfaces para el usuario dentro del software, se referencian los lineamientos generales para la implementación de interfaces de usuario.

DESEMPEÑO Criterios:Se describen los criterios y expectativas de desempeño de la aplicación.

LIMITACIONES Se define el conjunto de limitaciones y restricciones conocidas por parte del sistema o ya sean de carácter funcional o no funcional.

10.CONSTRUCCIÓN

10.1 Definición de Ambientes:

AMBIENTE Tipo de Ambiente: ☐ Desarrollo ☐ Pruebas ☐ ProducciónNombre Servidor: Ip:

Descripción: <Tipo de servidor: Aplicaciones, Base de Datos, File Server, FTP Server, Etc.>

Sistema Operativo: CPU: RAM:

Espacio en Disco: Usuarios administradores:

Software requerido:

Backup/Restauración:

Comentarios:

10.2 Buenas Practicas y lineamientos de desarrollo

Se adoptarán los lineamientos y buenas practicas sugeridas por Microsoft para el desarrollo seguro entendiendo que el estándar actual es tecnología .NET:Referencias:

.NET Framework Development Guide disponible en: https://msdn.microsoft.com/en-us/library/hh156542(v=vs.110).aspxC# Programming Guide disponible en: https://msdn.microsoft.com/en-us/library/67ef8sbd.aspxPatterns & practices disponible en: https://msdn.microsoft.com/en-us/library/ff921345.aspx

11.ASEGURAMIENTO DE CALIDAD (QA)

10

https://msdn.microsoft.com/en-us/library/ff921345.aspx

https://msdn.microsoft.com/en-us/library/67ef8sbd.aspx

https://msdn.microsoft.com/en-us/library/hh156542(v=vs.110).aspx

PROCESO


CÓDIGO RSGU03


Se describe el alcance de las pruebas a realizarse durante el ciclo de vida del software, este alcance se basa en las especificaciones de diseño y en los requerimientos.

PLAN DE PRUEBASId Características sujetas a calidad (Funcionalidad) Riesgo Avance1 ☒ <Autenticación de usuario y contraseña> A 0%2 ☐ 0%

FORMATO ASEGURAMIENTO DE CALIDADProyecto:<Nombre Proyecto>

Fecha creación:<dd/mm/aaaa>

Escenario:<Nombre del componente, proceso, escenario o característica>

Prueba No:<Consecutivo >

Tipo de Prueba:☐Prueba Unitaria☐Prueba de Integración☒Prueba de Aceptación

☐Prueba de Regresión☐Prueba de Sistema☐Prueba de Rendimiento

☐Prueba de Humo☐Prueba de Seguridad☐Prueba de Migración

Prioridad:☐Alta☐Media☐Baja

Resultado:☒Pendiente☐OK☐Fallido

Ambiente de pruebas:<Descripción del ambiente donde se realizó la prueba>

Versión:<Versión del sistema sujeto a la prueba>

Precondiciones:<Describir de manera corta y clara las precondiciones para la prueba>Dependencias:<Dependencias asociadas a la prueba >Consideraciones técnicas:<Describir los requisitos técnicos para realizar la prueba, acceso a DB, permisos, etc>Pasosid Descripción Datos Resultado

esperadoResultado

actualEstado

(OK/Fallido)

PostCondiciones:<>Evidencia:<La evidencia hace referencia al estado de los datos, imágenes o documentación que permita verificar el éxito de las pruebas realizadas>Observaciones:<>Responsable prueba:<>

Fecha de ejecución:<>

11

PROCESO


CÓDIGO RSGU03


12. IMPLANTACIÓN

FORMATO APROBACIÓN DEL SISTEMA Y PASO A PRODUCCIÓNFecha: Proyecto:

Fecha de Instalación: Motivo:☐ Nueva instalación ☐ Mejora ☐ Solución de Errores

Responsable Grupo de Aplicaciones:

Responsable Pruebas de aceptación:

Responsable Instalación:

Descripción de la solución implementada:

Comentarios:

Artefactos instalaciónNombre Versión CheckSum/

TamañoDestino PERMISOS

Prerrequisitos instalación:

InstalaciónConsideraciones de la instalación:

Procedimiento de instalación:<Paso1, paso 2 …>Aceptación de Pruebas☐Prueba Unitaria☐Prueba de Integración☐Prueba de Aceptación

☐Prueba de Regresión☐Prueba de Sistema☐Prueba de Rendimiento

☐Prueba de Humo☐Prueba de Seguridad☐Prueba de Migración

Documentación Soporte☐Plan de pruebas☐ Formatos Calidad (QA) ☐Plan de Migración

☐ Manual de Usuario☐ Manual de administrador☐ Manual de soporte

☐ Aceptación de código fuente☐ Aceptación de Seguridad☐ Capacitaciones

Los usuarios de las áreas abajo firmantes Aceptamos que el Software relacionado en el presente documento fue desarrollado y probado de acuerdo con los términos planteados en este informe y aprobamos su puesta en producción. Con base en lo anterior, solicitamos el despliegue de la solución en producción.

Nombre y Cargo Firma ObservacionesResponsable área solicitante

Responsable grupo de aplicaciones

Responsable

12

PROCESO


CÓDIGO RSGU03


Pruebas de aceptación

Responsable Instalación

Jefe Oficina de Tecnologías de la información

13.SOPORTE Y MANTENIMIENTO

ACEPTACIÓN DE CÓDIGO FUENTEProyecto:<Nombre Proyecto>

Fecha:<dd/mm/aaaa>

Ubicación Código Fuente:< Servidor/carpeta proyecto/documentos/…> Información SistemaPlataforma desarrollo:<.Net / Java / Php /…>

Lenguajes de programación:<c#,c++,F#, java,php/…>

Código FuenteDescripción de la estructura del repositorio:< Indicar la estructura de carpetas en el repositorio y el contenido de cada una de ellas ej:- modelo: Carpeta con clases que representan el modelo de negocio - Predios: Carpeta con los modelos específicos de la gestión de predios - Compensación: Clases proxy que se conectan con el sistema de compensaciones - Unidades Sociales: Clases que almacenan y gestionan la información de las unidades sociales- vista: Carpetas que almacena la descripción de los formularios a ser desplegados - Aplicación 1: Formularios de gestión de Aplicacion1 - Formulario2: Formularios de validación de datos de Formulario2 - Formulario3: Vistas para el ingreso de Formulario3- documentos: Archivos de documentación de la administración del sistema >VerificacionesUbicación documentos aseguramiento de calidad:< Servidor/carpeta proyecto/documentos/Pruebas…>☐ El código entregado compila.☐ Se tienen las instrucciones de como compilar el código.☐ Se ejecutaron satisfactoriamente las pruebas descritas en el documento plan de pruebas.☐ Se tienen documentación de versiones (Changelog).Versión entregada:<Número de versión, Commit, Changeset o referencia a la versión>Estándar de Codificación:<Nombre y referencia documental a la codificación utilizada>☐ Cumple con el estándar de codificación Observaciones:

13

PROCESO


CÓDIGO RSGU03


Licenciamiento ☐ Cuenta con licencia de usoTipo de Licencia:< Creative Commons v5, GPL versión 3, etc…>Ubicación Licencia:< Servidor/carpeta proyecto/documentos/Licencia/readme.txt>

ACEPTACIÓN DE MANUALESProyecto:<Nombre Proyecto>

Fecha:<dd/mm/aaaa>

Ubicación Manuales:<Ruta acceso : \\sm01cc23\Manuales - docs./oti/proyecto > Manual de Usuario Descripción:<Descripción y objetivo del manual del usuario>Tabla de Contenido:<Tabla de contenido del manual>Verificaciones☐ Responde a todos los escenarios de uso descritos en documento de requerimientos.☐ Contiene material instructivo evidencia de los escenarios.Observaciones:

Manual de Administrador Descripción:<Descripción general del contenido de los manuales de administrador. El manual del administrador contiene la información necesaria para que un usuario con rol de administrador del área que lidera la aplicación, pueda atender las necesidades >Tabla de Contenido:<Tabla de contenido del manual>Verificaciones☐ Responde a todos los escenarios de uso descritos en documento de requerimientos.☐ Contiene material instructivo evidencia de los escenarios.Observaciones:

Manual de Soporte Descripción:<Descripción general del contenido de los manuales de soporte. Este es un documento que detalla las características técnicas y de operación que debe conocer la mesa de servicios, para poder brindar el soporte de primer nivel a los usuarios de la >Tabla de Contenido:<Tabla de contenido del manual>Verificaciones☐ Indica los procedimientos de mantenimiento y actualización del sistema.

14

PROCESO


CÓDIGO RSGU03


☐ Indica los procedimientos de instalación y backup del sistema.☐ Indica los procedimientos de Gestión de acceso y Seguridad. Observaciones:

14.Relación de actividades para la Gestión de desarrollos:

No. Actividad Descripción Responsable Registro1 Opciones de

Alternativas de Solución

El dueño del proceso, el coordinador del proceso y el equipo de arquitectura, deben contemplar si existe una solución basada total o parcialmente en un producto existente en el mercado, si requiere un desarrollo a la medida, soluciones mixtas, si requiere un modelo de procesos y/o un modelo de negocio o una modificación a realizar por el proveedor de la solución.Se debe analizar qué requisitos y necesidades cumplen, si requieren o no infraestructura adicional, cobertura, licenciamiento, costo, presupuesto, adaptabilidad, escalabilidad y portabilidad, modelo de base de datos e interacción con otros sistemas.

El dueño del proceso

Profesional del proceso gestión de aplicaciones

Profesional equipo de arquitectura

2 Valoración y selección de alternativa

Con las opciones de Alternativas de Solución el Dueño del proceso, el coordinador del Proceso y el equipo de trabajo requerido junto con el equipo de arquitectura, realizan una valorización de las mismas, teniendo en cuenta el impacto en la entidad, desde el punto de vista tecnológico, organizativo y




Línea Base de Arquitectura de T.I. - Cód. RSFT01.

15

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable Registrode operación. Es importante reforzar el estudio de los riesgos realizados en el proceso “Detallar Requerimientos Acuerdos de Desarrollo", para cuantificar recursos y plazos en un plan de acción o plan de trabajo para cada alternativa. Evalúan los siguientes temas por cada alternativa: Descripción de la solución, Contexto e interacción con otros sistemas, Impacto, relación costo/beneficio, Valoración de riesgos, casos de uso, modelo Base de datos, procesos, interfaces, seguridad, migración de datos, conversión de datos, contingencia, y Se Obtiene el documento Línea Base de Arquitectura de T.I. - Cód. RSFT01.

3 Elaborar Diseño El coordinador del Proceso y el equipo de trabajo requerido junto con el equipo de arquitectura, con base en el documento Línea Base de Arquitectura de T.I. - Cód. RSFT01, se elaboran el diseño del sistema, según sea aplicable y requerido: Las especificaciones de arquitectura detalladas a nivel de bloques de solución de arquitectura; detallan requerimientos, acuerdos de desarrollo, define la arquitectura destino del sistema, casos de uso reales, clases, módulos del sistema, modelo y migración de datos, Especificaciones de prueba, requisitos de implantación, documentación, manuales, capacitación y cronograma inicial, ajustado a cada caso.




Elaboración según sea aplicable los formatos del capítulo Definición de requerimientos de esta guia.

Creación de proyecto en Team Foundation Server, a partir de la plantilla Scrum y revisión por parte del Profesional del proceso gestión de aplicaciones (Product Owner) y el equipo de trabajo

16

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable RegistroToda la anterior información debe estar incluida en detalle en la documentación del proyecto ubicada en el sitio de proyecto creado en el SharePoint

Creación de la biblioteca documental en el SharePoint según capitulo consideraciones en el desarrollo de aplicaciones de esta guía.

4 Aprobar Diseño El jefe de la oficina de TI, El Jefe del área solicitante, el líder funcional del área solicitante y el dueño del proceso aprueban la documentación del proyecto, previo visto bueno del coordinador del proceso y el equipo de trabajo requerido.




Revisión del Product Backlog entre el Product Owner y el equipo de trabajo, y se genera acata en sistema ITS

5 Preparación de ambientes

El coordinador del proceso es el responsable de asegurar un correcto y adecuado entorno y ambiente de trabajo para el desarrollo y pruebas del software, acorde con módulos, bases de datos requeridos, y otras dependencias de las aplicaciones.



Profesional equipo de

arquitectura

Elaboración según sea aplicable los formatos del capítulo Construcción de esta guía.

Creación de la solución en el Team Foundation Server según capitulo consideraciones en el desarrollo de aplicaciones de esta guía.

6 Desarrollo de Software

El coordinador del proceso y el equipo de trabajo requerido, se aseguran que el sistema sea desarrollado (por el proveedor o proveedores de software, o programadores específicos o programadores internos), de acuerdo al diseño aprobado y del desarrollo de procedimientos de operación y/o de seguridad del módulo o módulos en caso de que se requieran y la relación de paralelo de las pruebas



Revisión del Product Backlog en el proyecto en Team Foundation Server.

17

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable Registrorequeridas para facilitar un desarrollo incremental e iterativos de la solución.

7 Monitoreo y control de proyectos

El propósito de monitoreo y control de proyectos es proveer un entendimiento del avance del proyecto a fin de que las acciones correctivas sean tomadas en el momento cuando el proyecto se desvié significativamente del plan.

El coordinador del proceso y el equipo de trabajo deben monitorear el estado actual del proyecto contra el plan establecido, el progreso del proyecto, rendimientos e incidentes, los riesgos del proyecto, la gestión de la información, a través Sesiones de Scrum para evaluar avance de ítems de trabajo y estimar esfuerzo restante.



Diligenciamiento del Product Backlog en el proyecto en Team Foundation Server.

Documentos generados en SharePoint.

8 Diseño de Plan de Pruebas

El equipo de trabajo requerido y los programadores, son los responsables del diligenciamiento de los formatos de Aseguramiento de calidad (Capitulo Aseguramiento de calidad (QA) de esta guia), cuyo objetivo es la interacción y correcta funcionalidad de los módulos, componentes o subsistemas, según la documentación del proyecto.



Elaboración según sea aplicable los formatos definidos en el capítulo Aseguramiento de calidad (QA) de esta guía.

9

Realización de pruebas y aseguramiento de Calidad

El coordinador de proceso, asegura la competencia de equipo requerido para la realización de las pruebas. Cada inicio de una nueva prueba, debe verificar la totalidad de acciones o actividades descritas en los formatos de Aseguramiento de calidad (capitulo Aseguramiento



Diligenciar los formatos definidos en el capítulo Aseguramiento de calidad (QA) de esta guía.

18

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable Registrode calidad (QA) de esta guía).

Conforme el avance del proceso de desarrollo del proyecto se deben considerar los siguientes tipos de pruebas los cuales aportaran de manera incremental al aseguramiento de calidad del producto.

Pruebas unitarias: Las pruebas unitarias son definidas para comprobar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado, en esta sección se definen los módulos o funcionalidades sobre los cuales se deben realizar pruebas unitarias, estos componentes o funcionalidades debe relacionarse en el formato de pruebas unitarias.

Pruebas de integración: Las pruebas de integración se definen como las pruebas para evaluar un proceso compuesto por varios componentes o funcionalidades y se deben relacionar con el formato de pruebas de integración.

Pruebas de aceptación: Los test de aceptación son aquellos destinados a determinar si los requisitos de cierta funcionalidad han sido cumplidos, como usuarios finales, no tienen por qué preocuparse por los detalles de la implementación, sino que

19

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable Registrodeberían poder centrarse más en que la parte funcional cumple las expectativas creadas al inicio del Sprint.

Pruebas de regresión: Se definen el conjunto de pruebas necesarias para validar que ante eventuales cambios en el software, como parches, ajuste en datos, cambios en la configuración, interfaces, orígenes de datos etc. Las características del software se comporten de manera correcta.

Pruebas de rendimiento: Se definen el conjunto de pruebas asociadas al rendimiento del software y los mecanismos por los cuales se realizarán estas pruebas.

Pruebas de seguridad: Se definen el conjunto de pruebas asociadas a la seguridad del software y los mecanismos por los cuales se realizarán estas pruebas.

Los registros y la evidencia de todas las pruebas definidas en el plan de pruebas deben quedar alojadas en los documentos de proyecto dentro del respectivo sitio creado en el SharePoint.

10 Evaluación resultado pruebas del Sistema

El coordinador del proceso, el equipo de trabajo y el líder funcional, son los responsables de la evaluación del resultado de las pruebas del Sistema. Esta evaluación debe comprender: - Comparación de resultados



Incidencias registradas en el Proyecto del Team Foundation Server para su seguimiento

20

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable Registroobtenidos VS los resultados esperados.- Identificar origen de cada problema detectado y remitirlo al personal indicado- Determinar la complejidad de las modificaciones a realizar y plan de acción para su solución satisfactoria.- Indicar forma de continuar con las pruebas del Sistema, total o parcial y la utilización del Plan de pruebas o la necesidad de modificarlo. Generar un informe de resultados de pruebas de Sistema.

Si las Pruebas realizadas no satisfacen los resultados esperados, se deben crear las correspondientes incidencias para su seguimiento y trazabilidad, se debe continuar con el paso 6 de esta guía hasta obtener los resultados esperados en las actividades de pruebas y aseguramiento de calidad.

11 Elaboración de manuales

El coordinador del Proceso es el responsable por el diseño, preparación y aprobación de la documentación de usuario (Elaborada por los programadores y desarrolladores, del proveedor o contratistas o funcionarios de la entidad, involucrados en el desarrollo de la solución). Se obtiene Manual de usuario, manual de soporte y Manual de administrador.



Elaboración según sea aplicable los formatos definidos en el capítulo Soporte y mantenimiento de esta guía.

12 Elaboración Plan de Migración de

El dueño del Proceso el coordinador de proceso y su equipo son los responsables de


Profesional del


21

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable Registro

datos la planeación y ejecución de Migración de Datos, En caso de que aplique esta actividad.Los documentos generados deben quedar alojados en los documentos de proyecto dentro del respectivo sitio creado en el SharePoint.En caso de que no aplique pasar a la actividad 15.

proceso gestión de aplicaciones

13 Realizar Pruebas de Migración

El coordinador del Proceso asegura la realización de esta actividad, ejecutada por el equipo de trabajo requerido, demás funcionarios que estime convenientes. Se debe verificar la consistencia de la base de datos resultante y la consistencia y confiabilidad, disponibilidad e integridad de la información resultante.



Diligenciar los formatos formatos definidos en el capítulo Aseguramiento de calidad (QA)

14 Evaluación Pruebas de Migración

El Líder funcional y el equipo de trabajo que se estime conveniente debe asegurar la calidad de los datos y la información resultante de la migración, su confiabilidad, integridad y disponibilidad. Esta evaluación debe contemplar: - Comparación de resultados obtenidos VS los resultados esperados.- Identificar origen de cada problema detectado y remitirlo al personal indicado- Determinar la complejidad de las modificaciones a realizar y plan de acción para su solución satisfactoria.- Indicar forma de continuar con las pruebas del Sistema, total o




22

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable Registroparcialmente.

Si las Pruebas realizadas no satisfacen los resultados esperados, se deben crear las correspondientes incidencias para su seguimiento y trazabilidad, se debe continuar con la actividad 11 o a la actividad 6 de esta guía según los resultados obtenidos. hasta obtener los resultados esperados.

15 Capacitación a usuarios

El coordinador del proceso y el equipo de trabajo, son los responsables de la obtención de las necesidades de capacitación del usuario final, según las características funcionales del sistema y accesibilidad de los mismos planteados en la documentación. Se debe planear, programar y ejecutar la capacitación y debe ser aprobada por el Jefe del área Solicitante del requerimiento.



Listados de asistencia ASFT04

16 Presentación para Aprobación del sistema

El coordinador del proceso, debe recopilar y obtener toda la información relacionada y utilizada en este proceso, para presentar a las partes interesadas y Obtener la aprobación respectiva para realizar el proceso de Implantación del S.I. La información requerida es: Estudio Situación ActualEstudio de Viabilidad, Lista de requerimientos aprobados, Plan de trabajo de la soluciónAprobación diseño (opcional), Aprobación Plan de pruebas, Aprobación Pruebas



Jefe de la oficina de tecnologías de la información

Diligenciar formatos definidos en el capítulo Implantación

23

PROCESO


CÓDIGO RSGU03


No. Actividad Descripción Responsable RegistroAprobación solución final por parte de usuario Elaboración manuales, Plan de capacitación, Plan de implantación, Plan de Migración. Recepción y validación de código fuente y software y catalogación archivo del mismo.

Referencias Bibliográficas:

ICONTEC, (2013). Norma Técnica NTC-ISO-IEC Colombiana 27001,

Bogotá- Colombia.

ICONTEC, (2009). Norma Técnica De Calidad en la Gestión Pública NTCGP

1000:2009, Bogotá- Colombia.

THE OPEN GROUP. (2011). TOGAF® Versión 9.1, U.S, código PSDE01

THE OPEN GROUP. (2013. Guía de bolsillo TOGAF® Versión 9.1, U.S,

código PSDE02.

CMMI for Development Quick Reference CMMI-DEV v1.3, Nov. 2010

Secure Software Development Life Cycle Processes: A Technology Scouting

Report Noopur Davis - Diciembre 2005

The Scrum Guide™ Ken Schwaber and Jeff Sutherland – Julio 2013

CONTROL DE CAMBIÓSASPECTOS

QUE CAMBIARON

EL DOCUMENTO

DETALLES DE LOS CAMBIOS

EFECTUADOS

RESPONSABLE DE LA

SOLICITUD DEL CAMBIO

FECHA DEL

CAMBIO

VERSIÓN

Adopción del documento

Mediante NURC se aprobó el presente

Jefe Oficina de Tecnologías de

06/08/2015 1

24

PROCESO


CÓDIGO RSGU03


documentos con número 3-2015-015540.. la Información

Actividades

Se incluyó nueva metodología de trabajo denominada SCRUM, se definieron espacios de publicación para el manejo de registros del procedimiento, se modificaron acciones tendientes a la instalación de ambientes de desarrollo, pruebas y producción, se modificaron acciones de mantenimiento para los sistemas de información, se eliminaron actividades debido a los nuevos ajustes realizados en la secuencia lógica del proceso, mediante requerimiento NURC: 3-2016-019052

Aprobación NURC3-2016-019443

Jefe Oficina de Tecnologías de la Información

14/10/2016 2

25

Guía Gestión de Desarrollo - Supersalud · Web viewPruebas de aceptación: Los test de...

Documents

Transcript of Guía Gestión de Desarrollo - Supersalud · Web viewPruebas de aceptación: Los test de...