Proceso unificado– este es un marco generalizado del proceso de creación de software, que puede ser especializado en una amplia gama de sistemas de software. El proceso unificado utiliza un lenguaje de modelado unificado para desarrollar un modelo de un sistema de software.

Empiece a atacar los riesgos principales, condúzcalo continuamente, de lo contrario los riesgos lo atacarán a usted.

Asegúrese de que se cumplan los requisitos del cliente: documente los requisitos de una manera que el cliente pueda entender y cumpla estrictamente con estos requisitos durante el diseño y la implementación.

Concéntrate en el programa que tienes entre manos: ejecutar software pasar pruebas mejor que una documentación completa

Adaptarse a los cambios desde el principio del proyecto: las aplicaciones modernas son lo suficientemente complejas como para que podamos obtener requisitos específicos desde el principio del desarrollo. Por lo tanto, es necesario diseñar la arquitectura del software de tal manera que sea susceptible de cambios.

sentar las bases de una arquitectura ejecutable lo antes posible. Arquitectura ejecutable: casos de uso clave. El VI clave es la funcionalidad del sistema, sin la cual el software no tiene sentido. Llave. Los VI representan entre el 7% y el 10% de todas las opciones

construir un sistema a partir de componentes. Las aplicaciones basadas en componentes se crean más rápido, son más flexibles en términos de cambios y tienen un costo relativamente bajo.

trabajar como 1 equipo

hacer de la calidad una forma de vida, no una idea de último momento

6 Ciclo de vida de un proceso unificado. Los objetivos de cada etapa.

El proceso unificado se repite cíclicamente. Esta secuencia de iteraciones del Proceso Unificado representa el ciclo de vida del sistema. Cada ciclo finaliza con la entrega del lanzamiento del producto a los clientes.

Cada ciclo consta de cuatro fases: análisis y planificación de requisitos, diseño, construcción e implementación. Cada fase, como se analiza a continuación, se subdivide en iteraciones.

Durante fases de análisis y planificación requisitos buena idea se convierte en un concepto para un producto terminado y se crea un plan de negocios para el desarrollo de este producto. En particular, en esta fase se deben responder las siguientes preguntas:

¿Qué debería hacer primero el sistema por sus usuarios principales?

¿Cómo debería ser la arquitectura del sistema?

¿Cuál es el plan y cuánto costará desarrollar el producto?

En esta etapa, se crea una versión de prueba de la arquitectura. Suele ser un esquema que contiene los subsistemas más importantes. Durante esta fase, se identifican y priorizan los riesgos más importantes, se planifica en detalle la fase de diseño y se estima aproximadamente el proyecto general.

Durante fases de diseño la mayoría de los casos de uso se describen en detalle y se desarrolla la arquitectura del sistema.

Al final de la fase de diseño, el director del proyecto participa en la planificación de actividades y el cálculo de los recursos necesarios para completar el proyecto. La pregunta clave en este punto será: ¿los casos de uso, la arquitectura y el diseño están lo suficientemente maduros y los riesgos están lo suficientemente bajo control como para garantizar un compromiso contractual para completar el trabajo de desarrollo?

Durante fases de construcción se está creando un producto: se agregan músculos (programas completados) al esqueleto (arquitectura). Durante esta fase, el nivel básico de arquitectura crece hasta convertirse en un sistema maduro completo. Los conceptos se desarrollan en un producto listo para ser entregado a los usuarios. Durante la fase, la cantidad de recursos necesarios aumenta. Al final de esta fase, el producto incluye todos los casos de uso que la administración y el cliente acordaron incluir en la versión actual. Es cierto que pueden contener errores. La mayoría de los defectos serán descubiertos y corregidos durante la fase de implementación. La pregunta clave al final de la fase es: ¿Satisface el producto los requisitos del usuario hasta el punto de que se pueda entregar previamente a algunos clientes?

Fase de implementación cubre el período durante el cual el producto existe como versión beta o versión beta. Un pequeño número de usuarios calificados que trabajan con la versión beta del producto informan defectos y deficiencias. Luego, los desarrolladores corrigen los errores que encuentran e incorporan algunas de las mejoras sugeridas en una versión principal que está lista para una amplia distribución. La fase de implementación incluye actividades como la producción de copias, la formación de los empleados del cliente, la organización de una línea directa de soporte y la corrección de defectos descubiertos después de la entrega.

Proceso unificado racional (RUP)- metodología de desarrollo software, creado por racional Software.

Principios: Identificación temprana y eliminación continua (hasta el final del proyecto) de los principales riesgos. Concentración en cumplir con los requisitos del cliente para el programa ejecutable (análisis y construcción de un modelo de precedentes (casos de uso)). Espere cambios en los requisitos, las decisiones de diseño y la implementación durante el proceso de desarrollo. Arquitectura de componentes implementada y probada al principio del proyecto. Aseguramiento continuo de la calidad en todas las etapas del desarrollo del proyecto (producto).

Trabajando en un proyecto en un equipo muy unido, en el que los arquitectos juegan un papel clave.

Usos de RUP modelo de desarrollo iterativo. Al final de cada iteración (idealmente con una duración de 2 a 6 semanas), el equipo del proyecto debe lograr los objetivos planificados para esta iteración, crear o perfeccionar artefactos de diseño y obtener una versión intermedia pero funcional del producto final.

El ciclo de vida completo del desarrollo del producto consiste en cuatro fases, cada una de las cuales incluye una o más iteraciones: la fase inicial, la fase de clarificación, diseño e implementación.

Programación extrema (XP)

Programación extrema(Programación extrema, XP): una de las metodologías flexibles de desarrollo de software.

12 técnicas básicas La programación extrema (según la primera edición del libro Explicación de la programación extrema) se puede combinar en cuatro grupos:

Ciclo corto comentario: (Desarrollo basado en pruebas, el juego de planificación, el cliente siempre está ahí, programación en pareja

Proceso continuo en lugar de por lotes: Integración continua, refactorización, pequeños lanzamientos frecuentes.

Comprensión compartida por todos: Simplicidad, metáfora del sistema, propiedad colectiva del código o patrones de diseño seleccionados, estándar de codificación

Seguridad social de un programador: 40 horas semana de trabajo

La programación en pares implica que todo el código sea creado por pares de programadores que trabajan en la misma computadora. Propiedad colectiva significa que cada miembro del equipo es responsable de todo el código fuente. El "cliente" en XP no es el que paga las facturas, sino el que realmente utiliza el sistema.

Estándares de documentación

Los estándares garantizan la compatibilidad entre proyectos. Las normas mejoran la comprensión entre los ingenieros. Los ingenieros deben percibir las normas como algo útil para ellos, no como un conjunto de obstáculos. Los objetivos claros y mensurables que requieren un enfoque disciplinado y documentado suelen ser un buen motivador para los desarrolladores.

SVVP- El plan determina cómo y en qué secuencia se deben probar las etapas del proyecto. La verificación es el proceso de verificar que una aplicación esté construida correctamente. La validación verifica que se haya ensamblado el producto requerido.

SQAP- Plan de control de calidad del software

SCMP- Plan de gestión proyecto de software

SRS- Especificación de Requerimientos de Software

SDD- Documentación de diseño de software.

ETS- Documentación de pruebas de software

Coherencia e integridad de la documentación.

La gestión de documentos requiere importantes habilidades organizativas. Escribir documentación buena y flexible es similar a escribir código bueno y flexible.

La gestión de documentos significa mantenerlo lo completo Y consistencia y también incluye gestión de configuración.

Integridad – Disponibilidad de un conjunto de documentación que cubre el proceso de desarrollo y mantenimiento.

Consistencia significa que el conjunto de documentos no contiene contradicciones internas, el problema es que cuando este conjunto es grande, es bastante difícil evitar la aparición en él de declaraciones mutuamente excluyentes.

Soporte de configuración – es la coordinación de diferentes versiones y partes de documentación y código de programa.

RUP es un ejemplo de los llamados proceso "difícil", descrito en detalle y sugiriendo soporte para el desarrollo real del código fuente del software con una gran cantidad de acciones auxiliares. Ejemplos de tales actividades son el desarrollo de planes, tareas técnicas, numerosos modelos de diseño, documentación de diseño, etc. El objetivo principal de este proceso es separar las prácticas exitosas de desarrollo y mantenimiento de software de personas específicas que sepan cómo aplicarlas. Numerosas acciones de apoyo dan esperanza para hacerlo posible solución exitosa tareas de construcción y soporte de sistemas complejos con la ayuda de los trabajadores existentes, que no son necesariamente superprofesionales.

Para lograrlo, se realiza una descripción detallada jerárquica paso a paso de las acciones tomadas en una situación determinada, de modo que se pueda enseñar a un trabajador común y corriente a actuar de manera similar. Durante el transcurso de un proyecto, se crean muchos documentos intermedios que permiten a los desarrolladores dividir secuencialmente las tareas que enfrentan en otras más simples. Estos mismos documentos sirven para verificar la exactitud de las decisiones tomadas en cada paso, así como para rastrear el progreso general del trabajo y aclarar las estimaciones de los recursos necesarios para lograr los resultados deseados.

Programación extrema, por el contrario, representa el llamado métodos de desarrollo "en vivo" (ágiles), también llamado "luz" procesos. Hacen hincapié en el uso de buenos desarrolladores en lugar de buenos procesos de desarrollo. Los métodos de vida evitan comprometerse con planos claros que permitan una mayor flexibilidad proyecto por proyecto, y también desalientan el desarrollo de documentos adicionales que no contribuyen directamente a un programa de trabajo terminado.

Proceso racional unificado

RUP es bastante complejo y detallado. modelo de ciclo de vida iterativo POR .

Históricamente, RUP es un desarrollo del modelo de proceso de desarrollo adoptado por Ericsson en los años 70 y 80 del siglo XX. Este modelo fue creado por Ivar Jacobson, quien posteriormente, en 1987, fundó su propia empresa Objectory AB específicamente para el desarrollo. proceso tecnológico desarrollar software como un producto separado que podría transferirse a otras organizaciones. Después de que Objectory se fusionara con Rational en 1995, los desarrollos de Jacobson se integraron con el trabajo de Royce (Walker Royce, hijo del autor del libro "clásico" modelo en cascada), Kruchten (Philippe Kruchten) y Booch (Grady Booch), así como con el desarrollo paralelo lenguaje de modelado universal (lenguaje de modelado unificado, UML).

RUP se basa en tres ideas clave:

Todo el avance del trabajo está guiado por los objetivos finales del proyecto, expresados ​​​​en la forma casos de uso- escenarios de interacción del sistema de software resultante con usuarios u otros sistemas, durante los cuales los usuarios reciben resultados y servicios que son significativos para ellos. El desarrollo comienza con la identificación de casos de uso y en cada paso se controla el grado de cercanía a su implementación.

• La principal decisión tomada durante el proyecto es arquitectura el sistema de software resultante. La arquitectura establece el conjunto de componentes a partir de los cuales se construirá el software, las responsabilidades de cada componente (es decir, las subtareas que resuelve en el marco de las tareas generales del sistema), define claramente las interfaces a través de las cuales pueden interactuar, así como así como cómo los componentes interactúan entre sí.

  La arquitectura es a la vez la base para la obtención de software de calidad y la base para la planificación del trabajo y las estimaciones del proyecto en términos de tiempo y recursos necesarios para lograr determinados resultados. Viene en forma de set. modelos graficos en lenguaje UML.

• La base del proceso de desarrollo es planificado Y iteraciones guiadas, cuyo alcance (la funcionalidad implementada dentro de la iteración y el conjunto de componentes) se determina en función de la arquitectura.

Proceso unificado(ARRIBA) es un generalizado marco un proceso que puede especializarse para una amplia gama de sistemas de software, diferentes áreas de aplicación, niveles de habilidad y tamaños de proyectos.

Proceso unificado orientado a componentes. Esto significa que el sistema de software creado se basa en software. componentes, conectados por interfaces bien definidas.

Los aspectos específicos de UP residen en sus tres características:

● impulsado por casos de uso;

● tiene una orientación arquitectónica;

● es iterativo e incremental. .

Ciclo de vida del proceso unificado

El ciclo de vida de UP se divide en ciclos, cada uno de los cuales culmina con la entrega del lanzamiento de un producto. Cada ciclo de desarrollo consta de cuatro fases: análisis y planificación de requisitos, diseño, construcción e implementación. Cada fase se divide en iteraciones.

UP incluye ocho flujos de trabajo: cinco principales- definición de requisitos, análisis, diseño, implementación, pruebas y tres auxiliares (para soportar los principales) - configuración y gestión de cambios de requisitos, gestión de proyectos, gestión del entorno.

Para definir una estructura de flujo de trabajo, primero debe determinar qué tipos de artistas participar en el proceso. Entonces determinado artefactos, que debe ser creado durante un flujo de trabajo determinado por cada tipo de trabajador.

18. XP es un proceso.

Programación extrema(Inglés: Extreme Programming, XP) es una de las metodologías flexibles de desarrollo de software. Los autores de la metodología son Kent Beck, Ward Cunningham, Martin Fowler y otros.

Las doce técnicas básicas de programación extrema (según la primera edición del libro Programación extrema explicada) se pueden combinar en cuatro grupos:

1. Ciclo de retroalimentación corto (retroalimentación a escala fina)

a. Desarrollo impulsado por pruebas

b. juego de planificación

C. El cliente siempre está cerca (Todo el equipo, Cliente in situ)

d. Programación en pareja

2. Proceso continuo en lugar de por lotes

a. Integración continua

b. Refactorización (mejora del diseño, refactorización)

C. Lanzamientos pequeños frecuentes

3. Comprensión compartida por todos

a. Simplicidad (Diseño simple)

b. Comunicación

C. Respeto

d. Propiedad colectiva del código o patrones de diseño seleccionados (Propiedad colectiva de los patrones)

mi. Estándar de codificación o convenciones de codificación

4. Bienestar del programador:

a. Semana laboral de 40 horas (ritmo sostenible, semana laboral de cuarenta horas)

En XP, el proceso se divide en pasos muy pequeños en comparación con los procesos planificados. Esto da como resultado que los primeros pasos tomen días o semanas en lugar de meses o incluso años para cada paso en el modelo en cascada. Primero, se escriben pruebas automatizadas para describir los objetivos de desarrollo. Luego viene la codificación, que finaliza en el momento en que pasan todas las pruebas y los programadores no pueden idear nuevas pruebas. El diseño lo realizan las mismas personas que escriben el código. (Solo el último paso, conectar diseño y código, es común a todos los procesos ágiles). Un sistema inacabado pero en funcionamiento se muestra a un círculo reducido de usuarios (la mayoría de las veces son los propios desarrolladores). En este punto, comienzan a escribir pruebas para la siguiente parte más importante del sistema.

19. ICONIX es un proceso.

ICONIX fue desarrollado por Doug Rosenberg en Software ICONIX El proceso ICONIX se basa en casos de uso, pero no tiene muchas de sus desventajas. Este proceso también utiliza el lenguaje de modelado UML, pero sólo se utiliza la notación básica de UML: es decir, el 20% del lenguaje. El proceso ICONIX se basa en cuatro pasos principales de desarrollo de software basados ​​en casos de uso:

● modelado de dominios;

● modelado de precedentes;

● análisis de la idoneidad de los requisitos (comprobar que se cumplan todos los requisitos funcionales);

● construcción de diagramas de secuencia.

Las principales etapas del proceso son las siguientes:

● Análisis de requisitos

● Diseño preliminar

● Diseño

● Implementación

El proceso se basa en construir un número mínimo de modelos que reflejen el sistema futuro. En la etapa de análisis, se crean modelos de casos de uso, un modelo de interfaz de usuario y un modelo de entidad de dominio. Durante la fase de diseño preliminar, se crea un Diagrama de Robustez. También se complementan el modelo precedente y el modelo de entidad de dominio. Durante la fase de diseño detallado, se crea un diagrama de secuencia (SequenceDiagram) y un diagrama de clases. Durante la fase de implementación, se crea el código fuente. También puede crear un diagrama de implementación y un diagrama de componentes. Cada etapa culmina en un hito de revisión en el que los diagramas generados deben discutirse con colegas.

20. SCRUM es un proceso.

Scrum es un conjunto de principios sobre los cuales se construye el proceso de desarrollo, permitiendo períodos cortos de tiempo estrictamente fijos ( carreras de velocidad de 2 a 4 semanas) proporcionan al usuario final un software funcional con nuevas funciones que tienen la máxima prioridad. Las capacidades del software para su implementación en el siguiente sprint se determinan al comienzo del sprint en la etapa de planificación y no pueden cambiar durante toda su duración. Al mismo tiempo, la corta duración estrictamente fijada del sprint confiere previsibilidad y flexibilidad al proceso de desarrollo.

Principales roles de actuación en Scrum: ScrumMaster- el que lidera Melé se reúne y garantiza que se respeten todos los principios Melé(el rol no implica nada más que la correcta conducta del Melé-ah, el director del proyecto más bien se refiere a Dueño del producto y no debería ser ScrumMaster);Dueño del producto (Dueño del producto) - una persona que representa los intereses de los usuarios finales y otras partes interesadas en el producto; y multifuncional Equipo (Equipo Scrum), formado tanto por desarrolladores como testers, arquitectos, analistas, etc. (siendo el tamaño ideal del equipo de 7±2 personas). El equipo es el único participante plenamente involucrado en el desarrollo y es responsable del resultado en su conjunto. Nadie más que el equipo puede interferir con el proceso de desarrollo durante el sprint.

Durante cada sprint, se crea un crecimiento funcional del software. El conjunto de características que se entregan en cada sprint provienen de una etapa llamada Pila de Producto(documentación de solicitudes de trabajo) que tiene la máxima prioridad en términos del nivel de requisitos de trabajo que deben completarse. Solicitudes de trabajo ( elementos pendientes), determinado a lo largo consejo de planificación de sprint (reunión de planificación de sprint), pasan a la etapa de sprint. Durante esta reunión, el propietario del producto comunica las tareas que deben completarse. Luego, el equipo determina cuánto de lo que quieren lograr para completar las partes requeridas durante el siguiente sprint. Durante un sprint, el equipo completa una determinada lista fija de tareas (las llamadas. trabajo pendiente de sprint). Durante este período, nadie tiene derecho a modificar la lista de requisitos laborales, lo que debe entenderse como congelación de requisitos ( requisitos) durante un sprint.

Artefactos

Pila de Producto Es un documento que contiene una lista de requisitos de funcionalidad, ordenados por importancia. Una cartera de productos es una lista de lo que se debe entregar. Los elementos de esta lista se denominan "historias" ( historia del usuario) o elementos de trabajo pendiente ( elementos pendientes). El backlog del producto está abierto a la edición de todos los participantes en el proceso Scrum.

Introducción

Rational Unified Process (RUP) es una de las metodologías de desarrollo de software en espiral. La metodología cuenta con el respaldo de Rational Software y el producto se actualiza aproximadamente dos veces al año. Como lenguaje de modelado en Base común conocimiento, se utiliza el Lenguaje Unificado de Modelado (UML).

El desarrollo de software iterativo en RUP implica dividir un proyecto en varios proyectos pequeños que se llevan a cabo de forma secuencial, y cada iteración de desarrollo está claramente definida por un conjunto de objetivos que deben alcanzarse al final de la iteración. La iteración final supone que el conjunto de objetivos de la iteración debe coincidir exactamente con el conjunto de objetivos especificados por el cliente del producto, es decir, se deben cumplir todos los requisitos.

RUP está bastante bien formalizado y se presta la mayor atención a las etapas iniciales del desarrollo del proyecto: análisis y modelado. Así, esta metodología está orientada a reducir los riesgos comerciales (risk mitigating) mediante la detección de errores en las primeras etapas de desarrollo. Los riesgos técnicos se evalúan y priorizan al principio del ciclo de desarrollo y luego se revisan con el tiempo y a medida que el proyecto evoluciona a través de iteraciones posteriores. Nuevas metas aparecen en función de las prioridades de estos riesgos. Los lanzamientos de versiones se distribuyen de tal manera que los riesgos de mayor prioridad se abordan primero.

El proceso implica la evolución de modelos; una iteración del ciclo de desarrollo corresponde únicamente a una versión específica del modelo de software. Cada iteración (flujo de trabajo) contiene elementos de la gestión del ciclo de vida del software: análisis y diseño (modelado), implementación, integración, prueba, implementación. En este sentido, RUP es una implementación del modelo en espiral, aunque a menudo se representa como un gráfico de tabla. A continuación presentamos los principales componentes del proceso.

Para proceso exitoso El desarrollo requiere tres componentes (Fig. 1): un proceso, una notación y un conjunto de utilidades. Un proceso describe lo que hacemos, en qué orden y de qué manera; la notación es un medio de comunicación; un conjunto de utilidades ayuda a automatizar y gestionar el proceso.

Arroz. 1. Triángulo del éxito

RUP contiene los tres componentes. Primero, veamos las funciones de notación que hacen lo siguiente:

Realiza “pegado” el proceso en un solo todo;

Es un medio basado en el lenguaje para tomar decisiones que no son obvias en el código fuente;

Proporciona semántica para representar decisiones estratégicas y tácticas importantes;

Ofrece una forma suficiente para reflexionar y luego tomar decisiones y medios para automatizar el proceso con el fin de manipular datos formalizados.

De hecho, la notación cubre el desarrollo de software, desde el análisis hasta la implementación del producto. La notación en el caso de RUP-UML es un medio de lenguaje formal para describir un proceso (UML se analizará más adelante). A continuación, consideraremos la estructura del proceso y también proporcionaremos un conjunto de utilidades utilizadas en el proceso de gestión del desarrollo de proyectos según RUP.

estructura RUP

UP proporciona un enfoque estructurado para el desarrollo de software iterativo, dividiendo el proceso en cuatro hitos a lo largo del tiempo: inicio, elaboración, construcción y transición. Desafortunadamente, no existe una terminología establecida en el idioma ruso, por lo que en el futuro usaremos términos en inglés, acompañados de su traducción al ruso. En la Fig. La Figura 2 es una representación ampliamente utilizada de las fases de RUP. Los objetivos de cada una de estas fases son:

Inicio entendiendo lo que estamos creando. Fase de recogida de información y análisis de necesidades, definiendo la imagen del proyecto en su conjunto;

Elaboración entendiendo cómo lo creamos. Fase de análisis de requisitos y diseño del sistema, planificación de actividades y recursos necesarios, especificación de funciones y características de diseño;

Construcción de una versión beta del producto. La fase principal de desarrollo y codificación, construir el producto como una secuencia ascendente de iteraciones (versiones de código);

Creación de transición de la versión final del producto. Fase de introducción del producto, entrega del producto a un usuario específico.

Arroz. 2. Fases del RUP

Estas son las fases de la gestión de la evolución del producto: iteraciones del ciclo de vida. RUP implica acercarse al objetivo final, pero, a diferencia del estándar ISO clásico (metodología en cascada), donde la transición es la fase final, cada fase se puede repetir varias veces, reflejando cambios en los requisitos del cliente para el producto.

La metodología RUP se basa en nueve flujos de trabajo principales, que son elementos de la iteración del ciclo de vida del software:

Modelado de negocios (análisis de negocios): implica analizar los requisitos en una iteración determinada del ciclo de vida, determinando los parámetros deseados del sistema y las necesidades del usuario;

Formalización de requisitos de la imagen del sistema. Implica recopilar y gestionar requisitos, traducirlos en especificaciones funcionales. Aquí comienza el análisis de precedentes y la construcción de casos de uso (historias de usuario) y mapeo formal de requerimientos de usuario en UML. El resultado son documentos a nivel de gestión;

Análisis y diseño (análisis y modelado): implica la traducción de los requisitos recopilados a un modelo de software formalizado. El resultado es una descripción del sistema en la fase de implementación ( proyecto técnico) son documentos a nivel de desarrolladores de sistemas. El lenguaje de formalización es el Lenguaje de modelado unificado (UML), que se analizará a continuación. En el proceso de desarrollo iterativo, el producto de este flujo particular – el modelo del proyecto – evolucionará. Todos los cambios en RUP están vinculados directamente a los modelos, y las herramientas de automatización y un lenguaje de modelado bastante flexible le permiten gestionar este proceso de forma más o menos sencilla en términos de tiempo y recursos. Esto se refiere a que el resultado del desarrollo no es un modelo, sino un código ejecutable, por lo que al cliente normalmente no le gusta mucho pagar por el modelado, ya que los modelos no son el producto que necesita);

Implementación (implementación, codificación): implica realmente escribir el código. Los elementos de código en RUP ya se crean durante la fase de análisis y diseño, ya que la herramienta de implementación UML, Rational Rose, permite crear elementos de código en varios lenguajes de programación. Metodología - programación orientada a objetos;

La prueba implica probar el producto en una iteración determinada. Cabe señalar especialmente que las pruebas de regresión (pruebas de retorno, pruebas de “no deterioro” del producto) en este caso deben contener todas las pruebas actuales de la iteración anterior y las pruebas de aceptación de la fase de transición anterior;

La implementación (implementación) implica instalar el producto en el sitio del cliente, capacitar al personal, lanzar el sistema más pruebas de aceptación, preparar estándares para el empaque y distribución del producto, transferir materiales al departamento de ventas (las acciones son opcionales según las características específicas del producto). ).

Los elementos anteriores no son nuevos en términos del ciclo de vida del desarrollo de software, ya que ocurren en casi cualquier metodología, quizás con la excepción de XP (donde, sin embargo, se presentan de una forma muy original). Una característica de la implementación de RUP es el énfasis temporal, es decir, en qué iteraciones dominarán ciertos subprocesos, así como la presencia de un lenguaje universal y un conjunto de utilidades que permiten describir el proceso de desarrollo. Como vemos en la Fig. 2, en las etapas iniciales de la evolución del producto, se presta atención principal a la formalización del proyecto (análisis, modelado), que tiene como objetivo reducir los riesgos comerciales y reducir el costo de los errores de diseño. Cuando el panorama está más o menos claro, comienza el desarrollo, las pruebas y, finalmente, la implementación del producto.

Los internos preliminares son en realidad documentos emitidos por el consejo técnico para directivos de empresas. El objetivo principal de las etapas iniciales es celebrar un contrato o una carta de intención. Las iteraciones posteriores son el comienzo real del trabajo del equipo de desarrollo, que tiene el tiempo y los recursos para construir modelos formales. UML en este caso tiene herramientas que le permiten asignar el modelo a elementos de código. Por ejemplo, un árbol de objetos se muestra directamente, las variaciones dependen de la potencia de implementación del lenguaje de programación elegido por los desarrolladores, así como de la coincidencia de las opiniones de G. Butch y los desarrolladores de este lenguaje sobre el modelo de objetos. . Lo mismo se aplica a los métodos.

Ahora veamos los elementos relacionados con el soporte del producto: flujos de trabajo de soporte principales:

La gestión de la configuración (gestión de configuración y cambios) es una poderosa capa de acciones administrativas destinadas a gestionar las versiones de los productos, que implica el control del código fuente (modelo, módulos ejecutables, pruebas, documentación), control de las versiones del producto, estándares corporativos para el desarrollo y la documentación del código, seguimiento de cambios y errores (seguimiento de errores); estrechamente relacionado con las pruebas y la atención al cliente;

Gestión (gestión de proyectos): implica un conjunto de acciones administrativas para la gestión de proyectos de acuerdo con la ideología RUP, se utilizan herramientas de gestión de proyectos (consulte a continuación una lista de productos Rational);

El medio ambiente implica la creación y el mantenimiento. herramientas de análisis, diseño, desarrollo, pruebas (tanto software como hardware).

Desarrollo iterativo;

Gestión de requerimientos;

Uso de arquitecturas modulares;

Modelado visual;

Control de calidad;

Cambio de camino.

Las prácticas no forman parte directamente del proceso de RUP, pero son muy recomendables. Algunas prácticas se derivan directamente de la ideología del RUP. Por lo tanto, el desarrollo iterativo está integrado en la estructura de RUP, ya que este proceso es una de las implementaciones de la "espiral". La gestión de requisitos en RUP aparece en las primeras etapas del análisis. En teoría, la arquitectura modular permite reutilizar el código, lo que hace que el sistema sea más flexible. Debido a que UML es un lenguaje de objetos, es posible ignorar la modularidad, pero... es algo difícil. El modelado visual le permite abordar eficazmente la creciente complejidad de los sistemas. Además, los modelos son medios de comunicación entre desarrolladores, pero para ello los desarrolladores deben hablar UML, lo que requiere cierta formación. El modelado visual a menudo se realiza utilizando la herramienta Rational Rose, que permite obtener un conjunto de documentos muy útiles para gerentes, administradores de sistemas, desarrolladores, evaluadores y generar elementos de código. Esta herramienta no es la única implementación de UML: hay disponibles alternativas comerciales (por ejemplo, Microsoft Visio) y gratuitas. Cabe señalar que los dialectos UML implementados en las herramientas de modelado no siempre son los mismos: el dialecto Rational tiene algunas diferencias importantes, descritas tanto en la documentación como en los libros de UML.

Productos compatibles con RUP

Los siguientes son los productos más conocidos que soportan Rational Unified Process:

Herramienta de modelado visual Rational Rose CASE sistemas de información, que tiene la capacidad de generar elementos de código. Una edición especial del producto Rational Rose RealTime le permite obtener un módulo ejecutable como salida;

Herramienta de gestión de requisitos Rational Requisite Pro que le permite crear, estructurar, priorizar, rastrear y controlar los cambios de requisitos que surgen en cualquier etapa del desarrollo de los componentes de la aplicación;

Rational ClearQuest es un producto para gestionar cambios y rastrear defectos en un proyecto (seguimiento de errores), estrechamente integrado con herramientas de gestión de requisitos y pruebas y que proporciona un entorno único para vincular todos los errores y documentos entre sí;

Producto Rational SoDA para generar automáticamente documentación de proyectos, lo que le permite establecer un estándar corporativo para documentos internos. También es posible adaptar la documentación a los estándares existentes (ISO, CMM);

Rational Purify, Rational Quantify Rational PureCoverage, herramientas de prueba y depuración:

Rational Purify es una herramienta de búsqueda de errores en tiempo de ejecución muy potente para desarrolladores de aplicaciones y componentes que programan en C/C++.

Herramienta de medición del rendimiento de Rational Visual Quantify para desarrolladores de aplicaciones y componentes que programan en C/C++, Visual Basic y Java; ayuda a identificar y eliminar cuellos de botella en el rendimiento del software,

Rational Visual PureCoverage: identifica automáticamente áreas de código que no se están probando;

Rational ClearCase es un producto para la gestión de la configuración de software (Rational's Software Configuration Management, SCM), que permite el control de versiones de todos los documentos del proyecto. Con su ayuda, puede admitir varias versiones de proyectos simultáneamente, cambiando rápidamente entre ellas. Rational Requisite Pro admite actualizaciones y realiza un seguimiento de los cambios en los requisitos para el equipo de desarrollo;

Herramienta de automatización de pruebas SQA TeamTest;

Sistema de gestión de pruebas Rational TestManager que reúne todas las herramientas, artefactos, scripts y datos relacionados con las pruebas;

Herramienta Rational Robot para crear, modificar y ejecutar pruebas automáticamente;

SiteLoad, herramientas SiteCheck para probar el rendimiento de los sitios web y la presencia de enlaces rotos;

Rational PerformanceStudio: mide y predice las características de rendimiento del sistema.

Artefactos y roles

Una parte integral de RUP son los artefactos, los precedentes y los roles. Los artefactos son algunos de los productos de un proyecto que se generan o utilizan en el proyecto mientras se trabaja en el producto final. Los casos de uso son secuencias de acciones realizadas por el sistema para obtener un resultado observable. De hecho, cualquier resultado del trabajo de un individuo o grupo es un artefacto, ya sea un documento de análisis, un elemento de modelo, un archivo de código, un script de prueba, una descripción de un error, etc. Ciertos especialistas son responsables de la creación de uno u otro tipo de artefacto. Así, RUP define claramente las responsabilidades de cada miembro del equipo de desarrollo en una etapa u otra, es decir, cuándo y quién debe crear tal o cual artefacto. Todo el proceso de desarrollo de un sistema de software se considera en RUP como un proceso de creación de artefactos, desde los documentos de análisis inicial hasta los módulos ejecutables, manuales de usuario, etc. A continuación se muestra un conjunto de artefactos (modelos, documentos, etc.) para cada una de las corrientes.

Modelado de negocios

Determinación del modelo de proceso de negocio de los requisitos comerciales para el sistema que se está desarrollando;

Modelo de estructura empresarial: un artefacto para desarrollar un modelo funcional del sistema;

Modelos de documentos, entidades comerciales, modelos de escenarios de funciones comerciales, modelos de estados de entidades comerciales: para diseñar una interfaz de usuario, un sistema de base de datos; representar una descripción de los estados estáticos y dinámicos del sistema desde varios puntos de vista;

El artefacto de modelos de reglas comerciales se utiliza para modelar reglas en software.

Artefactos de documentos utilizados por RequisitePro, SoDA, procesadores de texto, Proyecto Microsoft:

Evaluación de la organización del cliente, estructura empresarial;

Diccionario de términos de áreas temáticas;

Un conjunto de reglas comerciales;

Oferta comercial;

Especificaciones de funciones comerciales;

Plan de trabajo en la etapa de modelado de negocios;

Solicitudes de cambio.

Requisitos

Modelos de artefactos utilizados por Rational Rose:

Modelo de función del sistema;

Modelo de escenario de función del sistema;

Modelo de interfaz de usuario;

Modelo de escenarios de usuario del sistema;

Modelo de formularios de salida;

Modelo de reglas del sistema.

Plan de gestión de requisitos;

Diccionario de términos del sistema;

Especificación para sistema de software;

Especificación de funciones del sistema;

Reglas del sistema;

Consultas de las partes interesadas;

Plan de trabajo en la etapa de determinación de los requisitos del sistema;

Solicitudes de cambio.

Análisis y diseño

Modelos de artefactos utilizados por Rational Rose:

Modelo de datos lógicos;

Modelo de datos físicos;

Modelo de especificaciones de los componentes del sistema;

Escenarios de interacción entre clases que implementan componentes del sistema.

Artefactos de documentos utilizados por RequisitePro, SoDA, procesadores de texto, MS Project:

Arquitectura de software;

Especificaciones de componentes de software;

Plan de trabajo en la etapa de análisis y diseño;

Solicitudes de cambio.

Implementación

Modelos de artefactos utilizados por Rational Rose:

Modelo de aplicación de componentes.

Código de artefactos utilizado por Rational Rose, herramientas de programación, procesadores de texto:

Elementos de generación de código procedentes de Rational Rose;

El código de aplicación real;

Documentación.

Artefactos de documentos utilizados por RequisitePro, SoDA, procesadores de texto, MS Project:

Plan de creación de aplicaciones;

Plan de trabajo en la etapa de implementación.

Prueba

Modelos de artefactos utilizados por Rational Rose:

Modelo de caso de prueba;

Modelo funcional del programa de prueba;

Modelo de especificación de componentes del programa de prueba;

Escenarios para la interacción de clases que implementan la interacción de componentes del programa de prueba.

Descripción de casos de prueba;

Plan de prueba;

Plan de trabajo para la fase de prueba;

Solicitudes de cambio.

Implementación de pruebas Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Despliegue

Modelos de artefactos utilizados por Rational Rose:

Descripción del modelo de ubicación de la ubicación de componentes en los nodos de procesamiento.

Artefactos de documentos utilizados por SoDA, procesadores de texto, MS Project:

Materiales educativos;

Documentos de instalación;

Descripción de versiones del sistema;

Plan de IMPLEMENTACION.

El próximo artículo de esta serie estará dedicado al Lenguaje Unificado de Modelado (UML).