Introduccin al Proceso de Desarrollo de Software

Un proceso define quin est haciendo qu, cundo, y cmo alcanzar un

determinado objetivo. En la ingeniera del software el objetivo es construir
un producto software o mejorar uno existente. Un proceso efectivo
proporciona normas para el desarrollo eficiente de software de calidad.
Captura y presenta las mejores prcticas que el estado actual de la
tecnologa permite. En consecuencia, reduce el riesgo y hace el proyecto
ms predecible. Es necesario un proceso que sirva como gua para todos
los participantes: clientes, usuarios, desarrolladores y directores
ejecutivos.
La tendencia actual en el software lleva a la construccin de sistemas ms
grandes y ms complejos. Por tanto, el problema del software se reduce a
la dificultad que afrontan los desarrolladores para coordinar las mltiples
cadenas de trabajo de un gran proyecto de software. La comunidad de
desarrolladores necesita una forma coordinada de trabajar. Necesita un
proceso que integre las mltiples facetas del desarrollo. Necesita un
proceso que: proporcione una gua para ordenar las actividades de un
equipo, especifique los artefactos que deben desarrollarse, y ofrezca
criterios para el control y medicin de los productos y actividades del
proyecto. El Proceso Unificado de Desarrollo o ms actualmente conocido
como RUP, es una alternativa de solucin al problema del software.
El Proceso Unificado no es slo un proceso de desarrollo de software, es
tambin un marco de trabajo genrico que puede especializarse para una
gran variedad de sistemas software y diferentes tamaos de proyectos. Se
caracteriza principalmente por estar dirigido por los casos de uso, estar
centrado en la arquitectura, y ser iterativo e incremental.
Los casos de uso definen la funcionalidad del sistema y guan su diseo,
implementacin y prueba; esto es, guan el proceso de desarrollo. Por otra
parte, la arquitectura software incluye los aspectos estticos y dinmicos
ms significativos del sistema. Por un lado, los casos de uso deben encajar
en la arquitectura cuando se llevan a cabo. Por otro lado, la arquitectura
debe permitir el desarrollo de todos los casos de uso requeridos, ahora y
en el futuro. En realidad, tanto la arquitectura como los casos de uso
deben evolucionar en paralelo.

El desarrollo de un producto software comercial puede durar mucho

tiempo, meses o hasta algunos aos. Por lo tanto, es prctico dividir el
trabajo en partes ms pequeas o miniproyectos. Cada miniproyecto es
una iteracin, planificado entre 2 a 6 semanas aproximadamente, que
resulta en un incremento. El resultado de cada iteracin es un sistema
ejecutable, pero incompleto; no est preparado para ser puesto en
produccin. No es un prototipo experimental, es un subconjunto con
calidad de produccin, es decir que el avance del producto software que
resulte de la iteracin debe estar probado y aceptado por los interesados.

El sistema crece incrementalmente a lo largo del tiempo, iteracin tras

iteracin, y por ello, este enfoque tambin se conoce como desarrollo
iterativo e incremental.

Beneficios del desarrollo iterativo:

Mitigacin tan pronto como sea posible de riesgos altos. Esto quiere
decir que se resuelven los casos de uso ms significativos y
complejos en las primeras iteraciones.
Progreso visible en las primeras etapas. Esto quiere decir que los
interesados en el producto software pueden ver parte de la
funcionalidad del sistema en las primeras iteraciones.
Una temprana retroalimentacin, compromiso de los usuarios y
adaptacin, que nos lleva a un sistema refinado que se ajusta ms a
las necesidades reales del personal involucrado.
Gestin de la complejidad.
El conocimiento adquirido en una iteracin se puede utilizar para
mejorar el propio proceso de desarrollo, iteracin a iteracin.
Las fases:
Inicio: Visin aproximada, anlisis del negocio, alcance,
estimaciones imprecisas. No es un fase de requisitos, sino una
especie de fase de viabilidad donde se lleva a cabo slo el estudio
suficiente para decidir si continuar o no.
Elaboracin: Visin refinada, implementacin iterativa del ncleo
central de la arquitectura, resolucin de los riesgos altos,
identificacin de ms requisitos y alcance, estimaciones ms
realistas. No es una fase de requisitos o de diseo, sino es una fase
donde se implementa, de manera iterativa, los casos de uso ms
significativos para la arquitectura o de ms alto riesgo.
Construccin: Implementacin iterativa del resto de requisitos de
menor riesgo y elementos ms fciles, preparacin para el
despliegue.
Transicin: Pruebas beta, despliegue.

El Marco de Desarrollo
Es importante saber que en RUP todas las actividades y artefactos
(modelos, diagramas, documentos ) son opcionales, bueno, quizs el
cdigo no!. En un proyecto RUP, un equipo debera seleccionar un
pequeo subconjunto de artefactos que sirvan para tratar sus problemas y
necesidades particulares, que demuestran tener un gran valor prctico. La
eleccin de los artefactos de RUP para un proyecto podra recogerse en un
documento breve denominado Marco de Desarrollo.
Como artefactos recomendados para los proyectos se debera considerar
los siguientes:
DISCIPLINA
Modelado del Negocio
Requisitos

Anlisis y Diseo

Implementacin
Pruebas
Gestin de Proyectos

ARTEFACTO
Modelo del Dominio
Visin
Modelo de Casos de Uso
Especificaciones Suplementarias
Modelo de Diseo
Documento de Arquitectura de Software
Modelo de Datos
Modelo de Implementacin
Modelo de Pruebas
Plan de Desarrollo de Software

El RUP gil
Se pueden distinguir diferentes tipos de procesos: procesos pesados y
ligeros, y procesos predictivos y adaptables. Un proceso pesado es un
trmino peyorativo, que pretende sugerir un proceso con las siguientes
cualidades:
Muchos artefactos creados en un ambiente burocrtico.
Rigidez y control.
Planificacin detallada, muy larga y elaborada.
Predictivo ms que adaptable.
Un proceso predictivo es aquel que intenta planificar y predecir en detalle
las actividades y asignacin de recursos (personal) en un intervalo
relativamente largo de tiempo, tal como la totalidad de un proyecto. Los

procesos predictivos normalmente siguen un ciclo de vida en cascada o

secuencial. Frente a esto, un proceso adaptable es aquel que acepta el
cambio como motor inevitable y fomenta la adaptacin flexible;
normalmente sigue un ciclo de vida iterativo. Un proceso gil implica un
proceso adaptable y ligero, listo para responder rpidamente a las
necesidades cambiantes.
La intencin de RUP no era que fuese pesado o predictivo, aunque su
amplio conjunto de actividades y artefactos opcionales, ha llevado a
algunos a tener esta impresin. Ms bien, la intensin fue que se adoptara
y aplicara con el espritu de un proceso gil. Por ejemplo, en RUP se puede
optar por un conjunto pequeo de actividades y artefactos, y tampoco
existe un plan detallado para todo el proyecto.