INTRODUCCIÓN

El desarrollo de software es un proceso tecnológico de alta complejidad que

consume tiempo, requiere mucho esfuerzo humano y demanda costos,
generalmente, elevados. Un porcentaje muy alto de proyectos de software
fracasan debido, entre otros factores, a una gestión deficiente del proyecto.
El éxito de un proyecto de software se mide en función de tres variables
fundamentales: costo, tiempo y calidad. Un proyecto exitoso es aquel que
se entrega a tiempo, bajo el presupuesto asignado y con la calidad
especificada. Para manejar estas tres variables, los ingenieros de software
emplean modelos, procesos y técnicas gerenciales.
I. METODOLOGÍA DE GESTIÓN DE PROYECTO

1.1 GESTION DE PROYECTOS DE SOFTWARE

1.1.1 MISIÓN, COORDINACIÓN CON OTROS PROYECTOS,

DIFERENCIAS Y DOCUMENTACIÓN (AD-HOC, DOCUMENTADO,
NORMAS)

1.1.1.1 Misión :

• Que el desarrollo del proyecto esté dentro de los límites

marcados de tiempo y presupuesto.
• Indirectamente garantiza una buena realización técnica.
• Una buena gestión no garantiza el éxito, pero sin gestión
hay fracaso

1.1.1.2 Coordinación con otros proyectos:

• Hablar de proyectos software puede resultar incorrecto por

que lo normal no es que se desarrolle un software sino un
sistema en el que el software va a tener una parte más o
menos protagonista.
• Generalmente el proyecto software no se ejecuta de forma
aislada sino que tiene que integrarse con otros proyectos
que se están realizando en la organización.
• Cuando se integra con otros proyecto (en curso o en
futuro) software de la organización se suele hablar de
gestión integrada de la información en la empresa.

1.1.1.3 Diferencia de la gestión de software con otros

campos:

• El producto es intangible
• No hay un proceso software estándar.
• No hay una relación cerrada entre tipos de producto
software

Tipos de Software: [1]

Software de sistemas
Está formado por todos aquellos programas cuya
finalidad es servir al desarrollo o al funcionamiento de
otros programas. Estos programas son muy variados:
editores, compiladores, sistemas operativos, entornos
gráficos, programas de telecomunicaciones, etc. pero
se caracterizan por estar muy próximos al hardware,
por ser utilizados concurrentemente por numerosos
usuarios y por tratarse de programas de amplia
difusión, no estando diseñados normalmente a medida.
Esto permite un mayor esfuerzo en su diseño y
optimización, pero también les obliga a ser muy fiables,
cumpliendo estrictamente las especificaciones para las
que fueron creados. Un ejemplo de este tipo de
software son los sistemas operativos, como Windows y
Unix.
Software de tiempo real
Esta formado por todos aquellos programas que miden,
analizan y controlan los sucesos del mundo real a
medida que ocurren, debiendo reaccionar de forma
correcta a los estímulos de entrada en un tiempo
máximo prefijado. Deben, por tanto, cumplir unos
requisitos temporales muy estrictos y, dado que los
procesos que controlan pueden ser potencialmente
peligrosos, tienen que ser fiables y tolerantes a fallos.
Por otro lado, no suelen ser muy complejos y precisan
de poca interacción con el usuario. Un sistema de
tiempo real es aquel en el que para que las operaciones
computacionales estén correctas no depende solo de
que la lógica e implementación de los programas
computacionales sea correcto, sino también en el
tiempo en el que dicha operación entregó su resultado.
Si las restricciones de tiempo no son respetadas el
sistema se dice que ha fallado. Un Buen ejemplo es el
de un robot que necesita tomar una pieza de una banda
sinfín. Si el Robot llega tarde, la pieza ya no estará
donde debía recogerla. Por lo tanto el trabajo se llevó
acabo incorrectamente, aunque el robot haya llegado al
lugar adecuado. Si el robot llega antes de que la pieza
llegue, la pieza aun no estará ahí y el robot puede
bloquear su paso.
Software de gestión
El procesamiento de información de gestión constituye,
casi desde los inicios de la informática la mayor de las
áreas de aplicación de los ordenadores. Estos
programas utilizan grandes cantidades de información
almacenadas en bases de datos con objeto de facilitar
las transacciones comerciales o la toma de decisiones.
Además de las tareas convencionales de procesamiento
de datos, en las que el tiempo de procesamiento no es
crítico y los errores pueden ser corregidos a posteriori,
incluyen programas interactivos que sirven de soporte a
transacciones comerciales.
Software científico y de ingeniería
Otro de los campos clásicos de aplicación de la
informática. Se encarga de realizar complejos cálculos
sobre datos numéricos de todo tipo. En este caso la
corrección y exactitud de las operaciones que realizan
es uno de los requisitos básicos que deben de cumplir.
El campo del software científico y de ingeniería se ha
visto ampliado últimamente con el desarrollo de los
sistemas de diseño, ingeniería y fabricación asistida por
ordenador (CAD, CAE y CAM), los simuladores gráficos y
otras aplicaciones interactivas que lo acercan más al
software de tiempo real e incluso al software de
sistemas.
Software de ordenadores personales
El uso de ordenadores personales y de uso doméstico
se ha generalizado a lo largo de la pasada década.
Aplicaciones típicas son los procesadores de textos, las
hojas de cálculo, bases de datos, aplicaciones gráficas,
juegos, etc. Son productos de amplia difusión
orientados a usuarios no profesionales, por lo que entre
sus requisitos se encuentran la facilidad de uso y el
bajo coste. Un ejemplo de este tipo de software es el
paquete de Office.
Software empotrado
Software empotrado es aquel que va instalado en otros
productos industriales, como por ejemplo la electrónica
de consumo, dotando a estos productos de un grado de
inteligencia cada vez mayor. Se aplica a todo tipo de
productos, desde un vídeo doméstico hasta un misil con
cabeza atómica, pasando por algunos sistemas de
control de los automóviles, y realiza funciones muy
diversas, que pueden ir desde complicados cálculos en
tiempo real a sencillas interacciones con el usuario
facilitando el manejo del aparato que los incorpora.
Comparten características con el software de sistemas,
el software de tiempo real, el software de ingeniería y
científico y el software de ordenadores personales. Otro
ejemplo de los productos que utilizan este tipo de
software son los teléfonos celulares.
Software de inteligencia artificial
El software basado en lenguajes procedimentales es útil
para realizar de forma rápida y fiable operaciones que
para el ser humano son tediosas e incluso inabordables.
Sin embargo, es difícilmente aplicable a problemas que
requieran la aplicación de funciones intelectuales más
elevadas, por triviales que nos puedan parecer. El
software de inteligencia artificial trata de dar respuesta
a estas deficiencias, basándose en el uso de lenguajes
declarativos, sistemas expertos y redes neuronales.
Un ejemplo de este software es Smart Airport
Operations Center, programa de logística creado por
Ascent Technology, el cual es utilizado en los
aeropuertos, que computacional-mente, son el mayor
 reto mundial para resolver problemas. Un cambio
(atraso, lluvia, falta de un empleado) genera el efecto
dominó. Con el susodicho software, este pulpo balancea
todos los detalles hasta que todo cuadre.
Son logísticas, pero el problema es más sutil que una
ecuación gigante. No hay manera de “solucionar” un
aeropuerto con sus miles de variables. A cambio, los
algoritmos genéticos usan la selección natural, la
mutación, el cruce de escenarios subóptimos,
permitiendo que el programa encuentre la mejor
opción. La gente hace esto instintivamente en la vida
diaria.
Pero el software eleva la productividad en un 30% en
los aeropuertos que lo usan, eliminando diferentes
engalletamientos.

• Grandes proyectos software son con frecuencia proyectos

únicos.
• Empleo de nuevas técnicas.
• Elevado número de interfases.

1.1.1.4 Documentación

• No se puede llamar gestión a lo que es un proceso

Ad-Hoc:

✔ Sin planes escritos, registros etc.

• Gestión es un proceso documentado :

✔ Si no, no es posible el seguimiento [2]

Hoy en día las valoraciones que se hacen de las

empresas, consideran como aspecto no-financiero
más importante la habilidad de ejecutar la
estrategia de una empresa, y no tanto la calidad de
la estrategia en sí misma.

De acuerdo con un informe de Ernst & Young, de los

factores no financieros más importantes a la hora de
valorar una empresa, el número uno es la habilidad
para ejecutar la estrategia de la empresa, mientras
que la calidad de esta estrategia se encuentra en
tercera posición.

Para confirmar esta idea, podemos ir a un estudio

publicado en la revista Fortune, que dice que
alrededor del 70% de los fallos que cometen los
directivos no están causados por una estrategia
pobre, sino por una ejecución deficiente de la
misma – siendo indecisivos y no cumpliendo con los
compromisos establecidos con los accionistas, los
clientes o los profesionales que trabajan en la
empresa.

El Cuadro de Mando Integral – CMI –

(denominación en castellano de Balanced
Scorecard, desarrollado por Kaplan y Norton a
principios de los años noventa) es una herramienta
de gestión estratégica que apoya la definición,
comunicación y gestión de los objetivos y estrategia
de la empresa. Según el CMI la estrategia de una
empresa puede definirse en función de cuatro
perspectivas como son la financiera, la de clientes,
la de procesos y la de aprendizaje y crecimiento.

BITS (Balanced IT Scorecard)

Los problemas presentados anteriormente se
acentúan en las compañías de Tecnologías de la
Información (TI), donde las barreras de
comunicación causadas por el uso de idiomas muy
distintos entre el departamento de TI y el resto del
negocio, provocan una reducción en el potencial
que las TI tienen para añadir valor a la empresa
identificando nuevas oportunidades de negocio.
Ante esta situación se ve la necesidad de crear un
lenguaje común en la empresa que ofrezca un
marco común de evaluación haciendo uso de los
mismos criterios en toda la empresa. Esto permitirá
que las inversiones en TI y las mejoras que se lleven
a cabo en la empresa estén orientadas a conseguir
objetivos de negocio y que puedan evaluarse en
función de esta aportación al negocio.

Conociendo los principios del CMI debemos

desarrollar una metodología para llevarlos a las
organizaciones de TI, considerando las
peculiaridades de estas empresas.

Podemos definir cinco perspectivas:

Financiera: ¿Cómo añaden valor económico a la

empresa nuestros procesos de desarrollo de
software y la mejora de dichos procesos?

Clientes: ¿Cómo sabemos que nuestros clientes,

internos y externos, están satisfechos?

Procesos ¿funcionan a un nivel suficiente que

satisfaga a los clientes? ¿Cumplen nuestros
 procesos con las expectativas de los clientes?

Personas : Aquí es donde introducimos una de las

diferencias respecto del BSC. Hemos añadido una
perspectiva más; la de personas. ¿Tienen nuestros
empleados las capacidades suficientes para realizar
su trabajo?, ¿Son felices con lo que están haciendo
y donde lo están haciendo?

Infraestructura e innovación: Aquí, para las

organizaciones de TI, queremos gestionar aspectos
relacionados con la mejora de procesos de software,
la tecnología y la infraestructura organizativa, por lo
que deberemos preguntarnos, ¿estamos trabajando
para implantar un programa de mejora sostenible?
Por programa de mejora sostenible entendemos un
programa de mejora continuo en el tiempo que
apoya a la empresa para alcanzar sus objetivos de
negocio, por lo que podremos medir el impacto de
estas mejoras en el negocio y por lo tanto su ROI.

La metodología BITS la componen principalmente

tres elementos

El primero es el Modelo Genérico: consiste en un

conjunto de objetivos genéricos que una empresa
de TI podría querer alcanzar y un conjunto de
conductores para alcanzar estos objetivos, para
cada una de las cinco perspectivas que hemos visto.
Asociados a estos objetivos y conductores (o
factores críticos de éxito) existe un conjunto de
indicadores cuantitativos para realizar el
seguimiento de los mismos.

El segundo componente es el Método, que ofrece

una forma para desarrollar un CMI para una
empresa de modo que en la empresa exista una
alineación entre las iniciativas de mejora de
procesos de software y los objetivos de negocio.

El tercer componente es el Material de Aplicación

del método. Aquí podemos encontrar material de
apoyo a la hora de aplicar el método, como por
ejemplo plantillas que las empresas pueden utilizar,
y que facilitan y aceleran el proceso de desarrollar
un CMI para una empresa.

✔ Tampoco sería posible la realimentación

✔ Y no se podría certificar el proceso de desarrollo.

• Normas de la documentación
 ✔ La documentación (que refleja el proyecto) ha de estar
ligada a una norma .
✔ Esta norma puede estar fijada por la organización o por
un estándar
✔ Una de las primeras tareas de la gestión es adaptar
(tailoring) las normas a la naturaleza y dimensiones del
proyecto.

1.1.2 TAREAS, PLANES Y ACTIVIDADES

1.1.2.1 Tareas:

1.1.2.1.2 Planificar el proyecto

• Fija objetivos, tiempos, recursos, normas, técnicas, etc.

(VER TEMA 2.1)

1.1.2.1.3 Controlar el proyecto

• Se realizan seguimientos, análisis, pruebas de los

elementos antes indicados .
• Se toman las acciones correctivas.
• Todo ello reflejado en los planes anteriores.

1.1.2.2 Planes :

• Plan de desarrollo software (ANEXO 01)

• Plan de configuración software (ANEXO 02)
• Plan de calidad de software
• Plan de verificación y validación
• Plan de mantenimiento
• Plan de desarrollo del personal
• Plan de despliegue.

1.1.2.3 Actividades de control del proyecto:

• Gestión de requisitos
• Establecimiento de plan de trabajo y Monitorización
progreso
• Gestión de la garantía de calidad de producto y de
proceso
• Gestión de la configuración
• Gestión del cambio
• Gestión del riesgo
• Selección y formación del personal
• Gestión de suministradores
• Medida y análisis
• Informe y presentaciones

1.1.3 ROLES, JEFE/GESTOR Y ORGANIZACIÓN DEL EQUIPO DE

DESARROLLO:CERRADO, ALEATORIO, ABIERTO, SINCRONIZADO
1.1.3.1 Roles asociados a las tareas

1.1.3.1.1 Roles mínimos

• Jefe o gestor de proyecto.

• Resp. de configuración.
• Resp. de calidad.
• Resp. de desarrollo.

1.1.3.1.2 Roles dependiendo de la aplicación

• Resp. de despliegue.
• Resp. de mantenimiento.
• Resp. de librerías.
• Resp. de la base de datos.
• Resp. de safety/seguridad.

1.1.3.2 Jefe/Gestor del proyecto software

• Responsable de la gestión del proyecto

• Supervisa la adherencia de los procesos a los
estándares y normas fijados en el proyecto.

• Responsable de la planificación y programación de

eventos.
• Controla el proyecto para mantenerlo dentro de
los márgenes de tiempo y presupuesto

1.1.3.3 Organización del equipos de desarrollo

Paradigma cerrado

Estructura jerárquica tradicional de autoridad

(proyectos de los que hay un gran conocimiento
previo ).

Aleatorio

El equipo se estructura libremente en función de la

iniciativa del personal. Funcionan bien en entornos
tecnológicos muy innovadores pero chocan cuando hay
que conseguir un rendimiento ordenado. No facilita la
asunción de responsabilidades.

Abierto

Conjuga los dos anteriores.

Se incluyen muchas vías de comunicación y toma de
decisiones consensuadas. Adecuados para la resolución
de problemas complejos pero no tienen tanto
rendimiento como el cerrado.
 Sincronizado

Se divide el problema en partes disjuntas de forma

natural, con una organización clara pero con poca
comunicación entre ellas.

1.1.4 NORMAS, ESTÁNDARES Y HERRAMIENTAS

1.1.4.1 Normas y estándares

1.1.4.1.1 Planificación

• PSS-05 - ECSS-E-40A

1.1.4.1.2 Calidad

• Iso 9001- CMM y CMMI - Capability Maturity Model

Integration

1.1.4.1.3 Ciclo de vida

• RUP - Rational Unified Process: Modelo de desarrollo

basado en su diagrama de ballenas.

• Las normas IEEE 1074 e ISO 12207-1 enfocan el

término de forma muy similar considerando una
actividad como un conjunto de tareas y una tarea como
una acción que transforman entradas en salidas.

1.1.4.2 Herramientas

1.1.4.2.1 Planificación

• REVIC y SOFTEST del USAAF

1.1.4.2.2 Control de la configuración

La Gestión de Configuración del Software (GCS) es un

conjunto de actividades desarrolladas para gestionar los
cambios a lo largo del ciclo de vida del software. Es una
actividad de garantía de calidad que se aplica en todas
las fases del proceso de ingeniería del software.

• CVS o ClearQuest

1.1.4.2.3 Control del versiones [3]

Un sistema de control de versiones debe proporcionar:

• Mecanismo de almacenaje de los elementos que
deba gestionar (ej. archivos de texto, imágenes,
documentación...)
 • Posibilidad de realizar cambios sobre los
elementos almacenados (ej. modificaciones
parciales, añadir, borrar, renombrar o mover
elementos)
• Registro histórico de las acciones realizadas con
cada elemento o conjunto de elementos
(normalmente pudiendo volver o extraer un
estado anterior del producto)
Aunque no es estrictamente necesario, suele ser muy
útil la generación de informes con los cambios
introducidos entre dos versiones, informes de estado,
marcado con nombre identificativo de la versión de un
conjunto de ficheros, etcétera.

• CVS, Subversion, SourceSafe, ClearCase, Darcs, Plastic

SCM, Git, Mercurial, etc.

1.1.4.2.4 Ciclo de vida

• Rational Enterprise Edition , Rational SoDA, Rational

Suite

1.2. PLANIFICACION

1.2.1 PLANIFICACIÓN: (MARCO DESARROLLO, COSTO, PLAN,

RIESGOS), RELACIÓN CON REQUISITOS, QUE DEFINE
(MARCO, PLANES, ACTIVIDADES).

1.2.1.1 Planificación:

Marco de desarrollo del proyecto

Definición a alto nivel de normas, estándares,
herramientas, etc.
Costo del proyecto
Consistirá en analizar los productos y el tiempo y
recursos que en abstracto tiene su desarrollo

Plan de trabajo
Se realizan las asignaciones de personal, tiempos
y recursos.

Riesgos
Gestión de riesgos

1.2.1.2 Función de los requisitos

Tiene que tener en cuenta los requisitos en sentido

amplio:
• Los que provienen de los stakeholders (los
interesados).
• Los que provienen del entorno de la propia
organización.
 1.2.1.3 Definiciones
• Definir un marco de referencia

• Definir un plan (ANEXO 03)

✔ Reflejado en un documento de planificación

✔ Este es un documento necesariamente vivo por lo
que se han de plantear los recursos para ellos.

• Actividades

1.2.2 MARCO GENERAL: ALCANCE, NORMAS, EQUIPO,

CONTROL Y HERRAMIENTAS

1.2.2.1 Alcance
• Definición de los objetivos y prioridades
• Definición de los productos finales en alto nivel
• Definición de Entregables

✔ Entregables hardware
✔ Entregables software
✔ Entregables de documentación

• Definición de límites e interfases con otras empresas.

1.2.2.2 Normas y referencias: customización

• Normas o estándares a emplear
• Adaptación de dichas normas al presente
proyecto
• Elección del Modelo de proceso de desarrollo
• Metodologías utilizadas

1.2.2.3 Organización del equipo

• Definición de la Estructura organizativa
• A nivel de asignación de los roles definidos en el
SQAP

Software Quality Assurance Plan o SQAP (es

decir, Plan de Garantía de Calidad de Software)
es un documento que organiza el desarrollo del
software con el fin de que el proceso de creación
de este siga unas pautas que aseguren la calidad
del resultado. Este plan de garantía forma parte
de la Ingeniería de software. En este documento
se organiza el equipo de personas, se elige el
ciclo de vida a seguir, se especifican los
documentos que harán falta, las revisiones que
se harán, las pruebas e incluso cómo realizar el
mantenimiento. (ANEXO 04)
 1.2.2.4 Mecanismos de monitorización y control

• Mecanismos de control y seguimiento en función

de lo definido en el SQAP
• Establecimiento de reuniones de seguimiento de
proyecto
• Reuniones internas de seguimiento del proyecto.
• Reuniones de hitos.
• Definición de informes de progreso
• Definición del registro de comunicaciones
• Control de suministradores

1.2.3 ANÁLISIS DEL COSTE: TAREAS DE DESARROLLO

(CSCI/CSC, ETIMACIÓN, AJUSTE, HISTORICO), NO
DESARROLLO, AJUSTE PRESUPUESTARIO

1.2.3.1 Descomposición de las tareas no directamente

de desarrollo

• Documentación
• Control
• Test
• Plan más allá del desarrollo

✔ No siempre se contemplan, a veces se posponen

✔ Definición de plan de despliegue
✔ Definición de las actividades de Mantenimiento

• Adquisición y recepción de recursos materiales

1.2.3.2 Descomposición de las tareas de desarrollo

1.2.3.2.1 Definición de Paquetes de Trabajo en

CSCI/CSC (Computer Software Configuration
Item/Computer Software Component)

• Fuente para su definición:

✔ Los requisitos
✔ Las normas (que fijan productos concretos)
✔ Los mecanismos de control
✔ La discusión entre ellos.

1.2.3.2.2 Estimación de horas/hombre por

paquete de trabajo

Para ello es necesario utilizar herramientas

basadas en modelos como COCOMO, COCOMO 2
o REVIC

Como funciona REVIC:

 • Se introduce el conjunto de CSCI/CSC del
proyecto

• Se realiza una estimación del número de

líneas de código de cada componente,
normalmente se introduce una distribución
estadística.

• A continuación se fijan unos parámetros

globales del proyecto como:

✔ Experiencia, criticidad,
aerotransportado, etc.

• El programa proporcionará una distribución

en valor medio (incluso varianza) .

1.2.4 PLAN DE TRABAJO: RECURSOS HUMANOS Y

MATERIALES, HITOS, ANÁLISIS, CAMINOS CRÍTICOS Y
TÉCNICAS

1.2.4.1 Recursos humanos

• Organizar el equipo de trabajo en función de la

norma y en función del volumen del proyecto.
• Asignar las horas/hombre al equipo de trabajo.
• Asignación de Responsabilidades a cada uno de
los paquetes. de trabajo.
• Formación.

1.2.4.2 Recursos materiales

• Reparto de los existentes

• Planes de adquisición

1.2.4.3 Estudiar caminos críticos

1.2.4.3.1 Tecnicas

GANTT [4]

En gestión de proyectos, el diagrama de Gantt

muestra el origen y el final de las diferentes
unidades mínimas de trabajo y los grupos de
tareas (llamados summary elements en la
imagen) o las dependencias entre unidades
mínimas de trabajo (no mostradas en la imagen).
Desde su introducción los diagramas de Gantt se
han convertido en una herramienta básica en la
 gestión de proyectos de todo tipo, con la finalidad
de representar las diferentes fases, tareas y
actividades programadas como parte de un
proyecto o para mostrar una línea de tiempo en
las diferentes actividades haciendo el método
más eficiente.

PERT [5]

Una malla PERT permite planificar y controlar el

desarrollo de un proyecto. A diferencia de las
redes CPM, las redes PERT trabajan con tiempos
probabilísticos. Normalmente para desarrollar un
proyecto específico lo primero que se hace es
determinar, en una reunión multidisciplinaria,
cuáles son las actividades que se deberá ejecutar
para llevar a feliz término el proyecto, cuál es la
precedencia entre ellas y cuál será la duración
esperada de cada una.

II. METODOLOGÍA DE DESARROLLO DE SOFTWARE

2.1 METODOLOGÍA Y PROCESO DE DESARROLLO DE SOFTWARE

Un proceso de desarrollo de software tiene como propósito la

producción eficaz y eficiente de un producto software que reúna los
requisitos del cliente. Dicho proceso, en términos globales se muestra
en la Figura 2 [3]. Este proceso es intensamente intelectual, afectado
por la creatividad y juicio de las personas involucradas [4]. Aunque un
proyecto de desarrollo de software es equiparable en muchos aspectos
a cualquier otro proyecto de ingeniería, en el desarrollo de software hay
una serie de desafíos adicionales, relativos esencialmente a la
naturaleza del producto obtenido. A continuación se explican algunas
particularidades asociadas al desarrollo de software y que influyen en
su proceso de construcción.
Un producto software en sí es complejo, es prácticamente inviable
conseguir un 100% de confiabilidad de un programa por pequeño que
sea. Existe una inmensa combinación de factores que impiden una
verificación exhaustiva de las todas posibles situaciones de ejecución
que se puedan presentar (entradas, valores de variables, datos
almacenados, software del sistema, otras aplicaciones que intervienen,
el hardware sobre el cual se ejecuta, etc.).
Un producto software es intangible y por lo general muy abstracto, esto
dificulta la definición del producto y sus requisitos, sobre todo cuando
no se tiene precedentes en productos software similares. Esto hace que
los requisitos sean difíciles de consolidar tempranamente. Así, los
cambios en los requisitos son inevitables, no sólo después de
entregado en producto sino también durante el proceso de desarrollo.
Además, de las dos anteriores, siempre puede señalarse la inmadurez
de la ingeniería del software como disciplina, justificada por su corta
vida comparada con otras disciplinas de la ingeniería. Sin embargo,
esto no es más que un inútil consuelo.

Requisitos nuevos Sistema nuevo

o modificados o modificado
Proceso de Desarrollo
de Software

Figura 1: proceso de desarrollo de software.

El proceso de desarrollo de software no es único. No existe un proceso

de software universal que sea efectivo para todos los contextos de
proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar
todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un
conjunto de actividades fundamentales que se encuentran presentes
en todos ellos [4]:
1. Especificación de software: Se debe definir la funcionalidad y
restricciones operacionales que debe cumplir el software.
2. Diseño e Implementación: Se diseña y construye el software
de acuerdo a la especificación.
3. Validación: El software debe validarse, para asegurar que
cumpla con lo que quiere el cliente.
4. Evolución: El software debe evolucionar, para adaptarse a las
 necesidades del cliente.
Además de estas actividades fundamentales, Pressman [1] menciona
un conjunto de “actividades protectoras”, que se aplican a lo largo de
todo el proceso del software. Ellas se señalan a continuación:
• Seguimiento y control de proyecto de software.
• Revisiones técnicas formales.
• Garantía de calidad del software.
• Gestión de configuración del software.
• Preparación y producción de documentos.
• Gestión de reutilización.
• Mediciones.
• Gestión de riesgos.
Pressman [1] caracteriza un proceso de desarrollo de software como se
muestra en la Figura 3. Los elementos involucrados se describen a
continuación:
• Un marco común del proceso, definiendo un pequeño número de
actividades del marco de trabajo que son aplicables a todos los
proyectos de software, con independencia del tamaño o complejidad.
• Un conjunto de tareas, cada uno es una colección de tareas de
ingeniería del software, hitos de proyectos, entregas y productos de
trabajo del software, y puntos de garantía de calidad, que permiten
que las actividades del marco de trabajo se adapten a las
características del proyecto de software y los requisitos del equipo
del proyecto.
• Las actividades de protección, tales como garantía de calidad del
software, gestión de configuración del software y medición, abarcan
el modelo del proceso. Las actividades de protección son
independientes de cualquier actividad del marco de trabajo y
aparecen durante todo el proceso.

Figura 2: Elementos del proceso del software

Otra perspectiva utilizada para determinar los elementos del proceso

 de desarrollo de software es establecer las relaciones entre elementos
que permitan responder Quién debe hacer Qué, Cuándo y Cómo
debe hacerlo [5].

Figura 3: Relación entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollo

de software y sus relaciones. Así las interrogantes se responden de la
siguiente forma:
• Quién: Las Personas participantes en el proyecto de desarrollo
desempeñando uno o más Roles específicos.

• Qué: Un Artefacto1 es producido por un Rol en una de sus

Actividades. Los Artefactos se especifican utilizando Notaciones
específicas. Las Herramientas apoyan la elaboración de Artefactos
soportando ciertas Notaciones.
• Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a
cabo un Rol durante el proceso de desarrollo. El avance del proyecto
está controlado mediante hitos que establecen un determinado
estado de terminación de ciertos Artefactos.
La composición y sincronía de las actividades está basada en un
conjunto de Principios y Prácticas. Las Prácticas y Principios enfatizan
ciertas actividades y/o la forma como deben realizarse, por ejemplo:
desarrollar iterativamente, gestionar requisitos, desarrollo basado en
componentes, modelar visualmente, verificar continuamente la calidad,
gestionar los cambios, etc.

2.1.1. Modelos de proceso software

Sommerville [4] define modelo de proceso de software como “Una
representación simplificada de un proceso de software,
representada desde una perspectiva específica. Por su naturaleza
1
Un artefacto es una pieza de información que (1) es producida, modificada o usada por el proceso, (2) define un
área de responsabilidad para un rol y (3) está sujeta a control de versiones. Un artefacto puede ser un modelo, un
elemento de modelo o un documento.
los modelos son simplificados, por lo tanto un modelo de procesos
del software es una abstracción de un proceso real.”
Los modelos genéricos no son descripciones definitivas de procesos
de software; sin embargo, son abstracciones útiles que pueden ser
utilizadas para explicar diferentes enfoques del desarrollo de
software.
Modelos que se van a discutir a continuación:
• Codificar y corregir
• Modelo en cascada
• Desarrollo evolutivo
• Desarrollo formal de sistemas
• Desarrollo basado en reutilización
• Desarrollo incremental
• Desarrollo en espiral

2.1.1.1. Codificar y corregir (Code-and-Fix)

Este es el modelo básico utilizado en los inicios del desarrollo
de software. Contiene dos pasos:
• Escribir código.
• Corregir problemas en el código.
Se trata de primero implementar algo de código y luego
pensar acerca de requisitos, diseño, validación, y
mantenimiento.
Este modelo tiene tres problemas principales [7]:
• Después de un número de correcciones, el código puede
tener una muy mala estructura, hace que los arreglos sean
muy costosos.
• Frecuentemente, aún el software bien diseñado, no se
ajusta a las necesidades del usuario, por lo que es
rechazado o su reconstrucción es muy cara.
• El código es difícil de reparar por su pobre preparación para
probar y modificar.

2.1.1.2. Modelo en cascada

El primer modelo de desarrollo de software que se publicó se
derivó de otros procesos de ingeniería [8]. Éste toma las
actividades fundamentales del proceso de especificación,
desarrollo, validación y evolución y las representa como fases
separadas del proceso.
El modelo en cascada consta de las siguientes fases:
• Definición de los requisitos: Los servicios, restricciones
y objetivos son establecidos con los usuarios del
 sistema. Se busca hacer esta definición en detalle.
• Diseño de software: Se particiona el sistema en
sistemas de software o hardware. Se establece la
arquitectura total del sistema. Se identifican y
describen las abstracciones y relaciones de los
componentes del sistema.
• Implementación y pruebas unitarias: Construcción de
los módulos y unidades de software. Se realizan
pruebas de cada unidad.

• Integración y pruebas del sistema: Se integran todas

las unidades. Se prueban en conjunto. Se entrega el
conjunto probado al cliente.
• Operación y mantenimiento: Generalmente es la fase
más larga. El sistema es puesto en marcha y se realiza
la corrección de errores descubiertos. Se realizan
mejoras de implementación. Se identifican nuevos
requisitos.
La interacción entre fases puede observarse en la Figura 5.
Cada fase tiene como resultado documentos que deben ser
aprobados por el usuario.
Una fase no comienza hasta que termine la fase anterior y
generalmente se incluye la corrección de los problemas
encontrados en fases previas.

Figura 4: Modelo de desarrollo en cascada.

En la práctica, este modelo no es lineal, e involucra varias
iteraciones e interacción entre las distintas fases de
desarrollo. Algunos problemas que se observan en el modelo
de cascada son:
• Las iteraciones son costosas e implican rehacer trabajo
debido a la producción y aprobación de documentos.
• Aunque son pocas iteraciones, es normal congelar parte del
desarrollo y continuar con las siguientes fases.
• Los problemas se dejan para su posterior resolución, lo que
 lleva a que estos sean ignorados o corregidos de una forma
poco elegante.
• Existe una alta probabilidad de que el software no cumpla
con los requisitos del usuario por el largo tiempo de
entrega del producto.
• Es inflexible a la hora de evolucionar para incorporar
nuevos requisitos. Es difícil responder a cambios en los
requisitos.
Este modelo sólo debe usarse si se entienden a plenitud los
requisitos. Aún se utiliza como parte de proyectos grandes.

2.1.1.3. Desarrollo evolutivo

La idea detrás de este modelo es el desarrollo de una
implantación del sistema inicial, exponerla a los comentarios
del usuario, refinarla en N versiones hasta que se desarrolle
el sistema adecuado. En la Figura 6 se observa cómo las
actividades concurrentes: especificación, desarrollo y
validación, se realizan durante el desarrollo de las versiones
hasta llegar al producto final.
Una ventaja de este modelo es que se obtiene una rápida
realimentación del usuario, ya que las actividades de
especificación, desarrollo y pruebas se ejecutan en cada
iteración.

Figura 5: Modelo de desarrollo evolutivo.

Existen dos tipos de desarrollo evolutivo:

• Desarrollo Exploratorio: El objetivo de este enfoque es
explorar con el usuario los requisitos hasta llegar a un
sistema final. El desarrollo comienza con las partes que se
tiene más claras. El sistema evoluciona conforme se
añaden nuevas características propuestas por el usuario.
• Enfoque utilizando prototipos: El objetivo es entender los
requisitos del usuario y trabajar para mejorar la calidad de
los requisitos. A diferencia del desarrollo exploratorio, se
comienza por definir los requisitos que no están claros para
el usuario y se utiliza un prototipo para experimentar con
ellos. El prototipo ayuda a terminar de definir estos
 requisitos.
Entre los puntos favorables de este modelo están:
• La especificación puede desarrollarse de forma creciente.
• Los usuarios y desarrolladores logran un mejor
entendimiento del sistema. Esto se refleja en una mejora
de la calidad del software.
• Es más efectivo que el modelo de cascada, ya que cumple
con las necesidades inmediatas del cliente.
Desde una perspectiva de ingeniería y administración se
identifican los siguientes problemas:
• Proceso no Visible: Los administradores necesitan entregas
para medir el progreso. Si el sistema se necesita desarrollar
rápido, no es efectivo producir documentos que reflejen
cada versión del sistema.
• Sistemas pobremente estructurados: Los cambios
continuos pueden ser perjudiciales para la estructura del
software haciendo costoso el mantenimiento.
• Se requieren técnicas y herramientas: Para el rápido
desarrollo se necesitan herramientas que pueden ser
incompatibles con otras o que poca gente sabe utilizar.
Este modelo es efectivo en proyectos pequeños (menos de
100.000 líneas de código) o medianos (hasta 500.000 líneas
de código) con poco tiempo para su desarrollo y sin generar
documentación para cada versión.
Para proyectos largos es mejor combinar lo mejor del modelo
de cascada y evolutivo: se puede hacer un prototipo global
del sistema y posteriormente reimplementarlo con un
acercamiento más estructurado. Los subsistemas con
requisitos bien definidos y estables se pueden programar
utilizando cascada y la interfaz de usuario se puede
especificar utilizando un enfoque exploratorio.

2.1.1.4. Desarrollo formal de sistemas

Este modelo se basa en transformaciones formales de los
requisitos hasta llegar a un programa ejecutable.

Figura 6: Paradigma de programación automática.

La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal
de programación automática. Se distinguen dos fases
globales: especificación (incluyendo validación) y
transformación. Las características principales de este
paradigma son: la especificación es formal y ejecutable
constituye el primer prototipo del sistema), la especificación
es validada mediante prototipación. Posteriormente, a través
de transformaciones formales la especificación se convierte
 en la implementación del sistema, en el último paso de
transformación se obtiene una implementación en un
lenguaje de programación determinado. , el mantenimiento
se realiza sobre la especificación (no sobre el código fuente),
la documentación es generada automáticamente y el
mantenimiento es realizado por repetición del proceso (no
mediante parches sobre la implementación).
Observaciones sobre el desarrollo formal de sistemas:
• Permite demostrar la corrección del sistema durante el
proceso de transformación. Así, las pruebas que verifican la
correspondencia con la especificación no son necesarias.
• Es atractivo sobre todo para sistemas donde hay requisitos
de seguridad y confiabilidad importantes.
• Requiere desarrolladores especializados y experimentados
en este proceso para llevarse a cabo.

2.1.1.5. Desarrollo basado en reutilización

Como su nombre lo indica, es un modelo fuertemente
orientado a la reutilización. Este modelo consta de 4 fases
ilustradas en la Figura 9. A continuación se describe cada
fase:
1. Análisis de componentes: Se determina qué componentes
pueden ser utilizados para el sistema en cuestión. Casi
siempre hay que hacer ajustes para adecuarlos.
2. Modificación de requisitos: Se adaptan (en lo posible) los
requisitos para concordar con los componentes de la etapa
anterior. Si no se puede realizar modificaciones en los
requisitos, hay que seguir buscando componentes más
adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el
marco de trabajo para el sistema. Se debe tener en cuenta
los componentes localizados en la fase 2 para diseñar o
determinar este marco.
4. Desarrollo e integración: El software que no puede
comprarse, se desarrolla. Se integran los componentes y
subsistemas. La integración es parte del desarrollo en lugar
de una actividad separada.

Las ventajas de este modelo son:

• Disminuye el costo y esfuerzo de desarrollo.

• Reduce el tiempo de entrega.
• Disminuye los riesgos durante el desarrollo.
 Figura 7: Desarrollo basado en reutilización de
componentes

Desventajas de este modelo:

• Los “compromisos” en los requisitos son inevitables,
por lo cual puede que el software no cumpla las
expectativas del cliente.
• Las actualizaciones de los componentes adquiridos
no están en manos de los desarrolladores del
sistema.

2.1.2. Procesos iterativos

A continuación se expondrán dos enfoques híbridos, especialmente
diseñados para el soporte de las iteraciones:
• Desarrollo Incremental.
• Desarrollo en Espiral.

2.1.2.1 Desarrollo incremental

Mills [9] sugirió el enfoque incremental de desarrollo como
una forma de reducir la repetición del trabajo en el proceso
de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el
sistema (ver Figura 10). Es una combinación del Modelo de
Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y
da oportunidad para retrasar las decisiones hasta tener
experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el
modelo de cascada o evolutivo, dependiendo del
conocimiento que se tenga sobre los requisitos a
implementar. Si se tiene un buen conocimiento, se puede
optar por cascada, si es dudoso, evolutivo.
 Figura 8: Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental se

encuentran:
• Los clientes no esperan hasta el fin del desarrollo para
utilizar el sistema. Pueden empezar a usarlo desde el
primer incremento.
• Los clientes pueden aclarar los requisitos que no tengan
claros conforme ven las entregas del sistema.
• Se disminuye el riesgo de fracaso de todo el proyecto, ya
que se puede distribuir en cada incremento.
• Las partes más importantes del sistema son entregadas
primero, por lo cual se realizan más pruebas en estos
módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo
son:
• Cada incremento debe ser pequeño para limitar el riesgo
(menos de 20.000 líneas).
• Cada incremento debe aumentar la funcionalidad.
• Es difícil establecer las correspondencias de los requisitos
contra los incrementos.
• Es difícil detectar las unidades o servicios genéricos para
todo el sistema.

2.1.2.2 Desarrollo en espiral

El modelo de desarrollo en espiral (ver Figura 11) es
actualmente uno de los más conocidos y fue propuesto por
Boehm [7]. El ciclo de desarrollo se representa como una
espiral, en lugar de una serie de actividades sucesivas con
retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definición de objetivos: Se definen los objetivos. Se definen
las restricciones del proceso y del producto. Se realiza un
diseño detallado del plan administrativo. Se identifican los
riesgos y se elaboran estrategias alternativas dependiendo
de estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis
 detallado de cada riesgo identificado. Pueden desarrollarse
prototipos para disminuir el riesgo de requisitos dudosos.
Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo
después de la evaluación del riesgo. El modelo que se
utilizará (cascada, sistemas formales, evolutivo, etc.)
depende del riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se
planea la siguiente fase del proyecto.
Este modelo a diferencia de los otros toma en consideración
explícitamente el riesgo, esta es una actividad importante en
la administración del proyecto.

El ciclo de vida inicia con la definición de los objetivos. De

acuerdo a las restricciones se determinan distintas
alternativas. Se identifican los riesgos al sopesar los objetivos
contra las alternativas. Se evalúan los riesgos con actividades
como análisis detallado, simulación, prototipos, etc. Se
desarrolla un poco el sistema. Se planifica la siguiente fase.

Figura 9: Modelo de desarrollo en Espiral

2.2. ¿Cuál es el modelo de proceso más adecuado?

Cada proyecto de software requiere de una forma de particular de
abordar el problema. Las propuestas comerciales y académicas
actuales promueven procesos iterativos, donde en cada iteración puede
utilizarse uno u otro modelo de proceso, considerando un conjunto de
criterios (Por ejemplo: grado de definición de requisitos, tamaño del
proyecto, riesgos identificados, entre otros).
En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos
criterios básicos para la selección de un modelo de proceso [10], la
medida utilizada indica el nivel de efectividad del modelo de proceso de
acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un
nivel de efectividad Bajo cuando los Requisitos y arquitectura no están
predefinidos ):
 Vi
si
ón
de
l
F pr
unci og
ona re
con so
Permit
requ Produ po
e
isito ce Gesti r
Mode correc
s y softw ón el
lo de ciones
arqu are de Cli
proce sobre
itect altam riesg en
so la
ura ente os te
march
no fiable y
a
pre el
defi Jef
nido e
s de
l
pr
oy
ec
to

Codifi
Me
car y
Bajo Bajo Bajo Alto di
corre
o
gir

Casca Ba
Bajo Alto Bajo Bajo
da jo

Me
Evolu
di
tivo Medi
Medio Medi Medio o o
explo o o
o Alto o Alto o
ratori Alto
Alt
o
o

Evolu
tivo
Medi A
proto Alto Medio Alto
o lto
tipad
o

Desar
rollo Bajo
forma a Ba
Bajo Alto Bajo
l de Medi jo
siste o
mas
Desar
rollo
orien Bajo
tado Medi Bajo a a A
Alto
a o Alto Medi lto
reutil o
izació
n

Incre
Medi Ba
ment Bajo Alto Bajo
o jo
al

Me
Espir
Alto Alto Alto Medio di
al
o

Tabla 1: Comparación entre modelos de proceso de software.

2.3. Metodologías para desarrollo de software

Un proceso de software detallado y completo suele denominarse

“Metodología”. Las metodologías se basan en una combinación de los
modelos de proceso genéricos (cascada, evolutivo, incremental, etc.).
Adicionalmente una metodología debería definir con precisión los
artefactos, roles y actividades involucrados, junto con prácticas y
técnicas recomendadas, guías de adaptación de la metodología al
proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente
se utiliza el término “método” para referirse a técnicas, notaciones y
guías asociadas, que son aplicables a una (o algunas) actividades del
proceso de desarrollo, por ejemplo, suele hablarse de métodos de
análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea
sencilla debido a la diversidad de propuestas y diferencias en el grado
de detalle, información disponible y alcance de cada una de ellas. A
grandes rasgos, si tomamos como criterio las notaciones utilizadas para
especificar artefactos producidos en actividades de análisis y diseño,
podemos clasificar las metodologías en dos grupos: Metodologías
Estructuradas y Metodologías Orientadas a Objetos. Por otra parte,
considerando su filosofía de desarrollo, aquellas metodologías con
mayor énfasis en la planificación y control del proyecto, en
especificación precisa de requisitos y modelado, reciben el apelativo de
Metodologías Tradicionales (o peyorativamente denominada
Metodologías Pesadas, o Peso Pesado). Otras metodologías,
denominadas Metodologías Ágiles, están más orientadas a la
generación de código con ciclos muy cortos de desarrollo, se dirigen a
equipos de desarrollo pequeños, hacen especial hincapié en aspectos
humanos asociados al trabajo en equipo e involucran activamente al
cliente en el proceso. A continuación se revisan brevemente cada una
de estas categorías de metodologías.

2.3.1. Metodologías estructuradas

Los métodos estructurados comenzaron a desarrollarse a
 fines de los 70’s con la Programación Estructurada, luego a
mediados de los 70’s aparecieron técnicas para el Diseño (por
ejemplo: el diagrama de Estructura) primero y posteriormente
para el Análisis (por ejemplo: Diagramas de Flujo de Datos).
Estas metodologías son particularmente apropiadas en
proyectos que utilizan para la implementación lenguajes de
3ra y 4ta generación.
Ejemplos de metodologías estructuradas de ámbito
gubernamental: MERISE2 (Francia), MÉTRICA3 (España),
SSADM4 (Reino Unido). Ejemplos de propuestas de métodos
estructurados en el ámbito académico: Gane & Sarson5, Ward
& Mellor6, Yourdon & DeMarco7 e Information Engineering8.

2.3.2. Metodologías orientadas a objetos

Su historia va unida a la evolución de los lenguajes de
programación orientada a objeto, los más representativos: a
fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la
primera versión de C++ por Bjarne Stroustrup en 1981 y
actualmente Java9 o C# de Microsoft. A fines de los 80’s
comenzaron a consolidarse algunos métodos Orientadas a
Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado
con la ambiciosa idea de conseguir una unificación de sus
métodos y notaciones, que posteriormente se reorienta a un
objetivo más modesto, para dar lugar al Unified Modeling
Language (UML)10, la notación OO más popular en la
actualidad.
Algunos métodos OO con notaciones predecesoras de UML
son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler
& Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la
notación UML son: Rational Unified Process (RUP)11, OPEN12,
MÉTRICA (que también soporta la notación estructurada).

2.3.3. Metodologías tradicionales (no ágiles)

Las metodologías no ágiles son aquellas que están guiadas
por una fuerte planificación durante todo el proceso de
desarrollo; llamadas también metodologías tradicionales o
2
http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002)
3
http://www.map.es/csi/metrica3/ (7.5.2003)
4
http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003)
5
http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc (29.8.2003)
6
http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003)
7
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco (29.8.2003)
8
http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html
(29.8.2003)
9
http://java.sun.com/ (7.5.2003)
10
http://www.uml.org/ (7.5.2003)
11
http://www.rational.com/products/rup/index.jsp (7.5.2003)
12
http://www.open.org.au/ (17.9.2003)
 clásicas, donde se realiza una intensa etapa de análisis y
diseño antes de la construcción del sistema.
Todas las propuestas metodológicas antes indicadas pueden
considerarse como metodologías tradicionales. Aunque en el
caso particular de RUP, por el especial énfasis que presenta
en cuanto a su adaptación a las condiciones del proyecto
(mediante su configuración previa a aplicarse), realizando
una configuración adecuada, podría considerarse Ágil.

2.3.4. Metodologías ágiles

Un proceso es ágil cuando el desarrollo de software es
incremental (entregas pequeñas de software, con ciclos
rápidos), cooperativo (cliente y desarrolladores trabajan
juntos constantemente con una cercana comunicación),
sencillo (el método en sí mismo es fácil de aprender y
modificar, bien documentado), y adaptable (permite realizar
cambios de último momento) [11].
Entre las metodologías ágiles identificadas en [11]:
• Extreme Programming [6].
• Scrum ([12], [13]).
• Familia de Metodologías Crystal [14].
• Feature Driven Development [15].
• Proceso Unificado Rational, una
configuración ágil ([16]).
• Dynamic Systems Development Method
[17].
• Adaptive Software Development [18].
• Open Source Software Development [19].

2.3.4.1. Programación extrema

La programación extrema se diferencia de las
metodologías tradicionales principalmente en que pone
más énfasis en la adaptabilidad que en la previsibilidad.
Los defensores de XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural,
inevitable e incluso deseable del desarrollo de
proyectos. Creen que ser capaz de adaptarse a los
cambios de requisitos en cualquier punto de la vida del
proyecto es una aproximación mejor y más realista que
intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos después en controlar los
cambios en los requisitos.
 Características13

• Desarrollo iterativo e incremental

• Pruebas unitarias continuas
• Programación en parejas
• integración del equipo de programación con el
cliente
• Corrección de todos los errores
• Refactorización del código
• Propiedad del código compartida
• Simplicidad en el código

2.3.4.2. Scrum
Scrum es un proceso de desarrollo de software iterativo
e incremental utilizado comúnmente en entornos
basado en la metodología Agile de desarrollo de
software.
Scrum es un proceso marco que incluye un conjunto de
prácticas y roles predefinidos. Los roles principales en
Scrum son el ScrumMaster, que mantiene los procesos
y trabaja de forma similar al director de proyecto, el
ProductOwner, que representa a los stakeholders
(clientes externos o internos), y el Team que incluye a
los desarrolladores.
Durante cada sprint, un periodo entre 15 y 30 días (la
longitud es definida por el equipo), el equipo crea un
incremento de software potencialmente entregable
(utilizable). El conjunto de características que forma
parte de cada sprint viene del product backlog, que es
un conjunto de requisitos de alto nivel priorizados que
dan forma al trabajo a realizar. Los elementos del
backlog que forman parte del sprint se determinan
durante la reunión de sprint planning. Durante esta
reunión, el Product Owner informa al equipo de los
elementos en el product backlog que quiere ver
completados. El equipo entonces determina la cantidad
de ese trabajo que puede comprometerse a completar
durante el siguiente sprint.[4] Durante el sprint, nadie
puede cambiar el sprint backlog, lo que significa que los
requisitos están congelados durante el sprint.
Existen varias implementaciones de sistemas para
gestionar el proceso de Scrum, que van desde notas
amarillas "post-it" y pizarras hasta paquetes de
software. Una de las mayores ventajas de Scrum es que
es muy fácil de aprender, y requiere muy poco esfuerzo
13
http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema
 para comenzarse a utilizar.

2.3.4.3. Proceso Unificado de Rational

Es un proceso de desarrollo de software y junto con el
Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas
orientados a objetos.
El RUP no es un sistema con pasos firmemente
establecidos, sino un conjunto de metodologías
adaptables al contexto y necesidades de cada
organización.
También se conoce por este nombre al software
desarrollado por Rational, hoy propiedad de IBM, el cual
incluye información entrelazada de diversos artefactos
y descripciones de las diversas actividades. Está
incluido en el Rational Method Composer (RMC), que
permite la personalización de acuerdo a necesidades.

2.3.4.4. Métrica V314

La metodología MÉTRICA Versión 3 ofrece a las
Organizaciones un instrumento útil para la
sistematización de las actividades que dan soporte al
ciclo de vida del software dentro del marco que permite
alcanzar los siguientes objetivos:
• Proporcionar o definir Sistemas de Información
que ayuden a conseguir los fines de la
Organización mediante la definición de un marco
estratégico para el desarrollo de los mismos.
• Dotar a la Organización de productos software
que satisfagan las necesidades de los usuarios
dando una mayor importancia al análisis de
requisitos.
• Mejorar la productividad de los departamentos de
Sistemas y Tecnologías de la Información y las
Comunicaciones, permitiendo una mayor
capacidad de adaptación a los cambios y
teniendo en cuenta la reutilización en la medida
de lo posible.
• Facilitar la comunicación y entendimiento entre
los distintos participantes en la producción de
software a lo largo del ciclo de vida del proyecto,
teniendo en cuenta su papel y responsabilidad,
así como las necesidades de todos y cada uno de
ellos.

14
http://www.csi.map.es/csi/metrica3/introduccion.pdf
 • Facilitar la operación, mantenimiento y uso de los
productos software obtenidos.
Los procesos de la estructura principal de MÉTRICA
Versión 3 son los siguientes:
• PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN.
• DESARROLLO DE SISTEMAS DE INFORMACIÓN.
• MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN.
Y define el proceso de desarrollo de sistemas de
información en:
• ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).
• ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI).
• DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI).
• CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN
(CSI).
• IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS).

2.3.4.5. Open Source Development Software15

Open Source es software desarrollado con la falta de
coordinación, donde los programadores que colaboran
libremente, utilizando libremente el código fuente
distribuido y la infraestructura de comunicaciones de
Internet. El código abierto se basa en la filosofía del
software libre. Sin embargo, el código abierto extiende
esta ideología ligeramente para presentar un enfoque
más comercial que incluye tanto un modelo de negocio
y metodología de desarrollo.
La catedral y el bazar es la descripción citada con
mayor frecuencia al ser relacionada como una de
desarrollo, sin embargo, aunque el documento se
identifican muchos de los mecanismos de éxito de
desarrollo de código abierto, no exponer la dinámica.
Existen críticas sobre ciertos aspectos que siguen
siendo ambiguas, lo que sugiere que el documento no
describe el proceso de desarrollo de código abierto.

15
http://chinese-school.netfirms.com/computer-article-open-source.html
III. METODOLOGÍAS DE CONTROL DE CALIDAD DEL SOTWARE

La obtención de un software con calidad implica la utilización de metodologías o

procedimientos estándares para el análisis, diseño, programación y prueba del software que
permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de
desarrollo como para el control de la calidad del software.
La política establecida debe estar sustentada sobre tres principios básicos: tecnológico,
administrativo y ergonómico.
● El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del
software.
● El principio administrativo contempla las funciones de planificación y control del
desarrollo del software, así como la organización del ambiente o centro de ingeniería de
software.
● El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad del software,
pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

3.1.¿Como controlar la calidad del software?

Para controlar la calidad del software es necesario, ante todo, definir los parámetros,
indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, “usted
no puede controlar lo que no se puede medir”. Las cualidades para medir la calidad del
software son definidas por innumerables autores, los cuales las denominan y agrupan
de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios,
donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La
Metodología para la evaluación de la calidad de los medios de programas de la CIC, de
Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor,
criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los
indicadores que conforman el nivel precedente. Otros autores identifican la calidad con
el nivel de complejidad del software y definen dos categorías de métricas: de
complejidad de programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medibles
que son las bases para la calidad, el control y el perfeccionamiento de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control,
que requiere los siguientes pasos:
● Definir el software que va a ser controlado: clasificación por tipo, esfera de
aplicación, complejidad, etc., de acuerdo con los estándares establecidos para
el desarrollo del software.
● Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada
clase de software es necesario definir los indicadores y sus magnitudes.
 ● Crear o determinar los métodos de valoración de los indicadores: métodos
manuales como cuestionarios o encuestas estándares para la medición de
criterios periciales y herramientas automatizadas para medir los criterios de
cálculo.
● Definir las regulaciones organizativas para realizar el control: quiénes participan
en el control de la calidad, cuándo se realiza, qué documentos deben ser
revisados y elaborados, etc.

3.2.La gestión de la calidad

Gestión de la calidad: "Aspectos de la función de gestión que determinan y aplican la
política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios
tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y
la mejora de la calidad".
Dentro de la gestión de la calidad se observa:
• Gestión de la calidad de software (ISO 9000): Conjunto de actividades de la
función general de la dirección que determina la calidad, los objetivos y las
responsabilidades y se implanta por medios tales como la planificación de la
calidad, el control de la calidad, el aseguramiento (garantía) de la calidad y la
mejora de la calidad, en el marco del sistema de calidad
• Política de calidad (ISO 9000): Directrices y objetivos generales de una
organización, relativos a la calidad, tal como se expresan formalmente por la
alta dirección.
La gestión de la calidad se aplica normalmente a nivel de empresa. También puede
haber una gestión de calidad dentro de la gestión de cada proyecto.

3.3.El aseguramiento de la calidad

Ante todo se debe conocer:
• Aseguramiento de la calidad: "Conjunto de acciones planificadas y
sistemáticas necesarias para proporcionar la confianza adecuada de que un
producto o servicio satisfará los requerimientos dados sobre calidad".
• Aseguramiento de la calidad de software: Conjunto de actividades
planificadas y sistemáticas necesarias para aportar la confianza en que el
producto (software) satisfará los requisitos dados de calidad.
 El aseguramiento de calidad del software se diseña para cada aplicación antes de
comenzar a desarrollarla. Hay quienes prefieren decir garantía de calidad en vez de
aseguramiento.
La garantía, puede confundir con garantía de productos, mientras que el aseguramiento
pretende dar confianza en que el producto tiene calidad.
El aseguramiento de calidad del software está presente en:
• Métodos y herramientas de análisis, diseño, programación y prueba.
• Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del
software.
• Estrategias de prueba multiescala.
• Control de la documentación del software y de los cambios realizados.
• Procedimientos para ajustarse a los estándares (y dejar claro cuando se está
fuera de ellos).
• Mecanismos de medida (métricas).
• Registro de auditorias y realización de informes.
Las actividades para el aseguramiento de calidad del software se detallan en:
• Métricas de software para el control del proyecto.
• Verificación y validación del software a lo largo del ciclo de vida (Incluye las
pruebas y los procesos de revisión e inspección).
• La gestión de la configuración del software.
Algunos métodos del aseguramiento:
• Revisiones técnicas y de gestión (su objetivo es la evaluación).
• Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto
correcto?.
• Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto
correctamente?.
• Auditorias (su objetivo es la confirmación del cumplimiento).

3.4.El control de la calidad

Se debe conocer:
• Control de calidad: "Conjunto de técnicas y actividades de carácter operativo,
utilizadas para verificar los requerimientos relativos a la calidad del producto o
servicio".
• Control de la calidad del software: Técnicas y actividades de carácter
operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas
en mantener bajo control el proceso de desarrollo y eliminar las causas de los
defectos en las diferentes fases del ciclo de vida.
El control de la calidad del software está centrado en dos objetivos fundamentales:
• Mantener bajo control un proceso.
• Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
En general, se puede decir que el control de de la calidad del software son las
actividades para evaluar la calidad de los productos desarrollados.
Las estrategias de trabajo se representan como sigue:
3.5.Modelos de calidad de software

1. CMM

El Modelo de Madurez de Capacidades (CMM) es un modelo de referencia

para la aplicación de conceptos de gestión de procesos y de mejora de calidad
en el desarrollo y mantenimiento de software, que deben ser implementadas
por toda organización interesada en desarrollar y mejorar la calidad de sus
productos y su productividad.

Este modelo está basado en conceptos de calidad total y de mejoramiento

continuo y ha sido desarrollado en el SEI (Software Engineering Institute)
relacionado con Carnegie Mellon University, en Pittsburgh.
El CMM se desarrolló como reacción a la crisis del software a principios de los
ochenta y financiado por el Departamento de Defensa de los Estados Unidos.

Se entiende por proceso el saber como utilizar el conocimiento del personal y la

tecnología de forma eficiente para lograr productos que alta calidad que
satisfagan las necesidades de los clientes, producidos dentro de costos y plazos
aceptables.

Un proceso puede considerarse maduro si cumple con los siguientes criterios:

➢ Está definido: El proceso es claro, sistemático y suficientemente

detallado. Además existe acuerdo entre el personal, la gerencia y los
proyectos respecto al proceso que se va a utilizar.

➢ Esta documentado: Esta escrito en un procedimiento publicado,

aprobado y fácilmente accesible.

➢ El personal ha sido entrenado en el proceso: Los ingenieros de software

y la gerencia han recibido cursos y entrenamiento en cada proceso que
aplica a su trabajo

➢ Es practicado: El proceso definido debe ser usado en las tareas

habituales llevadas a cabo por los proyectos. El entrenamiento y la
adaptación del proceso a la realidad de la empresa debieran garantizar
su aplicación en la vida real.

➢ Es mantenido: El proceso es revisado regularmente, para asegurarse

que está adaptado para satisfacer las necesidades reales de los
proyectos.
 ➢ Está controlado: Los cambios y puestas al día del proceso son
revisados, aprobados y comunicados oportunamente a todos los
usuarios.

➢ Se verifica: La gerencia mantiene mecanismos para asegurarse de que

todos los proyectos siguen el proceso vigente.

➢ Se valida: Se asegura que el proceso mantiene concordancia con los

requerimientos y estándares aplicables.

➢ Se mide: La utilización, los beneficios y el rendimiento resultante del

proceso se miden regularmente.

➢ Puede mejorarse: Existen mecanismos y apoyo de la gerencia para

revisar e introducir cambios en el proceso, de manera que se pueda
mejorar su eficacia e incorporar nuevas metodologías.

El CMM se basa principalmente es dos conceptos importantes, el concepto de

proceso maduro, definido anteriormente y el concepto de nivel de madurez que
es definido como la capacidad de los procesos de ingeniería de software y de
administración de proyectos usados en una organización de desarrollo de
software y entendiéndose por maduro el definido anteriormente como proceso.

1. Niveles de Madurez de CMM

El CMM identifica los niveles de madurez de los procesos siguientes:

Así es como el modelo CMM mide el progreso conforme avanza, en

niveles de madurez. Cada nivel tiene un cierto número de áreas de
proceso importantes que deben lograrse. Su logro se detecta mediante
la satisfacción (o no) de varios metas claras y cuantificables.

Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está
compuesto por un cierto número de Áreas Claves de Proceso,
conocidas a través de la documentación del CMM por su sigla inglesa:
KPA. Cada KPA identifica una agrupación de actividades y prácticas
relacionadas, las cuales cuando son realizadas en forma colectiva
permiten lograr alcanzar las metas fundamentales del proceso. Las
 KPAs pueden clasificarse en 3 tipos de proceso: Gestión,
Organizacional e Ingeniería.

Las prácticas que deben ser realizadas por cada Area Clave de Proceso
están organizadas en 5 Características Comunes, las cuales
constituyen propiedades que indican si la implementatción y la
institucionalización de un proceso clave es efectivo, repetible y duradero.

Estas 5 características son:

• Compromiso de la realización.
• La capacidad de realización.
• Las actividades realizadas
• Las mediciones y el análisis
• La verificación de la implementación.

El modelo CMM se formula de una manera genérica. Es independiente

de cualquier método (o metodología) y de cualquier ambiente de
tecnología (software o hardware).
Los métodos específicos usados por una compañía o agencia no
impone restricciones específicas en la utilización del SW-CMM, debido a
que sus prácticas se formulan de forma general para que pueda
fácilmente adaptarse de manera de satisfacer las necesidades de
ambientes particulares.

Este modelo debe interpretarse de acuerdo al tamaño de las compañías

o agencias, pero es aplicable en el contexto global. Cualquier entidad
que desarrolla o mantiene software, independientemente de su tamaño
se beneficiará mejorando su proceso de software aplicando el CMM.

Uno de los métodos de evaluación basados en el modelo CMM para el

mejoramiento interno de procesos, generalmente conocido como CBA-
IPI ("CMM -Based Appraisal for Internal Process Improvement"): su
principal objetivo es permitir a la empresa la determinación de sus
puntos fuertes y necesidades de mejoramiento, también permite revisar
las prácticas de los proveedores externos, a objeto de que puedan
derivar un plan de mejoramiento adecuado a su organización.

1. Nivel 1: Nivel Inicial

Nivel de Inmadurez

Es el estado inicial de las empresas que desarrollan software. En este

nivel se encuentran todas las empresas que no han logrado implementar
las prácticas básicas de gestión de proyectos e ingeniería de software
definidas a partir del nivel 2 o superiores. Una empresa está en el nivel
caótico cuando sus gerentes y personal afirmen que los proyectos no se
pueden planear, que los requerimientos no se pueden tener bajo control,
que no esté siempre en condiciones de controlar las versiones de
producto, donde la calidad sea percibida como una burocracia
innecesaria, cuando se acepte que los procesos son una cosa personal,
cuando no se pueda verificar ni validar el producto, y sobre todo, cuando
sus gerentes y personal vivan bajo condiciones de stress y frustración
permanentes.
La gerencia ocupa una parte significativa de su tiempo en paliar
problemas y enfrentar clientes insatisfechos. Ante una situación de crisis
permanente, se les hace difícil destinar recursos para definir o
 documentar procesos, lo que lleva a un círculo sin salida.

Cuando el proyecto se termina, la inversión hecha en desarrollar el

proceso es raramente reutilizada en nuevos proyectos. Los
desarrolladores de software generalmente tienen que trabajar largas
horas y paliar problemas en forma cotidiana, lo cual les disminuye su
creatividad y productividad netas.

2. Nivel 2: Nivel Repetible

El proyecto planificado

El nivel 2 o Repetible hace posible la implementación de prácticas

mínimas de administración de proyecto, de control de requerimientos,
versiones de producto y de proyectos realizados por subcontratistas. El
grupo o equipo humano que realizó el proyecto puede aprovechar su
experiencia e inversión en procesos para aplicarla en un nuevo
proyecto.

Este nivel no garantiza que todos los proyectos dentro de la empresa

estén necesariamente al mismo nivel de madurez. Algunos pueden estar
todavía en el nivel inicial. Luciano Guerrero [1], en cuya página hemos
basado gran parte del trabajo ha visto algunos casos en la práctica y en
todos ellos estos proyectos fueron ineficientes con respecto a los de
mayor madurez, malgastando el éxito de estos últimos. Eventualmente
algunos invertieron los esfuerzos necesarios para ponerse a tono, otros
simplemente fueron cerrados con un elevado costo de frustración y
descalabro de carreras profesionales.

Beneficios de implantar el Nivel 2

El mayor beneficio obtenido de la implementación del nivel 2 por la

empresa en la cual se encuentra actualmente [1], es la planificación
realista de los proyectos. Antes los cronogramas de proyecto
expresaban más los deseos de la gerencia que la realidad. Este
principio (el mismo en la cual se basa la magia) conducía una situación
de buscar culpables y generar excusas, produciendo al mismo tiempo
frustración y desconfianza entre clientes y empleados actualmente en la
empresa, los cronogramas son cada día más confiables, y mejora a
medida que se acumula más información en las bases de datos de los
proyectos pasados. El uso generalizado de métodos de estimación
permite al personal del proyecto de justificar plazos y recursos. Aún el
"olfato profesional" y la experiencia personal juegan un papel importante
en la generación de planes de proyecto, pero ahora son decisiones
informadas en vez de simples adivinanzas como en el pasado.

Los pasos siguientes

Este nivel todavía permite la proliferación y definición insuficiente de los

procesos de ingeniería de software. Los proyectos comparten
principalmente sus experiencias en materia de administración de
proyectos, pero sus métodos técnicos pueden diferir. Aún existe
incomunicación entre proyectos, grupos y entre personal y gerencia.

Este nivel identifica prácticas de sentido común que son aplicables en

todo tipo de organizaciones de desarrollo de software,
independientemente de su rubro, tamaño o ambiente de desarrollo. La
ausencia de cualquiera de sus prácticas simplemente pone en peligro el
éxito de la empresa.
 KPAs del Nivel 2

• Gestión de Requisitos
• Planificación del proyecto de software
• Seguimiento y Supervisión del proyecto
• Gestión de subcontratos de software
• Garantía de calidad de software
• Gestión de configuración del software

3. Nivel 3: El proceso definido

El proceso generalizado en todos los proyectos

La empresa ha definido un conjunto de procesos, metodologías y

herramientas comunes a todos los proyectos iniciados por la
corporación.

El proceso común está suficientemente documentado en una biblioteca

accesible a todo los desarrolladores. Todo el personal ha recibido el
entrenamiento necesario para entender el proceso estándar. Existen
pautas y criterios definidos para adaptar dicho proceso a las
necesidades y características propias de cada proyecto. El nivel de
definición es detallado y completo. La dependencia (o el riesgo de
depender) en individuos irreemplazables es baja.

Beneficios de implantar el Nivel 3 del CMM

La base de datos que reúne estadísticas de los proyectos pasados en

curso, permite planificar y comparar el rendimiento. Existen mecanismos
de comunicación entre proyectos y departamentos, lo que garantiza una
visión común del producto y una rápida acción para enfrentar los
problemas. Según el autor [1], ha conocido unas pocas empresas a este
nivel y la cosa que más le llamo la atención, fue la satisfacción del
personal. En empresas de nivel 1 habitualmente se escuchan quejas y
acusaciones.

A nivel 3 los empleados tienen una alta valoración de los procesos y

entienden claramente la manera en que afecta su desempeño habitual.
Los gerentes pueden realizar su verdadera función, administrar.

El hecho de realizar revisiones tempranas en forma regular mejora

visiblemente la calidad de los productos y minimiza las reiteraciones
innecesarias. Curiosamente muchas organizaciones de nivel 1 realizan
revisiones de pares, pero lo hacen de manera inconsistente y al primer
signo de pánico las suspenden.

Los pasos siguientes

El nivel 3 ya es un estado avanzado y es percibido por algunos gerentes

como un lujo. Si no todas, al menos unas cuantas de sus áreas claves
de procesos deben ser implementadas.

KPAs del Nivel 3

• Enfoque en el proceso de la organización

 • Definición del proceso de la organización
• Programa de entrenamiento
• Gestión integrada del software
• Ingeniería de software del producto
• Coordinación entre grupos
• Revisión de pares

4. Nivel 4: El proceso gestionado

La calidad planificada y confiable

En este nivel la corporación mide la calidad del producto y del proceso

de software. Ambos, producto y proceso, son seguidos en forma
cuantitativa y se controlan mediante métricas detalladas. La capacidad
de rendimiento del proceso es previsible. Las mediciones permiten
detectar cuando las variaciones del rendimiento se salen de los rangos
aceptables, de manera que se puedan tomar medidas correctivas para
asegurar la calidad.

Beneficios de implantar el Nivel 4 del CMM

La empresa es capaz de proponerse metas cuantitativas para la calidad
de los productos y de los procesos de software. Es posible medir la
productividad y calidad de los procesos de software a través de todo el
proyecto.

Los proyectos pueden controlar la variación del rendimiento de sus

productos y procesos para mantenerla dentro de fronteras cuantitativas
aceptables. Es posible discriminar las variaciones significativas en el
rendimiento del proceso de la variación (ruido) al azar, particularmente
dentro de líneas de productos establecidas.

Es necesario aclarar que el hecho de contar con un sistema de métricas

de software no significa que se esté en el nivel 4. Es una virtual señal de
alarma que les dice lo graves que son sus problemas, pero la inmadurez
de sus procesos no les permite hacer nada efectivo, excepto tal vez
abortar el producto para evitar un daño mayor que puede resultar de
distribuirlo a los clientes.

Los pasos siguientes

Son muy raras las empresas que han decidido implementar este nivel.
No son muchos los especialistas de procesos que realmente tengan
experiencia práctica, o incluso que entiendan bien las áreas claves de
proceso del nivel 4. Son solamente 2 prácticas, pero imposibles de
alcanzar si no se ha implementado firmemente los 2 niveles de
madurez anteriores.

KPAs del Nivel 4

• Gestión cuantitativa del proceso
• Gestión de la calidad del software

5. Nivel 5: El mejoramiento permanente

 La calidad planificada y confiable

En el Nivel Optimizado, la característica principal es el mejoramiento

continuo del proceso, en base a la realimentación cuantitativa y al
ensayo de ideas y tecnologías innovadoras.

Beneficios de implantar el Nivel 5 del CMM

La organización entera se aboca al mejoramiento continuo del proceso.
La corporación cuenta con los medios para identificar las debilidades y
reforzar el proceso, con objeto de prevenir la ocurrencia de defectos.

Los datos relativos a la eficacia del proceso de software se usan para

analizar el coste y el beneficio de usar nuevas tecnologías y de
implementar cambios al proceso de software.

Los proyectos de software analizan los defectos para determinar sus

causas. Los proceso de software se evalúan para prevenir que los
defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas
son difundidas a otros proyectos.

Los pasos siguientes

No existen más de 10 empresas en el mundo que estén a este nivel (no

hay ninguna en países hispano-hablantes). Y las pocas que lo han
logrado no divulgan sus secretos para mantener su ventaja competitiva.
Este nivel es un estado ideal, que probablemente nunca será alcanzado
por la mayoría de las empresas productoras de software. Luciano
Guerrero [1] opina que “es una hermosa utopía, pero inalcanzable en el
mundo normal.”

KPAs del Nivel 5

• Prevención de defectos
• Gestión del cambio de tecnología
• Gestión del cambio del proceso

2. La familia CMM

Hay toda una familia de modelos de madurez (CMM’s), aplicables a

otros dominios relacionados con el software.

SW-CMM: El modelo CMM lo aplicamos específicamente al ámbito del

software .

SE- CMM: que significa Systems Engineering, el cual cubre el ámbito de

la Ingeniería de Sistemas.
P-CMM:
P-CMM: que significa Personal CMM, el cual cubre la administración de
personal.
SA-CMM: que significa Software Acquisition, el cual cubre las prácticas
de la adquisición de productos de software.
IPD-CMM: que significa Integrated Product Development, el cual cubre
el desarrollo de la integración del producto.

A continuación pasamos a detallar los cinco niveles de madurez de que

consta CMM.

2. ISO / IEC TR 15504

Modelo para la mejora y evaluación de los procesos de desarrollo y
mantenimiento de sistemas y productos de software.

Origen

En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo

para el desarrollo de un modelo que fuera la base de un futuro estándar
internacional para la evaluación de los procesos del ciclo de vida del software.
Este trabajo recibió el nombre de proyecto SPICE (Software Process
Improvement and Capability dEtermination), y en junio de 1995, con la
publicación de su primer borrador, desde ISO fueron invitadas diferentes
organizaciones para aplicarlo y valorar sus resultados.

En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el

trabajo pasó a la fase de informe técnico con la denominación ISO/IEC TR
15504. La instrucción técnica consta de 9 apartados, recogidos en volúmenes
independientes que se han ido publicando como redacción definitiva del
estándar internacional ISO/IEC 15504 durante el periodo 2003 - 2005.

Características
• Establece un marco para métodos de evaluación, no es un método o
modelo en sí.
• Comprende: evaluación de procesos, mejora de procesos,
determinación de capacidad.
• Está alineado con el estándar ISO/IEC 12207 que define los
procesos del ciclo de vida del desarrollo, mantenimiento y operación de
los sistemas de software.
• Equivalencia y compatibilidad con CMMI. ISO forma parte del panel
elaborador del modelo CMMI y SEI mantiene la compatibilidad y
equivalencia de ésta última con 15504.
Dimensiones
Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad
de proceso.
Desde la dimensión de proceso agrupa a los procesos en tres grupos que
contienen cinco categorías de acuerdo al tipo de actividad:

Procesos primarios
• CUS: Cliente - Proveedor
• ENG: Ingeniería

Procesos de soporte
• SUP: Soporte

Procesos organizacionales
• MAN: Gestión
• ORG: Organización
Para todos los procesos se definen los componentes: Identificador, Nombre,
Tipo, Propósito, Salidas y Notas.

Desde la dimensión de capacidad el modelo define una escala de 6 niveles para

determinar la capacidad de cualquier proceso:
• Nivel 0: Incompleto
• Nivel 1: Realizado
• Nivel 2: Gestionado
• Nivel 3: Establecido
 • Nivel 4: Predecible
• Nivel 5: En optimización

3.5.3 METRICA3

La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil

para la sistematización de las actividades que dan soporte al ciclo de vida del software
dentro del marco que permite alcanzar los siguientes objetivos:

● Proporcionar o definir Sistemas de Información que ayuden a conseguir

los fines de la
● Organización mediante la definición de un marco estratégico para el
desarrollo de los mismos.
● Dotar a la Organización de productos software que satisfagan las
necesidades de los usuarios dando una mayor importancia al análisis de
requisitos.
● Mejorar la productividad de los departamentos de Sistemas y
Tecnologías de la Información y las Comunicaciones, permitiendo una
mayor capacidad de adaptación a los cambios y teniendo en cuenta la
reutilización en la medida de lo posible.
● Facilitar la comunicación y entendimiento entre los distintos participantes
en la producción de software a lo largo del ciclo de vida del proyecto,
teniendo en cuenta su papel y responsabilidad, así como las
necesidades de todos y cada uno de ellos.
● Facilitar la operación, mantenimiento y uso de los productos software
obtenidos.

En una única estructura la metodología MÉTRICA Versión 3 cubre distintos tipos de

desarrollo: estructurado y orientado a objetos, facilitando a través de interfaces la
realización de los procesos de apoyo u organizativos: Gestión de Proyectos, Gestión de
Configuración, Aseguramiento de Calidad y Seguridad.
La automatización de las actividades propuestas en la estructura de MÉTRICA Versión
3 es posible ya que sus técnicas están soportadas por una amplia variedad de
herramientas de ayuda al desarrollo.

3.5.3.1 PROCESOS PRINCIPALES DE MÉTRICA

MÉTRICA Versión 3 tiene un enfoque orientado al proceso, ya que la tendencia

general en los estándares se encamina en este sentido y por ello, como ya se
ha dicho, se ha enmarcado dentro de la norma ISO 12.207, que se centra en la
clasificación y definición de los procesos del ciclo de vida del software. Como
punto de partida y atendiendo a dicha norma, MÉTRICA Versión 3 cubre el
Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de
Información.
MÉTRICA Versión 3 ha sido concebida para abarcar el desarrollo completo de
Sistemas de Información sea cual sea su complejidad y magnitud, por lo cual su
estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse
en cada momento de acuerdo a las características particulares de cada
proyecto.
La metodología descompone cada uno de los procesos en actividades, y éstas
a su vez en tareas. Para cada tarea se describe su contenido haciendo
referencia a sus principales acciones, productos, técnicas, prácticas y
participantes.
El orden asignado a las actividades no debe interpretarse como secuencia en su
realización, ya que éstas pueden realizare en orden diferente a su numeración o
bien en paralelo, como se muestra en los gráficos de cada proceso. Sin
embargo, no se dará por acabado un proceso hasta no haber finalizado todas
las actividades del mismo determinadas al inicio del proyecto.
Así los procesos de la estructura principal de MÉTRICA Versión 3 son los
 siguientes:
● PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN.
● DESARROLLO DE SISTEMAS DE INFORMACIÓN.
● MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN.

El enfoque del Proceso de Planificación de Sistemas de Información, al no estar

dentro del ámbito de la norma ISO 12.207 de Procesos del Ciclo de Vida de
Software, se ha determinado a partir del estudio de los últimos avances en este
campo, la alta competitividad y el cambio a que están sometidas las
organizaciones. El entorno de alta competitividad y cambio en el que
actualmente se encuentran las organizaciones, hace cada vez más crítico el
requerimiento de disponer de los sistemas y las tecnologías de la información
con flexibilidad para adaptarse a las nuevas exigencias, con la velocidad que
demanda dicho entorno.
La existencia de tecnología de reciente aparición, permite disponer de sistemas
que apoyan la toma de decisiones a partir de grandes volúmenes de
información procedentes de los sistemas de gestión e integrados en una
plataforma corporativa. MÉTRICA Versión 3 ayuda en la planificación de
sistemas de información facilitando una visión general necesaria para posibilitar
dicha integración y un modelo de información global de la organización.
En cuanto al Proceso de Desarrollo de Sistemas de Información, para facilitar la
comprensión y dada su amplitud y complejidad se ha subdividido en cinco
procesos:

● ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).

● ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI).
● DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI).
● CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI).
● IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS).

La necesidad de acortar el ciclo de desarrollo de los sistemas de información ha

orientado a muchas organizaciones a la elección de productos software del
mercado cuya adaptación a sus requerimientos suponía un esfuerzo bastante
inferior al de un desarrollo a medida, por no hablar de los costes de
mantenimiento. Esta decisión, que es estratégica en muchas ocasiones para
una organización, debe tomarse con las debidas precauciones, y es una
realidad que está cambiando el escenario del desarrollo del software. Otra
consecuencia de lo anterior es la práctica, cada vez más habitual en las
organizaciones, de la contratación de servicios externos en relación con los
sistemas y tecnologías de la información y las comunicaciones, llevando a la
necesidad de una buena gestión y control de dichos servicios externos y del
riesgo implícito en todo ello, para que sus resultados supongan un beneficio
para la organización. MÉTRICA Versión 3 facilita la toma de decisión y la
realización de todas las tareas que comprende el desarrollo de un sistema de
información.
Desde el enfoque de la norma ISO 12.207, el Proceso de Mantenimiento de
Sistemas de Información comprende actividades y tareas de modificación o
retirada de todos los componentes de un sistema de información (hardware,
software, software de base, operaciones manuales, redes, etc.). Este marco de
actuación no es el objetivo de MÉTRICA Versión 3, ya que esta metodología
está dirigida principalmente al proceso de desarrollo del software. Por lo tanto,
MÉTRICA Versión 3 refleja los aspectos del Mantenimiento, correctivo y
evolutivo, que tienen relación con el Proceso de Desarrollo.

3.5.3.2 Interfaz Aseguramiento de la Calidad

El objetivo de la interfaz de Aseguramiento de la Calidad de MÉTRICA Versión 3

es proporcionar un marco común de referencia para la definición y puesta en
marcha de planes específicos de aseguramiento de calidad aplicables a
proyectos concretos. Si en la organización ya existe un sistema de calidad,
 dichos planes deberán ser coherentes con el mismo, completándolo en los
aspectos no contemplados relativos a normas particulares del cliente, usuario o
sistema concreto.
La calidad se define como “grado en que un conjunto de características
inherentes cumple con unos requisitos” [ISO 9000:2000]. El Aseguramiento de
la Calidad pretende dar confianza en que el producto reune las características
necesarias para satisfacer todos los requisitos del Sistema de Información.
Por tanto, para asegurar la calidad de los productos resultantes el equipo de
calidad deberá realizar un conjunto de actividades que servirán para:
● Reducir, eliminar y lo más importante, prevenir las deficiencias de
calidad de los productos a obtener.
● Alcanzar una razonable confianza en que las prestaciones y
servicios esperados por el cliente o el usuario queden satisfechas.

Para conseguir estos objetivos, es necesario desarrollar un plan de

aseguramiento de calidad específico que se aplicará durante la planificación del
proyecto de acuerdo a la estrategia de desarrollo adoptada en la gestión del
proyecto. En el plan de aseguramiento de calidad se reflejan las actividades de
calidad a realizar (normales o extraordinarias), los estándares a aplicar, los
productos a revisar, los procedimientos a seguir en la obtención de los distintos
productos durante el desarrollo en MÉTRICA Versión 3 y la normativa para
informar de los defectos detectados a sus responsables y realizar el
seguimiento de los mismos hasta su corrección.
El grupo de aseguramiento de calidad participa en la revisión de los productos
seleccionados para determinar si son conformes o no a los procedimientos,
normas o criterios especificados, siendo totalmente independiente del equipo de
desarrollo. Las actividades a realizar por el grupo de aseguramiento de calidad
vienen gobernadas por el plan. Sus funciones están dirigidas a:
● Identificar las posibles desviaciones en los estándares aplicados,
así como en los requisitos y procedimientos especificados.
● Comprobar que se han llevado a cabo las medidas preventivas o
correctoras necesarias.

Las revisiones son una de las actividades más importantes del aseguramiento
de la calidad, debido a que permiten eliminar defectos lo más pronto posible,
cuando son menos costosos de corregir. Además existen procedimientos
extraordinarios, como las auditorías, aplicables en desarrollos singulares y en el
transcurso de las cuales se revisarán tanto las actividades de desarrollo como
las propias de aseguramiento de calidad. La detección anticipada de errores
evita el que se propaguen a los restantes procesos de desarrollo, reduciendo
substancialmente el esfuerzo invertido en los mismos. En este sentido es
importante destacar que el establecimiento del plan de aseguramiento de
calidad comienza en el Estudio de Viabilidad del Sistema y se aplica a lo largo
de todo el desarrollo, en los procesos de Análisis, Diseño, Construcción,
Implantación y Aceptación del Sistema y en su posterior Mantenimiento.

3.5.3.2.1 ESTUDIO DE VIABILIDAD DEL SISTEMA

En este proceso el grupo de aseguramiento de calidad inicia el estudio

de los sistemas de información definidos en cada alternativa de solución
propuesta, con el fin de identificar las condiciones en que se van a
desarrollar y/o a implantar, así como las características que deben reunir
en cuanto a operación, mantenibilidad y portabilidad, para satisfacer las
necesidades del cliente y los requisitos especificados.
La necesidad de establecer un plan específico de aseguramiento de
calidad y el grado de intensidad con el que se aplican las actuaciones de
calidad, vendrá determinada en función de este estudio y de los riesgos
analizados por el equipo de desarrollo.
Una vez tomada la decisión de llevar a cabo un plan de aseguramiento
de calidad en las alternativas propuestas, se define el contenido de
dicho plan, de acuerdo a los estándares de calidad, si existen en la
organización, sino se recomienda acudir a los estándares UNE-EN-ISO
9001:2000 Sistemas de Gestión de la Calidad – Requisitos y UNE-EN-
ISO 9000:2000 Sistemas de Gestión de la Calidad – Fundamentos y
vocabulario. El plan de aseguramiento de calidad debe cubrir todas las
necesidades establecidas de modo que, aquellas normas impuestas por
los usuarios o clientes que difieran de las existentes en el sistema de
calidad, deben quedar también reflejadas en el plan.
El siguiente esquema muestra la correspondencia entre las actividades
del proceso EVS y las de la interfaz de Aseguramiento de la Calidad.

ACTIVIDAD EVS-CAL 1: IDENTIFICACIÓN DE LAS PROPIEDADES DE

CALIDAD PARA EL SISTEMA

ACTIVIDAD EVS–CAL 2: ESTABLECIMIENTO DEL PLAN DE

ASEGURAMIENTO DE CALIDAD
 ACTIVIDAD EVS–CAL 3: ADECUACIÓN DEL PLAN DE
ASEGURAMIENTO DE CALIDAD A LA SOLUCIÓN

3.5.3.2.2 ANÁLISIS DEL SISTEMA DE INFORMACIÓN

En este proceso se define de forma detallada el plan de aseguramiento

de calidad para un sistema de información, a partir de la especificación
resultante del proceso Estudio de Viabilidad del Sistema (EVS).
También se detallan los estándares y normas a cumplir, las revisiones a
llevar a cabo y sobre qué productos, así como los procedimientos y
mecanismos necesarios para resolver los problemas que surjan,
definiendo las acciones preventivas o correctoras para su posterior
corrección e identificando quiénes son los responsables en cada caso.
En el proceso Análisis del Sistema de Información (ASI), el grupo de
aseguramiento de calidad se implica directamente en la revisión de los
siguientes productos:
● Catálogo de requisitos, comprobando hasta que punto se han
definido de una forma que facilite su comprensión y seguimiento.
● Modelos resultantes del análisis, asegurando que se han
verificado y validado y que se ha realizado la trazabilidad de
requisitos.
● Plan de pruebas, comprobando que se han tenido en cuenta en
su definición los criterios establecidos en el plan de
aseguramiento de calidad, con el fin de facilitar en los procesos
Diseño del Sistema de Información (DSI), Construcción del
Sistema de Información (CSI) e Implantación y Aceptación del
Sistema (IAS) la revisión de los distintos niveles de prueba.
ACTIVIDAD ASI-CAL 1: ESPECIFICACIÓN INICIAL DEL PLAN DE
ASEGURAMIENTO DE CALIDAD

ACTIVIDAD ASI–CAL 2: ESPECIFICACIÓN DETALLADA DEL PLAN DE

ASEGURAMIENTO DE CALIDAD

ACTIVIDAD ASI-CAL 3: REVISIÓN DEL ANÁLISIS DE CONSISTENCIA

 ACTIVIDAD ASI-CAL 4: REVISIÓN DEL PLAN DE PRUEBAS

Actividad ASI-CAL 5: Registro de la Aprobación del Análisis del Sistema

3.5.3.2.3 DISEÑO DEL SISTEMA DE INFORMACIÓN

Las revisiones del diseño se centran en confirmar que los requisitos

especificados en el proceso Análisis del Sistema de Información se han
traducido en una arquitectura conforme al entorno tecnológico
seleccionado.
Asimismo, se revisan los requisitos que deben cumplir los distintos
niveles de pruebas (unitarias, de integración, del sistema, de
implantación y aceptación) especificados en el plan de pruebas, de
acuerdo a los criterios de revisión establecidos en el plan de
aseguramiento de calidad.
También se realiza una revisión de la identificación de los requisitos no
funcionales relacionados con la documentación de usuario e
implantación.
El siguiente esquema muestra la correspondencia entre las actividades
del proceso DSI y las de la interfaz de Aseguramiento de la Calidad.
ACTIVIDAD DSI–CAL 1: REVISIÓN DE LA VERIFICACIÓN DE LA
ARQUITECTURA DEL SISTEMA
 ACTIVIDAD DSI–CAL 2: REVISIÓN DE LA ESPECIFICACIÓN TÉCNICA
DEL PLAN DE PRUEBAS

ACTIVIDAD DSI–CAL 3: REVISIÓN DE LOS REQUISITOS DE

IMPLANTACIÓN

ACTIVIDAD DSI-CAL 4: REGISTRO DE LA APROBACIÓN DEL

DISEÑO DEL SISTEMA DE INFORMACIÓN

3.5.3.2.4 CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN

En este proceso el grupo de aseguramiento de calidad revisa los

estándares de nomenclatura y normativa aplicada en la generación del
código de componentes, en la evaluación de los resultados de las
pruebas, en los manuales de usuario y en el esquema de formación.
Con respecto a las pruebas, se revisa que se han llevado a cabo las
pruebas unitarias, de integración y del sistema según los criterios de
selección de verificaciones y casos de prueba asociados que se habrán
fijado en el plan de aseguramiento de calidad.
El siguiente esquema muestra la correspondencia entre las actividades
del proceso CSI y las de la interfaz de Aseguramiento de la Calidad.
ACTIVIDAD CSI–CAL 1: REVISIÓN DEL CÓDIGO DE COMPONENTES
Y PROCEDIMIENTOS
 ACTIVIDAD CSI–CAL 2: REVISIÓN DE LAS PRUEBAS UNITARIAS, DE
INTEGRACIÓN Y DEL SISTEMA

ACTIVIDAD CSI–CAL 3: REVISIÓN DE LOS MANUALES DE USUARIO

ACTIVIDAD CSI–CAL 4: REVISIÓN DE LA FORMACIÓN A USUARIOS

FINALES

ACTIVIDAD CSI-CAL 5: REGISTRO DE LA APROBACIÓN DEL

SISTEMA DE INFORMACIÓN

3.5.3.2.5 IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA

El grupo de aseguramiento de calidad en este proceso es responsable

de revisar la existencia de un plan de implantación que se habrá
elaborado conforme a la estrategia de implantación determinada en el
proceso Estudio de Viabilidad del Sistema (EVS) y teniendo en cuenta
los requisitos de implantación establecidos en el proceso Diseño del
Sistema de Información (DSI).
También deben comprobar que se han realizado las pruebas de
implantación y de aceptación según el plan de pruebas establecido en
MÉTRICA Versión 3 y la normativa acordada en el plan de
aseguramiento de calidad. Revisan la totalidad de las verificaciones y
casos de prueba de implantación y aceptación que se hayan
especificado para el sistema y las incidencias producidas, con el fin de
determinar si puede verse afectada alguna propiedad de calidad. En
cualquier caso, se registra la aprobación de las pruebas de implantación
y de aceptación por parte de operación y del usuario respectivamente.
En cuanto al mantenimiento, el grupo de aseguramiento de calidad debe
asegurar que se le entrega el producto software al responsable de
mantenimiento, con las propiedades adecuadas para que pueda asumir
el servicio de mantenimiento, una vez que el sistema se encuentre en
producción.
El siguiente esquema muestra la correspondencia entre las actividades
del proceso IAS y las de la interfaz de Aseguramiento de la Calidad.

ACTIVIDAD IAS-CAL 1: REVISIÓN DEL PLAN DE IMPLANTACIÓN DEL

SISTEMA

ACTIVIDAD IAS–CAL 2: REVISIÓN DE LAS PRUEBAS DE

IMPLANTACIÓN DEL SISTEMA
 ACTIVIDAD IAS–CAL 3: REVISIÓN DE LAS PRUEBAS DE
ACEPTACIÓN DEL SISTEMA

ACTIVIDAD IAS–CAL 4: REVISIÓN DEL PLAN DE MANTENIMIENTO

DEL SISTEMA

ACTIVIDAD IAS–CAL 5: REGISTRO DE LA APROBACIÓN DE LA

IMPLANTACIÓN DEL SISTEMA

3.5.3.2.6 MANTENIMIENTO DEL SISTEMA DE INFORMACIÓN

En el proceso Implantación y Aceptación del Sistema se habrá

determinado la necesidad de llevar a cabo un seguimiento y control de la
calidad en los sistemas de información, una vez se encuentren en el
entorno de producción.
El grupo de aseguramiento de calidad intenvendrá durante el
mantenimiento, efectuando revisiones de seguimiento periódicas, más o
menos frecuentes según los casos, que sirvan para constatar que el
mantenimiento establecido para el sistema de información se realiza de
forma correcta.
En algún caso, según las implicaciones del cambio, puede ser necesario
revisar puntualmente:
● El contenido del plan de pruebas de regresión.
● La ejecución de las pruebas de regresión según la normativa
acordada en el plan de aseguramiento de calidad.
● Las verificaciones y casos de prueba que se hayan incluido en el
plan de pruebas para los cambios producidos por una petición.
● Las incidencias detectadas con el fin de determinar si puede
verse afectada alguna propiedad de calidad.

En caso de revisar la ejecución de las pruebas de regresión, se

registrará la
aprobación de las pruebas por el responsable de mantenimiento.
En el siguiente gráfico se aprecian las actividades de Aseguramiento de
la Calidad
durante el Mantenimiento del Sistema de Información.

ACTIVIDAD MSI-CAL 1: REVISIÓN DEL MANTENIMIENTO DEL

SISTEMA DE INFORMACIÓN

ACTIVIDAD MSI–CAL 2: REVISIÓN DEL PLAN DE PRUEBAS DE

REGRESIÓN
ACTIVIDAD MSI–CAL3: REVISIÓN DE LA REALIZACIÓN DE LAS
PRUEBAS DE REGRESIÓN
IV. METODOLOGÍA DE GESTIÓN DE PROYECTO

4.1. Aseguramiento de calidad del software (Software Quality

Assurance)

• El aseguramiento de calidad del software es el conjunto de

actividades planificadas y sistemáticas necesarias para aportar la
confianza en que el producto (software) satisfará los requisitos
dados de calidad.
• El aseguramiento de calidad del software se diseña para cada
aplicación antes de comenzar a desarrollarla y no después.
• Algunos autores prefieren decir garantía de calidad en vez de
aseguramiento.
– Garantía, puede confundir con garantía de productos
– Aseguramiento pretende dar confianza en que el producto
tiene calidad
• El aseguramiento de calidad del software está presente en los
siguientes casos:
– Métodos y herramientas de análisis, diseño, programación y
prueba
– Inspecciones técnicas formales en todos los pasos del
proceso de desarrollo del software
– Estrategias de prueba multiescala
– Control de la documentación del software y de los cambios
realizados
– Procedimientos para ajustarse a los estándares (y dejar claro
cuando se está fuera de ellos)
– Mecanismos de medida (métricas)
– Registro de auditorias y realización de informes
• Actividades para el aseguramiento- de calidad del software
– Métricas de software para el control del proyecto
– Verificación y validación del software a lo largo del ciclo de
vida
• Incluye las pruebas y los procesos de revisión e inspección
– La gestión de la configuración del software

4.2. Aseguramiento de la Calidad de software

Se explican conceptos que los auditores deben evaluar y sobre los
que deben informar al comprador público. Aparecerán durante la
realización de la auditoría, pero su especificación debe realizarse al
principio.
Se conoce como garantía de calidad de Software (SQA, Software
Quality Assurance) al conjunto de actividades que se aplican a lo
largo de todo el proceso de ingeniería del software. SQA engloba:
• Métodos y herramientas de análisis, diseño, codificación y
prueba.
• Revisiones técnicas formales que se aplican durante cada
paso de la ingeniería del software.
• Pruebas de software secuenciadas en múltiples pasos y con
métodos específicos de diseño de casos de prueba.
• Control de la documentación del software y de los cambios
 realizados.
• Procedimientos que aseguren un ajuste a los estándares de
desarrollo de software.
• Mecanismos de medida y de información.
• Métricas para medir la calidad del software.

Todo este proceso se realiza de forma interna. La propia

organización puede tener un grupo de SQA que se encargue de la
realización de todas las tareas necesarias. Es posible tener un
grupo de consultores externos dedicados a SQA pero, a poco que la
organización tenga una mediana actividad de desarrollo, los costes
económicos de esta opción pueden ser elevados.

SQA es un proceso de control. La auditoría que puede encargarse

de SQA sin sufrir contradicción con la idea de “punto discontinuo de
control” es la auditoría interna que, siendo la encargada de las
tareas de control interno y estando realizada por personal propio,
dispone de los medios y estructura de costes adecuados.

Los factores que determinan la calidad del software se pueden

clasificar en dos grandes grupos:

• Factores que pueden ser medidos directamente.

• Factores que sólo pueden ser medidos indirectamente.

En cualquiera de los dos casos debemos comparar el software con

una referencia y llegar a una indicación de la calidad. Se han
propuesto los siguientes factores de calidad del software:
• Corrección: El grado en que un programa satisface sus
especificaciones y consigue los objetivos encomendados.
• Fiabilidad: El grado en que se puede esperar que un
programa lleve a cabo sus funciones con la precisión
requerida.
• Eficiencia: La cantidad de recursos de ordenador y de código
requeridos por un programa para llevar a cabo sus funciones.
• Integridad: La información utilizada será la última, exacta,
autorizada y completa.
• Facilidad de uso: Esfuerzo requerido para trabajar con un
programa.
• Facilidad de mantenimiento: Esfuerzo requerido para
localizar y arreglar el error en un programa.
• Flexibilidad: Esfuerzo requerido para modificar un programa
operativo.
• Facilidad de prueba: Esfuerzo requerido para probar un
programa.
• Portabilidad: Esfuerzo requerido para transferir un
programa desde un entorno operativo a otro.
• Reusabilidad: El grado en que un programa se puede reusar
en otras aplicaciones.
• Facilidad de interoperación: Esfuerzo requerido para
acoplar un sistema a otro.
Es difícil para los auditores desarrollar medidas directas de los
anteriores factores de calidad. Por tanto, para medir
cuantitativamente cada uno de los factores cada oferta deberá
expresar claramente qué métricas utiliza para la evaluación del
software.

La garantía de calidad del software (SQA) es un «planificado y

sistemático diseño de acciones» para asegurar la calidad del
software. El personal que lleva a cabo la SQA debe mirar el
software desde el punto de vista del usuario. ¿Se ha realizado el
desarrollo de software de acuerdo con los estándares establecidos?
¿Las disciplinas técnicas han desempeñado apropiadamente sus
papeles?

La calidad del software debe estar pensada para un producto o

sistema o conjunto de sistemas; no es algo impuesto a posteriori.
La SQA utiliza un conjunto de herramientas y métodos técnicos que
ayudan al analista a conseguir una especificación y un diseño de
alta calidad.

Una vez que se ha creado una especificación, un diseño o un

módulo, debe ser garantizada de algún modo su calidad. La
actividad central que permite garantizar la calidad es la revisión
técnica formal. El personal técnico se reúne con el único propósito
de descubrir problemas de calidad.

Otro método usado comúnmente es la prueba de software. Este

procedimiento combina múltiples pasos con una serie de métodos
de diseño de casos de prueba que ayudan a asegurar una efectiva
detección de errores. Muchos grupos de desarrollo de software
usan la prueba como una red de seguridad para la garantía de la
calidad. Se asume que mediante la prueba se descubrirá la mayoría
de los errores, mitigando así la necesidad de otras actividades de
SQA.

El grado de aplicación de procedimientos y estándares en el

proceso de ingeniería del software varía ampliamente dependiendo
de la organización de la que se trate. Si existen estándares
formales, escritos, se deben establecer actividades de SQA para
garantizar que se siguen.

Una de las principales amenazas para la calidad del software

proviene de una actividad supuestamente beneficiosa: los cambios.
El proceso de control de cambios debe venir especificado por la
metodología de desarrollo de sistemas que se use en esa
organización.
Enfoques formales a la SQA

Todo lo que se ha comentado hasta ahora de SQA se concreta en la

práctica en un conjunto de actividades que se deben realizar
durante el desarrollo de sistemas. Debido a esto, previamente se
señaló que son actividades de control, no de auditoría;
alternativamente, se les puede llamar actividades de auditoría
interna.

Segmentos de la comunidad de ingenieros de software vienen

sosteniendo que se deben implementar una serie de controles más
rigurosos, de tipo matemático y estadístico. Estos controles pueden
ser efectuados en cualquier momento, incluso en la fase de
explotación de sistemas.

Se describirán dos técnicas, que pueden ser el objetivo de un

proyecto de auditoría que abarque el área de explotación de SQA:

• Proceso limpio de creación de software

El proceso limpio de creación del software se centra en la

consecución del objetivo de número de defectos nulo. La idea
teórica central es conseguir la verificación matemática de la
corrección de elementos de un sistema de información. Sin
embargo, por el momento no se ha conseguido llevar a la
práctica esta idea para sistemas medianamente complejos,
aunque no sea totalmente descartable que en el medio plazo
se avance en esta dirección.

En segundo lugar, se debe proporcionar una certificación de

calidad estadística. Para ilustrar este proceso, supongamos
que una organización de desarrollo de software recoge
información sobre defectos durante un año, tanto en
explotación como en construcción de sistemas (esto puede
constituir por sí mismo un proyecto de control). Aunque se
descubran cientos de errores diferentes, todos ellos pueden
encuadrarse dentro de una o varias causas.

Los errores detectados deberán ser clasificados en tres

categorías: muy graves, graves, menores. Con estas dos
clasificaciones (causa e importancia) se podrán establecer
conclusiones estadísticas, que permitirán tomar medidas de
corrección. Esta técnica permite efectuar una eliminación
sistemática de las causas de los defectos empezando por los
más serios y mejorando la utilización de los recursos.

• Medidas de fiabilidad

La fiabilidad del software se define en términos estadísticos

como la “probabilidad de operación libre de fallos de un
programa de ordenador en un entorno determinado y durante
un tiempo específico”. Una sencilla medida de fiabilidad es el
tiempo medio entre fallos (MTBF, Mean Time Between
Failures- es el tiempo medio entre fallos de un sistema), y
la duración total de sus reparaciones, medida como el tiempo
medio de la reparación (MTTR, Mean Time To Repare – es el
tiempo medio de reparación) desde la comunicación del
envío, contando desplazamientos del personal y la duración
 de la reparación de la unidad averiada.

Muchos investigadores argumentan que esta medida es más

eficiente que la medida que se usa generalmente para
evaluar la cantidad de errores, que es el número de errores
por cada mil líneas de código.

4.3. Métodos y herramientas de análisis, diseño y codificación

La calidad del software debe estar diseñada para el producto o

sistema, no es algo impuesto a posteriori. Por esta razón, la
garantía de calidad del software comienza realmente con un
conjunto de herramientas y métodos técnicos que ayudan al
analista a conseguir una especificación y un diseño de alta calidad.
En un proceso de desarrollo software, existen una serie de fases
que vienen determinadas por las tareas básicas que hay que
realizar para obtener el producto software. Se definen distintos
ciclos de vida de acuerdo a la evolución del software a lo largo de
dichas fases. Las fases más típicas son:

• Requisitos del Sistema: también llamada análisis de

requisitos, especificación o diseño conceptual o diseño de alto
nivel. Según (Durán Toro, Bernárdez Jiménez, Corchuelo Gil, &
Toro Bonilla, 2000) en (IEEE, 1990) se define: “Requisitos: (a)
una condición o capacidad que un usuario necesita para
resolver un problema o lograr un objetivo. (b) una condición o
capacidad que debe tener un sistema o un componente de un
sistema para satisfacer un contrato, una norma, especificación
u otro documento formal. (c) una representación en forma de
documento de una condición o capacidad como las expresadas
en (a) o (b).”

La ingeniería de requisitos se define como:

“Todas las actividades relacionadas con: (a) identificación y

documentación de las necesidades del cliente y usuarios, (b)
creación de un documento que describe la conducta externa y las
restricciones asociadas del sistema que satisfará dichas
necesidades. (c) análisis y validación del documento de requisitos
para asegurar su consistencia, viabilidad y que sea completo. (d)
Evolución de las necesidades.”

Existen varias propuestas en cuanto a las actividades que conlleva

la ingeniería de requisitos. Por su claridad, se ha utilizado la
presentada en (Durán Toro et al., 2000), que comprende tres
actividades principales: obtención, análisis y validación.

La mayor parte de las normas y autores asumen que el proceso de

obtención de los requisitos, su análisis y validación es iterativo por
naturaleza, ya que se reconoce que es prácticamente imposible
obtener todos los requisitos y que éstos sean correctos sin tener
que volver atrás en algún momento del proceso. Las actividades
son:

• Obtención (“Elicitation”1) de Requisitos: los clientes,

compradores o usuarios del sistema a desarrollar descubren,
revelan, articulan y entienden sus propios requisitos. Los
requisitos se obtienen con entrevistas, cuestionarios,
reuniones de las distintas partes implicadas y diversas
técnicas cuyo resultado deben ser los requisitos orientados al
cliente o también llamados requisitos-C.

(1 El término en inglés “elicitatión” se utiliza en la obtención de requisitos para

definir la actividad realizada por el analista con el fin de proteger la información
que de las necesidades del sistema tienen los usuarios finales, los expertos y los
clientes.)

• Análisis de requisitos: se debe razonar sobre los

requisitos- C para comprender mejor el problema, detectar
conflictos o inconsistencias, combinar requisitos relacionados
e identificar nuevos requisitos, normalmente mediante la
construcción de modelos, en la que podrían participar
aquellos clientes y usuarios con los conocimientos
apropiados. El producto de esta actividad son los requisitos
orientados al desarrollador o requisitos- D, y en algunas
ocasiones, un prototipo. Además, esta actividad debe ser
capaz de mostrar el conocimiento tácito, aquello que los
usuarios no comentan por olvidarlo o considerarlo obvio. En
esta fase ya se están tomando decisiones de cómo hacer el
sistema ya que se realiza una descomposición del sistema en
subpartes siguiendo la técnica de “divide y vencerás”.

• Validación de requisitos: los clientes y usuarios deben

confirmar que los requisitos- C, una vez analizados, son
válidos, correctos y completos, mediante las inspecciones de
los documentos generados y mediante la evaluación del
prototipo, proceso que por lo general conlleva la obtención de
nuevos requisitos. Además será necesario validar que los
requisitos -D encajan con los requisitos -C. La nomenclatura
de los requisitos (requisitos-C para los del cliente y requisitos-
D para los del desarrollador) fue presentada en (Brackett,
1990) y está siendo aceptada por algunos autores como
(Durán Toro et al., 2000). La manera habitual de expresar los
requisitos-C es el lenguaje natural, que puede acompañarse
del uso de plantillas y patrones lingüísticos para facilitar su
uso. La forma de expresar los requisitos –D suele ser
mediante un modelo construido con técnicas estructuradas
(DFD, ERD, etc), técnicas orientadas a objetos (OMT, UML,
etc) o técnicas formales. Dado que diversos estudios han
revelado que el alto índice de fracasos en los proyectos de
desarrollo software tiene como principales causas actividades
relacionadas con los requisitos (falta de participación de los
usuarios, requisitos incompletos y frecuentes cambios de los
requisitos iniciales), es lógico que muchos estudios se basen
 en esta etapa, por lo que las publicaciones relativas a la
ingeniería de requisitos han sido abundantes en los últimos
años (por ejemplo, los números especiales de las revistas
“IEEE Software” Marzo/Abril 1998 o el de “Communications of
the ACM” Diciembre 1998 así como diversos libros). Además,
existen multitud de métodos de modelado en general que se
utilizan para el modelado de los requisitos-D. Otro ejemplo
es el proyecto MENHIR: Metodologías, Entornos y Nuevas
Herramientas para la Ingeniería de Requisitos (Proyecto de la
CICYT TIC 97- 0593-C05-0).

• Diseño: también llamado diseño arquitectural o diseño de

bajo nivel. Partiendo del modelo de análisis de requisitos
obtenido en la fase anterior, se transforma éste en un
conjunto de entes físicos (hardware) y entes lógicos
(software) inter-relacionados entre sí que no tienen por qué
conservar la misma estructura que en el modelo inicial.
Cualquier cambio en dicha estructura con respecto a la del
modelo inicial debe ir acompañado de las razones que lo han
aconsejado, que suelen ser ciertas características que en su
momento no se conocía, o no se tuvieron en cuenta por ser
un aspecto de mayor nivel de detalle. Aunque en principio los
requisitos -C afectan principalmente a la fase de análisis de
requisitos y se utilizan para la creación de los requisitos -D
(que evidentemente influyen directamente en la fase de
diseño), puede darse el caso de que alguno de los requisitos
del cliente tengan efecto directo sobre esta fase de diseño.

• Implantación e Integración: también llamada codificación.

Consiste en la codificación del software utilizando un lenguaje
de programación siguiendo la estructura y comportamiento
determinados en el diseño. Revisiones del software que se
aplican durante cada paso del desarrollo del mismo Una vez
que se ha creado una especificación y un diseño de un
software, debe garantizarse su calidad. Las revisiones del
software son un filtro para el proceso de ingeniería del
software y se aplican en varios momentos del desarrollo.
Sirven para detectar fallos tanto en el análisis como en el
diseño y la codificación, de manera que puedan ser
eliminados cuanto antes. Es necesario partir de la idea de
que todo el mundo comete errores, pero algunos de ellos se
le pasan por alto más fácilmente al que los origina que a
otras personas. Los errores cometidos en pasos anteriores se
amplifican en el paso siguiente. Según las estadísticas, las
actividades de diseño introducen entre el 50 y el 65 por 100
de todos los errores, por lo que cualquier técnica que permita
detectar los errores en las fases iniciales del desarrollo del
software será de gran utilidad. Existen muchos tipos
diferentes de revisiones dependiendo de qué se revise y el
tipo de profesional que lo revise. Una de ellas son las
revisiones técnicas formales o inspecciones, llevadas a cabo
por ingenieros del software. Las revisiones técnicas formales
 son el filtro más efectivo desde el punto de vista de la
garantía del software, ya que detectan el 75% de los errores
cometidos en el diseño. Los objetivos de la revisión técnica
formal son:
(a) Descubrir errores en la función, la lógica o la implantación de
cualquier representación del software.
(b) Verificar que el software bajo revisión alcanza sus requisitos.
(c) Garantizar que el software ha sido representado de acuerdo
con ciertos estándares predefinidos.
(d) Conseguir un software desarrollado de forma uniforme.
(e) Hacer que los proyectos sean más manejables.

4.4. Estrategia de prueba

La prueba del software es un elemento crítico para la garantía de

calidad del software y representa una revisión final de las
especificaciones, del diseño y la codificación. La prueba requiere
que se descarten las ideas preconcebidas sobre la “corrección” del
software que se acaba de desarrollar y se supere cualquier conflicto
de intereses que aparezca cuando se detecten errores.
En un libro clásico sobre la prueba del software (Myers, 1979) se
establecen una serie de reglas que pueden entenderse como
objetivos de la prueba:

(a) La prueba es un proceso de ejecución de un programa con la

intención de descubrir un error.

(b) Un buen caso de prueba es aquel que tiene una alta

probabilidad de mostrar un error no descubierto hasta
entonces.

(c) Una prueba tiene éxito si descubre un error no detectado

hasta entonces.

Debido a la importancia de las pruebas para la calidad y a su

dificultad, existen múltiples técnicas de prueba. En (Press m, 1995)
se muestran algunas de estas técnicas de prueba. Procedimiento
que asegure un ajuste a los estándares de desarrollo del software.

 Gestión de configuraciones de software (control de la

documentación del software y de los cambios realizados)
La gestión de configuraciones del software es una actividad
“protectora” que se aplica a lo largo del proceso de
ingeniería del software. Se trata de un conjunto de
actividades de seguimiento y control que comienza al
principio del proyecto de desarrollo del software y finaliza
sólo una vez que el software queda fuera de circulación.
Los elementos que componen toda la información
producida se denominan configuración del software
(programas, documentos que describen los programas y
estructuras de datos). La elaboración de la documentación
 resulta muy costosa, por lo que es necesario intentar
reducirla lo más posible y realizarla cuando los beneficios
que conlleve superen el coste de su realización. Una de las
principales amenazas para la calidad del software viene de
una fuente aparentemente benigna: los cambios. El
proceso de control de cambios contribuye directamente a
la calidad del software.

 El control de cambios se aplica durante el desarrollo del

software y, posteriormente, durante su mantenimiento. Ya
que un cambio se puede producir en cualquier momento,
las actividades de la gestión de configuraciones del
software sirven para: (1) identificar el cambio; (2) controlar
el cambio; (3) garantizar que el cambio se implementa
adecuadamente; (4) informar del cambio a todos aquéllos
a los que afecte. En (Belin, 1998) se muestran de manera
resumida las ideas principales de la gestión de la
configuración.

 Mecanismos de medida. La medición es una actividad

fundamental para cualquier disciplina de ingeniería. Un
objetivo importante de la garantía de calidad es seguir la
pista a la calidad del software y evaluar el impacto de los
cambios de metodología y de procedimiento que intentan
mejorar la calidad del software. Para conseguirlo, se deben
recolectar métricas del software, como se verá más
adelante.

 Registro y realización de informes. Son procedimientos

para la recolección y divulgación de información de la
garantía de calidad del software. Los resultados de las
revisiones, auditorías, control de cambios, prueba y otras
actividades de la garantía de calidad deben convertirse en
una parte del registro histórico de un proyecto.
Además, deben ser divulgados a la plantilla de desarrollo
para que tenga conocimiento de ellos.
V. AUDITORIAS DE SEGURIDAD [5.1]

5.1 Auditorías Técnicas

Centrándonos ahora en las auditorías técnicas, dependiendo de la

profundidad de los trabajos, hablaremos de auditorías de
vulnerabilidades, que tratan de localizar configuraciones erróneas o
relajadas en exceso y agujeros de seguridad en el software directamente
explotables, habitualmente con el apoyo de herramientas que
automatizan parte del trabajo, y proyectos de hacking controlado,
pruebas de intrusión o auditorías a nivel de aplicación, en la que los
trabajos se expanden para dejar sitio al lado más "creativo y artesano"
de los auditores de seguridad, que tratan de explotar errores de
programación, la arquitectura de red y las relaciones de confianza, las
debilidades de los protocolos de comunicación y los controles de acceso
para simular los ataques a una infraestructura de red bajo los perfiles
que se consideren de interés (atacante externo con distinto nivel de
calificación, usuario interno, auditor, administrador, competencia...) bajo
las mismas circunstancias y capacidades (información inicial, puntos de
acceso, recursos disponibles...).
Por otro lado, dependiendo de la aproximación que tomemos para
realizar las auditorías técnicas, hablaremos de pruebas de caja negra,
que buscan las debilidades desde el exterior de los sistemas
(habitualmente realizadas de forma remota, desde Internet), y pruebas
de caja blanca, que realizan una revisión de seguridad analizando la
configuración del propio sistema, con acceso al mismo.

Una auditoría de seguridad de caja negra normalmente comienza con

trabajos desde el exterior, para encontrar puntos débiles y ganar algún
tipo de acceso a los sistemas, y una vez conseguido este acceso,
examinar el sistema para escalar privilegios y tomar control sobre él.
Estas pruebas desde hace tiempo se vienen realizando basándose en el
estándar OSSTMM (Open Source Testing Methodology Manual) o el
documento SP 800-46 del NIST (instituto de estándares americano) que
contemplan las pruebas a realizar para realizar una revisión de seguridad
técnica completa.

En el caso de una auditoría de caja blanca el objetivo no es lograr el

acceso (la empresa lo proporciona para realizarla) sino revisar las
medidas de seguridad implementadas en el sistema y su conformidad, o
no, con estándares reconocidos y guías de "buenas prácticas", como por
ejemplo, los trabajos del instituto de estándares norteamericanos, NIST,
el CSI, Center of Internet Security, o del SANS Institute.

5.1.1. PRUEBA DE CAJA BLANCA

Por el contrario, las pruebas de caja blanca, como se ha

mencionado anteriormente, examinan el sistema desde su interior.
Por lo tanto es necesario tener un acceso a los sistemas. Este
acceso generalmente se obtiene porque directamente se le
proporciona al auditor un acceso al equipo para que pueda realizar
un análisis en profundidad de la configuración del sistema, aunque
en algunos casos una prueba de caja negra se convierte en caja
blanca por haber logrado un acceso al sistema a través de alguna
vulnerabilidad del mismo u obtener información que pueda
analizarse de esta forma (por ejemplo, el código fuente de las
aplicaciones utilizadas).

Es importante destacar que estas pruebas son complementarias de

las anteriores, ya que el hecho de no haber encontrado
vulnerabilidades en las pruebas de "caja negra", no significa que no
las haya, si no que generalmente significará que no se han
dedicado recursos suficientes a descubrirlas. Dicho de otra forma,
el hecho de que un sistema sea o no vulnerable no radica en que se
encuentre una vulnerabilidad, si no en que exista dicha
vulnerabilidad.

Siguiendo con esta filosofía, es necesario ampliar la información

que se posee sobre los sistemas al máximo, incluyendo topología,
protocolos utilizados, reglas en los cortafuegos, software empleado,
etc. Así, durante esta fase normalmente se realizan las siguientes
tareas:

• Análisis de la configuración de todos los sistemas operativos

implantados: usuarios, ficheros, etc.
• Análisis de la robustez de las contraseñas utilizadas.
• Análisis de la configuración del software de base (Web, Mail,
cortafuegos, etc.).
• Análisis del código fuente de las aplicaciones instaladas o
desarrolladas a medida.
• Determinación de las vulnerabilidades presentes en los
sistemas debido a la desactualización en la aplicación de
parches de seguridad (obsolescencia de los sistemas).

En algunos casos estas tareas de análisis pueden ser

automatizadas con algunas herramientas pero en la mayoría de los
casos se realizarán de forma manual y requerirán de un
conocimiento profundo de los sistemas auditados,
recomendaciones del fabricante, etc. Generalmente estas
inspecciones, aunque más laboriosas hacen que la tarea analítica-
correctora produzca un resultado cualitativamente superior.

5.1.2. PRUEBA DE CAJA NEGRA

Las pruebas de caja negra, para que sean realmente efectivas,

deben realizarse sin ningún conocimiento de la infraestructura,
garantizando de esta forma que el análisis no tratará de utilizar
ningún tipo de información que facilite la tarea de análisis. El
propósito de estas pruebas es que el auditor se comporte como si
realmente fuese un "atacante" de la infraestructura. Durante un
análisis de caja negra normalmente se llevarán a cabo pruebas de
visibilidad (para conocer los servicios y versiones de éstos activos y
visibles desde el exterior en cada uno de los sistemas), pruebas de
iden-
tificación de servicios (para determinar qué programas ofrecen los
servicios ofrecidos, a través de las cabeceras obtenidas o
respuestas programáticas y no fiándose de la lista de puertos
TCP/IP conocidos), obtención de información (recuperación de
información o datos de configuración del sistema final o sistemas
adyacentes que desvelen detalles de la infraestructura auditada) y
pruebas de vulnerabilidades en software estándar.

Estas últimas pruebas son las más complejas y se realizarán una

vez determinados los servicios que se están corriendo, junto con la
información disponible de versiones y sistemas operativos. Se
basan en una parte que puede ser realizada por herramientas de
diagnóstico automáticas y otra parte que debe ser realizada de
forma manual por el auditor. Esta fase tiene que realizarse con
ciertas precauciones puesto que son frecuentes los casos en que
las pruebas de vulnerabilidades que puedan tener éxito produzcan
cortes de servicio o caídas en los sistemas auditados.
 Una vez se ha conseguido penetrar con éxito en un sistema, la
auditoría de caja negra puede continuar hacia otros sistemas
adyacentes (generalmente más expuestos una vez traspasado el
perímetro) y también derivar hacia análisis de caja blanca.

5.2. Tipos de Pruebas [5.2]

5.2.1. Pruebas de unidad:

La prueba de unidad se centra en el módulo. Usando la descripción

del diseño detallado como guía, se prueban los caminos de control
importantes con el fin de descubrir errores dentro del ámbito del
módulo. La prueba de unidad hace uso intensivo de las técnicas de
prueba de caja blanca.

5.2.2. Prueba de integración:

El objetivo es coger los módulos probados en la prueba de unidad y

construir una estructura de programa que esté de acuerdo con lo
que dicta el diseño.
Hay dos formas de integración:

• Integración no incremental: Se combinan todos los módulos

por anticipado y se prueba todo el programa en conjunto.
• Integración incremental: El programa se construye y se
prueba en pequeños segmentos.

En la prueba de integración el foco de atención es el diseño y la

construcción de la arquitectura del software.
Las técnicas que más prevalecen son las de diseño de casos de
prueba de caja negra, aunque se pueden llevar a cabo unas pocas
pruebas de caja blanca.

5.2.3. Prueba del sistema:

Verifica que cada elemento encaja de forma adecuada y que se

alcanza la funcionalidad y el rendimiento del sistema total. La
prueba del sistema está constituida por una serie de pruebas
diferentes cuyo propósito primordial es ejercitar profundamente el
sistema basado en computadora. Algunas de estas pruebas son:

• Prueba de validación: Proporciona una seguridad final de que

el software satisface todos los requerimientos funcionales y
de rendimiento. Además, valida los requerimientos
establecidos comparándolos con el sistema que ha sido
construido. Durante la validación se usan exclusivamente
técnicas de prueba de caja negra.
• Prueba de recuperación: Fuerza un fallo del software y verifica
que la recuperación se lleva a cabo apropiadamente.
• Prueba de seguridad: Verificar los mecanismos de protección.
 • Prueba de resistencia: Enfrenta a los programas a situaciones
anormales.
• Prueba de rendimiento: Prueba el rendimiento del software en
tiempo de ejecución.
• Prueba de instalación: Se centra en asegurar que el sistema
software desarrollado se puede instalar en diferentes
configuraciones hardware y software y bajo condiciones
excepciones, por ejemplo con espacio de disco insuficiente o
continuas interrupciones.

5.2.4. Pruebas de regresión:

Las pruebas de regresión son una estrategia de prueba en la cual

las pruebas que se han ejecutado anteriormente se vuelven a
realizar en la nueva versión modificada, para asegurar la calidad
después de añadir la nueva funcionalidad. El propósito de estas
pruebas es asegurar que:

• Los defectos identificados en la ejecución anterior de la

prueba se ha corregido.
• Los cambios realizados no han introducido nuevos defectos o
reintroducido defectos anteriores.

La prueba de regresión puede implicar la re-ejecución de cualquier

tipo de prueba. Normalmente, las pruebas de regresión se llevan a
cabo durante cada iteración, ejecutando otra vez las pruebas de la
iteración anterior.

5.3. Estrategias de pruebas del software:

Una estrategia de prueba del software integra las técnicas de diseño de

casos de prueba en una serie de pasos bien planificados que llevan a la
construcción correcta del software.

Las características generales son:

• La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.

• En diferentes puntos son adecuadas a la vez distintas técnicas de
prueba.
• La prueba la realiza la persona que desarrolla el software y (para
grandes proyectos) un grupo de pruebas independiente.
• La prueba y la depuración son actividades diferentes.

Una estrategia de prueba para el software debe constar de pruebas de

bajo nivel, así como de pruebas de alto nivel.

. Más concretamente, los objetivos de la estrategia de prueba son:

• Planificar las pruebas necesarias en cada iteración, incluyendo las

pruebas de unidad, integración y las pruebas de sistema. Las
pruebas de unidad y de integración son necesarias dentro de la
 iteración, mientras que las pruebas de sistema son necesarias sólo
al final de la iteración.
• Diseñar e implementar las pruebas creando los casos de prueba
que especifican qué probar, cómo realizar las pruebas y creando, si
es posible, componentes de prueba ejecutables para automatizar
las pruebas.
• Realizar diferentes pruebas y manejar los resultados de cada
prueba sistemáticamente. Los productos de desarrollo de software
en los que se detectan defectos son probadas de nuevo y
posiblemente devueltas a otra etapa, como diseño o
implementación, de forma que los defectos puedan ser arreglados.

Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas

consta de las siguientes etapas:

• Planificación de las pruebas.

• Diseño de las pruebas.
• Implementación de las pruebas.
• Ejecución de las pruebas.
• Evaluación de las pruebas.

Los productos de desarrollo del software fundamentales que se

desarrollan en la etapa de Pruebas son:

• Plan de Pruebas.
• Casos de Prueba.
• Informe de evaluación de Pruebas.
• Modelo de Pruebas, que incluye Clases de Prueba, Entorno de
Configuración de Pruebas, Componentes de Prueba y los Datos de
prueba.

Los participantes responsables de las realizar las actividades y los

productos de desarrollo del software son:

• Diseñador de pruebas: Es responsable de la planificación, diseño,

implementación y evaluación de las pruebas. Esto conlleva generar
el plan de pruebas y modelo de pruebas, implementar los casos de
prueba y evaluar los resultados de las pruebas. Los diseñadores de
prueba realmente no llevan a cabo las pruebas, sino que se
dedican a la preparación y evaluación de las mismas.
• Probador (Tester): Es responsable de desarrollar las pruebas de
unidad, integración y sistema, lo que incluye ejecutar las pruebas,
evaluar su ejecución, recuperar los errores y garantizar los
resultados de las pruebas.

Durante la fase de Inicio puede hacerse parte de la planificación inicial de

las pruebas cuando se define el ámbito del sistema. Sin embargo, las
pruebas se llevan a cabo sobre todo cuando un producto de desarrollo
software es sometido a pruebas de integración y de sistema. Esto quiere
decir que la realización de pruebas se centra en las fases de Elaboración,
cuando se prueba la línea base ejecutable de la arquitectura, y de
construcción, cuando el grueso del sistema está implementado. Durante
la fase de Transición el centro se desplaza hacia la corrección de defectos
durante los primeros usos y a las pruebas de regresión.

Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los

casos de prueba que especifican cómo probar los primeros productos de
desarrollo software pueden ser utilizadas también como casos de prueba
de regresión que especifican cómo llevar a cabo las pruebas de regresión
sobre los productos de desarrollo software siguientes. El número de
pruebas de regresión necesarias crece por tanto de forma estable a lo
largo de las iteraciones, lo que significa que las últimas iteraciones
requerirán un gran esfuerzo en pruebas de regresión. Es natural, por
tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del
software completo, aunque el modelo de pruebas cambia
constantemente debido a:

• La eliminación de casos de prueba obsoletos.

• El refinamiento de algunos casos de prueba en casos de prueba de
regresión.
• La creación de nuevos casos de prueba para cada nuevo producto
de desarrollo de software.

5.4. Auditoría de procesos y gestión

La realización de una actividad de auditoría debe realizarse siguiendo

fielmente los códigos de buenas prácticas de seguridad de sistemas de
información reconocidos internacionalmente, en este caso la norma ISO-
17799 y la guía del NIST SP 800-26. En Germinus entendemos que este
tipo de auditoría debe realizarse con un conocimiento previo de los
distintos riesgos y controles que son aplicables a una organización,
debido a la amplitud del código de buenas prácticas ISO-17799 no tiene
sentido auditar todos los controles recomendados si éstos no son
aplicables a la organización, bien porque no existe un riesgo en ese
sentido, bien porque el coste de implantación de dichos con-
troles se ha considerado superior al coste resultante de la materialización
de una amenaza (impacto) o del propio activo.

Es por ello que la actividad de auditoría de procesos y gestión estará

precedida por un trabajo de análisis del entorno de la organización
incluyendo:

• Análisis de la política de seguridad.

• Análisis de los procesos implantados, incluyendo, entre otros, los
de gestión y administración.
• Entrevistas con los responsables de la seguridad de información de
la organización para determinar los controles establecidos.
• Revisión de los análisis de riesgos realizados previamente y en
función de los cuales se han implantado los controles.
• Revisión de las auditorías previas realizadas.

Toda vez que se haya realizado el análisis del entorno se procederá a

realizar una revisión exhaustiva de los controles implantados, la correcta
implantación de los procedimientos y la concordancia con el código de
buenas prácticas. Para ello se realizarán entrevistas con distinto personal
de la organización, el personal concreto a entrevistar será definido
basándose en el estudio del entorno y de la organización previamente
realizado. Entre el personal entrevistado se incluirán a:

• Los responsables de gestión.

• El personal técnico encargado de la gestión de la seguridad de
cada uno de los sistemas.
• Usuarios de los sistemas de información (muestra aleatoria)
 ANEXO 1
PLAN DE DESARROLLO DE SOFTWARE

Fase de Elaboración (4 semanas de duración) Comienzo Aprobación

Modelado del Negocio

Modelo de Casos de Uso del Negocio y Semana 1 aprobado

Modelo de Objetos del Negocio

Requisitos

Glosario Semana 1 aprobado

Visión Semana 2 aprobado

Modelo de Casos de Uso Semana 3 aprobado

Especificación de Casos de Uso Semana 3 aprobado

Especificaciones Adicionales Semana 2 aprobado

Análisis/Diseño

Modelo de Análisis/Diseño Semana 2 Semana 9

Modelo de Datos Semana 2 Semana 9

Implementación

Prototipos de Interfaces de Usuario Semana 2 Semana 10

Modelo de Implementación Semana 2 Semana 10

Pruebas
 Casos de Pruebas Funcionales Semana 2 Semana 9

Despliegue

Modelo de Despliegue Semana 2 Semana 9

Gestión de Cambios y Configuración Durante todo el proyecto

Gestión del proyecto

Plan de Desarrollo del Semana 7 Semana 7

Software en su versión 3.0
y planes de las Iteración 2
de Elaboración
Ambiente Durante todo el proyecto

ANEXO 2
MODELO DE UN PLAN DE CONFIGURACIÓN DE SOFTWARE
[6]
Generalidades

A lo largo del ciclo de vida del proceso de software, los productos

de software evolucionan. Desde la concepción del producto y la
captura de requisitos inicial hasta la puesta en producción del
mismo, y posteriormente desde el inicio del mantenimiento hasta
su retiro, se van realizando una serie de cambios, tanto en el
código como en la documentación asociada. La Gestión de
Configuración del Software es una disciplina encargada del control
de la evolución de los productos de software.
Como todo proceso, la Gestión de Configuración también puede ser
sistematizada y automatizada, lo que se denomina un Sistema de
Gestión de Configuración (SGC). Actualmente existen en el
mercado diversas herramientas que permiten apoyar una o más
actividades de la Gestión de Configuración.

Definiciones

Gestión de Configuración es el proceso de identificar y definir los

elementos en el sistema, controlando el cambio de estos elementos
a lo largo de su ciclo de vida, registrando y reportando el estado de
los elementos y las solicitudes de cambio, y verificando que los
elementos estén completos y que sean los correctos.

El propósito de la Gestión de Configuración del Software es

establecer y mantener la integridad de los productos de
software a través del ciclo de vida del proceso de software.

La Gestión de Configuración del Software implica la identificación

de la Configuración del software en puntos dados en el tiempo, el
control sistemático de los cambios en la Configuración y el
mantenimiento de la integridad y trazabilidad de la Configuración a
través del ciclo de vida del software. Los productos incluidos son:

• Software distribuido al cliente.

• Documentos de requerimientos del software.

• Código.

• Elementos requeridos para crearlos (ejemplo: el compilador)

Aspectos Funcionales

1. Identificación: Se necesita definir un esquema de identificación

para reflejar la estructura del producto, esto involucra identificar la
estructura y clases de componentes, dando a cada uno un nombre,
una identificación de versión y una identificación de Configuración.

2. Control: Se deben controlar los cambios que se le hacen a

través del ciclo de vida, asegurando que el software sea
consistente a través de la creación de una línea base del producto.

3. Estado: Se debe registrar y reportar el estado de los

componentes y solicitudes de cambio.

4. Auditoria y revisión: Se debe validar que el producto este

completo y asi mantener la consistencia entre los componentes,
asegurando que estén en un estado apropiado a través de todo el
ciclo de vida del producto y que el mismo sea una colección bien
definida de componentes.

ALGUNOS CONCEPTOS PRESENTES EN LA DISCIPLINA

Configuración

Las características funcionales y físicas de una versión especifica

de hardware y elementos de software que combinados de acuerdo
a procedimientos de construcción específicos cumplen un propósito
particular.

Elementos de configuración de software

Definimos como un elemento de Configuración a una unidad física

y/o lógica parte de un conjunto mayor de elementos, producida o
adquirida, que por sus características es distinguible de las demás
y cuya evolución interesa administrar.

Son elementos de Configuración en un proyecto de software:

01. El plan de proyecto.
02. El plan de Gestión de Configuración.
03. El documento de definición de requerimientos.
04. Estándares de análisis, diseño, codificación, pruebas, y
auditoria.
05. Documentos de análisis del sistema.
06. Documentos de diseño del sistema.
07. Prototipos.
08. Documentos de diseño de alto nivel.
09. Documentos de diseño de bajo nivel.
10. Especificaciones de prueba del sistema.
11. El plan de pruebas del sistema.
12. El Código fuente del programa.
13. Código objeto y ejecutable.
14. Especificaciones de pruebas de unidad.
15. Planes de pruebas de unidad.
16. Documentos de diseño de base de datos.
17. Datos de prueba.
18. Datos del proyecto.
19 .Manuales de usuario.

Versión

Una versión es una instancia de un elemento de Configuración. El

término se usa para señalar a un elemento de Configuración del
software que tiene un conjunto definido de características
funcionales.

Revisión

Se define revisión como una versión que se construye sobre otra

versión anterior. El término revisión generalmente se asocia a la
noción de corrección de errores, esto es, hacer cambios a un
programa que corrigen solo errores en el diseño lógico pero no
afectan las capacidades funcionales documentadas, dado que
ningún requerimiento ha cambiado.

Variante
Se define variante como una versión que es una alternativa a otra
versión. Las variantes pueden permitir a un elemento de
Configuración satisfacer requerimientos en conflicto. Una variante
es una nueva versión de un elemento que será añadida a la
Configuración sin reemplazar a la versión anterior.

Por ejemplo, si se desarrolla una aplicación para varios sistemas

operativos, algunas librerías pueden requerir modificaciones para
poder ser compiladas o ejecutadas en los diferentes sistemas; la
versiones para Unix y para Windows NT de una librería serían
variantes del mismo elemento.

Línea base

Una línea base es una especificación o producto revisado y

aprobado formalmente, que sirve como base para el desarrollo
posterior, y puede ser modificado solo a través de procedimientos
formales de control de cambios.

El término también se usa para referirse a una versión particular de

un elemento de software que ha sido aprobado. En cualquier caso,
la línea base solo se puede modificar a través de procedimientos
formales de control de cambios. Una línea base, junto con todos los
cambios aprobados a la línea base, representa la Configuración
aprobada actual.

Procesos Asociados

El estándar ISO/IEC 12207 ([ISO 12207]) para Procesos del Ciclo

de Vida del Software, establece el Proceso de Gestión de
Configuración como uno de los Procesos de Soporte del Ciclo de
Vida. Un Proceso de Soporte ”apoya” a otro proceso como una
parte integral, con un propósito distinto, y contribuye al éxito y a la
calidad del proyecto de software.

Este proceso consiste de las siguientes actividades:

1. Implementación del Proceso: Se desarrolla un Plan de

Gestión de Configuración que describe las actividades de
Gestión de Configuración, los procedimientos y el cronograma
para su realización, y los responsables de dichas actividades.
Dicho plan debe ser documentado e implementado.

2. Identificación de la Configuración: Se establece un

esquema de identificación de los elementos de software y sus
versiones a ser controlados por el proyecto.

3. Control de la Configuración: Se identifican y registran

 las solicitudes de cambio, se analiza y evalúa los cambios, se
aprueba o rechaza la solicitud, se implementa, verifica y
distribuye el elemento de software modificado.

4. Contabilidad de Estado de la Configuración: Se

preparan registros de Gestión y reportes de estado que
muestren el estado e historia de los elementos de software
controlados, incluyendo líneas base.

5. Evaluación de la Configuración: Se determina y asegura

que los elementos de software sean funcionalmente (versus
sus requerimientos) y físicamente completos (es decir, si su
diseño y Código reflejan una descripción técnica actualizada).

6. Gestión de actualización y distribución: Se controla

formalmente la actualización y distribución de los productos
de software.

En la figura 1 se presenta un modelo de este proceso elaborado

utilizando el perfil de UML para modelamiento de procesos de software,
propuesto por el Object Management Group (OMG)

El estándar IEEE Std. 1074-1995 ([IEEE 1074]) para el

Desarrollo de Procesos del Ciclo de Vida del Software, establece el
Proceso de Gestión de Configuración del Software como uno de los
Procesos Integrales. Estos son los Procesos necesarios para
completar exitosamente las actividades del proyecto, y son
utilizados para asegurar la finalización y calidad de las funciones
del proyecto. Este proceso consiste de las siguientes actividades:

1. Planificar la Gestión de Configuración.

2. Desarrollar la Identificación de la Configuración.
 3. Realizar el Control de la Configuración.
4. Realizar la Contabilidad de Estado.

Escenarios de Configuración en el Proceso de Software

Gestión de configuración del código fuente

La evolución del Código fuente es quizás el ejemplo mas claro en la

Gestión de Configuración. A lo largo del desarrollo (y
posteriormente en el mantenimiento) las modificaciones al software
se realizan sobre el Código fuente. Y es según el Código fuente que
se valida la documentación asociada.

Los sistemas administradores de versiones se suelen integrar a los

entornos de desarrollo y realizan administración de versiones del
Código fuente. Cada modificación de uno de los archivos del
programa va generando una revisión del mismo, y periódicamente
se crean líneas base de todo el proyecto.

De este modo, un equipo de desarrollo puede trabajar en paralelo,

compartiendo versiones de archivos de Código fuente y
actualizándolos periódicamente según se van creando o
modificando los archivos que conforman el proyecto.

Gestión de configuración en el desarrollo de software

Como ya habíamos comentado, un elemento de Configuración

puede ser prácticamente cualquier producto o subproducto del
desarrollo de software. Las especificaciones de requisitos, los
documentos de análisis y de diseño, el Código fuente y ejecutable,
y los procedimientos y datos de prueba pueden ser sometidos a
control de Configuración.

Con un control riguroso, es posible entonces mantener registro del

estado de todos estos elementos, lo que facilita la introducción de
cambios si se tiene registro de las dependencias entre ellos,
además de facilitar la elaboración de entregables; por ejemplo, si
se tiene registro de las dependencias entre los elementos de
Configuración, es posible que si se produce un cambio en las
especificaciones, los documentos de análisis y diseño y el Código
fuente asociados puedan ser actualizados sin que tome demasiado
tiempo realizar su búsqueda.

Gestión de configuración en el mantenimiento de software

En el mantenimiento de software, cobra importancia la función del

Comité de Control de Cambios (CCC), que se encarga de recibir,
estudiar y aprobar las solicitudes de cambio en el software que son
presentadas, sea por los usuarios o por los propios encargados del
mantenimiento. En este caso, las funciones de control y de
auditoria se vuelven casi indispensables, pues es necesario
mantener registro de todas las solicitudes de cambio presentadas y
del estado actual de cada una de ellas. Un sistema de Gestión de
Configuración que apoye la Gestión de solicitudes de cambio,
debería permitir el registro por parte de los usuarios de las
solicitudes de cambio, su revisión por parte del CCC, y si son
aprobadas la creación de ordenes de cambio.

Un cambio implica generalmente la actualización tanto del Código

fuente, como de los documentos de especificación de requisitos,
análisis y diseño, casos de prueba y manuales. Por lo tanto, en el
escenario anterior, resulta de utilidad mantener un registro de las
dependencias entre los elementos de Configuración. El cambio se
vera reflejado en la creación de nuevas versiones de los elementos
respectivos.

Gestión en la distribución del software a las PC- Usuarios

Cuando se pone en producción un software, se distribuyen copias

del mismo entre los diversos usuarios del sistema. En este
escenario, un sistema de Gestión de Configuración debería permitir
registrar las Configuraciones (conjunto de versiones de elementos
de Configuración) que cuenta cada PC - usuario. Puede ocurrir, que
si un mismo sistema se vende a distintos clientes, en algún
momento surjan requerimientos contradictorios o necesidades que
lleven a la creación de variantes de los elementos de
Configuración. El sistema de Gestión de Configuración apoyaría
entonces al momento de estudiar una solicitud de un usuario a
conocer cual es la Configuración con la que esta trabajando.

Modelo Genérico
1. Permite la creación de tipos de elementos de Configuración. De
este modo, es posible que el usuario cree sus propios tipos de
elementos dependiendo que es lo que desea controlar.

2. Permite la creación de tipos de relaciones entre los elementos de

Configuración. Es posible que el usuario cree los tipos de relaciones
que desee, y que especifique dependencias para la creación de
nuevas versiones entre el origen y el destino de la relación. Estas
dependencias pueden ser:
• Ninguna,
• Condicional-Origen (sí el origen cambia, el destino
podría cambiar)
• Condicional-Destino (sí el destino cambia, el origen
podría cambiar)
 • Obligatoria-Origen (sí el origen cambia, el destino debe
cambiar)
• Obligatoria-Destino (si el destino cambia, el origen debe
cambiar).

3. Cada tipo de elemento y cada tipo de relación puede tener los

campos de información adicional que el usuario considere
necesarios.

4. Un elemento de Configuración corresponde a un tipo y sus

versiones pueden estar relacionadas con versiones de otros
elementos según se creen relaciones para él.

5. Un elemento de Configuración tiene un conjunto de versiones

asociadas, cada una de las cuales esta asociada al usuario (dueño)
que la creo.

6. Un conjunto de versiones de elementos de Configuración

conforma una Configuración. Es posible de este modo registrar
muchas Configuraciones para el mismo software, que pueden
diferir en cuanto a versiones, o ser variantes (Configuraciones
alternativas).

De este modelo es posible obtener información acerca de:

1. Los tipos de elementos sometidos a Gestión de Configuración.
2. Las relaciones entre dichos elementos.
3.Las dependencias para la creación de versiones al momento de
analizar la introducción de un cambio. Es posible conocer como un
cambio en un elemento afectara a los demás.
4. Los usuarios que generaron cada versión de un elemento.

ANEXO 03

Descripción Detallada del SPMP

Planes de Gestión de Proyectos Software

Pagina de Título
Carta de Revisión
Prefacio
Tabla de Contenidos
Lista de Figuras
Lista de Tablas
1 Introducción
1.1 Alcance
1.2 Propósito
1.3 Acuerdo del proyecto
1.4 Evolución de SPMP
2 Referencias
3 Definiciones
4 Organización del Proyecto
4.1 Modelo de Proceso
4.2 Estructura Organizacional
4.3 Limites e Interfaces Organizacionales
4.4 Responsabilidades del Proyecto
5 Procesos Administrativos
5.1 Objetivos y Prioridades Administrativas
5.2 Dependencias, Restricciones y Supuestos.
5.3 Procesos Integrales
5.4 Gestión del Alcance Administrativo
5.5 Planes de gestión del Itinerario
5.6 Plan de gestión del Presupuesto
5.7 Plan de gestión de los Recursos
5.8 Planes de gestión de la Calidad
5.9 Planes de gestión de Riesgos
5.10 Planes de Obtención de Recursos
5.11 Planes de Manejo Comunicacional
6 Procesos Técnicos
6.1 Alcance del Producto
6.2 Métodos, Herramientas y Técnicas
6.3 Documentación del Software
 7 Planificación de las Actividades del Trabajo
7.1 Definiciones de las Actividades y Alcance
7.2 Dependencia de las Actividades
7.3 Itinerario de Actividades
7.4 Presupuesto de Actividades
7.5 Requerimientos de Recursos de las Actividades
8 Componentes Adicionales
8.1 Anexo

Página de título: Contiene el título de y una nota de revisión para identificar

unívocamente el documento.

Carta de revisión: Es una hoja separada que contiene el número de versión

del documento, la fecha de revisión, firma de aprobación, una lista de las
páginas que han sido modificadas en la actual versión y una lista de los
números de versión y fechas de revisión para cada una de las versiones previas
del SPMP.

Prefacio: Indica el alcance de las actividades del SPMP.

Tabla de contenido y las listas de figuras y tablas: Proveen los títulos y

los números de página.

1 Introducción
Esta parte provee una revisión tanto del proyecto como del producto a ser
confeccionado. El alcance del proyecto y el producto, una lista de la entrega del
proyecto y las consideraciones de evolución para e SPMP.

1.1 Alcance
Esta parte definiría el alcance tanto del proyecto como del producto a ser
entregado.

1.2 Propósito
Aquí se provee una resumida declaración de las necesidades del negocio
a ser satisfechas por el proyecto, con un conciso resumen de los
objetivos del proyecto.

1.3 Acuerdo del proyecto

En esta parte se listan los productos que van a ser entregados al cliente,
las fechas y lugar de entrega y la cantidad requerida para satisfacer los
acuerdos del proyecto.

1.4 Evolución del SPMP

Se especifica que mecanismos son usados para lograr la versión inicial
del SPMP y cambios de control del SPMP.

2 Referencias
Se provee una completa lista de todos los documentos y otros recursos de
información referenciados en el SPMP. Cada documento puede ser identificado
por el título, número de edición, fecha, autor, y organización editora. Otros
recursos, como los archivos electrónicos, deben ser identificados de una
manera no ambigua usando identificadores como la fecha y número de versión.
3 Definiciones
Se puede definir o provee referencias de la definición de todos los términos y
acronismos requeridos para interpretar adecuadamente el SPMP.

4 Organización del Proyecto

Esta parte especifica el modelo del proceso para el proyecto, describe la
estructura organizacional del proyecto, identifica el fin de la organización y
define las responsabilidades individuales para el proyecto.

4.1 Modelo de Procesos

Esta parte define las relaciones entre las funciones del proyecto principal
y las actividades por especificación de tiempo. El modelo de proceso
puede ser descrito usando una combinación de gráficos y notación
textual.

4.2 Estructura Organizacional

Esta parte describe la estructura de organización interna del proyecto.
Herramientas gráficas tales como una matriz de diagramas podría ser
usada para describir las líneas de autoridad, responsabilidad y
comunicación dentro del proyecto.

4.3 Limites e Interfaces Organizacionales

Aquí se describe los limites administrativos y gerenciales entre el
proyecto y cada una de las siguientes entidades: La organización de
origen, la organización del cliente, la organización subcontratada, o
cualquier otra organización que interactua con el proyecto.

4.4 Responsabilidades del Proyecto

En esta parte se identifica el estado natural de cada función y actividad
del proyecto principal, y identifica individualmente quienes son
responsables por esas actividades y funciones. Una matriz de funciones y
actividades versus responsabilidades individuales pueden ser usadas
para describir las responsabilidades del proyecto.

5 Procesos Administrativos
Esta parte especifica los procesos administrativos del proyecto que deben ser
consistentes con la declaración del alcance y puede incluir objetivos y
prioridades administrativas.

5.1 Objetivos y Prioridades Administrativas

Especificar la filosofía, metas y prioridades para la administración de las
actividades durante el proyecto. Tópicos específicos que pueden ser
incluidos son la frecuencia y mecanismos de reporte a ser usados, las
prioridades relativas entre los requerimientos y presupuesto del proyecto,
procedimientos administrativos de riesgos a seguir y una nota para la
adquisición, modificación y uso del software existente.

5.2 Dependencias, Restricciones y Supuestos

Condiciones sobre las cuales el proyecto esta basado, los eventos
externos de los cuales el proyecto depende y las restricciones con las
cuales el proyecto va a ser elaborado.
5.3 Procesos Integrales
Planifica los procesos integrales necesarios para una exitoso término de
los proyectos sw. Esos procesos pueden incluir: la configuración de
manejo, asegurar la calidad, verificación y validación del sw.

5.4 Gestión del Alcance Administrativo

Se especifica el plan de manejo del alcance del proyecto, también puede
incluir procedimientos para cambios en el alcance del SPMP, además de
la probabilidad de cambios, incluyendo los factores que pudiesen resultar
por el cambio del alcance del proyecto. El plan indicaría factores que
causaron el cambio, los resultados de los cambios y los métodos por los
cuales los cambios fueron documentados, comunicados y controlados.

5.5 Planes de Manejo del Itinerario.

Se define los planes para asegurar que el proyecto este terminado a
tiempo, además de, especificar los documentos que sirven como entrada
al proyecto. Se deben especificar las herramientas o metodología que
serán usadas para administrar el itinerario.
El plan indicaría factores que causaron el cambio, los resultados de los
cambios y los métodos por los cuales los cambios fueron documentados,
comunicados y controlados.

5.6 Plan de Manejo del Presupuesto

Se definen los planes para asegurar que el proyecto sea terminado con el
presupuesto establecido, además de especificar los documentos que
sirven como entrada al presupuesto. Se deben especificar las
herramientas o metodología que serán usadas para administrar el
presupuesto.
El plan indicaría factores que causaron el cambio, los resultados de los
cambios y los métodos por los cuales los cambios fueron documentados,
comunicados y controlados.

5.7 Plan de Manejo de los Recursos

Se especifica los planes de manejo de los recursos requeridos para la
exitosa culminación de esta. El plan puede especificar los métodos
usados para estimar el material, servicios y requerimientos de recursos
humanos. Se puede incluir el número y nivel de calificación del personal
requerido para completar el proyecto, el número y atributos de calidad
requerida por el personal y la naturaleza de los servicios contratados.

5.8 Planes de Manejo de la Calidad

El plan para asegurar la calidad de los procesos y del proyecto se define
en este apartado. El plan puede identificar los estándares del proyecto y
los métodos y recursos requeridos para implementar y asegurar el
cumplimiento de esos estándares.

5.9 Planes de Manejo de Riesgos

Se definen los planes de manejo de factores de riesgos asociados al
proyecto. Esta parte describe los métodos que serían usados para
identificar los factores de riesgo, como fueron evaluados y impacto
potencial de los riesgos identificados.
 5.10 Planes de Obtención de Recursos
Esta parte incluiría una descripción de los procesos de obtención de
recursos, incluyendo responsabilidades para todos los aspectos del
proceso. El plan podría incluir los procesos de obtención tangible e
intangible de recursos; procesos de obtención de: equipamiento,
estimaciones de tiempo de computado, Hw. y Sw. y transportes.

5.11 Planes de Manejo Comunicacional

Esta parte maneja la comunicación relativa del proyecto. Se definirían los
mecanismos de reporte, formas de reporte, información anticipada,
mecanismos de intervención, y otras herramientas y técnicas usadas
para monitorear y controlar los objetivos del proyecto.

6 Procesos Técnicos
Esta parte planea el manejo del alcance del producto, los métodos técnicos,
herramientas y técnicas usadas para la entrega del producto y documentación
del software.

6.1 Alcance del Producto

Esta parte contempla los planes de manejo del alcance del producto. En
este plan serían incluidos los métodos por los cuales el alcance del
proyecto va a ser medido además de los requerimientos del producto,
además se incluye los factores que pueden cambiar el alcance del
producto.

6.2 Métodos, Herramientas y Técnicas

Este parte describe el sistema de computación, metodologías de
desarrollo, estructuras de equipos, lenguaje de programación,
herramientas y técnicas a ser usadas para la especificación, diseño,
construcción, test, integración, documentos, modificaciones y
mantención del proyecto.

6.3 Documentación del Software

Se describe los planes de documentación para el proyecto software. Los
planes de documentación especificarían los requerimientos de
documentación y la importancia, referencias, revisiones para la
documentación del sw. El plan de documentación puede además
contener un estilo de guía, convenciones de nombre y formatos de
documentación.

7 Planificación de las Actividades del Trabajo

Esta parte definen las actividades y sus alcances, identifica las relaciones de
dependencia entre las actividades, estado de los recursos, asegurar la calidad
y las consideraciones de riesgo.

7.1 Definiciones de las Actividades y Alcance

Aquí se especifican y definen las actividades a ser completadas para
satisfacer los requerimientos del proyecto. El alcance de cada actividad
seria claramente definida, esta identificación puede ser basada sobre la
numeración de proyectos y/o títulos descriptivos.
 7.2 Dependencia de las Actividades
Se especifica el orden entre las actividades del proyecto y tareas
asociadas para describir las relaciones de dependencia entre actividades
y eventos externos.

7.3 Itinerario de Actividades

Estas listas expresan calendarios de tiempo o de incrementos relativos
del producto clave sobre el proyecto principal.

7.4 Presupuesto de Actividades

Especifica el presupuesto de varias tareas y actividades.

7.5 Requerimientos de Recursos de las Actividades

En esta parte se especifica, como una función de tiempo, los recursos
totales estimados para completar la actividad. Números y tipo de
personal, soporte de software y hardware y requerimientos de
mantención para las actividades del producto y tareas.

8 Componentes Adicionales
Ciertos componentes adicionales que puedan ser requeridos pueden ser
incluidos para ser anexados como material adicional al SPMP.

8.1 Anexo
Incluiría detalles específicos del personal, detalles de los costos
estimados, detalles de las estructuras de trabajo “breakdown” e
información suplementaria para una adecuada comprensión del SPMP

Fuentes
1: Tipos de Software,
http://tecnomaestros.awardspace.com/tipos_software.php,
2: Metodología y software para la construcción y seguimiento del Cuadro de
Mando Integral en las TIC´s (European Software Institute),
http://winred.com/management/metodologia-y-software-para-la-construccion-y-
seguimiento-del-cuadro-de-mando-integral-en-las-tic-s/gmx-niv116-
con1642.htm,
3: Control de versiones, http://es.wikipedia.org/wiki/Control_de_versiones,
4: Diagrama de Gantt, http://es.wikipedia.org/wiki/Diagrama_de_Gantt,
5: Técnica de revisión y evaluación de programas,
http://es.wikipedia.org/wiki/PERT,
5.1: Auditorias de Seguridad,
www.germinus.com/sala_prensa/articulos/Auditorias%20Seguridad.pdf,
5.2: Fase de Pruebas,
http://lsi.ugr.es/~arroyo/inndoc/doc/pruebas/pruebas_d.php,
6: Gestión de Configuración del Software,
http://www.histaintl.com/soluciones/configuracion/configuracion.php,