Otras Metodologas (Modernas)

Ing. De Software

Hernndez Basilio Armando

Ing. En Sistemas Computacionales

6 A

Contreras Ponce Laura Monzerrat

Ocampo Lara Tomas Fernando

Rodas Cabrera Felipe Carlos

Cruz Lopez Jonathan

Ganar-ganar (Win-Win)La mayora de las veces satisface las necesidades del cliente y el desarrollador gana logrando la entrega del sistema en fechas y actividades establecidas al principio del modelo.

Las actividades iniciales del modelo se establecen de la siguiente manera:

Identificacin del sistema o subsistemas clave de los directivos (saber qu quieren).

Determinacin de condiciones de los directivos (saber qu necesitan y los satisface).

Negociacin de las condiciones de todos los afectados (negociar para que ambos ganen). Directivo: Cliente

escogido con inters directo en el producto, que puede ser premiado por la organizacin si tiene xito o criticado si no.

Conseguidos completamente estos pasos iniciales se logra un resultado, que ser el criterio clave para continuar con la definicin del sistema y del software. El modelo en espiral win-win se ilustra en la figura.

Una vez revisadas las actividades, los ciclos definen lneas especficas a seguir:

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.

Ventajas

Minimiza riesgos del proyecto

Agrega objetivos de calidad

Desventajas

Genera mucho tiempo en el desarrollo del sistema

Resulta como un modelo muy costoso

Requiere de mucha experiencia en la identificacin de los riesgos

Proceso Unificado (PU)Es un intento por obtener los mejores rasgos y caractersticas de los modelos tradicionales del proceso del software.

El PU reconoce la importancia de la comunicacin con el cliente y los mtodos directos para describir su punto de vista respecto de un sistema (el caso de uso).

Al principio de la dcada de 1990, James Rumbaugh, Grady Booch e IvarJacobson comenzaron a trabajar en un mtodo unificado que combinara lo mejor de cada uno de sus mtodos individuales de anlisis y diseo orientado a objetos. El resultado fue un UML, lenguaje de modelado unificado.

Despus, Jacobson, Rumbaugh y Booch desarrollaron PU, estructura para la ingeniera de software orientado a objetos que utiliza UML. Actualmente, el proceso unificado (PU) y el UML se usan mucho en proyectos de toda clase orientados a objetos. El modelo iterativo e incremental propuesto por el PU puede y debe adaptarse para que satisfaga necesidades especficas del proyecto.

Fases:

La fase de concepcin, agrupa actividades tanto de comunicacin con el cliente como de planeacin. Al colaborar con los participantes, se identifican los requerimientos del negocio, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestin. Los requerimientos fundamentales del negocio se describen por medio de un conjunto de casos de uso preliminares que detallan las caractersticas y funciones que desea cada clase principal de usuarios.

La fase de elaboracin, incluye las actividades de planeacin y modelado del modelo general del proceso. La elaboracin mejora y ampla los casos de uso preliminares desarrollados como parte de la fase de concepcin y aumenta la representacin de la arquitectura para incluir cinco puntos de vista distintos del software: los modelos del caso de uso, de requerimientos, del diseo, de la implementacin y del despliegue. Es frecuente que en este momento se hagan modificaciones al plan.

La fase de construccin, es idntica a la actividad de construccin definida para el proceso general del software. Con el uso del modelo de arquitectura como entrada, esta fase desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales.

La fase de transicin, incluye las ltimas etapas de la actividad general de construccin y la primera parte de la actividad de despliegue general. Se da el software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como los cambios necesarios. Adems, el equipo de software genera la informacin de apoyo necesaria.

La fase de produccin, coincide con la actividad de despliegue del proceso general. Durante esta fase, se vigila el uso que se da al software, se brinda apoyo para el ambiente de operacin (infraestructura) y se reportan defectos y solicitudes de cambio para su evaluacin.

Entre las ventajas se encuentran las siguientes:

Hay varias oportunidades para revisar el sistema a desarrollar hasta que sea correcto. Se pueden encontrar errores y corregirlos.

Adaptabilidad del desarrollo a nuevos requisitos o nuevos cambios.

Se define una arquitectura slida en etapas tempranas del desarrollo.

Se reducen los riesgos de no obtener el producto deseado.

En cada momento hay una versin del sistema funcionando que se modifica segn las necesidades y deseos del cliente.

Progreso visible en las primeras etapas.

Reducir la redundancia e incrementa la productividad, un software bien diseado evita la duplicidad del cdigo con lo cual se obtiene un software robusto.

Fcil ejecucin del proceso de elaboracin del sistema software, ya que describen como est estructurado el sistema desde diferentes perspectivas orientadas a los diferentes involucrados en un proyecto.

El proceso es comprensible.

La metodologa de PU es ms adaptable para proyectos de largo plazo.

Entre las desventajas se encuentran:

El mtodo de PU requiere costos de dedicacin altos por lo que no es conveniente usarlo en procesos de un proyecto pequeo.

Si el proceso no se aplica bien desde el inicio el PU se puede volver muy grande y difcil, tanto para aprender como para administrar.

Una cantidad sustancial de tiempo se gasta en tratar de adecuar el PU a cada proyecto. Aqu, tambin, se corre el riesgo de volverse un esclavo del proceso y perder de vista la razn del proceso.

Es un proceso pesado.

Se basa mucho en la documentacin.

Ingeniera WebSe 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.

Es el proceso utilizado para crear, implantar y mantener aplicaciones y sistemas Web de alta calidad

Ofrece una solucin de comercio electrnico a las empresas que han decidido comercializar y administrar sus productos a travs de Internet mediante una tienda virtual y que adems 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 (www).

En toda instancia se debe crear un modelo de diseo antes de que comience la construccin.

Los encargados de la ingeniera web son los diseadores grficos, desarrolladores de contenida y otros participantes colaboran en la creacin de un modelo de diseo para la ingeniera web.

Es importante la ingeniera web porque permite a un ingeniero web crear un modelo que pueda valorarse en calidad y mejorar antes de que se generen el contenido, cdigo, se realicen pruebas y se involucran muchos usuarios finales.

Los pasos a seguir para el diseo web abarca 6 grandes pasos a los cuales alimenta la informacin obtenida durante el modelado de anlisis.

La ingeniera web utiliza informacin contenida dentro del modelo de anlisis como una base para establecer el diseo de los objetos de contenida y sus relaciones.

El diseo esttico establece la visin y el sentimiento que observa el usuario final.

El diseo arquitectnico se enfoca sobre la estructura hipermedia global de todos los objetos de contenido y funciones.

El diseo de las interfaces establece la plantilla global y los mecanismos de interaccin de que definen la interfaz del usuario.

El diseo de navegacin define como navega el usuario final a travs de la estructura hipermedia.

El diseo de componentes representa la estructura interna detallada de los elementos funcionales de la webapp

Calidad de la aplicacin Web.

Facilidad de uso: Tener una comprensin global del sitio, caractersticas de retroalimentacin en lnea y ayuda, calidad en la interfaz y esttica.

Funcionalidad: Capacidad de bsqueda y recuperacin, caractersticas de navegacin, visualizacin, aplicacin relacionadas con el dominio.

Confiabilidad: Se refiere los correctos procesamientos de vnculos, recuperacin de errores, validacin y recuperacin de entrada de usuario.

Eficiencia: Rapidez de generacin de pginas y grficas, desempeo en tiempo de respuesta.

Facilidad de mantenimiento: Adaptabilidad, extensibilidad y fcil de corregir.

Pressman sugiere un proceso de ingeniera web compuesto por las siguientes fases:

Planteamiento y formulacin. Identificamos los objetivos de nuestra aplicacin, y delimitamos el alcance de la primera iteracin.

Planificacin. Una vez planteado el problema, podremos estimar costos, riesgos y esfuerzo durante el desarrollo. Recordemos que en la planeacin iterativa solamente se detalla la iteracin actual, y las iteraciones subsecuentes slo se plantean de forma general.

Anlisis. Durante esta etapa establecemos los requerimientos tcnicos, grficos, y de contenido, que incorporaremos en la iteracin.

Ingeniera. La actividad de ingeniera incorpora dos grupos de tareas que se realizan en paralelo: el diseo del contenido y la produccin, se enfocan en el diseo, produccin y adquisicin del contenido de texto, grfico y video que se vayan a integrar en la aplicacin. Estas tareas son realizadas por personal no tcnico. Por otro lado, estn el diseo arquitectnico, de navegacin e interfaz, el cual lidia con los aspectos tcnicos.

Generacin de pginas y pruebas. Se prueba que el contenido dinmico se genere correctamente, utilizando las plantillas, interfaces y contenidos diseados en la fase de ingeniera. Posteriormente se realizan las pruebas pertinentes, que dependern del tipo de aplicacin y requerimientos no funcionales (por ejemplo, pruebas de desempeo, etctera).

Evaluacin del cliente. Al final de cada iteracin se debe realizar una evaluacin con el cliente, para validar el avance y determinar los cambios o mejoras en caso de ser necesarios, que se aplicarn en las siguientes iteraciones.

Ventajas

Es de Fcil uso

Permite la comunicacin rpida y directa con una o varias personas que se encuentre en cualquier parte del mundo, ayudando de esta manera en las TICs

Desarrollo de diferentes proyectos y propuestas para dar a conocer dichos proyectos a travs de la red

Ayuda en el proceso de globalizacin de las empresas, ya que permite contactar diferentes entidades y personas en el mundo sin altos costos

Crear publicidad para que los clientes puedan acceder a productos y servicios y tengan informacin actualizada de ellos.

Creacin de ventaja competitiva, ya que la empresa o entidad se encontrara a la vanguardia de la tecnologa.

Desventajas

No posee muchas funcionalidades para la empresa. solo suple necesidades de comunicacin.

No ofrece diversidad de opciones

gil

Basado en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan mediante la colaboracin de grupos auto organizados y multidisciplinarios. Los mtodos giles enfatizan las comunicaciones cara a caraen vez de la documentacin.

La mayora de los equipos giles estn localizados en una oficina abierta, a veces llamadas "plataformas de lanzamiento". La oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin y directores de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica.

Se basa en dos aspectos puntuales, el retrasar las decisiones y la planificacin adaptativa; permitiendo potencia an ms el desarrollo de software a gran escala.

Como resultado de esta nueva teora se crea un Manifiesto gil cuyas principales ideas son:

Los individuos y las interacciones entre ellos son ms importantes que las herramientas y los procesos empleados.

Es ms importante crear un producto software que funcione que escribir documentacin exhaustiva.

La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos.

La capacidad de respuesta ante un cambio es ms importante que el seguimiento estricto de un plan.

Entre los principales mtodos giles tenemos:

El XP (Extreme Programming o Programacin extrema):

Es la ms destacada de los procesos agiles de desarrollo de software formulada por Kent Beck. La programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad.

Las caractersticas fundamentales del mtodo son:

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.

Pruebas Unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin.

Programacin por parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto.

Frecuente interaccin del equipo de programacin con el cliente o usuario.

Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento.

Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve en que todo el personal pueda corregir y extender cualquier parte del proyecto.

Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario.

Ventajas

Programacin organizada.

Menor taza de errores.

Satisfaccin del programador.

Solucin de errores de programas.

Versiones nuevas.

Implementa una forma de trabajo donde se adapte fcilmente a las circunstancias.

Se adapta al desarrollo de sistemas pequeos y grandes; optimiza el tiempo de desarrollo; permite realizar el desarrollo del sistema en parejas para complementar los conocimientos; el cdigo es sencillo y entendible, adems de la poca documentacin a elaborar para el desarrollo del sistema.

Desventajas

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar.

Imposible prever todo antes de programar.

Demasiado costoso e innecesario.

No se tiene la definicin del costo y el tiempo de desarrollo; el sistema va creciendo despus de cada entrega al cliente y nadie puede decir que el cliente no querr una funcin ms; se necesita de la presencia constante del usuario, lo cual en la realidad es muy difcil de lograr.

Programacin en parejas, algunos desarrolladores son celosos del cdigo que escriben y no les es grato que alguien ms modifique las funciones que realiz o que su cdigo sea desechado por no cubrir el estndar.

Scrum:

Es un mtodo de desarrollo gil de software concebido por Jeff Sutherland y su equipo de desarrollo a principios de la dcada de 1990.

Los principios Scrum son congruentes con el manifiesto gil y se utilizan para guiar actividades de desarrollo dentro de un proceso de anlisis que incorpora las siguientes actividades estructurales: requerimientos, anlisis, diseo, evolucin y entrega. Dentro de cada actividad estructural, las tareas del trabajo ocurren con un patrn del proceso llamado sprint.

Scrum acenta el uso de un conjunto de patrones de proceso del software que han demostrado ser eficaces para proyectos con plazos de entrega muy apretados, requerimientos cambiantes y negocios crticos. Cada uno de estos patrones de proceso define un grupo de acciones de desarrollo:

Retraso: lista de prioridades de los requerimientos o caractersticas del proyecto que dan al cliente un valor del negocio.

Sprints: consiste en unidades de trabajo que se necesitan para alcanzar un requerimiento definido en el retraso que debe ajustarse en una caja de tiempo predefinida.

Reuniones Scrum: son reuniones breves (de 15 minutos, por lo general) que el equipo Scrumefecta a diario.

Ventajas

Se obtiene software lo ms rpido posible y este cumple con los requerimientos ms importantes.

Se trabaja en iteraciones cortas, de alto enfoque y total transparencia.

Se acepta que el cambio es una constante universal y se adapta el desarrollo para integrar los cambios que son importantes.

Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado.

Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias.

Permite producir software de una forma consistente, sostenida y competitiva.

Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento.

Desventajas

Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario.

Es una metodologa que difiere del resto, y esto causa cierta resistencia en su aplicacin para algunas personas.

Cristal

Alistar Cockburn cre la familia Cristal de mtodos giles a fin de obtener un enfoque de desarrollo de software que premia la maniobrabilidad durante lo que Cockburn caracteriza como un juego cooperativo con recursos limitados, de invencin y comunicacin, con el objetivo primario de entregar software til que funcione y con la meta secundaria de plantear el siguiente juego.

Es una metodologa centrada en el factor humano, donde un diseador lder y de dos a siete desarrolladores ms, se encuentran juntos en un local grande o en locales adyacentes con radiadores de informacin como pizarras y diagramas bien visibles en la pared, teniendo acceso fcil a usuarios claves; eliminando las distracciones; entregando cdigo funcional, testeado y utilizable en intervalos de uno a tres meses; reflexionando peridicamente y ajustando continuamente su estilo de trabajo.

Fases en las metodologas Cristal son:

Puesta en escena. Consiste en la planificacin del siguiente incremento. La planificacin debe finalizar con una planificacin ejecutable cada tres o cuatro meses. El equipo selecciona los requerimientos que sern implementados en el incremento y planifican lo que harn.

Revisiones. Cada incremento tiene varias iteraciones y cada iteracin incluye las actividades de construccin, demostracin y resumen de objetivos del incremento.

Monitoreo. Los progresos son monitoreados a partir de las diferentes entregas.

Paralelismo y flujo. Cuando el monitoreo nos brinda un estado suficientemente estable es hora de pasar a la prxima etapa. En CO nos indica que los equipos pueden trabajar con la mxima eficiencia concurrente.

Estrategia de diversidad holstica. Se utiliza en CO para dividir grandes equipos funcionales en equipos multifuncionales.

Tcnica de puesta a punto de la metodologa. Se basa en entrevistas y talleres para laborar una metodologa especfica para el proyecto. Sirve para modificar o fijar el proceso de desarrollo.

Puntos de vista del usuario. En CC se recomienda la opinin de dos usuarios por cada versin del producto, en CO tres revisiones por parte del cliente en cada iteracin.

Polticas diferentes para equipos diferentes

Clear es para equipos de hasta 8 personas o menos.

Amarillo para equipos entre 10 a 20 personas.

Naranja para equipos entre 20 a 50 persona.

Roja para equipos entre 50 a 100 personas.

La familia cristal dispone un cdigo de color para marcar la complejidad de una metodologa: cuanto mas obscuro un color, mas pesado es el mtodo, cuanto mas critico es un sistema, mas rigor se requiere.

En la figura se muestra una evaluacin de las pedidas que pueden ocasionar la falla de un sistema y el mtodo requerido segn este criterio.

Valores

Frecuencia en las entregas.

Comunicacin.

Crecimiento reflexivo.

Seguridad personal.

Concentracin.

Usuarios expertos.

Entorno tcnico para pruebas automatizadas.

Roles

Executive Sponsor (Patrocinador Ejecutivo).

Project Manager (Jefe de Proyecto).

Domain Expert (Experto en el Dominio).

Usage Expert (Experto de uso).

Designer-Programmer (Programador Diseador).

UI Designer (UI Diseador).

Tester (Realizador de Pruebas).

Technical (Programador Tcnico).

Caractersticas

1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia.

2. Retroalimentacin continua. El equipo entero se rene constantemente para discutir las actividades del proyecto.

3. Comunicacin constante. Se procura que cada uno de los miembros tengan acceso constante.

4. Seguridad. Se reconoce la prioridad del software.

5. Enfoque. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo.

6. Acceso a usuarios. Acceso a uno o ms usuarios del sistema que se estn construyendo.

7. Pruebas Automticas e Integracin. Ambiente tcnico con prueba automatizada, administracin de configuracin e integracin frecuente.

Ventajas

Es apropiada para entornos ligeros.

Al estar diseada para el cambio experimenta reduccin de costo.

Presenta una planificacin ms transparente para los clientes.

Se definen en cada iteracin cuales son los objetivos de la siguiente.

Permite tener una muy til realimentacin de los usuarios.

Su efectividad es mayor si se trabaja en equipos pequeos.

Desventajas

Delimita el alcance del proyecto con el cliente.

Su efectividad es menor si se trabaja en equipos grandes.

Kanban:

Los sistemas Kanban consisten en un conjunto de formas de comunicarse e intercambiar informacin entre los diferentes operarios de una lnea de produccin, de una empresa, o entre proveedor y cliente. Su propsito es simplificar la comunicacin, agilizndola y evitando errores producidos por falta de informacin.

El ejemplo ms comn de Kanban son las etiquetas que se les incorporan a los productos mientras son fabricados, para que posteriormente quede identificado a dnde tienen que enviarse o qu caractersticas tiene.

Estos son algunas de las formas de implementar un sistema Kanban:

Etiquetas de transporte con informacin de lo que contiene cada paquete y su destino.

Etiquetas de fabricacin con informacin de las caractersticas del producto a fabricar.

Etiquetas con cualquier otro tipo de informacin relevante para la realizacin de las actividades.

Fases principales para una buena implementacin del sistema Kanban:

Fase 1. Entrenar a todo el personal en los principios de kanban y sus beneficios.

Fase 2. Implementar kanban en aquellos componentes con mas problemas para facilitar su manufactura y para resaltar los problemas escondidos. El entretenimiento con el personal continua en la lnea de produccin.

Fase 3. Implementar kanban en el resto de los componentes.

Fase 4. Revisar del sistema kanban, los puntos de reorden y los niveles de reorden.

Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio, es ms importante que el seguimiento estricto de un plan. Se proponen porque para muchos clientes esta flexibilidad ser una ventaja competitiva y porque estar preparados para el cambio, significa reducir su coste.

Ventajas de las metodologas agiles:

Es que estas metodologas ofrecen una rpida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como despus poder modificarlos evitando grandes prdidas en cuanto a costes, motivacin, tiempo, etc.

El cliente, si quiere colaborar, puede observar como va avanzando el proyecto, y por supuesto, opinar sobre su evolucin gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.

Se puede deducir que al utilizar estas metodologas, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un pequeo intervalo de tiempo una pequea parte del proyecto al cliente, y si ste quiere cambiarlo, solo se habr perdido unas semanas de trabajo.

Importancia de la simplicidad al eliminar trabajo innecesario.

Desventajas de las metodologas agiles:

Falta de documentacin del diseo. Al no haber documentacin en el cdigo (junto con sus comentarios).

Fuerte dependencia de las personas.

Falta de reusabilidad derivada de la falta de documentacin.

Restricciones en cuanto a tamao de los proyectos.

Problemas derivados del fracaso de los proyectos giles. Si un proyecto gil fracasa no hay documentacin o hay muy poca; lo mismo ocurre con el diseo. La comprensin del sistema se queda en las mentes de los desarrolladores.

EmergenteEl tipo de conocimiento que genera este tipo de investigacin no se basa tanto en relaciones de causas y efectos como de llevar a cabo una comprensin de la realidad desde los mltiples puntos de vista de las personas implicadas.

Las conclusiones (o ms bien reflexiones a partir de lo investigado) son en realidad pequeas generalizaciones basadas en un contexto especfico.

Flexible, ya que las decisiones estn abiertas a las modificaciones que sean necesarias en funcin de las exigencias del proceso de investigacin.

Emergente, porque se desarrolla y evoluciona a lo largo de la investigacin.

Participativo y dialctico; ya que las diferentes fases se llevan a cabo por los diferentes miembros del equipo investigador y entre los implicados.

ICONIX

Es un proceso simplificado en comparacin con otros procesos ms tradicionales, que unifica un conjunto de mtodos de orientacin a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto.

ICONIX presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Adems, est adaptado a patrones y ofrece el soporte UML, dirigido por Casos de Uso y es un proceso iterativo e incremental.

Las tres caractersticas fundamentales de ICONIX son:

Iterativo e incremental: varias interacciones ocurren entre el modelo del dominio y la identificacin de los casos de uso. El modelo esttico es incrementalmente refinado por los modelos dinmicos.

Trazabilidad: cada paso est referenciado por algn requisito. Se define la trazabilidad como la capacidad de seguir una relacin entre los diferentes artefactos producidos.

Dinmica del UML: la metodologa ofrece un uso dinmico del UML como los diagramas del caso de uso, diagramas de secuencia y de colaboracin.

Mtodos

a) Anlisis de Requisitos

Modelo de dominio

Prototipacin rpida

Modelo de casos de uso

b) Anlisis y diseo preliminar

Descripcin de casos de uso

Diagrama de robustez

c) Diseo

Diagrama de secuencia

Completar el modelo esttico

d) Implementacin

Utilizar un diagrama de componentes

Escribir / Generar cdigo

Realizacin de pruebas

Ventajas:

Desarrollo incremental e iterativo y la relativa facilidad con que se puede utilizar en otras metodologas de desarrollo u otras tcnicas.

Satisface la mayor parte de los requisitos del cliente.

Usa un anlisis de robustez que reduce la ambigedad al describir los casos.

Es usado en proyectos ms ligeros que los usados en RUP, por lo que tiene un mayor campo de aplicabilidad.

Proporciona suficientes requisitos y documentacin de diseo, pero sin parar el anlisis.

Es refinado y actualizado a lo largo del proyecto, por lo que siempre refleja la actual comprensin del problema de espacio.

Desventajas:

No puede ser usado para proyectos grandes.

Necesita informacin rpida y puntual de los requisitos, el diseo y las estimaciones.

Se debe de conocer los diagramas de UML.

Modelo de mtodos formales El modelo de mtodos formales comprende agrupa actividades que llevan a la

especificacin matemtica del software de computadora.

Los mtodos formales permiten que un ingeniero de software especifique, desarrolle yverifique un sistema basado en computadora aplicando una notacin rigurosa ymatemtica.

Permiten especificar, desarrollar y verificar un sistema basado en computadora por mediodel empleo de una notacin matemtica rigurosa.

Sirven como base para la verificacin del programa, y as permiten descubrir y corregirerrores que de otro modo no seran detectados.

Aunque el modelo de los mtodos formales no es el ms seguido, promete un software librede defectos.

El enfoque de los mtodos formales ha ganado partidarios entre los desarrolladores quedeben construir software de primera calidad en seguridad (por ejemplo, controlelectrnico de aeronaves y equipos mdicos), y entre los desarrolladores que sufrirangraves prdidas econmicas si ocurrieran errores en su software.

Ventajas Se comprende mejor el sistema.

La comunicacin con el cliente mejora ya que se dispone de una descripcin clara y noambigua de los requisitos del usuario.

El sistema se describe de manera ms precisa.

El sistema se asegura matemticamente que es correcto segn las especificaciones.

Mayor calidad software respecto al cumplimiento de la realidad hacia el desarrollo deherramientas que apoyen la aplicacin de mtodos formales es complicado y los programasresultantes son incmodos para los usuarios.

Los investigadores por lo general no conocen la realidad industrial.

Es escasa la colaboracin entre la industria y el mundo acadmico, que en ocasiones semuestra demasiado dogmtico.

Se considera que la aplicacin de mtodos formales encarece los productos y ralentiza sudesarrollo.

Desventajas El desarrollo de modelos formales consume mucho tiempo y es caro.

Debido a que pocos desarrolladores de software tienen la formacin necesaria para aplicarmtodos formales, se requiere mucha capacitacin.

Es difcil utilizar los modelos como mecanismo de comunicacin para clientes sincomplejidad tcnica.

Bibliografas

Roger, S. P., Ingeniera de software, Un enfoque practico, 7ta edicin. Mxico D. F.: The McGraw-Hill, 2010.

http://fgaith2.blogspot.mx

http://ithjlmvu2.blogspot.mx

http://www.marcoteorico.com/curso/45/ingenieria-de-software/260/otras-metodologias