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

El proceso de Ingeniería del Software se basa en modelos,
métodos y herramientas que sirven como una guía para los
ingenieros del software durante el proceso de desarrollo, con la
finalidad de mejorar la calidad de los proyectos, procesos y
productos mediante la evaluación y medición de los mismos. El
objetivo de las organizaciones desarrolladoras de estos modelos,
procesos y metodologías es que en las empresas desarrolladoras
de software se los ponga en práctica para ver las mejoras en los
procesos de cada una de las fases de desarrollo. Otro tema
importante son los modelos del ciclo de vida del software, los
cuales se basan en diferentes técnicas y fases pero todos tienen un
mismo fin.
El fin de este trabajo es establecer un entorno general alrededor de
las aplicaciones y definiciones actuales del Proceso de Ingeniería
del Software, el mismo que puede reconocerse en dos niveles: el
primero involucra actividades técnicas y de gestión durante la
adquisición, desarrollo, mantenimiento y retirada del software en
el procesos del ciclo de vida del software y el segundo se refiere a
la definición, implementación, valoración, medición, gestión,
cambios y mejoras de los procesos mismo del ciclo de vida del
software. Algunos modelos estandarizados para la medición de la
calidad como lo son: CMMI e ISO 9000, son mencionados.
Términos Generales
Software, Procesos, Métodos, Modelos, Desarrollo de Software,
Ingeniería del Software, Procesos del Software
números, sabrás algo acerca de eso; pero cuando no puedes
medirlo, cuando no puedes expresarlo en números, tus
conocimientos serán escasos y no satisfactorios”
Lord Kelvin
La medición en general tiene tres principales objetivos: entender
qué ocurre durante el desarrollo y el mantenimiento, mejorar
nuestros procesos y nuestros productos y controlar lo que ocurre
en nuestros proyectos. Dentro de la gestión de proyectos de
desarrollo de software las métricas juegan un papel importante
para entender, monitorizar, controlar, predecir y probar el
desarrollo de software. Las métricas son medio para asegurar la
calidad en los PRODUCTOS / PROCESOS / PROYECTOS
SOFTWARE.
Objetivos
Los principales objetivos del desarrollo de este trabajo son:
• Comprender los conceptos principales relacionados con
el proceso de ingeniería de software y ciclo de vida del
software.
• Conocer los métodos y modelos que se aplican
actualmente en la ingeniería del software.
• Conocer los principales ciclos de vida del software.
2.ESTADO DEL ARTE

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
5, en la que al final de cada una de ellas se reúne la
documentación para garantizar que cumple las especificaciones y
los requisitos antes de pasar a la fase siguiente. [25]
Sus principales características son [6]:
• Cada fase empieza cuando se ha terminado la fase
anterior
• Para pasar de una fase a otra es necesario conseguir
todos los objetivos de la etapa previa
• Al final de cada fase el personal técnico y los usuarios
tienen la oportunidad de revisar el progreso del
proyecto
Las ventajas y desventajas [21], de este modelo se describen a
continuación:
2.3.1.1.1Ventajas
• Ayuda a prevenir que se sobrepasen las fechas de
entrega y los costes esperados
• Bajo riesgo para desarrollos bien comprendidos
utilizando tecnología conocida.
• Este modelo es sencillo ya que sigue los pasos intuitivos
necesarios a la hora de desarrollar el software.
2.3.1.1.2Desventajas
• Su inflexibilidad en la división del proyecto en distintas
etapas
• Esto hace difícil poder responder a los cambios en los
requerimientos del cliente.
• 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
muy difíciles
• Para obtener resultados se debe llegar a la etapa final
del proyecto. Un error importante no detectado hasta
que el programa este funcionando puede ser desastroso.
2.3.1.2Prototipado
Figura 6. Modelo Prototipado [6]
El modelo prototipado [26], modela el producto final y permite
efectuar un test sobre determinados atributos del mismo sin
necesidad de que este disponible. Se trata, simplemente, de testear
haciendo uso del modelo. Esta técnica puede ser utilizada en
cualquier etapa de desarrollo. A medida que el proceso progresa y
el producto se completa, el prototipo ha de abarcar, cada vez más
las características del producto final. En la Figura 6 se listan las
fases del modelo Prototipado.
Existen varios tipos como:
• Prototipado – Rápido
• Prototipado – Evolutivo
• Prototipado – Operacional
• Prototipado – Reutilizable
Los prototipos [6], tienen una doble función:
• El cliente ve el producto y refina sus requisitos
• El desarrollador comprende mejor lo que necesita hacer
Sus principales características son:
• Reduce el riesgo de construir productos que no
satisfagan las necesidades de los usuario
o Reduce costos y aumenta la probabilidad de
éxito
o Exige disponer de las herramientas adecuadas
o No presenta calidad ni robustez
• Suele utilizarse principalmente en dos áreas:
o Prototipado de la interfaz de usuario
o Prototipado del rendimiento
Las ventajas y desventajas [27], [28], se listan a continuación:
2.3.1.2.1Ventajas
• Es mucho mejor y conveniente usar este modelo porque
es el único apto para desarrollos en los que se utiliza
nueva tecnología.
• El prototipado es un medio excelente para recoger la
realimentación del usuario final, así como también es
mucho más rápido de desarrollarse.
• 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
son muy útiles cuando el usuario tiene más requerimientos.
 • El modelo iterativo: Este modelo mejora cada versión
es decir mejora la función que tiene la versión.
• El modelo incremental: Este modelo mantiene la
función anterior y aumenta otra, ya que puede ser que el
primer incremento no hubiera tenido todos los
requerimientos que necesitaba el proyecto.
• Difícil de aplicar a sistemas transaccionales que tienden
a ser integrados y a operar como un todo.
• Los errores en los requisitos se detectan tarde y su
corrección resulta costosa
• Necesitan una gran planeación.
• 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
o Restricciones
• Se evalúan las alternativas respecto a los objetivos y las
restricciones.
• Se formula una estrategia efectiva para resolver las
fuentes de riesgos (simulación, prototipado, etc.).
• Se plantea el próximo prototipo.
• Una vez resueltos los riesgos se sigue el ciclo en
cascada
• Cada ciclo se completa con una revisión que incluye
todo el ciclo anterior y el plan para el siguiente.
Las ventajas y desventajas de este modelo son [31]:
• Demostrar valor iterativamente.
• Elevar el valor de abstracción.
• Enfocarse en la calidad.
2.3.2.1.1Ciclo de vida de RUP
El proceso del RUP está dividido en 4 fases, en estas fases se
realiza varias iteraciones de acuerdo al proyecto, en la Figura 9 se
muestra gráficamente las 4 fases del RUP, cuyas iteraciones están
representadas con líneas verticales y marcadas con la letra
correspondiente a la inicial de la fase, la fase Inicial tiene una sola
iteración.

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.1.4.2Desventajas
• Es difícil evaluar los riesgos
• Necesita de la participación continua por parte del
cliente
• Cuando se subcontrata hay que producir previamente
una especificación completa de lo que se necesita y esto
lleva tiempo.
• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso requiere experiencia en la
identificación de riesgos
2.3.2Metodologías de desarrollo de software
2.3.2.1.2Fase de Inicio
En esta fase se define el modelo del negocio y el alcance del
proyecto, se identifican los autores y casos de usos y se diseñan
los casos de uso esenciales.
Los objetivos son:
• Establecer el ámbito del proyecto y sus limites
• Encontrar los casos de uso críticos del sistema, los
escenarios básicos.
• Mostrar una arquitectura para los escenarios principales.
• Estimar el coste en recursos y tiempo en todo el
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
En esta fase se analiza el dominio del problema, establece los
cimientos de la arquitectura, desarrolla el plan del proyecto y
elimina los riesgos mayores. Se construye un prototipo de la
arquitectura que evoluciona en iteraciones sucesivas hasta
convertirse en el sistema final.
Los objetivos de esta fase son:
• Definir, validar y cimentar la arquitectura.
• Completar la visión
• Crear un plan para la fase de construcción
• Demostrar que la arquitectura propuesta soportara la
visión
•
Los resultados son los siguientes:
• Un modelo de casos de uso al menos el 80%
• Requisitos adicionales que capturan los requisitos no
funcionales.
• Descripción de la arquitectura software
• Prototipo ejecutable de la arquitectura.
• Lista de riesgos y caso de negocio revisados
• Plan de desarrollo para el proyecto
• Manual de usuario preliminar.
2.3.2.1.4Fase de Construcción
En esta fase la finalidad es alcanzar la capacidad operacional del
producto de forma incremental a través de las sucesivas
iteraciones, en esta fase todas las componentes, características y
requisitos deben ser implementados, integrados y cambiados en su
totalidad.
Los objetivos son:
• Minimizar los costes de desarrollo mediante la
optimización de recursos.
• Conseguir calidad adecuada.
• Conseguir versiones funcionales tan rápido como sea
práctico.
Los resultados de la fase de construcción deben ser:
• Modelos completos(casos de uso, análisis, diseño,
despliegue e implementación)
• Arquitectura integra.
• Riesgos presentados mitigados
• Plan del proyecto para la fase de transición.
• Manual inicial de usuario.
• Prototipo operacional.
• Caso del negocio actualizado.
2.3.2.1.5Fase de Transición
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,
configuración, instalación y facilidad de uso del producto. En esta
fase también se realiza:
• La prueba de la versión beta para validar al nuevo
sistema frente a las expectativas del usuario.
• Funcionamiento paralelo con los sistemas legados que
están siendo sustituidos por el nuevo proyecto.
• Conversión de las bases de datos operacionales.
• Entrenamiento de los usuarios y técnicos de
mantenimiento.
• Traspaso del producto a los equipos de marketing,
distribución y venta.
Los objetivos de esta fase son:
• Conseguir que el usuario se valga por si mismo.
• Un producto final que cumpla los requisitos esperados,
que funcione y satisfaga suficientemente al usuario.
Los resultados son:
• Prototipo operacional
• Documentos legales
• Caso del negocio completo
• Línea base del producto completa y corregida que
incluye todos los modelos del sistema
• Descripción de la Arquitectura completa y corregida.
• Las iteraciones de esta fase irán dirigidas normalmente
a conseguir una nueva versión.
Los criterios de evaluación de esta fase son:
• El usuario se encuentra satisfecho.
• Son aceptables los gastos actuales versus los gastos
planificados.
2.3.2.2MSF
La metodología MSF (Microsoft Solucion Framework) [40], es
flexible e interrelacionada con una serie de conceptos, modelos y
prácticas de uso, y guías para diseñar y desarrollar soluciones
empresariales de una manera que asegura que todos los elementos
del proyecto tal como gente, procesos y herramientas, puedan ser
exitosamente conducidos.
MSF no sólo es aplicable al desarrollo de proyectos de desarrollo,
también es aplicable a otros proyectos de TI, como el despliegue
o proyectos de infraestructura o redes. MSF no fuerza al
desarrollador a utilizar una metodología específica (Cascada,
ágil), pero les permite decidir qué método utilizar.

Figura 10. Fases del modelo MSF [41]
El MSF está compuesto 6 por fases, como se muestra en la Figura
10, las fases se listan a continuación:
1. Visión: donde se reúne un equipo del proyecto, define
la visión y el ámbito de una solución que cumplirá los
objetivos del cliente. El equipo organiza entonces el
proyecto y proporciona un documento de visión/ámbito
aprobado. Las personas encargadas de funciones de
administración de productos y administración de
programas toman el mando en esta fase.
2. Planeación: donde se desarrollan los procesos de
diseño conceptual, lógico y físico, así como la
especificación funcional. La persona encargada de
funciones de administración de programas toma el
mando durante esta fase y crea planes de proyecto que
tratan el desarrollo, la comunicación y otras tareas; y
cada función proporciona los datos para crear la
programación del proyecto.
3. Desarrollo: El equipo crea y prueba la solución. La
persona encargada de funciones de desarrollo toma el
mando durante esta fase.
4. Estabilización: El equipo crea la solución piloto en
preparación para el lanzamiento de producción. La
persona encargada de las funciones de prueba toma el
mando durante esta fase.
5. Instalación.
6. Soporte
Las características más relevantes del MSF son:
• Adaptable: Es parecido a un compás, usado en
cualquier parte como un mapa, del cual su uso es
limitado a un específico lugar.
• 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:
• Fomentar la comunicación abierta.
• Trabajar en pro de una visión compartida.
• La autonomía de los miembros del equipo.
• Establecer una clara rendición de cuentas y la
responsabilidad compartida.
• Centrarse en entregar valor de negocio.
• Mantenerse ágil a espera del cambio.
• Invertir en calidad.
• Aprender de todas las experiencias.
MSF para Metodologías de Desarrollo Ágil (MSF4ASD)
MSF para Metodologías de Desarrollo Ágil es un proceso de
desarrollo manejado por escenarios, basado en contexto, que
utiliza muchas de las ideas incorporadas en Team System
(herramientas de Microsoft). Este proceso incorpora las prácticas
probadas desarrolladas en Microsoft con respecto a los
requerimientos, diseño, seguridades, rendimiento y pruebas
(testing) [42].
MSF para metodologías de desarrollo ágil presenta una guía
muy recomendable a los Desarrolladores y Gestores de proyectos
de software que pueden adaptarla a la metodología de su empresa,
en la que incluye documentos de ejemplo, plantillas, archivos en
blanco de Project, Excel y Word para la administración de
proyectos, requerimientos, seguridad y pruebas.
MSF para CMMI (MSF4CMMI)
EL MSF4CMMI para CMMI es una metodología formal para la
ingeniería de software es un proceso de mejora que proporciona a
las organizaciones los elementos esenciales del proceso continuo
de mejora que den lugar a una reducción de Ciclo de vida del
Desarrollo de Software, la mejora de la capacidad para satisfacer
las metas de costos y el calendario, la construcción de productos
de alta calidad.
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
distribuidos adecuadamente.
• Menos énfasis en la arquitectura del software, siendo
ésta primordial para el éxito del proyecto de software.
2.3.2.3.4Uso de Metodologías
El surgimiento de estas revolucionarias metodologías que no solo
nacen para el desarrollo de sistemas software sino para el manejo
o desarrollo de productos los incrementos en adeptos se presentan
gradualmente con el tiempo y las tecnologías. En la Figura 11, se
muestra [38]
Figura 11. Uso de Métodos Ágiles [38]
2.3.3Procesos del ciclo de vida del Software
2.3.3.1Estándar IEEE 1074
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
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
describe las diferentes actividades que van a ser asignada en el
modelo seleccionado. Sin embargo, este estándar no es una guía
de instrucción. También puede ser utilizado para desarrollar los
procesos de organización para apoyar el desarrollo de software y
procesos que tiene una única función dentro de un proyecto.
2.3.3.2Procesos de Mantenimiento:
2.3.3.2.1 IEEE 1219-1998
El estándar IEEE 1219-1998 [9], se basa en procesos iterativos
para ejecutar y manejar el mantenimiento de software.
Los procesos están aplicados a:
• Planeación de mantenimiento mientras el producto está
desarrollándose.
• Planeación y ejecución de mantenimiento para
productos de software existente.
• Aplica cualquiera de los modelos del ciclo de vida
disponibles.
• Estándares prescriben los requerimientos para procesos,
control y manejo de la planeación, ejecución y
documentación de actividades de mantenimiento de
software.
2.3.3.2.2 ISO 14764:1998
É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
de vida de un producto software. En muchos proyectos,
especialmente aquellos que tienen una vida larga, el
mantenimiento del software es con seguridad una de las
consideraciones más importantes del proyecto. Por esta razón es
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
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
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
procesos de ingeniería del software.
2.4Evaluación de Procesos
2.4.1Modelos de Evaluación del proceso
2.4.1.1CMMI
CMMi intenta proveer una guía para los procesos. Las áreas
específicas relacionadas son:
• Calidad de proceso y producto
• Verificación del proceso
• Validación del proceso
Hubo inicialmente algún debate sobre si la ISO 9001 o CMMi
podrían ser usadas por los ingenieros del software para asegurar la
calidad. Este debate fue publicado y como resultado la decisión
ha sido tomada que los dos son complementarios y que
teniendo certificación ISO 9001 puede ayudar grandiosamente en
altos niveles de madurez del CMMi. [6]
El modelo CMMI es un modelo de calidad del software que
clasifica las empresas en niveles de madurez. Estos niveles sirven
para conocer la madurez de los procesos que se realizan para
producir software.
2.4.2Métodos de evaluación del proceso
Estos medos fueron desarrollados por el SW-CMM
2.4.2.1CBA-IPI
El CBA-IPI [39], es un método de evaluación basado en CMM
sirve para mejorar internamente los procesos, fue desarrollado por
el Softare Engneer Institute de la Universidad Carnegie Mellon.
Es una herramienta de diagnostico que permite a las
organizaciones y proyectos el poder determinar las fortalezas y de
sus procesos de desarrollo de software, utiliza el método de
madurez de capacidades para software desarrollado por el SEI
2.4.2.2SCAMPI
Los métodos SCAMPI son grandes torres de evaluación CMMi.
Las actividades ejecutadas durante una evaluación, la distribución
de esfuerzo en estas actividades como la atmosfera durante una
evaluación son diferentes cuando son de mejora para la
adjudicación de un contrato.
2.5Medidas de Productos y Procesos
La medición de software es una disciplina relativamente joven,
consenso general sobre la definición exacta de los conceptos y
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.
A pesar de todo, los lectores encontrarán diferencias
terminológicas en la literatura; por ejemplo, el término “métrica”
se utiliza a veces en vez de “medida”. En la Figura1 se muestra el
ámbito de ISO/IEC 15939: [10]
Figura 12. Ámbito de la ISO/IEC 15939 [10]
Las actividades de la ISO/IEC 15939 son:
• Establecer y Mantener el Compromiso de Medición que
implica tareas como:
o Aceptar los requisitos de medición.
o Asignar recursos.
• Planificar el Proceso de Medición que implica tareas
como:
o Obtener características de la Organización.
o Identificar las necesidades de la Información.
o Seleccionar las medidas.
o Definir los procedimientos de recolección de
datos, análisis e informes.
o Definir los criterios de evaluación de los
productos de información y el proceso de
medición.
o Revisar, aprobar y proporcionar recursos para
las tareas de medición.
o Adquirir y utilizar tecnologías de apoyo.
• Realizar el Proceso de Medición que implica tareas
como:
o Integrar los procedimientos,
o Recoger los datos,
o Analizar los datos y desarrollar productos de
información.
o Comunicar los resultados.
• Evaluar la Medición que implica tareas como:
o Evaluar productos de información y el
proceso de medición,
o Identificar las mejoras potenciales.
2.5.1Medición del Proceso: ISO 15539-02
La medición del Proceso significa recoger, analizar e interpretar
información cuantitativa sobre nuestros procesos, para identificar
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.
• Número de Ocurrencias de un Evento número de
defectos descubiertos durante la revisión del código,
número de peticiones de cambio en requerimientos,
número promedio de líneas de código (LDC)
modificadas en respuesta a un cambio de
requerimientos, errores detectados por el usuario, etc.
Justificación
La recolección de métricas del proceso es esencial para la mejora
del mismo y se utilizan para evaluar la eficiencia de un proceso y
si éste ha mejorado con los cambios realizados.
• Las dos primeras métricas ayudan a descubrir si los
cambios en el proceso mejoran la eficiencia de un
proceso. Por ejemplo, se puede medir el tiempo y
esfuerzo necesarios para moverse de un hitos fijo a otro,
como la aceptación de requerimientos, terminación de
un diseño arquitectónico, etc. Esos valores ayudan a
identificar áreas de mejora en el proceso. Una vez
introducidos los cambios, las mediciones posteriores
indican si los cambios han sido positivos.
• El número de ocurrencias de un Evento Tienen
influencia directa en la calidad del software. Por
ejemplo, incrementar el número de defectos
descubiertos al cambiar el proceso de revisión del
código probablemente se reflejará en una mejora de la
calidad del producto, aunque tiene que confirmarse por
mediciones posteriores del producto.
Se describiría a las salidas de los procesos como: calidad del
producto (errores por KLOC (Kilo Líneas de Código) o por Punto
Función (FP)), mantenibilidad (el esfuerzo para hacer un cierto
tipo de cambio), productividad (LDC (Líneas de Código)) o
Puntos Función por persona-mes), tiempo-de-mercado, o
satisfacción del cliente (como medidos por medio de una encuesta
a clientes). Esta relación depende del contexto particular (por
ejemplo, el tamaño de la organización o el tamaño del proyecto).
De allí que el obtener las salidas del proceso que deseamos
significa que se debió haber implementado los procesos
adecuados.
2.5.2Medición del Producto: ISO 9126-01
¿Qué es un producto de software?
Un producto de software se lo puede describir en un sentido
extenso como: los ejecutables, código fuente, descripciones de
arquitectura, y así.
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
producto.
Un estándar internacional para la evaluación del Software es el
ISO 9126 supervisado por el proyecto SQuaRE, ISO 25000:2005.
[11] Permite evaluar la calidad del software desde distintas
perspectivas relacionadas con el desarrollo, adquisición,
requerimientos, uso, evaluación, mantenimiento, aseguramiento
de la calidad.
El estándar está dividido en cuatro partes las cuales dirigen,
respectivamente, lo siguiente:
2.5.2.1Modelo de la Calidad
Describe el modelo de calidad del producto de software
especificando 6 características de calidad interna (evalúa el total
de atributos que un software debe satisfacer) y externa (evalúa
que el software satisfaga las necesidades del usuario), que son
manifestadas externamente cuando el software es utilizado, y son
un resultado de atributos internos del software. El modelo de
calidad de ISO 9126-1 establece 3 niveles: (1) Característica, (2)
Subcaracterística y (3) Métricas. [12]
Características de calidad del ISO 9126-1:2001:
• Funcionalidad: conjunto de atributos que se relacionan
con la existencia de un conjunto de funciones y sus
propiedades específicas. Las funciones son aquellas que
satisfacen lo indicado o implica necesidades. Las
subcaracterísticas son: Idoneidad, Exactitud
Interoperabilidad, Seguridad, Cumplimiento de normas.
• Fiabilidad: conjunto de atributos relacionados con la
capacidad del software de mantener su nivel de
prestación bajo condiciones establecidas durante un
período de tiempo establecido. Las subcaracterísticas
son: Madurez, Tolerancia a fallas, Facilidad de
Recuperación, Conformidad de Fiabilidad.
• Usabilidad: conjunto de atributos relacionados con el
esfuerzo necesitado para el uso, y en la valoración
individual de tal uso, por un establecido o implicado
conjunto de usuarios. Las subcaracterísticas son:
Aprendizaje, Comprensión, Operatividad, Atractividad,
Conformidad de Usabilidad
• Eficiencia: conjunto de atributos que se refieren a las
relaciones entre el nivel de rendimiento del software y
la cantidad de recursos utilizados bajo unas condiciones
predefinidas. Las subcaracterísticas son:
Compartimiento en el tiempo, Compartimiento de
recursos, Conformidad de eficiencia.
• Mantenibilidad: conjunto de atributos relacionados con
la facilidad de extender, modificar o corregir errores en
un sistema software. Las subcaracterísticas de la
Facilidad de Mantenimiento son: Facilidad de análisis,
Facilidad de cambio, Estabilidad y Facilidad de prueba.
• Portabilidad: conjunto de atributos relacionados con la
capacidad de un sistema software para ser transferido
desde una plataforma a otra. Las subcaracterísticas de la
Portabilidad son: Capacidad de instalación, capacidad
de reemplazamiento, Adaptabilidad y Co-Existencia.
2.5.2.2Métricas Externas– ISO 9126-2:2003
Las cuales miden el software en sí mismo o software en ejecución
(Calidad Externa – Ambiente de Prueba).
2.5.2.3Métricas Internas – ISO 9126-3: 2003
Las cuales miden el comportamiento del sistema, dichas métricas
se aplican cuando el software no está en ejecución por ejemplo
durante el diseño y codificación. (Calidad Interna – Ambiente de
Desarrollo)
2.5.2.4Calidad en Uso–ISO 9126-4: 2004
El cual mide el efecto de usar el software en un contexto
específico (Ambiente de Producción).
ISO 9126-2, ISO 9126-3 e ISO 9126-4 están encaminados en
ambientes de Prueba, Desarrollo y Producción respectivamente.
¿Quién puede utilizar esta norma?
Esta Norma puede ser usada por desarrolladores, evaluadores
independientes y grupos de aseguramiento de la calidad
responsable de especificar y evaluar la calidad del software.
3.MODELOS ESTANDARIZADOS
DISPONIBLES
3.1CMMI
CMMI es un modelo de calidad del software que clasifica las
empresas en niveles de madurez. Estos niveles sirven para
conocer la madurez de los procesos que se realizan para producir
software.
3.1.1Niveles CMM – CMMI
Los niveles CMM - CMMI son 5:
• Inicial o Nivel 1 CMM – CMMI: En este nivel pertenecen
aquellas empresas que no tienen sus procesos bien definidos.
Características comunes de este tipo de empresas son: los
presupuestos se disparan, no se entrega el proyecto en fechas
establecidas, no hay control sobre el estado y desarrollo del
proyecto. El simple hecho de existir como empresa de
software se está en el nivel1.
• Repetible o Nivel 2 CMM – CMMI: El objetivo que
pretende alcanzar el nivel 2 es que los proyectos que lleve a
cabo las empresas se los ejecute con una adecuada gestión de
los procesos lo que implica planeación, ejecución, control,
medición de los mismos. Es un nivel difícil de alcanzar pues
al establecer procesos se está pretendiendo cambiar la forma
de trabajar de la empresa que muchas de las veces implica un
cambio cultural de la misma y por ende lo más importante
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
CMM-CMMI nivel 2.
Los procesos que hay que implantar para alcanzar este nivel
son:
• Gestión de requisitos
• Planificación de proyectos
• Seguimiento y control de proyectos
• Gestión de proveedores
• Aseguramiento de la calidad
• Gestión de la configuración
• Definido o Nivel 3 CMM – CMMI: Pertenecer a este nivel
significa que los proyectos que se llevan a cabo a más de
contar con procesos gestionados, la organización o empresa
debe contar con una forma definida para desarrollar dichos
proyectos es decir sus procesos deben estar establecidos,
documentados y contar con métricas para la consecución de
objetivos concretos.
Los procesos que hay que implantar para alcanzar este nivel
son:
• Desarrollo de requisitos
• Solución Técnica
• Integración del producto
• Verificación
• Validación
• Desarrollo y mejora de los procesos de la
organización
• Definición de los procesos de la organización
• Planificación de la formación
• Gestión de riesgos
• Análisis y resolución de toma de decisiones
• 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
para el control de los procesos, como pueden por ejemplo se
usan las métricas para gestionar la organización.
Los procesos que hay que implantar para alcanzar este nivel
son:
• Gestión cuantitativa de proyectos
• Mejora de los procesos de la organización
• Optimizado o Nivel 5 CMM – CMMI
Los procesos de los proyectos y de la organización en este
nivel a más de ser cuantitativamente gestionados están
orientados a la mejora de las actividades mediante el uso de
métricas.
Los procesos que hay que implantar para alcanzar este nivel
son:
• Innovación organizacional.
• Análisis y resolución de las causas.
3.2ISO 9000
“ISO 9000” se refiere a una serie de normas internacionales que
define un sistema de “Garantía de Calidad” en las organizaciones:
ISO 9001, ISO 9002, ISO 9003 e ISO 9004 (y sus subnormas)
desarrollado por la Organización Internacional de Normalización
(ISO). Esta norma ha sido adoptada por 90 países en todo el
mundo y está compuesta por representantes de normas nacionales
de más de 100 países.
La familia de normas apareció por primera vez en 1987 teniendo
como base una norma estándar británica (BS), y se extendió
principalmente a partir de su versión de 1994, estando
actualmente en su versión 2008, publicada el 13 de noviembre de
2008. La principal norma de la familia es actualmente la: ISO
9001:2008 - Sistemas de Gestión de la Calidad - Requisitos. [15]
3.2.1Proceso de Certificación
• Para brindar una certificación bajo la norma ISO
9000 a determinada empresa u organización,
existen las entidades certificadoras vigiladas por
organismos nacionales que les dan su acreditación
y son las encargadas de verificar que dichas
organizaciones o empresas cumplen con los
requisitos de la norma, una vez que éstas hayan
elegido el alcance de la actividad profesional que
se va a registrar, seleccionado un registro,
someterse a la auditoría y haber concretado con
éxito dicho proceso; se les otorga un certificado y
sello.
¿Qué hacer ante el incumplimiento?
Si un auditor/registrador encuentra áreas de incumplimiento la
organización o empresa tiene un plazo para adoptar medidas
correctivas, sin perder la vigencia de la certificación o la
continuidad en el proceso de certificación.
3.2.2 Marco Conceptual
La ISO 9001 y la ISO 9002 son normas de sistema. ISO 9001 se
aplica a las empresas que se dedican al diseño de productos o
servicios y también a su producción o implementación. ISO 9002
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
que una organización es perfectamente capaz de cumplir las
necesidades y requisitos de sus clientes de manera planificada y
controlada [16]. Si quiere ir más allá y lograr la excelencia,
debería cumplir requisitos adicionales. La ISO 9004:2000
establece estos requisitos adicionales.
4.ORGANIZACIONES
4.1Software Engineering Institute (SEI)
Es un instituto federal estadounidense de investigación y
desarrollo, fundado por el Congreso de los Estados Unidos en
1984 para desarrollar modelos de evaluación y mejora en el
desarrollo de software, que dieran respuesta a los problemas que
generaba al ejército estadounidense la programación e integración
de los sub-sistemas de software en la construcción de complejos
sistemas militares. Financiado por el Departamento de Defensa de
los Estados Unidos y administrado por la Universidad Carnegie
Mellon.
Es un referente en Ingeniería de Software por realizar el
desarrollo del modelo SW-CMM (1991) que ha sido el punto de
arranque de todos los que han ido formando parte del modelo que
ha desarrollado sobre el concepto de capacidad y madurez, hasta
el actual CMMI. [17]
4.2 British Computer Society (BCS):
Es una organización profesional y una sociedad científica que
representa a las personas que trabajan en la tecnología de la
información. Establecida en 1957, es el más grande de Reino
Unido basados en un organismo profesional de la informática.
Cubre los más de 68.000 miembros en más de 100 países, BCS es
una sin fines de lucro y se incorporó por Carta Real en 1984. Sus
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
avanzar en el conocimiento de la educación en las TIC en
beneficio de los profesionales y el público en general. [18]
4.3 IEEE Computer Society
En una unidad de organización del Instituto de Ingenieros
Eléctricos y Electrónicos (IEEE). Se estableció en 1963 cuando el
Instituto Americano de Ingenieros Eléctricos (AIEE) y el Instituto
de Ingenieros de Radio (IRE) se fusionaron para crear el IEEE.
En el momento de la fusión, la AIEE del Subcomité de gran
escala de Computación (creado en 1946) se fusionó con el IRE
del Comité Técnico de Electrónica Informática (establecida 1948)
para crear el Grupo de IEEE Computer. El grupo se convirtió en
el IEEE Computer Society en 1971.
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
procesamiento de la información." Procura "ser el proveedor líder
de información técnica y servicios a los profesionales del mundo
de la informática". [19]
4.4 RUSSOFT Association
Con sede en San Petersburgo, es un multi-nacional de la
asociación de software de empresas de Rusia, Ucrania y
Bielorrusia. Fue fundada el 9 de septiembre de 1999 y se ha
fusionado con la de Fort-Ross Consorcio en mayo de 2004.
Al igual que en la India NASSCOM, RUSSOFT fue creado para
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
presionar a sus intereses en sus países los gobiernos. [20]
5.MEJORA DE LOS PROCESOS DE
SOFTWARE
La mejora de procesos de Software (MPS) es un término que se
usa cuando se referencian mejoras al proceso de software.
Históricamente CMMI (y otros estándares y métodos envueltos) y
otras organizaciones añadieron un “S” para ampliar el alcance a
sistemas y procesos de software (MPSS), mientras que otras
organizaciones reemplazaron “Software” por “Sistemas” para
guardar el mismo acrónimo: Mejora de Procesos de Sistemas
(MPS) e incluir HW, SW, FW y WW. [21]
5.1Enfoque para MPS
En la mejora de procesos de software podemos encontrar tres
enfoques principales (o paradigmas) para la mejora de procesos
de sistemas/software que se usan independientes o combinadas:
• Mejora apoyada en Modelos: este enfoque se basa en
el uso de prácticas aceptadas por la industria como un
modelo para mejorar una organización, que no está
consolidada a estas prácticas. Frecuentemente se usan
dos modelos:
o Modelo de Madurez de capacidad integrada
(CMMI) del Instituto de Ingeniería de Software
(SEI).
o Conjunto de estándares de la ISO-9000 de la
Organización Internacional para la estandarización.
• Mejora de Procesos “Bottom-Up”: este enfoque se
centra en hacer mediciones como tamaño, esfuerzo,
productividad, defectos, reuso y otros indicadores de
procesos consiguiendo así datos de líneas-base y cuando
se determina que habido mejoras potenciales el cambio
se implementa. El efecto del cambio determina la
ocurrencia de una mejora significativa y el resultado es
usado para manejar el cambio organizacional.
 • 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