DSDM (Mtodo de Desarrollo de Sistema Dinmico).

El DSDM empez en Gran Bretaa en 1994 como un consorcio de compaas del Reino Unido que queran construir sobre RAD [N. del T. Desarrollo Rpido de Aplicaciones] y desarrollo iterativo. Habiendo empezado con 17 fundadores ahora tiene ms de mil miembros y ha crecido fuera de sus races britnicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros mtodos giles. Tiene una organizacin de tiempo completo que lo apoya con manuales, cursos de entrenamiento, programas de certificacin y dems. El mtodo empieza con un estudio de viabilidad y negocio. El estudio de viabilidad considera si DSDM es apropiado para el proyecto. El estudio de negocio es una serie corta de talleres para entender el rea de negocio dnde tiene lugar el desarrollo. Tambin propone arquitecturas de esbozos del sistema y un plan del proyecto. El resto del proceso forma tres ciclos entretejidos: el ciclo del modelo funcional produce documentacin de anlisis y prototipos, el ciclo de diseo del modelo disea el sistema para uso operacional, y el ciclo de implantacin se ocupa del despliegue al uso operacional. DSDM tiene principios subyacentes que incluyen una interaccin activa del usuario, entregas frecuentes, equipos autorizados, pruebas a lo largo del ciclo. Como otros mtodos giles usan ciclos de plazos cortos de entre dos y seis semanas. Hay un nfasis en la alta calidad y adaptabilidad hacia requisitos cambiantes. No he visto mucha evidencia de su uso fuera del Reino Unido, pero DSDM es notable por tener mucha de la infraestructura de las metodologas tradicionales ms maduras, al mismo tiempo que sigue los principios de los mtodos giles. Parece haber una pregunta en si sus materiales animan ms de una orientacin al proceso y ms ceremonia de lo que me gustara. La metodologia DSDM es caracterizada por su rapidez de desarrollo atendiendo a las demandas de tecnologia de forma eficaz y eficiente previendo que transcurra mucho tiempo y la tecnologia cambie. SEGUNDA PEGADA Es una metodologia agil situada dentro de las RAD (rapid aplication development), es ideal para proyectos de sistemas de informacion cuyos presupuestos y agendas son muy apretadas. DSDM consiste en tecnicas de desarrollo y gestion del proyecto en la misma metodologia. Las caracteristicas de DSDM son: Trabajo en equipo tanto los desarrolladores, los usuarios y los Stakeholders. El equipo de desarrollo puede tomar sus deciciones sin depender de autorizaciones de sus superiores. El desarrollo es iterativo e incremental El equipo de desarrollo debe realizar entregas cortas pero frecuentemente, estas entregas deben ser funcionales. Todos los cambios pueden ser revertibles, es decir, debemos tener una linea base y a partir de ella crear funcionalidad, pero si no tenemos los resultados deseados podemos regresar a la linea base nuevamente. La verificacion de calidad debe existir a lo largo del proceso de desarrollo y no solamente en al final del proyecto.

Existen consideraciones de importancia las cuales son: Ningun sistema es construido a la perfeccion en el primer intento. La entrega del proyecto debera ser a tiempo, respetando presupuesto y asegurando la calidad. DSDM solo quiere que se complete la iteracion con la funcionalidad suficiente como para que inicie la siguiente iteracion. DSDM es utilizado en sistemas TI pero tambien pudiera ser utilizado para proyectos en donde se requiera cambio de algun sistema aunque no sea TI. La evaluacion de riesgo debe estar enfocada en entregar funcionalidad no en el proceso de desarrollo La estimacion debe estar basada en funcionalidad del negocio. Estudio de Viabilidad: estudio de requerimientos (humanos, materiales y financieros) y los problemas de la empresa o cliente. Estudio de la Empresa: como planificar las actividades de la empresa. Iteracion del Modelo Funcional: plantear un modelo previo que de solucion aceptable a la problematica, esta es la etapa de diseo. Diseo e Iteracion de Estructura: se realiza la codificacion de la solucion, se prueba paralelamente la calidad del producto y se documenta el manual de usuario y tecnico. Implementacion: entrega del producto al cliente o usuario final.

Las fases de DSDM son:

Necesidad de un enfoque DSDM.

En un sistema normal un modelo de cascada puede funcionar bien. El cliente puede definir sus necesidades de diseo, tal vez tambien enviar su especificacion de requisitos para la seleccin de

proveedores. Sin embargo esto trae consigo todos los problemas que DSDM trata de evitar: la falta de participacin de los usuarios, limitan la oportunidades de cooperaciny colaboracin, los sistemas de baja calidad que no cumplen con los requisitos de los usuarios, etc todos estos son problemas que los grupos han encontrado. Entonces no tiene sentido cambiar el paradigma y encontrar un enfoque diferente? Uno donde los usuarios puedan participar en todo, cuando existe colaboracin y cooperacin, donde los productos son aptos para el proposito, por que la pureba est integrada. Pero no hay nada nuevo aqu por que DSDM aboga esto en sus proncipios y factores criticos de exito. Es suficiente operar de acuerdo a una copia de un manual de DSDM? Posiblemente si, pero el grupo de trabajo debe identificar las areas donde se requiere total cuidado y atencin, ofrece algunas orientaciones en estos ambitos.

Areas claves a considerar.

Uno de los factores de xito de DSDM(MCA) es la co-localizacin. Esto obviamente no es posible en un entorno normal. Por lo tanto, algunas reas claves que deben considerarse para lograr este CSF medida de lo posible se plantean en un entorno, en particular: Los contratos de gestin que apoya una relacin de colaboracin. Cmo lograr una buena comunicacin y comprensin en un ambiente cultural diverso. Garantizar la calidad del producto y comprobar que apunta ("la entrega a tiempo")rgimen.

Aplicacin de los principios DSDM.

En esta seccin vamos a explorar cmo los principios de DSDM puede ayudar y orientar a las personas que trabajan dentro de un entorno. A veces, una aplicacin ligeramente diferente de los principios se pueden aplicar. La clave del xito en la aplicacin de los principios es que las organizaciones deben comprender DSDM. Esto puede significar que las organizacin debe ser entrenado en DSDM antes que el trabajo empiece: la organizacin debera estar plenamente familiarizada con DSDM.

Participacin de los usuarios activos es imprescindible.

La lejana del equipos, significa que la participacin activa puede ser difcil, no slo para los usuarios, sino tambin para los desarrolladores, que pueden llegar a estar muy aislado de los impulsores del negocio. La clave del xito de DSDM ser la eliminacin de este aislamiento siempre que sea posible. Ms tarde, exploraremos las tcnicas de comunicacin, pero nos concentramos en los equipos desde aqu. Como en el estndar DSDM, cada intento se debe hacer funcionando como un solo equipo. El siguiente diagrama ilustra cmo se puede lograr.

Nota: Una persona puede tener ms de un papel y las funciones no son necesariamente a tiempo completo. El desafo es entender cmo conseguir una buena relacin de trabajo(y comunicacin), en particular entre el usuario y los desarrolladores.Todos los miembros del equipo, incluido el usuario deben participar en todo, incluidas las reuniones de control, las reuniones de revisin de prototipos, talleres, etc.

Los equipos de DSDM deben estar facultados para tomar decisiones.

Este principio de DSDM no cambia en un proyecto, pero es tal vez difcil de lograrlo a travs de diferentes entornos culturales. A menudo, el empoderamiento es rechazado y los desarrolladores slo quiere hacer "como usted dice". Buscar todas las maneras de inculcar la cultura de empoderamiento como sea posible Utilizar desarrolladores en un lugar durante un perodo prolongado puede funcionar bien, ya que la confianza crece.

Infundir confianza.
Si los desarrolladores no son parte de la organizacin, no pueden tener mucho o incluso algn conocimiento del negocio, o su conocimiento no est relacionado especficamente con esta organizacin. El conocimiento del negocio y por lo tanto, la confianza se pueden acumular en el entorno despus de una larga relacin, pero se perdera la organizacin en caso de disolucin. El mensaje clave es la primera vez, que requerir un esfuerzo adicional para lograr un buen nivel de conocimiento del negocio, los compromisos posteriores deberan ser ms fciles. Como siempre, las personas que hacen negocios relacionados con las decisiones deben ser los representantes de las empresas y, por el contrario, los tcnicos son los mas aptos para tomar

decisiones tcnicas.

La atencin se centra en la entrega frecuente de productos.

En un proyecto de DSDM ideal, el Embajador de usuario a ver que el sistema evolucione casi todos los das y la entrada continua de su desarrollo a travs de seruna parte fundamental del equipo de desarrollo. Puesto que los usuarios estn lejos de Embajador del desarrollo, es importante que vean los productos intermedios con tanta frecuencia como sea posible para demostrar el progreso en la direccin correcta. Las entregas frecuentes son tambin una herramienta valiosa para el director de proyecto para que pueda interpretar nuevos productos, aprobando en el sentido del progreso. Tambin puede controlar el progreso con reuniones de seguimiento para mantener el desarrollo en curso,con la participacin de todos los interesados, en particular, del usuario. Estos mecanismos proporcionan un fuerte control en los desarrollos, ya que evitar el "agujero negro", donde no aparece nada hasta que todo el desarrollo se ha completado, y por lo tanto ayudar a asegurar que el desarrollo va a cumplir con los requisitos.

Aptitud para el uso empresarial es el criterio esencial para la aceptacin de los entregables.
Este principio es muy importante en un entorno de desarrollo, ya que garantiza los criterios de aceptacin se entiende y se acuerda. Estos criterios sern la base para las pruebas y revisiones. Para los entornos de supervisin, las revisiones suelen ser electrnicos (envo de prototipos a un sitio local, revisar los comentarios y enviar de vuelta), sin embargo, esto requiere de herramientas tales como una sala de proyectos virtuales, videoconferencia, etc

En el desarrollo Iterativo e incremental es necesario converger en una conjunto preciso de soluciones empresariales.
Este principio elimina las ambigedades, asegurando retroalimentacin frecuente y general en la comprensin de los requisitos. Tambin ofrece la oportunidad de decidir si el proyecto ha conseguido beneficiar a las empresas lo suficiente. Sin embargo, es importante que la tecnologa y los soportes de comunicacin.

Todos los cambios durante el desarrollo son reversibles.

Este principio es fundamental para la gestion, en mltiples sitios de desarrollo se requiere una fuerte gestin de la configuracin y las herramientas de configuracin de gestin disponibles para ser utilizada por todos los miembros del equipo donde quiera que estn. Contratos con partes del entorno debe permitir cambios de lo contrario puede haber costos asociados con ello. Esto, entre otras razones, implica la necesidad de un contrato de colaboracin, establecido durante los estudios de viabilidad o de negocios.

Los requisitos son la lnea base a un alto nivel.

Los requisitos son la base del contrato con la empresa en el entorno y por lo tanto, la lnea de base se vuelve an ms importante. La participacin de la parte de gestin en el desarrollo de la lista de requisitos priorizados sera muy ventajoso. En lugares de trabajo por separado, no se dan cuenta de las diferencias de interpretacin que se estn arrastrando. La visibilidad y la comprensin comn son esenciales, por lo tanto, los requisitos generales deben estar disponibles, y deben ser entendidos por todos los miembros del equipo,

haciendo hincapi en la importancia de la comunicacin entre el visionario, el usuario y los desarrolladores, y la necesidad de un sistema electrnico para el almacenamiento de los requisitos que se encuentre disponible en todos los lugares. Los requisitos por escrito pueden ser difciles de entender, especialmente teniendo en cuenta las diferentes culturas e idiomas. Por lo tanto, es importante que el usuario y otros expliquen los requisitos para los miembros del equipo en todos los sitios, entre ellos los representantes del equipo de desarrollo. En este trabajo, estos representantes se les llama "Los desarrolladores embajadores". Esta funcin se inicia en el estudio de negocios o, posiblemente, la iteracin modelo funcional, y es importante a travs de la implementacin. Tcnicas tales como la prueba de aceptacin automtica (tal como se utiliza en XP) tambin ayudan a aclarar los requisitos.

Las pruebas son integrados a travs del ciclo de vida.

Este principio sirve en la gestin, las pruebas frecuentes y revisiones de los productos intermedios y prototipos permiten mantener el desarrollo en lnea con las necesidades a medida que evolucionan. Esto implica que los productos deben estar disponibles por medios electrnicos en lugares conocidos (por ejemplo, una sala de proyecciones), con herramientas electrnicas para el registro de comentarios, problemas, etc. Si se trata de una nueva relacin, la experiencia demuestra que puede ser necesario duplicar el papel de probador en la funcionalida y en la gestin. El papel de probador de funcionalidad(llamado el Coordinador de prueba en este documento) ser asesorar y apoyar al usuario en las pruebas y ayudar a coordinar las actividades de prueba entre las partes. A medida que la relacin se desarrolla, la dependencia del papel en desarrollo puede disminuir, sin embargo el papel tradicional del usuario sigue siendo el mismo con respecto a las pruebas. Los principios de las pruebas DSDM son tan importantes como siempre: Impulsado beneficio. Error cntrico. Idneo para el fin. Independiente. Repetible. Integrado a travs del ciclo de vida.

Repetible implica que el uso de herramientas automatizadas que sera til. La comunicacin de los temas es de vital importancia y puede requerir frecuentes llamadas telefnicas en momentos claves. La puntualidad de pruebas y comentarios son importantes y debe hacerse tan pronto como sea posible teniendo en cuenta las diferencias horarias. La gestin eficaz de los problemas es esencial y los problemas deben ser visibles a todas las partes interesadas. Una herramienta de prueba puede ser ventajoso en este proceso.

Un enfoque de colaboracin y de cooperacin entre todas las partes interesadas es esencial.

Campen y el patrocinio de los dos extremos.

Al igual que con cualquier proyecto de DSDM, es importante que ambas partes se han suscrito a un nivel superior para trabajar en forma colaborativa y cooperativa. En los proyectos costa afuera, el fracaso para lograr este compromiso es un riesgo importante. Como de costumbre, la educacin del personal de direccin al principio del proyecto de acuerdo a sus funciones y responsabilidades

es esencial. Por supuesto, las partes clientes y empresa tienen objetivos diferentes a los resultados del proyecto: el client se enfocar en el pago del producto entregado y la empresa desarrollo en un ajuste a los objetivos, en vez de productos comerciales desarrollados con un mnimo de los costos. El desafo ser gestionar las expectativas de ambas partes y al mismo tiempo mantener el carcter de colaboracin del equipo (s).
La empresa de desarrollo ha de participar en todo.

La formacin y retencin de un equipo de colaboracin lo antes posible es vital. En un entorno de desarrollo no todos pueden estar ubicados en lo que tenemos que asegurar que los mtodos de comunicacin estn integrados a la brevedad posible. Ya que hay ms de un equipo involucrado, el proyecto puede terminar con ms de un plan. Esto debe ser evitado. El director del proyecto debe asegurarse que todos trabajan juntos para llegar a un plan acordado, de conformidad para todos los equipos. Esto se debe teneren cuenta en todos los grupos y en todo el proyecto.

Personas.
Funciones estndar DSDM en un entorno de desarrollo.
Los principales beneficios del enfoque DSDM se derivan de los usuarios de negocio (clientes) que participa activamente en los equipos de desarrollo. En una situacin de equipo de gestin, donde el equipo de desarrollo cumple, varios roles existentes tienen responsabilidades adicionales como se muestra a continuacin y que requieren habilidades adicionales con el fin de proporcionar una estructura slida para un proyecto de DSDM que maximiza el beneficio de la participacin de los usuarios. Rol DSDM Patrocinador ejecutivo Responsabilidades adicionales Asegrese de que los resultados de la negociacin del contratosea un contrato comercialmente aceptable an en la cooperacin y colaboracin. Acuerdo del contrato definitivo con teniendo en cuenta detalles de gestin. Asumir un papel ms activo de garanta. Hacer el contrato de colaboracin. Resolver los problemas de escalado entre desarrollo y gestin , por lo general en gestin. En la mayora de los casos se trata de cuestiones financieras o de lnea de tiempo. Para cada tarea crtica para el negocio, revisar el plan de tarea. En situaciones de gestin revisin de la distribucin y alineacin de las actividades, y los resultados en el desarrollo. Resolver los problemas de una escalada de negocios entre los equipos de gestin y desarrollo. Asistir a crticas de negocio, cara a cara con los equipos de desarrollo y de gestin. Aprobar los cambios desde el punto de vista empresarial Asegrese de que todas las normas, directrices, procesos y herramientas se definen y aplican en todos los lugares. Crear y mantener un plan de integracin/infraestructura (construccin de entornos).Informar a los dos equiposde desarrollo y gestin de problemas tcnicos, las decisiones y suposiciones. Trabajar con los equipos de desarrollo y gestin para asegurar el software

Visionario

Coordinador Tcnico

Jefe de equipo Asesor del usuario Facilitador

suministrado se ajusta a la definicin de la arquitectura del sistema y cumple con los requisitos no funcionales. Comunicar los cambios en los requisitos no funcionales para todas las partes. Resolver los problemas tcnicos con los desarrolladores, tanto en gestin como con el cliente. Provide the glue between onshore and offshore teams on technical questions. Proporcionar el "pegamento" entre los equipos de desarrollo y gestin en las cuestiones tcnicas. Trabajar con desarrolladores y clientes en el control de calidad para asegurarse de que la revisin y auditora estn de acuerdo con las estrategias tcnicas del proyecto. Ser capaz de comunicarse eficientemente con los equipos de desarrrollo y gestin (y, si es necesario, adquirir los medios tcnicos para hacerlo). Asegurar que la infraestructura para el desarrollo y la prueba estn disponibles tanto en el desarrollo como en el cliente. Adems, asegrese de que conexiones entre desarrollo y gestin estn disponibles. Esta infraestructura se compone al menos de hardware, desarrollo de software, software de gestin de configuracin,software de gestin de requisitos y enlaces de comunicaciones. Asegrese de hardware y software en desarrollo y gestin sean compatibles.Resolver los problemas en esta rea. Trabajo en un solo lugar, ya sea en desarrollo o en gestin. Tener en cuenta las diferencias culturales. Tienen un fuerte nfasis en tener desarrolladores que estn comprometidos con el desarrollo de un sistema de un cliente remoto. Asegrese de que el Jefe de Proyecto y Jefe de otros Equipo(s) estn plenamente conscientes de los avances de su equipo. Trabajar con el Coordinador Tcnico para resolver y prevenir problemas tcnicos. Proporcionar conocimientos y habilidades a los equipos tanto en desarrollo como a los clientes. Nota: Con el equipo de gestin se llevar a cabo slo en casos excepcionales cara a cara. Tener conocimiento, o la conciencia, al menos, de las diferencias culturales. Ser experto en la facilitacin de las diferentes culturas. Organizar talleres con servicios de teleconferencia y videoconferencia. Organizar talleres retrospectivo (revisin al final de cada iteracin). Captar las lecciones aprendidas de lo que est funcionando, no de trabajo, en el mbito de la colaboracin y la cooperacin. Tenga en cuenta las diferencias culturales. Porque operan en un mismo lugar. Asistir a las teleconferencias y videoconferencias, a veces fuera del horario normal de trabajo. Nota: Puede que sea necesario para asistir a reuniones importantes en otros lugares.

Otros roles

Funciones adicionales de los clientes.

Las funciones adicionales que se enumeran en la tabla de abajo son tambin necesarias para hacer frente al hecho de que la organizacin que tiene intereses comerciales y objetivos diferentes. Roles DSDMO Desarrollador embajador Responsalbilidades Podra ser un desarrollador que trabaja en el negocio. Representar a la organizacin en la gestin, en particular, los desarrolladores y probadores. Representa la actividad en el lugar de la costa. Nota: es posible que haya menos necesidad para este papel, si bien las soluciones de tecnologa para la comunicacin estn en su lugar.

Desarrollador embajador de trabajo de usuario en la empresa Representantes apoyo y mantenimiento Coordinador de Prueba

Nota: Dado que el desarrollo se realiza en una ubicacin remota, las personas pueden ser menos conscientes de la necesidad de que el apoyo de soporte y mantenimiento y los representantes de mantenimiento lo ms pronto posible en elproceso de desarrollo.

Coordinar las pruebas para evitar la duplicacin de esfuerzos ya que los exmenes tienen lugar en varios lugares. Asegurar que los productos cumplen con los criterios tcnicos de calidad cuando se entrega desde la gestin de manera temprana. Hay dos funciones adicionales que le sern tiles pero no esenciales: Responsabilidades

Roles adicionales de DSDM-O Administrador de contratos Experto en gestin

Gestionar todos los asuntos contractuales con la organizacin externa. Tener experiencia en tratar con el pas en cuestin. Funcin de asesoramiento. Proporcionar asesoramiento a travs de la experiencia personal en proyectos con empresas extranjeras en general y el pas elegido en particular.

El proceso de DSDM-O.
Esta seccin trata sobre los efectos de las fases del ciclo de vida. Donde se identifican los productos, los retos, riesgos, funciones y responsabilidades que cambian o son nuevos. Los diagrama en cada fase muestran las diferencias de forma grfica.

Estudio de factibilidad.
El ventaja principal de DSDM durante el estudio de viabilidad es la decisin de si es o no una opcin viable en la gestin. Este es el momento de revisar las lecciones aprendidas en proyectos anteriores. Si una organizacin es completamente nueva para el trabajo en la gestin, sera conveniente determinar su viabilidad para la organizacin en general.

Desde DSDM-O implica al menos dos organizaciones diferentes que estn fsicamente separadas, es necesario entender las diferencias culturales y determinar el mejor entorno de colaboracin para un proyecto de DSDM. El diagrama muestra las principales diferencias de los proyectos del lado del cliente.

Efecto de DSDMO en el Estudio de Factibilidad.

Estudio del negocio.

El estudio del negocio suele ser la primera fase en la que est involucrada la gestin. Por lo tanto, es un buen momento para garantizar que la comunicacin entre las partes est trabajando y que hay un ambiente de colaboracin y cooperacin. El estudio de negocios genera la lista de requisitos priorizados, estos sern examinado para determinar cul de los requisitos se abordarn primero. En el estudio del negocio tambin se produce el Plan de Desarrollo: es importante que el tenga una representacin suficiente para garantizar los plazos, etc, el plan debe ser realista y factible.

Efecto de la gestin en el estudio de negocios.

Iteracin modelo funcional.

A menudo es en este punto que el trabajo realmente comienza en gestin, con los equipos de los usuarios y programadores que necesitan trabajar en estrecha colaboracin, adems de estar geogrficamente separados. Ya sea a miles de kilmetros o slo decenas, la separacin puede conducir a una mentalidad diferente en los equipos, la prdida de la comunicacin y una tendencia a hacer suposiciones. Es una tarea de gestin de proyectos para asegurarse de que el equipo est de hecho trabajando como un solo equipo. No hay que subestimar la necesidad de la comunicacin cara a cara.

Efecto de la gestin en la fase de modelo de iteracin funcional.

Diseo y Construccin de iteracin.

La clave para el xito del diseo y la fase de Creacin de iteracin en la gestin de un proyecto es asegurar que la comunicacin y herramientas de apoyo y ambientes permitan que los desarrolladores y los usuarios converjan con eficacia en una solucin que sea adecuada para el propsito.

Efecto de la gestion en la fase de diseo y construccin de iteracin

Productos.
En el diseo construccionde la iteracin en la gestin no tiene productos especficos. Slo se define el lugar donde se producen. La otra consideracin en la gestin de los productos es que debe tener un propietario nominado en el entorno del proyecto. Este titular puede ser desarrollador o cliente.

Implementacin.
Existen algunas diferencias en esta fase entre DSDM normal y DSDM-O. Lo siguiente debe ser observado sin embargo: Un representante tcnico en gestin debe estar disponible en el desarrollo para asegurar una transicin sin problemas a la produccin, y para dar cabida a la transferencia de conocimiento desde el proveedor al cliente. Si el desarrollo se ha llevado a cabo en un entorno aislado, las diferencias y las dependencias en las arquitecturas pueden surgir durante esta fase, aunque esta prueba debe haber sido incorporada en la estrategia de prueba dentro del Plan de Desarrollo. Diferencias de tiempo pueden causar retrasos en el camino crtico y estos deben ser atendidos.

Post-proyecto.
La fase post proyecto ser siempre en el desarrollo. No hay variacin de la norma DSDM, aunque el proveedor debe participar en los futuros cambios y en la determinacin de las lecciones aprendidas.

Herramientas y Tcnicas.
DSDM identifica las herramientas y tcnicas que son esenciales dentro de un proyecto de DSDM. En la gestin existe la necesidad de otras herramientas, principalmente debido a la lejana de las partes. Las siguientes son considerados como muy importantes: Reuniones cara a cara. Video conferencias. Teleconferencias. Herramientas para administracin de requerimientos. Software para hacerse cargo de un PC a distancia, por lo que los desarrolladores pueden mostrar prototipos directamente a los usuarios. El uso de imagenes, registros realizados de los mapas mentales, los modelos de actividad, etc, en las sesiones de capacitacin son a menudo ms comprensibles que los otros metodos tales como guias de usuario.

Algunas herramientas que tambin pueden ser utiles son:

Mientras que los siguientes son estndares genricos de desarrollo, pero se vuelven muy importantes en los limites, sobre todo si el desarrollo se divide: Convenciones de nombres (como el nombre de una clase, un mtodo, un adaptador de integracin, etc). Convenciones de la documentacin (definir el formato correspondiente y el nombrede un documento). Las convenciones de codificacin para que el equipo de gestin y el equipo de desarrollo pueda leer, desarrollar, y revisar el cdigo de cada uno. Objetos comunes, un diccionario comn.