Ingeniería de Software

Unidad I

Gestión de Proyectos de Software

Planificación de la gestión de proyectos de software

Tema

Semana 5

Objetivos Generales:

Comprender correcta y eficientemente los conceptos y principios del espectro de técnicas de Ingeniería de Software que puedan ser aplicadas en proyectos de software.

Desarrollar una cultura de ingeniería de software.

Objetivos Específicos:

Aplicar correctamente los conceptos y principios relacionados a la Ingeniería de Software en la resolución de casos prácticos para la gestión de proyectos de software de calidad.

Utilizar herramientas para el modelado y gestión de proyectos de software.

Utilizar metodologías agiles en el desarrollo de software.

Objetivos Instruccionales:

Realizar estimaciones del trabajo a realizar, de los recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización.

Analizar los riesgos para analizar y determinar la probabilidad de que pueda ocurrir.

Objetivos de la planificación del proyecto

• Proporcionar un marco de trabajo que permite al gerente de software hacer una estimación razonable de recursos, costo y planificación temporal.

• Las estimaciones deberían definir los escenarios del “mejor caso” y “peor caso” de forma que los resultados del proyecto puedan limitarse.

• Poner al día las estimaciones así como los progresos del proyecto.

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re

Actividades de la planificación del proyecto de software

1. Determinar el ámbito del software

2. Estimación de los recursos requeridos

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re

Ámbito del software

1. Se describe el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad.

2. Se evalúan las funciones descritas en la declaración del ámbito, y en algunos casos se refinan para dar mas detalle antes del comienzo de la estimación.

3. Las restricciones identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

Es la primera actividad de la planificación del proyecto de software en la cual:

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

Obtención de la información necesaria para el ámbito…

1. Determinar las metas globales del cliente para el sistema propuesto y expectativas por los beneficios.

2. Determinar las percepciones del cliente acerca de la naturaleza de una buena solución al problema.

3. Evaluar la efectividad de la reunión con el cliente.

Es importante para:

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

1. Establecer una reunión o una entrevista preliminar.

2. Realizando una serie de preguntas que lleven a:• Un entendimiento básico del problema,• Determinar porque las personas que están interesadas en

la solución,• Conocer la naturaleza de la solución que se desea.

Como empezar:

…Obtención de la información necesaria para el ámbito…

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

1. ¿Quien esta detrás de la solicitud de trabajo?

2. ¿Quién utilizara la solución?

3. ¿Cuál será el beneficio económico de una buena solución?

4. ¿Hay otro camino para la solución?

Preguntas centradas en el cliente, en los objetivos globales y en los beneficios:

…Obtención de la información necesaria para el ámbito…

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

1. ¿Cómo caracterizaría (el cliente) un resultado correcto que se generaría con una solución satisfactoria?

2. ¿Con que problema(s) se afrontara esta solución?

3. ¿Puede mostrarme (o describirme) el entorno en el que se utilizaría la solución?

4. ¿Hay aspectos o limitaciones especiales de rendimiento que afecten a la forma en que se aborda la solución?

Preguntas centradas en comprender mejor el problema y que el cliente exprese sus percepciones sobre una solución:

…Obtención de la información necesaria para el ámbito…

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

1. ¿Es Usted la persona apropiada para responder a estas preguntas? ¿Son oficiales sus respuestas?

2. ¿Son relevantes mis preguntas para su problema?

3. ¿Estoy realizando muchas preguntas?

4. ¿Hay alguien mas que pueda proporcionar información adicional?

5. ¿Hay algo mas que deba preguntarle?

Preguntas centradas en la efectividad de la reunión:

…Obtención de la información necesaria para el ámbito…

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

La Viabilidad…

Una vez identificado el ámbito, es razonable preguntarse:

1. ¿Podemos construir el software de acuerdo a este ámbito?

2. ¿Es factible el proyecto?

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

DimensiónDimensión IncertidumbreIncertidumbre

Tecnología ¿Es factible un proyecto técnicamente?

¿Esta dentro del estado actual de la técnica?

Financiera ¿Es factible financieramente?

¿Puede realizarse a un coste asumible por la empresa de software y el cliente?

Tiempo ¿Pueden los proyectos adelantarse a los de la competencia?

Recursos ¿La organización cuenta con los recursos suficientes para tener éxito?

…La Viabilidad…P

lan

ifica

ció

n d

e p

roye

cto

s d

e

softw

are

- A

MB

ITO

“Una vez que se ha comprendido el ámbito, tanto el equipo de desarrollo como el resto deben trabajar para determinar si puede ser construido

dentro de las dimensiones especificadas”.

…La ViabilidadP

lan

ifica

ció

n d

e p

roye

cto

s d

e

softw

are

- A

MB

ITO

Ejemplo de ámbito

Nº ID Nº ID Nº ID Nº ID Nº ID Nº ID

MOVIMIENTO DE LA CINTA TRANSPORTADORA

CODIGO DE BARRAS

ESTACION DETRABAJO

MECANISMO DECONTROL

CONEXIÓN DE CONTROL

1

2

3

4

5

6

•Lectura de la entrada del código de barras

•Lectura del tacómetro de pulsos

•Descodificación de los datos del código de pieza

•Búsqueda en la base de datos

•Determinar la posición del compartimiento

•Producción de la señal de control para el mecanismo de maniobra

•Mantener una lista de los destinos de las cajas

FU

NC

ION

ES

Pla

nifi

caci

ón

de

pro

yect

os

de

so

ftwa

re -

AM

BIT

O

Estimación de Recursos…

Personas

Componentes de Software reutilizables

Herramientas

Hardware/Software

Recursos del Proyecto

Cada recurso queda especificado mediante cuatro características:

•Descripción del recurso

•Informe de disponibilidad

•Fecha cronológica en la que se requiere el recurso

•Tiempo durante el que será aplicado el recurso.P

lan

ifica

ció

n d

e p

roye

cto

s d

e

softw

are

- R

EC

UR

SO

S Es la segunda actividad de la planificación del proyecto de software:

A. Recursos humanos:

Se debe tener en cuenta:

• Las habilidades que se requieren para llevar a cabo el desarrollo, especificando la posición dentro de la organización (gestor, Ing. de software experimentado, etc.) como la especialidad (telecomunicaciones, base de datos, etc.).

• El número de personas requeridas para un proyecto de software (personas-mes).

…Estimación de Recursos…P

lan

ifica

ció

n d

e p

roye

cto

s d

e

softw

are

- R

EC

UR

SO

S

B. Recursos de software reutilizables:Se debe tener en cuenta:

1. Componentes ya desarrollados. Puede provenir de la adquisición a un tercero o de uno desarrollado internamente para un proyecto anterior.

2. Componentes ya experimentados. Especificaciones, diseños, código o datos de prueba existentes desarrollados para proyectos anteriores que son similares al software que se va a construir.

3. Componentes con experiencia parcial. Especificaciones, diseños, código o datos de prueba existentes desarrollados para proyectos anteriores que se relacionan con el software que se va a construir, pero requerirá una modificación sustancial.

4. Componentes nuevos. El equipo de software debe construir específicamente para las necesidades del proyecto actual.

…Estimación de Recursos…P

lan

ifica

ció

n d

e p

roye

cto

s d

e

softw

are

- R

EC

UR

SO

S

Directrices a tener en cuenta si se especifican componentes reutilizables:

1. Componentes ya desarrollados. Es preferible adquirirlos si

cumplen los requisitos del proyecto. El coste de adquisición e integración es menor al costo de desarrollo.

2. Componentes ya experimentados. Los riesgos asociados a la modificación y a la integración generalmente se aceptan. El plan de proyecto debe reflejar la utilización de estos componentes.

3. Componentes con experiencia parcial. Su uso se debe analizar con detalle. El coste de modificar los componentes algunas veces puede ser mayor que el coste de desarrollar componentes nuevos.

…Estimación de Recursos…P

lan

ifica

ció

n d

e p

roye

cto

s d

e

softw

are

- R

EC

UR

SO

S

C. Recursos de entorno:Se debe tener en cuenta:

1. La incorporación de hardware y software requeridos. El hardware proporciona una plataforma con las herramientas (software) requeridas para producir los productos que son el resultado de una buena practica de la ingeniería de software.

2. El equipo de software puede requerir acceso a los elementos en desarrollo por otros equipos de ingeniería.

…Estimación de Recursos…P

lan

ifica

ció

n d

e p

roye

cto

s d

e

softw

are

- R

EC

UR

SO

S

Observaciones sobre la estimación…

¿Cuál es la característica mas importante que debe tener un gestor de proyectos?

La estimación de recursos, costes y planificación temporal de un esfuerzo en el desarrollo de software requiere:

• Experiencia.• Acceder a una buena información.• Confiar en las predicciones (medidas) cuantitativas

cuando solo existen datos cualitativos.

“La estimación conlleva a un riesgo inherente y es este riesgo el que lleva a la incertidumbre”

Est

ima

ció

n d

e p

roye

cto

s

• La complejidad del Proyecto:1. Tiene un gran efecto en la incertidumbre, que es inherente

en la planificación. 2. Sin embargo, La complejidad es una medida relativa que se

ve afectada por la familiaridad con esfuerzos anteriores.

• El tamaño del proyecto. 1. Afecta a la precisión y a la eficiencia de las estimaciones.2. Si aumenta el tamaño, se acentúa la interdependencia entre

varios elementos de software. 3. El problema de la descomposición se hace mas difícil

porque los elementos descompuestos pueden todavía excesivamente grandes.

Se debe de tener en cuenta:

…Observaciones sobre la estimación…E

stim

aci

ón

de

pro

yect

os

• El grado de incertidumbre estructural:1. El grado en que los requisitos se han definido. 2. La facilidad con la que pueden subdividirse funciones3. La naturaleza jerárquica de la información que debe

procesarse.

• La disponibilidad de información histórica. 1. Se pueden hacer estimaciones con mayor seguridad.2. Establecer planificaciones para evitar dificultades

anteriores, y así reducir el riesgo total.

Se debe de tener en cuenta:

…Observaciones sobre la estimaciónE

stim

aci

ón

de

pro

yect

os

La estimación del coste y del esfuerzo del software no es exacta, y esta involucra demasiadas variables como:

• Humanas,• Técnicas,• Entorno,• Políticas,

Que pueden afectar al coste final del software y al esfuerzo aplicado para desarrollarlo.

Est

ima

ció

n d

e p

roye

cto

sVariables inmersas

Para realizar estimaciones seguras tenemos las siguientes opciones:

1. Dejar la estimación para más adelante. No es práctica.

2. Basar las estimaciones en proyectos similares ya terminados.. Funciona bien si el proyecto actual es bastante similar a los esfuerzos pasados.

3. Utilizar “técnicas de descomposición” relativamente sencillas para generar las estimaciones de coste de esfuerzo del software.. “Divide y vencerás”

4. Utilizar uno o más modelos empíricos para la estimación del coste y el esfuerzo del software.

d=f(vi) donde d es uno de los valores estimados (esfuerzo, coste,etc) y los vi determinados parámetros independientes (LDC, PF estimados).

Est

ima

ció

n d

e p

roye

cto

s

Estimación orientada al Tamaño del software…

Se basa en:

1. El grado en que el planificador ha estimado adecuadamente el tamaño del producto a construir.

2. La habilidad para traducir la estimación del tamaño en esfuerzo humano, tiempo y dinero.

3. El grado en que el plan del proyecto refleja las habilidades del equipo de software.

4. La estabilidad de los requisitos del software y el entorno

que soporta el esfuerzo de la ingeniería de Software.

Est

ima

ció

n d

e p

roye

cto

s

…Estimación orientada al Tamaño del software

Enfoques para una cuantificación razonable:

1. Tamaño en lógica difusa. Técnicas aproximadas de razonamiento. El planificador debe identificar el tipo de aplicación, establecer su magnitud en una escala cuantitativa y refinarla dentro del rango original.

2. Tamaño en punto de función. El planificador desarrolla estimaciones de características del dominio de información.

3. Tamaño de componente estándar. Se compone de un numero de “componentes estándar” que son genéricos para un área en particular (pantallas, informes, archivos, LDC).

4. Tamaño del cambio. Se utiliza cuando un proyecto comprende la utilización de software existente que se debe de modificar de alguna manera como parte de un proyecto.

Est

ima

ció

n d

e p

roye

cto

s

Estimación basada en el problema

El planificador comienza con un visión limitada para el ámbito del software y desde este estado descompone el software en funciones que se pueden estimar individualmente.

Enfoques:1. Líneas de código (LDC). Esta enfocada en que las funciones

pueden dividirse en subfunciones que podrán asemejarse a entradas de una base de datos histórica.

2. Puntos de Función (PF). Esta enfocada en las características del dominio de la información (entradas, salidas, archivos).

Est

ima

ció

n d

e p

roye

cto

s

Ejemplo: Estimación basada en LDC…

Función LDC estimada

Interfase del usuario y facilidad de control (IUFC)Interfase del usuario y facilidad de control (IUFC) 23002300

Análisis geométrico de dos dimensiones (AG2D)Análisis geométrico de dos dimensiones (AG2D) 53005300

Análisis geométrico de tres dimensiones (A32D)Análisis geométrico de tres dimensiones (A32D) 67006700

Gestión de base de datos (GBD)Gestión de base de datos (GBD) 33503350

Facilidades de presentación grafica de computadora Facilidades de presentación grafica de computadora (FPGC)(FPGC)

49504950

Control de periféricos (CP)Control de periféricos (CP) 21002100

Módulos de análisis del diseño (MAD)Módulos de análisis del diseño (MAD) 84008400

Líneas de código estimadas 33200

LDC optimista = 4600

LDC probable = 6900

LDC pesimista = 8000

LDC estimado = (4600 + 4 x 6900 + 8000 ) / 6 = 6700

Est

ima

ció

n d

e p

roye

cto

s

Una revisión histórica de los datos indica:

• La productividad media es de 620 LDC/pm

• La tarifa laboral es de US$ 8000 por persona-mes

Entonces el coste por LDC es :

8000/620 = 12.90 13.00 US$

El coste total es : 13 x 33200 = 431,600 US$

El esfuerzo estimado es : 33200 / 620 = 54 personas-mes

Ejemplo: Estimación basada en LDC…E

stim

aci

ón

de

pro

yect

os

VALOR DE DOMINIO DE INFORMACION CUENTA PESO CUENTA PF

Numero de entradasNumero de entradas 2424 44 9696

Numero de salidasNumero de salidas 1616 55 8080

Numero de peticionesNumero de peticiones 2222 44 8888

Numero de archivosNumero de archivos 44 1010 4040

Numero de interfases externasNumero de interfases externas 22 77 1414

Cuenta totalCuenta total 318318

Ejemplo: Estimación basada en PFE

stim

aci

ón

de

pro

yect

os

FACTOR (Fi) VALOR

Copia de seguridad y recuperaciónCopia de seguridad y recuperación 44

Comunicación de datosComunicación de datos 22

Proceso distribuidoProceso distribuido 00

Rendimiento criticoRendimiento critico 44

Entorno operativo existenteEntorno operativo existente 33

Entrada de datos en líneaEntrada de datos en línea 44

Transacciones de entrada en múltiples pantallasTransacciones de entrada en múltiples pantallas 55

Archivos maestros actualizados en líneaArchivos maestros actualizados en línea 33

Complejidad de valores del dominio de informaciónComplejidad de valores del dominio de información 55

Complejidad del procesamiento internoComplejidad del procesamiento interno 55

Código diseñado para la reutilizaciónCódigo diseñado para la reutilización 44

Conversión / instalación en diseñoConversión / instalación en diseño 33

Instalaciones múltiplesInstalaciones múltiples 55

Aplicación diseñada para el cambioAplicación diseñada para el cambio 55

PF estimado = cuenta total x ( 0,65 + 0.01 x sumatoria Fi ) => PF = 318 x 1.17 = 375

Ejemplo: Estimación basada en PFE

stim

aci

ón

de

pro

yect

os

Una revisión histórica de los datos indica:

• La productividad media es de 6.5 PF/pm

• La tarifa laboral es de US$ 8000 por persona-mes

Entonces el coste por PF es : 8000/6.5 = 1,230 US$

El coste total es : 1230 x 375 = 461,250 US$

El esfuerzo estimado es : 375 / 6.5 = 58 personas-mes

Ejemplo: Estimación basada en PFE

stim

aci

ón

de

pro

yect

os

La estructura de los modelos de estimación

Típicamente derivado del análisis de la regresión sobre los datos de proyecto de software históricos, con las persona-meses estimados como la variable dependiente y LDC o PF como las variables independientes.

E = A + B x (ev)C

Donde:

E = es el esfuerzo persona-mesA, B y C son constantes obtenidas empíricamente.ev es la variable de estimación de LDC o PF

Mo

de

los

em

pír

ico

s d

e e

stim

aci

ón

La estructura de los modelos de estimación

Fórmula Modelo

E = 5.2 x (MLDC)0.91 Walson – Felix

E = 5.5 + 0.73 x (MLDC)1.16 Bailey – Basili

E = 3.2 x (MLDC)1.05 Boehm

E = -13.39 + 0.0545 PF Alfrech y Gaffney

E = 60.62 x 7.728 x 10-8 PF3 Kemerer

E = 585.7 +15.12 PF Matson, Barnett y Mellichamp

Mo

de

los

em

pír

ico

s d

e e

stim

aci

ón

Mo

de

los

em

pír

ico

s d

e e

stim

aci

ón

Realizar un trabajo de investigación en lo concerniente al modelo COCOMO y

COCOMO II

• Puede ser más eficaz en términos costo-beneficio adquirir un bloque de software en lugar desarrollarlo.

• El análisis de árbol de decisión proporciona una manera sistemática de ordenar la decisión de desarrollar-comprar.

• En el nivel estratégico, los gestores tienen en

consideración si una parte importante de todo el trabajo de software puede ser contratado a otros.

• En el nivel táctico, un jefe de proyecto determina si algunas partes o todo el proyecto es aconsejable realizarlo mediante subcontratación.

De

cisi

ón

de

De

sarr

olla

r -

Co

mp

rar

SISTEMA X

CONSTRUCCION

REUTILIZACION

COMPRA

CONTRATO

SIMPLE (0.30)

DIFICIL (0.70)

CAMBIOS MENORES (0.40)

SIMPLE (0.20)

COMPLEJO (0.80)

CAMBIOS IMPORTANTES (0.60)

CAMBIOS MENORES (0.70)

CAMBIOS IMPORTANTES (0.30)

SIN CAMBIOS (0.60)

CON CAMBIOS (0.40)

US$ 380,000

US$ 450,000

US$ 275,000

US$ 310,000

US$ 490,000

US$ 210,000

US$ 400,000

US$ 350,000

US$ 500,000

Árbol de decisiones…D

eci

sió

n d

e D

esa

rro

llar

- C

om

pra

r

Coste esperado Construcción = 0.30 x 380000 + 0.70 x 450000 = 429,000

Coste esperado reutilización = 0.40 x 275000 + 0.60( 0.20 x 310000 +0.80

x 490000) = 382,000

Coste esperado Compra = 0.70 x 210000 + 0.30 x 400000 = 267,000

Coste esperado Contrato = 0.60 x 350000 + 0.40 x 500000 = 410,000

Según la probabilidad y los costes proyectados, el coste mas bajo es para la opción de compra

De

cisi

ón

de

De

sarr

olla

r -

Co

mp

rar …Árbol de decisiones

Herramientas automáticas de estimación

1. Dimensionamiento de las entregas del proyecto. Se estima el tamaño de uno o mas productos de software, incluyen la representación externa del software (pantallas, informes), el software en si (MLDC), su funcionalidad y la información descriptiva (documentos).

2. Selección de las actividades del proyecto. Se selecciona el marco de trabajo del proceso adecuado y se especifica el conjunto de tareas de IS.

3. Predicción de los niveles de la plantilla. Se especifica el numero de personas disponibles para realizar el trabajo. Dado que la relación entre las personas disponibles y el trabajo no es muy lineal.

Funciones genéricas:

He

rra

mie

nta

s

4. Predicción del esfuerzo del software. Utiliza uno o mas modelos que relacionan el tamaño de las entregas del proyecto con el esfuerzo necesario para producirlas.

5. Predicción del coste del software. Dado los resultados del paso anterior, los costes pueden calcularse asignando proporciones del trabajo a las actividades del proyecto señaladas en el paso 2.

6. Predicción de la planificación del software. Cuando se conoce el esfuerzo, los niveles de plantilla y las actividades del proyecto, se puede realizar un borrador de la planificación asignando el trabajo a través de actividades de IS basados en modelos recomendados para la distribución del esfuerzo.

Herramientas automáticas de estimaciónH

err

am

ien

tas

Funciones genéricas:

SISTEMA COSTAR

• COmputer

• STored

• Ambulatory

• Record

Herramientas automáticas de estimaciónH

err

am

ien

tas

La Ingeniería de Sistemas es difícil. Nunca habrá una respuesta fácil en la solución de problemas de desarrollo de sistemas complejos.

Los Ingenieros de Software no tienen respuesta a todas las preguntas, pero entienden el funcionamiento del sistema.

Se debe de reconocer el papel que juega cada disciplina y cooperar entre todas en el proceso de Ingeniería de Sistemas.

La Ingeniería de Sistema involucra a múltiples disciplinas.

El Proceso de I.S sigue a menudo el modelo de cascada.

Re

sum

en

• La planeación del software involucra estimaciones en cuánto a tiempo, esfuerzo, dinero, y recursos para construir un sistema de software específico.

• Después de que el alcance del proyecto es determinado y el problema se descompone en problemas más pequeños, los gerentes del software usan los datos de proyectos históricos (así como la experiencia personal e intuición) para determinar las estimaciones para cada uno.

• Las estimaciones finales se ajustan típicamente tomando en cuenta la complejidad del proyecto y los riesgos.

• El producto resultante del trabajo se llama plan de dirección de proyecto.

Re

sum

en

Ingeniería de Software

Unidad I

Gestión de Proyectos de Software

Planificación de la gestión de proyectos de software

Tema

Semana 5