1

GUIA DE LA INGENIERIA DEL SOFTWARE

CUERPO DE CONOCIMIENTO
VERSION 2004
EDICION IEEE
CAROLINA HENAO ACOSTA
JUAN PABLO ORTIZ VILLEGAS
UNIVERSIDAD CATOLICA POPULAR DEL RISARALDA
FACULTAD DE CIENCIAS BASICAS E INGENIERIA
PEREIRA
NOVIEMBRE 24 DE 2009
2
CAPITULO 1
INTRODUCCION A LA GUIA
Esta gua inicia con una amplia y completa introduccin sobre el concepto de Ingeniera del
Software, desde la ptica de los miembros de la IEEE.
La definen como una ciencia relativamente nueva y con reconocimiento en el rea de Ingeniera. La
reconoce como una disciplina crucial para la evolucin de la industria de software a nivel mundial y
la define como la aplicacin de un enfoque sistemtico, disciplinado y cuantificable para el
desarrollo, operacin y mantenimiento de software.
na profesin para ser reconocida como tal debe cumplir con un cuerpo de conocimiento basado en
tres aspectos, desde el punto de vista acad!mico, moral y cognitivo"
#. $ue el conocimiento y las competencias de la profesin, sean validadas por profesionales
de la misma rea.
%. $ue el conocimiento sea validado desde la base racional y con fundamento cientfico
&. $ue el 'uicio del profesional se enfoque (acia el asesoramiento en el rea de estudio
Esta gua no debe ser confundida con el cuerpo de conocimiento de la Ingeniera del Software. La
finalidad de S)E*+, -.ua de la Ingeniera del Software /uerpo de /onocimiento0 es describir que
parte de !ste es aceptado de manera general y se estableci con el fin de cumplir cinco ob'etivos"
#. 1romover una vista general y consistente de la ingeniera del software a nivel mundial.
%. 2ar claridad del conte3to en el que se aplica la ingeniera del software con respecto a otras
disciplinas, como la ingeniera de sistemas, la ciencia de los computadores, la
administracin de proyectos y las matemticas.
&. /aracteri4ar los contenidos de esta disciplina.
5. 1roveer acceso temtico al cuerpo de conocimiento de la ingeniera del software.
6. 1roveer la fundacin de un ente para apoyar el desarrollo, certificacin y licenciamiento de
material de calidad, relacionado con la disciplina.
Est estructurada en #% captulos completamente divididos en subcaptulos, que e3plican todos los
componentes del cuerpo de conocimiento de la ingeniera del software, basados en reas del
conocimiento, esquemati4adas en los siguientes grficos"
3
4
5
CAPITULO 2
REQUERIMIENTOS DE SOFTWARE
El rea del conocimiento de los requisitos de software -,70, se refiere al anlisis, especificacin y
validacin de los requisitos de software. Se (a demostrado ampliamente que el (ec(o de no reali4ar
bien este proceso trae consecuencias fatales en el desarrollo de cualquier producto de software.
1. Fu!"#$%&'
n requisito de software es una caracterstica que se debe e3(ibir para solucionar un cierto
problema en el mundo real. Se convierte en una combinacin comple'a de requisitos entregados por
parte de los usuarios implicados dentro del desarrollo de la solucin, teniendo en cuenta que pueden
corresponder a diferentes niveles 'errquicos, ambientes e intereses. Es importante tambi!n que
cada requisito sea comprobable, pensando tambi!n en las implicaciones que esto puede conllevar.
Se pueden clasificar de la siguiente manera"
R$(u)')%&' !$ P*&!u+%&
Se refiere a generar los parmetros del problema a solucionar para ser traducido a un software.
R$(u)')%&' !$ P*&+$'&
Se refiere ya a la parte t!cnica y a lo que voy a utili4ar para reali4ar el software -lengua'e de
programacin, por e'emplo0.
R$(u)')%&' Fu+)&",$'
Son las capacidades o funciones del software.
R$(u)')%&' N& Fu+)&",$'
Son los que act8an para obligar a llegar a la solucin pero no son parte integral del software.
C"*"+%$*-'%)+"' I$'.$*"!"'
Son requisitos que se toman pero no pueden comprobarse (asta que est! funcionando el software
en condiciones reales.
R$(u)')%&' !$, S)'%$#" / !$ S&0%1"*$
6
Se refiere a todo lo que necesita el software para funcionar desde el punto de vista de (ardware,
software, recurso (umano, informacin, instalaciones, servicios, etc. Los requisitos de software se
derivan de los del sistema.
2. P*&+$'& !$ ,&' *$(u)')%&'
Inicia de manera aislada y se va refinando con el modelo de ciclo de vida del software y necesita ser
adaptado a la organi4acin y al conte3to del proyecto.
A2$%$' !$ P*&+$'&
Incluye a todas las personas, usuarias o no, que participan en el desarrollo del proyecto. Es un
grupo interdisciplinario que aporta informacin para la construccin del software. 1ueden ser
usuarios, clientes, analistas de mercado, reguladores, ingenieros de software, etc.
A/u!" / G$*$+)" !$ P*&+$'&
Se refiere a toda la parte presupuestal y de gerencia para llevar a cabo el proyecto.
C",)!"! / M$3&*" !$ P*&+$'&
Se refiere al coste generado por control de calidad y a los niveles de cumplimiento para lograr el
ob'etivo principal y por ende, la satisfaccin del cliente.
4. C".%u*" !$ ,&' R$(u)')%&'
Se refiere al 9cmo: se van a recolectar los requisitos por parte del ingeniero de software. Es aqu
donde es clave la comunicacin con el cliente y con todas las personas implicadas en el proceso.
Fu$%$' !$ ,&' R$(u)')%&'
2eben ser confiables y sometidas a verificacin para confirmar que la persona que suministra la
informacin es idnea para (acerlo y que se tom el tiempo para anali4ar su conveniencia. ;o solo
por idoneidad sino porque en ocasiones los usuarios no son buenos escribiendo y no son claros a la
(ora de (acer una solicitud.
T5+)+"' !$ C".%u*" !$ R$(u)')%&'
7 menudo, el ingeniero de software utili4a t!cnicas de captura de requisitos, tales como"
Entrevistas
1rototipos
7
<euniones
+bservacin
4. A6,)')' !$ R$(u)')%&'
Es una auditora a todo lo que se recopil. 2e aqu salen los requisitos del sistema y por ende los
de software. 1ermite establecer limitaciones y viabilidad del proyecto.
C,"')0)+"+)7 !$ ,&' *$(u)')%&'
1ueden clasificarse en"
=uncionales o no funcionales
2e producto o de proceso
2erivado
1rioritario
Estable o >oltil
M&!$,& C&+$.%u",
Se debe elegir un modelo conceptual que ayude a entender de una me'or manera el problema. Es
una (abilidad con la que debe contar el ingeniero de software, apoyado en (erramientas que le
ayuden a conte3tuali4ar el software, como el caso de ?L o el uso de la matemtica discreta. La
IEEE tiene tres estndares para el modelado. Estos son"
IEEE Std #&%@.# -conceptual0
I2E=@ -funcional0
IEE Std #&%@.%, I2E=#ABC -de informacin0
A')2"+)7 A*(u)%$+%7)+" !$, D)'$8& / ,&' R$(u)')%&'
Es la fusin de toda la parte de requisitos con la parte de diseDo. Es inseparable esta combinacinE
una es parte integral de la otra y es fcil su comprensin, apoyndose en el modelo conceptual. El
estndar IEEE Std #5C#F%@@@ puede servir de apoyo en esta prctica.
N$2&+)"+)7 !$ ,&' *$(u)')%&'
8
Se llega a esta etapa cuando (ay incompatibilidad en dos o ms requisitos y los solicitantes son
distintos. El ingeniero de software debe reunirlos y tomar la decisin ms conveniente para el
correcto funcionamiento de la solucin.
9. E'.$+)0)+"+)7 !$ R$(u)')%&'
Se refiere a plasmar en un documento todos los requisitos aprobados. Someterlos a verificacin por
parte de los actores del proyecto. Es usual que se (agan tres documentos"
2efinicin del sistema o documento de e3igencias
<equisitos de sistema
<equisitos de software
Es importante esta parte porque sin aprobar alguno o todos los documentos, es imposible pasar a la
etapa de diseDo.
El estndar IEEE Std G&@ HIEEEG&@FBGI, apoya este proceso de especificacin de requisitos.
:. V",)!"+)7 !$ ,&' R$(u)')%&'
Su ob'etivo es determinar que los documentos reali4ados sean comprensibles y de acuerdo a los
estndares determinados. 1or esto, deben someterse a una auditora final reali4ada por todo el
personal implicado en el desarrollo del software -cliente0, para asegurarse de que lo plasmado all es
lo que se solicit.
R$;)')&$' !$ ,&' *$(u)')%&'
Se nombra un comit! revisor, que incluye a un representante del cliente, con el fin de evaluar los
documentos ya mencionados. El estndar IEEE Std #@%G proporciona ayuda valiosa en la tarea de
revisin.
P*&%&%)."!&
Es un medio que utili4a el ingeniero de software para manifestar lo que entendi y para facilitar la
correccin, eliminacin o adicin de requisitos. /omo se evidencia, la venta'a de (acerlo es grande
pero el costo puede ser alto.
P*u$<"' !$ A+$.%"+)7
Son aquellas que se le aplican a cada requisito para determinar si el producto final lo satisface o no.
2ebe (aber total planeacin para aplicar estas pruebas y (acerlo de manera cuantitativa.
9
/omo conclusin para este captulo puede afirmarse que los requisitos de software deben tomarse
como una prctica seria, asignndole el tiempo y los recursos necesarios que permitan continuar con
un proceso ordenado para llegar a obtener un software de calidad.
10
CAPITULO 4
DISE=O DE SOFTWARE
Es definido por la IEEE como el proceso para definir la arquitectura, los componentes, las interfaces
y otras caractersticas de un sistema. >isto como proceso, el diseDo del software es la actividad del
ciclo de vida en la cual se anali4an los requisitos del software para producir una descripcin de su
estructura interna que servir como base para su construccin.
1. Fu!"#$%&'
P*&+$'& !$ !)'$8& !$ '&0%1"*$
Se divide en dos etapas"
D)'$8& A*(u)%$+%7)+&
2escompone el software en componentes y describe sus partes a nivel general, de estructura.
D)'$8& D$%",,"!&
2escribe el comportamiento especfico de estos componentes.
E3isten t!cnicas permisibles que permiten (acer un acercamiento al diseDo de software. Estas son
algunas"
A<'%*"++)7
Es el proceso de olvidarse de la informacin para poder tratar las cosas que son diferentes como si
fueran iguales.
A+&.,"!&* / C&>$')7
El acoplador es la fuer4a de las relaciones entre los mdulos y la co(esin se refiere a la relacin
que e3iste entre estos mdulos.
D$'+&#.&')+)7 / M&!u,"*)?"+)7
Esta t!cnica se utili4a para poner diversas funcionalidades en componentes ms pequeDos.
E+".'u,"+)7
1ermite empaquetar informacin y (acerla invisible. El !3ito est en darle una buena funcin a esa
informacin.
11
El siguiente grfico muestra la descomposicin del proceso de diseDo de software.
S$."*"+)7 !$ ," )%$*0"? / !$ ," .u$'%" $ .*6+%)+"
2efine un componente a trav!s de su interfa4 grfica.
D$'">&2&
7segura que la abstraccin se (i4o de manera correcta y que slo se tom lo relevante del
componente.
2. Cu$'%)&$' +,";$' !$, !)'$8& !$ '&0%1"*$
/ontribuye a entender cmo dividir, organi4ar y constituir los paquetes de software. Se ayuda con las
siguientes llaves"
C&+u**$+)"
Se refiere a cmo descomponer el software en procesos, tareas, (ilos de reparto y que conserve la
sincroni4acin en los procesos.
D)'%*)<u+)7 !$ C&#.&$%$'
12
/omo integrar cada parte del software con el (ardware necesario para su funcionamiento.
D)*$++)7 !$, E**&* / !$ E@+$.+)7 / T&,$*"+)" " F",,&'
2efine las t!cnicas para prevenir y tolerar fallos en el momento en que se presenten.
I%$*"++)7 / P*$'$%"+)7
Se refiere a la forma de mostrar y organi4ar las interacciones con los usuarios y la forma de
documentarlas.
4. E'%*u+%u*" / A*(u)%$+%u*" !$ S&0%1"*$
Es una descripcin de los subsistemas y de los componentes de un sistema de software y de las
relaciones entre ellos.
4. A6,)')' / E;",u"+)7 !$ ," C",)!"! !$, D)'$8& !$ S&0%1"*$
Esta parte es importante porque asegura la calidad del proceso de diseDo. Se utili4an m!tricas que
permiten estimar de manera cuantitativa varios aspectos del tamaDo, estructura o de la misma
calidad del software. Estas pueden ser estructuradas u orientadas a ob'etos.
9. N&%"+)&$' !$, D)'$8& !$ S&0%1"*$
.eneralmente son grficas y permiten modelar en un diagrama la propuesta de diseDo. Entre ellos
estn los diagramas de clases y ob'etos, de componentes, de despliegue, de entidadFrelacin, de
estructura de JacKson, de estructura de cartas y diferentes lengua'es que permiten describir la
arquitectura del software y sus componentes.
Lambi!n e3iste la notacin para las descripciones de comportamiento dinmico del software, en las
cuales tambi!n se usan diagramas y lengua'es te3tuales. Entre ellos estn los diagramas de
actividad, de colaboracin, organigrama de datos, tablas y diagramas de decisin, de secuencia, de
transicin de estado y diagramas de estado de carta, lengua'es de diseDo en pseudocdigo, etc.
:. E'%*"%$2)"' / M5%&!&' !$, D)'$8& !$ S&0%1"*$
1ermiten dirigir el proceso de diseDo. La estrategia est en t!rminos generales y los m!todos deben
ser especficos. 7qu se inicia la aplicacin del paradigma 2ivide y >encers y el proceso de
refinamiento. Se define tambi!n si se va a utili4ar el diseDo estructurado u orientado a ob'etos o
basado en componentes.
13
CAPITULO 4
CONSTRUCCION DEL SOFTWARE
Este captulo (ace 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 Mrea de /onocimiento de la /onstruccin del Software est vinculada a todas las otras ,7s
-Mreas de /onocimiento0, ms fuertemente al 2iseDo del Software y a las 1ruebas del Software.
Esto se debe a que el proceso mismo de construccin del software cubre tanto el diseDo significativo
de software como las actividades de pruebas.
En sntesis, esta es la etapa de creacin del cdigo fuente que tendr el software.
1. Fu!"#$%&'
La construccin del software tiene como ob'etivos los siguientes"
?inimi4ar la comple'idad
7nticiparse a los cambios
/onstruir para verificar
7plicacin de estndares en la construccin
La descomposicin de los temas de /onstruccin del Software se detallan en el siguiente grfico"
14

2. G$'%)7 !$ ," C&'%*u++)7
M&!$,&' !$ C&'%*u++)7
Los ms conocidos y utili4ados son los modelos de ciclo de vida en cascada y de entrega por
etapas. Estos modelos son robustos pero solo son eficientes si se (a (ec(o un buen traba'o en la
etapa de requisitos y de diseDo. 1or el contrario, los modelos prototipado evolucionista,
programacin e3trema y 9Scrum:, son ms fle3ibles en este tema, dado que son iterativos y
permiten, de manera cclica, reali4ar cambios, al combinar las tres etapas iniciales del desarrollo de
un proyecto de software.
P,")0)+"+)7 !$ ," C&'%*u++)7
En todo proyecto, la planificacin es vital. Es aqu donde se delimita la aplicacin de requisitos, en
qu! orden se irn tomando y que grado de cumplimiento tienen, con respecto al ob'etivo principal del
proyecto. 2e a( la importancia de elegir un modelo de ciclo de vida acorde a los requerimientos.
M$!)+)7 !$ ," C&'%*u++)7
Se refiere a los procedimientos utili4ados para medir la eficiencia del cdigo fuente, en lo que se
refiere a e3tensin, cdigo reutili4ado, cdigo destruido, comple'idad de cdigo, estadsticas de
inspeccin de cdigo, tasas de rectificacin y correccin de errores y los (orarios. Esto asegura el
control de la calidad.
4. C&')!$*"+)&$' P*6+%)+"'
1ara solucionar un problema de la vida real a trav!s de un software, es totalmente necesario utili4ar
un lengua'e de programacin. 7qu radica el !3ito del proyecto de software, dado que es el
ingeniero de software el encargado de aprobar el lengua'e a trav!s de los argumentos dados por los
encargados de la elaboracin del cdigo fuente.

L$2u"3$' !$ C&'%*u++)7
Son todos los tipos de comunicacin mediante los cuales un ser (umano puede especificar una
solucin e'ecutable para un problema de un ordenador. 1ueden ser de configuracin, de
(erramientas y de programacin. Estos 8ltimos, a su ve4, estn divididos en lingNsticos, formales y
visuales.
P*u$<"' !$ C&'%*u++)7
.eneralmente son reali4adas por el profesional que reali4 el cdigo. 1ueden ser unitarias o de
integracin. Su propsito es reducir el tiempo entre el ingreso de fallas en el cdigo y el tiempo que
se puede demorar su deteccin. 1ara tal fin, las normas estndar IEEE Std G%BF#BBG para
documentacin de pruebas y la IEE Std #@@GF#BGC para pruebas unitarias, pueden ser de gran
utilidad.
15
R$u%),)?"+)7
2efinir de manera ob'etiva, que parte del cdigo puede ser eficientemente reutili4ado para minimi4ar
tiempos de entrega, adems debe ser reportado a las personas que lideran el proyecto, por qu! y
para que se va a reutili4ar, ya que esto puede modificar el valor del proyecto, por e'emplo.
C",)!"! !$ ," C&'%*u++)7
E3isten varias t!cnicas para evaluar la calidad en la construccin del cdigo fuente de un proyecto
de software. Entre ellas tenemos"
L"' .*u$<"' u)%"*)"' / !$ )%$2*"+)7
El cdigo paso a paso
tili4acin de aserciones
2epuracin
<evisiones t!cnicas
7nlisis esttico
I%$2*"+)7
na parte clave del proceso de construccin es la integracin de las clases, componentes, rutinas,
subsistemas que (an sido construidos por separado, sobre todo si (ay implicaciones t!cnicas de
software o (ardware.

16
CAPITULO 9
PRUEBAS DEL SOFTWARE
Es una actividad que permite evaluar y me'orar la calidad del producto con el fin de detectar fallas y
corregir errores.
Las pruebas del software consisten en verificar el comportamiento de un programa dinmicamente a
trav!s de un grupo finito de casos de prueba, debidamente seleccionados. Se (a ido cambiando la
percepcin de que las pruebas de software se reali4an 8nicamente al final del proceso de creacin
de cdigo fuente, siendo muy 8til (acerlo en todas las etapas del desarrollo del softwareE esto
permite corregir errores y detectar fallas de fondo, a tiempo.
En la figura que sigue se pueden apreciar las partes que intervienen en le proceso de pruebas de
software.
17
CAPITULO :
MANTENIMIENTO DE SOFTWARE
INTRODUCCION
El proceso de desarrollo de software debe satisfacer los requerimientos planteados, una ve4 en
operacin el proceso de cubrimiento de defectos, operacin y cambio de ambiente debe darse en
esta etapa, la fase de mantenimiento empie4a con un periodo de garanta y de soporte postF
implementacin pero el mantenimiento del software ocurre muc(o antes.
7unque la etapa de mantenimiento del software no (a tenido el grado de atencin que se debe este
tipo de desarrollo de software ya esta empe4ando a cambiar ya que muc(os errores graves (an
ocurrido por no prestarle la atencin que se merece.
El mantenimiento de software se (a definido como el n8mero total de actividades requeridas para
proveer soporte efectivo al software, esto incluye un planeamiento efectivo antes. 2urante y despu!s
de la implementacin del software.
1. A'.$+%&' Fu!"#$%",$' $ $, #"%$)#)$%& !$, '&0%1"*$A
7qu se introduce a los aspectos fundamentales del mantenimiento del software"
1.1 Definiciones y terminologa:
Est definido en el estndar de la IEEE #%#B como la modificacin del producto de software
despu!s de la entrega para corregir las faltas, tambi!n se encarga de direccionar las actividades
de mantenimiento para darle prioridad a la entrega del producto.
El estndar IEEEOEI7 #%%@C define el mantenimiento como uno de los procesos principales en el
ciclo de vida del software, el ob'etivo es modificar el software e3istente preservando su
integridad tambi!n lo (acen en estos mismos t!rminos la IS+OIE/ #5CP5 este enfati4a en las
entregas previas para la planeacin del mantenimiento del software.
1.2 Naturaleza del mantenimiento:
18
El mantenimiento de software debe estar dentro del ciclo de vida operacional, un mantenimiento
esta definido por la IEEEOEI7 #%%@C como las actividades de mantenimiento que permiten el
desempeDo correcto.
Identifica las actividades de mantenimiento como un proceso de implementacin y modificacin
y anlisis del problema, estas actividades son discutidas en el tpico &.% Actividades de
Mantenimiento.
F)2u*" 1. Lpicos a tener en cuenta en el mantenimiento del software
1.3 Necesidad de mantenimiento:
La necesidad de mantenimiento se da para garanti4ar que el software cumple satisfactoriamente
con los requerimientos solicitados, este se aplica a cualquier desarrollo independiente del
modelo de ciclo de vida utili4ado, el mantenimiento se da en orden de alcan4ar el desempeDo
adecuado y en el orden de"
19
/orregir fallas.
Improvisar el diseDo.
Implementar correcciones.
Interfaces con otros sistemas.
7daptar programas a diferentes tipos de (ardware, software, configuracin del sistema y
facilidad de uso de telecomunicaciones.
?igracin legal de software.
<etiro de software.
1.4 Costos Mayoritarios de mantenimiento:
Los costos de mantenimiento de software son los mas costosos en todo el ciclo de vida del
software, estudios recientes (an demostrado que ms del G@Q del mantenimiento de software
es usado para acciones correctivas (ay que entender la categora del mantenimiento del
software para entender la estructura del costo de mantenimiento, entendiendo los factores que
influyen en el costo se puede ayudar a contener dic(os costos, a continuacin se presentan
algunos aspectos t!cnicos y no t!cnicos que afectan los costos de mantenimiento"
Lipo de 7plicacin.
2isponibilidad del mantenimiento de software.
/iclo de vida del software.
/aractersticas de (ardware.
/alidad del diseDo de software, construccin, documentacin y pruebas.
1. !voluci"n del soft#are:
En #BPB Le(man direcciono el mantenimiento del software y la evolucin de los sistemas,
durante %@ aDos se mantuvo su idea de la formulacin de oc(o 9Leyes de la evolucin: donde
se mantuvo la idea de la evolucin en el mantenimiento del software para continuar con el
desarrollo.
Lient4 y Swanson iniciali4aron la definicin de tres categoras de mantenimiento" correctivo,
adaptativo y perfectivo.
2. F"+%&*$' +,";$' $ $, #"%$)#)$%& !$, '&0%1"*$A
n numero de factores claves debemos tener presentes para asegurar el mantenimiento
efectivo del software, es importante comprender que el mantenimiento de software nos
proporciona una t!cnica 8nica en los desafos de administracin para los ingenieros de
20
software, podemos apreciar como se planean las liberaciones posteriores as como los parc(es
generados para las versiones anteriores, lo que sigue a continuacin nos presenta una manera
de cmo se nos presentan algunos factores de administracin y t!cnicos para el mantenimiento
de software, estos se agrupan seg8n los tpicos siguientes"
=actores t!cnicos.
=actores administrativos.
Estimacin de costos.
?edidas.
4. P*&+$'& !$ #"%$)#)$%&A
1rovee referencias y estndares utili4ados para implementar el proceso de mantenimiento
de software.
Las actividades de mantenimiento son diferenciadas por el desarrollo mostrado en la
relacin a las actividades de ingeniera de otro software.
F)2u*" 2. 7ctividades en el proceso del mantenimiento
En la figura planteada por la IS+OIE/ se puede apreciar que es muy parecida a la anterior
que es IEEE pero en esta se agrega una pequeDa diferencia"
21
/ada actividad de mantenimiento primario de software IS+OIE/ #5CP5 es desglosada en
los siguientes t!rminos"
1roceso de implementacin.
7nlisis del problema y modificaciones.
Implementacin y modificacin.
?antenimiento 7ceptacinO<evisin.
?igracin.
<etiro de Software.
T5+)+"' ."*" $, #"%$)#)$%&A
Esta subrea nos introduce a algunas generalidades aceptadas por las t!cnicas del
mantenimiento de software"
3.1 Com$rensi"n del $rograma
Los programadores gastan tiempo considerable leyendo y entendiendo programas para
poder implementar cambios e3isten distintas (erramientas que nos ayudan con este
proceso.
3.2 %eingeniera
Esta definida como el e3amen de de la alteracin del software para reconstituir una nueva
forma, la reingeniera es la mas radical y e3pansiva forma de la alteracin otros creen que
la reingeniera puede ser usada para cambios menores, siempre est enfocada en
mantener la legalidad del software asi como sus t!cnicas, casos de estudio y sus riesgos y
beneficios.
3.3 &ngeniera inversa
Es el proceso de anali4ar el software para identificar los componentes y sus relaciones para
crear representaciones del software dic(o de otra forma desde un nivel mas alto de
abstraccin, es pasiva, y no (ace cambios al software o resulta en otro software. 1roduce
grficas asi como control de flu'o y del cdigo fuente, un tipo de reingeniera puede ser la
redocumentacin, otro tipo es la reparacin del diseDo.
=inalmente la reingeniera (a sido de gran importancia en los 8ltimos aDos ya que gracias a
sus esquemas lgicos a podido restaurar bases de datos fsicas.
CAPITULO B
ADMINISTRACION DE LA CONFIGURACION DEL SOFTWARE
22
n sistema puede ser definido como un con'unto de componentes organi4ados con el propsito de
cumplir una funcin o con'unto de funciones especficas.
En este sentido la configuracin de un software y sus caractersticas funcionales de (ardware,
software, firmware o la combinacin de estas son un con'unto de caractersticas t!cnicas que se
deben cumplir para garanti4ar su correcto funcionamiento.
La administracin de configuracin es la disciplina encargada de identificar la configuracin general
de un sistema para as mantener su confiabilidad, adaptabilidad y configuracin a los diferentes
ciclos de vida. Est formalmente definida por la IEEEP#@.#%FB@ como 92isciplina aplicada de manera
t!cnica y administrativa para la direccin y supervivencia para" Identificar y documentar las
caractersticas fsicas y funcionales de la configuracin de los elementos, control en el cambio de
sus caractersticas grabar y reportar cambios en el proceso de implementacin as como su estado
y verificacin del cumplimiento de sus requerimientos especficos:.
1. A!#))'%*"+)7 !$ ,&' .*&+$'&' SCM
La S/? administra y controla la evolucin e integridad del software as como su verificacin,
control, reportes y configuracin de la informacin. na implementacin e3itosa del S/?
requiere un cuidado especial y planeacin y administracin.
1.1 Conte'to (rganizacional del )CM
23
1ara desarrollar un plan S/? es necesario conocer detalladamente los procesos de la
organi4acin ya que el S/? interact8a directamente con todos los elementos y actividades
organi4acionales.
1.2 Constantes y gua $ara el $roceso )CM
Esto proviene de un gran numero de fuentes tiene que ver con las polticas de la
organi4acin y su influencia en la administracin de los procesos.
1.3 *laneaci"n del )CM
El proceso de planeacin debe ser consistente con el conte3to organi4acional, y la
naturale4a del proyecto -por e'emplo el tamaDo y su crtica0 las actividades ms importantes
en este conte3to son" control de configuracin, control de estado, control de auditora,
control de liberaciones y entregas as como las (erramientas de configuracin y control y
sus interfaces consideradas.
1.4 *lan de la )CM
Los resultados de planeacin del proyecto son guardados en un plan de gestin y
configuracin del software, el documento se mantiene y se actuali4a o aprueba seg8n sea
necesario a lo largo del ciclo de vida del software.
Lambi!n es muy 8til (acer mediciones constantes a los procesos para (acer los cambios yOo
actuali4aciones correspondientes.
1. )eguimiento de la gesti"n de la configuraci"n del soft#are
2espu!s del cumplimiento del proceso de la S/? puede ser necesario un cierto nivel de
seguimiento para asegurarse que los procesos S/? se llevan a cabo adecuadamente, este
seguimiento puede (acer parte de un proceso de auditora para garanti4ar la calidad del
software.
El uso de (erramientas integradas en la S/? facilita el proceso de seguimiento.
1..1 Medidas y mediciones de la )CM
1roporcionan un buen medio para monitori4ar la efectividad de las actividades S/? de
una manera continuada, son 8tiles para caracteri4ar el estado actual del proceso y para
proporcionar una base para (acer comparaciones con el tiempo.
Las bibliotecas de software y las diferentes (erramientas proporcionan fuentes para
e3traer la informacin acerca de las caractersticas de los procesos S/?.
2. I!$%)0)+"+)7 !$ ," +&0)2u*"+)7 !$, '&0%1"*$
24
Identifica los elementos a ser controlados, establece e identifica esquemas y sus versiones,
establece (erramientas y t!cnicas utili4adas para administrar y controlar dic(os elementos.
2.1 &dentificar elementos a ser controlados
n primer paso sera identificar cambios en los elementos de software que sern
controlados para entender la configuracin del software en el conte3to del sistema.
2.2 +i,lioteca de soft#are
/oleccin controlada de software as como de sus documentos relacionados y est
relacionada para ayudar en el desarrollo de software, a( diferentes tipos y nos pueden
ayudar en diferentes etapas, son tambi!n una fuente importante de informacin para
mediciones del traba'o reali4ado y del progreso.
4. C&%*&, !$ ," +&0)2u*"+)7 !$, '&0%1"*$
Le concierne la gestin de cambios durante el ciclo de vida, cubre los procesos que
determinan los cambios a reali4ar, la autoridad para (acerlos y el soporte para la
implementacin de dic(os cambios.
La informacin derivada de estas actividades es 8til para medir el trfico de cambios y
ruptura de aspectos por re(acer.
3.1 *etici"n- evaluaci"n y a$ro,aci"n de cam,ios del soft#are
El primer paso es determinar los cambios a reali4ar, se eval8a el coste e impacto del cambio
propuesto se acepta o rec(a4a dic(o cambio, este se origina en cualquier momento del ciclo
de vida y puede incluir una solucin propuesta y una prioridad.
3.2 &m$lementando cam,ios en el soft#are
Se implementan utili4ando los procesos de software definidos de acuerdo con los
requerimientos de planificacin aplicables.
1odran sufrir auditoras de configuracin y verificacin de la calidad del software. Esta
soportada por las (erramientas de la biblioteca que proporcionan gestin de versiones y
soporte para el almacenamiento de cdigo.
3.3 Desviaciones y %emisiones
Las limitaciones que se imponen al esfuer4o de la ingeniera del software podran contener
necesidades que no pueden ser satisfec(as en el punto designado del ciclo de vida. na
25
remisin es una autori4acin para abandonar una necesidad antes del desarrollo del
elemento.
4. R$2)'%*& !$, $'%"!& !$ ," +&0)2u*"+)7 !$, S&0%1"*$
La contabilidad del estado de la configuracin del software -S/S70 es la actividad de
registrar y proporcionar la informacin necesaria para una gestin efectiva de la
configuracin del software.
4.1 &nformaci"n del estado de la configuraci"n del soft#are
.enera un con'unto de informes durante el ciclo de vida, se encarga de recoger y mantener
la informacin del estado de la configuracin que se (a de gestionar seg8n las
configuraciones evolucionan.
Es necesario alg8n tipo de soporte de (erramientas automticas para llevar a cabo las
tareas de recogida de datos y generacin de informes de la S/S7.
4.2 %e$ortes del estado de la configuraci"n del soft#are
Los reportes pueden ser usados para los elementos del proyecto de la organi4acin,
incluyendo el equipo de desarrollo, administracin de proyectos y actividades de calidad del
software.
Lambi!n sirve para responder algunas preguntas especficas de la etapa de produccin.
9. Au!)%&*-" !$ ," +&0)2u*"+)7 !$ '&0%1"*$
Es una actividad desarrollada independientemente para evaluar la conformidad de los
productos de software, se encarga de aplicar regulaciones, estndares, planes de gua y
procedimientos.
2eben ser cuidadosamente planeadas, e3isten (erramientas que apoyan la planeacin y
conduccin de las auditoras para facilitar su proceso.
2etermina la e3tensibilidad de los elementos y sus caractersticas fsicas, los informes
pueden ser orientados como puntos clave en el ciclo de vida, las auditorias pueden ser un
requisito para las lneas base.
.1 Auditoria funcional de la configuraci"n del soft#are
El propsito es asegurar la consistencia en los elementos de software auditados. La salida
de la verificacin y validacin del software es la clave de entrada de este tipo de auditora.
.2 Auditora de la configuraci"n fsica del soft#are
El propsito es asegurar que el diseDo y la documentacin de referencia es consistente con
la construccin del producto de software.
26
.3 Auditora durante el $roceso de una lnea ,ase de soft#are
/omo lo mencionado puede ser llevado durante el proceso de desarrollo para investigar el
estado actual de los elementos especficos de la configuracin. La auditora es aplicada a
los elementos de la lnea base para asegurar el desempeDo que sea consistente con las
especificaciones.
:. A!#))'%*"+)7 !$ ,"' $%*$2"' / ,)<$*"+)&$' !$ '&0%1"*$
El t!rmino 9liberacin: es usado en este conte3to para referirnos a las distribuciones de
software y los elementos en las actividades de desarrollo. Eso incluye liberaciones internas y
correcciones a las variantes de estos elementos.
La informacin y documentacin entregada en las liberaciones es conocida como el
documento descriptivo, este incluye los contenidos de instalacin y instrucciones de
actuali4acin.
CAPITULO C
GESTION DE LA INGENIERIA DEL SOFTWARE
1uede ser definida como las actividades de gestin de la aplicacin, planeacin, coordinacin,
medicin, monitori4acin, control y reportes para asegurar el desarrollo y mantenimiento del software
como sistemtico, disciplinado y cuantificable.
Es un aspecto muy importante en la administracin y medicin de la ingeniera del software.
En estas actividades se destacan tres niveles" .estin y organi4acin de la infraestructura, gestin
de proyectos, y control y planeacin del programa de medidas.
Los aspectos de la gestin de la organi4acin son importantes en t!rminos del impacto en la
ingeniera del software y en las polticas de gestin, esas polticas pueden ser influenciadas por los
requerimientos de un software efectivo, mantenimiento y desarrollo.
n n8mero de polticas especficas deben ser establecidos para una efectiva gestin en la ingeniera
del software y el nivel organi4acional.
Raciendo gestin con !nfasis en la medicin y un principio de presupuesto en cualquier disciplina de
verdadera ingeniera puede ayudar a darle la vuelta a esta percepcin.
na gestin efica4 requiere la combinacin tanto de n8meros como de e3periencia.
27
La gestin en la ingeniera del software se descompone en seis subreas principales a continuacin
se da un espacio detallado de cada una.
1. I)+)"+)7 / A,+"+$
Se centra en la determinacin efica4 de los requisitos del software por medio de varios m!todos de
induccin y la valoracin de la viabilidad del proyecto desde distintos puntos de vista, una ve4
establecida la viabilidad, la tarea pendiente es la especificacin de la validacin de requisitos y del
cambio de procedimientos.
28
2. P,")0)+"+)7 !$ u P*&/$+%& !$ S&0%1"*$
Esta regulado por los alcances y los requisitos y por la viabilidad del proyecto, se eval8an los
procesos de ciclo de vida y se selecciona el ms apropiado.
Se debe reali4ar una descomposicin 'errquica de tareas, y la reali4acin de un calendario y una
estimacin de costos.
?s adelante se le da un presupuesto a las tareas y la imposicin de (orarios y uso de materiales,
se debe llegar a la determinacin de procesos y responsabilidades para asegurar la calidad del
software, verificacin, validacin y revisiones de auditoras.
2.1 *lanificaci"n de un *roceso
La seleccin de un modelo de ciclo de vida o la adaptacin de un despliegue de ciclos se emprenden
a la lu4 del alcance particular y de los requisitos del proyecto.
Lambi!n se seleccionan m!todos y (erramientas pertinentes.
2.2 Determinar los entrega,les
Se especifica y caracteri4a los productos de cada tarea, se eval8a la posibilidad de reutili4ar
componentes de desarrollos anteriores y se planifica la utili4acin de terceras personas y del
software obtenido y se seleccionan los proveedores.
2.3 !sfuerzo- calendario y c.lculo del coste
Se determina el rango de esfuer4o esperado, utili4ando un modelo de estimacin calibrado, basado
en datos (istricos sobre el esfuer4o empleado.
/uando sea posible se solucionan cuellos de botella, y se elabora el esperado cuadro de tareas con
los (orarios de inicio, duraciones y (orarios de finali4acin bien planificados.
Los requisitos de recursos -personas, (erramientas0 se traducen en estimaciones de costo.
2.4 %e$arto de recursos
Los equipos, medios y personas se asocian a las tareas programadas, esta actividad est regulada y
limitada por la disponibilidad de los recursos y su uso ptimo ba'o estas circunstancias.
2. /esti"n de %iesgos
Se completa el anlisis de riesgos, la valoracin crtica de riesgos, la mitigacin de riesgos y la
planificacin de contingencias.
Los m!todos para la valoracin del riesgo deben utili4arse para resaltar y evaluar riesgos, en esta
etapa se deben evaluar las posibilidades de abandono del proyecto en conversaciones con todos los
contratistas.
2.0 /esti"n de calidad
29
Se define en t!rminos de atributos pertinentes del proyecto y en los de cualquier producto asociado
a !l, tanto en t!rminos cualitativos como cuantitativos.
Los lmites de ad(esin de calidad se colocan de acuerdo a las e3pectativas que tenga el contratista
sobre el software en cuestin as como los procedimientos de verificacin y validacin del producto
entregable.
2.1 /esti"n de $lanes
Los informes, la supervisin y el control del proyecto deben enca'ar en el proyecto de ingeniera del
software seleccionado y en las realidades del proyecto y deben refle'arse los artefactos que lo
gestionarn.
Los cambios a otros procesos de soporte e'emplo" gestin documental, resolucin de problemas
tambi!n deben gestionarse de la misma manera.
4. P*&#u,2"+)7 !$, .*&/$+%& !$ S&0%1"*$
Se e'ecutan los planes y se divulgan los procesos incluidos en los planes, en este proceso (ay total
e3pectativa de la ad(esin plena de los requisitos del contratista y el logro de los ob'etivos del
proyecto, son actividades fundamentales para la promulgacin la gestin, medicin, supervisin,
control e informacin del proyecto.
4. R$;)')7 / E;",u"+)7
Se eval8a el proceso global (acia el logro de los ob'etivos y satisfaccin de los requisitos del
contratista y se llevan a cabo valoraciones sobre la efectividad del proceso global (asta la fec(a, del
personal involucrado y de las (erramientas y m!todos utili4ados.
4.1 Determinar la satisfacci"n de los re2uisitos
2eterminar que el ob'etivo principal se est cumpliendo es primordial ya que lo que nos interesa es
la satisfaccin del usuario o contratista esto se debe (acer peridicamente.
Se deben identificar las variaciones a las e3pectativas para llevar a cabo las acciones adecuadas.
Lambi!n se debe gestionar el control de cambios a los procedimientos y a la configuracin del
software.
4.2 %evisar y !valuar la !3ecuci"n
Las revisiones peridicas a lo reali4ado nos proporcionan detalles sobre la probabilidad de ser fiel a
los planes, as como las posibles reas de dificultad, aqu se eval8an los diferentes m!todos,
(erramientas y t!cnicas empleadas para ver su eficacia y adecuacin y se eval8a constantemente la
eficacia de los procesos para ver su utilidad en el conte3to del proyecto, cuando sea necesario se
gestionan y se llevan a cabo los cambios.
30
9. C)$**$
El proyecto llega a su fin cuando todos los planes y procesos implicados se (an promulgado y
completado, en esta fase se repasan ciertos criterios para el !3ito del proyecto.
Se (an entregado los procesos tal como se (aban especificado y todos los productos planificados
(an sido entregados con caractersticas aceptables.
.1 Determinar el cierre
Se logran los ob'etivos del proyecto y estos procesos por lo general involucran a los contratistas y
acaban con la documentacin y de los informes de cualquier otro problema pendiente conocido.
.2 Actividades de cierre
Se arc(ivan los materiales del proyecto y la base de datos de medicin de la organi4acin se pone
al da con los datos finales del proyecto y se emprende el anlisis postFproyecto.
Se (ace con el fin de identificar temas. 1roblemas y oportunidades encontrados durante el proceso,
se sacan las lecciones del proceso y luego se alimentan los conocimientos de la organi4acin y los
intentos de me'ora.
:. M$!)!"' !$ ," )2$)$*-" !$, '&0%1"*$
7qu abordamos el tema de la medicin en la ingeniera del software y su importancia para esto se
sigue unas m!tricas y normas establecidas por entidades como la IS+ y la IEEE.
0.1 !sta,lecer y sostener el com$romiso de medir
Se deben tener ciertos compromisos de medicin establecidos, adems de requisitos que midan los
factores que contribuyen a un ob'etivo en particular para as gestionar los proyectos y (acerle frente
a este ob'etivo.
Se debe establecer una unidad u ob'etivo a medir en la organi4acin, adems se debe adquirir un
compromiso que se debe comunicar y apoyar en los recursos de la organi4acin.
Se deben asignar recursos para llevar a cabo el proceso de medicin adems de dar la financiacin
y (erramientas adecuadas para dirigir este proceso.
0.2 *lanificar el $roceso de medici"n
1ara esto es necesario identificar la unidad funcional a la cul se le est aplicando para que sea
caracteri4ada y as identificar las necesidades de informacin para proceder con los ob'etivos
primordiales y sus respectivas prioridades.
Se deben seleccionar las mediciones a reali4ar adems como las muestras de informacin que
sern tomadas para su posterior anlisis, verificacin e informacin a ser dada.
31
El plan de medicin tambi!n debe ser revisado y aprobado por los contratistas adecuados adems
de mantener disponibles los recursos para dic(o plan.
Se deben comunicar los resultados adems de documentarse publicarse.
0.3 !valuar las mediciones
Este proceso se debe llevar a cabo con un criterio de evaluacin especfico para determinar las
fuer4as y debilidades de los productos, se puede (acer por medio de un proceso de auditora interna
o e3terna y debe incluir una retroalimentacin a los usuarios.
Se deben identificar las me'oras potenciales y costos y beneficios de estas, comunicarlas a la
persona encargada para su revisin y aprobacin.
CAPITULO 9
PROCESO DE INGENIERDA DEL SOFTWARE
Se puede e3aminar en dos niveles desde lo t!cnico y desde el metaFnivel o nivel de implementacin,
valoracin, medicin y gestin.
E3isten varios significados sobre el proceso de la ingeniera del software puede verse como una sola
manera de reali4ar el proceso o como muc(as maneras que es lo que se quiere y se debe llegar a
32
(acer ya que el proceso de la ingeniera abarca muc(os factores, finalmente un tercer significado se
refiere al con'unto actual de actividades reali4adas dentro de una organi4acin que se puede ver
como un solo proceso.
Los procesos de ingeniera del software son considerados de gran importancia, el ob'etivo es
gestionar nuevos y me'ores procesos.
1. P*&+$'& !$ )#.,$#$%"+)7 / +"#<)&'
Se centra en los cambios organi4acionales, describe la infraestructura, actividades, modelos y
consideraciones prcticas de un proceso de implementacin y cambios"
Lambi!n es denominado el proceso de evaluacin, (ay que tener cuidado con las modificaciones ya
que puede que tambi!n sean necesarios cambios en la cultura organi4acional.
1.1 &nfraestructura del $roceso
Es necesario que la infraestructura este en su lugar, es decir que los recursos est!n al alcance de la
mano y que se (ayan asignado responsabilidades, es posible que se tengan que establecer comit!s
para supervisar el esfuer4o del proceso de ingeniera del software.
/on un grupo de proceso de la ingeniera del software se pretende ser el foco central en el proceso
de me'oras y tiene cierto n8mero de responsabiidades en la iniciali4acin y el mantenimiento.
El concepto de creadora de e3periencias -E=0 se centra en el proceso de me'oramiento de los
procesos de la ingeniera del software.
2. D$0))+)7 !$ .*&+$'&'
1ueden ser unos lineamientos, polticas o estndares se definen para facilitar el entendimiento
en la comunicacin (umana, apoyar y me'orar procesos , se deben considerar algunas variaciones
como la naturale4a del traba'o, el dominio de la aplicacin, el modelo de ciclo de vida y la madure4
de la organi4acin.
4. V",&*"+)7 !$, .*&+$'&
Se lleva a cabo utili4ando un m!todo y un modelo de valoracin que en algunos casos es visto como
un modelo de apreciacin y muc(as veces una evaluacin de capabilidad cuando es para la
ad'udicacin de alg8n contrato.
3.1 Modelos de valoraci"n del $roceso
33
<ecoge lo que se conoce como las buenas prcticas en el proceso de gestin de la ingeniera del
software, la IS+ define un modelo e'emplo de valoracin y de requisitos, se (an desarrollado
tambi!n un modelo de madure4 para sistemas de ingeniera que resulta 8til cuando un proceso est
implicado en el desarrollo y mantenimiento de un sistema incluyendo el software.
E3isten dos arquitecturas generales para un modelo de valoracin" continua y escalonadamente, son
muy diferentes entre ellas y se deben evaluar para conocer cul es la que me'or se adapta a mis
necesidades y ob'etivos.
3.2 M4todos de valoraci"n del $roceso
Es garanti4ar un m!todo cuantitativo que evaluara los procesos, e3isten de varios tipos dnde se
valoran distintos tpicos todos pensados en las me'oras de los procesos y la eficacia en la
organi4acin.
4. M$!)+)7 !$ ,&' .*&+$'&' / ,&' .*&!u+%&'
7unque puede resultar comple'a la medicin a la ingeniera del software e3isten varios aspectos que
son fundamentales para la medicin y anlisis, estas mediciones se pueden reali4ar para apoyar los
procesos de implementacin y cambio o evaluar consecuencias de estos.
4.1 Medici"n del $roceso
Se recoge, anali4a e interpreta informacin cuantitativa sobre el proceso, se utili4a para identificar la
fuer4a y debilidad en ellos y as mismo evaluarlos despu!s de (aber sido implementados o
cambiados.
34
La medicin de un producto software incluye principalmente, la medicin del tamaDo del producto, la
estructura del producto y la calidad del producto.
Lambi!n es importante tener en cuenta la medicin del tamaDo, de la estructura y de la calidad.
1ara garanti4ar la calidad en los resultados de la medicin es necesaria la medicin efectiva de los
programas para proveer resultados e3itosos.
CAPITULO 10
INSTRUMENTOS E MFTODOS DE LA INGENIERDA DEL SOFTWARE
Son los instrumentos asistidos por ordenador que son requeridos para ayudar a los procesos de
ciclo de vida del software, nos ayuda a reducir la carga cognoscitiva enfocndonos ms en los
aspectos creativos del proceso.
Los m!todos imponen la estructura a la actividad de la ingeniera del software con el ob'etivo de
(acerla sistemtica, por lo general proporcionan notacin y vocabulario para comprobar tanto el
proceso como el producto, aunque e3isten numerosos materiales sobre los instrumentos de apoyo
en la ingeniera del software, los te3tos sobre las t!cnicas sobre estos instrumentos son
relativamente escasos, una dificultad es el alto costo que representa un cambio de instrumento de
software en general, los instrumentos y m!todos cubren ciclos de vida completos por esto es tan
complicado (acer un cambio.
E'%u!)& !$ ,"' >$**"#)$%"' / #5%&!&' !$ ," )2$)$*-" !$ '&0%1"*$
1. L"' >$**"#)$%"' !$ )2$)$*-" !$ S&0%1"*$
Ests corresponden a las cinco primeras reas de conocimiento de la gua, E3igencias de software,
diseDo de software, construccin de software, pruebas de software y mantenimiento de software.
Los cuatro siguientes asuntos corresponden a las reas de conocimiento restantes" La direccin de
configuracin de software, la direccin de ingeniera de software, el proceso de ingeniera de
software, y la calidad del software.
1.1 5as 6erramientas de e'igencias de )oft#are
Ran sido clasificados en dos categoras" modelado e instrumentos de capacidad de rastreo.
35
E3igencias de los instrumentos de modelado" Son usados para
la obtencin, anlisis, especificacin y valide4 de las e3igencias de software.
E3igencias de los instrumentos de capacidad de <astreo" Se
(acen cada ve4 ms importantes debido a que la comple'idad del software crece, son presentados
separadamente de los instrumentos de modelado.
1.2 5as 6erramientas de Dise7o de )oft#are
/ubre los instrumentos para crear y comprobar diseDos de software, e3iste gran variedad de estos
gracias a la diversidad en las notaciones de diseDo de software y m!todos, a pesar de esta variedad
no se (a encontrado una divisin convincente.
1.3 5as 6erramientas de Construcci"n de )oft#are
Son instrumentos usados para producir y traducir la representacin de programa mquina, se utili4an
los redactores de programa, compiladores y generadores de cdigo, int!rpretes y depuradores.
1.4 6erramientas de *rue,as de )oft#are
Se incluyen" .eneradores de 1ruebas, marcos de e'ecucin de pruebas, (erramientas de evaluacin
de pruebas, (erramientas de direccin de pruebas y de anlisis y de funcionamiento, todas estas
estn enfocadas a la prueba del software construido as como de su funcionalidad, versatilidad y
calidad.
1. 6erramientas de Mantenimiento de )oft#are
7barca los instrumentos utili4ados para el mantenimiento de software, dos categoras son
identificadas" instrumentos de comprensin y instrumentos de reingeniera.
Rerramientas de comprensin" 7yudan a la comprensin (umana de programas, se incluyen
instrumentos como animadores o rebanadores.
Rerramientas de reingeniera" Es definido como el e3amen y la alteracin del software sustancial
para reconstruirlo de una nueva forma.
1.0 5as 8erramientas de direcci"n de configuraci"n de )oft#are
Ran sido dividas en tres categoras" rastreo, direccin de versin e instrumentos de liberacin.
<astreo" Son elementos utili4ados en la cone3in con las
cuestiones que rastrean problemas asociados con un producto de software particular.
Rerramientas de direccin de versin" Estn implicados en la
direccin de m8ltiples versiones de un producto.
Rerramientas de liberacin y construccin" Son usados para las
tareas de liberacin y construccin de un software incluye instrumentos de instalacin que son
e3tensamente utili4ados para configurar la instalacin de un producto software.
36
1.1 6erramientas de direcci"n en la &ngeniera de )oft#are
Esta subdivido en tres categoras" planificacin de proyecto y rastreo, mane'o arriesgado, y medida.
En la primera se busca una medida de esfuer4o en el proyecto y cuenta la valoracin as como la
planificacin del proyecto, en la segunda se identifican la estimacin y riesgos de supervisin,
finalmente en la medida se asiste la reali4acin de actividades relacionadas con el programa de
medida de software.
1.9 5as 6erramientas de $roceso de ingeniera de )oft#are
Est divida en instrumentos que modelan, instrumentos de direccin y ambientes de desarrollo de
software.
1.: 5as 8erramientas de Calidad de )oft#are
2ividas en dos categoras" inspeccin e instrumentos de anlisis.
En las (erramientas de revisin de auditoria se apoyan en revisin y revisiones de cuenta y en las de
anlisis estticos se anali4an artefactos de software como anali4adores sintcticos y semnticos as
como datos, el flu'o de control y anali4adores de dependencia.
1.1; Cuestiones de &nstrumento Com$uestas
/ubre el tema aplicable a todas las clases de instrumentos, tres categoras identificadas"
t!cnicas de integracin de instrumentos, metaFinstrumentos, y evaluacin de instrumento.
2. L&' M5%&!&' !$ ," I2$)$*-" !$, S&0%1"*$
Esta divido en tres temas" ?!todos (eursticos que tratan con accesos matemticamente basados, y
m!todos de prototipa4o que tratan con software que trama accesos basados en varias formas de
prototipa4o, cada tema trata sus preocupaciones distintas no quiere decir que no tengan que ver el
uno con el otro.
2.1 M4todos 6eursticos
Este tema contiene cuatro categoras" estructurado, orientado a datos, orientado a ob'etos, y
especfico de dominio.
La 8ltima incluye m!todos especiali4ados para desarrollar los sistemas que implican en tiempo real
aspectos relacionados con la seguridad.
En el m!todo estructurado se ve desde un punto de vista funcional para refinarlo y (acerlo cada ve4
ms detallado.
En el orientado a datos se estructura el programa y se manipula.
En el orientado a ob'etos el sistema es visto como una coleccin de ob'etos ms que de funciones.
2.2 M4todos <ormales
37
7qu se describe como el software se basa en m!todos de ingeniera basado matemticamente y se
subdivide seg8n varios aspectos de m!todos formales entre ellos"
E'.$+)0)+"+)7 !$, ,$2u"3$ / &%"+)&$'A 7qu se especifica la lengua usada y se clasifica seg8n
la orientacin del modelo las caractersticas o el comportamiento.
R$0)"#)$%&A 7qu se trata como de refinar o transformar las especificaciones en una forma ms
cercana a la deseable en un programa finalmente e'ecutable.
P*&.)$!"!$' !$ V$*)0)+"+)7GC&0)*#"+)7A 7qu se incluyen confirmaciones de teorema y la
comprobacin del modelo.
2.3 M4todos de *rototi$ado
/ubre m!todos que implican el prototipa4o de software y es subdivida en estilos de prototipa4o,
ob'etivos y t!cnicas de evaluacin.
Se deben incluir aspectos como" Estilos de prototipa4o, ob'etivos del prototipa4o, y las t!cnicas para
la evaluacin del prototipo propuesto.
38
CAPITULO 11
CALIDAD DEL SOFTWARE
S1orque es tan importante la calidad del software que est en todos los aspectos de la gua
S)E*+,T
?uc(os autores le (an dado varias definiciones a este t!rmino pero citar! la que le da la IS+ B@@#F
@@ la cul la define como 9el grado en el que un con'unto de caractersticas in(erentes cumple
requisitos:.
En este captulo se abordan los aspectos relativos a la calidad del software los cuales trascienden en
cualquier ciclo de vida, en esta gua se describen un con'unto de m!todos para alcan4ar la calidad,
en este caso se trataran las t!cnicas estticas es decir aquellas que no requieren la e'ecucin del
software para su evaluacin mientras las dinmicas cubren los aspectos de calidad en las pruebas
del software.
1. Fu!"#$%&' !$ C",)!"! !$, S&0%1"*$
7qu se definen formalmente los aspectos a tratar y la manera como un ingeniero de software
debera entender y adoptar los conceptos y caractersticas de calidad y su relevancia en el desarrollo
o mantenimiento de software.
Los aspectos de calidad deben estar in(erentes desde el momento mismo de los requerimientos as
como la medicin y criterios de aceptacin que eval8an estas caractersticas.
1.1 Modelos y Caractersticas de Calidad
La terminologa usada en las caractersticas difiere de una ta3onoma a otra ya que cada una posee
niveles 'errquicos diferentes, la IS+ (a definido tres modelos relacionados con la calidad en un
producto de software -la calidad interna, la calidad e3terna y la calidad en el empleo0.
1.2 Me3ora de Calidad
La tarea de la calidad puede ser me'orada cada ve4 ms gracias a un proceso iterativo de me'ora
continua que requiere control de direccin, control y retroalimentacin de muc(os procesos
39
simultneos" -#0 los procesos de ciclo de vida del software, -%0 el proceso de deteccin de
errorOdefecto, retirada de los mismos y prevencin y -&0 el proceso de me'ora de calidad, estos
procesos (an sido probados y certificados por e3pertos en calidad que afirman que la calidad de un
producto est directamente relacionada con la calidad del proceso empleado para crearlo.
E3isten varios instrumentos que nos permiten conocer los ob'etivos de la calidad como por e'emplo
el Lotal $uality ?anagement -L$?0, process of plan, 2o, /(ecK and 7ct -12/70 con estos podemos
identificar fallas, desarrollar acciones detalladas y gestionar el apoyo a la gerencia y a los recursos
asignados para el proyecto para traba'ar la calidad en la ingeniera del software.
2. P*&+$'&' !$ G$'%)7 !$ C",)!"! !$, S&0%1"*$
La gestin de calidad del software -S$?0 es de gran importancia y aplicacin a todas las
perspectivas de procesos de software, productos y recursos, estos consisten en numerosas
actividades, algunos de ellos pueden encontrar errores diariamente mientras que otros pueden
resultar mas bien en valiosas revisiones.
El S$? puede ser utili4ado para evaluar productos intermedios as como el producto final.
7lgunos de los procesos especficos estn definidos por la IEEE"
1rocesos de aseguramiento de calidad
1rocesos de >erificacin
1rocesos de >alidacin
1rocesos de <evisin
1rocesos de 7uditora
Estos procesos incentivan la calidad y tambi!n permiten encontrar posibles problemas.
Lodos los procesos S$? estn enfocados a cumplir tareas y t!cnicas para asegurar una calidad de
software ptima en un proyecto dado, estos procesos estn estrec(amente relacionados, pueden
solaparse y (asta en ocasiones estar combinados.
Lambi!n es importante tener en cuenta la gestin de riesgo ya que est 'uega un papel importante
en la entrega de software de calidad.
R$;)')&$' !$ G$'%)7A El ob'etivo es supervisar el progreso, determinando el estado de los planes
y programas, requerimientos confirmados y su sistema de locali4acin o evaluar la efectividad de los
enfoques de gestin empleados. /on esto se determina la idoneidad de los proyectos, programas y
requerimientos y supervisan su progreso o inconsistencias.
40
R$;)')&$' T5+)+"'A El propsito es evaluar el producto software para determinar si es idneo
para su correspondiente uso, deben establecerse los roles especficos, una revisin t!cnica requiere
que las entradas obligatorias est!n en su lugar con el ob'eto de proceder a" e3posicin de ob'etivos,
un producto software especfico, el plan especfico de gestin del proyecto, la lista de cuestiones
claves asociadas al producto y el procedimiento de revisin t!cnica.
I'.$++)&$'A 2etecta e identifica anomalas en los productos de software, e3isten dos importantes
elementos diferenciadores entre inspeccin y revisin y son los siguientes" un individuo que
mantiene una posicin de direccin sobre cualquier miembro del equipo de inspeccinE la inspeccin
(a de ser llevada por un inspector con formacin en inspecciones t!cnicas.
Las inspecciones por lo general requieren el autor de un producto intermedio y tambi!n a un lder de
inspeccin, generalmente son (ec(as sobre una pequeDa seccin del producto a la ve4, las
anomalas encontradas deben ser documentadas y enviadas al responsable de la inspeccin,
tambi!n es recomendable mane'ar listas de c(equeo durante la inspeccin de esta manera se
clasifican las anomalas y se determinan su e3actitud e integridad.
W",HI%>*&u2>'A El ob'etivo es evaluar el producto software, los ob'etivos principales son" Encontrar
anomalas, me'orar el producto software, considerar implementaciones alternativas, evaluar la
conformidad con estndares y especificaciones.
Es similar a una inspeccin pero su desarrollo por lo general es menos formal, generalmente es
desarrollado por el ingeniero de software para darle una oportunidad a su equipo de repasar el
traba'o como una t!cnica de aseguramiento.
Au!)%&*-"'A El ob'etivo es reali4ar una evaluacin independiente de la conformidad de productos de
software y procesos a regulaciones aplicables, estndares, directrices, planes y procedimientos, est
formalmente organi4ada con participantes que cumplen roles especficos contando con un
representante de la organi4acin auditada.
1uede reali4arse sobre casi cualquier proceso o producto en cualquier etapa de mantenimiento o
desarrollo.
4. C&')!$*"+)&$' P*6+%)+"'A
3.1 %e2uerimientos de calidad del soft#are:
7qu influyen varios factores como la planificacin la gestin y seleccin de actividades S$? y
t!cnicas incluyendo" 2onde residir el software , requerimientos del sistema y del software, los
componentes comerciales, estndares , m!todos y (erramientas de software, el presupuesto y los
usuarios implicados como tambi!n el nivel de integridad del sistema.
41
Las t!cnicas dinmicas son e'ecutadas durante todo el desarrollo y el mantenimiento de software,
generalmente son t!cnicas de testeo o simulacin.
Las pruebas e3aminan todos los output de la especificacin de requerimientos de software con el
ob'eto de asegurar su tra4abilidad, consistencia, completitud, correccin y e'ecucin.
E3isten muc(os tipos de pruebas entre ellos la de terceros ya que es la de un facilitador
independiente por lo general acreditado por alguna autoridad su ob'etivo es probar el producto
respecto a su conformidad con un con'unto de e3igencias.

CAPITULO 12
DISCIPLINAS RELACIONADAS CON LA INGENIERIA DEL SOFTWARE
42
Este captulo se centra en relacionar cada una de las disciplinas de la figura # con la Ingeniera del
Software. Es especfico en lo que respecta a determinar las temticas de cada una de ellas con
respecto a otras.