etapas posteriores del ejercicio.

En la medida de lo posible, hacer una realimentación a las

Empresas Tipo N, sobre errores detectados, mejoras recomendadas, consejos basados en
la experiencia, riesgos a tener en cuenta y todo lo demás que consideren necesario. De la
evaluación de las propuestas, la Presentación en público de la Propuesta, comprobación
de la existencia del sitio Web, de la adjudicación, y de la evaluación del contenido de todo
el “Segundo Congelado”, la Empresa tipo E presenta al Profesor un informe. El Profesor
con base en ese informe coloca una calificación. La calificación puede ser grupal o
individual, esto último cuando se vean grandes diferencias de trabajo por parte de los
miembros del Equipo de cada una de las Empresas Tipo N. La persona que no asista a la
presentación en público de la Propuesta, tiene cero como calificación. Los estudiantes que
conformaban parte de las Empresas Tipo N que salieron del juego y no lleven a cabo la
liquidación anticipada de su Empresa y/o no liberan todo su personal, tienen cero como
calificación.

Para el ejercicio académico del curso, terminada la sesión de adjudicación, las Empresas
Tipo N que siguen en el juego, pueden realizar ajustes y cambios a la Propuesta y/o al
Contrato, como resultado de la retroalimentación recibida en el curso, o cuando se
encuentren términos inaceptables para el desarrollo del curso, o cuando el Contrato
presente fallas y/o faltantes, o contengan aspectos mal tratados o no aconsejables, o en
general por cualquier otra razón bien documentada, soportada y justificada, siempre y
cuando la solicitud de cambio sea aprobada una vez cumplido con todo rigor el proceso de
cambios establecido en cada Empresa Tipo N, se notifique de esta situación al Cliente, el
Cliente la apruebe y por intermedio del Cliente se notifique a la Empresa Tipo E para su
conocimiento y demás fines que se consideren pertinentes. Si por cualquier motivo un
Contrato se rescinde, la Empresa Tipo N que rescinde el contrato tiene que iniciar de
nuevo con todo el proceso, como si apenas hubiera aceptado la invitación a participar,
tiene que presentar una nueva Propuesta, ponerse al día en todas las otras actividades
que se hayan cumplido en el curso, y en caso de no hacerlo sus integrantes pierden el
curso y su máxima calificación final del curso es uno sobre cinco (1/5).

3.12 Inicio del Proyecto

Notificadas las Empresas Tipo N, que han sido ganadores y que por lo tanto siguen en el
juego, el siguiente hito del curso es presentar el producto en estado Alfa. Para llegar a ese
estado Alfa del producto se tienen que realizar muchas tareas, que el Pmbok [ 39 las trata
en los procesos de iniciación, procesos de ejecución y procesos de seguimiento y control.

En este documento se van a presentar algunas acciones, tareas y pasos que se deben
tener en cuenta cuando se trabaja en un Proyecto. Es importante resaltar que muchas de
esas acciones comenzaron con la presentación de la Propuesta y el Contrato, ahora

Gerencia de Proyectos de Software – Notas de clase Pág. 43

continúan y otras aparecen en este momento que inicia el Proyecto; esto nos muestra,
que muchas de las cosas que se hacen en el proyecto son de elaboración gradual, es decir,
se empiezan a trabajar en un determinado momento del Proyecto de forma global y luego
se refinan, se completan y se detallan conforme pasa el tiempo y va avanzando el
Proyecto.

3.12.1 El director del proyecto

Para situaciones como la del ejercicio académico es muy bueno seleccionar al Director del
Proyecto antes o durante la elaboración de la Propuesta, con esta asignación temprana,
el Director del Proyecto está involucrado en el trabajo desde cuando se inicia la
elaboración de la Propuesta y conoce todos los pormenores de lo que se quiere proponer
y de lo que se puede hacer. Esto evita algo que suele suceder en las Empresas cuando es
solo la parte comercial la que se encarga de la Propuesta. Los vendedores preparan la
Propuesta, buscan la forma de ganar, se comprometen con muchas cosas, ganan el
negocio y luego suelen decir: "Hicimos nuestro trabajo, ganamos la Propuesta, ya está
firmado el Contrato, ahora les pasamos a ustedes el Proyecto para que lo ejecuten". Y lo
típico que suele suceder, es que la parte técnica recibe el Contrato y empieza a encontrar
que los vendedores se comprometieron con cosas que son imposibles de cumplir
técnicamente, o dejaron un alcance demasiado ambicioso, o los recursos son escasos, o
el tiempo es muy poco, o las características de calidad están por encima de los estándares,
o existen demasiados riesgos negativos. Si ya se hizo el nombramiento de Director del
Proyecto, se puede confirmar su designación. Si no se hizo, ahora que se comienza a
trabajar en el Proyecto, es el momento de definir quién va a ser el Director del Proyecto.
En el documento de soporte, se deben indicar las características, habilidades,
competencias que consideraron que debía tener el Gerente y cómo fue la metodología de
selección.

3.12.2 Roles
Es posible que la definición de roles en el Proyecto se haya hecho cuando se elaboró la
Propuesta. Ahora que se inicia el Proyecto se pueden confirmar o crear o detallar o
cambiar o suprimir roles. Adicionalmente hay que definir funciones, obligaciones, deberes,
responsabilidades. Definidos los roles y sus características, hacer la asignación de roles a
personas. En el documento de soporte indicar las políticas utilizadas para la asignación de
roles a personas y la política seguida para colocar perfiles deseados asociados a un rol.
Por ejemplo, mostrar la política aplicada cuando se asignan roles a personas; si una
persona solo puede tener un rol o si puede tener más de un rol. Si una persona puede
tener varios roles, determinar qué roles pueden ser ejercidos simultáneamente y cuáles
roles son incompatibles para que una persona los ejerza simultáneamente.

Preparó: Ismael Castañeda Fuentes Pág. 44

3.12.3 Organización administrativa del Proyecto
Es posible que la Organización administrativa del Proyecto se haya hecho cuando se
elaboró la Propuesta. Ahora que se inicia el Proyecto se pueden confirmar o detallar o
cambiar la estructura administrativa, o definirla en este momento si no se hizo en la
Propuesta.

3.12.4 Legislación, Normas y Estándares

Muy recomendable, es que cuando se inicie un Proyecto se mire cuidadosamente que se
estén cumpliendo tanto las leyes y normas jurídicas como cumpliendo las normas y
estándares que tengan que ver con los temas que tienen que ver con el Proyecto. Esto,
por una parte, asegura que no se está trabajando en algo ilegal o prohibido o regulado y
por otro lado, que se tiene en cuenta lo que de forma obligatoria se tiene que cumplir.

3.12.5 Procesos, Procedimientos, Instructivos, Plantillas

En el ejercicio del curso, para la gerencia y gestión del Proyecto hay que utilizar los
Procesos definidos en el Pmbok[ 39. Otros procesos pueden estar relacionados con el
Producto. Muy importante definir los procesos para realizar cambios, los procesos para las
adquisiciones, los procesos para pruebas, los procesos para desarrollo, los procesos para
seguimiento y control, y en general, cualquiera que por experiencia de otros proyectos o
por experiencia de los miembros del equipo, o por necesidad, se detecte que se van a
requerir muy temprano en el proyecto. Inicialmente pueden definirse de forma amplia y
general, pero a medida que avance el proyecto, refinarlos y detallarlos.

3.12.6 El Proyecto y la Empresa

Hay que definir muy bien cómo va a ser el comportamiento del Proyecto dentro de la
organización de la Empresa, el Proyecto con el Cliente, la Empresa con el Cliente, la
Empresa con otras Empresas y el Proyecto con otras Empresas. A medida que se vaya
avanzando en el trabajo, ver qué se puede pasar del Proyecto a los activos de la Empresa y
qué cosas tiene la Empresa en sus activos que se tienen que cumplir en el Proyecto.
Recomendable, que cada vez que haya una aprendizaje o nueva experiencia, se
documenten y se anoten en las lecciones aprendidas.

3.12.7 Fases del Proyecto

El ejercicio que se va a hacer en el curso es muy simple, fácil, elemental y sencillo, pero se
va a abordar con una metodología como si fuera un gran proyecto, muy complicado, difícil
y complejo. Por eso, el problema para su solución se debe dividir para ejecutarlo por
fases. El número de fases y la forma como se ejecutan las fases, las determina cada
Proyecto. Inicialmente, se pueden tener grandes fases que correspondan a una visión
global del problema y luego las grandes fases se pueden subdividir en fases más detalladas
que pueden corresponder a aspectos particulares.

Gerencia de Proyectos de Software – Notas de clase Pág. 45

3.12.8 Caso de Negocio
En este ejercicio académico, cuando se estaba en la preparación de la Propuesta se
aconsejó elaborar un caso de negocio. Si se hizo el caso de negocio, se puede revisar,
detallar y mejorar. Si no se hizo, en este punto de inicio del Proyecto, nuevamente se
aconseja hacer un caso de negocio, pues se trata de un estudio documentado de
viabilidad desde una perspectiva de negocio donde se explica el por qué el proyecto fue
seleccionado, cómo se ajusta a los objetivos estratégicos de la Empresa, cómo agrega
valor comercial a la Empresa, se puede visualizar información importante para el Proyecto
como es la relacionada con costos, beneficios, tiempos, alcance, riesgos, opciones,
situaciones y posibles problemas. Para un Director de Proyecto, en el Caso de Negocio, es
el lugar donde encuentra la razón por la cual el proyecto se inició; influirá en la manera
como se planifique el Proyecto; en la definición del alcance del proyecto, los cambios que
pueden permitirse; puede determinar, de forma temprana, si el Caso de negocio se puede
cumplir, y puede tener en el Caso de Negocio un soporte para pronosticar si el Proyecto se
pueda completar dentro de las restricciones dadas, aún antes de que el Proyecto se haya
autorizado formalmente. Por estas razones el Director del Proyecto debe entender muy
bien el Caso de Negocio y dirigir el Proyecto de acuerdo a ese contenido. Por otra parte, el
Cliente debe estar de acuerdo con el alcance y las limitaciones expuestas en el Caso de
Negocio.

3.12.9 Enunciado del Trabajo del Proyecto SOW

En el ejercicio académico ¿hay un Enunciado del Trabajo del Proyecto SOW, o hay que
elaborarlo? El enunciado del trabajo del proyecto lo crea el Cliente, allí en una descripción
narrativa se especifica lo que quiere que se haga en el Proyecto y se especifican los
requisitos conocidos del Producto hasta ese momento, es decir, no necesariamente tiene
que estar completo y en ese estado se utiliza como entrada para el proceso Desarrollar el
Acta de Constitución del Proyecto y luego se termina durante la planificación del Proyecto.

3.12.10 Los interesados

Hay que identificar a los interesados y establecer su rol en el Proyecto; hay que identificar
sus expectativas, su poder, nivel de influencia e interés (por ejemplo: positiva, negativa o
neutral); clasificar a los interesados (por ejemplo: dentro del Proyecto, dentro de la
Empresa o externos); ver el impacto que se desea y hay que elaborar el Registro de
Interesados. El Registro de Interesados es un documento que incluye la identificación,
evaluación y clasificación de los interesados del proyecto. En el Registro de interesados
normalmente se encuentra la siguiente información: identificación del interesado con su
nombre completo, su función, su sitio de ubicación; cómo, cuándo y dónde contactarlo; su
rol en la Empresa; sus requisitos, expectativas e influencia con el Proyecto; el nivel de
participación que se desea de él en el Proyecto y el impacto esperado de su participación.

Preparó: Ismael Castañeda Fuentes Pág. 46

La información del Registro de Interesados debe ser consultada y actualizada
regularmente y debe servir de soporte para hacer el análisis de los interesados; el Registro
de Interesados tiene que ser manejado con prudencia, reserva, privacidad, oportunidad y
buen tacto, por contener información muy sensible.

3.12.11 Acta de Constitución del Proyecto

El Acta de Constitución del Proyecto es un documento que proporciona una descripción
de alto nivel del Proyecto y de las características del producto, en donde se autoriza
formalmente la existencia del Proyecto, se reconoce formalmente al Director del
Proyecto, se autoriza para que el Director del Proyecto pueda utilizar recursos de la
Empresa en las actividades del Proyecto, la Empresa acepta y se compromete con el
Proyecto. Se elabora, entre otros, a partir del enunciado de trabajo del proyecto SOW; los
acuerdos; el Contrato; el Caso de Negocio; las normas, procedimientos y costumbres de la
Empresa. Como contenido se suele incluir: propósito del proyecto; justificación del
proyecto; objetivos tangibles y medibles tanto del Proyecto como del Producto; criterios
de éxito; descripción del proyecto a alto nivel; requisitos presentados a alto nivel,
restricciones, limitaciones, supuestos, entregables y riesgos; nombramiento del director
del proyecto, indicando su responsabilidad, funciones y nivel de autoridad; se identifican
los interesados clave, especialmente los miembros del equipo del proyecto; un
cronograma resumido o un cronograma de hitos; procedimientos para solución de
conflictos; procedimientos para entrega de productos; se identifican requisitos de
aprobación del proyecto, se indica quién decide y firma aprobación. Aprobada y firmada el
Acta de Constitución del Proyecto, el Proyecto se considera formalmente autorizado.

3.12.12 "Kick off del Proyecto"

Es muy común en la vida real hacer la "presentación en sociedad del Proyecto" o "Kick off
del Proyecto". En el ejercicio académico, es decisión de cada Empresa Tipo N hacer o no el
Kick-off. Si se celebra hay que prepararlo, ejecutarlo y hacerle seguimiento.

3.12.13 Acta de inicio

En muchos proyectos, en el Contrato se establecen algunos compromisos que hay que
cumplir. Uno de ellos es el que establece que se tiene que elaborar un documento
denominado Acta de Inicio. La fecha de esa Acta típicamente se toma como la fecha
formal de inicio de proyecto y con base en esa fecha se establecen otras fechas, como la
fecha de fin del Proyecto; la vigencia para los seguros y garantías, entre otros.

3.12.14 Plan para la Dirección del Proyecto

El Plan para la Dirección del Proyecto es un documento que describe de forma integral las
estrategias, tácticas y políticas de cómo el proyecto se va a planificar, ejecutar,
monitorear, controlar y cerrar. Es el documento que fija el norte, derrotero y

Gerencia de Proyectos de Software – Notas de clase Pág. 47

comportamiento del proyecto, por eso tal vez es uno de los documentos más importantes
que hay para gerencia y gestión del proyecto.

Integra y consolida los planes de gestión subsidiarios (secundarios): el Plan de Gestión del
Alcance, el Plan de Gestión del Cronograma, el Plan de Gestión de los Costos, el Plan de
Gestión de la Calidad, el Plan de Gestión de los Recursos Humanos, el Plan de Gestión de
las Comunicaciones, el Plan de Gestión de los Riesgos, el Plan de Gestión de las
Adquisiciones, el Plan de Gestión de los Interesados, el Plan de Gestión de los Requisitos,
el Plan de mejoras del Proceso, Plan de gestión de los cambios, Plan de gestión de la
configuración, y también integra y consolida la Línea Base del Alcance, la Línea Base de
Costos, la Línea Base del Cronograma.

En la vida real, para los problemas similares al del ejercicio de clase, no se tienen planes
de gestión subsidiarios individuales separados, sino que todo está incluido en el Plan para
la Dirección del Proyecto. En la vida real sólo en los grandes proyectos se tienen los planes
subsidiarios separados. Para el ejercicio académico, aunque el problema es muy sencillo y
simple, pero como se quiere practicar el comportamiento como si se tratara de un
proyecto muy grande, muy difícil y muy complejo, los planes subsidiarios tienen que ser
separados y el Plan para la Dirección del Proyecto tiene que integrarlos, consolidarlos,
resumirlos e incorporarlos.

La elaboración del Plan para la Dirección del Proyecto es un proceso iterativo, gradual y
progresivo donde se va incrementando el nivel de detalle a medida que se cuenta con
mayor cantidad de información y con estimaciones más precisas. En el ejercicio académico
se parte de la información existente, especialmente de lo escrito en la propuesta, en el
Contrato y el Acta de Constitución del Proyecto. Típicamente esa información es el
resultado de una planificación a alto nivel, muy general, pero a medida que se avanza en
el trabajo a realizar se planifica en un mayor detalle. También influye el medio ambiente
como se haya establecido la empresa y de las políticas de la empresa con respecto a la
ejecución de proyectos.

Desde el punto de vista del Pmbok[ 39, el Plan para la Dirección del Proyecto se crea y es
salida del proceso: Desarrollar el Plan para la Dirección del Proyecto; se actualiza y es una
salida de los procesos: Dirigir y Gestionar el Trabajo del Proyecto, Monitorear y Controlar
el Trabajo del Proyecto, Realizar el Control Integrado de Cambios, Controlar el Alcance,
Desarrollar el Cronograma, Controlar el Cronograma, Controlar los Costos, Realizar el
Aseguramiento de Calidad, Controlar la Calidad, Adquirir el Equipo del Proyecto, Dirigir el
Equipo del Proyecto, Gestionar las Comunicaciones, Controlar las Comunicaciones,
Planificar la Respuesta a los Riesgos, Controlar los Riesgos, Efectuar las Adquisiciones,
Controlar las Adquisiciones, Gestionar la Participación de los Interesados y Controlar la

Preparó: Ismael Castañeda Fuentes Pág. 48

Participación de los Interesados; es entrada de los procesos: Dirigir y Gestionar el Trabajo
del Proyecto, Monitorear y Controlar el Trabajo del Proyecto, Realizar el Control Integrado
de Cambios, Cerrar el Proyecto o Fase, Planificar la Gestión del Alcance, Validar el Alcance,
Planificar la Gestión del Cronograma, Controlar el Cronograma, Planificar la Gestión de los
Costos, Controlar los Costos, Planificar la Gestión de la Calidad, Controlar la Calidad,
Planificar la Gestión de los Recursos Humanos, Planificar la Gestión de las
Comunicaciones, Controlar las Comunicaciones, Planificar la Gestión de los Riesgos,
Controlar los Riesgos, Planificar la Gestión de las Adquisiciones, Controlar las
Adquisiciones, Cerrar las Adquisiciones, Planificar la Gestión de los Interesados, Controlar
la Participación de los Interesados.

Una tarea importante del Director del Proyecto, es tener lo mejor posible desarrollado el
Plan para la Dirección del Proyecto al máximo de detalle, y hacerlo aprobar. Una vez
aprobado, hacer una gestión integral, y tener en cuenta que únicamente se puede
modificar a través del Proceso "Realizar el Control Integrado de Cambios".

3.12.15 Plan para la Gestión del Alcance del Proyecto

El Plan para la Gestión del Alcance del Proyecto es un documento y componente del Plan
para la Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas
para definir criterios, establecer las actividades, procesos, procedimientos,
documentación y recursos para definir, planificar, desarrollar, gestionar, ejecutar, hacer
seguimiento, monitorear, validar, controlar y verificar el alcance del proyecto.

En el Plan para la Gestión del Alcance del Proyecto se plasman las estrategias y políticas
relacionadas con el trabajo que se necesita elaborar para crear el producto del proyecto y
del proceso utilizado para crearlo dentro de las especificaciones aprobadas. Se establecen
políticas para definir y controlar que está o no incluido en un proyecto. Se establecen
políticas para la determinación de supuestos y restricciones del proyecto. Se definen
estrategias, criterios, políticas y procedimientos para la creación, aprobación y
mantenimiento de la Estructura de Desglose de Trabajo EDT. Se definen políticas para la
determinación de entregables, paquetes de trabajo, subdivisión de los paquetes,
descomposición y niveles de subdivisión de la EDT. Se determinan criterios para el
enfoque en la creación de la EDT (por ejemplo, por analogías, de lo general a lo particular,
de lo particular a lo general, por mapas mentales). Se establecen políticas para asignar el
responsable de cada elemento de la EDT. Se establecen políticas para la creación,
contenido, uso y mantenimiento de diccionario de la EDT. Se establecen estrategias y
políticas para definir, identificar, estructurar y documentar actividades a partir de los
paquetes de trabajo. Se establecen estrategias y políticas para definir criterios de
aceptación de entregables y estrategias y políticas para establecer procesos para

Gerencia de Proyectos de Software – Notas de clase Pág. 49

formalizar la aceptación de los entregables del proyecto. Se determinan políticas para
establecer cuentas de control; políticas para monitorear el estado del proyecto y del
alcance del producto; políticas para gestionar cambios en el alcance de proyecto y/o
producto; políticas para determinar el impacto en el alcance del proyecto y/o del
producto. Se establecen políticas para hacer uso de técnicas y herramientas para definir,
controlar y documentar el alcance. Se establecen políticas para controlar cómo se
procesan e implementan las solicitudes de cambio relativas al enunciado del alcance

Para el ejercicio académico tener en cuenta que el alcance debe estar concordante con la
Propuesta, el Contrato, el Acta de Constitución del Proyecto y el Enunciado del Trabajo del
Proyecto y la Declaración del Alcance.

Desde el punto de vista del Pmbok[ 39, el Plan de gestión del alcance se crea y es una
salida del proceso Planificar la Gestión del Alcance y se utiliza como entrada de los
procesos Recopilar Requisitos y Crear la EDT.

3.12.16 Plan para la Gestión del Cronograma

El Plan para la Gestión del Cronograma es un documento y componente del plan para la
Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas para
definir criterios, establecer las actividades, procedimientos, documentación y recursos
para definir, planificar, desarrollar, gestionar, ejecutar, monitorear y controlar el
cronograma del proyecto.

En el Plan para la Gestión del Cronograma se definen políticas para establecer hitos; se
definen políticas para establecer calendarios; se definen políticas para elaborar
cronogramas; se definen políticas con respecto de la unidades de tiempo a utilizar; se
definen políticas con respecto al contenido de los cronogramas; se definen políticas para
crear, mantener, controlar y documentar procesos que sirvan para administrar y asegurar
que el proyecto termina a tiempo; se definen políticas para establecer estimados de
tiempo, esfuerzo y duración de las actividades, paquetes de trabajo y entregables de la
estructura de desglose del trabajo, en donde además se establezcan criterios de
oportunidad (por ejemplo: preliminar, conceptual, de factibilidad, de orden de magnitud,
definitivo), se establezcan criterios para indicar exactitud, se establezcan modos de
estimación (por ejemplo, análoga, ascendente, descendente, paramétrica, por utilización
de tres valores: optimistas, pesimistas y más probables); se definen políticas para uso de
herramientas, técnicas y plantillas para el manejo del cronograma; se definen políticas
para analizar secuencias de actividades, duraciones, requisitos de recursos y restricciones
del cronograma; se definen políticas para emitir pronósticos con respecto del cronograma;
se definen políticas para monitorear y controlar el desempeño del cronograma; se definen
políticas para gestionar cambios relativos a los datos del cronograma; se definen políticas

Preparó: Ismael Castañeda Fuentes Pág. 50

para calcular, monitorear y controlar la ruta crítica del cronograma del proyecto; se
definen políticas para ajustar el cronograma aplicando adelantos o atrasos; se definen
políticas para hacer compresión del cronograma por Ejecución Rápida (Fast Tracking) o
Intensificación (Crashing); se definen políticas para hacer Nivelación de Recursos; se
definen políticas para registrar información relacionada con el cronograma; se definen
políticas para establecer coherencia con la EDT; se definen políticas para establecer
variación aceptables del cronograma; se definen políticas para establecer umbrales de
control del cronograma; se definen políticas para establecer reglas para la medición del
desempeño; se definen políticas para variación del cronograma, el índice de desempeño
del cronograma y el valor ganado; se definen políticas para formatos, frecuencia y
contenido de informes relacionados con el cronograma; se definen políticas para procesos
para la gestión del cronograma; se definen políticas para crear la línea base del
cronograma; se definen políticas para procedimientos relacionados con cambios en el
cronograma y su impacto con el alcance, costo y calidad.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión del Cronograma se crea y es
salida del proceso Planificar la Gestión del Cronograma y se usa como entrada en los
procesos: Definir las Actividades, Secuenciar las Actividades, Estimar los Recursos de las
Actividades, Estimar la Duración de las Actividades, Desarrollar el Cronograma, Identificar
los Riesgos y Realizar el Análisis Cuantitativo de Riesgos.

3.12.17 Plan para la Gestión de los Costos

El Plan para la Gestión de los Costos Es un documento y componente del Plan para la
Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas para
definir criterios, establecer las actividades, procesos, procedimientos, documentación y
recursos para definir, planificar, estructurar, desarrollar, gestionar, ejecutar el gasto,
hacer seguimiento, monitorear, validar, controlar y verificar los costos del proyecto.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de los Costos se crea y es
salida del proceso Planificar la Gestión de los Costos, y se usa como entrada en los
procesos: Estimar los Costos, Determinar el Presupuesto, Identificar los Riesgos y Realizar
el Análisis Cuantitativo de Riesgos.

3.12.18 Plan para la Gestión de la Calidad

El Plan para la Gestión de la Calidad es un documento y componente del plan para la
Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas para
definir criterios, establecer las actividades, procesos, procedimientos, documentación y
recursos para definir, planificar, desarrollar, gestionar, ejecutar, monitorear y controlar
todo lo relacionado con la calidad del proyecto y del producto.

Gerencia de Proyectos de Software – Notas de clase Pág. 51

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de la Calidad se crea y es
una salida del proceso Planificar la Gestión de la Calidad, y se usa como entrada en los
procesos: Realizar el Aseguramiento de Calidad e Identificar los Riesgos.

3.12.19 Plan para la Gestión de los Recursos Humanos

El Plan para la Gestión de los Recursos Humanos es un documento y componente del Plan
para la Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas
para definir criterios, establecer las actividades, procesos, procedimientos,
documentación y recursos para definir, planificar, desarrollar, gestionar, ejecutar, hacer
seguimiento, monitorear, validar, controlar y verificar cómo los roles y responsabilidades,
las relaciones de comunicación y la gestión de personal serán tratados y estructurados.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de los Recursos Humanos se
crea y es salida del proceso: Planificar la Gestión de los Recursos Humanos, y es entrada
de los procesos: Estimar los Costos, Adquirir el Equipo del Proyecto, Desarrollar el Equipo
del Proyecto, Dirigir el Equipo del Proyecto e Identificar los Riesgos.

3.12.20 Plan para la Gestión de las Comunicaciones

El Plan para la Gestión de las Comunicaciones es un documento y componente del Plan
para la Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas
para definir criterios, establecer las actividades, procesos, procedimientos,
documentación y recursos para definir, planificar, desarrollar, gestionar, ejecutar, hacer
seguimiento, monitorear, validar, controlar y verificar las comunicaciones entre los
interesados del proyecto.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de las Comunicaciones se
crea y es una salida del proceso Planificar la Gestión de las Comunicaciones y se utiliza
como entrada de los procesos Gestionar las Comunicaciones y Gestionar la Participación
de los Interesados.

3.12.21 Plan para la Gestión de los Riesgos

El Plan para la Gestión de los Riesgos es un documento y componente del Plan para la
Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas para
definir criterios, establecer las actividades, procesos, procedimientos, documentación y
recursos para definir, planificar, desarrollar, gestionar, ejecutar, hacer seguimiento,
monitorear, validar, controlar y verificar los riesgos que se puedan presentar en el
proyecto.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de los Riesgos se crea y es
salida del proceso: Planificar la Gestión de los Riesgos, y se usa como entrada de los

Preparó: Ismael Castañeda Fuentes Pág. 52

procesos: Identificar los Riesgos, Realizar el Análisis Cualitativo de Riesgos, Realizar el
Análisis Cuantitativo de Riesgos y Planificar la Respuesta a los Riesgos.

3.12.22 Plan para la Gestión de las Adquisiciones

El Plan para la Gestión de las Adquisiciones es un documento y componente del Plan para
la Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas para
definir criterios, establecer las actividades, procesos, procedimientos, documentación y
recursos para definir, planificar, desarrollar, gestionar, ejecutar, hacer seguimiento,
monitorear, validar, controlar y verificar las adquisiciones del proyecto.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de las Adquisiciones se crea
y es una salida del proceso Planificar la Gestión de las Adquisiciones, y se usa como
entrada en el proceso Efectuar las Adquisiciones.

3.12.23 Plan para la Gestión de los Interesados

El Plan para la Gestión de los Interesados es un documento y componente del Plan para la
Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas para
definir criterios, establecer las actividades, procesos, procedimientos, documentación y
recursos para definir, planificar, desarrollar, gestionar, ejecutar, hacer seguimiento,
monitorear, validar, controlar y verificar la participación de los interesados del proyecto.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de los Interesados se crea y
es salida del proceso Planificar la Gestión de los Interesados, y se usa como entrada en los
procesos: Recopilar Requisitos y Gestionar la Participación de los Interesados.

3.12.24 Plan para la Gestión de Personal

El Plan para la Gestión de Personal es un documento que es parte del Plan para la Gestión
de los Recursos Humanos el cual describe el modo en que ser adquieren los miembros del
equipo del proyecto, en qué momento y por cuánto tiempo se requieren. Se actualiza para
reflejar los cambios en la estructura organizacional del proyecto y en las aplicaciones de
recursos, motivados por las respuestas a los riesgos. Esto puede incluir cambios en la
tolerancia o en el comportamiento en relación con la asignación del personal, así como
actualizaciones a la carga de recursos.

Desde el punto de vista del Pmbok[ 39, el Plan para la Gestión de Personal se crea y es una
salida del proceso Planificar la Gestión de los Recursos Humanos, y es una entrada de los
procesos: Adquirir el Equipo del Proyecto y Dirigir el Equipo del Proyecto.

3.12.25 Plan de Gestión de los Requisitos

El Plan de Gestión de los Requisitos es un documento y componente del Plan para la
Dirección del Proyecto en donde se establecen las estrategias, tácticas y políticas para

Gerencia de Proyectos de Software – Notas de clase Pág. 53

indicar la manera como se recopilan, analizan, verifican, definen, documentan, gestionan,
monitorean y controlan los requerimientos de los interesados para cumplir con los
objetivos del proyecto.

En el Plan de Gestión de los Requisitos se indican qué procesos se deben seguir para
obtener los requisitos; qué procesos se deben seguir para definir y documentar las
necesidades de los interesados; qué técnicas se van a utilizar; qué herramientas se van a
usar; cómo actuar ante los cambios de requisitos, cómo se analiza el impacto de un
cambio, cómo se monitorea la implementación del cambio, cómo se le hace seguimiento y
cómo se reporta; qué niveles de autorización se requieren para aprobar cambios de
requisitos; qué recursos se deben tener en cuenta para cumplir con los requisitos; qué
consideraciones se deben tener en cuenta con respecto a requisitos de tiempo; cómo es la
relación entre fases; cómo serán analizados, documentados y gestionados los requisitos;
cómo se planifican, monitorean y reportan las actividades asociadas con los requisitos;
qué criterios y políticas se deben seguir con respecto de reglamentación, especificaciones,
estándares y normas gubernamentales o técnicas; qué política aplicar para trazabilidad de
los requisitos (por ejemplo, al usar la matriz de rastreabilidad de requisitos, o si no se usa);
qué políticas y criterios seguir ante requisitos disímiles o contradictorios; qué estrategia y
políticas seguir en caso de requisitos incompletos o cambiantes; qué políticas se deben
aplicar para priorizar los requerimientos; qué políticas y criterios aplicar para agrupar los
requerimientos, por ejemplo, en funcionales y no funcionales; qué estrategia y políticas
aplicar para requisitos de financiamiento del proyecto; qué políticas y criterios tener en
cuenta para obtener información, por ejemplo, solicitada expresamente o no solicitada u
obtenida por retroalimentación de los interesados; qué políticas y criterios utilizar para
obtener información cualitativa de tipo subjetiva o cuantitativa de tipo objetiva;
información estructurada o no; información obtenida a través de entrevistas, a través de
encuestas, a través de documentos o de sistemas existentes. Todo lo anterior sin perder
de vista que toda información obtenida de entrada o por realimentación de los
interesados se convierten en requerimientos.

Para el ejercicio académico, la gestión de los requisitos se tiene que elaborar utilizando los
lineamientos de la Norma IEEE 830, que trata sobre la Práctica recomendada para
especificaciones de software; tener en cuenta que entre mejor, más detallados y siempre
actualizados estén los requerimientos, mejor es el tiempo en el desarrollo de los
productos, ya que se cuenta con las especificaciones claramente identificadas, evitando
problemas, inconvenientes o malas interpretaciones; el plan de Gestión de los Requisitos
tiene que estar concordante con la Propuesta, el Contrato, el Acta de Constitución del
Proyecto, el Enunciado del Trabajo, las políticas de la Empresa, las expectativas de los
interesados y la experiencia del equipo de trabajo, entre otros.

Preparó: Ismael Castañeda Fuentes Pág. 54

Desde el punto de vista del Pmbok[ 39, el Plan de Gestión de los Requisitos se crea y es
una salida del proceso Planificar la Gestión del Alcance y se utiliza como entrada del
proceso Recopilar Requisitos.

3.12.26 Plan de Mejoras del Proceso

El Plan de Mejoras del Proceso es un documento y componente del Plan para la Dirección
del Proyecto que detalla los pasos a seguir para analizar procesos de dirección del
proyecto y procesos de desarrollo de producto con el fin de identificar actividades que los
mejoran e incrementan su valor.

El director del Proyecto debe conocer todos los procesos que rigen el proyecto, y según las
necesidades del proyecto debe determinar los procesos que hay que crear. Con respecto
de los procesos existentes analizar el propósito de cada proceso, sus entradas, sus salidas,
su dueño y los interesados; buscar métodos que faciliten el análisis, seguimiento y control
de los procesos, como por ejemplo, utilizando representaciones gráficas, todo ello
conducente a identificar las mejoras necesarias en el desempeño de los procesos de la
Empresa, prevenir dificultades, ayudar a ahorrar tiempo al analizar procesos y aumentar la
probabilidad de satisfacción de los interesados.

Desde el punto de vista del Pmbok[ 39, el Plan de Mejoras del Proceso se crea y es salida
del proceso: Planificar la Gestión de la Calidad, y se usa como entrada del proceso:
Realizar el Aseguramiento de Calidad.

3.12.27 Línea base del alcance

La Línea base del alcance está conformada por la versión aprobada del Enunciado del
Alcance, la Estructura de Desglose del Trabajo (EDT) y el Diccionario de la EDT.

Desde el punto de vista del Pmbok[ 39, la Línea base del alcance se crea y es salida del
proceso Crear la EDT, y se usa como entrada en los procesos: Definir las Actividades,
Estimar los Costos, Determinar el Presupuesto e Identificar los Riesgos y Realizar el
Análisis Cualitativo de Riesgos.

3.12.28 Línea base de costos

La Línea base de costos es la versión aprobada del presupuesto del Proyecto.

Desde el punto de vista del Pmbok[ 39, la Línea base de costos es una salida del proceso
Determinar el Presupuesto.

3.12.29 Línea base del cronograma

La Línea base del cronograma corresponde a la versión aprobada del cronograma del
Proyecto.

Gerencia de Proyectos de Software – Notas de clase Pág. 55

Desde el punto de vista del Pmbok[ 39, la Línea base del cronograma es una salida del
proceso Desarrollar el Cronograma.

3.12.30 Línea Base para la Medición del Desempeño (PMB)

La Línea Base para la Medición del Desempeño es un plan aprobado para el trabajo del
proyecto con respecto al cual se compara la ejecución del proyecto y se miden las
desviaciones para el control de la gestión con el fin de tomar acciones correctivas o
preventivas. Por lo general, la Línea Base para la Medición del Desempeño integra los
parámetros relativos al alcance, al cronograma y a los costos del proyecto, pero también
puede incluir parámetros técnicos y de calidad.

El Valor Planificado (PV) total se conoce en ocasiones como la Línea Base para la Medición
del Desempeño (PMB). El Valor Planificado Total para el proyecto también se conoce
como presupuesto hasta la conclusión (BAC). La Línea Base para la Medición del
Desempeño (PMB) se utiliza en la Gestión del Valor Ganado (EVM) para comprarla con el
desempeño real del cronograma y del costo.

La Línea Base para la Medición del Desempeño (PMB) incluye la reserva para
contingencias y no incluye la reserva de gestión.

3.12.31 Plan de Gestión de Cambios

El Plan de Gestión de los Cambios establece las estrategias, tácticas y políticas para el
proceso definido en la Empresa para gestionar, hacer seguimiento, monitorear, informar,
implementar y controlar los cambios en el proyecto; establece las estrategias, tácticas y
políticas para tomar decisiones con respecto de acciones correctivas, acciones preventivas
y reparación de defectos; y define políticas y documenta lo relacionado con el Comité de
Control de Cambios (CCB Change Control Board).

3.12.32 Plan de Gestión de la Configuración

El Plan de Gestión de la Configuración define los elementos que son configurables, los que
requieren un control formal de cambios, y los procesos para controlar los cambios de
estos elementos; define cómo se gestionan los cambios a los entregables, a los procesos, a
la documentación que resulte en el proyecto y a las herramientas que se utilizan en la
empresa; y documenta cómo se lleva a cabo la gestión de la configuración. Para el
ejercicio académico, se aconseja ver también la Norma IEEE 828 sobre Gestión de la
Configuración en Sistemas e Ingeniería de Software.

3.12.33 Especificación de requerimientos

La especificación de requerimientos suele ser un tema que a veces los gerentes de
Proyectos de Software no le ponen mucho cuidado. Proyectos en donde los cambios de
requerimientos son muy frecuentes y/o los requerimientos son incompletos, son

Preparó: Ismael Castañeda Fuentes Pág. 56

Proyectos que presentan múltiples problemas. Una de las muchas formas de evitar estos
problemas es haciendo un excelente trabajo relacionado con la especificación de los
requerimientos. En el ejercicio académico del curso se va a forzar la utilización de la
norma IEEE 830 que trata sobre la especificación de requerimientos de software.

3.12.34 Herramientas informáticas

Para agilizar la realización de algunos trabajos que se tienen durante la elaboración de un
Proyecto, en el curso se tienen que utilizar varias herramientas de software que van a
facilitar el trabajo de la(s) persona(s) que está(n) haciendo la planificación del proyecto, el
registro de actividades, el seguimiento a tareas, el control al trabajo, la elaboración de
informes; el almacenamiento, versionamiento, acceso, seguimiento y control de archivos;
control y gestión del producto de software, entre otros.

Se toma como política, que se van a utilizar herramientas que todos los estudiantes,
evaluadores y el profesor puedan utilizar sin problemas de permisos especiales, licencias,
autorizaciones o el lleno de requisitos inalcanzables de hardware o de software.

Por lo anterior, en primera instancia se prefieren herramientas de software de uso libre o

que la Universidad tenga licenciamiento para todos. Esto trae ventajas y desventajas.

Generalmente las herramientas de uso libre que se encuentran en Internet son limitadas
o son muy especializadas en solo un aspecto del problema. Por lo que para hacer un
trabajo, a veces se necesita de más de una herramienta para hacer el trabajo que alguien
desea en el Proyecto. Esas herramientas típicamente son independientes y no son
fácilmente integrables. Por lo tanto, cuando se utilizan, es necesario duplicar el trabajo de
proporcionar los datos que ellas requieren. Al no ser integradas, parte del trabajo que se
espera se elabore de forma automática, es necesario hacerlo de forma manual o semi-
manual.

Sin embargo, ese inconveniente de que las herramientas no sean integradas, a veces es
una gran ventaja cuando se utilizan estas herramientas no integradas en la etapa de
aprendizaje.

Por principio de diseño, las herramientas integradas piden los datos que necesitan una y
solo una vez; el sistema se encarga del procesamiento y luego proporcionan la
información en el momento que el usuario la requiere. Ellas ocultan de forma deliberada
la complejidad que ello implica, ocultan la metodología que se sigue, ocultan las
decisiones intermedias. En otras palabras, nos brindan rápida y ágilmente los resultados,
pero nosotros no sabemos el cómo se llegó a ese resultado.

Gerencia de Proyectos de Software – Notas de clase Pág. 57

A veces, el tener que usar varias herramientas y tener que realizar doble ingreso de datos,
esto es, los mismos datos a diferentes herramientas, y tener que hacer pasos intermedios,
pasos manuales y semi-manuales, permiten visibilizar y aprender mucho más sobre la
metodología para llegar a una respuesta y para aprender el valor que tienen ciertos datos,
que de otra forma pasan desapercibidos por los usuarios. También nos permiten tener
bases sólidas para responder a preguntas que los miembros de un equipo de trabajo de un
proyecto pueden hacer, cuando se les pide que llenen cierta información. Para ellos, tener
que suministrar información a un sistema, es una perdedera de tiempo y un sin sentido,
porque no saben el valor que ello tiene para un gerente. Ellos a veces ni se imaginan que
con base en esa información el gerente puede tener el control sobre el proyecto, puede
tomar decisiones y puede hacer pronósticos.

Las herramientas obligatorias a usar en el curso se deciden de común acuerdo entre

profesores y estudiantes. Entre las actividades en donde se recomienda el uso de
herramientas computacionales están las siguientes: elaboración del cronograma, manejo
de ruta crítica; consecución/asignación/registro/control de recursos en el tiempo;
programación de actividades de los miembros del equipo del proyecto; registro del
trabajo realizado por un miembro del equipo; cálculo de indicadores del proyecto; registro
de hallazgos en los productos de software que se están elaborando; seguimiento y control
a las diferentes actividades de los proyectos; para edición de textos; hojas electrónicas;
presentadores; un repositorio; un gestor de versiones de productos de software, entre
otras.

El control de acceso a esas herramientas (típicamente identificador y contraseña) estarán

a cargo de algún rol y/o persona miembro del equipo de trabajo del proyecto. En todo
caso, a los evaluadores se les debe garantizar acceso sin problema a todos los datos y
servicios en la modalidad de solo lectura como mínimo.

3.12.34.1 Herramienta para Gestión de Proyectos

Herramienta de software de uso obligatorio que permita la representación de la EDT hasta
el nivel de actividades e hitos programados a través del tiempo; facilite el desarrollo de
planes; permita analizar cargas de trabajo; permita el registro, seguimiento y control de
actividades con recursos asignados; esté en capacidad de proporcionar salidas gráficas de
cronogramas, ruta crítica e indicadores, entre otros. La herramienta tiene que estar
disponible a través de Internet para que la puedan acceder tanto los miembros del equipo
del Proyecto como los Evaluadores y el Profesor, con permisos adecuados de acceso
dependiendo de los roles.

Preparó: Ismael Castañeda Fuentes Pág. 58

3.12.34.2 Herramienta para seguimiento y control de desarrollo de software
Herramienta de software de uso obligatorio que permita a un grupo de desarrollo de
software, a un grupo de pruebas de software, y a usuarios de un producto de software,
registrar hallazgos, hacer gestión, seguimiento y control de desarrollo de software. La
herramienta tiene que estar disponible a través de Internet para que la puedan acceder
tanto los miembros del equipo del Proyecto como los Evaluadores y el Profesor, con
permisos adecuados de acceso dependiendo de los roles.

3.12.34.3 Repositorio de datos e información

Herramienta de software de uso obligatorio que permita el almacenamiento versionado
de archivos. La herramienta tiene que estar disponible a través de Internet para que la
puedan acceder tanto los miembros del equipo del Proyecto como los Evaluadores y el
Profesor, con permisos adecuados de acceso dependiendo de los roles.

3.12.34.4 Herramienta para Gestión de Configuración de Software

Herramienta de software de uso opcional, pero muy recomendable, que básicamente
permita la gestión de un producto de software.

La herramienta tiene que estar disponible a través de Internet para que la puedan acceder
tanto los miembros del equipo del Proyecto como los Evaluadores y el Profesor, con
permisos adecuados de acceso dependiendo de los roles.

3.12.34.5 Herramientas de software para oficina

Hoy en casi cualquier oficina se encuentran herramientas de software que son básicas
para el trabajo cotidiano y también son básicas para el trabajo que se va a desarrollar en
el curso. Entre las herramientas básicas están los editores, los procesadores de palabra,
las hojas electrónica y los presentadores, entre muchas otras.

Con estas herramientas, a los equipos de trabajo se les va a facilitar la elaboración de

documentos; la manipulación de datos tanto numéricos como alfabéticos; la elaboración
de cálculos numéricos, financieros y estadísticos; el registro y almacenamiento de datos;
la presentación de información. Por lo tanto, sin ser obligatorios, se puede decir que son
indispensables.

3.12.34.6 Gestor de Base de Datos

La base de datos es la herramienta de software que facilita el almacenamiento de grandes
volúmenes de información; facilita la manipulación y extracción de datos y facilita la
conversión de datos en información. En el desarrollo del curso no se coloca como
obligatoria, pero sí, muy recomendable. Puede considerarse como una buena herramienta
de trabajo para la gestión del proyecto y casi se podría decir, que indispensable en la
construcción del producto.

Gerencia de Proyectos de Software – Notas de clase Pág. 59

3.12.34.7 Lenguajes de Programación
En el curso no van a existir herramientas de software obligatorias con respecto de los
lenguajes de programación. Cada equipo de desarrollo escoge los lenguajes de
programación que va a utilizar dirigidos hacia la presentación en Internet, lenguajes para
desarrollo de aplicaciones, lenguajes para bases de datos y sólo se aconseja seleccionar los
que más dominen, que manejen con más solvencia, en los cuales tengan mayor
experiencia, los que mejor se adapten a la solución del problema.

3.12.34.8 Herramientas para pruebas de código

Cuando en una fábrica de software se produce código, hay que probarlo. En el ejercicio
académico del curso se aconseja que para efectuar las pruebas de software se utilicen
herramientas de software especialmente elaboradas para prueba de código y también que
utilicen las facilidades para efectuar pruebas que proporcionan las mismas herramientas
con las cuales se elabora el código de los programas.

3.12.34.9 Software para administración, gestión, publicación, mantenimiento del

sitio Web
En el ejercicio académico del curso se exige que toda la información se tiene que publicar
en Internet, a diferentes niveles de acceso, por lo tanto es aconsejable que lo hagan con
herramientas de software especialmente elaboradas para tales fines.

3.12.34.10 Ambiente Integrado de Desarrollo

El Ambiente Integrado de Desarrollo (IDE Integrated Development Environment) es un
software opcional, pero muy recomendado, que facilita el trabajo de los desarrolladores
de software. Permite en un solo ambiente, utilizar varios lenguajes y productos; tiene
múltiples servicios como compilación de programas fuente, depuración de programas,
pruebas de programas, ejecución de programas, intérpretes de lenguajes, acceso a
sistemas de almacenamiento versionado, acceso a programas de gestión de configuración,
conexiones a servidores de bases de datos, conexiones a otros servicios de software, entre
otros.

3.13 Desarrollo del Producto

Cada Empresa tipo N tiene amplia libertad para seleccionar la metodología de cómo va a
desarrollar el Producto. La parte de la solución técnica es donde cada Empresa tipo N
debe seleccionar la metodología que más le convenga teniendo en cuenta el conocimiento
que tengan los miembros del equipo, de las destrezas, la experiencia y conveniencia, pero
siempre siguiendo los lineamientos del Plan para la Dirección del Proyecto y ejecutando
todo lo contemplado durante la planificación.

Preparó: Ismael Castañeda Fuentes Pág. 60

Desde el punto de vista del ejercicio del curso se va a pedir que en el desarrollo del
producto se muestre el producto en tres estados: un estado alfa, un estado beta y el
producto liberado o producto final. También se va a hacer énfasis para que las
especificaciones del software sean lo más completas posibles, para que la documentación
que acompañe al producto sea completa y se va a insistir que el aseguramiento de la
calidad es una tarea que se debe llevar a cabo durante todo el ciclo de vida del Proyecto.

3.14 Pruebas de Software

El aseguramiento de la calidad es un tema que debe ser catalogado como muy importante
en la gestión de un Proyecto. Por esta razón las pruebas de software, que son una parte
del aseguramiento de la calidad, deben ser muy bien definidas, planificadas, ejecutadas,
controladas y terminadas.

Probar un producto se software no es un asunto elemental, por el contrario puede

resultar complejo y hasta difícil, por lo tanto cuando se esté pensando en las pruebas, hay
que definir muy bien qué se espera de ellas; cuáles son los objetivos; qué pruebas se van a
realizar; cómo se van a realizar; a cargo de quién se van a realizar; qué métricas se van a
utilizar; qué herramientas de software se van a utilizar; cómo se les va a hacer
seguimiento y control; qué reportes se esperan producir y cómo se dan por terminadas las
pruebas.

Típicamente se encuentran pruebas unitarias, pruebas integradas, pruebas orientadas al

riesgo, pruebas de caja negra, pruebas de caja blanca, pruebas funcionales, pruebas
estructuradas, pruebas de regresión, pruebas de carga, pruebas de transición de estado,
pruebas de tablas de decisión, pruebas de escenarios, pruebas de casos de uso, pruebas
de accesibilidad, pruebas de compatibilidad, pruebas de conversiones, pruebas de
recuperación de desastres, pruebas de copias de seguridad, pruebas de recuperación a
partir de copias de seguridad, pruebas de instalación, pruebas de interoperabilidad,
pruebas de mantenibilidad, pruebas de rendimiento, pruebas de portabilidad, pruebas de
procedimientos, pruebas de fiabilidad, pruebas de seguridad, pruebas de estabilidad,
pruebas de usabilidad, pruebas de eficiencia, pruebas de escalabilidad, pruebas de
capacidad y muchas otras.

Para mayor información sobre este tema es aconsejable ver las normas IEEE 829 y sobre
todo la norma ISO/IEC/IEEE29119 que tratan sobre pruebas de software.

En el ejercicio académico del curso, las pruebas de software las debe hacer un equipo de
personas dentro de cada Empresa tipo N, y también es una responsabilidad de la Empresa
tipo E, que debe recibir y aceptar los productos de software.

Gerencia de Proyectos de Software – Notas de clase Pág. 61

3.15 Software en estado Alfa
Cuando se desarrolla un Producto de Software en una Fábrica de Software generalmente
se hace un desarrollo por fases en donde típicamente la primera fase se denomina fase
Alfa. Cada Empresa tipo N tiene que definir los entregables que se deben tener al final de
la fase Alfa. Como mínimo se debe mostrar un Producto que implemente los componentes
básicos de la maqueta diseñada; se pueda “navegar” por esa maqueta; puede ser
inseguro; puede ser inestable; puede o no tener alguna funcionabilidad; tiene que estar
en ambiente de producción, es decir, no se recibe en ambiente de desarrollo; se tiene que
poder acceder por Internet; el producto en estado Alfa tiene que estar disponible durante
las veinticuatro horas del día (24h/d) por lo menos ocho (8) días contados a partir del
momento de su presentación para dar cumplimiento al tercer hito del curso. Entre otros
objetivos mínimos, se debe tener diseñada toda la arquitectura de la solución, diseñado el
modelo de base de datos de soporte para el sistema; definidos e iniciados los manuales
que van a acompañar el Producto; definida e implementada la metodología de desarrollo
del Producto; definidas e implementadas las políticas para los programadores; definidas e
implementadas las políticas para las pruebas; definidas e implementadas las políticas para
el control de cambios; definidas e implementadas las políticas para para el versionamiento
del producto; definidas e implementadas las políticas para instalación y despliegue del
producto en ambiente de producción; definidas las actividades que el equipo de cada
Empresa N tiene que realizar con respecto al Producto en estado Alfa una vez presentado;
definidas e implementadas las políticas de seguridad, en especial las que tienen que ver
con las garantías de amplio acceso para los evaluadores y calificadores, desde luego, todo
lo anterior dentro del marco establecido en el Plan para la Dirección del Proyecto.

3.16 Tercera reunión para Control

Ocho días antes de la presentación en público del Producto en estado Alfa, la Empresa
tipo E se reúne con cada una de las Empresas tipo N con el fin de hacer seguimiento y
control de las actividades para cumplir con éxito el tercer hito del curso, el cual consiste
en que cada Empresa Tipo N presenta su Producto en estado Alfa; realiza una
presentación en público del trabajo realizado para llegar a este punto del Proyecto y
muestra el producto funcionando en estado Alfa en ambiente de producción.

La tercera reunión para control se hace en una sesión de clase, según el calendario del
curso, previa una determinación de hora y duración de la reunión. La Empresa tipo E hace
la agenda, preside la reunión, desarrolla la reunión y se encarga de las actas, excepto que
el acta con una o varias de las Empresas tipo N, durante la reunión, se designe de su
elaboración a otra persona.

Preparó: Ismael Castañeda Fuentes Pág. 62

La Empresa tipo E, tiene como insumos los informes semanales de las diferentes Empresas
tipo N. Con ellos, entre otras actividades, se recomienda que observen la planificación de
tareas, a nivel de cada persona, de equipo de trabajo y del proyecto; su cumplimiento; su
organización, y ojalá el equilibrio de tareas, esfuerzos y responsabilidades de los
participantes. También observar las desviaciones que se presenten de lo ejecutado con
respecto de lo planeado; se sugieran soluciones; se den recomendaciones; se miren los
riesgos y se haga un pronóstico.

Se debe insistir en que el producto en estado Alfa se tiene que presentar en ambiente de
producción; accesible por Internet para los miembros de cada equipo de proyecto que han
participado en su elaboración y a los evaluadores; disponible por lo menos durante ocho
(8) días, las veinticuatro (24) horas del día. Esto quiere decir, que por ningún motivo se va
a aceptar el producto en ambiente de desarrollo y tampoco se acepta que esté disponible
solo por espacios de tiempo. Para los evaluadores, deben garantizar acceso amplio y
suficiente para que puedan evaluar y calificar. También se debe insistir en la importancia
de registrar todos los datos para que se puedan fácilmente presentar los indicadores de
cada persona, del equipo y del proyecto.

De especial importancia, es que los temas tratados y los acuerdos queden registrados y
consolidados en el acta de la reunión.

Se siguiere que la Empresa tipo E, tenga preparado un formato de acta de la reunión, de

tal forma que su llenado sea rápido, ágil y práctico. Que antes de finalizar la reunión
quede protocolizada el Acta de la reunión y lista para su publicación, aprovechando las
facilidades tecnológicas que hoy existen, como el escaneo de documentos y
comunicaciones a través de Internet utilizando dispositivos móviles.

Terminadas las reuniones de Control con cada una de las Empresas tipo N, la Empresa
Tipo E, presenta un informe al Profesor de lo sucedido. El Profesor con base en ese
informe coloca una calificación. La persona que no asista, tiene cero como calificación.

3.17 Actividades antes de la presentación del producto en estado

Alfa
El día anterior a la Presentación del producto en estado Alfa, cada Empresa Tipo N, antes
del mediodía tiene que entregar al Profesor, en físico (CD, DVD, USB) el “Tercer
Congelado” de lo trabajado por ellos. El Profesor registra la entrega del “Tercer
Congelado”, lo hace llegar a la Empresa Tipo E para que ellos lo utilicen como una de las
entradas para evaluar las Empresas Tipo N. Con esto se busca que las tareas se elaboren
con antelación, la presentación del producto en estado Alfa esté muy bien preparada y no
improvisada; adicionalmente facilita el trabajo de los evaluadores, que van a tener

Gerencia de Proyectos de Software – Notas de clase Pág. 63

información antes de la Presentación y cuentan con mayor tiempo para revisar
cuidadosamente el “Tercer Congelado”.

El “Tercer Congelado” tiene que contener todo el trabajo adelantado hasta este momento
por cada una de las Empresas tipo N. Desde el punto de vista académico, es el sitio donde
debe estar absolutamente todo lo trabajado por las personas en el desarrollo del Proyecto
por cada una de las Empresas tipo N, incluido el código fuente de los programas. La razón
principal para exigir lo anterior, es para poder evaluar y calificar el trabajo adelantado. Lo
que no se vea clara y objetivamente, no se califica. La otra razón para exigir el “Tercer
Congelado”, es para tener trazabilidad, hacer seguimiento, poder controlar, poder medir
los avances reales del Proyecto y para ver los aciertos y equivocaciones en la gerencia,
dirección y gestión del Proyecto.

En el “Tercer Congelado” se tienen que encontrar las respuestas a muchos interrogantes

que posiblemente formulen los evaluadores.

Preguntas como las siguientes: ¿Cómo se planificó? ¿Se ejecutó lo que se planificó? ¿Se ha
hecho un registro cuidadoso de las tareas realizadas? ¿Cuáles son las desviaciones? ¿Qué
ajustes se han hecho? ¿Cómo es el comportamiento del desarrollo del producto con
respecto del alcance? ¿Con respecto del tiempo? ¿Con respecto de los costos? ¿Con
respecto de la calidad? ¿Están absolutamente seguros que eso es lo que desea el cliente?
¿Cómo validaron los resultados de las entrevistas, encuestas y demás fuentes de
información? ¿Cuál es la ruta crítica? ¿Tiene suficiente holgura el proyecto en tiempo y
costos? ¿Los recursos humanos han sido suficientes? ¿Cómo se han gestionado los
riesgos? ¿Qué nuevos riesgos han aparecido? ¿Qué tanto impacto pueden tener los
nuevos riesgos? ¿Cómo se ha gestionado el tema de las previsiones para atender las
eventualidades? ¿Cómo han gestionado, planificado, ejecutado, controlado y cerrado las
adquisiciones? ¿Cómo han gestionado a los interesados? ¿Cómo se ha gestionado lo
relacionado con conflictos? ¿Qué metodologías han utilizado para el desarrollo del
Producto? ¿Las metodologías seleccionadas han funcionado o han tenido inconvenientes?
¿Qué normas han seguido para la construcción del software? ¿Cómo han gestionado al
personal técnico que desarrolla el producto? ¿Cómo se ha gestionado el aseguramiento
de la calidad? ¿Cómo se han gestionado las comunicaciones? ¿Los canales de
comunicación han funcionado o han tenido problemas? ¿Cómo se ha gestionado el
seguimiento y control al desarrollo del Producto y al Proyecto? ¿Qué técnicas y
herramientas han utilizado para recolección de información? ¿Hicieron entrevistas? ¿A
quiénes entrevistaron? ¿Usaron encuestas? ¿Qué población seleccionaron para las
encuestas? ¿Cuáles fueron las encuestas? ¿Cuáles fueron los resultados de las encuestas?
¿Encontraron modelos de negocio similares? ¿Encontraron sistemas desarrollados

Preparó: Ismael Castañeda Fuentes Pág. 64

similares? ¿Qué otras fuentes de información utilizaron? ¿Qué metodologías utilizaron
para el diseño? ¿Cómo hicieron el desarrollo e implementación de lo diseñado? ¿Los
estimados de tiempo y costo han resultado acertados? ¿Cómo es el modelo de datos
resultante para soportar el sistema diseñado? ¿Ya están definidos todos los componentes
de la arquitectura de la solución? ¿Qué lenguajes y/o interpretadores seleccionaron para
hacer la programación? ¿Qué políticas pusieron en práctica con respecto a la calidad del
Producto? ¿Qué pruebas tienen previstas para el sistema? ¿Qué pruebas realizaron y
cuáles fueron sus resultados? ¿Qué repositorios han utilizado y cómo han sido sus
resultados? ¿Han utilizado algún sistema de trabajo colaborativo, qué resultados han
tenido? ¿Están utilizando algún software para la gestión de versiones del Producto? ¿Lo
pusieron en práctica para sacar el estado Alfa del Producto? ¿El Proyecto va a terminar
exitosamente?

3.18 Presentación en público del Producto en estado Alfa

El día programado para la presentación en público del Producto en estado Alfa, según el
calendario del curso, cada Empresa Tipo N muestra al público el trabajo que ha
adelantado y muestra el funcionamiento del Producto en estado Alfa. El auditorio son el
Profesor, la Empresa tipo E y las demás Empresas Tipo N. La hora y duración máxima de
cada presentación se establecen con anterioridad dentro de una sesión de clase. La
Empresa tipo E hace la agenda, preside la reunión y adelanta la evaluación y calificación.

El contenido y dinámica de la presentación en público del Producto en estado Alfa, el(los)

presentador(res), la consecución de las ayudas audiovisuales, las herramientas que
utilicen y demás cosas que necesiten y quieran utilizar, son responsabilidad y de libre
albedrío de cada Empresa tipo N. Es importante tener un plan básico, por si todo resulta
como se planifica, y uno o varios planes alternativos, en caso de alguna contingencia.

Se sugiere que la presentación se haga con ayuda de una herramienta informática y un

retroproyector. Pero también se puede utilizar el tablero, el papelógrafo, marcadores,
diapositivas y carteleras. Todo lo anterior acompañando a la presentación en línea del
producto en estado Alfa.

La Presentación en público del Producto en estado Alfa; la comprobación de la existencia

del sitio Web actualizado; de la existencia y acceso del producto en estado Alfa; y de la
evaluación del contenido de todo el “Tercer Congelado”, la Empresa tipo E presenta al
Profesor un informe. El Profesor con base en ese informe coloca una calificación. La
calificación puede ser grupal o individual, esto último cuando se vean grandes diferencias
de trabajo por parte de los miembros del Equipo de cada una de las Empresas Tipo N. La

Gerencia de Proyectos de Software – Notas de clase Pág. 65

persona que no asista a la presentación en público del producto en estado Alfa, tiene cero
como calificación.

3.19 Hallazgos sobre el producto en estado Alfa

Las actividades siguientes a la presentación del producto en estado Alfa, deben estar
planificadas por cada una de las Empresas Tipo N, de acuerdo con los planes de gestión,
las líneas base y sobre todo con el Plan para la Dirección del Proyecto.

Los usuarios que van a probar el producto en estado Alfa deben tener en cuenta que el
producto en estado Alfa puede ser inseguro; puede presentar inestabilidades; puede
tener alguna funcionalidad o simplemente se puede “navegar” para tener una idea de
cómo es el producto según la maqueta elaborada; es posible que no presente todas las
características previstas en los requerimientos del producto; es posible que tenga errores.

Por lo anterior, es que las personas que van a probar el producto en estado Alfa, son
personas muy cercanas al proyecto, en general son únicamente personas que pertenecen
al equipo del proyecto.

Desde el punto de vista académico, cada estudiante tiene que reportar como mínimo diez
(10) hallazgos utilizando la herramienta de software definida para el reporte de hallazgos
en la Empresa tipo N a la que pertenece y sobre el producto en estado Alfa que su
Empresa presenta. Se esperan hallazgos reportando funcionalidades que no se deben
incluir, funcionalidades faltantes según los requerimientos, errores, inestabilidades, fallas
de seguridad, fallas de acceso, fallas de integridad, mejoras, sugerencias, cambios.

Todos los hallazgos reportados en cada Empresa tipo N por los probadores, tienen que ser
atendidos, siguiendo el proceso definido para Control de Cambios.

Los cambios aprobados tienen que verse reflejados cuando se tenga el producto en estado
Beta y en la versión liberada.

3.20 Software en estado Beta

En una Fábrica de Software generalmente después del producto haber pasado por el o los
estados Alfa, típicamente pasa a una fase que se denomina la fase Beta.

El producto en estado Beta generalmente es la primera versión completa del producto; es

una versión del software en donde se presentan mejoras con respecto del estado Alfa;
usualmente ya tiene todas las características pedidas en los requerimientos; es funcional;
sin embargo no está totalmente libre de fallas; puede tener ciertos errores; es posible que
presente algunas inestabilidades pero es una versión útil que la pueden usar los posibles
usuarios bajo la advertencia de que se trata de una versión Beta; puede ser útil para

Preparó: Ismael Castañeda Fuentes Pág. 66