Preguntas oral del final

Question 1

Espina de pescado.

Answer 1

Es la representación de varios elementos (causas) de un sistema que pueden contribuir a un problema (efecto).
Es útil para la recolección de datos y es efectivo para estudiar los procesos y situaciones.
Es utilizado para identificar las posibles causas de un problema específico.
Ayuda a tener un mejora sobre la concepción común de un problema complejo.

Question 2

Atributos de calidad.

Answer 2

• Adecuación Funcional.
• Eficiencia de Desempeño.
• Compatibilidad.
• Usabilidad.
• Fiabilidad.
• Seguridad.
• Mantenibilidad.
• Portabilidad.

Question 3

ISO25010 - Adecuación Funcional.

Answer 3

Adecuación Funcional
Representa la capacidad del producto software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas, cuando el producto se usa en la condiciones específicas.
- Completitud Funcional.
- Corrección Funcional.
- Pertinencia Funcional.

Question 4

ISO25010 - Eficiencia de Desempeño.

Answer 4

Eficiencia de Desempeño
Esta característica representa el desempeño relativo a la cantidad de recursos utilizados bajo determinadas condiciones.
- Comportamiento temporal.
- Utilización de recursos.
- Capacidad.

Question 5

ISO25010 - Compatibilidad.

Answer 5

Compatibilidad
Capacidad de dos o más sistemas o componentes para intercambiar información y/o levar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software.
- Coexistencia.
- Interoperabilidad.

Question 6

ISO25010 - Usabilidad.

Answer 6

Usabilidad
Capacidad del producto software para ser entendido, aprendido, usado y resultar atractivo para el usuario, cuando se usa bajo determinadas condiciones.
- Capacidad para reconocer su adecuación.
- Capacidad de aprendizaje.
- Capacidad para ser usado.
- Protección contra errores de usuario.
- Accesibilidad.

Question 7

ISO25010 - Fiabilidad.

Answer 7

Fiabilidad
Capacidad de un sistema o componente para desempeñar las funciones específicadas, cuando se usa bajo unas condiciones y período de tiempo determinados.
- Madurez.
- Disponibilidad.
- Tolerancia a fallos.
- Capacidad de recuperación.

Question 8

ISO25010 - Seguridad.

Answer 8

Seguridad
Capacidad de protección de la información y los datos de manera que personas o sistemas no autorizados no pueden leerlos o modificarlos.
- Confidencialidad.
- Integridad.
- No repudio.
- Responsabilidad.
- Autenticidad.

Question 9

ISO25010 - Mantenibilidad.

Answer 9

Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas.

• Modularidad.
• Reusabilidad.
• Analizabilidad.
• Capacidad para ser modificado.
• Capacidad para ser probado.

Question 10

ISO25010 - Portabilidad.

Answer 10

Portabilidad
Capacidad del producto o componente de ser transferido de forma efectiva y eficiente de un entorno hardware, software, operacional o de utilización a otro.
- Adaptabilidad.
- Capacidad para ser instalado.
- Capacidad para ser reemplazado.

Question 11

¿Qué y cuáles son las visiones de calidad? Decríbalas brevemente.

Answer 11

Las visiones de calidad son:
- Trascendental: Relacionado con emocional. Ejemplo: me gusta al tacto cómo se siente un iPhone.
- Producto: Cualidades inherentes al producto. Ejemplo: cámara de 16 megapixels.
- Manufactura: Es la calidad en el proceso de fabricación. Ejemplo: en Mc Donalds de China la hamburguesa se hace igual que en Buenos Aires.
- Usuario: Es el uso que el usuario va a darle. Si vivo en el campo no me sirve un Audi tt.
- Valor: Es el valor que le da el usuario al producto.
Son distintas miradas para definir la calidad ya que esta depende del enfoque, por ejemplo, si se quieren captar requerimientos funcionales la visión trascendental no me sirve como parámetro de calidad, en cambio, la visión del usuario sí. Suelen utilizarse 2 o más al mismo tiempo. Cada una para distintas funciones.

Question 12

¿Qué es SCRUM? ¿En que contexto de cynefin rinde mas?

Answer 12

Un marco de trabajo para desarrollo ágil de software, dentro del cual se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente.
Se caracteriza por:
Basarse en una estructura de desarrollo incremental en lugar de la planificación y ejecución completa del producto.
Solapar las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

• Proyecto donde hay mucha incertidumbre.
• Cuando tenemos un contexto complejo.
• Ceremonias de SCRUM
• Roles de SCRUM

Question 13

Ceremonias de SCRUM.

Answer 13

Sprint Planning
Objetivo: Definir el Sprint Backlog.
Esta reunión se lleva a cabo al inicio de cada Sprint y debe dar respuesta a dos cuestiones:
- Qué se entregará al terminar el sprint.
- Cuál es el trabajo necesario para relizar el incremento de producto y cómo se realizará.
Al finalizar la reunión:
▪ Se compromete el Sprint Backlog
▪ Se asignan las user-stories comprometidas
▪ Se generan las tareas.

Daily meeting
Objetivo: Sincronizar el trabajo y detectar impedimentos.

Formato de la Ceremonia
Se realiza diariamente y no dura más de 15’. Cada miembro del equipo Scrum explica brevemente: ¿Qué hice para este proyecto desde la última reunión? ¿Qué pienso hacer hasta la próxima reunión? ¿Qué impedimentos tengo para cumplir mis compromisos?

Al finalizar la reunión:
▪ El equipo intenta remover los impedimentos.

Sprint Review
Objetivo: Revisar el incremento del producto y obtener feedback del negocio.
Verificar que esté completo el ciclo.
Participantes: Scrum Master, Equipo, Product Owner, Stakeholders.

Formato de la Ceremonia
▪ El equipo expone el objetivo del Sprint.
▪ Se muestran las funcionalidades desarrolladas.
▪ Se obtiene feedback del negocio.

Al finalizar la reunión: Se aprueban las características presentadas.
Una vez por sprint y al finalizar el sprint.

Retrospective
Objetivo: Revisar la forma de trabajo del último Sprint para mejora continua.

Formato de la Ceremonia
Se debe inspeccionar lo siguiente:
▪ Cosas que funcionaron bien.
▪ Cosas que no resultaron como esperábamos (y queremos mejorar).
▪ Propuesta de mejoras.
▪ Lecciones aprendidas.
▪ Acciones.

Al finalizar la reunión: Se obtienen las lecciones aprendidas y acciones para mejorar en el siguiente sprint.

Una vez por sprint y al finalizar el sprint.

Question 14

Roles de SCRUM. Describir: Team, Product Owner, Scrum master, Customer.

Answer 14

• Scrum master: dueño del proceso. Cuida al proceso y al equipo. Se asegura que el SCRUM se aplique correctamente.Elimina los obstáculos que impiden que se desarrolle el objetivo del sprint.
• Product owner: dueño de la definición “éxito” o “terminado” y del backlog. Define los objetivos de cada sprint y prioridades. Se asegura de que el equipo trabaje de forma adecuada desde la perspectiva del negocio.
• Team (equipo): Dueño del proceso de producción/ingenieril. Responsable de la creación del producto. Define colaborativamente cómo transformar el product backlog a un incremento de funcionalidad al final de la siguiente iteración.
• Stakeholders (Clientes, Proveedores, Vendedores, etc)
  Son las personas que hacen posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su desarrollo. Solo participan directamente durante las revisiones del “sprint”.

Question 15

UCP

Answer 15

¿Qué es?
Es un método de estimación de esfuerzo para proyectos de software, a partir de sus casos de uso. Requiere que sea posible contar el número de transacciones en cada caso de uso.

¿Para qué sirve?
Tiene como objetivo proveer un método simple de estimación adaptado a proyectos orientados a objetos.

Ventajas

• Los UCP se basan en casos de uso y se pueden medir muy temprano en el ciclo de vida del proyecto.
• UCP (estimación de tamaño) será independiente del tamaño, habilidad y experiencia del equipo que implementa el proyecto.
• Se encuentra que las estimaciones basadas en UCP son cercanas a las reales cuando la estimación es realizada por personas experimentadas.
• UCP es fácil de usar y no requiere análisis adicionales.
• Los casos de uso se utilizan ampliamente como método de elección para describir los requisitos. En tales casos, UCP es la técnica de estimación más adecuada.

Desventajas
- UCP se puede usar solo cuando los requisitos están escritos en forma de casos de uso.
- Depende de casos de uso bien redactados y orientados a objetivos. Si los casos de uso no están bien estructurados o de manera uniforme, es posible que el UCP resultante no sea preciso.
- Los factores técnicos y ambientales tienen un alto impacto en UCP. Se debe tener cuidado al asignar valores a los factores técnicos y ambientales.
- UCP es útil para la estimación inicial del tamaño total del proyecto, pero son mucho menos útiles para impulsar el trabajo de iteración a iteración de un equipo.
—–
Los Use Case Point tienen en cuenta: Casos de Uso, Transacciones de Casos de Uso y Actores.
—–
Entrada: Casos de uso. Salida: Use case points (o esfuerzo: UCP * CF).
Factores ambientales: bajan la estimación. Factores tecnológicos: suben la estimación.
Los Use Case Point tienen en cuenta: Casos de Uso, Transacciones de Casos de Uso y Actores.

Proceso

1. Clasificar actores.
2. Clasificar casos de uso (según complejidad).
3. Hallar:
   a. Peso no ajustado de los actores (UAW).
   b. Peso no ajustado de casos de uso (UUCW)
   c. Use Case Points no ajustados (UUCP).
   d. Factores de ajuste (Technical Complexity y Environmental).
   e. Use Case Points netos (UCP).

El número de Use Case Points de un producto depende de:
• La cantidad de casos de uso.
• La complejidad de dichos casos, según su cantidad de transacciones.
• Los actores que intervienen.
• Factores técnicos y ambientales.

Ojo: Pueden cambiar mucho las estimaciones xq ante mayor detalle del use case, más transacciones (más use case points). Hay estandarizar el nivel de detalle. La especificación debe incluir casos de uso bien definidos.

Factores de ajuste técnicos que pueden ser tenidos en cuenta para adecuar la estimación sin ajustar: Facilidad de integración, facilidad de instalar, facilidad de modificar, mantenibilidad, seguridad, reusabilidad, performance.

UCP. Un problema al estimar con Use Case Points:
Los analistas funcionales tienen distintos criterios para armar CU.

Question 16

¿Cuándo es bueno agregar gente a un proyecto?

Answer 16

La gente que se agrega debe tener experiencia en el tema, esté capacitada. Al inicio del proyecto. Cuando tengo tareas en paralelo, no independientes entre si, a las que no tenga ningún recurso asignado.

Question 17

¿Qué sucede a agregar más personas a un proyecto atrasado?

Answer 17

Si se agrega más personas a un proyecto atrasado hace que se retrase más. Esto es debido a que:

1. Genera mucho trabajo de coordinación adicional justamente en un momento en donde el foco debe estar puesto en los entregables.
2. El equipo no cuenta en ese momento con la calma necesaria para dar a las personas nuevas la capacitación que necesitan.
3. La gente nueva puede cuestionar la metodología de trabajo utilizada y eso dañaría aún más la productividad.

Question 18

¿Qué es un baseline?

¿Cómo puede modificarse?

Answer 18

Representa un estado de la configuración de un conjunto de ítems (IC) en el ciclo de desarrollo, que puede tomarse como punto de referencia para una siguiente etapa del ciclo.
- Sirven como punto de orientación para medir el avance del proyecto.
Se establece porque se verifica que esta configuración del ítem o conjunto de ítems satisface (n) algunos requerimientos funcionales o técnicos.

¿Cómo puede modificarse?
Las líneas base no se deben entender como algo estable a lo largo del proyecto, sino que se deberán actualizar cuando haya cambios importantes en el proyecto.

Question 19

Auditorías.

Answer 19

Realizar una verificación del estado de la configuración a fin de determinar si se están cumpliendo los requerimientos especificados.
La auditoría puede ser ejecutada con diferentes niveles de formalidad:
- Revisiones informales basadas en checklists.
- Pruebas exhaustivas de la configuración que son planificadas.

• Funcional: verifica el cumplimiento de requerimientos.
• Física: verifica la configuración del producto en cuanto a la estructura especificada.
• De Proceso: verifica se haya cumplido el proceso de SCM.

SCM - VoF? La auditoría de proceso se puede considerar como una actividad propia de QA.
V. Se puede considerar como una actividad propia de QA ya que indica que los componentes lleguen a producción siguiendo el proceso de cambio definido.

Question 20

¿Cuál es el ciclo dorado? ¿Cómo es el proceso de estimar?

Answer 20

Estimar -> Medir -> Registrar -> Comparar -> Analizar -> Calibrar -> Volver a estimar.

• Estimar: Comenzar x estimar el tamaño para derivar el esfuerzo y el costo.
• Medir: Mientras evoluciona el proyecto, medir el tamaño, el esfuerzo y costo incurrido.
• Registrar: Dejar claras las mediciones tomadas.
• Analizar: Razones de desvíos, supuestos que quizás variaron, temas no contemplados…
• Calibrar: Ajustar c/u de las variables y parámetros que intervienen en el proceso de estimación.
• Volver a estimar:
- El mismo proyecto pero ahora con más información que al comienzo del mismo.
- Nuevos proyectos con el proceso ajustado por la “calibración”.

Question 21

¿Cómo se realiza el control de la configuración? ¿Qué es el SCCB de SCM, quienes lo componen y por que es necesario?

Answer 21

Actividades
El control de la configuración consiste en establecer un procedimiento de control de cambios y controlar el cambio y la liberación de ICs a lo largo del ciclo de vida.

Objetivo
Asegurar que los ítems de configuración mantienen su integridad ante los cambios a través de:
- La identificación del propósito del cambio.
- La evaluación del impacto y aprobación del cambio.
- La planificación de la incorporación del cambio.
- El control de la implementación del cambio y su verificación.

Conceptos de Control de Cambios
➔ Se necesita controlar los cambios a los ítems de configuración estableciendo diferentes niveles de control.
◆ Control de versiones.
◆ Control de ítems que forman parte de líneas base.
➔ La complejidad del control de cambios surge de las necesidades de modificar archivos que son compartidos por diferentes personas y proyectos.
◆ Dos o más personas necesitan modificar el mismo artefacto.
◆ Dos o más proyectos trabajan sobre el mismo artefacto.
➔ Lo más importante: analizar el impacto del cambio, autorizarlo (o no) y realizar el seguimiento de los pedidos de cambio hasta su cierre.

La Solicitud de Cambio
• Debe estar registrada formalmente. Por ello la definición de un Formulario de Solicitud de Cambio es parte de la definición del proceso de CM.
• Esta solicitud tiene por objetivo registrar el cambio propuesto, quien lo propuso, la razón de porque el cambio fue solicitado y la urgencia del mismo (Establecida por el solicitante).
• También se utiliza para registrar la evaluación del cambio, complejidad, el análisis de impacto y las recomendaciones de los equipos.

SCCB - sw config control board
Está compuesto por perfiles del tipo con nivel de autoridad (change authority) y su función es aceptar o rechazar un cambio que ha sido solicitado.
SCCB son quienes velan porque el cambio no atente con la integridad del sw. Aceptan o no llevar adelante el cambio solicitado. Si consideran que los cambios pueden llegar a generar fallas lo suficientemente grandes para dejar trabado a todo el equipo, lo rechazan.
En proyectos pequeños puede ser una sola persona o el mismo líder, en proyectos más grandes puede estar conformado por muchas personas con muchas nivel de autoridad (change authority).
SCCB debería incluir un usuario representativo en su conformación.
El SCCB es quien tiene el governance del proceso de Control de Cambios.
Anotación audio azul: SCCB. Son muchas personas que por lo general hay dos puestos distintos.

Ejemplo de Proceso genérico de administración de cambios

1. Se solicita el cambio
   - Puede ser solicitado tanto por un usuario como un desarrollador. En general, solo se aceptan cambios de personas autorizadas a pedirlo.
2. El cambio es evaluado y comparado contra los objetivos del proyecto.
3. Un grupo de asesores evalúa el cambio y lo aprueba o rechaza
   - Se suele evaluar el impacto del cambio tanto en el producto como en la calendarización del proyecto.
   - Si se rechaza, se puede dejar como parte de una “Segunda Fase” del proyecto, o incorporarlo en una segunda iteración de desarrollo.
4. Si es aceptado, se replanifican las tareas a realizar y se le asigna recursos para resolverlo
5. El cambio implementado deberá ser revisado en auditorias.

La complejidad de la administración del cambio varía de acuerdo al proyecto. En proyectos pequeños, el pedido de cambio puede ser informal y desarrollarse rápidamente mientras que en proyectos más complejos puede haber comités de varias personas que evalúen el cambio

Question 22

Pruebas no funcionales. Decir tres y describirlas.

Answer 22

Volumen
Orientada a verificar a que el sistema soporta los volúmenes máximos definidos en la cuantificación de reqs.
– Capacidad de almacenamiento.
– Capacidad de procesamiento.
– Capacidad de transmisión.

Performance
– Orientada a verificar a que el sistema soporta los tiempos de respuesta definidos en la cuantificación de reqs. en las condiciones establecidas.
– Se evalúa la capacidad de respuesta con diferentes volúmenes de carga (x ej., demanda esperada, peaks de demanda, etc…).
– Ayudan a identificar “cuellos de botella” y causas de degradación.
– Se realizan de la mano de las de “volumen”.

Stress
Orientada a someter al sistema excediendo los límites de su capacidad definidos en la cuantificación de reqs.
– Capacidad de almacenamiento.
– Capacidad de procesamiento.
– Capacidad de transmisión.
Busca ver el comportamiento en términos de: Estabilidad, Disponibilidad y Manejo de Errores.

Question 23

¿Qué es la complejidad ciclomática? ¿Cómo lo relacionas con mantenimiento?

Answer 23

Complejidad Ciclomática
– Métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.

Cuenta el número de caminos independientes dentro de un fragmento de código y determina la cota superior del número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

• cantidad de caminos independientes.
• camino independiente: agrega un nuevo conjunto de sentencias de procesamiento o una nueva condición.
– Formas de calcularla
• número de regiones del grafo.
• V(g) = A - N + 2 (A = aristas, N = nodos).

Cuanto mayor sea la complejidad ciclomática, mayor será el esfuerzo que demanda realizar cambios (afectando la característica capacidad de ser modificado, sub-atributo de Mantenibilidad según 25000) y volverá más complejo el proceso de Depuración (complicando la capacidad de ser probado, otro sub-atributo de Mantenibilidad según 25000). Por lo tanto, la relación es DIRECTAMENTE proporcional al esfuerzo de mantenibilidad del código.

Question 24

¿Qué es el grado de cobertura en las pruebas de caja blanca?

Answer 24

– Cobertura de Sentencias
• Prueba c/instrucción.
– Cobertura de Decisiones
• Prueba c/salida de un “IF” o “WHILE”.
La cobertura de decisiones verifica que se evalúen todas las salidas de un if o while.
– Cobertura de Condiciones
• Prueba cada expresión lógica (A AND B) de los IF, WHILE.
– Prueba del Camino Básico
• Prueba todos los caminos independientes.
Se representa el flujo de control de una pieza de código a través de un grafo de flujo.

• ¿Qué diferencia a la cobertura de condición de la cobertura de la de decisión?
  La cobertura de decisión válida que todos lo caminos posibles, por ejemplo en un if o un while estén contemplados.
  La cobertura de condiciones incluye la cobertura de sentencias y decisiones, y además, evalúa todas las combiaciones de variables que dan valor a una condición. Ejemplo: if(A and B) evalúa qué pasa cuando A y B van tomando los distintos valores. También se evalúan funciones que retornan valores necesarios para la condición. Ejemplo: if(esMayorDeEdad(x)).
  Testing - VoF? La cobertura de sentencias es la más completa porque cubre el 100% de las sentencias.
  F. En la cobertura de sentencias se prueba cada instrucción. No asegura la completitud de los caminos, es decir, se pueden cubrir todas las sentencias pero no todos los caminos. Por lo tanto no se puede decir que es la más completa.
  Testing - VoF? En una prueba de caja blanca, la cobertura de camino básico es mayor que la de decisión.
  V. Cobertura de sentencias: prueba cada instrucción. No asegura la completitud. Puede cubrir todas las sentencias pero no todos los caminos.
  Cobertura de decisión: prueba cada salida de los if y los while. No cubre las condiciones. Garantiza que salió por verdadero o falso.
  Cobertura de condición: prueba cada expresión lógica de los if, while.
  Cobertura del camino básico: prueba caminos independientes.

Question 25

Cynefin.

Answer 25

Modelo que compara características de cinco dominios de complejidad diferentes: simple, complicado, complejo, caótico y desordenado.
Entendiendo en qué dominio (contexto operativo) estamos podemos:
• determinar qué tipo de framework conviene utilizar.
• tomar las decisiones adecuadas.

Los contextos simples y complicados: gestión basada en hechos. Suponen un universo ordenado, donde las relaciones de causa y efecto son perceptibles, y las respuestas correctas se pueden determinar en función de los hechos.
Los contextos complejos y caóticos: gestión basada en patrones. Están desordenados; no hay una relación inmediatamente aparente entre causa y efecto, y el camino a seguir se determina según los patrones emergentes.

Contexto Simple
• Observar, categorizar (el hecho), responder
• Existe una Best Practice o una regla para el hecho.
Significa que la situación es estable y existen reglas probadas para aplicar. Las Mejores Prácticas son métodos o técnicas superiores a cualquier otra alternativa que produce los mejores resultados que utilizando otros medios.
La relación entre causa y efecto es clara: si se realiza X, se espera Y.
En este domino se establecen los hechos, se categorizan y se responde con una regla o se aplica una mejor práctica (sense-categorize-respond).

Contexto Complicado
• Los líderes del proyecto detectan, analizan y responden (sense-analyze-respond) frente una situación.
• Existen múltiples respuestas correctas, Buenas Prácticas.
• Para responder se requiere análisis o experiencia, para ver qué good practice aplicar.
El dominio Complicado implica que la relación causa y efecto requiere análisis o experiencia. Las Buenas Prácticas son métodos o técnicas que pueden aplicarse según la decisión de un experto.
/* En el complicado tengo que hacer un análisis de alternativas, requiere más de un experto para poder tomar una solución. El experto nos ayuda a entender cuál es la solución.
Se evalúan los hechos, se analizan y se aplica una buena práctica . Es posible trabajar racionalmente hacia una decisión pero requiere un juicio refinado y con experiencia. */

Contexto Complejo
• Experimentar/explora, observar/analizar, responder (probe-sense-respond) al problema
• Existen Emerging Practices
• Se exploran soluciones (adaptativas). No es predecible el resultado de las acciones propuestas.
• El ámbito donde nos encontramos es desconocido y el cambio constante, NO predecible.
• No hay experiencia en la industria.
• No hay respuestas correctas.
En el dominio Complejo la relación causa y efecto solo puede ser decida en retrospectiva. Los Diseños Útiles e Informativos pueden desarrollarse. Se puede considerar experimentos para encontrar una solución a los problemas. Las soluciones son adaptativas.

Contexto Caótico
• Actuar, observar/analizar, responder (act-sense-respond).
• No hay tiempo de armar una prueba concepto, se actúa directamente.
• Cualquier Acción es la respuesta apropiada
• Se actúa para transformar el dominio en complejo
/* En el contexto caótico tenemos que tratar de buscar técnicas para salir del caótico lo antes posible.
Lo que pruebo no se si va a funcionar. Se tiene poco tiempo. Lo importante es estar alerta. Uno acciona e implementa esa solución, y ve después como reaccionó. Uno acá implementa y no se pone a pensar cuál es la mejor técnica. Ej: en un supermercado se cae el sistema de cajas.
En el dominio Caótico la relación causa y efecto es incierta. */

Question 26

Cynefin. Decir dos contextos y en cual de aplicaria una metodología agil.

Answer 26

Cuál de aplicaria una metodología agil: ( q creo q la rta es en complejo).

Question 27

Cynefin ejemplos

Answer 27

Simple

• Estás en tu coche y vas manejando. Se hace de noche. Es evidente que tenés que encender las luces.
• Una bombilla rota. Reconocemos que ya no se enciende y sólo hay una forma sensata de resolver el problema: reemplazarla.

Complicado

• Podemos saber que le pasa algo raro nuestro coche, pero necesitamos llevarlo a un mecánico para que diagnostique el problema.
• Construcción de una casa como un ejemplo. Analizando cuidadosamente las condiciones del suelo y los materiales y adoptando un método que ya ha demostrado su eficacia en otros proyectos, los constructores se asegurarán en última instancia de que el proyecto de construcción sea un éxito.

Complejo
- Por ejemplo, la selva tropical o los mercados (financieros) son complejos. Nunca seremos capaces de entender completamente qué es lo que sucede, y mucho menos predecir su comportamiento. Podemos “observar, intervenir con pequeños experimentos, y tratar de entender qué es lo que emerge a partir de estos”.

Caótico

• Se nos incendia la casa. No hay tiempo de pensar ni analizar.
• Un ataque terrorista crea un territorio caótico.

Question 28

V model. ¿Qué es V model?

Answer 28

V-Model
Es un modelo de ciclo de vida que indica que no hay necesidad de esperar a terminar de desarrollar todo para empezar a hacer los tests.
Puedo empezar a pensar a probar cuando tengo los requerimientos de usuario y eso ayude a desarrollar un producto menos ambiguo.
En una rama de la V están las distintas tareas de una fase del ciclo de desarrollo y del otro lado está la contraparte de testing que mapearía contra cada tarea.

Requerimientos -> Prueba de Sistema -> PAU
Especificación -> Prueba Funcional
Arquitectura -> Prueba de Integración
Diseño Detallado -> Prueba Unitaria.

Testing - VoF? La prueba de sistema permite verificar el cumplimiento de requisitos no funcionales.
V. Prueba del sistema en su conjunto y con el resto del sistema. Se prueba en un ambiente similar al real. Permite probar recuperación, seguridad, stress, rendimiento.

Question 29

Costos de calidad y costos de no calidad. ¿Qué harías para saber el costo de un proyecto?

Answer 29

Costo de la calidad: Costo de conformance (testing y prevención) + costo de non conformance (fallas internas previas al lanzamiento y fallas externas por-lanzamiento).

Costo de la NO CALIDAD
• Baja motivación de los equipos de trabajo/Duplicación de esfuerzos.
• Over-time constante/Re-trabajo constante (Mayor costo $$).
• Desgaste del equipo de trabajo.
• Imagen negativa ante el cliente.

Question 30

Dimensiones de un proyecto de software

Answer 30

• No se puede cumplir con todas a la vez !!

Enfoque de las 3 dimensiones (triple constraint)
Alcance → Costo → Tiempo
Enfoque de las 5 dimensiones
Alcance → Recursos → Costo → Tiempo → Calidad

Características de las dimensiones:
Driver: objetivo vital a lograr, tiene poco/nada de flexibilidad.
// No sería bueno ser flexible con eso. Por ej en un banco, pasar de 4 tipos de transacciones a 2 transacciones. Eso no está bueno.

Restricción: es una (o varias) dimensión del proyecto que se encuentra limitada por el contexto del mismo. Es poco o nada flexible. Por ejemplo: el presupuesto asignado al proyecto es de $xxxxxx y no más. No está bajo nuestro control directo y también tiene poco/nada de flexibilidad.
//Están fuera de mi control. Por ejemplo, no te podés pasar de tal fecha. Restricciones que no se negocian. No necesariamente son externas a mi empresa.

Grado de Libertad: Libertad para fijar objetivos. Existe Flexibilidad para manejar esta variable.

Question 31

¿Cómo se relaciona good enough con testing?

Answer 31

“Good Enough”: cierta cantidad de fallas no críticas es aceptable.

Cuando detengo la prueba
No hay una “única receta” y depende de cada situación en particular.
Algunos criterios pueden ser:
- Para exitosamente el conjunto de pruebas que fue diseñado
- “Good Enough ”: cierta cantidad de fallas no críticas es aceptable
- Cantidad de fallas detectadas es similar a la cantidad de fallas estimadas.

Question 32

¿Qué es QA y QC?

Answer 32

Relación de SCM con SQA (sw quality assurance)
SCM está relacionado muy de cerca con SQA. SCM ayuda a lograr SQA y , a su vez,algunos de los requerimientos específicos de SQA solicitan/prescriben actividades de SCM.
Definición de SQA- asegura que productos y procesos en el ciclo de vida del proyecto cumplan con requerimientos específicos , mediante la la planificación y la ejecución de un conjunto de actividades para proveer confianza suficiente de que la calidad está presente en la construcción del sw.
——————-
QA
Enfoque proactivo para prevenir defectos haciendo énfasis en el proceso usado en el desarrollo del producto, garantizando que lo propuesto en el plan de calidad se lleve a cabo.
- Asegura la calidad de los procesos utilizados para crear productos de calidad.’

QC
Proceso reactivo puntual encofaco en identificiar y corregir los defectos en el producto ya terminado antes de ser liberado o entregado al cliente final.
- QC es el proceso de probar la calidad de un producto.

Question 33

Testing
- Objetivo del testing.
- Definición de eficacia y eficiencia.
¿Por qué los falsos positivos afectan a la eficacia y a la eficiencia?

Answer 33

¿Qué persigue el testing?
Básicamente, encontrar fallas en el producto.
Hacerlo lo mas eficiente posible
* Lo mas rápido posible
* Lo mas barato posible
Hacerlo lo mas eficazmente posible
* Encontrar la mayor cantidad de fallas
* No detectar fallas que no son (falsos positivos).
* Encontrar las mas importantes.

Question 34

Integración Continua.

Answer 34

Integración Continua: Realizar integración de código al menos una vez por día o más, para minimizar problemas de código.
Ventajas
✓ No hay integraciones de días de trabajo.
✓ Mejora la visibilidad y la comunicación.
✓ Atrapar errores de integración complejos en forma temprana.
✓ Mayor rapidez para lanzar software al reducir problemas de integración.
✓ Fin del “en mi máquina funciona”.

Question 35

¿Cuáles son las visiones objetivas de la calidad? ¿Por qué son objetivas?

Answer 35

Manufactura y producto.
¿Por qué son objetivas?
Porque no dependen del usuario, sino que en si misma dan calidad o aseguran que tiene esos requisitos los productos ya sea porque pasaron por un proceso que al tener buenas prácticas genera un producto de calidad o que el producto en si mismo tiene atributos justificados, son medibles y dan calidad.

Question 36

Fallas en estimaciones - progreso vs esfuerzo.

Answer 36

Tiene que ver con que pase el tiempo no quiere decir que haya avanzado el proyecto porque si uno estima que el proyecto va a durar tanto tiempo y va a requerir este esfuerzo, a medida que pase el tiempo si esos recursos que yo invertí no hicieron que tenga más funcionalidad el proyecto, entonces el tiempo pasó, los recursos se consumieron pero el proyecto no avanzó, entonces nosotros tenemos que asegurar que a medida se invierten los recursos/tiempo/mano de obra, etc también se vaya ganando funcionalidad.

Question 37

Status & Accounting

Answer 37

Registrar y reportar la información necesaria para administrar la configuración de manera efectiva.
● Listar los ICs aprobados.
● Mostrar el estado de los cambios que fueron aprobados.
● Reportar la trazabilidad de todos los cambios efectuados al baseline.

Debe poder contestar 
● ¿Qué cambios se realizaron al sistema?
● ¿Cuándo cambió?
● ¿Quién lo cambió?
● ¿Qué cambió?
● Alcance del cambio
● ¿Quién aprobó el cambio?
● ¿Quién solicitó el cambio?
Se debe informar periódicamente con reportes a todos los grupos afectados.

Question 38

¿Qué es un IC?

Answer 38

Es cualquier elemento involucrado en el desarrollo del producto y que está bajo el control de la gestión de configuración. Para cada ítem se conoce información sobre su configuración (nombre, versión, fecha de creación, autor, entre otros).

Criterios válidos según CM para identificar IC

• Componentes que serán compartidos por 2 o más equipos.
• Componentes críticos del proyecto.
• Componentes que sufrirán cambios.
• Componentes que dependen unos de otros.
• Componentes de terceros.

Question 39

¿Cuáles son las ventajas de function point en comparación a planning poker?

Answer 39

TODO

Question 40

¿Cómo se hace un planning póker?

Answer 40

TODO

Question 41

¿Qué son los Classic Mistakes? ¿Cuáles son sus grupos? Nombrar algunos.

Answer 41

Los Classic Mistakes son los errores que se han cometido con tanta frecuencia, por tanta gente, que las consecuencias de cometer estos errores deben ser predecibles y los errores de los mismos deben ser evitables.

Se subclasifican en 4 categorías: Personas, Proceso, Producto y Tecnología.

1. Overly optimistic schedules (cronogramas muy optimistas)
2. Unrealistic expectations (expectativas poco realistas)
3. Excessive Multitasking (multitasking excesivo)
4. Shortchanged QA (escatimar en aseguramiento de calidad)
5. Wishful Thinking (ilusiones)
6. Visión poco clara del proyecto.
7. Confundir estimaciones con objetivos.
8. Oficinas ruidosas y abarrotadas.