INGENIERIA DE SOFTWARE AVANZADA

INGENIERIA

DE SOFTWARE

Dr. Mario Rossainz López

Fac. de Cs. de la Computación

Benemérita Universidad Autónoma de Puebla

Otoño 2021

Planificación de Proyectos Software

⚫ Conjunto de actividades necesarias para

desarrollar el proyecto.

⚫ Probablemente es la actividad que más consume

tiempo.

⚫ Existe una actividad continua desde el concepto

inicial del proyecto hasta que este es liberado. Los

planes deben de ser revisados regularmente a

medida que está disponible nueva información.


Estructura del plan del proyecto

⚫ Introducción.

⚫ Organización del proyecto.

⚫ Análisis de riesgos.

⚫ Requerimientos de software y hardware.

⚫ Repartición del trabajo.

⚫ Planificación del trabajo.

⚫ Monitorización y mecanismos de reporte.


Tipos de planes del proyecto

Plan Descripción

Plan de Desarrollo

Plan de Calidad

Plan de Validación

Plan de Mantenimiento

Plan de Desarrollo Personal

Describe la metodología a utilizar en el desarrollo

del proyecto.

Describe los procedimientos de calidad, y los

estándares a utilizar en el proyecto.

Describe el enfoque, los recursos y la programación

utilizados para la validación del sistema.

Predice los requerimientos de mantenimiento del

sistema, los costos del mantenimiento y el esfuerzo.

Describe como se adquirirán y desarrollarán los

conocimientos y habilidades del personal.


Proceso de planeación del proyecto

Establecer las restricciones del proyecto

hacer las suposiciones iniciales de los parámetros del proyecto

Definir hitos del proyecto y productos a entregar

while el proyecto no se haya completado o cancelado loop

Describe la planificación de tiempos del proyecto

Inicia las actividades de acuerdo a la planificación

Espera (a que se lleve a cabo el desarrollo)

Revisa el progreso del proyecto

Revisa los parámetros estimados del proyecto

Actualizar la planificación del proyecto

Renegociar las restricciones del proyecto y los productos a entregar

if (aparecen problemas) then

inicia una revisión técnica y sus posibles soluciones

end if

end loop


Organización de actividades

⚫ Las actividades en un proyecto deben ser organizadas

para producir resultados tangibles para que la

administración pueda juzgar el progreso.

⚫ Los “Hitos” son los puntos finales de alguna actividad.

⚫ Los “Productos Entregables” son los resultados del

proyecto que serán entregados a los clientes.

⚫ El proceso de “cascada” permite una definición precisa de

los “Hitos”.


Hitos y Productos Entregables

Estudio de

FactibilidadAnálisis de

Requerimientos

Informe de

Factibilidad

Desarrollo de

PrototiposEstudio del

Diseño

Diseño de la

ArquitecturaInforme de

EvaluaciónDefinición de

Requerimientos

Especificación de

Requerimientos

Requerimientos

Del sistema

ACTIVIDADES

HITOS


Calendarización del Proyecto

⚫ Distribuye el proyecto en tareas y estima el tiempo y los

recursos requeridos para completar cada tarea.

⚫ Organiza las tareas de forma concurrente para hacer

mejor uso de la fuerza laboral.

⚫ Minimiza dependencias entre tareas para evitar retrasos

debidos a que una tarea espere a la terminación de otra.

⚫ Depende de la intuición y experiencia de los

administradores.


Problemas con la Calendarización

⚫ Es difícil estimar la longitud y dificultad de las tareas, por

lo que la estimación del costo es mas difícil.

⚫ La productividad no es proporcional al número de

personas trabajando en una tarea.

⚫ Incluir personal en un proyecto en avance, retrasa el

proyecto por “overheads” en la comunicación.

⚫ Lo inesperado siempre sucede. Es necesario considerar

siempre contingencias.


Proceso de la calendarización del proyecto

Identificar

Actividades

Identificar

Dependencias de

Actividades

Requerimientos

de Software

Estimar recursos

para las

actividades

Asignar personas

A las actividadesCrear Gráficos

de proyectos

Redes de actividades

Gráficos de barras


Gráficas de barras y redes de actividades.

⚫ Se utilizan notaciones gráficas para ilustrar la

calendarización del proyecto.

⚫ Muestra la partición del proyecto en tareas. Las tareas no

deben ser muy pequeñas. Estas deben de tener una

duración de una semana o dos.

⚫ Las gráficas de actividades muestran las dependencias

entre tareas y la ruta crítica.

⚫ Las gráficas de barras muestran la planificación contra el

tiempo del calendario de actividades.


Duración de las tareas y dependencias.

T1 8

T2 15

T3 15 T1 (M1)

T4 10

T5 10 T2,T4 (M2)

T6 5 T1,T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3,T6 (M4)

T10 15 T5,T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

Tareas Duración (días) Dependencias


start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3

T9

M6

T11

M8

T12

M4

Red de Actividades


4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1

T2

M1

T7T3

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T11M8

T12

Start

Finish

Gráfico de barras de actividad (de Gantt)


4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

Gráfico de asignación de personal


⚫ ADMINISTRACION DE RIESGOS

Riesgo: Es la probabilidad de que una circunstancia

adversa ocurra.

Administración de Riesgos: Es la identificación de riesgos

que podrían afectar la programación del proyecto o la calidad

del software a desarrollar y la creación de planes para

minimizar sus efectos en el proyecto.

Los riesgos son una amenaza para el proyecto, el software

que se esta desarrollando y la organización



Categorías de Riesgos:

1. Riesgos del Proyecto: Afectan la calendarización o

los recursos del proyecto.

2. Riesgos del Producto: Afectan la calidad o

desempeño del software que se esta desarrollando.

3. Riesgos del Negocio: Afectan a la organización que

desarrolla el software.


⚫ ADMINISTRACION DE RIESGOSRIESGO TIPO DE RIESGO DESCRIPCION

Rotación de Personal Proyecto Personal con experiencia, abandona el proyecto

Cambio de Admon. Proyecto Cambio de Admon. Organizacional.

No disponibilidad del HW Proyecto El HW esencial para el proyecto no será

entregado a tiempo.

Cambio de requerimientos Proyecto y Producto Habrá más cambios en los requerimientos

Retrasos en la especificación Proyecto y Producto Las especificaciones de las interfaces no estarán

a tiempo

Subestimación del tamaño Proyecto y Producto El tamaño del sistema se ha subestimado

Bajo desempeño de la herramienta

CASE

Proyecto y Producto Las herramientas CASE utilizadas no tienen el

rendimiento anticipado

Cambio de tecnología Negocio La tecnología sobre la que se construye el

producto es sustituida por la nueva tecnología

Competencia del Producto Negocio Un producto competitivo se pone en venta antes

de que el sistema se complete.



Risk avoidanceand contingency

plans

Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks

Riskidentification

Riskassessment

Riskmonitoring

PROCESO:



PROCESO:

1. Identificación de Riesgos: Identificar los posibles riesgos para el

proyecto, el producto y los negocios.

2. Análisis de Riesgos: Valorar las probabilidades y consecuencias

de estos riesgos.

3. Planeación de Riesgos: Crear planes para abordar los riesgos,

ya sea para evitarlos o minimizar sus efectos en el proyecto.

4. Supervisión de Riesgos: Valorar los riesgos de forma constante y

revisar los planes para la mitigación de riesgos tan pronto como

la información de los riesgos esté disponible.



1. IDENTIFICACION DE RIESGOS:

TIPOS DE RIESGOS:

• Riesgos de Tecnología: Se derivan de las tecnologías de SW o de HW

utilizadas en el sistema que se esta desarrollando.

2. Riesgos de Personas: Riesgos asociados con las personas en el equipo

de desarrollo.

3. Riesgos Organizacionales: Se derivan del entorno organizacional donde

el software se esta desarrollando

4. Riesgos de Herramientas: Se derivan de las herramientas CASE y otro

software de apoyo utilizado para desarrollar el sistema

5. Riesgos de Requerimientos: Se derivan de los cambios de los

requerimientos del cliente y el proceso de administrar dicho cambio.

6. Riesgos de Estimación: Se derivan de los estimados administrativos

de las características del sistema y los recursos para construirlo.


Tipo de Riesgo Riesgos Posibles

Tecnología La BD que se utiliza en el sistema no puede procesar muchas transacciones por segundo

como se esperaba

Los componentes de SW a reutilizarse contienen defectos que limitan su funcionalidad.

Personas Es imposible reclutar personal con las habilidades requeridas para el proyexto

El personal clave esta enfermo y no disponible en momentos críticos

La capacitación solicitada para el personal no esta disponible

Organizacional La organización se reestructura de tal forma que una admon. diferente se responsabiliza

del proyecto.

Los problemas financieros de la organización fuerzan a reducciones en el prtesupuesto del

proyecto.

Herramientas Es ineficiente el código generado por las herramientas CASE

Las herramientas CASE no se pueden integrar

Requerimientos Se proponen cambios en los requerimientos que requieren rehacer el diseño

Los clientes no comprenden el impacto de los cambios en los requerimientos

Estimación El tiempo requerido para desarrollar el SW esta subestimado

La tasa de reparación de defectos esta subestimada

El tamaño del SW esta subestimado

1. IDENTIFICACION DE RIESGOS:⚫ ADMINISTRACION DE RIESGOS



2. ANALISIS DE RIESGOS:

Se considera por separado cada riesgo identificado y se decide

acerca de la probabilidad y la seriedad del mismo.

La probabilidad de que el riesgo se valore como muy bajo (<10%),

bajo (10%-25%), moderado (25%-50%), alto (50%-75%), o muy

alto (>75%).

Los efectos del riesgo pueden ser valorados como: catastróficos, serios,

tolerables o insignificantes.


⚫ ADMINISTRACION DE RIESGOS2. ANALISIS DE RIESGOS:

RIESGO PROBABILIDAD EFECTOS

Los problemas financieros de la organización fuerzan a reducir el presupuesto del proyecto Baja Catastrófico

Es imposible reclutar personal con las habilidades requeridas para el proyecto Alta Catastrófico

El personal clave esta enfermo y no disponible en momentos críticos Moderada Serio

Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad Moderada Serio

Se proponen cambios en los requerimientos que requieren rehacer el diseño Moderada Serio

La organización se reestructura de tal forma que una admon. diferente se responsabiliza del proy. Alta Serio

La BD que se utiliza en el sistema no puede procesar muchas transacciones por seg. Moderada Serio

El tiempo requerido para desarrollar el software esta subestimado Alta Serio

Las herramientas CASE no se pueden integrar Alta Tolerable

Los clientes no comprenden el impacto de los cambios en los requerimientos Moderada Tolerable

La capacitación solicitada para el personal no esta disponible Moderada Tolerable

La tasa de reparación de defectos esta subestimada Moderada Tolerable

El tamaño del SW esta subestimado Alta Tolerable

Es ineficiente el código generado por las herramientas CASE Moderada Insignificante



3. PLANEACIÓN DE RIESGOS:

Este proceso considera cada uno de los riesgos claves identificados

en el análisis de riesgos y las estrategias para administrarlos.

Categorías de Estrategias:

1. Estrategias de Anulación: Reducir la probabilidad de que un

riesgo surja

2. Estrategias de Disminución: Reducir el impacto del riesgo

3. Planes de Contingencia: Si sucede lo peor, se esta preparado

para ello

y se cuenta con una estrategia para abordarlo.


⚫ ADMINISTRACION DE RIESGOS3. PLANEACIÓN DE RIESGOS:

RIESGO ESTRATEGIA

Problemas Financieros

de la Organización

Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones importantes a

las metas del negocio

Problemas de

Reclutamiento

Alertar al cliente de las dificultades potenciales y las posibilidades de retraso, investigar los componentes comprados

Enfermendad del

Personal

Reorganizar el equipo de tal forma que haya traslapes en el trabajo y las personas comprendan el trabajo de los demás

Componentes

Defectuosos

Reemplazar los componentes defectuosos con los comprados de fiabilidad conocida

Cambios en los

requerimientos

Rastrear la información para valorar el impacto de los requerimientos, maximizxar la información oculta en ellos

Reestructuración

Organizacional

Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy

importantes a las metas del negocio.

Desempeño de la Base

de Datos

Investigar la posibilidad de comprar una base de datos con alto desempeño

Tiempo de Desarrollo

Subestimado

Investigar los componentes comprados y la utilización de un generador de programas



4. SUPERVISION DE RIESGOS:

Valora cada uno de los riesgos identificados para decidir si son más o

menos probables y cuando los efectos de los mismos han cambiado.

Se tienen que buscar otros factores para dar indicios de la probabilidad

Del riesgo y sus efectos.

Estos factores dependen de los tipos de riesgo.



4. SUPERVISION DE RIESGOS:

TIPO DE RIESGO INDICADORES POTENCIALES

TECNOLOGÍA Entrega retrasada del HW o de la ayuda al SW, muchos problemas

tecnológicos reportados

PERSONAS Baja moral del personal, malas relaciones entre los miembros del equipo,

disponibilidad de empleo.

ORGANIZACIONAL Chismorreo organizacional, falta de acciones por el administrador principal

HERRAMIENTAS Rechazo de los miembros del equipo para utilizar herramientas, quejas

acerca de las herramientas CASE, peticiones de estaciones de trabajo más

potentes.

REQUERIMIENTOS Peticiones de muchos cambios en los requerimientos, quejas del cliente

ESTIMACIÓN Fracaso en el cumplimiento de los tiempos acordados y en la eliminación de

defectos reportados.

Documents

INGENIERIA DE SOFTWARE AVANZADA