metodos de desarrollo de software: el desafio · este estilo de desarrollo de software, pero tambi...

Theoria

ISSN: 0717-196X

[email protected]

Universidad del Bío Bío

Chile

Gacitúa Bustos, Ricardo A.

Métodos de desarrollo de software: El desafío pendiente de la estandarización. Software

Development Methodologies: A Duel Pending for Standardization

Theoria, vol. 12, núm. 1, 2003, pp. 23-42

Universidad del Bío Bío

Chillán, Chile

Disponible en: http://www.redalyc.org/articulo.oa?id=29901203

Cómo citar el artículo

Número completo

Más información del artículo

Página de la revista en redalyc.org

Sistema de Información Científica

Red de Revistas Científicas de América Latina, el Caribe, España y Portugal

Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto

http://www.redalyc.org/revista.oa?id=299

http://www.redalyc.org/articulo.oa?id=29901203

http://www.redalyc.org/comocitar.oa?id=29901203

http://www.redalyc.org/fasciculo.oa?id=299&numero=1103

http://www.redalyc.org/articulo.oa?id=29901203

http://www.redalyc.org/revista.oa?id=299

http://www.redalyc.org

23

METODOS DE DESARROLLO DE SOFTWARE: EL DESAFIOPENDIENTE DE LA ESTANDARIZACION

SOFTWARE DEVELOPMENT METHODOLOGIES:A DUEL PENDING FOR STANDARDIZATION

RICARDO A. GACITÚA BUSTOS

Depto. Sistemas de Información, Facultad de Ciencias Empresariales, Universidad del Bío-Bío, Avda. Collao 1202,Concepción, Chile, e-mail: [email protected]

RESUMEN

Este artículo describe la evolución de los métodos de desarrollo de software. El foco está centrado en eldesacuerdo en cómo debe crearse el software. El tema es como se considera el desarrollo de software: como unproceso de ingeniería o un proceso centrado en las personas. Se presenta el lenguaje de modelamiento unifi-cado (UML) como una notación estándar del desarrollo de software. Actualmente es considerado como basepara una metodología monumental (que incluye muchas reglas y prácticas) – RUP. Se menciona la reaccióna las metodologías monumentales: los métodos ágiles. La cual es característica de un estado inmaduro deldesarrollo de software como una disciplina. No solo hay desacuerdo en terminologías, enfoques y detalles dediferentes métodos, sino incluso en un esquema de clasificación común. La siguiente estructura está basadaen la evolución de los principales conceptos y las distinciones claves que reflejan los cambios de paradigmasen la filosofía de métodos.

PALABRAS CLAVES: Métodos de desarrollo de software, metodología, UML, métodos ágiles.

ABSTRACT

This paper describes the evolution of software development methods. The focus is the disagreement abouthow programmers must make software. The issue is: How is software development considered as a engineeringprocess or as a human centered process. Unified Model Language (UML) is considered as a standard notationfor software development. At present, UML is considered as basis for a Monumental Methodology (whichinclude a lot of rules and practices) - RUP. We mentioned the reactions to these Monumental methodologies:The Agile Methodologies. Which is characteristic of an immature state of software development as a discipli-ne. There is not only disagreements in terminology, approach, and details of different methods, there is noteven a commonly accepted classification scheme. The following structure is based on the evolution of theunderlying concepts and the key distinctions that reflects the paradigmatic shifts the philosophy of methods.

KEYWORDS: Sofware development methodologies, methodology, UML, agiles methodologies.

Recibido: 05/05/2003 Aceptado: 24/10/2003

1. INTRODUCCION

El año 1994 un estudio dirigido por el StandishGroup (The Standish Group, 2000; Jonson,1994 y Jonson, 1995) –organización de pres-tigio mundial– analizó a más de 350 em-

presas norteamericanas y 8.000 proyectosde desarrollo de software. Dicho estudioarrojó que sólo el 16,2% de los proyectosen pequeñas compañías y el 9% en grandescompañías, finalizaban dentro de los costosy de los plazos establecidos, el 52,7 % de

Theoria, Vol. 12: 23-42, 2003 ISSN 0717-196X

24

Theoria, Vol. 12: 2003

los proyectos finalizaba excedido amplia-mente en el presupuesto (sobre el 189 %) ycon grandes retrasos de tiempo (sobre 122%),además de ofrecer menores características yfuncionalidad de las que originalmente sehabía especificado. Finalmente, el 31,1% res-tante simplemente se cancelaba (81 billonesde dólares botados). El estudio, en general,demostró la existencia de problemas serios decostos asociados al desarrollo de software porconcepto de retrasos, presupuestos excedidosy, sobre todo, por la no-implementación detoda la funcionalidad especificada que, almenos, eso es lo que se espera de un proyec-to de desarrollo de software. Lo anteriormuestra que el desarrollo de software no sólono ha logrado estándares de calidad acepta-bles –todo problema ocurrido en el sistemaoperativo Windows se resuelve reiniciandoel computador y nadie cuestiona la falta detolerancia a fallas del producto– sino quedemostró empíricamente lo que todo pro-gramador de aplicaciones de software sabe:que el desarrollo de software es una activi-dad caótica a menudo caracterizada por lafrase “programar y luego ajustar” (equiva-lente a construir un edificio y posteriormen-te, una vez construido, repararlo). En gene-ral el software es escrito sin un plan delinea-do para su construcción y el diseño de éste es“reparado” a partir de muchas decisiones decorto plazo, lo que demuestra que en generalexiste una falta de sistematización para cons-truirlo. Esta forma de trabajo funciona biencuando el sistema es pequeño pero, como elsoftware debe ser ampliado y ajustado a nue-vas condiciones, comienza a ser más difícilagregarle nuevas características. Además, loserrores comienzan incrementalmente a pre-valecer y a incrementar la dificultad de ajus-tarlo.

Para muchos usuarios no relacionadoscon el desarrollo de software la situaciónanterior no es visible, pues sólo se percibe lafuncionalidad en el ámbito de interfaz y deresultados pero se desconoce cómo ha sido

diseñado o cuál es la estructura a la que res-ponde; mucho menos se conoce la cantidadde recursos utilizados, ni la innumerable can-tidad de problemas que se ha debido enfren-tar para presentar este producto de software.En este sentido, es común encontrar mu-chos productos de software carentes de di-seño formal y entendido sólo por quien loha construido, sin documentación, escritoen lenguajes obsoletos, sin posibilidad de in-corporar nuevos requisitos, con resultadosno confiables, entre numerosos otros facto-res, que redundan finalmente en muchosproblemas, tales como, por ejemplo, la im-posibilidad de mantenerlo y adecuarlo anuevos requisitos o condiciones de opera-ción o asegurar la exactitud de los resulta-dos, entre otros. Es decir, como se dice enChile, un producto sostenido por“alambritos”.

Quizás lo anterior pareciera ser poco re-levante, pero si consideramos que hoy tene-mos software en casi toda la actividad hu-mana, desde simples dispositivos electróni-cos hasta modernas naves aerospaciales ycontrol de vuelo –pasando incluso por soft-ware de control de procesos de salud huma-na–, es fundamental hacer prevalecer la re-ducción de riesgos por concepto de pérdi-das económicas, de fallas en determinadasáreas y, lo más importante, reducir el riesgode pérdidas de vidas humanas.

Hemos vivido durante largo tiempo coneste estilo de desarrollo de software, perotambién se ha tenido una alternativa por ungran tiempo: métodos de desarrollo de soft-ware.

Un método, comúnmente llamado me-todología, impone un proceso disciplinadosobre el desarrollo de software con el objeti-vo de hacer el desarrollo de software máspredecible y eficiente. Por tanto, se planteaque un método define un camino reprodu-cible para obtener resultados confiables.

Todas las actividades basadas en conoci-miento utilizan métodos que varían en so-

25

fisticación y formalidad. Los cocineros seguían de recetas, los pilotos de avión a tra-vés de listas de chequeo antes de volar, losarquitectos utilizan planos y los músicos si-guen reglas de composición. Similarmenteun método de desarrollo de software descri-be cómo modelar y construir un sistema desoftware de una forma confiable y reprodu-cible. En general, los métodos permiten laconstrucción de modelos desde elementosde modelado que constituyen los conceptosfundamentales para representar sistemas ofenómenos. Las escala de notas musicales esel elemento del modelo para la música. Elenfoque de orientación a objeto para el de-sarrollo de software propone el equivalentea las notas –los objetos– para describir el soft-ware, para un enfoque funcional los elemen-tos del modelado son las funciones del siste-ma.

Los métodos también definen una repre-sentación –a menudo gráfica– que permitefacilitar la manipulación de modelos, y lacomunicación e intercambio de informaciónentre todas las partes involucradas. Una bue-na representación busca un balance entre ladensidad de información y la legibilidad.

En relación con los elementos del mode-lo y su representación gráfica, un métododefine las reglas que describen la resoluciónde los diferentes puntos de vista, el orden delas tareas y la asignación de responsabilida-des. Estas reglas definen un proceso que ase-gura armonía dentro de un grupo de ele-mentos cooperativos y explican cómo debe-ría ser usado el método. A medida que pasael tiempo, los usuarios de un método desa-rrollan un cierto “know-how”, así como dela forma en que debería ser usado. Esteknow-how, también llamado experiencia, nosiempre está claramente formulado y nosiempre es fácilmente traspasado.

El objetivo ideal, por tanto, es desarro-llar un proceso de desarrollo detallado y conun fuerte énfasis en la planificación, inspi-rado por otras disciplinas de la ingeniería.

Sin embargo, aun cuando han estado ron-dando por mucho tiempo, ellos no se desta-can por su éxito ni por su popularidad. Sinembargo, en el caso del desarrollo de soft-ware esto es discutible. Un estudio reciente(Nandhakumar and Avison, 1999) argu-menta que los métodos de desarrollo paralos sistemas de información tradicional (IS)“son tratados principalmente como una fic-ción necesaria para presentar una imagen decontrol o proporcionar un status simbóli-co”. El mismo estudio argumentaba que es-tas metodologías son muy mecánicas paraser usadas en detalle. Parnas y Clement (1986)habían mencionado los mismos argumentosanteriormente. El año 2000, Truex (Truexet al., 2000) tomó una posición extrema di-ciendo que es posible que los métodos tra-dicionales son “meramente ideas insosteni-bles para hombres hipotéticos, proporcio-nando guías normadas para situaciones dedesarrollo utópicas”. Como resultado, los de-sarrolladores de software industrial han co-menzado a ser escépticos acerca de las nuevassoluciones que son difíciles de contagiar y,además, no son utilizadas (Wiegers, 1998).

2. LA HISTORIA DE LOS METODOSDE DESARROLLO DE SOFTWARE

2.1. Hacia una disciplina de programación

2.1.1. La indisciplina

Quizás para muchos es desconocido el he-cho que las primeras actividades de “progra-mación” consistían en dar vuelta diversosswitch de control eléctrico, sobre la consolade un computador enorme, lo que permitíaconfigurar una secuencia numérica de ins-trucciones, tal cual se muestra en la figura1. El uso de los lenguajes de “alto-nivel” (coninstrucciones nemotécnicas) sólo comenzóen los años 50 (Fortran y Cobol fueron losmás populares de éstos) y, el hecho que és-

Métodos de desarrollo de software: El desafio pendiente... / RICARDO A. GACITÚA B.

26


tos existieran, fue considerado un gran lo-gro. Los programadores no pensaban mu-cho acerca del “estilo de programación”. Porsu parte, dado el limitado tamaño y veloci-dad de los primeros computadores, el granproblema de los programadores era cómoescribir código que fuera pequeño (pocas lí-neas de código) y eficiente en el uso de re-cursos (uso del espacio de memoria, tiempode respuesta, etc.). Los compiladores a me-nudo no eran muy buenos, así que los pro-gramadores se enorgullecían de conocer tru-cos de cómo burlar el compilador para ge-nerar el mejor código posible.

nificó que el costo del desarrollo de softwarepodría exceder el costo del hardware sobreel cual se ejecutaba. Por tanto, comienza aponerse en evidencia un nuevo conjunto decriterios para medir el éxito del desarrollode software. Estos criterios se mantienenincluso hoy. Un proyecto es juzgado comoexitoso si el código producido:

– Tiene un costo relativamente bajo de de-sarrollo inicial.

– Es fácilmente mantenible.– Es portable a un nuevo hardware.– Cumple los requisitos del cliente, esto es,

hace el trabajo que el cliente desea.– Satisface criterios de calidad (seguridad,

fiabilidad, etc.).

Mientras los lenguajes de alto nivel eranmuy populares en 1968, no existían reglaspara guiar a los programadores sobre el cómoescribir código que satisfaciera estos crite-rios. En efecto, en los primeros días, la pro-gramación se veía como un “arte” y los pro-gramadores se centraban en escribir códigoque fuera rápido y pequeño, y se aprendía eloficio de programador normalmente porprueba y error –tal cual ocurre aún en estosdías–. En resumen, el mundo del softwareera virtualmente indisciplinado y muchosaprendices de entonces lo adoraban, puesparecería ser una actividad sumamente di-vertida.

2.1.2. Programación estructurada

En 1968 el profesor Edsger Dijkstra publicóuna influyente carta al editor en la revista es-pecializada Communication of the Associationfor Computing Machinery (CACM) llamada“Go to Statement Considered Harmful”(“La sentencia Go To se considera perjudi-cial”). Dijkstra era un académico quien veíaa la ciencia de la computación como una ramade la matemática aplicada. Los programa-

FIGURA 1. Programando en los años 40.

En 1968 los mini-computadores comen-zaron a ser populares y, gracias al desarrollode grandes compañías de computadores, losprogramadores comienzan a entender la Leyde Moore –“La densidad de los chips se do-bla cada año”–, lo que había comenzado en1964. Esto significaba que los computado-res comenzaban a ser más grandes, más rá-pidos, el tamaño del programa y la veloci-dad dejaron de ser los principales criteriospara medir la efectividad de los programasde computador. La aparición del popularsistema IBM /360 y la amplia variedad delenguajes de programación de alto nivel im-plicó que los programas de computador erandurables y permanecían en el tiempo. Lapermanente baja del costo del hardware sig-

27

dores de computadores, parecidos a otrosingenieros, deberían aplicar métodos mate-máticos formales para crear programas efec-tivos y deben ser sometidos a pruebas for-males. Dijkstra argumentaba que este cons-tructor implementado en los lenguajes deprogramación de alto nivel (“go to”: saltosin condición a otra sentencia en un progra-ma de computador) era una abominación yllevaba a programas incorrectos, que no per-mitían pruebas formales. Las ideas de Dijkstraformaron las bases de la “programación es-tructurada”, lo cual se constituyó en el pri-mer método de desarrollo de software.

Básicamente, la programación estructu-rada se abocaba a:

– Desarrollar programas Top-Down (comoopuesto a Bottom Up)

– Usar un conjunto específico de construc-tores formales de programación –secuen-cia, selección e iteración– (El “go to” eradesterrado). Esto establecía que cualquierprograma de computador podía ser cons-

truido sólo sobre la base de estos tres cons-tructores.

– Seguir algunos pasos formales para des-componer grandes problemas.

Siguiendo esta metodología, se argumen-taba, se aseguraría a los programadores sa-tisfacer los criterios de éxito del software,enumerados anteriormente. Paralelamente,comienza a surgir un sinnúmero de concep-tos que pretendían facilitar la conceptuali-zación de los programas de computadoresque se construían, entre ellos conceptos ta-les como: Programación modular, Refina-miento sucesivo, Information Hiding [19],entre otros. Como complemento, variadasson las notaciones que se proponen paramodelar la estructura de los programas decomputador (comúnmente denominada ló-gica de detalle) y que, en su mayoría, reco-gen la propuesta de Dijkstra. Entre las másconocidas se cuentan: Diagramas de flujos(Flowchart), Diagramas N-S, Pseucódigo,Tablas de decisión, Arboles de decisión, en-tre otros.

FIGURA 2. Ejemplo de notaciones para representar estructura de programas: a) Flowchart; b) DiagramasN-S, y c) Diagramas N-S con Pseudocódigo.

En 1971 el profesor Niklaus Wirth lanzóel lenguaje de programación Pascal, el cualno proporcionaba la sentencia “go to” y te-nía las estructuras de control que implemen-taban el paradigma de la programación es-tructurada de Dijkstra. Posteriormente to-

dos los lenguajes de programación habíansido influenciados por las ideas de Wirth yDijkstra de crear programas bien estructu-rados y fáciles de leer. Sin embargo, fuertesdetractores a las ideas de Dijkstra comienzana surgir, y se origina un debate que se mantie-


a) b) c)

28


ne hasta el día de hoy. Uno de los principaleshitos fue marcado en 1974, cuando el profe-sor Donald Knuth, máximo opositor, publi-ca un libro The Art of Computer Programming,que escribió programas estructurados queincluían sentencias “go to” en The ACM’sComputing Survey. Lo cierto es que en esetiempo se comenzó a hablar de una “guerrareligiosa” entre los devotos de Dijkstra y losdevotos de Knuth.

2.1.3. Diseño y análisis estructurado

La influencia de Dijkstra no paró con el grandebate del “go to”. Las ideas de la progra-mación estructurada se llevaron al ámbitode diseño y análisis estructurado. De hechonació una nueva disciplina: Ingeniería desoftware. Los supuestos básicos detrás delanálisis estructurado eran lograr obtenermayor control intelectual sobre el crecienteaumento de la complejidad de los sistemas,utilizando como base el concepto de descom-posición funcional propuesto por Hamiltony Zeldin (1979), sobre la base de los siguien-tes supuestos:

– Un modelo conceptual común para des-cribir todos los problemas,

– Un conjunto de procedimientos para su-gerir la dirección general del análisis y or-denado por pasos,

– Un conjunto de guías de acción o decisio-nes soportadas en heurísticas acerca delproblema y su especificación y,

– Un conjunto de criterios para evaluar lacalidad del producto.

Surgen, pues, varios métodos denomina-dos genéricamente como métodos SA/SD(Structured Análisis / Structured Design),los que incluyen una variedad de notacio-nes para la especificación formal de software.Durante la fase de análisis, muchas notacio-nes, entre ellas diagramas de flujo de datos,

especificación de procesos, diccionario dedatos, diagramas de transición de estados ydiagramas de entidad-relación, entre otros,son usados para describir lógicamente el sis-tema, tal cual se presenta en las figuras 3, 4y 5.

La mayor parte de los métodos propues-tos en esta época se denominaban, además,métodos funcionales debido a que eran ins-pirados directamente por la arquitectura decomputadores (un dominio probado bienconocido de los programadores de la com-putación). La separación de datos y código,tal como existía físicamente en el hardware,fue trasladada a los métodos; por tanto losprogramadores tendían a pensar en térmi-nos de funciones de sistemas. En este senti-do, diversas propuestas para modelar datosy modelar procesos y/o funciones son defi-nidas; entre las principales se cuentan: SA/SD- Ed. Yourdon & DeMarco (Yourdon,1989), SA/SD- Gane & Sarson (1979), JSD-Jackson Structured Development (Jackson,1983), Information Engineering (Martín,1990), Warnier (1974), entre otros. En lamisma época, las exigencias de la defensa na-cional y las aplicaciones aero-espaciales re-sultan en una alta demanda por softwarecomplejo y de misión crítica. Los desarro-lladores responden creando una variedad deenfoques de dominio-específico a través dela adaptación del análisis estructurado parasoportar especificaciones de sistemas de con-trol embebidos (insertos dentro de compo-nentes electrónicos), agregando notacionespara capturar el control de comportamien-to. Estas variaciones son conocidas comoAnálisis / Real-Time (SA/RT). Uno de lostrabajos realizados para la armada de USA,en el sistema de defensa de mísiles, produjoel método SREM (Software RequirementEngineering Method) (Alford, 1977), ymuchas otras variaciones que han sido des-critas por Ward and Mellor (1986) y Hatley& Pirbhai (1987).

29

Al igual que el modelamiento de proce-sos de transformación de datos, surge confuerza la necesidad de modelar semántica-

mente los datos, para lo cual también sur-gen numerosas propuestas, entre ellas las deChen (1976) y Codd (1976).

FIGURA 3. Ejemplo de notaciones para análisis estructurado –modelado de procesos–: a) Diagrama de flujode datos - Método Yourdon & DeMarco; b) Diagrama de flujo de datos - Método SSADM; c) Diagramade flujo de datos - Método Gane & Sarson.

FIGURA 4. Ejemplo de notaciones para análisis estructurado - modelamiento semántico de datos-: a) Diagramaentidad-relación, Peter Chen; b) Diagrama modelo de datos, SSADM.

La necesidad de diseño surge del hechode modelar la estructura de la solución quese había de proponer para un determinadoproblema. En la fase de diseño, se agregan

detalles a los modelos de análisis y los diagra-mas de flujo de datos son convertidos encartas de estructura y descripciones de códi-go de lenguajes de programación.


a) b) c)

a) b)

30


El desarrollo de software era visto comoun proceso industrial. Muchos métodos fue-ron desarrollados y éstos proporcionabanuna serie de guías, reglas detalladas y regula-ciones para el proceso de desarrollo de soft-ware. Dijkstra volvió al mundo de la acade-mia, pero el liderazgo de la “guerra religio-sa” fue tomado por personas tales comoEdward Yourdon, Peter Coad, James Martin,y Tom DeMarco, quienes hasta el día de hoypermanecen activos. Cada uno de ellos, aveces solos, a veces en parejas, establecieronvalores (también conocidos como grupos deconsultoría). Se publicaron biblias, muchossermones fueron escritos y aclamados. Ellosprometían que, si incluso los programado-res perezosos y buenos para nada, seguíansu disciplina (como opuesto a los competi-dores charlatanes), entonces el desarrollo desoftware debería ser lejos menos costoso, elcódigo debería ser fácil de mantener y por-table, y los clientes deberían estar emocio-nados y deslumbrados con los resultados.

2.2. Brooks y el Mítico Hombre-Mes

En 1975, cuando la denominada “guerra delos métodos de Ingeniería de Software” es-taba en la cima (denominada así, dada laenorme cantidad de métodos propuestos connotaciones y procesos diferentes, tratandode imponerse unos sobre otros), Fred Brookspublicó su famoso libro The Mythical Man-Month (El Mítico Hombre-Mes, en alusióndirecta a la unidad de medida de esfuerzode Horas-Hombre, Hombre-Mes, etc.). Dis-tinto al académico Dijkstra y sus seguidoresconsultores, Brook aprendía su lección acercadel desarrollo de software cuando él era eladministrador del probablemente primerproyecto emprendido de desarrollo de soft-ware de gran escala –el desarrollo del siste-ma operativo IBM/360 (OS/360) a iniciode los años 60. El centro del mensaje deBrooks es que el desarrollo de software esun proceso centrado en el ser humano, y nouna disciplina de ingeniería. Atendiendo a

FIGURA 5. Ejemplo de notaciones para diseño estructurado: a) carta de estructura; b) método JSD, diagramasWarnier.

a) b)

31

los innumerables problemas y fracasos deldesarrollo de software sumado a una bajaproductividad de los programadores y unamala calidad de los productos de software,Brooks acuñó la frase hasta hoy usada: “Lacrisis del software”, aunque algunos planteanque se debería hablar de una “aflicción cró-nica”, pues las crisis tienen un punto alto yluego se resuelven, a diferencia de lo quesucede con el desarrollo de software. Su li-bro dispuso la primera metodología de de-sarrollo de software útil, porque el métodopresionaba por administrar procesos de per-sonas y no procesos de ingeniería.

2.2.1.Problemas claves de proyectos dedesarrollo de software, según Brooks

Brooks, en un estilo humorístico, identificalos muchos problemas que presentan losproyectos de software. Cualquiera que hayaestado involucrado en un proyecto de desa-rrollo de software los encontrará relevantesincluso hoy día.

1. La mina de alquitrán: “Los proyectos desoftware son quizás lo más intrincado ycomplejo de las cosas que hace la huma-nidad” (en términos de las distintas cla-ses de partes que lo componen). Esto esmás cierto hoy día en varias órdenes demagnitud, dado el aumento considerablede complejidad de las aplicaciones.

2. El Mítico Hombre-Mes: “Muchos proyec-tos fracasan más por pérdidas de tiempocalendario, que por todas las otras razo-nes combinadas”. Esta sentencia, que abreel libro de Brooks, es cierta hasta ahora.No se ha desarrollado hasta ahora unabuena forma de estimar cuánto tiempotomarán los proyectos de programación.La programación es un proceso creativosimilar al arte y la música. Los proyectosde programación son tentativas comer-

ciales. Esto lleva al corazón del problema:¿Cómo administramos exitosamente unproceso humano creativo (como opuestoa procesos mecánicos y productivos)?

3. La Ley de Brooks (la que exige ser validadapor investigaciones): “Agregar horas-hom-bre a un proyecto atrasado hace que se re-trase más”. Las personas y los tiempos noson intercambiables. Hay cierto procesosque no pueden ser apurados. Agregar máspersonas incrementa las intercomunica-ción y la sobrecarga en entrenamiento, tan-to como interrumpir el avance.

4. El Efecto del segundo sistema: “El segundoes el sistema más peligroso de una perso-na que sobre diseña; la tendencia generales a sobre diseñarlo”. En lenguaje moder-no debería llamarse “featuritis”.

5. ¿Por qué la Torre de Babel falla?: “Desas-tres de calendario, inadaptación funcio-nal y errores de sistema, todos crecen por-que la mano izquierda no sabe que estáhaciendo la mano derecha. Los equiposdefinen supuestos”. La comunicación esla parte más difícil de cualquier empren-dimiento humano. Esto, por supuesto, esel centro del Mítico Hombre-Mes.

6. Un paso adelante y un paso atrás: “Laentropía del sistema crece en el tiempo”.Esto también es conocido como “Pedazosde tonterías”. Reparar tiende a destruir es-tructuras e incrementar el desorden.

2.2.2. El Impacto del Mítico Hombre-Mes

Junto al crecimiento de los problemas en eldesarrollo de software, el libro ofrece algu-nas soluciones importantes que, cuando sontomadas juntas, proporcionan un métodouniversal para el desarrollo de software. Sinembargo, The Mythical Man-Month, a dife-rencia de la programación estructurada, noformó las bases de ninguna metodología pro-movida por algún gurú en los años 70 u 80.


32


Quizás, porque Brooks se orientaba a unacarrera académica y no se definía como gurúpara realizar consultorías. Mientras el librofue de una importancia increíble, no fuehasta finales de los años 90 que las ideas deBrooks fueron tomadas por los proponen-tes de los denominados métodos ágiles. En1995, en el aniversario veinte, se editó unanueva edición del libro. Brooks trató de ac-tualizarlo, pero como él mismo admite, es-tando en la academia se alejó de los asuntos,problemas y soluciones del mundo real. Sinembargo, el corazón del libro es hasta horarelevante, muchos años después de que fuepublicado.

2.3. 1975 al presente

2.3.1. Las herramientas CASE y laOrientación a Objeto

En los años 70 y principio de los 80, el aná-lisis y diseño estructurado dominaba la men-te de los desarrolladores de software. Comose mencionó anteriormente, varias sectas y

subsectas se reunían alrededor de los gurúsmás conocidos. Un modelo estándar de de-sarrollo de “ciclo de vida” para sistemas desoftware, llamado “Modelo en Cascada”(Waterfall Model), fue el primer modelo deciclo de vida documentado públicamente en1970 e inmediatamente comenzó a ser elparadigma dominante (Este modelo presu-me un desarrollo lineal, que consiste en queel resultado de una fase se constituye en laentrada de la otra fase). Desgraciadamente,el análisis y diseño estructurado falló en cum-plir la promesa de reducir los costos de de-sarrollo e incremento de la confiabilidad delsoftware, debido a que la complejidad de lossistemas aumentaba y se orientaba princi-palmente a lenguajes de tercera generación.Muy pronto, muchos “herejes” atacaron elmodelo de Cascada y desarrollaron toda clasede nuevos modelos de ciclo de vida, es de-cir, modelos acerca de los estadios o etapasde vida por las cuales atraviesa un productode software y la estrategia para componer elproducto final. Tal como se aprecia en la fi-gura 6.

FIGURA 6. Ejemplo de diferentes ciclos de vida: a) Waterfall (en cascada); b) Prototipo c) RAD; d) Espiral.

a) b)

c) d)

33

Pese a esta disputa, dos ideas interesantesen los métodos de desarrollo de softwareemergen en los años 80.

La primera de estas ideas es la herramien-ta de Ayuda Asistida por Computer (CASE:Computer Aided Software Engineering –Ayuda Asistida por Computador a la Inge-niería de Software). Cada gurú tiene unacompleja notación y un proceso, el cual de-

ben usar los diseñadores para modelar sussistemas de software. Muchos gurúes afir-man que sus métodos deberían comenzar aretornar valor solamente cuando las herra-mientas de ayuda asistida por computador(CASE) se integren con el método. Las pri-meras herramientas CASE fueron programasde dibujos gráficos primitivos vinculado auna notación de un método específico.

Pero, a la persona a quien realmente el CASEayudó a despegar fue a Philippe Kahn, el fun-dador de Borland International. En 1983Kahn lanzó un producto revolucionario: Unambiente integrado de Desarrollo (IDE –Integration Development Environment) lla-mado Turbo Pascal. La idea de un IDE noera nueva –Emacs había estado rondandopor un gran tiempo. Pero Turbo Pascal co-menzó justo cuando el computador personalestaba despegando y comenzando a ampliarla plataforma de desarrollo de software. Tur-bo Pascal manejó mucha de las tareas tedio-sas y repetitivas del desarrollo de software, per-mitiendo al desarrollador concentrarse en losproblemas del diseño de alto nivel. En efec-to, Turbo Pascal fue el precursor de VisualBasic y otros ambientes de desarrollo inte-grado visuales, tales como PowerBuilder. Sinembargo, ninguna de estas herramientas estáasociada con la idea tradicional de una “me-

todología de software” –guía de acciones ymodelos para crear software–, sino que con-forman una parte importante de las Toolkits(Cajas de Herramientas –software de ayudaal diseño que contiene apoyo a labores espe-cíficas de los desarrolladores de software). Adiferencia de las IDES’s, muchas de las he-rramientas CASE de los gurú han sido olvi-dadas.

La segunda idea interesante y útil es laidea del desarrollo de software Orientado aObjetos (OO). Uno de los padres de la OOes Alan Kay, el hombre quien dijo: “La me-jor forma de predecir el futuro es inventar-lo”. En 1971 él comenzó desarrollando lasideas detrás del lenguaje de programaciónSmalltalk. Este fue desarrollado muy lejosen Xerox Palo Alto Research Center (PARC)durante los años 70 y 80. El objetivo clavede Kay era hacer el mundo del softwaremucho más cercano al mundo real. En el

FIGURA 7. a) Diagramas manuales y b) diagramas elaborados en un CASE.


a) b)

34


mundo real, los objetos se comunican en-viando mensajes hacia atrás, para allá y paraacá. Cuando un objeto interactúa con otro,éste no tiene indicación del funcionamien-to interno del otro objeto. Cada objeto co-noce los protocolos de interacción y comu-nicación de los otros objetos. Sistemas muycomplejos pueden ser construidos combi-nando objetos y permitiéndoles que interac-túen naturalmente. El lenguaje Smalltalkproporcionaba una sofisticada implementa-ción de estas ideas.

Los proponentes de OO argumentan quesu amplia adopción permitirá una mayor fle-xibilidad en el desarrollo de software que conlas técnicas estructuradas iniciales. Esto de-bería permitir el re-uso de software y, unavez que el objeto haya sido bien definido ycreado, éste debería ser usado en diferentessistemas. Las ideas detrás de la OO comien-zan a prender en la comunidad de desarro-llo de software. En los inicios de los años80, el Departamento de Defensa de los Es-tados Unidos decidió que podría reducirmillones de dólares y asegurar la confiabili-

dad del software imponiendo que todos losdesarrollos de software sean hechos en unlenguaje OO. Cerca de 1983, el Departamen-to de Defensa gastó millones desarrollandouna nueva generación de Pascal con aspectosde OO. Esto fue llamado ADA. En el mismotiempo, Bjarne Stroustrup, de Bell Labs, creóuna nueva generación del Lenguaje C conaspectos OO, llamado C++ pero, ningunode estos lenguajes implementó completamen-te el poder de Smalltalk. Quizás por esta ra-zón (aunque no la única), por diez años tuvoque combatir por la aceptación final. Estopermitió la creación de la Web, que llevó a laexplosión en la adopción de los lenguajes ytécnicas OO. Mientras Smalltalk nunca des-pegó, su sucesor Java y Phyton han sido ex-tremadamente exitosos.

Al igual que en el caso anterior del enfo-que estructurado, numerosas son las pro-puestas surgidas de métodos orientados aobjeto y notaciones, y su evolución comen-zó desde la programación, pasando por eldiseño y finalmente abordando el análisis,tal cual se muestra en la figura 8.

Muchas son las propuestas realizadas, tan-to de Diseño como de Análisis OO. En elcaso del diseño, los métodos OO compar-ten los siguientes paso básicos de diseño,aunque los detalles varíen mucho:

– Se identifican los objetos y sus atributos.– Se establece la visibilidad de cada objeto

en relación con los demás objetos.– Se establece la interfaz de cada objeto y el

tratamiento de excepciones.– Se realizan y comprueban los objetos.

FIGURA 8. Evolución de métodos.

Algunos ejemplos de métodos de diseñoOO se encuentran en Booch (1994), Seid-ewitz y Stark (1986), Wasserman et al. (1990),entre otros.

Por su parte, el análisis OO evolucionóconsiderando dos fuentes: El modelamientode semántico de datos y el diseño OO y, conel transcurrir del tiempo, surgen muchas pro-puestas orientadas al Análisis OO, y muchosgurús se incorporan a este nuevo campo debatalla, entre los que se cuentan los trabajos

Programación Diseño Análisis

35

de Rumbaugh-OMT (Rumbaugh et al.,1991), Coad y Yourdon (1990), Shlaer yMellor (1988), Booch (1986, 1994 y 1999),Jacobson et al. (1992), Reenskaug-OORASS(Reenskaug et al., 1991), Martín y O’dell

(1992), entre muchos otros. Como conse-cuencia de lo anterior, numerosas son tam-bién las propuestas de notaciones para mo-delar distintos componentes de un sistemaOO, tal como lo muestra la figura 9.

Aun cuando existen muchas propuestas demétodos para el desarrollo de software OO,en la práctica la situación es más compleja–los métodos a menudo no cubren todo elciclo de vida, dado que muchas propuestasson orientadas sólo a diseño y especificaciónOO y muchas otras se orientan al AnálisisOO. Más aún, no se adecuan a todos los do-minios específicos requeridos tal como, porejemplo, el desarrollo para Internet. Por tan-to, en la práctica, los métodos están siendomezclados y entrelazados: un método A esusado para análisis seguido de un métodoB, el cual es usado para el diseño. A lo largodel desarrollo, se utiliza un único paradig-ma –el enfoque funcional o el enfoqueorientado a objeto–, esta división resulta ra-zonable. Una muestra de ello lo constituyeel método FUSION (Coleman et al., 1993),desarrollado por el Object-Oriented DesignGroup de los Laboratorios de Hewlett-Packard, Bristol. Este método, por ejemplo,se construye sobre la base de la primera ge-

FIGURA 9. Notaciones de diferentes Métodos OO para representar “clases” de objetos: a) Método de Booch;b) Método de Coad & Yourdon; c) Método OMT, Rumbaught.

neración de métodos, incluyendo Booch,OMT y CRC y provee una ruta completadesde la definición de requisitos hasta la im-plementación en un lenguaje de programa-ción.

Durante mucho tiempo, en las empresasse ha desarrollado un fuerte conocimiento deanálisis funcional y de métodos de modela-miento semántico de datos (por ejemplomodelos entidad-relación). Muchos desarro-lladores de software se inclinaban por seguiruna fase de análisis funcional-estructuradoseguido de una fase de diseño orientado aobjeto. Aun cuando puede ser no entendible,el hecho de mezclar paradigmas (funcional,OO, etc.) es claramente menos razonable yaconsejable, debido al serio inconvenienteasociado al cambio de paradigma: moversede un enfoque funcional a un enfoque orien-tado a objeto requiere un traslado de los ele-mentos de modelo funcional a elementos demodelo de objetos, lo cual está lejos de sernatural o ser una ventaja. Más aún, no hay


a) b) c)

36


una relación directa entre los dos conjuntosde elementos y es necesario romper los ele-mentos de modelo desde uno de los enfoquespara crear modelos de fragmentos de elemen-tos que puedan ser usado por otros (Por ejem-plo, diseñar con un enfoque estructurado yposteriormente programar con el paradigmaOO o modelar clases que incluye atributos ymétodos y posteriormente implementar enuna Base de Datos Relacional).

Este cambio de paradigma, centrado enel medio del esfuerzo de desarrollo, puedeimpedir enormemente la navegación desdelas sentencias de requisitos obtenidos tem-pranamente en las fases de análisis a la satis-facción de aquellos requisitos en la fase dediseño. Más aún, un diseño orientado a ob-

jeto obtenido después de la translación pue-de llevar a perder abstracción, y limitar elencapsulamiento de los objetos de bajo niveldisponibles en la implementación y ambien-te de ejecución, todo lo cual implica un granacuerdo de esfuerzo en orden a obtener resul-tados que no son muy satisfactorios.

La combinación de un enfoque funcio-nal y un enfoque orientado a objeto paradiseño e implementación, como equivalen-te a un moderno método orientado a objetoque cubre todo el ciclo de desarrollo de unsoftware, no necesita existir hoy día, auncuando existen numerosos trabajos con in-tención de establecer una integración, talcomo se muestra en Ward (1989).

FIGURA 10. Combinación de enfoques para modelamiento e implementación de sistemas.

Durante la pasada década, las aplicacio-nes orientadas a objeto –que fueron desde elanálisis de requisitos a la implementación–han sido desarrolladas en todos los sectoresde programación. La experiencia adquiridaen estos proyectos ha ayudado al entendi-miento de cómo unir las muchas y variadasactividades requeridas para soportar un en-foque completo orientado a objetos.

2.3.2. Lenguaje de ModelamientoUnificado (UML)

Los gurús rápidamente recogieron la idea dela Orientación a Objeto. Quizás, porque ellosentendieron que lo conceptual cambiaba des-de la programación secuencial al enfoqueOO y sería difícil y doloroso el cambio, peroque el entrenamiento de las personas debe-

37

ría ser una tendencia útil y lucrativa. El nú-mero de métodos orientados a objeto seincrementó desde menos de 10 a más de 50durante el período entre 1989 y 1994, poresta razón se hablaba la guerra de los méto-dos. Muchos usuarios de estos métodos te-nían dificultad para encontrar algún lenguajede modelamiento que satisficiera completa-mente sus necesidades.

Una gran concentración de ideas críticascomenzó a formarse a mediados de los 90’s,cuando Grady Booch (Rational SoftwareCorporation), Ivar Jacobson (Objectory) yJames Rumbaugh (General Electric), comen-zaron a adoptar ideas de cada uno de los otrosmétodos, los cuales colectivamente comen-zaron a reconocerse como líderes de los mé-todos orientados a objeto en el ámbito mun-dial. Así es como los principales autores delos métodos de Booch, OOSE y OMT, semotivaron a crear un lenguaje de modela-miento unificado, atendiendo a tres razones:

– Primero, los métodos estaban evolucionan-do realmente hacia el otro independiente-mente. Esto crea la sensación de que laevolución, juntos más que aparte, elimi-naría la potencial diferencia que podría lle-var a confundir a los usuarios.

– Segundo, unificado los métodos, se podríaproporcionar alguna estabilidad al merca-do de la orientación a objeto, permitiendoa los proyectos utilizar un lenguaje demodelamiento maduro y llevando a las he-rramientas de construcción a focalizarsesobre las características de salida más útiles.

– Tercero, se espera que la colaboración po-dría producir mejoramiento en los tresmétodos iniciales, ayudando a recoger laslecciones aprendidas y resolver los proble-mas que ninguno de los métodos habíamanejado previamente bien.

El esfuerzo de UML partió oficialmenteen octubre de 1994, cuando Rumbaugh se

unió a Booch de Rational. El proyecto ini-cial se concentró en la unificación de losmétodos de Booch y OMT. La versión draft0.8 del Método Unificado (así fue llamado)se lanzó en octubre de 1995. Alrededor delmismo tiempo, Jacobson se unía a Rationaly el ámbito del proyecto UML fue expandi-do para incorporar OOSE. El esfuerzo re-sultó en el nuevo lanzamiento de UML ver-sión 0.9 en junio de 1996. Durante 1996,los autores invitaron y recibieron retroali-mentación de la comunidad de ingenieríade software. Durante este tiempo comienzaa ser claro que muchas organizaciones veíana UML como una estrategia para sus nego-cios. Se estableció un consorcio UML convarias organizaciones destinando recursospara trabajar hacia una definición de UMLmás completa y fuerte. Estos socios contri-buyeron a la definición de UML 1.0, inclu-yendo Digital Equipment Corporation,Hewlett-Packard, i-Logic, Intellicorp y JamesMartín y Cia., IBM, ICON Computing,MCI Systemhouse, Microsoft, Oracle,Rational, Texas Instruments y Unisys. Esta co-laboración, resultó en UML 1.0, un lenguajede modelamiento que estaba bien definido,explícito y poderoso, y aplicable a una am-plia variedad de dominios de problemas. Enrespuesta a su petición para propuestas, porparte de Object Management Group(OMG), UML 1.0 fue ofrecido para la es-tandarización en enero de 1997. Entre ene-ro de 1997 y julio de 1997, el grupo origi-nal de socios fue ampliado para incluir vir-tualmente a todos los socios y contribuyen-tes de la oferta original de OMG, incluyendoAndersen Consulting, Ericsson, ObjectTimeLimited, Platinum Technology, Ptech, ReichtTechno- logies, Softeam, Sterling Software yTaskon. Una forzada tarea de semántica fuedefinida, liderada por Cris Kobryn de MCISystem-house y administrado por Ed Eykholtde Rational, para formalizar la especificación


38


de UML e integrar el UML con otros es-fuerzos de estandarización. Una versión re-visada de la versión UML 1.0 fue ofrecida ala estandarización de OMG en julio de1997. En septiembre de 1997 esta versiónfue aceptada por “The OMG Análisis and

A pesar de este acuerdo, y algún interéscomercial de muchos miembros del consor-cio sobre una notación estandarizada paramodelamiento de sistemas de software, es im-portante notar que los antiguos gurús teníanun mensaje centrado en lo humano de granimportancia que se perdió en el fragor de laguerra.

Uno de los principales argumentos parala programación estructurada es que el desa-rrollo de software está centrado principalmen-te sobre la comunicación entre personas, yno tanto en la comunicación de las personasa las máquinas. Los programas necesitan ser

FIGURA 11. Evolución de UML (Fuente: Rational).

Design Task Force” (ADTF) y el OMGArchitecture Board, y lo pusieron para vo-tación de todos los miembros de OMG. Laversión UML 1.0, la cual es la más descrita,fue aceptada por la OMG en noviembre de1997.

bien escritos y bien organizados, de modotal que los desarrolladores de software pue-dan comunicarse más fácilmente entre ellosmismos y con sus clientes. Estas ideas tanbuenas, son hasta ahora relevantes.

Lo cierto es que la guerra de los métodosno finalizó con la creación de UML. Inclu-so con una notación unificada, hay muchosnuevos métodos alternativos propuestos paramodelamiento de sistemas de software queincluyen, incluso a UML como notación.Pero debemos destacar, sin embargo, queUML es un gran logro –UML es una nota-ción no es un método–. Desde entonces se

39

considera un primer estándar. Sirve comoun lenguaje útil y universal que pueda serusado para comunicar diseños e ideas acer-ca de sistemas de software, no importa quemétodo sea escogido para usarlo. Incluso,la principal organización que promueveUML, Rational, ha formulado un Procesode Desarrollo soportado en UML (Ver fi-gura 11), llamado RUP (Rational UnifiedProcess), en el que se integran herramientasCASE y herramientas de asistencia al pro-

ceso riguroso, tales como aseguramiento decalidad, administración de requisitos entreotros, aun cuando se establece como premi-sa que es posible adecuar las actividades yreglas como mejor acomode a los desarro-lladores, es decir, es adaptable al gusto deldesarrollador. Esto pareciera ser un proble-ma, pues en ocasiones se cree necesario esta-blecer con claridad qué hacer, que disponerde una enorme cantidad de opciones paradecidir que realizar.

FIGURA 12. Proceso RUP – Rational Unified Process.

2.3.3. Una nueva alternativa:Los Métodos Agiles

Una de las principales críticas realizadas alos métodos propuestos hasta ahora es queson burocráticos, es decir, hay tantas cosasque hacer que el desarrollo de software se vuel-ve lento. Más aún, estos métodos han sidollamados “Heavy Methodologies“ (Métodospesados) o “Monumental Methodologies”(Métodos monumentales). Como una reac-ción a estas metodologías, a finales de losaños 90, ha surgido un nuevo grupo de me-todologías sustentadas en las antiguas ideasde Brooks, las que fueron conocidas por un

tiempo como “lightweight methodologies”,pero ahora el término aceptado es “AgilesMethodologies” (Métodos ágiles).

En este sentido, la guerra de los métodosde software ha venido ha completar un cír-culo peligroso. Mientras el manifiesto deDijkstra llamaba por “más” disciplina en eldesarrollo de software, los principales disiden-tes de los “tres amigos” (como se les llama alos creadores de UML) han lanzado un ma-nifiesto que llama por “menos”, llamado“Manifesto for Agile Software Development”(Manifiesto por el Desarrollo de SoftwareAgil). El que se sustenta en los siguientespostulados:


40


– Los individuos y sus interacciones, son másimportantes que los procesos y herramien-tas.

– Un software que funcione, es más impor-tante que una abundante documentación.

– La colaboración con los clientes, es más im-portante que la negociación de contratos.

– La respuesta ante el cambio, es más impor-tante que el seguimiento de un plan.

Hay varios paralelos entre las dos escue-las. El autodenominado estilo ágil ha comen-zado a presentar una serie de libros en TheAgile Software Development Series, similar alo propuesto por los tres amigos, ObjectTechnology Series. Los gurús ágiles han crea-do su propia empresa de consultoría y en-trenamiento orientando sus principales es-fuerzos hacia tomar ventajas de “la nueva eco-nomía”, es decir, el desarrollo sobre Internet.Es destacable, sin duda, que la principal con-tribución de los métodos ágiles es que ellosestán recogiendo ampliamente el enfoquecentrado en la persona propuesta por Brooks.Más aún, están agregando elementos adicio-nales para el entendimiento de la problemá-tica humana detrás del desarrollo de softwareen general. Highsmith (2002) utiliza la pala-bra “ecosistema” en vez de método o meto-dología para indicar que el desarrollo de soft-ware trata acerca de personas, sus interac-ciones y adaptaciones a un ambiente amplioy no sobre procesos de ingeniería. Algunosimportantes ejemplos de métodos ágiles son:XP (Extreme Programming), Cockburn’sCrystal Family, Open Source, Highsmith’sAdaptive Software Development, Scrum,Feature Driven Development y DSDM(Dynamic System Development Method).Se debe destacar que la carencia de docu-mentación es un síntoma de dos profundasdiferencias, según Martín Fowler, uno de loslíderes de estas propuestas:

1. Los métodos ágiles son más adaptativos quepredictivos. Los métodos monumentales

tienden a tratar de planear una gran partedel proceso de desarrollo de software, congran detalle por un gran lapso de tiempo.Esto está bien, hasta que las cosas cam-bian. Así es que su naturaleza es resistir elcambio. Los métodos ágiles, en cambio,reciben los cambios. Ellos tratan de pro-cesar y hacer propicio los cambios.

2. Los métodos ágiles son más orientados a laspersonas que al proceso. Ellos explícitamen-te manifiestan que se ha de “tratar” con eltrabajo y la naturaleza de las personas másque contra ellos, y enfatizan que el desa-rrollo de software debería ser una activi-dad entretenida.

Muchas personas apelan a estas metodo-logías ágiles como reacción a las metodolo-gías burocráticas o monumentales. Estosnuevos métodos intentan establecer un jus-to equilibro entre “sin proceso” y “demasia-do proceso”, proporcionando sólo el proce-so suficiente para obtener un retorno razo-nable. De muchas formas, estos métodosestán más orientados al código: siguiendo laidea de que plantean que la parte clave de ladocumentación es el código fuente.

CONCLUSIONES

Desde que Dijkstra planteó que el desarro-llo de software debería estar centrado fuer-temente en las matemáticas para producirproductos confiables y con costos predeci-bles, muchos esfuerzos se han realizado paradefinir un proceso de desarrollo de softwareen forma disciplinada y rigurosa. Importan-tes organizaciones, tales como Motorola,NASA, entre otros, basan su desarrollo entales prácticas disciplinadas. Por su parte, lainnumerable cantidad de métodos de desa-rrollo de software propuestos, algunos que-dando en el olvido y los menos –en su afánde adecuarse a los cambios de enfoques, a lainnumerable cantidad de situaciones que

41

deben enfrentar y a las diversas áreas de apli-cación en que se deben desenvolver– hanincorporado una gran cantidad de reglas,notaciones, prácticas y documentos que re-quieren mucha disciplina y tiempo para se-guirla correctamente. Esto ha llevado a serdefinidas como Metodologías monumenta-les o Heavy Methodologies. Sin embargo, sonmuchas las áreas en las cuales este tipo de de-sarrollo no se condice con las exigencias delproblema. Desarrollar, por ejemplo, aplica-ciones para la Web establece como premisaque el tiempo es corto, los requisitos cam-biantes, se requieren equipos multidiscipli-narios, entre otros aspectos. Por tanto, es di-fícil planificar dada la innumerable cantidadde cambios y se requiere una interacción muyfuerte entre el equipo de desarrolladores.

Por otra parte, pese al logro de la comu-nidad internacional de ingeniería de softwarede aceptar finalmente una notación estándarcomo lo es UML y su posterior inserción enun gran proceso de desarrollo de software(Rational Unified Process) –aun cuando exis-tan intereses económicos detrás–, existenmuchos detractores que se oponen a la acep-tación de dichos métodos monumentales so-bre la base de que hacen más burocrático ylento el desarrollo software y que este tipode desarrollo es un proceso centrado en laspersonas y en sus interrelaciones, y no entrelas personas y las máquinas, por tanto, no esequivalente a un proceso de ingeniería tra-dicional.

Sin duda, ambos enfoques tienen su áreade aplicación y sus exigencias. Quizás, por elhecho de que los productos de software serequieran en áreas tan diferentes, distintos ti-pos de requisitos, distinta volatilidad de re-quisitos, diferentes niveles de riesgos, diver-sos clientes, diferentes niveles de calidad, en-tre muchos otros aspectos, hace que ambostipos de enfoques metodológicos tengan suvalidez en el contexto en que se usan. Suma-do a lo anterior, se debe incluir como “méto-do” ampliamente usado, el estilo “hacker” o

programación por prueba y error, sin disci-plina ni sistematización alguna, tal como lodefinen algunos autores. Por lo tanto, se vedifícil, por el momento, tener reconciliadasestas propuestas y disponer de estandariza-ción de métodos de desarrollo de software,menos aún cuando siguen apareciendo nue-vas propuestas de métodos. Por lo demás,nos vemos obligado a sumar esta preocupa-ción a una de las tantas paradojas de estemundo actual, entre ellas: “Saber de todo,pero ser especialista en algo”, y, en el caso delos métodos de desarrollo de software: “Ser-vir para todas las áreas de aplicación y entodos los casos, pero simple y fácil de usar”.

REFERENCIAS

ALFORD, M. (1977) “A Requirement EngineeringMethodology for Real Time Processing Require-ments,” IEEE Trans. Software Eng., Vol. 3, Nº1, Jan., pp. 60-69.

BOOCH, G. (1994) Object-Oriented Análisis andDesign, Benjamin/Cumming, Redwood City,Calif.

BOOCH, G. (1986) “Object-Oriented develop-ment”. IEEE Trans. On Software Eng., Vol. SE-12(2), 211-221.

CHEN, P. (1976) The Entity-Relationship model:toward a unified view of data. ACM Trans. OnDataBase System, 1(1), 9-36.

COAD, P. and YOURDON, E. (1990) Object Ori-ented Analysis, Prentice-Hall, Englewood Cliffs,N.J.

CODD, E.F. (1976) A Relational Model of Data forLarge Share Data Banks. Comm. ACM, 13 (6),377-387.

COLEMAN, D., ARNOLD P., BODOFF, C.,DOLLIN, C., HAYES, F. and JEREMAES, P.(1993) Object - Oriented Development: TheFusion Method. Prentice-Hall.

GANE, C. and SARSON, T. (1979) Structured Sys-tem Anlysis. Prentice-Hall, New Jersey.

HAMILTON, M. and ZELDIN, S. (1979) “HigherOrde Software - A Methodology for DefiningSoftware”, IEEE Trans. Software Eng., Vol. 2, Nº1, Jan., pp. 9-32.

HATLEY, D. and PIRBHAI, I. (1987) Strategies forReal-Time Specification. Dorset House, New York,N.Y.


42


HIGHSMITH, J. (2002) Agile Software Ecosystem,Adisson-Wesley, IBSN 0-201-76043-6.

JACKSON, M. (1983) System Development. Engle-wood Cliffs, New Jersey: Prentice Hall Interna-tional.

JACOBSON, I., CHRISTERSON, M., JONSONP. and OVERGARD, G. (1992) Object-OrientedSoftware Engineering, Addison-Wesley, Reading,M.A.

JONSON, J. (1994) “Failure is Its Own Reward”,Application Development Trends, Vol 1., Nº 9,August, p. 70.

JONSON, J. (1995) “CHAOS: The Dollar Drainof IT Project Failure”, Application DevelopmentTrends, Vol. 2, Nº 1, January, pp. 41-47.

MARTÍN, J. (1990) Information Engineering, Vol.1, 2 y 3. PTR Prentice Hall, Englewood Cliffs,New Jersey 07632.

MARTÍN J. and O’DELL J. (1992) Object –Ori-ented Análisis and Design. Englewood Cliffs, NJ,Prentice-Hall.

NANDHAKUMAR, J. and AVISON, J. (1999). Thefiction of methodological development: a fieldstudy of information system development. Infor-mation Technology & People 12(2): 176-191.

PARNAS, D. (1972) “On the Criteria to be Usedin Decomposing Systems into Modules”, Comm.ACM, Vol. 15, Nº 12, Dec., pp. 1.053-1.058.

PARNAS, D. L. and CLEMENTS, P.C. (1986) Arational design process: How and why to fake it.IEEE Transactions on Software Engineering12(2): 251-257.

REENSKAUG, T., ANDERSON, E.P. and BERRE,A.J. (1991) Seamless support for the creation and

maintenance of object - oriented system. TaskonA/S Gandstadalteen 21, N-0371 Oslo 3.

RUMBAUGH, J. BLAHA, M., LORENSEN, W.,HEDI, F. and PREMERLANJ, W. (1991) Ob-ject Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, N.J.,

SEIDEWITZ, E. and STARK, M. (1986) GeneralObject-Oriented Software Development, Soft-ware Engineering Letters, 86-102.

SHLAER, S. and MELLOR S. (1988) Object-Ori-ented System Analysis: Modeling the World inData, Prentice-Hall, Englewood, Cliffs, N.J.

THE STANDISH GROUP (2000) The CHAOSReport. Dennis, MA: The Standish Group,1994

TRUEX, D. P., BASKERVILLE, R. and TRAVIS,J. A (2000) Methodical systems development:The deferred meaning of system developmentmethods. Accounting, Management and Infor-mation Technology 10: 53-79.

WARD, P. and MELLOR S. (1986) Structured De-velopment for Real-Time, Vols. 1, 2 y 3, Prentice-Hall, Englewood Cliffs, N.J.

WARD, P. (1989) How integrated object-orienta-tion with Structured Analysis and Design. IEEESoftware, 6 March.

WARNIER, J. (1974) Logical Construction of Pro-grams. New York: Van Nostrand Reinhold.

WASSERMAN A.L., PIRCHER P.A. and MULLERR.J. (1990) The Object-Oriented Structured de-sign notation for software design representation,IEEE Computer, 50-62, March.

WIEGERS, K.E. (1998) Read my lips: No newmodels. IEEE Software 15(5): 10-13.

YOURDON, E. (1989) Modern Structured Analy-sis. Englewood Cliffs, New Yersey: Yourdon Press.

metodos de desarrollo de software: el desafio · este estilo de desarrollo de software, pero tambi...

Documents