Con la tecnología de Blogger.

BANNER

BANNER
WEB

Followers

Blogroll

dsafsdfas

NUEVOS TEMAS - EXPOSISIONES

Posted by Luis De La Cruz On 0 comentarios

 DIAGRAMAS DE GANTT

El diagrama de Gantt, gráfica de Gantt o carta Gantt  es una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias.






DIAGRAMAS DE PERT/CPM

Las traducción de las siglas en inglés  significan: técnica de revisión y evaluación  de programas, es una técnica de redes desarrollado en la década de los 50, utilizada para programar y controlar programas a realizar. Cuando hay un grado extremo de incertidumbre y cuando el control sobre el tiempo es más importante sobre el control del costo, PERT es mejor opción que CPM.

CPM. La traducción de las siglas en inglés significan: método del camino crítico, es uno de los sistemas que siguen los principios de redes, que fue desarrollado en 1957 y es utilizado para planear y controlar proyectos, añadiendo el concepto de costo al formato PERT. Cuando los tiempos y costos se pueden estimar relativamente bien, el CPM puede ser superior a PERT.

Actividad. Es un trabajo que se debe llevar a cabo como parte de un proyecto, es simbolizado mediante una rama de la red de PERT.

Lista de actividades. Es una lista cuidadosa y ordenada donde se recopilan todas las diferentes actividades que intervienen en la realización de un proyecto.

Evento . Se dice que se realiza un evento, cuando todas las actividades que llegan a un mismo nodo han sido terminadas. Son los círculos numerados que forman parte del diagrama de red y representan el principio y el fin de las actividades que intervienen en el proyecto.

Rama. Son las flechas que forman Parte del diagrama de red y significan las actividades en el proyecto.

Ruta crítica o camino crítico. Camino es una secuencia de actividades conectadas, que conduce del principio del proyecto al final del mismo, por lo que aquel camino que requiera el mayor trabajo, es decir, el camino más largo dentro de la red, viene siendo la ruta crítica o el camino crítico de la red del proyecto.

Predecesor Inmediato. Es una actividad que debe Preceder (estar antes) inmediatamente a una actividad dada en un proyecto, también nombradas prioridades inmediatas.

Diagrama de red. Es una red de círculos numerados y conectados con flechas, donde se muestran todas las actividades que intervienen en un determinado proyecto y la relación de prioridad entre las actividades en la red.

Actividad ficticia. Actividades imaginarias que existen dentro del diagrama de red, sólo con el Propósito de establecer las relaciones de precedencia y no se les asigna tiempo alguno, es decir, que la actividad ficticia Permite dibujar redes con las relaciones de Precedencia apropiadas, se representa por medio de una línea punteada.

Holgura. Es el tiempo libre en la red, es decir, la cantidad de tiempo que puede demorar una actividad sin afectar la fecha de terminación del, proyecto total.

Distribución beta . Distribución utilizada para la estimación del tiempo de actividad esperado en el PERT, esta estimación se basa en el supuesto de que el tiempo de la actividad es una variable aleatoria cuya Probabilidad tiene una distribución beta unimodal.

Tiempo optimista. Es el tiempo mínimo o más corto posible en el cual es probable que sea terminada una actividad si todo marcha a la Perfección, utilizado en el PERT y simbolizado con a.

Tiempo más probable. Es el tiempo que esta actividad sea más probable que tome sí se repitiera una y otra vez, en otras palabras, es el tiempo normal que se necesita en circunstancias ordinarias, utilizado en el PERT y simbolizado con m.

Tiempo pesimista. Es el tiempo máximo o más largo posible en el cual es probable sea terminada una actividad bajo las condiciones más desfavorables, utilizado en el PERT y simbolizado con b.

Tiempo esperado para una actividad. Es el tiempo calculado en el PERT usando el promedio ponderado (a+4m+b)/6.

Tiempo normal. Es el tiempo en el CPM requerido para terminar una actividad si esta se realiza en forma normal. Es el tiempo máximo para terminar una actividad con el uso mínimo de recurso, el tiempo normal se aproxima al tiempo estimado probable en PERT.

Tiempo acelerado. Tiempo en el CPM que sería requerido si no se evita costo alguno con tal de reducir el tiempo del proyecto. Tiempo mínimo posible para terminar una actividad con la concentración máxima de recursos.



FUENTE: MONOGRAFIAS.COM




ESTIMACION DE COSTOS Y PLAZOS


Todo proyecto de ingenieria de software debe partir con un buen plan, pero lamentablemente, la planificacion es una tarea nada trivial uno de los aspectos que dificultan la labor de los administradores y jefes de proyecto en torno a la planificacion es la dificil tarea de realizar una estimacion de costos y plazos realista.
"la estimacion es mas arte que ciencia"

Metricas para la productividad y calidad del software: la medicion es esencial para cualquier disciplina de ingenieria y para la ingenieria de software no es la exepcion.



MODELOS DE ESTIMACION


COCOMO:    

submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).


La función básica que utilizan los tres modelos es:
E = a(Kl)b * m(X) donde:
a y b son constantes con valores definidos en cada submodelo Kl es la cantidad de líneas de código, en miles. m(X) Es un multiplicador que depende de 15 atributos. El resultado se da en unidades salario/mes y horas-hombre. A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:
modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).
modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.
modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

FUENTE: WIKIPEDIA


REQUERIMIENTOS

¿QUE SON?

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo



INCONVENIENTES PARA DEFINIR REQUERIMIENTOS

No son obvios, Provienen de diversas y variadas fuentes, Existen muchos tipos de requerimientos y diferentes niveles de detalle, Nunca son iguales. Algunos son más difíciles, más riesgosos o más importantes que otros , Los requerimientos están relacionados unos con otros, y a su vez están sujetos a un contexto , Un requerimiento puede cambiar a lo largo del ciclo de desarrollo (son inestables) , Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Características Deseables de un Requerimiento
1. Necesario
Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

2. Conciso
Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a
consultarlo en un futuro.

3. Consistente
Un requerimiento es consistente si no es contradictorio con otro requerimiento.

4. No Ambiguo
Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje, técnica o representación usado en su definición, no debe causar confusiones al lector.

5. Verificable
Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de métodos de verificación como inspección, análisis, demostración o pruebas.

6. Completo
Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.

7. Trazable
Un requerimiento es trazable cuando el desarrollo para lograr su satisfacción admite etapas que puedan ser verificadas.