El concepto de ciclo de vida del software. Ciclo de vida de los sistemas de software.

Anotación.

Introducción.

1. Ciclo de vida del software

Introducción.

Pasos del proceso de programación de Riley

Introducción.

1.1.1. Formulación del problema.

1.1.2. Diseño de solución.

1.1.3. Codificación de algoritmos.

1.1.4. Apoyo al programa.

1.1.5. Documentación de software.

Conclusión de la cláusula 1.1

1.2. Determinación de LCPO según Lehman.

Introducción.

1.2.1 Definición del sistema.

1.2.2. Implementación.

1.2.3. Servicio.

Conclusión de la cláusula 1.2.

1.3. Fases y funcionamiento del LCPO según Boehm

1.3.1. Modelo en cascada.

1.3.2. Justificación económica del modelo en cascada.

1.3.3. Mejora del modelo en cascada.

1.3.4. Determinación de las fases del ciclo de vida.

1.3.5. Trabajo principal del proyecto.

Literatura.

Introducción

El uso industrial de las computadoras y la creciente demanda de programas han planteado desafíos urgentes para aumentar significativamente productividad del desarrollo de software, desarrollo de métodos industriales de planificación y diseño de programas, transferencia de técnicas, patrones y métodos organizativos, técnicos, técnicos, económicos y socio-psicológicos del ámbito de la producción material al ámbito del uso de computadoras. Un enfoque complejo a los procesos de desarrollo, operación y mantenimiento de software, planteó una serie de problemas urgentes, cuya solución eliminará los cuellos de botella en el diseño del programa, reducirá el tiempo de finalización del trabajo, mejorará la selección y adaptación de los programas existentes y tal vez determinará el destino de los sistemas con ordenadores integrados.

En la práctica de desarrollar grandes proyectos de software, a menudo no existe enfoque unificado a la evaluación de costes laborales, plazos de trabajo y costes de materiales, lo que dificulta el aumento de la productividad del desarrollo de software y, en definitiva, la gestión eficaz del ciclo de vida del software. Dado que un programa de cualquier tipo se convierte en un producto (excepto, quizás, los programas prototipo educativos), el enfoque para su producción debería ser en muchos aspectos similar al enfoque para la producción de productos industriales, y las cuestiones de diseño del programa se vuelven extremadamente importantes. Esta idea está en el centro del libro de B.W. Boehm “Ingeniería de software”, que utilizamos al escribir este trabajo de curso. En este libro, diseño de software se refiere al proceso de creación de un diseño para un producto de software.

1 ciclo de vida del software

INTRODUCCIÓN

LCPO es un proceso continuo que comienza desde el momento en que se toma la decisión sobre la necesidad de crear software y finaliza en el momento en que se retira completamente del servicio.

Existen varios enfoques para determinar las fases y actividades del ciclo de vida del software (SLC), pasos del proceso de programación, modelos en cascada y en espiral. Pero todos contienen componentes fundamentales comunes: planteamiento del problema, diseño de la solución, implementación y mantenimiento.

La más famosa y completa, quizás, sea la estructura del proceso del ciclo de vida según Boehm, que incluye ocho fases. Se presentará con más detalle en el futuro.

Una de las posibles opciones podría ser una descripción de nivel superior según Lehman, que incluye tres fases principales y representa una descripción del ciclo de vida en el caso más general.

Y, para variar, presentamos los pasos del proceso de programación presentado por D. Riley en el libro “Using the Modula-2 Language”. Esta idea, en mi opinión, es muy sencilla y familiar, y comencemos por ella.

1.1 Pasos en el proceso de programación de Riley

Introducción

El proceso de programación consta de cuatro pasos (Figura 1):

enunciado del problema, es decir obtener una comprensión adecuada de qué tarea debe realizar el programa;

diseñar una solución a un problema ya planteado (en general, dicha solución es menos formal que el programa final);

codificación de programas, es decir, traducir la solución diseñada a un programa que pueda ejecutarse en una máquina;

apoyo al programa, es decir el proceso continuo de resolución de problemas del programa y adición de nuevas funciones.

Arroz. 1.Cuatro pasos de programación.

La programación comienza desde el momento en que usuario, es decir. alguien que necesita un programa para resolver un problema plantea el problema analista de sistemas. El usuario y el analista del sistema definen conjuntamente el planteamiento del problema. Este último luego se transmite algorítmico, quien es responsable de diseñar la solución. Una solución (o algoritmo) representa una secuencia de operaciones, cuya ejecución conduce a la solución de un problema. Dado que el algoritmo a menudo no es adecuado para su ejecución en una máquina, debe traducirse a un programa de máquina. Esta operación la realiza el codificador. El mantenedor es responsable de los cambios posteriores al programa. programador. Y el analista de sistemas, el algorítmico, el codificador y el programador que lo acompaña son todos programadores.

En el caso de un gran proyecto de software, el número de usuarios, analistas de sistemas y algorítmicos puede ser significativo. Además, puede ser necesario volver a pasos anteriores debido a circunstancias imprevistas. Todo esto sirve como argumento adicional para un diseño de software cuidadoso: los resultados de cada paso deben ser completos, precisos y comprensibles.

1.1.1 Planteamiento del problema

Uno de los pasos más importantes en la programación es definir el problema. Funciona como un contrato entre el usuario y los programadores. Al igual que un contrato legalmente mal redactado, un planteamiento del problema mal redactado es inútil. Con un buen planteamiento del problema, tanto el usuario como el programador representan de forma clara e inequívoca la tarea que debe realizarse, es decir, en este caso se tienen en cuenta los intereses tanto del usuario como del programador. El usuario puede planificar el uso de software que aún no se ha creado, basándose en el conocimiento de lo que puede hacer. Un buen planteamiento del problema sirve como base para formular su solución.

Formulación del problema (especificación del programa); Básicamente significa una descripción precisa, completa y comprensible de lo que sucede cuando se ejecuta un programa específico. El usuario suele mirar el ordenador como una caja negra: para él no importa cómo funciona el ordenador, lo importante es lo que el ordenador puede hacer que le interese al usuario. En este caso, la atención principal se centra en la interacción del hombre con la máquina.

Características de un buen planteamiento del problema:

Exactitud, es decir. eliminando cualquier ambigüedad. No debería haber dudas sobre cuál será el resultado del programa para cualquier entrada determinada.

Lo completo, es decir. considerando todas las opciones para una entrada determinada, incluidas las entradas erróneas o no intencionadas, y determinando la salida adecuada.

Claridad, es decir. debe ser comprensible tanto para el usuario como para el analista del sistema, ya que el planteamiento del problema es el único contrato entre ellos.

A menudo, los requisitos de precisión, integridad y claridad entran en conflicto. Por lo tanto, muchos documentos legales son difíciles de entender porque están escritos en un lenguaje formal, lo que permite formular ciertas disposiciones con extrema precisión, excluyendo cualquier discrepancia menor. Por ejemplo, algunas preguntas de los exámenes a veces se formulan con tanta precisión que el estudiante dedica más tiempo a comprender la pregunta que a responderla. Además, es posible que el estudiante ni siquiera comprenda el significado principal de la pregunta debido a la gran cantidad de detalles. La mejor formulación del problema es aquella que logra un equilibrio de los tres requisitos.

Forma estándar de planteamiento del problema.

Considere el siguiente enunciado del problema: "Ingrese tres números y genere los números en orden".

Tal declaración no satisface los requisitos anteriores: no es exacta, ni completa, ni comprensible. De hecho, ¿se deben ingresar los números uno por línea o todos los números en una sola línea? ¿La expresión "en orden" significa ordenar de mayor a menor, de menor a mayor, o el mismo orden en que fueron introducidos?

Evidentemente, semejante afirmación no responde a muchas preguntas. Si tenemos en cuenta las respuestas a todas las preguntas, el planteamiento del problema será detallado y difícil de entender. Por lo tanto, D. Riley sugiere utilizar un formulario estándar para plantear el problema, que garantice la máxima precisión, integridad y claridad e incluya:

nombre de la tarea (definición esquemática);

descripción general (breve resumen de la tarea);

errores (las opciones de entrada inusuales se enumeran explícitamente para mostrar a los usuarios y programadores qué acciones tomaría la máquina en tales situaciones);

ejemplo (un buen ejemplo puede transmitir la esencia del problema y también ilustrar diferentes casos).

Ejemplo. Planteamiento del problema en forma estándar.

NOMBRE

Ordenar tres números enteros.

DESCRIPCIÓN

Entrada y salida de tres números enteros, ordenados de menor a mayor.

Se ingresan tres números enteros, un número por línea. Un número entero es uno o más dígitos decimales consecutivos, que pueden ir precedidos por un signo más “+” o un signo menos “–”.

Se imprimen los tres números enteros ingresados y los tres se imprimen en la misma línea. Los números adyacentes están separados por un espacio. Los números se muestran de menor a mayor, de izquierda a derecha.

1) Si se ingresan menos de tres números, el programa espera una entrada adicional.

2) Se ignoran las líneas de entrada distintas de las tres primeras.

Ciclo vital es un modelo para crear y utilizar un sistema de software. Refleja los distintos estados de un sistema de software, desde el momento en que surge la necesidad de este sistema de software y se toma la decisión de crearlo, hasta la retirada completa del sistema de software.

La norma internacional ISOIES 12207 define un marco de ciclo de vida que contiene los procesos, actividades y tareas que deben realizarse durante la creación de software. Según esta norma, el ciclo de vida del software se basa en tres grupos de procesos:

los principales procesos del ciclo de vida, es decir, adquisición, entrega, desarrollo, operación y mantenimiento;

procesos auxiliares que aseguran la implementación de los procesos principales, es decir, documentación, verificación, certificación, evaluación de calidad y otros;

procesos organizacionales, es decir, gestión de proyectos, creación de infraestructura de proyectos y capacitación.

El desarrollo incluye todo el trabajo para crear software de acuerdo con los requisitos especificados. Esto incluye la preparación de documentación operativa y de diseño, preparación de materiales necesarios para probar la funcionalidad y calidad de los productos de software.

Principales etapas del proceso de desarrollo:

análisis de los requisitos del cliente;

diseño;

implementación (programación).

El proceso de operación incluye trabajos de puesta en funcionamiento del software, incluida la configuración de estaciones de trabajo, capacitación del personal, localización de problemas operativos y eliminación de las causas de su aparición, modificación del software dentro de las regulaciones establecidas y preparación de propuestas para la modernización del sistema.

Cada proceso se caracteriza por determinadas tareas y métodos para resolverlas, así como por datos y resultados iniciales.

El ciclo de vida del software es, por regla general, de naturaleza iterativa, es decir, se implementan etapas, comenzando desde las más tempranas, que se repiten cíclicamente de acuerdo con los requisitos cambiantes de las condiciones externas y la introducción de restricciones.

Modelos de ciclo de vida del software.

Existen varios modelos de ciclo de vida que determinan el orden de ejecución de las etapas de desarrollo y los criterios de transición de una etapa a otra. Hasta la fecha, los más extendidos son dos modelos de ciclo de vida: cascada Y espiral.

En los sistemas de información homogéneos existentes anteriormente, cada aplicación era un todo único. Para desarrollar dichas aplicaciones se utilizó un modelo de ciclo de vida en cascada, también llamado clásico o cascada.

Cuando se utilizó el modelo en cascada, el desarrollo se consideró como una secuencia de etapas, y la transición a la siguiente etapa inferior se produjo solo después de que todo el trabajo en la etapa actual se completó por completo. La implicación es que en el modelo en cascada, el desarrollo comienza a nivel del sistema y continúa a través del análisis, diseño, codificación, pruebas y mantenimiento.

Figura 1 – Principales etapas del desarrollo de un modelo en cascada

1. El análisis del sistema especifica el papel de cada elemento en un sistema informático y la interacción de los elementos entre sí. Dado que el software se considera parte de un sistema más grande, el análisis comienza determinando los requisitos para todos los elementos del sistema. La necesidad de un análisis del sistema se manifiesta claramente cuando se forma la interfaz del software con otros elementos, es decir, con hardware o bases de datos. En la misma etapa comienza la solución a los problemas de planificación del proyecto. Durante la planificación del proyecto, se determina el volumen de trabajo del proyecto y su riesgo, los costos laborales requeridos, se forman las tareas de trabajo y un cronograma de trabajo.

El análisis de requisitos se refiere a un único elemento de software. En esta etapa se aclaran y detallan las funciones de cada elemento, sus características e interfaz. En la misma etapa se completa la solución al problema de planificación del proyecto.

2. El diseño consiste en crear:

arquitecturas de software;

estructura de software modular;

estructura algorítmica del software;

estructuras de datos;

interfaz de entrada/salida (formularios de datos de entrada/salida).

Al resolver problemas de diseño, se presta especial atención a la calidad del futuro producto de software.

3. La codificación o desarrollo consiste en traducir los resultados del diseño al código del programa.

4. La prueba es la ejecución de un programa para identificar defectos en las funciones, lógica y forma de implementación de un producto de software.

5. El mantenimiento consiste en realizar cambios en el software operativo para:

corrección de errores;

adaptación a cambios en el entorno externo al software;

Mejora del software de acuerdo con los requisitos del cliente.

Ventajas de utilizar el modelo en cascada:

brinda un plan y un cronograma para todas las etapas del proyecto, agilizando así el progreso del desarrollo;

en cada etapa, se genera un conjunto completo de documentación de diseño, cuya integridad y coherencia se verifican;

Las etapas del trabajo realizadas en una secuencia lógica permiten planificar el momento de finalización de todo el trabajo y los costos correspondientes.

El modelo en cascada ha demostrado su eficacia en la construcción de sistemas de información, para los cuales, al comienzo del desarrollo, es posible formular con bastante precisión todos los requisitos del sistema, por ejemplo, sistemas de cálculo complejos, varios sistemas en tiempo real, etc. .

Desventajas del modelo en cascada:

los proyectos reales a menudo requieren desviaciones de la secuencia estándar de pasos;

el modelo en cascada se basa en la formulación precisa de los requisitos iniciales del software, pero en realidad, en varios casos, al inicio del proyecto, los requisitos del cliente sólo están determinados parcialmente;

Los resultados del proyecto están disponibles para el cliente sólo después de la finalización de todo el trabajo.

Debido a la necesidad en el proceso de creación de software de volver constantemente a etapas anteriores y aclarar o revisar decisiones tomadas previamente, el proceso real de desarrollo de software basado en el modelo en cascada se puede representar mediante el siguiente diagrama (Fig. 2).

Figura 2 – Proceso de desarrollo de software basado en el modelo en cascada

Estándares del ciclo de vida del software.

GOST 34.601-90
ISO/IEC 12207:1995 (equivalente ruso - GOST R ISO/IEC 12207-99)

Metodologías de desarrollo de software.

Proceso Unificado Racional (RUP).
Marco de soluciones de Microsoft (MSF). Incluye 4 fases: análisis, diseño, desarrollo, estabilización, implica el uso de modelado orientado a objetos.
Programación extrema ( Programación extrema, XP). La metodología se basa en el trabajo en equipo y la comunicación efectiva entre el cliente y el contratista durante todo el proyecto de desarrollo de IP. El desarrollo se lleva a cabo mediante prototipos sucesivamente perfeccionados.

Estándar GOST 34.601-90

El estándar GOST 34.601-90 prevé las siguientes etapas y etapas en la creación de un sistema automatizado:

Formación de requisitos para oradores.
1. Inspección de la instalación y justificación de la necesidad de crear una central nuclear
2. Formación de requisitos de usuario para hablantes.
3. Elaboración de un informe sobre la finalización del trabajo y una solicitud para el desarrollo de una central nuclear.
Desarrollo del concepto AC
1. Estudiando el objeto
2. Realizar los trabajos de investigación necesarios.
3. Desarrollo de opciones de concepto de CA y selección de una opción de concepto de CA que cumpla con los requisitos del usuario.
4. Elaboración de un informe sobre el trabajo realizado.
Tarea técnica
1. Elaboración y aprobación de especificaciones técnicas para la creación de centrales nucleares.
Diseño preliminar
1. Desarrollo de soluciones de diseño preliminar para el sistema y sus partes.
Proyecto técnico
1. Desarrollo de soluciones de diseño para el sistema y sus partes.
2. Desarrollo de documentación para el sistema de altavoces y sus partes.
3. Desarrollo y ejecución de documentación para el suministro de componentes.
4. Desarrollo de tareas de diseño en partes adyacentes del proyecto.
Documentación de trabajo
1. Elaboración de documentación de trabajo para la central nuclear y sus partes.
2. Desarrollo y adaptación de programas.
Puesta en servicio
1. Preparando un objeto de automatización
2. Capacitación del personal
3. Juego completo de parlantes con productos suministrados (software y hardware, sistemas de software y hardware, productos de información)
4. Trabajos de construcción e instalación.
5. Trabajos de puesta en servicio
6. Realización de pruebas preliminares.
7. Realización de una operación de prueba.
8. Realización de pruebas de aceptación.
Soporte de CA.
1. Realizar trabajos de acuerdo con las obligaciones de garantía.
2. Servicio posgarantía

Los bocetos, los diseños técnicos y la documentación de trabajo son la construcción coherente de soluciones de diseño cada vez más precisas. Es posible excluir la etapa de "Diseño de croquis" y las etapas individuales de trabajo en todas las etapas, combinar las etapas de "Diseño técnico" y "Documentación de trabajo" en un "Diseño técnico detallado", llevar a cabo varias etapas y trabajar en paralelo. , e incluir otros adicionales.

Esta norma no se adapta del todo a la evolución actual: muchos procesos no están suficientemente reflejados y algunas disposiciones están desactualizadas.

ISO/IEC 12207/ norma y su aplicación

La norma ISO/IEC 12207:1995 “Tecnología de la información - Procesos del ciclo de vida del software” es el principal documento normativo que regula la composición de los procesos del ciclo de vida del software. Define una estructura del ciclo de vida que contiene los procesos, actividades y tareas que deben completarse durante la creación del software.

Cada proceso se divide en un conjunto de acciones, cada acción en un conjunto de tareas. Cada proceso, actividad o tarea es iniciado y ejecutado por otro proceso según sea necesario y no existen secuencias de ejecución predeterminadas. Se conservan las conexiones entre los datos de entrada.

Procesos del ciclo de vida del software.

Básico:
- Adquisición (acciones y tareas del cliente que compra el software)
- Entrega (acciones y tareas del proveedor que suministra al cliente un producto o servicio de software)
- Desarrollo (acciones y tareas realizadas por el desarrollador: creación de software, preparación de documentación operativa y de diseño, preparación de materiales de prueba y capacitación, etc.)
- Operación (acciones y tareas del operador - la organización que opera el sistema)
- Mantenimiento (acciones y tareas realizadas por la organización acompañante, es decir, el servicio de soporte). Soporte: realizar cambios en el software para corregir errores, mejorar la productividad o adaptarse a condiciones o requisitos operativos cambiantes.
Auxiliar
- Documentación (descripción formalizada de la información creada durante el ciclo de vida del software)
- Gestión de la configuración (aplicación de procedimientos administrativos y técnicos a lo largo del ciclo de vida del software para determinar el estado de los componentes del software y gestionar sus modificaciones).
- Aseguramiento de la calidad (proporcionar garantías de que el sistema de información y sus procesos de ciclo de vida cumplen con los requisitos especificados y los planes aprobados)
- Verificación (determinar que los productos de software resultantes de alguna acción satisfacen plenamente los requisitos o condiciones impuestos por acciones anteriores)
- Certificación (que determina la integridad del cumplimiento de los requisitos especificados y el sistema creado con su propósito funcional específico)
- Evaluación conjunta (evaluación del estado de los trabajos del proyecto: control de la planificación y gestión de recursos, personal, equipos, herramientas)
- Auditoría (determinación del cumplimiento de requisitos, planes y términos del contrato)
- Resolución de problemas (análisis y resolución de problemas, independientemente de su origen o fuente, que se descubren durante el desarrollo, operación, mantenimiento u otros procesos)
Organizativo
- Control (acciones y tareas que puede realizar cualquier parte que gestione sus procesos)
- Creación de infraestructura (selección y mantenimiento de tecnología, estándares y herramientas, selección e instalación de hardware y software utilizados para el desarrollo, operación o mantenimiento de software)
- Mejora (evaluación, medición, control y mejora de los procesos del ciclo de vida)
- Formación (formación inicial y posterior desarrollo continuo del personal)

Cada proceso incluye una serie de acciones. Por ejemplo, el proceso de adquisición cubre las siguientes actividades:

Inicio de adquisición
Preparación de propuestas de licitación.
Preparación y ajuste del contrato.
Supervisión de actividades de proveedores.
Aceptación y finalización del trabajo.

Cada actividad incluye una serie de tareas. Por ejemplo, la preparación de propuestas de licitación debería incluir:

Formación de requisitos del sistema.
Generar una lista de productos de software
Establecer términos y acuerdos.
Descripción de las limitaciones técnicas (entorno operativo del sistema, etc.)

Etapas del ciclo de vida del software, relaciones entre procesos y etapas.

Modelo de ciclo de vida del software.- una estructura que determina la secuencia de ejecución y las relaciones entre procesos, acciones y tareas a lo largo del ciclo de vida. El modelo de ciclo de vida depende de las características específicas, la escala y la complejidad del proyecto y de las condiciones específicas en las que se crea y opera el sistema.

El estándar GOST R ISO/IEC 12207-99 no ofrece un modelo de ciclo de vida específico. Sus disposiciones son comunes a cualquier modelo, método y tecnología de ciclo de vida para la creación de propiedad intelectual. Describe la estructura de los procesos del ciclo de vida sin especificar cómo implementar o completar las actividades y tareas incluidas en esos procesos.

El modelo de ciclo de vida del software incluye:

Etapas;
Resultados del trabajo en cada etapa;
Los eventos clave son puntos de finalización del trabajo y de la toma de decisiones.

Escenario- parte del proceso de creación de software, limitada por un período de tiempo determinado y que finaliza con el lanzamiento de un producto específico (modelos, componentes de software, documentación), determinado por los requisitos especificados para esta etapa.

En cada etapa se pueden realizar varios procesos definidos en el estándar GOST R ISO/IEC 12207-99 y viceversa, el mismo proceso se puede realizar en diferentes etapas. La relación entre procesos y etapas también está determinada por el modelo de ciclo de vida del software utilizado.

Modelos de ciclo de vida del software.

Un modelo de ciclo de vida es una estructura que define la secuencia de ejecución y las relaciones de los procesos, actividades y tareas realizadas a lo largo del ciclo de vida. 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.

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

Modelo de problema;

modelo (o sistema) en cascada (70-85);

modelo espiral (actual).

modelo de problema

Al desarrollar un sistema "de abajo hacia arriba" desde tareas individuales hasta todo el sistema (modelo de tareas), inevitablemente se pierde un enfoque unificado para el desarrollo y surgen problemas en la conexión de la información de los componentes individuales. Como regla general, a medida que aumenta el número de tareas, aumentan las dificultades y es necesario cambiar constantemente los programas y estructuras de datos existentes. La velocidad de desarrollo del sistema se ralentiza, lo que ralentiza el desarrollo de la propia organización. Sin embargo, en algunos casos esta tecnología puede ser aconsejable:

Extrema urgencia (los problemas deben resolverse de alguna manera; luego habrá que volver a hacer todo);

Experimentación y adaptación del cliente (los algoritmos no están claros, las soluciones se encuentran por ensayo y error).

La conclusión general es que es imposible crear de esta manera un sistema de información suficientemente grande y eficaz.

modelo en cascada

modelo en cascada El ciclo de vida fue propuesto en 1970 por Winston Royce. Prevé la implementación secuencial de todas las etapas del proyecto en un orden estrictamente fijo. La transición a la siguiente etapa significa la finalización completa del trabajo en la etapa anterior (Fig. 1). Los requisitos determinados en la etapa de formación de requisitos se documentan estrictamente en forma de especificaciones técnicas y se registran durante todo el desarrollo del proyecto. 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 permiten planificar el tiempo de finalización de todos los trabajos y los costos correspondientes.

Etapas del proyecto según el modelo de cascada:

Formación de requisitos;
Diseño;
Implementación;
Pruebas;
Implementación;
Operación y mantenimiento.

Arroz. 1. Esquema de desarrollo 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. 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 de sus deficiencias, causadas principalmente por el hecho de que el proceso real de creación de sistemas nunca encaja completamente en un esquema tan rígido. Durante el proceso de creación, hubo una necesidad constante 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):

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

La principal desventaja del enfoque en cascada es el 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 los sistemas de información 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. La esencia de un enfoque sistemático para el desarrollo de SI radica en su descomposición (desglose) en funciones automatizadas: el sistema se divide en subsistemas funcionales, que a su vez se dividen en subfunciones, se subdividen en tareas, etc. El proceso de partición continúa hasta llegar a procedimientos específicos. Al mismo tiempo, el sistema automatizado mantiene una visión holística en la que todos los componentes están interconectados. Así, la principal ventaja de este modelo es su desarrollo sistemático, y sus principales desventajas son su lentitud y su coste.

modelo espiral

Para superar estos problemas se propuso modelo espiral ciclo de vida (Figura 3), que fue desarrollado a mediados de la década de 1980 por Barry Boehm. Se basa 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.

Prototipo- un componente de software operativo que implementa funciones individuales e interfaces externas. Cada iteración corresponde a la creación de un fragmento o versión del software, en el que se aclaran los objetivos y características del proyecto, se evalúa la calidad de los resultados obtenidos y se planifica el trabajo de la siguiente iteración.

Cada iteración representa un ciclo de desarrollo completo, que da como resultado el lanzamiento de una versión interna o externa de un producto (o un subconjunto del producto final) que se mejora de una iteración a otra hasta convertirse en un sistema completo.

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.

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 la finalización completa del trabajo en la 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.

Figura 3. Modelo en espiral del ciclo de vida de un CI.

Un posible enfoque para el desarrollo de software dentro del modelo de ciclo de vida en espiral es la metodología RAD (Rapid Application Development), que se ha generalizado recientemente. Este término suele referirse a un proceso de desarrollo de software que contiene 3 elementos:

un pequeño equipo de programadores (de 2 a 10 personas);

cronograma de producción breve pero cuidadosamente elaborado (de 2 a 6 meses);

un ciclo repetitivo en el que los desarrolladores, a medida que la aplicación comienza a tomar forma, solicitan e implementan en el producto los requisitos recibidos a través de la interacción con el cliente.

El ciclo de vida del software según la metodología RAD consta de cuatro fases:

fase de definición y análisis de requisitos;

fase de diseño;

fase de implementación;

fase de implementación.

En cada iteración se evalúa lo siguiente:

riesgo de exceder los plazos y costos del proyecto;
la necesidad de realizar otra iteración;
el grado de integridad y precisión de la comprensión de los requisitos del sistema;
viabilidad de dar por terminado el proyecto.

Ventajas del enfoque iterativo:

El desarrollo iterativo simplifica enormemente la realización de cambios en el proyecto cuando cambian los requisitos del cliente.
Cuando se utiliza el modelo en espiral, los elementos individuales del sistema de información se integran gradualmente en un todo único. Con un enfoque iterativo, la integración ocurre prácticamente de forma continua. Dado que la integración comienza con menos elementos, hay muchos menos problemas durante su implementación (según algunas estimaciones, cuando se utiliza el modelo de desarrollo en cascada, la integración representa hasta el 40% de todos los costos al final del proyecto).
El desarrollo iterativo proporciona una mayor flexibilidad en la gestión de proyectos, permitiendo realizar cambios tácticos en el producto que se está desarrollando.
El enfoque iterativo simplifica la reutilización de componentes (implementa un enfoque de programación basado en componentes). Esto se debe a que es mucho más fácil identificar partes comunes de un proyecto cuando ya se han desarrollado parcialmente que intentar identificarlas al principio del proyecto. El análisis del diseño después de algunas iteraciones iniciales revela componentes comunes y reutilizables que se mejorarán en iteraciones posteriores.
El modelo en espiral permite un sistema más confiable y estable. Esto se debe a que a medida que el sistema evoluciona, se descubren y corrigen errores y debilidades en cada iteración. Al mismo tiempo, se pueden ajustar parámetros de rendimiento críticos, lo que en el caso de un modelo en cascada sólo es posible antes de que se implemente el sistema.
El enfoque iterativo permite mejorar el proceso de desarrollo: el análisis realizado al final de cada iteración nos permite evaluar qué se debe cambiar en la organización de desarrollo y mejorarlo en la siguiente iteración.

Anotación.

Introducción.

1. Ciclo de vida del software

Introducción.

Pasos del proceso de programación de Riley

Introducción.

1.1.1. Formulación del problema.

1.1.2. Diseño de solución.

1.1.3. Codificación de algoritmos.

1.1.4. Apoyo al programa.

1.1.5. Documentación de software.

Conclusión de la cláusula 1.1

1.2. Determinación de LCPO según Lehman.

Introducción.

1.2.1 Definición del sistema.

1.2.2. Implementación.

1.2.3. Servicio.

Conclusión de la cláusula 1.2.

1.3. Fases y funcionamiento del LCPO según Boehm

1.3.1. Modelo en cascada.

1.3.2. Justificación económica del modelo en cascada.

1.3.3. Mejora del modelo en cascada.

1.3.4. Determinación de las fases del ciclo de vida.

1.3.5. Trabajo principal del proyecto.

Literatura.

Introducción

1 ciclo de vida del software

INTRODUCCIÓN

LCPO es un proceso continuo que comienza desde el momento en que se toma la decisión sobre la necesidad de crear software y finaliza en el momento en que se retira completamente del servicio.

La más famosa y completa, quizás, sea la estructura del proceso del ciclo de vida según Boehm, que incluye ocho fases. Se presentará con más detalle en el futuro.

Una de las posibles opciones podría ser una descripción de nivel superior según Lehman, que incluye tres fases principales y representa una descripción del ciclo de vida en el caso más general.

1.1 Pasos en el proceso de programación de Riley

El proceso de programación consta de cuatro pasos (Figura 1):

enunciado del problema, es decir obtener una comprensión adecuada de qué tarea debe realizar el programa;

diseñar una solución a un problema ya planteado (en general, dicha solución es menos formal que el programa final);

codificación de programas, es decir, traducir la solución diseñada a un programa que pueda ejecutarse en una máquina;

apoyo al programa, es decir el proceso continuo de resolución de problemas del programa y adición de nuevas funciones.

Arroz. 1.Cuatro pasos de programación.

La programación comienza desde el momento en que usuario, es decir. alguien que necesita un programa para resolver un problema plantea el problema analista de sistemas. El usuario y el analista del sistema definen conjuntamente el planteamiento del problema. Este último luego se transmite algorítmico, quien es responsable de diseñar la solución. Una solución (o algoritmo) representa una secuencia de operaciones, cuya ejecución conduce a la solución de un problema. Dado que el algoritmo a menudo no es adecuado para su ejecución en una máquina, debe traducirse a un programa de máquina. Esta operación la realiza el codificador. El programador acompañante es responsable de los cambios posteriores en el programa. Y el analista de sistemas, el algorítmico, el codificador y el programador que lo acompaña son todos programadores.

1.1.1 Planteamiento del problema

Características de un buen planteamiento del problema:

Exactitud, es decir. eliminando cualquier ambigüedad. No debería haber dudas sobre cuál será el resultado del programa para cualquier entrada determinada.

Lo completo, es decir. considerando todas las opciones para una entrada determinada, incluidas las entradas erróneas o no intencionadas, y determinando la salida adecuada.

Claridad, es decir. debe ser comprensible tanto para el usuario como para el analista del sistema, ya que el planteamiento del problema es el único contrato entre ellos.

Forma estándar de planteamiento del problema.

Considere el siguiente enunciado del problema: "Ingrese tres números y genere los números en orden".

nombre de la tarea (definición esquemática);

descripción general (breve resumen de la tarea);

errores (las opciones de entrada inusuales se enumeran explícitamente para mostrar a los usuarios y programadores qué acciones tomaría la máquina en tales situaciones);

ejemplo (un buen ejemplo puede transmitir la esencia del problema y también ilustrar diferentes casos).

Ejemplo. Planteamiento del problema en forma estándar.

NOMBRE

Ordenar tres números enteros.

DESCRIPCIÓN

Entrada y salida de tres números enteros, ordenados de menor a mayor.

1) Si se ingresan menos de tres números, el programa espera una entrada adicional.

2) Se ignoran las líneas de entrada distintas de las tres primeras.

3) Si cualquiera de las tres primeras líneas contiene más de un número entero, el programa sale y muestra un mensaje.

ERROR DE ENTRADA: solo se permite un número entero por línea.

entrada ® – 3

Este paso de programación es el más difícil. En esta etapa, el planteamiento del problema debe convertirse en un algoritmo. Por tanto, el diseñador de algoritmos debe tener suficiente experiencia en programación y abordar cada nuevo problema basándose en una metodología de diseño firmemente establecida. Desafortunadamente, hoy en día todos los programas grandes contienen errores, lo que conduce a malos proyectos. Los malos diseños, a su vez, son consecuencia de la complejidad de los problemas y del uso de métodos de diseño inadecuados. Para evitar errores en los programas, los algorítmicos deben utilizar procedimientos de diseño cuidadosamente diseñados y basados en reglas de inferencia.

Hay dos modelos de inferencia principales:

El primer modelo se conoce como inferencia deductiva. Esta forma de pensamiento lógico fue inmortalizada por el famoso detective Sherlock Holmes. La lógica deductiva aplica reglas generales a casos específicos. Por ejemplo, Holmes podría inferir la afirmación específica "El mayordomo es un asesino" a partir del conocimiento más general "El asesino rubio" y "El mayordomo es el único hombre rubio del que se puede sospechar".

El segundo modelo es salida inductiva, que es lo opuesto a la inferencia deductiva. La lógica inductiva extrae conclusiones generales de casos individuales. Por ejemplo, la inferencia inductiva se puede utilizar para justificar la conclusión general de que “el sol sale por el este” basada en muchas observaciones individuales de que el sol siempre ha salido por el este.

Estos dos procesos de inferencia son: deducción(de general a específico) y inducción(de específico a general): están estrechamente relacionados con los dos métodos de diseño más utilizados: "De arriba hacia abajo" Y "abajo arriba". Al igual que la deducción, el diseño de arriba hacia abajo comienza con un gran problema que se divide en subproblemas. Por ejemplo, el diseñador de un nuevo refrigerador-congelador, basándose en un conjunto inicial de especificaciones unitarias (es decir, el planteamiento del problema), debe producir diseños y especificaciones detalladas para el producto final (es decir, el diseño).

Si utiliza un método de diseño de arriba hacia abajo, entonces un único problema de diseño se puede dividir en dos subproblemas más pequeños: (1) diseño de la unidad de refrigeración y (2) diseño del congelador.

Sin embargo, puede utilizar el método de diseño ascendente y comenzar diseñando el compresor de refrigeración y luego las tuberías, la unidad o la cámara frigorífica de refrigeración. En este caso, esta elección impondrá ciertas restricciones a todo el proyecto.

La tarea del diseñador es crear un algoritmo que actúe como vínculo entre el planteamiento del problema y el programa listo para su ejecución. La verificación del algoritmo creado, es decir, qué tan bien refleja la formulación del problema, la lleva a cabo un analista de sistemas. Debido a esto, tanto el analista de sistemas como el diseñador deben poder leer y comprender el algoritmo. Cada algoritmo está escrito en algún pseudolenguaje. . Los algoritmos, también llamados pseudocódigos, no se pueden ejecutar en ninguna computadora.

El trabajo del codificador es traducir el algoritmo en un programa. Para crear un programa completo, preciso y comprensible, se requieren métodos apropiados para escribir programas. Por ejemplo, las recetas culinarias suelen estar escritas en idiomas naturales como el inglés, francés, ruso o japonés. Los programas están escritos en lenguajes de programación. Actualmente, ninguno de los lenguajes naturales puede utilizarse como lenguaje de programación porque son demasiado complejos para ser “entendidos” por las máquinas. A diferencia de los lenguajes naturales, los lenguajes de programación se crean específicamente para representar una solución a un problema que puede ser realizado por una computadora.

El codificador debe asegurarse de que el programa coincida con el pseudocódigo antes de salir. Luego el analista del sistema, el algorítmico y, lo más importante, el usuario deben probar y confirmar que funciona correctamente. Después de esto, podemos asumir que el programa está listo para ser transferido al usuario completo con toda la documentación necesaria.

Sin embargo, la programación no termina ahí; seguido por paso de acompañamiento. El caso es que puede haber errores en el programa, ya sea por un planteamiento inadecuado del problema, o por el hecho de que el proyecto no satisface el planteamiento del problema o el programa no se corresponde con el proyecto. Cualquiera sea el motivo, el usuario tiene derecho a exigir que se ajuste el programa porque no imaginaba que el programa funcionaría de esta manera. La corrección de errores es una de las principales tareas del mantenimiento del programa. Otra tarea igualmente importante del mantenimiento del programa es su modificación, es decir, agregar nuevas funciones al programa o cambiar las existentes. El usuario puede cambiar los requisitos para el funcionamiento del programa, lo que, a su vez, conducirá a la necesidad de reescribirlo. La complejidad del mantenimiento del programa depende del tipo de cambios que deben realizarse: en el peor de los casos, es posible que sea necesario rediseñar completamente el programa desde la producción hasta la codificación. Normalmente, se dedica más tiempo a mantener un programa que a crearlo.

La última parte del proceso de programación es documentación. Incluye una amplia gama de descripciones que facilitan el proceso de programación y enriquecen el programa resultante. La documentación continua debe ser una parte integral de cada paso de programación. Planteamiento de problemas, documentos de diseño, algoritmos y programas: todos estos son documentos. La documentación interna incluida directamente en el programa hace que el código sea más fácil de leer. El propósito de un manual de capacitación (otra forma de documentación) es enseñar al usuario cómo utilizar un programa nuevo; El manual de referencia proporciona una descripción de los comandos del software.

Conclusión de la cláusula 1.1.

Según el modelo presentado en este capítulo, la programación se puede dividir en cuatro pasos: definir el problema, diseñar soluciones, codificar el programa y mantener el programa. Además, el modelo incluye documentar el programa como actividades que deben realizarse durante todo el proceso de programación.

El modelo de programación está diseñado específicamente para resolver grandes problemas, ya que son de interés para los informáticos. Sin embargo, en la práctica, es importante utilizar técnicas de ingeniería cuidadosamente seleccionadas para el diseño de programas, independientemente del tamaño de los problemas: las habilidades adquiridas al resolver problemas más pequeños pueden reforzarse e implementarse con éxito al resolver problemas más grandes.

definiciones;

implementación;

servicio.

1.2.1 Definición del sistema

El proceso de creación de software comienza con una investigación práctica que conduce al análisis del sistema, cuya tarea es determinar los requisitos generales del sistema y los programas. Tal análisis debería, en primer lugar, establecer necesidades y objetivos reales y, si es posible, identificar los métodos disponibles para alcanzar el objetivo. Si es necesario, el análisis puede basarse en esquemas matemáticos u otros esquemas formales. Se cree que con cualquier enfoque, el análisis especificado debe tener una estructura determinada y llevarse a cabo de acuerdo con alguna teoría. El análisis y el refinamiento, realizados conjuntamente con analistas y usuarios potenciales, deberían conducir al desarrollo de una especificación de requisitos final. .

El proceso de redacción de dicha especificación tiene como objetivo obtener una especificación técnica correcta, completa en el sentido de reflejar los requisitos y coherente con la definición de la implementación. Después de la preparación de las especificaciones es la fase diseño, cuyo significado es identificar y estructurar datos, transformarlos y organizar su transferencia. Además, en esta fase es necesario lograr, en cierto sentido, una distribución óptima de las funciones del sistema, seleccionar un algoritmo y procedimientos, así como identificar los componentes del sistema y la relación entre ellos.

Habiendo completado diseño podemos empezar implementación sistemas. Sin embargo, en la práctica, las fases de diseño e implementación se superponen. Por lo tanto, a medida que avanza el proceso jerárquico de partición, el análisis de algunos elementos del sistema puede considerarse suficientemente completo para proceder a la implementación, mientras que otros elementos requieren mayor aclaración.

Durante el proceso de implementación, es necesario establecer la corrección del programa. Los procedimientos modernos se basan en gran medida en pruebas, aunque el uso de control estructural de extremo a extremo y métodos de validación de programas ha aumentado en los últimos años.

En cualquier caso, las pruebas a través de la ejecución del programa generalmente se realizan de abajo hacia arriba, primero a nivel de bloque (modular o procedimental), luego funcionalmente, componente por componente. A medida que se prueban los componentes individuales, se combinan en un sistema durante su proceso de diseño, después del cual comienzan las pruebas del sistema. En última instancia, una vez que se ha verificado de forma independiente la calidad del funcionamiento del sistema y se han evaluado sus parámetros, se considera que está listo para su uso. liberar.

1.2.3 Mantenimiento

El proceso de mantenimiento comienza inmediatamente después de que se lanza el sistema. Los errores deben ser identificados y corregidos. Si un error impide el funcionamiento normal del usuario, el programa defectuoso se puede eliminar temporalmente del sistema o se pueden realizar correcciones temporales o permanentes en algunos o todos los sistemas en uso. La solución o cambio permanente se puede incluir en una nueva versión del sistema. Para adaptarse a todos los cambios y sus combinaciones, se crean múltiples versiones de elementos del sistema. La tarea principal es la gestión de la configuración del sistema. Un papel decisivo en la gestión de la programación corresponde a los servicios de soporte que recopilan y regulan automáticamente todos los cambios en el sistema.

Conclusión a la cláusula 1.2.

El metasistema dentro del cual se desarrolla el programa contiene un número significativamente mayor de bucles de retroalimentación que el indicado anteriormente. Muchas actividades se superponen, se entrelazan de manera compleja y se repiten sistemáticamente. Por tanto, el modelo LCPO presentado por Boehm está suficientemente justificado.

1.3 Fases y funcionamiento de los centros de ciclo de vida según Boehm

El modelo en cascada se introdujo en los años 70 y 80. Es conveniente para software homogéneo, cuando cada aplicación era un todo.

Principales características del modelo:

El ciclo de vida se divide en etapas (fases);

Transición de una etapa a otra: solo después de la finalización completa de la etapa actual;

La etapa finaliza con la publicación de un conjunto completo de documentación, suficiente para que otro equipo de desarrollo pueda completar el trabajo.

Características principales modelo en cascada la siguiente:

completar cada fase con verificación y validación, cuyo propósito es eliminar tantos problemas asociados con el desarrollo de productos como sea posible;

repeticiones cíclicas de las fases implementadas desde la fase más temprana posible.

Figura 2. Modelo en cascada de LCPO.

En el modelo en cascada, la finalización exitosa de una de las fases del ciclo de vida significa el logro del correspondiente objetivo de programación de ingeniería (ver párrafo 2.4.). A estos subobjetivos hay que sumar dos más:

Diseñabilidad detallada– obtener especificaciones completas verificadas y estructuras de control y datos, conexiones de interfaz, características, algoritmos básicos y determinar las condiciones de funcionamiento de cada componente de software.

Codificabilidad– obtener un conjunto completo y verificado de componentes del programa.

Ventajas principales:

Formación de un juego completo de documentación del proyecto al finalizar el trabajo en el escenario. La documentación cumple con los criterios de exhaustividad e integridad;

Capacidad de planificación de plazos y costes. Para una serie de aplicaciones de software, este modelo es factible; esto es para sistemas para los cuales en la etapa de análisis es posible formular de manera precisa y completa todos los requisitos. Por ejemplo, programas informáticos complejos.

Principales desventajas:

Largos plazos de entrega desde el análisis hasta la finalización;

Los requisitos de software están "congelados" en forma de especificaciones técnicas hasta el final del desarrollo.

1.3.2 Justificación económica del modelo en cascada

Sin ahondar en el análisis económico que B.U. Boehm presta mucha atención en el libro "Ingeniería de software", digamos simplemente que la justificación económica del modelo en cascada, centrado en el logro secuencial de objetivos, se basa en dos premisas principales:

Para obtener un producto de software de alta calidad (es decir, uno que satisfaga plenamente todos los objetivos del producto de software requerido), es necesario en cualquier caso implementar todos los subobjetivos en cada etapa.

Cualquier otro orden de subobjetivos da como resultado la creación de un producto de software de menor calidad.

1.3.3 Mejora del modelo en cascada

Consideremos una de las mejoras del modelo en cascada ideal: el desarrollo paso a paso.

Desarrollo paso a paso es una mejora del método de diseño iterativo con creación de prototipos y desarrollo de arriba hacia abajo en capas. Este método implica aumentar incrementalmente la funcionalidad del software durante el proceso de desarrollo.

Como modelo en cascada avanzado, el desarrollo incremental se ha utilizado con éxito para crear productos de software tanto grandes como pequeños.

Las principales ventajas del desarrollo paso a paso sobre el desarrollo absolutamente iterativo y el desarrollo de arriba hacia abajo nivel por nivel son las siguientes:

el uso de sucesivas extensiones del programa proporciona una forma mucho menos costosa de incorporar la experiencia del usuario en un producto mejorado que con un nuevo desarrollo;

La ampliación de la funcionalidad es mucho más fácil de probar y es más útil que los productos intermedios en el desarrollo por capas.

El valor del desarrollo incremental radica principalmente en cambiar la distribución de los costos laborales del proyecto. En la Figura 3 se muestra una variante del modelo en cascada para el desarrollo paso a paso.

1.3.4 Definición de fases del ciclo de vida

A continuación se dará la formulación de los objetivos finales de cada fase para la transición a la siguiente. Para el desarrollo paso a paso, las declaraciones dadas se refieren a los límites de fase de cada paso de expansión.

Comience la fase de planificación y análisis de requisitos.(Revisión conceptual completa de LCPE).

Obtención de una arquitectura del sistema aprobada y confirmada, incluidos acuerdos básicos sobre la distribución de funciones entre hardware y programas. Obtener una comprensión general aprobada y confirmada del funcionamiento del software, incluidos acuerdos básicos sobre la distribución de funciones entre la persona y el sistema.

Formación de un plan general para el proceso del ciclo de vida, definiendo las principales etapas, recursos, responsabilidades, plazos y obras principales.

Completar la fase de planificación y análisis de requisitos. Iniciar la fase de diseño del producto.(Revisión completa de requisitos de software).

Formación de un plan de desarrollo detallado: indicadores detallados para la finalización de las etapas de desarrollo, planes de asignación de recursos, diagramas de estructura organizacional, responsabilidades, plazos, trabajos, métodos y productos.

Formación de un plan detallado de uso: puntos del plan de desarrollo, cuyo contenido está enfocado a la capacitación, transferencia de programas, implementación, operación y mantenimiento.

Formación de un plan detallado de depuración del producto: plan de gestión de la configuración del hardware, plan de control de calidad, plan general de verificación y confirmación.

Especificación de requisitos de software aprobada y validada: especificaciones funcionales, técnicas y de interfaz que hayan demostrado ser completas, consistentes, verificables y factibles.

Un acuerdo de desarrollo aprobado (formal o informalmente) basado en los puntos anteriores.

Finalizar la fase de diseño del producto. Comience la fase de diseño detallado.(Completar el análisis de los resultados del diseño del producto).

Desarrollo de una especificación verificada para un proyecto de producto de software:

formación de una jerarquía de componentes de software, interfaces entre bloques para datos y control;

formación de estructuras de datos físicas y lógicas hasta el nivel de campos individuales;

desarrollo de un plan para la distribución de recursos informáticos (tiempo, memoria, precisión);

verificación de la integridad, coherencia, viabilidad y validez de los requisitos.

Identificación y resolución de todas las contradicciones del desarrollo que aumentan el grado de riesgo.

Desarrollo de una etapa preliminar de integración y depuración, un plan de manual de usuario y pruebas de aceptación.

Completar la fase de diseño detallado. Comience la fase de codificación y depuración fuera de línea.(Finalización del control del proyecto de extremo a extremo o análisis crítico bloque por bloque del proyecto).

Especificaciones detalladas verificadas de cada bloque:

especificación de cada subrutina, nombre, propósito, supuestos, dimensiones, secuencia de llamadas, salidas de errores, datos de entrada y salida, algoritmos y diseño lógico;

descripción de la base de datos hasta el nivel de parámetros, símbolos y bits individuales;

Verificar la integridad, coherencia y cumplimiento de las especificaciones de diseño del sistema y los planes de asignación de recursos.

Plan de pruebas de aceptación aprobado.

Manuales de usuario, así como un plan preliminar de integración y depuración completo.

Finalice la fase de copia y depuración. Comience la fase de integración y depuración.(Satisfacer los criterios de depuración fuera de línea).

Comprobar el funcionamiento de todas las unidades no sólo en valores nominales, sino también en valores excepcionales y límite.

Verificar todas las opciones de entrada y salida, incluidos los mensajes de error.

Ejecución de todos los operadores y todas las ramas de transferencia de control.

Comprobación del cumplimiento de los estándares de programación.

Realización de la documentación bloque a bloque de la estructura interna.

Completar la fase de integración y pruebas. Iniciar la fase de implementación.(Finalización del análisis de los resultados de las pruebas de aceptación).

Comprobación del cumplimiento de la prueba de aceptación del programa:

comprobar el cumplimiento de los requisitos del software;

Demostración de la aceptabilidad de las características de desempeño especificadas en las especificaciones en condiciones anormales.

Aceptación de productos de software suministrados, informes, manuales, bases de datos, especificaciones de estructura interna.

Completar la fase de implementación. Iniciar la fase de operación y mantenimiento.(Revisión completa de aceptación del sistema).

Verificar los resultados satisfactorios de las pruebas de aceptación del sistema.

Verificar que los requisitos del sistema sean satisfactorios.

Comprobación de la preparación para la producción de software, hardware, herramientas de mantenimiento y personal.

Aceptación de productos suministrados e incluidos en el sistema: hardware, software, documentación, herramientas de formación y mantenimiento.

Finalización de todos los trabajos especificados y puesta en servicio del sistema.

Completar la fase de operación y mantenimiento.(por discontinuación).

Cumplimiento de todos los puntos del plan de desmantelamiento: transferencia de programas, documentación, creación de un archivo, transición a un nuevo sistema.

1.3.5 Trabajo principal del proyecto

Análisis de requerimientos.

Diseño de producto.

Programación.

Planificación de depuración.

Verificación y confirmación.

Gestión de proyectos.

Gestión de configuración y control de calidad.

Por tanto, se consideraron tres enfoques para determinar el ciclo de vida del software. En mi opinión, todos tienen derecho a existir, ya que en un grado u otro reflejan la práctica de la programación. Además, es fácil descubrir puntos comunes (se establece una tarea, se define un sistema, se analizan los requisitos; mantenimiento del programa, mantenimiento, operación y mantenimiento).

Sin embargo, cabe señalar que la definición de Boehm de las fases y el trabajo del centro del ciclo de vida es la más justificada, porque se basa en un enfoque más centrado en la programación de ingeniería (destinado a obtener un producto de software de alta calidad e implementar un proceso eficaz de desarrollo y mantenimiento de software) y está justificado económicamente.

A partir de este informe, queda claro lo importante y necesario que es conocer las necesidades del mundo moderno a la hora de crear un producto (producto) de software. Al elaborar un programa para automatizar cualquier sistema, es importante tener en cuenta que el mundo moderno cambia constantemente, lo que significa que el programa debe ser capaz de cambiar.

También es importante, al elaborar un programa, tener en cuenta que el programa debe ser preciso; completo en su contenido y apto para trabajar con problemas tanto pequeños como grandes de acuerdo con su finalidad; claro, para que el usuario pueda trabajar con él tranquilamente y sin dificultad. Y también para que el programa pueda corregirse o complementarse fácilmente en cualquier momento de acuerdo con los requisitos cambiantes del mundo moderno.

Debe recordarse que una buena programación no se trata de codificar una solución rápida utilizando cualquier técnica adecuada, sino de un procedimiento de ingeniería cuidadosamente instrumentado que produzca software completo, preciso y fácil de entender (claro).

1. B.U. Boehm, Ingeniería de Software. M.: Radio y comunicaciones. 1985.

2. D. Riley. "Usando el lenguaje Modula-2". M.: Mir. 1993.

3. yu.v. Ivanov “Programas y sus ciclos de vida” (resumen sobre la disciplina “Metrología del software”). 1998.

¡Hola, queridos residentes de Khabrovsk! Creo que será interesante que alguien recuerde qué modelos de desarrollo, implementación y uso de software existían anteriormente, qué modelos se utilizan principalmente ahora, por qué y qué es realmente. Este será mi pequeño tema.

En realidad, ¿qué es? ciclo de vida del software- una serie de eventos que ocurren con el sistema durante su creación y uso posterior. En otras palabras, este es el tiempo desde el momento inicial de creación de cualquier producto de software hasta el final de su desarrollo e implementación. El ciclo de vida del software se puede representar en forma de modelos.

Modelo de ciclo de vida del software.- una estructura que contiene procesos de acción y tareas que se llevan a cabo durante el desarrollo, uso y mantenimiento de un producto de software.
Estos modelos se pueden dividir en 3 grupos principales:

Enfoque de ingeniería
Teniendo en cuenta las particularidades de la tarea.
Tecnologías modernas de rápido desarrollo.

Ahora veamos los modelos existentes (subclases) y evaluemos sus ventajas y desventajas.

Modelo de codificación y eliminación de errores

Un modelo completamente sencillo, típico de estudiantes universitarios. Es según este modelo que la mayoría de los estudiantes desarrollan, digamos, trabajos de laboratorio.
Este modelo tiene el siguiente algoritmo:

Formulación del problema
Actuación
Comprobando el resultado
Si es necesario, vaya al primer punto.

Modelo también horrible anticuado. Es típico de los años 1960-1970, por lo que prácticamente no tiene ventajas sobre los siguientes modelos de nuestra revisión, pero las desventajas son obvias. Pertenece al primer grupo de modelos.

Modelo de ciclo de vida del software en cascada (cascada)

El algoritmo de este método, que muestro en el diagrama, tiene una serie de ventajas sobre el algoritmo del modelo anterior, pero también tiene una serie de significativo deficiencias.

Ventajas:

Implementación secuencial de las etapas del proyecto en un orden estrictamente fijo.
Le permite evaluar la calidad del producto en cada etapa.

Defectos:

Sin retroalimentación entre etapas
No corresponde a las condiciones reales de desarrollo de productos de software.

Pertenece al primer grupo de modelos.

Modelo en cascada con control intermedio (hidromasaje)

Este modelo es casi equivalente en algoritmo al modelo anterior, sin embargo, tiene conexiones de retroalimentación con cada etapa del ciclo de vida, y esto da lugar a un inconveniente muy importante: Aumento de 10 veces en los costos de desarrollo. Pertenece al primer grupo de modelos.

Modelo V (desarrollo basado en pruebas)

Este modelo tiene un algoritmo más cercano a los métodos modernos, pero aún tiene una serie de desventajas. Es una de las principales prácticas de la programación extrema.

Modelo basado en el desarrollo de prototipos.

Este modelo se basa en el desarrollo de prototipos y prototipado de productos.
Creación de prototipos utilizado en las primeras etapas del ciclo de vida del software:

Aclarar requisitos poco claros (prototipo de interfaz de usuario)
Elija una de una serie de soluciones conceptuales (implementación de escenarios)
Analizar la viabilidad del proyecto.

Clasificación de prototipos:

Horizontal y vertical
Desechables y evolutivos
papel y guiones gráficos

Horizontal prototipos: modela exclusivamente la interfaz de usuario sin afectar la lógica de procesamiento ni la base de datos.
Vertical prototipos - pruebas de soluciones arquitectónicas.
Desechable prototipos - para un rápido desarrollo.
Evolutivo Los prototipos son la primera aproximación de un sistema evolutivo.

El modelo pertenece al segundo grupo.

Modelo de ciclo de vida del software en espiral

El modelo en espiral es un proceso de desarrollo de software que combina diseño y creación de prototipos incrementales para combinar los beneficios de los conceptos ascendentes y descendentes.

Ventajas:

Obtenga resultados rápidamente
Mayor competitividad
Cambiar los requisitos no es un problema

Defectos:

Falta de regulación escénica

El tercer grupo incluye modelos como Programación extrema(PX) MELÉ, modelo incremental(RUP), pero me gustaría hablar de ellos en un tema aparte.

¡Muchas gracias por su atención!