ANALISIS DE LA IMPORTANCIA DEL ROL DEL

ADMINISTRADOR DENTRO DEL DESARROLLO DE

SOFTWARE

Investigación p
presentada por

EDGAR IOVAN MORALES PONCE

Licenciatura en Informática

Durango, Dgo., Diciembre del 2009

COMITÉ DE REVISIO
Dra. Dora Luz González Banales.

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

Capítulo 2 Roles de Desarrollo de Software ………………………,………………….. 4

2.1 Introducción ……………………………………………,………………...... 4
2.2 Administrador de Proyectos ………………………………………………... 5
2.3 Analista …………………………………………………………….............. 6
2.4 Diseñador ……………………………………………………………........... 8
2.5 Programador ……………………………………………………………....... 9
2.6 Téster ……………………………………………………………................. 11
2.7 Asegurador de Calidad ……………………………………………………... 12
2.8 Administrador de Configuración …………………………………………… 13
2.9 Ingeniero en Validación y Verificación ………………...………................. 15
2.10 Documentador ……………………….…………………………................. 17
2.11 Ingeniero en Manutención …………………..…………………................. 19

Capítulo 3 Modelos de Ciclo de Vida ………………….……………………................. 21

3.1 Ciclo de Vida de Software …………………………………………………... 21
3.2 Modelo en Cascada …………………..…………………............................. 22
3.3 Iteración de Procesos …………………..…………………........................... 24
3.3.1 Modelo Incremental …………………..…………………............... 24
3.3.2 Desarrollo en Espiral …………………..………………….............. 26
3.3.3 Modelo de Desarrollo Evolutivo …………………..……....……… 29

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

Capítulo 5 Metodología …………………..…………………........................................ 36

Resultados …………………..…………………..................…………………..…………. 37

Conclusiones ……..………….................…………………..…………………................. 38

Referencias Bibliográficas …………………..….…………..…………………................. 39

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.

La administración de proyectos requiere de una amplia variedad de habilidades que van

desde el análisis político y social a habilidades comunicativas, de habilidades de
administración de personas y recursos, habilidades para recabar fondos y técnicas de
evaluación.

El administrador, se encarga, como su nombre lo dice, de administrar, y controlar los

recursos disponibles para el proyecto (dinero, personas, etc.), no es dueño de nada, así que
debe dejar los recursos en la misma o mejor condición. Debe ayudar a cada integrante a
cumplir sus objetivos particulares, y al final cumplir con el objetivo general, para lograr
esto debe coordinar todas las actividades y los recursos.

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

Conocer la importancia del rol del administrador de desarrollo de software.

1.3 Alcance / Limitaciones

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.

En los demás roles de desarrollo de software, solo se tratara lo básico, cual es la

función de cada rol, es decir comprender los aspectos importantes. No se tratara las
actividades y metas, los objetivos específicos, relación con otros roles, herramientas
de trabajo, perfil, ni plan de trabajo.

La población estudiada tiene que ser específicamente, personas que conozcan el

desarrollo de software, ya que obviamente debe estar limitada a personas que estén
enteradas del tema.

1.6 Pregunta de Investigación

¿Qué importancia tiene el rol del administrador dentro del desarrollo de software?

2
1.7 Justificación

Beneficiar a las personas relacionadas con el desarrollo de software, que conozcan la

importancia que implica el rol del administrador de proyecto.

Asimismo tener conocimiento sobre el desarrollo de software, el ciclo de vida de software,

los modelos de ciclo de vida. Pero en sí saber la importancia del administrador de proyectos
dentro del desarrollo de software. Es un tema de suma importancia para un licenciado en
informática.

3
CAPITULO 2. ROLES DE DESARROLLO DE SOFTWARE

2.1 Introducción

El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en

grupo. Además, esta actividad requiere de distintas capacidades, las que no se encuentran
todas en una sola persona. Por ello, se hace necesario formar el grupo de desarrollo con las
personas que cubran todas las capacidades requeridas. Cada una de esas personas aportará
al grupo parte del total de las capacidades necesarias para llevar a cabo con éxito el
desarrollo.

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)

El hecho de que en un grupo de desarrollo no se tengan claro los roles y sus

responsabilidades y actividades asociadas, hace que se produzcan problemas. Por un lado,
es posible que una o más actividades no estén asociadas a ningún rol, con lo que el proyecto
sufrirá. Por otro lado, es posible que una o más actividades estén asociadas a más de un rol.
Esto último producirá problemas entre los miembros afectados, lo que también redunda en
problemas en el desarrollo del sistema. Por lo anterior, se hace necesario que cada miembro
conozca muy bien su rol dentro del proyecto, así como las responsabilidades y actividades
asignadas. Eso es lo que se intenta describir en este capítulo.

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)

2.2 Administrador de proyecto

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. Los
recursos asignados pueden ser recursos humanos, económicos, tecnológicos, espacio físico,
etc. En un proyecto, siempre debe existir un administrador. No obstante, un administrador
puede dirigir más de un proyecto.

El administrador no es dueño de nada, es sólo un administrador temporal de los recursos.

Como no es dueño de nada, debe dejarlos en la misma o mejor condición de cómo los
recibió. Por ello, el foco de una buena administración debe estar en el control y
coordinación de los diferentes eventos y actividades de un proyecto. Adicionalmente, deben

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

Algunos de los objetivos de un administrador de proyecto son los siguientes:

1. Tener el producto “a tiempo”, “bajo presupuesto” y con los requisitos de calidad
definidos.
2. Terminar el proyecto con los recursos asignados.
3. Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus integrantes a
cumplir sus objetivos particulares. Al final, se cumplirá el objetivo general.
4. Cumplir con éxito las diferentes fases de un proyecto, utilizando herramientas de
administración.
5. Cumplir con las expectativas del cliente.
Algunos de los objetivos específicos a cumplir por un administrador de proyecto son los
siguientes:
1. Comenzar y terminar cada actividad de acuerdo a lo planificado.
2. Lograr el mejor uso de los recursos disponibles.
3. Observar cada actividad para detectar y resolver inconvenientes.
(Fuller, 2003)

2.3 Analista

La palabra “análisis” se refiere a una característica típicamente relacionada con la

inteligencia humana. Esta se refiere a la habilidad de poder estudiar un problema de una
complejidad determinada, descomponiendo el problema en subproblemas de menor

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.

Lo anterior indica que la fase de análisis en un proyecto de construcción de software se

refiere a la especificación de un problema como la suma de subproblemas de menor
complejidad. Como el experto en el problema es el cliente, se hace necesario trabajar junto
a él para realizar la especificación correctamente. Los miembros del grupo que trabajan con
el cliente para realizar el análisis y especificación del sistema a construir son precisamente
los analistas.

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.)

Como el cliente es la persona que conoce a profundidad el problema, el analista tendrá

diversas reuniones con el cliente para determinar los objetivos del cliente, así como
también, en su caso, sugerirle al cliente lo que le conviene; para esto tiene que estar
preparado con un documento con preguntas hacia el cliente; y debido al contacto estrecho
con el cliente, debe tener capacidad de comunicación. El analista transforma los requisitos
de usuario en requisitos de software para proporcionarlos a los demás miembros, dichos
requisitos de usuario tendrá que presentarlos al cliente, para tener su opinión y
modificarlos, y volvérselos a mostrar, hasta que sean del agrado del cliente.

7
2.4 Diseñador

Es el encargado de generar el diseño del sistema. Entre sus funciones está:

Generar el diseño arquitectónico y diseño detallado del sistema, basándose en los
requisitos.

Generar prototipos rápidos del sistema (con analistas y programadores) para
chequear los requisitos.

Generar el documento de diseño arquitectónico de software (DDA), y mantenerlo
actualizado durante el proyecto.

Velar porque el producto final se ajuste al diseño realizado (funciones de téster).

En cada disciplina de la ingeniería, el diseño acompaña el enfoque disciplinado que se

requisitos y la implementación. En ingeniería de software, el propósito del diseño es la
construcción de un sistema que cumpla con los siguientes aspectos:

Satisfaga una especificación funcional dada.

Cumpla con las limitaciones del medio receptor del sistema.

Cumpla requisitos implícitos y explícitos de rendimiento y uso de recursos.

Satisfaga criterios de diseño implícitos y explícitos en la forma del artefacto
construido.

Satisfaga restricciones del mismo proceso de diseño, tal como su duración y costo, o
las herramientas disponibles para realizar el diseño. (“Roles Desarrollo Software,”
s.d.)

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)

El diseñador, se encarga de transformar los requisitos de software en un modelo de

implementación, que tiene como objetivo crear la estructura en niveles abstractos, en los
cuales el cambio de un nivel a otro, debe respetar los requerimientos del cliente. Su manera
de lograr su objetivo, es descomponiendo en subsistemas que deben estar relacionados, así
como definir las normas que tendrá dicho sistema (como acceso a datos), relacionarse con
el programador, de tal manera que escojan que lenguaje de programación a utilizar.

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.

Adicionalmente, otros objetivos importantes son:

Reducir el tiempo de codificación, aumentando la productividad del programador.

Disminuir el número de errores que ocurren durante el proceso de desarrollo.

Disminuir el esfuerzo de corregir errores en secciones del código que se encuentran
deficientes, remplazando secciones cuando se descubren técnicas más confiables,
funcionales o eficientes.

Disminuir los costos del ciclo de vida del software.

Para alcanzar estos objetivos, es importante escoger las herramientas de desarrollo

apropiadas. De eso dependerá en parte poder alcanzar los objetivos, y por lo tanto, el éxito
del proyecto. Es claro que para elegir las herramientas adecuadas, es necesario conocer el
ambiente donde el software va a correr.(Fuller, 2003)

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

El desarrollo de un sistema de software requiere la realización de una serie de actividades

de producción. En dichas actividades existe la posibilidad de que aparezcan errores
humanos. Dichos errores pueden empezar a aparecer desde el primer momento del proceso.
Por ejemplo, los requisitos del sistema pueden ser especificados en forma errónea o
imperfecta. Por ello, el desarrollo de software considera una actividad que apoye el proceso
de detección y eliminación de los errores y defectos del sistema en construcción. El
objetivo del rol de téster es precisamente realizar dichas tareas. El téster es el encargado de
asegurar la calidad de cada uno de los productos (documentos, prototipos, etc). Entre sus
tareas están:

Construir y aplicar los planes de prueba unitarios, de módulo, de sistema, y
aceptación parcial, manteniéndolos actualizados durante el proyecto.

Velar por la completitud, y exactitud (no ambigüedades) de todos los documentos
del proyecto.

Coordinar las inspecciones, y/o caminatas.

Velar por la adhesión al estándar adoptado para el desarrollo.

Velar por la calidad del producto final (cumplimiento de los requisitos). (“Roles
Desarrollo Software,” s.d.)

2.6.1 Objetivos

El objetivo principal de la labor de téster es el de diseñar tests que en forma sistemática,

permita eliminar diferentes clases de errores, realizando esto con la mínima cantidad de
tiempo y esfuerzo.
Los objetivos específicos en la labor de un téster son los siguientes:

Aplicar métodos para diseñar casos de tests efectivos.

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.

2.7 Asegurador de Calidad

En la actualidad, los factores dominantes en la administración de proyectos de software son

los tiempos y costos de desarrollo. Existen buenas razones para ello. Los tiempos y costos
de desarrollo son con frecuencia, muy grandes. Por ello, la administración se ha
concentrado en tratar de resolver dichos problemas. Sin embargo, existe un gran peligro en
esto. En la medida que crece la presión por cumplir con las fechas estipuladas, y reducir los
costos, es la calidad del producto la que sufre. Cuando se acelera el desarrollo de un sistema
que está atrasado, generalmente se corta todo lo que no se considere “esencial”, usualmente
cortando las actividades de verificación y testeo, resultando en un producto de calidad
reducida.

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.

2.8 Administrador de Configuración

La administración de la configuración es una disciplina que tradicionalmente se aplica al

desarrollo de sistemas de hardware, al desarrollo de elementos de hardware o sistemas de
hardware/software. La administración de la configuración de software corresponde a la
administración de la configuración aplicada a un sistema, o a partes de un sistema,
predominantemente correspondiente a software. Su aplicación, en conjunto con otras
disciplinas, lleva al desarrollo de sistemas en forma ordenada y estructurada.

La administración de la configuración es una disciplina que aplica dirección y vigilancia

técnica y administrativa a:

Identificar y documentar las características funcionales y físicas de items de
configuración.

Auditar los items de configuración para verificar cumplimiento de especificaciones,
control de interfaces y documentos, así como otros requisitos adicionales que pueda
definir el contrato.

Controlar cambios a los items de configuración y su documentación relacionada.

Registrar y reportar información necesaria para administrar items de configuración
en forma efectiva, incluyendo el estatus de cambios propuestos y el estatus de
implementación de cambios aprobados.

Mantener el repositorio del proyecto actualizado con las últimas versiones de todos
los entregables del proyecto.

Administrar el software utilizado para el control de versiones.

Definir y controlar perfiles de acceso a los archivos del proyecto.

Velar por la completitud y exactitud del repositorio del proyecto.

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.

La administración de configuración de software, es una disciplina que identifica la

configuración de un sistema en puntos discretos en el tiempo, con el propósito de controlar
sistemáticamente los cambios a esa configuración, manteniendo integridad y elementos
involucrados en la disciplina de la administración de la configuración de software, es
necesario formular un concepto de software. Digamos que software es información que es:

estructurada con propiedades lógicas y funcionales;

creada y mantenida en varias formas y representaciones durante su ciclo; y

ajustada para procesamiento de máquina en su estado completamente desarrollado.

Los elementos que componen la administración de configuración de software son:

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.)

La administración de configuración por lo general es enfocada al hardware, pero al

aplicarla en software determina el buen funcionamiento del sistema. Existe para apoyar el
identificar las características de los elementos del sistema, y controlar que los cambios que
se implementen sean adecuadamente.

2.9 Ingeniero en Validación y Verificación

Una de las metas necesarias de tener en cuenta en toda organización de desarrollo de

software que se considere exitosa es que el software que evoluciona, continúe satisfaciendo
las expectativas de los usuarios durante dicho proceso. Para lograr esta meta, es necesario
aplicar prácticas de ingeniería de software durante la evolución del producto. La mayoría de
estas prácticas tratan de crear y modificar software de forma de maximizar la probabilidad
de satisfacer las expectativas de sus usuarios. Otras prácticas tratan de asegurar que el
producto cumplirá con las expectativas de dichos usuarios. Estas últimas son ampliamente
conocidas como la validación y verificación de software (V&V). Validación se refiere al
proceso de evaluación del software al final de su proceso de desarrollo para asegurarse que
está libre de fallas y cumple con sus requisitos. Una falla se define como un
comportamiento incorrecto del producto. Validación se refiere al proceso de determinar si

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.

El proceso de V&V produce un Plan de Validación y Verificación de Software (PVVS),

planes individuales y reportes para tareas, reportes con resúmenes, reportes con anomalías y
un reporte de validación y verificación de software (RVVS) al final. El proceso de V&V
contiene actividades de administración de V&V y actividades técnicas de V&V de
software. Es necesario entender que el proceso de V&V tiene sus limitaciones. El objetivo
central de los enfoques de V&V de software es el de asegurarse que el producto está libre
de fallas y cumple con las expectativas de sus usuarios. Sin embargo, existen muchas
limitaciones teóricas y prácticas que hacen que este objetivo no sea posible de obtener para
el caso de muchos productos. Aunque no entraremos en detalles, estas limitaciones se
deben a:

Fundamentos teóricos.

No resulta práctico probar todos los datos.

No resulta práctico probar todos los caminos posibles en el software.

No es posible realizar una prueba de correctitud absoluta.
(“Roles Desarrollo Software,” s.d.)

16
2.9.1 Objetivos

El objetivo principal del proceso de V&V de software es el de analizar y testear en forma

completa el software durante el desarrollo para determinar que ejecuta su funcionalidad
correctamente, asegurarse que no ejecuta funciones no intencionalmente definidas y
proveer información sobre su calidad y confiabilidad. Dependiendo de las actividades de
V&V respecto a la funcionalidad y rendimiento del software, es posible identificar algunos
objetivos:

Correctitud: En que grado el producto está libre de fallas.

Consistencia: En que grado el producto es consistente consigo mismo y con otros
productos.

Necesidad: En que grado lo que hay en el producto es necesario.

Suficiencia: En que grado el producto es completo.

Rendimiento: En que grado el producto satisface los requisitos de rendimiento.

Estos objetivos proveen un marco en que es posible determinar la aplicabilidad de varios

enfoques y técnicas de V&V.(Fuller, 2003)

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

Durante el proceso de desarrollo de software, se genera una gran cantidad de

documentación. Dicha documentación debe ser almacenada en el repositorio del proyecto.
La documentación sirve, entre otras cosas, para conocer la historia del proyecto. Hay que
destacar que los documentos no se escriben al final del proyecto, sino que se van generando
junto con las diferentes fases del proyecto. A medida que el proyecto va avanzando, los

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.

Se suele clasificar la documentación en dos categorías [Sommerville]:

Documentación de procesos. Los documentos pertenecientes a esta categoría
registran la información del proceso de desarrollo y manutención del sistema. El
objetivo de esta documentación es hacer “visible” el proceso de desarrollo,
manteniendo información sobre:
• Planificación y control de procesos (planes, calendarios, estimaciones).
• Reportes sobre recursos utilizados durante el desarrollo.
• Estándares a ser utilizados en las diferentes fases.
• Registro de ideas y estrategias a ser consideradas por el equipo.
• Lógica de las decisiones de diseño.
• Detalles de la comunicación diaria entre los gerentes y el equipo de desarrollo.

Documentación de producto. Estos documentos describen el desarrollo del producto
desde los puntos de vista técnico (documentación de sistema) y usuario del sistema
(documentación de usuario), siendo el usuario un usuario final o un usuario
administrador del sistema. Estos dos tipos de documentación tienen las siguientes
características:
• La documentación de sistema incluye los documentos desde la especificación
de requisitos hasta el plan de testeo de aceptación final. Esta documentación es
usada durante la fase de manutención y debe ser actualizada cada vez que se
realizan cambios al sistema.
• La documentación de usuario debe contener una vista general de los servicios
prestados por el sistema, como usarlo, un manual de referencia que permita

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.

2.11 Ingeniero en Manutención

Hace ya casi 30 años, el proceso de manutención de software se caracterizaba con el

término “iceberg” [Canning], ya que los problemas que eran visibles eran una pequeña
parte de la enorme cantidad de problemas potenciales y costos que se escondían debajo de
la superficie.

La manutención es la última fase del proceso de desarrollo de software. Sin embargo, la

manutención toma una parte importante del presupuesto destinado al desarrollo. En general,
dichos costos son subestimados o simplemente ignorados. Por otro lado, a medida que se
desarrollan más programas, la cantidad de esfuerzo y recursos dedicados a la manutención
crecerá. Al final, algunas empresas pueden llegar a encontrarse con la barrera de la
manutención, no pudiendo abordar nuevos proyectos debido a que todos sus recursos están
dedicados a mantener programas antiguos. Sólo el 20% del trabajo de manutención es
usado arreglando errores. El 80% restante se utiliza adaptando sistemas existentes a
cambios en su ambiente externo, realizando mejoras pedidas por usuarios, y realizando
reingeniería del sistema para usos futuros. (Fuller, 2003)

19
2.11.1 Objetivos

Los objetivos a cumplir por un ingeniero de manutención son los siguientes:

Modificar el software para adaptar nuevas funciones o modificar algunas funciones
existentes.

Modernizar el software por medio de cambios al sistema.

Asegurarse de que el equipo de desarrollo esté informado de los errores encontrados
en el sistema.
(Fuller, 2003)

El ingeniero en manutención, se encarga de mantener el software, modernizándolo,

haciendo modificaciones, existen actividades de manutención preventiva o correctiva. Lo
que hace el ingeniero es diagnosticar y corregir los errores, luego adaptar al sistema los
cambios, para así satisfacer las recomendaciones del sistema.

20
CAPITULO 3. MODELOS DE CICLO DE VIDA DE SOFTWARE

3.1 Ciclo de vida de software

¿Qué es un ciclo de vida de Software?

• El periodo de tiempo que comienza cuando se concibe un software y concluye
cuando el producto ya no está disponible para su uso.
• El ciclo de vida del software típicamente incluye una fase de requisitos, una fase de
diseño, una fase de pruebas, una fase de instalación y aceptación, una fase de
operación y mantenimiento, y, con ocasiones, una fase de retirada.
• Un modelo de ciclo de vida es una abstracción particular que representa un ciclo de
vida de software.
• Un modelo de ciclo de vida se denomina con frecuencia un ciclo de vida de
desarrollo software (SDLC, siglas inglesas).
Estándar de Terminología de la Ingeniería del Software del IEEE

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.)

3.2 Modelo en cascada

El primer modelo de proceso de desarrollo de software que se publicó se derivó de procesos

de ingeniería de sistemas más generales. Este modelo se muestra en la figura 1. Debido a la
cascada de una frase a otra, dicho modelo se conoce como modelo en cascada o como ciclo
de vida del software. Las principales etapas de este modelo se transforman en actividades
fundamentales de desarrollo.
1. Análisis y definición de requerimientos. Los servicios, restricciones y metas del
sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en
detalle y sirven como una especificación del sistema.

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)

Figura 1. Modelo de Ciclo de Vida en Cascada (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:

1. Entrega incremental. La especificación, el diseño y la implementación del software

se divide en una serie de incrementos, los cuales se desarrollan por turnos.

2. Desarrollo en espiral. El desarrollo del sistema gira en espiral hacia afuera,

empezando con un esbozo inicial y terminando con el desarrollo final del mismo.

La esencia de los procesos iterativos es que la especificación se desarrolla junto con el

software. En el enfoque incremental, no existe una especificación completa del sistema
hasta que el incremento final se específica. Esto requiere un nuevo tipo de contrato, que a
los clientes grandes como las agencias del gobierno les puede ser difícil de incorporar.
(Rodríguez Corrales et al., 2009)

3.3.1 Modelo incremental

El modelo de desarrollo en cascada requiere que los clientes de un sistema cumplan un

conjunto de requerimientos antes de que se inicie el diseño y que el diseñador cumpla
estrategias particulares de diseño antes de la implementación. Los cambios de
requerimientos implican rehacer el trabajo de captura de éstos, de diseño e implementación.
Sin embargo, la separación en el diseño y la implementación deben dar lugar a sistemas

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.

Figura 2. Modelo Incremental

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.

Este proceso de desarrollo incremental tiene varias ventajas:

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.

Sin embargo, existen algunos problemas en el desarrollo incremental. Los incrementos

deben ser relativamente pequeños (no más de 20.000 líneas de código) y cada uno debe
entregar alguna funcionalidad del sistema. Puede ser difícil adaptar los requerimientos del
cliente a incrementos de tamaño apropiado. Más aún, muchos de los sistemas requieren un
conjunto de recursos que se utilizan en diferentes partes del sistema. Puesto que los
requerimientos no se definen en detalle hasta que un incremento se implementa, puede ser
difícil identificar los recursos comunes que requieren todos los incrementos.
(Somerville Ian, 2005)

3.3.2 Desarrollo en espiral

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.

Cada ciclo de la espiral se divide en cuatro sectores:

1. Definición de objetivos. Para esta fase del proyecto se definen los objetivos
específicos. Se identifican las restricciones del proceso y el producto, y se traza un
plan detallado de gestión. Se identifican los riesgos del proyecto. Dependiendo de
estos riesgos, se planean estrategias alternativas.

2. Evaluación y reducción de riesgos. Se lleva a cabo un análisis detallado para cada

uno de los riesgos del proyecto identificados. Se definen los pasos para reducir
dichos riesgo. Por ejemplo, si existe el riesgo de tener requerimientos inapropiados.
se puede desarrollar un prototipo del sistema.

3. Desarrollo y validación. Después de la evaluación de riesgos. se elige un modelo

para el desarrollo del sistema. Por ejemplo. si los riesgos en la interfaz de usuario
son dominantes. un modelo de desarrollo apropiado podría ser la construcción de
prototipos evolutivos. Si los riesgos de seguridad son la principal consideración, un
desarrollo basado en transformaciones formales podría ser el más apropiado, y así
sucesivamente. El modelo en cascada puede ser el más apropiado para el desarrollo
si el mayor riesgo identificado es la integración de los subsistemas.

4. Planificación. El proyecto se revisa y se toma la decisión de si se debe continuar con

un ciclo posterior de la espiral. Si se decide continuar. se desarrollan los planes para
la siguiente fase del proyecto.

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.

Un ciclo de la espiral empieza con la elaboración de objetivos, como el rendimiento y la

funcionalidad. Entonces se enumeran formas alternativas de alcanzar estos objetivos y las
restricciones impuestas en cada una de ellas. Cada alternativa se evalúa contra cada
objetivo y se identifican las fuentes de riesgo del proyecto. El siguiente paso es resolver
estos riesgos mediante actividades de recopilación de información como la de detallar más

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)

3.3.3 Modelo de desarrollo evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas

veces denominado como prototipado evolutivo) construye una serie de grandes versiones
sucesivas de un producto. Sin embargo, mientras que la aproximación incremental
presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo
evolutivo asume que los requerimientos no son completamente conocidos al inicio del
proyecto.

El desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo

no demanda una forma específica de observar el desarrollo de algún incremento. Así, el
modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente,
el desarrollo incremental y evolutivo puede ser combinado también.(Somerville Ian, 2005)

Figura 4. Modelo de Desarrollo Evolutivo

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)

Un gerente de proyectos es muchas veces un representante del cliente y debe determinar e

implementar las necesidades exactas del cliente, basándose en su conocimiento de la firma
que representa. La habilidad de adaptar los múltiples procedimientos internos de la parte
contratante y la forma de estrechar los lazos con los representantes seleccionados es
esencial para asegurar que los objetivos clave de costo, tiempo, calidad y, sobre todo,
satisfacción al cliente, se hagan realidad.

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.)

4.2 Actividades de gestión

Es imposible redactar una descripción estándar del trabajo de un administrador de software.

El trabajo difiere enormemente dependiendo de la organización y del producto de software
a desarrollar. Sin embargo, en algún momento, muchos administradores son responsables
de algunas o todas de las siguientes actividades:
• Redacción de la propuesta.
• Planeación y calendarización del proyecto.
• Costeo del proyecto.
• Supervisión y revisión del proyecto.

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.

La supervisión del proyecto es una actividad continua. El administrador debe tener

conocimiento del progreso del proyecto, y comparar los progresos y costos reales con los
planeados. Aunque muchas organizaciones tienen mecanismos formales para supervisar, un
administrador hábil podría formarse una imagen clara de lo que pasa llevando a cabo una
entrevista informal con el personal del proyecto. Con frecuencia, la supervisión informal
predice problemas importantes del proyecto y revela dificultades en su momento. Por
ejemplo, las entrevistas diarias con el personal del proyecto pueden exteriorizar un
problema en una falla del software. Más que esperar un informe de atraso del proyecto, el
administrador de software podría asignar un experto para resolver el problema o podría
decir si este problema se vuelve a calendarizar.(Somerville Ian, 2005)

Durante el proyecto, es normal tener varias revisiones formales de su administración. Se

hace la revisión completa del progreso y de los desarrollos técnicos del proyecto, y se toma
en cuenta el estado del proyecto junto con los propósitos de la organización encargada del
software. El tiempo de desarrollo para un proyecto grande de software puede ser de varios
años. Durante ese tiempo los objetivos organizacionales tienden obviamente a cambiar.
Estos cambios pueden significar que el software ya no se requiere más o que los
requerimientos originales del proyecto son inapropiados. La administración puede decidir

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)

4.3 Planificación del proyecto de software

La gestión de un proyecto de software comienza con un conjunto de actividades que

globalmente se denominan planificación del proyecto. Antes de que el proyecto comience,
el gestor y el equipo de software deben realizar una estimación del trabajo a realizar, de
recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su
realización.

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)

La planificación involucra la especificación de objetivos y metas para un proyecto y las

estrategias, políticas, planes y procedimientos para alcanzarlos. Todo proyecto de
ingeniería de software debe partir con un buen plan. La planificación es necesaria por la
existencia de incertezas sobre el ambiente del proyecto software y sobre fuentes externas.
La planificación enfoca su atención en las metas del proyecto, riesgos potenciales y
problemas que puedan interferir con el cumplimiento de esas metas.
(Steve McConnell, 1996)

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

El enfoque de investigación des el positivismo, ya que la información obtenida viene de

fuentes confiables de investigaciones científicas. La estrategia que se maneja es teórica. El
horizonte de tiempo es transversal, por que se dispone solo de seis meses para la realización
de la investigación. El método de recolección es datos secundarios, ya que se obtiene
información de libros, artículos y páginas de internet. El tipo de investigación es
documental, ya que se analiza de documentación existente.

36
RESULTADOS

Al concluir la investigación respecto a la importancia del administrador de proyectos de

desarrollo de software, se han logrado obtener los siguientes resultados:

• La administración procura siempre el máximo aprovechamiento de los recursos,

mediante su utilización eficiente.

• Administrar el grupo de trabajo, implica organizar y tratar los individuos en el

trabajo, de manera que cada uno de ellos pueda llegar a la mayor realización posible
de sus habilidades intrínsecas, alcanzando así una eficiencia máxima de ellos
mismos y de su grupo, y dando al proyecto del que forman parte, una ventaja
competida determinante, y por ende sus resultados óptimos.

• La causa principal de los problemas que se presentan al momento de realizar un

proyecto de programación es la falta de planeación (aplicación de procedimientos).
Para evitar esto, se requiere poner atención en la planeación de las distintas etapas
del desarrollo del producto (análisis, diseño, implementación, pruebas y
mantenimiento). Durante la planeación se decide anticipadamente qué, quién, cómo,
cuándo y por qué se hará el proyecto.

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.

La administración de proyectos es importante, ya que ofrece nuevas alternativas de

organización. Sirve para aprovechar de mejor manera los recursos críticos cuando están
limitados en cantidad y/o tiempo de disponibilidad. También ayuda a realizar acciones
concisas y efectivas para obtener el máximo beneficio.

El administrador es el responsable de llevar al éxito el proyecto, es decir, que el sistema

cumpla con los requerimientos especificados y las necesidades o expectativas del cliente o
usuario. Para lograr esto tiene que estar involucrado en todas las etapas (diseño,
programación, pruebas, etc.) del modelo de ciclo de vida que elija, debe verificar que cada
etapa se cumpla correctamente para poder pasar a la siguiente, y no tener que empezar
desde el principio (requisitos del cliente), de esta manera el administrador puede asegurar al
cliente que el sistema tiene calidad.

38
 REFERE CIAS BIBLIOGRAFICAS

15-el-desarrollo-del-software.pdf. (s.d.). . Recuperado a partir de

http://www.gsi.dit.upm.es/~fsaez/intl/libro_complejidad/15-el-desarrollo-del-
software.pdf
Bennatan, E. M. (1992). Gestión de Proyecto de Software. McGraw Hill.
Canós, J. H., Letelier, P., & Penadés, M. C. (2003). Metodologías Ágiles en el Desarrollo
de Software.
Charette, R. N. (1992). Edificio de Puentes Sobre Ríos Inteligentes (Vol. 5).
Cockbun. (2001). Desarrollo Ágil del Software. Addisson.
Fuller, D. (2003). Apuntes de Taller de Ingenieria de Software.
Gestión de proyectos - Wikipedia, la enciclopedia libre. (s.d.). . Recuperado Diciembre 8,
2009, a partir de http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_proyectos
Pressman, R. S. (2002). Ingeniería del Software: Un Enfoque Práctico (5º ed.). España:
McGraw Hill.
Randolph, W. A., & Posner, B. (1993). Gerencia de Proyectos. McGraw Hill.
Rodríguez Corrales, Jiménez López, Longorio Vélez, Orduña Cabrera, Reyes Avila, López
Morales, et al. (2009). Aplicación del método evolutivo incremental en el desarrollo
de un simulador didáctico de trayectorias planas.
Roles Desarrollo Software. (s.d.). . Recuperado Diciembre 6, 2009, a partir de
http://www.scribd.com/doc/6371079/Roles-Desarrollo-Software
Somerville Ian. (2005). Ingeniería del Software (Séptima.). Madrid: Pearson Educación.
Steve McConnell. (1996). Desarrollo y Gestión de Proyectos Informáticos. McGraw Hill.
Varas, C. M. (2000). Gestión de Proyectos de Desarrollo de Software.

39