Calidad de software

Parcial 1
Parte I
1. Principales requerimientos manejados por TSP (Tipo relacionado con).
Tipo de requerimientos

Relacionado con

Funcionales

Entradas, salidas, clculos y casos de uso.

De vinculacin del sistema con el exterior

Usuarios, hardware, software, comunicacin con

otras computadoraso dispositivos.

De software

Manejadores de bases de datos, lenguajes,

instalacin, etc.

De diseo

Estndares, compatibilidad, integracin con otros

sistemas, etc.

Otros

Seguridad, mantenimiento, portabilidad, etc.

2. FURPS (Funcionality, Usability, Reliability, Performance, Supportability)

Funcionalidad, Usabilidad, Confiabilidad, Rendimiento, capacidad de soporte. factores
Atributos

Subatributos

Funcionalidad

Conjunto de caractersticas
Capacidades

Generalidad
Seguridad

Facilidad de uso

Factores humanos
Esttica

Consistencia
Documentacin

Fiabilidad

Frecuencia/Severidad de falla
Recuperabilidad
Predictabilidad

Precisin
Tiempo promedio de falla

Rendimiento

Velocidad
Eficiencia
Consumo de recursos

Throughput
Tiempo de respuesta

Capacidad de soporte

Capacidad de prueba
Extensabilidad
Adaptabilidad
Mantenibilidad
Compatibilidad

Configurabilidad
Capacidad de servicio
Capacidad de instalacin
Capacidad de localizacin

3. Actividades que involucra la calidad del producto de software

Administracin de la calidad

Uso de tecnologa de Ingeniera de Software eficiente

Aplicacin de tcnicas formales a lo largo de todo el proceso de desarrollo

Minimizacin de las variaciones entre productos

Verificacin y pruebas formales en las diferentes etapas del desarrollo

Control de la documentacin

Correcto mantenimiento y servicios de post-venta

4. Disciplinas que involucra CMMI

Ingeniera de sistema: Cubre la construccin de un sistema con o sin software

Ingeniera de software: Cubre la construccin de soluciones software

Integracin de productos y procesos de desarrollo: Cubre la relacin a largo plazo con el cliente

Relacin con proveedores: Cubre los procesos relacionados con la subcontratacin de partes del
sistema

5. Actividades a desarrollar en cada uno de los ciclos de TSP

Estrategia.

Crear un diseo conceptual del producto

Crear un diseo de alto nivel

Establecer la estrategia de desarrollo

Especificar el diseo

Establecer el plan de administracin de la

configuracin

Inspeccionar el diseo

Planeacin.

Implementacin.
Usar PSP para implementar mdulos

Hacer una planificacin semanal

Trasladar el diseo al cdigo

Hacer un plan de calidad

Revisar el cdigo

Asignar tareas a los miembros del equipo

Diseo.

Requerimientos.

Test.
Producir documentacin de los usuarios

Especificar requerimientos

Crear pruebas e integrarlas al sistema

Analizar necesidades del cliente

Desarrollar el documento de
requerimientos

Postmorten.
Escribir un reporte del ciclo
Producir evaluacin de las personas

Parte II
5. Factores que determinan la calidad del software
Caracterstica

Nombre

Descripcin

Operativas

Correccin

Valorar si el software hace lo que se espera de l.

Operativas

eficiencia

Se utilizan ptimamente los recursos de la computadora.

Operativas

Facilidad de uso

La aplicacin ofrece una interfaz adecuada al usuario.

Operativas

Integridad

Es seguro con respecto a los datos.

Soporte a cambios

Facilidad de
mantenimiento

Estimar en qu medida el programa es susceptible de ser

corregido.

Soporte a cambios

Flexibilidad

En qu medida el programa es susceptible a ser cambiado.

Soporte a cambios

Facilidad de prueba

Si resulta fcil hacer pruebas de su funcionamiento.

Adaptabilidad a
nuevos cambios

Reusabilidad

Hasta qu punto se podra volver a usar parte de dicho

software en otro proyecto.

Adaptabilidad a
nuevos cambios

Facilidad de
interoperacin

Valorar si el software puede interactuar con otros sistemas

informticos.

Adaptabilidad a
nuevos cambios

Portabilidad

Si se puede usar en otra mquina que utilice un procesador

distinto.
Parte III

6. A grandes rasgos la calidad en el proeso de desarrollo se observa de la siguiente manera:

Calidad en el diseo: Se basa en definir un listado de especificaciones a seguir; involucra la

descripcin de los procesos de desarrollo, tareas y responsabilidades de los equipos de desarrollo.
Dichos procesos pueden estar estandarizados.

Calidad en la implementacin: Se enfoca al grado de cumplimiento de los requerimientos de diseo.

Si los requerimientos estn bien definidos y especificados, el cumplimiento de la calidad en esta fase
no debe tornarse difcil.

Calidad en la satisfaccin: Es la medida de calidad apreciada por los usuarios finales de los
productos de software. No puede esperarse calidad en esta fase si no hubo preocupacin por ella en las
etapas anteriores.
Parte IV

7. Niveles de CMM
Nivel

Descripcin

1. Inicial

Proceso improvisado y a veces catico.

Punto base sin valor.
La Org opera sin procesos formalizados.
El xito depende de las habilidades, conocimientos y motivacin
personal.
La capacidad es una cualidad de las personas, no de la organizacin. Se
alcanza el propsito de manera inconsistente, no es planeado ni lleva un
seguimiento.

2. Repetible

Procesos bsicos de gestin para manejar costos, cronogramas y

funcionalidad establecidos.
La disciplina del proceso permite la repeticin de xitos anteriores en
proyectos similares.
La fuerza de la organizacin est dada por la existencia de experiencia
en desarrollo de procesos similares pero existen riesgos al presentarse
nuevos desafos.
El proceso tiene disciplina por que existe planeacin y seguimiento, es
documentado, es estable pero an as no hay mtricas para servicio, solo para
productos.

3. Definido

El proceso para gerentes e ingenieros est documentado e integrado en

un proceso estndar para la organizacin.

Todos los proyectos usan una versin aprobada y adaptada del proceso
estndar de la organizacin.
Un grupo de proceso de ingeniera de software ha sido establecido para
focalizar y liderar esfuerzos de mejora.
Nivel estndar y consistente gracias a las prcticas de ingeniera de software y
administracin de proyectos, el proceso es estable y repetible.

4. Administrado

Existen mediciones detalladas del proceso y calidad del producto

El producto y el proceso son cuantitativamente conocidos y controlados
Nivel cuantificable y predecible. Gracias a que el proceso, a la par que el
producto y los servicios es medido y opera dentro del lmite cuantificable.

5. Optimizado

La organizacin busca identificar aquellos elementos ms dbiles del

proceso y optimizarlos sobre la base de un anlisis defecto-causa y
prevencin de defectos.
Existen datos que justifican la aplicacin de nuevas ideas o tecnologas
a determinadas tareas crticas y la evidencia cuantitativa permite
conocer el grado de eficacia alcanzado al implementarlas en proyectos
piloto.
El mejoramiento se da gracias al uso o implementacin de nuevas tecnologas o
mtodos, se obtiene un cumplimiento total de objetivos de calidad.

Parte V:
8. Calidad segn Boehm: Incluye las necesidades de los usuarios, como lo hace Mc Call; sin embargo,
incluye caractersticas de rendimiento de hardware que no se encuentran en el modelo de McCall.
9. Un mismo factor de calidad puede ser percibido por usuarios y profesionales desde puntos de vista
diferentes, y por tanto no pueden enmarse nicamente en una clase u otra.
10. Capacidad: Es la habilidad inherente de un proceso para producir los resultados planeados.
11. En CMM las preguntas utilizadas en la evaluacin son binarias (si No), lo que no permite registrar los
matices de la realidad. (crticas a CMM)
12. En CMM los niveles de madurez no garantizan el xito. Existen proyectos existosos en el nivel 1 y
fracasos en niveles superiores. (crticas a CMM)
otras crticas a CMM

La aplicacin del modelo requiere una inversin importante.

Compara organizaciones grandes con pequeas favoreciendo a las primeras.

13. CMMI proporciona compatibilidad con los principios, requisitos y recomendaciones de na nueva norma
ISO 9000:2000 (Mejora de CMMI)
otras mejoras de CMMI

Especial nfasis sobre la capacidad de los procesos y madurez de la organizacin en su conjunto (no
exclusivamente en el rea de I.S.)

nfasis sobre las mejoras medibles y cuantificables para alcanzar los objetivos del negocio
empresarial.

14. PSP es un requisito previo para la planificacin de una organizacin para introducir el TSP..
15. En la gestin Personal de la calidad (PSP 2 y 2.1) el objetivo es encontrar y eliminar todos los defectos
antes de llegar a la primera ejecucin.
16. Herramientas de apoyo, 2a Generacin. Uso de herramientas automatizadas como Leap, PSP Studio o
PSP Dashboard.
Dimensin de procesos (SPICE)

CUS: Cliente-Proveedor

Adquisicin de productos de software y/o

servicios

Documentacin.
Gestin de la configuracin software.

Establecimiento de contratos

Garanta de calidad.

Identificar necesidades del cliente

Resolucin de problemas.

Realizar auditoras y revisiones conjuntas

Entrega e instalacin del software

Realizar revisiones conjuntas.

Mantenimiento del software

MAN: Gestin
Gestionar el proceso.

Proporcionar servicio al cliente

Gestionar el proyecto.

Valorar la satisfaccin del cliente

SUP: Soporte

Gestionar la calidad.

ENG: Ingeniera

Gestionar los riesgos.

Anlisis y diseo de requerimientos del

sistema.

ORG: Organizacin

Anlisis de requerimientos del software.

Alineamiento de la organizacin.

Diseo del software.

Establecimiento del proceso.

Construccin del software.

Evaluacin del proceso.

Integracin y pruebas del software.

Mejora del proceso.

Integracin y pruebas del sistema.

Gestin de recursos humanos.

Mantenimiento del software y del sistema

Infraestructura.
Reutilizacin

Parcial II
Agregar parcial II
Parcial III
Parte I
1. Proceso de recopilacin de mtricas

2. Propiedades de las mtricas

Simplicidad: la definicin y uso de la mtrica ha de ser simple.
Objetividad: diferentes personas han de darle valores idnticos. Esto le da consistencia y evita
interpretaciones individuales.
Facilidad de recoleccin: el coste y esfuerzo para obtener la medida ha de ser razonable.
Robustez: la mtrica ha de ser insensible a cambios irrelevantes. Esto permite realizar tiles
comparaciones.
Validez: la mtrica ha de medir lo que se supone que mide. Esto da fiabilidad a la medida.
3. Mtricas de tamao
Mtricas de tamao
LOC: Lneas de cdigo
Lneas escalables en un mtodo
Evalua
facilidad de comprensin,
reutilizacin y
facilidad de mantenimiento
sugerencia para descubrir mtodos a dividir
24 loc en C++
8 loc en Smalltalk
granularidad: mtodo, clase, programa, sistema
ciclo de vida: implementacin
No es recomendable para sistemas OO
No es aceptable universalmente para medir el proceso de software
Nmero de mensajes enviados
Mide nmero de mensajes enviados en un mtodo
unarios
binarios
clave
Sugerencia:
umbral de 9 mensajes

 granularidad: mtodo
Ciclo de vida: Implementacin
4. ndice de especializacin por clase (Specialisation Index per Class-SIX-) [Lorenz y Kidd, 1994]
Muestra en qu medida las subclases redefinen el comportamiento de sus superclases
Un valor de 15%
5. La visin de un componente como proveedor de servicios resalta dos caractersticas:
1. El componente es una entidad ejecutable independiente. El cdigo fuente no esta disponible por lo
que no hay que compilarse antes de usarse.
2. Los servicios ofertados estn disponibles a travs de una interfaz y las interacciones son a travs de
ella. Su estado interno nunca se muestra.
6. Propiedades de un sistema basado en COTS
Adaptable: Un sistema debera tener una configuracin de componentes adaptables que permita a los
componentes una fcil incorporacin, eliminacin o ser reemplazados.
Auditable: Un sistema es auditable si los integradores y gestores son capaces de ver y monitorizar su
comportamiento interno
Abierto: Es aquel que ha sido construido acorde a estndares y tecnologas abiertas lo cual permite
que sea extendido e integrado.
Seguro: La seguridad debe ser considerada a nivel arquitectnico donde deben implementarse las
polticas apropiadas.
7. Incompatibilidades de interfaces
1) De parmetros: Las operaciones tienen el mismo nombre pero los tipos o numero de parmetros son
distintos
2) De operaciones: Los nombres de las operaciones de las interfaces son diferentes.
3) Operaciones incompletas: La interfaz proporciona de un componentes es subconjunto de interfaz
requiere o viceversa.
8. Diccionario de datos
Proporcionar un enfoque organizado para representar las caractersticas de cada objeto de datos y
elemento de control.
Es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con
definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma
comprensin de las entradas, salidas, de las componentes de los almacenes y tambin de los clculos
intermedios.
Contiene:
Nombre: el nombre principal del elemento de datos o de control, del almacn de datos, o de una
entidad externa.
Alias: otros nombres usados para la primera entrada.
Dnde se usa/cmo se usa: un listado de los procesos que usan el elemento de datos o de control y
cmo lo usan (entrada al proceso, salida del proceso, almacn de datos, entidad externa).
Descripcin del contenido: el contenido representado mediante una notacin.
Informacin adicional: otra informacin sobre los tipos de datos, los valores implcitos (si se
conocen), las restricciones o limitaciones,
9. Tipos de interfaces de un componente
1) Proporciona: Es el API y define los servicios, se indican con un crculo al final de una lnea desde
el icono del componente.
2) Requiere: que especifica que servicios deben ser proporcionados por otros componentes, no
compromete la independencia o despliegue ya que no se requiere un componente especifico, se
indican con un semicrculo.
Mtricas internas son aquellas que no dependen de la ejecucin del software (medidas estticas).

Mtricas externas son aquellas aplicables al software en ejecucin.

Parte II

Identificacin de los objetos y clases

Los objetos se manifiestan de alguna de las siguientes formas:
Entidades externas: otros sistemas, dispositivos, personas; que producen o consumen
informacin a usar por un sistema computacional;
Cosas: informes, presentaciones, cartas, seales; que son parte del dominio de informacin del
problema;
Ocurrencias o sucesos: una transferencia de propiedad o la terminacin de una serie de movimientos
en un robot; que ocurren dentro del contexto de una operacin del sistema;
Papeles o roles: director, ingeniero, vendedor; desempeados por personas que interactan con el
sistema;
Unidades organizacionales: divisin, grupo, equipo; que son relevantes en una aplicacin;
Lugares: planta de produccin o muelle de carga; que establecen el contexto del problema y la
funcin general del sistema;
Estructuras: sensores, vehculos de cuatro ruedas o computadoras; que definen una clase de objetos
o, en casos extremos, clases relacionadas de objetos.
Parte III
Coad y Yourdon sugieren seis caractersticas de seleccin a usar cada vez que un analista considera
si incluye o no un objeto potencial en el modelo de anlisis:
Informacin retenida: el objeto potencial ser de utilidad durante el anlisis solamente si la
informacin acerca de l debe recordarse para que el sistema funcione.
Servicios necesarios: el objeto potencial debe poseer un conjunto de operaciones identificables que
pueden cambiar de alguna manera el valor de sus atributos.
Atributos mltiples: durante el anlisis de requisitos, se debe centrar la atencin en la informacin
principal (un objeto con un solo atributo puede, en efecto, ser til durante el diseo, pero seguramente
ser mejor presentado como un atributo de otro objeto durante la actividad de anlisis);
Atributos comunes: puede definirse un conjunto de atributos para el objeto potencial, los cuales son
aplicables a todas las ocurrencias del objeto.
Operaciones comunes: puede definirse un conjunto de operaciones para el objeto potencial, las
cuales son aplicables a todas las ocurrencias del objeto;
Requisitos esenciales: entidades externas que aparecen en el espacio del problema y producen o
consumen informacin esencial para la produccin de cualquier solucin para el sistema, sern casi
siempre definidas como objetos en el modelo de requisitos.
Parte IV

Parte V

Componentes comerciales

Material
Extra