PA00XJVX

Vista previa del material en texto

DISCLAIMER <replace with the standard disclaimer, if required> Ibustibeate ratur aspelestia deliquia sitae etumquis sande ni nume nectur 
reped quat. Et enis in commo officat vollabo. Ut volorum sit excesto te venimax imoluptae nulpa quissit faceste non ped moloriate molorenit 
mo totat res eaquid minctatur ant laborporum. 
 
RESUMEN - ESTRATEGIA DE 
DESARROLLO DE SOFTWARE 
 
 
(DELETE THIS BLANK PAGE AFTER CREATING PDF. IT’S HERE TO MAKE FACING PAGES AND 
LEFT/RIGHT PAGE NUMBERS SEQUENCE CORRECTLY IN WORD. BE CAREFUL TO NOT DELETE 
THIS SECTION BREAK EITHER, UNTIL AFTER YOU HAVE GENERATED A FINAL PDF. IT WILL 
THROW OFF THE LEFT/RIGHT PAGE LAYOUT.)
1 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.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 
MODELO CONCEPTUAL 6 
ESPECIFICACIÓN FUNCIONAL Y NO FUNCIONAL 7 
DESARROLLO DE SOFTWARE 8 
PROCESO DE GENERACIÓN DE SOFTWARE 8 
PROCESO INCREMENTAL E INTERACTIVO 8 
ÁMBITO DEL DESARROLLO 9 
ASEGURAMIENTO DE CALIDAD Y PRUEBAS 10 
IMPLEMENTACIÓN (AMBIENTE DE PRODUCCIÓN) 11 
ACTIVIDADES POST IMPLEMENTACIÓN 11 
PILA TECNOLÓGICA 11 
TRANSFERENCIA DE CONOCIMIENTO 12 
 
 
 
 
 
 
 
 
 
 
 
3 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
INTRODUCCIÓN 
La asistencia técnica que brinda el Proyecto de USAID para la Gestión de las Finanzas Públicas – DRM, 
tiene definido su alcance mediante un instrumento contractual, y a partir de este, se identifican las áreas 
beneficiarias o áreas de acción en las cuales el proyecto desarrollará no solo componentes informáticos, 
sino de apoyo técnico. En este sentido, se identifican y priorizan las iniciativas en las que se estará 
brindando apoyo. 
Este documento presenta una visión general y resumida de la estrategia de desarrollo informático que 
implementa DRM en sus iniciativas de construcción de soluciones de software. Si bien es cierto a lo 
largo de este documento se mencionan varias especificaciones de estándares o mejores prácticas, el 
proyecto sólo recoge aquellas porciones que considera aportan valor a las iniciativas de desarrollo de 
software, no se asume un marco de trabajo de forma completa, sino que se toma aquello que se 
considera será más adecuado para el entorno en el que se desarrolla la asistencia técnica. 
Es posible, por ejemplo, que de la ISO 38500 solo se tomen algunos aspectos del gobierno de TI y no 
toda la especificación. 
De igual forma, con UML, no se utilizan todos los artefactos de la especificación, sino solo aquellos que 
se consideran oportunos para el escenario del proyecto en el Ministerio de Hacienda, debido a que la 
definición funcional de los sistemas, que son los artefactos que se adoptan del UML, corresponde al 
equipo contraparte y deben ser estos documentos de fácil utilización para el área funcional y para el 
área de programación. 
Por ejemplo, de RUP se toma la idea del desarrollo iterativo e incremental, así como también la 
elevación de la abstracción, la cual se logra mediante generación de código se abstrae de la construcción 
multicapa y se enfoca a los desarrolladores en las tareas de aplicación de reglas de negocio o de 
aspectos visuales. 
En otras palabras, las fases y componentes que forman parte de la estrategia de desarrollo tienen 
aplicabilidad en escenarios como el del Ministerio de Hacienda bajo proyectos como DRM, por las 
características del entorno, personal contraparte limitado, necesidad de acceder a tecnologías de punta y 
a estándares de desarrollo internacional. 
Es de hacer notar que esta es una estrategia probada que data del año 2005 y ha dado buenos 
resultados, coadyuvando a la construcción de soluciones tecnológicas exitosas. No obstante, con cierta 
periodicidad se evalúa si es necesaria una actualización o se deben incorporar nuevos estándares o 
componentes que demanda la industria del software y que han alcanzado madurez. La idea de esta 
revisión es evitar la obsolescencia tecnológica de las piezas de software que se construyen. 
Antes de entrar a la explicación del proceso, es necesario abordar algunas fases o etapas que se desarrollan 
en todo proyecto de DRM. 
 
 
4 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
DEFINICIÓN DEL PROYECTO. 
En esta fase se define alcance, las necesidades a nivel 0, es probable que exista un modelo conceptual, se 
especifica tiempo grosso modo, se realiza un adecuado manejo de expectativas, canales de 
comunicación, equipos contraparte y otros aspectos relevantes para el proyecto. En esta fase 
normalmente se define el qué, sin entrar en detalle en el cómo. 
Se define la coordinación entre las autoridades del Ministerio de Hacienda y DRM, con el objetivo de 
direccionar los recursos que estarán trabajando bajo el contexto del proyecto. Con la visión de 
garantizar que el esfuerzo tecnológico esté alineado con la estrategia de la entidad, además, los posibles 
riesgos vinculados inherentemente al desarrollo tecnológico no son solo conocidos, sino también 
administrados. 
En esta definición se identifican las personas que tienen interés o estarán vinculados de alguna forma en 
el resultado del proyecto, proceso o componente de software. Normalmente tienen características de 
conocimiento de negocio, tomadores de decisión o liderazgo. Además, deben ser investidas de la 
autoridad. 
Finalmente se definen los canales de comunicación válidos para el desarrollo del proyecto, proceso o 
componente de software. 
Algunos aspectos fundamentales que se definen en este apartado y que deben quedar claro: 
• Gobernanza (ISO/IEC 38500:2008). 
• Alcance, tiempo y calidad. 
• Interesados. 
• Establecimiento de canales de comunicación. 
DEFINICIÓN FUNCIONAL 
• Documento de visión 
• Procesos principales 
• Casos de Uso 
• Prototipos de pantallas 
• Diagrama de Casos de Uso 
DEFINICIÓN NO FUNCIONAL (FURPS+) 
• Especificaciones suplementarias 
• Estándar de desarrollo 
• Generación de código 
• Aseguramiento de calidad 
• Separación de Ambientes de desarrollo, pruebas, producción 
DESARROLLO DEL SOFTWARE 
• Actualización del plan detallado de Casos de Uso (Seguimiento SCRUM) 
5 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
• Análisis y diseño arquitectónico 
• Arquitectura de la solución 
• Desarrollo detallado de Casos de Uso 
• Pruebas Unitaria 
• Aseguramiento de calidad 
• Gestión de cambios 
• Pruebas integrales 
• Liberación 
 
GESTIÓN DEL PROYECTO – DIVISIÓN TECNOLOGÍA 
Con la finalidad de gestionar el recurso humano designado a desarrollar soluciones de software se utiliza 
la siguiente organización: 
ORGANIZACIÓN CAPITAL HUMANO 
Gerente TI
Coordinador TI Coordinador TI Líder IT (pasantes) Arquitecto
Líder componente TI
Líder Componente TI
Líder componente TI
Líder Componente TI
Pasante IT
Pasante IT
Pasante IT
Líder arquitectura
Ingeniería de 
Requerimientos
Lider Aseguramiento 
Calidad
 
Figura No. 1 Organigrama de TI 
En la estructura organizativa mostrada en la figura anterior el Gerente de Tecnología en su calidad de 
responsable de la División del Área de Tecnología tiene a su cargo dos grupos de trabajo de componentes 
(en función de los subsistemas o módulos a desarrollar). Además, es apoyado por el líder IT para la 
gestión de pasantes que es parte del compromiso empresarial de la empresa y que sirve de incubadora de 
nuevos candidatos a incorporar al proyecto de desarrollo de software. Finalmente, gestión las iteraciones 
que cada generador de código debe realizar con el apoyo de los arquitectos, en donde además se ven 
temas estructurales del desarrollo con el fin de ir estandarizando funcionalidadestipos. 
• Coordinador: responsable de gestión del desarrollo del subsistema en cuestión. 
• Arquitecto de software: encargado de diseñar la solución del software. 
• Cinco Desarrolladores: encargados de programar la solución informática. 
• Un analista de negocio: encargado de gestionar/ apoyar en el diseño y validación de los Casos 
de Uso, así como pruebas de calidad del software desarrollado. 
• Equipo funcional o contraparte. Definen funcionalmente utilizando Casos de Uso. 
6 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
GESTIÓN CAPITAL HUMANO 
Para maximizar el esfuerzo realizado del Recurso Humano se utiliza la filosofía de trabajo SCRUM, el cual 
acorde a su definición: Está diseñado para equipos de tres a nueve desarrolladores que rompen su trabajo en 
acciones que se pueden completar dentro de ciclos de duración fija (llamados "sprints "), seguimiento de progreso 
y re-planificar en las reuniones diarias de 15 minutos stand-up, y colaborar para entregar viable software cada 
sprint. “. 
Adicionalmente como mecanismo de control del trabajo diario realizado se utiliza software de gestión de 
tareas el cual es responsabilidad de cada uno de los integrantes del grupo registrar sus actividades diarias 
con la finalidad de: 
• Control de las actividades y tiempos realizados por cada uno de los miembros del equipo, 
horas de ingreso y de salida del personal. 
• Información de análisis sobre costos asociados a las actividades realizadas dado el recurso 
humano registrado en dichas tareas. 
GESTIÓN DESARROLLO SOFTWARE 
Para definición del proyecto del área de tecnología se establece un plan del mismo, que conlleva las fases 
de Planificación, Diseño, Ejecución y Finalización, la cual está conformada por tareas y estimaciones de 
tiempo provistas y tomadas en común acuerdo entre Coordinadores, Analistas de Negocio, Arquitecto 
de la Solución y Programadores, sobre los documentos de Visión y Casos de Uso (Ver Especificación 
Funcional y No Funcional) a su vez se considera el nivel de prioridad y urgencia que se pueda tener 
por parte de la Institución beneficiaria sobre la oportunidad que se desea aprovechar o la necesidad no 
cubierta para la creación del plan. 
MODELO CONCEPTUAL 
Fábrica Software
Usuarios Expertos 
Contraparte Técnico
Consultor
DRM
Casos de Uso
Documento de Visión
Modelo E-R
G
e
n
e
ra
d
o
Automatización DRM
Especificaciones
Desarrollo 
(Generación de 
Código)
Pruebas
Lógica de negocio
DRM
MH
Convenciones 
Estándares 
Buena Práctica 
Framework 
Componentes
Pruebas 
Automatizadas
Ambiente Pruebas
Bug Tracker
Modelo Conceptual – IT 
Estrategia DRM
Ambiente Desarrollo
Control 
Versiones
Codigo Fuente
Integrador
Pruebas
Unitarias
Casos de Prueba
IT Analista 
de negocio
 
Figura No. 2 Modelo conceptual de la estrategia de desarrollo de software 
7 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
El flujo de trabajo que conlleva el modelo conceptual de la estrategia de desarrollo de software 
considera las siguientes fases: 
ESTABLECIMIENTO DE 
REQUERIMIENTOS
DESARROLLO DEL SOFTWARE VALIDACIONES PRUEBAS IMPLENTACION EN PRODUCCION
1 2 3 4
 
Figura No. 3 Flujo de trabajo 
 
ESPECIFICACIÓN FUNCIONAL Y NO FUNCIONAL 
Los Usuarios Expertos / Contraparte Técnico establecen las necesidades o requerimientos del 
software a desarrollarse, para lo cual, en función de reuniones de trabajo, se discuten y 
desarrollan los documentos en el siguiente orden: 
• Documento de Visión. Documento que tiene como finalidad establecer el propósito y 
alcance del módulo/sistema/subsistema a desarrollar, detallando para ello las 
oportunidades del negocio a solventar, definición del problema, costos y licenciamiento 
entre otros. Dicho documento permite identificar a la alta gerencia sobre los beneficios a 
obtener del desarrollo de la herramienta tecnológica. 
• Casos de Uso: Documento que describe a nivel granular los actores involucrados que 
interactuará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 dicho 
documento sirva de guía al programador y minimice la brecha de la expectativa del 
usuario final con respecto a la necesidad planteada. Ya que será validada la funcionalidad 
desarrollada con el presente documento. 
Con la finalidad de apoyar a los usuarios expertos a desarrollar los Casos de Uso y Documento 
de Visión con el necesario detalle y formato esperado, se destina a personal IT Analista de 
Negocio, 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 de 
especificación necesario para la construcción del software. 
Adicional a las especificaciones funcionales, se solicita un documento de especificaciones no 
funcionales 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 a 
políticas, entre otros aspectos. 
8 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
DESARROLLO DE SOFTWARE 
Con los documentos debidamente validados por el IT Analista de Negocio en la fase Especificación 
Funcional y no Funcional, se designa un Arquitecto de la Solución el cual a partir de los Casos de 
Uso establece el Diseño de la Solución, creando el Modelo Entidad Relación (Estructuras de base 
de datos) que almacenarán la información necesaria, a partir de ello se inicia el desarrollo del 
software per se, utilizando para ello herramienta de generación de código automatizado cuya 
finalidad es agilizar el trabajo a realizar, asegurar la aplicación de estándares, pantallas 
transaccionales, clases, capas de software, etc. reduciendo el tiempo de trabajo de los 
programadores y el riesgo de errores en su construcción, ya que la herramienta de generación 
utiliza un conjunto de convenciones, estándares y buenas prácticas definidas por el mercado de 
tecnología para la creación de los componentes de software. 
PROCESO DE GENERACIÓN DE SOFTWARE 
Se utiliza esta técnica informática dentro de la estrategia de desarrollo de software y que opera 
en marcos de trabajo Modelo-Vista-Controlador como el que está estipulado en los proyectos 
que se desarrollan en el Ministerio de Hacienda. 
La técnica de generación de código, haciendo uso de plantillas estáticas crean fragmentos de 
código (header, footer, POM, etc) que tienden a no cambiar y que se incrustan en algunos casos 
dentro 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 convergencias 
para ir construyendo clases java, jsp, javascript, xml, archivos de configuración o cualquier otro 
componente necesario de un proyecto de esta naturaleza y todo se hace a partir de una 
conexió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. La 
creación del proyecto se organiza y separa en carpetas que previamente se han convenido para 
una mejor sostenibilidad del software. 
Para mayor legibilidad del código se utilizan una serie de tags que encapsulan la complejidad del 
código, no solo desde el punto de vista funcional, sino desde la parte visual. La única capa en 
donde se realiza programación de lógica de negocios es en la capa del controlador, a nivel de la 
capa visual se realizan solo validaciones de entrada de datos, esto implica que el programador 
desarrolla un software muy estandarizado, legible, escalable. 
PROCESO INCREMENTALE INTERACTIVO 
El desarrollo incremental e iterativo es una de las estrategias que mejor se acoplan a los 
desarrollos informáticos que se tienen definidos realizar en el Ministerio de Hacienda, en 
donde la especificación funcional se captura mediante Casos de Uso y son los que dirigen el 
desarrollo. La idea es que cada iteración tome un conjunto de Casos de Uso y transite el flujo 
definido 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 y 
diseño que se ha incorporado como parte de nuestra estrategia. En esta etapa se acompaña a 
9 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
las áreas de programación con apoyo arquitectónico con el objetivo de asegurar el 
acoplamiento de cada una de las opciones a desarrollar, puesto que al inicio del desarrollo se 
ha construido el núcleo de la solución de software y muchos de los Casos de Uso estarán 
previamente modelados y deberá en estos solo reflejarse la lógica de negocio y no todo el 
ciclo 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 que 
en ella se espera ya tiene algún tipo de desarrollo. 
 
Planificación
Requerimientos
Análisis y diseño
Implementación
Pruebas
Despliegue
Evaluación
Configuración & 
Gestión del Cambio
Planificación inicial
Ambiente
Apoyo Arquitectónico
 
Figura No. 4 Desarrollo Iterativo 
ÁMBITO DEL DESARROLLO 
Con los componentes de software generados de forma automática, los programadores inician 
los ajustes por las funcionalidades ad hoc en función de las necesidades descritas en los Casos 
de Uso, para ello y con la finalidad de controlar los cambios realizados en el proyecto de 
software 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 se 
encuentra en desarrollo, permitiendo identificar en todos momentos los cambios que 
se han realizado, programadores involucrados y fechas de modificación. 
• Ambiente de desarrollo: consiste en aquellos servidores de base de datos y 
aplicación que son utilizados como primer punto de validación del desarrollo 
realizado por los programadores, y en el cual estos últimos validan las 
funcionalidades en construcción. 
• Sistema de automatización de pruebas: software que permite definir un conjunto 
de tareas que tienen como finalidad probar funcionalidades del software 
desarrollado, de tal forma de reducir el riesgo de errores en el sistema en 
construcción. 
10 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
• Integración continua: Dado el ambiente colaborativo en el cual se desarrollan los 
componentes, se utilizan herramienta de integración continua, para asegurar que lo 
persistido en el control de versiones, no de errores a priori, y permita la 
identificación de problemas de forma proactiva. 
• Herramienta de validación de uso de estándares de desarrollo: para 
salvaguardar y certificar el uso de estándares de programación y buenas prácticas en 
el código fuente en desarrollo, se utiliza herramientas especializadas para validar 
dicho fin, el cual tiene como insumo el código fuente y a partir de verificaciones de 
dicha herramienta provee reporte y notificaciones sobre hallazgos para corrección 
debida por parte de los programadores. 
 
ASEGURAMIENTO DE CALIDAD Y PRUEBAS 
Una vez se tiene una versión del sistema programado informáticamente a un nivel que describe 
la necesidad esperada en los Casos de Uso, se procede a implementar dicho software en los 
servidores designados para pruebas de la solución, dicho ambiente es independiente de los 
servidores utilizados para la fase desarrollo. Sobre éste se ejecutan dos tipos de pruebas: 
• Pruebas automatizadas: consiste en un conjunto de tareas de validación establecidas 
en la fase de desarrollo de tal forma de evitar implementar software que no cumpla con 
necesidades básicas de funcionalidad. Dichas pruebas son ejecutadas de forma 
automática por herramienta de software al momento de implementar la solución en los 
ambientes de pruebas, en el caso que alguna de dichas tareas de un error o resultado no 
esperado, la solución no se implementa en los servidores de pruebas y por consiguiente 
notifica a los desarrolladores del error encontrado, caso contrario la solución es 
implementada 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 y 
no Funcional, esta persona realiza validaciones sobre lo establecido en el Caso de Uso vs 
lo desarrollado, de tal forma que en caso de existir incongruencias o brechas entre lo 
especificado y lo desarrollado procede a notificar al programador para su debida 
resolució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 los 
usuarios finales sobre el software desarrollado en los ambientes de pruebas con la 
finalidad de verificar el cumplimiento de la funcionalidad detallada en los casos de uso vs 
el componente de software producido. 
• Pruebas de estrés: en este tipo de pruebas se utiliza sistemas especializados en emular 
diferentes cantidades de conexiones y tareas sobre el software implementado, de tal 
forma de validar el desempeño del hardware, aplicación, base de datos y cualquier otro 
componente relacionado de tal forma de validar los tiempos de respuesta ante alta 
concurrencia de usuarios “virtuales”. A diferencia de las pruebas anteriores la presente 
prueba se realiza sobre la plataforma tecnológica designada para el ambiente de 
producción y es una prueba que debe coordinarse con cada uno de los encargados de los 
diferentes componentes, servidores ,etc. involucrados, de tal forma que a través de 
11 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
software especializado de monitoreo de cada componente se puedan revisar métricas 
sobre uso de los diferentes componentes para que en caso de existir fallas, o tiempos de 
respuesta inaceptables en función de las pruebas y las potenciales de ocurrencia de las 
mismas en caso de implementarse, se provean los pasos a seguir para poder solventar los 
inconvenientes que puedan suscitarse. Este tipo de pruebas son cíclicas en función de las 
acciones realizadas y sirven para validar los tiempos de respuestas aceptables y 
requeridas por el negocio. Dada la naturaleza extrema de estas pruebas, se realizan 
únicamente para nuevos componentes y se calendarice en horarios que minimizan el 
impacto 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 pruebas 
realizadas por los usuarios finales se utiliza herramienta de software para registrar dicho hallazgo y con 
ello facilitar la gestión y tratamiento de dichos incidentes para asignación, seguimiento y resolución por 
parte de los programadores designados a dichas actividades. Una vez que el programador ha solucionado 
o dado respuesta al incidente reportado se inicia el ciclo de pruebas para validar que se ha superado el 
incidente. 
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) que 
debe ser implementado en producción y el cual es trasladado al personal encargado de la 
contraparte técnica de IT para que realice dicha implementación sobre el ambiente de 
producción.ACTIVIDADES POST IMPLEMENTACIÓN 
Una vez la puesta en producción del software desarrollado se provee asesoría a la institución beneficiaria 
sobre 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ÓGICA 
La herramienta de generación de código más reciente cuenta con los siguientes componentes o da soporte 
a los siguientes: 
• Java 7, 8 
• Spring Framework MVC 4.1.6 
• Jqgrid 5.0.1 
• Jquery 2.1.1 
• Bootstrap 3.3.5 
• IO.Spring.platform 1.1.2 
• Hibernate 4.3.8 
• Spring Data JPA 1.7.2 
• JSON 
• Lombok 1.16.10 
12 | ESTRATEGIA DE DESARROLLO DE SOFTWARE USAID.GOV 
• Spring Security 3.2.7 
• PL/SQL ORACLE 11 y 12 
• HTML 5 
• JSP 2 
• Jasper 5.6.0 
 
TRANSFERENCIA DE CONOCIMIENTO 
Los proyectos de tecnología impulsados durante DRM tienen el compromiso de asegurar la 
transferencia de conocimiento a las áreas beneficiadas, es en ese sentido que se imparten diversas 
capacitaciones como en la que se desarrollan las técnicas de ingeniería de requerimiento a las áreas 
funcionales 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 la 
intención que se realice el proceso de transferencia de conocimiento bajo la figura de aprender-
haciendo. 
En algunas oportunidades se realiza procesos de coaching a las áreas beneficiadas para que estas asuman 
componentes de desarrollo de software.