Planillas de RUP (Español)

1
8.4.1 Plantilla Modelo de Casos de Uso del Negocio
[Nombre del proyecto] Modelo de

Casos de Uso del Negocio
Versin [1.0]
[Este documento es la plantilla base para elaborar el documento Modelo de Casos de
Uso. Los textos que aparecen entre parntesis rectos son explicaciones de que debe
contener cada seccin. Dichos textos se deben seleccionar y sustituir por el contenido
que corresponda. Para actualizar la tabla de Contenido, haga clic con el botn derecho
del ratn sobre cualquier lnea del contenido de la misma y seleccione Actualizar
campos, en el cuadro que aparece seleccione Actualizar toda la tabla y haga clic en el
botn Aceptar.]
[Este documento se realiza en forma previa al Modelo de Casos de Uso del Sistema y
constituye una entrada fundamental para realizar el mismo. El propsito principal de
modelar actores y CU del Negocio es describir como se utiliza el negocio por parte de
sus clientes y socios. Estos Casos de Uso del Negocio constituyen los procesos del
Negocio que dan valor a los actores involucrados. Estos procesos son el vehculo con el
que el Negocio hace cosas. Las estrategias del Negocio se traducen en Objetivos del
Negocio que guan las actividades realizadas en los procesos del Negocio, por lo que
cada CU del Negocio debe soportar por lo menos un objetivo del Negocio, y esta es una
gua para identificar la granularidad correcta para la definicin de los CU del Negocio.
Cuando se est realizando el modelado del Negocio solo para tener una visin primaria
para un proyecto de Ingeniera de Software, se debe delimitar con cuidado el esfuerzo
de modelado del Negocio. En este caso en general no vale la pena hacer el modelado
del Negocio entero, y es conveniente considerar la parte del Negocio con la que se est
tratando, como si fuera el Negocio entero, la parte considerada ser la que utilice
directamente el sistema en desarrollo. Las partes de la Organizacin que se dejen fuera
de los lmites del Negocio tomado en cuenta, pueden ser modeladas como actores del
Negocio.]
Historia de revisiones
Fecha
Versin
Descripcin
Autor
[dd/mm/aaaa]
[x.x]
[detalles]
[nombre]
Contenido
2
1. Actores ............................................................................................................... 150
1.1. [Actor 1] ...................................................................................................... 150
1.2. [Actor 2] ...................................................................................................... 150
2. Casos de Uso ...................................................................................................... 150
2.1. Diagramas de Casos De Uso ........................................................................ 150
2.2. [Caso de Uso 1]............................................................................................ 150
2.2.1. Descripcin ........................................................................................... 150
2.2.2. Pre-condiciones ................................... Error! Marcador no definido.148
2.2.3. Flujo de eventos principal ...................................................................... 150
2.2.4. Flujos de eventos alternativos ................................................................ 150
2.2.5. Post-condiciones .................................................................................... 148
2.2.6. Requerimientos especiales ..................................................................... 151
2.3. [Caso de Uso 2]............................................................................................ 151
3
1. Actores del Negocio
[En esta seccin se debe describir a cada uno de los actores del Negocio que
participan en los Casos de Uso del Negocio, un actor del Negocio es un usuario del
Negocio o cualquier entidad que interacta con el Negocio.]
1.1.
[Actor del Negocio 1]
[Descripcin del Actor 1 del Negocio]

1.2.
[Actor del Negocio 2]
[Descripcin del Actor 2 del Negocio]
2. Casos de Uso del Negocio

2.1.
Diagramas de Casos De Uso
[Aqu se presentan los Diagramas de Casos de Uso del Negocio, para mostrar la
interaccin entre los Actores y los Casos de Uso del Negocio.]
2.2.
[Caso de Uso del Negocio 1]
2.2.1.
Descripcin
[Explicar brevemente el propsito del caso de uso del Negocio]

2.2.2.
Flujo de eventos principal
[En esta seccin se realiza una descripcin textual del flujo del Negocio que
representa el Caso de Uso. El flujo debe describir que hace el Negocio para
proveer de valor a un actor del Negocio, pero no como hace el Negocio para
resolver sus problemas. Las alternativas simples se pueden presentar dentro del
texto del Caso de Uso. Si el flujo alternativo es ms complejo, use una seccin
separada para describirlo.]
2.2.3.
1.1.1.1.
Flujos de eventos alternativos

[Flujo alternativo 1]
[En esta seccin se describen las alternativas ms complejas a las cuales se haca
referencia en el Flujo de eventos principal. Estos flujos alternativos representan la
conducta alternativa normalmente debida a excepciones que ocurren en el flujo
principal. Ellos pueden ser necesarios para describir los eventos asociados con la
conducta alternativa. Cuando finaliza el flujo alternativo, se retoman los eventos
del flujo de eventos principal a menos que se establezca otra cosa.]
[Sub-flujo alternativo 1]
[Los flujos alternativos pueden dividirse en subsecciones si esto aporta claridad]
[Sub-flujo alternativo 2]
...
1.1.1.2.
[Flujo alternativo 2]
...
2.2.4.
Diagrama de Actividad
[En esta seccin incluye un Diagrama de Actividad que modele en forma grfica
los flujos del Caso de Uso del Negocio descritos previamente. Es importante que
se muestren los distintos condicionales que existen en el proceso que determinan
4
que se siga un camino u otro en la ejecucin del proceso, y cuales son todas las
opciones vde terminacin para los flujos modelados.]
2.2.5.
Requerimientos especiales
[En esta seccin se especifican los requerimientos especiales que son especficos a
un caso de uso del Negocio, que son las caractersticas del caso de uso del
Negocio no cubiertas por los flujos descritos.]
[Requerimiento
especial 1]
2.3.
...
[Caso de Uso del Negocio 2]
...
3. Reglas del Negocio

[En esta seccin se especifican las Reglas del Negocio que se deben tener en
cuenta en la ejecucin de los distintos procesos definidos. Las Reglas del Negocio
son tipos de requerimientos sobre como el Negocio, incluyendo sus herramientas,
debe funcionar.
Pueden ser leyes y regulaciones impuestas al Negocio entre otras, y pueden ser
clasificadas de distinta forma segn el Negocio, por ejemplo pueden estar
agrupadas por dominio, usuario o grupo de productos, aunque una clasificacin
ms formal las define como Restricciones y Derivaciones.
Las Reglas del Negocio deben ser expresadas con un nivel de formalismo que
permita su automatizacin, una forma puede ser utilizando el Object Constraint
Language (OCL) especificado en UML. De todas formas es til mostrar las Reglas
de Negocio como notas de texto en los elementos de los distintos diagramas y
modelos, por ejemplo en los Diagramas de Actividad.]
3.1.
...
[Regla del Negocio 1]
5
8.4.2 Plantilla Glosario
<Nombre del Proyecto>

Glosario
Versin <1.1.0>
[Nota: Este Plantilla tiene por finalidad servir
documento Glosario. El texto entre parntesis
itlico (estilo = InfoBlue) tiene por finalidad guiar
de la publicacin del documento. El estilo Body
cuando se ingresan prrafos de texto definitivo.]
de base para la confeccin del

cuadrados y desplegado en azul
al autor y debe ser borrado antes
Text se activa automticamente
Historia de Revisiones
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
ndice
1
Introduccin
1.1
1.2
1.3
1.4
Definiciones
2.1
2.2
2.3
155
Propsito
mbito
Referencias
Resumen Ejecutivo
155
Trminos
<Grupo de Trminos>
<Un segundo Grupo de Trminos>
155
155
155
155
155
156
157
Glosario
Introduccin
[La introduccin del Glosario provee un resumen del documento completo.
Presente cualquier informacin que el lector pueda necesitar para entender el
documento en esta seccin. El documento Glosario es usado para definir la
terminologa especfica para el dominio del problema, explicando los trminos que
puedan no ser familiares al lector acerca de la descripcin de los casos de uso o de
otros documentos del proyecto. Este documento puede ser un diccionario informal,
capturando la definicin de los datos en los que se pueda enfocar los casos de uso
u otros documentos del proyecto que necesiten hacer algo con esta informacin.
Este documento debe ser guardado con el nombre de Glosario..]
Propsito
[Especifique el propsito del Glosario.]
mbito
[Una breve descripcin del mbito de este Glosario; que proyecto(s) estn asociados
a l, o cualquier cosa que pueda versen afectada o influenciada por este documento.]
Referencias
[Esta subseccin provee una lista completa de todos los documentos referenciados
en cualquier parte de este Glosario. Identifique cada documento por ttulo,
nmero de edicin (si es aplicable), y editorial. Especifique las fuentes de donde
pueden obtenerse estas referencias. Esta informacin puede ser entregada a modo
de referencia a un apndice o a otro documento.]
Resumen Ejecutivo
[Esta subseccin describe el contenido del resto del Glosario, y explica cmo est
organizado el documento.]
Definiciones
[Los trminos definidos en este punto forman la esencia del documento. Estos
pueden ser definidos en el orden deseado, pero generalmente se usa el orden
alfabtico para proveer mayor accesibilidad.]
Trminos
Termino
Descripcin
Estereotipos de UML
9
[La definicin para <Un trmino> se
realiza aqu. Se debe presentar
cuanta informacin sea necesaria
para que el lector comprenda los
conceptos.]
[Esta seccin contiene o

referencia
las
especificaciones del
Unified
Modeling
Language(UML)
estereotipos
y
sus
implicaciones semnticasuna descripcin textual del
significado
y
uso
del
estereotipo,
adems
describe
cualquier
limitacin en su usopara
estereotipos ya conocidos
o desarrollados (y que son
importantes
para
el
sistema), El uso de estos
estereotipos puede ser
recomendado o
imprescindible; Por
ejemplo, cuando su uso es
requerido por un estndar
impuesto o cuando su uso
hace a los modelos
significativamente ms
fciles de entender. Esta
seccin puede estar vaca
si no existen estereotipos
adicionales, o si se usan
los predefinidos por UML.]
<Grupo de Trminos>
[A veces es til organizar los trminos por grupos para facilitar la lectura. Por
ejemplo si el dominio del problema contiene trminos iguales relacionados con
cuentas y con crear una construccin (si este fuera el caso en el que estamos
desarrollando un sistema que maneje los proyectos de construccin), presentar los
trminos de los dos subdominios diferentes puede confundir al lector. La solucin a
este problema es agrupar los trminos. En la presentacin de grupos de trminos,
proporcione una descripcin corta que ayude al lector a entender qu representa
<un grupo de trminos>. Los trminos presentados con el grupo deben estar
organizados alfabticamente para facilitar el acceso.]
10
Grupo de
trminos
Descripcin
Estereotipos de UML
[La definicin para <un grupo de

trminos> se presenta aqu. Incluya
tanta
informacin
como
sea
necesaria para que el lector pueda
entender el concepto.]
[Esta seccin contiene o

referencia
las
especificaciones del
Unified
Modeling
Language(UML)
estereotipos
y
sus
implicaciones semnticasuna descripcin textual del
significado
y
uso
del
estereotipo,
adems
describe
cualquier
limitacin en su usopara
estereotipos ya conocidos
o desarrollados (y que son
importantes
para
el
sistema), El uso de estos
estereotipos
puede
ser
recomendado
o
imprescindible;
Por
ejemplo, cuando su uso es
requerido por un estndar
impuesto o cuando su uso
hace a los modelos
significativamente ms
fciles de entender. Esta
seccin puede estar vaca
si no existen estereotipos
adicionales, o si se usan
los predefinidos por UML.]
<Un segundo Grupo de Trminos>
Grupo de
trminos
Descripcin
Estereotipos de UML
11
[La definicin para <un grupo
de trminos> se presenta
aqu. Incluya tanta informacin
como sea necesaria para que
el lector pueda entender el
concepto.]
[Esta seccin contiene o referencia

las especificaciones del Unified
Modeling
Language(UML)
estereotipos y sus implicaciones
semnticasuna descripcin
textual del significado y uso del
estereotipo,
adems
describe
cualquier limitacin en su usopara estereotipos ya conocidos o
desarrollados
(y
que
son
importantes para el sistema), El
uso de estos estereotipos puede
ser recomendado o imprescindible;
Por ejemplo, cuando su uso es
requerido
por
un
estndar
impuesto o cuando su uso hace a
los
modelos
significativamente
ms fciles de entender. Esta
seccin puede estar vaca si no
existen estereotipos adicionales, o
si se usan los predefinidos por
UML.]
12
8.4.3 Plantilla Visin

Visin
Versin <1.1.0>
[Nota: Esta Plantilla tiene por finalidad servir de Base para la confeccin del
documento Visin. El texto entre parntesis cuadrados y desplegado en azul itlico
(estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la
publicacin del documento. El estilo Body Text se activa automticamente cuando se
ingresan prrafos de texto definitivo.]
13
Fecha
<aaaa-mm-dd>
Versin
<1.1.0>
Descripcin
Documento Inicial
Autor
<Nombre>
14
ndice
1. Introduccin
161
1.1.
Propsito
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.
Declaracin del Problema (OBLIGATORIO)
162
2.2.
Declaracin de Posicionamiento del Producto
162
3. Descripcin de Clientes, Stakeholders y Usuarios 162
3.1.
Demografa del Mercado
163
3.2.
Resumen de Stakeholders (OBLIGATORIO)
163
3.3.
Resumen de usuarios (OBLIGATORIO)
163
3.4.
Alternativas y Competencia
163
4. Descripcin Global de la Solucin
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. Caractersticas del Producto
164
5.1.
<Caracterstica>
165
5.2.
<Siguiente Caracterstica>
165
6. Restricciones
165
7. Rangos de Calidad
165
8. Precedencia y prioridad
165
9. Otros Requerimientos del producto
165
9.1.
Estndares Aplicables
165
9.2.
Requerimientos de sistema
165
9.3.
Requerimientos de Performance
165
9.4.
Requerimientos de Entorno
165
10. Requerimientos de Documentacin 166 10.1. Manual de Usuario
166
10.2.
Gua de Instalacin, Configuracin, y archivo Read Me
166
15
Visin
1. Introduccin
[El propsito de este documento es recolectar, analizar y definir una vista global de las
necesidades de los usuarios y caractersticas del producto. Entendemos por producto al
conjunto de la solucin, incluyendo los procesos administrativos como el sistema. Este
es el documento inicial del proyecto, y resume la visin macro de todas las reas
afectadas: 1) el rea que da origen al proyecto, responsable de la definicin del
producto (usualmente el rea comercial); 2) el rea responsable de la solucin global
para satisfacer la definicin del producto (usualmente Ingeniera de Procesos); 3) el
rea responsable del desarrollo o modificacin del (los) sistema(s) computacional(es)
requeridos.
Enfquese en determinar las capacidades necesitadas por los stakeholders y por qu
existen estas necesidades y como el producto va a solucionarlas. Los detalles de cmo
la sern resueltas estas necesidades 1) por los procesos administrativos estarn en los
respectivos Diagramas de Actividad; 2) por el sistema computacional se describen en
las especificaciones de los casos de uso. ]
1.1.
Propsito
[Especifique el propsito de este documento de Visin.]

1.2.
mbito
[Breve descripcin sobre el mbito del documento de Visin, que reas

organizacionales y sistemas computacionales (nuevos o a modificar) estn asociados y
qu o quienes estarn afectados o influenciados por este proyecto]
1.3. Definiciones, Siglas, y Abreviaciones
[Definicin de todos los trminos, siglas y abreviaciones requeridas para interpretar el
documento de Visin. Esta informacin 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 gestin.
Pueden o no ser participantes del proceso o usuarios del sistema computacin.
Participantes del proceso: Personas o dispositivos que forman parte de los procesos
administrativos involucrados en la solucin. Pueden o no ser usuarios del sistema
computacional.
Usuarios: Personas que interactan 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 Visin.
Identificar cada documento por un ttulo, nmero de reporte (si aplica), fecha y
organizacin que la pblica.
Especificar las fuentes desde las cuales las referencias pueden ser obtenidas. Esta
informacin puede estar referida a un apndice u otro documento.]
16
1.5. Resumen Ejecutivo
[Breve resumen del contenido del resto del documento de Visin, y como este est
organizado].
2. Posicionamiento
2.1.
Declaracin del Problema (OBLIGATORIO)
[Obtener una declaracin 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]
[describa algunos beneficios claves que debe

contener una solucin para ser calificada de
exitosa]
Declaracin de Posicionamiento del Producto
Una solucin exitosa sera

2.2.
[Esta seccin 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 especfico de un cliente que no ser comercializado a
otros clientes, esta seccin no aplica.
El objetivo es proveer una declaracin a alto nivel, dando la posicin 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]
Quin
[declaracin de la necesidad u
oportunidad]
El (nombre del producto)
es un [categora del producto]
Que
[declaracin del beneficio clave,

esto es razn de conveniencia de la
compra)
A diferencia de
[primera alternativa de
competencia]
Nuestro producto
[declaracin de la diferencia
esencial]
3. Descripcin 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 tambin a todos los usuarios del (los) sistemas
17
computacionales, y asegurarse que estn adecuadamente representados por algn
Stakeholder. Esta seccin debe establecer un perfil de los stakeholders y usuarios de la
aplicacin y los problemas claves que ellos perciben que deben ser resueltos por la
solucin propuesta. El objetivo es proveer el background y la justificacin de por qu
los requerimientos son necesarios.]
3.1.
Demografa del Mercado
[Esta seccin 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 especfico de un cliente que no ser comercializado a
otros clientes, esta seccin no aplica.
[Esta seccin resume la demografa del mercado que motiva la decisin de existencia
del producto. Describe y posiciona los segmentos del mercado objetivo. Estima el
tamao y crecimiento del mercado segn el nmero de potenciales usuarios, o la
cantidad de dinero que sus clientes estn dispuestos a pagar tratando de encontrar las
necesidades que su producto podr satisfacer. Analice las principales tendencias y
tecnologa de la industria. Responda estas preguntas estratgicas: Cual es la
reputacin de la organizacin en ese mercado? Cmo quisieran Uds. que fuesen?
Cmo este producto o servicio apoya sus objetivos?
3.2.
Resumen de Stakeholders (OBLIGATORIO)
[Detalle a todos los stakeholders identificados.]
Nombre
Representa
[Nombre del tipo

de Stakeholder.]
[Describa brevemente
que representa para
el proyecto]
3.3.
Rol
[Describa
brevemente el rol
que jugar en el
desarrollo del
proyecto, cual ser
su nivel de
involucramiento]
Resumen de usuarios (OBLIGATORIO)
Criterios de xito
[Describa brevemente
cuales son los criterios
bajo los cuales el
Stakeholder considerar
que el proyecto es
exitoso].
[Detalle a todos los usuarios identificados.]
Nombre
[Nombre del perfil de
usuario, esto es conjunto
de
personas
que
cumplen el mismo rol
para el sistema]
3.4.
Descripcin
[Describa brevemente que
representan para el sistema,
cuantas personas hacen esa
tarea, cantidad de
operaciones, si es una tarea
nueva, si no lo es como la
ejecutan actualmente.]
Stakeholder
[Indique que
Stakeholder
representa a este
perfil de usuarios].
Alternativas y Competencia
[Identifique alternativas que sean percibidas como disponibles. Ello puede considerar
comprar un producto de la competencia, construir una nueva solucin, hacer mejoras a
18
una solucin existente o no hacer nada. Indique las principales fortalezas y debilidades
de cada opcin, y porque fueron desechadas.]
4. Descripcin Global de la Solucin

[Esta seccin contiene una visin de alto nivel sobre la solucin, sus capacidades,
interfaces a otras aplicaciones y configuraciones de sistemas]
4.1.
Modelo de Negocios
[El Objetivo de esta subseccin es dar un entendimiento del modelo de negocios al que
la solucin 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 sern ejecutadas manualmente, cuales usando sistemas
computacionales existentes y cuales usando sistemas computacionales a construir o
modificar.
Esta subseccin no es aplicable si la totalidad de la solucin es un sistema computacional,
por ejemplo un sistema de consulta de clientes por la WEB].
4.2.
Perspectiva del Producto de software
[Esta subseccin 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, indquelo 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
descripcin de cada Caso de Uso, hasta el nivel que sea necesario para poder
dimensionar el esfuerzo de su construccin].
4.3.
Resumen de capacidades
[Resuma los principales beneficios y caractersticas que la solucin cumplir. Organice las
funciones de manera fcil de entender, por ejemplo en una tabla como la siguiente:
4.4.
Beneficios
Caractersticas que lo permiten
[corresponden a los tems

identificados en la
Formulacin del problema
como una solucin exitosa
sera]
[A travs de que caractersticas de

que procedimientos y casos de uso
se obtendr el beneficio
respectivo]
[Identifique los factores que afectan las caractersticas establecidas en el documento de

Visin, especialmente aquellas que si cambian provocaran un cambio en este
documento. Por ejemplo, un supuesto podra establecer que un sistema operativo
especfico estar disponible para un Hardware especfico. Separe los supuestos tcnicos
de los no tcnicos.]
5. Caractersticas del Producto
19
[Liste y describa las caractersticas de los productos, Las caractersticas son las
capacidades de alto nivel del sistema, son los que entregan beneficios a los
usuarios. Cada caracterstica es un servicio esperado externamente que requiera
tpicamente una serie de entradas para alcanzar el resultado deseado. Por ejemplo,
una caracterstica 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 descripcin para referirse a los casos de uso.
Debido a que el documento Visin es revisado por un gran nmero 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 informacin suficiente para crear los casos de uso.
Para manejar la complejidad de la aplicacin efectivamente, se recomienda para
cualquier sistema Nuevo, o incremento de un sistema ya existente, que la
capacidad sea abstrada a un alto nivel de caractersticas, un buen nmero de
caractersticas son entre 25-99. Estas caractersticas proveen la base fundamental
para la definicin del producto, manejo del mbito y del proyecto. Cada
caracterstica debe explicarse con gran detalle en el modelo de casos de uso.
A travs de esta seccin, cada caracterstica debe ser externamente percibida
por los usuarios, operadores u otros sistemas externos. Estas caractersticas
deben incluir una descripcin de su funcionalidad y cualquier uso relevante. Se
pueden aplicar los siguientes principios:
Abstenerse de disear. Mantener la descripcin de las caractersticas en un
nivel general. Enfocarse en las capacidades necesarias y porque (no como)
deben ser implementadas
5.1.
5.1
<Caracterstica>
5.2.
5.2
<Siguiente Caracterstica>
6. Restricciones
[Indique cualquier restriccin externa al proyecto, por ejemplo fecha de trmino,
mxima, presupuesto mximo, plataformas de Hardware y Software Bsico,]
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 caractersticas del sistema.]
9. Otros Requerimientos del producto

[A un alto nivel, listar los estndares aplicables, los requerimientos de hardware o de
plataforma, requerimientos de performance, y los requerimientos de entorno]
9.1.
Estndares Aplicables
[Listar todos los estndares con los cuales debe cumplir el producto. Estos pueden
incluir estndares legales y reguladores (FDA, UCC), de comunicacin (TCP/IP, ISDN),
20
estndar de la plataforma (Windows, UNIX, etc.), y estndares de calidad y seguridad
(UL, ISO, CMM).]
9.2.
Requerimientos de sistema
[Defina cualquier requerimiento de sistema que sea necesario para soportar la

aplicacin. Este puede incluir soporte de operador de host y plataformas de network,
configuraciones, memoria, perifricos, y software]
9.3.
Requerimientos de Performance
[Use esta seccin para detallar los requerimientos de performance. Incluya estos tems
como factores de carga de usuario, ancho de banda o capacidad de la comunicacin,
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 elctricos, humedad,
radiacin, etc. Para aplicaciones software pueden incluir las condiciones de uso, entorno
de usuario, disponibilidad de recursos, mantenimiento, y manejo y recuperacin de
errores.]
10.
Requerimientos de Documentacin
[Esta seccin describe la documentacin que debe ser desarrollada para dar soporte
al despliegue exitoso de la aplicacin.]
10.1.
Manual de Usuario
[Describa el propsito y contenido del Manual de Usuario. Discuta sobre el tamao

deseado, nivel de detalle, necesidad de ndice, glosario, tutorial versus la
estrategia del manual de referencia, etc. Dando formato e imprimiendo las
constantes que tambin deben ser identificadas.]
10.2.
Gua de Instalacin, Configuracin, y archivo Read Me
[Consiste en un documento que incluye las pautas de instrucciones de instalacin y

configuracin, es importante que entregue una solucin completa. Tambin se
incluye tpicamente como un componente estndar
El archivo Read Me puede incluir una seccin de Lo Nuevo de esa versin, y un
capitulo de compatibilidad con versiones antiguas. La mayora de los usuarios
tambin aprecian la documentacin de bugs conocidos y sus soluciones.]
21
8.4.4 Plantilla Especificacin de Requerimientos de Software

Especificacin de
Requerimientos de Software (SRS)
Versin <1.1.0>
documento de Especificacin de Requerimientos de Software. El texto entre
parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad
guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body
Text se activa automticamente cuando se ingresan prrafos de texto definitivo. El
formato del texto debe tener tipo de letra verdana. ]
[NOTA: Para proyectos pequeos, de duracin menor a un mes y un equipo de
menos de 3 personas, este documento se puede reemplazar con una
referencia al documento Anlisis Preliminar. En este caso el jefe del proyecto
necesita mantener el documento Anlisis Preliminar durante el ciclo de vida
del proyecto como lnea base de requerimientos.]
22
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
23
ndice
1
INTRODUCCIN...........................................................................................................12
1.1 Antecedentes..................................................................................................................12
1.2 Problemtica..................................................................................................................12
1.3. Definiciones, Siglas, y Abreviaciones...........................................................................170
1.4. Referencias.....................................................................................................................170
1.5. Resumen Ejecutivo........................................................................................................170
2. Descripcin General.............................................................................................................179
2.1.
Especificacin de Funcionalidades.........................................................................179
2.2.
Supuestos y Dependencias......................................................................................180
2.3.
Acuerdos con el Cliente para la Administracin de Requerimientos......................180
3. Especificacin de Requerimientos........................................................................................180
3.1.
Reportes de Casos de Uso.......................................................................................180
3.2.
Requerimientos Funcionales...................................................................................180
3.3.
Requerimientos Adicionales....................................................................................182
3.4.
Requerimientos no Funcionales..............................................................................182
3.5.
Requerimientos Tcnicos........................................................................................183
3.6.
Requerimientos de Proceso.....................................................................................183
4. Administracin de Requerimientos......................................................................................183
4.1. Conjunto de Requisitos..................................................................................................184
4.2. Requisitos Individuales..................................................................................................184
4.3. Criterios de Revisin de Requerimientos......................................................................184
24
Especificacin de Requerimientos de Software

1. Introduccin
[La introduccin de la Especificacin de Requerimientos de Software debe ser
un resumen del documento completo. Debe incluir el propsito, mbito,
definiciones, acrnimos, abreviaciones, referencias, y resumen ejecutivo de este
documento]
1.1.
Propsito
El propsito de este documento es capturar todos los requerimientos de software del

sistema, o un subconjunto del sistema.
[Nota: Los Requerimientos que se realizarn utilizando algn framework
transaccional deben ser especificados en el documento apropiado para eso]
1.2.
mbito
[Prrafo obligatorio.]
[Una descripcin del entorno afectado; que proyectos se ven afectados o
influenciados por esta Especificacin de Requerimientos de Software.]
1.3.
Definiciones, Acrnimos y Abreviaciones
[Prrafo obligatorio si existen trminos, definiciones acrnimos o abreviaciones.]

[Esta subseccin debe proporcionar las definiciones de todos los trminos,
acrnimos, y abreviaciones requeridas para interpretar correctamente la
Especificacin de Requerimientos de Software. Esta informacin puede ser
entregada a modo de referencia al Glosario del proyecto.]
[Recomendacin: Se sugiere mantener solo un glosario para el proyecto.]
1.4.
Referencias
[Prrafo obligatorio si existen referencias.]

[Esta subseccin debe entregar una lista de todos los documentos referenciados en
cualquier lugar de esta Especificacin de Requerimientos de Software. Cada
documento debe ser identificado por ttulo, edicin (si es aplicable), fecha, y
editorial. Especificar las fuentes de donde se pueden obtener estas referencias,
esta informacin puede ser entregada como referencia a un apndice o a otro
documento.]
1.5.
Resumen Ejecutivo
[Prrafo NO obligatorio.]
[Esta subseccin debe describir el resto del documento conteniendo y explicando
cmo est organizado.]
2. Descripcin General
[Se considera en esta parte la descripcin de los factores principales que afectan al
espacio de la solucin. Incluya aquellos tems como perspectiva del producto,
25
funciones del producto, caractersticas de usuario, limitaciones, supuestos y
dependencias. No se incluye en esta seccin la descripcin de los requerimientos.]
2.1.
Especificacin de Funcionalidades
[Si usa el modelado de casos de uso, esta seccin debe contener la referencia de
ste, y una descripcin o resumen del modelo o del subconjunto ms
representativo del mismo. Esto incluye una lista de nombres y breves
descripciones de los casos de uso, actores, diagramas aplicables y relaciones...
En caso de no existir modelo de caso de uso se deben referenciar todas las
descripciones existentes de las funcionalidades, ya sean minutas de reunin,
correos electrnicos, etc. Es necesario agregar esas descripciones en esta seccin y
en el seccin 1.4 Referencias del documento se necesitan mencionar todos los
fuentes de los requerimientos.]
[Este punto se puede reemplazar con la plantilla Excel de Administracin de
Requerimientos haciendo referencia.]
2.2.
[Esta seccin describe cualquier factibilidad tcnica clave, disponibilidad de
componentes o subsistemas, u otros supuestos realizados en los cuales la
viabilidad del software descrito en esta Especificacin de Requerimientos de
Software se base.]
2.3. Acuerdos con el Cliente para la Administracin de

Requerimientos
[En esta seccin se define como se tratarn los cambios de los requerimientos.
Normalmente en la Orden de Servicio se define un porcentaje como cota para
realizar posibles cambios en los requerimientos. Este impacto se mide en la
cantidad de horas/hombre que requiera esta modificacin.]
3. Especificacin de Requerimientos
[Esta seccin debe describir detalladamente todos los requerimientos de software,
de forma de permitir a los diseadores, disear el sistema para satisfacer los
requerimientos como tambin a los probadores disear un plan de test adecuado
para poder verificar el cumplimiento de los mismos. Cuando se usa el modelado de
casos de uso, estos requerimientos se capturan en los casos de uso, y en las
especificaciones adicionales aplicables, Si no se usa el modelado de casos de uso,
la definicin de especificaciones adicionales debe insertarse directamente aqu.]
3.1.
Reportes de Casos de Uso
[En modelado de casos de uso, ellos definen la mayora de los requerimientos
funcionales del sistema, y algunos requerimientos no funcionales. Para cada caso
de uso en el modelo superior, o subconjunto del mismo, refirase o cierre, el
26
reporte de caso de uso en esta seccin. Asegrese de que cada requerimiento est
claramente etiquetado.]
[Para proyectos pequeos, de duracin menor a un mes y un equipo de menos de 3
personas, este prrafo se puede reemplazar con una referencia a documento
Anlisis
Preliminar.]
3.2.
Requerimientos Funcionales
[En esta seccin se deben describir todos los requerimientos funcionales en forma
detallada, esta seccin debe ser usada cuando las funcionalidades no son
transacciones de algn framework transaccional. La descripcin debe ser
suficientemente clara para permitir a los diseadores hacer un diseo apropiado,
los programadores entender funcionalidad y a los probadores elaborar un plan de
pruebas apropiado.]
[Datos a Definir por cada requerimiento no Funcional]
Campo
En qu Consiste
Los dgitos deben ir separados por "comas".
El primer dgito indica la fase en que se ingres el requerimiento. El
segundo dgito indica la iteracin.
Nmero (F,I,ID,V)
El tercer digito indica el ID del requerimiento, el cual no se puede
repetir en ninguna fase ni iteracin anterior (ES UNICO).
El cuarto indica la versin para un mismo requerimiento, en caso de
que un requerimiento sea modificado.
Fecha
Fecha en que se solicita el requerimiento o cambio.
Funcionalidad
Corresponde al requerimiento listado en la planilla TEC
Puede tener tres valores:
I : Requerimiento Inicial
Tipo
N : Nuevo Requerimiento
M: Modificacin del Requerimiento
Referencia a artefacto donde esta requerimiento escrito.
La referencia tiene siguiente formato:
Origen
<direccin relativa>\<nombre de artefacto>
Pedido por
Quien pide el requerimiento
Asignado a
Quien es asignado para administrar y resolver requerimiento
Prioridad asignada segn:
A: Alto
Prioridad
M: Medio
B: Bajo
Corresponde al estado actual del requerimiento reportado, segn:
PROPUESTO ACEPTADO
ASIGNADO
CONSTRUIDO VALIDADO
Estado
REVISADO
CANCELADO TERMINADO
27
Tipo de Modificacin del requerimiento, se aplica solo para cambios.
Segn:
FUNCIONAL
NO FUNCIONAL
Categora
DE PROCESO TCNICO
Impacto del
Requerimiento
Descripcin
Fecha de Inicio
Fecha de Trmino
Duracin (horas)
Tiempo de Cambios
(*)
Artefactos que se necesitan cambiar.

Incluido componentes, cdigo, pginas, (no solo documentos).
Por defecto:
UNKNOWN
ALTO
MEDIO
BAJO
Breve descripcin del requerimiento - texto de requerimiento
Fecha inicio de la implementacin
Fecha final de la implementacin
Estimacin de duracin de requerimiento en horas.
Tiempo en minutas que se gasto para cambiar la planilla (ingresar,
borrar o cambiar requerimientos).
3.3. Requerimientos Adicionales

[Las especificaciones adicionales capturan requerimientos que no estn incluidos en
los casos de uso. Los requerimientos especficos de las Especificaciones
adicionales, que son aplicables a este subsistema o caracterstica. Estos pueden ser
capturados directamente en este documento o referenciarse en Especificaciones
Adicionales por separado. Asegrese de que cada requerimiento est claramente
etiquetado.]
[Requerimientos adicionales son tambin requerimientos funcionales.]
3.4.
Requerimientos no Funcionales
[En esta seccin se describen los aspectos no funcionales, tales como tiempo de
respuesta, esttica de la aplicacin, facilidad de navegacin, etc.]
[Datos a Definir por cada requerimiento no Funcional.]
Campo
En qu Consiste
28
Nmero (F,I,ID,V)
Fecha
Funcionalidad
Tipo
Origen
Pedido por
Asignado a
Prioridad
Estado
Categora
Impacto del
Requerimiento
Descripcin
Fecha de Inicio
Fecha de Trmino
Duracin (horas)
Tiempo de Cambios
(*)
Los dgitos deben ir separados por "comas".

El primer dgito indica la fase en que se ingres el requerimiento. El
segundo dgito indica la iteracin.
El tercer digito indica el ID del requerimiento, el cual no se puede
repetir en ninguna fase ni iteracin anterior (ES UNICO).
El cuarto indica la versin para un mismo requerimiento, en caso de
que un requerimiento sea modificado.
Fecha en que se solicita el requerimiento o cambio.
Corresponde al requerimiento listado en la planilla TEC
Puede tener tres valores:
I : Requerimiento Inicial
N : Nuevo Requerimiento
M: Modificacin del Requerimiento
Referencia a artefacto donde esta requerimiento escrito.
La referencia tiene siguiente formato:
<direccin relativa>\<nombre de artefacto>
Quien pide el requerimiento
Quien es asignado para administrar y resolver requerimiento
Prioridad asignada segn:
A: Alto
M: Medio
B: Bajo
Corresponde al estado actual del requerimiento reportado, segn:
PROPUESTO
ACEPTADO
ASIGNADO
CONSTRUIDO
VALIDADO
REVISADO
CANCELADO
TERMINADO
Tipo de Modificacin del requerimiento, se aplica solo para cambios.
Segn:
FUNCIONAL
NO FUNCIONAL
DE PROCESO TCNICO
Artefactos que se necesitan cambiar.
Incluido componentes, cdigo, paginas, (no solo documentos).
Por defecto:
UNKNOWN
ALTO
MEDIO
BAJO
Breve descripcin del requerimiento - texto de requerimiento
Fecha inicio de la implementacin
Fecha final de la implementacin
Estimacin de duracin de requerimiento en horas.
Tiempo en minutas que se gasto para cambiar la planilla (ingresar,
borrar o cambiar requerimientos).
29
3.5.
Requerimientos Tcnicos
[En esta seccin se describen los requerimientos tcnicos, tales como sistema
operativo, plataforma de arquitectura, por ejemplo WebSphere, .NET, etc.]
[Este punto se puede reemplazar referenciando a la plantilla Excel de Administracin
de Requerimientos.]
3.6.
Requerimientos de Proceso
[En esta seccin se describen los requerimientos de proceso. Por ejemplo, para
desarrollo se necesita usar proceso de desarrollo en cascadas, RUP, XP, ITDA-KP,
Este prrafo se puede relacionar con artefacto Configuracin del Proceso o con el
Plan del Proyecto.]
[Este punto se puede reemplazar haciendo referencia a
Administracin de Requerimientos.]
la plantilla Excel de
4. Administracin de Requerimientos
[En esta seccin se especifica cmo se realizara el seguimiento de los
requerimientos, y los documentos asociados a este seguimiento, as mismo, en
esta seccin se describen como se realizaran los posibles cambios o nuevas
modificaciones existentes durante el proyecto. Esto normalmente se puede seguir
con la plantilla de Administracin de Requerimientos al cual se debe referenciar en
esta seccin.]
Normalmente estos controles se llevan mediante una Excel para mayor facilidad en
el control y la administracin
4.1. Conjunto de Requisitos

Caracterstica
Resultado
R1
R2
R3
Observaciones
Completos
Consistentes
Correctos
Priorizados
Comprensibles
Organizados
4.2. Requisitos Individuales
Caso de uso
/ Requisito
(1)
Completo
Trazabilidad hacia
Adelante
Atrs
Sin
ambigedad
Verificable
Independiente
del Diseo e
Implementar
Comprensible
30
R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3
R1
R2
R3
R1 R2
R3
(1) Requisito hace referencia a los No-Funcionales y a los Funcionales cuando son expresados
en sentencias y no en C
31
4.3. Criterios de Revisin de Requerimientos

APLICAN AL CONJUNTO DE REQUISITOS
Se toman todos los requisitos de software del sistema. Estos pueden estar
dados en casos de uso o sentencias.
Aplica a
especificacin en
Caso de
Sentencia
Uso
Accin a seguir si
NO cumple
El conjunto de requisitos de software esta completo si:

a). Incluye requisitos orientados a: funcionalidad,
desempeo, confiabilidad, usabilidad, disponibilidad, manejo
x
de errores, configuracin, mantenimiento, carga de datos,
respaldo, depuracin e interfaces externas.
Completos
b). Todos y cada uno de los requisitos de software estn

asociados al menos a una necesidad del negocio,
caracterstica del producto o requisito de usuario. Debido a x
que la trazabilidad es bi-direccional tambin debe verificarse
que cada necesidad tenga asociados al menos una
caracterstica y requisito de software.
ALERTAR
DETENER
c). En los casos de uso estn claramente descritos los

x
actores que participan en ellos.
ALERTAR
El conjunto de requisitos de software es consistente si:

a). El diagrama de casos de uso es consistente con las
convenciones de UML, u otro lenguaje de modelado bien
definido, dnde son bien empleados los elementos grficos x
que representan las relaciones, los actores y los casos de
uso
b). No hay comportamiento comn especificado en dos
requisitos diferentes
Consistente
c). No hay conflicto entre los rasgos de un comportamiento.

Por ejemplo, una precondicin del caso de uso 'X' implica
que el comportamiento del caso de uso 'Y' debe haber
ocurrido, y una precondicin del caso de uso 'Y' implica que
se haya dado algn comportamiento del caso de uso 'X'. x
Otro ejemplo: un requisito define que siempre debe darse el
comportamiento 'A' antes que el comportamiento 'B', pero
otro requisito indica que el comportamiento 'B' siempre debe
ocurrir antes que el 'A'.
d). No hay ms de un requisitos que enuncia el mismo
comportamiento u objetivo pero utilizando diferentes
x
trminos.
e). Los requisitos de un paquete dado son consistentes con
x
el tema o idea capturada en el nombre del paquete
f). Todos los casos de uso estn asociados por lo menos
ALERTAR
ALERTAR
DETENER
ALERTAR
ALERTAR
con un actor. Si no es as, el caso de uso debe estar x

asociado con otros casos de uso va relaciones de
extensin, inclusin, generalizacin.
El conjunto de requisitos de software es correcto si:
Correcto
Priorizados
ALERTAR
a). Cada requisito representa una parte necesaria para el

x
sistema a construir.
ALERTAR
b). Los requisitos han sido revisados y aprobados por el

x
cliente / usuario
DETENER
El conjunto de requisitos de software esta priorizado si:
32
a). Est definida la importancia relativa de cada requisito.
Por ejemplo, puede ser priorizado por importancia para el
negocio, complejidad para implantar, riesgo arquitectnico, x
costo de desarrollar, estabilidad del requisito, entre otros.
ALERTAR
ALERTAR
El conjunto de requisitos de software es comprensible si:

a). Presenta claramente el comportamiento del sistema. Es
decir, es fcil de entender lo que el sistema hace al revisar el x
modelo.
b). En los diagramas de casos de uso no hay largas cadenas
x
de relaciones de inclusin y extensin.
ALERTAR
c). No es presentado un requisito por cada pantallas de

x
interfaz grfica.
Comprensible
ALERTAR
d). En los diagramas de casos de uso no hay

descomposicin funcional o flujo de trabajo, cuyos sntomas
son: casos de uso demasiado pequeos; muchos casos de
uso; dificultad para entender el modelo; nombres de casos x
de uso como: operacin + objeto o funcin + dato (por
ejemplo Insertar tarjeta); asociaciones con punta de flecha (o
sin ella) entre casos de uso semejando un flujo de
actividades
e). El modelo y/o diagrama tiene una seccin donde
ALERTAR
describe el contenido del mismo, por ejemplo la secuencia x

ms comn de los casos de uso.
El conjunto de requisitos de software es organizado si:
Organizados
ALERTAR
a). Son organizados usando mltiples diagramas o paquetes

para dividir y organizar la funcionalidad del sistema
hacindolos comprensibles para los interesados. Cuando el
modelo es grande y/o las responsabilidades son distribuidas
en diversas partes del modelo, deben utilizarse paquetes de
x
requisitos de forma que sean intuitivos y hagan que el
modelo sea fcil de entender. Ejemplos de paquetes son
aquellos organizados por rea funcional, por actor, por
dependencia, por relacin entre los actores y el sistema, por
iteracin, entre otros.
DETENER, si no
hay al menos un (1)
diagrama de CU
APLICAN A REQUISITOS INDIVIDUALES
Los requisitos de software pueden estar dados en casos de uso o sentencias.
Aplica a
especificacin en
Caso de
Sentencia
Uso
Accin a
seguir si NO
cumple
Un requisito de software esta completo si:

a). El caso de uso proporciona las interacciones y comportamiento
x
necesarios para satisfacer las metas u objetivos de los actores
b). El requisito contiene nicamente la funcionalidad que ser realizada
x
por el sistema.
c). El caso de uso tiene claramente enunciado: Propsito,
x
Precondicin, Pos condicin, Flujos alternos y de excepciones
Completo
DETENER
DETENER
DETENER
d). Para cada caso de uso estn definidas las respuestas del software
a todas las entradas del actor tanto para flujos vlidos como no x
vlidos.
e). El requisito expresado como sentencia breve (tradicional) tiene
DETENER
33
definidas las respuestas del software tanto para comportamiento
vlidos como no vlidos.
DETENER
DETENER
f). El requisito expresado como sentencia breve (tradicional) tiene en

el enunciado el tipo de usuario, resultado deseado, objeto y calificador
medible.
Un requisito de software es rastreable hacia adelante si:
Trazabilidad
hacia adelante
a). El tiene un nico nombre o nmero de referencia as como

los componentes de diseo, mdulos de implementacin y
todos los elementos dnde este es referenciado.
Trazabilidad
hacia atrs
Un requisito de software es rastreable hacia atrs si:

a). Tiene referencia explcita a su origen o fuente.
ALERTA
ALERTA
Un requisito de software no es ambiguo si:
Sin
ambigedad
a). Tiene una sola interpretacin por usuarios e implementadores.

Para ello no deben existir palabras o frases que favorezcan la
mltiple interpretacin, tales como: Conjuncin (y, con, tambin), ya
que posiblemente representa varios requisitos; Disyuncin (o), ya que
posiblemente no representa un comportamiento concreto; y palabras
como usualmente, con frecuencia, normalmente, flexible, verstil,
eficiente, amigable al usuario y que signifiquen posibilidad (puede, tal
vez, probablemente).
b). No es excesivamente detallado con mltiple y profundo
anidamiento, sea por inclusiones en los casos de uso o por jerarqua
en las sentencias.
Un requisito de software es verificable si:
Verificable
Independiente
Diseo e
implementaci
n
ALERTA
ALERTA
a). No existen palabras o frases no verificables tales como: funciona

bien, rpido, buen desempeo, usualmente ocurre, entre otras.
DETENER
b). El requisito est enunciado en trminos cuantificables y

verificables
DETENER
c). En los casos de uso las precondiciones y pos-condiciones estn

declaradas de forma que pueden ser probadas.
DETENER
Un requisito de software es independiente del diseo e implementacin si:

a). En el requisito NO son empleadas palabras o frases tcnicas,
tales como: nombre de componentes, campos de bases de datos,
objetos de software, restriccin de diseo, entre otros.
ALERTA
Un requisito de software es comprensible si:
Comprensible
a). El caso de uso es auto-explicados. Esto es, las anotaciones,

modelos y formato de los casos de uso deben permitir que el
interesado revise, entienda y valide los casos de uso con una mnima
cantidad de esfuerzo.
b). El requisito est escrito en el 'lenguaje' de los clientes y usuarios,
utilizando trminos que son usados en el dominio del negocio
(Glosario).
ALERTA
ALERTA
34
8.4.5 Plantilla de Anlisis Preliminar

Anlisis Preliminar
Versin <1.1.0>
[Nota: Esta Plantilla tiene por finalidad servir de base para la confeccin del
documento Anlisis Preliminar. El texto entre parntesis cuadrados y desplegado
en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser
borrado antes de la publicacin del documento. El estilo Body Text se activa
automticamente cuando se ingresan prrafos de texto definitivo. El formato del
texto debe tener tipo de letra verdana.]
35
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
36
ndice
1
Introduccin
1.1 Propsito
1.2 mbito
1.3 Referencias
1.4 Resumen Ejecutivo
Requerimientos
2.1 Casos de Uso de la funcionalidad <Nombre de Funcionalidad>
2.1.1
Actores
2.1.2
Casos de Uso
2.2 Casos de Uso de la funcionalidad <Nombre de Funcionalidad>
2.2.1
Actores
2.2.2
Casos de Uso
Anlisis Preliminar
3.1 Modelo de Anlisis de Arquitectura Actual
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
2
1
8
3
1
8
37
3.2 Modelo de Anlisis de Arquitectura Propuesta

3.3 Diagrama de secuencia de Escenario Tpico
para la funcionalidad <Nombre de Funcionalidad>
3.4 Diagrama de Despliegue (Deployment)
Descripcin de la Solucin Propuesta
3
1
8
3
1
8
3
1
8
3
1
8
3
38
Anlisis Preliminar
1. Introduccin
[La introduccin del Anlisis Preliminar provee un resumen del documento
completo. Presente cualquier informacin que el lector pueda necesitar para
entender el documento en esta seccin.]
1.1.
Propsito
[Especifique el propsito del Anlisis Preliminar.]

1.2.
mbito
[Una breve descripcin del mbito de este Anlisis Preliminar; que proyecto(s)
estn asociados a l, o cualquier cosa que pueda versen afectada o influenciada
por este documento.]
1.3.
Referencias
[Esta subseccin provee una lista completa de todos los documentos referenciados
en cualquier parte de este Anlisis Preliminar. Identifique cada documento por
ttulo, nmero de edicin (si es aplicable), y editorial. Especifique las fuentes de
donde pueden obtenerse estas referencias. Esta informacin puede ser entregada a
modo de referencia a un apndice o a otro documento.]
1.4.
Resumen Ejecutivo
[Esta subseccin describe el contenido del resto del Anlisis Preliminar, y explica
cmo est organizado el documento.]
2. Requerimientos
[Desarrolle en esta seccin los anlisis bsicos de casos de uso, puede aadir o
eliminar subsecciones segn sea necesario]
2.1.
Casos de Uso de la funcionalidad <Nombre de Funcionalidad>
[Inserte el diagrama del Modelo de Casos de Uso correspondiente a la

funcionalidad <Nombre de funcionalidad>. Puede usar el siguiente texto como
punto de partida:
El modelo de los casos de uso (<Numero de la Figura>) representa la primera
abstraccin de los requerimientos del sistema de alto nivel, con sus
descripciones.]
Actores
[Nombre los actores que interactan con el sistema y una describa brevemente la
funcin de cada actor]
Casos de Uso
[Nombre y describa los distintos casos de uso mostrados en la figura correspondiente

a esta subseccin]
2.2.
Casos de Uso de la funcionalidad <Nombre de Funcionalidad>
[Para la explicacin de estos puntos, refirase al punto 2.1]
Actores
39
Casos de Uso
3. Anlisis Preliminar
3.1.
Modelo de Anlisis de Arquitectura Actual
[Incluya un diagrama del modelo de Anlisis de la arquitectura actual del sistema

(si corresponde), describa brevemente la generalidad del modelo.]
3.2.
Modelo de Anlisis de Arquitectura Propuesta
[Incluya un diagrama del modelo de Anlisis de la arquitectura propuesto como

solucin, describa brevemente la generalidad del modelo.]
3.3.
Diagrama de secuencia de Escenario Tpico para la funcionalidad
<Nombre de Funcionalidad>
[Incluya un diagrama de secuencia para el caso tpico de cada funcionalidad, no es
obligatorio el uso de este diagrama.]
3.4.
Diagrama de Despliegue
[Incluya un diagrama de despliegue para el sistema]
4. Descripcin de la Solucin Propuesta

[Ingrese la informacin de cada modulo de la solucin propuesta, la columna
llamada Estimacin del Esfuerzo es para informacin interna de la empresa y
debe ser eliminada al momento de presentar este documento al cliente]
Mdulo
[Nombre
de
cada
modulo
mostrado en el
diagrama del
Modelo de
Anlisis]
Descripcin
[Breve descripcin de la
funcionalidad que cumple este
modulo]
Solucin
[Nombre de la
solucion
propuesta, por
ejemplo el
lenguaje o
herramienta]
Estimacin del
Esfuerzo
[Cantidad de
esfuerzo
necesario,
estimado por
el arquitecto,
para
desarrollar la
solucin]
40
8.4.6 Plantilla Solicitud de Requerimientos
<Nombre Del Proyecto>

Solicitud de Requerimientos
Versin <1.1.0>
[Esta plantilla tiene por finalidad servir de base para la confeccin del documento
Solicitud de requerimientos. El texto entre parntesis cuadrados y desplegado en azul
itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de
la publicacin del documento.]
41
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
<Detalles>
Autor
<Nombre>
42
Solicitud de Requerimiento
No. Interno:
Prioridad:
Detalle del Solicitante

Nombre:
Unidad:
Gerencia de Divisin:
Fecha solicitud:
Centro Costo:
Anexo:
Detalle del Requerimiento

Tipo
Sistema Nuevo
Cambio Normativo
Cambio requerido por un Cliente
Otros
Correccin de un problema presentado con el sistema
Descripcin:
Nombre del Sistema: ____________________________________________________
rea de Aplicacin: _____________________________________________________
Explicacin detallada del requerimiento: (Si es necesario incluya un anexo)
Justificacin: (Indique las razones, que a su juicio, justifican el requerimiento)
Comit Control de Cambios:

Firma:
Aprobado
Fecha:
Rechazado
Comentarios:
Solo para Uso Interno de la Organizacin
43
Evaluacin
Evaluado por:
Recursos
Externos:
SI NO
Firma:
Fecha:
Recursos in ternos recomendados:
Costo total estimado:
Das/Hombre esfue rzo estimados:
Descripcin del Impacto: (Programas y archivos a crear, modificar, etc.)
Nombre:
Firma:
Fecha:
Fase de Ejecucin
Jefe de Proyecto Asignado:
Firma:
Fecha de Inicio:
Empresa o recursos internos asignados:
Das/hombre reales:
Comentarios
Fecha Entrega a Pruebas:
Firma:
Fecha aprobacin pruebas: (a llenar por Ingeniera de Procesos)
Firma:
Fecha aprobacin formalidades liberacin: (a llenar por Informtica)
Firma:
Fecha Liberacin: (Comit Control de Cambios)
Firma:
44
45
8.4.7 Plantilla Check List del Ambiente

Checklist de Ambiente
<Versin 1.1.0>
[Nota: Esta plantilla tiene por finalidad servir de base para la confeccin del
documento Checklist de Ambiente. El texto entre parntesis cuadrados y
desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y
debe ser borrado antes de la publicacin del documento. El estilo Body Text se
activa automticamente cuando se ingresan prrafos de texto definitivo. El
formato del texto debe tener tipo de letra verdana.]
46
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
47
ndice
1
Introduccin
1.1
1.2
1.3
1.4
1.5
Check Lists
2.1
2.2
2.3
2.4
2.5
191
Propsito
mbito
Definiciones, acrnimos y abreviaciones.
Referencias
Resumen Ejecutivo
192
General
Ambiente de Desarrollo
Ambiente de Test
Ambiente de Produccin
Ambiente de General
191
191
191
191
191
192
192
193
193
194
48
Check List
1. Introduccin
1.1.
Propsito
[Una descripcin breve acerca del propsito de este Checklist. Tambin agregue
una descripcin breve de a qu se aplica la Checklist; qu se ve afectado o
influenciado por este documento.]
1.2.
mbito
[Describa el alcance de este Checklist; qu proyectos estn asociados a el y cualquier

cosa que se vea afectada o influenciada por este documento.]
1.3.
[Esta sub-seccin provee las definiciones de todos los trminos, acrnimos, y

abreviaciones requeridas para interpretar correctamente el Checklist. Esta
informacin puede entregarse a modo de referencia al glosario del proyecto.]
1.4.
Referencias
[Esta sub-seccin provee una completa lista de todos los documentos referenciados
en cualquier punto del Checklist. Identifique cada documento por titulo, nmero
de edicin (si es aplicable), fecha, y editorial. Especifique las fuentes de donde
pueden obtenerse estas referencias.]
1.5.
Resumen Ejecutivo
[Describa brevemente que contiene el resto del Checklist y explique cmo est
organizado este documento.]
2. Checklists 2.1.
General
General
Check
[Rol del
Responsable]
Organigrama
Disponibilidad
Accesibilidad
Seguridad
Solicitudes de
Necesidades
Periodicidad y
Rol
Comentario
[Aada cualquier
comentario
correspondiente a este
campo como sugerencias,
tareas, descripciones o
herramientas]
49
Participantes de
Reuniones de
Coordinacin
Planes de Backup y
Restore para ambiente de
desarrollo y test
2.2.
Ambiente de
desarrollo
Mquinas
Check
Inicial
Check
Final
Servidor web
Servidor DB
Check
Inicial
Check
Final
Servidor de
componentes
Servidor para SCM
Software para
desarrollo
2.3.
Comentario
[Rol del
Responsable]
Estaciones de trabajo
Caracterstica de la
Red
Ambiente de
desarrollo
Software
Sistema operativo
Rol
Rol
[Aada
cualquier
comentario
campo como
sugerencias, tareas,
descripciones o
herramientas]
Comentario
Ambiente de Pruebas
Ambiente de Pruebas
Check
Inicial
Check
Final
Rol
Comentario
50
[Rol del
Responsable]
Mquinas
Estaciones de trabajo
Servidor Web
Servidor DB
Servidor de
componentes
[Aada cualquier
comentario
herramientas]
Herramientas
Herramientas para
pruebas
2.4.
Check
Inicial
Check
Final
[Rol del
Responsable]
Mquinas
Check
Inicial
Check
Final
Servidor DB
Servidor de
componentes
Servidor Firewall
Ambiente de produccin
Servidor Web
Schema de seguridad
Rol
Rol
Comentario
[Aada cualquier
comentario
herramientas]
Comentario
51
Sistema operativo
Firewall
Servidor Web
Conectividad
Software
2.5.
Ambiente en General
Ambientes en General
Check
Inicial
Check
Final
[Rol del
Responsable]
Protocolos
Interfaces
Diagramas de Navegacin
Topologa de la red en
produccin
Relacin Datos - Tablas
Rol
Comentario
[Aada cualquier
comentario
herramientas]
52
8.4.8 Plantilla Plan de Especificacin del Ambiente
<Nombre del proyecto>

Plan de Especificacin de Ambiente
Versin <1.1.0>
[Nota: Esta plantilla tiene por finalidad servir de base para la confeccin del
documento Especificacin de Ambiente. El texto entre parntesis cuadrados y
activa automticamente cuando se ingresan prrafos de texto definitivo. El
formato del texto debe tener tipo de letra verdana.]
53
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
54
ndice
1. Introduccin
198
1.1 Propsito
1.2 mbito
1.3 Definiciones, Acrnimos y Abreviaciones
1.4 Referencias
1.5 Resumen ejecutivo
2. Recursos
198
2.1 Recursos computacionales crticos
2.2 Personal y Responsables
3. Modelo de Ambientes
198
3.1
3.3
Ambiente de Pruebas
198
198
198
198
198
198
198
198 3.2
198
198
55
Especificacin de Ambiente
1. Introduccin
[La introduccin de la Especificacin de Ambiente proporciona una descripcin del
documento completo. Este incluye el propsito, mbito, definiciones, acrnimos,
abreviaciones, referencias, y una descripcin de este documento.]
2.6.
Propsito
[Especifica el propsito de este documento.]

2.7.
mbito
[Es una descripcin del mbito de esta Especificacin de Ambiente; que proyectos
estn asociados con cualquier cosa que afecte o influya este documento.]
2.8.
Definiciones, Acrnimos y Abreviaciones
[Definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para

interpretar correctamente la Especificacin de Ambiente. Esta informacin puede ser
obtenida del Glosario del proyecto.]
2.9.
Referencias
[Lista completa de todos los documentos referenciados en cualquier lugar de la

Especificacin de Ambiente. Identificando cada uno por ttulo, numero de edicin si
es aplicable, fecha, y editorial. Especificando las fuentes de donde se pueden obtener
las referencias. Ejemplo: [1] Visin del proyecto. [2] Lista de riesgos del proyecto.]
2.10. Resumen ejecutivo
[Describe qu contiene el resto del documento y explica cmo est organizado.]
3. Recursos
3.1.
Recursos computacionales crticos
[Esta sub-seccin describe qu son recursos computacionales crticos tales como

hardware, tiempo de disponibilidad, etc. Por ejemplo: para finalizar el proyecto faltan
computadores para pruebas y falta acceso de mainframe, o para produccin se necesita
un nuevo servidor. Si para un proyecto existen recursos computacionales crticos se
necesitan poner como riesgo dentro de artefacto Lista de riesgos].
3.2.
Personal y Responsables
[Describa en este punto los nombres de las personas asignadas a cada rol.]
4. Modelo de Ambientes
[Contiene diagramas de despliegue para cada ambiente. El modelo de ambiente contiene
una descripcin detallada de aspectos tales como hardware y software]
4.1.
[Incluya aqu los diagramas de despliegue correspondientes al ambiente de desarrollo]

4.2.
Ambiente de Pruebas
[Incluya aqu los diagramas de despliegue correspondientes al ambiente de pruebas]

4.3.
56
[Incluya aqu los diagramas de despliegue correspondientes al ambiente de produccin]
57
8.4.9 Plantilla Plan del Desarrollo de Software

Plan de Desarrollo del Software
Versin <1.1.0>
documento Plan de Desarrollo del Software. El texto entre parntesis
cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar
al autor y debe ser borrado antes de la publicacin del documento. El estilo Body
Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]
[Nota: Para proyectos pequeos, los artefactos que deben estar contenidos
en este plan y no como documentos independientes son:
-
Mapeo de Roles
Carta Gantt (en forma de tabla)
Lista de Riesgos
Plan SQA
Plan SCM.
Los documentos obligatorios para proyectos pequeos, que no estn
contenidos en este plan son:
Anlisis Preliminar
TEC
Configuracin del Proceso. ]
58
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
59
ndice
1
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.4.1
4.4.2
4.4.3
Introduccin
203
1.1 Propsito
203 1.2 Alcance
203
1.3 Definiciones, acrnimos y abreviaciones.
203
1.4 Referencias
203
204
Resumen del Proyecto
205
2.1 Propsito del Proyecto, mbito, y Objetivos
205
2.2 Supuestos y Lmites
205
2.3 Entregables del Proyecto
205
2.4 Evolucin del Plan de Desarrollo del Software
208
Organizacin del Proyecto
208 3.1 Estructura Organizacional
208
3.2 Interfaces externas
208
3.3 Roles y Responsabilidades
209
Gestin del Proceso
209
4.1 Estimaciones del Proyecto
209
4.2 Plan de Desarrollo del Software
209
Plan de la fase
209
Objetivos de las iteraciones
211
Versiones
211
Agenda del Proyecto
211
Recursos del Proyecto
214
Presupuesto
214
4.3 Plan de Iteracin
214
4.4 Monitorizacin y Control del Proyecto
215
Plan de Administracin de Requerimientos
215
Agenda del Plan de Control
215
Plan de Control de Presupuesto
215 4.4.4 Plan de Control de Calidad
215 4.4.5 Plan de
Reporte
215
4.4.6 Plan de Medicin
216
4.5 Plan de Administracin de Riesgos
216
4.6 Plan de Clausura
216
Plan de Procesos Tcnicos
216
5.1 Configuracin de Proyecto
216 5.2 Mtodos, Herramientas, y Tcnicas 216
5.3 Plan de Infraestructura
216
5.4 Plan de Aceptacin del Producto
216
Plan de Proceso de Soporte
217
60
7
8
6.1 Plan de CM
6.2 Plan de Evaluacin
6.3 Plan de Documentacin
6.4 Plan de Garanta de Calidad (QA)
6.5 Plan de Resolucin de Problemas
6.6 Plan Administracin de Subcontratista
6.7 Plan de Mejora de los Procesos
Planes Adicionales
218
Anexos
218
217
217
217
217
217
217
217
61

5. Introduccin
[Una descripcin breve acerca del propsito de Plan de Desarrollo del
Software. Agregue tambin una descripcin breve de a que se aplica el Plan de
Desarrollo del Software; que se ve afectado o influenciado por este
documento.]
Este documento provee una visin global del enfoque de desarrollo propuesto basado
en una metodologa de Rational Unified Process en la que nicamente se proceder a
cumplir con las tres primeras fases que marca la metodologa, constando nicamente en
la tercera fase de dos iteraciones. Es importante destacar esto puesto que utilizaremos la
terminologa RUP en este documento. Se incluir el detalle para las fases de Inicio y
Elaboracin y adicionalmente se esbozarn las fases posteriores de Construccin y
Transicin para dar una visin global de todo proceso.
El enfoque desarrollo propuesto constituye una configuracin del proceso RUP de
acuerdo a las caractersticas del proyecto, seleccionando los roles de los participantes,
las actividades a realizar y los artefactos (entregables) que sern generados. Este
documento es a su vez uno de los artefactos de RUP.
5.1.
Propsito
El propsito de este documento es permitir organizar, controlar y administrar la

documentacin referente al proyecto [Nombre del Proyecto]. En este documento se
encuentra la referencia a todos los planes y documentos generados durante el proyecto
los cuales se irn agregando a lo largo del proyecto.
5.2.
Alcance
[Describa el alcance de este Plan de Desarrollo del Software; que proyectos
estn asociados a l y cualquier elemento que se vea afectado o influenciado por
este documento.]
5.3.

[Prrafo obligatorio
abreviaciones.]
si
existen
trminos,
definiciones,
acrnimos
[Esta subseccin provee las definiciones de todos los trminos, acrnimos, y

abreviaciones requeridas para interpretar correctamente el Plan de Desarrollo
del Software. Esta informacin puede entregarse como una referencia al
Glosario del proyecto.]
[Para pequeos proyectos el glosario se puede incorporar en esta
subseccin. Si es incorporado en el documento Anlisis Preliminar, se
debe hacer referencia.]
[Recomendacin: Se sugiere mantener solo un glosario para el proyecto, ste
puede mantenerse en el documento Glosario, en el Anlisis Preliminar o en el
Plan de Desarrollo del Software.]
5.4.
Referencias
62
[Prrafo obligatorio si existen referencias.]
[Esta subseccin provee una completa lista de todos los documentos referenciados en
cualquier punto del Plan de Desarrollo del Software. Identifique cada documento por
ttulo, nmero de edicin (si es aplicable), fecha, y editorial. Especifique las fuentes
de donde pueden obtenerse estas referencias. Esta informacin puede entregarse
como una referencia a un apndice o a otro documento.
Para el Plan de Desarrollo del Software, la lista de artefactos referenciados
debe incluir:
5.5.
TEC Plan
Asignacin de Roles
Plan de Iteracin o Gantt de Iteracin
Plan de Mediciones
Lista de Riesgos
Configuracin de Proyecto
Pautas de la Interfaz de Usuario
Pautas de Diseo
Pautas de Programacin
Pautas de Test
Gua de Estilo del Manual, Convenciones de Cdigo
Especificacin de Ambiente
Plan de Aceptacin del Producto
Plan de Gestin de la Configuracin
Plan de Evaluacin (Slo s ste es un plan por separado normalmente esta

es parte del Plan de Desarrollo del Software en la seccin 6.2)
Plan de Documentacin
Plan SQA
Plan de Resolucin de Problemas
Plan de Administracin del Subcontratista
Plan de Mejora de los Procesos]

Resumen Ejecutivo
[Describa brevemente que contiene el resto de Plan de Desarrollo del Software
y explique cmo est organizado este documento.]
6. Resumen del Proyecto
63
6.1.
Propsito del Proyecto, mbito, y Objetivos
[Describa brevemente el propsito y los objetivos de este proyecto, aada adems
una breve descripcin de los entregables y a quien sern entregados.]
6.2.
Supuestos y Lmites
[Liste los supuestos en los que se ha basado este plan y cualquier limitante, por
ejemplo, presupuesto, staff, equipamiento, y fechas, que sean aplicables al
proyecto.]
6.3.
Entregables del Proyecto
A continuacin se indican y describen cada uno de los artefactos que sern
generados y utilizados por el proyecto y que constituyen los entregables. Esta lista
constituye la configuracin de RUP desde la perspectiva de artefactos, y que
proponemos para este proyecto.
Es preciso destacar que de acuerdo a la filosofa de RUP (y de todo proceso
iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo
del proceso de desarrollo, con lo cual, slo al trmino del proceso podramos tener
una versin definitiva y completa de cada uno de ellos. Sin embargo, el resultado
de cada iteracin y los hitos del proyecto estn enfocados a conseguir un cierto
grado de completitud y estabilidad de los artefactos. Esto ser indicado ms
adelante cuando se presenten los objetivos de cada iteracin.
1) Plan de Desarrollo del Software

Es el presente documento.
2) Modelo de Casos de Uso del Negocio

Es un modelo de las funciones de negocio vistas desde la perspectiva de los
actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.).
Permite situar al sistema en el contexto organizacional haciendo nfasis en los
objetivos en este mbito. Este modelo se representa con un Diagrama de Casos
de Uso usando estereotipos especficos para este modelo.
3) Modelo de Objetos del Negocio

Es un modelo que describe la realizacin de cada caso de uso del negocio,
estableciendo los actores internos, la informacin que en trminos generales
manipulan y los flujos de trabajo (flujos de trabajo) asociados al caso de uso del
negocio. Para la representacin de este modelo se utilizan Diagramas de
Colaboracin (para mostrar actores externos, internos y las entidades
(informacin) que manipulan, un Diagrama de Clases para mostrar grficamente
las entidades del sistema y sus relaciones, y Diagramas de Actividad para
mostrar los flujos de trabajo.
4) Glosario
64
Es un documento que define los principales trminos
Permite establecer una terminologa consensuada. .
usados en el proyecto.
5) Modelo de Casos de Uso

El modelo de Casos de Uso presenta las funciones del sistema y los actores que
hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso.
6) Visin
Este documento define la visin del producto desde la perspectiva del cliente,
especificando las necesidades y caractersticas del producto. Constituye una base
de acuerdo en cuanto a los requisitos del sistema.
7) Especificaciones de Casos de Uso

Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que
no baste con una simple descripcin narrativa) se realiza una descripcin
detallada utilizando una plantilla de documento, donde se incluyen:
precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales
asociados. Tambin, para casos de uso cuyo flujo de eventos sea complejo podr
adjuntarse una representacin grfica mediante un Diagrama de
Actividad.
8) Especificaciones Adicionales
Este documento capturar todos los requisitos que no han sido incluidos como
parte de los casos de uso y se refieren requisitos no-funcionales globales. Dichos
requisitos incluyen: requisitos legales o normas, aplicacin de estndares,
requisitos de calidad del producto, tales como: confiabilidad, desempeo, etc., u
otros requisitos de ambiente, tales como: sistema operativo, requisitos de
compatibilidad, etc.
9) Prototipos de Interfaces de Usuario

Se trata de prototipos que permiten al usuario hacerse una idea ms o menos
precisa de las interfaces que proveer el sistema y as, conseguir
retroalimentacin de su parte respecto a los requisitos del sistema. Estos
prototipos se realizarn como: dibujos a mano en papel, dibujos con alguna
herramienta grfica o prototipos ejecutables interactivos, siguiendo ese orden de
acuerdo al avance del proyecto. Slo los de este ltimo tipo sern entregados al
final de la fase de Elaboracin, los otros sern desechados. Asimismo, este
artefacto, ser desechado en la fase de Construccin en la medida que el
resultado de las iteraciones vayan desarrollando el producto final.
10)
Modelo de Anlisis y Diseo
Este modelo establece la realizacin de los casos de uso en clases y pasando

desde una representacin en trminos de anlisis (sin incluir aspectos de
implementacin) hacia una de diseo (incluyendo una orientacin hacia el
entorno de implementacin), de acuerdo al avance del proyecto.
11)
Modelo de Datos
65
Previendo que la persistencia de la informacin del sistema ser soportada por
una base de datos relacional, este modelo describe la representacin lgica de
los datos persistentes, de acuerdo con el enfoque para modelado relacional de
datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se
utiliza un archivo UML para Modelado de Datos, para conseguir la representacin
de tablas, claves, etc.).
12) Modelo de Implementacin

Este modelo es una coleccin de componentes y los subsistemas que los contienen.
Estos componentes incluyen: ficheros ejecutables, ficheros de cdigo fuente, y todo
otro tipo de ficheros necesarios para la implantacin y despliegue del sistema. (Este
modelo es slo una versin preliminar al final de la fase de Elaboracin,
posteriormente tiene bastante refinamiento).
13)
Modelo de Despliegue
Este modelo muestra el despliegue la configuracin de tipos de nodos del sistema,

en los cuales se har el despliegue de los componentes.
14)
Casos de Prueba
Cada prueba es especificada mediante un documento que establece las

condiciones de ejecucin, las entradas de la prueba, y los resultados esperados.
Estos casos de prueba son aplicados como pruebas de regresin en cada
iteracin. Cada caso de prueba llevar asociado un procedimiento de prueba con
las instrucciones para realizar la prueba, y dependiendo del tipo de prueba dicho
procedimiento podr ser automatizable mediante un script de prueba.
15)
Solicitud de Cambio
Los cambios propuestos para los artefactos se formalizan mediante este

documento. Mediante este documento se hace un seguimiento de los defectos
detectados, solicitud de mejoras o cambios en los requisitos del producto. As se
provee un registro de decisiones de cambios, de su evaluacin e impacto, y se
asegura que stos sean conocidos por el equipo de desarrollo. Los cambios se
establecen respecto de la ltima baseline (el estado del conjunto de los
artefactos en un momento determinado del proyecto) establecida. En nuestro
caso al final de cada iteracin se establecer una baseline.
16)
Plan de Iteracin
Es un conjunto de actividades y tareas ordenadas temporalmente, con recursos

asignados, dependencias entre ellas. Se realiza para cada iteracin, y para todas
las fases.
17)
Evaluacin de Iteracin
Este documento incluye le evaluacin de los resultados de cada iteracin, el

grado en el cual se han conseguido los objetivos de la iteracin, las lecciones
aprendidas y los cambios a ser realizados.
18)
Lista de Riesgos
66
Este documento incluye una lista de los riesgos conocidos y vigentes en el
proyecto, ordenados en orden decreciente de importancia y con acciones
especficas de contingencia o para su mitigacin.
19)
Manual de Instalacin
Este documento incluye las instrucciones para realizar la instalacin del producto.
20)
Material de Apoyo al Usuario Final
Corresponde a un conjunto de documentos y facilidades de uso del sistema,

incluyendo: Guas del Usuario, Guas de Operacin, Guas de Mantenimiento y
Sistema de Ayuda en Lnea
21)
Producto
Los ficheros del producto empaquetados y almacenadas en un CD con los

mecanismos apropiados para facilitar su instalacin. El producto, a partir de la
primera iteracin de la fase de Construccin es desarrollado incremental e
iterativamente, obtenindose una nueva versin al final de cada iteracin.
Los artefactos 19, 20 y 21 se generarn a partir de la fase de Construccin, con lo
cual se han incluido aqu slo para dar una visin global de todos los artefactos que
se generarn en el proceso de desarrollo.
[Liste los artefactos adicionales no incluidos en la lista anterior que se crearan
durante el proyecto, incluyendo las fechas objetivo de entrega. Se puede
remplazar con una referencia a Gantt de proyecto, solo si Gantt contiene datos de
los entregables.]
Fase
Iteracin
Artefacto
Fecha de Entrega
[nombre de artefacto]
6.4.
Evolucin del Plan de Desarrollo del Software
[Tabla de versiones propuestas del Plan de Desarrollo del Software, y el criterio
usado para revisiones no programadas y la reedicin de este plan.]
7. Organizacin del Proyecto

7.1.
Estructura Organizacional
[Describe la estructura organizacional del equipo del proyecto, incluyendo al
administrador y otras autoridades de revisin. Se puede reemplazar con una
referencia a documento Asignacin de Roles.]
67
[Para pequeos proyectos la estructura se puede describir dentro del plan y
no es necesario crear el documento Asignacin de Roles.]
7.2.
Interfaces externas
[Describe como es la interfaz entre el proyecto y los grupos externos. Para cada
grupo externo, identifique los nombres de los contactos internos y externos. Se
puede reemplazar con una referencia a documento Asignacin de Roles.]
[Para Administracin de Requerimientos es necesario establecer quien o quienes
sern la contraparte oficial
para la aceptacin de cambios o nuevos
requerimientos]
7.3.
Roles y Responsabilidades
[Identifique las unidades organizacionales del proyecto que son responsables por
cada una de las disciplinas, detalles del flujo de trabajo, y procesos de soporte. Se
puede reemplazar con una referencia a documento Asignacin de Roles.]
A continuacin se describen las principales responsabilidades de cada uno de los

puestos en el equipo de desarrollo durante las fases de Inicio y Elaboracin, de acuerdo
con los roles que desempean en RUP.
Puesto
Responsabilidad
Jefe de Proyecto
Asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios,
y mantiene al equipo del proyecto enfocado en los objetivos. El jefe de proyecto tambin establece
un conjunto de prcticas que aseguran la integridad y calidad de los artefactos del proyecto.
Adems, se encargar de supervisar el establecimiento de la arquitectura del sistema. Gestin de
riesgos. Planificacin y control del proyecto.
Analista de Sistemas
Captura, especificacin y validacin de requisitos, interactuando con el cliente y los usuarios

mediante entrevistas. Elaboracin del Modelo de Anlisis y Diseo. Colaboracin en la elaboracin
de las pruebas funcionales y el modelo de datos.
Programador
Construccin de prototipos. Colaboracin en la elaboracin de las pruebas funcionales, modelo de

datos y en las validaciones con el usuario
Ingeniero de Software
Gestin de requisitos, gestin de configuracin y cambios, elaboracin del modelo de datos,

preparacin de las pruebas funcionales, elaboracin de la documentacin. Elaborar modelos de
implementacin y despliegue.
8. Gestin del Proceso

8.1.
Estimaciones del Proyecto
[Provee el costo estimado y agenda del proyecto, tambin las bases para estas
estimaciones, los puntos y circunstancias en el proyecto que pueden provocar una
re-estimacin de estos datos.]
8.2.
68
1.1.1. Plan de la fase
[Para pequeos proyectos este prrafo NO es obligatorio]
[Incluya lo siguiente:
Estructura de desglose
Estructura de Desglose de Trabajo (WBS). WBS se define como: "Un WBS es

una agrupacin de componentes del proyecto orientadas a entregables que
organizan y definen el mbito total del proyecto; el trabajo no incluido en el
WBS no pertenece al mbito del proyecto. - Project Management Body of
Knowledge 2008, Project Management Institute, USA
Un TimeLine o Carta Gantt que muestre la posicin en el tiempo de las fases del
proyecto o iteraciones
Identifique las fases ms importantes y su criterio para ser archivados Defina
cualquier versin importante e interfaces previas a realizar.
Se puede reemplazar con una referencia al Gantt del Proyecto si l mismo contiene
el plan de cada fase del proyecto.]
El desarrollo se llevar a cabo en base a fases con una o ms iteraciones en cada una de
ellas. La siguiente tabla muestra una la distribucin de tiempos y el nmero de
iteraciones de cada fase (para las fases de Construccin y Transicin es slo una
aproximacin muy preliminar)
Fase
Nro. Iteraciones
Duracin
Fase de Inicio
Fase de Elaboracin
Fase de Construccin
Fase de Transicin
Los hitos que marcan el final de cada fase se describen en la siguiente tabla.
Descripcin
Hito
Fase de Inicio
En esta fase desarrollarn los requisitos del producto desde la perspectiva del usuario, los cuales sern
establecidos en el artefacto Visin. Los principales casos de uso sern identificados y se har un refinamiento
del Plan de Desarrollo del Proyecto. La aceptacin del cliente /usuario del artefacto Visin y el Plan de
Desarrollo marcan el final de esta fase.
69
Fase de Elaboracin
En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo las partes ms
relevantes y / o crticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos
que sern implementados en la primera versin de la fase de Construccin deben estar analizados y diseados
(en el Modelo de Anlisis / Diseo). La revisin y aceptacin del prototipo de la arquitectura del sistema marca
el final de esta fase. En nuestro caso particular, por no incluirse las fases siguientes, la revisin y entrega de
todos los artefactos hasta este punto de desarrollo tambin se incluye como hito. La primera iteracin tendr
como objetivo la identificacin y especificacin de los principales casos de uso, as como su realizacin
preliminar en el Modelo de Anlisis / Diseo, tambin permitir hacer una revisin general del estado de los
artefactos hasta este punto y ajustar si es necesario la planificacin para asegurar el cumplimiento de los
objetivos. Ambas iteraciones tendrn una duracin de una semana.
Fase de Construccin
Durante la fase de construccin se terminan de analizar y disear todos los casos de uso, refinando el Modelo
de Anlisis / Diseo. El producto se construye en base a 2 iteraciones, cada una produciendo una versin a la
cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboracin de material de
apoyo al usuario. El hito que marca el fin de esta fase es la versin de la versin 2.0, con la capacidad
operacional parcial del producto que se haya considerado como crtica, lista para ser entregada a los usuarios
para pruebas beta.
Fase de Transicin
En esta fase se prepararn dos versiones para distribucin, asegurando una implantacin y cambio del sistema
previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase
incluye, la entrega de toda la documentacin del proyecto con los manuales de instalacin y todo el material de
apoyo al usuario, la finalizacin del entrenamiento de los usuarios y el empaquetamiento del producto.
8.2.1.1.
Carta Gantt de la fase en forma de tabla
[Nombre de la fase]
No
[el
nmer
o de
tarea]
Actividad
Responsable
[nombre
de la
actividad]
[nombre de
la persona
que va
realizar esta
actividad]
1.1.2.
Fecha
Comienzo
[fecha]
Fecha
Trmino
[fecha]
Artefactos
de Entrada
[nombre
de los
artefactos
de
entrada
para la
actividad]
Artefactos
de Salida
[nombre
de los
artefactos
de salida
para la
actividad]
[nmero
de la
activida
d
anterior
]
[nmero
de la
actividad
siguiente
]
Objetivos de las iteraciones
[Liste los objetivos que debern cumplirse en cada iteracin.]
Fase
1.1.3.
Iteracin
Objetivo
Versiones
[Describa brevemente cada versin de software y si corresponde a un demo, beta,

etc.]
Fase
Iteracin
Release
70
[Si en fin de la fase o iteracin existe un release
de software describir release y su versin, o si un
release no existe poner N/A.]
1.1.4.
Agenda del Proyecto
[Prrafo obligatorio]
[Tabla o Diagrama que muestra las fechas objetivo de finalizacin paras las
iteraciones y fases, puntos de revisin, demos, y otras fases. Se puede reemplazar
con Gantt de Proyecto haciendo referencia.]
[Para pequeos proyectos se recomienda llenar la carta Gantt en forma de
tabla y no manejar Gantt separado.]
Como se ha comentado, el proceso iterativo e incremental de RUP est caracterizado

por la realizacin en paralelo de todas las disciplinas de desarrollo a lo largo del
proyecto, con lo cual la mayora de los artefactos son generados muy tempranamente
en el proyecto pero van desarrollndose en mayor o menor grado de acuerdo a la fase e
iteracin del proyecto. La siguiente figura ilustra este enfoque, en ella lo ensombrecido
marca el nfasis de cada disciplina (flujo de trabajo) en un momento determinado del
desarrollo.
Para el proyecto, segn lo establecido en la metodologa RUP, se ha establecido el

siguiente calendario. La fecha de aprobacin indica cundo el artefacto en cuestin
tiene un estado de completitud suficiente para someterse a revisin y aprobacin, pero
esto no quita la posibilidad de su posterior refinamiento y cambios.
Disciplinas / Artefactos generados o modificados durante
la Fase de Inicio
Modelado del Negocio
Comienzo
Aprobacin
71
Modelo de Casos de Uso del Negocio y Modelo de Objetos del
Negocio
Requisitos
Glosario
Visin
Modelo de Casos de Uso
siguiente fase
Especificacin de Casos de Uso
siguiente fase
Especificaciones Adicionales
siguiente fase
Anlisis/Diseo
Modelo de Anlisis/Diseo
siguiente fase
Modelo de Datos
siguiente fase
Implementacin
Prototipos de Interfaces de Usuario
siguiente fase
Modelo de Implementacin
siguiente fase
Pruebas
Casos de Pruebas Funcionales
siguiente fase
Despliegue
siguiente fase
Gestin de Cambios y Configuracin
Durante todo el proy ecto
Gestin del proyecto

Plan de Desarrollo del Software en su versin 1.0 y planes de las
Iteraciones
Ambiente
Durante todo el proyecto
Disciplinas / Artefactos
generados o modificados durante
Fase de Elaboracin
Modelado del Negocio
la
Modelo de Casos de Uso del Negocio y Modelo de Objetos

del Negocio
Comienzo
Aprobacin
aprobado
Requisitos
Glosario
aprobado
Visin
aprobado
Modelo de Casos de Uso

Especificacin de Casos de Uso
Especificaciones Adicionales
Anlisis / Diseo
Modelo de Anlisis / Diseo
Revisar en cada iteracin
Modelo de Datos
Implementacin
72
Modelo de Implementacin
Pruebas
Casos de Pruebas Funcionales
Despliegue
Gestin de Cambios y Configuracin
Durante todo el pr oyecto
Gestin del proyecto

Plan de Desarrollo del Software en su versin 2.0 y planes de
las Iteraciones
Ambiente

Durante todo el proyecto
8.2.1.2. Carta Gantt del proyecto en forma de tabla

No
[el
nmer
o de
tarea]
Fase
Actividad
[nomb
r e de
la fase
o
acrni
mo]
[nombre
de la
actividad]
Respon
sable
[nom
bre
de la
perso
na
Estado
[esta
do
de la
activi
dad]
Fecha
Comienzo
[fecha]
que
va
realiz
ar
esta
activi
dad]
[Acrnimos para las fases son:

C - Concepcin
E - Elaboracin
Co - Construccin
T - Transicin]
[Estados de una actividad son:
P - Pendiente
T - Terminada
<Nmero>% - % de trabajo finalizado]
1.1.5. Recursos del Proyecto
8.2.1.3.
Plan Del Staff
Fecha
Trmino
[fecha]
Artefactos de
Entrada
[nombre de
los
artefactos
de entrada
para la
actividad]
Artefactos de
Salida
[nombre
de
los
artefactos
de salida
para la
actividad]
A
[n
m
ero
de la
activ
i dad
ante
r ior]
D
[ nme
r o de
la
activida
d
siguient
e]
73
[Identifique aqu el tipo de staff requerido y la cantidad, incluyendo cualquier
habilidad especial, conocimiento o experiencia, calendarizado por fase del proyecto
o iteracin. Se puede reemplazar con una referencia a documento TEC Plan.]
8.2.1.4.
Plan de Adquisicin de recursos
[Prrafo NO obligatorio.
SUBCONTRATACIN]
OBLIGATORIO
EN
CASO
DE
QUE
EXISTA
[Describa como se conseguir el personal necesario para el proyecto.]

[Describa el plan de entrevistas a realizar entre estas alternativas o proponga la que
ms se acomoda al proyecto:
a) Entrevista Personal de conocimientos especficos
b) Entrevista Grupal para medir interaccin entre pares]
8.2.1.5.
Plan de capacitacin
[Prrafo NO obligatorio. Es parte de programa de capacitacin de la

empresa.]
[Liste cualquier tipo de capacitacin especial que requieran los miembros del
equipo del proyecto, con fechas objetivo para cuando se debe finalizar esta
capacitacin.]
1.1.6. Presupuesto
[Asignacin de Costos versus el Estructura de Desglose del Trabajo y el Plan de
Fase. Se puede reemplazar con una referencia a documento TEC Plan.]
8.3.
Plan de Iteracin
[Para pequeos proyectos este prrafo NO es obligatorio.]

[Cada plan de Iteracin debe ser incluido en esta seccin como referencia. Este
plan se puede representar con Gantt o un documento separado. Para proyectos
pequeos, de duracin menor a un mes y un equipo de menos de 3 personas, se
recomienda realizar el plan de iteraciones como parte integral del Plan de
Desarrollo del Software.]
8.4.
Monitorizacin y Control del Proyecto
1.1.7. Plan de Administracin de Requerimientos
[Debe Incluirse como una referencia.]
1.1.8. Agenda del Plan de Control
74
[Describa que aproximacin se tomara para monitorear el progreso versus la agenda
programada para tomar las acciones correctivas que sean necesarias.]
[Se recomienda definir monitorizaciones al menos una vez por fase con el Senior
Manager, y en perodos menores a una semana por parte del jefe de proyecto]
1.1.9. Plan de Control de Presupuesto

[Describa que aproximacin se tomar para monitorear los gastos vs. el
presupuesto del proyecto y como tomar acciones correctivas cuando sea requerido.
Para control de presupuesto del proyecto se necesita agregar TEC plan y el mismo
usar para ingresar valores en el columna Plan de Presupuesto.]
Fase
Iteracin
Fecha Comienzo
Plan
Real
Fecha Termino
Plan
Real
Presupuesto
Plan Real
Diff.
Suma
1.1.10. Plan de Control de Calidad
[Describa cuando se aplicara el control de calidad y los mtodos que se usaran
para los entregables del proyecto. Debe incluir adems como tomar acciones
correctivas cuando sea necesario. Se puede reemplazar con referencia a
documento Plan SQA.]
[Para pequeos proyectos el Plan de SQA se puede describir dentro del
Plan de Desarrollo del Software y no mantener documento independiente
para Plan de SQA. En este plan e el Plan de Test se pueden incluir como
puntos separados, o el Plan de Test se necesita desarrollar como
documento separado. Ver prrafo 6.2 del Plan de Desarrollo del Software,
Plan de Evaluacin.]
1.1.11. Plan de Reporte
[Describa los reportes internos o externos que deben ser generados, incluya tambin
la frecuencia y distribucin de cada publicacin.]
1.1.12. Plan de Medicin
75
[Para pequeos proyectos este prrafo debe contener una lista de
medidas del proyecto.]
8.5.
Plan de Administracin de Riesgos

[Debe Incluirse como una referencia a documento Lista de Riesgos.]
[Para pequeos proyectos la Lista de Riegos se puede incorporar
directamente en este plan, y no es necesario tener un documento
separado.]
8.6.
Plan de Clausura
[Describa las actividades para la finalizacin en orden del proyecto, incluyendo
reasignaciones del staff, archivo de materiales del proyecto, reportes y resmenes
post clausura, etc.]
9. Plan de Procesos Tcnicos

9.1.
Configuracin de Proyecto
[Debe incluirse como una referencia al documento Configuracin de Proceso.]
9.2.
Mtodos, Herramientas, y Tcnicas
[Liste los estndares tcnicos del proyecto documentados, como referencia, puede
incluir:
9.3.

Pautas del Modelado de Casos de Uso
Pautas de Diseo
Pautas de Pruebas
Gua de estilo del Manual]
Plan de Infraestructura
[Debe Incluirse como una referencia al documento Especificacin de Ambiente.
Tambin este prrafo se puede realizar con un diagrama de despliegue.]
9.4.
76
10.
Plan de Proceso de Soporte [Prrafo NO obligatorio.]

10.1. Plan de Comunicaciones
[Debe Incluirse como una referencia a documento Plan SCM.]
10.2. Plan de Evaluacin
[Parte del Plan de Desarrollo del Software, este describe los planes del
proyecto para la evaluacin del producto, y cubre las tcnicas, criterios, mtricas, y
procedimientos usados para la evaluacin ste debe incluir instrucciones paso a
paso, inspecciones, y revisiones. Note que ste es una adicin al plan de test que
no est incluida en el Plan de Pruebas del Proyecto.]
[Para pequeos proyectos el Plan de Pruebas se puede describir dentro del
Plan de Desarrollo del Software y no mantener un documento
independiente.]
10.3. Plan de Documentacin
[Este plan define todos los artefactos necesarios para el proyecto. Entregables (ver
punto 2.3) es solo una parte del proyecto. Debe Incluirse como una referencia o
se puede remplazar con una referencia a la Carta Gantt de Proyecto slo si la Gantt
contiene informaciones de documentos de entrada y salida.]
10.4. Plan de Aseguramiento de Calidad (SQA)
[Debe Incluirse como una referencia a documento Plan SQA.]
[Para pequeos proyectos el Plan de SQA se puede describir dentro del
Plan de Desarrollo del Software y no mantener documento independiente
para Plan de SQA. En este plan e el Plan de Test se pueden incluir como
puntos separados, o el Plan de Test se necesita desarrollar como
documento separado. Ver prrafo 6.2 del Plan de Desarrollo del Software,
Plan de Evaluacin.]
10.5. Plan de Resolucin de Problemas
[Debe Incluirse como una referencia a documento Plan SQA.]
[Para pequeos proyectos el Plan de SQA se puede describir dentro del Plan
de Desarrollo del Software y no en forma separada.]
10.6. Plan Administracin de Subcontratista
10.7. Plan de Mejora de los Procesos
77
11.
Planes Adicionales
[Planes adicionales que pueden ser requeridos por contrato o regularizaciones.]
12.
Anexos
[Material adicional para uso del lector de Plan de Desarrollo del Software.]
78
8.4.10 Plantilla Plan de Aseguramiento de la Calidad (SQA)

Plan de Aseguramiento de la Calidad (SQA)
Versin <1.1.0>
documento Plan de ASEGURAMIENTO DE LA CALIDAD. El texto entre
parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por
finalidad guiar al autor y debe ser borrado antes de la publicacin del documento.
El estilo Body Text se activa automticamente cuando se ingresan prrafos de
texto definitivo.]
79
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
80
ndice
1
Introduccin
1.1 Propsito
1.2 Distribucin
1.4 Referencias
ASEGURAMIENTO DE LA CALIDAD Tareas
2.1 Revisiones y Auditorias
2.1.1
2.1.2
Plan de revisin del Proceso

Plan de revisin de Productos de Trabajo
2.1.3
de acuerdo a Estndares definidos

Plan de auditorias y revisiones de
Administracin de Configuraciones de Software

2.2 Reporte de problemas y seguimiento
de las acciones correctivas.
2.2.1
Mecanismos de reportes
2.2.2
Seguimiento de acciones correctivas
2.3 Cambios en Procesos
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
3
2
2
3
2
2
3
2
2
3
2
2
3
2
2
3
2
2
3
2
2
3
2
2
81
2.3.1
Metas y Objetivos de los Cambios en el Proceso.
2.3.2
Descripcin de los Cambios
Evolucin del Plan
Anexos
4
2
2
4
2
2
4
2
2
4
2
2
4
82
Plan de Aseguramiento se La Calidad

1. Introduccin
12.1. Propsito
Definir, planificar y documentar las actividades de Aseguramiento de Calidad del
Proceso y Producto para el Proyecto.
12.2. Distribucin
[Describa las reas que se ven afectadas o interesadas por este documento.]
12.3. Definiciones, acrnimos y abreviaciones.
abreviaciones
requeridas
para interpretar
correctamente
el
Plan de ASEGURAMIENTO DE LA CALIDAD. Esta informacin puede entregarse
como una referencia al Glosario del proyecto.]
12.4. Referencias
[Esta subseccin provee una completa lista de todos los documentos referenciados
en cualquier punto del Plan de ASEGURAMIENTO DE LA CALIDAD. Identifique
cada documento por titulo, nmero de edicin (si es aplicable), fecha, y editorial.
Especifique las fuentes de donde pueden obtenerse estas referencias. Esta
informacin puede entregarse como una referencia a un apndice o a otro
documento.
Para el Plan del Proyecto, la lista de artefactos referenciados debe incluir:
Plan de Iteracin
Plan de Mediciones
Plan de Administracin de Riesgos
Caso de Desarrollo
Pautas para el Modelado de Negocio
Pautas de Diseo
Pautas de Pruebas
Gua de Estilo del Manual
Plan de Infraestructura
Plan de Administracin de la Configuracin
Plan de Documentacin
83
13.
Plan de Resolucin de Problemas
Plan de Administracin del Subcontratista Plan de Mejora de los Procesos]
ASEGURAMIENTO DE LA CALIDAD Tareas
13.1. Revisiones y Auditorias

1.1.13. Plan de revisin del Proceso
Esta revisin se realiza sobre los artefactos definidos en la Configuracin del Proceso.
En cuanto a modelos slo revisa su existencia de acuerdo a la fase en que se
encuentre.
Fase
Fecha
Artefactos a ser revisados (Si es una revisin general indicar Documentos de acuerdo a la
Configuracin de Proceso)
1.1.14. Plan de revisin de Productos de Trabajo de acuerdo a Estndares definidos
Esta revisin se realiza sobre modelos, fuentes y otros documentos asociados al producto
final, buscando la adherencia a los estndares definidos para stos.
Fase
Fecha
Productos de Software
Estndares
Utilizados
Recursos requeridos
[Indique si requiere
de asistencia de
recursos de otras
reas para realizar
esta revisin]
1.1.15. Plan de auditoras y revisiones de Administracin de Configuraciones de
Software
Fecha
Descripcin de la revisin a ser realizada
13.2. Reporte de problemas y seguimiento de las acciones correctivas.

1.1.16. Mecanismos de reportes
Se establece que el mecanismo de control es la Planilla Verificacin de Proceso
84
1.1.17. Seguimiento de acciones correctivas
[Indique aqu como se realizar el seguimiento de las acciones correctivas producto de

las revisiones practicadas y registradas en la Planilla de Verificacin de Proceso.]
13.3. Cambios en Procesos
1.1.18. Metas y Objetivos de los Cambios en el Proceso.
[Describa los motivos por los cuales no se sigue el proceso estndar que se describe.
1.1.19. Descripcin de los Cambios
[Describa cambios realizados al procedimiento que debern ser tomados en cuenta
por el ASEGURAMIENTO DE LA CALIDAD en sus revisiones]
14.
Evolucin del Plan
El Plan de ASEGURAMIENTO DE LA CALIDAD deber ser actualizado a lo menos al final

de cada Fase y a lo ms al final de cada iteracin
15.
Anexos
[Material adicional al Plan de ASEGURAMIENTO DE LA CALIDAD]
85
8.4.11 Plantilla Plan de Administracin de Configuracin

Plan de Administracin de Configuracin (CM)
<Versin 1.1.0>
documento Plan Administracin de Configuracin. El texto entre parntesis
Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
86
ndice
1
2.2.1
2.2.2
2.2.3
3
3.1.1
3.1.2
3.2.1
3.2.2
3.3.1
3.3.2
4
5
Introduccin
228
1.1 Propsito
1.2 mbito
1.4 Referencias
Administracin de la Configuracin
228
2.1 Organizacin, Responsabilidades, e Interfaces
2.2 Herramientas, Entorno, e Infraestructura
Herramientas
229
Ubicacin fsica del las mquinas servidores y clientes
229
Ubicacin fsica del los documentos y lneas base
229
Programa de Administracin de la Configuracin 230
3.1 Identificacin de la Configuracin
Mtodos de Identificacin
230
Lneas Base del Proyecto
230
3.2 Configuracin y Control de Cambios
Proceso de peticin de cambios y aprobacin
230
Comit de Control de Cambios (CCB)
230
3.3 Cuentas de Configuracin de Status
Almacenamiento de la media del Proyecto, y proceso de Versin 230
Reportes e intervenciones
231
Fases
231
Capacitacin y Recursos
231
228
228
228
228
228
228
228
230
230
230
87
Plan de Administracin de Configuracin

1. Introduccin
[La introduccin del Plan de Administracin de Configuracin provee un
resumen del documento completo. Este incluye el propsito, mbito, definiciones,
acrnimos, abreviaciones, referencias, y un resumen ejecutivo de este
documento.]
1.1.
Propsito
[Especifique el propsito de este Plan de Administracin de Configuracin.]

1.2.
mbito
[Describa brevemente el mbito de este Plan de Administracin de

Configuracin; que modelos se encuentran asociados, y cualquier elemento que
se vea influenciado o afectado por l.]
1.3.

abreviaciones requeridas para interpretar correctamente este Plan de
Administracin de Configuracin. Esta informacin puede entregarse como una
referencia al Glosario del proyecto.]
1.4.
Referencias
[Esta subseccin provee una lista completa de todos los documentos a los que se
haga una referencia en cualquier parte de este Plan de Administracin de
Configuracin. Identifique cada documento por ttulo, edicin (si es aplicable,
fecha y editorial. Especifique las fuentes de donde se pueden obtener estas
referencias. Esta informacin puede ser entregada como una referencia a un
apndice o a otro documento.]
1.5.
Resumen Ejecutivo
[Esta subseccin describe el resto del contenido del Plan de Administracin de

Configuracin, adems explica cmo est organizado este documento.]
2. Administracin de la Configuracin
2.1.
Organizacin, Responsabilidades, e Interfaces
[Describa quien ser responsable de llevar a cabo las diferentes actividades de

Administracin de Configuracin (CM). Se puede hacer referencia a documento
Asignacin de Roles, para determinar roles responsables para SCM. Interfaces: se
necesita describir en qu manera se va comunicar con otros grupos y afectados.
Por ejemplo: reuniones semanal, e-mail, video conferencia...]
2.2.
Herramientas, Entorno, e Infraestructura
[Describa el entorno computacional y las herramientas software que sern

utilizadas para cumplir las funciones de CM a travs del proyecto o del ciclo de vida
del producto.
Describa las herramientas y procedimientos requeridos para ser utilizados en los
tems de configuracin de control de versin generados a travs del proyecto o del
ciclo de vida del producto.
88
Los elementos involucrados en fijar el entorno de CM incluyen:
Tamao anticipado de la data del producto (aprox.)
Distribucin del equipo del producto
Ubicacin fsica de las maquinas servidoras y clientes
1.1.20. Herramientas
Actividad
Herramienta
[Nombre de la herramienta que se va usar

para la actividad. Por ejemplo: para
[Nombre de la actividad que se va actividad Administracin de Requerimientos,
cubrir
usando
herramienta.
Por herramienta puede ser: MS Excel,MS
ejemplo: Administracin de
OFFICE, Requisito Pro, DOORS,... . Se puede
Requerimientos]
agregar y direccin donde se puede
encontrarse
la
instalacin
de
la
herramienta.]
1.1.21. Ubicacin fsica del las mquinas servidores y clientes
IP
Nombre
[Por ejemplo:
1P:192.168.0.33]
[Por ejemplo
SERVER]
Responsable
SC
M
[Nombre de administrador de la
maquina o nombre de usuario si
maquina es estacin del trabajo]
1.1.22. Ubicacin fsica del los documentos y lneas base
Direccin
Tipo de documento
89
[La direccin donde se va guardar las
lneas base. Se recomienda usar
nombres
relativos
\\<nombre
de
servidor>\<direccin> Por ejemplo:
para lnea base de requerimientos:
\\SCM SERVER\Reqs\]
[Nombre del tipo de documento que se va

guardar dentro de la lnea base. Por
ejemplo:
para
la
Administracin
de
Requerimientos, puede ser: .DOC, .TXT y
como base de datos PROYECT1.mdf ]
3. Programa de Administracin de la Configuracin

3.1.
Identificacin de la Configuracin
1.1.23. Mtodos de Identificacin
[Describa como sern nombrados, marcados y numerados los artefactos del

proyecto o del producto. El esquema de identificacin necesita cubrir el hardware,
software de sistema, productos comerciales, y todos los artefactos desarrollados
para la aplicacin, listados en la estructura de directorios del producto; por
ejemplo, planes, modelos, componentes, software de test, resultados y data,
ejecutables, etc.]
1.1.24. Lneas Base del Proyecto
[Las Lneas Base proveen un estndar oficial en el cual se basarn los trabajos
subsecuentes y a los cuales solo se le pueden aplicar cambios autorizados.
Describa en qu puntos durante el proyecto o el ciclo de vida del producto se han
establecido Lneas Base. La mayora de los Lneas Base comunes deberan estar al
final de cada fase de Concepcin, Elaboracin, Construccin, y Transicin. Los
Lneas Base tambin pueden ser generados al final de las iteraciones con las
diferentes fases o incluso ms frecuentemente.
Describa quien autoriza unas lneas base.
Se puede hacer referencia a el documento "Poltica, estndar y procedimiento de
CM" general, si proyecto no tiene algunas cosas especificas y si este documento
existe dentro de la organizacin]
3.2.
Configuracin y Control de Cambios

1.1.25. Proceso de peticin de cambios y aprobacin
[Describa los procesos por los cuales los problemas y cambios se han enviado,
revisado y dispuesto.]
1.1.26. Comit de Control de Cambios (CCB)
[Describa los miembros y procedimientos para el proceso de peticin de cambios y
aprobaciones que deben ser seguidos por el CCB. Se puede hacer referencia a el
documento "Poltica, estndar y procedimiento de CM" general, si proyecto no tiene
algunas cosas especificas y si este documento existe dentro de la organizacin.]
90
3.3.
Cuentas de Configuracin de Status

1.1.27. Almacenamiento de la media del Proyecto, y proceso de Versin
[Describa las polticas de retencin, de respaldos, desastres y planes de
recuperacin. Tambin describa como se almacena la media online, offline, tipo
de media, y el formato. Si existe un plan de respaldo general se puede hacer
referencia a documento donde este plan esta escrito.
Los procesos de versin deben describir que incluye la versin, a quien va dirigido,
descripcin de cualquier problema conocido y cualquier instruccin de instalacin.]
1.1.28. Reportes e intervenciones
[Describa el contenido, formato,
intervenciones requeridas.
propsito
de
los
reportes
requeridos
Los reporte son usados para evaluar la calidad del producto en cualquier
momento dado del proyecto o del ciclo de vida de producto. El reporte de los
defectos basados en las peticiones de cambios pueden proveer indicadores de
calidad muy tiles y, de este modo, alertar a administradores y desarrolladores
acerca de reas particulares criticas de desarrollo. Los defectos son clasificados
segn su importancia (alto, medio, y bajo) y deben ser reportados segn la
siguiente base:
Antigedad (Reportes basados en el tiempo): Hace cuanto se han

establecido estos defectos? Cul es el tiempo de retraso desde que los
defectos fueron encontrados hasta que fueron reparados?
Distribucin (Reportes basados en nmeros):Cuantos defectos existen en

cada categora, ordenados por autor, prioridad, y estado de reparacin?
Tendencias (Reportes basados en Tiempo y Nmero): Cul es el nmero

de defectos acumulativos encontrados y cuales se han solucionado despus
del tiempo? Cul es el ratio de defectos descubiertos y reparados? Cul es
el Boquete de Calidad en trminos de defectos reportados y reparados?
Cul es el tiempo de resolucin promedio de un defecto?
4. Fases
[Identifique las fases internas y del cliente relativas al esfuerzo de CM del producto
o del proyecto. Esta seccin debe incluir detalles de actualizaciones del Plan de CM.
Se puede hacer referencia a el documento "Configuracin del Proceso", donde se
puede ver plan de actualizaciones del plan de SCM.]
5. Capacitacin y Recursos
[Describa las herramientas de software, personal y capacitacin necesaria para
implementar las actividades de CM especificadas. Si personal tiene conocimiento el
prrafo se puede omitir.]
91
8.4.12 Plantilla Plan de Pruebas

Plan de Pruebas
Versin <1.1.0>
[Nota: Esta Plantilla tiene por finalidad servir de Base para la confeccin del documento
de Plan de Pruebas. El texto entre parntesis cuadrados y desplegado en azul itlico
publicacin del documento. El estilo Body Text se activa automticamente cuando se
ingresan prrafos de texto definitivo.]
92
Fecha
<aaaa-mm-dd>
Versin
<1.1.0>
Descripcin
Documento inicial
Autor
<Nombre>
93
ndice
1
1.2.1
1.2.2
1.2.3
1.2.4
Introduccin
236
1.1 Propsito
1.2 mbito
Pruebas Unitario
236
Pruebas Funcionales
236
Riesgos
237
Identificacin del Proyecto
238
1.3 Dirigido a
1.4 Breve Descripcin
1.5 Terminologa del Documento y Acrnimos
1.6 Referencias
Requerimientos para el Prueba 240
2.1 Casos de Uso
240 2.1.1 Vista Global
240
2.1.2
3
3.1.1
3.1.2
3.1.3
3.1.4
4
4.2.1
236
236
238
239
239
239
Caso de uso 1
240 2.1.3
Caso de uso 2
240
2.1.4 Caso de uso 3
240
2.2
240
2.2.1 Componentes Comunes
240
2.2.2 Componente 1
240
2.2.3 Componente 2
240
2.3
Requerimientos No - Funcionales (Matriz con Input/Output)
240
2.3.1 Componente 1
240
2.3.2 Componente 2
240
Estrategia del Pruebas
241
3.1 Tipos de Pruebas
241
Integridad de la Base de Datos y de los Datos
241
Pruebas Funcional
242
Pruebas de Ejecucin
243
Pruebas de Seguridad y de Acceso a Datos
243
Recursos
244
4.1 Profesionales
244
4.2 Ambiente de Pruebas
245
Preparacin del Ambiente de Pruebas
245
94
4.2.2
Diseo del Ambiente de Pruebas

Diseo Ambiente de Pruebas
245 4.2.3
247
4.2.4
Integracin del Ambiente de Pruebas y Configuracin

247 4.2.5
Definicin del Banco de Datos de Prueba
248
4.2.6 Generacin de Datos
248 5 Hitos del Proyecto de Pruebas
250
Entregables
6.1
6.1.1
7
7.1
7.2
7.3
8
9
9.1
9.2
9.3
9.4
10
10.1
10.2
11
12
13
13.1
13.2
13.3
13.4
13.5
13.6
252
Modelo del Prueba
Criterio de entrada para el modelo de Prueba

Criterio de salida para el modelo de Prueba
6.1.3 Criterio de suspensin y reinicio
6.2
Resultados del Prueba
6.3
Reporte de Defectos
Anexos
253
A: Tareas del Proyecto
253
B: Pruebas de Ejecucin
254
C: Pruebas de Seguridad y de Control de Acceso
255
Flujo de trabajo del Pruebas
257
Necesidades del entorno
258
Hardware base del sistema
258
Elementos Software base en el entorno de Prueba
258
Herramientas de Productividad y Ayuda
259
Configuraciones de Entorno de Prueba
259
Responsabilidades, Personal, y Capacitacin Necesaria 260
Personas y Roles
260
Personal y entrenamiento necesario
262
Fases del proceso de Iteracin 263
Riesgos, Dependencias, Suposiciones y Limitaciones 264
Procesos administrativos y procedimientos 265
Medicin y determinacin del grado de la prueba
265
Reporte de la cobertura del Prueba
265
Reporte de problemas, extensin, y edicin de la resolucin. 265
Manejo de los ciclos de Pruebas
265
Estrategias de Trazabilidad
265
Aprobacin y Trmino
265
252
252 6.1.2
252
252
252
252
95
Plan de Pruebas
1. Introduccin
Propsito
1.1.
El propsito de este Plan de Pruebas es recopilar toda la informacin necesaria

para planificar y controlar el esfuerzo de Pruebas de esta iteracin. Este
documento describe una aproximacin al Pruebas del software y es el primer
plan generado y utilizado por los administradores para dirigir el esfuerzo de
Pruebas.
Este Plan de Pruebas, para el proyecto <Nombre del Proyecto>, contempla los
siguientes objetivos:
[Identificar la informacin existente del proyecto y los componentes de

software que deberan ser Probados a partir de los Casos de Uso Listar los
requerimientos recomendados para el Prueba. (Alto Nivel) Recomendar y
describir la estrategia de Pruebas que ser utilizada.
1.2.
Identificar los recursos requeridos y proveer una estimacin del esfuerzo que
significar el Pruebas.
Listar los elementos entregables del proyecto de Prueba.]

mbito
[Proporciona una descripcin por escrito de a quin va dirigido este Modelo de

Prueba.
Nota: El contenido y el estilo de este documento puede alterarse en relacin de
a quin va dirigido]
1.1.29. Pruebas Unitario
[El Pruebas unitario de componentes corresponder a las pruebas unitarias que
realizar el equipo de desarrollo.]
1.1.30. Pruebas Funcionales
El Pruebas sealado en este plan ser de tipo Caja Negra. Este tipo de Pruebas
pretende verificar el comportamiento de la unidad, observando cmo est
implementado el comportamiento de dicha unidad.
Con esta finalidad se utilizarn datos de entradas (input), se ejecutar el proceso y
se obtendr un resultado esperado (output).
Los datos de entrada sern los utilizados por las transacciones involucradas.
Cada argumento de entrada puede seleccionar uno de los siguientes datos de
Prueba, dependiendo este del resultado que se desea obtener (esperado),
verificando as el comportamiento de la componente a Probar usando distintos
valores de entrada:
Valores normales para cada transaccin
96
Valores lmites para cada transaccin
Valores de borde
Valores ilegales
1.1.31. Riesgos
Durante el desarrollo del Plan de Pruebas se pueden producir impactos sobre
algunas fases (Diseo, Desarrollo o Implementacin) del Pruebas.
Algunos riesgos a considerar:
1. Documentacin de especificacin errnea o incompleta.

2. Lista de requerimientos inconsistente con los Casos de Uso.
3. Componentes a Probar y componentes comunes correspondan a distintas versiones.
4. Hardware y Software no funcionen correctamente.
5. Herramientas de Pruebas automatizado estn mal configuradas.
6. Flujo de trabajo del seguimiento de defectos no sean llevados en forma adecuada, para plantear
soluciones rpidas y mejoradas.
Los riesgos sern identificados de acuerdo a un concepto de Bajo, Medio o Alto,
dependiendo de la importancia del Caso de Uso para el cual se est
desarrollando el Pruebas.
As mismo, para el proyecto <Nombre del Proyecto>se han identificado una serie
de riesgos (calificados entre 1 y 10 dependiendo de su gravedad) los que estn
detallados en el documento <Lista de Riesgos.doc> con sus alcances y acciones,
en el presente plan, los enunciamos para sugerir algunas acciones.
1.2.1.1. Matrices de Riesgos

1.2.1.1.1.
Proyecto Pruebas
N
Riesgo
1
2
3
4
5
6
Descripcin
Gravedad
Accin
97
1.2.1.1.2.
N
Riesgo
Descripcin
Gravedad
Descripcin
Gravedad
1
N
Riesgo
2
3
4
5
6
1.1.32. Identificacin del Proyecto

La siguiente tabla permite identificar la documentacin disponible para desarrollar el
Plan de Pruebas.
Documento
(versin / fecha)
Creado o
Disponible
Recibido o
Revisado
Documento de Visin
Si No
Si No
Especificacin de
Requerimientos
Si No
Si No
Especificaciones Funcionales
Si No
Si No
Informe de Casos de Uso
Si No
Si No
Plan del Proyecto
Si No
Si No
Especificacin de Diseo
Si No
Si No
Prototipo
Si No
Si No
Manuales de Usuario
Si No
Si No
Modelo de Negocio y Flujo
Si No
Si No
Modelo de Datos y Flujo
Si No
Si No
Funciones del Negocio y Roles
Si No
Si No
Proyecto / Listado Riesgos
Si No
Si No
1.3.
Dirigido a
Autor u
Origen
Notas
98
[Provee una descripcin acerca de para quien se est escribiendo este documento.
Esto ayuda a los lectores del documento a identificar si es un documento creado
para su uso, y ayuda a prevenir que este documento sea usado inapropiadamente.
Nota: El contenido y el estilo del documento pueden ser modificados en relacin
de a quin van dirigidos. Esta seccin debe tener una extensin entre tres y cinco
prrafos de longitud.]
1.4.
Breve Descripcin
[Breve descripcin del proyecto con: descripcin corta de arquitectura, lgica de

sistema, roles y personas responsables para Prueba, y los tipos de Pruebas como
funcionalidad, usabilidad, seguridad, Ejecucin y soporte que sern direccionados
por este Modelo de Pruebas. Tambin es importante entregar una indicacin
general de reas significantes que sern excluidas de este punto, especialmente
aquellas en las cuales se podra asumir, de forma razonable, que estn incluidas.]
1.5.
Terminologa del Documento y Acrnimos
[Esta seccin provee las definiciones de los trminos, acrnimos, y abreviaciones

requeridas para interpretar correctamente este documento. Esta informacin
puede contener referencias al Glosario del proyecto.]
1.6.
Referencias
[Este punto deber:

Proveer una completa lista de todos los documentos referenciados en cualquier
lugar del documento Plan de Pruebas.
Identificar cada documento por un ttulo, nmero de reporte (si aplica), fecha y
organizacin que la pblica.
Especificar las fuentes desde las cuales las referencias pueden ser obtenidas.
Esta informacin puede estar referida a un apndice u otro documento.]
2. Requerimientos para el Prueba

La siguiente lista identifica los tems (Casos de Uso, Requerimientos Funcionales y
Requerimientos no Funcionales) que se han identificado como requerimientos a ser
Probados.
2.1.
Casos de Uso
1.1.33. Vista Global
[Agregar o eliminar segn corresponda]
1.1.34. Caso de uso 1
99
2.2.
1.1.37. Componentes Comunes
[Agregar o eliminar segn corresponda]
1.1.38. Componente 1
2.3.
Requerimientos No - Funcionales (Matriz con Input/Output)

Nro.
Caso de Uso
Input
Output
Input
Output
1
Nro.
Caso de Uso
3. Estrategia del Pruebas

[A continuacin se describe la estrategia de Pruebas a ser utilizada en <nombre del
proyecto>, en otras palabras, se indica cmo se realizar el Pruebas de los
requerimientos analizados en la seccin precedente (Requerimientos para el
Pruebas) la cual identifica qu se va a Probar.
Se proponen varios tipos de Pruebas, en funcin de los riesgos identificados para el
proyecto; sin embargo es slo el Pruebas Funcional el que ser desarrollado y
ejecutado, los otros tipos de Pruebas se proponen como complementarios y estn
sujetos a su factibilidad de ser ejecutados por <nombre de usuario>.
3.1.
Tipos de Pruebas
1.1.42. Integridad de la Base de Datos y de los Datos
[De acuerdo al Riesgo N1, identificado en el punto 1.2.3.1.2 de este
documentos, y definido en el documento Lista de riesgos.doc, se sugiere realizar
esta actividad, considerando el modelo que propone el RUP.
El Administrador de Bases de Datos de <nombre del cliente>, deber asegurar
que las bases de datos para el proyecto de Pruebas, sean un reflejo de las de
produccin.]
El Administrador de Bases de Datos deber indicar las herramientas y tcnicas para
ejecutar esta prueba.
100
Objetivo del
Prueba:
Asegurar que los mtodos de Acceso a la Base de Datos SQL y

los procesos asociados, funcionan apropiadamente y sin riesgo
de datos corruptos.
Tcnica a Utilizar:
Realizar la llamada a una Base de Datos y ejecutar algn

proceso con datos vlidos e invlidos.
Inspeccionar la Base de Datos para verificar que los procesos
se han realizado correctamente.
Criterio de
Verificacin:
Todos los mtodos de acceso a la Base de Datos y sus procesos

deben estar sin datos corruptos.
Consideraciones
Especiales:
La prueba puede requerir que el Administrador de Bases de

Datos disee un ambiente o drivers para acceder a los datos
directamente.
Deben invocarse los procesos manualmente.
Se debe utilizar una reducida cantidad de registros para facilitar
la inspeccin de los datos e identificar eventos errneos.
Observaciones:
1.1.43. Pruebas Funcional

El Pruebas funcional se realizar sobre los requerimientos funcionales antes
descritos y sus Casos de Uso. Este Prueba tiene por finalidad verificar la
funcionalidad de la aplicacin a partir de datos vlidamente seleccionados sobre
las transacciones del sistema.
Este tipo de comprobacin se basa en las tcnicas de caja negra, que permiten
verifica la aplicacin (y sus procesos interiores) actuando recprocamente con la
aplicacin va el GUI y analizando el rendimiento (resultados).
Objetivo del
Prueba:
Asegurar la funcionalidad del conjunto de casos, incluyendo la

navegacin en la aplicacin, el ingreso de datos, el proceso y la
recuperacin (resultados).
Que la navegacin a travs de los casos de prueba refleje
apropiadamente las reglas del negocio y los requerimientos,
incluyendo ventana a ventana, campo a campo y usando los
mtodos de acceso correctamente (tecla tab, movimiento del
mouse, etc.)
Que los objetos de las ventanas y sus caractersticas, tales
como mens, tamao, posicin, estados y el foco, estn de
acuerdo a los estndares.
101
Tcnica a Utilizar:
Ejecutar cada Caso de Uso, su flujo y funcionalidad usando

tanto datos vlidos como invlidos para verificar lo siguiente:
Que los resultados esperados ocurren cuando los datos vlidos
son utilizados.
Que el mensaje de error es el apropiados cuando se utilizan
datos invlidos
Que cada Regla de Negocio se utiliza apropiadamente.
Crear y modificar los procedimientos de Prueba para cada
ventana, para verificar los estados de los objetos y de la
aplicacin.
Criterio de
Verificacin:
Todos los defectos identificados han sido asignados.
Consideraciones
Especiales:
Todas la pruebas planificadas se ejecutaron correctamente
Cada ventana debe ser verificada para mantener la

consistencia con la versin maestra y verificar que est
dentro de los estndares aceptables.
[Puede que no todas las propiedades sean verificadas,

considerar las ms importantes y/o definidas y no todos los
objetos de terceras partes puedan ser verificados.]
Observaciones:
1.1.44. Pruebas de Ejecucin
[Este Pruebas no est considerado realizar en esta primera etapa, de tal forma
que slo se enmarca en una recomendacin que <nombre de usuario> deber
evaluar y decidir.]
Un detalle de este tipo de Pruebas, adjunta en el Anexo B de este documento.
1.1.45. Pruebas de Seguridad y de Acceso a Datos
[Este Pruebas no est considerado realizar en esta primera etapa, de tal forma
que slo se enmarca en una recomendacin que <nombre de usuario> deber
evaluar y decidir.]
Este tipo de Pruebas se enmarca dentro de la metodologa del RUP.
Un detalle de este tipo de Pruebas, adjunta en el Anexo B de este documento.
102
4. Recursos
Esta seccin presenta una recomendacin de recursos para el esfuerzo de Pruebas
del sistema <Nombre del Proyecto>, sus principales responsabilidades y sus
conocimientos y habilidades.
4.1.
Profesionales
La siguiente tabla muestra el equipo para el Proyecto de Pruebas:

Recursos Humanos
Trabajador
Recursos mnimos
recomendados
(Nmero
trabajadores
FullTime)
Diseador del
Prueba
Responsabilidades especficas / Comentarios
de
Identificar, priorizar e implementar los casos del

Prueba
Responsabilidades
Genera el plan de Prueba
Genera el Modelo de Prueba
Evaluar de forma efectiva el esfuerzo de Pruebas
Probador
Ejecutar los Prueba Responsabilidades:

Ejecuta los Prueba
Guarda estado de los resultados
Recuperacin de errores
Peticin de cambio de la documentacin
Administrador de
sistema del Prueba
Asegurar que el entorno de Prueba y valores

estn controlados y mantenidos.
Responsabilidades
Administrar el sistema de control del Prueba
Administrador de la
Base de Datos /
Encargado de la
Base de Datos
Instalar / manejar el acceso de los trabajadores al

sistema de Pruebas
Asegurar que el entorno de datos del Prueba
(Base de Datos) y los valores que contiene estn
controlados y mantenidos.
Responsabilidades:
Administra los datos del Prueba (Base de
Datos)
Recursos Humanos
103
Trabajador
Recursos mnimos
recomendados
(Nmero
trabajadores
FullTime)
Diseador
Responsabilidades especficas / Comentarios
de
Identificar y definir las operaciones, atributos y

asociaciones de las clases del Prueba.
Responsabilidades:
Identifica y define el(las) clase(s) de Prueba
Identifica y define los paquetes del Prueba
Implementador
Implementar y unir las clases de Prueba y los

paquetes.
Responsabilidades:
Crea las clases de Prueba y los paquetes
implementados en el Modelo de Prueba.
4.2.
Ambiente de Pruebas
Para el Ambiente de Pruebas se describen los recursos y las actividades necesarias

para la configuracin del Ambiente de Pruebas. Se identifican los requerimientos
de hardware, software y de comunicacin necesarios para crear y dar soporte
permanente al Ambiente de Pruebas.
Las actividades de instalacin y
configuracin para el conjunto de los componentes del Ambiente de Pruebas,
debern ser planificadas y calendarizadas. Se requiere que este ambiente sea
seguro, estable y dedicado exclusivamente para las pruebas del sistema.
1.1.46. Preparacin del Ambiente de Pruebas
Las pruebas unitarias y de regresin debern ser ejecutadas dentro del Ambiente
de Desarrollo, las pruebas de aceptacin del usuario y del sistema se ejecutarn en
este Ambiente de Pruebas. Este Ambiente deber representar una configuracin
idntica al Ambiente de Produccin o al menos, una versin en menor escala del
Ambiente Operacional (Produccin). Esto se requiere debido a que se debe replicar
el rendimiento de la lnea base y las medidas de mejoramiento relacionadas.
1.1.47. Diseo del Ambiente de Pruebas

La siguiente tabla identifica los recursos de sistema identificados para el proyecto de
Pruebas.
ITEM
DESCRIPCIN
OBSERVACIONES
DESCRIPCIN
OBSERVACIONES
HARDWARE
Estacin de Pruebas (Cliente)
Procesador
ITEM
104
Memoria RAM
Espacio en Disco
Tipo Monitor y Resolucin
Unidad de Disquete
Tarjeta de red
Mdem
Mouse
Tipo Enlace
Servidores
(Pruebas)
Procesador
Memoria RAM
Espacio en Disco
Tipo Monitor y Resolucin
Unidad de Disquete
Tarjeta de red
Mdem
Mouse
Tipo Enlace
Tipo Enlace
Clase de Enlace
Tipo Enlace
Impresoras
Marca y Modelo
Tipo
Resolucin
Ejecucin
Dedicacin
RED
Topologa
Medio
Velocidad
Protocolo
Mdems
Conexin Internet
ITEM
DESCRIPCIN
OBSERVACIONES
105
Sistema
de
Respaldo
Restauracin
Unidad (Modelo y Marca)
Capacidad
Ubicacin
SOFTWARE
Estacin de Pruebas (Cliente)
Sistema Operativo
Herramienta de Pruebas
Herramienta de Modelamiento
BDMA
Browser
Software de Escritorio
Repositorios
Servidor
Dominio / Cuenta
Seguridad
1.1.48. Diseo Ambiente de Pruebas

El siguiente diagrama muestra la arquitectura del Ambiente de Pruebas requerido para
realizar el Pruebas de <nombre del proyecto>.
<<incluir_diagrama_de_la_arquitectura_del_ambiente_de_prueba>>
1.1.49. Integracin del Ambiente de Pruebas y Configuracin
Para esta actividad se requerir la participacin de profesionales de <nombre de
cliente> en cuanto a instalacin, configuracin y puesta en marcha del Ambiente de
Pruebas. Principalmente se requiere del responsable de la Red y Administracin de
Bases de Datos, de tal forma de obtener un ambiente lo ms consistente y smil al
de produccin, con las bases de datos creadas y el software configurado para
asegurar que el sistema funciona de acuerdo a diseo.
Las actividades generales a ser consideradas son:
106
Actividad
Responsable
Fecha
Estimada
Fecha
Real
Observaciones
1.1.50. Definicin del Banco de Datos de Prueba

Para el tipo de Pruebas que se realizar, se debe asegurar que los
requerimientos sern adecuadamente probados y verificados. En este sentido,
se debern tomar las siguientes consideraciones al momento de generar el
Banco de Datos.
4.2.1.1.1. Profundidad
4.2.1.1.2. Variacin
4.2.1.1.3. Alcances
4.2.1.1.4. Ejecucin
4.2.1.1.5. Condiciones
En esta consideracin, se requiere conocer la documentacin del sistema, de tal
forma de obtener el mximo de informacin para la creacin de los datos.
La documentacin que se requiere es:
Documentacin conceptual del sistema

Definicin de Requerimientos
Especificacin de software / hardware
Diagrama entidad - relacin
Diagrama de Casos de Uso
Diagrama de Estado
Diccionario de datos
1.1.51. Generacin de Datos
La generacin de los datos para las pruebas consideran los siguientes aspectos,
que se deben definir de acuerdo a los requerimientos y posibilidades de su
obtencin. Los aspectos que se describen a continuacin, pretenden que tanto
los datos sean los correctos, como la cobertura de los mismos cubra todos los
riesgos y situaciones que se presenten.
107
4.2.1.2. Muestra de Produccin
Para que la muestra de datos sea realmente representativa, se deber elegir una
fecha adecuada y que posibilite la mayor cobertura de datos. En este sentido se ha
elegido como fecha el <<indicar_fecha_para_obtencin_de_datos>>
Para la obtencin de datos por esta va, se debern definir las restricciones (por
motivos de confidencialidad) y generar algn utilitario para filtrar los datos de tal
forma de obtener la mayor variabilidad de datos posible.
Adems se deben considerar los siguientes aspectos para asegurar que estos datos
funcionen correctamente en el Ambiente de Pruebas:
Archivos Maestros al Inicio del Da

Tablas de Parmetros
Interfaces de Entrada
Archivos de Movimientos del da o del periodo
Todos estos aspectos se deben considerar en los distintos ambientes donde los datos
van a ser utilizados en las transacciones o actualizaciones.
4.2.1.3.
Datos Complementarios
En este aspecto se deben verificar si es necesario generar datos complementarios

para cubrir todas las posibles variaciones que se puedan dar. La generacin de los
datos complementarios depender de los datos obtenidos de produccin y de la
informacin que est en la documentacin solicitada.
Uno de los aspectos a considerar para generar datos complementarios, es el
aspecto de fecha, para lo cual se deber considerar el envejecimiento de los datos
a objeto de mantener la consistencia de las pruebas e independencia de la fecha de
proceso.
4.2.1.4.
Envejecimiento de Datos de Prueba
En este aspecto se deben considerar los envejecimientos de los datos de prueba, de

tal forma que cumplan con la validez de las pruebas. Los datos a envejecer sern
tanto los obtenidos desde produccin como los complementarios generados para
cubrir el total de las condiciones y variaciones.
Esta consideracin es eventual y deber considerarse slo si es necesario. Tienen
especial relevancia ciertas fechas en que, para <nombre de usuario>, se realizan
procesos claves, las fechas en cuestin con sus implicancias se detallan a
continuacin:
Fecha
Consideraciones
Observaciones
108
Procesos Batch
4.2.1.5.
En este aspecto se consideran algunos procesos batch que son necesarios para la
actualizacin de datos en <Nombre del proyecto>
Los procesos batch identificados son los siguientes:
Archivo
Job
maestro
Archivo de
Movimiento
Tablas
Interfaces
Informes
5. Hitos del Proyecto de Pruebas

[A continuacin se enumeran las actividades a realizar en el Proyecto de Pruebas.]
Tareas
Plan Prueba
Identificar el Proyecto
Definir Estrategia
Estimar Actividades
Identificar Recursos
Documentar Plan de
Pruebas
Agenda de Actividades
Revisin del Plan de
Pruebas
Diseo del Prueba
Analizar Requerimientos
Especificar Procedimientos
de Prueba
Especificar Prueba Case
Responsable
Esfue
r zo
Fecha
Inicio
Fecha
Trmino
109
Revisar Cobertura de los
requerimientos de Prueba
Tareas
Responsable
Esfue
r zo
Fecha
Inicio
Fecha
Trmino
Implementacin de Prueba
Establecer Ambiente de
Implementacin
Desarrollar los
Procedimientos de Prueba
Probar y debugear los
Modificar los
Reprobar y debugear los
Ejecucin del Prueba
Ejecutar Prueba
Verificar Resultados
Esperados
Investigar Resultados
Inesperados
Log de Defectos
Re-Ejecutar Prueba
Evaluacin del Prueba
Revisar el Log del Prueba
Evaluar cobertura de los
Casos de Prueba
Evaluar Defectos
Reportar Defectos
6. Entregables
[En esta seccin se deben listar los documentos, herramientas, y reportes que sern
creados, autor, destinatario y fecha de entrega]
6.1.
Modelo del Prueba
[Esta seccin identifica los reportes del Modelo de Prueba que sern creados y
distribuidos. Estos artefactos pertenecientes al modelo de Prueba deben ser
creados y referenciados en la herramienta ASQ]
1.1.52. Criterio de entrada para el modelo de Prueba
[Especifica el criterio que se usara para determinar si la ejecucin del Modelo de
110
Prueba puede comenzar]
1.1.53. Criterio de salida para el modelo de Prueba
[Especifica el criterio que se usara para determinar si la ejecucin del Modelo de
Prueba se ha completado o si contina en ejecucin sin entregar resultados]
1.1.54. Criterio de suspensin y reinicio
[Especifica el criterio que se usara para determinar si el Pruebas debe ser
suspendido prematuramente o finalizado antes que el modelo de Prueba haya sido
ejecutado completamente, y bajo qu criterio puede ser reasumido el Pruebas ]
Resultados del Prueba
6.2.
[Describe los mtodos y las herramientas usadas para registrar y reportar en el

Prueba los resultados y el status del Prueba]
Reporte de Defectos
6.3.
[Esta seccin identifica el mtodo y la(s) herramienta(s) usadas para registrar,

ajustar y reportar los incidentes del Prueba y sus status]
7. Anexos
A: Tareas del Proyecto
7.1.
La siguiente lista muestra las tareas relacionadas con el Prueba:
No Aplica
Plan de Pruebas (Preliminar)

Identificar Requerimientos para el Pruebas
Medir los Riesgos
Desarrollar la Estrategia del Pruebas
Identificar los Recursos del Pruebas
Creacin del Inventario
Generar Plan de Pruebas
Disear el Pruebas
Anlisis de Carga de Trabajo
Identificar y Describir los Prueba Case
Identificar y Estructurar los Procedimientos de Prueba
Revisar y Accesar la Cobertura del Prueba
Implementar el Prueba
Grabar o Programar los Script del Prueba
Identificar las funcionalidades de Prueba especficos en el modelo de
diseo e implementacin.
Establecer el Conjunto de Datos Externos
111
Ejecutar el Prueba
Ejecutar los Procedimientos de Prueba
Evaluar la Ejecucin del Prueba
Recuperacin de una Prueba interrumpida.
Verificar los Resultados
Investigar los Resultados Inesperados
Log de Defectos
Evaluar el Prueba
Evaluar la cobertura de los Prueba Case
No Aplica
Evaluar la Cobertura del Cdigo

Analizar Defectos
Determinar si el Criterio de Carga y el Criterio de aceptacin fueron
archivados
7.2.
B: Pruebas de Ejecucin
[De acuerdo al Riesgo N2, identificado en el punto 1.2.3.1.2 de este documento

y definido en el documento Lista de riesgos.doc, se sugiere realizar este tipo de
Pruebas.
Las Pruebas de Ejecucin es una prueba para verificar los tiempos de respuestas,
la tasa de transacciones y otros tiempos requeridos de desempeo. La finalidad
de las Pruebas de Ejecucin es verificar que los tiempos de respuestas requeridos
son los ptimos. Las Pruebas de Ejecucin verifican que el desempeo del
sistema y la configuracin del hardware son adecuados frente a una serie de
transacciones bajo ciertas condiciones de carga.]
Para esto, se definen las transacciones de acuerdo a los Casos de Uso especficos
que se espera que un actor del sistema realice usando un conjunto de datos para
agregar o modificar transacciones.
Verificar la conducta de Ejecucin para las transacciones

seleccionadas o funcionalidades bajo las siguientes condiciones:
Objetivo del
Pruebas:
- Una carga de trabajo normal

- Una sobrecarga de trabajo
Tcnica:
Usar los procedimientos de pruebas desarrollados para el

Pruebas Funcional.
Modificar los archivos de datos para aumentar las transacciones
o los script de robotizacin para incrementar el nmero de
iteraciones de cada transaccin.
Los script debern correr en una mquina (la mejor referencia
es un solo usuario y una nica transaccin) y repetirla con
112
mltiples clientes (virtuales o reales).
Criterio de
Verificacin:
Una Transaccin / Un Usuario: La finalizacin exitosa de los

Prueba scripts sin ninguna falla dentro del tiempo esperado (por
transaccin en forma independiente).
Mltiples Transacciones / Mltiples Usuarios: La finalizacin
exitosa de los Prueba scripts sin ninguna falla dentro tiempo
estimado.
La extensin de las Pruebas de Ejecucin requiere tener en
background la carga de trabajo en el servidor.
Existen varios mtodos que se pueden usar para realizar esto
como por ejemplo:
Consideraciones
Especiales:
Gatillar transacciones directamente al servidor, normalmente en

forma de llamadas de SQL.
Crear una carga de usuarios virtuales para simular
(normalmente varios cientos) los clientes. Para esto se utilizan
herramientas de emulacin de terminales remotas para lograr
esta carga. Esta tcnica tambin puede usarse para someter a
la red a un alto trfico.
Usar mltiples clientes fsicos, cada uno corriendo los Prueba
scripts para agregar una carga al sistema.
Las Pruebas de Ejecucin deberan realizarse en una mquina
dedicada o en un tiempo dedicado. Esto permite un control
total y una exacta medicin.
Las bases de datos utilizadas para realizar las Pruebas de
Ejecucin debern ser del tamao equivalente a las de
produccin o a escala similar.
Observaciones:
7.3.
Este tipo de Pruebas no se planificar ni se ejecutar.
C: Pruebas de Seguridad y de Control de Acceso
[De acuerdo al Riesgo N4, identificado en el punto 1.2.3.1.2 de este documento y

definido en el documento Lista de riesgos.doc, se sugiere realizar este tipo de
Pruebas.]
Se recomienda que el Administrador de la Red y del Sistema planifique algunas
pruebas en este sentido.
[El Pruebas de Seguridad y de Control de Acceso enfoca en dos reas claves de la
seguridad:]
113
Seguridad a nivel de la Aplicacin, incluyendo acceso a los datos o funciones de
negocio, y
Seguridad a nivel del Sistema, incluyendo el login y/o el acceso remoto al sistema.
La seguridad a nivel de la aplicacin, asegura que, sobre la base de la seguridad
deseada, se restringen a los usuarios a ciertas funciones o Casos de Uso
especficos o se les limita el acceso a datos disponible para ellos.
La seguridad a nivel de sistema, asegura que slo los usuarios definidos en el
sistema son capaces de acceder a la aplicacin y slo a travs de entradas
apropiadas.
Objetivo del Prueba:
Seguridad a Nivel de Aplicacin: Verificar que un usuario

puede acceder slo a las funcionalidades y datos para
las cuales ese tipo de usuario tiene permiso.
Seguridad a Nivel de Sistema: Verifica que slo esos
usuarios con acceso al sistema y aplicacin tienen
permitido el acceso.
Nivel de Aplicacin: Identifique y liste cada tipo de
usuario y las funcionalidades y datos de cada tipo para
las cuales tiene permiso.
Tcnica:
Cree Prueba para cada tipo de usuario y verifique cada

permiso creando transacciones especficas para cada
usuario.
Modifique los tipos de usuarios y vuelva a ejecutar los
Prueba case para los mismos usuarios. En cada caso
verifique si las funcionalidades y los datos estn
correctamente disponibles o denegados.
Acceso a Nivel de Sistema: vea las consideraciones
especiales ms abajo.
Criterio de Verificacin:
Para cada tipo de usuario conocido, las funcionalidades y

los datos correctos debieran estar disponibles y todas las
transacciones ejecutadas debieran ejecutarse de acuerdo
a lo esperado.
Consideraciones
Especiales:
El acceso al sistema debera ser verificado con el

administrador de la red o del sistema. Este Pruebas
quizs pueda requerir de la participacin del
administrador de la red o del sistema.
Observaciones:
Este tipo de Pruebas no ser planificado y no se

ejecutar.
114
8. Flujo de trabajo del Pruebas
[Proporciona un entorno del flujo de trabajo a seguir por el equipo de Prueba en
el desarrollo y ejecucin del Modelo de Prueba
El flujo de trabajo especfico del Pruebas que ser usado debe ser documentado
por separado en los Casos de desarrollo del proyecto. Este debera explicar
cmo, en el proyecto, se ha personalizado la base RUP de flujo de trabajo
Pruebas.
Los detalles ms especficos de las tares de Pruebas individuales estn definidas de
diferentes formas, dependiendo de la naturaleza del proyecto; por ejemplo:
Definido como una lista de tareas en esta seccin del Modelo de Prueba, en un
apndice.
Definido en un cronograma central del proyecto (a menudo con una herramienta

como Microsoft Project)
Documentado por separado, listas dinmicas To-Do para cada miembro del
equipo, usualmente tambin estn detallados para ser ubicados en el Modelo de
Prueba.
Documentado en un panel central y actualizado dinmicamente.
Documentado de manera no formal del todo.
Basado en la naturaleza del proyecto, debera listar las tareas especficas de Pruebas
en este punto o entregar un texto descriptivo explicando los procesos que usa el
equipo de Pruebas para manejar los detalles del plan y entregar una referencia de
donde sern almacenados estos detalles, siempre y cuando sea apropiado.
Para los planes de Pruebas maestros, se recomienda evitar la descripcin detallada de
la tarea de planeamiento.]
9. Necesidades del entorno

[Esta seccin especfica los recursos no humanos requeridos por el Modelo de
Prueba]
9.1.
Hardware base del sistema
La siguiente tabla establece los recursos necesarios por el Prueba enunciado en este
Modelo de Prueba.
[Los elementos especficos del sistema de Prueba pueden no ser comprendidos
en su totalidad en las primeras iteraciones, por lo tanto se espera que esta
seccin se complete despus del tiempo.]
[Nota: Aadir o borrar tems segn sea necesario]
Recurso
Servidor de Base de Datos
Network o Subnet
Nombre del Servidor
Nombre de Base de
Datos
Cantidad
Nombre y tipo
115
PCs clientes de Prueba
Extras
Configuracin
Requerimientos
Deposito de Prueba
Network o Subnet
Nombre del Servidor
PCs de desarrollo del Prueba
9.2.
Elementos Software base en el entorno de Prueba
Los siguientes elementos software base son requeridos en el entorno de Prueba de

este Modelo de Prueba.
Nombre del elemento

Software
NT Workstation
Windows 2000
Internet Explorer
Netscape Navigator
Microsoft Outlook
McAffee Antivirus
9.3.
Versin
Tipo y Otras Notas

Sistema Operativo
Sistema Operativo
Browser de Internet
Browser de Internet
Software cliente de eMail
Deteccin de virus y
recuperacin de software
Herramientas de Productividad y Ayuda
Las siguientes herramientas sern empleadas como ayuda al Prueba para este
Modelo de Prueba.
Herramienta Categora o
Tipo
Manejo del Prueba
Ajuste de Defectos
Herramienta ASQ para
Pruebas funcional
Herramienta ASQ para
Marca de la
herramienta
Vendedor o Local
Versin
116
Pruebas de Ejecucin
Monitor del nivel de
cobertura del Prueba
Administracin del
proyecto
Herramientas DBMS
9.4.
Configuraciones de Entorno de Prueba
Las siguientes Configuraciones de Entorno de Prueba necesitan ser proporcionadas y

soportadas para este proyecto.
Nombre de la Configuracin
Descripcin
Implementado en
configuracin fsica
Configuracin de usuario
promedio
Configuracin mnima soportada
Visibilidad y Movilidad Probada
S.O. Internacional de Doble Byte
Instalacin de Network(No del
cliente)
Responsabilidades, Personal, y Capacitacin Necesaria
10.
[Esta seccin presenta los recursos requeridos para dirigir el Prueba en el Modelo
de Prueba; las responsabilidades generales y el conocimiento o habilidad
requerida para estos recursos]
10.1.
Personas y Roles
Esta tabla muestra los roles del personal en el esfuerzo de Prueba.

Recursos Humanos
Rol
Recursos Mnimos Recomendados

(nmero de roles asignados por
tiempo completo)
Responsabilidades Especficas o
Comentarios
117
Realiza un manejo superficial.
Sus responsabilidades incluyen:
Planeamiento y Logstica
Misin de acuerdo
Identificar los motivos
Adquirir los recursos apropiados
Presentar reportes gerenciales
Abogar por los intereses del
Prueba
Evaluar la efectividad del esfuerzo de
Prueba
Encargado de
Prueba
Identifica y define los Prueba

especficos que deben realizarse.
Identificar las ideas del
Prueba
Definir los detalles del Prueba
Determinar los resultados del
Prueba
Peticiones de cambios en la
Documentacin
Evaluar la calidad del producto
Analista de
Prueba
Recursos Humanos
Rol
Diseador del
Prueba

tiempo completo)
Comentarios
Define el acercamiento tcnico para la
implementacin del esfuerzo de
Prueba.
Define una aproximacin al
Prueba
Define la arquitectura de
automatizacin
Verifica las tcnicas de
Prueba
Define la Pruebas de los elementos
Estructura la implementacin del
Prueba
118
Implementa y ejecuta los Pruebas.
Implementar los Pruebas y los Prueba
suites.
Ejecutar los Prueba suites.
Guardar run registro de los resultados.
Analizar y recuperarse de una falla en
el Prueba.
Documentar los incidentes.
Probador
Asegura que el entorno de Prueba se

encuentre en buenas condiciones.
Administrar el sistema de
Prueba
Instala y da soporte para el acceso y
recuperacin del entorno de
configuraciones y laboratorios de
Prueba.
Asegura que el entorno de datos del
Prueba (Base de Datos) se encuentre
activo y en buenas condiciones. Sus
responsabilidades incluyen:
Dar soporte a la administracin
de los datos
del Prueba (Base de Datos)
Administrador
de sistema del
Prueba.
Administrador
de la Base de
Datos,
Encargado de
la Base de
Datos
Recursos Humanos
Rol
Diseador
Implementado
r

tiempo completo)
Comentarios
Identifica y define las operaciones,
atributos, y asociaciones de las clases
del Prueba.
Definir las clases del Prueba
requeridas para soportar los
requerimientos de Pruebas
como fueron definidos por el
equipo de Prueba.
Implementa y une los Pruebas de las
clases y paquetes de Prueba.
119
10.2.
Crear los componentes del

Prueba requeridos para
soportar los requerimientos
de Pruebas como fueron
definidos por el diseador.
Personal y entrenamiento necesario
Esta seccin muestra como acercar al personal y capacitarlos en los roles de Prueba
definidos para el proyecto.
[La forma de acercar al personal y capacitarlo puede variar de un proyecto a otro.
Si esta seccin es parte del Plan de Prueba Maestro, debera indicar en qu puntos
del ciclo de vida del proyecto se necesitarn diferentes habilidades y nmero de
personas. Si esta es una Iteracin del Plan de Prueba, debera enfocarse
principalmente en donde y que capacitacin debe efectuarse durante la iteracin
De todas maneras la etapa de capacitacin necesita un cronograma, esto basado en
la filosofa del Just-In-Time (JIT).
Ver las oportunidades de combinar herramientas de productividad comerciales con la
capacitacin en estas herramientas.
El equipo de Prueba requiere, a menudo, soporte y habilidades de miembros de
otros equipos que no sean directamente parte de este equipo de Prueba.
Asegurarse de tener en mente en el plan una apropiada disponibilidad de los
Administradores de Sistemas, Administradores de la Base de Datos, y
Desarrolladores quienes son necesarios para establecer el esfuerzo de Prueba.]
11.
Fases del proceso de Iteracin
[Identificar las fechas claves de cada fase que fije el contexto para el esfuerzo de Prueba.]
Fase
Acuerdo del Plan de Iteracin.
Comienzo de la Iteracin
Lnea Final de los requerimientos.
Lnea Final de la Arquitectura
Lnea Final de la Interfaz de Usuario
Primer Entregable entregado para el
Prueba
Primer Entregable aceptado en el
Prueba
Primer Entregable que completa el
ciclo de Prueba
Fecha de
Inicio
planeada
Fecha de
Inicio
actual
Fecha de
Termino
planeada
Fecha de
Termino
actual
120
[El Segundo Entregable no ser
Probado]
Tercer Entregable entregado para el
Prueba
Tercer Entregable aceptado en el
Prueba
Tercer Entregable que completa el
ciclo de Prueba
Cuarto Entregable entregado al Prueba
Cuarto Entregable aceptado en el
Prueba
Revisin de la evaluacin de la
Iteracin
Fin de la Iteracin
12.
Riesgos, Dependencias, Suposiciones y Limitaciones
[Listar cualquier riesgo que pueda afectar la ejecucin satisfactoria de este Plan de
Prueba, e identificar las estrategias de mitigacin y contingencia para cada riesgo.
Indicar tambin un ranking de los riesgos ms esperados y de los que pueden producir
el mayor impacto.]
Riesgo
No se cumple el criterio de
Prerrequisito de entrada.
Datos del Prueba de prueba

son inadecuados
La Base de Datos requiere

actualizacin
Estrategia de Mitigacin
<Probador> Deber definir los
prerrequisitos que se deben cumplir antes
de empezar a cargar el Pruebas
<Cliente> Deber esforzarse por cumplir
los prerrequisitos indicados por el
<Probador>
Contingencia (El riesgo se realiza)

Encontrar las salidas de los
prerrequisitos
Considerar una falla en la
introduccin de los datos del
Prueba
<Cliente> Debe asegurar que un conjunto

completo de datos del Prueba estn
disponibles y sean apropiados
Redefinir los datos del Prueba

Revisar el Modelo de Prueba y
modificar los componentes
<Probador> Deber indicar que es lo que

se requiere y deber verificar que los datos
del Prueba sean apropiados.
(estos son, scripts)

Considerar una falla en la
introduccin de los datos del
<Administrador de Sistema> Deber

preocuparse de que la Base de Datos sea
regularmente actualizada, tan frecuente
como sea requerido por el <Probador>
Prueba
Restaurar los datos y comenzar de
nuevo
Limpiar la Base de Datos
[Listar cualquier dependencia identificada durante el desarrollo de este Modelo de

Prueba que pueda afectar su ejecucin satisfactoria si estas dependencias no han sido
mencionadas. Tpicamente estas dependencias que estn relacionadas con actividades
en la ruta crtica son prerrequisitos o postrequisitos para una o ms actividades
121
procedentes (o subsecuentes). Deber considerar las responsabilidades de miembros
de otros equipos o del personal, externas al esfuerzo de Pruebas]
Dependencia entre
Potencial impacto o
dependencia
Propietarios
[Listar cualquier suposicin realizada durante el desarrollo de este Modelo de Pruebas

que puedan afectar su ejecucin satisfactoria. si estos supuestos comprueban que son
incorrectos. Los supuestos estn relacionados]
Supuesto a probar
Impacto del supuesto si es
Propietarios
incorrecto
[Listar cualquier restriccin puesta en el esfuerzo de Pruebas que haya tenido un

efecto negativo en la manera en que se haya realizado este Modelo de Prueba]
Restriccin en
Impacto de la restriccin en
el esfuerzo de Prueba
Propietarios
Procesos administrativos y procedimientos
13.
[Describa qu procesos y procedimientos deben ser utilizados cuando los

resultados cumplen con el Modelo de Prueba y con los resultados esperados]
13.1.
Medicin y determinacin del grado de la prueba
[Describa el proceso de medicin y cuantificacin que ser usado para ajustar el

grado del Prueba]
13.2.
Reporte de la cobertura del Prueba
[Describa el proceso de cuantificacin para revisar y aceptar los reportes de este

Modelo de Prueba]
13.3.
Reporte de problemas, extensin, y edicin de la resolucin.
[Defina como los problemas del proceso sern reportados y extendidos, y el

proceso a seguir para llevar a cabo la resolucin.]
13.4.
Manejo de los ciclos de Pruebas
122
[Describa el manejo de los procesos de control para un ciclo de Pruebas]
13.5.
Estrategias de Trazabilidad
[Considere una adecuada estrategia de trazabilidad para:
Cobertura del Prueba versus las especificaciones Establece una medida para el
grado del Prueba
Motivaciones para el Prueba Establece determinaciones de relevancia de los
Prueba para ayudar a determinar donde mantener o retirar Pruebas
Elementos del diseo de software Establece ajustes de los subsecuentes cambios
en el diseo que harn necesario la re-ejecucin de Prueba o su retiro
Peticin de los resultados de los cambios Permite a los Pruebas que descubrieron
la necesidad de un cambio, ser identificados y ejecutados nuevamente para verificar
que la peticin de cambios a sido completada satisfactoriamente ]
13.6.
Aprobacin y Trmino
[Describe el proceso de aprobacin y lista los ttulos de los trabajos (y nombres

de los actuales Responsables), antes de esto el plan debe haber sido aprobado y
los planes deben haber completado satisfactoriamente su ejecucin]
123
8.4.13 Plantilla Lista de Riesgos

Lista de Riesgos
Versin <1.1.0>
documento de Lista de Riesgos. El texto entre parntesis cuadrados y desplegado en
azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado
antes de la publicacin del documento. El estilo Body Text se activa automticamente
cuando se ingresan prrafos de texto definitivo. El formato del texto debe tener
tipo de letra verdana. ]
124
Fecha
<aaaa-mm-dd>
Versin
<1.1.0>
Descripcin
Documento inicial
Autor
<Nombre>
125
ndice
1.
1.1
1.2
1.3
1.4
1.5
2.
3.
3.1
3.2
3.3
Introduccin
269
Propsito
269
mbito
269
Definiciones, Acrnimos, y Abreviaciones
269
Referencias
269
Resumen Ejecutivo
269
Gestin de los Riesgos
270
Riesgos
271
Resumen de los riesgos
271
Nivel de magnitud y valores de Exposicin
271
Valores de Probabilidad e impacto
271
Tabla 3
271
4. Detalles de los riesgos
272
4.1
<Identificador de RiesgoUn nombre descriptivo o numero> 272
4.1.1 Magnitud del Riesgo o Ranking
272
4.1.2 Descripcin
272
4.1.3 Impactos
272
4.1.4 Indicadores
272
4.1.5 Estrategia de mitigacin
272
4.1.6 Plan de contingencia
272
4.2
<Siguiente identificador de RiesgoUn nombre descriptivo o numero>
272
126
Lista de Riesgos
1. Introduccin
[La introduccin de la Lista de Riesgos es un resumen del resto del documento.
Incluye el propsito, mbito, definiciones, acrnimos, abreviaciones, referencias y una
descripcin de esta Lista de Riesgos]
1.1.
Propsito
[Especificar el propsito de esta Lista de Riesgos.]

1.2.
mbito
[Es una descripcin del mbito de esta Lista de Riesgos; que proyectos estn asociados
con cualquier cosa que afecte o influya este documento.]
1.3.
Definiciones, Acrnimos, y Abreviaciones
[Esta seccin entrega las definiciones de todos los trminos, acrnimos, y abreviaciones
requeridas para interpretar correctamente la Lista de Riesgos. Esta informacin
puede ser obtenida del Glosario del proyecto]
1.4.
Referencias
[Esta seccin entrega una lista completa de todos los documentos referenciados en
cualquier lugar de la Lista de Riesgos. Identificando cada documento por ttulo,
edicin si es aplicable, fecha, y editorial. Especificando las Fuentes de donde se pueden
obtener las referencias. Esta informacin puede ser entregada como referencia en un
apndice o algn otro documento.]
1.5.
Resumen Ejecutivo
[Esta seccin describe que contiene el resto del documento y explica cmo est
organizado.]
2. Gestin de los Riesgos

El objetivo de la gestin de riesgos de los proyectos es identificar problemas
potenciales antes de que ocurran de manera que las actividades de manejo de riesgos
puedan ser planeadas y usadas cuando se necesiten durante la vida del proyecto para
mitigar los impactos adversos que impidan alcanzar los objetivos del proyecto. RUP
(Rational Unified Process) considera la evaluacin de los riesgos como una parte
fundamental del proceso.
Es necesario decidir cmo abordar, planificar y ejecutar las actividades de gestin de
riesgos para un proyecto.
Id
Paso
Descripcin
Responsable
Salida
Identificar
riesgos
En la fase de Inicio y Planeacin se identifican los riesgos del

proyecto, en primera instancia se busca en el plan de riesgos los
posibles riesgos, si no se encuentra en el listado se ingresa
como un riesgo genrico del proyecto
Vendedor
PM
Plan de
Riesgos
127
2
Analizar y
priorizar
Planear
Hacer
seguimiento y
reportar
Registro
organizaciona
l
Asignar a cada riesgo la probabilidad de ocurrencia que debe

estar entre 0 y 50% segn la priorizacin y el anlisis
Formular estrategias, acciones y planes de mitigacin para los
riesgos identificados
Supervisar los planes de accin, verificar que los planes de
mitigacin han sido implementados, en caso de que no
funcionen, reportar el riesgo materializado, fecha, nmero de
ocurrencias, magnitud de prdida en horas, solucin y accin
correctiva y preventiva formulada
Registrar en lecciones aprendidas aquellos riesgos que se
materializaron en el proyecto y que deban formar parte del
conocimiento organizacional para que sirvan de fuente de
consulta para otros proyectos
Vendedor
PM
Plan de
Riesgos
Vendedor
PM
Plan de
Riesgos
PM
Plan de
Riesgos
PM
Lecciones
Aprendida
s
3. Riesgos
3.1.
Resumen de los riesgos
Fase/Iteracin del proyecto

M
Concepcin
1
Elaboracin
1
Construccin
1
Riesgo
Transicin
1
a
g
n
i
t
u
d
Tabla 1
3.2.
Nivel de magnitud y valores de Exposicin
Magnitud
A Alto
S Significativo
M Moderado
I Inferior
B Baja
Exposicin
6.4 a 10.0
3.6 a 6.4
1.6 a 3.6
0.4 a 1.6
0 a 0.4
Tabla 2
3.3.
Valores de Probabilidad e impacto
128
Nivel
Valores de
Probabilidad
Alto
0.8 a 1.0
Significativo
0.6 a 0.8
Moderado
0.4 a 0.6
Inferior
0.2 a 0.4
Bajo
0.0 a 0.2
Tabla 3
4. Detalles de los riesgos
Valores de
Impacto
8.0 a 10.0
6.0 a 8.0
4.0 a 6.0
2.0 a 4.0
0.0 a 2.0
[Para lograr el xito del proyecto es necesario realizar un estudio a conciencia de todos
los riesgos que inciden, sea de forma directa o indirecta, tomar las acciones necesarias,
tener el control y darle total seguimiento a los mismos, con el fin de evitarlo o reducir
el impacto que pueda generar.]
4.1.
<Identificador de RiesgoUn nombre descriptivo o numero>
[Identificar los riesgos: Consiste en determinar todos los riesgos posibles que podran
afectar el proyecto y determinar sus caractersticas].
1.1.55. Magnitud del Riesgo o Ranking
[Un indicador de la magnitud del riesgo, puede ser asignado a un ranking de riesgos
ordenado desde el ms daino al menos daino hacia el proyecto.]
1.1.56. Descripcin
[Una descripcin del riesgo.]
1.1.57. Impactos
[Lista el impacto en el proyecto o producto. El impacto (CONSECUENCIAS) hay que
medirlo en el alcance: cuanto se afecta la duracin (por cunto tiempo se manifiesta el
riesgo).]
1.1.58. Indicadores
[Describe como monitorear y detectar que los riesgos han ocurrido o pueden ocurrir.
Incluyendo aquellas cosas como mtricas y umbrales, resultados de las pruebas,
eventos especficos, etc.]
1.1.59. Estrategia de mitigacin
[Describe que se hace actualmente en el proyecto para reducir el impacto de los
riesgos.]
1.1.60. Plan de contingencia
129
[Describe el curso de accin a seguir en caso de que el riesgo de materialice.
Soluciones alternativas, reduccin de funcionalidad, etc.]
4.2.
<Siguiente identificador de RiesgoUn nombre descriptivo o numero>
130
8.4.14 Plantilla Minuta de la Reunin

Minuta de la reunin
Versin:
<1.1.0>
Fecha:
<aaaa-mm-dd>
Descripcin:
<Caracterstica genrica de la
reunin>
Lugar
<lugar>
Hora inicio:
<hh:mm>
Hora
termino:
a.
<hh:mm>
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
<Detalles>
Autor
<Nombre>
1. Participantes
[Ingresar todos los participantes de la reunin con nombre, cargo y empresa.]
Nombre
Cargo
Empresa
2. Definiciones, Acrnimos y Abreviaciones

[Prrafo obligatorio si aplican.]
[Si existen cosas como nombres cortos, signos, Por ejemplo nombre de la
empresa o persona se puede describir con dos letras de nombre.]
3. Referencias
[Prrafo obligatorio si existen referencias con otros artefactos.]
[Nombrar documentos, informes o cosas similares conectadas con el tema de la
reunin.]
4. Temas
131
[Describir todos los temas de reunin. Cada tema tiene su propia descripcin.
Exponer opiniones de los participantes de la reunin sobre el tema]
4.1.
<Tema 1>
5. Compromisos
[Describir todos los compromisos acordados durante la reunin. Cada
compromiso tiene sus acciones acordadas, su plazo y su(s) responsable(s). Por
ejemplo, un compromiso puede ser un tema de la reunin, como Plan del
Proyecto, y acciones acordadas pueden ser entregar plan del proyecto a
Gerente.]
Compromiso
Acciones Acuerdos
Plazo
Responsable(s)
6. Seguimiento
[Prrafo obligatorio si se realiza seguimiento.]
[Listar las actividades a las cuales se les realiza seguimiento durante la reunin,
con su responsable, el plazo de finalizacin y el avance al momento de la
reunin.]
Actividad
Responsables (s)
Plazo
Avance
7. Conclusiones
[Describir todas las conclusiones de la reunin. Cada conclusin tiene su propia
descripcin. Exponer responsables para cada conclusin.]
7.1.
<Conclusin 1>
7.2.
<Conclusin 2>
132
8.4.15 Plantilla Asignacin de Roles
<Nombre de Proyecto>
Asignacin de Roles
Versin <1.1.0>
[Esta plantilla tiene por finalidad servir de base para la confeccin del documento
Asignacin de Roles. El texto entre parntesis cuadrados y desplegado en azul itlico
publicacin del documento.]
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<autor>
133
ndice
1.1
1.3
1.4
1.5
2.1
2.2
2.3
1 Introduccin ................................................................................................................ 278

Propsito
...............................................................................................................
278
1.2
mbito .................................................................................................................. 278
Definiciones, acrnimos y abreviaciones ............................................................... 278
Referencias ........................................................................................................... 278
Resumen Ejecutivo ............................................................................................... 278
2 Asignacin de Roles de la Organizacin y del Cliente ................................................. 279
Organigrama del Proyecto ..................................................................................... 279
Esquema de comunicaciones ................................................................................. 279
Asignacin de roles para el Proyecto ..................................................................... 280 3
Identificacin de Dependencias Crticas....................................................................... 281
134
14.
Introduccin
[La introduccin debe proveer un resumen del documento completo. Presente cualquier
informacin que el lector pueda necesitar para entender el documento en esta seccin.]
14.1.
Propsito
El propsito del documento es describir el equipo del proyecto y establecer sus

responsabilidades y roles.
14.2.
mbito
[Describa el alcance de este documento, a qu proyecto est asociado y cualquier

elemento que se vea afectado o influenciado por este documento.]
14.3.
Definiciones, acrnimos y abreviaciones

abreviaciones requeridas para interpretar correctamente el documento. Esta
informacin puede entregarse a modo de referencia a documento Glosario del
proyecto.]
14.4.
Referencias
[Esta subseccin provee una lista completa de todos los documentos referenciados en
cualquier parte de este artefacto. Cada documento debe ser identificado por ttulo,
edicin/versin, fecha, autor y nombre de archivo. Especificar las fuentes de donde se
pueden obtener estas referencias. Esta informacin puede ser entregada como
referencia a un apndice o a otro documento.]
14.5.
Resumen Ejecutivo
[Esta subseccin debe describir brevemente el resto del documento y explicar cmo est
organizado.]
15.
15.1.
Asignacin de Roles de la Organizacin y del Cliente

Organigrama del Proyecto
El siguiente diagrama contiene la estructura de roles del proyecto:

[Incorporar todos los roles necesarios en el diagrama, la estructura debe corresponder a
la realmente utilizada en el proyecto, la que se muestra solo es un ejemplo.]
135
Equipo delroyecto
p
Gerente de proyectos
<Nombre
>
Jefe de proyecto
- Cliente
<Nombre
>
Analista de calidad
<Nombre
>
Jefe de royecto
p
<Nombre
>
Admin. De config.
<Nombre
>
Grte. de proyectos
- Cliente
<Nombre
>
Diseador graf. (Opcional)

<Nombre
>
Representante de los usuarios

<Nombre
>
Equipode Desarrollo
[El Equipo de Desarrollo se compone de ingenieros de software y de sistemas

(analistas, arquitectos, programadores, etc.), testeadores y documentadores,
opcionalmente el diseador grfico puede ser externo a este grupo.]
[Hay tres roles distintitos que como mnimo debe definir la organizacin Cliente en un
proyecto. Estos son: Gerente de proyectos, Jefe de proyectos y Representante de los
usuarios. Es decir, el Cliente debe actuar como contraparte efectiva en el proyecto,
gestionando recursos por parte del cliente (Jefe de proyectos), colaborando en la
definicin de los requerimientos, en la validacin/aceptacin de los productos y/o
servicios (Representante de los usuarios), y en el seguimiento y aprobacin general del
proyecto (Gerente de proyectos).]
15.2. Esquema de comunicaciones
[En esta seccin se deben identificar todos los canales de comunicacin que son
relevantes para el proyecto, al menos se debe considerar el documentar quin ser el
interlocutor vlido para solicitudes de requerimientos.]
De acuerdo a los roles identificados en el proyecto, por el lado de la organizacin el
receptor de requerimientos ser el Jefe de proyecto, <Nombre del Jefe de proyecto> y
el solicitante vlido de requerimientos o modificaciones a los mismos ser el <rol del
solicitante>, <nombre del solicitante>.
15.3. Asignacin de roles para el Proyecto
[Los roles consignados en la siguiente tabla corresponden a una representacin de
roles en el modelo RUP los cuales se deben mapear con los utilizados en su
organizacin.
Se debe adoptar la nomenclatura y descripcin que se utilice en su organizacin, o
adoptar los descritos.]
Roles en RUP
Rol en la Organizacin
Responsable
136
Gerente de Proyectos
Planifica y controla los recursos fsicos,
humanos, monetarios e informticos que se le
otorgan para lograr los resultados esperados de
los distintos proyectos de desarrollo de su rea.
[Ingrese en esta columna el rol

equivalente en su organizacin]
Jefe de Proyecto
Lidera y coordina al grupo de trabajo, verifica y
revisa los productos, configura el proceso,
decide y verifica el cumplimiento de las mejores
prcticas, define, sigue y controla el plan del
proyecto, define y sigue los riesgos, gestiona los
contactos necesarios con los usuarios
coordinando su interaccin con el grupo de
trabajo.
Grupo de Ing. de Software
Trabaja en el desarrollo y mantencin de
software, lleva a cabo actividades como anlisis,
diseo, codificacin, testing, documentacin, y
redaccin de informes tcnicos.

[Ej. Project Manager (PO),]
[Ej. Director de operaciones, Chief

Operating Officer (COO) Senior
Manager (SM)]
[Ingrese en esta columna el

nombre de la(s) persona(s)
responsable(s)]

[Otros Ejemplos, Arquitecto de
SW, Diseador grfico, Diseador
de BD, Diseador de SW,
Diseador Grfico,
Programador,]
Grupo de Ing. de Sistemas

Responsable por la especificacin de
requerimientos, de asignar los requerimientos de
hardware y software, de especificar las
interfaces, y de controlar el diseo para
mantener la consistencia de los componentes
durante todo el ciclo de vida del proyecto.
Probador
Responsable de disear el plan de pruebas,
desarrollar los casos de prueba, preparar el
ambiente de pruebas, los datos de prueba y
ejecutar los ciclos de prueba.

Administrador de Configuraciones
Planifica y realiza las actividades de
administracin de configuracin. Controla y
autoriza todos los cambios en las lneas base.
La administracin del repositorio de lneas base
es revisada y aprobada por este rol antes de
tomar cualquier accin.
Roles en RUP
Analista de Calidad
Planifica
y
acta
en
actividades
de
aseguramiento de calidad de los procesos y en
que los productos no se desven de los
estndares. Es independiente de los grupos de
Administracin y Desarrollo. Realiza reportes
directamente a Gerente de proyectos.

[Otros Ejemplos, Analista,

Analista de sistemas, Revisor de
requerimientos, Especificador de
requerimientos,]
[Otros Ejemplos, Diseador de
casos de prueba, Analista de
pruebas,]
[Otros Ejemplos, Configuration

Management (CM) Group,
Software Configuration
Management (SCM) Group, ]
Rol en la Organizacin
[Otros Ejemplos, Process and
Product Quality Assurance
(PPQA) Group, PPQA Manager,
Software Quality Assurance
Group (SQA),]
Responsable
137
Vendedor
Responsable de la documentacin y del diseo equivalente en su organizacin]
de propuestas comerciales a Clientes y de los
[Otros Ejemplos,
Evaluador
contratos con subcontratistas.
tcnico, Marketing & Sales
(MS),]
Documentador
Produce material generalmente para la equivalente en su organizacin]
implantacin y los usuarios finales aunque
[Otros Ejemplos, Technical writer,
eventualmente puede colaborar con la redaccin
]
de otros artefactos necesarios.
16. Identificacin de Dependencias Crticas

[Identificar y documentar dependencias crticas entre los involucrados en el
proyecto. Para cada dependencia identificada se debe describir compromisos
adquiridos entre las partes, criterios para determinar si los compromisos se
satisfacen y un calendario de interaccin.]
138
8.4.16 Plantilla Plan de Despliegue del Proyecto

<Plan de Despliegue>
Versin <1.1.0>
[Nota: Esta plantilla tiene por finalidad servir de base para la confeccin
documentos o informes distintos a los definidos. El texto entre parntesis
Text se activa automticamente cuando se ingresan prrafos de texto definitivo.
Ninguno de los Campos definidos es obligatorio.]
139
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
140
ndice
1
Introduccin
285
1.1
Propsito
285
1.2
Alcance
285
2
3
4
5
6
7
8
9
10
11
Ambiente de instalacin
285
Pre-requisitos
285
Salidas
285
Entrenamiento
286
Respaldo
286
Pasos para llevar a cabo la instalacin 286
Seguridad
286
Agenda
286
Comprobacin instalacin
287
Tiempo para solucionar errores en instalacin 287
141
Plan de Despliegue del Proyecto

Introduccin
17.
[Seccin NO obligatoria.]
17.1.
Propsito
[Objetivo, determinar qu se pretende conseguir con el procedimiento].
Describir el alcance y los elementos necesarios a cabo un despliegue del software en las
instalaciones del cliente. El producto que se ha producido, disear como hacerlo llegar
a los usuarios finales.
17.2.
Alcance
[Efecto o trascendencia del procedimiento. Hasta donde cubre. Si es posible, explicar

qu no se cubre.
Definir el alcance de la instalacin, qu funcionalidades y servicios quedarn
habilitados una vez finalice la instalacin].
18.
Ambiente de instalacin
[Definir los servidores, bases de datos y sitios dnde se llevar a cabo la instalacin
Tiempo necesario para llevar a cabo la instalacin
Riesgos que se pueden materializar durante la instalacin y plan de mitigacin en
caso de materializarse
Carga de datos o configuracin de tablas maestras para que el software pueda
operar]
19.
Pre-requisitos
[Identificar qu elementos deben estar listos antes de llevar a cabo la instalacin

(estructura de directorios, imgenes, dlls, componentes, backup, etc.)]
20.
Salidas
[Identificar todos los elementos que deben quedar listos una vez se concluya la
instalacin:]
Base de datos
WebServices
Aplicacin
Reportes
Cron automtico
142
Libreras Componentes
Triggers, etc.
21.
Entrenamiento
[Conocimientos necesarios para llevar a cabo la instalacin]
22.
Respaldo
[Describir todos los elementos a los cuales se les debe sacar backup antes de
realizar la instalacin, dnde sern almacenados en caso de ser necesario
recuperar la informacin.]
1. Base de
datos
2. Fuentes 3.
Scripts
4. Etc.
23.
Pasos para llevar a cabo la instalacin
[Describir todo los pasos que van a ser necesarios para realizar la instalacin en los
diferentes equipos del cliente, segn se especifico en el Plan del Proyecto de
Desarrollo de Software] Por ejemplo:
1. Backup
2. Creacin base de datos
3. Carga datos iniciales
4. Instalar aplicacin
5. Instalar componentes
6. Configuracin sitio
7. Montar contenedor (websphere, tomcat, resin, internet information server, application server)
8. Definir contexto
9. Creacin estructura de directorios del proyectos
10.
Copia de archivos compilados
24.
Seguridad
[En esta seccin es necesario tomar en cuenta todos los elementos existentes en el
cliente, a la hora de realizar la instalacin de las aplicaciones.]
25.
Actividad
Integracin con Active Directory, LDAP

Transacciones seguras SSL
Registro de componentes de seguridad Etc...
Agenda
Fecha y
hora
inicial
estimada
Fecha y
hora
final
estimada
Responsabl
e IG
Responsable
Cliente
Recursos
Observaciones
Fecha
y hora
inicial
real
Fecha
y hora
final
real
143
26.
Comprobacin instalacin
[Describir las actividades que determinarn que la instalacin qued satisfactoria,

especificar pruebas de instalacin]
27.
Tiempo para solucionar errores en instalacin
[En caso de presentarse errores en la instalacin, especificar el tiempo mximo

para solucionar errores, en caso de superar este tiempo, especificar que se aborta
la instalacin y determinar cmo se dejar el software, en caso de ser un paralelo
indicar que se deja corriendo el software anterior.]
144
8.4.17 Plantilla Lista de Revisin del Ciclo de Vida del Proyecto

DATOS GENERALES DEL PROYECTO
Responsable
Administrador del Proyecto (PM)
Proyecto
NOMBRE
Cliente
NOMBRE
Fecha
<dd-mm-yyyy>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
Planeacin
Aprobacin
Cliente
Entregable
Plan de desarrollo de software
Requerido
S
Aprobacin Interna
S
Aprobado Por
PMO
Plan Manejo de requisitos

Plan de Administracin de Configuracin (CM)
S
S
S
S
Comit
requisitos
CM
S
No
Plan de riesgos
PMO
Lista de revisin ciclo de vida proyectos
No
No aplica
No
Acta del Proyecto
No
No aplica
No
Solicitud creacin estructura de repositorios
No
No aplica
No
Elaborar WBS
No
No aplica
No
Ordenamiento de actividades
No
No aplica
No
Estimacin duracin de actividades
No
No aplica
No
Criterios de aceptacin
No
No aplica
Kickoff interno
No
No
No aplica
No
Kickoff externo
No
No
No aplica
No
Planear siguiente iteracin
No
No aplica
No
Entregable
Documento Visin
Requerido
S
Aprobacin Interna
S
Aprobado Por
Revisor par
Glosario
No
No aplica
Documento de Especificacin de Requisitos de Software
No
Revisor par
Modelo del negocio
No
No aplica
No
Modelo del dominio
No
No aplica
No
Lista de requisitos de alto nivel en EA
No
No aplica
No
Lista de actores en EA
No
No aplica
No
Documento de Atributos de los Requisitos
No
No
No aplica
No
Diagrama de casos de uso
No
No aplica
No
Plan de riesgos
No
No aplica
No
R equisitos
Aprobacin
Cliente
145
Acta de reunin de licitacin
No
No aplica
Documento especificacin caso de uso
Revisor par
Matriz de trazabilidad de requisito
No
No aplica
No
Email solicitud revisin par
No
No aplica
No
Email con retroalimentacin revisin par
No
No aplica
No
Acta de entrega
No
No aplica
Presentacin requisito
No
No
No aplica
No
Lecciones aprendidas
No
No aplica
No
Acciones correctivas, preventivas, mejora
No
No aplica
No
Entregable
Requerido
Aprobacin Interna
Documento de arquitectura de software

Acta comit de arquitectura
S
S
S
No
Aprobado Por
Comit
arquitectura
No aplica
S
No
No
No aplica
No
Email con retroalimentacin revisin par
No
No aplica
No
Prototipo
No
Revisor par
Flujo de navegacin
No
No
No aplica
No
Documento de usabilidad
No
No aplica
Documento especificacin caso de uso refinado
Revisor par
Modelo de datos
Revisor par
Cumplimiento estndar base de datos
No
No aplica
No
Diseo de pruebas unitarias
No
No aplica
No
Check list anlisis y diseo
No
No aplica
No
Acta de entrega
No
No aplica
No
No aplica
No
No aplica
No
No
No aplica
No
Entregable
Acta de entrega de diseo
Requerido
S
Aprobacin Interna
No
Aprobado Por
No aplica
Presentacin diseo
No
No
No aplica
No
Inventario de componentes
No
No aplica
No
Cdigo fuente de la solucin
No
No aplica
No
Cumplimiento estndares codificacin
No
No aplica
No
Cumplimiento convenciones nombramiento
No
No aplica
No
Prueba unitaria
No
No aplica
No
No
No aplica
No
Registro de errores encontrados
No
No aplica
No
Lista de chequeo de desarrollo
No
No aplica
No
Diagrama de secuencia
No
No aplica
No
Integracin de componentes
No
No aplica
No
Artefactos para despliegue
No
No aplica
No
Manual de instalacin y configuracin
Equipo pruebas
A nlisis y Diseo
Aprobacin
Cliente
Im plementacin
Aprobacin
Cliente
146
Plan de despliegue
No
No aplica
Check list de instalacin
No
No aplica
No
No
No aplica
No
No
No aplica
No
Entregable
Plan de pruebas
Requerido
Opcional
Aprobacin Interna
S
Aprobado Por
PM
Aprobacin
Cliente
No
Lista de ideas de prueba
Opcional
No
No aplica
No
Check list de pruebas
Opcional
No
No aplica
No
Registro de errores en Bugtracker
No
No aplica
No
Diseo y ejecucin casos de prueba
No
No aplica
No
Estadsticas
No
No aplica
No
No
No
Pr ueba
Carta de certificacin
S
S
S
No
Coordinador
Pruebas
No aplica
No
No aplica
No
Entregable
Gestionar avance cronograma
Requerido
S
Aprobacin Interna
No
Aprobado Por
No aplica
Aprobacin
Cliente
No
Gestionar riesgos
No
No aplica
No
Gestionar facturacin
No
No aplica
No
Aseguramiento de calidad
No
No aplica
No
Entregable
Plan de pruebas
Requerido
S
Aprobacin Interna
S
Aprobado Por
PM
Aprobacin
Cliente
No
Lista de ideas de prueba
No
No aplica
No
Check list de pruebas
No
No aplica
No
Registro de errores
No
No aplica
No
Diseo y ejecucin casos de prueba
No
No aplica
No
Estadsticas
No
No aplica
No
No
No
No
Ej ecucin
Pr uebas
Carta de certificacin
S
S
S
No
Coordinador
Pruebas
No aplica
No
No aplica
Entregable
Plan de despliegue
Requerido
S
Aprobacin Interna
No
Aprobado Por
No aplica
Inventario de componentes de despliegue
No
No aplica
No
Lista de chequeo despliegue
No
No aplica
No
Control de asistencia
No
No aplica
No
Evaluacin instructor
No
No aplica
No
No
No aplica
No
D espliegue
Aprobacin
Cliente
147
No
No aplica
No
Entregable
Gestionar cronograma
Requerido
S
Aprobacin Interna
No
Aprobado Por
No aplica
Aprobacin
Cliente
No
Gestionar control de cambios
PM
Gestionar personal (vacaciones, capacitacin)
No
PMO
No
Gestionar riesgos
No
No aplica
No
Seguimiento interno proyecto (analistas)
No
No aplica
No
Informes estado proyecto
PM
No
Seguimiento interno proyecto (PMO)
No
No aplica
No
Informe de avance (cliente)
No
No aplica
Acta de reunin (cliente)
No
No aplica
No
No aplica
No
Entregable
Requerido
S
Aprobacin Interna
No
Aprobado Por
No aplica
Asistencia
No
No
No aplica
No
Plan capacitacin
No
PMO
Evaluacin capacitacin
No
No
No aplica
No
Instalador
No
No aplica
No
Manual de instalacin y configuracin
No
No aplica
Manual de usuario
No
No aplica
Acta de entrega
No
No aplica
No
No aplica
No
No
No aplica
No
C ontrol
E ntrega
Aprobacin
Cliente
148
8.4.18 Plantilla Documento Arquitectura del Software
<Nombre Proyecto>
Documento de Arquitectura de Software
Versin <1.0>
[Nota: Esta plantilla tiene como finalidad servir de base para la construccin del
documento de la Arquitectura del Software, basada en Rational Unified Process. El
texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) se
incluye para proporcionar una gua al autor y debe ser borrado antes de publicar el
documento. Un prrafo introducido siguiendo este estilo se ajustar automticamente a
la normalidad (Texto Fsica =).]
149
Fecha
<dd/mm/yy>
Versin
<x.x>
Descripcin
<detalles>
Autor
<nombre>
150
ndice
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Introduccin
294
1.1 Propsito
1.2 Alcance
1.3 Definiciones, acrnimos y abreviaturas
1.4 Referencias
1.5 Resumen
Representacin Arquitectnica
295
Metas y Restricciones de la Arquitectura 295
Vista de Casos de Uso
296
4.1 Casos de Uso-Realizaciones
Vista Lgica
296 5.1 Resumen
296
5.2
Diseo Arquitectnico de Paquetes
Vista del Proceso
297
Vista de Despliegue
297
Vista de Implementacin
297
8.1 Informacin general
8.2 Capas
Vista de datos (opcional)
297
Tamao y Rendimiento
298
Calidad
298
294
294
294
294
295
296
296
297
297
151
Documento de Arquitectura de Software

1. Introduccin
Uno de los desarrollos ms importantes dentro de la construccin del software es el
desarrollo de la arquitectura de software, que permite representar la estructura del
sistema, sirviendo de comunicacin entre las personas involucradas en el desarrollo
y ayudando a realizar diversos anlisis que orienten el proceso de toma de
decisiones. La plantilla de este documento se bas en las especificaciones de RUP
(Rational Unified Process) para el documento de arquitectura de software.
[La introduccin del Documento de Arquitectura de Software proporciona una
visin general del Documento completo. Incluye el propsito, alcance, definiciones,
acrnimos, abreviaturas, referencias, y una visin general del Documento de
Arquitectura de Software.]
1.1.
Propsito
Este documento proporciona una descripcin de la arquitectura del sistema,

haciendo uso de diversas visiones arquitectnicas para representar diversos
aspectos del sistema. Se realiza con el fin de documentar las decisiones de
arquitectura significativas que se han tomado en el sistema.
[En esta seccin se define la funcin o el propsito del Documento de Arquitectura
de Software, en la documentacin general del proyecto, y describe brevemente la
estructura del documento. Las audiencias especficas para el documento se
identifica, con indicacin de la forma en que se espera que utilicen el documento.]
1.2.
Alcance
[Una breve descripcin de lo que consiste el Documento de Arquitectura de

Software. Lo que se ve afectada o influenciada por este documento, definiendo de
manera detallada la distribucin de los paquetes del sistema en las diversas capas
que ste presenta, as como una descripcin de las capas a utilizar.]
1.3.
Definiciones, acrnimos y abreviaturas
[Esta seccin provee las definiciones de los trminos, acrnimos y abreviaturas

requeridas para interpretar apropiadamente el Documento de Arquitectura de
Software. Esta informacin puede ser proporcionada por referencia al Glosario del
proyecto.]
1.4.
Referencias
[Esta seccin provee una lista completa de todos los documentos referenciados en
cualquier parte del Documento de Arquitectura de Software. Identifica cada
documento por el nmero y nombre de informe, (si aplica), fecha y organizacin
152
que lo publica. Especifique las fuentes de donde las referencias se pueden obtener.
Esta informacin puede ser proporcionada por referencia a un apndice o a otro
documento.]
Por ejemplo algunas de las referencias aplicables pueden ser:
1.
2.
3.
4.
Documento de Especificacin de Requisitos de Software.

Documento de Visin del Proyecto del Sistema.
Glosario de Trminos del Sistema.
Plan de Proyecto del Sistema.
1.5.
Resumen
[Esta seccin describe lo que el resto del Documento de Arquitectura de Software

contiene y explica cmo el Documento de Arquitectura de Software est
organizado.]
Todas las secciones de este documento detallan la arquitectura del software a
desarrollar. Para ello se presenta de manera clara el caso de uso que mas
representa la arquitectura del sistema, empleando un lenguaje sencillo y directo, as
como grficos y vistas de acuerdo a la metodologa utilizada.
Por ejemplo:
Se incluye la Vista de Casos de Uso, con una descripcin completa de cada uno de
ellos y sus respectivos diagramas. Luego, se muestra la Vista Lgica en la que se
muestran las principales clases que modelan al sistema y las relaciones que existen
entre ellas, as como tambin el diseo de los paquetes de la arquitectura. Tambin
se encuentra la Vista de Despliegue, cuyo principal objetivo es establecer los
requerimientos del sistema en cuanto a la arquitectura requerida para su correcto
funcionamiento.
2. Representacin Arquitectnica
[Esta seccin describe lo que la arquitectura de software es que el sistema actual,
y cmo se representa. De los casos de uso, lgico, Vista al proceso, el despliegue y
ejecucin, se enumeran los puntos de vista que son necesarios, y para cada punto
de vista, explica qu tipos de elementos del modelo que contiene.] Por ejemplo:
La Arquitectura a utilizar ser Cliente-Servidor. El cliente es la aplicacin que ser
implementada en el lugar donde se encuentra la empresa. Se desarrollar una sola
aplicacin integrada, en la que solo se permitir el acceso a los usuarios registrados
en el sistema y a las reas a las cuales tengan acceso autorizado. Se emplear un
solo servidor centralizado.
3. Metas y Restricciones de la Arquitectura

[Esta seccin describe los requisitos de software y los objetivos que tienen algn
impacto significativo en la arquitectura, por ejemplo, la seguridad, la privacidad, el
153
uso de un producto fuera de la plataforma, la portabilidad, la distribucin y la
reutilizacin. Tambin captura las restricciones especiales que pueden aplicarse:
Diseo y estrategia de implementacin, herramientas de desarrollo, la estructura
del equipo, calendario, cdigo de la herencia, y as sucesivamente]
4. Vista de Casos de Uso

[Esta seccin muestra los casos de uso o escenarios del modelo de caso de uso si
representan alguna funcionalidad significativa, en el centro del sistema final, o si
tienen una gran cobertura arquitectnica-que ejercen muchos elementos
arquitectnicos o si ilustran el estrs o un procedimiento especfico, punto delicado
de la arquitectura.]
4.1.
Casos de Uso-Realizaciones
[En esta seccin se ilustra cmo el software funciona realmente dando un grupo
selecto de casos de uso (o escenario) realizaciones, y explica cmo los diversos
elementos de diseo de modelos de contribuir a su funcionalidad.]
5. Vista Lgica
[Esta seccin describe las partes arquitectnicamente significativas del modelo de
diseo, tales como su descomposicin en subsistemas y paquetes. Y para cada
paquete importante, su descomposicin en clases y los servicios pblicos de clase.
Usted debe introducir clases de gran importancia arquitectnica y describir sus
responsabilidades, as como algunas relaciones muy importantes, operaciones y
atributos.]
5.1.
Resumen
[Esta seccin describe la descomposicin general del modelo de diseo en cuanto a

su jerarqua de paquetes y las capas. Soporta los requerimientos funcionales y los
servicios que el sistema debe proveer a sus usuarios finales.]
5.2.
Diseo Arquitectnico de Paquetes
[Para el diseo de la arquitectura del sistema a desarrollar se utilizara la nocin de

paquetes, los cuales representan el formato de tres capas que por el que se rige el
desarrollo del proyecto.
Para cada paquete principal, incluir un apartado con su nombre, breve descripcin
y un diagrama con todas las clases y paquetes significativos contenidos en el
paquete.
Para cada clase significativa en el paquete, incluir su nombre, una breve
descripcin y, opcionalmente, una descripcin de algunos de sus principales
responsabilidades, operaciones y atributos.]
154
Los paquetes ms utilizados normalmente son:
Paquete Interfaz: Representa el fragmento del proyecto que interactuar con los
distintos usuarios, recibir informacin y solicitudes por parte de stos as como
tambin mostrar las respuestas a las diferentes solicitudes.
Paquete Manejador: Se encargar del manejo de las consultas y utilizacin de la
base de datos en la cual se encontrar toda la informacin relacionada a las
distintas funcionalidades que ofrecer el sistema.
Paquete Lgico del Negocio: Se encarga de realizar todas las operaciones y mtodos
que ofrece el sistema, as como tambin de la validacin de datos antes de realizar
las consultas. Contiene la lgica para el manejo de las operaciones del negocio.
6. Vista del Proceso

[Esta seccin describe la descomposicin del sistema en los procesos ligeros (hilos
de control individuales) y los procesos de peso pesado (agrupaciones de procesos
ligeros). Organizar la seccin de los grupos de procesos que se comunican o
interactan. Describir las principales vas de comunicacin entre procesos, como el
paso de mensajes, alarmas, y el encuentro. Se incluye aqu el Diagrama de
Entidad Relacin, que es el diagrama principal para el Anlisis y Diseo, adems de
la inclusin del Diccionario de Datos relacionado al Diagrama de Entidad Relacin]
7. Vista de Despliegue
[Esta seccin describe una o ms de la red fsica (hardware) las configuraciones en
las que se ha implementado el software y ser ejecutado. Se trata de un punto de
vista del modelo de implementacin. Como mnimo para cada configuracin debe
indicar los nodos fsicos (ordenadores, CPUs) que ejecutan el software y sus
interconexiones (bus, LAN, punto a punto, y as sucesivamente.) Tambin incluyen
un mapeo de los procesos del Proceso Ver en los nodos fsicos.]
8. Vista de Implementacin
[Esta seccin describe la estructura general del modelo de implementacin, la
descomposicin del software en capas y subsistemas en el modelo de
implementacin, y cualquier otro componente de gran importancia arquitectnica.]
8.1.
Informacin general
[Esta seccin define los nombres y las diferentes capas y su contenido, las reglas
que rigen la inclusin de una capa determinada, y los lmites entre las capas.
Incluir un diagrama de componentes que muestra las relaciones entre las capas. ]
8.2.
Capas
155
[Para cada capa, incluyen una subseccin con su nombre, una enumeracin de los
subsistemas situados en la capa, y un diagrama de componentes.]
9. Vista de datos (opcional)

[Una descripcin de la perspectiva de volumen de datos generados por del sistema.
Esta seccin es opcional si hay volumen de datos poco o nada, o la traduccin
entre el modelo de diseo y el modelo de datos es trivial.]
10.
Tamao y Rendimiento
[Una descripcin de las caractersticas principales de dimensionamiento del

software que afectan la arquitectura, as como las limitaciones de rendimiento de
destino.]
Se puede describir aspectos como:
Tiempo de respuesta en el acceso a la Base de Datos

Tiempo de respuesta de transacciones
Espacio en disco para el cliente
Espacio en disco para el servidor de Base de datos
11.
Calidad
[Una descripcin de cmo la arquitectura del software contribuye a todas las

capacidades (que no sea la funcionalidad) del sistema: extensibilidad, fiabilidad,
portabilidad, y as sucesivamente. Si estas caractersticas tienen un significado
especial, como la implicacin en la seguridad, la seguridad o privacidad, que debe
estar claramente delimitada.]
Para un mejor aprovechamiento de la arquitectura de software se pueden revisar los

siguientes aspectos:
Usabilidad
Eficiencia Seguridad
Confiabilidad
Mantenimiento
Estndares
156
8.4.19 Plantilla Solicitud de Cambio de Requerimientos
Solicitud de Cambio de Requerimientos
Iniciador autorizado:
ID Cambio:
Estado:
[ Abierto / Cerrado ]
Cambio propuesto
Descripcin
Beneficio esperado /
Justificacin
Anlisis de Impacto
En calendario
En recursos
En costos
Comentarios:
Evaluacin del Comit de Control de Cambios

Beneficio / Prioridad: [ Crtico / Importante / til / Ninguna ]
Comentarios:
Aprobado
No aprobado
Firma:
Responsable del
anlisis
de
impacto
Firma:
Firma:
Firma:
Firma:
Fecha:
Fecha:
Fecha:
Fecha:
Fecha:
Emisor de la
propuesta
Responsable por
la evaluacin
Iniciador
notificado
Cerrado
157
8.4.20 Plantilla Acta de Inicio del Proyecto
Nombre Proyecto:
Cliente:
Preparacin:
Administrador Proyecto:
Encargado Cliente:
Propsito del Proyecto o Justificacin:

[Definir la razn por la que est siendo creado el proyecto. En esta seccin se puede
referir a un caso de negocio, el plan estratgico, los factores externos, contrato o
cualquier otro documento o la razn para llevar a cabo el proyecto.]
Descripcin del Proyecto:

[Proporcionar una descripcin resumida a nivel del proyecto. En esta seccin se pueden
incluir informacin a nivel macro de los productos y proyectos, as como el enfoque del
proyecto.]
Proyecto y Requisitos del producto:

[Definir los requisitos principales que se deben cumplir para satisfacer el propsito del
proyecto. Describir las caractersticas del producto y las funciones que deben estar
presentes para satisfacer las necesidades y expectativas de los interesados. Esta
seccin no se describe los requisitos detallados como los que estn cubiertos en la
documentacin de requisitos.]
Criterios de aceptacin:
[Identificar los criterios que deben cumplirse para que el proyecto sea aceptado por el
cliente o patrocinador.]
Riesgos Inciales:
[Documentar los riesgos inciales del proyecto. Estos luego sern incorporados a un
Registro de riesgos, como la planificacin para el inicio del proyecto.]
Objetivos
Alcance
Criterios de xito
Persona que Aprueba
158
[Una
declaracin
que
describe
el
alcance
necesario para lograr los
objetivos planteados para
el proyecto.]
[Los criterios especficos y

cuantificables
que
determinarn el xito del
proyecto.]
[El nombre o la posicin de

la persona que firma la
aprobacin de los objetivos
planteados.]
Tiempo
[Descripcin
de
los [Las fechas especficas que
objetivos para lograr la se deben cumplir para
finalizacin oportuna del determinar el xito de la
proyecto]
programacin.]

aprobacin de los
objetivos planteados.]
Costo
[Descripcin
de
los [El costo o el rango del
objetivos para los gastos costo que define el xito
que se incurrirn en el del presupuesto del
proyecto.]
proyecto]
[Nombre o la posicin de la
persona
que
firma
la
planteados.]
Calidad
[Descripcin
de
los
criterios de calidad que se
establecern para lograr el
xito el proyecto.]
Medidas especficas que

deben cumplirse para el
proyecto y producto para
ser considerado un xito.

planteados.]
[Cualquier otro tipo de [Resultados

especficos
objetivos apropiados que medibles que definen el
deban definirse para el xito.]
proyecto.]

planteados.]
Otros
Resumen de Hitos
Vencimiento
[Hechos significativos en el proyecto. Estos pueden incluir la [Fecha

de
realizacin de objetivos clave, el comienzo o la finalizacin de una terminacin del
fase de proyecto o de la aceptacin del producto.]
hito.]
159
Presupuesto Estimado:
[Rango inicial del estimado de gastos para el proyecto]
Nivel de Autoridad del Administrador del Proyecto

Decisiones sobre el Personal:
[Definir la autoridad del administrador del proyecto para contratar, despedir,
disciplinar, aceptar o no aceptar personal para el proyecto.]
Gestin del Presupuesto y Varianza

[Definir la autoridad del administrador del proyecto para tomar decisiones tcnicas
sobre los entregables o el enfoque del proyecto.]
Decisiones Tcnicas
[Definir la autoridad del administrador del proyecto para tomar decisiones tcnicas
sobre los entregables o el enfoque del proyecto.]
Resolucin de Conflictos
[Definir la autoridad del administrador del proyecto para resolver los conflictos dentro
del equipo, dentro de la organizacin y con los interesados stakeholders externos.]
Escalamiento de los Lmites de Autoridad

[Define la ruta de escalamiento de asuntos ajenos al nivel de autoridad del
administrador del proyecto.]
Aprobaciones:
Firma del Administrador del Proyecto
Firma del Cliente
Nombre del Administrador del Proyecto Nombre del Encargado del Cliente
Fecha
Fecha
160
8.4.21 Plantilla Estructura de Desglose del Trabajo
161
8.4.22 Plantilla Cronograma del Proyecto
162
163
164
8.4.23 Plantilla Prototipos de Interfaces de Usuario

Versin <1.1.0>
[Nota: Este Plantilla tiene por finalidad servir de base para la confeccin de los
prototipos de Interfaces de Usuario. El texto entre parntesis cuadrados y
activa automticamente cuando se ingresan prrafos de texto definitivo. Ninguno
de los Campos definidos es obligatorio.]
165
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
166
ndice
1
1.1
1.2
1.3
1.4
1.5
2
3
4
4.1
Introduccin
311
Propsito
311
mbito
311
311
Referencias
311
Resumen Ejecutivo
311
Requerimientos de interfaz 311
Diseo de las interfaces de usuario 312
Otros aspectos a tomar en cuenta 312
Seguridad
312 4.2 Reportes
313 4.3 Rendimiento
313
4.4 Integracin con otro Software
313
167

12. Introduccin
Uno de los principales problemas en el desarrollo de software es el poco conocimiento
que se tiene de cmo unir la lgica del negocio con la forma en que se presentara
esta a los usuarios finales del software.
Se trata de prototipos que permiten al usuario hacerse una idea ms o menos
precisa de las interfaces que proveer el sistema y as, conseguir retroalimentacin
de su parte respecto a los requisitos del sistema, adems de esto definir como
disear las interfaces graficas de usuario y describir algunos problemas que se
deben tener en cuenta en el desarrollo de interfaces pero que van ms all del
alcance de este proyecto.
12.1.
Propsito
El propsito del presente documento es delinear las interfaces grficas de las

aplicaciones a desarrollar, documentando las pantallas y los flujos de navegacin
entre las mismas.
12.2.
mbito
[Proporciona una descripcin por escrito de a quin va dirigido este documento.]

12.3.

requeridas para interpretar apropiadamente el documento. Esta informacin puede
ser proporcionada por referencia al Glosario del proyecto.]
12.4.
Referencias
cualquier parte del Documento. Identifica cada documento por el nmero y nombre
de informe, (si aplica), fecha y organizacin que lo publica. Especifique las fuentes
de donde las referencias se pueden obtener. Esta informacin puede ser
proporcionada por referencia a un apndice o a otro documento.]
12.5.
Resumen Ejecutivo
[Esta seccin describe lo que el resto del Documento contiene y explica cmo el
mismo estar organizado.]
13. Requerimientos de interfaz

[Los requerimientos de interfaz son todos aquellos elementos que debe proveer el
sistema para permitir la interaccin entre el usuario y las funcionalidades que este
168
tiene, con el fin de que en el proceso de diseo se tenga claridad de las interfaces
que se deben crear y la relacin que debe existir entre ellas. Para la definicin de
los requerimientos de interfaz se deben identificar los siguientes elementos:
Id: Identifica de manera nica una interfaz grfica
Descripcin: Indica los elementos que debe tener la interfaz.
Requerimientos asociados: Indican las funcionalidades asociadas a la

interfaz grfica.
En este nivel, no se va definir de manera detallada la interfaz, solo se pretende

tener una primera aproximacin a los elementos que deben ser tenidos en cuenta
en el desarrollo de estas.]
14. Diseo de las interfaces de usuario

[Las pantallas deben permitir una forma de interaccin entre el usuario y todas las
funcionalidades que ofrece el sistema, cada una de ellas debe al menos presentar
una funcionalidad para que su creacin este justificada. Los elementos comunes
entre pantallas que se podran definir son:
Encabezado (Opcional)
Men (Opcional)
Zona de mensajes (error, xito)
Zona de Contenido
Hojas de estilo
Los elementos que se deben definir para cada pantalla son:
Informacin a presentar o recolectar
Validaciones
Relacin entre datos
Flujo de pantallas
Una prctica recomendable para verificar la completitud entre las pantallas

definidas y las funcionalidades del sistema es llenar una matriz y marcar la
interseccin entre una pantalla y una funcionalidad, indica que la pantalla
implementa esa funcionalidad.
Tomando en cuenta los aspectos anteriormente descritos, desplegar un pantallazo

de la interfaz que ha sido creada, describiendo por cada una los elementos a definir
y presentar.]
169
15. Otros aspectos a tomar en cuenta

15.1.
Seguridad
[Aspectos a tomar en cuenta en cuanto a la seguridad de acceso y control del

software]
15.2.
Reportes
[Aspectos a tomar en cuenta relacionados con los reportes que deben ser
desplegados o generados desde el software. Presentar algunos prototipos]
15.3.
Rendimiento
[Aspectos relacionados con el rendimiento que debe tener el software.]
15.4.
Integracin con otro Software
[En algunos casos, el nuevo desarrollo de software debe interfazarse con otros
sistemas, tomar en cuenta y detallar estos aspectos en este punto]
170
8.4.24 Plantilla Documento de Lecciones Aprendidas

Lecciones Aprendidas
Versin [1.0]
[Este plantilla tiene como finalidad ser la base para elaborar la lista de verificacin
de Lecciones Aprendidas.
Esta checklist se compone (genera y mantiene) por los aportes realizados por
todos los integrantes del grupo en la reunin quincenal y por las observaciones
realizadas por el Director de Proyecto en la reunin de evaluacin de Fase.
Los textos que aparecen entre parntesis rectos son explicaciones de que debe
contener cada seccin. Dichos textos se deben seleccionar y sustituir por el
contenido que corresponda. Para actualizar la tabla de Contenido, haga clic con el
botn derecho del ratn sobre cualquier lnea del contenido de la misma y
seleccione Actualizar campos, en el cuadro que aparece seleccione Actualizar toda
la tabla y haga clic en el botn Aceptar.
LAS SECCIONES PARA LAS QUE NO TENGA DATOS NO DEBE BORRARLAS; EN
DICHOS CASOS MRQUELAS CON N/A O SIN DATOS]
Historia de revisiones
Fecha
[dd/mm/aaaa]
Versin
[x.x]
Descripcin
[detalles]
Autor
[nombre]
171
ndice
1.
2.
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
2.10.
3.
3.1.
3.2.
Introduccin ....................................................................................................... 317

Por Disciplinas ................................................................................................... 317
Requerimientos ............................................................................................ 317
Diseo.......................................................................................................... 317
Implementacin ........................................................................................... 317
Verificacin ................................................................................................. 318
Implantacin ................................................................................................ 318
Gestin de Proyecto ..................................................................................... 318
Gestin de Configuracin y Control de Cambios .......................................... 318
Gestin de Calidad ....................................................................................... 318
Comunicacin .............................................................................................. 318
Formacin y Entrenamiento ...................................................................... 318
Otras lecciones ................................................................................................... 318
[Observaciones del Director] ........................................................................ 318
[otra lecc. 2] ................................................................................................. 318
172
1. Introduccin
Leccin Aprendida: Experiencia positiva o negativa obtenida durante la realizacin
de alguna actividad.
Se trata del registro de mejores prcticas, problemas
recurrentes o experiencias exitosas, durante la implantacin del proceso.
[El propsito de este documento es proveer de una herramienta que contenga el
conjunto de lecciones aprendidas durante el transcurso del proyecto, para ser
utilizada al momento de realizar la Planificacin de la Iteracin, o cuando se crea
oportuno]
Como la leccin aprendida es un conocimiento explcito que se obtiene como
resultado de un proceso de aprendizaje e involucra reflexionar sobre la experiencia,
es importante tener una gua que facilite su construccin. La leccin aprendida se
vuelve como un ejemplo ilustrativo, basado en la experiencia, que resulta aplicable
a una situacin general ms que a una circunstancia especfica. La leccin debera
contener los siguientes aspectos:
Tema de la leccin
Supuesto original, antes de que se tuviera esta experiencia
La nueva interpretacin o supuesto
1 o 2 ejemplos que confirman el nuevo supuesto
La forma en que se lleg a esta nueva percepcin
Por qu es importante la leccin
Para qu sirve la leccin
Quin es el autor de la leccin
Fecha de creacin de la leccin

Tambin, es importante definir un vocabulario comn para las lecciones,
dependiendo del contexto. Esto permitir eliminar hasta cierto punto la ambigedad
del lenguaje, precisando mucho ms la terminologa tcnica del dominio.
La siguiente lista de verificacin es actualizada (agregando, modificando y/o
eliminando tems, cada 15 das en la reunin de equipo).
2. Por Disciplinas
2.1. Requerimientos
[En las reuniones con el cliente considerar...]
[En las reuniones con el cliente siempre llevar...]
[Los nuevos requerimientos deben aprobarlos/evaluarlos...]
2.2. Diseo
[Usar siempre el patrn de diseo...]
[...]
173
2.3. Implementacin
[El plazo lmite para reportar las pruebas unitarias es...]
[No modificar los elementos de lnea base sin gestin de cambios...]

[Atencin al integrar modulo xxx con modulo yyy...]
[...]
2.4. Verificacin
[...]
[...]
2.5. Implantacin
[Verificar que el servidor de produccin cuenta con...]
[...]
2.6. Gestin de Proyecto
[Estimar las actividades de ... con una holgura de ...]
[...]
2.7. Gestin de Configuracin y Control de Cambios
[monitorear el correcto uso de los elementos de lnea base...]
[...]
2.8. Gestin de Calidad
[Chequear la coherencia entre los cronogramas de los planes de proyecto,

de verificacin y calidad...]
[...]
2.9. Comunicacin
[Por consultas tcnicas dirigirse a...]
[Por consultas del entorno del negocio dirigirse a ...]
Formacin y Entrenamiento
2.10.
[...]
[...]
3. Otras lecciones
3.1. [Observaciones del Director]
[Para futuras reuniones cambiar...]
174
[...]
3.2. [otra leccin. 2]
[...]
175
8.4.25 Plantilla Plan de Gestin de los Costos
<Proyecto>
<Plan de Gestin de los Costos> Versin
<1.1.0>
[Nota: Esta Plantilla tiene por finalidad servir de base para la confeccin
documentos o informes distintos a los definidos. El texto entre parntesis
Text se activa automticamente cuando se ingresan prrafos de texto definitivo.
Ninguno de los Campos definidos es obligatorio.]
Fecha
<aaaa-mm-dd>
Versin
1.1.0
Descripcin
Documento inicial
Autor
<Nombre>
176
ndice
1.
1.1
1.2
1.3
1.4
1.5
2.
3.
4.
1.9
1.10
320
Introduccin
322
Propsito
Alcance
Referencias
Resumen Ejecutivo
Tipos De Estimacin Del Proyecto 322
Costo de los Recursos
323
1.6 Esfuerzo de Trabajo por Fase
Control de Costos del Proyecto
Condiciones de Facturacin y Pago
Totales por Fases
Gastos Estimados
Fechas Reales de Cobranza
322
322
322
322
322
323
324
324 1.8
325
325
325
1.7
Ingresos
177
Plan de Gestin de los Costos

1. Introduccin
[El PMBOK propone muchas tcnicas para la estimacin de costos tales como
Estimacin por analoga, Estimacin par a mtrica, Estimacin ascendente, Anlisis
de reserva, Utilizacin de software de estimacin de costos para la direccin de
proyectos, etc. Dependiendo de las necesidades de la organizacin, se deben de
usar la tcnica ms adecuada para la estimacin de los costos del proyecto.]
1.1.
Propsito
El propsito de este documento es llevar el plan de gestin de los costes en los que
el proyecto va a incurrir. Para ello se identificarn los costes asociados a cada tarea
en funcin de los recursos utilizados.
[Detallar cualquier otro aspecto relacionado al Plan que se est definiendo]
1.2.
Alcance
[Proporciona una descripcin por escrito de a quin va dirigido este documento.]
1.3.

requeridas para interpretar apropiadamente el documento. Esta informacin puede
ser proporcionada por referencia al Glosario del proyecto.]
1.4.
Referencias
cualquier parte del Documento. Identifica cada documento por el nmero y nombre
de informe, (si aplica), fecha y organizacin que lo publica. Especifique las fuentes
de donde las referencias se pueden obtener. Esta informacin puede ser
proporcionada por referencia a un apndice o a otro documento.]
1.5.
Resumen Ejecutivo
[Esta seccin describe lo que el resto del Documento contiene y explica cmo el
mismo estar organizado.]
2. Tipos De Estimacin Del Proyecto

[Los tipos de estimacin a utilizar en el proyecto con indicacin del modo de
formulacin y los niveles de precisin de cada tipo.]
TIPO DE ESTIMACIN
MODO DE
FORMULACIN
NIVEL DE PRECISIN
178
[Especificar los tipos de
estimacin a usar en el
proyecto, ej. orden de
magnitud, presupuesto,
definitiva]
[Especificar en detalle el [Especificar el nivel de

modo de formulacin del precisin del estimado,
estimado indicando el ej. -15% +25%]
porqu, quin, cmo, y
cundo]
3. Costo de los Recursos

Esfuerzo de Trabajo por Fase
3.1.
[Se establece el porcentaje de tiempo que ser requerido cada uno de los recursos
humanos para cada una de las fases del proyecto] Se presenta un ejemplo:
Etapa
Duracin
Gerente
Project
Arquitecto
Semanas
Director
Director
Analista
Programador Programador
Pginas
Probador
Fbrica
Concepcin
0.50
5%
20%
100%
50%
50%
0%
Elaboracin
4.00
5%
20%
25%
0%
0%
50%
Construccin
2.50
5%
20%
50%
100%
100%
50%
Transicin
0.50
5%
20%
50%
100%
50%
50%
Total
5.00
0.38
1.50
3.00
3.25
3.00
3.50
TOTAL
7.50
Esfuerzo
Variacin
10
0.5
0.25
30
20
1.5
50
65
2.5
3.25
10
10
0.5
0.5
100
100
3.2.
Esfuerzo de Trabajo por Fase
[En esta rea se establece el esfuerzo porcentual de trabajo que estar asignado
cada uno de los recursos del proyecto]
Recurso
Horas
Precio
Total
Requeridas
UF/Hora
UF
Recurso 1
1.00
1.00
1.00
Recurso 2
1.00
1.00
1.00
Recurso3
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
179
1.00
Subtotal
1.00
6.00
6.00
0.6
0.60
6.60
6.60
Margen 10 %
Total
1.00
4. Control de Costos del Proyecto

[Ya una vez se encuentra el proyecto en desarrollo, se deben controlar los costos
estimados contra los costos reales que ha implicado] Se establece un ejemplo:
Fase CONCEPCION
Gerente
Project
Arquitecto
Gerente
Director
Analista
Pginas
TOTAL
Fabrica
Horas Planificadas
1.00
4.00
Horas Reales
0.00
0.00
0.00
0.00
0.00
0.00
Superavit/Deficit
1.00
4.00
20.00
10.00
10.00
45.00
Fase ELABORACION
20.00
Gerente
Project
Arquitecto
Director
Director
Analista
10.00
10.00
Pginas
45.00
TOTAL
Fabrica
Horas Planificadas
8.00
32.00
40.00
0.00
0.00
80.00
Horas Reales
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
Superavit/Deficit
8.00
Fase CONSTRUCCION
32.00
40.00
Gerente
Project
Arquitecto
Director
Director
Analista
50.00
Pginas
80.00
TOTAL
Fabrica
Horas Planificadas
5.00
Horas Reales
0.00
0.00
0.00
0.00
0.00
0.00
Superavit/Deficit
5.00
20.00
50.00
100.00
100.00
275.00
Fase TRANSICION
20.00
Gerente
Project
Arquitecto
Director
Director
Analista
100.00
100.00
Pginas
275.00
TOTAL
Fabrica
Horas Planificadas
1.00
4.00
10.00
20.00
10.00
45.00
Horas Reales
0.00
0.00
0.00
0.00
0.00
0.00
Superavit/Deficit
1.00
4.00
10.00
20.00
10.00
45.00
4.1.
Condiciones de Facturacin y Pago

Condiciones de
Facturacin y Pago
Fase
Porcentaje
Facturacin
Total a
Cobrar por
Hito
Hito 1
0%
Hito 1 faltante
0%
Fecha
Estimada de
Cobranza
180
Hito 3
Hito n
Total
0%
0%
0%
Supervit / Dficit del

Proyecto
4.2.
Fase
Concepcin
Elaboracin
Construccin
Transicin
4.3.
0.00
Ingresos Totales por Fases

Total
Total
Supervit/Dficit
Ingreso Egreso
Real
Real
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
Gastos Estimados
Proveedores/Fbricas
Egreso
Estimado
Egreso
Real
Concepcin
Elaboracin
Construccin
Transicin
4.4.
Fechas Reales de Cobranza

Fecha Real
de
Cobranza
Cobrado
Real
Cobrado
Acumulado
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
181
0.00
0.00
0.00

Planillas de RUP (Español)

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Planillas de RUP (Español)

Cargado por

Copyright:

Formatos disponibles

1

8.4.1 Plantilla Modelo de Casos de Uso del Negocio

[Nombre del proyecto] Modelo de

[Actor del Negocio 1]

[Descripcin del Actor 1 del Negocio]

[Actor del Negocio 2]

[Descripcin del Actor 2 del Negocio]

2. Casos de Uso del Negocio

Diagramas de Casos De Uso

[Caso de Uso del Negocio 1]

[Explicar brevemente el propsito del caso de uso del Negocio]

Flujo de eventos principal

Flujos de eventos alternativos

[Caso de Uso del Negocio 2]

3. Reglas del Negocio

[Regla del Negocio 1]

<Nombre del Proyecto>

de base para la confeccin del

[Esta seccin contiene o

[La definicin para <un grupo de

[Esta seccin contiene o

<Un segundo Grupo de Trminos>

[Esta seccin contiene o referencia

8.4.3 Plantilla Visin

<Nombre del Proyecto>

[Especifique el propsito de este documento de Visin.]

[Breve descripcin sobre el mbito del documento de Visin, que reas

Declaracin del Problema (OBLIGATORIO)

[principales involucrados por el problema]

El impacto del cual es

[cual es el impacto del problema]

[describa algunos beneficios claves que debe

Una solucin exitosa sera

[Esta seccin aplica en proyectos que implican el desarrollo de un nuevo producto o

El (nombre del producto)

es un [categora del producto]

[declaracin del beneficio clave,

3. Descripcin de Clientes, Stakeholders y Usuarios

Resumen de Stakeholders (OBLIGATORIO)

[Detalle a todos los stakeholders identificados.]

[Nombre del tipo

[Detalle a todos los usuarios identificados.]

4. Descripcin Global de la Solucin

Perspectiva del Producto de software

[Esta subseccin pone el producto de software a construir o modificar en perspectiva de

Caractersticas que lo permiten

[corresponden a los tems

[A travs de que caractersticas de

[Identifique los factores que afectan las caractersticas establecidas en el documento de

5. Caractersticas del Producto

9. Otros Requerimientos del producto

[Defina cualquier requerimiento de sistema que sea necesario para soportar la

[Detalle los requerimientos de entorno necesarios. Para sistemas basados en hardware,

[Describa el propsito y contenido del Manual de Usuario. Discuta sobre el tamao

Gua de Instalacin, Configuracin, y archivo Read Me

[Consiste en un documento que incluye las pautas de instrucciones de instalacin y

8.4.4 Plantilla Especificacin de Requerimientos de Software

<Nombre del Proyecto>

Especificacin de Requerimientos de Software

El propsito de este documento es capturar todos los requerimientos de software del

Definiciones, Acrnimos y Abreviaciones

[Prrafo obligatorio si existen trminos, definiciones acrnimos o abreviaciones.]

[Prrafo obligatorio si existen referencias.]