METODOLOGÍA DE LOS SISTEMAS

U1 – SISTEMAS DE INFORMACIÓN
Sistema de información: Conjunto de componentes (software)
interrelacionados que reúnen, procesan, almacenan y distribuyen datos
e información y proporcionan un mecanismo de retroalimentación para
cumplir un objetivo.

Dato: Hecho aislado, representa cosas del mundo real.

Información: Conjunto de datos organizados de tal manera que poseen

un valor adicional más allá del valor que tienen los hechos individuales.

Conocimiento: Comprensión de un conjunto de información y las formas

en que se puede convertir en algo útil para tomar una decisión; poseer
conocimiento es comprender las relaciones entre la información.

Se podría afirmar que vivimos en una economía basada en la

información; por lo tanto, integrar la información de diferentes fuentes
genera un potencial importante en las organizaciones.

Se pueden establecer reglas y relaciones para organizar los datos en

información útil y valiosa; en ese sentido, el tipo de información que se
genera depende de las relaciones definidas entre los datos.

El valor de la información está relacionado directamente con la forma en

que ayuda a tomar decisiones y alcanzar las metas de la organización.
La información valiosa ayuda a realizar tareas de manera eficiente y
eficaz.

Trabajadores del conocimiento: personas que crean, usan y distribuyen

conocimiento.

Administración del conocimiento: estrategia mediante la cual una

organización reúne, organiza, almacena, analiza y comparte su
conocimiento y experiencia colectiva.
Características de la información de calidad:

-​ Accesible: Los usuarios deben poder acceder de manera fácil, en

el momento correcto y el tiempo preciso.
-​ Exacta: Debe estar libre de errores.
-​ Completa: Contiene todos los hechos relevantes.
-​ Económica: El costo de producción debe ser barato. Debe
equilibrarse el valor de la información con el costo de producción.
-​ Flexible: Debe poder utilizarse para una gran variedad de
propósitos.
-​ Relevante: Debe ser importante para las personas que toman las
decisiones.
-​ Confiable: Los usuarios pueden depender de la información.
-​ Segura: Se debe proteger el acceso a usuarios no autorizados.
-​ Simple: Debe establecerse en términos simples; no es necesario
que sea sofisticada y detallada.
-​ Oportuna: Debe proporcionarse en el momento que se necesita.
-​ Verificable: Debe poder comprobarse para asegurarse de que es
correcta.
 U1 – INGENIERÍA DE SOFTWARE (CAP 1)
La ingeniería de software es una estructura que incluye un proceso, un
conjunto de métodos y herramientas.

La ingeniería del software es la aplicación de un enfoque sistemático,

disciplinado y cuantificable al desarrollo, operación y mantenimiento, y
también el estudio de los enfoques según lo anterior.

El software puede ser un producto o un vehículo para la entrega del

mismo. En tanto producto, es un transformador de información simple o
compleja; como vehículo, es una base para el control de la
computadora, comunicación o creación y control de otros programas.

El software es:

-​ Instrucciones (programas) que, al ejecutarse, proporcionan las

características, función y desempeño buscados.
-​ Estructuras de datos que permiten el funcionamiento correcto de
los programas.
-​ Información descriptiva que describe la operación y uso de los
programas.

Características del software (al ser un elemento de un sistema

lógico):
Se desarrolla o modifica con intelecto, no se manufactura:

Refleja que la alta calidad del software se logra a través de un buen

diseño; son distintos enfoques en la construcción de un producto. No
puede administrarse un proyecto de software como uno de manufactura.

No se “desgasta”:

Durante su vida, el software sufre cambios que pueden introducir

errores no intencionados. Esto hace que la curva de tasas de falla tenga
incrementos súbitos; es una curva idealizada que simplifica los modelos
reales de las fallas del software. A diferencia del diseño de hardware,
donde hay refacciones al desgastarse un componente, en el software no
existe eso, y los cambios implican una complejidad mayor.

​
La mayor parte del software se construye para un uso individualizado:

Al evolucionar una disciplina de ingeniería, se crean componentes

estandarizados para el diseño. Un componente de software debe
diseñarse e implementarse de modo que pueda volverse a usar en
muchos programas diferentes.

Siete grandes categorías de software de computadora:

1.​ Software de sistemas: sirve para dar servicio a otros programas,
tiene gran interacción con el hardware.
2.​ Software de aplicación: programas aislados que resuelven una
necesidad específica de negocios. Procesan datos comerciales o
técnicos y facilitan la operación de negocios.
3.​ Software de ingeniería y ciencias: se caracteriza por ser
algoritmos “devoradores de números”.
4.​ Software incrustado: existe dentro de un producto y se usa para
implementar características para el usuario final; son funciones
limitadas y particulares.
5.​ Software de línea de productos: proporciona capacidades para
diferentes consumidores, se centra en un mercado limitado y
particular o en mercados masivos.
6.​ Aplicaciones web: se centran en redes y agrupan una amplia
gama de aplicaciones; se conectan con bases de datos
corporativas y aplicaciones de negocios.
7.​ Software de inteligencia artificial: hace uso de algoritmos no
numéricos.
Desafíos para el desarrollo de software:
-​ Computación en un mundo abierto: El reto será desarrollar
software que permita a múltiples dispositivos diferentes (móviles,
PC, sistemas empresariales) comunicarse a través de redes
enormes.
-​ Construcción de redes: La red global se construye en un motor de
computación y en un proveedor de contenido; el desafío será
hacer arquitecturas sencillas.
-​ Fuente abierta: Con la tendencia a la distribución de código
fuente, el desafío será elaborar código fuente autodescriptivo y
desarrollar técnicas que permitan saber cuáles cambios se
hicieron y cómo se manifiestan en el software.

Software heredado: Son desarrollados hace décadas y tienen muchas

modificaciones; es costoso mantenerlo, pero riesgoso hacerlo
evolucionar.

Se caracteriza por su longevidad e importancia crítica para el negocio.

La respuesta razonable es no hacer nada, ya que si no necesita
repararse, no hace falta cambiarlo.

Puede ocurrir que el sistema evolucione porque:

-​ Debe adaptarse a las necesidades de nuevos ambientes de

cómputo y tecnología.
-​ Debe ser mejorado para implementar nuevos requerimientos del
negocio.
-​ Debe ampliarse para que sea operable con otros sistemas o
bases de datos modernas.
-​ Debe rediseñarse para hacerla viable en un ambiente de redes.

Los sistemas y aplicaciones basados en web “involucran una mezcla

entre las publicaciones impresas y el desarrollo de software, entre las
comunicaciones internas y relaciones externas”.

La mayoría de las webapps presentan los siguientes atributos:

-​ Uso intensivo de redes (residen en la red y atienden las

necesidades de múltiples clientes).
-​ Concurrencia (pueden acceder muchos usuarios al mismo
tiempo).
-​ Carga impredecible (cambia el número de usuarios que acceden).
 -​ Rendimiento (si el usuario debe esperar demasiado, suele irse).
-​ Disponibilidad (se suele demandar acceso 24/7).
-​ Orientadas a los datos (suele presentar al usuario información
proveniente de bases de datos).
-​ Contenido sensible (la calidad y estética del contenido son un
rasgo importante).
-​ Evolución continua.
-​ Inmediatez (pueden tener plazos de días o semanas para salir al
mercado).
-​ Seguridad (deben tener medidas estrictas de seguridad).
-​ Estética (el atractivo de la web app es su apariencia y percepción).​

Realidades sencillas de la ingeniería del software:

-​ El software está incrustado en casi todos los aspectos de nuestras
vidas; debe hacerse un esfuerzo concreto para entender los
problemas antes de desarrollar una aplicación propiamente dicha.
-​ Los requerimientos de la tecnología de la información que
demandan los individuos se hacen más complejos con el paso del
tiempo; por eso, el diseño es una actividad crucial.
-​ Los individuos y negocios dependen cada vez más del software
para la toma de decisiones y las operaciones cotidianas; por eso,
el software debe tener alta calidad.

Al aumentar la base de usuarios y el tiempo de uso, crecen la demanda

para crecimiento; por eso, el software debe tener facilidad para recibir
mantenimiento.

La ingeniería de software es una tecnología con varias capas, pero el

fundamento en el que se apoya es el compromiso con la calidad, donde
el proceso es el aglutinante que permite el desarrollo.

Los métodos proporcionan la experiencia técnica para elaborar software

y se basan en un conjunto de principios fundamentales.

Proceso: Conjunto de actividades, acciones y tareas que se ejecutan

cuando se crea algún producto del trabajo.

Actividad: Busca lograr un objetivo amplio y se desarrolla sin importar el

dominio, tamaño o complejidad.

Acción: Conjunto de tareas que producen un producto importante.

Tarea: Se centra en un objetivo pequeño pero bien definido que produce
un resultado tangible.

En la ingeniería del software, el proceso es un enfoque adaptable que

permite que el equipo de software busque y elija el conjunto apropiado
de acciones y tareas para el trabajo.

La estructura del proceso establece el fundamento para el proceso

completo mediante la identificación de un número pequeño de
actividades estructurales que sean aplicables a todos los proyectos de
software; además, incluye un conjunto de actividades sombrilla
aplicables a través de todo el proceso.​

Capas de la Ingeniería del software:​

Compromiso con la calidad:​

Es importante tener en cuenta que en la Ingeniería del Software todo el
proceso se ve impulsado por el objetivo de lograr calidad.

Capa de Proceso:​
Implica definir un conjunto estructurado de actividades, modelos y
prácticas para el desarrollo de software.

Capa de Métodos:​
Los métodos incluyen análisis de requisitos, diseño, implementación,
pruebas y mantenimiento.

Capa de Herramientas:​
Incluye IDEs, compiladores, depuradores y Frameworks de pruebas
automatizadas. Automatizan y agilizan el proceso de desarrollo.
Una estructura de proceso general consta de cinco actividades:
1.​ Comunicación: Entender los objetivos de los participantes y reunir
los requerimientos para definir características y funciones del
software.
2.​ Planeación: Crear un “mapa” que guía al equipo llamado plan de
proyecto, que describe tareas técnicas, riesgos probables,
recursos requeridos y programa las actividades.
3.​ Modelado: Se crea un bosquejo para entender el panorama
general en un esfuerzo por comprender mejor el problema y cómo
llegar a resolverlo.
4.​ Construcción: Combina la generación de código con las pruebas
para descubrir errores.
5.​ Despliegue: Se entrega al consumidor, que evalúa y da
retroalimentación.

Estas actividades se ejecutan cada cierto número de repeticiones del

proyecto, donde cada iteración produce un incremento del software; con
cada incremento, el software se hace más complejo.

Actividades sombrilla:
-​ Seguimiento y control del proyecto de software: Permite que se
evalúe el progreso comparándolo con el plan del proyecto.
-​ Administración del riesgo: Evalúa los riesgos que puedan afectar
el resultado o calidad del proyecto.
-​ Aseguramiento de la calidad del software: Define y ejecuta las
actividades requeridas para garantizar la calidad.
-​ Revisiones técnicas: Evalúa para descubrir y eliminar errores
antes de propagarlos a la siguiente actividad.
-​ Medición: Define y reúne mediciones para ayudar al equipo a
entregar el software.
-​ Administración de la configuración del software: Administra los
efectos del cambio en el proceso.
-​ Administración de la reutilización: Define criterios para volver a
usar el producto del trabajo.
-​ Preparación y producción del trabajo: Agrupa actividades para
crear productos del trabajo
La esencia de la práctica de la ingeniería del software:
Entender el problema:

Dedicar tiempo y responder: ¿quiénes son los participantes? ¿Qué

datos, funciones y características son necesarias para resolverlo?
¿Podemos fraccionar en problemas más pequeños? ¿Podemos crear
un modelo de análisis?

Plantear la solución:

Podemos hacer un pequeño diseño y responder si hay algún software

que implemente lo requerido. ¿Se pueden reutilizar los elementos de
otra solución?

Ejecutar el plan:

El diseño sirve como un mapa que nos guía. ¿El código fuente puede
apegarse al diseño? ¿Hay pruebas respecto a la corrección del
algoritmo?

Examinar la exactitud del resultado:

Luego de diseñar pruebas para descubrir los posibles errores,

¿podemos probar cada parte de la solución? ¿Se validó el software con
los requerimientos de los participantes?
Siete principios que se centran en la práctica de la ingeniería del
software:
1.​ La razón de que exista todo: Dar valor a los usuarios es esa
razón. Al desarrollar, debemos preguntarnos si agrega valor real al
sistema.
2.​ MSE (Mantenerlo Sencillo y Estúpido): Todo diseño debe ser tan
simple como sea posible; facilita conseguir un sistema más fácil
de entender.
3.​ Mantener la visión: Es esencial una visión clara; por eso, es
importante tener un arquitecto que mantenga la visión y obligue al
cumplimiento.
4.​ Otros consumirán lo que producimos: Alguien más usará,
mantendrá y documentará el sistema. Siempre debemos
establecer especificaciones, diseñar e implementar con la
seguridad de que alguien tendrá que entender lo que hacemos.
5.​ Abrirse al futuro: Para tener éxito, debemos hacer sistemas fáciles
de adaptar a los cambios; no debemos diseñar sobre algo
iniciado.
6.​ Planear por anticipado la reutilización: La reutilización ahorra
tiempo y esfuerzo; es uno de los mayores beneficios de usar
tecnología orientada a objetos. La planificación anticipada para
búsqueda de reutilización disminuye el costo e incrementa el valor
de los componentes.
7.​ ¡Piense!: Pensar con claridad produce mejores resultados.
Debemos aprender a reconocer cuándo no sabemos algo para
investigar una respuesta.

​
​
 U1 – INGENIERÍA DE REQUERIMIENTOS
Requerimientos: descripciones de lo que el sistema debe hacer ya sean
servicios que ofrece o restricciones en su operación. Reflejan las
necesidades de los clientes.

Ingeniería de Requerimientos: proceso de descubrir, analizar,

documentar y verificar dichos servicios y restricciones, es decir
requerimientos.

Podemos separar los requerimientos en:

-​ Requerimientos de usuario: enunciados acerca de los servicios y

restricciones que esperan los usuarios del sistema.
-​ Requerimientos del sistema: descripciones mas detalladas de las
funciones, servicios y restricciones operacionales del sistema de
software.

Es necesario escribirlos con diferentes niveles de detalle ya que

diferentes lectores los usan e interpretan de diversas formas.

También podemos clasificar los requerimientos en:

-​ Requerimientos funcionales: enunciados acerca de servicios que

el sistema debe proveer, como reacciona ante entradas
particulares y cómo debería comportarse el sistema.
-​ Requerimientos no-funcionales: limitaciones sobre servicios o
funciones que ofrece el sistema, se suelen aplicar al sistema como
un todo más que a determinadas características.

Suele ocurrir que al generarse un nuevo requerimiento aunque sea

no-funcional, este último puede generar requerimientos funcionales. Es
decir, los requerimientos no son independientes y pueden generar o
restringir otros requerimientos.

Requerimientos funcionales:
Refieren a lo que el sistema debe hacer, dependen del tipo de software
que se desarrollé, los usuarios y el enfoque de la organización.

Son variados, pueden ir desde lo más general hasta cosas muy

específicas.

En general definen las actividades específicas que debe proporcionar el

sistema.
La especificación debe ser completa y consistente, deben definirse
todos los servicios requeridos (totalidad) y deben evitarse las
definiciones contradictorias (consistencia).

Requerimientos no-funcionales:
No se relacionan directamente con los servicios específicos y pueden
relacionarse con propiedades emergentes del sistema o también definir
restricciones sobre el sistema.

Especifican o restringen características del sistema como un todo.

Afectan más a la arquitectura global de un sistema que a los

componentes individuales.

Pueden generar requerimientos funcionales relacionados que también

definen nuevos servicios del sistema.

Surgen a través de necesidades del usuario, debido a restricciones

organizacionales, necesidades etc.

Podemos dividirlos en:

-​ Requerimientos del producto: Especifican o restringen el

comportamiento del software.
-​ Requerimientos de la organización: Requerimientos amplios, que
vienen de políticas y procedimientos en la organización del cliente
y desarrollador.
-​ Requerimientos externos: Derivados de factores externos al
sistema y desarrollo, establecen lo que debe hacer el sistema para
ser aprobado por un regulador (ej. Afip)
Documento de requerimientos de software: Comunicado oficial de lo que
deben implementar los desarrolladores del sistema.

Debe ser un compromiso entre la comunicación de requerimientos a los

clientes, con definición de los requerimientos e inclusión de información
sobre la posible evolución del sistema.

La información que se incluya en un documento de requerimientos

depende del tipo de software que se va a desarrollar y del enfoque que
se use.

Para documentos extensos tenemos que incluir una tabla de contenido

global y un índice del documento.

Especificación de Requerimientos:
Es el proceso de escribir en un documento de requerimientos, los
requerimientos del usuario y del sistema.

Deben escribirse los requerimientos en lenguaje natural, con tablas y

formas o diagramas.

Suele pasar que se incluya información del diseño del sistema, por
diversas razones:

-​ Quizás se tiene que diseñar una arquitectura inicial del sistema

para ayudar a estructurar la especificación de requerimientos.
-​ Deben interoperar con los sistemas existentes lo cual restringe el
diseño e impone requerimientos del nuevo sistema.
-​ Quizás es necesario usar una arquitectura específica para cubrir
los requerimientos no funcionales.

Especificación en lenguaje natural: Expresivo, intuitivo y universal pero

su significado depende del lector.

Es la forma más utilizada para especificar requerimientos de sistema y

software.
Se recomienda seguir estos lineamientos:

-​ Crear un formato estándar y asegurarse que las definiciones sigan

dicho formato.
-​ Utilice el lenguaje de manera clara para distinguir entre
requerimientos obligatorios y deseables.
-​ Usar texto resaltado para seleccionar partes claves del
requerimientos
-​ Debe evitarse el uso de jerga, abreviaturas y acrónimos
-​ Asociar una razón con cada requerimiento de usuario. Debe
explicar por qué se incluye el requerimiento.

Especificaciones estructuradas: El lenguaje natural estructurado es una

manera de escribir requerimientos del sistema, se limita la libertad del
escritor en una forma estándar.

Se debe incluir la siguiente información al usar una forma estándar:

-​ Descripción de la función o entidad a especificar

-​ Descripción de entradas y procedencias
-​ Descripción de salidas y a dónde se dirigen
-​ Información de los datos requeridos para el sistemas
-​ Descripción de la acción a tomar
-​ Precondición y postcondición específicas antes y después de
llamar a la función
-​ Descripción de los efectos colaterales de la operación

Procesos de ingeniería de requerimientos: Incluyen cuatro actividades

de alto nivel.

1.​ Estudio de factibilidad.

2.​ Adquisición y análisis.
3.​ Especificación
4.​ Validación

La ingeniería de requerimientos es un proceso iterativo donde las

actividades están entrelazadas.

Estudios de factibilidad: un breve estudio enfocado que debe realizarse

en el proceso de IR.
Adquisición y análisis de requerimientos:
Se trabaja con el cliente y usuarios finales para describir el dominio de
aplicación, los servicios que proporciona el sistema, desempeño
requerido, etc.

Proceso de adquisición y análisis:

1. Descubrimiento de requerimientos: Interactuar con los

participantes del sistema para descubrir sus requerimientos.

2. Clasificación y organización de requerimientos: Agrupa

requerimientos relacionados y organiza en grupos coherentes.

3. Priorización y negociación de requerimientos: Se priorizan los

requerimientos, se encuentran y resuelven conflictos de
requerimientos mediante la negociación.

4. Especificación de requerimientos: Se documentan e ingresan a la

siguiente ronda de la espiral, pueden producirse documentos
formales o informales.

Razones por las que la adquisición y comprensión de los

requerimientos por parte de los participantes del sistema es un
proceso difícil:

1.​ Los participantes no saben lo que quieren excepto en términos

muy generales
2.​ Expresan naturalmente los requerimientos con sus conocimientos
técnicos de su trabajo.
3.​ Los diferentes participantes tienen distintos requerimientos y
pueden expresarse de distintas formas.
4.​ Las políticas de la organización o empresa pueden solicitar
requerimientos específicos del sistema, ya que aumentan la
influencia en la organización.
5.​ El ambiente económico y empresarial es dinámico, lo que lleva a
cambios en importancia de requerimientos o nuevos
requerimientos en sí.​
Descubrimiento de requerimientos:
Proceso de recopilar información sobre el sistema requerido y los
sistemas existentes. También consiste en separar los requerimientos del
usuario con los del sistema.

Los requerimientos tienen diversas fuentes como:

-​ Documentación
-​ Participantes del sistema (Desde administradores hasta usuarios
finales)
-​ Reguladores
-​ Dominio de aplicación
-​ Otros sistemas que interactúan con el sistema a especificar.​

Entrevistas: Son una parte de la mayoría de los procesos de ingeniería

de requerimientos. Se formulan preguntas a los participantes sobre el
sistema utilizado actualmente, además de lo que se va a desarrollar.

Tienen dos tipos:

1.​ Cerradas donde los participantes responden a un conjunto de

preguntas pre-establecidas
2.​ Abiertas donde no hay una agenda predefinida.

No son tan útiles para comprender requerimientos desde el dominio de

la aplicación por dos razones:

1.​ Los especialistas usan terminología y jerga específicas de un

dominio que los ingenieros de requerimiento quizás no dominen.
2.​ Cierto conocimiento del dominio es tan familiar que se vuelve
difícil explicarlo o no vale la pena mencionarlo debido a lo
fundamental que resulta.​

Los entrevistadores efectivos deben:

1.​ Tener mentalidad abierta para evitar ideas preconcebidas sobre

los requerimientos.
2.​ Instar al entrevistado a hablar con una pregunta de trampolín,
además de dar una propuesta de requerimientos o trabajar juntos
en un prototipo.
Escenarios: Son útiles para detallar un bosquejo de descripción de
requerimientos, son ejemplos sobre descripciones de sesiones de
interacción. Se usan para formular los verdaderos requerimientos del
sistema.

Comienza con un bosquejo de la interacción, se suman detalles para

crear una representación completa de la interacción.

Implica trabajar con los participantes para identificar escenarios y captar

detalles a incluir en dichos escenarios.

Casos de uso: Técnica de descubrimiento de requerimientos que

identifica a los actores implicados en una interacción y nombra el tipo de
interacción, además de complementar con información adicional.

Se documentan con el empleo de un diagrama de caso de uso de alto

nivel, el conjunto de casos de uso representa todas las interacciones
posibles a describir en los requerimientos del sistema.

No es tan efectivo para adquirir requerimientos empresariales o no

funcionales, ni de dominio.

Etnografía: Es una técnica de observación que se usa para entender los

procesos operacionales y ayudar a derivar requerimientos de apoyo
para dichos procesos.

Se toman notas sobre las tareas existentes mediante la observación.

Ayuda a descubrir requerimientos que reflejan las formas en las que

trabaja la gente.

Puede revelar detalles críticos de procesos de los usuarios finales que

se pierden en otras técnicas de adquisición.
Es muy efectiva para descubrir requerimientos que:

1.​ Se derivan de la forma en que realmente trabaja la gente, en vez

de la forma en la cual las definiciones del proceso indican que se
debe trabajar.
2.​ Se derivan de la cooperación y el conocimiento de las actividades
de otras personas

Validación de Requerimientos:
Proceso de verificar que los requerimientos definen realmente el
sistema que quiere el cliente.

Se interesa por encontrar problemas con los requerimientos, es

importante porque los errores pueden conducir a grandes costos por
re-ingeniería.

Los cambios a los requerimientos implican un cambio en el diseño e

implementación del sistema.

Diferentes tipos de comprobaciones sobre los requerimientos:

-​ De validez: Un usuario cree que necesita un sistema para ciertas

funciones, pero con mayor análisis encontramos las funciones
adicionales o diferentes que efectivamente se requieren.
-​ De consistencia: No deben estar en conflicto entre sí, no debe
haber restricciones contradictorias.
-​ De totalidad: Debe incluir requerimientos que definan todas las
funciones y restricciones contradictorias.
-​ De realismo: Deben comprobarse para garantizar que en realidad
pueden implementarse, debe considerarse el presupuesto y la
fecha.
-​ Verificabilidad: Deben escribirse los requerimientos de manera
que sean verificables, para demostrar que se cumple con cada
requerimiento especificado.

Algunas técnicas de validación de requerimientos son:

1.​ Revisiones de requerimientos: Se analizan usando un equipo de

revisores.
2.​ Creación de prototipos: Se muestra un modelo ejecutable a
usuarios finales y clientes para constatar si se cubre con sus
necesidades reales.
3.​ Generación de casos de prueba: Deben ser comprobables.
Administración de requerimientos:
Es el proceso de comprender y controlar los cambios en los
requerimientos del sistema. Es necesario mantener los vínculos entre
los requerimientos dependientes para valorar el efecto de cambio en los
requerimientos.

Una vez que se instala el sistema y se usa con regularidad, surgen

nuevos requerimientos. Al experimentar con el sistema, se descubren
nuevas necesidades y prioridades.

La planeación es una primera etapa esencial, establece el nivel de

detalle que se requiere en la administración de requerimientos.

Se debe decidir sobre:

1.​ Identificación de requerimientos

2.​ Un proceso de administración del cambio (valoran el efecto y
costo de los cambios)
3.​ Políticas de seguimiento (definen las relaciones entre cada
requerimiento)
4.​ Herramientas de apoyo (incluye el procesamiento de grandes
cantidades de información sobre los requerimientos)​

La administración de requerimientos necesita herramientas de apoyo

para:

-​ Almacenamiento de requerimientos: tienen que mantenerse en un

almacén administrado y seguro
-​ Administración del cambio: se simplifica con las herramientas
correctas
-​ Administración del seguimiento: Permite la identificación de
requerimientos relacionados.​
Administración del cambio en los requerimientos:
Debe aplicarse a todos los cambios propuestos a los requerimientos de
un sistema.

Es esencial porque es necesario determinar si los beneficios de

implementar un nuevo requerimiento están justificados por los costos de
su implementación.

Existen tres etapas principales de un proceso de administración del

cambio:

1. Análisis del problema y especificación del cambio: Comienza con

identificar un problema en los requerimientos, se analiza para
comprobar si la propuesta de cambio es valida y por ultimo se
responde con una propuesta de cambio o se retira la petición.

2. Análisis del cambio y estimación del costo: El costo por realizar el

cambio se estima en términos de modificaciones al documento, al
diseño y la implementación del sistema.

3. Implementación del cambio: Se modifica el documento, el diseño y

la implementación del sistema.

​
 U1- MODELOS
Modelo: Representación de un objeto, sistema o idea. Ayudan a
explicar, entender y mejorar un sistema.

Construimos determinados modelos para comprender mejor el sistema

que estamos construyendo. Permiten trabajar con mayores niveles de
abstracción.

Clasificación de Modelos:

-​ Estáticos: Describen un instante en un momento determinado.

-​ Dinámicos: Reconocen explícitamente el paso del tiempo.
-​ Físicos
-​ Esquemáticos
-​ Simbólicos

Principios del Modelado:

-​ La elección del modelo tendrá incidencia directa en la forma de la
solución.
-​ Todo modelo puede ser obtenido con diferentes grados de
precisión.
-​ Todo modelo debe reflejar las características esenciales de la
realidad.
-​ No es suficiente con hacer un solo modelo o vista.​

​
 U2 – PROYECTO
Metodología: El estudio (descripción, explicación y justificación) de los
métodos, y no los métodos en sí.

El término tiene distintos usos:

-​ Técnicas: Los procedimientos o técnicas específicos utilizados en

un ámbito científico.
-​ Honoríficos: donde la metodología se refiere al método científico
en sí y no a particularidades de técnicas o procedimientos
específicos.
-​ Epistemología: Refiere a lo que se puede decir sobre la ciencia en
sí o ciencias particulares.

Proyecto: Conjunto único de actividades necesarias para alcanzar un

resultado específico dentro de un marco de tiempo determinado y con
una asignación concreta de recursos.

Alcance: es todo el trabajo necesario para completar un proyecto con

éxito incluyendo lo necesario y cualquier trabajo adicional que no haya
sido planeado.

Procesos clave de la gestión de alcances:

Planificar la gestión de alcance: Cómo se determina el alcance y cómo
se controla a lo largo del ciclo de vida

Recopilar requisitos: Identificar y documentar las necesidades

Definir el alcance: declaración detallada del alcance con los entregables

claves del proyecto, sus restricciones y supuestos

Crear la estructura de desglose del trabajo: dividir los entregables en

componentes más manejables

Validar el alcance: aprobación formal de los entregables por parte de los

interesados

Controlar el alcance: monitorear el estado del alcance del proyecto y

gestionar los cambios

​
El alcance del proyecto es esencial para definir y limitar el trabajo,
asegurando que los objetivos sean claros y alcanzables dentro de los
parámetros establecidos. Ayuda a evitar retrasos y sobrecostos y
permite entregar una solución que cumple con las expectativas del
cliente.

Tiempo: es una de las restricciones más críticas a manejar. Involucra

una serie de procesos que aseguran que el proyecto se complete dentro
del tiempo estimado.

Procesos clave de la Gestión de Tiempo:

Planificar la gestión del cronograma: establecer políticas procedimientos
y documentación del cronograma del proyecto

Definir las actividades: Identificar y documentar las tareas específicas a

producir

Secuenciar las actividades: determinar el orden que deben realizarse

identificando dependencias entre ellas

Estimar la duración de las actividades: calcular el tiempo necesario para

completar cada actividad del proyecto

Desarrollar el cronograma: un cronograma de proyecto que integre las

actividades, secuencias, duraciones, recursos y restricciones del
proyecto.

Controlan el cronograma: monitorear el progreso y gestionar los

cambios en el cronograma para garantizar que se cumplan los plazos.

Costo: es fundamental para asegurar que se mantenga dentro del

presupuesto asignado al proyecto. Involucra los procesos necesarios
para planificar, estimar, gestionar y controlar los costos para que el
proyecto se complete dentro del presupuesto aprobado.

​
Procesos clave de la Gestión de Costos:
Planificar la gestión de costos: Cómo se planificarán, estructurarán y
controlarán los costos del proyecto.

Estimar los costos: calcular los costos aproximados de los recursos

necesarios para completar el proyecto.

Determinar el presupuesto: sumar los costos estimados para establecer

una línea base de costos.

Controlar los costos: monitorear el estado del proyecto para actualizar

los costos y gestionar cambios asegurando que se mantenga dentro de
los límites.

Triple restricción:
Un triángulo donde los tres lados corresponden a las restricciones de
Alcance Costo y Tiempo.

Están interrelacionadas, es decir que ante cualquier cambio en una de

ellas afecta inevitablemente a las otras dos.

Alcance: Define todo el trabajo a realizar para entregar un producto o

servicio específico punto incluye los objetivos entregables y tareas. Es
esencial para saber que está dentro y fuera del proyecto.

Tiempo: refiere al cronograma del proyecto, incluye planificación de

todas las actividades, duración de las tareas y la secuencia en que se
deben realizar para cumplir con los plazos. Es esencial porque los
proyectos tienen fecha límite que debe cumplirse

Costo: presupuesto total necesario para completar el proyecto. Incluye

salarios del equipo, compra de materiales y otros gastos asociados. Es
esencial para evitar sobrecostos.

​
En el centro del triángulo encontramos la calidad, está directamente
influenciado por el equilibrio entre alcance, tiempo y costo punto si uno
se desequilibra la calidad podría verse afectada. Esto es importante ya
que nuestro trabajo va dirigido directamente hacia ofrecerle calidad a los
clientes o usuarios.​

Evolución de la triple restricción: incorporación de nuevas

restricciones
El objetivo final de un proyecto es entregar valor a las partes
interesadas por lo tanto se ha incluido otras tres restricciones críticas:
Calidad, Riesgos y Recursos.

Calidad: es una restricción en sí misma ya que asegura que el producto

final cumpla con estándares y expectativas establecidos.

Requiere planificación y control a lo largo de todo el proyecto.​

Riesgos: hacen referencia a cualquier incidente inesperado que pueda

interferir en el proyecto.

Es necesario identificar, analizar y mitigar los riesgos potenciales que

podrían desviar el proyecto de sus objetivos.

Recursos: refieren a las personas, equipos, materiales y otros

elementos necesarios para completar el proyecto. Implica asegurar que
se tenga los recursos adecuados.
Modelos de proceso prescriptivo:
Prescriben un conjunto de modelos del proceso y proporcionan una
estructura y flujo del proceso definidos.

Modelo de Cascada o Clásico:

Es un enfoque sistemático y secuencial para el desarrollo del software
donde el trabajo fluye de manera lineal.

Ventajas:

Estructura clara, facilidad de gestión y visualización clara.

Desventajas:

Rigidez, Inflexibilidad y Dificultad de Retroalimentación

Modelo Evolutivo:
Enfoque iterativo que permite desarrollar versiones cada vez más
completas de un software.

Es adecuado en situaciones en las que los requerimientos del negocio y

producto cambian. Se caracteriza por aceptar que los Los
requerimientos pueden evolucionar.

Modelo Evolutivo - Prototipo:

Se trata de realizar un plan y modelado rápido​
se construye un prototipo, se entrega y ​
se obtiene retroalimentación.

Sus ventajas son una mejor comprensión​

de los requisitos y flexibilidad ante cambios,​
permitiendo ajustes continuos.
Sus desventajas son un posible aumento de costo y el riesgo de
desviarse del objetivo.

Modelo Evolutivo Espiral:

Consiste de las 5 fases: Se comienza con la comunicación, sigue con la
planeación, modelado, construcción y despliegue.

Sus ventajas son una mejor gestión de riesgos y flexibilidad mientras

que sus desventajas son mayor complejidad y costo y una dificultad
para gestionar.

Modelo V:
El modelo V es una extensión del modelo en cascada, pero con un
enfoque en las pruebas. Este modelo destaca la importancia de las
pruebas en cada fase del desarrollo, de manera que para cada fase de
diseño hay una fase correspondiente de prueba.

Ventajas:

-​ Refuerza el enfoque en la calidad del software, ya que las pruebas

se planifican desde el inicio.
-​ Es útil cuando los requisitos son claros y no cambiarán mucho
durante el desarrollo.

Desventajas:

-​ No es tan flexible en términos ​

de cambios en los requisitos.
-​ Puede resultar costoso debido a la ​
planificación detallada de las pruebas.
Modelo Ágil
Los modelos ágiles, como Scrum o Extreme Programming (XP), se
basan en iteraciones cortas (sprints) y una alta colaboración con los
clientes. Se centra en la entrega rápida de software funcional,
adaptándose constantemente a los cambios de requisitos a lo largo del
proceso.

Ventajas:

-​ Muy flexible y adaptable a los cambios en los requisitos.

-​ Promueve la colaboración continua con el cliente y el equipo.
-​ Rápida entrega de funcionalidades.

Desventajas:

-​ Requiere un alto nivel de comunicación y coordinación.

-​ Puede ser difícil de gestionar en proyectos grandes o distribuidos.
-​ Requiere equipos de trabajo experimentados y disciplinados.

​
 U2 – SCRUM
Agilidad: implica ser diestro y capaz de responder de manera apropiada
a los cambios. Incluye la filosofía expuesta en el en el manifiesto ágil
más allá que ser simplemente una respuesta efectiva al cambio.

Pone el énfasis en la entrega rápida funcional y resta importancia a los

productos intermedios del trabajo, puede aplicarse a cualquier proceso
de software.

Cuatro valores del desarrollo ágil:

-​ Individuos e interacciones sobre procesos y herramientas.

-​ Software que funciona sobre documentación exhaustiva.
-​ Colaboración con el cliente sobre negociación de un contrato.
-​ Responder al cambio sobre apegarse a un plan.

Una de las principales ventajas del desarrollo ágil es que permite que el
equipo de software haga cambios en una fase tardía del proyecto sin
que haya un efecto notable en el costo y tiempo del mismo.

El proceso ágil aborda cierto número de suposiciones clave:

-​ Es difícil predecir qué requerimientos persistirán y cuáles

cambiarán.
-​ Es difícil pronosticar cómo cambiarán las prioridades del cliente a
medida que avance el proyecto.
-​ Es difícil predecir cuántos diseños se necesitan antes de que se
use la construcción para probar el diseño.
 12 Principios de la agilidad:
1.​ La prioridad más alta y satisfacer al cliente a través de la entrega
pronta y continua de software valioso
2.​ Los procesos ágiles dominan el cambio para aprovecharse de las
ventajas competitivas que pueda tener el cliente
3.​ Entregar con frecuencia Software que funcione
4.​ Las personas de negocio y los desarrolladores deben trabajar
juntos durante todo el proyecto
5.​ Desarrollar los proyectos con individuos motivados.
6.​ El método más eficiente y eficaz para transmitir información es
cara a cara.
7.​ La medida principal de avance es el software que funciona.
8.​ Los procesos ágiles promueven el desarrollo sostenible es
necesario mantener un ritmo constante de forma indefinida.
9.​ La atención continua, la Excelencia técnica y el buen diseño
mejoran la agilidad
10.​ Es esencial la simplicidad, es decir maximizar la cantidad de
trabajo no realizado.
11.​ Las mejores arquitecturas y diseños surgen de equipos con
organización propia.
12.​ El equipo reflexiona en intervalos regulares Cómo ser más
eficaz y luego afinar y ajustar su comportamiento en
consecuencia.

En el desarrollo ágil el proceso se adapta a las necesidades de las

personas y del equipo no al revés.

Para ello debe existir cierto número de características claves en el

equipo ágil como tal:

-​ Competencia: incluye el talento innato, las habilidades específicas

relacionadas con el software y el conocimiento general del
proceso que el equipo del elegido aplicar.
-​ Enfoque común: todo el equipo debe centrarse en una meta:
entregar al cliente un incremento de Software que funcione.
-​ Colaboración: se trata de crear información que ayudará a todos
los participantes a entender el trabajo del equipo y generar
información que aporte el cliente valor de negocio.
-​ Habilidad para tomar decisiones: el equipo debe tener cierta
autonomía para tomar decisiones sobre asuntos técnicos como
del proyecto.
 -​ Capacidad para resolver problemas difusos: debe aceptarse que
el problema que se resuelva hoy no sea el problema que se
resuelva mañana punto pero las lecciones aprendidas a partir de
la solución resolución de problemas será benéfica para todo el
equipo en etapas posteriores del proyecto.
-​ Confianza y respeto mutuos: el equipo debe tener la confianza y
respeto necesario para hacer que su tejido sea tan fuerte que el
todo es más que la suma de las partes.
-​ Organización propia: El equipo se organiza a sí mismo, además
de organizar el proceso y la programación del trabajo.

Diferencias entre la gestión predictiva y la gestión ágil:

La gestión ágil se caracteriza por lo siguientes principios, en vez de

centrarse en la planificación detallada y ejecución conforme al plan:

-​ Respuesta al cambio sobre seguir un plan dos puntos es decir

adaptarse rápidamente a las modificaciones en los requerimientos
del cliente.
-​ Productos que funcionan frente a especificaciones detalladas: se
prioriza la entrega de un producto funcional.
-​ Colaboración con el cliente sobre negociación contractual: la
interacción constante y con el cliente es la clave para ajustar el
producto a sus necesidades.
-​ Personas e interacciones sobre procesos y herramientas dos
puntos se enfatiza la comunicación y colaboración entre equipos
de trabajo.​

La elección entre gestión ágil y predictiva depende de varios factores

clave:

Prioridad de negocio: la gestión predictiva es ideal para garantizar

cumplimiento de plazos mientras que la ágil se enfoca en maximizar el
valor.

Estabilidad de los requisitos: Si los requisitos son inestables o pueden

cambiar con frecuencia la gestión ágil resulta más adecuada.

Rigidez del producto: la rigidez afecta la elección del modelo de gestión,

tener en cuenta qué tan fácil será modificar el producto en desarrollo.

Coste de prototipado: en la gestión ágil se utiliza prototipos para

experimentar y ajustar el producto mejorando la entrega continua.
Criticidad del sistema: en sistemas de alta criticidad puede ser necesario
un enfoque más predictivo.

Tamaño del sistema: los proyectos grandes con equipos dispersos

pueden enfrentar desafíos al implementar métodos ágiles. Pero al usar
prácticas ágiles puede ayudarnos a superar dichas barreras.

Scrum: Marco de trabajo ligero que ayuda a generar valor generando

soluciones que se adapten a problemas complejos

Debe Haber:

-​ Product Owner que ordena el trabajo en un Product Backlog.

-​ Equipo de Scrum que entrega un incremento de valor durante un
Sprint.
-​ El equipo de Scrum y las partes interesadas inspeccionan
resultados y realizan ajustes necesarios para los próximos sprints.​

Scrum se basa en:

-​ Empirismo, es decir el conocimiento proviene de la experiencia y

la toma de decisiones basado en lo que se observa.
-​ Pensamiento Lean, se enfoca en reducir los desperdicios y
centrarse en lo esencial.

​
Pilares de Scrum:

-​ Transparencia: Permite la inspección y conduce a disminuir

riesgos y aumentar el valor
-​ Inspección: Sirve para detectar varianzas o problemas
indeseables, permite la adaptación.
-​ Adaptación: Permite realizar ajustes ante cualquier problema, se
hace lo antes posible para minimizar cualquier desviación
adicional.

Valores Scrum:

-​ Compromiso
-​ Enfoque
-​ Apertura
-​ Respeto
-​ Coraje

Roles:

-​ Equipo: Unidad fundamental que consiste de 7+-2 personas. Son

multifuncionales, todos los miembros tienen habilidades
necesarias para crear valor en cada Sprint. Además son
responsables de todas las actividades relacionadas a productos.
Su objetivo es crear un incremento útil y valioso en cada Sprint.
-​ Product Owner: Responsable de maximizar el valor del producto
resultante del trabajo del Equipo. Es responsable también de una
gestión eficaz del Product backlog.
-​ Scrum Master: Responsable de establecer Scrum según la guía
de Scrum. Es necesario que comprenda la teoría y práctica de
Scrum porque es responsable de la efectividad del Equipo.

​
Eventos formales para la inspección y adaptación:

Los eventos permiten la transparencia y se usan para crear regularidad

y minimizar la necesidad de reuniones no definidas en Scrum.

-​ Sprint: es un contenedor para todos los eventos. Tienen longitud

fija. Permiten la previsibilidad al garantizar la inspección y
adaptación del progreso hacia un objetivo del Producto.
-​ Planning: Inicia el Sprint y establece el trabajo a realizar en el
mismo. Se trata porque es valioso dicho Sprint, que se puede
hacer en el mismo y cómo se realizará el trabajo.
-​ Daily: Su propósito es inspeccionar el progreso hacia el Objetivo
de la Sprint y adaptar el Sprint Backlog según sea necesario.
-​ Review: Su propósito es inspeccionar el resultado del Sprint y
determinar futuras adaptaciones.
-​ Retrospective: Concluye el sprint y sirve para planificar formas de
aumentar la calidad y eficiencia. Se inspecciona como fue el
último Sprint.

Artefactos de Scrum:

Representan trabajo o valor y contienen un compromiso para garantizar

que proporcionan información que mejora la transparencia y enfoque
con el que se puede medir el progreso.

-​ Product Backlog: Es una lista emergente y ordenada de lo que se

necesita para mejorar el producto.
-​ Sprint Backlog: Se compone del objetivo Sprint, el conjunto de
elementos de trabajo que fueron seleccionados para este Sprint y
un plan de acciones para lograr el incremento.
-​ Incremento: Es un paso hacia el objetivo del Producto. Es aditivo a
los anteriores y verificado a fondo. Debe ser utilizable.
User Stories: Describe una funcionalidad que provee valor a un usuario
o cliente de un sistema o software. Tienen 3 aspectos:

1.​ Una descripción escrita de la historia usada para planeamiento o

recordatorio.
2.​ Conversaciones sobre la historia que permiten extender los
detalles de la misma.
3.​ Pruebas o detalles de documentos que pueden ser usados para
determinar si la historia está completa o no.

Las historias de usuario deben ser escritas de forma tal que el cliente o
usuario pueda valorarlas.​
Si una historia es muy grande se refiere a la misma como una épica,
que puede ser dividida en dos o más historias de tamaño más pequeño.
Es importante tener en cuenta que no debemos dividir historias de
usuario al punto tal que tengamos una historia por cada detalle a cubrir.

Spike: Tipo especial de Historia técnica o funcional para saldar una

deuda técnica del equipo, quitando riesgo o incertidumbre.

Se agrega una tarea de análisis e investigación al Product Backlog.

Aparecen a medida que surge el problema.
 U2- FACTIBILIDAD

Factibilidad: Refiere a la capacidad de llevar a cabo un proyecto

teniendo en cuenta si puede realizarse con los recursos, tecnología
personal y tiempo disponibles.
También implica identificar posibles obstáculos o limitaciones que
pueden surgir durante la implementación.

Viabilidad: Evalúa si es rentable o sostenible realizar un proyecto,

Considera los factores económicos y beneficios que generará el
proyecto.Además, implica un estudio detallado del mercado, demanda y
tendencias económicas.

Tipos de factibilidad:

Factibilidad técnica: Evalúa si los recursos tecnológicos son suficientes

para poder desarrollar el proyecto.Es importante analizar los recursos
actuales y las necesidades futuras.
Elementos Clave:
-​ Hardware(Evaluación de equipos, Estabilidad y Compatibilidad,
Capacidad y Procesamiento)
-​ Software (Desarrollo propio, Tercerización, Compra de software
existente y Compatibilidad)
-​ Procesamiento y Rendimiento (Capacidad de procesamiento,
Simulación de Rendimiento)
-​ Seguridad y Escalabilidad

Herramientas y Estrategias de Evaluación:

1.​ Matriz de Homogeneización: Una herramienta que permite
estandarizar las tecnologías.
2.​ Análisis de compatibilidad de hardware y software: Verifica si el
hardware y el software que ya tiene la empresa pueden trabajar
bien con las nuevas soluciones tecnológicas a implementar.
3.​ Benchmarking de Tecnología: Consiste en comparar diferentes
tecnologías, herramientas o productos que cumplen funciones
similares.
 4.​ Pruebas de concepto: Permiten realizar pruebas a pequeña escala
de una nueva tecnología o enfoque.
5.​ Estudio de capacidad de procesamiento: Analiza si los sistemas
actuales tienen capacidad de procesamiento como para manejar
la nueva carga de trabajo.
6.​ Simulación de rendimiento: Se simulan condiciones de uso en
escenarios reales o extremos para comprobar el funcionamiento
bajo diferentes niveles de carga o estrés.
7.​ Evaluación de escalabilidad y seguridad: Asegura que el sistema
pueda crecer sin problemas a medida que las necesidades
aumentan y que esté protegido frente a amenazas de seguridad.

Factibilidad Económica:
Se refiere a evaluar si un proyecto es financieramente viable, Implica
comparar los costos involucrados con los beneficios esperados.
Es importante para evitar pérdidas, optimizar la inversión y asegurar la
rentabilidad del proyecto.

Herramientas:
-​ Análisis de retorno sobre inversión: Es una métrica financiera que
mide el porcentaje de retorno generado por un proyecto.Compara
los beneficios obtenidos con el costo total del proyecto
proporcionando una medida clara sobre la viabilidad económica.
-​ Análisis costo beneficio: Compara los costos totales del proyecto
con los beneficios económicos y no económicos que se podrían
obtener.
-​ Valor presente neto: Calcula el valor presente de los flujos de caja
futuros descontados a una tasa de interés. Este análisis considera
que el valor del dinero disminuye con el tiempo y ayuda a
determinar si los ingresos futuros justifican la inversión inicial.
-​ Análisis de punto de equilibrio: En el momento en que los ingresos
generados igualarán a los costos. Es importante para decidir si es
sostenible.
-​ Flujo de caja descontado: Este análisis valora el proyecto
basándose en los ingresos y egresos proyectados.
 -​ Análisis de recuperación: Calcula el tiempo que tomará recuperar
la inversión inicial. Es útil para evaluar qué tan rápido un proyecto
comenzará a ser rentable.
-​ Análisis de sensibilidad económica: Evalúa como los cambios en
algunas variables clave afectan la viabilidad del proyecto. Sirve
para identificar los factores con mayor impacto en la rentabilidad
del proyecto.

Factibilidad Operativa:
Evalúa si la organización tiene la capacidad para implementar y utilizar
un nuevo sistema o proceso de manera efectiva.
Es importante porque: Garantiza la adopción del sistema, evita
interrupciones en las operaciones, reduce el riesgo de fallos operativos
y optimiza el uso de Recursos Humanos y materiales.
​
Elementos Clave:
1.​ Evaluación de recursos humanos: Evalúa si el personal disponible
cuenta con las competencias y habilidades necesarias para operar
el sistema.
2.​ Evaluación tecnológica: Analiza si la tecnología actual de la
organización es compatible con el nuevo sistema.
3.​ Aceptación por parte de los usuarios: Debe evaluar la disposición
de los usuarios a usar el sistema para evitar resistencias o bajos
niveles de adopción.
4.​ Momento de implementación: Debe planificarse cuidadosamente
para evitar interrupciones operativas.
5.​ Simulaciones y pruebas: Es útil para prever problemas potenciales
y evaluar el impacto organizacional.

Factores específicos:
-​ Preparación del sitio y equipos.
-​ Capacidad de los usuarios.
-​ Conversiones de datos.
-​ Controles.
Capacitación de Usuarios: Es crucial para asegurar que los usuarios
puedan aprovechar plenamente un nuevo sistema.
Para ser exitoso debe: Aumentar la adopción, disminuir errores, mejorar
la productividad y aumentar la satisfacción.

Planificación de la Capacitación:
1.​ Identificación de necesidades de capacitación.
2.​ Definición de objetivos claros.
3.​ Métodos de capacitación.
4.​ Desarrollo de contenido.
5.​ Recursos necesarios.
6.​ Evaluación de la capacitación.

Importancia del análisis de factibilidad:

Ofrece varios beneficios clave:
-​ Reducción de riesgos: Permite identificar obstáculos potenciales y,
en consecuencia, mitigar su impacto.
-​ Mejor administración de recursos: Garantiza que los recursos
disponibles se utilicen de manera eficiente.
-​ Alineación con los objetivos organizacionales: Confirma que el
software que se va a desarrollar será útil para la organización.
-​ Optimización de tiempo y esfuerzo: A prevenir problemas como
retrasos o sobrecostos.
-​ Decisiones informadas: Proporciona datos y análisis concretos
que facilitan la toma de decisiones fundamentadas.
 U2- RIESGO

Gestión de Riesgo: Implica anticipar riesgos que pudiera alterar el

calendario del proyecto o la calidad a entregar y posteriormente tomar
acciones para evitar dichos riesgos.

Categorías de Riesgos:
-​ Riesgos del proyecto: Alteran el calendario o los recursos del
proyecto.
-​ Riesgos del producto: Afectan la calidad o el rendimiento del
software a desarrollar.
-​ Riesgos empresariales: Afectan a la organización que desarrolla o
adquiere el software

Análisis de consecuencias: Establece las consecuencias del riesgo para

el proyecto, producto y compañía.

Proceso de Gestión de Riesgo:

1.​ Identificación del riesgo
2.​ Análisis de riesgos
3.​ Planeación del riesgo
4.​ Monitorización del riesgo

Plan de Gestión de riesgo: Incluye el estudio de los riesgos que enfrenta

el proyecto, un análisis de dichos riesgos e información de cómo se
gestiona el riesgo.

Identificación del Riesgo:

Identifica los riesgos que pudieran plantear una amenaza al proceso.
Se pueden incluir 6 tipos de riesgos en una lista de verificación:
1.​ Tecnológicos
2.​ Personales
3.​ Organizacionales
4.​ De Herramientas
5.​ De Requerimientos
6.​ De Estimación
Análisis de riesgo:
Se debe considerar cada riesgo identificado y realizar un juicio acerca
de la probabilidad y gravedad de dicho riesgo.
Asignar a una de ciertas bandas: Probabilidad(Baja,Alta,Moderada) y
Efectos (Catastrófico, Grave, Tolerable o Insignificante)

Planeación del riesgo:

Considera cada 1 de los riesgos clave identificados y desarrolla
estrategias para manejarlos. Deben considerarse acciones a tomar para
minimizar la perturbación del proyecto si se produce el problema
identificado.
3 categorías de estrategias:
1.​ Evitación (Se reduce la probabilidad de que surge el riesgo.)
2.​ Minimización (Se reduce el efecto del riesgo.)
3.​ Planes de Contingencia (Contamos con una estrategia para
enfrentar el riesgo si ocurre.)

Monitorización del riesgo:

Eso para comprobar que no han cambiado las suposiciones sobre los
riesgos del producto, proceso o empresa. Debe valorarse regularmente
cada uno de los riesgos para decidir si se vuelve más o menos
probable.
 U3 - UML:

Lenguaje de modelado visual de propósito general para especificar,

visualizar, construir y documentar los artefactos de un sistema de
software.
Esta pensado para ser apoyado por herramientas visuales e interactivas

Permite construcciones organizativas para agrupar los modelos en

paquetes, permitiendo dividir grandes sistemas en piezas pequeñas
más fáciles de trabajar comprender y controlar; además de visualizar las
dependencias y gestionar sus versiones.

Uml ha reemplazado la mayoría de las notaciones de modelado de los

procesos de desarrollo y también los artículos de literatura técnica.

UML 2.0 Tiene una cantidad de cambios importantes entre los cuales
hayamos:
-​ Construcción y notación de diagramas de secuencia basados en
ITU Message Sequence Chart
-​ Se elimina la relación entre los conceptos de modelado de
actividad y máquina de estado
-​ Se unifica el modelado de actividad con el modelado de acción

Objetivo de UML: No pretende ser un modelo completo de desarrollo

sino que está pensado para dar soporte a todos o al menos la mayoría
de los procesos de desarrollo.
Ser tan simple como fuera posible pero manteniendo la capacidad de
modelar toda la gama de sistemas que se necesita construir.

Áreas conceptuales de UML:

Se pueden agrupar los conceptos y modelos en las siguientes áreas:
-​ Estructura estática: Deben definirse los conceptos clave de la
aplicación, sus propiedades internas y las relaciones entre cada
una. En cada una la información que almacena se modela como
atributos, mientras que el comportamiento se modela como
 operaciones.Las relaciones entre los objetos se modelan mediante
asociaciones entre clases
-​ Construcciones de diseño: los modelos de uml también están
pensados para el diseño destinado a la implementación.
Determinadas construcciones representan elementos de diseño.
-​ Construcciones de despliegues: un nodo representa un recurso de
cálculo de tiempo que define una ubicación. Un artefacto es una
unidad física de información en un sistema informático. Los
artefactos se despliegan en nodos. La vista de despliegue
describe la configuración de los nodos en un sistema en ejecución
y la situación de los artefactos en ellos.
-​ Comportamiento Dinámico: Tenemos Tres formas de modelar…
Una es la historia de vida de un objeto, es decir la vista de un
objeto aislado o una máquina de Estados.
Otra son los patrones de comunicación de un conjunto de objetos
conectados, es decir un diagrama de secuencia o diagrama de
comunicación.
Por último tenemos la evolución del proceso de ejecución, es decir
un diagrama de actividad que muestra los cálculos y flujos de
trabajo en las organizaciones humanas.
Para guiar todas las vistas de comportamiento encontramos los
casos de uso que incluyen la estructura estática de los casos de
uso y actores además de las secuencias dinámicas de mensajes
entre actores y el sistema expresadas como diagramas de
secuencia o texto.
-​ Organización del modelo: Permite que la información de modelado
sea dividida en piezas para que los equipos puedan trabajar sobre
las diferentes partes de forma concurrente.
-​ Perfiles: Uml contiene una capacidad limitada de extensión que
permite la mayoría de las necesidades sin modificar el lenguaje
básico. Un estereotipo es un nuevo tipo de elemento del modelo
con la misma estructura que un elemento existente Pero con
restricciones adicionales de interpretación e icono diferentes,
encontramos que un estereotipo define un conjunto de valores
etiquetados. Un valor etiquetado es un atributo definido por el
usuario que se aplica a los propios elementos del modelo.
 U3 - UML Capítulo 2 - Modelos

Modelo: Es una representación en un medio de algo, captura los

aspectos importantes de lo que se está modelando desde un cierto
punto de vista.
Se expresa en un medio adecuado
Tiene semántica y notación

Se utilizan para :
-​ Capturar y enumerar exhaustivamente los requisitos y el dominio
del conocimiento para que todos los implicados puedan entenderlo
y estar de acuerdo
-​ Pensar en el diseño de un sistema (Gracias a la simplicidad de
crear y modificar pequeños modelos, que permite un pensamiento
creativo con poco coste)
-​ Para capturar las decisiones de diseño en un formato alterable
independiente de los requisitos
-​ Para generar productos usables para el trabajo
-​ Para organizar, encontrar, filtrar, recuperar, examinar y corregir la
información en grandes sistemas
-​ Para explorar económicamente múltiples soluciones
-​ Para dominar sistemas complejos

En resumen, permiten ocuparse de la complejidad que es demasiado

difícil de tratar directamente. Puede abstraerse a un nivel comprensible
sin perder detalles. Además puede determinar el impacto potencial de
realizar un cambio antes de realizarlo efectivamente.

Niveles de los modelos:

Los modelos tienen distintas formas para distintos propósitos y
aparecen en distintos niveles de abstracción.
Debe adaptarse la cantidad de detalles a uno de los siguientes
propósitos:

-​ Guías para el proceso de pensamiento: sirve para centrarse en el

proceso de pensamiento de los participantes y destacar
determinadas opciones no necesitan los detalles o precisión de un
modelo de implementación ni necesitan de una gama completa de
conceptos de implementación.
-​ Especificaciones abstractas de la estructura esencial de un
sistema: se centran los conceptos claves y mecanismos del
posible sistema pero faltan los detalles en el modelo que deben
ser añadidos explícitamente durante el proceso de diseño. Su
propósito es obtener de forma correcta los aspectos principales de
alto nivel antes de abordar detalles más localizados. Están
pensados para hacer los evolucionar hacia los modelos finales.
-​ Especificaciones completas de un sistema final: un modelo de
implementación incluye suficiente información como para construir
el sistema, debe incluir la semántica lógica y los algoritmos,
estructura de datos y mecanismos que aseguran un rendimiento
adecuado. Es necesario incluir las decisiones organizativas sobre
los artefactos del sistema.
-​ Ejemplos de sistemas típicos o posibles: se usan cuando
necesitamos modelos que especifiquen el caso general. Suele
incluir instancias específicas más que descriptores generales.
-​ Descripciones completas o parciales de un sistema: un modelo
puede ser una descripción completa de un solo sistema sin
referencias externas.

Que tiene un modelo:

-​ Semántica: captura el significado de una aplicación en forma de
una red de construcciones lógicas que llevan el significado del
modelo. la información semántica suele ser denominada como el
modelo
-​ Presentación: Muestra la información semántica de forma que
pueda ser vista y corregida por los humanos, muestran el modelo
de forma que este sea comprensible pero organiza la presentación
para enfatizar la organización del modelo de una manera útil.
 -​ Contexto: los modelos se utilizan dentro de un contexto mayor que
les da su significado completo.

Significado de un modelo:
Un modelo es una abstracción a un cierto nivel que captura los aspectos
esenciales de un sistema e ignora alguno de los detalles.
-​ Abstracción frente a detalle: el modelo captura los aspectos
esenciales del sistema e ignora otros modelos con distintos
niveles de precisión pueden ser utilizados a lo largo de la vida del
proyecto
-​ Especificación frente implementación: un modelo puede decir qué
es lo que hace algo, la especificación y cómo se consigue la
función, es decir implementación.
-​ Descripción frente a instancia: los modelos son descripciones, las
cosas que describen son instancias las cuales normalmente
aparecen en los modelos solo como ejemplo.
-​ Variaciones en la interpretación: hay muchas interpretaciones
posibles de los modelos en un lenguaje de modelado podemos
definir ciertos puntos de variación semántica es decir lugares
donde son posibles distintas interpretaciones y asignarle a cada
interpretación un nombre como variación semántica.
 U3 - UML Capítulo 3 - Vistas

Vista: Subconjunto de las construcciones de modelado de UML,

representan un aspecto del sistema.

Clasificación:
Vista Estática:
Modela conceptos del dominio de la aplicación y conceptos internos
inventados como parte de la implementación de la aplicación.
Los componentes principales son las clases y sus relaciones.

Vistas de Diseño:​
Modelan la estructura de diseño de la propia aplicación, su expansión
en clasificadores estructurados, las colaboraciones que proporcionan
funcionalidad y su ensamblado a partir de componentes con interfaces
bien definidas.
Diagramas:
-​ Diagrama de estructura interna: Muestra la descomposición
interna de una clase.
-​ Diagrama de colaboración: Una colaboración es una relación
contextual entre un conjunto de objetos que trabajan juntos
para lograr un propósito.
-​ Diagrama de componentes: un componente es un tipo de
clasificador estructurado, cuya estructura debe definirse en
un diagrama de estructura interna. Muestra los componentes
de un sistema y las dependencias entre componentes para
valorar el impacto de un cambio propuesto.

Vista de casos de uso:

Modela la funcionalidad de un sistema tal como lo perciben los agentes
externos o actores. Estos últimos interactúan con el sistema desde un
punto de vista particular.
Un caso de uso es una unidad de funcionalidad expresada como una
transacción entre los actores y el sistema
El propósito de esta vista es enumerar los actores y casos de uso y
mostrar qué actores participan en cada caso de uso.
Vista de máquina de Estados:
Una máquina de Estados modela las posibles historias de vida de un
objeto de una clase.
Contiene estados que son conectados por transiciones y cada estado
modela un periodo de tiempo durante la vida de un objeto que satisface
en el que satisface ciertas condiciones.
Al ocurrir un evento se desencadenó una transición que lleva el objeto a
un nuevo estado.
Se utiliza para describir interfaces de usuario controladores de
dispositivos y otros subsistemas reactivos. También pueden ser usadas
para describir objetos que pasan por varias fases cualitativamente
distintas durante su tiempo de vida y además dichas fases tienen un
comportamiento especial.

Vista de actividad:
Una actividad muestra el flujo de control entre las actividades
involucradas en la realización de un cálculo o flujo de trabajo.
Una acción es un paso computacional primitivo.
Mientras que un nodo de actividades es un grupo de acciones o
subactividades.

Vista de interacción:
Describe el intercambio de secuencias de mensajes entre las partes de
un sistema.

Diagrama de secuencia:
Muestra un conjunto de mensajes ordenados en una secuencia
temporal. Un diagrama de secuencia puede mostrar un escenario o
historia individual de una transacción.
Se utilizan para mostrar la secuencia de comportamiento de un caso de
uso

Diagrama de comunicación:
Muestra los roles en una interacción con una disposición geométrica
donde cada rectángulo es un rol.Los mensajes entre los objetos se
muestran como flechas vinculadas a los conectores.
Un uso posible es mostrar la implementación de cualquier operación.
Vista de despliegue:
Representa el despliegue de artefactos de tiempo de ejecución sobre
nodos.

Vista de gestión del modelo:

Modela la organización del modelo en sí mismo. Un modelo abarca un
conjunto de paquetes que contiene los elementos del modelo, a su vez
los paquetes pueden contener otros paquetes.
Un modelo es una descripción completa de un sistema con una
determinada precisión y punto de vista.
Los paquetes son unidades para manipular los contenidos de un modelo
además de unidades para el control de acceso y control de
configuración.
 U3- UML Capítulo 4 - Relaciones

Asociación:
Describe conexiones discretas entre objetos u otras instancias en un
sistema. Llevan la información sobre las relaciones entre los objetos de
un sistema.
La mayor parte de la información sobre una asociación se vincula a uno
de sus extremos además, es importante considerar la multiplicidad, es
decir cuantas instancias pueden relacionarse con otra.
Una asociación también puede tener atributos por sí misma, en ese
caso es una clase de asociación.
Las asociaciones representan relaciones lógicas entre objetos.

Agregación: Representa una relación todo-parte, se representa con un

diamante hueco en el extremo de la trayectora unida a la clase
agregada.

Composición: Es una forma más fuerte de asociación en la cual el

compuesto es el responsable único de gestionar sus partes como en el
caso de su asignación y desasignación.

Enlaces: Una instancia de una asociación es un enlace, un enlace es

una lista ordenada de referencias a objetos. Los enlaces no existen
independientemente de los objetos sino que toman su identidad de los
objetos que relacionan.

Bidireccionalidad: Los distintos extremos de una asociación son

distinguibles, incluso si dos de ellos involucran a la misma clase. Dado
que son distinguibles una asociación no es simétrica los extremos no
pueden ser intercambiados.

Generalización: La relación de generalización es una relación

taxonómica entre una descripción más general y una descripción más
específica que se construye sobre ella y la va extendiendo.
se representa como una flecha del hijo al padre con un gran triángulo
hueco en el extremo conectado al padre
Propósito de la generalización:
1.​ Definir las condiciones bajo las cuales una instancia de una clase
puede ser utilizada cuando se declara una variable. Permite
operaciones polimórficas porque la clase padre puede tener
muchos hijos cada uno de los cuales implementa su propia
variación de una operación.
2.​ Permitir la descripción incremental de un elemento que comparte
descripciones con su antecesor, esto se denomina Herencia.

Herencia:
Mecanismo mediante el cual una descripción de un objeto de una clase
se construye a partir de fragmentos de declaraciones de dicha clase y
sus antecesores.
Es importante tener en cuenta que un atributo declarado en un
antecesor no puede ser redeclarado en un descendiente.

Herencia múltiple: si un clasificador tiene más de un padre hereda de

cada uno de ellos y sus características son la unión de las de sus
padres.

Realización: Conecta a un elemento del modelo como una clase con

otro elemento como interfaz quien proporciona su especificación de
comportamiento pero no estructura o implementación.
Relaciona dos elementos de diferentes niveles semánticos.

Dependencia: Indica una relación semántica entre dos o más elementos

del modelo, un cambio en el elemento proveedor puede requerir un
cambio o indicar un cambio en el significado del elemento cliente de la
dependencia.

Restricción: Es una expresión booleana representada como una cadena

que debe ser interpretada en un determinado lenguaje

Instancia: Es una entidad de tiempo de ejecución con identidad es decir

se puede distinguir de otras entidades de tiempo de ejecución. Tiene un
valor en todo momento.
 U3 - 4 VISTAS +1

Para cada vista definimos el conjunto de elementos a utilizar, teniendo

en cuenta las formas y patrones que funcionan.

Vista Lógica:

Muestra los requerimientos funcionales, es decir lo que el sistema

debería proveer a los usuarios.

El sistema se descompone en un conjunto de abstracciones claves del

dominio del problema, en forma de objetos o clases.

Se suele representar utilizando diagramas de clase.

Vista de Procesos:

Toma en cuenta algunos requisitos no-funcionales como el rendimiento

y disponibilidad. Además tiene en cuenta los aspectos de concurrencia y
distribución entre otros.

Puede describirse en varios niveles de abstracción, donde cada nivel

responde a diferentes preocupaciones.
La vista de Despliegue:

Se enfoca en el módulo de software en el entorno de desarrollo. El

software esta empaquetado en pequeñas cantidades o subsistemas.

Se representa con un diagrama de módulos y subsistemas.

Tiene en cuenta requerimientos internos relacionados a la facilidad del

desarrollo y manejo de software.

Esta vista sirve como base para la asignación de recursos, equipos,

evaluación de costos y planeamiento.

La vista física:

Tiene en cuenta los requisitos no-funcionales del sistema tales como

disponibilidad, fiabilidad, rendimiento y escalabilidad.

Los diversos elementos identificados se mapean a los diversos nodos.

El mapeo del software a los nodos tiene que ser flexible y tener un
mínimo impacto en el código fuente.
Escenarios o Vista de Casos de Uso:

Los elementos en las cuatro vistas trabajan en conjunto de manera

fluida por el uso de escenarios.

Los escenarios son una abstracción de los requerimientos mas

importantes, su diseño se expresa usando el diagrama de objetos.

Esta vista es redundante con las otras (por eso se conoce como +1)
pero sirve para dos propósitos importantes:

1.​ Para descubrir los elementos arquitectónicos durante el diseño de

arquitectura
2.​ Como un rol de validación e ilustración luego de que el diseño de
arquitectura esta completo.
 U4 - TESTING
Testing de Software: Consiste en una serie de actividades orientadas a
recopilar información sobre el funcionamiento y comportamiento de una
aplicación, para determinar si esta lista para su uso público o
generalizado.

La crisis del software de los años 80 hizo que el control y la mejora de la

calidad se convirtieran en una necesidad urgente.

Aseguramiento de Calidad (QA): es un enfoque preventivo que busca

establecer procesos y estándares que garanticen que el software
cumpla con los requisitos y expectativas del cliente.

Control de Calidad (QC): es un enfoque correctivo que implica evaluar el

producto terminado para encontrar defectos y problemas.

Verificación: Responde a la pregunta ¿Estamos construyendo el

producto de manera correcta?. Se asegura que se sigan los estándares
y requisitos establecidos. Se verifican calidad de documentación,
cumplimiento de modelos y una implementación adecuada de los
requisitos. Se centra en corregir el proceso de desarrollo

Validación: Responde a la pregunta ¿Estamos construyendo el producto

correcto? El enfoque esta en el producto final, se valida que esten
satisfechas las necesidades del usuario/cliente. Se centra en evaluar si
el producto final es el adecuado.

Principios del Testing:

1.​ El testing muestra la presencia de defectos y no su ausencia: Las

pruebas realizadas nunca pueden demostrar que el producto esta
completamente libre de defectos.
2.​ El testing exhaustivo es imposible: Es imposible probar todas las
combinaciones posibles de entradas y escenarios en un software.
3.​ Testing temprano: Las actividades de testing deben comenzar lo
antes posible en el ciclo de vida del desarrollo del software.
4.​ Agrupación de defectos: La mayoría de los defectos se concentran
en unos pocos módulos del software.
 5.​ Paradoja del pesticida: Si las mismas pruebas se repiten, se
dejarán de encontrar nuevos errores, por eso es que las pruebas
deben actualizarse constantemente.
6.​ El testing depende del contexto: Las pruebas deben adaptarse al
tipo de software que se esta evaluando.
7.​ Falacia de ausencia de errores: Encontrar y corregir defectos no
garantiza el éxito, el software puede fallar si no satisface las
necesidades del usuario o no cumple con los requisitos.

Rol del Tester:

Responsable de llevar a cabo todo el proceso de pruebas de un

software. Usa diversas técnicas para identificar errores y asegurar que
el producto cumple con los requisitos establecidos.

Se enfoca en:

-​ Bugs (fallos o cualquier cosa que pueda afectar negativamente el

valor del producto)
-​ Riesgos (Identifican riesgos que podrían derivar en futuros
errores)
-​ Problemas (No necesariamente afecta al producto pero amenaza
el éxito del proyecto)
-​ Testeabilidad (Identifican características del software que dificultan
o limitan el proceso de pruebas)
-​ Artefactos (Problemas que surgen como consecuencia de la
herramienta utilizada para realizar las pruebas)

Error: Ocurre cuando una persona comete una equivocación ya sea al

escribir el código o documentar los requisitos del sistema.

Defecto: Resultado de un error que fue introducido en el código o

documento, al ejecutarse el programa un defecto genera
comportamiento no deseado.

Al analizar un defecto surgen estas dos características:

-​ Severidad: mide el impacto que tiene el defecto

-​ Prioridad: Indica que tan urgente es corregir el defecto.
Fallo: Ocurre cuando un defecto se manifiesta al ejecutarse el sistema,
es el resultado visible del defecto y genera que el programa funcione de
manera incorrecta o no funcione.

Al analizar cuanto testing es necesario y suficiente es necesario tener

en cuenta dos variables:

-​ Riesgo: mide la probabilidad de que algo salga mal y el impacto

que tendría dicho fallo en el sistema.
-​ Costo: refiere tanto al costo financiero del proyecto como al costo
potencial de no detectar y corregir los defectos a tiempo.

Severidad: refleja el impacto que tiene la funcionalidad del sistema o en

la experiencia del usuario.

Es necesario analizar los defectos en función de impacto y probabilidad

donde:​
- Impacto mide la gravedad del defecto cuando ocurre y sus niveles son
alto o bajo

- Probabilidad donde se mide la frecuencia con la que es probable que

ocurra el defecto y puede ser alta o baja

Estados de los defectos:

-​ Nuevo
-​ Asignado
-​ Rechazado
-​ Solucionado
-​ Listo para Pruebas
-​ Reprueba fallida
-​ Cerrado

Pruebas Unitarias: Son un tipo de prueba donde se verifica el

funcionamiento de las partes más pequeñas y aisladas de una
aplicación.

Se crean casos de prueba específicos que cubren escenarios para la

unidad que esta en prueba.
Ventajas de las Pruebas Unitarias:

-​ Detección temprana de errores

-​ Facilitan el mantenimiento
-​ Mejor comprensión del código

Tipos de Pruebas Unitarias:

-​ Pruebas Positivas: Verifican que la unidad de código se

compruebe en condiciones normales o válidas
-​ Pruebas Negativas: Verifican que el código maneje
adecuadamente situaciones o entradas no válidas.
-​ Pruebas de Frontera: Se usan para verificar el comportamiento de
una unidad en el límite de sus valores permitidos
-​ Pruebas de excepción: Evalúan el comportamiento del código al
ocurrir una excepción

Pruebas Complementarias a las Unitarias:​

- Pruebas de verificación funcional: Verifican que cada unidad cumpla
con su funcionalidad esperada.

- Pruebas de Regresión: Conjunto de pruebas unitarias que se ejecutan

nuevamente después de realizar cambios en el código para asegurarse
de que las modificaciones no hayan introducido errores en
funcionalidades existentes.

Pruebas de Integración: Tipo de prueba diseñada para verificar que los

diferentes módulos de una aplicación funcionen correctamente cuando
se combinen. Validan que las partes del sistema interactúan y se
comuniquen de manera adecuada.

Ventajas de las Pruebas de Integración:

-​ Detección de errores en la interacción entre modulos

-​ Prevención de problemas de integración tardía
-​ Validación de funcionalidades mas complejas
-​ Mayor confiabilidad del sistema
Tipos de Pruebas de Integración:

-​ Pruebas de Integración de Big Bang: Todos los módulos se

integran simultáneamente y se prueban en conjunto.
-​ Pruebas de Integración Incremental: Se integran y se prueban de
manera gradual los módulos. Pueden ser Top-Down o Bottom-Up
-​ Pruebas de Integración Continua: Se ejecutan pruebas de manera
constante con cada nuevo cambio en el código.
-​ Pruebas de Interfaz: Verifican que las interfaces se comuniquen
correctamente y transfieran los datos de manera esperada.

Pruebas de Sistema: Un tipo de prueba que se lleva a cabo sobre el

sistema completo e integrado. Sirve para verificar que todos los
componentes funcionen en conjunto y cumplan con los requisitos
especificados.

Se somete a una batería de pruebas que verifican funcionalidades y

características no funcionales.

Ventajas de las Pruebas de Sistema:

-​ Verificación Integral del Sistema

-​ Detección de Problemas en Entornos reales
-​ Aseguran la calidad global del proyecto

Tipos de Prueba de Sistemas:

-​ Pruebas Funcionales: Verifican que el sistema cumpla con todas

las funciones requeridas según las especificaciones del cliente.
-​ Pruebas No Funcionales: Evalúan aspectos como rendimiento,
seguridad, escalabilidad y fiabilidad.
-​ Pruebas de Carga: Evalúan el rendimiento del sistema bajo
diferentes niveles de carga.
-​ Pruebas de Estrés: Se usan para determinar los límites del
sistema sometiendo a condiciones extremas.
-​ Pruebas de Seguridad: Verifican la capacidad del sistema para
resistir ataques de seguridad
-​ Pruebas de Backup y Restauración: Evalúan la capacidad del
sistema para realizar copias de seguridad de datos de manera
efectiva.
 -​ Smoke Testing: Conjunto básico de pruebas para verificar si las
funcionalidades principales del sistema funcionan correctamente
después de una construcción o actualización
-​ Pruebas de Usabilidad: Evalúan lo fácil y amigable que es el
sistema para los usuarios finales.
-​ Pruebas de Compatibilidad: Aseguran que el sistema funcione
correctamente en diferentes plataformas y dispositivos.
-​ Recovery Testing: Evalúan la capacidad del sistema para
recuperarse ante los fallos
-​ Pruebas End To End: Validan el flujo completo de la aplicación
desde el inicio al fin, asegurándose que los componentes y
módulos trabajen en conjunto correctamente.

Pruebas de Aceptación (UAT): Pruebas donde los usuarios finales

validan si el sistema cumple con los requisitos y expectativas
establecidos.

Su objetivo es asegurar que el software es apropiado para su uso en el

mundo real. Se evalúa además si es fácil de usar, intuitivo y de acuerdo
con las expectativas del cliente.

Ventajas de las Pruebas de Aceptación:

-​ Validación desde la perspectiva del usuario

-​ Detección de errores en una etapa tardía
-​ Asegura la satisfacción del cliente
-​ Reduce el riesgo de post-lanzamiento

Tipos de Pruebas de Aceptación:

-​ Pruebas de Aceptación del Usuario

-​ Pruebas de Aceptación Operacional: Se centran en evaluar
aspectos operacionales del sistema como seguridad o
recuperación
-​ Pruebas Alfa: Realizadas en un entorno de desarrollo
-​ Pruebas Beta: Fuera del equipo de desarrollo
-​ Pruebas de Aceptación Contractual o Regulación: Verifican que el
sistema cumpla con las normativas y regulaciones contractuales o
legales.
-​ Pruebas de Aceptación de Negocio: Evalúan si el software
satisface las necesidades de negocio.
 -​ Pruebas de Aceptación de Usabilidad: Evalúan la facilidad de uso
del sistema, experiencia de usuario y accesibilidad.

Casos de Prueba: Artefacto fundamental en el proceso de pruebas,

permite analizar y documentar si el software cumple con los requisitos y
funciona correctamente.

Se componen de los siguientes elementos:

1.​ Objetivo o Propósito de la prueba

2.​ Datos de entrada y ambiente
3.​ Comportamiento esperado y actual

Características de un buen caso de prueba:

-​ Preciso
-​ Económico
-​ Rastreable
-​ Repetible
-​ Reutilizable

Fases del Proceso de Pruebas:

1.​ Planificación de las Pruebas: fase en la que se definen los

objetivos de las pruebas y actividades necesarias para cumplirlos.
Se suele plasmar en un Plan de Pruebas
2.​ Especificación de Pruebas: Definición detallada de los casos de
pruebas, considerando el ambiente de prueba, los datos, el diseño
y priorización de los casos.
3.​ Ejecución de las pruebas: Se definen los procedimientos de
prueba, ya sean manuales o automatizados.
4.​ Análisis de Pruebas: Se interpretan los resultados obtenidos.
5.​ Evaluación de las Pruebas: Se comparan los resultados obtenidos
con los planes y criterios de aceptación previamente establecidos.

Tipos de pruebas de Software:

1.​ Según el comportamiento:

-​ Estáticas: no se ejecuta el codigo, se evalúa el codigo fuente
para identificar defectos
-​ Dinámicas: Requieren ejecutar y observar el
comportamiento en tiempo real del software.
 2.​ Según el punto de vista de implementación y ejecución:
-​ Manuales: Implican la intervención de un tester humano que
sigue un conjunto predefinido de pasos para probar el
software
-​ Automatizadas: Se usan herramientas de software para
ejecutar las pruebas de manera automática
3.​ Según los Requisitos:
-​ Funcionales: validan que el software cumpla con las
funcionalidades descritas en el documento de
requerimientos.
-​ No Funcionales: Validan Aspectos del sistema que no estan
directamente relacionados con la funcionalidad del mismo.

Pruebas de Caja Negra: Se enfocan exclusivamente en las entradas y

salidas del sistema sin considerar su estructura interna o
implementación. Validan que el sistema cumpla con los requisitos
funcionales y produzca resultados correctos y esperados.

Pruebas de Caja Blanca: Requieren un entendimiento profundo del

código fuente del sistema y evaluar la lógica interna y flujo del
programa.

Test Driven Development (TDD):

Forma parte de la metodología XP, Se basa en el ciclo

Red-Green-Refactor donde:

-​ Rojo: escribir una prueba que falle ya que no hay codigo

implementado aun
-​ Verde: Implementar el código mínimo necesario para que la
prueba pase
-​ Refactorizar: Mejorar el código asegurando que no se rompa la
funcionalidad
Acceptance Test Driven Development (ATDD):

Los clientes, testers y desarrolladores colaboran para definir los criterios

de aceptación antes del desarrollo. Se asegura de que se entienda
claramente que se espera del sistema

Behavior Driven Development (BDD):​

Se enfoca en el comportamiento del sistema desde una perspectiva del
negocio, usa ejemplos concretos para definir cómo debería comportarse
el sistema en diferentes escenarios.

Automatización de Pruebas: Consiste en utilizar herramientas

especializadas para realizar el proceso de testing de software de forma
automática. Permite alcanzar mayor cobertura en las pruebas y reducir
la necesidad de intervención manual.

Es necesario tener en cuenta:

-​ Capacidad de mantenimiento
-​ Flexibilidad
-​ Capacidad de control
-​ Escalabilidad
-​ Tiempo de ejecución