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 Ivar

Jacobson 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 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.
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 cara
en 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 Scrum
efecta 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.

Emergente
El 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)

b)

c)

d)

Anlisis de Requisitos

Modelo de dominio

Prototipacin rpida

Modelo de casos de uso

Anlisis y diseo preliminar

Descripcin de casos de uso

Diagrama de robustez

Diseo

Diagrama de secuencia

Completar el modelo esttico

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 y

verifique un sistema basado en computadora aplicando una notacin rigurosa y
matemtica.

Permiten especificar, desarrollar y verificar un sistema basado en computadora por medio

del empleo de una notacin matemtica rigurosa.

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

Aunque el modelo de los mtodos formales no es el ms seguido, promete un software libre

de defectos.

El enfoque de los mtodos formales ha ganado partidarios entre los desarrolladores que
deben construir software de primera calidad en seguridad (por ejemplo, control
electrnico de aeronaves y equipos mdicos), y entre los desarrolladores que sufriran
graves 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 no

ambigua 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 de

herramientas que apoyen la aplicacin de mtodos formales es complicado y los programas
resultantes 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 se

muestra demasiado dogmtico.

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

desarrollo.

Desventajas

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

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

Es difcil utilizar los modelos como mecanismo de comunicacin para clientes sin
complejidad 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/otrasmetodologias