UNIVERSIDAD NACIONAL DE INGENIERIA
FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS
SECCION POSGRADO
Especificación de Metodología Agil para
Desarrollo de Software, Apoyada en la
Herramienta CASE Genexus
TESIS
PARA OPTAR EL GRADO ACADEMICO DE:
MAESTRO EN CIENCIAS CON MENCION EN
INGENIERIA DE SISTEMAS
Lic. ·naniel Luis Fernández Verástegui
Lima - Perú
DEO ICA
TORIA
A MIS PADRES ROSA Y DANIEL,
POR INCULCARME EL AMORAL
ESTUDIO Y A LA SUPERACION
A MI ESPOSA GLADYS Y A MIS
HIJOS POR SU COMPRENSION Y
APOYO PARA LOGRAR SUPERAME
AGRADECIMIENTO
AGRADEZCO A MIS PROFESORES POR
SUS VALIOSAS ENSEI\IANZAS
A MIS COMPAI\IEROS DE ESTUDIOS DE
MAESTRIA DE LA UNI POR HABERME
APOYADO A CULMINAR MIS ESTUDIOS
A MI ASESOR DE TESIS Y JURADOS
ESPECIALISTAS POR SU VALIOSA
COLABORACION PARA EL DESARROLLO
DEL PRESENTE TRABAJO DE
IN DICE
Dedicatoria
Agradecimiento . . . ii
lndice ... ... iii
O escnp ores ema tcos . . . .. . t T 't' VIII ...
Resumen Ejecutivo . . . .. . .. . x
Introducción ... :. . . .. xii
CAPITULO 1 . . . 1
PROBLEMA DE INVESTIGACION
1.1. Planteamiento del Problema .. . .. . . .. .. . .. . .. .. .... .. .. .. .. . .. .. . .. . .. .. . .. .. 2 1.2. Hipótesis y Objetivos de la Investigación .. .. . .. .. . .. .. .. .. .. .. . .. . .. .. . .. . 11 1.3. Justificación de la Investigación y Delimitación de la Investigación. 16
CAPITULO 11 ... :. . . 19
MARCO TEORICO
2.1. Antecedentes ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 20 2.1.1. Principales Metodologías Tradicionales. Ventajas, Desventajas.... 20 2.1.2. Principales Metodologías Agiles. Ventajas, Desventajas .. . .. . .. ... 26 2.1.3. Los Métodos Formales de Desarrollo de Software... 40 2.1.4. Las herramientas CASE .. . .. .. .. .. .. .. .. .. . .. . .. .. .. .. .. .. . . .. ... . .. .. .. . .. .. 43 2.2. Reseña Organizacional . .. .. .. .. .. .. .. .. . .. .. .. .. . .. . .. .. .. ... .. .. .. .. .. .. .. .. . 49 2.3. Bases Teóricas ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 53
CAPITULO 111 . . . .. . . ... 62
METODOLOGIA DE LA INVESTIGACION
3.1.2. Método de Investigación para la Ingeniería de Software ... 64
3.2. Investigación en Acción... 68
CAPITULO
IV ... ... ... ... ... ... ... ... ... ... ... ...
71METODOLOGIA DE DESARROLLO PROPUESTA 4. 1. Bases de la propuesta .. .. .. .. . .. . .. .. .. .. . .. .. . .. .. .. .. .. .. .. .. .. .. .. . .. . .. .. 72
4.1.1. Objetivos de la Metodología Propuesta . .. . .. .. .. .. . .. .. .. .. .... .. . .. .. . 73
4.1.2. Herramientas y técnicas usadas en la Metodología Propuesta ... 73
4.1.2.1. La herramienta CASE Genexus .. . ... ... ... ... ... ... 73
4.1.2.1.1. Modelando la realidad... 75
4.1.2.1.2. El problema Teórico ... ... ... ... ... ... ... ... 76
4.1.2.1.3. Desarrollo Incremental... 77
4.1.2.1.4. Implementación del desarrollo incremental... 80
4.1.2.1.4.1. Diseño . . . .. . . .. . . 82
4.1.2.1.4.1.1. Desarrollo basado en el conocimiento .. . .. . .. .. .. . .. .. . .. .. ... 85
4.1.2.1.4.1.2. Múltiples plataformas/Múltiples capas... 85
4.1.2.1.4.2. Prototipado... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 86
4.1.2.1.4.3. Implementación... 87
4.1.2.1.4.4. Mantenimiento . . . .. . . .. ... 89
4.1.2.1.4.5. Documentación... 90
4.1.2.1.4.6. Consolidación de varias aplicaciones y reutilización del conocimiento ... ... ... ... ... ... ... 91
4.1.2.1.5. Características de Genexus... ... ... ... 92
4.1.2.1.6. Funcionalidades Avanzadas... 94
4.1.2.1.6.1. Componentes Web... 94
4.1.2.1.6.2. Objeto Theme ... ... ... ... ... ... ... ... ... ... ... ... ... 95
4.1.2.1.6.3. Patrones... 95
4.1.2.1.6.4. Seguridad . . . 98
4.1.2.1.6.5. Arquitectura AJAX: Implementación con Genexus ... ... 100
4.1.2.1.6.6. Web Services: Implementación con Genexus .. . .. ... ... .. . .. ... 101
4.1.2.2. Prototipos ... 103
4.1.2.3. Pruebas... 103
4.1.2.5. Modelado... 103
4.1.2.6. Gestión de la configuración... 103
4.2. Metodología de desarrollo de software propuesta . . . .. . . . .. . . 104
4.2.1. Principios y prácticas en que se basa la Metodología... 105
4.2.2. Ciclo de vida de Metodología propuesta. Fases ... ... 108
4.2.2.1. Fase de Estudio del sistema de software a desarrollar... 108
4.2.2.1.1. Estudiodefactibilidad ... 108
4.2.2.1.2. Estudio del negocio ... 110
4.2.2.2. Fase de Diseño... 111
4.2.2.2.1. Creación de una Base de Conocimiento... 112
4.2.2.2.2. Creación de un Objeto transacción... 114
4.2.2.2.3. Descripción de estructura de la transacción... 115
4.2.2.2.4. Definición de campos calculados: Fórmulas... 118
4.2.2.2.5. Visualización del Modelo de Datos inferido por Genexus... 119
4.2.2.2.6. Visualización de los Formularios del objeto transacción... 121
4.2.2.2. 7. Creación de Formularios atrayentes: Temas .. . .. .... .. . .. . . .. . .. 123
4.2.2.2.8. Agregar Reglas del Negocio: Reglas... 125
4.2.2.2.9. Creación del objeto Transacción PROVEEDOR... 126
4.2.2.2.10. Revisión de los cambios efectuados al Modelo de Datos. 129 4.2.2.3. Fase de Prototipo ... 131
4.2.2.3.1. Generación Automática de Base de Datos... 131
4.2.2.3.2. Prototipado de la Aplicación... 131
4.2.2.3.3. Prototipado de la Aplicación en .NET con SQL Server 2005 Express Edition... ... ... ... ... ... ... ... ... ... ... ... ... ... ... . 132
4.2.2.3.4. Visualización del informe de creación de la Base de datos. 135 4.2.2.3.5. Creación de la base de datos del Modelo de prototipo... 137
4.2.2.3.6. Generación Automática de Código... 138
4.2.2.3.7. Especificación y Generación del Código fuente... 138
4.2.2.3.8. Visualización del Reporte de Especificación... 139
4.2.2.3.9. Generación de prototipo funcional... 142
4.2.2.3.10. Ejecución de la Aplicación... .. 144
4.2.2.3.12. Desarrollo Incremental y mantenimiento de la Aplicación 147
4.2.2.3.12.1. Inclusión de nuevos Objetos en la Aplicación. ... .. . ... ... . .. 148
4.2.2.3.12.2. Revisión de los cambios efectuados en el Modelo de Datos 149 4.2.2.3.12.3. Análisis de Impacto y Reorganización de la Base de Datos 150 4.2.2.3.12.4. Regeneración de los programas de la Aplicación... 153
4.2.2.3.12.5. Compilación y Ejecución de la Aplicación... 155
4.2.2.3.13. Construcción de Procesos no Interactivos (Reporte y Procedimientos)... 156
4.2.2.3.13.1. Creación e Invocación de un Reporte... 157
4.2.2.3.13.2. Especificación, Generación y Ejecución de la Aplicación. 164 4.2.2.3.14. Consultas- Diálogos Interactivos ( Web Panels) ... 164
4.2.2.3.14.1. Creación de Web Panel: Trabajar con Proveedores ... .... 164
4.2.2.3.14.2. Ejecutar el Web Panel: Trabajar con Proveedores... 174
4.2.2.3.15. Inclusión de objeto Genexus Analista de Compras ... 174
4.2.2.3.16. Creación y consumo de Web Services con Genexus ... 178
4.2.2.3.17. Aplicación de patrones con Genexus ... 182
4.2.2.3.18. Desarrollo Multiplataforma... ... ... ... ... ... ... ... ... .... ... ... ... 191
4.2.2.4. Fase de producción ... 192
4.2.2.5. Fase de Implementación... 193
4.2.3. Roles representados... 194
4.2.4. Naturaleza Iterativa e Incremental de la Metodología MDDS-GX. 195 4.2.5. Factores críticos de éxito de la Metodología propuesta ... 196
CAPITULO V... 197
ESTUDIO DE CASOS 5.1. Aplicación Informática: Tienda de venta de Equipos de Cómputo 198 5.1.1. Diseño de Aplicación Basada en el Conocimiento... 199
5.1.1.1. Creación de una Base de Conocimiento... 199
5.1.1.1.1. Creación de un Objeto transacción FACTURA ... .. . .... .. .. .. . .. 200
5.1.1.1.2. Descripción de estructura de la transacción FACTURA... 201
5.1.1.1.3. Definición de campos calculados: Fórmulas... 201
5.1.1.1.4. Visualización del Modelo de Datos inferido por Genexus... 202
5.1.1.1.6. Creación de Formularios atrayentes: Temas . . . 204
5.1.1. 1. 7. Agregar Reglas del Negocio: Reglas... 205
5.1.1.1.8. Creación del objeto Transacción CLIENTE ... ... ... ... . .. ... 206
5.1.1.1.9. Revisión de los cambios efectuados al Modelo de Datos... 208
5.1.1.2. Generación Automática de Base de Datos... 208
5.1.1.2.1. Prototipado de la Aplicación... 208
5.1.1.2.2. Prototipado de la Aplicación en .NET con SQL Server 2005 Express Edition... ... ... ... ... ... ... ... ... ... ... ... ... ... . 208
5.1.1.2.3. Visualización del informe de creación de la Base de datos. 211 5.1.1.2.4. Creación de la base de datos del Modelo de prototipo .. . . 212
5.1.1.3. FASE DE PROTOTIPO: Generación Automática de Código . 213 5.1.1.3.1. Especificación y Generación del Código fuente .. .. .. ... .. . .... 213
5.1.1.3.2. Visualización del Reporte de Especificación... 214
5.1.1.4. Generación de prototipo funcional... 215
5.1.1.4.1. Ejecución de la Aplicación... 215
5.1.1.4.2. Prueba de la Aplicación... 215
5.1.1.5. Desarrollo Incremental y mantenimiento de la Aplicación... 217
5.1.1.5.1. Inclusión de nuevos Objetos en la Aplicación. ... ... ... ... 217
5.1.1.5.2. Revisión de los cambios efectuados en el Modelo de Datos.. 218
5.1.1.5.3. Análisis de Impacto y Reorganización de la Base de Datos... 218
5.1.1.5.4. Regeneración de los programas de la Aplicación... 221
5.1.1.5.5. Compilación y Ejecución de la Aplicación... 222
5.1.1.6. Construcción de Procesos no Interactivos (Reporte y Procedimientos)... 223
5.1.1.6.1. Creación e Invocación de un Reporte... 223
5.1.1.6.2. Especificación, Generación y Ejecución de la Aplicación... . 227
5.1.1.7. Consultas y Diálogos Interactivos (Work Panels y Web Panels) 227 5.1.1. 7.1. Creación de un Web Panel: Trabajar con Clientes... 227
5.1.1. 7.2. Ejecutar el Web Panel: Trabajar con Clientes... 233
5.2. Estudio de Caso: Aplicación en Empresa de Micro finanzas... 234
5.2.1. Fase de Estudio del Negocio .. . .. . .. .. .. .. .. .. .. .. .. .. . ... .. .. . .. .. .. . .. . 234
5.2.3. Fase de Prototipo ... ... ... .... .. ... ... ... ... ... ... ... 241
5.2.3.1. Web Services: Creación y Consumo con Genexus . .. .. .. . .. .. . 242
5.2.3.2. Patrones: Su aplicación con Genexus ... ... ... 245
CAPITULO VI . . . .. 248
ANALISIS DE RESULTADOS
6. 1. Análisis de Resultados . . . .. . . . 249
6.1. 1. Análisis del logro de objetivos . . . 249
6.1.2. Principales Aportes . . . .. . 258
CONCLUSIONES
y
RECOMENDACIONES .. .. . . .. .. .. .. .. .. .. .. .. .. .. . .. . 259GLOSARIO DE TERMINOS ... ·... 262
DESCRIPTORES TEMATICOS.
• Software.
• Ingeniería de Software.
• Metodología de Desarrollo de Software.
• Metodología Agil de Desarrollo de Software.
• Base de Conocimiento.
• Herramienta CASE Genexus.
• Ciclo de Vida del Desarrollo de Software.
• Calidad del Software.
• Calidad y Aseguramiento de la Calidad del
Software.
RESUMEN
La Superintendencia de Banca Seguros y AFP (SBS) informó que entre el 8 y 1 O de Octubre del 2008, en el Foro de la Microempresa, Perú fue elegido
como el País que reúne las mejores condiciones para las microfinanzas en América Latina y el Caribe.
La mayoría de los pobres en el mundo y entre ellos Peruanos, no tienen acceso a los servicios proporcionados por la banca formal debido a que siempre se ha considerado muy costosos y de alto riesgo atender a los clientes, llamémosles pequeños, con las técnicas bancarias convencionales. Por lo que encuentran en el sector microfinanciero una alternativa para mejorar su condición económica.
Muchas de las instituciones microfinancieras del Perú que han ido creciendo hasta llegar a atender miles de clientes, no cuentan con el Software adecuado que les permita administrar su cartera de créditos, así como las operaciones financieras eficientemente. Este es el caso de la empresa PYME MICREDITPERU de la ciudad de Trujillo, que cuenta con 12 agencias a nivel nacional.
El objetivo de esta Tesis consistió en definir una Metodología Ágil para el Desarrollo de Software apoyada en la herramienta CASE Genexus, que pueda ser aplicada en el Desarrollo de Software de calidad, para la empresa MICREDITPERU y en otras empresas similares.
Herramienta basada en una rama de la inteligencia artificial, la administración del conocimiento.
Los beneficios obtenidos de este trabajo de investigación fueron:
- Se definió una Metodología Ágil de Desarrollo de Software apoyada en la Herramienta CASE Genexus, que aporta valor a la comunidad informática y que permite producir Software de manera eficaz y eficiente, asegurando su Calidad.
- Se da a conocer a los de desarrolladores de software las bondades de las herramientas CASE, contribuyendo así, a romper el escepticismo que existe por parte de muchos de ellos en lo que se refiere a su utilidad.
INTRODUCCION
Muchas de las instituciones microfinancieras son organizaciones sin fines de lucro que han decidido participar como intermediarios financieros por motivos sociales. Es entendible por lo tanto, que en sus inicios no cuenten con conocimientos administrativos y sistemas sofisticados y que además sus sistemas de software tengan la tendencia a ser rudimentarios. Pero a medida que han ido creciendo hasta llegar a atender miles de clientes y a muchos más, han empezado a sentir la necesidad de mejorarlos.
Los gerentes de instituciones crediticias en proceso de expansión pierden la capacidad de mantener contacto con lo que está sucediendo en el campo y llegan a una situación en la que se dan cuenta de que no pueden administrar su cartera de créditos, así como las operaciones financieras
eficientemente sin contar con mejor información sobre ellas.
Por lo tanto, encontramos que muchas instituciones de microfinanzas
están fuertemente motivadas a mejorar su sistema de software. Desafortunadamente, esto no es muy fácil de llevarse a cabo. Debido a que el Software de aplicaciones comerciales existentes usualmente, no proporciona la solución ideal. Muchas instituciones de microfinanzas han tratado de desarrollar ellas mismas gran parte de su Software. La mayoría de las que han optado por esta alternativa reportan que han tenido que sufragar costos mayores a los previstos inicialmente, tanto en dinero, tiempo requerido y dedicación de la gerencia, sin lograr soluciones del todo aceptables, principalmente por no haber usado una metodología de desarrollo de software adecuada,.
las Metodologías ágiles son temas de actualidad en ingeniería de software, han despertado gran interés en los ingenieros de software, profesores, e incluso alumnos, lo que hace prever una gran proyección industrial.
Actualmente, las áreas de Tecnologías de Información de las empresas u organizaciones que desarrollan Software en respuesta a estas exigencias se han visto en la necesidad de hacer uso de herramientas CASE (Computer Aided Software Engineering). Esto con el fin de aumentar la eficacia de los procesos de desarrollo de Software, al soportar la realización de sus actividades haciendo uso de modernas tecnologías de información.
Teniendo en cuenta la problemática antes expuesta, en el presente trabajo de tesis, se diseñó una Metodología Ágil para el Desarrollo de Software, que haciendo uso de las mejores prácticas de las Metodologías Tradicionales y ágiles de Desarrollo de Software y con el apoyo de tecnologías modernas en el Desarrollo de Software, como lo son las Herramientas CASE. (Computer-Aided Software Engineering, Ingeniería de Software Asistida por Computadora), para de ese modo capitalizar los beneficios que dichas herramientas proporcionan, tanto en el desarrollo como en el mantenimiento del Software.
Este estudio de investigación abarca 6 capítulos, las conclusiones y recomendaciones, la bibliografía y finalmente el glosario; que describimos brevemente a continuación:
Capítulo 1, Comprende el planteamiento de la investigación, aquí definimos el planteamiento del problema, su definición, justificación y delimitación de la investigación, hipótesis y finalmente se definen los objetivos principales y específicos que se constituyen en las líneas directrices durante todo el proceso de la investigación.
desventajas; el estudio de las principales metodologías ágiles de desarrollo
de software existentes, sus ventajas, desventajas; las características de los
métodos formales de desarrollo de software, las herramientas CASE, sus
características, la reseña organizacional de la Empresa Micrédito sac. Y
finalmente las bases teóricas en que se basó esta investigación.
Capitulo 111, comprende la metodología de la investigación, aquí se
describe la metodología que sirvió de base a esta investigación, como son la
investigación en ingeniería de software, el objeto de estudio de la ingeniería
de software, el método de investigación para la ingeniería de software y
finalmente el método de investigación en acción.
Capítulo IV, Comprende la metodología de desarrollo de software
propuesta, conformado por, primero las bases de la propuesta como son:
los objetivos de la metodología propuesta, la descripción de las
herramientas y técnicas usadas en la metodología propuesta, principalmente
las características y funcionalidades de la herramienta CASE Genexus.
luego en una segunda sección se define la metodología propuesta
propiamente dicha, principios y prácticas en que se basa la metodología, su
ciclo de vida, las fases que comprende, se describe detalladamente las
principales fases soportadas por la herramienta CASE Genexus, los roles
representados, la naturaleza iterativa e incremental de la metodología
propuesta y finalmente los factores críticos de éxito de la metodología.
Capítulo V, Comprende el estudio de casos, se aplica la metodología
en el desarrollo de un prototipo de una empresa de venta de equipos de
cómputo y del desarrollo de un prototipo de la empresa de microfinazas
Micredito SAC. de la ciudad de Trujillo.
Capítulo VI, Comprende el análisis de resultados, En este capítulo,
tomando como base la Metodología de Investigación descrita en el capítulo
111, se analizan los resultados obtenidos de la aplicación de la Metodología
propuesta, en los casos de estudio descritos en el capítulo V, de este trabajo
inicio de este trabajo, y se indican los principales aportes de esta Tesis de
Maestría.
Las conclusiones y recomendaciones, comprende las conclusiones a
las que se arribó en este trabajo de investigación, para finalmente se anotan
un conjunto de recomendaciones que surgen como consecuencia del trabajo
a lo largo del proceso investigativo.
La bibliografía, comprende el soporte bibliográfico de este trabajo de
investigación.
El glosario, comprende una breve descripción del significado de
CAPITULO 1
1.1.
PLANTEAMIENTO DEL PROBLEMA
Según [Flores, R, 2009] "Las Microfinanzas han evolucionado de manera impresionante en los últimos veinte años. El Perú no sólo no ha sido ajeno a este desarrollo mundial, sino que se ha convertido, conjuntamente con Bolivia, en uno de los mercados líderes de Latinoamérica, tanto por el volumen de sus operaciones y calidad de sus instituciones como por la fortaleza de su regulación.
Este reconocimiento nos lleva a la necesidad de ser de los primeros en preguntarnos qué entendemos por Microfinanzas. Para ello, centraremos nuestro análisis en su componente más conocido: el microcrédito (1); y nos remitiremos a Muhammad Yunus, galardonado con el Premio Nobel de la Paz 2006, y quien es reconocido como el creador del microcrédito moderno.
De acuerdo con Yunus, el microcrédito lo constituyen aquellos programas que ofrecen crédito sin garantías para actividades generadoras de ingresos, y que son dirigidos encaminados a que los pobres superen la línea de la pobreza. De acuerdo con esta definición, el microcrédito debe ser entendido en un sentido más complejo, y no sólo pensar que se trata de prestar dinero a los pobres. De ello, surge la pregunta ¿qué instituciones vienen trabajando para promover este concepto de microcrédito en el país?
Asimismo, es necesario entender si las instituciones públicas y privadas que promueven y regulan el sector financiero están interesadas en promover este concepto de microcrédito. Finalmente, y quizás lo más importante, es saber si las instituciones que otorgan créditos a la población de escasos recursos tienen el objetivo de ayudarlos a superar su condición de pobres.
(1) El concepto de microfinanzas agrupa a diferentes serv1ctos
financieros
y
no financieros, dirigidos a atender las diferentesnecesidades de la población marginada, tates como microseguros,
capacitación, micropensiones, crédito para la construcción
y
Esto nos lleva a dos reflexiones: la primera, es que la definición de microcrédito en la regulación financiera resulta muy amplia (2), ya que aglutina diversas modalidades de crédito, destinos de fondos (3) y perfiles de clientes; por lo que sería necesario contar con una definición más precisa. Así, el concepto de microcrédito podría subdividirse en categorías que permitan una mayor precisión en el diseño de las políticas: microcrédito, créditos para pequeños negocios, inversión en mejora de la vivienda y consumo para personas de escasos recursos.
La segunda reflexión es que dado que las instituciones de microcrédito, bajo la definición de Yunus, deben tener como objetivo ayudar a los pobres a dejar de serlo, éstas deberían tener un fin social superior al fin de lucro de sus accionistas. En efecto, Yunus nos habla de manera permanente de la importancia de lograr instituciones microfinancieras sólidas y eficientes como requisito para asegurar el éxito de los programas de microcrédito; pero al mismo tiempo, resalta la importancia del cumplimiento de la misión social y su primacía sobre el lucro. Por ello, microcrédito y maximización del lucro son incompatibles.
El cumplimiento de la misión social y la importancia de lograr que los pobres puedan superar su condición de pobreza, debe llevar a las instituciones microfinancieras a identificar las necesidades insatisfechas de sus clientes.
(2) La Superintendencia de Banca, Seguros y AFP clasifica al
microcrédito como aquel dirigido a una persona jurídica o natural con
negocio (es decir que cuente con RUS
o
RUC) y cuya exposición en elsistema financiero nacional no supere los 30,000 USD.
(3) Bajo la calificación actual, podría incluirse como microcrédito a un
crédito otorgado a un micro
o
pequeño empresario, sin diferenciar silos recursos se utilizan para invertir en su negocio, para comprar ropa
o
regalos para su familiao
para construir un cuarto adicional a suEn este sentido, el microcrédito debe ser entendido como una herramienta y no como la solución mágica para aliviar la pobreza. Es por ello que, dado el gran número de necesidades insatisfechas de la población de bajos recursos, el acceso al crédito resulta tan importante como el acceso a la oportunidad de ahorrar, de acceder a seguros de vida y planes de salud, a un plan de pensiones que asegure su tranquilidad futura, a la oportunidad de adquirir o mejorar su vivienda, a dar una educación técnica o superior a sus hijos, etc. Estas son necesidades que en la actualidad no viene siendo suficientemente atendidas por las microfinanzas.
la Superintendencia de Banca Seguros y AFP (SBS) de Perú informó en el marco del Foro de la Microempresa, organizado por el Fondo Multilateral de Inversiones (FOMIN) y el gobierno de Paraguay, celebrado en su capital Asunción, entre el 8 y 10 de Octubre del 2008, los resultados de un último estudio realizado por el Economist lntelligence Unit (EIU) con apoyo del Banco Interamericano de Desarrollo (BID) y de la Corporación Andina de fomento (CAF), en donde el Banco Interamericano de Desarrollo (BID) en su informe anual "Entorno de negocios para las microfinanzas de América latina y el Caribe", más conocido como el Microscopio Regional. Otorgó el primer lugar a Perú, como el País que reúne las mejores condiciones para las microfinanzas en America latina y el Caribe.
Según [Sánchez C., 2008], "Por el Tratado de libre Comercio (TlC) que Perú suscribió con Estados Unidos, se estima que habrá nuevas oportunidades laborales para los peruanos, también se prevé que generará algunas limitaciones en algunos sectores denominados "sensibles", como en la agricultura, que es el sector donde generalmente donde laboran las personas más pobres del país.
La pobreza que tiene sus raíces en los asentamientos humanos, comunidades urbano-marginales y rurales, así como en los grupos étnicos de la Amazonía, encuentra en el sector microfinanciero una gran resistencia para seguir avanzando.
El sector microfinanciero será en los siguientes años, uno de los sectores más dinámicos de la economía peruana. Urge entonces que desde ahora, este sector se prepare para asumir nuevos roles que van desde la lucha frontal contra la pobreza hasta la formalización de nuevas pequeñas empresas.
En el Perú hay nuevas generaciones de emprendedores que requieren microcréditos para salir adelante. La cultura emprendedora es ya una realidad en el país. Hay más de tres millones de unidades productivas y comerciales y esta cifra va en aumento".
Según [Waterfield C., Ramsing N., 1998] "La mayoría de los pobres en el mundo (entre ellos Peruanos), no tienen acceso a los servicios proporcionados por la banca formal debido a que siempre se ha considerado muy costoso y de alto riesgo atender a los clientes, llamémosles pequeños, con las técnicas bancarias convencionales.
Muchas de las instituciones microfinancieras son organizaciones sin fines de lucro que han decidido participar como intermediarios financieros por motivos sociales. Es entendible por lo tanto, que en sus inicios no cuenten con conocimientos administrativos y sistemas sofisticados y que además sus sistemas de información computarizados tengan la tendencia a ser rudimentarios. Pero a medida que han ido creciendo hasta llegar a atender miles de clientes y a muchos más, han empezado a sentir la necesidad de mejorarlos.
administrar su cartera de créditos, así como las operaciones financieras eficientemente sin contar con mejor información sobre ellas.
Por lo tanto, encontramos que muchas instituciones de microfinanzas están fuertemente motivadas a mejorar su sistema de información computarizados. Desafortunadamente, esto no es muy fácil de llevarse a cabo. Debido a que el Software de aplicaciones comerciales existentes usualmente, no proporciona la solución ideal. Muchas instituciones de microfinanzas han tratado de elaborar ellas mismas gran parte de su Software. La mayoría de las que han optado por esta alternativa informan que han tenido que sufragar costos mayores a los previstos inicialmente, tanto en dinero, tiempo requerido y dedicación de la gerencia, sin lograr soluciones del todo aceptables".
[S
Finanzgruppe, 2003] menciona que: '7. Las microfinanzas significanbuena organización y técnica."
Las microfinanzas no se caracterizan por volúmenes altos, sino por grandes números de transacciones.
La concentración de un gran número de depósitos pequeños y de la otorgación de muchos créditos pequeños, no requieren particularmente de técnicas sofisticadas de análisis, sino más bien una organización eficiente. Esto es muy importante, ya que los clientes, no viven solamente en la capital o en los centros urbanos, sino que están repartidos por todo el país. Estos dos factores juntos- grandes cantidades de transacciones y la organización descentralizada- solo se pueden manejar con personal bien capacitado y con un equipo técnico apropiado.
Las microfinanzas por lo tanto no quieren decir papel y lápiz, sino hardware robusto y software eficiente."
de los Desarrolladores de Software se guían por planos que se denominan Modelos, tales como: Los Modelos de Casos de Uso, Modelo de Clases, de Actividades, Prototipos, etc.
La Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo de Software.
En los últimos 20 años las notaciones de modelado y luego las herramientas pretendieron ser la "solución" para lograr el éxito en el desarrollo de software, sin embargo, estas expectativas no fueron satisfechas, esto se debe en gran medida a que se dejó de lado un elemento importante, como son las Metodologías de desarrollo. Hasta hace poco el proceso de desarrollo le daba una gran importancia al control del proceso por medio de definiciones rigurosas de roles, actividades y artefactos, así como modelado y documentación exhaustiva. Esta forma "tradicional" de enfocar el desarrollo de software ha demostrado ser efectivo y útil en proyectos de gran envergadura en cuanto a tiempo y recursos empleados. Sin embargo, este enfoque no resulta ser el más indicado para la gran mayoría de los proyectos actuales donde el entorno del sistema es cambiante y la exigencia de entrega de los sistemas requiere tiempos de desarrollo mínimos pero conservando alta calidad.
Debido a la dificultad de usar las Metodologías tradicionales contemplando estas exigencias de tiempo y flexibilidad, muchos desarrolladores desisten del uso de estas Metodologías y optan por el uso de las denominadas Metodologías ágiles como una posible solución para llenar ese vacío metodológico.
Las Metodologías ágiles son temas de actualidad en ingeniería de software, han despertado gran interés en los ingenieros de software, profesores, e incluso alumnos, lo que hace prever una gran proyección industrial.
cuales sus características se ajustan a las de las Metodologías ágiles.
La manera de Desarrollar Software, ha ido experimentando continuamente cambios a través del tiempo, buscando asegurar el logro de resultados esperados cada vez que se inicia un nuevo proyecto de desarrollo. Los objetivos del Software a Desarrollar podrían definirse fácilmente, pero seguir el ciclo adecuado para poder alcanzarlos y que este ciclo conserve el equilibrio necesario entre la eficiencia y la efectividad es una tarea difícil. Esto significa buscar la manera de desarrollar Software de Calidad.
Actualmente, las áreas de Tecnologías de Información de las empresas u organizaciones que desarrollan Software en respuesta a estas exigencias se han visto en la necesidad de hacer uso de herramientas CASE (Computer Aided Software Engineering). Esto con el fin de aumentar la eficacia de los procesos de desarrollo de Software, al soportar la realización de sus actividades haciendo uso de modernas tecnologías de información.
negativos".
Una herramienta (,ASE es un software utilizado con la finalidad de aumentar la produc,dvidarl del analista y la calidad de los sistemas desarrollados por éstos :smith, 1989]; [Kerr, 1989]; [Kendall, 1999];[Chen y Norman, 1992). Por J.al motivo muchas organizaciones en los EE.UU. las adquirieron, pero su impl'..tmentación en muchas de ellas fue un fracaso [Kemerer, 1992].
La herramient&s CASE es una herramienta y no una Metodología, como se refieren frecr;dntemente a ella, algunos vendedores de CASE [Callaos, 1991). ActJalmente las empresas peruanas, tanto públicas como privadas, están interesar~as en adquirir nuevas tecnologías, desarrollar sistemas de informacit 11 y/o aplicar re ingeniería a los viejos sistemas. En
todos estos procese-.:; las herramientas CASE representan una pieza clave, pues contribuyen con el trr .. oajo del analista, haciéndolo más eficiente.
Teniendo en cue. 1ta la problemática antes expuesta, en el presente trabajo de tesis, Sd diseFió una Metodología Ágil para el Desarrollo de
Software, que haciend0 uso de las mejores prácticas de las Metodologías Tradicionales y ágik.:s de Desarrollo de Software y con el apoyo de Tecnologías modernas e.1 el Desarrollo de Software, como lo son las Herramientas CASE. ((,omputer-Aided Software Engineering, 1 ngeniería de Software Asistida rvr Computadora), para de ese modo capitalizar los beneficios que dichas hr;rramientas proporcionan, tanto en el desarrollo como en el mantenimie: 1to del Software.
DEFINICION DEL PRC'BLEMA
Tomaremos comr referencia de pequeñas empresas de microfinanzas a la Empresa PYME MICREDITPERU cuya oficina principal está ubicada en la ciudad de Trujillo y viPne operando desde hace aproximadamente un año.
Sus Procesos están Apoyados por un Software que no satisface sus necesidades de información manifestándose de la manera siguiente:
la Gerencia General y la Gerencia de Operaciones manifiestan que, a nivel de la oficina principal, no se cuenta con información oportuna y confiable tanto a nivel de cada una de las agencias como a nivel de toda la Empresa que les permitan obtener en forma oportuna y confiable: Estados financieros, Indicadores de gestión, Flujos de caja, Gestionar la cartera de préstamos, Presupuestos proyectados y ejecutados, Estadísticas numéricas y graficas.
Los Administradores de las Agencias manifiestan que tienen problemas de oportunidad y confiabilidad en la información que les permita gestionar adecuadamente la cartera de créditos, el desempeño de sus Analistas de Crédito, la calificación de solicitudes de créditos, los estados de cuenta de los Clientes y la obtención de sus estados financieros.
Manifiestan también que presentan la existencia de inconsistencias en la información contenida en los diferentes reportes que se emiten.
Este Software se ha desarrollado sin seguir una Metodología de Desarrollo adecuada. Debido a esto es que aún continúa "afinándose" y presenta problemas de inconsistencias, falta de integración y falta de confiabilidad en la información producida, así como dificultad para obtener información que apoye en la toma de decisiones, a nivel operativo, de control y de planeamiento.
La labores de mantenimiento del Software insume demasiados recursos horas/programador y no satisface los requerimientos de los
usuarios ..
El mantenimiento correctivo del sistema actual, generalmente, no se hace oportunamente, dando lugar a que se brinde un servicio inadecuado y el consiguiente reclamo de los clientes.
Desarrollo de Software usando herramientas y metodologías de última generación que permita maximizar la productividad y calidad en todo el ciclo de vida del Desarrollo del Software.
1.2. HIPOTESIS Y OBJETIVOS DE LA INVESTIGACION
HIPO TESIS
Al inicio del trabajo de investigación llevado en esta Tesis de Maestría y considerando lo escrito, con anterioridad, en esta sección, se planteo la siguiente hipótesis de trabajo:
"Es factible la especificación de una Metodología Ágil para Desarrollo de Software, apoyada en la Herramienta CASE GENEXUS, que cumpla con los principales requisitos que debe tener una Metodología de Desarrollo de Software, que permita superar o mitigar las limitaciones de las metodologías de desarrollo de software actuales, que permita desarrollar software que satisfaga los requerimientos funcionales y no funcionales de la empresa
PYME de microfinanzas MICREDITPERU, así como, los requerimientos generalmente aceptados de las PYMES de microfinanzas de la localidad de Trujillo- Perú."
OBJETIVO PRINCIPAL
El objetivo principal de este trabajo de investigación derivado de esta hipótesis es: Especificar una Metodología Ágil para Desarrollo de Software, apoyada en la Herramienta CASE GENEXUS, que cumpla con los principales requisitos que debe tener una Metodología de Desarrollo de Software, que permita superar o mitigar las limitaciones de las metodologías de desarrollo de software actuales, desarrollar software que satisfaga los requerimientos funcionales y no funcionales de la empresa PYME de microfinanzas MICREDITPERU, así como, los requerimientos generalmente
aceptados de las PYMES de microfinanzas de la localidad de Trujillo- Perú.
OBJETIVOS ESPECIFICOS
1. Identificar los principales requisitos deseables que se deben considerar
al construir una metodología de desarrollo de software y proponer una
serie de criterios de evaluación de dichos requisitos.
2. Establecer las principales características que debe reunir una
Metodología para desarrollar el Software de una PYME de
Microfinanzas localizada en la ciudad de Trujillo -Perú, asegurando la
Calidad del Software.
3. Determinar las limitaciones de las metodologías ágiles de desarrollo de
software actuales.
4. Determinar las mejores prácticas usadas en las principales
Metodologías de Desarrollo de Software existentes, tanto de las
Tradicionales como de las Ágiles.
5. Determinar las principales características y funcionalidades de la
Herramienta CASE GENEXUS.
6. Especificar la Metodología a proponer, teniendo en cuenta los objetivos
1., 2., 3. y4.
7. Validar la Metodología a proponer mediante su aplicación a 2 casos de
estudio: Aplicación de Facturación de una Empresa de venta de Equipos
de cómputo y de La PYME de microfinanzas MICREDITPERU de la
ciudad de Trujillo- Perú.
Con respecto al objetivo específico 1 , consideramos lo propuesto por
Rafael Menéndez- Barza llano- Ascencio del Departamento de Informática y
Sistemas de la Universidad de Murcia - España:
http://www. um. es/docencia/barza na/lAG P/lagp3. html
¿Qué hay que saber para construir o elegir una Metodología?
En el momento de construir una Metodología, se han de considerar
unos requisitos deseables, por lo que seguidamente se proponen una serie
1. La Metodología debe ajustarse a los objetivos: Cada aproximación al
desarrollo de software está basada en unos objetivos. Por ello la Metodología que se elija debe recoger el aspecto filosófico de la aproximación deseada, es decir que los objetivos generales del desarrollo deben estar implementados en la Metodología de desarrollo.
2. La Metodología debe cubrir el ciclo entero de desarrollo de
software: Para
Ello, la Metodología ha de realizar unas etapas:
Investigación, Análisis de requisitos, Diseño, Implementación, Pruebas y Mantenimiento.
3. La Metodología debe integrar las distintas fases del ciclo de
desarrollo:
Rastreabilidad. Es importante poder referirse a otras fases de un
proyecto y fusionarlo con las fases previas. Es importante poder moverse no sólo hacia adelante en el ciclo de vida, sino hacia atrás de forma que se pueda comprobar el trabajo realizado y se puedan efectuar correcciones.
_Fácil interacción entre etapas del ciclo de desarrollo. Es necesaria
una validación formal de cada fase antes de pasar a la siguiente. La información que se pierde en una fase determinada queda perdida para siempre, con un impacto en el sistema resultante.
4. La Metodología debe incluir la realización de validaciones: La
Metodología debe detectar y corregir los errores cuanto antes. Uno de los problemas más frecuentes y costosos es el aplazamiento de la
detección y corrección de problemas en las etapas finales del proyecto. Cuanto más tarde sea detectado el error más caro será corregirlo.
5. La Metodología debe soportar la determinación de la exactitud del sistema a través del ciclo de desarrollo: La exactitud del sistema
implica muchos asuntos, incluyendo la correspondencia entre el sistema y sus especificaciones, así como que el sistema cumple con las necesidades del usuario. Por ejemplo, los métodos usados para análisis y especificación del sistema deberían colaborar a terminar con el problema del entendimiento entre los informáticos, los usuarios, y otras partes implicadas. Esto implica una comunicación entre usuario y técnico, amigable y sencilla, exenta de consideraciones técnicas.
6. La Metodología debe ser la base de una comunicación efectiva:
Debe ser posible gestionar a los informáticos, y éstos deben ser capaces de trabajar conjuntamente. Ha de haber una comunicación efectiva entre analistas, programadores, usuarios y gestores, con pasos bien definidos para realizar progresos visibles durante la actividad del desarrollo.
7. La Metodología debe funcionar en un entorno dinámico orientado al usuario a lo largo de todo el ciclo de vida del desarrollo se debe producir una transferencia de conocimientos hacia el usuario. La
clave del éxito es que todas las partes implicadas han de intercambiar información libremente. La participación del usuario es de importancia vital debido a que sus necesidades evolucionan constantemente. Por otra parte la adquisición de conocimientos del usuario le permitirá la toma de decisiones correctas.
Para involucrar al usuario en el análisis, diseño y administración de datos, es aconsejable el empleo de técnicas lo más sencillas posible. Para esto, es esencial contar una buena técnica de diagramación.
8. La Metodología debe especificar claramente los responsables de resultados: Debe especificar claramente quienes son los participantes
9. La Metodología debe poder emplearse en un entorno amplio de
proyectos de desarrollo de software:
_ Variedad. Una empresa deberá adoptar una Metodología que sea
útil para un gran número de sistemas que vaya a construir. Por esta razón no es práctico adoptar varias Metodologías en una misma empresa.
_ Tamaño, ciclo de vida. Las Metodologías deberán ser capaces de
abordar sistemas de distintos tamaños y rangos de ciclos de vida.
_Complejidad. La Metodología debe servir para sistemas de distinta
complejidad, es decir puede abarcar un departamento, varios departamentos o diversas empresas.
Entorno. La Metodología debe servir con independencia de la
tecnología disponible en la empresa.
1 O. La Metodología se debe de poder enseñar: En una organización de
dimensiones reducidas, serán muchas las personas que la van a utilizar, incluso los que se incorporen posteriormente a la empresa. Cada persona debe entender las técnicas específicas de la Metodología, los procedimientos organizativos y de gestión que la hacen efectiva, las herramientas automatizadas que soportan la Metodología y las motivaciones que subyacen en ella.
11. La Metodología debe estar soportada por herramientas CASE: La Metodología debe estar soportada por herramientas automatizadas que mejoren la productividad, tanto del ingeniero de software en particular, como la del desarrollo en general.
12. La Metodología debe soportar la eventual evolución del sistema: Normalmente durante su tiempo de vida los sistemas tienen muchas versiones, pudiendo durar incluso más de 1 O años. Existen herramientas CASE para la gestión de la configuración y otras denominadas "Ingeniería inversa" para ayudar en el mantenimiento de los sistemas no estructurados, permitiendo estructurar los componentes de éstos facilitando así su mantenimiento.
13. La Metodología debe contener actividades conducentes a mejorar el proceso de desarrollo de software: Para mejorar el proceso es básico disponer de datos numéricos que evidencian la efectividad de la aplicación del proceso con respecto a cualquier producto software resultante del proceso.
Para disponer de estos datos, la Metodología debe contener un conjunto de mediciones de proceso para identificar la calidad y coste asociado a cada etapa del proceso. Sería ideal el uso de herramientas CASE.
14. La Metodología debe permitir desarrollar software que satisfaga los requerimientos funcionales y no funcionales de· la empresa PYME de microfinanzas MICREDITPERU, así como, los requerimientos generalmente aceptados de las PYMES de microfinanzas de la localidad de Trujillo- Perú.
15. La Metodología debe superar o mitigar las limitaciones de las
metodologías de desarrollo de software actuales.
1.3. JUSTIFICACION
Y
DELIMITACION
INVESTIGACION.
1.3.1. IMPORTANCIA Y JUSTIFICACION
1.3.1.1. Relevancia Organizacional
DE
LA
principalmente que apoye en los procesos de Toma de Decisiones de la Gerencia General. Agilizándose significativamente la atención a los clientes contribuyendo en esa forma a acelerar la ejecución de sus proyectos.
1.3.1.2. UTILIDAD METODOLOGICA.
Valiéndonos de los avances en Tecnología de Información existentes, tal como la Herramienta CASE GENEXUS y de las mejores prácticas usadas en las Metodologías de Desarrollo de Software existentes, tanto tradicionales como las denominadas Agiles, se diseñará una Metodología Ágil para Desarrollo de Software apoyada en dicha herramienta CASE.
Es conveniente que la comunidad informática cuente con una Metodología Ágil de desarrollo de Software que se apoye en herramientas de última generación para llevar a cabo con eficacia y eficiencia las diversas etapas que conllevan el Desarrollo de Software.
1.3.1.3. VALOR TEORICO
Se dará a conocer como la Herramienta CASE GENEXUS apoya en las diferentes etapas de la Metodología Ágil para Desarrollo de Software propuesta en el presente trabajo de investigación, asegurando la Calidad del Software e incrementando su productividad.
1.3.1.4. IMPLICACIONES PRACTICAS.
1.3.2. DELIMIT ACION
En cuanto a la temática, en esta tesis, se responderá las preguntas siguientes:
¿Cómo definir una Metodología Ágil para Desarrollo de Software, teniendo como base las Metodologías y notaciones actualmente empleadas (Rational Unified Process, Extreme Programming, etc), que incorpore las mejores y más avanzadas prácticas existentes en cada etapa del desarrollo de Software?
¿Cómo la Herramientas CASE GENEXUS, apoya en las diferentes etapas de la Metodología Ágil de Desarrollo de Software a proponer?
CAPITULO 11
2.1. ANTECEDENTES
La comunidad de desarrolladores de software, motivados y podría decirse presionados, ante exigencias de los usuarios, tales como las de lograr el desarrollo de software comercial de calidad, en plazos acordes con las exigencias del mercado y de la competencia, siempre está en busca de métodos más eficientes de desarrollo de los productos software, esta búsqueda ha dado lugar al descubrimiento de nuevos paradigmas para el desarrollo de software, búsqueda que aún continua, en la medida de que el proceso de desarrollo de software no se asemeje al de las demás ingenierías.
A continuación haremos una breve descripción de las principales Metodologías actuales, así también, mencionaremos sus ventajas y desventajas.
2.1.1. PRINCIPALES METODOLOGÍAS TRADICIONALES:
2.1.1.1. PROCESO RATIONAL UNIFICADO- RUP:
Es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto.
Tiene 3 características esenciales; está dirigido por Casos de Uso: que orientan el proyecto a la importancia para el usuario y lo que este quiere, está centrado en la arquitectura: que Relaciona la toma de decisiones que indican cómo tiene que ser construido el sistema y en qué orden, y es iterativo e incremental: donde divide el proyecto en miniproyectos donde los casos de uso y la arquitectura cumplen sus objetivos de manera más
depurada
PRINCIPIOS CLAVE DEL RUP:
Balancear prioridades: Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.
Colaboración entre equipos: El desarrollo de software no lo hace
una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
Demostrar valor iterativamente: Los proyectos se entregan,
aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y . . se refina la dirección del proyecto así como también los riesgos involucrados
Elevar el nivel de abstracción: Este principio dominante motiva el
uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Éstos se pueden
acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML.
Enfocarse en la calidad: El control de calidad no debe realizarse
al final de cada iteración, sino en todos los aspectos de la producción
EL CICLO DE VIDA DE RUP
RUP divide el proceso en 4 fases (ver Fig. NO 01), dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades.
[Booch, 1999]
En las iteraciones de cada fase se hacen diferentes esfuerzos en
diferentes actividades
· Iniciación: Se hace un plan de fases, se identifican los principales
· Elaboración: Se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos.
Figura N° 01. Fases e Iteraciones del RUP
' -
-L·---"
··~-lmpMmllfll•cllm
! - -
-1
j - -
1---! ... .., .... ! • •
Fuente:
http:/lwww. ibm. com/developerworks/rational/library/content/03July/1 00 0/1251/1251 bestpractices TP026B.pdf
· Construcción: Se concentra en la elaboración de un producto totalmente operativo y eficiente y el manual de usuario.
· Transición: Se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.
2.1.1.2. METRICA- VERSION 3
METODOLOGIA DE PLANIFICACION, DESARROLLO Y MANTENIMIENTO DE SISTEMAS DE INFORMACION
software que a través de esta Metodología las administraciones públicas españolas pretenden llevar a cabo.
Todo proyecto Métrica 3 consta de un conjunto de fases que se desglosan en múltiples puntos cuya cronología hay que seguir con claridad para ir avanzando en el desarrollo del proyecto. La Figura 02. muestra el esquema general de estas fases:
En general, con Métrica 3 es posible gestionar proyectos orientados a objetos y proyectos estructurados. En tanto que la tendencia de la ingeniería de software actual lleva con claridad hacia los sistemas y herramientas cuya utilización está basada exclusivamente en el modelo de la orientación a objetos.
1 1
1
1
1
Figura NO 02. Estructura del Métrica V3.
Metrica V3
Planlfteaelón
de Sistemas da
Jntótmaelon
,
..
Aseguramiento d• Calidad
Desarrollo
JAS
ltr~IM.ÜLJI~I<Ioi
Sillllnl
Gestión de
Proyoctoa
Geetiónde · Configuración
Mantenimiento de Sistemas de Información
1 __ ' -__ -__ -_ - __ -_ -_ - ~ .
2.1.1.3. CMMI: CAPABILITY MATURITY MODEL INTEGRATION
CMMI, es un modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Fue desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en enero de 2002.Dos representaciones: Continua y escalonada (Ver Figuras 03 y 04 respectivamente)
Niveles de madurez
El "escalonado" CMM define 5 niveles posibles de madurez para las organizaciones que desarrollan y mantienen software.
Nivel1: Inicial
Los resultados de calidad obtenidos son consecuencia de las personas y de las herramientas que emplean. No de los procesos, porque o no los hay o no se emplean.
Nivel2: Repetible
Se considera un nivel 2 de madurez cuando se llevan a cabo prácticas básicas de gestión de proyectos, de gestión de requisitos, control de versiones y de los trabajos realizados por subcontratistas. Los equipos de los proyectos pueden aprovechar las prácticas realizadas para aplicarlas en nuevos proyectos.
Nivel 3: Definido
Los procesos comunes para desarrollo y mantenimiento del software están documentados de manera suficiente en una biblioteca accesible a los equipos de desarrollo. Las personas han recibido la formación necesaria para comprender los procesos.
Nivel 4: Gestionado
La organización mide la calidad del producto y del proceso de forma cuantitativa en base a métricas establecidas.
Nivel 5: Optimizado
La mejora continua de los procesos afecta a toda la organización, que cuenta con medios para identificar las debilidades y reforzar la prevención de defectos. Se analizan de forma sistemática datos relativos a la eficacia de los procesos de software para analizar el coste y el beneficio de las adaptaciones y las mejoras.
Se analizan los defectos de los proyectos para determinar las causas, y su ma peado sobre los procesos.
COMPONENTES ESPERADOS
• Práctica genérica: Una práctica genérica se aplica a cualquier área de proceso porque puede mejorar el funcionamiento y el control de cualquier proceso.
• Práctica específica: Una práctica específica es una actividad que se
considera importante en la realización del objetivo específico al cual está asociado. Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de proceso.
Figura N003. Representación Continua
Estructura CM MI 1.1 {representación continua)
Figura N° 04. Representación Escalonada
¡ - - - .
--·--·-···---·---l
¡ Estructura CMMJ 1.1 {representación escalonada)
Fuente: CMMI® for Development, Version 1.2 CMU/SEI-2006-TR-008 ESC-TR-2006-008, copyright 2006 by Carnegie Mellon University.
2.1.2. PRINCIPALES METODOLOGÍA ÁGILES (AMs):
2.1.2.1. PROGRAMACION EXTREMA (Extreme Programming, XP): [Beck, K, 2000].
Figura N° 05. Ciclo de Vida de XP.
Fuente: Kent Beck, "RE: (OTUG) XP and Documentation". Rational's
Object Technology User Group Mailing List, 23 de Marzo de
1999.
2.1.2.2.
SCRUM
{Ken Schwaber, 2004] Desarrollada por Ken Schwaber,Jeff Sutherland y Mike Beedle. Define un marco para la gestión de
proyectos, que se ha utilizado con éxito durante los últimos 1 O años. Esta
especialmente indicada para proyectos con un rápido cambio de requisitos.
Sus principales características se pueden resumir en dos. El desarrollo de
software se desarrolla mediante iteraciones, denominadas sprints, con una
duración de 30 días. El resultado de cada sprint es un incremento ejecutable
que se muestra al cliente. La segunda característica importante son las
reuniones a lo largo del proyecto, entre ellas destaca la reunión diaria de 15
minutos del equipo de desarrollo para coordinación e integración. En la
Figura N° 06. Ciclo de Vida de Metodología SCRUM
--"
~---" .Crnd6n EJplc:.k. PNMII Pruebl. PNibl . . Prulba.
dll Conatplo ~· Otnl'lo COclgo .Unldecl ltUgnlcl6n Slll.ml ~
Pre-~eoo
.llego p~
~·
f', "'\
1 Plane1mlento 1 A r 1'
'
.-
..
)
r
r--
Ust.dt tnal,~ Documentos
,._, 1'-'--1· • Sprint
¡i L...ca• Rt1m.o ~ ln ...
l.
eión.*"'"'~ ~
.
~ SPRNT - " Prueba deL_..--
~
!ewtaoor~j
PMiba 1 Ennp ;.::l
Sistem1 i-1H
Oiselio de Ato 1 1~
Ret•neNivel/ Arqullectura
1 lntttmedlo
1 1
Fuente: Pekka Abrahamsson. "Agile Software development methods: A minitutorial". VTT Technical Research Centre of Finland,
http://www. vtt.fi/virtuallagile/seminar2002/Abrahamsson_agil e_methods_minitutorial.pdf, 2002.
2.1.2.3.
CRYSTAL METODOLOGIES:
[Alistar Cockburn and JimHighsmith, 2004)
Son un conjunto de Metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software es considerado como un juego cooperativo de invención y cooperación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Esta políticas dependerán del tamaño del equipo, estableciéndose un clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros). la Figura NO 07, muestra esta clasificación.
describían como secuencias de pasos. Aún cuando se recomendaran iteraciones e incrementos (que no hacían más que agregar confusión a la interpretación) los modelos parecían dictar un proceso en cascada, por más que los autores aseguraran que no era así. El problema con estos procesos es que realmente están describiendo un workflow requerido, un grafo de dependencia: el equipo no puede entregar un sistema hasta que está integrado y corre. No puede integrar y verificar hasta que el código no está escrito y corriendo. Y no puede diseñar y escribir el código hasta que se le dice cuáles son los requerimientos. Un grafo de dependencia se interpreta necesariamente en ese sentido, aunque no haya sido la intención original.
Figura N° 07. Clasificación de Metodogias Crystal por colores
c.
rit. ica.Ud ..a
..
df
~del SisternaJ-.. _ __..__.._.,.,._ ... _.~., .. r...,..._·..._..__¡-... •·--·.-..--· .. ,,
•
1
!1
j:S
LO 1 U:O L140 ., ...e; :• t ' t :
'
1
1
tUl 1 t :;') '- •e
-11
ICMI n:-J r ... .r.
..
1' 1 ' 1 i 1 1
1 •C.G c.::-, C4:'l
..
1
1 ~
!
Claro
AmanUo NaranJaRoto
' 1 ~ Tema 'Pro· nodef yecto
Fuente: Pekka Abrahamsson. "Agite Software development methods: A minitutorial". VTT Technical Research Centre of Finland.
http://www. vtt.fi/virtual/agile/seminar2002/Abrahamsson_agile_met hods_minitutorial. pdf, 2002.
siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una unidad, (3) la iteración (nótese que
ce
requiere múltiples entregas por proyecto pero no muchas iteraciones por entrega), (4) la semana laboral, (5) el período de integración, de 30 minutos a tres días, (6) el día de trabajo, (7) el episodio de desarrollo de una sección de código, de pocos minutos a pocas horas. Ver Figura NO 08.Figura N° 08. Ciclos de un proyecto Crystal Metodologies
:~~::.::::::::::.:mu.::ult!n
::: :::
<::-:::.:: .:
:'~::::::
:::::::
¡
. .
. . .
.
.int~ón
in!gmciln
iñgr~iónintegmón
. :
:
: :. : '
dm
día
~a ~
~ía
día
día
f.tia
::·:
~
--
r-r-F
~ ;p~r;;¡r
~r,;r
;¡¡;: .
;¡¡;: . .
~ ~IC
·n
~de ~
tk . de
d<de
de i R
D~de ~
ck
i
~
.k
~
de
~
Oit'CR ·
-Fuente: Pekka Abrahamsson. "Agile Software development methods: A minitutorial". VTT Technical Research Centre of Finland.
http://wwN.vtt.fi/virtuallagile/seminar2002/Abrahamsson_agile_met hods_minitutorial. pdf, 2002.
Cockburn subraya que interpretar no linealmente un modelo de ciclos es difícil; la mente se resiste a hacerlo. Él mismo asegura que estuvo diez años tratando de explicar el uso de un proceso cíclico y sólo recientemente ha logrado intuir cómo hacerlo. La figura muestra los ciclos y las actividades conectadas a ellos. Las letras denotan Chartering, planeamiento de iteración, reunión diaria de pie (standup), desarrollo, check-in, integración, taller de Reflexión, Entrega (Delivery), y empaquetado del proyecto (V\kapup).
2.1.2.3.1. DYNAMIC SYSTEMS DEVELOPMENT METHOD
(DSDM):
{Stapleton J., 1997] Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una Metodología RAD ( Rapid application development ) unificada. Sus principales características son: Iterativo e incremental y el equipo de desarrollo y usuarios trabajan juntos. Propone cinco fases: Estudio de viabilidad, estudio del negocio, modelado funcional, diseño y construcción y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación en todas sus fases.
En Febrero de 1995 DSDM Consortium liderado por Tony Mobbs, Jennifer Stapleton, gary Hosdon, Paul Herizlich y Peter Constable, publicó la 1 era. Versión de DSDM.
La versión actual es la 4.1 y es el método más usado en el Reino Unido y va extendiéndose por Europa y Estados Unidos.
La idea dominante detrás de DSDM es explícitamente inversa a la que se encuentra en otras partes, y al principio resulta contraria a la intuición; en lugar de ajustar tiempo y recursos para lograr cada funcionalidad, en esta Metodología tiempo y recursos se mantienen como constantes y se ajusta la funcionalidad de acuerdo con ello. Esto se expresa a través de reglas que se conocen como "reglas MoSCoW' por las iniciales de su estipulación en inglés. Las reglas se refieren a rasgos del requerimiento:
1. Must have: Debe tener. Son los requerimientos fundamentales del sistema, de estos, el subconjunto mínimo ha de ser satisfecho por
completo.
2. Should have: Debería tener. Son requerimientos importantes para los
que habrá una resolución en el corto plazo.
3. Could have: Podría tener. Podrían quedar fuera del sistema si no hay
4. Want to have but won't have this time around: Se desea que tenga, pero no lo tendrá esta vuelta. Son requerimientos valorados, pero pueden esperar.
MSDM consiste de cinco fases:
1. Estudio de viabilidad. 2. Estudio del negocio.
3. Iteración del modelo funcional. 4. Iteración de diseño y versión. 5. Implementación.
las últimas tres fases son iterativas e incrementales. De acuerdo con la iniciativa de mantener el tiempo constante, las iteraciones de DSDM son cajas de tiempo. la iteración acaba cuando el tiempo se consume. Se supone que al cabo de la iteración los resultados están garantizados. Una caja de tiempo puede durar de unos pocos días a unas pocas semanas.
A diferencia de otros AMs, DSDM ha desarrollado sistemáticamente el problema de su propia implantación en una empresa. El proceso de Examen de Salud (Health Check) de DSDM se divide en dos partes que se interrogan, sucesivamente, sobre la capacidad de una organización para adoptar el método y sobre la forma en que éste responde a las necesidades una vez que el proyecto está encaminado. Un Examen de Salud puede insumir entre tres días y un mes de trabajo de consultoría.
1. Estudio de factibilidad. Se evalúa el uso de DSDM o de otra Metodología
