Resumen

Captulo I
pg.
1

1.- Metodologa de Desarrollo de software

1.1.-Definicin:
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas etapas. Un modelo de ciclo de vida del software: Describe las fases principales de desarrollo de software. Define las fases primarias esperadas de ser ejecutadas durante esas fases. Ayuda a administrar el progreso del desarrollo, y Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software. As, los modelos por una parte suministran una gua para los ingenieros de software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

1.2.-Modelo Cascada
Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin. El modelo de ciclo de vida cascada, captura algunos principios bsicos: Planear un proyecto antes de embarcarse en l. Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna. Documentar los resultados de cada actividad.

pg.

 Disear un sistema antes de codificarlo. Testear un sistema despus de construirlo. 1.2.1.- Ciclo de vida en cascada

Comunicacin

Planeacin

Modelado

Construccin

Despliegue

1.3.- Modelo Incremental

Ella permite priorizar las funcionalidades del sistema requeridas por los usuarios e ir desarrollndolas en funcin de las necesidades. Pero a diferencia de los modelos evolutivos este modelo se centra en cada entregable a realizar, sin revidar o mejorar funcionalidades desarrolladas en iteraciones anteriores

pg.

1.3.1.-CICLO DE VIDA DEL SOFTWARE MODELO INCREMENTAL

Se evitan proyectos largos y se entrega Algo de valor a los

usuarios con cierta frecuencia. El usuario se involucra ms. Difcil de evaluar el coste total. Difcil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo. Requiere gestores experimentados. Los errores en los requisitos se detectan tarde. El resultado puede ser muy positivo.

1.4.- MODELO ESPIRAL

pg.

1.4.1.- Historia Modelo creado en el ao de 1986 por Boehm, de este surgi una de la ideas fundamentales que la metodologas posteriores adoptaran el anlisis de riesgo. Esta clase trato sobre el modelo espiral, el cual es a base de una serie de ciclos los cuales se repiten en forma de espiral, cada vez que se avanza un ciclo se va alcanzando un nivel superior hasta concluir el proyecto. Este modelo utiliza prototipos para un mejor desarrollo del producto. Lo caracterstico de este modelo es que incluye un anlisis de riesgo es decir que podemos analizar si el proyecto puede continuar o mejor lo suspendemos. Este modelo se basa en que antes de hacer algo debemos analizarlo, tambin debemos buscar varias opciones de resolucin de problemas para de all escoger la opcin ms conveniente, y adems analizar los riesgos que se pueda tener. Este modelo necesita de otro para poder desarrollarse. Se debe escoger el modelo cascada cuando se pierda el control del presupuesto o por el calendario; y el de prototipo cuando tengamos problemas con la interfaz. El modelo espiral consta de 4 cuadrantes que son sus fases y se dividen de la siguiente forma: 1.2.3.4.Planificacin. Anlisis de Riesgos. Ingeniera. Evaluacin.

pg.

1.4.2.- Caractersticas Principales Trata de mejorar los ciclos de vida clsicos y prototipos. Permite acomodar otros modelos. Incorpora objetivos de calidad y gestin de riesgos. Elimina errores y alternativas no atractivas al comienzo. Permite iteraciones, vuelta atrs y finalizaciones rpidas. Cada ciclo empieza identificando: Los objetivos de la porcin correspondiente. Las alternativas. Restricciones.

Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el plan para el siguiente.

Reconocimiento explcito de las diferentes alternativas. Identificacin de riesgos para cada alternativa desde el comienzo.

Al dividir el proyecto en ciclos, al final de cada uno existe un acuerdo para los cambios que hay que realizar en el sistema.

El modelo se adapta a cualquier tipo de actividad adicional.

1.5.- Modelo de proceso evolutivo

El software como todos los sistemas complejos evoluciona con el tiempo los requisitos de los negocios y productos cambian conforme se realiza el desarrollo; por lo tanto la ruta lineal que conduce a un producto final no ser real ; las estrictas fechas de tope de mercado imposibilitan la conclusin de un producto completo, por lo que se debe presentar una versin limitada para liberar la presin competitiva y de negocios se tiene claro un conjunto de requisitos del producto o sistema esencial pero todava se deben definir los detalles de las extensiones del producto o sistema. En estos y otras situaciones similares los ingenieros de software necesitan un modelo de proceso que haya sido diseado de manera explcita para incluir un producto que evolucione con el tiempo. Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez ms completas del software. Los modelos de procesos evolutivos producen una versin completa en forma incremental con cada iteracin

pg.

Captulo II
2.1.- Modelo de programacin Extrema (XP)
2.1.1.- Introduccin
La mayora de los programadores tenemos cierta tendencia en embebernos en cuestiones tcnicas, hablar de lenguajes de programacin, de tcnicas de programacin, de entornos de desarrollo o de editores de recursos. Pero se nos pasan por alto temas muy importantes que nos afectan tanto o ms que las cuestiones mencionadas, como es la ingeniera de software, la manera en que debemos de hacer nuestro software. Alrededor de cmo hacer software hay un gran nmero de autores teoras, propuestas, etc., etc.

2.1.2.- Historia
La Programacin Extrema, como proceso de creacin de software diferente al convencional, nace de la mano de Kent Beck (gur de la XP y autor de los libros ms influyentes sobre el tema). Chrysler Corporation haca tiempo que estaba desarrollando una aplicacin de nminas, pero sin demasiado xito por parte de la gente que tena en el proyecto. El verano de 1996, Beck entr en nmina en la compaa y se le pidi de hacer esta aplicacin como trabajo. Es en esta aplicacin cuando nace la Programacin Extrema como tal. Beck reconoci que el proceso (o metodologa) de creacin de software o la carencia de este era la causa de todos los problemas y lleg a la conclusin que para proporcionar un proceso que fuera flexible era necesario realizar ciertos cambios en la estructura o manera de hacer de los programadores, los cuales se tenan que acomodar al cambio a realizar. El tena varias ideas de metodologas para la realizacin de programas que eran cruciales para el buen desarrollo de cualquier sistema. Las ideas primordiales de su sistema las comunic en la revista C++ Magazine en una entrevista que sta le hizo el ao 1999. En sta deca que l estaba convencido que la mejor metodologa era un proceso que enfatizase la comunicacin dentro del equipo, que la implementacin fuera sencilla, que el usuario tena que estar muy informado y implicado y que la toma de decisiones tena que ser muy rpida y efectiva.

pg.

Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward Cunningham o Ron Jeffries entre otros) de la Programacin Extrema, fueron a la web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cmo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin que tenan y en cada pgina que, poco o mucho hablara de temas de programacin. Este hecho, lleg a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programacin. Fue tanta esta molestia que naci el fenmeno XP Free Zone (zona libre de XP) en determinadas webs como peticin de no hablar de Programacin Extrema en ella. La discusin sobre temas de diseo de modelos de programacin sobre los cambios recientes se hizo tema difcil porque la mayora de la actividad fue relacionada con la Programacin Extrema. Eventualmente, y debido a esto, la mayora de la gente que sola discutir sobre los temas de diseo de modelos de programacin fue apartndose de este ambiente para discutir sus ideas en otros ambientes ms "reservados". La comunidad empez a referirse a estos sitios como a Salas Wiki

2.1.3.- Definicin
La programacin extrema es una metodologa de desarrollo ligera (o gil) basada en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programacin se basa en una serie de metodologas de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay

2.1.4.- XP Sus objetivos

Los objetivos de XP son muy simples: la satisfaccin del cliente. Esta metodologa trata de dar al cliente el software que l necesita y cuando lo necesita. Por tanto, debemos responder muy rpido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programacin. El segundo objetivo es potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estn involucrados en el desarrollo del software.

pg.

2.1.5.-Las cuatro variables.

XP define cuatro variables para proyectos de software: coste, tiempo, calidad y mbito. Adems de estas cuatro variables, Beck propone que slo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores en funcin de las otras tres. Pongmonos en un episodio diario de desarrollo. El jefe de proyecto: Quiero estos requisitos realizados para el da 1 de mes prximo, con lo que contis con el equipo actual. Ah ya sabis que la calidad es lo primero! Todos sabemos qu es lo primero que salta por la ventana en estos casos: la calidad, Por qu? Porqu nadie es capaz de trabajar bien cuando se le somete a mucha presin. XP nos propone que juguemos todas las partes implicadas en el proyecto hasta que el valor que alcancen las cuatro variables sea el correcto para todas las partes: Si quieres ms calidad en menos tiempo tendrs que aumentar el equipo e incrementar el coste. Adems con el agravante de que estas cuatro variables no guardan una relacin tan directa como en principio pueda parecer. El incremento del nmero de programadores no repercutir de manera lineal en el tiempo de desarrollo del proyecto, siendo de todo conocido el dicho: nueve mujeres no pueden tener un hijo en un mes. Con la calidad suele suceder un fenmeno extrao: frecuentemente un proyecto que tratemos de aumentar la calidad conduce a que el proyecto pueda realizarse en menos tiempo, siempre con unos mrgenes obviamente. Es verdad que cuando un equipo de desarrollo se acostumbra a realizar pruebas intensivas, se siguen estndares de codificacin, poco a poco se comenzara a andar ms rpido y ms seguro, por tanto ms preparados para futuros cambios, sin estrs y as sucesivamente. Frente a esto existe la tentacin de entregar el trabajo ms rpido, por tanto probar menos, codificar ms rpido y peor, sin hacer planteamientos maduros, esto repercutir en la confianza de nuestros clientes, al entregarle trabajos con fallos. Esta es una apuesta a muy corto plazo y suele ser una invitacin al desastre, conduce a la desmoralizacin del equipo, y con ello a la larga a la ralentizacin del proyecto y la prdida de tiempo que habramos conseguido en un principio. La cuarta variable, el mbito del proyecto, suele ser conveniente que sea establecida por el equipo de desarrollo. Es una variable muy importante que nos va a decir donde vamos a llegar con nuestro software, que problemas vamos a resolver y cuales vamos a dejar para siguientes versiones. Cuntas veces hemos escuchado Los clientes no nos pueden decir lo que quieren. Cuando le damos lo que nos piden no les gusta. Y es que los requisitos nunca

pg.

son claros al principio y el mismo desarrollo del software hace cambiar los requisitos. Por tanto el mbito debe de ser dctil, podremos jugar con l, si el tiempo para el lanzamiento es limitado, siempre habr cosas que pudramos diferir para siguientes versiones. Por tanto implementaremos primero los requisitos ms importantes para el cliente, de forma que si tenemos que dejar algo para despus que sea menos importante que las que ya incorporen un sistema.

2.1.6.- El coste del cambio.

Una de las suposiciones establecidas en la industria del software es que el coste de los cambios en un programa crece exponencialmente con el tiempo. XP propone que si el sistema que empleas hace que el coste del software aumente con el tiempo debes de actuar de forma diferente a cmo lo haces. XP propugna que esta curva ha perdido validez y con una combinacin de buenas prcticas de programacin y tecnologa es posible lograr que la curva sea la contraria, por tanto se pretende conseguir esto: Si decidimos aceptar el cambio debemos de desarrollar para basarnos en dicha curva, pero cmo se consigue dicha curva?, no existe una forma mgica desde luego hay varias medidas que nos ayudan a conseguirla. Disear los ms sencillos que sean posibles, para hacer slo lo imprescindible en un momento dado, la simplicidad del cdigo y los test continuos hace que los cambios sean posibles tan a menudo como sea necesario. La programacin orientada a objetos es una tecnologa clave para el mantenimiento del software, cada mensaje a un objeto es una oportunidad de cambio sin necesidad de cambiar el cdigo existente, esto no quiere decir que no puedas tener flexibilidad sin programar orientado al objeto y el caso contrario que haya programas orientados a objetos que nadie quera tocar, slo se dice que el programar orientado a objetos reduce el costo del cambio. En vez de tomar grandes decisiones al principio y pocas posteriormente, podemos idear una aproximacin para desarrollar software en la que se tomen decisiones rpidamente, pero estas decisiones apoyadas por pruebas y que te preparan para mejorar el diseo del software cuando aprendas una mejor manera de disearlo. He odo a muchos programadores (entre los que me incluyo) decir: Hasta que no he terminado el programa no lo he entendido ahora lo hara con esta jerarqua y que esta clase herede de esta otra, dejemos pues abierta la puesta a esta posibilidad.

2.1.7.- Los cuatro valores. pg.

10

Una de las cosas que a los programadores nos tiene que quedar muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarn los requisitos, las reglas de negocio, el personal, la tecnologa, todo va a cambiar. Por tanto el problema no es el cambio en s, ya que este va a suceder sino la incapacidad de enfrentarnos a estos cambios. Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos inciales.

Estos cuatro valores son: Comunicacin Sencillez Retroalimentacin Valenta

Comunicacin. Cuntas veces hemos tenido problema en nuestro equipo de desarrollo por falta de comunicacin, por no comentar un cambio crtico en el diseo, por no preguntar lo que pensamos al cliente. La mala comunicacin no surge por casualidad y hay circunstancias que conducen a la ruptura de la comunicacin, como aquel jefe de proyecto que abronca al programador cuando ste lo comunica que hay un fallo en el diseo. XP ayuda mediante sus prcticas a fomentar la comunicacin. Sencillez. Siempre debemos hacernos esta pregunta Qu es lo ms simple que pueda funcionar? Lograr la sencillez no es fcil. Tenemos cierta tendencia a pensar en qu programaremos maana, la prxima semana y el prximo mes. Cuntos de nosotros no hacemos a veces ms de lo que debemos: Ya que estoy tocando esta clase voy a aadirle dos mtodos ms para visualizar los mensajes en colores, cuando eso no est entre los requisitos, es que maana puede que lo necesite, si maana est entre los requisitos, hazlo entonces.

pg.

11

XP nos ensea a apostar, apuesta por hacer una cosa sencilla hoy y pagar un poco ms para maana, si es necesario, que hacer una cosa complicada hoy y no utilizarla despus. La sencillez y la comunicacin se complementan, cuanto ms simple es tu sistema menos tienes que comunicar de l.

Retroalimentacin. No me preguntes a m, pregntale al sistema, es la primera clave de la retroalimentacin, por medio de pruebas funcionales a nuestro software este nos mantendr informado del grado de fiabilidad de nuestro sistema, esta informacin realmente no tiene precio. Los clientes y las personas que escriben pruebas tienen una retroalimentacin real de su sistema. La retroalimentacin acta junto con la sencillez y la comunicacin, cuanto mayor retroalimentacin ms fcil es la comunicacin. Cuanto ms simple un sistema ms fcil de probar. Escribir pruebas nos orienta como simplificar un sistema, hasta que las pruebas funcionen, cuando las pruebas funcionen tendr mucho echo. Valenta. Asumir retos, ser valientes antes los problemas y afrontarlos. En mi experiencia como programador estuve realizando un programa de Nominas para la delegacin portuguesa de SP. Yo estaba encargado de elaborar unos informes para la seguridad social portuguesa denominados Balano Social, nunca se me olvidar. Mientras ms avanzaba en el trabajo ms engorro montaba en el cdigo por tal de que aquello funcionara despus de 3 semanas de trabajo casi lo tena resuelto, pero el cdigo estaba tan sper parcheado que no haba nadie que lo entendiera. Realmente hasta ese momento yo no entenda realmente lo que se necesitaba y decid tirarlo todo y reprogramar todo el sistema, al principio de los cambios todo empez a fallar, pero ahora avanzaba firme y seguro, a los pocos das todas las pruebas empezaron a funcionar, hasta que finalic el trabajo. Es una de las acciones valientes que adoptas y despus te enorgulleces de ellas, otras veces me he escondido detrs de la complejidad de los cambios y no los he realizado, me acobarde pensando en las consecuencias, en las broncas de mis jefes si les deca que haba cambiado el sistema. Cuando no afrontas el problema y parcheas un cdigo que positivamente sabes que est mal acabas odiando el sistema, y cada maana cuando vas a la oficina en el coche te entra dolor de barriga. Cuando vayas hacia el trabajo y se te revuelva el estomago piensa en cambiar de trabajo.

pg.

12

Nuestro trabajo se asimila al de un escalador cuando hacemos una cima tenemos que volver a bajar para hacer otra cima y as constantemente, plantendonos hacer sistemas cada vez ms sencillos y fiables. La valenta junto con la comunicacin y la sencillez se convierte en extremadamente valiosa. Odio este cdigo vamos a ver cunto podemos cambiar en esta tarde? Para continuar tenemos que disponer de unas guas ms concretas que satisfagan y encarnen estos cuatro valores.

2.1.8.- Las cuatro actividades bsicas

Ahora que tenemos nuestros cuatro valores estamos preparados para construir una disciplina de desarrollo de software. Qu tareas debemos de llevar a cabo para desarrollar un buen software?

Codificar Es la nica actividad de la que no podremos prescindir. Sin cdigo fuente no hay programa, aunque hay gente que cuenta que existe software en produccin del que se perdi el cdigo fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a travs del cdigo. En una programacin en XP en pareja el cdigo expresa tu interpretacin del problema, as podemos utilizar el cdigo para comunicar, para hacer mas tus ideas, y por tanto para aprender y mejorar. Hacer pruebas Las caractersticas del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que implement es lo que en realidad yo pensaba que haba implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo. No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro cdigo, con el tiempo llegaras a conclusiones sobre las pruebas y podrs pensar que si dos de tus pruebas ya funcionan la tercera prueba no ser necesaria escribirla, sin caer en demasiada confianza.

pg.

13

Programar y probar es ms rpido que slo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perders mucho tiempo en la depuracin. Tendrs menos errores, tendrs que volver menos veces sobre el cdigo, te costar menos localizar los errores, perders menos tiempo escuchado como tus clientes te dicen que no funciona. Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por all y volveremos a caer dentro. Escuchar Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software para qu nos querran? Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la informacin. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fcil y difcil de obtener, y la realimentacin entre ambos nos ayudan a todos a entender los problemas.

2.1.9.- Fases de la metodologa XP

Existen diversas prcticas inherentes al desarrollo de software. 2.1.9.1.- Planificacin. XP plantea la planificacin como un permanente dialogo entre las partes la empresarial (deseable) y la tcnica (posible). Las personas del negocio necesitan determinar: mbito: Qu es lo que el software debe de resolver para que este genere valor? Prioridad: Qu debe ser hecho en primer lugar? Composicin de versiones: Cunto es necesario hacer para saber si el negocio va mejor con software que sin l? En cuanto el software aporte algo al negocio debemos de tener lista las primeras versiones. Fechas de versiones: Cules son las fechas en la presencia del software o parte del mismo pudiese marcar la diferencia?

pg.

14

El personal del negocio no puede tomar en vaci estas decisiones, y el personal tcnico tomar las decisiones tcnicas que proporcionan la metera prima para las decisiones del negocio. Estimaciones: Cunto tiempo lleva implementar una caracterstica? Consecuencias: Informar sobre las consecuencias de la toma de decisiones por parte del negocio. Por ejemplo el cambiar las bases de datos a Oracle. Procesos: Cmo se organiza el trabajo y el equipo? Programacin detallada: Dentro de una versin Qu problemas se resolvern primero?

2.1.9.2.- Pequeas versiones. Cada versin debe de ser tan pequea como fuera posible, conteniendo los requisitos de negocios ms importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media caracterstica y lanzar la versin. Es mucho mejor planificar para 1 mes o 2 que para seis meses y un ao, las compaas que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.

2.1.10.- Criticas al modelo de programacin extrema

Hay opiniones de todos los gustos de quienes lo prueban. Las opiniones negativas mayoritarias alegan lo siguiente:

Los programadores tienen un acusado sentimiento de posesin del cdigo y esta postura no encaja con la filosofa de X.P. Tambin se ve un fuerte sentimiento para respectar las 40 horas semanales, y X.P. no lo garantiza.

Los jefes de proyecto tambin expresan su recelo con este mtodo tan poco tradicional. En cambio una visin ms optimista dice que:

X.P. slo funcionar con gente buena, es decir, profesionales que son capaces de hacer un buen diseo, sencillo y a la vez fcilmente ampliable. Por otro lado se ha de recalcar que XP no ha inventado ningn mtodo nuevo, sencillamente ha recogido mtodos ya existentes y los ha agrupado, y ha comprobado que funcionen. Y para

pg.

15

terminar, mencionar que el creador de XP asegura que se garantiza un rato

2.1.11.- Principios bsicos

La Programacin Extrema se basa en 12 principios bsicos agrupados en cuatro categoras: 2.1.11.1.- Retroalimentacin a escala fina. 2.1.11.1.1.El principio de pruebas: se tiene que establecer un perodo de pruebas de aceptacin del programa (llamado tambin perodo de caja negra) donde se definirn las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit testing frameworks). Un buen ejemplo de un ambiente de prueba es el JUnit para Java (www.junit.org/index.htm). Otros ambientes de pruebas para otros lenguajes como C, C++, JavaScript, XML y servicios Web, pueden encontrarse en www.xprogramming.com/software.htm. 2.1.11.1.2.- Proceso de planificacin: en esta fase, el usuario tendr
que escribir sus necesidades, definiendo las actividades que realizar el sistema. Se crear un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin para recibir retroalimentacin por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones peridicas durante esta fase de planificacin. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y sealar aquellos puntos a los que se les ha de dar ms importancia por su dificultad o por su punto crtico.

2.1.11.1.3.- El cliente en el sitio: se le dar poder para determinar los requerimientos, definir la funcionalidad, sealar las prioridades y responder las preguntas de los programadores. Esta fuerte interaccin cara a cara con el programador disminuye el tiempo de comunicacin y la cantidad de documentacin, junto con los altos costes de su creacin y mantenimiento. Este representante del cliente estar con el equipo de trabajo durante toda la realizacin del proyecto. 2.1.11.1.4.- Programacin en parejas: uno de los principios ms radicales y en el que la mayora de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su cdigo en parejas, compartiendo una sola mquina. De acuerdo con los experimentos, este principio puede producir aplicaciones ms buenas, de manera consistente, a iguales o menores costes. Aunque el pairprogramming puede no ser para todo el mundo, la evidencia anecdtica en la lista de correo de XP (extremeprogramming@yahoogroups.com) demuestra un gran xito.

pg.

16

2.1.11.2.- Proceso continuo en lugar de por lotes. 2.1.11.2.1.- Integracin continua: permite al equipo hacer un rpido progreso implementando las nuevas caractersticas del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su cdigo y reconstruir el sistema varias veces al da. Esto reduce los problemas de integracin comunes en proyectos largos y estilo cascada. 2.1.11.2.2.Refactorizacin: permite a los equipos de programadores XP mejorar el diseo del sistema a travs de todo el proceso de desarrollo. Los programadores evalan continuamente el diseo y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimizacin del cdigo duplicado y/o ineficiente. 2.1.11.2.3.- Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza de forma rpida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como mximo. 2.1.11.3.- Entendimiento compartido. 2.1.11.3.1.- Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos obsoletos de forma sencilla. 2.1.11.3.2.- Metfora: desarrollada por los programadores al inicio del proyecto, define una historia de cmo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metfora expresa la visin evolutiva del proyecto que define el alcance y propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo a definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con ellas). 2.1.11.3.3.- Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el

pg.

17

propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales en los que un simple programador posee un conjunto de cdigo. Los defensores de XP argumentan que mientras haya ms gente trabajando en una pieza, menos errores aparecern. 2.1.11.3.4.- Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona. 2.1.11.4.- Bienestar del programador. 2.1.11.4.1.- La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad. Como dice Beck, est bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas. 2.1.11.4.2.- Proceso de desarrollo. La programacin extrema parte del caso habitual de una compaa que desarrolla software, normalmente a medida, en la que hay diferentes roles: un equipo de gestin (o diseo), uno de desarrollo y los clientes finales. La relacin entre el equipo de diseo, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologas tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validacin posterior al mismo.

2.1.11.4.3.- Interaccin con el cliente. En este tipo de programacin el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es mxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificacin. Tiene un papel importante de interaccin con el equipo de programadores, sobre todo despus de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programacin existirn pruebas de aceptacin de la programacin que ayudarn a que su labor sea lo ms provechosa posible.

pg.

18

Al fin y al cabo, el cliente se encuentra mucho ms cerca del proceso de desarrollo. Se elimina la fase inicial de recopilacin de requerimientos, y se permite que stos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. En XP aparece un nuevo concepto llamado Historia de usuario. Se trata de una lista de caractersticas que el cliente necesita que existan en el producto final. Estas constan de dos fases.

En la primera fase, el cliente describe con sus propias palabras las caractersticas y, es el responsable del equipo, el encargado de informarlo de las dificultades tcnicas de cada una de ellas y de su coste. A consecuencia de este dilogo, el cliente deja por escrito un conjunto de historias y las ordena en funcin de la prioridad que tiene pera l. De esta manera ya es posible definir unas fechas aproximadas para ellos. En la segunda fase, el cliente coger las primeras historias a implementar y las dividir en trabajos a realizar. El cliente tambin participa, pero hay ms peso por parte del equipo de desarrolladores, esto dar como resultado una planificacin ms exacta. Este mtodo se repetir para cada historia.

A diferencia de otras tcnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. En esta fase, el equipo tcnico ser el 'encargado de catalogar las historias del cliente y asignarles una duracin. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programacin. Las que requieran menos tiempo sern agrupadas, y las que necesiten ms sern modificadas o divididas. Finalmente decir que las historias de los usuarios sern escritas en tarjetas, lo que facilitar que el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, as como el trabajo de los programadores que podrn catalogarlas correctamente. Este formato tambin es muy til en el momento de las pruebas de aceptacin.

2.1.12.- Ciclo de Vida

El ciclo de vida de Xp se enfatiza en el carcter interactivo e incremental del desarrollo, Segn [1] una iteracin de desarrollo es un perodo de tiempo en el que se realiza un conjunto de funcionalidades

pg.

19

determinadas que en el caso de Xp corresponden a un conjunto de historias de usuarios. Las iteraciones son relativamente cortas ya que se piensa que entre ms rpido se le entreguen desarrollos al cliente, ms retroalimentacin se va a obtener y esto va a representar una mejor calidad del producto a largo plazo. Existe una fase de anlisis inicial orientada a programar las iteraciones de desarrollo y cada iteracin incluye diseo, codificacin y pruebas, fases superpuestas de tal manera que no se separen en el tiempo.

2.1.13.- Fases
La siguiente figura muestra las fases en las que se subdivide el ciclo de vida Xp:

Figura No.2. Ciclo de vida de eXtreme Programming, Tomado de [1], [2] [1] y [3] nos describen cada una de las fases en las que se subdivide el ciclo de vida de eXtreme Programming: 2.1.13.1.- Fase de la 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. Se prueba la tecnologa y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y familiaridad que tengan los programadores con la tecnologa.

pg.

20

2.1.13.2.- Fase del planeamiento: se priorizan las historias de usuario y se acuerda el alcance del relase. Los programadores estiman cunto esfuerzo requiere cada historia y a partir de all se define el cronograma. La duracin del cronograma del primer relase no excede normalmente dos meses. La fase de planeamiento toma un par de das. Se deben incluir varias iteraciones para lograr un relase. El cronograma fijado en la etapa de planeamiento se realiza a un nmero de iteraciones, cada una toma de una a cuatro semanas en ejecucin. La primera iteracin crea un sistema con la arquitectura del sistema completo. Esto es alcanzado seleccionando las historias que harn cumplir la construccin de la estructura para el sistema completo. El cliente decide las historias que se seleccionarn para cada iteracin. Las pruebas funcionales creadas por el cliente se ejecutan al final de cada iteracin. Al final de la ltima iteracin el sistema est listo para produccin. 2.1.13.3.- Fase de produccin: requiere prueba y comprobacin extra del funcionamiento del sistema antes de que ste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden todava ser encontrados y debe tomarse la decisin de si se incluyen o no en el relase actual. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas. Las ideas y las sugerencias pospuestas se documentan para una puesta en prctica posterior por ejemplo en la fase de mantenimiento. Despus de que se realice el primer relase productivo para uso del cliente, el proyecto de Xp debe mantener el funcionamiento del sistema mientras que realiza nuevas iteraciones. 2.1.13.4.- Fase de mantenimiento: requiere de un mayor esfuerzo para satisfacer tambin las tareas del cliente. As, la velocidad del desarrollo puede desacelerar despus de que el sistema est en la produccin. La fase de mantenimiento puede requerir la incorporacin de nueva gente y cambiar la estructura del equipo.

2.1.13.5.- Fase de muerte: 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.

pg.

21

2.1.14.- Ciclo de planificacin Programacin Extrema (XP)

de

procesos

en

En distintas entradas en este sitio, hemos ido avanzando en la perspectiva de conjugar la teora con la prctica para elaborar un prototipo metodolgico suficientemente consolidado como para permitir la transmisin de nuestra experiencia, tan flexible como para poder adecuarse a los distintos requerimientos que demanda la compleja multisectorialidad convocada por los programas de proteccin social y enriquecerse a su vez de las redes que hubiere generado ese nuevo momento. En la entrada anterior (que aparece despus de sta en el blog...), anotamos -con apoyo de multimedia-, los que a nuestro juicio resultan ser los elementos centrales y motores de las transformaciones de las cuales somos arte y parte. Podemos apreciar que los tres componentes que all detallamos como esenciales al anlisis de media situacional y que en estricto rigor estn constantemente sometidos a dinmicas de cambio e interpenetracin en el desarrollo de procesos, son -debido a ello-, tan importantes como las interfaces que generan, resaltando la tendencia eventual determinada por el contexto, a la constitucin de reas con mayor densidad, que habran de ser objeto particular de estudio. La labor de transmisin de contenidos que caracteriza las Redes de Resonancia Cognitiva (RRC) que generamos en nuestra labor, hacen que todo el esquema de Interoperabilidad Dialgica (ID) que lo sustenta, pudiera ser concebido como un campo comunicacional, lo cual viene a reafirmar la definicin conceptual de media situacional que proponemos. Cada una de estas tres reas y las interfaces que generan al relacionarse a travs de la prctica de sus respectivos agentes, tiene una gran cantidad de antecedentes y proyecciones particulares, tanto en lo terico como en su implementacin, que deben irse desarrollando de acuerdo a las condiciones de un enfoque estocstico, en tanto forma adecuada de enfrentar las situaciones imprevistas y de articulacin de redes complejas. Incorporamos a continuacin un diagrama de Programacin Extrema (XP, por su sigla en ingls), considerado clsico en esta rama heterodoxa del desarrollo de sistemas. Anotemos que aunque lo esencial del mismo proviene de fuente citada, ha sido modificado por la reflexin sobre nuestra experiencia acumulada. Por otra parte, subrayemos que el esquema no pretende otra cosa que proponer un modelo de aproximacin a la relacin entre tiempos y productos, siendo en si una respuesta consciente al desarrollo realista de las relaciones que efectivamente se generan entre las necesidades y las respuestas. Finalmente, la sustitucin del concepto clsico de retroalimentacin, por el de resonancia (en RRC), constituye un aporte en ciernes, que

pg.

22

adeca nuestra comprensin a los nuevos momentos: aunque anuncia un tratamiento especfico, el trmino proveniente de la fsica de partculas, explica mejor la condicin necesaria para que se produzca la retroalimentacin, tal como hemos postulado, en mbito asociado, la conversacin entre las personas ha de preceder a la

interoperabilidad de los sistemas.

2.2.- Visin General del Proceso Unificado Racional (RUP)

2.2.1.- Introduccin
La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process El Proceso Unificado es un proceso de desarrollo de software: conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. RUP es un marco genrico que puede especializarse para una variedad de tipos de sistemas, diferentes reas de aplicacin, tipos de organizaciones, niveles de aptitud y diferentes tamaos de proyectos. RUP est dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental. El Ciclo de Vida del Proceso Unificado El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versin del sistema.

2.2.2.- Historia pg.

23

Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software compr una compaa sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los mtodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten.

2.2.3.- Fases e Hitos

Cada fase finaliza con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos, es decir un conjunto de modelos o documentos que han sido desarrollados hasta alcanzar un estado predefinido. Los hitos tienen muchos objetivos. El ms crtico es que los directores deben tomar ciertas decisiones antes de que el trabajo contine con la siguiente fase. Los hitos tambin permiten controlar la direccin y progreso del trabajo. Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumidos en cada fase. Estos datos son tiles para las estimaciones en futuros proyectos. Cada ciclo constas de cuatro fases: inicio, elaboracin, construccin, y transicin. Faces e Hitos de un Proyecto Hitos Inicio Elaboracin
Tiempo

Construccin

Transicin

2.2.3.1.- Fase de Inicio Durante la fase de inicio se desarrolla una descripcin del producto final, y se presenta el anlisis del negocio. El objetivo de esta fase es ayudar al equipo de proyecto a decidir cules son los verdaderos objetivos del proyecto. Las iteraciones exploran diferentes soluciones posibles, y diferentes arquitecturas posibles. Puede que todo el trabajo fsico realizado en esta fase sea descartado. Lo nico que normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el equipo. Los artefactos que tpicamente sobreviven a esta fase son: - Un enunciado de los mayores requerimientos planteados generalmente como casos de uso.

pg.

24

Un boceto inicial de la arquitectura. Una descripcin de los objetivos del proyecto. Una versin muy preliminar del plan del proyecto. Un modelo del negocio.

La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida. Este hito es alcanzado cuando el equipo de proyectos y los stakeholders llegan a un acuerdo sobre: Cul es el conjunto de necesidades del negocio, y que conjunto de funciones satisfacen estas necesidades. Una planificacin preliminar de iteraciones. Una arquitectura preliminar. 2.2.3.2.- Fase de Elaboracin Durante la fase de elaboracin se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura. Las iteraciones en la fase de elaboracin: Establecen una firme comprensin del problema a solucionar. Establece la fundacin arquitectural para el software. Establece un plan detallado para las siguientes iteraciones. Elimina los mayores riesgos.

El resultado de esta fase es la lnea base de la arquitectura. En esta fase se construyen tpicamente los siguientes artefactos: El cuerpo bsico del sw en la forma de un prototipo arquitectural. Casos de prueba La mayora de los casos de uso (80%) que describen la funcionalidad del sistema. Un plan detallado para las siguientes iteraciones. La fase de elaboracin finaliza con el hito de la Arquitectura del Ciclo de Vida. Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: Los casos de uso que describen la funcionalidad del sistema. La lnea base de la arquitectura Los mayores riesgos han sido mitigados El plan del proyecto

2.2.3.3.- Fase de Construccin Durante la fase de construccin se crea el producto. La lnea base de la arquitectura crece hasta convertirse en el sistema completo.

pg.

25

Al final de esta fase, el producto contiene todos los casos de uso implementados, sin embargo puede que no est libre de defectos. Los artefactos producidos durante esta fase son: El sistema software Los casos de prueba Los manuales de usuario

La fase de construccin finaliza con el hito de Capacidad Operativa Inicial. Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: El producto es estable para ser usado El producto provee alguna funcionalidad de valor Todas las partes estn listas para comenzar la transicin

2.2.3.4.- Fase de Transicin La fase de transicin cubre el perodo durante el cual el producto se convierte en la versin beta. Las iteraciones en esta fase continan agregando caractersticas al sw. Sin embargo las caractersticas se agregan a un sistema que el usuario se encuentra utilizando activamente. Los artefactos construidos en esta fase son los mismos que en la fase de construccin. El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior. La fase de transicin finaliza con el hito de Lanzamiento del Producto. Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: Se han alcanzado los objetivos fijados en la fase de Inicio. El usuario est satisfecho.

2.2.4.- Iteraciones y disciplinas

Cada fase se subdivide en iteraciones. En cada iteracin se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

pg.

26

2.2.5.- Disciplinas
Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un rea especfica dentro del proyecto total. Las ms importantes son: Requerimientos, Anlisis, Diseo, Codificacin, y Prueba. El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visin tradicional en cascada.

Alcances y objetivos

Arquitectu ra

Versin Beta

Versin Final

Inicio Fases

Elaboracin

Construccin

Transicin

Iteraciones

Iteracio n1

Iteracio n 2

Iteracio n

Iteracio n n

Requerimient os Anlisis y Diseo Codificaci Gestin n Pruebas Configuracin y Admin.

pg. 27 Entreg
as

Disciplinas

2.2.3.- Un proceso conducido por casos de Uso

2.2.3.1.- Int roduccin Veamos una visin general de cmo se desarrolla el trabajo a travs de todos los flujos en un proceso dirigido por casos de uso. Tomaremos como ejemplo una versin simplificada de un sistema para un Cajero Automtico (CA).

2.2.3.1.1.- El Modelo de Caso de Usos representa los requisitos funcionales La primera disciplina que se desarrolla dentro de cada iteracin es la de requerimientos (posiblemente luego de realizar un modelado del dominio o del negocio). El objetivo de esta fase es determinar los requerimientos del sistema. Los requerimientos funcionales son plasmados a travs de casos de uso en un Modelo de Casos de Uso. El modelo de casos de uso ayuda al cliente, a los usuarios, y a los desarrolladores a llegar a un acuerdo sobre cmo utilizar el sistema. Ej.: Modelo de Casos de Uso para el sistema Cajero Automtico (CA)

pg.

28

Para cada caso de uso debe especificarse sus caminos o secuencias de acciones posibles. Ej.: Secuencia de acciones para un camino del caso de uso Sacar Dinero (simplificada). El cliente del banco se identifica El cliente elige de que cuenta sacar dinero y especifica cantidad El sistema deduce la cantidad de la cuenta y entrega el dinero

Los casos de uso tambin se utilizan como contenedores para los requisitos no funcionales. 2.2.4.- Importancia de una arquitectura Se necesita una arquitectura para: Comprender el sistema Organizar el desarrollo Fomentar la reutilizacin Hacer evolucionar el sistema 2.2.4.1.- Desarrollo de la arquitectura La arquitectura se desarrolla mediante iteraciones, principalmente en la etapa de elaboracin. El resultado de la fase de elaboracin es la lnea base de la arquitectura un esqueleto del sistema con pocos msculos de software. Los casos de uso que son relevantes para la arquitectura son resumidamente aquellos que mitigan los mayores riesgos del proyecto, aquellos que son ms importantes para el usuario, y aquellos que nos ayudan a cubrir todas las funcionalidades significativas. 2.2.4.2.- Descripcin de la arquitectura

pg.

29

La lnea base de la arquitectura, es la versin interna del sistema al final de la fase de elaboracin. El conjunto de modelos que describen esta lnea base se denomina Descripcin de la Arquitectura. El papel de la descripcin de la arquitectura es guiar al equipo de desarrollo a travs del ciclo de vida del sistema. La descripcin de la arquitectura puede adoptar diferentes formas. Puede ser un extracto de los modelos que son parte de la lnea base de la arquitectura, o puede ser una reescritura de los extractos de forma que sea ms fcil leerlos. 2.2.5.- Un proceso iterativo e incremental 2.2.5.1.- Desarrollo en pequeos pasos La tercera clave importante del RUP consiste en desarrollar un producto software en pasos pequeos manejables: Planificar un poco. Especificar, disear, e implementar un poco. Integrar, probar, y ejecutar un poco en cada iteracin. Las iteraciones en las primeras fases tratan en su mayor parte con la determinacin del mbito del proyecto, la eliminacin de los riesgos crticos, y la creacin de la lnea base de la arquitectura. Despus, a medida que avanzamos a lo largo del proyecto y vamos reduciendo gradualmente los riesgos restantes e implementado los componentes, la forma de las iteraciones cambia, dando incrementos como resultado. 2.2.5.2.- Por qu un desarrollo iterativo e incremental? Para tomar las riendas de los riesgos crticos y significativos desde el principio. Para poner en marcha una arquitectura que gue el desarrollo del software. Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos. Para construir el sistema a lo largo del tiempo en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso. Para proporcionar un proceso de desarrollo a travs del cual el personal puede trabajar de manera ms eficaz. 2.2.5.3.- La iteracin genrica
Una iteracin es un mini proyecto, un recorrido ms o menos completo a lo largo de todos los flujos de trabajo fundamentales, que obtiene como resultado una versin interna del sistema.

2.2.6.- Conceptos clave

2.2.6.1.- Conceptos Claves

pg.

30

Proceso de Ingeniera de Software Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En ingeniera de software, el objetivo es construir un producto de software nuevo o extender uno existente. En RUP esto se organiza en un conjunto de Disciplinas que define un flujo de trabajo.

2.2.6.1.1.- Disciplina
Una disciplina es una coleccin de actividades relacionadas vinculadas con un rea especfica del proyecto. Este agrupamiento de actividades en disciplinas es principalmente para facilitar la comprensin del proyecto desde la perspectiva tradicional del modelo en cascada.

2.2.6.1.2.- Flujo de trabajo

Un flujo de trabajo describe la secuencia en que se realizan las actividades en una disciplina, quienes la realizan (trabajadores) y que artefactos producen.

2.2.6.1.3.- Trabajador (Rol)

Un trabajador o rol, define un comportamiento o responsabilidades de un individuo o grupo de individuos trabajando en equipo, en el contexto de una organizacin de ingeniera de software. Actividad Los trabajadores realizan actividades. Una actividad es algo que realiza un trabajador para proveer un resultado de valor en el contexto de un proyecto.

2.2.6.1.4.- Pasos (steps)

Las actividades son descompuestas en pasos. Podemos distinguir tres categoras de pasos: Pasos de anlisis: donde el trabajador comprende la naturaleza de la tarea, examina los artefactos de entrada, y formula las salidas. Pasos de accin: donde los trabajadores crean o actualizan algunos artefactos. Pasos de revisin: donde los trabajadores inspeccionan los resultados segn determinados criterios.

2.2.6.1.5.- Artefactos
Las actividades tienen artefactos de entrada y de salida. Un artefacto es un producto de trabajo en un proceso: los trabajadores utilizan artefactos para realizar actividades y producen artefactos como resultado de sus actividades. Los artefactos son responsabilidad de un nico trabajador y promueven la idea de que toda pieza de informacin en el proceso debe ser responsabilidad de un rol especfico.

2.2.7.- Requisitos, Anlisis, Diseo, Implementacin y Prueba del Proceso Unificado

2.2.7.1.- Requisitos 2.2.7.1.1.- Introduccin

pg.

31

El propsito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto. Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado. En otros casos si es un sistema acotado que no da soporte al negocio podemos partir de un modelo de objetos sencillo como un modelo del dominio. En otros casos el cliente puede ya haber desarrollado una especificacin completa de requisitos no basada en objetos, de la cual podemos partir. En forma tpica, el flujo de trabajo de requisitos incluye los siguientes pasos: Enumerar los requisitos candidatos. Comprender el contexto del sistema. Capturar requisitos funcionales. Capturar requisitos no funcionales. Enumerar los requisitos candidatos La lista de caractersticas deseadas del sistema constituyen los requisitos candidatos. De cada caracterstica se registra: Nombre corto Descripcin Estado (propuesto, aprobado, incluido, o validado) Coste estimado de implementacin (en trmino de tipos de recursos y horas-hombre) Prioridad (crtico, importante, o secundario) Nivel de riesgo asociado a la implementacin de la caracterstica (crtico, significativo, ordinario) Capturar requisitos funcionales Los requisitos funcionales son capturados por medio de casos de uso, que conforman el modelo de casos de uso. Los casos de uso tambin capturan requisitos no funcionales especficos de un caso de uso determinado. Capturar requisitos no funcionales Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementacin, rendimientos, etc. Hay requisitos no funcionales especficos para un caso de uso y otros genricos para la aplicacin. Los que son especficos para un caso de uso, pueden documentarse junto con el caso de uso correspondiente. Los que son ms genricos se documentan por medio de una lista de requisitos adicionales. 2.2.7.1.2.- Modelo del Dominio Un modelo del dominio captura los tipos ms importantes de objetos en el contexto del sistema. Los objetos del dominio representan las

pg.

32

cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Las clases del dominio aparecen en tres formas tpicas: Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas, contratos, etc.

Objetos del mundo real y conceptos de los que el sistema debe hacer seguimiento como aviacin enemiga, misiles, trayectorias, etc. Sucesos que ocurrirn o han ocurrido, como llegada de un avin, su salida, hora de la comida, etc. se representa fundamentalmente por

El modelo de dominio diagramas de clases en UML.

El objetivo del modelado del dominio es comprender y describir las clases ms importantes dentro del contexto del sistema. 2.2.7.1.3.- Modelo del Negocio El modelado del negocio es una tcnica para comprender los procesos de negocio de la organizacin. El modelado del negocio est soportado por dos tipos de modelos de UML: el modelado de casos de uso, y modelos de objetos. 2.2.7.1.4.- Bsqueda de Casos de Uso a partir de un modelo del negocio En primer lugar se identifica un actor por cada trabajador y por cada actor del negocio (es decir, el cliente). Cada trabajador y actor del negocio que vaya a ser usuario del sistema de informacin requerir un soporte por parte del mismo. El soporte necesario se determina tratando cada uno de los actores uno detrs de otro. 2.2.7.1.5.- Requisitos adicionales Los requisitos adicionales, son requerimientos No funcionales que no pueden asociarse a ningn caso de uso en particular. Algunos ejemplos son el rendimiento, las interfaces, y los requisitos de diseo fsico, as como las restricciones arquitectnicas. 2.2.7.1.6.- Captura de requisitos como casos de uso Los requisitos funcionales se estructuran de forma natural mediante casos de uso que constituyen el Modelo de Casos de Uso. 2.2.7.1.7.- Trabajadores y Artefactos

pg.

33

Trabajador Analista de sistemas

Responsable de (artefacto) Modelo de casos de uso Actores Glosario Caso de uso Prototipo de interfaz de usuario Descripcin de la (vista del modelo de casos de uso) arquitectura

Especificador de casos de uso Diseador de Interfaz de Usuario Arquitecto

Los requisitos no funcionales restantes, se modelan como dijimos en el documento de requisitos adicionales. 2.2.7.1.8.- Artefactos Los artefactos utilizados en la captura de requisitos por casos de uso son: Modelo de casos de uso Actor Caso de uso Descripcin de la arquitectura vista del modelo de casos de uso Glosario Prototipo de interfaz de usuario Artefacto: Modelo de casos de uso Un modelo de casos de uso es un modelo del sistema que contiene actores, casos de uso y sus relaciones.

Artefacto: actor

pg.

34

El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario. Cada uno de stos se representa mediante uno o ms actores. Los actores suelen corresponderse con trabajadores (o actores del negocio). Artefacto: Caso de Uso Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Para cada caso de uso debe detallarse su flujo de sucesos. El flujo de sucesos puede plasmarse en forma textual y describe como interacta el sistema con los actores cuando se lleva a cabo un caso de uso. Tambin pueden vincularse a un caso de uso requisitos no funcionales especficos del caso de uso. Artefacto: Descripcin de la arquitectura vista del modelo de casos de uso La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de casos de uso, que representa los casos de uso significativos para la arquitectura. Artefacto: glosario Podemos utilizar un glosario para definir trminos comunes importantes que los analistas utilizan para describir el sistema. Artefacto: prototipo de interfaz de usuario Los prototipos de interfaz de usuario nos ayudan a comprender y especificar las interacciones entre actores humanos y el sistema durante la captura de requisitos. 2.2.7.1.9.- Trabajadores Analizamos los trabajadores responsables de crear los artefactos mencionados. Trabajador: analista de sistemas Responsable de: modelo de casos de uso actores que contiene glosario

pg.

35

Trabajador: especificador de casos de uso Asisten al analista de sistema en la descripcin detallada de cada caso de uso. Responsable de: caso de uso

Trabajador: diseador de interfaz de usuario Responsable de: prototipo de interfaz de usuario

Trabajador: arquitecto Responsable de: descripcin de la arquitectura (vista del modelo de casos de uso

2.2.7.1.10.- Flujo de Trabajo

Actividad: encontrar actores y casos de uso Identificamos actores y casos de uso para: Delimitar el sistema de su entorno Esbozar quin y qu (actores) interactuarn con el sistema, y que funcionalidad (casos de uso) se espera del sistema Capturar y definir un glosario de trminos comunes esenciales para la creacin de descripciones detalladas de las funcionalidades del sistema.

pg.

36

Esta actividad consta de cuatro pasos: Encontrar los actores Encontrar los casos de uso Describir brevemente cada caso de uso Describir el modelo de casos de uso completo (este paso tambien incluye la preparacin de un glosario de trminos)

Estos pasos no tienen que ser ejecutados en un orden determinado, y a menudo se hacen simultneamente. Encontrar actores: Depende de nuestro punto de partida. Si partimos de un modelo del negocio, el analista puede asignar un actor a cada trabajador del negocio y un actor a cada actor del negocio (cliente) que utilizar informacin del sistema. En otro caso, con o sin un modelo del dominio, el analista del sistema junto con el cliente identifica los usuarios e intenta organizarlos en categoras representadas por actores. En ambos casos hay que identificar actores que representan sistemas externos y los actores de mantenimiento y operacin del sistema. Los actores modelan roles. Encontrar casos de uso: Cuando se parte de un modelo del negocio, se propone un caso de uso para cada rol de trabajador que utilizar informacin del sistema. El mtodo ms general es la identificacin a partir del anlisis de cada actor por separado. Actividad: priorizar casos de uso El propsito de esta actividad es priorizar cuales son los casos de uso ms importantes para abordar en las primeras iteraciones. Los resultados se recogen en la vista de la arquitectura del modelo de casos de uso. Esta vista revisada con el jefe de proyecto se utiliza como entrada al hacer la planificacin de lo que debe desarrollarse dentro de una iteracin. Actividad: detallar casos de uso El objetivo principal de detallar cada caso de uso es describir su flujo de sucesos en detalle, incluyendo como comienza, termina, e interactan con los actores. Para detallar los casos de uso se usan: Descripciones textuales Diagramas de transicin de estados para describir los estados de los casos de uso y las transiciones entre esos estados

pg.

37

Diagramas de actividad para describir transiciones entre estados con ms detalle como secuencias de acciones. Los diagramas de actividad pueden describirse como la generalizacin de los diagramas de transicin de estados Diagramas de interaccin para describir cmo interacta una instancia de caso de uso con la instancia de un actor. Los diagramas de interaccin muestran el caso de uso y el actor o actores participantes.

Para cada caso de uso debe detallarse: Estado inicial como precondicin Cmo y cuando comienza el caso de uso (primera accin a ejecutar) Orden en que deben ejecutarse las acciones (puede ser una secuencia numerada) Cmo y cuando terminan los casos de uso Posibles estados finales como pos condiciones Caminos de ejecucin que no estn permitidos Camino bsico Caminos alternativos Actividad: prototipar interfaz de usuario Comenzamos con los casos de uso e intentamos discernir que se necesita de las interfaces de usuario para habilitar los casos de uso para cada actor. Hacemos un diseo lgico de la interfaz de usuario, luego creamos un modelo fsico, y desarrollamos prototipos para ilustrar como pueden utilizar el sistema los usuarios para ejecutar los casos de uso. Actividad: estructurar el modelo de casos de uso Los casos de uso identificado son estructurados utilizando las relaciones de uso (secuencias comunes), extensiones (casos excepcionales), y generalizaciones.

2.2.7.2.- Anlisis Durante el anlisis, analizamos los requisitos que se describieron en la captura de requisitos, refinndolos y estructurndolos. El objetivo de hacerlo es conseguir una comprensin ms precisa de los requisitos y una descripcin de los mismos que sea fcil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.

pg.

38

2.2.7.2.1.- Artefactos Artefacto: Modelo del anlisis

Compuesto por un sistema de anlisis que es el paquete de ms alto nivel, el cual se compone a su vez de otros paquetes y clases de anlisis y realizaciones de casos de uso. Artefacto: clase del anlisis Una clase de anlisis representa una abstraccin de una o varias clases y/o subsistemas del diseo. Caractersticas: Se centra en el tratamiento de requisitos funcionales y pospone los no funcionales para el diseo. Es ms conceptual. Raramente define una interfaz en trminos de operaciones y sus signaturas. Su comportamiento se define mediante responsabilidades en un nivel ms alto y menos formal. Una responsabilidad es una descripcin textual de un conjunto cohesivo del comportamiento de una clase. Artefacto: realizacin caso de uso anlisis Una realizacin de caso de uso anlisis es una colaboracin dentro del modelo de anlisis que describe cmo se lleva a cabo y se ejecuta un caso de uso determinado en trminos de las clases del anlisis y sus objetos del anlisis en interaccin. Una realizacin de caso de uso anlisis posee una descripcin textual del flujo de sucesos, diagramas de clases participantes, y diagramas de interaccin que muestran la realizacin de un flujo o escenario particular del caso de uso en trmino de objetos del anlisis.

pg.

39

Artefacto: paquete del anlisis Los paquetes del anlisis proporcionan un medio para organizar los artefactos del modelo de anlisis en piezas manejables. Un paquete de anlisis puede constar de clases de anlisis, de realizaciones de casos de uso, y de otros paquetes del anlisis recursivamente. Paquete de servicio Un servicio representa un conjunto coherente de acciones relacionadas funcionalmente un paquete de funcionalidad- que se utiliza en varios casos de uso. Un cliente de un sistema normalmente compra una combinacin de servicios para ofrecer a sus usuarios los casos de uso necesario. Un servicio es indivisible en el sentido de que el sistema necesita ofrecerlo o todo entero o nada en absoluto. Los casos de uso atraviesan los servicios, es decir, un caso de uso requiere acciones de varios servicios. En RUP, el concepto de servicio est soportado por los paquetes de servicio. Los paquetes de servicio se utilizan en el nivel ms bajo de la jerarqua (de agregacin) de paquetes de anlisis para estructurar el sistema de acuerdo a los servicios que proporciona. Podemos observar lo siguiente acerca de los paquetes de servicio: Un paquete de servicios contiene un conjunto de clases relacionadas funcionalmente. Un paquete de servicios es indivisible. Para llevar a cabo un caso de uso puede que participen ms de un paquete de servicios. Un paquete de servicios puede depender de otro paquete de servicios. Un paquete de servicios normalmente es relevante para un pequeo grupo de actores. Un paquete de servicios puede gestionarse como una unidad de distribucin independiente. Puede representar una funcionalidad adicional del sistema. Los paquetes de servicio pueden ser mutuamente excluyentes, o pueden representar diferentes variantes del mismo servicio. Los paquetes de servicio constituyen la entrada fundamental para las actividades de diseo e implementacin subsiguientes, dado que ayudarn a estructurar los modelos de diseo e implementacin en trminos de subsistemas de servicio.

pg.

40

Artefacto: descripcin de la arquitectura (vista del modelo de anlisis) Los siguientes artefactos del modelo de anlisis se consideran significativos para la arquitectura: Descomposicin del modelo de anlisis en paquetes de anlisis y sus dependencias. Esta descomposicin suele tener su efecto en los subsistemas de las capas superiores durante el diseo e implementacin. Las clases fundamentales del anlisis. Realizaciones de casos de uso que describen funcionalidades importantes y crticas, probablemente las correspondientes a los casos de uso que aparecen en la vista de la arquitectura del modelo de casos de uso.

2.2.7.2.2.- Trabajadores Trabajador: Arquitecto Es responsable de la integridad del modelo de anlisis, garantizando que sea correcto, consistente, y legible como un todo. El arquitecto es responsable de: la descripcin de la arquitectura modelo del anlisis

Trabajador: Ingeniero de casos de uso Es responsable de la integridad de una o ms realizaciones de caso de uso, garantizando que cumplen los requisitos que recaen sobre ellos. El ing.de casos de uso es responsable de: realizacin de casos de uso anlisis

Trabajador: Ingeniero de componentes Define y mantiene las responsabilidades, atributos, relaciones, y requisitos especiales de una o varias clases del anlisis asegurndose de que cada clase del anlisis cumple los requisitos que se esperan de ella de acuerdo a las realizaciones de caso de uso en que participan. . El ingeniero de componentes es responsable de:

pg.

41

clase del anlisis paquete del anlisis

2.2.7.2.3.- Flujo de Trabajo

Actividad: anlisis de la arquitectura El propsito de anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de paquetes del anlisis, clases anlisis evidente, y requisitos especiales comunes. Identificacin de paquetes de anlisis Los paquetes proporcionan un medio para organizar el modelo de anlisis en piezas ms pequeas y manejables. Pueden identificarse inicialmente como forma de dividir el anlisis o encontrarse a medida que se avanza en el anlisis. Una identificacin inicial se hace de manera natural basndonos en los requisitos funcionales y en el dominio de problema, agrupando un cierto nmero de casos de uso en un paquete concreto, y realizando la funcionalidad correspondiente dentro de dicho paquete. Algunos criterios para agrupar casos de uso son: Casos de uso para dar soporte a un determinado proceso de negocio. Casos de uso para dar soporte a un determinado actor del sistema. Casos de uso relacionados mediante relaciones de generalizacin y de extensin.

pg.

42

Cuando dos paquetes necesitan compartir una misma clase, es conveniente ubicar dicha clase en su propio paquete.

Identificacin de paquetes de servicio La identificacin de paquetes de servicio se suele hacer cuando el trabajo de anlisis est avanzado, cuando se comprenden bien los requisitos funcionales, y existen la mayora de las clases del anlisis. Para identificar paquetes de servicio debemos: Identificar un paquete de servicio por cada servicio opcional. El paquete de servicio ser una unidad de compra. (por ej. enviar avisos a clientes) Identificar un paquete de servicio por cada servicio que podra hacerse opcional, incluso aunque todos los clientes siempre lo quieran.

Definicin de dependencias entre paquetes del anlisis Deben definirse dependencias entre los paquetes del anlisis si sus contenidos estn relacionados. La direccin de la dependencia debera ser la misma (navegabilidad) direccin de la relacin. Identificacin de clases de entidad obvias Pueden identificarse una lista de clases entidad candidatas basado en las clases del dominio o las entidades del negocio. Sin embargo la mayora de las clases se identificarn al crear las realizaciones de casos de uso. Por lo cual en esta etapa es conveniente con un esbozo inicial de las clases significativas para la arquitectura. Identificacin de requisitos especiales Un requisito especial es un requisito que aparece durante el anlisis y que es importante anotar de forma que pueda ser tratado adecuadamente en las subsiguientes actividades de diseo e implementacin. 2.2.7.3.- Diseo 2.2.7.3.1.- Introduccin Durante el diseo modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseo es el modelo de anlisis.

pg.

43

El diseo es el centro de atencin al final de la fase de elaboracin y comienzo de las iteraciones de construccin.

2.2.7.3.2.- Artefactos Artefacto: Modelo del Diseo El modelo de diseo es un modelo de objetos que describe la realizacin fsica de los casos de uso centrndose en los requisitos funcionales como en los no funcionales. Las abstracciones del modelo de diseo tienen una correspondencia directa con los elementos fsicos del ambiente de implementacin.

Artefacto: Clase del Diseo Una clase de diseo es una abstraccin sin costuras con una clase o construccin similar en la implementacin del sistema. Artefacto: realizacin de caso de uso-diseo Es una colaboracin en trmino de clases de diseo que describe como se realiza un caso de uso especfico. Una realizacin de caso de uso diseo, tiene una traza directa a la correspondiente realizacin del caso de uso anlisis. Una realizacin de caso de uso-diseo se describe utilizando: Diagramas de clases para mostrar los objetos participantes en la realizacin. Diagrama de interaccin, particularmente diagramas de secuencia, enfatizando en la secuencia de mensajes.

pg.

44

Flujos de sucesos-diseo, descripcin textual que explica y complementa los diagramas y sus etiquetas.

Artefacto: subsistema de diseo Los subsistemas de diseo son una forma de organizar los artefactos del modelo de diseo en piezas ms manejables. Un subsistema puede constar de clases de diseo, realizaciones de caso de uso, interfaces, y otros subsistemas. Un subsistema puede proporcionar interfaces que representan la funcionalidad que exportan en trmino de operaciones. Los subsistemas pueden representar separacin de un sistema grande en subsistemas que pueden desarrollarse por equipos separados. Las dos capas de aplicacin de nivel ms alto suelen tener trazas directas hacia paquetes y/o clases del anlisis. Los subsistemas pueden representar productos software reutilizados. Los subsistemas encapsulndolos. pueden representar sistemas heredados

Subsistemas de Servicio: Los subsistemas de servicio diseo se usan en un nivel inferior de la jerarqua de subsistemas. La identificacin de subsistemas de servicio se basa en los paquetes de servicio del modelo de anlisis, y normalmente existe una traza uno a uno. Un subsistema de servicio ofrece servicios en trmino de interfaces y operaciones. Un subsistema de servicio suele ejecutable en la implementacin. Artefacto: interfaz Las interfaces se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas del diseo. Se dice que una clase de diseo o un subsistema de diseo realizan o implementan una interfaz. Las interfaces constituyen una forma de separar la especificacin de la funcionalidad en trminos de operaciones de sus implementaciones en trminos de mtodos. Artefacto: descripcin de la arquitectura (vista del modelo de diseo) Se consideran significativos para la arquitectura los siguientes artefactos del modelo de diseo: La descomposicin del modelo de diseo en subsistemas, sus interfaces, y las dependencias entre ellos. Clases de diseo fundamentales como clases activas y clases centrales. Realizaciones de caso de uso-diseo que describan alguna funcionalidad importante y crtica. dar lugar a un componente

pg.

45

Artefacto: modelo de despliegue El modelo de despliegue es un modelo de objetos que describe la distribucin fsica del sistema en trminos de cmo se distribuye la funcionalidad entre los nodos de cmputo. Artefacto: descripcin de la arquitectura (vista del modelo de despliegue) La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de despliegue que muestra sus artefactos relevantes para la arquitectura. 2.2.7.3.3.- Trabajadores Trabajador: arquitecto Responsable del modelo de descripcin de la arquitectura. diseo, modelo de despliegue, y

Trabajador: ingeniero de casos de uso Responsable de la realizacin de caso de uso diseo. Trabajador: ingeniero de componentes Responsable de Clases de diseo, subsistema de diseo, interfaz. 2.2.7.3.4.- Flujo de Trabajo

pg.

46

Actividad: diseo de la arquitectura El objetivo del diseo de la arquitectura es esbozar los modelos de diseo y despliegue identificando: Nodos y configuraciones de red. Subsistemas e interfaces Clases de diseo significativas para la arquitectura como las clases activas (procesos). Mecanismos de diseo genricos que tratan requisitos comunes.

Nodos y configuraciones de red Entre los aspectos de configuraciones de red podemos resaltar: Qu nodos se necesitan, que capacidad deben tener? Qu tipo de conexiones debe haber entre los nodos, que protocolos de comunicaciones? Qu caractersticas deben tener los nodos, ancho de banda, disponibilidad, calidad, etc.? procesos redundantes, capacidad de fallos, etc.?

Identificacin de subsistemas y de sus interfaces Los subsistemas constituyen un medio para organizar el modelo de diseo en piezas manejables. Pueden identificarse inicialmente como forma de dividir el trabajo de diseo, o bien pueden irse encontrando a medida que el modelo de dselo evoluciona. Subsistemas de aplicacin: Son las capas superiores de la aplicacin y pueden derivarse directamente de los paquetes de anlisis. Se distingue capa especfica y general de la aplicacin. Subsistemas intermedios y de software del sistema: Constituyen los cimientos de un sistema. Son sistemas operativos, SGBD, software de comunicaciones, tecnologas de distribucin de objetos, kits de construccin de GUIs, gestores de transacciones, etc. Actividad: diseo de un caso de uso Los objetivos del diseo de un caso de uso son: Identificar clases y/o subsistemas necesarios para llevar a cabo el caso de uso Distribuir el comportamiento del caso de uso entre los objetos del diseo que interactan y/o entre los subsistemas participantes. Definir los requisitos sobre las operaciones de las clases del diseo y/o sobre los subsistemas y sus interfaces. Capturar los requisitos de implementacin del caso de uso.

pg.

47

Actividad: diseo de una clase Para una clase implica definir: sus operaciones. sus atributos. sus relaciones. sus mtodos (que realizan sus operaciones). su ciclo de vida (mquina de estados). sus dependencias con cualquier mecanismo de diseo genrico. los requisitos relevantes a su implementacin. la correcta realizacin de cualquier interfaz requerida. Esbozar la clase del diseo: Disear clase interfaz: depende de la tecnologa especfica que se use (VB, Java, etc.) Disear clases entidad: aspectos de persistencia, a menudo implica uso de tecnologas BD. Disear clases de control: encapsulan secuencias, coordinacin de otros objetos, y a veces lgica del negocio. Se deben tener en cuenta: aspectos de distribucin en nodos de red, aspectos de rendimiento, aspectos de transaccin.

Identificar Operaciones: Identificamos las operaciones y las describimos utilizando el lenguaje de programacin que se usar. Entradas importantes son: Responsabilidades de las clases de anlisis que tienen traza con la clase de diseo Requisitos especiales de la clase de anlisis que tienen traza Interfaces que la clase de diseo necesita proporcionar Realizaciones de caso de uso diseo en las que la clase participa Identificar Atributos: Identificamos atributos requeridos por la clase y los describimos utilizando el lenguaje de programacin que se usar. Identificar Asociaciones y agregaciones: Los ingenieros de componentes estudian la transmisin de mensajes en los diagramas de secuencia para determinar que asociaciones son necesarias. Aspectos a tener en cuenta: Asociaciones y agregaciones en las clases de anlisis correspondientes Los nombres de roles de asociacin pueden llegar a ser atributos de la clase de diseo que referencia a la otra clase. Una asociacin de clases puede llegar a ser una nueva clase.

pg.

48

Se debe considerar la navegabilidad (direccin de los mensajes).

Identificar generalizaciones: Las generalizaciones deben implementarse utilizando herencia si el lenguaje lo permite. Si el lenguaje no lo admite debe utilizarse asociacin/agregacin para proporcionar la delegacin desde los objetos de clases ms especficas a objetos de clases ms generales.

Describir los mtodos: Pueden describirse los algoritmos de los mtodos utilizando lenguaje natural, pseudocdigo, o el lenguaje de programacin especfico. Sin embargo esto suele diferirse hasta la implementacin de la clase. Describir estados: Se utilizan diagramas de estado para describir los estados de los objetos estados dependientes. Actividad: diseo de un subsistema Los objetivos del diseo de un subsistema son: Garantizar que el subsistema es lo ms independiente de los otros subsistemas. Garantizar que el subsistema proporciona las interfaces correctas. Garantizar que el subsistema cumple su propsito de ofrecer una realizacin correcta de las operaciones que se definen en las interfaces. 2.2.7.4.- Implementacin 2.2.7.4.1.- Introduccin En la implementacin empezamos con el resultado del diseo e implementamos el sistema en trmino de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binario, ejecutables, y similares. La implementacin es el centro durante las iteraciones de construccin, aunque tambin se lleva a cabo trabajo de implementacin durante la fase de elaboracin, para crear la lnea base ejecutable de la arquitectura, y durante la fase de transicin para tratar defectos tardos.

pg.

49

2.2.7.4.2.- Trabajadores y Artefactos Trabajador Arquitecto Responsable de (artefacto) Modelo de implementacin Modelo de despliegue Descripcin de la arquitectura Integracin de sistema Componente Implementacin de subsistema Interfaz

Integrador de sistema Ingeniero de Componentes

2.2.7.4.3.- Artefactos Artefacto: Modelo de Implementacin El modelo de diseo es un modelo de objetos que describe la realizacin fsica de los elementos del modelo de diseo.

Artefacto: componente Un componente es el empaquetamiento fsico de los elementos de un modelo, como son las clases en el modelo de diseo. Stubs Un Stub es un componente con una implementacin esqueltica o de propsito especial que puede ser utilizado para desarrollar o probar otro componente que depende del stub. Artefacto: subsistema de implementacin Los subsistemas de implementacin proporcionan una forma de organizar los artefactos del modelo de implementacin en trozos ms manejables. Los subsistemas de implementacin estn muy relacionados con los subsistemas de diseo con los cuales tienen una traza uno a uno (isomrfica).

pg.

50

Artefacto: interfaz En el modelo de implementacin las interfaces pueden ser utilizadas para especificar las operaciones implementadas por componentes y subsistemas de implementacin. Artefacto: descripcin de la arquitectura La descripcin de la arquitectura tiene la visin de la arquitectura del modelo de implementacin. Los siguientes artefactos son considerados arquitectnicamente significativos: Descomposicin del modelo de implementacin en subsistemas, sus interfaces, y dependencias entre ellos. Componentes clave que siguen la traza de las clases de diseo significativas arquitectnicamente.

Artefacto: plan de integracin El sistema se desarrolla incrementalmente a pasos manejables. Cada paso de construccin debe ser sometido a pruebas de integracin. Para prepararse ante el fallo de una construccin se lleva un control de versiones para poder volver atrs a una construccin anterior. Un plan de integracin de construcciones describe la secuencia de construcciones necesarias en una iteracin. Un plan de este tipo describe lo siguiente para cada construccin: La funcionalidad que se espera sea implementada en dicha construccin, consiste en una lista de casos de uso a implementar.

pg.

51

Las partes del modelo de implementacin que estn afectadas por la construccin (lista de subsistemas y componentes necesarios para implementar la funcionalidad).

2.2.7.4.4.- Trabajadores Trabajador: arquitecto Durante la fase de implementacin, el arquitecto es responsable de la integridad del modelo de implementacin y asegura que el modelo como un todo es correcto, completo, y legible. El arquitecto es responsable del modelo de implementacin, el modelo de despliegue, y la descripcin de la arquitectura. Trabajador: ingeniero de componentes Define y mantiene el cdigo fuente de uno o varios componentes, garantizando que el componente implementa la funcionalidad correcta. A menudo tambin mantiene la integridad de uno o varios subsistemas de implementacin. Trabajador: integrador de sistemas Es responsable del plan de integracin de construcciones.

Actividad: implementacin de la arquitectura

pg.

52

El propsito de la implementacin de la arquitectura es esbozar el modelo de implementacin y su arquitectura mediante: Identificacin de componentes significativos arquitectnicamente tales como componentes ejecutables. La asignacin de componentes a los nodos en las configuraciones de redes relevantes.

Para esto consideramos las clases activas encontradas durante el diseo y asignamos un componente ejecutable a cada clase activa. Actividad: integrar el sistema Los objetivos de la integracin son: Crear un plan de integracin de construcciones Integrar cada construccin antes de que sea sometida a pruebas de integracin. Actividad: implementar un subsistema El propsito de implementar un subsistema es el de asegurar que un subsistema cumpla su papel en cada construccin. Actividad: implementar una clase El propsito de implementar una clase es implementar una clase de diseo en un componente fichero. Esto incluye: Esbozo de un componente fichero que contendr el cdigo. Generacin del cdigo fuente a partir de la clase de diseo y de las relaciones en que participa. Implementacin de las operaciones de la clase de diseo en forma de mtodos. Comprobacin de que el componente proporciona las mismas interfaces que la clase de diseo. Actividad: realizar prueba de unidad El propsito de realizar la prueba de unidad es probar los componentes implementados como unidades individuales. Existen dos tipos de prueba: Prueba de especificacin, o prueba de caja negra, que verifica el comportamiento de la unidad observable externamente. Prueba de estructura o prueba de caja blanca, que verifica la implementacin interna de la unidad. 2.2.7.5.- Prueba

pg.

53

2.2.7.5.1.- Introduccin Los objetivos de la prueba son: Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de integracin y las pruebas de sistema. Disear e implementar pruebas creando los casos de prueba (especifican qu probar), procedimientos de prueba (especifican cmo realizar las pruebas), creando componentes de prueba para automatizar las pruebas. Realizar las pruebas.

2.2.7.5.2.- Trabajadores y Artefactos Trabajador Diseador de Pruebas Responsable de (artefacto) Modelo de pruebas Casos de Prueba Procedimientos de prueba Evaluacin de pruebas Plan de pruebas Componente de pruebas

Ingeniero de Componentes

Ingeniero de Pruebas deDefecto Ingeniero de Pruebas de Sistema Defecto 2.2.7.5.3.- Artefactos Artefacto: Modelo de pruebas Describe como se prueban los componentes en el modelo de implementacin. El modelo de pruebas es una coleccin de casos de prueba, procedimientos de prueba, y componentes de prueba. Artefacto: Caso de prueba Un caso de prueba especfica una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse. Artefacto: Procedimiento de prueba

pg.

54

Un procedimiento de prueba especif ica cmo realizar uno o varios casos de prueba o partes de estos. Artefacto: Componente de prueba Un componente de prueba automatiza uno o varios procedimientos de prueba o partes de ellos. Artefacto: Plan de prueba El plan de prueba describe las estrategias, recursos y planificacin de la prueba. La estrategia incluye definicin de tipo de pruebas a realizar por iteracin, sus objetivos, nivel de cobertura y cdigo necesario.

Artefacto: Defecto Un defecto es una anomala del sistema. Un defecto puede ser utilizado para localizar cualquier cosa que los desarrolladores necesitan registrar como sntoma de un problema. Artefacto: Evaluacin de prueba Una evaluacin de prueba es una evaluacin de los resultados de la prueba. 2.2.7.5.4.- Trabajadores Trabajador: diseador de pruebas Un diseador de pruebas es responsable de la integridad del modelo de pruebas, asegurando que el modelo cumple con su propsito. Planean las pruebas. Seleccionan y describen los casos de prueba y procedimientos de prueba. Trabajador: ingeniero de componentes Son responsables de los componentes de prueba que automatizan algunos de los procedimientos de prueba. Trabajador: ingeniero de pruebas de integracin Son los responsables de realizar las pruebas de integracin que se necesitan para cada construccin producida en el flujo de implementacin. Documentan los defectos que aparecen como resultados de las pruebas de integracin.

pg.

55

Trabajador: ingeniero de pruebas de sistema Un ingeniero de pruebas de sistema es responsable de realizar las pruebas de sistema necesarias sobre una construccin que muestra el resultado de una iteracin completa. Las pruebas de sistema se llevan a cabo para verificar interacciones entre los actores y el sistema.

2.2.7.5.5.- Flujo de trabajo

pg.

56

Actividad: planificar prueba Describir una estrategia de la prueba Estimar requisitos para la prueba, recursos humanos y sistemas necesarios Planificar esfuerzo de la prueba Actividad: disear la prueba Identificar y describir los casos de prueba para cada construccin Identificar y estructurar los procedimientos de prueba especificando como realizar los casos de prueba.

Actividad: implementar la prueba Automatizar los procedimientos de componentes de prueba si esto es posible. prueba creando

Actividad: realizar pruebas de integracin Realizar las pruebas de integracin relevantes ejecutando los procedimientos o componentes de prueba correspondientes. Comparar los resultados de las pruebas con los resultados esperados e investigar resultados no esperados. Informar defectos a los ingenieros de componentes responsables de los componentes que registran fallas. Informar los defectos a los diseadores de pruebas, quienes usarn los defectos para evaluar los resultados de las pruebas.

Actividad: realizar prueba del sistema Una vez finalizadas las pruebas de integracin se realizan las pruebas de sistema de forma similar. Actividad: evaluar la prueba Se comparan resultados de la prueba con resultados esperados. Para esto se utilizan mtricas: Complecin de la prueba: indica el porcentaje de casos de prueba que han sido ejecutados y el porcentaje de cdigo que ha sido probado. Fiabilidad: Se basa en el anlisis de las tendencias den los defectos detectados y en las tendencias en las pruebas que se ejecutan con el resultado esperado.

pg.

57

*Revista de Estudios Politcnicos Polytechnical Studies Review 2008, Vol. VI, n 9 -ISSN: 1645-9911 Modelo de investigacin, aplicado en el desarrollo de software. Caso de estudio en instituciones pblicas de educacin superior, Saltillo, Coahuila Mxico *Metodologas De Desarrollo De Software - Mara A. Mendoza Snchez Ing. Informtico UNT Microsoft Certified Professional MCP Analista y Desarrolladora TeamSoft Per S.A.C.junio del 2004 *Metodologas giles en el Desarrollo de Software - Jos H. Cans, Patricio Letelier y M Carmen Penads - DSIC -Universidad Politcnica de Valencia Camino de Vera s/n, 46022 Valencia *Metodologa para el Desarrollo de Software Educativo (DESED)- S. Gustavo Pelez Camarena - UPIICSA XIV, VI, 41-42 *Metodologa para el Desarrollo de Software - Dr. Jos Ignacio Pelez Snchez E.T.S.I. Informtica de Sistemas. 3erCurso. Ao 2004/2005 *Diseo de una Metodologa gil de Desarrollo de Software. Schenone Marcelo Hernn. Tesis de Grado en Ingeniera en Informtica. Facultad de Ingeniera. Universidad de Buenos Aires. 2004 *El Proceso Unificado de Desarrollo de Software - Diseo de Sistemas - A.U.S. Gustavo Torossi

pg.

58