Pautas para documentar desarrollos de sistemas

Basado en el documento homnimo, versin 3, generado por el GCBA

(http://www.buenosaires.gov.ar/dgsinf/estandares/pautas_sistemas%203.0.zip)
Para agilizar el seguimiento de los proyectos de desarrollo de software, as como
para minimizar el impacto del futuro mantenimiento que estos sistemas puedan requerir, se
han fijado pautas para su documentacin, de modo que haya un aceptable grado de
uniformidad en todo el mbito de la Administracin Pblica Provincial.
La documentacin de un desarrollo de sistemas no se puede concebir como una
actividad aislada, sino como el resultado esperado de una metodologa de trabajo, de un
proceso con sus etapas y tareas en cada etapa. Por lo tanto, habr distintos documentos que
se irn generando en cada etapa.
Atentos a los desarrollos actuales en materia de Tecnologa de la Informacin y a
las tendencias del mercado, se permitir abordar la documentacin desde las dos estrategias
de desarrollo ms usuales, las denominadas Ciclo de vida Estructurado y Orientacin a
Objetos. Esta eleccin no supone negar que existan otros enfoques para el desarrollo de
sistemas que estamos dejando de lado, y que se podrn analizar en cada caso.
Ms all de que existen diversas metodologas, recomendamos la adopcin de la
Orientacin a Objetos, ya que este tipo de metodologa, adems de estar imponindose en
todos los desarrollos de un par de aos a esta parte, incorpora la idea del desarrollo
incremental con alta participacin de usuarios.
Lo que sigue es, entonces, una gua para la documentacin, confeccionada con el
objetivo de reunir, compatibilizar y sintetizar los planteos ms usuales de ambas metodologas
utilizando la terminologa ms habitual para cada una.
A continuacin describimos:

La documentacin que, al fin de cada etapa, deber entregarse segn la

metodologa de Ciclo de Vida Estructurado.

La documentacin que, al fin de cada etapa, deber entregarse segn la

metodologa de Orientacin a Objetos.

Algunas consideraciones sobre la actualizacin de la documentacin en relacin a

las tareas de mantenimiento de la aplicacin, luego de su puesta en produccin.

En todos los casos, la Direccin General de Gobierno Digital puede determinar que
cierta documentacin es optativa en un determinado proyecto, basndose en el tamao y
grado de complejidad del mismo.

Pg. 1 de 23

a.- Ciclo de vida estructurado

ETAPA

DOCUMENTACION

TAREAS

Definicin de
Requerimientos

Diagnstico de la situacin y necesidad del sistema

Deteccin de objetivos y
lmites del sistema y su
interaccin con el
ambiente

Modelo del Ambiente:

Declaracin de Propsitos
Diagrama de Contexto
Lista de Eventos o Catlogo de Requerimientos

En base a entrevistas con

usuarios

Glosario
Diagrama de Gantt del proyecto (preliminar)
Anlisis

Modelo de Comportamiento
Diagrama de Flujo de Datos
Especificacin de procesos
Diagrama Entidad Relacin
Diccionario de Datos
Diagrama de Transicin de Estados
Diagrama de Gantt del proyecto (actualizacin)

Diseo

Modelo del usuario

Formalizacin de objetivos,
independiente de la
naturaleza de la tecnologa
a aplicar y de cualquier
cuestin de implantacin
Determinacin de
entidades, con atributos e
interrelaciones
Determinacin de procesos

Eleccin del entorno

tecnolgico

Modelo del Procesador

oDiagrama de hardware
oJustificacin del entorno tecnolgico
Modelo de Tareas: Diagrama de Fronteras

Establecimiento de la
arquitectura de la
aplicacin
Diseo de Interfaces de
usuarios y procesos

Modelo de implantacin de programas: Diagrama estructurado

Interfaces de usuario: Prototipos de pantallas y reportes
Base de datos: estructura
Diagrama de Gantt del proyecto (actualizacin)
Desarrollo

Normas de programacin y estndares de nomenclatura

Implementacin

Esquema definitivo de la Base de Datos

Creacin base de datos

Cdigo fuente (con documentacin incorporada)

Codificacin e integracin
de mdulos

Diagrama de Gantt del proyecto (definitivo)

Testeo e instalacin

Cdigo fuente definitivo (con documentacin incorporada)

Pruebas unitarias

Documentacin sobre las pruebas realizadas

Pruebas de Integracin

Manual de Usuario

Carga de tablas de
configuracin

Pautas para migracin de datos

Manual de administracin y soporte tcnico
Descripcin general para el funcionario no informtico

Pg. 2 de 23

Migracin de Datos e
instalacin
Capacitacin si
corresponde

NOTA 1: Cdigo fuente incluye no slo las lneas codificadas en el lenguaje en que
se decida desarrollar la aplicacin, sino los posibles stored procedures, el cdigo que pudiera
estar embebido en formularios y cualquier pieza de software, local a la aplicacin y necesaria
para que sta funcione. Tambin se incluye el cdigo HTML, XML, ASP, JSP, PHP, o cualquier
otro usado en el desarrollo web.
NOTA 2: Todos los diagramas especificados se refieren a la notacin de Yourdon,
que se puede consultar en Anlisis estructurado moderno, de Edward Yourdon, Editorial
Prentice Hall, 1993, ISBN 9688803030. Tambin se puede ver en la web, en el sitio de
Yourdon, http://www.yourdon.com/strucanalysis/index.html (en ingls).

Pg. 3 de 23

b.- Breve descripcin de los documentos y diagramas

1. Diagnstico de la situacin y necesidad del sistema (Objetivos):
Tiene que ser una descripcin somera de la situacin actual y las mejoras que
traer la implementacin del sistema. Como a veces en esta etapa se decide que no es
necesario hacer un desarrollo, o que se va a reutilizar uno existente, hay que explicar por qu
es necesario el desarrollo en cuestin. Si se trata de un mantenimiento de un sistema
existente, se deber explicar por qu es necesario y cules son las contras de no hacerlo.
Por ejemplo:
Actualmente, la Secretara de Educacin no cuenta con una forma confiable de obtener
estadsticas de alumnos de las escuelas de la ciudad. Una de las causas que hace que las
estadsticas no sean confiables proviene del hecho de que numerosos alumnos se inscriben
en ms de una escuela y no hay una base de datos nica que permita detectar esta
situacin. Por otro lado, los mtodos manuales utilizados impiden saber si los criterios
utilizados en todos los relevamientos son los mismos. Adems, la obtencin de datos actual
es muy costosa en trminos econmicos y de tiempo. Por todas estas consideraciones, se ha
decidido desarrollar la Base nica de Datos de Alumnos, que va a permitir uniformizar
criterios y mantener la informacin centralizada.

2. Modelo ambiental:
Este modelo define la frontera del sistema describiendo sus lmites y alcances.
Definido qu queda en el interior y qu en el exterior del sistema, se deben definir
los estmulos (mensajes, acciones de usuarios u otros sistemas, etc.) del exterior a los que el
sistema responde, as como las interfaces de ese intercambio. Utiliza:
2.1 Declaracin de propsitos: Es una descripcin textual, breve y concisa del
propsito del sistema, de no ms de un prrafo. Debe incluirse la enumeracin de los
beneficios tangibles y cuantificables que se lograrn con el nuevo sistema. Si se trata de un
sistema existente que se va a modificar, debe quedar claro en este documento. El empleo de
trminos que hacen a la especificidad del negocio puede requerir que se le asocien notas
explicativas.
Por ejemplo:
La Base nica de Datos de Alumnos deber permitir el almacenamiento de los todos los
datos de alumnos que hoy manejan las escuelas de la ciudad, tanto de gestin
gubernamental como privada, incluyendo las calificaciones e informacin de presentismo.
Este sistema permitir obtener estadsticas que hacen a la gestin de la Secretara de
Educacin, que hoy deben realizarse con mtodos manuales, a la vez costosos e imprecisos,
adems de centralizar en una nica base de datos la informacin de alumnos de toda la
ciudad.

2.2 Diagrama de contexto: Muestra en forma detallada las distintas interfaces

con el ambiente; grafica las personas, organizaciones, mquinas o sistemas con los que el
nuevo sistema se comunica, as como los datos que recibe y produce. Debe recordarse que es
una herramienta que debe permitir una comprensin con un golpe de vista.
nivel 0):

A continuacin se muestra un diagrama de contexto (algunos lo llaman DFD de

Pg. 4 de 23

En el mismo, el sistema se representa como un crculo en el centro, y las entidades

externas son rectngulos que lo rodean, con las interacciones entre ambos representadas por
flechas. Debe recordarse que debe ser entendido por el usuario, por lo que los trminos deben
ser afines a su vocabulario.
2.3 Listado de eventos: Es especialmente importante en sistemas interactivos, no
justificndose su aplicacin en desarrollos batch. Es un listado de estmulos que ocurren en el
ambiente a los cuales el sistema debe responder; debe incluir situaciones de fallo o error de
los agentes que estimulan al sistema. Puede reemplazarse con el catlogo de requerimientos.
2.4 Catlogo de requerimientos: Incluye los requerimientos, tanto funcionales
como de cualquier otro tipo, que pudieran haberse detectado en las entrevistas con usuarios.
Este documento suele ser un texto escrito en los trminos de los usuarios, con posibles
aclaraciones que hagan al lenguaje de los desarrolladores. Dicho en forma coloquial, es como
el pasaje en limpio y en forma organizada de las entrevistas con los usuarios. Puede
reemplazarse por el listado de eventos recin descripto.

3. Glosario:
Es una descripcin de trminos que hacen al negocio, cuya comprensin es
necesaria por parte de diseadores y programadores, y tiene la forma de un diccionario,
poniendo los trminos y sus significados. Esto a veces no es necesario, ya sea porque los
trminos son lo suficientemente corrientes o porque ya hubieran sido explicados en otros
documentos.

4. Diagrama de Gantt del proyecto:

Debe hacerse el plan de trabajo del proyecto en forma de Diagrama de Gantt o
similar, que luego se ir actualizando al final de cada etapa.

5. Modelo de comportamiento:
Define el comportamiento del sistema para manejarse con xito en el ambiente.
Ese comportamiento se establece tomando como unidad cada una de los estmulos de la Lista
de Eventos ya comentada.
Incluye el contenido de los datos que el sistema almacena y que se mueven a
travs de l.
Se traduce en:

Pg. 5 de 23

5.1 Diagrama de Flujo de Datos (DFD):

Es un diagrama que muestra los procesos y los flujos de datos entre los mismos. Se
lo llama tambin diagrama de burbujas. Es fundamental cuando las funciones o procesos son
ms importantes que los datos.
Debe caber en una pgina y no tener ms de 6 burbujas. Si no, hay que nivelarlo
en ms diagramas.
En esta etapa se trata de un diagrama preliminar, que se ir actualizando.
A continuacin hay un DFD de ejemplo:

Las burbujas son los procesos, los rectngulos almacenamientos de datos y las
flechas representan los flujos de informacin. ste es otro diagrama para interactuar con
usuarios, por lo que tambin deben usarse trminos de su dominio.
5.2 Especificacin de procesos:
Es la especificacin de los procesos que se diagraman en el DFD. De todas
maneras, slo tiene sentido realizarlo cuando los procesos tengan cierta complejidad.
En una versin preliminar, la especificacin se puede hacer con tablas de decisin,
de modo de no condicionar el diseo futuro. Los refinamientos sucesivos llevarn esta
especificacin a lenguaje estructurado o pseudocdigo.
Una tabla de decisin es una tabla de doble entrada como la que sigue, que
muestra 5 casos distintos en funcin de valores de diferentes variables:

Emisor responsable inscripto

Emisor responsable no inscripto
Emisor exento
Receptor responsable inscripto
Receptor responsable no inscripto
Receptor consumidor final
Receptor exento
21% en fact A
Pg. 6 de 23

IVA a aplicar
1
2
3
X
X
X

X
X
X
X
X
X

X
X
X
X

X
X
X
X
X

31,5% en fact A
21% en fact B
0% en fact C

X
X
X

El pseudocdigo equivalente sera algo as:

Si emisor es responsable inscripto
Si receptor es responsable inscripto
Factura A
IVA <- 21%
Si receptor es responsable no inscripto
Factura A
IVA <- 31.5%
Si receptor es consumidor final
Factura B
IVA <- 21%
Si emisor es responsable no inscripto o exento
Factura C
IVA <- 0%
Fin
5.3 Diagrama de Entidad Relacin (DER):
Describe la distribucin de datos en un sistema. Es fundamental en sistemas
centrados en datos. No es necesario si el sistema tiene poco o ningn acceso a bases de datos,
como algunos sitios web.
Lo que sigue es un DER simple, a modo de ejemplo:

En un DER, los rectngulos son tipos de objetos y los rombos relaciones.

5.4 Diccionario de datos:
Define de manera formal los datos del sistema.

Pg. 7 de 23

Como con los diagramas, es importante seguir una notacin, como la de Yourdon,
de modo que la documentacin sea comprensible por cualquier potencial lector.
A continuacin se muestra un diccionario de datos elemental (la primera lnea
muestra una composicin e iteracin, la segunda slo una composicin, la tercera una
especificacin de rango y la cuarta una seleccin entre dos posibilidades):
Factura = cliente + direccin + { tem de factura }
Cliente = nombre + DNI
DNI = rango 0 a 30.000.000
Direccin = [domicilio laboral | domicilio particular]
5.5 Diagrama de Transicin de Estados (DTE):
Muestra los cambios de estado de los datos del sistema o de una parte del mismo.
Es importante en sistemas reactivos (los que suelen estar inactivos mientras no reciban
estmulos externos), con eventos, o para mostrar la vida de un objeto o cmo es afectado un
objeto en un determinado escenario. Hay casos de sistemas o procesos en los cuales los DTE
no aportan informacin.
A continuacin se muestra un DTE simple de un contestador telefnico:
Inactivo

Esperando llamada

Grabando mensaje

Rebobinando

Reproduciendo
mensaje

Contestando
llamada

En un DTE, las elipses son estados y las flechas transiciones entre los mismos.

6. Modelo del procesador:

Es lo que permite pasar del modelo de anlisis a los distintos componentes de
hardware, con sus comunicaciones. Habr que incluir un diagrama de hardware, en el cual se
muestre el hardware sobre el que se implementar el sistema, y una justificacin de la eleccin
del entorno tecnolgico, en la cual se explican las consideraciones que se hicieron para elegir
dicho hardware.
A continuacin se muestra un diagrama de hardware, en el cual se detallan qu
procesos se realizan en cada procesador:

Pg. 8 de 23

7. Modelo de tareas:
Se puede resumir en un Diagrama de Fronteras, que indique en forma grfica los
componentes del hardware y las tareas que se hacen en cada uno de ellos. Es importante para
dar una idea general con un simple vistazo. En general, este es un diagrama importante en
sistemas distribuidos, de arquitectura de varias capas o aqullos en los cuales haya que
mostrar claramente la frontera con otros sistemas de informacin. De no ser as, se podra
omitir, quedando el diagrama de contexto, el diagrama de hardware y los DFDs como
sucedneos.
Vanse el siguiente diagrama de fronteras de ejemplo:

8. Modelo de implantacin de programas

Organizacin jerrquica de mdulos en una tarea. Se realiza con un Diagrama
estructurado.

Pg. 9 de 23

A continuacin hay un diagrama estructurado de ejemplo:

El diagrama estructurado no es apto para mostrar el comportamiento de sistemas

basados en eventos o reactivos. En estos casos conviene pasar directamente a diagramas en
UML u otra notacin OO.

9. Interfaces de usuario
Se especifican con prototipos de las interfaces de usuario y reportes. stas pueden
consistir en dibujos o bocetos que muestren cmo van a ser las interfaces, aun cuando luego
estos sean modificados luego.
A continuacin hay un prototipo de pantalla:

Pg. 10 de 23

10. Esquema de la Base de Datos

A continuacin se muestra uno:

1) Listado de proyectos disponibles

2) Datos del proyecto seleccionado
3) Obras pertenecientes al proyecto seleccionado
...

11. Cdigo fuente con documentacin incorporada

La documentacin incorporada se refiere a la documentacin embebida en el cdigo.
Tambin deben documentarse las configuraciones que se deban hacer en la mquina
de desarrollo para que esos fuentes corran, como directorios especiales, variables
de entorno, DLLs y dems.

12. Documentacin sobre las pruebas realizadas

Debe incluir una descripcin de la metodologa de pruebas (centradas en verificacin
o en validacin, de caja blanca o de caja negra, lotes de prueba, revisiones de
cdigo, pruebas unitarias, de integracin, de sistema y de aceptacin).

13. Manuales
Manual de procedimientos del usuario:
informacin sobre tutoriales y ayudas en lnea.

puede

reemplazarse

por

Pautas para la migracin de datos, si la hubiese

Manual de administracin y soporte tcnico: Es necesario que tenga una

descripcin de los errores posibles del sistema, as como los procedimientos de
recuperacin ante fallas y una gua de los problemas ms comunes que se pueden
plantear.
Descripcin general para el funcionario no informtico: puede ser un
simple diagrama que indique la funcionalidad general del sistema y su despliegue en
los distintos componentes de hardware, pero escrito en trminos lo ms corrientes
que sea posible.

Pg. 11 de 23

c.- Orientacin a objetos

Debe tenerse especialmente en cuenta que las metodologas de orientacin a
objetos no se basan en un enfoque algortmico tradicional. Son metodologas dirigidas por
casos de uso, centradas en la arquitectura, iterativas e incrementales.
Todas las etapas se entienden
(por ejemplo, se comienza el testeo
realimentacin a etapas anteriores (por
producen reajustes en la especificacin de

como consecutivas pero parcialmente superpuestas

antes del fin de toda la programacin) y con
ejemplo, durante el diseo y la programacin se
funcionalidades).

Por lo tanto, las pautas para documentar se han fijado en funcin de las fases,
utilizando la divisin en fases del Proceso Unificado de Desarrollo de Software.

FASE

DOCUMENTACIN

TAREAS

Inicio

Diagnstico de la situacin y necesidad del sistema

Deteccin de objetivos y lmites del

sistema y su interaccin con el
ambiente

Aspectos funcionales:

Declaracin de propsitos

Despliegue tentativo

Diagrama de Contexto

Listas de casos de uso y actores, con

diagramas de casos de uso

Planificacin de las iteraciones en

que se ir construyendo el sistema

Glosario

Aspectos Tecnolgicos:

Elaboracin

Diagrama de despliegue tentativo

Diagrama de Gantt del proyecto

Aspectos funcionales

Diagrama de la base de datos

Modelo de casos de uso para los ms

importantes: lista y descripcin de casos de
uso, con sus diagramas de actividades, de
interaccin o de estado, si corresponde

Diagrama de clases conceptual (parcial),

esquemtico y con responsabilidades

Aspectos no funcionales:

Construccin

Justificacin del entorno tecnolgico

Prototipos de pantallas y reportes

Diagrama de componentes mostrando la

arquitectura

Prioridades de los casos de uso descriptos

Normas de programacin y estndares de

nomenclatura

Aspectos funcionales

Formalizacin de requisitos de
escalabilidad, disponibilidad,
seguridad, mantenimiento y
desempeo.

Descripcin detallada de los casos

de uso ms importantes.
Priorizacin de los mismos.
Determinacin de las clases de
anlisis (parcial), a partir de los
participantes de los casos de uso
descriptos. Descripcin de su
comportamiento.
Determinacin de las interfaces de
usuario para cada caso de uso
descripto.
Establecimiento de la arquitectura
de la aplicacin. Determinacin de
las clases de arquitectura ms
importantes.
Diseo de la base de datos.
Determinacin de las normas de
programacin y estndares de
nomenclatura.
Descripcin detallada de los casos
de uso restantes. Priorizacin de
los mismos.

Modelo de casos de uso para los restantes:

lista y descripcin de casos de uso, con sus
diagramas de actividades, de interaccin o
de estado, si corresponde

Diagrama de clases completo

Diagramas de comportamiento en los casos

necesarios: de estados y de interaccin

Determinacin de las clases de

anlisis restantes, a partir de los
participantes de los casos de uso
descriptos. Descripcin de su
comportamiento.

Cdigo fuente (con documentacin

Determinacin del resto de las

Pg. 12 de 23

incorporada)

Documentacin sobre pruebas realizadas

Esquema definitivo de la base de datos

Aspectos no funcionales:

Transicin

clases de arquitectura y
descripcin del comportamiento.
Diseo de las interfaces de
usuario.
Creacin de la base de datos.

Prioridades de los casos de uso restantes

Codificacin.

Prototipos de las interfaces de usuario

Diagrama de despliegue y componentes

definitivo

Realizacin de pruebas parciales y

de integracin.

Manual de Usuario

Pautas para migracin de datos

Manual de administracin y soporte tcnico

Descripcin general para el funcionario no

informtico

Actualizacin de toda la documentacin que

sea necesario actualizar

Pruebas de sistema y de
aceptacin

Cargas de tablas de configuracin

Migracin de Datos

Afinacin

NOTA 1: Cdigo fuente incluye no slo las lneas codificadas en el lenguaje en que
se decida desarrollar la aplicacin, sino los posibles stored procedures, el cdigo que pudiera
estar embebido en formularios y cualquier pieza de software, local a la aplicacin y necesaria
para que sta funcione. Tambin se incluye el cdigo HTML, XML, ASP, JSP, PHP, o cualquier
otro usado en el desarrollo web.
NOTA 2: Todos los diagramas especificados se refieren a la notacin UML, que se
puede consultar en UML gota a gota, Martin Fowler, Editorial Addison Wesley, 1999, ISBN
9684443641. Tambin se recomiendan los libros sobre UML (El lenguaje unificado de
modelado) escritos en conjunto por Booch, Rumbaugh y Jacobson.
NOTA 3: El Proceso Unificado de Desarrollo de Software, que no necesariamente se
recomienda, pero del cual se ha extrado la divisin en fases, puede consultarse en El Proceso
Unificado de Desarrollo de Software, Ivar Jacobson, Grady Booch, James Rumbaugh, Editorial
Addison Wesley, 2000, ISBN 8478290362.
NOTA 4: Un buen curso de UML puede obtenerse en la Web, en castellano, en
http://www.dsic.upv.es/~uml/, tanto como presentacin PowerPoint como en formato PDF.

Pg. 13 de 23

d.- Breve descripcin de los documentos y diagramas

1. Documentos similares a los de la metodologa estructurada
Hay algunos elementos que no cambian por utilizar una metodologa OO. Por lo
tanto, su descripcin puede encontrarse ms arriba, en la metodologa estructurada. stos
son:

Declaracin de propsitos.

Diagrama de contexto (aunque puede hacerse con un diagrama de casos de uso,

que veremos luego).

Glosario.

Especificacin de procesos con tablas de decisin (aunque tambin puede hacerse

con diagramas de interaccin, los que veremos luego).

Diagrama de Gantt o similar.

Justificacin del entorno tecnolgico.

Prototipos de pantallas y reportes.

Normas de programacin y estndares de nomenclatura.

Documentacin sobre las pruebas.

Manual del usuario.

Manual de administracin y soporte tcnico.

Descripcin general para el funcionario no informtico.

2. Modelo de casos de uso:

Es una lista de los casos de uso, con sus descripciones, incluyendo flujos
alternativos, requisitos funcionales y no funcionales, pre y postcondiciones, algn diagrama de
actividades o de interaccin si fuera necesario para aclarar el flujo de control y los
participantes (que se utilizarn para encontrar las clases de anlisis).
A continuacin se muestra una ficha tpica de un caso de uso:
Nombre de Caso de Uso:

Actualizaciones:

AUTENTICACIN DE USUARIO

Original Juan Prez 17/6/2003

Actores:
Prioridad: Alta.

Todos
Descripcin:

El usuario se conecta al sistema. Ingresa su nombre de usuario y contrasea. El sistema lo identifica e ingresa a
su entorno.
Flujos alternativos:
El nombre de usuario no es vlido, se informa al usuario y se blanquean los campos.
La contrasea no es vlida, se informa al usuario y se blanquean los campos.
El usuario ya se encuentra usando el sistema, se informa al usuario y se blanquean los campos.
Requisitos no funcionales:
El sistema no puede tardar ms de 30 segundos en autenticar a un usuario.

Pg. 14 de 23

Precondiciones:
Ninguna
Postcondiciones:
El usuario tiene una sesin abierta en el sistema.
Se rechaza la solicitud.
Diagrama de Actividades:
No es necesario.
Participantes:
Usuario, Base de datos de usuarios autenticados.
Clases de anlisis, responsabilidades, atributos:
A rellenar luego.
Prototipos de IU y reportes:
No es necesario especificarlos en este caso.

3. Diagramas de casos de uso:

Se usan para modelar:

especificaciones de servicios

contexto del sistema

capturan requerimientos funcionales

tiles en la interaccin con el usuario

El que sigue es un diagrama de casos de uso:

Pg. 15 de 23

En el diagrama, los actores se representan como un esquema de persona, los casos

de uso como elipses y las comunicaciones con lneas. Los actores pueden ser cualquier entidad
externa, incluyendo otros sistemas.

4. Diagramas de actividades:
Se usan para modelar:

flujos de procesos

especificacin de comportamiento de alto nivel

especificacin de algoritmos

mostrar actividades concurrentes

mostrar distintos agentes u objetos en un flujo

generar casos de prueba

Vase el diagrama de actividades presentado en la prxima pgina.

Pg. 16 de 23

Cliente

Cajero

Inserta
tarjeta

Pide clave

Ingresa
clave

Chequea
clave

Banco

[clave incorrecta]
[clave correcta]

Pide monto
Chequea
saldo

Procesa
transaccin

Retira dinero

Entrega
dinero

[saldo >=
monto]

Debita
cuenta

[saldo <
monto]
Muestra
saldo

Retira tarjeta

Expulsa
tarjeta

Los objetos se representan por calles en sentido vertical (slo en el segundo de

los diagramas), y cada estado por el que van pasando por rectngulos redondeados. Las
flechas representan transiciones de estados. Hay nodos especiales para representar el
comienzo y fin de la actividad, as como rombos que representan ramificaciones, con el mismo
significado que tenan en los antiguos diagramas de flujo.

Pg. 17 de 23

5. Diagramas de interaccin:
Se usan para modelar:

cmo un escenario puede ser realizado a travs de un conjunto de

mensajes entre objetos

ayudan a encontrar las operaciones (mtodos) de las clases

distintos objetos trabajando en conjunto

mensajes asncronos

Para ello existen:

Diagrama de colaboracin: enfatiza relaciones estructurales entre objetos

Diagrama de secuencia: enfatiza el paso del tiempo o el ciclo de vida de los

objetos

Pg. 18 de 23

Ambos diagramas son semnticamente equivalentes, es decir, se puede reemplazar

uno por el otro sin prdida de informacin. En el de colaboracin, el paso del tiempo est
representado por nmeros asociados a los mensajes. Los mensajes, en ambos casos, se
representan con flechas, y los objetos con rectngulos, cuyo nombre se subraya. El diagrama
de secuencia muestra el ordenamiento temporal mediante un eje vertical, representando la
lnea de vida de los objetos. En ambos es factible representar iteraciones, concurrencia,
mensajes sncronos y asncronos, as como la muerte de un objeto.

6. Diagramas de estado:
Se usan para modelar:

comportamiento complejo de los objetos

estados concurrentes

pruebas de caja blanca

A continuacin hay un diagrama de estados que muestra el juego del ajedrez:

/ Juegan las blancas

Turno de las blancas

Turno de las negras

/ Juegan las negras

/ Jaque mate

/ Tablas

/ Jaque mate
/ Tablas

Ganan las negras

Ganan las blancas

Un diagrama de estados est compuesto por nodos y los arcos, ms un nodo

especial para indicar el comienzo y otro para indicar la finalizacin. En los nodos y los arcos se
pone una descripcin del estado o evento que corresponda.
Dentro del nodo que corresponde a cada estado se puede poner un texto adicional
que especifique si el objeto se encuentra realizando alguna accin. Asimismo, en la descripcin
de las transiciones se puede poner una condicin que se deba satisfacer, entre corchetes, o
incluso parmetros que acompaen al evento.

7. Diagramas de clases:
Se usan para modelar:

la visin esttica de todo el sistema

vocabulario de dominio del problema (sin operaciones)

clases de anlisis con responsabilidades

clases de diseo (con atributos y operaciones)

estructura de la base de datos

analizar acoplamiento entre clases y paquetes

Pg. 19 de 23

Lo que sigue es un diagrama de clases de ejemplo:

1

cSistemaInscripcion

cPersona
*

cCurso

+PantallaInscripcion()
+ElegirCurso()

cDocente

cAspirante

+ChequearCorrelativas()
+InscribirAlumno()

+ConsultarOpinion()

+NotificarAlumno()

cProfesor
1

+ConsultarOpinion()

cCoordinador
+ConsultarOpinion()

1
1

cCurriculaAlumno
+ConsultarCurricula()

Las clases son rectngulos, con divisiones para el nombre de la clase, los atributos
y los mtodos. Las asociaciones entre clases se representan con lneas, mientras las jerarquas
de herencia con flechas dirigidas hacia la clase ancestro. Se pueden especificar roles,
multiplicidad y grados de visibilidad.
De todas maneras, es importante recordar que un diagrama de clases debe ser
simple y orientado a mostrar no ms de un tipo de relacin (herencia, asociacin o
colaboracin). Por lo tanto, lo ideal va a ser separar los diagramas que muestren las jerarquas
de las clases de los que muestren las asociaciones.
Un diagrama de clases se puede hacer tambin en forma ms esquemtica en las
primeras etapas del desarrollo. A continuacin se muestra un diagrama de clases conceptual,
en el que no se indican atributos, mtodos ni relaciones de herencia:
cPedido

cCliente
*

+Artculos de lnea

cLineaDePedido

8. Diagramas de componentes y despliegue

Se usan para modelar el despliegue de los distintos componentes de software sobre
el hardware.
A continuacin se muestra un diagrama de despliegue con sus componentes:

Pg. 20 de 23

Cada cubo representa un nodo de hardware, y las lneas que los unen son
conexiones. Dentro de cada nodo se han representado componentes software, que son
rectngulos con bisagras, que a menudo implementan una interfaz, representada con crculo
pequeo. Las dependencias se representan con flechas discontinuas.

Pg. 21 de 23

e.- Sobre el mantenimiento de la aplicacin luego de su puesta en

produccin
Denominamos mantenimiento a las tareas de correccin de errores, evolucin por
cambio de requerimientos y preservacin para mantener operable un sistema, una vez que se
encuentra en produccin.
El mantenimiento debe incluir siempre la actualizacin de la documentacin
asociada, amn de mantener la documentacin de versiones anteriores.
Los procesos de modificacin pueden variar en su grado de complejidad, desde
correcciones de errores pequeos hasta cambios funcionales que impliquen la inclusin de
nuevos procedimientos o funciones; a continuacin se presenta una lista de eventos que
derivan en procesos de modificacin:

Identificacin de errores (bugs) de programas.

Necesidad de adicionar nuevas caractersticas o capacidades.

Cambios de requerimientos funcionales.

Aumento / disminucin en el mbito de aplicacin del sistema.

Adaptaciones por cambios en el entorno operativo del mismo.

Ms all del tipo de cambio (correctivo ante errores, adaptativo a cambios en el

entorno del funcionamiento de la aplicacin o perfectivo, ya sea en funcionalidad o afinacin),
importa su grado de impacto. Y ello determinar el nivel de documentacin de respaldo
necesario.
Para la resolucin de errores que no afecten la estructura modular de las
aplicaciones y para cambios estticos en las interfaces de usuario (tipo de letras, color), como
ejemplo, ser suficiente habilitar un Anexo a la Documentacin, el Registro de Modificaciones.
El Registro contendr, para cada modificacin, fecha del pedido, solicitante, descripcin del
cambio, fecha de concrecin y versin en la que es incluido.
Los cambios funcionales (agregado de nueva funcionalidad o modificacin en las
caractersticas de la que el sistema ya provee) implican, para su concrecin, un volver a
recorrer las etapas de desarrollo de la aplicacin; por consiguiente, y en forma paralela a su
realizacin, esos cambios impactarn en la documentacin, desde la que refleja el anlisis de
requerimientos hasta el Manual del Usuario. Por ello nuevas versiones de la documentacin
acompaarn las nuevas versiones de la aplicacin.
Es factible que estos cambios impliquen tambin cambios estructurales. Los
cambios estructurales darn lugar a nuevas versiones de los modelos que reflejan las
estructuras de datos, desde el Diccionario de Datos o Diagrama de Clases al Esquema
definitivo de la Base de Datos. Si impactasen en el diseo de pantallas o la funcionalidad, el
cambio se reflejar tambin en el Manual del Usuario. No se reflejar en la documentacin
para el usuario todo aquello que no impacte en su forma de uso del sistema, como, por
ejemplo, optimizaciones.
Los cambios en el entorno tecnolgico se reflejarn en la documentacin que alude
al entorno tecnolgico.
En cualquier caso se deber generar una nueva versin del cdigo fuente, con el
respectivo nmero de versin, que tambin forma parte de la documentacin.

Pg. 22 de 23

f.- Forma de entregar la documentacin

Cuando deba entregarse, la documentacin se presentar en CD.
Los formatos de los archivos a entregar debern ser alguno de los siguientes:

Texto puro: extensin .TXT, o la extensin que corresponda en el caso de ser cdigo
fuente.

Documentacin textual: preferentemente en PDF, de otra manera Microsoft Word

(.DOC) u OpenOffice (.ODT).

Planillas de clculo y tablas: Microsoft Excel (.XLS) u OpenOffice (.ODS)

Presentaciones: Microsoft Powerpoint (.PPT) u OpenOffice (.ODP)

Diagramas: Microsoft Visio Drawing (.VSD), Dia (.DIA), OpenOffice (.ODG) u otro
formato vectorial, pero preferentemente envindolo tambin en PDF.

Si se envan archivos compactados, se utilizar un formato estndar, como zip o

tar.gz.

El cdigo fuente debe entregarse tambin en CD, con la estructura de directorios o

carpetas con que est implementado, de modo de garantizar que se pueda chequear antes de
dar la aprobacin. Tambin deben documentarse las configuraciones que se deban hacer en la
mquina de desarrollo para que esos fuentes corran, como directorios especiales, variables de
entorno, DLLs y dems.

Pg. 23 de 23