Trabajo de Investigación de Angy Metodologia de Desarrollo de Software Corregido

Ao de la Consolidacin del Mar de Grau
Metodologa de
desarrollo de software
CURSO:
METODOLOGA DE DESARROLLO DE SOFTWARE.

CATEDRTICO:
Lic. Kevin Vladimir ESPINOZA LPEZ.
ESTUDIANTE:
YAPIAS AVILEZ Angy Ivett.
CICLO:
III
SECCIN:
Junn Per
2016
21
INTRODUCCIN
El desarrollo del software puede ser un tema bastante complejo
si as lo
queremos,
este da vamos
tratar
de
reducir
esta
como
una
complejidad a algo comprensible en unas lneas.

Al
momento
de
definir
software podramos verlo
herramienta que nos sirve para agilizar nuestro trabajo, en los juegos
que usamos en Facebook, las aplicaciones de nuestro, todo lo que
usamos en la computadora fue creado por un equipo de desarrollo,
pequeo, grande, distribuido o local, pero la pregunta que nos
plantearemos es: Que hay detrs de este herramienta, como se
construyo
esta aplicacin Es
trabajo detrs de
claro
cada botn, detrs de
que
hay
un
gran
cada informacin que
mandamos a guardar.
Como todo proyecto el software tiene un ciclo para desarrollarse y
consta de una serie de pasos que se van completando en diferente
tiempo; este ciclo de desarrollo de software depende directamente de
la metodologa.
Utilizando este desarrollo, y no es ms que una serie de pasos tareas
que tenemos que seguir como en cualquier otro proyecto, no hay
nada escondido, nada mgico excepto la gran mente del equipo de
desarrollo y las creaciones para tener una experiencia nica al utilizar
la aplicacin o el paquete de software.
Antes
de
entrar
en
mas
detalle,
debemos
mencionar
que
las metodologas para el desarrollo del software es independiente de

la tecnologa que usemos para el desarrollo del mismo.
21
CONCEPTOS DE PARADIGMAS
Cada lenguaje de programacin es una creacin y como tal ha sido
cuidadosamente diseado. Algunos lenguajes han sido diseados por
personas nicas, como por
Ejemplo:
La programacin pascal. Otros, han sido diseados por un grupo
grande de personas. La experiencia sugiere que aquellos
lenguajes diseados por personas nicas o grupos pequeos,
tienden a ser ms compactos y coherentes que aquellos
lenguajes diseados por grandes grupos.
Un lenguaje de programacin, digno de su nombre, debe reunir
ciertos
requisitos.
El lenguaje de programacin debe ser universal, es decir, cualquier

problema debe tener una solucin que puede ser programada en el
lenguaje y dicha solucin ser implementada en cualquier computador.
Este requisito es uno de los ms fuertes y pocos lenguajes lo poseen.
Se dice que cualquier lenguaje en el cual pueden definirse funciones
recursivas se considera universal.
1. SINTAXIS Y SEMNTICA
Cada lenguaje tiene sintaxis y semntica:
La sintaxis de un lenguaje de programacin est relacionada con

la forma de los programas, por ejemplo, como es que las
expresiones, comandos, declaraciones, etc. son puestos juntos
en un programa.
21
La semntica de un lenguaje de programacin est relacionada

con el significado de los programas; por ejemplo, cmo ellos se
comportarn cuando se ejecutan en una computadora.
La sintaxis de un lenguaje influye en cmo los programas son

escritos por el programador, ledos por otro programador y
traducidos por el computador. La semntica de un lenguaje
determina
como
programador,
los
programas
entendidos
por
son
compuestos
otros
por
el
programadores
interpretados por el computador. La sintaxis es importante; pero

la semntica es ms importante an.
2. PARADIGMAS DE LA POGRAMACIN
Para que una computadora realice una tarea, debe programrsela
para que lo haga colocando en la memoria principal un algoritmo
apropiado el cual es expresado en lenguaje mquina.
Al estudio de los lenguajes en cuanto al enfoque del proceso de
programacin se le denomina paradigmas de la programacin,
entendindose el trmino paradigma como la forma de ver y
hacerlos
programas.
Bajo
este
enfoque
se
tienen
cuatro
paradigmas los cuales son:
Paradigma por procedimientos o paradigma imperativo:

Representa
un
enfoque
particular
filosofa
para
la
construccin del software.
Paradigma
declarativo:
la programacin
Es
imperativa,
la
es
contraposicin
un paradigma
a
de
programacin que est basado en el desarrollo de programas

especificando o "declarando" un conjunto de condiciones,
proposiciones,
afirmaciones,
restricciones,
ecuaciones
transformaciones que describen el problema y detallan su

solucin.
La
solucin
es
obtenida
mediante
mecanismos
internos de control,
21
Paradigma funcional: se basa en el concepto de funcin (que

no es ms que una evolucin de los predicados), de corte ms
matemtico.
Paradigma
orientado
objetos:
Los
lenguajes
de
programacin proporcionan mecanismos para implementar una

filosofa o paradigma de programacin. Un paradigma es una
forma de entender y representar la realidad: un conjunto de
teoras, estndares y mtodos que, juntos, representan un
modo de organizar el pensamiento, es decir, un modo de ver el
mundo. Cada nuevo paradigma responde a una necesidad real
de nuevas formas de afrontar problemas. A menudo un nuevo
paradigma es creado como respuesta a las deficiencias de
paradigmas anteriores
ESQUEMA:
Conjunto de normas,
creencias actitudes, sobre
la visin del mundo.
Es un esquema terico o
una va de percepcin y
comprensin del mundo.
Paradigma
Es un modelo o ejemplo a
seguir por una comunidad
cientfica, para entender el
mundo.
Se convierte en patrones,
modelos o reglas a seguir
por los investigadores de un
campo de accin
determinado
21
METODOLOGA
1. Definicin;
Se define como el grupo de mecanismos o procedimientos
racionales, empleados para el logro de un objetivo, o serie de
objetivos que dirige una investigacin cientfica. Este trmino se
encuentra vinculado directamente con la ciencia, sin embargo, la
metodologa puede presentarse en otras reas como la educativa,
en donde se encuentra la metodologa didctica o la jurdica en el
derecho.
Se
denomina
metodologa
al
estudio
de
los
mtodos
de
investigacin que luego se aplican en el mbito cientfico. La

Metodologa, del griego met "ms all", ods "camino" y logos
"estudio"
2. Diferencias:
a. Metodologa
21
El metodlogo no pone en tela de juicio el conocimiento ya

aceptado como vlido por la comunidad cientfica sino que se
concentra en la bsqueda de estrategias para ampliar el
conocimiento
Ejemplo: Imp. Estadstica
b. Epistemologa
Cuestiona el valor de esos datos y muestras
La metodologa se relaciona con la investigacin supone la
sistematizacin, es decir, la organizacin de los pasos a travs de
los cuales se ejecutar una investigacin cientfica. No es posible
concebir la idea de investigacin sin pensar de manera casi
automtica en la serie de pasos que debemos cumplir para otorgar
seriedad, veracidad y cientificidad a dicha investigacin.
3. Importancia de la Metodologa
En toda tarea que realizamos en nuestra Vida Cotidiana tenemos
que tener un orden y establecer distintas prioridades para que la
actividad que nos propongamos tenga su respectivo xito y
podamos Alcanzar un Objetivo que nos hemos planteado desde un
principio, evitando que este resultado est condicionado por
factores aleatorios y que la cuota del azar o la suerte no sea la
ms importante a la hora de efectuarlo.
Para poder realizar cada una de estas tareas es necesaria la
aplicacin de una Metodologa de Trabajo, la cual es aplicable a
todo mbito de nuestras vidas, teniendo para ello que contar con
un Conocimiento Previo que nos permita establecer una forma de
llevarse a cabo, por lo que se considera siempre que el primer
paso metodolgico consiste en la Observacin del campo de
aplicacin.
La palabra metodologa puede ser utilizada; a continuacin alguna
de ellos:
La metodologa didctica. Tiene que ver con todo lo relacionado
con las formas o mtodos de enseanza que permiten el xito del
21
proceso
enseanza-aprendizaje,
que
en
este
caso
sera
la
obtencin de los conocimientos necesarios para el aprendizaje,

desarrollo y entendimiento de diversas maneras de aprender un
trabajo o profesin en especial.
4. Metodologa del desarrollo de software, hace referencia al
conjunto de tcnicas, procedimientos y soportes documentales

empleados en el diseo de sistemas de informacin.
Entre las metodologas de desarrollo de software ms aplicadas:
a. La metodologa XP programacin extrema, se caracteriza por
ser una de las ms conocidas dentro de los procesos giles de
desarrollo de software, ya que pone mayor nfasis en la
adaptabilidad, ms que en la previsibilidad.
b. La
metodologa
metodologa
Scrum. Se
gil
caracteriza
flexible que
por
permite
ser
una
gestionar
el
desarrollo de software, tratando de cumplir con su objetivo, el

cual
es
maximizar
el retorno
de
inversin hecha
por
la empresa.
5. Metodologa del conocimiento, se encuentra compuesta por
una serie de elementos que permiten la correspondencia entre

el hombre con su medio ambiente.
6. Metodologa de la historia, se define como una serie de
tcnicas y procedimientos empleados por los historiadores para

manejar las fuentes primarias y otras evidencias que contribuyan
en la investigacin sobre hechos pasados de gran importancia para
las sociedades humanas.
7. Metodologa
cientfica,
esta
queda
definida
como
el
procedimiento investigativo utilizado principalmente en la creacin

de conocimiento basado en las ciencias. Se denomina cientfico
porque dicha investigacin se apoya en lo emprico y en la
21
medicin, ajustndose a los principios especficos de las pruebas

de razonamiento.
Esquema:
METODOLOGIA DE DESARROLLO SSADM

1. Definicin:
21
El ssadm fue producido por la agencia central de informtica y

telecomunicaciones,
del
gobierno
del
reino
unido
oficina
relacionada con el uso de la tecnologa en el gobierno

Es un mtodo de cascada para el anlisis y diseo de sistemas de
informacin. Una de las principales caractersticas de ssadm es la
participacin de los usuarios.
Los aspectos claves de SSADM v 4 Son:
1. nfasis en los usuarios: sus requisitos y participacin.
2. Definicin del proceso de produccin: qu hacer, cundo y
cmo.
3. Tres puntos de vista: datos, eventos, procesos.
4. Mxima flexibilidad en herramientas y tcnicas de
implementacin.
SSADM proporciona un conjunto de procedimientos para llevar a
cabo el anlisis y diseo, pero no cubre aspectos como la
planificacin estratgica ni entra en la construccin del cdigo.
2. Fases de la metodologa
Fase 0: Estudio de
Fase 1: Investigacin del
Viabilidad.
Entorno.
El estudio de viabilidad es El
analista
aprende
la
una versin condensada de terminologa de la empresa.

un anlisis y diseo de -
El
sistema.
de
proporciona los requisitos
un
bsicos
esta
El
producto
etapa
es
documento de estudio de
viejo
sistema
para
el
nuevo
sistema.
viabilidad formal donde se El modelo de datos puede ser

especifica
las
que
estudio
el
secciones construido.
debe Los
usuarios
contener y los detalles de aprenden
las
participan
tcnicas
las opciones excluidas y los modelos del analista.

motivos de su rechazo.
Los
lmites
del
sistema
pueden ser definidos.
21
Fase 2: Opciones del
Fase 3: Especificacin de
sistema de negocio
requisitos
Despus
de
investigado
haber Usa
el
actual,
el
decidir
sobre
los
requisitos
sistema desarrollados en la etapa 1 y
analista
el
debe trabaja en el marco de la

diseo opcin
empresarial
general del nuevo sistema. seleccionada,

Para hacer esto, l o ella, debe
el
analista
desarrollar
usando las salidas de la especificacin
una
completa
etapa anterior, desarrollar lgica de lo que el nuevo

un conjunto de opciones de sistema
sistemas
de
negocio.
debe
El especificacin
hacer.
debe
La
estar
analista puede realizar una libre de error, ambigedad e

sesin de lluvia de ideas inconsistencia. Por lgica, se
para
que
se
generen entiende
diferentes ideas.
que
la
especificacin no dice cmo

el sistema se implementar
sino que describe lo que el
sistema va a hacer.
Fase 4: Tcnicas Fase 5: Diseo
Fase 6: Diseo
Del Sistema
Lgico
Esta etapa es la El
primera
diseo
hacia especifica
una
mtodos
implementacin
principales
Fsico
lgico Esta es la etapa
los final en
todas
la
que
las
de especificaciones
fsica del nuevo interaccin
en lgicas
del
sistema. Al igual trminos
de sistema
se
que las opciones estructuras
de convierten en las
de
negocio
del mens
sistema, en este estructuras
y descripciones del
de sistema
en
momento un gran mando
trminos
nmero
hardware real y
de
de
21
opciones para la
software. Esta es
aplicacin
una
del
etapa
muy
nuevo sistema se
tcnica
una
generan.
visin simple se
presenta aqu
Segn Metodologia SSADM:

El mtodo de anlisis y diseos estructurados proporciona
sistemas que responden a los cambios en el entorno empresarial
as como tambin fomenta
el uso eficaz de los
recursos
disponibles, se encarga de mejorar la calidad mediante la

reduccin de las tasas de error, con siguiendo con esto una
flexibilidad y una productividad mayor.
4
FASES:
BENEFICIOS
Entrega el sistema para los usuarios a tiempo
Entregar los sistemas que cumplen con las necesidades del

usuario
Proporcionar sistemas que correspondan a los cambios en el

entorno empresarial
Fomentar un uso mas eficaz y economico de los conocimientos

disponibles.
Mejora de la calidad mediante la reduccion de la tasas de error.
Mejorar la flexibilidad
Mejorar la productividad
Evitar la dependecia de una sola fuente de suministro

METODOLOGA DE DESARROLLO MERISE
Se define:
Esta metodologa surge en Francia en 1977 a propuesta del Ministerio
de Industria, como un intento de unificar criterios en torno a la
metodologa de desarrollo para los sistemas informticos de la
Administracin Pblica Francesa.
21
Sus principios generales son:
Desglose en etapas: estudio preliminar, estudio detallado,

realizacin y puesta en marcha.
Divisin en el estudio de los tratamientos por un lado y el

estudio de los datos por otro.
Uso del modelo Entidad/Relacin y sus formalismos para

representar los datos.
Uso de los Diagramas de Encadenamiento de Procedimientos

para representar los tratamientos.
Completo reparto de tareas y responsabilidades entre los

desarrolladores durante la fase inicial, y entre los usuarios y
ordenador en la explotacin. (Esquema director)
NIVEL
TRATAMIENTOS
CONCEPTUAL
Las
bases
de
OPCIN
Modelo
Conceptual
De gestin
Modelo Lgico
De
organizacin
Modelo Fsico
Tcnica
Modelo Conceptual
ORGANIZACION
Modelo
AL
Organizacional
OPERACIONAL
DATOS
Modelo
Operacional
MERISE
comenzaron
en
1.972
por
un
equipo
universitario de ingenieros de Aix-en-Provence. La primera versin

sali a finales de 1.976.
El proyecto parti del Centre Technique Informatique del Ministerio de
Industria Francs en Septiembre de 1.977, para cubrir las necesidades
tanto de la administracin como de las empresas. El proyecto finaliz
en mayo de 1.978 dando lugar a MERISE como metodologa de
Anlisis y Diseo de Sistemas de Informacin.
Esta metodologa aporta un ciclo de vida ms largo a los existentes
hasta entonces que se materializa en un conjunto definido de etapas.
Introducen dos ciclos complementarios: ciclo de abstraccin y ciclo de
decisin. El ciclo de abstraccin se basa en la percepcin de tres
21
niveles de abstraccin: conceptual, organizativo y fsico. Adems se

definen dos niveles para cada nivel: un modelo de datos y otro de
tratamientos.
Las fases de la metodologa MERISE son
Estudio preliminar
Estudio detallado
Implementacin.
Realizacin y puesta en marcha
La metodologa Merise aport un ciclo de vida ms largo que los

existentes anteriormente con un conjunto definido de etapas. Abarca
los aspectos relacionados con:
La recopilacin y validacin de la informacin.
Capacitacin de personal.
Evaluacin de equipos informticos.
Anlisis, diseo y validacin de los procesos.
Implementacin, gestin de costos y tiempos y el desarrollo del
cdigo.
Adems del ciclo de vida ms largo, esta metodologa introduce dos
ciclos complementarios:
Ciclo de vida
El ciclo de abstraccin, se basa en la percepcin de tres niveles de
abstraccin de lo ms abstracto al ms concreto: conceptual
finalidades generales de la empresa, organizativo descripcin de la
organizacin necesaria para alcanzar los objetivos y fsico (concrecin
del medio software y el hardware necesarios). Los tres niveles se
desarrollan simultneamente.
El ciclo de decisin. En cada etapa del ciclo de vida, cada vez se va
bajando ms en el nivel de abstraccin (segn el ciclo de
abstraccin), y se toman decisiones, al principio de forma global, y
21
despus de forma ms detallada, conforme se va progresando en el

trabajo.
METODOLOGAS DE DESARROLLO PESADAS

En los inicios de la Informtica, el desarrollo de software era
prcticamente "artesanal" en su totalidad. Debido a la fuerte
necesidad de mejorar el proceso y de hacer cumplir los objetivos
deseados para los proyectos, tuvieron que importarse la concepcin y
fundamentos de metodologas existentes en otras disciplinas y
adaptarlas al desarrollo de software. Algo muy habitual era dividir el
desarrollo en fases secuenciales, donde una tras otra se realizaban
las actividades propias del desarrollador (anlisis, diseo, codificacin
y prueba).
Estas metodologas pesadas o tradicionales que se crearon, consistan
en procesos rigurosos con abundante documentacin. Procesos que
permiten que el desarrollo de software sea ms predecible y eficiente,
como en el caso de una de metodologas ms populares: el Proceso
Unificado.
L a metodologa pesada
Entre las metodologas tradicionales ms populares se encuentran el
mencionado Rational Unified Process (RUP) o tambin Microsoft
Solutions Framework (MSF), que centran su atencin en mantener
21
una documentacin exhaustiva del proyecto y cumplir con el plan

previsto y definido con precisin en la fase inicial del desarrollo del
proyecto.
Digamos
que
las
enfatizar
la documentacin,
metodologas
la
tradicionales
planificacin
suelen
y seguimiento
riguroso de mltiples actividades (mediante plantillas, tcnicas de

administracin, revisiones formales, etc.).
Aunque los modelos generalmente son realistas y estn pensado para
avanzar en la construccin del software de una manera iterativa e
incremental, algunas de las caractersticas negativas dentro de
estos enfoques son los altos costos de implementar cualquier cambio
y el no ofrecer una buena solucin para proyectos que operan en un
entorno extremadamente incierto.
Arquitectura orientada a servicio
Ciclo de vida SOA

Varios de los modelos de proceso importantes se centran en la idea
de "arquitectura", muy a menudo en arquitecturas de componentes o
en las llamadas arquitecturas orientadas a servicios (Service-Oriented
Architecture o SOA). Por eso en esta seccin se explica brevemente lo
que son las arquitecturas orientadas a servicios.
21
Un servicio es un componente que provee un conjunto de funciones

de negocios. Conceptualmente son autnomos, opacos y bajamente
acoplados.
Arquitectura de referencia SOA
SOA permite que los servicios de informacin satisfagan ms
gilmente las necesidades del negocio, cerrando cada vez ms la
brecha entre la estrategia del negocio y la tecnologa subyacente al
mismo.
La
idea
es
crear
servicios
basados
en
estndares,
interoperables e independientes de un proveedor especfico, para

fomentar la reutilizacin de servicios que permitan crear eficazmente
nuevas aplicaciones o funcionalidades en nuestro negocio
Arquitectura de referencia
Implementacin
Para implementar SOA es necesario evaluar el grado de madurez de
la organizacin y definir los grados que aspira alcanzar con el tiempo.
Se comenzara implementado un proyecto piloto, usando SOA para
servicios simples que impacten nicamente un rea del negocio. En el
caso de sistemas heredados se podran habilitar como servicios
aquellas funciones de negocio que requiere el proyecto piloto, y esta
sera una manera de ir introducindose en el uso de esta arquitectura.
21
Niveles de madurez
Nivel
Nivel 6
Nivel 5
Nivel 4
Nivel 3
Nivel 2
Nivel 1
Herramienta
SOA optimizadoa
Adopcin
empresarial de SOA
SOA repetible
Enfoque
SOA
definido
Adopcin Ad Hoc de
SOA
Ninguna
adopcin
de SOA
Utilizacin
Explotacin
Explotacin
Expansin
Expansin
Exploracin
Exploracin
Ejemplo de plataforma de servicios SOA
21
Servicios Web
Los Servicios Web (Web Services) juegan un papel importante en SOA,
ya que brindan mecanismos independientes de la plataforma con los
que exponer, descubrir e invocar servicios.
SOA requiere que un servicio:
Sea descubrible e invocable dinmicamente (como ocurre con UDDI,
WSDL, SOAP...)
Tenga una definicin del contrato independiente de plataforma
(tpicamente XML)
Pueda interpelar con otros servicios (por ejemplo mediante HTTP)
Esquema.
21
METODOLOGAS DE DESARROLLO METRICA

MTRICA esta metodologa propia est basada en el modelo de
procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information
Technology - Software
Life Cycle Processes) as como en la
norma ISO/IEC 15504 SPICE (Software Process Improvement And

Assurance Standards Capability Determination)
Es una metodologa desarrollada y promovida por el Ministerio de
Administraciones
Pblicas
del
Gobierno
de
Espaa
para
la
planificacin, desarrollo y mantenimiento de sistemas informticos

para la gestin de actividades del ciclo de vida de los proyectos
software dentro de las Administraciones Pblicas.
Objetivos
Proporcionar o definir sistemas de informacin que ayuden a
conseguir los fines de la organizacin.
-Dotar a la organizacin de productos software.
-Mejorar la productividad de los departamentos de sistemas y
tecnologas de la informacin y las comunicaciones.
21
-Facilitar
la
comunicacin
entendimiento
entre
los
distintos
participantes en la produccin de software.

-Facilitar la operacin, mantenimiento y uso de los productos software
obtenido.
Como funciona.
Los procesos de la estructura principal de Mtrica son
Planificacin de sistemas de informacin.
Desarrollo de sistemas de informacin.
Mantenimiento de sistemas de informacin
Esquema:
Planificacin de sistemas
Est enfocado a partir del estudio de los ltimos avances en este
campo, la alta competitividad y el cambio a que estn sometidas las
organizaciones
Esquema:
21
Proceso de Desarrollo
- Estudio de viabilidad del sistema (evs).
- Anlisis del sistema de informacin (asi).
- Diseo del sistema de informacin (dsi).
- Construccin del sistema de informacin (csi).
- Implantacin y aceptacin del sistema (ias).
Esquema:
21
Estudio de la viabilidad del sistema (EVS)

La finalidad es proponer una solucin a las necesidades que tenga en
cuenta restricciones tcnicas, econmicas, legales y operativas.
Anlisis de sistemas de informacin (ASI)
El objetivo es obtener una especificacin que responda a las
necesidades de los usuarios y se pueda emplear como entrada para
el diseo.
Proceso de diseo de sistemas de informacin (DSI)
Se revisan los siguientes conjuntos de requisitos: los especificados en
el anlisis, los de las pruebas y los no funcionales.
Proceso de construccin de sistemas de informacin (CSI)
Se revisan los estndares de codificacin, de evaluacin de las
pruebas, manuales de usuario y formacin. Se comprueba que las
pruebas se han llevado a cabo segn los criterios del plan de
aseguramiento de la calidad.
Proceso de implantacin de sistemas de informacin (CSI)
El objetivo es que el sistema sea aceptado por el cliente y que
empiece a funcionar.
Mantenimiento de Sistemas
Ante una peticin de cambio de un sistema de informacin ya en
produccin, se realiza un registro de las peticiones, se diagnostica el
tipo de mantenimiento y se decide si se le da respuesta o no, en
funcin del plan de mantenimiento asociado al sistema afectado por
la peticin, y se establece con qu prioridad.
Esquema:
21
Interfaces
Las interfaces descritas en la metodologa son:
- Gestin de Proyectos (GP)
- Seguridad (SEG)
- Aseguramiento de la Calidad (CAL)
- Gestin de la Configuracin (GC)
Esquema:
Gestin de Proyectos
La Gestin de Proyectos tiene como finalidad principal la planificacin,
el seguimiento y control de las actividades y de los recursos humanos
y materiales que intervienen en el desarrollo de un Sistema de
Informacin.
Esquema:
21
Seguridad
Si bien los riesgos que afectan a un sistema de informacin son de
distinta ndole: naturales (inundaciones, incendios, etc.) o lgicos
(fallos propios, ataques externos, virus, etc.)
Son estos ltimos los contemplados en la interfaz de Seguridad de
MTRICA Versin 3.
Esquema:
21
Gestin de la Configuracin
Su finalidad es identificar, definir,
proporcionar informacin
controlar los cambios en la configuracin del sistema, as como las

modificaciones y versiones de los mismos
Esquema:
Aseguramiento de la Calidad
21
El objetivo de la interfaz de Aseguramiento de la Calidad de MTRICA

Versin 3 es proporcionar una referencia comn para la definicin y
puesta en marcha de planes especficos de aseguramiento de calidad
aplicables a proyectos concretos.
Esquema:
Opinin Personal
Metodologa Mtrica 3 es lo ms parecido a un modelo de proceso
tipo ISO, pues implantar un modelo de calidad con los continuos
avances en software y hardware sera difcil.
Mtrica 3 resulta til como texto de referencia o material de
formacin de UML, prcticas de gestin de proyectos formal, etc.,
21
Ventajas
O Esta metodologa tiene 4 interfaces que define actividades
orientadas a la mejora y perfeccionamiento de los procesos
principales para garantizar la consecucin del objeto del
desarrollo.
O Cubre distintos tipos de desarrollo.
O Mejora a productividad de los departamentos de Sistemas y
Tecnologas
de
la
informacin
las
Comunicaciones,
permitiendo una mayor capacidad de adaptacin a los cambios

y las Comunicaciones.
O Proporcionar o definir Sistemas de Informacin que ayuden a
conseguir los fines de la Organizacin mediante la definicin de
un marco estratgico para el desarrollo de los mismos
Desventajas
O Es demasiado pesado tanto en su implementacin.
O Se mantiene algunos factores de las anteriores versiones.
O Las actividades son de manera general.
21
O Es necesario que cada uno de los miembros tenga el

compromiso y la disciplina de seguir el plan.
O La mayor desventaja es que surge como un modelo abierto y
flexible pero asocia sus herramientas a Microsoft y se vuelve
licenciado en ese sentido.
O No existe un estndar generalmente aceptado.
21
METODOLOGIA RUP
Define:
Es una metodologa cuyo fin es entregar un producto de software. Se
estructura todos los procesos y se mide la eficiencia de la
organizacin.
Es un proceso de desarrollo de software el cual utiliza el lenguaje
unificado de modelado UML, constituye la metodologa estndar ms
utilizada para el anlisis, implementacin y documentacin de
sistemas
orientados
objetos.
El RUP es un conjunto de metodologas adaptables al contexto y

necesidades de cada organizacin.
Describe cmo aplicar enfoques para el desarrollo del software,
llevando a cabo unos pasos para su realizacin.
Se centra en la produccin y mantenimiento de modelos del sistema.
Caractersticas
Forma disciplinada de asignar tareas y responsabilidades (quin

hace qu, cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de

Software.
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software
En esta metodologa lo que se pretende es el desarrollo de un
21
software, en el cual se aplicara el PSP y el CMMI en todos sus fases,

que
estn
en
la
realizacin
de
los
procesos
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 cdigo
fuente, etc.) y roles (papel que desempea una persona en un
determinado momento, una persona puede desempear distintos
roles a lo largo del proceso).
CICLO DE VIDA. PON EN ESPAOL
Esfuerzo en actividades segn fase del proyecto

El ciclo de vida RUP es una implementacin del Desarrollo en espiral.
Fue
creado
ensamblando
los
elementos
en
secuencias
semi-
ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan
varias iteraciones en nmero variable segn el proyecto y en las que
se hace un mayor o menor hincapi en las distintas actividades.
Fases del ciclo de vida del RUP:
21
Fase de Inicio: Esta fase tiene como propsito definir y acordar el

alcance del proyecto con los patrocinadores, identificar los riesgos
asociados al proyecto, proponer una visin muy general de la
arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
Fase de elaboracin: En la fase de elaboracin se seleccionan

los casos de uso que permiten definir la arquitectura base del
sistema y se desarrollaran en esta fase, se realiza la especificacin
de los casos de uso seleccionados y el primer anlisis del dominio
del problema, se disea la solucin preliminar.
Fase de Desarrollo: El propsito de esta fase es completar la

funcionalidad del sistema, para ello se deben clarificar los
requerimientos pendientes, administrar los cambios de acuerdo a
las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
Fase de Cierre: El propsito de esta fase es asegurar que el

software est disponible para los usuarios finales, ajustar los
errores y defectos encontrados en las pruebas de aceptacin,
capacitar a los usuarios y proveer el soporte tcnico necesario. Se
debe verificar que el producto cumpla con las especificaciones
entregadas por las personas involucradas en el proyecto.
21
La metodologa RUP tiene 6 principios clave:

Adaptacin
del
proceso: El
proceso
debe
adaptarse
las
caractersticas de la organizacin para la que se est desarrollando

el software.
Balancear prioridades: Debe encontrarse un balance que satisfaga
a todos los inversores del proyecto.
Colaboracin entre equipos: Debe haber una comunicacin fluida
para coordinar requerimientos, desarrollo, evaluaciones, planes,
resultados, entre otros.
Demostrar
valor
iterativamente: Los
proyectos
se
entregan,
aunque sea de una forma interna, en etapas iteradas. En cada

iteracin se evaluar la calidad y estabilidad del producto y
analizar la opinin y sugerencias de los inversores.
Elevar el nivel de abstraccin: Motivar el uso de conceptos
reutilizables.
Enfocarse en la calidad: La calidad del producto debe verificarse
en cada aspecto de la produccin.
Disciplina de desarrollo de RUP
21
Determina las etapas a realizar durante el proyecto de creacin del

software.
Ingeniera o modelado del negocio: Analizar y entender las

necesidades del negocio para el cual se est desarrollando el
software.
Requisitos: Proveer una base para estimar los costos y tiempo de

desarrollo del sistema.
Anlisis
diseo: Trasladar
los
requisitos
analizados
anteriormente a un sistema automatizado 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.
Disciplina de soporte RUP
Determina la documentacin que es necesaria realizar durante el

proyecto.
Configuracin y administracin del cambio: Guardar todas las
versiones del proyecto.
Administracin
del
proyecto:
Administrar
los
horarios
recursos que se deben de emplear.
Ambiente: Administrar el ambiente de desarrollo del software.
Distribucin: Hacer todo lo necesario para la salida del proyecto.
Elementos del RUP
Actividades:
Procesos
que
se
han
de
realizar
en
cada
etapa/iteracin.
Trabajadores: Personas involucradas en cada actividad del

proyecto.
21
Artefactos: Herramientas empleadas para el desarrollo del

proyecto. Puede ser un documento, un modelo, un elemento del
modelo.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura
esttica) realiza una serie de artefactos que sirven para comprender
mejor tanto el anlisis como el diseo del sistema (entre otros). Estos
artefactos
(entre
otros)
son
los
siguientes:
Inicio:
Documento Visin
Especificacin de Requerimientos
Elaboracin:
Diagramas de caso de uso
Construccin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista lgica:
Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)
Vista de implementacin:
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin
Vista conceptual
Modelo de dominio
Vista fsica
Mapa de comportamiento a nivel de h
21
DIAGRAMA EN UML
DEFINICIN
UML son las siglas de Unified Modeling Language o Lenguaje
Unificado de Modelado. Se trata de un estndar que se ha adoptado
a nivel internacional por numerosos organismos y empresas para
crear
esquemas,
diagramas
documentacin
relativa
los
desarrollos de software (programas informticos).

QU ES Y PARA QU SIRVE UML?
El trmino lenguaje ha generado bastante confusin respecto a lo
que es UML. En realidad el trmino lenguaje quizs no es el ms
apropiado, ya que no es un lenguaje propiamente dicho, sino una
serie de normas y estndares grficos respecto a cmo se deben
representar los esquemas relativos al software. Mucha gente piensa
por confusin que UML es un lenguaje de programacin y esta idea es
errnea: UML no es un lenguaje de programacin. Como decimos,
UML son una serie de normas y estndares que dicen cmo se debe
representar algo.
UML
es
una
herramienta
propia
de
personas
que
tienen
conocimientos relativamente avanzados de programacin y es

frecuentemente usada por analistas funcionales aquellos que definen
qu debe hacer un programa sin entrar a escribir el cdigo y
analistas-programadores aquellos que dado un problema, lo estudian
y escriben el cdigo informtico para resolverlo en un lenguaje como
Java, C#, Python o cualquier otro.
Por tanto si ests dando tus primeros pasos en programacin, te
recomendaramos que te olvides de UML hasta que tengas unos
conocimientos mnimos como uso de condicionales, bucles, y
conocimiento de la programacin orientada a objetos. Esto es solo
una recomendacin, en realidad prcticamente cualquier persona
21
puede usar UML, incluso podra usarse para realizar esquemas o

documentacin
de
procesos
que
no
tengan
que
ver
con
la
informtica.
Hemos dicho que UML es un estndar. Vamos a aclarar primero qu
es un estndar. Supongamos que vamos a definir un estndar
llamado
LMAPR
aprenderaprogramar.com.
lenguaje
Ahora
de
definimos
modelado
dentro
de
de
nuestro
estndar estas normas:
Un animal debe representarse con su nombre escrito enteramente

en minsculas enmarcado dentro de un rectngulo doble. Encima
del nombre debe etiquetarse el tipo de animal as: Tipo de
Animal.
Por ejemplo, Gato.
Si un animal enva un mensaje a otro animal deben conectarse los

dos animales con una lnea punteada terminada en flecha encima
de la cual debe figurar el texto msg Contenido del mensaje.
Ahora supongamos que tenemos dos gatos, uno de los cuales le

dice al otro Caza un ratn y tremelo aqu por favor. Veamos
formas de representar esto:
Esta es una forma de representacin. Sin embargo, no se adapta al

estndar que hemos definido por varios motivos: no indica
<<Gato>> encima de los nombres de los animales, no escribe los
21
nombres en minsculas, no representa los animales con un

rectngulo, etc.
Veamos la representacin que s se adaptara al estndar definido:
Explcito qu es y para qu sirve UML: un conjunto de normas

que nos dicen cmo hay que representar esquemas de software. En el
caso del software orientado a objetos, en vez de gatos tendremos
clases u objetos instanciados, y dispondremos de numerosos tipos de
esquemas y diagramas para representar distintas cosas. Un esquema
que cumple las normas UML podra tener este aspecto:
O tambin este otro:
21
Por qu si ambos esquemas cumplen con UML tienen un

aspecto tan distinto?
Porque UML define normas para construir muchos tipos de esquemas,
no esquemas de un solo tipo.
Quin usa UML?

UML lo suelen usar las empresas o medianos o grandes equipos de
desarrollo software con el objetivo de planificar y documentar cmo
se construyen los programas informticos complejos. Los usuarios
individuales o pequeos equipos de desarrollo de 2 o 3 personas no
suelen usar herramientas UML.
UML es un trmino que se relaciona mucho con Ingeniera del
software.
Al
igual
que
un
proyecto
de
edificio
requiere
la
participacin de un arquitecto y unos plantos, un proyecto software

requiere
la
participacin
de
ingenieros
informticos
una
planificacin y documentacin.
21
METODOLOGIA AGIL
Hechos histricos:
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el
trmino .gil. Aplicado al desarrollo de software. En esta reunin
participan un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologas de
software. Su objetivo fue esbozar los valores y principios que deberan
permitir
los
equipos
desarrollar software
rpidamente
respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Se pretenda ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades
desarrolladas.
El Manifiesto gil:
Segn el Manifiesto se valora:
21
Al individuo y las interacciones del equipo de desarrollo sobre

el proceso y las herramientas. La gente es el principal factor de
xito de un proyecto software. Es ms importante construir un
buen equipo que construir el entorno. Muchas veces se comete el
error de construir primero el entorno y esperar que el equipo se
adapte automticamente. Es mejor crear el equipo y que ste
configure
su propio entorno de desarrollo en base a sus
necesidades.
Desarrollar software que funciona ms que conseguir una buena

documentacin. La regla a seguir es .no producir documentos a
menos que sean necesarios de forma inmediata para tomar una
decisin importante... Estos documentos deben ser cortos y
centrarse en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un

contrato. Se propone que exista una interaccin constante entre el
cliente y el equipo de desarrollo. Esta colaboracin entre ambos
ser la que marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan.

La habilidad de responder a los cambios que puedan surgir a los
largo del proyecto (cambios en los requisitos, en la tecnologa, en
el equipo, etc.) determina tambin el xito o fracaso del mismo.
Por lo tanto, la planificacin no debe ser estricta sino flexible y
abierta.
Los valores anteriores inspiran los doce principios del manifiesto.

Son caractersticas que diferencian un proceso gil de uno
tradicional. Los dos primeros principios son generales y resumen
gran parte del espritu gil. El resto tienen que ver con el proceso a
seguir y con el equipo de desarrollo, en cuanto metas a seguir y
organizacin del mismo.
Principios:
La prioridad es satisfacer al cliente mediante tempranas y

continuas entregas de software que le aporte un valor.
21
Dar la bienvenida a los cambios. Se capturan los cambios para que

el cliente tenga una ventaja competitiva.
Entregar frecuentemente software que funcione desde un par de

semanas a un par de meses, con el menor intervalo de tiempo
posible entre entregas.
La gente del negocio y los desarrolladores deben trabajar juntos a

lo largo del proyecto.
Construir el proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo.
El dilogo cara a cara es el mtodo ms eficiente y efectivo para

comunicar informacin dentro de un equipo de desarrollo.
El software que funciona es la medida principal de progreso.
Los procesos giles promueven un desarrollo sostenible. Los

promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante.
La atencin continua a la calidad tcnica y al buen diseo mejora

la agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de los

equipos organizados por s mismos.
En intervalos regulares, el equipo reflexiona respecto a cmo llegar

a ser ms efectivo, y segn esto ajusta su comportamiento
Clasificacin de metodologas giles:

En la actualidad se cuentan alrededor de 15 a 20 metodologas agiles
sin contar los mtodos hbridos de desarrollo que integran en sus
prcticas como ejemplo a XP con Scrum. A continuacin el listado de
metodologas agiles en desarrollo de software ms representativas
con el ao de creacin,
21
Metodologas que se basan en procesos rpidos, pensados en ser

funcionales, adaptables y adems manejan similitudes entre ellos y
pueden complementarse o formar mtodos hbridos.
Metodologas ligeras vs mtodos tradicionales:
Aunque las metodologas ligeras se basan en las ideas de los
procesos tradicionales estas usan lo ms importante para el buen
desarrollo del proyecto con lgicay dejando atrs el manejo excesivo
de artefactos y burocracia.
21
Diferencias entre mtodos agiles y metodologas tradicionales.

Uso de mtodos agiles:
Desde el surgimiento de estas revolucionarias metodologas que
no solo nacen para el desarrollo de sistemas software sino para el
management o desarrollo de productos los incrementos en adeptos
se presentan gradualmente con el tiempo y las tecnologas.
Y los que las usan, Por qu razn o razones lo hacen?:
Para reducir el tiempo de desarrollo: 45%
Para mejorar la calidad: 43%
Para reducir costes: 23%
Para alinear el desarrollo con los objetivos de negocio: 39%
Otras razones: 12%.
Y cul es el ranking de preferencias entre modelos giles? 1. Extreme Programming (28%) 2.- FDD (26%) 3.- Scrum (20%) 4.Crystal (6%) gil 5.- DSDM (4%) Fuente: Agile Journal [2], n1,
Marzo-2006.
Tipos de metodologas
Editar 0 12
21
Algunos ejemplos de metodologa gil son:

Programacin Extrema, es uno de los ejemplos ms exitosos de
metodologa gil.
Scrum
Crystal
Evolutionary Project Management (Evo)
Feature Driven Development (FDD)
Adaptive Software Developmen(ASD)
Lean Development (LD) y Lean Software Development (LSD)
Proceso Unificado de Desarrollo Software
21
METODOLOGA SCRUM
Scrum es una metodologa gil de desarrollo, aunque surgi como
modelo para el desarrollo de productos tecnolgicos, tambin
se emplea en entornos que trabajan con requisitos inestables y
que requieren rapidez y flexibilidad; situaciones frecuentes en
el desarrollo de determinados sistemas de software.
Es una metodologa de desarrollo muy simple, que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en
la adaptacin continua a las circunstancias de la evolucin del
proyecto.
Scrum es una metodologa gil, y como tal:
Es un modo de desarrollo de carcter adaptable ms que

predictivo.
Orientado a las personas ms que a los procesos.
Emplea la estructura de desarrollo gil: incremental basada en

iteraciones y revisiones.
Se comienza con la visin general del producto, especificando y

dando detalle a las funcionalidades o partes que tienen mayor
prioridad de desarrollo y que pueden llevarse a cabo en un periodo de
tiempo breve (normalmente de 30 das).
Cada uno de estos periodos de desarrollo es una iteracin que finaliza
con la produccin de un incremento operativo del producto.
Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su
evolucin a travs de reuniones breves diarias en las que todo el
equipo revisa el trabajo realizado el da anterior y el previsto para el
da siguiente.
21
Estructura central de Scrum
Caractersticas
Equipos auto dirigidos
Utiliza reglas para crear un entorno gil de administracin de

proyectos
No prescribe prcticas especficas de ingeniera
Los requerimientos se capturan como tems de la lista Product

Backlog.
El producto se construye en una serie de Sprints de un mes de

duracin.
Herramientas y Prcticas
Scrum no requiere ni provee prcticas de Ingeniera. En lugar de

eso, especifica prcticas y herramientas de gerencia que se
aplican en sus distintas fases para evitar el caos originado por la
complejidad e imposibilidad de realizar predicciones.
Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en

el proyecto. Cuando un proyecto comienza es muy difcil tener
claro todos los requerimientos sobre el producto. Sin embargo,
21
suelen surgir los ms importantes que casi siempre son ms que

suficientes para un Sprint.
El objetivo es asegurar que el producto definido al terminar la lista

es el ms correcto, til y competitivo posible y para esto la lista
debe acompaar los cambios en el entorno y el producto.
Existe un rol asociado con esta lista y es el de Product Owner. Si

alguien quiere realizar cualquier modificacin sobre la lista por
ejemplo: agregar o incrementar la prioridad de sus elementos
tiene que convencer al Product Owner.
Sprints
Un Sprint es el procedimiento de adaptacin de las cambiantes

variables
del
entorno
(requerimientos,
tiempo,
recursos,
conocimiento, tecnologa). Son ciclos iterativos en los cuales se

desarrolla o mejora una funcionalidad para producir nuevos
incrementos. Durante un Sprint el producto es diseado, codificado
y probado. Y su arquitectura y diseo evolucionan durante el
desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras

para que sea fcil de recordar y est siempre presente en el
equipo.
Burn down Chart
La burn down chart es una grfica mostrada pblicamente que

mide la cantidad de requisitos en el Backlog del proyecto
pendientes al comienzo de cada Sprint. Dibujando una lnea que
conecte los puntos de todos los Sprints completados, podremos
ver el progreso del proyecto. Lo normal es que esta lnea sea
descendente (en casos en que todo va bien en el sentido de que
los requisitos estn bien definidos desde el principio y no varan
nunca) hasta llegar al eje horizontal, momento en el cual el
proyecto se ha terminado (no hay ms requisitos pendientes de ser
21
completados en el Backlog). Si durante el proceso se aaden

nuevos requisitos la recta tendr pendiente ascendente en
determinados segmentos, y si se modifican algunos requisitos la
pendiente variar o incluso valdr cero en algunos tramos.
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los

tems de la Product Backlog List que van a ser implementados en
el siguiente Sprint.
Los tems son seleccionados por el Scrum Team, el Scrum Master y

el Product Owner en la Sprint Planning Meeting a partir de la
priorizacin de los tems y los objetivos que se marcaron para ese
Sprint. A partir de los objetivos a cumplir durante el Sprint el
Scrum Team determina que tareas debe desempear para cumplir
el objetivo. De esto surge el Sprint Backlog.
Stabilization Sprints
En estos Sprints el equipo se concentra en encontrar defectos, no

en agregar funcionalidad. Suelen aplicarse cuando se prepara un
producto para el release. Son tiles cuando se estn realizando
pruebas beta, se est introduciendo a un equipo en la metodologa
de Scrum o cuando la calidad de un producto no alcanza los lmites
esperados.
No fueron definidos por Scrum pero han sido recomendados por su

utilidad al aplicar esta metodologa.
Scrum of Scrums o MetaScrum
Los equipos de Scrum suelen tener entre 5 y 10 personas, sin

embargo est metodologa ha sido aplicada en proyectos que
involucran ms de 600 personas. Esto ha sido llevado a cabo
21
dividiendo a los accionistas en equipos de pequeos de hasta 10

personas aproximadamente.
Y definiendo jerrquicamente personas que pertenecen a dos

equipos, es decir, adems de su rol especfico dentro de un equipo
tienen el rol de enlace en un equipo superior.
Roles y responsabilidades
Scrum clasifica a todas las personas que intervienen o tienen

inters en el desarrollo del proyecto en: propietario del producto,
equipo, gestor de Scrum tambin Scrum Manager o Scrum Master
y otros interesados.
Los tres primeros grupos (propietario, equipo y gestor) son los

responsables del proyecto, los que segn la comparacin siguiente
(y sin connotaciones peyorativas) seran los cerdos; mientras
que el resto de interesados seran las gallinas.
Cerdos y gallinas
Esta metfora ilustra de forma muy grfica la diferencia de

implicacin en el proyecto entre ambos grupos:
Una gallina y un cerdo paseaban por la carretera.
La gallina dijo al cerdo: Quieres abrir un restaurante conmigo.
El cerdo consider la propuesta y respondi: S, me gustara. Y

cmo lo llamaramos?.
La gallina respondi: Huevos con jamn.
El cerdo se detuvo, hizo una pausa y contest:
Pensndolo mejor, creo que no voy a abrir un restaurante contigo. Yo

estara realmente comprometido, mientras que t estaras
slo implicada.
Roles Cerdo
21
Los Cerdos son los que estn comprometidos con el proyecto y el

proceso Scrum; ellos son los que "ponen el jamn en el plato".
Product Owner
El Product Owner representa la voz del cliente. Se asegura de

que el equipo Scrum trabaja de forma adecuada desde la
perspectiva del negocio. El Product Owner escribe historias de
usuario, las prioriza, y las coloca en el Product Backlog.
Scrum Master (o Facilitador)
El Scrum es
facilitado por
un Scrum
Master, cuyo trabajo
primario es eliminar los obstculos que impiden que el equipo

alcance el objetivo del sprint. El Scrum Master 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
Scrum Master se asegura de que el proceso Scrum se utiliza como
es debido. El Scrum Master es el que hace que las reglas se
cumplan.
Equipo
El equipo tiene la responsabilidad de entregar el producto. Un

pequeo
equipo
de
personas
con
las
habilidades
transversales necesarias para realizar el trabajo (diseador,

desarrollador, etc.).
Roles "Gallina"
Los roles gallina en realidad no son parte del proceso Scrum, pero
deben tenerse en cuenta. Un aspecto importante
de una
aproximacin gil es la prctica de involucrar en el proceso a los

usuarios, expertos del negocio y otros interesados (stakeholders).
Es
importante
que
esa
gente
participe
entregue
retroalimentacin con respecto a la salida del proceso a fin de

revisar y planear cada sprint.
21
Usuarios
Es el destinatario final del producto. Como bien lo dice la paradoja,

El rbol cae en el bosque cuando no hay nadie Hace ruido? Aqu
la definicin sera Si el software no es usado fue alguna vez
escrito?
Stakeholders Clientes, Proveedores
Se refiere a la gente que hace posible el proyecto y para quienes el

proyecto producir el beneficio acordado que lo justifica. Slo
participan directamente durante las revisiones del sprint.
Managers
Es la gente que establece el ambiente para el desarrollo del

producto.
Reuniones en Scrum
Daily Scrum
Cada da de un sprint, se realiza la reunin sobre el estado de un

proyecto. Esto se llama "daily standup". El scrum tiene unas guas
especficas:
La reunin comienza puntualmente a su hora. A menudo hay

castigos -acordados por el equipo- para quin llega tarde (por
ejemplo: dinero, flexiones, llevar colgando una gallina de plstico
del cuello, etc.
Todos son bienvenidos, pero solo los "cerdos" pueden hablar.
La reunin tiene una duracin fija de 15 minutos, de forma

independiente del tamao del equipo.
Todos los asistentes deben mantenerse de pie esto ayuda a

mantener la reunin corta
21
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:
Qu has hecho desde ayer?
Qu es lo que ests planeando hacer hoy?
Has tenido algn problema que te haya impedido alcanzar tu
objetivo? (Es el papel del Scrum Master recordar estos
impedimentos).
Scrum de Scrum
Cada da normalmente despus del Daily Scrum
Estas reuniones permiten a los grupos de equipos discutir su

trabajo, enfocndose especialmente en reas de solapamiento e
integracin.
Asiste una persona asignada por cada equipo.
La agenda ser la misma como del Daily Scrum, adems de las

siguientes cuatro preguntas:
Qu ha hecho tu equipo desde nuestra ltima reunin?
Qu har tu equipo antes que nos volvamos a reunir?
Hay algo que demora o estorba a tu equipo?
Ests a punto de poner algo en el camino del otro equipo?
Reunin de Planificacin del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint cada 15 o 30 das, una Reunin de

Planificacin del Sprint se lleva a cabo.
Seleccionar que trabajo se har
Preparar, con el equipo completo, el Sprint Backlog que detalla el

tiempo que tomara hacer el trabajo.
Identificar y comunicar cunto del trabajo es probable que se

realice durante el actual Sprint
Ocho horas como lmite
21
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la

Reunin de Revisin del Sprint y la Retrospectiva del Sprint
Reunin de Revisin del Sprint (Sprint Review Meeting)
Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados (alias demo)
El trabajo incompleto no puede ser demostrado
Cuatro horas como lmite
21
Retrospectiva del Sprint (Sprint Retrospective)
Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo
dejan sus impresiones sobre el sprint recin superado. El propsito de la retrospectiva es realizar una mejora
continua del proceso. Esta reunin tiene un tiempo fijo de cuatro horas.
21
Visin general del modelo SCRUM
21
METODOLOGA CRYSTAL CLEAR

Qu es Crystal Clear?
Crystal Clear no es una metodologa en si misma sino una familia

de metodologas con un cdigo gentico comn.
El nombre Crystal deriva de la caracterizacin de los proyectos

segn 2 dimensiones, tamao y complejidad (como en los
minerales,
color
dureza).
Por ejemplo.
Clear es para equipos de hasta 8 personas o menos.
Amarillo para equipos entre 10 a 20 personas.
Naranja para equipos entre 20 a 50 persona.
Roja para equipos entre 50 a 100 personas.
Azul para equipos entre 100 a 200 personas.
CC puede ser usado en proyectos pequeos y como casi todos los

otros mtodos, CC consiste en valores, tcnicas y procesos.
La conclusin:
Menos nfasis en la documentacin exhaustiva y ms en versiones
que corran y puedan ser probadas.
Primero son promesas, lo segundo hechos. Cada proyecto necesita

sus propios mtodos. Alistair Cockburn en lugar de partir solament
e de su experiencia personal para construir una teora de cmo de
ben hacerse las cosas
complementa su experiencia directa con la bsqueda activa de pro
yectos para ver cmo trabajan.
l ha explorado a fondo los mtodos giles, haciendo nfasis en la

familia de metodologas Crystal. Es una
familia porque cree que los diferentes tipos de proyectos requieren
diferentes tipos de metodologas. l mira
esta variacin a lo largo de dos ejes: el nmero de personas en el p
royecto, y las consecuencias de los errores.
Cada metodologa encaja en una parte diferente, de modo que par

a un proyecto de 40 personas que puede perder dinero discreciona
21
lmente tiene una metodologa diferente a la de un proyecto vital d

e seis personas.
La familia de metodologas Crystal comparten con la XP una ori

entacin humana, pero esta centralizacin en la gente se hace
de una manera diferente.
Alistair considera que las personas encuentran difcil seguir una

disciplina, as que ms que seguir la alta disciplina de la XP, Alis
tair explora la metodologa menosdisciplinada que aun podra te
ner xito, intercambiando conscientemente productividad por fa
cilidad de ejecucin.
l considera que aunque Crystal es menos productivo que la XP,

ms personas sern capaces de seguirlo.
Alistair tambin pone mucho peso en las revisiones al final de la

iteracin, animando al proceso a aplicar tcnicas de
mejoramiento continuo en forma automtica.
Su asercin es que el desarrollo iterativo est para encontrar los

problemas temprano y entonces permitir
corregirlos. Esto pone ms nfasis en la gente
supervisando su proceso y afinndolo conforme desarrollan.
21
Definiciones
Se trata de un conjunto de metodologas para el desarrollo de soft

ware caracterizadas por estar centradas en las personas que
componen un equipo y la reduccin al mximo del nmero de
artefactos producidos
El desarrollo de software se considera un juego cooperativo de inve

ncin y comunicacin, limitado por los recursos a utilizar.
El equipo de desarrollo es un factor clave, por lo que se deben inve

rtir esfuerzos en mejorar sus habilidades y destrezas, asi como
tener polticas de trabajo en equipo definidos.
Estas polticas dependern del tamao del equipo, establecindose

una clasificacin por colores, por ejemplo Crystal Clear 3 a 8 miem
bros y Crystal Orange 25 a 50 miembros.
Caractersticas:
Las personas, como dispositivos activos, tienen modos de xito y mod
os de fallo. Los siguientes son los principales:
Cuando el nmero de personas aumenta, tambin aumenta la n

ecesidad de coordinar.
Cuando el potencial de daos se incrementa, la tolerancia a vari

aciones es afectada.
La sensibilidad del tiempo en que se debe estar en el mercado v

ara: a veces este tiempo debe acortarse al mximo y se toleran
defectos, otras se enfatiza la auditoria, confiabilidad, proteccin
legal, entre otros.
Las personas se comunican mejor cara a cara, con la pregunta y

la respuesta en el mismo espacio de tiempo.
El factor ms significativo es comunicacin.
Los mtodos se llaman Crystal evocando las facetas de una gema: ca

da faceta es otra versin del proceso y
todas se sitan en torno a un ncleo idntico.
Hay cuatro variantes de metodologas:
21
Crystal Clear para:

Equipos de 8 o menos integrantes Amarillo, para 8 a 20 Naranja, par
a 20 a 50 Rojo, para 50 a100.
La ms exhaustivamente documentada es Crystal Clear (CC), y es la q
ue se ha de describir a continuacin. CC puede ser usado en proyecto
s pequeos. El otro mtodo elaborado en profundidad es el Naranja, a
pto para proyectos de duracin estimada en 2 aos. Los otros dos an
se estn desarrollando. Como casi todos los otros mtodos, CC consist
e en valores, tcnicas y procesos. Los siete valores o propiedades de
CC son:
1) Entrega frecuente
Consiste en entregar software a los clientes con frecuencia, no sola
mente en
compilar el cdigo. La frecuencia depender del proyecto, pero pue
de ser diaria semanal o mensual.
2) Comunicacin osmtica
Todos juntos en el mismo cuarto. Una variante especial es disponer
en la
sala de un experto diseador senior y discutir respecto del tema qu
e se trate.
3) Mejora reflexiva
Tomarse un pequeo tiempo unas pocas horas cada o una vez al m
es para pensar bien qu se est haciendo, cotejar notas, reflexiona
r, discutir.
4) Seguridad personal
Hablar con los compaeros cuando algo molesta dentro del grupo.
5) Foco
Saber lo que se est haciendo y tener la tranquilidad y el tiempo p
ara hacerlo.
6) Fcil acceso a usuarios expertos
Tener alguna comunicacin con expertos desarrolladores.
21
Crystal Clear no requiere ninguna estrategia o tcnica, pero siempre e

s til tener unas cuantas a mano paraempezar.
Las estrategias comunes a otras Metodologas giles, son:
1) Exploracin de 360. Verificar o tomar una muestra del valor de
negocios del proyecto, los requerimientos en el modelo de domino
la tecnologa.
2) Victoria temprana. Es mejor buscar pequeos triunfos iniciales q
ue aspirar a una gran victoria tarda.
3) Esqueleto ambulante. Es una transaccin que debe ser simple p
ero completa.
4) Rearquitectura incremental. Se ha demostrado que no es conve
niente interrumpir el desarrollo para corregir la arquitectura. Ms b
ien la arquitectura debe evolucionar en etapas, manteniendo el sis
tema en ejecucin mientras ella se modifica.
5) Radiadores de informacin. Es una lmina pegada en algn lug
ar que el equipo pueda observar mientras trabaja o camina.
En cuanto a las tcnicas, se favorecen:
a) Entrevistas de proyectos. Se suele entrevistar a ms de un resp
onsable para tener visiones ms ricas.
b) Talleres de refl exin. El equipo debe detenerse treinta minutos
o una hora para reflexionar sobre sus convenciones de trabajo, dis
cutir inconvenientes y mejoras y planear para el perodo siguiente.
c) Planeamiento Blitz. Una tcnica puede ser el Juego de Planeamie
nto de XP. En este juego, se ponen tarjetas
indexadas en una
mesa, con una historia de usuario o funcin visible.

El grupo finge que no hay dependencias entre tarjetas, y las alinea
en secuencias de desarrollo preferidas. Los programadores escribe
n en cada tarjeta el tiempo estimado para desarrollar cada funcin.
Patrocinador del usuario escribe la secuencia de prioridades, tenie
ndo en cuenta los tiempos referidos y el valor de negocio de cada f
uncin. Las tarjetas se agrupan en perodos de tres semanas llama
dos iteraciones que se agrupan en entregas, usualmente no ms la
rgas de tres meses.
21
d) Estimacin Delphi con estimaciones de pericia. En el proceso

Delphi se rene con los expertos responsables y proceden como en
un remate para proponer el tamao del sistema, su tiempo de
ejecucin, las fechas de entrega segn dependencias tcnicas y de
negocios y para equilibrar las entregas en paquetes de igual
tamao.
e) Encuentros diarios de pie. La palabra clave es brevedad, cinc
o a diez minutos como mximo.
No se trata de discutir problemas, sino de identificarlos.
f) Miniatura de procesos. Una forma de presentar Crystal Clear pu
ede consumir entre 90 minutos y un da. La idea es que la gente p
ueda degustar la nueva metodologa.
g) Grficos de quemado. Su nombre viene de los grficos de quem
ado de caloras de los regmenes
dietticos se usan tambin en Scrum.
Se trata de una tcnica de graficacin para descubrir demoras y pr
oblemas tempranamente en el proceso, evitando que se descubra
demasiado tarde que todava no se sabe cunto falta.
Para ello se hace una estimacin del tiempo faltante para program
ar lo que resta al ritmo actual, lo cual sirve para tener dominio de
proyectos en los cuales las prioridades cambian
bruscamente y con frecuencia.
Esta tcnica se asocia con algunos recursos ingeniosos, como la Lis
ta Tmpana, llamada as porque se refiere al agregado de tems co
n alta prioridad en el tope de las listas de trabajos pendientes, esp
erando que los dems elementos se hundan bajo la lnea de flotaci
n los elementos que estn sobre la lnea se entregarn en la itera
cin siguiente, los que estn por debajo en las restantes.
En otras Metodologas giles la Lista Tmpana no es otra cosa que
un grfico de retraso.
Los grficos de quemado ilustran la velocidad del proceso, analizan
do la diferencia entre las lneas proyectadas y efectivas de cada en
trega.
21
h) Programacin lado a lado.

Mucha gente siente que la programacin en pares de XP involucra
unapresin excesiva la versin de Crystal Clear establece proximid
ad, pero cada quien se enfoca a su
trabajo asignado,
prestando un ojo a lo que hace su compaero,
quien tiene
su propia mquina.
Continuacin se describen los artefactos de los que son responsabl
es los roles de CC:
Patrocinador. Produce la Declaracin de Misin con Prioridade

s de Compromiso (Tradeoff).
Consigue los recursos y definen la totalidad del proyecto.
Usuario Experto. Junto con el Experto en Negocios produce la

Lista de ActoresObjetivos y el
Archivo de Casos de Uso y Requerimientos.
Debe familiarizarse con el uso del sistema.
Diseador Principal. Produce la Descripcin Arquitectnica. S

e supone que debe ser al menos un profesional de Nivel 3.
En Metodologas giles se definen tres niveles de experiencia:
Nivel 1 es capaz de seguir los procedimientos.
Nivel 2 es capaz de apartarse de los procedimientos especfico
s y encontrar otros distintos
Nivel 3 es capaz de manejar con fluidez, mezclar e inventar pro
cedimientos. El Diseador Principal tiene roles de coordinador, a
rquitecto, mentor y programador ms experto.
DiseadorProgramador. Produce, junto con el Diseador Prin

cipal, los Borradores de Pantallas, el Modelo Comn de Dominio,
las Notas y Diagramas de Diseo, el Cdigo Fuente, el Cdigo d
e Migracin, las Pruebas y el Sistema Empaquetado.
Un programa en CC es diseo y programa sus programadores
son diseadoresprogramadores. En CC un diseador que no pro
grame no tiene cabida.
21
Experto en Negocios. Junto con el Usuario Experto produce la

Lista de ActoresObjetivos y el Archivo de Casos de Uso y Requer
imientos. Debe conocer las reglas y polticas del negocio.
Coordinador. Con la ayuda del equipo, produce el Mapa de Pro

yecto, el Plan de Entrega, el Estado del Proyecto, la Lista de Rie
sgos, el Plan y Estado de Iteracin y la Agenda de Visualizacin.
Verificador. Produce el Reporte de Bugs. Puede ser un program

ador en tiempo parcial, o un equipo de varias personas.
Escritor. Produce el Manual de Usuario. El Equipo como Grupo

es responsable de producir la Estructura y Convenciones del Eq
uipo y Resultados de Taller de Reflexin.
El Cdigo Gentico
Consiste en:
Un modelo de juegos cooperativos
Este modelo ve al desarrollo de software como una serie de

partidos que consisten en inventar y comunicar. Cada partido es
diferente y tiene como objetivo entregar software y prepararse
para
el
siguiente
juego.
Esto
permite
al
equipo
trabajar
concentrado y en forma efectiva con un objetivo claro cada vez.

Prioridades
Crystal Clear establece un conjunto de prioridades y principios que
sirven de gua para la toma de decisiones:
Eficiencia en el desarrollo: para hacer que los proyectos sean

econmicamente rentables
Seguridad en lo que se entrega
Habitabilidad: hacer que todos los miembros del equipo

adopten y sigan las convenciones de trabajo establecidas por el
equipo mismo.
Propiedades
21
Frecuencia en las entregas: entregar al usuario funcionalidad

"usable" con una frecuencia de entre 2 semanas y no ms de un
mes.
Comunicacin: Crystal Clear toma como uno de sus pilares a la

comunicacin. Promueve prcticas como el uso de pizarrones,
pizarras y espacios destinados a que todos (miembros del equipo y
visitas) puedan ver claramente el progreso del trabajo.
Crecimiento reflexivo: es necesario que el equipo lleve a cabo

reuniones peridicas de reflexin que permitan crecer y hacernos
ms
eficientes.
Estas tres propiedades son "obligatorias" para Crystal Clear, las

siguientes pueden agregarse en la medida de las necesidades de
cada grupo y proyecto.
Seguridad personal: lograr que cada miembro del team pueda

sentirse cmodo con el trabajo y el entorno.
Concentracin:
desarrollador
las
puede
entregas
enfocar
frecuentes
de
un
permiten
problema
que
cada
evitando
dispersiones.
Fcil acceso a usuarios clave: tratar de hacer que el usuario sea

una parte ms del equipo es fundamental para ir depurando
errores de manera temprana.
Entorno tcnico con:

1 Testing automatizado incorporacin, por ejemplo, de UnitTest
2
Integracin frecuente uso de herramientas especficas como
Cruise Control.
Principios
El grado de detalle necesario en documentar requerimientos,

diseo, planeamiento, etc., vara segn el proyecto.
Es imposible eliminar toda documentacin pero puede ser reducida

logrando un modo de comunicacin ms accesible, informal y
precisa que pueda ser accedido por todos los miembros del equipo.
21
El equipo ajusta constantemente su forma de trabajo para lograr

que cada personalidad encaje con los otros miembros, con el
entorno y las particularidades de cada asignacin.
Estrategias
Ni las estrategias ni las tcnicas son mandatorias para Crystal Clear.
Pero es bueno tener en cuenta alguna de ellas al momento de
empezar
trabajar.
Tres de las estrategias que estn ms relacionadas son las de apuntar

a tener "Victorias Tempranas", arrancar el desarrollo de lo que se
denomina un "Esqueleto que Camine" y pensar siempre en hacer
"Rearquitectura Incremental" van de la mano.
El poder arrancar el proceso a partir de un esqueleto sobre el cual se
ir agregando funcionalidad en cada una de las entregas ayuda a que
se vean los avances desde el comienzo aunque sea una simple
pantalla de ABM que se conecta con la base de datos y muestra un
solo dato. A medida que se avanza en el proceso, la rearquitectura
permitir ir agregando ms "cuerpo" al esqueleto inicial.
Todas
describen
una
forma
de
tomar
ventaja
del
desarrollo
incremental para establecer valor desde el principio.
Tcnicas
Igual que con las estrategias, hay una lista de tcnicas propuestas por
Crystal Clear, de las cuales se pueden ir tomando las ms
convenientes segn el momento en que se encuentra el proceso de
desarrollo del proyecto.
21
Las reuniones diarias (introducidas por la metodologa Scrum)

acompaan el seguimiento y mantienen el foco en el prximo paso a
seguir, y tambin permiten la discusin productiva de lneas a seguir.
Las reuniones de reflexin peridicas son fundamentales para que
los miembros del equipo se expresen abiertamente, para revisar el
trabajo hecho y evaluar qu cosas dan resultado y cules no o de
empezar a trabajar.
Todo esto permite ir armando una metodologa de trabajo que se
adecue al equipo, el proyecto y los tiempos que se manejen.
21
METODOLOGA DSDM
Qu es DSDM?
DSDM es el acrnimo que da nombre a un modelo de procesos para el
desarrollo de sistemas de software, desarrollado y concebido por el
denominado DSDM Consortium, que se fund en Inglaterra en 1994, y
que actualmente tiene presencia en Inglaterra, EE.UU. Benelux,
Dinamarca, Francia y Suiza; y con inters y contactos para futuras
representaciones en Australia, India y China.
Es un modelo que estuvo representado en la firma del Manifiesto gil.
Arie van Bennekum, firmante del manifiesto, era miembro del
consorcio en Benelux, consultor y formador de DSDM.
En 2001, ao del Manifiesto gil, DSDM public la versin 4.1 de su
modelo, y se consider una metodologa gil; y aunque mantuvo las
siglas,
cambi
Development
la
denominacin
Method)
original
por Framework
for
(Dynamis
Systems
Business
Centred
Development.
El modelo es propiedad del DSDM Consortium y solo sus miembros
pueden emplearlo con fines comerciales.
Origen
Tomando como fuente las bases tericas y las experiencias de RAD
(Rapad Application Development) el consorcio se fund en enero de
1994 con la finalidad de desarrollar un modelo de desarrollo
independiente de herramientas y que fuera de dominio pblico.
Ed Holt, presidente del consorcio en sus dos primeros aos, afirm
que el uso de herramientas RAD estaba necesitando un marco de
procesos.
La primera versin del modelo se public a principios de 1995, junto
con un programa de adopcin temprana para obtener retroinformacin de las primeras organizaciones que lo adoptaran.
21
Con la informacin y experiencia que el consorcio iba obteniendo se

public la versin 2 en noviembre de 1995, y la 3 en agosto de 1997.
Principios:
En su versin actual (4.2) el marco de procesos DSDM se basa en 9

principios.
La implicacin activa de los usuarios es imprescindible.
Los miembros de los equipos de desarrollo DSDM deben tener la

autonoma y potestad necesarias para tomar decisiones.
Entrega frecuente de incrementos operativos del producto.
El principal criterio de prioridad, desarrollo y validacin de las

entregas incrementales es los objetivos y la salud del negocio.
El desarrollo iterativo o incremental hace posible obtener la

solucin ms adecuada a las necesidades del negocio.
Todos los cambios realizados en el desarrollo son reversibles.
Los requisitos se establecen a un nivel general
Las pruebas forman parte del ciclo de desarrollo
Es imprescindible trabajar con espritu de colaboracin con todos

los agentes implicados en el sistema que se desarrolla.
Procesos del ciclo de desarrollo DSDM

El ciclo de desarrollo de DSDM est compuesto de 5 fases, precedidas
de un pre-- --1. Proyecto y un post-proyecto.
2. Pre-proyecto
3. Estudio de viabilidad
4. Estudio de negocio
5. Iteracin de modelado funcional
6. Iteracin de diseo y desarrollo
7. Implementacin
8. Post-desarrollo
21
Los cinco procesos centrales se suelen representar con el siguiente

grfico, familiarmente denominado "de las 3 pizzas y el queso".
Proceso
21
METODOLOGA FDD
Es una metodologa gil diseada para el desarrollo de software,
basada en la calidad y el monitoreo constante del proyecto.
Fue desarrollada por Jeff De Luca y Peter Coad a mediados de los aos
90. Esta metodologa se enfoca en iteraciones cortas, que permiten
entregas tangibles del producto en un periodo corto de tiempo, de
como mximo dos semanas
Caractersticas
Se preocupa por la calidad, por lo que incluye un monitoreo

constante del proyecto.
Ayuda
contrarrestar
situaciones
como
el
exceso
en
el
presupuesto, fallas en el programa o el hecho de entregar menos

de lo deseado.
Propone tener etapas de cierre cada dos semanas. Se obtienen

resultados peridicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que

producen un software funcional que el cliente y la direccin de la
empresa pueden ver y monitorear.
Ventajas:
El equipo de desarrollo no malgasta el tiempo y dinero del cliente
desarrollando soluciones innecesariamente generales y complejas
que en realidad no son un requisito del cliente.
Cada componente del producto final ha sido probado y satisface los
requerimientos.
Rpida respuesta a cambios de requisitos a lo largo del desarrollo.
Entrega continua y en plazos cortos de software funcional.
21
Trabajo conjunto entre el cliente y el equipo de desarrollo.

Minimiza los costos frente a cambios.
Importancia de la simplicidad, al eliminar el trabajo innecesario.
Atencin continua a la excelencia tcnica y al buen diseo.
Mejora continua de los procesos y el equipo de desarrollo.
Desventajas:
Falta de documentacin del diseo. El cdigo no puede tomarse como
una documentacin. En sistemas de tamao grande se necesitar leer
los cientos o miles de pginas del listado de cdigo fuente.
Problemas
derivados
de
la
comunicacin
oral.
Este
tipo
de
comunicacin resulta difcil de preservar cuando pasa el tiempo y est

sujeta a muchas ambigedades.
Fuerte dependencia de las personas. Como se evita en lo posible la
documentacin y los diseos convencionales, los proyectos giles
dependen crticamente de las personas.
Procesos
Desarrollar un modelo global: Al inicio del desarrollo se construye un
modelo teniendo en cuenta la visin, el contexto y los requisitos que
debe tener el sistema a construir. Este modelo se divide en reas que
se analizan detalladamente. Se construye un diagrama de clases por
cada rea.
Construir
una
lista:
Se
elabora
una
lista
que
resuma
las
funcionalidades que debe tener el sistema, cuya lista es evaluada por

el cliente. Cada funcionalidad de la lista se divide en funcionalidades
ms pequeas para un mejor entendimiento del sistema.
Planear: Se procede a ordenar los conjuntos de funcionalidades
conforme
a su prioridad y dependencia, y se asigna a los
programadores jefes.
21
Disear: Se selecciona un conjunto de funcionalidades de la lista. Se

procede a disear y construir la funcionalidad mediante un proceso
iterativo, decidiendo que funcionalidad se van a realizar en cada
iteracin. Este proceso iterativo incluye inspeccin de diseo,
codificacin, pruebas unitarias, integracin e inspeccin de cdigo
Roles y responsabilidades
El equipo de trabajo est estructurado en jerarquas, siempre debe
haber un jefe de proyecto, y aunque es un proceso considerado ligero
tambin incluye documentacin (la mnima necesaria para que algn
nuevo integrante pueda entender el desarrollo de inmediato).
Arquitecto jefe: Realiza el diseo global del sistema. Ejecucin de
todas las etapas.
Director de desarrollo: Lleva diariamente las actividades de desarrollo.
Resuelve conflictos en el equipo. Resuelve problemas referentes a
recursos.
Programador Jefe: Analiza los requerimientos. Disea el proyecto.
Selecciona las funcionalidades a desarrollar de la ltima fase del FDD.
Cuando usarla
Toda metodologa debe ser adaptada al contexto del proyecto
(recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema).
Exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en
proyectos pequeos y con requisitos muy cambiantes.
Las metodologas giles ofrecen una solucin casi adecuada para una
gran cantidad de proyectos.
Esquema
21
21
ASD DESARROLLADOR DE SOFTWARE ADAPTABLE

DEFINICION:
El mtodo gil ASD Adaptive Software Development en traduccin
significa Desarrollo Adaptable de Software es un modelo de
implementacin de patrones giles para desarrollo de software. Al
igual que otras metodologas giles, su funcionamiento es cclico y
reconoce que en cada iteracin se producirn cambios e incluso
errores.
El desarrollo de software adaptable Adaptive Software Development
ASD es una metodologa de desarrollo que hace nfasis en aplicar las
ideas que se originaron en el mundo de los sistemas complejos,
adaptacin continua del proceso al trabajo.
CARACTERISITICAS:
Sus principales caractersticas del ASD son:
Iterativo.
Orientado a los componentes de software la funcionalidad que el
producto va a tener, caractersticas, etc. ms que a las tareas en
las que se va a alcanzar dicho objetivo.
Tolerante a los cambios.
Guiado por los riesgos
La revisin de los componentes sirve para aprender de los errores
y volver a iniciar el ciclo de desarrollo
CICLO DE VIDA:
ASD utiliza un "cambio orientado hacia el ciclo de vida", que tiene tres
componentes que son: especulacin, colaboracin y aprendizaje.
Especulacin: Compuesta por 5 pasos:
-
Inicio para determinar la misin del proyecto.
Determinacin del marco temporal del proyecto.
Determinacin del n de iteraciones y la duracin de cada una.
76
Determinacin del objetivo de cada una.
Asignacin de funcionalidad a cada iteracin.
Colaboracin:
- Desarrollo concurrente del trabajo de
- construccin y gestin del producto
Aprendizaje: En cada iteracin se revisa:
Calidad, con criterios de cliente.
Calidad, con criterios tcnicos.
Funcionalidad desarrollada.
Estado del proyecto.
Las caractersticas bsicas de ASD son:

-
Trabajo orientado y guiado por la misin del proyecto.
Basado en la funcionalidad.
Desarrollo iterativo.
Desarrollo acotado temporalmente.
Guiado por los riesgos.
Trabajo tolerante al cambio.
En ASD se realizan estimaciones de tiempo sabiendo que pueden

sufrir desviaciones. Sin embargo, estas son necesarias para la
correcta atencin de los trabajadores que se mueven dentro de plazos
de forma que puedan priorizar sus tareas.
Segn Jim Highsmith identifica cuatro tipos de aprendizaje en esta
etapa:
-
Calidad del producto desde un punto de vista del cliente: Es

la nica medida legtima de xito, pero adems, dentro de las
metodologas giles, los clientes tienen un valor importante.
Calidad del producto desde un punto de vista de los

desarrolladores: Se trata de la evaluacin de la calidad de los
76
productos desde un punto de vista tcnico. Ejemplos de esto

incluyen la adhesin a las normas y objetivos conforme a la
arquitectura.
-
La gestin del rendimiento: Este es un proceso de evaluacin

para ver lo que se ha aprendido mediante el empleo de los
procesos
utilizados
por
el
equipo.
Situacin del proyecto. Como paso previo a la planificacin de la

siguiente iteracin del proyecto, es el punto de partida para la
construccin de la siguiente serie de caractersticas.
ACTIVIDAD
ACTIVIDAD DEL
DEL CICO
CICO DE
DE VIDA
VIDA DEL
DEL DESARROLLO
DESARROLLO DEL
DEL
SOFTWARE
SOFTWARE
CICLO DE
APRENDIZAJE
Iniciaci
Iniciaci
n
n del
del
proyecto
proyecto
Planeaci
Planeaci
n
n de
de los
los
ciclos
ciclos
Especulacin
Especulacin
Ingeniera
Ingeniera
de
de
component
component
es
es
concurrent
concurrent
es
es
Control
Control
de
de
calidad
calidad
Colaboracin
Entrega
Entrega
final
final
Aprendizaje
VENTAJAS Y DESVENTAJAS
Ventajas
La tercera fase del ciclo de vida, revisin de los componentes, sirve
para aprender de los errores y volver a iniciar el ciclo de desarrollo.
Apunta hacia
el Rapid Application
Development (RAD),
el cual
enfatiza velocidad de desarrollo para crear un producto de alta

calidad, bajo mantenimiento involucrando al usuario lo ms posible.
Utiliza informacin disponible acerca de cambios para mejorar el
comportamiento del software.
Promulga colaboracin, la interaccin de personas.
Anticipa cambios y trata automticamente con ellos dentro de un
programa en ejecucin, sin la necesidad de un programador.
Desventajas
76
Aunque el ciclo entre el aprendizaje y la especulacin es bueno

permitindonos entregar productos con alta calidad, la prolongacin
de dicho ciclo por errores o cambios que no son detectados en
reuniones anteriores afecta tanto a la calidad del producto como a su
costo total.
Dado a que es una metodologa gil implica no realizar procesos que
son requeridos en las metodologas tradicionales o por lo menos no
realizarlos en procesos diferentes, lo cual implica que empresas
grandes las cuales necesitan llevar un mayor control a procesos y
personas, tener tareas asignadas a un estado o proceso especifico, y
en las cuales dicho incremento de procesos no afectan en gran
medida al costo final del producto, para dichas empresas el elegir una
metodologa tradicional resulta mucho ms rentable tanto por el gran
volumen de personal, de productos, y de costos que se manejan y
para los cuales se tendr un mayor control.
76
METODOLOGA XP
Bdch
Entregas
pequeas:
colocan
un
sistema
sencillo
en
produccin rpidamente que se actualiza de forma rpida y constante

permitiendo que el verdadero valor de negocio del producto sea
evaluado en un ambiente real. Estas entregas no pueden pasar las 2
o 3 semanas como mximo.
1. Entendimiento
Diseo simple: se basa en la filosofa de que el mayor valor de

negocio es entregado por el programa ms sencillo que cumpla
l. Simple Design se enfoca en proporcionar un sistema que
cubra las necesidades inmediatas del cliente, ni ms ni menos.
Este proceso permite eliminar redundancias y rejuvenecer los
diseos obsoletos de forma sencilla.
Metfora: desarrollada por los programadores al inicio del

proyecto, define una historia de cmo funciona el sistema
completo. XP estimula historias, que son breves descripciones
de un trabajo de un sistema en lugar de los tradicionales
diagramas y modelos UML (Unified Modeling Language). La
metfora expresa la visin evolutiva del proyecto que define el
alcance y propsito del sistema. Las tarjetas CRC (Clase,
Responsabilidad y Colaboracin) tambin ayudarn al equipo a
definir actividades durante el diseo del sistema. Cada tarjeta
representa una clase en la programacin orientada a objetos y
define sus responsabilidades (lo que ha de hacer) y las
colaboraciones con las otras clases (cmo se comunica con
ellas).
76
Propiedad colectiva del cdigo: un cdigo con propiedad

compartida. Nadie es el propietario de nada, todos son el
propietario de todo. Este mtodo difiere en mucho a los
mtodos tradicionales en los que un simple programador posee
un conjunto de cdigo. Los defensores de XP argumentan que
mientras haya ms gente trabajando en una pieza, menos
errores aparecern.
Estndar de codificacin: define la propiedad del cdigo

compartido as como las reglas para escribir y documentar el
cdigo y la comunicacin entre diferentes piezas de cdigo
desarrolladas por diferentes equipos. Los programadores las
han de seguir de tal manera que el cdigo en el sistema se vea
como si hubiera estado escrito por una sola persona.
2. Bienestar del programador:

2.1. La semana de 40 horas: la programacin extrema sostiene
que los programadores cansados escriben cdigo de menor
cualidad.
Minimizar
las
horas
extras
mantener
los
programadores frescos, generar cdigo de mayor calidad.

Como dice Beck, est bien trabajar tiempos extra cuando es
necesario, pero no se ha de hacer durante dos semanas
seguidas.
76
Esquema:
3. Proceso de desarrollo:
La programacin extrema parte del caso habitual de una compaa
que desarrolla software normalmente a medida, en la que hay
diferentes roles: un equipo de gestin (o diseo), uno de desarrollo
y los clientes finales. La relacin entre el equipo de diseo, los que
desarrollan el software y clientes es totalmente diferente al que se
ha producido en las metodologas tradicionales, que se basaba en
una fase de captura de los requisitos previa al desarrollo, y de una
fase de validacin posterior al mismo.
4. Interaccin con el cliente,
En este tipo de programacin el cliente pasa a ser parte implicada
en el equipo de desarrollo. Su importancia es mxima en el
momento de tratar con los usuarios y en efectuar las reuniones de
planificacin. Tiene un papel importante de interaccin con el
76
equipo de programadores, sobre todo despus de cada cambio, y

de cada posible problema localizado, mostrando las prioridades,
expresando sus sensaciones... En este tipo de programacin
existirn pruebas de aceptacin de la programacin que ayudarn
a que su labor sea lo ms provechosa posible.
Al fin y al cabo, el cliente se encuentra mucho ms cerca del
proceso de desarrollo. Se elimina la fase inicial de recopilacin de
requerimientos, y se permite que stos se vayan cogiendo a lo
largo del proyecto, de una manera ordenada. De esta forma se
posibilita que el cliente pueda ir cambiando de opinin sobre la
marcha, pero a cambio han de estar siempre disponibles para
solucionar las dudas del equipo de desarrollo.
En XP aparece un nuevo concepto llamado Historia de usuario.
Se trata de una lista de caractersticas que el cliente necesita que
existan en el producto final. Estas constan de dos fases:
En la primera fase, el cliente describe con sus propias
palabras las caractersticas y, es el responsable del equipo,
el encargado de informarlo de las dificultades tcnicas de
cada una de ellas y de su coste. A consecuencia de este
dilogo, el cliente deja por escrito un conjunto de historias y
las ordena en funcin de la prioridad que tienen pera l. De
esta manera ya es posible definir unas fechas aproximadas
para ellos.
En la segunda fase, el cliente coger las primeras historias a
implementar y las dividir en trabajos a realizar. El cliente
tambin participa, pero hay ms peso por parte del equipo
de
desarrolladores,
esto
dar
como
resultado
una
planificacin ms exacta. Este mtodo se repetir para cada

historia.
A diferencia de otras tcnicas, como puede ser UML, en el
caso de XP, se exige que sea el cliente el encargado de
escribir los documentos con las especificaciones de lo que
76
realmente quiere, como un documento de requisitos de

usuario:
En esta fase, el equipo tcnico ser el 'encargado de
catalogar las historias del cliente y asignarles una duracin.
La norma es que cada historia de usuario tiene que poder ser
realizable en un espacio entre una y tres semanas de
programacin. Las que requieran menos tiempo sern
agrupadas, y las que necesiten ms sern modificadas o
divididas.
Finalmente decir que las historias de los usuarios sern
escritas en tarjetas, lo que facilitar que el cliente pueda
especificar la importancia relativa entre las diferentes
historias
de
usuario,
as
como
el
trabajo
de
los
programadores que podrn catalogarlas correctamente. Este

formato tambin es muy til en el momento de las pruebas
de aceptacin.
5. Planificacin del proyecto
En este punto se tendr que elaborar la planificacin por etapas,
donde se aplicarn diferentes iteraciones. Para hacerlo ser
necesaria la existencia de reglas que se han de seguir por las
partes implicadas en el proyecto para que todas las partes tengan
voz y se sientan realmente partcipes de la decisin tomada.
Las entregas se tienen que hacer cuanto antes mejor, y con cada
iteracin, el cliente ha de recibir una nueva versin. Cuanto ms
tiempo se tarde en introducir una parte esencial, menos tiempo se
tendr para trabajar con ella despus. Se aconseja muchas
entregas y muy frecuentes. De esta manera un error en la parte
inicial
del
sistema
tiene
ms
posibilidades
de
detectarse
rpidamente.
Una de las mximas a aplicar es, los cambios, no han de suponer
ms horas de programacin para el programador, ya que el que no
se termina en un da, se deja para el da siguiente.
76
Se ha de tener asumido que en el proceso de planificacin habrn

errores, es ms, sern comunes, y por esto esta metodologa ya
los tiene previstos, por lo tanto se establecern mecanismos de
revisin. Cada tres o cinco iteraciones es normal revisar las
historias
de
los
usuarios,
renegociar
la
planificacin.
Cada iteracin necesita tambin ser planificada, es lo que se

llama planificacin iterativa, en la que se anotarn las historias de
usuarios que se consideren esenciales y las que no han pasado las
pruebas de aceptacin. Estas planificaciones tambin se harn en
tarjetas, en las que se escribirn los trabajos que durarn entre
uno y tres das.
Es por esto que el diseo se puede clasificar como continuo. Aade
agilidad al proceso de desarrollo y evita que se mire demasiado
hacia delante, desarrollando trabajos que an no han estado
programados.
Este tipo de planificacin en iteraciones y el diseo iterativo, hace
que aparezca una prctica que no exista en la programacin
tradicional. Se trata de las discusiones diarias informales, para
fomentar la comunicacin, y para hacer que los desarrolladores
tengan tiempo de hablar de los problemas a los que se enfrentan y
de ver cmo van con sus trabajos.
6. Diseo, desarrollo y pruebas
El desarrollo es la parte ms importante en el proceso de la
programacin extrema. Todos los trabajos tienen como objetivo
que se programen lo ms rpidamente posible, sin interrupciones y
en
direccin
correcta.
Tambin es muy importante el diseo, y se establecen los

mecanismos, para que ste sea revisado y mejorado de manera
continuada a lo largo del proyecto, segn se van aadiendo
funcionalidades al mismo.
La clave del proceso de desarrollar XP es la comunicacin. La
mayora de los problemas en los proyectos son por falta de
76
comunicacin
en
el
equipo.
En XP, aparece un nuevo concepto llamado Metfora. Su principal

objetivo es mejorar la comunicacin entre todos los integrantes del
equipo, al crear una visin global y comn de lo que se quiere
desarrollar. La metfora tiene que ser expresada en trminos
conocidos por los integrantes del equipo, por ejemplo comparando
el sistema que se desarrollar con alguna cosa de la vida real.
Antes de empezar a codificar se tienen que hacer pruebas
unitarias,
es
decir:
Cada vez que se quiere implementar una parte de cdigo, en XP,

se tiene que escribir una prueba sencilla, y despus escribir el
cdigo para que la pase. Una vez pasada se ampla y se contina.
En XP hay una mxima que dice "Todo el cdigo que puede fallar
tiene que tener una prueba".
Con estas normas se obtiene un cdigo simple y funcional de
manera bastante rpida. Por esto es importante pasar las pruebas
al
100%.
Respecto a la integracin del soft, en XP se ha de hacer una

integracin continua, es decir, cada vez se tienen que ir integrando
pequeos fragmentos de cdigo, para evitar que al finalizar el
proyecto se tenga que invertir grandes esfuerzos en la integracin
final. En todo buen proyecto de XP, tendra que existir una versin
al da integrada, de manera que los cambios siempre se realicen
en esta ltima versin.
Otra peculiaridad de XP es que cada programador puede trabajar
en cualquier parte del programa.
De esta manera se evita que haya partes "propietarias de cada
programador". Por esto es tan importante la integracin diaria.
Para terminar, otra peculiaridad que tiene la XP. La de fomentar la
programacin en parejas, es decir, hacer que los programadores
no trabajen en solitario, sino que siempre estarn con otra
76
persona. Una pareja de programadores ha de compartir el teclado,

el monitor y el ratn. El principio fundamental de este hecho es
realizar de manera continua y sin parar el desarrollo de cdigo. Las
parejas tienen que ir cambiando de manera peridica, para hacer
que el conocimiento se difunda en el grupo. Est demostrado que
de esta manera el trabajo es ms eficaz y tambin se consigue
ms y mejor cdigo.
Esquema:
76
CONCLUSIONES
En mi propia opinin los temas investigado La Ingeniera de Software
surge como la aplicacin de modelos y formas de la ingeniera tradicional
a la prctica de construir productos de software; situacin que ha
condicionado su accionar al tener como norte las precisiones y
seguridades que en otros mbitos tiene la ingeniera. Histricamente han
surgido varios enfoques que buscan abordar de manera sistemtica, la
planificacin, anlisis, diseo e implementacin de los proyectos de
desarrollo de software,
sean estos de gran
escala y pequeas
aplicaciones, software a la medida o productos de software. Cada uno de

estos enfoques tiene su raz en las preconcepciones dominantes en su
poca y, sobre todo, en la bsqueda incesante de mejoras a los enfoques
precedentes.
76

Trabajo de Investigación de Angy Metodologia de Desarrollo de Software Corregido

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Trabajo de Investigación de Angy Metodologia de Desarrollo de Software Corregido

Caricato da

Copyright:

Formati disponibili

Ao de la Consolidacin del Mar de Grau

METODOLOGA DE DESARROLLO DE SOFTWARE.

complejidad a algo comprensible en unas lneas.

software podramos verlo

cada botn, detrs de

cada informacin que

las metodologas para el desarrollo del software es independiente de

El lenguaje de programacin debe ser universal, es decir, cualquier

La sintaxis de un lenguaje de programacin est relacionada con

La semntica de un lenguaje de programacin est relacionada

La sintaxis de un lenguaje influye en cmo los programas son

interpretados por el computador. La sintaxis es importante; pero

paradigmas los cuales son:

Paradigma por procedimientos o paradigma imperativo:

construccin del software.

programacin que est basado en el desarrollo de programas

transformaciones que describen el problema y detallan su

Paradigma funcional: se basa en el concepto de funcin (que

programacin proporcionan mecanismos para implementar una

investigacin que luego se aplican en el mbito cientfico. La

El metodlogo no pone en tela de juicio el conocimiento ya

obtencin de los conocimientos necesarios para el aprendizaje,

conjunto de tcnicas, procedimientos y soportes documentales

desarrollo de software, tratando de cumplir con su objetivo, el

una serie de elementos que permiten la correspondencia entre

tcnicas y procedimientos empleados por los historiadores para

procedimiento investigativo utilizado principalmente en la creacin

medicin, ajustndose a los principios especficos de las pruebas

METODOLOGIA DE DESARROLLO SSADM

El ssadm fue producido por la agencia central de informtica y

relacionada con el uso de la tecnologa en el gobierno

Fase 1: Investigacin del

una versin condensada de terminologa de la empresa.

proporciona los requisitos

viabilidad formal donde se El modelo de datos puede ser

contener y los detalles de aprenden

las opciones excluidas y los modelos del analista.

pueden ser definidos.

Fase 2: Opciones del

sistema desarrollados en la etapa 1 y

debe trabaja en el marco de la

general del nuevo sistema. seleccionada,

usando las salidas de la especificacin

etapa anterior, desarrollar lgica de lo que el nuevo

analista puede realizar una libre de error, ambigedad e

especificacin no dice cmo

fsica del nuevo interaccin

sistema. Al igual trminos

que las opciones estructuras

sistema, en este estructuras

momento un gran mando

Segn Metodologia SSADM:

el uso eficaz de los

disponibles, se encarga de mejorar la calidad mediante la

Entrega el sistema para los usuarios a tiempo

Entregar los sistemas que cumplen con las necesidades del

Proporcionar sistemas que correspondan a los cambios en el

Fomentar un uso mas eficaz y economico de los conocimientos

Mejora de la calidad mediante la reduccion de la tasas de error.

Evitar la dependecia de una sola fuente de suministro

Sus principios generales son:

Desglose en etapas: estudio preliminar, estudio detallado,

Divisin en el estudio de los tratamientos por un lado y el

Uso del modelo Entidad/Relacin y sus formalismos para