ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

Ensayo


Enviado por   •  9 de Septiembre de 2015  •  Ensayos  •  1.907 Palabras (8 Páginas)  •  167 Visitas

Página 1 de 8

Para producir un plan de requerimientos, se debe cumplir con cinco condiciones, las cuales son:

  • Accesibilidad: Para ser accesible, un plan debe proporcionar la información necesaria para que pueda ser encontrado; debe estar en el formato adecuado; y no debe estar atestado de material extraño. A pesar de tener un plan completo es importante mencionar que los planes voluminosos son difíciles de manejar. Es necesario poder encontrar rápidamente el horario, o plan inicial y todas las revisiones posteriores. Los datos de defectos deben ser claros, y los datos del tamaño del programa deben estar disponibles para todas las versiones del programa. Por conveniencia, estos datos deben estar en un orden prescrito y en un formato conocido, consistente, y no redundante.
  • Claridad: En los documentos no se deben dejan dejar vacíos, inconsistencias. A veces, incluso notas incomprensibles están apuntadas en los márgenes. Si los datos no son completos e inequívocamente claros, no se pueden utilizar con confianza. Si no se pueden utilizar con confianza, no hay ningún punto en la recolección de ellos en absoluto.
  • Especificidad: Un plan con especificidad identifica lo que se hará, cuándo, por quién, y a qué costos. Si estos elementos no son claros, el plan no es específico.
  • Precisión: La precisión es una cuestión de relacionar la unidad de medida a la magnitud total de la medición. Si, por ejemplo, se analiza un proyecto que tomó 14 años programador, la administración no estaría interesada en unidades de minutos, horas o incluso días, probablemente. De hecho, semanas programador probablemente sería el mejor nivel de detalle que se podría considerar útil.
  • Exactitud: Aunque los otros cuatro puntos son todos importantes, la precisión es crucial. Una preocupación principal del proceso de planificación es producir planes con precisión predecible. Al planificar tareas en PSP, no hay que preocuparse demasiado acerca de los errores en cada pequeña tarea, siempre y cuando parezcan al azar.

Como desarrolladores, todos usamos ambos planes de proyecto y planes de periodo. Un plan de periodo consta de un calendario de días, semanas, meses o años. Involucra actividades que se programan calendáricamente. Las empresas también funcionan con planes de periodo, ellos pagan los salarios a intervalos regulares, facturan periódicamente a los clientes, y pagan dividendos cada trimestre. También vivimos en un mundo periódico, comemos y dormimos a intervalos regulares y trabajamos en días específicos de la semana. Las estimaciones y los planes del proyecto cubren el esfuerzo y el coste de desarrollar productos.

Los productos pueden ser tangibles, como los programas y libros, o intangibles como los diseños y planes de prueba. Los planes del proyecto son impulsados por las necesidades del trabajo. Algunas tareas deben preceder a otras, y varios entregables pueden ser producidos sólo cuando el trabajo de preparación adecuado se ha hecho.

Para hacer un cronograma del proyecto, es necesario difundir el trabajo previsto para el tiempo disponible. Esta asignación de tareas del proyecto con el calendario se convierte en el cronograma del proyecto. Es un elemento clave del plan del proyecto. Para hacer un horario, se debe estimar el esfuerzo necesario para hacer la totalidad del trabajo. Luego asignar estas horas a las diversas tareas del proyecto.

Esto supone que el trabajo para la nueva tarea se distribuirá de la misma forma en que fue para las tareas anteriores. También supone que cada fase del proyecto requiere una sola tarea. Para los pequeños proyectos como los ejercicios de PSP, los proyectos son lo suficientemente pequeño que las fases pueden ser consideradas como tareas individuales.

Para proyectos de equipo más grandes, normalmente hay muchas tareas por fase, y cada proyecto generalmente tiene una diferente distribución de fechas y tiempos. La clave está en realizar un seguimiento de los datos de tiempo y tamaño para cada tipo de tarea y utilizar estos datos para hacer estimaciones PROBE cada vez que tenga los datos para hacerlo. Incluso si sólo tiene datos en una tarea e incluso si estos datos son sólo para un miembro del equipo, puede utilizar los datos hasta que haya suficientes datos personales para hacer una estimación PROBE.

Incluso si es necesario utilizar los datos de otra persona, su estimación será mejor que una conjetura. En un caso, un gran equipo debía estimar el trabajo de diseño para la siguiente fase del proyecto; habían completado la fase de requerimientos y concluyeron que había alrededor de 600 clases para diseñar en la siguiente fase. El equipo se mostró reacio a adivinar el tiempo requerido para diseñar una clase, ya que entonces se multiplicaría un valor al azar por 600. Uno de los desarrolladores tenía datos sobre dos clases que ya había diseñado, el equipo utilizó sus datos para la estimación y el resultado fue de aproximadamente 10% del tiempo real que el equipo gasto.

En un equipo de TSP, las horas dedicadas a las tareas planificadas se denominan horas de trabajo. Aunque usted puede trabajar en muchas otras actividades relacionadas con el proyecto, si estas actividades no son tareas específicas en su plan, no son contadas como tiempo de trabajo. Las horas de trabajo son parte del plan del proyecto, y las horas de trabajo normales son parte del plan de período.

Antes de estimar horas de trabajo semanales, tener en cuenta el número de horas de trabajo en un año. Un año de 52 semanas de semana de 40 horas cuenta con 2.080 horas de trabajo. Tras considerar las vacaciones, días de fiesta, enfermedades y el tiempo personal, las horas de trabajo se cortan generalmente por 10% a 15%. Además, en la mayoría de las organizaciones de ingeniería, los desarrolladores pasan de 20 a 25 horas a la semana en reuniones, manejo de correo electrónico, consultando otros proyectos, ayudando en la comercialización, o la realización de cualquiera de los otros miles de tareas que generalmente deben hacer. En una típica semana laboral de 40 horas, no es inusual que los desarrolladores sólo desarrollen alrededor de 12 a 15 horas de trabajo. Hay muchos factores que afectan a estas horas, y van a variar sustancialmente entre los individuos e incluso de una semana a otra.

...

Descargar como (para miembros actualizados)  txt (11.6 Kb)   pdf (93.2 Kb)   docx (14.9 Kb)  
Leer 7 páginas más »
Disponible sólo en Clubensayos.com