Entonces, la esencia del enfoque estructural para el desarrollo del software EIS radica en su descomposición (particionamiento) en funciones automatizadas: el sistema se divide en subsistemas funcionales, que, a su vez, se dividen en subfunciones, éstas en tareas, y así sucesivamente. hasta procedimientos específicos. Al mismo tiempo, el sistema conserva una visión holística en la que todos los componentes que lo componen están interconectados. Al desarrollar un sistema "ascendente", desde las tareas individuales hasta el sistema completo, se pierde la integridad, surgen problemas al describir la interacción de la información de los componentes individuales.
Todos los métodos más comunes del enfoque estructural se basan en una serie de principios generales:
1. El principio de "divide y vencerás";
2. El principio de ordenación jerárquica: el principio de organizar las partes constituyentes del sistema en estructuras de árbol jerárquico con la adición de nuevos detalles en cada nivel.
La selección de dos principios básicos no significa que los principios restantes sean secundarios, porque ignorar cualquiera de ellos puede tener consecuencias impredecibles (incluido el fracaso de todo el proyecto”). Los principales de estos principios son:
1. El principio de abstracción - destacando los aspectos esenciales del sistema y la distracción de lo no esencial.
2. El principio de coherencia, validez y consistencia de los elementos del sistema.
3. Principio de estructuración datos - datos debe estar estructurado y organizado jerárquicamente.
En el enfoque estructural, hay básicamente dos grupos de herramientas que describen la estructura funcional del sistema y las relaciones entre los datos. Cada grupo de herramientas corresponde a ciertos tipos de modelos (diagramas), los más comunes entre ellos son:
· DFD (diagramas de flujo de datos) - diagramas de flujos de datos;
SADT (Técnica de Análisis y Diseño Estructurado - metodología de análisis y diseño estructural) - modelos y diagramas funcionales correspondientes: notaciones IDEF0 (modelado funcional de sistemas), IDEF1x (modelado conceptual de bases de datos), IDEF3x (sistemas de construcción para evaluar la calidad de un objeto ; descripción gráfica de los procesos de flujo, la interacción de procesos y objetos que son cambiados por estos procesos);
· ERD (Diagramas Entidad - Relación) - diagramas "entidad-relación".
En casi todos los métodos del enfoque estructural (análisis estructural), se utilizan dos grupos de herramientas de modelado en la etapa de formación de requisitos de software:
1. Diagramas que ilustran las funciones que debe realizar el sistema y las relaciones entre estas funciones - DFD o SADT (IDEF0).
2. Diagramas que modelan datos y sus relaciones (ERD).
La forma específica de los diagramas enumerados y la interpretación de sus construcciones dependen de la etapa del ciclo de vida del software.
En la etapa de formación de requisitos de software, los modelos SADT y DFD se utilizan para construir el modelo “TAL CUAL” y el modelo “FUERA DE SER”, reflejando así la estructura existente y propuesta de los procesos de negocio de la organización y la interacción entre ellos. (usando modelos SADT como generalmente se limitan solo a esta etapa, ya que originalmente no estaban destinados al diseño de software). Con la ayuda de ERD se realiza la descripción de los datos utilizados en la organización a nivel conceptual, independientemente del medio de implementación de la base de datos (DBMS).
Anotación: Un enfoque flexible para el desarrollo de software, se consideran los principios básicos del desarrollo flexible. Se proporciona una lista de técnicas que, en cierta medida, corresponden a los principios del desarrollo de software flexible. Se analizan los valores y principios clave del desarrollo ágil.
Puede descargar la presentación de esta conferencia.
Propósito de la conferencia:
Obtenga una comprensión del propósito y los principios básicos del desarrollo ágil de software.
Metodología ágil de desarrollo de software se centró en el uso de un enfoque iterativo, en el que software se crea gradualmente, en pequeños pasos, incluida la implementación de un determinado conjunto de requisitos. Se supone que los requisitos pueden cambiar. Los equipos que utilizan metodologías ágiles están formados por desarrolladores versátiles que realizan diversas tareas en el proceso de creación de un producto de software.
Al utilizar metodologías ágiles, la minimización del riesgo se lleva a cabo reduciendo el desarrollo a una serie de ciclos cortos llamados iteraciones, con una duración de 2-3 semanas. Una iteración es un conjunto de tareas programadas para completarse en un período de tiempo específico. En cada iteración, se crea una versión viable del sistema de software, en la que la mayor prioridad (para esta iteración) requerimientos del cliente. Cada iteración realiza todas las tareas necesarias para crear software que funcione: planificación, análisis de requisitos, diseño, codificación, pruebas y documentación. Si bien una sola iteración generalmente no es suficiente para liberar nueva versión producto, se entiende que el actual software listo para su lanzamiento al final de cada iteración. Al final de cada iteración, el equipo vuelve a priorizar los requisitos para el producto de software, posiblemente haciendo ajustes al desarrollo del sistema.
Para la metodología de desarrollo ágil se declaran postulados clave que permiten a los equipos alcanzar un alto desempeño:
Personas e interacción. Las personas son la parte más importante del éxito. Los miembros individuales del equipo y las buenas comunicaciones son esenciales para los equipos de alto rendimiento. Para facilitar la comunicación, las prácticas ágiles implican debates frecuentes sobre los resultados del trabajo y los cambios en las decisiones. Se pueden realizar debates diarios durante unos minutos y al final de cada iteración con un análisis de los resultados del trabajo y una retrospectiva. Para comunicarse de manera efectiva en las reuniones, los miembros del equipo deben cumplir con las siguientes reglas clave de conducta:
Además de un equipo eficaz y buenas comunicaciones, se necesitan herramientas de software perfectas para crear equipos de alto rendimiento en metodologías ágiles.
El software funcional es más importante que la documentación completa. Todas las metodologías ágiles resaltan la necesidad de entregar pequeñas piezas de software funcional al cliente a intervalos predeterminados. Software, como regla, debe pasar el nivel de prueba unitaria, prueba a nivel de sistema. La cantidad de documentación debe mantenerse al mínimo. Durante el proceso de diseño, el equipo debe mantener actualizado un breve documento que contenga la justificación de la decisión y una descripción de la estructura.
La cooperación con el cliente es más importante que los acuerdos formales bajo el contrato. Para que el proyecto se complete con éxito, es necesaria una comunicación regular y frecuente con el cliente. El cliente debe participar regularmente en la discusión de las decisiones tomadas sobre el software, expresar sus deseos y comentarios. Involucrar al cliente en el proceso de desarrollo de software es necesario para crear un producto de calidad.
Responder rápidamente al cambio es más importante que seguir un plan. La capacidad de responder al cambio determina en gran medida el éxito de un proyecto de software. En el proceso de creación de un producto de software, a menudo cambian requerimientos del cliente. Los clientes a menudo no saben exactamente lo que quieren hasta que ven que funciona. software. Las metodologías ágiles buscan comentario de los clientes en el proceso de creación de un producto de software. La capacidad de respuesta al cambio es esencial para crear un producto que brinde satisfacción al cliente y valor comercial.
Los principios del desarrollo ágil están respaldados por 12 principios. Las metodologías ágiles específicas definen procesos y reglas que más o menos se ajustan a estos principios. Metodologías de creación flexibles productos de software se basan en los siguientes principios:
Los principios anteriores, en cierta medida, corresponden a una serie de metodologías de desarrollo de software:
| Modelado ágil | un conjunto de conceptos, principios y técnicas (prácticas) que le permiten realizar de forma rápida y sencilla el modelado y la documentación en proyectos de desarrollo de software; |
| Proceso unificado ágil (AUP) | una versión simplificada de IBM RationalUnifiedProcess(RUP), que describe una aproximación (modelo) simple y comprensible para crear software para aplicaciones empresariales; |
| Abrir | es un método iterativo-incremental de desarrollo de software. Posicionado como una opción de RUP ligera y flexible; |
| AgileDataMethod | un grupo de métodos iterativos de desarrollo de software en los que los requisitos y las soluciones se logran a través de la colaboración de diferentes equipos multifuncionales; |
| DSDM | una metodología para desarrollar sistemas dinámicos basada en el concepto de desarrollo rápido de aplicaciones (RapidApplicationDevelopment, RAD). Representa un enfoque iterativo e incremental que enfatiza la participación continua del usuario/consumidor en el proceso; |
| Programación extrema (XP) | Programación extrema; |
| Desarrollo de software adaptativo (ADD) | desarrollo de software adaptativo; |
| Desarrollo impulsado por características (FDD) | desarrollo enfocado en la adición gradual de funcionalidad; |
| Volviéndose Real | un enfoque iterativo sin especificaciones funcionales utilizado para aplicaciones web; |
| MSFfogDesarrollo de software ágil | Metodología ágil de desarrollo de software de Microsoft; |
| Melé | establece reglas para gestionar el proceso de desarrollo y le permite utilizar las prácticas de codificación existentes ajustando los requisitos o realizando cambios tácticos [ |
Hasta la fecha, en ingeniería de software, existen dos enfoques principales para el desarrollo de software EIS, cuya diferencia fundamental se debe a diferentes caminos descomposición de sistemas. El primer enfoque se denomina funcional-modular o estructural. Se basa en el principio de descomposición funcional, en el que la estructura del sistema se describe en términos de la jerarquía de sus funciones y la transferencia de información entre elementos funcionales individuales. El segundo enfoque, orientado a objetos, utiliza la descomposición de objetos. En este caso, la estructura del sistema se describe en términos de objetos y relaciones entre ellos, y el comportamiento del sistema se describe en términos del intercambio de mensajes entre objetos.
Entonces, la esencia del enfoque estructural para el desarrollo del software EIS radica en su descomposición (particionamiento) en funciones automatizadas: el sistema se divide en subsistemas funcionales, que, a su vez, se dividen en subfunciones, éstas en tareas, y así sucesivamente. hasta procedimientos específicos. Al mismo tiempo, el sistema automatizado conserva una visión holística en la que todos los componentes están interconectados. Al desarrollar un sistema "de abajo hacia arriba", desde las tareas individuales hasta el sistema completo, se pierde la integridad, surgen problemas al describir la interacción de la información de los componentes individuales.
Todos los métodos más comunes del enfoque estructural se basan en una serie de principios generales. Los principios básicos son:
el principio de "divide y vencerás" (ver subsección 2.1.1);
principio de ordenamiento jerárquico - el principio de organizar las partes constituyentes del sistema en estructuras de árbol jerárquico con la adición de nuevos detalles en cada nivel.
La selección de dos principios básicos no significa que los principios restantes sean secundarios, ya que ignorar cualquiera de ellos puede tener consecuencias impredecibles (incluyendo el fracaso de todo el proyecto). Los principales de estos principios son:
el principio de abstracción: la asignación de aspectos esenciales del sistema y la distracción de los no esenciales;
el principio de consistencia - la validez y consistencia de los elementos del sistema;
el principio de estructuración de datos: los datos deben estar estructurados y organizados jerárquicamente.
El enfoque estructural utiliza principalmente dos grupos de herramientas que describen la estructura funcional del sistema y las relaciones entre los datos. Cada grupo de herramientas corresponde a ciertos tipos de modelos (diagramas), los más comunes de los cuales son:
DFD (diagramas de flujo de datos) - diagramas de flujo de datos;
SADT (Técnica de análisis y diseño estructurado - un método de análisis y diseño estructural) - modelos y diagramas funcionales correspondientes;
ERD (diagramas de entidad-relación) - diagramas de entidad-relación.
Los diagramas de flujo de datos y los diagramas de entidad-relación son los tipos de modelos más utilizados en las herramientas CASE.
La forma específica de los diagramas enumerados y la interpretación de sus construcciones dependen de la etapa del ciclo de vida del software.
En la etapa de formación de requisitos para el software, los modelos SADT y DFD se utilizan para construir el modelo "AS-IS" y el modelo "TO-BE", reflejando así la estructura existente y propuesta de los procesos de negocio de la organización y la interacción entre ellos (el uso de modelos SADT, por regla general, se limita solo a esta etapa, ya que originalmente no estaban destinados al diseño de software). Con la ayuda de ERD, la descripción de los datos utilizados en la organización se realiza a un nivel conceptual que es independiente de las herramientas de implementación de la base de datos (DBMS).
En la etapa de diseño, los DFD se utilizan para describir la estructura del sistema de software diseñado, mientras que pueden refinarse, expandirse y complementarse con nuevos diseños. De manera similar, los ERD se refinan y complementan con nuevas construcciones que describen la representación de datos en un nivel lógico adecuado para la generación posterior de un esquema de base de datos. Estos modelos pueden complementarse con diagramas que reflejen la arquitectura del sistema del software, diagramas de bloques de programas, la jerarquía de pantallas y menús, etc.
Los modelos listados juntos dan Descripción completa software EIS, independientemente de si el sistema es existente o se ha desarrollado recientemente. La composición de los diagramas en cada caso particular depende de la complejidad del sistema y de la completitud requerida de su descripción.
El área temática de la mayoría de los ejemplos de diagramas proporcionados en este capítulo es el sistema fiscal de la Federación Rusa, cuya descripción más completa se encuentra en el Código Fiscal de la Federación Rusa. Tecnologías de la información utilizados en el sistema fiscal de la Federación Rusa, tienen ciertas características.
Ahora bien, en la ingeniería de software existen dos enfoques principales para el desarrollo de software IS, cuya diferencia fundamental se debe a las diferentes formas de descomposición de los sistemas: un enfoque funcional-modular (estructural), que se basa en el principio de descomposición funcional, en el que la estructura del sistema se describe en términos de la jerarquía de sus funciones y la transferencia de información entre los elementos funcionales individuales, y enfoque orientado a objetos, que utiliza la descomposición de objetos, describe la estructura del SI en términos de objetos y relaciones entre ellos, y el comportamiento del sistema en términos de mensajería entre objetos.
Entonces, la esencia del enfoque estructural para el desarrollo del software IS radica en su descomposición en funciones automatizadas: el sistema se divide en subsistemas funcionales, que a su vez se dividen en subfunciones, se dividen en tareas, y así sucesivamente hasta específicos procedimientos. Al mismo tiempo, IS preserva la integridad de la representación, donde todos los componentes están interconectados. Al desarrollar un sistema "de abajo hacia arriba", desde las tareas individuales hasta el sistema completo, se pierde la integridad, surgen problemas al describir la interacción de la información de los componentes individuales.
Los principios básicos del enfoque estructural son:
o principio " divide y vencerás";
o principio orden jerárquico - el principio de organizar los sistemas de componentes en estructuras de árbol jerárquico con la adición de nuevos detalles en cada nivel. La selección de dos principios básicos no significa que los principios restantes sean secundarios, ya que ignorar cualquiera de ellos puede tener consecuencias impredecibles.
Los principales de estos principios son:
oh abstracción - destacando los aspectos esenciales del sistema;
consistencia - validez y coherencia de los elementos del sistema;
o estructuración de datos - los datos deben estar estructurados y organizados jerárquicamente.
Modelado visual. Un modelo de software generalmente se denomina descripción formalizada de un sistema de software en un cierto nivel de abstracción. Cada modelo define un aspecto específico del sistema, utiliza un conjunto de diagramas y documentos en un formato dado y refleja los pensamientos y actividades de diferentes personas con intereses, funciones o tareas específicas.
Los modelos gráficos (visuales) son herramientas para visualizar, describir, diseñar y documentar la arquitectura del sistema. La composición de los modelos utilizados en cada proyecto específico, y el grado de detalle de los mismos en el caso general, depende de los siguientes factores:
o las dificultades del sistema diseñado;
o la necesaria exhaustividad de su descripción;
o conocimientos y habilidades de los participantes del proyecto;
o tiempo asignado para el diseño.
El modelado visual ha influido mucho en el desarrollo de las herramientas CASE en particular. El concepto de CASE (Computer Aided Software Engineering) se utiliza en un sentido amplio. El significado original de este concepto, limitado únicamente a las tareas de automatización del desarrollo de software, ha adquirido ahora un nuevo significado, que abarca la mayor parte de los procesos del ciclo de vida del software.
La tecnología CASE es un conjunto de métodos de diseño de software, así como un conjunto de herramientas, permitiendo de forma visual modelar el tema, analizar este modelo en todas las etapas de desarrollo y mantenimiento del software, y desarrollar aplicaciones de acuerdo con las necesidades de información de los usuarios. La mayoría de las herramientas CASE existentes se basan en métodos de diseño y análisis estructural u orientado a objetos, utilizando especificaciones en forma de diagramas o textos para describir los requisitos externos, las relaciones entre los modelos del sistema, la dinámica del comportamiento del sistema y las arquitecturas de software.
En la primera parte, optamos por comparar metodologías de desarrollo de software con indicadores tales como la relación entre la metodología y el desarrollo iterativo y el grado de formalidad en el diseño de los materiales de trabajo y en general en el desarrollo. En esta parte, usamos estas métricas para comparar las prácticas de desarrollo de software más conocidas.
Por desgracia, esta es la categoría más difícil de describir; después de todo, incluye tanto el producto del lanzamiento convulsivo de un principiante que intenta completar su primer proyecto a toda costa, como metodologías bastante maduras y bien establecidas que han absorbido muchos años. de y variada experiencia de equipos de desarrollo específicos e incluso descritos en normativa interna. Dado que las personas que pueden desarrollar su propia metodología, por regla general, pueden evaluarla en términos de iteración y formalización, nos centraremos en los principiantes. Por desgracia, la mayoría de las veces esto significa que las reglas para llevar a cabo el desarrollo no existen en absoluto o se han desarrollado y adoptado, pero no se están implementando. Natural en tales condiciones es un nivel extremadamente bajo de formalismo de desarrollo. Así que todo esto está claro.
Desarrollo "Cómo funciona"
¿Qué tal un enfoque iterativo? Por desgracia, por regla general, no se utiliza en tales proyectos. En primer lugar, porque permitiría, incluso en las primeras iteraciones, evaluar el proyecto como extremadamente dudoso y que requiere una intervención urgente de la alta dirección para restablecer el orden. Después de todo, en un proyecto iterativo, la respuesta tradicional del programador de que todo está listo en un 90 % solo dura hasta la finalización de la primera iteración...
Metodologías Estructurales
Los métodos estructurales son un grupo de metodologías desarrolladas, por regla general, incluso antes del uso generalizado de los lenguajes orientados a objetos. Todos ellos implican el desarrollo de cascadas. Aunque, como resultó, en ese artículo, que a menudo se cita como la primera presentación del enfoque en cascada, se dijo que es deseable comenzar el proyecto con el desarrollo de un prototipo, es decir, realizar al menos dos iteraciones.
Sin embargo, la base de estas metodologías es la transición secuencial de obra a obra y la transferencia de los resultados (documentos) de la siguiente etapa a los participantes de la siguiente.
Además, todas estas metodologías asumen un enfoque altamente formalizado, aunque en ellas se pueden encontrar declaraciones sobre una cantidad razonable de documentación. Uno de los ejemplos no evidentes de que las metodologías de desarrollo de software no se desarrollaron sólo en occidente es una cita de un libro publicado en nuestro país a principios de la década de los 80, que establece que el grado de formalización de una tarea de programación debe determinarse en base a en lo bien que el analista y el programador. Y esto a pesar de que el tema del libro involucraba el desarrollo de sistemas bastante críticos, como ahora se los llama, errores en los que se derivan pérdidas graves o incluso desastres.
Las metodologías ágiles se basan en diez principios, de los cuales nombraremos únicamente aquellos que determinan la valoración de estas metodologías según los parámetros seleccionados:
Por lo tanto, estos métodos están claramente enfocados en el desarrollo de software iterativo y la mínima formalización del proceso. Sin embargo, es necesario hacer una reserva con respecto al segundo punto: estos métodos se centran en el nivel mínimo de formalización aceptable para un proyecto determinado. Al menos una de las metodologías incluidas en el grupo flexible - Crystal - tiene modificaciones diseñadas para realizar procesos con diferente número de participantes y diferente criticidad del software desarrollado (la criticidad del software está determinada por las posibles consecuencias de los errores, que pueden variar desde insignificantes perdidas financieras corregir un error a uno catastrófico). Para que no sea inútil una mayor comparación con metodologías flexibles, presentamos breves descripciones Varios de ellos.
La metodología XP, desarrollada por Kent Beck, Ward Cunningham y Ron Jeffries, es la más conocida de las metodologías ágiles en la actualidad. En ocasiones, el propio concepto de "metodologías ágiles" se identifica explícita o implícitamente con XP, que predica la sociabilidad, la sencillez, la retroalimentación y la valentía. Se describe como un conjunto de prácticas: juego de planificación, lanzamientos cortos, metáforas, diseño simple, refactorización de código, desarrollo de prueba anticipada, programación en pares, código compartido, 40 horas. semana de trabajo, presencia del cliente y estándares de código. El interés en XP creció de abajo hacia arriba: desde desarrolladores y evaluadores, atormentados por procesos dolorosos, documentación, métricas y otros formalismos. No rechazaron la disciplina, pero no estaban dispuestos a seguir los requisitos formales sin sentido y buscaron nuevos enfoques rápidos y flexibles para el desarrollo de programas de alta calidad.
Cuando se utiliza XP, el cuidadoso diseño preliminar del software se reemplaza, por un lado, por la presencia constante del cliente en el equipo, listo para responder cualquier pregunta y evaluar cualquier prototipo, y por otro lado, las revisiones periódicas del código (las llamadas refactorización). El código minuciosamente comentado se considera la base de la documentación de diseño. Se presta mucha atención en la metodología a las pruebas. Como regla general, para cada método nuevo, primero se escribe una prueba y luego se desarrolla el código del método real hasta que la prueba comienza a ejecutarse con éxito. Estas pruebas se almacenan en suites que se ejecutan automáticamente después de cualquier cambio de código.
Si bien la programación en pares y la semana laboral de 40 horas son quizás las características más conocidas de XP, siguen siendo de apoyo y contribuyen a una alta productividad del desarrollador y a la reducción de errores de desarrollo.
Crystal es una familia de metodologías que determinan el grado de formalización requerido del proceso de desarrollo, dependiendo del número de participantes y la criticidad de las tareas.
La metodología Crystal Clear es inferior a XP en términos de rendimiento, pero es lo más fácil de usar posible. Requiere un esfuerzo mínimo para implementar porque se enfoca en los hábitos humanos. Se cree que esta metodología describe el orden natural del desarrollo de software, que se establece en equipos suficientemente calificados, si no están comprometidos en la implementación deliberada de otra metodología.
Características clave de Crystal Clear:
Además de Crystal Clear, hay varias otras metodologías en la familia Crystal diseñadas para proyectos más grandes o más críticos. Difieren en requisitos un poco más estrictos para la cantidad de documentación y procedimientos de respaldo, como el control de cambios y versiones.
El desarrollo basado en funciones (FDD) funciona en términos de una función del sistema o una función que es bastante similar al concepto de caso de uso de RUP. Quizás la diferencia más significativa es una restricción adicional: "cada función debe permitir la implementación en no más de dos semanas". Es decir, si el caso de uso es lo suficientemente pequeño, puede considerarse una función, y si es grande, debe dividirse en varias funciones relativamente independientes.
FDD incluye cinco procesos, y los dos últimos se repiten para cada característica:
El trabajo en el proyecto implica compilaciones frecuentes y se divide en iteraciones, cada una de las cuales se implementa utilizando un conjunto específico de características.
Los desarrolladores de FDD se dividen en "maestros de clase" y "programadores en jefe". Los programadores principales involucran a los propietarios de las clases involucradas para trabajar en la siguiente propiedad. A modo de comparación: en XP no hay personalmente responsable de clases o métodos.
La lista de metodologías flexibles es actualmente bastante amplia. Sin embargo, las metodologías que hemos descrito dan una imagen muy completa de toda la familia.
Casi todas las metodologías ágiles utilizan un enfoque iterativo, en el que solo se planifica en detalle una cantidad limitada de trabajo asociado con el lanzamiento del próximo lanzamiento.
Casi todas las metodologías ágiles se centran en el enfoque más informal del desarrollo. Si el problema se puede resolver en el curso de una conversación normal, entonces es mejor hacer precisamente eso. Además, es necesario redactar la decisión en forma de documento en papel o electrónico solo cuando sea imposible prescindir de él.
Metodologías ágiles
Los GOST, al igual que los requisitos de CMM descritos en la siguiente sección, no son metodologías. Por regla general, no describen los procesos de desarrollo de software en sí mismos, sino que solo formulan ciertos requisitos para los procesos, a los que corresponden varias metodologías en un grado u otro. La comparación de requisitos de acuerdo con los mismos criterios con los que comparamos metodologías lo ayudará a decidir de inmediato qué metodologías debe usar si necesita desarrollar de acuerdo con GOST.
En la actualidad, están vigentes en Rusia los GOST antiguos de las series 19 y 34 y el GOST R ISO IEC 122207 más nuevo. Los GOST de las series 19 y 34 se centran estrictamente en el enfoque en cascada para el desarrollo de software. El desarrollo de acuerdo con estos GOST se lleva a cabo en etapas, cada una de las cuales implica la realización de un trabajo estrictamente definido y finaliza con la publicación de una cantidad bastante grande de documentos muy formales y extensos. Por lo tanto, el cumplimiento estricto inmediato de estos estándares no solo conduce a un enfoque en cascada, sino que también proporciona un grado muy alto de formalización del desarrollo.
Requisitos GOST
GOST 12207, en contraste con los estándares de las series 19 y 34, describe el desarrollo de software como un conjunto de procesos principales y auxiliares que pueden operar desde el principio hasta el final del proyecto. El modelo de ciclo de vida se puede seleccionar en función de las características del proyecto. Por lo tanto, este GOST no prohíbe explícitamente el uso de un enfoque iterativo, pero no recomienda explícitamente su uso. GOST 12207 también es más flexible en términos de requisitos para la formalidad del proceso de desarrollo. Contiene solo indicaciones de la necesidad de documentar los principales resultados de todos los procesos, pero no contiene listas de documentos requeridos e instrucciones sobre su contenido.
Por lo tanto, GOST 12207 permite el desarrollo de software iterativo y menos formalizado.
Además de las normas nacionales e internacionales, existen varios enfoques para la certificación del proceso de desarrollo. Los más famosos de ellos en Rusia son, aparentemente, CMM y CMMI.
CMM (Capability Maturity Model) es un modelo de madurez de los procesos de desarrollo de software, que está diseñado para evaluar el nivel de madurez del proceso de desarrollo en una empresa en particular. Según este modelo, hay cinco niveles de madurez del proceso de desarrollo. El primer nivel corresponde al desarrollo “cómo va”, cuando los desarrolladores van a cada proyecto como una proeza. El segundo corresponde a procesos más o menos establecidos, cuando es posible con suficiente confianza contar con un resultado positivo del proyecto. El tercero corresponde a la presencia de procesos desarrollados y bien descritos utilizados en el desarrollo, y el cuarto corresponde al uso activo de métricas en el proceso de gestión para fijar metas y monitorear su cumplimiento. Finalmente, el quinto nivel se refiere a la capacidad de la empresa para optimizar el proceso según sea necesario.
Requisitos de CMM y CMMI
Después de la llegada de CMM, se comenzaron a desarrollar modelos de madurez especializados para crear sistemas de información, para el proceso de selección de proveedores y algunos otros. En base a ellos, se desarrolló un modelo CMMI integrado (Capability Maturity Model Integration). Además, en CMMI se intentó superar las deficiencias de CMM que se habían manifestado en ese momento: una exageración del papel de las descripciones formales de los procesos, cuando la presencia de cierta documentación se valoraba mucho más que solo una bien establecida, pero no se describe el proceso. Sin embargo, CMMI también se enfoca en utilizar un proceso altamente formalizado.
Así, la base de los modelos CMM y CMMI es la formalización del proceso de desarrollo. Apuntan a los desarrolladores a la implementación de un proceso descrito detalladamente en las normas e instrucciones, que, a su vez, no puede sino requerir el desarrollo de una gran cantidad de documentación del proyecto para su adecuado control e información.
La relación de CMM y CMMI con el desarrollo iterativo es más indirecta. Formalmente, ninguno de ellos presentó requisitos específicos para adherirse a un enfoque en cascada o iterativo. Sin embargo, según algunos expertos, CMM es más compatible con el enfoque en cascada, mientras que CMMI también permite un enfoque iterativo.
Por supuesto, RUP es una metodología iterativa. Aunque formalmente la ejecución obligatoria de todas las fases o un número mínimo de iteraciones no se indica en ninguna parte de RUP, todo el enfoque se centra en el hecho de que hay bastantes. El número limitado de iteraciones no le permite aprovechar al máximo RUP. Al mismo tiempo, RUP también se puede usar en proyectos casi en cascada, que realmente incluyen solo un par de iteraciones: una en la fase de construcción y la otra en la fase de transferencia. Por cierto, este es el número de iteraciones que realmente se usa en los proyectos en cascada. Después de todo, la operación de prueba y prueba del sistema implica realizar correcciones, lo que puede implicar ciertas acciones relacionadas con el análisis, el diseño y el desarrollo, es decir, en realidad, son un paso más por todas las fases del desarrollo.
Metodología RUP
En cuanto a la formalidad de la metodología, RUP presenta al usuario un abanico de posibilidades muy amplio. Si realiza todo el trabajo y las tareas, crea todos los artefactos y realiza todas las revisiones de manera bastante formal (con un revisor oficial, con la preparación de una revisión completa en forma de documento electrónico o en papel, etc.), RUP puede convertir resulta ser una metodología extremadamente formal y pesada. Al mismo tiempo, RUP le permite desarrollar solo aquellos artefactos y realizar solo aquellos trabajos y tareas que son necesarios en un proyecto en particular. Y los artefactos seleccionados se pueden ejecutar y revisar con un grado arbitrario de formalidad. Es posible exigir un estudio detallado y una ejecución cuidadosa de cada documento, la provisión de una revisión igualmente ejecutada y formalizada, e incluso, siguiendo la práctica antigua, aprobar cada revisión en el consejo científico y técnico de la empresa. puedes limitar correo electrónico o dibujar en papel. Además, siempre existe una posibilidad más: formar un documento en tu cabeza, es decir, pensar en el tema relevante y tomar una decisión constructiva. Y si esta decisión solo le concierne a usted, limítese, por ejemplo, a un comentario en el código del programa.
Así, RUP es una metodología iterativa con un rango muy amplio soluciones posibles en términos de formalizar el proceso de desarrollo.
Resumamos la segunda parte del artículo. RUP, a diferencia de la mayoría de las otras metodologías, le permite elegir el grado de formalización e iteración del proceso de desarrollo en un amplio rango, dependiendo de las características de los proyectos y la organización en desarrollo.
Y por qué esto es tan importante, lo discutiremos en la siguiente parte.
