DIagrama de PERT

El diagrama PERT es una representación gráfica de las relaciones entre las tareas del proyecto que permite calcular los tiempos del proyecto de forma sencilla.

Caracteristicas

• Es un grafo, o sea, un conjunto de puntos (nodos) unidos por flechas.
• Representa las relaciones entre las tareas del proyecto, no su distribución temporal.
• Las flechas del grafo corresponden a las tareas del proyecto.
• Los nodos del grafo, representado por círculos o rectángulos, corresponden a instantes del proyecto. Cada nodo puede representar hasta dos instantes distintos, el inicio mínimo de las tareas que parten del nodo y el final máximo de las tareas que llegan al mismo.
• Es una herramienta de cálculo, y una representación visual de las dependencias entre las tareas del proyecto.

Tarea   Predec.   Duración  A - 2 B A 3 C - 2 D C 3 E DII+1 2 F BFI-1 3 G D, E, F 3 H GFF 2

Método Constructivo

Para construir un diagrama PERT se han de tener en cuenta las siguientes reglas

• Los nodos representan instantes del proyecto. Cada nodo representa el inicio mínimo (im) de las tareas que tienen origen en dicho nodo y el final máximo (FM) de las tareas que llegan al mismo.
  
• Sólo puede haber un nodo inicial y un nodo final. O sea, sólo puede haber un nodo al que no llegue ninguna flecha (nodo inicial) y sólo puede haber un nodo del que no salga ninguna flecha (nodo final).
• La numeración de los nodos es arbitraria, si bien se reserva el número menor (generalmente el 0 o el 1) para el nodo inicial y el mayor para el nodo final.
• Las flechas representan tareas y se dibujan de manera que representen las relaciones de dependencia entre las tareas. Los recorridos posibles a través del diagrama desde el nodo inicial al nodo final, siguiendo el sentido de las flechas, deben corresponder con las secuencias en que deben realizarse las distintas tareas, o sea, los caminos del proyecto.
  
• No puede haber dos nodos unidos por más de una flecha.
  
• Se pueden introducir tareas ficticias con duración 0, que acostumbran a notarse f(0), para evitar construcciones ilegales o representar dependencias entre tareas, como en los ejemplos siguientes.
  
  
  Ejemplo 1:
  Las tareas I y J dependen de la tarea H, mientras que la tarea K depende, a su vez, de I y J; la representación más inmediata sería la mostrada en el gráfico anterior, que no está permitida, siendo la correcta:
  
  Ejemplo 2:
  La tarea J depende de H y la tarea K depende de H e I. Siguiendo las flechas, puede comprobarse que el gráfico propuesto define los caminos H-J y H-K e I-K.
  
  Ejemplo 3:
  En el proyecto con las relaciones de dependencia establecidas en la siguiente tabla, es necesario utilizar dos tareas ficticias para representar la relación de dependencia de la tarea E, ya que sería imposible hacerlo de otro modo sin vincularla también la las tareas C o D.
  
  

  Tarea   Predec.  A - B - C A D B E A, B

Veremos, a continuación, la representación de las relaciones básicas de dependencia:

• Relación Fin-Inicio (FI).
  
  
  
• Relación Fin-Inicio (FI) con retardo. El retardo se representa como una tarea fictica de duración igual al retardo; si el retardo es negativo, se ha de indicar su signo y tenerlo en cuenta al realizar los cálculos.
  
  
  
• Relación Inicio-Inicio (II). Para su representación en el diagrama se sustituye la relación II por una relación equivalente a efectos de cálculo: una relación Fin-Inicio con un retardo negativo igual a la duración de la tarea predecesora.
  
  
  
• Relación Inicio-Inicio (II) con retardo. Se introduce una tarea ficticia adicional con la duración del retardo, como en el caso Fin-Inicio. Si se desea, se pueden sumar (teniendo en cuenta sus signos) las duraciones de las tareas ficticias correspondientes al tipo de relación y al retardo y representarlas mediante una única tarea ficticia.
  
  
  
• Relación Fin-Fin (FF). Para su representación en el diagrama se sustituye la relación FF por una relación equivalente a efectos de cálculo: una relación Fin-Inicio con un retardo negativo igual a la duración de la tarea sucesora.
  
  
  
  
• Relación Fin-Fin (FF) con retardo. Se introduce una tarea ficticia adicional con la duración del retardo, como en el caso Fin-Inicio. Si se desea, se pueden sumar (teniendo en cuenta sus signos) las duraciones de las tareas ficticias correspondientes al tipo de relación y al retardo y representarlas mediante una única tarea ficticia.
  

Cálculos

El diagrama PERT permite calcular los inicios mínimos y los finales máximos de todas las tareas del proyecto. En cada nodo obtendremos el inicio mínimo de todas las tareas que tengan origen en ese nodo y el final máximo de todas las tareas que lleguen a él. En todas las ilustraciones y ejemplos de este curso situaremos los inicios mínimos en la parte superior del nodo y los finales máximos en la parte inferior.

En primer lugar se calculan todos los inicios mínimos del proyecto; para ello:

• Por definición, el inicio mínimo de un proyecto es el instante cero de ese proyecto. por lo tanto, se ha de poner un cero en la parte superior del primer nodo.
  
  
  
• Si al inicio mínimo (im) de una tarea T_i le sumamos la duración de la misma, obtendremos el final mínimo (fm) de dicha tarea: fm_i=im_i+d_i. Si la tarea T_j depende sólo de la tarea T_i con una relación fin-inicio, T_j sólo podrá iniciarse una vez que la tarea precedente (T_i) haya terminado. O sea, el inicio mínimo de T_j será igual al fin mínimo de T_i:

  imj = fmi = imi+di

  Por lo tanto, se ha de recorrer el diagrama en el sentido de las flechas. En la parte superior de cada nodo se escribe el valor resultante de sumar la duración de la tarea mediante la que se llega al nodo y el valor en la parte superior del nodo del que procede. 
  
  
  
• Si una tarea T_j depende de varias tareas T_i con una relación fin-inicio, la tarea T_i no se podrá iniciar hasta que no hayan terminado todas las tareas T_i, o sea, el inicio mínimo de T_jes igual al mayor de los finales mínimos de las tareas T_i:

  imj = max(fmi)

  Por lo tanto, sobre el grafo, cuando a un nodo llegan varias flechas se deben calcular los valores obtenidos a través de los distintos caminos de llegada al nodo y tomar el mayor de dichos valores.
  
  
  
• El último nodo representa el final del proyecto. En este punto ya conocemos los inicios mínimos de todas las tareas del proyecto. El valor en la parte superior del nodo es el inicio mínimo de cualquier tarea que se realice una vez terminado el proyecto, por lo que corresponde con el fin mínimo del proyecto. Normalmente nos interesa hacer los cálculos de manera que reflejen lo más pronto que se puede acabar el proyecto, por lo que fijaremos el fin máximo del proyecto igual a su fin mínimo.

  fmproy = FMproy

  Así, una vez se llega al último nodo, se copia en la parte inferior el valor obtenido en la parte superior.
  
  
  

A continuación se calcularán todos los finales máximos del proyecto:

• Si al final máximo de una tarea T_j le restamos su duración, obtendremos su inicio máximo (lo más tarde que puede empezar sin retrasar el proyecto), o sea: IM_j = FM_j-d_j. Si la tarea T_j depende sólo de la tarea T_i con una relación fin-inicio, la tarea T_i no podrá acabar más tarde del inicio máximo de T_j sin retrasar el proyecto, o sea, lo más tarde que puede terminar T_i es lo más tarde que puede empezar T_j:

  FMi = IMj = FMj-dj

  Por lo tanto, se ha de recorrer el diagrama en sentido inverso al de las flechas empezando por el nodo final. En la parte inferior de cada nodo se escribe el valor resultante de restar la duración de la tarea que parte del nodo calculado al valor en la parte inferior del nodo al que llega la tarea.
  
  
  
• Si varias tareas T_j dependen de una o más tareas T_i, lo más tarde que podrán terminar las tareas T_i sin retrasar el proyecto será lo más tarde que podrá empezar la primera de las tareas T_j, o sea, aquella cuyo inicio mínimo sea menor. De este modo:

  FMi = mín(IMj) = mín(FMj-dj)

  Así, cuando de un nodo parten varias flechas, se deben calcular los valores obtenidos a través de cada una de ellas y tomar el menor de dichos valores.
  
  
  
• El primer nodo del proyecto corresponde a su inicio, así que el valor obtenido como fin máximo se refiere al fin máximo que debería tener cualquier actividad previa al proyecto. Para que el proyecto pueda empezar en el instante 0, el fin máximo de cualquier actividad previa deberá también ser 0, por lo que éste deberá de ser el valor que obtengamos en la parte inferior del primer nodo.
  
  
  Aunque la obtención de un cero en la parte inferior del primer nodo no nos garantiza que los cálculos sean correctos, si se obtiene cualquier otro valor se podrá afirmar que existe algún error en los cálculos realizados.
  

RESUMEN

Se necesita 6 pasos para desarrollar el proyecto Pert/tiempo los cuales son los sig:

• Construcción de la red Pert: Se trata de desarrollar una secuencia lógica, de las actividades por realizar, el proyecto y la correlación de estas actividades respecto al tiempo. Al construir un diagrama de flechas debe pensar en todas las actividades requeridas y en sus relaciones correspondientes en cuanto al tiempo, se tiene que desarrollar una lista de las actividades del proyecto.

• Cálculo del tiempo esperado: Debe estar claro que el tiempo más probable (m) debe llevar un peso mucho mayor que el más optimista (a) y el más pesimista (b). El tiempo esperado te representa el valor específico del tiempo (horas, días, semanas, etc). En una curva acampanada normal, como se dijo previamente, el tiempo probable es el tiempo promedio o tiempo esperado. Sin embargo cuando es cargada hacia la derecha o hacia la izquierda, el tiempo esperado estará hacia la derecha o izquierda del valor más probable, dependiendo de las tres cifras del tiempo.
  Te= a+4m+b
  6

• Determinación del tiempo más próximo y más tardío: Un evento puede tener uno o más valores, depende de la relación actividad- tiempo. El tiempo del evento cero se convierte en el tiempo base a la que se suman todos los tiempos subsecuentes. Se debe optar por el tiempo más próximo de “x” semanas como el tiempo esperado más próximo para el evento.

• Determinación de la ruta o rutas criticas: Es el trayecto del tiempo más largo que la cruza, su tiempo más próximo Te, es igual a su tiempo mas tardío TL. En consecuencia, no hay tiempo de holgura o de sobra.

• Cálculo de holgura: En consecuencia la red permite ver cuales actividades se puede y se debe ahorrar tiempo y en cuales otras se puede apresurar un poco el programa durante cierto periodo, si resulta ventajoso hacerlo.La formula de la holgura S (total) es la siguiente:

S=TL-Te

• Evaluación de la red Pert: El análisis de sensibilidad es muy importante.Si los tiempos totales no son satisfactorios dispone de varios métodos de ajuste entre éstos el intercambio de trabajadores, máquinas y materiales de las rutas no críticas a las críticas.

Pert/Costos

la cifra más baja se debe reducir substancialmente, su utilidad depende directamente de los datos con que se alimente al sistema de computación. La desviación estándar es una medida de la dispersión relativa de una distribución de probabilidad respecto a su media. Esta distancia puede representarse por aproximadamente +/- 3 desviaciones estándar () que puede expresarse matemáticamente como sigue:

6σ= b-a

σ=b-a

6

En consecuencia, una desviación estándar para una actividad es igual a (b-a)/6.

La suma de las desviaciones estándar elevadas al cuadrado para cada actividad. La fórmula se da como:

2 2 2

√Σσ1+σ2 +…σ n

Proporciona un enfoque para mantener la planeación actualizada al irse cumpliendo los diversos eventos, prever rápidamente el efecto de las desviaciones respecto al plan y realizar una acción correctiva anticipada en las áreas con problemas latentes. Todos los controladores conocen el momento preciso de iniciación de su trabajo, ayuda a eliminar la vaguedad de las asignaciones de responsabilidades.

Proporciona un número de verificaciones y salvaguardadas para evitar que se incurra en errores al desarrollar un plan. El costo de las redes PERT/Tiempo varía del 0.5 a 2% de los costos totales del proyecto. PERT/Costos, los costos son de 1 al 5% sobre los costos totales del proyecto.

SUMARY 6 steps are needed to develop the Pert / time project which are the sig:
• Construction of the network Pert: This is to develop a logical sequence of activities to be undertaken, the project and the correlation of these activities over time. • Calculate the expected time: It should be clear that the most likely time (m) must carry a weight much higher than the most optimistic (a) and pessimistic (b). • Determination of the nearest and later time: An event can have one or more values, it depends on the activity-time relationship. • Determination of the route or critical paths: the path is longer than the crossing time, his nearest time Te, is equal to its TL later time. Consequently, there is no slack time or surplus. • Calculation of slack: Consequently the network allows you to see which activities can and should save time and which others can speed a little program for a certain period, if it is advantageous formula hacerlo.La clearance S (total) is the following: S = TL-Te • Evaluation of network Pert: Sensitivity analysis is very importante.Si total times are not satisfactory offers several methods of adjustment between these exchange workers, machines and materials noncritical paths to criticism.
Pert / Cost The lower figure should be reduced substantially, its usefulness depends directly on the data that is fed to the computer system. The standard deviation is a measure of the relative dispersion of a probability distribution from its mean.
6σ = b-a σ = b-a 6
Accordingly, a standard deviation for an activity is equal to (b-a) / 6. The sum of the squared deviations high standard for each activity. The formula is given as:
2 2 2 √Σσ1 + σ2 + ... σ n

It provides an approach to maintain updated to meet the various events go quickly predict the effect of deviations to plan and carry out an early corrective action in areas with latent problems planning. All drivers know the precise time of initiation of their work, it helps eliminate the vagueness of responsibilities assignments. It provides a number of checks and safeguarded to prevent errors incurred in developing a plan. The cost of the PERT / Time networks varies from 0.5 to 2% of the total project costs. PERT / Cost, costs are from 1 to 5% of the total project costs. Traductor de Google para empresas:Google Translator ToolkitTraductor de sitios webGlobal Market Finder
RECOMENDACIONES
Recomendamos analizar a fondo la información presentada en la siguiente investigación ya que esto nos ayudara a comprender de manera fácil la aplicación del modelo PERT.

Recomendamos la aplicación de método PERT ya que este tiene muchas aplicaciones que oscilan desde le planeación y control de proyectos, construcción de puentes edificios, desarrollos industriales, instalación de equipos electrónicos, grandes operaciones comerciales.

CONCLUSIONES

El PERT es un excelente elemento dentro de la función de control, especialmente en la etapa de medición de resultados contra los estándares preestablecidos, ayuda en la corrección y/o agilización para alcanzar dichos estándares y externa información valiosa en la etapa de retroalimentación al ser compatibles con los factores que comprenden el control (Cantidad, tiempo, costo).

APRECIACIONES DEL EQUIPO

propongo, acudir al método PERT, el cual aporta al empresario dinámico, la herramienta que le permita planear en forma objetiva, sencilla y práctica, pero a la vez eficaz, todas y cada una de las actividades a realizar para conseguir éxito en los objetivos que pretende obtener la empresa.

LINKOGRAFIA

http://www.iusc.es/recursos/gesproy/textos/03.03.02.htm
http://es.ccm.net/contents/582-metodo-pert
http://www.ehowenespanol.com/diagrama-pert-info_243496/
http://es.slideshare.net/Ada007/diagrama-gantt-pert-y-ruta-crtica

Link de la Diapositiva

http://es.slideshare.net/mireya2022/pert-62003987

Video de Referencia

COCOMO II

COCOMO II

El nuevo modelo incorporado en el año 1990, tiene características de los modelos COCOMO 81 y Ada COCOMO. COCOMO II tiene también tres submodelos ; El modelo de composición de la aplicación es usada para estimar el esfuerzo y planificación de proyectos que usa las herramientas integradas CASE (Computer Aided Software Engineering) para un desarrollo rápido de la aplicación.

Realizando una comparación entre COCOMO 81 y COCOMO II; a este último se le añadió nuevos manejadores de costos para la aplicaciones precedentes, flexibilidad en el desarrollo, necesita documentación para el ciclo de vida, múltiples sitios de desarrollo y requiere software reusable.

Modelo COCOMO II post-arquitectura cubre el actual desarrollo y mantenimiento de un producto de software. Esta etapa del ciclo de vida procede mas a un costo efectivo, si el ciclo de vida de una arquitectura de software ha sido desarrollada, validada con respecto a la misión del sistema y establecida como un marco de trabajo para el producto.

El modelo de post-arquitectura predice el esfuerzo de desarrollo del software, personas-mes (PM), utiliza un conjunto de 17 multiplicadores de manejadores de costo (EM) y un conjunto de 5 escalas de manejadores de costo para determinar la escala del exponente del proyecto (SF). Esta escalas de los manejadores de costo remplazan los modos de aplicación (orgánico, sem.-acoplado y acoplado); el modelo tiene la siguiente forma:

PM = A * (Size) 1.01 + “j5= 1*

---

 I17= 1 Emil

Los manejadores de costo tiene para elegir una de las seis posibilidades que son: Very Low (VL), Low (L), Nominal (N), High (H), Very High (VH), y Extra High (XH); no todos los rangos son válidos para todos los manejadores de costo.

ADA COCOMO

Barrí Bohema & Walter Rocíe, 1987, 1988 definen el nuevo modelo COCOMO, llamado “Ada COCOMO”.

Este modelo al igual que el COCOMO estándar utiliza los manejadores de costo y ecuaciones anteriormente definidas.

COCOMO INCREMENTAL

Fue definido casi al mismo tiempo que Ada COCOMO. EL modelo COCOMO Incremental es una moderna alternativa para el tradicional modelo cascada de el desarrollo de procesos de software.

El modelo de desarrollo Incremental COCOMO permite una variedad de desarrollo de procesos. En vez de modelar el software como a esfuerzo simple para obtener un producto simple; el modelo incremental COCOMO permite desarrollar una serie de proyectos de software concurrente y producir un producto intermedio.

Esta estrategia reduce risk y permite entregar un producto inicial más fácilmente al cliente.

También existen algunas derivaciones de COCOMO como ser:

§  Cocots, (Constructive Cost)

§  Cossemo, (Constructive Staged Schedule & Effort Model).

§  Copromo, (Constructive Productivity Improvement Model).

§  Coqualmo

§  Coradmo

CARACTERÍSTICAS

·         Es una herramienta basada en las líneas de código la cual la hace muy poderosa para la estimación de costos y no como otros que solamente miden el esfuerzo en base al tamaño.

·         Representa el más extenso modelo empírico para la estimación de software.

·         Existen herramientas automáticas que estiman costos basados en COCOMO como ser: Costar, COCOMO 81.

OBJETIVOS PARA LA CONSTRUCCIÓN DE COCOMO II

·         Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que se adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras.

·         Construir una base de datos de proyectos de software que permitiera la calibración continua del modelo, y así incrementar la precisión en la estimación.

·         Implementar una herramienta de software que soportara el modelo.

·         Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en las diferentes etapas del ciclo de vida de desarrollo.

MODELOS DE COCOMO II

Los tres modelos de COCOMO II se adaptan tanto a las necesidades de los diferentes sectores, como al tipo y cantidad de información disponible en cada etapa del ciclo de vida de desarrollo, lo que se conoce por granularidad de la información. Estos tres modelos son:

·         Modelo de composición de aplicación. Utilizado durante las primeras etapas de la Ingeniería del software, donde el prototipado de las interfaces de usuario, la interacción del sistema y del software, la evaluación del rendimiento, y la evaluación de la madurez de la tecnología son de suma importancia.

·         Modelo de fase de diseño previo. Utilizado una vez que se han estabilizado los requisitos y que se ha establecido la arquitectura básica del software.

·         Modelo de fase posterior a la arquitectura. Utilizado durante la construcción del software.

DISTRIBUCIÓN DEL MERCADO DE SOFTWARE ACTUAL Y FUTURO

1.       Aplicaciones desarrolladas por Usuarios Finales: En este sector se encuentran las aplicaciones de procesamiento de información generadas directamente por usuarios finales, mediante la utilización de generadores de aplicaciones tales como planillas de cálculo, sistemas de consultas, etc. Estas aplicaciones surgen debido al uso masivo de estas herramientas, conjuntamente con la presión actual para obtener soluciones rápidas y flexibles.

2.       Generadores de Aplicaciones: En este sector operan firmas como Lotus, Microsoft, Novell, Borland con el objetivo de crear módulos pre-empaquetados que serán usados por usuarios finales y programadores.

3.       Aplicaciones con Componentes: Sector en el que se encuentran aquellas aplicaciones que son específicas para ser resueltas por soluciones pre-empaquetadas, pero son lo suficientemente simples para ser construidas a partir de componentes interoperables.

4.       Sistemas Integrados: Sistemas de gran escala, con un alto grado de integración entre sus componentes, sin antecedentes en el mercado que se puedan tomar como base. Porciones de estos sistemas pueden ser desarrolladas a través de la composición de aplicaciones. Entre las empresas que desarrollan software representativo de este sector, se encuentran grandes firmas que desarrollan software de telecomunicaciones, sistemas de información corporativos, sistemas de control de fabricación, etc.

5.       Infraestructura: Área que comprende el desarrollo de sistemas operativos, protocolos de redes, sistemas administradores de bases de datos, etc. Incrementalmente este sector direccionará sus soluciones, hacia problemas genéricos de procesamiento distribuido y procesamiento de transacciones, a soluciones middleware. Firmas representativas son Microsoft, Oracle, SyBase, Novell y NeXT.

RESUMEN

COCOMO II

El nuevo modelo incorporado en el año 1990, tiene características de los modelos COCOMO 81 y Ada COCOMO. COCOMO II tiene también tres submodelos ; El modelo de composición de la aplicación es usada para estimar el esfuerzo y planificación de proyectos que usa las herramientas integradas CASE (Computer Aided Software Engineering) para un desarrollo rápido de la aplicación.

ADA COCOMO

Barrí Bohema & Walter Rocíe, 1987, 1988 definen el nuevo modelo COCOMO, llamado “Ada COCOMO”.

Este modelo al igual que el COCOMO estándar utiliza los manejadores de costo y ecuaciones anteriormente definidas.

COCOMO INCREMENTAL

Fue definido casi al mismo tiempo que Ada COCOMO. EL modelo COCOMO Incremental es una moderna alternativa para el tradicional modelo cascada de el desarrollo de procesos de software.

CARACTERÍSTICAS

·         Es una herramienta basada en las líneas de código la cual la hace muy poderosa para la estimación de costos y no como otros que solamente miden el esfuerzo en base al tamaño.

·         Representa el más extenso modelo empírico para la estimación de software.

·         Existen herramientas automáticas que estiman costos basados en COCOMO como ser: Costar, COCOMO 81.

OBJETIVOS PARA LA CONSTRUCCIÓN DE COCOMO II

·         Desarrollar un modelo de estimación de costo y cronograma de proyectos de software.

·         Construir una base de datos de proyectos de software que permitiera la calibración continua del modelo, y así incrementar la precisión en la estimación.

·         Implementar una herramienta de software que soportara el modelo.

MODELOS DE COCOMO II

Los tres modelos de COCOMO II se adaptan tanto a las necesidades de los diferentes sectores, como al tipo y cantidad de información disponible en cada etapa del ciclo de vida de desarrollo, lo que se conoce por granularidad de la información. Estos tres modelos son:

·         Modelo de composición de aplicación

·         Modelo de fase de diseño previo

·         Modelo de fase posterior a la arquitectura

SUMARY

COCOMO II

The new built-in 1990 model has characteristics of COCOMO and Ada COCOMO 81 models. COCOMO II also has three sub-models; The model composition of the application is used to estimate effort and project planning using the integrated tools CASE (Computer Aided Software Engineering) for rapid application development.

ADA COCOMO

Walter Barrí Bohema & Spray, 1987, 1988 define the new COCOMO model, called "Ada COCOMO."

This model like COCOMO uses standard cost handlers defined above equations.

INCREMENTAL COCOMO

It was defined almost at the same time Ada COCOMO. Incremental COCOMO model is a modern alternative to the traditional waterfall model of the software development process.

CHARACTERISTICS

• It is a tool based on the lines of code which makes it very powerful for estimating costs and not as others that only measure the effort based on the size.

• It represents the most extensive empirical model for estimating software.

• There are automated tools that estimate costs based on COCOMO as: Costar, COCOMO 81.

OBJECTIVES FOR CONSTRUCTION OF COCOMO II

• Develop a model for estimating cost and schedule software project.

• Build a database of software projects that allow continuous model calibration, and thus increase the accuracy in the estimation.

• Implement a software tool that would support the model.

MODEL COCOMO II

The three models COCOMO II suit both the needs of different sectors, such as the type and amount of information available at each stage of development life cycle, which is known for granularity of information. These three models are:

• Model application composition

• Model predesign phase

• Model later stage architecture

Traductor de Google para empresas:Google Translator ToolkitTraductor de sitios webGlobal Market Finder

RECOMENDACIONES

Se recomienda:

·         No utilizar la herramienta de Cocomo cuando el proyecto tiene un tamaño muy corto.

·         Conocer bien cada nivel de Cocomo para poder aplicarlo en un proyecto de software.

·         Analizar cada función de Cocomo para poder implementar un proyecto de software.

·         Revisar los enlaces bibliográficos en caso de que se requiera tener más información acerca de los temas.

CONCLUSIONES

Se concluye:

·         Cocomo II es una herramienta rápida para la estimación de costos y esfuerzo de un proyecto de software.

·         El nivel avanzado de Cocomo II nos permite tener una perspectiva más amplia en cuando al impacto que se dará en cada proceso de estimación. 

·         La funcionalidad de Cocomo nos da una perspectiva muy amigable en cuando al manejo de la aplicación.

·         Las diferentes herramientas destinadas a la estimación de costo y esfuerzo, se derivan a de COCOMO.

          APRECIACIÓN DEL EQUIPO

Hoy en día es necesario para un administrador de proyectos posser una herramienta de estimación de costos; y esta herramienta puede ser COCOMO.

COCOMO representa el más extenso modelo empírico para la estimación de software publicado hasta la fecha.

GLOSARIO

Generalidad

Es la amplitud de aplicación potencial de los componentes del programa

Herencia

Es la propiedad que permite que una subclase herede los atributos y los mensajes de una superclase. Es el mecanismo por el cual elementos más específicos incorporan la estructura y el comportamiento de elementos más generales

Interacción

Es una especificación de comportamiento cuyo fin es lograr un propósito específico. Abarca un conjunto de intercambios de mensajes entre un conjunto de objetos dentro de un contexto particular. Una interacción puede ilustrarse mediante uno o más escenarios.

Completitud

Es el grado en que se ha conseguido la total implementación de las funciones requeridas.

Diseño

Es la parte del proceso de desarrollo de software cuyo propósito principal es decidir cómo se construirá el sistema. Durante el diseño se toman decisiones estratégicas y tácticas para alcanzar los requerimientos funcionales y la calidad esperada.

Evento

En el contexto de un diagrama de estado, un evento es un acontecimiento que puede disparar una transición de estados.

      Link de la Diapositva

        http://www.slideshare.net/mireya2022/cocomo-ii-61971864

   

      Video de Referencia