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

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.
Una profesin para ser reconocida como tal debe cumplir con un cuerpo de conocimiento basado en
tres aspectos, desde el punto de vista acadmico, moral y cognitivo:
1. Que el conocimiento y las competencias de la profesin, sean validadas por profesionales
de la misma rea.
2. Que el conocimiento sea validado desde la base racional y con fundamento cientfico
3. Que el juicio del profesional se enfoque hacia 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 SWEBOK (Gua de la Ingeniera del Software Cuerpo de Conocimiento) es describir que
parte de ste es aceptado de manera general y se estableci con el fin de cumplir cinco objetivos:
1. Promover una vista general y consistente de la ingeniera del software a nivel mundial.
2. Dar claridad del contexto 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.
3. Caracterizar los contenidos de esta disciplina.
4. Proveer acceso temtico al cuerpo de conocimiento de la ingeniera del software.
5. Proveer la fundacin de un ente para apoyar el desarrollo, certificacin y licenciamiento de
material de calidad, relacionado con la disciplina.
Est estructurada en 12 captulos completamente divididos en subcaptulos, que explican todos los
componentes del cuerpo de conocimiento de la ingeniera del software, basados en reas del
conocimiento, esquematizadas en los siguientes grficos:

CAPITULO 2
REQUERIMIENTOS DE SOFTWARE
El rea del conocimiento de los requisitos de software (KA), se refiere al anlisis, especificacin y
validacin de los requisitos de software. Se ha demostrado ampliamente que el hecho de no realizar
bien este proceso trae consecuencias fatales en el desarrollo de cualquier producto de software.
1. Fundamentos
Un requisito de software es una caracterstica que se debe exhibir para solucionar un cierto
problema en el mundo real. Se convierte en una combinacin compleja de requisitos entregados por
parte de los usuarios implicados dentro del desarrollo de la solucin, teniendo en cuenta que pueden
corresponder a diferentes niveles jerrquicos, ambientes e intereses. Es importante tambin que
cada requisito sea comprobable, pensando tambin en las implicaciones que esto puede conllevar.
Se pueden clasificar de la siguiente manera:
Requisitos de Producto
Se refiere a generar los parmetros del problema a solucionar para ser traducido a un software.
Requisitos de Proceso
Se refiere ya a la parte tcnica y a lo que voy a utilizar para realizar el software (lenguaje de
programacin, por ejemplo).
Requisitos Funcionales
Son las capacidades o funciones del software.
Requisitos No Funcionales
Son los que actan para obligar a llegar a la solucin pero no son parte integral del software.
Caractersticas Inesperadas
Son requisitos que se toman pero no pueden comprobarse hasta que est funcionando el software
en condiciones reales.
Requisitos del Sistema y de Software

Se refiere a todo lo que necesita el software para funcionar desde el punto de vista de hardware,
software, recurso humano, informacin, instalaciones, servicios, etc. Los requisitos de software se
derivan de los del sistema.
2. Proceso de los requisitos
Inicia de manera aislada y se va refinando con el modelo de ciclo de vida del software y necesita ser
adaptado a la organizacin y al contexto del proyecto.
Agentes de Proceso
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. Pueden ser
usuarios, clientes, analistas de mercado, reguladores, ingenieros de software, etc.
Ayuda y Gerencia de Proceso
Se refiere a toda la parte presupuestal y de gerencia para llevar a cabo el proyecto.
Calidad y Mejora de Proceso
Se refiere al coste generado por control de calidad y a los niveles de cumplimiento para lograr el
objetivo principal y por ende, la satisfaccin del cliente.
3. Captura de los Requisitos
Se refiere al cmo 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.
Fuentes de los Requisitos
Deben ser confiables y sometidas a verificacin para confirmar que la persona que suministra la
informacin es idnea para hacerlo y que se tom el tiempo para analizar su conveniencia. No solo
por idoneidad sino porque en ocasiones los usuarios no son buenos escribiendo y no son claros a la
hora de hacer una solicitud.
Tcnicas de Captura de Requisitos
A menudo, el ingeniero de software utiliza tcnicas de captura de requisitos, tales como:

Entrevistas
Prototipos

Reuniones
Observacin

4. Anlisis de Requisitos
Es una auditora a todo lo que se recopil. De aqu salen los requisitos del sistema y por ende los
de software. Permite establecer limitaciones y viabilidad del proyecto.
Clasificacin de los requisitos
Pueden clasificarse en:

Funcionales o no funcionales
De producto o de proceso
Derivado
Prioritario
Estable o Voltil

Modelo Conceptual
Se debe elegir un modelo conceptual que ayude a entender de una mejor manera el problema. Es
una habilidad con la que debe contar el ingeniero de software, apoyado en herramientas que le
ayuden a contextualizar el software, como el caso de UML o el uso de la matemtica discreta. La
IEEE tiene tres estndares para el modelado. Estos son:
IEEE Std 1320.1 (conceptual)
IDEF0 (funcional)
IEE Std 1320.2, IDEF1X97 (de informacin)
Asignacin Arquitectnica del Diseo y los Requisitos
Es la fusin de toda la parte de requisitos con la parte de diseo. Es inseparable esta combinacin;
una es parte integral de la otra y es fcil su comprensin, apoyndose en el modelo conceptual. El
estndar IEEE Std 1471-2000 puede servir de apoyo en esta prctica.
Negociacin de los requisitos

Se llega a esta etapa cuando hay 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.
5. Especificacin de Requisitos
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 hagan tres documentos:

Definicin del sistema o documento de exigencias

Requisitos de sistema
Requisitos de software

Es importante esta parte porque sin aprobar alguno o todos los documentos, es imposible pasar a la
etapa de diseo.
El estndar IEEE Std 830 [IEEE830-98], apoya este proceso de especificacin de requisitos.
6. Validacin de los Requisitos
Su objetivo es determinar que los documentos realizados sean comprensibles y de acuerdo a los
estndares determinados. Por esto, deben someterse a una auditora final realizada por todo el
personal implicado en el desarrollo del software (cliente), para asegurarse de que lo plasmado all es
lo que se solicit.
Revisiones de los requisitos
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 1028 proporciona ayuda valiosa en la tarea de
revisin.
Prototipado
Es un medio que utiliza el ingeniero de software para manifestar lo que entendi y para facilitar la
correccin, eliminacin o adicin de requisitos. Como se evidencia, la ventaja de hacerlo es grande
pero el costo puede ser alto.
Pruebas de Aceptacin
Son aquellas que se le aplican a cada requisito para determinar si el producto final lo satisface o no.
Debe haber total planeacin para aplicar estas pruebas y hacerlo de manera cuantitativa.

Como 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 3
DISEO DE SOFTWARE
Es definido por la IEEE como el proceso para definir la arquitectura, los componentes, las interfaces
y otras caractersticas de un sistema. Visto como proceso, el diseo del software es la actividad del
ciclo de vida en la cual se analizan los requisitos del software para producir una descripcin de su
estructura interna que servir como base para su construccin.
1. Fundamentos
Proceso de diseo de software
Se divide en dos etapas:

Diseo Arquitectnico

Descompone el software en componentes y describe sus partes a nivel general, de estructura.

Diseo Detallado

Describe el comportamiento especfico de estos componentes.

Existen tcnicas permisibles que permiten hacer un acercamiento al diseo de software. Estas son
algunas:

Abstraccin

Es el proceso de olvidarse de la informacin para poder tratar las cosas que son diferentes como si
fueran iguales.

Acoplador y Cohesin

El acoplador es la fuerza de las relaciones entre los mdulos y la cohesin se refiere a la relacin
que existe entre estos mdulos.

Descomposicin y Modularizacin

Esta tcnica se utiliza para poner diversas funcionalidades en componentes ms pequeos.

Encapsulacin

Permite empaquetar informacin y hacerla invisible. El xito est en darle una buena funcin a esa
informacin.

11

El siguiente grfico muestra la descomposicin del proceso de diseo de software.

Separacin de la interfaz y de la puesta en prctica

Define un componente a travs de su interfaz grfica.

Desahogo

Asegura que la abstraccin se hizo de manera correcta y que slo se tom lo relevante del
componente.
2. Cuestiones claves del diseo de software
Contribuye a entender cmo dividir, organizar y constituir los paquetes de software. Se ayuda con las
siguientes llaves:
Concurrencia
Se refiere a cmo descomponer el software en procesos, tareas, hilos de reparto y que conserve la
sincronizacin en los procesos.
Distribucin de Componentes

12

Como integrar cada parte del software con el hardware necesario para su funcionamiento.
Direccin del Error y de Excepcin y Tolerancia a Fallos
Define las tcnicas para prevenir y tolerar fallos en el momento en que se presenten.

Interaccin y Presentacin
Se refiere a la forma de mostrar y organizar las interacciones con los usuarios y la forma de
documentarlas.
3. Estructura y Arquitectura de Software
Es una descripcin de los subsistemas y de los componentes de un sistema de software y de las
relaciones entre ellos.
4. Anlisis y Evaluacin de la Calidad del Diseo de Software
Esta parte es importante porque asegura la calidad del proceso de diseo. Se utilizan mtricas que
permiten estimar de manera cuantitativa varios aspectos del tamao, estructura o de la misma
calidad del software. Estas pueden ser estructuradas u orientadas a objetos.
5. Notaciones del Diseo de Software
Generalmente son grficas y permiten modelar en un diagrama la propuesta de diseo. Entre ellos
estn los diagramas de clases y objetos, de componentes, de despliegue, de entidad-relacin, de
estructura de Jackson, de estructura de cartas y diferentes lenguajes que permiten describir la
arquitectura del software y sus componentes.
Tambin existe la notacin para las descripciones de comportamiento dinmico del software, en las
cuales tambin se usan diagramas y lenguajes textuales. 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, lenguajes de diseo en pseudocdigo, etc.
6. Estrategias y Mtodos del Diseo de Software
Permiten dirigir el proceso de diseo. La estrategia est en trminos generales y los mtodos deben
ser especficos. Aqu se inicia la aplicacin del paradigma Divide y Vencers y el proceso de
refinamiento. Se define tambin si se va a utilizar el diseo estructurado u orientado a objetos o
basado en componentes.

13

CAPITULO 4
CONSTRUCCION DEL SOFTWARE
Este captulo 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.
En sntesis, esta es la etapa de creacin del cdigo fuente que tendr el software.
1. Fundamentos
La construccin del software tiene como objetivos los siguientes:
Minimizar la complejidad
Anticiparse a los cambios
Construir para verificar
Aplicacin de estndares en la construccin
La descomposicin de los temas de Construccin del Software se detallan en el siguiente grfico:

14

2. Gestin de la Construccin
Modelos de Construccin
Los ms conocidos y utilizados son los modelos de ciclo de vida en cascada y de entrega por
etapas. Estos modelos son robustos pero solo son eficientes si se ha hecho un buen trabajo en la
etapa de requisitos y de diseo. Por el contrario, los modelos prototipado evolucionista,
programacin extrema y Scrum, son ms flexibles en este tema, dado que son iterativos y
permiten, de manera cclica, realizar cambios, al combinar las tres etapas iniciales del desarrollo de
un proyecto de software.
Planificacin de la Construccin
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 objetivo principal del
proyecto. De ah la importancia de elegir un modelo de ciclo de vida acorde a los requerimientos.
Medicin de la Construccin
Se refiere a los procedimientos utilizados para medir la eficiencia del cdigo fuente, en lo que se
refiere a extensin, cdigo reutilizado, cdigo destruido, complejidad de cdigo, estadsticas de
inspeccin de cdigo, tasas de rectificacin y correccin de errores y los horarios. Esto asegura el
control de la calidad.
3. Consideraciones Prcticas
Para solucionar un problema de la vida real a travs de un software, es totalmente necesario utilizar
un lenguaje de programacin. Aqu radica el xito del proyecto de software, dado que es el
ingeniero de software el encargado de aprobar el lenguaje a travs de los argumentos dados por los
encargados de la elaboracin del cdigo fuente.
Lenguajes de Construccin
Son todos los tipos de comunicacin mediante los cuales un ser humano puede especificar una
solucin ejecutable para un problema de un ordenador. Pueden ser de configuracin, de
herramientas y de programacin. Estos ltimos, a su vez, estn divididos en lingsticos, formales y
visuales.
Pruebas de Construccin
Generalmente son realizadas por el profesional que realiz el cdigo. Pueden 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. Para tal fin, las normas estndar IEEE Std 829-1998 para
documentacin de pruebas y la IEE Std 1008-1987 para pruebas unitarias, pueden ser de gran
utilidad.

15

Reutilizacin
Definir de manera objetiva, que parte del cdigo puede ser eficientemente reutilizado para minimizar
tiempos de entrega, adems debe ser reportado a las personas que lideran el proyecto, por qu y
para que se va a reutilizar, ya que esto puede modificar el valor del proyecto, por ejemplo.
Calidad de la Construccin
Existen varias tcnicas para evaluar la calidad en la construccin del cdigo fuente de un proyecto
de software. Entre ellas tenemos:
Las pruebas unitarias y de integracin
El cdigo paso a paso
Utilizacin de aserciones
Depuracin
Revisiones tcnicas
Anlisis esttico
Integracin
Una parte clave del proceso de construccin es la integracin de las clases, componentes, rutinas,
subsistemas que han sido construidos por separado, sobre todo si hay implicaciones tcnicas de
software o hardware.

16

CAPITULO 5
PRUEBAS DEL SOFTWARE
Es una actividad que permite evaluar y mejorar 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
travs de un grupo finito de casos de prueba, debidamente seleccionados. Se ha ido cambiando la
percepcin de que las pruebas de software se realizan nicamente al final del proceso de creacin
de cdigo fuente, siendo muy til hacerlo en todas las etapas del desarrollo del software; 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 6
MANTENIMIENTO DE SOFTWARE

INTRODUCCION
El proceso de desarrollo de software debe satisfacer los requerimientos planteados, una vez en
operacin el proceso de cubrimiento de defectos, operacin y cambio de ambiente debe darse en
esta etapa, la fase de mantenimiento empieza con un periodo de garanta y de soporte postimplementacin pero el mantenimiento del software ocurre mucho antes.
Aunque la etapa de mantenimiento del software no ha tenido el grado de atencin que se debe este
tipo de desarrollo de software ya esta empezando a cambiar ya que muchos errores graves han
ocurrido por no prestarle la atencin que se merece.
El mantenimiento de software se ha definido como el nmero total de actividades requeridas para
proveer soporte efectivo al software, esto incluye un planeamiento efectivo antes. Durante y despus
de la implementacin del software.
1. Aspectos Fundamentales en el mantenimiento del software:
Aqu se introduce a los aspectos fundamentales del mantenimiento del software:
1.1 Definiciones y terminologa:
Est definido en el estndar de la IEEE 1219 como la modificacin del producto de software
despus de la entrega para corregir las faltas, tambin se encarga de direccionar las actividades
de mantenimiento para darle prioridad a la entrega del producto.
El estndar IEEE/EIA 12207 define el mantenimiento como uno de los procesos principales en el
ciclo de vida del software, el objetivo es modificar el software existente preservando su
integridad tambin lo hacen en estos mismos trminos la ISO/IEC 14764 este enfatiza 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 IEEE/EIA 12207 como las actividades de mantenimiento que permiten el
desempeo correcto.
Identifica las actividades de mantenimiento como un proceso de implementacin y modificacin
y anlisis del problema, estas actividades son discutidas en el tpico 3.2 Actividades de
Mantenimiento.

Figura 1. Tpicos a tener en cuenta en el mantenimiento del software

1.3 Necesidad de mantenimiento:
La necesidad de mantenimiento se da para garantizar que el software cumple satisfactoriamente
con los requerimientos solicitados, este se aplica a cualquier desarrollo independiente del
modelo de ciclo de vida utilizado, el mantenimiento se da en orden de alcanzar el desempeo
adecuado y en el orden de:

19

Corregir fallas.
Improvisar el diseo.
Implementar correcciones.
Interfaces con otros sistemas.
Adaptar programas a diferentes tipos de hardware, software, configuracin del sistema y
facilidad de uso de telecomunicaciones.
Migracin legal de software.
Retiro 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 han demostrado que ms del 80% del mantenimiento de software
es usado para acciones correctivas hay 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 dichos costos, a continuacin se presentan
algunos aspectos tcnicos y no tcnicos que afectan los costos de mantenimiento:
Tipo de Aplicacin.
Disponibilidad del mantenimiento de software.
Ciclo de vida del software.
Caractersticas de hardware.
Calidad del diseo de software, construccin, documentacin y pruebas.
1.5 Evolucin del software:
En 1969 Lehman direcciono el mantenimiento del software y la evolucin de los sistemas,
durante 20 aos se mantuvo su idea de la formulacin de ocho Leyes de la evolucin donde
se mantuvo la idea de la evolucin en el mantenimiento del software para continuar con el
desarrollo.
Lientz y Swanson inicializaron la definicin de tres categoras de mantenimiento: correctivo,
adaptativo y perfectivo.

2. Factores claves en el mantenimiento del software:

Un 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 tcnica nica en los desafos de administracin para los ingenieros de

20

software, podemos apreciar como se planean las liberaciones posteriores as como los parches
generados para las versiones anteriores, lo que sigue a continuacin nos presenta una manera
de cmo se nos presentan algunos factores de administracin y tcnicos para el mantenimiento
de software, estos se agrupan segn los tpicos siguientes:

Factores tcnicos.
Factores administrativos.
Estimacin de costos.
Medidas.

3. Proceso de mantenimiento:
Provee referencias y estndares utilizados 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.

Figura 2. Actividades en el proceso del mantenimiento

En la figura planteada por la ISO/IEC se puede apreciar que es muy parecida a la anterior
que es IEEE pero en esta se agrega una pequea diferencia:

21

Cada actividad de mantenimiento primario de software ISO/IEC 14764 es desglosada en

los siguientes trminos:
Proceso de implementacin.
Anlisis del problema y modificaciones.
Implementacin y modificacin.
Mantenimiento Aceptacin/Revisin.
Migracin.
Retiro de Software.

Tcnicas para el mantenimiento:

Esta subrea nos introduce a algunas generalidades aceptadas por las tcnicas del
mantenimiento de software:
3.1 Comprensin del programa
Los programadores gastan tiempo considerable leyendo y entendiendo programas para
poder implementar cambios existen distintas herramientas que nos ayudan con este
proceso.
3.2 Reingeniera
Esta definida como el examen de de la alteracin del software para reconstituir una nueva
forma, la reingeniera es la mas radical y expansiva 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 tcnicas, casos de estudio y sus riesgos y
beneficios.
3.3 Ingeniera inversa
Es el proceso de analizar el software para identificar los componentes y sus relaciones para
crear representaciones del software dicho de otra forma desde un nivel mas alto de
abstraccin, es pasiva, y no hace cambios al software o resulta en otro software. Produce
grficas asi como control de flujo y del cdigo fuente, un tipo de reingeniera puede ser la
redocumentacin, otro tipo es la reparacin del diseo.
Finalmente la reingeniera ha sido de gran importancia en los ltimos aos ya que gracias a
sus esquemas lgicos a podido restaurar bases de datos fsicas.
CAPITULO 7
ADMINISTRACION DE LA CONFIGURACION DEL SOFTWARE

22

Un sistema puede ser definido como un conjunto de componentes organizados con el propsito de
cumplir una funcin o conjunto de funciones especficas.
En este sentido la configuracin de un software y sus caractersticas funcionales de hardware,
software, firmware o la combinacin de estas son un conjunto de caractersticas tcnicas que se
deben cumplir para garantizar 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 IEEE610.12-90 como Disciplina aplicada de manera
tcnica 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. Administracin de los procesos SCM

La SCM administra y controla la evolucin e integridad del software as como su verificacin,
control, reportes y configuracin de la informacin. Una implementacin exitosa del SCM
requiere un cuidado especial y planeacin y administracin.
1.1 Contexto Organizacional del SCM

23

Para desarrollar un plan SCM es necesario conocer detalladamente los procesos de la

organizacin ya que el SCM interacta directamente con todos los elementos y actividades
organizacionales.
1.2 Constantes y gua para el proceso SCM
Esto proviene de un gran numero de fuentes tiene que ver con las polticas de la
organizacin y su influencia en la administracin de los procesos.
1.3 Planeacin del SCM
El proceso de planeacin debe ser consistente con el contexto organizacional, y la
naturaleza del proyecto (por ejemplo el tamao y su crtica) las actividades ms importantes
en este contexto son: control de configuracin, control de estado, control de auditora,
control de liberaciones y entregas as como las herramientas de configuracin y control y
sus interfaces consideradas.
1.4 Plan de la SCM
Los resultados de planeacin del proyecto son guardados en un plan de gestin y
configuracin del software, el documento se mantiene y se actualiza o aprueba segn sea
necesario a lo largo del ciclo de vida del software.
Tambin es muy til hacer mediciones constantes a los procesos para hacer los cambios y/o
actualizaciones correspondientes.
1.5 Seguimiento de la gestin de la configuracin del software
Despus del cumplimiento del proceso de la SCM puede ser necesario un cierto nivel de
seguimiento para asegurarse que los procesos SCM se llevan a cabo adecuadamente, este
seguimiento puede hacer parte de un proceso de auditora para garantizar la calidad del
software.
El uso de herramientas integradas en la SCM facilita el proceso de seguimiento.
1.5.1

Medidas y mediciones de la SCM

Proporcionan un buen medio para monitorizar la efectividad de las actividades SCM de
una manera continuada, son tiles para caracterizar el estado actual del proceso y para
proporcionar una base para hacer comparaciones con el tiempo.
Las bibliotecas de software y las diferentes herramientas proporcionan fuentes para
extraer la informacin acerca de las caractersticas de los procesos SCM.

2. Identificacin de la configuracin del software

24

Identifica los elementos a ser controlados, establece e identifica esquemas y sus versiones,
establece herramientas y tcnicas utilizadas para administrar y controlar dichos elementos.
2.1 Identificar elementos a ser controlados
Un primer paso sera identificar cambios en los elementos de software que sern
controlados para entender la configuracin del software en el contexto del sistema.
2.2 Biblioteca de software
Coleccin controlada de software as como de sus documentos relacionados y est
relacionada para ayudar en el desarrollo de software, ah diferentes tipos y nos pueden
ayudar en diferentes etapas, son tambin una fuente importante de informacin para
mediciones del trabajo realizado y del progreso.

3. Control de la configuracin del software

Le concierne la gestin de cambios durante el ciclo de vida, cubre los procesos que
determinan los cambios a realizar, la autoridad para hacerlos y el soporte para la
implementacin de dichos cambios.
La informacin derivada de estas actividades es til para medir el trfico de cambios y
ruptura de aspectos por rehacer.
3.1 Peticin, evaluacin y aprobacin de cambios del software
El primer paso es determinar los cambios a realizar, se evala el coste e impacto del cambio
propuesto se acepta o rechaza dicho cambio, este se origina en cualquier momento del ciclo
de vida y puede incluir una solucin propuesta y una prioridad.
3.2 Implementando cambios en el software
Se implementan utilizando los procesos de software definidos de acuerdo con los
requerimientos de planificacin aplicables.
Podran sufrir auditoras de configuracin y verificacin de la calidad del software. Esta
soportada por las herramientas de la biblioteca que proporcionan gestin de versiones y
soporte para el almacenamiento de cdigo.
3.3 Desviaciones y Remisiones
Las limitaciones que se imponen al esfuerzo de la ingeniera del software podran contener
necesidades que no pueden ser satisfechas en el punto designado del ciclo de vida. Una

25

remisin es una autorizacin para abandonar una necesidad antes del desarrollo del
elemento.
4. Registro del estado de la configuracin del Software
La contabilidad del estado de la configuracin del software (SCSA) es la actividad de
registrar y proporcionar la informacin necesaria para una gestin efectiva de la
configuracin del software.
4.1 Informacin del estado de la configuracin del software
Genera un conjunto de informes durante el ciclo de vida, se encarga de recoger y mantener
la informacin del estado de la configuracin que se ha de gestionar segn las
configuraciones evolucionan.
Es necesario algn tipo de soporte de herramientas automticas para llevar a cabo las
tareas de recogida de datos y generacin de informes de la SCSA.
4.2 Reportes del estado de la configuracin del software
Los reportes pueden ser usados para los elementos del proyecto de la organizacin,
incluyendo el equipo de desarrollo, administracin de proyectos y actividades de calidad del
software.
Tambin sirve para responder algunas preguntas especficas de la etapa de produccin.
5. Auditora de la configuracin de software
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.
Deben ser cuidadosamente planeadas, existen herramientas que apoyan la planeacin y
conduccin de las auditoras para facilitar su proceso.
Determina la extensibilidad 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.
5.1 Auditoria funcional de la configuracin del software
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.
5.2 Auditora de la configuracin fsica del software
El propsito es asegurar que el diseo y la documentacin de referencia es consistente con
la construccin del producto de software.

26

5.3 Auditora durante el proceso de una lnea base de software

Como 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 desempeo que sea consistente con las
especificaciones.

6. Administracin de las entregas y liberaciones de software

El trmino liberacin es usado en este contexto 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
actualizacin.

CAPITULO 8
GESTION DE LA INGENIERIA DEL SOFTWARE
Puede ser definida como las actividades de gestin de la aplicacin, planeacin, coordinacin,
medicin, monitorizacin, 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: Gestin y organizacin de la infraestructura, gestin
de proyectos, y control y planeacin del programa de medidas.
Los aspectos de la gestin de la organizacin son importantes en trminos 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.
Un nmero de polticas especficas deben ser establecidos para una efectiva gestin en la ingeniera
del software y el nivel organizacional.
Haciendo 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.
Una gestin eficaz requiere la combinacin tanto de nmeros como de experiencia.

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. Iniciacin y Alcance
Se centra en la determinacin eficaz de los requisitos del software por medio de varios mtodos de
induccin y la valoracin de la viabilidad del proyecto desde distintos puntos de vista, una vez
establecida la viabilidad, la tarea pendiente es la especificacin de la validacin de requisitos y del
cambio de procedimientos.

28

2. Planificacin de un Proyecto de Software

Esta regulado por los alcances y los requisitos y por la viabilidad del proyecto, se evalan los
procesos de ciclo de vida y se selecciona el ms apropiado.
Se debe realizar una descomposicin jerrquica de tareas, y la realizacin de un calendario y una
estimacin de costos.
Ms adelante se le da un presupuesto a las tareas y la imposicin de horarios 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 Planificacin de un Proceso
La seleccin de un modelo de ciclo de vida o la adaptacin de un despliegue de ciclos se emprenden
a la luz del alcance particular y de los requisitos del proyecto.
Tambin se seleccionan mtodos y herramientas pertinentes.
2.2 Determinar los entregables
Se especifica y caracteriza los productos de cada tarea, se evala la posibilidad de reutilizar
componentes de desarrollos anteriores y se planifica la utilizacin de terceras personas y del
software obtenido y se seleccionan los proveedores.
2.3 Esfuerzo, calendario y clculo del coste
Se determina el rango de esfuerzo esperado, utilizando un modelo de estimacin calibrado, basado
en datos histricos sobre el esfuerzo empleado.
Cuando sea posible se solucionan cuellos de botella, y se elabora el esperado cuadro de tareas con
los horarios de inicio, duraciones y horarios de finalizacin bien planificados.
Los requisitos de recursos (personas, herramientas) se traducen en estimaciones de costo.
2.4 Reparto 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 bajo estas circunstancias.
2.5 Gestin de Riesgos
Se completa el anlisis de riesgos, la valoracin crtica de riesgos, la mitigacin de riesgos y la
planificacin de contingencias.
Los mtodos para la valoracin del riesgo deben utilizarse para resaltar y evaluar riesgos, en esta
etapa se deben evaluar las posibilidades de abandono del proyecto en conversaciones con todos los
contratistas.
2.6 Gestin de calidad

29

Se define en trminos de atributos pertinentes del proyecto y en los de cualquier producto asociado
a l, tanto en trminos cualitativos como cuantitativos.
Los lmites de adhesin de calidad se colocan de acuerdo a las expectativas que tenga el contratista
sobre el software en cuestin as como los procedimientos de verificacin y validacin del producto
entregable.
2.7 Gestin de planes
Los informes, la supervisin y el control del proyecto deben encajar en el proyecto de ingeniera del
software seleccionado y en las realidades del proyecto y deben reflejarse los artefactos que lo
gestionarn.
Los cambios a otros procesos de soporte ejemplo: gestin documental, resolucin de problemas
tambin deben gestionarse de la misma manera.
3. Promulgacin del proyecto de Software
Se ejecutan los planes y se divulgan los procesos incluidos en los planes, en este proceso hay total
expectativa de la adhesin plena de los requisitos del contratista y el logro de los objetivos del
proyecto, son actividades fundamentales para la promulgacin la gestin, medicin, supervisin,
control e informacin del proyecto.
4. Revisin y Evaluacin
Se evala el proceso global hacia el logro de los objetivos y satisfaccin de los requisitos del
contratista y se llevan a cabo valoraciones sobre la efectividad del proceso global hasta la fecha, del
personal involucrado y de las herramientas y mtodos utilizados.
4.1 Determinar la satisfaccin de los requisitos
Determinar que el objetivo principal se est cumpliendo es primordial ya que lo que nos interesa es
la satisfaccin del usuario o contratista esto se debe hacer peridicamente.
Se deben identificar las variaciones a las expectativas para llevar a cabo las acciones adecuadas.
Tambin se debe gestionar el control de cambios a los procedimientos y a la configuracin del
software.
4.2 Revisar y Evaluar la Ejecucin
Las revisiones peridicas a lo realizado nos proporcionan detalles sobre la probabilidad de ser fiel a
los planes, as como las posibles reas de dificultad, aqu se evalan los diferentes mtodos,
herramientas y tcnicas empleadas para ver su eficacia y adecuacin y se evala constantemente la
eficacia de los procesos para ver su utilidad en el contexto del proyecto, cuando sea necesario se
gestionan y se llevan a cabo los cambios.

30

5. Cierre
El proyecto llega a su fin cuando todos los planes y procesos implicados se han promulgado y
completado, en esta fase se repasan ciertos criterios para el xito del proyecto.
Se han entregado los procesos tal como se haban especificado y todos los productos planificados
han sido entregados con caractersticas aceptables.
5.1 Determinar el cierre
Se logran los objetivos 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.
5.2 Actividades de cierre
Se archivan los materiales del proyecto y la base de datos de medicin de la organizacin se pone
al da con los datos finales del proyecto y se emprende el anlisis post-proyecto.
Se hace con el fin de identificar temas. Problemas y oportunidades encontrados durante el proceso,
se sacan las lecciones del proceso y luego se alimentan los conocimientos de la organizacin y los
intentos de mejora.
6. Medidas de la ingeniera del software
Aqu abordamos el tema de la medicin en la ingeniera del software y su importancia para esto se
sigue unas mtricas y normas establecidas por entidades como la ISO y la IEEE.
6.1 Establecer y sostener el compromiso de medir
Se deben tener ciertos compromisos de medicin establecidos, adems de requisitos que midan los
factores que contribuyen a un objetivo en particular para as gestionar los proyectos y hacerle frente
a este objetivo.
Se debe establecer una unidad u objetivo a medir en la organizacin, adems se debe adquirir un
compromiso que se debe comunicar y apoyar en los recursos de la organizacin.
Se deben asignar recursos para llevar a cabo el proceso de medicin adems de dar la financiacin
y herramientas adecuadas para dirigir este proceso.
6.2 Planificar el proceso de medicin
Para esto es necesario identificar la unidad funcional a la cul se le est aplicando para que sea
caracterizada y as identificar las necesidades de informacin para proceder con los objetivos
primordiales y sus respectivas prioridades.
Se deben seleccionar las mediciones a realizar adems como las muestras de informacin que
sern tomadas para su posterior anlisis, verificacin e informacin a ser dada.

31

El plan de medicin tambin debe ser revisado y aprobado por los contratistas adecuados adems
de mantener disponibles los recursos para dicho plan.
Se deben comunicar los resultados adems de documentarse publicarse.
6.3 Evaluar las mediciones
Este proceso se debe llevar a cabo con un criterio de evaluacin especfico para determinar las
fuerzas y debilidades de los productos, se puede hacer por medio de un proceso de auditora interna
o externa y debe incluir una retroalimentacin a los usuarios.
Se deben identificar las mejoras potenciales y costos y beneficios de estas, comunicarlas a la
persona encargada para su revisin y aprobacin.

CAPITULO 9
PROCESO DE INGENIERA DEL SOFTWARE
Se puede examinar en dos niveles desde lo tcnico y desde el meta-nivel o nivel de implementacin,
valoracin, medicin y gestin.
Existen varios significados sobre el proceso de la ingeniera del software puede verse como una sola
manera de realizar el proceso o como muchas maneras que es lo que se quiere y se debe llegar a

32

hacer ya que el proceso de la ingeniera abarca muchos factores, finalmente un tercer significado se
refiere al conjunto actual de actividades realizadas dentro de una organizacin que se puede ver
como un solo proceso.
Los procesos de ingeniera del software son considerados de gran importancia, el objetivo es
gestionar nuevos y mejores procesos.
1.

Proceso de implementacin y cambios

Se centra en los cambios organizacionales, describe la infraestructura, actividades, modelos y
consideraciones prcticas de un proceso de implementacin y cambios:

Tambin es denominado el proceso de evaluacin, hay que tener cuidado con las modificaciones ya
que puede que tambin sean necesarios cambios en la cultura organizacional.
1.1

Infraestructura del proceso

Es necesario que la infraestructura este en su lugar, es decir que los recursos estn al alcance de la
mano y que se hayan asignado responsabilidades, es posible que se tengan que establecer comits
para supervisar el esfuerzo del proceso de ingeniera del software.
Con un grupo de proceso de la ingeniera del software se pretende ser el foco central en el proceso
de mejoras y tiene cierto nmero de responsabiidades en la inicializacin y el mantenimiento.
El concepto de creadora de experiencias (EF) se centra en el proceso de mejoramiento de los
procesos de la ingeniera del software.

2.

Definicin de procesos
Pueden ser unos lineamientos, polticas o estndares se definen para facilitar el
entendimiento
en la comunicacin humana, apoyar y mejorar procesos , se deben considerar algunas variaciones
como la naturaleza del trabajo, el dominio de la aplicacin, el modelo de ciclo de vida y la madurez
de la organizacin.

3.

Valoracin del proceso

Se lleva a cabo utilizando un mtodo y un modelo de valoracin que en algunos casos es visto como
un modelo de apreciacin y muchas veces una evaluacin de capabilidad cuando es para la
adjudicacin de algn contrato.

3.1

Modelos de valoracin del proceso

33

Recoge lo que se conoce como las buenas prcticas en el proceso de gestin de la ingeniera del
software, la ISO define un modelo ejemplo de valoracin y de requisitos, se han desarrollado
tambin un modelo de madurez para sistemas de ingeniera que resulta til cuando un proceso est
implicado en el desarrollo y mantenimiento de un sistema incluyendo el software.
Existen 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 mejor se adapta a mis
necesidades y objetivos.
3.2

Mtodos de valoracin del proceso

Es garantizar un mtodo cuantitativo que evaluara los procesos, existen de varios tipos dnde se
valoran distintos tpicos todos pensados en las mejoras de los procesos y la eficacia en la
organizacin.

4.

Medicin de los procesos y los productos

Aunque puede resultar compleja la medicin a la ingeniera del software existen varios aspectos que
son fundamentales para la medicin y anlisis, estas mediciones se pueden realizar para apoyar los
procesos de implementacin y cambio o evaluar consecuencias de estos.

4.1

Medicin del proceso

Se recoge, analiza e interpreta informacin cuantitativa sobre el proceso, se utiliza para identificar la
fuerza y debilidad en ellos y as mismo evaluarlos despus de haber sido implementados o
cambiados.

34

La medicin de un producto software incluye principalmente, la medicin del tamao del producto, la
estructura del producto y la calidad del producto.
Tambin es importante tener en cuenta la medicin del tamao, de la estructura y de la calidad.
Para garantizar la calidad en los resultados de la medicin es necesaria la medicin efectiva de los
programas para proveer resultados exitosos.

CAPITULO 10
INSTRUMENTOS Y MTODOS DE LA INGENIERA 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 mtodos imponen la estructura a la actividad de la ingeniera del software con el objetivo de
hacerla sistemtica, por lo general proporcionan notacin y vocabulario para comprobar tanto el
proceso como el producto, aunque existen numerosos materiales sobre los instrumentos de apoyo
en la ingeniera del software, los textos sobre las tcnicas 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 mtodos cubren ciclos de vida completos por esto es tan
complicado hacer un cambio.
Estudio de las herramientas y mtodos de la ingeniera de software
1.

Las herramientas de ingeniera de Software

Ests corresponden a las cinco primeras reas de conocimiento de la gua, Exigencias de software,
diseo 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

Las Herramientas de exigencias de Software

Han sido clasificados en dos categoras: modelado e instrumentos de capacidad de rastreo.

35

Exigencias de los instrumentos de modelado: Son usados para

la obtencin, anlisis, especificacin y validez de las exigencias de software.
Exigencias de los instrumentos de capacidad de Rastreo: Se
hacen cada vez ms importantes debido a que la complejidad del software crece, son presentados
separadamente de los instrumentos de modelado.

1.2

Las Herramientas de Diseo de Software

Cubre los instrumentos para crear y comprobar diseos de software, existe gran variedad de estos
gracias a la diversidad en las notaciones de diseo de software y mtodos, a pesar de esta variedad
no se ha encontrado una divisin convincente.

1.3

Las Herramientas de Construccin de Software

Son instrumentos usados para producir y traducir la representacin de programa mquina, se utilizan
los redactores de programa, compiladores y generadores de cdigo, intrpretes y depuradores.

1.4

Herramientas de Pruebas de Software

Se incluyen: Generadores de Pruebas, marcos de ejecucin de pruebas, herramientas de evaluacin
de pruebas, herramientas 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.5

Herramientas de Mantenimiento de Software

Abarca los instrumentos utilizados para el mantenimiento de software, dos categoras son
identificadas: instrumentos de comprensin y instrumentos de reingeniera.
Herramientas de comprensin: Ayudan a la comprensin humana de programas, se incluyen
instrumentos como animadores o rebanadores.
Herramientas de reingeniera: Es definido como el examen y la alteracin del software sustancial
para reconstruirlo de una nueva forma.

1.6

Las herramientas de direccin de configuracin de Software

Han sido dividas en tres categoras: rastreo, direccin de versin e instrumentos de liberacin.
Rastreo: Son elementos utilizados en la conexin con las
cuestiones que rastrean problemas asociados con un producto de software particular.
Herramientas de direccin de versin: Estn implicados en la
direccin de mltiples versiones de un producto.
Herramientas de liberacin y construccin: Son usados para las
tareas de liberacin y construccin de un software incluye instrumentos de instalacin que son
extensamente utilizados para configurar la instalacin de un producto software.

36

1.7

Herramientas de direccin en la Ingeniera de Software

Esta subdivido en tres categoras: planificacin de proyecto y rastreo, manejo arriesgado, y medida.
En la primera se busca una medida de esfuerzo 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 realizacin de actividades relacionadas con el programa de
medida de software.

1.8

Las Herramientas de proceso de ingeniera de Software

Est divida en instrumentos que modelan, instrumentos de direccin y ambientes de desarrollo de
software.

1.9

Las herramientas de Calidad de Software

Dividas en dos categoras: inspeccin e instrumentos de anlisis.
En las herramientas de revisin de auditoria se apoyan en revisin y revisiones de cuenta y en las de
anlisis estticos se analizan artefactos de software como analizadores sintcticos y semnticos as
como datos, el flujo de control y analizadores de dependencia.

1.10

Cuestiones de Instrumento Compuestas

Cubre el tema aplicable a todas las clases de instrumentos, tres categoras identificadas:
tcnicas de integracin de instrumentos, meta-instrumentos, y evaluacin de instrumento.

2.

Los Mtodos de la Ingeniera del Software

Esta divido en tres temas: Mtodos heursticos que tratan con accesos matemticamente basados, y
mtodos de prototipazo que tratan con software que trama accesos basados en varias formas de
prototipazo, cada tema trata sus preocupaciones distintas no quiere decir que no tengan que ver el
uno con el otro.

2.1

Mtodos Heursticos
Este tema contiene cuatro categoras: estructurado, orientado a datos, orientado a objetos, y
especfico de dominio.
La ltima incluye mtodos especializados para desarrollar los sistemas que implican en tiempo real
aspectos relacionados con la seguridad.
En el mtodo estructurado se ve desde un punto de vista funcional para refinarlo y hacerlo cada vez
ms detallado.
En el orientado a datos se estructura el programa y se manipula.
En el orientado a objetos el sistema es visto como una coleccin de objetos ms que de funciones.

2.2

Mtodos Formales

37

Aqu se describe como el software se basa en mtodos de ingeniera basado matemticamente y se

subdivide segn varios aspectos de mtodos formales entre ellos:
Especificacin del lenguaje y notaciones: Aqu se especifica la lengua usada y se clasifica segn
la orientacin del modelo las caractersticas o el comportamiento.
Refinamiento: Aqu se trata como de refinar o transformar las especificaciones en una forma ms
cercana a la deseable en un programa finalmente ejecutable.
Propiedades de Verificacin/Confirmacin: Aqu se incluyen confirmaciones de teorema y la
comprobacin del modelo.
2.3

Mtodos de Prototipado
Cubre mtodos que implican el prototipazo de software y es subdivida en estilos de prototipazo,
objetivos y tcnicas de evaluacin.
Se deben incluir aspectos como: Estilos de prototipazo, objetivos del prototipazo, y las tcnicas para
la evaluacin del prototipo propuesto.

38

CAPITULO 11
CALIDAD DEL SOFTWARE
Porque es tan importante la calidad del software que est en todos los aspectos de la gua
SWEBOK?
Muchos autores le han dado varias definiciones a este trmino pero citar la que le da la ISO 900100 la cul la define como el grado en el que un conjunto de caractersticas inherentes 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 conjunto de mtodos para alcanzar la calidad,
en este caso se trataran las tcnicas estticas es decir aquellas que no requieren la ejecucin del
software para su evaluacin mientras las dinmicas cubren los aspectos de calidad en las pruebas
del software.
1.

Fundamentos de Calidad del Software

Aqu 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 inherentes desde el momento mismo de los requerimientos as
como la medicin y criterios de aceptacin que evalan estas caractersticas.

1.1

Modelos y Caractersticas de Calidad

La terminologa usada en las caractersticas difiere de una taxonoma a otra ya que cada una posee
niveles jerrquicos diferentes, la ISO ha definido tres modelos relacionados con la calidad en un
producto de software (la calidad interna, la calidad externa y la calidad en el empleo).

1.2

Mejora de Calidad
La tarea de la calidad puede ser mejorada cada vez ms gracias a un proceso iterativo de mejora
continua que requiere control de direccin, control y retroalimentacin de muchos procesos

39

simultneos: (1) los procesos de ciclo de vida del software, (2) el proceso de deteccin de
error/defecto, retirada de los mismos y prevencin y (3) el proceso de mejora de calidad, estos
procesos han sido probados y certificados por expertos en calidad que afirman que la calidad de un
producto est directamente relacionada con la calidad del proceso empleado para crearlo.
Existen varios instrumentos que nos permiten conocer los objetivos de la calidad como por ejemplo
el Total Quality Management (TQM), process of plan, Do, Check and Act (PDCA) con estos podemos
identificar fallas, desarrollar acciones detalladas y gestionar el apoyo a la gerencia y a los recursos
asignados para el proyecto para trabajar la calidad en la ingeniera del software.
2.

Procesos de Gestin de Calidad del Software

La gestin de calidad del software (SQM) 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 SQM puede ser utilizado para evaluar productos intermedios as como el producto final.
Algunos de los procesos especficos estn definidos por la IEEE:

Procesos de aseguramiento de calidad

Procesos de Verificacin
Procesos de Validacin
Procesos de Revisin
Procesos de Auditora

Estos procesos incentivan la calidad y tambin permiten encontrar posibles problemas.

Todos los procesos SQM estn enfocados a cumplir tareas y tcnicas para asegurar una calidad de
software ptima en un proyecto dado, estos procesos estn estrechamente relacionados, pueden
solaparse y hasta en ocasiones estar combinados.
Tambin es importante tener en cuenta la gestin de riesgo ya que est juega un papel importante
en la entrega de software de calidad.
Revisiones de Gestin: El objetivo es supervisar el progreso, determinando el estado de los planes
y programas, requerimientos confirmados y su sistema de localizacin o evaluar la efectividad de los
enfoques de gestin empleados. Con esto se determina la idoneidad de los proyectos, programas y
requerimientos y supervisan su progreso o inconsistencias.

40

Revisiones Tcnicas: El propsito es evaluar el producto software para determinar si es idneo

para su correspondiente uso, deben establecerse los roles especficos, una revisin tcnica requiere
que las entradas obligatorias estn en su lugar con el objeto de proceder a: exposicin de objetivos,
un producto software especfico, el plan especfico de gestin del proyecto, la lista de cuestiones
claves asociadas al producto y el procedimiento de revisin tcnica.
Inspecciones: Detecta e identifica anomalas en los productos de software, existen 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 inspeccin; la inspeccin
ha de ser llevada por un inspector con formacin en inspecciones tcnicas.
Las inspecciones por lo general requieren el autor de un producto intermedio y tambin a un lder de
inspeccin, generalmente son hechas sobre una pequea seccin del producto a la vez, las
anomalas encontradas deben ser documentadas y enviadas al responsable de la inspeccin,
tambin es recomendable manejar listas de chequeo durante la inspeccin de esta manera se
clasifican las anomalas y se determinan su exactitud e integridad.
Walk-throughs: El objetivo es evaluar el producto software, los objetivos principales son: Encontrar
anomalas, mejorar 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
trabajo como una tcnica de aseguramiento.
Auditoras: El objetivo es realizar una evaluacin independiente de la conformidad de productos de
software y procesos a regulaciones aplicables, estndares, directrices, planes y procedimientos, est
formalmente organizada con participantes que cumplen roles especficos contando con un
representante de la organizacin auditada.
Puede realizarse sobre casi cualquier proceso o producto en cualquier etapa de mantenimiento o
desarrollo.

3.
3.1

Consideraciones Prcticas:
Requerimientos de calidad del software:
Aqu influyen varios factores como la planificacin la gestin y seleccin de actividades SQM y
tcnicas incluyendo: Donde residir el software , requerimientos del sistema y del software, los
componentes comerciales, estndares , mtodos y herramientas de software, el presupuesto y los
usuarios implicados como tambin el nivel de integridad del sistema.

41

Las tcnicas dinmicas son ejecutadas durante todo el desarrollo y el mantenimiento de software,
generalmente son tcnicas de testeo o simulacin.
Las pruebas examinan todos los output de la especificacin de requerimientos de software con el
objeto de asegurar su trazabilidad, consistencia, completitud, correccin y ejecucin.
Existen muchos tipos de pruebas entre ellos la de terceros ya que es la de un facilitador
independiente por lo general acreditado por alguna autoridad su objetivo es probar el producto
respecto a su conformidad con un conjunto de exigencias.

CAPITULO 12
DISCIPLINAS RELACIONADAS CON LA INGENIERIA DEL SOFTWARE

42

Este captulo se centra en relacionar cada una de las disciplinas de la figura 1 con la Ingeniera del
Software. Es especfico en lo que respecta a determinar las temticas de cada una de ellas con
respecto a otras.