Ciclo de Vida SDLC

UNIVERSIDAD NACIONAL AUTONOMA DE HONDURAS
Pág.1
UNIVERSIDAD NACIONAL
AUTONOMA DE HONDURAS
“UNAH”
CICLO DE VIDA DE DESARROLLO DE SOFTWARE

“SDLC”
Clase: Análisis y Diseño de Sistemas
Ingeniero: Andrea Martínez
Presentado Por:
 Kevin Balerio Sánchez Aguilar
20151003973
Lugar y Fecha: Tegucigalpa F.M. Viernes 19 de Octubre 2018.
UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

Pág.2
CICLO DE VIDA DE DESARROLLO DE SOFTWARE SDLC
SDLC significa Ciclo de Vida de Desarrollo de Software. SDLC es un proceso que consiste en
una serie de actividades planificadas para desarrollar o alterar los Productos de Software. Este
tutorial le dará una descripción general de los conceptos básicos de SDLC, los modelos de
SDLC disponibles y su aplicación en la industria. Este tutorial también explica otras
metodologías relacionadas como Agile, RAD y Prototyping.
SDLC - DESCRIPCIÓN GENERAL
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 objetivo de SDLC es
producir un software de alta calidad que cumpla o supere las expectativas del cliente, que se
complete dentro de los plazos y las estimaciones de costos.
 SDLC es el acrónimo de Software Development Life Cycle.
 También se le llama como 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 procesos de ciclo de vida de

software. Su objetivo es ser el estándar que define todas las tareas necesarias para
desarrollar y mantener el software.
SDLC es un proceso seguido 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
alterar o mejorar software específico. El ciclo de vida define una metodología para mejorar la
calidad del software y el proceso de desarrollo general.
La siguiente figura es una representación gráfica de las diversas etapas de un SDLC típico.

Pág.3
Un ciclo de vida de desarrollo de software típico consiste en las siguientes etapas:
Etapa 1: Planificación y análisis de requerimientos

El análisis de requerimientos es la etapa más importante y fundamental en el SDLC. Es
realizado por los miembros principales del equipo con aportaciones 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 realizan 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 los riesgos mínimos.
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 del
mercado. Esto se realiza a través de un documento SRS (Especificación de requisitos de
software) que consta de todos los requisitos del producto que se diseñarán y desarrollarán
durante el ciclo de vida del proyecto.

Pág.4
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 que se va a desarrollar. De acuerdo con los requisitos especificados en SRS,
generalmente se propone y documenta más de un enfoque de diseño para la arquitectura del
producto en un DDS - Especificación de documento de diseño.
Este DDS es revisado por todas las partes interesadas importantes y se basa en diversos
parámetros como la evaluación de riesgos, la solidez del producto, la modularidad del diseño,
el presupuesto y las limitaciones de tiempo, y 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 de flujo de datos con los módulos externos y de terceros
(si los hay). El diseño interno de todos los módulos de la arquitectura propuesta debe definirse
claramente con el más mínimo detalle en el DDS.
Etapa 4: Construcción o desarrollo del producto

En esta etapa de SDLC se inicia 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 se puede realizar sin mucha molestia.
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. Se utilizan diferentes lenguajes de programación de alto nivel como C,
C ++, Pascal, Java y PHP para la codificación. El lenguaje de programación se elige con
respecto al tipo de software que se está desarrollando.
Etapa 5: Probando el producto

Esta etapa suele ser un subconjunto de todas las etapas, ya que en los modelos modernos de
SDLC, 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 única del producto donde los
defectos del producto se informan, se rastrean, se arreglan y se vuelven a probar, hasta que el
producto alcanza los estándares de calidad definidos en el SRS.

Pág.5
Etapa 6: Despliegue en el Mercado y Mantenimiento

Una vez que el producto está probado y listo para ser implementado, se lanza formalmente en
el mercado apropiado. A veces, la implementación del producto ocurre en etapas según la
estrategia de negocios de esa organización. El producto puede lanzarse primero en un
segmento limitado y probarse en el entorno empresarial real (UAT, prueba de aceptación del
usuario).
Luego, en función de los comentarios, el producto puede lanzarse tal como está o con las
mejoras sugeridas en el segmento de mercado de segmentación. Una vez que el producto se
lanza al mercado, su mantenimiento se realiza 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 conocen como
modelos de procesos de desarrollo de software ". Cada modelo de proceso sigue una serie de
pasos únicos a su tipo para garantizar el éxito en el proceso de desarrollo de software.
Los siguientes son los modelos SDLC más importantes y populares seguidos en la industria &
miuns;
 Modelo de cascada
 Modelo iterativo
 Modelo espiral
 Modelo V
 Modelo de Big Bang
Otras metodologías relacionadas son el modelo ágil, el modelo RAD, el desarrollo rápido de
aplicaciones y los modelos de creación de prototipos

Pág.6
SDLC - Modelo de cascada
El modelo de cascada fue el primer modelo de proceso que se introdujo. También se le conoce
como un modelo de ciclo de vida lineal-secuencial . Es muy simple de entender y usar. En un
modelo de cascada, cada fase debe completarse antes de que la siguiente fase pueda comenzar
y no haya superposición en las fases.
El modelo Waterfall es el primer enfoque SDLC que se utilizó para el desarrollo de software.
El modelo de cascada ilustra el proceso de desarrollo de software en un flujo secuencial

lineal. Esto significa que cualquier fase en el 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 de cascada fue el primer modelo SDLC que se usó ampliamente en Ingeniería de
Software para asegurar el éxito del proyecto. En el enfoque de "The Waterfall", todo el
proceso de desarrollo de software se divide en fases separadas. En este modelo de cascada, por
lo general, 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.

Pág.7
Las fases secuenciales en el modelo de cascada son:
 Recopilación y análisis de requisitos: todos los requisitos posibles del sistema a

desarrollar se capturan en esta fase y se documentan en un documento de
especificación de requisitos.
 Diseño del sistema: las especificaciones de requisitos de la primera fase se estudian en

esta fase y se prepara el diseño del sistema. El diseño de este sistema ayuda a
especificar los requisitos de hardware y sistema y ayuda a definir la arquitectura
general del sistema.
 Implementación: con los aportes 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 está desarrollada y probada para su funcionalidad, que se conoce
como Unidad de Pruebas.
 Integración y pruebas: 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 fallos.
 Despliegue del sistema: una vez realizadas las pruebas funcionales y no

funcionales; El producto se implementa en el entorno del cliente o se lanza al mercado.
 Mantenimiento: 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 mejores versiones. El mantenimiento se realiza para entregar estos
cambios en el entorno del cliente.
Todas estas fases están conectadas en cascada entre sí, en las que se ve que el progreso fluye
constantemente hacia abajo (como una cascada) a través de las fases. La siguiente fase se
inicia solo después de que se haya alcanzado el conjunto definido de objetivos para la fase
anterior y se haya cerrado, por lo que se llama "Modelo de cascada". En este modelo, las fases
no se superponen.
Modelo de cascada - Aplicación

Cada software desarrollado es diferente y requiere un enfoque de SDLC adecuado a seguir en
función de los factores internos y externos. Algunas situaciones donde el uso del modelo de
cascada es el más apropiado son:
 Los requisitos están muy bien documentados, claros y fijos.

Pág.8
 La definición del producto es estable.
 La tecnología se entiende y no es dinámica.
 No hay requisitos ambiguos.
 Amplios recursos con la experiencia requerida están disponibles 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 una programación con fechas límite para cada etapa de desarrollo y un
producto puede proceder a través de las fases del modelo de proceso de desarrollo una por
una.
El desarrollo se mueve desde el concepto, a través del diseño, implementación, prueba,

instalación, solució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 de cascada 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 tareas.
 El proceso y los resultados están bien documentados.

Pág.9
Modelo de cascada - Desventajas

La desventaja del desarrollo de la 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.
 Altas cantidades de riesgo e incertidumbre.
 No es un buen modelo para proyectos complejos y orientados a objetos.
 Modelo pobre para proyectos largos y continuos.
 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 en etapas.
 No puede acomodar los requisitos cambiantes.
 Ajustar el alcance durante el ciclo de vida puede terminar un proyecto.
 La integración se realiza como un "big bang. Al final, que no permite identificar ningún
cuello de botella tecnológico o de negocios o desafíos antes.
SDLC - Modelo iterativo
En el modelo iterativo, el proceso iterativo comienza con una implementación simple de un

pequeño conjunto de requisitos de software y mejora iterativamente 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
los requisitos. En su lugar, el desarrollo comienza especificando e implementando solo una
parte del software, que luego se revisa para identificar otros requisitos. Este proceso luego se
repite, produciendo una nueva versión del software al final de cada iteración del modelo.

Pág.10
Modelo iterativo - Diseño

El proceso iterativo comienza con una implementación simple de un subconjunto de los
requisitos del software y mejora iterativamente las versiones en evolución hasta que se
implemente 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 (iterativo) y en porciones más pequeñas a la vez
(incremental).
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 construcciones. 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
con respecto a los requisitos dentro de cada ciclo del modelo. A medida que el software
evoluciona a lo largo de ciclos sucesivos, las pruebas deben repetirse y extenderse para
verificar cada versión del software.

Pág.11
Modelo iterativo - Aplicación

Al igual que otros modelos SDLC, el desarrollo iterativo e incremental tiene algunas
aplicaciones específicas en la industria del software. Este modelo se usa con más frecuencia en
los siguientes escenarios:
 Los requisitos del sistema completo están claramente definidos y comprendidos.
 Los requisitos principales deben ser definidos; sin embargo, algunas funcionalidades o
mejoras solicitadas pueden evolucionar con el tiempo.
 Hay un tiempo 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 que se utilicen en base a contratos 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 existe un modelo operativo 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 en 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 de servicio.
Las ventajas del modelo SDLC iterativo e incremental son las siguientes:
 Algunas funcionalidades de trabajo pueden desarrollarse rápidamente y al principio del

ciclo de vida.
 Los resultados se obtienen temprano y periódicamente.
 Se puede planificar un desarrollo paralelo.
 El progreso puede ser medido.
 Menos costoso cambiar el alcance / requisitos.

Pág.12
 Probar y depurar durante una iteración más pequeña es fácil.
 Los riesgos son identificados y resueltos durante la iteración; y cada iteración es un hito
fácilmente manejado.
 Más fácil de administrar el riesgo: la parte de alto riesgo se realiza primero.
 Con cada incremento, se entrega el producto operacional.
 Los problemas, desafíos y riesgos identificados de cada incremento se pueden utilizar /

aplicar al siguiente incremento.
 El análisis de riesgo es mejor.
 Es compatible con los 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 la retroalimentación del cliente.
Las desventajas del modelo de SDLC iterativo e incremental son las siguientes:
 Se pueden requerir más recursos.
 Aunque el costo del cambio es menor, pero no es muy adecuado para los requisitos
cambiantes.
 Se requiere más atención de la gerencia.
 La arquitectura del sistema o los problemas de diseño pueden surgir porque no todos
los requisitos se reúnen 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 más.
 El final del proyecto puede no ser conocido, lo que es un riesgo.
 Se requieren recursos altamente cualificados para el análisis de riesgos.
 El progreso de los proyectos depende en gran medida de la fase de análisis de riesgos.

Pág.13
SDLC - Modelo Espiral
El modelo en espiral combina la idea de desarrollo iterativo con los aspectos sistemáticos y
controlados del modelo de cascada. Este modelo en espiral es una combinación de un modelo
de proceso de desarrollo iterativo y un modelo de desarrollo lineal secuencial, es decir, el
modelo de 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 Espiral - Diseño

El modelo espiral tiene cuatro fases. Un proyecto de software pasa repetidamente por estas
fases en iteraciones llamadas Spirals.
Identificación
Esta fase comienza con la recopilación de los requisitos comerciales en la espiral de
referencia. 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 comprender 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
implementa en el mercado identificado.
Diseño
La fase de diseño comienza con el diseño conceptual en la línea de base espiral e incluye 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 línea de base de la espiral, cuando se piensa en el producto y se está
desarrollando el diseño, se desarrolla un POC (Prueba de concepto) en esta fase para obtener
la opinión del cliente.

Pág.14
Luego, en las espirales posteriores, con mayor claridad en los requisitos y detalles de diseño,
se produce un modelo operativo del software llamado build con un número de versión. Estas
compilaciones se envían al cliente para su retroalimentación.
Evaluación y análisis de riesgos

El análisis de riesgos incluye identificar, estimar y monitorear la viabilidad técnica y los
riesgos de gestión, como el deslizamiento de la programación y el exceso de costos. 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 espiral, que enumera las actividades
en cada fase.
Sobre la base de 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 los comentarios
sugeridos por el cliente. El proceso de iteraciones a lo largo de la espiral continúa a lo largo de
la vida del software.
Aplicación de modelo en espiral

El modelo en espiral se utiliza ampliamente en la industria del software, ya que está en
sintonía con el proceso de desarrollo natural de cualquier producto, es decir, el aprendizaje con
madurez que implica un riesgo mínimo para el cliente y para las empresas de desarrollo.

Pág.15
Los siguientes punteros explican los usos típicos de un modelo en espiral:
 Cuando hay una restricción presupuestaria y la evaluación del riesgo es importante.
 Para proyectos de riesgo medio a alto.
 Compromiso a largo plazo del proyecto 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 que se agreguen elementos
del producto, cuando estén disponibles o se conozcan. 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 compilaciones y
lanzamientos de software que permiten realizar una transición ordenada a una actividad de
mantenimiento. Otro aspecto positivo de este método es que el modelo en espiral obliga a una
participación temprana del usuario en el esfuerzo de desarrollo del sistema.
Por otro lado, se necesita una administració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 recibir solicitudes de cambio es muy importante para desarrollar e
implementar el producto con éxito.
Las ventajas del modelo Spiral SDLC son las siguientes:
 Los requisitos cambiantes pueden ser acomodados.
 Permite el uso extensivo de prototipos.
 Los requisitos pueden ser capturados con mayor precisión.
 Los usuarios ven el sistema temprano.

Pág.16
 El desarrollo se puede dividir en partes más pequeñas y las partes de riesgo se pueden
desarrollar antes, lo que ayuda a una mejor gestión de riesgos.
Las desventajas del modelo Spiral SDLC son las siguientes:
 La gestión es más compleja.
 El final del proyecto puede no ser conocido temprano.
 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.
 Gran cantidad de etapas intermedias requiere documentación excesiva.
SDLC - Modelo V
El modelo V es un modelo SDLC donde la ejecución de procesos se realiza de forma

secuencial en forma de V. También es conocido como modelo de verificación y validación .
El modelo V 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
altamente disciplinado y la siguiente fase comienza solo después de completar la fase anterior.
Modelo V - Diseño
Bajo el Modelo V, la fase de prueba correspondiente de la fase de desarrollo se planea 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.

Pág.17
Modelo V - Fases de verificación

Hay varias fases de verificación en el modelo V, cada una de ellas se explica en detalle a
continuación.
Análisis de requerimientos de negocios

Esta es la primera fase del ciclo de desarrollo donde 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 los 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 qué
necesitan exactamente. La planificación del diseño de la prueba de aceptación se realiza en
esta etapa, ya que los requisitos comerciales se pueden utilizar como información para las
pruebas de aceptación.
Diseño de sistemas
Una vez que tenga los requisitos claros y detallados del producto, es hora de diseñar el sistema
completo. El diseño del sistema comprenderá y detallará la configuración completa de
hardware y 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 de la prueba real más adelante.

Pág.18
Diseño arquitectónico
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 toman funcionalidades
diferentes. Esto también se conoce como diseño de alto nivel (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,
las pruebas de integración se pueden diseñar y documentar durante esta etapa.
Módulo de diseño
En esta fase, se especifica el diseño interno detallado de todos los módulos del sistema,
denominado Diseño de bajo nivel (LLD) . Es importante que el diseño sea compatible con los
otros módulos en 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 las
fallas y errores máximos en una etapa muy temprana. Estas pruebas unitarias pueden diseñarse
en esta etapa basándose en 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 toma en la
fase de codificación. El mejor lenguaje de programación adecuado se decide en función del
sistema y los requisitos arquitectónicos.
La codificación se realiza en base a las pautas y estándares de codificación. El código pasa por
numerosas revisiones de código y está optimizado para obtener el 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. La prueba de unidad es la prueba a nivel de código y ayuda a

Pág.19
eliminar errores en una etapa temprana, aunque todos los defectos no pueden ser descubiertos
por la prueba de unidad.
Pruebas de integración
Las pruebas de integración están asociadas a 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.
Pruebas del sistema

La prueba del sistema está directamente asociada con la fase de diseño del sistema. Las
pruebas del sistema verifican toda la funcionalidad 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 los requisitos del negocio
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 de 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 volver atrás y hacer cambios. Este modelo se utiliza
en el campo del desarrollo médico, ya que es estrictamente un dominio disciplinado.
Los siguientes punteros son algunos de los escenarios más adecuados para usar 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 es bien entendida por el equipo del proyecto.
 No hay requisitos ambiguos o indefinidos.
 El proyecto es corto.

Pág.20
Modelo V - Pros y Contras

La ventaja del método V-Model es que es muy fácil de entender y aplicar. La simplicidad de
este modelo también hace que sea más fácil de administrar. La desventaja es que el modelo no
es flexible a los cambios y, en caso de que haya un cambio en los requisitos, que es muy
común en el mundo dinámico de hoy, resulta muy costoso realizar el cambio.
Las ventajas del método V-Model son las siguientes:
 Este es un modelo altamente 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 del modelo V son las siguientes:
 Alto riesgo e incertidumbre.
 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.
SDLC - Modelo Big Bang
El modelo Big Bang es un modelo SDLC en el que no seguimos ningún proceso específico. El
desarrollo comienza con el dinero requerido y los esfuerzos 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

Pág.21
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 la
codificación del software, con muy poca o ninguna planificación. Los requisitos se entienden e
implementan como vienen. Cualquier cambio requerido puede o no debe 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 de práctica. Es un modelo ideal para el producto
donde los requisitos no se comprenden bien y no se da la fecha de lanzamiento final.
Modelo de Big Bang - Pros y Contras

La ventaja de este modelo de Big Bang es que es muy simple y requiere muy poca o ninguna
planificación. Fácil de manejar 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 malentendidos pueden incluso llevar a una reversión completa o un raspado
del proyecto. Es ideal para proyectos pequeños o repetitivos con riesgos mínimos.
Las ventajas del modelo Big Bang son las siguientes:
 Este es un modelo muy simple.
 Se requiere poca o ninguna planificación
 Fácil de manejar
 Muy pocos recursos requeridos
 Da flexibilidad a los desarrolladores
 Es una buena ayuda de aprendizaje para los recién llegados o estudiantes.
Las desventajas del modelo de Big Bang son las siguientes:
 Muy alto riesgo e incertidumbre.

Pág.22
BIBLIOGRAFIA
TUTORIAS POINT. (2018). SDLC Ciclo de Vida de Desarrollo de Software. octubre

2018, de TUTORIAS POINT Sitio web:
https://www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm

Ciclo de Vida SDLC

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ciclo de Vida SDLC

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD NACIONAL AUTONOMA DE HONDURAS

CICLO DE VIDA DE DESARROLLO DE SOFTWARE

Clase: Análisis y Diseño de Sistemas

Ingeniero: Andrea Martínez

Lugar y Fecha: Tegucigalpa F.M. Viernes 19 de Octubre 2018.

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

CICLO DE VIDA DE DESARROLLO DE SOFTWARE SDLC

SDLC - DESCRIPCIÓN GENERAL

 SDLC es el acrónimo de Software Development Life Cycle.

 También se le llama como Proceso de Desarrollo de Software.

 ISO / IEC 12207 es un estándar internacional para procesos de ciclo de vida de

SDLC es un proceso seguido para un proyecto de software, dentro de una organización de

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

Un ciclo de vida de desarrollo de software típico consiste en las siguientes etapas:

Etapa 1: Planificación y análisis de requerimientos

La planificación de los requisitos de garantía de calidad y la identificación de los riesgos

Etapa 2: Definición de requisitos

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

Etapa 3: Diseño de la arquitectura del producto

Etapa 4: Construcción o desarrollo del producto

Etapa 5: Probando el producto

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

Etapa 6: Despliegue en el Mercado y Mantenimiento

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

SDLC - Modelo de cascada

El modelo de cascada ilustra el proceso de desarrollo de software en un flujo secuencial

Modelo de cascada - Diseño

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

Las fases secuenciales en el modelo de cascada son:

 Recopilación y análisis de requisitos: todos los requisitos posibles del sistema a

 Diseño del sistema: las especificaciones de requisitos de la primera fase se estudian en

 Integración y pruebas: todas las unidades desarrolladas en la fase de implementación

 Despliegue del sistema: una vez realizadas las pruebas funcionales y no

Modelo de cascada - Aplicación

 Los requisitos están muy bien documentados, claros y fijos.

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

 La definición del producto es estable.

 La tecnología se entiende y no es dinámica.

 No hay requisitos ambiguos.

 Amplios recursos con la experiencia requerida están disponibles para respaldar el

Modelo de cascada - Ventajas

El desarrollo se mueve desde el concepto, a través del diseño, implementación, prueba,

 Simple y fácil de entender y usar

 Las fases se procesan y completan una a la vez.

 Etapas claramente definidas.

 Hitos bien entendidos.

 Fácil de organizar tareas.

 El proceso y los resultados están bien documentados.

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

Modelo de cascada - Desventajas

Las principales desventajas del modelo de cascada son las siguientes:

 Altas cantidades de riesgo e incertidumbre.

 No es un buen modelo para proyectos complejos y orientados a objetos.

 Modelo pobre para proyectos largos y continuos.

 Es difícil medir el progreso en etapas.

 No puede acomodar los requisitos cambiantes.

 Ajustar el alcance durante el ciclo de vida puede terminar un proyecto.

SDLC - Modelo iterativo

En el modelo iterativo, el proceso iterativo comienza con una implementación simple de un

UNAH/ III PERIODO 2018 / ANALISIS Y DISEÑO DE SISTEMAS

Modelo iterativo - Diseño

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