Trabajo planeamiento

CALENDARIZACION DE PROYECTOS DE SOFTWARE Resumen-Solución Problemas

Planeamiento y Administración de Proyectos Informáticos

Alumna: Rueda Zapata Yosely Jannet

X CICLO –ING. Informática

CALENDARIZACION DE PROYECTOS DE SOFTWARE

2013

Página 2


Uno de los problemas que se ha incrementado es el retraso de la entrega del

software y las justificaciones salen a relucir quizás esto se debe a la poca

valoración que se le suele dar al a tiempo, o los constantes cambios que se le

suelen dar a los requerimientos, o quizás algún tipo de dificultades técnicas etc.

Las fechas límites muy adecuadas son un hecho de la vida en el negocio del

software, por ello se debe tener en cuenta los hechos que ocurren con frecuencia

como:

Es irreal presentarse en la oficina de alguien, en este caso supongamos que es el

cliente,

Y demandarle que cambie la fecha de entrega, para ello debemos tener en cuenta

los siguientes puntos los cuales son importantes:

1. Realizar una estimación detallada tomando en cuenta la realización de

proyectos previos

2. Reunirse con el cliente y explicarle el porqué de la fecha límite, y

asegurarse que todas las estimaciones están basadas en las estimaciones

de proyectos previos

3. Ofrezca la estrategia de desarrollo incremental, como alternativa.

La realidad de un proyecto técnico es que siento de pequeñas tareas deben

realizarse para lograr una meta mayor, alguna de tales tareas están fuera de la

corriente principal , y se pueden completar sin preocuparse acerca de su impacto ,

sobre la fecha de determinación del proyecto .

La calendarización de proyectos de software es una actividad que distribuye

estimaciones de esfuerzo a través de la duración planificada del proyecto al

asignar el esfuerzo a tareas especificas de ingeniería de software , sin embargo es

importante señalar que la calendarización evoluciona a lo largo del tiempo, y tener

en cuenta que durante las primeras etapas del desarrollo del proyecto se

desarrolla una calendarización macroscópica, este tipo de calendarización

identifica las principales actividades del marco de trabajo , del proceso y las

funciones del producto a las que se aplican , conforme es proyecto transcurre

cada entrada en la calendarización macroscópica se refina en un la


2013

Página 3

calendarización mas detallada, aquí se identifican y calendarizan tareas

especificas de software (requeridas para completar alguna actividad).

Principios básicos

Compartimentación: el proyecto debe dividirse en compartimiento en varias

actividades, acciones y tareas manejables lograrlo requiere descomponer tanto el

producto como el proceso

Interdependencia: se debe determinar la interdependencia de cada actividad o

tarea compartimentada, algunas tareas deben ocurrir en secuencia mientras que

otras deben ocurrir en paralelo.

Asignación de tiempo

A cada tarea por calendarizar se le debe asignar cierto número de tareas de

trabajo (Personas días de esfuerzo)

Validación del esfuerzo: todo proyecto tiene un número definido de personas en el

equipo de software, a medida que transcurre el tiempo el mismo gestor debe

percatarse que no se han asignado un número excesivo de personas para realizar

cierta tarea

Definición de responsabilidades

Toda tarea calendarizada se le debe asignar a un miembro específico del equipo.

Definición de resultados

Toda tarea calendarizada debe tener un resultado definido, en proyectos

de software el resultado mayormente es un producto de trabajo (Por ejemplo el

diseño de un modulo)

Definición de hitos

Cualquier tarea o conjunto de tareas debe estar asociada con un hito de

proyecto un hito se logra cuando se ha realizado la calidad de uno o más de uno

proyectos de trabajo.

Relación entre el personal y el esfuerzo

En un pequeño proyecto de desarrollo de software una sola persona puede

analizar los requisitos realizar el diseño y generar el código y dirigir las pruebas

conforme aumenta el tamaño del proyecto, más gente resulta involucrada, existe


2013

Página 4

un mito muy común que dice, si nos retrasamos, si nos retrasamos en la

calendarización siempre podremos incorporar mas programadores y recuperarnos

más adelante en el proyecto ,desgraciadamente incorporar más personas aun

proyecto el cual se encuentra retrasado tienen un efecto perturbador , sobre este

lo que provoca que la calendarización se desfase aun mas, el nuevo personal

debe aprender el sistema y las personas que les enseñan es la misma que está

haciendo el trabajo, durante la enseñanza no se realiza trabajo y el proyecto

experimenta mayores retrasos

Refinamiento de las tareas principales

Las tareas principales descritas en la sección precedente, se pueden utilizar

para definir la calendarización macroscópica de un proyecto sin embargo esta

calendarización se debe refinar para crear una calendarización detallada del

proyecto. El refinanciamiento comienza al tomar cada tarea principal y

descomponerla en un subconjunto de tareas(con productos de trabajo e hitos

relacionados ).


2013

Página 5

DESARROLLO DE PREGUNTAS CAP 24

24.1.- las fechas límite “irracionales” son un hecho de la vida en el negocio del software ¿Cómo

se debe proceder si se enfrenta con una?

Esto es uno de los problemas que con mayor concurrencia se presenta es el tema de las fecha de

entrega o las fechas límite como se les suele llamar en algunas ocasiones , existen percances por

los cuales se da el retraso de la entrega del software por ejemplo :

el constante cambio de los requerimientos

los equipos con los que se trabaja de muy bajo nivel

incluso mucha veces por la falta de personal

Es por ello que se debe prever un análisis que nos permita adecuar la fecha precisa en que se

puede entregar el software teniendo en cuenta que el cliente siempre debe quedar satisfecho con

el producto que se le entregara.

Una solución adecuada para este tipo de problemas seria estar en constante comunicación con el

cliente para darle a conocer los puntos críticos del desarrollo para que él también se involucre el

hecho de obtener un producto en el tiempo preciso.

24.2.-¿CUAL ES LA DIFERENCIA ENTRE UNA CALENDARIZACION MACROSCOPICA Y UNA

CALENDARIZACION DETALLADA?¿ES POSIBLE GESTIONAR UN PROYECTO SI SOLO SE

DESARROLLAUNA CALENDARIZACION MACROSCOPICA?¿PORQUE?

a) La calendarización Macroscópica identifica las principales actividades del marco de trabajo del

proceso y las funciones de producto a las que se aplican, se realiza durante las primeras etapas de

la planificación del proyecto mientras que La calendarización Detallada se identifica y

calendarizan tareas específicas de software, requeridas para completar una actividad.

b) No es posible, Porque que ambas calendarizaciones complementan el buen desarrollo de

software. Al empezar siempre se da una vista general del proyecto, se identifican los puntos

principales. Pero ya cuando se va entrado a fondo del desarrollo y se ha visto partes

fundamentales y tareas importantes del proyecto es ahí entonces donde se va ampliando el

estudio del mismo y se detallan tareas a seguir. Pues en conclusión una no se puede dar sin la otra.


2013

Página 6

24.3 existe algún caso en el que un hito de un proyecto de software no esté ligado a una

revisión, si es así ofrecer uno o más ejemplos

Los hitos son significativos para el proyecto por lo tanto es conveniente que estén relacionados

con una revisión ya sea un hito relacionados con el análisis, diseño, programación y prueba,

Los hitos son importantes ya que nos permite verificar el camino en el que se enfoca nuestro

proyecto, aunque un modelo iterativo es el mejor marco de trabajo para un proyecto, el

paralelismo de las tareas dificulta el seguimiento del proyecto y es ahí donde el gestor del

proyecto puede tener dificultades al establecer hitos significativos para un proyecto debido a

varias cosas diferentes que ocurren a la vez

24.4.-La sobrecarga de comunicación puede ocurrir cuando muchas personas trabajan en un

proyecto de software, el tiempo empleado de la comunicación con otros reduce el tiempo de la

productividad individual, y el resultado es menor productividad para el equipo ilustrar

cuantitativamente como los ingenieros versados en las buenas prácticas de ingeniería de

software Y que usa n revisiones técnicas formales pueden aumentar la tasa de producción de un

equipo Cuando se compara con la suma de las tasas de producción individuales sugerencia: se

puede suponer que las revisiones reducen la reelaboración y que esta puede explicar el 20-40

porciento de una persona

Existe una enorme diferencia entre los desarrolladores de software y la estimación de ellos con

respecto al valor que le atribuyen al tiempo de desarrollo de software a menudo el intercambio

de ideas involucra mucha pérdida de tiempo para poder encontrar la solución algún problema que

se ha originado a medida que avanza.

Muchos de los problemas detectados en las etapas de construcción o prueba de los sistemas se

deben a problemas en las etapas de análisis, especificación o diseño. La realización de revisiones

formales a los documentos asociados a las distintas etapas del ciclo de desarrollo del software

(especificación de requerimientos, diseño, etc.) permiten:

Obtener de alertas tempranas sobre potenciales riesgos y problemas de calidad.

Reducir los tiempos de desarrollo y testing al evitar re trabajos.

Generar estándares útiles para los distintos ciclos de desarrollo.

Las revisiones técnicas formales validan la completitud y corrección de los entregables de un

proyecto, previniendo en forma temprana sobre potenciales problemas y riesgos que puedan

derivarse en etapas posteriores del proyecto: inconsistencias, ambigüedades, no cumplimiento de

estándares, etc (evaluaciones durante el armado del proyecto, durante el proyecto y post-

proyecto)

El servicio consiste en la revisión formal de la documentación de Arquitectura, Diseño,

Requerimientos, Modelo de Datos, etc. con el objetivo de:


2013

Página 7

Verificar la consistencia interna de la documentación y su coherencia con los

requerimientos.

Verificar el cumplimiento de estándares del cliente.

Validar la completitud y facilidad de lectura de la documentación.

Proponer mejoras, agregados, y estándares nuevos.

24.5.-AUNQUE AGREGUE PERSONAL A UN PROYECTO DE SOFTWARE RETRASADO, PUEDO

RETRASARLO MAS, EXISTEN CIRCUNSTANCIAS EN LAS CUALES ESTO NO ES CIERTO DESCRIBANCE

El número de canales de comunicación diferentes aumenta con el número de personas de forma

exponencial; si se dobla el número de personas en el proyecto, el resultado es 4 veces más

conversaciones.

La cantidad, calidad y papel de la gente que se incorpora al proyecto son factores a tener en

cuenta. Los buenos programadores o especialistas se pueden incorporar con menos necesidad de

tiempo para su formación. También se puede incorporar personal para realizar otras tareas

relacionadas con el proyecto, por ejemplo documentación o garantía de calidad en caso de que la

tarea esté disponible, así se disminuye el tiempo de la rampa de subida.

Los problemas menores se resuelven en equipos pequeños y un equipo superior es responsable

de la integración del sistema. Para poder trabajar así es necesario segmentar el problema de forma

correcta; en caso contrario, puede empeorar el problema, impidiendo la comunicación entre los

programadores que trabajan en diferentes partes del problema que están directamente

relacionados, aunque el plan del proyecto afirme que no los están.

Tenemos que tener en en cuenta que desgraciadamente, agregar más personas en etapas tardías

de un proyecto con frecuencia tiene un efecto perturbador sobre este, lo que provoca que la

calendarización se desfase a un mas, las personas que se agregan deben aprender el sistema y la

gente que les enseña es la misma que está haciendo el trabajo , durante la enseñanza no se realiza

el trabajo y el proyecto experimenta mayor retraso.


2013

Página 8

24.6 la relación entre personal y tiempo es enormemente no lineal. Mediante la ecuación del

software de Putnam (descrita en la sección 24.2.2) desarrollar una tabla que relacione el número

de personas con la duración del proyecto para un proyecto de software que requiera 50 000 LDC

15 personas-año de esfuerzo el parámetro de productividad es 5000 supóngase que el software

debe entregarse en un máximo de 24 meses o un mínimo de 12.

La relación número de personas/productividad no es lineal. Si se juntan 4 programadores, y cada

uno produce 500 LDC por mes, el equipo no producirá 2,000 LDC por mes. La comunicación cuesta.

La relación esfuerzo/tiempo no es lineal. Usando la ecuación del software de Putnam-Myers, con

LDC = 40,000, B = 0.28, P = 12,000 y T = 1 año, se obtiene el esfuerzo E.

E = (40,000 * 0.280.333 / 12,000)3 * (1 / 1)4 = 11 hombres-año

Si se extendiera la fecha de entrega a 1.5 años, el esfuerzo es:

E = (40,000 * 0.280.333 / 12,000)3 * (1 / 1.5)4 = 2 hombres-año

Aumentando el tiempo en 6 meses, el esfuerzo se redujo a la quinta parte.

Regla del 40-20-40. Una distribución recomendada es dedicar el 40% a las tareas de análisis y

desarrollo, el 20% a la codificación y el 40% a las pruebas. Esta distribución sólo marca directrices,

no es ley.

http://148.225.83.24/ic2/ic2apuntes/estimacion.html#espm


2013

Página 9

24.7.- Suponga que una universidad lo ha contratado para desarrollar un sistema de registro en línea a cursos (SRELC). Primero, actúe como el cliente (si es estudiante ¡esto debe ser sencillo!) y especifique las características de un buen sistema. Por medio de los métodos de estimación tratados en el capítulo 23, desarrolle una estimación del esfuerzo y la duración para el SRELC. Sugiera como: Definiría las actividades de trabajo paralelas durante el proyecto de SRELC Requerimientos generales

Consultar los horarios de los cursos

Consultar la programación de los exámenes

Actualizar y ver su información personal.

Consultar Notas

Requerimientos Funcionales del sistema académico

Número Requerimiento Descripción Prioridad

RF1 LA ADMINISTRACION LLEVARA UN CONTROL DE NOTAS DE LOS ALUMNOS

El sistema tendrá las notas de los alumnos en cada curso que ha llevado y que esta cursando actualmente,

5

RF2 EL ADMINISTRADOR PODRA MODIFICAR LAS NOTAS

El sistema deberá permitir la modificación de las notas del curso del ciclo vigente

5

RF3 VIZUALIZAR LA RELACION DE CURSOS Y NOTAS.

El sistema proporcionara al Profesor y al Alumno la información de notas de los cursos del ciclo vigente

4

RF4 TENER UN CONTROL DE LA INFORMACION DE LOS PAGOS

El sistema proporcionara los datos de los pagos realizados por el alumno.

4

RF5 GENERACION DE INFORMES Y REPORTES

Con los informes se podrá obtener resultados detallados sobre las notas del curso, notas por evaluación, además del promedio final, grado académico, clasificarlos por alumno, área, fecha, etc. Estos podrán ser impresos.

4

RF6 GENERACION DE USUARIOS CURSOS Y CICLOS PARA LA ADMINISTRACIOND EL SISTEMA

El sistema permitirá el ingreso de nuevos usuarios en cualquiera de las tres categorías, ciclos academicos y cursos para cada programa.

4

ç


2013

Página 10

Requerimientos No Funcionales del sistema académico

Número Requerimiento Descripción Prioridad

RF1 LA ADMINISTRACION LLEVARA UN CONTROL DE NOTAS DE LOS ALUMNOS

El sistema tendrá las notas de los alumnos en cada curso que ha llevado y que esta cursando actualmente,

5

RF2 EL ADMINISTRADOR PODRA MODIFICAR LAS NOTAS

El sistema deberá permitir la modificación de las notas del curso del ciclo vigente

5

RF3 VIZUALIZAR LA RELACION DE CURSOS Y NOTAS.

El sistema proporcionara al Profesor y al Alumno la información de notas de los cursos del ciclo vigente

4

RF4 TENER UN CONTROL DE LA INFORMACION DE LOS PAGOS

El sistema proporcionara los datos de los pagos realizados por el alumno.

4

RF5 GENERACION DE INFORMES Y REPORTES

Con los informes se podrá obtener resultados detallados sobre las notas del curso, notas por evaluación, además del promedio final, grado académico, clasificarlos por alumno, área, fecha, etc. Estos podrán ser impresos.

4

RF6 GENERACION DE USUARIOS CURSOS Y CICLOS PARA LA ADMINISTRACIOND EL SISTEMA

El sistema permitirá el ingreso de nuevos usuarios en cualquiera de las tres categorías, ciclos académicos y cursos para cada programa.

4

Para tener claras las tareas que se llevaran a cabo paralelamente, definiría todas las tareas, así

como su respectiva prioridad entre pequeñas tareas y tareas criticas. Construyendo una red de

bosquejo de desarrollo que especifique las tareas trascendentales, aquellas que necesitan de

cuidado y tiempo único y aquellas que se pueden llevar paralelamente.

Por ejemplo en este caso definimos las tareas:

Recolección de Datos

Recolección y revisión de información y requerimientos

Consiste en la recolección y revisión de toda la información

necesaria para el total entendimiento de este desarrollo de

sistema de registro de cursos en línea.


2013

Página 11

Análisis

Determinar los Procesos relacionados con el sistema.

En esta actividad se determinarán aquellos procesos del negocio

que se automatizarán y serán implementados en el nuevo

sistema.

Aplicar Encuestas.

En esta actividad se aplicaran encuestas para tener conocimiento

como llevar a cabo la realización de tareas de registro y gestión

en línea a los alumnos de esta universidad y que beneficios se

obtendría contando con un sistema web para el registro de

cursos.

Análisis del estado actual de los procesos para el registro de cursos

en la universidad.

Con la información obtenida en las encuestas obtendremos una

clara visión de los procesos actuales que se llevan para el registro

de cursos de los alumnos analizando el estado en el que se

encuentra.

Definición y Descripción de Casos de Uso

En esta actividad se definirán los casos de usos del sistema, se

procederá a la descripción de cada uno de ellos, así como su

respectiva diagramación.

Diseñar diagrama de clases

En esta actividad se elaborará el diagrama de clases del nuevo

sistema. Este diagrama es importante debido a que permite

visualizar las relaciones entre las entidades que involucrará el

sistema.

Diseñar Diagrama de Secuencia

En esta actividad se elaborará el diagrama de secuencia del nuevo

sistema, el cual permite representar en forma gráfica la secuencia de

eventos y describe paso a paso la interacción entre cada uno de los

procesos.


2013

Página 12

Diseño

Modelado de la base de datos del sistema.

Actividad que consiste en formar, analizar, regularizar o poner en

orden los diferentes Datos o información que se va a utilizar en el

sistema, además de modelar las tablas que contendrán la

información, los tipos de datos que serán almacenados, así como

las relaciones entre estas.

Diseñar interfaces de usuario

Escoger los modelos adecuados de diseño (ventanas) que se

visualizaran en el sistema de tal manera que el manejo del

sistema sea fácil y flexible al usuario final.

Diseño de módulos.

Escoger los modelos adecuados de diseño (módulos) de tal

manera que el manejo del sistema sea fácil y flexible.

Elaborar diagrama de navegación.

En esta actividad se elaborará el diagrama de navegación el cual

permitirá saber cómo están enlazadas las páginas del sistema a

desarrollar.

Codificación

Codificación del sistema

En esta actividad se escribirán las líneas de código necesarias

para la creación del sistema.

Documentación de la Codificación

En esta actividad se escribirán las líneas de código necesarias

para la creación del sistema.

Implementación

Instalación y configuración de la plataforma.

En esta actividad se instalará en el servidor la plataforma sobre

la que se ejecutará el nuevo sistema.


2013

Página 13

Instalación del sistema

En esta actividad se procederá a la instalación y puesta en

marcha del nuevo sistema.

Pruebas

En esta actividad se probará el nuevo sistema simulando un

trabajo normal, además de simulaciones bajo citaciones

inesperadas y bajo un fuerte rendimiento.

Se aprobará el sistema si todas las pruebas son correctas, caso

contrario, se realizarán las correcciones respectivas.

24.8.-SELECCIONE UN CONJUNTO DE TAREAS APROPIADO PARA EL PROYECTO DEL SRELC

Una red de tareas es una representación grafica del flujo de tareas en un proyecto.

1.1.1 identificar necesidades y beneficios

Reunirse con el cliente

Identificar necesidades del proyecto

Identificar restricciones y limitaciones del proyecto

Establecer enunciado del producto

hito: enunciado del producto definido

1.1.2 definir salidas/control/entradas(sce)deseadas

Alcance de lo que el usuario debe ingresar

Alcance de las funciones de iteración

Alcance de lo que se debe mostrar

Hito: sce definidas

1.1.3 definir funciones /comportamiento

Definir funciones de entrada

Definir funciones de iteración

Definir funciones de salida

Modificar conforme se requiera

Hito definición completa de sce

1.1.4 aislamiento de elementos de software

Hito: elemento de software definidos

1.1.5 investigar disponibilidad de software existente

Investigar facilidad de uso


2013

Página 14

1.1.6 hito factibilidad técnica valorada

1.1.7 Revisión rápida

Revisión de requerimientos

Modificar requerimientos

Hito documento de ámbito completado


2013

Página 15

24.9.- Defina una red de tarea para el SRELC o alternativamente para otro proyecto de software que le interese. Asegúrese de mostrar las tareas e hitos y de

vincular las estimaciones de esfuerzo y duración a cada tarea si es posible utilice una herramienta automatizada de calendarización para realizar el trabajo.

Definición del

Proyecto

SRELC-UNP

Recolección de

datos

Definición de

requerimientos

Análisis

Evaluación de

riesgos

Análisis

Evaluación de

riesgos

Diseño

Análisis

Codificación

Por

módulos: 3

Implantación

de modulo 3

Implantación

de modulo 1

Implantación

de modulo 2 Integración

de los

módulos 1,

2, 3

Puesta en

marcha

Implantación

de conceptos

24.10.- Si está disponible una herramienta automatizada de calendarización determine la

trayectoria critica para la red definida en el problema 24.9 Red detallada

Tareas Precedencia Tiempo Personal a trabajar

A Recolección de datos - 1 semanas 1

B Análisis A 2 semanas 2

C Diseño B 2 semanas 2

D Codificación C 4 semanas 5

E Implementación D 2 semanas 3

F Pruebas E 1 semana 2

G Capacitación F 1 semana 1

Implantación

de modulo 3

Implantación

de modulo 1

Implantación

de modulo 2 Integración

de los

módulos 1,

2, 3

Puesta en

marcha

Inicio A

B

C

D

E

F

G Fin

0 0 0 1

1 2

1

2

3 5

4 6

5 9

6 10

3

1 3

2 4

9 11

9 11

9 10

10 11

1112

11 12

12 12

12 1 2


2013

Página 17

24.11 Desarrolle un cronograma para el proyecto SRELC

TAREAS DE TRABAJO S1 S2 S3 S4 S5

1.1.1 identificar necesidades y beneficios

x

Reunirse con el cliente

x

Identificar necesidades del proyecto Identificar restricciones y limitaciones del proyecto

x

Establecer enunciado del producto

x

hito: enunciado del producto definido

x

1.1.2 definir salidas/control/entradas(sce)deseadas

x

Alcance de lo que el usuario debe ingresar

x

Alcance de las funciones de iteración

x

Alcance de lo que se debe mostrar

x

Hito: sce definidas

x

1.1.3 definir funciones /comportamiento

x

Definir funciones de entrada

x

Definir funciones de iteración

x

Definir funciones de salida

x

Modificar conforme se requiera

x

Hito definición completa de sce

x

1.1.4 aislamiento de elementos de x


2013

Página 18

software

Hito: elemento de software definidos

x

1.1.5 investigar disponibilidad de software existente

x

Investigar facilidad de uso

x

1.1.6 hito factibilidad técnica valorada

x

1.1.7 Revisión rápida

x

Revisión de requerimientos

x

Modificar requerimientos

x

Hito documento de ámbito completado

x

Trabajo planeamiento

Technology

Transcript of Trabajo planeamiento