Ciclo de vida del proceso de desarrollo. Ciclo de vida de los sistemas de software.

En el caso general, un sistema de software, además de los programas en sí, también contiene hardware, y también suele considerarse rodeado de otros sistemas de software y hardware.

El ciclo de vida de un sistema de software generalmente se entiende como el período completo de existencia de un sistema de software, comenzando desde el momento en que se desarrolla el concepto inicial del sistema y finalizando cuando el sistema queda obsoleto. Concepto ``ciclo de vida"" Se utiliza cuando se espera que el sistema de software tenga una vida útil bastante larga, a diferencia de la programación experimental en la que los programas se ejecutan varias veces y no se vuelven a utilizar.

El ciclo de vida se modela tradicionalmente como un cierto número de etapas sucesivas (o etapas, fases). Actualmente, no existe una división generalmente aceptada del ciclo de vida de un sistema de software en etapas. A veces un escenario se destaca como un punto separado, a veces se incluye como parte integral de un escenario más grande. Las acciones realizadas en una u otra etapa pueden variar. No hay uniformidad en los nombres de estas etapas. Por lo tanto, primero intentaremos describir algún ciclo de vida generalizado de un sistema de software y luego demostraremos varios ejemplos de diferentes ciclos de vida, indicando analogías con este ciclo generalizado.

Etapas del ciclo de vida del software

El ciclo de vida del software es el período de desarrollo y operación del software, que generalmente incluye las siguientes etapas: -1- surgimiento e investigación de una idea; -2- análisis y diseño de requisitos; -3- programación; -4- pruebas y depuración; -5- poner en práctica el programa; -6- operación y mantenimiento; -7- fin de operación.

Cabe señalar que dividir el ciclo de vida en etapas a veces ayuda a oscurecer algunos aspectos importantes de la creación de software; Esto es especialmente cierto en relación con un proceso tan necesario como la implementación iterativa de varias etapas del ciclo de vida para corregir errores, cambiar decisiones que resultaron incorrectas o tener en cuenta cambios en los requisitos generales del sistema.

Ejemplos de descripciones del ciclo de vida.

Consideremos varias descripciones del ciclo de vida del software, que servirán como una especie de comentario sobre las etapas del ciclo de vida generalizado.

En los documentos reglamentarios nacionales (por ejemplo, GOST ESPD), se adopta la siguiente división en etapas, que se indica con analogías de la lista que figura al comienzo de la sección:

desarrollo de especificaciones técnicas (etapas 1 y 2);

diseño técnico (tercera etapa hasta 3.2.1 inclusive);

borrador de trabajo (3.2.2, 4.2.1 y, en parte, 4.2, 4.3);

implementación piloto (4.2 y 4.3);

puesta en servicio para operación comercial (etapa 5);

operación industrial (etapa 6).

Esta descripción se basa en la tecnología de desarrollo de hardware y, por lo tanto, no tiene en cuenta todas las características distintivas del diseño de software. Una descripción más apropiada del ciclo de vida del software parece ser la de 12 etapas, que son muy similares a las etapas del ciclo de vida generalizado (ver Figura 1.1). Entre paréntesis, después del nombre de la fase, se indica un análogo del ciclo generalizado. Casi todas las etapas finalizan con la verificación de los resultados obtenidos en la etapa correspondiente.

Arroz. 1.1 Ejemplo del ciclo de vida de los sistemas de software.

Iniciación y planificación del proyecto (etapa 1). Se determinan las acciones necesarias, planes y organización de la gestión del proyecto. Se determinan medidas para garantizar la ejecución continua de las fases del ciclo de vida.

Análisis de requisitos objetivo (2.1). Se determinan las características generales del sistema que debe satisfacer, sin tener en cuenta los medios de implementación. Se establece qué debe hacer el sistema y cómo debe hacerlo.

Análisis de requisitos del sistema (2.2). Describe cómo se deben satisfacer las solicitudes del usuario, en términos de conceptos funcionales específicos, se describen las acciones del sistema propuesto, los datos almacenados, la interfaz utilizada, todo esto sin tener en cuenta la implementación física. Se prueba la idoneidad de estos conceptos específicos.

Diseño del sistema (3.1). La estructura del sistema o, en otras palabras, su arquitectura se establece en términos de los componentes principales de este sistema y su implementación prevista (hardware, software, uso del entorno, etc.). Se establecen requisitos para cada componente, así como una estrategia de prueba e integración.

Diseño preliminar de software (3.2.1). Determinación de componentes de software específicos que serán desarrollados e implementados en el sistema final. Comprobar la coherencia de este conjunto de componentes con los requisitos generales del software. Determinación de requisitos funcionales, operativos y de prueba para cada componente específico.

Diseño detallado del software (3.2.2). En términos de las construcciones de software utilizadas, se hace una descripción de cómo se desarrollará cada componente específico. Se describen los modos de uso de cada componente del sistema.

Codificación y prueba de software (4.1.1 y 4.1.2). Creación, prueba de módulos individuales, documentación y aceptación de componentes de software que componen el sistema de software.

Integración de software (parte 4.2). Probar el rendimiento y la integridad funcional de las partes de software del sistema en un entorno predecible (hardware y entorno).

Integración del sistema (4.3). Probar el rendimiento y la integridad funcional de partes del sistema general en su conjunto.

Aceptación y entrega del sistema (5). El sistema es aceptado por el cliente y se le entrega el sistema.

Operación y mantenimiento del sistema (6). Lanzamiento de versiones posteriores o versiones del sistema, cuya necesidad surge debido a la eliminación de defectos, prueba de requisitos modificados, etc.

Finalización del proyecto (7). Formación de un modelo post-origen de acciones del proyecto con análisis de ventajas, desventajas, etc., y su utilización como base para mejorar el proceso de desarrollo.

Como siguiente ejemplo, consideremos un ciclo de vida de software incompleto, sin etapas de operación y mantenimiento (ver Fig. 1.2). Esta opción no fija la secuencia de fases o etapas, sino que propone una lista de acciones que se deben realizar a lo largo del ciclo de vida del software. Estas acciones pueden desglosarse o, por el contrario, agruparse en diferentes etapas, dependiendo de condiciones específicas. Se pueden distinguir las siguientes etapas del ciclo de vida de los sistemas de software (entre paréntesis, como antes, se encuentran los análogos del modelo de ciclo generalizado):

la etapa de planificación, que determina y coordina las actividades para desarrollar el sistema de software (etapa 1);

Etapa de desarrollo en la que se crea un sistema de software:

planteamiento del problema (etapa 2),

diseño (3),

codificación (4.1.1),

obtener código ejecutable (4.1.1, 4.3);

una etapa integrada que asegura la corrección, verificación y determinación de la integridad del sistema de software, así como su liberación. Esta etapa incluye verificación, monitoreo de la configuración del sistema, evaluación de calidad y verificación de la interacción entre las etapas. Del nombre de esta etapa se desprende claramente que se realiza junto con otras etapas a lo largo del ciclo de vida del sistema.

Arroz. 1.2 Opción para un ciclo de vida simplificado de un sistema de software.

La ausencia de una etapa integrada en el ciclo de vida general no significa que la verificación se lleve a cabo únicamente cuando así se indica claramente en el nombre de la etapa (por ejemplo, 4.2.1 y 4.2). Cada etapa se puede considerar completada sólo cuando los resultados obtenidos en esta etapa se consideran satisfactorios, y para ello es necesario verificar los resultados en cada etapa. En el resumen del ciclo de vida, algunas comprobaciones se han destacado como elementos separados para demostrar el mayor volumen, complejidad e importancia de estas comprobaciones.

La secuencia de etapas del ciclo de vida de diferentes sistemas de software está determinada por características tales como funcionalidad, complejidad, tamaño, estabilidad, uso de resultados obtenidos previamente, la estrategia que se está desarrollando y el hardware.

En la Fig. 1.3. muestra la secuencia de etapas de desarrollo de software para componentes individuales de un solo sistema de software con diferentes ciclos de vida.

Arroz. 1.3 Secuencia de etapas de desarrollo de componentes de software.

Para el componente W, a partir del conjunto de requisitos del sistema para un solo producto, se forma un subconjunto de requisitos relacionados con este componente, estos requisitos se utilizan al formar un proyecto para un componente de software, este proyecto se implementa en el código fuente y luego el El componente está integrado con el hardware. El Componente X muestra el uso de software previamente desarrollado. El componente Y muestra el uso de una única función simple que se puede codificar directamente según los requisitos del software. El componente Z muestra el uso de la estrategia del prototipo. Normalmente, los objetivos de la creación de prototipos son comprender mejor los requisitos del software y reducir los riesgos técnicos y de desarrollo al crear el producto final. Los requisitos iniciales se utilizan como base para la obtención de un prototipo. Este prototipo se convierte en un entorno típico para el uso específico de desarrollo del sistema. El resultado de la transformación son datos refinados que se utilizan para crear el producto de software final.

Casi todas las etapas del ciclo de vida se combinan con la verificación.

ciclo de vida del software

Uno de los conceptos básicos de la metodología de diseño de SI es el concepto de ciclo de vida del software (SOLC).

JC– este es un modelo de varios estados de un producto de software, desde el momento en que surge la necesidad de este producto de software hasta el momento en que deja de utilizarse para todos los usuarios.

El ciclo de vida de las bases de datos aún no está regulado por estándares; los estándares existentes se refieren únicamente al ciclo de vida del software.

Los estándares del ciclo de vida de los PS se pueden utilizar como documentos directivos, de orientación o de asesoramiento.

El ciclo de vida, la tecnología para desarrollar y garantizar la calidad del software se reflejan más plenamente en las normas ISO (Organización Internacional de Normalización). La norma ISO 12207:1995 - "Procesos del ciclo de vida del software" - refleja más plenamente la arquitectura, el trabajo, la organización y la gestión del ciclo de vida del software.

Los modelos de ciclo de vida del software realmente utilizados en las empresas han cambiado recientemente en relación con los que figuran en los estándares debido a la introducción y el desarrollo de análisis y métodos orientados a objetos para el desarrollo rápido de software, sistemas CASE y lenguajes de cuarta generación. Los nuevos modelos reducen el trabajo de creación directa de componentes de software y detallan el trabajo de análisis de sistemas y diseño de sistemas de software y bases de datos.

En general, al crear proyectos de PS y garantizar su ciclo de vida, es aconsejable utilizar una muestra de todo el conjunto de estándares presentados (tanto internacionales como nacionales) y llenar los vacíos existentes en la estandarización con estándares de facto y documentos regulatorios departamentales.

Perfil es un conjunto de varios estándares básicos y otros documentos regulatorios destinados a implementar una función o grupo de funciones determinado.

Partiendo del mismo conjunto de estándares básicos, se pueden formar diferentes perfiles para diferentes proyectos.

En la certificación de sistemas de información, la certificación del cumplimiento del perfil se distingue como un tipo especial de prueba. Y aquí debe tenerse en cuenta que en la estandarización internacional de la propiedad intelectual se adopta una interpretación estricta del concepto de perfil: se cree que solo los estándares aprobados a nivel internacional y nacional pueden ser la base de un perfil (es decir, el uso de no se permiten normas de facto ni documentos reglamentarios de las empresas).

En función del perfil específico, está previsto redactar documentación. Además, para cada etapa del ciclo de vida se redacta su propia documentación, que a su vez se divide en tipos, dependiendo de para qué especialistas se crea.

El ciclo de vida del software es un proceso continuo que comienza desde el momento en que se toma la decisión sobre la necesidad de su creación y finaliza en el momento de su total retirada del servicio.

El principal documento normativo que regula el ciclo de vida del software es la norma internacional ISO /IEC 12207 (ISO - Organización Internacional de Normalización, IEC - Comisión Electrotécnica Internacional). Define la estructura del ciclo de vida que contiene los procesos, actividades y tareas que deben realizarse durante la creación del software.

La estructura del ciclo de vida del software según la norma ISO/IEC 12207 se basa en tres grupos de procesos:

· procesos principales Ciclo de vida del software (compra, suministro, desarrollo, operación, soporte);

· procesos auxiliares asegurar la implementación de procesos básicos (documentación, gestión de configuración, aseguramiento de la calidad, verificación, certificación, evaluación, auditoría, resolución de problemas);

· procesos organizacionales(gestión de proyectos, creación de infraestructura del proyecto, definición, evaluación y mejora del propio ciclo de vida, formación).

Desarrollo incluye todo el trabajo de creación de software y sus componentes de acuerdo con los requisitos especificados, incluida la preparación de la documentación operativa y de diseño, la preparación de los materiales necesarios para probar la funcionalidad y la calidad adecuada de los productos de software, los materiales necesarios para organizar la capacitación del personal, etc.

El desarrollo de software incluye, generalmente:

· análisis;

· diseño;

· implementación (programación).

La fase de desarrollo comienza con un estudio de viabilidad del proyecto y luego lo traduce de los requisitos del usuario a una forma que pueda implementarse en las computadoras.

Esta fase suele representar el 50% del costo de diseño y el 32% de los costos laborales.

Explotación comienza cuando el producto es entregado al usuario, en uso y en uso.

Incluye:

Trabajar en la puesta en funcionamiento de los componentes del software, incluida la configuración de la base de datos y las estaciones de trabajo de los usuarios;

Proporcionar documentación operativa;

Realización de formación de personal, etc., y operación directa, incluida la localización de problemas y la eliminación de las causas de su aparición.

Modificación de software dentro de la normativa establecida, elaboración de propuestas de mejora, desarrollo y modernización del sistema.

Fase de mantenimiento También llamada fase de desarrollo continuo.

Consiste en identificar y eliminar errores en los programas y cambiar su funcionalidad..

Los profesionales han reconocido que esta parte del ciclo de vida (LC) debe tenerse en cuenta desde el momento en que comienza el desarrollo para mejorar el diseño de acuerdo con las necesidades del usuario.

Proceso de mantenimiento, continuará en paralelo con el funcionamiento del PI.

La estructura de los costos laborales para varios tipos de actividades de soporte es tal que aproximadamente el 78% del tiempo se dedica a cambiar la funcionalidad del software y el 17% a identificar errores.

Gestión de configuración Es uno de los procesos auxiliares que soportan los procesos principales del ciclo de vida del software, principalmente los procesos de desarrollo y mantenimiento de software. Al crear proyectos SI complejos que constan de muchos componentes, cada uno de los cuales puede tener variedades o versiones, surge el problema de tener en cuenta sus conexiones y funciones, crear una estructura unificada y asegurar el desarrollo de todo el sistema. La gestión de la configuración le permite organizar, tener en cuenta sistemáticamente y controlar los cambios en el software en todas las etapas del ciclo de vida. Los principios generales y recomendaciones para la contabilidad de la configuración, la planificación y la gestión de la configuración del software se reflejan en el borrador de la norma ISO 12207-2.

Aseguramiento de la calidad del proyecto. asociado con problemas de verificación, verificación y prueba de software. Verificación Es el proceso de determinar si el estado actual de desarrollo alcanzado en una etapa determinada cumple con los requisitos de esa etapa. Examen le permite evaluar el cumplimiento de los parámetros de desarrollo con los requisitos iniciales. El cheque coincide parcialmente con pruebas, que está asociado con la identificación de diferencias entre los resultados reales y esperados y la evaluación del cumplimiento de las características del software con los requisitos iniciales. En el proceso de implementación del proyecto, un lugar importante lo ocupan las cuestiones de identificación, descripción y control de la configuración de los componentes individuales y de todo el sistema en su conjunto.

Gestión de proyectos asociado con cuestiones de planificación y organización del trabajo, creación de equipos de desarrollo y seguimiento del tiempo y la calidad del trabajo realizado. El apoyo técnico y organizativo del proyecto incluye la selección de métodos y herramientas para la implementación del proyecto, determinación de métodos para describir estados intermedios de desarrollo, desarrollo de métodos y herramientas para pruebas de software, capacitación de personal, etc.

Cada proceso se caracteriza por:

tareas específicas y métodos para resolverlas,

los datos iniciales obtenidos en la etapa anterior,

resultados.

Los resultados del análisis, en particular, son modelos funcionales, modelos de información y sus correspondientes diagramas. El software del ciclo de vida lleva naturaleza iterativa: Los resultados de la siguiente etapa a menudo provocan cambios en las soluciones de diseño desarrolladas en etapas anteriores.

Modelos de ciclo de vida del software.

El estándar ISO/IEC 12207 no proporciona un modelo de ciclo de vida específico ni métodos de desarrollo de software. (El modelo de ciclo de vida depende de las características específicas del sistema de información y de las condiciones específicas en las que este último se crea y opera). Su normativa es común a cualquier modelo de ciclo de vida, metodologías y tecnologías de desarrollo. El estándar ISO/IEC 12207 describe la estructura de los procesos del ciclo de vida del software, pero no especifica en detalle cómo implementarlos o realizarlos. comportamiento Y tareas incluidos en estos procesos.

Hasta la fecha, los siguientes dos modelos principales de ciclo de vida se han generalizado:

· modelo en cascada (70-85);

· modelo espiral (86-90).

En el SI homogéneo original, cada aplicación era un todo único. Para desarrollar este tipo de aplicación utilizamos método en cascada. Su característica principal es la división de todo el desarrollo en etapas, y la transición de una etapa a la siguiente ocurre solo después de que se completan por completo los trabajos en la actual (Fig. 1). Cada etapa culmina con la publicación de un conjunto completo de documentación suficiente para permitir que otro equipo de desarrollo continúe el desarrollo.

Los aspectos positivos de utilizar el enfoque en cascada son los siguientes:

· en cada etapa, se genera un conjunto completo de documentación de diseño que cumple con los criterios de integridad y coherencia;

· las etapas de trabajo realizadas en una secuencia lógica nos permiten planificar el tiempo de finalización de todos los trabajos y los costos correspondientes.

Arroz. 1. Esquema de desarrollo de software en cascada.

El enfoque en cascada ha demostrado su eficacia en la construcción de sistemas de información, para los cuales, al comienzo del desarrollo, todos los requisitos pueden formularse con bastante precisión y de manera completa para brindar a los desarrolladores la libertad de implementarlos lo mejor posible desde un punto de vista técnico. Punto de vista. En esta categoría entran los sistemas de cálculo complejos, los sistemas en tiempo real y otras tareas similares. Sin embargo, en el proceso de aplicación de este enfoque, se descubrieron varias deficiencias, causadas principalmente por el hecho de que el proceso real de creación de software nunca encaja completamente en un esquema tan rígido:

· Identificar las razones por las que es necesario cambiar un proyecto en etapas posteriores.: normalmente no se comprueba la funcionalidad y viabilidad de un proyecto de aplicación en las primeras etapas.

· Gestión de riesgos inadecuada: los riesgos asociados con el proyecto se identifican en las últimas etapas del proyecto.

· No hay procedimiento para revisar requisitos: En este modelo, los requisitos deben formularse y registrarse en las primeras etapas de desarrollo. Como regla general, las metas y objetivos del proyecto no se comprenden completamente al comienzo del proyecto y, por lo tanto, deben revisarse en etapas posteriores, lo que conduce a un aumento significativo en los costos de desarrollo y retrasos en el lanzamiento del producto. Si los requisitos modificados no se tienen en cuenta en el proyecto, el cliente no considerará que la aplicación cumple con los objetivos.

Arroz. 2 Proceso real de desarrollo de software utilizando un esquema en cascada

Por tanto, la principal desventaja del enfoque en cascada es un retraso significativo en la obtención de resultados. La coordinación de los resultados con los usuarios se lleva a cabo únicamente en los puntos planificados después de la finalización de cada etapa del trabajo, los requisitos para el SI están "congelados" en forma de especificaciones técnicas durante todo el tiempo de su creación. Por lo tanto, los usuarios pueden hacer sus comentarios sólo después de que el trabajo en el sistema esté completamente completado. Si los requisitos no se establecen con precisión o cambian durante un largo período de desarrollo de software, los usuarios terminan con un sistema que no satisface sus necesidades. Los modelos (tanto funcionales como informativos) del objeto automatizado pueden quedar obsoletos simultáneamente con su aprobación.

Así, en el proceso de creación de software, existía una constante necesidad de volver a etapas anteriores y aclarar o revisar decisiones tomadas previamente. Como resultado, el proceso real de creación de software tomó la siguiente forma (Fig. 2):

Para superar estos problemas se propuso modelo de ciclo de vida en espiral(Fig. 3), centrándose en las etapas iniciales del ciclo de vida: análisis y diseño. En estas etapas se prueba la viabilidad de las soluciones técnicas mediante la creación de prototipos. Cada vuelta de la espiral corresponde a la creación de un fragmento o versión de software. Aclara los objetivos y características del proyecto, determina su calidad y planifica el trabajo de la siguiente vuelta de la espiral. De esta manera, los detalles del proyecto se profundizan y se especifican consistentemente y, como resultado, se selecciona una opción razonable, que se lleva a la implementación.

El desarrollo por iteraciones refleja el ciclo espiral objetivamente existente de creación de un sistema. La finalización incompleta del trabajo en cada etapa le permite pasar a la siguiente etapa sin esperar a que se complete por completo la etapa actual. Con un método de desarrollo iterativo, el trabajo faltante se puede completar en la siguiente iteración. La tarea principal es mostrar a los usuarios del sistema un producto viable lo más rápido posible, activando así el proceso de clarificación y complementación de requisitos.

El principal problema del ciclo en espiral es determinar el momento de transición a la siguiente etapa. Para solucionarlo es necesario introducir restricciones de tiempo para cada etapa del ciclo de vida. La transición avanza según lo planeado, incluso si no se completa todo el trabajo planificado. El plan se elabora a partir de datos estadísticos obtenidos en proyectos anteriores y la experiencia personal de los desarrolladores.

El modelo de ciclo de vida en espiral pone énfasis en las etapas iniciales del ciclo de vida: análisis y diseño. En estas etapas se prueba la viabilidad de las soluciones técnicas mediante la creación de prototipos. Cada vuelta de la espiral corresponde a la creación de un fragmento o versión del software, donde se aclaran los objetivos y características del proyecto, se determina su calidad y se planifica el trabajo de la siguiente vuelta de la espiral. De esta manera, los detalles del proyecto se profundizan y se especifican consistentemente, y como resultado, se selecciona una opción razonable, que se lleva a la implementación.

Arroz. 3. Modelo de ciclo de vida en espiral

Al crear software se puede utilizar. "Un modelo de reutilización e ingeniería inversa".

En él, el peso principal de las decisiones de diseño recae en el diseño. El propósito de este modelo es la reutilización (reutilización) en proyectos actuales de soluciones de diseño "antiguas" bien probadas registradas en bibliotecas de proyectos ya completados. Durante el proceso de análisis y diseño preliminar, se delinean planes de trabajo que incluyen tareas para probar soluciones de diseño alternativas. Luego se comienza a trabajar en la creación de los prototipos planificados mediante un esquema en cascada. Como resultado, se selecciona una de las soluciones alternativas, desarrollada en iteraciones paralelas durante el resto del ciclo de desarrollo del producto. Es posible seleccionar una opción mixta basada en la combinación de los resultados de varios turnos.

Si la versión implementada falla, es posible una reversión del proyecto (Reingeniería).

El desarrollo de software es imposible sin comprender el llamado ciclo de vida del software. Puede que el usuario medio no necesite saber esto, pero es recomendable dominar los estándares básicos (más adelante se dirá por qué es necesario).

¿Qué es el ciclo de vida en un sentido formal?

Se suele entender por ciclo de vida de cualquier aplicación el tiempo de su existencia, desde la etapa de desarrollo y hasta el momento del abandono total de su uso en el campo de aplicación elegido, hasta la retirada total de la aplicación de su uso.

En términos simples, los sistemas de información en forma de programas, bases de datos o incluso “sistemas operativos” sólo tienen demanda si los datos y las oportunidades que brindan están actualizados.

Se cree que la definición del ciclo de vida no se aplica de ninguna manera a las aplicaciones de prueba, como las versiones beta, que son las más inestables en funcionamiento. El ciclo de vida del software en sí depende de muchos factores, entre los cuales uno de los papeles principales lo desempeña el entorno en el que se utilizará el programa. Sin embargo, es posible identificar condiciones generales utilizadas en la definición del concepto de ciclo de vida.

Requisitos iniciales

formulación del problema;
análisis de requisitos mutuos del futuro software para el sistema;
diseño;
programación;
codificación y compilación;
pruebas;
depuración;
Implementación y mantenimiento del producto software.

El desarrollo de software consta de todas las etapas mencionadas anteriormente y no puede prescindir de al menos una de ellas. Pero se han establecido normas especiales para el control de dichos procesos.

Estándares de proceso del ciclo de vida del software

Entre los sistemas que predeterminan las condiciones y requisitos para dichos procesos, hoy podemos nombrar solo tres principales:

GOST 34.601-90;
ISO/CEI 12207:2008;
MDL de Oracle.

Para el segundo estándar internacional existe un análogo ruso. Este es GOST R ISO/IEC 12207-2010, que es responsable de la ingeniería de sistemas y software. Pero el ciclo de vida del software descrito en ambas reglas es esencialmente idéntico. Esto se explica de forma muy sencilla.

Tipos de software y actualizaciones

Por cierto, para la mayoría de los programas multimedia conocidos actualmente, son un medio para guardar parámetros de configuración básicos. El uso de software de este tipo es, por supuesto, bastante limitado, pero comprender los principios generales de cómo trabajar con los mismos reproductores multimedia no vendrá mal. Y es por eso.

De hecho, incluyen el ciclo de vida del software solo al nivel de actualizar la versión del propio reproductor o instalar códecs y decodificadores. Y los transcodificadores de audio y video son atributos integrales de cualquier sistema de audio o video.

Ejemplo basado en FL Studio

Inicialmente, el estudio-secuenciador virtual FL Studio se llamaba Fruity Loops. El ciclo de vida del software en su modificación inicial ha caducado, pero la aplicación se ha transformado un poco y ha adquirido su forma actual.

Si hablamos de las etapas del ciclo de vida, primero, en la etapa de planteamiento del problema, se establecieron varias condiciones obligatorias:

crear un módulo de batería similar a las cajas de ritmo como Yamaha RX, pero utilizando muestras one-shot o secuencias en formato WAV, grabadas en vivo en estudios;
integración en sistemas operativos Windows;
la capacidad de exportar un proyecto en formatos WAV, MP3 y OGG;
Compatibilidad de proyectos con la aplicación adicional Fruity Tracks.

En la etapa de desarrollo se utilizaron herramientas del lenguaje de programación C. Pero la plataforma parecía bastante primitiva y no proporcionaba al usuario final la calidad de sonido requerida.

En este sentido, en la etapa de prueba y depuración, los desarrolladores tuvieron que seguir el camino de la corporación alemana Steinberg y aplicar soporte para el modo Full Duplex en los requisitos para el controlador de sonido principal. La calidad del sonido ha mejorado y le permite cambiar el tempo, el tono y aplicar efectos FX adicionales en tiempo real.

Se considera que el final del ciclo de vida de este software es el lanzamiento de la primera versión oficial de FL Studio, que, a diferencia de sus antepasados, ya contaba con la interfaz de un secuenciador completo con la capacidad de editar parámetros en un 64 virtual. Consola de mezclas de dos canales con adición ilimitada de pistas de audio y pistas MIDI.

No se detuvo ahí. En la etapa de gestión del proyecto, se introdujo el soporte para conectar complementos del formato VST (primero la segunda versión y luego la tercera), que alguna vez fue desarrollado por Steinberg. En términos generales, cualquier sintetizador virtual que admita VST-host podría conectarse al programa.

No es de extrañar que pronto cualquier compositor pueda utilizar análogos de modelos de "hardware", por ejemplo, conjuntos completos de sonidos del otrora popular Korg M1. Además. El uso de módulos como Addictive Drums o el complemento universal Kontakt hizo posible reproducir sonidos en vivo de instrumentos reales grabados con todos los matices de articulación en estudios profesionales.

Al mismo tiempo, los desarrolladores intentaron lograr la máxima calidad creando soporte para los controladores ASIO4ALL, que resultaron estar muy por encima del modo Full Duplex. En consecuencia, la tasa de bits también aumentó. Hoy en día, la calidad del archivo de audio exportado puede ser de 320 kbps a una frecuencia de muestreo de 192 kHz. Y este es sonido profesional.

En cuanto a la versión inicial, su ciclo de vida podría considerarse completamente completo, pero tal afirmación es relativa, ya que la aplicación solo cambió de nombre y adquirió nuevas capacidades.

Perspectivas de desarrollo

Ya está claro cuáles son las etapas del ciclo de vida del software. Pero vale la pena mencionar por separado el desarrollo de tales tecnologías.

No hace falta decir que ningún desarrollador de software está interesado en crear un producto fugaz que probablemente no sobrevivirá en el mercado durante varios años. A largo plazo, todo el mundo está mirando su uso a largo plazo. Esto se puede lograr de diferentes maneras. Pero, por regla general, casi todos se reducen al lanzamiento de actualizaciones o nuevas versiones de programas.

Incluso en el caso del sistema operativo Windows, estas tendencias se pueden ver a simple vista. Es poco probable que hoy haya al menos un usuario que utilice sistemas como las modificaciones 3.1, 95, 98 o Millennium. Su ciclo de vida terminó después del lanzamiento de XP. Pero las versiones de servidores basadas en tecnologías NT siguen siendo relevantes. Incluso Windows 2000 hoy en día no sólo es muy relevante, sino que en algunos parámetros de instalación o seguridad incluso supera a los últimos desarrollos. Lo mismo se aplica al sistema NT 4.0, así como a una modificación especializada de Windows Server 2012.

Pero en relación con estos sistemas, el apoyo todavía se declara al más alto nivel. Pero el otrora sensacional Vista está experimentando claramente el declive de su ciclo. No sólo resultó inacabado, sino que tenía tantos errores y lagunas en su sistema de seguridad que uno sólo puede adivinar cómo una solución tan insostenible pudo lanzarse al mercado del software.

Pero si decimos que el desarrollo de software de cualquier tipo (control o aplicación) no se detiene, solo podemos decir que hoy en día se trata no solo de sistemas informáticos, sino también de dispositivos móviles, en los que las tecnologías utilizadas suelen estar por delante de las sector informático. ¿La aparición de chips de procesador basados en ocho núcleos no es el mejor ejemplo? Pero no todos los portátiles pueden presumir de tener dicho hardware.

Algunas preguntas adicionales

En cuanto a la comprensión del ciclo de vida del software, se puede decir de manera muy condicional que terminó en un momento determinado, porque los productos de software todavía cuentan con el apoyo de los desarrolladores que los crearon. Más bien, el final se refiere a aplicaciones heredadas que no cumplen con los requisitos de los sistemas modernos y no pueden ejecutarse en su entorno.

Pero incluso teniendo en cuenta el progreso tecnológico, muchos de ellos pronto podrían volverse insostenibles. Luego tendrá que tomar la decisión de publicar actualizaciones o revisar completamente todo el concepto incorporado originalmente en el producto de software. De ahí el nuevo ciclo, que implica cambiar las condiciones iniciales, el entorno de desarrollo, las pruebas y el posible uso a largo plazo en un área determinada.

Pero en la tecnología informática hoy en día se da preferencia al desarrollo de sistemas de control automatizados (ACS), que se utilizan en la producción. Incluso los sistemas operativos, en comparación con los programas especializados, pierden.

Los entornos basados en Visual Basic siguen siendo mucho más populares que los sistemas Windows. Y no estamos hablando en absoluto de software de aplicación para sistemas UNIX. Qué podemos decir si casi todas las redes de comunicación de un mismo Estados Unidos funcionan exclusivamente para ellos. Por cierto, sistemas como Linux y Android también se crearon originalmente en esta plataforma. Por lo tanto, lo más probable es que UNIX tenga muchas más perspectivas que otros productos juntos.

En lugar de un total

Queda por agregar que en este caso solo se dan principios generales y etapas del ciclo de vida del software. De hecho, incluso las tareas inicialmente planteadas pueden variar de forma muy significativa. En consecuencia, se pueden observar diferencias en otras etapas.

Pero las tecnologías básicas para desarrollar productos de software y su posterior soporte deben quedar claras. Por lo demás, se deben tener en cuenta las características específicas del software que se está creando, los entornos en los que se supone que debe funcionar y las capacidades de los programas proporcionados al usuario final o al productor, y mucho más.

Además, en ocasiones los ciclos de vida pueden depender de la relevancia de las herramientas de desarrollo. Si, por ejemplo, un lenguaje de programación se vuelve obsoleto, nadie escribirá programas basados en él, y mucho menos los implementará en sistemas automatizados de control de producción. Aquí ni siquiera los programadores pasan a primer plano, sino los especialistas en marketing quienes deben responder de manera oportuna a los cambios en el mercado de las computadoras. Y no hay tantos especialistas de este tipo en el mundo. El personal altamente cualificado que sabe estar al tanto del mercado se está convirtiendo en el más solicitado. Y a menudo son los llamados "cardenales grises" de quienes depende el éxito o el fracaso de un determinado producto de software en el campo de TI.

Puede que no siempre comprendan la esencia de la programación, pero son claramente capaces de determinar modelos del ciclo de vida del software y la duración de su uso, basándose en las tendencias globales en esta área. La gestión eficaz suele producir resultados más tangibles. Sí, al menos tecnologías de relaciones públicas, publicidad, etc. Es posible que el usuario no necesite alguna aplicación, pero si se anuncia activamente, la instalará. Esto ya es, por así decirlo, un nivel subconsciente (el mismo efecto del cuadro 25, cuando la información se introduce en la conciencia del usuario independientemente de él).

Por supuesto, estas tecnologías están prohibidas en el mundo, pero muchos de nosotros ni siquiera nos damos cuenta de que todavía pueden usarse e influir en el subconsciente de cierta manera. Basta mirar el costo de la "zombificación" por parte de los canales de noticias o sitios de Internet, sin mencionar el uso de medios más poderosos, como la exposición al infrasonido (esto se usó en una producción de ópera), como resultado de lo cual una persona puede experimentar miedo o emociones inapropiadas.

Volviendo al software, cabe añadir que algunos programas utilizan una señal sonora al iniciarse para atraer la atención del usuario. Y, como muestran las investigaciones, dichas aplicaciones son más viables que otros programas. Naturalmente, el ciclo de vida del software también aumenta, independientemente de la función que se le haya asignado inicialmente. Y, lamentablemente, muchos desarrolladores utilizan esto, lo que genera dudas sobre la legalidad de dichos métodos.

Pero no nos corresponde a nosotros juzgar esto. Es posible que en un futuro próximo se desarrollen herramientas para identificar dichas amenazas. Hasta el momento esto es sólo una teoría, pero, según algunos analistas y expertos, queda muy poco antes de la aplicación práctica. Si ya están creando copias de las redes neuronales del cerebro humano, ¿qué podemos decir?

El ciclo de vida del software incluye seis etapas:

- análisis de requerimientos;

– determinación de especificaciones;

- diseño;

– codificación;

– pruebas;

– acompañamiento.

Análisis de requerimientos. Es extremadamente importante en el desarrollo de software. Los errores cometidos en esta etapa, incluso si las etapas posteriores se llevan a cabo sin problemas, pueden llevar al hecho de que el producto de software desarrollado no cumplirá con los requisitos de la práctica y el alcance de su aplicación. Para crear productos competitivos durante esta etapa, se deben obtener respuestas claras a las siguientes preguntas:

– ¿Qué debería hacer el programa?

– ¿Cuáles son los problemas reales que debería ayudar a resolver?

– ¿Cuáles son los datos de entrada?

– ¿Cuáles deberían ser los datos de salida?

– ¿Qué recursos tiene el diseñador?

Definición de especificaciones. Especificación– una descripción formal precisa y completa de las propiedades, características y funciones de un programa, elemento de datos u otro objeto. Hasta cierto punto, esta etapa puede considerarse como la formulación de conclusiones a partir de los resultados de la etapa anterior. Los requisitos del programa deben expresarse como un conjunto de especificaciones que definen explícitamente las características de desempeño del programa futuro. Dichas características pueden incluir velocidad de ejecución, cantidad de memoria consumida, flexibilidad de uso, etc.

Diseño. En esta etapa se crea la estructura general del programa, la cual debe satisfacer las especificaciones; Se determinan los principios generales de gestión e interacción entre los distintos componentes del programa.

Codificación. Consiste en traducir estructuras escritas en un lenguaje de diseño a un lenguaje de programación.

Pruebas. En esta etapa se realiza una verificación exhaustiva de los programas.

Escolta. Esta es la etapa operativa del sistema. No importa cuán sofisticadas puedan ser las pruebas de programas, desafortunadamente, en grandes sistemas de software es extremadamente difícil eliminar absolutamente todos los errores. Eliminar los errores descubiertos durante la operación es la tarea principal de esta etapa. Sin embargo, esto no es todo lo que se logra durante el soporte. El análisis de la experiencia operativa del programa realizado durante el mantenimiento nos permite detectar “cuellos de botella” o soluciones de diseño fallidas en determinadas partes del paquete de software. Como resultado de dicho análisis, se puede tomar la decisión de realizar trabajos para mejorar el sistema desarrollado. El soporte también puede incluir consultas, capacitación de los usuarios del sistema y suministro rápido de información a los usuarios sobre nuevas versiones del sistema. La calidad de la fase de mantenimiento determina en gran medida el éxito comercial de un producto de software.

Pruebas. Hay tres aspectos a la hora de comprobar un programa:

– corrección;

– eficiencia de la implementación;

- complejidad computacional.

La validación garantiza que un programa haga exactamente aquello para lo que fue diseñado. La perfección matemática de un algoritmo no garantiza la exactitud de su traducción en un programa. Asimismo, ni la ausencia de mensajes de diagnóstico del compilador ni la apariencia razonable de los resultados obtenidos ofrecen garantía suficiente de la corrección del programa. Normalmente, la validación implica desarrollar y ejecutar un conjunto de pruebas. Además, para calcular programas, a veces es posible comparar las soluciones resultantes con una solución ya conocida. En general, es imposible dar una solución general para comprobar la corrección de un programa.

La prueba de la complejidad computacional, por regla general, consiste en un análisis experimental de la complejidad de un algoritmo o una comparación experimental de dos o más algoritmos que resuelven el mismo problema.

Probar la efectividad de una implementación tiene como objetivo encontrar una manera de hacer que el programa correcto se ejecute más rápido o use menos memoria. Para mejorar el programa, los resultados de la implementación se revisan durante el proceso de construcción del algoritmo. Sin considerar todas las opciones y direcciones posibles para optimizar programas, presentaremos aquí algunos métodos útiles destinados a aumentar la velocidad de ejecución del programa.

El primer método se basa en la siguiente regla. La suma y la resta son más rápidas que la multiplicación y la división. La aritmética de enteros es más rápida que la aritmética real. Por tanto, X+X es mejor que 2*X, donde * es el signo de multiplicación. Al realizar operaciones con números enteros, recuerde que gracias al uso del sistema numérico binario, la multiplicación por múltiplos de dos se puede sustituir por el número correspondiente de desplazamientos hacia la izquierda.

La segunda forma es eliminar cálculos redundantes.

Una tercera forma de probar la efectividad de una implementación se basa en la capacidad de algunos compiladores de construir código para evaluar expresiones booleanas de modo que la evaluación se detenga cuando el resultado se vuelva obvio. Por ejemplo, en la expresión A, B o C, si A es verdadera, las variables B y C ya no se verifican. Por lo tanto, puede ahorrar tiempo colocando las variables A, B, C de modo que la primera variable sea la que tiene más probabilidades de ser verdadera y la última sea la que tiene menos probabilidades de ser verdadera.

La cuarta técnica es la eliminación de ciclos.

La quinta técnica es el despliegue de ciclos.

Esta no es una lista completa de métodos de optimización. Aquí sólo se dan los más obvios. También cabe señalar que no siempre vale la pena dejarse llevar por la velocidad, ya que esto suele deteriorar la legibilidad de los programas. En el caso de que la ganancia sea "menor", no vale la pena preferirla a la claridad y legibilidad del programa.

El software es un conjunto de programas diseñados para resolver un problema. El ciclo de vida del software es el período de tiempo desde el momento en que surge la necesidad de crear un software hasta el momento en que se retira del servicio. Etapas del ciclo de vida del software que pueden ocurrir de forma secuencial, paralela o casi paralela:

1. desarrollo;

2. operación;

3. acompañamiento.

Durante la fase de soporte, por regla general, se realizan los siguientes tipos de trabajo:

ampliación de la funcionalidad del software;
modificación de funciones existentes;
modificación de software asociada con modificación de hardware;
eliminación de errores de software que no se detectaron durante el desarrollo debido a la imposibilidad de realizar pruebas completas, pero que aparecieron solo durante la fase de operación.

A la hora de realizar el desarrollo se distinguen claramente las siguientes etapas:

determinación de los requisitos de software, lo que implica recopilar la información necesaria.
diseño externo (la información contenida en las especificaciones técnicas está sujeta a análisis y estricta formalización; el objetivo principal de esta etapa es darle al desarrollador la idea más completa y precisa de lo que finalmente se debe lograr). No requerido.
diseño interno (se aclara la información obtenida en las etapas anteriores y se desarrollan las estructuras de datos utilizadas en el software, se determina la estructura modular del software, las reglas para la interacción de los módulos en el proceso de transferencia de control o intercambio de información, etc. .).
programación (codificación).
pruebas y depuración. La prueba es el proceso de identificar la presencia de errores en un programa. Depuración – pruebas + diagnóstico y localización de errores + eliminación de errores.
pruebas de software. Las pruebas son un tipo especial de prueba cuyo propósito es identificar inconsistencias entre el software resultante y los requisitos de las especificaciones técnicas.

Modelos de ciclo de vida del software:

§ modelo en cascada

§ modelo en espiral: cuando pasa una vuelta de la espiral, el resultado es una versión del software. Después de las pruebas, se toma la decisión de desarrollar la siguiente versión o no desarrollarla si esta versión satisface plenamente los requisitos de las especificaciones técnicas.

31. Especificaciones técnicas (GOST 19.201 – 78). Sus principales apartados y sus contenidos.

De acuerdo con esta norma, las especificaciones técnicas incluyen los siguientes apartados:

2. Introducción;

3. base para el desarrollo;

4. propósito del desarrollo;

5. requisitos para el producto de software;

6. requisitos de documentación;

7. indicadores técnicos y económicos;

8. etapas y etapas de desarrollo;

9. procedimiento de control y aceptación

10. aplicación.

Introducción:

§ Nombre;

§ breve descripción del área de aplicación del software.

El objetivo principal de esta sección es demostrar la relevancia de este desarrollo y qué lugar ocupa entre otros similares.

Motivo del desarrollo:

§ nombre del documento a partir del cual se realiza el desarrollo;

§ organización que aprobó este documento;

§ nombre o símbolo del tema de desarrollo.

Dicho documento puede ser un plan, pedido, contrato, etc.

Propósito del desarrollo:

§ descripción de la finalidad funcional y operativa de este sistema, indicando la categoría de sus usuarios.

Requisitos para un programa o producto de software.

Esta sección debe incluir las siguientes subsecciones:

1. requisitos de características funcionales;

2. requisitos de confiabilidad;

3. condiciones de funcionamiento;

4. requisitos para la composición y parámetros de los medios técnicos;

5. requisitos de compatibilidad de información y software;

6. requisitos de etiquetado y embalaje;

7. requisitos de transporte y almacenamiento.

8. requisitos especiales.

La sección de requisitos para las características funcionales debe enumerar todas las funciones y describir la composición, características y formas de presentación de los datos y resultados iniciales. En el mismo apartado, si es necesario, indique los criterios de eficiencia (tiempo máximo de respuesta del sistema, cantidad máxima de memoria utilizada).

La sección de requisitos de confiabilidad debe indicar el nivel de confiabilidad del software que debe garantizarse durante el desarrollo. En sistemas con requisitos de confiabilidad normales, es decir aquellos no relacionados con sistemas en los que existe riesgo para la vida humana, indican adicionalmente acciones de desarrollo del sistema destinadas a aumentar la confiabilidad del sistema (creación de copias de seguridad, bloqueo de acciones peligrosas).

En la sección de condiciones de funcionamiento se indican requisitos especiales para las condiciones de funcionamiento del software (temperatura, humedad). Dichos requisitos son necesarios cuando el software funcionará (operará) en condiciones distintas al centro de desarrollo. Si las condiciones no difieren, además indican que no hay requisitos o omiten esta sección por completo. Esta sección a veces indica los tipos de servicios requeridos y las calificaciones del personal de mantenimiento.

En la sección Requisitos para la composición y parámetros de los medios técnicos se indica la composición requerida y las principales características de los medios técnicos. En este apartado se suelen indicar dos configuraciones de equipamiento técnico: mínima y nominal.

En la sección de requisitos de información y compatibilidad de software, si es necesario, puede especificar los métodos de programación, el entorno de desarrollo y el sistema operativo utilizado. Si se supone que el software se utilizará con otro software, entonces esta sección debe proporcionar una lista de estos software y describir en detalle la interfaz de interacción a nivel de formatos de datos y funciones API.

La sección de requisitos de etiquetado y embalaje especifica los métodos para marcar y empaquetar el software.

La sección de requisitos de transporte y almacenamiento especifica las condiciones de transporte, los lugares de almacenamiento, las condiciones de almacenamiento y los períodos de almacenamiento bajo diversas condiciones.

La sección de requisitos especiales identifica los requisitos que no se incluyen en ninguna de las secciones descritas anteriormente.

Requisitos para la documentación del programa.

Esta sección proporciona una lista de software y documentación operativa que se debe desarrollar junto con el producto de software. Si es necesario, especifica requisitos especiales para la estructura y composición de los documentos. Cantidad mínima de documentación: manual de usuario.

Indicadores técnicos y económicos.

Etapas y etapas de desarrollo.

Indica las etapas y etapas de desarrollo del trabajo que se está realizando, indicando plazos y ejecutores.

Procedimiento de control y aceptación.

Indica el procedimiento de prueba y los requisitos generales para su aceptación.

Solicitud: listado de proyectos de investigación, justificaciones, cálculos y otros documentos que deben utilizarse para el desarrollo.

Dependiendo de las características del software que se esté desarrollando, es posible aclarar las secciones descritas, introducir otras nuevas o combinar las existentes.

32. Diseño de software estructural: método de análisis estructural, diseño de una estructura modular.

El método de análisis estructural se basa en una serie de principios generales, que se enumeran a continuación.

1. Principio de descomposición Y orden jerárquico, que consiste en dividir un problema grande y complejo en muchos subproblemas independientes más pequeños que son fáciles de entender y resolver. Además, se puede llevar a cabo la descomposición de subtareas ya asignadas. Como resultado de dicha descomposición secuencial, el sistema especificado puede entenderse y construirse según niveles jerárquicos, cada uno de los cuales añade nuevos detalles.

2. Principio de abstracción Consiste en resaltar aspectos del sistema que son significativos desde algunas posiciones y abstraer de aquellos que no existen para presentar el problema en una forma general conveniente.

3. Principio de formalización radica en la necesidad de un estricto enfoque metodológico y de resolución de problemas.

4. El principio de ocultación. Consiste en “ocultar” información que no es esencial en una determinada etapa: cada parte “sabe” sólo lo que es necesario.

5. Principio de integridad es controlar la presencia de elementos innecesarios.

6. Principio de coherencia radica en la validez y consistencia de los elementos.

7. Principio de independencia lógica es centrarse en el diseño lógico para garantizar la independencia de la ejecución física.

8. Principio de independencia de datos es que los modelos de datos deben analizarse y diseñarse independientemente de sus procesos lógicos de procesamiento, así como de su estructura física y distribución en la memoria del sistema informático.

9. Principio de estructuración de datos. es que los datos deben estar estructurados y organizados jerárquicamente.

Guiado por todos los principios en su totalidad, es posible en la etapa de especificación comprender cuál será el software que se está desarrollando, detectar errores y deficiencias, lo que, a su vez, facilitará el trabajo en las etapas posteriores del ciclo de vida.

Con el fin de especificar sistemas en análisis estructural, se utilizan tres grupos de herramientas, que ilustran:

* funciones que debe realizar el sistema;

* relaciones entre datos;

* comportamiento del sistema en función del tiempo (aspectos de tiempo real).

Para este propósito:

* DFD (Diagramas de flujo de datos): diagramas de flujo de datos junto con diccionarios de datos y especificaciones de procesos;

* ERD (Diagramas de entidad-relación) – diagramas de entidad-relación;

* STD (Diagramas de transición de estados): diagramas de transición de estados.

El DFD muestra fuentes y sumideros de datos externos al sistema, identifica funciones lógicas (procesos) y grupos de elementos de datos que vinculan una función con otra (hilos) e identifica los almacenes (almacenes de datos) a los que se accede. Las estructuras de flujo de datos y las definiciones de sus componentes se almacenan en un diccionario de datos. Cada función lógica puede detallarse mediante un DFD de nivel inferior. Cuando se agotan los detalles, pasan a describir la lógica utilizando una especificación del proceso.

La estructura de cada repositorio se describe mediante un ERD. En el caso del tiempo real, DFD se complementa con la descripción del comportamiento del sistema en función del tiempo, que se describe mediante STD. Estas conexiones se muestran en la figura.

Relación entre herramientas de análisis estructural.

Diseño de una estructura modular. Un módulo es una unidad de software separada y funcionalmente completa que puede usarse de forma independiente o ser parte de un programa. El software se crea sobre la base de una estructura modular que consta de módulos individuales.

Las ventajas del desarrollo de software utilizando módulos incluyen las siguientes:

El diseño del software se simplifica, ya que un problema grande y complejo es más fácil de entender dividiéndolo en partes funcionales separadas.
Permite organizar la colaboración entre grandes equipos de desarrolladores, ya que cada programador se ocupa de una parte independiente del software: un módulo o grupo de módulos.
La depuración de programas se simplifica, ya que el acceso limitado al módulo y la falta de ambigüedad de su comportamiento externo eliminan la influencia de los errores de otros módulos en su funcionamiento.
La fiabilidad de los programas aumenta, ya que el tamaño relativamente pequeño de los módulos y, en consecuencia, su baja complejidad, permiten un control más completo de los mismos.

Para diseñar y documentar una estructura modular se utilizan mapas estructurales de Constantine, que son un modelo de las relaciones entre módulos de software.

Un mapa de estructura es un gráfico dirigido. Los nodos de los mapas de estructura corresponden a módulos y áreas de datos, y los arcos representan llamadas entre módulos. En este caso, las llamadas cíclicas y condicionales se modelan mediante nodos especiales unidos a arcos.

Elementos de mapas estructurales.

El elemento básico de un mapa estructural es un módulo. Hay diferentes tipos de módulos:

1. El módulo en sí se utiliza para representar el fragmento del software de procesamiento y localizarlo en el diagrama.

2. Subsistema – un conjunto de módulos previamente definidos. Se puede reutilizar cualquier cantidad de veces en cualquier diagrama.

3. Una biblioteca se diferencia de un subsistema en que se define fuera del contexto del sistema.

4. El área de datos se utiliza para indicar módulos que contienen áreas de variables globales (distribuidas).

Tipos de módulos en mapas de estructuras.

Al crear mapas de estructuras, agregar módulos y vincularlos se realiza mediante flujos que demuestran una jerarquía de llamadas. Hay llamadas secuenciales y paralelas. Cuando se llaman secuencialmente, los módulos se pueden llamar en cualquier orden o simultáneamente.

Los nodos condicionales y de iteración se utilizan para modelar llamadas condicionales y cíclicas.

Imágenes de llamadas condicionales e iterativas.

Estructuras modulares típicas. Dependiendo de las tareas resueltas por el desarrollador y del método de diseño elegido, el software modular puede tener una de las siguientes estructuras principales: monolítica - modular; secuencialmente - modular; modular - jerárquico; modular - caótico.

a - monolítico; b - secuencial; c - jerárquico; g – caótico.

La estructura modular monolítica incluye un gran módulo de software que implementa la mayoría de las funciones asignadas al programa. Desde esta parte hay un pequeño número de llamadas a otros módulos de software de tamaño mucho menor. Una estructura de este tipo tiene todas las desventajas del principio de programación no modular: es difícil de entender, probar y mantener.

La estructura modular secuencial incluye varios módulos que transfieren secuencialmente el control entre sí. Esta estructura es simple e intuitiva, pero sólo puede implementarse para tareas relativamente simples.

La estructura jerárquica modular incluye módulos de software ubicados en diferentes niveles de la jerarquía. Los módulos de nivel superior controlan el funcionamiento de los módulos de nivel inferior. Esta estructura es la más preferible y le permite crear programas bastante complejos.

Modulares: estructuras caóticas. Estos programas son difíciles de probar y mantener. Esta estructura sólo es permisible en sistemas de tiempo real con características espacio-temporales estrictas, cuando sea imposible lograrlas utilizando programas con una estructura diferente.

Reglas generales para el diseño estructural de software. En las etapas iniciales del desarrollo de software se forma su estructura y reglas generales para la interacción de componentes, las cuales son las siguientes:

la estructura del software y las reglas para formatear la descripción de cada módulo de software deben estar unificadas;
cada módulo se caracteriza por su integridad funcional, autonomía e independencia en el diseño de los módulos que lo utilizan y a los que llama;
se aplican reglas estándar para organizar las conexiones entre el módulo de control e información (datos) y otros módulos;
El software se desarrolla en forma de un conjunto de módulos de programa, pequeños en número de operadores (hasta 100), conectados de forma jerárquica;
no debería haber ningún efecto después de la siguiente ejecución del programa en ejecuciones posteriores;
se regula el uso de variables locales y registros informáticos.

hogar » Préstamos » Ciclo de vida del proceso de desarrollo. Ciclo de vida de los sistemas de software.