Pressman - Ejercicios Capítulo 15

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 6

TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE ORIZABA

Equipo “TUX”
González Antonio Luis Alfonso (17011160)

Ingeniería en Sistemas Computacionales


6° semestre
Ene – Jun 2020

FUNDAMENTOS DE INGENIERÍA DE SOFTWARE

Observaciones:
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------

Calificación:

________________________ ________________________
Firma de alumno Firma de docente
Contenido

Introducción ........................................................................................................................................ 3
Capítulo 15 – Preguntas ...................................................................................................................... 4
Bibliografía .......................................................................................................................................... 6

2
Introducción
De manera breve, se repasan los temas vistos en el capítulo 15 del libro “Ingeniería
de Software, enfoque práctico” de Pressman. Tiene como finalidad fortalecer la
lectura apoyado de preguntas y ejercicios.
Aclaración: Ejercicios están diferenciadas con negritas y respuestas es texto normal.

3
Capítulo 15 – Preguntas
15.1. Explique la diferencia entre un error y un defecto.

• Error: para denotar un problema de calidad descubierto por ingenieros de software


(o de otra clase) antes de entregar el software al usuario final (o a alguna actividad
estructural del proceso del software).
• Defectos: implican un problema de calidad descubierto después de haberse liberado
el software a los usuarios finales
15.2. ¿Por qué no puede esperarse a las pruebas para encontrar y corregir todos los
errores del software?
Cuando se desarrolla un software siempre van a ir apareciendo errores a lo largo de la
creación e ir resolviéndolos conforme se avanza es la mejor opción que esperar hasta las
pruebas, ya que esto tomaría más tiempo y dinero.
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?

Se supone que en cada etapa de prueba se detecta y corrige 50% de todos los
errores de entrada sin que se introduzcan nuevos errores (suposición optimista).
Diez defectos preliminares de diseño se amplifican a 94 errores antes de que
comiencen las pruebas. Se liberan al campo 12 errores latentes (defectos).
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?

En caso de que el 60% de eficacia se le aplique a todas las fases: al público saldrán
6 errores.
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 en el punto 15.3 es de 12, esto multiplicado por 4800 es


$57, 600. En el punto 15.4 son 6 errores dando un total de $28, 800.
En total se ahorraron $28, 000.

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

En la figura se refleja el esfuerzo y el tiempo que se dedica de acuerdo a si se


realizan revisiones, pruebas, correcciones y si ninguna de estas se realiza nos deja
una conclusión, que las revisiones no nos quitan tiempo si no que nos 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é.
Verificar que el software que se revisa cumple sus requerimientos.
Es importante validar este punto ya que si no se cumple con los requerimientos previamente
establecidos de nada va a servir que el producto funcione a la perfección si no está hecho
para lo que s pidió por adelantado.
15.8. ¿Se le ocurren algunos casos en los que una verificación de escritorio genere
problemas en lugar de beneficios?

Si, cuando se identifican erróneamente problemas o la prioridad en que deben


solucionarse, ya que al ser una revisión informal da menos eficacia que una revisión
formal.
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?
Los participantes que no suelen prepararse no entran en contexto, no aportan ideas o lo
poco que llegan a aportar es inservible o fuera del tema. En el caso de ser líder y observar
esa situación le recomendaría que se tome unos minutos aparte para que lea un poco sobre
el tema y poder aportar alguna idea o al menos comprender sobre lo que se está hablando
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é?
Revise al producto y no al productor. Este es un punto a tomar en cuenta en el ámbito
empresarial, no te enfoques en quién hace el producto, sino cómo lo hace, la manera en
qué trabaja, al final un buen producto es lo que importa.

5
Bibliografía
Roger S. Pressman, P. (2010). Ingeniería del software. En P. Roger S. Pressman, Ingeniería del
software, un enfoque práctico (pág. 805). México: Mc Graw Hill.

También podría gustarte