Enfoques de desarrollo de software. Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software.

Estos son los enfoques ms generales, que se desarrollan en varias metodologas especficas.

INCREMENTAL
Provee

una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.

 Los principios bsicos son:

Una serie de mini-Cascadas se llevan a cabo, donde

todas las fases de la cascada modelo de desarrollo se han completado para una pequea parte de los sistemas, antes de proceder a la prxima incremental

 Se definen los requisitos antes de proceder con la

evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura y colectiva bsicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalacin del prototipo final.

Rapid Application Development (RAD)

El desarrollo rpido de aplicaciones (RAD) es una

metodologa de desarrollo de software, que implica el desarrollo interativo y la construccin de prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.

Principios bsicos:
Objetivo clave es para un rpido desarrollo y entrega

de una alta calidad en un sistema de relativamente bajo coste de inversin. Intenta reducir el riesgos inherente del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo.


Orientacin dedicada a producir sistemas de alta

calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Hace especial hincapi en el cumplimiento de la necesidad comercial, mientras que la ingeniera tecnolgica o la excelencia es de menor importancia.


Control

de proyecto implica el desarrollo de prioridades y la definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite. En general incluye Joint application development (JAD), donde los usuarios estn intensamente participando en el diseo del sistema, ya sea a travs de la creacin de consenso estructurado en talleres, o por va electrnica.


La

participacin activa de los usuarios es imprescindible. Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo. Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.

MODELO EN V
El modelo en v se desarroll para terminar con

algunos de los problemas que se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducan hasta el final del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo ms pronto posible en el ciclo de vida. Tambin muestra que las pruebas no son slo una actividad basada en la ejecucin.


Hay una variedad de actividades que se han de

realizar antes del fin de la fase de codificacin. Estas actividades deberan ser llevadas a cabo en paralelo con las actividades de desarrollo, y los tcnicos de pruebas necesitan trabajar con los desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y tareas y producir una serie de entregables de pruebas.

Ventajas
Las ventajas que se pueden destacar de este modelo son

las siguientes: Es un modelo simple y fcil de utilizar. En cada una de las fases hay entregables especficos. Tiene una alta oportunidad de xito sobre el modelo en cascada debido al desarrollo de planes de prueba en etapas tempranas del ciclo de vida. Es un modelo que suele funcionar bien para proyectos pequeos donde los requisitos son entendidos fcilmente.

Inconvenientes
Entre los inconvenientes y las crticas que se le hacen a

este modelo estn las siguientes: Es un modelo muy rgido, como el modelo en cascada. Tiene poca flexibilidad y ajustar el alcance es difcil y caro. El software se desarrolla durante la fase de implementacin, por lo que no se producen prototipos del software.

Modelo iterativo
Es un modelo derivado del ciclo de vida en

cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos.


Consiste en la iteracin de varios ciclos de vida en

cascada. Al final de cada iteracin se le entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El cliente es quien despus de cada iteracin evala el producto y lo corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga las necesidades del cliente.

Modelo de ciclo de vida

Ventajas
Una de las principales ventajas que ofrece este

modelo es que no hace falta que los requisitos estn totalmente definidos al inicio del desarrollo, sino que se pueden ir refinando en cada una de las iteraciones. Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo en pequeos ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las entregas

Inconvenientes
La primera de las ventajas que ofrece este

modelo, el no ser necesario tener los requisitos definidos desde el principio, puede verse tambin como un inconveniente ya que pueden surgir problemas relacionados con la arquitectura.

Historias de usuario:
El primer paso de cualquier proyecto que siga la metodologa X.P es definir las historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias, como por ejemplo, Constan de 3 4 lneas escritas por el cliente en un lenguaje no tcnico sin hacer mucho hincapi en los detalles.

Relase planning:
Despus de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en ingls "Relase plan", donde se indiquen las historias de usuario que se crearn para cada versin del programa y las fechas en las que se publicarn estas versiones. Un "Relase plan" es una planificacin donde los desarrolladores y clientes establecen los tiempos de implementacin ideales de las historias de usuario, la prioridad con la que sern implementadas y las historias que sern implementadas en cada versin del programa.

Iteraciones:
Todo proyecto que siga la metodologa X.P. se ha de dividir en iteraciones de aproximadamente 3 semanas de duracin. Al comienzo de cada iteracin los clientes deben seleccionar las historias de usuario definidas en el "Relase planning" que sern implementadas. Tambin se seleccionan las historias de usuario que no pasaron el test de aceptacin que se realiz al terminar la iteracin anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 das de duracin que se asignarn a los programadores

Velocidad del proyecto:

La velocidad del proyecto es una medida que representa la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el nmero de historias de usuario que se pueden implementar en una iteracin; de esta forma, se sabr el cupo de historias que se pueden desarrollar en las distintas iteraciones.

Usando la velocidad del proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteracin.

Programacin en pareja:
La metodologa X.P. aconseja la programacin en parejas pues incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica haciendo hincapi en la calidad de la funcin o mtodo que est implementando, el otro analiza si ese mtodo o funcin es adecuado y est bien diseado. De esta forma se consigue un cdigo y diseo con gran calidad.

Reuniones diarias:
Es necesario que los desarrolladores se renan diariamente y expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el mundo tiene que tener voz y voto.

Diseos simples:
La metodologa X.P sugiere que hay que conseguir diseos simples y sencillos.
Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseo fcilmente entendible e implemntale que a la larga costar menos tiempo y esfuerzo desarrollar.

Glosarios de trminos

Riesgos
Funcionabilidad Extra

Tarjetas C.R.C

La codificacin debe hacerse ateniendo a estndares de codificacin ya creados. Programar bajo estndares mantiene el cdigo consistente y facilita su comprensin y escalabilidad.

Crear test que prueben el funcionamiento de los distintos cdigos implementados nos ayudar a desarrollar dicho cdigo.

Uno de los pilares de la metodologa X.P es el uso de test para comprobar el funcionamiento de los cdigos que vayamos implementando. El uso de los test en X.P son diferentes para cada aspecto, por ejemplo podra verse de la siguiente manera:
Se deben crear las aplicaciones que realizarn los test con un entorno de desarrollo especfico para test.

Hay que someter a tests las distintas clases del sistema omitiendo los mtodos ms triviales.

SCRUM
Scrum es un proceso gil que se puede usar

para gestionar y controlar desarrollos complejos de software y productos usando prcticas iterativas e incrementales. Scrum es un proceso incremental iterativo para desarrollar cualquier producto o gestionar cualquier trabajo.

 Aunque Scrum estaba previsto que fuera para la

gestin de proyectos de desarrollo de software, se puede usar tambin para la ejecucin de equipos de mantenimiento de software o como un enfoque de gestin de programas.

Caractersticas
Scrum es un esqueleto de proceso que incluye

un conjunto de prcticas y roles predefinidos. Los roles principales en Scrum son el ScrumMaster que mantiene los procesos y trabaja junto con el jefe de proyecto, el Product Owner que representa a las personas implicadas en el negocio y el Team que incluye a los desarrolladores.


Una

parte muy importante de Scrum son las reuniones que se realizan durante cada una de las iteraciones. Hay distintos tipos:

Scrum diario: cada da durante la iteracin, tiene

lugar una reunin de estado del proyecto. A esta reunin se le domina Scrum Reunin de planificacin de iteracin (sprint): se lleva a cabo al principio del ciclo de la iteracin. Reunin de revisin de iteracin: al final del ciclo de la iteracin. Iteracin retrospectiva: al final del ciclo de la iteracin.

Flujo de proceso de SCRUM

Dynamic Systems Development Method (DSDM)

El mtodo de desarrollo de sistemas dinmico

(DSDM) es una metodologa de desarrollo de software originalmente basada en la metodologa RAD. DSDM es un enfoque iterativo e incremental que enfatiza la participacin continua del usuario.


Su objetivo es entregar sistemas software en tiempo

y presupuesto ajustndose a los cambios de requisitos durante el proceso de desarrollo. DSDM es uno de los mtodos giles para el desarrollo de software, y forma parte de la Alianza gil.

Ciclo de desarrollo de DSDM

Crystal Clear
Crystal Clear es un miembro de la familia de

metodologas Crystal como describe Alistair Cockburn y se considera un ejemplo de metodologa gil. Crystal Clear est pensado para aplicarse a equipos pequeos de 6 a 8 desarrolladores ubicados en el mismo sitio trabajando en sistemas que no son crticos. La familia de metodologas Crystal se centra en la eficiencia y habitabilidad (las personas pueden vivir con l e incluso usarlo) como componentes de la seguridad del proyecto.


Crystal Clear se centra en las personas, no en los

procesos o artefactos. Crystal Clear cuenta con las siguientes propiedades (las tres primeras son requeridas): Entrega frecuente de cdigo usable a los usuarios Mejora reflexiva Comunicacin osmtica preferiblemente estando en la misma ubicacin Seguridad personal Fcil acceso a los usuarios expertos

Agile Unified Process (AUP)

El proceso unificado gil (AUP) es una versin

simplificada de RUP desarrollada por Scott Ambler. Describe un enfoque simple, fcil de entender, del desarrollo de software de aplicacin de negocios usando tcnicas y conceptos giles. AUP aplica tcnicas giles incluyendo desarrollo orientado a pruebas, modelado gil, gestin de cambios gil y refactorizacin de bases de datos para mejorar la productividad.

La naturaleza en serie de AUP se presenta en cuatro fases:

Inicio: el objetivo es identificar el alcance inicial del

proyecto, una arquitectura potencial para el sistema y obtener fondos y aceptacin por parte de las personas involucradas en el negocio. Elaboracin: el objetivo es probar la arquitectura del sistema.


Construccin: el objetivo es construir software

operativo de forma incremental que cumpla con las necesidades de prioridad ms altas de las personas involucradas en el negocio.
Transicin: el objetivo es validar y desplegar el

sistema en el entorno de produccin.

REINGENIERIA

Conceptualizacin general
Proceso de reingeniera de negocios y/o el software de reingeniera que lo soporta. Aplicando procesos:Las revisiones tcnicas formales que evalan los modelos de anlisis y de diseo. las revisiones tcnicas especializadas: capacidad de aplicacin comercial , la compatibilidad y la comprobacin se aplican a descubrir errores en la funcionalidad y en la interoperabilidad.

Define metas comerciales, Mundo cambiante, identifica y con funciones de evala los negocio y procesos de tecnologa de *Especialist negocios y informacin . as en crea procesos que mejoran Cualquier producto va negocio. las metas envejeciendo, un *Ingenieros software no es un de software hadware que se tira y se remplaza, mas bien se reconstruye. funcionabilidad, rendimiento y fiabilidad.

Concepto general
El software suele ser la realizacin de las reglas

de negocio que describe Hammer. A medida que las reglas cambian, el software tambin tiene que cambiar. En la actualidad, existen compaas importantes que poseen decenas de miles de programas de computadora que prestan apoyo a las viejas reglas del negocio.

 Cuando

los administradores trabajan para modificar estas reglas y lograr as una mayor efectividad y competitividad, el software seguir el mismo ritmo en algunos casos, esto implica la creacin de sistemas nuevos e importantes basados en computadora. Pero en muchos otros, esto implica la modificacin y/o reconstruccin de las aplicaciones existentes.

Mantenimiento
Un problema al realizar software es el

mantenimiento del mismo, ya que al momento la empresa se ocupa de otros problemas mas importantes, que el actualizar, corregir, adaptar y mejorar el sistema que controla sus procesos.
La reingeniera fue creada por un iceberg

MANTENIMEINTO DEL SOFTWARE

Gran parte del software del que dependemos en

la actualidad tiene por trmino medio entre diez y quince aos de antigedad. Aun cuando los softwares se realizan con las mejores tcnicas de diseo en la poca, se crearon cuando el tamao de los programas y el espacio de almacenamiento eran las preocupaciones principales.

Mantenimiento del software.

Problema: Nuevas plataformas Cambios de maquina y S.O. Nuevas necesidades

ARQUITECTURA GLOBAL

Que es la reingeniera?
Al adquirir un software hay que tomar en cuenta que

est envejeciendo. Y al final ya no representa la ltima tecnologa. Si el producto es de hardware, probablemente ser se adquirir uno nuevo pero si es un software personalizado, no se puede tirar. Se necesitar reconstruirlo. Crear un producto con funcionalidad nueva, mejor rendimiento y fiabilidad, y un mantenimiento mejorado.

A esto se le llama reingeniera.

Quien hace la reingeniera?

La reingeniera es ejercida por especialistas de

negocio (A nivel de negocio) frecuentemente empresas de consultora. A nivel de software, la reingeniera es ejecutada por ingenieros del software.

Por qu es importante?
Ya que vivimos en un mundo en constante

cambio, las demandas de funciones de negocios y de tecnologa de informacin que las soportan estn cambiando la cual impone presin competitiva en todas las organizaciones comerciales. Tanto los negocios como el software que lo soportan, debern disearse una vez ms para mantener el ritmo.

Pasos de la REINGENIERIA
La reingeniera de procesos de negocios (RPN)

define las metas comerciales, identifica y evala los procesos de negocios existentes, crea procesos comerciales revisados que mejoran las metas actuales. El proceso de reingeniera del software acompaa el anlisis de inventarios, la estructuracin de documentos, la ingeniera inversa, la reestructuracin de datos y la ingeniera avanzada. El objetivo de estas actividades es crear versiones nuevas de los programas existentes que exhiben una mantenibilidad de mayor calidad.

Producto Obtenido
Son varios los productos que se elaboran (por

ejemplo, modelos anlisis, modelos de diseo, procedimientos de pruebas). El resultado final es un proceso de reingeniera de negocios y/o el software de reingeniera que lo soporta.

Esta o no bien hecho!

Utilizando las mismas prcticas que se aplican en todos los procesos de ingeniera del software

Las revisiones tcnicas formales

evalan los modelos de anlisis y de diseos, las revisiones especializadas tienen en consideracin la capacidad de aplicacin comercial y la compatibilidad.

la comprobacin se aplica para descubrir los errores en el contenido, en la funcionalidad y en la interoperabilidad.