Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

9.4 Gestin del proceso de desarrollo de una

aplicacin Web
185 progresos en relacin con todas las influencias que impiden a tiempo, costo y calidad con
respecto a los clientes, el trabajo lugar, las fuerzas del mercado, otros factores externos, y el
equipo de desarrollo "(Friedlein 2002).
Otra tarea importante del gestor de proyecto Web es la asistencia y la integracin de la al
cliente durante el desarrollo de una aplicacin web. Hay dos peculiaridades a esta tarea, en
comparacin con los proyectos de software convencionales:
1. La transicin de un proyecto Web desde el desarrollo hasta el uso regular es fluido.
Tambin, es con frecuencia difcil para el director del proyecto Web para determinar
cundo AWeb aplicacin tiene tenido plenamente en funcionamiento, y por lo tanto
cuando el proyecto de desarrollo real ha sido uso completado y regular (incluido el
mantenimiento) de la aplicacin web desarrollada tiene comenzado.
2. Adems, a menudo no est claro si es o no AWeb director del proyecto an debe
participar con el proyecto una vez que la aplicacin se ha trasladado a la fase de
operacin y mantenimiento. Esto se hace ms crtico debido al hecho de que, debido
al conocimiento especial de solo miembros de un equipo de proyecto Web, el principal
medio de contacto con el cliente en proyectos Web no es mantenido a travs del
gestor de proyecto Web, sino directamente a travs de expertos (ver Burdmann 1999).
Este hecho podra ser otra seal de la falta de madurez de gestin de proyectos Web
como se practica actualmente.
La Tabla 9-3 muestra las reglas ms importantes de un jefe de proyecto Web debe respetar
para gestin exitosa de proyectos Web.
Tabla 9-3 Diez reglas de oro para gerentes de proyectos web
Diez reglas de oro para Jefes de Proyecto Web
1. Promover la auto-concepcin profesional de cada miembro del equipo. Cuidar de la
tica en el equipo.
2. destacan la importancia de diferentes conocimientos aplicacin para el proyecto.
3. Resolver los conflictos de forma rpida. Asegrese de que ningn miembro del equipo
es un ganador o un perdedor todo el tiempo.
4. Explicar a cada miembro del equipo de sus funciones y responsabilidades de forma
continua.
5. Identificar desarrollos paralelos y utilizar las sinergias potenciales.
6. Distribuir tareas de documentacin a los miembros del equipo bastante en funcin de
su mbito de aplicacin.
7. Promover y coordinar el uso continuo de herramientas desde el principio del proyecto.
8. Traducir costos y valores en diferentes reas del proyecto.
9. Promover la integracin continua de la atencin al cliente en el proyecto.
10. Siempre mantenga un ojo en el progreso del proyecto y el objetivo del proyecto.

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

9.4 Gestin del proceso de desarrollo de un sitio Web

Solicitud
9.4.1 Implementacin de las herramientas
aplicaciones Web se desarrollan necesariamente utilizando un enfoque muy flexible,
caracterizado por una alto grado de reutilizacin, mtodos y procesos giles, cercana al
cliente, y un gran nmero de productos intermedios. Los cambios que puedan ser necesarios
para los procesos de desarrollo utilizados para
Gestin de Proyectos Web 186
Ingeniera Web ser discutido en el captulo 10. Los captulos 11 a 13 discutir importante los
aspectos de garanta de calidad.
Sin embargo, con respecto a las herramientas utilizadas y los resultados (intermedios)
producidos, se puede
Tambin observar una transicin desde el enfoque del documento impulsado en el software
tradicional (rgida) hacia un enfoque altamente herramienta apoyado en proyectos de
desarrollo gil (Orr 2002). Esta transicin de soporte de la herramienta en los enfoques giles
se muestra en la Tabla 9-4, que utiliza el modelo de la documentacin de (Mayr, 2005).
enfoques giles requieren cada vez ms herramientas, por ejemplo, para la gestin de
requisitos, planificacin, diseo / aplicacin, planificacin y ejecucin de pruebas y control de
errores, as como continuas gestin de la configuracin. Esto se aplica en particular a los
desarrolladores jvenes y sin experiencia, ya que pueden perder fcilmente su control sobre el
proyecto, sobre todo si es muy iterativo. En una de las pocos estudios que tratan
explcitamente de los problemas de gestin de proyectos Web, (Cutter Consortium 2000)
sugiere que ". . . iteraciones pueden convertirse fcilmente en desarrollos ad-hoc sin
herramientas para
9.4 Gestin del proceso de desarrollo de una aplicacin Web 187
medicin del avance, gestin del cambio, y la revisin de resultados. . . [Y]. . . monitoreo
cuidadoso de los requisitos de ambos por el promotor y el cliente ". La misma fuente menciona
que proyectos web en particular, tienen que ser manejado en base a un plan documentado, y
que amplia y la prueba cuidadosa es inevitable, incluso si el proyecto ya sufre de retrasos.
Estas herramientas deben interactuar bien (o, idealmente, ser integrado) para asegurar que el
desarrollo de un proyecto mejora la eficiencia (vase el proyecto de Eclipse en
http://www.eclipse.org para un ejemplo).
Sin embargo, se debe tener cuidado para asegurar que el proceso de desarrollo es
independiente de estas herramientas y tecnologas (McDonald y 2001a) Welland. Dado que
las tecnologas disponibles para desarrollar aplicaciones Web cambiar rpidamente y de una

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

manera impredecible, el proceso de desarrollo deben estar claramente separados de

herramientas y lenguajes de implementacin.
En muchos casos, al pasar a un enfoque gil, la gente se olvida de que la disponibilidad de
estos herramientas es slo una cara de la moneda; el manejo de ellos tiene que ser aprendido
y practicado, tambin. El tiempo requerido para tales procesos de aprendizaje con frecuencia
no est previsto en el proyecto Web cortos, o su coste no puede ser justificado. Dado que los
desarrolladores de proyectos Web son normalmente sin experiencia, aprendizaje individual
"autodidacta" de los mtodos giles y las herramientas necesarias podra, de hecho, conducir
a una situacin en la que se omite todo subjetivamente poco importante, mientras que la
piratera hace su entrada (Beck y McBreen 2002).
Herramientas para la Gestin de Proyectos Web
Dado que los desarrolladores web son especialmente familiarizados con la Web, herramientas
basadas en la Web son idealmente adecuado para la gestin de proyectos web. herramientas
de
gestin
de
proyectos
basados
en
la
web,
tales
como
PHProjekt
(Http://www.PHProjekt.com), permitir manejar las tareas tradicionales de gestin de
proyectos, tales como el registro del tiempo, mantener un diario, archivar documentos y
control de versiones resultado, la explotacin forestal, pizarras, salas de chat, distribucin de
correo electrnico, etc., para apoyar la comunicacin del equipo Web.
Muchas de estas herramientas son gratis para uso personal y educativo. Adems, tales
herramientas facilitar la comunicacin y la colaboracin ms all de las fronteras locales, que
se producen con frecuencia en proyectos web. Proyecto Management Institute (1999) da una
visin general de la gestin de proyectos herramientas, incluyendo herramientas basadas en
la Web.
Herramientas para la Gestin de la Configuracin
Un sistema de gestin de la configuracin (Dardo de 2000) es una herramienta importante
para apoyar una ordenada proceso del proyecto. En la ingeniera Web, gestin de
configuracin se utiliza principalmente para la siguiente tareas debido a los ciclos de iteracin
cortos:

la gestin de versiones del cdigo fuente y el contenido de la aplicacin, y se regula el

acceso a la el contenido,
la creacin de configuraciones, tanto para el cdigo fuente y el contenido de la
aplicacin para establecer una poltica de liberacin ordenada,
solicitudes de cambio de la gestin y el manejo de errores y defectos,
controlar el estado del documento para monitorear el progreso del proyecto.

Creacin de variantes es menos comn en la ingeniera Web. Si se crean variantes (por

ramificacin en el rbol de desarrollo), entonces la razn es a menudo slo para completar
una versin del cliente debido a la
Gestin de Proyectos Web 188

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

ciclos de iteracin cortos, mientras que otros miembros del equipo estn trabajando en el
progreso del producto a lo largo de un segundo rama (ver seccin 10.3.4 para las notas sobre
el desarrollo paralelo de diferentes versiones).
Dado que muchos proyectos Web empezar poco a poco y luego crecen sucesivamente, es
importante utilizar sistemas de gestin de configuracin desde el inicio del proyecto, incluso si
el proyecto a continuacin, parecen "demasiado pequeo" para la gestin de configuracin de
la herramienta-compatible. El cambio a la configuracin de gestin ms adelante sera costoso
y consume mucho tiempo. Adems, la historia evolucin no puede ser rastreado a menos que
uno utiliza una herramienta de gestin de la configuracin desde el principio del proyecto.
Cuando un proyecto Web se divide en muchos sub-proyectos pequeos y sus resultados
tienen que consolidarse para cada producto (intermedio), una herramienta de gestin de la
configuracin har rpidamente convertido en una parte indispensable del proyecto de
desarrollo de aplicaciones Web (Baskerville y Levine 2001).
La gestin de configuracin permite especificar quin puede cambiar qu y cundo, y permite
Un control de estos cambios. Especialmente en la ingeniera Web, los componentes de una
aplicacin son a menudo creadas por personas con menos experiencia en ingeniera de
software. A menudo crean una gran nmero de versiones de un solo componente o
documento, perdiendo rpidamente un seguimiento de los efectos de cada una de estas
versiones, o si una versin est todava al da. Esta situacin hace que el cantidad de
documentos en los proyectos Web para crecer de manera espectacular, sobre todo porque los
documentos con contenido multimedia (denominados activos, que comprende, por ejemplo,
clips de msica o videos) requieren una gran cantidad de memoria. Muchas herramientas
disponibles para administrar las configuraciones de software que se est desarrollando (por
ejemplo, Visual Fuente Segura, http://msdn.microsoft.com/ssafe; La subversin,
http://www.subversion.com; ClearCase, http://www.rational.com/products/clearcase) tienen
dificultades en el procesamiento activos (gran demanda de memoria) y la identificacin de
diferencias de versin (formato binario). Algunos herramientas de configuracin pueden
incluso no ser capaz de procesar dichos activos debido a la demanda de datos. Esto es
probablemente la razn por la que muchas herramientas de gestin de configuracin para
multimedia se siguen desarrollado individualmente (Wallner 2001).
9.4.2 Medicin de Progreso
En el desarrollo de aplicaciones Web, a menudo se crean slo dos documentos (McDonald y
Welland 2001a). El primer documento es la especificacin del sistema, que contiene los
resultados de el anlisis de requisitos y de las decisiones de diseo. El segundo "documento"
es la banda acabada solicitud. Esta aplicacin Web normalmente se crea en una secuencia
rpida de los resultados intermedios por medio de la creacin de un prototipo muy iterativo y
evolutivo. Sharma (2001) sugiere que la etapas de iteracin debe ser tan pequea como sea
posible y tienen una funcionalidad claramente definida. cada uno de estos pasos deben ir
seguidas de una revisin que incluya una ubicacin del cliente.

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

Este enfoque es idntico con desarrollo rpido de aplicaciones (RAD), una tcnica que tiene
sido bien conocido y practicado con frecuencia en el desarrollo de software tradicional para
casi veinte aos. El desarrollo de aplicaciones Web se caracteriza por el hecho de que sus
necesidades en general, no puede estimarse de antemano, lo que significa que el tamao del
proyecto y el costo no puede ser anticipado o bien (Reifer 2002). Adems, la alta presin
habitual con respecto a un definido y muy corto plazo de entrega significa que "la calidad de
un producto a tiempo fijo debe ser estimado en lugar de los costes para un sistema bien
especificado "(Pressman 1998).
Las dificultades para anticiparse a estos factores, y el posterior control de avance de la Web
proyectos han sido resumidos por D. Reifer (vase la Tabla 9-5 adaptado de (Reifer 2002))
utilizado para desarrollar un proyecto especfico en la Web metric.4 Esta medida considera el
uso de Web-especfica componentes y la gran cantidad de reutilizacin de la siguiente
manera. Anlogo al "software objetos "del modelo COCOMO II (Boehm et al., 2000), Reifer
define los llamados" objetos Web ", permitiendo el uso de puntos de objeto COCOMO similar
para los componentes Web (Reifer 2002), donde la enlaces funcionales tienen que ser
adaptados considerablemente (ver Reifer 2002 para detalles y Olsina et al. 2005, para una
visin general de otras mtricas web).
Por supuesto, las directrices de conteo claramente definidos para los objetos Web son
importantes para obtener estimaciones significativas, similar a cualquier otra mtrica. Sin
embargo, esto no resuelve el principal problema que los componentes de diseo relacionados
con el desarrollo se cuentan, es decir, que hay ms de entrada en el desarrollador lado y
menos en el lado del cliente. Contar es un buen mtodo para medir el progreso.
Pero no responde a la pregunta de si o no el grado de cobertura puede ser objetivo mejorado.
La Tabla 9-6 resume las recomendaciones para un uso apropiado de herramientas en
proyectos Web.
Tabla 9-6 Recomendaciones para un uso apropiado de herramientas
Recomendaciones para un uso adecuado de las herramientas
1. 1 Separar el proceso de desarrollo claramente de herramientas, modelos y lenguajes.
2. 2 Ponga atencin que las herramientas se pueden utilizar durante todo el desarrollo y
son fciles de integrar.
3. 3 Comience a utilizar herramientas temprano. Un posterior introduccin / cambio de
modelos es engorroso y poco satisfactoria.
4. 4 Utilice las herramientas y procesos que apoyan de manera eficiente el enfoque
iterativo y evolutivo y comentarios de los clientes.
5. 5 Plan de tiempo extra para la formacin y la familiarizacin con cada herramienta.
6. 6 Compruebe la necesidad y consecuencias antes de cada herramienta o liberacin
cambio.
7. 7 No slo medir el progreso del proyecto, sino tambin el grado de cobertura objetiva.

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

4 IEEE (IEEE 610.12-1990 Estndar - Ingeniera de Software Terminologa) define una mtrica
como una medida cuantitativa para el grado en el que un componente del sistema o un
proceso del sistema tiene una determinada propiedad.
Gestin de Proyectos Web 190
9.4.3 Riesgos del proyecto
Riesgos en el desarrollo de software
Un riesgo es la posibilidad de una actividad para causar la prdida o dao. Sin embargo, se
habla de riesgo slo se si las consecuencias son inciertas. Esto significa que un riesgo
representa un problema potencial (Thayer y Fairley 1997).
No hay tal cosa como un proyecto sin riesgos (y los problemas derivados de las mismas). "Si
un proyecto tiene xito, entonces no tiene xito porque no haba riesgos y problemas, pero
debido a los riesgos y problemas se han manejado con xito "(Torre 1986). Cada riesgo
tambin representa una oportunidad econmica. Un ciclo de desarrollo ms corto se puede
traducir en una deseable ventaja competitiva para el tiempo de salida al mercado de un
producto. El riesgo de utilizar una nueva tecnologa puede abrir segmentos de mercado. Por
ejemplo, el uso de la plataforma .NET permite la el despliegue de los telfonos mviles
basados en Microsoft como posibles dispositivos de destino.
Los riesgos ms importantes en el desarrollo de software se han identificado y actualizada
peridicamente por B. Boehm, uno de los pioneros en el campo de la gestin de riesgos en la
ingeniera de software, ya la dcada de 1980. Tabla 9-7 (adaptado de Boehm 1998) compara
los diez riesgos ms importantes para proyectos de software en la dcada de 1980 en
comparacin con los de la dcada de 1990. Se puede observar que el trmino "proceso" ni
siquiera aparece en la lista de ms edad, mientras que representa la ms alta nueva entrada
en la dcada de 1990 list.5
Tabla 9-7 Los riesgos ms importantes en los proyectos de software de acuerdo con (Boehm,
1998)
No. 1980 1990
1. 1 Personal dficit dficit de personal
2. 2 tiempo y costo especificaciones no realistas de tiempo poco realistas y
especificaciones de costos; atencin insuficiente proceso de
3. 3 Desarrollo de malas propiedades de productos dficits en los componentes de
terceros (COTS)
4. 4 de interfaz de usuario Incomprendido propiedades de los productos mal diseados
5. 5 "sobrerregulacin" (la aplicacin innecesaria propiedades) interfaz de usuario mal
diseado
6. 6 funcionalidad Creeping cambia la arquitectura pobre, el rendimiento, la calidad de
general
7. 7 Los dficits en componentes de terceros para el Desarrollo de las propiedades del
producto equivocadas

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

8. 8 Los dficits en tareas externalizadas de construccin para los sistemas heredados o

incrustacin ellos
9. (9) Los dficit real de rendimiento en tiempo en tareas externalizadas
10. 10 Sobre-explotacin de las tecnologas de la sobreexplotacin de las tecnologas
El segundo nuevo elemento de riesgo de la dcada de 1990 representa el uso de software de
legado, es decir, el uso de sistemas de software histricamente crecido. En la dcada de
1980, era comn pensar que este problema podra ser resuelto por la re-aplicacin, que
result ser errnea. Especialmente en el desarrollo de aplicaciones web, muchos sistemas
heredados tienen que ser incorporados, tales como la gestin de datos / almacenamiento
5 B. Boehm an no ha publicado una lista actualizada de la dcada actual. sistemas. Por
ejemplo, el autor supervis un proyecto para un gran proveedor de metal piezas de repuesto
que queran ofrecer sus servicios en Internet. Dentro de este proyecto, un entorno COBOL con
una base de datos jerrquica como el sistema de informacin primaria tuvo que ser integrado
en el aplicacin web que se construir (mediante el uso de tecnologas de contenedor).
Tampoco la empresa quiere reemplazar su sistema de base de datos existente, ni tampoco
era viable, ya que toda la operacin corporativa dependido de esta base de datos, ya que la
empresa se comprometi a plazos de entrega muy cortos como su marca importante.
Riesgos especficos en Ingeniera Web
En la ingeniera Web, las principales razones de los retrasos o el fracaso total de proyectos
Web son idnticas a las principales riesgos mencionados por B. Boehm (ver Tabla 9-7).
Proyectos fracasan debido principalmente a la mala comunicacin dentro del equipo de
proyecto Web y con el cliente, es decir, los dficits personales. El segundo importante razn
es la mala comprensin de los procesos de desarrollo de una aplicacin web (McDonald y
2001a Welland).
J. Nielsen, el "gur de la pgina Web de la usabilidad", menciona la siguiente lista de los diez
de los riesgos en una proyecto web, sobre todo frente a la gestin de proyectos web (Nielsen
1997b):
1. definicin poco clara de objetivos: Muchas aplicaciones web se crean sin claridad
explicar el propsito de la aplicacin a los desarrolladores. Seccin 9.3.2 mencion
que una empresa puede hacer frente a objetivos totalmente distintos de los clientes
con una aplicacin web; un aplicacin de servicio con el servicio de asistencia cumple
totalmente diferentes tareas de un catlogo en lnea con la funcin de ordenar. Es
importante especificar claramente los objetivos y cmo los clientes pueden
beneficiarse de una aplicacin web, y para explicar estos objetivos a todos en el
equipo.
1. McDonald y Welland (2001a) menciona los objetivos y requisitos de la investigacin
pobres anlisis como las principales razones de la falta de madurez de los procesos
actuales de desarrollo de
2. Aplicaciones web.

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

3. pblico objetivo incorrecto: Muchas aplicaciones web estn fuertemente orientada a

los deseos de gestin empresarial (declaraciones de misin, de perfiles de gestin,
etc.), mientras que no frente a grupo objetivo de la aplicacin.
4. Estructura de la pgina orientada al desarrollo: La forma ms fcil para los
desarrolladores crear la contenido es siguiendo el organigrama de la contratista. Una
vez que esta estructura ha sido aplicada a una aplicacin, que es con frecuencia ya no
es posible seguir un orientado al cliente operacin. La aplicacin se centra en la
empresa y no en los usuarios.
5. A falta de coherencia debido a la subcontratacin: Si el desarrollo de aplicaciones web
diferentes de la misma empresa (o partes de una aplicacin web ms grande) est
subcontratado a diferentes empresas externas, existe un alto riesgo de que la
individualidad de estas empresas externas reflejar fuertemente en las aplicaciones,
especialmente en los contenidos y ayudas a la navegacin.
6. Cada una de estas empresas introducir su perfil y tratar de distinguirse de sus
competidores, lo que lleva a un trabajo fallido arriba con respecto a la apariencia y la
funcionamiento de la aplicacin. Pressman (2000b) sugiere definir el pblico objetivo,
su inters en el producto, y el diseo general, ya sea internamente o por una sola
empresa que funciona como un coordinador. Adems, las revisiones peridicas de los
productos intermedios son necesarias para garantizar que las incoherencias entre
partes de aplicacin pueden ser identificados temprano y eliminado.
7. 5. A falta de presupuesto para el mantenimiento: Si bien los proyectos de desarrollo de
software tradicional estimar 10% a 15% para el mantenimiento anual (Mayr 2005), el
costo de mantenimiento para las aplicaciones Web es mucho mayor debido a su
contenido de envejecimiento rpido y rpidamente evolucin de las tecnologas.
Nielsen (1997b) recomienda la estimacin de al menos 50% de la el coste de
desarrollo (100% es ms apropiado) al ao para el mantenimiento.
8. 6. Contenido reciclado: Muchos tratan de extraer el contenido para aplicaciones web
tradicionales de fuentes documentales. A menudo se pasa por alto que estos medios
estn diseados generalmente para ser ledo y analizado de forma lineal (de adelante
hacia atrs). En contraste, la Web vive en el la no linealidad de la estructura
hipermedia y su vinculacin. Las posibilidades que ofrece una estructura de soporte no
lineal no se utilizan, debido a que muchas aplicaciones y negocios los expertos han
crecido en contenido puramente lineal (libros impresos, artculos de peridicos), y que
han sido educados para crear contenido lineal para medios de comunicacin
tradicionales. el replanteamiento proceso ha sido lento en este campo.
8. Poor vinculacin: El reciclaje de contenido lineal conduce al problema de que los
enlaces son a menudo aadido "artificialmente", que puede ser perjudicial en lugar de
beneficioso (por ejemplo, al convertir manuales impresos en los sistemas de ayuda en
lnea). Adems, muchos enlaces apuntan a de orden superior pginas en lugar de
sealar que el contenido especfico. Le corresponde entonces al usuario a encontrar la
el contenido deseado desde el punto de partida general y tener la paciencia para hacer
esto.
9. Mezcla de Internet e Intranet: Mientras que una presencia en Internet representa una
empresa a la afuera, por tanto, el transporte de la cultura corporativa, las ideas de
relaciones pblicas, etc., adems de la informacin, a los tribunales a los usuarios
potenciales, una intranet sirve para apoyar de manera eficiente el trabajo de un

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

exactamente grupo de usuarios definido - el personal de la empresa. Por esta razn, la

eficacia de las aplicaciones Web en una intranet con claridad se debe dar preferencia
a travs de PR y la esttica (exagerada).
Dentro de la intranet, la productividad es la meta, y los usuarios se supone que son leales.
Esto significa que las aplicaciones de Internet y de la intranet tienen que estar claramente
separados. Cuando el desarrollo de una aplicacin web, los desarrolladores tienen que saber
de antemano si es creado para la Internet o de una intranet. 9. investigacin de mercados y la
usabilidad de investigacin confusa: Mientras que la comercializacin de investigacin evala
los deseos de los usuarios, investigacin de usabilidad est dirigido a averiguar cmo los
usuarios manejan una Web aplicacin y qu problemas tienen. La investigacin de mercados
nunca puede descubrir que funcionalidad particular de una aplicacin web es deseable, pero
no es atractivo porque es difcil de usar. La confusin entre los dos campos de investigacin
puede conducir a suposiciones errneas, similar a lo que ocurri con algunos proveedores de
automviles que, al final de la dcada de 1990, reducir en lneas directas de denuncia por
razones de coste a continuacin, felizmente notaron una notable disminucin de la demanda
casos por producto.
10. La subestimacin de la importancia estratgica de la Web: presencia web se ha
convertido tomada por supuesto para todas las empresas. A largo plazo, haciendo
caso omiso de este canal de comunicacin dar lugar a importantes desventajas
competitivas. Sin embargo, muchas empresas tienen sobreestimado la importancia de
la Web (vase el "choque puntocom") y luego han hecho el error de desarrollar una
aversin Web, perder el autobs en el largo plazo. En resumen, es importante para
cada proyecto web para soportar los riesgos ms crticos en la mente y a aseguran
que van a ser superados. La limitacin y el dominio de estos riesgos son las tareas de
gestin de riesgos, que se debatir en la prxima seccin.

Gestin de Riesgo 9.4.4

La gestin de riesgos significa tomar en consideracin de forma proactiva que existe una
cierta probabilidad de que los problemas se pueden producir en un proyecto. Esto se realiza
mediante la estimacin de la probabilidad, el anlisis de la impacto de los problemas
potenciales, y la preparacin de soluciones de problemas adecuados de antelacin (Bennatan
2000). De esta manera el desarrollo de software "sin sorpresas" se hace posible.
La Figura 9-4 muestra las tareas implicadas en la gestin del riesgo. Tanto las tareas de
gestin de riesgos y los procesos son los mismos en la ingeniera Web y en otros campos de
desarrollo de software. los nica diferencia radica en el tipo de riesgos a manipular. Nosotros
por lo tanto no vamos a discutir cada paso que participan en la gestin de riesgos en detalle y
en lugar de referirse a nuestros lectores (Mayr, 2005).
La gestin del riesgo se puede considerar como una forma de seguro que cubre un problema
inmediatamente a proporcionar una solucin tan pronto como surja el problema. En muchos

Isaac Emmanuel Rubio Giron

una aplicacin Web Ing Web II

9.4 Gestin del proceso de desarrollo de

casos, un problema que se ha analizado y se detecta a tiempo es mucho ms fcil y ms

barato de resolver que un problema que se convierte de forma inesperada. La gestin del
riesgo no proporciona recetas generales para todo tipo de casos.
Sin embargo, la literatura seala al hecho de que, mientras se trabaja en actividades de
gestin de riesgos, grupos desempean mucho mejor que los individuos (Gemmer 1997). Un
mtodo riesgo impulsada, por ejemplo, una espiral modelo, permite al grupo para integrar de
manera ptima gestin del riesgo en el desarrollo del proyecto proceso.
Aunque la gestin de riesgos no viene de forma gratuita, debe ser rentable, es decir, sus
beneficios deben compensar los costes. Sin embargo, ya que la gestin de riesgos se supone
que para evitar problemas, buena la gestin de riesgos puede hacer frente a la situacin de
justificar los costes pas para el anlisis de los problemas que Nunca ocurrido. Por esta razn,
un anlisis de coste-beneficio es indispensable para justificar el riesgo actividades de gestin
(Pressman, 2005).