1

CAPTULO 9

2
3

PROCESO DE INGENIERA DEL SOFTWARE

4 ACRNIMOS
5
CMMI
EF
FP
HRM
IDEAL
OMG
QIP
SCAMPI
SCE
SEPG

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Modelo de Capacidad de Madurez Integrado

Creadora de Experiencia
Punto Funcin
Gestin de Recursos Humanos
(Modelo de) Iniciacin-DiagnsticoEstablecimiento-Actuacin-Apoyo
Grupo de Gestin de Objetos
Paradigma de Mejoras de la Calidad
Evaluacin Basada en el MCM para Mejoras
de los Procesos utilizando la CMMI
Evaluacin de la Capacidad del Software
Grupo de Proceso de la Ingeniera del
Software

INTRODUCCIN
El KA del Proceso de Ingeniera del Software
puede examinarse en dos niveles. El primer nivel
engloba las actividades tcnicas y de gestin dentro
de los procesos del ciclo de vida del software
realizadas durante la adquisicin, desarrollo,
mantenimiento y retirada del software. El segundo
es un meta-nivel, que se refiere a la definicin,
implementacin, valoracin, medicin, gestin,
cambios y mejoras de los procesos mismos del
ciclo de vida del software. El primer nivel lo
cubren las otras KAs en la Gua. Este KA se ocupa
del segundo nivel.
El trmino proceso de ingeniera del software
puede interpretarse de diversas maneras, y esto
puede llevar a confusiones.

23 Un significado, donde se usa la palabra el,

24
como en el caso de el proceso de ingeniera
25
del software, podra implicar que existe slo
26
un modo correcto de realizar tareas de
27
ingeniera del software. En la Gua se evita
28
este significado porque no existe tal proceso.
29
Los estndares como IEEE12207 hablan de
30
procesos de ingeniera del software, lo que
31
significa que
hay
muchos procesos
32
involucrados, tales como Procesos de
33
Desarrollo o Proceso de Configuracin de
34
Gestin.
35 Un segundo significado se refiere a una
36
discusin general sobre procesos relacionados

37
38
39
40

con la ingeniera del software. Este es el

significado que se pretende con el ttulo de esta
KA y el que se usa con ms frecuencia en la
descripcin del KA.

41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

73
74
75
76
77
78
79

DESCOMPOSICIN DE LOS TEMAS PARA EL

PROCESO DE INGENIERA DEL SOFTWARE

Finalmente, un tercer significado podra

referirse al conjunto actual de actividades
realizadas dentro de una organizacin, que
podra verse como un solo proceso,
especialmente desde dentro de la organizacin.
Se utiliza este significado en el KA en muy
pocos casos.

Esta KA se aplica a cualquier parte de la gestin de

los procesos del ciclo de vida del software en la
que se introduzcan cambios de procedimiento o
tecnolgicos para la mejora de procesos o
productos.
Los procesos de ingeniera del software tienen
importancia no slo para las grandes
organizaciones. Ms an, las actividades
relacionadas con los procesos pueden ser, y han
sido, realizadas con xito por pequeas
organizaciones, equipos e individuos.
El objetivo de gestionar los procesos del ciclo de
vida del software es implementar nuevos o mejores
procesos en las prcticas actuales, sean stos
individuales, proyectos u organizacionales.
Esta KA no aborda explcitamente la Gestin de
Recursos Humanos (HRM), por ejemplo, como lo
recoge el MCM de la Gente (Cur02) y procesos de
ingeniera de sistemas [ISO1528-028; IEEE 122098].
Tambin debera reconocerse que muchos temas de
procesos de ingeniera del software estn
relacionados de cerca con otras disciplinas, tales
como la gestin, incluso a veces utilizando una
terminologa diferente.

La Figura 1 muestra la descomposicin de los

temas en este KA:
1.

Proceso de Implementacin y Cambios

sta subrea se centra

organizacionales. Describe

en los cambios
la infraestructura,

1 actividades, modelos y consideraciones prcticas

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

2 de un proceso de implementacin y cambios.

Figura 1 Divisin de los temas para el KA del Proceso de Ingeniera Software

Aqu se describe la situacin en la que los procesos se

despliegan por primera vez (por ejemplo,
introduciendo un proceso de inspeccin en un
proyecto o un mtodo que cubra todo el ciclo de
vida), y donde se cambian lo procesos actuales (por
ejemplo, introduciendo una herramienta u
optimizando un procedimiento). A esto tambin se le
puede denominar proceso de evolucin. En ambos
casos hay que modificar las prcticas actuales. Si
resulta que se extienden las modificaciones, puede
que tambin sean necesarios cambios en la cultura
organizacional.
1.1. Infraestructura del Proceso
[IEEE12207.0-96; ISO15504; SEL96]
Este tpico incluye el conocimiento relacionado con
la infraestructura del proceso de ingeniera del
software.
Para establecer procesos de ciclo de vida del
software, es necesario que la adecuada infraestructura
est en su lugar, es decir que los recursos estn al

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

alcance de la mano (personal competente,

herramientas y financiacin) y que se hayan asignado
responsabilidades. El que se hayan completado estas
tareas, indica el compromiso con la gestin y
propiedad del esfuerzo del proceso de ingeniera del
software. Puede que haya que establecer diversos
comits, tales como un comit de direccin que
supervise el esfuerzo del proceso de ingeniera del
software.
En [McF96] se ofrece una descripcin de la
infraestructura de la mejora de los procesos en
general. En la prctica se utilizan dos tipos
principales de infraestructura: el Grupo de Proceso de
Ingeniera del Software y la Creadora de Experiencia.
1.1.1

Grupo de Proceso de la Ingeniera del

Software (SEPG)

Se pretende que el SEPG sea el foco central del

proceso de mejoras de la ingeniera del software y
tiene cierto nmero de responsabilidades en trminos

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

de inicializacin y mantenimiento. stos se describen

en [Fow90].

29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

1.1.2

Creadora de Experiencia (EF)

El concepto de EF separa la organizacin del

proyecto (la organizacin del desarrollo del software,
por ejemplo) de la organizacin de las mejoras. La
organizacin del proyecto se centra en el desarrollo y
en el mantenimiento del software, mientras que la EF
se ocupa del proceso de mejoras de la ingeniera del
software.
Se trata de que la EF institucionalice el aprendizaje
colectivo de una organizacin, desarrollando,
actualizando, y entregando a la organizacin del
proyecto los paquetes de experiencia (por ejemplo,
guas, modelos y cursos de entrenamiento), tambin
conocidos como validaciones de procesos. La
organizacin del proceso ofrece a la EF sus
productos, los planes utilizados en su desarrollo, y los
datos reunidos durante su desarrollo y operacin. En
[Bas92] se presentan ejemplos de paquetes de
experiencia.
1.2. Ciclo de Gestin del Proceso del Software
[Bas92; Fow90; IEEE12207.0-96; ISO15504-98;
McF96; SEL96]
La gestin de los procesos del software consiste en
cuatro actividades secuenciadas en un ciclo iterativo
permitiendo una retroalimentacin continua y
mejoras del proceso del software:

La actividad del Establecimiento de la

Infraestructura de un Proceso consiste en
establecer un acuerdo con el proceso de
implementacin y cambios (que incluya la
obtencin de la gestin de compra buy-in) y
levantar una adecuada infraestructura (recursos y
responsabilidades) para que tenga lugar.
El propsito de la actividad de Planificacin es
comprender los objetivos de las empresas
actuales y las necesidades del proceso del
individuo, proyecto u organizacin, para
identificar sus fuerzas y flaquezas, y elaborar un
plan para el proceso de implementacin y
cambios.
El propsito del Proceso de Implementacin y
Cambios consiste en llevar a cabo el plan,
desplegar nuevos procesos (que pueden implicar,
por ejemplo, el desarrollo de herramientas y el
entrenamiento del personal) y/o cambiar
procesos ya existentes.
La Evaluacin del Proceso se encarga de
descubrir lo bien que se ha llevado a cabo la
implementacin y cambios, y si se materializaron
o no los beneficios esperados. Los resultados se
utilizarn ms adelante como entradas para ciclos
subsiguientes.

1.3. Modelos Para el Proceso de Implementacin y

Cambios

57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

Han surgido dos modelos generalizados para llevar a

cabo el proceso de implementacin y cambios que
son el Paradigma de Mejoras de la Calidad (QIP)
[SEL96] y el modelo IDEAL [McF96]. En [SEL96]
se comparan los dos paradigmas. La evaluacin del
proceso de implementacin y de los resultados de los
cambios pueden ser cualitativos o cuantitativos.

1.4. Consideraciones Prcticas

El proceso de implementacin y cambios constituye
una instancia del cambio organizacional. Los
esfuerzos de ms xito en los cambios
organizacionales tratan del cambio como un proyecto
en toda regla, con planes adecuados, monitoreo y
revisiones.
En [Moi98; San98; Sti99] se encuentran las
directrices sobre el proceso de implementacin y
cambios dentro de las organizaciones de ingeniera
del software, incluyendo la planificacin de las
acciones, entrenamientos, gestin de patrocinadores,
compromisos, y la seleccin de proyectos piloto, y
abarcan tanto los procesos como las herramientas. En
[EIE99a] se sealan los estudios empricos sobre
factores de xito para los cambios en los procesos.
El papel de los agentes de cambio en esta actividad se
discute en (Hut94). El proceso de implementacin y
cambios puede verse asimismo como una instancia de
consultora (sea interna o externa).
Uno tambin puede ver cambios organizacionales
desde la perspectiva de la transferencia de tecnologa
(Rog83). Los archivos de ingeniera del software que
se ocupan de la transferencia de tecnologa y de las
caractersticas de los recipientes de nuevas
tecnologas (que podran incluir tecnologas
relacionadas con los procesos) son (Pfl99; Rag89).
Hay dos formas de acercarse la evaluacin de un
proceso de implementacin y cambios, sea en
trminos de cambios al proceso mismo o en trminos
de cambios en las salidas de los procesos (por
ejemplo, midiendo lo que te devuelve una inversin
tras realizar un cambio). Una visin pragmtica de lo
que se puede lograr con estas evaluaciones se nos da
en (Her98).
Las investigaciones sobre cmo evaluar el proceso de
implementacin y cambios, y los ejemplos de
estudios dedicados a ello, se encuentran en [Gol99],
(Kit98; Kra99; McG94).
2.

Definicin de Procesos

Una definicin de un proceso puede ser un

procedimiento, una poltica, o un estndar. Los
procesos de ciclo de vida del software se definen por
muchas razones, que incluira el incrementar la
calidad del producto, el facilitar el entendimiento y la
comunicacin humana, apoyar las mejoras de los
procesos, apoyar la gestin de los procesos,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

suministrar una gua automatizada para los procesos,

y suministrar un apoyo para ejecuciones
automatizadas. Los tipos de definiciones de procesos
requeridos dependern, al menos parcialmente, de las
razones para la definicin.
Habra que sealar tambin que el contexto del
proyecto y de la organizacin determinar el tipo de
definicin del proceso que resulte ms til. Algunas
variables importantes que hay que considerar
incluyen la naturaleza del trabajo (por ejemplo,
mantenimiento o desarrollo), el dominio de la
aplicacin, el modelo de ciclo de vida, y la madurez
de la organizacin.
2.1. Modelos de Ciclo de Vida del Software
[Pf101:c2; IEEE12207.0-96]
Los modelos del ciclo de vida del software sirven
como definiciones de alto nivel de las fases que
tienen lugar durante el desarrollo. No estn enfocadas
a ofrecer definiciones detalladas sino ms bien a
sobresaltar
las
actividades
clave
y
sus
interdependencias. Algunos ejemplos de modelos de
ciclo de vida del software son el modelo de cascada,
el modelo de prototipado de usar y tirar lo
desechable,
desarrollo
evolutivo,
entrega
incremental/iterativa, el modelo en espiral, el modelo
de software reutilizable, y la sntesis de software
automatizado. Las comparaciones entre estos
modelos se encuentran en [Como97], (Dav88), y hay
un mtodo para seleccionar entre muchos de ellos en
(Ale91).
2.2. Procesos del Ciclo de Vida del Software
Las definiciones de los procesos de ciclo de vida del
software tienden a ser ms detalladas que los modelos
de ciclo de vida del software. Sin embargo, los
procesos del ciclo de vida del software no pretenden
ordenar sus procesos en el tiempo. Esto significa que,
en lnea de principio, los procesos del ciclo de vida
del software pueden ordenarse para tener cabida en
cualquiera de los modelos del ciclo de vida del
software. La principal referencia sobre esta rea se
encuentra en IEEE/EIA 12207.0: Informacin
Tecnolgica Procesos del Ciclo de Vida del
Software [IEEE 12207.0-96].
El estndar IEEE 1074:1997 para desarrollar procesos
de ciclo de vida ofrece tambin una lista de procesos
y actividades para el desarrollo y el mantenimiento
del software [IEEE1074-97], adems de ofrecer una
lista de actividades del ciclo de vida que pueden
mapearse hacia procesos y organizarse del mismo
modo que cualquiera de los modelos de ciclo de vida
del software. Adems, identifica y une a estas
actividades otros estndares de software IEEE. En
lnea de principio, el estndar IEEE 1074 puede
utilizarse para construir procesos de acuerdo a
cualquiera de los modelos de ciclo de vida. Los
estndares enfocados al mantenimiento de procesos

57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

son el estndar IEEE 1219-1998 y la ISO 14764:1998

[IEEE 1219-98].
Otros
estndares
importantes
definiciones de procesos son:

que

ofrecen

Estndar IEEE 1540: Gestin de Riesgos del

Software.
Estndar IEEE 1517: Procesos de Reutilizacin
del Software (IEEE 1517-99).
ISO/IEC 15939: Proceso de Medicin del
Software [IEEE 15939-02]. Ver tambin el KA
de Gestin de Ingeniera del Software para una
descripcin detallada de este proceso.

En algunas ocasiones se han de definir los procesos

de ingeniera del software tomando en cuenta los
procesos organizacionales para la gestin de la
calidad. La ISO 9001 ofrece los requisitos para los
procesos de gestin de la calidad y la ISO/IEC 90003
interpreta esos requerimientos para organizaciones
que desarrollan software (ISO90003-04).
Algunos procesos del ciclo de vida del software
ponen nfasis en entregas rpidas y en una fuerte
participacin de los usuarios, como por ejemplo
mtodos giles tales como la Programacin Extrema
[Bec99]. Un tipo de problema de seleccin tiene que
ver con la eleccin realizable a lo largo del eje del
mtodo basado en planificacin. Un acercamiento
basado en riesgos para tomar tal decisin se describe
en (Boe03a).
2.3. Notaciones para las Definiciones de los
Procesos
Se pueden describir los procesos en diferentes niveles
de abstraccin (por ejemplo, definiciones genricas
contrapuestas a definiciones adaptadas, descriptivas
contrapuestas a prescriptivas contrapuestas a
proscriptivas [Pf101].
Varios elementos de un proceso pueden definirse, por
ejemplo, actividades, productos (artefactos), y
recursos. Los marcos detallados que estructuran los
tipos de informacin requeridos para definir los
procesos estn descritos en (Mad94).
Existen algunas notaciones que se utilizan para
definir procesos (SPC92). Una diferencia clave entre
ellas reside en el tipo de informacin que definen,
capturan y utilizan los marcos mencionados
anteriormente. El ingeniero del software debera ser
consciente de las siguientes aproximaciones al
asunto: diagramas de flujo de datos, en trminos de la
finalidad del proceso y de las salidas [ISO15504-98],
como una lista de procesos descompuestos en
actividades constituyentes y tareas definidas en
lenguaje natural [IEEE12207.0-96], Grficos de
Estados (Har98), EVTX (Rad85), modelado de
Dependencia del Actor (Yu94), notacin SADT
(Mcg93), redes Petri (Ban95); IDEF0 (IEEE 1320.198), y los basados en reglas (Bar95). Ms
recientemente, un estndar de modelado del proceso

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

ha sido publicado por el OMG que tiene como fin

armonizar las notaciones de modelado. A esto se le
llama la especificacin MPIS (Meta-Modelo del
Proceso de Ingeniera del Software). [OMG02]
2.4. Adaptacin del Proceso
[IEEE 12007.0-96; ISO15504-98; Joh99]
Es importante sealar que los procesos predefinidos
incluso los estandarizados deben adaptarse a las
necesidades locales, por ejemplo, el contexto
organizacional, el tamao del proyecto, los requisitos
reguladores, las prcticas industriales y las culturas
corporativas. Algunos estndares, tales como
IEEE/EIA 12207, contienen mecanismos y
recomendaciones para lograr la adaptacin.
2.5. Automatizacin
[Pf101:c2]
Las herramientas automatizadas o apoyan la
ejecucin de las definiciones del proceso o aportan
una gua a los humanos que desarrollan los procesos
definidos. En los casos en los que se realiza el
anlisis de un proceso, algunas herramientas permiten
distintos tipos de simulaciones (por ejemplo, la
simulacin de un evento discreto).
Adems, existen herramientas que apoyan cada una
de las notaciones de la definicin del proceso citados
anteriormente. Ms an, estas herramientas pueden
ejecutar las definiciones de procesos para otorgar una
ayuda automatizada a los procesos actuales, o en
algunos casos para automatizarlos plenamente. Una
visin general de las herramientas de modelado de
procesos puede encontrarse en [Fin94] y de los
entornos centrados en procesos en (Gar96). Los
trabajos sobre cmo aplicar Internet al suministro de
una gua de un proceso en tiempo real est descrita en
(Kel98).
3.

Valoracin del Proceso

La valoracin del proceso se lleva a cabo utilizando

tanto un modelo de valoracin como un mtodo de
valoracin. En algunas instancias, el trmino
apreciacin se utiliza en vez de valoracin, y el
trmino evaluacin de la capabilidad se utiliza
cuando el apreciacin tiene como propsito la
adjudicacin de un contrato.
3.1. Modelos de Valoracin del Proceso
Un modelo de valoracin recoge lo que se reconoce
como buenas prcticas. Estas prcticas pueden
referirse slo a las actividades tcnicas de ingeniera
del software, o puede que se refieran tambin, por
ejemplo, a actividades de gestin, de ingeniera de
sistemas, y tambin de gestin de recursos humanos.
La ISO/IEC 15504 [ISO15504-98] define un modelo
ejemplar de valoracin y de requisitos de
conformidad con otros modelos de valoracin. Los
modelos de valoracin especficos disponibles y en
uso son SW-CMM (SEI95), CMMI [SEI01], y

56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110

Bootstrap [Sti99]. Se han definido muchos otros

modelos de capacidad y madurez por ejemplo, para
diseo, documentacin y mtodos formales, por
nombrar algunos. La ISO 9001 es otro modelo comn
de validadcin que ha sido aplicado por
organizaciones de software (ISO9001-00).
Se ha desarrollado asimismo un modelo de madurez
para sistemas de ingeniera, que puede resultar til
cuando un proyecto u organizacin est implicado en
el desarrollo y mantenimiento de sistemas, incluido el
software (EIA/IS731-99).
En [Joh99; San98] se examina la aplicabilidad de los
modelos de valoracin a pequeas organizaciones.
Existen dos arquitecturas generales para un modelo
de valoracin que ofrecen diversas conjeturas sobre el
orden en el que los procesos han de ser valorados:
continua y escalonadamente (Pau94). Son muy
diferentes entre s y la organizacin debera
evaluarlos sopesndolos para determinar cules son
los ms pertinentes para sus necesidades y objetivos.

3.2. Mtodos de Valoracin del Proceso

[Go199]
Para poder realizar una valoracin, se necesita seguir
un mtodo especfico de valoracin para producir un
resultado cuantitativo que caracterizara la capacidad
del proceso (o madurez de la organizacin).
El mtodo de valoracin CBA-IPI, por ejemplo, se
centra en la mejora de proceso (Dun96), y el mtodo
SCE se centra en evaluar la capacidad de los
proveedores (Bar95). Ambos mtodos fueron
desarrollados para el SW-CMM. En [ISO15504-98],
(Mas95) se ofrecen los requisitos de ambos tipos de
mtodos que reflejan lo que se cree que seran buenas
prcticas de valoracin. Los mtodos SCAMPI giran
en torno a las valoraciones CMMI [SEI01]. Las
actividades realizadas durante una valoracin, la
distribucin de esfuerzos en estas actividades, as
como la atmsfera durante una valoracin son muy
diferentes dependiendo de que sean para una mejora o
para la adjudicacin de un contrato.
Se han criticado los modelos y mtodos de las
valoraciones de los procesos, por ejemplo (Fay97;
Gra98). La mayora de estas crticas se refieren a la
evidencia emprica que apoya el uso de modelos y
mtodos de valoracin. Sin embargo, desde la
publicacin de estos artculos, ha existido alguna
evidencia sistemtica que apoyaba la eficacia de las
valoraciones de los procesos (Cla97; Ele00; Ele00a;
Kri99).
4.

Medicin de los Procesos y Productos

Mientras que la aplicacin de mediciones a la

ingeniera del software puede resultar compleja,
particularmente en trminos de mtodos de modelado

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

y anlisis, existen varios aspectos de las mediciones

en la ingeniera del software que resultan
fundamentales y que estn a la base de muchos de los
procesos de medicin y anlisis ms avanzados. Ms
an, los esfuerzos para mejorar el logro de procesos y
productos slo puede valorarse si se ha establecido un
conjunto de medidas de base.
La medicin puede realizarse para apoyar la
iniciacin de un procesos de implementacin y
cambio o para evaluar las consecuencias de un
proceso de implementacin y cambio, o puede
realizarse en el producto mismo.
La medicin puede realizarse para apoyar la
iniciacin de un procesos de implementacin y
cambio o para evaluar las consecuencias de un
proceso de implementacin y cambio, o puede
realizarse en el producto mismo.
Los trminos clave de medicin del software y de
mtodos de medicin han sido definidos en la
ISO/IEC 15939 basados en el vocabulario ISO
internacional de metrologa. La ISO/IEC 15359
tambin ofrece un proceso estndar para medir tanto
los procesos como las caractersticas de los productos
[VIM93].
A pesar de todo, los lectores encontrarn diferencias
terminolgicas en la literatura; por ejemplo, el
trmino mtrica se utiliza a veces en vez de
medida.
4.1 Medicin del Proceso
[ISO15539-02]
El trmino medicin del proceso, tal y como se
utiliza aqu, significa que se recoge, analiza e
interpreta informacin cuantitativa sobre el proceso.
Se utiliza la medicin para identificar las fuerzas y las
debilidades de los procesos y para evaluar los
procesos despus de que hayan sido implementados
y/o cambiados.
La medicin del proceso tambin puede servir para
otros propsitos. Por ejemplo, la medicin del
proceso es til para gestionar un proyecto de
ingeniera del software. Aqu, el enfoque est en la
medicin del proceso con el propsito de la
implementacin y cambio del proceso.

57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

que resultan importantes para la organizacin de la

empresa.
Mientras que se pueden hacer algunos esfuerzos para
valorar la utilizacin de herramientas y de hardware,
el recurso principal que necesita ser gestionado en la
ingeniera del software es el personal. Como
resultado de esto, las principales mediciones del
inters son aqullas relacionadas con la productividad
de los equipos o procesos (por ejemplo, utilizando
una medida de puntos funcin producidos por unidad
de persona-esfuerzo) y sus niveles asociados de
experiencia en la ingeniera del software en general, y
quizs en particulares tecnologas [Fen98: c3, c11;
Som05: c25].
Las salidas de los procesos pueden ser, por ejemplo,
calidad del producto (errores por KLOC (Kilo Lneas
de Cdigo) o por Punto Funcin (FP)),
mantenibilidad (el esfuerzo para hacer un cierto tipo
de cambio), productividad (LDC (Lneas de Cdigo))
o Puntos Funcin por persona-mes), tiempo-demercado, o satisfaccin del cliente (como medidos
por medio de una encuesta a clientes). Esta relacin
depende del contexto particular (por ejemplo, el
tamao de la organizacin o el tamao del proyecto).
En general, estamos mucho ms preocupados acerca
del proceso de salidas. Sin embargo, con el objetivo
de conseguir las salidas del proceso que deseamos
(por ejemplo, mayor facilidad de mantenimiento,
mayor satisfaccin del cliente), debemos haber
implementado los procesos adecuados.
Por supuesto que no son nicamente los procesos lo
que tiene incidencia en las salidas. Otros factores
como la capacidad del equipo y las herramientas que
utilizan juegan un importante papel. Por ejemplo,
cuando se evala el impacto de cambio en un
proceso, es importante poner de relieve esas otras
influencias. Adems es importante considerar el
grado en el que el proceso ha sido institucionalizado
(que fidelidad hay al proceso) para poder explicar
porqu buenos procesos no siempre proporcionan
las salidas deseadas en una situacin dada.

El diagrama de caminos de la Figura 2 ilustra algo

que se dar por supuesto en la mayora de los
proyectos de ingeniera del software, que indica que
normalmente el proceso tiene un impacto en los
resultados de un proyecto.
No todo proceso va a tener un impacto positivo en
todas sus salidas. Por ejemplo, la introduccin de
inspecciones del software puede reducir esfuerzos y
costes de las pruebas, pero puede incrementar el
tiempo de espera si cada inspeccin introduce largas
esperas a causa de haber calendarizado reuniones de
larga inspeccin (Vot93). Por tanto, es preferible
utilizar medidas para salidas de mltiples procesos

98
99 Figura 2 Diagrama que muestra la relacin entre un
100
proceso y los resultados obtenidos
101
102
103 Software Product Measurement
104 [ISO9126-01]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

La medicin de un producto software incluye,

principalmente, la medicin del tamao del producto,
la estructura del producto y la calidad del producto.
4.1.1

Medicin del Tamao

El tamao de un producto software es evaluado a

menudo mediante medidas de longitud (por ejemplo,
lneas de cdigo fuente en un mdulo, pginas en
documento de especificacin de los requisitos del
software), o funcionalidad (por ejemplo, puntos de
funcin en una especificacin). El Estndar IEEE Std
14143.1 proporciona los principios de medicin
funcional del software. Los estndares internacionales
para la medicin funcional del software incluyen el
ISO/IEC 19761, 20926, y el 20968 [IEEE 14143.100; ISO19761-03; ISO20926-03; ISO20968-02].
4.1.2

Medicin de la Estructura

L
4.1.3

Medicin de la Calidad

L
4.2. Calidad de los Resultados de Medicin
S
4.3 Modelos de Informacin del Software
L
4.3.1

Creacin de Modelos

L
4.3.2

Implementacin de Modelos

L
4.4 Tcnicas de Medicin del Proceso
S
4.4.1

Tcnicas Analticas

34 Estudios Experimentales: la experimentacin

35
implica
36 El Informe de Definicin del Proceso es un
37
medio de
38 La Clasificacin del Defecto Ortogonal es una
39
tcnica
40 El Anlisis de Causas desde la Raz es otra
41
tcnica analtica comn que se utiliza en la
42
prctica.
43 La tcnica de Clasificacin del Defecto
44
Ortogonal descrita arriba es
45 El Proceso de Control Estadstico es un modo
46
eficaz

47 El Proceso Personal de Software define una serie

48
de mejoras
49 4.4.2 Tcnicas de Bancos de Pruebas
50 L

[Sti99]

[Som05]

[SEL96]

[SEI01]

[San98]

[Pre04]

[Pfl01]

[OMG02]

[Mus99]

[Moi98]

[McF96]

[Joh99]

Gol99]

[Fow90]

[Fin94]

[Fen98]

[Com97]

[Boe03]

[Bec99]

[Bas92]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

[Abr96]

1
2

1.Proceso de Implementacin y Cambios

1.1Infraestructura del Proceso

1.2 Ciclo de Gestin del Proceso Software

1.3 Modelos para el Proceso de Implementacin y

Cambios

1.4 Consideraciones Prcticas

*
*

2.Definicin de Procesos
2.1Modelos de Ciclo de Vida del Software

2.2Procesos del Ciclo de Vida del Software

c2

2.3Notaciones para la Definicin de Procesos

2.4 Adaptacin del Proceso

2.5Automatizacin

c2

*
*

3.Valoracin del Proceso

c2

3.1Modelos de Valoracin de Procesos

3.2Mtodos de Valoracin de Procesos

c3,
c11
c8c10

4.1Medicin de Procesos
4.2Medicin de Productos Software
*

c25
c15

c24

c2

4.4Modelos de Informacin Software

Construccin del Modelo

4.Medicin de Productos y Procesos

4.3Caliddad de los Resultados de Medicin

c11
c4,
c6,c13

Implementacin del Modelo

c6

4.5 Tcnicas de Medicin de Procesos

c25
c3,
c11,c12
*

c22

c25

IEEE14143
.1

IEEE12207

IEEE 1540

IEEE 1517

IEEE 1219

IEEE 1074

IEEE 1061

IEEE 1044

ISO VIM

ISO20969

ISO20926

ISO19761

ISO15939

ISO15288

ISO15504

ISO14764

ISO9126

ISO9000-3

ISO9001
1.Proceso de Implementacin y Cambios
1.1Infraestructura del Proceso

1.2 Ciclo de Gestin del Proceso Software

1.3 Modelos para el Proceso de Implementacin y

Cambios
1.4 Consideraciones Prcticas
2.Definicin de Procesos
2.1Modelos de Ciclo de Vida del Software
2.2Procesos del Ciclo de Vida del Software

2.3Notaciones para la Definicin de Procesos

2.4 Adaptacin del Proceso

2.5Automatizacin
3.Valoracin del Proceso
3.1Modelos de Valoracin de Procesos

3.2Mtodos de Valoracin de Procesos

4.Medicin de Productos y Procesos

4.1Medicin de Procesos
4.2Medicin de Productos Software
4.3Caliddad de los Resultados de Medicin

*
*

*
*

*
*

4.4Modelos de Informacin Software

Construccin del Modelo
Implementacin del Modelo
4.5 Tcnicas de Medicin de Procesos

1 REFERENCIAS RECOMENDADAS
2 [Abr96] A. Abran and P.N. Robillard, Function Points
3 Analysis: An Empirical Study of its Measurement
4 Processes, IEEE Transactions on Software
5 Engineering, vol. 22, 1996, pp. 895-909.
6 [Bas92] V. Basili et al., The Software Engineering
7 Laboratory An Operational Software Experience
8 Factory, presented at the International Conference on
9 Software Engineering, 1992.
10 [Bec99] K. Beck, Extreme Programming Explained:
11 Embrace Change, Addison-Wesley, 1999.
12 [Boe03] B. Boehm and R. Turner, Using Risk to
13 Balance Agile and Plan-Driven Methods, Computer,
14 June 2003, pp. 57-66.
15 [Com97] E. Comer, Alternative Software Life Cycle
16 Models, presented at International Conference on
17 Software Engineering, 1997.
18 [ElE99] K. El-Emam and N. Madhavji, Elements of
19 Software Process Assessment and Improvement, IEEE
20 Computer Society Press, 1999.
21 [Fen98] N.E. Fenton and S.L. Pfleeger, Software
22 Metrics: A Rigorous & Practical Approach, second ed.,
23 International Thomson Computer Press, 1998.
24 [Fin94] A. Finkelstein, J. Kramer, and B. Nuseibeh,
25 Software Process Modeling and Technology,
26 Research Studies Press Ltd., 1994.
27 [Fow90] P. Fowler and S. Rifkin, Software Engineering
28 Process Group Guide, Software Engineering Institute,
29 Technical Report CMU/SEI-90-TR-24, 1990, available
30 at
31 http://www.sei.cmu.edu/pub/documents/90.reports/pdf/tr
32 24.90.pdf.
33 [Gol99] D. Goldenson et al., Empirical Studies of
34 Software Process Assessment Methods, presented at
35 Elements of Software Process Assessment and
36 Improvement, 1999.
37 [IEEE1074-97] IEEE Std 1074-1997, IEEE Standard for
38 Developing Software Life Cycle Processes, IEEE, 1997.
39 [IEEE12207.0-96] IEEE/EIA 12207.0-1996//ISO/
40 IEC12207:1995, Industry Implementation of Int. Std
41 ISO/IEC 12207:95, Standard for Information
42 Technology- Software Life Cycle Processes, IEEE, 1996.
43 [VIM93] ISO VIM, International Vocabulary of Basic
44 and General Terms in Metrology, ISO, 1993.
45 [ISO9126-01] ISO/IEC 9126-1:2001, Software
46 Engineering - Product Quality-Part 1: Quality Model,
47 ISO and IEC, 2001.
96

48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

[ISO15504-98] ISO/IEC TR 15504:1998, Information

Technology - Software Process Assessment (parts 1-9),
ISO and IEC, 1998. [ISO15939-02] ISO/IEC
15939:2002, Software Engineering Software
Measurement Process, ISO and IEC, 2002.
[Joh99] D. Johnson and J. Brodman, Tailoring the
CMM for Small Businesses, Small Organizations, and
Small Projects, presented at Elements of Software
Process Assessment and Improvement, 1999.
[McF96] B. McFeeley, IDEAL: A Users Guide for
Software Process Improvement, Software Engineering
Institute CMU/SEI-96-HB-001, 1996, available at
http://www.sei.cmu.edu/pub/documents/96.reports/pdf/h
b001.96.pdf.
[Moi98] D. Moitra, Managing Change for Software
Process Improvement Initiatives: A Practical Experience
Based Approach, Software Process Improvement
and Practice, vol. 4, iss. 4, 1998, pp. 199-207.
[Mus99] J. Musa, Software Reliability Engineering:
More Reliable Software, Faster Development and
Testing, McGraw-Hill, 1999.
[OMG02] Object Management Group, Software
Process Engineering Metamodel Specification, 2002,
available at http://www.omg.org/docs/formal/02-1114.pdf.
[Pfl01] S.L. Pfleeger, Software Engineering: Theory and
Practice, second ed., Prentice Hall, 2001.
[Pre04] R.S. Pressman, Software Engineering: A
Practitioners Approach, sixth ed., McGraw-Hill, 2004.
[San98] M. Sanders, The SPIRE Handbook: Better,
Faster, Cheaper Software Development in Small
Organisations, European Commission, 1998.
[SEI01] Software Engineering Institute, Capability
Maturity Model Integration, v1.1, 2001, available at
http://www.sei.cmu.edu/cmmi/cmmi.html.
[SEL96] Software Engineering Laboratory, Software
Process Improvement Guidebook, NASA/GSFC,
Technical Report SEL-95-102, April 1996, available at
http://sel.gsfc.nasa.gov/website/documents/onlinedoc/95-102.pdf.
[Som05] I. Sommerville, Software Engineering, seventh
ed., Addison-Wesley, 2005.
[Sti99] H. Stienen, Software Process Assessment and
Improvement: 5 Years of Experiences with Bootstrap,
Elements of Software Process Assessment and
Improvement, K. El-Emam and N. Madhavji, eds., IEEE
Computer Society Press, 1999.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

APNDICE A. LISTA DE LECTURAS ADICIONALES

(Agr99) W. Agresti, The Role of Design and Analysis
in Process Improvement, presented at Elements of
Software Process Assessment and Improvement, 1999.
(Ale91) L. Alexander and A. Davis, Criteria for
Selecting Software Process Models, presented at
COMPSAC 91, 1991.
(Ban95) S. Bandinelli et al., Modeling and Improving
an Industrial Software Process, IEEE Transactions on
Software Engineering, vol. 21, iss. 5, 1995, pp. 440-454.
(Bar95) N. Barghouti et al., Two Case Studies in
Modeling Real, Corporate Processes, Software Process
Improvement and Practice, Pilot Issue, 1995, pp. 1732.
(Boe03a) B. Boehm and R. Turner, Balancing Agility
and Discipline: A Guide for the Perplexed, AddisonWesley, 2003.
(Bur99) I. Burnstein et al., A Testing Maturity Model
for Software Test Process Assessment and
Improvement, Software Quality Professional, vol. 1,
iss. 4, 1999, pp. 8-21.
(Chi92) R. Chillarege et al., Orthogonal Defect
Classification
A
Concept
for In-Process
Measurement, IEEE Transactions on Software
Engineering, vol. 18, iss. 11, 1992, pp. 943-956.
(Chi96)
R.
Chillarege,
Orthogonal
Defect
Classification, Handbook of Software Reliability
Engineering, M. Lyu, ed., IEEE Computer Society
Press, 1996.
(Col93) J. Collofello and B. Gosalia, An Application of
Causal Analysis to the Software Production Process,
Software Practice and Experience, vol. 23, iss. 10, 1993,
pp. 1095-1105.
(Cur02) B. Curtis, W. Hefley, and S. Miller, The People
Capability Maturity Model: Guidelines for Improving
the Workforce, Addison-Wesley, 2002.
(Dav88) A. Davis, E. Bersoff, and E. Comer, A
Strategy for Comparing Alternative Software
Development Life Cycle Models, IEEE Transactions
on Software Engineering, vol. 14, iss. 10, 1988, pp.
1453-1461.
(Dun96) D. Dunnaway and S. Masters, CMM-Based
Appraisal for Internal Process Improvement
(CBA IPI): Method Description, Software Engineering
Institute CMU/SEI-96-TR-007, 1996, available at
http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr
007. 96.pdf.
(EIA/IS731-99) EIA, EIA/IS 731 Systems Engineering
Capability
Model,
1999,
available
at
http://www.geia.org/eoc/G47/index.html.
(ElE-97) K. El-Emam, D. Holtje, and N. Madhavji,
Causal Analysis of the Requirements Change Process
for a Large System, presented at Proceedings of the
International Conference on Software Maintenance,
1997.

56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109

(ElE-99a) K. El-Emam, B. Smith, and P. Fusaro,

Success Factors and Barriers in Software Process
Improvement: An Empirical Study, Better Software
Practice for Business Benefit: Principles and
Experiences, R. Messnarz and C. Tully, eds., IEEE
Computer Society Press, 1999.
(ElE-00a) K. El-Emam and A. Birk, Validating the
ISO/IEC 15504 Measures of Software Development
Process Capability, Journal of Systems and Software,
vol. 51, iss. 2, 2000, pp. 119-149.
(ElE-00b) K. El-Emam and A. Birk, Validating the
ISO/IEC 15504 Measures of Software Requirements
Analysis Process Capability, IEEE Transactions on
Software Engineering, vol. 26, iss. 6, June 2000, pp.
541-566
(Fay97) M. Fayad and M. Laitinen, Process
Assessment: Considered Wasteful, Communications of
the ACM, vol. 40, iss. 11, November 1997.
(Flo99) W. Florac and A. Carleton, Measuring the
Software Process: Statistical Process Control for
Software Process Improvement, Addison-Wesley, 1999.
(Gar96) P. Garg and M. Jazayeri, Process-Centered
Software Engineering Environments: A Grand Tour,
Software Process, A. Fuggetta and A. Wolf, eds., John
Wiley & Sons, 1996.
(Gra97) R. Grady, Successful
Improvement, Prentice Hall, 1997.

Software

Process

(Gra88) E. Gray and W. Smith, On the Limitations of

Software Process Assessment and the Recognition of a
Required
Re-Orientation
for
Global
Process
Improvement, Software Quality Journal, vol. 7, 1998,
pp. 21-34.
(Har98) D. Harel and M. Politi, Modeling Reactive
Systems with Statecharts: The Statemate Approach,
McGraw-Hill, 1998.
(Her98) J. Herbsleb, Hard Problems and Hard Science:
On the Practical Limits of Experimentation, IEEE
TCSE Software Process Newsletter, vol. 11, 1998, pp.
18-21, available at http://www.seg.iit.nrc.ca/SPN.
(Hum95) W. Humphrey, A Discipline for Software
Engineering, Addison-Wesley, 1995.
(Hum99) W. Humphrey, An Introduction to the Team
Software Process, Addison-Wesley, 1999.
(Hut94) D. Hutton, The Change Agents Handbook: A
Survival Guide for Quality Improvement Champions,
Irwin, 1994.
(Kan02) S.H. Kan, Metrics and Models in Software
Quality Engineering, second ed., Addison-Wesley,
2002.
(Kel98) M. Kellner et al., Process Guides: Effective
Guidance for Process Participants, presented at the 5th
International Conference on the Software Process, 1998.
(Kit98) B. Kitchenham, Selecting Projects for
Technology Evaluation, IEEE TCSE Software Process

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

Newsletter, iss. 11, 1998, pp. 3-6, available at

http://www.seg.iit.nrc.ca/SPN.
(Kra99) H. Krasner, The Payoff for Software Process
Improvement: What It Is and How to Get It, presented
at Elements of Software Process Assessment and
Improvement, 1999.
(Kri99) M.S. Krishnan and M. Kellner, Measuring
Process Consistency: Implications for Reducing
Software Defects, IEEE Transactions on Software
Engineering, vol. 25, iss. 6, November/December 1999,
pp. 800-815.
(Lyu96) M.R. Lyu, Handbook of Software Reliability
Engineering, Mc-Graw-Hill/IEEE, 1996.
(Mad94) N. Madhavji et al., Elicit: A Method for
Eliciting Process Models, presented at Proceedings of
the Third International Conference on the Software
Process, 1994.
(Mas95) S. Masters and C. Bothwell, CMM Appraisal
Framework - Version 1.0, Software Engineering
Institute CMU/SEI-TR-95-001, 1995, available at
http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr
001.95.pdf.
(McG94) F. McGarry et al., Software Process
Improvement in the NASA Software Engineering
Laboratory, Software Engineering Institute CMU/SEI94R-22,
1994,
available
at
http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr
22.94.pdf.
(McG01) J. McGarry et al., Practical Software
Measurement: Objective Information for Decision
Makers, ddison-Wesley, 2001.
(Mcg93) C. McGowan and S. Bohner, Model Based
rocess Assessments, presented at International
Conference on Software Engineering, 1993.
(Nak91) T. Nakajo and H. Kume, A Case History
Analysis of Software Error Cause-Effect Relationship,
IEEE Transactions on Software Engineering, vol. 17,
iss. 8, 1991.
(Pau94) M. Paulk and M. Konrad, Measuring Process
Capability Versus Organizational Process Maturity,
presented at 4th International Conference on Software
Quality, 1994.
(Pfl99) S.L. Pfleeger, Understanding and Improving
Technology Transfer in Software Engineering, Journal
of Systems and Software, vol. 47, 1999, pp. 111-124.

46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

(Pfl01) S.L. Pfleeger, Software Engineering: Theory and

Practice, second ed., Prentice Hall, 2001.
(Rad85) R. Radice et al., A Programming Process
Architecture, IBM Systems Journal, vol. 24, iss. 2,
1985, pp. 79-90.
(Rag89) S. Raghavan and D. Chand, Diffusing
Software- Engineering Methods, IEEE Software, July
1989, pp. 81-90.
(Rog83) E. Rogers, Diffusion of Innovations, Free Press,
1983.
(Sch99) E. Schein, Process Consultation Revisited:
Building the Helping Relationship, Addison-Wesley,
1999.
(SEI95) Software Engineering Institute, The Capability
Maturity Model: Guidelines for Improving the Software
Process, Addison-Wesley, 1995.
(SEL96) Software Engineering Laboratory, Software
Process Improvement Guidebook, Software Engineering
Laboratory, NASA/GSFC, Technical Report SEL-95102,
April
1996,
available
at
http://sel.gsfc.nasa.gov/website/documents/onlinedoc/95-102.pdf
(SPC92) Software Productivity Consortium, Process
Definition and Modeling Guidebook, Software
Productivity Consortium, SPC-92041-CMC, 1992.
(Som97) I. Sommerville and P. Sawyer, Requirements
Engineering: A Good Practice Guide, John Wiley &
Sons, 1997.
(Vot93) L. Votta, Does Every Inspection Need a
Meeting? ACM Software Engineering Notes, vol. 18,
iss. 5, 1993, pp. 107-114.
(Wei93)
G.M.
Weinberg,
Quality
Software
Management, First-Order Measurement (Ch. 8,
Measuring Cost and Value), vol. 2, 1993.
(Yu94) E. Yu and J. Mylopolous, Understanding
Why in Software Process Modeling, Analysis, and
Design, presented at 16th International Conference on
Software Engineering, 1994
(Zah98) S. Zahran, Software Process Improvement:
Practical Guidelines for Business Success, AddisonWesley, 1998.
(Zel98) M. V. Zelkowitz and D. R. Wallace,
Experimental Models for Validating Technology,
Computer, vol. 31, iss. 5, 1998, pp. 23-31.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

APNDICE B. LISTA DE ESTNDARES

(IEEE1044-93) IEEE Std 1044-1993 (R2002), IEEE
Standard for the Classification of Software Anomalies,
IEEE, 1993.
(IEEE1061-98) IEEE Std 1061-1998, IEEE Standard for
a Software Quality Metrics Methodology, IEEE, 1998.
(IEEE1074-97) IEEE Std 1074-1997, IEEE Standard for
Developing Software Life Cycle Processes, IEEE, 1997.
(IEEE1219-98) IEEE Std 1219-1998, IEEE Standard for
Software Maintenance, IEEE, 1998.
(IEEE1220-98) IEEE Std 1220-1998, IEEE Standard for
the Application and Management of the Systems
Engineering Process, IEEE, 1998.
(IEEE1517-99) IEEE Std 1517-1999, IEEE Standard for
Information Technology-Software Life Cycle ProcessesReuse Processes, IEEE, 1999.
(IEEE1540-01)
IEEE
Std
15402001//ISO/IEC16085:2003,IEEE Standard for Software
Life Cycle Processes-Risk Management, IEEE, 2001.
(IEEE12207.0-96)
IEEE/EIA
12207.0-1996//ISO/
IEC12207:1995, Industry Implementation of Int. Std
ISO/IEC 12207:95, Standard for Information
Technology-Software Life Cycle Processes, IEEE, 1996.
(IEEE12207.1-96) IEEE/EIA 12207.1-1996, Industry
Implementation of Int. Std ISO/IEC 12207:95, Standard
forInformation Technology-Software Life Cycle
Processes -Life Cycle Data, IEEE, 1996.
(IEEE12207.2-97) IEEE/EIA 12207.2-1997, Industry
Implementation of Int. Std ISO/IEC 12207:95, Standard
for Information Technology-Software Life Cycle
Processes -Implementation Considerations, IEEE, 1997.
(IEEE14143.1-00) IEEE Std 14143.1-2000//ISO/
IEC14143-1:1998, Information Technology-Software

69

34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

Measurement-Functional Size Measurement-Part 1:

Definitions of Concepts, IEEE, 2000.
(ISO9001-00) ISO 9001:2000, Quality Management
Systems-Requirements, ISO, 1994.
(ISO9126-01)
ISO/IEC
9126-1:2001,
Software
Engineering-Product Quality-Part 1: Quality Model,
ISO and IEC, 2001.
(ISO14674-99) ISO/IEC 14674:1999, Information
Technology - Software Maintenance, ISO and IEC,
1999.
(ISO15288-02)
ISO/IEC
15288:2002,
Systems
Engineering-System Life Cycle Process, ISO and IEC,
2002.
(ISO15504-98) ISO/IEC TR 15504:1998, Information
Technology - Software Process Assessment (parts 1-9),
ISO and IEC, 1998.
(ISO15939-02)
ISO/IEC
15939:2002,
Software
Engineering-Software Measurement Process, ISO and
IEC, 2002.
(ISO19761-03)
ISO/IEC
19761:2003,
Software
Engineering-Cosmic
FPP-A
Functional
Size
Measurement Method, ISO and IEC, 2003.
(ISO20926-03)
ISO/IEC
20926:2003,
Software
Engineering-IFPUG 4.1 Unadjusted Functional Size
Measurement Method-Counting Practices Manual, ISO
and IEC, 2003.
(ISO20968-02)
ISO/IEC
20968:2002,
Software
Engineering-MK II Function Point Analysis Counting
Practices Manual, ISO and IEC, 2002.
(ISO90003-04) ISO/IEC 90003:2004, Software and
Systems Engineering - Guidelines for the Application of
ISO9001:2000 to Computer Software, ISO and IEC,
2004.
(VIM93) ISO VIM, International Vocabulary of Basic
and General Terms in Metrology, ISO, 1993.