REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA,

CIENCIA Y TECNOLOGIA
UNIVERSIDAD POLITECNICA TERRITORIAL “ARISTIDES BASTIDAS”
PROGRAMA NACIONAL DE FORMACIÓN EN INFORMÁTICA
INDEPENDENCIA - EDO YARACUY

Plan de Iteraciones del Sistema de

Información para la Administración de
Servicios Técnicos de equipos electrónicos en
Aguas de Yaracuy

Autores:
Delmoral, José 26.325.099
Gómez, Alejandro 26.602.566
Rojas, Jose 27.328.685
Ruiz, José 26.079.021

Independencia, Abril 2018

El desarrollo de sistemas intensivos en software, está basado en un proceso
iterativo e incremental, el cual consiste en la ejecución de las tareas de Inicio,
Elaboración, Construcción y Transición; en forma sucesiva sobre un número de
repeticiones o iteraciones.
El presente documento describe el Plan de Iteración previsto para el proyecto del
Sistema de Información para la Administración de Servicios Técnicos, para las
iteraciones. El Plan de Iteración aquí realizado busca recoger:
 Estado actual del proyecto: En especial los problemas no resueltos, las
fallas descubiertas y los porcentajes de evaluación de los artefactos.
 Artefactos a ser refinados en la iteración: Indicando los porcentajes de
evaluación que se han de alcanzar.
 Asignación de esfuerzo por roles y persona: Indicando las
responsabilidades de cada quien y la cantidad de horas hombre esperadas
en cada actividad.
 Requisitos Suplementarios y Riesgos identificados como relevantes, para la
iteración.
 Las pautas de evaluación sobre las que se determinaran los puntajes de
cada artefacto.
Al término de las iteraciones se realizarán las evaluaciones pertinentes, cuyos
resultados serán reseñados en este documento. La calidad se logra por medio de
la revisión constante de las actividades que conducen desde la idea al producto. Al
momento del cierre de una iteración es buen momento para hacer una pausa, y
evaluar lo logrado, los problemas encontrados y los retos a enfrentar.
El presente documento además marca el final de las iteraciones, y contiene
una evaluación de los artefactos y actividades realizadas durante la misma.
Se recogen también las impresiones y observaciones hechas durante el
desarrollo de la iteración, así como el esfuerzo invertido en cada una de las
disciplinas involucradas.
Código de la Iteración

Fase a la que pertenece

Fecha de Inicio
Fecha de Cierre
Comentarios

Metas
[Indicar los objetivos específicos que se persiguen con la iteración. Ejemplos:
refinar los modelos A y B, solucionar los errores C y D, compensar el tiempo
perdido o atraso, incorporar la información dada por la actividad X, etc.]

Disciplinas
 Disciplina Número 1: [¿Qué disciplinas son importantes en esta iteración?
Esta sección enumera y comenta las disciplinas que tengan la mayor carga
de trabajo prevista. Posiblemente se indicarían sus objetivos específicos o
las adaptaciones de método que configuren a estas disciplinas.]
 Disciplina Número N: [Si bien es cierto que en todas las iteraciones se
ejecutan en mayor o menor medida todas las disciplinas, lo cierto es que
solo es necesario dar detalles de aquellas en las que la iteración hace
mayor enfasis. Por ejemplo la fase de concepción tiene foco en las
disciplinas de requisitos, análisis y diseño; en tanto que construcción tiene
énfasis en las disciplinas de implementación y pruebas.]

Flujos de Trabajo
 Disciplina Número 1: [Si resulta de interés, se puede colocar aquí un flujo
de trabajo personalizado o adaptado para la disciplina indicada. Otra
alternativa es indicar un flujo de trabajo que ensamble en forma particular
las tareas previstas para la iteración. Ahora que si no hay un flujo de trabajo
personalizado entonces simplemente indicar “No aplica” o hacer referencia
al documento donde tenga definido sus procesos y flujos de trabajo de
referencia.]
  Disciplina Número N: [Así como en la sección “Disciplinas” no se cree que
sea necesario en ningún caso de tamaño razonable el tener que detallar
flujos de trabajo para mucho más que una o dos disciplinas. Tener que
comentar también que los flujos de trabajo personalizados para una
iteración no son obras de creatividad; son en realidad instancias de los
flujos generales de cada disciplina, organizados o parametrizados aquí
sobre que opción tomar en cada bifurcación que presente el flujo original.
MEDICIÓN Y ANÁLISIS: las opciones de pasos en los flujos de trabajo de
las disciplinas son un dato que debe ser recogido ya que refleja información
cuantitativa de interés para la gestión del proyecto.]

Requisitos de la Iteración
[El diccionario define requisito como “circunstancia o condición necesaria para una
cosa”. Aquí, se plantean tres puntos de vista para todas las circunstancias que
rodean la ejecución de la iteración:
 Requisitos exigidos por la iteración, condiciones previas necesarias para el
correcto inicio de la iteración. Esto es, “las entradas de la iteración”.
 Requisitos que se espera cumpla la iteración, condiciones que han de
verificarse al cumplimiento de esta. En otras palabras “las salidas de la
iteración”.
 Requisitos generales del proyecto que afectan la iteración. Simplemente,
las circunstancias en que esta se desarrolla y la forma en que serán
atendidas. En una palabra: “el contexto”.
La información antes señalada se estructura alrededor de los artefactos
involucrados, de los riesgos y problemas pertinentes. ]

Artefactos Actualizados
[Cierto es que RUP/UP no es un proceso centrado en artefactos ni orientado a la
documentación; pero no es menos cierto que es posible organizar mucho del
trabajo de una iteración si se saben cuáles artefactos se espera que se actualicen
en las tareas y actividades ejecutadas durante la iteración.
Señale aquí cuales son sus artefactos a actualizar.]
 Objetivo de la
Artefacto Actual Meta
Actualización
[Nombre del [Puntaje actual] [Puntaje meta] [Información a
Artefacto] incluir: Reporte de
Casos de Uso
XYZ, Realización
del Modelo ABC,
etc.]

Artefactos Abiertos
[Así como es útil pensar en las actualizaciones de los artefactos (ver sección
anterior) también es muy útil planificar cuales artefactos (documentos, modelos,
etc.) van a ser iniciados en una iteración. Los proyectos pequeños suelen ser
breves, por lo que el número de artefactos abiertos y actualizados por iteración es
grande. No se asuste entonces cuando llene la tabla para un proyecto pequeño y
encuentre que está repitiendo mucha de la información del caso de desarrollo.]
Artefacto Meta Comentarios
[Nombre del Artefacto] [Puntaje meta] [Información a incluir:
Reporte de Casos de Uso
XYZ, Realización del
Modelo ABC, etc.]

Reportes
[Los reportes son documentos que presentan un estado transitorio de un artefacto
o que capturan los resultados de una actividad sin otro resultado tangible.
Como los reportes por definición no se actualizan, no tiene sentido darle un
seguimiento a los puntajes de revisión de estos.]
Reporte Objetivo Comentarios
[Nombre del Reporte] [Asunto particular a ser [Razones que motivan la
tratado en el reporte] generación del reporte]
 Requisitos Suplementarios
[Referencia y comentarios sobre los requisitos suplementarios que tocan la
iteración que estamos planificando. Por ejemplo, los criterios de calidad pueden
ser enunciados aquí a lo largo de todo el proyecto como un “recordatorio” en tanto
que los requisitos suplementarios de usabilidad pueden ser repetidos aquí en las
iteraciones de la Fase de Inicio, donde se prototipo la interfaz. Los requisitos
suplementarios típicamente están contenidos en un artefacto por lo que no es
valido expresar aquí estos más que como referencia. Esta tabla no captura
requisitos, los realza de manera de poner en evidencia la pertinencia de estos
durante las actividades y tareas de la iteración.]
Requisito Grado Comentarios
[Nombre del Requisito] [Grado: Alto, Medio, Bajo] [Indicaciones sobre
como cumplir con el
requisito suplementario
aquí señalado.]

Riesgos
[Esta es una tabla provisional, la verdad no estoy aún seguro de cuál es la mejor
forma de resumir los riesgos y de presentarlos a la hora de un plan de iteración.
Modifique por tanto esta sección según su mejor saber y entender. Un ejemplo
armado con la tabla actual es: El riesgo de cambio inesperado de requisitos
consiste en recibir un comentario negativo de los stakeholders se origina en la
presentación del prototipo de interfaz de usuario se verifica si al Sr. Perez le
disgusta la interfaz impacta en equipo de diseño de interfaces se mitiga si se
cuidan los aspectos de comunicación durante la presentación de presentarse
informar a la gerencia del proyecto]
El Riesgo de
Consiste en
Se origina en
 Se verifica si
Se mitiga si
Impacta en
De presentarse
Su probabilidad es

Problemas a Resolver
[Notas y comentarios varios sobre los problemas pendientes y lo que se ha
discutido sobre ellos; en formato libre.]

Asignación de Recursos
[Durante las iteraciones es frecuente necesitar no solo de una cierta cantidad de
horas de esfuerzo, sino también recursos materiales y servicios de contratistas. La
presente sección detalla lo que se ha podido planificar en cuanto a asignación y
procura de aquellos recursos requeridos por las actividades de incluidas en la
iteración.]

RR.HH.
[El esfuerzo humano invertido en el proyecto viene de nuestros trabajadores, tanto
de los que son personal interno de la organización de desarrollo como de los que
se han contratado a terceras partes. Anote para cada rol la cantidad estimada de
esfuerzo y las personas que van a atacar estas actividades.]
El Rol de Esfuerzo estimado A desempeñar por
[Cantidad en horas [Listado de nombres que
[Nombre del Rol]
hombre] en potencia
han de cumplir este Rol]

Procura de Recursos
[Equipos adicionales, libros, material de oficina, etc. Cualquier cosa material que
se deba comprar o alquilar para efectuar una actividad dentro de la iteración.]
Para la Actividad Se requiere de Para la fecha Debido a
 [Nombre y [Fecha tope
[Nombre de la [Breve comentario
Cantidad del para incorporar
Actividad] del uso del Articulo]
Articulo requerido] el Articulo]

Otros Recursos
[Según aplique.]

Pautas de Evaluación
[La evaluación es una actividad necesariamente subjetiva. Sin embargo, si se dan
parámetros ciertos y se limitan los rangos de puntuación a valores pequeños, es
factible obtener estimaciones semi-cuantitativas, que a la larga sirvan para obtener
una visión estadística de la situación y avance del proyecto.
Estas pautas de evaluación se organizan por artefacto y actividad, presentando
para cada una de ellas la siguiente información:
 Nombre del aspecto a evaluar.
 Rango número en que se determinara la nota.
 Peso que se le da al aspecto. Este número puede cambiar de iteración en
iteración.
 Comentarios u observaciones que aclaran la forma de aplicar el aspecto.
En cualquier caso, hay que considerar a las pautas de evaluación como una ayuda
a quien realiza la actividad. Saber que es lo importante para la evaluación es una
gran ayuda para sacar mejor nota.]

Nombre del Artefacto Número 1

[La siguiente tabla detalla los aspectos a evaluar en los resultados de la Iteración.
Detallando el rango numérico o nota con que se califica, el cual siempre comienza
en cero; el multiplicador o peso específico del criterio, y un comentario indicando el
porque de la importancia del aspecto.]
Aspecto a
Rango Peso Comentarios Nota Final
Evaluar
 Hitos Especiales

Hito Número 1
[Informe de lo ocurrido en los hitos señalados en el Plan de Iteración; es decir que
aquí tendremos un título 3 por cada hito que se identifico en el plan de iteración.
Para cada hito basta con decir si ocurrió o no, y una breve descripción o reseña
del mismo.]

Riesgos y Problemas
[Informe de lo ocurrido en la iteración, en términos generales.]

Notas y Observaciones
[Informe de lo ocurrido en la iteración, en términos generales.]

Anexos
Título del primer anexo
[Según aplique.]

Referencias a otros documentos

[Insumos
Plan de Desarrollo de Software versión 1.0 al 1 de febrero de 2007
Visión del Sistema versión 2.2 al 15 de marzo de 2007
Requisitos Suplementarios versión 1.1 al 20 de marzo de 2007
Documentos derivados
Cierre de la iteración I2 al 30 de abril de 2007]

Glosario de términos
[El estilo recomendado para llevar el glosario como anexo de múltiples
documentos es enumerar los términos definidos aquí, más no copiar las
definiciones. En todos los casos las definiciones completas han de estar en un
solo documento: Glosario del Sistema]
 Significado de los elementos de la notación gráfica

Estereotipado UML utilizado

[Si el documento contiene diagramas UML que utilicen algún estereotipo en
particular, se deben indicar aquí su significado y reglas de uso]

Significado de los elementos No UML

[En ocasiones los documentos hacen uso de notaciones gráficas distintas al UML
– por ejemplo diagramas E/R Cuando sea conveniente, se indican aquí las reglas
para interpretar estas convenciones gráficas adicionales]