WIXLIB

El flujo de trabajo que conlleva el modelo conceptual de la estrategia de desarrollo de softwareconsidera las siguientes fases:132ESTABLECIMIENTO DEREQUERIMIENTOSDESARROLLO DEL SOFTWARE4VALIDACIONES PRUEBASIMPLENTACION EN PRODUCCIONFigura No. 3 Flujo de trabajoESPECIFICACIÓN FUNCIONAL Y NO FUNCIONALLos Usuarios Expertos / Contraparte Técnico establecen las necesidades o requerimientos delsoftware a desarrollarse, para lo cual, en función de reuniones de trabajo, se discuten ydesarrollan los documentos en el siguiente orden: Documento de Visión. Documento que tiene como finalidad establecer el propósito yalcance del módulo/sistema/subsistema a desarrollar, detallando para ello lasoportunidades del negocio a solventar, definición del problema, costos y licenciamientoentre otros. Dicho documento permite identificar a la alta gerencia sobre los beneficios aobtener del desarrollo de la herramienta tecnológica. Casos de Uso: Documento que describe a nivel granular los actores involucrados queinteractuarán con la funcionalidad/opción/proceso descrito en el presente documento,el flujo de trabajo, los campos o atributos que deben almacenarse, pantallas requeridas,reportes, reglas de negocio, subflujos, etc. Lo anterior con el objetivo que dichodocumento sirva de guía al programador y minimice la brecha de la expectativa delusuario final con respecto a la necesidad planteada. Ya que será validada la funcionalidaddesarrollada con el presente documento.Con la finalidad de apoyar a los usuarios expertos a desarrollar los Casos de Uso y Documentode Visión con el necesario detalle y formato esperado, se destina a personal IT Analista deNegocio, quien tiene la misión de guiar y validar el trabajo desarrollado por los usuarios expertos.Ya que en caso de no cumplir con el detalle esperado en dichos documentos el(los) usuario(s)experto(s) deben corregir y/o ampliar las necesidades descritas, para alcanzar el nivel deespecificación necesario para la construcción del software.Adicional a las especificaciones funcionales, se solicita un documento de especificaciones nofuncionales que sigue la plantilla de FURPS en donde se plasma aspectos de seguridad, W3C,marco de trabajo para el desarrollo, componentes del marco, compatibilidad, adherencia apolíticas, entre otros aspectos.7 ESTRATEGIA DE DESARROLLO DE SOFTWAREUSAID.GOV

DESARROLLO DE SOFTWARECon los documentos debidamente validados por el IT Analista de Negocio en la fase EspecificaciónFuncional y no Funcional, se designa un Arquitecto de la Solución el cual a partir de los Casos deUso establece el Diseño de la Solución, creando el Modelo Entidad Relación (Estructuras de basede datos) que almacenarán la información necesaria, a partir de ello se inicia el desarrollo delsoftware per se, utilizando para ello herramienta de generación de código automatizado cuyafinalidad es agilizar el trabajo a realizar, asegurar la aplicación de estándares, pantallastransaccionales, clases, capas de software, etc. reduciendo el tiempo de trabajo de losprogramadores y el riesgo de errores en su construcción, ya que la herramienta de generaciónutiliza un conjunto de convenciones, estándares y buenas prácticas definidas por el mercado detecnología para la creación de los componentes de software.PROCESO DE GENERACIÓN DE SOFTWARESe utiliza esta técnica informática dentro de la estrategia de desarrollo de software y que operaen marcos de trabajo Modelo-Vista-Controlador como el que está estipulado en los proyectosque se desarrollan en el Ministerio de Hacienda.La técnica de generación de código, haciendo uso de plantillas estáticas crean fragmentos decódigo (header, footer, POM, etc) que tienden a no cambiar y que se incrustan en algunos casosdentro de codificación más complejas que son implementadas por las plantillas dinámicas(responsables de crear la vista, servicios y persistencia), entre ambas se realizan convergenciaspara ir construyendo clases java, jsp, javascript, xml, archivos de configuración o cualquier otrocomponente necesario de un proyecto de esta naturaleza y todo se hace a partir de unaconexión a base de datos. El proceso identifica las entidades en la base de datos y a partir de ahíse generan automáticamente los CRUD dinámicamente para cada entidad en la base de datos. Lacreación del proyecto se organiza y separa en carpetas que previamente se han convenido parauna mejor sostenibilidad del software.Para mayor legibilidad del código se utilizan una serie de tags que encapsulan la complejidad delcódigo, no solo desde el punto de vista funcional, sino desde la parte visual. La única capa endonde se realiza programación de lógica de negocios es en la capa del controlador, a nivel de lacapa visual se realizan solo validaciones de entrada de datos, esto implica que el programadordesarrolla un software muy estandarizado, legible, escalable.PROCESO INCREMENTAL E INTERACTIVOEl desarrollo incremental e iterativo es una de las estrategias que mejor se acoplan a losdesarrollos informáticos que se tienen definidos realizar en el Ministerio de Hacienda, endonde la especificación funcional se captura mediante Casos de Uso y son los que dirigen eldesarrollo. La idea es que cada iteración tome un conjunto de Casos de Uso y transite el flujodefinido en cada una de las iteraciones relacionadas a la codificación: análisis, diseño,implementación, prueba y despliegue.Hay una parte arquitectónica que se desarrolla entre la fase del requerimiento y el análisis ydiseño que se ha incorporado como parte de nuestra estrategia. En esta etapa se acompaña a8 ESTRATEGIA DE DESARROLLO DE SOFTWAREUSAID.GOV

las áreas de programación con apoyo arquitectónico con el objetivo de asegurar elacoplamiento de cada una de las opciones a desarrollar, puesto que al inicio del desarrollo seha construido el núcleo de la solución de software y muchos de los Casos de Uso estaránpreviamente modelados y deberá en estos solo reflejarse la lógica de negocio y no todo elciclo del análisis y diseño.A diferencia de otros ambientes en donde se utiliza este mismo esquema de manera completa,en DRM las áreas de programación utilizan parcialmente algunas de ellas pues parte de lo queen ella se espera ya tiene algún tipo de desarrollo.PlanificaciónPlanificación inicialEvaluaciónRequerimientosConfiguración &Gestión del CambioApoyo ArquitectónicoAnálisis y ura No. 4 Desarrollo IterativoÁMBITO DEL DESARROLLOCon los componentes de software generados de forma automática, los programadores inicianlos ajustes por las funcionalidades ad hoc en función de las necesidades descritas en los Casosde Uso, para ello y con la finalidad de controlar los cambios realizados en el proyecto desoftware utiliza los siguientes subsistemas y/o componentes como herramientas de apoyo: Software de Control de Versiones: centraliza el código fuente de la solución que seencuentra en desarrollo, permitiendo identificar en todos momentos los cambios quese han realizado, programadores involucrados y fechas de modificación. Ambiente de desarrollo: consiste en aquellos servidores de base de datos yaplicación que son utilizados como primer punto de validación del desarrollorealizado por los programadores, y en el cual estos últimos validan lasfuncionalidades en construcción. Sistema de automatización de pruebas: software que permite definir un conjuntode tareas que tienen como finalidad probar funcionalidades del softwaredesarrollado, de tal forma de reducir el riesgo de errores en el sistema enconstrucción.9 ESTRATEGIA DE DESARROLLO DE SOFTWAREUSAID.GOV

Integración continua: Dado el ambiente colaborativo en el cual se desarrollan loscomponentes, se utilizan herramienta de integración continua, para asegurar que lopersistido en el control de versiones, no de errores a priori, y permita laidentificación de problemas de forma proactiva.Herramienta de validación de uso de estándares de desarrollo: parasalvaguardar y certificar el uso de estándares de programación y buenas prácticas enel código fuente en desarrollo, se utiliza herramientas especializadas para validardicho fin, el cual tiene como insumo el código fuente y a partir de verificaciones dedicha herramienta provee reporte y notificaciones sobre hallazgos para correccióndebida por parte de los programadores.ASEGURAMIENTO DE CALIDAD Y PRUEBASUna vez se tiene una versión del sistema programado informáticamente a un nivel que describela necesidad esperada en los Casos de Uso, se procede a implementar dicho software en losservidores designados para pruebas de la solución, dicho ambiente es independiente de losservidores utilizados para la fase desarrollo. Sobre éste se ejecutan dos tipos de pruebas: Pruebas automatizadas: consiste en un conjunto de tareas de validación establecidasen la fase de desarrollo de tal forma de evitar implementar software que no cumpla connecesidades básicas de funcionalidad. Dichas pruebas son ejecutadas de formaautomática por herramienta de software al momento de implementar la solución en losambientes de pruebas, en el caso que alguna de dichas tareas de un error o resultado noesperado, la solución no se implementa en los servidores de pruebas y por consiguientenotifica a los desarrolladores del error encontrado, caso contrario la solución esimplementada de forma automática en los servidores de pruebas. Pruebas de Analistas de Negocios IT: Dado el conocimiento alcanzado en el proceso oárea de negocio por los Analistas de Negocios IT durante la fase Especiación Funcional yno Funcional, esta persona realiza validaciones sobre lo establecido en el Caso de Uso vslo desarrollado, de tal forma que en caso de existir incongruencias o brechas entre loespecificado y lo desarrollado procede a notificar al programador para su debidaresolución y/o en caso de no existir inconvenientes se procede al paso c). Pruebas de usuarios: consiste en aquellas actividades de validación realizadas por losusuarios finales sobre el software desarrollado en los ambientes de pruebas con lafinalidad de verificar el cumplimiento de la funcionalidad detallada en los casos de uso vsel componente de software producido. Pruebas de estrés: en este tipo de pruebas se utiliza sistemas especializados en emulardiferentes cantidades de conexiones y tareas sobre el software implementado, de talforma de validar el desempeño del hardware, aplicación, base de datos y cualquier otrocomponente relacionado de tal forma de validar los tiempos de respuesta ante altaconcurrencia de usuarios “virtuales”. A diferencia de las pruebas anteriores la presenteprueba se realiza sobre la plataforma tecnológica designada para el ambiente deproducción y es una prueba que debe coordinarse con cada uno de los encargados de losdiferentes componentes, servidores ,etc. involucrados, de tal forma que a través de10 ESTRATEGIA DE DESARROLLO DE SOFTWAREUSAID.GOV

software especializado de monitoreo de cada componente se puedan revisar métricassobre uso de los diferentes componentes para que en caso de existir fallas, o tiempos derespuesta inaceptables en función de las pruebas y las potenciales de ocurrencia de lasmismas en caso de implementarse, se provean los pasos a seguir para poder solventar losinconvenientes que puedan suscitarse. Este tipo de pruebas son cíclicas en función de lasacciones realizadas y sirven para validar los tiempos de respuestas aceptables yrequeridas por el negocio. Dada la naturaleza extrema de estas pruebas, se realizanúnicamente para nuevos componentes y se calendarice en horarios que minimizan elimpacto a otros subsistemas preexistentes en los ambientes ya productivos.Con el fin de ordenar los hallazgos en caso de existir inconvenientes o anormalidades en las pruebasrealizadas por los usuarios finales se utiliza herramienta de software para registrar dicho hallazgo y conello facilitar la gestión y tratamiento de dichos incidentes para asignación, seguimiento y resolución porparte de los programadores designados a dichas actividades. Una vez que el programador ha solucionadoo dado respuesta al incidente reportado se inicia el ciclo de pruebas para validar que se ha superado elincidente.IMPLEMENTACIÓN (AMBIENTE DE PRODUCCIÓN)Concluida la fase Aseguramiento de Calidad y Pruebas se realiza la generación del archivo WAR(Web Application Archive) y script de creación de estructuras de datos (en caso aplique) quedebe ser implementado en producción y el cual es trasladado al personal encargado de lacontraparte técnica de IT para que realice dicha implementación sobre el ambiente deproducción.ACTIVIDADES POST IMPLEMENTACIÓNUna vez la puesta en producción del software desarrollado se provee asesoría a la institución beneficiariasobre identificación/tunning de querys con mayor impacto para tratar de eficientizar los recursos informáticos,así como a los componentes de software creados.PILA TECNOLÓGICALa herramienta de generación de código más reciente cuenta con los siguientes componentes o da soportea los siguientes: 11 Java 7, 8Spring Framework MVC 4.1.6Jqgrid 5.0.1Jquery 2.1.1Bootstrap 3.3.5IO.Spring.platform 1.1.2Hibernate 4.3.8Spring Data JPA 1.7.2JSONLombok 1.16.10ESTRATEGIA DE DESARROLLO DE SOFTWAREUSAID.GOV

Spring Security 3.2.7PL/SQL ORACLE 11 y 12HTML 5JSP 2Jasper 5.6.0TRANSFERENCIA DE CONOCIMIENTOLos proyectos de tecnología impulsados durante DRM tienen el compromiso de asegurar latransferencia de conocimiento a las áreas beneficiadas, es en ese sentido que se imparten diversascapacitaciones como en la que se desarrollan las técnicas de ingeniería de requerimiento a las áreasfuncionales y de tecnología, así como capacitaciones en la pila tecnología a las áreas de tecnología.Es frecuente que se incorpore personal de tecnología al proyecto de desarrollo informático, con laintención que se realice el proceso de transferencia de conocimiento bajo la figura de aprenderhaciendo.En algunas oportunidades se realiza procesos de coaching a las áreas beneficiadas para que estas asumancomponentes de desarrollo de software.12 ESTRATEGIA DE DESARROLLO DE SOFTWAREUSAID.GOV

2 estrategia de desarrollo de software usaid.gov contenidos introducciÓn 3 definiciÓn del proyecto. 4 definiciÓn funcional 4 definiciÓn no funcional (furps ) 4 desarrollo del software 4 gestiÓn del proyecto - divisiÓn tecnologÍa 5 organizaciÓn capital humano 5 gestiÓn capital humano 6 gestiÓn desarrollo software 6