Actividad 1 Unidad 3: “Relacionar modelos de calidad de software clásicos y actuales”. Nombre del Facilitador: Guadalupe Heriberto Rangel Robles. Nombre del alumno: Paulo C. Casillas Martínez. Se analiza y debate en forma colaborativa los modelos de McCall y Boehm, indicando la importancia y relación con el desarrollo de los modelos de calidad de software actuales. Universidad Abierta y a Distancia de México Carrera: Ingeniería en Desarrollo de Software. 9no.Cuatrimestre Materia: Modelos de calidad de software.
Grupo: DS-DMCS-1402C-001 03/08/2014
1
Índice. Instrucciones. ............................................................................................................................ 3 RELACIONAR MODELOS DE CALIDAD DE SOFTWARE CLÁSICOS Y ACTUALES. ............................. 4 Caso de estudio. .................................................................................................................... 4 Identifica en el caso las fases de la evaluación de la calidad del software: requerimientos o requisitos, factores de calidad y criterios de evaluación. ......................................................... 7 Análisis del caso de estudio....................................................................................................... 7 Requerimientos funcionales: ................................................................................................ 7 Factores y criterios de calidad modelo McCall en el caso de estudio................................... 8 Factores y criterios de calidad modelo Boehm en el caso de estudio. ................................. 9 Factores y criterios de calidad modelo actual en el caso de estudio. ................................... 9 Comparación entre los modelos e identificación de la influencia de los modelos clásicos en los modelos actuales. .............................................................................................................. 10 Conclusiones. .......................................................................................................................... 11 Bibliografía .............................................................................................................................. 12
2
Instrucciones. Actividad 1. Relacionar modelos de calidad de software clásicos y actuales. El propósito de esta actividad es que analices y debatas en forma colaborativa los modelos de McCall y Boehm e indiques la importancia y relación con el desarrollo de los modelos de calidad de software actuales más comunes. Para ello, es necesario que recuperes algunos de los proyectos realizados en tus asignaturas previas o investigues un caso de desarrollo de software. Tu Facilitador(a) te hará llegar las instrucciones, una vez que cuentes con un proyecto de software y las instrucciones de tu Facilitador(a), realiza los siguientes pasos:
Identifica en el caso las fases de la evaluación de la calidad del software: requerimientos o requisitos, factores de calidad y criterios de evaluación. Identifica los elementos que correspondan al modelo de calidad indicado. Integra la información en un organizador de contenido (esquema, tabla, gráfica, etcétera). Envía la información a tu Facilitador(a) a su correo institucional o repositorio que te indique. Ingresa al foro y participa con base en las instrucciones de tu Facilitador (a) Lee y analiza las participaciones de mínimo dos de tus compañeros. Ingresa una segunda participación con tus conclusiones basándote en la participación de tus compañeros incluyendo tu propia aportación.
*No olvides, consultar el documento Criterios de evaluación de las actividades de la Unidad 3 y la Rúbrica de participación en foros para conocer los parámetros de esta actividad. Para el desarrollo de esta actividad es necesario recuperar algunos de los objetos desarrollados en la asignatura Programación .NET II o Programación NET III, un proyecto de alguna otra asignatura o alguno que investiguen, una vez que el alumno cuente con un ejemplo de desarrollo de software, se requiere que indique al alumno que deberán integrar en forma individual en un organizador gráfico las características principales de los siguientes modelos, ejemplificando con su ejemplo de desarrollo de software: Grupo 1: Modelo de McCall. Grupo 2: Modelo de Bohem. Grupo 3: Modelo actual o reciente. La participación en el foro se realizará en dos etapas que se verán reflejadas en dos participaciones en el foro por parte de todos los alumnos: Etapa 1 de participación en el foro. Análisis e identificación de las principales características de los modelos de calidad y su importancia. Etapa 2 de participación en el foro: Comparación entre los modelos e identificación de la influencia de los modelos clásicos en los modelos actuales.
3
RELACIONAR MODELOS DE CALIDAD DE SOFTWARE CLÁSICOS Y ACTUALES. Caso de estudio.
Estimado(a) Alumno(a) UnADM Asignatura: Programación .Net II De acuerdo a nuestra Metodología de Trabajo, el ejercicio que deberás resolver en la Actividad 2. Herencia mediante C# correspondiente a la Unidad II Herencia y polimorfismo en el lenguaje C#, consiste en lo siguiente: Desarrolla en CSharp el siguiente problema, que se muestra en el siguiente diseño de herencia.
A partir de lo anterior, construya:
Una clase abstracta llamada “Persona”, por ejemplo, con los siguientes datos miembros
protegidos. string Nombre; int Edad; int Rfc char Sexo; double Sueldo Tendrá un constructor que recibirá los 5 datos y los almacenará dentro de la clase. Tendrá 3 métodos abstractos llamados: Actividades, Horario e Informacion.
4
Una clase llamada, “Empleado”, que hereda de “Persona”, tendrá un dato miembro protegido llamado “Puesto” de tipo string, Su constructor recibirá los 6 datos y llamará a su padre enviándole 5 de ellos y guardando el “Puesto”. Es necesario que dé funcionalidad al método abstracto “Actividades” guardando en un dato
miembro de tipo string y pr otegido llamado “Actividad” la actividad realizada por la clase “Empleado”. Es necesario que dé funcionalidad al método abstracto “Horario”, guardando en un dato
miembro de tipo string y protegido llamado HorasDeTrabajo. Por ejemplo un empleado puede trabajar de “8:00-16:00”. Es necesario que dé funcionalidad al método Información mostrando la información de la clase. Construya una clase llamada “JefeDepartamental” que herede de “Persona”, tendrá un dato miembro protegido llamado “Departamento” de tipo string, Su constructor recibirá los 6 datos y llamará a su padre enviándole 5 de ellos y guardando el “Departamento”. Dé funcionalidad al método abstracto “Actividades” guardando en dos datos miembro de tipo string y privado llamado “Actividad1” y “Actividad2”, donde se guardan las dos actividades realizadas por la clase “JefeDepartmental”.
Dé funcionalidad al método abs tracto “Horario”, guardando en dos datos miembro de tipo string y privados llamados TurnoDeTrabajo1 y TurnoDeTrabajo2. Por ejemplo un jefe de departamento puede tener un horario de “8:00-14:00” y de “16:00 -18:00”. Dé funcionalidad al método Información mostrando la información de la clase. Construya una clase llamada: “Suspendido”, que hereda de “Empleado”, tendrá un dato miembro protegido llamado “Puesto” de tipo string, Su constructor recibirá los 6 datos y
llamará a su padre enviándole todos ellos. Agrega un método llamado Causa que recibirá una cadena indicando la causa de porque está suspendido y lo guardará en un dato miembro privado de tipo string llamado: Suspensión. Re-escribe el método información mostrando la información de la clase. Construya una interfaz llamada “Funcion”, tendrá la propuesta de 2 métodos abstractos. Uno llamado “AgregaJefeInmediato” que recibirá una cadena y nos devolverá un void. El otro método se llamará “AgregaPuesto”, recibirá una cadena y nos devolverá un void.
Construya una clase llamada “AsesorInterno” que herede de “Persona” he implemente “Funcion”. Tendrá un dato miembro privado llamado “Departamento” de tipo string, Su
constructor recibirá los 6 datos y llamará a su padre enviándole 5 de ellos y guardando el “Departamento”. Dé funcionalidad al método abstracto “Actividades” guardando en un dato miembro de tipo string y protegido llamado “Actividad” la actividad realizada por la clase “AsesorInterno”.
5
Dé funcionalidad al método abstracto “Horario”, guardando en un dato miembro de tipo string y protegido llamado HorasDeTrabajo. Por ejemplo un asesor puede trabajar de “8:00-16:00”. Agregue la funcionalidad a los métodos “AgregaJefeInmediato”, recibiendo una cadena y
guardándolo dentro de una variable de tipo string y privada llamada: “Jefe”. Agregue la funcionalidad a los métodos “AgregaPuesto”, recibiendo una cadena y guardándolo dentro de una variable de tipo string y privada llamada: “Puesto”.
Dé funcionalidad al método Información mostrando la información de la clase. Construya una clase llamada “AsesorExterno” que herede de “Persona” e implemente “Funcion”. Tendrá un dato miembro privado llamado “Compania” de tipo string, Su
constructor recibirá los 6 datos y llamará a su padre enviándole 5 de ellos y guardando la “Compania” asesora externa. Dé funcionalidad al método abstracto “Actividades” guardando en un dato miembro de tipo string y protegido llamado “Actividad” la actividad realizada por la clase “AsesorExterno”. Dé funcionalidad al método abstracto “Horario”, guardando en un dato miembro de tipo string y protegido llamado HorasDeTrabajo, pero siempre se va a guardar el mensaje “24 Horas”. Agregue la funcionalidad a los métodos “AgregaJefeInmediato”, recibiendo una cadena y
guardándolo dentro de una variable de tipo string y privada llamada: “Jefe”. Agregue la funcionalidad a los métodos “AgregaPuesto”, recibiendo una cadena y guardándolo dentro de una variable de tipo string y privada llamada: “Puesto”.
Dé funcionalidad al método Información mostrando la información de la clase.
6
Identifica en el caso las fases de la evaluación de la calidad del software: requerimientos o requisitos, factores de calidad y criterios de evaluación. Análisis del caso de estudio. Requerimientos funcionales:
1. El software debe permitir identificar al usuario. 2. El software debe contar con una interfaz que solicite y permita capturar al usuario, información de los empleados de la organización. 3. El software debe permitir almacenar la información de cada uno de los empleados de la organización (nombre, edad, RFC, sexo y sueldo). 4. El software debe permitir capturar y almacenar información del tipo de trabajador que la organización tiene contratado (Empleado, Jefe de departamento, Asesor interno y Asesor externo). 5. El software debe permitir solicitar y guardar información de: a. Para el rol de Empleado, su actividad principal. b. Para el rol de Jefe de departamento, sus dos actividades principales. c. Para el rol de asesor interno, la actividad principal que desarrolla. d. Para el rol de asesor externo, la actividad principal que desarrolla. 6. El software debe permitir solicitar y almacenar información de: a. Para el rol de Empleado, su horario de trabajo, en formato de horario corrido. b. Para el rol de Jefe de departamento, su horario de trabajo, en formato discontinuo (horario matutino y vespertino). c. Para el rol de asesor interno, su horario de trabajo, en formato de horario corrido. d. Para el rol de asesor externo, un mensaje en su horario de trabajo que indique “24 horas”.
7. Para el rol de asesor interno, el software debe permitir la captura y almacenamiento del nombre del departamento al cual está asesorando. 8. Para el rol de asesor interno, el software debe permitir la captura y almacenamiento del nombre del jefe de departamento al cual está asesorando. 9. Para el rol de asesor interno, el software debe permitir la captura y almacenamiento del puesto del jefe de departamento al cual está asesorando. 10. Para el rol de asesor externo, el software debe permitir la captura y almacenamiento del nombre de la compañía que representa. 11. Para el rol de asesor externo, el software debe permitir la captura y almacenamiento del nombre del jefe de departamento al cual asesora. 12. Para el rol de asesor externo, el software debe permitir la captura y almacenamiento del puesto del jefe de departamento al cual asesora. 13. Para el rol de Jefe de departamento, el software debe permitir la captura y almacenamiento del nombre del departamento que dirige. 14. El software debe permitir imprimir en pantalla, la información almacenada de cada empleado de la organización.
7
a. Para el rol de empleado: Su nombre, edad, RFC , sexo, sueldo, actividades y horario de trabajo en que desarrolla sus actividades). b. Para el rol de Jefe de departamento: su nombre, edad, RFC, sexo, sueldo, las dos actividades principales, el nombre del departamento que dirige y sus dos horarios en que desarrolla sus actividades. c. Para el rol de asesor interno: su nombre, edad, RFC, sexo, sueldo, actividad principal, horario de trabajo, nombre del jefe de departamento que asesora, nombre del departamento que asesora y puesto del jefe de departamento que asesora. d. Para el rol de aseso externo: su nombre, edad, RFC, sexo, sueldo, nombre de la compañía a la cual representa, actividad principal que desarrolla, su horario de trabajo, nombre del jefe de departamento que asesora, y puesto del jefe de departamento que asesora. 15. El software permitirá la captura y almacenamiento de información de los empleados que causen suspensión, detallando el motivo por el cual fue suspendido. 16. El software debe permitir imprimir en pantalla, la información completa de los empleados suspendidos y la causa por la cual fue suspendido. Factores y criterios de calidad modelo McCall en el caso de estudio.
Factor Mantenibilidad.
Flexibilidad.
Testeabilidad. Reusabilidad.
Correctitud.
Eficiencia. Confiabilidad.
Integridad. Usabilidad.
Criterio. -Consistencia. -Simplicidad. -Auto-descripción. -Modularidad. -Generalidad. -Auto-descripción. -Modularidad. -Simplicidad. -Instrumentación. -Generalidad. -Modularidad. -Auto-descripción. -Trazabilidad. -Completitud. -Consistencia. -Eficiencia en tiempo. -Tolerancia a errores. -Consistencia. -Simplicidad. -Exactitud. -Control de acceso. -Auditoría de acceso. -Operabilidad. -Entrenamiento. -Comunicación. -Volumen de E/S.
8
Factores y criterios de calidad modelo Boehm en el caso de estudio.
Usos primarios
Mantenibilidad.
Uso intermedio Testeabilidad.
Entendibilidad.
-Flexibilidad. Confiabilidad.
Utilidad.
Eficiencia.
Usabilidad.
Primitivas. -Comunicación. -Auto-descripción. -Estructuración. -Consistencia. -Estructuración. -Consicidad. -Legibilidad. -Estructuración. -Auto-contención. -Exactitud. -Completitud. -Consistencia. -Robustez/Integridad. -Eficiencia del dispositivo. -Accesibilidad. -Integridad/Robustez. -Accesibilidad. -Comunicación.
Factores y criterios de calidad modelo actual en el caso de estudio.
Factor Funcionalidad.
Confiabilidad.
Eficiencia. Usabilidad.
Mantenibilidad.
Eficacia. Productividad. Seguridad. Satisfacción.
Criterio. -Adecuación. -Exactitud. -Cumplimiento. -Madurez. -Tolerancia a fallas. -Cumplimiento. -En tiempo. -Cumplimiento. -Entendimiento. -Aprendizaje. -Operabilidad. -Cumplimiento. -Analizibilidad. -Facilidad para el cambio. -Testeabilidad. -Cumplimiento. Capacidad de ayudar al usuario a realizar sus objetivos con exactitud y completitud, en un dado contexto. Capacidad de ayudar al usuario en emplear una apropiada cantidad de recursos en obtener sus resultados. Capacidad de lograr aceptables niveles de riesgo para las personas, el ambiente de trabajo, y la actividad, en un dado contexto de uso. Capacidad de satisfacer un usuario en un dado contexto de uso.
9
Comparación entre los modelos e identificación de la influencia de los modelos clásicos en los modelos actuales. Características/Modelo McCall Perspectivas -Revisión del producto. -Transición del producto. -Operación del producto. Factores de calidad -Corrección. -Fiabilidad. -Eficiencia. -Integridad. -Usabilidad. -Facilidad de Mtto. -Facilidad de evaluación. -Flexibilidad. -Portabilidad. -Reusabilidad. -Interoperabilidad. Criterios de calidad -Consistencia. -Simplicidad. -Concisidad. -Auto-descripción. -Modularidad. -Expandibilidad. -Generalidad. -Instrumentación. -Independencia de la máquina. -Independencia del sistema operativo. -Interoperabilidad en comunicación. -Interoperabilidad en datos. -Trazabilidad. -Completitud. -Tolerancia a errores. -Exactitud. -Eficiencia en tiempo. -Eficiencia en espacio. -Control de acceso. -Auditoria de acceso. -Operabilidad. -Entrenamiento. -Comunicación. -Volumen de E/S. -Tasa de E/S.
Boehm -Características de Alto nivel. -Características de nivel intermedio -Características primitivas. -Utilidad per-se. -Mantenibilidad. -Utilidad general. -Portabilidad. -Confiabilidad. -Eficiencia. -Usabilidad. -Testeabilidad. -Facilidad de entendimiento. -Modificabilidad o flexibilidad. -Independencia de dispositivos. -Auto-contención. -Exactitud. -Completitud. -Consistencia. -Robustez/integridad. -Accesibilidad. -Eficiencia de uso de dispositivos. -Comunicación. -Auto-descripción. -Estructuración. -Concisidad. -Legibilidad. -Aumentabilidad.
Actual -Interna. -Externa. -Uso.
-Funcionalidad. -Confiabilidad. -Usabilidad. -Eficiencia. -Facilidad de mtto. -Portabilidad. -Eficacia. -Productividad. -Seguridad. -Satisfacción.
-Adecuación. -Exactitud. -Seguridad. -Interoperabilidad. -Cumplimiento. -Madurez. -Tolerancia a fallos. -Recuperación. -Cumplimiento. -Entendimiento. -Aprendizaje. -Operabilidad. -Atractivo. -En tiempo. -En recursos. -Analizabilidad. -Facilidad para el cambio. -Estabilidad. -Testeabilidad. -Cumplimiento. -Adaptabilidad. -Instalabilidad. -Conformidad. -Reemplazo. -
Conclusiones. Durante muchos años, se ha buscado en la Ingeniería de software, un modelo único para expresar la calidad. Esto representa una ventaja obvia: poder comparar productos entre sí. Los primeros modelos (McCall y Boehm) fueron los primero intentos en tal sentido, y aunque parezcan similares, la diferencia estriba en que McCall focaliza en medidas precisas de alto nivel, mientras que Boehm presenta un rango más amplio de características primitivas en la mantenibiliad, la cual, está más desarrollada en este último modelo. Sin embargo, éstos modelos tienen sus límites, ya que es difícil que las características y subcaracterísticas sean siempre perfectamente independientes, falta una asociación explícita entre los modelos y el proceso de software. Las características son en general, propiedades abstractas y medibles mediante métricas. No siempre existe una relación perfectamente lineal entre los valores de las métricas y las características que éstas deben estimar. Por todo lo anterior, y lo visto en la comparativa de los primeros modelos, se muestra cómo éstos han influenciado de manera importante en los modelos actuales, tan es así, que es creada la ISO 9126 como una variante del modelo de McCall. El foco en la calidad, cambia durante el ciclo de vida del software: Al principio, durante la recopilación de requerimientos y análisis, la calidad es especificada por los requisitos del usuario, sobre todo desde el punto de vista externo. En la fase de diseño e implementación, la calidad externa se traduce en un diseño técnico, confrontándose con el punto de vista de los desarrolladores sobre la calidad interna y complementándose con los requisitos implícitos que el software debe cumplir. Por último, la calidad final debe ser apropiada para el usuario y su contexto de uso. Es importante recordar que no existe calidad perfecta o absoluta. Sólo existe una calidad necesaria y suficiente para un contexto dado.
11
Bibliografía Fillottrani., P. R. (2007). Calidad en el Desarrollo de Software. Modelos de calidad de software. En P. R. Fillottrani., Calidad en el Desarrollo de Software. Modelos de calidad de software. (págs. 2-19). Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. México., U. A. (2014). Modelos de Calidad de Software. Unidad 3. Modelos de Calidad de Software. En UNADM., Modelos de Calidad de Software. Unidad 3. Modelos de Calidad de Software. (págs. 3-14). México, D.F.: Secretaría de Educación Pública.
12
