1.

5 MODELOS DE CICLO DE VIDA Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas etapas. [1] Las principales diferencias entre distintos modelos de ciclo de vida estn divididas en tres grandes visiones: *El alcance de ciclo de vida *La cualidad y cantidad de las etapas en que dividiremos el ciclo de vida *La estructura y la sucesin de las etapas [2] MODELO CASCADA Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia simple de fases.[3] El modelo de ciclo de vida cascada, captura algunos principios bsicos: Planear un proyecto antes de embarcarse en l. Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna. Documentar los resultados de cada actividad. Disear un sistema antes de codificarlo. Testear un sistema despus de construirlo. [4] Tipos de proyectos para los que es adecuado Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniera. Se est desarrollando un tipo de producto que no es novedoso. Proyectos complejos que se entienden bien desde el principio.[5]

[6]

MODELO INCREMENTAL El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.[7] *Se evitan proyectos largos y se entrega Algo de valor a los usuarios con cierta frecuencia *El usuario se involucra ms *Difcil de evaluar el coste total *Difcil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo *Requiere gestores experimentados *Los errores en los requisitos se detectan tarde. *El resultado puede ser muy positivo.[8]

[9] PROTOTIPADO EVOLUTIVO En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es actualizada, y una segunda versin del producto es desarrollada y desplegada.[10]

Construccin de una implementacin parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema: *Reduce el riesgo y aumenta la probabilidad de xito *No se conocen niveles apropiados de calidad y documentacin *Problemas de gestin de configuracin.[11]

MODELO DE PROTOTIPO *No modifica el flujo del ciclo de vida *Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. *Reduce costos y aumenta la probabilidad de xito *Exige disponer de las herramientas adecuadas *No presenta calidad ni robustez *Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.[12]

[13]

MODELO DE CICLO DE VIDA EN ESPIRAL Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseo, errores en la implementacin, etc. [14]

[15] En cada iteracin Boehm recomienda recopilar la siguiente lista de informaciones:

Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc. Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista
o o

Caractersticas del producto. Formas de gestionar el proyecto.

Restricciones:
o

Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc. 4

Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

Riesgos: Lista de riesgos identificados. Resolucin de riesgos: La tcnica ms usada es la construccin de prototipos. Resultados: Son lo que realmente ha ocurrido despus de la resolucin de riesgos. Planes: Lo que se va a hacer en la siguiente fase. Compromiso: Decisiones de gestin sobre como continuar.[16]

Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, tambin se verifica que funciona correctamente. El propio cliente evala el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.[17] Ventajas

No necesita una definicin completa de los requisitos para empezar a funcionar. Al entregar productos desde el final de la primera iteracin es ms fcil validar los requisitos. El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn bien). El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.[18]

Inconvenientes

Es difcil evaluar los riesgos. Necesita de la participacin continua por parte del cliente. Cuando se subcontrata hay que producir previamente una especificacin completa de lo que se necesita, y esto lleva tiempo.[19]

Dnde es adecuado

Sistemas de gran tamao. Proyectos donde sea importante el factor riesgo. Cuando no sea posible definir al principio todos los requisitos.[20] MODELO BASADO EN REUTILIZACION

*Principios de la reutilizacin: Existen similitudes entre distintos sistemas de un mismo dominio de aplicacin 5

El software puede representarse como una combinacin de mdulos Disear aplicaciones = especificar mdulos + interrelaciones Los sistemas nuevos se pueden caracterizar por diferencias respecto a los antiguos *Reduce tiempos y costes de desarrollo *Aumenta la fiabilidad *Dificultad para reconocer los componentes potencialmente reutilizables *Dificultad de catalogacin y recuperacin *Problemas de motivacin *Problemas de gestin de configuracin.[21]

[22]

CICLOS DE VIDA ORIENTADOS A OBJETOS Los objetos tienen una particularidad, y es que estn basados en componentes que se relacionan entre ellos a travs de interfaces, o lo que es lo mismo, son ms modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos. Un tipo de ciclo de vida orientado a objetos, que es el ms representativo, el modelo fuente.[23] MODELO FUENTE 6

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientacin a objetos y posiblemente el ms seguido. Un proyecto se divide en las fases: 1. Planificacin del negocio 2. Construccin: Es la ms importante y se divide a su vez en otras cinco actividades
o o o o o

Planificacin Investigacin Especificacin Implementacin Revisin

3. Entrega La primera y la tercera fase son independientes de la metodologa de desarrollo orientado a objetos. Adems de las tres fases, existen dos periodos: 1. Crecimiento: Es el tiempo durante el cual se construye el sistema 2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificacin del negocio, Construccin y Entrega.[24] Cada clase puede tener un ciclo de vida slo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e iterativo.[25]

[26]

1.6 LEGISLACION DEL SOFTWARE

Qu leyes rigen en Mxico para los programas de cmputo, las bases de datos y su documentacin? Principalmente las siguientes:

Ley Federal de Derechos de Autor (LFDA) y su reglamento

Protege los programas de cmputo, su documentacin y las bases de datos en forma similar a los libros, las canciones y sus letras, las grabaciones musicales, las pinturas, y dems obras. Tiene adems su Reglamento (RLFDA). Ley de Propiedad Industrial (LPI) y su reglamento Protege elementos que pueden acompaar a un programa de cmputo, como son: marcas, dibujos o conos distintivos. Cdigo Penal Federal y Cdigo Federal de Procedimientos Penales Sancionan la produccin masiva de COPIAS no autorizadas de programas de cmputo o su venta.[27] La LPI, que regula el otorgamiento de patentes en Mxico a las invenciones de productos o de procesos, menciona en su artculo 19 seccin IV que los programas de cmputo no son considerados invenciones. Un programa de cmputo podra ser parte de un invento, sea un producto o un proceso, como un elemento para realizar alguna de las funciones del invento.[28] Si hago un programa de cmputo, necesito registrarlo para que yo tenga derechos de autor sobre de l? No. LFDA Artculo 5: La proteccin se concede a las obras desde el momento en que hayan sido fijadas en un soporte material. El reconocimiento de los derechos de autor y de los derechos conexos no requiere registro ni documento de ninguna especie. [29] Si no requiero registrarlo para que valgan los derechos de autor de mi programa de cmputo o base de datos, entonces para qu lo registro? La decisin de registrar o no un programa o su documentacin es tuya. El registro de un programa de cmputo o base de datos en el INDA es un antecedente fechado por una institucin oficial, que puede ayudarte a resolver una controversia si se presentara. Tanto el Registro Pblico del Derecho de Autor, como t conservan un ejemplar sellado de tu obra, y un oficio con el nmero de registro. [30]

Si soy empleado o consultor y realizo un programa de cmputo durante mi trabajo, soy el titular del derecho de autor o lo es mi empleador? Salvo pacto en contrario, los derechos patrimoniales sobre un programa de computacin y su documentacin, cuando hayan sido creados por uno o varios empleados en el ejercicio de sus funciones o siguiendo las instrucciones del empleador, corresponden a ste. LFDA 103.[31] Si soy empleado o consultor y realizo un programa de cmputo en mi tiempo libre, en casa, con equipo y herramientas de desarrollo de mi propiedad, soy el titular del derecho de autor del programa? Depende de las clusulas de tu contrato de trabajo, y de si firmaste un acuerdo de confidencialidad y/o desarrollos propietarios con tu empleador. ste ltimo puede especificar que todo programa que desarrolles es propiedad de tu empleador, sin dejar en claro el caso descrito en esta pregunta.[32] Si el programa de cmputo que pretendes hacer se traslapa con las responsabilidades de tu puesto, tambin deja menos claro el caso. Decide si quieres consultar tu caso con un abogado o no. En caso afirmativo, el abogado examinar tus documentos y te propondr un acuerdo de reconocimiento de derechos para que lo firme el representante legal de tu empleador, preferentemente antes de empezar a desarrollar el programa. El acuerdo de reconocimiento de derechos dejar en claro que el programa que vas hacer no es un trabajo por encargo y que sers el titular del derecho de autor.[33] Necesito definir la licencia de uso para mi programa de cmputo antes de registrarlo? No. Lo que s tienes que decidir, es si vas a registrar el cdigo fuente o el cdigo binario. Qu tipos de licencias hay? Las licencias de uso de software generalmente caen en alguno de estos tipos: *Licencia propietaria. Uso en una computadora por el pago de un precio. *Shareware. Uso limitado en tiempo o capacidades, despus pagar un precio. *Freeware. Usar y copiar ilimitado, precio es cero. *Software libre. Usar, copiar, estudiar, modificar, redistribuir. Cdigo fuente incluido.[34] 1.7 METODOLOGIA Definicin de metodologa

Conjunto de mtodos que se siguen en una investigacin cientfica o en una exposicin doctrinal. [35]

La metodologa (meta = a travs de, fin; odos = camino, manera; lgos = teora, razn, conocimiento): es la teora acerca del mtodo o del conjunto de mtodos. La metodologa es normativa (valora), pero tambin es descriptiva (expone) o comparativa (analiza). [36] Tipos de metodologa, elementos que forman parte de una metodologa y desarrollo de los pasos de una metodologa

Rational Unified Process (RUP) La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, divide en 4 fases el desarrollo del software:

Inicio, El Objetivo en esta etapa es determinar la visin del proyecto. Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima. Construccin, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Transmisin, El objetivo es llegar a obtener el release del proyecto. [37]

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos disciplinas: Disciplina de Desarrollo

Ingeniera de Negocios: Entendiendo las necesidades del negocio. Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software. Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo lo solicitado est presente. [38]

Disciplina de Soporte

Configuracin y administracin del cambio: Guardando todas las versiones del proyecto. Administrando el proyecto: Administrando horarios y recursos. Ambiente: Administrando el ambiente de desarrollo. Distribucin: Hacer todo lo necesario para la salida del proyecto [39] 10

Es recomendable que a cada una de estas iteraciones se les clasifique y ordene segn su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentacin que se tendra en cada entregable o en cada iteracin. Los elementos del RUP son:

Actividades, Son los procesos que se llegan a determinar en cada iteracin. Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso. Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

En cada ciclo de iteracin, se hace exigente el uso de artefactos, por este motivo, es una de las metodologas ms importantes para alcanzar un grado de certificacin en el desarrollo del software. [40] Extreme Programing (XP) Es una de las metodologas de desarrollo de software ms exitosas en la actualidad, utilizada para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.[41] Caractersticas de XP, la metodologa se basa en:

Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos estndares, siendo ms flexible al cambio. Programacin en pares: propone la programacin en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa. [42]

Qu es lo que propone XP? 11

Empieza en pequeo y aade funcionalidad con retroalimentacin continua El manejo del cambio se convierte en parte sustantiva del proceso El costo del cambio no depende de la fase o etapa No introduce funcionalidades antes que sean necesarias El cliente o el usuario se convierte en miembro del equipo [43]

Derechos del Cliente

Decidir que se implementa Saber el estado real y el progreso del proyecto Aadir, cambiar o quitar requerimientos en cualquier momento Obtener lo mximo de cada semana de trabajo Obtener un sistema funcionando cada 3 o 4 meses [44]

Derechos del Desarrollador Decidir cmo se implementan los procesos Crear el sistema con la mejor calidad posible

Pedir al cliente en cualquier momento aclaraciones de los requerimientos Estimar el esfuerzo para implementar el sistema Cambiar los requerimientos en base a nuevos descubrimientos [45]

Lo fundamental en este tipo de metodologa es: La comunicacin, entre los usuarios y los desarrolladores La simplicidad, al desarrollar y codificar los mdulos del sistema

La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales [46]

Microsoft Solution Framework (MSF) Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas.[47] MSF tiene las siguientes caractersticas: Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es limitado a un especfico lugar. Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. 12

Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa. [48]

MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto:

Modelo de Arquitectura del Proyecto: Diseado para acortar la planificacin del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a travs del lanzamiento de versiones. Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de personas disponibles. Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su relacin con el Modelo de equipo. Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratgicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar. Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseo eficiente y flexible a travs de un enfoque iterativo. Las fases de diseo conceptual, lgico y fsico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores. Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para disear y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores. [49]

CONCLUSION Comenzando por la definicin de modelo de ciclo de vida de software, es una vista de las actividades que ocurren durante el desarrollo de software. Existen diversos modelos, por mencionar algunos estn: *Modelo de cascada 13

*Incremental *Prototipo evolutivo *Espiral *Orientado a objetos, etc. Cada uno de los anteriores tiene caractersticas diferentes y algunas en comn, algunos son ms convenientes en su uso en proyectos ms grandes que otros, otros tienen ms contacto con el usuario durante el desarrollo, de tal forma que es preferible utilizar el que mejor se adapte al proyecto a desarrollar, para esto, debemos analizar la complejidad del problema, si el cliente desea entregas parciales para verificar los requerimientos pedidos en un principio, el tiempo del que se dispone para entregar el proyecto, la certeza de que los requerimientos dados por el cliente son completos y correctos. En cuanto a legislacin del software, en Mxico no se considera un software como un invento, es por eso que solo se permite, que por derechos de autor se proteja dicho programa, es decir, de forma similar a los libros, msica, etc. Se puede sancionar la produccin masiva de copias no autorizadas del programa de cmputo o su venta. Tambin se decide si se registrara el cdigo fuente o el cdigo binario y finalmente existen tipos de licencia de software como lo son: *Licencia propietaria. Uso en una computadora por el pago de un precio. *Shareware. Uso limitado en tiempo o capacidades, despus pagar un precio. *Freeware. Usar y copiar ilimitado, precio es cero. *Software libre. Usar, copiar, estudiar, modificar, redistribuir. Cdigo fuente incluido.

Por metodologa, comprend que es quien estudia los mtodos, los cuales son el camino para lograr llegar al cometido (objetivos), existen diversos tipos de metodologa, pero especficamente en lo anterior solo se mencionan los referentes al diseo de software, plasmando 3, que son: Rational Unified Process (RUP), Extreme Programing (XP) y Microsoft Solution Framework (MSF), la metodologa RUP es ms til cuando se trata de proyectos programados a largo plazo, se divide en 4 fases que son Inicio, Elaboracin, Construccin y Transmisin, donde se marcan objetivos que van desde la visin del proyecto hasta la entrega del mismo. En el desarrollo de los pasos se tienen que tomar en cuenta las necesidades del negocio para plasmarlas de manera adecuada en un sistema, que ser el que ayudara a la empresa, conllevando el comportamiento requerido y deseado por el cliente. Sus elementos son las actividades, trabajadores, as como los artefactos, estos ltimos pueden ser documentos, modelos, etc., en esta metodologa particularmente se exige el uso de artefactos, convirtindola en una metodologa muy importante. Consecuentemente se mencion Extreme Programing (XP), metodologa que acta en situaciones de proyectos a corto plazo y que emergentemente tienen que entregarse en caso de demorarse, su particularidad es tener al usuario final como parte del equipo, ya que es una pieza clave para lograr el xito, adems se caracteriza por realizar pruebas unitarias, las cuales pueden adelantarnos los posibles errores en el futuro, puede reutilizar cdigo y propone la programacin en pares, de tal manera que un desarrollador realiza lo que el otro no hace en ese momento. El cliente tiene derecho a saber en qu estado se 14

encuentra el sistema, en decidir que se implementa en el momento que lo requiera, as de igual manera el desarrollador puede pedir al cliente aclaraciones de los requerimientos, realizar un sistema con calidad, decidir cmo implementar los procesos, entre otras actividades, por eso es de mucha relevancia la comunicacin entre el cliente y el desarrollador, la simplicidad al codificar y finalmente la retroalimentacin. Por ltimo Microsoft Solution Framework (MSF) se centra en modelos de proceso y de equipo, es por eso que es adaptable, escalable, flexible, de tecnologa agnstica, concretamente puede usarse en cualquier parte, es capaz de organizar grupos pequeos de 3 o 4 personas, as como proyectos que requieren 50 personas o ms, puede tener soluciones basadas sobre otro tipo de tecnologa, se compone de diversos modelos que planifican ciertas partes del proyecto, y son: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de Diseo del Proceso, Modelo de Aplicacin, que disean desde la planificacin del ciclo de vida, hasta el mantenimiento, desarrollo, control, identificacin de lo que se requiera.

[1] http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/lpcu097%20-%2001.pdf [2]-[4]http://rguerrero334.blogspot.es/img/Def.Modelo_de_Ciclo_de_Vida.pdf [5] http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html [6] http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf [7] http://rguerrero334.blogspot.es/img/Def.Modelo_de_Ciclo_de_Vida.pdf [8],[9] http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf [10] http://rguerrero334.blogspot.es/img/Def.Modelo_de_Ciclo_de_Vida.pdf [11]-[13] http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf [14]-[20] http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html [21],[22] http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf [23]-[26] http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html

15

[27]-[34] http://pp.com.mx/legalfaq.html [35] Diccionario de la Real Academia Espaola, Vigsima edicin [36] https://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r33282.PDF [37]-[49] http://www.informatizate.net/articulos/metodologias_de_desarrollo_de_software_07062004.html

16