Metodologas de desarrollo de Software

Ingeniera de software
Ingeniera del Software es el estudio de los principios y metodologas
para el desarrollo y mantenimiento de sistemas de software (Zelkovitz,
1978)

Ingeniera del Software es la aplicacin prctica del conocimiento
cientfico al diseo y construccin de programas de computadora y a la
documentacin asociada requerida para desarrollar, operar (funcionar)
y mantenerlos. Se conoce tambin como desarrollo de software o
produccin de software (Bohem, 1976)

Ingeniera del Software trata del establecimiento de los principios y
mtodos de la ingeniera a fin de obtener software de modo rentable
que sea fiable y trabaje en mquinas reales (Bauer, 1972)

La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al
desarrollo, operacin (funcionamiento) y mantenimiento del software;
es decir, la aplicacin de ingeniera al software. (IEEE, 1993)

El desarrollo de software no es una tarea
fcil. Prueba de ello es que existen
numerosas propuestas metodolgicas que
inciden en distintas dimensiones del
proceso de desarrollo.
Metodologa de Desarrollo de
Software
Una metodologa para el desarrollo de software
comprende los procesos a seguir sistemticamente
para idear, implementar y mantener un producto
software desde que surge la necesidad del producto
hasta que cumplimos el objetivo por el cual fue creado

Las metodologas son marcos de trabajo (frameworks)
para planificar y gestionar el desarrollo de un
desarrollo de software las cuales combinan ciclos de
vida con tecnologas y herramientas.
VENTAJAS DEL USO DE UNA
METODOLOGA

Desde el punto de vista de gestin:
Facilitar la tarea de planificacin
Facilitar la tarea del control y seguimiento de un proyecto
Mejorar la relacin coste/beneficio
Optimizar el uso de recursos disponibles
Facilitar la evaluacin de resultados y cumplimiento de los objetivos
Facilitar la comunicacin efectiva entre usuarios y desarrolladores

Desde el punto de vista de los ingenieros del software:
Ayudar a la comprensin del problema
Optimizar el conjunto y cada una de las fases del proceso de desarrollo
Facilitar el mantenimiento del producto final
Permitir la reutilizacin de partes del producto

Desde el punto de vista del cliente o usuario:
Garanta de un determinado nivel de calidad en el producto final
Confianza en los plazos de tiempo fijados en la definicin del proyecto
Definir el ciclo de vida que ms se adecue a las condiciones y
caractersticas del desarrollo

Segn la filosofa de desarrollo se
pueden clasificar las metodologas en
dos grupos
Metodologas tradicionales

Metodologas giles
Metodologas tradicionales

Centran su atencin en llevar una documentacin
exhaustiva de todo el proyecto y en cumplir con un plan de
proyecto, definido todo esto, en la fase inicial del desarrollo
del proyecto.

Se focalizan en la documentacin, planificacin y procesos
(plantillas, tcnicas de administracin, revisiones, etc.)

Metodologas giles Metodologas tradicionales
Basadas en heursticas provenientes de prcticas de
produccin de cdigo
Basadas en normas provenientes de estndares
seguidos por el entorno de desarrollo
Especialmente preparados para cambios durante el
proyecto
Se espera que no ocurran cambios de gran impacto
durante el proyecto
Impuestas Internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos principio Proceso mucho ms controlado, con numerosas
polticas/normas
No existe contrato tradicional o al menos es bastante
flexible
Existe un contrato prefijado
El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de desarrollo
mediante reuniones
Grupos pequeos (<10 integrantes) y trabajando en
el mismo sitio
Grupos grandes y posiblemente distribuidos
Pocos artefactos Ms artefactos
Pocos roles Ms roles
La arquitectura se va definiendo y mejorando a lo
largo del proyecto
Se promueve que la arquitectura se defina
tempranamente en el proyecto
RUP (Rational Unified Procces)
MSF (Microsoft Solution Framework)
Win-Win Spiral Model
Iconix
Ejemplos de Metodologas
Tradicionales:
RUP (Rational Unified
Procces)
Es una de las metodologas pesadas ms conocidas y
utilizadas, es un marco de desarrollo de software que se
caracteriza por estar dirigido por casos de uso, centrado en la
arquitectura y por ser iterativo e incremental.
Divide el desarrollo en 4 etapas
Inicio : El objetivo es determinar la visin del proyecto y defi
nir lo que se desea realizar.

Elaboracin: Etapa en la que se determina la arquitectura
ptima del proyecto.

Construccin: Se obtiene la capacidad operacional inicial.

Transmisin : Obtener el producto acabado y definido.
La metodologa RUP tiene 6 pri
ncipios clave:
Adaptacin del proceso : El proceso debe adaptarse a las caractersticas d
e la organizacin para la que se esta desarrollando el software.

Balancear prioridades : Debe encontrarse un balance que satisfaga a todos los inver
sores del proyecto.

Colaboracin entre equipos : Debe haber una comunicacin fluida para coordinar r
equerimientos, desarrollo, evaluaciones, planes, resultados.

Demostrar valor iterativamente : Los proyectos se entregan, aunque sea de una for
ma interna, en etapas iteradas. En cada iteracin se evaluar la calidad y estabilidad d
el producto y analizar la opinin y sugerencias de los inversores.

Elevar el nivel de abstraccin : Motivar el uso de de conceptos reutilizables.

Enfocarse en la calidad : La calidad del producto debe verificarse en cada aspecto d
e la produccin.

Disciplina de desarrollo de RUP

Ingeniera o modelado del negocio: Analizar y entender las necesidades d
el negocio para el cual se est desarrollando el software.

Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sist
ema.

Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema au
tomatizado y desarrollar una arquitectura para el sistema.

Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga
el comportamiento deseado.

Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo
solicitado est presente.

Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.
Diagrama del esfuerzo de actividades segn
la etapa del proyecto
Los elementos del RUP
son:
Actividades: Procesos que se han de rea
lizar en cada etapa/iteracin.
Trabajadores: Personas involucradas en
cada actividad del proyecto.
Artefactos: Herramientas empleadas pa
ra el desarrollo del proyecto. Puede ser un
documento, un modelo, un elemento del
modelo, etc.,...
Metodologas giles
Entre las metodologas giles ms destacadas hasta el momento se pueden nombrar:

XP (Extreme Programming)

Scrum

Crystal Clear

DSDM (Dynamic Systems Developmemt Method)

FDD (Feature Driven Development)

ASD (Adaptive Software Development)

XBreed

Extreme Modeling
XP (eXtreme Programming)
Es el ms destacado y popular de los procesos giles de desarrollo de
software.

Se centra en potenciar las relaciones interpersonales como clave para
el xito en desarrollo de software.

Promueve el trabajo en equipo, preocupndose por el aprendizaje de
los desarrolladores, y propiciando un buen clima de trabajo.

XP se basa en realimentacin continua entre el cliente y el equipo de
desarrollo, comunicacin fluida entre todos los participantes,
simplicidad en las soluciones implementadas y coraje para enfrentar
los cambios.

XP se define como especialmente adecuada para proyectos con
requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo
tcnico.
Las historias de usuario
Las historias de usuario son la tcnica
utilizada en XP para especificar los
requisitos del software. Se trata de
tarjetas de papel en las cuales el cliente
describe brevemente las caractersticas
que el sistema debe poseer, sean
requisitos funcionales o no funcionales.
Roles de XP
Programador.-El programador escribe las pruebas unitarias y produce el cdigo del sistema.

Cliente.- El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementacin.

Encargado de pruebas (Tester).- El encargado de pruebas ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente, difunde los resultados.

Encargado de seguimiento (Tracker).- El encargado de seguimiento proporciona retroalimentacin
al equipo en el proceso XP.

Entrenador (Coach).- Es responsable del proceso global. Es necesario que conozca a fondo el
proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP.

Consultor.- Es un miembro externo del equipo con un conocimiento especfico en algn tema
necesario para el proyecto. Gua al equipo para resolver un problema especfico.

Gestor (Big boss).- Es el vnculo entre clientes y programadores,
ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial
es de coordinacin.

El ciclo de vida ideal de XP
consiste de seis fases:
Exploracin
Planificacin de la Entrega (Release)
Iteraciones
Produccin
Mantenimiento
Muerte del Proyecto
PRCTICAS XP

El juego de la planificacin
Entregas pequeas
Metfora
Diseo simple
Pruebas
Refactoring



Programacin en parejas
Propiedad colectiva
Integracin contnua
Semana de 40 horas
Cliente in situ
Estndares de programacin
Metodologa SCRUM
Es una metodologa, framework o filosofa que permite definir
un proceso propio para el desarrollo de nuevos productos en
lneas generales.

Los valores que promulga son:
Empowerment (delegar y hacer sentir dueos de su trabajo) y
compromiso con las personas.
Transparencia y visibilidad del proyecto.
Coraje y responsabilidad

Se basa en:
Empirismo.
Auto-organizacin.
Colaboracin.
Priorizacin.
Compromiso con los tiempos (time-boxing).

SCRUM
Se trata de un modelo iterativo e
incremental dividido en sprints. Cada
sprint se centrar en unos requisitos
concretos (user stories) y tendr una
duracin entre una y cuatro semanas.

Cada sprint recoge las fases de
desarrollo de software comunes:
anlisis, diseo, programacin y
pruebas. Mediante esta metodologa se
van finalizando los requisitos sencillos
(incremental) y se van perfeccionando
aquellos complejos (iterativo). En el
caso del cuadro de la Figura 5, aquellas
partes sencillas del cuadro las puedo
terminar en un sprint.

Documentos esenciales:

Product Backlog: se describen de forma
reducida todos los requerimientos (user
stories) priorizados y con una
estimacin de tiempos. Tambin se
muestra informacin global del
desarrollo. La gestin del Product
Backlog se puede llevar a cabo
mediante una simple hoja de clculo o a
travs de herramientas software ms
completas.
Ejemplo de Product Backlog
Sprint Backlog
Documento detallado de los
requerimientos (user stories) de cada
sprint.
User Stories

Los requisitos o los casos de uso en UML, describen de forma muy breve la funcionalidad o
capacidades del sistema desde el punto de vista del usuario. Deben ser independientes e indicar:
Quin es el usuario que se beneficia?
Qu accin lleva a cabo?
Cul es el beneficio?

Siempre se redactan segn la siguiente plantilla:
As a <type of user>, I want <some goal> so that <some reason>.

Como profesor, quiero listar los alumnos con nota superior a 6 para saber quin libera el examen

El equipo de proyecto debe decidir la descomposicin de la historia de usuario en tareas, estimando
la duracin de cada una de ellas y la asignacin a los miembros del equipo.
Scrum Board

Se recomienda realizar un seguimiento
del Product Backlog y sobe todo, del
Sprint Backlog mediante un tablero
fsico. Aunque existen un gran nmero
de herramientas software que permiten
llevar esta gestin mediante el
ordenador, es conveniente tener nuestro
tablero ya que ser nuestro lugar donde
se celebrarn las reuniones diarias.
Roles Principales

Product Owner. representa la voz del cliente. El
Product Owner escribe historias de usuario, las
prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador) . El ScrumMaster no es
el lder del equipo (porque ellos se auto-organizan),
sino que acta como una proteccin entre el equipo
y cualquier influencia que le distraiga. El
ScrumMaster se asegura de que el proceso Scrum
se utiliza como es debido.

Equipo de desarrollo. El equipo tiene la
responsabilidad de entregar el producto.

Daily Scrum o Stand-up
meeting

Cada da de un sprint, se realiza la reunin sobre el estado de un
proyecto. Esto se llama daily standup o Stand-up meeting.

El scrum tiene unas guas especficas:
La reunin comienza puntualmente a su hora.
Todos son bienvenidos, pero slo los involucrados en el proyecto
pueden hablar.
La reunin tiene una duracin fija de 15 minutos, de forma
independiente del tamao del equipo.
La reunin debe ocurrir en la misma ubicacin y a la misma hora todos
los das.

Durante la reunin, cada miembro del equipo contesta a tres preguntas:
3

Qu has hecho desde ayer?
Qu es lo que hars hasta la reunin de maana?
Has tenido algn problema que te haya impedido alcanzar tu
objetivo?
(Es el papel del ScrumMaster recordar estos impedimentos).

QUIN USA SCRUM?

Microsoft, Sun, Sammy Studios, Siemens,
CNA, State Farm, State Street Bank,
Philips, BBC, IBM, SAIC, LMCO, APL,
Ariba, Federal Reserve Bank, HP,
Motorola, Nokia, TransUnion, IDX,
Siemens Medical, Gestalt, Yahoo,
Conchango, BMC, Lexis-Nexis, Bently
Systems, Bose, CapitalOne,Federal
Reserve Bank, ClearChannel, Xerox,
Patient Keeper, British Telecom, PayPal,