EL ROL DEL ADMI
ISTRADOR
DE
TRO DEL DESARROLLO DE
SOFTWARE
Edgar I. Morales Ponce
Instituto Tecnológico de Durango
champixdeluxe@hotmail.com
RESUME
un rol en especifico para poder hacer esta actividad..
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.
o es dueño de 2.1 Administrador de Proyectos
nada, es sólo un administrador temporal de los
recursos.
1. INTRODUCCIÓN
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]
2. ROLES DE DESARROLLO DE
SOFTWARE
El desarrollo de software, es una actividad que necesita
de diferentes capacidades para poderlo llevar a cabo,
todas las capacidades es difícil encontrarlas en una sola
persona, por lo que se necesita un grupo de personas con
Debemos tener en cuenta que para llevar a cabo con éxito
el desarrollo del sistema, cada una de las personas debe
conocer perfectamente sus responsabilidades y
actividades que le son asignadas. [1]
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. [1]Se menciona un ejemplo claro de su
función, debe enfocarse a todo el bosque, sin embargo
debe cuidar a cada árbol, ya que cada árbol contribuye al
bosque, este ejemplo se refiere a que 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.
2.2 Analista
La función de un analista, es descomponer un problema
en subproblemas de menor complejidad, para así la suma
de las soluciones de los subproblemas de una solución al
problema. Una causa del fracaso de un sistema, es contar
con un análisis pobre, porque los desarrolladores crean el
proyecto que no cumple con los requisitos del cliente.
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. [1]
2.3 Diseñador
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. [1]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.4 Programador
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.[1] 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 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.5 Téster
En el desarrollo del proyecto, es posible que se presenten
errores humanos, es labor del téster detectar y eliminar
dichos errores. Utilizan dos métodos: caja blanca, hacer
lo posible por que todo marche bien, y caja negra,
encontrar errores. [1] 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.6 Asegurador de Calidad
Para la creación de software se requiere reducir costo y
tiempo, obteniendo un producto con calidad reducida, es
por eso que la calidad se toma como una meta final. 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. [1]
2.7 Administración de Configuración
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 desarrollo del software, así como su ciclo
de vida y su evolución. Su función principal es identificar
las características de los elementos del sistema, y
controlar que los cambios que se implementen sean
adecuadamente.
[1]
2.8 Ingeniero de Validación y Verificación
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. [1]
2.9 Documentador
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. [1] El documentador
sirve como comunicador de los diferentes miembros del
equipo. Sobra mencionar que tiene que ser una persona
muy ordenada.
2.10 Ingeniero en Manutención
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. [1]
3. MODELOS DE CICLOS DE VIDA DE
SOFTWARE
3.1 Ciclo de Vida del 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). [2]
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. [3]
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.
[3]
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]
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. [3]
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. [3]
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. [3]
Figura 1. Modelo en Cascada
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. [4]
Dos de los procesos que han sido diseñados
explícitamente para apoyar la iteración de procesos son:
Entrega incremental y Desarrollo en Espiral. [4]
3.3.1Entrega 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 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. [3]
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. [2]
Figura 2. Modelo Incremental
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. [3]
Una vez que un incremento se completa y entrega, los
clientes pueden ponerlo en servicio. [3]
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 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. [3]
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. [3]
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]
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. [3]
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. [3]

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 Figura 4. Modelo de Desarrollo Evolutivo
cascada puede ser el más apropiado para el desarrollo

4. GESTIÓN 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.[5]

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
si el mayor riesgo identificado es la integración de
algún momento, muchos administradores son
los subsistemas. [3]
responsables de algunas o todas de las siguientes
actividades:
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

Redacción de la propuesta.
desarrollan los planes para la siguiente fase del

Planeación y calendarización del proyecto.
proyecto. [3]

Costeo del proyecto.
Figura 3. Modelo en Espiral de Boehm para el proceso del
Supervisión y revisión del proyecto.
Software (IEEE, 1988)
Selección y evaluación de personal.

Redacción y presentación de informes. [3]
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
 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.[6]
4.4 Análisis y Gestión de Riesgos
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.[6]
REFERENCIAS
[1] D. Fuller, Apuntes de Taller de Ingenieria de Software,
2003.
[2] “15-el-desarrollo-del-software.pdf.”
[3] Somerville Ian, Ingeniería del Software, Madrid: Pearson
Educación, 2005.
[4] Rodríguez Corrales, Jiménez López, Longorio Vélez,
Orduña Cabrera, Reyes Avila, López Morales, Ochoa
Estrella, y Sánchez Islava, “Aplicación del método
evolutivo incremental en el desarrollo de un simulador
didáctico de trayectorias planas,” 2009.
[5] C.M. Varas, “Gestión de Proyectos de Desarrollo de
Software,” 2000.
[6] R.S. Pressman, Ingeniería del Software: Un Enfoque
Práctico, España: McGraw Hill, 2002.

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

La causa principal de los problemas que se

presentan al momento de realizar un proyecto
de programación es la falta de planeación.

6. CONCLUSIONES

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.

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.