Unidad II: Planificacin del Sistema

2.1. Planificacin del tiempo 2.2. Evaluacin del costo beneficio 2.3. Estudio de viabilidad 2.4. Planificacin de la documentacin 2.5. Gestin de la configuracin del software(GCS)

                    

2.1. Planificacin del tiempo 2.1.1. Mtodos de planificacin temporal 2.2. Evaluacin del costo beneficio 2.2.1. Mtricas de Software 2.2.2. Estimacin del proyecto del software 2.2.2.1. Tcnicas para la estimacin de Software 2.2.2.2. Modelos de estimacin 2.2.2.3. La desicin a desarrollar o comprar 2.2.2.4. Herramientas automticas de estimacin 2.2.3. Evaluacin del costo beneficio 2.2.3.1. Mtodos para el anlisis Costo/Beneficio 2.3. Estudio de viabilidad 2.4. Planificacin de la documentacin 2.5. Gestin de la configuracin del software(GCS) 2.5.1. Planificacin de la GCS 2.5.2. El proceso de gestin de la configuracin del software 2.5.2.1. Identificacin de objetos en la GCS 2.5.2.2. Control de versiones 2.5.2.3. Control de cambios 2.5.2.4. Auditoria de la configuracin 2.5.2.5. Informes de estado

Introduccin: Gestin de proyectos



La gestin de proyectos de software se hace necesaria ya que todo proyecto esta sujeto a restricciones de presupuesto y tiempos. La gestin permite asegurar que el software se lleve a cabo a tiempo y de acuerdo con los requerimientos especificados.

Introduccin: Gestin de proyectos



La gestin del software es particularmente difcil, algunas de las razones son: El producto de software es intangible. No hay un proceso estndar. A menudo los proyectos de software grandes son nicos. Las de las actividades comunes de la gestin de proyectos software son: Redaccin de la propuesta. Planificacin del proyecto Estimaciones de costo, tiempo y esfuerzo. Supervisin y revisin del proyecto. Seleccin y evaluacin del personal. Redaccin y presentacin de informes.

Que es la Planificacin


Es una gua de desarrollo para cumplir las metas del proyecto. Es un proceso iterativo el cual termina hasta que el proyecto mismo haya terminado. Esto quiere decir que su revisin es continua, ya que tanto requerimientos como restricciones pueden cambiar a lo largo del desarrollo

Importancia de la Planificacin


El xito o fracaso de un proyecto de software depende en gran parte de la planificacin, ya que con ayuda de sta se pueden evitar problemas a los que un proyecto est sujeto, tales como:

Retraso de tiempo de entrega Sobrepasar el presupuesto Baja calidad del producto Alto costo de mantenimiento, etc.

Actividades de la Gestin y la Planificacin

PLANIFICACI N

GESTION DE PROYECTOS Propuesta Planificacin Supervisin Personal Informal

Planificacin del tiempo (calendarizacin) Estimacin de costos (esfuerzo)

Gestin de riesgos y control de calidad Gestin de la configuracin de sw

2.1. Planificacin del tiempo



El factor tiempo es muy importante en el desarrollo de software ya que ganaremos o perderemos a un cliente si este no es entregado en los tiempos establecido o ya negociados. La planificacin de tiempo se puede definir como una actividad en la cual se debe estimar el tiempo que requerir para llevar a cabo una tarea y los recursos necesarios para su realizacin.

Actividades e Hitos


Durante la recoleccin de requerimientos, se listan todos los elementos que se deben entregar del proyecto (actividades e hitos), que son los tems que los clientes esperan ver durante el desarrollo del proyecto. La descomposicin en hitos y actividades beneficia:

Tanto a clientes como desarrolladores para entender el desarrollo y mantenimiento del sistema. Al gestor para juzgar el progreso del software y puede entonces actualizar costos y el calendario.

Actividades e Hitos en el desarrollo de software

Calendarizar el proyecto


Una vez definidas las actividades y hitos lo siguiente es calendarizar el proyecto, esto es, dividir el trabajo en actividades o tareas complementarias y considerar el tiempo que requiere cada una para completarse. Generalmente se representa con grficos de barras y grafos o redes de actividades que muestran las actividades, los responsables, la dependencia entere actividades y la asignacin de recursos, entre otras cosas. El gestor debe coordinar las tareas del trabajo, asignarles a stas el personal y otros recursos de tal manera que se aprovechen de manera ptima. Las actividades por lo general duran al menos una semana, la cantidad de tiempo mxima sugerida es de 8 a 10 semanas.

2.1.1 Mtodos de Planificacin temporal



Existen varios mtodos para la planificacin :

La tcnica de revisin y evaluacin del

programa(PERT) CPM la ruta crtica

Tambin existen varias representaciones grficas como los son:

Redes de actividades Grficos de barras

Diagrama de Actividades


Por, medio de una red de actividades se muestra la dependencia entre las diferentes actividades y se estima el tiempo en que tardar cada tarea, se debe considerar que algunas de stas se podrn realizar en paralelo.
T1 8 T2 15 T3 15 T4 10 T5 10 T6 5 T7 20 T8 25 T9 15 T10 15 T11 7 T12 10

Tarea Duracin (das)

T1 (M1) Dependencias

T2,T4 (M2)

T1,T2 (M3)

T1 (M1)

T4 (M5)

T3, T6 (M4)

T5, T7 (M7)

T9 (M6)

T11 (M8)

M representa un Hito

Diagrama de Actividades
3 1 6 Es el tiempo mnimo requerido para finalizar el proyecto
11

10

9 8

12

Diagramas de Gantt

Diagramas de Gantt


En un diagrama de Gantt las actividades son seguidas por una barra sombreada (azul) y cuya longitud es calculada por una herramienta de calendarizacin. La barra azul indica que hay flexibilidad en la fecha de terminacin para dichas actividades. Entonces la ruta crtica se ve afectada solamente si:

Las actividades que no tienen barra azul no se completan a tiempo. Las actividades con barra azul pasa del lmite de tiempo marcado por sta.

Personas asignadas a diferentes Actividades en el Proyecto

Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Ingeniero Jane Anne Jane Fred Mary Anne Jim Fred Jane Anne Fred Fred

Mtodos PERT (Program Evaluation and Review Technique) y CPM(Crtical Path Method)


Ambos mtodos aportaron los elementos administrativos necesarios para formar el mtodo del camino crtico actual, utilizando el control de los tiempos de ejecucin y los costos de operacin, para buscar que el proyecto total sea ejecutado en el menor tiempo y al menor costo posible. Tanto PERT como CPM hacen uso de diagramas o redes de actividades.

El mtodo PERT


El mtodo PERT se desarroll para proyectos en donde hubiera incertidumbre en el tiempo de las actividades (usualmente debido a que el proyecto nunca se haba intentado antes y por tanto no haba bases de datos, para los tiempos de las actividades). Esto condujo al enfoque probabilstico que se tom. La principal desventaja es que no es funcional para grandes proyectos, debido a los tres estimados de tiempo que se requieren en cada actividad y a la capacidad limitada de los computadores actuales, para almacenar esta vasta cantidad de datos. Adems, el costo de actualizar y mantener la informacin del proyecto con el tiempo en ambientes tan dinmicos, puede ser excesivamente prohibitivo.

Pasos en el planteamiento de PERT

1. 2. 3. 4. 5. 6.

Identificar las actividades y su interdependencia Determinar la secuencia de actividades Construir el diagrama de red Tiempos estimados de actividades Determinar la trayectoria crtica Actualizar segn el progreso del proyecto

El mtodo CPM


El CPM se desarroll para manejar proyectos repetitivos o similares (ej., mantenimiento de plantas qumicas). Obviamente, se gana gran cantidad de experiencia con el tiempo en tales circunstancias, aun cuando dos proyectos puede que no sean iguales. Esta experiencia llev al anlisis de tcnicas de colisin utilizadas en las redes CPM.

Pasos en CPM
1. 2. 3. 4.

5.

6.

Especificar las actividades individuales. Determinar la secuencia de esas actividades. Dibujar el diagrama de la red. Estimar el tiempo de terminacin para cada actividad. Identificar la trayectoria crtica (la trayectoria ms larga a travs de la red) Actualizar el diagrama del CPM

Mtodo crtico


No solamente se llama camino crtico al mtodo sino tambin a la serie de actividades contadas desde la iniciacin del proyecto hasta su terminacin, que no tienen flexibilidad en su tiempo de ejecucin, por lo que cualquier retraso que sufriera alguna de las actividades de la serie provocara un retraso en todo el proyecto. Desde otro punto de vista, camino crtico es la trayectoria crtica de mayor duracin a travs de la red. Debido a su impacto en el proyecto entero, el anlisis de trayectoria crtica es un aspecto importante del planeamiento del proyecto.

Diferencias entre PERT y CPM

PERT es un mtodo Probabilstico. Considera que la variable de tiempo es una variable desconocida de la cual solo se tienen datos estimativos. El tiempo esperado de finalizacin de un proyecto es la suma de todos los tiempos esperados de las actividades sobre la ruta crtica. CPM es un mtodo Determinstico. Considera que los tiempos de las actividades se conocen y se pueden variar cambiando el nivel de recursos utilizados. A medida que el proyecto avanza, estos estimados se utilizan para controlar y monitorear el progreso. Si ocurre algn retraso en el proyecto, se hacen esfuerzos por lograr que el proyecto quede de nuevo dentro de los tiempos programados cambiando la asignacin de recursos.

Suponiendo que las distribuciones de los tiempos de las actividades son independientes, la varianza del proyecto es la suma de las varianzas de las actividades en la ruta crtica. Considera tres estimativos de tiempos: o el ms probable o optimista, o pesimista.

Considera que las actividades son continuas e interdependientes, siguen un orden cronolgico y ofrece parmetros del momento oportuno del inicio de la actividad. Considera tiempos normales y acelerados de una determinada actividad, segn la cantidad de recursos aplicados en la misma.

2.2 Evaluacin del costo-beneficio



Actualmente el Software es el elemento ms caro en la mayora de los sistemas de informacin, por lo que la estimacin debe realizarse cuidadosamente ya que un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y prdidas tanto para clientes y la empresa desarrolladora de software. Algunas razones por las cuales es crucial comprender cual ser el costo aproximado son :

Los costos excedidos pueden causar que los clientes cancelen el proyecto. Los costos subestimados pueden no compensar el tiempo invertido por el equipo del proyecto. No se debe olvidar que la estimacin es una actividad compleja que se vale de modelos y de tcnicas y estos a su vez se basan en mtricas, por lo que es necesario profundizar sobre stas.

2.2.1. Mtricas de software

Cuando se puede medir lo que se esta diciendo y expresarlo con nmeros, significa que tenemos conocimientos sobre ese tema, cuando esto no ocurre significa que nuestro conocimiento es precario y deficiente.

Porque medir el Software

 

Nos indica la calidad del producto Nos ayudan a evaluar

la productividad de la gente que desarrolla el producto los beneficios de utilizar nuevos mtodos y herramientas de ingeniera de software justificando el uso de stos. Esta evaluacin permite una mejora continua al proceso de desarrollo de software.

Nos ayuda a establecer una lnea base para la estimacin

Que es una medida?

Cuando se recopila un solo aspecto de los datos se est hablando de medidas. Ejemplo: nmero de lneas de cdigo o nmero de errores.

Que es una mtrica?

Qu es un Indicador?


Un ingeniero de software recopila medidas y desarrolla mtricas para obtener indicadores. Un indicador: es una mtrica o una combinacin de mtricas que proporcionan un visin profunda del proceso y proyecto del software o del producto en si mismo. Hay dos tipos de indicadores o mtricas: Indicadores de proceso e indicadores del proyecto

Indicadores de proceso


Brindan una visin profunda sobre la eficacia de un proceso ya existente. Permiten evaluar lo que est y no funcionando. Su propsito es mejorar los procesos de software a largo plazo y conducir a estrategias que permitan mejorar la calidad del proceso.

Indicadores del proyecto



Son utilizadas para supervisar el progreso durante el desarrollo de software y controlar la calidad del producto, adems se utilizan para realizar las estimaciones de tiempo y esfuerzo. Permiten al gestor de proyecto:

Evaluar el estado del proyecto Seguir las pistas de los riesgos potenciales Detectar las reas de problemas para evitar reas crticas Ajustar el flujo y las tareas del trabajo Evaluar la habilidad del equipo del proyecto para controlar la calidad del producto de software.

Mtricas de Software
Son la aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo.

Mtricas de Software
Podemos definir las Mtricas de Software o Medidas de Software como: La aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo del software y sus productos, para producir una informacin de gestin significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos y los productos que se obtienen de ellos. Estas medidas son aplicables a todo el ciclo de vida del desarrollo, desde la iniciacin, cuando debemos estimar los costos, al seguimiento y control de la fiabilidad de los productos finales, y a la forma en que los productos cambian a travs del tiempo debido a la aplicacin de mejoras.

Mtricas de Software
Esencialmente, las Mtricas de Software se aplican al producto Software y a los procesos mediante los que se desarrolla. Por tanto, las medidas del software y los modelos de medida son entonces tiles para estimar y predecir costos y para medir la productividad y la calidad del producto.

Caractersticas de las mtricas de Software

Una medida ideal debera ser: Objetiva. Sencilla, definible con precisin para que pueda ser evaluada. Fcilmente obtenible (a un coste razonable). Valida, la mtrica debera medir exactamente lo que se quiere medir y no otra cosa. Robusta. Debera de ser relativamente insensible a cambios poco significativos en el proceso o en el producto.

Mtricas de Producto

Clasificacin de las Mtricas de Software

Mtricas de Proceso

Mtricas de producto y de proceso

Las Mtricas de producto, Son medidas del producto software durante cualquier fase de su

desarrollo, desde los requisitos hasta la instalacin. Las Mtricas de Producto pueden medir la complejidad del diseo, el tamao del producto final (fuente u objeto) o el nmero de pginas de documentacin producida.

Las Mtricas de proceso, Son medidas del proceso de desarrollo del software tales como
tiempo de desarrollo total, esfuerzo en das/hombre o meses/hombre de desarrollo del producto, tipo de metodologa utilizada o nivel medio de experiencia de los programadores.

Se pueden clasificar las mtricas de otras maneras:

POR LAS PROPIEDADES OBJETIVAS Y SUBJETIVAS Por ejemplo, el tamao del producto medido en lneas de cdigo (LOC) es una medida objetiva del producto, y una medida subjetiva sera la clasificacin del software segn el modelo de estimacin de costos de Bohem (COCOMO) en orgnico, semilibre o rgido. Para medida de procesos, el tiempo de desarrollo es una medida objetiva y el nivel de experiencia de un programador es una medida subjetiva.

Mtricas de Productos

Mtrica orientadas al tamao Mtricas orientadas a la funcin Mtricas de calidad

Puntos de Funcin Lneas de Cdigo

 

Mtricas de Procesos Conclusiones (mtricas)

Mtricas orientadas al Tamao

a) Lneas de Cdigo: La medida ms utilizada de la longitud del cdigo fuente de

un programa es el Nmero de Lneas de Cdigo (Lines of Code en ingles, abreviado LOC). La definicin ms comn es la siguiente:

Una lnea de cdigo es cualquier lnea de un texto de un programa que no es un comentario o lnea en blanco, sin tener en cuenta el nmero de instrucciones o parte de instrucciones en la lnea. Esta medida se suele representar por NCLOC (No Comentary Lines of Code). Si queremos conocer la longitud real del programa esta sera: LOC = NCLOC + CLOC donde CLOC (Comentary Lines of Code( es el nmero de lneas de comentarios.) Una medida indirecta de la densidad de comentarios sera: CLOC / LOC

Dos problemas
a) No se tiene en cuenta el concepto de reutilizacin. b) No se tiene en cuenta el concepto de costes fijos ni tareas que se desarrollan que no producen instrucciones. Por ello, no debe ser utilizada esta medida directamente en la estimacin de esfuerzo o productividad. Cuando se est buscando la nocin pura de longitud existen dos alternativas aceptables si se quiere utilizar bajo el concepto de tasa (ratio): Medir la longitud en trminos de nmero de bytes de almacenamiento requerido para contener el texto del programa. Medir la longitud en trminos de nmero de caracteres en el texto del programa (char). Si se conoce el nmero medio de caracteres por lnea de texto, NL; el nmero de lneas sera: LOC = CHAR/NL

Ventajas y desventajas
Ventajas:  Que son fciles de calcular en cualquier proyecto  Existen varias herramientas de estimacin basadas en las lneas de cdigo Desventajas:  la falta de una definicin universal de lnea de cdigo  las lneas de cdigo dependen de los lenguajes de programacin y por lo tanto perjudica a los programas ms cortos pero bien diseados.  El estilo de programacin depender de cada persona. Comparar la productividad utilizando lenguajes diferentes de programacin puede llevar a conclusiones errneas respecto a la productividad de los programadores.  El decidir que lneas de cdigo se contabilizaran ya sean nuevas, lneas modificadas, reutilizadas ms definiciones de datos y comentarios.  dificultad de estimar en fases tempranas del desarrollo la cantidad de lneas que tendr una aplicacin.

Mtricas de Productos

Mtrica orientadas al tamao Mtricas orientadas a la funcin Mtricas de calidad

Puntos de Funcin Lneas de Cdigo

 

Mtricas de Procesos Conclusiones (mtricas)

Mtricas orientadas a la Funcin

Es un mtodo para cuantificar el tamao y la complejidad de un sistema software en trminos de las funciones que el usuario desarrolla o desarrollar. Se entiende por funciones a las entradas, salidas, archivos, etc.

Mtricas Funcionales Un punto de funcin es una mtrica sinttica que se compone de la suma ponderada de los totales de las entradas, las salidas, las consultas, los archivos lgicos, e interfaces que se identifican en la aplicacin.

Metodologa Original de Puntos de Funcin (1979)

La proposicin de puntos de funcin tuvo los siguientes objetivos:
    

Medir lo que el usuario pide y recibe. Medir independientemente de la tecnologa utilizada en la implantacin del sistema. Poder ser aplicados tempranamente en el ciclo de vida del producto. Proporcionar una mtrica de tamao que d soporte al anlisis de la calidad y la productividad. Ser independientes de cdigo fuente o lenguaje.

Inicialmente consider solo 4 parmetros bsicos y un factor de ajuste de complejidad. La siguiente tabla ilustra el mtodo original.

Metodologa Revisada de Puntos de Funcin (1984)

Revisin de 1984 de la mtrica Puntos de Funcin, de IBM

 Ejemplos de entradas: pantallas de datos llenadas por usuarios, cintas magnticas, discos flexibles, entradas sensoriales, por lpiz magntico, mouse clicks. Entradas: Pantallas o formularios a travs de los cuales usuarios humanos de una aplicacin u otros programas agregan nuevos datos o actualizan datos existentes. Si una pantalla de entrada es muy grande para ser desplegada de una vez (asumiendo 80 columnas y 25 lneas) y requiere de una segunda pantalla, el conjunto cuenta como una (1) sola entrada. Se deben considerar entradas que requieren procesamiento nico. Ejemplos de salidas: pantallas de datos de salidas, informes impresos, archivos en disco flexible, sets de cheques, facturas impresas. En general, contabilizar como una salida entidades que son referenciables por un nombre; contabilizar independientemente salidas que comparten los datos pero varan en formato. Por ejemplo, una tabla y un histograma. Salidas: Pantallas o informes que la aplicacin produce para uso humano o para otros programas. Las salidas que requieren procesamiento separado deben ser contabilizadas: en una aplicacin de remuneraciones una funcin de salida que genere 100 cheques contara como una sola salida.

Ejemplos de archivos internos lgicos: Coleccin lgica de registro que la aplicacin modifica o actualiza. Un archivos puede ser plano en una base de datos en PC, una rama de una base de datos jerrquica, una tabla de una base de datos relacional. Ejemplos de (archivos externos lgicos de) interfaz: bases de datos compartidas, archivos lgicos direccionables desde o hacia otra aplicacin. Interfaces: Archivos compartidos con otras aplicaciones, como archivos en cinta magntica que vienen o que van, bases de datos compartidas, o listas de parmetros. Las consultas se dividen en dos partes: la porcin de entrada y la porcin de salida. Ejemplos de consultas: consulta de un usuario sin actualizar un archivo, mensajes de ayuda, mensajes de seleccin. Una consulta tpica sera una relacionada con una reservacin area. La porcin de entrada sera la pregunta (por ejemplo: qu vuelos Ladeco salen de Santiago a Via del Mar despus de las 5 pm?) y la porcin de salida la respuesta (por ejemplo: Vuelo 123 a las 6:05 pm). Consultas: Pantallas que le permiten a los usuarios interrogar una aplicacin y solicitar asistencia o informacin, tal como pantallas de ayuda (HELP).

14 factores de influencia
             

C1 comunicacin de datos C2 funciones distribuidas C3 objetivos de performance C4 configuracin usada fuertemente C5 tasa de transacciones C6 entrada de datos en lnea C7 eficiencia del usuario final C8 actualizacin en lnea C9 procesamiento complejo C10 reusabilidad C11 facilidad de instalacin C12 facilidad operacional C13 sitios mltiples C14 facilitamiento del cambio

La escala de evaluacin tiene el siguiente significado:

     

0 factor no presente o sin influencia 1 influencia insignificante 2 influencia moderada 3 influencia promedio 4 influencia significativa 5 influencia fuerte

 Comunicacin de datos: implica que datos y/o informacin de control son enviadas o recibidas sobre facilidades de comunicacin. La evaluacin se reflejara en un 0 para aplicaciones batch, y un 5 para aplicaciones en que predomina el teleproceso. Funciones distribuidas: analiza si una aplicacin es monoltica y opera en un solo procesador o si es distribuida entre varios procesadores. La evaluacin arrojara un 0 para aplicaciones monolticas puras, y un 5 para aplicaciones que se ejecutan dinmicamente en varios procesadores. Objetivos de performance: la evaluacin sera un 0 si no hay establecido ningn criterio especial de performance por los usuarios, y un 5 si los usuarios insisten en objetivos de performance muy rigurosos que requieren un esfuerzo considerable para ser logrados.

 Configuracin usada fuertemente: la evaluacin sera un 0 si la aplicacin no tiene restricciones especiales de uso, y un 5 si el uso anticipado requiere especial esfuerzo para ser logrado. Tasa de transacciones: la evaluacin sera un 0 si el volumen de transacciones no es significativo, y un 5 si el volumen es lo suficientemente significativo como para producir stress en la aplicacin y requerir un esfuerzo especial para alcanzar throughputs deseados. Entrada de datos en lnea: la evaluacin sera un 0 si menos del 15% de las transacciones son interactivas, y un 5 si ms del 50% de las transacciones son interactivas. Eficiencia del usuario final: la evaluacin sera un 0 si no hay usuarios finales o no hay requerimientos especiales para los usuarios finales, y un 5 si los requerimientos de eficiencia de usuarios finales son lo suficientemente rgidos como para requerir un esfuerzo

 Actualizacin en lnea: la evaluacin sera un 0 si no hay, y un 5 si las actualizaciones son obligatorias y especialmente difciles, quizs debido a la necesidad de proteger datos de cambios accidentales. Procesamiento complejo: la evaluacin sera un 0 si no hay, y un 5 en casos que requieren decisiones lgicas extensas, matemtica compleja, procesamiento truculento de excepciones, o esquemas de seguridad elaborados. Reusabilidad: la evaluacin sera un 0 si la funcionalidad se planifica para permanecer local a la aplicacin actual, y un 5 si mucha de la funcionalidad y los artefactos del proyecto se pretende que sean usados ampliamente por otras aplicaciones.

 Facilidad de instalacin: la evaluacin sera un 0 si este factor es insignificante, y un 5 si la instalacin es importante y tan restrictiva que requiere un esfuerzo especial para cumplirla satisfactoriamente. Facilidad operacional: la evaluacin sera un 0 si este factor es insignificante, y un 5 si la facilidad operacional es tan restrictiva que requiere un esfuerzo especial para alcanzarla. Sitios mltiples: la evaluacin sera un 0 si hay solo un sitio planificado de uso, y un 5 si el proyecto y sus artefactos se pretenden sean usados en muchos lugares. Facilitamiento del cambio: la evaluacin sera un 0 si el cambio no ocurre, y un 5 si la aplicacin se desarrolla especficamente para permitir a los usuarios finales el hacer cambios rpidos para controlar datos o tablas que ellos mantienen con la ayuda de la aplicacin.

El procedimiento para calcular el factor de ajuste es el siguiente:

Asignar una evaluacin individual a cada uno de los 14 factores Sumar las evaluaciones (esta dar un valor entre 0 y 70) Multiplicar la suma de evaluaciones por 0.01 para obtener un valor decimal Sumar 0.65 al valor decimal para crear un factor de complejidad (un valor entre 0.65 y 1.35)

Ejemplo
Suponga una aplicacin con 10 entradas, 10 salidas, 10 consultas, 1 archivo de datos y 1 archivo de interfaz, todos ellos de complejidad promedio. Suponga que los factores de influencia se determinaron de la siguiente manera:

Conversin de Puntos de Funcin a lneas de Cdigo

Ada Basic Compilado Basic Interpretado Ensamblador C C++ Visual Basic Cobol80 Fortran77 Prolog Pascal Lisp Modula2

75 90 128 320 128 29 30 96 185 61 90 61 80

Ejemplo
Por ejemplo, si al aplicar el procedimiento de clculo para puntos de funcin sin ajustar se obtiene un resultado de 165 UNFP (Puntos de Funcin sin Ajustar) y el proyecto va a desarrollarse en el lenguaje de programacin C++: 165 UNFP x 29 = 4785 SLOC (Lneas de Cdigo Fuente) Haciendo la conversin mencionada anteriormente: 4785/1000= 4.785 KSLOC (Miles de Lneas de Cdigo Fuente).

Mtricas de Productos

Mtrica orientadas al tamao Mtricas orientadas a la funcin Mtricas de calidad

Puntos de Funcin Lneas de Cdigo

 

Mtricas de Procesos Conclusiones (mtricas)

Mtricas de Calidad


Cualquier proyecto de ingeniera del software tiene como objetivo principal obtener sistemas y productos de alta calidad La calidad es difcil medirla directamente, no obstante hay indicadores que nos pueden dar una idea sobre la misma. Estos indicadores se basan en los siguientes aspectos: Correccin Facilidad de mantenimiento Integridad Facilidad de uso

Correccin
Correccin.- Es el grado en el que el software lleva a cabo su funcin. Se mide en defectos por KLDC (miles de lneas de cdigo), entendindose por defecto cualquier falta de concordancia con los requisitos.

Facilidad de Mantenimiento


Facilidad de mantenimiento.- Se mide por la facilidad de:

Corregir defectos encontrados, Adaptar ese programa a nuevos entornos, y Mejorar el programa si el cliente desea cambios.

La facilidad de mantenimiento se mide indirectamente por medio de una mtrica orientada al tiempo: tiempo medio del cambio (TMC), es decir, por el tiempo que se tarda en analizar la peticin del cambio, disear la modificacin, implementarla, probarla y distribuir la notificacin del cambio a los usuarios.

Integridad


Integridad.- Mide la habilidad de un sistema para resistir ataques contra su seguridad. El proteger los datos, programas y documentacin debe ser una prioridad. Para medirla se consideran dos atributos adicionales:

Amenaza, que es la probabilidad estimada o deducida

de que se produzca un ataque de un tipo determinado. Seguridad, probabilidad estimada o deducida de el nuestro sistema pueda repeler dichos ataques.

Facilidad de uso


Facilidad de uso. Entendindose como tal lo amigable que resulta al usuario el sistema. Es un intento de cuantificar los amigable que es el sistema. Se puede deducir a partir de cuatro caractersticas:

Habilidad intelectual o fsica requerida para aprender el sistema. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema. El aumento de productividad de alguien que usa el sistema. Valoracin subjetiva de la disposicin de los usuarios hacia el sistema.

Tcnicas de Estimacin de Costos

2.2.2. Estimacin del proyecto de software

Estimacin de Proyectos
La primer tarea en la gestin de proyectos es la estimacin. La estimacin se define como el proceso que proporciona un valor a un conjunto de variables para la realizacin de un trabajo, dentro de un rango aceptable de tolerancia. Podemos definirlo tambin como la prediccin de personal, del esfuerzo, de los costos y de la planificacin que se requerir para realizar todas las actividades y construir todos los productos asociados con el proyecto. Uno de los parmetros crticos de la estimacin es determinar su exactitud. La estimacin puede realizarse a partir de datos histricos o con herramientas.

Tareas crticas en la Gestin de Proyectos

Hay tres tareas que son crticas y que deben ser desarrolladas correctamente si se desea que el proyecto termine bien, estas son: Estimacin de duracin, costo y esfuerzo necesarios para construir el producto. Planificacin de tareas a realizar, asignacin de personas, tiempos, etc. para construir el producto. Seguimiento durante la realizacin del trabajo, para asegurar el cumplimiento de lo planificado en cuanto a costes, fechas, etc. En caso de desviaciones del plan, se deben tomar las medidas pertinentes.

Relacin entre las actividades clave de la Gestin de Proyectos

2.2.2.1. Tcnicas para la estimacin del software

Tcnicas de Estimacin
Existen cuatro tcnicas bsicas y comunes La opinin de los expertos; Esta tcnica se basa en la experiencia profesional de los participantes en el proyecto de estimacin. La analoga; Es una aproximacin ms formal que la experiencia de los expertos y se basa en la comparacin directa de uno o ms proyectos pasados. La descomposicin; Consiste en la descomposicin de un producto en componentes ms pequeos, o descomponer un proyecto en tareas de nivel inferior. Las ecuaciones de estimacin; Son frmulas matemticas que establecen la relacin de algunas medidas de entrada (que normalmente es la medida del tamao del producto) y determinan el esfuerzo que se requerir.

La opinin de los expertos

Se emplea la opinin de ms de un experto para obtener una mayor fiabilidad en la estimacin. En algunos casos, simplemente se calcula la media de los valores ofrecidos por las distintas personas.
***La tcnica ms utilizada es la Delphi**, Bohem la refin en 1981 (Delphi de banda ancha)

Estimacin por Analoga

 

Constituye un complemento a la de juicio de expertos. En esta la personas involucradas no slo trabajan con su experiencia acumulada, sino que disponen tambin de datos de proyectos acabados relativamente similares al que hay que estimar. As por comparacin, se pueden evaluar las diferencias entre el nuevo proyecto y los antiguos y extrapolar su costo. La ventaja de esta tcnica est en que es precisa si est disponible la informacin del proyecto con el cul se va a comparar. La desventaja es que es imposible de comparar si el proyecto ha sido abordado. Trae consigo costos de mantenimiento de la base de datos.

Estimacin por descomposicin



En esta tcnica el responsable de cada componente del software que hay que construir estima el costo de su desarrollo. La estimacin para el proyecto completo se calcula mediante la suma de las cantidades parciales

2.2.2.2. Modelos de estimacin

MODELOS ALGORTMICOS MODELOS DE ESTIMACIN MODELOS EMPRICOS PARAMTRICOS NO PARAMTRICOS

MODELOS ALGORTMICOS


Son modelos que expresan la relacin entre el esfuerzo y los factores que lo influencian. Utilizan ecuaciones donde el esfuerzo es la variable dependiente y varios factores como la experiencia, tamao (que es el de mayor influencia) y tipo de sistema, son las variables independientes. Estos modelos suelen basarse en el tamao del software.

MODELOS EMPRICOS


Los Modelos empricos se dividen en:

Paramtricos.

Los cuales tiene una formula funcional explcita, relacionando una variable dependiente con una o ms variables.

No paramtricos. No tiene una formula funcional

explcita, por ejemplo, un modelo desarrollado usando la tcnica de aprendizaje mquina como una red neuronal.

MODELOS PARMETRICOS EMPRICOS



Los modelos de estimacin ms comunes son los Modelos paramtricos empricos.

Utilizan frmulas derivadas empricamente para

predecir el esfuerzo como una funcin de LDC o PF. Utilizan datos empricos obtenidos de una muestra de proyectos: Son difciles de usar para todas las clases de software y todos los entornos de desarrollo Se deben calibrar para las condiciones especficas de una organizacin

MODELOS PARMETRICOS EMPRICOS

E = A + B X (ev) c

Donde A y B: son constantes obtenidas empricamente E: esfuerzo en meses/persona ev: variable de estimacin (LDC o PF)

EL MODELO COCOMO (Constructive Cost Model)



COCOMO: Constructive Cost Model. Desarrollado en la dcada del 70 por Boehm. Revisado con una nueva revisin en 1995.

Es una coleccin de tres modelos: Bsico: aplicable cuando se conoce muy poco del proyecto Intermedio: aplicable luego de la especificacin de requerimientos Avanzado: aplicable cuando se termina el diseo. Todos utilizan la misma frmula: donde: E = aSbFA

E: esfuerzo en personas mes S: tamao medido en KLDC FA: Factor de ajuste (igual a 1 en el modelo bsico) a, b: s/tablas del modelo en funcin del tipo de sistema

EL MODELO COCOMO (Constructive Cost Model)

Por otro lado, COCOMO define tres modos de desarrollo o tipos de proyectos: 1. Orgnico. Proyectos relativamente sencillos, menores de 50KDLC,en los cules se tiene experiencia de proyectos similares. 2. Semi-acoplado. Proyectos intermedios en complejidad y tamao (menores de 300KDLC), donde la experiencia en este tipo de proyectos es variable. 3. Empotrado. Proyectos bastante complejos, en los que apenas se tiene experiencia y se engloban en un entorno de gran innovacin tcnica.
Bsico Modo Orgnico Semi-acoplado Empotrado a 2.4 3.0 3.6 b 1.05 1.12 1.2 c 2.5 2.5 2.5 d 0.38 0.35 0.32 a 3.2 3.0 2.8 b 1.05 1.12 1.2 Intermedio c 2.5 2.5 2.5 0.38 0.35 0.32 d

EL MODELO COCOMO (Constructive Cost Model)

Cuando se conoce un poco mas: el lenguaje, herramientas a utilizar se puede aplicar COCOMO intermedio. Se eligen los conductores de costos de una tabla que presenta 15. La importancia de cada conductor de costo es clasificada en una escala ordinal con seis puntos: Muy Baja, Baja, Media, Alta, Muy Alta, Extra Alta. A cada punto le corresponde un valor de factor de ajuste Ejemplo: Si se estimo la Capacidad de Anlisis como Muy Baja, el factor es 1.46, quiere decir que se debe aumentar el esfuerzo calculado previamente en un 46%.

15 MANEJADORES DE COSTO
Manejadores de Costo ACAP Analyst Capability AEXP Applications Experience CPLX Product Complexity DATA Database Size LEXP Language Experience MODP Modern Programming Practices PCAP Programmer Capability RELY Required Software Reliability SCED Required Development Schedule STOR Main Storage Constraint TIME Execution Time Constraint TOOL Use of Software Tools TURN Computer Turnaround Time VEXP Virtual Machine Experience VIRT Virtual Machine Volatility Very Low 1.46 1.29 0.70 1.14 1.24 1.42 0.75 1.23 1.24 1.21 Low 1.19 1.13 0.85 0.94 1.07 1.10 1.17 0.88 1.08 1.10 0.87 1.10 0.87 Nominal 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 High 0.86 0.91 1.15 1.08 0.95 0.91 0.86 1.15 1.04 1.06 1.11 0.91 1.07 0.90 1.15 Very High 0.71 0.82 1.30 1.16 0.82 0.70 1.40 1.10 1.21 1.30 0.83 1.15 1.30 Extra High 1.65 1.56 1.66 -

MODELO BSICO


Modelo Orgnico, Semi Acoplado y Empotrado.

Para determinar el esfuerzo del personal

E = aSbFA
Para determinar el tiempo de desarrollo

T=c Ed

MODELO INTERMEDIO


En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisin de la estimacin. Para determinar el esfuerzo del personal E = aSbFA Para determinar el tiempo de desarrollo T=c Ed Para determinar la productividad PR=LDC/E Para calcular el Personal promedio P=E/T

EL MODELO COCOMO II (Constructive Cost Model)



Es un modelo de estimacin de tiempo y de costo del software de acuerdo con los ciclos de vida utilizados en los 90 y en la primera dcada del 2000. Desarrolla bases de datos con costos de software y herramientas de soporte para la mejora continua del modelo. Proporcionar un marco analtico cuantitativo y un conjunto de herramientas y tcnicas para la evaluacin de los efectos de la mejora tecnolgica del software en costes y tiempo del ciclo de vida software.

Modelos de COCOMO II


El modelo de Composicin de Aplicaciones.

Indicado para proyectos construidos con herramientas modernas de construccin de interfaces grficos para usuario. Este modelo puede utilizarse para obtener estimaciones aproximadas del costo de un proyecto antes de que est determinada por completo su arquitectura. Utiliza un pequeo conjunto de drivers de costo nuevo y nuevas ecuaciones de estimacin. Est basado en Punto de Funcin sin ajustar o KSLOC (Miles de Lneas de Cdigo Fuente). Este es el modelo COCOMO II ms detallado. Se utiliza una vez que se ha desarrollado por completo la arquitectura del proyecto. Tiene nuevos drivers de costo, nuevas reglas para el recuento de lneas y nuevas ecuaciones.

El modelo de Diseo anticipado.

El modelo Post-Arquitectura.

Tabla comparativa ente COCOMO y COCOMO II

Comparativa entre modelos de COCOMO II

Modelo de Putnam Modelo SLIM



  

Surge en 1978 como solucin a un requerimiento de la marina de EEUU para proveer un mtodo para estimar esfuerzo y tiempo. Fue desarrollado por Putnam y lo llam modelo SLIM. Se utiliza para proyectos con mas de 70.000 LOC Puede ser ajustado para proyectos mas pequeos Asume que el esfuerzo para proyectos de desarrollo de software es distribuido en forma similar a una coleccin de curvas de Rayleigh, una para cada una de las actividades principales del desarrollo.

Curvas de Rayleigh para el modelo SLIM

Modelo SLIM


Putnam utiliza observaciones empricas sobre niveles de productividad para derivar su ecuacin de software a partir de la frmula bsica de la curva de Rayleigh

donde:  Tamano: medido en LOC  C: factor tecnolgico que incluye 14 conductores de costos y  puede tomar hasta 20 valores distintos  K: total del esfuerzo del proyecto calculado en personas ao  td: tiempo transcurrido para la entrega, medido en aos. td es el punto en el cual la curva alcanza un mximo.

2.2.2.3. Desarrollar o comprar?



En muchas ocasiones es ms aconsejable adquirir un producto de software que desarrollarlo. Los gestores son los que tienen que tomar esta decisin y deben tener en cuenta lo siguiente:

Comprar/alquilar el software ya desarrollado con licencia y que se ajuste a las especificaciones. Comprar componentes de software parcial o totalmente experimentados y luego modificarlos para ajustarse con las especificaciones. Encargar la construccin del software a una empresa externa.

En cualquiera de las tres alternativas, un factor importantsimo es la disponibilidad de recursos humanos, Tcnicos/hardware/ software.

2.2.2.4. Herramientas automticas de estimacin



Implementan tcnicas de descomposicin y modelos empricos. Permiten al planificador estimar costos y esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la seleccin del personal. Dependiendo de los datos, el modelo implementado por la herramienta proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos casos la planificacin temporal de desarrollo y riesgos asociados.

Herramientas automticas de Estimacin



Qu datos necesitan: Datos cuantitativos sobre el tamao del proyecto (LDC, PF) Caractersticas cualitativas del proyecto. Datos relacionados con el entorno y personal de desarrollo. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerir y cuanta gente necesitar para su realizacin. La estimacin del proyecto de software nunca ser una ciencia precisa, pero la combinacin de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin.

2.2.3. Evaluacin del costo-beneficio



El anlisis econmico incluye lo que se llama, el anlisis o evaluacin de costobeneficio, significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema. El anlisis econmico sirve para : Valorar la necesidad de la realizacin de un proyecto. Seleccionar la alternativa ms beneficiosa para la realizacin del proyecto. Estimar adecuadamente los recursos econmicos necesarios en el plazo de realizacin del proyecto.

Evaluacin del costo-beneficio



Algunos costos y beneficios pueden cuantificarse fcilmente: ahorros en costos, tales como una disminucin en costos de operacin y aumentos en las utilidades directas. Otros ejemplos de beneficios tangibles son :

Disminucin de errores Incremento de rentabilidad Reduccin de costos anteriores (fijos o variables)

Beneficios intangibles son aquellos que en el momento del anlisis, no se pueden cuantificar y con frecuencia estn relacionados a la calidad de la informacin que proporciona el sistema, tales como los listados a continuacin:

Satisfaccin en el servicio al cliente En las actividades administrativas, mejora en la toma de decisiones

2.2.3.1 Mtodos para el anlisis Costo / Beneficio



Diferentes mtodos pueden ser utilizados para calcular la relacin costobeneficio. Los mtodos ms sofisticados consideran el tiempovalor del dinero como parte del anlisis costo beneficio. Los mtodos comunes para el anlisis de costo beneficio incluyen: Punto de equilibrio Periodo de devolucin Valor presente neto Tasa interna de retorno

Punto de equilibrio


Observa el punto de equilibrio para realizar un esfuerzo por mejorar, es una de las formas ms sencillas de hacer el anlisis de costo beneficio. El punto de equilibrio es el tiempo que tomara para que el total de los ingresos incrementados y/o la reduccin de gastos sea igual al costo total. Sin embargo, no toman en cuenta el valor del dinero en el tiempo.

Frmula: PE = (Costo / Total de ingresos incrementados y/o reduccin de gastos) x 12 (meses)

Perodo de devolucin


El periodo de Devolucin es el tiempo requerido para recuperar el monto inicial de una inversin de capital. Este mtodo calcula la cantidad de tiempo que se tomara para lograr un flujo de caja positivo igual a la inversin total. Toma en cuenta beneficios, tales como el valor asegurado. Este mtodo indica esencialmente la liquidez del esfuerzo por mejorar un proceso en vez de su rentabilidad. Al igual que el anlisis del punto de equilibrio, el anlisis del periodo de devolucin no tiene en cuenta el valor del dinero en el tiempo.

Frmula: PD = [(Costo Valor Asegurado) / Total de ingresos incrementados y/o reduccin de gastos] x 12 (meses)

Valor presente neto

El NVP representa el Valor Presente (PV) de los flujos salientes de caja menos la cantidad de la inversin inicial (I).  Simplemente NPV = PV I  El valor presente del flujo de caja futuro es calculado utilizando el costo del capital como un factor de descuento. El propsito del factor de descuento es contar el Valor Futuro del dinero en Valor Presente (dlares futuros a dlares presentes) y se expresa como 1 + la tasa de inters (i). Frmula PV = ((ingresos + Valor Asegurado) / Factor de descuento) NPV = PV inversin (I)


Tasa interna de retorno



La tasa interna de retorno es la tasa de inters que hace la ecuacin de la inversin inicial (I) con el Valor presente (PV) de los futuros flujos de caja entrantes .

Cuando se calcula la TIR, el NPV se fija en cero y se resuelve para un inters (i). en este caso, el factor de descuento es (1 + i) ya que no conocemos el inters verdadero, solamente conocemos el inters deseado. Frmula PV = ((ingresos + Valor Asegurado) / Factor de descuento) NPV = PV inversin (I)


Tasa interna de retorno

A -70.000 12.000 1 2 3 4 5 6 7 15.000 18.000 21.000 26.000 Frmula =TIR(A2:A6) =TIR(A2:A7) B Datos Descripcin Costo inicial de un negocio Ingresos netos del primer ao Ingresos netos del segundo ao Ingresos netos del tercer ao Ingresos netos del cuarto ao Ingresos netos del quinto ao Descripcin (Resultado) Tasa interna de retorno de la inversin despus de cuatro aos (-2%) Tasa interna de retorno despus de cinco aos (9%)

2.3. Estudio de factibilidad



El proceso de ingeniera de requerimientos comienza con un estudio de viabilidad. Este es un estudio corto que ayuda a resolver si un nuevo sistema de software es o no candidato para desarrollarse de acuerdo a los recursos y restricciones impuestas por al organizacin. Llevar a cabo un estudio de factibilidad comprende la evaluacin y recoleccin de informacin y la redaccin de informes.
Viablidad Tcnica Viabilidad Econmica Viabilidad Operativa

2.3.1. Viabilidad Econmica

Es una evaluacin de costo beneficio del sistema que se quiere desarrollar, para saber que tan efectivo resultar su desarrollo, si contribuye o no a los objetivos del negocio, lo que determinar si vale la pena o no la inversin econmica.

2.3.2. Viabilidad Tcnica

Es un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. Las restricciones adems de presupuesto y tiempo incluyen los recursos humanos, hardware y software. Con este estudio se determina si con la tecnologa existente se puede implementar el nuevo sistema, o si hay que adquirir nueva tecnologa.

2.3.3. Viabilidad Operativa



Se trata de averiguar si el nuevo sistema es el adecuado para la organizacin. Se necesita saber si el nuevo sistema es flexible y puede integrarse a otros ya existentes en la organizacin.

2.4. Planificacin de la documentacin



Para mantener informado al cliente acerca de los riesgos, de la planificacin de tiempo y de la organizacin usualmente se hace por medio de un documento llamado plan de proyecto. El plan del proyecto de software se produce como culminacin de la etapa de planificacin. El plan del proyecto de software es un documento breve, esta dirigido a una diversa audiencia y debe :

Comunicar el alcance y recursos a los gestores del Software, personal tcnico y clientes. Definir los riesgos y sugerir planes de contingencia Definir el costo y el plan temporal para la revisin de la gestin. Proporcionar una aproximacin global del desarrollo del software para toda la gente involucrada en el proyecto. Describir cmo se garantizar la calidad y la gestin de cambios.

2.5 Gestin de la configuracin del software (GCS)



Los cambios durante el construccin de un software:

proceso

de

Son inevitables Provocan confusin e incertidumbre Pueden ocurrir en cualquier momento

Estos cambios aumentan conforme avanza el tiempo.

El arte de coordinar el desarrollo de software para minimizarla confusin, se denomina gestin de la configuracin. La gestin es el arte de identificar, organizar y controlar las modificaciones que sufre el softwarela meta es maximizar la productividad minimizando errores. Babich [BAB86].

2.5.1 Planificacin de la GCS



La planificacin de la GCS empieza durante las primeras fases del proyecto y debe definir el o los documentos que se controlarn. Aquellos documentos que puedan requerirse para el futuro mantenimiento del software, debern ser identificados y especificados como documentos de control. El plan de la GCS incluye:

La identificacin de los ECS La asignacin de responsabilidades Las polticas de la GCS La definicin de archivos de la GCS que deben ser controladas. La definicin de la base de datos Puede incluir informacin de software externo, proceso de auditora, etc.

2.5.2 El proceso de gestin de la configuracin del software



La GCS es un elemento importante de garanta de calidad, ya que es responsable de controlar los cambios. Sin embargo tambin se debe identificar los ECS individuales. El proceso se puede definir en cinco tareas de GCS:
1. 2. 3. 4. 5. Identificacin Control de versiones Control de cambios Auditorias de configuracin Generacin de informes