resumen - estrategia de desarrollo de software

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


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


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.


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)


• 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 funcionalidades tipos.

• 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.


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

Ge

ne

rad

o

Automatización DRM

EspecificacionesDesarrollo

(Generación de

Código)

Pruebas

Lógica de negocio

DRM

MH

Convenciones

Estándares

Buena Práctica

Framework

Componentes

Pruebas

AutomatizadasAmbiente 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


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.


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 INCREMENTAL E 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


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ónConfiguració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.


• 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


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


• 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.

resumen - estrategia de desarrollo de software

Documents