UF2406: El ciclo de vidad del desarrollo de
aplicaciones.
CONCEPTO DESCRIPCIÓN
Software Instrucciones que cuando se ejecutan desempeñan una determinada
función, pero software no es sólo un programa que funciona, que es lo
más importante, sino también la estructura de datos sobre la que opera y
la documentación resultado del proceso de desarrollo y la que describe
cómo se tiene que utilizar el programa.
Crisis del El proceso de desarrollo del software en sus inicios se planteó como un
software trabajo “artesanal” donde cada desarrollador se ponía a programar sin una
planificación previa ni unas mínimas normas.
La crisis del software se refiere a los problemas significativos que
surgieron en el desarrollo de software durante las décadas de 1960 y
1970. Este término describe las dificultades que enfrentaban los proyectos
de software, como:
• Sobrecostos: Los proyectos excedían los presupuestos iniciales.
• Retrasos: Las entregas se realizaban mucho más tarde de lo
planeado.
• Baja calidad: El software no cumplía con las expectativas de los
usuarios.
• Dificultad de mantenimiento: Los sistemas eran complejos y
difíciles de actualizar.
• Falta de metodologías: No existían procesos estandarizados para
gestionar proyectos grandes.
La crisis llevó a la creación de la ingeniería de software como una
disciplina formal para abordar estos desafíos y mejorar la planificación,
diseño y desarrollo de sistemas complejos.
Ingeniería del La ingeniería del software es una disciplina que aplica principios,
software métodos y técnicas de ingeniería para el diseño, desarrollo,
mantenimiento y gestión de software.
Su objetivo principal es regular de alguna manera el desarrollo del
software, es decir establecer de manera clara las tareas que hay que
realizar para crear aplicaciones informáticas que sean confiables,
eficientes y adaptables, utilizando un enfoque sistemático y
cuantificable.
1
Esta disciplina incluye varias etapas, como el análisis de requisitos,
diseño del sistema, desarrollo, pruebas, implementación y
mantenimiento. Además, se basa en el concepto de ciclo de vida del
software, que abarca desde la concepción del proyecto hasta su
mantenimiento y actualización.
Fases del Análisis de requisitos (o especificación): Se identifican las necesidades
desarrollo del del cliente y los objetivos del software.
software
Diseño: Se crea la arquitectura del sistema, definiendo cómo funcionará y
cómo se verá.
Programación (implementación): Se escribe el código y se desarrolla el
software basado en el diseño.
Pruebas: Se verifica que el software funcione correctamente y cumpla con
los requisitos.
Despliegue (implantación): El software se pone en funcionamiento para
los usuarios finales.
Mantenimiento: Se realizan actualizaciones, correcciones y mejoras
según sea necesario.
Modelos del • Modelo en cascada o ciclo de vida clásico.
proceso de • Modelo de proceso incremental.
ingeniería • Modelo de proceso evolutivo.
• Modelo de proceso especializado.
• Modelo de desarrollo ágil.
Modelo en Es el primer ciclo de vida que surgió. Enfoque secuencial para el desarrollo
cascada del software. Poco flexible ante cambios inesperados. Uso recomendable
(waterfall) o en proyectos pequeños o con requisitos estables
ciclo de vida Cada fase del proyecto debe completarse antes de pasar a la
clásico siguiente, sin posibilidad de retroceder..
Para evitar que se propaguen los errores se establece un proceso de
revisión al completar una fase, antes de comenzar a la siguiente.
Descripción: Proceso lineal y secuencial donde cada fase debe
completarse antes de pasar a la siguiente.
2
Ventajas: Estructura clara, ideal para proyectos con requisitos bien
definidos.
Desventajas: Poco flexible frente a cambios; difícil retroceder si surgen
errores.
Uso recomendado: Proyectos pequeños o con requisitos estables.
Modelo de Descripción: El software se desarrolla en incrementos o versiones,
proceso añadiendo funcionalidad en cada iteración. En la versión en cascada el
incremental producto no se entrega al cliente hasta que esté completamente
terminado, en el modelo incremental se van haciendo distintos
entregables funcionales que se van mejorando en cada una de las
versiones siguientes. En cada una de las versiones se trabaja con el
modelo en cascada-
Ventajas: Permite entregar partes funcionales rápidamente; más flexible
que el modelo en cascada.
Desventajas: Puede ser difícil gestionar múltiples incrementos.
Uso recomendado: Proyectos donde se pueden priorizar funcionalidades.
Modelo Descripción: Desarrollo iterativo que permite crear prototipos y refinar el
evolutivo software con base en retroalimentación.
Ventajas: Ideal para proyectos con requisitos poco claros; mejora
continua.
Desventajas: Puede ser costoso y difícil de gestionar.
Uso recomendado: Proyectos innovadores o con alta incertidumbre.
Modelo Descripción: Diseñado para necesidades específicas, como el modelo
especializado orientado a objetos o basado en componentes.
Ventajas: Adaptado a contextos particulares; puede optimizar recursos.
Desventajas: Requiere experiencia y herramientas específicas.
Uso recomendado: Proyectos con requisitos únicos o complejos.
Modelo de Las metodologías ágiles son enfoques de gestión de proyectos que se
desarrollo ágil centran en la flexibilidad, la colaboración, la mejora continua y la
entrega de valor en ciclos cortos. Tanto Scrum como Kanban son dos de
las metodologías ágiles más populares, aunque tienen enfoques distintos.
Scrum: es un marco de trabajo (framework) que proporciona una
estructura para gestionar proyectos complejos. Se basa en ciclos de
trabajo cortos y fijos llamados sprints (generalmente de 2 a 4 semanas)
durante el cual un equipo de desarrollo trabaja para completar un
conjunto de tareas o funcionalidades del software. Es comúnmente
utilizado en el desarrollo de software.
Kanban: Ayuda a identificar cuellos de botella. Trabaja con paneles
visuales que se utilizan para gestionar el flujo de trabajo continuo en
proyectos. Estos paneles ayudan a organizar las tareas y mejorar la
eficiencia al proporcionar una representación clara de las etapas en
3
proceso. Cada panel Kanban se divide en columnas que representan
diferentes estados del trabajo, como “Por hacer”, “En progreso” y
“Completado”
Requisitos Son las necesidades y las expectativas del cliente final sobre el software
que se va a construir. Definen lo que es software debe hacer y cómo debe
comportarse.
Básicamente se dividen en dos categorías principales:
los requisitos son las descripciones formales de las necesidades y
expectativas que deben cumplir el software o el sistema que se va a
construir
Requisitos funcionales: Describen las funciones específicas que el
software debe realizar.
Ejemplo: "El sistema debe permitir a los usuarios registrarse y acceder con
un nombre de usuario y contraseña."
Requisitos no funcionales: Detallan las características de calidad del
sistema, como rendimiento, seguridad, usabilidad, etc.
Ejemplo: "El sistema debe responder a las solicitudes en menos de 2
segundos."
Esta etapa es crucial porque establece la base para el diseño, desarrollo y
pruebas del software. Una mala definición de requisitos puede llevar a
problemas en fases posteriores del proyecto.
Metodología La metodología establece las tareas concretas que hay que llevar a cabo,
cómo se debe realizar cada tarea, con qué herramientas…
Una metodología puede seguir uno o varios modelos del ciclo de vida.
El ciclo de vida es el modelo general que se sigue para el desarrollo del
software, indica qué es lo que hay que obtener a lo largo del desarrollo del
proyecto, pero no cómo. El cómo lo establece la metodología.
4
Ciclo de vida → indica qué queremos obtener al desarrollar el proyecto
Metodología → cómo lo vamos a obtener: tareas, herramientas.
Enfoques Los enfoques metodológicos en programación son estrategias o marcos
metodológicos que guían el desarrollo de software para hacerlo más eficiente, organizado
y efectivo.
• Enfoque estructurado
• Enfoque orientado a objetos.
Enfoque Se basa en dividir el problema en partes más pequeñas y resolverlas de
estructurado manera secuencial. Se usan diagramas de flujo, pseudocódigo y
estructuras como bucles y condicionales.
Ejemplo: programación en lenguaje C o Pascal.
Enfoque La programación orientada a objetos es un paradigma de programación
orientado a que define cómo diseñar y escribir código. Considera que una aplicación
objetos informática está constituida por diferentes objetos que interactúan
entre sí. Organiza el software en "objetos" que representan entidades
del mundo real. Se usan clases, herencia, encapsulación y polimorfismo.
Ejemplo: Lenguajes como Java, Python o C++.
UML Lenguaje de Modelado Unificado.
Es utilizado para representar, diseñar y documentar los componentes de
un sistema, especialmente en proyectos orientados a objetos. UML incluye
diagramas como casos de uso, clases, secuencia estándar visual para
modelar sistemas de software, actividades, entre otros, que ayudan a
visualizar y entender cómo funciona un sistema.
Herramientas Las herramientas CASE (Computer-Aided Software Engineering) son
CASE aplicaciones diseñadas para apoyar el desarrollo de software en
diferentes etapas, como análisis, diseño, implementación y pruebas.
Estas herramientas automatizan tareas repetitivas y mejoran la
productividad del equipo.
Las herramientas CASE suelen incluir soporte para UML, ya que este es un
lenguaje ampliamente utilizado para modelar sistemas.
Draw.io, aunque no es una herramienta CASE en sí misma, si es una
opción gratuita que ofrece apoyo en el desarrollo del software, ya que
permite crear diagramas como casos de uso, clases, secuencia, etc. Esto
es importante en la etapa de diseño del software, aunque no automatiza
procesos como lo harían las herramientas CASE completas.
Pruebas La tarea de pruebas es una de las tareas principales del proceso del
software y tiene como objetivo fundamental la deteccción de defectos
que se han cometido inadvertidamente durante el proceso de
construcción del software.
5
El objetivo de esta tarea es la detección de defectos y no la
demostración de que el software no tiene defectos.
Un caso de prueba consiste básicamente en indicar qué datos de entrada
vamos a suministrar al programa, qué datos de salida se deben obtener y
para qué desemos llevar a cabo este caso de prueba, por ejemplo, para
determinar que se cumple un determinado requisito.
Puntos de vista El objetivo de las pruebas puede percibirse desde dos puntos de vista:
de las pruebas:
validación y Validación: las pruebas deben comprobar que el producto es el que
verificación quiere el cliente. Se conocen también como pruebas de aceptación de
usuario.
Verificación: las pruebas deben comprobar que el producto está
construido correctamente, es decir, que lo que hace lo hace bien.
Estrategia de Las pruebas siempre comienzan probando pequeñas porciones de
aplicación de software y se va incrementando de manera progresiva el alcance de la
las pruebas prueba. Al software se le pasará secuencialmente los siguientes tipos de
pruebas:
• Pruebas de unidad
• Pruebas de integración
• Pruebas de sistema
• Prueba de validación
Pruebas de Se comienza probando módulos individuales de software. En el caso de
unidad programación orientada o objetos, se probarán cada una de las clases por
separado. Para ello será necesario probar, para cada uno de los métodos
no triviales de la clase, que su comportamiento es el adecuado.
Prueba de Se hacen para comprobar que todas las clases de las que consta el
integración software funcionan correctamente cuando cooperan entre ellas para
realizar las tareas encomendadas por el software.
Prueba del Es el proceso de prueba de un sistema integrado de hardware y software
sistema para comprobar si cumple con los requisitos especificados (tanto los
(system testing) funcionales como los no funcionales). Se realiza para evaluar el sistema
completo, integrado y funcionando como un todo asegurando que todas
las partes del sistema trabajen juntas de manera correcta.
.
Se centra en las entradas y salidas del sistema, sin examinar el código
interno (pruebas de caja negra).
Prueba de El objetivo de la prueba de validación, también llamada prueba de
validación aceptación es determinar si el software es considerado válido por parte
6
del usuario y si este está preparado para su implantación en el entorno del
usuario.
La consideración de validez del software se debe basar en una serie de
criterios de validación o aceptación previamente establecidos, que deben
formar parte de la especificación de requisitos del software.
En este tipo de pruebas participa activamente el usuario, el cuál debe
ejecutar las pruebas ayudado por el equipo de pruebas. Este tipo de
pruebas es la fase final del proceso software mediante la cual el usuario
da su aceptación para que el software pase a sus uso o explotación.
Pruebas de caja El objetivo es crear casos de prueba que permitan revisar todos los
negra requisitos funcionales de un programa. Existen diferentes técnicas de
diseño de casos de prueba de caja negra:
• Particiones o clases de equivalencia: en esta técnica se deben
identificar una serie de clases de equivalencia o tipos de valores
que se deben asignar a los datos de entrada del programa.
• Análisis de los valores límites: es complementaria a las clases de
equivalencia. La diferencia es que en lugar de elegir cualquier valor
que esté dentro de la clase de equivalencia se elige el que está
justo en los límites de la clase y los casos de prueba se generan
teniendo en cuenta no sólo los valores de entrada sino también los
de salida.
• Conjetura de errores: se elabora una lista con los errores comunes
que suelen comenter los desarrolladores y los casos de prueba se
generan teniendo en cuenta esa lista.
Pruebas de caja El objetivo es crear casos de prueba que permitan revisar detalles
blanca internos del software.
Se utiliza una técnica que recibe el nombre de prueba de trayectoria o de
ruta básica. Esta técnica permite generar una métrica llamada
complejidad ciclomática de McCabe, que es un número entero que
indica el número de caminos independientes que hay en el código, y, en
consecuencia, el número mínimo de casos de prueba que hay que
ejecutar para garantizar que se recorren todas las sentencias del código al
menos una vez.
Se debe representar el código que se va a probar en un grafo de flujo.
La complejidad ciclomática se representa con V(G)
Un nodo predicado (NP) es el que tiene una bifurcación.
Una región es una zona cerrada del grafo, se debe incluir también la región
externa.
Fórmulas para calcular la complejidad ciclomática:
• V(G) = nº de regiones del grafo.
• V(G) = A – N + 2 (aristas – nodos + 2)
• V(G) = NP + 1 (nodos predicado + 1)
Si la complejidad ciclomática es mayor de 10 la probabilidad de defectos
en el módulo o en el programa crece bastante si dicho valor no se debe a
7
sentencias case-of o similares. En caso de un V(G) elevado es
recomendable dividir el módulo complejo en varios módulos para reducir
la complejidad del software.
Error, defecto Error es una equivocación humana que ocurre durante el desarrollo del
(bug) y fallo software, el defecto, también llamado bug, es la manifestación de ese
error en el código, es una imperfección o anomalía en el software y la fallo
es la revelación del defecto al utilizar el sistema en tiempo de ejecución.
Error (humano) → Defecto (en el software) → Fallo (comportamiento
incorrecto observable).
Muchas veces se utiliza bug (coloquial) para referirse a cualquier
problema, error o defecto que causa un comportamiento inesperaado o
incorrecto.
Ejemplo:
Error: un programador escribe mal una condición lógica incorrecta en el
código.
Defecto: una función devuelve un resultado incorrecto debido a una
fórmula mal implementada.
Fallo: el sistema se bloquea al intentar realizar una operación específica.
Proceso de Se puede decir que la depuración es el resultado de un caso de prueba
depuración exitoso porque el objetivo de las pruebas debe ser encontrar defectos en el
software y tras la detección de un defecto se debe acometer esta tarea.
Generación de La documentación de las pruebas es conveniente para una buena
informes de las organización de estas y para asegurar su reutilización.
pruebas
Se deben documentar tanto el diseño de las pruebas como el resultado o
ejecución de las mismas.
