CICLO DE VIDA

Cualquier sistema de informacin va pasando por una serie de fases a lo largo de su vida. Su
ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes:
- Planificacin
- Anlisis
- Diseo
- Implementacin
- Pruebas
- Instalacin o despliegue
- Uso y mantenimiento
Planificacin
Antes de que se le d oficialmente el pistoletazo de salida a un proyecto de desarrollo de un
sistema de informacin, es necesario realizar una serie de tareas previas que influirn
decisivamente en la finalizacin con xito del proyecto. Estas tareas se conocen popularmente
como el fuzzy front-end del proyecto al no estar sujetas a plazos. Las tareas iniciales que se
realizarn esta fase inicial del proyecto incluyen actividades tales como la determinacin del
mbito del proyecto, la realizacin de un estudio de viabilidad, el anlisis de los riesgos
asociados al proyecto, una estimacin del coste del proyecto, su planificacin temporal y la
asignacin de recursos a las distintas etapas del proyecto.
En una de estas tareas se obtiene un documento breve, de 1 2 pginas, en el que se
describe el problema que nuestro sistema de informacin pretende resolver. Este documento,
denominado a veces mission statement o project charter, debe existir siempre en todo proyecto
Anlisis
Lo primero que debemos hacer para construir un sistema de informacin es averiguar qu es
exactamente lo que tiene que hacer el sistema. La etapa de anlisis en el ciclo de vida del
software corresponde al proceso mediante el cual se intenta descubrir qu es lo que realmente
se necesita y se llega a una comprensin adecuada de los requerimientos del sistema (las
caractersticas que el sistema debe poseer). Muchas prcticas resultan efectivas para gestionar
adecuadamente los requerimientos de un sistema y, en cierto modo, controlar su evolucin. Un
buen analista debera tener una formacin adecuada en:
Tcnicas de elicitacin de requerimientos.
Herramientas de modelado de sistemas.
Metodologas de anlisis de requerimientos.
Diseo
Mientras que los modelos utilizados en la etapa de anlisis representan los requisitos del
usuario desde distintos puntos de vista (el qu), los modelos que se utilizan en la fase de
diseo representan las caractersticas del sistema que nos permitirn implementarlo de forma
efectiva (el cmo).
En la fase de diseo se han de estudiar posibles alternativas de implementacin para el
sistema de informacin que hemos de construir y se ha de decidir la estructura general que
tendr el sistema (su diseo arquitectnico). El diseo de un sistema es complejo y el
proceso de diseo ha de realizarse de forma iterativa. La solucin inicial que propongamos
probablemente no resulte la ms adecuada para nuestro sistema de informacin, por lo que
deberemos refinarla. Afortunadamente, tampoco es necesario que empecemos desde cero.
Existen autnticos catlogos de patrones de diseo que nos pueden servir para aprender de los
errores que otros han cometido sin que nosotros tengamos que repetirlos. Igual que en la etapa
de anlisis crebamos distintos modelos en funcin del aspecto del sistema en que

centrbamos nuestra atencin, el diseo de un sistema de informacin tambin presenta

distintas facetas:
Por un lado, es necesario abordar el diseo de la base de datos.
Por otro lado, tambin hay que disear las aplicaciones que permitirn al usuario
utilizar el sistema de informacin. Tendremos que disear la interfaz de usuario del
sistema y los distintos componentes en que se descomponen las aplicaciones
Implementacin
Una vez que sabemos qu funciones debe desempear nuestro sistema de informacin
(anlisis) y hemos decidido cmo vamos a organizar sus distintos componentes (diseo), es el
momento de pasar a la etapa de implementacin, pero nunca antes. Antes de escribir una sola
lnea de cdigo (o de crear una tabla en nuestra base de datos) es fundamental haber
comprendido bien el problema que se pretende resolver y haber aplicado principios bsicos de
diseo que nos permitan construir un sistema de informacin de calidad.
Para la fase de implementacin hemos de seleccionar las herramientas adecuadas, un entorno
de desarrollo que facilite nuestro trabajo y un lenguaje de programacin apropiado para el tipo
de sistema que vayamos a construir. La eleccin de estas herramientas depender en gran
parte de las decisiones de diseo que hayamos tomado hasta el momento y del entorno en el
que nuestro sistema deber funcionar.
A la hora de programar, deberemos procurar que nuestro cdigo no resulte indescifrable. Para
que nuestro cdigo sea legible, hemos de evitar estructuras de control no estructuradas, elegir
cuidadosamente los identificadores de nuestras variables, seleccionar algoritmos y estructuras
de datos adecuadas para nuestro problema, mantener la lgica de nuestra aplicacin lo ms
sencilla posible, comentar adecuadamente el texto de nuestros programas y, por ltimo, facilitar
la interpretacin visual de nuestro cdigo mediante el uso de sangras y lneas en blanco que
separen distintos bloques de cdigo.
Adems de las tareas de programacin asociadas a los distintos componentes de nuestro
sistema, en la fase de implementacin tambin hemos de encargarnos de la adquisicin de
todos los recursos necesarios para que el sistema funcione (por ejemplo, las licencias de uso
del sistema gestor de bases de datos que vayamos a utilizar). Usualmente, tambin
desarrollaremos algunos casos de prueba que nos permitan ir comprobando el funcionamiento
de nuestro sistema conforme vamos construyndolo.
Pruebas
Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que se hayan
podido cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos). Lo suyo,
adems, es hacerlo antes de que el usuario final del sistema los tenga que sufrir. De hecho,
una prueba es un xito cuando se detecta un error (y no al revs, como nos gustara pensar).
La bsqueda de errores que se realiza en la etapa de pruebas puede adaptar distintas formas,
en funcin del contexto y de la fase del proyecto en la que nos encontremos:
Las pruebas de unidad sirven para comprobar el correcto funcionamiento de un
componente concreto de nuestro sistema. Es este tipo de pruebas, el "probador" debe
buscar situaciones lmite que expongan las limitaciones de la implementacin del
componente, ya sea tratando ste como una caja negra ("pruebas de caja negra") o
fijndonos en su estructura interna ("pruebas de caja blanca"). Resulta recomendable
que, conforme vamos aadindole nueva funcionalidad a nuestras aplicaciones,
vayamos creando nuevos tests con los medir nuestro progreso y tambin repitamos los
antiguos para comprobar que lo que antes funcionaba sigue funcionando (test de
regresin).

Las pruebas de integracin son las que se realizan cuando vamos juntando los
componentes que conforman nuestro sistema y sirven para detectar errores en sus
interfaces. En algunas empresas, como Microsoft, se hace una compilacin diaria
utilizando los componentes del sistema tal como estn en ese momento (daily build) y
se somete al sistema a una serie de pruebas bsicas (la prueba de humo, smoke test)
que garanticen que el proyecto podr seguir avanzando al da siguiente. El causante de
que la compilacin diaria falle suele tener que quedarse a hacer horas extra para que
sus compaeros puedan seguir trabajando al da siguiente...
Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de la organizacin
encargada del desarrollo del sistema. Estas pruebas, realizadas desde el punto de vista
de un usuario final, pueden ayudar a pulir aspectos de la interfaz de usuario del sistema
Cuando el sistema no es un producto a medida, sino que se vender como un producto
en el mercado, tambin se suelen realizar pruebas beta. Estas pruebas las hacen
usuarios finales del sistema ajenos al equipo de desarrollo y pueden resultar vitales
para que un producto tenga xito en el mercado.
En sistemas a medida, se suele realizar un test de aceptacin que, si se supera con
xito, marcar oficialmente el final del proceso de desarrollo y el comienzo de la etapa
de mantenimiento.
Por ltimo, a lo largo de todo el ciclo de vida del software, se suelen hacer revisiones de todos
los productos generados a lo largo del proyecto, desde el documento de especificacin de
requerimientos hasta el cdigo de los distintos mdulos de una aplicacin. Estas revisiones, de
carcter ms o menos formal, ayuden a verificar la correccin del producto revisado y tambin
a validarlo (comprobar que se ajusta a los requerimientos reales del sistema).
Instalacin / Despliegue
Una vez concluidas las etapas de desarrollo de un sistema de informacin (anlisis, diseo,
implementacin y pruebas), llega el instante de que poner el sistema en funcionamiento, su
instalacin o despliegue.
De cara a su instalacin, hemos de planificar el entorno en el que el sistema debe funcionar,
tanto hardware como software: equipos necesarios y su configuracin fsica, redes de
interconexin entre los equipos y de acceso a sistemas externos, sistemas operativos
(actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados
por terceras partes, etctera.
Para asegurar el correcto funcionamiento del sistema, resulta esencial que tengamos en cuenta
las dependencias que pueden existir entre los distintos componentes del sistema y sus
versiones. Una aplicacin puede que slo funcione con una versin concreta de una biblioteca
auxiliar. Un disco duro puede que slo rinda al nivel deseado si instalamos un controlador
concreto. Componentes que por separado funcionaran correctamente, combinados causan
problemas, por lo que deberemos utilizar slo combinaciones conocidas que no presenten
problemas de compatibilidad.
Si nuestro sistema reemplaza a un sistema anterior o se despliega paulatinamente en distintas
fases, tambin hemos de planificar cuidadosamente la transicin del sistema antiguo al nuevo
de forma que sus usuarios no sufran una disrupcin en el funcionamiento del sistema. En
ocasiones, el sistema se instala fsicamente en un entorno duplicado y la transicin se hace de
forma instantnea una vez que la nueva configuracin funciona correctamente. Cuando el
presupuesto no da para tanto, tal vez haya que buscar un momento de baja utilizacin del
sistema para realizar la actualizacin (por las noches o en fin de semana, por ejemplo).
Uso y mantenimiento

La etapa de mantenimiento consume tpicamente del 40 al 80 por ciento de los recursos de una
empresa de desarrollo de software. De hecho, con un 60% de media, es probablemente la
etapa ms importante del ciclo de vida del software. Dada la naturaleza del software, que ni se
rompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes:
Eliminar los defectos que se detecten durante su vida til (mantenimiento correctivo),
lo primero que a uno se le viene a la cabeza cuando piensa en el mantenimiento de
cualquier cosa.
Adaptarlo a nuevas necesidades (mantenimiento adaptativo), cuando el sistema ha de
funcionar sobre una nueva versin del sistema operativo o en un entorno hardware
diferente, por ejemplo.
Aadirle nueva funcionalidad (mantenimiento perfectivo), cuando se proponen
caractersticas deseables que supondran una mejora del sistema ya existente.
De las distintas facetas del mantenimiento, la eliminacin de defectos slo supone el 17% del
coste de mantenimiento de un sistema, mientras que el diseo e implementacin de mejoras es
responsable del 60% del coste de mantenimiento. Es decir, ms de un tercio del coste total del
software se emplea en aadirle caractersticas a software ya existente (el 60% del 60%). La
correccin de errores supone, en contraste, "slo" en torno al 10% del coste total del software.
An menos cuanto mejores sean las tcnicas usadas en su desarrollo.
Se ha observado que, cuanto mejor sea el software, ms tendremos que invertir en su
mantenimiento, aun cuando se emplee menos esfuerzo en corregir defectos. Este hecho, que
puede parecer paradjico, se debe, simplemente, a que nuestro sistema se usar ms (a
veces, de formas que no habamos previsto). Por tanto, nos llegarn ms propuestas de
modificacin y mejora que si el sistema hubiese quedado aparcado, cogiendo polvo, en algn
rincn. Si examinamos las tareas que se llevan a cabo durante la etapa de mantenimiento, nos
encontramos que en el mantenimiento se repiten todas las etapas que ya hemos visto del ciclo
de vida de un sistema de informacin. Al tratar principalmente de cmo aadirle nueva
funcionalidad a un sistema ya existente, el mantenimiento repite "en miniatura" el ciclo de vida
completo de un sistema de informacin. Es ms, a las tareas normales de desarrollo hemos de
aadirle una nueva, comprender el sistema que ya existe, por lo que se podra decir que el
mantenimiento de un sistema es ms difcil que su desarrollo (Glass, 2003).

PROTOTIPOS INFORMATICOS
Un de un prototipo en software:es un modelo del comportamiento del sistema que puede ser
usado para entenderlo completamente o ciertos aspectos de l y as clarificar los
requerimientos Un prototipo es una representacin de un sistema, aunque no es un sistema
completo, posee las caractersticas del sistema final o parte de ellas
Modelo o maqueta del sistema que se construye para comprender mejor el problema y sus
posibles soluciones:
Evaluar mejor los requisitos.
Probar opciones de diseo.
Caractersticas de los prototipos
Funcionalidad limitada.
Poca fiabilidad.
Caractersticas de funcionalidad pobres.
Alto grado de participacin del usuario el cual evala los prototipos, propone mejoras y
detalla requisitos.
Alto grado de participacin del analista de sistemas, ya que en muchos casos los
usuarios no pueden indicar los requisitos sin tener experiencia con el sistema.
El prototipo da mayor conocimiento al usuario y analistas ayudando a que el usuario
aprenda a utilizar el sistema.
Uso de prototipo
Se presenta al cliente un prototipo para su experimentacin.
Ayuda al cliente a establecer claramente los requisitos.
Ayuda a los desarrolladores a:
Validar correccin de la especificacin.
Aprender sobre problemas que se presentarn durante el diseo e implementacin del
sistema.
Mejorar el producto.
Examinar viabilidad y utilidad de la aplicacin.
Tipos de prototipos.
Prototipado de interfaz de usuario: modelos de pantallas.
Prototipado funcional (operacional): implementa algunas funciones, y a medida que se
comprueba que son las apropiadas, se corrigen, refinan, y se aaden otras.
Modelos de rendimiento: evalan el rendimiento de una aplicacin crtica (no sirven al anlisis
de requisitos).
Rpido o desechable:
Sirve al anlisis y validacin de los requisitos.
Despus se redacta la especificacin del sistema y se desecha el prototipo.
La aplicacin se desarrolla siguiendo un paradigma diferente.
Problema: cuando el prototipo no se desecha, y termina convirtindose en el sistema
final.
Evolutivos:
Comienza con un sistema relativamente simple que implementa los requisitos ms
importantes o mejor conocidos.
El prototipo se aumenta o cambia en cuanto se descubren nuevos requisitos.
Finalmente, se convierte en el sistema requerido.
Actualmente se usa en el desarrollo de sitios Webs y en aplicaciones de comercio
electrnico.
FASES
Las fases que comprende el mtodo de desarrollo orientado a prototipos seran:

Investigacin preliminar. Las metas principales de esta fase son: determinar el

problema y su mbito, la importancia y sus efectos potenciales sobre la organizacin
por una parte y, por otro lado, identificar una idea general de la solucin para realizar un
estudio de factibilidad que determine la factibilidad de una solucin software.
Definicin de los requerimientos del sistema. El objetivo de esta etapa es registrar
todos los requerimientos y deseos que los usuarios tienen en relacin al proyecto bajo
desarrollo. Esta etapa es la ms importante de todo el ciclo de vida, es aqu donde el
desarrollador determina los requisitos mediante la construccin, demostracin y
retroalimentaciones del prototipo. Por lo mismo esta etapa ser revisada con ms
detalle luego de esta descripcin.
Diseo tcnico. Durante la construccin del prototipo, el desarrollador ha obviado el
diseo detallado. El sistema debe ser entonces rediseado y documentado segn los
estndares de la organizacin y para ayudar a las mantenciones futuras. Esta fase de
diseo tcnico tiene dos etapas: por un lado, la produccin de una documentacin de
diseo que especifica y describe la estructura del software, el control de flujo, las
interfaces de usuario y las funciones y, como segunda etapa, la produccin de todo lo
requerido para promover cualquier mantencin futura del software.
Programacin y prueba. Es donde los cambios identificados en el diseo tcnico son
implementados y probados para asegurar la correccin y completitud de los mismos con
respecto a los requerimientos.
Operacin y mantencin. La instalacin del sistema en ambiente de explotacin, en
este caso, resulta de menor complejidad, ya que se supone que los usuarios han
trabajado con el sistema al hacer las pruebas de prototipos. Adems, la mantencin
tambin debera ser una fase menos importante, ya que se supone que el refinamiento
del prototipo permitira una mejor claridad en los requerimientos, por lo cual las
mantenciones perfectivas se reduciran. Si eventualmente se requiriese una mantencin
entonces el proceso de prototipado es repetido y se definir un nuevo conjunto de
requerimientos.
La fase ms importante corresponde a la definicin de requerimientos, la cual correspondera a
un proceso que busca aproximar las visiones del usuario y del desarrollador mediante
sucesivas iteraciones. La definicin de requerimientos consiste de cinco etapas entre dos de
las cuales se establece un ciclo iterativo:
Anlisis grueso y especificacin. El propsito de esta subfase es desarrollar un
diseo bsico para el prototipo inicial.
Diseo y construccin. El objetivo de esta subfase es obtener un prototipo inicial. El
desarrollador debe concentrarse en construir un sistema con la mxima funcionalidad,
poniendo nfasis en la interface del usuario.
Evaluacin. Esta etapa tiene dos propsitos: extraer a los usuarios la especificacin de
los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo
haya sido en concordancia con la definicin de requerimientos del sistema. Si los
usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige
el prototipo antes de la siguiente evaluacin. El prototipo es repetidamente modificado y
evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El
proceso de evaluacin puede ser dividido en cuatro pasos separados: preparacin,
demostracin, uso del prototipo y discusin de comentarios. En esta fase se decide si el
prototipo es aceptado o modificado.
Modificacin. Esto ocurre cuando la definicin de requerimientos del sistema es
alterada en la subfase de evaluacin. El desarrollador entonces debe modificar el
prototipo de acuerdo a los comentarios hechos por los usuarios.
Trmino. Una vez que se ha desarrollado un prototipo estable y completo, es necesario
ponerse de acuerdo en relacin a aspectos de calidad y de representacin del sistema.

En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la
especificacin de requerimientos est claramente diferenciada de las dems. Es en ella donde
se utiliza el prototipado, ya que permite entregar al usuario lo que sera una visin la solucin
final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de
especificaciones errneas.

Modelo de desarrollo Orientado a Prototipos

Las ventajas de un enfoque de desarrollo orientado a prototipos estn dadas por:
Reduccin de la incertidumbre y del riesgo
Reduccin de tiempo y de costos, incrementos en la aceptacin del nuevo sistema,
Mejoras en la administracin de proyectos
Mejoras en la comunicacin entre desarrolladores y clientes, etc.
Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, tambin presenta
desventajas como:
La dependencia de las herramientas de software para el xito ya que la necesidad de
disminucin de incertidumbre depende de las iteraciones del prototipo, entre ms
iteraciones exista mejor y esto ltimo se logra mediante el uso de mejores herramientas
lo que hace a este proceso dependiente de las mismas.
Tambin, no es posible aplicar la metodologa a todos los proyectos de software y,
finalmente, la mala interpretacin que pueden hacer los usuarios del prototipo, al cual
pueden confundir con el sistema terminado.
No se puede desconocer que la fase de definicin de requerimientos se ha
perfeccionado en dos aspectos importantes: primero se ha aproximado las visiones del
usuario y el desarrollador, lo cual representa el beneficio de establecer una base comn
de comunicacin; tambin, el hacer explcita la posibilidad de iterar sobre estos
dominios permitira que la convergencia de los mismos sea una posibilidad cierta.

ADQUISICIN DE SOFTWARE
Investigar el mercado de aplicaciones para Servicios Profesionales
Comprender la funcionalidad bsica del software para la industria
Investigar sobre las capacidades ms avanzadas del software
Aprender la diferencia entre software basado en la WEB, (SaaS) y el que se instala en su
empresa (On-premise)
Identificar el camino por el cual el software har ms eficiente su compaa
Sensibilizarse con los costos de una implementacin de software
Priorizar sus requerimientos
Identificar aquello que el software deber resolver
Identificar las limitaciones del software actual
Hacer una lista de las capacidades que se necesitan con el software ideal
Revisar la lista de ideales con colegas
Dar prioridad a la lista separando aquello que es imprescindible de lo que es deseable
Construir el caso
Identificar los decisores de la empresa que usted necesita para la aprobacin de la propuesta
Enumere y presente los desafos que debe afrontar la compaa y las ineficiencias actuales
Detalle la forma en que el nuevo software solucionar los problemas
Muestre un cuadro con el presupuesto necesario para poner en marcha el nuevo software
Obtenga la aprobacin para proceder con la bsqueda y evaluacin
Elaborar una lista corta de empresas vendedoras
Definir cul es el software adecuado para el giro del negocio
Definir qu productos satisfacen los requerimientos de ms alto nivel de la organizacin
Definir qu tipo de productos est acorde con su presupuesto
Contactar hasta 5 empresas vendedoras
Comunicar a los vendedores cul ser su proyecto
Explictele a las empresas vendedoras cmo sern evaluados.
Comparta con los vendedores preseleccionados sus prioridades.
Comntele a las empresas oferentes con quines estn compitiendo.
Detalle su proceso de seleccin y la lnea de tiempo de las actividades y decisiones.
Sea explcito sobre lo que usted espera de los vendedores durante el proceso.
Presenciar y evaluar las demostraciones
Prepare los puntos de inters para la demostracin y compralos con la empresa vendedora.
Agende la fecha y hora para la demostracin de cada mdulo del sistema.
Invite a la gente adecuada, o usuarios claves, de su organizacin.
Utilice una ficha de puntuacin para darle valor a cada punto de la demostracin.
Renase con sus colegas luego de la demostracin. Intercambie con ellos las anotaciones y
puntuaciones.
Ordenar de acuerdo a un ndice objetivo los ERPs
Elimine de la lista a las empresas vendedoras que no cumplen con los requerimientos
imprescindibles.
Elabore un rnking del resto de los vendedores en base a la puntuacin funcional.
Elabore otro rnking de acuerdo a la facilidad de uso del producto.
Si es necesario, vuelva a pedir una demostracin.

Compare precios
Solicite un detalle de precios a las empresas vendedoras.
Provea los datos necesarios para que realicen la propuesta.
Asegrese que las propuestas contengan el precio de todos los tems involucrados en el
proyecto y que sean de incumbencia de la empresa vendedora.
Compare las propuestas de manera homognea. Como se dice popularmente peras con
peras, manzanas con manzanas.
Pida a los vendors el contrato tipo o modelo de licenciamiento y el de servicios.
Verificar referencias y viabilidad del proveedor elegido
Infrmele a la empresa vendedora que est considerando avanzar con su propuesta.
Pdale el contacto con dos o ms clientes con tamao o actividades similares a las suyas.
Pida referencias sobre la respuesta de la empresa vendedora para solucionar problemas.
Asegrese sobre la viabilidad financiera y estratgica de la empresa vendedora con la que est
avanzando
Revisar el contrato de licencias y servicios
Pida descuentos si es necesario.
Asegrese de estar adquiriendo las licencias necesarias.
Evale los costos de entrada y los recurrentes.
Observe cuidadosamente las clusulas de auto renovacin.

DESARROLLO DE USUSARIO FINAL

El EUD (End-User Development) o Desarrollo por el Usuario Final se define como un conjunto
de actividades o tcnicas que permiten a las personas, que no son desarrolladores
profesionales, crear o modificar software. Este paradigma est basado en campos de
investigacin ya conocidos y explorados, como es el caso de la Interaccin Persona Ordenador
y la Ingeniera de Software, principalmente. El EUD surge como iniciativa europea a partir del
proyecto EUD-Net, una Red de Excelencia Europea que tiene como objetivo hacer posible, de
una forma rpida y barata, la coevolucin de sistemas y usuarios finales como uno solo, a partir
de la adaptacin explcita de las aplicaciones informticas a las actividades de los propios
usuarios. Los sistemas basados en el EUD deben ser fciles de entender, de aprender, de
usar, de ensear y de evaluar.
Objetivos
Aunque a grandes rasgos el principal objetivo que persigue el Desarrollo por el Usuario Final es
facilitar la autora de software a cualquier tipo de usuario, es necesario plantear unos objetivos
ms concretos, basados en el anlisis de la situacin actual y que permitan, finalmente,
conseguir ese objetivo principal marcado como hito. De esta forma, son los objetivos que a
continuacin se detallan los que se marcan como prioritarios dentro del EUD:
Aumentar la participacin del usuario en el proceso inicial de diseo. Se trata de tener
en cuenta la opinin del usuario en todo momento, haciendo un diseo mucho ms
centrado en el usuario y adaptado a sus propias necesidades. En cualquier caso, los
requerimientos del usuario final son muy diversos y cambiantes, y pueden ser difciles
de especificar en un momento dato. Los mtodos tradicionales utilizados para el ciclo de
vida de aplicaciones software son difciles de adaptar a la filosofa del EUD. Se
necesitan por tanto mtodos evolutivos, haciendo ms hincapi en el Diseo durante el
uso en vez del Diseo antes del uso.
Utilizar lenguajes visuales de modelado. Es primordial conseguir lenguajes fciles de
usar para el usuario, ms intuitivos, as como lenguajes de dominio especfico. Esto
permite hacer frente a la diferencia de abstraccin existente entre los profesionales del
software y usuarios finales o expertos del dominio.
Llegar a un compromiso aceptable entre la expresividad y la facilidad de uso. Lo
deseable para este caso es conseguir entornos de creacin de software fciles de
utilizar, intuitivos, a partir de tcnicas WYSIWYG, disminuyendo por el contrario la
capacidad expresiva de los mismos. En definitiva, se trata de evaluar lo que se
denomina el Gentle Slope of Complexity [4], es decir, conseguir un compromiso
aceptable entre la expresividad y la facilidad de uso a base de reducir la complejidad
conceptual de las aplicaciones. Para ello sera deseable que el software basado en
EUD incorporara caractersticas tales como permitir al usuario establecer parmetros y
seleccionar objetos, integrar componentes existentes en el sistema y extender el
sistema programando nuevos componentes.
Disear ms software adaptativo. Teniendo al usuario final como objetivo en el diseo
de software para autora, sera conveniente, como ayuda al usuario, construir sistemas
que se adapten a ste durante el uso. Para ello el software adaptativo debe realizar un
seguimiento del comportamiento del usuario, as como de otras actividades
contextuales, como la actividad actual o la situacin y el contexto de uso. Es importante
que el sistema lleve a cabo una adaptacin no intrusiva, intentando no distraer el
usuario de su tarea principal.