Nothing Special   »   [go: up one dir, main page]

Práctica de Control de Calidad de Software

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 3

PRCTICA DE CONTROL DE CALIDAD DE SOFTWARE

ESTUDIANTE: Rogelio Roman Flores


SEMESTRE: X
ESCUELA PROFESIONAL: Ingeniera de sistemas
1. Qu proponen los factores de calidad de McCall en comparacin con los
factores de calidad que se proponen en ISO 9126?
Factores de la calidad de McCall
Confiabilidad
Usabilidad
Eficiencia
Facilidad de recibir mantenimiento
Portabilidad

Factores de la calidad ISO 9126


Confiabilidad
Usabilidad
Eficiencia
Facilidad de recibir mantenimiento
Portabilidad

Los factores de calidad que propone la ISO 9126 tambin propone McCall. Que
ambos coinciden no solo en la definicin del termino de cada factor sino en el
propsito que cada factor tiene para medir la calidad del software.
2. Explique cul es el dilema de la calidad de software en general.
El problema sobre la calidad del software normalmente se presenta cuando los
desarrolladores estn bajo la presin de cumplir las propuestas del cliente,
hacen que no se retrase el proyecto y obvian la calidad del software.
Ley de Meskimen:
Nunca hay tiempo para hacerlo bien, pero siempre hay tiempo para
hacerlo otra vez. Mi consejo es: tomarse el tiempo para hacerlo bien
casi nunca es la decisin equivocada.
3. Cules son los mtodos y tcnicas de administracin de proyectos que
se utilizan en la ingeniera software y por qu son importantes?
Mtodos:
1) Planear
2) Organizar
3) Dirigir
4) Monitorear
5) Controlar
Tcnicas:
1) Un gerente de proyecto usa estimaciones para verificar que las fechas
pueden cumplirse.
2) Se comprenden las dependencias de las actividades programadas y el
equipo resiste la tentacin de usar atajos.
3) La planeacin del riesgo se lleva a cabo de manera que los problemas no
alienten el caos, entonces la calidad del software se ver influida de
manera positiva.
Son importantes porque ayudan a asegurar la calidad que va brindar a los
usuarios finales.

4. Cmo se puede lograr el aseguramiento de la calidad?


Para lograr un software con calidad implica en utilizar las metodologas o
procedimientos estndares para el anlisis, diseo, programacin y prueba del
software que permitan unificar la filosofa del trabajo.
5. Explique brevemente los enfoques utilizados en el aseguramiento de la
calidad de software.
Calidad de los requerimientos. Para empezar a desarrollar un software hay
que asegurarse de definir bien todos los requerimientos pertinentes a dicho
software.
Calidad del diseo. El diseo del software debe cumplir con los
requerimientos tal como se estableci en el comienzo del desarrollo del
software.
Calidad del cdigo. La escritura del cdigo debe ser legible y cumplir con los
estndares locales de codificacin. Para que facilite el mantenimiento cuando
se requiera.
Eficacia del control de calidad. Un software de alta calidad debe emplear
ptimamente los recursos del sistema.
6. Explique detalladamente como se realizan las pruebas para el software
convencional con respecto a:
a) Prueba de caja blanca
La prueba de caja blanca se realiza en la estructura interna del software, es
decir hacer las pruebas en cada estructura de cdigo fuente (datos internos,
rutas lgicas, bucles, etc). As todo el detalle de cdigo se pone a prueba a fin
de garantizar su validez.
b) Prueba de estructura de control
Realiza la prueba de estructuras de control mejorando ampliamente la calidad
de la prueba de caja blanca.
- La prueba de condicin (0<i1) se enfoca en la prueba de cada condicin
del programa.
- La prueba de flujo de datos selecciona caminos de prueba de un programa
que contenga sentencias if o bucles anidados.
- Prueba de bucles (simples, anidados, concatenados, no estructurados) es
una tcnica de prueba de caja blanca que se enfoca exclusivamente en la
validez de los constructos bucle.
c) Prueba de caja negra
Se enfoca en realizar las pruebas de todos los requerimientos funcionales de
un programa con el fin de encontrar errores en las categoras siguientes:
- Funciones incorrectas o faltantes
- Errores de interfaz
- Errores en las estructuras de datos o en el acceso a bases de datos
externas
- Errores de comportamiento o rendimiento
- Errores de inicializacin y terminacin.

d) Prueba basada en modelo

Realiza la prueba en el comportamiento de un programa, que utiliza los


diagramas UML como informacin base para hacer las pruebas. Y consta en
cinco pasos:
- Analizar un modelo de comportamiento existente para el software o crear
uno
- Recorrer el modelo de comportamiento y especificar las entradas que
forzarn al software a realizar la transicin de estado a estado.
- Revisar el modelo de comportamiento y observar las salidas esperadas,
conforme el software realiza la transicin de estado a estado.
- Ejecutar los casos de prueba.
- Comparar los resultados reales y esperados y adoptar una accin
correctiva segn se requiera.
e) Prueba para entornos, arquitecturas y aplicaciones especializadas
- Pruebas de interfaces grficas de usuario: por el gran nmero de
permutaciones asociadas con las operaciones de la GUI, la prueba de GUI
debe abordarse usando herramientas automatizadas.
- Prueba de arquitecturas cliente-servidor: se realiza en tres niveles.
1) Las aplicaciones cliente individuales se prueban en un modo
desconectado; sin considerar la operacin del servidor ni la red
subyacente.
2) El software cliente y las aplicaciones servidor asociadas se prueban en
concierto, pero las operaciones de red no se revisan de manera
explcita.
3) Se prueba la arquitectura cliente-servidor completa, incluidos la
operacin de red y el rendimiento.
- Documentacin de prueba y centros de ayuda: esta prueba se realiza en
dos fases. Revisin tcnica que examina el documento en su claridad
editorial, prueba en vivo usa la documentacin en conjunto con el programa
real.
- Prueba para sistemas de tiempo real: se realiza la prueba cuando el
programa est en operacin. Pero las pruebas no son efectivas, porque el
tiempo limita la prueba. Aunque no ha evolucionado mucho los mtodos
generales de diseo de casos de prueba para sistemas de tiempo real. Sin
embargo, se propone una estrategia en cuatro pasos:
1) Prueba de tareas
2) Prueba de comportamiento
3) Prueba intertarea
4) Prueba de sistema

También podría gustarte