SDLC - Guía rápida
El ciclo de vida del desarrollo de software (SDLC) es un proceso utilizado por la industria del software para diseñar, desarrollar y probar software de alta calidad. El SDLC tiene como objetivo producir un software de alta calidad que cumpla o supere las expectativas del cliente, se complete en tiempos y estimaciones de costos.
SDLC es el acrónimo de Software Development Life Cycle.
También se denomina Proceso de desarrollo de software.
SDLC es un marco que define las tareas realizadas en cada paso del proceso de desarrollo de software.
ISO / IEC 12207 es un estándar internacional para los procesos del ciclo de vida del software. Pretende ser el estándar que define todas las tareas necesarias para desarrollar y mantener software.
¿Qué es SDLC?
SDLC es un proceso que se sigue para un proyecto de software, dentro de una organización de software. Consiste en un plan detallado que describe cómo desarrollar, mantener, reemplazar y modificar o mejorar un software específico. El ciclo de vida define una metodología para mejorar la calidad del software y el proceso de desarrollo en general.
La siguiente figura es una representación gráfica de las distintas etapas de un SDLC típico.
Un ciclo de vida de desarrollo de software típico consta de las siguientes etapas:
Etapa 1: planificación y análisis de requisitos
El análisis de requisitos es la etapa más importante y fundamental en SDLC. Es realizado por los miembros senior del equipo con aportes del cliente, el departamento de ventas, estudios de mercado y expertos en el dominio de la industria. Esta información se utiliza luego para planificar el enfoque básico del proyecto y para realizar un estudio de viabilidad del producto en las áreas económica, operativa y técnica.
La planificación de los requisitos de garantía de calidad y la identificación de los riesgos asociados con el proyecto también se realiza en la etapa de planificación. El resultado del estudio de viabilidad técnica es definir los diversos enfoques técnicos que se pueden seguir para implementar el proyecto con éxito y con el mínimo de riesgos.
Etapa 2: Definición de requisitos
Una vez que se realiza el análisis de requisitos, el siguiente paso es definir y documentar claramente los requisitos del producto y obtener la aprobación del cliente o de los analistas de mercado. Esto se hace mediante unSRS (Software Requirement Specification) documento que consta de todos los requisitos del producto a diseñar y desarrollar durante el ciclo de vida del proyecto.
Etapa 3: Diseño de la arquitectura del producto
SRS es la referencia para que los arquitectos de productos presenten la mejor arquitectura para el producto a desarrollar. Con base en los requisitos especificados en SRS, generalmente se propone y documenta más de un enfoque de diseño para la arquitectura del producto en una DDS - Especificación de documento de diseño.
Esta DDS es revisada por todas las partes interesadas importantes y, basándose en varios parámetros como evaluación de riesgos, solidez del producto, modularidad del diseño, limitaciones de tiempo y presupuesto, se selecciona el mejor enfoque de diseño para el producto.
Un enfoque de diseño define claramente todos los módulos arquitectónicos del producto junto con su comunicación y representación del flujo de datos con los módulos externos y de terceros (si los hubiera). El diseño interno de todos los módulos de la arquitectura propuesta debe estar claramente definido con el más mínimo de los detalles en DDS.
Etapa 4: Creación o desarrollo del producto
En esta etapa de SDLC comienza el desarrollo real y se construye el producto. El código de programación se genera según DDS durante esta etapa. Si el diseño se realiza de manera detallada y organizada, la generación de código puede lograrse sin muchos problemas.
Los desarrolladores deben seguir las pautas de codificación definidas por su organización y las herramientas de programación como compiladores, intérpretes, depuradores, etc. se utilizan para generar el código. Para la codificación se utilizan diferentes lenguajes de programación de alto nivel como C, C ++, Pascal, Java y PHP. El lenguaje de programación se elige con respecto al tipo de software que se está desarrollando.
Etapa 5: Prueba del producto
Esta etapa suele ser un subconjunto de todas las etapas, ya que en los modelos SDLC modernos, las actividades de prueba están involucradas principalmente en todas las etapas de SDLC. Sin embargo, esta etapa se refiere a la etapa de prueba del producto en la que los defectos del producto se informan, rastrean, reparan y vuelven a probar, hasta que el producto alcanza los estándares de calidad definidos en el SRS.
Etapa 6: Despliegue en el mercado y mantenimiento
Una vez que el producto se prueba y está listo para implementarse, se lanza formalmente en el mercado correspondiente. A veces, la implementación del producto ocurre en etapas según la estrategia comercial de esa organización. El producto puede lanzarse primero en un segmento limitado y probarse en el entorno empresarial real (prueba de aceptación del usuario de UAT).
Luego, según los comentarios, el producto puede lanzarse tal cual o con mejoras sugeridas en el segmento de mercado de destino. Una vez que el producto se lanza al mercado, se realiza su mantenimiento para la base de clientes existente.
Modelos SDLC
Hay varios modelos de ciclo de vida de desarrollo de software definidos y diseñados que se siguen durante el proceso de desarrollo de software. Estos modelos también se denominan "Modelos de proceso de desarrollo de software". Cada modelo de proceso sigue una serie de pasos únicos para su tipo para garantizar el éxito en el proceso de desarrollo de software.
A continuación se muestran los modelos SDLC más importantes y populares que se siguen en la industria:
- Modelo de cascada
- Modelo iterativo
- Modelo espiral
- V-Model
- Modelo Big Bang
Otras metodologías relacionadas son Agile Model, RAD Model, Rapid Application Development y Prototyping Models.
El modelo de cascada fue el primer modelo de proceso que se introdujo. También se conoce comolinear-sequential life cycle model. Es muy sencillo de entender y utilizar. En un modelo de cascada, cada fase debe completarse antes de que pueda comenzar la siguiente y no hay superposición en las fases.
El modelo Waterfall es el primer enfoque SDLC que se utilizó para el desarrollo de software.
El modelo en cascada ilustra el proceso de desarrollo de software en un flujo secuencial lineal. Esto significa que cualquier fase del proceso de desarrollo comienza solo si la fase anterior está completa. En este modelo de cascada, las fases no se superponen.
Modelo de cascada - Diseño
El enfoque en cascada fue el primer modelo SDLC que se utilizó ampliamente en ingeniería de software para garantizar el éxito del proyecto. En el enfoque "The Waterfall", todo el proceso de desarrollo de software se divide en fases separadas. En este modelo de cascada, típicamente, el resultado de una fase actúa como entrada para la siguiente fase de forma secuencial.
La siguiente ilustración es una representación de las diferentes fases del modelo de cascada.
Las fases secuenciales en el modelo Waterfall son:
Requirement Gathering and analysis - Todos los posibles requisitos del sistema a desarrollar se capturan en esta fase y se documentan en un documento de especificación de requisitos.
System Design- En esta fase se estudian las especificaciones de requisitos de la primera fase y se prepara el diseño del sistema. Este diseño de sistema ayuda a especificar los requisitos del sistema y del hardware y ayuda a definir la arquitectura general del sistema.
Implementation- Con los insumos del diseño del sistema, el sistema se desarrolla primero en pequeños programas llamados unidades, que se integran en la siguiente fase. Cada unidad se desarrolla y prueba para determinar su funcionalidad, lo que se conoce como prueba unitaria.
Integration and Testing- Todas las unidades desarrolladas en la fase de implementación se integran en un sistema después de probar cada unidad. Después de la integración, todo el sistema se prueba para detectar fallas y fallas.
Deployment of system- Una vez realizada la prueba funcional y no funcional; el producto se implementa en el entorno del cliente o se lanza al mercado.
Maintenance- Hay algunos problemas que surgen en el entorno del cliente. Para solucionar esos problemas, se lanzan parches. También para mejorar el producto se lanzan algunas versiones mejores. El mantenimiento se realiza para ofrecer estos cambios en el entorno del cliente.
Todas estas fases están en cascada entre sí en las que se ve el progreso como fluyendo constantemente hacia abajo (como una cascada) a través de las fases. La siguiente fase se inicia solo después de que se logra el conjunto de objetivos definido para la fase anterior y se firma, por lo que el nombre "Modelo de cascada". En este modelo, las fases no se superponen.
Modelo de cascada - Aplicación
Cada software desarrollado es diferente y requiere que se siga un enfoque SDLC adecuado en función de los factores internos y externos. Algunas situaciones en las que el uso del modelo Waterfall es más apropiado son:
Los requisitos están muy bien documentados, son claros y fijos.
La definición del producto es estable.
La tecnología se entiende y no es dinámica.
No hay requisitos ambiguos.
Hay disponibles amplios recursos con la experiencia necesaria para respaldar el producto.
El proyecto es corto.
Modelo de cascada - Ventajas
Las ventajas del desarrollo en cascada son que permite la departamentalización y el control. Se puede establecer un cronograma con fechas límite para cada etapa de desarrollo y un producto puede avanzar a través de las fases del modelo del proceso de desarrollo una por una.
El desarrollo se mueve desde el concepto, pasando por el diseño, la implementación, las pruebas, la instalación, la resolución de problemas y termina en la operación y el mantenimiento. Cada fase de desarrollo procede en estricto orden.
Algunas de las principales ventajas del modelo Waterfall son las siguientes:
Simple y fácil de entender y usar
Fácil de manejar debido a la rigidez del modelo. Cada fase tiene entregables específicos y un proceso de revisión.
Las fases se procesan y completan una a la vez.
Funciona bien para proyectos más pequeños donde los requisitos se entienden muy bien.
Etapas claramente definidas.
Hitos bien entendidos.
Fácil de organizar las tareas.
El proceso y los resultados están bien documentados.
Modelo de cascada - Desventajas
La desventaja del desarrollo en cascada es que no permite mucha reflexión o revisión. Una vez que una aplicación está en la etapa de prueba, es muy difícil volver atrás y cambiar algo que no estaba bien documentado o pensado en la etapa de concepto.
Las principales desventajas del modelo de cascada son las siguientes:
No se produce ningún software que funcione hasta tarde durante el ciclo de vida.
Grandes cantidades de riesgo e incertidumbre.
No es un buen modelo para proyectos complejos y orientados a objetos.
Modelo deficiente para proyectos largos y en curso.
No es adecuado para los proyectos donde los requisitos tienen un riesgo de cambio de moderado a alto. Entonces, el riesgo y la incertidumbre son altos con este modelo de proceso.
Es difícil medir el progreso dentro de las etapas.
No puede adaptarse a los requisitos cambiantes.
Ajustar el alcance durante el ciclo de vida puede poner fin a un proyecto.
La integración se realiza como un "big-bang. Al final, lo que no permite identificar temprano ningún cuello de botella o desafío tecnológico o empresarial".
En el modelo iterativo, el proceso iterativo comienza con una implementación simple de un pequeño conjunto de requisitos de software y mejora de manera iterativa las versiones en evolución hasta que el sistema completo está implementado y listo para ser implementado.
Un modelo de ciclo de vida iterativo no intenta comenzar con una especificación completa de requisitos. En cambio, el desarrollo comienza especificando e implementando solo una parte del software, que luego se revisa para identificar más requisitos. Luego, este proceso se repite, produciendo una nueva versión del software al final de cada iteración del modelo.
Modelo iterativo - Diseño
El proceso iterativo comienza con una implementación simple de un subconjunto de los requisitos de software y mejora iterativamente las versiones en evolución hasta que se implementa el sistema completo. En cada iteración, se realizan modificaciones de diseño y se agregan nuevas capacidades funcionales. La idea básica detrás de este método es desarrollar un sistema a través de ciclos repetidos (iterativos) y en porciones más pequeñas a la vez (incrementales).
La siguiente ilustración es una representación del modelo iterativo e incremental:
El desarrollo iterativo e incremental es una combinación de diseño iterativo o método iterativo y modelo de construcción incremental para el desarrollo. "Durante el desarrollo de software, más de una iteración del ciclo de desarrollo de software puede estar en progreso al mismo tiempo". Este proceso puede describirse como un enfoque de "adquisición evolutiva" o "construcción incremental" ".
En este modelo incremental, todo el requisito se divide en varias compilaciones. Durante cada iteración, el módulo de desarrollo pasa por las fases de requisitos, diseño, implementación y prueba. Cada versión posterior del módulo agrega función a la versión anterior. El proceso continúa hasta que el sistema completo está listo según el requisito.
La clave para un uso exitoso de un ciclo de vida de desarrollo de software iterativo es la validación rigurosa de los requisitos y la verificación y prueba de cada versión del software frente a esos requisitos dentro de cada ciclo del modelo. A medida que el software evoluciona a través de ciclos sucesivos, las pruebas deben repetirse y ampliarse para verificar cada versión del software.
Modelo iterativo: aplicación
Como otros modelos de SDLC, el desarrollo iterativo e incremental tiene algunas aplicaciones específicas en la industria del software. Este modelo se utiliza con mayor frecuencia en los siguientes escenarios:
Los requisitos del sistema completo están claramente definidos y comprendidos.
Deben definirse los requisitos principales; sin embargo, algunas funcionalidades o mejoras solicitadas pueden evolucionar con el tiempo.
Hay un momento para la restricción del mercado.
Se está utilizando una nueva tecnología y el equipo de desarrollo la está aprendiendo mientras trabaja en el proyecto.
Los recursos con los conjuntos de habilidades necesarios no están disponibles y se planea usarlos por contrato para iteraciones específicas.
Hay algunas características y objetivos de alto riesgo que pueden cambiar en el futuro.
Modelo iterativo: pros y contras
La ventaja de este modelo es que hay un modelo funcional del sistema en una etapa muy temprana de desarrollo, lo que facilita la búsqueda de fallas funcionales o de diseño. Encontrar problemas en una etapa temprana de desarrollo permite tomar medidas correctivas con un presupuesto limitado.
La desventaja de este modelo SDLC es que solo es aplicable a proyectos de desarrollo de software grandes y voluminosos. Esto se debe a que es difícil dividir un pequeño sistema de software en más pequeños incrementos / módulos útiles.
Las ventajas del modelo SDLC iterativo e incremental son las siguientes:
Algunas funciones de trabajo se pueden desarrollar rápidamente y al principio del ciclo de vida.
Los resultados se obtienen de forma temprana y periódica.
Se puede planificar un desarrollo paralelo.
El progreso se puede medir.
Menos costoso cambiar el alcance / los requisitos.
Probar y depurar durante iteraciones más pequeñas es fácil.
Los riesgos se identifican y resuelven durante la iteración; y cada iteración es un hito de fácil gestión.
Más fácil de administrar el riesgo: la parte de alto riesgo se realiza primero.
Con cada incremento, se entrega un producto operativo.
Los problemas, desafíos y riesgos identificados en cada incremento se pueden utilizar / aplicar al siguiente incremento.
El análisis de riesgos es mejor.
Admite requisitos cambiantes.
El tiempo de funcionamiento inicial es menor.
Más adecuado para proyectos grandes y de misión crítica.
Durante el ciclo de vida, el software se produce temprano, lo que facilita la evaluación y los comentarios del cliente.
Las desventajas del modelo SDLC iterativo e incremental son las siguientes:
Es posible que se requieran más recursos.
Aunque el costo del cambio es menor, no es muy adecuado para los requisitos cambiantes.
Se requiere más atención administrativa.
Pueden surgir problemas de arquitectura o diseño del sistema porque no todos los requisitos se recopilan al comienzo de todo el ciclo de vida.
La definición de incrementos puede requerir la definición del sistema completo.
No apto para proyectos más pequeños.
La complejidad de la gestión es mayor.
Es posible que no se conozca el final del proyecto, lo que constituye un riesgo.
Se requieren recursos altamente calificados para el análisis de riesgos.
El progreso de los proyectos depende en gran medida de la fase de análisis de riesgos.
El modelo en espiral combina la idea de desarrollo iterativo con los aspectos sistemáticos y controlados del modelo en cascada. Este modelo en espiral es una combinación de modelo de proceso de desarrollo iterativo y modelo de desarrollo lineal secuencial, es decir, el modelo en cascada con un gran énfasis en el análisis de riesgos. Permite lanzamientos incrementales del producto o refinamiento incremental a través de cada iteración alrededor de la espiral.
Modelo en espiral - Diseño
El modelo en espiral tiene cuatro fases. Un proyecto de software pasa repetidamente por estas fases en iteraciones llamadas Espirales.
Identificación
Esta fase comienza con la recopilación de los requisitos comerciales en la espiral básica. En las espirales posteriores a medida que el producto madura, la identificación de los requisitos del sistema, los requisitos del subsistema y los requisitos de la unidad se realizan en esta fase.
Esta fase también incluye la comprensión de los requisitos del sistema mediante la comunicación continua entre el cliente y el analista del sistema. Al final de la espiral, el producto se despliega en el mercado identificado.
Diseño
La fase de Diseño comienza con el diseño conceptual en la espiral de la línea de base e involucra el diseño arquitectónico, el diseño lógico de los módulos, el diseño físico del producto y el diseño final en las espirales posteriores.
Construir o construir
La fase de construcción se refiere a la producción del producto de software real en cada espiral. En la espiral de la línea de base, cuando se piensa en el producto y se está desarrollando el diseño, se desarrolla una POC (Prueba de concepto) en esta fase para obtener comentarios de los clientes.
Luego, en las siguientes espirales con mayor claridad en los requisitos y detalles de diseño, se produce un modelo funcional del software llamado build con un número de versión. Estas compilaciones se envían al cliente para recibir comentarios.
Evaluación y análisis de riesgos
El análisis de riesgos incluye la identificación, estimación y seguimiento de la viabilidad técnica y los riesgos de gestión, como retrasos en el cronograma y sobrecostos. Después de probar la compilación, al final de la primera iteración, el cliente evalúa el software y proporciona comentarios.
La siguiente ilustración es una representación del modelo en espiral, que enumera las actividades en cada fase.
Según la evaluación del cliente, el proceso de desarrollo de software ingresa a la siguiente iteración y, posteriormente, sigue el enfoque lineal para implementar la retroalimentación sugerida por el cliente. El proceso de iteraciones a lo largo de la espiral continúa durante toda la vida del software.
Aplicación del modelo en espiral
El Modelo Espiral es muy utilizado en la industria del software ya que está sincronizado con el proceso de desarrollo natural de cualquier producto, es decir, aprender con madurez que implica un riesgo mínimo tanto para el cliente como para las empresas desarrolladoras.
Los siguientes indicadores explican los usos típicos de un modelo en espiral:
Cuando existe una restricción presupuestaria y la evaluación de riesgos es importante.
Para proyectos de riesgo medio a alto.
Compromiso con el proyecto a largo plazo debido a posibles cambios en las prioridades económicas a medida que los requisitos cambian con el tiempo.
El cliente no está seguro de sus requisitos, que suele ser el caso.
Los requisitos son complejos y necesitan evaluación para obtener claridad.
Nueva línea de productos que debe lanzarse en fases para obtener suficientes comentarios de los clientes.
Se esperan cambios significativos en el producto durante el ciclo de desarrollo.
Modelo en espiral: pros y contras
La ventaja del modelo de ciclo de vida en espiral es que permite agregar elementos del producto cuando están disponibles o se conocen. Esto asegura que no haya conflicto con los requisitos y el diseño anteriores.
Este método es consistente con los enfoques que tienen múltiples versiones y versiones de software, lo que permite hacer una transición ordenada a una actividad de mantenimiento. Otro aspecto positivo de este método es que el modelo en espiral obliga a que el usuario participe desde el principio en el esfuerzo de desarrollo del sistema.
Por otro lado, se necesita una gestión muy estricta para completar dichos productos y existe el riesgo de ejecutar la espiral en un bucle indefinido. Por lo tanto, la disciplina del cambio y el alcance de las solicitudes de cambio son muy importantes para desarrollar e implementar el producto con éxito.
Las ventajas del modelo Spiral SDLC son las siguientes:
Pueden adaptarse requisitos cambiantes.
Permite un uso extensivo de prototipos.
Los requisitos se pueden capturar con mayor precisión.
Los usuarios ven el sistema temprano.
El desarrollo se puede dividir en partes más pequeñas y las partes riesgosas se pueden desarrollar antes, lo que ayuda a una mejor gestión del riesgo.
Las desventajas del modelo Spiral SDLC son las siguientes:
La gestión es más compleja.
Es posible que el final del proyecto no se conozca antes.
No es adecuado para proyectos pequeños o de bajo riesgo y podría ser costoso para proyectos pequeños.
El proceso es complejo
La espiral puede continuar indefinidamente.
Un gran número de etapas intermedias requiere una documentación excesiva.
El modelo V es un modelo SDLC en el que la ejecución de procesos se realiza de forma secuencial en forma de V. También se conoce comoVerification and Validation model.
El V-Model es una extensión del modelo de cascada y se basa en la asociación de una fase de prueba para cada etapa de desarrollo correspondiente. Esto significa que para cada fase del ciclo de desarrollo, hay una fase de prueba directamente asociada. Este es un modelo muy disciplinado y la siguiente fase comienza solo después de completar la fase anterior.
V-Model - Diseño
Bajo el V-Model, la correspondiente fase de prueba de la fase de desarrollo está planificada en paralelo. Por lo tanto, hay fases de Verificación en un lado de las fases 'V' y Validación en el otro lado. La fase de codificación une los dos lados del V-Model.
La siguiente ilustración muestra las diferentes fases en un modelo V del SDLC.
Modelo V - Fases de verificación
Hay varias fases de verificación en el modelo V, cada una de las cuales se explica en detalle a continuación.
Análisis de requisitos comerciales
Esta es la primera fase del ciclo de desarrollo en la que los requisitos del producto se entienden desde la perspectiva del cliente. Esta fase implica una comunicación detallada con el cliente para comprender sus expectativas y requisitos exactos. Esta es una actividad muy importante y debe gestionarse bien, ya que la mayoría de los clientes no están seguros de lo que necesitan exactamente. losacceptance test design planning se realiza en esta etapa, ya que los requisitos comerciales se pueden utilizar como entrada para las pruebas de aceptación.
Diseño de sistemas
Una vez que tenga los requisitos del producto claros y detallados, es hora de diseñar el sistema completo. El diseño del sistema comprenderá y detallará la configuración completa del hardware y la comunicación para el producto en desarrollo. El plan de prueba del sistema se desarrolla en base al diseño del sistema. Hacer esto en una etapa anterior deja más tiempo para la ejecución real de la prueba más adelante.
Diseño arquitectonico
Las especificaciones arquitectónicas se entienden y diseñan en esta fase. Por lo general, se propone más de un enfoque técnico y, en función de la viabilidad técnica y financiera, se toma la decisión final. El diseño del sistema se divide en módulos que asumen diferentes funciones. Esto también se conoce comoHigh Level Design (HLD).
La transferencia de datos y la comunicación entre los módulos internos y con el mundo exterior (otros sistemas) se entiende y define claramente en esta etapa. Con esta información se pueden diseñar y documentar pruebas de integración durante esta etapa.
Diseño de módulo
En esta fase, se especifica el diseño interno detallado para todos los módulos del sistema, denominado Low Level Design (LLD). Es importante que el diseño sea compatible con los otros módulos de la arquitectura del sistema y los otros sistemas externos. Las pruebas unitarias son una parte esencial de cualquier proceso de desarrollo y ayudan a eliminar el máximo de fallas y errores en una etapa muy temprana. Estas pruebas unitarias se pueden diseñar en esta etapa en función de los diseños de los módulos internos.
Fase de codificación
La codificación real de los módulos del sistema diseñados en la fase de diseño se retoma en la fase de Codificación. El lenguaje de programación más adecuado se decide en función del sistema y los requisitos arquitectónicos.
La codificación se realiza según las directrices y estándares de codificación. El código pasa por numerosas revisiones de código y está optimizado para un mejor rendimiento antes de que la compilación final se registre en el repositorio.
Fases de validación
Las diferentes fases de validación en un modelo V se explican en detalle a continuación.
Examen de la unidad
Las pruebas unitarias diseñadas en la fase de diseño del módulo se ejecutan en el código durante esta fase de validación. Las pruebas unitarias son las pruebas a nivel de código y ayudan a eliminar errores en una etapa temprana, aunque las pruebas unitarias no pueden descubrir todos los defectos.
Pruebas de integración
Las pruebas de integración están asociadas con la fase de diseño arquitectónico. Se realizan pruebas de integración para probar la coexistencia y comunicación de los módulos internos dentro del sistema.
Prueba del sistema
La prueba del sistema está directamente asociada con la fase de diseño del sistema. Las pruebas del sistema verifican la funcionalidad completa del sistema y la comunicación del sistema en desarrollo con sistemas externos. La mayoría de los problemas de compatibilidad de software y hardware se pueden descubrir durante la ejecución de esta prueba del sistema.
Test de aceptación
Las pruebas de aceptación están asociadas con la fase de análisis de requisitos comerciales e implican probar el producto en el entorno del usuario. Las pruebas de aceptación descubren los problemas de compatibilidad con los otros sistemas disponibles en el entorno del usuario. También descubre problemas no funcionales, como defectos de carga y rendimiento en el entorno del usuario real.
V- Modelo ─ Aplicación
La aplicación del modelo V es casi la misma que la del modelo en cascada, ya que ambos modelos son de tipo secuencial. Los requisitos deben ser muy claros antes de que comience el proyecto, ya que generalmente es costoso regresar y hacer cambios. Este modelo se utiliza en el campo del desarrollo médico, ya que es un dominio estrictamente disciplinado.
Los siguientes indicadores son algunos de los escenarios más adecuados para utilizar la aplicación V-Model.
Los requisitos están bien definidos, claramente documentados y fijados.
La definición del producto es estable.
La tecnología no es dinámica y el equipo del proyecto la comprende bien.
No hay requisitos ambiguos o indefinidos.
El proyecto es corto.
V-Model - Pros y contras
La ventaja del método V-Model es que es muy fácil de entender y aplicar. La sencillez de este modelo también facilita su gestión. La desventaja es que el modelo no es flexible a los cambios y en caso de que haya un cambio de requisito, lo cual es muy común en el mundo dinámico actual, se vuelve muy costoso realizar el cambio.
Las ventajas del método V-Model son las siguientes:
Este es un modelo muy disciplinado y las fases se completan una a la vez.
Funciona bien para proyectos más pequeños donde los requisitos se entienden muy bien.
Simple y fácil de entender y usar.
Fácil de manejar debido a la rigidez del modelo. Cada fase tiene entregables específicos y un proceso de revisión.
Las desventajas del método V-Model son las siguientes:
Alto riesgo e incertidumbre.
No es un buen modelo para proyectos complejos y orientados a objetos.
Modelo deficiente para proyectos largos y en curso.
No es adecuado para los proyectos donde los requisitos tienen un riesgo de cambio de moderado a alto.
Una vez que una aplicación está en la etapa de prueba, es difícil volver atrás y cambiar una funcionalidad.
No se produce ningún software que funcione hasta tarde durante el ciclo de vida.
El modelo Big Bang es un modelo SDLC donde no seguimos ningún proceso específico. El desarrollo simplemente comienza con el dinero y los esfuerzos necesarios como entrada, y la salida es el software desarrollado, que puede o no ser según los requisitos del cliente. Este modelo de Big Bang no sigue un proceso / procedimiento y se requiere muy poca planificación. Incluso el cliente no está seguro de lo que quiere exactamente y los requisitos se implementan sobre la marcha sin mucho análisis.
Por lo general, este modelo se sigue para proyectos pequeños donde los equipos de desarrollo son muy pequeños.
Modelo Big Bang ─ Diseño y aplicación
El Modelo Big Bang consiste en enfocar todos los recursos posibles en el desarrollo y codificación de software, con muy poca o ninguna planificación. Los requisitos se entienden e implementan a medida que surgen. Cualquier cambio requerido puede o no necesitar renovar el software completo.
Este modelo es ideal para proyectos pequeños con uno o dos desarrolladores trabajando juntos y también es útil para proyectos académicos o prácticos. Es un modelo ideal para el producto donde los requisitos no se comprenden bien y no se da la fecha de lanzamiento final.
Modelo Big Bang - Pros y contras
La ventaja de este modelo Big Bang es que es muy simple y requiere muy poca o ninguna planificación. Fácil de administrar y no se requiere ningún procedimiento formal.
Sin embargo, el modelo Big Bang es un modelo de muy alto riesgo y los cambios en los requisitos o los requisitos mal entendidos pueden incluso dar lugar a una reversión completa o la eliminación del proyecto. Es ideal para proyectos repetitivos o pequeños con riesgos mínimos.
Las ventajas del modelo Big Bang son las siguientes:
Este es un modelo muy simple
Requiere poca o ninguna planificación
Fácil de manejar
Se requieren muy pocos recursos
Da flexibilidad a los desarrolladores
Es una buena ayuda para el aprendizaje para los recién llegados o los estudiantes.
Las desventajas del modelo Big Bang son las siguientes:
Riesgo e incertidumbre muy altos.
No es un buen modelo para proyectos complejos y orientados a objetos.
Modelo deficiente para proyectos largos y en curso.
Puede resultar muy costoso si se malinterpretan los requisitos.
El modelo SDLC ágil es una combinación de modelos de procesos iterativos e incrementales con enfoque en la adaptabilidad del proceso y la satisfacción del cliente mediante la entrega rápida de un producto de software funcional. Los métodos ágiles dividen el producto en pequeñas construcciones incrementales. Estas compilaciones se proporcionan en iteraciones. Cada iteración suele durar de una a tres semanas. Cada iteración implica equipos multifuncionales que trabajan simultáneamente en varias áreas como:
- Planning
- Análisis de requerimientos
- Design
- Coding
- Pruebas unitarias y
- Test de aceptación.
Al final de la iteración, se muestra un producto funcional al cliente y a las partes interesadas importantes.
¿Qué es Agile?
El modelo ágil cree que cada proyecto debe manejarse de manera diferente y los métodos existentes deben adaptarse para adaptarse mejor a los requisitos del proyecto. En Agile, las tareas se dividen en cuadros de tiempo (pequeños marcos de tiempo) para ofrecer funciones específicas para un lanzamiento.
Se adopta un enfoque iterativo y se entrega la compilación de software funcional después de cada iteración. Cada compilación es incremental en términos de características; la construcción final contiene todas las características requeridas por el cliente.
Aquí hay una ilustración gráfica del modelo ágil:
El proceso de pensamiento ágil había comenzado temprano en el desarrollo del software y comenzó a popularizarse con el tiempo debido a su flexibilidad y adaptabilidad.
Los métodos ágiles más populares incluyen Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development y Dynamic Systems Development Method (DSDM) (1995). Estos ahora se conocen colectivamente comoAgile Methodologies, después de la publicación del Manifiesto Ágil en 2001.
Los siguientes son los principios del Manifiesto Ágil:
Individuals and interactions - En el desarrollo ágil, la autoorganización y la motivación son importantes, al igual que las interacciones como la ubicación conjunta y la programación por pares.
Working software - El software de trabajo de demostración se considera el mejor medio de comunicación con los clientes para comprender sus requisitos, en lugar de simplemente depender de la documentación.
Customer collaboration - Como los requisitos no se pueden recopilar por completo al comienzo del proyecto debido a varios factores, la interacción continua con el cliente es muy importante para obtener los requisitos adecuados del producto.
Responding to change - Agile Development se centra en respuestas rápidas al cambio y desarrollo continuo.
Modelos SDLC tradicionales y ágiles
Agile se basa en adaptive software development methods, mientras que los modelos SDLC tradicionales como el modelo en cascada se basan en un enfoque predictivo. Los equipos predictivos en los modelos SDLC tradicionales generalmente trabajan con una planificación detallada y tienen un pronóstico completo de las tareas y características exactas que se entregarán en los próximos meses o durante el ciclo de vida del producto.
Los métodos predictivos dependen enteramente de la requirement analysis and planninghecho al comienzo del ciclo. Los cambios a incorporar pasan por un estricto control de gestión y priorización de cambios.
Agile utiliza un adaptive approachdonde no hay una planificación detallada y hay claridad sobre las tareas futuras solo con respecto a las características que deben desarrollarse. Hay un desarrollo impulsado por funciones y el equipo se adapta a los requisitos cambiantes del producto de forma dinámica. El producto se prueba con mucha frecuencia, a través de las iteraciones de lanzamiento, minimizando el riesgo de fallas importantes en el futuro.
Customer Interactiones la columna vertebral de esta metodología Agile, y la comunicación abierta con documentación mínima son las características típicas del entorno de desarrollo Agile. Los equipos ágiles trabajan en estrecha colaboración entre sí y suelen estar ubicados en la misma ubicación geográfica.
Modelo ágil: pros y contras
Los métodos ágiles están siendo ampliamente aceptados en el mundo del software recientemente. Sin embargo, es posible que este método no siempre sea adecuado para todos los productos. A continuación, se muestran algunos pros y contras del modelo Agile.
Las ventajas del modelo ágil son las siguientes:
Es un enfoque muy realista para el desarrollo de software.
Fomenta el trabajo en equipo y el entrenamiento cruzado.
La funcionalidad se puede desarrollar y demostrar rápidamente.
Los requisitos de recursos son mínimos.
Adecuado para requisitos fijos o cambiantes
Ofrece soluciones de trabajo parciales tempranas.
Buen modelo para entornos que cambian constantemente.
Reglas mínimas, documentación de fácil aplicación.
Permite el desarrollo y la entrega simultáneos dentro de un contexto planificado general.
Requiere poca o ninguna planificación.
Fácil de administrar.
Da flexibilidad a los desarrolladores.
Las desventajas del modelo ágil son las siguientes:
No apto para manejar dependencias complejas.
Más riesgo de sostenibilidad, mantenibilidad y extensibilidad.
Un plan general, un líder ágil y una práctica de gestión de proyectos ágil es una necesidad sin la cual no funcionará.
La gestión estricta de la entrega dicta el alcance, la funcionalidad que se entregará y los ajustes para cumplir con los plazos.
Depende en gran medida de la interacción con el cliente, por lo que si el cliente no lo tiene claro, el equipo puede ir en la dirección equivocada.
Existe una dependencia individual muy alta, ya que se genera una documentación mínima.
La transferencia de tecnología a los nuevos miembros del equipo puede ser un desafío debido a la falta de documentación.
los RAD (Rapid Application Development)El modelo se basa en la creación de prototipos y el desarrollo iterativo sin una planificación específica involucrada. El proceso de escribir el software en sí implica la planificación necesaria para desarrollar el producto.
El desarrollo rápido de aplicaciones se centra en recopilar los requisitos del cliente a través de talleres o grupos focales, pruebas tempranas de los prototipos por parte del cliente utilizando un concepto iterativo, reutilización de los prototipos (componentes) existentes, integración continua y entrega rápida.
¿Qué es RAD?
El desarrollo rápido de aplicaciones es una metodología de desarrollo de software que utiliza una planificación mínima a favor de la creación rápida de prototipos. Un prototipo es un modelo funcional que es funcionalmente equivalente a un componente del producto.
En el modelo RAD, los módulos funcionales se desarrollan en paralelo como prototipos y se integran para hacer el producto completo para una entrega más rápida del producto. Dado que no hay una planificación previa detallada, es más fácil incorporar los cambios dentro del proceso de desarrollo.
Los proyectos de RAD siguen un modelo iterativo e incremental y tienen pequeños equipos compuestos por desarrolladores, expertos en el dominio, representantes de clientes y otros recursos de TI que trabajan progresivamente en su componente o prototipo.
El aspecto más importante para que este modelo tenga éxito es asegurarse de que los prototipos desarrollados sean reutilizables.
Diseño de modelo RAD
El modelo RAD distribuye las fases de análisis, diseño, construcción y prueba en una serie de ciclos de desarrollo breves e iterativos.
A continuación se muestran las diversas fases del modelo RAD:
Modelado de negocios
El modelo de negocio del producto en desarrollo está diseñado en términos de flujo de información y distribución de información entre varios canales de negocio. Se realiza un análisis comercial completo para encontrar la información vital para los negocios, cómo se puede obtener, cómo y cuándo se procesa la información y cuáles son los factores que impulsan el flujo de información exitoso.
Modelado de datos
La información recopilada en la fase de modelado empresarial se revisa y analiza para formar conjuntos de objetos de datos vitales para el negocio. Se identifican y definen los atributos de todos los conjuntos de datos. La relación entre estos objetos de datos se establece y define en detalle en relación con el modelo de negocio.
Modelado de procesos
Los conjuntos de objetos de datos definidos en la fase de modelado de datos se convierten para establecer el flujo de información empresarial necesario para alcanzar los objetivos empresariales específicos según el modelo empresarial. El modelo de proceso para cualquier cambio o mejora en los conjuntos de objetos de datos se define en esta fase. Se proporcionan descripciones de procesos para agregar, eliminar, recuperar o modificar un objeto de datos.
Generación de aplicaciones
El sistema real se construye y la codificación se realiza mediante el uso de herramientas de automatización para convertir los modelos de datos y procesos en prototipos reales.
Pruebas y rotación
El tiempo total de prueba se reduce en el modelo RAD, ya que los prototipos se prueban de forma independiente durante cada iteración. Sin embargo, el flujo de datos y las interfaces entre todos los componentes deben probarse minuciosamente con una cobertura de prueba completa. Dado que la mayoría de los componentes de programación ya se han probado, reduce el riesgo de problemas importantes.
La siguiente ilustración describe el modelo RAD en detalle.
Modelo RAD Vs SDLC tradicional
El SDLC tradicional sigue modelos de proceso rígidos con un gran énfasis en el análisis de requisitos y la recopilación antes de que comience la codificación. Presiona al cliente para que apruebe los requisitos antes de que comience el proyecto y el cliente no se da cuenta del producto ya que no hay una compilación funcional disponible durante mucho tiempo.
Es posible que el cliente necesite algunos cambios después de ver el software. Sin embargo, el proceso de cambio es bastante rígido y puede que no sea factible incorporar cambios importantes en el producto en el SDLC tradicional.
El modelo RAD se centra en la entrega iterativa e incremental de modelos de trabajo al cliente. Esto da como resultado una entrega rápida al cliente y la participación del cliente durante el ciclo completo de desarrollo del producto, lo que reduce el riesgo de incumplimiento de los requisitos reales del usuario.
Modelo RAD - Aplicación
El modelo RAD se puede aplicar con éxito a los proyectos en los que es posible una modularización clara. Si el proyecto no se puede dividir en módulos, RAD puede fallar.
Los siguientes indicadores describen los escenarios típicos en los que se puede utilizar RAD:
RAD debe usarse solo cuando un sistema se pueda modularizar para entregarse de manera incremental.
Se debe utilizar si hay una alta disponibilidad de diseñadores para el modelado.
Debe usarse solo si el presupuesto permite el uso de herramientas de generación de código automatizadas.
El modelo RAD SDLC debe elegirse solo si hay expertos en el dominio disponibles con conocimientos comerciales relevantes.
Debe utilizarse cuando los requisitos cambian durante el proyecto y los prototipos de trabajo deben presentarse al cliente en pequeñas iteraciones de 2-3 meses.
Modelo RAD - Pros y contras
El modelo RAD permite una entrega rápida ya que reduce el tiempo de desarrollo general debido a la reutilización de los componentes y el desarrollo paralelo. RAD funciona bien solo si hay ingenieros altamente calificados disponibles y el cliente también se compromete a lograr el prototipo deseado en el período de tiempo dado. Si falta el compromiso de cualquiera de las partes, el modelo puede fallar.
Las ventajas del modelo RAD son las siguientes:
Pueden adaptarse requisitos cambiantes.
El progreso se puede medir.
El tiempo de iteración puede ser corto con el uso de potentes herramientas RAD.
Productividad con menos personas en poco tiempo.
Reducción del tiempo de desarrollo.
Aumenta la reutilización de componentes.
Se producen revisiones iniciales rápidas.
Fomenta la retroalimentación de los clientes.
La integración desde el principio resuelve muchos problemas de integración.
Las desventajas del modelo RAD son las siguientes:
Dependencia de miembros del equipo técnicamente sólidos para identificar los requisitos comerciales.
Solo el sistema que se puede modularizar se puede construir usando RAD.
Requiere desarrolladores / diseñadores altamente calificados.
Gran dependencia de las habilidades de modelado.
Inaplicable a proyectos más económicos, ya que el costo del modelado y la generación de código automatizado es muy alto.
La complejidad de la gestión es mayor.
Adecuado para sistemas escalables y basados en componentes.
Requiere la participación del usuario durante todo el ciclo de vida.
Adecuado para proyectos que requieren tiempos de desarrollo más cortos.
La creación de prototipos de software se refiere a la creación de prototipos de aplicaciones de software que muestran la funcionalidad del producto en desarrollo, pero que en realidad pueden no tener la lógica exacta del software original.
La creación de prototipos de software se está volviendo muy popular como modelo de desarrollo de software, ya que permite comprender los requisitos del cliente en una etapa temprana de desarrollo. Ayuda a obtener comentarios valiosos del cliente y ayuda a los diseñadores y desarrolladores de software a comprender qué se espera exactamente del producto en desarrollo.
¿Qué es la creación de prototipos de software?
Prototype es un modelo funcional de software con algunas funciones limitadas. El prototipo no siempre mantiene la lógica exacta utilizada en la aplicación de software real y es un esfuerzo adicional que debe considerarse en la estimación del esfuerzo.
La creación de prototipos se utiliza para permitir a los usuarios evaluar las propuestas de los desarrolladores y probarlas antes de la implementación. También ayuda a comprender los requisitos que son específicos del usuario y que pueden no haber sido considerados por el desarrollador durante el diseño del producto.
A continuación se explica un enfoque paso a paso para diseñar un prototipo de software.
Identificación de requisitos básicos
Este paso implica comprender los requisitos básicos del producto, especialmente en términos de interfaz de usuario. Los detalles más intrincados del diseño interno y los aspectos externos como el rendimiento y la seguridad pueden ignorarse en esta etapa.
Desarrollando el Prototipo inicial
El prototipo inicial se desarrolla en esta etapa, donde se muestran los requisitos muy básicos y se proporcionan interfaces de usuario. Es posible que estas características no funcionen exactamente de la misma manera internamente en el software real desarrollado. Mientras tanto, las soluciones alternativas se utilizan para dar la misma apariencia al cliente en el prototipo desarrollado.
Revisión del prototipo
A continuación, el prototipo desarrollado se presenta al cliente y a las demás partes interesadas importantes del proyecto. La retroalimentación se recopila de manera organizada y se utiliza para futuras mejoras en el producto en desarrollo.
Revisar y mejorar el prototipo
La retroalimentación y los comentarios de revisión se discuten durante esta etapa y se llevan a cabo algunas negociaciones con el cliente en función de factores como: limitaciones de tiempo y presupuesto y viabilidad técnica de la implementación real. Los cambios aceptados se incorporan nuevamente en el nuevo Prototipo desarrollado y el ciclo se repite hasta que se cumplen las expectativas del cliente.
Los prototipos pueden tener dimensiones horizontales o verticales. Un prototipo horizontal muestra la interfaz de usuario del producto y ofrece una vista más amplia de todo el sistema, sin concentrarse en las funciones internas. Un prototipo vertical en el otro lado es una elaboración detallada de una función específica o un subsistema en el producto.
El propósito del prototipo tanto horizontal como vertical es diferente. Los prototipos horizontales se utilizan para obtener más información sobre el nivel de la interfaz de usuario y los requisitos comerciales. Incluso se puede presentar en las demostraciones de ventas para hacer negocios en el mercado. Los prototipos verticales son de naturaleza técnica y se utilizan para obtener detalles del funcionamiento exacto de los subsistemas. Por ejemplo, los requisitos de la base de datos, la interacción y las cargas de procesamiento de datos en un subsistema determinado.
Prototipos de software: tipos
Existen diferentes tipos de prototipos de software que se utilizan en la industria. A continuación se muestran los principales tipos de prototipos de software que se utilizan ampliamente:
Prototipos desechables / rápidos
La creación de prototipos desechables también se denomina creación de prototipos rápida o cerrada. Este tipo de creación de prototipos utiliza muy pocos esfuerzos con un análisis de requisitos mínimos para construir un prototipo. Una vez que se entienden los requisitos reales, el prototipo se descarta y el sistema real se desarrolla con una comprensión muy clara de los requisitos del usuario.
Prototipos evolutivos
La creación de prototipos evolutivos, también denominada prototipos de placa de pruebas, se basa en la construcción de prototipos funcionales reales con una funcionalidad mínima al principio. El prototipo desarrollado forma el corazón de los futuros prototipos sobre los que se construye todo el sistema. Mediante el uso de prototipos evolutivos, los requisitos bien entendidos se incluyen en el prototipo y los requisitos se agregan a medida que se comprenden.
Prototipos incrementales
La creación de prototipos incrementales se refiere a la construcción de múltiples prototipos funcionales de los diversos subsistemas y luego a integrar todos los prototipos disponibles para formar un sistema completo.
Prototipos extremos
La creación de prototipos extremos se utiliza en el dominio del desarrollo web. Consta de tres fases secuenciales. Primero, se presenta un prototipo básico con todas las páginas existentes en formato HTML. Luego, el procesamiento de datos se simula utilizando una capa de servicios prototipo. Finalmente, los servicios se implementan e integran al prototipo final. Este proceso se llama Prototipado Extremo y se usa para llamar la atención sobre la segunda fase del proceso, donde se desarrolla una interfaz de usuario completamente funcional con muy poca atención a los servicios reales.
Prototipos de software: aplicación
La creación de prototipos de software es más útil en el desarrollo de sistemas que tienen un alto nivel de interacciones del usuario, como los sistemas en línea. Los sistemas que necesitan que los usuarios completen formularios o pasen por varias pantallas antes de que se procesen los datos pueden usar la creación de prototipos de manera muy efectiva para brindar la apariencia exacta incluso antes de que se desarrolle el software real.
El software que implica demasiado procesamiento de datos y la mayor parte de la funcionalidad es interna con muy poca interfaz de usuario no suele beneficiarse de la creación de prototipos. El desarrollo de prototipos podría ser una sobrecarga adicional en tales proyectos y puede requerir muchos esfuerzos adicionales.
Prototipos de software: pros y contras
La creación de prototipos de software se utiliza en casos típicos y la decisión debe tomarse con mucho cuidado para que los esfuerzos invertidos en la construcción del prototipo agreguen un valor considerable al software final desarrollado. El modelo tiene sus propios pros y contras que se comentan a continuación.
Las ventajas del modelo de creación de prototipos son las siguientes:
Mayor participación del usuario en el producto incluso antes de su implementación.
Dado que se muestra un modelo de trabajo del sistema, los usuarios obtienen una mejor comprensión del sistema que se está desarrollando.
Reduce el tiempo y el costo ya que los defectos se pueden detectar mucho antes.
Los comentarios de los usuarios más rápidos están disponibles, lo que conduce a mejores soluciones.
La funcionalidad faltante se puede identificar fácilmente.
Se pueden identificar funciones confusas o difíciles.
Las desventajas del modelo de creación de prototipos son las siguientes:
Riesgo de análisis de requisitos insuficiente debido a una dependencia excesiva del prototipo.
Los usuarios pueden confundirse con los prototipos y los sistemas reales.
En la práctica, esta metodología puede aumentar la complejidad del sistema ya que el alcance del sistema puede expandirse más allá de los planes originales.
Los desarrolladores pueden intentar reutilizar los prototipos existentes para construir el sistema real, incluso cuando no sea técnicamente factible.
El esfuerzo invertido en la construcción de prototipos puede ser demasiado si no se supervisa adecuadamente.