CONCEPTOS GENERALES

DEFINICIÓN DE SOFTWARE:
El software es
1. Instrucciones (programas de cómputo) que cuando se ejecutan proporcionan características
que dan ciertas funcionalidades a los usuarios.
2. Estructura de datos que permiten que los programas manipulen en forma adecuada la
información.
3. Información descriptiva tanto en papel como en formas virtuales que describen la operación
de programas.
El software son programas de computador, procedimientos, y la documentación y los datos
posiblemente asociado-relacionados con la operación de un sistema de computador.
SOFTWARE
- El software se desarrolla o modifica con intelecto; no se manufactura en el sentido clásico.
Los costos del software se concentran en la ingeniería. Esto significa que los proyectos de software
no pueden administrarse como si fueran proyectos de manufactura.
- El software no se desgasta.
El software no es susceptible a los problemas ambientales que hacer que el hardware se desgaste.
Por tanto, en teoría, la curva de la tasa de fallas adopta la forma de la -curva idealizada- las cuales
en realidad se corrigen a una -curva real-. En conclusión, el software no se desgasta, ¡pero si se
deteriora!
Vida Ideal:

Cuando uno va a implementar un software al principio el software falla o no funciona (lo que
se debe de hacer es afinar lo que haya que afinar para que inmediatamente el software
empiece a funcionar y se estabilice) esto es muy común en las implementaciones de software
 entonces el software se va a mantenerse constantemente estable en la línea del tiempo porque
si el software no cambia, el software no va a fallar, lo que tenia que fallar ya se quito y ya se
estabilizo hasta que el software se deja de usar (se deja de usar porque el hardware ya no
sirve, porque el sistema operativo en el que corría ya es obsoleto, ya no le dan mantenimiento)
Vida Real:

En la vida real la cosa es diferente porque se implementa un software y al igual que la otra
falla desde el principio porque hay que afinarle, colocarle los archivos, hacer la
configuración, etc. Uno empieza a estabilizar el software hasta que ya esta en un punto donde
se estabiliza, llega y va a funcionar bien.
Lo que pasa en las empresas se estabiliza un software y cuando llega a su estado de madurez
resulta que algo en el negocio cambio (ejemplo la pandemia), entonces se empieza a realizar
cambios esos cambios y volvemos arrancar el software con cambios donde se debe de
estabilizar y no mas se estabilice se hace otro cambio (porque encima que vino la pandemia
se le ocurre a la SAT hacer el FEL) entonces se realiza el cambio y se vuelve a estabilizar otra
vez el software, se nota que el software ya no se estabiliza de manera idealizada si no empieza
a estabilizarse de una manera distinta aceptar cierto margen de error.
DOMINIOS DE APLICACIÓN DEL SOFTWARE
- Software de Sistemas: Conjunto de programas escritos para dar servicios a otros programas.
- Software de Aplicación: Programas aislados que resuelven una necesidad especifica de negocios.
Ej: Procesamiento de transacciones en punto de venta, control de procesos de manufactura en
tiempo real.
- Software de Ingeniería y Ciencias: Caracterizado por algoritmos “devoradores de números”.
- Software Incrustado: Reside dentro de un producto o sistema. Ej: Tablero de horno microondas.
- Software de Línea de Productos: Diseñado para proporcionar una capacidad especifica. Ej:
Inventario.
- Aplicación Web: Llamadas webaps, categoría de software centrado en redes.
- Software de Inteligencia Artificial: Uso de algoritmos no numéricos para resolver problemas
complejos.
SURGIMIENTO DEL SOFTWARE
Con las primeras computadoras:
1. El programador era el mismo que ocupada la computadora, conocido como centro de cómputo.
2. Los problemas del día a día eran muy repetitivos, por lo tanto, muy sencillos.
Conforme las computadoras empezaron a desarrollar aparecieron las primeras PC’s:
1. Aparece la figura del programador especializado.
2. Debido al avance tecnológico de las computadoras y el incremento de la capacidad de procesos
que permite atender problemas más complejos.
3. Por primera vez se conoce la crisis del software debido a que escaseaba el talento humano época.
“El término ingeniería de software aparece por primera vez en el año 1968.”
Ingeniero: es el que aplica el método y enfoque científico a la solución de problemas.
Ingeniería de Software: Aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento de software, esto es, la aplicación de la ingeniería de
software.
Al unir el método científico con el software se crea un enfoque sistemático disciplinado y
cuantificable para desarrollar software por medio de técnicas y herramientas (aquí nace la
ingeniería de software).
¿Cómo solucionar un problema complejo? – aplicando básicamente 2 conceptos.
1. ¿Qué es Análisis? el cual consiste en tomar el problema y dividirlo en partes suficientemente
sencillas.
2. ¿Qué es Síntesis? una vez comprendidas las partes se vuelven a unir en un todo para resolver el
problema.
RELACIONES CON OTRAS DISCIPLINAS
- Ciencias de la computación.
Teorías y funciones de computadoras.
- Atención a Clientes Internos y Externos.
En términos generales son los primeros que generan problemas con los sistemas de información
teniendo prevención en los sistemas de testing y control de calidad de software, lo cual genera
mucha atención en soporte post implementación.
- La ingeniería de software desarrolla los siguientes puntos para resolver problemas.
1. Métodos.
2. Herramientas.
3. Procedimientos.
4. Paradigmas.
 - La ingeniería de software resuelve problemas en ambientes empresariales y corporativos, que
los analistas y programadores no saben o no pueden gestionar debido a la falta de los 4 puntos
indicados en el inciso anterior.
CAPAS DE LA INGENIERIA DE SOFTWARE
- Herramientas. (análisis y síntesis)
- Métodos.
- Procesos.
- Compromiso con la Calidad.
SOFTWARE DE LA SOCIEDAD ACTUAL
¿Dónde no está presente?
1. Energía.
2. Comunicaciones.
3. Automóviles.
4. Electrodomésticos.
5. Equipos Médicos.
¿Crisis del Software?
El término Crisis del Software se acuñó en 1968 Bauer, Bolliet & Heims, en la primera conferencia
elaborada por la OTAN celebró sobre desarrollo de software. Con dicho término se definieron los
problemas que surgían en el desarrollo de sistemas de software, cuyos proyectos terminaban tarde,
desbordando los presupuestos y con problemas de funcionamiento.
ÉTICA Y RESPONSABILIDAD
Repercusiones de fallas en el software:
- Perdidad financieras.
- Riesgos a la Seguridad.
- Credibilidad al gremio de tecnologia de información.
- Alta rotación de personal.
Más allá de las fallas:
- Impacto social.
- Calidad de vida.
- Cuestiones legales, generalmente denominados para recuperar el capital invertido.
- Costo de oportunidad por no contar con herramientas tecnologicas que demandadn el mercado
global.
PROBLEMAS TÍPICOS DE LA INGENIERÍA DE SOFTWARE
1. No se cumple con el plazo estipulado para la entrega de la aplicación funcionando y sin errores.
2. Costo mucho más elevado respecto al presupuesto establecido.
3. Utilidad de la solución de la aplicación.
4. Requerimientos obscuros o cambiantes por parte del usuario final.
5. Fallas de la aplicación por no aplicar técnica QA.
6. Rigidez del software que no permite acomodarse a las nuevas modalidades.
7. Alto costo de mantenimiento, tener mucho personal alternamente calificado.
8. Riesgo, siempre es alto al desarrollar aplicaciones.

CALIDAD – PERSPECTIVA DEL CONCEPTO

Perspectiva de la calidad
1. Trascendente – se reconoce, pero no se puede definir.
2. Del Usuario – adecuado al uso (gustos propios de cada usuario).
3. Del Productor – adecuación a las especificaciones (lo que requiere la organización).
4. Del Producto – características específicas.
1. Comportamiento externo (visibilidad para todos)-
2. Características internas (normalmente solo visible al productor).
5. Basada en el valor – cuanto está dispuesto a pagar ($).
La calidad es un circulo de mejora continua que se conoce como el ciclo de Deming
CALIDAD – PERSPECTIVA DEL USUARIO – IMPLEMENTADOR
Usuario
1. Satisfacer necesidades / expectativas (utilidad, tiempo de respuesta).
2. Esfuerzo necesario (facilidades de aprendizaje y uso).
3. Sin inconvenientes (frecuencia e impacto de fallas).
Implementador
1. Cantidad y tipo de fallas.
2. Facilidad de entender.
3. Bajo impacto de las modificaciones.
 CALIDAD – OTRAS PERSPECTIVAS
• Según la visibilidad
- Factores Internos y Externos.
• Atinentes al:
- Producto, una vez que ya existe.
- Proceso de productos, mientras se produce.
• ¿Qué relación habrá entre?
- Factores Internos y Externos.
- Factores del Proceso y del Producto.
• En contexto del negocio
- Valor técnico, valor para el negocio.
• Retorno de la inversión, ROI
- Período de repago.
- Tasa de retorno.
- Valor actual de los flujos de caja.
• Retorno de la inversión, Software
- Factores de costo – beneficio.
• Valor para el negocio
¿QUIENES PARTICIPAN EN LA INGENIERÍA DE SOFTWARE?
• Producto o proyecto llave en mano.
• Integración:
• En forma nativa.
• Por Interfaz.
• Por hardware.

INGENIERÍA DE SOFTWARE Y SISTEMAS

El software como componente de un sistema
- Hardware.
- Software.
- Personas.
Sistema
- Límite.
- Interacción con el Exterior.
- Componentes y sus Relaciones.

MODELOS DEL PROCESO

ESTRUCTURA DE UN PROCESO DE SOFTWARE
FLUJOS DE PROCESO

a) Flujo de Proceso Lineal

Ejecuta cada una de las cinco actividades estructurales en secuencia, comenzando por la
comunicación y terminando por el despliegue.
 b) Flujo de Proceso Iterativo
Repite una o más de las actividades antes de pasar a la siguiente.
El flujo de proceso es la base para llegar a las metodologías tradicionales o a algunas
metodologías de desarrollo de software.

c) Flujo de Proceso Evolutivo

Realiza las actividades en forma circular; a través de las 5 de actividades, cada circulito lleva a una
versión más completa del software.

d) Flujo de Proceso Paralelo

Ejecuta una o más actividades en paralelo (por ejemplo, el modelado de un aspecto software tal vez
se ejecuta en paralelo).
MODELOS DE PROCESO PRESCRIPTIVO – MODELO DE CASCADA
El modelo de cascada, a veces llamado ciclo de vida clásico sugiere un enfoque sistemático y
secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos
por parte del cliente y avanza a través de planeación, modelo, construcción y despliegue, para
concluir con el apoyo del software terminado.

Al inicio después de 1968 que fue donde se juntaron las personas para empezar a ver el tema
de la criticidad del software, fue que crearon la ingeniería de software y dentro de la ingeniería
del software crearon las metodologías de desarrollo de software. Entonces de las primeras
metodologías del desarrollo de software fue el modelo de cascada esta es la metodología
tradicional pero no es la única también esta la que se conoce como modelo en V.
MODELO EN V
Es una variante del modelo de la cascada.
Se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con
la comunicación, modelado y construcción temprana. A medida que el equipo de software avanza
hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia
representaciones técnicas cada vez más detalladas del problema y de su solución. Una ve se ha
generado el código, el equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de
pruebas (acciones para asegurar la calidad) que validan cada uno de los modelos creados cuando el
equipo fue hacia abajo por el lado izquierdo.
Esta metodología ha servido de base para las metodologías de implementación de ERP de clase
mundial.
Modelado de los Requerimientos: Entender cómo funciona el negocio, después de esto tenemos
que saber que es lo que el cliente espera.
Diseño de la Arquitectura: Saber que arquitectura se va a utilizar: cliente servidor, web,
microservicios. Aquí se empieza a diseñar el modelo ER, modelo de BD, casos de uso,
diagramas UML.
Diseño de los Componentes: aquí se escoge cual es el lenguaje de programación: java, php, etc.
Generación de Código: después de realizar todos los puntos anteriores pasamos a realizar la
programación. Luego de realizar esto se debe de compilar todos los programas (cada miembro
del equipo agarra un módulo).
Pruebas Unitarias: significa que uno como programador va a validar que lo que se programo
funcione. (prueba de uno, yo). Si en dado caso da problemas en las pruebas se cambia o se
modifica y se vuelve a realizar las pruebas unitarias. Si no hay mayor inconveniente en estas
pruebas, podemos pasar a las pruebas de integración.
Pruebas de Integración: es donde un programador con otro programador realizaron sus
módulos, pero ahora lo tienen que unir y tienen que ver que esos módulos coexistan uno con el
otro y que se transfieran o graben los datos necesarios y que trabajen bien de manera conjunta.
(puede que en estas pruebas suceda algo incompatible porque no se uso un componente
 adecuado, entonces se debe de regresar a la parte componente o puede ser que en esa parte de
la integración no se había contemplado algo y eso afecto la arquitectura).
Pruebas del Sistema: el cliente nos dice que su sistema haga a, b, c, d, e. entonces en las pruebas
del sistema es que al cliente se le muestra y se le dice mire para que su sistema haga a se hace
esto y esto y se le demuestra que funciona y así sucesivamente empieza a probar uno por uno
de las cosas que tiene el sistema hasta que el cliente dice “si cumple con lo que el necesita de
cumpla”. Si algo sale mal se debe de regresar en la arquitectura y ver si se esta utilizando lo
que se debe de usar o simplemente el cliente dice lo que usted está haciendo ahí yo no se lo
pedí. (puede que sea un error o puede que la empresa haya cambiado con lo que quería).
Pruebas de Aceptación: es donde se le demuestra al cliente que el sistema hace lo que el necesita
que haga.
EL MODELO INCREMENTAL
Aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada
secuencia lineal produce “incrementos” de software susceptibles de entregarse de manera parecida a los
incrementos producidos en un flujo de proceso evolutivo.

Sirve cuando uno hace un desarrollo, resulta que cuando uno lo termina el usuario se da cuenta
que se obtener más y más y resulta un circulo de mejora (el circulo de mejora es que el esta viendo
el beneficio que tiene para su empresa tener estos sistemas de información y como mira que tiene
estos beneficios, el quiere tener aun más beneficios y quisiera meter todo lo que el hace en el
sistema, para que el sistema le dé reportes, estadísticos o información necesaria para toma de
decisiones)
EL PARADIGMA DE HACER PROTOTIPOS
Comienza con comunicación.
Se reúnen con los participantes para definir los objetivos generales del software, identifica cualquier
requerimiento que conozca y detecta las áreas en las que es imprescindible una mayor definición.
Se planea rápidamente una iteración para hacer el prototipo, y se lleva a cabo el modelado en forma de
un diseño rápido.
El diseño rápido lleva a la construcción de un prototipo, este es entregado y evaluado por los
participantes, que dan retroalimentación para mejorar los requerimientos.

La ventaja de hacer prototipos es que de alguna manera pronta y rápida el usuario tenga idea de
como va a ser su software, eso si va a ver pantallas vacías (se refiere a que va a estar poblada de
campos, pero no va a grabar, no va a consultar, no va a hacer nada). Le da una idea al usuario
final de como el espera ver el sistema en teoría funcionando.
MODELO ESPIRAL
Es un generador de modelo de proceso impulsado por el -riesgo-, que se usa para guiar la ingeniería
concurrente con participantes múltiples de sistemas intensivos en software. Tiene dos características
distintivas principales.
1. Enfoque cíclico para el crecimiento incremental del grado de definición del sistema e
implementación mientras disminuye el riesgo.
2. Puntos de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones
factibles y satisfactorias.
MODELO DE DESARROLLO BASADO EN COMPONENTES
Incorpora muchas de las características del modelo espiral. Es de naturaleza evolutiva y demanda el
enfoque iterativo para la creación de software. Sin embargo, el modelo de desarrollo basado en
componentes construye aplicaciones a partir de fragmentos de software prefabricados.
El modelo de desarrollo basado en componentes lleva a la reutilización del software.

Este es muy ágil pero el riesgo de que no haga lo que se esperaba es un poco más elevado.
MODELO DE MÉTODOS FORMALES
Lleva una especificación matemática formal del software de cómputo. Permite especificar, desarrollar y
verificar un sistema basado en computadora por medio de matemáticas rigurosas.
No es muy seguido, pero promete un software libre de defectos.
• El desarrollo de modelos formales consume mucho tiempo y es caro.
• Pocos desarrolladores tienen esta formación, se requiere mucha capacitación.
• Es difícil utilizar los modelos como mecanismo de comunicación para clientes sin complejidad
técnica.

PROCESO UNIFICADO – UML (Es precursor de las metodologías agiles).

Es un intento por obtener los mejores rasgos y características de los modelos tradicionales del
proceso de software, pero en forma que implemente muchos de los mejores principios del
desarrollo ágil de software. Reconoce la importancia de la comunicación con el cliente y los
métodos directos para describir su punto de vista respecto de un sistema o caso de uso.
Hace énfasis en la importancia de la arquitectura del software para que sea comprensible, permita
cambios futuros y reutilización.

Este proceso unificado lo que hace es que, teniendo una comunicación con el usuario, se tiene
una concepción y planeación de que es lo que se va a hacer, para modelarlo y de una vez
agregarle código y eso lo colocamos a funcionar. Entonces lo que uno hace son desarrollos
basados en comunicación y ponernos de acuerdo con el usuario final y el programador. Esto
viene siendo un poco más ágil (es incremental). Metodologías agiles es: scrum.
 DESARROLLO ÁGIL
DESARROLLO ÁGIL – DESCUBRIENDO MEJORES FORMAS DE HACER LAS
COSAS
(aspectos que se deben de tomar en cuenta para hacer desarrollo ágil)
1. Tener al equipo de desarrollo necesario para poder implementar metodologías agiles.
2. Enfocarse a que el software funcione.
3. Colaboración con el cliente.
4. Responder al cambio.
- Los individuos y sus interacciones, sobre los procesos y herramientas.
- El Software que funciona, más que la documentación exhaustiva.
- La colaboración con el cliente, y no tanto la negociación del contrato.
- Responder al cambio, mejor que apegarse a un plan.
QUE ES ÁGILIDAD
• Un proceso de software moderno.
• Un equipo ágil es diestro y capaz de responde de manera apropiada a los cambios.
• El cambio es de lo que trata el software en gran medida.
• Hay cambios en el software que se construye, en los miembros del equipo, debidos a las
nuevas tecnologías, de todas clases y que tienen un efecto en el producto que se elabora o
en el proyecto que lo crea.

Ágil es que en muy corto plazo de tiempo nosotros podamos planificar, diseñar, desarrollar,
probar, instalar y por último vamos a lanzar al productivo, pero esto se hace en cortos
espacios de tiempo de 2 a 4 semanas (no más de esto porque se debe de hacer entregables
tangibles).

CAMBIO DE LOS COSTOS EN FUNCIÓN DEL TIEMPO TRANSCURRIDO

La experiencia estable que los costos se incrementan en forma no lineal a medida que el proyecto
avanza.
• Es muy fácil hacer lo cambios al inicio del proyecto y el equipo de proyecto reúne los
requisitos.
• Los defensores de la agilidad afirman que un proceso ágil bien diseñado “aplana” el costo
de la curvatura.
La línea de negro son metodologías tradicionales de desarrollo (se empieza a llevar la metodología,
pero no hay entregables pronto, se empieza a entregar a los 6 o 12 meses). La línea de gris es de
procesos agiles. Y la línea de pedazos es del costo ideal.
Como ingenieros tenemos que cuidar los costos de desarrollo y después de cambios

¿QUÉ ES UN PROCESO ÁGIL? – FORMA EN QUE SE ABORDA LAS SUPOSICIONES

1. Es difícil predecir que requerimientos de software persistirán y cuales cambiarán.
2. Para muchos tipos de software, el diseño y la construcción deberá ser simultáneos.
3. El análisis, diseño, la construcción y pruebas no son tan predecibles como nos gustaría.

PRINCIPIOS DE ÁGILIDAD
1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y continua del
software.
2. Son bienvenidos los requerimientos cambiantes.
3. Entregar con frecuencia software que funcione.
4. Las personas de negocios y los desarrollos deben trabajar juntos.
5. Hay que desarrollar los proyectos con individuos motivados.
6. Comunicación efectiva cara a cara.
7. La medida principal de avance es el software que funciona.
8. Los procesos ágiles promueven el desarrollo sostenible.
9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.
10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no realizado.
11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos con organización
propia.
12. El equipo reflexiona a intervalos regulares sobre como ser más eficaz.
PROGRAMACIÓN EXTREMA – XP (es un método de desarrollo acelerado)
• Es el enfoque más utilizado del desarrollo de software ágil.
Comunicación Eficaz: Colaboración estrecha en forma verbal.
Simplicidad: Solo diseñar las necesidades inmediatas.
Retroalimentación: Software implementado, clientes y equipo.
Disciplina: Diseñar para hoy y los requerimientos no cambien.
Respeto: El equipo ágil inculca respeto entre sus miembros.
PROGRAMACIÓN EXTREMA – EL PROCESO XP
• Usa un enfoque orientado a objetos como paradigma preferido de desarrollo.
• Engloba un conjunto de reglas y prácticas que ocurren en 4 actividades:
1. Planeación, se escuchan historias de usuarios y se define prioridad.
2. Diseño, mantenlo sencillo.
3. Codificación, programación por parejas en una sola estación para crear código de una
historia.
4. Pruebas, son pruebas del cliente especificadas por el cliente.

La Programación eXtrema si funciona y sirve para hacer cosas que son realmente críticas y
que son beneficio para la organización.
EL DEBATE XP – ASPECTOS DE LOS CRÍTICOS
• Volatilidad de los requerimientos, los cambios se solicitan de manera informal, el alcance
del proyecto cambia y debe cambiarse el software para adoptar los cambios.
• Necesidades conflictivas del cliente, cada proyecto tiene cliente múltiples, cada uno con
sus propias necesidades.
• Los requerimientos se expresan informalmente, las historias de usuario y pruebas de
aceptación y su única manifestación explicita de los requerimientos en XP.
• Falta de un diseño formal, no motiva el diseño de la arquitectura, los diseños de las clases
deben ser informales. La sencillez es básica en XP y por ello limita lo completo, pero pone
en riesgo la calidad de ser susceptible a recibir mantenimiento.
DESARROLLO ADAPTATIVO DE SOFTWARE – DAS
Los fundamentos filosóficos de DAS se centran en la colaboración humana y en la organización
propia del equipo.
• Especulación, inicia planeación adaptativa del ciclo, requerimientos básicos para definir
los ciclos incrementales.
• Colaboración, multiplicar la producción creativa más allá. Incluye comunicación, trabajo
en equipo, confianza, crítica constructiva, ayuda mutua, trabajo duro.
• Aprendizaje, ayudará a los desarrolladores a mejorar el nivel de entendimiento
completando el software.

SCRUM
Los principios Scrum son congruentes con el manifiesto ágil y se utilizan para guiar actividades de
desarrollo dentro de un proceso de análisis que incorpora las actividades estructurales:
requerimientos, análisis, diseño, evolución y entrega. Dentro de cada actividad estructural, las
tareas del trabajo ocurren con un patrón del proceso llamado sprint.
• Retraso: lista de prioridades de los requerimientos o características del proyecto que dan
al cliente un valor del negocio. Es posible agregar en cualquier momento otros aspectos al
retraso (ésta es la forma en la que se introducen los cambios). El gerente del proyecto evalúa
el retraso y actualiza las prioridades según se requiera.
• Sprints: consiste en unidades de trabajo que se necesitan para alcanzar un requerimiento
definido en el retraso que debe ajustarse en una caja de tiempo14 predefinida (lo común
son 30 días). Durante el sprint no se introducen cambios (por ejemplo, aspectos del trabajo
retrasado).
• Reuniones Scrum: son reuniones breves (de 15 minutos, por lo general) que el equipo
Scrum efectúa a diario. Hay tres preguntas clave que se pide que respondan todos los
miembros del equipo: 1. ¿Qué hiciste desde la última reunión del equipo?, 2. ¿Qué
 obstáculos estás encontrando?, 3. ¿Qué planeas hacer mientras llega la siguiente reunión
del equipo?

CONTEXTO DE LA DIRECCIÓN DE PROYECTOS

DEFINICIÓN DE PROYECTO:
Un proyecto es un esfuerzo temporal (todo aquello que sea en un espacio de tiempo se puede
considerar proyecto, pero que esto permita crear producto, servicio o resultado único para una
organización o una empresa). La Naturaleza del tiempo significa que debe tener un principio
(un inicio) y un final bien definido. El final se alcanza cuando se logran los objetivos del
proyecto, cuando se termina porque sus objetivos no se cumplirán o no puede ser cumplidos, o
cuando ya no existe la necesidad que le dio origen.
FASES QUE VA A TENER UN PROYECTO

Durante todas las fases vamos a estar controlando los proyectos desde el principio a fin.

UN PROYECTO PUEDE GENERAR:

• Un producto, que puede ser un componente de otro elemento.
• Un servicio o la capacidad de realizarlo.
• Una mejora de las líneas de productos o servicios existentes.
• Un resultado, tal como una conclusión o un documento.
El factor común es que todo proyecto debe de generar algo, si un proyecto no genera algo en
beneficio a la organización tampoco es proyecto.

SUB-PROYECTOS
Cada sub-proyecto tiene las mismas fases que un proyecto.
Los proyectos se puedes hacer sub-proyecto, y estos sub-proyecto deben tratarse a su vez
como si fueran proyectos.

DIRECCIÓN DE PROYECTOS
En todo proyecto debe de haber una cabeza, porque una persona debe de ser responsable del
proyecto (solamente una) ya que cuando hay más de una persona responsable ninguna se hace
cargo del proyecto.
La dirección de proyectos tiene que manejar unos procesos que son:
- Iniciación.
- Planeación.
- Ejecución.
- Seguimiento y Control.
- Cierre.

ÁREAS DE EXPERIENCIA EN LA DIRECCIÓN DE PROYECTOS

Guía PMBOK:
• Conocimiento del Área de Aplicación, Estándares y Regulaciones (para poder dirigir un
 proyecto.
• Entendimiento del Ambiente del Proyecto. (es decir que debemos tener experiencia).
• Conocimiento y Habilidades de Administración General del Proyecto. (el director de
Proyectos)
• Habilidades Interpersonales. (como liderazgo, trabajo en equipo, empatía, coach,
inteligencia emocional) “todas estas características deben tener un líder de proyecto porque
él se va a someter a un estrés bastante fuerte al ser el único responsable del proyecto”.

PROGRAMA
Se habla de un tipo de agrupación de proyectos, una forma de clasificar los proyectos; y los
proyectos los podemos orientar o lo podemos agrupar dentro de programas de proyectos y este
nos puede servir para estructurar de alguna manera nuestros proyectos. Entonces un tipo de
clasificador.

EJEMPLO DE DIRECCIÓN DE PROGRAMA

PORTAFOLIO DE PRODUCTOS
Es toda la variedad de productos que una empresa ofrece a sus clientes.

PORTAFOLIO
portafolio es otra forma de clasificar los proyectos, un portafolio puede agrupar varios programas,
y varios programas pueden agrupar varios proyectos. Y un portafolio puede agrupar tanto
programascomo proyectos según la conveniencia que uno tenga.

RELACIÓN ENTRE LA DIRECCIÓN DE PROYECTOS, DIRECCIÓN DE PROGRAMAS

Y GESTIÓN DE PORTAFOLIOS
Cuando son muy pocas empresas como uno o dos no hacen esto.
Cuando son varias empresas tienen objetivos estratégicos y en primer lugar usan la oficina de
proyectos, se empieza a manejar algunos proyectos dentro de un programa y se va a tenervarios
programas en ejecución con diversos proyectos y todo esto va a formar el portafolio de proyectos.
(se organiza de la manera que a uno más le conviene). (se va a tener directores de proyectos,
directores de programas y directores de portafolio).

DIRECCIÓN ORGANIZACIONAL DE PROYECTOS

Se debe definir tanto como a los proyectos, los programas y los portafolios el alcance.

El alcance es lo que uno va a hacer dentro del proyecto y que es lo que no se va a hacer
dentro del proyecto. (es importante decir dentro del proyecto que no se está contemplando).
El cambio, en todos los proyectos siempre hay cambios, pero se debe de manejar nuestros
cambios. No se debe de permitir que los cambios nos dominen.
También se manejará la planificación y la dirección tanto en proyectos, programas y
portafolios.

OFICINA DE DIRECCIÓN DE PROYECTOS PMO

Las empresas grandes tienen la PMO, la PMO es una oficina de proyectos (hay proyectos de
ventas, proyectos de recursos humanos, proyectos de mejoras de edificios, proyectos de
automatización, proyectos de optimizar los costos, proyectos de tecnología, proyectos
aseguramiento a la calidad de productos).
La PMO organiza estos proyectos dentro de una organización, es donde se centraliza todos los
proyectos de la organización. Cuando son empresas pequeñas dos, tres o cuatro no es necesario
hacer una PMO porque esto requiere una capital de inversión, requiere contratar profesionales
que se dediquen solo a proyectos.
La PMO sirve para definir políticas, para obtener recursos, para manejar procesos, estándares
y entrenamiento dentro de la organización.

GESTIÓN DE OPERACIONES
Un proyecto es algo que es definido en el tiempo, porque tiene un origen, una fecha de inicio
y una fecha de fin. (cuando no tiene fecha de inicio y fecha de fin esos se llama operación)
Las operaciones son una función de la organización que efectúan permanentemente actividades
que producen un mismo producto o proveen un servicio repetitivo.

ROL DEL DIRECTOR DEL PROYECTO

El director de proyectos es la persona asignada por la organización para alcanzar los objetivosdel
proyecto. (Todo proyecto tiene que llevar a un director de proyectos).
El Patrocinador es quien designa al director del proyecto.
El patrocinador es el alto ejecutivo que le da dinero o da cuentas para que tenga vida el
proyecto.

DIRECCIÓN EFECTIVA DE PROYECTOS

El director del proyecto debe de contar al menos con 3 características:
- Conocimiento, debe saber de dirección de proyectos.
- Desempeño, aplicando el conocimiento de dirección de proyecto puede hacer las
cosas.
- Personal, debe comportarse con inteligencia emocional, con actitud positiva, liderazgo
para guiar el equipo para alcanzar los objetivos.

CONSIDERACIÓN DEL DIRECTOR DE PROYECTO

Triple Restricción:
En base a los requerimientos funcionales se designa un alcance.
El Alcance es todo lo que se va a hacer y lo que no se va a hacer también es parte del alcance
(lo que no se va a hacer se debe de escribir en un papel para que se conozca). Cuando se define este
alcance se podrá estimar el tiempo que se va a llevar para realizarlo, porque se debe de saber con
cuánta gente vamos a contar entonces como se sabe con cuánta gente se va a trabajar definimos
una cantidad de tiempo para cumplir el alcance, teniendo esto se le pone precio alos costos que
se va a consumir sueldos, salarios, computadoras, servidores, internet, nube, alquileres, energía
eléctrica, etc. Entonces teniendo el alcance, tiempo y el costo, entonces se puede dar cierto nivel
de calidad al entregable del proyecto.
FACTORES AMBIENTALES DE LA EMPRESA
Se deben de tomar en cuenta estos factores ambientales como director de proyectos, que son:
- Cultura de la empresa.
- Ambiente social.
- Nivel de Tecnología.
- Esquema Económico/Financiero.
- Ambiente Jurídico/Político.
- Competencia (personal que tendremos a nuestro cargo que tan competente es).
- Estándares y Reglamentos. (Reglamento del corte de cabello, vestimenta).

CICLO DE VIDA DEL PROYECTO

Todo tiene un ciclo de vida, un proyecto normalmente se divide en fases, cada una de esas
fases normalmente es sinónimo de un sub-proyecto y un sub-proyecto se maneja igual queun
proyecto, por lo tanto, significa que cada fase va a tener un inicio, un fin y al fin va a tener
entregables. (lo mismo en cada fase).

CARACTERÍSTICAS DEL CICLO DE VIDA DE PROYECTO

Todo proyecto va a arrancar con una salida de la dirección del proyecto en términos generales,para
en términos de nosotros ingenieros en sistemas los proyectos van a arrancar con un DERCAS.
(todos los proyectos de desarrollo de software).
Sub-proyecto 1: Salidas de la Dirección del Proyecto.
Sub-proyecto 2: Acta de Constitución del Proyecto. (Inicio del proyecto o darle vida y es donde
se nombra al director del proyecto y al equipo del proyecto)
Sub-proyecto 3: Plan para la dirección del proyecto. (Organización y Preparación, se elaboraotro
documento y el plan para la dirección del proyecto contempla el DERCAS, el acta de constitución
del proyecto y todos los procesos).
Sub-proyecto 4: Entregables Aceptados. (Después van los criterios de aceptación en donde se va
entregando el software funcionando y entonces los usuarios interesados nos ira aceptando el
software o rechazando, dependiendo el caso).
Sub-proyecto 5: Documentos del Proyecto Archivado. (Documento de Cierre del Proyecto).

DERCAS: Documento Especificación de Requerimientos y Criterios de Aceptación de

Software.

IMPACTO DE LA VARIABLE EN FUNCIÓN DEL TIEMPO DEL PROYECTO

Si uno quiere cambiar algo cuando el proyecto inicia, cualquier cambio que se haga no cuesta casi
nada de dinero o esfuerzo, pero la influencia de los interesados, la incertidumbre y el riesgo de
que el proyecto fracase es ALTO, cuando arranca un proyecto.
Cuando el tiempo va pasando y estamos por terminar un proyecto la influencia de los interesados
es muy BAJA, estos interesados ya no deben que aportar mayor cosa porque ya está funcionando,
el riesgo a que fracase o la incertidumbre de que funcione YA NO EXISTE porque ya está
funcionando. Mientras que, si se quiere hacer cambios, pero ya en ambiente productivo ya sale
CARO ya no es tan fácil en hacer cambios. Por eso es importante plantear bien desde un principio
comose va a hacer el sistema y que cosas va a llevar para tener todo bien documentado.

RELACIONES ENTRE EL CICLO DE VIDA DEL PRODUCTO Y DEL PROYECTO

Los productos son el resultado de un proyecto, es que el producto tiene una preparación,
construcción, acabados y una aceptación final.
Proyectos manejan el proceso de iniciación, el proceso de planificación, el proceso de ejecución,
el proceso de seguimiento y control (en todo momento desde el inicio hasta el final) y el proceso
de cierre.

ÉXITOS DEL PROYECTO

Para que un proyecto sea exitoso se debe de hablar acerca del alcance, tiempo, costo y la
calidad como mínimo, pero también se debe de considerar los recursos y el riesgo. (el riesgo se
puede mitigar o gestionar).

INTERESADOS DE UN PROYECTO
- Patrocinador (da vida al proyecto y nombra al director del proyecto)
- Director del Proyecto (escoge al equipo).
- Equipo del proyecto.
- Equipo Directivo del Proyecto.
- Otros miembros del equipo del proyecto (de manera interna).
- Oficina de Dirección de Proyectos (PMO) (de manera externa).
- Director del Programa.
- Director del Portafolio.
- Otros interesados.
- Gestión de Operaciones.
 - Gerentes Funcionales.
- Vendedores / Socios de Negocios.
- Clientes / Usuarios.

ORGANIZACIÓN FUNCIONAL
- Un Director Ejecutivo.
- Gerentes Funcionales.
- Cada Gerente con su Personal a Cargo.

ORGANIZACIÓN MATRICIAL – DÉBIL

Un Director Ejecutivo, Con Gerentes Funcionales, Pero en la parte de hasta abajo se tiene a
la Coordinación del Proyecto.
ORGANIZACIÓN MATRICIAL – EQUILIBRADA
Se va a tener un Director del proyecto debajo de un Gerente Funcional y se va a tener a otras
personas que nos va a ayudar para manejar el proyecto.

ORGANIZACIÓN MATRICIAL – FUERTE

Se puede tener también Gerente Funcional (como ventas, compras, contabilidad) pero adicional
dentro del organigrama se tiene a un Director de Directores de Proyectos (va a manejar varios
directores de proyectos para cada uno de los proyectos que se va a manejar).

ORGANIZACIÓN ORIENTADA A PROYECTOS

Cambia completamente porque se va a tener Director de Proyectos debajo del Director Ejecutivo
y cada uno de ellos va a manejar a su personal de cada proyecto que van a administrar.

ORGANIZACIÓN COMBINADA
Puede ser que tenga Director Ejecutivo, se tiene Gerente Funcionales (gerente normal dentro de
una empresa como ventas, compras), se tendrá Director de Directores y dentro de cada uno de
esto se va a tener Director de Proyecto de una forma horizontal y se puede tener unacoordinación
de forma vertical.

*Cuando se hace la PMO saca a la gente del área funcional y la mete en la oficina en la PMO
en el área de proyectos*

NATURALEZA DE LA DIRECCIÓN DE PROYECTOS

¿Cuáles son los Procesos que lleva cada Proyectos, fases o sub-proyectos son?
- Proceso de Iniciación: Define autoriza un nuevo proyecto.
- Proceso de Planificación: Establece alcance, objetivos y curso de acción.
- Proceso de Ejecución: Integra individuos y otros recursos para llevar a cabo el plan.
- Proceso de Seguimiento y Control: Mide y da seguimiento al proceso paraidentificar
 las variaciones y aplica acciones correlativas para lograr los objetivos.
- Proceso de Cierre: Formaliza la Aceptación del Producto.

EN LA NATURALEZA DE LA DIRECCIÓN DE PROYECTOS ENTRA LA:

- Fase de un Proyecto.
- Proceso de Iniciación.
- Planificación.
- Ejecución con su Seguimiento y Control.
- Cierre.

INTERACCIONES ENTRE PROCESOS

- Grupo del proceso de iniciación. (Inicio)
- Grupo de proceso de planificación.
- Grupo de proceso de Ejecución.
- Grupo del proceso de Seguimiento y Control.
- Grupo del proceso de Cierre. (Finalización).

INTEGRACIÓN DEL PROYECTO

PMP (Project Management Professional)
PMBOK (Project Management Base Of Knowledge)

INTEGRACIÓN
Es un área de conocimiento del PMP que nos sirve para poder implementar todas las áreas
de conocimiento de esta metodología para que el proyecto tenga éxito al final. Incluyendo
todas las áreas de conocimiento (como alcance, tiempo, costo, calidad, recursos, adquisiciones,
riesgos, comunicaciones) todo esto para hacer exitoso un proyecto.

¿Desde el punto de vista académico, usted tiene a cargo un proyecto de desarrollo de

software usando su sentido común, cual sería el producto entregable de un desarrollo de
software?
R// software, documentación, certificación y la implementación (que se utilice).

Se planea y produce usando el ciclo de vida del proyecto y al final se obtendrá el entregable de
un proyecto de desarrollo de sistema es el software funcional e implementado. Si el software no
se usa, entonces el proyecto fue un fracaso.
Se va a medir la calidad con la satisfacción del usuario final. El alcance, tiempo y costo ayudan a
definir la calidad. Se debe tener constante comunicación con los usuarios porque ellos son los
dueños de los procesos. Las adquisiciones son las compras que se hacen dentro del proyecto, estas
van de la mano con los costos. Gestionar los recursos humanos por medio del liderazgo.
¿la metodología de proyectos es equivalente a SCRUM?
No es equivalente porque el SCRUM es una metodología de desarrollo como (V, cascada,
espiral, basada en prototipo).

La metodología de proyectos es en donde se lleva el alcance del proyecto, calidad del

proyecto, tiempo del proyecto, costos del proyecto, comunicaciones con los usuarios y con
los interesados, en donde se manejan las compras de todo lo que se necesita dentro del
proyecto, donde se gestiona a las personas y se busca a la que tenga mejor talento, donde se
administran los riesgos y se tratan de mitigarlos.

Ciclo de vida de proyecto no es lo mismo que el ciclo de vida de software y tampoco es lo

mismo que el ciclo de desarrollo de software.

ACCIONES CRÍTICAS EN LA INTEGRACIÓN DEL PROYECTO

El documento del plan para la dirección del proyecto se actualiza constantemente durante el
desarrollo del proyecto. No se deben asumir cosas, todo debe estar documentado. La mayoría de
los proyectos fracasan por falta de comunicación.
Cuando se arranca un proyecto se maneja el concepto de Kick-Off Meeting (Reunión de la Patada
Inicial) significa el momento en que inicia un proyecto – Junta de arranque del proyecto.
En la carta constitutiva del proyecto se debe establecer los objetivos (el objetivo general,
objetivo especificos) y metas.
EDT (significa estructura desglosada de trabajo)

ÁREAS DE CONOCIMIENTO.
1. Gestión de la Integración del Proyecto (5 procesos: grupo de proceso de iniciación, grupo
del proceso de planificación, grupo del proceso de ejecución, grupo del proceso de
 seguimiento y control, grupo del proceso de cierre)
a. El primer proceso cuando inicia un proyecto es desarrollar el acta de constitución
del proyecto (Develop Project Charter)
El acta de constitución del proyecto aprobada marca el inicio formal del
proyecto, esta acta le da autoridad al director del proyecto para asignar
recursos.
b. El enunciado de trabajo del proyecto es el DERCAS
c. El caso de negocio: son los diagramas de proceso del negocio
d. Proyecto: conjunto de actividades planificadas para lograr un producto en un
determinado tiempo, el cual tiene una fecha de inicio y una fecha de finalización
e. El alcance de un producto no es lo mismo que el alcance de un proyecto.
f. En el DERCAS se plantea el alcance del producto que se busca tener con el proyecto.
g. El alcance del producto es un subconjunto del alcance del proyecto.
h. Casos de negocio. Acuerdos de nivel de servicio (SLA)
i. Los activos de los procesos de la organización son los documentos que se emiten de
los proyectos, políticas o procedimientos internos de las empresas son activos de los
procesos de la organización. Los proyectos usan esta documentación para ejecutar
los proyectos.
¿Qué es un Proyecto? Es un conjunto de actividades planificadas para lograr un producto
en un determinado tiempo, el cual tiene una fecha de inicio y una fecha de finalización, donde
va a tener un entregable que va a ser un producto o un servicio o un documento.
¿Qué es el alcance de un Producto? Es elaborar un software donde se cumple todos los
requerimientos que pidió el cliente, que el cliente este contento y que lo use. (es solo la parte
que se va a entregar como proyecto). (el producto es un subconjunto del alcance del
proyecto).
¿Qué es el alcance de un Proyecto? Es donde se entrega el producto en el tiempo que se
ofreció, con el presupuesto que se definió, con las características de calidad que se definió,
con las adquisiciones que se dijo que se iban a hacer, con el nivel de comunicación que dijimos
que se iba a tener con los interesados, mitigando los riesgos que se pudieran presentar.
El alcance del proyecto es hacerlo en el presupuesto, tiempo, adquisiciones esperadas,
personal que se dijo que se iba a ocupar para hacerlo y en el alcance producto es todo lo que
el cliente espera que haga el software. (el producto es un subconjunto del alcance del
proyecto.
SMART: no solo significa “inteligente”, por su traducción del inglés, sino que además las
letras que le componen son un efectivo checklist que potenciará la efectividad de tu estrategia
inbound a la hora de definir los objetivos. Cada letra representa un requisito que tus
objetivos deberán cumplir. S (especifico), M (medible), A (alcanzable), R (relevante) y T (a
tiempo).
2. Herramientas y técnicas
a. Juicio de expertos. El director de proyecto debe ser una persona experta en el tema del
proyecto.
 b. Técnicas de facilitación, se usan para poder investigar, para poder conocer, para poder
saber cómo elaborar el acta de la constitución del proyecto o carta constitutiva del
proyecto.
3. Acta de constitución del proyecto.
a. Se deben colocar los objetivos SMART
b. Hitos son los eventos o reuniones importantes que van a ocurrir dentro del proyecto.

PLAN PARA LA DIRECCIÓN DEL PROYECTO

Se tienen todos los documentos generados dentro del proyecto. Se va a llevar la ejecución,
monitoreo, control y el cierre del proyecto al igual que la apertura por medio de la carta de
constitución del proyecto.
Se manejan entradas y las salidas van a ser para el plan para la dirección de proyectos,
también hay técnicas y herramientas que nos van a ayudar para hacer el documento del plan
para la dirección de proyectos

ALCANCE DEL PROYECTO

GESTIÓN DEL ALCANCE DEL PROYECTO

Es muy importante que uno pueda describir de una manera profesional todo lo que se va a hacer
dentro del proyecto, debe de participar el patrocinador, los interesados, los usuarios, los expertos,
los dueños de los procesos y el equipo de proyecto.
Para definir este alcance primero se debe de definir el alcance del producto (si no se define el
alcance del producto, no se puede definir el alcance del proyecto).
El alcance del producto lo vamos a hacer a través del DERCAS.
“tenemos el DERCAS, definimos el alcance del producto y luego hacemos el alcance del proyecto”

Siguientes procesos:
Iniciación, planificación, ejecución, seguimiento y control; y cierre.
El recopilar los requisitos es el DERCAS

PLANIFICAR LA GESTIÓN DEL ALCANCE

Se tiene que definir que es lo que se va a incluir en el alcance.
Con el objetivo de desarrollar el plan de gestión del alcance, y definir el alcance del proyecto, se
recomienda al director del proyecto y su equipo comience con el análisis de la información
contenida en el acta de constitución del proyecto. (Esto reduce el riesgo del alcance oculto (Scope
Creep) del proyecto).

Plan para la dirección del proyecto es el documento donde se va a meter el DECAS, Carta
Constitutiva del Proyecto, Alcance, EDT, Cronograma, Costos, Calidad, Compras,
Comunicaciones (todos los documentos relacionados al proyecto deben de ir aquí)
RECOPILAR REQUISITOS
Este es el DERCAS para nosotros los ingenieros en sistemas.

DEFINICIÓN DEL ALCANCE

Es critico que esto se haga bien, porque si no esta bien el resto del proyecto es un desastre, no sirve.

Con el alcance ya definido se va a crear la EDT

CREAR LA EDT (estructura de desglose de trabajo)

Es una descomposición jerárquica orientada al producto entregable del trabajo que será ejecutado
por el equipo del proyecto para lograr los objetivos del mismo y crear los productos entregables
requeridos.
Es decir que la EDT va a servir de mucha ayuda para saber cuales son los entregables.
Definición: La EDT organiza y define el alcance total del proyecto

En la planeación de proyectos, el director debe estructurar el trabajo en pequeños elementos que

sean:
1. Administrable. Donde la autoridad y responsabilidad especifica pueda ser asignada.
2. Independiente. Con una interface y dependencia mínima de otros elementos en curso.
3. Integrable. Con una visión global del alcance.
4. Medible. En términos de progreso.

DESCOMPOSICIÓN DE LA EDT
Se manejan 4 niveles que son: (todos son entregables)
1. Se define la meta o el objetivo general.
2. Los objetivos específicos
3. Cuentas de Control
4. Paquetes de trabajo.
 5. Actividades (Cronograma)
Diferencia es que las actividades llevan verbo Infinitivo.

CRITERIOS PARA DESARROLLAR UNA EDT

TIEMPO DEL PROYECTO

PLANIFICAR LA GESTIÓN DEL CRONOGRAMA

En base con lo que se construye la EDT con eso se va a listar las actividades
Significa que se debe de hacer una serie de actividades para cumplir con el entregable

Se descompone las cuentas de control o paquetes de trabajo en actividades (son acciones y llevan
verbos infinitivos)
PLANIFICACIÓN
La planificación se puede dividr el problema en partes y volverlo a integrar o haerlo con el equipo
en reuniones y dividirlo entre los integrantes. No realizarlo en horas sino en días y tener plantilla
con asuetos para tener que días realmente son laborales.
PARTES DEL EDT:
• META
• OBJETIVOS
• CUENTAS DE CONTROL (son entregables o sea hacer una serie de actividades para
cumplir)
• PAQUETES DE TRABAJO (son entregables o sea hacer una serie de actividades para
cumplir), se puede descomponer en actividades, estas se escriben en verbo infinitivo.
HITOS: Pueden ser reuniones, actividades, pagos, aspectos importantes del proyecto.
Después de definir las actividades, se debe realizar la secuencia lógica de las mismas.
SECUENCIAR LAS ACTIVIDADES (se incluyen los hitos)

SECUENCIAR LAS ACTIVIDADES (HERRAMIENTAS Y TÉCNICAS)

Método de diagramación por precedencia (PDM)
RUTA CRÍTICA: Es la ruta más larga del proyecto.
Se llama crítica porque si uno se atrasa un día en la ruta más larga del proyecto, se atrasa el
proyecto. Esta da la fecha de inicio y fecha de fin del proyecto.
Nota: un proyecto debe tener una fecha de inicio y fecha de fin porque si no este no es un proyecto.
Relaciones de Precedencia

Final a inicio es el más común que se usa en los cronogramas de actividades, B no puede
iniciar hasta que A termine.
ESTIMAR LOS RECURSOS DE LAS ACTIVIDADES
Al Hablar de Estimar los recursos de las actividades en primer lugar hablamos de personas.

Cuando se hacen las alternativas se puede analizar que opciones tengo si no se tiene lo que
inicialmente se pidió. por ejemplo, necesito un servidor on premise y no me lo dan a tiempo
entonces lo puedo alquilar en la nube.
Un proyecto se puede medir por funcionalidad, es decir si el proyecto funciona y lo usan los
usuarios finales es un éxito.
ESTIMAR LA DURACIÓN DE LAS ACTIVIDADES
Estimación Por 3 Valores es el Más Usado

No abusar en el análisis de reserva

DESARROLLAR EL CRONOGRAMA

Método de la Ruta Crítica

1. Fecha de Inicio Temprana (ES)
2. Fecha de Inicio Tardía (LS)
3. Fecha de Finalización Temprana (EF)
4. Fecha de Finalización Tardía (LF)
 DIRECCIÓN DE PROYECTO PMI
COSTOS DEL PROYECTO

Costos Fijos: son todos aquellos costos que van relacionados al proyecto, que como su nombre
lo indica siempre van. (ejemplo: los sueldos).
Costos Variables: Son todos aquellos que no necesariamente deben estar siempre en los
proyectos y pueden variar según el proyecto. (ejemplo: el consumo de energía eléctrica, agua,
servidores de la nube)
Costos Directos: Son todos aquellos costos asociados de forma directa a la elaboración del
proyecto.
Costos Indirectos: Son todos los costos que no están asociados directamente a la elaboración de
las tareas del proyecto, pero sin embargo, si influyen para que el proyecto se pueda llevar a cabo
con éxito.
Depreciación acelerada: Esta se usa en los equipos de tecnología.
Estimación análoga: es una técnica para calcular los costos que no es la mejor, pero es una técnica.
¿Cuáles son las formas para estimar los costos?
- Estimación Paramétrica.
- Estimación Ascendente.
- Estimación Definitiva
Valor presente neto (Net Present Value), Tasa interna de retorno (Internal Rate Of Return IRR) y
periodo de recuperación de pago (Payback Period), son indicadores que los patrocinadores
necesitan saber para ver cuándo van a tener en retorno el dinero.
Costo de Oportunidad (Oportunity Cost): Es el costo de que si uno no hace el proyecto que
pasaría.
Costo hundido (Sunk Cost): Son costos que no tenemos presupuestados (por ejemplo: se arruinó
la cañería de un balo y esa fuga de agua arruino equipos y se tuvo que pagar para reparar).
“SIEMPRE SE DEBEN DE EXPONER LOS RIEGOS DEL PROYECTO”

EJEMPLO DE PLANIFICAR LA GESTIÓN DE COSTOS

Los Costos se pueden ahorrar, por ejemplo, en vez de utilizar servidores se puede utilizar
computadoras vitaminadas corei7, 32gb RAM y discos de estado sólido que no es lo mismo
que un servidor, pero es funcional. Se compra computadoras clones sin licencia de Windows
y se le instala Ubuntu, Oracle Linux, Linux light y un software basado en java con BD 18C
Express Edition que es gratuita y funciona bien en Linux. Las computadoras de usuario no
tendrán estado sólido. Se usa un top cad y glashfish, se usa el open java, usando todas las
opciones open source. Se colocó hipervisor proxmox se montan servidor de Oracle Linux BD,
Storash, Aplication Server y manejo de archivos todos basados en Linux.
CENTOS –SERVER – Oracle Linux SE CONTRATO UN CONSULTOR DE OPEN
SOURCE
Ya se había definido:
• Servidores de base de datos
• Lenguaje de programación
• Aplication Server
• Base de datos
• Computadoras de usuarios
• Routers
• Cableado estructurado
• Switches
Ya logró planificar que va a comprar y en base a eso se sabe cuánto se gastará y con eso se
puede realizar el plan. Para presentar presupuesto al patrocinador.
PLANIFICACIÓN:

INDICADORES PARA PLANIFICCAR LA GESTIÓN DE LOS COSTOS

ESTIMAR LOS COSTOS

En Net Server se encuentra el Open Project: Es un server donde todo el mundo sube sus
proyectos, agrupan sus programas y ahí se crean los portafolios de proyectos.
Análisis de Ofertas de Proveedores: Son las dichosas Cotizaciones.
ESTIMAR LOS COSTOS
Va a significar que nosotros calculemos con base al costo mas probable optimista y pesimista, cual
es el costo esperado que se va a tener de cada actividad o de las cosas que se tengan que comprar
en el proyecto.

En los costos no se puede referir con costos de proyectos anteriores ya que pueden variar mucho.
CALCULAR LA ESTIMACIÓN DE LOS COSTOS: HERRAMIENTAS Y TÉCNICAS

CO= Costo Optimista, CM= Costo Más Probable, CP= Costo Pesimista

ANÁLISIS DE RESERVA

Estimación de costos y presupuesto no es lo mismo.

Estimación de costos hacemos los análisis del CO, CM, CP y en el presupuesto colocamos los
análisis de reserva.
DETERMINAR EL PRESUPUESTO (Herramientas y Técnicas)

• Agregación de costos son la suma de los costos

• Análisis de reservas se debe tener mucho cuidado como se va a manejar los colchones de
dinero, y sólo a las actividades que son críticas.
• Juicio de experto siempre se necesita
• Relaciones Históricas, siempre se debe consultar proyectos anteriores o previos.
• Conciliación del límite de financiamiento, puede suceder que una parte lo coloque la
empresa, pero la otra parte lo dará el banco, donde se debe presentar el plan de costos para
mostrar en que fecha y que monto debe pagar y el banco lo hace, pero no da el dinero a la
empresa ni al patrocinador.

Cuenta de control, constituye la línea Base de los costos

CONTROLAR LOS COSTOS: HERRAMIENTAS Y TECNICAS

Gestión del valor ganado (EVM): es la que dará certeza si con el alcance y tiempo que se definió,
se están gastando costos que se establecieron, manteniendo la calidad del proyecto que se había
acordado.
DIMENSIONES SON (INDICADORES)
Estos son los indicadores que se pueden estar manejando para controlar los costos del
proyecto

PV: que es lo que planifique (es la medida del trabajo realizado en términos de presupuesto
autorizado)
EV: si lo estoy haciendo como dije que se iba a hacer (Es lo que uno pago)
AC: cuanto realmente se gasto

SV: se puede calcular si uno va adelantado, atrasado o en tiempo.

CV: si voy arriba, abajo o con los costos que corresponde.
RESUMEN DE LOS CALCULOS