Está en la página 1de 10

UNIVERSIDAD METROPOLITINA DE

HONDURAS CAMPUS SANTA ROSA DE COPAN

ASIGNATURA: Pruebas y Documentación de Software

ASUNTO: Actividad ll

DOCENTE: Ing. Germán Antonio Medina

INTEGRANTES:

Jose Rodolfo Espinoza Hernandez 202201575

JOSE RODOLFO ESPINOZA HERNANDEZ

Fecha 11-7-2023
PROBLEMAS Y PUNTOS POR EVALUAR

15.1. Explique la diferencia entre un error y un defecto.

❖ El error es una acción humana que produce un resultado incorrecto,


por ejemplo, un error de programación.

❖ El defecto en un componente o sistema es la causa por el cual el


sistema o componente no logra llevar a cabo su función específica.

15.2. ¿Por qué no puede esperarse a las pruebas para encontrar y corregir
todos los errores del software?

❖ En el contexto del proceso del software, los términos defecto y falla


son sinónimos. Los dos implican un problema de calidad
descubierto después de liberado el software a los usuarios finales,
otra actividad estructural del proceso del software.
15.3. Suponga que en el modelo de requerimientos se han cometido 10
errores y que cada uno se amplificará en un factor de 2:1 en el diseño, y
que se cometerán otros 20 errores de diseño adicionales que luego se
amplificarán en un factor de 1.5:1 en el código, donde se cometerán otros
30 errores adicionales. Suponga que todas las pruebas unitarias
encontrarán 30 por ciento de todos los errores, que la integración
descubrirá 30 por ciento de los restantes y que las pruebas de validación
hallarán 50 por ciento de los que queden. No se efectuarán revisiones.
¿Cuántos errores saldrán al público?
15.4. Vuelva a considerar la situación descrita en el problema 15.3, pero
ahora suponga que se realizan revisiones en los requerimientos, diseño y
código, con 60 por ciento de eficacia en el descubrimiento de todos los
errores en esa etapa. ¿Cuántos errores saldrán al público?
15.5. Estudie de nuevo la situación descrita en los problemas 15.3 y 15.4.
Si cada uno de los errores que salen al público tiene un costo de $4 800
por ser detectado y corregido, y hacer lo mismo para cada error
descubierto en la revisión cuesta $240, ¿cuánto dinero se ahorra por
efectuar revisiones?

❖ La cantidad de errores que salen al público en el punto 15.3 son de


20, por lo tanto, son 96000$ dólares en detectar y corregir
errores. En el punto 15.4 Los errores descubiertos en
requerimiento, pruebas y diseño, son un total de 51, por lo tanto,
son 12 240$ y salieron 7errores al público que equivale a
33 600$, se puede decir entonces que en total con las
revisiones y los errores que salieron al público hace un total de 45
845$. Se ahorraron 50,155$.

15.6. En sus propias palabras, describa el significado de la figura 15.4.

❖ El trabajo efectuado cuando se utilizan revisiones se refleja pronto


en el desarrollo de un incremento de software, pero esta inversión
temprana paga dividendos debido a que se reduce el esfuerzo
necesario para hacer pruebas y correcciones. De igual importancia
es que la fechade entrega del desarrollo con revisiones ocurre antes
que la que se hace sin revisiones. ¡Las revisiones no quitan tiempo,
lo ahorran!

15.7. ¿Cuál de las características del modelo de referencia piensa usted


que tiene el mayor efecto en la formalidad de la revisión? Explique por
qué.

❖ Un modelo de referencia para la formalidad de la revisión identifica


roles de las personas, planeación y preparación, estructura de la
reunión, enfoque de corrección y verificación.
15.8. ¿Se le ocurren algunos casos en los que una verificación de
escritorio genere problemas en lugar de beneficios?
❖ Ejecutar consultas grandes en horarios laborales podría afectar el
sistema de la empresa causando lentitud o volcamientos de la
memoria RAM del servidor.

15.9. Una revisión técnica formal es eficaz sólo si cada quien se prepara
por adelantado. ¿Cómo se reconoce a un participante que no se haya
preparado? ¿Qué haría si usted fuera el líder de la revisión?
❖ Cuando el participante no está siguiendo la normatividad que sigue
un proceso de calidad, lo primero que haría sería capacitarlo.

15.10. Al considerar todos los lineamientos para la revisión


presentados en la sección 15.6.3, ¿cuál piensa que sea el más
importante y por qué?

❖ Pienso que el más importante es el: Enuncié áreas de problemas:


pero no intente resolver cada uno. Una revisión no es una sesión
para resolver problemas. Es frecuente que la solución de un
problema la obtenga el productor, sólo o con ayuda de otra
persona.
PROBLEMAS Y PUNTOS POR EVALUAR

16.1. Algunas personas afirman que “el control de la variación es el


corazón del control de calidad”. Como todo programa que se crea es
diferente de cualquier otro programa, ¿cuáles son las variaciones que se
buscan y cómo se controlan?
❖ Lo que se busca con una evaluación es hacer un análisis algo
profundo para detectar las fortalezas y debilidades de cada
alumno; es decir se evalúa para hacer las cosas mejor en el
desarrollo educativo. Para resolver estos problemas o
variaciones y mejorar la Calidad, es necesario basarse en hechos
y no dejarse guiar solamente por el sentido común, la
experiencia o la audacia. Basarse en estos tres elementos puede
ocasionar que en caso de fracasar nadie quiera asumir la
responsabilidad. De allí la conveniencia de basarse en hechos
reales y objetivos. Además, es necesario aplicar un conjunto de
herramientas estadísticas siguiendo un procedimiento
sistemático y estandarizado de solución de problemas.

16.2. ¿Es posible evaluar la calidad del software si el cliente cambia


continuamente lo que se supone que debe hacerse?

❖ La calidad podría bajar si en lo que el cliente cambia, cambia la


estructura del software también diría que no porque para tener
calidad se siguen estándares.

16.3. La calidad y confiabilidad son conceptos relacionados, pero difieren


en lo fundamental por varias razones. Analice las diferencias.

❖ Formalmente la confiabilidad se define en términos del


comportamiento estadístico: la probabilidad de que el software
opere como es esperado en un intervalo de tiempo especificado.
16.4. ¿Un programa puede corregirse y aun así ser confiable? Explique
su respuesta.
❖ si ya que no se estaría modificando la base del programa si no
se estaría actualizando por así decirlo es decir si una vez fue
confiable lo seguirá siendo si se mantiene la calidad.
16.5. ¿Un programa puede corregirse y tener buena calidad? Explique lo
que responda.
❖ No necesariamente ya que al corregirse la calidad dependerá si
esa corrección no brinde un funcionamiento agradable.
16.6. ¿Por qué es frecuente que haya tensiones entre el grupo de
ingeniería de software y el del aseguramiento de la calidad? ¿Es
saludable eso?
❖ Porque según entiendo los aseguramientos tienen muchas
reglas y son quienes deciden si el programa es acto. Diría que
es sana ya que obliga a los programadores o ingenieros a
hacer un buen trabajo.
16.7. El lector tiene la responsabilidad de mejorar la calidad del
software en su organización. ¿Qué es lo primero que debe hacer? ¿Qué
es lo siguiente?
❖ Primero debe de inspeccionar toda la parte de documentación
y proceso del software para proceder a ejecutar pruebas.

16.8. Además de contar los errores y defectos, ¿hay otras características


cuantificables de software que impliquen calidad? ¿Cuáles son y cómo
podrían medirse directamente?

❖ Calidad funcional. Refleja en qué medida el software cumple con


o se ajusta a un determinado diseño, basado en requerimientos
funcionales. Éstos abarcan las actividades del software que
involucran procesamiento de datos de entrada.
❖ Calidad estructural. Refleja en qué medida el software cumple
con los requerimientos no funcionales, como rendimiento,
capacidad de mantenimiento o escalabilidad.
❖ Funcionalidad. Las funciones del software son aquellas que
buscan satisfacer las necesidades del usuario.
❖ Confiabilidad. La capacidad del software de mantener su
rendimiento bajo ciertas condiciones durante cierto período de
tiempo.
❖ Usabilidad. Basada en el esfuerzo necesario para utilizar el
software por parte de un grupo de usuarios.
❖ Eficiencia. Basada en la relación entre el nivel de rendimiento del
software y el volumen de recursos utilizado, bajo ciertas
condiciones.
❖ Capacidad de mantenimiento. Basada en el esfuerzo necesario
para realizar modificaciones específicas.
❖ Portabilidad. Basada en la capacidad del software para ser
transferido de un entorno a otro.

16.9. El concepto del tiempo medio para la falla del software es objeto de
críticas. Explique por qué.

❖ se calcula sumando el tiempo de funcionamiento total de los


productos que se están evaluando y dividiendo esa cifra por el
número de dispositivos.

16.10. Considere dos sistemas cuya seguridad sea crítica y que estén
controlados por computadora. Enliste al menos tres peligros que se
relacionen directamente con fallas del software.

❖ ­La computadora se apague o reinicie.


❖ ­Hackeo.
❖ ­deadlock o bloqueo de la muerte

16.11. Obtenga una copia de las normas ISO 9001:2000 e ISO 9000-3.
Prepare una presentación que analice tres requerimientos de ISO 9001 y
la forma en la que se apliquen en el contexto del software.

Pasos para una buena implementación de la Norma ISO 9001


• Identifica las razones por las que deseas obtener la
acreditación ISO 9001.

• Define la estrategia.

• Planifica los recursos.

• Identifica tus procesos.

• Identifica las necesidades de formación.

• Documenta.

• Implementa el SGC.

• Realiza auditoría.

También podría gustarte