Descripción general del ciclo de vida del desarrollo de software (SDLC)

Table of Contents hide

1 modelo de cascada

2 modelo de transformación

2.1 modelo espiral

2.2 fuente modelo

2.3 modelo V

2.4 modelo incremental

2.5 Modelo basado en componentes

2.6 método prototipo

2.7 método XP

2.8 Método de proceso unificado (UP)

2.9 Aprende más

El ciclo de vida del desarrollo de software proporciona a las organizaciones un enfoque sistemático paso a paso para desarrollar software exitoso mediante la recopilación de requisitos iniciales para nuevos productos. Es un proceso sistemático de construcción de software para asegurar la calidad y corrección del software construido y cumplir con las expectativas del cliente.

Los principales modelos de desarrollo incluyen el modelo en cascada, el modelo incremental, el modelo en espiral, el modelo de fuente, el modelo inteligente, el modelo V, el modelo RAD, el modelo CBSD, el método prototipo, el método XP, el método RUP, etc.

modelo de cascada

El modelo de cascada, también conocido como el método del ciclo de vida, es el modelo de desarrollo más utilizado en el método del ciclo de vida. Divide el proceso de desarrollo de software en seis etapas: planificación de software, análisis de requisitos, diseño de software, codificación de programas, prueba de software y operación y mantenimiento. Para lograr su orden fijo de arriba abajo, como una cascada, caen paso a paso.

Plan de software : determina principalmente los objetivos de desarrollo y la viabilidad del software.
Análisis de requisitos : después de confirmar que el desarrollo del software es factible, realice un análisis detallado de las diversas funciones que el software debe lograr. La etapa de análisis de requisitos es una etapa muy importante. Un buen trabajo en esta etapa sentará una buena base para el éxito de todo el proyecto de desarrollo de software.
Diseño de software : Diseñe todo el sistema de software, como el diseño del marco del sistema, el diseño de la base de datos, etc., en función de los resultados del análisis de demanda. El diseño de software generalmente se divide en diseño general (diseño de esquema) y diseño detallado.
Código de programa : convierte el resultado del diseño de software en un código de programa que puede ejecutar una computadora. En el proceso de programación, se debe formular una especificación de programación unificada y compatible con los estándares para garantizar la legibilidad del programa, el fácil mantenimiento y mejorar la eficiencia operativa del programa.
Pruebas de software : una vez que se completa el diseño del software, debe someterse a pruebas rigurosas para encontrar y corregir los problemas en el software durante todo el proceso de diseño. En el proceso de prueba, es necesario establecer un plan de prueba detallado y realizar pruebas en estricta conformidad con el plan de prueba para reducir la arbitrariedad de la prueba. Mantenimiento del software:
El mantenimiento del software es el período más largo en el ciclo de vida del software. Después de que el software se desarrolla y se pone en uso, debido a varias razones, el software no puede continuar satisfaciendo los requisitos de los usuarios. Para prolongar la vida útil del software, se debe mantener el software.

modelo de transformación

El modelo de transformación (modelo de evolución) se basa en el desarrollo rápido de un prototipo. Según los comentarios y sugerencias de los usuarios en el proceso de llamada del prototipo, se mejora el prototipo para obtener una nueva versión del prototipo, y este proceso se repite hasta evolucionar al producto de software final.

modelo espiral

El modelo espiral combina el modelo de cascada y el modelo de transformación. Combina las ventajas de los dos y agrega análisis de riesgo. Se basa en el prototipo y gira de adentro hacia afuera a lo largo de la espiral. Cada rotación requiere planificación, análisis de riesgos, ingeniería de implementación, evaluación del cliente y otras actividades, y se desarrolla una nueva versión del prototipo. Después de varias espirales, se obtiene el sistema final.

fuente modelo

El modelo fuente brinda soporte para la reutilización de software y la integración de múltiples actividades de desarrollo en el ciclo de vida y, principalmente, admite métodos de desarrollo orientados a objetos. El término «fuente» en sí mismo encarna las características de iteración y falta de espacios. Cierta parte del sistema a menudo repite el trabajo muchas veces, y las funciones relacionadas se agregan al sistema evolucionado en cada iteración. El llamado gapless significa que no existe un límite obvio entre el análisis, el diseño y la codificación en las actividades de desarrollo.

modelo V

En el modelo de desarrollo, las pruebas se utilizan a menudo como una ocurrencia tardía para remediar la situación, pero también existe un modelo de desarrollo centrado en las pruebas, es decir, el modelo V. El modelo V solo ha sido vagamente reconocido en la industria del software. El modelo V afirma que las pruebas no son una ocurrencia tardía, sino un proceso tan importante como el proceso de desarrollo.

El modelo V describe algunos niveles de prueba diferentes y explica las diferentes etapas del ciclo de vida correspondientes a estos niveles. En la figura, el descenso de la izquierda son las diversas etapas del proceso de desarrollo, y las correspondientes son las partes ascendentes de la derecha, es decir, las diversas etapas del proceso de prueba.

Tenga en cuenta que el nombre de la fase de prueba puede ser diferente en diferentes organizaciones. El valor del modelo V es que muestra claramente los diferentes niveles que existen en el proceso de prueba y describe claramente la correspondencia entre estas fases de prueba y las diversas fases durante el proceso de desarrollo:

El objetivo principal de las pruebas unitarias es tratar varios errores que pueden existir en el proceso de codificación. Por ejemplo: el usuario ingresa un error en el valor límite durante el proceso de verificación.
El objetivo principal de las pruebas de integración es abordar los posibles problemas en el diseño detallado, especialmente para verificar los posibles errores en la interfaz entre cada unidad y otras partes del programa.
La prueba del sistema es principalmente para el diseño del esquema, verificando si el sistema en su conjunto está funcionando de manera efectiva. Por ejemplo: si se logra el alto rendimiento esperado en la configuración del producto.
Las pruebas de aceptación generalmente las llevan a cabo expertos comerciales o usuarios para confirmar que el producto realmente puede satisfacer las necesidades comerciales del usuario.

modelo incremental

Los modelos incrementales, como los modelos de implementación de prototipos y otros métodos evolutivos, son esencialmente iterativos. Pero a diferencia de la implementación del prototipo, el modelo incremental enfatiza que cada incremento libera un producto operable. Los primeros incrementos son la versión «desmontable» del producto final, pero proporcionan funciones de servicio al usuario y proporcionan una plataforma para que los usuarios evalúen.

La característica del modelo incremental es la introducción del concepto de paquetes incrementales. No necesita esperar hasta que salgan todos los requisitos, siempre que salgan los paquetes incrementales de un determinado requisito, puede comenzar el desarrollo. Aunque es posible que un determinado paquete incremental deba adaptarse aún más a las necesidades de los clientes y deba cambiarse, siempre que el paquete incremental sea lo suficientemente pequeño, su impacto puede ser soportable para todo el proyecto.

Modelo RAD El modelo de desarrollo rápido de aplicaciones (RAD) es un modelo de proceso de desarrollo de software incremental que enfatiza un ciclo de desarrollo muy corto.

The RAD model is a “high-speed” variant of the waterfall model, which wins rapid development through extensive use of reusable components and a component-based construction method. If the requirements are well understood and the scope of the project is constrained, this model can be used to quickly create a fully functional “information system”.

The process starts with business modeling, followed by data modeling, process modeling, application generation, testing, and iteration. The software process using the RAD model is shown in the figure below.

The tasks to be completed in each activity period of the RAD model are as follows.

Modelado de negocios: ¿Qué información impulsa la operación del proceso de negocios? ¿Qué información se va a generar? ¿Quién lo generó? ¿Hacia dónde va el flujo de información? ¿Quién lo manejará? Se puede complementar con diagramas de flujo de datos.

Modelado de datos: para respaldar el flujo de datos del proceso comercial, encuentre la colección de objetos de datos, defina los atributos de los objetos de datos y forme el modelo de datos con la relación con otros objetos de datos, que pueden complementarse con diagramas ER .

Modelado de procesos: permita que los objetos de datos completen varias funciones comerciales en el flujo de información. El proceso de creación describe la adición, modificación, eliminación y búsqueda de objetos de datos, es decir, el refinamiento del cuadro de procesamiento en el diagrama de flujo de datos.

Generación de programas de aplicación: utilice el lenguaje de cuarta generación (4GL) para escribir el programa de procesamiento, reutilizar los componentes existentes o crear nuevos componentes reutilizables, y utilice las herramientas proporcionadas por el entorno para generar y construir automáticamente todo el sistema de aplicaciones.

Las pruebas y la entrega, debido a una gran cantidad de reutilización, generalmente solo realizan pruebas generales, pero los componentes recién creados aún deben probarse.

Modelo basado en componentes

Componente (Componente) es una unidad de software con valor reutilizable y funciones relativamente independientes. El modelo de desarrollo de software basado en componentes (CBSD) consiste en utilizar un enfoque modular para modularizar todo el sistema y, con el apoyo de un determinado modelo de componente, reutilizar uno o más componentes de software en la biblioteca de componentes, a través de la combinación El proceso de construcción de software de aplicación sistemas con alta eficiencia y alta calidad.

El modelo de desarrollo basado en componentes incorpora muchas características del modelo espiral, y es esencialmente evolutivo, y el proceso de desarrollo es iterativo. El modelo de desarrollo basado en componentes consta de cinco etapas: análisis y definición de los requisitos del software, diseño de la arquitectura, establecimiento de la biblioteca de componentes, construcción, prueba y lanzamiento del software de la aplicación.

método prototipo

El prototipo de software es la realización parcial del nuevo producto propuesto. El objetivo principal de establecer el prototipo es resolver el problema de la demanda incierta en la etapa inicial del desarrollo del producto. Su propósito es aclarar y mejorar los requisitos, explorar opciones de diseño y desarrollar el producto final.

Hay muchas formas de clasificar los prototipos. Desde la perspectiva de si el prototipo realiza sus funciones, los prototipos de software se pueden dividir en dos tipos: prototipos horizontales y prototipos verticales.

Los prototipos horizontales también se denominan prototipos de comportamiento, que se utilizan para explorar algunos comportamientos específicos del sistema esperado y lograr el propósito de refinar los requisitos. Los prototipos horizontales suelen ser solo navegación de funciones, pero en realidad no implementan funciones. El prototipo horizontal se utiliza principalmente en la interfaz.

Los prototipos verticales también se denominan prototipos estructurados, que implementan parte de sus funciones. Los prototipos verticales se utilizan principalmente en la realización de algoritmos complejos.

método XP

XP es un método de desarrollo de software ligero (ágil), eficiente, de bajo riesgo, flexible, predecible, científico y divertido. En comparación con otras metodologías, la mayor diferencia radica en:

Proporcione retroalimentación específica y continua antes en un período más corto.
Planificación iterativa, primero generando un plan maestro rápidamente desde el principio y luego desarrollándolo continuamente a lo largo del proceso de desarrollo del proyecto.
Confíe en los procedimientos de prueba automatizados para monitorear el progreso del desarrollo y detectar defectos temprano.
Confíe en la comunicación verbal, las pruebas y la comunicación del programa fuente.
Abogar por el diseño evolutivo continuo.
Confíe en la estrecha colaboración dentro del equipo de desarrollo.
Trate de equilibrar los intereses a corto plazo del programador y los intereses a largo plazo del proyecto tanto como sea posible.

Método de proceso unificado (UP)

Unified Process es un marco de proceso general que puede hacer frente a una amplia gama de sistemas de software, diferentes campos de aplicación, diferentes tipos de organización, diferentes niveles de rendimiento y diferentes escalas de proyectos. UP está basado en componentes, lo que significa que el sistema de software desarrollado por él está compuesto por componentes, y los componentes están conectados entre sí a través de interfaces bien definidas. Al preparar todos los planos del sistema de software, UP utiliza el lenguaje de modelado unificado UML.

Comparado con otros procesos de software, UP tiene tres características notables: impulsado por casos de uso, centrado en la arquitectura básica, iteración e incremento. El proceso de software en Rational Unified Process se divide en cuatro fases secuenciales en el tiempo, a saber, la fase inicial, la fase de perfeccionamiento, la fase de construcción y la fase de entrega. Al final de cada etapa, se debe organizar una revisión técnica para determinar si se han cumplido los objetivos de esta etapa. Si los resultados de la revisión son satisfactorios, se puede permitir que el proyecto avance a la siguiente etapa.