INGENIERÍA DEL SOFTWARE: UN ENFOQUE

PRÁCTICO

Autor Roger S. Pressman

LAZCANO PÉREZ DIANA VANESSA

RESPONDER PROBLEMAS Y PUNTOS POR EVALUAR A PARTIR 14.1 HASTA 14.12. CAP. 14. TEXTO INGENIERÍA
DEL SOFTWARE: UN ENFOQUE PRÁCTICO; AUTOR ROGER S. PRESSMAN

14.1. DESCRIBA CÓMO EVALUARÍA LA CALIDAD DE UNA UNIVERSIDAD ANTES DE INSCRIBIRSE.

Se evalúa el número de aspirantes que entrar en la universidad, las diversas carreras que
ofrece como posgrados, las condiciones de las instalaciones, así como recursos
bibliográficos, movilidad, actividades extra como culturales como deportivas.

¿Cuáles factores serían importantes?

La disponibilidad de entrar a la carrera deseada, la movilidad para llegar a ella, la relación

laboral.

¿Cuáles tendrían importancia crítica?

La obtención de un lugar a la universidad, el costo, la actualización de los académicos.

14.2. GARVIN [GAR84] DESCRIBE CINCO PUNTOS DE VISTA DISTINTOS SOBRE LA CALIDAD. DÉ UN
EJEMPLO DE CADA UNO CON EL USO DE UNO O MÁS PRODUCTOS ELECTRÓNICOS CONOCIDOS CON
LOS QUE ESTÉ FAMILIARIZADO.

El punto de vista trascendental: Al comprar un teléfono celular de la marca Apple

El punto de vista del usuario: Al adquirir una TV con Smart Tv y contiene otras aplicaciones a
un bajo precio.

El punto de vista del fabricante: La marca Apple con los sistemas de seguridad y privacidad
de sus usuarios.

El punto de vista del producto: La producción de teléfonos celulares donde cada marca
quiere superarse respecto a la competencia con la integración de las cámaras y resolución
de ellas.

El punto de vista basado en el valor: Los Smartphone resientes con nuevas actualizaciones
al lanzarse al mercado tienden a tener los precios más elevados.

14.3. CON EL USO DE LA DEFINICIÓN DE CALIDAD DEL SOFTWARE PROPUESTA EN LA SECCIÓN 14.2, DIGA
SI CREE POSIBLE CREAR UN PRODUCTO ÚTIL QUE GENERE VALOR MEDIBLE SIN EL USO DE UN PROCESO
EFICAZ. EXPLIQUE SU RESPUESTA.

La creación de un producto útil que genere valor medible sin el uso de un proceso eficaz,
en mi parecer es algo complicado ya que para generar un software de calidad es
importante realizar varias pruebas para eliminar el gran número de errores para obtener la
calidad deseada y tener mejores resultados.

1
14.4. AGREGUE DOS PREGUNTAS ADICIONALES A CADA UNA DE LAS DIMENSIONES DE LA CALIDAD DE
GARVIN PRESENTADAS EN LA SECCIÓN 14.2.1.

Calidad del desempeño: ¿El software no presenta fallas en su desempeño?, ¿El software no
requiere de instalar funciones extras para su uso?

Calidad de las características: ¿El software tiene características adecuadas para los
diferentes usuarios?, ¿El software puede realizar todas las funciones?

Confiabilidad: ¿El software es seguro para su funcionamiento?, ¿El software es capaz de

realizar sus funciones sin necesidad de terceros?

Conformidad: ¿El diseño del software puede adaptarse para diversos usuarios?, ¿Las
interfaces están diseñadas para el funcionamiento adecuado para el software?

Durabilidad: ¿El software cuenta con la función de ser actualizarla varias veces para su
funcionamiento?, ¿Al ser actualizada, es posible que no genere errores?

Servicio: ¿Se pueden dar avisos a los usuarios de posibles actualizaciones para el correcto
funcionamiento?, ¿Es posible revisar periódicamente el software para posibles
correcciones?

Estética: ¿El software está diseñado de manera que el usuario puede entenderle?, ¿El
software no está muy cargado de interfaces?

Percepción: ¿Qué software es mejor de Apple o Android?, ¿Si se actualiza el software de mi

computadora puede que sea una buena inversión?

14.5. LOS FACTORES DE CALIDAD DE MCCALL SE DESARROLLARON EN LA DÉCADA DE 1970. CASI TODOS
LOS ASPECTOS DE LA COMPUTACIÓN HAN CAMBIADO MUCHO DESDE ENTONCES, NO OBSTANTE LO
CUAL AÚN SE APLICAN AL SOFTWARE MODERNO. ¿QUÉ CONCLUSIONES SACA CON BASE EN ELLO?

Aunque hay bastantes cambios en la computación los puntos más importantes que siempre
se van a requerir para la calidad de un software va a hacer: corrección, confiabilidad,
eficiencia, integridad, usabilidad, facilidad de recibir mantenimiento. Ya que estas bases
nos encaminan a realizar software de alta calidad para la evolución de la computación.

2
14.6. CON EL EMPLEO DE LOS SUBATRIBUTOS MENCIONADOS EN LA SECCIÓN 14.2.3 PARA EL FACTOR DE
CALIDAD LLAMADO “FACILIDAD DE RECIBIR MANTENIMIENTO”, DE LA ISO 9126, DESARROLLE PREGUNTAS
QUE EXPLOREN SI ESTOS ATRIBUTOS EXISTEN O NO. CONTINÚE EL EJEMPLO PRESENTADO EN LA SECCIÓN
14.2.4.

¿Es posible analizar el software periódicamente?

¿Las interfaces pueden se cambiables ante otras prioridades?

¿Al realizar los cambios en la interfaz puede generar errores?

¿Puede ver variaciones en las interfaces?

14.7. DESCRIBA CON SUS PROPIAS PALABRAS EL DILEMA DE LA CALIDAD DEL SOFTWARE.

Mientras menos dedicación le inviertas a un software este no funcionará, pero si inviertes

demasiado tiempo, dinero y esfuerzo aún software este va a hacer inaccesible para el
público y también fallara, lo ideal es generar un software bueno sin necesidad de invertir
demasiado dinero pero a la vez que sea desarrollado correctamente pensando en las
necesidades de los usuarios.

14.8. ¿QUÉ ES UN SOFTWARE “SUFICIENTEMENTE BUENO”? MENCIONE UNA COMPAÑÍA DADA Y

PRODUCTOS ESPECÍFICOS QUE CREA QUE FUERON DESARROLLADOS CON EL USO DE LA FILOSOFÍA DE
LO SUFICIENTEMENTE BUENO.

Una de las compañías puede ser Apple ya que cada año traen al mercado un nuevo
Smartphone con nuevas funciones y a la vez de mayor costo.

14.9. CONSIDERE CADA UNO DE LOS CUATRO ASPECTOS DE LA CALIDAD Y DIGA CUÁL PIENSA QUE ES
EL MÁS CARO Y POR QUÉ.

Pienso que la Eficacia ya que al tener que hacer interfaces, distribuciones dando un estilo
a estos, se necesita de más inversión de tiempo como de dinero puesto que esto nos lleva
en pensar en materiales de almacenamiento.

3
14.10. HAGA UNA BÚSQUEDA EN WEB Y ENCUENTRE OTROS TRES EJEMPLOS DE “RIESGOS” PARA EL
PÚBLICO QUE PUEDAN ATRIBUIRSE DIRECTAMENTE A LA MALA CALIDAD DE UN SOFTWARE. COMIENCE
LA BÚSQUEDA EN HTTP://CATLESS.NCL. AC.UK/RISKS.

Las principales causas que incrementan el nivel de riesgo de un proyecto de software son:
a. Caer en alguno de los errores típicos.

b. Desarrollar sin metodología.

c. No tener una correcta estimación, evaluación y administración de riesgos.

Ejemplos de riesgos:

1. Que el contenido de la planeación y propuesta no sea realmente definido por el equipo,

sino que solo escriban lo que el cliente les dicta.

2. Hacer cronogramas muy optimistas, pensando en “el mundo ideal”.

3. Se omiten actividades en el cronograma que al final se tienen que hacer y terminan

impactando negativamente al proyecto.

4. La falta de conocimiento de una metodología o algún paso necesario para la ejecución

del proyecto.

5. La falta de un propietario o patrocinador del sistema que esté involucrado al 100%.

6. Desarrolladores ineficientes (no saben analizar, no saben programar, etc.)

7. Falta de organización del equipo de desarrollo.

8. Poca retroalimentación del usuario final.

9. Instalaciones de desarrollo no disponibles.

10. Falta de disponibilidad de herramientas.

14.11. ¿SON LO MISMO CALIDAD Y SEGURIDAD? EXPLIQUE SU RESPUESTA.

No, pero van de la mano, ya que para obtener seguridad en el software se requiere de una
cierta calidad en ello puesto al fallar en la calidad es fácil acceder y hacer modificaciones
que pueden generar errores fatales.

4
14.12. EXPLIQUE POR QUÉ ES QUE MUCHOS DE NOSOTROS UTILIZAMOS LA LEY DE MESKIMEN. ¿QUÉ
OCURRE CON EL SOFTWARE DE NEGOCIOS QUE CAUSA ESTO?

Lo que ocurre con ese software es que no son confiables en la mayoría de los casos aunque
a veces lo hacen para generar nuevas versiones y seguir vendiendo.