PROGRAMACIN DE LADO DEL SERVIDOR

Contenido
4.1 Caractersticas y modelos de desarrollo.
4.2 Ventajas.
4.3 Aplicaciones comunes.
4.4 Tecnologas de desarrollo en el servidor.
4.5 Modelo de objetos en el servidor.
4.6 Programacin de scripts en el servidor.
4.7 Pginas dinmicas de servidor.
4.8 Comunicacin de datos entre formularios.
4.9 Programacin con objetos y componentes.
4.10 Elementos de comunicacin asncrona entre
clientes y servidor (AJAX)

4.1 Caractersticas y modelos de
desarrollo
Con objeto de evitar una Web enmaraada y lograr un
mayor xito en el desarrollo y aplicacin de sistemas
basados en Web complejos y a gran escala, existe una
necesidad apremiante de enfoques de ingeniera Web
disciplinada y de mtodos y herramientas nuevos para
el desarrollo, empleo y evaluacin de sistemas y
aplicaciones basados en Web.

4.1 Caractersticas y modelos de
desarrollo
Tales enfoques y tcnicas debern tener en cuenta las
caractersticas especiales en el medio nuevo, en los
entornos y escenarios operativos, y en la multiplicidad
de perfiles de usuario implicando todo ello un reto
adicional para el desarrollo de aplicaciones basadas en
Web.
4.1 Caractersticas y modelos de
desarrollo
La Ingeniera Web (IWeb) est relacionada con el
establecimiento y utilizacin de principios cientficos,
de ingeniera y de gestin, y con enfoques sistemticos
y disciplinados del xito del desarrollo, empleo y
mantenimiento de sistemas y aplicaciones basados en
Web de alta calidad [MUR99]

Metodologas orientadas al
desarrollo Web
WSDM: Web Site Design Method
SOHDM: Scenario-based Object Oriented Hypermedia
Design Methodology
RNA: Relationship-Navigational Analysis
HFPM: Hypermedia Flexible Process Modeling
OOHDM: Object Oriented Hypermedia Design Method
UWE: UML-Based Web Engineering
W2000
NDT: Navigational Development Techniques
OOWS(Object Oriented Web Solution)
EORM: Enhanced Object Relationship Methodology
MEDEPA
EORM
Es definido por un proceso iterativo que se concentra
en el modelo orientado a objetos por la representacin
de las relaciones entre los objetos como objetos.
Entre las ventajas de este modelo estn la flexibilidad y
la reutilizacin , por la existencia de una librera de
clases de enlaces que pueden ser reutilizadas en
diferentes proyectos de desarrollo hipermedia
EORM
Fase de Anlisis: se trata de orientar a objetos al
sistema, obtenindose un modelo de objetos que
refleje la estructura de la informacin (mediante clases
con atributos y relaciones entre las clases) y el
comportamiento del sistema (a travs de los mtodos
asociados a las clases de objetos)
Fase de Diseo: Procede a modificar el modelo de
objetos aadiendo la semntica apropiada a las
relaciones entre clases para convertirlas en enlaces
hipermedia

EORM
Fase de construccin: Se tranforman los esquemas en
codigo y guardados en una Base de Datos y en elaborar
formularios de las consultas de las clases.

OOHDM
Es un metodo de diseo de desarrollo de hypermedia
orientado a objetos y abarca las cuatro actividades
Modelo conceptual
Diseo Navegacional
Diseo abstracto de Interfaz
Puesta en prctica
Estas actividades se realizan en una mezcla de estilo
incremental, iterativo, y basado en prototipos de
desarrollo


OOHDM
Cuenta con las siguientes fases
Fase conceptual: el esquema conceptual esta construido
por clases, por relaciones y subsistemas.
Fase navegacional: en este mtodo la navegacion es
considerada un paso critico en el diseo de las
aplicaciones
Fase de interfaz abstracta: se debe tener las estructuras
navegacionales definidas, se deben especificar los
aspectos de la interfaz.

OOHDM
Fase de implementacion
1. Definir los items de informacin que son parte del dominio
del problema
2. Identificar como son clasificados los items de acuerdo al
perfil de usuario y su tarea
3. Decidir que interfaz debera ver y como deber comportarse

Este modelo propone un conjunto de tareas que en principio
involucran mayor costo de diseo pero que a mediano y largo
plazo reducen notablemente los tiempos de desarrollo al
tener como objetivo principal la reusabilidad del diseo y asi
simplificar la evolucin y el mantenimiento.

SOHDM
Es un Mtodo que Desarrolla Diseo en panoramas
(escenario) Orientada a Objetos en Hipermedia
(Escenario - based Object-oriented Hypermedia
Design Methodology). Presenta la necesidad de
disponer de un proceso que permita capturar las
necesidades del sistema. Para ello, propone el uso de
escenarios.
Se caracteriza principalmente porque su ciclo de vida
comienza con la aplicacin de los escenarios como
tcnica de solicitacin y definicin de requisitos.

SOHDM
El proceso de definicin de requisitos parte de la realizacin de
un diagrama de contexto tal y como se propone en los diagramas
de flujos de datos (DFD) de Yourdon (1989)
Cada escenario describe el proceso de interaccin entre el
usuario y el sistema cuando se produce un evento determinado,
especificando el flujo de actividades, los objetos involucrados y
las transacciones realizadas.
Propone un proceso para conseguir a partir de estos escenarios el
modelo conceptual del sistema, que es representado mediante
un diagrama de clases.
El proceso de SOHDM contina reagrupando estas clases para
conseguir un modelo de clases navegacionales del sistema.

SOHDM
Consiste en seis fases:
Fase de Anlisis, se realizar un estudio de las necesidades
de la aplicacin, del entorno de trabajo y de los actores. La
finalidad principal de esta fase es conseguir los escenarios
que representen las actividades que se pueden llevar a cabo
en el sistema
Fase de Modelado de Objetos, se desarrolla un diagrama
de clases que representa la estructura conceptual del
sistema
Fase de Diseo de Vistas, se reorganizan los objetos en
unidades navegacionales que representan una vista de los
objetos del sistema


SOHDM
Fase de Diseo Navegacional, se enriquecen dichas
vistas definiendo los enlaces e hiperenlaces que existen
en el sistema
Fase de Diseo de la Implementacin, se disean
las pginas, la interfaz y la base de datos del sistema
Fase de Construccin, se realiza la construccin de la
base de datos del sistema. la que se implementa la
aplicacin
SOHDM
En conclusin SOHDM es una propuesta nueva que cubre en
mayor parte todas las fases del proceso de desarrollo, aunque no
toma en cuenta la implantacin y las pruebas, proponindonos
un proceso cclico de tal forma que al realizar una fase se puede
regresar a alguna de las anteriores para refinarla y adaptarla
mejor.
Esta propuesta es hasta ahora la nica que tiene en cuenta
aspectos como la especificacin de requisitos haciendo uso de los
escenarios.
Es que es un proceso sencillo de seguir, no obstante su
nomenclatura es muy cerrada. Adems es una propuesta donde
se hacen uso de tcnicas de modelado orientado a objetos, algo
muy significativo ya que es adecuado para el desarrollo de este
tipo de aplicaciones

WSDM
Es un Mtodo de Diseo para Sitios Web (Web Site Design
Method), donde hay un acercamiento al usuario que define
los objetos de informacin basado en sus requisitos de
informacin para el uso de la Web.
En este mtodo se definen una aplicacin Web a partir de
los diferentes grupos de usuarios que vaya a reconocer el
sistema.
Propone cuatro etapas:
Modelo de usuario,
Diseo conceptual,
Diseo de la implementacin
Implementacin.

WSDM
Fase de Modelo de Usuario, se intenta detectar los perfiles
de usuarios para los cuales se construye la aplicacin.
Durante esta fase es necesario determinar:

Quin es el pblico objetivo? Cmo ser la visin de su
sitio Web? Cules son los objetivos de marketing de la
empresa? Cules son los objetivos de su sitio web? Qu
mensaje tiene su compaa quiere transmitir? Cul es el
campo del negocio? Cules son los estndares de la
industria?



WSDM
Fase de Diseo Conceptual, Durante el modelado conceptual
se realizan dos tareas a la vez: el modelado de objetos, que es lo
que en OOHDM se llama modelo conceptual y el diseo de la
navegacin, que coincide con la idea del diseo navegacional de
OOHDM, Este tipo de diseo de navegacin en aplicaciones
Web tiene una estructura muy jerrquica. La aplicacin de
diseo pasa a crear un coherente y eficiente modelado
conceptual.
Distingue tres tipos de componentes de navegacin, informacin
y externos. Cada navegacin consta de tres capas: contexto,
navegacin y capas de informacin. En WSDM puede existir ms
de un modelo de navegacin, dependiendo de los roles de
usuario detectados durante la primera fase

WSDM
Fase de Diseo de Implementacin: Se modela la
interfaz para cada rol de usuario, Ahora que se tiene
una versin definitiva del plan se puedan comenzar
con la construccin del sitio web. Durante esta fase, se
tendr lugar lo siguiente:
La construccin de la arquitectura de navegacin del sitio.
Creacin de alta funcionalidad, teniendo como fin a la
animacin, pues har que se propague por todas las pginas
de los medios necesarios con sus los grficos y el texto.
El cdigo de los programas tcnicos y la funcionalidad del
sitio.
La creacin y diseo de la pgina principal disponible


WSDM
Fase de Realizacin de Implementacin, se codifican todos
estos aspectos en el lenguaje concreto que se haya seleccionado.
WSDM es tambin una propuesta viva que est cambiando y
adaptndose a nuevos requisitos.
Preparamos el lanzamiento de la web teniendo en cuenta
Cundo entraran a nuestra web? Antes de la puesta en marcha
vamos a garantizar lo siguiente:
Continuo y exhaustivas pruebas que garantizar un impecable
final del sitio web.
Trabajo directamente con la empresa para garantizar la tcnica y
la usabilidad se cumplen las normas.
Velar el final del proyecto con la finalidad de ver si se han
cumplido los requisitos planteados.
Crear una fecha de lanzamiento y el plan

WSDM
WSDM se describe en trminos de componentes y enlaces.
Distingue tres tipos de componentes de navegacin. Cada
navegacin consta de tres capas: contexto, la navegacin y capas
de informacin.
El contexto es la capa superior de la navegacin y a su vez la de
informacin es la capa inferior.
La capa de navegacin conecta la capa de contexto y la capa de
informacin.
Para acceder a la informacin intermedia por componentes y los
vnculos que se crean, tales como los ndices. En la actualidad, es
uno de los trabajos ms interesantes y novedosos que se le est
aplicando es el desarrollo de una herramienta CASE que permita
aplicar el ciclo de vida de desarrollo de WSDM
RNA
Es un mtodo de Anlisis de Navegacin Relacional
(Relationship Navigational Analysis), que define una
secuencia de pasos que se utilizarn para el desarrollo de la
Web.
Es especialmente til para uso de la Web creados en base de
sistema de herencia.
En este mtodo encontramos cinco fases las cuales son:
Anlisis del entorno, donde el propsito de esta fase es el
de estudiar las caractersticas de la audiencia, luego
encontramos las definiciones de elementos de inters, el
anlisis del conocimiento y navegacin y finalmente la
implementacin de los anlisis realizados.
RNA
La propuesta de RNA es quizs una de las que ms ha
resaltado la necesidad de trabajar con la especificacin
de requisitos, incluyendo tareas como el anlisis del
entorno y de los elementos de inters. Adems, resulta
interesante pues plantea la necesidad de analizar los
requisitos conceptuales de manera independiente a los
navegacionales. A continuacin detallaremos cada
fase.

RNA
Fase de Anlisis del Entorno, se determinar y
clasifica a los usuarios finales de la aplicacin en
grupos segn sus perfiles
Fase de Definicin de Elementos: Aqu prosiguen
los elementos de inters en la cual se han listando
dichos elementos de la aplicacin. Por elementos de
inters se entienden los documentos, las pantallas que
se van a requerir, la informacin, etc.

RNA
Fase de Anlisis del Conocimiento, se desarrollar
un esquema que represente a la aplicacin. Para ello
RNA propone identificar los objetos, los procesos y las
operaciones que se van a poder realizar en la
aplicacin, as como las relaciones que se producen
entre estos elementos
Fase de Anlisis de Navegacin, se verifica que el
esquema obtenido en la fase anterior sea enriquecido
con las posibilidades de navegacin dentro de la
aplicacin

RNA
Fase de Implementacin del Anlisis, cuando una
vez obtenido el esquema final en el que ya se
encuentran incluidos los aspectos de navegacin, se
pasa el esquema a un lenguaje entendible por la
mquina
HFPM: Hypermedia Flexible
Process Modeling
La propuesta de HFPM (Olsina,1998 ) describe un
proceso detallado que cubre todo el ciclo de vida de un
proyecto software. HFPM propone un total de trece
fases para las cuales se especifican a su vez una serie
de tareas. Para este estudio es principalmente
relevante la primera fase, denominada de modelado de
requisitos, cuyas tareas son las siguientes:
HFPM
Descripcin breve del problema. No indica ninguna
tcnica concreta pudiendo realizarse esta descripcin
mediante el lenguaje natural.
Descripcin de los requisitos funcionales mediante
casos de uso. Realizar un modelo de datos para esos
casos de uso, proponiendo el uso de un modelo de
clases.



HFPM
Modelar la interfaz de usuario. Para ello, propone el
uso de sketches y prototipos que permitan presentar
los datos al usuario.
Modelar los requisitos no funcionales. En stos
incluyen la navegacin, la seguridad, etc.
Se puede observar que la propuesta de HFPM ofrece
mayor detalle a la hora de realizar el tratamiento de los
requisitos. Sin embargo, no ofrece tcnicas concretas,
especialmente a la hora de trabajar con los requisitos
no funcionales
UWE: UML-Based Web
Engineering
UML-Based Web Engineering (UWE) es una
propuesta metodolgica basada en el Proceso
Unificado (Jacobson, Booch & Rumbaugh, 1999) y
UML para el desarrollo de aplicaciones web
(Hennicker & Koch, 2000, Koch, 2001). UWE cubre
todo el ciclo de vida de este tipo de aplicaciones,
centrando adems su atencin en aplicaciones
personalizadas (adaptivas).
UWE
Esta metodologa distingue entre la tarea de solicitar
requisitos, definir y validar los requisitos. El resultado
final de la captura de requisitos en UWE es un modelo
de casos de uso acompaado de documentacin que
describe los usuarios del sistema, las reglas de
adaptacin, los casos de uso y la interfaz.


UWE
UWE clasifica los requisitos en dos grandes grupos:
funcionales y no funcionales. Los
requisitos funcionales tratados por UWE son:
requisitos relacionados con el contenido
requisitos relacionados con la estructura
requisitos relacionados con la presentacin
requisitos relacionados con la adaptacin
requisitos relacionados con los usuarios

UWE
Adems, UWE propone como tcnicas apropiadas para
la captura de los requisitos de un sistema web las
entrevistas, los cuestionarios y los checklists y los casos
de uso, los escenarios y el glosario para la definicin de
requisitos. Para la validacin propone walk-throughs,
auditoras y prototipos.

W2000
W2000 (Baresi, Garzotto & Paolini, 2001) supone una
propuesta que ampla la notacin de UML con
conceptos para modelar elementos de multimedia
heredados de la propuesta HDM (Hypermedia Design
Model) (Garzotto, Schwabe & Paolini, 1993).
El proceso de desarrollo de W2000 se divide en tres
etapas: anlisis de requisitos, diseo de hipermedia y
diseo funcional.
W2000
La especificacin de requisitos en W2000 se divide en
dos subactividades: anlisis de requisitos funcionales y
anlisis de requisitos navegacionales.
La especificacin de requisitos comienza haciendo un
estudio de los diferentes roles de usuario que van a
interactuar con el sistema.
Cada actor potencialmente distinto tendr su modelo
de requisitos de navegacin y de requisitos
funcionales.

W2000
El modelo de requisitos funcionales es representado
como un modelo de casos de uso tal y como se propone
en UML. En l se representa la funcionalidad principal
asociada a cada rol y las interacciones que se producen
entre el sistema y cada rol.
El segundo modelo consiste en otro diagrama de casos
de uso pero que no representa funcionalidad sino
posibilidades de navegacin de cada actor. La
representacin grfica es realizada con una extensin
de UML.

NDT: Navigational Development
Techniques
NDT (Navigational Development Techniques) (Escalona, Torres
& Mejas, 2002) es una tcnica para especificar, analizar y disear
el aspecto de la navegacin en aplicaciones web.
Para este trabajo, solo es relevante la propuesta que ofrece para la
definicin y captura de requisitos.
El flujo de especificacin de requisitos de NDT comienza con la
fase de captura de requisitos y estudio del entorno. Para ello,
plantea el uso de tcnicas como las entrevistas o el brainstorming
y JAD.
Tras esta fase, se propone la definicin de los objetivos del
sistema. En base a estos objetivos, el proceso contina
definiendo los requisitos que el sistema debe cumplir para cubrir
los objetivos marcados. NDT clasifica los requisitos en:
NDT
Requisitos de almacenamiento de informacin
Requisitos de actores
Requisitos funcionales
Requisitos de interaccin, representados mediante:
Frases, que recogen cmo se va a recuperar la
informacin del sistema utilizando un lenguaje especial
denominado BNL (Bounded Natural Language)
(Brisaboa, Penabad, Places & Rodrguez, 2001).
Prototipos de visualizacin, que representan la
navegacin del sistema, la visualizacin de los datos y la
interaccin con el usuario.
NDT
Requisitos no funcionales
Todo el proceso de definicin y captura de requisitos y objetivos que
propone NDT se basa principalmente en plantillas o patrones, pero
tambin hace uso de otras tcnicas de definicin de requisitos como
son los casos de uso y los glosarios. La propuesta ofrece una plantilla
para cada tipo de requisito, lo que permite describir los requisitos y
objetivos de una forma estructurada y detallada. Algunos de los
campos de los patrones son cerrados, es decir, solo pueden tomar
valores predeterminados. Estos campos permiten que en el resto del
proceso del ciclo de vida de NDT se puedan conseguir resultados de
forma sistemtica.
El flujo de trabajo de especificacin de requisitos termina
proponiendo la revisin del catlogo de requisitos y el desarrollo de
una matriz de trazabilidad que permite evaluar si todos los objetivos
han sido cubiertos en la especificacin.


NDT
La propuesta viene acompaada de una herramienta
case, NDT-Tool, que facilita la cumplimentacin de los
patrones y que permite automatizar el proceso de
consecucin de resultados.

OOWS (Object Oriented Web
Solution)
OOWS es una propuesta para el tratamiento de
requisitos y anlisis de la navegacin en la web. Es una
extensin de OO-Method con capacidades
navegacionales y de presentacin. La metodologa
OOWS siguiendo la aproximacin OO-Method,
realiza en la fase de especificacin conceptual de la
aplicacin la definicin de requerimientos de usuario.

OOWS (Object Oriented Web
Solution)
Luego para modelar la navegacin asociada al sistema est propuesto
un proceso de desarrollo de soluciones Web el cual posee dos pasos
principales:
Especificacin del Problema y desarrollo de la solucin Fase de
Especificacin del problema: En esta fase se captura el comportamiento
del sistema debe ofrecer.
Para esta fase se capturan los requisitos mediante la aproximacin de
casos de uso y posteriormente las actividades de modelado conceptual
del sistema. Para la parte del modelado conceptual las abstracciones
derivadas del problema se especifican en trminos de clases y de su
estructura, comportamiento y funcionalidad, para lo cual se construyen
los siguientes modelos: de objetos, dinmico, funcional, navegacional y
de presentacin.
Esta fase adems realiza un estudio de los tipos de usuarios que pueden
interactuar con el sistema.
OOWS (Object Oriented Web
Solution)
Fase de Desarrollo de la solucin: En esta fase se propone una
estrategia de generacin de cdigo basada en componentes que
permite integrar la solucin propuesta en ambientes Web.
Esta fase se desarrolla de manera totalmente automtica por
intermedio de un compilador de modelos conceptuales (Model
Compiler) el cual construye un sistema de software que recoge
los requisitos de la aplicacin que fue modelada.
Esta estrategia permite facilidad de las tareas de mantenimiento
y evolucin, dado por la generacin automtica basada en
patrones se realiza utilizando soluciones previamente probadas
y validadas.
Esta filosofa permite obtener de manera muy rpida
aplicaciones finales de calidad, evitando la fase de pruebas
(testing) del sistema.

OOWS (Object Oriented Web
Solution)
Ventajas
El uso de base de datos para generacin dinmica de
contenidos.
La utilizacin de una estructura arquitectnica y
navegacin para Sistemas de informacin basados en
Web Permite esquematizar la navegacin de sitios
Web con el uso de contextos navegacionales.
Desventajas
An es una propuesta bastante joven.

MEDEPA
MEDEPA
Es la metodologa de desarrollo del Principado de Asturias. Las
caractersticas de esta metodologa son:
Desarrollo iterativo e incremental. El ms clsico paradigma de ciclo de
vida en cascada ha dado paso a un desarrollo iterativo e incremental,
ms apropiado para la compleja realidad del desarrollo software. Se
reconoce la imposibilidad de cerrar completamente las fases de
definicin de requisitos, y se inician las fases siguientes cuando se tiene
informacin suficientemente elaborada. Asimismo, se plantea el
desarrollo de sistemas complejos como una serie de iteraciones, donde
se tiene un sistema usable al final de cada iteracin. El sistema final se
obtiene tras la ejecucin incremental de varias iteraciones.
nfasis en la comunicacin gil. Se plantea un modelo de
comunicacin donde se involucra a los participantes del proyecto, y tan
temprano como sea posible.
MEDEPA
Soportado en plantillas. Existe una serie de cuestiones que han de dilucidarse
durante el proceso de desarrollo, relativas a la funcionalidad a implementar,
mbito de aplicacin, etc. Estas cuestiones han de irse respondiendo a medida
que se disponga de la informacin necesaria, y la metodologa proporciona
plantillas que guan en la identificacin y resolucin de las cuestiones ms
importantes, identificndolas.
Uso de tcnicas de modelado y validacin formal. En ninguna disciplina
madura (fabricacin, construccin, etc.) se construye nada sin antes pasar por
a) una fase de diseo donde se representa el objeto a construir
b) una fase de validacin donde se refina el modelo.

Esto permite reducir tremendamente los costes, al detectarse fallas antes de la
construccin. Al igual que no se edifica una casa sin antes dibujarla, la
metodologa la expectativa de poseer una descripcin de aquellos elementos a
construir empleando tcnicas estndar de representacin, y que estas
descripciones sean validadas.
MEDEPA
Uso de UML. Se propone el uso del Lenguaje Unificado de Modelado
(UML en sus siglas en ingls) como tcnica estndar de representacin.
La propia metodologa est modelada de acuerdo a SPEM (Software
Process Engineering Metamodel), una extensin de este lenguaje para
la representacin de procesos de ingeniera de desarrollo software.
Difusin de mejores prcticas. En los procesos descritos, se incorporan
las mejores prcticas conocidas en la organizacin a fin de conseguir su
uso por el mayor nmero de proyectos. Estas prcticas son el resultado
de los mltiples proyectos llevados a cabo hasta la fecha por un nmero
de equipos de desarrollo.
Mantenimiento y evolucin. La metodologa debe ser mantenida y
evolucionada por un equipo de la organizacin. Para ello, se establece
un grupo propietario de esta, que la va refinando en base a las
lecciones aprendidas en la ejecucin de proyectos y de tcnicas
cuantitativas.
MEDEPA
Ventajas
Es una metodologa muy utilizada en el Principado de
Asturias.
Est en constante evolucin.
Flujo de trabajo repetible. La metodologa describe un
proceso sistemtico, igual para todos los proyectos y
por tanto repetible. Esto permite que el estado de un
proyecto pueda comunicarse efectivamente a personas
que no participan en su ejecucin, en base a
entregables (artefactos) que son los mismos
independientemente del proyecto.



MEDEPA
Proporciona un proceso consistente. Dado que los
artefactos elaborados son formalmente iguales entre
los distintos proyectos, stos son comparables. Por
tanto, pueden establecerse estndares (plantillas,
criterios mnimos de calidad, etc.) y definirse en qu
lugares stos es de aplicacin.
Proporciona un proceso automatizable. Al definir el
desarrollo como un proceso, es posible automatizar
determinadas tareas (especialmente las ms
repetitivas y tediosas), de manera que pueden
construirse herramientas que den soporte al proceso.

MEDEPA
Describe un proceso medible. Tomando un proceso
sistemtico, pueden elaborarse mtricas que midan
determinados aspectos del proceso (desempeo, calidad,
etc.). Una metodologa posibilita el uso de tcnicas
estadsticas de gestin, que aumentan enormemente la
capacidad de predecir y controlar los resultados de los
proyectos.
Permite la mejora del proceso. Al presentar una descripcin
explcita del proceso y al contar con mtricas que nos
informan de los aspectos relevantes, pueden tomarse
decisiones de mejora sobre la propia metodologa,
empleando tcnicas cuantitativas. Estas mejoras deben
revertir en un mayor control y un mejor rendimiento del
proceso de desarrollo.
MEDEPA
Desventajas
Est muy orientada a la estructura orgnica del
Principado de Asturias.
No est tan enfocada a objetos como otras
metodologas.



RUP
RUP es actualmente constituye la metodologa estndar
ms utilizada para el anlisis, implementacin y
documentacin e sistemas orientados a objetos.
Esta metodologa est basada en el modelo en espiral,
aunque no es un sistema con pasos firmemente
establecidos, sino un conjunto de metodologas adaptables
al contexto y necesidades de cada organizacin. Los
creadores de RUP estudiaron las diversas causas por las
cuales solan fallar los proyectos software y estudiaron las
mejores prcticas para evitarlos. Estos estudios dieron
como resultado una metodologa iterativa e incremental.
RUP
Ventajas
Demuestra valor iterativamente: Los proyectos se entregan,
aunque sea de un modo interno, en etapas iteradas. En cada
iteracin se obtiene una versin ejecutable del proyecto
(artefacto). En cada iteracin se analiza la opinin de los
inversores, la estabilidad y calidad del producto, y se refina la
direccin del proyecto as como tambin los riesgos
involucrados.
Elevar el nivel de abstraccin: Este principio dominante motiva
el uso de conceptos reutilizables tales como patrn del software,
lenguajes 4GL o esquemas (frameworks) por nombrar algunos.
Se enfoca a la calidad: El control de calidad no debe realizarse al
final de cada iteracin, sino en todos los aspectos de la
produccin

RUP
Desventajas
Si el conjunto de documentos y artefactos no son
concebidos tal y como se plantea en RUP, la
documentacin solo servir para ser archivada lo cual
no genera valor respecto a la calidad del desarrollo, y
evoluciona en problemas ms complejos.
Una de las desventajas que ms se menciona sobre
RUP es que supone un mayor coste de personal que
otras metodologas.

XP (eXtreme Programming)
Es la metodologa ms destacada de los procesos giles
de desarrollo de software.
Una de sus principales caractersticas es la constante
comunicacin con el cliente y la participacin del
mismo en el proceso de desarrollo. Adems, ven los
cambios en los requerimientos como algo natural y se
adapta a ellos.
El trabajo se realiza siguiendo estos principios:
XP (eXtreme Programming)
Planning
a. Los clientes escriben las historias de usuario (equivalente a
casos de uso).
b. Crear el calendario de releases a implementar.
c. Hacer pequeas releases frecuentemente.
d. Se mide la velocidad del proyecto y se compara con la
estimada.
e. El proyecto se divide en iteraciones
f. Se divide el proyecto en iteraciones de longitud constante.
g. Rotacin d personas en las tareas del proyecto.
h. Reuniones del equipo al comienzo de cada da.
i. Reparar el proceso cuando no funcione, con estos mismos
principios.
XP (eXtreme Programming)
Designing
a. Simplicidad
b. Seguir criterios de nombrado.
c. Usar tarjetas CRC.
d. Crear pequeos prototipos para reducir el riesgo.
e. No aadir funcionalidades antes de lo que marca el
planning.
f. Refactorizar siempre que sea posible.
XP (eXtreme Programming)
Coding
a. El cliente siempre est disponible.
b. El cdigo debe estar escrito siguiendo los estndares.
c. Primero se codifican las pruebas unitarias.
d. Todo el cdigo se escribe por parejas.
e. Solo un par integra cdigo al mismo tiempo.
f. Integrar a menudo.
g. Uso colectivo del cdigo fuente.
h. Las optimizaciones se dejan para el final.
i. No sobrepasar las 40 horas semanales.
XP (eXtreme Programming)
Testing
a. Todo el cdigo debe tener pruebas unitarias.
b. Todo el cdigo debe pasar todas las pruebas unitarias
antes de incluirse en una release.
c. Cuando se encuentra un error, se crean tests.
d. Se crean test de aceptacin a partir de las historias de
usuario.
XP (eXtreme Programming)
Ventajas
Programacin organizada.
Menor tasa de errores.
Satisfaccin del programador.
Desventajas
Se debe contar con un equipo de personas muy bueno.
Se critica la programacin por parejas.
Cuenta con que el cliente siempre est disponible, cosa
que en el mundo real rara vez ocurre.
SCRUM
Scrum es una metodologa gil:
Es un modo de desarrollo de carcter a daptable.
Orientado a las personas antes que a los procesos.
Emplea desarrollo gil: iterativo e incremental.
Cada uno de los ciclos de desarrollo es una iteracin
(sprint) que produce un incremento terminado y
operativo del producto. La gestin de la evolucin de las
iteraciones es a travs de reuniones breves de
seguimiento en las que todo el equipo revisa el trabajo
realizado desde la reunin anterior y el previsto hasta la
reunin siguiente.
SCRUM
Toma las siguientes prcticas de la gestin gil:
Revisin de las Iteraciones: Al final de cada sprint o
iteracin, se realiza una revisin con todas las personas
implicadas en el proyecto. Este es el periodo mximo
que se puede tardar en reconducir una desviacin del
proyecto o de las circunstancias del producto.
Desarrollo incremental: En el proyecto, no se trabaja
con diseos o abstracciones. El desarrollo incremental
implica que al final de cada iteracin se dispone de una
parte del producto operativa que se puede
inspeccionar y evaluar.


SCRUM
Desarrollo evolutivo: Con Scrum, el diseo y la estructura del
resultado se construyen de forma evolutiva. Para evitar los
problemas de degradacin del sistema o de la arquitectura por la
evolucin continua del producto se deben incluir prcticas de
refactorizacin en las tareas de diseo y codificacin.
Auto-organizacin: Durante el desarrollo de un proyecto surgen
circunstancias impredecibles en todas las reas y niveles. En
Scrum los equipos son auto-organizados, con margen de
decisin suficiente para tomar las decisiones que consideren
oportunas.
Colaboracin: Las prcticas y el entorno de trabajo giles
facilitan la colaboracin del equipo, que es necesaria y debe
basarse en la colaboracin abierta entre todos segn los
conocimientos y capacidades de cada persona, y no segn su rol
o puesto.
SCRUM

Ventajas
Gran flexibilidad ante cambios.
Entrega de un producto final en cada sprint.
Contina refactorizacin de la arquitectura.





SCRUM
Desventajas
No funciona con equipos no experimentados.
Tampoco si el cliente no tiene una gran disponibilidad.
Enfocada a proyectos grandes.
No genera toda la documentacin de otras metodologas.
Frecuentemente es necesario complementarla con otros
procesos de XP.
Una vez recopilada la informacin sobre las principales
metodologas de anlisis orientado a objetos, decidimos no
seguir ninguna metodologa en concreto, sino que nos
decantamos por utilizar una metodologa propia cogiendo de
las metodologas vistas, las caractersticas que se consideran
ms importantes y relevantes para el proyecto a desarrollar.