Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Unidad de Trabajo n1: Visin general del desarrollo del software y primeros pasos en la programacin usando IDEs (Semana 1) SEMANA 1: Primeros pasos en la programacin usando IDEs SEMANA 2: Introduccin al desarrollo del Software

Contenido
Esquema del documento .............................................................................................................. 3 Introduccin al desarrollo del software ........................................................................................ 3 Programacin Spaguetti ............................................................................................................ 3 Desventajas de la programacin spaguetti ............................................................................... 3 La crisis del software ................................................................................................................. 4 Ingeniera del software ............................................................................................................. 4 Qu es el ciclo de vida de software? ....................................................................................... 4 Funciones principales de un ciclo de vida del software ............................................................ 4 Ventajas de seguir un ciclo de vida del software ...................................................................... 5 Quines intervienen en el ciclo de vida del software?............................................................ 5 Estudio de los diferentes ciclos de vida. ....................................................................................... 5 Modelo en Cascada ................................................................................................................... 6 Modelo Incremental.................................................................................................................. 6 Modelo en Espiral ..................................................................................................................... 7 Modelos de Sistemas Orientados a Objetos (OO)..................................................................... 9 Primeros pasos en la orientacin a objetos ................................................................................ 10 Clases, objetos, atributos y comportamientos ....................................................................... 10 Qu es UML? ......................................................................................................................... 11 Diagrama de clases.................................................................................................................. 12 Diagrama de casos de uso ....................................................................................................... 13 Diagrama de estados ............................................................................................................... 15 Diagrama de Actividades ......................................................................................................... 15 Otras caractersticas de UML .................................................................................................. 18 Paquetes .............................................................................................................................. 18 Notas ................................................................................................................................... 18 RUP (Rational Unified Process) .................................................................................................. 19 1

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Metodologas .............................................................................................................................. 22 Metodologas vs Ciclos de Vida ............................................................................................... 22 Clasificacin de las metodologas............................................................................................ 22 Metodologas tradicionales vs recientes................................................................................. 22 Bibliografa .................................................................................................................................. 23

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Esquema del documento

En este documento veremos una introduccin al desarrollo del software siguiendo la siguiente estructura: Introduccin al desarrollo del software Estudio de los diferentes ciclos de vida. Primeros pasos en la orientacin a objetos. RUP como caso particular de ciclo de vida orientado a objeto

Introduccin al desarrollo del software

Programacin Spaguetti
Tradicionalmente el desarrollo de aplicaciones informticas se llevaba a cabo de forma individualizada, a base de codificar (generar lneas de cdigo) y probar lo realizado cuanto antes. La misma persona escriba el cdigo, lo ejecutaba y, si fallaba, lo depuraba. El proceso se realizaba sin ninguna planificacin previa y sin que soliese existir documentacin alguna. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estara all cuando se produjese algn fallo. En principio, el hecho de que desde un primer momento se vaya generando cdigo, podra considerarse como un sntoma de enorme progreso, pero puede suponer posteriormente un gran retroceso e incluso la necesidad de desechar una gran parte de lo realizado en el caso de que existan errores y no se puedan llevar a cabo las modificaciones necesarias para subsanarlos (por ejemplo, si al 90% del cdigo se descubre que el diseo de la base de datos es incorrecto, puede suponer desechar el trabajo y tener que comenzar de nuevo). Con este enfoque, cualquier cosa que no sea codificacin pura y dura no se realiza (como, por ejemplo, actividades de planificacin, de documentacin, de aseguramiento de la calidad). Esta forma de desarrollar software, tambin llamada en argot programacin spaguetti puede ser eficaz en programas pequeos. Para otro tipo de proyectos, puede resultar peligrosa su utilizacin, ya que no se puede conocer el progreso del proyecto, ni tampoco su calidad, simplemente se est codificando y probando hasta que finaliza el proyecto. Otras maneras de realizar el desarrollo software, como se vern en los siguientes apartados, permitirn, por ejemplo, conocer el progreso, detectar un error lo antes posible, etc.

Desventajas de la programacin spaguetti

Las principales desventajas de este enfoque de codificar y probar es que la aplicaciones as desarrolladas: Sean poco flexibles, y ante posibles modificaciones (por cambios en los requerimientos del cliente, cambios en el hardware, etc.) se incremente el coste de los proyectos e, incluso, en ocasiones, resulten virtualmente irrealizables debido a la naturaleza personalizada de los programas y a la falta de documentacin (lo que provocar problemas de mantenimiento).

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Sean incompletas o no reflejen bien las necesidades del cliente, es decir, que no realicen todas las funciones requeridas y, adems, lo hagan con una escasa fiabilidad. Provoquen el descontento de los clientes, pues se producen retrasos en la entrega (no se conoce el momento exacto en el que se entregarn), aparecen una vez que la aplicacin ha sido entregada (lgico al no haberse realizado de forma sistemtica actividades de verificacin y validacin en el proyecto).

La crisis del software

La llamada crisis del software ocurri cuando se percibi que se gastaba ms tiempo en hacer las modificaciones a los programas que en volver a crear el software. La razn era que ya se haban codificado millones de lneas de cdigo antes de que se definiera un buen mtodo para crear los programas.

Ingeniera del software

La solucin a esta crisis del software ha sido la definicin de la ingeniera del software como un oficio que requera un mtodo de trabajo similar al del resto de ingenieras. La bsqueda de una metodologa de trabajo que elimine esta crisis parece que an no est resuelta, de hecho los mtodos de trabajo siguen redefinindose una y otra vez.

Qu es el ciclo de vida de software?

El ciclo de vida software es la descripcin de las distintas formas de desarrollo de un proyecto o aplicacin informtica, es decir, la orientacin que debe seguirse para obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. Tambin puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software.

Funciones principales de un ciclo de vida del software

Las funciones principales de un ciclo de vida software son: Determinar el orden de las fases y procesos involucrados en el desarrollo del software y su evolucin (teniendo en cuenta el modelo de procesos que se utilice como referencia). Establecer los criterios de transicin para pasar de una fase a la siguiente (productos intermedios). Todo ello, incluye los criterios para la terminacin de la fase actual y los criterios para seleccionar e iniciar la fase siguiente.

El ciclo de vida software da respuesta a las siguientes preguntas de la gestin de un proyecto de software: Qu har a continuacin? Cunto tiempo continuar hacindolo?

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Ventajas de seguir un ciclo de vida del software

Algunas de las ventajas que aporta el enfoque de ciclo de vida residen en lo siguiente: En las primeras fases, aunque no haya lneas de cdigo, pensar el diseo es avanzar en la construccin del sistema, pues posteriormente resulta ms fcil la codificacin. Asegura un desarrollo progresivo, con controles sistemticos, que permite detectar precozmente los defectos. Se controla el sobrepasar los plazos de entrega y los costes excesivos, mediante un adecuado seguimiento del progreso. La documentacin se realiza de manera formal y estandarizada simultneamente al desarrollo, lo que facilita la comunicacin interna entre el equipo de desarrollo y la de ste con el cliente y los usuarios. Tambin aumenta la visibilidad y la posibilidad de control para la gestin del proyecto. Supone una gua para el personal de desarrollo, marcando las tareas a realizar en cada momento. Minimiza la necesidad de rehacer trabajo y los problemas de puesta a punto.

Quines intervienen en el ciclo de vida del software?

En el ciclo de vida del desarrollo del software intervienen: Cliente: es quin encarga la aplicacin y proporciona mediante entrevistas y diversa documentacin informacin acerca del dominio de la aplicacin a desarrollar. Usuarios: son los que realmente van a usar la aplicacin a desarrollar. Analista: Es el que realiza el anlisis y el diseo de una aplicacin. Utilizando el smil de la construccin el analista es a la informtica lo que el arquitecto a la construccin. Desarrolladores: Realizan la programacin de la aplicacin. Utilizando el smil de la construccin los desarrolladores seran los que realizan la obra realmente: capataces, obreros, etc

Estudio de los diferentes ciclos de vida.

A continuacin veremos los ciclos de vida ms usuales: Modelos tradicionales: o Modelo en cascada o Modelo incremental o Modelo en espiral Modelos para sistemas orientados a objeto.

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Modelo en Cascada
El modelo en cascada es el ms antiguo. El nmero de fases o etapas que se proponen en este
ciclo suele variar, aunque suelen ser:

Algunas caractersticas de este ciclo son: Cada fase empieza cuando se ha terminado la fase anterior. Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa. Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.

Algunas de las crticas del modelo en cascada son: No refleja el proceso real de desarrollo de software. Los proyectos reales raramente siguen este flujo secuencial, puesto que siempre hay iteraciones. Aunque en este modelo la iteracin est permitida en etapas contiguas en la vida real normalmente la iteracin abarca ms de una etapa. Un caso tpico es la redefinicin de los requisitos cuando se est codificando la aplicacin. Se tarda mucho tiempo en pasar por todo el ciclo, dado que hasta que no se finalice una fase no se pasa a la siguiente. As, se podra dar el caso de no salir nunca de la fase de anlisis de requisitos software. Acenta el fracaso de la industria del software con el usuario final. En este caso, el usuario debe tener paciencia, ya que el sistema en funcionamiento no estar disponible hasta las fases finales del proyecto.

Modelo Incremental
El modelo incremental corrige la necesidad de una secuencia no lineal de pasos de desarrollo. En el modelo incremental se va creando el sistema software aadiendo componentes funcionales al sistema (llamados incrementos). En cada paso sucesivo, se actualiza el sistema con nuevas funcionalidades o requisitos, es decir, cada versin o refinamiento parte de una versin previa y le aade nuevas funciones. El sistema software ya no se ve como una nica entidad monoltica con una fecha fija de entrega, sino como una integracin de resultados sucesivos obtenidos despus de cada iteracin. 6

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

El modelo incremental se ajusta a entornos de alta incertidumbre, por no tener la necesidad de poseer un conjunto exhaustivo de requisitos, especificaciones, diseos, etc., al comenzar el sistema, ya que cada refinamiento ampla los requisitos y las especificaciones derivadas de la fase anterior.

Algunas Crticas al modelo incremental son las siguientes: 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.

Modelo en Espiral
El modelo en espiral consta de una serie de ciclos. Cada uno empieza identificando los objetivos, las alternativas y las restricciones del ciclo. Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado empezar a plantear el prximo.

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Otro grfico que muestra el modelo en espiral es el siguiente:

Algunas caractersticas del mdelo en espiral son: 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. El modelo en espiral puede aplicarse en la mayora de las ocasiones. Sin embargo, en algunos casos hay que resolver ciertas dificultades: 8

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Trabajo con software contratado. El modelo en espiral trabaja bien en los

desarrollos internos, pero necesita un ajuste posterior para adaptarlo a la subcontratacin de software. En el desarrollo interno existe una gran flexibilidad y libertad para ajustarse a los acuerdos etapa por etapa, para aplazar acuerdos de opciones especficas, para establecer miniespirales con objeto de resolver caminos crticos, para ajustar niveles de esfuerzo, o para acomodar prctica como prototipado, desarrollo evolutivo, o uso de mtodos de diseo ajustado al coste. En el desarrollo de software bajo contrato no existe esta flexibilidad y libertad, por lo que es necesario mucho tiempo para definir los contratos, ya que los entregables no estarn previamente definidos de forma clara. Necesidad de expertos en evaluacin de riesgos: para identificar y manejar las fuentes de riesgos de un proyecto. Normalmente, un equipo sin experiencia puede producir una especificacin con una gran elaboracin de los elementos de bajo riesgo bien comprendidos, y una pequea y pobre elaboracin de los elementos de alto riesgo. A no ser que se realice una inspeccin por expertos, en este tipo de proyecto se tendr la ilusin de progresar durante un perodo, y, sin embargo, se encuentra dirigido directamente hacia el desastre. Otro aspecto a tener en cuenta es que una especificacin dirigida por riesgos es tambin dependiente del personal. Por ejemplo, un diseo producido por un experto puede ser implantado por inexpertos. Sin embargo, lo contrario es muy difcil llevarlo a cabo.

Modelos de Sistemas Orientados a Objetos (OO)

En los modelos orientados a objetos se dan las siguientes circunstancias: Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto. Aparece una nueva forma de concebir los lenguajes de programacin y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables. Hay un alto grado de iteracin y solapamiento, lo que lleva a una forma de trabajo muy dinmica.

En general, todos los expertos en tecnologa de objetos proponen seguir un desarrollo iterativo e incremental. Es iterativo porque las tareas de cada fase se llevan a cabo de forma iterativa haciendo evolucionar el sistema. Es incremental porque el sistema se divide en partes cada una de las cuales se desarrolla de forma completa, creando un pool (piscina en espaol) de componentes reutilizables. Ms adelante vamos a ver el modelo de ciclo de vida orientado a objeto de RUP (Rational Unified Process) como caso particular de ciclo de vida OO. Este ciclo de vida (RUP) no es el nico pensado para la orientacin de objetos. Pero si resulta uno de los primeros con xito puesto que surge de los tres amigos, que son Grady Booch, James Rumbaugh e Ivar Jacobson, que despus de trabajar en diferentes empresas y realizar trabajos por separado sobre la orientacin a objetos con mucho xito, son contratados por la empresa Rational Software Corporation en 1994 que les permite desarrollar en conjunto UML y RUP.

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Primeros pasos en la orientacin a objetos

Aqu se ir explicando la orientacin a objeto introduciendo los conceptos y la notacin UML a la vez, de forma prctica y evitando los formalismos. En esta semana vemos solamente una introduccin. En las prximas semanas veremos con detalle los nueve tipos de diagramas UML. Ahora mismo slo vamos a ver dos tipos de diagrama. Empecemos

Clases, objetos, atributos y comportamientos

Cuando se escribe un programa en un lenguaje orientado a objetos, definimos una plantilla o clase que describe las caractersticas y el comportamiento de un conjunto de objetos similares. La clase Lavadora describe las caractersticas comunes de todas las lavadoras: sus atributos y su comportamiento. Los atributos o propiedades se refieren a la marca o fabricante, el modelo, el nmero de serie, la capacidad, el color, las dimensiones, etc. El comportamiento se refiere a la posibilidad de agregar ropa, agregar detergente, activarse, sacar la ropa, etc.

Luego, tenemos lavadoras concretas (objetos), por ejemplo Mi lavadora es blanca, de marca otsein, con nmero de serie 123-ARS-3, y de 75x120cm, etc. Una clase es por tanto una pantilla implementada en software que describe un conjunto de objetos con atributos y comportamiento similares. En UML se representara:

Como se ve, es un recuadro con tres filas: La 1 fila es el nombre de la clase. La 2 fila contiene los atributos. La 3 fila contiene los mtodos. Una instancia u objeto de una clase es una representacin concreta y especfica de una clase y que reside en la memoria del ordenador.

10

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

En UML se representara:

Dnde aparece un cuadrado con: El nombre del objeto: Mi Lavadora. El nombre de la clase Lavadora a la que pertenece el objeto Mi lavadora. El smbolo de dos puntos : que separa el nombre del objeto y la clase en la que se encuentra. Tanto el objeto, los dos puntos y el nombre de la clase estn subrayados. Atributos o propiedades Los atributos son las caractersticas individuales que diferencian un objeto de otro y determinan su apariencia, estado u otras cualidades. Los atributos se guardan en variables denominadas de instancia, y cada objeto particular puede tener valores distintos para estas variables. Comportamiento El comportamiento de los objetos de una clase se implementa mediante funciones miembro o mtodos. Un mtodo es un conjunto de instrucciones que realizan una determinada tarea y son similares a las funciones de los lenguajes estructurados.

Qu es UML?
El UML est compuesto por diversos elementos grficos que se combinan para conformar diagramas. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. El modelo UML de un sistema es similar a un modelo a escala de un edificio junto con la interpretacin del artista del esdificio. Es importante destacar que un modelo UML describe lo que supuestamente har un sistema, pero no dice cmo implementar dicho sistema. A continuacin se describirn los diagramas ms comunes del UML y los conceptos que representan. Concretamente veremos esta semana: Diagrama de clase Diagrama de casos de uso Diagrama de estados Diagrama de actividades

Tambin veremos esta semana otras caractersticas de UML: Notas Paquetes

11

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Diagrama de clases
Es un diagrama en el que se representan las relaciones entre clases. Observa los siguientes ejemplos:

Recuerda que cada clase se representa con un rectngulo que tiene dentro tres filas, tal y como lo vimos para el caso de la clase Lavadora. En los ejemplos que se muestran anteriormente no se muestra la fila de los atributos ni la fila de los mtodos porque lo que se quiere resaltar es la multiplicidad. En el primer ejemplo, se lee: Dado un esposo ste est casado con una esposa. Se trata pues de una relacin uno a uno. Tambin se puede leer a la inversa: Dada una esposa, sta est casada con un esposo. En el segundo ejemplo, se lee: Dado un maestro ste ensea a muchos estudiantes. Se trata pues de una relacin uno a muchos. Si se lee a la inversa: Dado un estudiante, ste es enseado por un solo Maestro. Ves la diferencia? 12

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

En el tercer ejemplo, se lee: Dado un cajero ste atiende de 1 a muchos clientes. Se trata pues de una relacin uno a uno o ms. Si se lee a la inversa: Dado un cliente, ste es atendido por un solo Cajero. Fjate que los puntos suspensivos .. sirven para indicar el mnimo y el mximo de multiplicidad. En el cuarto ejemplo, se lee: Dada una casa ste tiene 0 o ninguna chimenea. Se trata pues de una relacin una a ninguna o una. Si se lee a la inversa: Dada una chimenea, sta es de una casa. Fjate que la coma indica las posibles multiplicidades de la chimenea, es decir, una o ninguna.

Diagrama de casos de uso

Un caso de uso es una descripcin de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores del sistema, sta es una herramienta valiosa, ya que es una tcnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante pues muchas veces se desarrollan proyectos sin la debida participacin de los usuarios, y se suele dar el caso que cuando est terminado no es de utilidad para los usuarios para los que se supone se ha desarrollado. Los casos de uso permiten que tanto analistas, clientes, desarrolladores y usuarios puedan utilizar un lenguaje comn.

Se le llama actor a toda entidad externa al sistema que guarda una relacin con ste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero tambin incluye a todos los sistemas externos, adems de entidades abstractas, como el tiempo. En el caso del caso de uso anterior: el Usuario de la lavadora es un actor. Lavar ropa es un caso de uso. La lnea entre el actor y el caso de uso es una relacin (asociacin) que denota la participacin del actor en el caso de uso.

13

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

El siguiente caso muestra un diagrama de casos de uso ms complejo:

En este caso se trata de recoger la operacin de una mquina de gaseosas. El diagrama de casos de uso tiene los siguientes elementos: Actores: Cliente, Representante del proveedor y Recolector. Casos de uso: Comprar gaseosa, Reabastecer y Recolectar dinero. El contexto, que es el recuadro que supone el lmite del sistema. Las relaciones, que son las lneas que unen los actores con los casos de uso que utilizan.

A continuacin se describen los actores y los casos de uso que utiliza cada uno: Cliente, o persona que introduce el dinero en la mquina para comprar una gaseosa. Representante del proveedor, que es el que Reabastece de gaseosas la mquina cada cierto tiempo. Recolector, que es la persona que abre la mquina para recoger el dinero recaudado por la mquina de gaseosa.

14

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Diagrama de estados
En cualquier momento, un objeto se encuentra en un estado en particular. Una persona puede ser recin nacida, nia, adolescente, joven o adulta. Un elevador se mover hacia arriba, estar en estado de reposo o se mover hacia abajo. Una lavadora podr estar en fase de remojo, lavado, enjuague, centrifugado o apagada. A continuacin se muestra un ejemplo sobre los estados en que puede estar una lavadora. El smbolo que est en la parte superior de la figura representa el estado inicial y el de la parte inferior el estado final.

Diagrama de Actividades
Un diagrama de actividades ha sido diseado para mostrar una visin simplificada de lo que ocurre durante una operacin o proceso. Es una extensin de un diagrama de estados como el que vimos en el apartado anterior. La diferencia con el diagrama de estados es que ste muestra los estados de un objeto (en un rectngulo con bordes redondeados) y representa las actividades como flechas que conectan los estados. El diagrama de actividades, sin embargo, resalta precisamente las actividades. A cada actividad se le representa mediante un rectngulo redondeado, y la transicin entre una actividad y otra se representa mediante una flecha. Un ejemplo de diagrama de actividad es el siguiente:

15

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

16

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Una versin muy interesante de diagrama de actividades es aqul que incluye marcos para determinar la responsabilidad de cada actividad. A continuacin se muestra un ejemplo en el que se aprecian las responsabilidades del vendedor, el consultor y un tcnico:

17

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Otras caractersticas de UML

UML proporciona caractersticas que le permiten organizar y extender los diagramas. Entre ellas estn las siguientes: Paquetes En algunas ocasiones se encontrar con la necesidad de organizar los elementos de un diagrama en un grupo. Tal vez quiera mostrar que ciertas clases o componentes son parte de un subsistema en particular. Para ello, los agrupar en un paquete, que se representar por una carpeta tabular, como se muestra a continuacin:

Notas Es frecuente que alguna parte del diagrama no presente una clara explicacin del porqu est all o la manera en que trabaja. Cuando ste sea el caso, la nota UML ser til. Imagine a una nota como el equivalente grfico de un papel adhesivo. La nota es un rectngulo con una esquina doblada, y dentro del rectngulo se coloca la explicacin. Usted adjunta la nota al elemento del diagrama conectndolos mediante una lnea discontinua.

18

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

RUP (Rational Unified Process)

A continuacin vamos a ver el proceso unificado de Rational RUP (Rational Unified Process).

RUP no es el nico Ciclo de Vida pensado para la orientacin de objetos. Pero si resulta uno de los primeros con xito puesto que surge de los tres amigos, que son Grady Booch, James Rumbaugh e Ivar Jacobson, que despus de trabajar en diferentes empresas y realizar trabajos por separado sobre la orientacin a objetos con mucho xito, son contratados por la empresa Rational Software Corporation en 1994 que les permite desarrollar en conjunto UML y RUP. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones.

19

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina vara. En el ciclo de vida RUP se basa en: Proceso dirigido por los casos de uso. Proceso iterativo e Incremental Proceso centrado en la Arquitectura Proceso dirigido por los casos de Uso Se dice que est dirigido por los casos de uso puesto que los casos de uso integran el trabajo como se muestra grficamente a continuacin:

Proceso iterativo e incremental En RUP hay 4 fases que se componen de varias iteraciones cada una de ellas, donde: Cada iteracin es como un ciclo de vida en cascada a menor escala. Cada iteracin genera un prototipo ejecutable que se muestra a los usuarios y clientes. Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes.

20

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Cada iteracin es un pequeo ciclo de vida en cascada a menor escala que comprende: Planificar la iteracin (estudio de riesgos) Anlisis de los Casos de Uso y escenarios Diseo de opciones arquitectnicas Codificacin y pruebas. La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccin. Evaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) Preparacin de la entrega (documentacin e instalacin del prototipo) Proceso centrado en la arquitectura En este sentido: Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades. RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo. El mdulo de orientacin a objetos permite la creacin de cdigo reutilizable que permite ir creando un pool de componentes reutilizables.

21

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Metodologas
Una metodologa es un Conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.

Metodologas vs Ciclos de Vida

A veces se confunde metodologa con Ciclo de Vida y por ello damos las siguientes diferencias: Una metodologa puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica qu es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cmo hacerlo. La metodologa indica cmo hay que obtener los distintos productos parciales y finales.

Clasificacin de las metodologas

A continuacin vemos la siguiente clasificacin de metodologas: Las metodologas estructuradas o Orientadas a procesos o Orientadas a datos Jerrquicas No jerrquicas o Mixtas Orientadas a objetos Para sistemas de tiempo real Las metodologas estructuradas se basan en: la programacin estructurada, que consiste en el uso de las tres estructuras bsicas estudiadas la semana anterior: secuencial, condicional y repetitiva. Se basan en el estudio por separado de procesos y datos. Para el anlisis de datos se usan los diagramas de Entidad/Interrelacin y para el anlisis de los procesos se usan los diagramas de flujos de datos.

Las metodologas orientadas a objetos se basan sin embargo en la identificacin y organizacin de conceptos del dominio de la aplicacin y no tanto de su representacin final en un lenguaje de programacin.

Metodologas tradicionales vs recientes

Las metodologas tradicionales, como la de cascada, persiguen el cumplimiento de los plazos para las fases y descuidan bastante la interaccin entre usuarios y desarrolladores. Las metodologas basadas en el desarrollo del software hacen justo lo contrario: se difumina la diferenciacin entre fases, y sin embargo existe mucho ms contacto entre usuarios y desarrolladores. Las metodologas recientes permiten que el analista pueda ser creativo y no tenga que estar encorsetado en fases artificiales. Hoy en da se asume que cada desarrollo es diferente y se permite que el analista sea creativo. Pero a la vez

22

Unidad de Trabajo n1: Introduccin al Desarrollo del Software (Semana 2)

Bibliografa
Anlisis y Diseo detallado de aplicaciones Informticas de Gestin. Mario Piattini y otros. Editorial RAMA Aprendiendo UML en 24 horas. Joseph Schmuller. Editorial Prentice-Hall. Desarrollo de Software Orientado a Objeto usando UML. Patricio Letelier Torres (Departamento Sistemas Informticos y Computacin (DSIC) - Universidad Politcnica de Valencia (UPV) - Espaa

23