La ingeniería del software es una disciplina que se enfoca en la creación de software de alta calidad

mediante la aplicación de principios científicos y técnicas de ingeniería. El objetivo principal de la

ingeniería del software es desarrollar software de manera eficiente, con calidad, dentro del plazo y
presupuesto previstos, y que cumpla con los requisitos del cliente. Para lograr este objetivo, es necesario
seguir un proceso sistemático y controlado de desarrollo de software.

El producto

Características del producto de Software

 El software se desarrolla, no se fabrica en el sentido clásico (intangible).
 El software no se “rompe”.
 Aunque la industria tiende a ensamblar componentes (Api, librerías), la mayoría del software se
construye a medida.
 En la curva ideal entre índice de fallos y tiempo comienza con muchos fallos, luego se resuelven y
termina la vida del programa.
 En la curva real, el entorno cambia todo el tiempo (requisitos, sistemas operativos, hardware, etc), a
tal punto que hay más cambios que la capacidad de solucionarlos.

Los modelos de procesos de software describen la secuencia de actividades y tareas que se deben llevar a
cabo para desarrollar un software. Estos modelos proporcionan una guía para el equipo de desarrollo de
software sobre qué hacer en cada etapa del proceso de desarrollo.

Modelo en Cascada
Esta metodología es lineal y consta de algunas fases que hay que seguir y completar para poder avanzar a la
fase siguiente. El ciclo de vida de un programa realizado bajo la metodología en cascada, es extenso pero
muy bien estructurado. El detalle aquí es que no se puede saltarte fases ni volver a repetirlas. Por ejemplo: Si
se realiza un análisis de requerimientos, avanzamos a diseñar el programa y ya estamos en el desarrollo y de
momento el cliente nos dice que desea modificar los requerimientos, digamos que por tratarse del modelo en
cascada, no es posible volver atrás. Por lo tanto se tendría que reiniciar el proyecto o bien concluirlo y ver
como queda el software al final.

Modelo en el Espiral
El modelo espiral en ingeniería del software tiene un enfoque muy distinto al modelo de cascada,
principalmente porque su enfoque va dirigido hacia el análisis de riesgos. El modelo de ciclo de vida en
espiral, consiste en realizar diversas 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 las
iteraciones que se consideren necesarias. Entre las principales ventajas de desarrollar un proyecto con el
modelo espiral, es que los riesgos se van disminuyendo conforme 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 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 del equipo tenga un gran nivel de
conocimientos y si es posible buena experiencia para superar cualquier riesgo al que se puedan enfrentar.

Modelo Iterativo o por Prototipos

Es un modelo que se maneja a base de prototipos, es decir. Es uno de los primeros ciclos de vida que
permitían que el código fuente fuera reutilizable, sin embargo con el modelo iterativo no solo es utilizable, si
no que para muchos, estos prototipos pueden llegar a ser el producto final que siempre quisieron, lo cual lo
hace realmente relevante y destacable, por encima del resto de los modelos anteriores que se pueda
encontrar. Una de las principales ventajas del modelo iterativo, es que la retroalimentación a los usuarios se
proporciona desde muy temprano, haciendo que adentrarse en el proyecto sea demasiado sencillo. Por
supuesto que el hecho de contar con iteraciones nos da ciertas ventajas, pues con cada iteración realizada, se
van separando las partes complejas de el, permitiendo más el acceso al software. Y por supuesto, un sistema
creado mediante el ciclo de vida iterativo, tiende a no fallar casi, lo cual es garantía de satisfacción para el
cliente en este caso o para la empresa que está implementando esta metodología. Requiere de muchos
recursos.

Modelo Incremental o Evolutivo (modelo cascada + modelo por prototipos):

Este modelo de proceso de software divide el proyecto en incrementos o iteraciones más pequeñas. Cada
incremento involucra el análisis de requisitos, diseño, implementación y prueba de una parte funcional del
sistema. Cada incremento representa una versión funcional del software que se entrega al cliente o usuario
para su revisión y retroalimentación. Después de cada entrega, se recopilan comentarios, se identifican
mejoras y se ajustan los requisitos. Estos ajustes se incorporan en el próximo incremento, lo que permite una
adaptación más ágil a cambios y una mejora continua del producto. Cada incremento se mejora a través de
las iteraciones.
Las principales ventajas son la flexibilidad para adaptarse a cambios en los requisitos y la capacidad de
proporcionar un producto funcional al cliente más rápidamente.

Modelo de Desarrollo Ágil

Engloba varios enfoques ágiles como Scrum, XP (Extreme Programming), Kanban, etc. Prioriza la
adaptabilidad y la colaboración con el cliente.

Se centra en la entrega de software funcional en pequeñas iteraciones llamadas "sprints", en lugar de esperar
hasta que todo el proyecto esté completamente desarrollado. Se centran en la entrega rápida y continua de
software funcional, colaboración con los clientes, capacidad de responder rápidamente a los cambios,
retroalimentación y adaptación a cambios durante todo el proceso de desarrollo.

El Proceso Unificado de Desarrrollo

El Proceso Unificado de Desarrollo (PUD) no es un modelo de desarrollo en sí mismo, sino más bien es un
marco o metodología de desarrollo de software que puede incorporar elementos de varios modelos de
desarrollo, incluyendo los mencionados: Modelo de Desarrollo Ágil, Modelo Incremental o Evolutivo,
Modelo Iterativo o por Prototipos, Modelo en Espiral y Modelo en Cascada. (Marco o Metodología VS
Modelo: Un marco o metodología es un enfoque general y flexible que proporciona principios y guías para
abordar el desarrollo de software, mientras que un modelo es una representación más específica y detallada
que define la secuencia de actividades y tareas en el proceso de desarrollo)

“Conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software”.

 Está dirigido por Casos de Uso (se enfoca en las necesidades del usuario y en cómo el sistema
puede satisfacer esas necesidades).
 Está centrado en la Arquitectura (lo que ayuda a identificar los riesgos y las complejidades
técnicas temprano en el proceso).
  Es un proceso iterativo e incremental. Múltiples iteraciones de los 5 flujos por cada fase.

Dirigido por Casos de Uso

El modelado de casos de uso es una técnica utilizada para comprender, capturar y documentar los requisitos
del usuario. Describen las interacciones entre los actores y el sistema. Los CU representan una acción
concreta en infinitivo y son una forma de tomar requerimientos, dirigir el proceso e idear la
arquitectura. El enfoque dirigido por casos de uso de PUD se centra en definir los requisitos funcionales
del sistema para planificar las iteraciones del proyecto. Dado que un sistema ve la luz para brindar algo a sus
usuarios, tiene sentido guiar el desarrollo partiendo de los requerimientos de los mismos. Son los C.U.
quienes capturan estos requrimientos siendo un C.U. un fragmento funcional del sistema. Los Caso de Uso
dirigen el proceso e idean la arquitectura.

Centrado en la arquitectura

La arquitectura es una visión general del modelo del sistema que resalta las caracterisiticas clave sin dar
demasiada importancia en los detalles. Si los C.U. son la funcionalidad del sistema, entonces la arq. es la
forma del sistema. La arquitectura es una vista del diseño completo con las características más importantes
resaltadas, dejando los detalles de lado.

Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso deben encajar en la
arquitectura, y a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos,
actualmente y a futuro.

La arquitectura de software se refiere a la estructura del software y cómo las diferentes partes del software se
relacionan entre sí.

La arquitectura de software se define en la fase de elaboración del PUD y se utiliza como una guía para el
equipo de desarrollo durante la fase de construcción. La arquitectura de software también se utiliza para
fomentar la reutilización y hacer evolucionar al sistema.

El diseño de la arquitectura se ve afectada por:

 La funcionalidad
 Rendimiento
 Flexibilidad
 Reutilización
 Estética
 Compromisos Económicos

Iterativo e incremental

Es práctico dividir el trabajo en iteraciones, los cuales tienen como resultado un incremento. De esta forma
se reduce el riesgo y los costos (identificación temprana de problemas, retroalimentación constante, mejora
en la estimación de tiempos y costos …).

El proceso se divide en cuatro fases principales: inicio, elaboración, construcción y transición. Cada fase se
compone de múltiples iteraciones y cada fase debe completarse para avanzar a la siguiente fase.
 1. Inicio:
En la fase de inicio, se identifican los requisitos y se establece una visión general del proyecto. También se
identifican los objetivos del proyecto, los riesgos y las limitaciones. Se presenta el análisis de negocio. El
objetivo de esta fase es ayudar al equipo de proyecto a decidir cuales son los verdaderos objetivos del
proyecto, los riesgos y las limitaciones. La fase de inicio concluye con la aprobación de un documento
llamado Visión del Proyecto.

2. Elaboración:
La fase de elaboración se enfoca en la definición de la arquitectura del sistema y la identificación de los
requisitos. En esta fase, se elabora un plan detallado del proyecto y se crean prototipos del software. Al final
de la fase, se debe tener un documento de requisitos completado, una arquitectura definida y una lista de
tareas detallada. El resultado de esta fase es la línea base de la arquitectura.

3. Construcción:
Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta convertirse
en el sistema completo. Al final de esta fase, el producto contiene todos los casos de uso implementados, sin
embargo puede que no este libre de defectos.

La fase de construcción es la fase principal del proceso de desarrollo. En esta fase, se construye el software
y se realizan pruebas exhaustivas para garantizar la calidad. Durante la fase de construcción, el software se
divide en iteraciones, y cada iteración se enfoca en un conjunto específico de funcionalidades. Al final de
cada iteración, se realiza una revisión de la funcionalidad completada y se planifica la siguiente iteración.

4. Transición:
La fase de transición es la fase final del proceso de desarrollo. En esta fase, se realiza la transición del
software desde el equipo de desarrollo hasta el equipo de mantenimiento. Durante esta fase, se realiza una
prueba final y se entrega el software al cliente.

Entonces..

El Proceso Unificado de Desarrollo se dirige por casos de uso para identificar los requisitos del sistema, se
enfoca en la arquitectura para diseñar una estructura sólida y flexible, y utiliza un proceso iterativo e
incremental para mejorar la calidad del sistema a través de pruebas y validación continua.
Las 4 "P" del desarrollo de software
Elementos fundamentales que se deben considerar durante el proceso de desarrollo de software:

 Personas: importancia de tener un equipo de trabajo altamente capacitado y motivado para el éxito
del proyecto.

 Procesos: los procesos deben ser eficientes, efectivos y adaptables para asegurar la calidad del
software y la satisfacción del cliente.

 Productos: el software debe cumplir con los requisitos del cliente y ser de alta calidad. Debe ser
fácil de usar, seguro y escalable.

 Proyectos: Se refiere a la gestión del proyecto, esto implica la definición de objetivos claros, la
gestión adecuada del tiempo y recursos, y la identificación y gestión de riesgos y problemas.

FLUJOS:

1) Requisitos (Captura de Requisitos)

- Descripción del sistema correcto: Esto implica comprender completamente los requisitos del
cliente y documentarlos de manera precisa y detallada.

- Entendible por el usuario: Esto significa que los requisitos deben ser escritos en un lenguaje claro
y conciso, evitando términos técnicos complejos.

- Planificación y seguimiento: Al documentar claramente los requisitos, se puede establecer una

línea de tiempo para su implementación y seguimiento del progreso del proyecto. Además, una vez
que los requisitos han sido capturados, se pueden utilizar como base para la estimación de costos
y recursos necesarios para el desarrollo del sistema.
Hay diferentes puntos de partida para la captura de requisitos.

En algunos casos comenzamos haciendo un modelo del negocio (diagrama de casos de uso )o partimos
de uno ya desarrollado. El modelo de negocio describe cómo los actores interactúan con el sistema y los
procesos y flujos de trabajo que ocurren dentro del sistema. Ayuda a entender la lógica del negocio y a
definir los requisitos funcionales del sistema.

En otros casos si es un sistema acotado que no da soporte al negocio podemos partir de un modelo de
objetos sencillo como un modelo del dominio (diagrama de clases). Describe las clases que componen el
sistema, sus propiedades y métodos, y las relaciones entre ellas. Este modelo nos proporciona una visión
de donde está ubicado el sistema.

La principal diferencia entre el modelo de negocio y el modelo de dominio es que el modelo de negocio se
enfoca en cómo una empresa crea valor a través de sus actividades comerciales, mientras que el modelo
de dominio se enfoca en la representación de conceptos clave en un dominio específico.

En otros casos el cliente puede ya haber desarrollado una especificación completa de requisitos no
basada en objetos, de la cual podemos partir.

En forma típica, los pasos para la captura de requisitos son:

1. Enumerar requisitos candidatos: Implica la identificación de los posibles requisitos que el sistema
debe cumplir. Se pueden obtener a través de diversas fuentes, como la experiencia de los usuarios, el
análisis de sistemas similares, etc.

2. Comprender el contexto del sistema: Para expresar el contexto del sistema se utiliza el Modelo de
dominio o el modelo de negocio.

3. Capturar requisitos funcionales: Requisitos que describen lo que el sistema debe hacer (Modelo de
caso de uso).

4. Capturar requisitos no funcionales: Requisitos que describen cómo el sistema debe hacer lo que
debe hacer. Representan restricciones, condiciones o propiedades del sistema. Los que son más
genéricos se documentan por medio de una lista de requisitos adicionales.
Los requisitos funcionales se refieren a las funciones que debe realizar el sistema (“el usuario debe ser
capaz de iniciar sesión”), mientras que los requisitos no funcionales se refieren a cómo debe hacerlo (“el
tiempo de respuesta no debe ser mayor a 10 seg”).

Requisitos adicionales*: son requerimientos No funcionales que no pueden asociarse a ningún caso de
uso en particular.

Artefactos*: Son elementos tangibles que se generan durante el proceso de desarrollo de software. Estos
pueden incluir documentos, diagramas, modelos, código fuente y ejecutables. Los artefactos permiten a
los miembros del equipo comunicarse y colaborar de manera efectiva, además de documentar el progreso
y los resultados del proyecto.

Flujo de trabajo de Requerimientos

Hacer diagrama de casos de

uso (include, extend, herencia).

○ Precondiciones
○ Camino básico
○ Caminos
alternativos
○ Postcondiciones
○ No Funcionales

1) Encontrar actores y casos de uso

2) Priorizar los casos de uso
3) Detallar los caso de uso
4) Estructurar el modelo de caso de uso
5) Prototipar la interfaz de usuario
2) Análisis
Durante el análisis, analizamos los requisitos que se describieron en la captura de requisitos, refinándolos
y estructurándolos. El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y
una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero,
incluyendo su arquitectura.

Entonces el análisis es:

 Especificación más precisa de los requerimientos.

 Utiliza el lenguaje de los desarrolladores.
 Estructura los requerimientos (clases y paquetes estereotipados) de modo de facilitar su
comprensión, separación y modificación, y en general, su mantenimiento.
 Primera aproximación al diseño.

Flujo de trabajo de Análisis

1) Análisis de la arquitectura (Diag. de Paquete):

 Identificar paquetes del análisis (agrupaciones lógicas de elementos).
 Dependencias entre paquetes (como si hubieran distintos niveles, un paquete más general que
contiene varios un poco más específicos).
 Identificar clases de entidad obvias.
 Identificar requisitos especiales comunes.

2) Analizar casos de uso:

 Identificar clases de análisis o estereotipos:
o Clase de interfaz: interactua con el usuario. Pueden ser formularios, páginas, pantallas,
etc.
o Clase de control: coordinan, secuencian, realizan transacciones, implementan algún tipo
de lógica de negocio.
o Clase de entidad: se utilizan para representar las entidades del mundo real que se
manejan en el sistema. Son fijas, una vez que las estableces no cambian y permanecen
durrante todo el proceso. El profe dijo que son las que persistian como por ejemplo
Mensajes.
 Diagrama de colaboración.
 Descripción de la interacción entre objetos.
 Captura de requisitos especiales.

3) Analizar una clase:

Identificar:
 Responsabilidades
 Atributos
 Asociaciones y Agregaciones
 Generalizaciones
 Requisitos Especiales
4) Analizar un paquete:
 Que sea lo más independiente posible
 Que sea lo más cohesivo posible
3) Diseño

“Modelamos el sistema y encontramos su forma para que soporte todos los requisitos incluyendo los
no funcionales”.

Propósito
● Comprensión profunda de los requisitos no funcionales, restricciones de los lenguajes de
programación, componentes reutilizables, sistemas operativos, tecnologías de distribución y
concurrencia, etc.
● Crear un punto de partida para la implementación.
● Descomponer los trabajos de implementación en partes más manejables.
● Capturar las interfaces entre subsistemas antes del ciclo del software.
● Poder visualizar y reflexionar sobre el diseño.
● Crear una abstracción de la implementación.

Analisis vs Diseño
Diseño en el ciclo de vida

Flujo de Trabajo

1) Diseño de la Arquitectura

1 - Identificar los nodos y la configuración de la red (Diag. de Despliegue)

Los nodos representan las entidades de hardware o software en los que se ejecutarán los componentes del
sistema. Habitualmente se utiliza un patrón de 3 capas: clientes, funcionalidad de DB y lógica de negocio o
aplicación.

Configuración de red:
● Capacidad de hardware (qué nodos, cpu, memoria)
● Conexión y protocolo (velocidad, disponibilidad y calidad)
● Redundancia, modos de fallo, migración, mantenimiento de copia de seguridad, etc.

El diagrama de despliegue es una representación visual que muestra cómo se distribuyen los nodos y cómo
se comunican entre sí a través de la red.
2 - Identificar subsistemas y sus interfaces (Diag. de Subsistemas)
Los subsistemas son un medio para organizar el modelo de diseño en piezas manejables. El sistema se divide
en subsistemas para poder distribuirlos en los nodos.

● Capa específica de la aplicación (paquetes de análisis):

Es aquella que contiene la lógica de negocio y las funcionalidades específicas de la aplicación. Esta
capa se enfoca en implementar los requisitos y objetivos del sistema en sí. Ej: Gestión de comprador,
la interfaz de usuario, etc.

● Capa general de la aplicación (paquetes de análisis):

La capa general de la aplicación se refiere a los componentes y módulos que ofrecen funcionalidades
compartidas y reutilizables en todo el sistema. Ej: Gestión de planificación de pagos, gestión de
cuentas, servicio de autenticación, etc.

● Capa intermedia:
La capa intermedia, también conocida como capa de servicios o middleware, actúa como una interfaz
entre los diferentes componentes del sistema y se encarga de facilitar la comunicación y la
coordinación entre ellos. Ej: máquina virtual java, creo que python, etc.

● Capa de software del sistema (bajo nivel):

La capa de software del sistema se refiere a los componentes y módulos que son responsables de
brindar servicios y funcionalidades de bajo nivel necesarios para el funcionamiento del sistema en su
totalidad. Ej: TCP/IP, etc.

3 - Identificación de clases de diseño relevantes para la arquitectura.

● Clases que surgen a partir de las clases de análisis
Por ejemplo, si en el análisis se identificó una clase "Cliente", en el diseño se puede derivar una clase
de diseño llamada "ClienteDAO" ("Data Access Object") que se encargue de la persistencia de los
datos de los clientes.

● Clases activas: Las clases activas son aquellas que representan objetos o componentes del sistema
que tienen un comportamiento activo y pueden realizar acciones o ejecutar métodos. Estas clases son
responsables de llevar a cabo las operaciones y procesos del sistema. Por lo general, se asocian con
los elementos que ejecutan la lógica del negocio o implementan funcionalidades específicas.
4 - Identificar los mecanismos genéricos de diseño
Patrones o enfoques comunes que se utilizan en el diseño:
● Persistencia
● Distribución transparente (ocultar la complejidad de la infraestructura y permitir una experiencia de
usuario coherente y sin interrupciones)
● Características de Seguridad
● Recuperación de Errores
● Transacciones
● Etc.

2) Diseño de un CASO DE USO

1. Identificar las clases de diseño participantes.

2. Descripción de las interacciones entre objetos de diseño (Diaf. de Secuencia ¿?).
3. Identificar los subsistemas e interfaces participantes.
4. Descripción de interacciones entre subsistemas.
5. Captura de requisitos de implementación

3) Diseño de una CLASE (Diag. de Clases de Diseño)

1. Esbozar la clase de diseño

2. Identificar operadores, atributos, asociaciones, agregaciones
3. Descubrir métodos
4. Descubrir estados
5. Tratar requisitos especiales (ej: la factura debe ser accedida de distintos puntos)

4) Diseño de un Subsistema

1. Mantenimiento de las dependencias entre subsistemas

2. Mantenimiento de las interfaces proporcionadas por subsistemas
3. Mantenimiento de contenidos de los subsistemas.

El principal resultado del diseño es el modelo de diseño que se esfuerza en conservar la estructura del
sistema impuesta por el modelo de análisis, y que sirve como esquema para la implementación.

El diseño también obtiene como resultado el modelo de despliegue, que describe todas las configuraciones
de red sobre las cuáles debería implantarse el sistema.
4) Implementación
La implementación juega un papel importante en la fase de construcción del software.

Objetivos
● Implementar clases y subsistemas.
● Planificar integraciones en cada iteración.
● Asignar a nodos los componentes ejecutables.
● Probar componentes individualmente.

Flujo de trabajo

Implementación de la arquitectura

Identificar componentes arquitectónicos:

● Identificación de ejecutables
● Asignación a Nodos

se traduce el diseño de la arquitectura del software en código real

Integrar el sistema

● Planificación de una construcción:

○ Debe añadir funcionalidad implementando CU o escenarios.
○ No incluir demasiados componentes nuevos o refinados (uso de stubs).
○ Debe estar basada en una construcción anterior y expandirse hacia arriba y hacia los costados
en la jerarquía de subsistemas.
● Integración de una construcción.

Una vez que los componentes individuales del sistema se han implementado, es necesario
integrarlos para formar un sistema coherente y funcional.

Implementar un subsistema

En algunos casos, puede ser necesario implementar un subsistema específico antes de completar
todo el sistema
Implementar una clase

● Esbozar el componente que contendrá el código fuente.

● Generar el código fuente a partir de las clases de diseño.
● Implementación de las operaciones de la clase de diseño en forma de métodos.
● Comprobación de que el componente proporciona las mismas interfaces que la clase de diseño.

Realizar pruebas de unidad

● Pruebas de especificación (caja negra): verifica el comportamiento de la unidad observable

externamente.
● Pruebas de estructura (caja blanca): verifica la implementación interna de la unidad.

Durante la implementación, es crucial realizar pruebas de unidad para asegurarse de que cada
componente, subsistema o clase funciona correctamente de manera individual.
5) Pruebas

Objetivos
● Planificar las pruebas necesarias en cada iteración.
● Diseñar e implementar las pruebas creando los casos y procedimientos de prueba.
● Realizar las pruebas y manejar los resultados de cada una sistemáticamente.
Flujo de trabajo

Planificar pruebas

● Establecer una estrategia de pruebas.

● Estimar los requisitos para el esfuerzo de la prueba. Recursos humanos y sistemas necesarios.
● Planificar el esfuerzo de la prueba.

se identifican los requisitos de prueba y se elabora un plan de pruebas que incluye el alcance de
las pruebas, los recursos necesarios, el cronograma y los criterios de aceptación.

* es un documento formal que describe en detalle cómo se llevarán a cabo las actividades de
prueba en un proyecto de desarrollo de software

* criterios de aceptación: son condiciones específicas que un producto o proyecto debe cumplir
para que se considere satisfactorio y se acepte como completado.
Diseñar pruebas

Un Caso de Prueba es una especificación detallada de una funcionalidad o escenario particular que se va a
probar en el software.

● Diseñar Casos de Prueba:

○ Diseñar Casos de Prueba Integración: Las pruebas de integración se centran en verificar que
los diferentes componentes o módulos de un sistema interactúen correctamente entre sí.
Cuando un software se desarrolla, suele dividirse en módulos más pequeños para facilitar su
desarrollo y mantenimiento. Estos módulos deben integrarse para formar el sistema completo.
Las pruebas de integración se realizan para asegurar que las interfaces entre los módulos
funcionen adecuadamente y que los datos se transfieran de manera correcta entre ellos. Estas
pruebas se llevan a cabo después de que se hayan probado individualmente cada uno de los
módulos en pruebas unitarias.

○ Diseñar Casos de Prueba de Sistema: Se enfocan en verificar el sistema completo en su

totalidad, una vez que todos los módulos han sido integrados. Se centran en probar el
comportamiento del sistema en su conjunto y en diferentes situaciones

○ Diseñar Casos de Prueba de Regresión: Se utilizan para asegurarse de que los cambios no
hayan afectado de forma negativa la funcionalidad existente.

● Identificación y estructuración de los procedimientos de prueba. Los diseñadores de pruebas

analizan y sugieren los pasos específicos que deben seguirse para realizar las pruebas en cada caso
particular.

A un Caso de prueba hay que especificarle:

● Condiciones: Las condiciones necesarias para ejecutar correctamente el caso de prueba.
● Entrada: Los valores o datos que se deben proporcionar como entrada para ejecutar el caso de
prueba.
● Resultado Esperado

Implementar pruebas

Una vez diseñados los casos de prueba, se implementan en un entorno de pruebas. Esto implica
configurar el ambiente de prueba, preparar los datos necesarios y asegurarse de que las
herramientas de pruebas estén listas para su ejecución.

Realizar pruebas de integración

se ejecutan las pruebas de integración para verificar que los diferentes componentes del software
se comunicen y funcionen correctamente en conjunto

Realizar pruebas de sistema

se llevan a cabo pruebas más amplias para evaluar el sistema en su conjunto y verificar si cumple
con los requisitos y expectativas establecidos.
Evaluar pruebas

Una vez que se han completado las pruebas, se realiza una evaluación exhaustiva de los
resultados. Esto implica analizar los informes de pruebas, registrar y seguir los problemas
encontrados, priorizar y solucionar los errores, y evaluar si se ha cumplido con los criterios de
aceptación establecidos.
Gestión de configuración de software (GCS)
Se denomina GCS a los elementos que componen toda la información producida como parte del proceso
de ingeniería del software.

Definición de ChatGPT: Se refiere al proceso de identificación, control y seguimiento de los cambios

realizados en el software a lo largo del ciclo de vida del desarrollo del software, incluyendo la gestión de
versiones, la gestión de cambios y la gestión de la línea base.

La Gestión de Configuración es el arte de identificar, organizar y controlar las modificaciones que

sufre el software. La meta es maximizar la productividad minimizando los errores. La GCS es una
actividad de protección que este presente en todo el ciclo de vida del desarrollo de software.

Objetivos:
 Identificar productos/elementos que pueden cambiar (ECS).
 Organizar y controlar las modificaciones (controlador de versiones).
 Garantizar que el cambio se implementó de forma adecuada.
 Auditar los cambios e informar a todo el equipo en cada cambio.

Elementos de Configuración:
 Programas de computadora (tanto en forma de código fuente como ejecutable).
 Documentos que describen los programas de computadora (tanto técnicos como de usuario).
 Datos (contenidos en el programa o externos a él).

Los cambios son inevitables

Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el
deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.

Fuentes de cambio
 Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto
o en las normas comerciales.
 Nuevas necesidades del cliente que demandan la modificación de los datos producidos,
funcionalidades entregadas por productos o servicios entregados por un sistema.
 Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades
del proyecto.
 Restricciones presupuestarias o de planificación.

Línea base
Una especificación o producto que se ha revisado formalmente y sobre el que se ha llegado a un
acuerdo. A partir de ahí se realizan futuros desarrollos. Puede cambiarse solamente a través de
procedimientos formales de control de cambios.

UML*: es un lenguaje de modelado visual utilizado para representar sistemas de software. UML se utiliza
en el PUD para describir la estructura, el comportamiento y las interacciones entre los diferentes
componentes del sistema de software. UML se compone de diferentes tipos de diagramas, como
diagramas de casos de uso, diagramas de clases, diagramas de secuencia y diagramas de estado.
Métodos Ágiles
Los "Métodos Ágiles" no son una metodología, son una mentalidad y comportamiento guiados por valores
y principios establecidos en el Manifiesto Ágil y se centran en la flexibilidad, la adaptabilidad y la entrega
incremental de software. Ejemplos de métodos ágiles incluyen Scrum, Kanban, Extreme Programming
(XP), entre otros..

Valores

● A los individuos y su interacción, por encima de los procesos y las herramientas

● El software que funciona, por encima de la documentación exhaustiva

● La colaboración con el cliente, por encima de la negociación contractual

● La respuesta al cambio, por encima del seguimiento de un plan

Scrum

Scrum es una metodología ágil de gestión de proyectos que se utiliza comúnmente en el desarrollo de
software y en otros campos donde se requiere un enfoque iterativo e incremental

Se utiliza para gestionar y organizar equipos de desarrollo y se basa en roles, eventos, artefactos y reglas
claras. Scrum se enfoca en la entrega continua de funcionalidades.

Una historia de usuario es una técnica utilizada para expresar los requisitos funcionales desde la
perspectiva del usuario final o del cliente. Se trata de una descripción concisa y fácil de entender de una
característica o funcionalidad que el equipo de desarrollo debe implementar en un producto o sistema de
software. Cada historia de usuario representa un pequeño incremento de valor que el equipo se
compromete a desarrollar durante un sprint, que es un período de tiempo fijo y corto (generalmente de una
a cuatro semanas). Como [tipo de usuario], quiero [acción/demanda], para [objetivo/beneficio].

El ingrediente vital de Scrum es la comunicación. Con el modelo scrum se debe estar comunicado con el
equipo de trabajo en todo momento, para estar al tanto de los sucesos.

Los roles en Scrum incluyen:

 Scrum Team: compuesto por Scrum Master, Product Owner y Equipo de Desarrollo. No hay
subequipos ni jerarquías. Todo el equipo es responsable de crear un incremento valioso y útil en
cada Sprint.
 Product Owner: es la persona responsable del product backlog y priorizar las historias de usuario
en función de la necesidad del cliente y del valor que aportan al producto. Es el responsable de
maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo.
 Equipo de desarrollo: es el grupo de personas encargado de desarrollar el software y cumplir con
los requisitos del cliente. El equipo de desarrollo es multifuncional y autoorganizado.
 Scrum Master: Es el encargado de asegurarse de que el equipo de desarrollo siga los principios y
prácticas de Scrum. El Scrum Master ayuda a resolver obstáculos y mejora continuamente el
proceso de Scrum.
Los eventos en Scrum incluyen:

Sprint (de dos a cuatro semanas): Ceremonia de SCRUM. Contiene a los demás eventos. Es un
ciclo de trabajo de 2 a 4 semanas, cuyo resultado es un incremento. Este posee un objetivo que
durante el sprint no debe ser modificado.

1. Spring Planning: se realiza al comienzo de cada sprint para establecer los objetivos y entregables
del sprint. Durante este evento, el equipo de Scrum trabaja con el dueño del producto para revisar y
refinar el backlog del producto, y luego selecciona un conjunto de elementos del backlog que
pueden ser completados durante el sprint.El resultado del sprint planning es el sprint backlog.
Sprint backlog: El sprint backlog es una lista de elementos seleccionados del backlog del producto
y se divide en tareas que se asignan a los miembros del equipo.
2. Daily Scrum: Reunión diaria para sincronizar el progreso y discutir cualquier problema que haya
surgido.
3. Sprint review: al final del sprint, el equipo de desarrollo muestra el software funcionando al
propietario del producto y otros interesados, para recibir comentarios.
4. Retrospectiva del sprint: al final de cada sprint, el equipo de desarrollo se centra en áreas a
mejorar.

* Product Backlog: Es una lista de requerimientos ordenados según la importancia en base al criterio del
Product Owner. Contiene el objetivo del producto. Se encuentre presente durante todo el ciclo de vida del
sistema. Siempre se está actualizando.
Gráfico BurnDown (gráfico de trabajo pendiente)
Es una herramienta utilizada en Scrum para visualizar el progreso del equipo en la entrega del producto.
Este gráfico muestra la cantidad de trabajo restante en un eje vertical y el tiempo transcurrido en un eje
horizontal. El gráfico BurnDown permite al equipo identificar posibles retrasos y ajustar el plan de trabajo
para cumplir con los objetivos del proyecto.

1. Gráfico de Burndown Ideal: Este gráfico representa la

línea de progreso teórica si el equipo avanzara de manera
constante y completa todas las tareas previstas en el sprint.
Ayuda a visualizar el ritmo necesario para lograr completar
todas las tareas planificadas.
2. Gráfico de Burndown Actual: Este gráfico muestra el
progreso real del equipo a medida que el sprint avanza. Si el
equipo está avanzando más rápido de lo previsto, la línea
del gráfico puede ser más empinada que la línea ideal. Si el
equipo está retrasado, la línea del gráfico puede ser más
plana o incluso subir si se están agregando nuevas tareas.

Kamba
Consiste en la creación de un tablero con etiquetas, donde se seccionan cada una de las fases de su
desarrollo, además se clasifica de acuerdo a los equipos de trabajo y se les asignan objetivos a corto,
mediano y largo plazo. Destaca el hecho de no tener un orden tal cual, de hecho todas las fases
comienzan a trabajar a la par, no hay tiempos de espera y básicamente su objetivo es que los
desarrolladores y programadores están trabajando todo el tiempo.

Planning Poker
Su propósito es estimar el esfuerzo y duración de las tareas en cada Sprint. El objetivo del planning poker
es obtener una medida de tamaño relativo de todas las historias respecto a sí mismas. En un primer
momento, el modelo inicial consta de 8 cartas donde cada participante consta de un juego de cartas. De
forma individual cada participante estima el esfuerzo que puede demorar una tarea, luego todos muestran
su carta boca arriba y se suma el esfuerzo estima
Calidad
¿Qué es?
Es la conformidad de las expectativas del consumidor/cliente.

Lo que se podría considerar calidad en el diseño de software:

● ¿Lo mejor?¿Se reconoce apenas se ve?
● ¿Lo bien hecho?
● ¿Lo más caro?
● ¿Lo último en tecnología?
● ¿Lo más usado?

Calidad de software (lo que debe respetar?)

● Concordancia con los requerimientos. “que cumpla” con los requerimientos. Es lo que el cliente
“espera” del software.
● Cumplimiento de los requerimientos implícitos. son requerimientos que no se dicen, pero que se
esperan de todas formas. Por ejemplo, que el sistema no debe demorar más de 1 minuto en cargar las
diferentes vistas.
● Seguir los estándares especificados. seguir aquello que se acordó.

Evolución

1. Primero surgió el Control de calidad, que se centra en el producto e intenta reducir la variabilidad.
2. Luego vino el Aseguramiento de la calidad, que se centra en el proceso. Algunas herramientas para
mejorar la calidad son la ISO 9001 (mejora la gestión de la calidad) y la CMMI (mejora los
procesos)
3. Por último el concepto de calidad total, el cual hace referencia a mejorar la cultura en todos los
ámbitos de la organización.

Aseguramiento de la calidad (SQA)

“La SQA es un conjunto de actividades sistemáticas y planificadas para proporcionar confianza al

producto o servicio, y que de este modo satisfaga los requisitos de calidad....”

Sus actividades principales son:

● Descripción del proceso de desarrollo.

● Revisión de las actividades de ingeniería de software.
● Asegurar que todas las desviaciones al proceso se documenten.
● Obtener el feedback para la mejora continua.
Revisiones del software

“El trabajo debe ser revisado por el mismo motivo que los lápices necesitan gomas, errar es humano.”
El objetivo principal de estas revisiones es encontrar errores o fallos y documentarlos, no solucionarlos.

La revisión del software es una actividad que nos da garantía sobre la calidad del mismo. El objetivo es:

encontrar Errores durante el proceso antes de que estos se conviertan en fallos/defectos para el cliente.

● Tener en cuenta:
○ Revisar el producto y no a la persona (no en juzgar al desarrollador).
○ Fijar agenda y mantenerla.
○ Limitar el debate (registrar el problema y listo, no debatir para solucionarlo).
○ No intentar solucionar los problemas (la solución se hace en otra etapa posterior).
○ Registrar los resultados de la revisión (para poder planear acciones).

Costos de la calidad y de la no calidad

Tener calidad:

● Costos de prevención:
○ Planificación SQA
○ Revisiones técnicas.
○ Capacitación.
○ RRHH.
● Costos de evaluación:
○ Inspecciones del proceso.
○ Pruebas
○ Auditorias
● Costos de solución de los errores encontrados.

No tener calidad

● Resolución de fallos.
● Resolución de quejas.
● Devoluciones
● Soporte en línea (asistencia para brindar soluciones a los usuarios)
● Costos de imágen (pérdida de reputación o imagen de la empresa)
Métricas
¿Qué es?
“Un indicador que proporciona una visión profunda que permite al gestor de proyectos o a los ingenieros de
software ajustar el producto, el proyecto o el proceso para que las cosas salgan mejor”

Medida: Proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o

tamaño de algunos atributos de un proceso o producto.

Medición: Acto de tomar las medidas sobre el proceso o producto.

Las mediciones se realizan durante todo el ciclo de vida. Ej: cantidad de líneas en un método.

¿Para qué?
● Indicar la calidad de un producto.
● Evaluar la productividad de la gente.
● Establecer línea base para la estimación.
● Justificar herramientas o formación adicional.

Tipos de medidas

Directas

Fácil de determinar la unidad de medición.

● Costos (plata?)
● Esfuerzo (tiempo?)
● Cantidad de líneas de código

Indirectas

Se mide de forma indirecta ya que no tiene una unidad de medición como tal.
● Usabilidad
● Mantenibilidad
● Curva de aprendizaje
● Escalabilidad

Actividades

Formulación

Se establecen el objetivo, la pregunta y la métrica. Por ejemplo, el objetivo podría ser mejorar la calidad
del código, la pregunta podría ser "¿Cuál es el nivel de complejidad del código?" y la métrica podría ser
"Número de líneas de código por método".

Recolección de datos: Realizar la acción de medir.

Análisis de los datos: Cálculo de las métricas utilizando los datos recolectados.
Interpretación

Una vez que se han calculado las métricas, es importante interpretar/evaluar los resultados obtenidos. La
interpretación puede involucrar comparar los resultados con umbrales predefinidos, realizar análisis de
tendencias o identificar patrones relevantes.

Retroalimentación

Implica tomar acciones basadas en los resultados e interpretaciones obtenidas. Si las métricas revelan áreas
problemáticas o oportunidades de mejora, se deben tomar medidas adecuadas.

Clasificación

Métricas de Productividad

Se centran en medir la eficiencia, rendimiento y la capacidad de producción de un equipo de desarrollo de

software.

Métricas de Calidad

Estas métricas se utilizan para identificar defectos, errores y problemas en el software, y para evaluar la
satisfacción del usuario final.

Métricas Técnicas

Las métricas técnicas se centran en evaluar aspectos técnicos del software, como su diseño, estructura y
mantenibilidad. Estas métricas se utilizan para medir y evaluar la calidad interna del software y su capacidad
para ser modificado y mantenido a largo plazo.

Las métricas deberían…

● Ser simples y fáciles de usar.
● Ser consistente y objetiva.
● No utilizar combinaciones extrañas de unidades (evitar confusiones al interpretar resultados).
● Independiente de la tecnología usada.
● Eficaz para la retroalimentación de calidad.

Patrones de diseño
Los patrones de diseño son soluciones a problemas que ocurren con frecuencia en el diseño de software. Son
como planos prefabricados que se pueden personalizar para resolver un problema de diseño recurrente
en el código. Nos ayudan a solucionar problemas comunes hablando un lenguaje habitual entre los
desarrolladores.

Los patrones según su proposito se clasifican en:

- Los patrones creacionales proporcionan mecanismos de creación de objetos que incrementan la

flexibilidad y la reutilización de código existente.

- Los patrones estructurales tratan la manera en que los objetos se conectan con otros objetos, para
asegurar que los cambios del sistema no requieren cambiar esas conexiones.
- Los patrones de comportamiento se encargan de una comunicación efectiva y la asignación
de responsabilidades entre objetos.