<HalleyGod.

com>
Visión
Versión <1>

[Nota: Esta Plantilla tiene por finalidad servir de Base para la confección del
documento Visión. El texto entre paréntesis cuadrados y desplegado en azul
itálico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado
antes de la publicación del documento. El estilo Body Text se activa
automáticamente cuando se ingresan párrafos de texto definitivo.]
 Historia de Revisiones
Fecha Versión Descripción Autor

<2019-10-08> <1> Documento Inicial <Nombre>

Índice
1. Introducción 161
1.1. Propósito 161
1.2. Ámbito 161
1.3. Definiciones, Siglas, y Abreviaciones 161
1.4. Referencias 161
1.5. Resumen Ejecutivo 161
2. Posicionamiento 162
2.1. Declaración del Problema (OBLIGATORIO) 162
2.2. Declaración de Posicionamiento del Producto 162
3. Descripción de Clientes, Stakeholders y Usuarios 162
3.1. Demografía del Mercado 163
3.2. Resumen de Stakeholders (OBLIGATORIO) 163
3.3. Resumen de usuarios (OBLIGATORIO) 163
3.4. Alternativas y Competencia 163
4. Descripción Global de la Solución 163
4.1. Modelo de Negocios 164
4.2. Perspectiva del Producto de software 164
4.3. Resumen de capacidades 164
4.4. Supuestos y Dependencias 164
5. Características del Producto 164
5.1. <Característica> 165
5.2. <Siguiente Característica> 165
6. Restricciones 165
7. Rangos de Calidad 165
8. Precedencia y prioridad 165
9. Otros Requerimientos del producto 165
9.1. Estándares Aplicables 165
9.2. Requerimientos de sistema 165
9.3. Requerimientos de Performance 165
9.4. Requerimientos de Entorno 165
10. Requerimientos de Documentación 166
10.1. Manual de Usuario 166
10.2. Guía de Instalación, Configuración, y archivo “Read Me” 166
 Visión
1. Introducción
[El propósito de este documento es recolectar, analizar y definir una vista global
de las necesidades de los usuarios y características del producto. Entendemos
por producto al conjunto de la solución, incluyendo los procesos administrativos
como el sistema. Este es el documento inicial del proyecto, y resume la visión
macro de todas las áreas afectadas: 1) el área que da origen al proyecto,
responsable de la definición del producto (usualmente el área comercial); 2) el
área responsable de la solución global para satisfacer la definición del producto
(usualmente Ingeniería de Procesos); 3) el área responsable del desarrollo o
modificación del (los) sistema(s) computacional(es) requeridos.
Enfóquese en determinar las capacidades necesitadas por los stakeholders y
por qué existen estas necesidades y como el producto va a solucionarlas. Los
detalles de cómo la serán resueltas estas necesidades 1) por los procesos
administrativos estarán en los respectivos Diagramas de Actividad; 2) por el
sistema computacional se describen en las especificaciones de los casos de
uso.]
1.1.Propósito
[Especifique el propósito de este documento de Visión.]

1.2.Ámbito
[Breve descripción sobre el ámbito del documento de Visión, que áreas
organizacionales y sistemas computacionales (nuevos o a modificar) están
asociados y qué o quienes estarán afectados o influenciados por este proyecto]

1.3. Definiciones, Siglas, y Abreviaciones

[Definición de todos los términos, siglas y abreviaciones requeridas para
interpretar el documento de Visión. Esta información debe irse incorporando al
Glosario del proyecto. Por ejemplo:

Stakeholder: Ejecutivos de la empresa que se ven principalmente afectados

por el proyecto. Un resultado exitoso del mismo redundará positivamente en su
gestión. Pueden o no ser participantes del proceso o usuarios del sistema
computación.

Participantes del proceso: Personas o dispositivos que forman parte de los

procesos administrativos involucrados en la solución. Pueden o no ser usuarios
del sistema computacional.

Usuarios: Personas que interactúan directamente con el sistema computacional.]

1.4. Referencias
[Este punto deberá:
 Proveer una completa lista de todos los documentos referenciados en cualquier
lugar del documento de Visión.
 Identificar cada documento por un título, número de reporte (si aplica), fecha
y organización que la pública.
 Especificar las fuentes desde las cuales las referencias pueden ser obtenidas.
Esta información puede estar referida a un apéndice u otro documento.]

1.5. Resumen Ejecutivo

[Breve resumen del contenido del resto del documento de Visión, y como este está
organizado].
2. Posicionamiento
2.1. Declaración del Problema (OBLIGATORIO)
[Obtener una declaración del o los problemas que será resuelto por el proyecto.
Se debe usar el siguiente formato:

El problema de [describa el problema]

Afecta a [principales involucrados por el problema]

El impacto del cual es [cual es el impacto del problema]

Una solución exitosa sería [describa algunos beneficios claves que debe
contener una solución para ser calificada de
exitosa]

2.2. Declaración de Posicionamiento del Producto

[Esta sección aplica en proyectos que implican el desarrollo de un nuevo
producto o servicio, que se intentará posicionar en el mercado. Si el origen del
proyecto es un requerimiento interno, o uno específico de un cliente que no
será comercializado a otros clientes, esta sección no aplica.

El objetivo es proveer una declaración a alto nivel, dando la posición que intenta
el producto tomar en el mercado. Normalmente se obtendrá de definiciones
generadas por la Gerencia Comercial. Se sugiere el siguiente formato:

Para [cliente objetivo]

Quién [declaración de la necesidad u

oportunidad]

El (nombre del producto) es un [categoría del producto]

Que [declaración del beneficio clave,

esto es razón de conveniencia de la
compra)

A diferencia de [primera alternativa de

competencia]

Nuestro producto [declaración de la diferencia

esencial]

3. Descripción de Clientes, Stakeholders y Usuarios

[Para obtener productos y servicios que satisfagan las verdaderas necesidades
de los clientes, stakeholders y usuarios, es necesario identificar e involucrar a
todos aquellos que se vean afectados por el proyecto (stakeholders) en el
proceso de Modelamiento del Negocios. Es importante identificar también a
todos los usuarios del (los) sistemas computacionales, y asegurarse que estén
adecuadamente representados por algún Stakeholder. Esta sección debe
establecer un perfil de los stakeholders y usuarios de la aplicación y los
problemas claves que ellos perciben que deben ser resueltos por la solución
propuesta. El objetivo es proveer el background y la justificación de por qué los
requerimientos son necesarios.]
3.1. Demografía del Mercado
[Esta sección aplica en proyectos que implican el desarrollo de un nuevo
producto o servicio, que se intentará posicionar en el mercado. Si el origen del
proyecto es un requerimiento interno, o uno específico de un cliente que no
será comercializado a otros clientes, esta sección no aplica.

[Esta sección resume la demografía del mercado que motiva la decisión de

existencia del producto. Describe y posiciona los segmentos del mercado
objetivo. Estima el tamaño y crecimiento del mercado según el número de
potenciales usuarios, o la cantidad de dinero que sus clientes están dispuestos
a pagar tratando de encontrar las necesidades que su producto podrá satisfacer.
Analice las principales tendencias y tecnología de la industria. Responda estas
preguntas estratégicas: ¿Cuál es la reputación de la organización en ese
mercado? ¿Cómo quisieran Uds. que fuesen? ¿Cómo este producto o servicio
apoya sus objetivos?

3.2. Resumen de Stakeholders (OBLIGATORIO)

[Detalle a todos los stakeholders identificados.]

Nombre Representa Rol Criterios

de éxito
[Nombre del [Describa [Describa [Describa
tipo de brevemente que brevemente el rol brevemente
Stakeholder.] representa para el que jugará en el cuales son
proyecto] desarrollo del los criterios
proyecto, cuál será bajo los
su nivel de cuales el
involucramiento] Stakeholder
considerará
que el
proyecto es
exitoso].

3.3. Resumen de usuarios (OBLIGATORIO)

[Detalle a todos los usuarios identificados.]

Nombre Descripción Stakeholder

[Nombre del perfil de [Describa brevemente que [Indique
usuario, esto es representan para el sistema, que
conjunto de personas cuantas personas hacen esa Stakeholder
que cumplen el mismo tarea, cantidad de representa
rol para el sistema] operaciones, si es una tarea a este perfil
nueva, si no lo es como la de
ejecutan actualmente.] usuarios].

3.4. Alternativas y Competencia

[Identifique alternativas que sean percibidas como disponibles. Ello puede
considerar comprar un producto de la competencia, construir una nueva
solución, hacer mejoras a una solución existente o no hacer nada. Indique las
principales fortalezas y debilidades de cada opción, y porque fueron
desechadas.]

4. Descripción Global de la Solución

[Esta sección contiene una visión de alto nivel sobre la solución, sus capacidades,
interfaces a otras aplicaciones y configuraciones de sistemas]

4.1. Modelo de Negocios

[El Objetivo de esta subsección es dar un entendimiento del modelo de negocios
al que la solución a construir responde. Para ello se recomienda incluir un
Diagrama de Casos de Uso de Negocio, y para cada caso de uso un Diagrama
de Actividad Global, identificando cuales funciones serán ejecutadas
manualmente, cuales usando sistemas computacionales existentes y cuales
usando sistemas computacionales a construir o modificar.

Esta subsección no es aplicable si la totalidad de la solución es un sistema

computacional, por ejemplo, un sistema de consulta de clientes por la WEB].

Ilustración 1. Diagrama de Caso de Uso del Negocio (Realizar Venta).

 Ilustración 2. Diagrama de Actividades del Caso de Uso "Realizar Venta".

Funciones Ejecutadas Manualmente:

 Mostrar productos.
 Despachar Productos.

4.2. Perspectiva del Producto de software

[Esta subsección pone el producto de software a construir o modificar en
perspectiva de otros productos relacionados y del ambiente de los usuarios. Si
el producto es independiente y totalmente autocontenido, indíquelo aquí. Si es
una parte de un sistema mayor, debe identificar las interfaces entre los
sistemas, Se recomienda incluir un Diagrama de Casos de Uso de Software,
distinguiendo que Casos de Uso son nuevos y cuales son adecuaciones a Casos
de Uso ya existentes. Se debe incluir una breve descripción de cada Caso de
Uso, hasta el nivel que sea necesario para poder dimensionar el esfuerzo de su
construcción].

4.3. Resumen de capacidades

[Resuma los principales beneficios y características que la solución cumplirá.
Organice las funciones de manera fácil de entender, por ejemplo, en una tabla
como la siguiente:

Beneficios Características que lo permiten

[corresponden a los ítems [A través de que características de
identificados en la que procedimientos y casos de uso
Formulación del problema se obtendrá el beneficio
como “una solución exitosa respectivo]
sería”]

4.4. Supuestos y Dependencias

[Identifique los factores que afectan las características establecidas en el
documento de Visión, especialmente aquellas que si cambian provocarían un
cambio en este documento. Por ejemplo, un supuesto podría establecer que un
sistema operativo específico estará disponible para un Hardware específico.
Separe los supuestos técnicos de los no técnicos.]

5. Características del Producto

[Liste y describa las características de los productos, Las características son
las capacidades de alto nivel del sistema, son los que entregan beneficios
a los usuarios. Cada característica es un servicio esperado externamente
que requiera típicamente una serie de entradas para alcanzar el resultado
deseado. Por ejemplo, una característica de un problema de ajuste de
sistema puede ser la habilidad de entregar reportes de tendencias. Como
el modelo de casos de uso toma una forma, actualice esta descripción para
referirse a los casos de uso.

Debido a que el documento Visión es revisado por un gran número de

personal, el nivel de detalle necesita ser lo suficientemente general como
para ser entendido por cualquier persona. De todas formas, debe tener el
suficiente detalle para entregar al equipo la información suficiente para
crear los casos de uso.
Para manejar la complejidad de la aplicación efectivamente, se recomienda
para cualquier sistema Nuevo, o incremento de un sistema ya existente,
que la capacidad sea abstraída a un alto nivel de características, un buen
número de características son entre 25-99. Estas características proveen la
base fundamental para la definición del producto, manejo del ámbito y del
proyecto. Cada característica debe explicarse con gran detalle en el modelo
de casos de uso.

A través de esta sección, cada característica debe ser externamente

percibida por los usuarios, operadores u otros sistemas externos. Estas
características deben incluir una descripción de su funcionalidad y
cualquier uso relevante. Se pueden aplicar los siguientes principios:

Abstenerse de diseñar. Mantener la descripción de las características

en un nivel general. Enfocarse en las capacidades necesarias y porque
(no como) deben ser implementadas
5.1. 5.1 <Característica>

5.2. 5.2 <Siguiente Característica>

6. Restricciones
[Indique cualquier restricción externa al proyecto, por ejemplo, fecha de término,
máxima, presupuesto máximo, plataformas de Hardware y Software Básico,]

7. Rangos de Calidad
[Defina los rangos de calidad exigidos para performance, robustez, tolerancia a
fallas, usabilidad y otros atributos no funcionales.]

8. Precedencia y prioridad
[Defina la prioridad de las diferentes características del sistema.]

9. Otros Requerimientos del producto

 [A un alto nivel, listar los estándares aplicables, los requerimientos de
hardware o de plataforma, requerimientos de performance, y los
requerimientos de entorno]

9.1. Estándares Aplicables

[Listar todos los estándares con los cuales debe cumplir el producto. Estos
pueden incluir estándares legales y reguladores (FDA, UCC), de comunicación
(TCP/IP, ISDN), estándar de la plataforma (Windows, UNIX, etc.), y estándares
de calidad y seguridad (UL, ISO, CMM).]

9.2. Requerimientos de sistema

[Defina cualquier requerimiento de sistema que sea necesario para soportar la
aplicación. Este puede incluir soporte de operador de host y plataformas de
network, configuraciones, memoria, periféricos, y software]

9.3. Requerimientos de Performance

[Use esta sección para detallar los requerimientos de performance. Incluya
estos ítems como factores de carga de usuario, ancho de banda o capacidad de
la comunicación, rendimiento, exactitud, y confiabilidad o tiempo de respuesta
bajo variadas condiciones de carga.]

9.4. Requerimientos de Entorno

[Detalle los requerimientos de entorno necesarios. Para sistemas basados en
hardware, los requerimientos de entorno pueden incluir temperatura, golpes
eléctricos, humedad, radiación, etc. Para aplicaciones software pueden incluir las
condiciones de uso, entorno de usuario, disponibilidad de recursos,
mantenimiento, y manejo y recuperación de errores.]

10. Requerimientos de Documentación

[Esta sección describe la documentación que debe ser desarrollada para dar
soporte al despliegue exitoso de la aplicación.]

10.1. Manual de Usuario

[Describa el propósito y contenido del Manual de Usuario. Discuta sobre el
tamaño deseado, nivel de detalle, necesidad de índice, glosario, tutorial
versus la estrategia del manual de referencia, etc. Dando formato e
imprimiendo las constantes que también deben ser identificadas.]

10.2. Guía de Instalación, Configuración, y archivo “Read Me”

[Consiste en un documento que incluye las pautas de instrucciones de
instalación y configuración, es importante que entregue una solución
completa. También se incluye típicamente como un componente estándar

El archivo “Read Me” puede incluir una sección de “Lo Nuevo de esa
versión”, y un capítulo de “compatibilidad con versiones antiguas”. La
mayoría de los usuarios también aprecian la documentación de “bugs”
conocidos y sus soluciones.]