FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS. Fundamentos del Enfoque orientado a Objetos.

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos. Estos principios son: la Abstraccin, el Encapsulamiento, la Modularidad y la Herencia. Fundamento 1: Abstraccin Es el principio de ignorar aquellos aspectos de un fenmeno observado que no son relevantes, con el objetivo de concentrarse en aquellos que si lo son. Una abstraccin denota las caractersticas esenciales de un objeto (datos y operaciones), que lo distingue de otras clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio, es el problema central del diseo orientado a objetos. Los mecanismos de abstraccin son usados en el EOO para extraer y definir del medio a modelar, sus caractersticas y su comportamiento. Dentro del EOO son muy usados mecanismos de abstraccin: la Generalizacin, la Agregacin y la clasificacin. La generalizacin es el mecanismo de abstraccin mediante el cual un conjunto de clases de objetos son agrupados en una clase de nivel superior (Superclase), donde las semejanzas de las clases constituyentes (Subclases) son enfatizadas, y las diferencias entre ellas son ignoradas. En consecuencia, a travs de la generalizacin, la superclase almacena datos generales de las subclases, y las subclases almacenan slo datos particulares.La especializacin es lo contrario de la generalizacin. Por ejemplo; La clase Mdico es una especializacin de la clase Persona, y a su vez, la clase Pediatra es una especializacin de la superclase Mdico. La agregacin es el mecanismo de abstraccin por el cual una clase de objeto es definida a partir de sus partes (otras clases de objetos). Mediante agregacin se puede definir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos perifricos. El contrario de agregacin es la descomposicin. La clasificacin consiste en la definicin de una clase a partir de un conjunto de objetos que tienen un comportamiento similar. La ejemplificacin es lo contrario a la clasificacin, y corresponde a la instanciacin de una clase, usando el ejemplo de un objeto en particular. Fundamento 2: Encapsulamiento Es la propiedad del EOO que permite ocultar al mundo exterior la representacin interna del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo no son conocidos fuera de l. La idea central del encapsulamiento es esconder los detalles y mostrar lo relevante. Permite el ocultamiento de la informacin separando el aspecto correspondiente a la especificacin de la implementacin; de esta forma, distingue el "qu hacer" del "cmo hacer". La especificacin es visible al usuario, mientras que la implementacin se le

oculta. El encapsulamiento en un sistema orientado a objeto se representa en cada clase u objeto, definiendo sus atributos y mtodos con los siguientes modos de acceso: Pblico (+): Atributos o Mtodos que son accesibles fuera de la clase. Pueden ser llamados por cualquier clase, aun si no est relacionada con ella. Privado (-): Atributos o Mtodos que solo son accesibles dentro de la implementacin de la clase. Protegido (#): Atributos o Mtodos que son accesibles para la propia clase y sus clases hijas (subclases). Los atributos y los mtodos que son pblicos constituyen la interfaz de la clase, es decir, lo que el mundo exterior conoce de la misma.Normalmente lo usual es que se oculten los atributos de la clase y solo sean visibles los mtodos, incluyendo entonces algunos de consulta para ver los valores de los atributos. El mtodo constructor (Nuevo, New) siempre es Pblico. Fundamento 3: Modularidad Es la propiedad que permite tener independencia entre las diferentes partes de un sistema. La modularidad consiste en dividir un programa en mdulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones con otros mdulos. En un mismo mdulo se suele colocar clases y objetos que guarden una estrecha relacin. El sentido de modularidad est muy relacionado con el ocultamiento de informacin. Fundamento 4: Herencia Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra clase que lo preceda en una jerarqua de clasificaciones. Permite la definicin de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programacin Diferencial), evitando repeticin de cdigo y permitiendo la reusabilidad. Las clases heredan los datos y mtodos de la superclase. Un mtodo heredado puede ser sustituido por uno propio si ambos tienen el mismo nombre. La herencia puede ser simple (cada clase tiene slo una superclase) o mltiple (cada clase puede tener asociada varias superclases). La clase Docente y la clase Estudiante heredan las propiedades de la clase Persona (superclase, herencia simple). La clase Preparador (subclase) hereda propiedades de la clase Docente y de la clase Estudiante (herencia mltiple). Fundamento 5: Polimorfismo Es una propiedad del EOO que permite que un mtodo tenga mltiples implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la ejecucin del mtodo. El polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual nombre a diferentes clases o estn relacionados en trminos de inclusin. En este tipo de polimorfismo, los mtodos son interpretados en el

contexto del objeto particular, ya que los mtodos con nombres comunes son implementados de diferente manera dependiendo de cada clase. Por ejemplo, el rea de un cuadrado, rectngulo y crculo, son calculados de manera distinta; sin embargo, en sus clases respectivas puede existir la implementacin del rea bajo el nombre comn rea. En la prctica y dependiendo del objeto que llame al mtodo, se usar el cdigo correspondiente. Ejemplos: Superclase: Clase Animal Subclases: Clases Mamfero, Ave, Pez. Se puede definir un mtodo Comer en cada subclase, cuya implementacin cambia de acuerdo a la clase invocada, sin embargo el nombre del mtodo es el mismo. Mamifero.Comer Ave.Comer Pez.Comer Otro ejemplo de polimorfismo es el operador +. Este operador tiene dos funciones diferentes de acuerdo al tipo de dato de los operandos a los que se aplica. Si los dos elementos son numricos, el operador + significa suma algebraica de los mismos, en cambio si por lo menos uno de los operandos es un String o Carcter, el operador es la concatenacin de cadenas de caracteres. Caractersticas del Enfoque Orientado a Objetos. Las caractersticas siguientes son las ms importantes: Abstraccin: Denota las caractersticas esenciales de un objeto, donde se capturan sus comportamientos.Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin.El proceso de abstraccin permite seleccionar las caractersticas relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstraccin es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar. Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar la cohesin de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultacin, principalmente porque se suelen emplear conjuntamente. Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes. Estos mdulos se pueden compilar por separado, pero tienen conexiones con otros

mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas. Principio de ocultacin: Cada objeto est aislado del exterior, es un mdulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especfica cmo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstraccin. La aplicacin entera se reduce a un agregado o rompecabezas de objetos. Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en una referencia producir el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin tarda o asignacin dinmica. Algunos lenguajes proporcionan medios ms estticos (en "tiempo de compilacin") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++. Herencia: Las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un objeto hereda de ms de una clase se dice que hay herencia mltiple. Recoleccin de basura: La recoleccin de basura o garbage collector es la tcnica por la cual el entorno de objetos se encarga de destruir automticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignacin o liberacin de memoria, ya que el entorno la asignar al crear un nuevo objeto y la liberar cuando nadie lo est usando. En la mayora de los lenguajes hbridos que se extendieron para soportar el Paradigma de Programacin Orientada a Objetos como C+ + u Object Pascal, esta caracterstica no existe y la memoria debe desasignarse manualmente. Componentes fundamentales del Enfoque Orientado a Objetos.

Clase: Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciacin es la lctura de estas definiciones y la creacin de un objeto a partir de ellas. Herencia: (Por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos mtodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) tambin se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y slo pueden ser accedidos a travs de otros mtodos pblicos. Esto es as para mantener hegemnico el ideal de OOP. Objeto: Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (mtodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase. Mtodo: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se desencadena tras la recepcin de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un mtodo puede producir un cambio en las propiedades del objeto, o la generacin de un "evento" con un nuevo mensaje para otro objeto del sistema. Evento: Es un suceso en el sistema (tal como una interaccin del usuario con la mquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. Tambin se puede definir como evento, a la reaccin que puede desencadenar un objeto, es decir la accin que genera. Mensaje: Una comunicacin dirigida a un objeto, que le ordena que ejecute uno de sus mtodos con ciertos parmetros asociados al evento que lo gener. Propiedad o atributo: Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus caractersticas predeterminadas, y cuyo valor puede ser alterado por la ejecucin de algn mtodo. Estado interno: Es una variable que se declara privada, que puede ser nicamente accedida y alterada por un mtodo del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase. Componentes de un objeto: Atributos, identidad, relaciones y mtodos. Identificacin de un objeto: Un objeto se representa por medio de una tabla o entidad que est compuesta por sus atributos y funciones correspondientes. Reusabilidad de componentes. Una vez que una clase ha sido escrita, creada y depurada, se puede distribuir a otros programadores para utilizar en sus propios programas. Esta propiedad se llama reusabilidad o reutilizacin. Su concepto es similar a las funciones incluidas en las bibliotecas de funciones de un lenguaje procedimental como C que se pueden

incorporar en diferentes programas. En C++, el concepto de herencia proporciona una extensin o ampliacin al concepto de reusabilidad. Un programador puede considerar una clase existente y sin modificarla, aadir competencias y propiedades adicionales a ella. Esto se consigue derivando una nueva clase de una ya existente. La nueva clase heredar las caractersticas de la clase antigua, pero es libre de aadir nuevas caractersticas propias. La facilidad de reutilizar o rehusar el software existente es uno de los grandes beneficios de la POO: muchas empresas consiguen con la reutilizacin de clase en nuevos proyectos la reduccin de los costes de inversin en sus presupuestos de programacin. Las propiedades comunes de varias clases slo necesitan ser implementadas una vez y slo necesitan modificarse una vez si es necesario. ESTNDARES EN EL PROCESO DE DESARROLLO DE SOFTWARE La gran cantidad de organizaciones de desarrollo de software implementan metodologas para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentstica, que en los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un contrato. El estndar internacional que regula el mtodo de seleccin, implementacin y monitoreo del ciclo de vida del software es ISO 12207. Durante dcadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software. Otros aplican tcnicas de gestin de proyectos para la creacin del software. Sin una gestin del proyecto, los proyectos de software corren el riesgo de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen sus metas en trminos de funcionalidad, costes o tiempo de entrega, una gestin de proyectos efectiva es algo que a menudo falta. Planificacin. La importante tarea a la hora de crear un producto de software es obtener los requisitos o el anlisis de los requisitos. Los clientes suelen tener una idea ms bien abstracta del resultado final, pero no sobre las funciones que debera cumplir el software. Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un anlisis del mbito del desarrollo. Este documento se conoce como especificacin funcional. Implementacin, pruebas y documentacin. La implementacin es parte del proceso en el que los ingenieros de software programan el cdigo para el proyecto. Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la funcin de detectar los errores de software lo antes posible. La documentacin del diseo interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentacin de un API, tanto interior como exterior.

Despliegue y mantenimiento. El despliegue comienza cuando el cdigo ha sido suficientemente probado, ha sido aprobado para su liberacin y ha sido distribuido en el entorno de produccin. Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software. El mantenimiento y mejora del software de un software con problemas recientemente desplegado puede requerir ms tiempo que el desarrollo inicial del software. Es posible que haya que incorporar cdigo que no se ajusta al diseo original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno redisear el sistema para poder contener los costes de mantenimiento.

Codificar y corregir. Este es el modelo bsico utilizado en los inicios del desarrollo de software. Contiene dos pasos: Escribir cdigo. Corregir problemas en el cdigo. Se trata de primero implementar algo de cdigo y luego pensar acerca de requisitos, diseo, validacin, y mantenimiento. Este modelo tiene tres problemas principales: Despus de un nmero de correcciones, el cdigo puede tener una muy mala estructura, hace que los arreglos sean muy costosos. Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es muy cara. El cdigo es difcil de reparar por su pobre preparacin para probar y modificar. Modelo en cascada. El primer modelo de desarrollo de software que se public se deriv de otros procesos de ingeniera. ste toma las actividades fundamentales del proceso de especificacin, desarrollo, validacin y evolucin y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: 1. Definicin de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definicin en detalle. 2. Diseo de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Implementacin y pruebas unitarias: Construccin de los mdulos y unidades de software. Se realizan pruebas de cada unidad. 4. Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es puesto en marcha y se realiza la correccin de errores descubiertos. Se realizan mejoras de implementacin. Se identifican nuevos requisitos. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la correccin de los problemas encontrados en fases previas.

Desarrollo evolutivo. La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura se observa cmo las actividades concurrentes: especificacin, desarrollo y validacin, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.

Existen dos tipos de desarrollo evolutivo: Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se

tiene ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario. Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. Entre los puntos favorables de este modelo estn: La especificacin puede desarrollarse de forma creciente. Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software. Es ms efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente. Desde una perspectiva de ingeniera y administracin se identifican los siguientes problemas: Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del sistema. Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. Este modelo es efectivo en proyectos pequeos (menos de 100.000 lneas de cdigo) o medianos (hasta 500.000 lneas de cdigo) con poco tiempo para su desarrollo y sin generar documentacin para cada versin. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento ms estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio. Desarrollo formal de sistemas. Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable. Se distinguen dos fases globales: especificacin (incluyendo validacin) y transformacin. Las caractersticas principales de este paradigma son: la especificacin es formal y ejecutable constituye el primer prototipo del sistema), la

especificacin es validada mediante prototipacin. Posteriormente, a travs de transformaciones formales la especificacin se convierte en la implementacin del sistema, en el ltimo paso de transformacin se obtiene una implementacin en un lenguaje de programacin determinado. , el mantenimiento se realiza sobre la especificacin (no sobre el cdigo fuente), la documentacin es generada automticamente y el mantenimiento es realizado por repeticin del proceso (no mediante parches sobre la implementacin). Observaciones sobre el desarrollo formal de sistemas: Permite demostrar la correccin del sistema durante el proceso de transformacin. As, las pruebas que verifican la correspondencia con la especificacin no son necesarias. Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes. Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo. Desarrollo basado en reutilizacin. Como su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuacin se describe cada fase: 1. Anlisis de componentes: Se determina qu componentes pueden ser utilizados para el sistema en cuestin. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes ms adecuados (fase 1). 3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para disear o determinar este marco. 4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integracin es parte del desarrollo en lugar de una actividad separada. Ventajas de este modelo: Disminuye el costo y esfuerzo de desarrollo. Reduce el tiempo de entrega. Disminuye los riesgos durante el desarrollo.

Desventajas de este modelo: Los compromisos en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente. Las actualizaciones de los componentes adquiridos no estn en manos de los desarrolladores del sistema. Procesos iterativos: A continuacin se expondrn dos enfoques hbridos, especialmente diseados para el soporte de las iteraciones: Desarrollo Incremental. Desarrollo en Espiral. Desarrollo incremental. Sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema Es una combinacin del Modelo de Cascada y Modelo Evolutivo.Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Entre las ventajas del modelo incremental se encuentran: Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento. Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema. Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos. Algunas de las desventajas identificadas para este modelo son: Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas). Cada incremento debe aumentar la funcionalidad. Es difcil establecer las correspondencias de los requisitos contra los incrementos. Es difcil detectar las unidades o servicios genricos para todo el sistema. Desarrollo en espiral. El modelo de desarrollo en espiral. Es actualmente uno de los ms conocidos y fue propuesto por Boehm .El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: 1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseo detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. 3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo, esta es una actividad importante en la administracin del proyecto.

El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalan los riesgos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

Metodologas para desarrollo de software. Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo. La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el

apelativo de Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. Rapid Application Development (RAD). El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que implica el desarrollo interativo y la construccin de prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991. Principios bsicos: Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversin. Intenta reducir los riesgos inherentes del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo. Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestin de bases de datos (DBMS), lenguajes de programacin de cuarta generacin, generadores de cdigo, y tcnicas orientada a objetos. Hace especial hincapi en el cumplimiento de la necesidad comercial, mientras que la ingeniera tecnolgica o la excelencia es de menor importancia. Control de proyecto implica el desarrollo de prioridades y la definicin de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapi en la reduccin de requisitos para el ajuste, no en el aumento de la fecha lmite. En general incluye Joint application development (JAD), donde los usuarios estn intensamente participando en el diseo del sistema, ya sea a travs de la creacin de consenso estructurado en talleres, o por va electrnica. La participacin activa de los usuarios es imprescindible. Iterativamente realiza la produccin de software, en lugar de enfocarse en un prototipo. Produce la documentacin necesaria para facilitar el futuro desarrollo y mantenimiento.

DOCUMENTACIN Y ARTEFACTOS Documentacin. La documentacin es la debilidad ms frecuente en productos e instalaciones informticos. Los actores que intervienen en el ciclo de vida del software desempean diversos roles. Arquitectos, diseadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos. El cdigo fuente del software, la estructura de datos y los enlaces de comunicaciones constituyen en conjunto el paradigma de la documentacin informtica. Sin embargo, cuando los modelos de arquitectura, estructuras y especificaciones de diseo no los vinculan, slo pueden acceder a stos dificultosamente los iniciados. Hay buenas prcticas para escribir cdigo fuente pero, las condiciones y circunstancias de cada programa y sistema son tan diversas que, las exigencias habituales se reducen a que funcione razonablemente. Artefactos. Artefactos, de acuerdo con RUP, es una pieza de informacin producida, modificada o utilizada por un proceso. Artefacto son los productos tangibles del proyecto, las cosas

que los proyectos producen o utilizan mientras se trabaja hacia el producto final. Los artefactos son insumos utilizados para realizar actividades y, son los resultados de estas actividades. Son artefactos entregables como ejecutables, el cdigo fuente, manuales, planes y proyectos. Productos intermedios, como documentos de arquitectura y diseo, especificaciones de requerimientos, modelos de negocios y casos de uso. De igual forma, son artefactos los elementos que componen los modelos y productos, como glosarios y diccionarios, grficos, clases o subsistemas. Tambin, en negocios regulados, son artefactos los instrumentos y evidencias de la gestin informtica. Requisitos y Herramientas. Los requerimientos con sus especificaciones permiten disear y elaborar el software, proveen las glosas, trminos, conceptos y definiciones necesarios para elaborar todo tipo de manuales y guas de uso del software. Cuando los requerimientos funcionales tienen marcos legales con requisitos especficos, como en los casos de entidades financieras, empresas que cotizan en bolsa o que manipulan datos personales es necesario adems, documentar la gestin del software y, la operacin de los sistemas y las instalaciones. Herramientas automatizadas para la administracin de requerimientos, el modelado del negocios, y las plataformas de desarrollo proporcionan gran parte de la documentacin de las estructuras y especificaciones de diseo para articular, mediante referencias y trazabilidad, los casos de uso, con los componentes del software y sus programas fuentes. Toda regulacin de la operacin informtica requiere de resguardar datos y configuracin, los llamados back-up, tambin la identificacin del acceso a la informacin. Adems, la regulacin actual requiere evidencias de las modificaciones al software y su configuracin, y registros de los incidentes ocurridos en la operacin y gestin del software. Hay herramientas automatizadas para proporcionar estas evidencias, los sistemas de seguridad, de recuperacin de datos ante contingencias, de control de cambios, despliegue de programas y configuracin, y de seguimiento de incidentes (suelen utilizarse al menos dos sistemas de incidentes, uno para los del negocio y otro para los de operaciones e instalaciones).

Proceso Unificado de Desarrollo. El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational. Fases de Desarrollo. Fase de Inicio. Es la fase ms pequea del proyecto e, idealmente, debe realizarse tambin en un periodo de tiempo pequeo (una nica iteracin). El hecho de llevar a cabo una fase de inicio muy larga indica que se esta realizando una especificacin previa excesiva, lo que responde ms a un modelo en cascada. Objetivos: o Establecer una justificacin para el proyecto. o Establecer el mbito del proyecto. o Esbozar los casos de uso y los requisitos clave que dirigirn las decisiones de diseo. o Esbozar las arquitecturas candidatas. o Identificar riesgos. o Preparar el plan del proyecto y la estimacin de costes. El hito de final de fase se conoce como Hito Objetivo del Ciclo de Vida. Fase de Elaboracin.

Durante esta fase se capturan la mayora de los requisitos del sistema. Los objetivos principales de esta fase sern la identificacin de riesgos y establecer y validar la arquitectura del sistema. Base de Arquitectura Ejecutable: La arquitectura se valida a travs de la implementacin de una Base de Arquitectura Ejecutable: se trata de una implementacin parcial del sistema que incluye los componentes principales del mismo. Al final de la fase de elaboracin la base de arquitectura ejecutable debe demostrar que soporta los aspectos clave de la funcionalidad del sistema y que muestra la conducta adecuada en trminos de rendimiento, escalabilidad y coste. Al final de la fase se elabora un plan para la fase de construccin. El hito arquitectura del ciclo de vida marca el final de la fase. Fase de construccin. Es la fase ms larga de proyecto. El sistema es construido en base a lo especificado en la fase de elaboracin. Las caractersticas del sistema se implementan en una serie de iteraciones cortas y limitadas en el tiempo. El resultado de cada iteracin es una versin ejecutable de software. El hito de capacidad operativa inicial marca el final de la fase. Fase de transicin. En esta fase el sistema es desplegado para los usuarios finales. La retroalimentacin recibida permite incorporar refinamientos al sistema en las sucesivas iteraciones. Esta iteracin tambin cubre el entrenamiento de los usuarios para la utilizacin del sistema. El hito de lanzamiento del producto marca el final de la fase.

Disciplinas. Modelado del negocio. El objetivo es establecer un canal de comunicacin entre los ingenieros del negocio y los ingenieros del software. Los ingenieros del software deben conocer la estructura y dinmica de la organizacin objetivo (el cliente), los problemas actuales y sus posibles mejoras. Se plasma en la identificacin del modelo del dominio en el que se visualizan los aspectos bsicos del dominio de aplicacin. Requisitos. El objetivo es describir que es lo que tiene que hacer el sistema y poner a los desarrolladores y al cliente de acuerdo en esta descripcin. Anlisis y diseo. Describe como el software ser realizado en la fase de implementacin. Se plasma en un modelo de diseo que consiste en una serie de clases (agrupadas en paquetes y subsistemas) con interfaces bien definidos. Tambin contiene descripciones de cmo los objetos colaboran para realizar las acciones incluidas en los casos de uso. Implementacin. Se implementan las clases y objetos en trminos de componentes (ficheros fuentes, binarios, ejecutables, entre otros). Prueba. Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integracin entre objetos, la implementacin de todos los requisitos, entre otros. Despliegue. Se crea la versin externa del producto, se empaqueta, se distribuye y se instala en el lugar de trabajo. Tambin se da asistencia y ayuda a los usuarios. Gestin de configuraciones y cambios.

Gestiona aspectos como los sistemas de control de versiones. Controla las peticiones de cambios clasificndolas segn su estado (nueva, registrada, aprobada, asignada, completa, entre otros). Los datos se almacenan en una base de datos y se pueden obtener informes peridicos. Herramientas como Rational ClearQuest o Bugzilla. Gestin del proyecto. Encargada de definir los planes del proyecto global, los planes de fase y los planes de iteracin. Entorno. Se centra en las actividades necesarias para configurar el proceso de un proyecto. El objetivo es proveer a la organizacin de desarrollo software de un entorno de trabajo (que incluye procedimientos y herramientas) que soporten al equipo de desarrollo.