Preguntas oral del final Flashcards
(41 cards)
Espina de pescado.
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.
Atributos de calidad.
- Adecuación Funcional.
- Eficiencia de Desempeño.
- Compatibilidad.
- Usabilidad.
- Fiabilidad.
- Seguridad.
- Mantenibilidad.
- Portabilidad.
ISO25010 - Adecuación Funcional.
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.
ISO25010 - Eficiencia de Desempeño.
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.
ISO25010 - Compatibilidad.
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.
ISO25010 - Usabilidad.
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.
ISO25010 - Fiabilidad.
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.
ISO25010 - Seguridad.
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.
ISO25010 - Mantenibilidad.
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.
ISO25010 - Portabilidad.
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.
¿Qué y cuáles son las visiones de calidad? Decríbalas brevemente.
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.
¿Qué es SCRUM? ¿En que contexto de cynefin rinde mas?
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
Ceremonias de SCRUM.
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.
Roles de SCRUM. Describir: Team, Product Owner, Scrum master, Customer.
- 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”.
UCP
¿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
- Clasificar actores.
- Clasificar casos de uso (según complejidad).
- 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.
¿Cuándo es bueno agregar gente a un proyecto?
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.
¿Qué sucede a agregar más personas a un proyecto atrasado?
Si se agrega más personas a un proyecto atrasado hace que se retrase más. Esto es debido a que:
- Genera mucho trabajo de coordinación adicional justamente en un momento en donde el foco debe estar puesto en los entregables.
- El equipo no cuenta en ese momento con la calma necesaria para dar a las personas nuevas la capacitación que necesitan.
- La gente nueva puede cuestionar la metodología de trabajo utilizada y eso dañaría aún más la productividad.
¿Qué es un baseline?
¿Cómo puede modificarse?
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.
Auditorías.
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.
¿Cuál es el ciclo dorado? ¿Cómo es el proceso de estimar?
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”.
¿Cómo se realiza el control de la configuración? ¿Qué es el SCCB de SCM, quienes lo componen y por que es necesario?
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
- 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. - El cambio es evaluado y comparado contra los objetivos del proyecto.
- 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. - Si es aceptado, se replanifican las tareas a realizar y se le asigna recursos para resolverlo
- 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
Pruebas no funcionales. Decir tres y describirlas.
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.
¿Qué es la complejidad ciclomática? ¿Cómo lo relacionas con mantenimiento?
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.
¿Qué es el grado de cobertura en las pruebas de caja blanca?
– 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.
