Para poder entender los procesos de producción comercial de software debemos

entender primero:

¿Que Es un Proceso de Software?

Conjunto total de actividades necesarias para transformar los requisitos de un cliente

en un conjunto consistente de artefactos que representan un producto “software” y en
punto posterior en el tiempo para transformar cambios en dichos requisitos en nuevas
versiones del producto.

Podemos definir que existen dos tendencias en los procesos de desarrollo de software:

METODOLOGIAS PESADAS O TRADICIONALES

Las metodologías pesadas son consideradas como el extremo de la Burocracia, con

procesos rígidos y definidos al máximo nivel de detalle.

Entre ellos encontramos:

RUP

El proceso unificado de desarrollo (RUP) es una metodología para la ingeniería de

software que va más allá del mero análisis y diseño orientado a objetos para
proporcionar una familia de técnicas que soportan el ciclo completo de desarrollo de
software. El resultado es un proceso basado en componentes, dirigido por los casos de
uso, centrado en la arquitectura, iterativo e incremental.

Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro

de una organización de desarrollo. Su meta es asegurar la producción de software de
muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un
calendario y presupuesto predecible.

El Proceso Unificado se basa en componentes (component-based), lo que significa que

el sistema en construcción está hecho de componentes de software interconectados
por medio de interfaces bien definidas (well-defined interfaces).

METRICA v3

Métrica tiene ya varios años de vida y su actual versión, la 3, se crea con la finalidad
de incorporar las nuevas técnicas derivadas de la programación y el análisis orientado
a objetos, al proceso de desarrollo de software que a través de esta metodología las
administraciones públicas españolas pretenden llevar a cabo.

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

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

- Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de

la Organización mediante la definición de un marco estratégico para el desarrollo de los
mismos.

- Dotar a la Organización de productos software que satisfagan las necesidades de los

usuarios dando una mayor importancia al análisis de requisitos.
- Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la
Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a
los cambios y teniendo en cuenta la reutilización en la medida de lo posible.

- Facilitar la comunicación y entendimiento entre los distintos participantes en la

producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su
papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.

- Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

Posee la siguiente estructura:

ESTRUCTURA PRINCIPAL

• Introducción
• Planificación de Sistemas de Información (Proceso PSI)
• Estudio de Viabilidad del Sistema (Proceso EVS)
• Análisis del Sistema de Información (Proceso ASI)
• Diseño del Sistema de Información (Proceso DSI)
• Construcción del Sistema de Información (Proceso CSI)
• Implantación y Aceptación del Sistema (Proceso IAS)
• Mantenimiento del Sistema de Información (Proceso MSI)

Todo proyecto Métrica 3 consta de un conjunto de fases que se desglosan en múltiples

puntos cuya cronología hay que seguir con claridad para ir avanzando en el desarrollo
del proyecto. El siguiente gráfico muestra el esquema general de estas fases:
MSF (Microsoft Solutions Framework)

Microsoft Solutions Framework (MSF) es una flexible e interrelacionada serie de

conceptos, modelos y prácticas de uso que controlan la planificación, el desarrollo y la
gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo
dejando en un segundo plano las elecciones tecnológicas. Originalmente creado en 1994
para conseguir resolver los problemas a los que se enfrentaban las empresas en sus
respectivos proyectos, se ha convertido posteriormente en un modelo práctico que
facilita el éxito de los proyectos tecnológico

MSF se compone de varios modelos encargados de planificar las diferentes partes

implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,
Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de Diseño
de Proceso y finalmente el modelo de Aplicación.

El modelo de proceso MSF combina los mejores principios del modelo en cascada y del
modelo en espiral. Combina la claridad que planea el modelo en cascada y las ventajas
de los puntos de transición del modelo en espiral.

El Modelo de proceso MSF consta de cinco fases distintas:

1. Previsión
2. Planeamiento
3. Desarrollo
4. Estabilización
5. Implementación
METODOLOGIAS AGILES

El encanto de estas metodologías ágiles es su reacción ante la burocracia de las

metodologías monumentales. Estos nuevos métodos buscan un justo medio entre
ningún proceso y demasiado proceso, proporcionando simplemente suficiente proceso
para que el esfuerzo valga la pena.

El resultado de todo esto es que los métodos ágiles cambian significativamente algunos
de los énfasis de los métodos ingenieriles. La diferencia inmediata es que son menos
orientados al documento, exigiendo una cantidad más pequeña de documentación para
una tarea dada. De muchas maneras son más bien orientados al código: siguiendo un
camino que dice que la parte importante de la documentación es el código fuente.

Manifiesto de las Metodologías Ágiles

En un taller de dos días en Snowbird, Utah, en febrero de 2001 se reunieron los

representantes de cada una de las metodologías ágiles. Había mucho en común, y este
reconocimiento era mucho mayor que las diferencias entre los procesos.

Además de un contacto útil entre los líderes de procesos, existía también la idea de
emitir una declaración conjunta en favor de procesos de desarrollo de software ágiles.

El resultado es un Manifiesto para el Desarrollo de Software Ágil, una declaración de

los principios y valores comunes de los procesos ágiles.

Hay también un deseo de colaborar más en el futuro, para animar más tanto a
tecnólogos como a gente de negocios para usar y requerir acercamientos ágiles al
desarrollo de software.

El manifiesto fue sólo eso, una publicación que actuó como un punto de partida para
aquellos que compartían estas ideas básicas. Uno de los frutos del esfuerzo fue la
creación de un cuerpo más longevo, la Alianza Ágil

La Alianza Ágil es una organización sin fines de lucro que busca promover el
conocimiento y la discusión de todos los métodos ágiles. Muchos de los líderes de
metodologías de desarrollo de software ágiles son miembros y líderes de la Alianza
Ágil.

Los principios que se establecieron en el manifiesto son:

1. La prioridad principal es satisfacer al cliente mediante tempranas y

continuas entregas de software que le reporte un valor.
2. Dar la bienvenida a los cambios. Los MA capturan los cambios para que el
cliente tenga una ventaja competitiva.
3. Entregar frecuentemente software que funcione, desde un par de semanas a
un par de meses, con el menor intervalo de tiempo posible entre una
entrega y la siguiente.
4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo
del proyecto.
5. Construir el proyecto entorno a individuos motivados. Darles el entorno y el
apoyo que necesitan y confiar en ellos para conseguir el trabajo.
 6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro de un equipo de desarrollo.
7. El software que funciona es la medida principal de progreso.
8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz
constante.
9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
10. La simplicidad es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos
organizados por sí mismos.
12. En intervalos regulares, el equipo reflexiona respecto de cómo llegar a ser
más efectivo, y según esto ajusta su comportamiento.

XP

XP (eXtreme Programing) nace como nueva disciplina de desarrollo de software hace

aproximadamente unos seis años, y ha causado un gran revuelo entre el colectivo de
programadores del mundo. Kent Beck, su autor, es un programador que ha trabajado
en múltiples empresas y que actualmente lo hace como programador en la conocida
empresa automovilística DaimlerChrysler. Con sus teorías ha conseguido el respaldo de
gran parte de la industria del software y el rechazo de otra parte.

La programación extrema se basa en la simplicidad, la comunicación y el reciclado

continuo de código, para algunos no es mas que aplicar una pura lógica.

Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata
de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos
responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al
final de ciclo de la programación.

El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los jefes de

proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el
desarrollo del software.

XP está basada en estos cuatro valores:

·Comunicación
·Sencillez
·Retroalimentación
·Valentía

MSF AGILE

MSF Agile (Microsoft Solution Framework Agile) es la nueva propuesta de Microsoft en

el mundo de procesos y prácticas ágiles de desarrollo de software. “Microsoft Agile”
renueva al ya exitoso MSF V3.0, que es un marco de trabajo en cascada y espiral,
implementando las mejores prácticas del mundo de desarrollo ágil de software.

MSF Agile tiene como principales características el ser altamente insistente, de

planificación adaptable a los cambios y enfocado a las personas
Desarrollo Manejado por Rasgos (FDD)

El Desarrollo Manejado por Rasgos (FDD por su sigla en inglés de Feature-Driven

Development) fue desarrollado por Jeff De Luca y el viejo gurú de la Orientación a
Objetos Peter Coad. Como las otras metodologías adaptables, se enfoca en iteraciones
cortas que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran
dos semanas.

El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.
• Desarrollar un Modelo Global
• Construir una Lista de los Rasgos
• Planear por Rasgo
• Diseñar por Rasgo
• Construir por Rasgo

Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da
un criterio de comprobación.

Los desarrolladores entran en dos tipos:

• dueños de clases, y
• programadores jefe.

Los programadores jefe son los desarrolladores más experimentados. A ellos se les
asignan rasgos a construir. Sin embargo ellos no los construyen solos. Sólo identifican
qué clases se involucran en la implantación de un rasgo y juntan a los dueños de
dichas clases para que formen un equipo para desarrollar ese rasgo. El programador
jefe actúa como el coordinador, diseñador líder y mentor, mientras los dueños de clases
hacen gran parte de la codificación del rasgo.

WEBGRAFIA:
http://www.slideshare.net/dersteppenwolf/la-ingeniera-de-software-y-rup
http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
http://www.csae.map.es/csi/metrica3/index.html
http://www.auladirectiva.com/curso/metrica-v3/presentacion.html
http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/planificacion/msf.mspx
http://sel.unsl.edu.ar/ApuntesMaes/2004/Metodologias%20Agiles.doc