Este documento presenta un resumen de los primeros cuatro capítulos de la Guía de la Ingeniería del Software Cuerpo de Conocimiento (SWEBOK) de la IEEE. Introduce los conceptos clave de la ingeniería de software, requisitos de software, diseño de software y construcción de software. Describe los fundamentos, procesos, técnicas y estándares asociados con cada una de estas áreas del conocimiento de la ingeniería de software.

1. 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. 2
CAPITULO 1
INTRODUCCION A LA GUIA
Esta guía inicia con una amplia y completa introducción sobre el concepto de Ingeniería 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 Ingeniería. La
reconoce como una disciplina crucial para la evolución de la industria de software a nivel mundial y
la define como la aplicación de un enfoque sistemático, disciplinado y cuantificable para el
desarrollo, operación y mantenimiento de software.
Una profesión 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:
1. Que el conocimiento y las competencias de la profesión, sean validadas por profesionales
de la misma área.
2. Que el conocimiento sea validado desde la base racional y con fundamento científico
3. Que el juicio del profesional se enfoque hacia el asesoramiento en el área de estudio
Esta guía no debe ser confundida con el cuerpo de conocimiento de la Ingeniería del Software. La
finalidad de SWEBOK (Guía de la Ingeniería 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 ingeniería del software a nivel mundial.
2. Dar claridad del contexto en el que se aplica la ingeniería del software con respecto a otras
disciplinas, como la ingeniería de sistemas, la ciencia de los computadores, la
administración de proyectos y las matemáticas.
3. Caracterizar los contenidos de esta disciplina.
4. Proveer acceso temático al cuerpo de conocimiento de la ingeniería del software.
5. Proveer la fundación de un ente para apoyar el desarrollo, certificación y licenciamiento de
material de calidad, relacionado con la disciplina.
Está estructurada en 12 capítulos completamente divididos en subcapítulos, que explican todos los
componentes del cuerpo de conocimiento de la ingeniería del software, basados en áreas del
conocimiento, esquematizadas en los siguientes gráficos:

3. 3

4. 4

5. 5
CAPITULO 2
REQUERIMIENTOS DE SOFTWARE
El área del conocimiento de los requisitos de software (KA), se refiere al análisis, especificación y
validación 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 característica que se debe exhibir para solucionar un cierto
problema en el mundo real. Se convierte en una combinación compleja de requisitos entregados por
parte de los usuarios implicados dentro del desarrollo de la solución, teniendo en cuenta que pueden
corresponder a diferentes niveles jerárquicos, 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:
 Requisitos de Producto
Se refiere a generar los parámetros del problema a solucionar para ser traducido a un software.
 Requisitos de Proceso
Se refiere ya a la parte técnica y a lo que voy a utilizar para realizar el software (lenguaje de
programación, por ejemplo).
 Requisitos Funcionales
Son las capacidades o funciones del software.
 Requisitos No Funcionales
Son los que actúan para obligar a llegar a la solución pero no son parte integral del software.
 Características 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

6. 6
Se refiere a todo lo que necesita el software para funcionar desde el punto de vista de hardware,
software, recurso humano, información, 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 organización 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 información para la construcción 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 satisfacción del cliente.
3. Captura de los Requisitos
Se refiere al “cómo” se van a recolectar los requisitos por parte del ingeniero de software. Es aquí
donde es clave la comunicación con el cliente y con todas las personas implicadas en el proceso.
 Fuentes de los Requisitos
Deben ser confiables y sometidas a verificación para confirmar que la persona que suministra la
información es idónea 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.
 Técnicas de Captura de Requisitos
A menudo, el ingeniero de software utiliza técnicas de captura de requisitos, tales como:
• Entrevistas
• Prototipos

7. 7
• Reuniones
• Observación
4. Análisis de Requisitos
Es una auditoría 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.
 Clasificación de los requisitos
Pueden clasificarse en:
• Funcionales o no funcionales
• De producto o de proceso
• Derivado
• Prioritario
• Estable o Volátil
 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 matemática discreta. La
IEEE tiene tres estándares para el modelado. Estos son:
IEEE Std 1320.1 (conceptual)
IDEF0 (funcional)
IEE Std 1320.2, IDEF1X97 (de información)
 Asignación Arquitectónica del Diseño y los Requisitos

8. 8
Es la fusión de toda la parte de requisitos con la parte de diseño. Es inseparable esta combinación;
una es parte integral de la otra y es fácil su comprensión, apoyándose en el modelo conceptual. El
estándar IEEE Std 1471-2000 puede servir de apoyo en esta práctica.
 Negociación de los requisitos
Se llega a esta etapa cuando hay incompatibilidad en dos o más requisitos y los solicitantes son
distintos. El ingeniero de software debe reunirlos y tomar la decisión más conveniente para el
correcto funcionamiento de la solución.
5. Especificación de Requisitos
Se refiere a plasmar en un documento todos los requisitos aprobados. Someterlos a verificación por
parte de los actores del proyecto. Es usual que se hagan tres documentos:
• Definición 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 diseño.
El estándar IEEE Std 830 [IEEE830-98], apoya este proceso de especificación de requisitos.
6. Validación de los Requisitos
Su objetivo es determinar que los documentos realizados sean comprensibles y de acuerdo a los
estándares determinados. Por esto, deben someterse a una auditoría 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 estándar IEEE Std 1028 proporciona ayuda valiosa en la tarea de
revisión.
 Prototipado

9. 9
Es un medio que utiliza el ingeniero de software para manifestar lo que entendió y para facilitar la
corrección, eliminación o adición de requisitos. Como se evidencia, la ventaja de hacerlo es grande
pero el costo puede ser alto.
 Pruebas de Aceptación
Son aquellas que se le aplican a cada requisito para determinar si el producto final lo satisface o no.
Debe haber total planeación para aplicar estas pruebas y hacerlo de manera cuantitativa.
Como conclusión para este capítulo puede afirmarse que los requisitos de software deben tomarse
como una práctica seria, asignándole el tiempo y los recursos necesarios que permitan continuar con
un proceso ordenado para llegar a obtener un software de calidad.

10. 10
CAPITULO 3
DISEÑO DE SOFTWARE
Es definido por la IEEE como el proceso para definir la arquitectura, los componentes, las interfaces
y otras características de un sistema. Visto como proceso, el diseño del software es la actividad del
ciclo de vida en la cual se analizan los requisitos del software para producir una descripción de su
estructura interna que servirá como base para su construcción.
1. Fundamentos
 Proceso de diseño de software
Se divide en dos etapas:
• Diseño Arquitectónico
Descompone el software en componentes y describe sus partes a nivel general, de estructura.
• Diseño Detallado
Describe el comportamiento específico de estos componentes.
Existen técnicas permisibles que permiten hacer un acercamiento al diseño de software. Estas son
algunas:
• Abstracción
Es el proceso de olvidarse de la información para poder tratar las cosas que son diferentes como si
fueran iguales.
• Acoplador y Cohesión

11. 11
El acoplador es la fuerza de las relaciones entre los módulos y la cohesión se refiere a la relación
que existe entre estos módulos.
• Descomposición y Modularización
Esta técnica se utiliza para poner diversas funcionalidades en componentes más pequeños.
• Encapsulación
Permite empaquetar información y hacerla invisible. El éxito está en darle una buena función a esa
información.
El siguiente gráfico muestra la descomposición del proceso de diseño de software.
• Separación de la interfaz y de la puesta en práctica
Define un componente a través de su interfaz gráfica.
• Desahogo
Asegura que la abstracción se hizo de manera correcta y que sólo se tomó lo relevante del
componente.

12. 12
2. Cuestiones claves del diseño de software
Contribuye a entender cómo dividir, organizar y constituir los paquetes de software. Se ayuda con
las siguientes llaves:
 Concurrencia
Se refiere a cómo descomponer el software en procesos, tareas, hilos de reparto y que conserve la
sincronización en los procesos.
 Distribución de Componentes
Como integrar cada parte del software con el hardware necesario para su funcionamiento.
 Dirección del Error y de Excepción y Tolerancia a Fallos
Define las técnicas para prevenir y tolerar fallos en el momento en que se presenten.
 Interacción y Presentación
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 descripción de los subsistemas y de los componentes de un sistema de software y de las
relaciones entre ellos.
4. Análisis y Evaluación de la Calidad del Diseño de Software
Esta parte es importante porque asegura la calidad del proceso de diseño. Se utilizan métricas que
permiten estimar de manera cuantitativa varios aspectos del tamaño, estructura o de la misma
calidad del software. Estas pueden ser estructuradas u orientadas a objetos.
5. Notaciones del Diseño de Software
Generalmente son gráficas y permiten modelar en un diagrama la propuesta de diseño. Entre ellos
están los diagramas de clases y objetos, de componentes, de despliegue, de entidad-relación, de
estructura de Jackson, de estructura de cartas y diferentes lenguajes que permiten describir la
arquitectura del software y sus componentes.

13. 13
También existe la notación para las descripciones de comportamiento dinámico del software, en las
cuales también se usan diagramas y lenguajes textuales. Entre ellos están los diagramas de
actividad, de colaboración, organigrama de datos, tablas y diagramas de decisión, de secuencia, de
transición de estado y diagramas de estado de carta, lenguajes de diseño en pseudocódigo, etc.
6. Estrategias y Métodos del Diseño de Software
Permiten dirigir el proceso de diseño. La estrategia está en términos generales y los métodos deben
ser específicos. Aquí se inicia la aplicación del paradigma Divide y Vencerás y el proceso de
refinamiento. Se define también si se va a utilizar el diseño estructurado u orientado a objetos o
basado en componentes.
CAPITULO 4
CONSTRUCCION DEL SOFTWARE
Este capítulo hace referencia a la creación detallada de software operativo y significativo, por medio
de una combinación de codificación, verificación, pruebas unitarias, pruebas de integración y
depuración.
El Área de Conocimiento de la Construcción del Software está vinculada a todas las otras KAs
(Áreas de Conocimiento), más fuertemente al Diseño del Software y a las Pruebas del Software.
Esto se debe a que el proceso mismo de construcción del software cubre tanto el diseño significativo
de software como las actividades de pruebas.
En síntesis, esta es la etapa de creación del código fuente que tendrá el software.
1. Fundamentos
La construcción del software tiene como objetivos los siguientes:
Minimizar la complejidad
Anticiparse a los cambios
Construir para verificar
Aplicación de estándares en la construcción
La descomposición de los temas de Construcción del Software se detallan en el siguiente gráfico:

14. 14
2. Gestión de la Construcción
 Modelos de Construcción
Los más 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 diseño. Por el contrario, los modelos prototipado evolucionista,
programación extrema y “Scrum”, son más flexibles en este tema, dado que son iterativos y
permiten, de manera cíclica, realizar cambios, al combinar las tres etapas iniciales del desarrollo de
un proyecto de software.
 Planificación de la Construcción
En todo proyecto, la planificación es vital. Es aquí donde se delimita la aplicación de requisitos, en
qué orden se irán 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.
 Medición de la Construcción
Se refiere a los procedimientos utilizados para medir la eficiencia del código fuente, en lo que se
refiere a extensión, código reutilizado, código destruido, complejidad de código, estadísticas de
inspección de código, tasas de rectificación y corrección de errores y los horarios. Esto asegura el
control de la calidad.
3. Consideraciones Prácticas

15. 15
Para solucionar un problema de la vida real a través de un software, es totalmente necesario utilizar
un lenguaje de programación. Aquí radica el éxito del proyecto de software, dado que es el
ingeniero de software el encargado de aprobar el lenguaje a través de los argumentos dados por los
encargados de la elaboración del código fuente.
 Lenguajes de Construcción
Son todos los tipos de comunicación mediante los cuales un ser humano puede especificar una
solución ejecutable para un problema de un ordenador. Pueden ser de configuración, de
herramientas y de programación. Estos últimos, a su vez, están divididos en lingüísticos, formales y
visuales.
 Pruebas de Construcción
Generalmente son realizadas por el profesional que realizó el código. Pueden ser unitarias o de
integración. Su propósito es reducir el tiempo entre el ingreso de fallas en el código y el tiempo que
se puede demorar su detección. Para tal fin, las normas estándar IEEE Std 829-1998 para
documentación de pruebas y la IEE Std 1008-1987 para pruebas unitarias, pueden ser de gran
utilidad.
 Reutilización
Definir de manera objetiva, que parte del código puede ser eficientemente reutilizado para minimizar
tiempos de entrega, además 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 Construcción
Existen varias técnicas para evaluar la calidad en la construcción del código fuente de un proyecto
de software. Entre ellas tenemos:
 Las pruebas unitarias y de integración
El código paso a paso
Utilización de aserciones
Depuración
Revisiones técnicas
Análisis estático
 Integración
Una parte clave del proceso de construcción es la integración de las clases, componentes, rutinas,
subsistemas que han sido construidos por separado, sobre todo si hay implicaciones técnicas de
software o hardware.

16. 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 dinámicamente a
través de un grupo finito de casos de prueba, debidamente seleccionados. Se ha ido cambiando la
percepción de que las pruebas de software se realizan únicamente al final del proceso de creación
de código 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. 17
CAPITULO 6
MANTENIMIENTO DE SOFTWARE
INTRODUCCION
El proceso de desarrollo de software debe satisfacer los requerimientos planteados, una vez en
operación el proceso de cubrimiento de defectos, operación y cambio de ambiente debe darse en
esta etapa, la fase de mantenimiento empieza con un periodo de garantía y de soporte post-
implementación pero el mantenimiento del software ocurre mucho antes.
Aunque la etapa de mantenimiento del software no ha tenido el grado de atención 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 atención que se merece.

18. 18
El mantenimiento de software se ha definido como el número total de actividades requeridas para
proveer soporte efectivo al software, esto incluye un planeamiento efectivo antes. Durante y después
de la implementación 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 terminología:
Está definido en el estándar de la IEEE 1219 como la modificación 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 estándar 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 también lo hacen en estos mismos términos la ISO/IEC 14764 este enfatiza en las
entregas previas para la planeación del mantenimiento del software.
1.2 Naturaleza del mantenimiento:
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
desempeño correcto.
Identifica las actividades de mantenimiento como un proceso de implementación y modificación
y análisis del problema, estas actividades son discutidas en el tópico 3.2 Actividades de
Mantenimiento.

19. 19
Figura 1. Tópicos 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 desempeño
adecuado y en el orden de:
• Corregir fallas.
• Improvisar el diseño.
• Implementar correcciones.
• Interfaces con otros sistemas.

20. 20
• Adaptar programas a diferentes tipos de hardware, software, configuración del sistema y
facilidad de uso de telecomunicaciones.
• Migración 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 más del 80% del mantenimiento de software
es usado para acciones correctivas hay que entender la categoría 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 continuación se presentan
algunos aspectos técnicos y no técnicos que afectan los costos de mantenimiento:
• Tipo de Aplicación.
• Disponibilidad del mantenimiento de software.
• Ciclo de vida del software.
• Características de hardware.
• Calidad del diseño de software, construcción, documentación y pruebas.
1.5 Evolución del software:
En 1969 Lehman direcciono el mantenimiento del software y la evolución de los sistemas,
durante 20 años se mantuvo su idea de la formulación de ocho “Leyes de la evolución” donde
se mantuvo la idea de la evolución en el mantenimiento del software para continuar con el
desarrollo.
Lientz y Swanson inicializaron la definición de tres categorías de mantenimiento: correctivo,
adaptativo y perfectivo.

21. 21
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 técnica única en los desafíos de administración para los ingenieros de
software, podemos apreciar como se planean las liberaciones posteriores así como los parches
generados para las versiones anteriores, lo que sigue a continuación nos presenta una manera
de cómo se nos presentan algunos factores de administración y técnicos para el mantenimiento
de software, estos se agrupan según los tópicos siguientes:
• Factores técnicos.
• Factores administrativos.
• Estimación de costos.
• Medidas.
3. Proceso de mantenimiento:
Provee referencias y estándares utilizados para implementar el proceso de mantenimiento
de software.
Las actividades de mantenimiento son diferenciadas por el desarrollo mostrado en la
relación a las actividades de ingeniería de otro software.

22. 22
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 pequeña diferencia:
Cada actividad de mantenimiento primario de software ISO/IEC 14764 es desglosada en
los siguientes términos:
• Proceso de implementación.
• Análisis del problema y modificaciones.
• Implementación y modificación.
• Mantenimiento Aceptación/Revisión.

23. 23
• Migración.
• Retiro de Software.
Técnicas para el mantenimiento:
Esta subárea nos introduce a algunas generalidades aceptadas por las técnicas del
mantenimiento de software:
3.1 Comprensión 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 Reingeniería
Esta definida como el examen de de la alteración del software para reconstituir una nueva
forma, la reingeniería es la mas radical y expansiva forma de la alteración otros creen que
la reingeniería 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 Ingeniería 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
abstracción, es pasiva, y no hace cambios al software o resulta en otro software. Produce
gráficas asi como control de flujo y del código fuente, un tipo de reingeniería puede ser la
redocumentación, otro tipo es la reparación del diseño.
Finalmente la reingeniería ha sido de gran importancia en los últimos años ya que gracias a
sus esquemas lógicos a podido restaurar bases de datos físicas.
CAPITULO 7
ADMINISTRACION DE LA CONFIGURACION DEL SOFTWARE

24. 24
Un sistema puede ser definido como un conjunto de componentes organizados con el propósito de
cumplir una función o conjunto de funciones específicas.
En este sentido la configuración de un software y sus características funcionales de hardware,
software, firmware o la combinación de estas son un conjunto de características técnicas que se
deben cumplir para garantizar su correcto funcionamiento.
La administración de configuración es la disciplina encargada de identificar la configuración general
de un sistema para así mantener su confiabilidad, adaptabilidad y configuración a los diferentes
ciclos de vida. Está formalmente definida por la IEEE610.12-90 como “Disciplina aplicada de manera
técnica y administrativa para la dirección y supervivencia para: Identificar y documentar las
características físicas y funcionales de la configuración de los elementos, control en el cambio de
sus características grabar y reportar cambios en el proceso de implementación así como su estado
y verificación del cumplimiento de sus requerimientos específicos”.
1. Administración de los procesos SCM

25. 25
La SCM administra y controla la evolución e integridad del software así como su verificación,
control, reportes y configuración de la información. Una implementación exitosa del SCM
requiere un cuidado especial y planeación y administración.
1.1 Contexto Organizacional del SCM
Para desarrollar un plan SCM es necesario conocer detalladamente los procesos de la
organización ya que el SCM interactúa directamente con todos los elementos y actividades
organizacionales.
1.2 Constantes y guía para el proceso SCM
Esto proviene de un gran numero de fuentes tiene que ver con las políticas de la
organización y su influencia en la administración de los procesos.
1.3 Planeación del SCM
El proceso de planeación debe ser consistente con el contexto organizacional, y la
naturaleza del proyecto (por ejemplo el tamaño y su crítica) las actividades más importantes
en este contexto son: control de configuración, control de estado, control de auditoría,
control de liberaciones y entregas así como las herramientas de configuración y control y
sus interfaces consideradas.
1.4 Plan de la SCM
Los resultados de planeación del proyecto son guardados en un plan de gestión y
configuración del software, el documento se mantiene y se actualiza o aprueba según sea
necesario a lo largo del ciclo de vida del software.
También es muy útil hacer mediciones constantes a los procesos para hacer los cambios y/o
actualizaciones correspondientes.

26. 26
1.5 Seguimiento de la gestión de la configuración del software
Después 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 auditoría 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 información acerca de las características de los procesos SCM.
2. Identificación de la configuración del software
Identifica los elementos a ser controlados, establece e identifica esquemas y sus versiones,
establece herramientas y técnicas utilizadas para administrar y controlar dichos elementos.
2.1 Identificar elementos a ser controlados
Un primer paso sería identificar cambios en los elementos de software que serán
controlados para entender la configuración del software en el contexto del sistema.

27. 27
2.2 Biblioteca de software
Colección 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 también una fuente importante de información para
mediciones del trabajo realizado y del progreso.
3. Control de la configuración del software
Le concierne la gestión 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
implementación de dichos cambios.
La información derivada de estas actividades es útil para medir el tráfico de cambios y
ruptura de aspectos por rehacer.
3.1 Petición, evaluación y aprobación de cambios del software
El primer paso es determinar los cambios a realizar, se evalúa 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 solución 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 planificación aplicables.
Podrían sufrir auditorías de configuración y verificación de la calidad del software. Esta
soportada por las herramientas de la biblioteca que proporcionan gestión de versiones y
soporte para el almacenamiento de código.

28. 28
3.3 Desviaciones y Remisiones
Las limitaciones que se imponen al esfuerzo de la ingeniería del software podrían contener
necesidades que no pueden ser satisfechas en el punto designado del ciclo de vida. Una
remisión es una autorización para abandonar una necesidad antes del desarrollo del
elemento.
4. Registro del estado de la configuración del Software
La contabilidad del estado de la configuración del software (SCSA) es la actividad de
registrar y proporcionar la información necesaria para una gestión efectiva de la
configuración del software.
4.1 Información del estado de la configuración del software
Genera un conjunto de informes durante el ciclo de vida, se encarga de recoger y mantener
la información del estado de la configuración que se ha de gestionar según las
configuraciones evolucionan.
Es necesario algún tipo de soporte de herramientas automáticas para llevar a cabo las
tareas de recogida de datos y generación de informes de la SCSA.
4.2 Reportes del estado de la configuración del software
Los reportes pueden ser usados para los elementos del proyecto de la organización,
incluyendo el equipo de desarrollo, administración de proyectos y actividades de calidad del
software.
También sirve para responder algunas preguntas específicas de la etapa de producción.

29. 29
5. Auditoría de la configuración de software
Es una actividad desarrollada independientemente para evaluar la conformidad de los
productos de software, se encarga de aplicar regulaciones, estándares, planes de guía y
procedimientos.
Deben ser cuidadosamente planeadas, existen herramientas que apoyan la planeación y
conducción de las auditorías para facilitar su proceso.
Determina la extensibilidad de los elementos y sus características físicas, los informes
pueden ser orientados como puntos clave en el ciclo de vida, las auditorias pueden ser un
requisito para las líneas base.
5.1 Auditoria funcional de la configuración del software
El propósito es asegurar la consistencia en los elementos de software auditados. La salida
de la verificación y validación del software es la clave de entrada de este tipo de auditoría.
5.2 Auditoría de la configuración física del software
El propósito es asegurar que el diseño y la documentación de referencia es consistente con
la construcción del producto de software.
5.3 Auditoría durante el proceso de una línea base de software
Como lo mencionado puede ser llevado durante el proceso de desarrollo para investigar el
estado actual de los elementos específicos de la configuración. La auditoría es aplicada a
los elementos de la línea base para asegurar el desempeño que sea consistente con las
especificaciones.
6. Administración de las entregas y liberaciones de software

30. 30
El término “liberación” 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 información y documentación entregada en las liberaciones es conocida como el
documento descriptivo, este incluye los contenidos de instalación y instrucciones de
actualización.
CAPITULO 8
GESTION DE LA INGENIERIA DEL SOFTWARE
Puede ser definida como las actividades de gestión de la aplicación, planeación, coordinación,
medición, monitorización, control y reportes para asegurar el desarrollo y mantenimiento del software
como sistemático, disciplinado y cuantificable.
Es un aspecto muy importante en la administración y medición de la ingeniería del software.
En estas actividades se destacan tres niveles: Gestión y organización de la infraestructura, gestión
de proyectos, y control y planeación del programa de medidas.
Los aspectos de la gestión de la organización son importantes en términos del impacto en la
ingeniería del software y en las políticas de gestión, esas políticas pueden ser influenciadas por los
requerimientos de un software efectivo, mantenimiento y desarrollo.
Un número de políticas específicas deben ser establecidos para una efectiva gestión en la ingeniería
del software y el nivel organizacional.

31. 31
Haciendo gestión con énfasis en la medición y un principio de presupuesto en cualquier disciplina de
verdadera ingeniería puede ayudar a darle la vuelta a esta percepción.
Una gestión eficaz requiere la combinación tanto de números como de experiencia.
La gestión en la ingeniería del software se descompone en seis subáreas principales a continuación
se da un espacio detallado de cada una.

32. 32
1. Iniciación y Alcance
Se centra en la determinación eficaz de los requisitos del software por medio de varios métodos de
inducción y la valoración de la viabilidad del proyecto desde distintos puntos de vista, una vez
establecida la viabilidad, la tarea pendiente es la especificación de la validación de requisitos y del
cambio de procedimientos.

33. 33
2. Planificación de un Proyecto de Software
Esta regulado por los alcances y los requisitos y por la viabilidad del proyecto, se evalúan los
procesos de ciclo de vida y se selecciona el más apropiado.
Se debe realizar una descomposición jerárquica de tareas, y la realización de un calendario y una
estimación de costos.
Más adelante se le da un presupuesto a las tareas y la imposición de horarios y uso de materiales,
se debe llegar a la determinación de procesos y responsabilidades para asegurar la calidad del
software, verificación, validación y revisiones de auditorías.
2.1 Planificación de un Proceso
La selección de un modelo de ciclo de vida o la adaptación de un despliegue de ciclos se emprenden
a la luz del alcance particular y de los requisitos del proyecto.
También se seleccionan métodos y herramientas pertinentes.
2.2 Determinar los entregables
Se especifica y caracteriza los productos de cada tarea, se evalúa la posibilidad de reutilizar
componentes de desarrollos anteriores y se planifica la utilización de terceras personas y del
software obtenido y se seleccionan los proveedores.
2.3 Esfuerzo, calendario y cálculo del coste
Se determina el rango de esfuerzo esperado, utilizando un modelo de estimación calibrado, basado
en datos históricos 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 finalización bien planificados.
Los requisitos de recursos (personas, herramientas) se traducen en estimaciones de costo.

34. 34
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 Gestión de Riesgos
Se completa el análisis de riesgos, la valoración crítica de riesgos, la mitigación de riesgos y la
planificación de contingencias.
Los métodos para la valoración 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 Gestión de calidad
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 límites de adhesión de calidad se colocan de acuerdo a las expectativas que tenga el contratista
sobre el software en cuestión así como los procedimientos de verificación y validación del producto
entregable.
2.7 Gestión de planes
Los informes, la supervisión y el control del proyecto deben encajar en el proyecto de ingeniería del
software seleccionado y en las realidades del proyecto y deben reflejarse los artefactos que lo
gestionarán.
Los cambios a otros procesos de soporte ejemplo: gestión documental, resolución de problemas
también deben gestionarse de la misma manera.
3. Promulgación del proyecto de Software

35. 35
Se ejecutan los planes y se divulgan los procesos incluidos en los planes, en este proceso hay total
expectativa de la adhesión plena de los requisitos del contratista y el logro de los objetivos del
proyecto, son actividades fundamentales para la promulgación la gestión, medición, supervisión,
control e información del proyecto.
4. Revisión y Evaluación
Se evalúa el proceso global hacia el logro de los objetivos y satisfacción 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 métodos utilizados.
4.1 Determinar la satisfacción de los requisitos
Determinar que el objetivo principal se está cumpliendo es primordial ya que lo que nos interesa es
la satisfacción del usuario o contratista esto se debe hacer periódicamente.
Se deben identificar las variaciones a las expectativas para llevar a cabo las acciones adecuadas.
También se debe gestionar el control de cambios a los procedimientos y a la configuración del
software.
4.2 Revisar y Evaluar la Ejecución
Las revisiones periódicas a lo realizado nos proporcionan detalles sobre la probabilidad de ser fiel a
los planes, así como las posibles áreas de dificultad, aquí se evalúan los diferentes métodos,
herramientas y técnicas empleadas para ver su eficacia y adecuación y se evalúa 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.

36. 36
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 habían especificado y todos los productos planificados
han sido entregados con características 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 documentación 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 medición de la organización se pone
al día con los datos finales del proyecto y se emprende el análisis 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 organización y los
intentos de mejora.
6. Medidas de la ingeniería del software
Aquí abordamos el tema de la medición en la ingeniería del software y su importancia para esto se
sigue unas métricas y normas establecidas por entidades como la ISO y la IEEE.
6.1 Establecer y sostener el compromiso de medir

37. 37
Se deben tener ciertos compromisos de medición establecidos, además 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 organización, además se debe adquirir un
compromiso que se debe comunicar y apoyar en los recursos de la organización.
Se deben asignar recursos para llevar a cabo el proceso de medición además de dar la financiación
y herramientas adecuadas para dirigir este proceso.
6.2 Planificar el proceso de medición
Para esto es necesario identificar la unidad funcional a la cuál se le está aplicando para que sea
caracterizada y así identificar las necesidades de información para proceder con los objetivos
primordiales y sus respectivas prioridades.
Se deben seleccionar las mediciones a realizar además como las muestras de información que
serán tomadas para su posterior análisis, verificación e información a ser dada.
El plan de medición también debe ser revisado y aprobado por los contratistas adecuados además
de mantener disponibles los recursos para dicho plan.
Se deben comunicar los resultados además de documentarse publicarse.
6.3 Evaluar las mediciones
Este proceso se debe llevar a cabo con un criterio de evaluación específico para determinar las
fuerzas y debilidades de los productos, se puede hacer por medio de un proceso de auditoría interna
o externa y debe incluir una retroalimentación a los usuarios.
Se deben identificar las mejoras potenciales y costos y beneficios de estas, comunicarlas a la
persona encargada para su revisión y aprobación.

38. 38
CAPITULO 9
PROCESO DE INGENIERÍA DEL SOFTWARE

39. 39
Se puede examinar en dos niveles desde lo técnico y desde el meta-nivel o nivel de implementación,
valoración, medición y gestión.
Existen varios significados sobre el proceso de la ingeniería 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
hacer ya que el proceso de la ingeniería abarca muchos factores, finalmente un tercer significado se
refiere al conjunto actual de actividades realizadas dentro de una organización que se puede ver
como un solo proceso.
Los procesos de ingeniería del software son considerados de gran importancia, el objetivo es
gestionar nuevos y mejores procesos.
1. Proceso de implementación y cambios
Se centra en los cambios organizacionales, describe la infraestructura, actividades, modelos y
consideraciones prácticas de un proceso de implementación y cambios:
También es denominado el proceso de evaluación, hay que tener cuidado con las modificaciones ya
que puede que también 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 estén al alcance de la
mano y que se hayan asignado responsabilidades, es posible que se tengan que establecer comités
para supervisar el esfuerzo del proceso de ingeniería del software.
Con un grupo de proceso de la ingeniería del software se pretende ser el foco central en el proceso
de mejoras y tiene cierto número de responsabiidades en la inicialización y el mantenimiento.
El concepto de creadora de experiencias (EF) se centra en el proceso de mejoramiento de los
procesos de la ingeniería del software.

40. 40
2. Definición de procesos
Pueden ser unos lineamientos, políticas o estándares se definen para facilitar el entendimiento
en la comunicación humana, apoyar y mejorar procesos , se deben considerar algunas variaciones
como la naturaleza del trabajo, el dominio de la aplicación, el modelo de ciclo de vida y la madurez
de la organización.
3. Valoración del proceso
Se lleva a cabo utilizando un método y un modelo de valoración que en algunos casos es visto como
un modelo de apreciación y muchas veces una evaluación de capabilidad cuando es para la
adjudicación de algún contrato.
3.1 Modelos de valoración del proceso
Recoge lo que se conoce como las buenas prácticas en el proceso de gestión de la ingeniería del
software, la ISO define un modelo ejemplo de valoración y de requisitos, se han desarrollado
también un modelo de madurez para sistemas de ingeniería 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 valoración: continua y escalonadamente, son
muy diferentes entre ellas y se deben evaluar para conocer cuál es la que mejor se adapta a mis
necesidades y objetivos.
3.2 Métodos de valoración del proceso
Es garantizar un método cuantitativo que evaluara los procesos, existen de varios tipos dónde se
valoran distintos tópicos todos pensados en las mejoras de los procesos y la eficacia en la
organización.

41. 41
4. Medición de los procesos y los productos
Aunque puede resultar compleja la medición a la ingeniería del software existen varios aspectos que
son fundamentales para la medición y análisis, estas mediciones se pueden realizar para apoyar los
procesos de implementación y cambio o evaluar consecuencias de estos.
4.1 Medición del proceso
Se recoge, analiza e interpreta información cuantitativa sobre el proceso, se utiliza para identificar la
fuerza y debilidad en ellos y así mismo evaluarlos después de haber sido implementados o
cambiados.

42. 42
La medición de un producto software incluye principalmente, la medición del tamaño del producto, la
estructura del producto y la calidad del producto.
También es importante tener en cuenta la medición del tamaño, de la estructura y de la calidad.
Para garantizar la calidad en los resultados de la medición es necesaria la medición efectiva de los
programas para proveer resultados exitosos.
CAPITULO 10
INSTRUMENTOS Y MÉTODOS DE LA INGENIERÍA 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 enfocándonos más en los
aspectos creativos del proceso.
Los métodos imponen la estructura a la actividad de la ingeniería del software con el objetivo de
hacerla sistemática, por lo general proporcionan notación y vocabulario para comprobar tanto el
proceso como el producto, aunque existen numerosos materiales sobre los instrumentos de apoyo
en la ingeniería del software, los textos sobre las técnicas sobre estos instrumentos son
relativamente escasos, una dificultad es el alto costo que representa un cambio de instrumento de

43. 43
software en general, los instrumentos y métodos cubren ciclos de vida completos por esto es tan
complicado hacer un cambio.
Estudio de las herramientas y métodos de la ingeniería de software
1. Las herramientas de ingeniería de Software
Estás corresponden a las cinco primeras áreas de conocimiento de la guía, Exigencias de software,
diseño de software, construcción de software, pruebas de software y mantenimiento de software.
Los cuatro siguientes asuntos corresponden a las áreas de conocimiento restantes: La dirección de
configuración de software, la dirección de ingeniería de software, el proceso de ingeniería de
software, y la calidad del software.
1.1 Las Herramientas de exigencias de Software
Han sido clasificados en dos categorías: modelado e instrumentos de capacidad de rastreo.
• Exigencias de los instrumentos de modelado: Son usados para la obtención, análisis, especificación
y validez de las exigencias de software.
• Exigencias de los instrumentos de capacidad de Rastreo: Se hacen cada vez más importantes
debido a que la complejidad del software crece, son presentados separadamente de los
instrumentos de modelado.
1.2 Las Herramientas de Diseño de Software
Cubre los instrumentos para crear y comprobar diseños de software, existe gran variedad de estos
gracias a la diversidad en las notaciones de diseño de software y métodos, a pesar de esta variedad
no se ha encontrado una división convincente.

44. 44
1.3 Las Herramientas de Construcción de Software
Son instrumentos usados para producir y traducir la representación de programa máquina, se utilizan
los redactores de programa, compiladores y generadores de código, intérpretes y depuradores.
1.4 Herramientas de Pruebas de Software
Se incluyen: Generadores de Pruebas, marcos de ejecución de pruebas, herramientas de evaluación
de pruebas, herramientas de dirección de pruebas y de análisis y de funcionamiento, todas estas
están 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 categorías son
identificadas: instrumentos de comprensión y instrumentos de reingeniería.
Herramientas de comprensión: Ayudan a la comprensión humana de programas, se incluyen
instrumentos como animadores o rebanadores.
Herramientas de reingeniería: Es definido como el examen y la alteración del software sustancial
para reconstruirlo de una nueva forma.
1.6 Las herramientas de dirección de configuración de Software
Han sido dividas en tres categorías: rastreo, dirección de versión e instrumentos de liberación.
• Rastreo: Son elementos utilizados en la conexión con las cuestiones que rastrean problemas
asociados con un producto de software particular.
• Herramientas de dirección de versión: Están implicados en la dirección de múltiples versiones de un
producto.

45. 45
• Herramientas de liberación y construcción: Son usados para las tareas de liberación y construcción
de un software incluye instrumentos de instalación que son extensamente utilizados para configurar
la instalación de un producto software.
1.7 Herramientas de dirección en la Ingeniería de Software
Esta subdivido en tres categorías: planificación de proyecto y rastreo, manejo arriesgado, y medida.
En la primera se busca una medida de esfuerzo en el proyecto y cuenta la valoración así como la
planificación del proyecto, en la segunda se identifican la estimación y riesgos de supervisión,
finalmente en la medida se asiste la realización de actividades relacionadas con el programa de
medida de software.
1.8 Las Herramientas de proceso de ingeniería de Software
Está divida en instrumentos que modelan, instrumentos de dirección y ambientes de desarrollo de
software.
1.9 Las herramientas de Calidad de Software
Dividas en dos categorías: inspección e instrumentos de análisis.
En las herramientas de revisión de auditoria se apoyan en revisión y revisiones de cuenta y en las de
análisis estáticos se analizan artefactos de software como analizadores sintácticos y semánticos así
como datos, el flujo de control y analizadores de dependencia.
1.10Cuestiones de Instrumento Compuestas
Cubre el tema aplicable a todas las clases de instrumentos, tres categorías identificadas:
técnicas de integración de instrumentos, meta-instrumentos, y evaluación de instrumento.

46. 46
2. Los Métodos de la Ingeniería del Software
Esta divido en tres temas: Métodos heurísticos que tratan con accesos matemáticamente basados, y
métodos 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 Métodos Heurísticos
Este tema contiene cuatro categorías: estructurado, orientado a datos, orientado a objetos, y
específico de dominio.
La última incluye métodos especializados 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 hacerlo cada vez
más detallado.
En el orientado a datos se estructura el programa y se manipula.
En el orientado a objetos el sistema es visto como una colección de objetos más que de funciones.
2.2 Métodos Formales
Aquí se describe como el software se basa en métodos de ingeniería basado matemáticamente y se
subdivide según varios aspectos de métodos formales entre ellos:
Especificación del lenguaje y notaciones: Aquí se especifica la lengua usada y se clasifica según
la orientación del modelo las características o el comportamiento.
Refinamiento: Aquí se trata como de refinar o transformar las especificaciones en una forma más
cercana a la deseable en un programa finalmente ejecutable.
Propiedades de Verificación/Confirmación: Aquí se incluyen confirmaciones de teorema y la
comprobación del modelo.

47. 47
2.3 Métodos de Prototipado
Cubre métodos que implican el prototipazo de software y es subdivida en estilos de prototipazo,
objetivos y técnicas de evaluación.
Se deben incluir aspectos como: Estilos de prototipazo, objetivos del prototipazo, y las técnicas para
la evaluación del prototipo propuesto.

48. 48
CAPITULO 11
CALIDAD DEL SOFTWARE
¿Porque es tan importante la calidad del software que está en todos los aspectos de la guía
SWEBOK?

49. 49
Muchos autores le han dado varias definiciones a este término pero citaré la que le da la ISO
9001-00 la cuál la define como “el grado en el que un conjunto de características inherentes cumple
requisitos”.
En este capítulo se abordan los aspectos relativos a la calidad del software los cuales trascienden en
cualquier ciclo de vida, en esta guía se describen un conjunto de métodos para alcanzar la calidad,
en este caso se trataran las técnicas estáticas es decir aquellas que no requieren la ejecución del
software para su evaluación mientras las dinámicas 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
debería entender y adoptar los conceptos y características 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 medición y criterios de aceptación que evalúan estas características.
1.1 Modelos y Características de Calidad
La terminología usada en las características difiere de una taxonomía a otra ya que cada una posee
niveles jerárquicos 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 más gracias a un proceso iterativo de mejora
continua que requiere control de dirección, control y retroalimentación de muchos procesos

50. 50
simultáneos: (1) los procesos de ciclo de vida del software, (2) el proceso de detección de
error/defecto, retirada de los mismos y prevención 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 ingeniería del software.
2. Procesos de Gestión de Calidad del Software
La gestión de calidad del software (SQM) es de gran importancia y aplicación 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 específicos están definidos por la IEEE:
• Procesos de aseguramiento de calidad
• Procesos de Verificación
• Procesos de Validación
• Procesos de Revisión
• Procesos de Auditoría

51. 51
Estos procesos incentivan la calidad y también permiten encontrar posibles problemas.
Todos los procesos SQM están enfocados a cumplir tareas y técnicas para asegurar una calidad de
software óptima en un proyecto dado, estos procesos están estrechamente relacionados, pueden
solaparse y hasta en ocasiones estar combinados.
También es importante tener en cuenta la gestión de riesgo ya que está juega un papel importante
en la entrega de software de calidad.
Revisiones de Gestión: El objetivo es supervisar el progreso, determinando el estado de los planes
y programas, requerimientos confirmados y su sistema de localización o evaluar la efectividad de los
enfoques de gestión empleados. Con esto se determina la idoneidad de los proyectos, programas y
requerimientos y supervisan su progreso o inconsistencias.
Revisiones Técnicas: El propósito es evaluar el producto software para determinar si es idóneo
para su correspondiente uso, deben establecerse los roles específicos, una revisión técnica requiere
que las entradas obligatorias estén en su lugar con el objeto de proceder a: exposición de objetivos,
un producto software específico, el plan específico de gestión del proyecto, la lista de cuestiones
claves asociadas al producto y el procedimiento de revisión técnica.
Inspecciones: Detecta e identifica anomalías en los productos de software, existen dos importantes
elementos diferenciadores entre inspección y revisión y son los siguientes: un individuo que
mantiene una posición de dirección sobre cualquier miembro del equipo de inspección; la inspección
ha de ser llevada por un inspector con formación en inspecciones técnicas.
Las inspecciones por lo general requieren el autor de un producto intermedio y también a un líder de
inspección, generalmente son hechas sobre una pequeña sección del producto a la vez, las
anomalías encontradas deben ser documentadas y enviadas al responsable de la inspección,
también es recomendable manejar listas de chequeo durante la inspección de esta manera se
clasifican las anomalías y se determinan su exactitud e integridad.

52. 52
Walk-throughs: El objetivo es evaluar el producto software, los objetivos principales son: Encontrar
anomalías, mejorar el producto software, considerar implementaciones alternativas, evaluar la
conformidad con estándares y especificaciones.
Es similar a una inspección 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 técnica de aseguramiento.
Auditorías: El objetivo es realizar una evaluación independiente de la conformidad de productos de
software y procesos a regulaciones aplicables, estándares, directrices, planes y procedimientos, está
formalmente organizada con participantes que cumplen roles específicos contando con un
representante de la organización auditada.
Puede realizarse sobre casi cualquier proceso o producto en cualquier etapa de mantenimiento o
desarrollo.
3. Consideraciones Prácticas:
3.1 Requerimientos de calidad del software:
Aquí influyen varios factores como la planificación la gestión y selección de actividades SQM y
técnicas incluyendo: Donde residirá el software , requerimientos del sistema y del software, los
componentes comerciales, estándares , métodos y herramientas de software, el presupuesto y los
usuarios implicados como también el nivel de integridad del sistema.
Las técnicas dinámicas son ejecutadas durante todo el desarrollo y el mantenimiento de software,
generalmente son técnicas de testeo o simulación.
Las pruebas examinan todos los output de la especificación de requerimientos de software con el
objeto de asegurar su trazabilidad, consistencia, completitud, corrección y ejecución.

53. 53
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.

54. 54
CAPITULO 12
DISCIPLINAS RELACIONADAS CON LA INGENIERIA DEL SOFTWARE
Este capítulo se centra en relacionar cada una de las disciplinas de la figura 1 con la Ingeniería del
Software. Es específico en lo que respecta a determinar las temáticas de cada una de ellas con
respecto a otras.

55. 55