You are on page 1of 19

Contenido INGENIERIA DE SOFTWARE Tema 2: Administracin de proyectos de software

Presenta: David Martnez Torres Universidad Tecnolgica de la Mixteca dtorres@mixteco.utm.mx IEC 37


1

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Administracin de proyectos de software Grficas PERT y GANTT Mtricas del proyecto Mediciones del software Mtricas orientadas al tamao (LDC) Modelo de Estimacin de Costos COCOMO Mtricas orientadas a los puntos de funcin Anlisis de riesgos Conclusiones Referencias
2

1. Administracin de proyectos

Lo que puede controlar el administrador de proyectos (Variables de la admon de proyectos)

La administracin de proyectos consiste en gestionar la produccin de un producto dentro del tiempo dado y los lmites de fondos. Requiere recursos humanos Involucra l no slo l la l organizacin tcnica y las l habilidades organizacionales, sino tambin el arte de administrar personas.

El costo total del proyecto Por ejemplo, aumentar los gastos Las capacidades del producto Como eliminar una lista de caractersticas La calidad del producto Como aumentar el tiempo medio entre fallas La duracin del proyecto Por ejemplo, reducir el tiempo programado 20% O posponer un mes la fecha de terminacin

Componentes de la administracin de proyectos

Mapa Conceptual tpico para la administracin de un proyecto


1.

Estructura (elementos organizacionales involucrados) Proceso administrativo (responsabilidades y supervisin de los participantes) Proceso de desarrollo (mtodos, herramientas, lenguajes, documentacin y apoyo) Programa (tiempos en los que deben realizarse las porciones del trabajo)

2.

Comprender el contenido, alcance y marco del tiempo del proyecto Identificar el proceso de desarrollo

(modelos, mtodos, herramientas, lenguajes, documentacin y apoyo) (elementos organizacionales involucrados) (responsabilidades de los participantes) (tiempos en los que deben realizarse las porciones del trabajo) TSP, PSP, CMM, MOPROSOFT

3.

Determinar la estructura organizacional

4 4.

Identificar el proceso administrativo

5.

Desarrollar una programacin

6.

Desarrollar el plan de personal

7. 8. 9.

Iniciar la administracin de riesgo Identificar los documentos que se producirn Iniciar el proceso

Planeacin de proyectos

2. Grficas PERT y GANTT

Se refiere a la identificacin de actividades, hitos y entregas producidas por un proyecto Para eso, se requiere un plan del proyecto: fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo El plan del proyecto, puede contener otros tipos de planes

Siempre hay plazos, algunos ms ajustados y otros mas holgados. Son exigibles. Responden a compromisos (verbales o escritos) cmo enfrentarlos?

Plan de Plan de Plan de Plan de Plan de

calidad validacin administracin de la configuracin mantenimiento desarrollo del personal

Herramientas para la planeacin de proyectos: PERT, GANTT.

Buena estimacin de tiempo, p , esfuerzo y costos. Especialmente p Ruta Crtica. Se recomienda uso de modelos incrementales. Conversarlos con el Jefe (lograr un acuerdo) y luego con el usuario(s)/cliente lograr un consenso). Afinar la planificacin. Comunicarla : que todos los involucrados la conozcan

Grficas PERT y GANTT


Principios bsicos

Calidad v/s plazos Origen de los retrasos Compromisos poco realistas (presiones). Cambios de requisitos. Subestimacin de esfuerzos y/o recursos requeridos. Errores predecibles e impredecibles no considerados en la planificacin. Dificultades tcnicas imprevistas. Dificultades humanas imprevistas. Falta de comunicacin dentro del equipo del proyecto. Subestimar los retrasos y no administrar medidas correctivas
9

Compartimentacin: El proyecto debe dividirse en un nmero de actividades y tareas manejables. Interdependencia: Cmo dependen unas tareas de otras para su ejecucin? Asignacin g de tiempo: p a cada tarea. Ej. j Personas-da de esfuerzo Validacin del esfuerzo: Verificar que no se ha asignado ms horas de trabajo que las disponibles. Responsabilidades definidas: Cada tarea que se programe debe asignarse a un miembro del equipo especfico. Resultados definidos: Cada tarea programada debe tener un resultado definido. Hitos definidos: Momentos de control global o por mdulo. 10

Camino Crtico

Grficas de barras (GANTT) y redes de actividades (PERT).

Es la secuencia de tareas cuyo atraso provoca atrasos en el fin del proyecto Las herramientas lo calculan automticamente (grafos PERT y Gantt) Una tarea no crtica tiene un margen de tiempo a partir del cual se convierte en crtica Por lo tanto:

El mayor esfuerzo de la estimacin debe ser en las tareas crticas Para comprimir tareas en el cronograma, debe comenzar el anlisis por las tareas crticas
11

Se utilizan notaciones grficas para ilustrar la planificacin del proyecto. Muestra la particin del proyecto en tareas. Las tareas no deben ser muy pequeas. Estas deben de tener una duracin de una semana o dos dos. Las grficas de actividades muestran las dependencias entre tareas y la ruta crtica. Las grficas de barras muestran la planificacin contra el tiempo del calendario de actividades.

12

Diagramas GANTT

Diagramas GANTT

Tcnica de control de proyectos, que puede ser utilizada para Scheduling y Plan de recursos Cada barra representa una actividad Se dibujan contra una lnea de tiempo La longitud de cada barra representa la longitud de tiempo de esa actividad A las tareas se le puede asignar los recursos

Pueden ser derivados automticamente de los grafos PERT Los GANTT ayudan a planear la utilizacin de recursos

13

14

15

16

Grafos PERT

Grafos PERT

Program Evaluation and Review Technique Grafo dirigido etiquetado Los nodos representan actividades y los ejes dependencias Los nodos pueden tener varios tipos de informacin Nombre, fecha de inicio y finalizacin Algunos nodos pueden ser definidos como milestones (hitos, puntos de control)

Que se puede calcular? Fecha ms temprana y tarda de comienzo Fecha ms temprana y tarda de finalizacin Se puede determinar el camino crtico de un proyecto Ventajas de los grafos PERT Fuerza al lder del proyecto a planear (debe definir que tareas son necesarias) Expone claramente las actividades crticas del proyecto Expone paralelismo de tareas y por lo tanto ayuda a la asignacin de recursos Permite al lder del proyecto a monitorear y controlar el proyecto

17

Los PERT son mejores para monitorear el progreso y el retraso de las actividades 18

Ejemplo 1. PERT

Ej 2. PERT

19

20

21

22

Hitos en el proceso de requerimientos

23

24

3. Introduccin Mtricas

3. Introduccin Mtricas

Medicin proceso por el cual nmeros smbolos son asignados a atributos de entidades en el mundo real, de manera semejante como se les atribuye

reglas definidas

Mtricas son estndares (i.e., escalas comunmente aceptadas) que definen atributos medibles de entidades, sus unidades y sus alcances Medida es una relacin entre un atributo y una escala de medicin

3. Introduccin Mtricas

Mtricas del proceso

Las mtricas de software son medidas que se usan para cuantificar el software, los recursos del desarrollo de software, y/o el proceso de desarrollo de software. Esto incluye elementos que son medibles de forma directa, tal como las lneas de cdigo, as como tambin elementos que son calculados de mediciones, tal como la calidad del software.

Se puede aplicar al proceso con la intencin de mejorarlo La eficacia de un proceso de sw se mide indirectamente. Se extrae un conjunto de mtricas de los resultados que provienen del proceso

Errores detectados antes de la entrega del sw Defectos detectados e informados por los usuarios finales Productos de trabajo entregados Esfuerzo humano y tiempo consumido

Mtricas del proceso


Mtricas del proyecto

PSP, TSP, CMM, MOPROSOFT Las mtricas del proceso de software se utilizan para propsitos estratgicos

En el proyecto se puede aplicar para ayudar a:

Estimar costos Control de calidad Evaluacin de productividad Control de proyectos

Finalmente para evaluar la calidad de productos tcnicos para ayudar en la toma de decisiones tcticas a medida que el proyecto evoluciona.

Mtricas del proyecto

Mtricas del proyecto

Las mtricas del proyecto son tcticas

Durante el trabajo tcnico, se tienen otras mtricas

Esto es, las mtricas de proyectos y los indicadores derivados de ellos los utiliza un gestor de proyectos y un equipo de sw para adaptar el flujo de trabajo del proyecto y las actividades tcnicas

ndices de produccin: pginas de documentacin, horas de revisin, puntos de funcin y lneas fuentes entregadas Minimizar la planificacin de desarrollo Evaluar la calidad de los productos en el momento actual

La primera aplicacin de las mtricas de proyectos de sw ocurre durante la estimacin, para esto se utilizan las mtricas de proyectos anteriores Estimaciones del esfuerzo y del tiempo para el trabajo actual
31

Las mtricas para el proyecto se utilizan para:


Porqu usar mtricas?

Sin mediciones no hay forma de determinar si el proceso esta mejorando. Las mtricas permiten el establecimiento de metas significativas para la mejora. Se puede establecer una lnea de inicio de la cual las mejoras pueden ser medidas Las mtricas permiten identificar las causas de defectos que tienen mayores efectos en el desarrollo de software Cuando se aplican mtricas a un producto pueden ayudar a identificar:

Que requerimientos del usuario son probables de cambiar Que mdulos son ms propensos a errores Cuanta prueba debera ser planeada para cada modulo

Quienes se benefician de las mtricas?

4. Medicin Directa e Indirecta

Administradores

Que cuesta cada proceso? Que tan productivo es el personal? Que tan bueno es el cdigo que esta siendo desarrollado? Estar satisfecho el usuario con el p producto? Como podemos mejorarlo? Son comprobables los requerimientos? Se han encontrado todas las fallas? Conocemos las metas del producto o proceso? Que podemos predecir de nuestro producto software en el futuro?
35

Ingenieros

La medicin directa de un atributo de una entidad no involucra otros atributos o entidades La medicin indirecta es til en hacer visible la interaccin entre mediciones directas La medicin d indirecta d es favorable f bl cuando d el l tamao de medidas empricas es bastante grande (i.e., muchas relaciones y muchas entidades)

36

Mtricas simples orientadas al tamao


5. Tamao del software

Errores por KLDC (miles de lneas de cdigo) Defectos por KLDC Pginas de doc. Por KLDC Errores/persona-mes LDC/persona mes

Uno de los atributos ms tiles es el tamao de un producto software, que puede ser medido estticamente, i.e., sin ejecutar el sistema Es necesario definir el tamao del sw., en trminos de ms de un atributo interno interno, que cada uno capture un aspecto clave del tamao del sw. La medicin del tamao debe reflejar esfuerzo, costo

y productividad.

38

Tamao del software

Tamao del sw.: Longitud

El tamao del sw., puede ser descrito por la longitud, funcionalidad y complejidad. Longitud es el tamao fsico del producto. Funcionalidad es una medida de las funciones

suministradas al producto Complejidad es un atributo que puede ser interpretado de muchas maneras

Reuso tambin es un atributo que tiene que ver con el tamao, especficamente la cantidad o tamao de reuso dentro de un programa
39

En el desarrollo de sw., hay tres productos principales de desarrollo: especificacin, diseo y codificacin La longitud de la especificacin puede indicar cunto tiempo se necesita para que se realice el diseo, qu a su vez es un predictor de longitud del cdigo. cdigo Tradicionalmente, la longitud de cdigo se refiere a la longitud de cdigo basado en texto.

40

Longitud: Cdigo-LOC

Longitud: Problemas - Cdigo

La medida ms comnmente usada de la longitud del programa fuente es el nmero de lneas de cdigo (LOC)

NCLOC CLOC

Longitud total:

(LOC) = NCLOC + CLOC

Conforme el desarrollo de software utiliza ms herramientas automatizadas, la medicin de lneas de cdigo es cada vez menos significativa Herramientas que generan cdigo a partir de p especificaciones Herramientas de programacin visual Cual puede ser la medida de longitud para objetos que no son textuales? Como puede uno contar componentes que son construidos externamente? (libreras, repositorios, funciones heredadas, patrones de diseo, etc.)
42

41

Longitud: Problemas - Cdigo

Resumen: Tamao del Software

La medicin del tamao LOC necesita ser reemplazada por otras medidas tales como:

Puntos de objetos (usados en COCOMO 2.0) Medir la longitud tomando en cuenta la porcin de cdigo reutilizado

Las mtricas orientadas al tamao son medidas directas del software. Esas mtricas incluyen esfuerzo (personas-tiempo), dinero gastado, LOC, # de pginas de documentos creados, errores y nmero de personal La medida bsica para la longitud es LOC. Las mtricas simples orientadas al tamao pueden ser generadas de LOC como sigue: Productividad = KLOC/persona-mes Calidad = defectos/KLOC Documentacin = pginas de documentos / KLOC
44

43

Modelos del COCOMO


6. Modelo de estimacin de costos COCOMO

COCOMO (Constructive Cost Model) (Boehm, 1981): Es un modelo que se basa en entradas que relacionan al tamao del sistema y un nmero de conductores de costo que afectan la productividad COCOMO II, la versin actualizada, considera cambios en la tecnologa de ingeniera de sw, incluyendo sw OO, sw creado va modelos de desarrollo evolutivos o espiral, reuso de sw y nuevas construcciones de sistemas usando componentes sw del estante (COTS-Commercial off the shelf)
45

Modelo bsico. Se aplica cuando se conoce poco del proyecto. El esfuerzo (persona-mes) se calcula en funcin del tamao del programa (KLOC) Modelo intermedio. Se aplica despus de la adquisicin de requerimientos. Calcula el esfuerzo como una funcin del tamao del programa y un conjunto de conductores de costo (para el producto producto, hw, personal y proyecto) Modelo avanzado. Se aplica despus de que el diseo es completado. Calcula el esfuerzo en funcin del tamao del programa y un conjunto de conductores de costo valorados en cada fase del ciclo de vida del software.
46

Tipos de proyectos del COCOMO

Frmula para los tres modelos COCOMO


E = aS b F

tiende a usar base de datos y se centra en operaciones y recuperacin de datos. Ej. Sistemas de contabilidad o bancarios Modo empotrado: Contiene sw de tiempo real, que es parte integral de sistemas grandes, basados en hw. Ej. sistema de misiles guiados, sw de control de navegacin para un avin. Modo semi-acoplado: Algn sistema entre orgnico y empotrado. Ej. Un sistema de procesamiento de transacciones con requisitos fijos para un hw de terminal, un sw de gestin de base de datos.
47

Modo orgnico: involucra procesamiento de datos,

T = cE d

Donde: E es el esfuerzo en persona-mes T es el tiempo de desarrollo S es el tamao medido en KLOC F es el factor de ajuste del esfuerzo (1 en el modelo bsico) Los factores a, b dependen del tipo de modelo de COCOMO, y los factores c y d dependen del tipo de proyecto
48

COCOMO: Bsico

COCOMO: Intermedio

El factor de ajuste del esfuerzo (F) vale 1 en este modelo Valores de los factores a, b, c y d|

El factor de ajuste del esfuerzo (F) se calcula usando 15 conductores de costo Valores de los factores a, b, c y d

Modo Orgnico Semi-acoplado Empotrado

a 2.4 3.0 3.6

b 1.05 1.12 1.20

c 2.5 2.5 2.5

d__ 0.38 0.35 0.32

Modo Orgnico Semi-acoplado Empotrado

a 3.2 3.0 2.8

b 1.05 1.12 1.20

c 2.5 2.5 2.5

d__ 0.38 0.35 0.32

49

50

COCOMO: Intermedio

Conductores de costos

Conductores de costo:

atributos del producto, del hardware, del personal y del proyecto

Atributos del producto


Cada conductor de costo es valorado en una escala ordinal de 0-5:

RELY Required software reliability DATA Database size CPLX Product complexity

very low, l low, l nominal, i l high, hi h very high hi h y extra t high. hi h

Basado en la valoracin, se determina el multiplicador de esfuerzo (ME) a partir de las tablas publicadas por Boehm, 1981. El producto de todos los multiplicadores de esfuerzo es (F)

Atributos del hardware


F =

15

ME

i
51

TIME STOR VIRT TURN

Execution time constraint Main store constraint Virtual machine volatility Computer turnaround time
52

i =1

Conductores de costos

Atributos del personal


ACAP AEXP PCAP VEXP LEXP

Analyst capability Applications experience Programmer capability Virtual Machine experience Language experience

Atributos del proyecto


MODP Modern programming practices TOOL Software tools SCED Development schedule
53 54

55

56

COCOMO: Avanzado

Ejemplo

Las 4 fases usadas en el modelo detallado de COCOMO son: planeacin de requerimiento y diseo del producto (RDP), diseo detallado (DD), pruebas de cdigo y por unidad (CUT), e integracin y pruebas (IT) Cada conductor de costo se descompone por cada fase como se ve en la tabla La estimacin realizada para cada mdulo se combinan en subsistemas y eventualmente se estima todo el proyecto
valor very Low low Nominal High Very High RDP 1.80 0.85 1.00 0.75 0.55 DD 1.35 0.85 1.00 0.90 0.75 CUT 1.35 0.85 1.00 0.90 0.75 IT 1.50 1.20 1.00 0.85 0.70
57

Conductor de costo ACAP(Analyst Capability)

Para predecir el esfuerzo requerido para implementar el sw para un mejor sistema de conmutacin telefnica, se ha determinado que el sistema requerir 5000 KLOC. El software es empotrado, dado que es un sistema de tiempo real, real que es parte de un gran sistema hw complejo. Determine el esfuerzo y la duracin utilizando COCOMO, as como, el nmero de personas en el total del tiempo de desarrollo.

58

7. Mtricas orientadas a la funcin

La funcionalidad es otro atributo del tamao del sw. La idea es que un producto con ms funcionalidad ser ms grande en tamao. Estas mtricas son medidas indirectas del sw., que se centran en la funcionalidad y la utilidad Las 1er Mtrica orientada a la funcin fue propuesta por Albrecht (19791983) quien sugiri una aproximacin a la medicin de la productividad llamado el mtodo de Punto de Funcin (FP) Los puntos de funcin (FPs) miden la cantidad de funcionalidad en un sistema basado en la especificacin del sistema

Estimacin antes de la implementacin

59

60

Punto de Funcin (FP) /1


Se componen de medidas directas denominadas puntos de funcin, tales como :

External Inputs (Entradas externas) External Outputs (Salidas externas) External Inquiry (Consultas externas) Internal Logical File (Archivo lgico interno) External Interface File (Archivo de interfase externa)

61

62

Punto de Funcin (FP) /2

Conteo de FP Sin ajustar (UFC)

Los Puntos de Funcin se calcula en dos pasos:

Clculo de los Puntos de Funcin Sin Ajustar(UFC, Unadjusted Function point Count) Clculo del Factor Tcnico de Complejidad(TCF, Technical Complexity Factor)

El punto de funcin final (ajustado) es:

Se listan todos los tipos de funcin encontrados en el sistema Se le asigna a cada tipo de funcin una complejidad(baja, media o alta), con su correspondiente valor en puntos de funcin funcin. Se suman todos los puntos de funcin, dando como resultado los puntos de funcin sin ajustar.

FP=UFC*TCF

63

64

Ej. Resultados de los puntos de funcin sin ajustar


Internal Logical Files
Selected Parts File Selected Parts Table Parts Master File low low low low low lo avg avg low low low high 7 7 5 3 3 5 5 4 3 3 6 51

Valores de los puntos de funcin

External Interface File External Inquiries External Outputs


Parts Description Pa ts In Parts Inventory ento

External Inputs

Parts Inventory Report Control Report Control Report Summary

Ej. si todas la funciones tienen complejidad media tendremos: UFC = 4*T_EI+5*T_EO+4*T_EQ+10*T_EIF+7*T_ILF

Add Part Remove Part Create Selected Parts File Total

65

66

Complejidad
Determinado por:

Data Element Types (DET's)

Los DET's son campos que no se repiten, reconocibles por el usuario, contenidos en el ILF

Data Element Types (DETs) Record Element Types (RETs)

Ej. Los campos fsicamente almacenados en campos mltiples (como nmeros de cuenta, fechas, hora) deberan ser contados como un campo cuando el usuario se refiere a ellos como un elemento.

67

68

Componente funcional EI

Ejemplos EIs

El conteo se hace para las siguientes categoras, como procesos elementales: External Inputs (EI): Los datos cruzan los lmites de afuera hacia adentro. Estos datos pueden venir de una pantalla de entrada o de otra aplicacin aplicacin. Los datos son usados para mantener uno o ms archivos lgico internos (ILFs). Los datos pueden ser datos orientados a la aplicacin informacin de control. Si los datos son info. de control, no se tiene que actualizar un ILF

69

Ejemplos EIs

Ejemplo: External Input


Sistema de Inventario

A/B/C
inventario

Parte: ________________________ Descripcin: _______________ Origen: _________________ Cantidad: _______________ Precio: _____________ Colocacin: ______________ Mensaje ____________________________

auditoria

72

Ejemplos EIs

Matriz de Entradas de Usuario

74

Conteo de External Input

Componente funcional EO

Contar todos los elementos de datos nicos o archivos lgicos usados. No incluir nmeros de pginas, literales o encabezados de columnas en la cuenta de elementos de datos. Contar un solo DET para todos los campos que muestren mensajes de error (o mensajes de confirmacin), campos de control o almacenamiento multiple del mismo campo de datos. El conteo de los puntos de funcin es una medida estadstica. Se basa en un gran nmero de observaciones diferentes.
75

External Outputs (EO): Los datos derivados cruzan los lmites de adentro hacia fuera. Los datos crean reportes o archivos de salida enviados a otras aplicaciones. Estos reportes y archivos son creados de uno o mas ILFs o archivos de interfase externos (EIF s). (EIFs) Los datos derivados son datos que son procesados ms all de la edicin directa de informacin de ILFs. Los datos derivados son usualmente el resultado de algoritmos o clculos. Los datos derivados ocurren cuando uno o ms elementos de datos son combinados con una frmula para generar o derivar elementos de datos adicionales

Ejemplos EOs

Ejemplos EOs

Ejemplo: External Ouput

Anlisis de la EO anterior.

tarifas

ahorros

empleados

Impuestos

seguros
79

Un reporte tpico de nmina accedera a mas de 3 archivos de negocios (archivo de empleados, de tasas, de seguros, de ahorros, de tarifas de salarios). El total para los campos tasas, seguros, pago bruto, pago neto ya determina que el tipo de funcin es una EO. La EO tendra 15 DET DET's s y ms de 3 RET's, RET s, por tanto se clasifica como complejidad high. Los DET's incluiran todas las 8 columnas. Adicionalmente, el total de una columna se cuenta como un DET separado. Adems la fecha y el campo departamento se incluiran en el conteo de los DET's. Sin embargo el nmero de pgina no se contara como un DET separado. Los diferentes formatos de impresin causados por las diferentes caractersticas de las impresoras no se contaran como EO's separadas.
80

Matriz de Salidas de Usuario

Componente funcional EQ

External Inquiry (EQ): Todas las

combinaciones de entradas/salidas que resultan de la adquisicin de datos de uno o ms ILFs o EIFs. El proceso de entrada no actualiza ningn ILF, y el proceso de salida no contiene datos derivados.
Nota: los campos totales de un DET son contados como un nico DET de su propio campo. Esta interpretacin est bajo Debate.
81

Ejemplos EQ

Ejemplos EQ

Ejemplo: Consulta simple

Ejemplo: Consulta compleja

85

86

Complejidad EQ

Matriz de Entradas de Usuario


Ejemplo Lado EI low L d EO average Lado EQ average

Determinar la complejidad del lado de entrada EI Determinar la p j del lado complejidad de salida EO La complejidad de EQ es la ms alta de las dos

87

88

Matriz de Salidas de Usuario

Punto de Funcin (FP) /4

El conteo se hace para las siguientes categoras: Internal Logical File (ILF) : Un ILF es un grupo de datos definidos por el usuario que estn relacionados lgicamente, que residen en su totalidad dentro de los lmites de la aplicacin y que son actualizados a travs de entradas externas. External Interface File (EIF): Un EIF es un grupo de datos definidos por el usuario que estn relacionados lgicamente y que solo son usados para propsitos de referencia. Los datos residen enteramente fuera de la aplicacin y son mantenidos por otra aplicacin. Este archivo(s) es un ILF para otra aplicacin

Nota: los campos totales de un DET son contados como un nico DET de su propio campo. Esta interpretacin est bajo Debate.
89 90

Complejidad ILF y EIF

Record Element Type (RET)


Subgrupo de elementos de datos en ILF Reconocibles por el usuario Ningn proceso elemental propio Tipos

Obligatorio Opcional

En la prctica sin embargo, las mayora de ILFs tendrn solo un tipo de RET y menos de 50 DETs. Por tal razn, las reglas de conteo NEFPUG han reducido la matriz de complejidad ILF al primer rengln.
91

Contar 1 RET por subgrupo

92

Ejemplo

FP: Ejemplo /1

Espec., de un corrector ortogrfico: El corrector acepta como entrada un archivo con el documento y un archivo del diccionario personal opcional. El corrector, lista todas las palabras que no estn contenidas en alguno de los archivos archivos. El usuario puede consultar el nmero de palabras procesadas y el nmero de errores ortogrficos encontrados en alguna etapa durante el procesamiento.

93

94

Especificacin de un Corrector Ortogrfico

FP: Ejemplo /1(cont...)

Ni=2 (EI): nombre del archivo del documento, nombre del


diccionario personal palabras procesadas en el mensaje, nmero de errores en el mensaje Nq=2 Nq 2 (EQ): palabras procesadas, errores encontrados Nef=2 (EIF): archivo del documento, diccionario personal Nif=1 (ILF): diccionario
UFC=4x2+5x3+4x2+10x2+7x1=58

No=3 (EO): reporte de palabras incorrectas, nmero de

Suponer que:
F1=F2=F6=F7=F8=F14=3; F4=F10=5 y el resto son cero. TCF=0.65+0.01(18+10)=0.93 FP=58x0.9354

95

Factores tcnicos de Complejidad

Factores tcnicos de Complejidad

TCF es una suma de pesos de 14 componentes:


F8 Actualizacin On-line F9 Procesamiento complejo F10 Reusabilidad F11 Facilidad de Instalacin F12 Facilidad operacional F13 Multiples sitios F14 Facilidad de cambios

Cada componente tiene un rango de 0-5


F1 Comunicacin de los datos F2 Procesamiento distribuido F3 Rendimiento F4 Configuracin del equipo F5 Volumen de transacciones F6 Entrada de datos On-line F7 interfase con el usuario

0 1 2 3 4 5

= = = = = =

No influencia Incidental (poco, accidental) Moderado Medio Significativo Esencial

El TCF puede ser calculado como: 14


TCF = 0.65 + 0.01 Fj
j =1

97

EL TCF vara de 0.65 (si todos los Fj son asignados a cero) a 1.35 (si todos los Fj son asignados a 5)

98

Factores tcnicos de Complejidad

Factores tcnicos de Complejidad


6. Captura de datos En Lnea 7. Eficiencia del usuario final 8. Actualizacin En Lnea

Cuntas herramientas de comunicacin hay para ayudar en la transferencia o intercambio de informacin de la aplicacin o sistema?

1. Comunicacin de datos

Qu porcentaje de informacin se captura En Lnea?

Cmo son manejados los datos distribuidos y las funciones de procesamiento?

2. Procesamiento de datos distribuidos 3. Nivel de ejecucin

Se dise la aplicacin pensando en la eficiencia del usuario final?

Cuntos ILFs se actualizan en transacciones En Lnea?

El tiempo de respuesta o el nivel de eficiencia es requerido por el usuario?

9. Procesamiento complejo 10. Reusabilidad

Qu tanto se usa la plataforma de hardware en donde la aplicacin se va a ejecutar?

4. Configuracin ms usada 5. Nivel de transacciones

La aplicacin tiene mucho procesamiento lgico o matemtico?

La aplicacin se desarroll para cumplir una o muchas necesidades del usuario?


99 100

Qu tan frecuentemente se ejecutan las transacciones al da, semana, mes, etc.?

Factores Tcnicos de Complejidad

8. Anlisis de Riesgos

11. Facilidad de Instalacin 12. Facilidad de Operacin 13. Mltiples Sitios

Qu tan difciles son la conversin y la instalacin?

Qu tan efectivos y/o automatizados son los procedimientos de inicio, respaldo y recuperacin?

La aplicacin se dise, desarroll y soport especficamente para ser instalada en mltiples sitios para varias organizaciones?

14. Facilidad de mantenimiento

La aplicacin se dise, desarroll y soport especficamente para facilitar el mantenimiento?

Una tarea importante del administrador de proyectos es anticipar los riesgos que podran afectar la programacin del proyecto o la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. riesgos Los resultados del anlisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el anlisis de consecuencias cuando el riesgo ocurra. Identificarlos y crear planes para minimizarlos, se le llama administracin de riesgos.

Manejo de Riesgos

Categoras de Riesgos

La tarea principal del administrador consiste en minimizar riesgos. El riesgo inherente en una actividad se mide en base a la incertidumbre que presenta el resultado de esa actividad. actividad Las actividades con alto riesgo causan sobre-costes en cuanto a planeacin y costos El riesgo es proporcional al monto de la calidad de la informacin disponible. Cuanto menos informacin, mayor el riesgo.
103

RIESGOS DEL PROYECTO. Afectan la calendarizacin o los recursos del proyecto. RIESGOS DEL PRODUCTO: Afectan la calidad o desempeo del software que se est desarrollando. RIESGOS SGOS DEL NEGOCIO: GOC O Afectan f a la l organizacin que desarrolla el software.

Riesgos posibles en el Software


RIESGO Rotacin de personal Cambio de administracin No disponibilidad del hardware Cambio de requerimientos Retrasos en la especificacin Subestimacin del tamao Bajo desempeo de la herramienta CASE Cambio de tecnologa Competencia producto del TIPO DE DESCRIPCIN RIESGO Proyecto Personal con experiencia abandona el proyecto antes de que finalice Proyecto Habr un cambio de administracin organizacional con diferentes prioridades Proyecto El hardware esencial para el proyecto no ser entregado a tiempo Proyecto y Habr ms cambios en los requerimientos que lo producto anticipado. Proyecto y Las especificaciones de las interfaces esenciales no producto estarn a tiempo. Proyecto y El tamao del sistema se ha subestimado. producto Producto Las herramientas CASE que ayudan al proyecto no tienen el desempeo anticipado Negocio La tecnologa fundamental sobre la que se construir el sistema se sustituye por nueva tecnologa. Negocio Un producto competitivo se pone en venta antes de que el sistema se acomplete

Riesgos y tipos de riesgos


TIPO DE RIESGOS POSIBLES RIESGO Tecnologa La base de datos que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba. Los componentes de software a reutilizarse contienen defectos que limitan la funcionalidad. Personas Es imposible reclutar personal con las habilidades requeridas para el proyecto. El personal clave est enfermo y no disponible en momentos crticos. p solicitada p para el p personal no est disponible. p La capacitacin Organizacio La organizacin se reestructura de tal forma que una administracin diferente nal se responsabiliza del proyecto. Los problemas financieros de la organizacin fuerzan a reducciones en el presupuesto del proyecto. Herramient Es ineficiente el cdigo generado por las herramientas CASE. as Las herramientas CASE no se pueden integrar. Requerimie Se proponen cambios en los requerimientos que requieren rehacer el diseo. ntos Los clientes no comprenden el impacto de los cambios en los requerimientos. Estimacin El tiempo requerido para desarrollar el software est subestimado. La tasa de reparacin de defectos est subestimada. El tamao del software est subestimado.

Anlisis de Riesgos Riesgos y tipos de riesgos

TIP O

RIESGO

PROBABILIDA D

EFECTOS

O P P T R O T E H R P E E H

Los problemas financieros de la organizacin fuerzan a reducciones en el Baja presupuesto del proyecto. Es imposible reclutar personal con las habilidades requeridas para el Alta proyecto. El personal clave est enfermo y no disponible en momentos crticos. Moderada Los componentes de software a reutilizarse contienen defectos que limitan Moderada la funcionalidad. Se proponen cambios en los requerimientos que requieren rehacer el Moderada diseo. La organizacin i i se reestructura de d tal l forma f que una administracin d i i i Alta l diferente se responsabiliza del proyecto. La base de datos que se utiliza en el sistema no puede procesar muchas Moderada transacciones por segundo como se esperaba. El tiempo requerido para desarrollar el software est subestimado. Alta Las herramientas CASE no se pueden integrar. Alta Los clientes no comprenden el impacto de los cambios en los Moderada requerimientos. La capacitacin solicitada para el personal no est disponible. Moderada La tasa de reparacin de defectos est subestimada. Moderada El tamao del software est subestimado. Alta Es ineficiente el cdigo generado por las herramientas CASE. Moderada

Catastrfico Catastrfico Serio Serio Serio Serio i Serio Serio Tolerable Tolerable Tolerable Tolerable Tolerable
Insignificante

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 catastrficos serio catastrficos, serio, tolerable o insignificante insignificante.

9. Conclusiones

9. Conclusiones

La planificacin temporal es de suma importancia para llevar un control de la terminacin a tiempo de la tareas de un proyecto. Las herramientas PERT y GANTT ayudan a la realizacin de la planificacin temporal PERT, para monitorear el progreso y el retraso de las actividades, tomando como base la ruta crtica GANTT, ayudan a planear la utilizacin de recursos, as tambin, muestra de forma grfica el calendario del proyecto.
109

Las mtricas de software es una parte de la Ingeniera de software que proporcionan productos cuantitativos orientados a medidas de caractersticas de sistemas de informacin, as como sus procesos de desarrollo y operacin. Permiten la estimacin de esfuezo, duracin, productividad, calidad, documentacin, as como tambin costo de desarrollo del sw. En todo desarrollo de software, siempre es indispensable hacer un presupuesto para desarrollar, comprar o aplicar outsourcing
110

9. Conclusiones

10. Referencias
1.

Hemos visto que el mtodo de Puntos de Funcin y COCOMO se complementan. Mientras COCOMO mediante LDC y otros parmetros calcula el esfuerzo y duracin, los puntos de funcin mediante funciones de usuario calcula puntos de funcin ajustados, los cuales para cierto lenguaje de programacin le corresponde un nmero de LDC LDC, que son la entrada para COCOMO. Debido a que los mtodos COCOMO y FP son mtodos comnmente usados por la comunidad de mtricas de software; la mayora de herramientas como BYL, COSMOS, COSTAR, Jmetric, etc., contienen estos dos mtodos.

Pressman, S Roger (1998) Ingeniera del Software: Un enfoque prctico, 4a edicin

2.

3.

McGraw-Hill. Somerville, Ian (2002) Ingeniera de software. 6a edicin. Addison Wesley. Braude Eric J. (2003) Ingeniera de Software Una perspectiva orientada a objetos, Alfaomega

111

112

10. Referencias
1.

2.

3.

4.

Software Metrics: A Rigorous and Practical Approach, (2nd ed.) (638p.), N.E. Fenton and S.L. Pfleeger, PWS Publishing, 1998. Eric J. Braude. (2003) Ingeniera de Software: una perspectiva orientada a objetos. objetos Alfaomega Alfaomega, Mxico Roger S. Pressman. (2005) Ingeniera de software. Un enfoque prctico. 6 edicin, McGraw Hill, Mxico Ian Somerville (2002) Ingeniera de Software. 6 edicin, Addison Wesley, Mxico

Preguntas? Gracias!

114

You might also like