Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Versión <1.0>
[Nota: La siguiente plantilla es provista para el uso con el Rational Unified Process. El texto encerrado en
paréntesis cuadrados y desplegado en azul itálico (Estilo=InfoBlue) esta incluido para ser una guía al
autor y debe ser borrado antes de publicar el documento. Un párrafo introducido siguiendo este estilo se
establecerá como normal (Estilo=Body Text).]
[Para personalizar los campos automáticos (los cuales despliegan un fondo gris cuando se seleccionan),
seleccione Archivo>Propiedades y reemplace los campos de Título, Asunto y Organización con la
información apropiada para este documento. Después de cerrar el dialogo, los campos automáticos deben
ser actualizados a través del documento al seleccionar Edición->Seleccionar todo (o Ctrl_E) y luego se
debe oprimir la tecla F9 o simplemente click sobre cada uno de los campos y presione F9. Esto debe
hacerse separadamente para encabezados y pie de página. Alt-F9 cambiar entre el despliegue del nombre
del campo y su contenido. Consultar la ayuda de Word para mayor información para trabajar con
campos. ]
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO
Historial de Revisiones
Fecha Versión Descripción Autor
<dd/mmm/yy> <x.x> <detalles> <nombre>
Tabla de Contenidos
1. Introducción 2
1.1 Propósito 2
1.2 Alcance 2
1.3 Definiciones, Acrónimos y Abreviaturas 2
1.4 Referencias 2
1.5 Resumen 2
6. Restricciones 2
7. Rangos de calidad 2
8. Precedencia y prioridad 2
Visión
1. Introducción
[La introducción de la Visión debería proveer un resumen de todo el documento. Debería incluir el
propósito, alcance, definiciones, acrónimos, abreviaciones, referencias y el resumen de esta Visión.]
1.2 Alcance
[Una breve descripción del alcance de esta Visión; lo que se encuentra asociado con el Proyecto, y lo que
sea afectado o influenciado por este documento]
1.4 Referencias
[Esta sección debería proveer una lista completa de todos los documentos referenciados en la Visión.
Cada documento debería ser identificado por título, número de reporte (si aplica), fecha, y publicador.
Especifica los fuentes desde los cuales las referencias pueden ser obtenidas. Esta información puede ser
provista por referencia a un apéndice o a otro documento.]
1.5 Resumen
[Esta sección debería describir lo que contiene el resto de la Visión y explicar cómo está organizado el
documento.]
[El informe de posicionamiento del producto comunica las intenciones de la aplicación y la importancia
del proyecto para todos los patrocinadores.]
patrocinador
p.e. Representado mediante
Patrocinador1
3.4 Ambiente del usuario Si se aplican las preguntas, se contestan y añado otras
[Detalla el ambiente de trabajo del usuario destino. Aquí hay algunas sugerencias:
Número de personas involucradas en la realización de la tarea. ¿Está cambiando?
¿Cuán largo es el ciclo de la tarea? ¿Cantidad de tiempo requerido en cada actividad? ¿Está
cambiando?
Cualquier restricción ambiental única: móvil, externa, etc.
¿Cuáles plataformas de sistemas se usan actualmente? ¿Plataformas futuras?
¿Qué otras aplicaciones están en uso?¿Su aplicación necesita integrarse con ellas?
Esto es un extracto del Modelo de Negocios el cual podría ser incluido para resaltar las tareas y los
usuarios involucrados, etc]
Tipo Calificar la experticia del usuario p.e. GURU, USUARIO CASUAL, etc.
p.e. Trasfondo técnico y grado de sofisticación.
Responsabilidades Lista de principales responsabilidades del usuario con respecto al sistema (p.e.
capturar detalles del cliente, reportes de producción, trabajo coordinado).
Criterios de Éxito ¿Cómo el usuario define el éxito? ¿Cuán satisfecho está el usuario?
Involucrado en Cuán involucrado está el usuario con el proyecto – relacione donde sea posible con
los patrocinadores RUP (p.e. Verificador de Requerimientos etc.)
Entregables Entregables que el usuario produce, y para quienes...
Comentarios/ Problemas que interfieren con el éxito y cualquier otra información relevante.
Tópicos Tendencia que hace el trabajo del usuario más fácil o difícil.
Es importante entender la importancia relativa que el patrocinador pone en solucionar en cada problema.
Clasifique y acumule las técnicas votadas que indican problemas que deben ser resueltos versus los
puntos que ellos querían resolver.
Llene la siguiente tabla – si se están usando RequisitePro para capturar las Necesidades éstas podrían ser
un extracto/reporte de la herramienta.
3.8.1 <UnCompetidor>
3.8.2 <OtroCompetidor>
5.1 <UnaCaracterística>
6. Restricciones
[Anote cualquier restricción de diseño, restricción externa u otras dependencias.]
7. Rangos de calidad
[Define los rangos de calidad para desempeño, robustez, tolerancia a fallos, usabilidad y características
similares que no son capturadas en el Conjunto de Características.]
8. Precedencia y prioridad
[Define la prioridad de las diferentes características del sistema.]
detalle, índices, glosario de términos, tutoriales versus la estrategia del manual de referencia, etc. Las
restricciones de formato e impresión deben ser también identificadas.]
11.1 Estado
[Se establece después de negociación y revisión por el equipo de administración del proyecto. Da
seguimiento al progreso durante la definición de la línea base del proyecto.]
Propuesto Usado para describir características que están bajo discusión pero
todavía no han sido revisadas y aceptadas por el ‘canal oficial’, tales
como un grupo de trabajo consistente de representantes del equipo
de trabajo, la administración del producto y la comunidad de clientes
y usuarios.
Aprobado Capacidades que son útiles y factibles y han sido aprobadas para
implementarlas por el canal oficial.
11.2 Beneficio
[Se deben establecer por medio del administrador del producto o el analista del negocio. Los
requerimientos no son definidos de la misma manera. Se debe priorizar los requerimientos de acuerdo a su
Confidencial ¡Error!Nombre desconocido de 8
propiedad de documento., 2000
<Nombre del Proyecto> Versión: <1.0>
Visión Fecha: <dd/mmm/yy>
<identificador del documento> ***FISC VISION # GRUPO
beneficio relativo hacia el cliente final, de manera que exista un dialogo entre clientes, analistas y
miembros del grupo de desarrollo. La definición de beneficios se utiliza para manejar el alcance y
determinar las prioridades de desarrollo.]
11.3 Esfuerzo
[Establecer el equipo de desarrollo. Debido a que algunas características requieren más tiempo y recursos
que otras, se debe estimar el número de personas o semanas por persona, líneas de código requeridas por
funcionamiento, por ejemplo, la mejor manera de calibrarla complejidad y las expectativas de lo que se
puede o no se puede hacer dado por un periodo de tiempo. Se utiliza para administrar el alcance y
determinar las prioridades de desarrollo.]
11.4 Riesgo
[El equipo del desarrollo se basó en la probabilidad de que el proyecto experimentará eventos no
deseados, tales como el costo sobreestimado, los retardos del horario o aún la cancelación. La mayoría
de los administradores de proyectos encuentran categorías de riesgos tales como suficiente alto, medio y
bajo, aunque gradaciones más finas son posibles. El riesgo puede ser evaluado a menudo indirectamente
midiendo la incertidumbre (el rango) de la estimación del horario de los equipos de proyectos.]
11.5 Estabilidad
[El conjunto del analista y del equipo del desarrollo se basó en la probabilidad de que la característica
cambiará o la comprensión del equipo de la característica cambiará. Ayudaban a establecer prioridades
del desarrollo y a determinar esos ítemes para los cuales la respuesta adicional es la siguiente acción
apropiada.]
implementada. Cuando se maneja el alcance, la liberación puede ser mejorada y su mejora de be ser
incluida en el documento de Visión dentro de un cronograma para su posterior liberación.]
11.7 Asignación a
[In muchos proyectos, las características pueden ser asignadas por equipos responsables de levantar los
requerimientos de software y su implementación. Esta ayudará a cada uno en el equipo de proyecto a
entender mejor las responsabilidades.
11.8 Razón
[Esta sección es utilizada para seguir la fuente de las características requeridas. Los requerimientos
existen por diversas razones. En esta sección se establece una explicación o una referencia a una
explicación. Por ejemplo, las referencias podrían ser a una página o línea de especificaciones de
productos o a entrevistas con los usuarios.]