PROCESOS DE INGENIERÍA DEL SOFTWARE
Armando Cabrera Raquel Solano Mayra Montalván
Loja, Ecuador Loja, Ecuador Loja, Ecuador
aacabrera@utpl.edu.ec rfsolano@utpl.edu.ec mamontalvan@utpl.edu.ec
RESUMEN “Cuando puedas medir lo que estás diciendo y expresarlo en
números, sabrás algo acerca de eso; pero cuando no puedes
El proceso de Ingeniería del Software se basa en modelos, medirlo, cuando no puedes expresarlo en números, tus
métodos y herramientas que sirven como una guía para los conocimientos serán escasos y no satisfactorios”
ingenieros del software durante el proceso de desarrollo, con la
finalidad de mejorar la calidad de los proyectos, procesos y Lord Kelvin
productos mediante la evaluación y medición de los mismos. El
objetivo de las organizaciones desarrolladoras de estos modelos, La medición en general tiene tres principales objetivos: entender
procesos y metodologías es que en las empresas desarrolladoras qué ocurre durante el desarrollo y el mantenimiento, mejorar
de software se los ponga en práctica para ver las mejoras en los nuestros procesos y nuestros productos y controlar lo que ocurre
procesos de cada una de las fases de desarrollo. Otro tema en nuestros proyectos. Dentro de la gestión de proyectos de
importante son los modelos del ciclo de vida del software, los desarrollo de software las métricas juegan un papel importante
cuales se basan en diferentes técnicas y fases pero todos tienen un para entender, monitorizar, controlar, predecir y probar el
mismo fin. desarrollo de software. Las métricas son medio para asegurar la
calidad en los PRODUCTOS / PROCESOS / PROYECTOS
El fin de este trabajo es establecer un entorno general alrededor de SOFTWARE.
las aplicaciones y definiciones actuales del Proceso de Ingeniería
del Software, el mismo que puede reconocerse en dos niveles: el Objetivos
primero involucra actividades técnicas y de gestión durante la Los principales objetivos del desarrollo de este trabajo son:
adquisición, desarrollo, mantenimiento y retirada del software en
el procesos del ciclo de vida del software y el segundo se refiere a • Comprender los conceptos principales relacionados con
la definición, implementación, valoración, medición, gestión, el proceso de ingeniería de software y ciclo de vida del
cambios y mejoras de los procesos mismo del ciclo de vida del software.
software. Algunos modelos estandarizados para la medición de la • Conocer los métodos y modelos que se aplican
calidad como lo son: CMMI e ISO 9000, son mencionados. actualmente en la ingeniería del software.
• Conocer los principales ciclos de vida del software.
Términos Generales
Software, Procesos, Métodos, Modelos, Desarrollo de Software, 2.ESTADO DEL ARTE
Ingeniería del Software, Procesos del Software
Palabras claves 2.1 Conceptos de procesos de ingeniería del
CMMI software
QIP
Modelo Ágil
RUP
Modelo Cascada
1.INTRODUCCIÓN
El proceso de ingeniería del software puede ser visto desde dos
enfoques: El primero: ciclo de vida del software, procesos durante
la adquisición, desarrollo, mantenimiento y cierre y el segundo
con definición, implementación, evaluación, manejo, cambio y
mejora del ciclo de vida del software
El principal objetivo del manejo del proceso de vida de software
es implementar nuevos o mejores procesos en prácticas actuales y Figura 1. Elementos del proceso de software [6]
que sean aplicados en el desarrollo de software, tales modelos
como CMMI, IDEAL, QIP, entre otros.

cuatro grandes fases: concepción, elaboración, construcción y
transición.
• Concepción: Define el alcance del proyecto y
desarrolla un caso de negocio.
• Elaboración: Define un plan del proyecto, especifica
las características y fundamenta la arquitectura.
• Construcción: Crea el producto.
• Transición: Transfiere el producto a los usuarios.
En la Figura 1, se muestra los elementos principales del proceso
de Software que son: Personal. Métodos y Procedimientos y
Herramientas y Tecnologías.
En la Figura 2, se muestra los tipos de elementos para modelar o
representar un Proceso de Software
Figura 2. Tipos de elementos para modelar/representar un
Proceso Software [6] 2.1.4Ciclo de vida del Software
2.1.1Proceso de Software Un concepto dado por IEEE 1074 [6] es, el ciclo de vida del
software es una aproximación lógica a la adquisición, el
Según Piatini [2] El proceso de software es un conjunto coherente
suministro, el desarrollo, la explotación y el mantenimiento del
de: políticas, estructuras organizacionales, tecnologías,
software”
procedimientos y artefactos; que son necesarios para: concebir,
Y otro concepto dado por ISO 12207 “Es un marco de referencia
desarrollar, instalar y mantener un producto software.
que contiene los procesos, las actividades y las tareas
2.1.2Ingeniería del Software involucradas en el desarrollo, la explotación y el mantenimiento
de un producto de software, abarcando la vida del sistema desde
Se puede decir que Ingeniería de software [1], es la disciplina o la definición de los requisitos hasta la finalización de su uso”
área de la informática que ofrece métodos y técnicas para
desarrollar y mantener software de calidad.
2.2Procesos de implementación y cambios
Existen algunos conceptos de Ingenierita del Software, a 2.2.1Modelos para Procesos de Implementación y
continuación se lista conceptos de autores más reconocidos: Cambios
• Ingeniería de Software es el estudio de los principios y
metodologías para el desarrollo y mantenimiento de A continuación se trata dos modelos principales para
sistemas software (Zelkovitz, 1978) mejoramiento de procesos: Modelo IDEAL y modelo QIP
(Quality Improvement Paradigm)
• Ingeniería de software es la aplicación práctica del
conocimiento científico al diseño y construcción de
programas de computadora y a la documentación 2.2.1.1Modelo IDEAL
asociada requerida para desarrollar, operar y
mantenerlos. Se conoce también como Desarrollo de
Software o Producción de Software (Bohem, 1976).
• Ingeniería de Software trata del establecimiento de los
principios y métodos de la ingeniería a fin de obtener
software de modo rentable, que sea fiable y trabaje en
máquinas reales (Bauer, 1972).
• Es la aplicación de un enfoque sistemático, disciplinado
y cuantificable al desarrollo, operación y mantenimiento
del software; es decir, la aplicación de la ingeniería al
software (IEEE, 1993).
2.1.3Proceso de Ingeniería del Software
El proceso de ingeniería de software [3], se define como "un
conjunto de etapas parcialmente ordenadas con la intención de Figura 3. Modelo IDEAL [23]
lograr un objetivo, en este caso, la obtención de un producto de
software de calidad" [Jacobson 1998]. A este proceso
El modelo IDEAL [4], es un ciclo de mejoramiento de procesos,
también se le llama el ciclo de vida del software que comprende
proporciona un conjunto de actividades coherentes para sustentar

la adopción de las prácticas recomendadas por el CMM, teniendo
variaciones de una entidad a otra dependiendo del tipo de
industria de software, tamaño de organización y modalidades de
operación.
Las 5 fases principales que componen el modelo son:
1. Iniciar.- Establece los fundamentos básicos para
garantizar la iniciativa de mejoramiento de procesos.
Cuyas actividades son:
a. Estimulo para iniciar el mejoramiento
b. Establecimiento del contexto
c. Establecer patrocinio de la gerencia
d. Establecer infraestructura para el
mejoramiento
e. Evaluar y caracterizar el estado actual de las
practicas
Figura 4. Modelo QIP [24]
f. Desarrollar recomendaciones y documentar
los resultados de la fase Otro de los modelos reconocidos es el modelo QIP [5] El
propósito de este modelo es apoyar el proceso de mejora continua
2. Diagnosticar.- Evalúa mediante un método formal las y la ingeniería de los procesos de desarrollo, para ayudar en la
fortalezas y debilidades del proceso seguido por los tecnología de perfusión. Una forma de ver el modelo es también
proyectos. Las principales actividades son: verlo como un modelo para la organización de aprendizaje, donde
a. Evaluar y caracterizar el estado actual de las la organización establece una forma de desarrollar las prácticas a
practicas través de la experimentación con ellos y, a continuación, la
captura y el paquete en una forma que pueden ser reutilizados en
b. Desarrollar recomendaciones y documentar
otras partes, dentro de ciertos límites.
los resultados de la fase
QIP esta basado en las principales disciplinas del software, por
3. Establecer.- realiza la planificación especifica de los
eso es natural, revolucionario y experimental. El trabajo para
mejoramientos que desea alcanzar. Principales
desarrollo de software se basa en los humanos y su diseño de
actividades:
trabajo.
a. Establecer los equipos de acción de procesos
2.3Definición de procesos
b. Elaboración del Plan de Acción
2.3.1Modelos del ciclo de Vida del Software
4. Actuar.- Implementa el mejoramiento de procesos Existen varios modelos del ciclo de vida del software, sin
llevando a cabo el plan de acción. Sus características embargo los mas utilizados son: Cascada, Prototipado,
son: Incremental y en Espiral
a. Planificar, ejecutar y seguir la instalación
b. Planificar y ejecutar proyectos piloto
2.3.1.1Cascada
c. Refinar la solución
d. Implementar la solución
5. Difundir.- Aprende de la experiencia del ciclo recién
realizado y aumenta la habilidad de la empresa u
organización para mejorar los procesos en forma
continua. Sus características son:
a. Documentar y analizar las lecciones.
b. Revisar el enfoque seguido y proponer
acciones futuras.
2.2.1.2Modelo QIP
Figura 5. Modelo en Cascada [6]
Este modelo es conocido también como ciclo de vida lineal o
básica. Este modelo admite la posibilidad de hacer iteraciones. Se

define como una secuencia de fases como se muestra en la Figura El modelo prototipado [26], modela el producto final y permite
5, en la que al final de cada una de ellas se reúne la efectuar un test sobre determinados atributos del mismo sin
documentación para garantizar que cumple las especificaciones y necesidad de que este disponible. Se trata, simplemente, de testear
los requisitos antes de pasar a la fase siguiente. [25] haciendo uso del modelo. Esta técnica puede ser utilizada en
Sus principales características son [6]: cualquier etapa de desarrollo. A medida que el proceso progresa y
el producto se completa, el prototipo ha de abarcar, cada vez más
• Cada fase empieza cuando se ha terminado la fase
las características del producto final. En la Figura 6 se listan las
anterior
fases del modelo Prototipado.
• Para pasar de una fase a otra es necesario conseguir
todos los objetivos de la etapa previa Existen varios tipos como:
• Al final de cada fase el personal técnico y los usuarios • Prototipado – Rápido
tienen la oportunidad de revisar el progreso del • Prototipado – Evolutivo
proyecto • Prototipado – Operacional
• Prototipado – Reutilizable
Las ventajas y desventajas [21], de este modelo se describen a
continuación: Los prototipos [6], tienen una doble función:
• El cliente ve el producto y refina sus requisitos
2.3.1.1.1Ventajas • El desarrollador comprende mejor lo que necesita hacer
• Ayuda a prevenir que se sobrepasen las fechas de
Sus principales características son:
entrega y los costes esperados
• Bajo riesgo para desarrollos bien comprendidos
• Reduce el riesgo de construir productos que no
satisfagan las necesidades de los usuario
utilizando tecnología conocida.
o Reduce costos y aumenta la probabilidad de
• Este modelo es sencillo ya que sigue los pasos intuitivos éxito
necesarios a la hora de desarrollar el software. o Exige disponer de las herramientas adecuadas
o No presenta calidad ni robustez
2.3.1.1.2Desventajas • Suele utilizarse principalmente en dos áreas:
• Su inflexibilidad en la división del proyecto en distintas o Prototipado de la interfaz de usuario
etapas o Prototipado del rendimiento
• Esto hace difícil poder responder a los cambios en los Las ventajas y desventajas [27], [28], se listan a continuación:
requerimientos del cliente.
2.3.1.2.1Ventajas
• Se tarda mucho tiempo en pasar por todo el ciclo
• El mantenimiento se realiza en el código fuente
• Las revisiones de proyectos de gran complejidad son • Es mucho mejor y conveniente usar este modelo porque
muy difíciles es el único apto para desarrollos en los que se utiliza
nueva tecnología.
• Para obtener resultados se debe llegar a la etapa final
del proyecto. Un error importante no detectado hasta • El prototipado es un medio excelente para recoger la
que el programa este funcionando puede ser desastroso. realimentación del usuario final, así como también es
mucho más rápido de desarrollarse.
2.3.1.2Prototipado • El cliente se va familiarizando con el nuevo producto.
• Permite proporcionar una funcionalidad útil en manos
del cliente sin tener la aplicación finalizada.
2.3.1.2.2Desventajas
• No hay que usar en casos experimentales ya que no
puede funcionar.
• La gestión de desarrollo que es lenta porque da vueltas
hasta que el usuario este de acuerdo, o se pongan
limites.
• Imposibilidad de conocer a priori el tiempo de
desarrollo
• Es muy difícil y complejo realizarlo
2.3.1.3Iterativo e Incremental
Estos modelos disminuyen riesgos y nos ayudan a tener un mejor
desarrollo de software ya que se basan en la retroalimentación por
lo que nos ayudan a tener una mejor arquitectura del software y
Figura 6. Modelo Prototipado [6] son muy útiles cuando el usuario tiene más requerimientos.

• El modelo iterativo: Este modelo mejora cada versión • Difícil de aplicar a sistemas transaccionales que tienden
es decir mejora la función que tiene la versión. a ser integrados y a operar como un todo.
• El modelo incremental: Este modelo mantiene la • Los errores en los requisitos se detectan tarde y su
función anterior y aumenta otra, ya que puede ser que el corrección resulta costosa
primer incremento no hubiera tenido todos los • Necesitan una gran planeación.
requerimientos que necesitaba el proyecto.
• Debido a la interacción con los usuarios finales, cuando
sea necesaria la retroalimentación hacia el grupo de
desarrollo, utilizar este modelo de desarrollo puede
llevar a avances extremadamente lentos.
• No es una aplicación ideal para desarrollos en los que
de antemano se sabe que serán grandes en el consumo
de recursos y largos en el tiempo.
• Al requerir constantemente la ayuda de los usuarios
finales, se agrega un costo extra a la compañía, pues
mientras estos usuarios evalúan el software dejan de ser
directamente productivos para la compañía.
2.3.1.4En espiral
Figura 7. Modelo Iterativo e Incremental [6]
En la Figura 7, se muestra el modelo Incremental, en este modelo
se aplican secuencias lineales de forma escalonada mientras
progresa el calendario.
Sus principales características son:
• Corrige la necesidad de una secuencia no lineal de
pasos de desarrollo
• El sistema se crea añadiendo componentes funcionales
al sistema incrementos
• El sistema no se ve como una entidad monolítica con
una fecha fija de entrega, sino que es una integración de
resultados sucesivos obtenidos después de cada
iteración Figura 8. Modelo en Espiral [6]
• Se ajusta a entornos de alta incertidumbre
El modelo en Espiral que se muestra en la Figura 8, es un modelo
Las ventajas y desventajas de este modelo son [30] [32]: de proceso de software evolutivo que combina la naturaleza
iterativa de construcción de prototipos con los aspectos
2.3.1.3.1Ventajas controlados y sistemáticos del modelo lineal secuencial.
• Se evitan proyectos largos y se entrega “algo de valor”
a los usuarios con cierta frecuencia. Según Wikipedia [31], las actividades de este modelo se
• El usuario se involucra más. conforman en una espiral, en la que cada bucle o iteración
representa un conjunto de actividades. Las actividades no están
• Mayor retorno de la inversión.
fijadas a priori, sino que las siguientes se eligen en función del
• Disminuyen riesgos análisis de riesgo, comenzando por el bucle interior. El software
• Se puede cambiar los requerimientos pues como nos se desarrolla en una serie de versiones incrementales.
basamos en una versión a esta la aumentamos o la
modificamos.
• Durante las primeras iteraciones, la versión incremental
• Reduce costos, si algo sale mal solo volvemos a la
podría ser un modelo en papel o un prototipo.
antigua versión y comenzamos de nuevo.
• Durante las últimas iteraciones, se producen versiones
• Al usuario se le entrega parte del producto, es decir una
cada vez más completas del sistema diseñado.
versión con la cual el puede trabajar.
Sus principales características son:
2.3.1.3.2Desventajas
• Cada ciclo empieza identificando:
• Difícil de evaluar el coste total.
o Los objetivos de la porción correspondiente
• Requiere gestores experimentados.

o Las alternativas • Demostrar valor iterativamente.
o Restricciones • Elevar el valor de abstracción.
• Se evalúan las alternativas respecto a los objetivos y las
• Enfocarse en la calidad.
restricciones.
• Se formula una estrategia efectiva para resolver las 2.3.2.1.1Ciclo de vida de RUP
fuentes de riesgos (simulación, prototipado, etc.).
• Se plantea el próximo prototipo. El proceso del RUP está dividido en 4 fases, en estas fases se
• Una vez resueltos los riesgos se sigue el ciclo en realiza varias iteraciones de acuerdo al proyecto, en la Figura 9 se
cascada muestra gráficamente las 4 fases del RUP, cuyas iteraciones están
• Cada ciclo se completa con una revisión que incluye representadas con líneas verticales y marcadas con la letra
todo el ciclo anterior y el plan para el siguiente. correspondiente a la inicial de la fase, la fase Inicial tiene una sola
iteración.
Las ventajas y desventajas de este modelo son [31]:
2.3.1.4.1Ventajas
• No necesita una definición completa de los requisitos
para empezar a funcionar.
• Al entregar productos desde el final de la primera
iteración es mas fácil validar los requisitos
• El riesgo en general es menor, porque si todo se hace
mal , solo se ha perdido el tiempo y recursos invertidos
en una iteración
• El riesgo de sufrir retrasos es menor ya que al
identificar los problemas en etapas tempranas hay
tiempo de subsanarlos,
• El análisis del riesgo se hace de forma explícita y clara.
Une los mejores elementos de los restantes modelos.
• Reduce riesgos del proyecto
• Incorpora objetivos de calidad Figura 9. Fases del RUP [35]
• Integra el desarrollo con el mantenimiento, etc.
2.3.2.1.2Fase de Inicio
2.3.1.4.2Desventajas
• Es difícil evaluar los riesgos En esta fase se define el modelo del negocio y el alcance del
• Necesita de la participación continua por parte del proyecto, se identifican los autores y casos de usos y se diseñan
cliente los casos de uso esenciales.
• Cuando se subcontrata hay que producir previamente Los objetivos son:
una especificación completa de lo que se necesita y esto
lleva tiempo. • Establecer el ámbito del proyecto y sus limites
• Genera mucho tiempo en el desarrollo del sistema • Encontrar los casos de uso críticos del sistema, los
• Modelo costoso requiere experiencia en la escenarios básicos.
identificación de riesgos • Mostrar una arquitectura para los escenarios principales.
• Estimar el coste en recursos y tiempo en todo el
2.3.2Metodologías de desarrollo de software proyecto.
• Estimar los riesgos, las fuentes de incertidumbre.
2.3.2.1RUP Los resultados de la fase son:
• Documento de visión
RUP [35] es un proceso para el desarrollo de un proyecto de • Modelo inicial de casos de uso
software que define quien, como, cuando y que debe hacerse en el
• Glosario inicial
proyecto, con 3 características esenciales como: Casos de uso,
centrado n la arquitectura y es iterativo e incremental. • Caso de negocio
• Lista de riesgos y plan de contingencia
El RUP maneja 6 principios clave:
• Plan del proyecto
• Adaptación del proceso. • Modelo de negocio
• Balancear prioridades.
• Colaboración entre equipos.

2.3.2.1.3Fase de Elaboración configuración, instalación y facilidad de uso del producto. En esta
fase también se realiza:
En esta fase se analiza el dominio del problema, establece los
cimientos de la arquitectura, desarrolla el plan del proyecto y • La prueba de la versión beta para validar al nuevo
elimina los riesgos mayores. Se construye un prototipo de la sistema frente a las expectativas del usuario.
arquitectura que evoluciona en iteraciones sucesivas hasta
• Funcionamiento paralelo con los sistemas legados que
convertirse en el sistema final.
están siendo sustituidos por el nuevo proyecto.
Los objetivos de esta fase son: • Conversión de las bases de datos operacionales.
• Definir, validar y cimentar la arquitectura. • Entrenamiento de los usuarios y técnicos de
• Completar la visión mantenimiento.
• Crear un plan para la fase de construcción • Traspaso del producto a los equipos de marketing,
• Demostrar que la arquitectura propuesta soportara la distribución y venta.
visión
Los objetivos de esta fase son:
•
Los resultados son los siguientes:
• Un modelo de casos de uso al menos el 80% • Conseguir que el usuario se valga por si mismo.
• Requisitos adicionales que capturan los requisitos no • Un producto final que cumpla los requisitos esperados,
funcionales. que funcione y satisfaga suficientemente al usuario.
• Descripción de la arquitectura software Los resultados son:
• Prototipo ejecutable de la arquitectura.
• Lista de riesgos y caso de negocio revisados
• Plan de desarrollo para el proyecto • Prototipo operacional
• Manual de usuario preliminar. • Documentos legales
• Caso del negocio completo
• Línea base del producto completa y corregida que
2.3.2.1.4Fase de Construcción incluye todos los modelos del sistema
• Descripción de la Arquitectura completa y corregida.
En esta fase la finalidad es alcanzar la capacidad operacional del • Las iteraciones de esta fase irán dirigidas normalmente
producto de forma incremental a través de las sucesivas a conseguir una nueva versión.
iteraciones, en esta fase todas las componentes, características y
requisitos deben ser implementados, integrados y cambiados en su Los criterios de evaluación de esta fase son:
totalidad.
Los objetivos son: • El usuario se encuentra satisfecho.
• Minimizar los costes de desarrollo mediante la
• Son aceptables los gastos actuales versus los gastos
planificados.
optimización de recursos.
• Conseguir calidad adecuada.
• Conseguir versiones funcionales tan rápido como sea
práctico. 2.3.2.2MSF
Los resultados de la fase de construcción deben ser: La metodología MSF (Microsoft Solucion Framework) [40], es
flexible e interrelacionada con una serie de conceptos, modelos y
• Modelos completos(casos de uso, análisis, diseño,
prácticas de uso, y guías para diseñar y desarrollar soluciones
despliegue e implementación)
empresariales de una manera que asegura que todos los elementos
• Arquitectura integra. del proyecto tal como gente, procesos y herramientas, puedan ser
• Riesgos presentados mitigados exitosamente conducidos.
• Plan del proyecto para la fase de transición.
• Manual inicial de usuario.
MSF no sólo es aplicable al desarrollo de proyectos de desarrollo,
• Prototipo operacional. también es aplicable a otros proyectos de TI, como el despliegue
• Caso del negocio actualizado. o proyectos de infraestructura o redes. MSF no fuerza al
desarrollador a utilizar una metodología específica (Cascada,
2.3.2.1.5Fase de Transición ágil), pero les permite decidir qué método utilizar.
En esta fase se pone el producto en manos de los usuarios finales,
para lo que se requiere desarrollar nuevas versiones actualizadas
del producto, completar la documentación, entrenar al usuario en
el manejo del producto y tareas relacionadas con el ajuste,

• Escalable: Puede organizar equipos tan pequeños entre
3 o 4 personas, así como también, proyectos que
requieren 50 personas a más.
• Flexible: Es utilizada en el ambiente de desarrollo de
cualquier cliente.
• Tecnología Agnóstica: Porque puede ser usada para
desarrollar soluciones basadas sobre cualquier
tecnología.
Principios fundamentales en los que se basa MSF
MSF propone una secuencia generalizada de actividades para la
construcción de soluciones empresariales, este proceso es flexible
y se puede adaptar al diseño y desarrollo de una amplia gama de
proyectos de una empresa, además está basado en fases, puntos de
transición y de carga de forma iterativa que se puede aplicar en el
desarrollo de aplicaciones tradicionales, soluciones empresariales
para comercio electrónico así como aplicaciones Web
distribuidas.
Los principios en los que se fundamenta MSF son:
Figura 10. Fases del modelo MSF [41]
• Fomentar la comunicación abierta.
El MSF está compuesto 6 por fases, como se muestra en la Figura • Trabajar en pro de una visión compartida.
10, las fases se listan a continuación:
• La autonomía de los miembros del equipo.
1. Visión: donde se reúne un equipo del proyecto, define • Establecer una clara rendición de cuentas y la
la visión y el ámbito de una solución que cumplirá los responsabilidad compartida.
objetivos del cliente. El equipo organiza entonces el • Centrarse en entregar valor de negocio.
proyecto y proporciona un documento de visión/ámbito • Mantenerse ágil a espera del cambio.
aprobado. Las personas encargadas de funciones de • Invertir en calidad.
administración de productos y administración de
• Aprender de todas las experiencias.
programas toman el mando en esta fase.
2. Planeación: donde se desarrollan los procesos de MSF para Metodologías de Desarrollo Ágil (MSF4ASD)
diseño conceptual, lógico y físico, así como la MSF para Metodologías de Desarrollo Ágil es un proceso de
especificación funcional. La persona encargada de desarrollo manejado por escenarios, basado en contexto, que
funciones de administración de programas toma el utiliza muchas de las ideas incorporadas en Team System
mando durante esta fase y crea planes de proyecto que (herramientas de Microsoft). Este proceso incorpora las prácticas
tratan el desarrollo, la comunicación y otras tareas; y probadas desarrolladas en Microsoft con respecto a los
cada función proporciona los datos para crear la requerimientos, diseño, seguridades, rendimiento y pruebas
programación del proyecto. (testing) [42].
MSF para metodologías de desarrollo ágil presenta una guía
3. Desarrollo: El equipo crea y prueba la solución. La
persona encargada de funciones de desarrollo toma el muy recomendable a los Desarrolladores y Gestores de proyectos
mando durante esta fase. de software que pueden adaptarla a la metodología de su empresa,
en la que incluye documentos de ejemplo, plantillas, archivos en
4. Estabilización: El equipo crea la solución piloto en blanco de Project, Excel y Word para la administración de
preparación para el lanzamiento de producción. La proyectos, requerimientos, seguridad y pruebas.
persona encargada de las funciones de prueba toma el
mando durante esta fase. MSF para CMMI (MSF4CMMI)
EL MSF4CMMI para CMMI es una metodología formal para la
5. Instalación.
ingeniería de software es un proceso de mejora que proporciona a
las organizaciones los elementos esenciales del proceso continuo
6. Soporte
de mejora que den lugar a una reducción de Ciclo de vida del
Las características más relevantes del MSF son: Desarrollo de Software, la mejora de la capacidad para satisfacer
• Adaptable: Es parecido a un compás, usado en las metas de costos y el calendario, la construcción de productos
cualquier parte como un mapa, del cual su uso es de alta calidad.
limitado a un específico lugar. El MSF4CMMI se ha ampliado una orientación MSF4ASD con
una formalidad adicional, evaluación, verificación y auditoría
[43].

Una de las ventajas de utilizar el proceso CMMI es el estándar de Essential Unified EssUP
evaluación por la que uno puede comparar la capacidad de Process
desarrollar software en otras organizaciones.
Feature Driven FDD De Luca & Coad
Development 1998 Palmer &
2.3.2.3Modelo Ágil Felsing 2002,
Lean LD Charette 2001,
Development
El Modelo de Desarrollo Ágil se originó a mediados de los años Mary y Tom
1990 y se podría decir que fue extraído del modelo de desarrollo Poppendieck
en cascada, pues éste último era visto como burocrático, lento, Programación XP Beck 1999
degradante e inconsistente por lo exigente y muy estructurado en Extrema
sus formas de desarrollo de software que sin embargo realizaban
un trabajo eficiente. Scrum Scrum Sutherland 1994
En el año 2001, miembros prominentes de la comunidad de la Schwaber 1995
industria del software se reunieron en Sonwbird, Utah, y Microsoft MSF Microsoft 1994
adoptaron el nombre de "Metodologías ágiles"[36]. Solutions
El modelo de desarrollo ágil es un paradigma de Desarrollo de Framework
Software que utiliza procesos ágiles (pequeñas y frecuentes
Rapid RAD McConnell 1996
entregas con ciclos rápidos) enfocados en la gente y resultados, se
Development
podría decir que es:
Open Unified OpenUP
• Cooperativo, clientes y desarrolladores trabajan
constantemente con una comunicación muy fina y Process
constante, Rational Unified RUP Krutchen 1996
• Sencillo, método fácil de aprender y modificar para el Process
equipo pues la reducción de documentación se
reemplaza por la constante comunicación, y
Algunas empresas que usan metodologías de desarrollo ágil en
• Adaptativo, capaz de permitir cambios de último algunos de sus proyectos, son:
momento.
• Google,
El objetivo de este modelo es desarrollar software rápidamente,
respondiendo a los cambios que puedan surgir a lo largo del
• Oracle,
proyecto. • Yahoo,
• Canon,
Esta metodología propone que un pequeño grupo de personas (10
como máximo) conformado de los más experimentados y capaces • Xerox,
ingenieros de software, trabajen en el desarrollo de iteraciones • Sun,
(software desarrollado en una unidad de tiempo) con una duración • HP,
máxima de hasta 4 semanas y desarrollando una serie de “user • Nokia,
stories” (Casos de Uso) que al final cumplan con los • Honda,
requerimientos establecidos en línea directa por los usuarios • Toyota, etc.
finales del sistema [37].
2.3.2.3.2Ventajas:
2.3.2.3.1Metodologías Agiles
• Métodos de comunicación más eficaces en este tipo de
Hacemos mención de algunas metodologías ágiles de desarrollo metodologías.
de software en la Tabla 1, estas metodologías son: • Es posible identificar y atacar los problemas más
críticos y controversiales del proyecto en las primeras
Tabla 1. Lista de Metodologías Ágiles etapas.
• El cliente comenzará a ver su sistema lo más pronto
Metodología Acrónimo Creación posible y verificar que se están cubriendo sus
Adaptive ASD Highsmith 2000 requerimientos de forma adecuada.
Software • Entrega de resultados tangibles en etapas tempranas del
Development proyecto.
Agile Modeling AM Ambler 2002
2.3.2.3.3Desventajas:
Agile RUP dx Booch, Martin, • Proceso menos controlado y con pocos principios.
Newkirk 1998 • No existe contrato tradicional o al menos es bastante
Crystal Methods CM Cockbum 1998 flexible.

• Grupos pequeños, trabajando en el mismo sitio y no documentación de actividades de mantenimiento de
distribuidos adecuadamente. software.
• Menos énfasis en la arquitectura del software, siendo
ésta primordial para el éxito del proyecto de software. 2.3.3.2.2 ISO 14764:1998
2.3.2.3.4Uso de Metodologías Éste estándar internacional como es ISO 14764 [34] aclara los
requerimientos para el Proceso de Mantenimiento del Software.
El Mantenimiento del Software es un proceso primario en el ciclo
El surgimiento de estas revolucionarias metodologías que no solo
de vida de un producto software. En muchos proyectos,
nacen para el desarrollo de sistemas software sino para el manejo
especialmente aquellos que tienen una vida larga, el
o desarrollo de productos los incrementos en adeptos se presentan
mantenimiento del software es con seguridad una de las
gradualmente con el tiempo y las tecnologías. En la Figura 11, se
consideraciones más importantes del proyecto. Por esta razón es
muestra [38]
necesario ser capaces de corregir los fallos que se encuentran
durante su manejo.
Mantenimiento de Software se puede hacer combinando
herramientas software, métodos y técnicas, se aplica a programas
de ordenador, código, datos, y documentación. Se intenta que se
aplique a productos software creados durante el desarrollo del
producto software. Éste estándar internacional está pensado para
su uso en todos los esfuerzos de mantenimiento,
independientemente del ciclo de vida o del enfoque usado en el
desarrollo.
2.3.3.3ISO 9001-2000
Figura 11. Uso de Métodos Ágiles [38] El estándar o norma ISO 9001:2000 (Quality management
systems –Requirements) que significa Calidad del manejo de
requerimientos del sistema, especifica los requerimientos para el
2.3.3Procesos del ciclo de vida del Software manejo de la calidad de un sistema organizacional proveyendo
requerimientos de los productos y satisfacción del cliente.
Primario se basa en la calidad del software, y segundo en los
2.3.3.1Estándar IEEE 1074 procesos de ingeniería del software.
El estándar IEEE 1074 [7] y [8], es un estándar para la
generación de los que rigen el proceso de desarrollo de software y
mantenimiento de un proyecto. Este estándar requiere la selección 2.4Evaluación de Procesos
de proyectos de software y modelos de ciclo de vida, basado en la
misión, visión, metas y recursos de las organizaciones. También
2.4.1Modelos de Evaluación del proceso
describe las diferentes actividades que van a ser asignada en el
modelo seleccionado. Sin embargo, este estándar no es una guía 2.4.1.1CMMI
de instrucción. También puede ser utilizado para desarrollar los
procesos de organización para apoyar el desarrollo de software y CMMi intenta proveer una guía para los procesos. Las áreas
procesos que tiene una única función dentro de un proyecto. específicas relacionadas son:
2.3.3.2Procesos de Mantenimiento:
• Calidad de proceso y producto
2.3.3.2.1 IEEE 1219-1998 • Verificación del proceso
• Validación del proceso
El estándar IEEE 1219-1998 [9], se basa en procesos iterativos
para ejecutar y manejar el mantenimiento de software. Hubo inicialmente algún debate sobre si la ISO 9001 o CMMi
Los procesos están aplicados a: podrían ser usadas por los ingenieros del software para asegurar la
calidad. Este debate fue publicado y como resultado la decisión
• Planeación de mantenimiento mientras el producto está ha sido tomada que los dos son complementarios y que
desarrollándose. teniendo certificación ISO 9001 puede ayudar grandiosamente en
• Planeación y ejecución de mantenimiento para altos niveles de madurez del CMMi. [6]
productos de software existente. El modelo CMMI es un modelo de calidad del software que
• Aplica cualquiera de los modelos del ciclo de vida clasifica las empresas en niveles de madurez. Estos niveles sirven
disponibles. para conocer la madurez de los procesos que se realizan para
• Estándares prescriben los requerimientos para procesos, producir software.
control y manejo de la planeación, ejecución y

2.4.2Métodos de evaluación del proceso
Estos medos fueron desarrollados por el SW-CMM • Planificar el Proceso de Medición que implica tareas
como:
2.4.2.1CBA-IPI o Obtener características de la Organización.
o Identificar las necesidades de la Información.
El CBA-IPI [39], es un método de evaluación basado en CMM o Seleccionar las medidas.
sirve para mejorar internamente los procesos, fue desarrollado por o Definir los procedimientos de recolección de
el Softare Engneer Institute de la Universidad Carnegie Mellon. datos, análisis e informes.
Es una herramienta de diagnostico que permite a las o Definir los criterios de evaluación de los
organizaciones y proyectos el poder determinar las fortalezas y de productos de información y el proceso de
sus procesos de desarrollo de software, utiliza el método de medición.
madurez de capacidades para software desarrollado por el SEI o Revisar, aprobar y proporcionar recursos para
las tareas de medición.
2.4.2.2SCAMPI o Adquirir y utilizar tecnologías de apoyo.
Los métodos SCAMPI son grandes torres de evaluación CMMi. • Realizar el Proceso de Medición que implica tareas
Las actividades ejecutadas durante una evaluación, la distribución como:
de esfuerzo en estas actividades como la atmosfera durante una o Integrar los procedimientos,
evaluación son diferentes cuando son de mejora para la o Recoger los datos,
adjudicación de un contrato. o Analizar los datos y desarrollar productos de
información.
o Comunicar los resultados.
2.5Medidas de Productos y Procesos
• Evaluar la Medición que implica tareas como:
o Evaluar productos de información y el
La medición de software es una disciplina relativamente joven, proceso de medición,
consenso general sobre la definición exacta de los conceptos y o Identificar las mejoras potenciales.
terminología que maneja, aunque términos clave de medición del
software y métodos de medición han sido definidos en la ISO/IEC
15939 basados en el vocabulario ISO internacional de metrología. 2.5.1Medición del Proceso: ISO 15539-02
A pesar de todo, los lectores encontrarán diferencias
terminológicas en la literatura; por ejemplo, el término “métrica” La medición del Proceso significa recoger, analizar e interpretar
se utiliza a veces en vez de “medida”. En la Figura1 se muestra el información cuantitativa sobre nuestros procesos, para identificar
ámbito de ISO/IEC 15939: [10] las fuerzas y las debilidades de los mismos y para evaluarlos
después de que hayan sido implementados y/o cambiados.
Muchos son los propósitos que abarca la medición del Proceso en
el presente caso de estudio nos centraremos en la medición del
proceso para gestionar un proyecto de software enfocado en la
implementación y cambio del proceso.
El medir un proceso de software implica medir las actividades
relacionadas con el software como por ejemplo el esfuerzo, el
coste y los defectos encontrados, mientras que se pueden hacer
algunos esfuerzos para valorar la utilización de herramientas y de
hardware, un recurso principal que necesita ser gestionado en la
ingeniería del software es el personal.
Existen tres tipos de métricas de proceso:
• Tiempo requerido para completar un proceso en
particular: total del proyecto, por ingeniero, por
actividad, etc.
• Recursos requeridos para un proceso en particular:
esfuerzo en personas/día, costes de viajes, recursos de
hardware, etc.
Figura 12. Ámbito de la ISO/IEC 15939 [10]
• Número de Ocurrencias de un Evento número de
defectos descubiertos durante la revisión del código,
Las actividades de la ISO/IEC 15939 son: número de peticiones de cambio en requerimientos,
número promedio de líneas de código (LDC)
• Establecer y Mantener el Compromiso de Medición que modificadas en respuesta a un cambio de
implica tareas como: requerimientos, errores detectados por el usuario, etc.
o Aceptar los requisitos de medición.
o Asignar recursos.

Justificación que el software satisfaga las necesidades del usuario), que son
manifestadas externamente cuando el software es utilizado, y son
La recolección de métricas del proceso es esencial para la mejora un resultado de atributos internos del software. El modelo de
del mismo y se utilizan para evaluar la eficiencia de un proceso y calidad de ISO 9126-1 establece 3 niveles: (1) Característica, (2)
si éste ha mejorado con los cambios realizados. Subcaracterística y (3) Métricas. [12]
• Las dos primeras métricas ayudan a descubrir si los Características de calidad del ISO 9126-1:2001:
cambios en el proceso mejoran la eficiencia de un
• Funcionalidad: conjunto de atributos que se relacionan
proceso. Por ejemplo, se puede medir el tiempo y
con la existencia de un conjunto de funciones y sus
esfuerzo necesarios para moverse de un hitos fijo a otro,
propiedades específicas. Las funciones son aquellas que
como la aceptación de requerimientos, terminación de
satisfacen lo indicado o implica necesidades. Las
un diseño arquitectónico, etc. Esos valores ayudan a
subcaracterísticas son: Idoneidad, Exactitud
identificar áreas de mejora en el proceso. Una vez
Interoperabilidad, Seguridad, Cumplimiento de normas.
introducidos los cambios, las mediciones posteriores
indican si los cambios han sido positivos. • Fiabilidad: conjunto de atributos relacionados con la
capacidad del software de mantener su nivel de
• El número de ocurrencias de un Evento Tienen
prestación bajo condiciones establecidas durante un
influencia directa en la calidad del software. Por
período de tiempo establecido. Las subcaracterísticas
ejemplo, incrementar el número de defectos
son: Madurez, Tolerancia a fallas, Facilidad de
descubiertos al cambiar el proceso de revisión del
Recuperación, Conformidad de Fiabilidad.
código probablemente se reflejará en una mejora de la
calidad del producto, aunque tiene que confirmarse por • Usabilidad: conjunto de atributos relacionados con el
mediciones posteriores del producto. esfuerzo necesitado para el uso, y en la valoración
individual de tal uso, por un establecido o implicado
Se describiría a las salidas de los procesos como: calidad del
conjunto de usuarios. Las subcaracterísticas son:
producto (errores por KLOC (Kilo Líneas de Código) o por Punto
Aprendizaje, Comprensión, Operatividad, Atractividad,
Función (FP)), mantenibilidad (el esfuerzo para hacer un cierto
Conformidad de Usabilidad
tipo de cambio), productividad (LDC (Líneas de Código)) o
Puntos Función por persona-mes), tiempo-de-mercado, o • Eficiencia: conjunto de atributos que se refieren a las
satisfacción del cliente (como medidos por medio de una encuesta relaciones entre el nivel de rendimiento del software y
a clientes). Esta relación depende del contexto particular (por la cantidad de recursos utilizados bajo unas condiciones
ejemplo, el tamaño de la organización o el tamaño del proyecto). predefinidas. Las subcaracterísticas son:
Compartimiento en el tiempo, Compartimiento de
De allí que el obtener las salidas del proceso que deseamos recursos, Conformidad de eficiencia.
significa que se debió haber implementado los procesos • Mantenibilidad: conjunto de atributos relacionados con
adecuados. la facilidad de extender, modificar o corregir errores en
un sistema software. Las subcaracterísticas de la
2.5.2Medición del Producto: ISO 9126-01 Facilidad de Mantenimiento son: Facilidad de análisis,
Facilidad de cambio, Estabilidad y Facilidad de prueba.
¿Qué es un producto de software? • Portabilidad: conjunto de atributos relacionados con la
Un producto de software se lo puede describir en un sentido capacidad de un sistema software para ser transferido
extenso como: los ejecutables, código fuente, descripciones de desde una plataforma a otra. Las subcaracterísticas de la
arquitectura, y así. Portabilidad son: Capacidad de instalación, capacidad
de reemplazamiento, Adaptabilidad y Co-Existencia.
De allí que las métricas del producto se refieren a las
características del propio software que incluye: la medición del
tamaño del producto, la estructura del producto y la calidad del 2.5.2.2Métricas Externas– ISO 9126-2:2003
producto.
Las cuales miden el software en sí mismo o software en ejecución
Un estándar internacional para la evaluación del Software es el (Calidad Externa – Ambiente de Prueba).
ISO 9126 supervisado por el proyecto SQuaRE, ISO 25000:2005.
[11] Permite evaluar la calidad del software desde distintas 2.5.2.3Métricas Internas – ISO 9126-3: 2003
perspectivas relacionadas con el desarrollo, adquisición,
Las cuales miden el comportamiento del sistema, dichas métricas
requerimientos, uso, evaluación, mantenimiento, aseguramiento
se aplican cuando el software no está en ejecución por ejemplo
de la calidad.
durante el diseño y codificación. (Calidad Interna – Ambiente de
El estándar está dividido en cuatro partes las cuales dirigen, Desarrollo)
respectivamente, lo siguiente:
2.5.2.4Calidad en Uso–ISO 9126-4: 2004
El cual mide el efecto de usar el software en un contexto
2.5.2.1Modelo de la Calidad
específico (Ambiente de Producción).
Describe el modelo de calidad del producto de software ISO 9126-2, ISO 9126-3 e ISO 9126-4 están encaminados en
especificando 6 características de calidad interna (evalúa el total ambientes de Prueba, Desarrollo y Producción respectivamente.
de atributos que un software debe satisfacer) y externa (evalúa

¿Quién puede utilizar esta norma? • Desarrollo y mejora de los procesos de la
Esta Norma puede ser usada por desarrolladores, evaluadores organización
independientes y grupos de aseguramiento de la calidad • Definición de los procesos de la organización
responsable de especificar y evaluar la calidad del software. • Planificación de la formación
• Gestión de riesgos
• Análisis y resolución de toma de decisiones
3.MODELOS ESTANDARIZADOS
DISPONIBLES • Cuantitativamente Gestionado o Nivel 4 CMM – CMMI:
Nivel 4 a más de contar con procesos definidos para el
desarrollo de los proyectos se utilizan técnicas cuantitativas
3.1CMMI para el control de los procesos, como pueden por ejemplo se
CMMI es un modelo de calidad del software que clasifica las usan las métricas para gestionar la organización.
empresas en niveles de madurez. Estos niveles sirven para Los procesos que hay que implantar para alcanzar este nivel
conocer la madurez de los procesos que se realizan para producir son:
software.
• Gestión cuantitativa de proyectos
3.1.1Niveles CMM – CMMI • Mejora de los procesos de la organización
• Optimizado o Nivel 5 CMM – CMMI
Los niveles CMM - CMMI son 5: Los procesos de los proyectos y de la organización en este
nivel a más de ser cuantitativamente gestionados están
• Inicial o Nivel 1 CMM – CMMI: En este nivel pertenecen orientados a la mejora de las actividades mediante el uso de
aquellas empresas que no tienen sus procesos bien definidos. métricas.
Características comunes de este tipo de empresas son: los Los procesos que hay que implantar para alcanzar este nivel
presupuestos se disparan, no se entrega el proyecto en fechas son:
establecidas, no hay control sobre el estado y desarrollo del
• Innovación organizacional.
proyecto. El simple hecho de existir como empresa de
• Análisis y resolución de las causas.
software se está en el nivel1.
3.2ISO 9000
• Repetible o Nivel 2 CMM – CMMI: El objetivo que
pretende alcanzar el nivel 2 es que los proyectos que lleve a “ISO 9000” se refiere a una serie de normas internacionales que
cabo las empresas se los ejecute con una adecuada gestión de define un sistema de “Garantía de Calidad” en las organizaciones:
los procesos lo que implica planeación, ejecución, control, ISO 9001, ISO 9002, ISO 9003 e ISO 9004 (y sus subnormas)
medición de los mismos. Es un nivel difícil de alcanzar pues desarrollado por la Organización Internacional de Normalización
al establecer procesos se está pretendiendo cambiar la forma (ISO). Esta norma ha sido adoptada por 90 países en todo el
de trabajar de la empresa que muchas de las veces implica un mundo y está compuesta por representantes de normas nacionales
cambio cultural de la misma y por ende lo más importante de más de 100 países.
aquí es saber si se cuenta con el apoyo de la dirección para
afrontar este cambio. Sin este apoyo no se podría alcanzar el La familia de normas apareció por primera vez en 1987 teniendo
CMM-CMMI nivel 2. como base una norma estándar británica (BS), y se extendió
principalmente a partir de su versión de 1994, estando
Los procesos que hay que implantar para alcanzar este nivel
actualmente en su versión 2008, publicada el 13 de noviembre de
son:
2008. La principal norma de la familia es actualmente la: ISO
• Gestión de requisitos 9001:2008 - Sistemas de Gestión de la Calidad - Requisitos. [15]
• Planificación de proyectos
• Seguimiento y control de proyectos 3.2.1Proceso de Certificación
• Gestión de proveedores • Para brindar una certificación bajo la norma ISO
• Aseguramiento de la calidad 9000 a determinada empresa u organización,
• Gestión de la configuración existen las entidades certificadoras vigiladas por
organismos nacionales que les dan su acreditación
• Definido o Nivel 3 CMM – CMMI: Pertenecer a este nivel y son las encargadas de verificar que dichas
significa que los proyectos que se llevan a cabo a más de organizaciones o empresas cumplen con los
contar con procesos gestionados, la organización o empresa requisitos de la norma, una vez que éstas hayan
debe contar con una forma definida para desarrollar dichos elegido el alcance de la actividad profesional que
proyectos es decir sus procesos deben estar establecidos, se va a registrar, seleccionado un registro,
documentados y contar con métricas para la consecución de someterse a la auditoría y haber concretado con
objetivos concretos. éxito dicho proceso; se les otorga un certificado y
sello.
Los procesos que hay que implantar para alcanzar este nivel
¿Qué hacer ante el incumplimiento?
son:
• Desarrollo de requisitos Si un auditor/registrador encuentra áreas de incumplimiento la
• Solución Técnica organización o empresa tiene un plazo para adoptar medidas
• Integración del producto correctivas, sin perder la vigencia de la certificación o la
• Verificación continuidad en el proceso de certificación.
• Validación

3.2.2 Marco Conceptual La Computer Society declara "dedicada al avance de la teoría, la
práctica y la aplicación de la informática y la tecnología de
La ISO 9001 y la ISO 9002 son normas de sistema. ISO 9001 se procesamiento de la información." Procura "ser el proveedor líder
aplica a las empresas que se dedican al diseño de productos o de información técnica y servicios a los profesionales del mundo
servicios y también a su producción o implementación. ISO 9002 de la informática". [19]
simplemente excluye el elemento de diseño de un modelo similar
para garantía de calidad.
Los certificados que pueden concederse mediante ellas señalan 4.4 RUSSOFT Association
que una organización es perfectamente capaz de cumplir las Con sede en San Petersburgo, es un multi-nacional de la
necesidades y requisitos de sus clientes de manera planificada y asociación de software de empresas de Rusia, Ucrania y
controlada [16]. Si quiere ir más allá y lograr la excelencia, Bielorrusia. Fue fundada el 9 de septiembre de 1999 y se ha
debería cumplir requisitos adicionales. La ISO 9004:2000 fusionado con la de Fort-Ross Consorcio en mayo de 2004.
establece estos requisitos adicionales.
Al igual que en la India NASSCOM, RUSSOFT fue creado para
4.ORGANIZACIONES representar a empresas rusas de desarrollo de software en el
mercado mundial, a fin de mejorar la comercialización y
actividades de relaciones públicas de sus miembros, y para
4.1Software Engineering Institute (SEI) presionar a sus intereses en sus países los gobiernos. [20]
Es un instituto federal estadounidense de investigación y
desarrollo, fundado por el Congreso de los Estados Unidos en 5.MEJORA DE LOS PROCESOS DE
1984 para desarrollar modelos de evaluación y mejora en el
desarrollo de software, que dieran respuesta a los problemas que
SOFTWARE
generaba al ejército estadounidense la programación e integración
de los sub-sistemas de software en la construcción de complejos La mejora de procesos de Software (MPS) es un término que se
sistemas militares. Financiado por el Departamento de Defensa de usa cuando se referencian mejoras al proceso de software.
los Estados Unidos y administrado por la Universidad Carnegie Históricamente CMMI (y otros estándares y métodos envueltos) y
Mellon. otras organizaciones añadieron un “S” para ampliar el alcance a
Es un referente en Ingeniería de Software por realizar el sistemas y procesos de software (MPSS), mientras que otras
desarrollo del modelo SW-CMM (1991) que ha sido el punto de organizaciones reemplazaron “Software” por “Sistemas” para
arranque de todos los que han ido formando parte del modelo que guardar el mismo acrónimo: Mejora de Procesos de Sistemas
ha desarrollado sobre el concepto de capacidad y madurez, hasta (MPS) e incluir HW, SW, FW y WW. [21]
el actual CMMI. [17]
5.1Enfoque para MPS
4.2 British Computer Society (BCS):
En la mejora de procesos de software podemos encontrar tres
enfoques principales (o paradigmas) para la mejora de procesos
Es una organización profesional y una sociedad científica que de sistemas/software que se usan independientes o combinadas:
representa a las personas que trabajan en la tecnología de la
información. Establecida en 1957, es el más grande de Reino • Mejora apoyada en Modelos: este enfoque se basa en
Unido basados en un organismo profesional de la informática. el uso de prácticas aceptadas por la industria como un
modelo para mejorar una organización, que no está
Cubre los más de 68.000 miembros en más de 100 países, BCS es consolidada a estas prácticas. Frecuentemente se usan
una sin fines de lucro y se incorporó por Carta Real en 1984. Sus dos modelos:
objetivos son promover el estudio y la aplicación de la tecnología
de las comunicaciones y la informática y la tecnología para o Modelo de Madurez de capacidad integrada
avanzar en el conocimiento de la educación en las TIC en (CMMI) del Instituto de Ingeniería de Software
beneficio de los profesionales y el público en general. [18] (SEI).
o Conjunto de estándares de la ISO-9000 de la
4.3 IEEE Computer Society Organización Internacional para la estandarización.
• Mejora de Procesos “Bottom-Up”: este enfoque se
En una unidad de organización del Instituto de Ingenieros
centra en hacer mediciones como tamaño, esfuerzo,
Eléctricos y Electrónicos (IEEE). Se estableció en 1963 cuando el
productividad, defectos, reuso y otros indicadores de
Instituto Americano de Ingenieros Eléctricos (AIEE) y el Instituto
procesos consiguiendo así datos de líneas-base y cuando
de Ingenieros de Radio (IRE) se fusionaron para crear el IEEE.
se determina que habido mejoras potenciales el cambio
En el momento de la fusión, la AIEE del Subcomité de gran
se implementa. El efecto del cambio determina la
escala de Computación (creado en 1946) se fusionó con el IRE
ocurrencia de una mejora significativa y el resultado es
del Comité Técnico de Electrónica Informática (establecida 1948)
usado para manejar el cambio organizacional.
para crear el Grupo de IEEE Computer. El grupo se convirtió en
el IEEE Computer Society en 1971.

• Reingeniería de Negocios: establece mejor un cambio 7.REFERENCIAS
radical que un cambio incremental, un poco similar al
enfoque “Mejora de Procesos Bottom-Up”.
[1] Mario Piattini, Francisco J. Pino y Félix García,
5.2 Grupos de Procesos de Ingeniería de “Contribución de los estándares internacionales a la gestión
Sistemas e Ingeniería de Software (SEPG) de procesos software”, Facultad de Ingeniería Electrónica y
Telecomunicaciones, Universidad del Cauca, Colombia
http://www.aemes.org/rpm/descargar.php?volumen=4&nume
Software Engineering Process Group, nombre original dado al ro=2&articulo=1
servicio registrado del Instituto de Igeniería del Software (SEI) a
los “grupos responsables por las actividades de proceso de las [2] Wikipedia, “Ingeniería de software”,
organizaciones del software”. Algunos de estos grupos son: http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwar
e
• SEPG: Grupo de Procesos de Ingeniería de Sistemas.
[3] Zavala R. 2000. Diseño de un Sistema de Información
• SSEPG: Grupo de Procesos de Ingeniería de Software y Geográfica sobre internet. Tesis de Maestría en Ciencias de
Sistemas. la Computación. Universidad Autónoma Metropolitana-
• SSPG: Grupo de Procesos de Software y Sistemas. Azcapotzalco. México, D.F. En prensa,
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.
• PEG: Grupo de Ingeniería de Procesos.
html#IngSoft
• PIG: Grupo de Mejora de Procesos.
[4] Luciano Guerrero, Monerreal: Canadá, 1999, “Ciclo de
• QIG: Grupo de Mejora de Calidad. Mejoramiento de Procesos, El modelo
• PTIG: Grupo de Mejora de Procesos y Tecnología. IDEAL,”www.geocities.com/SiliconValley/Lab/3629/IDEA
L_ciclo.pdf
6.CONCLUSIONES [5] “Software process engineering systems: models and industry
cases”,
http://herkules.oulu.fi/isbn9514265084/html/x287.html
Finalmente se puede concluir acerca del tema:
[6] Francisco Ruiz, Procesos de Ingeniería del Software,
• Dentro del proceso de Ingeniería del Software los tres
http://personales.unican.es/ruizfr/is1/doc/teo/02/is1-t02-
factores más importantes son: Personal, Métodos y
trans.pdf
Procedimientos y Herramientas y Técnicas.
• El proceso de ingeniería del software está basado en [7] IEEE, “IEEE 1074-2006”, http://www.techstreet.com/cgi-
procesos y modelos a la definición, evaluación y medición bin/detail?product_id=1277365
del software. [8] IEEE Standard Association, “IEEE Std 1074-1997 IEEE
• Existen modelos y procesos aplicados en las diferentes Standard for Developing Software Life Cycle Processes -
etapas del proceso de software. Description”,
• La facilidad de entendimiento humano y comunicación, http://standards.ieee.org/reading/ieee/std_public/description/s
ayuda a llevar una buena definición de los procesos. e/1074-1997_desc.html
• La medición del Proceso de un Proyecto de Desarrollo de
Software es primordial pues gracias a éste nos permite [9] Jin Lyu, Kyle Hancock y Linus Luotsinen, IEEE Standard
identificar las fuerzas y las debilidades del mismo y a su 1219-1998 Software Maintenance,
vez del proyecto. http://classes.cecs.ucf.edu/eel6883/berrios/slides/ch%209%2
• La recolección de métricas del proceso es esencial para la 0-%20art%202%20-%20IEEE%20Standard%201219-
mejora del mismo y se utilizan para evaluar la eficiencia 1998.ppt
de un proceso y si éste ha mejorado con los cambios [10] “Métricas”, disponible en: http://alarcos.inf-
realizados. r.uclm.es/doc/Calidad/capitulo09.ppt
• Un producto de software constituye: los ejecutables,
[11] “ISO/IEC 9126” disponible en:
código fuente, descripciones de arquitectura, y así.
http://es.wikipedia.org/wiki/ISO/IEC_9126
• Medir un producto de software implica: la medición del
tamaño del producto, la estructura del producto y la [12] Fernanda Scalone, Software Quality Management,
calidad del producto. disponible en: http://softqm.blogspot.com/2007/01/visin-
• Las métricas en un proyecto de desarrollo de software e se general-acerca-de-iso-9126.html
pueden aplicar a procesos y productos. [13] María Del Carmen Sosa Sierra, “Inteligencia artificial en la
• Las métricas del proceso permiten a una organización de gestión financiera empresarial”,
ingeniería del software tener una visión profunda de la http://ciruelo.uninorte.edu.co/pdf/pensamiento_gestion/23/6_
eficacia de un proceso ya existente Inteligencia%20artificial.pdf
• Dos modelos estandarizados que se los puede utilizar para
la medición de la calidad del Software son: CMMI y ISO [14] Carlos J. Alonso González, Departamento de Informática,
9000. “Inducción de Reglas Proposicionales”,
http://www.infor.uva.es/~calonso/IAII/Aprendizaje/Induccio
nReglasProposicionales.pdf

[15] Wikipedia, “Normas ISO 9000” disponible en: [36] Wikipedia, disponible
http://es.wikipedia.org/wiki/Normas_ISO_9000 en:http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gi
[16] CINTERFOR,“ Gestión de calidad en la formación” l_de_software
disponible en: [37] “Gucoba” disponible en:
http://www.ilo.org/public/spanish/region/ampro/cinterfor/te http://gucoba.com/index.php?option=com_content&vi
mas/calidad/doc/cedefop1.htm ew=article&id=56&Itemid=57
[17] Wikipedia, “Software Engineering Institute” disponible en: [38] Monografias, disponibe en:
http://es.wikipedia.org/wiki/Software_Engineering_Institute
http://www.monografias.com/trabajos67/metodologia-
[18] Wikipedia, “British Computer Society” disponible en: desarrollo-softwares/metodologia-desarrollo-
http://en.wikipedia.org/wiki/British_Computer_Society softwares2.shtml
[19] Wikipedia, “IEEE Computer Society” disponible en: [39] “Método CBA IPI para la evaluación de proyectos”,
http://en.wikipedia.org/wiki/IEEE_Computer_Society Disponible en:
[20] Wikipedia, “RUSSOFT” disponible en: http://www.geocities.com/SiliconValley/Lab/3629/cbai
http://en.wikipedia.org/wiki/RUSSOFT, disponible en: pi.htm
http://www.slideshare.net/aacevedolipes/spin-colombia
[40] “Metodologías De Desarrollo De Software”, María A.
[21] Rduardo A. Rodríguez Tello, “Procesos de software”, 2008, Mendoza Sanchez , 2004,
http://www.tamps.cinvestav.mx/~ertello/swe/sesion03.pdf http://www.willydev.net/InsiteCreation/v1.0/descargas
[22] Chirstian Tzec, “Fundamentos de Desarrollo de Sistemas”, /cualmetodologia.pdf
http://www.scribd.com/doc/16416960/Modelo-cascada- [41] Microsoft Solution Framework, figura tomada de:
espiralincremental http://caraujo334.blogspot.es/img/msf1.jpeg
[23] https://www.mytconsulting.com/principal/images/12207_5.p [42] http://www.mentores.net/default.aspx?tabid=104&type
ng
=art&site=183&parentid=32
[24] http://www.cs.umd.edu/users/basili/qip/img007.gif [43] http://en.wikipedia.org/wiki/Microsoft_Solutions_Fra
[25] http://es.kioskea.net/contents/genie-logiciel/cycle-de- mework
vie.php3
[26] Sid@r, “Prototipado”,
http://www.sidar.org/recur/desdi/traduc/es/visitable/tecnicas/
Prototyping.htm
[27] “Introducción a la Ingeniería de Software”,
http://oacosta334.blogspot.es/tags/prototipo/
[28] Wikipedia, “Modelo de prototipos”, 2009,
http://es.wikipedia.org/wiki/Modelo_de_prototipos
[29] http://cmunoz334.blogspot.es/tags/Modelo/
[30] “MODELOS DE PROCESO ITERATIVOS E
INCREMENTALES”,
http://scruz334.blogspot.es/1193793960/
[31] Wikipedia, “Desarrollo en espiral”, Modificado: 16 abril del
2009,
http://es.wikipedia.org/wiki/Desarrollo_en_espiral#Ventajas
[32] Wikipedia, “Desarrollo iterativo y creciente”, Modificado 18
de Junio 2009,
http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente
#Debilidades_de_este_modelo_de_desarrollo
[33] Samira Lamayzi, “La norma ISO 14764”, 1999,
http://alarcos.inf-
cr.uclm.es/per/fruiz/cur/mso/comple/ISO14764.pdf
[34] http://www.aemes.org/rpm/descargar.php?volumen=4&nume
ro=2&articulo=1
[35] Juan Pablo Gomez Gallego, “Fundamentos de la
Metodología RUP Rational Unified Process”, 2007