Fundamentos del enfoque Orientado a Objetos

El paradigma orientado a objetos se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

En el enfoque Orientado a Objetos, las propiedades del objeto son claves. Los
principios del modelo OO son: abstraccin, encapsulacin, modularidad y jerarqua, fundamentalmente, y en menor grado tipificacin (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO. Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus caractersticas esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia. Es el orden de las abstracciones organizado por niveles. Tipificacin. Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. est. Concurrencia. Es la propiedad que distingue un objeto que est activo de uno que no lo

Persistencia. Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).

Caractersticas de la POO.
Existe un acuerdo acerca de qu caractersticas contempla la "orientacin 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.

Por ejemplo, volvamos al ejemplo de los automviles, Qu caractersticas podemos abstraer de los automviles? O lo que es lo mismo Qu caractersticas semejantes tienen todos los automviles? Todos tendrn una marca, un modelo, nmero de chasis, peso, llantas, puertas, ventanas, etc. Y en cuanto a su comportamiento todos los automviles podrn acelerar, frenar, retroceder, etc. En los lenguajes de programacin orientada a objetos, el concepto de Clase es la representacin y el mecanismo por el cual se gestionan las abstracciones. Por ejemplo, en Java tenemos: public class Automovil { // variables // mtodos } 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, el encapsulamiento consiste en unir en la Clase las caractersticas y comportamientos, esto es, las variables y mtodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstraccin y el ocultamiento que veremos a continuacin. La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde slo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesar ser conocer qu hace la Clase pero no ser necesario saber cmo lo hace. 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 que se puedan compilar por separado, pero que 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. Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer slo los detalles que sean necesarios para el resto del sistema. El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habr cierto comportamiento privado de la Clase que no podr ser accedido por otras Clases. Y controlar porque daremos ciertos mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dnde se validarn que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y mtodos.

 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. La herencia es uno de los conceptos ms cruciales en la POO. La herencia bsicamente consiste en que una clase puede heredar sus variables y mtodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y mtodos propios, tiene incorporados los atributos y mtodos heredados de la superclase. De esta manera se crea una jerarqua de herencia. Por ejemplo, imaginemos que estamos haciendo el anlisis de un Sistema para una tienda que vende y repara equipos celulares. En el grfico vemos 2 Clases ms que posiblemente necesitemos para crear nuestro Sistema. Esas 2 Clases nuevas se construirn a partir de la Clase Celular existente. De esa forma utilizamos el comportamiento de la SuperClase. 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.

Aplicaciones Orientadas a Objetos.

A lo largo de la historia de la programacin, los lenguajes y las metodologas han pasado de una relativa simplicidad a una complejidad creciente. Los lenguajes de programacin orientados a objetos pretenden aportar simplicidad a la tarea de programacin de grandes aplicaciones. Cuando se crearon las primeras computadoras todava no existan los lenguajes de programacin, tal como ahora los entendemos. El lenguaje ensamblador puede considerarse como el primer lenguaje de programacin propiamente dicho. Permita al usuario un dilogo ms fluido con la mquina a travs de instrucciones que tenan relacin directa con el conjunto de operaciones que la mquina poda realizar. A partir de este momento empez la evolucin de los lenguajes de programacin. _cada uno tena su entorno definido y aunque en realidad todos los lenguajes son polivalentes (en teora,

con cualquiera de ellos se puede desarrollar cualquier programa de gestin o cientfico). Pronto apareci la especializacin funcional. As, COBOL (Common Business Orientated Language) se introdujo como lenguaje mainframe para el diseo de aplicaciones de gestin.; FORTRAN (Formula Translator) para el diseo de aplicaciones cientficas; APL (A Programming Language) para el clculo matemtico, etc. A medida que el software tomaba importancia, aparecieron los primeros problemas relacionados con la programacin. Al tiempo que aumenta elvolumen de un programa, disminuye el control del mismo por parte del programador y la capacidad de este de dar mantenimiento. En un intento de solucionar estos problemas aparecen las metodologas de programacin. Una metodologa es un conjunto de reglas destinadas a simplificar las tareas de diseo, estimacin de costes, desarrollo y mantenimiento de un sistema informtico. A menudo se ven acompaadas con unas herramientas (CASE: Computer Aided Software Engeneering) que permiten la elaboracin estructurada y documentada de los sistemas informticos. DISEO DE APLICACIONES Y ELECCIN DE ENTORNO En entorno de programacin implica tanto el lenguaje de programacin como al empleo de una determinada metodologa. Los lenguajes de programacin no se producen por generacin espontnea y se ven influidos en gran manera por la forma en la que los profesionales piensan que se debe programar. De esta manera se crea un conjunto de reglas para simplificar la tarea de programacin. Generalizadas y codificadas, se convierten en <<principios>> de los que surgen los lenguajes de programacin en un afn por darles soporte. Estos <<principios>> son modelos que proporcionan tcnicas que , a su vez, deben aplicarse en el diseo e implementacin de los programas. Estas tcnicas nos indican la forma de resolver los distintos problemas que surgen a la hora de programar. Decimos que un lenguaje de programacin <<soporta>> un conjunto de <<principios>> si el lenguaje simplifica la aplicacin de estas tcnicas. A estos <<principios>> se les denomina metodologas de programacin. Las metodologas de programacin son modelos sobre como disear e implementar los programas. Diferentes modelos tienen como resultado diferentes tcnicas. Que cada tcnica sea distinta no implica que una sea la verdadera y que las dems falsas. Por el contrario, las metodologas se complementan entre s. Lo que todas las metodologas tienen en comn es la premisa de que hay que partir de abstracciones que corresponden a elementos del problema a resolver, y que la implementacin de la solucin se debe realizar mediante un conjunto de mdulos preferiblemente reutilizables. Las metodologas orientadas a objetos se centran en las estructuras de datos que sin embargo se relegan a un segundo plano en los modelos procedurales. La base de esta metodologa es que una estructura de datos debe contener las operaciones que los modifican. La tcnica que se utiliza para obtener esta <<abstraccin de datos>> es la encapsulacin de los mismos en una estructura conocida como clase. El accesos a los datos contenidos en la clase se realiza mediante las operaciones que la propia clase define. Por tanto, la metodologa orientada a objetos complementa el punto de vista procedural de operaciones realizadas sobre un flujo de datos, al asociar a cada dato el conjunto de operaciones que lo modifican. Como podr ver, ambos enfoques son complementarios. Para ilustrar las diferencias entre las aproximaciones orientadas a procedimientos y las orientadas a objetos, considere el diseo de un <<compilador>> El compilador es un programa que a partir de un conjunto de fichero fuente (programa) construye el cdigo objeto que posteriormente se convierte en programa. Para realizar su

trabajo, el compilador lee el fichero fuente y separa de l las variables y las instrucciones. Las variables constituyen la tabla de smbolos del programa, mientras que las instrucciones se organizan en un rbol sintctico donde se plasman todas la referencias que realizan los mandatos y funciones entre s. El modelo mejor establecido es el basado en funciones (procedural) que trata de la construccin de un programa como una coleccin de funciones. Las metodologas proporcionan una grua sobre cmo disear, organizar e implementar las funciones que componen un programa. La programacin orientada a objetos est basada en un modelo de construcciones de programas como un conjunto de clases. El diseo orientado a objetos identifica los tipos que representan los distintos objetos en el programa. Las operaciones a realizar con cada uno delos objetos son, al igual que en el modelo procedural, los pasos destinados a solucionar el problema. El objeto sirve adems de mdulo que puede reutilizarse para la solucin de un problema de similares caractersticas en otro programa. Ninguna metodologa resuelve con acierto todos los tipos de problemas. La programacin requiere una especializacin como la que se produce en la ingeniera pero todava no es posible identificarla como una ciencia. Las tcnicas a emplear se han de utilizar con exquisito cuidado, sin perder de vista el objetivo de resolver un determinado problema. Actualmente existe la tendencia de identificar la programacin con una disciplina Como la ingeniera. Sin embargo, debe considerarse ms como un arte como la arquitectura, donde se unen la inspiracin y el dominio de la tcnica. Para la eleccin de un determinado entorno debemos fijar los criterios necesarios, como los que describimos a continuacin.: Tamao de la aplicacin. Cuanto mayor sea el volumen de informacin a procesar, mas necesidad habr de estructurar dicha informacin de forma que se fcil su manipulacin. TIPOS DE RELACIONES Una relacin es una conexin semntica entre elementos del modelo. En el UML se definen relaciones de asociacin, generalizacin y dependencia. La agregacin y composicin son casos especiales de relaciones de asociacin. Tipos de relaciones. Notacin UML a) Asociacin: es un enlace fsico o conceptual entre objetos y denota algn tipo de dependencia semntica entre los objetos. granito: Familia de roca oid_familia = 1 sienita: Familia de roca oid_familia = 2 gab ro : Familia d e ro ca oid_f amilia = 3Una visin policntrica del ambiente bajo el enfoque orientado a objetos 99 Esta relacin es mostrada mediante enlaces representados por lneas slidas que conectan los elementos y que son enriquecidas con una variedad de adornos que indican sus propiedades, la figura 6 describe el concepto. Asociacin binaria: se establece entre dos clases y es representada por una lnea que las relaciona; cada lnea de la relacin determina una funcin, que indica el comportamiento

de una clase en la asociacin. Asociacin binaria Ejemplo de lo anterior se presenta en la figura 6, considerando las figuras jurdico administrativas denominadas reas bajo rgimen especial (ABRAE), se interpreta de la siguiente forma: cada categora de ABRAE (Parque Nacional-PN, Refugio de Fauna-RF, entre otras) agrupa muchas ABRAES (PN El vila, PN Sierra Nevada, RF Cuare) y cada ABRAE pertenece a una categora. Si la asociacin es compleja puede definirse una clase que contenga las propiedades de la asociacin, y es llamada clase asociacin, y representa una asociacin que tiene propiedades de clase (atributos, operaciones y asociaciones); denotada mediante un rectngulo de clase atado a una asociacin por medio de una lnea punteada. ABRAE oid_abrae nombre superfice Decreto_nro CAT_ABRAE oid_cat_abrae nombre La asociacin de las clases se interpreta tomando como ejemplo un rea de produccin agrcola, de la siguiente forma: en una parroquia se cultivan varios rubros agrcolas, y cada rubro es cultivado en algunas parroquias. La clase asociacin Parroquia/Rubro presenta un atributo llamado nmero_de_hectreas, e indica las hectreas dedicadas a un determinado rubro en una parroquia dada. Tambin es necesario mencionar que una asociacin entre tres o ms clases se denomina asociacin n-aria. Una funcin, tal como se menciona en la definicin de asociacin binaria, puede tener los siguientes adornos, y son: El nombre de la funcin, vinculado al extremo de la asociacin. Multiplicidad, la cual especifica el rango de la cardinalidad permitida (un intervalo con el formato: lmite-inferior..lmitesuperior; un entero; el smbolo * que denota un nmero ilimitado de elementos) b) Agregacin: es una forma de asociacin que especifica una relacin todo-parte entre el agregado (el todo) y sus componentes (las partes). c) Composicin: es una agregacin fuerte en donde el todo y las partes coinciden en su tiempo de vida. d) Generalizacin o herencia: es una relacin entre una clase (superclase) y una o ms variaciones de la clase (subclases). La superclase contiene los atributos y mtodos comunes mientras que la subclase los heredan aadiendo sus propios atributos y operaciones. Reusabilidad: Cualidad que nos indica que partes del programa ( en este caso objetos) pueden ser reutilizados en la confeccin de otros programas. Ello implica que los objetos definidos en un programa pueden ser extrados del mismo e implantados en otro sin tener que realizar modificaciones importantes en el cdigo del objeto. El objeto final es que el programador construya una librera de objetos que le permita realizar programas basndose en la tcnica de

cortar y pegar. Esta extrae (corta) cdigo de otras aplicaciones ya realizadas y las implementa (pega) en la aplicacin a realizar donde, tras algunos retoques, la nueva aplicacin estar lista para funcionar. Como podr observar el concepto de reusabilidad, permite reducir el tiempo de realizacin , ganando en claridad, mantenibilidad y productividad. Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay algunos modelos ms para representar este proceso. 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. Modelos de desarrollo de Software Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debera escoger el ms apropiado para sus necesidades. En ocasiones puede que una combinacin de varios modelos sea apropiado. Modelo de cascada Artculo principal: Desarrollo en cascada. El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva: 1. Especificacin de requisitos 2. 3. 4. Diseo del software Integracin Pruebas (o validacin)

5. 6.

Despliegue (o instalacin) Mantenimiento

Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones tambin se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crtica de los defensores de modelos ms flexibles. Modelo de Espiral Artculo principal: Desarrollo en espiral. La principal caractersticas del modelo en espiral es la gestin de riesgos de forma peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologas del modelo de cascada y del desarrollo rpido de aplicaciones, pero dando nfasis en un rea que para muchos no jug el papel que requiere en otros modelos: un anlisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala. La espiral se visualiza como un proceso que pasa a travs de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades: 1. crear planes con el propsito de identificar los objetivos del software,seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software; 2. Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para evaluar como identificar y eliminar el riesgo; 3. la implementacin del proyecto: implementacin del desarrollo del software y su pertinente verificacin; Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software puede ayudar como una meta propia en la integracin en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan: 1. El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que acepten este anlisis y acten en consecuencia. Para ello es necesaria confianza en los desarrolladores as como la predisposicin a gastar ms para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala. 2. Si la implementacin del riesgo de anlisis afectar de forma esencial los beneficios del proyecto, no debera utilizarse este modelo. 3. Los desarrolladores de software han de buscar de forma explcita riesgos y analizarlos de forma exhaustiva para que este modelo funcione. La primera fase es la bsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para as buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por ltimo, se evalan los resultados y se inicia el diseo de la siguiente fase. Desarrollo iterativo e incremental

El desarrollo iterativo recomienda la construccin de secciones reducidas de software que irn ganando en tamao para facilitar as la deteccin de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseo en el caso de clientes que no saben como definir lo que quieren.1 Desarrollo gil Artculo principal: Desarrollo gil de software. El desarrollo gil de software utiliza un desarrollo interactivo como base para abogar por un punto de vista ms ligero y ms centrado en las personas que en el caso de las soluciones tradicionales. Los procesos giles utilizan retroalimentacin en lugar de planificacin, como principal mecanismo de control. La retroalimentacin se canaliza por medio de pruebas peridicas y frecuentes versiones del software. Hay muchas variantes de los procesos giles: En el caso de la programacin extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un da o en una semana, en lugar de los meses o aos de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Despus se programa el cdigo, que ser completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabran como mejorar el conjunto de pruebas necesario. El diseo y la arquitectura emergen a partir de la refactorizacin del cdigo, y se da despus de programar. El diseo lo realizan los propios desarrolladores del cdigo. El sistema, incompleto, pero funcional se despliega para su demostracin a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de ms importancia. Codificacin y Correccin El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms que una estrategia predeterminada, el resultado de una falta de experiencia o presin que se ejerce sobre los desarrolladores para cumplir con una fecha de entrega.2 Sin dedicar tiempo de forma explcita para el diseo, los programadores comienzan de forma inmediata a producir cdigo. Antes o despus comienza la fase de pruebas de software (a menudo de forma tarda) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software. Modelos de Mejora de Procesos Capability Maturity Model Integration El Capability Maturity Model Integration (CMMI), en espaol Integracin de Modelos de Madurez de Capacidades es uno de los modelos lderes basados en mejores prcticas. Son evaluaciones independientes las que confirman el grado con el que una organizacin siguen sus propios procesos, que no evala la calidad de los procesos o del software que se produce. CMMI ha reemplazado a CMM y tiene un mbito global, no slo en procesos destinados al desarrollo del software. ISO 9000 ISO 9000 describe estndares para un proceso organizado formalmente para resultar en un producto y los mtodos de gestin y monitoreo del progreso. Aunque este estndar se cre inicialmente para el sector de produccin, los estndares de ISO 9000 tambin se han aplicado al desarrollo del software. Al igual que CMMI, que una organizacin est certificada con el ISO 9000 no garantiza la calidad del resultado final, slo confirma que se ha seguido los procesos establecidos. ISO 15504

ISO 15504, tambin conocido como Software Process Improvement Capability Determination (SPICE), en espaol Determinacin de la Capacidad de Mejora del Proceso de Software es un marco para la evaluacin de procesos de software. Este estndar tiene como objetivo un modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo que una organizacin o proyecto hace durante el desarrollo del software. Esta informacin se analiza para identificar puntos dbiles y definir acciones para subsanarlos. Tambin identifica puntos fuertes que pueden adoptarse en el resto de la organizacin. Mtodos Formales Los mtodos formales son soluciones matemticas para resolver problemas de software y hardware a nivel de requisitos, especificacin y diseo. Ejemplos de mtodos formales incluyen el Mtodo B, la red de Petri, la demostracin automtica de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje Z. Ms generalmente, se puede utilizar la teora de autmatas para aumentar y validar el comportamiento de la aplicacin diseando un sistema de autmata finito. Las metodologas basadas en los autmatas finitos permiten especificacin de software ejecutable y evitar la creacin convencional de cdigo. Los mtodos formales se suelen aplicar en software de aviacin, especialmente si es software de seguridad crtico. Los estndares de aseguramiento del software de seguridad, tales como DO178B demandan mtodos formales en el nivel ms alto de categorizacin (Nivel A). La formalizacin del desarrollo de software est ganando en fuerza poco a poco, en otros mbitos, con la aplicacin del lenguaje de especificacin OCL2.0 (y especializaciones tales como Java Modeling Language) y particularmente con Model-driven Architecture, que permite la ejecucin de diseos, incluso especificaciones. Otra tendencia que est surgiendo en el desarrollo de software es la redaccin de especificaciones en algn tipo de lgica (normalmente una variacin de FOL), para acto seguido ejecutar esa lgica como si se tratase de un programa. El lenguaje OWL, basado en lgica descriptiva, es un buen ejemplo. Tambin se est trabajando en enlazar un idioma natural de forma automtica con lgica, lgica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lgica de negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una caractersticas de los sistemas que apoyan el vnculo bidireccional ingls-lgica y ejecucin directa de la lgica es que pueden explicar sus resultados en ingls en un nivel de negocios o cientfico.