Sunteți pe pagina 1din 20

Antecedentes.

Acerca del WUP El Proceso Unificado de la web es una ligera combinacin de un par de mtodos de desarrollo giles y UML. Su nombre es pretencioso. Sin embargo, el objetivo del mtodo es proporcionar a los desarrolladores web con una herramienta para agilizar sus proyectos y entregar productos de alta calidad. Introduccin El desarrollo de aplicaciones Web crece rpidamente. Sin embargo, la principal diferencia se mantendr: la web tiene que ver con la comunicacin y la comunicacin humana depende en gran medida el uso de la emocin. Como todos sabemos, la fuerza tradicional de desarrollo de TI no est en diseo creativo Esta dependencia de la emocin y la creatividad conduce directamente a un trade-off que molesta cada empresa de desarrollo web. Cmo en la tierra se puede mezclar el libre espritu de la web con la eficacia que el desarrollo de modernas aplicaciones pide? Lo mejor de ambos mundos Funcionalidad de la web no puede ser planificada, los plazos se descuidan, los presupuestos se sobrestimaron y los resultados no se ajustan a las necesidades de un cliente: esto suena realmente como un proyecto medio de Internet. Sin embargo, el desarrollo tcnico mtodo descrito en el presente documento podra evitar estos problemas, utilizando la creatividad y la flexibilidad de la red y las capacidades estructurales de desarrollo ms tradicionales. Web proceso unificado WUP (Proceso Unificado de la web) es un mtodo para la construccin de aplicaciones web en un entorno profesional. El mtodo utiliza UML (Unified Modeling Language) para su notacin. El mtodo WUP guas desarrolladores y administradores de proyectos en una estructura ms flexible y manera de construir aplicaciones web que se adapten a las necesidades del cliente. Se diferencia de los procesos tradicionales a ser mucho ms prctica, sencilla y directamente diseado una red de puntos de vista. Este documento comienza con la determinacin de las lneas generales del mtodo, despus de que los detalles se describen. Las siluetas de WUP WUP (Proceso Unificado de la web) es un mtodo para la construccin de aplicaciones web. El mtodo utiliza UML (Unified Modeling Language) y, en su caso la Wae UML (Web Application Extension) para su notacin. El mtodo trata de establecer un proyecto iterativo ritmo, en la que algunos escenarios tarea repetitiva se realizan de acuerdo a un plan. El desarrollo de una aplicacin est segmentada en periodos de tiempo llamado incrementos.

Una descripcin del problema de dominio es el comienzo de cada proyecto. comportamiento del futuro sistema est impulsado por casos de uso UML.
El objetivo del mtodo

El

En general, un mtodo de desarrollo est destinado a orientar las actividades de un equipo de desarrolladores. Especialmente en los proyectos que son relativamente complicado, las cosas tienden a ser olvidado o subestimado. Un mtodo estructural pueden servir de gua para los menos experimentados miembros del equipo e incluso los desarrolladores ms experimentados. Como resultado de ello, cada miembro del equipo tiene una visin clara de la orden de las tareas que tiene que realizar, lo que significa que todo el mundo sabe que cuando se va a hacer qu y por qu se le va a hacer eso.
Ritmo

El proceso tiene la principal responsabilidad de establecer un ritmo, que ayuda a construir proyecto inercia. En la prctica, esta inercia se mantendr el flujo de velocidad o el desarrollo del proyecto, incluso en tiempos difciles. El mtodo tambin ofrece criterios para el seguimiento y la medicin del proyecto. El WUP trata de proporcionar un enfoque flexible para la construccin de aplicaciones web, todo sin la molestia de los mtodos tradicionales. El proceso intenta evitar que la creatividad de ser estructurado a la muerte. La mayor parte de todos, WUP es prctico. Si usted es dueo de una pequea empresa de desarrollo web y desea comenzar con un proyecto de inmediato, basta con leer el manual de WUP y utilizar la plantilla de los documentos.

Las herramientas de WUP


Se Definen algunos de los conjuntos de Herramientas WUP. Clases de Dominio La entidad es una unidad funcional que acta en el problema de dominio para que la aplicacin web se est construyendo. En objeto de orientacin, las entidades que se traducen en clases del sistema. El dominio de diagrama de clases es el modelo UML en el que estas clases se muestran.

La determinacin de las clases


Una clase modelo se determina a travs de una serie de pasos. Esto se realiza en sesiones de lluvia de ideas. Preferiblemente, todo el equipo se une a estas sesiones. Si esto no es posible, al menos funcional que toma decisiones y un par de tcnicos desarrolladores deben estar presentes. Identificar todos los posibles candidatos de clase el problema de dominio y casos de uso (si est presente); seleccionar las clases de la lista de candidatos; hacer un modelo de diccionario; identificar las asociaciones;

identificar atributos; identificar las operaciones; generalizar el uso de herencia (Tenga cuidado! Esto no es apoyada por todos los lenguajes de programacin); hacer limitaciones; iterar a lo largo de estos pasos.

Un ejemplo de un diagrama de clases de dominio El resultado del perodo de sesiones se describe podra dar lugar al siguiente diagrama. Este simple ejemplo es tomado del diseo de un sistema de ventas en lnea.

[esta imagen se basa en una ilustracin de Martin Fowler] Requisito descripcin La descripcin de las necesidades de los sistemas se pueden dividir en tres partes: los casos de uso, sus historias y los requisitos del sistema. Casos de uso Los requisitos empresariales que describen fuera de la funcionalidad del sistema se definen en los casos de uso UML. Casos de uso son breves descripciones del comportamiento del sistema, desde el punto de vista del usuario. Un caso de uso describe explcitamente la interaccin entre el usuario o el actor y el sistema, donde el sistema se considera un cuadro negro. Un caso de uso tiene un nombre, condiciones previas, una descripcin, las excepciones, puesto condiciones y una prioridad. La decisin maker funcional define los casos de uso. l determina su valor comercial y, por tanto, su prioridad. El caso de uso lista puede ser modificada a una prueba de la lista de deshacer los casos de uso a las preguntas. Al solicitar estas preguntas, la capacidad del sistema para satisfacer los requisitos se pueden comprobar fcilmente.

Caso de uso de paquetes La completa funcionalidad del sistema se describe en partes funcionales o los paquetes de casos de uso. Una de ellas podra ser la interfaz cliente, o un mdulo de administracin. Un paquete puede ser demostrado por medio de un caso de uso UML Diagrama de paquetes, como se hace para un sistema de ventas en lnea en el siguiente diagrama.

[esta imagen se basa en una ilustracin de Martin Fowler] Historias En un caso de uso, el sistema se considera un cuadro negro. Esto significa que la lgica interna no se describe ni siquiera se menciona. En WUP, un caso de uso tiene una o ms historias. Cuidadosa, utilizamos un tipo diferente de la historia que hace XP! Historias describir las medidas que deben adoptarse dentro del sistema para realizar un caso de uso. Las historias no son parte del UML, pero son parte de WUP porque es una forma muy directa de describir lo que el sistema tiene que hacer. El que toma decisiones orgnicas y los desarrolladores de definir las historias de cada caso de uso conjunto, en contraposicin a los casos de uso propios, que son definidas por el fabricante de decisin funcional. Una historia es una unidad que puede ser aplicado, y puede considerarse como una tarea directa para los desarrolladores. Una historia puede ser tcnica, pero tambin se puede decir que se trata de un diseador o un escritor. El funcional que toma decisiones no debe ser molestado con esta distincin. Los desarrolladores propios inscribirse para la realizacin de un caso de uso o historias individuales. Historia de estimacin Los desarrolladores estimar la complejidad de cada historia y, por tanto, la complejidad de cada caso de uso. Cada desarrollador de signos en para realizar un par de historias. Estas estimaciones se expresan en el PPD. Un PPD significa un proyecto Perfect Day o un da de desarrollo para un alto desarrollador externo sin complicaciones. Una historia tiene, en general, un perodo de realizacin, con un mximo de 2 o 3 PPD. Si el nmero de PPD's es superior a la que, el equipo debera considerar la posibilidad de dividir la historia.

Velocidad de realizacin La velocidad de realizacin para diferentes niveles de desarrollo puede estimarse como esto: Senior 1 PPD / da Medior 0,8 PPD / da Junior 0,6 PPD / da Aprendiz 0,4 PPD / da El uso de estos supuestos, la duracin del proyecto puede estimarse considerando los recursos del equipo. Es tan simple como esto: para cada miembro del equipo de desarrollo, multiplique el nmero de das que l o ella est presente cada semana por su velocidad especfica diaria. Esto lleva a que el nmero de PPD de cada semana por persona. La suma de estos nmeros para todo el equipo, lo que conduce a la semana del equipo de produccin. Divida el importe total del proyecto del PPD's (todos los casos de uso resumirse) por el equipo de la semana. Esto se traduce en la duracin del proyecto en semanas. Si esta duracin no se ajusta a la fecha lmite, casos de uso con baja prioridad debe ser desechada a partir de la lista de tareas. Este procedimiento debe repetirse hasta que la lista de casos de uso cumple la fecha lmite del proyecto. Para obtener ms informacin acerca de esto, eche un vistazo al documento de estimacin de la duracin del mismo autor. Prioridad El funcional que toma decisiones tiene que determinar la prioridad de cada caso de uso y cada historia. La prioridad indica que son casos de uso que deban realizarse y que no estn en el caso de un nmero limitado de PPD. Para desplegar antes de la fecha lmite es ms importante que los detalles en la funcionalidad! Prioridad P es cuantificado con un A, B C. P = Esto es una funcionalidad bsica. El sistema no puede existir sin ella. P = B El sistema podra funcionar sin esta pieza de funcionalidad, pero es todava relativamente importante. P = C Si hay izquierda del PPD antes de la fecha lmite es superior, que podra ser gastado en la funcionalidad con prioridad C, pero no es un desastre si la funcionalidad no est construido. Por supuesto que tambin podra utilizar Mosc, o cualquier otra cosa. En un caso de uso, las historias pueden ser priorizados. Por lo general, la prioridad total de un caso de uso refleja el promedio de prioridad de sus historias.
Notacin de caso de uso e historias

Un caso de uso con sus historias se puede encontrar en un diseo funcional WUP en la siguiente notacin.
Ttulo Actor Condiciones previas Relaciones Descripcin Excepciones Postconditions Historias

PPD

La izquierda de campos abiertos deben ser llenadas pulg

Diagramas de Casos de Uso WUP no utiliza UML diagramas de caso de uso por defecto, ya que una de sus primeras prioridades es ofrecer un diseo funcional que se puede ajustar en el abrir y cerrar de ojos. Obviamente, se necesita ms tiempo para ajustar las imgenes que texto plano. Sin embargo, si un diseo funcional cuenta con ms de, digamos, 50 casos de uso, es aconsejable aadir estratgicamente diagramas de caso de uso para obtener una visin general de ciertas partes del proceso. Los desarrolladores de gracias. Diagramas de secuencia Un diagrama de secuencia muestra la interaccin de los actores y las entidades del problema de dominio en un caso de uso a travs del tiempo. Esta interaccin se define de forma implcita ya en un caso de uso y sus historias, pero la secuencia diagrama suministra una visin diferente en cada caso de uso. El diagrama se refiere a las clases con el uso de caso y las historias. Aparte de las clases problema de dominio, una secuencia diagrama utiliza web sistema clases si es necesario. Estos sistemas de clases se definen habitualmente en las historias que cuentan a partir de la interaccin entre la lgica de negocio y la presentacin, por ejemplo. La lgica de negocio clases por lo general, literalmente, representan el problema dominio de clases, mientras que las clases de presentacin han limitado relacionados con el sistema funciones. Estos representan el sistema de clases de objetos, como "servidor de la pgina ',' forma 'y' Client Page '. Dentro de los diagramas de secuencia Wae (Web Application Extension) de UML se usa para definir estas web relacionadas con el sistema de clases. Esta extensin utiliza metamodelo clases o estereotipos que se interponen para los objetos en una arquitectura web. Un ejemplo de una secuencia se muestra el diagrama de un caso de uso que describe una parte de un sistema de ventas en lnea.

[esta imagen se basa en una ilustracin de Martin Fowler] Requisitos del sistema Los requisitos del sistema son los requisitos tcnicos que describen las normas a las que el sistema debe cumplir. Estos requisitos del sistema no estn relacionadas con cualquier accin de un actor y son, por lo tanto se describe en el diseo tcnico. Requisitos del sistema puede ser descrito en forma de texto, y son acerca de cosas como la eleccin de la plataforma, el rendimiento y as sucesivamente. Las races El proceso descrito se basa en parte en iterativo, incremental mtodos dinmicos como Mtodo de Desarrollo de Sistemas (DSDM) y Extreme Programming (XP). Estos procesos son ampliamente utilizados en proyectos de tecnologas de costumbre, pero para la construccin de aplicaciones web un enfoque ms flexible se recomienda. El Rational Unified Process y el Proceso Unificado de ICONIX son tambin recursos de los que se basa WUP. Estos mtodos son impulsadas por UML, aunque no especialmente diseado para desarrollo web app.
No reinventar la rueda

Es una cuestin de ajuste: un mtodo no puede ser igualmente til para regular las TI y para proyectos web al mismo tiempo. Por lo tanto, los usos WUP partes de los cuatro mtodos para crear una web cumple con forma de trabajar. Aparte de esta combinacin de mtodos, el WUP mtodo se basa tambin en una amplia experiencia en el desarrollo web. Por lo tanto, WUP no pretende ser un nuevo mtodo de desarrollo, pero no es ms que

pretende ser un marco en el que la web cumple con las partes de los mtodos existentes y UML son en su conjunto. Esto se traduce en un entorno de desarrollo estructural en tanto que los codificadores y los diseadores puede ser creativo. Cuando se utiliza WUP, por favor sintase libre para ajustar el proceso a las necesidades especficas de su empresa. Mtodo de desarrollo no se exactamente satisfacer sus propios procesos, pero puede proporcionar alguna orientacin. Las especificaciones El mtodo se ha creado para servir los ms grandes proyectos web que estn dependiendo en gran medida a la lgica tcnica. El proceso se basa en una arquitectura slida fundacin. Este tipo de proyectos es preferentemente orientada a objetos (OO) y por lo general de nivel 3. En una arquitectura de 3 niveles, el software est estrictamente dividida en tres partes: la presentacin de nivel, la lgica de negocio y el nivel de nivel de datos. La separacin de estos componentes da lugar a un sistema que sea ms escalable y ms fcil de mantener.
Pequeos equipos

El WUP enfoque apoya el desarrollo en pequeos equipos mejor de los casos. El equipo desarrollador debe constar de un jefe de proyecto, dos o ms desarrolladores y al menos un funcional que toma decisiones. Si el nmero de personas en un equipo es superior, digamos, doce, sera aconsejable crear ms funciones que las habituales WUP papel definicin de cuentas.
Tiempo de boxeo

Este equipo tiene por objeto la prestacin de alguna funcionalidad dentro de un plazo determinado, que satisface las necesidades del cliente. La fecha lmite se ha fijado, pero sobre la marcha la ptima funcionalidad puede ser redefinido. El proyecto puede ser funcionalmente dirigi, en funcin de los avances del proyecto y las necesidades del cliente. Esta forma de tratar con el tiempo, los recursos y la funcionalidad se llama tiempo de boxeo. Tiempo medio de boxeo que efectivamente el tiempo y el dinero son fijos, sino que la funcionalidad vara. Cada fase del proyecto se considera como una caja de tiempo. Usualmente hay cuatro fases en un promedio web del proyecto: la fase conceptual, la fase de anlisis, la fase de desarrollo y la posterior a la fase de despliegue.

Desarrollo del proyecto


La fase conceptual

En la fase conceptual, un concepto de negocio se crea. Un concepto describe la funcionalidad del futuro sistema de comercializacin a nivel, por lo general de comercializacin de personas, en no ms de un par de pginas por escrito. En la fase de anlisis de los desarrolladores y el cliente para intentar colmar las lagunas en la funcionalidad del concepto, para crear un diseo funcional inicial, una definicin de estilo, un diseo de interaccin y un primer diseo tcnico. En la fase de desarrollo de personas realmente empezar la codificacin, pruebas y liberacin. El producto final se supone que debe ser entregado al final de esta fase. El perodo posterior a la fase de despliegue puede incluir pruebas de la versin beta, para ajustar el rendimiento, el mantenimiento y la formacin de los usuarios. Iteraciones La programacin es por lo general ms xito si se hace por etapas, con cada paso se centr en un nmero limitado objetivo fcilmente alcanzable. Por lo tanto, el proceso de desarrollo se ejecuta iterativamente. Los pasos o iteraciones se han previsto utilizar la informacin en valor para el negocio y la prioridad de las necesidades funcionales que la decisin maker suministros. Habr pequeas liberaciones para cada parte independiente del sistema, para dar una oportunidad para que la retroalimentacin. Incrementos Un sistema muy complejo requiere un enfoque incremental. Un incremento es un perodo despus de que una versin funcional del sistema es puesto en libertad. Despus de terminar un incremento, el que toma decisiones orgnicas y el cliente puede decidir si y cmo continuar. Dentro de un incremento del desarrollo siempre se ejecuta iterativamente.
El Lenguaje Unificado de Modelado (UML)

El inicio de un proyecto se caracteriza por la determinacin del problema de dominio. Las entidades del problema de dominio se definen y se utilizan para construir un modelo de dominio de la clase de acuerdo con el estndar UML. A partir de este modelo las clases de objetos y modelo de datos se derivan. El comportamiento externo que el sistema debe exponer se describe en casos de uso. Casos de uso son pequeas unidades de funcionalidad, que describe la interaccin entre un actor fuera del sistema y el negro-box propio sistema. Casos de uso son fciles de leer, tanto para los clientes y desarrolladores. La decisin maker funcional define los casos de uso. Despus de eso, los desarrolladores y el que toma decisiones orgnicas determinar las acciones dentro del sistema que conduzca a la realizacin del caso de uso. Estas acciones se llaman historias. Las historias son la prioridad y estima en complejidad. Los desarrolladores individuales a firmar en la realizacin de un uso especfico de su caso y las historias. El vnculo entre casos de uso e historias se describe con ms detalle utilizando los diagramas de secuencia. Estos pueden ser modelados usando la Wae (Web Application Extension) para UML.

Utilice los casos e historias de suministro una herramienta sencilla para el director del proyecto y funcional que toma decisiones para controlar y medir los avances del proyecto. Desde el tiempo necesario para hacer realidad las historias se estima, es muy fcil de calcular la cantidad total de das necesarios para terminar el proyecto. La duracin de un proyecto puede calcularse utilizando los miembros del equipo de 'las capacidades individuales o de desarrollo de velocidad. Aparte de casos de uso, el sistema debe ajustarse a los requisitos del sistema tcnico. Estas limitaciones son generalmente expresado en una declaracin que comienza con: "El sistema.". Equipo de WUP El equipo debe constar de un jefe de proyecto, dos o ms desarrolladores y al menos un funcional que toma decisiones. Los desarrolladores pueden ser tcnicos desarrolladores, diseadores o texto escritores. Desarrolladores versus el mundo Estas son las personas que hacen el anlisis, el desarrollo y la mayor parte de la etapa posterior a la fase de despliegue del trabajo del proyecto. La fase conceptual, sin embargo, se puede tomar el cuidado de comercializacin de personas, aunque el equipo de desarrolladores podra ser capaz de hacer esto tambin y definitivamente debe ser incluido en el proceso. Si hay ms de dos desarrolladores de una disciplina, se recomienda designar a uno de los desarrolladores a ser el lder del equipo de esta disciplina. Esta persona es preferiblemente un desarrollador de alto nivel. El funcional que toma decisiones es, o como funciones, el cliente. l es el responsable de determinar los requerimientos del negocio y tiene que tomar todas las decisiones que tienen algo que ver con las reglas de negocio. Los requisitos de un proyecto se describen en el diseo funcional. Un miembro del equipo ha sido designada para ser responsable de este diseo funcional, preferentemente el que toma decisiones funcionales, o al menos alguien que continuamente mantiene en contacto con l. Todo el mundo tiene que cumplir una funcin especfica, pero es importante recalcar que estn todos en el mismo equipo y comparten el mismo objetivo. Quin est haciendo qu? Los miembros del equipo tienen tareas concretas. Estas tareas se enumeran a continuacin. Se definen sobre la base de las principales hiptesis de que la gente de negocios que las decisiones empresariales, tcnicos y la gente hace las decisiones tcnicas. Los gestores de proyectos equilibrio de poder entre los desarrolladores y gente de negocios. Los miembros del equipo tienen tareas especficas, as como derechos. El que toma decisiones orgnicas y gerente del proyecto tienen el derecho: tener un plan general (a saber lo que se puede lograr, cuando ya qu costo);

a cambiar de opinin acerca de los requisitos y prioridades (dentro de un cuadro de tiempo); a ser informado de los cambios de horarios.

Los desarrolladores tienen derecho: a saber lo que se necesita, con visin clara acerca de la prioridad; para pedir y recibir ayuda de desarrolladores de alto nivel y funcional que toma decisiones; para realizar y actualizar sus propias estimaciones. El que toma decisiones funcionales El papel funcional de decisin fabricante se define sobre la base de los principales hiptesis de que la gente de negocios que las decisiones empresariales, tcnicos y la gente hace las decisiones tcnicas. El funcional que toma decisiones es la persona que define las prioridades de negocio y los requisitos. Debe ser alguien que conozca el problema de dominio o permanece en estrecho contacto con alguien que hace. Preferentemente, el funcional que toma decisiones es un representante del cliente. Si el tamao del proyecto lo justifique, ver para conseguir un representante permanente al cliente en el lugar. Si esto no es posible, intente esto: Trate de conseguir a alguien para representar al cliente a nivel local; Trate de conseguir que el cliente sobre el terreno en las sesiones; Ir y visita a menudo el cliente; Release cdigo con frecuencia para el cliente; Esperar a tener malos entendidos! En la prctica, puede ser til para tener un sistema funcional de diseo tienen el papel funcional de adoptar decisiones. Para los proyectos que no tienen una relacin directa del cliente, este es el camino por recorrer. Para los proyectos que hacer, porque es fundamental que el diseo funcional tiene una comunicacin permanente con la posibilidad real que toma decisiones orgnicas en el lugar del cliente. El director del proyecto En un WUP proyecto, el proyecto de gestin de papel es muy centrado en la gestin de Lo que es ms importante, el xito del proyecto depende eliminacin de cualquier cosa, desde el camino del equipo que de brindar una buena aplicacin web a tiempo. Necesitas algo? Pregntele al gerente Buscan a cabo por las cosas que estn ralentizando el equipo, agilizar las compras, la organizacin de reuniones, informar de los resultados; el director del proyecto no es ms que la persona que facilita el proceso del equipo. l es tambin el que se refiere a las finanzas y todas esas cosas que un desarrollador no le importan. Es muy importante para un director de proyecto WUP para saber qu no hacer. En lo importante, pero es muy per se. de administrador de la no contribuye al objetivo

que respecta al proceso de planificacin tcnica, diseo, ensayo, codificacin, y la liberacin: los administradores no hacen estas cosas directamente. El director del proyecto hace estas cosas por hacer, coordinar su tarea, e informar los resultados. Estas son tareas que consumen mucho tiempo como es, y significa que un jefe de proyecto no puede ser el que toma decisiones funcionales (que bien podra ser un trabajo completo). Adems a partir del momento en cuestin, un director de proyecto tiene completamente diferentes motivaciones que el cliente. El director del proyecto se centra en la eficacia del proceso, en lugar de a las prioridades de las actividades. Los requerimientos del negocio y la prioridad tiene que ser determinado por el experto, no ocupado por un gerente. Los desarrolladores El tamao del equipo de desarrolladores que, evidentemente, depende del alcance del proyecto. Si un proyecto es lo suficientemente grande, un equipo puede consistir de los siguientes miembros.
El equipo tcnico

Un equipo tcnico debe constar de codificadores y al menos una tcnica de alto nivel, que actuar como responsable tcnico del equipo lder. Las limitaciones tcnicas y el diseo detallado del sistema estn documentadas en el diseo tcnico, de preferencia inicialmente construido por los superiores. Todos los miembros del equipo de desarrollo son responsables de esta tcnica de diseo durante la fase de desarrollo. Sin embargo, una persona ha sido designada para que eche un ojo a los desarrolladores los esfuerzos para mantener el diseo tcnico al da durante el proyecto. Esta persona es preferentemente el jefe del equipo tcnico, pero no necesariamente. Otro miembro del equipo de tcnicos verifica la base de datos y procedimiento almacenado guiones cada semana, segn un procedimiento especfico que se describe ms adelante en este documento.
Equipo de diseo

Un equipo de diseo debe constar de los diseadores y al menos un diseo de alto nivel, que actuar como el diseo del equipo lder. El proceso de diseo se describe ms adelante en este documento.
Interaccin diseador

Diseo funcional y diseo tcnico no satisfacen las necesidades de los desarrolladores. Lo que echamos de aqu es un diseo de interaccin, que describe una intuitiva pgina de flujo y dnde encontrar qu parte de la funcionalidad. Para esta oferta, necesitamos un diseador de interaccin. Se trata de una persona que es perfectamente capaz de leer el diseo funcional, y puede hablar con el equipo tcnico para verificar si sus ideas son tcnicamente posibles. Debe tener experiencia en el uso de interfaces web. Sin embargo, no puede ser la misma persona que hizo el diseo funcional: un diseo

funcional conoce perfectamente la funcionalidad: cualquier interfaz de hacer, por lo que a l se refiere. Esto implica que el diseo funcional no puede disear una interfaz ms intuitiva. Lo mismo puede decirse de tcnicos las personas: ellos saben cmo los sistemas de trabajo, que no se puede decir para el usuario final del sistema. Por lo tanto, un diseador de interaccin no debe ser demasiado tcnico.
Texto escritores

Dependiendo del alcance del proyecto y los acuerdos con el cliente, texto escritores son necesarias para el suministro de contenidos. Texto escritores de la Internet son subestimados en gran medida: en la final, el contenido es lo que atraer a los usuarios finales del sistema web. Sin embargo, es prctica comn que el propio cliente se encarga del contenido. Obviamente, las grandes empresas quieren que su propio pueblo para llenar y actualizar los sitios web pblicos. Disear En WUP, no hay diferencia entre los diseadores y programadores: estn todos los desarrolladores en el equipo WUP. Esto, por supuesto, implica que los diseadores tendrn que leer las tcnicas de diseo, al menos parcialmente, as como el diseo funcional. Sus comentarios no harn sino aumentar la calidad global de la solicitud. Sin embargo, aparte de un funcionales y tcnicas del diseo, los diseadores necesitan su propio conjunto de herramientas y los medios de documentacin. Mapa de navegacin Un mapa de navegacin es una vista de la aplicacin web que muestra el nivel especfico presentacin pginas HTML en un diagrama de rbol jerrquico. Este mapa, naturalmente, se desarrolla el uso de caso modelo. Mapas de navegacin se puede hacer para los diferentes niveles de usuario, o incluso actor especfico si es necesario. Por ejemplo, el mdulo de administrador de una solicitud tiene una navegacin completamente diferente que el mapa de usuarios regulares del sistema. El mapa de navegacin se pueden encontrar en el diseo funcional. Diseo breve El diseo se describe breve de alto nivel de interfaz de usuario directrices. El diseo est creado por un diseador y el cliente directamente. Normalmente, los creativos breve define: el estado de nimo del sitio; si el sitio se utilizan marcos; cualquier color limitaciones, el sitio tendr; si procede: una gua de normas grficas. Cuestiones tcnicas como el tipo de navegadores que se utilizarn y la velocidad de conexin de la mayora de los usuarios ser en el diseo tcnico. Diseo plantilla

Desde el diseo funcional, los principales elementos web se puede extraer que tienen que ser diseadas. Web elementos son el conjunto de componentes grficos estndar que regresar en casi todas las pginas. Estos elementos y el diseo proporcionan la informacin de que los diseadores hacer el diseo. El diseo consta de una o ms pginas web que contienen los principales elementos web que se utilizarn. El diseo est construido con el nico propsito de tener el cliente tome una decisin sobre el diseo creativo direccin. Diseo comps Diseo comps constar de maquetas de lo que el sitio puede verse as, sobre la base de la plantilla de diseo. Estos modelos suelen ser imgenes, con un navegador alrededor. La oferta comps el diseador de interaccin con un estilo estructural de directriz, y el cliente con la felicidad (creme). La interaccin y el diseo de prototipos De los casos de uso, el mapa de navegacin y el diseo comps, un diseo de interaccin se hace. Estos son preferentemente imgenes en blanco y negro que muestran la funcionalidad del GUI de cada uno y cada una de las pginas. Los colores que desdibujar la opinin del cliente sobre lo que es importante aqu: la construccin de una intuitiva interfaz de usuario. Si el alcance del proyecto lo justifica, HTML prototipos de seguir el diseo de interaccin. Estas son las pginas HTML plano sin ningn tipo de diseo que reflejan la funcionalidad del diseo de interaccin, pero que tienen una gestin de transacciones simuladas (es decir, sin lgica de negocio real, slo una simulacin). Esto da una visin ms clara an en el GUI. Diseo de planificacin de la produccin Fija las estimaciones pueden hacerse para la creacin de un mapa de navegacin, el diseo, diseo, comps, la interaccin y diseo de prototipos. Planeando para el diseo de produccin de una manera estructurada slo es posible despus de la finalizacin de la fase inicial de diseo. A partir de ese momento, los diseadores (o quizs plantilla HTML constructores, dependiendo de su capacidad) saben exactamente qu hacer. Esto significa que por cada pgina que tiene que ser construido, el nmero de la PPD se calcula por el diseador que se suscribe en la pgina. Riesgos Es muy importante que se tengan en cuenta el riesgo en un sistema incluso antes de empezar a desarrollar. Hay algunos tipos de riesgo en cada proyecto que pueden ser clasificados.

Requisitos de riesgo - Desastres escenarios que se han esbozado en una etapa temprana de la que toma decisiones funcionales. l sabe mejor lo que podra ser la peor cosa que suceda a su empresa. Especial casos de uso que describen estas catstrofes tienen la ms alta prioridad. Tecnolgico de riesgo - La tecnologa que se elija o requerido se adecue a los requisitos funcionales? Puede entregar las funciones que los usuarios necesitan?

Habilidades de riesgo - Son los miembros del equipo disponible capaz de construir una aplicacin? Si no es as, entonces no empiece, pero la demanda de ms o de otros miembros del equipo. Contenidos riesgo - Hay alguna las fuerzas polticas que pudieran ponerse en el camino de su proyecto, consecuencias jurdicas o personas con agendas ocultas? Piense en este tipo de riesgo, y slo el documento que si no agrandar el riesgo de hacerlo!

Documentacin del proyecto.


Proyecto Las fases de un proyecto WUP se muestran a continuacin, incluyendo lo que ocurre en estas fases. Tenga en cuenta que las etapas como se dice aqu no son lineales en el tiempo, sino que consiste simplemente de eventos recurrentes. Fase conceptual

Crear concepto de negocio Verificar alcance tcnico Considere la posibilidad de riesgo contextual Obtener el compromiso patrocinador

Fase de anlisis

Definir problema de dominio Diseo funcional o Definir las clases de dominio o Definir casos de uso o Definir historias Considere las necesidades de riesgo Diseo inicial Prototipos Diseo tcnico o Definir la base de datos inicial o Definir el modelo inicial de clase Considere la posibilidad de riesgo tecnolgico Crear un equipo Considerar las aptitudes de riesgo Definir incrementos Definir fechas Obtener el compromiso patrocinador

Fase de desarrollo

Inicio incremento Diseo de produccin Redefinir casos de uso

Pick caso de uso Iniciar la realizacin de una historia Definir una prueba Ejecutar una prueba Finalizar historia Finalizar caso de uso Integrar el sistema Ejecutar las pruebas de integracin Liberar Evaluar (total de diseo) Optimizacin Fix-se desliz a travs de errores Aceptacin de prueba Al final de su incremento en libertad Despliegue Obtener el compromiso de patrocinar nuevo incremento (opcional)

Post-fase de despliegue

Evaluar fase de desarrollo Capacitar a los usuarios (opcional) Mantenimiento

Cuando fases de cambio, el cliente debe estar en condiciones de cancelar la continuacin del proyecto. Cada una de las fases puede considerarse como un cuadro de tiempo y cada una de ellas puede ser planificada y en el costo estimado por separado. Durante las fases, el cliente debera participar estrechamente y capaces de dirigir el proyecto en todo momento. Fase conceptual WUP no define gran parte de cmo trabajar en esta fase, ya que su filosofa es la de dejar hacer en todo el mundo que l es mejor. Sin embargo, hay un par de cosas que deben mencionarse. La fase conceptual no requiere un equipo especfico. Dependiendo de la empresa, negocio o alcance del cliente, las personas que crean un concepto que se eligen. Del mercado y los desarrolladores no se mezclan Por lo general, se trata del mercado. Su ventaja es que pueden crear conceptos sin preocuparse por cuestiones tcnicas, pero su ventaja es tambin su desventaja. Una gran cantidad de proyectos web estn en mal estado debido a las empresas de marketing y desarrollo de aplicaciones apenas mezcla. Para evitar que a partir de esto, es importante abordar el alcance tcnico de un concepto en una etapa temprana. Esto significa que al menos un miembro del departamento tcnico debe ser incorporado en el proceso conceptual, para verificar si es tcnicamente

posible construir una aplicacin que se inscribe en el concepto. No firme promesa o nada hasta que esta se ha verificado! El cliente reglas (literalmente) En la fase conceptual, es tan importante como en las fases posteriores a recordar que el cliente para quien el concepto es creado conoce mejor su negocio. Por eso, cuando el pensamiento de un concepto de negocio, la comunicacin con el cliente es la clave. Olvdese de las cosas Web La otra cosa es: no trate de hablar de botones, la navegacin Web o cualquier cosas por el estilo en un concepto de negocio. Se supone que ser un concepto, no constituye una solicitud de diseo. Esperar con la excelente detalles hasta la fase de anlisis comienza, y dejar que los desarrolladores de definir ellos: ellos saben mejor cmo hacerlo. Si no se adhieren a la imagen grande, para asegurarse de que el cliente recibir informado falsamente, porque los detalles del cambio en el proceso de todos modos. Por lo general, los mejores conceptos de negocio se puede describir en tan slo un par de pginas escritas. Obviamente, el final de la fase conceptual requiere el compromiso de patrocinar un proyecto. Fase de anlisis La fase de anlisis tiene la prestacin de llegar a un punto de partida para el resto del proyecto. Recuerde que no conduce a un plan fijo! Es slo una primera gua tipo de cosas. Tanto los clientes y los desarrolladores se cambien de opinin ms adelante, puede apostar a eso. Problema de dominio Lo primero que hay que hacer en la fase de anlisis es determinar el problema de dominio en detalle. El que toma decisiones orgnicas y el cliente se sientan juntos y escriba una descripcin del problema de dominio. Esta descripcin no debera ser superior a una pgina. Un primer problema de dominio de clase diagrama se puede construir con el cliente, ya que l conoce su propio negocio mejor. Desde el problema de dominio y el concepto, una lista de exigencias funcionales, se deriva que describe lo que la aplicacin debe hacer para encajar el concepto dentro del dominio. Estos requisitos se describen utilizando casos de uso e historias, que son la prioridad. Esta priorizacin debe conducir a la decisin de entregar el sistema en incrementos o no, dependiendo de los deseos del cliente. Esperar con las fechas exactas y detalladas de la funcionalidad de estos incrementos despus de que el diseo funcional se construye. Ahora es el momento de poner juntos un primer equipo de desarrolladores que ayuden a construir la funcional, tcnica, interaccin y diseo creativo. Estas son las necesidades

desnudo para un desarrollador a comienzo de la siguiente fase: la fase de desarrollo en s. Diseo funcional De la lista de requisitos y el diagrama inicial de clase, un diseo funcional se deriva, de preferencia por el fabricante de decisin funcional (es decir, si l no es el cliente). Esto puede hacerse utilizando el modelo FD documento por el mismo autor. Este es un primer FD, de que un primer proyecto de plan se har. En este FD problema de dominio de clase, caso de uso conjunto, caso de uso y diagramas de secuencia estn presentes. Tras la finalizacin de la FD inicial, el plan de una reunin con los desarrolladores para discutir el contenido. Que ellos estimar la complejidad de cada caso de uso y de historia. Esto proporcionar una idea en la duracin del proyecto. Verificar la exactitud de la FD con el cliente directamente. Inicial de diseo creativo Desde la interfaz de usuario es realmente importante, el aspecto y tacto de la aplicacin debe determinarse en una etapa temprana del proyecto. Paralelamente a la construccin de casos de uso, la interfaz de usuario inicial directrices deben determinarse.
El diseo breve

Estas directrices tienen mucho que ver con la emocin que los usuarios del sistema deben experiencia. Por lo tanto, lo mejor es enviar a uno de los diseadores de hablar con el cliente directamente. Una cosa es tener un sistema funcional que toma decisiones en el equipo, pero para traducir la emocin no es posible. Este diseador regresa con suficiente informacin para completar el diseo. Por cierto, los lmites tcnicos del sistema asociado con el diseo (por ejemplo, hacer que los navegadores de los usuarios de apoyo) no debe necesariamente ser determinada por este diseador, sino que debera estar ya en el diseo tcnico. El uso de la Diseo Breve debera dar lugar a uno o un par de pginas que representan la sensacin de que el cliente quiere que su aplicacin a tener. En estas pginas se llaman as el diseo de plantillas. En esta plantilla, los ms importantes elementos de diseo se muestran. Se recomienda que los que slo un tipo de diseo se hace, que deben adaptarse en funcin de los clientes desea. Si ms de un dibujo o modelo se ofrece, el cliente se aplica principalmente a una combinacin de todos modos. Se trata de una gran cantidad de trabajo adicional para los diseadores y da una mala ventaja competitiva para el proceso creativo.
Diseo comps

Por ltimo, un par de pginas del futuro sistema son simuladas, que se utilizan como gua por el diseador de interaccin para construir su diseo de interaccin. Estas maquetas de la futura web GUI se llaman diseo comps.

La interaccin y el diseo de prototipos Los casos de uso (no necesariamente las historias) y diagramas de secuencia son entregados a una persona creativa en el equipo que es o acta como un diseador de interaccin. Utiliza los casos de uso para construir un esquema de la navegacin del futuro sistema, el mapa de navegacin. La mayora de las pginas de este mapa ya estn definidos funcionalmente en los casos de uso o en la secuencia de diagramas, especialmente si la Wae para UML se ha utilizado. El diseador de interaccin entonces compone imgenes de cada uno y cada una de las pginas. l se define cuando los campos de entrada son, en qu orden, donde estn los botones, los logos y todo lo dems no se me ocurre ahora mismo. Estas imgenes, preferentemente digitalizadas en virtud del calendario, pero la presin a veces incluso dibujado a mano, se llaman la interaccin de diseo. El Diseo de Interaccin es una caracterstica clave, y no slo en WUP. Durante este proceso, el diseador de interaccin mantiene un ojo sobre el estilo de directrices tal como se definen en los comps de los diseadores creativos. El siguiente paso es crear prototipos funcionales para cada una de esas pginas. Este proceso da lugar a una serie de semi-interactivo pginas HTML que la oferta de orientacin para los desarrolladores que tienen que construir parte de la presentacin de la solicitud. Tome buena nota de las repercusiones de la construccin de estos prototipos en el horario: si el calendario es apretado, utiliza el "papel" interaccin diseo y olvidarse de los prototipos. Tanto el mapa de navegacin y la interaccin de diseo son una herramienta poderosa para mostrar al cliente lo que su aplicacin tendr el siguiente aspecto. Deje que el funcional que toma decisiones sobre ellos y modificarlos si es necesario. Tcnicas de diseo Junto con el diseo inicial, las tcnicas de diseo se puede iniciar (por ejemplo, utilizando la plantilla de documento TD). Esto se puede hacer por cualquiera de los tcnicos desarrolladores. Sin embargo, esta persona debera haber participado en las reuniones que se acerca el diseo funcional. El diseo tcnico es relativamente simple: la clase modelo se define directamente el problema de dominio de clase y el diagrama rudimentario funcionalidad del sistema. Lo mismo ocurre con el modelo de datos. No sirve de nada para definir con ms detalle. El diseo tcnico ser una directriz inicial, pero a medida que el proyecto rollos que servir cada vez ms como la documentacin en lugar de una directriz. En la prctica, las soluciones para los problemas se pueden descubrir en el trabajo de quienes son los mejores en esto: los desarrolladores. As, durante el desarrollo del diseo tcnico seguir los desarrolladores, no al revs. Una persona de la tcnica de los desarrolladores se debe dar la responsabilidad de mantener un ojo en el TD mantenerte al da durante el proyecto. Cada desarrollador es responsable de los cambios en el documento TD: cada vez que cambia algo que afecta a la TD, deber cambiar el TD. Planificacin incrementos

Tras la finalizacin de FD, TD y diseo inicial, una detallada planificacin del proyecto puede ser construido. La decisin maker funcional define al comienzo de un incremento de casos de uso que se debe construir, sobre la base de valor del negocio, la complejidad y la velocidad de realizacin de los desarrolladores. Un incremento se ha previsto utilizar el siguiente conjunto de acciones:

Determinar el uso que los casos e historias que usted necesita para terminar con un producto exitoso; Deje que el designado personas de la tercera edad estimar el PPD para la historia y cada caso de uso; Prioridades de casos de uso e historias; Estimacin de la velocidad de realizacin para cada miembro del equipo; Definir un incremento fecha; Elige los casos de uso que se ajustan a la duracin de desarrollo de acuerdo a la capacidad del equipo y la fecha lmite, a partir de los que con ms alta prioridad; Algunos anlisis de riesgos basado en la funcionalidad elegido (lo que puede salir mal?).

No se olvide que el primer perodo de liberacin requiere ms tiempo que el resto de ellos, porque un par de cosas inicial hay que tener cuidado de. Piense en las clases iniciales, base de datos y, por supuesto, los entornos de desarrollo tcnico, software y as sucesivamente. Por otra parte, los ciclos de liberacin interior puede ser previsto. Interna son las emisiones las emisiones en que el sistema est desplegado en el entorno de prueba sobre una base regular. En el momento del despliegue, el desarrollo se detiene. Este es el comienzo de una integracin a corto y funcional perodo de prueba en la que todo el equipo participa, evitando as acabar con una carga de errores al final del incremento. Se recomienda hacer una prueba de liberacin, al menos, cada dos semanas, o incluso cada semana cuando se encuentre en un apretado calendario. Fuente: http://translate.google.com/translate? hl=es&sl=en&u=http://www.centrical.com/category/15.aspx&sa=X&oi=translate&resnum= 1&ct=result&prev=/search%3Fq%3Ddefine%2BWUP%26hl%3Des

S-ar putea să vă placă și