Hoja1Domnguez Garca Carlo Alejandro Ramos Gmez Jorge Ivn

MetodologaConcepto y CaractersticasEtapasDescripcin de cada etapaCaracterstica del software/aplicarCaracterstica del cliente/aplicarTiempo de DesarrolloCascadaTambin conocido como modelo clsico, modelo tradicional o modelo lineal secuencial. l mtodo de la cascada es considerado como el enfoque clsico para el ciclo de vida del desarrollo de sistemas, se puede decir que es un mtodo puro que implica un desarrollo rgido. Esta es una secuencia de actividades que consisten en el anlisis de requerimientos, l diseo ,la implementacin, la integracin y las pruebas. Su caracterstica principal consiste en que no se puede avanzar de etapa si no se ha terminado la enterior.Anlisis Diseo Implementacin Pruebas Mantenimiento

El anlisis de requerimientos consiste en reunir las necesidades del cliente para poder implementarlas en un sistema. Diseo: describe la estructura interna del producto y suele representarse con diagramas y texto. Implementacin: en esta etapa se desarrolla el sistema tomando en cuenta el anlisis y el diseo previamente realizado. Prueba: es la etapa en donde se evalua el sistema y se detectan errores. Mantenimiento: la etapa de cierre del mtodo, ya que es la que llega al usuario final para que cumpla con todas las espectativas. Realiza un buen funcionamiento en equipos dbiles y productos maduros, por lo que se requiere de menos capital y herramientas para hacerlo funcionar de manera ptima.Es un modelo fcil de implementar y de entender, por lo que el cliente no necesita de mucho tiempo para comprenderlo pero ya debe tener muy claras sus ideas y qu es lo que necesita.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.INCREMENTALCONCEPTO: El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el enfoque incremental de desarrollocomo 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 adquirirexperiencia con el sistema. Este modelo se conoce tambin bajo las siguientes denominaciones:

Mtodo de las comparaciones limitadas sucesivas.Ciencia de salir del paso.Mtodo de atacar el problema por ramas.

El modelo incremental combina elementos del modelo en cascada con la filosofa interactiva de construccin de prototipos. Se basa en la filosofa de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Caractersticas:Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.El usuario se involucra mas.Dificil de evaluar el costo total.Dificil 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 positivo.el proceso se divide en 4 partes:

AnlisisDiseoCdigoPrueba ProductoAnlisis: La primera etapa en laproduccin de un sistema de software esdecidir exactamente que ha de hacer elsistema; esta etapatambin se conoce como etapa de requisitos oespecificacionesy por esta circunstancia muchos tratadistas suelen subdividir laetapa en otras dos.Anlisis y definicin delproblema(requisitos)Especificacin derequisitos(especificaciones)Diseo: El diseo se considera como un actividad y consiste en lasolucin de negocios para el usuario y se expresa con los casosde uso. El diseo es la solucin del equipo de proyecto delnegocio y consiste de lassiguientes tareas:Identificar los usuarios y sus rolesObtener datos de los usuariosEvaluar la informacinDocumentar los escenarios de usoValidar con los usuariosValidar contra laarquitectura de la empresaCdigo: El diseo debe traducirse en una forma legible para la mquina.Se implementa el cdigo fuente. Dependiendo del lenguaje deprogramacin y su versin se crean laslibreras y componentesreutilizables dentro del mismo proyecto para hacer que laprogramacin sea un proceso mucha ms rpido.Pruebas: Durante la prueba de Sistemas, elSistema se emplea demanera experimental para asegurarse de que el Software notenga fallas, es decir, que funciona de acuerdo con lasespecificaciones y en la forma enque los usuarios esperan quelo haga.Se alimentancomo entradasconjunto dedatos deprueba para su procesamiento y despus se examinan losresultados.Producto: En la parte final de la etapa nos encontramos con la etapaproducto el cual nos da a conocer que el software quedesarrollamos gracias al mtodo incremental, a sido terminado yahora es un producto listo para ser usado, ya que paso laprueba de errores.es para aplicarse a sistemas no transaccionales que no tengan tendencia a ser integrados ni funcionar como un todoEs dirigida para cuando existe poco personal,aplicado para clientes que puedan congeniar con versiones incompletas de un sw y que tengan la base economica para satisfacer el aumento de costo debido a las pruebasEl proceso de creacion del software es tardado porque los errores en requisitos se detectan tarde.Espirales 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.-Planeacin-Anlisis de riesgo-Ingeniera-EvaluacinPlaneacin : determinacin de los objetivos, alternativas y restriccionesAnlisis de riesgo : anlisis de alternativas e identificacin/resolucin de riesgosIngeniera : desarrollo del producto hasta "el siguiente nivel".Evaluacin : valoracin por parte del cliente de los resultados obtenidos.Debido a su elevada complejidad no se aconseja utilizarlo en pequeos sistemas y genera mucho tiempo en el desarrollo del sistema. Es recomendado para sistemas grandes.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. Es recomendable para clientes que dediquen tiempo al desarrollo de su sistema.Genera mucho tiempo en el desarrollo del sistema, porque se va desarrllando de manera evolutiva puede ir cambiando constante mente.Modelo EvolutivoEs el modelo cuyas etapas consisten en expandir incrementos de un producto de software operacional donde la direccin de la evolucin la dicta la experiencia con el sistema . El cliente recibe pequeos incrementos del sistema a medida que van siendo desarrollados : distribucin incremental .El cliente recibe pequeos incrementos del sistema a medida que van siendo desarrollados : distribucin incremental . CARACTERISTICAS Gestionan bien la naturaleza evolutiva del software Son iterativos: construyen versiones de softwarecada vez ms completas

ES INTERACTIVO -Con cada incremento se entrega al cliente un producto operacional , que puede evaluarloPERSONAL - Permite variar el personal asignado a cada interaccin GESTION RIESGOS TECNICOS - Por ejemplo disponibilidad de hardware especifico Especificacion inicial Desarrollo del producto Implementacion,uso y Evaluacion(version del software) Re-especificacionDefinicion del problema y especificacion inicial en base a los requisitos definidos Desarrollo del software en base a un proceso con enfasis en la rapidez de la liberacion Implantacion y uso del software en ambiente de explotacion , monitores de los nuevos requerimientos Re-definicion del problema en base a los nuevos requerimientosDiseado para software que este libre a cambios , e incluso hasta accesible a ser completamente reemplazado por uno nuevo con la finalidad de satisfacer nuevas necesidadesSe recomienda a clientes que se involucran al desarrollo de su sistemaEs del tipo rpido porque busca satisfacer las necesidades del cliente lo ms pornto posible ademas que hace modificaciones durante el desarrolloGanar Ganar En los modelos clsicos surge en la comunicacin con los clientes para determinar los requisitos, en este modelo se basa en la negociacin entre el cliente y el desarrollador, se negocia coste frente a funcionalidades, rendimiento, calidad, o simplemente el gestor del proyecto le pregunta al cliente qu necesita y l proporciona la informacin para continuar.

Esto se refiere que a la obtencin de requisitos requieren de una negociacin, que tiene xitocuando ambas partes ganan.Se consideran cuatro ciclos, compuesto cada uno de cuatro actividades: -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.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. Se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas, lo que permite utilizarlo tanto en proyectos pequeos, como mayores.En los modelos clsicos surge en la comunicacin con los clientes para determinar los requisitos, en este modelo se basa en la negociacin entre el cliente y el desarrollador, se negocia coste frente a funcionalidades, rendimiento, calidad, o simplemente el gestor del proyecto le pregunta al cliente qu necesita y l proporciona la informacin para continuar.Se genera mucho tiempo de desarrollo del software ya que se requiere planificar cada ciclo aparte de que es costoso.Proceso Unificadoes un mtodo iterativo de diseo de software que describe cmo desarrollar software de forma eficaz, utilizando tcnicas probadas en la industria. El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental. El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Es una metodologa orientada a conducir el proceso de desarrollo de software en sus aspectos tcnicos; los flujos y productos de trabajo de UP no incluyen la administracin del proyecto.Fase de Inicio en UP Fase de Elaboracin en UP Fase de Construccin en UP Fase de Transicin en UPFase 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).Est dirigido por casos de uso. Est centrado en la arquitectura (es decir, en una solucin de conjunto). Tiene un ciclo de vida iterativo incremental. Es una metodologa orientada a conducir el proceso de desarrollo de software en sus aspectos tcnicos; los flujos y productos de trabajo de UP no incluyen la administracin del proyecto.Dirigido a personas que tienen amplio conocimiento sobre los detalles de la empresa y el tema de ing de softwarecon respecto a las etapas de cada proceso.Relativamente lento ya que se busca conocer a detalle cada proceso para continuar con este mtodo. Emergente o XP ( extreme programing )Est centrada en en potenciar las relaciones interpersonales como clave para el xito. Se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluda entre todos los participantes y simplicidad en las soluciones implementadasFase I: Exploracin Fase II: Planificacin de la entrega Fase III: Iteraciones Fase IV: Produccin Fase V: Mantenimiento Fase VI: Muerte del proyectoI.- Exploracin: En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de inters para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. II.- Planificacin: En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. III.- Iteraciones: El Plan de Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. IV.- Produccin: La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a la versin actual, debido a cambios durante esta fase. V.- Mantenimiento: Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. VI.- Muerte del proyecto: Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.Es recomendable para desarrollar pequeos sistemas ya que termina siendo mas eficienteEst dirigido a clientes con tiempo para poder establecer que es lo que necesita y estar en contacto con el equipo de desarrollo para lograr los objetivos planteados Est recomendado para sistemas a corto plazo, por lo que no requiere mucho tiempo de desarrollo.gil o Scrum Scrum es una metodologa gil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversin para su empresa y minimizar los riesgos. Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin.Planificacin de la Iteracin Ejecucin de la Iteracin Inspeccion y AdaptacinPlanificacin de la iteracin: Tiene dos partes:Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de tareas de la iteracin necesarias para desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas. Ejecucin de la iteracin: Cada da el equipo realiza una reunin de sincronizacin (15 minutos mximo). Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para poder hacer lDurante la iteracin el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.Elimina los obstculos que el equipo no puede resolver por s mismo.Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad. Inspeccin y adaptacin: El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes:Demostracin (4 horas mximo). El equipo presenta al cliente los requisitos completados en la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo. En funcin de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteracin, replanificando el proyecto.Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera de trabajar y cules son los problemas que podran impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargar de ir eliminando los obstculos identificados.Sirve para software que requiera funcionar mientras se desarrolla ya que al termino de cada iteracin el cliente puede usarlo y conforme a ello ir mejorando el producto, reduciendo riesgos y evitando prdidas.Alta capacidad de reaccin ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodologa est diseada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos. Por lo que el cliente debe estar en contacto constante con el sistema que solicita.Debido a que trata de reducir los riesgos al mnimo y puede haber cambios mientras se lleva a cabo el tiempo de desarrollo es largo.Ingenieria WebLa ingeniera web es la aplicacin de metodologas sistemticas, disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin de aplicaciones de alta calidad en la www.Anlisis de requisitos Diseo Conceptual Diseo Navegacional Diseo de Presentacin Anlisis de Requisitos: Fija los requisitos funcionales de la aplicacin Web para reflejarlos en un modelo de casos de uso. Diseo Conceptual: Materializado en un modelo de dominio, considerando los requisitos reflejados en los casos de uso. Diseo Navegacional: Lo podemos subdividir en : Modelo del Espacio de Navegacional. Modelo de la Estructura de navegacin: Muestra la forma denavegar ante el espacio de navegacin. Diseo de Presentacin: Representa las vistas del interfaz del usuario mediante modelos estndares de interaccin UML.Es funcional para cualquier desarrollo de paginas web ya que tiene demasiadas variaciones y por lo mismo se pueden usar diversas herramientas para llevarlo a cabo aunque solo suple necesidades de comunicacinFuncional para clientes que no interactuen con sus propios clientes, ya que est metodologa est enfocada a uso mediante pginas web. Dependiendo de la cantidad de servicios y productos que se requieran incluir, por lo que un tiempo de desarrollo depende del cliente.Basado en componentesEl 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. Reutilizacin del Software Simplificacin de Pruebas Mantenimiento del Sistema Mayor CalidadReutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software.Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes del sistema.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.Se enfoca en reutilizar un software ya existente. Por lo que puede ser implementado para mejorar algn sistema.Clientes que ya tengan sus componentes listos y quieran adquirir alguna mejora para ellos.Genera mucho tiempo de desarrollo y es costoso aparte de que requiere mucha experiencia.