D

rr
d
d

hbbb

1
Ciclo de vida del software

También conocido como (SDLC o Systems Development Life Cycle), es el proceso que se sigue para
construir y hacer evolucionar un determinado software. El ciclo de vida permite iniciar una serie de
fases mediante las cuales se procede a la validación y al desarrollo del software garantizando que se
cumplan los requisitos para la aplicación y verificación de los procedimientos de desarrollo; para ello,
se utilizan métodos del ciclo del software, que indican distintos pasos a seguir para el desarrollo de un
producto.
Si bien existen diferentes ciclos de desarrollo de software, la normativa ISO/IEC/IEEE
12207:2017 establece:
"Un marco común para los procesos del ciclo de vida de los programas informáticos, con una
terminología bien definida, a la que pueda remitirse la industria del software. Contiene procesos,
actividades y tareas aplicables durante la adquisición, el suministro, el desarrollo, el
funcionamiento, el mantenimiento o la eliminación de sistemas, productos y servicios
informáticos. Estos procesos del ciclo de vida se llevan a cabo mediante la participación de los
interesados, con el objetivo final de lograr la satisfacción del cliente (s.p.)".
A continuación, se indican cuáles son los elementos que integran un ciclo de vida:

Fases:
Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se
construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del
tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales
correspondientes a la asignación de recursos (humanos, financieros o materiales).

Entregables:
Son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales
(documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante
comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización
previamente establecido.
1.1 Fases

Las fases del modelo de ciclo del software son: planificación, análisis, diseño, implementación, pruebas
y mantenimiento, las cuales se describen en la siguiente figura.
FASE PLANIFICACIÓN:
En esta primera fase se realiza el planteamiento del problema, se definen alcances y objetivos del
software.

Objetivos: estudio de viabilidad, realizar planificación detallada.

1/5
FASE ANÁLISIS (definición de requisitos):
Esta fase busca definir los requisitos que son los que dirigirán el desarrollo del proyecto de software.

Objetivos: conocer los requisitos, asegurar que los requisitos son alcanzables, formalizar acuerdo con
el cliente.
2/5

FASE DISEÑO:
En esta fase se estudian posibles opciones de implementación para el software que hay que construir,
estructura general del mismo.

Objetivos: Identificar soluciones tecnológicas, asignar recursos materiales, proponer identificar y

seleccionar, establecer métodos de validación, ajustar especificaciones.
3/5
FASE PRUEBAS:
Esta fase busca detectar fallos cometidos en las etapas anteriores para corregirlos.

Objetivos: Realizar los ajustes necesarios para corregir posibles errores o inconsistencias.
4/5

FASE MANTENIMIENTO:
En esta fase se realizan tres puntos referenciados: mantenimiento correctivo, mantenimiento adaptativo
y mantenimiento perfectivo.

Objetivos: Operación asegurar que el uso del proyecto es el que se pretendía, mantenimiento.
5/5
1.2. Paradigmas de los modelos de ciclo de vida del software

Con la finalidad de proporcionar una metodología común entre el cliente y la empresa de software, se
utilizan los modelos de ciclos de vida o paradigmas de desarrollo de software para plasmar las etapas y
la documentación necesaria, de manera que cada fase se valide antes de continuar con la siguiente.
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el
desarrollo de software e intenta determinar el orden de las etapas involucradas y los criterios de
transición asociados entre estas.
Según la norma 1074 IEEE se define al ciclo de vida del software como:
Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el
mantenimiento del software
La ISO/IEC 12207 Information Technology / Software Life Cycle Processes señala que es:
Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el
desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema
desde la definición de los requisitos hasta la finalización de su uso (2008).
Existen modelos preestablecidos con los cuales se pude elaborar un proyecto; a continuación, se
mencionan los diferentes paradigmas de modelos de ciclo de vida para desarrollar software.

Paradigma tradicional
Los paradigmas tradicionales se identifican, fundamentalmente, por ser lineales, es decir se trata de
completar cada proceso de principio a fin hasta que quede listo para avanzar a la segunda fase del ciclo
del software.
Si bien es verdad que las metodologías actuales están basadas en lo que fueron los paradigmas
tradicionales, hoy en día se ha evolucionado, sin embargo, los paradigmas tradicionales se mantienen.

Desventaja:
Pérdida de tiempo si se encuentran errores en una fase avanzada porque al devolverse se debe pasar
nuevamente por todas las fases y reestructurar de acuerdo con las modificaciones.

Paradigma orientado a objetos:

Las etapas de desarrollo de software en el paradigma orientado a objetos, se conforma principalmente
por la creación de clases, análisis de requisitos y el diseño. Con este paradigma se pretende que el
código fuente sea reutilizable para otros proyectos.

Paradigma de desarrollo ágil

El objetivo de este paradigma es el desarrollo de proyectos en poco tiempo, se simplifican procesos
tediosos, se agilizan las fases del desarrollo y las interacciones se hacen en corto tiempo.
Una de las principales diferencias con los paradigmas anteriores es que el cliente se ve involucrado en
el proyecto durante el desarrollo de este, así, el cliente sugiere mejoras, propone ideas y se mantiene al
tanto del desarrollo del producto, a diferencia del paradigma tradicional y el orientado objeto donde el
cliente únicamente está al principio.
A continuación, se revisan los modelos del paradigma tradicional más utilizados.
Modelo en cascada

Uno de los primeros modelos de ciclo de vida del desarrollo fue establecido por W. Royce en 1970 y es
conocido como el “modelo de cascada” (waterfall model).
En su concepción básica, cada una de las actividades genera, como salidas, productos y modelos que
son utilizados como entradas para el proceso subsiguiente; esto supone que una actividad debe
terminarse (por lo menos, en algún grado) para empezar la siguiente.
Figura 1. Modelo de cascada del ciclo de vida del desarrollo.
Modelo espiral
Fue diseñado por Boehm en el año 1988 y se basa en una serie de ciclos repetitivos para ir ganando
madurez en el producto final. El espiral se repite las veces que sea necesario hasta que el cliente o el
usuario obtenga la satisfacción de sus necesidades.
En este modelo hay 4 actividades que envuelven a las etapas: planificación, análisis de riesgo,
implementación y evaluación. Una de sus principales ventajas es que los riesgos van disminuyendo
conforme avanzan los ciclos o interacciones.
 Modelo iterativo o por prototipos
Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar y analizar una
aplicación que represente el sistema que será implementado (McCracken y Jackson, 1982).
Objetivos
1. A
Son un medio eficaz para aclarar los requisitos de los usuarios e identificar las características de un
sistema que deben cambiarse o añadirse.
1. B
Mediante el prototipo se puede verificar la viabilidad del diseño de un sistema.
Las etapas del modelo son:
1. 1
Colecta y refinamiento de los requerimientos y proyecto rápido.
2. Análisis.
3. Especificación del prototipo.
4. 2
Diseño rápido.
5. 3
Construcción del prototipo.
6. 4
Evaluación del prototipo por el cliente.
7. 5
Refinamiento del prototipo.
8. Diseño técnico.
9. Programación y test.
[Link]ón y mantenimiento.
11.6
Producto de ingeniería.

Figura 3. Modelo iterativo o por prototipos.

Modelo Scrum

Este modelo se basa en el desarrollo incremental, es decir conforme pasen las fases y la iteración mayor
será el tamaño del proyecto que se está desarrollando.
Los procesos que utiliza son:
1. 1
 Product Backlog.
2. 2
Sprint Backlog.
3. 3
Sprint Planning Meeting.
1. 4
Daily Scrum.
2. 5
Sprint Review.
3. 6
Sprint Retrospective
El Scrum consiste en realizar un análisis de los requerimientos del sistema (Product Backlog), señalar
cuáles serán los objetivos a corto o mediano plazo dentro de un sprint, o sea, la fase de desarrollo.
Posteriormente, los desarrolladores harán lo suyo, se realizarán algunas pruebas y se retroalimentará de
acuerdo con lo conseguido al terminar la última fase.
Ventajas
• Gestión regular de las expectativas del usuario: los usuarios participan y proponen soluciones.
• Resultados anticipados: no es necesario esperar hasta el final para ver resultados.
• Flexibilidad y adaptación: se adapta a cualquier contexto, área o sector.
• Gestión sistemática de riesgos: los problemas son gestionados en el mismo momento de su aparición.

Figura 4. Modelo ágil Scrum.

Modelo Kanban
 David J. Anderson (reconocido como el líder de pensamiento de la adopción del Lean/Kanban para el
trabajo de conocimiento), formuló el método Kanban como una aproximación al proceso evolutivo e
incremental y al cambio de sistemas para las organizaciones de trabajo. El método está enfocado en
llevar a cabo las tareas pendientes y los principios más importantes pueden ser divididos en cuatro
principios básicos y seis prácticas.
El modelo Kanban es uno de los modelos más visuales de las metodologías ágiles; este consiste en la
creación de un tablero con etiquetas, donde se seccionan cada una de las fases de su desarrollo, además
se clasifican de acuerdo con los equipos de trabajo y se les asignan objetivos a corto, mediano y largo
plazo.
Mediante la metodología japonesa Kanban se:
1. 1
Define el flujo de trabajo.
2. 2
Establecen las fases del ciclo de producción.
1. 3
Stop Starting, start finishing.
2. 4
Tiene un control.
Kanban.
 Nota. Adaptada de Anderson.
Figura 5. Modelo ágil Kanb

Modelo XP o programación extrema

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software

formulado por Kent Beck, autor del primer libro sobre este tema: Extreme Programming Explained:
Embrace Change (1999). Esta metodología es adaptable según las necesidades y requerimientos a
implementar, además, el cliente se encuentra involucrado en el proceso de desarrollo lo que hace que el
producto pueda ser terminado en un menor tiempo.
Características principales de la programación extrema:
1. 1
Tipo de desarrollo iterativo e incremental.
2. 2
Pruebas unitarias.
3. 3
 Trabajo en Equipo.
4. 4
Trabajo junto al cliente.
1. 5
Corrección de errores.
2. 6
Reestructuración del código.
3. 7
El código es de todos.
4. 8
El código simple es la clave.
Programación Extrema (XP).

Nota. Adaptada de Muradas (2020).

Figura 6. Modelo XP
2
Fase de definición de requisitos

En esta primera fase del ciclo de vida del software, también llamada fase de análisis, se recopila, se
examina y se formulan los requisitos del cliente, así como la verificación de las posibles restricciones
que se puedan aplicar.
Por eso, la etapa de análisis en el ciclo de vida del software corresponde al proceso a través del cual se
intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los
requerimientos del sistema (las características que el sistema debe poseer).
La etapa de análisis es esencial debido a que sin esta no se sabe con precisión qué es lo que se necesita
y ningún proceso de desarrollo permitirá obtenerlo. El problema que se presenta es que al inicio del
desarrollo el cliente no sepa exactamente lo que necesita; por tanto, se debe averiguar con ayuda de
distintas técnicas.
De otra parte, la inestabilidad de los requerimientos de un sistema es inevitable, pues se estima que
25% de los requerimientos iniciales de un sistema cambian antes de que el sistema comience a
utilizarse. Por ello, muchas prácticas resultan efectivas para gestionar adecuadamente los
requerimientos de un sistema y, en cierto modo, controlar su evolución.
En la siguiente tabla, se describen las actividades y los artefactos que se realizan en la fase de
definición de requisitos.
Tabla 1/ Actividades y artefactos de la fase de definición de requisitos
Fase Actividades Artefactos

Definición del alcance del

proyecto.
Identificación del negocio. Modelo del negocio.
Análisis (definición de
requisitos). Toma de requerimientos. Análisis y realización de casos de uso.
Modelo de procesos y actividades de
Estudio de procesos de negocio.
negocio.
Calendarización del proyecto. Cronograma del proyecto.
3
Requisitos
Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o
conseguir un objetivo determinado (IEEE, 1990).
Los requisitos comunican las expectativas de los consumidores de productos software; de otra parte, los
requisitos pueden ser obvios o estar ocultos, conocidos o desconocidos, esperados o inesperados, desde
el punto de vista del cliente.
3.1 Importancia de los requisitos

Los requisitos cobran importancia dentro del ciclo de vida del software, puesto que:

Establecen el alcance del trabajo subsecuente, pueden definir estrategias de desarrollo, riesgos, tomar
decisiones de negocio (viabilidad de negocio), de proyecto (tiempo, recursos), de sistema
(arquitectura).

Indican al equipo del proyecto qué requieren los usuarios (necesidades de negocio).

El éxito o fracaso de un proyecto está altamente influenciado por la calidad de los requisitos y el
proceso para gestionarlos durante el desarrollo de un producto.

En la siguiente figura se pueden revisar las características que los requisitos deben cumplir de acuerdo
con Pfleeger (2002).
Necesario
Completo
Consistente
Correcto
Factible
Modificable
Priorizado
Verificable
Rastreable
Claro
Claro

Un requerimiento es conciso si es fácil de leer y entender, su redacción debe ser simple y clara para

quienes lo consulten en un futuro.

3.2 Clasificación

Los requerimientos se pueden definir de distintas maneras, la primera clasificación se encuentra

relacionada con el nivel de descripción con la que cuentan estos y dentro de este tipo de clasificación se
encuentran:
Requerimientos de usuario

Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema
proporcione y de las restricciones bajo las cuales debe funcionar.
Requerimientos de sistema
En la siguiente clasificación se observa la que se da a los requerimientos del sistema, la cual se
encuentra dividida con base en lo que se va a describir, las clasificaciones son:
Requerimientos funcionales

Requerimientos no funcionales
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo y estándares. Dentro de estos requerimientos se encuentra todo
lo referente a la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.

En la siguiente tabla se presentan algunos ejemplos sobre requisitos funcionales y no funcionales.

Tabla 2/ Requisitos.
Funcionales No funcionales
Se debe ingresar cédula, nombre y teléfono de cada Las consultas deben resolverse en menos de 3
cliente. segundos.
Se requiere un listado de clientes por zona. El lenguaje de programación debe ser Java.
Se puede ampliar el tema de requisitos funcionales y no funcionales en los videos que se proponen
dentro del material complementario.
Ingeniería de requisitos
 Las siguientes son definiciones de ingeniería de requisitos de algunos autores.
La ingeniería de requisitos es la disciplina para desarrollar una especificación completa,
consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes
involucradas y en dónde se describen las funciones que realizará el sistema.
- (Boehm, 1979).
La ingeniería de requisitos es el proceso de estudiar las necesidades del usuario para llegar a una
definición de requisitos de sistema, hardware o software.
- (IEEE, 1990).
La ingeniería de requisitos puede considerarse como un proceso de descubrimiento y
comunicación de las necesidades de clientes y usuarios y la gestión de los cambios de dichas
necesidades.
- (Amador, 2000)
El término IR “ingeniería de requisitos” ha surgido para englobar los procesos de desarrollo y gestión
de requisitos en el ciclo de vida del software, el primer término (ingeniería) se enfoca en las actividades
de obtención, análisis, especificación y validación de los requisitos que permitirá alcanzar los objetivos
del negocio y el segundo (requisitos) está centrado en la administración de los mismos y tiene como
propósito central la gestión de los cambios y la trazabilidad, de esta forma la IR proporciona el
mecanismo apropiado para:
• Entender lo que el cliente quiere.
• Analizar las necesidades.
• Evaluar la factibilidad.
• Negociar una solución razonable.
• Especificar la solución sin ambigüedades.
• Validar la especificación.
• Administrar los requisitos conforme éstos se transforman en un sistema operacional.
Etapas de la ingeniería de requisitos
Hay cuatro (4) etapas en un proceso usual de ingeniería de requisitos y que son utilizadas para el
desarrollo de un producto único, a saber: elicitación, análisis, especificación y validación de los
requisitos.
Elicitación
Actividad involucrada en el descubrimiento de los requisitos del sistema. Aquí los analistas deben
trabajar junto con el cliente para descubrir el problema que el sistema debe resolver, los diferentes
servicios que el sistema debe prestar y las restricciones que se pueden presentar.
Los principales objetivos que se deben alcanzar son los siguientes:
• Conocer el dominio del problema, de forma tal que los analistas puedan entenderse con los clientes y
usuarios y sean capaces de transmitir dicho conocimiento al resto del equipo.
• Descubrir necesidades reales entre clientes y usuarios, haciendo énfasis en aquellas que la mayor parte
de las veces se asumen y toman por implícitas.
• Consensuar los requisitos entre los propios clientes y usuarios hasta obtener una visión común de los
mismos.
Análisis Sobre la base de la obtención realizada previamente, comienza esta fase la cual tiene como
propósito descubrir problemas con los requisitos del sistema identificados hasta el momento, para ello
se basa en los siguientes objetivos:
• Detectar conflicto en los requisitos que suelen provenir de distintas fuentes y presentar contradicciones
o ambigüedades debido a su naturaleza informal.
• Profundizar en el conocimiento del dominio del problema puede facilitar el proceso de construir un
producto útil para clientes y usuarios (Durán, 2000).
En esta fase, el analista proporciona un sistema de retroalimentación que refina el entendimiento
conseguido en la etapa de obtención.

•
Especificación Especificación
Aquí se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle. En la
práctica, esta etapa se realiza conjuntamente con el análisis, por lo que se puede decir que la
especificación es el “pasar en limpio” el análisis realizado previamente aplicando técnicas y/o
estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un
 estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requisitos
basada en los casos de uso se utilizan cada vez más para la obtención de requisitos.

• Validación
Por último, la validación garantiza que los requisitos, una vez analizados y resueltos los posibles
conflictos, correspondan realmente a las necesidades de clientes y usuarios, para evitar que, a pesar de
que el producto final sea técnicamente correcto, no sea satisfactorio. La validación puede llevar al
analista a reescribir algunas especificaciones de requisitos y, en otros casos, a obtener nuevos, producto
de la aparición de necesidades que hasta entonces estaban ocultas, para volver a evaluar el análisis
inicial, o para corregir y perfeccionar el conjunto de requisitos documentados.
•
•
Para crear un mapa mental sobre Ingeniería de Requisitos en el Ciclo de Vida del Software (SDLC),
puedes estructurar la información en varios niveles, comenzando con los conceptos más generales y
desglosándolos en detalles específicos. Aquí te presento una estructura detallada que puedes seguir: