METODOLOGÍA DE DESARROLLO DE SOFTWARE

Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información.1

Tres patrones básicos en las metodologías de desarrollo de software.

1 INTRODUCCIÓN

2 HISTORIA

3 METODOLOGÍAS 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

INTRODUCCIÓN

Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.

A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.

El FRAMEWORK para metodología de desarrollo de software consiste en:

Una filosofía de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software.

Herramientas, modelos y métodos para asistir al proceso de desarrollo de software

Estos frameworks son a menudo vinculados a algún tipo de organización, que además desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo documentada en algún tipo

de documentación formal.

HISTORIA

El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década 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 información en una muy deliberada, estructurada y metódica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de información en torno a las actividades resueltas pesadas para el

procesamiento de datos y rutinas de cálculo.

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

1970s

Programación estructurada sol desde 1969

Programación estructurada Jackson desde 1975

1980s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980

Structured Analysis and Design Technique (SADT) desde 1980

Ingeniería de la información (IE/IEM) desde 1981

1990s

Rapid application development (RAD) desde 1991. Desarrollo rápido de aplicaciones

El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Delphi, Foxpro , Anjuta,

PROGRAMACIÓN ORIENTADA A OBJETOS (OOP) a lo largo de la década de los 90's

Programación orientada a objetos

La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.

Contenido

1 Introducción

2 Origen

3 Conceptos fundamentales

4 Características de la POO

5 Resumen

6 Lenguajes orientados a objetos

7 Enlaces externos

INTRODUCCIÓN

Los objetos son entidades que combinan estado (atributo), comportamiento (método) e identidad:

El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).

El comportamiento está definido por los procedimientos o métodos 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 análogo al de identificador de una variable o una constante).

Un objeto contiene toda la información 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 interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos 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 podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

ORIGEN

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían 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 más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.

La programación orientada a objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.

Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características 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 aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha modificado, soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

CONCEPTOS FUNDAMENTALES

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

CLASE: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación 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 métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.

OBJETO: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) 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.

MÉTODO: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

EVENTO: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al

objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.

MENSAJE: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros 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 características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método 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 métodos.

Identificación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

CARACTERÍSTICAS DE LA POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las características siguientes son las más importantes:

Abstracción: denota las características 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 cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño 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 abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos 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 abstracción. La aplicación 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 invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. 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 común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.

Recolección de basura: la recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, 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 asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.

RESUMEN

La programación orientada a objetos es un paradigma que utiliza objetos como elementos fundamentales en la construcción de la solución. Surge en los años 70. Un objeto es una abstracción de algún hecho o ente del mundo real que tiene atributos que representan sus características o propiedades y métodos que representan su comportamiento o acciones que realizan. Todas las propiedades y métodos 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 características principales de un lenguaje orientado a objetos. Fue creado para hacer programas de simulación, en donde los "objetos" son la representación de la información más importante. Smalltalk (1972 a 1980) es posiblemente el ejemplo canónico, y con el que gran parte de la teoría de la programación orientada a objetos se ha desarrollado.

Entre los lenguajes orientados a objetos se destacan los siguientes:

ABAP, ABL Lenguaje de programación de OpenEdge de Progress Software, ActionScript, ActionScript 3, Ada, C++, C#, Clarion, Clipper (lenguaje de programación) (Versión 5.x con librería de objetos Class(y)), D, Object Pascal (Delphi), Gambas, Harbour, Eiffel,Java, JavaScript (la herencia se realiza por medio de la programación basada en prototipos), Lexico (en castellano), Objective-C, Ocaml, Oz, R, Perl (soporta herencia múltiple. La resolución se realiza en preorden, pero puede modificarse al algoritmo linearization C3 por medio del módulo Class::C3 en CPAN), PHP (a partir de su versión 5), PowerBuilder, Python, Ruby, Smalltalk (Proyecto investigativo. Influenció a Java.), Magik (SmallWorld), Vala, VB.NET,Visual FoxPro (en su versión 6), Visual Basic 6.0, Visual Objects, XBase++, Lenguaje DRP, Lenguaje de programación Scala (lenguaje usado por Twitter).

Muchos de estos lenguajes de programación no son puramente orientados a objetos, sino que son híbridos que combinan la POO con otros paradigmas.

Al igual que C++ otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object REXX, han sido creados añadiendo extensiones orientadas a objetos a un lenguaje de programación clásico.

Un nuevo paso en la abstracción de paradigmas de programación es la Programación Orientada a Aspectos (POA). Aunque es todavía una metodología en estado de maduración, cada vez atrae a más 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 (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, 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 Colaboración entre equipos

1.5 Elevar el nivel de abstracción

1.6 Enfocarse en la calidad

2 Ciclo de vida

3 Principales características

4 Fases

5 Artefactos

6 Un poco de historia

7 Comentarios sobre Alcance del RUP

8 Comentarios sobre Metodología

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 características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También 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 podrán 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 iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados

COLABORACIÓN ENTRE EQUIPOS

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

ELEVAR EL NIVEL DE ABSTRACCIÓN

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón 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 codificación 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 reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar 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 iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

CICLO DE VIDA

Esfuerzo en actividades según fase del proyecto.

El ciclo de vida RUP es una implementación 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 número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea 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 elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición 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 varía.

PRINCIPALES CARACTERÍSTICAS

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

Pretende implementar las mejores prácticas en Ingeniería de Software

Desarrollo iterativo, Administración de requisitos, Uso de arquitectura basada en componentes

Control de cambios, Modelado visual del software, Verificación 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 código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar 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 sección son: (Revise nuevamente la gráfica), Modelado de negocio, Requisitos, Análisis y Diseño, Implementación, Pruebas, Despliegue

SOPORTE: En esta parte nos encontramos con las siguientes etapas:

Gestión del cambio y configuraciones, Gestión del proyecto, Entorno

La estructura dinámica 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(También llamado Incepción o Concepción)

ELABORACIÓN

DESARROLLO(También llamado Implementación, Construcción)

CIERRE (También llamado Transición)

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

Fase de Desarrollo: El propósito 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 propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico 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 estática) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

INICIO:

Documento Visión

Especificación de Requisitos

ELABORACIÓN:

Diagramas de caso de uso

CONSTRUCCIÓN:

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica Diagrama de clases, Modelo E-R (Si el sistema así lo requiere),Vista de Implementación Diagrama de Secuencia, Diagrama de estados, Diagrama de Colaboración, Vista Conceptual Modelo de dominio, Vista física Mapa de comportamiento a nivel de hardware.

UN POCO DE HISTORIA

Los orígenes 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 investigación. En 1995 Rational Software compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten.

COMENTARIOS SOBRE ALCANCE DEL RUP

La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación 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 por Kristinn R. Thórisson

Agile Unified Process (AUP) desde 2005 por Scott Ambler

ENFOQUES DE DESARROLLO DE SOFTWARE

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias

metodologías específicas. Estos enfoques son los siguientes:1

Modelo en cascada: Framework lineal.

Prototipado: Framework iterativo.

Incremental: Combinación de framework lineal e iterativo.

Espiral: Combinación 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 través de las fases de análisis de las necesidades, el diseño,

implementación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W.2 en

1970, aunque Royce no utiliza el término "cascada" de este artículo.

Los PRINCIPIOS BÁSICOS del modelo de cascada son los siguientes:1

El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.

Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.

Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff por el usuario y la tecnología de la información de gestión al final de la mayoría de las fases antes de

comenzar la próxima 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 BÁSICOS 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 pequeña parte de los sistemas, antes de proceder a la

próxima 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, análisis de las necesidades, y el diseño de la arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos,

que culmina en la instalación del prototipo final.

ESPIRAL

Los PRINCIPIOS BÁSICOS son:

La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de

desarrollo, así como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideración de la continuación del proyecto durante todo el ciclo de vida.

Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteración; (2) Evaluar alternativas; Identificar y resolver los

riesgos; (3) desarrollar y verificar los resultados de la iteración, y (4) plan de la próxima iteración.3

Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia, y termina con la revisión y examinación.3

RAPID APPLICATION DEVELOPMENT (RAD)

El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo iterativo y la construcción de prototipos. El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.

PRINCIPIOS BÁSICOS:

Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión.

Intenta reducir el riesgos inherente del proyecto partiéndolo en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.

Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promueve la participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), Computer Aided Software Engineering

(CASE) las herramientas, los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos.

Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o la excelencia es de menor importancia.

Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no

en el aumento de la fecha límite.

En general incluye Joint application development (JAD), donde los usuarios están intensamente participando en el diseño del sistema, ya sea a través de la creación de consenso estructurado en

talleres, o por vía electrónica.

La participación activa de los usuarios es imprescindible.

Iterativamente realiza la producción de software, en lugar de enfocarse en un prototipo.

Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.

OTROS ENFOQUES DE DESARROLLO DE SOFTWARE

Metodologías de desarrollo Orientado a objetos, Diseño orientado a objetos (OOD) de Grady Booch, también conocido como Análisis y Diseño Orientado a Objetos (OOAD). El modelo incluye

seis diagramas: de clase, objeto, estado de transición, la interacción, módulo, y el proceso.

Top-down programming, evolucionado en la década de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado.

Proceso Unificado, es una metodología de desarrollo de software, basado en UML. Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecución de una o más iteraciones de desarrollo de software: creación, elaboración, construcción, y las directrices. Hay una serie de

herramientas y productos diseñados para facilitar la aplicación. Una de las versiones más populares es la de Rational Unified Process.

PROGRAMACIÓN EXTREMA

(Redirigido desde Extreme Programming)

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más é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 aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

CONTENIDO

1 VALORES

2 CARACTERÍSTICAS FUNDAMENTALES

3 VÉASE TAMBIÉN

4 ENLACES EXTERNOS

1.- VALORES

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:

SIMPLICIDAD:

La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.

COMUNICACIÓN:

La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que características tienen prioridad y siempre debe estar disponible para solucionar dudas.

RETROALIMENTACIÓN (feedback):

Al estar el cliente integrado en el proyecto, su opinión 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 más importante. Considérense 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 código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.

CORAJE O VALENTÍA:

Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?. Para los gerentes la programación en parejas puede ser difícil 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 código. Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad. La simplicidad es uno de los principios más difíciles de adoptar. Se requiere coraje para implementar las características que el cliente quiere ahora sin caer en la tentación de optar por un enfoque más 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 retroalimentación para saber si va en la dirección correcta. La forma de construir marcos de trabajo es mediante la refactorización del código 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 compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, sino orientándolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.

CARACTERÍSTICAS FUNDAMENTALES

Las características fundamentales del método son:

DESARROLLO ITERATIVO E INCREMENTAL: pequeñas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, 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.

PROGRAMACIÓN 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 código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.

Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

REFACTORIZACIÓN DEL CÓDIGO, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.

PROPIEDAD DEL CÓDIGO COMPARTIDA: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

SIMPLICIDAD EN EL CÓDIGO: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores

MSF

Virtual de la máquina de estados finitos

Figura 1: VFSM en el entorno virtual

Una máquina de estados finitos virtual es una máquina de estados finitos (FSM) se define en un entorno virtual. El concepto VFSM proporciona un método de especificación de software para describir el comportamiento de un sistema de control mediante la asignación de nombres de las propiedades del control de entrada y salida de las acciones.

El método VFSM introduce un modelo de ejecución y facilita la idea de una especificación ejecutable. Esta tecnología se utiliza principalmente en el control del complejo de máquinas, instrumentos y aplicaciones de telecomunicaciones.

CONTENIDO

Propiedades de control

Una variable en el medio ambiente VFSM puede tener uno o más 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 específicos, pero son más bien ciertos estados de la variable. Por ejemplo, una variable digital podría proporcionar tres propiedades del control: VERDADERO FALSO, y DESCONOCIDO según sus valores booleanos posible. Un numérica (analógico) 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 más importantes; los demás 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 numérica (analógico) variable de salida tiene una acción: 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:

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 lógica positiva. Los nombres de salida de disparador de acciones (acciones de entrada, salida de las acciones, las acciones de entrada o de acciones de transición).

Positivo Álgebra Lógica

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 Ejecución VFSM

Figura 2: Diagrama de flujo Ejecutor VFSM

Un subconjunto de todos los nombres definidos de entrada, que sólo puede existir en una determinada situación, se llama entrada virtual (VI). Por ejemplo, la temperatura puede ser "demasiado bajo", "buena" o "muy alto". Aunque hay tres nombres definidos de entrada, sólo una de ellas puede existir en una situación real. Esta se construye el VI.

Un subconjunto de todos los nombres de salida definida, que sólo puede existir en una determinada situación se llama salida virtual (VO). VO es construido por la acción en curso (s) de la VFSM.

La especificación 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 consideración de la especificación el comportamiento de la situación actual, el VO se establece.

La figura 2 muestra una posible implementación de un ejecutor VFSM. A partir de esta aplicación las características de una conducta típica debe ser considerado.

Tabla de estado

página principal: tabla de estado de transición .

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 lógica positiva y se colocan en la tercera columna aparecen los nombres de salida:

Nombre del Estado Estado (s) Acciones (s)

Estado actual Entrada acción nombre de salida (s)

Salir de la acción nombre de salida (s)

Virtual condición nombre de salida (s)

... ...

nombre del estado Siguiente Virtual condición nombre de salida (s)

nombre del estado Siguiente Virtual condición nombre de salida (s)

... ... ...

Lea la tabla de la siguiente manera: las dos primeras líneas definen las acciones de entrada y salida de la situación actual. Las siguientes líneas que no proporcionan el siguiente estado representan las acciones de entrada. Por último, la líneas que proporcionan el siguiente estado representan las condiciones de transición de estados y acciones de transición. Todos los campos son opcionales. Un VFSM pura combinatoria es posible en el caso sólo cuando las acciones de que se utilicen, pero no las transiciones de estado se define. La acción de transición puede ser sustituido por el uso adecuado de otras acciones.

Herramientas

StateWORKS StateWORKS is the only Software Engineering method that uses design practices as sound as those used to engineer hardware, bridges and airplanes: StateWORKS takes the coding out of software and truly puts the "engineering" back in software! StateWORKS es el único método de ingeniería de software que utiliza prácticas de diseño como el sonido como los utilizados para ingeniero de hardware, puentes y aviones: StateWORKS elimina la codificación de software y realmente pone la "ingeniería" de nuevo en el software! StateWORKS could very well be software's . StateWORKS podría muy bien ser el software de Silver Bullet .

With StateWORKS, your software team will increase its productivity, with dramatic reductions in development time and on-time delivery, every time. Con StateWORKS, su equipo de software aumentar su productividad, con una reducción drástica del tiempo de desarrollo y la entrega a tiempo, todo el tiempo.

StateWORKS has been around for several years, is extremely reliable and has been applied successfully to a , and particularly in highly complex systems: , etc.. StateWORKS ha

existido por varios años, 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, medición , etc. StateWORKS-generated applications run on Windows, Linux and any other operating system, in fact they can even run on small microprocessors. aplicaciones StateWORKS generados se ejecutan en Windows, Linux y cualquier otro sistema operativo, de hecho, incluso se puede ejecutar en pequeños microprocesadores.

What is StateWORKS ¿Qué es StateWORKS

StateWORKS is a , from development to runtime, for creating high-quality software through models: software behaviour is expressed as a system of . StateWORKS es un método completo , desde el desarrollo a tiempo de ejecución, para la creación de software de alta calidad a través de modelos: el comportamiento del software se expresa como un sistema de máquinas de estados finitos . Very large complex systems can be handled, by using many state machines in a hierarchical structure; the complexity is fully managed, in fact the top levels of the hierarchy constitute a specification of the project that is clear enough to be discussed with management, marketing or customers. Muy grandes sistemas complejos pueden ser manejados, mediante el uso de muchas máquinas del Estado en una estructura jerárquica, la complejidad es completamente gestionado, de hecho, los niveles más altos de la jerarquía constituye un pliego de condiciones del proyecto que es suficientemente claro como para ser discutido con la gerencia, la comercialización o clientes.

StateWORKS , allow engineers to express application requirements so completely, and in such fine detail, that the executable application can be generated without any code writing. StateWORKS herramientas, incluyendo el modo de múltiples editores , permiten a los ingenieros de expresar los requisitos de aplicación tan completamente, y en detalle tal, que el ejecutable de la aplicación se puede generar sin escribir código. By almost eliminating coding and debugging, StateWORKS brings phenomenal increases in productivity and dramatically reduced development time. Por casi eliminar la codificación y depuración, StateWORKS trae aumentos fenomenales de la productividad y reduce drásticamente el tiempo de desarrollo. Bugs are eliminated in the design process, not left to the "testing" or "maintenance" phase. Los insectos son eliminados en el proceso de diseño, no deja a la "prueba" o fase de "mantenimiento". Applications developed with StateWORKS are well documented and maintainable. Las aplicaciones desarrolladas con StateWORKS están bien documentadas y fáciles de mantener.

StateWORKS executable files are fast and efficient. StateWORKS archivos ejecutables son rápidos y eficientes. You link StateWORKS executable files with our libraries and run the application on any OS or processor. Usted StateWORKS vincular archivos ejecutables con nuestras bibliotecas y ejecutar la aplicación en cualquier sistema operativo o el procesador. StateWORKS is described in great detail in the book StateWORKS se describe con gran detalle en el libro "Modelado de software con Finito Máquinas de Estado: Un enfoque práctico"

StateWORKS Advantages StateWORKS: Ventajas Algunas de las ventajas para los programadores de software de ingeniería con StateWORKS son:

Software desarrollado con StateWORKS es rápido, bien documentado, fácil de leer y de mantener.

Al iniciar un proyecto, las especificaciones StateWORKS son fáciles de comprobar con su cliente!

Al entregar la documentación se genera automáticamente. No hay necesidad de gastar el tiempo de depuración, y sus clientes nunca se libera

buggy temprana. Las nuevas características o cambios se pueden agregar sin dolor, porque no hay

código obtiene ajustado (no hay ningún código!). especificaciones StateWORKS son infinitamente más fácil de leer que el código C

o UML. StateWORKS permite a sus ingenieros para crear una verdadera columna vertebral

de arquitectura para su aplicación. StateWORKS es fácil de aprender.