Autor Roger S.

Pressman

LAZCANO PÉ REZ DIANA VANESSA

INGENIERÍA DEL SOFTWARE: UN

ENFOQUE PRÁ CTICO
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.

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?

1
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.

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?

2
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.

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:

3
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.

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.