METODOLOGA DE DESARROLLO DE SOFTWARE Metodologa de desarrollo de software en ingeniera de software es un marco de trabajo usado para estructurar, planificar y controlar

el proceso de desarrollo en sistemas de informacin.1 Tres patrones bsicos en las metodologas de desarrollo de software. 1 INTRODUCCIN 2 HISTORIA 3 METODOLOGAS DE DESARROLLO DE SOFTWARE 4 ENFOQUES DE DESARROLLO DE SOFTWARE 4.1 MODELO EN CASCADA 4.2 PROTOTIPADO 4.3 INCREMENTAL 4.4 ESPIRAL 4.5 RAPID APPLICATION DEVELOPMENT (RAD) 4.6 OTROS ENFOQUES DE DESARROLLO DE SOFTWARE 5 REFERENCIA INTRODUCCIN Una metodologa de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de informacin. A lo largo del tiempo, una gran cantidad de mtodos han sido desarrollados diferencindose por su fortaleza y debilidad. El FRAMEWORK para metodologa de desarrollo de software consiste en: Una filosofa de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software. Herramientas, modelos y mtodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algn tipo de organizacin, que adems desarrolla, apoya el uso y promueve la metodologa. La metodologa es a menudo documentada en algn tipo de documentacin formal. HISTORIA El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en una muy deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de informacin en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de clculo. METODOLOGAS DE DESARROLLO DE SOFTWARE 1970s Programacin estructurada sol desde 1969 Programacinestructurada Jackson desde 1975 1980s Structured Systems Analysis and Design Methodology (SSADM) desde 1980 Structured Analysis and Design Technique (SADT) desde 1980 Ingeniera de la informacin (IE/IEM) desde 1981 1990s Rapid application development (RAD) desde 1991.Desarrollo rpido de aplicaciones El desarrollo rpido de aplicaciones o RAD (acrnimo en ingls de rapidapplicationdevelopment) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El mtodo comprende el desarrollo iterativo, la construccin de prototipos y el uso de utilidades CASE (ComputerAided Software Engineering). Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin. Hoy en da se suele utilizar para referirnos al desarrollo rpido de interfaces grficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas ms conocidas son Visual Studio, Delphi, Foxpro ,Anjuta,

PROGRAMACIN ORIENTADA A OBJETOS(OOP) a lo largo de la dcada de los 90's Programacin orientada a objetos La programacin orientada a objetos o POO (OOP segn sus siglas en ingls) es un paradigma de programacin que usa objetos y sus interacciones, para disear aplicaciones y programas informticos. Est basado en varias tcnicas, incluyendo herencia, abstraccin, polimorfismo y encapsulamiento. Su uso se populariz a principios de la dcada de los aos 1990. En la actualidad, existe variedad de lenguajes de programacin que soportan la orientacin a objetos. Contenido 1 Introduccin 2 Origen 3 Conceptos fundamentales 4 Caractersticas de la POO 5 Resumen 6 Lenguajes orientados a objetos 7 Enlaces externos INTRODUCCIN Los objetos son entidades que combinan estado (atributo), comportamiento (mtodo) e identidad: El estado est compuesto de datos, ser uno o varios atributos a los que se habrn asignado unos valores concretos (datos). El comportamiento est definido por los procedimientos o mtodos con que puede operar dicho objeto, es decir, qu operaciones se pueden realizar con l. La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto anlogo al de identificador de una variable o una constante).

Un objeto contiene toda la informacin que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interaccin llamados mtodos, que favorecen la comunicacin entre ellos. Esta comunicacin favorece a su vez el cambio de estado en los propios objetos. Esta caracterstica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los mtodos (comportamiento) y atributos (estado) estn estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de mtodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podra producir el hbito errneo de crear clases contenedoras de informacin por un lado y clases con mtodos que manejen a las primeras por el otro. De esta manera se estara realizando una programacin estructurada camuflada en un lenguaje de programacin orientado a objetos.

La POO difiere de la programacin estructurada tradicional, en la que los datos y los procedimientos estn separados y sin relacin, ya que lo nico que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programacin estructurada anima al programador a pensar sobre todo en trminos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programacin estructurada slo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitndoles que realicen sus mtodos por s mismos. ORIGEN Los conceptos de la programacin orientada a objetos tienen origen en Simula 67, un lenguaje diseado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cmputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosin combinatoria de cmo las diversas cualidades de diferentes naves podan afectar unas a las otras. La idea surgi al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados ms tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versin fue escrita sobre Basic) pero diseado para ser un sistema completamente dinmico en el cual los objetos se podran crear y modificar "sobre la marcha" (en tiempo de ejecucin) en lugar de tener un sistema basado en programas estticos.

La programacin orientada a objetos se fue convirtiendo en el estilo de programacin dominante a mediados de los aos ochenta, en gran parte debido a la influencia de C++, una extensin del lenguaje de programacin C. Su dominacin fue consolidada gracias al auge de las Interfaces grficas de usuario, para las cuales la programacin orientada a objetos est particularmente bien adaptada. En este caso, se habla tambin de programacin dirigida por eventos.

Las caractersticas de orientacin a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adicin de estas caractersticas a los lenguajes que no fueron diseados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del cdigo. Los lenguajes orientados a objetos "puros", por su parte, carecan de las caractersticas de las cuales muchos programadores haban venido a depender. Para saltar este obstculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en mtodos orientados a objetos, pero permitiendo algunas caractersticas imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparicin de Internet, y a la implementacin de la mquina virtual de Java en la mayora de navegadores. PHP en su versin 5 se ha modificado, soporta una orientacin completa a objetos, cumpliendo todas las caractersticas propias de la orientacin a objetos. CONCEPTOS FUNDAMENTALES La programacin orientada a objetos es una forma de programar que trata de encontrar una solucin a estos problemas. Introduce nuevos conceptos, que superan y amplan conceptos antiguos ya conocidos. Entre ellos destacan los siguientes: CLASE: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciacin es la lectura 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. En comparacin con un lenguaje imperativo, una "variable", no es ms que un contenedor interno del atributo del objeto o de un estado interno, as como la "funcin" es un procedimiento interno del mtodo del objeto. 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. 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 especifica 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 garbagecollector 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.

RESUMEN La programacin orientada a objetos es un paradigma que utiliza objetos como elementos fundamentales en la construccin de la solucin. Surge en los aos 70. Un objeto es una abstraccin de algn hecho o ente del mundo real que tiene atributos que representan sus caractersticas o propiedades y mtodos que representan su comportamiento o acciones que realizan. Todas las propiedades y mtodos comunes a los objetos se encapsulan o se agrupan en clases. Una clase es una plantilla o un prototipo para crear objetos, por eso se dice que los objetos son instancias de clases. LENGUAJES ORIENTADOS A OBJETOS Simula (1967) es aceptado como el primer lenguaje que posee las caractersticas principales de un lenguaje orientado a objetos. Fue creado para hacer programas de simulacin, en donde los "objetos" son la representacin de la informacin ms importante. Smalltalk (1972 a 1980) es posiblemente el ejemplo cannico, y con el que gran parte de la teora de la programacin orientada a objetos se ha desarrollado. Entre los lenguajes orientados a objetos se destacan los siguientes: ABAP, ABL Lenguaje de programacin de OpenEdge de Progress Software,ActionScript, ActionScript 3, Ada, C++, C#,Clarion, Clipper (lenguaje de programacin) (Versin 5.x con librera de objetos Class(y)), D, Object Pascal (Delphi), Gambas, Harbour,Eiffel,Java, JavaScript (la herencia se realiza por medio de la programacin basada en prototipos), Lexico (en castellano), Objective-C, Ocaml, Oz, R, Perl (soporta herencia mltiple. La resolucin se realiza en preorden, pero puede modificarse al algoritmo linearization C3 por medio del mdulo Class::C3 en CPAN), PHP (a partir de su versin 5),PowerBuilder, Python, Ruby, Smalltalk (Proyecto investigativo. Influenci a Java.), Magik (SmallWorld),Vala, VB.NET,Visual FoxPro (en su versin 6), Visual Basic 6.0, Visual Objects, XBase++, Lenguaje DRP, Lenguaje de programacin Scala (lenguaje usado por Twitter). Muchos de estos lenguajes de programacin no son puramente orientados a objetos, sino que son hbridos que combinan la POO con otros paradigmas. Al igual que C++ otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object REXX, han sido creados aadiendo extensiones orientadas a objetos a un lenguaje de programacin clsico. Un nuevo paso en la abstraccin de paradigmas de programacin es la Programacin Orientada a Aspectos (POA). Aunque es todava una metodologa en estado de maduracin, cada vez atrae a ms investigadores e incluso proyectos comerciales en todo el mundo Virtual finite state machine (VFSM) desde 1990s Dynamic Systems Development Method desarrollado en UK desde 1995. Scrum (desarrollo), en la ltima parte de los 90's

RATIONAL UNIFIED PROCESS (RUP) DESDE 1999. Proceso Unificado de Rational El Proceso Racional Unificado (RationalUnifiedProcess en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el RationalMethodComposer (RMC), que permite la personalizacin de acuerdo con las necesidades. Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el RationalUnifiedProcess, que se vendiera como producto independiente. Contenido 1 Principios de desarrollo 1.1 Adaptar el proceso 1.2 Equilibrar prioridades 1.3 Demostrar valor iterativamente 1.4 Colaboracin entre equipos 1.5 Elevar el nivel de abstraccin 1.6 Enfocarse en la calidad 2 Ciclo de vida 3 Principales caractersticas 4 Fases 5 Artefactos 6 Un poco de historia 7 Comentarios sobre Alcance del RUP 8 Comentarios sobre Metodologa

9 Enlaces externos Principios de desarrollo El RUP est basado en 6 PRINCIPIOS CLAVE que son los siguientes: ADAPTAR EL PROCESO El proceso deber adaptarse a las necesidades del cliente ya que es muy importante interactuar con l. Las caractersticas propias del proyecto u organizacin. El tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal. EQUILIBRAR PRIORIDADES Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro. DEMOSTRAR VALOR ITERATIVAMENTE Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados

COLABORACIN ENTRE EQUIPOS El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc. ELEVAR EL NIVEL DE ABSTRACCIN Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.

ENFOCARSE EN LA CALIDAD El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente. CICLO DE VIDA Esfuerzo en actividades segn fase del proyecto. El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. 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. 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. PRINCIPALES CARACTERSTICAS Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo, Administracin de requisitos, Uso de arquitectura basada en componentes Control de cambios, Modelado visual del software, Verificacin de la calidad del software El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso). FASES Establece oportunidad y alcance, Identifica las entidades externas o actores con las que se trata Identifica los casos de uso, RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: 'PROCESO': Las etapas de esta seccin son: (Revise nuevamente la grfica), Modelado de negocio, Requisitos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue SOPORTE: En esta parte nos encontramos con las siguientes etapas: Gestin del cambio y configuraciones, Gestin del proyecto, Entorno La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente: INICIO(Tambin llamado Incepcin o Concepcin) ELABORACIN DESARROLLO(Tambin llamado Implementacin, Construccin) CIERRE(Tambin llamado Transicin) Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.

Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto. ARTEFACTOS RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los siguientes: INICIO: Documento Visin Especificacin de Requisitos ELABORACIN: Diagramas de caso de uso CONSTRUCCIN: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica Diagrama de clases, Modelo E-R (Si el sistema as lo requiere),Vista de Implementacin Diagrama de Secuencia, Diagrama de estados, Diagrama de Colaboracin, Vista Conceptual Modelo de dominio, Vista fsica Mapa de comportamiento a nivel de hardware. UN POCO DE HISTORIA Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software compr una compaa sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los mtodos de desarrollo orientados a objetos. El RationalUnifiedProcess fue el resultado de una convergencia de RationalApproach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el RationalObjectoryProcess, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe PhilippeKruchten.

COMENTARIOS SOBRE ALCANCE DEL RUP La metodologa RUP es ms apropiada para proyectos grandes (Aunque tambin pequeos), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios. NUEVO MILENIO Extreme Programming(XP) desde 1999 Enterprise Unified Process (EUP) extensiones RUP desde 2002 Constructionist design methodology (CDM) desde 2004 porKristinn R. Thrisson Agile Unified Process (AUP) desde 2005 por Scott Ambler ENFOQUES DE DESARROLLO DE SOFTWARE Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software. Estos son los enfoques ms generales, que se desarrollan en varias metodologas especficas. Estos enfoques son los siguientes:1 Modelo en cascada: Framework lineal. Prototipado: Framework iterativo. Incremental: Combinacin de framework lineal e iterativo. Espiral: Combinacin de framework lineal e iterativo. RAD: Rapid Application Development, framework iterativo.

MODELO EN CASCADA Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a travs de las fases de anlisis de las necesidades, el diseo, implementacin, pruebas (validacin), la integracin, y mantenimiento. La primera descripcin formal del modelo de cascada se cita a menudo a un artculo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el trmino "cascada" de este artculo.

Los PRINCIPIOS BSICOS del modelo de cascada son los siguientes:1

El proyecto est dividido en fases secuenciales, con cierta superposicin y splashback aceptable entre fases. Se hace hincapi en la planificacin, los horarios, fechas, presupuestos y ejecucin de todo un sistema de una sola vez. Un estricto control se mantiene durante la vida del proyecto a travs de la utilizacin de una amplia documentacin escrita, as como a travs de comentarios y aprobacin / signoff por el usuario y la tecnologa de la informacin de gestin al final de la mayora de las fases antes de comenzar la prxima fase. PROTOTIPADO El prototipado es el framework de actividades dedicada al desarrollo de software prototipo, es decir, versiones incompletas del software a desarrollar. INCREMENTAL Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro. Los PRINCIPIOS BSICOS son: Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequea parte de los sistemas, antes de proceder a la prxima incremental Se definen los requisitos antes de proceder con la evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema El concepto inicial de software, anlisis de las necesidades, y el diseo de la arquitectura y colectiva bsicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalacin del prototipo final. ESPIRAL Los PRINCIPIOS BSICOSson: La atencin se centra en la evaluacin y reduccin del riesgo del proyecto dividiendo el proyecto en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideracin de la continuacin del proyecto durante todo el ciclo de vida. Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes bsicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteracin; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteracin, y (4) plan de la prxima iteracin.3

Cada ciclo comienza con la identificacin de los interesados y sus condiciones de ganancia, y termina con la revisin y examinacin.3 RAPID APPLICATION DEVELOPMENT(RAD) El desarrollo rpido de aplicaciones (RAD) es una metodologa de desarrollo de software, que implica el desarrollo iterativo y la construccin de prototipos. El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991. PRINCIPIOS BSICOS: Objetivo clave es para un rpido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversin. Intenta reducir el riesgos inherente del proyecto partindolo en segmentos ms pequeos y proporcionar ms facilidad de cambio durante el proceso de desarrollo. Orientacin dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteracin por prototipos (en cualquier etapa de desarrollo), promueve la participacin de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz grfica de usuario (GUI), ComputerAided 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 Jointapplicationdevelopment (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.

OTROS ENFOQUES DE DESARROLLO DE SOFTWARE Metodologas de desarrollo Orientado a objetos, Diseo orientado a objetos (OOD) de Grady Booch, tambin conocido como Anlisis y Diseo Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transicin, la interaccin, mdulo, y el proceso. Top-downprogramming, evolucionado en la dcada de 1970 por el investigador de IBM Harlan Mills (y NiklausWirth) en Desarrollo Estructurado. Proceso Unificado, es una metodologa de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecucin de una o ms iteraciones de desarrollo de software: creacin, elaboracin, construccin, y las directrices. Hay una serie de herramientas y productos diseados para facilitar la aplicacin. Una de las versiones ms populares es la de RationalUnifiedProcess.

PROGRAMACIN EXTREMA (Redirigido desde Extreme Programming) La programacin extrema o eXtremeProgramming (XP) es un enfoque de la ingeniera de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme ProgrammingExplained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos. Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software. CONTENIDO 1 VALORES 2 CARACTERSTICAS FUNDAMENTALES 3 VASE TAMBIN 4 ENLACES EXTERNOS 1.-VALORES

Los Valores originales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor, respeto, fue aadido en la segunda edicin de Extreme ProgrammingExplained. Los cinco valores se detallan a continuacin: SIMPLICIDAD: La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo simple a medida que crece. Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo debe comentarse en su justa medida, intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, mtodos y clases. Los nombres largos no decrementan la eficiencia del cdigo ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorizacin que existen actualmente. Aplicando la simplicidad junto con la autora colectiva del cdigo y la programacin por parejas se asegura que cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el sistema completo. COMUNICACIN: La comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado. Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un mtodo. Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases y los mtodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que caractersticas tienen prioridad y siempre debe estar disponible para solucionar dudas. RETROALIMENTACIN (feedback): Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante. Considrense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El cdigo tambin es una fuente de retroalimentacin gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el cdigo.

CORAJE O VALENTA: Los puntos anteriores parecen tener sentido comn, entonces, por qu coraje?. Para los gerentes la programacin en parejas puede ser difcil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores est escribiendo cdigo. Hay que ser valiente para confiar en que la programacin por parejas beneficia la calidad del cdigo sin repercutir negativamente en la productividad. La simplicidad es uno de los principios ms difciles de adoptar. Se requiere coraje para implementar las caractersticas que el cliente quiere ahora sin caer en la tentacin de optar por un enfoque ms flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo (frameworks) mientra el cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de desarrollo no recibe retroalimentacin para saber si va en la direccin correcta. La forma de construir marcos de trabajo es mediante la refactorizacin del cdigo en sucesivas aproximaciones. RESPETO: El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compaeros. Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, sino orientndolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de produccin en el equipo. CARACTERSTICAS FUNDAMENTALES Las caractersticas fundamentales del mtodo son: DESARROLLO ITERATIVO E INCREMENTAL: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres ltimas inspiradas en JUnit. PROGRAMACIN EN PAREJAS: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.

REFACTORIZACIN DEL CDIGO, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo. PROPIEDAD DEL CDIGO COMPARTIDA: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. SIMPLICIDAD EN EL CDIGO: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo. La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores

MSF

Virtual de la mquina de estados finitos

Figura 1: VFSM en el entorno virtual Una mquina de estados finitos virtual es una mquina de estados finitos (FSM) se define en un entorno virtual. El concepto VFSM proporciona un mtodo de especificacin de software para describir el comportamiento de un sistema de control mediante la asignacin de nombres de las propiedades del control de entrada y salida de las acciones. El mtodo VFSM introduce un modelo de ejecucin y facilita la idea de una especificacin ejecutable. Esta tecnologa se utiliza principalmente en el control del complejo de mquinas, instrumentos y aplicaciones de telecomunicaciones.

CONTENIDO Propiedades de control

Una variable en el medio ambiente VFSM puede tener uno o ms valores que son relevantes para el control - en este caso se trata de una variable de entrada. Los valores son las propiedades del control de esta variable. propiedades de control no son necesariamente los valores de datos especficos, pero son ms bien ciertos estados de la variable. Por ejemplo, una variable digital podra proporcionar tres propiedades del control: VERDADERO FALSO, y DESCONOCIDO segn sus valores booleanos posible. Un numrica (analgico) variable de entrada tiene propiedades de control tales como: baja, alta, OK, BAD, DESCONOCIDO de acuerdo con su rango de valores deseados. Un contador de tiempo puede tener su estado OVER (tiempo de espera se produjo) como su valor de control ms importantes; los dems valores se pudo detener, correr, etc..

Acciones
Una variable en el medio ambiente VFSM pueden ser activados por acciones - en este caso se trata de una variable de salida. Por ejemplo, una salida digital tiene dos acciones: Verdadero y Falso. Un numrica (analgico) variable de salida tiene una accin: Set. Un contador de tiempo que es a la vez: una entrada y una variable de salida puede ser provocada por acciones como: Inicio, Detener o Reiniciar.

Entorno Virtual
El entorno virtual caracteriza el entorno en el que un VFSM opera. Se define por tres conjuntos de nombres:
y y y

nombres de entrada, representada por las propiedades del control de todas las variables disponibles nombres de salida, representada por todas las acciones disponibles en las variables nombres de estado, tal como se define para cada uno de los estados de los Estados Federados de Micronesia.

Los nombres de entrada de crear condiciones virtual para realizar las transiciones de estado o las acciones de entrada. Las condiciones virtuales se construyen utilizando el lgebra de la lgica positiva. Los nombres de salida de disparador de acciones (acciones de entrada, salida de las acciones, las acciones de entrada o de acciones de transicin).

Positivo lgebra Lgica

Para construir un estado virtual utilizando los nombres de las operaciones de entrada el booleano AND y OR se admiten. El operador NOT no es posible porque los nombres de

entrada no se puede negar, incluso cuando aparentemente describen valores booleanos. Simplemente existe o no.

Modelo de Ejecucin VFSM

Figura 2: Diagrama de flujo Ejecutor VFSM Un subconjunto de todos los nombres definidos de entrada, que slo puede existir en una determinada situacin, se llama entrada virtual (VI). Por ejemplo, la temperatura puede ser "demasiado bajo", "buena" o "muy alto". Aunque hay tres nombres definidos de entrada, slo una de ellas puede existir en una situacin real. Esta se construye el VI. Un subconjunto de todos los nombres de salida definida, que slo puede existir en una determinada situacin se llama salida virtual (VO). VO es construido por la accin en curso (s) de la VFSM. La especificacin de comportamiento es construida por una tabla de estado que describe todos los detalles de un solo estado de la VFSM. El ejecutor VFSM se desencadena por VI y el estado actual de la VFSM. En consideracin de la especificacin el comportamiento de la situacin actual, el VO se establece. La figura 2 muestra una posible implementacin de un ejecutor VFSM. A partir de esta aplicacin las caractersticas de una conducta tpica debe ser considerado.

Tabla de estado
pgina principal: tabla de estado de transicin .

Una tabla de estado define todos los detalles del comportamiento de un estado de un VFSM. Se compone de tres columnas: en la primera columna los nombres de estado se utilizan, en el segundo las condiciones virtual construido con los nombres de entrada usando el lgebra de la lgica positiva y se colocan en la tercera columna aparecen los nombres de salida: Nombre del Estado Estado actual Estado (s) Entrada accin Salir de la accin Virtual condicin ... nombre del estado Siguiente nombre del estado Siguiente ... Virtual condicin Virtual condicin ... Acciones (s) nombre de salida (s) nombre de salida (s) nombre de salida (s) ... nombre de salida (s) nombre de salida (s) ...

Lea la tabla de la siguiente manera: las dos primeras lneas definen las acciones de entrada y salida de la situacin actual. Las siguientes lneas que no proporcionan el siguiente estado representan las acciones de entrada. Por ltimo, la lneas que proporcionan el siguiente estado representan las condiciones de transicin de estados y acciones de transicin. Todos los campos son opcionales. Un VFSM pura combinatoria es posible en el caso slo cuando las acciones de que se utilicen, pero no las transiciones de estado se define. La accin de transicin puede ser sustituido por el uso adecuado de otras acciones.

Herramientas

StateWORKS
StateWORKS es el nico mtodo de ingeniera de software que utiliza prcticas de diseo como el sonido como los utilizados para ingeniero de hardware, puentes y aviones: StateWORKS elimina la codificacin de software y realmente pone la "ingeniera" de nuevo en el software!StateWORKS podra muy bien ser el software de SilverBullet . Con StateWORKS, su equipo de software aumentar su productividad, con una reduccin drstica del tiempo de desarrollo y la entrega a tiempo, todo el tiempo. StateWORKS ha existido por varios aos, es muy fiable y ha sido aplicado con xito a una amplia variedad de proyectos , y en particular en sistemas altamente complejos: los sistemas integrados, telecomunicaciones, medicin , etc. aplicaciones StateWORKS generados se ejecutan en Windows, Linux y cualquier otro sistema operativo, de hecho, incluso se puede ejecutar en pequeos microprocesadores.

Qu es StateWORKS
StateWORKS es un mtodo completo , desde el desarrollo a tiempo de ejecucin, para la creacin de software de alta calidad a travs de modelos: el comportamiento del software se expresa como un sistema de mquinas de estados finitos . Muy grandes sistemas complejos pueden ser manejados, mediante el uso de muchas mquinas del Estado en una estructura jerrquica, la complejidad es completamente gestionado, de hecho, los niveles ms altos de la jerarqua constituye un pliego de condiciones del proyecto que es suficientemente claro como para ser discutido con la gerencia, la comercializacin o clientes. StateWORKSherramientas, incluyendo el modo de mltiples editores , permiten a los ingenieros de expresar los requisitos de aplicacin tan completamente, y en detalle tal, que el ejecutable de la aplicacin se puede generar sin escribir cdigo. Por casi eliminar la codificacin y depuracin, StateWORKS trae aumentos fenomenales de la productividad y reduce drsticamente el tiempo de desarrollo. Los insectos son eliminados en el proceso de diseo, no deja a la "prueba" o fase de "mantenimiento". Las aplicaciones desarrolladas con StateWORKS estn bien documentadas y fciles de mantener. StateWORKS archivos ejecutables son rpidos y eficientes. Usted StateWORKS vincular archivos ejecutables con nuestras bibliotecas y ejecutar la aplicacin en cualquier sistema operativo o el procesador. StateWORKS se describe con gran detalle en el libro "Modelado de software con Finito Mquinas de Estado: Un enfoque prctico"

StateWORKS: Ventajas
Algunas de las ventajas para los programadores de software de ingeniera con StateWORKS son:
y y y y y y y y

Software desarrollado con StateWORKS es rpido, bien documentado, fcil de leer y de mantener. Al iniciar un proyecto, las especificaciones StateWORKS son fciles de comprobar con su cliente! Al entregar la documentacin se genera automticamente. No hay necesidad de gastar el tiempo de depuracin, y sus clientes nunca se libera buggy temprana. Las nuevas caractersticas o cambios se pueden agregar sin dolor, porque no hay cdigo obtiene ajustado (no hay ningn cdigo!). especificaciones StateWORKS son infinitamente ms fcil de leer que el cdigo C o UML. StateWORKS permite a sus ingenieros para crear una verdadera columna vertebral de arquitectura para su aplicacin. StateWORKS es fcil de aprender.