Secion 4

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.

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.

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 MethodSOHDM: Scenario-based Object Oriented Hypermedia Design MethodologyRNA: Relationship-Navigational AnalysisHFPM: Hypermedia Flexible Process ModelingOOHDM: Object Oriented Hypermedia Design MethodUWE: UML-Based Web EngineeringW2000NDT: Navigational Development TechniquesOOWS(Object Oriented Web Solution)EORM: Enhanced Object Relationship MethodologyMEDEPA

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 conceptualDiseo Navegacional Diseo abstracto de InterfazPuesta 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 aplicacionesFase de interfaz abstracta: se debe tener las estructuras navegacionales definidas, se deben especificar los aspectos de la interfaz.

OOHDM
Fase de implementacion1. Definir los items de informacin que son parte del dominio del problema2. Identificar como son clasificados los items de acuerdo al perfil de usuario y su tarea3. 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. Losrequisitos funcionales tratados por UWE son:requisitos relacionados con el contenidorequisitos relacionados con la estructurarequisitos relacionados con la presentacinrequisitos relacionados con la adaptacinrequisitos 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 informacinRequisitos de actoresRequisitos funcionalesRequisitos 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.

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.

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.

VentajasEl 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. DesventajasAn es una propuesta bastante joven.

MEDEPA
MEDEPAEs 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 construirb) 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
VentajasEs 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
DesventajasEst 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:

Planninga. 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 iteracionesf. 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.


Designing
a. Simplicidadb. 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.


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.


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.

VentajasProgramacin organizada.Menor tasa de errores.Satisfaccin del programador.

DesventajasSe 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.

Secion 4

Documents

Transcript of Secion 4