Alumnos: No. Control: Briseño Ramírez Omar Isaac 18251005 Marcos Arroyo Itzel 19251086 Diaz Galicia Raúl Alberto 19251067 Pascual Estrada Jareli 19251056 Luna Godínez Zayra Monserrat 19251065 Maestra: María Esther García Hernández Agosto - Diciembre 2021 3.1 Aplicación de herramientas para estimación de tiempos y costos de desarrollo de software. 3.2 Ámbito del software. 3.3 Métricas orientadas al tamaño, al esfuerzo y a los costos. 3.4 Análisis y gestión del riesgo. Instituto Tecnológico de Tlalnepantla. Ingeniería de Software Ingeniería en Tecnologías de la Información y Comunicación.. 

Scene 1

Alumnos:			No. Control: Briseño Ramírez Omar Isaac	                    18251005 Marcos Arroyo Itzel                                               19251086 Diaz Galicia Raúl Alberto                                      19251067 Pascual Estrada Jareli                                            19251056 Luna Godínez Zayra Monserrat                           19251065 Maestra: María Esther García Hernández Agosto - Diciembre 2021 3.1 Aplicación de herramientas para estimación de tiempos y costos de desarrollo de software. 3.2 Ámbito del software. 3.3 Métricas orientadas al tamaño, al esfuerzo y a los costos. 3.4 Análisis y gestión del riesgo. Instituto Tecnológico de Tlalnepantla. Ingeniería de Software Ingeniería en Tecnologías de la Información y Comunicación.

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

Scene 2

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.

La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipando problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado.. 

Scene 3

La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipando problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado.

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permite 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. Las estimaciones deberían definir los escenario 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.. 

Scene 4

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.  Las estimaciones deberían definir los escenario 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.

ESTIMACION DEL PROYECTO DE SOFTWARE.. Cuando se planifica un proyecto de software ese tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Si el proyecto es distinto entonces puede que las experiencias obtenidas no sean suficientes.. 

Scene 5

Cuando se planifica un proyecto de software ese tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Si el proyecto es distinto entonces puede que las experiencias obtenidas no sean suficientes.

3.2.- ÁMBITO DEL SOFTWARE.. Plantillas,instrucciones y software para imprimir tarjeta.... 

Scene 6

Plantillas,instrucciones y software para imprimir tarjeta...

El ámbito de software es el lugar donde se incorpora el proyecto, involucrando hardware y software. El hardware proporciona las herramientas para el desarrollo del software. El software verifica la disponibilidad.

"El estudio del ámbito del software, consiste en realizar un estudio del ámbito al cual pertenecen los componentes software para los que se quiere evaluar la calidad. Es recomendable revisar fuentes de información que describan dicho ámbito."

Los recursos humanos son la cantidad de personas requeridas para el desarrollo de un proyecto de software, determinados por un tiempo, en una organización.

El numero de personas necesario para un proyecto de software se establece después de que se ha realizado una evaluación del esfuerzo de desarrollo (por ejemplo, persona por mes).

Se deben establecer las habilidades que se necesitan para llevar a cabo el desarrollo del proyecto. Hay que especificar tanto la posición dentro de la organización como la especialidad. El número de personas requerido para un proyecto de software se determina después de hacer una estimación del esfuerzo de desarrollo.. 

Scene 7

Se deben establecer las habilidades que se necesitan para llevar a cabo el desarrollo del proyecto. Hay que especificar tanto la posición dentro de la organización como la especialidad. El número de personas requerido para un proyecto de software se determina después de hacer una estimación del esfuerzo de desarrollo.

Software de Recursos Humanos: 7 Herramientas claves

La segunda actividad de la planeación del desarrollo de software es la evaluación de los recursos necesarios para solventar el esfuerzo del proceso de software.

ersona
mponentes d
software
Herramientas de Hardware
y Software

La figura siguiente ilustra los recursos para el desarrollo de software reutilizable en forma piramidal.

En la base se ubica el entorno de desarrollo (materiales de hardware y software), que suministra la infraestructura de soporte al esfuerzo de desarrollo. En un nivel más alto se encuentran los componentes de software.

Hay que tomar en cuenta también las cuatro categorías de recursos de software:. 

Scene 8

Hay que tomar en cuenta también las cuatro categorías de recursos de software:

01 npouerlteb"nuevu'o.
Componentes ya desarrollados.
(Sorn e
Componentes con experiencia parcial.

El entorno es donde se apoya el proyecto de software, llamado a menudo entorno de ingeniería del software (EIS), incorpora hardware y software.  Cada elemento de hardware debe ser especificado por el planificador del proyecto de software.

El hardware facilita una plataforma con los materiales (software) solicitados para desarrollar los productos que son la consecuencia de un buen trabajo de la ingeniería del software.

Como las empresas de software suelen tener aspectos que necesitan tener acceso a EIS, un analista de proyecto debe establecer la ventana temporal intimada para el hardware y el software, y confirmar que estos recursos estarán utilizables.

Gestión del Capital humano: ¿qué es y cómo optimizarla?

3.3 METRICAS ORIENTADAS AL TAMAÑO, AL ESFUERZO Y A LOS COSTOS. 

Scene 9

3.3 METRICAS ORIENTADAS AL TAMAÑO, AL ESFUERZO Y A LOS COSTOS

Las métricas son una medida efectuada sobre los programas, documentación, su desarrollo y mantenimiento, o sobre algún aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparación con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias.

METRICAS ORIENTADAS A TAMAÑO. Es para saber en que tiempo se va a terminar el software y cuantas personas se van a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño. MEDIDAS Líneas de código Esfuerzo en hombre-mes Costo en pesos Numero de paginas de documentación Numero de errores Numero de defectos Numero de personas en el proyecto. 

Scene 10

Es para saber en que tiempo se va a terminar el software y cuantas personas se van a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño.  MEDIDAS Líneas de código Esfuerzo en hombre-mes Costo en pesos Numero de paginas de documentación  Numero de errores Numero de defectos Numero de personas en el proyecto

'royecto
Alfa
Beta
Gamma
LDC
12,100
27200
20,200
Esfuerzo Coste
24
62
43
f(000)
168
440
314
Pag. Doc.
365
1224
1050
Errores
134
321
256
Defectos
29
86
64
Personas
3
5
6

METRICAS ORIENTADAS AL ESFUERZO. El desarrollo del software es una actividad humana que depende en gran medida del trabajo personal. A la hora de valorar un sistema software debe considerarse la cantidad de esfuerzo que debe invertir el equipo de desarrollo para culminar su construcción. El coste del desarrollo es prácticamente el del trabajo empleado, pues la gente asignada a materiales es de tan poca entidad que resulta despreciable frente a la mano de obra. El esfuerzo requerido para construir un sistema puede ser medido con mucha utilidad.. 

Scene 11

El desarrollo del software es una actividad humana que depende en gran medida del trabajo personal. A la hora de valorar un sistema software debe considerarse la cantidad de esfuerzo que debe invertir el equipo de desarrollo para culminar su construcción.  El coste del desarrollo es prácticamente el del trabajo empleado, pues la gente asignada a materiales es de tan poca entidad que resulta despreciable frente a la mano de obra. El esfuerzo requerido para construir un sistema puede ser medido con mucha utilidad.

MEDIDAS ORIENTADAS A LOS COSTOS. La estimación y calendarización para que el proyecto se lleve de forma conjunta, también a su vez permite la utilización efectiva de los recursos y una adecuada planeación. Costos de hardware y software, incluyendo mantenimiento. Costos de viajes y capacitación Costos de esfuerzo (pago a los ingenieros de software) Para muchos proyectos, el costo dominante es el costo de esfuerzo.. 

Scene 12

La estimación y calendarización para que el proyecto se lleve de forma conjunta, también a su vez permite la utilización efectiva de los recursos y una adecuada planeación.  Costos de hardware y software, incluyendo mantenimiento. Costos de viajes y capacitación Costos de esfuerzo (pago a los ingenieros de software) Para muchos proyectos, el costo dominante es el costo de esfuerzo.

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

Scene 13

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

ANÁLISIS Y GESTIÓN DEL RIESGO Son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre. Es una buena idea identificar, evaluar la probabilidad de aparición de un problema, estimar su impacto, y establecer un plan de contingencia. Lo hacen todos los que estén involucrados en el proceso del software: gestores, ingenieros de software y clientes. El software es una empresa difícil. Muchas cosas pueden ir mal, a menudo van mal. Esta es la razón para estar preparados comprendiendo los riesgos y tomando las medidas proactivas para evitarlo o gestionarlo es un elemento clave de una buena gestión de proyectos de software.. 

Scene 14

ANÁLISIS Y GESTIÓN DEL RIESGO Son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre. Es una buena idea identificar, evaluar la probabilidad de aparición de un problema, estimar su impacto, y establecer un plan de contingencia.  Lo hacen todos los que estén involucrados en el proceso del software: gestores, ingenieros de software y clientes. El software es una empresa difícil. Muchas cosas pueden ir mal, a menudo van mal. Esta es la razón para estar preparados comprendiendo los riesgos y tomando las medidas proactivas para evitarlo o gestionarlo es un elemento clave de una buena gestión de proyectos de software.

ESTRATEGIAS DE RIESGO PROACTIVAS VS. REACTIVAS ESTRATEGIAS DE RIESGO REACTIVAS : Supervisa el proyecto en previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema rápidamente. Este es el método denominado a menudo “de bomberos”. Cuando falla, la gestión de crisis entra en acción y el proyecto se encuentra en peligro real. ESTRATEGIA INTELIGENTE PARA EL CONTROL DEL RIESGO ES SER PROACTIVO . Empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia.. 

Scene 15

ESTRATEGIAS DE RIESGO PROACTIVAS VS. REACTIVAS ESTRATEGIAS DE RIESGO REACTIVAS : Supervisa el proyecto en previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema rápidamente. Este es el método denominado a menudo “de bomberos”.  Cuando falla, la gestión de crisis entra en acción y el proyecto se encuentra en peligro real.  ESTRATEGIA INTELIGENTE PARA EL CONTROL DEL RIESGO ES SER PROACTIVO . Empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia.

IDENTIFICACION DEL RIESGO Intento sistemático para especificar las amenazas al plan del proyecto. Hay dos tipos: Los riesgos genéricos son una amenaza potencial para todos los proyectos de software. Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Forma de identificar los riesgos La lista de comprobación se centra en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas: Tamaño del producto, Impacto en el negocio, Características del cliente, Definición del proceso, Entorno de desarrollo, Tecnología a construir, Tamaño y experiencia de la plantilla.. 

Scene 16

IDENTIFICACION DEL RIESGO Intento sistemático para especificar las amenazas al plan del proyecto. Hay dos tipos:  Los riesgos genéricos son una amenaza potencial para todos los proyectos de software.  Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión.  Forma de identificar los riesgos La lista de comprobación se centra en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas: Tamaño del producto, Impacto en el negocio, Características del cliente, Definición del proceso, Entorno de desarrollo, Tecnología a construir, Tamaño y experiencia de la plantilla.

RIESGO DEL SOFTWARE Tiene dos características: 1. INCERTIDUMBRE: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad. 2. PÉRDIDA: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas. Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.. 

Scene 17

RIESGO DEL SOFTWARE Tiene dos características: 1.  INCERTIDUMBRE:  el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad. 2.  PÉRDIDA:  si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas. Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos: Evitar el riesgo. Supervisar el riesgo, y Gestionar el riesgo y planes de contingencia Supervisar los siguientes factores: Actitud general de los miembros del equipo basándose en las presiones del proyecto; Grado de compenetración del equipo; Relaciones interpersonales entre los miembros del equipo; Problemas potenciales con compensaciones y beneficios; Disponibilidad de empleo dentro y fuera de la compañía.. 

Scene 18

REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DEL RIESGO Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos: Evitar el riesgo. Supervisar el riesgo, y Gestionar el riesgo y planes de contingencia Supervisar los siguientes factores: Actitud general de los miembros del equipo basándose en las presiones del proyecto; Grado de compenetración del equipo; Relaciones interpersonales entre los miembros del equipo; Problemas potenciales con compensaciones y beneficios; Disponibilidad de empleo dentro y fuera de la compañía.

1. R. Pressman. Ingeniería del Software: Un Enfoque Práctico. 7 Ed. McGraw Hill, 2010. 2. Sommerville Ian. Ingeniería del Software. Pearson 7a. Edición. 2005. 3. S. Sánchez, M. Sicilia, D. Rodríguez. Ingeniería del software. Un enfoque desde la guía SWEBOK. Alfaomega. 2012. 4. RAE Real Academia Española RAE, Real Academia Española, “Diccionario de la Lengua Española Diccionario de la Lengua Española”, 22ª Ed 2001 22ª ed., 2001. 5. Sommerville, I. “Ingeniería de Software”, 6ª ed., Addison Wesley, 2002. 6. Yourdon, E.: “Análisis Estructurado Moderno”, Prentice Hall, 1993. 7. https://www.efectodigital.online/single-post/2017/12/08/%C3%A1mbito-de-las-aplicaciones-de-software. 

Scene 19

1. R. Pressman. Ingeniería del Software: Un Enfoque Práctico. 7 Ed. McGraw Hill, 2010. 2. Sommerville Ian. Ingeniería del Software. Pearson 7a. Edición. 2005. 3. S. Sánchez, M. Sicilia, D. Rodríguez. Ingeniería del software. Un enfoque desde la guía SWEBOK. Alfaomega. 2012. 4. RAE Real Academia Española RAE, Real Academia Española, “Diccionario de la Lengua Española Diccionario de la Lengua Española”, 22ª Ed 2001 22ª ed., 2001. 5. Sommerville, I. “Ingeniería de Software”, 6ª ed., Addison Wesley, 2002. 6. Yourdon, E.: “Análisis Estructurado Moderno”, Prentice Hall, 1993. 7.   https://www.efectodigital.online/single-post/2017/12/08/%C3%A1mbito-de-las-aplicaciones-de-software

Scene 0

 1. R. Pressman. Ingeniería del Software: Un Enfoque Práctico. 7 Ed. McGraw Hill, 2010. 2. Sommerville Ian. Ingeniería del Software. Pearson 7a. Edición. 2005. 3. S. Sánchez, M. Sicilia, D. Rodríguez. Ingeniería del software. Un enfoque desde la guía SWEBOK. Alfaomega. 2012. 4. RAE Real Academia Española RAE, Real Academia Española, “Diccionario de la Lengua Española Diccionario de la Lengua Española”, 22ª Ed 2001 22ª ed., 2001. 5. Sommerville, I. “Ingeniería de Software”, 6ª ed., Addison Wesley, 2002. 6. Yourdon, E.: “Análisis Estructurado Moderno”, Prentice Hall, 1993. 7.   https://www.efectodigital.online/single-post/2017/12/08/%C3%A1mbito-de-las-aplicaciones-de-software