fmarcelo77
Empleado del buffet
Sin estado :(
Ing. en Sistemas
Facultad Regional Buenos Aires
Mensajes: 1
Agradecimientos dados: 0
Agradecimientos: 25 en 1 posts
Registro en: May 2012
|
Mensaje: #1
[Ingeniería en Software][Aporte] Final 24/07/2012
Finales
Ingeniería de Software
Final Ingeniería en Software 24/07/2012
Calidad (Producto)
1. El modelo ISO 9126 puede transformar la calidad del producto en algo medible y tangible.
2. La visión de la calidad basada en el usuario está basada en los atributos planteados en la ISO 9126.
3. Según el modelo ISO 9126, la facilidad de mantenimiento contempla los atributos tolerancia a fallas y recuperabilidad.
Métricas
4. La complejidad ciclomática es adecuada para determinar la mantenibilidad del código.
5. La cantidad de falsos positivos sobre el total de incidentes es un indicador de la eficiencia de la prueba.
6. Cantidad casos de prueba ejecutados por tester es adecuada para medir productividad en la prueba.
SW Configuration Management
7. La misma versión de un IC determinado no puede estar presente en una o más líneas bases.
8. El SCCB tiene autoridad suficiente para rechazar un cambio a una línea base.
9. Una release de un producto puede coincidir con una baseline pero un baseline puede no coincidir con una release.
Riesgos
10. En la actividad de “planificación” del paradigma del SEI se propone estudiar los tiempos de ocurrencia.
11. En la actividad de ”análisis” se prioriza en función del grado de exposición y de la urgencia que demande la acción correctiva.
12. En la actividad de “planificación” del paradigma del SEI se definen los planes de Mitigación y Contingencia para todos los riesgos.
Estimaciones
13. Los FPs Permiten medir el tamaño del software en base a la funcionalidad definida en los requerimientos.
14. Los OPs son muy adecuados para estimar proyectos de mantenimiento de SW.
15. La técnica del Timebox Development permite estimar el tamaño y la duración del proyecto.
16. Los UCOs están basados en el enfoque del Object Points.
Testing
17. Dos fallas distintas detectadas pueden ser producidas por el mismo defecto.
18. Las condiciones de pruebas de aceptación del SW no se pueden comenzar a construir hasta que haya finalizado la construcción del código.
19. La cobertura de sentencia es la que nos asegura mayor completitud en las pruebas.
20. Las pruebas de aceptación de usuario deben asegurar la completitud de condiciones que se pueden derivar de las técnicas de caja negra y caja blanca.
Project Tracking
21. Si su proyecto tiene SPI (EV/PV) < 1, se deben tomar acciones correctivas para ajustar el Schedule del proyecto y finalizar a tiempo.
22. El costo actual (“actual cost”) me permite saber cuánto trabajo completé hasta el momento de la medición.
23. CPI (Cost Performance Index) positivo indica que el proyecto marcha de acuerdo con el cronograma establecido.
24. Wideband Delphi es una técnica para hacer el seguimiento de proyectos que tienen restricciones fuertes de calendario.
Quality Assurance
25. Las inspecciones permiten detectar incumplimientos de estándares.
26. El principal propósito de los peer reviews (revisión de pares) es remover los defectos en forma temprana y eficiente.
27. Durante una inspección formal de código se detectan fallas.
28. La función de SQA (Software Quality Assurance) debe cuidar que se cumpla con un testing con cobertura de todo el código de una aplicación.
SW Configuration Managment
29. En el marco de un proyecto de desarrollo puedo establecer la cantidad de baselines que desee.
30. Las auditorías de proceso verifican consistencia ente código y lo especificado en los requerimientos definidos.
31. Componentes de terceros deben ser considerados en las actividades de SCM.
Métricas
32. El método Goal-Question-Metric me permite realizar una correcta recolección de datos históricos para un programa de métricas.
33. Cantidad de métodos x clase es una medida de complejidad de código.
34. La complejidad cliclomática proporciona una medición cuantitativa de las complejidad lógica de un programa.
Calidad (Proceso)
35. El contenido en ambas representaciones de CMMI (Continua y por Estados) es la misma solamente está organizado de manera diferente.
36. El CMMI es un modelo que sirve para medir la calidad del software que una organización produce.
37. El Nivel 2 se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos.
38. Un nivel de madurez es un subconjunto de procesos de la organización que sirven de base para poder moverse al siguiente nivel en el modelo de madurez en el marco de un proceso de mejora continua.
Calidad
39. La visión de la manufactura está alineada con marcos de referencia como CMMI.
40. El costo de la calidad es la suma del costo derivado de las tareas de prevención de defectos (revisiones tempranas) mas el costo del testing y el retrabajo.
|
|
27-07-2012 20:37 |
|
fmarcelo77 recibio 25 Gracias por este postfmarcelo77 recibio 25 Gracias por este post
Agro (27-07-2012), Cheppak (27-07-2012), federicogk (28-07-2012), gonnza (29-07-2012), blito (29-07-2012), alexandermonday (29-07-2012), Harmonium (30-07-2012), marthita64 (22-10-2012), danicam (18-11-2012), martinbrout (19-11-2012), reDDevil (22-11-2012), mcTowers (25-11-2012), nituguivi (03-12-2012), xpabloxx (06-12-2012), SilvinaG (07-12-2012), Santz (15-12-2012), pablosreitano (16-12-2012), Mati Dumrauf (21-05-2013), matiasGorosito (21-05-2013), Maxter (16-07-2013), MSC (19-08-2013), calui (21-09-2013), Santos55 (14-07-2014), nanjiro (28-02-2015), DarkCrazy (18-02-2016)
|
reDDevil
Campeon del cubo Rubik
Al rojo vivo
Ing. en Sistemas
Facultad Regional Buenos Aires
Mensajes: 122
Agradecimientos dados: 12
Agradecimientos: 132 en 16 posts
Registro en: Feb 2010
|
Mensaje: #2
RE: [Ingeniería en Software][Aporte] Final 24/07/2012
Ayer Lunes 3-12-2012 tomaron este mismo final, idéntico.
Como estaba con tiempo pedí ver el exámen y traté de acordarme las respuestas 'oficiales'.
Además discutí un par que me parecía que estaban mal.
Puede que haya una sóla que le haya pifiado pero estoy 100% seguro de todas las demás (esto es porque tenía mal 8 respuestas y no me acuerdo bien cuál es la octava que me pusieron mal jaja).
Calidad (Producto)
1. El modelo ISO 9126 puede transformar la calidad del producto en algo medible y tangible. V
2. La visión de la calidad basada en el usuario está basada en los atributos planteados en la ISO 9126. F
3. Según el modelo ISO 9126, la facilidad de mantenimiento contempla los atributos tolerancia a fallas y recuperabilidad. F
Métricas
4. La complejidad ciclomática es adecuada para determinar la mantenibilidad del código. V
5. La cantidad de falsos positivos sobre el total de incidentes es un indicador de la eficiencia de la prueba. V
6. Cantidad casos de prueba ejecutados por tester es adecuada para medir productividad en la prueba. V
SW Configuration Management
7. La misma versión de un IC determinado no puede estar presente en una o más líneas bases. F
8. El SCCB tiene autoridad suficiente para rechazar un cambio a una línea base. V
9. Una release de un producto puede coincidir con una baseline pero un baseline puede no coincidir con una release. V
Riesgos
10. En la actividad de “planificación” del paradigma del SEI se propone estudiar los tiempos de ocurrencia. F
11. En la actividad de ”análisis” se prioriza en función del grado de exposición y de la urgencia que demande la acción correctiva. F
12. En la actividad de “planificación” del paradigma del SEI se definen los planes de Mitigación y Contingencia para todos los riesgos. V (esta fui a discutirsela porque en realidad hay riesgos que se aceptan ó atacan por lo que no se define ningún plan y me dieron la razón)
Estimaciones
13. Los FPs Permiten medir el tamaño del software en base a la funcionalidad definida en los requerimientos. F
14. Los OPs son muy adecuados para estimar proyectos de mantenimiento de SW. V (porque tiene en cuenta la reusabilidad del código, entre otros)
15. La técnica del Timebox Development permite estimar el tamaño y la duración del proyecto. F
16. Los UCOs están basados en el enfoque del Object Points. F
Testing
17. Dos fallas distintas detectadas pueden ser producidas por el mismo defecto. V
18. Las condiciones de pruebas de aceptación del SW no se pueden comenzar a construir hasta que haya finalizado la construcción del código. V (esta fui a discutirsela porque según el V-Model se puede empezar a diseñar los UAT luego de definir los requerimientos y me dijeron que tenía razón)
19. La cobertura de sentencia es la que nos asegura mayor completitud en las pruebas. F
20. Las pruebas de aceptación de usuario deben asegurar la completitud de condiciones que se pueden derivar de las técnicas de caja negra y caja blanca. F
Project Tracking
21. Si su proyecto tiene SPI (EV/PV) < 1, se deben tomar acciones correctivas para ajustar el Schedule del proyecto y finalizar a tiempo. V
22. El costo actual (“actual cost”) me permite saber cuánto trabajo completé hasta el momento de la medición. F
23. CPI (Cost Performance Index) positivo indica que el proyecto marcha de acuerdo con el cronograma establecido. F
24. Wideband Delphi es una técnica para hacer el seguimiento de proyectos que tienen restricciones fuertes de calendario. F
Quality Assurance
25. Las inspecciones permiten detectar incumplimientos de estándares. V
26. El principal propósito de los peer reviews (revisión de pares) es remover los defectos en forma temprana y eficiente. V
27. Durante una inspección formal de código se detectan fallas. F
28. La función de SQA (Software Quality Assurance) debe cuidar que se cumpla con un testing con cobertura de todo el código de una aplicación. F
SW Configuration Managment
29. En el marco de un proyecto de desarrollo puedo establecer la cantidad de baselines que desee. V
30. Las auditorías de proceso verifican consistencia ente código y lo especificado en los requerimientos definidos. F
31. Componentes de terceros deben ser considerados en las actividades de SCM. V
Métricas
32. El método Goal-Question-Metric me permite realizar una correcta recolección de datos históricos para un programa de métricas. F
33. Cantidad de métodos x clase es una medida de complejidad de código. V
34. La complejidad cliclomática proporciona una medición cuantitativa de las complejidad lógica de un programa. V
Calidad (Proceso)
35. El contenido en ambas representaciones de CMMI (Continua y por Estados) es la misma solamente está organizado de manera diferente. V
36. El CMMI es un modelo que sirve para medir la calidad del software que una organización produce. F
37. El Nivel 2 se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. F
38. Un nivel de madurez es un subconjunto de procesos de la organización que sirven de base para poder moverse al siguiente nivel en el modelo de madurez en el marco de un proceso de mejora continua. V
Calidad
39. La visión de la manufactura está alineada con marcos de referencia como CMMI. V
40. El costo de la calidad es la suma del costo derivado de las tareas de prevención de defectos (revisiones tempranas) mas el costo del testing y el retrabajo. V
.be positive B+
(Este mensaje fue modificado por última vez en: 08-12-2012 09:59 por reDDevil.)
|
|
04-12-2012 23:28 |
|
reDDevil recibio 13 Gracias por este postreDDevil recibio 13 Gracias por este post
Cheppak (04-12-2012), Agro (05-12-2012), xpabloxx (06-12-2012), SilvinaG (07-12-2012), Santz (15-12-2012), pablosreitano (16-12-2012), overkill23 (17-12-2012), Mati Dumrauf (21-05-2013), matiasGorosito (21-05-2013), gonnza (27-07-2013), MSC (19-08-2013), calui (21-09-2013), DarkCrazy (18-02-2016)
|