INSTITUTO TECNOLOGICO DE ACAPULCO

INGENIERIA DE SOFWARE
UNIDAD 2 METODOLOGIAS DE DESARROLLO

PROFRA: ING. MARIA NANCY GARCIA CASTRO

INTEGRANTES:

AULA: 709

HORARIO: 15:00-16:00Hrs.

ACAPULCO., GRO. 29 DE ABRIL DE 2013

INDICE
INTRODUCCIN.....................3 2.1 Metodologas clsicas 2.1.1 CASCADA (1er Autor).....................................................................4 2.1.1 CASCADA (2do Autor).....................................................................8

2.1.2 INCREMENTAL (1er Autor).11

2.1.2 INCREMENTAL (2do Autor). .14 2.1.3 EVOLUTIVO (1er Autor)...17 2.1.3 EVOLUTIVO (2do Autor).....................................................................19 2.1.4 ESPIRAL (1er Autor).. 21 2.1.4 ESPIRAL (2do Autor)..25 2.1.5 PROTOTIPOS (1er Autor)..................................................28 2.1.5PROTOTIPOS (2do Autor)..31 2.1.6 DESARROLLO BASADO EN COMPONENTES (1er Autor)33 2.1.6 DESARROLLO BASADO EN COMPONENTES (2do Autor)35

2.2 OTRAS METODOLOGIAS

2.2.1 GANAR-GANAR (1er Autor)38 2.2.1 GANAR-GANAR (2do Autor)..40 2.2.2 PROCESO UNIFICADO (UP) (1er Autor).42 2.2.2 PROCESO UNIFICADO (UP) (2do Autor)45 2.2.3 INGENIERIA WEB (1er Autor)..48 2.2.3 INGENIERIA WEB(2do Autor)..52

2.2.4 METODOLOGIAS AGILES (1er Autor)..54 2.2.4 METODOLOGIAS AGILES (2do Autor)..64 2.2.5 METODOLOGIAS EMERGENTES (1er Autor)65 2.2.5 METODOLOGIAS EMERGENTES (2do Autor).69 2.3 REINGENIERIA (1er Autor).70 2.3 REINGENIERIA (2do Autor)75

CONCLUSION.77 BIBLIOGRAFIA .......78

INTRODUCCIN
El concepto de metodologa, dentro de la Ingeniera del Software es, sin duda, uno de los temas ms oscuros y que ms confusin produce tanto en estudiantes como en profesionales involucrados en procesos de desarrollo de software. Tanto es as, que en muchos proyectos de desarrollo, la aplicacin de una metodologa brilla por su ausencia, siendo ste un concepto casi desconocido. Adems, la constante innovacin tecnolgica hace que cada vez sea necesaria la aplicacin de nuevas metodologas adaptadas a los nuevos tiempos y, sin embargo, siguen figurando en los libros de texto viejas metodologas pensadas para viejos problemas... cosa que no sera necesariamente mala si las nuevas metodologas tuviesen tambin su lugar... pero a menudo no es as. Y no es que haya una metodologa claramente superior a las dems. Todas las metodologas son, en esencia, bienintencionadas. Obviamente, las ms modernas responden a problemas y necesidades ms actuales. Afortunadamente, los tiempos van cambiando. La informtica va madurando y tanto algunos profesionales de las tecnologas de la informacin como algunos de sus clientes se van dando cuenta de que se hace necesario seguir unas ciertas pautas predefinidas en el desarrollo del software de calidad: es decir, llevar un comportamiento metdico: seguir una metodologa.

2.1.1 CASCADA (1er AUTOR)

Es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos. Diseo del Sistema. Diseo del Programa. Codificacin. Pruebas. Implantacin. Mantenimiento.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo el paradigma ms seguido al da de hoy.

Fases del modelo Anlisis de requisitos En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante sealar que en esta etapa se debe consensuartodo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software.

Diseo del Sistema Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras. Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin.

Diseo del Programa Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. Codificacin Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregirerrores. Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido.

Pruebas Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificacin Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. En la creacion de desarrollo de cascada se implementa los codigos de investigacion y puebas del mismo

Mantenimiento Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas. VENTAJAS El modelo cascada por su sencillez solo utiliza los pasos intuitivos necesarios a la hora de desarrollar el software, adems es muy entendible para cliente. + La planificacin es sencilla. + La calidad del producto resultante es alta. + Permite trabajar con personal poco cualificado

Desventajas En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien. Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo.

EJEMPLO: En la materia de refrigeracin y aire acondicionado est el modelo cascada. En donde hay dos sistemas: Sistema 1: evaporador 1 compresor 1 condensador 1 vlvula de expansin 1

Sistema 2: evaporador 2 compresor 2 condensador 2 vlvula de expansin 2

En donde el fluido del sistema 1 tiene mejores propiedades, que el del sistema 2. Es decir, es capaz de absorber ms energa en forma de calor. El sistema 1 y 2 estn acondicionados de tal forma que el calor cedido del condensador 1, lo absorbe el evaporador 2. Bueno, este sistema de cascada se aplica en cmaras frigorficas.

2.1.1 CASCADA (2do AUTOR)

Modelo en Cascada1(Bennington 1956): El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades:
Ingeniera y Anlisis del Sistema Anlisis de los Requisitos Diseo Codificacin Prueba Mantenimiento

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algn subconjunto de estos requisitos al software.

Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas.

Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin.

Ingeniera del Software: Un enfoque practico, Roger S. Presuman, 3ra Edicin, Pag. 26-30.

Codificacin: el diseo debe traducirse en una forma legible para la maquina. El paso de codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la codificacin puede realizarse mecnicamente. Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. La prueba se centra en la lgica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Mantenimiento: el software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Desventajas: Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicacin del paradigma. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El ciclo de vida clsico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una versin operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso. La ventaja de este mtodo radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Modelo V (Ministerio de Defensa de Alemania, 1992): El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolucin del mismo. Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integracin asociado a cada una de las etapas de la mitad anterior.

Los planes de prueba son el nexo entre el desarrollo y la verificacin

ANALISIS DE REQUERIMIENTOS

OPERACION Y MANTENIMIENTO

Plan de Pruebas de Aceptacin

PRUEBA DE ACEPTACION

Validar requerimientos
Plan de Pruebas del Sistema

DISEO DEL SISTEMA

PRUEBA DEL SISTEMA

Verificar diseo
Plan de Pruebas de Integracin

DISEO DETALLADO

PRUEBA DE INTEGRACION

IMPLEMENTACION DE PROGRAMAS Y

Se puede identificar una ventaja principal con respecto al Modelo Cascada ms simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada. Desventajas: El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptacin al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementacin, lo que puede traer como consecuencia un roll-back de todo un proceso que cost tiempo y dinero. El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo. A pesar de todo lo antes mencionado, definitivamente se trata de un modelo ms robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada. EJEMPLO: Este modelo es ampliamente utilizado en los sistemas gubernamentales de gran tamao, en especial en el Departamento de Defensa de los Estados Unidos (DOD).

10

2.1.2 INCREMENTAL (1er autor)

El modelo incremental es una unin de las mejores funcionalidades del modelo de cascada y del modelo de prototipos. A medida que se presenta un prototipo se produce un incremento, que es una iteracin del proceso anterior pero aplicando las experiencias aprendidas del proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo estn orientados a ser operacionales en cada incremento y no ser solo una previa de cmo sera el sistema en su versin final. El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. El Modelo Incremental se puede ver aqu en forma grafica: - 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 los 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.

11

Pipeline La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Esta arquitectura es muy comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe). Tambin es una arquitectura muy natural en el paradigma de programacin funcional, ya que equivale a la composicin de funciones matemticas. Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucre ms. - Difcil de evaluar el costo total. - Difcil de aplicar a los 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. Ventajas: - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. - El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. - Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. - Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos. - Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. Desventajas: - El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos. - Requiere de mucha planeacin, tanto administrativa como tcnica. - Requiere de metas claras para conocer el estado del proyecto.

12

EJEMPLO: Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra aportar, en principio, funciones bsicas de edicin de archivos y produccin de documentos (algo como un editor simple). En un segundo incremento se le podra agregar edicin ms sofisticada, y de generacin y mezcla de documentos. En un tercer incremento podra considerarse el agregado de funciones de correccin ortogrfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido. As, el producto va creciendo, acercndose a su meta final, pero desde la entrega del primer incremento ya es til y funcional para el cliente, el cual observa una respuesta rpida en cuanto a entrega temprana; sin notar que la fecha lmite del proyecto puede no estar acotada ni tan definida, lo que da margen de operacin y alivia presiones al equipo de desarrollo.

13

2.1.2 INCREMENTAL (2do AUTOR)

Sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software [MDE93]. Por ejemplo, el software de tratamiento de textos desarrollado con el paradigma incremental podra extraer funciones de gestin de archivos bsicos y de produccin de documentos en el primer incremento; funciones de edicin ms sofisticadas y de produccin de documentos en el segundo incremento; correccin ortogrfica y gramatical en el tercero; y una funcin avanzada de esquema de pgina en el cuarto. PUNTO CLAVE El modelo incremental entrega el software en partes pequeos, pero utilizables, llamadas (incrementos). En general, cado incremento se construye sobre aqul que ya ha sido entregado. Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisin detallada). Como un resultado de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. El modelo de proceso incremental, como la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin. El desarrollo incremental es particularmente til cuando la dotacin de personal no est disponible para una implementacin completa en la fecha

14

lmite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas. Ventajas: - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. - El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. - Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. - Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos. - Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. Desventajas: - El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos. - Requiere de mucha planeacin, tanto administrativa como tcnica. - Requiere de metas claras para conocer el estado del proyecto.

15

EJEMPLO: El mtodo incremental propone ubicar la decisin pblica en valores marginales y no en valores centrales, es decir, en grandes temas. Los administradores han de elegir nicamente entre las diversas polticas alternativas que ofrecen diferentes combinaciones marginales de valores

16

2.1.3 MODELO EVOLUTIVO (1er AUTOR)

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. 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. El proceso se repite indefinidamente. El desarrollo evolutivo no demanda una forma especfica de observar el desarrollo de algn incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado tambin. Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentacin debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada. Hay 2 tipos de desarrollo evolutivo: 1. Desarrollo exploratorio: Trabaja con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

17

2. Prototipos desechables: Busca comprender los requerimientos del cliente y desarrollar una definicin mejorada de los requerimientos. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

18

2.1.3 MODELO EVOLUTIVO (2do AUTOR)

Modelo Evolutivo. (Transparencia A.4) A partir de este modelo, encontramos los ms recientes originados del de cascada, que actualmente estn impactando y adaptndose cada vez ms a la orientacin a objetos. El modelo Evolutivo conocido tambin como incremental e iterativo, consiste en hacer la documentacin de las fases, realizando un prototipo del sistema, se evala el qu tan lejos el prototipo est de la solucin final esperada por el cliente; se toman en cuenta las observaciones de esta evaluacin, y se crea un nuevo prototipo que las incluya. Esto se realiza en una vuelta repetitiva donde se incrementa el alcance del prototipo en pequeas proporciones hasta cumplir los requerimientos totales. En este mtodo no es necesario esperar hasta que toda una fase est terminada para iniciar la siguiente. Si se cuenta con una parte del anlisis bien entendida, se puede realizar un primer diseo del corazn o de una parte medular del sistema, hacer su codificacin y con esto, formar nuestro primer prototipo que ampliaremos en las siguientes iteraciones (vueltas), creando prototipos cada vez mejores y amplios con respecto a los requerimientos originales. La ventaja es que es ideal para sistemas que no tiene bien definidos los requerimientos, es decir, para la mayora de los sistemas que se desarrollan. El cliente desde el principio tiene una idea de los requerimientos de su sistema, pero no estn claros hasta el ltimo detalle. An as podemos basarnos en lo ya entendido (cliente y desarrollador), trabajar con esta informacin, y mientras se vayan creando prototipos, el cliente detallar sus especificaciones. Su desventaja es que es difcil distinguirlo del proceso "codifica y corrige", pues en cierta medida son parecidos, la diferencia est que en la prctica se requiere que al construir el prototipo se aplique el anlisis y el diseo pero slo a una parte de los requerimientos ya entendidos, que se documente y se codifique, logrndose con todo esto, un poco de disciplina heredada del modelo en cascada, de esta manera, la desventaja no lo es tanto. La caracterstica de este modelo es que est enfocado a la produccin de prototipos.

Es un proceso repetitivo y creciente.

19

Ventaja: ideal para sistemas que no tienen bien definidos los requerimientos. Desventaja: es difcil de distinguirlo del proceso "codifica y corrige". Caracterstica: enfocado a la produccin de prototipos. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se aconsejable introducir una versin funcional limitada de alguna forma para aliviar las presiones competitivas. En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estn diseados para acomodarse a una evolucin temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estn bien definidos a nivel detalle. En el modelo cascada y cascada realimentado no se tiene demasiado en cuenta la naturaleza evolutiva del software,se plantea como esttico, con requisitos bien conocidos y definidos desde el inicio.6 Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin. Los modelos iterativo incremental y espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo.

20

2.1.4 MODELO EN ESPIRAL (1er AUTOR)

El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construccin de prototipos con los aspectos controlados y sistemticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versin incremental podra ser un modelo en papel o un prototipo, durante las ltimas iteraciones se producen versiones cada vez ms completas del sistema diseado. EL modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas REGIONES DE TAREAS , Cada una de las regiones estn compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las caractersticas del proyecto que va a emprenderse en todos los casos se aplican actividades de proteccin.

TIPOS El modelo espiral tuvo varias modificaciones que son: Modelo Original de Boehm. Modelo Tipico de Seis Regiones. Modelo WINWIN.

21

MODELO ORIGINAL DE BOEHM No hay un nmero definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestin de proyecto Cada vuelta se divide en 4 sectores:

Planeacin : determinacin de los objetivos, alternativas y restricciones Anlisis de riesgo : anlisis de alternativas e identificacin/resolucin de riesgos Ingeniera : desarrollo del producto hasta "el siguiente nivel". Evaluacin : valoracin por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteracin su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez ms completas. Uno de los puntos ms interesantes del modelo, es la introduccin al proceso de desarrollo a las actividades de anlisis de los riesgos asociados al desarrollo y a la evaluacin por parte del cliente de los resultados del software.

MODELO TIPICO DE SEIS REGIONES A diferencia del modelo de proceso clsico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Una visin alternativa del modelo en espiral puede ser considerada examinando el eje de punto de entrada en el proyecto. Las regiones de tareas que componen este modelo son:

Comunicacin con el cliente: las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente.

22

Planificacin: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras informaciones relacionadas con el proyecto. Ingeniera: las tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementacin durante la etapa de instalacin.

MODELO WINWIN El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociacin al principio de casa paso alrededor de la espiral. Ms que una simple actividad de comunicacin con el cliente se definen las siguientes actividades:

Identificacin del sistema o subsistemas clave de los directivos.

Determinacin de las condiciones de victoria de los directivos.

23

Negociacin de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisin antes de continuar el proyecto de software.

VENTAJAS

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. El modelo en espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. En la utilizacin de grandes sistemas a doblado la productividad.

DESVENTAJAS

Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable. Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas. Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos

http://modeloespiral.blogspot.mx/ 24

2.1.4 MODELO EN ESPIRAL (2do AUTOR)

Este modelo, propuesto por Bohem en 1988 [BOE88], es un modelo de proceso de software evolutivo que acompaa la naturaleza evolutiva de con los aspectos controlados y sistemticos del ciclo de vida tradicional. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En este modelo, el sistema se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones se producen versiones cada vez ms completas de ingeniera del sistema. .

El Modelo en Espiral se divide en un nmero de actividades estructurales, tambin llamadas "regiones de tareas" . Generalmente existen entre tres y seis regiones de tareas:

Comunicacin con el cliente.- Las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente, sea revisar especificaciones, plantear necesidades, etc.

Planificacin.- Las tareas requeridas para definir recursos, tiempos e informacin relacionada con el proyecto.

Anlisis de riesgos.- Las tareas requeridas para evaluar riesgos tcnicos y de gestin.

Ingeniera.- Las tareas requeridas para construir una o ms representaciones de la aplicacin

Construccin y adaptacin.- Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

25

Evaluacin del cliente.- Las tareas requeridas para obtener la reaccin del cliente, segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin

Cada una de las regiones estn pobladas por una serie de tareas que se adaptan a las caractersticas del proyecto que va a emprenderse. Para proyectos pequeos el nmero de tareas y su formalidad es bajo, para proyectos mayores y ms crticos, cada regin contiene tareas que se definen para lograr un nivel ms alto de formalidad.

Cuando empieza este proceso evolutivo, el equipo de trabajo gira alrededor de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificacin de productos, los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones ms sofisticadas del software. Cada paso de la regin de planificacin produce ajustes en el plan del proyecto. . El coste y la planificacin se ajustan en funcin de la evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para completar el proyecto o el producto software de que se trate. La siguiente figura muestra grficamente el Modelo Espiral, para las seis regiones de tareas y suponiendo un proyecto tal que forzosamente requiere iniciar en la conceptualizacin previa a la vuelta de desarrollo, an cuando hemos dicho que frecuentemente se puede iniciar desde esta tarea. Asimismo, se presenta la terminacin del proyecto en la ltima vuelta, como mantenimiento del mismo proyecto, pareciese que ah terminase el ciclo, sin embargo, la vuelta siguiente existe y correspondera al inicio de un nuevo proyecto que puede o no tomar como base el proyecto anterior.

26

MODELO EN ESPIRAL El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software en gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el usuario comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El modelo en espiral utiliza la construccin de prototipos como mecanismo de reduccin de riesgos, pero lo que es ms importante, permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. Mantiene el enfoque sistemtico de los pasos sugeridos por el ciclo de vida clsico, pero lo incorpora al marco de trabajo interactivo que refleja mejor el mundo real. El modelo demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemticos. Pero al igual que otros modelos, ste no es la panaca. Puede resultar difcil convencer a grandes clientes, (particularmente en situaciones bajo contrato) de que el enfoque evolutivo que presenta este modelo es controlable. Requiere una considerable habilidad para la evaluacin del riesgo, y de ello depende el xito. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. Finalmente, en s mismo, el modelo es relativamente nuevo y no se ha utilizado tanto como otros. Todava tendr que pasar muchas pruebas para certificar los beneficios que la utilizacin de este prometedor modelo parece ofrecer para el desarrollo de sistemas de informacin.

http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_externos/Administracion_infor matica_de_las_organizaciones_Ramon_E_Enriquez_Gonzalez/AIO2_Mod_ESPIRAL.html

27

2.1.5 PROTOTIPOS (1er AUTOR)

El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estn de acuerdo en lo que se necesita as como tambin la solucin que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseos para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real. Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no est seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interacta el hombre y la mquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. El paradigma de construccin de prototipos tiene tres pasos: Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las reas donde es obligatorio ms definicin. Construir y revisar la maqueta (prototipo). El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. Este modelo es til cuando: El cliente no identifica los requisitos detallados. El responsable del desarrollo no est seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-mquina.

28

Etapas para la elaboracin del Modelo de Prototipo.

Figura 1. Etapas del Modelo de prototipo

Ciclo de Vida de un Sistema basado en Prototipo. Una maqueta o prototipo de pantallas muestra la interfaz de la aplicacin, su cara externa, pero dicha interfaz est fija, esttica, no procesa datos. El prototipo no tiene desarrollada una lgica interna, slo muestra las pantallas por las que ir pasando la futura aplicacin. Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que satisface los requisitos y necesidades que se han entendido claramente. Realiza, por tanto, un un proceso real de datos, para contrastarlo con el usuario. Se va modificando y desarrollando sobre la marcha, segn las apreciaciones del cliente. Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el software est constantemente variando, pero, a la larga, genera un producto ms seguro, en cuanto a la satisfaccin de las necesidades del cliente. Cuando un prototipo se desarrolla con el slo propsito de precisar mejor las necesidades del cliente y despus no se va a aprovechar ni total ni parcialmente en la implementacin del sistema final se habla de un prototipo desechable. Para que la construccin de prototipos sea posible se debe contar con la participacin activa del cliente.

29

Figura 2. Ciclo de Vida del prototipo Ventajas del Modelo de Prototipo. Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina.

Desventajas del Modelo de Prototipo. Su principal desventaja es que una vez que el cliente ha dado su aprobacin final al prototipo y cree que est a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo ms seguro es que el desarrollador haya hecho compromisos de implementacin para hacer que el prototipo funcione rpidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que est escrito en un lenguaje de programacin inadecuado. El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido construido con "plastilina y alambres", y puede desilusionarse al decirle que el sistema an no ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

http://gestionrrhhusm.blogspot.mx/2011/05/modelo-de-prototipo.html

30

2.1.5 PROTOTIPOS (2do AUTOR)

En Ingeniera de software El Modelo de construccin de prototipos que pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que ste sea aprobado nosotros podemos iniciar el verdadero desarrollo del software. Etapas Comunicacin Plan rpido Modelado, diseo rpido Construccin del Prototipo Desarrollo, entrega y retroalimentacin

El paradigma de construccin de prototipos se inicia con la Comunicacin. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es necesaria ms definicin. Entonces se plantea con rapidez esto es el plan rapido, es cuando despus de hablar del uso general del prototitpo se empieza con una iteracin de construccin de prototipos y se presenta el modelado (en la forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el usuario final. El diseo rpido conduce a la Construccin de un prototipo. El prototipo lo evala el usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. El desarrollo la entrega y la retroalimentacin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer.

Ventajas Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

31

Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humanomquina. La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos Inconvenientes El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin.
http://es.scribd.com/doc/42874496/Modelo-de-prototipos

32

2.1.6 DESARROLLO BASADO EN COMPONENTES (1er AUTOR)

El modelo basado en componentes es un paradigma de desarrollo, donde el software es desarrollado mediante la reutilizacin de componentes de software pre-existentes. Emergi como una importante solucin al problema del desarrollo de sistemas grandes y complejos, se caracteriza por ser: Evolutivo por naturaleza Exige un enfoque iterativo para la creacin de software Contiene diagramas de componentes y/o Interfaces Componentes y nodos Restricciones

El desarrollo de software basado en componentes permite reutilizar piezas de cdigo pre-elaborado que permite realizar diversas tareas, conllevando a diversos beneficios como: La mejora a la calidad La reduccin del ciclo de desarrollo y Mayor retorno sobre la inversin

El reutilizar trozos de experiencias, ideas y artefactos, no solo asegura no volvera cometer errores del pasado sino que se puede lograr construir cosas cada vez ms grandes y maravillosas, con bases firmes y calidad incomparable. Algunas ventajas que pueden ser destacadas en este modelo de componentes consisten en: La reutilizacin de software Simplificacin de pruebas Simplificacin del mantenimiento del sistema Mayor calidad, Ciclos de desarrollo ms corto y Funcionalidad mejorada

El modelo basado en componentes es un proceso que concede particular importancia al diseo y la construccin de sistemas basados en computadoras que utilizan componentes de software reutilizable. Segn Clements esta cambiando la forma en que se desarrollan los grandes sistemas de software encarnando la filosofa de comprar , no construir.

33

De esta forma cambio el inters de programar software por componer sistemas de software, la implementacion ha dado paso a la integracin como centro de enfoque. Superficialmente parece bastante similar a la ingeniera de software orientada a objetos convencional, el proceso comienza cuando un equipo de software establece requisitos para el sistema que se construira mediante tcnicas convencionales de investigacin de requisitos, se establece un diseo arquitectnico, pero no se dirige inmediatamente a las tareas de diseo mas detalladas, el equipo examina los requisitos para determinar que subconjunto estan dispuestos para la composicin y no para la construccin, para esto no planteamos las siguientes preguntas: Hay componentes comerciales de linea(CDL) disponibles para

implementar los requisitos? Hay disponibles componentes reutilizables desarrollados internamente para implementar los requisitos? Las interfaces para los componentes disponibles son compatibles dentro de la arquitectura del sistema que se construir? En caso tal existan requisitos donde no se pueda implementar con CDL o de desarrollo propio se aplicaran mtodos de software en la construccin de aquellos nuevos componentes que deben desarrollarse para satisfacer los requerimientos. Mientras que para los requisitos que se abordan con los componentes disponibles comienza un conjunto diferente de actividades de ingeniera del software : cualificacin, adaptacin, composicin y actualizacin.

http://guillermofonseca.wordpress.com/2011/03/29/modelo-de-desarrollo-de-softwarebasado-en-componentes/

34

2.1.6 DESARROLLO BASADO EN COMPONENTES (2do AUTOR)

Un componente es una pieza de cdigo preelaborado que encapsula alguna funcionalidad expuesta a travs de interfaces estndar. Es algo muy similar a lo que podemos observar en el equipo de msica que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseado para acoplarse perfectamente con sus pares, las conexiones son estndar y el protocolo de comunicacin est ya preestablecido. Al unirse las partes, obtenemos msica para nuestros odos.
El paradigma de ensamblar componentes y escribir cdigo para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes. Desarrollo basado en componentes El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creacin del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases). El modelo de desarrollo basado en componentes conduce ala reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un ndice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software. El proceso unificado de desarrollo de software representa un nmero de modelos de desarrollo basado en componentes que han sido propuestos en la industria. El lenguaje de modelado unificado define los componentes. Utilizando una combinacin del desarrollo incremental e interactivo, el proceso unificado define la funcin del sistema aplicando un enfoque basado en escenarios. El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos ms efectivos para la construccin de grandes sistemas y aplicaciones de software. Una vez que la mayor parte de los aspectos funcionales de esta disciplina comienzan a estar bien definidos, la atencin de la comunidad cientfica comienza a centrarse en los aspectos extra funcionales y de calidad, como un paso hacia una verdadera ingeniera. En este artculo se discuten precisamente los aspectos de calidad relativos a los componentes software y a las aplicaciones que con ellos se construyen, con especial nfasis en los estndares internacionales que los definen y regulan, y en los problemas que se plantean en este tipo de entornos. Beneficios del Desarrollo de Software Basado en Componentes El uso de este paradigma posee algunas ventajas: 1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software. 2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.

35

3. Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes del sistema. 4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del tiempo La Notacin de Componentes Un componente puede ser algo como un control Actives; tanto un componente de la Interfaz de usuario como un servidor de reglas de negocio. El Diagrama de Componentes El diagrama de componentes muestra la relacin entre componentes de software, sus dependencias, su comunicacin su ubicacin y otras condiciones. Interfaces Los componentes tambin pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un componente est ofreciendo y dejando disponibles a otros componentes de software y clases. Tpicamente, un componente est compuesto por numerosas clases y paquetes de clases internos. Tambin se puede crear a partir de una coleccin de componentes ms pequeos. Los componentes y los Nodos Un diagrama de despliegue muestra el despliegue fsico del sistema en un ambiente de produccin (o de prueba). Muestra dnde se ubican los componentes, en qu servidores, mquinas o hardware. Puede representar los enlaces de redes. Restricciones Los componentes pueden restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo que debe ser verdadero antes de que un componente pueda realizar alguna funcin; las post-condiciones indican lo que debe ser verdadero despus de que un componente haya realizado algn trabajo y los invariantes especifican lo que debe permanecer verdadero durante la vida del componente. Tenemos la fortuna de presenciar el nacimiento de una nueva forma de hacer software, que traer beneficios inmensos para todos. El desarrollo de software basado en componentes desde siempre fue la idea revolucionaria que nos llev a pensar que s era posible el construir software de calidad en corto tiempo y con la misma calidad que la mayora de las industrias de nuestro tiempo. Al mirar hacia atrs, vemos los increbles avances que hemos logrado en la comprensin de la forma correcta de reutilizar el software y el conocimiento existente, y nos asombramos cada vez ms al darnos cuenta de que este solo es el inicio. El desarrollo de software basado de componentes se convirti en el pilar de la Revolucin Industrial del Software y se proyecta hoy en da en diversas nuevas formas de hacer software de calidad con los costos ms bajos del mercado y en tiempos que antes eran impensables. Empresas como Microsoft entendieron el potencial de esta metodologa hace aos y hoy nos ofrecen nuevas iniciativas y herramientas que

36

buscan llevar al proceso de construccin de software hacia el sitial privilegiado en el que debi colocarse desde un principio. Anlisis del riesgo Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. Ventajas El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. - Reduce riesgos del proyecto - Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento Desventajas: Genera mucho tiempo en el desarrollo del sistema - Modelo costoso Requiere experiencia en la identificacin de riesgos Inconvenientes Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difcil).

http://ingenieraupoliana.blogspot.mx/2010/10/modelo-de-desarrollo-basado-en.html

37

2.2 OTRAS METODOLOGIAS 2.2.1 GANAR-GANAR (1er AUTOR)

El modelo ganar-ganar (en ingls, win-win) extiende el modelo espiral, haciendo nfasis en la identificacin de las condiciones de ganancia para todas las partes, creando un plan para alcanzar las condiciones ganadoras y evitar los riesgos correspondientes. Se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas. El modelo no necesita mucho tiempo de gestin. Esto permite utilizarlo tanto en proyectos pequeos como grandes. Se consideran cuatro los ciclos, cada uno compuesto de cuatro actividades. Las cuatro actividades son:

Elaborar los objetivos, restricciones y alternativas del proceso y producto del sistema y subsistema Evaluar las alternativas con respecto a los objetivos y restricciones. Identificar y resolver las fuentes principales de riesgo en el proceso y el producto. Elaborar la definicin del producto y proceso. Planear el siguiente ciclo, actualizando el plan del ciclo de vida, incluyendo la particin del sistema en subsistemas para ser considerados en ciclos paralelos, lo cual puede incluir un plan para terminar el proyecto si es muy riesgoso o no es factible, asegurando el compromiso de la administracin para continuar segn lo planeado. Una vez revisadas las actividades, los ciclos definen lneas especficas a seguir. En el Ciclo 0 (grupos de aplicacin) se determina la viabilidad de un grupo apropiado de aplicaciones. En el Ciclo 1 (objetivos del ciclo de vida de la aplicacin) se desarrollan los objetivos del ciclo de vida, incluyendo prototipos, planes y especificaciones de aplicaciones individuales, y se verifica la existencia de al menos una arquitectura viable para cada aplicacin. En el Ciclo 2 (arquitectura del ciclo de vida de la aplicacin) se establece una arquitectura del ciclo de vida detallado, se verifica su viabilidad, y se determina que no existen riesgos mayores en satisfacer los planes y especificaciones.

38

En el Ciclo 3 (capacidad de operacin inicial) se alcanza una capacidad operacional inicial para cada etapa crtica del proyecto en el ciclo de vida del software. Las creencias del modelo son: crear software basado en componentes para lograr mayor calidad en los sistemas de mayor tamao, escribir software reutilizable para hacer eficiente el proceso de desarrollo, medir la calidad del sistema como aspecto clave del desarrollo del producto, lograr mayor calidad en el proceso de ensamblaje a partir de componentes menores, usar tecnologas basadas en objetos como aspecto bsico para lograr la calidad, producir sistemas rpidamente (sencillos, confiables y de calidad) empleando procesos bien definidos, utilizar el modelo espiral como base del proceso, hacer flexible el proceso de creacin del software para lograr los objetivos generales de eficiencia, involucrar al cliente mediante el manejo de prototipos y analizar los riesgos en el proceso del desarrollo del software para asegurar la calidad final del sistema. En el sistema GA se basa principalmente en resolver los problemas que puedan surgir en el software y as poder tener un mejor producto y uso del mismo, para lograr esto se usaran los manuales de contingencia y de mantenimiento. Para justificar de una forma ms exacta el uso de dicho modelo en el sistema GA es porque este modelo se basa principalmente del modelo espiral el cual tiene una secuencias de actividades como son el anlisis, diseo, pruebas, implementacin; el sistema GA utilizo todas estas actividades para poder ser realizado con esto podemos destacar que se podrn obtener a su vez las diferentes versiones que pueden ser realizadas por medio de dichas actividades, ya que nuestro sistema GA tendr diferentes actualizaciones que se enfocan en las versiones de mismo. Tambin podemos destacar que nuestro sistema se basa en la tecnologa gratuita para el software y esto a su vez mejor la calidad del mismo, ya que el modelo Ganar-ganar se basa principalmente en la calidad y eficiencia de un sistema.

http://ithuejutlagabrielarb.blogspot.mx/

39

2.2.1 GANAR-GANAR (2do AUTOR)

Las mejores negociaciones se esfuerzan en obtener victoria -victoria. Esto es, el cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.

Se basa en el modelo en espiral Este modelo se basa principalmente del modelo espiral, el cual tiene una secuencia de actividades como son el anlisis, diseo, pruebas, implementacin.

Ciclos Se consideran cuatro los ciclos, compuestos cada uno de cuatro actividades que se detallan a continuacin: Elaborar los objetivos, restricciones y alternativas del proceso y producto del sistema y subsistema. Evaluar las alternativas con respecto a los objetivos y restricciones. Elaborar la definicin del producto y proceso. Planear el siguiente ciclo y actualizar el plan de su ciclo de vida, incluyendo la particin del sistema en subsistemas para ser considerados en ciclos paralelos.

Ciclo 0. Grupos de aplicacin. Se determina la viabilidad de un grupo apropiado de aplicaciones. Ciclo 1. Objetivos del ciclo de vida de la aplicacin. Se desarrollan los objetivos del ciclo de vida, incluyendo prototipos, planes y especificaciones de aplicaciones individuales, y se verifica la existencia de al menos una arquitectura viable para cada aplicacin. Ciclo 2. Arquitectura del ciclo de vida de la aplicacin. Se establece una arquitectura del ciclo de vida detallado, se verifica la viabilidad y determina que no existen riesgos mayores en satisfacer los planes y especificaciones. Ciclo 3. Capacidad de operacin inicial. Alcanzar una capacidad operacional inicial para cada etapa crtica del proyecto en el ciclo de vida del software

40

El significad de la palabra "ganar - ganar" es el grado de satisfaccin que alcanzan ambas partes, pero `para lograr tal agrado es importante tomar en cuenta lo siguiente: Se les pide a los usuarios, clientes e interesados, que ordenen sus requisitos y despues discutan los conflictos relacionados con la prioridad. Se le identifican y analizan los riesgos asociados con cada requisito. Se hacen estimaciones preliminares del esfuerzo requerido para su desarrollo y despues se utlizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre todo en el tiempo de entrega para as lograr la satisfaccin de las partes.

http://elmundodelingeniero.blogspot.mx/2011_02_01_archive.html

41

2.2.2 PROCESO UNIFICADO (UP) (1er AUTOR)

El proceso unificado (en ingls, UPunifi ed process) es una extensin al proceso objectory (del ingls object factory), que tiene sus orgenes en la dcada de los aos 80. Estos modelos de proceso se basan principalmente en la especificacin de requerimientos de un sistema mediante casos de uso (maneras de utilizar un sistema). El proceso unificado considera como aspecto esencial del desarrollo de software una visin que parte de la arquitectura del sistema, siguiendo un proceso iterativo e incremental. El proceso considera e integra diferentes aspectos, como son los ciclos, fases, flujos de trabajo, mitigacin de riesgo, control de calidad, administracin de proyecto y control de configuracin. De manera adicional, el proceso unificado considera las cuatro P del desarrollo de software: personas, proyecto, producto y proceso. El proceso unificado tiene las siguientes creencias: para construir un sistema exitoso se debe conocer qu quieren y necesitan los usuarios potenciales; al igual que la arquitectura, en la construccin, permite disear edificios desde mltiples puntos de vista, estructura, electricidad, etc., las arquitecturas de los sistemas de software deben permitir visualizar un sistema desde mltiples perspectivas; y el desarrollo de un producto de software comercial puede significar un gran esfuerzo continuando por meses, aos o incluso ms, por lo que es prctico dividir el trabajo en pedazos, donde cada iteracin resulta en un incremento del proyecto. El proceso unificado considera como aspecto esencial del desarrollo de software una visin que parte de la arquitectura del sistema, siguiendo un proceso iterativo e incremental. El proceso considera e integra diferentes aspectos, como son los ciclos, fases, flujos de trabajo, mitigacin de riesgo, control de calidad, administracin de proyecto y control de configuracin. El Proceso Unificado tiene dos dimensiones Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lgica de acuerdo a su naturaleza. La primera dimensin representa el aspecto dinmico del proceso conforme se va desarrollando, se expresa en trminos de fases, iteraciones e hitos (milestones). La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.

42

Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema por desarrollar. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema.

UP Divide El Trabajo De Desarrollo De Software En Cuatro Fases: Fase de Inicio en UP: En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad del proyecto a realizar, se representa el modelo de negocio, visin y metas del proyecto, se identifican actores, conceptos de dominio y deseos de usuario. Adicionalmente se complementa con la definicin de la arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos. Tambin se define la viabilidad del proyecto. Fase de Elaboracin en UP: En la fase de elaboracin se obtiene la visin refinada del proyecto a realizar, la implementacin iterativa del ncleo central de la aplicacin, la resolucin de los riesgos ms altos, la identificacin de nuevos requisitos y nuevos alcances, y estimaciones ms ajustadas. A esta altura existe la posibilidad de detener el proyecto por complejidad tcnica. Fase de Construccin en UP: La fase de construccin es la implementacin iterativa del resto de los requisitos de menor riesgo y elementos ms sencillos. Es la evolucin hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el cliente y la direccin del proyecto han acordado. La mayora de los casos de uso que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso durante esta fase. Fase de Transicin en UP: Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (instalado). Caractersticas

Est dirigido por casos de uso (vase la seccin sobre UML). Est centrado en la arquitectura (es decir, en una solucin de conjunto.

43

Tiene un ciclo de vida iterativo incremental (vase ms adelante). Ventajas: Su uso es libre (como decir barra libre, sin condiciones). Hay excelentes textos, que explican la aplicacin de este proceso paso a paso, como UML y patrones, de Craig Larman, publicado por PearsonPrentice Hall (Segunda Edicin, Madrid, 2003). Desventaja: Es necesario aterrizar los conceptos, lo cual puede resultar un poco difcil para quien no tenga experiencia en el uso de procesos de ingeniera de software.

http://ithuejutlajoseluisvite.blogspot.mx/

44

2.2.2 PROCESO UNIFICADO (UP) (2do AUTOR)

El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. El Proceso Unificado tiene dos dimensiones Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lgica de acuerdo a su naturaleza. La primera dimensin representa el aspecto dinmico del proceso conforme se va desarrollando, se expresa en trminos de fases, iteraciones e hitos (milestones). La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles. El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en construccin est hecho de componentes de software interconectados por medio de interfaces bien definidas (well-defined interfaces). El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparacin de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par. Los aspectos distintivos del Proceso Unificado estn capturados en tres conceptos clave: dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace nico al Proceso Unificado.

45

El Proceso Unificado es dirigido por casos de uso Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema por desarrollar. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema. Una especificacin funcional tradicional se concentra en responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo. An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. El Proceso Unificado est centrado en la arquitectura El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver una radiografa completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que est siendo construido. El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como estn reflejadas en los casos de uso. Sin embargo, tambin est influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutar, la disponibilidad de componentes reutilizables, consideraciones de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo con las caractersticas ms importantes hechas ms visibles y dejando los detalles de lado. Ya que lo importante depende en parte del

46

criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reuso. Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso funcin corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del huevo y la gallina. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo. El Proceso Unificado es Iterativo e Incremental Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o aos. Es prctico dividir el trabajo en pequeos pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada. Los desarrolladores basan su seleccin de qu van a implementar en una iteracin en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteracin trata con los riesgos ms importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteracin anterior. En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseo usando la arquitectura como gua, implementan el diseo en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.

http://itg-gabriel.blogspot.mx/

47

2.2.3 INGENIERA WEB (1er AUTOR)

La ingeniera web es la aplicacin de metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones de alta calidad en la World Wide Web. La ingeniera web se debe al crecimiento desenfrenado que est teniendo la Web est ocasionando un impacto en la sociedad y el nuevo manejo que se le est dando a la informacin en las diferentes reas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta va. Desde que esto empez a suceder el Internet se volvi ms que una diversin y empez a ser tomado ms en serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafo para los (Ingeniera del software) ingenieros del software, a raz de esto se crearon enfoques disciplinados, sistemticos y metodologas donde tuvieron en cuenta aspectos especficos de este nuevo medio. Entonces la ingeniera de la Web es la aplicacin de metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones de alta calidad en la World Wide Web. [] En este sentido, la ingeniera de la Web hace referencia a las metodologas, tcnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web complejas y de gran dimensin en las que se apoya la evaluacin, diseo, desarrollo, implementacin y evolucin de dichas aplicaciones. El desarrollo de aplicaciones Web posee determinadas caractersticas que lo hacen diferente del desarrollo de aplicaciones o software tradicional y sistemas de informacin. La ingeniera de la Web es multidisciplinar y aglutina contribuciones de diferentes reas: arquitectura de la informacin, ingeniera de hipermedia/hipertexto, ingeniera de requisitos, diseo de interfaz de usuario, usabilidad, diseo grfico y de presentacin, diseo y anlisis de sistemas, ingeniera de software, ingeniera de datos, indexado y recuperacin de informacin, testeo, modelado y simulacin, despliegue de aplicaciones, operacin de sistemas y gestin de proyectos. La ingeniera de la Web no es un clon o subconjunto de la ingeniera de software aunque ambas incluyen desarrollo de software y programacin, pues a pesar de que la ingeniera de la Web utiliza principios de ingeniera de software, incluye nuevos enfoques, metodologas, herramientas, tcnicas, guas y patrones para cubrir los requisitos nicos de las aplicaciones web. Sin embargo el trmino de ingeniera de la web ha sido un trmino muy controvertido especialmente para profesionales en disciplinas tales como la ingeniera del software ya que no la consideran como un campo dentro de la ingeniera.

48

Los principales aspectos de la ingeniera de la Web incluyen, entre otros, los siguientes temas:

Diseo de procesos de negocio para aplicaciones web. Herramientas CASE para aplicaciones web. Generacin de cdigo para aplicaciones web. Desarrollo web colaborativo. Modelado conceptual de aplicaciones web. Diseo de Modelos de datos para sistemas de informacin web. Ingeniera web emprica. Entornos de desarrollo de aplicaciones web integrados. Herramientas de autor para contenido multimedia. Pruebas de rendimiento de aplicaciones basadas en web. Personalizacin y adaptacin de aplicaciones web. Herramientas y mtodos de prototipado. Control de calidad y pruebas de sistemas. Ingeniera de requisitos para aplicaciones web. Aplicaciones para la Web Semntica. Factoras de software para la web. Mtodos, herramientas y automatizacin de pruebas para aplicaciones web. Aplicaciones web mviles y ubcuas. Usabilidad de aplicaciones web. Accesibilidad para la web. Metodologas de diseo web. Formacin en ingeniera de la web. Diseo de interfaces de usuario. Mtricas para la web, estimacin de costes y medicin. Gestin de proyectos web y gestin de riesgos. Desarrollo y despliegue de servicios web.

Categoras Los sitios web pueden ser categorizados de la siguiente forma:

Slo esttico que se enfoca en la organizacin de la estructura y el contenido, en la forma como se va a presentar la informacin y que sea fcil de manejar para cualquier usuario, pero debe tener en cuenta la eficiencia y la confiabilidad. Sitio esttico con formularios de entrada este sitio tiene las mismas caractersticas que el anterior, adicionndole que l le permite a los usuarios la interaccin por medio de cuestionarios, comentario y sugerencias. Sitio con acceso de datos dinmicos aqu, adems de las caractersticas antes mencionadas, cuenta con bases de datos en las cuales el usuario puede realizar consultas y bsquedas. Sitio creado dinmicamente en este sitio los requerimientos son parecidos pero deben suplir con las necesidades de cada usuario;

49

creando sitios dinmicos que sean compatibles con el entorno de navegacin de cada usuario. Aplicacin de software basada en la Web este sitio puede tener todas las caractersticas antes mencionadas, pero logrando un parecido con una implementacin cliente/servidor comnmente conocido que a un sitio web esttico.

Con el pasar del tiempo y la constante evolucin tecnolgica que atraviesa nuestro mundo circundante hemos podido observar la necesidad y la utilidad de la red de redes; Internet para mejorar de cierta manera nuestras condiciones de vida y as fortalecer ms nuestro proceso de formacin educativa y contribuir con un mejoramiento del global de las necesidades de cada quien observemos que un proyecto que comenz meramente con fines militares para no centralizar los datos, ha tenido un crecimiento significable hoy en da el mundo se mueve con la web, ayudando a pequeas, medianas y grandes empresas as como todo entidad educativa. Tengamos en cuenta que empresas mueven sus negocios por medio de la internet y que hasta polticas como el CRM para el manejo de clientes, son muy importantes para las empresas como por ejemplo, Dell, surgen polticas para el mantener los clientes y tenerlos en contactos va Web, mediante Internet se cuidada de cierta manera la imagen de una empresa, por ejemplo mediante el marketing a travs de Internet permite reforzar el servicio, haciendo ms fuerte la relacin entre la marca y el cliente. Esto implica un uso creativo del medio, involucrando verdaderamente a las personas con la compaa. Utilizando la inmediatez, que brinda esta va de comunicacin. Con la herramienta comunicacional, se permite una relacin constante e inmediata con los clientes, as como mantener a los clientes contentos, conquistar nuevos nichos de mercado y, por ende, incrementar las ventas. Debemos tener en cuenta que para la efectiva comunicacin en la web, se tienen protocolos que es como el lenguaje para que se haga efectiva el intercambio de comunicacin, vale la pena preguntarse, as para poder acceder a toda la informacin que nos puede suministrar Internet slo debes poseer un servicio de algn proveedor de Internet un navegador como Mozilla o Netscape. Por medio de un sitio web podremos tener nuestro sitio accesible o disponible 24 horas al da, 365 das del ao en absolutamente todo el mundo para quienes tienen acceso; es decir, cerca de 600 millones de personas aproximadamente, es por esto que nuestros datos en internet publicados en el sitio web podran ser accesibles a toda persona en cualquier momento en cualquier parte del mundo. Todas estas consideraciones nos llevan a la conclusin de que un sitio web bien logrado no es nicamente un espacio en la red para ver el mismo comercial que en televisin; es en realidad una extensin de las empresas o instituciones, as mismo teniendo en cuenta la importancia y aplicabilidad que

50

tiene la ingeniera Web en nuestro desarrollo cognitivo, social y vivencial es fcil visionar que cada una de las funciones que ella emana estarn siempre ligadas a la vanguardia del desarrollo progresivo de la tecnologa y del hombre. Naturaleza multidisciplinaria De acuerdo con esto, la ingeniera Web puede utilizar una parte de cada una de estas disciplinas y no ser dominada por puntos de vista muy particulares, es una respuesta de carcter multidisciplinario para las aplicaciones Web. Usualmente, las aplicaciones web son multidisciplinares, ya que son construidas en un medio constantemente cambiante, donde los requerimientos son inestables, los equipos de desarrollo generalmente son pequeos, las comunidades de usuarios son ms amplias que antes y la competicin ahora es a nivel mundial. En general, las aplicaciones web, necesitan ser funcionales, mantenibles, escalables y seguras. Como podemos ver, la actual demanda de las aplicaciones web es totalmente diferente de las aplicaciones convencionales y por lo tanto hay una gran necesidad de la ingeniera web.

http://es.scribd.com/doc/131732168/UnidaII-Ingenieria-de-Software

51

2.2.3 INGENIERA WEB (2do AUTOR)

Es una aplicacin de software que permite al usuario recuperar y visualizar documentos de hipertexto, comnmente descritos en HTML. Los sitios web pueden ser categorizados de la siguiente forma: Slo esttico que se enfoca en la organizacin de la estructura y el contenido, en la forma como se va a presentar la informacin y que sea fcil de manejar para cualquier usuario, pero debe tener en cuenta la eficiencia y la confiabilidad. Sitio esttico con formularios de entrada este sitio tiene las mismas caractersticas que el anterior, adicionndole que el le permite a los usuarios la interaccin por medio de cuestionarios, comentario y sugerencias. Sitio con acceso de datos dinmicos aqu, adems de las caractersticas antes mencionadas, cuenta con bases de datos en las cuales el usuario puede realizar consultas y bsquedas. Sitio creado dinmicamente en este sitio los requerimientos son parecidos pero deben suplir con las necesidades de cada usuario; creando sitios dinmicos que sean compatibles con el entorno de navegacin de cada usuario. Aplicacin de software basada en la Web este sitio puede tener todas las caractersticas antes mencionadas, pero logrando un parecido con una implementacin cliente/servidor comnmente conocido que a un sitio web esttico.

En general, las aplicaciones web, necesitan ser funcionales, mantenibles, escalables y seguras. Como podemos ver, la actual demanda de las aplicaciones web es totalmente diferente de las aplicaciones convencionales y por lo tanto hay una gran necesidad de la ingeniera web. Las actividades que forman parte del proceso son: Formulacin Planificacin Anlisis Modelizacin Generacin de pginas Test

52

Evaluacin del cliente

Formulacin: Identifica objetivos y establece el alcance de la primera entrega. Planificacin: genera la estimacin del coste general del proyecto, la evaluacin de riesgos y el calendario del desarrollo y fechas de entrega. Anlisis: El anlisis especifica los requerimientos e identifica el contenido. Modelizacin: se compone de dos secuencias paralelas de tareas. Una consiste en el diseo y produccin del contenido que forma parte de la aplicacin. La otra, en el diseo de la arquitectura, navegacin e interfaz de usuario. Generacin de pginas: se integra contenido, arquitectura, navegacin e interfaz para crear esttica o dinmicamente el aspecto ms visible de las aplicaciones, las pginas. El test: el test busca errores a todos los niveles: contenido, funcional, navegacional, rendimiento, etc. El hecho de que las aplicaciones residan en la red, y que inter-operen en plataformas muy distintas, hace que el proceso de test sea especialmente difcil.

La Ingeniera de la Web no es un clon o subconjunto de la ingeniera de software aunque ambas incluyen desarrollo de software y programacin, pues a pesar de que la Ingeniera de la Web utiliza principios de ingeniera de software, incluye nuevos enfoques, metodologas, herramientas, tcnicas, guas y patrones para cubrir los requisitos nicos de las aplicaciones web. Adems, existen ciertos aspectos que van ligados a la ingeniera web y que son de mucha utilidad para las aplicaciones que realicen, aqu los ms importantes para m:

Diseo de procesos de negocio para aplicaciones web Generacin de cdigo para aplicaciones web Desarrollo web colaborativo Ingeniera web emprica Entornos de desarrollo de aplicaciones web integrados

Ingeniera de software. Por Shari Lawrence Peleeger.

53

2.2.4 METODOLOGIAS AGILES (1er AUTOR)

Qu es una metodologa gil? Consiste en desarrollar una pequea parte del software que se desea construir. De esta forma, el cliente nos indica si vamos por el buen camino, estableciendo aquellas partes que le son ms relevantes y as juntos, nos aseguramos de que construimos una aplicacin que aadir valor a su negocio. *La mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo. * Las metodologas giles de desarrollo estn especialmente indicadas en proyectos con requisitos poco definidos o cambiantes. * Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo *Entrega continua y en plazos breves de software funcional *Trabajo conjunto entre el cliente y el equipo de desarrollo Importancia de la simplicidad, eliminado el trabajo innecesario * Atencin continua a la excelencia tcnica y al buen diseo * Mejora continua de los procesos y el equipo de desarrollo Nota. La definicin moderna de desarrollo gil de software evolucion a mediados de los aos 1990 como parte de una reaccin contra los mtodos de "peso pesado", muy estructurados y estrictos, extrados del modelo de desarrollo en cascada.. La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento.. Las metodologas livianas Dieron paso al termino giles Consideraba por muchos desarrolladores como meramente intuitiva. En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace formalmente el trmino gil aplicado al desarrollo. La agilidad es un comportamiento persistente o habilidad, de entidad sensible, que presenta flexibilidad para adaptarse a cambios, esperados o inesperados, rpidamente; persigue la duracin ms corta en tiempo; usa instrumentos econmicos, simples y de calidad en un ambiente dinmico; y utiliza los conocimientos y experiencia previos para aprender tanto del entorno interno como del externo. Existen valores principales del desarrollo AGIL que se manifiestan de la siguiente manera, en los cuales se valora A :

54

*Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. *Desarrollar software documentacin. que funciona ms que conseguir una buena

*La colaboracin con el cliente ms que la negociacin de un contrato. *Responder a los cambios ms que seguir estrictamente un plan.

Los valores anteriores inspiran los doce principios del manifiesto: La prioridad es satisfacer al cliente. Dar la bienvenida a los cambios. Entregar frecuentemente software que funcione con el menor intervalo de tiempo posible entre entregas. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. Construir el proyecto entorno a individuos motivados. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. El software que funciona es la medida principal de progreso. Los procesos giles promueven un desarrollo sostenible. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. La simplicidad es esencial. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento. Aunque el manifiesto gil es la piedra angular sobre la que cimientan todas las metodologas giles, cada una tiene unas caractersticas propias y hace hincapi en algunos aspectos ms especficos. En esta seccin se describen, a grandes rasgos, las particularidades fundamentales de algunas otras metodologas giles, que actualmente tienen gran aceptacin en el mercado.

55

EJEMPLOS DE METODOLOGIAS AGILES *Programacin Extrema o XP- eXtremeProgramminges uno de los ejemplos ms exitosos de metodologa gil. *Scrum *Crystal *Feature Driven Development (FDD) *Adaptive Software Development (ASD) *Lean Development (LD XP Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. Oficialmente fue creada en 1999 por Kent Beck, con la publicacin de su libro Extreme Programming Explained. XP se centra en la continua retroalimentacin entre el cliente y el equipo de desarrollo, la comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define como una metodologa especialmente adecuada para proyectos con requisitos muy cambiantes e imprecisos, donde existe un alto riesgo tcnico. Como metodologa pragmtica, recoge las que considera mejores prcticas para el desarrollo software, cuya aplicacin disciplinada pretende disminuir la curva exponencial del costo del cambio a lo largo del proyecto. Se trata de doce prcticas: el juego de la planificacin, entregas pequeas, metfora, diseo simple, pruebas, refactorizacin, programacin en parejas, propiedad colectiva del cdigo, integracin continua, 40 horas por semana, cliente in-situ y estndares de programacin. Una posterior revisin de la metodologa clasific las prcticas en primarias, aquellas que segn Beck proporcionan una mejora inmediata independientemente de la metodologa que se est siguiendo, y secundarias, que implican una mayor dificultad si no se tiene experiencia en las prcticas primarias. Siguiendo esta clasificacin, las prcticas primarias consideradas fueron la adecuacin del lugar de trabajo, sentarse juntos, entorno de trabajo informativo, sentimiento de equipo, trabajo enrgico, programacin en parejas,

56

user stories, iteraciones cortas, integracin continua, pruebas primero, diseo incremental y refactorizacin. El conjunto de prcticas secundarias qued compuesto por la involucracin del cliente, continuidad del equipo, equipos retractiles, cdigo compartido y alcance del contrato negociado. SCRUM Est especialmente indicada para proyectos con un rpido cambio de requisitos. Sus principales caractersticas se pueden resumir en dos. Mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda caracterstica importante son las reuniones a lo largo proyecto. Una reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin. Este trmino que describe una forma para desarrollar productos iniciada en Japn. No se trata de un concepto nuevo, sino que ya en 1987 Ikujiro Nonaka y Hirotaka Takeuchi [19] acuaron este trmino, una estrategia utilizada en rugby en la que todos los integrantes del equipo actan juntos para avanzar la pelota y ganar el partido, para denominar un nuevo tipo de proceso de desarrollo de productos. Escogieron este nombre por las similitudes que consideraban que existan entre el juego del rugby y el tipo de proceso que proponan: adaptable, rpido, auto-organizable y con pocos descansos. *es un proceso para la gestin y control del producto que trata de eliminar la complejidad en estas reas para centrarse en la construccin de software que satisfaga las necesidades del negocio. Es simple y escalable, ya que no establece prcticas de ingeniera del software sino que se aplica o combina, fcilmente, con otras prcticas ingenieriles, metodologas de desarrollo o estndares ya existentes en la organizacin. *se concentra, principalmente, a nivel de las personas y equipo de desarrollo que construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de forma eficiente obteniendo productos complejos y sofisticados. Podramos entender SCRUM como un tipo de ingeniera social que pretende conseguir la satisfaccin de todos los que participan en el desarrollo, fomentando la cooperacin a travs de la auto-organizacin. De esta forma se favorece la franqueza entre el equipo y la visibilidad del producto. Pretende que no haya problemas ocultos, asuntos u obstculos que puedan poner en peligro el proyecto. Los equipos se guan por su conocimiento y experiencia ms que por planes de proyecto formalmente definidos. La planificacin detallada se realiza sobre cortos espacios de tiempo lo que permite una constante retroalimentacin que proporciona inspecciones simples y un ciclo de vida adaptable. As, el desarrollo de productos se produce de forma incremental y con un control emprico del proceso que permite la mejora continua.

57

Este Modelo de desarrollo aplicando SCRUM muestra el ciclo de vida del desarrollo que propone SCRUM para un producto software.

Las historias de usuario son el elemento base que utiliza SCRUM para describir las caractersticas que el usuario espera que tenga el software que se va a desarrollar . Por lo tanto, pueden incorporar tanto cuestiones relacionadas con las funciones del sistema como con cualquier otro aspecto del mismo (restricciones, rendimiento, etc.). Las historias de usuario se presentan desde la perspectiva del usuario. As, no se describen utilizando una terminologa tcnica sino que se escriben utilizando un lenguaje cercano al dominio de la aplicacin que se est desarrollando de forma que sea comprensible por los clientes y por los desarrolladores. Las historias de usuario se construyen bajo un mismo esqueleto que centra el foco de las caractersticas del producto. *Primero se determina quin propone la historia de usuario, *luego se describe la caracterstica que se cubre con la historia de usuario y *finalmente se especifica la razn por la que dicha caracterstica es necesaria.

CRYSTAL es un conjunto de metodologas giles para equipos de diferentes tamaos y con distintas caractersticas de criticidad. Fue propulsada por uno de los padres del Manifiesto Agil, Alistair Cockburn, que consideraba que la metodologa debe adaptarse a las personas que componen el equipo utilizando polticas diferentes para equipos diferentes. Estas polticas dependern del tamao del

58

equipo, establecindose una clasificacin por colores: Crystal Clear (3 a 8 miembros), Crystal Yellow (10 a 20 miembors), Crystal Orange (25 a 50 miembros), Crystal Red (50 a 100 miembros) y Crystal Blue (para ms de 100 miembros). Por ejemplo, Crystal Clear, la metodologa ms ligera de este conjunto, esta dirigida a la comunicacin de equipos pequeos que desarrollan software cuya criticidad no es elevada. Tiene asociadas siete caractersticas: liberacin frecuente de funcionalidad, mejora reflexiva, comunicacin osmtica, seguridad personal, atencin, fcil acceso para usuario expertos y requisitos para el entorno tcnico.

Feature Driven Development (FDD) Esta metodologa, ideada por Jeff De Luca y Peter Coad, combina el desarrollo dirigido por modelos con el desarrollo gil. Se centra en el diseo de un modelo inicial, cuyo desarrollo ser dividido en funcin a las caractersticas que debe cumplir el software e, iterativamente, se disear cada una de estas caractersticas. Por tanto, cada iteracin consta de dos partes, diseo e implementacin de cada caracterstica. Este tipo de metodologa est dirigido al desarrollo de aplicaciones con un alto grado de criticidad. Adaptive Software Development (ASD) Lean Development (LD Es una metodologa de desarrollo dirigida especialmente al desarrollo de sistemas cuyas caractersticas varan constantemente. Fue definida por Bob Charettes a partir de su experiencia en proyecto industriales, constituyendo una adaptacin para el desarrollo software de las lecciones aprendidas en la industria, en particular, en el sistema de produccin automovilista japonesa de Toyota. La metodologa establece que todo cambio en el desarrollo software conlleva riesgos, pero si se manejan adecuadamente pueden convertirse en oportunidades que mejoren la productividad del cliente. Consta de siete principios dirigidos a gestionar los cambios: eliminacin de todo aquello que no aporte valor al negocio, conocimiento incremental, toma de decisiones tan tarde como sea posible, deliberar funcionalidad tan pronto como sea posible, poder del equipo, construccin incremental del producto y perspectiva global del proyecto. Dynamic Software Development Method (DSDM) puede considerarse un marco para el proceso de produccin de software, ms que una metodologa. Naci en 1994 con el objetivo de crear una metodologa RAD (Rapid Application Development) unificada. Divide el proyecto en tres fases: pre-proyecto, ciclo de vida del proyecto y post-proyecto especificando de forma rigurosa la arquitectura y gestin del proyecto. As,

59

propone cinco fases en el desarrollo del proyecto: estudio de la viabilidad y estudio del negocio que constituyen la etapa de pre-proyecto; y, de forma iterativa, modelado funcional, diseo y construccin y finalmente implementacin, adems de una adecuada retroalimentacin a todas las fases. Sus principales caractersticas son interaccin con el usuario, poder del equipo de desarrollo, liberaciones frecuentes de funcionalidad, regirse siguiendo las necesidades del negocio, desarrollo iterativo e incremental, adaptacin a los cambios reversibles, fijar el nivel de alcance al comienzo del proyecto, pruebas durante todo el desarrollo y eficiente y efectiva comunicacin. Aunque el movimiento gil est sustentado por valores y principios para el desarrollo de productos software, la mayora de estas metodologas tienen asociadas un conjunto de prcticas, en muchos casos comunes, que buscan la agilidad en el desarrollo. En esta seccin vamos a analizar algunas de las ms relevantes: *Planificacin * programacin en parejas o pair programming *Integracin continua *Refactorizacin *Desarrollo dirigido por pruebas (Test Driven Development). Planificacin, Historias de usuario. Mientras que las metodologas convencionales centran la ingeniera de requisitos en habilidades de prediccin basndose en frreas planificaciones previas al desarrollo, las metodologas giles perciben la gestin de cambios como un aspecto inherente al proceso de desarrollo software, considerando planificaciones continuas, ms flexibles y en cortos plazos, que respondan mejor a los cambios en las necesidades del cliente. Con el objetivo de disminuir el coste, no siempre amortizable, que supone la etapa de planificacin en las metodologas convencionales, las giles simplifican las tareas de gestin y documentacin de las necesidades del sistema. Apuestan por involucrar de una forma ms intensa al cliente a lo largo de todo el proceso de desarrollo, de forma que, la comunicacin directa y frecuente retroalimentacin son las prcticas ms importantes para la planificacin y especificacin de requisitos en estas metodologas . En este proceso de definicin de las necesidades del sistema que guiar el desarrollo, se utilizan las llamadas historias de usuario para detallar, en un lenguaje cercano al cliente, la funcionalidad que debe satisfacer el sistema. Las historias de usuario se descomponen en tareas que debern ser realizadas para cumplir con la funcionalidad que se solicita. Ntese que la estimacin de tiempo no es una restriccin fija, simplemente constituye una aproximacin inicial. Se considera que las historias de usuario deben cumplir seis

60

caractersticas: independientes, negociables, valorables, estimables, pequeas y comprobables.

Programacin en pareja (Pair Programming). Una de las prcticas ms utilizadas en metodologas giles, sobre todo en sistemas de alta complejidad, es la programacin en parejas, que establece que la produccin de cdigo se realice con trabajo en parejas de programadores. El utilizar Pair Programming en un proyecto no implica que todas las lneas de cdigo sean escritas por una pareja, ya que mientras una persona est escribiendo el cdigo, la otra puede estar verificando errores, pensando en alternativas mejores, identificando casos de prueba, pensando en aspectos de diseo, etc. El objetivo principal de esta tcnica es disminuir la tasa de errores, mejorar el diseo y aspectos como la satisfaccin de los programadores. No obstante, algunos estudios como indican que se trata de una tcnica intensa y estresante para los propios programadores, aunque admiten que acelera el proceso de desarrollo. Otro detalle a tener en cuenta es las habilidades y capacidades de los miembros de la pareja. Si existe una diferencia importante entre ellos, puede llegar a ser una prctica frustrante para ambos. En este caso concreto, el Pair Programming ha de ser visto como una tcnica de aprendizaje. Integracin continua (Countinuous integration) La integracin continua pretende mitigar la complejidad que el proceso de integracin suele tener asociada en las metodologas convencionales, superando, en determinadas circunstancias, la propia complejidad de la codificacin. El objetivo es integrar cada cambio introducido, de tal forma que pequeas piezas de cdigo sean integradas de forma continua, ya que se parte de la base de que cuanto ms se espere para integrar ms costoso e impredecible se vuelve el proceso. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. Para que esta prctica sea viable es imprescindible disponer de una batera de test, preferiblemente automatizados, de tal forma, que una vez que el nuevo cdigo est integrado con el resto del sistema se ejecute toda la batera de pruebas. Si son pasados todos los test del sistema, se procede a la siguiente tarea. En caso contrario, aunque no falle el nuevo modulo que se quiere introducir en el sistema, se ha de regresar a la versin anterior, pues sta ya haba pasado la batera de pruebas. Refactorizacin. Actividad constante en los desarrollos giles cuyo objetivo es mejorar el diseo de un sistema sin influir en su funcionalidad. Se pretende reestructurar el

61

cdigo para eliminar duplicaciones, mejorar su legibilidad, simplificarlo y hacerlo ms flexible de forma que se faciliten los posteriores cambios. Recordemos que el cdigo que funciona es el principal aporte de valor para las metodologas giles, por encima de la documentacin, por lo que se enfatiza en que ste sea legible y permita la comunicacin entre desarrolladores. Desarrollo dirigido por pruebas (Test Driven Development). Al utilizar esta prctica la produccin de cdigo est dirigida por las pruebas. Concretamente, se trata de escribir las pruebas que validarn el sistema antes de comenzar a construirlo, idealmente que sea el propio cliente quien las escriba. De esta forma, ante cada modificacin del sistema la batera completa de pruebas es ejecutada. Esta prctica constituye, por tanto, la primera lnea para garantizar la calidad del producto, pues sta se considera en trminos de la correcta funcionalidad que se le ofrece al cliente. Entre las ventajas que aporta el desarrollo dirigido por pruebas podemos destacar que disminuye el tiempo dedicado a solucionar errores y genera un sentimiento de confianza de xito del proyecto en el equipo. Tecnologas como JUnit son utilizadas para manejar y ejecutar conjuntos de pruebas automatizadas. No obstante, el hecho de que aspectos tan importantes como la cohesin o el acoplamiento de los mdulos pase a un segundo plano en el desarrollo a favor de la funcionalidad, implica la necesidad de realizar constantes etapas de refactorizacin que permitan mantener la calidad del cdigo. Como se puede apreciar, a pesar de la reciente aplicacin de las metodologas giles la mayora de las prcticas propuestas no so novedosas sino que de alguna manera ya haban sido propuestas en ingeniera del software. El mrito de las metodologas giles es proponer una aplicacin conjunta, equilibrada y efectiva de forma que se complementen con ideas desde la perspectiva del negocio, los valores humanos y el trabajo. Las metodologas giles ofrecen una solucin casi a medida para una gran cantidad de proyectos. Las metodologas giles se caracterizan por su sencillez, tanto en su aprendizaje como en su aplicacin; sin embargo, gozan tanto de ventajas como de inconvenientes. Las metodologas giles permiten a los pequeos grupos de desarrollo concentrarse en la tarea de construir software fomentando prcticas de fcil adopcin y en un entorno ordenado que permiten que los proyectos finalicen exitosamente. XP es una de las metodologas giles ms extendidas y populares, adems es considerada como una metodologa posmoderna cuyas grandes capacidades se generan a travs de procesos emergentes. A pesar de las continuas criticas que las metodologas giles sufren, son usadas por muchas grandes empresas y se han utilizado en grandes sistemas, lo que hace prever que estas metodologas han llegado para quedarse.

62

Las metodologas giles son sin duda uno de los temas emergentes en ingeniera del software que est acaparando gran inters investigador. De hecho, estn ocupando un espacio destacado en la mayora de conferencias y workshops celebrados en los ltimos aos. Aunque algunas crticas argumentan que no son ms que viejo vino presentado en botellas nuevas7 otros estudios reflejan que el desarrollo de productos en entornos giles es muy diferente al desarrollo de productos en entornos convencionales, y que, por tanto, se necesitan estudios que indaguen en este sentido. Por ejemplo, en [30, 31] se analizan las diferencias existentes en el rea de ingeniera de requisitos, y en [32] aspectos relacionados con la gestin del proyecto, concluyendo que aquellas organizaciones que utilizan metodologas giles en la gestin de releases incrementan su satisfaccin. Finalmente, respecto a las metodologas giles analizadas en las investigaciones, la tabla muestra la distribucin establecida por . Este reciente estudio revisa el estado actual de la investigacin respecto a las metodologas giles. De los estudios considerados, aquellos de mayor calidad, el 76% fueron realizados utilizando XP. Metodologas como SCRUM y Lean Software Development apenas contaron con un artculo de inters cada una. Distribucin del tipo de metodologa gil utilizada en las investigaciones

La principal implicacin investigadora de este estudio establece la necesidad de realizar ms y mejores estudios de desarrollo gil. En particular, la prioridad se centra en realizar estudios sobre metodologas de gestin de proyectos como SCRUM, tal como el presentado en esta tesis de mster, por ser muy populares en la industria software pero sin apenas atencin investigadora. Por ltimo, cabe destacar un nuevo estudio realizado en , que por ser muy reciente no fue contabilizado en , en el que se analiza el proceso de autoorganizacin al que se enfrentan los equipos de desarrollo software al introducir SCRUM como metodologa para la gestin del proyecto. AUTORES.. Pilar Rodrguez Gonzlez http://oa.upm.es/1939/1/TESIS_MASTER_PILAR_RODRIGUEZ_GONZALEZ.p df

63

slideshare.net/profetiacademico/metodologias-agiles Ingenieria de software. un enfoque prctico (pressman 5th ed)

2.2.4 METODOLOGIAS AGILES (2doAUTOR)

Este en esta primera parte se describen las principales caractersticas de de las metodologas giles, expresadas en el Manifiesto, sus ventajas y desventajas, as como algunos casos donde no conviene usar mtodos giles.

Hoy en da con el auge de la tecnologa, y con el objetivo de agilizar y automatizar los procesos en el desarrollo de software, nos vemos en la necesidad de implantar Metodologas de Desarrollo de Software que nos ayuden a entregar un producto de calidad en tiempo y costo estimados, las metodologas giles de desarrollo de software han despertado inters gracias a que proponen simplicidad y velocidad para crear sistemas. Las metodologas tradicionales no se adaptan a las nuevas necesidades o expectativas que tienen los usuarios hoy en da, en parte que los mtodos usados no son flexibles ante la posibilidad de la exigencia de nuevos requerimientos. Estos cambios generalmente implican altos costos, demanda de tiempo y la reestructuracin total del proyecto que se est llevando; en contraparte, los mtodos giles permiten un desarrollo iterativo y adaptable que permite la integracin de nuevas funcionalidades a lo largo del desarrollo del proyecto; para que tanto el cliente como el desarrollador queden satisfechos porque el producto final tiene una calidad adecuada.

Un proceso es gil cuando el desarrollo de software es:

Incremental. Entregas pequeas de software, con ciclos rpidos.

Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin. Sencillo. El mtodo en s mismo es simple, fcil de aprender y modificar. Esta bien documentado y es adaptable. Permite realizar cambios de ltimo momento). Sus elementos claves son: * Poca documentacin. * Simplicidad.

64

* Anlisis como una actividad constante. * Diseo evolutivo. * Integraciones. * Testeos diarios. slideshare.net/profetiacademico/metodologias-agiles

2.2.5 METODOLOGIAS EMERGENTES (1er AUTOR)

Una metodologa emergente de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin. A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por su fortaleza y debilidad. El framework para metodologa de desarrollo de software consiste en:

Una filosofia de desarrollo de un programa de computacin con el enfoque del proceso de desarrollo de software Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems desarrolla, apoya el uso y promueve la metodologa. La metodologa es a menudo documentada en algn tipo de documentacin formal. Las principales ventajas de la utilizacin de un framework son: 1. El desarrollo rpido de aplicaciones. Los componentes incluidos en un framework constituyen una capa que libera al programador de la escritura de cdigo de bajo nivel. 2. La reutilizacin de componentes software al por mayor. Los frameworks son los paradigmas de la reutilizacin. 3. El uso y la programacin de componentes que siguen una poltica de diseo uniforme. Un framework orientado a objetos logra que los componentes sean clases que pertenezcan a una gran jerarqua de clases, lo que resulta en bibliotecas ms fciles de aprender a usar. Las desventajas de los frameworks son:

1. La dependencia del cdigo fuente de una aplicacin con respecto al framework. Si se desea cambiar de framework, la mayor parte del cdigo debe reescribirse. 2. La demanda de grandes cantidades de recursos computacionales debido a que la caracterstica de reutilizacin de los frameworks tiende a generalizar la

65

funcionalidad de los componentes. El resultado es que se incluyen caractersticas que estn "de ms", provocando una sobrecarga de recursos que se hace ms grande en cuanto ms amplio es el campo de reutilizacin. 3. Otra ventaja de los frameworks, y en especial de esta acepcin amplia, es la portabilidad de aplicaciones de una arquitectura a otra. Por ejemplo, los byte codes generados a partir del cdigo fuente de clases en Java pueden ser ejecutados sobre cualquier mquina virtual, independientemente de la arquitectura hardware y software subyacente. El trmino framework tiene una acepcin ms amplia, en donde adems de incluir una biblioteca de componentes reutilizables, es toda una tecnologa o modelo de programacin que contiene mquinas virtuales, compiladores, bibliotecas de administracin de recursos en tiempo de ejecucin y especificaciones de lenguajes. Tal es el caso del framework Microsoft .NET.

Desarrollar un buen software depende de un gran nmero de actividades y etapas, donde el impacto de elegir la metodologa para un equipo en un determinado proyecto es trascendental para el xito del producto. Segn la filosofa de desarrollo se pueden clasificar las metodologas en dos grupos. Las metodologas tradicionales, que se basan en una fuerte planificacin durante todo el desarrollo, y las metodologas giles, en las que el desarrollo de software es incremental, cooperativo, sencillo y adaptado. Como industria, el software requiere de productos y servicios de alta calidad, lo cual se logra mediante la aplicacin de modelos y metodologas de calidad reconocidos in- ternacionalmente. Las empresas emergentes no logran aplicar estas metodologas pues su gran obstculo se observa en los altos costos de implementacin, el recurso humano requerido y los estndares exigidos que restringen la creatividad, parte importante de su capital. El Laboratorio de Investiga- cin para el Desarrollo de la Ingeniera de Software (LIDIS), siendo consecuente con esta situacin, adelant una investigacin que

66

propone un modelo liviano de mejo- ramiento de los procesos de desarrollo de software partiendo de la caracterizacin de las empresas emergentes.

Primera aproximacin a la aplicacin de las metodologas SCRUM para mejorar la eficacia de los procesos de la Vigilancia e Inteligencia Competitiva, con la finalidad de obtener resultados pronto, con requisitos cambiantes o poco definidos, siendo la innovacin, la competitividad, la flexibilidad y la productividad factores fundamentales. Metodologas de desarrollo Orientado a objetos, Diseo orientado a objetos (OOD) de Grady Booch, tambin conocido como Anlisis y Diseo Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transicin, la interaccin, mdulo, y el proceso. Top-down programming, evolucionado en la dcada de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado. Proceso Unificado, es una metodologa de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecucin de una o ms iteraciones de desarrollo de software: creacin, elaboracin, construccin, y las directrices. Hay una serie de herramientas y productos diseados para facilitar la aplicacin. Una de las versiones ms populares es la de Rational Unified Process. Una metodologa es emergente si permite adaptar la forma de trabajo a las condiciones del proyecto. Caractersticas.. El uso de modelo orientado a odjetos ayuda a explotar el poder expresivo de todos los lenguajes de programacin basados en odjetos y los orientados a objetos, como.. Smalltalk, Object Pascal C++ CLOS

Evita malentendidos de Probar el cdigo de Ada y Java. requerimientos entre el forma constante no Incertidumbre: la cliente y el equipo genera productos de direccin indica la El uso del modelo calidad, slo revela necesidad estratgica orientado a objetos falta de anlisis y que se desea cubrir, alienta la reutilizacin no diseo. Ofreciendo mxima solo del software, sino mxima libertad al equipo de trabajo de diseos completos.

67

Proporcionan mejores Difusin y resultados en los transferencia del conocimiento proyectos de alto riesgo. alta rotacin de los miembros de los equipos entre diferentes proyectos. Por otra parte, potenciar el acceso libre a la informacin y documentacin.

VENTAJAS Las metodologas emergentes motivan mas a los equipos de trabajo. Se utiliza mayoritariamente en desarrollo de productos con innovaciones importantes, y para sistemas de informacin empresarial. El principal beneficio del diseo orientado a objetos es que proporcionan un mecanismos para formalizar modelos de la realidad. Evita malentendidos de requerimientos entre el cliente y el equipo. El uso del modelo orientado a objetos alienta la reutilizacin no solo del software si no de diseos completos que proporcionan mejores resultados en los proyectos de alto riesgo. es emergente orientado a objetos Se utiliza emergentes motivan ms de la comunicacin si permite adaptar ayuda a explotar el mayoritariamente en a los equipos de trabajo. Este tipo de la forma de trabajo poder expresivo de desarrollo de El principal beneficio del comunicacin resulta a las condiciones todos los lenguajes productos con diseo orientado a difcil de preservar del proyecto. programacin innovaciones objetos es que cuando pasa el basados en objetos y importantes, y para proporciona un tiempo y est sujeta los orientados a sistemas de mecanismo. DESVENTAJAS Problemas derivados de la comunicacin oral. Este tipo de comunicacin resulta difcil de preservar cuando pasa el tiempo y esta sujeta a muchas ambigedades y falta de calidad. Probar el cdigo de forma constante no genera productos de calidad, solo revela falta de anlisis y diseo.

68

http://www.slideshare.net/thecarlosrock/metodologias-todas

2.2.5 METODOLOGAS AUTOR)

EMERGENTES

(2do

El desarrollo de software no es sin dudas una tarea fcil. Como resultado a este problema ha surgido una alternativa desde hace mucho: la Metodologa. Las metodologas imponen un procesodisciplinado sobre el desarrollo de software con el fin de hacerlo ms predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte nfasis en planificar inspirado por otras disciplinas de la ingeniera. Las metodologas ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. An menos por su popularidad. La crtica ms frecuente a estas metodologas es que son burocrticas. Hay tanto que hacer para seguir la metodologa que el ritmo entero del desarrollo se retarda. Hoy en da existen numerosas propuestas metodolgicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas especficamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran nmero de proyectos, sobre todo aquellos proyectos de gran tamao (respecto a tiempo y recursos). Sin embargo la experiencia ha demostrado que las metodologas tradicionales no ofrecen una buena solucin para proyectos donde el entorno es voltil y donde los requisitos no se conocen con exactitud, porque no estn pensadas para trabajar con incertidumbre. Aplicar metodologas tradicionales nos obliga a forzar a nuestro cliente a que tome la mayora de las decisiones al principio. Luego el coste de cambio de una decisin tomada puede llegar a ser muy elevado si aplicamos metodologas tradicionales. Una metodologa emergente de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin. A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por su fortaleza y debilidad.

69

El framework para metodologa de desarrollo de software consiste en: Una filosofia de desarrollo de un programa de computacin con el enfoque del proceso de desarrollo de software Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems desarrolla, apoya el uso y promueve la metodologa. La metodologa es a menudo documentada en algn tipo de documentacin formal.

2.3 REINGENIERIA ( 1er AUTOR)

La reingeniera es la transformacin sistemtica de un sistema existente dentro de una nueva forma de realizar mejoramientos de calidad en una operaciones, capacidad del sistema, funcionabilidad, rendimiento o evolucin a bajo costo, agendas o riesgos para el cliente. Reingeniera del software se puede definir como: modificacin de un producto software, o de ciertos componentes, usando para el anlisis del sistema existente tcnicas de Ingeniera Inversa y, para la etapa de reconstruccin, herramientas de Ingeniera Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilizacin, comprensin o evaluacin. Cuando una aplicacin lleva siendo usada aos, es fcil que esta aplicacin se vuelva inestable como fruto de las mltiples correcciones, adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que cada vez que se pretende realizar un cambio se producen efectos colaterales inesperados y hasta de gravedad, por lo que se hace necesario, si se prev que la aplicacin seguir siendo de utilidad, aplicar reingeniera a la misma. Entre los beneficios de aplicar reingeniera a un producto existente se puede incluir:

Pueden reducir los riegos evolutivos de una organizacin. Puede ayudar a las organizaciones a recuperar sus inversiones en software. Puede hacer el software ms fcilmente modificable Ampla las capacidades de las herramientas CASE Es un catalizador para la automatizacin del mantenimiento del software Puede actuar como catalizador para la aplicacin de tcnicas de inteligencia artificial para resolver problemas de reingeniera

La reingeniera del software involucra diferentes actividades como son:

70

anlisis de inventarios reestructuracin de documentos ingeniera inversa reestructuracin de programas y datos ingeniera directa

con la finalidad de crear versiones de programas ya existentes que sean de mejor calidad y los mismos tengan una mayor facilidad de mantenimiento. Para Roger Pressman una definicin completa de reingeniera implica: La reingeniera del software abarca una serie de actividades entre las que se incluye el anlisis de inventario, la reestructuracin de documentos, la ingeniera inversa, la reestructuracin de programas y datos, y la ingeniera directa. El objetivo de esas actividades consiste en crear versiones de los programas existentes que muestren una mayor calidad, y una mejor mantenibilidad. La Reingeniera de Software es una forma de modernizacin para mejorar las capacidades y/o mantenibilidad de los sistemas de informacin heredados mediante la aplicacin de tecnologas y prcticas modernas. La Reingeniera de Software ofrece una disciplina de preparacin para migrar un sistema de informacin heredado hacia un sistema evolucionable. El proceso aplica principios de ingeniera para un sistema existente para encontrar nuevos requerimientos.

La reingeniera cuenta entre sus objetivos con: Proporcionar asistencia automatizada para el mantenimiento. Reducir los errores y costos del mantenimiento. Incrementar la intercambiabilidad del grupo de mantenimiento. Hacer sistemas fciles de entender, cambiar y probar. Habilitar la conversin y migracin de sistemas. Reforzar el apego a estndares. Mejorar la respuesta a peticiones de mantenimiento. Mejorar el estado de nimo del grupo de mantenimiento. Proteger y extender la vida del sistema. .Usar CASE para apoyar sistemas existentes .Re-usar componentes de sistema existentes.

CUANDO ES NECESARIA LA REINGENIERIA Los candidatos a la reingeniera aparecen usualmente si cumplen estas condiciones: Frecuentes fallas de produccin (fiabilidad cuestionable). Problemas de rendimiento.

71

 Tecnologa obsoleta. Problemas de integracin del sistema. Cdigo de calidad pobre. Dificultad (peligroso) al cambio. Dificultad para probar. Mantenimiento caro. Incremento de problemas del sistema. A pesar de estas razones, y antes de reconstruir un sistema en uso, es conveniente analizarlas diversas alternativas disponibles: Dejar el producto como est. Adquirir uno en el mercado que realice la misma funcin. Reconstruirlo. Evidentemente, elegiremos la opcin que mejor relacin coste/beneficio nos ofrezca, y eso nos lleva al apartado siguiente:

COSTES Y RIESGOS ANALIZANDO LAS OPCIONES Los costes de la reingeniera obviamente dependen de la magnitud del trabajo que tiene que llevarse a cabo, tal y como muestra la figura [Sommerville], los costes se incrementan desde la izquierda hacia la derecha para que la traduccin de cdigo fuente sea la opcin ms econmica.

Los principales factores que afectan a los costes de reingeniera son los que menciona Sommerville: 1. La calidad del software sobre el que se va a hacer reingeniera. Cuanto ms baja sea la calidad del software y su documentacin asociada (si la hay), ms altos sern los costes de reingeniera. 2. Las herramientas de soporte disponibles para la reingeniera. Normalmente no es rentable hacer reingeniera sobre un sistema software a menos que puedan utilizarse herramientas CASE para automatizar la mayor parte de los cambios en los programas.

72

3. La amplitud de la conversin de datos requerida. Si el sistema sobre el que se va a hacer reingeniera requiere que se conviertan grandes volmenes de datos. el coste del proceso se incrementa de forma significativa. 4. La disponibilidad de personal experto. Si el personal responsable de mantener el sistema no puede implicarse en el proceso de re ingeniera, los costes se incrementarn debido a que los ingenieros encargados de la reingeniera tienen que invertir una gran cantidad de tiempo en comprender el sistema.

Sneed Pressman ha propuesto un modelo de anlisis de costes y beneficios para la reingeniera. Se definen nueve parmetros: P1 = coste de mantenimiento anual actual para una aplicacin; P2 = coste de operacin anual de una aplicacin; P3 = valor de negocios anual actual de una aplicacin; P4 = coste de mantenimiento anual predicho despus de la reingeniera; P5 = coste de operaciones anual predicho despus de la reingeniera; P6 = valor de negocio actual predicho despus de la reingeniera; P7 = costes de reingeniera estimados; P8 = fecha estimada de reingeniera; P9 = factor de riesgo de la reingeniera (P, = 1 ,O es el valor nominal); L = vida esperada del sistema. El anlisis de costes y beneficios presentados en las ecuaciones anteriores se puede llevar a cabo para todas aquellas aplicaciones de alta prioridad que se hayan identificado durante un anlisis de inventario. Aquellas aplicaciones que muestren el mayor beneficio en relacin con los costes podrn destinarse a la reingeniera, mientras que las dems podrn ser propuestas hasta que se disponga de ms recursos. VENTAJAS Y DESVENTAJAS Hacer reingeniera de un sistema software, segn Ian Sommerville, tiene dos ventajas clave sobre aproximaciones ms radicales a la evolucin del sistema: Riesgo reducido. Existe un alto riesgo en volver a desarrollar software crtico para los negocios. Pueden cometerse errores en la especificacin, o puede haber problemas en el desarrollo. Los retrasos en la introduccin del nuevo software pueden significar prdidas en el negocio e incurrir en costes adicionales. Por ejemplo, en 1999 una gran compaa de comida en Estados Unidos tuvo retrasos en la introduccin de un nuevo sistema de pedidos, lo que condujo a retrasos en las entregas de productos valoradas en 100 millones de dlares en una estacin de mxima venta. Coste reducido. El coste de hacer reingeniera es significativamente menor que el coste de desarrollar nuevo software. Ulrich (Ulrich, 1990) cita un ejemplo de un sistema comercial en el que los costes de Re implementacin se estimaron en 50 millones de dlares. Al sistema se le

73

aplic reingeniera con xito por 12 millones de dlares. Se presume que, con la tecnologa moderna del software, el coste relativo de la re implementacin probablemente sea menor. pero aun as supera de forma considerable los costes de la reingeniera. La principal desventaja de la reingeniera del software es que existen lmites prcticos a la extensin del sistema que puede ser mejorada mediante reingeniera. No es posible. Por ejemplo, convertir un sistema diseado utilizando una aproximacin funcional en un sistema orientado a objetos. Los cambios arquitectnicos mayores o la reorganizacin radical de la gestin de datos del sistema no pueden realizarse de forma automtica, por lo que se incurrir en costes adicionales elevados. Aunque la reingeniera puede mejorar la mantenibilidad, el sistema al que se va a aplicar reingeniera probablemente no ser tan mantenible como un nuevo sistema desarrollado utilizando mtodos modernos de ingeniera del software.

74

2.3 REINGENIERIA ( 2do AUTOR)

REINGENIERA SEGN IAN SOMMERVILLE La reingeniera comienza con un sistema existente y el proceso de desarrollo para su reemplazo se basa en comprender y transformar el sistema original. La Figura ilustra el proceso de reingeniera. La entrada del proceso es un programa heredado y la salida es una versin modularizada y estructurada del mismo programa .

EL PROCESO DE REINGENIERIA

Durante la reingeniera del programa, los datos del sistema tambin sufren reingeniera. Las actividades de este proceso de reingeniera son: l. Traduccin del cdigo fuente. El programa es convenido desde un lenguaje de programacin antiguo a una versin ms moderna del mismo lenguaje o a un lenguaje diferente. 2. Ingeniera inversa.

75

El programa se analiza y se extrae informacin a partir de l. Esto ayuda a documentar su organizacin y funcionalidad. 3. Mejora de la estructura de los programas. La estructura de control del programa se analiza y modifica para hacerla ms fcil de leer y comprender.

4. Modularizacin de los programas. Se agrupan las panes relacionadas del programa y se elimina la redundancia en donde resulta adecuado. En algunos casos. esta etapa pueden implicar una transformacin arquitectnica en la que un sistema centralizado pensado para una nica computadora se modifica para ejecutarse sobre una plataforma distribuida. 5. Reingeniera de datos. Los datos procesados por el programa se cambian para reflejar los cambios en l. La Reingeniera no es lo mismo que ingeniera hacia adelante, el cual comienza con una especificacin del sistema e implica el diseo e implementacin de un nuevo sistema. Roger Pressman Habla sobre.. Anlisis de inventario Reestructuracion de documentos Ingenieria inversa Reestructuracin de cdigo Reestructuracion de datos Ingenieriera directa. Ian Sommervielle Habla sobre.. Traduccion del cdigo fuente Ingenieria inversa Mejora de la estructura del programa Modularizacion de los programas Reingeniera de datos

http://epetushuaia.files.wordpress.com/2011/06/reingenieria-de-soft.pdf http://cnx.org/content/m17438/latest/

76

CONCLUSION
Una metodologa de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin. A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por su fortaleza y debilidad El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de clculo. Metodologas de Desarrollo de Software tiene como objetivo presentar un conjunto de tcnicas tradicionales y modernas de modelado de sistemas que permitan desarrollar software de calidad, incluyendo heursticas de construccin y criterios de comparacin de modelos de sistemas. Para tal fin se describen, fundamentalmente, herramientas de Anlisis y Diseo Orientado a Objetos (UML), sus diagramas, especificacin, y criterios de aplicacin de las mismas. Como complemento se describirn las metodologas de desarrollo de software que utilizan dichas herramientas, ciclos de vida asociados y discusin sobre el proceso de desarrollo de software ms adecuado para las diferentes aplicaciones ejemplos que se presentarn. Principalmente, se presentar el Proceso Unificado el cual utiliza un ciclo de vida iterativo e incremental.

77

BIBLIOGRAFIA

http://modeloespiral.blogspot.mx/

http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_externos/Administra cion_informatica_de_las_organizaciones_Ramon_E_Enriquez_Gonzalez/AIO2 _Mod_ESPIRAL.html http://epetushuaia.files.wordpress.com/2011/06/reingenieria-de-soft.pdf http://cnx.org/content/m17438/latest/ slideshare.net/profetiacademico/metodologias-agiles http://www.slideshare.net/thecarlosrock/metodologias-todas http://oa.upm.es/1939/1/TESIS_MASTER_PILAR_RODRIGUEZ_GONZALEZ.p df Ingenieria de software. un enfoque prctico (pressman 5th ed) AUTORES.. Pilar Rodrguez Gonzlez

78