CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

DESARROLLO

DEFINICION DE CICLO DE VIDA

Ciclo de vida de un software, según Pressman.”Es el conjunto de fases por las que pasa el sistema que se
está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado
(muere)”. También se denomina a veces un paradigma.
El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas), es una secuencia estructurada y
está bien definida las etapas en Ingeniería de software para el desarrollo de un producto de software
deseado.
El SDLC es una metodología que está definida en fases para el análisis y diseño, de acuerdo con el cual
los sistemas se desarrolla mucho mejor al utilizar un ciclo específico de actividades tanto para el analista
como los usuarios.
Los analistas no han logrado tener un acuerdo sobre la cantidad de fases que hay en el SDLC, pero por
lo general se alaban de su metodología organizada. Las fases están compuesta en 7 como se muestra en
la siguiente imagen, aunque nunca se puede llevar a cabo como un paso separado, sino que se realiza
varias actividades que ocurre al mismo tiempo, e incluso se pueden repetir.

Figuar 1 7 fases del ciclo de vida de desarrollo de software

Fuente: tomado del libro Analisis y Diseño de Sistemas, Kendal y Kendal, 8 edicion, pagina 8

Las 7 fases del ciclo de vida son:

Identificación de los problemas, oportunidades y objetivos
En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista es el encargado de
identificar correctamente los problemas, las oportunidades y los objetivos. Esta etapa es imprescindible
para el éxito del resto del proyecto, ya que a nadie le gusta desperdiciar el tiempo resolviendo un
problema que este mal caracterizado.
En la primera fase el analista debe realizar un análisis con honestidad lo que está ocurriendo en la
empresa. Después, con los demás miembros de la organización, debe señalar los problemas. A menudo,
otras personas también habrían planteado estos problemas, razón por la cual a esto se llamó en un
principio al analista. Las oportunidades esta resididas en las situaciones que el analista cree poder hacer
mejorar por el uso de sistemas de información computarizados. Al aprovechar estas oportunidades, la
empresa puede obtener una ventaja competitiva o establecer un estándar en la industria.
La identificación de los objetivos también es un componente muy importante ya que el analista debe
descubrir primeramente qué trata de hacer o realizar la empresa; para después ser capaz de determinar si
alguno de los aspectos de las aplicaciones de los sistemas de información les permita ser de ayudar a que
la empresa logre sus objetivos al enfrentar problemas u oportunidades que sea específicos.
Las personas que se involucran en la primera fase son los usuarios, los analistas y los administradores de
sistemas que son las que coordinan el proyecto. En esta fase las actividades que realizan consisten en
realizar una serie de entrevistas a los encargados de la administración de los usuarios, de poder sintetizar
el conocimiento que se obtuvo, de estimar el alcance del proyecto y documentar los resultados. El
resultado de esta fase se hace un informe de viabilidad, el cual contiene la definición de un problema y
sintetiza los objetivos. Después, la administración de la empresa debe tomar una decisión en cuanto a
que debe proceder o no con el proyecto propuesto. Si el grupo de usuarios no tiene suficientes fondos en
su presupuesto o quiere hacer frente a problemas que no están relacionados, o si los problemas no
requieren un sistema computacional, tal vez se pueda hacer una solución distinta y el proyecto de
sistemas no puede ser continuado.

Determinación de los requerimientos de información del factor humano

En esta fase es que entra el analista en determinar cuáles son las necesidades de los usuarios que están
involucrados, por medio del uso de muchas herramientas, para poder comprender la forma en que
interactúan en el contexto laboral con sus sistemas de información actuales. El analista deberá utilizar
métodos interactivos como entrevistas, muestreos e investigación de datos duros, además de los
cuestionarios y los métodos discretos, como mirar el comportamiento de los encargados en el momento
de tomar las decisiones y sus entornos de oficina, y los métodos integrales como la creación de
prototipos.
El analista utilizará estos métodos para plantear y responder muchas preguntas relacionadas con la
interacción humano-computadora (HCI), en que se incluye preguntas como: “¿Cuáles son las fortalezas
y limitaciones físicas de los usuarios?”, o “¿qué hay que hacer para que el sistema sea perceptible,
legible y seguro?”, “¿cómo se puede diseñar el nuevo sistema para que sea de fácil de uso, de aprender
y de recordar?”, “¿cómo puede el sistema que sea agradable o incluso divertido al momento de usar?”,
“¿cómo puede el sistema apoyar las tareas laborales individuales de un usuario y poder buscar nuevas
formas de hacerla que sea más productivas?”.
En esta fase, el analista se esforzara por comprender qué información requieren o necesitan los usuarios
para realizar sus trabajos. En este punto el analista debe examinar cómo hacer que el sistema sea útil
para las personas que se involucraran con este sistema. ¿Cómo puede el sistema ofrecer un mejor apoyo
para las tareas individuales que se llevara a cabo? ¿Qué nuevas tareas hace habilitar el nuevo sistema
que los usuarios no puedan hacer sin su ayuda?
Las personas que se involucran en esta fase son los analistas y los usuarios, por lo general los gerentes y
los trabajadores de operaciones. El analista de sistema debe conocer los detalles sobre las funciones del
sistema actual: el quién o las personas involucradas, el qué (la actividad de la empresa), el dónde (el
entorno o el medio en el que se llevara a cabo el trabajo), el cuándo (la coordinación) y el cómo (de qué
manera particular se realizan los procedimientos actuales) de la empresa a la que está estudiando.
Después, el analista debe hacer preguntas de por qué la empresa utiliza el sistema actual. Puede que
tenga buenas razones por las cuales la empresa trabaje con los métodos actuales, razón por la que se
deben tener en cuenta al diseñar un nuevo sistema.
El desarrollo ágil se hace por la metodología orientada a objetos (OOA) para el desarrollo de sistemas,
en la cual incluye un método de desarrollo junto con la generación de los requerimientos de
información, así como herramientas de software.
No obstante, si la razón de seguir con las operaciones actuales es que “siempre se ha hecho de esa
forma”, el analista querrá mejorar los procedimientos. Al finalizar esta fase, el analista deberá
comprender la forma en que los usuarios realizan su trabajo al interactuar con una computadora y deberá
empezar a comprender cómo mejorar la utilidad y capacidad de uso del nuevo sistema. También deberá
saber cómo funciona la empresa y tener información completa sobre personas, objetivos, datos y
procedimientos involucrados.

Análisis de las necesidades del sistema

La siguiente fase que debe llevar a cabo el analista de sistemas debe involucrar el análisis de las
necesidades del sistema. Aquí también hay herramientas y técnicas que son especiales que permite
ayudar al analista a realizar las determinaciones de los requerimientos. En que se usa las herramientas
como los diagramas de flujo de datos (DFD) que sirve para graficar la entrada, los procesos y la salida
de las funciones de la empresa, o los diagramas de actividad o de secuencia para mostrar la secuencia de
los eventos, estos sirven para ilustrar a los sistemas de una manera estructurada y gráfica. A partir de los
diagramas de flujo de datos, de secuencia u otros tipos de diagramas se hace el desarrollo de un
diccionario de datos para listar todos los elementos de datos que fueron utilizados en el sistema, así
como sus especificaciones.
Durante esta fase, el analista de sistemas también analiza las decisiones estructuradas llevadas a cabo.
Las decisiones estructuradas son aquellas para las que pueden determinar condiciones, alternativas de
condición, acciones y reglas de acción. Existe tres métodos principales para el análisis de las decisiones
estructuradas que son: inglés/español estructurado, tablas de decisión y árboles de decisión.
En este punto del SDLC, el analista de sistemas preparara una propuesta de sistemas en la que debe
sintetizar todo lo que ha investigado sobre los usuarios, la capacidad de uso y la utilidad de los sistemas
actuales; incluyendo un análisis de costo-beneficio de las alternativas y, si se requiere, hace
recomendaciones. Si la administración acepta una de las recomendaciones, el análisis continúa por esa
vía. Cada problema de sistemas es único, por lo que nunca hay una solución correcta. La manera en que
se formule una recomendación o solución depende de las cualidades individuales y la capacitación
profesional de cada analista, y de su interacción con los usuarios en el contexto de su entorno laboral.

Diseño del sistema recomendado

En la fase de diseño del SDLC, el analista de sistemas utiliza la información que se recolecto antes para
realizar el diseño lógico del sistema de información. El analista hace el diseño de los procedimientos
para ayudar a que los usuarios introduzcan los datos con precisión, de manera que los datos que entren al
sistema de información sean los correctos. Además, el analista debe ayudar a que los usuarios completen
la entrada de datos efectiva al sistema de información por medio del uso de las técnicas del buen diseño
de formularios y páginas Web.
La parte del diseño lógico del sistema de información es idear la HCI. La interfaz se conecta el usuario
con el sistema, lo que es muy importante. La interfaz del usuario se diseña con la ayuda de los usuarios
para asegurar que el sistema sea fácil de percibir, legible y seguro, así como atractivo y divertido de
usar. Ejemplos de interfaces de usuario físicas son el teclado en que permite escribir las preguntas y
respuestas, los menús en pantalla y varios tipos de interfaces gráficas de usuario (GUI) basadas en un
ratón o una pantalla táctil.
La fase de diseño también incluye el diseño de bases de datos que almacenarán gran parte de los datos
que son necesarios para los encargados de tomar las decisiones en la organización. Los usuarios se
benefician de una base de datos bien organizada que sea lógica para ellos y se corresponda con la forma
en que ven su trabajo. En esta fase, el analista también trabaja con los usuarios para diseñar una salida
(ya sea en pantalla o impresa) que cumpla con sus necesidades de información.
Por último, el analista debe diseñar controles y procedimientos de respaldo para proteger el sistema y los
datos, y para producir paquetes de especificación de programas para los programadores. Cada paquete
debe contener los diseños de las entradas y las salidas, las especificaciones de los archivos y los detalles
sobre el procesamiento; también puede incluir árboles o tablas de decisión, UML o diagramas de flujo
de datos, junto con los nombres y las funciones de cualquier código previamente escrito dentro de la
empresa o que utilice código u otras bibliotecas de clases.

Desarrollo y documentación del software

En la quinta fase del SDLC, el analista trabaja con los programadores durante el desarrollo del software
original requerido. En ello, el analista desarrollara junto con los usuarios una documentación efectiva
para el software, en que incluye manuales de procedimientos, ayuda en línea, sitios Web con preguntas
frecuentes y archivos Léame (Read Me) para incluir en el nuevo software. Como los usuarios están
involucrados desde el principio, la fase de documentación debe estar lidiado con las preguntas que se
hicieron y que se resolvieron junto con el analista. La documentación debe indicar a los usuarios cómo
deben usar el software y qué deben hacer en caso de que ocurran problemas.
Los programadores desempeñan un rol muy importante en esta fase, ya que diseñan, codifican y
eliminan los errores que son sintácticos de los programas de computadora. Para poder asegurar la
calidad, el programador puede llevar a cabo un recorrido por el diseño o por el código para explicar las
porciones complejas del programa a un equipo formado por otros programadores.

Prueba y mantenimiento del sistema

Antes de utilizar el sistema de información, se debe hacer las pruebas. Es menos costoso detectar los
problemas antes de entregar el sistema a los usuarios. Una parte del procedimiento de prueba se lleva a
cabo por los programadores solos; la otra se realiza junto con los analistas de sistemas. Primero se
completa una serie de pruebas para señalar los problemas con unos datos de muestra y después se
utilizan datos reales del sistema actual. A menudo, los planes de prueba se crean en las primeras etapas
del SDLC y son refinados a medida que el proyecto este progresando.
El mantenimiento del sistema y la documentación de este mantenimiento empiezan en esta fase y se
lleva a cabo de manera de rutina durante toda la vida del sistema de información. Gran parte del trabajo
rutinario del programador consiste en el mantenimiento, por lo cual las empresas hacen una inversión de
gran cantidad de dinero durante este proceso.
Ciertos procedimientos de mantenimiento, como las actualizaciones de los programas, se pueden llevar a
cabo a través del sitio Web del distribuidor. Muchos de los procedimientos sistemáticos que emplea el
analista durante el SDLC pueden ayudar a asegurar que el mantenimiento siempre se mantenga en el
nivel mínimo necesario.

Implementación y evaluación del sistema

En esta última fase del desarrollo de sistemas, el analista ayuda a implementar el sistema de
información. En esta fase hay que capacitar a los usuarios para operar el sistema. Los distribuidores se
encargan de una parte de la capacitación, pero la supervisión de la capacitación es responsabilidad del
analista de sistemas. Además, el analista necesita planear una conversión sin problemas del sistema
antiguo al nuevo. Este proceso incluye convertir los archivos de los formatos anteriores a los nuevos, o
crear una base de datos, instalar equipo y llevar el nuevo sistema a producción.

Actividades del SDLC

Estas actividades aportan una serie de pasos a seguir con una finalidad de diseñar y desarrollar un
producto software de manera eficiente. El borrador del SDLC incluye los pasos que veremos a
continuación:

Comunicación
Este es el primer paso donde el usuario inicia la petición de un producto software. Contacta al proveedor
de servicios e intenta negociar las condiciones. Presenta su solicitud al proveedor de servicios aportando
la organización por escrito.

Recolección de solicitudes
A partir de este paso, el equipo de desarrollo software trabaja para ir adelante en el proyecto. El equipo
se reúne con varios depositarios de dominio del problema, e intentan conseguir la máxima cantidad de
información posible sobre lo que se requiere. Los requisitos se contemplan y se agrupan en requisitos
del usuario, requisitos funcionales y requisitos del sistema. La recolección de todos los requisitos se
lleva a cabo como se especifica a continuación :

Estudiando el software y el sistema actual ya sea bueno u obsoleto,

Entrevistar a los usuarios y a los desarrolladores de Software,

Consultando la base de datos o recoger las respuestas por medio de cuestionarios.

MODELO CLASICO O DE LINEA SECUENCIAL

Este modelo recibe muchos nombres como “ciclo de vida clásico”, “modelo en cascada” o de “línea secuencial”
ya que se trata de un modelo para desarrollo de software en que hay que seguir una serie de etapas ordenadas de
forma sistemática con el fin de generar un software.

Este modelo se enfoca típicamente en software empresariales, para algunos autores hacen referencia a aquel
software que desarrollara a la medida de la organización, pero esto no quiere decir que deben seguir las mismas
etapas o faces.

Las fases de este modelo son:

Definición de los requisitos: Los servicios, las restricciones y los objetivos se establece con los usuarios del
sistema. En que se busca hacer esta definición de manera detallada.
Diseño de software: en esta fase se hace una partición del sistema en sistemas de software o hardware. Ahí se
establece la arquitectura total del sistema. Se puede identificar y describir las abstracciones y relaciones de los
componentes del sistema.
Implementación y pruebas unitarias: la construcción de módulos y las unidades de software. En ello se realizan
pruebas de cada unidad.
Integración y pruebas del sistema: en ello se integran todas las unidades. Se hace las pruebas en conjunto. Se
entrega el conjunto probado al cliente.
Operación y mantenimiento: Es la fase más larga. El sistema es pone en marcha y se realiza la corrección de
errores que sea descubiertos. Se realizan mejoras de implementación y se identifican nuevos requisitos.
En cada fase se obtendrá el resultado por medio de documentos que deben ser aprobados por el usuario y
una fase no empieza hasta que se acabe la fase anterior, en ello se hace las correciones de problemas que
se encuentren en las fases previas.

Imagen 2 Modelo Clasico

Fuente: tomado del documento Desarrollo Software

http://www.fing.edu.uy/tecnoinf/maldonado/cursos/2015/rpyl/desarrolloSoftware.pdf

MODELO EN ESPIRAL
Este modelo es un enfoque muy diferente al modelo en cascada, ya que su enfoque va dirigido hacia el análisis de
los riesgos. En este modelo de ciclo de vida en espiral, consiste en realizar muchas iteraciones, pasando por cada
una de sus fases una y otra vez. A diferencia del modelo cascada que no tiene vuelta atrás, en el modelo en espiral
se pueden hacer iteraciones que sea necesarias y estas son sus fases principales:
1. Determinación de Objetivos: en ello se hará la especificación del alcance del producto que se
obtendrá al final de la iteración, se identificarán los riesgos y se determinarán posibles
alternativas de solución.

2. Análisis de riesgos: en esta fase se evaluara alternativas, se identifica y resuelve los riesgos.

3. Desarrollo y Pruebas: en esta fase, se debe comprender las actividades de análisis, diseño,
construcción e implantación de la versión del producto o software.

4. Planificación: en esta se realizara un estudio de la situación actual del sistema y del proyecto, en
que se determinara la necesidad o no de una nueva evolución y en el caso de que sea necesaria se
realiza la planificación de la misma.
Entre las principales ventajas de desarrollar un proyecto de software con el modelo espiral, es que los
riesgos se van disminuyendo a medida que avanzan los ciclos o iteraciones, de hecho no se puede
avanzar a un ciclo nuevo, si no se ha dado solución a todos los riesgos latentes. Lamentablemente el
modelo es realmente muy costoso y para que se pueda tener un alto nivel de eficacia en la evaluación
final del proyecto con este ciclo de vida, se necesita que el equipo tenga un gran nivel de conocimiento y
si es posible buena experiencia para superar cualquier riesgo al cual se puedan enfrentar.

Imagen 3 Modelo en Espiral

Fuente: tomado del documento Desarrollo Software,

http://www.fing.edu.uy/tecnoinf/maldonado/cursos/2015/rpyl/desarrolloSoftware.pdf

MODELO DE PROTOTIPOS
Es también conocido como modelo ITERACTIVO, en que se maneja a base de prototipos, es decir. Es
uno de los primeros ciclos de vida en que se permitía que el código fuente fuera reutilizado, sin embargo
con el modelo iterativo no solo se utiliza, sino que, en estos prototipos pueden llegar a ser el producto
final que siempre quieren, lo cual lo hace realmente relevante y destacable, por encima del resto de los
modelos que se pueda encontrar.

Básicamente, las fases del ciclo de vida del sistema, son las siguientes:

1. Inicialización
2. Iteración
3. Lista de Control

Una de las principales ventajas del modelo iterativo, es que la retroalimentación a los usuarios se
proporciona muy temprano, haciendo que al adentrar en el proyecto sea muy sencillo. El hecho de contar
con iteraciones nos da ciertas ventajas, pues con cada iteración realizada, se separa las partes complejas
de él, permitiendo más el acceso al software. Y por supuesto, un sistema creado por medio del ciclo de
vida iterativo, tiende a que no casi o pocas veces se falle, lo cual es garantía de satisfacción para el
cliente o para la empresa que necesiten implementar este método o modelo.

Imagen 4 Modelo de Prototipo

Fuente: tomado del documento Desarrollo Software,

https://www.fing.edu.uy/tecnoinf/maldonado/cursos/2015/rpyl/desarrolloSoftware.pdf

EL MODELO DRA
Es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. Este modelo es una
adaptación de "alta velocidad" del modelo de cascada. El proceso de DRA permite que un equipo de desarrollo
cree un sistema completamente funcional dentro de un periodo muy corto de 60 a 90 días.
El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de
software, desarrollado inicialmente por James Martin en 1980. Este método comprende en desarrollo iterativo, la
construcción de prototipos y el uso de utilidades de la herramienta CASE. De manera tradicional, el desarrollo
rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. Este metodo es
un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo
extremadamente corto.

DRA es una adaptación de “Alta velocidad" en el que logra que el desarrollo rápido utilizando un enfoque de
construcción basado en componentes. Si se logra comprender bien los requisitos y se limita el ámbito del
proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de
periodos cortos de tiempo.
La limitación de tiempo impuesto en un proyecto DRA demanda "ámbito en escalas". Si durante la aplicación de
gestión se puede modular de forma que permita completarse cada una de las funciones principales en menos de
tres meses. Cada una de las funciones se afronta por un equipo DRA diferente y será integrada en solo un
conjunto. Al igual que todos los modelos de proceso, el enfoque DRA tiene muchos inconvenientes como: Para
proyectos grandes aunque por escalas, el DRA requiere recursos humanos que sea suficientes para crear el
número correcto de equipos DRA. También, se debe requerir clientes y desarrolladores que estén comprometidos
en las actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso,
por ninguna de las partes constituyentes, los proyectos DRA fracasaran.

MODELOS EVOLUTIVOS
En este modelo los requerimientos del usuario pueden ser cambiante para el usuario. Ya que en la
práctica se demuestra que obtener todos los requerimientos al comienzo del proyecto es muy difícil; y no
solo por la dificultad para el usuario poder transmitir su idea, sino porque los requerimientos
evolucionan durante el desarrollo y así, surgen nuevos requerimientos que se debe cumplir.
El sistema es considerado como desarrollado, porque los usuarios lo usan, y proveen la
retroalimentación a los desarrolladores. Basado en esto, en la especificación de requerimientos se
actualiza, y hay una segunda versión del producto es desarrollado y será desplegado. En este proceso se
repite indefinidamente.

Imagen 5 Modelo Evolutivo

Fuente: tomado del documento, introducción de procesos, Universidad Politécnica de Valencia,

http://www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc

Existen dos tipos de desarrollo evolutivo:

 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos
hasta llegar al sistema final. El desarrollo comienza con las partes que se tiene más claras. El
sistema evolucionara conforme se añaden nuevas características propuestas por el usuario.
 Enfoque utilizando prototipos: El objetivo de este es entender los requisitos del usuario y
trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se
comienza por definir los requisitos que no sea claro por el usuario y en ello se utiliza un
 prototipo para experimentar con ellos. El prototipo permitirá ayudar a terminar de definir estos
requisitos.

EJERCICIOS/ACTIVIDADES

Consultar otros tipos de ciclos de vida de desarrollo de software que no se indican en esta guía.
Hacer un cuadro comparativo entre las metodologías de desarrollo SCRUM y las que utiliza Microsoft y Oracle.

BIBLIOGRAFIA

 Ciclo de vida de desarrollo de software. Recuperado de:

http://www.tutorialspoint.com/sp/software_engineering/software_development_life_cycle.htm
 Desarrollo en cascada. Recuperado de: https://es.wikipedia.org/wiki/Desarrollo_en_cascada
 Ciclo de vida del software. Recuperado de: https://okhosting.com/blog/el-ciclo-de-vida-del-software/
 Modelo DRA. Recuperado de: http://modelo-dra-ing-de-sistemas.blogspot.com/
 Ciclo de vida de desarrollo de software. Recuperado de:
http://148.202.105.18/webcucsur/sites/default/files/CICLO%20DE%20VIDA%20DEL%20SW%20JAIM
E.pdf
 material docente: diseño de sistema de información administrativo. Recuperado de:
https://www.u-cursos.cl/ingenieria/2007/2/IN55A/1/material_docente/bajar?id..
 https://www.fing.edu.uy/tecnoinf/maldonado/cursos/2015/rpyl/desarrolloSoftware.pdf
 Analisis y Diseño de sistemas, 8 Edicion, Kendall y Kendall.