Sie sind auf Seite 1von 13

1

INDICE

1. METODOLOGIAS AGILES .......................................................................... 2
1.1. Definicin .............................................................................................. 2
1.2. El Manifiesto Agil ................................................................................... 2
1.3. Principios ............................................................................................... 3
1.4. Diferencias Entre Metodologias Agiles Y Metodologias Tradicionales .. 5
1.5. Algunas Metodologias Agiles En El Desarrollo De Software ................. 6
2. INGENIERA DE REQUERIMIENTOS......................................................... 8
2.1. Definicion .............................................................................................. 8
2.2. Caracteristicas ...................................................................................... 9
2.3. Tipos ...................................................... Error! Bookmark not defined.
2.4. El Proceso De La Ingeniera De RequisitosError! Bookmark not
defined.
2.5. Fases De Implementacin ...................... Error! Bookmark not defined.
2.6. Herramientas Y Tcnicas De La Ingeniera De Requerimientos ......... 10
2.7. Especificacin De Requisitos Del Software ......................................... 11
2.8. Ventajas Y Desventajas De La Ingeniera De Requisitos.................... 11













2





1. METODOLOGIAS AGILES

1.1. DEFINICIN

Es un mtodo de ingeniera del software basado principalmente en el desarrollo
iterativo e incremental, donde los requerimientos y soluciones evolucionan
mediante la colaboracin de los grupos de equipos autos dirigidos y
multidisciplinarios.
En una reunin celebrada en Utah-EEUU, en el mes de febrero de 2001, nace
el trmino gil el cual es aplicado al desarrollo de software. En dicha reunin
participaron expertos en la industria del software incluyendo as a uno de los
creadores o impulsores de la metodologa de software. El objetivo ante todo era
el de esbozar los valores y principios que deberan permitir a los equipos el
desarrollo de los software de manera rpida y la misma vez respondiendo a los
cambios que puedan presentarse a lo largo del proyecto.
De esta manera se pretenda dar una alternativa a los procesos de desarrollo
de software tradicionales, los cuales son rgidos y son dirigidos por la
documentacin que se genera en cada una de las actividades desarrolladas.

1.2. EL MANIFIESTO AGIL

Tras una reunin se crea THE AGILE ALLIANCE dicha organizacin estaba
dedicada a promover los conceptos relacionados con el desarrollo gil de
software y ayudar a las organizaciones para adopten dichos conceptos. El cual
parte con un documento q resume la filosofa gil, el manifiesto gil se toma
como valoracin:

3

Al individuo y las interacciones del equipo de desarrollo sobre el proceso
y las herramientas.

o Construir un buen equipo antes q el entorno, de tal manera el
equipo configurar su propio entorno de desarrollo en base a sus
necesidades.

El desarrollar software que funciona ms que conseguir una buena
documentacin

o El no producir documentos a menos que sean necesarios de
forma inmediata para tomar una decisin importante, es una de
las reglas a seguir. Aparte dichos documentos debern ser cortos
y solo centrarse en lo fundamental.

La colaboracin con el cliente ms que la negociacin de un contrato

o El que exista una interaccin constante entre el cliente y el equipo
de desarrollo, con dicha colaboracin el proyecto marchar bien y
alcanzar el xito de ste.

Responder a los cambios ms que seguir estrictamente un plan

o La planificacin no debe ser estricta sino flexible y abierta, de esta
manera se responder a los cambios que puedan surgir a largo
del proyecto, ya sean en los cambios de requisitos, de tecnologa
o de equipo, etc., de esta determinar el xito o bien el fracaso
del mismo.

1.3. PRINCIPIOS

4

Los dos primeros principios son generales, resumiendo el espritu gil, el
resto tiene q ver con el proceso a seguir y con el equipo de desarrollo,
en base a metas a seguir y la organizacin del mismo.

1er principio:
Nuestra prioridad principal es satisfacer al cliente atreves de entregas de
software valiosos, de forma temprana y continua.

2do principio:
Los cambios a los requisitos son bienvenidos, aun as sean tardos. Los
procesos agiles aprovechan el cambio para otorgar una ventaja al
cliente.

3er principio:
Enviar software operativo frecuentemente, en un periodo entre dos
semanas y dos meses, con frecuencia a escalas de tiempo ms cortos.

4to principio:
La gente del negocio y los desarrolladores deben trabajar juntos a los
largo del proyecto.

5to principio:
Ejecutar proyectos con personar motivadas. Brindar el ambiente y
soporte que ellos necesitan, y la confianza de que ellos podrn realizar
el trabajo requerido.


6to principio:
El mtodo ms eficiente y efectivo para transmitir la informacin hacia el
equipo son las conversaciones cara a cara.

7mo principio:
El software operativo es la principal medicin del avance.

5

8vo principio:
Los procesos agiles promueven el desarrollo sostenible. Los
patrocinadores desarrolladores y usuarios deben ser capaces de
mantener el paso constante indefinidamente.

9no principio:
Una continua atencin hacia un buen diseo y la excelencia tcnica
mejora la agilidad.

10mo principio:
La simplicidad, el arte de maximizar la cantidad de trabajo no hecho, es
esencial.

11vo principio:
Las mejores arquitecturas, requisitos, y de diseo emergen de equipos
auto dirigidos.

12vo principio:
En intervalos regulares, el equipo refleja cmo trabaja de forma ms
efectiva, entonces afina y ajusta su comportamiento adecuadamente.

1.4. DIFERENCIAS ENTRE METODOLOGIAS AGILES Y
METODOLOGIAS TRADICIONALES

METODOLOGIA AGILES METODOLOGIAS TRADICIONALES
Basadas en heursticas provenientes
de prcticas de produccin de
cdigo.
Basadas en normas provenientes de
estndares seguidos por el entorno
de desarrollo.
Son preparados especialmente para
cambios durante el proyecto.
Cierta resistencia a los cambios
Impuestas internamente(por el
equipo)
Impuestas externamente
Proceso menos contralado, con
pocos principios.
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 El cliente interacta con el equipo de
6

desarrollo desarrollo mediante reuniones.
Grupos pequeos (<10 integrantes)
y trabajando en el mismo sitio
Grupos grandes y posiblemente
distribuidos
Pocos artefactos Mas artefactos
Pocos roles Mas roles
Menos nfasis en la arquitectura del
software
La arquitectura del software es
esencial y se expresa mediante
modelos.

Dichas diferencias no solo afectan al proceso en s, sino tambin al contexto
del equipo as como a su organizacin.

1.5. ALGUNAS METODOLOGIAS AGILES EN EL DESARROLLO DE
SOFTWARE

LA PROGRAMACION EXTREMA (XP): Se caracteriza por que pone
ms nfasis en la adaptabilidad que en la previsibilidad. Se adapta a los
cambios de requisitos en cualquier punto de la vida del proyecto
considerndose una aproximacin mejor y ms realista que el intentar
definir todos los requisitos al comienzo del proyecto e invertir esfuerzos
despus en controlar los cambios en los requisitos. Sus caractersticas
fundamentales son:

Desarrollo iterativo e incremental
Pruebas unitarias continuas
Programacin en parejas
Frecuente integracin del equipo de programacin con el cliente
Correccin de todos los datos antes de aadir nueva
funcionalidad
Refactorizacin del cdigo
Propiedad del cdigo compartida
Simplicidad en el cdigo

SCRUM: Desarrollada por Ken Schwaber, Jeff Sutherland y Mike
Beedle, este tipo de metodologa es especialmente para proyectos con
un rpido cambio de requisitos, se caracteriza por lo siguiente:
7


El desarrollo del software se realiza por medio de iteraciones,
denominadas Sprints cuya duracin es de 30 das, el resultado
de cada Sprint fue en incremento ejecutable que se muestra al
cliente.
La realizacin de reuniones a lo largo del proyecto, q puede ser
diaria de 15 min. Del equipo de desarrollo para la debida
coordinacin e integracin.

CRYSTAL METHODOLOGIES: conjunto de metodologas para el
desarrollo de software, la cual est caracterizada por estar centradas en
las personas que componen el equipo y la reduccin del mximo nmero
de artefactos producidos.

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM): es un
proceso iterativo e incremental y el equipo de trabajo con el usuario
trabajan juntos. Propone cinco fases:

Estudio Viabilidad
Estudio Del Negocio
Modelo Funcional
Diseo Y Construccin
Implementacin

ADAPTIVE SOFTWARE DEVELOPMENT: Es iterativo, orientado a los
componentes software ms que a las tareas y tolerante a los cambios. El
ciclo de vida propone tres fases: especulacin (se inicia el proyecto y se
planifican las caractersticas del software), colaboracin (desarrollo de
las caractersticas), aprendizaje (se reviza la calidad) y se entrega al
cliente. Su impulsor es Jim Highsmith.

FEATURE-DRIVE DEVELOPMENT (FDD): Es de proceso iterativo,
dichas iteraciones son cortas (hasta 2 semanas), se centra en la fase de
diseo e implementacin del sistema, la cual parte de una lista de
8

caractersticas que debe reunir el software. Sus impulsores son Jeff De
Luca y Peter Coad.

LEAN DEVELOPMENT (LD): Fue definida por Bob Charettes, los
cambios se consideran riesgos, pero al manejarlo adecuadamente se
puede convertir en oportunidades que mejoran la productividad del
cliente. Su caracterstica principal es introducir un mecanismo para
implementar dichos cambios.

2. INGENIERA DE REQUERIMIENTOS

2.1. DEFINICION

Es el proceso de descubrir, analizar, documentar y verificar los
requisitos del software. Es decir un proceso de descubrimiento, refinamiento,
modelado y especificacin, comprende todas las tareas relacionadas con la
determinacin de las necesidades o de las condiciones a satisfacer para un
software nuevo o modificado, tomando en cuenta los diversos requisitos de los
inversores, que pueden entrar en conflicto entre ellos.
El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un
estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los
buenos requisitos deben ser medibles, comprobables, sin ambigedades o
contradicciones, etc.
De dnde provienen los requerimientos?






9





2.2. CARACTERISTICAS DE LOS REQUERIMIENTONS

Necesario: Un requerimiento es necesario si su omisin provoca una
deficiencia en el sistema a construir, y adems su capacidad,
caractersticas fsicas o factor de calidad no pueden ser reemplazados
por otras capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fcil de leer y entender.
Su redaccin debe ser simple y clara para aquellos que vayan a
consultarlo en un futuro.

Completo: Un requerimiento est completo si no necesita ampliar
detalles en su redaccin, es decir, si se proporciona
la informacin suficiente para su comprensin.

Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.


No ambiguo: Un requerimiento no es ambiguo cuando tiene una
sola interpretacin. El lenguaje usado en su definicin, no debe causar
confusiones al lector.

Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de los
siguientes mtodos de verificacin: inspeccin, anlisis, demostracin
o pruebas.


2.3. DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS

o Los requerimientos no son obvios y vienen de muchas fuentes.
o Son difciles de expresar en palabras (el lenguaje es ambiguo).
o Existen muchos tipos de requerimientos y diferentes niveles de detalle.
o La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
10

o Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms
importantes o ms estables que otros.
o Los requerimientos estn relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
o Cada requerimiento tiene propiedades nicas y abarcan reas funcionales
especficas.
o Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
o Son difciles de cuantificar, ya que cada conjunto de requerimientos es
particular para cada proyecto.




2.4. PROCESO DE LA INGENIERA DE REQUERIMIENTOS



2.4.1. Estudio de viabilidad: Este permitir rendir un informe tanto al
equipo de desarrollo del proyecto como al usuario o cliente,
donde se verificar si el proyecto vale la pena desarrollarlo. Es de
vital importancia para la satisfaccin de los objetivos del negocio.

2.4.2. Captura y Anlisis: En esta fase el desarrollador o su equipo de
desarrollo entran en contacto con el usuario final o con el cliente
para determinar el alcance del proyecto o del sistema que se
desea construir, adems, se debe identificar cules son los
servicios que prestar el sistema, su rendimiento, sus
necesidades y restricciones, y cules son los objetivos esperados.

2.4.3. Especificacin: Aqu se debe obtener un documento de
especificacin de requisitos, en cual se llega a definir de una
forma completa, precisa y verificable cada uno de los
requerimientos o necesidades que debe satisfacer el sistema a
11

desarrollar, adems de sus respectivas restricciones (software,
hardware).

2.4.4. Validacin: Consiste en mostrar o comprobar que cada uno de
los requisitos obtenidos definen el sistema o proyecto que se va a
construir y que desea el cliente. En esta etapa solamente entran
aquellos requisitos que se mencionaron ya en la especificacin.

2.4.5. Gestin: Se realiza la comprensin y control de los cambios de
cada una de los requisitos, sean estos requisitos estables
(corresponden al estado del sistema) o voltiles (representan
eventos que hacen que el sistema realice una funcin dada)



2.5. ESPECIFICACIN DE REQUISITOS DEL SOFTWARE

Implica una descripcin completa del comportamiento del sistema a desarrollar,
incluye conjuntos de casos de uso que describen todas las interacciones que
prevn que los usuarios tendrn con el software.
Los requisitos se dividen en tres:
Funcionales:
Son los que el usuario necesita que efecte el software. Normalmente se
identifican como los requisitos que responden a la pregunta qu hace?. El
sistema debe emitir un comprobante al asentar la entrega de mercadera.
No funcionales:
Son los "recursos" para que trabaje el sistema de informacin (redes,
tecnologa). Ej: el soporte de almacenamiento a usar debe ser MySQL
Empresariales u Organizacionales:
Son el marco contextual en el cual se implantar el sistema para conseguir
un objetivo macro.

12

2.6. VENTAJAS Y DESVENTAJAS DE LA INGENIERA DE
REQUERIMIENTO

VENTAJAS
- Mediante ellas se obtiene gran cantidad de informacin a travs del
usuario.
- Pueden ser usadas para obtener una visin general del dominio del
problema.
- Son bastante flexibles.
- Permiten combinarse con otras tcnicas.
- La produccin de ideas en grupos puede ser ms efectiva que la
individual.
- Aflora una gran cantidad de ideas sin ataduras.
DESVENTAJAS
- La informacin obtenida al principio puede ser redundante o incompleta.
- Si el volumen de informacin manejado es alto, requiere mucha
organizacin de parte del analista, as como la habilidad para tratar y
comprender el comportamiento de todos los involucrados.
- En sistemas grandes toma mucho tiempo definir todos los casos de uso.
- El anlisis de calidad depende de la calidad con que se haya hecho la
descripcin inicial.
















13




















CONCLUSIONES

Las metodologas agiles nos permiten trabajar con tcnicas y
herramientas que nos resulten convenientes para cada caso de
desarrollo de software.

La ingeniera de requisitos es muy importante en el desarrollo de
software, para evitar la disconformidad en la obtencin de
requerimientos.

Das könnte Ihnen auch gefallen