Tabla de contenidos

1. Introducción ..............................................................................................................4
2. Subtemas .................................................................................................................5
3.1 APLICACION DE HERRAMIENTAS PARA ESTIMACION DE TIEMPOS Y
COSTOS DE DESARROLLO. ..................................................................................6
3.2. Ámbito del software ..........................................................................................22
3.3 Métricas orientadas al tamaño, al esfuerzo y a los costos. ............................31
3.4 Análisis y gestión del riesgo: estrategias, identificación, proyección,
refinamiento, reducción, supervisión y gestión del riesgo. ..............................40
3.5 Conclusiones: .....................................................................................................50
3.6 Herramientas y recursos utilizados ..................................................................51
4. Bibliografía:...........................................................................................................52

1
 Introducción
La planeación debe realizarse antes de dar el salto e iniciar el proyecto, para ello el
equipo del proyecto o contratista debe tomarse el tiempo suficiente para planear
adecuadamente. El plan de trabajo debe mostrar cómo se completará el proyecto dentro
del presupuesto y el tiempo previsto. Tratar de realizar un proyecto sin un plan es como
tratar de armar un asador para jardín sin leer las instrucciones.

Las personas que piensan que la planeación es innecesaria o que representa una
pérdida de tiempo, invariablemente necesitarán encontrar tiempo para rehacer las cosas
más adelante. Es importante planear el trabajo y después trabajar el plan, de lo contrario,
habrá caos y frustración, y el riesgo de que el proyecto fracase será mayor. Una vez que
un proyecto esté autorizado y/o se firme un contrato con un contratista externo, la
siguiente fase del ciclo de vida del proyecto es hacer una planeación detallada de cómo
realizarlo.

La planeación consiste en determinar qué se debe hacer (alcance, entregables), cómo

se hará (actividades, secuencia), quién lo va a hacer (recursos, responsabilidad), cuánto
tiempo tomará hacerlo (duración, programa), cuánto dinero costará (presupuesto), y
cuáles son los riesgos. El resultado de este esfuerzo es un plan inicial, es decir, un plan
de acción según los requerimientos y las limitaciones estipulados en la cédula del
proyecto o contrato. Este plan también se utilizará como punto de referencia para
comparar el avance real. Tomarse el tiempo para desarrollar un plan bien elaborado es
fundamental para el logro exitoso de cualquier proyecto. Muchos proyectos han rebasado
sus presupuestos, incumplido con sus fechas de terminación o satisfecho sólo
parcialmente sus especificaciones técnicas porque no se implementó un plan inicial
viable antes de comenzar. Es importante que las personas que participen en la ejecución
del proyecto también se involucren en la planeación del trabajo, pues por lo general son
quienes están mejor informadas acerca de las actividades detalladas que se deben
realizar. Además, al participar en la planeación del trabajo estas personas se
comprometen a realizarlo con base en el plan. La participación genera compromiso.

2
La planeación efectiva de un proyecto de software comprende lo siguiente: desarrollar
un plan para la dirección del proyecto, recopilar los requerimientos, definir el alcance del
proyecto, crear la estructura de desglose del trabajo, definir las actividades y darles una
secuencia, hacer una estimación de los recursos necesarios para llevar a cabo las
actividades del proyecto y una estimación de la duración de cada actividad, desarrollar
un cronograma, estimar los costos del proyecto, determinar el presupuesto, planificar la
calidad, los recursos humanos, las comunicaciones, la gestión de riesgos y las
adquisiciones.

La primera actividad en la administración del proyecto de software es determinar el

ámbito del software, que se define al responder las siguientes preguntas: Contexto.
¿Cómo encaja en un sistema, producto o contexto empresarial más grande el software
que se va a construir y qué restricciones se imponen como resultado del contexto?
Objetivos de información. ¿Qué objetos de datos visibles para el cliente se producen
como salida del software? ¿Qué objetos de datos se requieren como entrada? Función
y desempeño. ¿Qué función realiza el software para transformar los datos de entrada en
salida? ¿Existe alguna característica de desempeño especial que deba abordarse? Si no
puede acotar una característica del software que intenta construir, mencione la
característica como un riesgo del proyecto. El ámbito del proyecto de software no debe
tener ambigüedades ni ser incomprensible en los niveles administrativo y técnico. Debe
acotar un enunciado del ámbito del software; es decir, los datos cuantitativos (por
ejemplo, número de usuarios simultáneos, entorno objetivo, máximo tiempo de respuesta
permisible) se enuncian de manera explícita, se anotan las restricciones y/o limitaciones
(por ejemplo, el costo del producto restringe el tamaño de la memoria) y se describen los
factores mitigantes (por ejemplo, los algoritmos están bien entendidos y disponibles en
el lenguaje de programación que se va a emplear).

Subtemas
• 3.1. Aplicación de herramientas para estimación de tiempos y costos de desarrollo
de software: GANTT, PERT/CPM, uso de software para la estimación de tiempos
y costos.

3
 • 3.2. Ámbito del software: recursos humanos, recursos de software reutilizables,
recursos del entorno.

• 3.3. Métricas orientadas al tamaño, al esfuerzo y a los costos.

• 3.4. Análisis y gestión del riesgo: estrategias, identificación, proyección,

refinamiento, reducción, supervisión y gestión del riesgo.

3.1 APLICACION DE HERRAMIENTAS PARA ESTIMACION DE TIEMPOS Y COSTOS

DE DESARROLLO.

El objetivo de la Planificación del proyecto de Software es proporcionar un marco de

trabajo que permita al gestor de planificación hacer estimaciones razonables de recursos,
costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de
tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse
regularmente a medida que progresa el proyecto. Además, las estimaciones deberían
definir los escenarios del mejor caso, y peor caso, de modo que los resultados del
proyecto pueden limitarse. El Objetivo de la planificación se logra mediante un proceso
de descubrimiento de la información que lleve a estimaciones razonables.

La calendarización de un proyecto de software no difiere enormemente de la de cualquier

esfuerzo de ingeniería multitarea. Por tanto, las herramientas y técnicas generalizadas
de calendarización de proyecto pueden aplicarse con pocas modificaciones para
proyectos de software. La evaluación del programa y la técnica de revisión (PERT, por
sus siglas en inglés) y el método de ruta crítica (CPM, por sus siglas en inglés) son dos
métodos de calendarización de proyecto que pueden aplicarse en el desarrollo de
software. Ambas técnicas se impulsan mediante información ya desarrollada en
actividades de planificación de proyectos anteriores: estimaciones de esfuerzo, una
descomposición de la función del producto, la selección del modelo de proceso y el
conjunto de tareas adecuadas, así como la descomposición de las tareas que se
seleccionan. Las interdependencias entre tareas pueden definirse usando una red de
tareas. Las tareas, en ocasiones llamadas estructura de distribución del trabajo del

4
proyecto (EDT), se definen para el producto como un todo o para funciones individuales.
Tanto la PERT como el CPM proporcionan herramientas cuantitativas que permiten:

1) Determinar la ruta crítica (la cadena de tareas que determina la duración del proyecto).
2) establecer estimaciones de tiempo “más probables” para tareas individuales aplicando
modelos estadísticos.
3) calcular “tiempos frontera” que definen una “ventana” de tiempo para una tarea
particular.

CPM Y PERT El método de la ruta crítica (CPM, por sus siglas en inglés) y la técnica de
evaluación y revisión de programas (PERT, por sus siglas en inglés) son métodos
basados en redes diseñados para ayudar a planificar, programar y controlar proyectos.
Un proyecto se define como un conjunto de actividades interrelacionadas donde cada
actividad consume tiempo y recursos. El objetivo de CPM y PERT es idear herramientas
analíticas para programar las actividades. Primero definimos las actividades del proyecto,
sus relaciones de precedencia y sus requerimientos de tiempo. Luego se modelan las
relaciones de precedencia entre las actividades como una red. El tercer paso implica
cálculos específicos para desarrollar el cronograma. Durante la fase de ejecución real,
es posible que la ejecución de las actividades no discurra como se planeó, en el sentido
de que algunas de las actividades pueden ser despachadas o demoradas. Las dos
técnicas, CPM y PERT, se desarrollaron de forma independiente. Difieren en que CPM
asume duraciones de actividad determinísticas y PERT supone duraciones
probabilísticas.

Los cronogramas de barras o “gráficos de Gantt” fueron concebidos por el ingeniero

norteamericano Henry L. Gantt, uno de los precursores de la ingeniería industrial
contemporánea de Taylor. Gantt procuro resolver el problema de la programación de
actividades, es decir, su distribución conforme a un calendario, de manera tal que se
pudiese visualizar el periodo de duración de cada actividad, sus fechas de iniciación y
terminación e igualmente el tiempo total requerido para la ejecución de un trabajo.

5
El instrumento que desarrolló permite también que se siga el curso de cada actividad, al
proporcionar información del porcentaje ejecutado de cada una de ellas, así como el
grado de adelanto o atraso con respecto al plazo previsto.

Diagramas de Gantt

La historia de los diagramas de Gantt

La primera versión de un diagrama de Gantt fue inventada por Karol Adamiecki, quien
inventó lo que llamamos armonograma en 1896. Adamiecki publicó sus hallazgos en ruso
y polaco, lo que dificultó el acceso en los países de habla inglesa. En 1910, Henry Gantt
popularizó, por su parte, un gráfico similar en los Estados Unidos, que elaboró con el
objetivo de representar cuánto tiempo dedicaban los obreros de una fábrica a trabajar en
una tarea específica. Desde entonces, estos dos sistemas se han combinado para crear
lo que hoy conocemos en la era moderna como el diagrama de Gantt.

Todo comenzó con el seguimiento de las tareas de los obreros en las fábricas, pero más
adelante, los diagramas de Gantt se transformaron en una forma muy difundida de dar
seguimiento a los cronogramas de los proyectos. Originalmente, los diagramas de Gantt
se hacían en papel, entonces, si las fechas cambiaban había que volver a dibujarlos.
Más adelante, los gerentes de proyectos empezaron a usar hojas enteras o cuadernos
para representar las barras del diagrama de Gantt y así poder moverlas según lo
necesitaran.

Karol Adamiecki

6
 Henry Gantt

Entonces, ¿qué es un diagrama de Gantt?

Son muy comunes en la gestión de proyectos. Un diagrama de Gantt es un gráfico de
barras horizontales que se usa para ilustrar el cronograma de un proyecto, programa o
trabajo. Es una forma de ver la programación de tu proyecto, de dar seguimiento a los
logros y de estar siempre familiarizado con el cronograma de tu trabajo. Cada barra de
un diagrama de Gantt representa una etapa del proceso (o una tarea del proyecto) y su
longitud, la cantidad de tiempo que demandará llevar a cabo esa etapa o finalizar la tarea.
Cuando los miras en perspectiva, los diagramas de Gantt ofrecen a los equipos un
panorama general acerca de cuál es el trabajo que hay que hacer, quién lo hace y
cuándo.

7
El diagrama de Gantt permite:
• Que se siga el curso de cada actividad, al proporcionar información del porcentaje
ejecutado de cada una de ellas
• El grado de adelanto o atraso con respecto al plazo previsto.

Funciones clave de los diagramas de Gantt en la era moderna

Hoy en día, los diagramas de Gantt se usan con software inteligente y en línea, lo que
favorece la detección de dependencias y el trabajo de programación en el tiempo;
además, permiten mantener a los proyectos bajo control. A continuación, se encuentran
algunas funciones clave de los diagramas de Gantt modernos:

Visualizan el progreso de los proyectos en tiempo real

La mayoría de los diagramas de Gantt actuales son herramientas de software para
gestión en la nube que sirven para que los equipos planifiquen proyectos de todo tipo de
tamaño. A diferencia de los diagramas de Gantt originales que se dibujaban en papel,
los diagramas de Gantt en línea permiten que los equipos tengan el control de la
planificación de sus proyectos y que puedan hacer ajustes fácilmente cuando lo
necesitan. Cuando cambias una fecha o trasladas un Logro, el diagrama de Gantt
debería reflejar automáticamente esas modificaciones, para que puedas estar al día con
respecto a las novedades del proyecto. Así, se facilita la colaboración entre los equipos
y se lleva a cabo un excelente trabajo.

Fechas de inicio y fin

Los diagramas de Gantt son ideales para observar proyectos complejos con muchas
tareas. Cada "barra" horizontal del diagrama de Gantt representa una tarea en particular.
De este modo, los equipos pueden contar con una idea clara de qué tareas se llevan a
cabo, cuándo y cuánto tiempo demandará realizarlas.

Dependencias de las tareas

Además de la posibilidad de ver las fechas de inicio y fin individuales de cada tarea en
un diagrama de Gantt, estos gráficos visuales facilitan la trazabilidad entre las
dependencias de las tareas. Con el software que uses para los diagramas de Gantt,
deberías poder trazar las dependencias de las tareas. Gracias a las dependencias, los

8
miembros de los equipos pueden identificar fácilmente quién está esperando que termine
el trabajo para poder empezar. Y, si por algún motivo necesitas posponer un trabajo,
puedes identificar los posibles problemas y hacer las modificaciones necesarias para
evitar conflictos de dependencias antes de empezar.

Logros
Los logros son una función clave de los proyectos con diagramas de Gantt. A diferencia
de la mayoría de las tareas en un diagrama de Gantt, que aparecerán como barras
horizontales que se extienden a lo largo de un período, los logros son puntos destacados
en el tiempo. En un diagrama de Gantt, los logros representan puntos de control y
momentos importantes en el cronograma del proyecto. También permiten apreciar de un
solo vistazo todas las fechas clave del proyecto.

5 pasos para crear un excelente diagrama de Gantt

Los mejores diagramas de Gantt sirven para dar seguimiento a la programación de tu
proyecto con un gráfico de barras, para ver exactamente el cronograma y el progreso.
Asegúrate de que el software con el que usas tus diagramas de Gantt ofrezca alguna
forma en que queden claras las dependencias entre las tareas y con la que se puedan
identificar los logros de los proyectos.

1. Define el período
2. Agrega tareas con fechas de inicio y fin
3. Aclara las dependencias
4. Identifica los logros
5. Modifica el trabajo a medida que cambian los planes

Desventajas de usar un diagrama de Gantt

Los diagramas de Gantt tienen sus imperfecciones. A continuación, se encuentran
algunas trabas que las personas enfrentan con frecuencia:

Prepararlos puede demandar mucho tiempo

Preparar un diagrama de Gantt no es instantáneo. En particular, si usas una hoja de
cálculo, te podría llevar bastante tiempo plasmar tu trabajo en la vista de un diagrama de

9
Gantt. Incluso si usas una plantilla, probablemente aún tengas que hacerle ajustes para
personalizarla según las necesidades específicas de tu equipo.

No es fácil gestionar un proyecto en el mismo lugar en el que lo planificaste

Los diagramas de Gantt tradicionales son muy útiles para la fase de planificación de un
proyecto. Una vez que hayas trazado el esquema de tu trabajo, con frecuencia cambiarás
a una herramienta o plataforma diferente para gestionar las actividades diarias y será
difícil saber cuál es el verdadero punto de referencia de tu equipo.

Al agregar más detalles se complica

Independientemente de que hablemos de micro pasos para un logro, archivos o una
explicación de lo que quisiste decir con "Activar la campaña de recaptación", agregar
esos detalles útiles al plan de tu proyecto en un diagrama de Gantt puede hacer que un
trazado fácil de mirar se transforme en una abrumadora y caótica hoja.

CPM/PERT
Los métodos CPM/PERT utilizan la representación en forma de red Cada actividad está
representada por un arco que apunta en la dirección del avance del proyecto.

Los nodos de la red establecen las relaciones de precedencia entre las diferentes
actividades. Se dispone de tres reglas para construir la red.

Regla 1. Cada actividad está representada por uno, y sólo un arco.

Regla 2. Cada actividad debe estar identificada por dos nodos terminales distintos.

Ejemplo: Dadas las siguientes actividades

10
Se puede transformar a un diagrama de red, queda así

CPM (Critical Path Method)

CPM permite

1. Determinar la ruta crítica (la cadena de tareas que determina la duración del
proyecto)

2. Calcular “tiempos frontera” que definen una “ventana” de tiempo para una tarea
particular.

11
Cálculos del método de la ruta crítica (CPM) El resultado final en el CPM es un
cronograma para el proyecto Para lograr este objetivo se realizan cálculos especiales
para obtener la siguiente información:

1. Duración total necesaria para completar el proyecto.

2. Clasificación de las actividades del proyecto como críticas o no críticas.

Una actividad es crítica si sus tiempos de inicio y terminación están predeterminados

(fijos). Una actividad es no crítica si puede ser programada en un espacio de tiempo
mayor que su duración, lo que permite tiempos de inicio y terminación flexibles (dentro
de los límites). Una demora en el tiempo de inicio de una actividad crítica definitivamente
retrasa la terminación del proyecto, en tanto que una demora en una actividad no crítica
quizá no afecte la fecha de terminación del proyecto.

Para realizar los cálculos necesarios, definimos un evento como un punto en el tiempo
en el cual se completan las actividades y se inician las subsiguientes. En función de la
red, un evento corresponde a un nodo. Sean

= Tiempo de ocurrencia más temprano del evento j

= Tiempo de ocurrencia más tardío del evento j

Dij = Duración de la actividad (i,j)

Los cálculos de la ruta crítica implican dos pasos: El paso adelantado determina los
tiempos de ocurrencia más tempranos de los eventos y el paso retrasado calcula sus
tiempos de ocurrencia más tardíos.

Paso adelantado (tiempos de ocurrencia más tempranos, ). Los cálculos se inician

en el nodo 1 y avanzan recursivamente hacia el nodo n.

Paso retrasado (tiempos de ocurrencia más tardíos, ). Los cálculos del paso
retrasado se inician en el nodo n y terminan en el nodo 1.

12
1. Las actividades críticas (mostradas por las líneas sólidas) están escalonadas una justo
después de la otra para garantizar que el proyecto se complete dentro de la duración
especificada.

2. Las actividades no críticas (mostradas por las líneas de rayas) tienen lapsos de tiempo
permisibles mayores que sus respectivas duraciones, lo que permite una holgura (o
“margen”) al programarlas dentro de sus intervalos de tiempo asignados.

PERT
PERT permite

1. Determinar la ruta crítica (la cadena de tareas que determina la duración del
proyecto)

2. Establecer estimaciones de tiempo “más probables” para tareas individuales

aplicando modelos estadísticos

3. Calcular “tiempos frontera” que definen una “ventana” de tiempo para una tarea
particular.

13
Redes PERT
PERT difiere de CPM en que asume tiempos de duración probabilísticos basados en tres
estimaciones:

1. Tiempo optimista, a, el cual ocurre cuando la ejecución transcurre extremadamente

bien.

2. Tiempo más probable, m, el cual ocurre cuando la ejecución se realiza en condiciones

normales.

3. Tiempo pesimista, b, el cual ocurre cuando la ejecución transcurre extremadamente

deficiente.

El tiempo más probable, m, queda en el intervalo (a, b).

Formulas para calcular tiempo esperado, varianza, desviación necesarios

14
 σ = √𝑣

Por último, la duración promedio del proyecto (TE) es la suma de todos los tiempos
promedio de actividad en la ruta crítica (suma de D) y sigue una distribución normal.

Si se conocen la duración promedio del proyecto y las varianzas de las actividades, se

tiene la probabilidad de terminar el proyecto (o un segmento) en un tiempo específico
que se calcula con tablas estadísticas estándar.

Donde
TE = duración de la ruta crítica

TS = duración programada del proyecto

Z = probabilidad (de cumplir la duración programada) que se encuentra en la tabla

estadística

15
Ejemplo
Dados los datos

Se representa de la siguiente manera

16
Por ejemplo, ¿cuál es la probabilidad de que el proyecto se termine antes de un tiempo
programado (TS) de 67?

¿Cuál es la probabilidad de que el proyecto se termine antes de un tiempo programado

(TS) de 60?

URL de tabla de distribución normal

http://dsp.facmed.unam.mx/wp-content/uploads/2013/12/Quevedo-F.-Distribucion-
normal.-Medwave-2011-May-1105.pdf

http://estadisticasoctys.freetzi.com/Estadistica2/Estadisticainferencial/TABLAS.pdf

17
 DESCARGA de OPEN WORKBENCH
https://ccm.net/download/download-1357-open-workbench
Java runtime environment
https://java.com/en/download/

Descarga de WBS Chart Pro

https://ccm.net/download/download-1357-open-workbench

Software para estimación de costos

18
 Problemas de PERT
https://ocw.unican.es/pluginfile.php/274/course/section/196/PERT%20clase.pdf

19
3.2. Ámbito del software

Determinar el ámbito del software será la primera actividad que deberá realizarse en la
planificación del proyecto, y se llevará a cabo evaluando las funciones y el rendimiento
asignados a este en la ingeniería del sistema de la computadora. Si estas
especificaciones no estuvieran descritas en las especificaciones del sistema, serán tarea
del planificador del proyecto.

El ámbito del software deberá de estar bien delimitado, indicando datos concretos como
el número de usuarios simultáneos, el tiempo máximo de respuesta, etc. Deberá
especificar las limitaciones de que dispondrá en cuanto a, el tamaño máximo de
memoria, y deberán especificarse los factores de atenuación indicando las facilidades de
las que se van a disponer como por ejemplo algoritmos ya desarrollados, etc. Se deberán
describir cinco aspectos como:

20
La función, el rendimiento y las restricciones, tres aspectos íntimamente relacionados, y
las interfaces y la fiabilidad.

-La función, se revisará y se concretaran las descritas en la ingeniería del sistema.

-Rendimiento, se concretarán las necesidades en cuanto a tiempos de respuesta y

procesamiento.

-Las restricciones, se concretarán las limitaciones hardware con que se encontrara el

software.

-Las interfaces, se deberá identificar claramente la información que se comunicara,

además de los elementos externos que tomarán parte en esta comunicación, tanto

21
dispositivos hardware, como elementos software con los que se deberán crear enlaces,
así como personal humano que hará uso de él.

-La fiabilidad, se establecerá el nivel de seguridad que deberá tener el proyecto

dependiendo de su naturaleza. No tendrá el mismo nivel de seguridad un procesador de
texto que una aplicación que controle el tráfico aéreo, para así poder estimar el esfuerzo
y el coste que harán de este un proyecto fiable, pero no se establecerán medidas de
fiabilidad del software en este momento.

Recursos
La estimación de recursos necesarios para el desarrollo del proyecto es la segunda
actividad a realizar, en ella se concentrarán los recursos hardware, software y humanos
que se necesitarán, indicando cuando y durante cuánto tiempo, además de los requisitos
que estos deberán cumplir.

-Recursos humanos: Los recursos humanos que se van a necesitar para el proyecto, se
indicarán las características que deberán cumplir entre las que se incluirán su
especialidad y puesto en la empresa; se deberá indicar también su disponibilidad y a
duración que tendrá su tarea, además de la fecha en la que deberá comenzar. Sin
embargo, el número total de personas que se necesitaran solo se podrá determinar

22
cuando este calculado el esfuerzo que requiera el proyecto.

-Recursos de Hardware: Los recursos hardware que se utilizaran para el desarrollo del
proyecto conformaran lo que se conoce como el sistema anfitrión, y lo formara la maquina
donde se desarrolle el software junto con sus periféricos, también se observar los casos
en los que para la fase de pruebas se necesite hardware adicional, que será la máquina
para la que se está diseñando el software. De cada uno de estos elementos necesarios
se deberá especificar su disponibilidad, la duración de su uso y la fecha de distribución.

23
-Recursos Software: Al igual que ocurre con las herramientas hardware, el planificador
del proyecto puede hacer uso de herramientas software especialmente diseñadas para
el desarrollo de software; a este tipo de herramientas se les denomina herramientas
CASE (Ingeniería del Software Asistida por Ordenador), a continuación, se nombrarán
algunas:

-De planificación de sistemas.

-De gestión de proyectos.
-De soporte.
-De análisis y diseño.
-De programación.
-De prueba e integración.
-De simulación y creación de proyectos.
-De mantenimiento.
-De estructura.

También es importante que se establezcan en este momento la conveniencia de utilizar

software ya desarrollado que habrá que adquirir y en algunos casos modificar si no se
adapta perfectamente a las necesidades.

DevOps
Es un conjunto de practicas que combina el desarrollo de software(Dev) y las
operaciones TI(Ops) con el objetivo es acortar el ciclo de vida del desarrollo de sistemas
y proporcionar una entrega continua con alta calidad de software.

DevOps describe los enfoques para agilizar los procesos con los que una idea (como
una nueva función de software, una solicitud de mejora o una corrección de errores) pasa
del desarrollo a la implementación, en un entorno de producción en que puede generar
valor para el usuario.

CONCEPTOS LIGADOS A DEVOPS

24
DESARROLLO AGIL

•Se Basa en el Desarrollos cortos con objetivos entregable especificos

•El producto(software)evlociona conforme los ciclos avanzan

•Los grupos de trabajo son multidiciplinarios y por lo general autogestionados

LO QUE NOS DA DEVOPS

•Autoservicio.

•Autogestión.

•Integración continua.

•Colaboración.

25
CADENA DEVOPS

COMPONENTES DE UN DESARROLLO AGIL DE UN PRODUCTO DE SOFTWARE

•Control de versiones

•Gestion de entornos

•Automatizacion

•Pruebas y QA

26
•Integracion

Comunicación

GESTION DE ENTORNOS

•Heroku

•Openshift

•Docker

•Dokku

•Elastic Beanstalk

Google Cloud App Enginer

HERRAMIENTAS DE SOFTWARE

•Github

•Git

Gitlap

AUTOMATIZACION

•Chef

•Puppet

Terraform

PREUBAS, ASEGURAMIENTO DE CALIDAD DE INTEGRACION

¿Que probamos y validamos?

•Código(unitarias)

27
•Integración

•funcionalidad

HERRAMIENTAS SP

•JENKINS

•Travis Ci

28
3.3 Métricas orientadas al tamaño, al esfuerzo y a los costos.

Las métricas del software orientadas a la función utilizan una medida de la funcionalidad
entregada por la aplicación como un valor de normalización. Ya que la
«funcionalidad>>no se puede medir directamente, se debe derivar indirectamente
mediante otras medidas directas.

Las métricas orientadas a la función fueron propuestas por primera vez por Albretch,
quien sugirió una medida llamada punto defunción.

Los puntos de función se derivan con una relación empírica según las medidas contables
(directas) del dominio de información del software y las evaluaciones de la complejidad
del software.

Número de entradas de usuario. Se cuenta cada entrada de usuario que proporciona

diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las
peticiones, las cuales se cuentan de forma separada.

Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario

información orientada a la aplicación. En este contexto la salida se refiere a informes,
pantallas, mensajes de error, etc.

Número de peticiones de usuario. Una petición se define como una entrada interactiva
que produce la generación de alguna respuesta del software inmediata en forma de
salida interactiva.

Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de
datos que puede ser una parte de una gran base de datos o un archivo independiente).

Número de interfaces externas. Se cuentan todas las interfaces legibles por la máquina
(por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir
información a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de
complejidad. Para calcular puntos de función (PF), se utiliza la (4.5) relación siguiente:

29
Metrica Orientada al Tamaño

(COCOMO: Modelo contructivo de costes)

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive

COst MOdel) es un modelo matemático de base empírica utilizado para estimación de
costes[1] de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y
aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del
software: básico, intermedio y detallado.

Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos
de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics"
(Prentice-Hall, 1981).

30
•El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive
COst MOdel) es un modelo matemático de base empírica utilizado para estimación de
costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y
aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del
software: básico, intermedio y detallado.

CARACTERISTICAS

•Pertenece a la categoría de modelos de subestimaciones basados en estimaciones

matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto,
en líneas de código principalmente.

31
INCONVENIENTES

•Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los
recursos necesarios para realizarlas.

•Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el

código fuente.

•Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser
"vistos" de distinta manera por distintos analistas que usen el método.

32
•Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la
productividad.

•La medición por líneas de código no es válida para orientación a objetos.

•Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos
(que también sólo estiman).

MODELOS DE ESTIMACION

•La función básica que utilizan los tres modelos es:

E = a(Kl)b * m(X) donde:

•a y b son constantes con valores definidos en cada submodelo

•Kl es la cantidad de líneas de código, en miles.

•m(X) Es un multiplicador que depende de 15 atributos.

El resultado se da en unidades salario/mes y horas-hombre.

A LA VEZ, CADA SUBMODELO TAMBIÉN SE DIVIDE EN MODOS QUE REPRESENTAN EL

TIPO DE PROYECTO, Y PUEDE SER:

33
•modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en
un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño
pequeño) a unas decenas de miles (medio).

•modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el

rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no
experimentadas.

•modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar
relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es
difícil basarse en la experiencia, puesto que puede no haberla.

MODELO BASICO

Se utiliza para obtener una primera aproximación rápida del esfuerzo, y hace uso de la
siguiente tabla de constantes para calcular distintos aspectos de costes:

•Estos valores son para las fórmulas:

•Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)

•Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)

•Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV

34
•Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y
analistas.

MODELO INTERMEDIO

Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el
entorno de trabajo, incrementando así la precisión de la estimación.
Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de
aplicar los atributos que se decidan utilizar.
Los valores de las constantes a reemplazar en la fórmula son:

Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando
el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido
han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto
multiplicador de los atributos de coste.

35
ATRIBUTOS

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal
- alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se
asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el
atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por
1000).

El significado de los atributos es el siguiente, según su tipo:

.-De software

•RELY: garantía de funcionamiento requerida al software. Indica las posibles

consecuencias para el usuario en el caso que existan defectos en el producto. Va
desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de
vidas humanas (extremadamente alto, software de alta criticidad).

•DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor
del modificador se define por la relación: D / K, donde D corresponde al tamaño de la
base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.

•CPLX: representa la complejidad del producto.

2.-De hardware

•TIME: limitaciones en el porcentaje del uso de la CPU.

•STOR: limitaciones en el porcentaje del uso de la memoria.

•VIRT: volatilidad de la máquina virtual.

•TURN: tiempo de respuesta requerido.

3.-De personal

•ACAP: calificación de los analistas.

•AEXP: experiencia del personal en aplicaciones similares.

36
•PCAP: calificación de los programadores.

•VEXP: experiencia del personal en la máquina virtual.

•LEXP: experiencia en el lenguaje de programación a usar.

4. De proyecto

•MODP: uso de prácticas modernas de programación.

•TOOL: uso de herramientas de desarrollo de software.

•SCED: limitaciones en el cumplimiento de la planificación.

El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:

37
3.4 Análisis y gestión del riesgo: estrategias, identificación, proyección,
refinamiento, reducción, supervisión y gestión del riesgo.

Gestión del riesgo

La gestión del riesgo es una de las tareas más sustanciales para un administrador de
proyecto. La gestión del riesgo implica anticipar riesgos que pudieran alterar el calendario
del proyecto o la calidad del software a entregar.

La gestión de riesgos adecuada implica el control de posibles eventos futuros. Además,

es proactiva, en lugar de reactiva.

¿Qué es el riesgo?
Podemos considerar un riesgo como algo que es preferible que no ocurra. Los riesgos
pueden amenazar el proyecto, el software que se desarrolla o a la organización.

Categorías:
Riesgos del proyecto:
Riesgos del producto:
Riesgos empresariales:

Identificación
Para identificar los riesgos es necesario revisar, de preferencia trabajando en equipo, los
documentos obtenidos en las etapas previas de la planificación del proyecto —el
Enunciado del alcance, la EDT, el Cronograma, el Presupuesto, y otros— para detectar
qué elementos de los ahí expuestos pueden representar un riesgo. Hay que poner
especial énfasis en las restricciones y los supuestos aceptados en la planificación, ya
que, de no darse, constituirán un posible tropiezo. Por otra parte, existen artículos, libros,
bases de datos accesibles al público, etc., sobre riesgos por área de aplicación o industria
que es conveniente consultar, ya que ofrecen información valiosa sobre estadísticas de
riesgos por área de actividad.

Es más provechoso identificar los riesgos en trabajo de equipo mediante tormenta de

ideas o utilizando la técnica Delphi. Ésta consiste en reunir a un grupo de personas con
experiencia en el tema y en solicitarles su opinión sobre un riesgo específico; por rondas

38
sucesivas, el facilitador va haciendo converger sus opiniones hasta llegar a una
conclusión. Para trabajar de manera estructurada, conviene definir una serie de
categorías y subcategorías de riesgos. Por ejemplo, la categoría riesgos técnicos podría
incluir las subcategorías: requisitos, tecnologías a utilizar y su dominio, obsolescencia,
complejidad, interfaces técnicas, etcétera.

De esta manera se obtiene un documento de registro, estructurado por categorías de

riesgos, sus causas y posibles respuestas, como podemos observar en

Lluvia de ideas para identificación de riesgos

Ventajas: Ayuda a la identificación de los riesgos de una manera muy sencilla y
aprovechando la experiencia de los participantes.

Desventajas: Ausencia de evaluación cuantitativa del nivel de riesgo ni de su impacto o

la probabilidad de que éste se presente.

Sugerencia: Usar esta herramienta como inicio en los procesos de soporte que nunca
han hecho análisis de riesgos antes de pasar a herramientas más complejas.

Video: //poner bibliografia de ste video

39
Proyección
La proyección del riesgo, también denominada estimación del riesgo, intenta medir cada
riesgo de dos maneras

1. La probabilidad de que el riesgo sea real

2. Las consecuencias de los problemas asociados con el riesgo, si ocurriera.

El jefe del proyecto, junto con otros gestores y personal técnico, realiza cuatro
actividades de proyección del riesgo:

(1) establecer una escala que refleje la probabilidad percibida del riesgo;
(2) definir las consecuencias del riesgo;
(3) estimar el impacto del riesgo en el proyecto y en el producto;
(4) apuntar la exactitud general de la proyección del riesgo de manera que no haya
mucho error.

El jefe del proyecto estudia la tabla ordenada resultante y define una línea de corte. La
línea de corte (dibujada horizontalmente) implica que sólo a los riesgos que quedan por
encima de la línea se les prestará atención en adelante. Los riesgos que caen por debajo
de la línea son reevaluados para conseguir una priorización de segundo orden.

40
Todos los riesgos que se encuentran por encima de la línea de corte deben ser
considerados. La columna etiquetada RSGR contiene una referencia que apunta hacia
un plan de reducción, supervisión y gestión del riesgo desarrollado para todos los que se
encuentran por encima de la línea de corte.

La probabilidad de riesgo puede determinarse haciendo estimaciones individuales y

desarrollando después un único valor de consenso. Aunque este enfoque es factible, se
han desarrollado técnicas más sofisticadas para determinar la probabilidad de riesgo.

Los controladores de riesgo pueden valorarse en una escala de probabilidad cualitativa

que tiene los siguientes valores: imposible, improbable, probable y frecuente.

Métodos cuantitativos
Método Montecarlo
Método de valoración del riesgo, de Welberg Anders.

41
Método MOSLER

Métodos cualitativos
Análisis del árbol de fallos (fault tree analysis).
Análisis de seguridad de tareas.
Matriz de riesgos

Estrategias
Esto está enfocado a cómo manejar el riesgo, decidir qué hacer con cada riesgo, para
que podamos manejarlos mejor. En el mundo de la gestión de riesgos, existen varias
estrategias algunas son:

Omisión del riesgo

Omitir el riesgo es modificar el plan del proyecto para eliminar la contingencia o situación.
Aunque resulta imposible eliminar todos los eventos de riesgo, es posible evitar algunos
peligros específicos antes de iniciar el proyecto. Por ejemplo, la adopción de tecnología
probada y no la experimental puede excluir las fallas técnicas. Elegir un proveedor
australiano y no uno de Indonesia descartaría casi por completo las posibilidades de que
una crisis política interrumpa el suministro de materiales básicos.

Transferencia del riesgo

Es común transferir el riesgo a otra parte; este traslado no cambia el riesgo. Hacerlo casi
siempre resulta en que se paga una prima por esta exención. Los contratos de precio fijo
son el ejemplo clásico de transferir el riesgo de un propietario a un contratista. Este último
entiende que su empresa pagará cualquier evento de riesgo que se materialice; por lo
tanto, se añade un factor de riesgo monetario al precio de la licitación. Antes de decidir
la transferencia del riesgo, el propietario debe determinar qué partido puede controlar
mejor las actividades, lo cual conduciría al riesgo. Además, ¿puede el contratista
absorberlo? Es imperativo identificar y documentar la responsabilidad para la absorción
del riesgo. Una manera más obvia de transferir el riesgo es un seguro. Sin embargo, en
general esto es poco práctico porque resulta difícil y caro definir el evento de riesgo del
proyecto y esto lo condiciona a que un corredor de seguros, que no conoce el proyecto,
lo haga. Por supuesto, es más fácil definir y obtener un seguro para los eventos de riesgo

42
de poca probabilidad y grandes consecuencias. Otros instrumentos financieros para
trasladar riesgos son los bonos por desempeño y las garantías de diversos tipos.

Distribución del riesgo

Al distribuirlo se asignan proporciones del riesgo a distintas partes. Un ejemplo de
distribución del riesgo se dio con el Airbus A340. Se repartieron riesgos para
investigación y desarrollo a países europeos como Gran Bretaña y Francia. Por otro lado,
la industria del entretenimiento formó un consorcio para definir un formato común de
operación para el disco de video digital (DVD, Digital Video Disk) a fin de garantizar la
compatibilidad entre productos. Están surgiendo otras formas de distribuir riesgos. En
proyectos de construcción internacionales grandes, como plantas petroquímicas y
refinerías petroleras, los países anfitriones insisten en que los contratos pongan en
práctica las provisiones para construir-poseer-operar-transferir (BOOT, Build-Own-
Operate-Transfer). Aquí se espera que la organización primaria del proyecto no sólo
construya las instalaciones, sino que también se convierta en propietaria hasta que se
haya probado su capacidad de operación y se haya dado todo el desciframiento de las
operaciones, antes de la transferencia final de la propiedad al cliente. En tales casos, el
país anfitrión y la empresa encargada del proyecto se ponen de acuerdo en compartir el
riesgo financiero de la propiedad hasta que se termine el proyecto y se comprueben las
capacidades. También se ha usado la distribución del riesgo para reducir los costos de
los proyectos y fomentar la innovación. La creación de sociedades entre el propietario y
los contratistas ha desencadenado el desarrollo de procedimientos de mejora continua
para fomentar a los contratistas a que sugieran formas innovadoras para la puesta en
práctica del proyecto. Quizá el nuevo método implique costos adicionales para el inicio y
el riesgo de que el nuevo proceso no funcione. En general, los costos del riesgo y los
beneficios del proceso mejorado se comparten 50/50 entre el propietario y las empresas
contratistas.

Retención del riesgo

43
En algunos casos se toma una decisión de aceptar el riesgo de que ocurra un evento.
Algunos riesgos son tan grandes que no es posible considerar una transferencia o una
reducción del evento (por ejemplo, un terremoto o una inundación). El propietario del
proyecto asume el riesgo porque las probabilidades de que un evento así se presente
son escasas. En otros casos, los riesgos que se identifican en la reserva del presupuesto
pueden absorberse si se materializan. El riesgo se retiene al desarrollar un plan de
contingencia para el momento en que el primero se realice. En algunos casos es posible
ignorar un evento de riesgo y aceptar un excedente en los costos si el evento se presenta.
Mientras mayor esfuerzo se haga para responder al riesgo antes de que el proyecto se
inicie, mayores serán las posibilidades de minimizar sorpresas en el proyecto.

Al saber que la respuesta a un evento se retendrá, transferirá o compartirá, se elimina

mucho estrés e incertidumbre cuando se presenta el evento de riesgo. De nuevo, es
posible mantener el control con este enfoque estructurado del evento de riesgo. Como
todos los planes, responde a los cuestionamientos de qué, dónde, cuándo y cuánta
acción se llevará a cabo.

Plan de contingencia
La falta de un plan de contingencia, cuando se presenta un evento de riesgo, puede
propiciar que un gerente retrase o posponga la decisión de poner en práctica un remedio.
Cuando lo hace puede producir pánico y la aceptación de la primera componenda que
se sugiera. Tomar una decisión así, posterior al evento y bajo presión, puede ser muy
peligrosa y costosa. En la planeación para contingencias se evalúan soluciones alternas
para eventos previstos antes de que se presenten y se escoge el mejor plan entre las
opciones disponibles. Esta planeación temprana para contingencias facilita una
transición fácil a la solución o al plan de trabajo en torno a la dificultad. Cuando se cuenta
con un plan de contingencias aumentan mucho las probabilidades de que el proyecto
tenga éxito.

Refinamiento
Durante las primeras etapas de la planificación del proyecto, un riesgo puede enunciarse
de manera muy general. Conforme pasa el tiempo y se aprende más acerca del proyecto

44
y de los riesgos, es posible refinar el riesgo en un conjunto de riesgos más detallados,
cada uno un poco más sencillo de mitigar, monitorear y manejar. Una forma de hacer
esto es representar el riesgo en formato condición-transición-consecuencia (CTC). Es
decir, el riesgo se enuncia en la forma siguiente: Dado que _____ entonces hay
preocupación porque (posiblemente) _______

Reducción
En general, la reducción del riesgo es la primera alternativa considerada. Sobre todo,
hay dos estrategias para mitigar el riesgo:

1) reducir la probabilidad de que el evento se presente

2) disminuir el efecto que el evento adverso podría tener en el proyecto.

La mayoría de los equipos de riesgo se centran primero en reducir la probabilidad de los

eventos de riesgo ya que, de tener éxito, pueden eliminar la necesidad de considerar la
segunda estrategia, potencialmente costosa. A menudo, la comprobación y la
elaboración de un prototipo pueden utilizarse para evitar que surjan problemas más
adelante en un proyecto. Un ejemplo de comprobación puede encontrarse en un proyecto
de sistemas de información. El equipo del proyecto era el responsable de instalar un
nuevo sistema operativo en su empresa matriz. Antes de poner el proyecto en práctica,
el equipo probó el nuevo sistema en una red aislada más pequeña. Al hacerlo
descubrieron una diversidad de problemas y pudieron obtener soluciones antes de la
ejecución. El equipo todavía se topó con algunos problemas de instalación, pero su
cantidad y gravedad se redujeron mucho. A menudo resulta útil identificar las causas
más profundas de un evento. Por ejemplo, el miedo de que un proveedor no pueda
proporcionar a tiempo los componentes hechos a la medida puede atribuirse a:

1) malas relaciones con proveedores,

2) mala comunicación del diseño
3) falta de motivación.

45
Como resultado de este análisis, el administrador del proyecto puede decidir llevar a su
contraparte a comer para limar asperezas, invitar al proveedor a asistir a las juntas de
diseño y reestructurar el contrato para que incluya incentivos para la entrega a tiempo.

Otros ejemplos para la reducción de la probabilidad de que los riesgos se presenten son
la programación de trabajo en exteriores durante los meses de verano, la inversión en
capacitación en seguridad de primera y la elección de materiales y equipo de alta calidad.
Cuando las preocupaciones son un mal cálculo de la duración y los costos, los gerentes
aumentarán los estimados para compensar las incertidumbres. Es común utilizar una
proporción entre un proyecto nuevo y otro antiguo para ajustar tiempos y costos. En
general, tal proporción sirve como constante. Por ejemplo, si en el proyecto anterior se
han necesitado 10 minutos por línea de código de computadora, se utilizaría una
constante de 1.10 (que representa un aumento de 10 por ciento) para los estimados
propuestos para el tiempo del proyecto porque el nuevo proyecto es más difícil que los
anteriores. Una estrategia alterna de mitigación consiste en reducir el efecto del riesgo
si éste se presentara.

Por ejemplo, un proyecto de construcción de un puente ilustra la reducción de riesgos.

En un proyecto de edificación de un puente nuevo para un puerto en la costa se utilizaría
un proceso innovador de vaciado continuo de cemento que desarrolló una empresa
australiana, a fin de ahorrar grandes cantidades de tiempo y dinero. El riesgo más
importante era que no podría interrumpirse el proceso de vaciado continuo de cada
sección importante del proyecto. Cualquier suspensión exigiría que se destruyera toda la
sección de cemento (cientos de metros cúbicos) y que se comenzara de nuevo. Una
evaluación de los riesgos posibles ubicaba la entrega de cemento de la fábrica que lo
producía. Los camiones podrían retrasarse y la fábrica podría fracasar. Tales riesgos
causarían retrasos y grandes costos por el trabajo repetido. El riesgo se redujo al instalar
dos plantas portátiles de cemento que se construyeron en varias carreteras cercanas, a
20 millas del proyecto en cuestión, en caso de que se interrumpiera el suministro de la
fábrica principal. Dichas plantas acarrearon materia prima para toda una sección del
puente y había camiones listos para cada ocasión que se requería un vaciado continuo.
Escenarios semejantes para la reducción de riesgos se dan en los proyectos de

46
desarrollo de software y sistemas en los que se utilizan procesos paralelos de innovación
en caso de que alguno falle.

Supervisión de riesgos
De nada sirve haber identificado durante la planificación del proyecto que se puede
presentar un riesgo, haberlo analizado y haber establecido una actitud ante él si luego
no estamos atentos a cuándo se presenta realmente.

Por ello, se deben realizar un seguimiento del proyecto en busca de la aparición de

riesgos o de los disparadores o triggers que anuncian su llegada. Así, se debe revisar el
proyecto cuidadosamente y de manera constante. Según algunos expertos, el
instrumento más potente de control de riesgos es la supervisión permanente. Para ello,
se deben realizar reuniones específicas en las que se revisen los puntos anteriormente
desarrollados y se analicen en relación con el estado actual del proyecto.

47
Conclusiones:
En este tema aprendimos mucho sobre la importancia de la planeación del proyecto, en
la cual si se hacen las cosas bien ahorra muchos costos y tiempo también permite prever
problemas, los cuales si se llegan a presentar gracias a haber realizado una buena
planeación ya conocemos que hacer. Entre las diferentes etapas primero está la
estimación de tiempos y costos, después el ámbito del software lo cual se refiere a todos
los recursos necesarios para el desarrollo del proyecto del software, después aprendimos
sobre que existen métricas para así poder medir el costo del proyecto de software,
finalmente vimos sobre las etapas para la gestión del riesgo, técnicas para identificarlo,
métodos para estimarlo y estrategias para gestionarlo, para presentar todo esto tuvimos

48
que investigar a fondo, utilizar recursos de video, libros, y software, lo cual ha sido algo
que disfrutamos para aprender más sobre la ingeniería del software.

Herramientas y recursos utilizados

Para investigar utilizamos youtube.com, libros descargados de academia.edu, artículos

web.

Para escribir esta investigación empleamos Microsoft Word.

Para aplicar el conocimiento en estimación de tiempos y costos usamos software de

gestión de proyectos, como Project Libre, Work Bench, sinnaps, diagrams.net, trello,
simplestimate, entre otros.
Para la presentación revisamos las siguientes herramientas de software.
Plataformas para desarrollo de software

https://www.heroku.com

https://www.openshift.com

https://www.docker.com

https://dokku.com

https://aws.amazon.com/es/elasticbeanstalk/

https://cloud.google.com/appengine?hl=es

Repositorios de software

https://github.com

https://git-scm.com

https://about.gitlab.com

AUTOMATIZACION

https://www.chef.io/products/chef-automate

https://puppet.com

https://www.terraform.io

49
HERRAMIENTAS SP

https://www.jenkins.io

https://travis-ci.org

50
Bibliografía:
Somerville. (2011). Ingeniería de software. Recuperado de
https://www.academia.edu/25063155/Ingenieria_de_Software_Somerville

Gomez, F., & Cervantes, O., & González, P. (2012). NOTAS DEL CURSO
ADMINISTRACIÓN DE PROYECTOS. Recuperado de
https://www.academia.edu/40130912/UNIVERSIDAD_AUT%C3%93NOMA_METROPO
LITANA_UNIDAD_CUAJIMALPA_ADMINISTRACI%C3%93N_DE_PROYECTOS_UNI
VERSIDAD_AUT%C3%93NOMA_METROPOLITANA_UNIDAD_CUAJIMALPA_Casa_
abierta_al_tiempo_ADMINISTRACI%C3%93N_DE_PROYECTOS

Asana. (2020). ¿No conocías los diagramas de Gantt? Comienza aquí. Recuperado de
https://asana.com/es/resources/gantt-chart-basics

Pichardo, D. (2020). RUTA CRÍTICA O CPM-(Definición y Ejemplo). Recuperado de

https://www.youtube.com/watch?v=NGQzWqFE-RY

Gray, Clifford., & Larson, E. (2009). administración de proyectos 4 ed. Recuperado de

https://www.academia.edu/10845328/Administracion_de_proyectos_Clifford_F_Gray

Rivera. M, F., & Hernández. C, G. (2010). Administración de proyecto guía de

aprendizaje. Recuperado de
https://www.academia.edu/37404112/Administracion_de_proyectos_Francisco_Rivera_
Martinez_pdf

Taha, A, H. (2012). INVESTIGACIÓN DE OPERACIONES. Recuperado de

https://www.academia.edu/15590842/Investigaci%C3%B3n_de_Operaciones_9a_ed_T
aha_H_2012_

Leandro, G. (2015). Administración de proyectos PERT - parte 3. Recuperado de

https://www.youtube.com/watch?v=iYsVb8SzaTM

Marcoteorico. (2016). Ámbito del software. Recuperado de

https://www.marcoteorico.com/curso/91/ingenieria-de-software/858/ambito-del-software

51
GOB.MX. (2018). Supervisión basada en riesgos
https://www.gob.mx/cms/uploads/attachment/file/412911/Metodologi_as_de_SBR_en_e
l_SAR_J15nov2018.pdf

Gestiondeproyectovazquez. (2014). Gestión de proyecto. Recuperado de:

https://sites.google.com/site/gestiondeproyectovazquez/home/unidad-3-planificacion-
del-proyecto/3-5-analisis-de-riesgos/3-5-2-identificacion-impacto-y-proyeccion-del-
riesgo

García, Bryan. (2015). Riesgo en los proyectos. Recuperado de:

https://ingsoftwarebryan.files.wordpress.com/2015/07/riesgo-en-los-proyectos.pdf

Arévalo, M. C. (2020). Conoce ocho procesos para identificar riesgos. Recuperado de

https://www.piranirisk.com/es/blog/conozca-ocho-procesos-para-identificar-riesgos

Delgado, E. (2017). 3 Herramientas para el Análisis de Riesgos. Recuperado de

https://spcgroup.com.mx/3-herramientas-para-el-analisis-de-riesgos/

Delgado, O. (2020). Tres técnicas de identificación de riesgos que quizá no conocías.

Recuperado de https://sgc-lab.com/tres-tecnicas-de-identificacion-de-riesgos-que-quiza-
no-conocias/

Delgado, Juan. (2016). Riesgos en la gestión de proyectos: no los ignores, contrólalos.

Recuperado de https://www.itmplatform.com/es/blog/riesgos-en-la-gestion-de-
proyectos-no-los-ignores-controlalos/

EALDE. (2018). Métodos cuantitativos y cualitativos para la Gestión de Riesgos.

Recuperado de https://www.ealde.es/gestion-de-riesgos-metodos-cuantitativos-
cualitativos/

Comunidad.madrid. (2009). Análisis y cuantificación del riesgo. Recuperado de

http://www.madrid.org/cs/StaticFiles/Emprendedores/Analisis_Riesgos/pages/pdf/metod
ologia/4AnalisisycuantificaciondelRiesgo(AR)_es.pdf

52
Hurtado, Josué. (2020). MÉTODO MOSLER para la gestión de riesgos. Recuperado de
https://youtu.be/BBqCm0ySlUQ

Universidad de Murcia. (2002). Gestión de riesgos en ingeniería del software.

Recuperado de http://dis.um.es/~barzana/Informatica/IAGP/IAGP_riesgos.html

Hernandez, Orlando. (2020). Identificación de riesgos. Recuperado de

https://www.youtube.com/watch?v=hze7TwldnBI

RedHat. (2019). Concepto de DevOps. Recuperado de

https://www.redhat.com/es/topics/devops

Exceltic. (2017). DevOps en menos de 3 minutos. Recuperado de

https://www.youtube.com/watch?v=p-bOnV8FRMQ&t=44s

Cloudevel. (2017). Conceptos y herramientas básicas de DevOps. Recuperado de

https://www.youtube.com/watch?v=JPmFy4tglrw&t=2428s

Heyselllopez. (2010). Métrica orientada al tamaño COCOMO. Recuperado de

http://heyssellopez.blogspot.com/2010/10/metrica-orientada-al-tamano-cocomo.html

Cidecame. (2014). Métricas orientadas al tamaño. Recuperado de

http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro22/231_mtricas_orientadas_al
_tamao.html

Infante, F. (2019). Estimación del Costo COCOMO I-Ing. Fernando Infante Saavedra.
Recuperado de Estimación de https://www.youtube.com/watch?v=f_RcCgKQoKc

53