70 Ind. data 13(2), 2010

SISTEMA E INFORMTICA

(1) Ing. Oscar Tinoco Gmez1(2) Ing. Pedro Pablo Rosales Lpez2

(3) Ing. Julio Salas Bacalla3

INTRODUCCIN

Avison y Fitzgerald (1995) nos presentan una defi nicin de las metodologas de desarrollo muy clara, destacando sus principa-les componentes, fases, herramientas y tcnicas. Una metodo-loga es una coleccin de procedimientos, tcnicas, herramien-tas y documentos auxiliares que ayudan a los desarrolladores de software en sus esfuerzos por implementar nuevos sistemas de informacin. Una metodologa esta formada por fases, cada una de las cuales se puede dividir en sub-fases, que guiarn a los desarrolladores de sistemas a elegir las tcnicas ms apro-piadas en cada momento del proyecto y tambin a planifi carlo, gestionarlo, controlarlo y evaluarlo.

Modelo de proceso

Segn Darniame (1999), un modelo de procesos es una repre-sentacin del mundo real, que captura el estado de actual de las actividades para guiar, reforzar o automatizar partes de la produccin de los procesos.

En el artculo de E. Georgiadou Software Process and Product Improvement: A Historical Perspective, nos hablan de los mode-los; V-Model, WModel, X-Model, RAD y Orientado a Objetos, sin embargo los ms conocidos son:

Modelo secuencial. Representado por metodologas tan famosas como Waterfall. Se inicia con un completo anlisis de los requisitos de los usuarios. En el siguiente paso, los programadores implementan el diseo y fi nalmente, el com-pletado y perfecto sistema es probado y enviado.

Desarrollo incremental. Su principal objetivo es reducir el tiempo de desarrollo, dividiendo el proyecto en intervalos incrementales superpuestos. Del mismo modo que con el modelo waterfall, todos los requisitos se analizan antes de empezar a desarrollar, sin embargo, los requisitos se dividen en incrementos independientemente funcionales.

Desarrollo iterativo. A diferencia del modelo incremental se centra ms en capturar mejor los requisitos cambiantes y la gestin de los riesgos. En el desarrollo iterativo se rompe el proyecto en iteraciones de diferente longitud, cada una de

1 Magster en Marketing y Turismo, Docente auxiliar FII UNMSM. E-mail: otinocog@gmail.com2 Egresado Maestra Ing Industrial UNMSM. E-mail: pprl@gmail.com3 Ingeniero Industrial, Profesor del departamento de Produccin y Gestin Industrial UNMSM.

E-mail: jasalasb@hotmail.com

Revista de la Facultad de Ingeniera Industrial 13(1): 70-74 (2010) UNMSMISSN: 1560-9146 (Impreso) / ISSN: 1810-9993 (Electrnico)

Criterios de seleccin de metodologas de desarrollo de software

RESUMEN

El desarrollo de software no es una tarea sencilla, por mucho tiempo esta labor se ha llevado adelante sin una metodologa defi nida. Al respecto algunos autores defi nen una metodologa como una colec-cin de procedimientos, tcnicas, herramientas y documentos auxiliares que ayudan a los desarrolla-dores de software en sus esfuerzos por implementar nuevos sistemas de informacin.

En las dos ltimas dcadas, respecto a estas meto-dologas de desarrollo de software se ha entablado un intenso debate entre dos grandes corrientes. Por un lado, las denominadas metodologas tradicio-nales, centradas en el control del proceso, con un riguroso seguimiento de las actividades involucra-das en ellas. Por otro lado, las metodologas giles, centradas en el factor humano, en la colaboracin y participacin del cliente en el proceso de desarrollo y a un incesante incremento de software con iteracio-nes muy cortas.

El artculo presenta una propuesta, en medio de este debate, para seleccionar una metodologa de desa-rrollo de software.

Palabra clave: Seleccin metodologas; desarrollo software.

SELECTION CRITERIA OF METHODOLOGIES OF SOFTWARE DEVELOPMENT

ABSTRACT

In the last two decades, on these software develo-pment methodologies has been engaged in intense debate between two currents. On the one hand, the so-called traditional methods, focusing on process control, with rigorous monitoring of the activities in-volved in them. On the other hand, agile methods, focusing on human factors in collaboration and cus-tomer participation in the development process and a relentless increase in software with very short ite-rations.

The article presents a proposal, in the midst of this debate, to select a software development methodo-logy.

Keywords: Selection methodologies; development software.

Recibido: 19/11/10 Aceptado: 14/12/10

71

SISTEMA E INFORMTICA

OSCAR TINOCO GMEZ / PEDRO ROSALES / JULIO SALAS

Ind. data 13(2), 2010

ellas produciendo un producto completo y entre-gable.

Modelo en espiral. Comprende las mejores ca-ractersticas de ciclo de vida clsico y el proto-tipado (desarrollo iterativo). Adems, incluye el anlisis de alternativas, identifi cacin y reduc-cin de riesgos.

MARCO CONCEPTUAL

Dijkstra, con un infl uyente artculo (Go to statement considered harmful), sienta las bases para la crea-cin de las metodologas, como las conocemos ahora.

Entre otros autores se establecieron unos criterios que marcasen el xito del desarrollo del software, que hasta ahora estn vigentes:

El coste del desarrollo inicial debe ser relativa-mente bajo.

El software debe ser fcil de mantener.

El software debe de ser portable a nuevo hard-ware.

El software debe hacer lo que el cliente quiere.

A partir de que Dijkstra plantear su programacin estructurada (a travs de su libro A Discipline of Programming), empezaron a surgir lenguajes de programacin infl uenciados por este, que respeta-ban los siguientes criterios:

Desarrollo de programas mediante top-down, en contraposicin a bottom-up.

Utilizar un conjunto especfi co de reglas de pro-gramacin (Prohibido el uso de Go To).

Seguir un conjunto de pasos formales para descomponer los problemas grandes (divide y vencers).

Metodologas tradicionales y Metodologas agi-les

Diversos autores coinciden en sealar algunos re-quisitos que deben tener las metodologas de de-sarrollo:

Visin del producto.

Vinculacin con el cliente.

Establecer un modelo de ciclo de vida.

Gestin de los requisitos.

Plan de desarrollo.

Integracin del proyecto.

Medidas de progreso del proyecto.

Mtricas para evaluar la calidad.

Maneras de medir el riesgo.

Como gestionar los cambios.

Establecer una lnea de meta.

En tiempos recientes, han surgido las metodolo-gas giles, como una alternativa, una reaccin a las metodologas tradicionales y principalmente a su burocracia. Brooks, en su mtico libro The Mythi-cal Man Month, expone las primeras ideas que se plantean en las metodologas giles, gran parte de ellas, responden al sentido comn.

Cans, J. (2005) resume las caractersticas de am-bas metodologas, en la siguiente tabla:

Tabla 1. Comparacin de metodologas.

Metodologas giles Metodologas tradicionales

Se basan en heursticas provenientes de prcticas de produccin de cdigo

Se basan en normas provenientes de estndares seguidos por el entorno de desarrollo

Preparados para cambios durante el proyecto Cierta resistencia a los cambios

Impuestas internamente por el equipo Impuestas externamente

Proceso menos controlado, con pocos principios Proceso muy controlado, numerosas normas

Contrato flexible e incluso inexistente Contrato prefijado

El cliente es parte del desarrollo Cliente interacta con el equipo de desarrollo mediante reuniones

Grupos pequeos (

72

SISTEMA E INFORMTICA

CRITERIOS DE SELECCIN DE METODOLOGAS DE DESARROLLO DE SOFTWARE

Ind. data 13(2), 2010

Entre las metodologas giles, se puede mencionar a las siguientes:

Adaptative Software Development

Agile Modeling

Agile Model Driven Development

Agile Project Management

Agile Unifi ed Process

Crystal Methods

Dynamic Systems development methods

Feature driven development

Internet Speed Development

Lean development

Pragmatic programming

Scrum

Test Driven Development

XBreed

Extreme Programming

Win Win Spiral

Evolutionary Project Management

Story cards driven development

Agile Unifi ed Process

Open Unifi ed Process

Seleccin de metodologas giles, por criterios de presencia

Los diseadores de software tienen inters de tra-bajar con metodologas lo sufi cientemente docu-mentadas, que nos faciliten la obtencin de infor-macin, pero tambin es interesante trabajar con metodologas que dispongan de algn tipo de cer-tifi cacin y training. Segn estas condiciones, he-mos determinado seis clasifi caciones que permiten seleccionar una metodologa, segn se encuentran mejor posicionadas, en el acumulado fi nal.

Las clasifi caciones son:

La metodologa con mayor presencia en Inter-net.

La metodologa mejor documentada.

Metodologas certifi cadas y con training.

Metodologas con comunidades.

Metodologa ms utilizada por empresas. Pre-sencia empresarial.

Metodologa ms utilizada en proyectos soft-ware.

Se considera como metodologas certifi cadas aquellas que emiten un certifi cado que aseguran el cumplimiento y seguimiento de la metodologa, as como sus tcnicas y prcticas.

Una metodologa dispone de training, si se en-cuentra alguna institucin, organizacin o compa-a que ofrezca formacin de la metodologa.

Se considera que una metodologa tiene comuni-dad, contemplando si se ha formado una comuni-dad relevante o si est asociada a la Agile Alliance, soportndola y cumpliendo sus principios.

Se consideran los proyectos realizados, en su ma-yora por metodologas que se han aplicado en empresas privadas y por lo tanto no existe mucha documentacin pblica al respecto. Por lo tanto, determinar esta clasifi cacin, requiere de una bs-queda exhaustiva.

Seleccin de metodologas

Este aspecto no ha sido tratado de manera ade-cuada, sobre todo en el mbito de las metodologas tradicionales, y en el caso de las giles no existe un criterio unifi cado. Por ello, el presente artculo se orienta a la formulacin inicial, en base a la in-formacin existente a la fecha y a la experiencia personal, a la formulacin de dos procedimientos al respecto: seleccin por criterios de presencia y por conocimiento.

Aplicacin del criterio de seleccin por presen-cia

A un grupo de programadores profesionales en el medio local (10), se le ha aplicado una encuesta, sobre recordacin, conocimiento y uso de metodo-logas, quedando un grupo de 5 metodologas, que se han evaluado, segn este criterio de seleccin.

Para determinar la presencia, de las metodologas en Internet, se han realizado bsquedas en Google, Yahoo y Live. Sobre el resultado, se asignaron 5 puntos al mayor, y 1 punto al menor.

Para determinar las metodologas de mayor docu-mentacin, se han considerado como documentos, los Libros en espaol, Libros en ingls y Papers que hablen sobre la aplicacin de la metodologa. Siguiendo el mismo mtodo, se asign 5 puntos al mayor y 1 punto al menor.

En el caso de la Certifi cacin y Training, se ha buscado si hay instituciones que certifi can la

73

SISTEMA E INFORMTICA

OSCAR TINOCO GMEZ / PEDRO ROSALES / JULIO SALAS

Ind. data 13(2), 2010

implementacin de la metodologa, as como si hay entrenamiento o capacitacin en la misma. Como no es posible hacer diferencias en cuanto a la certifi cacin, habindose asignado el mismo puntaje a las metodologas que tienen Certifi cacin y Training (5 puntos) y 3 puntos las metodologas que contienen slo training.

En cuanto a Comunidades, la mayora pertenece a la Agile alliance, pero hay algunas que tienen sus propias comunidades, alianzas e intensa actividad a su alrededor. A estas metodologas se le asigna-ron 5 puntos, porque no es posible diferenciar entre estas comunidades el nmero de miembro. A las metodologas que solo pertenecen a la Agile allian-ce, se le asignaron 2 puntos.

En cuanto a proyectos de software y presencia em-presarial, se han asignado 5 puntos, a la metodolo-ga que presenta ms proyectos y un punto a la que presenta menos.

Resultado de la aplicacin del criterio de selec-cin por presencia

Se ha preparado un cuadro resumen con los re-sultados de la seleccin. Para cada metodologa evaluada, se ha colocado la puntuacin que se ha obtenido de la clasifi cacin. La sumatoria de cada clasifi cacin determina que Scrum, es la metodolo-ga que se debera usar, por tener una mejor pun-tuacin.

MetodologaMayor

presenciaen Internet

Mejordocumentacin

Certificadasy con training Comunidades

Presenciaempresarial

Proyectosde software Total

Agile Project Management (APM) 2 1 3 5 1 1 11

Dynamic Systems development methods (DSDM) 1 3 5 5 4 4 22

Scrum 5 2 5 5 5 5 27

Test Driven Development 3 4 3 2 2 2 16

Extreme Programming (XP) 4 5 3 2 3 3 19

Total 15 15 19 19 15 15 95

Seleccin de metodologa, por criterios de co-nocimientos

En funcin del grupo de trabajo o de diseo, se consideran los siguientes criterios en funcin de los conocimientos que el equipo de desarrollo tenga de las metodologas a evaluar. Estos criterios son:

Grado de conocimiento

Soporte orientado a objetos

Adaptable a cambios

Basado en casos de uso

Posee documentacin adecuada

Facilita la integracin entre las etapas de de-sarrollo

Relacin con UML

Permite desarrollo software sobre cualquier tecnologa

En funcin de los conocimientos que el equipo ten-ga, se establecen los pesos para cada criterio. Por ejemplo, Ros y Suntaxi [37], en su tesis de grado, proponen la siguiente tablas de pesos:

20% para el Grado de conocimiento

15% para Adaptable a cambios y Posee docu-mentacin adecuada

10% para el resto de criterios

Para determinar la metodologa a usar, Ros y Sun-taxi, han elaborado un cuadro resumen, evaluando las siguientes metodologas:

RUP, Rational Unifi ed Process

MSF, Microsoft Solution Framework

RAD, Rapid Application Development

XP, Extreme Programming

En esta evaluacin, la metodologa RUP es la que recibe un mayor puntaje por parte del equipo de de-sarrollo.

Tabla 2

74

SISTEMA E INFORMTICA

CRITERIOS DE SELECCIN DE METODOLOGAS DE DESARROLLO DE SOFTWARE

Ind. data 13(2), 2010

Criterio % RUP MSF RAD XP Total

Grado de conocimiento 20 15 10 10 10 45

Soporte orientado a objetos 10 10 10 10 10 40

Adaptable a cambios 15 10 15 10 15 50

Basado en casos de uso 10 10 5 10 5 30

Posee documentacin adecuada 15 15 15 15 10 55

Facilita la integracin entre las etapas de desarrollo 10 10 10 10 10 40

Relacin con UML 10 10 8 8 8 34

Permite desarrollo software sobre cualquier tecnologa 10 10 10 10 10 40

Total 100 90 83 83 78

CONCLUSIONES

En algunas tesis revisadas, el criterio de seleccin de la metodologa, es bastante subjetivo. Por ello se ha buscado de establecer una escala ordinal de valoracin de la importancia de los criterios de se-leccin, hecho que contribuye a una mejora en el proceso de seleccin pero que no desaparece el nivel de subjetividad inherente al proceso

En tal sentido, los autores se comprometen, en un prximo artculo, a enfocar el problema desde el punto de vista del proceso analtico jerrquico.

REFERENCIAS BIBLIOGRFICAS

[1] Avison, D. and G. Fitzgerald, (1995). Informa-tion Systems Development: Methodologies, Techniques, and Tools. McGraw-Hill.

[2] Brooks, Fred (1995). The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Ed. Addison Wesley. 2da edition.

[3] Cans, Joseph (2005). Mtodologas giles en el Desarrollo de Software. Universidad Politc-nica de Valencia.

[4] Derniame, J (1999). Software Process: Prin-ciples, Methodology, Technology. Lecture No-tes in Computer Science 1500 Springer 1999, ISBN 3-540-65516-6 BibTeX

[5] Dijkstra E (1976). A Discipline of Programming. Prentice Hall, Universidad de Texas.

[6] Georgiadou, E. (2003) Software Proces And Product Improvement: A Historical Perspec-tive. Cybernetics and Systems Analysis. Vol. 39, N. 1 2003.

[7] Ros, Edgar y Wilson Suntaxi (2008). Desarro-llo de un sistema informtico para los procesos de cosecha y post cosecha de la camaronera Pampas de Cayanca. Tesis de grado, Facultad de ingeniera de sistemas, Escuela Politcnica Nacional, Quito.

Tabla 3