Proyecto de Investigacion El Rol Del Administrador
Proyecto de Investigacion El Rol Del Administrador
Proyecto de Investigacion El Rol Del Administrador
Investigación p
presentada por
Licenciatura en Informática
i
DEDICATORIA
Dedicó el siguiente proyecto de investigación a mis padres, que siempre me han apoyado
en mis estudios. Y también a la maestra Dora por orientarme en el desarrollo de éste
proyecto.
ii
TABLA DE CO
TE
IDO
Dedicatoria ……………………………………………………………………...…….. II
Resumen ……………………………………………………………………...……….. V
Capítulo 1 Introducción……………………………………………………...……….... 1
1.1 Definición del Problema ……………………………………..……………. 2
1.2 Objetivo ……………………………………………………..……….......... 2
1.3 Alcances / Limitaciones …………………………………..……………….. 2
1.4 Pregunta de Investigación ………………………………..………………... 2
1.5 Justificación ……………………………………………,,………………..... 3
iii
Capítulo 4 Gestión del Proyecto …………………..…………………............................ 31
4.1 Gestión …………………..…………………............................................... 31
4.2 Actividades de Gestión …………………..…………………......................... 31
4.3 Planificación del Proyecto de Software …………………..………………….. 33
4.3 Análisis y Gestión de Riesgos …………………..…………………................ 34
Resultados …………………..…………………..................…………………..…………. 37
Conclusiones ……..………….................…………………..…………………................. 38
iv
RESUMÉ
En este trabajo se hace un análisis de la importancia del administrador dentro del desarrollo
de software. El administrador de proyecto es la persona que administra y controla los
recursos asignados a un proyecto, con el propósito de que se cumplan correctamente los
planes definidos. No es dueño de nada, es sólo un administrador temporal de los recursos.
v
CAPITULO 1. I
TRODUCCIÓ
En los últimos veinte años, los proyectos han tomado un papel central en el trabajo de los
jóvenes y puede considerarse hoy en día como una herramienta para el cambio social, un
eje clave para el desarrollo comunitario y también como herramienta para construir y/o
fortalecer a la sociedad civil. Como consecuencia de lo anterior la administración de
proyectos se ha convertido en una habilidad necesaria para las organizaciones de jóvenes y
un tópico recurrente para el entrenamiento para el trabajo con jóvenes.
1
1.1 Definición del Problema
Analizar la importancia del rol del administrador, dentro del desarrollo de software. El
administrador de proyectos implica una gran importancia, ya que es la persona que
administra y controla los recursos asignados a un proyecto, con el propósito de que se
cumplan correctamente los planes definidos.
1.2 Objetivo
Sólo se hablará de los modelos de ciclo de vida más utilizados, por ejemplo, modelo
en cascada, en espiral y basado en prototipos, porque son los más recomendables
para usar.
¿Qué importancia tiene el rol del administrador dentro del desarrollo de software?
2
1.7 Justificación
3
CAPITULO 2. ROLES DE DESARROLLO DE SOFTWARE
2.1 Introducción
Por ello, es que cada persona debe tener un rol dentro del grupo, que viene dado por su
experiencia y capacidades personales. En este capítulo se describen los roles que
tradicionalmente se consideran en el desarrollo de software. Estos roles son administrador
de proyecto, analista, diseñador, programador, téster, asegurador de calidad, documentador,
ingeniero de manutención, ingeniero de validación y verificación, administrador de la
configuración y por último, el cliente. Para cada uno de estos roles, se definen sus
objetivos, actividades, interacción con otros roles, herramientas a utilizar, perfil de las
personas en ese rol y un plan de trabajo.
Hay que señalar que es posible que no se requieran todos los roles en un desarrollo. Eso
dependerá del tamaño y del tipo del desarrollo. Por ejemplo, el desarrollo de un sistema de
información de gran tamaño requerirá más roles que uno de menor tamaño.
Si el tipo del proyecto está enfocado más hacia la parametrización e integración de
sistemas, requerirá algunos roles en menor medida y otros en mayor. Es posible también
que una persona realice las labores de más de un rol al mismo tiempo. Esto, sobre todo en
proyectos de desarrollo de software más pequeños. No obstante, es imprescindible que
dichas personas conozcan completamente todas sus tareas.
Por otro lado, también es posible la situación de tener más de una persona con un mismo rol
en un equipo de desarrollo. Por ejemplo, en sistemas de complejidad mediana hemos
utilizado con éxito la fórmula de tener un administrador de proyecto, dos analistas, dos
4
diseñadores, dos programadores y un téster. Eso hace un total de ocho personas en un
grupo. Las actividades de documentación y administración de configuración son asumidas
por todos los roles. Parte de las actividades de aseguramiento de calidad son asumidas por
el téster. El resto de las actividades no son realizadas. (Cockbun, 2001)
Es bastante común que, frente a una oferta de una empresa en busca de personal calificado
para su equipo de desarrollo de software, nos sintamos atraídos a postular a un rol
específico. Por ello, al final del capítulo se entrega, adicionalmente, algunas
recomendaciones básicas para postular al cargo que se desee. (Fuller, 2003)
5
crearse las mejores condiciones posibles para que se realicen las actividades. Una de las
preocupaciones principales para los administradores debe ser el tener una visión y misión
claras del proyecto, trabajando para que ambas se cumplan. En otras palabras, el foco de un
administrador de proyecto debe estar en el bosque más que en los árboles. Sin embargo,
debe cuidar cada árbol ya que cada uno de ellos contribuye al bosque. El rol de
administrador de proyecto es un rol muy importante, debido a que sus acciones y decisiones
afectan al proyecto completo. (Fuller, 2003)
2.2.1 Objetivos
2.3 Analista
6
complejidad. De esa forma, la solución del problema completo se obtiene como la suma de
las soluciones de los subproblemas de menor complejidad.
Para que el trabajo de los analistas tenga sentido para todos los integrantes del grupo, se
hace necesario ponerse de acuerdo en la forma como se realizará la especificación, así
como la forma como el resto del grupo la entenderá. Esto sugiere el uso de un estándar para
realizar la fase de análisis del problema. En el caso del estándar de la ESA, el análisis se
divide en dos fases: especificación de requisitos de usuario y especificación de requisitos de
software. Los analistas deben liderar ambas fases.
Una de las razones más frecuentes del fracaso de un desarrollo de software es la de realizar
un análisis pobre. Debido al insuficiente esfuerzo dedicado a conocer y especificar el
sistema que desea el cliente, los desarrolladores construyen sistemas que no cuentan con las
características que el cliente desea. Ese error se repite una y otra vez, y se debe básicamente
a la inexperiencia del grupo de desarrolladores.(“Roles Desarrollo Software,” s.d.)
7
2.4 Diseñador
2.4.1 Objetivos
El propósito del diseño es el de crear una estructura interna limpia y relativamente simple,
también llamada a veces una arquitectura. Un diseño es el producto final del proceso de
diseño. Así, una de las metas en el diseño de software es derivar una arquitectura del
sistema. Esta arquitectura sirve como un marco desde el cual se conducen más actividades
de diseño detallado.
8
Las buenas arquitecturas de software tienden a tener algunos atributos comunes. Entre ellos
se pueden mencionar los siguientes:
Se encuentran construidos en niveles de abstracción bien definidos, provistos a
través de una interfaz bien definida y controlada, y construida sobre facilidades
igualmente bien definidas y controladas en niveles de abstracción inferiores.
Existe una separación clara de preocupaciones entre la interfaz y la implementación
de cada nivel, haciendo posible cambiar la implementación de un nivel sin violar las
suposiciones que hicieron los clientes.
La arquitectura es simple, comportamiento común se obtiene a través de
abstracciones y mecanismos comunes.(Fuller, 2003)
2.5 Programador
El programador escribe las pruebas unitarias y produce el código del sistema. Deben
convertir la especificación del sistema en código fuente ejecutable utilizando uno o más
lenguajes de programación, así como herramientas de software de apoyo a la programación.
El éxito del desarrollo de software depende grandemente de conocimiento. Este
conocimiento no sólo corresponde a habilidades de programación y de administración de
proyectos, sino que a una percepción y entendimiento de los últimos desarrollos de la
industria del software. En los mercados actuales, rápidamente cambiantes y altamente
competitivos, se hace necesario conocer los últimos desarrollos, quien da soporte, y como
pueden beneficiar al proyecto y a la organización. A través de este conocimiento es que la
organización genera un camino hacia el éxito futuro. (Canós, Letelier, & Penadés, 2003)
9
2.5.1 Objetivos
Uno de los principales objetivos de los programadores durante su trabajo debe ser la de
reducir la complejidad del software. Algunos de los beneficios que implican la reducción de
la complejidad del programa son:
Menor cantidad de problemas de testeo.
Aumento de la productividad de los programadores.
Aumento de la eficiencia en la manutención del programa.
Aumento de la eficiencia en la modificación del programa.
Los programadores tienen una función muy importante, que es la de transformar el modelo
del sistema, en código fuente ejecutable. Es necesario que este actualizado de la industria
de software, para saber quien le puede dar soporte y como beneficiará al proyecto. Un
objetivo es el de tener el mínimo de errores en el proceso, para lograr esto se deben tener
las herramientas necesarias, por eso es importante conocer el ambiente donde se
desarrollará el software. En este rol se pueden requerir dos o más programadores. Cada
programador tiene su forma de hacer el programa, pero si trabajan en grupo deben hacerlo
bajo el mismo estándar. El diseñador puede ayudar a determinar cual lenguaje de
10
programación es el apropiado para el proyecto, aunque se relaciona con todos, excepto con
los clientes, ya que los clientes no pueden decirle que modificar del programa.
2.6 Téster
2.6.1 Objetivos
11
Construir buenos casos de tests que tengan altas probabilidades de encontrar errores
aún no descubiertos.
Demostrar que las funciones del sistema parecen estar funcionando de acuerdo a sus
especificaciones.
Proveer una buena indicación de la confiabilidad del software y algunas
indicaciones de la calidad del software. (Fuller, 2003)
Utilizan dos métodos: caja blanca, hacer lo posible por que todo marche bien, y caja negra,
encontrar errores. Debe participar en la revisión de requisitos del sistema así como estar en
contacto con los demás miembros para coordinar que todo esté bien.
Se hace necesario encontrar una nueva ecuación para el desarrollo de software. No debe ser
simplemente “producto de software = a tiempo + dentro de los costos”. Debiese ser
“producto de software = calidad + a tiempo + dentro de los costos”. Para ello, debe existir
el convencimiento individual y de la gerencia de considerar la calidad como una meta final,
junto con el cumplimiento de plazos y costos. Como se mencionó antes, la calidad
corresponde a un conjunto de atributos a cumplir por el desarrollador. Típicamente, dichos
atributos se encuentran definidos en la forma de un estándar, el que debe cumplirse.
(Fuller, 2003)
12
El asegurador de calidad se encarga de revisar y asegurarse que el trabajo de los demás
roles cumpla con los requisitos. Existen reuniones llamadas RTF que se encarga de
verificar y modificar el proyecto si es necesario hasta que no tenga errores.
13
Los problemas de software más frustrantes son frecuentemente ocasionados por una pobre
administración de la configuración. Los problemas son frustrantes debido a que requieren
tiempo para arreglarlos, y usualmente ocurren en el peor momento, y son totalmente
innecesarios. La administración de la configuración ayuda a reducir estos problemas
coordinando los productos de muchas personas que trabajan en un proyecto común. Sin ese
control, su trabajo va a producir conflictos con frecuencia, resultando en problemas como
los descritos a continuación:
Modificaciones simultáneas. Cuando dos o más personas trabajan separadamente en
el mismo programa o documento, el último en realizar los cambios puede
fácilmente destruir el trabajo del otro.
Código común. En grandes sistemas, cuando se modifican funciones comunes de un
programa, es necesario notificarlo a todos los miembros del grupo. Sin una
administración de código efectiva, no hay forma de estar seguro de encontrar y
alertar a cada uno de los miembros del equipo.
Versiones. Muchos de los grandes programas son desarrollados en releases
evolucionarios. Con uno siendo utilizado por el usuario, otro en testeo, y un tercer
en desarrollo, los arreglos de errores deben ser propagados entre ellos. En sistemas
de gran tamaño con varios releases activos en forma simultánea y muchos
programadores trabajando en arreglo de errores y mejoras, los conflictos y
confusión son bastante frecuentes.
14
Identificación de la configuración. Corresponde a una disciplina para identificar la
configuración de un ítem, documentando sus características funcionales y físicas.
Auditoria de configuración. Provee los mecanismos para determinar una línea base
formalmente establecida.
Control de configuración. Es la ejercitación de procedimientos establecidos para
clasificar, aprobar o reprobar, liberar, implementar y confirmar cambios aprobados
a especificaciones y líneas base.
Contabilidad del estatus de configuración. Contabilidad de configuración es el
registro y reporte de datos relacionados con la identificación de la configuración,
estatus de aprobación de cambios propuestos y estatus de implementación de
cambios aprobados durante todas las fases del proyecto.(“Roles Desarrollo
Software,” s.d.)
15
el producto en una determinada fase del proceso de desarrollo cumple con los requisitos
establecidos en la fase anterior. V&V es una ayuda para determinar que los requisitos de
usuario han sido implementados correcta y completamente, y existen trazas a los requisitos
del resto de las fases. El objetivo principal del proceso de V&V es el de analizar y testear el
software en forma completa durante el desarrollo para determinar que el software ejecute
sus funcionalidad correctamente, asegurarse que no ejecute funciones no definidas, y
proveer información sobre su calidad y confiabilidad. En otras palabras, las personas
dedicadas a V&V deben evaluar cuan bien el software está cumpliendo con sus requisitos
técnicos y sus objetivos de seguridad y confiabilidad relativos al sistema. También asegura
que los requisitos de usuario no están en conflicto con ninguno de los estándares o
requisitos aplicables a otros componentes del sistema. Las tareas de la V&V de software
son analizar, revisar, demostrar y testear todas las salidas del desarrollo de software.
16
2.9.1 Objetivos
El proceso de validación y verificación, se refiere a que el sistema debe estar libre de fallas,
y que cumple con las expectativas del usuario. Se encarga de que si existe un error, en el
desarrollo del software, inmediatamente informar al grupo de desarrollo acerca de éste. Se
debe asegurar que se planifiquen todos los testeos requeridos para el sistema, también
verifica y evalúa los demás roles, buscando errores o características faltantes.
2.10 Documentador
17
documentos deben ir siendo modificados para mantener el estado de los documentos a la
par con el estado de desarrollo del proyecto. Por lo anterior, debe pensarse que los
documentos van evolucionando, para mostrar el estado más reciente de desarrollo del
proyecto. Sin embargo, el objetivo principal de la documentación es de actuar como medio
de comunicación entre los miembros del equipo, incluyendo el cliente. Además, durante el
proyecto, la documentación sirve también para reducir la distorsión de ideas, ayudar al
control del proyecto, almacenar la lógica de las decisiones tomadas y hacer visibles, en
forma temprana, tanto las capacidades como las limitaciones del sistema.
18
manejar los errores y facilidades prestadas por el sistema, un documento que
describa el proceso de instalación del sistema y un manual de
administración.(Fuller, 2003)
La documentación, es para conocer la historia del proyecto, esta no se escribe al final, sino
que se va adquiriendo conforme pasan las etapas. Existen dos tipos de documentación, una,
es la documentación de procesos de elaboración, y otra es la del producto, que contiene el
desarrollo del producto. El documentador debe contar con un repositorio. Además debe
construir una manual de uso del sistema para el usuario final. El documentador sirve como
comunicador de los diferentes miembros del equipo. Sobra mencionar que tiene que ser una
persona muy ordenada.
19
2.11.1 Objetivos
20
CAPITULO 3. MODELOS DE CICLO DE VIDA DE SOFTWARE
En principio, el ciclo de vida de un proyecto software incluye todas las acciones que se
realizan sobre él desde que se especifican las características que debe tener, hasta que se
mantiene en operación. A veces (aunque no será éste nuestro caso) se incluyen en el ciclo
de vida las modificaciones que pueden realizarse al sistema para adaptarse a nuevas
especificaciones.
Podría pensarse que el ciclo de vida de un programa no tiene por qué seguir un desarrollo
"lineal", entendiendo como tal una sucesión de etapas. En principio, las distintas
actividades que se realizan son bastante independientes, y pueden llevarse (hasta cierto
punto) en paralelo. Por ejemplo, para empezar a codificar hay que tener mínimamente
claras las especificaciones que hay que cumplir. Pero (aunque no es una buena decisión,
como veremos más adelante), podría pensarse en comenzar la producción de código
mientras se completan las especificaciones, para poder irlo probando, por ejemplo. Más
adelante se harían las modificaciones necesarias.
21
Pero si el desarrollo de productos software ya es algo complejo en sí mismo (véase el
capítulo sobre Medidas o Métricas de la Complejidad del Software), aún lo complicaremos
más si intentamos "hacerlo todo a la vez", sin seguir una cuidadosa y detallada
planificación. Y esto es precisamente lo que pretenden los modelos del ciclo de vida del
software: simplificar en lo posible la gestión del proceso de desarrollo. La meta está en
añadir la mínima complejidad que sea posible a la que de por sí ya implica el software.
Desde el punto de vista del esquema HxIxO->IO, podríamos decir que los modelos del
ciclo de vida son un instrumento conceptual (I) que permite a la persona encargada (H) de
gestionar un desarrollo de software (el O será por tanto el propio proceso de desarrollo)
tratar con un problema más sencillo (el IO resultante).
Para ello, estos modelos dividen el proceso de desarrollo en unas cuantas etapas bien
diferenciadas, y definen los posibles caminos por los que se deben relacionar. Además
intentan que estos caminos lleven a un "progreso lineal", en el sentido de que antes de
comenzar una etapa se haya concluido exitosamente (con las especificaciones cumplidas) la
anterior. Sin embargo, esto no es siempre posible, y hay que recurrir a iteraciones (por
ejemplo, entre el diseño y la codificación), que nos lleven mediante aproximaciones
sucesivas a cumplir con los objetivos de la mejor forma posible.
(“15-el-desarrollo-del-software.pdf,” s.d.)
22
2. Diseño del sistema y del software. El proceso de diseño del sistema divide los
requerimientos en sistemas hardware o software. Establece una arquitectura
completa del sistema. El diseño del software identifica y describe las abstracciones
fundamentales del sistema software y sus relaciones.
3. Implementación y prueba de unidades. Durante esta etapa, el diseño del software se
lleva a cabo como un conjunto o unidades de programas. La prueba de unidades
implica verificar que cada una cumpla su especificación.
4. Integración y prueba del sistema. Los programas o las unidades individuales de
programas se integran y prueban como un sistema completo para asegurar que se
cumplan los requerimientos del software. Después de las pruebas, el sistema
software se entrega al cliente.
5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), ésta
es la fase más larga del ciclo de vida. El sistema se instala y se pone en
funcionamiento práctico. El mantenimiento implica corregir errores no descubiertos
en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades
del sistema y resaltar los servicios del sistema una vez que se descubren nuevos
requerimientos.
(Somerville Ian, 2005)
23
3.3 Iteración de procesos
Los cambios son inevitables en todos los proyectos de software grandes. Los
requerimientos del sistema cambian cuando el negocio que procura el sistema responde a
las presiones externas. Las prioridades de gestión también cambian. Cuando se dispone de
nuevas tecnologías, cambian los diseños y la implementación. Esto significa que el proceso
del software no es un proceso único; más bien, las actividades del proceso se repiten
regularmente conforme el sistema se rehace en respuesta a peticiones de cambios.
Dos de los procesos que han sido diseñados explícitamente para apoyar la iteración de
procesos son:
24
bien documentados susceptibles de cambios. En contraste, un enfoque de desarrollo
evolutivo permite que los requerimientos y las decisiones de diseño se retrasen, pero
también origina un software que puede estar débilmente estructurado y difícil de
comprender y mantener.
La entrega incremental (ver figura 2) es un enfoque intermedio que combina las ventajas de
estos modelos. En un proceso de desarrollo incremental, los clientes identifican, a grandes
rasgos, los servicios que proporcionará el sistema. Identifican qué servicios son más
importantes y cuáles menos. Entonces, se derivan varios incrementos en donde cada uno
proporciona un subconjunto de la funcionalidad del sistema. La asignación de servicios a
los incrementos depende de la prioridad del servicio con los servicios de prioridad más alta
entregados primero.
Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en servicio.
Esto significa que tienen una entrega temprana de parte de la funcionalidad del sistema.
Pueden experimentar con el sistema, lo cual les ayuda a clarificar sus requerimientos para
los incrementos posteriores y para las últimas versiones del incremento actual. Tan pronto
como se completan los nuevos incrementos, se integran en los existentes de tal forma que la
funcionalidad del sistema mejora con cada incremento entregado. Los servicios comunes se
pueden implementar al inicio del proceso o de forma incremental tan pronto como sean
requeridos por un incremento.
25
Los clientes no tienen que esperar hasta que el sistema completo se entregue
para sacar provecho de él. El primer incremento satisface los requerimientos
más críticos de tal forma que pueden utilizar el software inmediatamente.
Los clientes pueden utilizar los incrementos iniciales como prototipos y
obtener experiencia sobre los requerimientos de los incrementos posteriores
del sistema.
Existe un bajo riesgo de un fallo total del proyecto. Aunque se pueden
encontrar problemas en algunos incrementos, lo normal es que el sistema se
entregue de forma satisfactoria al cliente.
Puesto que los servicios de más alta prioridad se entregan primero, y los
incrementos posteriores se integran en ellos, es inevitable que los servicios
más importantes del sistema sean a los que se les hagan más pruebas. Esto
significa que es menos probable que los clientes encuentren fallos de
funcionamiento del software en las partes más importantes del sistema.
El modelo en espiral del proceso del software (Figura 3) fue originalmente propuesto por
Boehm (Boehm, 1988). Más que representar el proceso del software como una secuencia de
actividades con retrospectiva de una actividad a otra, se representa como una espiral. Cada
ciclo en la espiral representa una fase del proceso del software. Así, el ciclo más interno
26
podría referirse a la viabilidad del sistema. el siguiente ciclo a la definición de
requerimientos, el siguiente ciclo al diseño del sistema, y así sucesivamente.
27
Figura 3. Modelo en Espiral de Boehm para el proceso del Software (IEEE, 1988)
La diferencia principal entre el modelo en espiral y los otros modelos del proceso del
software es la consideración explícita del riesgo en el modelo en espiral. Informalmente, el
riesgo significa sencillamente algo que puede ir mal. Por ejemplo, si la intención es utilizar
un nuevo lenguaje de programación, un riesgo es que los compiladores disponibles sean
poco fiables o que no produzcan código objeto suficientemente eficiente. Los riesgos
originan problemas en el proyecto, como los de confección de agendas y excesos en los
costos; por lo tanto, la disminución de riesgos es una actividad muy importante en la
gestión del proyecto.
28
el análisis, la construcción de prototipos y la simulación. Una vez que se han evaluado los
riesgos, se lleva a cabo cierto desarrollo seguido de una actividad de planificación para la
siguiente fase del proceso.(Somerville Ian, 2005)
29
3.3.3.1 Ventajas y desventajas
Reduce el riesgo y aumenta la probabilidad de éxito.
Se puede aplicar para partes de un sistema mayor, por ejemplo la interface de
usuarios.
No se conocen niveles apropiados de calidad y documentación.
El proceso no es visible.
Requiere destrezas especiales. por ejemplo, lenguajes para prototipos rápidos
Construir software para que pueda ser modificado fácilmente es un “arte
desconocido”
(Somerville Ian, 2005)
30
CAPITULO 4. GESTIÓ
DEL PROYECTO
4.1 Gestión
Gestión son todas las actividades y tareas ejecutadas por una o más personas con el
propósito de planificar y controlar las actividades de otros para alcanzar un objetivo o
completar una actividad que no puede ser realizada por otros actuando independientemente.
(Varas, 2000)
Sin importar el campo, un gerente de proyectos exitoso debe ser capaz de visualizar el
proyecto completo de principio a fin y tener la habilidad de asegurar que esa visión se haga
realidad.(“Gestión de proyectos - Wikipedia, la enciclopedia libre,” s.d.)
31
• Selección y evaluación de personal.
• Redacción y presentación de informes.
La primera etapa de un proyecto de software implica redactar una propuesta para realizar
ese proyecto. La propuesta describe los objetivos del proyecto y cómo se llevará a cabo. La
misma incluye estimado de costo y calendarización. Justifica por qué el contrato del
proyecto se le debe dar a una organización o a un equipo en particular. La planeación de
proyectos se refiere a la identificación de actividades, hitos y entregas producidas por un
proyecto. Por lo tanto se debe bosquejar un plan para guiar el desarrollo hacia las metas del
proyecto. La estimación del costo es una actividad relacionada que se refiere al estimado de
los recursos requeridos para llevar a cabo el plan del proyecto.
32
detener el desarrollo del software o cambiar el proyecto para adecuarlo a los cambios de los
objetivos de la organización.(Randolph & Posner, 1993)
Siempre que estimamos, estamos mirando hacia el futuro y aceptamos resignados cierto
grado de incertidumbre. Aunque la estimación es más un arte que una ciencia, es una
actividad importante que no debe llevarse a cabo de forma descuidada.(Pressman, 2002)
El planificador del proyecto de software tiene que estimar tres cosas antes de que comience
el proyecto: cuánto durará, cuánto esfuerzo requerirá y cuánta gente estará implicada.
Además, el planificador debe predecir los recursos (de hardware y de software) que va a
requerir, y el riesgo implicado.(Bennatan, 1992)
33
4.4 Análisis y gestión de riesgos
En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más
allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos
previamente con nuestras acciones del pasado. La pregunta es, podemos, por tanto,
cambiando nuestras acciones actuales, crear una oportunidad para una situación diferente y,
con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo
implica cambio, que puede venir dado por cambios de opinión, de acciones, de lugares ...
[En tercer lugar,] el riesgo implica elección, y la incertidumbre que entraña la elección. Por
tanto, el riesgo, como la muerte y los impuestos, es una de las pocas cosas inevitables en la
vida.(Charette, 1992)
Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares
conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos
preocupa -¿qué riesgos podrían hacer que nuestro proyecto fracasara?-. El cambio es
nuestra preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las
tecnologías de desarrollo, en las computadoras a las que va dirigido el proyecto y a todas
las entidades relacionadas con él, al cumplimiento de la planificación temporal y al éxito en
general?. Para terminar, debemos enfrentarnos a decisiones -¿qué métodos y herramientas
deberíamos emplear, cuánta gente debería estar implicada, cuánta importancia hay que
darle a la calidad?-.
Cuando se pone mucho en juego en un proyecto de software el sentido común nos aconseja
realizar un análisis de riesgo. Y sin embargo, la mayoría de los jefes de proyecto lo hacen
informal y superficialmente, si es que lo hacen. El tiempo invertido identificando,
analizando y gestionando el riesgo merece la pena por muchas razones: menos trastornos
durante el proyecto, una mayor habilidad de seguir y controlar el proyecto y la confianza
que da planificar los problemas antes de que ocurran. El análisis de riesgos puede absorber
una cantidad significativa del esfuerzo de planificación del proyecto. Pero el esfuerzo
merece la pena. Por citar a Sun Tzu, un general chino que vivió hace 2.500 años, G Si
34
conoces al enemigo y te conoces a ti mismo, no tendrás que temer el resultado de cien
batallas». Para el jefe de proyectos de software, el enemigo es el riesgo.
(Pressman, 2002)
35
CAPITULO 5. METODOLOGÍA
36
RESULTADOS
37
CO
CLUSIO
ES
La administración de proyectos implica una gran importancia, por lo que es usada en una
gran diversidad de campos; desde proyectos espaciales, en bancos, en organizaciones, pero
no solo es aplicado a estos campos, también es usado en el desarrollo de software.
38
REFERE
CIAS BIBLIOGRAFICAS
39