GESTION DE RIESGOS

La Gestion de riesgos es transmitir lo indices relativos respecto a una sociedad.

Involucra todos los recursos disponibles por los seres humanos.

Inexistente 0%
Improbable 1%
Alto riesgo 99%
Inminente 100%

ESTRATEGIA

Proactiva-en pro de desarrollo del software.
Este funciona para justificar el proyecto y antes de realizarlo, Se valora la probabilidad de todos los riesgos identificados, previniendo todos de forma general, pero con una estrategia para cada uno, Cuando un riesgo de baja probabilidad o no identificado entonces se hace uso de esta estrategia.

Reactiva-en el momento que se presente el problema.
Esta se reacciona al momento de la aparicion del riesgo, Afecta tanto al equpo de desarrolo como al cliente una vez terminado el producto, Muchas veces, el riesgo se convirtio ya en un peligro real, cuando se toma la decision, Funciona mejor para riesgos


RIESGOS DE SOFTWARE

Tecnicos.- amenazan la calidad del proyecto en cuanto a producciòn. Maneja diseño, implementacion, de interfaz, de verificacion, mantenimiento.

De negocio.-Amenazan la calidad del proyecto en cuanto a producciòn. Producto que no encaja en la estrategia comercial(rtiesgo estrategico), Perder el apoyo debido a cambios de enfoque o de personal(riesgo de direccion),Perder presupuesto o gasta mas de lo requerido (riesgos de presupuesto).

IDENTIFICACION DE RIESGOS

Genericos.-Son una amenza potencial para cualquier proyecto.
Riesgo de rendimiento, de coste, de soporte y verificacion, de tiempo, de personal.

Especificos.- Amenazan el proyecto potencial para alguna parte del proyecto.
Tamaño del producto, impacto del negocio, caracteristicas del cliente,organizacion del proceso de produccion, entorno de desarrollo, complejidad de la tecnologia a construir.

DIAGRAMA DE GANTT

Definiciòn:

El gráfico de Gantt permite identificar la actividad en que se estará utilizando cada uno de los recursos y la duración de esa utilización, de tal modo que puedan evitarse periodos ociosos innecesarios y se dé también al administrador una visión completa de la utilización de los recursos que se encuentran bajo su supervisión.

Características de GANTTPV:

Cada actividad se representa mediante un bloque rectangular cuya longitud indica su duración; la altura carece de significado.



1· La posición de cada bloque en el diagrama indica los instantes de inicio y finalización de las tareas a que corresponden.

2· Los bloques correspondientes a tareas del camino crítico acostumbran a rellenarse en otro color (en el caso del ejemplo, en rojo).

3- Es imprescindible tener bien definido el papel y la situación de cada uno, así como estar preparados para afrontar cualquier cambio.

4- Solución software organizar estas cuestiones de una manera cómoda, fluida y sin depender del volumen de trabajo.

5- Controla todas las acciones necesarias para administrar un proyecto, personal y recursos humanos, tareas asignadas a cada persona.

6- Recursos materiales necesarios para desarrollar cada tarea, costes y presupuestos, vacaciones o días libres, dependencias.

7- Completa interfaz de usuario, con numerosas opciones y posibilidades

8- Es altamente funcional y un instrumento muy valioso a la hora de manejar con soltura y fluidez

9 - Proyectos de mayor tamaño

10- Indica qué tareas es necesario completar antes de abordar otras.

Ejemplo de grafica de gantt:

Ejemplo propio:

Caracteristicas de GanttProject :

1- La aplicación GanttProject ha sido desarrollada en lenguaje Java y se distribuye para diversas plataformas

2-Al proyecto se puede agregar algunas o todas las columnas predefinidas Tipo, Prioridad, Info, Duración, Progreso, Coordinador, Antecesores y ID. Y si es necesario, se permite agregar columnas personalizadas por el usuario.

3- La creación de tareas se puede realizar con un clic derecho desde el panel bajo la pestaña Gantt o desde el menú Tarea

4- La creación y configuración de tareas y recursos incluye también aspectos de presentación que pueden brindar información específica de forma ágil.

5- Los archivos que crea GanttProject son documentos XML y gracias a la tecnología XSL se realizan trasformaciones para obtener páginas HTML o archivos PDF.

6- Cualquier aplicación que desee procesar diagramas de Gantt puede emplear los archivos generados por GanttProject y elaborar un hoja de estilos XSL para cada tipo de transformación que requiera.

7- GanttProject ofrece la creación de diagramas Pert a partir de diagramas de Gantt que muestran la secuencia de las tareas y discriminan los hitos.

8- Cuando una tarea no se cumple de acuerdo a lo planificado es importante analizar el tiempo y los recursos que se emplearon realmente.

9- GanttProject tiene la funcionalidad de comparar el estado actual de las tares con estados anteriores, y podemos utilizar esta funcionalidad para ajustar la configuración de tiempo y recursos en el futuro.

10- Los servidores WebDAV también son soportados por GanttProject y se puede trabajar con proyectos almacenados en servidores web para publicar o guardar proyectos en él.

-------------------------------------------------------------------------------------------------

QUE ES UN DIAGRAMA PERT:

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

Unidad 3.- Planifiacion de un proyecto de software.

Planeaciòn:

" La planeación consiste en fijar el curso concreto de acción que ha de seguirse, estableciendo los principios que habrán de orientarlo, la secuencia de operaciones para realizarlo, y la determinación de tiempos y números necesarios para su realización ".A. Reyes Ponce.

"Determinación del conjunto de objetivos por obtenerse en el futuro y el de los pasos necesarios para alcanzarlos a través de técnicas y procedimientos definidos" Ernest Dale.

" Planeación es la selección y relación de hechos, así como la formulación y uso de suposiciones respecto al futuro en la visualización y formulación de las actividades propuestas que se cree sean necesarias para alcanzar los resultados esperados" George R. Terry.

Referencia: http://sistemas.itlp.edu.mx/tutoriales/procesoadmvo/tema2_1.htm

Definicion de planeaciòn propia:

Para mi la planeaciòn consiste en determinar los objetivos y formular políticas, procedimientos y métodos para lograrlos, de manera eficiente alcanzando con esto un nivel de satisfacciòn grata de manera personal y profesional.



http://sitemasdesoftware2.blogspot.com/

Traer un proyecto de planeacion que sea importante para mi.

PLANEACION DE UN PROYECTO PERSONAL

El proyecto de planeación que tengo contemplado en este momento, es el desarrollarme internamente dentro del trabajo donde actualmente laboro, ya que es un área donde existe la posibilidad de trabajar por lo cual me he planteado que tengo que empezar a prepararme mas en el campo de la informática y así poder demostrar que mis conocimientos y habilidades son las adecuadas para poder ocupar un cargo importante dentro de la empresa, por lo cual busco planearme una estrategia de estudio rigurosa y posteriormente ir poniendo en practica dicho conocimientos en crear software que sea calidad y que sea similar a los que se usan en la empresa, por lo cual busco ubicarme a un corto plazo como un buen desarrollador y a mediano plazo trabajar dentro de la empresa y en largo plazo tener una empresa propio de software.

3.1 Objetivos de la Planificación del Proyecto.

El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.

El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

3.1.1 RECURSOS:

La Segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables.
Y en la parte mas alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano).

Cada recurso queda especificado mediante cuatro características:

· Descripción del Recurso.
· Informes de disponibilidad.
· Fecha cronológica en la que se requiere el recurso.
· Tiempo durante el que será aplicado el recurso.


3.1.2 Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñara cada profesional.

3.1.3 Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilizacion, esto es la creación y la reutilizacion de bloques de construcción de Software.

Tales bloques se deben establecer en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para la también fácil integración.

El Autor Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a medida que se avanza con la planificación:

· Componentes ya desarrollados.
· Componentes ya experimentados.
· Componentes con experiencia Parcial.
· Componentes nuevos.

3.1.4. Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de Software, incorpora Hardware y Software.

El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles. Muchas veces el desarrollo de las pruebas de validación de un proyecto de software para la composición automatizada puede necesitar un compositor de fotografías en algún punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software.

ESTIMACION DEL PROYECTO DE SOFTWARE.

En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento mas caro de la mayoría de los sistemas informáticos.

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

Para realizar estimaciones seguras de costos y esfuerzos se tienen varias opciones posibles:
Dejar la estimación para mas adelante (obviamente se puede realizar una estimación al cien por cien fiable después de haber terminado el proyecto).

Basar las estimaciones en proyectos similares ya terminados.

Utilizar técnicas de descomposición relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto.

Desarrollar un modelo empírico para él calculo de costos y esfuerzos del Software.

La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son métodos viables para la estimación del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas como comprobación de las otras.

Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a construir y generar una estimación de su tamaño.

Estimación basada en el Proceso.

Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea.
Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software.

DIFERENTES MODELOS DE ESTIMACION.

Modelos Empíricos:

Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia.

Modelo COCOMO.

Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm esta constituida por los siguientes:

Modelo I. El Modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de Software en función del tamaño del programa, expresado en las líneas estimadas.

Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

Modelo III. El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.) del proceso de ingeniería de Software.

3.2 Ambito del Software.

Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software.

En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos

Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

El Ambito se define como un pre-requisito para la estimación y existen algunos elementos que se debe tomar en cuenta como es:

· La Obtención de la Información necesaria para el software. Para esto el analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés para su desarrollo.

BIBLIOGRAFIA

http://html.rincondelvago.com/planeacion-de-sistemas-de-informacion.html

http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/planproy.htm

EXPOSICION 29 DE ABRIL

GESTION DE RIESGOS

-Proyeccion del riesgo

-Reduccion ,supervision y gestion del riesgo

-Riesgos y peligros para la seguridad

-TRAER REFERENCIAS BUIBLIO

-CUESTIONARIO 10 PREGUNTAS

-CONCLUSIONES PERSONALES

-RECURSOS(VIDEO, DIAGRMAS, TABLAS COMPARATIVAS)

3.4.- ESTIMACION DE PROYECTOS DE SOFTWARE

ESTIMACIÓN

Es una pequeña planeación sobre que es lo que va a ser mi proyecto. Una de las actividades
cruciales del proceso de gestión del proyecto del software es la planificación. Cuando se planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del esfuerzo humano requerido, de la duración cronológica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto es bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Pero que pasa si el proyecto es totalmente distinto entonces puede que la experiencia obtenida no sea lo suficiente.

Se han desarrollado varias técnicas de estimación para el desarrollo de software, aunque cada
una tiene sus puntos fuertes y sus puntos débiles, todas tienen en común los siguientes atributos.

1. Se han de establecer de antemano el ámbito del proyecto.
2. Como bases para la realización de estimaciones se usan métricas del software de
proyectos pasados.
3. El proyecto se desgloba en partes más pequeñas que se estiman individualmente.

-TITULO

-MARCO TEORICO

-REFERENCIAS BIBLIO

-CONCLUSION

-RECURSOS

-CUESTIONARIO 5 PREGUNTAS

BLOGS

javiersantiagoperez.blogspot.com

3.8.- HERRAMIENTAS AUTOMATICAS DE DESCOMPOSICION

sistemasdesoftwareii.blogspot.com

3.7 LA DECISION DE DESARROLLAR- COMPRAR

rios-vazquez.blogspot.com

ruiz-moran-ss2.blogspot.com

3.5 TECNICAS DE DESCOMPOSICION

HACERLES COMENTARIOS AL BLOG DE CADA QUIEN

ESTIMACIÓN DEL PROYECTO DE SOFTWARE:

La estimación del coste y del esfuerzo del software no es una ciencia exacta, son demasiadas las variables- humanas, técnicas , de entorno, políticas- que pueden afectar al coste final del software y al esfuerzo aplicado para desarrollarlo.

Para estimaciones seguras de costes y esfuerzos tenemos varias opciones posibles:
- dejar la estimación para cuando se ha acabado el proyecto, pero esto no es
práctico pues las estimaciones de los costes han de ser a priori.
- basarse en proyectos similares ya terminados, no fiable.
- usar técnicas de descomposición (divide_y_vencerás).
- modelo empírico para el cálculo de costes y esfuerzos del software.
Las dos últimas opciones son métodos viables para la estimación del proyecto software,
incluso pueden aplicarse conjuntamente.

Estimación de recursos y costes

La estimación de recursos y costes es una actividad importante que debe llevarse a cabo con el mayor detalle posible, porque permite al comprador establecer una aproximación al coste total y plazos del desarrollo del sistema.
Para ello se requiere experiencia, acceso a una buena información histórica y determinación para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.
Factores que afectan a esta estimación:
La complejidad del proyecto, cuantificando la misma en función de:
Número de módulos y nivel de interrelación entre los mismos.
Número y tipo de las interfaces externas con otros sistemas, programas o datos.
Grado de distribución y heterogeneidad del entorno de implantación.
Grado de sofisticación de las herramientas de desarrollo.
Naturaleza de los algoritmos que se deben diseñar y programar.
Otros factores específicos del proyecto.
La dimensión del sistema a desarrollar: conforme aumenta el tamaño de un sistema de información, la interdependencia entre los distintos elementos del sistema de información crece rápidamente y la descomposición del problema en partes más pequeñas se hace más difícil.
El grado de estructuración del proyecto: por estructuración se entiende la facilidad con que las funciones pueden ser compartimentalizadas y la naturaleza jerárquica de la información a tratar. A medida que el grado de estructuración aumenta, la posibilidad de estimar con precisión mejora y, por consiguiente, el riesgo disminuye.
Existen varias técnicas de estimación para el desarrollo de sistemas de información. Aunque cada una tiene sus puntos fuertes y débiles, todas tienen en común las siguientes características:
Se ha de establecer de antemano el alcance del proyecto.
Como base para la realización de estimaciones, se usan las métricas del software, es decir, medidas relativas al esfuerzo de desarrollo del equipo lógico.

El proyecto se desglosa en partes más pequeñas cuyos costes y recursos se estiman individualmente.

Ejemplos de estas técnicas son:
Análisis de puntos de función.
Técnicas de descomposición.
Modelos empíricos de estimación.
Herramientas automáticas de estimación.
Una vez estimado el tiempo y recursos necesarios para el desarrollo de la aplicación y teniendo en cuenta las tarifas de los distintos profesionales del desarrollo, se puede establecer una aproximación al presupuesto que va a exigir el desarrollo del sistema de información objeto del pliego.
La Administración ha promovido el desarrollo de una herramienta, SISDEL (Sistema Integrado de Soporte al Desarrollo de Equipos Lógicos), que sirve como ayuda a la gestión de la calidad, a la planificación y control de plazos, y a la estimación de proyectos de desarrollo de sistemas de información.

http://informatica.uv.es/iiguia/2000/IPI/material/tema5.pdf

http://www.csae.map.es/csi/silice/Dsamed25.html

PREGUNTAS

1. ¿Qué son las técnicas de descomposición?Permiten fragmentar el problema y coordinar la resolución de los subproblemas para alcanzar la solución del problema completo; las técnicas de descomposición se pueden ver como estrategias de partición del grafo que representa el árbol de escenarios y de resolución coordinada de los fragmentos del grafo.

2. ¿A qué se refieren las estimaciones basadas en el problema?Puede usarse LOC o PF para hacer estimaciones.Si se utiliza LOC, la descomposición es esencial y a menudo debe ser a detalle.Si se utiliza PF, en vez de centrar la descomposición en la función, se calcula el PF como se estudió en el capítulo anterior, estimando de alguna forma, cada uno de los valores.En ambos casos, mediante datos históricos o la intuición, se estiman valores optimista (O), medio (M) y pesimista (P) para cada función o contador, y se calcula el valor esperado (E) con la siguiente fórmula:E = (O + 4 * M + P) / 6

3. ¿Qué son las estimaciones basadas en el proyecto?Delimitar las funciones del software.Identificar las tareas de ingeniería del software para cada una de las funciones y representarlas en una tabla.Estimar el esfuerzo (número de personas/unidad de tiempo) de realización de cada tarea para cada una de las funciones del software.Aplicar las tarifas laborales (coste/unidad de esfuerzo) correspondientes a cada una de las tareas.Calcular los costes y el esfuerzo para cada función y cada tarea.

4. ¿Porque es inconveniente usar técnicas de descomposición?La dificultad para contemplar los costes de actividades relacionadas con el proyecto como lectura de código, revisión, reuniones, y actividades no relacionadas con el proyecto relacionado con los hábitos de trabajo.

5. ¿Cual es la diferencia entre la descomposición de benders y la relajación langragiana?Descomposición de BendersLa descomposición de Benders [Benders,1962], [VanSlyke,1969] propone separar en subproblemas las decisiones tomadas en diferentes etapas. Para ello se necesita que las decisiones de una etapa sólo dependan de las consecuencias de las decisiones tomadas en la etapa anterior. Con esta descomposición se plantea un problema por cada etapa, y en ese problema se incluye tanto la parte correspondiente a la propia etapa como la parte que liga esa etapa a las decisiones tomadas en la etapa anterior.Relajación lagrangianaEl otro método de descomposición más relevante es la relajación lagrangiana [Geoffrion, 1970], En esta ocasión se intentan separar dentro de cada etapa las decisiones para grupos de variables que están relacionadas entre sí. Es decir, se pueden localizar conjuntos de variables que están muy conectadas con otras etapas, pero poco relacionadas con otras variables de la misma etapa.

CONCLUSION

La conclusion que puedo dar es que las tecnicas de planificacion y descomposicion nos permiten el analisis detallado del software en base a criterios especificos ya preestablecidos, permitiendo al programador o al analisita el poder decidirse sobre una en especifico y generar un proyecto mucho mejor para el cliente al cual se le desarrollara el proyecto en especifico, ademas que el cliente puede estar confiado en que el desarrollador le dara un software de calidad que cumpla sus espectativas.

Unidad 2.- PROCESO DEL SOFTWARE Y METRICAS DEL PROCESO.

Qué es? El proceso del software y las métricas del producto son una medida cuantitativa que permite a la gente del software tener una visión profunda de la eficacia del proceso del software y de los proyectos que dirigen utilizando el proceso como un marco de trabajo.¿Quién lo hace? Las métricas del software son analizadas y evaluadas por los administradores del software. A menudo las medidas son reunidas por los ingenieros del software.¿Por qué es importante? Si no mides, sólo podrás juzgar basándote en una evaluación subjetiva. Mediante la medición, se pueden señalar las tendencias (buenas o malas), realizar mejores estimaciones, llevar a cabo una verdadera mejora sobre el tiempo.¿Cuáles son los pasos? Comenzar definiendo un conjunto limitado de medidas de procesos, proyectos y productos que sean fáciles de recoger.¿Cuál es el producto obtenido? Es un conjunto de métricas del software que proporcionan una visión profunda del proceso y de la comprensión del proyecto.¿Cómo puedo estar seguro de que lo he hecho correctamente? Aplicando un plan de medición sencillo pero consistente.Hay cuatro razones para medir los procesos del software, los productos y los recursos:
1-caracterizar

2-evaluar

3-predecir

4-mejorar

Caracterizamos para comprender mejor los procesos, los productos, los recursos y los entornos y para establecer las líneas base para las comparaciones con evaluaciones futuras. Evaluamos para determinar el estado con respecto al diseño. Predecimos para poder planificar. Medimos para mejorar.

2.2METRICAS EN EL PROCESO Y DOMINIOS DEL PROYECTO.
Los indicadores de proceso permiten a una organización de ingeniería del software tener una visión profunda de la eficacia de un proceso ya existenteLos indicadores de proyecto permiten al gestor de proyectos del software (1) evaluar el estado del proyecto en curso; (2) seguir la pista de los riesgos potenciales: (3) detectar las áreas de problemas antes de que se conviertan en «críticas»; (4) ajustar el flujo y las tareas del trabajo, y (5) evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo del software.

HERRAMIENTAS ALTERNAS A MS PROJECT

Planner

Originalmente conocida como Mr. Project, es una herramienta escrita en lenguaje de programación C para gestión de proyectos, diseñada para el escritorio de GNOME. Utiliza los diagramas Gantt para esquematizar las actividades del proyecto y su interacción entre éstas y otros elementos.Es, junto con Evolution, Gnumeric, Abiword y otros más, parte del conjunto GNOME Office. Planner utiliza un formato de fichero en XML o HTML, y también puede almacenar la información en una base de datos PostgreSQL. Tiene capacidad para importar proyectos desde Microsoft Project (solo formato XML).

2.4RECONCILIACION DE DIFERENTES ENFOQUES DE METRICAS.
La relación entre las líneas de código y los puntos de función depende del lenguaje de programación que se utilice para implementar el software y de la calidad del diseño.Hay muchos factores que influyen en la productividad, haciendo que la comparación sea fácilmente interpretable. factores humanosfactores del problema (complejidad)factores del procesofactores del productofactores de los recursos.

2.5 METRICAS PARA LA CALIDAD DEL SOFTWARE.El proceso es el único factor de «los controlables al mejorar la calidad del software y su rendimiento como organización».La eficacia de un proceso de software se mide indirectamente. Las métricas de proceso también se extraen midiendo las características de tareas específicas de la ingeniería del software. El proceso personal del software (PPS) es un conjunto estructurado de descripciones de proceso, mediciones y métodos que pueden ayudar a que los ingenieros mejoren su rendimiento personal.Humphrey reconoce que la mejora del proceso del software puede y debe empezar en el nivel individual.Etiqueta de métricas del software» adecuada para gestores al tiempo que instituyen un programa de métricas de proceso:Utilice el sentido común y una sensibilidad organizativa al interpretar datos de métricas.Proporcione una retroalimentación regular para particulares y equipos que hayan trabajado en la recopilación de medidas y métricas.No utilice métricas para evaluar a particulares.Trabaje con profesionales y equipos para establecer objetivos claros y métricas que se vayan a utilizar para alcanzarlos.No utilice nunca métricas que amenacen a particulares o equipos.Los datos de métricas que indican un área de problemas no se deberían considerar «negativos». Estos datos son meramente un indicador de mejora de proceso.No se obsesione con una sola métrica y excluya otras métricas importantes.Mejora estadística de proceso del sofmare (MEPS) utiliza el análisis de fallos del software para recopilar información de errores y defectos3 encontrados al desarrollar y utilizar una aplicación de sistema o producto. El análisis de fallos funciona de la misma manera:1. Todos los errores y defectos se categorizan por origen (por ejemplo: defectos en la especificación, en la lógica, no acorde con los estándares).2. Se registra tanto el coste de corregir cada error como el del defecto.3. El número de errores y de defectos de cada categoría se cuentan y se ordenan en orden descendente.4. Se computa el coste global de errores y defectos de cada categoría.5. Los datos resultantes se analizan para detectar las categorías que producen el coste más alto para la organización.

GESTION DE PROYECTOS DE SOFTWARE

GESTION DE PROYECTOS La gestión eficaz de un Proyecto de SW se centra en “4 P” Personal Producto Proceso ProyectoPERSONAL Los participantes que colaboran en el Proceso de SW se pueden clasificar en: Gestores Superiores: Definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto. Gestores del Proyecto: Son los que planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo. Profesionales: Son los que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación. Clientes: Son los que especifican los requisitos del proyecto. Usuarios finales: Son los que interactúan con el producto entregado.PRODUCTO Antes de Planificar un proyecto se deben establecer:  Objetivos  Ámbito del Producto  Estimaciones de Costo  Soluciones alternativas  Valorización del Riesgo  Dificultades Técnicas  Planificación del Proyecto  Dificultades de Gestión Sin ésta información es imposible definirPROCESO Lo definiremos como un marco de trabajo de las tareas que se requieren para desarrollar Software de Alta Calidad.PROYECTO Todos los Proyectos de Software deben ser PLANIFICADOS Y CONTROLADOS por una razón principal: Poder manejar su complejidadEs el Primer Nivel del Proceso de Ingeniería del Software y cubre TODO el proceso de desarrollo desde el comienzo al fin. Para alcanzar un PROYECTO EXITOSO se debe comprender:  El ámbito del trabajo a realizar.  Los riesgos en que se puede incurrir.  Recursos requeridos  Tareas a llevar a cabo  El costo presupuestado  Plan a seguir

unidad 1 geestion de proyectos de software