Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Prefacio:
Introduccin a la
Calidad de
Software
Calidad de
Software.
Herramientas
bsicas de calidad.
Herramientas de
gestin, creatividad
y estadstica.
Calidad de los
Sistemas
Informticos
Calidad de
sistemas de
informacin.
Modelo de calidad
interna y externa.
Modelo de calidad
en uso.
Calidad del
Proceso
Software
Evaluacin y mejora
de Procesos
El proceso
software.
Medicin de sistemas
de informacin.
Modelado de
procesos
software.
El modelo ideal y el
proceso de software
personal.
Entorno PSEE.
Proceso de software de
equipo y el modelo
CMM.
Ciclo de vida.
Herramientas de
diseo y medicin.
El estndar ISO/IEC
15504.
I. PREFACIO
II. DESARROLLO DE LOS CONTENIDOS
UNIDAD DE APRENDIZAJE 1: INTRODUCCIN A LA CALIDAD DE SOFTWARE
1.
Introduccin
a. Presentacin y contextualizacin
b. Competencia
c. Capacidades
d. Actitudes
e. Ideas bsicas y contenido
2.
Desarrollo de los temas
a. Tema 01: Calidad de software .
b. Tema 02: Herramientas bsicas de calidad.
c. Tema 03: Herramientas de gestin, creatividad y estadstica.
d. Tema 04: Herramientas de diseo y medicin.
3.
Lecturas recomendadas
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 2: CALIDAD DE LOS SISTEMAS INFORMTICOS
1.
Introduccin
a. Presentacin y contextualizacin
b. Competencia
c. Capacidades
d. Actitudes
e. Ideas bsicas y contenido
2.
Desarrollo de los temas
a. Tema 01: Calidad de sistemas de informacin.
b. Tema 02: Modelo de calidad interna y externa.
c. Tema 03: Modelo de calidad en uso.
d. Tema 04: Normas ISO 9126 e ISO 14598.
3.
Lecturas recomendadas
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 3: CALIDAD DEL PROCESO SOFTWARE
1.
Introduccin
a. Presentacin y contextualizacin
b. Competencia
c. Capacidades
d. Actitudes
e. Ideas bsicas y contenido
2.
Desarrollo de los temas
a. Tema 01: El proceso software.
b. Tema 02: Modelado de procesos software.
c. Tema 03: Entorno PSEE.
d. Tema 04: Ciclo de vida.
3.
Lecturas recomendadas
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 4: EVALUACIN Y MEJORA DE PROCESOS
1.
Introduccin
a. Presentacin y contextualizacin
b. Competencia
c. Capacidades
d. Actitudes
e. Ideas bsicas y contenido
2.
Desarrollo de los temas
a. Tema 01: Medicin de sistemas de informacin.
b. Tema 02: El modelo ideal y el proceso de software personal.
c. Tema 03: Proceso de software de equipo y el modelo CMM.
d. Tema 04: El estndar ISO/IEC 15504.
3.
Lecturas recomendadas
4.
Actividades
5.
Autoevaluacin
6.
Resumen
III. GLOSARIO
IV. FUENTES DE INFORMACIN
V. SOLUCIONARIO
02
03 - 152
05-41
06
06
06
06
06
06
07-37
07
12
18
27
38
38
39
41
42-72
43
43
43
43
43
43
44-68
44
52
58
63
69
69
71
72
73-110
74
74
74
74
74
74
75-106
75
84
95
101
107
107
108
110
111-149
112
112
112
112
112
112
113-145
113
124
133
139
146
146
147
149
150
151
152
Introduccin
a) Presentacin y contextualizacin
La calidad del software es un concepto complejo que no es directamente
comparable con la calidad de la manufactura de producto. Los productos de
software
son
uno
de
los
principales
objetivos
estratgicos
de
muchas
b) Competencia
Reconoce las principales herramientas y estrategias aplicadas al control de
calidad de software.
c) Capacidades
1. Comprende la calidad del software como el conjunto de propiedades y
caractersticas de un producto o servicio para satisfacer necesidades
expresadas.
2. Reconoce las herramientas bsicas de calidad aplicado a la ingeniera del
software.
3. Describe las herramientas de gestin, creatividad y estadstica en el control de
calidad de software.
4. Aplica las frmulas adecuadas de diseo y medicin en el control de calidad de
software.
d) Actitudes
Valora las cualidades y beneficios de un producto software en el proceso de
control de calidad.
Pone en prctica las distintas herramientas de control de calidad de software.
Calidad
TEMA 1
de
Software
Competencia:
Comprender la calidad del software como el
conjunto de propiedades y caractersticas de
un producto o servicio para satisfacer
necesidades expresadas.
Calidad (Concepto Dinmico): La calidad est muy relacionada al desarrollo del ser
humano. Por lo tanto es un concepto dinmico sujeto a diferentes
definiciones segn la poca y el entorno en que se desenvuelve
Calidad (William Deming, 1986): Ofrecer a bajo costo
productos y servicios que satisfagan a los clientes. Implica un
compromiso con la innovacin y mejoras continuas.
Calidad (Philip Crosby, 1995): La explica desde una perspectiva ingenieril como el
cumplimiento de normas y requerimientos precisos. Su lema es Hacerlo bien a la
primera vez y conseguir cero defectos Con estas definiciones como antecedente
podemos concluir que la calidad no es un concepto absoluto ms bien es algo
multidimensional, ya que est sujeta a restricciones y ligada a compromisos
aceptables.
Orgenes de la Calidad
Calidad Realizada, la calidad que se ha conseguido.
Calidad Programada o Especificada, la calidad que se
pretende obtener.
Calidad Necesaria o Requerida, la calidad que el cliente
exige.
Lo ideal es que las tres coincidan, a la interseccin entre la calidad Requerida y la
calidad Realizada se llama calidad Percibida, y es la nica que el cliente valora; toda
calidad que se realiza pero no se necesita es un gasto intil de tiempo y dinero.
proceso
cumple
los
requerimientos
(Software
Quality
que
determina
la
calidad,
los
objetivos
las
10
11
Herramientas
Bsicas
de Calidad
TEMA 2
Competencia:
Reconocer las herramientas bsicas de calidad
aplicado a la ingeniera del software.
12
En conclusin, este diagrama de flujo nos ayuda a lograr una mejor comunicacin en
las discusiones y anlisis. Es importante que no olvide que para desarrollar un
diagrama de flujo debe utilizar los smbolos adecuados, como algunos que se
muestran en la figura.
13
2.
3.
4.
Diagrama de Pareto
La idea central del diagrama de Pareto es
localizar los pocos defectos, problemas o
fallas vitales para concentrar los esfuerzos de
solucin o mejora en estos.
Se representa a travs de una grfica de
datos de conteo, donde se muestra la frecuencia de cada conteo en el eje vertical y la
clasificacin sobre el eje horizontal. Segn la regla enunciada por Wilfrido Pareto, si se
tiene un problema con muchas causas, podemos decir que el 20 % de las causas
resuelven el 80 % del problema y el 80 % de las causas solo resuelven el 20 % del
problema. Regla del 80 - 20
14
15
2.
3.
Identificar de 3 a 6 espinas mayores que puedan ser las causas del problema /
efecto principal.
4.
5.
6.
7.
8.
16
los
datos
recabados
segn
determinadas
De modo general las hojas de recopilacin de datos se pueden clasificar segn el tipo
de datos en:
De verificacin, inspeccin, chequeo o tareas de mantenimiento.
De localizacin de defectos en las piezas.
De distribucin de variaciones de variables de los artculos (peso, volumen,
longitud, calidad, etc.).
De clasificacin de artculos defectuosos.
17
Herramientas
de Gestin,
TEMA 3
Creatividad
y
Estadstica
Competencia:
Describir
las herramientas de gestin,
creatividad y estadstica en el control de
calidad de software.
18
Tipos de correlacin
19
Diagrama de relaciones
Es una herramienta utilizada para identificar las causas ms significativas de un
problema y representar grficamente los vnculos que puedan existir entre los factores
relacionados con ese problema. Esta herramienta ayuda a un grupo de trabajo a
identificar los enlaces naturales entre diferentes aspectos de una situacin compleja.
Los diferentes elementos del diagrama se relacionan entre s con flechas.
20
Diagrama de rbol
Se utiliza para representar jerrquicamente los diferentes niveles de complejidad de un
determinado proceso o producto, partiendo de un primer nivel genrico que se va
descomponiendo en niveles de mayor detalle hasta alcanzar un nivel bsico o
autodescriptivo.
21
1.
2.
Para cada tarea del tercer nivel identificar que es 10 que podra salir mal.
3.
Revisar todas las listas de problemas potenciales y eliminar aquellos que sean
improbables o cuyas consecuencias pudieran llegar a ser poco significativas.
4.
5.
6.
Estudia la viabilidad de cada plan de contingencia, marcando con una "X" los
impracticables y con una "O" los que S podrn llegarse a dar.
HERRAMIENTAS DE CREATIVIDAD
Aunque existen herramientas de creatividad como los
mapas conceptuales, el uso de analogas, etc. aqu se
presentan solo la tormenta de ideas como la ms utilizada.
Es una herramienta de trabajo en grupo basada en la
creatividad de los componentes del grupo de trabajo. Se
pretende obtener el mayor nmero de ideas o soluciones
en el menor tiempo posible, seleccionando posteriormente
las ms indicadas, es decir, aquellas que mejor se adaptan a los objetivos del
problema.
22
Para ella es necesario que el equipo de trabajo conozca dichos objetivos. Existen dos
modos de realizacin de esta tcnica:
Modo Iibre: los miembros del grupo van aportando ideas segn se les van
ocurriendo sin seguir ningn turno preestablecido. Se crea un ambiente ms
relajado pero se corre el peligro de que haya personas que no participen y por
tanto no se conozcan sus ideas.
HERRAMIENTAS ESTADSTICAS
Control estadstico del proceso
Se entiende por capacidad de un proceso el grado de aptitud que tiene para cumplir
con las especificaciones tcnicas deseadas. Cuando la capacidad de un proceso es
alta, se dice que es capaz. Cuando se mantiene estable a 10 largo del tiempo se dice
que est bajo control. Para determinar si un proceso es 0 no capaz, se pueden utilizar
las siguientes herramientas:
Histogramas
Grficos de Control
Grficos de Probabilidad
23
ndice de capacidad
Se considera un ndice de Capacidad como la relacin
entre la variacin natural del proceso y el nivel de
variacin
especificada.
Se
pueden
hacer
dos
clasificaciones:
Respecto a su posicin:
a. ndices centrados con respecto a los limites
b. ndices descentrados con respecto a los lmites pero contenidos en
ellos.
c. Slo con lmite superior
d. Slo con lmite inferior
CORTO PLAZO
(INTRAGRUPO)
LARGO PLAZO
(INTERGRUPO)
CON LMITE
CON LMITE
SUPERIOR
INFERIOR
CPK
CPU
CPL
PPK
PPU
PPL
CENTRADO
NO CENTRADO
CP
PP
= {
,
}
3
3
24
Para afirmar que un proceso es capaz CP y/o CPK deben ser mayor o igual que 1,33, lo
que garantiza que el 99,994 % de los productos fabricados o servicios prestados por el
proceso centrado est dentro de las especificaciones.
En caso de ser necesario estudiar los dos, ambos deben valer como mnima 1,33. En
otro caso, habr que aplicar acciones correctoras.
3
25
Diseo de experimentos
El Diseo de Experimentos (DDE, DOE, Design of Experiments) tiene como objetivo
averiguar si unos determinados factores influyen en una 0 varias variables de inters
para la calidad, y si se demostrara dicha influencia, cuantificarla. Las etapas de las que
consta un DOE pueden resumirse en:
1.
2.
3.
4.
5.
6.
7.
8.
9.
26
Herramientas
de
Diseo
TEMA 4
Medicin
Competencia:
Aplicar las frmulas adecuadas de diseo y
medicin en el control de calidad de
software.
27
que los requisitos del c1iente lleguen a estar completamente contenidos en las
especificaciones tcnicas del producto o servicio. La principal ventaja de esta tcnica
es la reducci6n del tiempo del desafo y la disminuci6n de los costes, manteniendo y
mejorando la calidad.
2.
3.
28
2.
3.
4.
5.
6.
7.
8.
9.
29
modificaciones
importantes
para
30
IPR
DETECCION
GRAVEDAD
IPR
DETECCIN
FRECUENCIA
PREVENTIVOS
CONTROLES
CAUSA
EFECTO
MODO
PRIORIDAD
RESULTADO
FRECUENCIAS
EVALUACIN DE
RESPONSABLES Y
PLAZOS
FECHA
APLICACIN
FALLO
ACCIONES CORRECTIVAS
Causa de Falla: hay que describir las anomalas de las que se tiene
sospecha que han podido producir el fallo: variaciones en los
parmetros. de manipulacin optima, deficiencias en el diseo del
producto, servicio o proceso, deficiencia en los materiales usados, uso
indebido por parte del cliente, etc.
31
32
33
HERRAMIENTAS DE MEDICIN
COQ (coste de la calidad)
Llamado tambin Anlisis de Costes de Pobre Calidad, el COQ
es un proceso utilizado para identificar problemas potenciales, y
cuantificar los costes en los que habra que incurrir por no hacer las
cosas bien desde el principio.
Para realizar un anlisis COQ se recomienda seguir estos pasos:
Benchmarking
El benchmarking es un proceso estructurado que permite comparar las mejores
prcticas de las organizaciones, de manera que se pueden incorporar aquellas que no
se desarrollan o mejorar las que se desarrollan a la propia organizacin, o a los
procesos de la organizacin.
34
Planificar:
a. Definir los objetivos del estudio. Hay que elegir aquellos que sean crticos para
el xito organizacional.
b. Formar un equipo multidisciplinar que afronte firmemente el estudio que se va
a desarrollar.
c. Estudiar los propios procesos de la organizacin: es preciso conocer cmo
funcionan las cosas internamente para hacer un buen trabajo en la
comparacin.
d. Identificar los profesionales de la organizacin que podran desarrollar las
mejores prcticas.
Recopilar Datos:
a. Recopilar los datos directamente de los profesionales de la organizacin. Hay
que recoger tanto las descripciones de los procesos como los datos
numricos, usando cuestionarios, entrevistas telefnicas y/o visitas.
Analizar:
a. Comparar los datos recolectados, tanto los numricos como los descriptivos.
b. Determinar las brechas entre las medidas de rendimiento de los procesos de la
propia organizacin con los de las otras organizaciones.
c. Determinar las diferencias en las prcticas que provocan dichas brechas.
Adaptar:
a. Desarrollar objetivos para los procesos de la organizacin.
b. Desarrollar planes de accin para conseguir esos objetivos.
c. Implementar y monitorizar dichos planes.
35
Encuestas
Estn destinadas a determinar la naturaleza de los
procesos. Existen dos modalidades:
Interrogacin
directa:
los
trabajadores
del
NIVELES DE MADUREZ
Varios autores han sealado que las organizaciones pueden presentar diferentes
niveles en la gestin de la calidad. As, por ejemplo, Crosby (1979) distingue los
siguientes cinco niveles:
36
DESCRIPCIN
HERRAMIENTAS
MADUREZ
BAJO
No
hay
mejora
continua
formal. Control
MEDIO
Estadstico
de Proceso
ALTO
de
estrategia
de
departamentos
la
organizacin.
procesos
Los QFD
monitorizan
37
Lecturas Recomendadas
Actividades y Ejercicios
38
Autoevaluacin
39
40
Resumen
UNIDAD DE APRENDIZAJE I:
defectos. Diagrama
41
42
Introduccin
a) Presentacin y contextualizacin
La calidad de una empresa u organizacin depende de la calidad de los procesos de
negocio soportados por el sistema de informacin, as como la propia calidad de
este. En la calidad de un producto software, as como en las mtricas asociadas en
las diferentes etapas del ciclo de vida del software, se suelen distinguir tres aspectos
diferentes: calidad interna: medible a partir de las caractersticas intrnsecas, como
el cdigo fuente; calidad externa; medible en el comportamiento del producto, como
en una prueba; o en uso: medible durante la utilizacin efectiva por parte del usuario
en un contexto determinado.
b) Competencia
Analiza las principales caractersticas de los modelos de control de
informacin, describiendo su funcionalidad para su empleo adecuado dentro
de cualquier organizacin.
c) Capacidades
1. Comprende la importancia de los sistemas de informacin y el proceso
adecuado de control de calidad de software.
2. Reconocer las principales estrategias que representan al modelo de calidad
externa e interna.
3. Describe las caractersticas del modelo de calidad de uso y la evaluacin de un
producto software.
4. Aplica las normas ISO 9126 e ISO 14598 en el control de calidad de software.
d) Actitudes
Promueve el cumplimiento de las normas ISO 9126 e ISO 14598.
Valora los distintos modelos de control de calidad de la informacin.
43
Calidad
de Sistemas
TEMA 1
de
Informacin
Competencia:
Comprender la importancia de los sistemas
de informacin y el proceso adecuado de
control de calidad de software.
44
COMPONENTES DE LA CALIDAD
La calidad de un sistema informtico (SI) puede descomponerse
en diferentes factores que contribuyen a la misma.
45
46
de
otros
tipos
de
productos:
A finales de los aos ochenta, fueron propuestos dos modelos alternativos a los de
McCall basados igualmente en la identificacin de factores: el modelo de factores de
Evans y Marciniak (1987) y el modelo de factores de Deutsch y Willis (1988).
En la siguiente tabla puede encontrarse una comparativa entre los distintos modelos
donde se muestran los factores observados por cada uno de los autores en sus
correspondientes trabajos.
47
McCall
Evansy Marcinlak
Deutsch y Willis
(1976)
(1987)
(1988)
Correccin
Fiabilidad
Eficiencia
Integridad
Usabilidad
Mantenibilidad
Flexibilidad
Testeabilidad
Portabilidad
Reusabilidad
Inter operatividad
Verificabilidad
Expandibilidad
Seguridad de uso
Manejabilidad
Capacidad de
supervivencia
48
49
desarrollar
como
2504n
Evaluacin
apartado
de
incluye
-Divisin
de
Calidad.
Este
normas
que
proporcionan
requisitos,
Divisiones de SQuaRE
50
51
Modelo
de Calidad
Interna
y Externa
TEMA 2
Competencia:
Reconocer las principales estrategias que
representan al modelo de calidad externa
e interna.
52
Funcionalidad
Capacidad del producto software para proporcionar funciones que satisfacen
necesidades declaradas e implcitas cuando se usa bajo condiciones especificadas.
sta caracterstica se subdivide a su vez en:
53
Fiabilidad
Capacidad del producto software para mantener un nivel especificado de prestaciones
cuando se usa bajo condiciones especificadas. Esta caracterstica se subdivide a su
vez en:
mantener
un
nivel
especificado
de
54
Usabilidad
Capacidad del producto software para ser entendido, aprendido, usado y ser atractivo
para el usuario, cuando se usa bajo condiciones especificadas. Esta caracterstica se
<subdivide a su vez en:
Eficiencia
Capacidad del producto software para proporcionar prestaciones apropiadas, relativas
a la cantidad de recursos usados, bajo condiciones determinadas. Esta caracterstica
se subdivide a su vez en:
55
Mantenibilidad
Capacidad del producto software para ser modificado. Las modificaciones podran
incluir correcciones, mejoras o adaptaci6n del software a cambios en el entorno, y
requisitos y especificaciones funcionales. Esta caracterstica se subdivide a su vez en:
Capacidad para ser probado. Capacidad del producto software que permite
Portabilidad
Capacidad del producto software para ser transferido de un entorno a otro. Esta
caracterstica se subdivide a su vez en:
56
57
Modelo
de Calidad
en Uso
TEMA 3
Competencia:
Describir las caractersticas del modelo de
calidad de uso y la evaluacin de un
producto software.
58
Productividad
Capacidad del producto software para permitir a los usuarios gastar una cantidad
adecuada de recursos con relacin a la efectividad alcanzada, en un contexto de uso
especificado.
59
Seguridad de uso
Capacidad del producto software para alcanzar niveles
aceptables del riesgo de hacer dao a personas, al
negocio, al software, a las propiedades o al medio
ambiente en un contexto de uso especificado.
Satisfaccin
Capacidad del producto software para satisfacer a los usuarios en un contexto de uso
especificado.
Por ejemplo:
La divisin de la escala en dos categoras: satisfactorio e insatisfactorio.
La divisin de la escala en cuatro categoras limitadas por el nivel actual de un
producto existente o alternativo, el peor caso y el nivel proyectado. El nivel actual
se declara con el fin de controlar que el nuevo sistema no suponga un deterioro
en relacin a la situacin actual. EI nivel
proyectado
es
lo
que
se
considera
60
61
necesario
evaluar
cuan
eficaces,
De entre los modelos de proceso de evaluacin es importante referirse al [ISO145985], que estaba incluido originalmente en [ISO9126], y que tiene como objetivo
principal proveer un marco de evaluacin genrico, abstracto, que permita a los
evaluadores,
62
Normas
ISO
9126 e ISO
14598
TEMA 4
Competencia:
Aplicar las normas ISO 9126 e ISO 14598 en el
control de calidad de software.
63
Eficiencia.
Idoneidad.
Atractividad.
Exactitud.
Comportamiento en el tiempo.
Interoperabilidad.
Comportamiento de recursos.
Seguridad.
Mantenibilidad.
Cumplimiento de normas.
Estabilidad.
Fiabilidad.
Facilidad de anlisis.
Madurez.
Facilidad de cambio.
Recuperabilidad.
Facilidad de pruebas.
Tolerancia a fallos.
Portabilidad.
Usabilidad.
Capacidad de instalacin.
Aprendizaje.
Capacidad de reemplazamiento.
Comprensin.
Adaptabilidad.
Operatividad.
Co-Existencia
64
Un producto software est definido en un sentido amplio como: los ejecutables, cdigo
fuente, descripciones de arquitectura, y as, como resultado, la nocin de usuario se
ampla tanto a operadores como a programadores, los cuales son usuarios de
componentes como son bibliotecas software.
65
SQUID,
permite
la
especificacin,
planificacin,
66
subcaractersticas
en
atributos.
5. Descomponer atributos derivados (aquellos
que no sean medibles directamente) en
atributos bsicos.
6. Establecer relaciones entre entidades de calidad (por ejemplo, aumentar la
subcaractersticas de seguridad lleva consigo que aumente la madurez de
un producto)
7. Determinar metlicas para los atributos.
67
Relaciones y proceso de transicin entre las series ISO/IEC 9126 e ISO/IEC 14598
a la serie de normas SquaRE
68
Lecturas Recomendadas
MODELO DE LA CALIDAD
http://www.mginformatica.com.ar/modelo-de-calidad.htm
Actividades y Ejercicios
69
Autoevaluacin
70
10) La familia de normas ISO 25000 (ISO 2005a-n) es conocida con el nombre de:
a. Quality.
b. Secure.
c. Square.
d. Sunthuar.
e. Caswell.
71
Resumen
Uno de los modelos clsicos ms utilizados desde su creacin, incluso con vigencia en
nuestros das, es el desarrollado por McCall (McCall et al., 1977), en el que la calidad
de un producto software se descompone en once caractersticas o factores de calidad
agrupados en tres categoras: Operacin de producto, Revisin de producto y
transicin de producto.
A finales de los aos ochenta, fueron propuestos dos modelos alternativos a los de
McCall basados igualmente en la identificacin de factores: el modelo de factores de
Evans y Marciniak (1987) y el modelo de factores de Deutsch y Willis (1988).
El modelo de calidad para calidad interna y externa categoriza los atributos de calidad
software
en
seis
caractersticas:
Funcionalidad
(adecuacin,
exactitud,
La norma ISO 9126 entiende por calidad en uso "la capacidad del producto software
para permitir a determinados usuarios alcanzar' objetivos especificados con
efectividad, productividad, seguridad y satisfaccin, en contextos de uso
especificados". La norma ISO 14598 da una visin general del proceso de evaluacin
de un producto software, explicando en sus diferentes partes como aplicar el proceso
en diferentes circunstancias. Esta norma se apoya en la ISO 9126 ya que los aspectos
cuantificables pueden medirse cuantitativamente usando mtricas de calidad, cuyo
valor medido se sima en una escala.
72
73
Introduccin
a) Presentacin y contextualizacin
Tradicionalmente la Ingeniera del Software se ha centrado en metodologas y
lenguajes de programacin, modelos de desarrollo y herramientas. Sin embargo, y
teniendo en cuenta la creciente complejidad de los sistemas, se haca necesario
incluir determinadas reas que hoy en da son crticas para la ingeniera del
software, como las infraestructuras de gestin y organizacin, por lo que surge la
denominada ingeniera del software basada en el proceso.
b) Competencia
Describe los diferentes modelos de calidad del proceso software y sus
caractersticas.
c) Capacidades
1. Analiza los procesos bsicos de un proceso de software.
2. Aplica diversos mtodos en el control de procesos de software.
3. Comprende los diferentes entornos de ingeniera del software orientados al
proceso.
4. Reconoce los diversos procesos en el ciclo de vida del software.
d) Actitudes
Participa activamente en el desarrollo de las tareas de proceso de software.
Cumple con rigurosidad las actividades relacionados con los diversos mtodos
de control de proceso de software.
74
El Proceso
Software
TEMA 1
Competencia:
Analizar los procesos bsicos de un proceso
de software.
75
que
la
gente
usa
para
El proceso software es un proceso con una naturaleza especial, determinada por las
siguientes caractersticas (Demiame et al., 1999):
Es complejo.
76
Est
basado
en
descubrimientos que
dependen
de
la
comunicacin,
77
y practique universalmente
por
la
78
79
80
Por lo tanto, uno de los grandes objetivos de la tecnologa de procesos es lograr que la
representacin de procesos pueda ser usada para gestionar los procesos actales de
desarrollo y mantenimiento del software. Como primer paso, la tecnologa de procesos
introduce la nocin de modelo de procesos, que consiste en la descripcin de un
proceso expresndolo en un lenguaje de modelado de procesos adecuado
Un modelo de procesos puede ser analizado, validado y simulado, si es ejecutable. En
los modelos de procesos se puede describir de una forma precisa los diferentes
aspectos relacionados con los procesos software, de forma que con diferentes
modelos se puedan expresar las diferentes vistas de un proceso.
81
82
83
Modelado
de Procesos
Software
TEMA 2
Competencia:
Aplicar diversos mtodos en el control de
procesos de software.
84
DIAGRAMAS PERT
Los diagramas PERT (Program Evaluation and
Review Techniqlle) representan grficamente los
procesos mediante un grafo dirigido en el que se
incluyen las tareas, su duracin y sus relaciones de
precedencia. Son ms difciles de leer que un
diagrama de Gantt, pero a su vez permiten un anlisis
ms complejo del proceso, como la identificacin de caminos crticos.
85
Los
principales
elementos.
De
acuerdo
al
86
87
Elementos Basicos (Basic Elements): define los elementos bsicos, que son
refinados en otros paquetes.
Estructura del Proceso (Process Structure), define los principales conceptos del
proceso, como artefactos (arttfacts), roles (roles), o productos de trabajo (work
items).
88
Promenade
PROMENADE (Franch y RibO, 1999; 2003) es un lenguaje para la modelizacin de
procesos software que utiliza UML para describir sus constructores, mediante la
generacin de un profile.
89
Spem
SPEM (Software Process Engineering Metamodel) es
una especificacin de OMG (2002). SPEM describe
un metamodelo genrico para la descripcin de
procesos software concreto. Est basado en MOF y
utiliza UML como notacin de modelado. Por tanto,
se basa en los principios de orientacin a objetos. En esta propuesta no se da
soporte a la ejecucin (enactment) de los procesos, es decir, la planificacin y
ejecucin de proyectos usando un modele de proceso descrito con SPEM.
90
SMSDM
El
metamodelo
SMSDM
(Standard
Metamo
del
for
Software
Development
91
Entorno
PSEE
TEMA 3
Competencia:
Comprender los diferentes entornos de
ingeniera del software orientados al
proceso.
92
Un elemento clave del entorno constituye el motor del proceso (process engine) que
es el encargado de guiar y ayudar a las personas a la hora de llevar a cabo las
distintas actividades del proceso, y automatiza la ejecucin de las actividades que no
requieren intervencin humana. El motor de procesos est constituido por los
siguientes elementos:
93
El Entorno PSEE
Entorno de ingeniera del software orientado al proceso
Controla
Proceso de Gestin
Proceso de Produccin
Realimenta Soporta
PSEE
Integra
Tecnologa de
Gestin
Proporciona
Explota
Tecnologa de
Procesos
Proporciona
Estandariza
Integra
Tecnologa de
Produccin
Proporciona
Justifica
Entorno exterior
Un PSEE tambin tiene que tener la capacidad para compartir datos con el
exterior mediante canales de importacin y exportacin, que permitan el
intercambio de productos y modelos en un formato de comunicacin
reconocible.
94
Otro de los aspectos clave de los PSEE es el tipo de soporte que ofrecen a los
usuarios, distinguindose entre cuatro posibles tipos (Bandinelli et aI., 1996):
Rol Pasivo. El usuario gua el proceso y el PSEE opera en respuesta a las
peticiones del usuario.
Gua Activa. El PSEE gua el proceso y pregunta al usuario cuando es
necesario, recordndoles en todo momento que actividades debern realizar. Los
usuarios son libres para decidir y realizar las
acciones sugeridas por el entorno.
Obligacin. El PSEE fuerza a los usuarios a
actuar tal y como se ha especificado en el
modelo de procesos.
Automatizacin.
El
PSEE
ejecuta
las
95
Un mismo PSEE puede adoptar distintas formas de soporte al usuario, como por
ejemplo adoptar el enfoque de automatizacin para
actividades que no requieren la intervencin de los
usuarios y el de obligacin para el resto.
Tambin es posible clasificar los PSEE en funcin de la
forma de controlar y guiar el proceso. En este caso se
distingue entre PSEE Proactivos, en los que el
entorno inicia y controla las operaciones realizadas por las personas y Reactivos en
los que el entorno queda subordinado a los usuarios.
96
Tambin implica que el PSEE debe ser capaz de dar soporte a la comunicacin,
coordinacin, cooperacin y negociacin entre los usuarios realizadores con sus
diferentes roles.
EI PSEE debe dar soporte a la evolucin de procesos software: tanto
evolucin "off-line" como "on-line". En este caso deben tenerse en cuenta las
consecuencias en los procesos que estn en curso y en los que ya han
sobrepasado el punto de cambio en el modelo. Los PSEE tambin deben dar
soporte a la evolucin privada: el cambio ser local a la instancia de modelo de
proceso que se est ejecutando. Las desviaciones del proceso respecto del
modelo deben ser soportadas y negociadas y su impacto debe ser gestionado.
Ejemplos de PSEE
En este apartado se ilustran las caractersticas de los
PSEE mediante la presentacin de algunos ejemplos
representativos de la bibliografa.
Spade
El entorno SPADE (Bandinelli et aI., 1993; 1995: 1996) es un PSEE diseado en la
Universidad Politcnica de Miln que proporciona soporte al anlisis, diseo y
ejecucin de los procesos software. Para el modelado de los procesos utiliza el
formalismo SLANG (SPADE Language), que es un LMP basado en una extensin de
Redes de Petri a alto nivel. En SLANG un proceso se describe como una jerarqua de
actividades.
97
Apel
APEL (Dami et al., 1998; Estublier et al., 1998: 2003) es un PSEE desarrollado en el
Laboratoire Logiciels, Systemes, Reseallx, en Francia. Los objetivos fundamentales
que persigue se basan en dar soporte a la:
1. Interoperabilidad entre PSEE heterogneos, permitiendo al desafiador del
proceso construir una "federacin" de PSEE capaces de gestionar procesos
complejos y distribuidos.
2. Evolucin del Proceso, con el fin de hacer frente a situaciones imprevistas
durante la ejecucin.
98
Arquitectura SPADE
APEL tiene dos formas de representacin del proceso: significa, destinada a usuarios
finales del proceso y para descripciones del proceso a alto nivel y textual, para
usuarios avanzados y herramientas.
Un
editor
grfico
para
capturar
modelar
procesos.
o
99
Servidor de Eventos, que captura y gestiona todos los eventos (tal y como se
han definido en el modelo de procesos).
pueden
tener
estados,
que
varan
como
100
Ciclo
TEMA 4
de
Vida
Competencia:
Reconocer los diversos procesos en el ciclo de
vida del software.
101
La norma ISO 12207 entiende por modelo de ciclo de vida "Un marco de referencia
que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la
explotacin y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la
definicin de los requisitos hasta la finalizacin de su uso".
Por otro lado, la norma ISO 15288 (ISO, 2003) define ciclo
de vida de los sistemas como "la evolucin en el tiempo
de un sistema de inters desde su concepcin hasta su
retirada", destacando que un modelo de ciclo de vida es
"un marco de procesos y actividades relativas al ciclo de
vida que acta tambin como una referencia para la comunicacin y el entendimiento".
102
El ciclo de vida abarca, por tanto, toda la vida del sistema, comenzando con su
concepcin y finalizando cuando ya no se utiliza. A veces tambin se habla de
"ciclo de desarrollo", que es un subconjunto del anterior y que empieza en el
anlisis y finaliza con la entrega del sistema al usuario.
Procesos principales
Los procesos principales son aquellos que son tiles a las personas que inician o
realizan el desarrollo, la explotacin o el mantenimiento del software durante su ciclo
de vida. Los procesos principales son:
103
104
elementos
consistentes
de
con
software
el
diseo
Prueba
del
software,
cuyo
objetivo
es
Integracin del sistema, cuyo objetivo es integrar los elementos del sistema
(incluyendo elementos software, elementos hardware, operaciones manuales, y
otros sistemas) para producir un sistema completo que satisfaga el diseo del
sistema y las expectativas de los clientes expresadas en los requisitos del
sistema.
105
106
Lecturas Recomendadas
PROCESO DE SOFTWARE
http://www.congresoson.gob.mx/ISO/normas/normatividad_conceptos.pdf
Actividades y Ejercicios
107
Autoevaluacin
108
109
Resumen
Los diagramas de Gantt y los diagramas PERT son representaciones graficas de los
procesos en el que se incluyen las tareas, su duracin y sus relaciones de
precedencia. PROMENADE es un lenguaje para la modelizacin de procesos software
que utiliza UML. SPEM describe un metamodelo genrico para la descripcin de
procesos software concreto. El metamodelo SMSDM, establece un marco de trabajo
para la definicin y extensin de metodologas de desarrollo de software.
Los Entornos de Ingeniera del Software Orientados al Proceso (PSEE), dan soporte a
los procesos de ingeniera, usados para concebir, disear, desarrollar y mantener un
producto software. Un elemento clave del entorno constituye el motor del proceso.
Todo PSEE est caracterizado por el lenguaje de modelado de procesos (LMP) que
utiliza.
El modelo de ciclo de vida es un marco de referencia que contiene los procesos, las
actividades y las tareas involucradas en el desarrollo, la explotacin y el
mantenimiento de un producto de software, abarcando la vida del sistema desde la
definicin de los requisitos hasta la finalizacin de su uso. Las actividades que se
pueden realizar durante el ciclo de vida del software se agrupan en procesos
principales, procesos de soporte y procesos generales.
110
111
Introduccin
a) Presentacin y contextualizacin
Los temas que se desarrollan en la presente unidad tienen por finalidad de que el
alumno conozca que hoy en da la calidad del software no puede garantizarse
nicamente centrando los programas de calidad en el producto, dado que, tal y
como se ha comentado la calidad final del producto software est directamente
relacionado con la forma en que se desarrolla y mantiene, es decir, con el
proceso. Todo ella ha motivado en gran medida que las organizaciones dedicadas
al desarrollo y mantenimiento del software se preocupen cada vez ms de la
mejora de sus procesos.
b) Competencia
Identifica los diferentes modelos de mejora y evaluacin de procesos del
producto software.
c) Capacidades
1.
2.
3.
4.
d) Actitudes
112
Medicin
de
TEMA 1
Sistemas
de
Informacin
Competencia:
Conocer la
Medicin de Sistemas de
Informacin
proporcionadas
a
las
organizaciones.
113
El estndar ISO 90003 surge debido a que la gestin de la calidad que propone ISO
9001 aun siendo un buen marco de partida, es excesivamente general y se queda
corta para abordar proyectos de diseo e implantacin de sistemas de gestin de la
calidad ms especializados. Las directrices proporcionadas en esta norma
internacional no estn enfocadas a ser utilizadas como criterios de evaluacin en la
certificacin y registro del sistema de gestin de la calidad.
114
CMM (SEI, 1995) es el modelo propuesto por el SEI como referencia para determinar
la capacidad de los procesos software de una organizacin. CMM proporciona a las
organizaciones de software el modelo de referencia necesario
como soporte para el control de sus procesos de desarrollo y
mantenimiento y para facilitar su evolucin hacia una cultura de la
Ingeniera del Software y de excelencia en la gestin. Es un
modelo con la finalidad de:
115
116
117
Prcticas Clave. Constituyen los ejemplos de que se debe hacer para satisfacer
los objetivos de un rea clave de proceso sin entrar en detalle de cmo hacerlo.
Para poder conocer el nivel de madurez de una organizacin
es necesario realizar la evaluacin de sus procesos
software. Por este motivo y con el fin de proporcionar el
medio necesario para realizar evaluaciones basadas en
CMM y para poder comparar los resultados de evaluacin se cre el marco de
trabajo CAF (CMM Appraisal Framework), que identifica los requisitos y
caractersticas necesarias en un mtodo de evaluacin basado en CMM para
mejorar la consistencia y la fiabilidad de los diferentes mtodos de evaluacin y
sus resultados.
Los dos principales mtodos de evaluacin basados en CMM son SCE (Software
Capability Evaluation) y CBA-IPI (CMM - Based Appraisal for Internal Process
Improvement). Por otra parte, el marco de mejora de procesos del SEI, basado en
CMM, lo constituye el modelo IDEAL. A continuacin se resumen todos ellos.
118
119
120
121
Las actividades y alcance del proceso de evaluacin del mtodo CBA-IPI son
bsicamente los mismos que en el mtodo SCE (planificacin, conduccin y
generacin de informes). En realidad, CBA-IPI es muy similar a SCE con la diferencia
fundamental de que CBA IPI es una evaluacin centrada en la mejora de procesos,
mientras que SCE suele orientarse ms a la seleccin de suministradores, aunque
tambin se puede usar para la evaluacin interna de procesos.
122
123
El
Modelo Ideal
y el
TEMA 2
Proceso de
Software
Personal
Competencia:
Analizar el modelo ideal y el proceso de
software personal para la mejora de procesos.
124
un
El modelo IDEAL est compuesto por cinco fases, cada una de las cuales esta
formada por una serie de actividades:
Respecto
la
infraestructura,
se
establecen
dos
125
126
Estos artefactos son aadidos a la base de datos del proceso, que constituye una
fuente de informacin muy relevante para el personal implicado en la prxima iteracin
por las fases del modelo. La informacin reunida permite realizar una evaluacin sobre
la estrategia, los mtodos y la infraestructura utilizada en el programa de mejora, lo
que permite su conexin y ajuste de cara a futuras mejoras. Es necesario plantear
algunas preguntas, como por ejemplo sobre el rendimiento de la infraestructura
(equipos de trabajo MSG, SEPG, TWG, etc.) y los mtodos empleados por los TWG
en sus actividades de desarrollo de la solucin. Una respuesta adecuada a cada una
de estas preguntas es fundamental para plantear el siguiente ciclo del modelo IDEAL.
127
Al igual que en CMM, PSP se basa sobre los principios de mejora del proceso, sin
embargo, mientras que CMM se centra en mejorar la capacidad de la organizacin,
PSP se centra en la mejora de los ingenieros software aplicando la gestin y control
del proceso a nivel individual. Con PSP los ingenieros desarrollan software usando un
enfoque disciplinado y estructurado, siguiendo un proceso definido y planificando,
midiendo, realizando un seguimiento de su trabajo, gestionando la calidad del producto
y aplicando la realimentacin obtenida para mejorar sus procesos de trabajo
individuales.
Entre los beneficios que PSP ofrece a los ingenieros de software destacan los
siguientes:
128
Estos resultados son obtenidos haciendo que los participantes recopilan datos
especficos relacionados con el proceso y el producto y estableciendo la lnea base
que proporcione a los ingenieros con un contexto para mejorar el proceso.
Para alcanzar un nivel se deben cumplir los requisitos establecidos en los niveles
previos, ms los nuevos impuestos en dicho nivel.
129
PASO
FASE
DESCRIPCION
planificar
planificar el trabajo
disear
disear el programa
codificar
compilar
probar
implementar el diseo
compilar el programa y corregir y registrar los
defectos
realizar las pruebas del programa y corregir
postmorten
Las tres medidas base de PSP son: tiempo de desarrollo, defectos y tamao. Todas
las dems medidas en PSP son derivadas de las anteriores. EI proceso de medicin
en PSP se introduce desde las tres primeras asignaciones del proceso en los niveles
PSPO y PSPO.1. En la siguiente tabla se muestran ejemplos de los formularios que se
utilizan para el registro de tiempos y defectos:
COMIENZO
FIN
Tiempo. Interrup
T. DELTA
FASE
COMENTARIOS
13/05/2005
7:58
8:45
44
planificar
llamada telefnica
8:47
10:29
100
disear
7:49
8:59
70
codificar
9:15
9:46
31
compilar
compilar y enlazar
9:47
10:10
23
probar
ejecutar pruebas A B y C
4:33
4:51
16
postmortem
Gestin Personal del Proyecto (PSP1 Y PSP 1.1), se centra en las tcnicas para la
gestin del proyecto a nivel individual. Se introducen mtodos para la
estimacin del esfuerzo y planificacin y seguimiento de calendario. Las
estimaciones de tamao y esfuerzo se realizan usando el mtodo
PROBE (Proxy-Based Estimating), con el que los ingenieros usan el
tamao relativo del Proxy, como por ejemplo objetos, puntos funcin,
procedimientos, y los transforman a lneas de cdigo (LOC).
130
131
no
exponenciales,
en
grandes
proyectos.
132
Proceso
de Software
de Equipo
TEMA 3
y el
Modelo CMM
Competencia:
Describir el proceso de software de equipo y el
modelo CMM que se implantan en las
empresas.
133
Este
hecho
cre
una evidencia
muy
significativa sobre los beneficios que los ingenieros obtendran al usar PSP: les
permitira tener el control de su proceso personal mediante la mejora de sus
habilidades de estimacin y la reduccin de los defectos introducidos en los productos
sin afectar a su productividad. Sin embargo no quedaba claro como los ingenieros
podran aplicar estas habilidades en la prctica dentro de las empresas. Como
resultado no se aplic PSP de forma efectiva en la industria salvo en algunas
empresas.
134
como
guiones
ms
que
como
las
libros
de
definici6n
de
los
procesos
de
la
Antes de que los miembros puedan participar en un equipo TSP, deben conocer como
realizar un trabajo disciplinado. Tal y como se muestra en la figura de abajo, es
necesario que los ingenieros que usan TSP estn formados en PSP. La formacin en
PSP incluye el aprendizaje necesario para: realizar planes detallados, reunir y usar
datos del proceso, desarrollar planes, usar los valores obtenidos para realizar un
seguimiento del proyecto, medir y gestionar la calidad del producto y definir y usar
procesos operacionales. En TSP, la tarea de construir el equipo es un proceso de
planificacin de cuatro das denominado lanzamiento del equipo (team launch).
135
En
completado este proceso inicial, el equipo sigue su proceso definido para hacer el
trabajo necesario.
De acuerdo a TSP, los equipos son relanzados peridicamente. Ello se debe a que
TSP sigue una estrategia de desarrollo iterativa y evolutiva, lo que hace que los
relanzamientos peridicos sean necesarios de forma que cada fase o ciclo pueda ser
planificado de acuerdo al conocimiento obtenido en los ciclos previos. El relanzamiento
tambin es necesario para actualizar los planes detallados de los ingenieros, que
normalmente son precisos solo para unos pocos meses.
136
En cada relanzamiento los equipos hacen un plan global y un plan detallado de los tres
meses o cuatro meses posteriores. Durante cada lanzamiento del equipo tambin se
elabora el plan de calidad. Para gestionar la calidad los equipos establecen mtricas y
objetivos de calidad as como planes para alcanzar dichos objetivos y los medios para
conocer el progreso y llevar a cabo acciones colectivas cuando no se satisfacen los
objetivos. TSP ensea a los equipos como deben realizar este proceso de gestin de
calidad mediante guiones en los que se definen las mtricas a usar como parte del
proceso.
Las mtricas pueden ser de tamao (por ejemplo en miles de lneas de cdigo, KLOC),
tiempo (en minutos y horas), calidad (en forma de defectos),
rendimiento del proceso (% de defectos eliminados antes de
una fase determinada) y densidad de defectos (defectos
KLOC) de los productos obtenidos. En TSP se establece
como estas mtricas son definidas, estimadas, recopiladas,
presentadas y analizadas. Tambin se hace uso en el
proceso de datos histricos de los equipos, y de lneas gua sobre calidad y
planificacin.
137
138
El
Estndar
TEMA 4
ISO/IEC 15504
Competencia:
Aplicar la norma estndar ISO/IEC 15504 en la
evaluacin de software.
v
139
La parte informativa del estndar proporciona la gua necesaria sobre cmo utilizar un
proceso de evaluacin dentro de un programa de mejora o dentro de un tipo de
proceso para la determinacin de la capacidad.
El estndar est compuesto por cinco partes (que sustituyen las nueve partes de la
versin anterior de 1998), y de las cuales la quinta se encuentra actualmente en
preparacin.
140
141
CMMI Y SCAMPI
El xito y amplia aceptacin de CMM propicio la aparicin de modelos similares
incluso en otras disciplinas adems del software. Esta
proliferacin de modelos ha facilitado la aparicin de conflictos
en los objetivos y tcnicas de la mejora de procesos, debido al
considerable incremento en el entrenamiento requerido, y a la
confusin por parte de los que los aplican de cul de los modelos usar segn sus
necesidades especficas. CMMI constituye un solo modelo que cubre mltiples
disciplinas y se cre con el objetivo de eliminar esas desventajas.
El proyecto CMMI persigue objetivos tanto a corto como a largo plazo. Los objetivos
iniciales (los cuales se llevaron a cabo en el 2000 con la publicacin de la versin 1.0
de los modelos CMMI-SE/SW y CMMI-SE/SW/IPPD) consistan en integrar tres
modelos de mejora de procesos especficos: software, ingeniera de sistemas y
desarrollo de procesos y productos integrados. CMMI-SE/S\V especifica el modelo
CMMI que contiene las disciplinas de ingeniera de sistemas y software.
CMMI-SE/SW/IPPD indica el modelo que aade material para la integracin de
procesos y desarrollos de procesos en CMMI-SE/SW.
142
Los objetivos a largo plazo consisten en establecer la base necesaria para la posterior
inclusin de otras disciplinas (tales como adquisicin y seguridad). Para facilitar
ambos modelos de integracin actuales y futuros, el equipo de desarrollo de CMMI
cre un marco de trabajo automatizado y extensible y defini reglas para la posible
inclusin de ms disciplinas dentro de este marco de trabajo.
Modelos de CMMI
143
Otro aspecto importante y muy novedoso en el modelo CMMI, es que usa dos tipos de
representaciones de sus modelos, incluyendo de esta forma la representacin de
CMM y la representacin de ISO 15504: representacin por etapas y continuo.
144
Representacin contina
Los modelos continuos proporcionan una gua menos
especfica con respecto al orden en el cual debera realizarse
el proceso de mejora. Se denominan continuos porque
ninguna etapa discreta est asociada con la madurez de la
organizacin. Como los modelos por etapas, los modelos
continuos tienen reas de procesos que contienen prcticas. A diferencia de los
modelos por etapas, las prcticas de un rea de procesos en un modelo continuo
estn organizadas de forma que dan soporte a la mejora y al crecimiento de procesos
individuales. La mayora de las prcticas asociadas con la mejora de procesos son
genricas; son externas a las reas de procesos individuales y son aplicables a todas
las reas de procesos. Las prcticas genricas estn agrupadas bajo niveles de
capacidad, cada una de las cuales tiene una definicin que es casi equivalente a la
definicin de niveles de madurez en los modelos por etapas.
145
Lecturas Recomendadas
Actividades y Ejercicios
146
Autoevaluacin
147
7) PEOPLE-CMM se refiere al :
a. Modelo de planificacin de la produccin.
b. Modelo de madurez de capacidad de las personas.
c. Modelo de planificacin de madurez.
d. Modelo de la capacidad de planificar de las personas.
e. Modelo de planificacin de las personas.
148
Resumen
EI estndar ISO/IEC 15504 (ISO, 2004a; 2004b; 2004c: 2004d: 2006) proporciona un
marco de trabajo para la evaluacin de procesos software y establece los requisitos
mnimos para realizar una evaluacin que asegure la receptibilidad y consistencia de
las valoraciones obtenidas. El objetivo de la evaluacin del proceso es conocer la
capacidad de los procesos de una organizacin. Como resultado de una exitosa
implementacin de la evaluacin de los procesos se determina la informacin que
caracteriza los procesos evaluados y el punto hasta el cual los procesos realizan su
propsito.
149
Glosario
REPOSITORIO: Es aquel que consta de las tablas y vistas que se utilizan como
interfaz con los datos y el cdigo procedimental que las maneja. Almacena los
detalles del sistema que se est desarrollando
150
Fuentes de Informacin
BIBLIOGRFICAS:
ELECTRNICAS:
Calidad de software
http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF
Gestin de la calidad
http://www.uhu.es/eyda.marin/apuntes/gesempre/Tema5_1IGE.pdf
151
Solucionario
UNIDAD DE
APRENDIZAJE 1
1. B
2. C
3. A
4. B
5. D
6. A
7. A
8. C
9. A
10. C
UNIDAD DE
APRENDIZAJE 2:
1. A
2. D
3. E
4. A
5. B
6. C
7. D
8. E
9. B
10. C
11.
UNIDAD DE
UNIDAD DE
APRENDIZAJE 3:
APRENDIZAJE 4:
1. C
1. A
2. E
2. E
3. A
3. C
4. D
4. A
5. B
5. D
6. B
6. A
7. D
7. B
8. A
8. C
9. E
9. E
10. C
10. A
152