---
title: Ingenieria de Software - 4K3 - Teorico
tags: ISW, Ingenieria de Software, 4K3
description: Notas tomadas a lo largo del cursado de Ingenieria de Software en el curso 4K3.
---
[TOC]

---

:::info
User stories: Describirlas, actor, criterios de aceptacion, pruebas de usuario.
Estimaciones en la serie de Fibonacci
:::

### Software Configuration Managment (SCM)
Es una disciplina de soporte/protectora, que ocurre transversalmente al proyecto y lo trasciende para darle soporte y mantener la integridad del producto en todo su ciclo de vida desde el momento uno, desde el primer **item de configuracion (configuration item)**, que seria cualquier cosa que pueda entrar a la computadora, ya sea una imagen, un prototipo del producto, codigo, etc.
Un producto para mantener integridad debe cumplir con:
- Satisfacer las necesidades del usuario
- Facil y rastreable en todo su ciclo de vida
- Satisfacer los criterios de la performance
- Cumplir con la expectativa de costo

La responsabilidad de mantener la integridad de un producto es de todas las personas que involucran la construccion de ese producto. Cada persona del equipo es responsable de seguir los lineamientos de configuracion que se definieron para todo el equipo.

#### Conceptos clave para la gestion de configuracion
- ++Configuracion:++ Una foto del repositorio y su conjunto de items de configuracion en un determinado momento.

- ++Item de configuracion:++ Todos y cada uno de los artefactos que forman parte del producto o del proyecto. Necesitan ser compartidos entre los miembros del equipo (Requerimientos, User Story. Pero son todos elementos que pueden estar en un File System. Una foto, un libro excel, word, base de datos, codigo, etc.).
- De Producto: Ciclo de vida mas largo, trasciende a los proyectos.
- De Proyecto:
- De Iteracion: Menor ciclo de vida

- ++Repositorio:++ Lugar donde se almacenan, contenedor de todos los items de configuracion y su historia, accesible por varias personas a la vez y mantener las versiones. Tiene una estructura que permite definir cada lugar para cada item con el objetivo de mantener trazabilidad y si uno quiere encontrar un item, sepa exactamente donde buscarlo.
- ++Version:++ Estado particular en el tiempo de cada item de configuracion.

- ++Linea Base:++ Es un item o un conjunto de item de configuracion que son estables, es decir que se los puede tomar como referencia, por lo que ya pasaron por todos los niveles de revision y aprobacion y no deben ser modificados con libertad sin previa aprobacion. Esto quiere decir que para modificar una Linea Base debe pasar por un proceso formal de Control de Cambios.
Se los marca o "tagea" de manera univoca para identificar que ese conjunto de items forman parte de la **linea base**. La forma de identificacion univoca se da con un nombre, un estado, un id e indicar cuales son los items que forman parte de la linea base con su estado.
Se utiliza para poner un punto de referencia, un punto de partida para avanzar en el desarrollo.
Pueden ser de dos tipos:
- De especificacion(Requerimientos, Diseoño): No tienen codigo, tienen informacion de la ingenieria del producto
- Operacionales: Contienen codigo que en general es operativo y se marcan para entrar en una version de prueba de aceptacion o produccion.

- ++Ramas:++ No es recomendable trabajar y modificar los items de la rama principal o master del proyecto, por lo cual se crea una bifurcacion para poder trabajar con ella, y una vez que los cambios realizados estan aprobados, se hace un merge o una integracion de la bifurcacion a la rama principal, es decir, lleva los cambios a la rama principal. En la integracion, pueden surgir conflictos que debemos resolver con diff.
Eventualmente todas las ramas creadas que no sean la principal, deberian integrarse a la misma o descartarse.

#### Actividades Fundamentales en el SCM
- ++Identificacion de items:++ Se define la estructura del repositorio, se identifican los items de configuracion univocamente y se asignan los items y se asignan los items a un lugar especifico dentro de la estructura del repositorio.
La especificacion de los items no siempre se puede realizar de antemano, por lo que se establecen reglas de nombrado, genericos, que suelen seguir lineamientos, estandares.

- ++Control de Cambios:++ Actividad que se encarga de definir los cambios sobre las Lineas Base y mantener la integridad de las mismas a lo largo del tiempo. Procedimiento formal que involuctra diferentes actores y una evaluacion del impacto del cambio. En el control de cambios interviene un Comite de Control de Cambios (CCC) formado por representantes de todas las areas involucradas en el desarrollo (Analisis/Diseño, Implementacion, Testing, Otros(clientes, etc)).

- ++Auditorias de Configuracion:++ Se realiza en base a un plan que responda al porque de cada cosa, porque esta hecho de esa manera, para contrastarlo con la realidad. La herramienta que me ayuda a hacer auditoria es la *Matriz de Trazabilidad*. Dos tipos de auditorias en la gestion de configuracion:
- Auditoria Fisica: **Se realiza primero ya que me dice donde estan los items de configuracion y me permite pasar a la Funcional. Realiza la parte de verificacion**. Vela por la integridad del repositorio, que este, que se encuentre alojado en el lugar donde se fijo, que los items de configuracion respeten las normas de nombrado, que esten guardados en la parte correspondiente del repositorio. **Se audita sobre una linea base.** La auditoria es realizada por un tercero al proyecto, de afuera, para obtener una vision objetiva del proyecto.

- Auditoria Funcional: **Se realiza luego de la Fisica y en base a la misma. Realiza la parte de validacion**. Ver si el producto, es el producto correcto, si los items de configuracion que se tienen, responden a lo que los requerimientos dicen que tienen que hacer

- ++Informes de Estado:++ Generar reportes acerca del estado de la configuracion para generar visibilidad, proporcionar informacion y poder tomar decisiones mas acertadas.
El reporte basico se denomina Inventario, es aquel que lista todos los items de configuracion que tiene el repositorio con su estado en un momento de tiempo. Se puede listar la cantidad de solicitudes de cambio en un determinado periodo de tiempo, listar el contenido de una linea base, listar cuantas lineas bases se tienen para un determinado proyecto.

#### SCM y Desarrollo Agil
La auditoria es la que mas se cuestiona, las demas siempre se deben realizar en un proyecto de desarrollo agil. Lo unico que se debe acordar antes de comenzar es de que manera se va a aplicar la Gestion de Configuracion, pero siempre deberiamos hacerla. Es responsabilidad de todo el equipo.

---

### Testing de Software

#### Que es testing
Porceso destructivo cuyo objetivo es encontrar defectos, asumiendo que una porcion de software por mas trivial que sea, va a tener defectos, con el objetivo de resolverlos contribuyendo a la calidad del software.

#### Cuanto testing es suficiente
Es imposible poder garantizar la prueba de todas las combinaciones posibles.
Existen diferentes criterios para determinar cuando dejar de hacer testing
- Goog enough: Cortar cuando la cantidad de defectos encontrados lleguen a cierto umbral
- Economico: Cortar cuando se haya consumido el presupuesto definido a ejecutar pruebas

#### Error vs Defecto
Ambas son fallas, pero dependera del momento en el que se encuentren o producen para determinar si es un error o un defecto.
- Error: Es cuando la falla es encontrada durante la misma etapa que la origino, por ej: encontramos una falla de implementacion en esa etapa estamos frente a un error.
- Defecto: Es cuando la falla trasciende a la etapa en la cual se origino, por ejemplo, aparece en etapa de produccion, pasa a ser un defecto.

El objetivo del testing es encontrar defectos, ya que es una actividad realizada posteriormente a la implementacion y brinda una retroalimentacion a la misma con el objetivo de corregir los mismos.

#### Proceso del Testing

digraph {
  compound=true
  rankdir=RL
  node [ fontname="Source Sans Pro", fontsize=30];
  edge [ fontname="Source Sans Pro", fontsize=12 ];

  subgraph {
     concentrate=true
    a [label="Planificacion y Control"] [shape=box]
    b [label="Analisis y Diseño"] [shape=box]
    c [label="Ejecucion"] [shape=box]
    d [label="Evaluacion y Reportes"] [shape=box]
    a -> b  [dir="back"]
    b -> c  [dir="back"]
    c -> d  [dir="back"]
  }
}

- Analisis y Diseño: Etapa en la que se formulan los casos de prueba que son los artefactos por excelencia del testing como disciplina y que van a servir como guia a la ejecucion de las pruebas para luego tomar una retroalimentacion en base a los reportes

#### Niveles de Testing

- Testing Unitario (Desarrollador): El objetivo del testing unitario no es encontrar defectos a diferencia de lo que indica la disciplina ya que se desarrollan durante la implementacion.
No buscan encontrar errores, proveen un mecanismo de verificacion de la comprension de la funcionalidad que se esta implementando.

- Testing de Integracion (Tester): Busca defectos. Orientado a probar interfaces (no graficas), a nivel de fronteras o uniones entre diferentes componentes en el producto de software. Prueba las integraciones entre los componentes.

- Testing de Sistema (Tester): Se prueba una funcionalidad en su totalidad. Ejecutar cierto camino, con ciertas entradas, caracteristicas para poder si el resultado obtenido coincide con el resultado esperado. Pruebas hechas en funcionalidades ya implementadas.

- Testing de Aceptacion (PO en agile/Usuario/Cliente): El objetivo no es encontrar defectos ya que a esta altura no deberia haber defectos, si no, capacitarlo en la funcionalidad que esta implementada o generar una aproximacion al entorno productivo.

**Casos de prueba:** Artefacto por excelencia del testing, que contendra un conjunto de condiciones/pasos que se deben ejecutar para poder garantizar que el resultado obtenido sea o no igual al esperado y de esa manera encontrar defectos.
Para ello, vamos a diseñar casos de prueba de manera inteligente y economica, realizando la menor cantidad de casos de prueba posibles para maximizar la cantidad de defectos encontrados. Tenemos dos estrategias para cumplirlo:

- Caja Blanca: Podemos ver el detalle de la implementacion de la funcionalidad, vamos a disponer del codigo y vamos a poder diseñar nuestro caso de prueba para poder garantizar la **cobertura**. Es decir por ejemplo, cubrir todos los *if* todos los *else*, todas las ramas de ejecucion. El nombre de caja blanca hace referencia a que yo conozco la estructura interna y por lo tanto puedo guiar el caso por donde yo quiera.

- Caja Negra: A diferencia del anterior, yo no conozco la estructura interna de la implementacion, por lo que solo voy a analizar en terminos de entradas y salidas. Identificar cuales son las diferentes entradas que una funcionalidad puede tener, elegir los valores para ejecutarla, y finalmente comparar las salidas obtenidas con las que esperaba tener. Entradas vs Salidas.

#### Metodos de caja negra:

- Basado en especificaciones
- Particion de equivalencias:
1. Analizar cuales son las diferentes condiciones externas que van a estar involucradas en una funcionalidad, tanto entradas como salidas posibles.
2. Para cada condicion externa, analizo cuales son los subconjuntos de valores posibles que pueden tomar cada una de las condiciones externas que producen dentro de ese mismo subconjunto un resultado equivalente *(Definicion de particion de equivalencia)*. Pueden ser rangos de valores continuos, valores discretos, seleccion simple o multiple.
- Analisis de valores limites (Particularidad/Variante de la particion de equivalencias): Plantea que la mayor cantidad de los defectos se encuentran en los extremos de los intervalos. Lo que cambia ahora, es que a la hora de escribir el caso de prueba, en vez de escribir cualquier valor de la particion de equivalencia, tomaremos uno que se encuentre proximo a los extremos.
- Basados en la experiencia
- Adivinanza de defectos
- Testing exploratorio

Cada una tiene sus pros y sus contras, por lo que lo optimo seria encontrar una combinacion entre ambas tecnicas que nos permita maximizar la cantidad de defectos encontrados

##### ++Descripcion de casos de prueba++
Prioridad:
- Alta: Aquellos casos de prueba que dirigen a escenarios de "caminos felices"
- Media: Combinaciones de valores que puedan ejecutarse bajo ciertas condiciones que producen alguna falla
- Baja: Todas aquellas validaciones relacionadas a formato o a "no ingresa valor"

Nombre: Debe describir de forma clara el escenario que estamos probando

Precondiciones: Conjunto de caracteristicas que tiene que tener mi contexto para poder llevar a cabo este caso de prueba en particular

Pasos: Conjunto de operaciones ordenadas y enumeradas para conseguir un resultado esperado en las cuales el formato de escritura es: "El ROL ejecuta cierta accion"

Resultado esperado: Salida que deberia tener el sistema en la ejecucion de ese caso de prueba en especifico con esas entradas.

#### Metodos de Caja Blanca
**Coberturas**
- ++De enunciados o caminos basicos:++ Buscar garantizar que todos los caminos independientes que tiene mi funcionalidad, seran recorridos al menos una vez. Con esta cobertura, podemos decir que garantizamos que nuestro codigo ha sido ejecutado pasando por todos los caminos indepentientes. Se requiere poder representar la ejecucion mediante grafos/diagramas de flujo, se calcula la complejidad ciclomatica. A partir del grafo se generan casos de prueba.
Complejidad: $M = E-N + 2P$
Siendo:
M = Complejidad ciclomatica
E = Numero de aristas del grafo
N = Numero de nodos del grafo
P = Numero de componentes conexos, nodos de salida
- ++De sentencias:++ Buscar la cantidad minima de casos de prueba que me permiten evaluar/recorrer, todas las sentencias. Una sentencia es toda asignacion de variable, invocacion de metodo, mostrar un mensaje, lanzar una excepcion, etc.
- ++De decision:++ Una decision es una estructura de control completa. Busca encontrar la menor cantidad de casos de prueba que abarquen todas las decisiones (los ifs), sin importar lo que tengan dentro. Tengo que cubrir todas las ramas de la decision, tanto para los true, como para los false.
- ++De condicion:++ Busca encontrar la menor cantidad de casos de prueba que nos permiten valuar cada una de las condiciones tanto en su valor verdadero como su valor falso, independientemente de por donde salga la decision. A este metodo solo le interesa garantizar que cada una de las condiciones sale por cada uno de los valores logicos (True, False), sin importar si la decision sale por verdadero o falso ni los cortocircuitos de los operadores.
- ++De cobertura de decision/condicion:++ Busca valuar las decisiones y las condiciones en cada uno de los valores logicos. Combinacion de ambas anteriores.
- ++De cobertura multiple:++ Tiene como objetivo hacer el combinatorio de los valores de verdad de todas las condiciones adentro de las decisiones, teniendo en cuenta los operadores logicos.
- Etc

### Design Thinking

Generar ideas innovadoras
Encontrar un equilibrio entre el pensamiento intuitivo y el analitico para generar ideas innovadoras pero a la vez posibles
Etapas del proceso:
1- Descubrimiento: Identificar las ideas
2- Ideacion:
3- Generacion de prototipos: Pruebas de concepto
4- Resultado final: MVP

### Retrospectivas
Reuniones que se realizan al final de un periodo de trabajo, regularmente de forma usual luego de una iteracion y/o release.
El objetivo de las restrospectivas es analizar el pasado para mejorar el futuro. Visto en el concepto de SCRUM como una reunion de retrospectiva luego de cada Sprint. Es la ultima actividad a realizar, incluso luego de la demo. Tambien son utilizadas en el contexto de procesos definidos.
Participantes de una retrospectiva: Developers, PO y Scrum Master.
Quienes NO deberian participar: Jefes, lideres, para poder hablar libremente en esa reunion de retrospectiva.

#### Estructura de la retrospectiva
- Preparar el escenario
- Reunir Datos:
- Generar Ideas: Una vez reunidos los datos, el equipo evalua que hacer con la informacion resultante
- Decidir que hacer: Resultados medibles, que hizo que no se hizo.
- Cerrar la Retrospectiva: Retrospectiva de la retrospectiva. Tomar feedback para una proxima retrospectiva mejor