Flores Fuentes Kevin Tarea: #5

1. Software Development Life Cycle (SDLC)

El ciclo de vida de desarrollo de software (SDLC) es un marco que define las tareas
realizadas en cada paso del proceso de desarrollo de software. SDLC es una
estructura seguida por un equipo de desarrollo dentro de la organización de
software. Consiste en un plan detallado que describe cómo desarrollar, mantener y
reemplazar software específico.

El ciclo de vida define una metodología para mejorar la calidad del software y el
proceso de desarrollo general. El ciclo de vida del desarrollo de software también
se conoce como el proceso de desarrollo de software.

El desarrollo de software personalizado comienza con una idea, que luego se

documenta para iniciar el proceso de desarrollo. Después de que el equipo de
desarrollo de documentación comienza a trabajar en él y sigue una serie de pasos.
La secuencia completa de pasos que conducen a la entrega del software terminado
se conoce como Software Development Lifecycle (SDLC). Para la entrega exitosa
de cualquier software, se debe seguir el marco SDLC.

SDLC consta de las siguientes actividades:

 Planificación: las partes más importantes del desarrollo de software, la

recopilación de requisitos o el análisis de requisitos suelen ser realizadas por
los ingenieros de software más calificados y experimentados de la
organización. Después de que los requisitos se recopilan del cliente, se crea
un documento de alcance en el que se determina y documenta el alcance del
proyecto.
 Implementación: Los ingenieros de software comienzan a escribir el código
de acuerdo con los requisitos del cliente.
 Prueba: este es el proceso de encontrar defectos o errores en el software
creado.
 Documentación: Cada paso en el proyecto está documentado para referencia
futura y para la mejora del software en el proceso de desarrollo. La
documentación de diseño puede incluir la escritura de la interfaz de
programación de aplicaciones (API).
 Implementación y mantenimiento: el software se implementa después de que
se haya aprobado su lanzamiento.
 Mantenimiento: El mantenimiento del software se realiza para referencia
futura. La mejora del software y los nuevos requisitos (solicitudes de cambio)
pueden llevar más tiempo del necesario para crear el desarrollo inicial del
software.

Todas las etapas anteriores se mencionan generalmente en el Acuerdo de Nivel de

Servicio (SLA) por la compañía de desarrollo de software antes de comenzar con el
proyecto. La calidad del proyecto terminado depende de qué tan bien se hayan
seguido los pasos de SDLC durante el desarrollo de la solución de software.
Flores Fuentes Kevin Tarea: #5

Sin embargo, el hecho es que el proceso de desarrollo de software nunca termina

el ciclo.

Dio una serie de beneficios en el desarrollo de software, tales como:

 Se sabe que es el mejor método para la planificación, programación y

estimación de proyectos.
 Ayuda en el seguimiento del progreso del proyecto.
 Aumenta la velocidad de desarrollo.
 Ayuda en la gestión de proyectos.
 Disminuye el riesgo del proyecto y la gestión del proyecto.

2.Metodologías de Diseño de Software.

En el campo del desarrollo de software, existen dos grupos de metodologías, las
denominadas tradicionales (formales) y las ágiles. Las primeras son un tanto rígidas,
exigen una documentación exhaustiva y se centran en cumplir con el plan del
proyecto definido totalmente en la fase inicial del desarrollo del mismo; mientras que
la segunda enfatiza el esfuerzo en la capacidad de respuesta a los cambios, las
habilidades del equipo y mantener una buena relación con el usuario.
Ambas propuestas tienen sus propias ventajas y desventajas; de cualquier manera,
las metodologías de desarrollo nos dicen el ¿Qué hacer? más no el ¿Cómo hacer?

2.1 Waterfall (Cascada)

En Ingeniería de software el desarrollo en cascada, es denominado así por la
posición de las fases en el desarrollo de esta, que parecen caer en cascada hacia
las siguientes fases. Es el enfoque metodológico que ordena rigurosamente las
Flores Fuentes Kevin Tarea: #5

etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada
etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el
modelo está diseñado para llevar a cabo una revisión final, que se encarga de
determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue
el primero en originarse y es la base de todos los demás modelos de ciclo de vida.
Este modelo comenzó a diseñarse en 1966 y se terminó alrededor de 1970. El
principal problema de esta aproximación es el que no podemos esperar que las
especificaciones iníciales sean correctas y completas y que el usuario puede
cambiar de opinión sobre una u otra característica. Además, los resultados no se
pueden ver hasta muy avanzado el proyecto por lo que cualquier cambio debido a
un error puede suponer un gran retraso además de un alto coste de desarrollo.
Como es evidente esto es solo un modelo teórico, si el usuario cambia de opinión
en algún aspecto tendremos que volver hacia atrás en el ciclo de vida.

Ingeniería y Análisis del Sistema: debido que el software es siempre parte de un

sistema mayor, el trabajo comienza estableciendo los requisitos de todos los
elementos del sistema y luego asignando algún subconjunto de estos requisitos al
software.
Análisis de los requisitos del software: el proceso de recopilación de los
requisitos se centra e intensifica especialmente en el software. El ingeniero de
software (Analistas) debe comprender el ámbito de la información del software, así
como la función, el rendimiento y las interfaces requeridas.
Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa:
la estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. Codificación: el diseño debe traducirse en una forma
legible para la máquina. El paso de codificación realiza esta tarea. Si el diseño se
realiza de una manera detallada la codificación puede realizarse mecánicamente.
Flores Fuentes Kevin Tarea: #5

Prueba: una vez que se ha generado el código comienza la prueba del programa.
La prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados
que realmente se requieren.
Mantenimiento: el software sufrirá cambios después de que se entrega al cliente.
Los cambios ocurrirán debido a se han encontrado errores, a que el software deba
adaptarse a cambios del entorno externo (sistema operativo o dispositivos
periféricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.
Ventajas:

 Rápida respuesta a cambios de requisitos a lo largo del desarrollo del

proyecto gracias a su proceso iterativo.
 El cliente, si quiere colaborar, puede observar cómo va avanzando el
proyecto, y por supuesto, opinar sobre su evolución gracias a las numerosas
reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.
Desventajas:

 Los proyectos reales raramente siguen el flujo secuencial que propone el

modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
 Es difícil para el cliente establecer explícitamente al principio todos los
requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar
posibles incertidumbres que pueden existir al comienzo de muchos
productos.

2.2 Prototyping
Un prototipo es una versión preliminar de un sistema de información con fines de
demostración o evaluación. El prototipo de requerimientos es la creación de una
implementación parcial de un sistema, para el propósito explícito de aprender sobre
los requerimientos del sistema. Un prototipo es construido de una manera rápida tal
como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos,
posibilitando que ellos experimenten con el prototipo. Estos individuos luego
proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del
prototipo proporcionado, quienes capturan en la documentación actual de la
especificación de requerimientos la información entregada por los usuarios para el
desarrollo del sistema real.
El prototipo puede ser usado como parte de la fase de requerimientos (determinar
requerimientos) o justo antes de la fase de requerimientos (como predecesor de
Flores Fuentes Kevin Tarea: #5

requerimientos). En otro caso, el prototipo puede servir su papel inmediatamente

antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.
El prototipo ha sido usado frecuentemente en los 90, porque la especificación de
requerimientos para sistemas complejos tiende a ser relativamente dificultoso de
cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer
retroalimentación convenientemente basada en la manipulación, leer una
especificación de requerimientos potencialmente ambigua y extensa. Diferente del
modelo evolutivo donde los requerimientos mejor entendidos están incorporados,
un prototipo generalmente se construye con los requerimientos entendidos más
pobremente. En caso que ustedes construyan requerimientos bien entendidos, el
cliente podría responder con "sí, así es", y nada podría ser aprendido de la
experiencia.

Ventajas:

 Útiles cuando los requerimientos son cambiantes.

 Cuando el usuario no se quiere comprometer con los requerimientos.
 Cuando se requiere rapidez en el desarrollo
Desventajas:

 No se conoce cuando se tendrá un producto aceptable.

 No se sabe cuántas iteraciones serán necesarias.
 Se puede volver el producto aún y cuando no esté con los estándares.
Flores Fuentes Kevin Tarea: #5

3. Bibliografía

 Demián Gutierrez. (2011). Metodos de Desarrollo de Software. 2019,

de Universidad de los Andes Sitio web:
http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_
procesos.pdf
 -. (-). Software Development Life Cycle. 2019, de TechoPedia Sitio
web: https://www.techopedia.com/definition/22193/software-
development-life-cycle-sdlc
 ADMIN. (2019). Software Development Life Cycle (SDLC). 2019, de
winklix Sitio web: https://www.winklix.com/blog/software-
development-life-cycle-sdlc/