Taller sobre duración de un Proyecto

ACTIVIDADES REALIZADAS

·         Explicación de taller a realizar en clase.

·         Desarrollo de taller en el aula.

ESTRATEGIAS UTILIZADAS

Taller práctico realizado en clase. El taller a desarrollar era:

Como gestor de proyectos, es llamado a una prestigiosa empresa donde se realizan las siguientes actividades:

Realice:

a) Gráfico correspondiente, ¿Cuál es la duración del proyecto?

b) ¿Cúal actividad no se puede realizar?

Solución actividad:

  Para cada actividad se calcularán 4 tiempos,   Se denotarán:

1. Tiempo de inicio temprano: Es el tiempo más temprano posible para iniciar una actividad

  ES = EF más alto de la(s) actividad(es) anterior(es)

2. Tiempo de terminación temprano: Es el tiempo de inicio temprano más el tiempo para completar la actividad

  EF = ES de la actividad más duración de la actividad

  El ES y el EF se calculan recorriendo la red de izquierda a derecha

3. Tiempo de terminación más lejana: Es el tiempo más tardío en que se puede completar la actividad sin afectar la duración total del proyecto

 LF = LS más bajo de la(s) actividad(es) próxima(s)

4. Tiempo de inicio más lejano: Es el tiempo de terminación más lejano de la actividad anterior menos la duración de la actividad

  LS = LF de la actividad – duración de la actividad

  Para calcular LF y LS la red se recorre de derecha a izquierda

  Después de calculados los cuatro tiempos de cada actividad, se calculan las holguras

  La holgura es el tiempo que se puede atrasar una actividad sin afectar la duración total del proyecto

H = LF – EF

5. La ruta crítica se encuentra como aquella ruta para la cual todas sus actividades tienen holgura igual a cero

Empleando el método CPM o ruta crítica, encontramos que:

a) La duración del proyecto es de 45 días.

b) Las actividades que no se pueden realizar son E, F, G y H.

Estimaciones del Software

ESTRATEGIAS UTILIZADAS

Se realizo una clase magistral donde un medio audiovisual es el uso de video -beam se socializó aspectos relacionados con las Estimaciones del Software.

ACTIVIDADES REALIZADAS

·         Presentación de las diapositivas sobre Estimaciones del software.

·         Se expuso y debatió los siguientes temas:

La estimaciones son  una pequeña planeación sobre qué 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 desglosa en partes más pequeñas que se estiman individualmente.

La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipado problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado. No se analizara la planeación que implica a la estimación de la necesidad de un sistema de software y la habilidad de producir tal sistema, la asignación de prioridad al proceso de su producción.

ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE

1. Mal análisis en los requerimientos.

2. Una mala planeación.

3. No tener una negociación (documento, contrato) con el cliente.

4. No hacer un análisis costo beneficio.

5. Desconocer el ambiente de trabajo de los usuarios.

6. Desconocer los usuarios que trabajan con el sistema.

7. Mala elección de recursos (hardware, software, humanos).

 

ACTIVIDADES INDEPENDIENTES

Leer la metodología de la ruta crítica o CPM.

Nota: para ampliar el tema de esta clase recomendamos esta lectura:

http://www.slideshare.net/devaldiviesoxxx/estimacin-de-proyectos-de-software

OBJETIVO GENERAL:

Realizar planificación y gestión de proyectos de software.

ESTRATEGIAS UTILIZADAS

Se realizo una clase magistral donde un medio audiovisual es el uso de video -beam se presento un documento donde se realizo una series de debates.

ACTIVIDADES REALIZADAS

Presentación de las diapositivas sobre la planificación y gestión de proyectos de software
Debate sobre las diapositivas expuestas


A continuación se describe lo que se realizo en clases.

Planificación y gestión de proyectos de software, comienza con un conjunto de actividades que globalmente se denomina planificación de proyecto. Antes de que el proyecto comience. El tamaño del proyecto es otro factor importante que puede afectar la precisión y la eficiencia de las estimaciones.

La complejidad del proyecto y el grado de incertidumbre estructural afectan a  la fiabilidad de la estimación.  El registro se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas por recursos, coste y planificación temporal.  El planificador del software debería solicitar definiciones completas de rendimiento y de interfaz.

El objetivo de la planificación del proyecto software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y plantación temporal.  Las estimaciones deberían definir los escenarios del <<mejor caso>> y <<peor caso>>  de forma que los resultados del proyecto pueden limitarse.  El ámbito de software describe el control y los datos a procesar, la función, el rendimiento, las restricciones, ámbito, fiabilidad.

PLANIFICACION DE PROYECTO DE SOFTWARE

¿Por qué planifican?

Bohem, 1975.  45% de los errores tienen su origen en los requisitos y en el diseño preliminar
De los marcos, 1984. 56% de los errores que tienen en un proyecto de software se deben a una mala especificación de requisitos

Antes de comenzar se debe estimar: Esfuerzo, tiempo, personal y demás recursos. Luego de estimar se debe planificar

Establecer un plan de proyecto que defina tareas y fechas clave, identificar responsables por tareas y especificar dependencias entre tareas.

• Objetivos

Resolver problemas corrientes arriba abajo costo
La experiencia dice que el proyecto promedio de gasto es de un 80% de su tiempo en reelaboración corrigiendo errores que se cometieron en etapas tempranas del proyecto.
Proporciona un marco de trabajo que permita al gestor estimar razonablemente los recursos, costos y programas de trabajo.

Adaptar y actualizar el plan conforme se avance en el proyecto.

• Actividades

La planificación del proyecto software abarcan grandes actividades:
Estimación
Programa de trabajo
Análisis de riesgos
Planificación de la gestión de calidad
Planificación de la gestión del cambio, puede presentarse cambios

• La Estimación

No necesita realizarse  en una forma improvisada
La experiencia es una gran ayuda
La estimación implica un riesgo inherente,  y este conduce a la incertidumbre
El riesgo de la estimación implica un riesgo inherente, y este conduce a la incertidumbre
El riesgo de la estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas para recursos, costos y programas de trabajo.
Variabilidad en requisitos= inestabilidad

Un gestor no debe obsesionarse con las estimaciones.

Recursos: Divididos en cuatros categorías
Personal          importante
Componentes de software reutilizable  Recursos de software son reutilizables
Entorno

La Trinidad





 
Recurso Humano

El planificador debe especificar
Habilidades requeridas
Posición organizacional
Especialidad
El planificador puede estar geográficamente disperso


RECURSOS DE SOFTWARE REUTILIZABLE

• Ingeniería de software basada en componentes        

• Énfasis en la reutilización        ¿Qué hay? ¿Que existe?

• Componentes ya desarrollados

• Adquirir componentes de terceros

• Componentes experimentados: ya han sido probados

• Componentes de experiencia parcial : no han sido probados del todo

No inventar el agua tibia

RECURSOS DEL ENTORNO

Hardware
Software (herramientas de desarrollo)


ESTIMACIÓN

Plansoft= software para estimaciones para proyectos de software

Nunca es exacto
Mientras más se conozca menos errores serios se cometerán
Implica muchas variables
Técnicas
Ambientales
Políticas
Etc.

¿CÓMO LOGRAR ESTIMACIONES CONFIABLES?
Apoyarse  en proyectos similares

Descomposición simple : importante descomponer en tareas

Uso de modelos empíricos

ACTIVIDADES INDEPENDIENTES

Leer sobre el modelo Estratégico CocoMo.

Nota: La información consultada se encuentra en:

http://es.wikipedia.org/wiki/COCOMO

http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm

Crisis del Software

Plan perfecto. Prevención de Riesgos Laborales

Conceptos de Prevención de Riesgos Laborales

Riesgos del Software

ESTRATEGIAS UTILIZADAS

Se realizó una clase magistral sobre el tema, con elementos audiovisuales e interacción docente-alumnos en el análisis de textos alusivos.

ACTIVIDADES REALIZADAS

1.    Presentación de video sobre Conceptos de prevención de Riesgos Laborales.

2.    Explicación al video y relacionarlo con la ingeniería del software

3.    Presentación de video sobre Plan Perfecto. Prevención de Riesgos Laborales.

4.    Explicación sobre el video expuesto.

Después de ver el primer video se debatió  sobre la prevención de riesgos, se llego a unas series de conclusiones como de que los riesgos deben minimizarse lo más posible, se deben realizar una series de prevenciones entre ellas tenemos:

ü  Seguridad en el trabajo: Utilizar herramientas adecuadas y de buena calidad

ü  Higiene industrial

ü  Medicina laboral

ü  Formación: Proporcionar conocimientos

ü  Ergonomía

Luego de ver unas series de prevenciones se resalto algunos ítem entre ellos destacamos:

ü  Identificar donde está el riesgo.

ü  Prever todo riesgo, hay que atacarlos ante no después.

ü  Se definió que a nivel de software es fundamental tener en cuenta el personal y el negocio

Hay que tener en cuenta que algunos riesgos son predecibles.

Según Charette propuso otra categorización general de los riesgos entre ellos tenemos:

ü  Riesgos conocidos

ü  Riesgos predecibles

ü  Riesgos impredecibles

Como podemos identificar los riesgos existen métodos que consiste en crear una lista de verificación de riesgos. Con esta podemos identificar riesgos y enfocarnos en algún en algún subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:

ü  *Tamaño del producto: asociado al tamaño global del software que se construirá o modificara

ü  *Impacto en el negocio: asociados a las restricciones que impone la gerencia o el mercado

ü *Características del cliente: asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse  con él en una forma oportuna.

ü  *Definición del proceso: asociado con el grado en el que se ha definido el proceso de software y en que le da seguimiento la organización que lo desarrolla.

ü  *Entorno de desarrollo: asociado con la disponibilidad y calidad de las herramientas que se usaran en la construcción del producto

ü  *Tecnología que construir: asociado con la complejidad del sistema que se construirá y la novedad de la tecnología que esta empaquetada en el sistemas

ü  *Tamaño y experiencia en la plantilla de personal: asociado con la experiencia global técnica y en el proyecto de los ingenieros de software que harán el trabajo.

Los componentes de riesgos se definen de la siguiente forma:

ü  *Riesgo de desempeño: Grado de incertidumbre de que el producto satisfaga los requisitos y se ajuste al uso que se pretende darle

ü  *Riesgo de costo: Grado de incertidumbre que se mantenga el presupuesto  del proyecto

ü  *Riesgo de soporte: Grado de incertidumbre de que el software resultante será fácil de corregir, adaptar y mejorar

ü  *Riesgo de calendarización: Grado de incertidumbre de que se mantenga la calendarización del proyecto y de que el producto se entregue a tiempo

A contunuacion se relación la tabla de riesgo del libros de Roger Pressman:

 

ACTIVIDADES INDEPENDIENTES

Identificar todos los posibles riesgos en AS 4 piso de la UFPS en la tabla de Pressman.