You are on page 1of 9

CAPTULO 4

CONSTRUCCIN DEL SOFTWARE

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
57

ACRNIMOS
OMG
UML

Grupo de Gestin de Objetos


Lenguaje Unificado de Modelado

INTRODUCCIN
El trmino construccin del software hace referencia
a la creacin detallada de software operativo y
significativo, por medio de una combinacin de
codificacin, verificacin, pruebas unitarias, pruebas
de integracin y depuracin.
El rea de Conocimiento de la Construccin del
Software est vinculada a todas las otras KAs (reas
de Conocimiento), ms fuertemente al Diseo del
Software y a las Pruebas del Software. Esto se debe a
que el proceso mismo de construccin del software
cubre tanto el diseo significativo de software como
las actividades de pruebas. Tambin utiliza las salidas
del diseo y proporciona una de las entradas para las
pruebas, consistiendo estas actividades en el diseo y
en las pruebas, y en este caso no en las KAs. Las
fronteras detalladas entre el diseo, la construccin y
las pruebas (si es que existen) varan dependiendo de
los procesos de ciclo de vida del software utilizados
en un proyecto.
A pesar de que se pueda realizar parte del diseo
detallado antes de la construccin, mucho del trabajo
del diseo se lleva a cabo durante la actividad misma
de la construccin. Por lo que el KA de Construccin
del Software est vinculado muy de cerca al KA de
Diseo del Software.
Por medio de la construccin los ingenieros del
software realizan tanto pruebas unitarias, como
pruebas de integracin de su trabajo. De tal manera
que el KA de Construccin del Software est tambin
vinculada de cerca al KA de Pruebas del Software.
La construccin del software, por lo general, produce
el mayor nmero de elementos de configuracin que
se necesitan gestionar en un proyecto de software
(archivos de cdigo fuente, contenido, casos de
pruebas, etc). De este modo, el KA de Construccin
del Software tambin est vinculado de cerca al KA
de Gestin de la Configuracin del Software.
Dado que la construccin del software tiene una gran
dependencia de las herramientas y de los mtodos, y
de que se trata probablemente del KA que ms
herramientas tiene y utiliza, est vinculada al KA de
Herramientas y Mtodos de la Ingeniera del
Software.

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

Aunque la calidad del software es importante en


todas las KAs, el cdigo es el ltimo entregable de un
proyecto de software y, por tanto, la Calidad del
Software est vinculada de cerca a la Construccin
del Software.
Entre las Disciplinas Descritas de la Ingeniera del
Software el KA de Construccin del Software es lo
ms parecido a la ciencia informtica en su uso del
conocimiento de algoritmos y de las prcticas
detalladas de codificacin, ambas son consideradas,
con frecuencia, como pertenecientes al dominio de la
ciencia informtica. Tambin est relacionada con la
gestin del proyecto en la medida en que la gestin
de la construccin pueda presentar retos
considerables.

83
84
85
86
87
88
89
90
91
92
93
94

1.

95
96
97
98
99
100
101
102
103
104
105

DESCOMPOSICIN DE LOS TEMAS


CONSTRUCCIN DEL SOFTWARE

DE

A continuacin se presenta la descomposicin del


KA de la Construccin del Software junto con breves
descripciones de los temas ms importantes asociados
a este. La figura 1 ofrece una representacin grfica
de la descomposicin de alto nivel de las divisiones
de este KA.
Fundamentos de la Construccin del Software

Los fundamentos de la construccin del software


incluyen:
Minimizar la complejidad
Anticiparse a los cambios
Construir para verificar
Estndares en la construccin
Los tres primeros conceptos se aplican tanto al diseo
como a la construccin. Las siguientes secciones
definen estos conceptos y describen cmo se aplican
a la construccin.
1.1 Minimizar la complejidad
[Bec99; Ben00; Hun00; Ker99; Mag93; McC04]
El principal factor que hace que la gente utilice
ordenadores consiste en la limitadsima capacidad
que tiene para retener estructuras complejas e
informacin en su memoria operativa, especialmente
durante largos perodos de tiempo. Esto lleva a uno
de los ms fuertes impulsores de la construccin del
software: minimizar la complejidad. La necesidad de
reducir la complejidad se aplica esencialmente a todo
aspecto de la construccin del software, y es de

1
2
3
4
5
6
7
8
9
10
11
12
13

crtica importancia para el proceso de verificacin y


pruebas de las construcciones del software.
En la construccin del software slo se alcanza una
reducida complejidad por medio del nfasis en la
creacin de cdigo que sea simple y legible, y no
tanto inteligente.
Se logra minimizar la complejidad mediante el uso de
estndares, como se ve en el apartado 1.4 Estndares
de Construccin, y mediante numerosas tcnicas
especficas que estn resumidas en el apartado 3.3
Codificacin. Tambin se apoya en las tcnicas de
calidad enfocadas a la construccin resumidas en el
apartado 3.5 Calidad de la Construccin.

14
15
16
17
18
19
20
21
22
23
24
25

1.2 Anticiparse a los cambios

26
27
28
29
30
31
32
33
34
35
36
37
38

1.3 Construir para verificar

[Ben00; Ker99; McC04]


La mayora del software cambiar a lo largo del
tiempo, y el anticiparse a los cambios dirige muchos
aspectos de la construccin del software. El software
es inevitablemente parte de los ambientes externos
que cambian continuamente, y los cambios en esos
ambientes externos afectan al software de diversos
modos.
El anticiparse a los cambios se apoya en muchas
tcnicas especficas resumidas en el apartado 3.3
Codificacin.

[Ben00; Hun00; Ker99; Mag93; McC04]


Construir para verificar significa construir software
de tal manera que los ingenieros del software puedan
sacar a relucir los fallos con facilidad al estar
escribiendo el cdigo, adems de cuando realizan
pruebas independientes y actividades operacionales.
Las tcnicas especficas que sirven de base para
construir con vistas a verificar incluyen el
seguimiento de estndares de codificacin que
permitan las revisiones del cdigo, las pruebas
unitarias, la organizacin del cdigo que permita
pruebas automticas, y el uso restringido de

39 estructuras de lenguaje que sean complejas o difciles


40 de entender, entre otras.
41 1.4 Estndares en la construccin
42
[IEEE12207-95; McC04]
43 Los estndares que afectan directamente a elementos
44 de la construccin incluyen:
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

Mtodos de comunicacin (por ejemplo,


estndares para los formatos de los documentos y
de los contenidos)
Programacin de lenguajes (por ejemplo,
estndares de lenguaje para lenguajes como Java
y C++)
Plataformas (por ejemplo, estndares de
interfaces del programador para llamadas al
sistema operativo)
Herramientas
(por
ejemplo,
estndares
diagramticos para notaciones como UML
(Lenguaje Unificado de Modelado))

Uso de estndares externos. Construir depende del


uso de estndares externos para los lenguajes de
construccin, las herramientas de construccin, las
interfaces tcnicas, y las interacciones entre la
Construccin del Software y las otras KAs. Los
estndares provienen de numerosas fuentes,
incluyendo las especificaciones de interfaz del
hardware y del software, tales como el Grupo de
Gestin de Objetos (OMG) y las organizaciones
internacionales tales como la IEEE o ISO.
Uso de estndares internos. Los estndares tambin
pueden crearse partiendo de una base organizacional
a un nivel corporativo o para su uso en proyectos
especficos.
Estos
estndares
permiten
la
coordinacin de actividades de grupo, el minimizar la
complejidad, el anticipar los cambios y el construir
para verificar.

76
77
78
79
80
81
82
83
84

1
2

Figura 1 Descomposicin de los temas del KA de Construccin de Software

3 2. Gestin de la Construccin
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

2.1 Modelos de Construccin [Bec99; McC04]

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

2.2 Planificacin de la Construccin

Se han creado numerosos modelos para el desarrollo


del software, algunos de los cuales ponen ms nfasis
en la construccin que otros.
Algunos modelos son ms lineales que otros desde el
punto de vista de la construccin tales como los
modelos en cascada y los del ciclo de vida de
entregas por etapas. Estos modelos tratan la
construccin como una actividad que sucede slo
despus de que se haya completado un significativo
trabajo con los prerrequisitos incluyendo un trabajo
detallado sobre los requisitos, un extensivo trabajo
sobre el diseo y una planificacin detallada. Los
enfoques ms lineales tienden a poner el nfasis en
las actividades que preceden a la construccin
(requisitos y diseo), y tienden a crear separaciones
ms marcadas entre las actividades. En estos
modelos, la codificacin sera el punto de mayor
nfasis de la construccin.
Otros modelos son ms iterativos, tales como el
prototipado evolucionista, Programacin Extrema y
Scrum. Estos enfoques tienden a tratar la
construccin como una actividad que ocurre en estos
momentos con otras actividades de desarrollo del
software incluyendo los requisitos, el diseo y la
planificacin, o que se traslapa con ellas. Estos
enfoques tienden a mezclar el diseo, la codificacin
y las actividades de pruebas, y con frecuencia tratan
la combinacin de actividades como una
construccin.
Por consiguiente, lo que est considerado como
construccin depende hasta cierto grado del
modelo de ciclo de vida utilizado.

[Bec99; McC04]
La eleccin de un mtodo de construccin es un
aspecto clave de la planificacin de la actividad de
construccin. La eleccin de un mtodo de
construccin afecta hasta dnde se realizan los
prerrequisitos de construccin, el orden en el que se
realizan, y el grado hasta el que se espera que se
completen antes de que comience el trabajo de
construccin.
El modo como se afronta la construccin afecta a la
habilidad del proyecto para reducir la complejidad,
anticipar cambios y construir para verificar. Cada uno
de estos objetivos puede tambin afrontarse en los
niveles de proceso, requisitos y diseo pero tambin
estarn influenciados por la eleccin de un mtodo de
construccin.
La planificacin de la construccin tambin define el
orden en el que se crean e integran, segn el mtodo
elegido, los componentes, los procesos de gestin de

57 la calidad del software, la asignacin de tareas a


58 ingenieros del software especficos y el resto de las
59 tareas.
60
61
62
63
64
65
66
67
68
69
70
71
72

2.3 Medicin de la Construccin

73
74
75
76
77
78
79
80
81

3.

82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

[McC04]
Se pueden medir numerosas actividades de
construccin y artefactos, incluidos el cdigo
desarrollado, el cdigo modificado, el cdigo
reutilizado, el cdigo destruido, la complejidad del
cdigo, las estadsticas de la inspeccin del cdigo,
las tasas de rectificacin de errores y de
identificacin de errores, y los horarios. Estas
mediciones pueden ser tiles para propsitos de
gestin de la construccin, asegurando la calidad
durante la construccin, mejorando los procesos de
construccin, amn de otras razones.
Consideraciones Prcticas

La construccin es una actividad en la cual el


software se las tiene que ver con restricciones
arbitrarias y caticas del mundo real, y hacer
exactamente lo que piden. Gracias a su proximidad a
las restricciones del mundo real, la construccin est
guiada por consideraciones prcticas ms que otras
KAs, y la ingeniera del software es quizs el rea de
construccin ms artesanal.
3.1 Diseo de la Construccin
[Bec99; Ben00; Hun00; IEEE12207-95; Mag93;
McC04]
Algunos proyectos asignan una mayor actividad de
diseo a la construccin; otros a una fase que se
centra
explcitamente
en
el
diseo.
Independientemente de su asignacin exacta, en el
nivel de construccin tambin se trabaja algo el
diseo detallado y ese trabajo de diseo tiende a estar
dictaminado por restricciones inamovibles impuestas
por un problema del mundo real que est siendo
afrontado por el software.
As como los obreros de una construccin que
construyen una estructura fsica tienen que realizar
modificaciones a pequea escala para cubrir huecos
no previstos en los planes del constructor, los obreros
de la construccin del software tendrn que hacer
modificaciones en una mayor o menor escala para
revelar los detalles del diseo de software durante la
construccin.
Los detalles de la actividad de diseo a nivel de la
construccin son esencialmente los mismos que se
describen en el KA del Diseo del Software, pero se
aplican en una escala inferior.

106 3.2 Lenguajes de Construccin


107
[Hun00; McC04]

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
57
58
59

Los lenguajes de construccin incluyen todos los


tipos de comunicacin mediante los cuales un
humano puede especificar una solucin ejecutable
para un problema de un ordenador.
El tipo ms simple de lenguaje de construccin es un
lenguaje de configuracin en el que los ingenieros
del software eligen de entre un conjunto limitado de
opciones predefinidas para crear nuevas o tpicas
instalaciones del software. Los archivos de
configuracin basados en texto utilizados tanto en los
sistemas operativos de Windows como de Unix son
ejemplos de esto, y otro ejemplo son las listas de
seleccin en forma de men de algunos generadores
de programas.
Los lenguajes de herramientas se utilizan para
construir aplicaciones partiendo de las herramientas
(conjuntos integrados de partes reutilizables
especficas de las aplicaciones), y son ms complejos
que los lenguajes de configuracin. Los lenguajes de
herramientas pueden definirse explcitamente como
lenguajes de programacin de aplicaciones (por
ejemplo, scripts), o pueden simplemente estar
implcitos en el conjunto de interfaces de las
herramientas.
Los lenguajes de programacin son el tipo ms
flexible de lenguaje de construccin. Tambin son los
que menos informacin contienen acerca de las reas
especficas de la aplicacin y los procesos de
desarrollo, y por tanto requieren el mayor
entrenamiento y destreza posibles para utilizarlo con
eficacia.
Existen tres tipos generales de notacin utilizados
para los lenguajes de programacin, a saber:
Lingsticos
Formales
Visuales
Las notaciones lingsticas se distinguen en particular
por la utilizacin de cadenas de texto del tipo palabra
para representar construcciones complejas de
software, y por la combinacin en patrones de tales
cadenas del tipo palabra que tienen una sintaxis del
tipo sentencia. Utilizadas adecuadamente, cada una
de estas cadenas debera tener una fuerte connotacin
ofreciendo un entendimiento intuitivo inmediato de lo
que sucedera cuando se ejecutara la construccin del
software subyacente.
Las notaciones formales se apoyan menos en los
significados de las palabras y cadenas de texto
intuitivos y de todos los das, y ms en las
definiciones respaldadas por definiciones precisas,
sin ambigedad, y formales (o matemticas). Las
notaciones de construccin formal y los mtodos
formales estn en el corazn de la mayora de las
formas de programacin de sistemas, donde la
precisin, el comportamiento del tiempo, y la
capacidad de realizar pruebas son ms importantes
que la facilidad de mapeo a un lenguaje natural. Las
construcciones formales tambin utilizan modos de
combinar smbolos definidos con precisin que evitan

60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

la ambigedad de muchas construcciones del


lenguaje natural.
Las notaciones visuales se apoyan bastante poco en
las notaciones orientadas al texto tanto de la
construccin lingstica como de la formal, y en
cambio s se apoyan en una interpretacin visual
directa y en la colocacin de las entidades visuales
que representan al software subyacente. La
construccin visual tiende a estar un tanto limitada
por la dificultad de hacer declaraciones complejas
utilizando slo el movimiento de entidades visuales
en un despliegue. Sin embargo, tambin puede
convertirse en un arma poderosa en los casos en
donde la principal tarea de programacin es
simplemente construir y ajustar una interfaz visual
a un programa, cuyo comportamiento detallado ha
sido definido anteriormente.

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

3.3 Codificacin

103
104
105
106
107
108
109
110
111
112
113
114
115
116

3.4 Pruebas de Construccin

[Ben00; IEEE12207-95; McC04]


Las consideraciones siguientes se aplican a la
actividad de construccin del cdigo del software:
Tcnicas para crear cdigo fuente comprensible,
que incluye la asignacin de nombres y el
esquema del cdigo fuente
Utilizacin de clases, tipos enumerados,
variables, constantes predefinidas, y otras
entidades similares
Utilizacin de estructuras de control
Tratamiento de las condiciones de error tanto lo
errores planeados como las excepciones (la
entrada de datos malos, por ejemplo)
Prevencin de brechas en la seguridad a nivel de
cdigo (el bfer o el ndice de la matriz se
desborda, por ejemplo)
Utilizacin de recursos por medio del uso de
mecanismos de exclusin y disciplina en el
acceso serial a recursos reutilizables (incluyendo
threads o bloqueos de bases de datos)
Organizacin
del
cdigo
fuente
(en
declaraciones, rutinas, clases, paquetes u otras
estructuras)
Documentacin del cdigo
Puesta a punto del cdigo

[Bec99; Hun00; Mag93; McC04]


Construir implica dos tipos de pruebas, que por lo
general las realiza el mismo ingeniero del software
que escribi el cdigo:
Pruebas unitarias
Pruebas de integracin
El propsito de las pruebas de construccin es reducir
la brecha entre el tiempo en el que se introducen
fallos en el cdigo y el tiempo en el que se detectan
esos fallos. En algunos casos, las pruebas de
construccin se llevan a cabo despus de la escritura
del cdigo. En otros casos, se pueden elaborar casos
de pruebas antes de que se escriba el cdigo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Es tpico de las pruebas de construccin el incluir un


subconjunto de tipos de pruebas, que se describen en
el KA de Pruebas del Software. Por ejemplo, no es
tpico de las pruebas de construccin el incluir las
pruebas del sistema, las pruebas alfa, las pruebas
beta, las pruebas de estrs, las pruebas de
construccin, las pruebas de posibilidad de uso, u
otros tipos de pruebas ms especializadas.
Se han publicado dos estndares sobre dicho tema:
IEEE Std 829-1998, IEEE Standard for Software Test
Documentation and IEEE Std 1008-1987, IEEE
Standard for Software Unit Testing.
Se
pueden
ver
tambin
los
sub-temas
correspondientes en el KA de Pruebas del Software:
2.1.1 Pruebas Unitarias y 2.1.2 Pruebas de
Integracin para un material de referencia ms
especializado.

18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

3.5 Reutilizacin
[IEEE1517-99; Som05].
Tal y como se afirma en la introduccin del
(IEEE1517-99):
El implementar la utilizacin del software conlleva
algo ms que crear y utilizar libreras de recursos.
Requiere formalizar la prctica de la reutilizacin por
medio de la integracin de procesos y actividades de
reutilizacin en el ciclo de vida del software. Sin
embargo, la reutilizacin tiene suficiente importancia
en la construccin del software como para dedicarle
aqu un tema.
Las tareas relacionadas con la reutilizacin en la
construccin del software durante su codificacin y
pruebas son:

33 La seleccin de unidades, bases de datos,


34
procedimientos de pruebas o datos de pruebas
35
reutilizables.
36 La evaluacin de la posibilidad de reutilizacin
37
del cdigo o de las pruebas.
38 Comunicar la informacin sobre reutilizacin
39
realizada en el cdigo nuevo, los procedimientos
40
de pruebas o los datos de pruebas.
41
42
43
44
45
46
47

3.6 Calidad de la Construccin


[Bec99; Hun00; IEEE12207-95; Mag93;
McC04]
Existen numerosas tcnicas para garantizar la calidad
del cdigo mientras est siendo elaborado. Las
tcnicas ms importantes utilizadas para la
construccin incluyen:

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

La tcnica o tcnicas especficas elegidas dependen


de la naturaleza del software que se est
construyendo, as como del conjunto de habilidades
de los ingenieros del software que llevan a cabo la
construccin.
Las actividades de calidad de la construccin se
distinguen de las otras actividades de calidad por su
enfoque. Las actividades de calidad de la
construccin se centran en el cdigo y en los
artefactos que estn estrechamente relacionados con
el cdigo: diseos en pequea escala en oposicin a
otros artefactos que estn menos directamente ligados
al cdigo, tales como requisitos, diseos de alto nivel
y planes.

77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93

3.7 Integracin

Las pruebas unitarias y las pruebas de


integracin (tal y como se describen en el punto
3.4 Pruebas de Construccin)
El desarrollo de primero-haz-pruebas (ver
tambin el KA de las Pruebas del Software,
punto 2.2 Objetivos de las Pruebas)
El cdigo paso a paso
Utilizacin de aserciones
Depuracin
Revisiones Tcnicas (ver tambin el KA de la
Calidad del Software, sub-punto 2.3.2 Revisiones
Tcnicas)
Anlisis esttico (IEEE1028) (ver tambin el KA
de la Calidad del Software, punto 2.3 Revisiones
y Auditorias)

[Bec99; IEEE12207-95; McC04]


Una actividad clave durante la construccin es la
integracin de rutinas, clases, componentes y
subsistemas construidos por separado. Adems, un
sistema particular del software podra necesitar ser
integrado con otros sistemas de software o de
hardware.
Los intereses relacionados con la integracin de la
construccin incluyen planificar la secuencia en la
que se integrarn los componentes, crear andamiajes
que soporten versiones provisionales del software,
determinar el grado de pruebas y la calidad del
trabajo realizado sobre los componentes antes de que
sean integrados, y determinar los puntos en el
proyecto en los que se prueban las versiones
provisionales del software.

[Som05]

[Mcc04]

[Mag93]

[Ker99]

[IEEE
12207.0]

[IEEE
1517]

[Ben00]

[Hun00]

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

[Bec99]

1
2
3

1. Fundamentos de
Construccin de
Software

1.1 Minimizar la
Complejidad

c17

1.2 Anticipacin a
Cambios

c2, c3

c7,c8

c2, c3

c11,c13c14

1.3 Construir para


verificar

c4

2.2 Plan de
Construccin
2.3 Mtricas de la
construccin
3. Consideraciones
Prcticas
3.1 Diseo de la
Construccin
3.2 Lenguajes de
Construccin

c21,
c23,
c34,
c43

c1, c5, c6

3.7 Integracin

4
5

c2,c3,
c5,c7

c8, c20c23,
c31-c34
c4

c2, c3,
c27, c29
c3,
c4,c21,
c27-c29

c10
c12,
c15,
c21

c25, c28

c17

c18-c10,
p175-6

c33

c6

c12,
c14-c20

3.3 Codificacin
3.4 Pruebas de
Construccin
3.5 Reusabilidad
3.6 Calidad de
Construccin

c3-c5,
c24,
c31,
c32, c34

c2, c9

1.4 Estndares de
Construccin
2. Gestin de la
Construccin
2.1 Modelos de
Construccin

c6

c2, c3,
c7-c9,
c24,
c27,
c28,
c31,
c32-c34

C4

c6-c10
c18

c3, c5,
c24

c5-c19,
c25-c26

X
c34,
c43

c4

c22, c23

c4,
c6, c7

c8, c20c25

X
c18
c16

c18

c14

c29

1 REFERENCIAS RECOMENDADAS PARA LA


2 CONSTRUCCIN DE SOFTWARE
3
4 [Bec99] K. Beck, Extreme Programming Explained:
5 Embrace Change, Addison-Wesley, 1999, Chap. 10, 12,
6 15, 16-18, 21.
7 [Ben00a] J. Bentley, Programming Pearls, second ed.,
8 Addison-Wesley, 2000, Chap. 2-4, 6-11, 13, 14, pp. 1759 176.
10 [Hun00] A. Hunt and D. Thomas, The Pragmatic
11 Programmer, Addison-Wesley, 2000, Chap. 7, 8 12, 1412 21, 23, 33, 34, 36-40, 42, 43.
13 [IEEE1517-99] IEEE Std 1517-1999, IEEE Standard for
14 Information Technology-Software Life Cycle Processes15 Reuse Processes, IEEE, 1999.
30

16
17
18
19
20
21
22
23
24
25
26
27
28
29

[IEEE12207.0-96] IEEE/EIA 12207.01996//ISO/IEC12207:1995, Industry Implementation of


Int. Std.ISO/IEC 12207:95, Standard for Information
Technology-Software Life Cycle Processes, IEEE, 1996.
[Ker99a] B.W. Kernighan and R. Pike, The Practice of
Programming, Addison-Wesley, 1999, Chap. 2, 3, 5, 6, 9.
[Mag93] S. Maguire, Writing Solid Code: Microsofts
Techniques for Developing Bug-Free C Software,
Microsoft Press, 1993, Chap. 2-7.
[McC04] S. McConnell, Code Complete: A
PracticalHandbook of Software Construction, Microsoft
Press, second ed., 2004.
[Som05] I. Sommerville, Software Engineering, seventh
ed., Addison-Wesley, 2005.

1 APNDICE A. LISTA DE LECTURAS ADICIONALES.


2
3 (Bar98) T.T. Barker, Writing Software Documentation: A
4 Task-Oriented Approach, Allyn & Bacon, 1998.
5 (Bec02) K. Beck, Test-Driven Development: By Example,
6 Addison-Wesley, 2002.
7 (Fow99) M. Fowler and al., Refactoring: Improving the
8 Design of Existing Code, Addison-Wesley, 1999.
18

9
10
11
12
13
14
15
16
17

(How02) M. Howard and D.C. Leblanc, Writing Secure


Code, Microsoft Press, 2002.
(Hum97b) W.S. Humphrey, Introduction to the Personal
Software Process, Addison-Wesley, 1997.
(Mey97) B. Meyer, Object-Oriented Software
Construction, second ed., Prentice Hall, 1997, Chap. 6, 10,
11.
(Set96) R. Sethi, Programming Languages: Concepts &
Constructs, second ed., Addison-Wesley, 1996, Parts II-V.

1 APNDICE B. LISTA DE ESTNDARES


2
3 (IEEE829-98) IEEE Std 829-1998, IEEE Standard for
4 Software Test Documentation, IEEE, 1998.
5 (IEEE1008-87) IEEE Std 1008-1987 (R2003), IEEE
6 Standard for Software Unit Testing, IEEE, 1987.
7 (IEEE1028-97) IEEE Std 1028-1997 (R2002), IEEE
8 Standard for Software Reviews, IEEE, 1997.
16

9
10
11
12
13
14
15

(IEEE1517-99) IEEE Std 1517-1999, IEEE Standard for


Information Technology-Software Life Cycle ProcessesReuse Processes, IEEE, 1999.
(IEEE12207.0-96) IEEE/EIA 12207.01996//ISO/IEC12207:1995, Industry Implementation of
Int. Std.ISO/IEC 12207:95, Standard for Information
Technology-Software Life Cycle Processes, IEEE, 1996.

You might also like