Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SOFTWARE
1
Ingenierı́a Informática
Ciencias de la Computación
neofrancosh@gmail.com
2
1 Introducción
Según la muy difundida (y no por eso confiable) Wikipedia encontramos la sigu-
iente definición: ”Se entiende como desarrollo ágil de software a un paradigma
de desarrollo de software basado en procesos ágiles. Los procesos ágiles de desar-
rollo de software, conocidos anteriormente como metodologı́as livianas, intentan
evitar los tortuosos y burocráticos caminos de las metodologı́as tradicionales en-
focándose en la gente y los resultados.” Por ende y basándome en la información
encontrada en la nube me doy cuenta que hoy por hoy el tema referido a las
metodologı́as de desarrollo se encuentra tambien bajo el nombre de ”Desarrollo
ágil de Software”. La Metodologı́a de Desarrollo vendrı́a a ser entonces una
colección de documentación formal referente a los procesos, las polı́ticas y los
procedimientos que intervienen en el desarrollo del software. En Ingles software
development methodology (SDM) o system development life cycle (SDLC). La
finalidad de una metodologı́a de desarrollo es garantizar la eficacia (p.ej. cumplir
los requisitos iniciales) y la eficiencia (p.ej. minimizar las pérdidas de tiempo) en
el proceso de generación de software. Los riesgos a afrontar y los controles a es-
tablecer varı́an en función de las diferentes etapas del ciclo de vida de desarrollo.
De forma general podrı́amos encontrar las siguientes fases:
• Documentación funcional
• Arquitectura y diseño técnico
• Codificación y ejecución de pruebas unitarias
• Pruebas globales del sistema
• Pruebas de integración
• Implantación
• Formación de usuarios
Ademas, durante todo el ciclo de vida del proyecto se deberán realizar las
siguientes tareas:
3
• Gestión del entorno de desarrollo: herramientas de desarrollo, librerı́as,
ficheros, gestión de datos.
Figure 1:
4
La relación entre los diferentes procesos variará en función de la metodologı́a
que la organización desee utilizar. En términos generales, podrı́amos hacer 3
agrupaciones:
Figure 2:
5
Para la implantación de mecanismos de mejora, primero es necesario iden-
tificar/mapear los procesos definidos en la ISO 12207 con los procesos de la
organización. En una segunda parte, a partir del modelo de referencia definido
en el estándar, es posible medir el nivel de ”capacidad” de cada uno de los
procesos:
• Nivel 0 - Proceso incompleto: El proceso no existe o no cumple con los
objetivos
• Nivel 1 - Proceso ejecutado
• Nivel 2 - Proceso gestionado: el proceso no solo se encuentra en fun-
cionamiento, sino que es planificado, monitorizado y ajustado.
• NIvel 3 - Proceso definido: el proceso, los recursos, los roles y responsabil-
idades se encuentran documentados y formalizado.
• Nivel 4 - Proceso predecible: se han definido técnicas de medición de
resultados y controles.
• Nivel 5 - Proceso optimizado: todos los cambios son verificados para de-
terminar el impacto, se han definido mecanismos para la mejora continua,
etc.
Por tanto, para cada proceso se evalua y se asigna un nivel. A partir de aquı́,
es posible definir las acciones de mejora necesarias. En general, la ISO 15504
consta de las siguientes normas:
Figure 3:
Ahora que tenemos la idea de lo que es, posee y requiere una Metodologı́a
de Desarrollo de Software paso a presentar algunas de las metodologı́as mas
utilizadas. Poniendo de menos a más ágil, de más ’revolucionaria’ a menos, las
metodologı́as más populares, tenemos la siguiente lista:
6
• SCRUM
• RUP - Rational Unified Process
• MSF Agile
• Extreme Programming
A continuación detallaré SCRUM y RUP que son las metodologı́as mas co-
munes, utilizadas y eficientes.
2 SCRUM
Es una forma de gestionar proyectos de software. No es una metodologı́a de
análisis, ni de diseño, es una metodologı́a de gestión del trabajo. Es un proceso
ágil que puede ser usado para gestionar y controlar el desarrollo de productos
y software complejos usando prácticas iterativas y actualizables. Se trata de
evitar lo que como habı́amos hablado en clase, fácilmente nos va a pasar: Nuestro
proyecto se encuentra bastante avanzado nos damos cuenta de que no vamos por
el buen camino o, simplemente, el cliente decide introducir cambios sustanciales,
y esos cambios nos obligan a tirar por la borda todo el trabajo realizado hasta
entonces, y nos impiden acabar en el plazo previsto. Dado que los cambios
nunca van a dejar de existir, lo que necesitamos es ser capaces de gestionar los
proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses
Takeuchi y Nonaka estudiaron las prácticas de empresas con buenos resultados
de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson,
Brother, 3M o Hewlett-Packard. De ahı́ extrajeron la base de la metodologı́a
SCRUM que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta
consolidarse en campos de actividad muy diferentes. Seguro que puedes utilizar
algunas de sus técnicas y procedimientos para mejorar la gestión de los proyectos
en tu empresa. Estas son algunas de las claves de SCRUM:
7
Figure 4:
claro- QUÉ es lo que queremos hacer. Con esas historias de usuario construimos
la lista de requisitos del producto o ”product backlog”. A cada item de la lista se
le asigna una prioridad. El equipo tiene que estimar cuánto tiempo es necesario
para realizar cada una de las tareas.
• El product owner o dueño del producto, que representa la voz del cliente
y aporta la visión de negocio. Él se encarga de escribir las historias de
usuario, les da prioridad y las ubica en la lista de requisitos del producto.
8
• El ScrumMaster o facilitador, que tiene como principal papel el de dejar
el camino libre de obstáculos e impedimentos para que el resto del equipo
consiga el objetivo del sprint.
• El equipo, que tiene la responsabilidad de entregar el producto. Lo ideal es
que incluya entre 5 y 9 miembros, y que pertenezcan a diferentes disciplinas
(desarrolladores, diseñadores, etc.).
El papel de los ”pollos”, que no son actores esenciales pero sı́ están implicados
y deben ser tenidos en cuenta, lo juegan:
• Todos los roles son bienvenidos, pero sólo los ”cerdos” pueden hablar
• En la reunión se realizan las siguientes 3 preguntas clave: 1. £Qué has
hecho desde ayer? 2. £Qué tienes planeado hacer mañana? 3. £Has
encontrado algún problema para conseguir tu objetivo?
9
• Sprint Backlog: De la lista anterior, se toman las primeras funcionalidades,
se descomponen en tareas y son anotadas en esta lista. Estas tareas serán
realizadas en el siguiente mes.
Reglas Básicas:
• Una vez que se pasan las tareas más prioritarias del ”Product Backlog”
al ”Sprint Backlog”, estas no se pueden cambiar, esto quiere decir, que el
trabajo de un mes queda fijado. Esta es la regla más importante de todas.
• Al final del mes, este periodo se le llama ”Sprint”, se tiene que tener un
ejecutable con las funcionalidades del ”Sprint Backlog”.
• Todo el mundo puede añadir funcionalidades al ”Product Backlog”, pero
sólo una persona puede ordenarlo. A esta persona se le denomina ”Product
Owner”. Es el responsable del producto final.
3 RUP
3.1 Historia
El antecedente más importante se ubica en 1967 con la Metodologı́a Ericsson
(Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desar-
rollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre
los años de 1987 a 1995 Jacobson fundó la compañı́a Objectory AB y lanza el
proceso de desarrollo Objectory (abreviación de Object Factory).
Figure 5:
10
Posteriormente en 1995 Rational Software Corporation adquiere Objectory
AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir
de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML
como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James
Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para
expandir ROP, destacándose especialmente el flujo de trabajo conocido como
modelado del negocio. En junio del 1998 se lanza Rational Unified Process.
Figure 6:
Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcio-
nan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos
que son generados en las diferentes actividades del proceso de desarrollo.
11
La arquitectura involucra los aspectos estáticos y dinámicos más significa-
tivos del sistema, está relacionada con la toma de decisiones que indican cómo
tiene que ser construido el sistema y ayuda a determinar en qué orden. Además
la definición de la arquitectura debe tomar en consideración elementos de calidad
del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe
ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influen-
ciada por la plataforma software, sistema operativo, gestor de bases de datos,
protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de
estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso
se presta especial atención al establecimiento temprano de una buena arquitec-
tura que no se vea fuertemente impactada ante cambios posteriores durante la
construcción y el mantenimiento.
Cada producto tiene tanto una función como una forma. La función corre-
sponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona
la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura,
los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la
arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos,
actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos
de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de
software.
Aquı́ podemos ver la evolución de la arquitectura durante las fases de RUP.
Se tiene una arquitectura más robusta en las fases finales del proyecto. En las
fases iniciales lo que se hace es ir consolidando la arquitectura por medio de
baselines y se va modificando dependiendo de las necesidades del proyecto.
Figure 7:
12
durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como
una iteración (un recorrido más o menos completo a lo largo de todos los flujos
de trabajo fundamentales) del cual se obtiene un incremento que produce un
crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada como vemos a con-
tinuación. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,
Implementación y Pruebas), también existe una planificación de la iteración,
un análisis de la iteración y algunas actividades especı́ficas de la iteración. Al
finalizar se realiza una integración de los resultados con lo obtenido de las itera-
ciones anteriores.
Figure 8:
13
Figure 9:
14
• Eje vertical: Representa los aspectos estáticos del proceso. Describe el
proceso en términos de componentes de proceso, disciplinas, flujos de tra-
bajo, actividades, artefactos y roles.
Figure 10:
3.4.1 Inicio
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.
Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso
más esenciales (aproximadamente el 20Los objetivos en esta fase son:
• Establecer el ámbito del proyecto y sus lı́mites.
• Encontrar los Casos de Uso crı́ticos del sistema, los escenarios básicos que
definen la funcionalidad.
15
Figure 11:
3.4.2 Elaboración
El propósito de la fase de elaboración es analizar el dominio del problema,
establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y
eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe evolu-
cionar en iteraciones sucesivas hasta convertirse en el sistema final. Este pro-
totipo debe contener los Casos de Uso crı́ticos identificados en la fase de inicio.
También debe demostrarse que se han evitado los riesgos más graves. Los obje-
tivos en esta fase son:
• Definir, validar y cimentar la arquitectura.
• Completar la visión.
16
• Crear un plan fiable para la fase de construcción. Este plan puede evolu-
cionar en sucesivas iteraciones. Debe incluir los costes si procede.
• Demostrar que la arquitectura propuesta soportará la visión con un coste
razonable y en un tiempo razonable.
Los resultados deben ser:
• Un modelo de Casos de Uso completa al menos hasta el 80
• Requisitos adicionales que capturan los requisitos no funcionales y cualquier
requisito no asociado con un Caso de Uso especı́fico.
• Descripción de la arquitectura software.
• Un prototipo ejecutable de la arquitectura.
• Lista de riesgos y caso de negocio revisados.
• Plan de desarrollo para el proyecto.
• Un caso de desarrollo actualizado que especifica el proceso a seguir.
• Un manual de usuario preliminar (opcional).
3.4.3 Construcción
La finalidad principal de esta fase es alcanzar la capacidad operacional del pro-
ducto de forma incremental a través de las sucesivas iteraciones. Durante esta
fase todos los componentes, caracterı́sticas y requisitos deben ser implementa-
dos, integrados y probados en su totalidad, obteniendo una versión aceptable
del producto. Los objetivos en esta fase son:
• Minimizar los costes de desarrollo mediante la optimización de recursos y
evitando el tener que rehacer un trabajo o incluso desecharlo.
• Conseguir una calidad adecuada tan rápido como sea práctico.
• Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rápido como sea práctico.
Los resultados deben ser:
• Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Imple-
mentación)
• Arquitectura ı́ntegra (mantenida y mı́nimamente actualizada)
• Riesgos Presentados Mitigados
• Plan del Proyecto para la fase de Transición.
• Manual Inicial de Usuario (con suficiente detalle)
• Prototipo Operacional - beta
• Caso del Negocio Actualizado
17
3.4.4 Transición
La finalidad de la fase de transición es poner el producto en manos de los usuar-
ios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del
producto, completar la documentación, entrenar al usuario en el manejo del pro-
ducto, y en general tareas relacionadas con el ajuste, configuración, instalación
y facilidad de uso del producto. Los objetivos en esta fase son:
• Prototipo Operacional
• Documentos Legales
• Caso del Negocio Completo
• Lı́nea de 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.
4 Fuentes
• MarbleStation (http://www.marblestation.com/)
• IBM Best Practices (http://groups.google.com.pe/group/c-data-structure-
ucsp/files)
• Kruchten, P., The Rational Unified Process: An Introduction, 2000
• Geeks MS (http://geeks.ms/blogs/rcorral/)
• Consulta web a McV1c10us Moya (SCRUM) ( http://www.lavidaeninternet.net
)
18