Metodologias de desarrollo de software

Metodología Conjunto de procedimientos, técnicas, herramientas y un soporte documental que

ayuda a los desarrolladores a realizar nuevo software. Una metodología puede seguir uno o varios
modelos de ciclo de vida, es decir, el ciclo de vida indica qué es lo que hay que obtener a lo largo del
desarrollo del proyecto pero no cómo hacerlo. La metodología indica cómo hay que obtener los
distintos productos parciales y finales.

METODOLOGIA RATIONAL UNIFIED PROCESS RUP

Proceso Racional Unificado es un proceso de desarrollo de software y junto con el Lenguaje

Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías
adaptables al contexto y necesidades de cada organización. Originalmente se diseñó un proceso
genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational
Unified Process, que se vendiera como producto independiente.

Proceso de Desarrollo del Software

El RUP está basado en 6 procesos que son los siguientes:

Adaptar el proceso:

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con
él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o
las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en
cuenta el alcance del proyecto en un área subformal.

Equilibrar prioridades:

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse
recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este
equilibrio se podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente:

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración
se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección
del proyecto así como también los riesgos involucrados.

Colaboración entre equipos:

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una
comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción:

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software,
lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los
ingenieros de software vayan directamente de los requisitos a la codificación de software a la
medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los
requisitos y sin comenzar desde un principio pensando en la reutilización del código.

Enfocarse en la calidad:

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la
producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo
independiente.

Desarrollo de Componentes
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número
variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas
actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en
la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión
del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos
críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura. Durante la fase de
inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura,
abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño
y una parte de implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de
iteraciones.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se
procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se
realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición, se pretende garantizar que se tiene un producto preparado para su entrega
a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase
el esfuerzo dedicado a una disciplina varía.

Características de Campo
 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos
tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles
(papel que desempeña una persona en un determinado momento, una persona puede desempeñar
distintos roles a lo largo del proceso).

Documentación
Primer nivel de documentación:

Especifica en términos generales qué actividades deberán integrar el Sistema de Aseguramiento de

Calidad, que será implantado en la organización. Este nivel contiene los siguientes elementos:
• Declaración de Visión: Proyecciones de la administración sobre el lugar que ocupará la
organización en el futuro.
• Declaración de Misión: Compromiso de la administración para alcanzar la Visión.
• Política de Calidad: Posición de la organización, en cuanto a la manera en que la calidad afectará
la manera de cumplir con la Misión.
• Requerimientos de Calidad: Conjunto de actividades que la organización debe llevar a cabo, para
asegurar la calidad tanto del proceso como el producto que desarrolla
La Visión, Misión y Políticas de Calidad fueron desarrolladas a partir de los lineamientos estratégicos
del Departamento de Sistemas de Información.
El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000.

Segundo nivel de documentación:

Este nivel incluye especificaciones detalladas, orientadas a la administración, para explicar cómo se
llevarán a cabo las actividades que integran el Sistema de Aseguramiento de Calidad. Este nivel está
compuesto básicamente por procedimientos Administrativos, que son declaraciones de direcciones
sistemáticas, sobre cómo la organización debe llevar a cabo cada uno de los Requerimientos de
Calidad, definidos en el Primer Nivel de Documentación.

Tercer nivel de documentación:

Este nivel incluye especificaciones punto a punto, explícito y conciso para llevar a cabo cualquier
tarea en la organización. Está compuesto básicamente por Procedimientos de Operativos que
describen cada paso que se debe realizar para concretar una tarea o actividad; y Estándares que se
utilizan con el fin de registrar datos o información de algo específico. Estos procedimientos y
estándares han sido divididos en tres grupos:
1. Los relacionados con el desarrollo del curso Proyecto de Título.
2. Los relacionados con el desarrollo de producto de software.
3. Los que guían la implantación y mejoramiento del Sistema de Aseguramiento de Calidad.
Esta división facilita el uso y mantención del sistema. Por ejemplo, si hay cambios en las normas
administrativas que afecten el desarrollo de los cursos en general, entonces sólo se verán afectados
los procedimientos y estándares relacionados con el desarrollo del proyecto.

Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de
artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre
otros). Estos artefactos (entre otros) son los siguientes:

Inicio:
 Documento Visión
 Especificación de Requisitos
Elaboración:
 Diagramas de caso de uso
Construcción:

 Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica
 Diagrama de clases
 Modelo E-R (Si el sistema así lo requiere)
Vista de Implementación
 Diagrama de Secuencia
 Diagrama de estados
 Diagrama de Colaboración
Vista Conceptual
 Modelo de dominio
Vista física
 Mapa de comportamiento a nivel de hardware.

Programación extrema (XP)

La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de
la ingeniería de softwareformulada por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de
los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se
diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo
de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto
de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los
requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los
requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías

de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de
manera dinámica durante el ciclo de vida del software.

Características fundamentales
Las características fundamentales del método son:

 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

 Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la
codificación. Véase, por ejemplo, las herramientas de prueba JUnitorientada a Java, DUnit
orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas
inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a
realizar tests, realizado para el lenguaje de programación Smalltalk.

 Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por
dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el
código es revisado y discutido mientras se escribe- es más importante que la posible pérdida
de productividad inmediata.

 Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda

que un representante del cliente trabaje junto al equipo de desarrollo.

 Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas
frecuentes.

 Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su
legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de
garantizar que en la refactorización no se ha introducido ningún fallo.

 Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de

cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal
 pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión
garantizan que los posibles errores serán detectados.

 Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta
que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se
requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más

comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más
simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación
más completa, especialmente si se puede reducir el equipo de programadores.

Roles
Programador

Escribe las pruebas unitarias y produce el código del sistema.

Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementación.
Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración
centrándose en aportar el mayor valor de negocio.

Tester
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los
resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

Tracker
Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado
de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los
resultados para mejorar futuras estimaciones.

Entrenador (coach)
Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso
correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento específico en algún tema necesario
para el proyecto. Ayuda al equipo a resolver un problema específico.

Gestor (Big boss)

Es el dueño de la tienda y el vinculo entre clientes y programadores. Su labor esencial es la
coordinación.

Metodología rad
El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es
un proceso de desarrollo de software, desarrollado inicialmente por James Martin en1980. El método
comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE
(Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones
tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales
como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas
son Visual Studio, Lazarus, Gambas, Delphi,Foxpro , Anjuta, Game Maker, Velneo o Clarion. En el
área de la autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder
proveen plataformas de desarrollo rápido de aplicaciones, dentro de ciertos límites.

FASES DEL RAD

  Modelado de gestión: el flujo de información entre las funciones de gestión se
modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el
proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la
información? ¿Quién la proceso?
 Modelado de datos: el flujo de información definido como parte de la fase de
modelado de gestión se refina como un conjunto de objetos de datos necesarios para
apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de
los objetos y las relaciones entre estos objetos.
 Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de información necesario para implementar
una función de gestión. Las descripciones del proceso se crean para añadir, modificar,
suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
 Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta
generación. En lugar de crear software con lenguajes de programación de tercera
generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya
existentes (cuando es posible) o a crear componentes reutilizables (cuando sea
necesario). En todos los casos se utilizan herramientas automáticas para facilitar la
construcción del software.
 Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo de
pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben
ejercitar todas las interfaces a fondo.

CARACTERÍSTICAS DE RAD
Equipos Híbridos

 Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y

usuarios de tiempo completo del sistema así como aquellas personas involucradas con
los requisitos.
 Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y
programadores en uno.

Herramientas Especializadas

 Desarrollo "visual"
 Creación de prototipos falsos (simulación pura)
 Creación de prototipos funcionales
 Múltiples lenguajes
 Calendario grupal
 Herramientas colaborativas y de trabajo en equipo
 Componentes reusables
 Interfaces estándares (API)

"Timeboxing"

 Las funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.
Prototipos Iterativos y Evolucionarios.

 Reunión JAD (Joint Application Development):

 Se reunen los usuarios finales y los desarrolladores.
 Lluvia de ideas para obtener un borrador inicial de los requisitos.
 Iterar hasta acabar:
 Los desarrolladores construyen y depuran el prototipo basado en los requisitos
actuales.
 Los diseñadores revisan el prototipo.
 Los clientes prueban el prototipo, depuran los requisitos.
 Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar
los requisitos y generar solicitudes de cambios.
 Los cambios para los que no hay tiempo no se realizan. Los requisitos
secundarios se eliminan si es necesario para cumplir el calendario.

VENTAJAS

1. Comprar puede ahorrar dinero en comparación con construir.

2. Los entregables pueden ser fácilmente trasladados a otra plataforma.
3. El desarrollo se realiza a un nivel de abstracción mayor.
4. Visibilidad temprana.
5. Mayor flexibilidad.
6. Menor codificación manual.
7. Mayor involucramiento de los usuarios.
8. Posiblemente menos fallas.
9. Posiblemente menor costo.
10. Ciclos de desarrollo más pequeños.
11. Interfaz gráfica estándar.

DESVENTAJAS

1. Comprar puede ser más caro que construir.

2. Costo de herramientas integradas y equipo necesario.
3. Progreso más difícil de medir.
4. Menos eficiente.
5. Menor precisión científica.
6. Riesgo de revertirse a las prácticas sin control de antaño.
7. Más fallas (por síndrome de “codificar a lo bestia”).
8. Prototipos pueden no escalar, un problema mayúsculo.
9. Funciones reducidas (por “timeboxing”).
10. Dependencia en componentes de terceros: funcionalidad de más o de menos,
problemas legales.
 Scrum
Scrum es un modelo de desarrollo ágil caracterizado por:

 Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución

completa del producto.
 Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos
autoorganizados, que en la calidad de los procesos empleados.
 Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en
un ciclo secuencial o de cascada.

Proceso y Roles de Scrum

El proceso

El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada Sprint, tiene
una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del
software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la
funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que
aporten mayor valor de negocio.

 Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no

técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión
 considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso
del proyecto a intervalos regulares.
 Sprint Planning: Reunión durante la cual el Product Owner presenta las historias del backlog por
orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a
completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a
conseguir.
 Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir
lashistorias del Product Backlog a las que se ha comprometido, en una nueva versión del software
totalmente operativo.
 Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.
 Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza
para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y
si hay impedimentos.
 Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las
historias conseguidas mediante una demonstración del producto. Posteriormente, en la
retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de
cómo perfeccionarlos.

Roles

En Scrum, el equipo se focaliza en construir software de calidad. La gestión de un proyecto Scrum se

centra en definir cuáles son las características que debe tener el producto a construir (qué construir,
qué no y en qué orden) y en vencer cualquier obstáculo que pudiera entorpecer la tarea del equipo
de desarrollo.
El equipo Scrum está formado por los siguientes roles:
 Scrum master: Persona que lidera al equipo
guiándolo para que cumpla las reglas y procesos
de la metodología. Gestiona la reducción de
impedimentos del proyecto y trabaja con
el Product Owner para maximizar el ROI.
 Product owner (PO): Representante de lso
accionistas y clientes que usan el software. Se
focaliza en la parte de negocio y el es
responsable del ROI del proyecto (entregar un
valor superior al dinero invertido). Traslada la
visión del proyecto al equipo, formaliza las
prestaciones en historias a incorporar en
el Product Backlog y las reprioriza de forma
regular.
 Team: Grupo de profesionales con los
conocimientos técnicos necesarios y que
desarrollan el proyecto de manera conjunta
llevando a cabo las historiasa las que se
comprometen al inicio de cada sprint.