1. Enfoques de Calidad
El Enfoque hacia el Producto
El Enfoque hacia el Proceso

2.  Varios autores han enunciado distintos modelos de
características de calidad de software o atributos
que pueden ser útiles para la negociación,
planificación, y tasación de la calidad de
productos software (Boehm 78; McCall 77)
Boehm 78
McCall 77

3.  ISO/IEC ha definido tres modelos relacionados de
calidad de productos software (la calidad interna,
la calidad externa, y la calidad en el empleo)
(ISO9126-01) y un conjunto de partes relacionadas
(ISO14598-98)
 NTP-ISO/IEC 17799:2007 (Norma Peruana)

4. Procesos Principales Procesos de Apoyo
1. Adquisición 1. Documentación
2. Suministro
2. Gestión de la Configuración
3. Desarrollo
4. Operación 3. Aseguramiento de la Calidad
4. Verificación 5. Validación
5. Mantenimiento
6. Revisión Conjunta
Organizativos
1. Gestión 7. Auditoría
2. Infraestructura 3. Mejora
8. Solución de Problemas
Diseño de Software 4. Recursos Humanos 4

5.  Esto da por consecuencia dos enfoques
principales para las características de la
calidad del software, el enfoque hacia
el producto y el enfoque hacia el
proceso
 La gestión de la calidad de software y la
calidad de proceso en la ingeniería de
software guardan relación directa con
la calidad del producto software

6.  El ingeniero de software, ante todo,
necesita determinar el Objetivo
verdadero del software
 En cuanto a esto, es de suma
importancia tener presente los
requerimientos del cliente y aquellos que
estos incluyen como requerimientos de
calidad, no únicamente los
requerimientos funcionales

7.  La calidad de un producto no se limita a su
confiabilidad o corrección, aunque ésta
debería estar en consonancia con el
precio y el uso de la aplicación de este
software
 Atañe a aspectos de similar importancia a
la confiabilidad, como la seguridad del
producto, de sus partes, cada vez más
importante en tanto y cuanto una parte
del software actual se realiza mediante la
composición de componentes
proporcionados bien por el programador,
bien por el sistema de desarrollo, bien
suministrado por terceros

8.  Otros aspectos fundamentales de la
calidad de un producto de software son
la facilidad de utilización por los usuarios
esperados, las prestaciones ofrecidas
por las aplicaciones, la adaptación a su
mantenimiento y producción de nuevas
versiones, la flexibilidad y la
transportabilidad a sistemas
hardware/software diferentes, etc.
 Una de las acepciones más utilizadas de
la calidad es la relacionada con
modelos de aseguramiento tipo ISO 9000

9.  El estándar ISO/IEC 9126-01 define, para
dos de sus tres modelos de calidad,
características de calidad, Sub-
características, y las medidas que son útiles
para Evaluación de calidad de producto
de software
 Como ejemplos de un producto cabe
incluir, aunque no con carácter limitativo,
una completa especificación del sistema,
una especificación de requerimientos de
software para un componente de software
de un sistema, un módulo de diseño,
código, documentación de prueba, o los
informes producidos como consecuencia
de tareas de análisis de calidad

10.  Mientras la mayor parte del tratamiento de la
calidad es descrito en términos del software final y
funcionamiento del sistema, una ingeniería práctica
responsable requiere que los productos intermedios
relevantes para la calidad sean evaluados a lo largo
de todo el proceso de ingeniería de software
 ISO 9000: Calidad de Software
 ISO 8402:1994. Gestión de la calidad y garantía de la
calidad. Vocabulario.
 ISO 12207:1995. Procesos del ciclo de vida del
software.
 ISO/IEC 9126:1991. Características de la calidad de
un producto software.
 ISO/IEC 12119:1995. Productos software: evaluación y
test.
 ISO/IEC 14102:1995. Guía para la evaluación y
selección de herramientas CASE.

11.  Las metodologías de desarrollo nos
ayudan a realizar este proceso (el de
desarrollo) reglado y prefijado para
conseguir productos adecuados
 Dentro de la Ingeniería de Software
existen multitud de metodologías para el
desarrollo de productos de software
 Incluso, cada país suele tener su versión
de metodología obligatoria
(normalmente en lo relativo a los
aspectos formales orientados a la
documentación) en los productos de
administración pública

12.  La orientación adecuada consiste en
partir de una metodología de desarrollo
suficientemente contrastada y admitida,
personalizada para la propia
organización pero sin pérdida de la
generalidad de la misma (lo que
consiguen muchas personalizaciones es
la pérdida de la eficiencia de la
metodología)

13.  Un proceso de desarrollo de software
determina quién debe hacer qué,
cuándo y cómo
 Un proceso de software define la forma
en que se organiza el trabajo de un
equipo de desarrollo y otros grupos de
apoyo
 Son las actividades que se realizan
siguiendo métodos y técnicas para
desarrollar un producto de software
 El proceso de desarrollo recibe como
entrada requisitos nuevos o modificados
y genera un sistema nuevo o modificado

14.  Los procesos de software difícilmente se
inventan desde cero, más bien recogen las
mejores prácticas y experiencias de los que
han tenido éxito en el desarrollo de software
 Actualmente, disponemos de una serie de
modelos generados por consenso entre
profesionistas, que podemos tomar como
modelos de referencia
 Los ejemplos más destacados de estos
modelos el CMM-SW, el CMMI, el ISO/IEC 12207
e ISO/IEC 15504
 La confianza en estos modelos se debe al
hecho de que fueron sustraídos de las
experiencias de varias empresas y de muchos
proyectos exitosos desarrollados anteriormente

16.  Los modelos de referencia mencionados
muestran, que para tener éxito en el
proceso de desarrollo de software hay que
darle la debida importancia no solamente
a los aspectos técnicos, sino también a los
aspectos de gestión de un proyecto
 Una organización que quiera medir la
calidad, o usando los términos de los
modelos, la capacidad y/o madurez de sus
procesos, puede comparar su forma de
trabajar con respecto a lo que sugieren
estos modelos
 Esto se conoce como evaluación de
procesos (Process Assessment)

17.  Esencialmente el proceso está definido
por un modelo de proceso junto con la
definición de artefactos, actividades y
roles
 Además, existe consenso respecto a
que el proceso de desarrollo debe ser
iterativo
 En este sentido normalmente se
combinan una estrategia de desarrollo
incremental con una de desarrollo en
espiral

18.  Una importante característica de un
proceso iterativo es que la
especificación del software es
desarrollada a lo largo del proceso de
desarrollo de software, es decir, no se
establece de forma completa e
inmutable al principio del desarrollo
 Un artefacto es cualquier información
usada o producida por el proceso de
desarrollo de software (OMG 2002)
 Ejemplos de artefactos son:
documentos, modelos, archivos fuente y
ejecutables

19.  Un rol es la definición del
comportamiento y responsabilidades de
un individuo o conjunto de individuos
trabajando juntos como un equipo,
dentro del contexto de la organización
de ingeniería de software
 Una actividad es una unidad de trabajo
que puede realizar un determinado rol
 Todo lo anterior se define de acuerdo a
la terminología utilizada en RUP (Rational
Unfied Process) que es la versión de la
empresa Rational del proceso unificado

20.  No existe un proceso de desarrollo de
software universal que sea adecuado
para cualquier proyecto
 Debido a esto, un proceso de desarrollo
debe ser entendido como un marco de
trabajo configurable, capaz de ser
adoptado y escalda según las
características del proyecto
 En la actualidad, quizá dos de los
exponentes más representativos de
procesos en cuanto a su interés
industrial, son RUP y XP (Extreme
Programming) (Beck 2000)

21.  Ambos representan una pugna entre lo
que se ha clasificado por algunos
autores como procesos peso pesado
(heavyweight) y procesos peso ligero
(lightweight) o también llamados
metodologías ágiles
 La diferencia más clara entre los
procesos llamados pesados y los ligeros
está en la envergadura de los proyectos
para los cuales están orientados y el
grado de “ceremonia” o mejor dicho,
formalidad que el proceso establece

22.  En RUP se hace mayor hincapié en el
modelado y hay una precisa definición
de cada uno de los roles, actividades y
artefactos que deben formar el proceso
de desarrollo
 RUP es un marco de trabajo que puede
ser adaptado a las necesidades del
proyecto, con lo cual puede
configurarse para proyectos de distintas
envergaduras

23.  XP se orienta fuertemente a la producción
de código y sus pruebas, restando
protagonismo al modelado y enfatizando
aspectos tales como: la satisfacción del
cliente, el potenciar la capacidad
individual y promover una estrecha
colaboración del equipo de desarrollo
 XP debido a sus principios, presenta
inconvenientes para ser escalado a
grandes proyectos en condiciones en las
cuales, por ejemplo, como lo señala Smith
(2001) hay más de 10 participantes, el
equipo está distribuido geográficamente,
el tiempo de desarrollo es de años, etc.

24.  Se puede resumir todo lo anterior de la
forma siguiente:
Gente
Tecnología Proceso

25.  Gente
› Con las habilidades, entrenamiento y
motivación
 Tecnología
› Herramientas e Infraestructura
 Proceso
› Procedimientos y Métodos definiendo las
relaciones de las tareas