PLANIFICACION Y GESTION DE PROYECTOS

Control de avance

En esta etapa se incluyen varias etapas algunas de estas se repetirán durante el ciclo para llega a una satisfacción plena en cuanto al objetivo final.
El Software solo es útil si ejecuta la función estimada en un principio, para llegar a esta idea se debe pensar muy bien lo que se requiere y diseñar un proyecto para diseñarlo. Se debe crear un cronograma de trabajo en el cual se delegan actividades además de sus estimaciones en cuanto a tiempo para cada una de las actividades.
Como primera medida se inicia el trabajo con los clientes potenciales y los usuarios para entender de primera mano las necesidades y brindar una solución optima a sus requerimientos, se realiza una lista de todas las necesidad y requerimientos los cuales el cliente desea ver en el sistemas a desarrollar ya sean documentos, demostraciones de funciones, demostraciones de precisión, demostraciones de confiabilidad, seguridad y desempeño.
Una vez obtenidos estos ítems se procede a analizar el impacto que puede tener cada uno de los puntos anteriormente nombrados sobre el proyecto, con el análisis de proyectos podemos brindar una visión mas clara apoyada sobre un cronograma del inicio de una actividad su desarrollo y su finalización, además de cómo dar un proceso eficiente así como la delegación de estas actividades para que su progreso de construcción se sustancial para el proyecto.
El proyecto a desarrollar teniendo en cuenta su robustez y complejidad se puede separa o modular para que el análisis sea aun mas objetivo, en este momento donde cada desarrollador divide en etapas o fases le es mas fácil a líder de proyector delegar las actividades dependiendo su complejidad de desarrollo.
Descomposición del trabajo y diagrama de actividades
Este represente un proyecto en un diagrama por separada identificando cada una de las actividades que este debe realizar de una manera lógica pero entendible para el cliente, de esta manera se puede ver el desarrollo del proyecto de una manera mas entendible y común, debido a que en cualquier punto del proyecto el cliente puede involucrarse con los avances del mismo y este debe ser entendible para el.
Estas actividades se pueden describir en cuatro parámetros que son: el precursor, la duración, la fecha de entrega, y el punto final.
El precursor: son todos aquellos pasos que anteceden a la iniciación del proyecto
La Duración: el tiempo necesario para completar cada actividad
Fecha de Entrega: fecha pactada para entregar el proyecto desarrollado cumpliendo al 100% las expectativas del cliente y del equipo de desarrollo
Punto final: terminación del proyecto en su totalidad.

ESTIMACION DEL PROYECTO DE SOFTWARE

Para realizar estimaciones seguras de coste y esfuerzo surge un numero de posible de opciones como:
Retrasar la estimación mas adelante en el proyecto (obviamente se puede hacer una estimación cien por ciento fiable después de completar el proyecto)
Utilizar "técnicas de descomposición " relativamente simples para generar las estimaciones del proyecto de software (por ej. Estimación LDC y PF)
Desarrollar un modelo empírico para el coste y el esfuerzo de software.
Adquirir una o más herramientas automáticas de estimación.Desdichadamente la primera opción, aunque atractiva no es practica, porque las estimaciones del coste deben ser proporcionadas de antemano. Las tres opciones restantes son aproximaciones viables para la estimación del proyecto de software. Las técnicas de descomposición utilizan una aproximación de "divide y vencerás " para la estimación del proyecto de software. Los modelos de estimación empíricos pueden utilizarse para completar las técnicas de descomposición y ofrecer una aproximación de la estimación potencialmente evaluable por ella misma. Las herramientas automáticas de estimación implementan una o mas técnicas de descomposición o modelos empíricos.

MODELOS DE ESTIMACIÓN EMPÍRICA

Un modelo de estimación para el software por computadora utiliza formulas derivadas empíricamente para predecir los datos.
Los datos empíricos que soportan la mayoría de los modelos se obtienen de una muestra limitada de proyectos. Tomando en cuenta los recursos se tienen los modelos recursos y consisten en una o más ecuaciones obtenidas empíricamente que predicen el esfuerzo (personas-mes), la duración del proyecto (meses cronológicos) o otros datos pertinentes al proyecto.

MODELO COCOMO

Barry Boehm en su libro "economía de la ingeniería de software" detalla un modelo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software .

COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).
El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.

Básico: es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).

Intermedio: calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de "guías de costo" que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.

Avanzado: incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.

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.
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.

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.

ESTIMACIÓN DE COSTOS

La estimación es más arte que ciencia; también es parte de la etapa de la planificación y algunas actividades de la ingeniería. La diferencia en la estimación de costos entre ingeniería de software y otras disciplinas es que en ingeniería de software lo principal para las personas es el costo; y en otras disciplinas el costo de las cosas materiales depende de la actividad.El manejador de costo principal para un proyecto de desarrollo de software es sin duda el tamaño del producto. La medida del tamaño debe ser tal que esté en relación directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de considerar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos y complejidad.

MÉTRICAS PARA LA PRODUCTIVIDAD Y CALIDAD DEL SOFTWARE

La medición es esencial para cualquier disciplina de ingeniería y la ingeniería de software no es una excepción.
Las métricas de software se refieren aun amplio rango de medidas para el software de computadoras dentro del contexto de la planificación del proyecto de software, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación de costos.
Las mediciones en el mundo físico pueden ser catalogadas en dos campos: medidas directas y medidas indirectas. Las métricas de software pueden ser catalogadas de forma parecida,Se puede clasificar en:

MÉTRICAS DE PRODUCTIVIDAD

Se centran en el rendimiento del proceso de la ingeniería de software.

MÉTRICAS DE CALIDAD

Proporcionan una indicación de cómo se ajusta el software, a los requerimientos implícitos y explícitos del cliente.

MÉTRICAS TÉCNICAS

Se centran en el carácter del software mas que en el proceso, a través del cual el software a sido desarrollado.

MÉTRICAS ORIENTADAS AL TAMAÑO

Son utilizadas para obtener medidas directas del resultado y la calidad de la ingeniería del software.

MÉTRICAS ORIENTADAS A LA FUNCIÓN

Son medidas indirectas del software y del proceso por el cual se desarrollará; se centran en la funcionalidad o utilidad del programa (Puntos de Función)

MÉTRICAS ORIENTADAS A LA PERSONA

Consiguen información sobre la forma en que la gente desarrolla software de computadora y sobre el punto de vista humano de la efectividad de las herramientas y métodos.