Sistemas informáticos proyecto

1. ¿Te has percatado de la importancia que tienen los sistemas informáticos en tu
entorno?
Es sorprendente darnos cuenta de que estamos rodeados de aplicaciones
informáticas que nos facilitan la toma de decisiones en la vida diaria; sin
embargo, para que éstas pudieran llegar a nuestras manos, fueron definidas,
diseñadas y desarrolladas, tomando en cuenta las características y
necesidades de cada una. Este proceso requirió que un grupo de personas se
organizará y planificará un proyecto de TI, con el afán de que, al seguir varias
etapas, las ideas se concretarán en los sistemas que ahora utilizas.
Como puedes darte cuenta, lo anterior implica conocer un poco más acerca de
los sistemas informáticos, no sólo la programación sino también la planificación
y la utilidad que ésta tiene en las organizaciones. La decisión de que un
proyecto sea aceptado o rechazado recae en las áreas administrativas y la alta
dirección, además del área de TI, quienes se encargarán de evaluar la
viabilidad y determinar la aprobación de un proyecto, de acuerdo con los
objetivos estratégicos de la empresa.
Para conocer más sobre el motivo por el que fracasan los proyectos de TI, te
invitamos a leer el artículo ¿Por qué fracasan los proyectos de software?; un
enfoque organizacional, de Zavala Ruiz (2004) en el que podrás identificar la
importancia de un software, la utilidad de un proyecto del software, los factores
que determinan el fracaso y el éxito del proyecto, así como el enfoque
organizacional que lo caracteriza.
¿Por qué fracasan los proyectos de software?; un enfoque
organizacional.pdf
Después de leer el artículo, responde las preguntas en un archivo word para
que no se te olviden. Ya que tengas tus respuestas, entra al foro Reflexión de
lectura, compártelas con tus compañeros. Realizada la acción anterior,
comenta las respuestas de tus compañeros, con la finalidad de realimentar tus
conocimientos sobre la importancia de planificar de forma correcta un proyecto
de TI. Es importante que seas tolerante con la opinión de tus compañeros y
utiliza un lenguaje respetuoso dentro del foro.
Foro Reflexión de lectura
Con apoyo en la lectura ¿Por qué fracasan los proyectos de software?; un
enfoque organizacional, contesta las siguientes preguntas y realimenta la
participación de al menos 2 de tus compañeros. Es importante que tengas en
cuenta que debes ser muy respetuoso en la realimentación que realices,
además intenta ser lo más asertivo posible y no dejes ir ningún comentario que
consideres sea productivo.
 ¿Qué consideras que es un proyecto de software?
 ¿Cuál crees que es la función y uso de un proyecto de software?

2.  ¿Por qué son importantes los proyectos de software en una
organización?
 ¿Cuáles consideras que son los factores o fallas por los que fracasan los
proyectos de software?
 ¿Para ti cuáles son los factores por los que tiene éxito un proyecto?
 De acuerdo con tu opinión, ¿cuál es la diferencia (si la hay) entre un
software y una aplicación de TI?
Es importante tomar en cuenta que el foro académico te permitirá reforzar tus
conocimientos, al enriquecer los comentarios de por lo menos dos de tus
compañeros.
Es momento de comenzar a conocer los conceptos claves de la administración
de un proyecto de Tecnologías de la Información (TI).
¿Qué es un proyecto?
Existen diversas definiciones de proyecto, todas ellas válidas y fundamentadas
de acuerdo con la perspectiva y rama del conocimiento; sin embargo, se
presentan dos definiciones formales, por su grado de aceptación a escala
internacional, y una tercera que será la propuesta del presente bloque.
De acuerdo con la Guía de Fundamentos de la Dirección de Proyectos
(PMBOK Guide, por sus siglas en inglés) en su tercera edición: “Un proyecto es
un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o
resultado único” (Project Management Institute, 2004, p. 5).
Según la Organización Internacional de Normalización (ISO) en su Norma
Internacional 10006:2003, un proyecto “es un proceso único que consiste en un
conjunto de actividades coordinadas y controladas con fechas de inicio y
finalización, llevadas a cabo para lograr un objetivo conforme a requisitos y
requerimientos que incluyen limitaciones de tiempo, costo y recursos”.
Por lo tanto, para fines del MOOC se definirá de la siguiente manera:
Un proyecto es una serie de actividades ordenadas de forma lógica,
relacionadas entre sí, en un tiempo finito para alcanzar un objetivo
determinado.

3. De forma ideal, los proyectos tienen sus etapas perfectamente definidas e
identificadas, sin que sufran cambios en el ciclo de vida del proyecto. Esto no
ocurre en la práctica, debido a que existen imprevistos que van desde
modificaciones y atrasos hasta, en el peor de los casos, la cancelación del
mismo.
Aquellos proyectos basados en el desarrollo de una solución informática que
sirva de soporte a la toma de decisiones de una persona o grupo de gente son
denominados “Proyectos de Tecnologías de Información”, y están orientados a
resolver la necesidad de obtener datos estadísticos, reportes y automatizar
procesos. Estos proyectos deben cumplir ciertos requisitos para que no sean
clasificados solamente como Sistemas Informáticos. Por ello, de entre las
características principales destacan las siguientes:
 Tienen una relación típica con un grado de innovación.
 Contienen información de procesos y del entorno organizacional.
 Son realizados por equipos interdisciplinarios compuestos por más que
sólo desarrolladores (contadores, administradores, publicistas, entre
otros).
 Automatizan tareas operativas de acuerdo con la clasificación del tipo de
información.
 Se orientan a la alta dirección y sus beneficios deben ser visibles a corto
plazo.
 Son justificados debido a la necesidad de información estadística y gran
volumen de datos que requieren procesar, usar y mostrar.
 La relación costo-beneficio tiende a ser clara para justificar el precio de
su desarrollo e implementación.

4. Es importante destacar que en este tipo de proyectos, de acuerdo con los
Objetivos de Control para Información y Tecnologías Relacionadas (CoBIT, por
sus siglas en inglés), existe un grado de incertidumbre al trabajar con
tecnología, pues no puede ser controlada ni pueden hacerse demasiadas
previsiones para problemas que surjan durante su empleo. Además de lo
anterior, es necesario recalcar que la gestión de este tipo de proyectos se basa
de forma general en las etapas que marca el PMBOK; sin embargo, en la etapa
de ejecución es donde se evidencia la diferencia y donde tiene mayor peso
para ser aplicado en el entorno de las Tecnologías de la Información.
A continuación conocerás cada una de las etapas que contemplan la
administración de un proyecto de TI y su respectiva descripción. Si lo deseas,
puedes hacer una búsqueda en la Web para obtener más información acerca
de estas etapas.
Una vez que hayas analizado las etapas para la administración de un proyecto,
es importante que conozcas las etapas de gestión de un proyecto para
comenzar a visualizarlo, por lo que a continuación se mencionan las
características de cada una de ellas
Etapas para gestionar un proyecto
A continuación te presentaremos las tres etapas de gestión para un proyecto.
Etapa 0. Anteproyecto
Todo proyecto surge como una idea para satisfacer una necesidad, resolver
una problemática o por haber visualizado una oportunidad informática que no
ha sido satisfecha. A esta primera etapa se le denomina Anteproyecto o
Propuesta.
Los proyectos de Tecnologías de la Información (TI) formal deben contar con
una ficha de anteproyecto, la cual permitirá evaluar su viabilidad.
La vida de esta etapa tiende a ser muy corta, dura de dos a tres semanas.
Asignar más tiempo a esta parte del proceso convertiría al trabajo de definición
y de delimitación en una actividad de mayor complejidad, que resultará en un
desperdicio de esfuerzo.
Se considera una etapa donde las actividades llegan a ser informales porque
se entablan reuniones de trabajo, pláticas, se revisa material no especializado y
tendencias. Pero sobre todo se genera la lluvia de ideas donde se dan los
primeros pasos para conocer las características generales que tendrá el
proyecto.
Por un lado, las estimaciones del tiempo y costos se pueden realizar a partir de
un supuesto, apoyándose en la recomendación de un experto en el tema o
mediante la consulta de proyectos similares. Por otro lado, la conformación del
equipo de trabajo, recursos materiales, equipamiento y entorno de desarrollo se

5. realiza de forma superficial para ubicar e ir delimitando el proyecto, sin que se
lleve a cabo una evaluación profunda y detallada.
En esta primera etapa, el interesado en presentar un proyecto determinará el
objetivo, los resultados esperados, el alcance y beneficios del desarrollo, por lo
que la redacción debe ser clara y explícita.
De esta primer etapa se crea un documento denominado “ficha de
anteproyecto” o “protocolo” (en algunos casos específicos también es llamado
“ficha técnica”). En este documento se insertará la información recabada del
Proyecto de TI, el posible nombre o, si en su caso aplica, nombre clave y la
información que permite caracterizar al proyecto que se ha logrado definir.
Para reforzar lo aprendido hasta este momento te invitamos a realizar la
siguiente actividad donde tendrás que ordenar los elementos en la pirámide
acordes a las características vistas.

6. Dentro de los documentos a entregar debe de existir la sesión de derechos y la
debida constancia de la propiedad intelectual o derechos morales de quienes
participaron en la elaboración y diseño de la Solución Informática.
Una vez que se ha comprendido la definición de un proyecto de TI y cuáles
son sus características principales, debemos centrar nuestra atención en las
etapas que compondrán la administración del proyecto, que es la razón de ser
del MOOC.
A partir de este momento ya conoces las etapas que contemplan la
administración de un proyecto de TI, por lo que ahora, conocerás las etapas de
gestión para un proyecto donde partiremos de una idea para desarrollar una
Tecnología de Información, su planificación, así como la implementación y, los
planes de ejecución y control, así como la entrega y el cierre.
Posteriormente, se realizará la tarea de la definición y delimitación de un
Proyecto de TI, es decir que en el anteproyecto es necesario centrar los
esfuerzos en conceptualizar y describir, mediante un plan inicial, las etapas
para realizar el proyecto, donde se requiere verificar los alcances esperados,
tiempos y costos; además de la organización, tareas, actividades y
responsabilidades de los involucrados, para finalmente generar el equipo de
trabajo.
Etapa 1. Definición
Una práctica adecuada para poder definir un proyecto de TI consiste en realizar
una investigación básica para conocer aspectos que pudieran ser relevantes
para definirse y que no se hubieran considerado en la etapa anterior.

7. Ahora bien, para el bloque, y a modo de facilitar la definición del proyecto, se
recomienda responder once cuestionamientos que se presentan a
continuación, los cuales permitirán delimitar y enfocar el proyecto de TI.
Descarga la siguiente tabla.
Definición del proyecto de TI.pdf
Entre mayor sea el número de respuestas solucionadas en esta etapa, mejor
definido y enmarcado quedará el proyecto de TI; sin embargo, ésta no es una
labor fundamental de este proceso ni se deben forzar las respuestas. Conforme
se avance en la etapa de planeación se irán resolviendo las preguntas, incluso
podrían ocurrir algunas modificaciones mientras se avanza, lo cual también es
correcto.
Objetivo del proyecto
Se refiere a las actividades que deben realizarse para alcanzar el fin del
proyecto, es decir, es el trabajo que se requiere hacer para satisfacer una
necesidad o solucionar una problemática en el ámbito de las Tecnologías de la
Información (TI). El objetivo de un proyecto se puede clasificar en dos tipos: el
general y los específicos. Si el objetivo general cambiara, habría que analizar la
situación y determinar la conveniencia de centrar los esfuerzos en adecuar lo
ya realizado o finalizar el proyecto e iniciar uno nuevo con el objetivo redefinido.
Una vez planteado el objetivo, es momento de comenzar a describir el proyecto
que se va a realizar, a este momento se le denomina iniciación. Si se toma la
primicia de que un Proyecto de Tecnologías de la Información (TI) busca
solucionar una problemática o necesidad en su entorno, estas oportunidades
detectadas requieren ser evaluadas en un análisis inicial, donde se destaque
su grado de importancia, originalidad e influencia en los procesos de una
organización.
Esta primera etapa tiene como propósito describir el alcance que tendrá el
proyecto, sus metas generales y participantes (equipo de desarrollo e
involucrados). Además, se considera el bosquejo de la idea, de acuerdo con un
esquema organizado, estructuralmente cercano a un documento formal, en el
que se incluyen las funciones generales del sistema informático, conforme al
concepto de solución de TI. Éste deberá describir claramente la funcionalidad
del proyecto, su complejidad, características, tiempo dedicado y entorno de
desarrollo.
Etapa 2. Planeación
Una vez conceptualizado y definido el proyecto de TI, se requiere describir
detalladamente las tareas y sus actividades. Esta etapa es considerada como
el plan de trabajo para el proyecto, y se incluyen las principales líneas de
acción del desarrollo del sistema informático, analizando los requisitos de
hardware y software a partir de los objetivos fijados.

8. El líder del proyecto o responsable de presentar la propuesta se encarga de
seleccionar la metodología de planeación que mejor se adapte a las
características propias de la propuesta, para administrar de la mejor manera el
proyecto de TI.
Los principales requisitos de esta etapa son:
 Contar con una metodología de planeación
 Seleccionar el equipo de trabajo y roles de los integrantes
 Diseño de las líneas de acción de las tareas y actividades de trabajo
 Análisis y estudio de los requerimientos técnicos y tecnológicos para el
desarrollo
 Propuesta de solución
Si derivado de los trabajos de planeación se observa que el proyecto requiere
reestructurarse o replantearse, será necesario retomar el anteproyecto, para
reformular los puntos necesarios que permitan garantizar que se concluya de
forma correcta y nuevamente pase por la iniciación y la planificación.
A continuación se te presenta un ejemplo del ciclo de planeación de un
proyecto.
Como se había mencionado anteriormente, para realizar un proyecto no sólo basta
tener en mente los objetivos propuestos a desarrollar, también es necesario plantear
una metodología acorde al proyecto.

9. Una vez considerada la metodología, es importante tomar en cuenta hasta
donde se podrá llevar a cabo el proyecto y el tiempo adecuado para el mismo.
Alcance y tiempo
Para la administración de un proyecto de Tecnologías de Información es
fundamental dejar establecido hasta dónde abarcará un sistema informático, es
decir, qué procesos se automatizan o qué mejora se tendrá con el software
desarrollado; si es claro el alcance, el éxito se encuentra prácticamente
garantizado, debido a que la tareas y actividades se encontrarán alineadas.
De las tareas establecidas se obtienen los alcances parciales, que aumentarán
el porcentaje de avance del proyecto a este nivel de detalles. Es imprescindible
que el proyecto se encuentre bien definido y que los desarrolladores de la
aplicación tengan conocimiento suficiente sobre lo que se quiere y lo que se
espera obtener cuando el desarrollo haya concluido y se realicen las pruebas
piloto.
Es razonable que los integrantes del equipo de desarrollo tengan expectativas
diferentes, unos de otros. Esto se debe al rol y las funciones que se hayan
diseñado para cada persona del equipo, por ello es importante dar a conocer
con claridad el proyecto. Una buena práctica hacia el interior del proyecto es
documentar las dudas e inquietudes, para que se puedan integrar como un
entregable en la etapa de cierre e integración de la documentación.
Si bien, en la planeación, el alcance busca que el proyecto de TI quede
debidamente delimitado y enfocado por quienes lo diseñaron, es
responsabilidad del equipo de desarrollo comunicar cuando alguna de las
metas operativas no pueda alcanzarse, justificando la razón por la cual no se
podrá llevar a cabo dicha tarea, para que se tomen las medidas pertinentes
para modificar el proyecto y determinar el grado de impacto general para el
mismo proyecto.
Por ello, en el alcance, los elementos que se incluyen en un proyecto son tan
importantes como los que quedan fuera y es sólo mediante el consenso de los
interesados en el sistema informático y de los participantes (equipo de trabajo)
que se establece el límite real del proyecto de TI.
En el caso del curso, al haber seleccionado la metodología del Diagrama de
Gantt, las tareas se encuentran en secuencia, lo que implica la participación de
una o más personas, de acuerdo con la complejidad y características de la
actividad; sin embargo, existe una interactividad entre ellas para lograr un
alcance o porcentaje de avance.
La declaración del alcance del proyecto se constituye para generar el ciclo de
vida del proyecto, y a ésta se le controla y monitorea a lo largo del proyecto
hasta su fin o conclusión. El documento que hace referencia al alcance del
proyecto puede quedar estructurado de manera formal y general o formal y
detallada, ello dependerá del caso particular del que se trate.

10. El tiempo
Todo proyecto formal de TI requiere contar con un cronograma para medir el
grado de avance de las actividades, las cuales requieren estar ordenadas de
forma coherente y secuencial donde se indique la duración y los recursos que
se van a emplear en cada una de las etapas, el grado de detalle del
cronograma es variable dependiendo de la complejidad del proyecto mismo.
Para crear el cronograma del proyecto se deben tomar en cuenta las fechas de
inicio y conclusión, en ese intervalo se debe administrar el tiempo que duren las
actividades con los hitos que correspondan y las holguras programadas. Al
elaborar el cronograma, es posible que se requiera modificar el plazo y los
tiempos de entrega, ésta es una de las utilidades y ventajas de la
administración de un proyecto.
La elaboración del cronograma es una etapa fundamental para visualizar el
tiempo que durará un proyecto. La calendarización de las tareas y sus
actividades se encuentra relacionada mayormente con la metodología de la
Ruta Crítica, debido a las características que se han descrito de ella con
anterioridad.
Con el cronograma se logra:
 Definir las tareas y actividades
 Secuencia y orden
 Estimación y cálculo de todos los recursos
 Duración general y específica del proyecto y sus etapas
Por ejemplo:

11. Ya que hayas visualizado el alcance y el tiempo del proyecto, debes de realizar
el estudio financiero del proyecto.
Administración financiera del proyecto
Al igual que todo proyecto formal, los relacionados con las TI deben contar con
un estudio financiero, que les permitirá a los interesados (inversionistas o
clientes) evaluar los costos de desarrollo de un Sistema Informático. A quienes
tomen la decisión de aprobar el proyecto, les resultará fundamental contar con
el análisis financiero. Al elaborarse un correcto estudio donde los costos se
encuentren especificados y distribuidos de forma ordenada y coherente, se
puede lograr la aprobación de la propuesta de solución; sin embargo, este
mismo punto puede ser la razón principal por la que un buen proyecto de TI
llegue a ser rechazado.
El presupuesto que se asigne a la solución informática debe quedar integrado
por la estimación de gastos en la vida del proyecto, así como el flujo de capital
y el control de los costos. Para los proyectos donde el alcance es demasiado
corto, el presupuesto asignado y el estimado de costos son considerados una
misma etapa para facilitar la elaboración de estudio. En el caso de proyectos
de TI, por lo regular su dimensión es amplia, por lo que se debe realizar por
separado cada punto del estudio.

12. En ambos casos, el capital humano y el periodo de tiempo son directamente
proporcionales, es decir, un proyecto de alcance corto requiere una persona o
dos para realizar el estudio financiero en un periodo de tiempo corto, mientras
que el un proyecto amplio se requiere del apoyo de un equipo de trabajo con un
tiempo adecuado para elaborar el estudio.
Al determinar los costos es importante tomar en cuenta la ubicación geográfica
del proyecto y el tipo de moneda local. Una práctica común en proyectos
formales es poner los valores totales en la moneda local y en dólares
estadounidenses.
En resumidas cuentas, la elaboración de un plan de costos permite, desde la
perspectiva financiera, definir los criterios de planificación a partir del
presupuesto asignado y distribución de los recursos.
Cabe señalar que en un proyecto de TI difícilmente se puede hablar de un
retorno de la inversión directa, debido a que el sistema informático por sí
mismo es un activo intangible para la organización, por lo tanto se debe
comprender que una solución informática es, por lo regular, un medio para
alcanzar un objetivo estratégico dentro de una organización. Por lo que es
responsabilidad de quien elabora la propuesta general dejar especificado que
los costos de inversión en un sistema informático se verán reflejados en el
proceso central, los administrativos o de soporte en una empresa u
organización, donde se obtendrán beneficios en términos de mejorar en la
reducción de tiempo, personal, errores, flujo de información, automatización de
procesos, por citar algunos ejemplos.
El siguiente diagrama muestra los principales componentes y sus elementos de
la gestión de los costos de un proyecto, de acuerdo con el PMBOK. Es
importante destacar que, si bien es una descripción detallada, se requiere
adaptar a las características propias de cada proyecto, que para el caso del
MOOC es en TI, ya que no es necesario que se cubran todos los puntos.

13. Para una mayor comprensión sobre los elementos que debe cubrir un análisis
financiero, se describen tres técnicas para la administración financiera, el
presupuesto y los costos para un proyecto de TI.

15. Presupuesto
Consiste en asignar el monto presupuestado a cada tarea y grupo de
actividades; sin embargo, el presupuesto estimado no siempre es el asignado,
ello dependerá de la habilidad de negociación del líder del proyecto para
conseguir una mayor cantidad de recursos o, en caso de que sean limitados,
de su habilidad para realizar las adecuaciones correspondientes para alcanzar
el objetivo.
La elaboración del presupuesto debe considerar los siguientes elementos:
 Estimado de costos por tareas
 Cronograma del proyecto
 Asignación de recursos
 Contratos y cláusulas de pago
 Presupuesto para equipamiento y herramientas de desarrollo
 Presupuesto reservado
 Límite del presupuesto asignado
Es importante también, considerar los costos o recursos económicos para
desarrollar el proyecto.
Costos
Son los recursos económicos que permitirán desarrollar el proyecto. Para su
estimación se requiere hacer uso de predicciones sobre los montos que se
deben asignar a las etapas o a la correcta distribución de un monto

16. especificado como primicia para crear la solución de TI. Los costos se
encuentran dados a partir de lograr el equilibrio entre la salida y entrada de
capital, aunado a los riesgos por asignar recursos financieros en un momento
dado para solventar una necesidad dentro del proyecto para su avance.
Si bien los costos óptimos se redefinen a lo largo del proyecto, la estimación de
los mismos se precisa en el ciclo de vida para garantizar que a todas las etapas
del proyecto se le asignen recursos económicos suficientes para lograr su
conclusión. Los dos tipos de costos que todo proyecto debe tener son los
directos que se encuentran relacionados con las actividades para desarrollar el
proyecto y los indirectos correspondientes al entorno de gestión que
complementan a la planificación.
Ya en este punto, como material adicional para esta meta del MOOC, se te
proporcionan los siguientes documentos:
 Formato de Ficha de Anteproyecto
A continuación te presentaremos un ejemplo de una ficha de anteproyecto, te
recomendamos descargar y revisar para que te sea más clara la información.
Ficha de Anteproyecto.doc
 Formato general para planificar un proyecto
Una vez revisadas etapas y la metodología, se te presenta un formato
propuesto sobre la planeación de un proyecto, descargar el siguiente archivo
denominado Planificación del proyecto para que tengas una noción sobre el
tipo de archivos que puedes ocupar para planear un proyecto de TI.
Formato planificación del proyecto.doc
 Cédula de Proyecto
Te recomendamos descargar el siguiente archivo Cédula del proyecto para que
lo uses al desarrollar tu proyecto de TI.
Cédula del proyecto.doc
De igual manera, se te proporcionará un ejemplo sobre Ejercicio de Análisis
financiero para un proyecto de Tecnologías de la Información, por lo que te
recomendamos descargar tambien este archivo.
Ejercicio de Análisis financiero para un proyecto de Tecnologías de la
Información.doc

17. Puedes usar y requisitar estos formatos para que compruebes tus
conocimientos, además te sirvan de apoyo para presentar un proyecto de TI.
Bloque 2: Desarrollo del proyecto > Meta 2: Implementación de un proyecto de TI,
tomando en cuenta factores de planeación de desarrollo de software y administración de
riesgos > P2
Una vez analizada la información del bloque anterior, en donde se define un
proyecto, es momento de generar el expediente del proyecto, el cual
integrará los formatos propuestos y desarrollados con la información relevante
para continuar con el desarrollo del proyecto de TI. Esta buena práctica se
realiza con la finalidad de reunir en un solo lugar todos los documentos y sean
accesibles para su consulta y referencia en el futuro.
En el presente bloque nos enfocaremos en el desarrollo del proyecto. Una de
las cuestiones importantes a señalar antes de comenzar es que el equipo debe
unir esfuerzos para que el proyecto llegue a buen término. Para alcanzar el
éxito, bajo ninguna circunstancia se debe permitir que una meta personal
supere el objetivo colectivo o que tenga mayor peso que éste.
Cabe aclarar que una planeación, sin importar qué tan bien estructurada esté,
es un planteamiento teórico; siempre habrá factores y variables que
modificarán el plan original del proyecto. Por ello, es recomendable contar con
las etapas de control y de riesgos, mismas que permitan monitorear y
minimizar los cambios y problemas durante la elaboración de una solución
informática del tipo de Tecnologías de la Información. No obstante, también es
importante seleccionar una metodología de desarrollo de software para
administrar las etapas de la creación de una solución informática.
En este bloque se te presentarán diversas técnicas que te apoyarán en la
construcción de una Tecnología de la Información desde la perspectiva del
desarrollo del software. Para lo anterior se ha seleccionado “El método rápido
de Scrum”, con la finalidad de representar la etapa de desarrollo e
implementación de un proyecto de TI. Posteriormente se abordarán las etapas
de control y de riesgos de un proyecto, que por sus características propias
guardan una relación inherente en las actividades para minimizar los posibles
efectos adversos que puedan ocurrir y que pongan en riesgo la planeación y la
vida del proyecto mismo.
Aunado a lo anterior, nunca se debe olvidar que un proyecto,
independientemente de su naturaleza, se encuentra encapsulado en un

18. momento de la realidad en la vida de las personas. Para la administración
estratégica, estas mismas personas son el activo más importante en
las empresas u organizaciones, porque son ellas quienes dan vida a su
entorno de trabajo y generan los cambios en él.
Se ha seleccionado el marco de trabajo propuesto por John Zachman por ser
considerado en la industria del desarrollo de software como una técnica para
crear un sistema informático dentro de una organización.
La matriz de Zachman
Esta herramienta es un marco de trabajo (Framework), cuya utilidad inicial se
orienta al desarrollo de Sistemas Informáticos. Fue propuesta por John A.
Zachman en su artículo titulado "A framework for information systems
architecture", en el cual menciona: “Para guardar el negocio de la
desintegración, el concepto de una arquitectura de los sistemas de
información se está convirtiendo en menos de una opción y más de una
necesidad”. Este marco emplea modelos y vistas desde las perspectivas de
los participantes, lo que permite crear, para el caso del MOOC, las
características técnicas y de información de una herramienta de Tecnologías
de la Información.
La principal característica de la matriz de Zachman radica en presentar un
nuevo modelo de comunicación y flujo de información, con base en distintas
perspectivas, de entre las cuales se destacan las siguientes:
 Analista de sistemas, para presentar la lógica de negocio
 Diseñador, para crear la estructura del sistema
 Desarrolladores de sistemas, para aplicar tecnologías de desarrollo de
aplicaciones
 El sistema en sí mismo, es decir, el ciclo de vida del software
De acuerdo con su autor (John a. Zachman), la matriz establece
horizontalmente las siguientes cuestiones:

19. En forma vertical, se establecen los modelos que se encuentran orientados de
acuerdo con el perfil de los participantes:
Una vez analizadas las tablas anteriores, a continuación se te mostrará una
tabla donde se integran las cuestiones (primera fila) y modelos (primera
columna) que mencionamos, los cuales se interrelacionan entre sí de acuerdo
con el proceso de elaboración de la solución informática.

20. A partir de revisar la matriz de Zachman, puedes observar que tiene distintas
perspectivas que son de gran interés para el MOOC de AP de TI. Éstas se
presentan a continuación:
El diseñador: el perfil se relaciona con la especificación de los planos
conceptuales de sistemas informáticos y de la información, que permiten
soportar la operación de los procesos organizacionales.
El constructor: este perfil se encarga de unir y elaborar los diversos
componentes del sistema informático, de acuerdo con las restricciones para
desarrollar la Tecnología de la Información.
El programador: es el perfil encargado de programar los componentes en la
plataforma de desarrollo seleccionando, de acuerdo con las especificaciones
del constructor.
Ciclo de vida del software (CVS)
Cuando se habla de desarrollar un programa, sistemas informáticos o
Tecnología de la Información, es importante hablar del proceso del software, en
el que nace como una idea, se desarrolla como una aplicación y se libera
(termina). Este proceso se conoce como el Ciclo de vida del software y es
una característica en común que comparten las soluciones informáticas.
De acuerdo con la Organización Internacional de Normalización (ISO, por sus
siglas en inglés), en su norma 12207-2008, al ciclo de vida del software se le
define de la siguiente manera:
[Es] Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en
el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta que finaliza su uso o deja de ser útil.
Como se puede ver, el desarrollo de una solución informática se encuentra
relacionado con recursos, tiempo, requerimientos técnicos y no técnicos,
actividades y productos intermedios (módulos o avances sustanciales)
necesarios para desarrollar una herramienta informática.
Por ello, la administración de un proyecto de TI requiere una planeación que
abarque más que las etapas del ciclo de vida del sistema informático
(software), es decir, que además tome en cuenta los objetivos, alcance,
actividades, tareas, seguimiento, capital humano, recursos financieros, plan de
riesgos y entrega de la solución al cliente.

21. Es necesario
puntualizar que el objetivo de este ciclo es validar las actividades de una forma
coherente y ordenada, para garantizar que el sistema informático cumpla con
los criterios y requisitos funcionales solicitados. A continuación se ilustran los
procesos del ciclo de vida del software.

22. El proceso del CVS define tres tipos de procesos básicos para el desarrollo de
software. Cada uno de ellos contiene distintas etapas, lo que facilita segmentar
el trabajo, definir y administrar el progreso en la construcción de la aplicación
informática.
El proceso de desarrollo
De las distintas etapas del ciclo de vida del software, destaca el proceso de
desarrollo, que es la descripción secuencial de actividades ordenadas
coherentemente para crear el programa informático. Este proceso contempla
seis actividades que guardan gran relación con la administración general del
proyecto, por lo que es recomendable hacer uso de la información con que se
cuenta, para hacer más rápida la integración del proceso de desarrollo de la
aplicación, con base en los requerimientos técnicos que se han solicitado.
Es en esta parte donde se aprovecha el conocimiento previo obtenido de la
definición y alcance del proyecto, con el objetivo de generar las actividades
internas que permitirán seleccionar el modelo de CVS que se adapte mejor al
tipo de proyecto planteado, para desarrollar el diseño de la aplicación,
seleccionar el entorno de programación, requisitos y limitaciones tecnológicas,
para que una vez que se tenga construida la solución informática se pueda
iniciar con las pruebas y, finalmente, se entregue la solución informática.
La siguiente ilustración muestra de forma gráfica el proceso de desarrollo del
software.

23. A continuación conocerás los modelos del ciclo de vida de un software, los
cuales te servirán como guía para el desarrollo de una aplicación informática.
Modelos del Ciclo de vida del software
Los modelos de CVS se presentan como una pauta para guiar el desarrollo de
aplicaciones informáticas, por lo que sirven de referencia para organizar las
etapas, actividades, tareas y requerimientos. Estos marcos de gestión del
desarrollo permiten controlar y coordinar las actividades de acuerdo con el tipo
de proyecto.
Por lo anterior, no existe un modelo único que se adapte a todas las
necesidades y características de un sistema a ser desarrollado, por lo que
dependerá del tipo de proyecto y la forma en que se busque coordinarlo para
seleccionar uno o varios modelos.
Ahora se presentan algunos modelos que son muy conocidos y han sido
usados en la industria del desarrollo de software.

27. A continuación descarga el siguiente archivo, en el cual se te mostrará una
tabla comparativa de los modelos ya revisados y analizados.
Tabla comparativa de modelos.pdf
La selección de una metodología de desarrollo es una tendencia y una buena
práctica en la industria del software, pero no es solamente exclusiva de las
empresas, pues los desarrolladores y administradores de proyectos de
Tecnologías de la Información también se benefician de su uso y adopción.
Para este MOOC se ha seleccionado el método Scrum para describir el
proceso de creación de una solución informática por la siguientes razones:
permite desarrollar aplicaciones en poco tiempo e incluye al cliente, pueden

28. realizarse cambios mientras se motiva al equipo de desarrollo, se considera de
fácil comprensión y se centra en la productividad en plazos cortos y la mejora
continua.
Método Scrum
Este método tiene su origen en Japón. En 1986, Hirotaka Takeuchi e Ikujiro
Nonaka publicaron el trabajo de investigación “El nuevo juego de desarrollo
para productos nuevos”, en el que se menciona por primera vez este término. A
este método también se le conoce como Manufactura sin Desperdicios y su
concepto se centra en agilizar la manufactura de un producto.
Sin embargo, fueron los norteamericanos Ken Schwaber y Jeff Sutherland
quienes de forma separada usaron el término Scrum (melé) para referirse al
concepto de manufactura rápida, que viene del juego inglés de Rugby y se
refiere a una jugada donde los participantes de cada equipo se agrupan en una
posición (Scrum) para luchar por la obtención del balón que se pondrá en el
centro. En 1995, trabajando de forma conjunta, crean este método (Framework)
que permite simplificar las etapas de desarrollo del software minimizando los
costos y tiempos de entrega.
Una vez explicado lo anterior, podemos decir que el principio de Scrum se
enfoca en que los proyectos informáticos tienen requerimientos y riesgos
inciertos. Por esta razón se elimina la documentación innecesaria, para
centrarse en la productividad con base en etapas cortas y bien definidas que
incluyen al cliente. Con ello se busca minimizar los problemas que conlleva la
gestión de un proyecto de desarrollo que requiere una pronta implementación y
entrega.
Cabe resaltar que el trabajo colaborativo es importante en Scrum para la
solución de problemas de desarrollo y programación y la atención de cambios
o errores en la aplicación. También la motivación del equipo es fundamental
para mantener su alto desempeño en el proyecto, por lo que se realizan
diariamente juntas rápidas, donde se da seguimiento continuo a los avances
programados. Por otro lado, la inclusión del cliente en el proyecto, desde un
inicio, permite que éste conozca su avance real, mientras que el equipo puede
conocer su punto de vista en cada etapa del desarrollo y efectuar con rapidez
los cambios que se presenten, además de enterarse directamente si el cliente
aprueba el trabajo realizado. Esta unidad y capacidad de comunicación
mantienen el trabajo alineado con el objetivo del proyecto y su alcance.
Por otra parte, en el método Scrum, se llama iteraciones a los pequeños
bloques que arrojan un resultado significativo en un tiempo corto y
debidamente acotado, donde hay pruebas y realimentación de las funciones
por parte del equipo de pruebas y el cliente. La suma de cada una de estas
iteraciones da como resultado el producto terminado, listo para ser entregado
en el tiempo pactado o mucho antes de ser posible, con lo que se reducen los
costos para el cliente. Éste concepto de mínimo esfuerzo es uno de los
diferenciadores de Scrum. El plan de desarrollo parte de una lista de
requerimientos y objetivos priorizados del sistema informático que es dictado

29. por el cliente, estos quedan descritos como iteraciones y avances
programados.
También los costos son un aspecto importante en este método, así que al tener
al cliente como una parte activa del proyecto, se logra optimizar los recursos
financieros en aquellas iteraciones que requieran una atención urgente.
A continuación se muestra el diagrama con el método Scrum.
Una vez revisado y analizado el diagrama, conocerás las seis actividades del Scrum
que a continuación se te presentan:

34. Después de revisar la información anterior, con la siguiente animación,
conocerás los cuatro actores o participantes dentro del método Scrum.
Una buena planificación de un proyecto requiere incluir las etapas de control y
gestión de riesgos para monitorear y minimizar los cambios y las amenazas
que puedan surgir en el ciclo de vida de un proyecto.
Etapa de control y seguimiento
Todo proyecto requiere contar con una etapa que permita verificar su grado de
avance y desarrollo. A diferencia de otras fases de la administración de un
proyecto que tienen un inicio y un fin claro, el control se relaciona con varios
procesos del ciclo de vida, ya que vigila, revisa y da el seguimiento con
respecto a la planificación que se ha elaborado.
De la diferencia que exista entre la planeación y el desarrollo real de las
actividades se pueden generar acciones preventivas y correctivas que permitan
efectuar los cambios necesarios que garanticen el correcto progreso del
proyecto.

35. La principal meta que persigue la etapa de control en un proyecto es lograr que
el objetivo del mismo sea alcanzado al realizar, en caso de que sea necesario,
los ajustes a la planificación de las actividades del proyecto. Como resultado de
los ajustes efectuados, el cronograma sufrirá actualizaciones, por lo cual debe
ajustarse la calendarización de las actividades y el tiempo. Dependiendo del
grado de alteración en los tiempos en el calendario, se puede hacer uso de las
holguras para tratar de minimizar los efectos adversos de estos cambios o, en
casos más drásticos, afrontar que el plazo de entrega no se podrá llevar a cabo
en los tiempos pactados, para lo cual es necesario registrar y documentar los
motivos por los que se ha llegado a tener un desfase en el proyecto.
Para prevenir o detectar desviaciones en la gestión del proyecto, el equipo que
lo integra puede hacer uso de las lecciones aprendidas, en caso de que tenga
un conocimiento previo, o al haber desarrollado otra solución informática, con el
objetivo de prevenir el impacto que tendrán estas alteraciones.
A continuación conocerás cómo, de qué manera y para qué es importante
tomar en cuenta las acciones correctivas y preventivas.

37. Ahora bien, los indicadores y sus métricas también deben ser catalogados de
acuerdo con la naturaleza de lo que se quiera medir; entre mejor se puedan
agrupar y clasificar será mucho más fácil poder trabajar tanto en su elaboración
como en su uso.
A continuación se muestran un par de ejemplos de indicadores y métricas de
desempeño.
Nota: las siglas “RFR” y “RFA” significan “Recurso financiero real” y “Recurso
financiero asignado”, respectivamente; el símbolo ≡ significa “exactamente
igual a”. Elaborado por MDTI Ricardo Ángel Aguilar Pérez, para el MOOC de
AP de TI.
Nota: las siglas “TD” significan “tiempo de desarrollo”; (m) es “medida de
tiempo” (horas, días, semanas, meses); el símbolo ∑ significa “sumatoria”; (t)
es periodo de tiempo; (mp) es “medida de tiempo propuesto” (horas, días,
semanas, meses). Elaborado por MDTI Ricardo Ángel Aguilar Pérez, para el
MOOC de AP de TI.

38. El control de cambios
Ahora bien, el control de cambios se realiza mediante un análisis de las
desviaciones que sufre el proyecto, llevado a cabo por equipo del proyecto, que
afectan de forma directa o indirecta el desarrollo de la solución informática.
Como se ha visto, es durante el ciclo de vida del proyecto cuando se presentan
situaciones que dificultan alcanzar el objetivo del proyecto.
Por lo anterior, el control de los cambios es una actividad rigurosa, definida y
crítica que debe realizarse desde la planeación del proyecto, ya que de esta
forma se podrá llevar un registro de las acciones preventivas o correctivas que
se tengan que hacer, pero sobre todo, deben ser justificadas y aprobadas
tanto por el equipo del proyecto como por el cliente.
Entre los factores que llegan a afectar a un proyecto se encuentran los
siguientes: cambios en la organización interna del proyecto o por parte del
cliente, surgimiento de nuevas áreas y oportunidades tecnológicas, falta de
solvencia económica por parte del cliente, nuevas necesidades no previstas y
que afectan el desarrollo de la solución, cambios en el entorno del proyecto
(sociales y de medio ambiente), normativas gubernamentales, políticas
públicas, por citar algunos ejemplos. En el peor de los escenarios, todos estos
factores podrían llegar a presentarse durante el desarrollo del proyecto, sin
embargo, si son debidamente resueltos y se cuenta con un equipo sólido, se
podrán superar para llevar a buen fin la solución informática.
Como se ha visto, el control de los cambios es una actividad que termina
siendo interna para el equipo del proyecto; es decir, las peticiones de cambios
tienen origen del lado del cliente y, cuando estas son aprobadas, es la parte de
desarrollo la encargada de efectuarlas. Para que un cambio sea aprobado, es
necesario realizar una evaluación sobre el motivo y la justificación del cambio
de acuerdo con el plan original.
Se pueden identificar dos tipos de peticiones dentro del control de cambios de
un proyecto de TI:
 Errores en la programación: cuando se identifica un fallo o defecto.
 Requerimiento de actualización: cuando se requiere modernizar un
componente de la solución informática.
Las peticiones generan dos tipos de respuestas por parte del equipo de
desarrollo:
 Documento de aprobación: los cambios deben verse reflejados en el
sistema informático.
 Documento de rechazo: se justifica el motivo por el cual no se
considera necesario emprender la acción correctiva o solicitada.

39. Gestión de riesgos
Al igual que en la etapa de control, en la gestión de riesgos se debe elaborar un
plan de respuesta a partir de la identificación y el análisis de los posibles
sucesos que supongan un peligro para el correcto funcionamiento de las
etapas de un proyecto. Es por ello que se requiere monitorear y dar
seguimiento a las distintas fases que conlleva realizar una herramienta de
Tecnologías de Información. Con lo anterior se busca minimizar los riesgos y el
impacto que estos podrían tener en caso de que ocurrieran. Se considera que
un riesgo es todo suceso o evento con un grado de incertidumbre que puede
ocurrir en el futuro y que pone en peligro al menos un segmento importante de
un proyecto.
Todos los proyectos tienen algo en común desde su etapa de definición, tienen
un grado de incertidumbre que permanecerá latente durante la vida de los
mismos. La probabilidad de que ocurran eventos que pongan en peligro un
proyecto es tal que se requiere de un plan de contingencia, el cual permita
identificar posibles problemas, su grado de impacto, el potencial de sus efectos
y consecuencias.
Por lo anterior, es recomendable que un miembro del equipo con experiencia
en proyectos sea la persona designada para realizar el análisis de los posibles
riesgos y diseñar un plan de contingencia contra ellos.
Existen dos tendencias claras que pueden asumir los miembros del equipo de
un proyecto:
 Del tipo reactivo: no se realiza ninguna planeación y se espera hasta
que suceda un problema para solucionarlo; sin embargo, la desventaja
de esta tendencia radica en que si una problemática es muy grande, se
pone en peligro que el proyecto continúe.
 Del tipo proactivo: en esta tendencia se realiza proceso de análisis e
identificación de problemas potenciales, en el que se evalúa la
probabilidad de que ocurran y el impacto que podrían tener. A partir de
ello se diseña un plan de contención. Su desventaja radica en que la
búsqueda de dificultades potenciales y la elaboración de un plan de
contingencia consumen tiempo.
Ahora bien, los cuatro tipos de riesgos más comunes para un sistema
informático son los siguientes:
 Riesgos organizacionales del proyecto
 Riesgos del tipo técnico o tecnológico
 Riesgos relacionados con las herramientas de diseño
 Riesgos del tipo financiero

40. La identificación de riesgos es una actividad sistemática que se relaciona con
las amenazas que giran en torno a la planeación del proyecto, pero que
incluyen factores externos que no pueden ser controlados pese a que se hagan
esfuerzos, hacia el interior de la administración del proyecto, para minimizarlos.
Asimismo, es necesario evaluar tres aspectos para conocer el impacto de un
riesgo: la naturaleza del problema, el ambiente por el cual se originó y el grado
de afectación que tendrá el calendario (el tiempo).
Para lograr que las probabilidades de éxito de un proyecto se logren, no sólo
basta con tener buena voluntad para llevarlo a cabo, se requiere de una
constante vigilancia sobre las actividades y tareas que se han planificado, ya
que teóricamente se pueden mostrar secuenciales o paralelas, pero en realidad
se traslapan, retrasan o adelantan, sobre todo en aquellos proyectos de gran
complejidad y que por su duración, como se ha mencionado, se recomienda
fragmentar, para ser divididos en módulos, haciendo de la tarea de monitoreo
una acción más compleja.

42. El plan de los riesgos en el proyecto
El plan de riesgos es un proceso en el que se elabora un documento donde se
definen las acciones que se deben tomar en caso de que un riesgo aparezca
en el horizonte del proyecto. Su función es determinar las acciones que debe
realizar el equipo del proyecto frente a una situación y cómo debe ser
solucionada, éstas deben quedar enmarcadas en un intervalo de tiempo muy
pequeño y ser muy concretas, de lo contrario afectarán el correcto desempeño
general de las actividades del proyecto. Este plan debe iniciarse siempre al
terminar el análisis; en algunos casos, sobre todo aquellos en que el proyecto
sea de gran prioridad y tenga gran rispidez, puede hacerse en paralelo con la
identificación de los riesgos, para iniciar su mitigación en cuanto sea posible.
Como se ha mencionado, el plan de riesgos debe contener acciones claras
sobre cómo actuar ante una amenaza y cómo solucionarla. Al respecto, el
equipo del proyecto espera que la acción de respuesta sea acorde a la
magnitud del problema, al tipo de proyecto y su objetivo.
En definitiva, la persona o el equipo asignado para esta etapa debe estar
consciente de que su responsabilidad radica en la correcta evaluación y
formulación de las respuestas ante los riesgos que se puedan presentar en el
proyecto; de otra forma, los costos serían mayores, lo cual provocaría un

43. peligro interno, quizá mucho mayor que los que puedan encontrarse en el
entorno de la herramienta de TI.
Desarrollo del proyecto
Una vez que se ha desarrollado la solución informática con base en la
metodología seleccionada para desarrollar un software, es necesario iniciar con
el cierre del proyecto. Si bien esta etapa se considera administrativa y
complementaria a los trabajos de planeación, permite que los participantes del
proyecto tengan plasmada la información fundamental sobre el proyecto y su
gestión.
El presente bloque tiene como objetivo describir las características de la etapa
de cierre de un proyecto, así como presentar los tipos de documentación que
deberán acompañar al sistema informático cuando sea presentado y entregado
a los usuarios finales de las empresas u organizaciones.
A continuación conocerás las características de la etapa de cierre de un
proyecto de TI.
Etapa del Cierre
Esta etapa consiste en llevar a cabo las actividades de gestión concernientes a
la conclusión formal del proyecto. Se pueden identificar dos tipos de cierre: el
interno, que está relacionado con la conclusión de las actividades por parte del
equipo de desarrollo; y el externo, relacionado con el cliente y la empresa u
organización para la cual se elaboró el sistema informático.
El cierre toma en cuenta la planificación del proyecto y las etapas anteriores a
ésta, es decir, las etapas del PMBOK y la planificación del proyecto, validando
que se hayan concluido con los trabajos y las actividades calendarizadas en el
cronograma. Además, permite verificar si los objetivos del proyecto han sido
logrados y si se han cubierto las necesidades y los requerimientos para el
desarrollo de una solución informática.
La documentación de la etapa del cierre se encuentra orientada hacia las
acciones que garanticen el término o conclusión del proyecto para que, en caso
de que el sistema sea aprobado, se libere y se transfiera al cliente en las
cláusulas y tiempos que se hayan acordado.
Es en esta etapa donde se elabora y genera el mayor número de entregables
(documentos significativos) producidos en el ciclo de vida del proyecto. Estos
documentos se deben integrar en el archivo interno del proyecto, mediante una
carpeta que constituye el expediente de la herramienta de TI. También se
deben incluir los escritos pertenecientes a la propia etapa de cierre y entrega,
lo cual se abordará más adelante.

45. Con lo anterior, te habrás percatado que un proyecto cancelado no tiene por qué
quedar en el olvido, simplemente puede quedar guardado en el archivo para futuros
trabajos.
Cancelación de un proyecto
Un proyecto es cancelado cuando no llega a buen término y éste ha sido
cerrado por razones ajenas a la planeación inicial y aún con un plan de riesgos
elaborado. Las situaciones que dan origen a un cierre inesperado pueden ser
tanto internas como externas y no son planificadas. Sin embargo, los
responsables del proyecto tienen el compromiso de documentar en un formato
especial los hechos y causas que desembocan en la decisión de finiquitar los
trabajos.
Es importante recordar que la redacción del documento es libre y queda a
consideración de quien lo elabora, sin embargo se recomienda que se incluyan
los siguientes puntos para justificar los motivos del cierre prematuro de
proyecto:
 Describir la situación que generó la cancelación definitiva del proyecto.
 Resaltar los hechos que originaron la situación.
 Estado de avance del proyecto y su grado de avance en porcentaje.
 Listado de las actividades y tareas realizadas hasta la fecha de la
cancelación.
 En caso de ser una decisión interna, presentar la justificación y los
motivos.
 Las consideraciones para retomar el proyecto en trabajos futuros.
 Fondos del presupuesto aún por asignar, gastos del presupuesto y
costos del proyecto.
Aprobación y aceptación del proyecto

46. La aprobación y aceptación del proyecto es un documento emitido por el cliente
(propietario final) del sistema informático, en el que se señala la aceptación de
la solución de TI, reconociendo con ello que se ha cumplido con el objetivo y
que se puede dar por concluido satisfactoriamente el proyecto.
Las lecciones aprendidas constituyen un documento interno que, si bien no es
un requisito administrativo para el cierre, es de gran importancia hacia el
interior del equipo, ya que es aquí donde se pueden intercambiar opiniones,
experiencia ganada, resolución de conflictos e imprevistos y, sobre todo,
generar conocimiento colectivo para el equipo, que puede ser empleado en
proyectos futuros. Estos acontecimientos por lo general no son documentados,
para ello se aprovecha este punto.
Cuando el producto se ha implementado se recomienda realizar una
presentación para el equipo de desarrollo y otra para el cliente, mismas que se
expondrán en reuniones posteriores. En estas reuniones se resumirá el
proyecto partiendo de la idea, la definición y su objetivo general, hasta llegar a
las grandes etapas de gestión, técnicas y metodologías empleadas para la
administración y desarrollo del sistema informático, así como las principales
aportaciones del proyecto, tanto como una solución de TI y como una fortaleza
para el área donde se implementó
Una vez realizada la documentación sobre la cancelación o aprobación del proyecto,
es necesario realizar un expediente del proyecto, el cual se presenta a continuación.

47. Otro documento que puedes utilizar para el llenado de información, en donde
podrás documentar los éxitos alcanzados, problemas durante el desarrollo,
entre otros, es el de lecciones aprendidas, el cual a continuación se te explica a
fondo.
Lecciones aprendidas
Las lecciones aprendidas constituyen un documento en el que se recuperan las
experiencias de trabajo a lo largo del proyecto. Su objetivo es recolectar en un
archivo los éxitos parciales alcanzados, problemas de gestión y problemas
técnicos y frustraciones operativas en el desarrollo de las actividades y tareas
del proyecto en general. Estas experiencias constituyen el conocimiento

48. colectivo del equipo del proyecto y permiten mejorar futuros desarrollos,
mediante la prevención, minimización o evasión de posibles riesgos. También
permiten conocer, con base en experiencias previas, escenarios que podrían
llegar a presentarse, para poder prever riesgos y su impacto, por ejemplo, el
tiempo y los costos para poder tomar decisiones en casos donde las
situaciones sean similares.
Por otro lado, también se pueden evitar problemas futuros si se mantienen en
regla todos los aspectos del proyecto. A continuación conocerás más a fondo la
concertación del proyecto y los acuerdos de negocio.

49. La presentación del proyecto
Si bien los entregables conforman la parte física que acompaña a un proyecto,
también es importante elaborar una serie de láminas a modo de presentación;
una para el equipo de trabajo y otra para el cliente.
El enfoque del contenido es distinto en ambas presentaciones, ya que, por un
lado, para el equipo de trabajo lo más importante será verificar el cumplimiento
de los objetivos en el desarrollo de la solución en TI, corroborar que la
planeación fuera la acordada desde un inicio y, en caso de que lo hubiera,
revisar el grado de desviación que se tuvo en relación con el cronograma, así
como el nivel y grado de aprendizaje de la metodología y las propuestas que se
hicieron hacia el interior del equipo para alcanzar la meta fijada.
Por otro lado, es recomendable que para el cliente la presentación se enfoque
en resaltar los beneficios que conlleva el uso de la herramienta de TI y el
cumplimiento del objetivo general, comparando los resultados tanto con la
solución informática como sin ella; si la implementación se ha llevado en
módulos, se tendrán mayores referencias. Es recomendable aplicar una
pequeña encuesta de satisfacción a los usuarios para ser presentada
gráficamente, que apoye el éxito del sistema informático implementado. Otras
características importantes para este tipo de presentación son el tiempo
invertido total, el presupuesto inicial contra los gastos y la curva de aprendizaje
del sistema por los propios
usuarios.