Apuntes Diseno Sistemas

Academia de Computacin
Centro de Estudios Tecnolgicos Industrial y de Servicios

No. 49
Apuntes de Diseo de
Sistemas
Ing. Edgar Paredes Basilio
Apuntes de Diseo de Sistemas

Elaboro: Ing. Edgar Paredes Basilio
ndice
UNIDAD 1 Introduccin
1.
Etapas en el desarrollo de sistemas de informacin
2.
Modelos de sistema
3.
Herramientas informticas utilizadas en cada etapa
Herramientas de escritorio
Herramientas CASE
1. Definicin
2. Objetivos del CASE
3. Repositorio de datos
4. Clasificacin de las herramientas CASE
5. Software CASE
10
4.
Problemas en el desarrollo de software
11
5.
Bibliografa
12
UNIDAD 2 Calidad del Software

6.
Definicin
13
7.
Uso de Estndares y su importancia
13
Definicin
13
Ventajas
13
Factores de calidad
14
Exactitud
14
Fiabilidad
14
Eficacia
14
Integridad
14
Testeabilidad
14
Flexibilidad
14
Mantenibilidad
14
Reutilizacin
15
Interoperabilidad
15
Tabla resumen
15
Garanta de Calidad del Software (SQA)
15
8.
9.
10. Actividades de SQA
15
Aplicacin de mtodos y tcnicas
15
Realizacin de Revisiones Tcnicas Formales (RTF)
16
Prueba del software
16
ndice Temtico
Pg.: 1 de 98
Ultima actualizacin: 03/2002

Ajuste a estndares
16
Control de cambios
16
Mediciones
16
Registro y realizacin de informes
16
11. Revisiones Tcnicas Formales
16
Objetivos de la RTF
17
La reunin de revisin
17
Pasos de la RTF
17
12. Ventajas y desventajas de la SQA
18
Ventajas
18
Desventajas
18
13. Bibliografa
18
UNIDAD 3 Diseo de Sistemas

14. Qu se entiende por Diseo de Sistemas?
19
15. Modelo de Implementacin
20
16. Fundamentos del Diseo
20
17. Requerimientos No Funcionales
21
Requerimientos de rendimiento
22
1. Tiempo de respuesta
22
2. Orden alternativo
23
Cumplimiento de Estndares
23
Limitaciones de Hardware
24
Operaciones
25
Requerimientos de adaptacin a diferentes instalaciones
25
1. Parametrizacin
25
2. Multiplataforma
25
Impacto en la Organizacin
26
UNIDAD 4 Modelo de Tecnologa

18. Qu se entiende por Modelo de Tecnologa?
27
19. Componentes del modelo
28
Tecnologa en produccin (necesaria para implementar el sistema)
28
Tecnologa para desarrollo (necesaria para desarrollar el sistema)
30
ndice Temtico
Pg.: 2 de 98

UNIDAD 5 Modelo Fsico de Datos

20. Modelo Fsico de Datos
31
21. Definicin:
31
22. Pautas generales:
31
Codificar lo mximo posible
31
Numeraciones / codificaciones internas
31
Datos de clculo
31
Creacin de ndices
31
Campos para parametrizacin
31
Permisos
31
Funciones provistas por los motores de bases de datos
32
UNIDAD 6 Modelo Fsico Externo o del Usuario

23. Pautas Generales
33
Tipos de usuarios
33
Niveles de conocimiento del Usuario
36
Roles de los usuarios
36
24. Diseando en Windows
37
Controles de Windows
38
25. Orientacin a Eventos
39
Particularidades
39
Cmo funciona una aplicacin controlada por eventos?
39
Diseo de pantallas
39
1. Objetivos medibles en un diseo de interfaces
39
2. Reglas tiles para el diseo de interfaces
40
3. Prevencin de errores
40
Herramientas de trabajo
41
Bosquejo de pantallas y descripcin de procesos
41
Diagrama de Transicin de Estados (DTE)
41
Diagrama de Interaccin (DI)
42
26. Diseo de la ayuda
42
UNIDAD 7 Modelo Fsico Interno o de Programas

27. Definicin
44
44
29. Acoplamiento
44
ndice Temtico
Pg.: 3 de 98

Acoplamiento de datos
45
Acoplamiento de estructura de datos
45
Acoplamiento de control
46
Acoplamiento comn
46
Acoplamiento de contenido
47
Observaciones importantes
47
30. Cohesin
47
Cohesin funcional
48
Cohesin secuencial
49
Cohesin comunicacional
49
Cohesin procedural
50
Cohesin temporal
50
Cohesin lgica
51
Cohesin coincidental
51
31. Herramienta: Diagrama de Composicin
52
5.
53
Bibliografa
UNIDAD 6 Prueba del Software

32. Introduccin
54
33. Conceptos bsicos
54
Definicin
54
Objetivos de la prueba
54
Encargado de realizar la prueba
54
Pautas generales
55
34. Estrategia de prueba
55
Proceso de la prueba
56
Prueba de Unidad
56
Prueba de Integracin
57
Prueba de Validacin
57
Prueba del Sistema
57
35. Casos de prueba
58
Diseo de casos de prueba
58
36. Tcnicas de prueba
59
Prueba de Caja Blanca
59
Prueba de Caja Negra
63
37. Calidad de la etapa de prueba
65
38. Bibliografa
66
ndice Temtico
Pg.: 4 de 98

ANEXO U1
ANEXO U6
ANEXO U8
ANEXO U9
ANEXO U10
ANEXO U11
ndice Temtico
Pg.: 5 de 98

1. Etapas en el desarrollo de sistemas de informacin

El proceso de desarrollo de sistemas de informacin es un enfoque por etapas que sostiene que los
sistemas son desarrollados de mejor manera mediante el uso de un ciclo especfico para las actividades
de los profesionales y del usuario. Los profesionales proceden sistemticamente.
El marco de referencia para su enfoque sistemtico es proporcionado por lo que se denomina ciclo de
vida del desarrollo de sistemas.
En todo desarrollo de sistemas pueden identificarse al menos siete etapas bien definidas.
Dependiendo del modo en que se lleven a cabo estas etapas se definen los diferentes ciclos de vida de
desarrollo de sistemas.
Las siete etapas son:
1. Relevamiento
2. Anlisis
3. Diseo
4. Codificacin
5. Prueba o testing
6. Implementacin
7. Mantenimiento
2. Modelos de sistema
Los modelos involucrados en la construccin de un sistema pueden visualizarse en el siguiente esquema:
Modelo
del
Sistema
Modelo
Modelo
de
Esencial
Implementacin
Modelo
Ambiental
Modelo de Datos
Modelo de
Lgico
Comportamiento
Modelo de
Tecnologa
Modelo de Datos
Modelo de
Fsico
Usuario o Fsico
Externo
Modelo de
Programas o
Fsico Interno
En este grfico vemos el modelo de sistema completo. La parte sombreada es la etapa que concierne al
Diseo del Sistema. Lo dems se refiere a lo visto en la etapa de Anlisis de Sistemas.
Esta etapa sombreada est compuesta por el modelo de implementacin que se divide en:
1. Modelo de Tecnologa: en este modelo se define la implantacin del sistema, especificando entre
otros el equipamiento y su distribucin; el sistema operativo y lenguaje que se utilizar.
2. Modelo de Datos Fsico: en este modelo se disea todo lo relacionado a los datos requeridos para
el funcionamiento del sistema en el ambiente tecnolgico definido y segn las especificaciones no
funcionales que se realicen. Se toma como base el modelo de datos esencial el cual se transforma en
el modelo de datos fsico.
Herramientas utilizadas:
Unidad 1 - Introduccin
Mapa Cannico Fsico

Pg.: 6 de 98

3. Modelo de Usuario o Fsico Externo: en este modelo se identifican los tipos/roles de usuarios y se
disea la interfaz del sistema con los mismos.
Diagrama de Pantallas
Diagrama de Transicin de Estados
Diagrama de Interaccin
4. Modelo de Programas o Fsico Interno: en este modelo se describe la lgica, la estructura y la

especificacin interna del sistema antes de ser codificado.
Diagrama de Composicin
3. Herramientas informticas utilizadas en cada etapa

El proceso de desarrollo de un sistema de informacin debe ser asistido por herramientas informticas
para:
Aumentar la productividad de las reas de desarrollo
Facilitar el mantenimiento de los sistemas informticos
Mejorar la calidad del software desarrollado
Reducir tiempos y costos de desarrollo y mantenimiento del software
Mejorar la gestin del proyecto en cuanto a su planificacin, ejecucin y control
Simplificar la divulgacin de la documentacin del proyecto
Herramientas de escritorio
A continuacin se sugiere un listado de herramientas informticas de escritorio que se pueden combinar
para documentar el proceso de desarrollo de:
Etapa
Herramientas informticas sugeridas
Relevamiento
Anlisis
Software para representar los modelos:

Modelo de datos esencial:
Erwin: exporta el modelo de datos a una base de datos, permite definir
procedimientos catalogados
Visio: la misma herramienta puede utilizarse para varios modelos.
Flexible, abierta, integrada con otras herramientas de escritorio
Procesadores de texto
Correo electrnico
Software para disear formularios
Bases de datos para procesar informacin
Modelo del ambiente:

EasyCase: herramienta CASE solo para documentacin
Modelo de comportamiento:
EasyCase: herramienta CASE solo para documentacin
Pg.: 7 de 98

Diseo
Software para representar los modelos:

Modelo de datos fsico:
Erwin: genera bases de datos segn lenguaje elegido, permite definir
procedimientos catalogados
Modelo de usuario o fsico externo:

Para diagrama de pantallas: software para crear prototipos de pantallas
e informes.
Para Diagrama de Interaccin y Diagrama de Transicin de Estados:
Visio, la misma herramienta puede utilizarse para varios modelos. Flexible,
abierta, integrada con otras herramientas de escritorio.
Modelo de programas o fsico interno:

Procesador de texto
Prueba o testing
Procesadores de texto
Bases de datos para registrar las pruebas planificadas y los resultados
Software de planificacin para el plan de testing
Implementacin
Procesadores de texto para los manuales de usuario

Software de planificacin para el plan de implementacin
Mantenimiento
Bases de datos para registrar un histrico de mantenimientos realizados
A largo de todo el ciclo de vida de desarrollo de sistemas, adems de las herramientas CASE se pueden
usar las siguiente herramientas informticas:
Software de administracin de recursos: Para planificar las actividades y realizar el seguimiento

de las mismas y para administrar la asignacin de personas y recursos del proyecto. Ej.: Microsoft
Project, TurboProject
Software de grficos y de presentacin: Ayudan en la creacin de ilustraciones y producen una

presentacin profesional para los usuarios. Ej.: Microsoft PowerPoint, Lotus ScreenCam
Bases de datos documentales: Agilizan la administracin de la documentacin de proyectos. Ej.:

Lotus Notes, Groupwise
Herramientas CASE
1. Definicin
La sigla CASE significa Ingeniera de Software Asistida por Computadoras (Computer Aided Software
Engineering) es decir la automatizacin del proceso de desarrollo de software.
CASE es una filosofa que se orienta a la mejor comprensin de los modelos de empresa, sus actividades
y el desarrollo de los sistemas de informacin. Esta filosofa involucra adems el uso de programas que
permiten:
Construir los modelos que describen la empresa
Describir el medio en el que se realizan las actividades
Llevar a cabo la planificacin
El desarrollo del Sistema Informtico, desde la planificacin, pasando por el anlisis y diseo de
sistemas, hasta la generacin del cdigo de los programas y la documentacin
Pg.: 8 de 98

2. Objetivos del CASE
Aumentar la productividad de las reas de desarrollo y mantenimiento de los sistemas

informticos.
Mejorar la calidad del software desarrollado.
Reducir tiempos y costos de desarrollo y mantenimiento del software.
Mejorar la gestin y dominio sobre el proyecto en cuanto a su planificacin, ejecucin y control.
Mejorar el archivo de datos de conocimientos (repositorio de datos) y facilitar su uso, reduciendo

la dependencia de analistas y programadores.
Automatizar :
El desarrollo del software
La documentacin
La generacin del cdigo
El chequeo de errores
La gestin del proyecto
Permitir:
La reutilizacin (reusabilidad) del software
La portabilidad del software
La estandarizacin de la documentacin
Integrar las fases de desarrollo (ingeniera del software) con las herramientas CASE
Facilitar la utilizacin de las distintas metodologas de ingeniera del software.
3. Repositorio de datos
En el contexto CASE se entiende por repositorio a la base de datos que contiene todas las informaciones
relacionadas con las especificaciones, anlisis y diseo del software.
En est base de datos se incluyen las informaciones de:
Datos: atributos (campos), asociaciones (relaciones), entidades (registros), almacenes de datos,

estructuras, etc.
Procesos: procesos, funciones, mdulos, etc.
Grficos: DFD (Diagrama de Flujo de Datos), DER (Diagrama Entidad Relacin), DDF (Diagrama de
Descomposicin Funcional), ED (Diagrama de Estructura), Diagrama de Clases, etc.
Reglas: de Gestin, de mtodos, etc.
4. Clasificacin de las herramientas CASE

Como ya hemos comentado en los apartados precedentes, CASE es una combinacin de herramientas
de software (aplicaciones) y de metodologas de desarrollo:
Las herramientas permiten automatizar el proceso de desarrollo del software.
Las metodologas definen los procesos a automatizar.
Una primera clasificacin del CASE es considerando su amplitud:
ToolKit: es una coleccin de herramientas integradas que permiten automatizar un conjunto de

tareas de algunas de las fases del ciclo de vida del sistema informtico: Planificacin estratgica,
Anlisis, Diseo o Codificacin de programas.
WorkBench: son conjuntos integrados de herramientas que dan soporte a la automatizacin del
proceso completo de desarrollo del sistema informtico. Permiten cubrir el ciclo de vida completo. El
producto final aportado por ellas es un sistema en cdigo ejecutable y su documentacin.
Pg.: 9 de 98

Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que
automatizan:
Upper CASE: Planificacin estratgica, Especificacin de Requerimientos.
Middle CASE: Anlisis, Diseo.
Lower CASE: Generacin de cdigo, Prueba, Implantacin.
5. Software CASE
PowerDesigner 9.0 (SyBase)
Dessigner 2000 (Oracle)
PowerDesigner 9.0 - SyBase

Es un entorno integrado para el anlisis y diseo de aplicaciones empresariales, con amplias
capacidades para el modelado de negocios, datos y objetos dentro de un ambiente altamente grfico.
Modelado de Procesos de Negocio: PowerDesigner le brinda poder a los usuarios no tcnicos para
disear y modelar procesos de negocio en trminos reales del negocio, usando un modelo simple, fcil de
usar, altamente grfico, y no tcnico. Incluye soporte a la generacin e ingeniera inversa de cdigo XML.
Modelado de Datos: PowerDesigner disea y genera el esquema de la base de datos a travs de un
verdadero modelado de bases de datos relacionales de dos niveles (conceptual y fsico) basado en
mtodos probados. PowerDesigner tambin soporta tcnicas especficas de modelado para
datawarehouse.
Modelado de Objetos: PowerDesigner completa el anlisis y el diseo usando tcnicas UML estndar. A
partir de un diagrama de clase, PowerDesigner automticamente genera y realiza ingeniera inversa de
ambientes populares como Java, XML, Servicios Web, C++, PowerBuilder y VisualBasic, a travs de un
generador personalizable.
Repositorio Empresarial: La versin Enterprise de PowerDesigner agrega un repositorio de clase
empresarial. El repositorio permite fcilmente visualizar y compartir modelos y otra informacin entre
todos los miembros del equipo de desarrollo. El repositorio es altamente escalable y soporta seguridad
basada en roles, control de versiones, bsqueda y generacin de reportes.
Designer 2000 - Oracle
Designer 2000 es una herramienta CASE que abarca todo el ciclo de vida de la creacin de cualquier
sistema de informacin, incluyendo la generacin del cdigo necesario para la puesta en produccin.
Adems soporta cualquier metodologa de desarrollo que quiera utilizarse para el desarrollo del mismo
incluyendo: Oracle CASE Method, Buisness Process Reengineering (BPR), Ingeniera en Reverso, Bases
de datos distribuidas, etc.
Cuenta con Diagramadores y Herramientas para cada etapa del desarrollo completamente integradas
entre ellas, las cuales obtienen la informacin de un repositorio de informacin comn, que permite
acceso a mltiples usuarios en forma simultnea sobre la misma aplicacin; esto facilita la creacin de
aplicaciones corporativas desarrolladas con equipos de trabajo.
Adems brinda facilidades tales como:
Manejar mltiples versiones de una aplicacin
Mantener copias "congeladas" de stas
Crear perfiles de usuario dentro del repositorio separados de los esquemas de seguridad de la
base de datos
Generacin de reportes sobre el estado actual de cualquier elemento de la aplicacin
Ingeniera en reverso de aplicaciones existentes
Extraer informacin de otras herramientas CASE e incluirlas dentro de la definicin de las

aplicaciones, etc.
Pg.: 10 de 98

4. Problemas en el desarrollo de software

Caractersticas del software:
El software es un elemento lgico en vez de fsico; por tanto, el xito se mide por la calidad de
una nica entidad en vez de por muchas entidades fabricadas.
El software no se rompe. Si se encuentran fallos, lo ms probable es que se introdujeran

inadvertidamente durante el desarrollo y no se detectaran durante la prueba.
Reemplazamos las "partes defectuosas" durante el mantenimiento del software, pero tenemos
muy pocas piezas de repuesto, incluso ninguna; es decir, el mantenimiento incluye
normalmente la correccin o modificacin del diseo.
La naturaleza lgica del software representa un desafo para la gente que lo desarrolla.
Suele ocurrir que los responsables del desarrollo del software son ejecutivos de nivel medio y alto, sin
conocimientos de software.
Un antiguo axioma de gestin dice: "Un buen gestor puede gestionar cualquier proyecto". Pero en este
caso debemos aadir: "...Si est dispuesto a aprender las nuevas tcnicas que pueden utilizarse para
medir el desarrollo del proyecto, a aplicar mtodos efectivos de control, a ignorar la mitologa y a llegar a
conocer una tecnologa que cambia rpidamente".
El gestor debe comunicarse con todos los componentes implicados en el desarrollo del software
clientes, realizadores del software, equipo de soporte y otros. La comunicacin puede romperse debido a
que se comprenden mal las caractersticas especiales del software y los problemas particulares asociados con su desarrollo. Cuando esto ocurre, los problemas se multiplican.
Los problemas que afectan al desarrollo del software se pueden caracterizar bajo diferentes perspectivas,
los aspectos de "fondo" pueden resumirse en:
(1) la planificacin y estimacin de costos son frecuentemente muy imprecisas;
(2) la productividad de la comunidad del software no se corresponde con la demanda de sus
servicios, y
(3) la calidad del software no llega a ser a veces ni aceptable.
Algunas consecuencias son:
Desajustes en los costos de hasta un orden de magnitud
Errores en la planificacin en meses o aos
Insatisfaccin y falta de confianza de los clientes
Los problemas asociados con la crisis del software se han producido por el propio carcter del software y
por los errores de las personas encargadas del desarrollo del mismo.
Entre las causas podemos enumerar:
No se recogen datos sobre el proceso de desarrollo del software. Sin datos histricos como gua, la
estimacin no ha sido buena y los resultados previstos muy pobres. Sin una indicacin slida de la
productividad, no podemos evaluar con precisin la eficacia de las nuevas herramientas, tcnicas o
estndares.
La insatisfaccin del cliente con el sistema "terminado" se produce demasiado frecuentemente. Los
proyectos de desarrollo del software se acometen frecuentemente con slo una vaga indicacin de
los requisitos del cliente. Normalmente, la comunicacin entre el cliente y el que desarrolla el
software es muy escasa.
La calidad del software es normalmente cuestionable. Hemos empezado a comprender

recientemente la importancia de la prueba sistemtica y tcnicamente completa del software. Estn
comenzando a emerger conceptos cuantitativos slidos sobre la fiabilidad del software y las garantas
de calidad.
Pg.: 11 de 98

El software existente puede ser muy difcil de mantener. La tarea de mantenimiento del software se
lleva la mayor parte de todo el dinero invertido en el software. El mantenimiento no se ha considerado
un criterio importante en la aceptacin del software.
Falta de formacin: Sin formacin especfica algunas personas desarrollan un mtodo ordenado y eficiente de desarrollo del software mediante prueba y error, pero muchos otros desarrollan malos
hbitos que dan como resultado una pobre calidad y mantenibilidad del software.
Todos los problemas descritos anteriormente pueden corregirse. La clave est en dar un enfoque de
ingeniera al desarrollo del software, junto con la mejora continua de las tcnicas y de las herramientas.
5. Bibliografa
Ingeniera del Software, un enfoque prctico, (3ra edicin) Roger S. Pressman, McGraw Hill
Pg.: 12 de 98

Calidad del Software

6. Definicin
Una definicin inicial de Calidad del software:
Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los
estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera
de todo software desarrollado profesionalmente.
Esta definicin dista mucho de ser definitiva, pero nos sirve para destacar tres puntos importantes:
1. Los requisitos del software son las bases de las medidas de calidad. La falta de concordancia
con los requisitos es una falta de calidad.
2. Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma
en que se aplica la ingeniera de software. Si no se siguen estos criterios casi siempre habr falta
de calidad.
3. Existe un conjunto de requisitos implcitos que a menudo no se mencionan (p. Ej.: el deseo de
un buen mantenimiento). Si el software se ajusta a sus requisitos explcitos pero falla en alcanzar
los requisitos implcitos, pierde calidad.
Condicionantes de un buen diseo:
Factores de calidad
Lenguaje
Entornos Operativos
La calidad del software est directamente relacionada con el grado de satisfaccin del usuario y la
adaptacin a las caractersticas de la empresa (lenguaje, sistema operativo, etc.)
7. Uso de Estndares y su importancia

Definicin
Los estndares son convenciones documentadas que contienen especificaciones tcnicas u otro criterio
puntual, para ser usado consistentemente como reglas, guas, o definiciones, para asegurar que los
productos, procesos y servicios son adecuados para cumplir su objetivo.
De esta manera, los estndares contribuyen a simplificar las tareas y a aumentar la confiabilidad y
efectividad de los bienes y servicios que producimos.
La utilizacin de estndares mejora el tiempo de productividad, principalmente cuando se trabaja en
grupos.
Con respecto al equipo de desarrollo la utilidad de un estndar consensuado y debidamente
implantado no es otra que permitir que el profesional A se enfrente al sistema desarrollado por el
profesional B, y no encuentre problemas en la comprensin de dicho sistema. Por ejemplo en la etapa
de mantenimiento, ya que esta puede durar muchos aos y para ello cualquier profesional nuevo
entender con ms facilidad un sistema si contiene estndares.
Con respecto a los usuarios cuando se est haciendo un diseo siempre debemos tener en cuenta la
terminologa usada. Este punto puede ser crtico en el momento en que estemos capacitando al
personal para el uso del nuevo sistema. Si usamos un vocabulario ya conocido por el personal de la
empresa ser mucho ms fcil difundir nuestras ideas y lograr que los usuarios comprendan, y en
consecuencia acepten, el nuevo sistema.
Ventajas
Mejoran la calidad y confianza en el software que se adquiere o produce
Facilitan el entendimiento Brindan un lenguaje comn
Unidad 2 - Calidad en el Software
Pg.: 13 de 98

Generan documentacin del proceso de desarrollo
Mayor mantenibilidad de los sistemas
Simplifican la comunicacin y el traslado de la informacin
Favorecen el crecimiento de lo desarrollado
8. Factores de calidad
La calidad alcanzada por un sistema est estrechamente relacionada al grado de satisfaccin que se
logre de las expectativas del usuario y a la adaptacin a las caractersticas propias de la empresa. Estas
expectativas y caractersticas se pueden expresar por medio de los siguientes factores de calidad.
Exactitud
Es la adecuacin del software a las necesidades del usuario.
Cuando sabemos que determinadas funciones muy complejas no son satisfechas al ciento por
ciento debido a problemas tecnolgicos o por propia decisin del usuario estamos frente a una
situacin de baja exactitud.
Fiabilidad
Es la cantidad de fallas que ocurren por perodo de tiempo.
Se debe definir claramente qu se entender por fallas y los posibles tipos que se encontrarn en
el sistema.
Eficacia
Es el consumo de recursos en general que har el sistema.
Se deben definir los tiempos de respuesta que tendr a consultas especficas, o promediales.
Integridad
Se refiere a mantener los datos coherentes pase lo que pase.
Se debe definir hasta qu punto el sistema es capaz de detectar inconsistencias en los datos.
Testeabilidad
Es la facilidad del sistema para el testeo.
Esto deber ser previsto en la etapa de diseo. Al usuario no le va a interesar si el sistema es o
no fcilmente testeable, s le interesar a los encargados de mantenimiento.
Flexibilidad
Es la capacidad para cambiar componentes, es decir la posibilidad de agregar o quitar mdulos
ante nuevas necesidades del usuario.
Un bajo acoplamiento entre mdulos favorece la flexibilidad.
Mantenibilidad
Es la facilidad con que puede ser modificado el sistema, especialmente por un desarrollador que
no lo construy.
Algunos aspectos que favorecen la mantenibilidad son la calidad de la documentacin, los
comentarios en fuentes, etc.
Pg.: 14 de 98

Reutilizacin
Grado en que podrn se utilizados los componentes para la construccin de otros sistemas o en
otros eventos del mismo sistema.
Juegan un papel fundamental la cohesin y el acoplamiento que tendrn los mdulos. Ser muy
importante la correcta administracin del repositorio de componentes.
Interoperabilidad
Posibilidad de acoplarlo con otros sistemas.
Tabla resumen
Factor
Pregunta que lo sintetiza
Exactitud
Hace lo que quiero?
Fiabilidad
Es confiable todo el tiempo?
Eficacia
Se ejecutar en mi hardware lo mejor posible?
Integridad
Es seguro? Es consistente?
Testeabilidad
Puedo probarlo?
Flexibilidad
Puedo cambiarlo?
Mantenibilidad
Puedo corregirlo?
Reutilizacin
Puedo reusar alguna parte?
Interoperabilidad
Puedo hacerlo interactuar con otro?
9. Garanta de Calidad del Software (SQA)

La Garanta de calidad es una actividad esencial en cualquier empresa que produce productos que van a
ser usados por otros.
La historia de la calidad en el desarrollo del software ha ido paralela a la historia de la calidad en la
fabricacin del hardware. Durante los primeros aos de la informtica (aos 50 y 60), la calidad era
responsabilidad nicamente del programador. Durante los aos 70 se introdujeron estndares de garanta
de calidad para el software en los contratos militares que se han ido extendiendo rpidamente en los
desarrollos de software del rea comercial.
La Garanta de Calidad del Software (Software Quality Assurance SQA), es un diseo de acciones
planificado y sistemtico que se requieren para asegurar la calidad del software.
La responsabilidad en la garanta de calidad del software corresponde a muchas de las partes de la
organizacin ingenieros de software, gestores del proyecto, clientes, y personas que trabajan dentro del
grupo de SQA.
El grupo de SQA sirve como representacin del cliente dentro de la casa, es decir la gente que lleva a
cabo SQA debe mirar el software desde el punto de vista del cliente.
10. Actividades de SQA

Aplicacin de mtodos y tcnicas
Ayudan al analista a conseguir especificacin y diseo de alta calidad.
Pg.: 15 de 98

Realizacin de Revisiones Tcnicas Formales (RTF)

Es una reunin del personal tcnico con el propsito de descubrir problemas de calidad. En
muchas situaciones se ha visto que las RTF son tan efectivas como la prueba para descubrir
defectos en el software.
Prueba del software

Combina una estrategia de mltiples pasos con una serie de mtodos de diseo de casos de
prueba que ayudan a asegurar una efectiva deteccin de errores. Muchos grupos de desarrollo
usan la prueba del software como una red de seguridad para la garanta de calidad. O sea,
asumen que mediante la prueba detectarn la mayora de los errores, mitigando as otras
actividades de SQA. Desgraciadamente la prueba, an cuando se realiza adecuadamente, no es
tan efectiva como desearamos para todas las clases de errores.
Ajuste a estndares
En muchos casos los estndares vienen dados por los clientes o por mandamientos de
regulacin. En otras situaciones los estndares se imponen por s solos. Si existen estndares
formales (escritos) se debe establecer una actividad de SQA para garantizar que se cumplan.
Este control puede llevarse a cabo en las RTF o por el grupo de SQA mediante su propia
auditora.
Control de cambios
Cada cambio realizado sobre el software en potencia puede introducir errores o crear efectos
laterales que propaguen errores. El proceso de control de cambios (parte de la Gestin de
Configuracin del Software) contribuye directamente a la calidad del software, al formalizar las
peticiones de cambio, evaluar la naturaleza del cambio y controlar el impacto del cambio. Se
aplica en la etapa de desarrollo y posteriormente en la de mantenimiento.
Mediciones
Un objetivo importante de la SQA es la evaluacin del impacto de cambios de metodologa y de
procedimiento que intentan mejorar la calidad del software. Para ello se deben recolectar
mtricas de software.
Registro y realizacin de informes

Los resultados de las revisiones, auditoras, control de cambios, prueba y otras actividades de SQA
deben formar parte del registro histrico de un proyecto y ser divulgados al plantel de desarrollo para
que tengan conocimiento de ellos.
11. Revisiones Tcnicas Formales

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniera
del software. Cada una tiene su lugar. Una reunin informal alrededor de una mquina de caf es una
forma de revisin, si se discuten problemas tcnicos. Una presentacin formal de un diseo de software a
una audiencia de cliente, ejecutivos y personal tcnico es una forma de revisin. Una Revisin Tcnica
Formal (RTF) es llevada a cabo por ingenieros de software (y otros) para los ingenieros de software.
El beneficio de las RTF es el pronto descubrimiento de defectos del software, de forma que cada defecto
pueda ser corregido lo antes posible. Esto reduce sustancialmente el costo de las siguientes fases del
proyecto.
Pg.: 16 de 98

Varios estudios indican que las actividades de diseo introducen entre el 50 y 65% de los errores de la
fase de desarrollo del proceso de ingeniera del software. Sin embargo, las RTF se han mostrado
efectivas, hasta el 75% de los casos para descubrir fallas en el diseo. Esta deteccin de errores reduce
sustancialmente el costo de las fases de desarrollo y mantenimiento.
A partir de datos de costo recogidos realmente para grandes proyectos de software, supongamos que un
error no descubierto durante el diseo cuesta $1 corregirlo. El mismo error descubierto justo despus que
comienza la prueba, costar $6,5; durante la prueba, $15; y despus de entregar el software, entre $60 y
$100.
Objetivos de la RTF
Los objetivos de la RTF son:
Descubrir los errores y/o defectos. Por ejemplo, ver si un objeto definido en los requerimientos de
usuario no est creado o est mal.
Controlar que el software alcance sus requisitos.
Garantizar la conformidad con los estndares. No solo hay que definir los estndares sino
tambin comprobar que se cumplan.
Conseguir un software desarrollado de manera ms uniforme.
Hacer que los proyectos sean ms manejables estableciendo puntos de control en los cuales
dependiendo del resultado se podr decidir replantear las fechas planificadas.
La reunin de revisin
Independientemente del formato que se elija para la RTF, cualquier reunin de revisin tiene las
siguientes caractersticas:
Es una reunin de personas. Se renen:

El productor (desarrollador)
El jefe de revisin
El registrador
Los revisores
Es estructurada tiene una agenda
Es limitada en participantes (de 3 a 5 personas)
Es limitada en duracin (menos de 2 horas)
Pasos de la RTF
Establecer una agenda y avisar a los participantes
Durante la reunin:
El productor presenta su producto
Los revisores evalan el producto
El registrador toma nota de los errores
Normas:
Revisar el producto, no al productor. Si se lleva a cabo incorrectamente, la reunin puede tomar
el aura de inquisicin. La RTF debe llevar a todos los participantes a la sensacin de estar
cumpliendo con su deber.
Fijar una agenda. La RTF debe seguir un plan de trabajo concreto. El jefe de revisin debe
mantener el plan de la reunin y cortar las discusiones cuando se empiece a divagar.
Registrar errores y no corregirlos. Una revisin no es una sesin de resolucin de problemas. La
resolucin de problemas puede ser pospuesta para despus de la reunin de revisin.
Pg.: 17 de 98


Tomar notas escritas. Para que las declaraciones o la asignacin de prioridades pueda ser
comprobada por el resto de los revisores.
Limitar el nmero de participantes e insistir con la preparacin anticipada.
Elaborar una gua con posibles problemas (errores ms comunes). Desarrollar listas de
comprobaciones para los documentos de anlisis, de diseo, de codificacin e incluso de prueba.
Llevar a cabo buen entrenamiento de los revisores.
Repasar las revisiones anteriores. Esto suele ser beneficioso para descubrir problemas en el
propio proceso de revisin.
No debatir estndares: aceptarlos como estn. Actualizarlos fuera de la RTF.
12. Ventajas y desventajas de la SQA

Ventajas

Menos defectos latentes -> Menor esfuerzo, tiempo de prueba y mantenimiento

Mayor fiabilidad -> Mayor satisfaccin del cliente
Reduccin de costos de mantenimiento
Disminucin del costo total de ciclo de vida
Desventajas

Es difcil de aplicar en organizaciones pequeas

Representa un importante cambio cultural
Requiere un gasto explcito -> CostoErroresSinSQA > CostoSQA + CostoErroresConSQA
13. Bibliografa
Pg.: 18 de 98

14. Qu se entiende por Diseo de Sistemas?

No existe una definicin absoluta sobre Diseo de Sistemas, pero se pueden considerar estos conceptos:
En el diseo se implementa todo el anlisis previamente realizado.
Para lograrlo se anexan dos nuevos elementos:

o Tecnologa de implantacin del sistema:
previamente a comenzar a disear se debe planificar y decidir acerca de la tecnologa
que se va a usar: el lenguaje, el soporte de datos, los equipos y software de base
necesarios, la arquitectura del sistema, etc. (modelo de tecnologa)
o Requerimientos no funcionales del sistema:
son requerimientos que no hacen a la funcionalidad del sistema pero que son vitales de
considerar antes de comenzar el diseo, de modo de cumplimentarlos y garantizar la
calidad del sistema.
Cuando se tiene definido el modelo tecnolgico y acotados los requerimientos no funcionales se

realizan, junto a todos los productos obtenidos en el anlisis:
Las modificaciones que se consideren necesarias al modelo de datos esencial,
transformndolo en modelo de datos fsico
Se agregan nuevos procesos si fueran necesarios a los previstos en el anlisis
Se disean las interfaces del sistema dando la mayor flexibilidad posible para el usuario
interacte con el sistema, previo haber considerado tipos y roles usuarios.
Se realiza el diseo detallado de los procesos para lograr luego su codificacin , en la
siguiente etapa
Situndonos dentro del ciclo de vida del desarrollo de sistemas podramos decir que disear sistemas es
producir un plan de implementacin a partir de los requerimientos de datos y de los requerimientos
funcionales relevados en la etapa de anlisis, incorporando adems la tecnologa y los requerimientos no
funcionales.
Durante la etapa de anlisis se comprende el sistema que se debe desarrollar, obtenemos el "qu" se
debe hacer. La etapa de diseo nos da la idea del "cmo" hacerlo.
Anlisis Qu hacer
Diseo Cmo hacerlo
Se encuentran numerosos inconvenientes en el diseo que no se manifiestan en las etapas previas del
ciclo de desarrollo, pues el anlisis de un sistema tiene una sola forma de hacerse correctamente, salvo
pequeos detalles, bsicamente porque es esencial , libre de todo aspecto tecnolgico o fsico.
En cambio cuando diseamos sistemas podemos optar por diferentes caminos en cuanto a la
organizacin del mismo.
No es posible poseer criterios de evaluacin subjetiva respecto a lo correcto del diseo de un sistema ya
que distintas personas poseern distinto grado de aceptabilidad segn sus necesidades, lo que debe
tratar el diseador es de satisfacer los requerimientos plasmados en el anlisis sin descuidar otros
aspectos como performance, estandarizacin, restricciones, funcionalidad y operatividad de la interfase,
etc.
Unidad 3 Diseo de Sistemas
Pg.: 19 de 98

15. Modelo de Implementacin

Modelo
de
Implementacin
Modelo de
Tecnologa
Modelo de Datos
Modelo de
Usuario o Fsico
Fsico
Externo
Modelo de
Programas o
Fsico Interno
Modelo de Tecnologa: en este modelo se define la implantacin del sistema, especificando entre
otros el equipamiento y su distribucin; el sistema operativo y lenguaje que se utilizar.
Modelo de Datos Fsico: en este modelo se disea todo lo relacionado a los datos requeridos para
el funcionamiento del sistema en el ambiente tecnolgico definido y segn las especificaciones no
funcionales que se realicen. Se toma como base el modelo de datos esencial el cual se transforma en
el modelo de datos fsico.
Mapa Cannico Fsico
Modelo de Usuario o Fsico Externo: en este modelo se identifican los tipos/roles de usuarios y se
disea la interfaz del sistema con los mismos.
Diagrama de Pantallas
Modelo de Programas o Fsico Interno: en este modelo se describe la lgica, la estructura y la

especificacin interna del sistema antes de ser codificado.
Diagrama de Composicin
16. Fundamentos del Diseo

Los conceptos del diseo proporcionan criterios bsicos para su calidad, es decir proporcionan la
estructura bsica necesaria para hacerlo bien.
Abstraccin: Durante el anlisis de los requisitos del software se establece la solucin en trminos
de lo que es familiar al entorno del problema. A medida que avanzamos en el proceso de
diseo, se reduce el nivel de abstraccin, y finalmente se alcanza el nivel inferior de abstraccin
cuando se construye el cdigo.
Refinamiento: Proporciona un mecanismo para representar capas sucesivas de detalles funcionales.
Ayuda al diseador a revelar detalles de bajo nivel a medida que progresa el diseo.
Modularidad: Permite al diseador simplificar y reutilizar componentes. La arquitectura del software
conlleva modularidad, es decir, se divide el software en componentes identificables y tratables por
separado, denominados mdulos, que estn integrados para satisfacer los requerimientos del
programa.
Pg.: 20 de 98

El software modular permite su fcil comprensin y manejo, en contrapartida al software monoltico

(de un solo mdulo) no son fcilmente abarcado por el lector (gran cantidad de lneas de cdigo,
gran nmero de caminos de control, gran nmero de variables, complejidad global, etc.).
17. Requerimientos No Funcionales

El anlisis de un sistema muestra los aspectos esenciales del mismo. Es independiente de la
implementacin tecnolgica. Es ms, considera que esta tecnologa es perfecta: memoria ilimitada,
tiempos de respuesta instantneos, capacidad de almacenamiento infinita, disponibilidad inmediata del
dinero necesario y muchos otros requerimientos fundamentales a la hora de la implementacin.
En el momento de realizar el anlisis, nos basamos exclusivamente en requerimientos funcionales, es
decir aquellos que son necesarios para el funcionamiento del sistema sobre cualquier tecnologa.
Sin embargo, luego llega el momento de bajar al mundo real. Hay que implementar un sistema en
computadoras de variadas velocidades, la adquisicin de los equipos que se necesitan est restringida
por un presupuesto limitado, el sistema operativo que se est usando en la empresa tiene ciertos
condicionamientos, hay riesgos de fallas en equipos y posibilidad de robo de la informacin, hay normas y
costumbres arraigadas desde mucho tiempo en la organizacin, entre muchas otras restricciones.
Por eso, es en esta etapa de diseo donde debemos tener en cuenta ciertos requerimientos no
funcionales que terminarn definiendo la aceptacin o no de nuestro sistema por parte de los usuarios,
impactando directamente en la calidad del sistema.
Estos requerimientos no funcionales pueden clasificarse en:
Requerimientos de Rendimiento
Operaciones
Impacto en la organizacin
Pg.: 21 de 98

Requerimientos de rendimiento
Es la especificacin cualitativa y cuantitativa del rendimiento deseado para el sistema a implementar.
Principalmente se refiere al tiempo de respuesta esperado para los procesos.
1. Tiempo de respuesta
Muchas veces las necesidades de obtener informes / consultas en un corto lapso de tiempo se ven
afectadas por el modelo de datos definido en el anlisis.
Ejemplo: Supongamos que necesitamos emitir un listado de saldos de nuestros clientes. Podemos,
segn el modelo esencial, buscar cada cliente y, partiendo de un saldo inicial en cero, reconstruir ese
saldo, acumulando los importes de cada movimiento de su cuenta corriente.
Pero existe un problema: cada Cliente a lo largo de su vida en la empresa, ha acumulado en

promedio 500 movimientos y la empresa cuenta con ms de mil clientes activos.
Por lo tanto, para emitir ese listado de saldos nuestro sistema debera recorrer ms de 500.000
registros, con lo que los tiempos de emisin se volveran inaceptables.
Una forma prctica de salvar este inconveniente sera incorporar en la cuenta del cliente un campo
denominado saldo, que, mediante un proceso adicional, ira acumulando el saldo real de este cliente
en el momento de ingresar cada movimiento en su cuenta corriente.
De esta forma, un proceso que, en principio debera recorrer ms de 500 000 registros, se reducira a
una bsqueda sobre solo mil registros.
Pero se debe tener sumo cuidado al tomar la decisin de agregar un campo de clculo a las tablas
esenciales, ya que este campo implicar sin duda un nuevo proceso a contemplar en el anlisis,
diseo, programacin y mantenimiento (para el ejemplo anterior, la rutina de ingreso de movimientos
del cliente deber contar con un proceso que, adems, actualice el saldo) y podra tambin perjudicar
la performance de la aplicacin actual. Por eso este tipo de soluciones se realiza cuando la criticidad
de la performance del evento lo exige y siempre analizando costo / beneficio de la solucin.
Pg.: 22 de 98

2. Orden alternativo
Otro de los problemas de rendimiento que se pueden presentar es cuando debemos mostrar los
datos en un orden diferente al de la clave definida en el modelo de datos.
Ejemplo: Supongamos que queremos listar el archivo de clientes tratado en el punto anterior, pero
necesitamos que este listado se encuentre ordenado alfabticamente. Como nuestra clave para el
archivo es nro_cliente, la nica solucin que tendramos sera guardar los datos que correspondan al
listado en un archivo, luego, mediante alguna tcnica definida, ordenarlo alfabticamente, y por
ltimo, listarlo.
Para esto, necesitaramos 1000 accesos de lectura al archivo original ms otros 1000 accesos de
escritura en el archivo que vamos a usar para el ordenamiento, y por ltimo, una vez ordenado, otros
1000 accesos al archivo de ordenamiento. Por lo tanto, tendramos 3000 accesos a archivos, para un
proceso tan simple como listar alfabticamente, sin contar el tiempo que demandar ordenar los
datos en el archivo de ordenamiento.
Si, por otro lado, tuviramos que listar slo los clientes de Rosario (y sabemos que tenemos slo 10),
necesitaramos recorrer 1000 registros para listar slo 10 (el 1%).
Estos dos problemas se solucionan agregando dos ndices al archivo de clientes.
Para el primer caso, se necesitara un ndice por ape_cliente y nom_cliente, y para el segundo, uno
por cod_postal.
De esta forma, la bsqueda ser mucho ms eficiente, ya que en el primer caso slo recorrer 1000
registros (contra los 3000 anteriores) y en el segundo, slo 10 (contra 1000).
Por lo tanto cada archivo/tabla de datos contar con:
Clave Principal
ndices Secundarios
Tanto la primera como la segunda son soluciones que apuntan a reducir drsticamente los tiempos
que toma presentar / procesar la informacin.
Algunos aspectos a tener en cuenta para aplicar correctamente ambas soluciones:
Estimar el crecimiento de las tablas
Definir la frecuencia con la que se va a recuperar la informacin (diaria, mensual, anual)
Identificar los informes/procesos de tiempo crtico, que
emitirse/ejecutarse prcticamente al instante en que se solicitan
son
aquellos
que
deben
Definir el tiempo de respuesta requerido en cada caso

Identificar el orden en que se mostrar la informacin en los reportes
Existen requerimientos derivados de estndares tales como: formato de informes, convenciones de
nombres, procedimientos contables, pistas de auditora, regulaciones legales, elementos de seguridad.
Los estndares pueden ser internos (de la organizacin que construye el sistema) y externos (de la
organizacin que compra el sistema).
Pg.: 23 de 98

Los internos son aquellos necesarios para asegurar la calidad del sistema y posteriormente el
mantenimiento del mismo. Son estndares que fija la organizacin que construye el sistema, abarcan
todas las etapas del ciclo de vida y son decisivos en el momento de corregir nuestro software.
Si hemos aplicado correctamente los estndares, las tareas de mantenimiento correctivo (arreglos) y
perfectivo (mejoras) no necesitarn explicaciones bsicas muy extensas, ya que se eliminan aclaraciones
obvias y repetitivas: el cdigo habla por s mismo. Adems evita que un proyecto especfico dependa del
grupo de desarrolladores, amplindolo a cualquier grupo / persona y tambin ayuda a reducir la tasa de
errores del sistema, ya que se evitan muchas equivocaciones.
Por ltimo lo estndares internos facilitan la comunicacin y entendimiento entre las diferentes reas de
ingeniera del software.
En cuanto a los estndares externos, es decir impuestos por la organizacin cliente, pueden ser una
restriccin a cumplimentar para el xito del sistema y pueden facilitar las etapas de implementacin y
aceptacin del sistema. Trabajar con estndares que conoce el cliente facilitar la compresin y toda
accin que realice el usuario final. (Por ej. se contrata un sistema de toma de decisiones para la gerencia
y se impone como estndar que el nuevo sistema debe permitir al gerente operar de forma similar al
sistema que ste utiliza diariamente. Es decir debe respetar los botones comunes que tienen las
interfases del sistema, la ayuda ,etc.)
Pero pueden existir estndares ms complejos a cumplimentar. Uno de ellos podra ser la exigencia de la
organizacin cliente de que el sistema se adapte a las medidas de seguridad o respaldo existentes. Por
ejemplo, la seguridad de una Planta posee un acceso restringido al sector de Almacenes, entonces el
sistema deber contemplar una seguridad basada en puestos fijos (o sea que esas operaciones slo
podrn ser realizadas desde los puestos ubicados en el sector).
Si estos estndares no son detectados a tiempo (antes de comenzar a disear) el costo de construccin
del sistema se puede ver terriblemente afectado, ya que los cambios que se tengan que realizar para
satisfacer al cliente pueden impactar en todos los procesos o en procesos crticos del sistema que ya
estn desarrollados / testeados.
Pueden existir otros estndares externos ms simples a cumplimentar, como, por ejemplo, que todos los
informes / listados del cliente deben llevar el logo del mismo, o fecha hora de su emisin. Ellos deben se
igualmente contemplados para garantizar la satisfaccin del cliente y disminuir los tiempos/esfuerzos del
grupo de desarrollo.
Como se ha visto en anlisis, la esencia de un sistema es independiente del hardware donde se va a
utilizar. All nos desentendemos de dnde se va a implementar y encontramos un sistema que funcionar
tanto en una supercomputadora con equipos interconectados con satlites o fibra ptica, como en un
sistema a implementarse con lpiz, papel y fichas de cartn.
Pero ahora llega el momento de bajar a la realidad.
La empresa donde vamos a instalarlo, seguramente tendr hardware que no es de la ltima generacin y
que estn interesados en mantenerlo operativo.
Las redes existentes pueden no tener la velocidad ptima y cambiar el sistema operativo puede
representar un costo elevado, por lo que se debern analizar diferentes alternativas.
Por lo tanto se deber:
definir un equipamiento mnimo imprescindible para el funcionamiento ptimo del sistema,
especificando como mnimo:
Servidor/es, sistema operativo, capacidad del mismo (memoria, disco, etc.)
Puestos clientes, sistema operativo, capacidad de los mismos (memoria, disco, etc.)
Distribucin, cantidades de cada pieza del hardware a implementar
Pg.: 24 de 98

definir la infraestructura mnima de comunicaciones necesarias para que el equipamiento y el

sistema puedan operar correctamente.(tipo de cableado, tipo de red, etc.)
Luego se proceder a analizar si es factible o no la materializacin del sistema de acuerdo a lo que se
necesita versus lo que se dispone y se tomarn las medidas adecuadas para que el diseo contemple
las mismas y asegure la implementacin exitosa del sistema.
Operaciones
Describe las operaciones normales y especiales requeridas por el usuario tales como:
Los diferentes modos de operacin en la organizacin. Por ejemplo, para usuarios principiantes o
experimentados las formas de operar del sistema sern:
Segn el conocimiento del usuario ( Ej.: Copiar / Pegar, Ctrl-C / Ctrl-V)
Segn el dominio del problema (brindar ms ayuda para nuevos usuarios)
Perodos de operaciones interactivas
Perodos de operaciones no atendidas (batch)
Funciones de soporte de procesamiento de datos
Operaciones de resguardo y recuperacin (para los backups se deber planificar cmo se hace
(Espejado, RAID, cinta, disco rgido, diskettes, ZIPs), con qu periodicidad, en qu horario, dnde
se almacenan y quin ser el responsable)
Cuestiones de seguridad:
perfiles de usuario
niveles de acceso del sistema
seguridad a nivel del sistema operativo
Auditora:
Informes totales, o
Informes por excepcin

Define los requerimientos para cualquier dato o secuencias de inicializacin especficos de una
instalacin particular o modo de operacin de software.
Especifica facilidades del software que deben modificarse para adaptarlo a una instalacin particular.
1. Parametrizacin
Permite la reutilizacin y facilita el crecimiento del sistema.
Ejemplos:
Nombre de la organizacin
Horario de trabajo
Portabilidad idiomtica (ej.: castellano - portugus)
Unidad monetaria
2. Multiplataforma
Permite que el sistema pueda operar en diferentes plataformas de hardware y/o de software.
Pero este requerimiento puede tener un alto impacto en el costo de desarrollo si no se trabaja con
una arquitectura que permita independizar los procesos, datos e interfases y con software de
Pg.: 25 de 98

base que sea por naturaleza altamente portable (ej. Java como lenguaje, Linux como sistema
operativo).
Impacto en la Organizacin
Describe cambios y/o adaptaciones o agregados a estructura, funciones, responsabilidades, normas,
mtodos, etc. en los sectores involucrados por la implantacin del software.
Es sabido que las personas son reacias al cambio.
El impacto disminuye notablemente si los cambios o adaptaciones se trabajan en forma anticipada a la
implementacin del sistema y contribuye a esto el hecho de que el sistema respete y / o se adapte a los
estndares del cliente.
Pg.: 26 de 98

18. Qu se entiende por Modelo de Tecnologa?
Modelo
de
Implementacin
Modelo de
Tecnologa
Modelo de Datos
Modelo de
Usuario o Fsico
Fsico
Externo
Modelo de
Programas o
Fsico Interno
El Modelo de Tecnologa es la definicin de todos los componentes tecnolgicos que debern

implementarse para permitir el funcionamiento adecuado del sistema de informacin en cuestin.
En este modelo deben especificarse:
Tecnologa a utilizar para poner en produccin el sistema
Hardware
Software de Base
Tipo de red que permitir la conexin de los elementos citados anteriormente
Arquitectura del sistema
Tecnologa para el desarrollo del sistema (si no se contrata esta actividad)
Hardware
Software de base
Cuando se evala el modelo de tecnologa para implementar un nuevo sistema o una nueva parte del
sistema existente, puede ocurrir que no se disponga de ninguna componente (por ejemplo, servidores,
PCs ) para esta implementacin o que ciertos componentes ya existan, y que:
puedan utilizarse tal cual estn, sin que esto afecte las actividades que realiza
actualmente la organizacin, o que,
necesiten ampliarse:
instalar ms PCs,
ampliar componentes de las PCs actuales (Ej. ms RAM),
cablear nuevos puestos, etc.
En cualquiera de los casos se debern detallar las componentes que se citan en el punto 2, y luego ver
de qu forma se re-utilizan o se adquieren.
Unidad 4 Modelo Tecnologa
Pg.: 27 de 98

19. Componentes del modelo

Los componentes a definir para el modelo de tecnologa podrn incluir adems de las requeridas para el
funcionamiento del sistema, las que sean necesarias para su desarrollo, si el mismo se realiza como
parte de la organizacin que va a utilizar el sistema.
Tecnologa en produccin (necesaria para implementar el sistema)

Definir claramente las siguientes componentes:
Hardware:
o Clientes o Puestos de trabajo
Definir la cantidad de puestos donde se implementar el sistema
Croquis de las instalaciones y ubicacin de cada puesto de trabajo
Definir si cada puesto ser PC o terminal y en caso de ser PC determinar:
Procesador
Disco rgido
Memoria
Dispositivos multimediales
o Impresoras
Definir la cantidad de impresoras a utilizar y su distribucin
Definir la tecnologa de impresin y caractersticas
o Servidores
Definir cantidad de servidores y utilizacin
Aplicaciones
Datos
Firewall
Web y / o correo
Croquis de las instalaciones y ubicacin de cada servidor
Definir para cada servidor:
Procesador
Disco rgido
Memoria
Dispositivos de back up
UPS (Provisin Ininterrumpida de Energa)
o Otros (definir cantidad y distribucin)
Lectores de tarjeta, o cdigos de barra
Tiqueadoras
Carteles digitales
Multimedios, etc.
Pg.: 28 de 98

Software de base a nivel de servidores y de clientes

o Sistema operativo
Para el servidor (ej. Windows 2000, Linux)
Para las PC clientes (ej. Windows 2000 o Windows 98). Definir adems cantidad de
licencias necesarias.
o Motor de la Base de datos
Definir el motor y cantidad de licencias de Base de Datos necesarias para que los
usuarios utilicen el sistema. Segn los motores de base de datos estas licencias pueden
ser por puesto de trabajo o por usuario concurrente que utiliza una conexin a la Base de
Datos, por cantidad o capacidad del procesador donde se instala el motor , etc.
Definir en que servidor estar residente el motor.
o Lenguaje de programacin

Licencias para que corran las aplicaciones, si son necesarias (por ej., con Visual Basic
se genera un ejecutable, el cual no necesita de la adquisicin de licencias de lenguaje
para ser usado).
Definir donde estarn residentes los ejecutables.
o Otro software necesario
Visualizadores
Herramientas de oficina (procesadores de texto, planillas de clculo, etc)
Navegadores
Tipo de red
Dimensin de la red (LAN, MAN, WAN, INTERNET)
Topologa de la red
Tipo de cableado
Dispositivos de red (placas de red, hubs, routers, switches, etc)
Caractersticas de los componentes mencionados
Poltica de Backup
Definir qu informacin estar sujeta a Backup
Definir los tipos de Backups que se realizarn y con qu periodicidad
Determinar medios para hacerlo y rotacin de los mismos
Poltica de antivirus
Definir a qu nivel trabaja el antivirus, donde se instala y cmo se actualiza.
Arquitectura del sistema

1 capa
Cliente / servidor (2 capas)
3 capas
J2EE
Pg.: 29 de 98

Tecnologa para desarrollo (necesaria para desarrollar el sistema)

Definir claramente las siguientes componentes (con el mismo detalle que en el punto anterior)
Hardware
Puestos de trabajo
Servidores de desarrollo y de testing
Impresoras (dem Tecnologa de produccin)
Software
Lenguaje de programacin
Motor de base de datos
Pg.: 30 de 98

20. Modelo Fsico de Datos

21. Definicin:
En este modelo se disea todo lo relacionado a los datos requeridos para el funcionamiento del sistema
en el ambiente tecnolgico definido y segn las especificaciones no funcionales que se realicen. Se toma
como base el modelo de datos esencial el cual se transforma en el modelo de datos fsico. La
herramienta utilizada para obtenerlo es el Mapa Cannico Fsico
22. Pautas generales:

A continuacin se enumeran los conceptos sugeridos a tener en cuenta al disear los datos.
Codificar lo mximo posible

Beneficios:
Simplifica el mantenimiento de la estructura de datos
Simplifica las bsquedas de datos
Permite una identificacin clara y nica de cada suceso referenciado en la estructura de datos
Numeraciones / codificaciones internas

Asignacin de nmeros / cdigos internos, sin validez en general para los usuarios pero que permiten al
sistema el manejo de cdigos significativos, por ejemplo, sin mayores problemas en el mantenimiento y
actualizacin de los mismos.
Datos de clculo
Campos creados para facilitar el proceso de la informacin cuando el recorrido de las tablas es complejo,
o la creacin de informes u obtencin de resultados poseen tiempos de respuesta crticos. Estos campos
se actualizan desde el sistema y van llevando resultados temporales, subtotales, etc.
Creacin de ndices
Orden alternativo de una tabla (el principal es el de la clave) que permite agilizar la bsqueda de
resultados cuando los campos / atributos de bsqueda no son los mismos que componen la clave
primaria.
Campos para parametrizacin

Cuando se disean los sistemas podr decidirse usar parmetros que permitan la reutilizacin y
crecimiento del sistema de manera sencilla. Por ejemplo, al disear una pantalla de consulta de cdigo
(ayuda descriptiva), esta podra reusarse para otras tablas si uno de los parmetros al llamarla es el
nombre de la tabla, de igual manera para la cantidad de columnas a mostrar, etc.
Permisos
La organizacin de los datos deber permitir el control de los accesos a los mismos. Esto conduce a
disearlos de manera tal que pueda definirse por usuario sobre que datos podr trabajar y que podr
hacer con los mismos. dem para las opciones de la interfaz que los usuarios tendrn habilitadas, ej. El
men de altas de un producto.
Unidad 5 Modelo Fsico de Datos
Pg.: 31 de 98

Funciones provistas por los motores de bases de datos

El motor de una base de datos puede permitir la instrumentacin de ciertas funciones, validaciones sin
necesidad de programarlas desde el lenguaje, sino que ya vienen provistas por dicho motor.
Pero en esta etapa de diseo es necesario determinar las que se implementarn.
Por ej. el control de integridad referencial entre las diferentes tablas madres-hijas, store procedures (o
procedimientos almacenados que permiten el manejo de operaciones de insert, update, delete, select con
una tabla), triggers (procedimientos que se disparan automticamente al darse una condicin y pueden
generar informacin de auditora).
Adems es necesario tener en cuenta:
Que para disear el modelo fsico de datos es muy importante recolectar datos acerca de:
Volumen de las tablas, mximo y promedio de crecimiento (por ej. para dimensionar el tamao de
disco necesario, y ver si coincide con lo definido en el modelo de tecnologa, donde debera
hacerse realizado el mismo clculo)
Frecuencia de cada evento (por ej. si un evento se usa una sola vez al mes, y resulta no tener la
performance adecuada , puede ser que no se realice ningn cambio al modelo de datos para
cambiar la performance, s se arribara a una solucin de este tipo si la frecuencia de uso es
diaria)
Tiempos de respuesta ante cada evento (existen procesos que sern crticos para su operacin y
necesitarn un determinado tiempo de respuesta para evitar por ej. colas en la atencin de un
cliente, respuesta rpida ante una atencin telefnica, etc.)
Unidad 5 Modelo Fsico de Datos
Pg.: 32 de 98


Una vez identificadas las interacciones con el entorno, mediante el empleo de flujos de interfase en el
modelo de procesadores (anlisis), estamos en condiciones de formalizar el modelo de usuario.
MODELO DE USUARIO: Etapa en donde se disean interfases y se plasman en herramientas las
interacciones con el usuario, teniendo en cuenta todas las caractersticas definidas en el modelo de
tecnologa y el modelo de datos fsico.
En todos aquellos lugares en que se identific una relacin con el medio ser necesario construir una
interfase (pantalla, men, ventana de aviso, etc.), para interactuar con los usuarios del sistema.
Las herramientas que se utilizarn aqu como estndares son:
Pantallas (de entrada y salida del sistema, consultas y reportes del mismo)
EI diseo en el Modelo de Usuario estar estrechamente relacionado a dos aspectos principales:
el tipo de personas que sern usuarias en cada interaccin en particular del sistema, y
la clase de procesos que se realizarn en el sistema (procesos batch, cargas de datos masivas,
consultas para la toma de decisiones, entrada de datos, etc.).
USUARIO: Quien va a tener contacto directo con el sistema
Tipos de usuarios
La diversidad de habilidades humanas, know-how (cunto conoce el usuario?), estilos y personalidades
constituyen un desafo muy grande para los diseadores de software y traen aparejados distintos puntos
que deberan ser debidamente estudiados.
Estos son:
1) Tiempo de aprendizaje: Cunto puede demandarle al usuario acostumbrarse a todas las
funciones del sistema al punto de poder usarlo sin depender de un manual de ayuda.
2) Frecuencia de uso: Cunto tiempo pasar el usuario en contacto con el sistema. (Ej.: uso diario,
semanal, etc.)
3) Objetivos del usuario: Qu se propone lograr con el sistema, un objetivo simple demandar un
diseo simple.
4) Impacto de los errores del usuario: Cul es la probabilidad de que el usuario cometa un error y
cmo responde el sistema ante un error del usuario.
5) Impacto de los errores del sistema: Cmo responde el usuario ante un error del sistema.
Conocer al usuario debe ser un objetivo del diseador para poder satisfacer sus necesidades.
Si pensamos que el grado de calidad que alcance el sistema estar estrechamente relacionado con el
grado de satisfaccin que obtenga el usuario respecto a sus expectativas y necesidades originales,
entonces el modelo del usuario jugar un papel primordial dentro de toda la etapa del desarrollo de
sistemas.
Otro aspecto importante al clasificar a los usuarios es definir el nivel de permisos para cada uno de ellos,
ya sea para tareas individuales o eventos completos a los cuales pueden acceder unos u otros.
Este punto debe ser tenido en cuenta al disear el sistema, pues se debern agregar procesos de control
de permisos ante determinadas tareas, como as tambin definir las caractersticas que poseer la
pantalla o reporte a disear.
Unidad 6 - Modelo Fsico Externo
Pg. 33 de 98

Entre estas caractersticas podramos sealar algunas como:

1) Tipo y magnitud de las ayudas.
2) Uso de interfaces grficas o de caracteres. (el uso de interfaces grficas es el que se
corresponde naturalmente con el diseo orientado a eventos)
3) Volumen de informacin mostrada.
4) Controles de errores, etc.
Se tienen tres grandes grupos de usuarios:
Usuarios novatos
No poseen ningn conocimiento sobre el sistema y adems poco conocimiento de computacin.
Pueden llegar a tener un conocimiento superficial de las tareas que lleva a cabo el sistema, solo
superficial, y una gran ansiedad por conocer algo nuevo, lo cual dificulta el aprendizaje.
En estos casos en necesario restringir el vocabulario a un pequeo nmero de tareas. Cuanta ms
informacin se le d al usuario respecto de lo que est haciendo el sistema, mejor; como as tambin
respecto de los errores.
El uso de manuales y ayudas online juegan un papel esencial.
Usuarios intermitentes
Son aquellos capaces de mantener el conocimiento respecto de las tareas ejecutadas por el sistema,
pero tienen dificultad en recordar aspectos computacionales.
En estos casos es aconsejable el uso de lenguajes de comandos con estructuras simples y
consistentes y la utilizacin de menes.
Secuencias consistentes de acciones, mensajes significativos e indicaciones que ayuden al usuario a
darse cuenta si las ejecuciones son correctas o no.
En estos casos son muy tiles los manuales de usuario adecuadamente organizados.
Usuarios frecuentes o expertos

Son aquellos familiarizados tanto con las tareas como con los conocimientos acerca del uso de
computadoras, ste tipo de usuario se siente satisfecho si, por ejemplo, puede contar con una macro
u otra forma abreviada que le permita reducir el nmero de pasos para acceder a un determinado
lugar.
Este usuario ha tenido ya contacto con un buen nmero de diferentes interfaces.
Cuando un sistema debe soportar ms de una clase de usuario, deben identificarse adecuadamente las
tareas, entendindose por tarea a los procesos con los cuales se relacionan cada uno de los tipos de
usuario y que ejecutarn cada uno de ellos.
Las frecuencias relativas de las acciones sern importantes a la hora de determinar el tamao de un
conjunto de comandos o de la estructura de un men.
Las acciones que son ms frecuentes debern ser simples y rpidas de ejecutar.
Cuando se disea un sistema, toma un papel trascendental el armado de cada una de las pantallas.
Existe una diversidad de posibilidades en cuanto a ventanas, fuentes, colores, etc.; que influirn en la
calidad del producto final.
En procesos interactivos se deben tener en cuenta factores tales como:
Cantidad de personas promedio esperando a ser atendidas,
Tiempo de respuesta del sistema,
Interfase del mismo con el operador, etc.
Pg. 34 de 98

Si no se tienen en cuenta estas caractersticas se puede caer en el error de construir un sistema

que no sea utilizado, debido a que ocasiona demoras y altera el buen desenvolvimiento de los
procesos del negocio. Hay que tener en cuenta tambin que se puede llegar a construir un
sistema sumamente eficaz, con un alto nivel en cuanto a su funcionamiento pero que debido a la
pobreza de las interfaces, el usuario lo rechaza.
Pg. 35 de 98

Niveles de conocimiento del Usuario

Sintaxis:
Conocimiento de los dispositivos. (teclados, caracteres de control, etc.)
Conocimiento de los comandos. (Enter, Ctrl-D, Logout)
Capacidad de alternar entre sistemas.
Semntica:
Conceptos de computacin:
Objetos. (archivos, prrafos, lneas)
Acciones. (copiar, mover, eliminar)
Roles de los usuarios

Adems de tener en cuenta los tipos de usuario que interactuarn con nuestro sistema, se deber poner
especial atencin a los roles que cubrirn cada uno con el mismo.
Que es un rol de un usuario? Es un nivel de usuario que agrupa una o varias funciones (u opciones de
men) las cuales estarn habilitadas en el sistema para todos aquellos usuarios que tengan dicho rol.
Por ejemplo para el sistema de alumnado, los roles usuarios son: Bedeles, No docentes, Alumnos,
Docentes, Administrador.
Dentro del rol Bedeles estarn los usuarios Juan Gmez y Jos Garca, y las opciones que tendrn
habilitadas son:
Alta de regularidades de alumnos,
impresin de actas de examen,
consulta de situacin de alumnos,
inscripcin de alumnos a exmenes,
etc.
Dentro del rol Alumnos estarn habilitados cada uno de los alumnos de la facultad y tendrn habilitadas
las opciones:
inscripcin a materias,
inscripcin a exmenes,
consulta de situacin en una materia,
emisin de certificado analtico,
etc.
Para manejar diferentes roles usuarios (o grupos usuarios) es necesario determinar los mismos y detallar
correctamente las opciones que estarn habilitadas a cada uno.
Esto se puede realizar a travs de una tabla con el siguiente esquema:
Opciones del sistema
Rol1
.....
Rol n
Nombre opcin 1
Nombre opcin 2
..............
Nombre opcin n
Luego se deber indicar el rol que tendr cada usuario al que se permita el acceso al sistema.
Pg. 36 de 98

Esto se puede formalizar a travs de una nueva tabla donde se detalla el nombre del usuario, datos que
lo identifican y el rol que realizar (esta opcin se utiliza generalmente cuando recin se inicia el sistema)
o a travs del formulario de alta del usuario (que contiene nombre y otros datos de identificacin) donde
se indica tambin el rol del mismo. Esta segunda opcin es individual: generalmente se utiliza para
anexar nuevos usuarios al sistema, luego de haberse iniciado el mismo.
Usuarios
del
sistema(Apellido,
nombre, Tipo-doc, nro doc)
Usuario 1
Rol1
.....
Rol n
Usuario 2
..............
Usuario n
Para manejar los usuarios y sus roles en forma dinmica, facilitando el mantenimiento del sistema y la
creacin / eliminacin de usuarios y roles es necesario utilizar un sub-modelo de seguridad que se debe
tener en cuenta al realizar el modelo de fsico de datos.
Luego en el modelo del fsico externo se pueden completar las tablas diseadas con los datos especficos
de cada rol / grupo, opciones / permisos y usuarios que estarn habilitados para utilizar las mismas.
24. Diseando en Windows

El diseo en Windows o diseo visual se caracteriza, principalmente, porque el diseador desarrolla su
tarea dndole importancia a aspectos visuales que anteriormente en el diseo estructurado, no se tenan
en cuenta.
La posibilidad de uso de funciones y objetos nuevos hace que en el proceso de creacin de una interfaz
haya que pensar en diferentes y variadas opciones de solucin cuando antes slo existan algunas
contadas posibilidades.
Adems de esto hay que destacar las diferencias visuales evidentes entre una pantalla usada en DOS y
una en Windows.
Disear en Windows hace que el diseador olvide por completo de cmo se gestiona el mouse, de
permitir al usuario mediante ciertas teclas moverse de un lugar a otro, etc. Todo esto, y ms, queda
implcito en los estndares de Windows y no hace falta disearlo, con lo cual el diseador puede
centrarse en lo que realmente le interesa, el funcionamiento lgico del sistema.
El diseo en Windows nos permite crear aplicaciones robustas y tiles que hagan un uso completo de la
interfaz grfica de usuario (GUI). El diseador puede pensar en crear aplicaciones multimedia
sencillamente, uso de grficos, etc.
Un sistema operativo visual como puede ser Windows ayuda al diseador a ser ms productivo,
proporcionndole herramientas apropiadas para los diferentes aspectos del desarrollo de GUI. Puede
crear la interfaz grfica de la aplicacin haciendo uso de objetos de manera grfica. Puede definir las
propiedades de los objetos para concretar su apariencia y comportamiento.
Pg. 37 de 98

Pantalla tipo D.O.S.
Pantalla Tipo Windows
Controles de Windows
La mayora de los controles ms comunes usados en toda interfaz estn presentes en ambos tipos de
diseo, slo que en Windows poseen otra apariencia. Adems hay una infinidad de controles en Windows
que no existen en diseos tipo DOS.
Los controles pueden ir desde Labels (etiquetas), Cajas de Dilogo, Botones de Chequeo y opcin
Botones, Frames (marcos), Listas, Grillas de diversos tipos, Pictures o cajas de imgenes, rboles o
TreeViews, Combos de Opciones, hasta controles poco comunes de Navegacin, de Seleccin y arrastre
o de control interno de puertos, etc.
Bsicamente la diferencia est en que los controles comunes antes usados en forma limitada, presentan
diferentes estilos de uso en Windows, ms all de la tpica apariencia 3D de los mismos (cajas de texto
que parecen hundidas en la pantalla por ejemplo) y adems se suman otros, antes impensados.
Pg. 38 de 98

25. Orientacin a Eventos

Particularidades
Windows es un entorno gestionado por eventos, que son generados por una accin exterior por parte del
usuario, como el movimiento del mouse, la pulsacin de una tecla o de uno de los botones del mouse, o
bien por el propio Windows.
Las aplicaciones diseadas para funcionar sobre este entorno tienen que trabajar dirigidas por estos
eventos, y no siguiendo la metodologa clsica de programacin utilizada en sistemas como DOS.
Por ejemplo, una aplicacin no puede estar esperando exclusivamente a que el usuario realice una
entrada por teclado cuando se presenta el formulario, porque el usuario en ese momento podra pulsar
sobre cualquier otro control del formulario, y la aplicacin sin embargo estara an esperando la entrada
por teclado.
Por ello, el diseo en Windows, debe ser realizado pensando que los procedimientos pueden ser
convocados cuando es necesario por el propio Windows ante un requerimiento del usuario. Cada uno de
los controles que podemos disear en el formulario, incluido el propio formulario, pueden recibir en el
futuro, una serie de eventos, en unos casos comunes y en otros especficos de cada control.
Cmo funciona una aplicacin controlada por eventos?

Un evento es una accin reconocida por un formulario o control. Las aplicaciones controladas por eventos
responden a dicho evento convocado. Cada formulario y control tiene un juego de eventos predefinido.
Un buen diseo contemplar todas las opciones que puedan pensarse para cada control. Aunque los
controles en un diseo tipo Windows reconocen automticamente un juego predefinido de eventos (sobre
un botn se puede clickear con el mouse, pero no desplegar un men, por ejemplo), el diseador es
quien determina si responden a un evento concreto (uno que crea necesario para el objetivo planteado) y
cmo lo hacen.
Esto es lo que ocurre en una tpica aplicacin controlada por eventos:
La aplicacin se inicia y automticamente se carga y presenta el formulario inicial.
Un formulario o control recibe un evento. El evento puede ser provocado por el usuario (por ejemplo,
presionando una tecla) o indirectamente por el cdigo (por ejemplo, un evento Load cuando se
carga un formulario).
Si fue diseado y posteriormente programado un procedimiento correspondiente a dicho evento, se
ejecuta.
La aplicacin espera el siguiente evento.
Diseo de pantallas
El diseo de pantallas es el plasmado o dibujo de la interfaz que interactuar con el usuario, incluyendo
en dicho dibujo todos los controles que se utilizarn, de modo que finalmente represente el producto
terminado.
1. Objetivos medibles en un diseo de interfaces
Estos objetivos deben ser medidos previamente a la construccin de los modelos de diseo. Estas
cantidades influenciarn en la forma y los criterios utilizados en la construccin del sistema de acuerdo a
los grupos de usuarios expresados anteriormente.
Tiempo de aprendizaje:
Grado de complejidad del sistema respecto del tipo de usuario que interactuar
con la aplicacin. En este punto se debe tener especial cuidado con el o los
usuarios posibles de cada una de las interfaces del sistema. Se deber poner
especial nfasis en las ayudas, textos ilustrativos, grficos (en casos de
informacin para la toma de decisiones, volumen de informacin en la pantalla,
Pg. 39 de 98

posibilidad de carga masiva de informacin sin tener que utilizar el mouse en

forma restrictiva para poder ingresar un nuevo registro, etc.).
Tiempo de realizacin de una tarea:

Es importante que se preste especial atencin a las interfases de aquellos eventos cuyo tiempo
de respuesta sea crtico para que la misma sea lo ms gil posible.
Tasa de errores del usuario:

Grado en que sern permitidos errores por parte del usuario. Esta medida estar estrechamente
relacionada al tipo de usuario.
Hay casos en los que a determinados usuarios se necesita solamente avisarle que se ha
producido un error, a otros hay que indicarle adems que acciones debe realizar para
solucionarlo o no producirlo nuevamente.
Tambin es importante la informacin que se muestra por pantalla para avisar qu acciones
deben realizarse antes de cometer un error o prevenir dichos errores(ej. salir sin guardar), sobre
todo a usuarios que son del tipo novatos.
Satisfaccin subjetiva:
Referida a las expectativas del usuario respecto de la funcionalidad, interfase, velocidad de
respuesta, etc. que posea el sistema.
Por un lado el sistema debe cumplir con todos y cada uno de los puntos definidos en el anlisis
que fueron relevados al usuario, pero por el otro, tiene que hacer un uso ptimo de los recursos
disponibles.
El otro aspecto a tener en cuenta es la calidad de las interfaces con el usuario. La mayora de los
usuarios estn acostumbrados a trabajar con buena cantidad de objetos, con posibilidades de
hacer drag and drop, etc. Esos usuarios no conciben que un sistema desarrollado, adems de
cumplir con sus requerimientos funcionales, posean interfaces tecnolgicamente atrasadas en el
tiempo, y que para realizar sus tareas diarias deban cambiar abruptamente de entorno.
2.

Reglas tiles para el diseo de interfaces

Permitir el uso de atajos a usuarios frecuentes.
Ofrecer retroalimentacin de informacin.
Permitir deshacer lo hecho.
Poner el control del lado del usuario.
No obligar a recordar largas secuencias.
3.

Prevencin de errores
Completar las secuencias incompletas
Slo aceptar comandos correctos
Capturar la atencin del usuario (intensidad, color, fonts, grficos, conos)
Mejorar la calidad de los mensajes de error.
Pg. 40 de 98

Herramientas de trabajo
Bosquejo de pantallas y descripcin de procesos
Toda pantalla puede tener diferentes niveles de diseo y, por supuesto, en etapas preliminares se puede
bosquejar pantallas e ir dndole forma de acuerdo a los requerimientos planteados por los usuarios.
Ver generalidades y tipos de pantallas ( ABMC, listados, consultas, menes) en apunte Anexo U9Modelo Fsico externo.
El Diagrama de Transicin de Estados es una herramienta muy til para la miniespecificacin de
procesos de tiempo real y para expresar el comportamiento de interfaces con el usuario.
Se puede definir al diagrama de transicin de estados como:
Herramienta de especificacin de transiciones ante la presencia de estmulos
externos.
Modela:
a) el comportamiento del sistema
b) las acciones que en el ocurren
c) las causas por las cuales esas acciones se producen
Elementos:
a) Transicin
b) Estado
c) Accin
CONDICION DE
d) Condicin
INGRESO
TRANSICIN EN EL
MISMO ESTADO
CONDICION
DE SALIDA
ESTADO
CONDICIN
TRANSICIN
ACCIN
ESTADO
Ver ejemplo, y estndares utilizados para su construccin en apunte Anexo U9 - Modelo Fsico Externo.
El Diagrama de Transicin de Estados puede representar los diferentes estados de una pantalla (como
en el ejemplo) o tambin puede representar el juego de estados y transiciones de varias pantallas.
El grado de profundidad e importancia que se le da a un diagrama es subjetivo y depende de las
necesidades y la ptica del diseador. Esto por ejemplo puede influenciar en la inclusin o no de una
transicin.
Pg. 41 de 98

El diagrama de interaccin es una herramienta muy til para reflejar los efectos que producen las
interacciones del usuario con el formulario, adems de los efectos de la derivados de la ejecucin
de eventos propios del mismo (Ej. load).
Ver generalidades, estndares utilizados para su construccin y otro ejemplo en apunte Anexo U9-Modelo
externo.
Ejemplo : Presin sobre un botn para salir del formulario

Acciones
ME
Click en Salir:
sale
de
CmdSalir
TxtNombre
Click
Unload
Explicacin:
La presin sobre el botn (evento click en control Salir) es representada por la lnea que posee
una explicacin del evento en la primer columna.
Sobre la lnea adems est explicado el evento principal que ocurrira, y la lnea viaja hacia el
objeto del formulario al cual apuntara el evento.
El rectngulo representa un proceso desarrollado (en un futuro sera una porcin de cdigo) que
dispara la salida del formulario (segunda lnea de vuelta al formulario (objeto ME)).
La finalizacin es con un crculo, que sera la porcin nativa del lenguaje que descarga la
pantalla.
Sobre la lnea se aclara Unload (Descarga).
26. Diseo de la ayuda

Algunos tipos de ayuda a tener en cuenta son:
Ayuda fija en el cdigo. Se generan pantallas con el texto de la ayuda escrito en ella en el momento
de la programacin.
Ayuda parametrizada en Base de Datos. Se crea una tabla de ayuda en la Base de Datos y se la
llama desde una ventana dentro de la aplicacin, con un parmetro se indica qu registro de ayuda
tiene que mostrar.
Ayuda con HTML. Se crean documentos HTML que se relacionan mediante hipervnculos y permiten
ser llamados desde la aplicacin.
Ayuda de Windows. Se crean archivos de ayuda de Windows (*.HLP), los que se llaman usando el
WinHelp.
Hipertextos
Los archivos de ayuda HLP y las pginas HTML son dos tipos de implementacin de hipertexto. A pesar
que son similares, tambin tienen muchas diferencias. Existen pros y contras para cada sistema. La
siguiente tabla ofrece una comparacin de alguno de los puntos ms importantes.
Pg. 42 de 98

HLP
HTML
Presentacin consistente. (El visualizador es

siempre el mismo)
Los browsers pueden ser diferentes y cada uno soporta

diferentes funciones.
Ventanas Popup con ayuda.
No hay Popups.
Funcin de bsqueda.
No tiene funcin de bsqueda.
Botones para Navegacin.
No hay Botones para Navegacin.
No permite imgenes transparentes.
Acepta imgenes transparentes y comprimidas. (GIF,

JPG)
No soporta fondos.
Acepta diferentes tipos de fondo.
Soporta WMF y BMP.
No soporta WMF ni BMP.
No soporta JPG ni GIF.
Soporta JPG y GIF.
No soporta imgenes en 256 colores y ms.
Soporta imgenes en 256 colores y ms.
Soporte limitado para sonidos y animaciones. Soporte para sonidos y animaciones que mejora
continuamente.
Un sistema de informacin complejo se
puede representar con un nico archivo.
(consume menos espacio en disco)
Un sistema de informacin complejo debe representarse

con varias pginas Web. (consume ms espacio en
disco)
Soporta diferentes familias de fonts y

tamaos de letras.
No soporta diferentes familias de fonts y tamaos de

letras como un estndar en los distintos tipos de
navegadores de Web.
El compilador de ayuda no siempre muestra

adecuadamente las vietas y listas
numeradas.
Las vietas y listas numeradas funcionan

adecuadamente. (excepto cuando se usa Word 97)
Ms fcil distribuir al estar comprendida en

un solo archivo.
Distribucin ms compleja. (varios archivos HTML, ms

los archivos de imgenes)
Pg. 43 de 98

27. Definicin
En este modelo se describe la lgica, la estructura y la especificacin interna del sistema, que servir en
la siguiente etapa del ciclo de vida (Codificacin) para que el programador pueda codificar las distintas
aplicaciones componentes del mismo.

Para dicho diseo habr que tener en cuenta conceptos que si bien no aplicaremos en forma directa son
necesarios para mantener una buena modularizacin y reusabilidad de partes del sistema, contribuyendo
en forma directa a aumentar la calidad del mismo. Dichos conceptos se exponen a continuacin.
29. Acoplamiento
Muchos aspectos de modularidad pueden ser comprendidos solamente examinando mdulos (futuras
secciones de cdigo o programas) en relacin con otros mdulos. Decimos que dos mdulos son
totalmente independientes si cada uno puede funcionar completamente sin la presencia del otro. Esta
definicin implica que no hay conexin entre los mdulos, directa o indirecta, implcita o explcita, obvia o
no. Pero tener mdulos completamente independientes en nuestro sistema es un ideal imposible de
alcanzar, lo que necesitamos es definir y controlar el nivel de dependencia, "Acoplamiento", que existe
entre los elementos del sistema.
Acoplamiento es una medida de la intensidad de la conexin entre mdulos.
Luego, mdulos altamente acoplados son juntados por fuertes conexiones; y mdulos menos acoplados
son juntados por dbiles conexiones; los mdulos que no poseen ningn tipo de acoplamiento, no tienen
interconexiones y son independientes.
Obviamente nosotros buscaremos siempre construir mdulos dbilmente acoplados, esto es, sistemas en
los cuales podamos estudiar (hacer debug o mantenimiento) un mdulo sin tener que conocer mucho
acerca de los otros mdulos del sistema.
Acoplamiento es un concepto abstracto, es el grado de interdependencia entre mdulos, que puede ser
pensado como la probabilidad que, en codificacin, debug o modificacin de mdulos, un programador
tenga que tomar en cuenta algo de otro mdulo. Si dos mdulos son altamente acoplados, entonces
habr una alta probabilidad de que un programador tratando de modificar uno de ellos tenga que hacer
un cambio en el otro. Claramente, el costo total del sistema estar altamente influenciado por el grado de
acoplamiento entre los mdulos.
Examinaremos a continuacin los cinco diferentes tipos de acoplamiento que pueden ocurrir entre un par
de mdulos.
En orden a su importancia estos son:
BAJO
Tipo de Acoplamiento
de datos
de estructura de datos
de control
comn
de contenido
ALTO
Unidad 7 Modelo Fsico Interno
BUENO
MALO
Pg. 44 de 98

Acoplamiento de datos
Dos mdulos tienen acoplamiento de datos si se comunican por medio de parmetros. Los parmetros
por medio de los cuales se comunican son elementos de datos simples, o tablas homogneas (tablas en
las cuales cada una de las filas contiene el mismo tipo de informacin).
Calcular total a facturar
Total factura
Monto total factura

Tipo de Cliente
Calcular Monto del IVA
Acoplamiento de estructura de datos

Dos mdulos tienen acoplamiento de estructura si ellos refieren a la misma estructura de datos, pero el
mdulo subordinado no utiliza todos los elementos de la estructura. La estructura de datos en comn
puede ser por ejemplo un registro compuesto por varios campos. La siguiente figura contiene tres
mdulos acoplados por medio de una estructura (datos-cliente).
Emitir Factura
Cod-Cliente
Datos Cliente
Datos Cliente
Recuperar Datos Cliente
Imprimir Cabecera
Este tipo de acoplamiento se da cuando se le pasa a un mdulo ms datos de los que l necesita, por
ejemplo la estructura "datos cliente" est compuesta de seis tems de datos, y de stos, el mdulo
"Imprimir cabecera", solo usa tres. Esto no quiere decir que no usemos estructuras de datos como
parmetros, al contrario son muy aconsejables, lo que hay que hacer es pasar solo los tems de datos
necesarios, ya sea como parmetros separados o como estructuras de datos. En los nicos casos en que
se justifica resignar este tipo de acoplamiento es cuando se pasan estructuras con ms informacin que
la necesaria dado que luego el mdulo ser reusado en otra situacin con los dems datos.
Pg. 45 de 98

Acoplamiento de control
Dos mdulos tienen acoplamiento de control si uno pasa al otro, un elemento de informacin para
controlar la lgica interna del otro.
Recuperar Registro de
Clientes
Bandera
Registro
Maestro
Registro
Transitorio
Controlar Sistema DE I/O
El parmetro de control "bandera" podr tener dos valores diferentes que condicionarn la accin a tomar
por el mdulo "Controlar sistema de I/O".
En los casos de acoplamiento de control, el mdulo subordinado no se comporta como una caja negra.
Si el parmetro de control es pasado en direccin inversa, otra clase de falla de particionamiento
aparece, sta es inversin de autoridad, esto significa que un subordinado le da una orden al mdulo
padre. Este tipo de acoplamiento es inevitable por ejemplo en los casos en que un mdulo subordinado
debe comunicarle al llamador que se ha cancelado un proceso.
Ingresar Datos Cliente
Cod-Cliente
Control
Validar Existencia Cliente
Acoplamiento comn
Dos mdulos tienen acoplamiento comn si refieren al mismo rea comn de datos. Esto es que se han
definido variables globales que comparten distintos mdulos.
Acoplamiento comn es malo por cinco razones:
Un error, ya sea del programador o no, en un mdulo que hace referencia a un rea comn de
datos puede aparecer en otro mdulo que usa el mismo rea comn, porque los datos no residen
localmente en un solo lugar.
Los mdulos que hacen referencia a datos globales quedan comprometidos a usar el mismo
nombre con el que se defini la variable global, ya que no pueden cambiarlo.
Algunas veces las reas globales pueden ser drsticamente utilizadas, por ejemplo cuando
diferentes mdulos usan el mismo rea para almacenar diferente informacin. En determinados
casos la variable "bandera1" puede significar "Error de bsqueda", y en otro Insuficiente Stock
Pg. 46 de 98

Programas con gran cantidad de variables globales son muy difciles de comprender para los
encargados de mantenimiento, porque se torna complejo saber que datos son utilizados en un
mdulo en particular.
Se hace muy complicado identificar qu mdulos deben ser modificados si cambia un elemento
de datos que pertenece al rea comn de datos.
Acoplamiento de contenido
Dos mdulos tienen acoplamiento de contenido si uno refiere a algo que reside en el interior de otro. El
caso tpico de este tipo de acoplamiento es la sentencia GOTO. Los lenguajes modernos de 4ta
generacin no permiten esta clase de sentencias, pero s la encontramos en lenguajes ms antiguos.
Estos casos violan el concepto de caja negra, con todos los problemas que ello implica, sobre todo en la
etapa de mantenimiento
Observaciones importantes
Dos mdulos pueden estar acoplados en ms de un sentido. En esos casos el acoplamiento es definido
por el peor de los tipos de acoplamiento exhibidos. Por ejemplo, si dos mdulos tienen acoplamiento de
estructura y comn, se dir que tienen acoplamiento comn, pues ste es peor que el anterior.
30. Cohesin
Un criterio muy importante utilizado para evaluar la forma en la que se particion un sistema es mediante
el estudio del grado de relacin entre mdulos; ste es el criterio de acoplamiento. Otro mtodo que nos
permite determinar el grado de particionamiento, es observando cmo las actividades que posee un
mdulo simple estn relacionados con otro mdulo; ste es el criterio de cohesin. Ambos, cohesin y
acoplamiento, son mtodos que nos permiten medir el grado de particionamiento. Dichos conceptos son
independientes. La cohesin determina en qu medida el mdulo estar acoplado a otros mdulos.
Si se colocan en cada mdulo los procesos asociados especficamente a cada uno de ellos, la necesidad
de comunicacin entre ellos resultar menor, y dentro de cada uno quedarn solo las cosas
estrechamente asociadas entre s.
Todo esto nos permite dar la siguiente definicin:
Cohesin es la medida de la intensidad de la asociacin funcional de los elementos que residen
en un mdulo.
Entendindose por elemento a una instruccin, un grupo de instrucciones, una llamada a otro mdulo, o
una pieza de cdigo que lleva a cabo un trabajo.
En sntesis, lo que trataremos de obtener son mdulos altamente cohesivos, cuyos elementos estn
estrechamente relacionados entre s. Adems, los elementos de un mdulo no deben estar fuertemente
relacionados con los elementos de otro mdulo, porque esto nos provocara acoplamiento entre los
mismos.
Asegurndonos que todos los mdulos tienen buena cohesin es el mejor camino para minimizar el
acoplamiento entre ellos. La idea de cohesin la inici Larry Constantine a mediados de los aos sesenta.
El se interes en aprender porqu la gente crea cierto tipo de mdulos, en examinar las mtricas relativas
a la cohesin y las ventajas y desventajas de cada tipo de stas. El trmino cohesin fue tomado de la
sociologa, donde significa relacin entre humanos dentro de un grupo.
Despus de esos estudios y luego de sucesivos refinamientos, Stevens, Myers, Constantine y Yourdon
desarrollaron una escala de cohesin como medida para ser aplicadas a mdulos, los resultados son
explicados a continuacin.
Pg. 47 de 98

En orden a su importancia estos son:

ALTA
Tipo de Cohesin
BUENA
Mantenibilidad
Pruebas
Caja Negra
Funcional
Caja no completamente Negra
Secuencial
Comunicacional
Procedural
Caja Gris
Temporal
Lgica
Caja Blanca o Transparente
Coincidental
BAJA
MALA Mantenibilidad
A continuacin se detallarn los distintos tipos de cohesin.
Cohesin funcional
Un mdulo que posee cohesin funcional contiene elementos que en su conjunto contribuyen a la
ejecucin de una y solo una tarea relacionada a un problema. Ejemplos de cohesin funcional podran
ser:
Calcular el coseno de un ngulo
Verificar la sintaxis
Leer registro de transmisin
Calcular punto de impacto del misil
Calcular salario neto
Ntese que cada uno de estos mdulos tienen un nico propsito. Cuando el mdulo padre llama a
cualquiera de estos se llevar a cabo solo una tarea sin involucrar ninguna otra actividad ms.
Se debe observar que algunos mdulos con cohesin funcional son demasiado simples. Leer
transaccin" esta obviamente haciendo una funcin simple, pero no se puede asegurar que "Calcular
salario neto" est realizando solo una tarea cuando tienen que realizar varios y complicados clculos. El
punto es que a pesar de la complejidad del mdulo, si se puede dividir en subfunciones que realicen cada
una de las tareas, entonces obtendremos mdulos funcionalmente cohesivos.
Realizar esta divisin es a veces una tarea muy complicada. El factor crucial es decidir el nivel de
cohesin en aquellos mdulos que no pueden dividirse en funciones
Pg. 48 de 98

Cohesin secuencial
Un mdulo con cohesin secuencial es aquel en el cual se agrupan funciones solo porque la salida de las
primeras sirve como entradas de las siguientes actividades.
Para determinar el nivel de cohesin de los mdulos, se debe realizar la siguiente pregunta: Cmo se
relacionan cada una de las actividades que lo componen ?. Si la respuesta es que la salida de una sirve
como entrada de la prxima entonces dichas funciones debern ser divididas en mdulos distintos.
Un ejemplo de cohesin secuencial es:
Registro formateado y validado
Registro Fuente
Formatear y validar
Registro
Se puede observar en el ejemplo cmo la salida de la primer actividad (formatear registro) es la entrada
de la segunda (validar registro).
Un mdulo con cohesin secuencial es fcil de identificar, porque si su nombre es representativo,
seguramente tendr una conjuncin "y" que une las tareas a dividir.
Cohesin comunicacional
Un mdulo con cohesin comunicacional es uno cuyos elementos son utilizados en actividades que usan
la misma salida o entrada de datos.
Supongamos que queremos realizar algunas actividades con un libro tales como:
1. Buscar el ttulo
2. Buscar el precio
3. Buscar el cdigo
4. Buscar el autor
Estas cuatro actividades estn relacionadas pues todas ellas trabajan sobre una misma entrada de datos,
el libro, por lo tanto el mdulo poseer cohesin comunicacional.
Otro ejemplo podra ser:
Estado de Cuenta del Cliente
Nro de
Cliente
Cuenta
del
Nombre del Cliente
Determinar detalle del Cliente
Las dos actividades que realizan bsquedas usan el mismo dato de entrada (Nmero de cuenta de
cliente). El acoplamiento que genera un mdulo con cohesin comunicacional es comnmente aceptable.
En el ejemplo anterior es posible que en otro evento del sistema se necesite buscar el nombre de un
cliente pero no le interese su estado de cuenta, en este caso, si se hubieran dividido las dos funciones,
podran rehusarse por separado cada una de ellas.
Otro problema que puede traer la cohesin comunicacional al compartir cdigo de dos actividades dentro
de un mdulo, es que al querer modificar una de ellas sin querer que se afecte a la otra.
Pg. 49 de 98

Veamos por ejemplo la siguiente figura:

Tabla
de
Empleados
Salario
de
Salario Calculado
Producir reporte de salario y calcular

salario de los empleados
Detalle del reporte de
salario
de
los
empleados
Escribir
Casi siempre se podr mejorar la mantenibilidad si se divide un mdulo con cohesin comunicacional en
estructuras separadas, con cohesin funcional en cada uno de ellas.
Los mdulos con cohesin secuencial y comunicacional son bastante parecidos. Poseen bajo
acoplamiento, pues pocos de sus elementos estn relacionados con los elementos de otros mdulos.
La principal diferencia entre ellos es que los mdulos con cohesin secuencial operan como una lnea de
ensamble, las actividades individuales deben ser llevadas a cabo en un orden especfico. Pero en
mdulos con cohesin comunicacional el orden de ejecucin no es importante.
Cohesin procedural
Cuando alcanzamos la cohesin procedural estamos cruzando las fronteras de la facilidad de
mantenimiento de los mdulos. Los mdulos con cohesin procedural son aquellos que poseen
elementos involucrados en actividades diferentes y posiblemente no relacionadas. Un ejemplo podra ser:
Registro de Salida
Registro de Entrada
parcialmente editado
Leer, editar y escribir algo
Mdulos con cohesin procedural tienden a ser compuestos de piezas de funciones que tienen poca
relacin entre s, excepto que lleven a cabo una orden especfica en un momento preciso de tiempo.
"Leer, editar y escribir algo" finalizan el contacto cuando escriben el registro de salida, y comienza el
contacto con el mdulo siguiente cuando lee y edita en el registro de entrada. Es tpico en la cohesin
procedural que los datos enviados al mdulo y los que ste devuelve tengan muy poca relacin. Es
tambin tpico que cada uno de los mdulos paseo resultados parciales (Ej.: el parmetro de salida
"registro de entrada parcialmente editado") Los mdulos con cohesin procedural tienden a hacer solo
parte del trabajo necesario.
Cohesin temporal
Un mdulo con cohesin temporal es aquel cuyos elementos estn involucrados en actividades que estn
relacionadas en el tiempo. Un ejemplo se da cuando se actualizan los datos ingresados en una tarea o
evento de diseo.
Pg. 50 de 98

Es comn que dichas funciones sean realizadas al final, por razones de integridad. Comnmente se
agrupan todas las actualizaciones en un nico mdulo que se llama "Actualizar". De esta forma se estn
juntando tareas que muchas veces tienen poco que ver, por ejemplo una actualizacin es completamente
distinta a una insercin, como tambin actualizar Datos Clientes es diferente a actualizar Datos Compra .
Una manera correcta de realizar dichas funciones sera:
Actualizar
Insertar Datos del

Cliente
Actualizar Datos del Cliente
Insertar datos de la compra
Un mdulo con cohesin temporal tiene problemas parecidos a los de la cohesin comunicacional, pues
los programadores se ven tentados a compartir cdigo entre actividades relacionadas solo por el instante
de tiempo en el que se realizan, por lo cual sern difciles de reusar posteriormente.
Cohesin lgica
Mdulos con cohesin lgica son aquellos cuyos elementos forman parte de actividades de una misma
categora general, en la cual las actividades ejecutadas son seleccionadas desde fuera del mdulo.
Un mdulo con cohesin lgica contiene un nmero de actividades de la misma clase general. Para usar
el mdulo, se debe escoger las piezas necesarias dentro de ese subconjunto.
Las actividades en un mdulo son forzadas a compartir la nica interfase del mdulo. Un ejemplo en el
cual podemos ver cohesin lgica es el siguiente.
Bandera
IVA Cliente
Calcular IVA Cliente segn

bandera sea = 1 o = 2
Podemos observar en este ejemplo cmo las actividades que se llevan a cabo en el mdulo dependen
del parmetro de control "bandera", cuyo valor es asignado desde fuera del mdulo. Este tipo de
cohesin trae grandes problemas en la etapa de mantenimiento.
Cohesin coincidental
Un mdulo con cohesin coincidental es aquel cuyos elementos no tienen ninguna relacin entre s.
Un mdulo con cohesin coincidental es similar a uno con cohesin lgica: Estas actividades no estn
nunca relacionadas por flujos de datos ni por flujos de control.
Sin embargo las actividades en la cohesin lgica estn en la misma categora o pertenecen a un mismo
grupo genrico; en un mdulo con cohesin coincidental, esto no es as.
Pg. 51 de 98

31. Herramienta: Diagrama de Composicin

Es un diagrama en donde se representa la lgica interna del formulario, especificando los objetos
participantes con sus mtodos, eventos y propiedades y explicando cada uno de ellos. La estructura
propuesta es la siguiente:
Nombre del formulario:
Descripcin del funcionamiento del formulario:
Propiedades no estndares del formulario:
<nombre propiedad 1>: <valor 1>
<nombre propiedad n>: <valor n>
Control:<nombre del control 1>
Propiedades no estndares del control
Descripcin de eventos del control
<nombre de evento 1>: <descrip.evento 1>

.....................................
................
...........................
<nombre de evento n>: <descrip.evento n>
..................................
Control:<nombre del control n>

......................................
................
..........................
Ejemplo: Parte de un Diagrama de Composicin de ABMC

frmabmcgrupos
Descripcin del funcionamiento del formulario: En esta pantalla se pueden realizar las tareas
de alta, baja, modificacin y consulta de los distintos grupos de usuarios del sistema

MaxButton = False
MinButton = False
Control: cmdAgregar

Click: Vaca los campos de edicin y permite
ingresar los nuevos datos
Control: cmdModificar

Click: Habilita los campos de edicin para que
se los pueda modificar
Control: cmdGuardar
Pg. 52 de 98

Click:
Graba los datos en la tabla grupos
5. Bibliografa
Pg. 53 de 98

32. Introduccin
La prueba del software es un elemento crtico para la garanta de calidad del software, y representa un
ltimo repaso de las especificaciones, del diseo y la codificacin.
Durante las fases anteriores, el ingeniero de software intenta construir el software partiendo de un
concepto abstracto y llegando a una implementacin tangible.
Es en esta etapa donde el ingeniero crea una serie de casos de prueba que intentan demoler el
software que ha sido construido.
La gente que desarrolla software es por naturaleza constructiva. La prueba requiere que se descarten
ideas preconcebidas sobre la correccin del software que se acaba de desarrollar y superar cualquier
conflicto de intereses que aparezca cuando se descubran errores.
33. Conceptos bsicos

Definicin
Tradicionalmente existe una concepcin incorrecta del trmino probar, tal como:
Probar es demostrar que no hay errores presentes en un programa.
Probar es mostrar que el programa realiza correctamente las funciones esperadas.
Estas definiciones describen casi todo lo contrario de lo que se debe considerar como prueba.
La concepcin tradicional ha sido considerar que un caso de prueba que NO descubre errores es exitoso.
Sin embargo, dado que no descubre error alguno, la prueba constituye un desperdicio de tiempo y dinero,
por lo que no parece adecuado llamarla exitosa.
Bajo este punto de vista la mejor definicin de prueba del software es:
Proceso de ejecutar un programa con el fin de encontrar errores.
Esta ltima definicin nos plantea un cambio de concepcin con respecto a lo que se considera prueba
exitosa y no exitosa.
No hay que comenzar la prueba del software pensando que el programa est libre de errores, conviene
comenzar suponiendo que el programa tiene errores (lo que seguramente es verdad) y tratar de encontrar
la mayor cantidad posible de stos.
Objetivos de la prueba
La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto
hasta entonces.
Una prueba tiene xito si descubre un error no detectado hasta entonces.
Lo primordial es disear pruebas que sistemticamente detecten diferentes clases de errores, hacindolo
con la menor cantidad de tiempo y esfuerzo. Sin embargo, hay algo que no puede hacer la prueba:
La prueba no puede asegurar la ausencia de defectos;
slo puede demostrar que existen defectos en el software.
Encargado de realizar la prueba

La prueba del software puede crea conflictos de inters; el desarrollador no debera probar el producto
por l desarrollado. Para lograr esto se debe crear el llamado Grupo Independiente de Prueba (GIP).
Unidad 8 Prueba del Software
Pg.: 54 de 98

El GIP realiza las pruebas en un entorno de prueba, separado del de desarrollo y del de produccin.
Adems de las razones antes mencionadas, la organizacin del GIP se justifica por:
El mejoramiento de la eficiencia de la etapa de prueba
La mejora en la calidad total del producto
El mejoramiento de la eficiencia se dar por la especializacin del grupo, la utilizacin de tcnicas y

herramientas desarrolladas para el proceso de prueba.
Pautas generales
La definicin del resultado esperado a la salida del programa es una parte integrante y necesaria
del caso de prueba. Si el resultado esperado de la prueba no ha sido predefinido cabe la posibilidad
que un resultado plausible pero errneo se interprete como correcto.
Un programador no debe probar sus propios programas.
Examinar concienzudamente el resultado de cada prueba. Ocurre que errores que suelen aparecer
casualmente son errores expuestos por las casos de prueba pero que se escaparon a la deteccin
por falta de inspeccin.
Evite los casos de prueba desechables. Es una prctica sentarse frente al monitor, improvisar un
caso de prueba y pasarlo al programa. El problema est en la prdida de tiempo, ya que cuando se
tenga que probar nuevamente (por haber corregido algn error) se tendr que reinventar la prueba.
Uno de los mayores problemas de la prueba es determinar cundo finalizar la misma.
La probabilidad de encontrar errores adicionales en un mdulo del programa es proporcional al

nmero de errores ya encontrados en dicho mdulo. Contrariamente a lo que la intuicin indicara,
esto ha sido verificado en muchos programas.
No altere nunca el programa para que la prueba resulte ms fcil.
La prueba como cualquier otra actividad debe comenzar con la definicin de sus objetivos.
34. Estrategia de prueba

Una estrategia trata de integrar las tcnicas de diseo de casos de prueba en una serie de pasos
planificados que se van llevando a cabo a medida que se va construyendo el software; es decir, establece
los pasos a llevar a cabo como parte de la prueba, cundo se debe planificar y realizar esos pasos y
cunto esfuerzo, tiempo y recursos sern requeridos.
Las estrategias que se plantean son:
Prueba de unidad Prueba de integracin
Prueba de validacin Prueba del sistema
Y poseen las siguientes caractersticas:
La prueba comienza a nivel de un mdulo, y se avanza hacia fuera hasta lograr la integracin
completa del sistema.
En distintos puntos son necesarios a la vez distintas tcnicas de prueba.
La prueba y la depuracin son actividades diferentes. Independientemente de la estrategia de

prueba que se este utilizando, una vez terminada la misma, si se encontraron errores sern
depurados y se volver a realizar la prueba (retesting).
Pg.: 55 de 98

Proceso de la prueba
La prueba de software es un proceso iterativo que finaliza cuando se alcanza los valores prefijados para
tal fin.
Existen en le mercado herramientas informticas que automatizan el proceso de prueba (documentacin
y ejecucin de los casos de prueba) pero cuyo costo hace difcil su utilizacin.
A continuacin se diagrama el proceso general de prueba de software:
Configuracin
de prueba
(1)
Ejecutar testing
o prueba
(el GIP)
Configuracin
de software
Cambios
Resultados
Resultados de
la prueba
(2)
Depurar
programa (el
programador)
Retesting
Se proporcionan dos entradas al proceso de prueba:

1. una configuracin del software que incluye la especificacin de requerimientos del software, la
especificacin de diseo y el cdigo fuente.
2. una configuracin de prueba que incluye un plan y procedimiento de prueba, casos de pruebas
y resultados esperados.
Se lleva a cabo la prueba y se comparan los resultados de la prueba con lo esperado; si se descubren
errores, estos sern solucionados durante la depuracin o debugging (Ver el apunte anexo de esta
Unidad : Debugging). A medida que se van recopilando y evaluando los resultados de la prueba,
comienza a vislumbrarse una medida cualitativa de la calidad y fiabilidad del software.
Si el funcionamiento parece ser correcto y los errores encontrados son fcilmente corregibles, se puede
sacar una de dos conclusiones:
la calidad y la fiabilidad del software son aceptables.
las pruebas son inadecuadas para encontrar errores serios.
Prueba de Unidad
Es el proceso de verificacin de la menor unidad de software: el mdulo. Se probarn:
La interfaz
Las estructuras de datos locales
Las condiciones lmite
Los caminos independientes
Los caminos de manejo de errores

Se aplican las tcnicas de caja negra y caja blanca.
Pg.: 56 de 98

La prueba de unidad comienza cuando se han terminado de escribir y corregir las sintaxis del cdigo
fuente correspondientes al mdulo. Dado que el mdulo no es un programa independiente es necesario
crear cierto entorno para que pueda ejecutarse.
Prueba de Integracin
La prueba de integracin realiza pruebas sobre grupos de mdulos o de subsistemas integrados y/o
cooperantes, o del sistema global.
Se aplican las tcnicas de caja negra y caja blanca.
Prueba de Validacin
El software est validado cuando funciona de acuerdo a las expectativas del cliente, las cuales estn
definidas en las especificaciones de requerimientos de software.
Se aplica la tcnica de caja negra.
Pruebas alfa y beta
Son pruebas de validacin que permiten que el cliente valide los requerimientos. Se utilizan cuando se
cree que existen errores que slo el usuario final puede descubrir o cuando se tiene un producto de
software a ser utilizado por muchos clientes.
Prueba alfa: es la conducida por el cliente en el lugar de desarrollo bajo la supervisin del jefe de
desarrollo.
Prueba beta: en los lugares donde se correr el sistema, con los clientes, bajo condiciones de
operacin naturales. Los clientes registran todos los problemas que encuentran durante la prueba
e informan a intervalos regulares al equipo de desarrollo.
Prueba del Sistema

En esta estrategia de prueba el software es incorporado a otros elementos del sistema (hardware, datos)
y se realizan pruebas de integracin del sistema y de validacin para verificar que se han integrado
adecuadamente todos los elementos del sistema y que funcionan de acuerdo a lo esperado.
Su objetivo es la comprobacin del sistema global, normalmente se realizan pruebas de cuatro tipos
distintos:
Prueba de recuperacin de fallos
Tiene por objetivo forzar al software a fallar y verificar que la recuperacin se lleve a cabo
adecuadamente.
Si la recuperacin es automtica hay que evaluar el correcto funcionamiento de los casos que la
componen (reinicializacin, recuperacin de datos de arranque, etc.).
Si la recuperacin requiere de intervencin humana se deber evaluar los tiempos medios de
reparacin para determinar si est dentro de los lmites aceptables.
Prueba de seguridad
Intenta verificar que los mecanismos de proteccin realmente protejan al sistema de la
penetracin indebida (protecciones de la informacin).
El encargado de esta prueba debe ubicarse en el lugar del que intenta penetrar al sistema en
forma no autorizada. Todo recurso es vlido para este tipo de prueba: tratar de conseguir las
claves, producir errores intencionales en el sistema para entrar en la etapa de recuperacin, etc.
Evidentemente si se le da a una persona el tiempo y los recursos suficientes, terminar por
penetrar el sistema; por lo tanto, el objetivo es lograr que el costo de penetrar el sistema sea
mayor que el valor de la informacin.
Pg.: 57 de 98

Prueba de resistencia
Est diseada para enfrentar al sistema con situaciones anormales, es decir una mayor demanda
de recursos, tanto en cantidad como en frecuencia. Esto tiene por objeto responder a la pregunta:
a que potencia se puede poner a funcionar un sistema antes de que falle?
Prueba de rendimiento
Se utiliza para probar el rendimiento del software en tiempo de ejecucin. Se lleva a cabo en
cada etapa del ciclo de prueba, pero no puede asegurarse el rendimiento total del sistema hasta
que no se lo tenga totalmente integrado. Muchas veces se realiza simultneamente con las
pruebas de resistencia.
35. Casos de prueba

Diseo de casos de prueba
Dado que la prueba depende de la ejecucin controlada del cdigo debemos proveer valores para que
aquel se ejecute con stos. Cada conjunto de datos creados para la ejecucin del cdigo, junto con el
resultado esperado de la correcta corrida, se denomina caso de prueba.
Datos + ResultadoEsperado = CasoDePrueba
Es necesario crear un conjunto suficientemente grande y amplio para encontrar tantos errores como sea
posible y asegurar la presencia de todas las funciones que fueron originariamente especificadas.
Existen muchas tcnicas para el desarrollo de casos de prueba. El procedimiento ms simple es permitir
a la persona que prueba crear los datos a su gusto y usarlos. Esto puede funcionar ms o menos bien,
dependiendo del grado de conocimiento que se tenga sobre el sistema, pero no es adecuado para un
testeo completo del producto.
La siguiente es una lista de la posibles formas de determinar casos de prueba:
creacin intuitiva
conjunto exhaustivo de todos los datos posibles
datos que representen todos los datos disponibles
datos que representen el uso real del sistema
datos que causen un efecto deseado
datos que causen la ejecucin de todas las sentencias
datos que causen la ejecucin de todos los caminos
datos diseados para ser improcesables
Evidentemente no es posible realizar todas las anteriores, por lo cual es necesario definir un objetivo de
la prueba.
Sin un objetivo podra ser suficiente seleccionar datos distribuidos aleatoriamente sobre el conjunto de
datos posibles. Sin embargo, estudios sobre la utilizacin de esta tcnica demostraron que descubre solo
el 60% de los errores.
Cualquier producto de ingeniera puede ser probado de dos formas:
1. Conociendo la funcin especfica para la que fue diseado el producto se pueden llevar a cabo
pruebas que demuestren que cada funcin es completamente operativa (prueba de caja negra).
2. Conociendo el funcionamiento del producto se pueden desarrollar pruebas que aseguren que la
operacin interna se ajusta a las especificaciones y que todos los componentes internos se han
comprobado en forma adecuada (prueba de caja blanca).
Pg.: 58 de 98

Modelo de planilla para documentar casos de prueba

Planilla para Casos de Prueba
Sistema:
Planilla Nro.:
Men/opcin:
Fecha:
(camino para ejecutar el programa)
Evento (nombre de la opcin):

(nombre del programa o mdulo)
Testing a cargo de :
Analista/programador:
N de
caso
Caso
Datos de Prueba
Resultado esperado
Comentario
36. Tcnicas de prueba

Prueba de Caja Blanca
El objetivo de esta tcnica es garantizar que:
se ejecuten por lo menos una vez todos los caminos independientes de cada mdulo
se ejecuten todas las decisiones lgicas en sus partes verdaderas y falsas
se ejecuten todos los bucles dentro de sus lmites operacionales
se utilicen las estructuras de datos internas para asegurar su validez
1) Prueba del camino bsico

Es una prueba de caja blanca que asegura que se ejecuten todas las sentencias del mdulo por lo menos
una vez. Sus caractersticas son:
permite obtener una medida de la complejidad del diseo
utiliza la medida obtenida para definir una serie de caminos de ejecucin y
crea casos de prueba que sigan estos caminos
Grafo de Flujo:
Flujo del control lgico mediante la siguiente notacin:
secuencia
If
while
until
Notacin:
Crculo
nodo (sentencias)
Flechas
aristas (flujo de control)
reas entre nodos y aristas
regiones
Nodo que contiene una condicin

nodo predicado
Una arista debe terminar en un nodo, aunque no represente ninguna sentencia procedimental.
Pg.: 59 de 98

Complejidad ciclomtica:
Es una mtrica del software que proporciona una medicin cuantitativa de la complejidad lgica de un
programa.
En la Prueba del Camino Bsico se define el nmero de caminos independientes de un programa y nos
da el lmite superior para el nmero de pruebas que asegure que se ejecuta cada sentencia al menos una
vez.
Un camino independiente se debe mover al menos por una arista que no haya sido recorrida
anteriormente a la definicin del camino.
Una combinacin de caminos no se considera un camino independiente (no incorpora ninguna arista
nueva).
Clculo de la complejidad ciclomtica:
Hay tres formas de calcular la complejidad ciclomtica:
1. Nmero de Regiones del Grfico
(ComplejCiclomtica = NroAristas
2. V(G) = A N + 2
3. V(G) = P + 1
- NroNodos + 2)
(ComplejCiclomtica = NodosPredicados + 1)
Pasos a seguir para la Prueba de Camino Bsico:

1. Construir un grafo del flujo del procedimiento.
2. Calcular la complejidad ciclomtica. Esto es el nmero de caminos distintos independientes. Este
nmero nos da un lmite superior al nmero de pruebas que deben realizarse para que se
ejecuten al menos una vez todas las sentencias del mdulo.
3. Determinar cules son los caminos independientes. El nmero de caminos coincide con la
complejidad ciclomtica. Cada camino queda explicitado especificando los nodos que lo
componen.
4. Preparar los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico. Para
esto se deben preparar los datos de manera que cumplan con las condiciones que habilitan cada
camino y especificar los resultados esperados de cada caso de prueba.
5. Al final se comparan los resultados de las pruebas con los resultados esperados. Cuando se
hayan ejecutado todos los caminos, se habrn ejecutado al menos una vez todas las sentencias.
Ejemplo de Prueba del Camino Bsico
Evento: Click en el Botn CmdAgregar del formulario FrmAbmProyectos
Private Sub cmdAgregar_Click()
1
2
3
4
5
6
7
8
9
10
fAlta=True
InvalidarControles
DatAbm.Recordset.AddNew
i = 0
while i <= Me.Controls.Count 1
If TypeOfMe.Controls(i) Is TextBox Then
Me.Controls(i).Text =
End If
TxtCodProy.SetFocus
i = i + 1
Pg.: 60 de 98

11
12
end while
End Sub
Complejidad Ciclomtica (Cantidad de caminos a tomar)

1. Nro. de Regiones del Grfico = 4
2. V(G) = Nro. Aristas Nro. Nodos + 2
V(G) = 11 9 + 2 = 4
3. V(G) = Nro nodos Predicados + 1
V(G) = 3 + 1 = 4
Pg.: 61 de 98

1, 2, 3,4
10
11
12
Caminos:
Camino 1: 1,2,3,4,5,12
Camino 2: 1,2,3,4,5,6,8,9,10,11,12
Camino 3: 1,2,3,4,5,6,7,8,9,10,11,12
Camino 4: 1,2,3,4,5,6,7,8,9,10,11,5,12
Casos de Prueba:
N de Caso
caso
Datos de Prueba
Resultado
esperado
Comentario
Prueba del
Camino 1
Valor(i) = Cantidad de controles en el Ninguno

formulario = 0
Prueba del
Camino 2
Valor(i) = Cantidad de controles en el Ninguno

formulario = 1
No es caja de texto
Prueba del
Camino 3
Valor(i) = Cantidad de controles en Blanquea la caja

de texto
el formulario = 1
Cajas de texto = 1
Prueba del
Camino 4
Valor(i) = Cantidad de controles en el Falta resultado

formulario >= 1
Cajas de texto >= 1
Pg.: 62 de 98

2) Prueba de bucles
Es una prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de
bucles. Clases de bucles:
Bucles simples. Se deben aplicar las siguientes pruebas:

o Saltar totalmente un bucle (caso del WHILE).
o Pasar una sola vez por un bucle.
o Pasar dos veces por un bucle.
o Hacer m pasos por el bucle con m < n (n: mximo nmero de pasos)
o Hacer n-1, n y n+1 pasos por el bucle
Bucles anidados. No se pueden realizar el mismo nmero de pruebas, ya que ste crece
rpidamente por la anidacin. Sin embargo se deben someter a las siguientes pruebas:
o Comenzar en el bucle ms interior utilizando a todos los dems bucles en sus valores
iniciales.
o Llevar a cabo las pruebas de bucles simples con el ms interior, mientras se mantienen
los exteriores en sus valores mnimos.
o Progresar hacia fuera llevando a cabo las pruebas para el siguiente bucle, pero
manteniendo los dems bucles exteriores en sus valores mnimos y los dems bucles
anidados con valores tpicos.
o Poner un contador no condicional en cada bucle y comparar el contador con los valores
tericos.
Bucles concatenados. Estos pueden probarse de la misma forma que los bucles simples,
siempre y cuando cada uno sea independiente de los restantes.
Bucles no estructurados. Esta clase de bucles debe evitarse en lo posible, pues no es posible
realizar pruebas sobre ellos.
Prueba de Caja Negra

Estas pruebas se centran en los requerimientos funcionales del software. Permite definir conjuntos de
condiciones de entrada que ejerciten completamente todos los requerimientos funcionales del programa.
No se trata de un enfoque alternativo a las pruebas de la caja blanca, sino ms bien un enfoque
complementario que trata de descubrir distintos tipos de errores, entre estos tenemos:
Funciones incorrectas o ausentes
Errores de interfase
Errores de estructuras de datos
Errores de rendimiento
Errores de inicio y terminacin
Tcnica de la particin equivalente

Se dirige a la definicin de casos de pruebas que descubran clases de errores, de manera tal que se
reduzca el nmero total de pruebas a desarrollar.
Esta tcnica consiste en dividir el rango de datos de entrada en clases de datos (bsicamente clase
vlida y clase invlida) de la que se derivan casos de pruebas para cada una de ellas.
Si una condicin de entrada especifica un rango, se define una clase de datos correcta vlida y
dos clases de datos invlidas; una de las clases invlidas abarca el rango de datos invlidos a la
derecha del rango vlido y la otra a la izquierda del rango de datos vlidos.
Si una condicin de entrada requiere un valor especfico se define una clase vlida y dos
invlidas
Pg.: 63 de 98

Si una condicin especifica un miembro de un conjunto, se especifican una clase vlida y una
invlida
Si una condicin de entrada es booleana se define una clase vlida y una invlida
Rango
V I
Valor Especfico
V I
Miembro de conjunto
V I
Booleana
V I
Ejemplo:
Supongamos un sistema que debe registrar el cdigo de los artculos (este cdigo tiene 4 dgitos
y debe comenzar con 1 o 2); y tambin debe registrar la marca del fabricante del artculo. Esta
marca puede estar comprendida en un conjunto de marcas (A, B, C y D).
El ingreso del cdigo es una condicin de entrada de rango con valores vlidos entre 1000 y
2999, por lo que seleccionamos dos clases invlidas (400 y 5250, por ejemplo) y una vlida
(1020).
La marca del fabricante es una condicin de entrada que especifica un conjunto, por lo tanto se
define una clase vlida (los elementos que pertenecen al conjunto) y una clase invlida (cualquier
otra marca que no pertenezca al conjunto de marcas). Seleccionaremos una vlida (B) y una
invlida (J).
Cdigo (Rango)
Marca (Miembro de conjunto)
Inv1
Vl
Inv2
400
1020
5250
Tcnica del anlisis de los valores lmite

Esta tcnica se basa en el hecho de que los errores, por razones no muy claras, tienden a darse en los
lmites del rango de entrada. Es una tcnica complementaria a la anterior que en lugar de seleccionar
cualquier elemento de una clase de datos, selecciona aquellos que estn en los lmites de la clase de
manera que:
Si la condicin de entrada establece un rango entre los valores a y b, entonces disear

casos de prueba para los valores a, b, a+1, b-1, a-1 y b+1.
Si la salida / entrada de datos debe estar comprendida en un rango, generar casos de prueba
que produzcan como salida / entrada los valores mximos y mnimos.
Si existen estructuras de datos con lmites preestablecidos, por ejemplo un array, asegurarse
que se ejercite la estructura en esos lmites.
Tcnica de la prueba de validez de datos

Se utiliza en sistemas que posean una interfaz de segunda generacin, es decir donde el usuario genera
rdenes especficas con una determinada sintaxis. Las siguientes son algunas de las pruebas especficas
que se pueden aplicar a este tipo de sistemas:
Especificar rdenes con sintaxis incorrectas
Entradas sintcticamente correctas pero fuera de secuencia
Escribir una orden parcialmente correcta y dar por terminada la entrada.
Proporcionar rdenes correctas, pero con parmetros incorrectos o en exceso.
Pg.: 64 de 98

37. Calidad de la etapa de prueba

La prueba es la ltima tarea dentro de las actividades de garanta de calidad. Aunque la prueba no
produce calidad directamente, nos asegura que el producto ser mejorado hasta alcanzar los niveles de
calidad fijados en las etapas anteriores.
A esta altura del proyecto puede surgir la tentacin de apresurar la prueba para lograr una rpida
liberacin del producto, descuidando la calidad de la prueba en s misma.
La utilizacin de mtricas relativas a la etapa de prueba nos puede ayudar a determinar en qu momento
finalizar la prueba de un producto de software.
Entre las tcnicas para determinar el momento de finalizacin de la prueba tenemos:
1. Se alcanz un determinado nivel de cobertura.
Este mtodo es el ms cuantitativo de todos. Nos permite establecer el nivel de cobertura
deseado que puede estar determinado por:
Ejecucin de un n% de las sentencias del mdulo.
Ejecucin de un n% de todos los caminos.
Ejecucin de todos los ciclos condicionales 0,1,...,k veces.

2. Hemos encontrado el nmero predicho de errores.
Esta tcnica requiere contar con una forma de calcular el probable nmero de errores a ser
encontrados en el software.
La prueba finalizara cuando se ha alcanzado una cifra de errores similar a la predicha.
La forma de calcular el nmero posible de errores es emprica, es decir basada en datos de
proyectos anteriores.
3. El ratio de descubrimiento de errores ha cado
Esta tcnica se basa en la suposicin que el grfico de errores descubiertos tiene
120
100
80
60
40
20
0
1
10
un dibujo de este tipo:

Se decidir terminar la prueba cuando la curva alcance su punto de inflexin en su porcin
descendente, pues a partir de este punto el costo y tiempo para descubrir un nuevo error ser
cada vez mayor.
En la grfica se ve que el ratio de descubrimiento de errores ha cado y se ha estabilizado, por lo
tanto podra optarse por finalizar la prueba.
4. Se ha descubierto determinado porcentaje de los errores sembrados
Esta aproximacin se basa en el supuesto de que la completitud de la prueba puede medirse a
travs de la introduccin artificial de errores (sembrado de errores). Los errores sembrados que
faltan por descubrir es una indicacin de los errores reales que faltan por descubrir.
5. Se ha alcanzado un determinado nivel de confianza
Pg.: 65 de 98

Se puede definir la confianza como la probabilidad de no tener fallas durante un especificado

perodo de tiempo. Podemos usar como medida del tiempo entre fallas.
Se podra terminar la prueba cuando el tiempo medio entre fallas haya alcanzado una
determinada longitud.
6. Se ha acabado el tiempo asignado a la prueba
Este enfoque es sin duda el ms aplicado, aunque no recomendado.
Su efectividad depende por supuesto de la cantidad de tiempo asignada, la que puede ser mayor
o menor de la que es realmente necesaria (generalmente es mucho menor), y no tiene en cuenta
la calidad del producto.
38. Bibliografa
Pg.: 66 de 98

Anexo U1 Normalizacin
1. Optimizacin del Mapa Preliminar
Conceptos previos
Es en el Mapa de Informacin Preliminar donde explicitamos las vinculaciones entre las entidades: es
decir inter-entidad.
El prximo paso es optimizarlo para que pueda cumplir con los objetivos de todo Modelo de Datos.
Antes de comenzar a describir como optimizar, ser necesario volcar algunos conceptos o definiciones
que intervienen en este proceso.
Clave Candidata
Es posible que existan ms de un atributo o conjunto de atributos que puedan identificar unvocamente a
una ocurrencia de una entidad,. A estos se los llama claves candidatas.
Dicho de otra manera son todas las posibles claves de una entidad.
Ejemplo:
NroLegajo al igual que TipDocumento + NroDocumento podran ser pensadas, bajo ciertas
condiciones, como claves candidatas de la entidad Alumnos.
Clave Primaria
En el caso que haya varias claves candidatas, se elige una como identificador principal y a esa se la
llama clave primaria. Para indicarla en el Diccionario, se la subraya.
Ejemplo:
Se puede elegir NroLegajo como clave primaria de la entidad Alumnos.
Clave Alternativa
El resto de las claves candidatas que no hayan sido elegidas como primaria, se denominan claves
alternativas.
Ejemplo:
El TipDocumento + NroDocumento podran constituir una clave alternativa de la entidad Alumnos.
Dependencia Funcional
Para optimizar el Mapa de Informacin Preliminar, ser necesario analizar en profundidad cada una de
las entidades del mismo, las vinculaciones que existen entre los atributos o elementos de datos que
componen cada una, llamadas vinculaciones intra-entidad.
Adems, para el estudio de esas vinculaciones, apicaremos el concepto de dependencia funcional.
Sea una entidad E y sus atributos X e Y (E = X + Y), decimos que X determina funcionalmente e Y si y
solo si, para cada valor de X existe un nico valor de Y en todo instante.
En otras palabras, dado el valor de X, queda determinado unvocamente el valor de Y.
Se indica X Y
Ejemplos:
1. Sea la entidad Empleados = NroLegajo + NomEmpleado y la siguiente visin de contexto: el
sistema le asignar un nmero de legajo nico.
As, dado un nmero de legajo, hay un nico nombre de empleado que se corresponde con l.
Esto se indica:
Anexo U1 - Normalizacin
Pg.: 67 de 98

NroLegajo
Nombre
2. Sea la entidad
Libros = CodLibro + Titulo + Editorial + 1{NroEdicion + FecEdicion}n
y las siguientes visiones de contexto:
1) El sistema asignar un cdigo de libro nico
2) Un libro no puede ser editado varias veces
3) Un libro es editado por una nica editorial
4) Cada edicin tiene una nica fecha de edicin
Por lo tanto:
Ttulo
CodLibro
Editorial
NroEdicion
FecEdicion
Este esquema suele llamarse grafo de dependencias funcionales y representa las relaciones que existen
entre los atributos de una entidad.
Supongamos que ahora cambiamos la tercer visin de contexto:
3) Un libro puede ser editado por varias editoriales.
Tendremos los siguientes cambios:
Libros = CodLibro + Titulo + 1{Editorial + 1{NroEdicion + FecEdicion}n }n

Ttulo
CodLibro
Editorial
NroEdicion
FecEdicion
Dependencias completas y no completas

Volvamos al ejemplo:
CodLibro
Ttulo
Editorial
NroEdicion
FecEdicion
Titulo y Editorial dependen funcionalmente CodLibro
Titulo y Editorial dependen funcionalmente en forma no completa del par CodLibro + NroEdicion,
ya que para un valor de CodLibro + NroEdicion, corresponde un nico valor de Titulo y Editorial
Pg.: 68 de 98

Por lo tanto
Titulo y Editorial dependen funcionalmente en forma completa de CodLibro
Titulo y Editorial de penden funcionalmente en forma no completa de CodLibro y NroEdicion.
NOTA: De ahora en adelante, y salvo indicacin expresa, cada vez que hablemos de dependencias
funcionales, nos estaremos refiriendo a las que son completas
Carcter unvoco
El concepto de dependencia funcional tiene carcter unvoco y no biunvoco.
Hay dependencia funcional entre CodLibro y Editorial, porque al valor de CodLibro le corresponde un
nico valor de Editorial. Esto es suficiente para que exista dependencia funcional. Es evidente que aqu
no aparece el carcter biunvoco; es decir: a una entidad le corresponden muchos CodLibro y no uno
solo.
Supongamos la entidad
Empresa = CodEmpresa + RazonSocial + Domicilio + CUIT + SitTributaria
Como sabemos que el CUIT es nico para cada empresa, as como el cdigo que a cada una le asigna el
sistema, podemos graficar las dependencias funcionales entre CodEmpresa y CUIT de la siguiente
manera:
CodEmpresa
CUIT
Transitividad
Sea la entidad E y sus atributos X, Y y Z (E = X + Y + Z); donde X determina funcionalmente a Y, e Y
determina funcionalmente a Z. Entonces X determina funcionalmente en forma transitiva a Z
XYZ
Ejemplo:
Supongamos que tenemos:
Proveedores = CodProveedor + RazonSocial + Domicilio + Localidad + Categora + 1{CodProducto +
Cantidad}n
Y tenemos las siguientes visiones de contexto:
- El sistema asignar un cdigo nico al proveedor
- Un proveedor vende varios productos y cada producto se identifica con un cdigo
- Un producto puede ser vendido por varios proveedores
- Una localidad tiene una nica categora
El anlisis de las dependencias funcionales sera el siguiente:
CodProveedor
CodProducto
RazonSocial
Domicilio
Localidad
Categora
Cantidad
Pg.: 69 de 98

Normalizacin
Hasta ahora nos hemos puesto de acuerdo en ciertas definiciones bsicas y todava no hemos abordado
cmo optimizar nuestro modelo de datos para que pueda satisfacer los siguientes objetivos:
Estructura mnima
Que asegure la no prdida de informacin
Que facilite los procesos de mantenimiento (o ABM)
Mxima supervivencia
Es aqu donde aparece la normalizacin como herramienta para optimizar y poder lograr esos objetivos.
La normalizacin es una disciplina que, va la aplicacin sistemtica de una sucesin de pasos formales,
va transformando entidades originales en otras ms adecuadas (en funcin de los objetivos), basndose
en el significado de los datos tratando de modelar su estructura real.
2. Formas Normales
Son los estados por los que va pasando una entidad durante los sucesivos pasos de transformacin.
As se habla de una entidad en:
- 1ra forma normal
(1NF)
- 2da forma normal
(2NF)
- 3ra forma normal
(3NF)
- Forma normal de Boyce-Codd
(BCNF)
- 4ta forma Normal
(4NF)
- etc.
Cada forma normal representa un avance respecto a su predecesora.
Proceso de Normalizacin
Qu haremos?
De ahora en ms, a partir de un caso en particular:
definiremos las tres primeras formas normales
evaluaremos el cumplimiento de los objetivos
definiremos un criterio para reconocer cuales son las buenas descomposiciones
Presentacin del caso

Sea la entidad
Cantidad}n
Y un conjunto de visiones de contexto que determinan las siguientes dependencias funcionales:
CodProveedor
CodProducto
RazonSocial
Domicilio
Localidad
Categora
Cantidad
Pg.: 70 de 98

Observaciones:
- Cantidad es la parte que el proveedor nos vende de cada producto
- Categora depende de la localidad donde se domicilia el proveedor
Primera Forma Normal

Una entidad est en 1NF si no tiene atributos multivalor.
Esta definicin est ntegramente ligada al concepto de clave candidata, ya que elegir una clave
candidata asegura eliminar todos los atributos multivalor.
En nuestro caso, la nica clave candidata es CodProveedor + CodProducto.
Eligindolos como clave candidata, desaparecen los atributos multivalor. En cambio si se hubiera elegido
solo CodProveedor como clave, CodProducto + CantProvista seran grupos repetitivos o atributos
multivalor: para un valor de CodProveedor, habra varios vaslores de CodProducto.
Pasar a esta etapa (1NF) implica elegir una clave candidata.
RazonSocial
Domicilio
Localidad
CodProveedor
CodProducto
Categora
Cantidad
1NF Se elige una clave
Segunda Forma Normal

Una entidad est en 2NF si y solo si est en 1NF y todo atributo no clave depende de la clave en forma
funcionalmente completa.
Para satisfacer esta restriccin es preciso descomponer la entidad original en nuevas entidades.
CodProveedor
CodProveedor
CodProducto
RazonSocial
Domicilio
Localidad
Categora
Cantidad
Ahora al descomponer la entidad original en dos entidades, los atributos no clave de cada una de ellas,
dependen de la clave y ahora en forma completa.
Vemoslo a nivel de Diccionario de Datos
Antes de normalizar:
Cantidad}n
Pg.: 71 de 98

1NF
Proveedores = CodProveedor + CodProducto + Cantidad + RazonSocial + Domicilio + Localidad +
Categora
2NF
Proveedores = CodProveedor + RazonSocial + Domicilio + Localidad + Categora
Productos por Proveedor = CodProveedor + CodProducto + Cantidad
El proceso al llegar a 2NF termina rompiendo los grupos repetitivos, los cuales pasan a formar parte de
una nueva entidad dentro de la cual ya no son ms grupos repetitivos.
2NF se buscan dependencias completas (se eliminan los grupos repetitivos)
Tercera Forma Normal

Una entidad est en 3NF si y solo si est en 2NF y no existen dependencias funcionales entre atributos
no clave.
Veamos nuestro caso:
CodProveedor
Cantidad
CodProducto
CodProveedor
Localidad
RazonSocial
Domicilio
Localidad
Categora
Encontramos una dependencia funcional entre Localidad y Categora. Por lo tanto fue preciso
descomponerla en dos.
13
3NF Se eliminan las dependencias entre atributos no clave
Pg.: 72 de 98

3. Por qu conviene normalizar

A medida que abordamos las tres primeras formas normales vimos como la entidad original
desnormalizada fue reemplazada sin prdida de informacin por una estructura ms adecuada, teniendo
presente los objetivos que debera tener todo modelo de datos.
Pero, por qu ms adecuada? Veamos el caso presentado:
Para ello, representaremos la entidad en 1NF como una tabla:
CdProveedor
CodProducto
Razn Social
Cantidad
Domicilio
Localidad
Categora
100
20
Prez, Juan
12
Alem 934
Rosario
20
100
30
Prez, Juan
15
Alem 934
Rosario
20
100
40
Prez, Juan
20
Alem 934
Rosario
20
200
20
Lpez, Pedro
10
Bs.As. 720
Casilda
15
200
35
Lpez, Pedro
18
Bs.As. 720
Casilda
15
200
40
Lpez, Pedro
28
Bs.As. 720
Casilda
15
300
10
Peci, Jos
100
Maip 889
Rosario
20
Y centraremos nuestro anlisis en el cumplimiento del tercer objetivo: Facilitar los procesos de
mantenimiento o ABM.
Problemas con la 1NF

Altas
Supongamos que necesito decir que tengo un proveedor nuevo con Cdigo 400, su Razn Social es
Sols, Jos y es de Crdoba. Hasta tanto no le compre algn producto, no puedo incorporar esta
informacin, ya que el Cdigo Producto es parte de la clave.
Por lo tanto, tengo informacin en la realidad que no existe en el Modelo de Datos.
Bajas
Supongamos que el proveedor 300 no provee ms el producto 10. Si elimino esa ocurrencia, pierdo
informacin respecto a su Razn Social y su Domicilio.
Modificaciones
Supongamos que el proveedor 200 se muda. Es preciso modificar tres ocurrencias.
Por lo tanto, con la entidad en 1NF no se cumple el objetivo de minimizar la estructura de datos ni de
facilitar los procesos de mantenimiento.
Veamos qu sucede en 2NF:
CdProveedor
CodProducto
Cantidad
100
20
12
100
30
15
100
40
20
200
20
10
200
35
18
200
40
28
CodProveedor
Razn Social
Domicilio
Localidad
100
Prez, Juan
Alem 934
Rosario
20
200
Lpez, Pedro
Bs.As. 720
Casilda
15
Pg.: 73 de 98
Categora

300
Peci, Jos
Maip 889
Rosario
20
400
Sols, Jorge
Mitre 88
Crdoba
25
Los tres problemas anteriores se resolvieron:
Puedo incorporar los datos del proveedor 400, aunque todava no le compr ningn producto.
Si el proveedor 300 deja de proveer el producto 10, no pierdo sus datos.
Si el proveedor 200 se muda, slo debo modificar una ocurrencia.
Problemas con la 2NF

Altas
No puedo informar que la categora de Tucumn es 35 hasta no tener algn proveedor en Tucumn.
Bajas
Si elimino el proveedor 200, pierdo la informacin que la categora de Casilda es 15
Modificaciones
Supongamos que Rosario cambia de categora. Debo modificar dos ocurrencias.
Esto obliga a continuar buscando una estructura que cumpla mejor con los objetivos.
Veamos qu sucede en 3NF
CdProveedor
CodProducto
Cantidad
100
20
12
100
30
15
100
40
20
CdProveedor
Razn Social
Domicilio
Localidad
100
Prez, Juan
Alem 934
Rosario
300
Peci, Jos
Maip 889
Rosario
400
Sols, Jorge
Mitre 88
Crdoba
Localidad
Categora
Rosario
20
Casilda
15
Crdoba
25
Tucumn
35
Los tres problemas anteriores estn resueltos:
Puedo decir que la categora de Tucumn es 35, an sin tener proveedores all.
Puedo eliminar al proveedor 200, junto con todos los productos que me vende, sin perder
informacin sobre Casilda
Si Rosario cambia de categora, puedo informarlo modificando una sola ocurrencia.
Pg.: 74 de 98

Anexo U6 - Seguridad en bases de datos

Introduccin
El aspecto global de seguridad de los datos est muy vinculado al propio concepto de lo que es la base
de datos: "Un conjunto de datos integrados, adecuado a varios usuarios y a diferentes usos". Es el
propio uso concurrente de los datos el que, en muchos casos, genera problemas de seguridad que el
administrador de la base de datos debe paliar en la medida de lo posible.
La proteccin de los datos deber realizarse contra fallos fsicos (de memoria secundaria, de memoria
principal, etc.), fallos lgicos (de programacin, del sistema operativo, etc.) y fallos humanos, ya sean
stos intencionados o no.
Estos fallos alteran indebidamente los datos, los "corrompen", con lo que la base de datos ya no puede
servir a los fines para los que fue creada.
El Sistema Gestor de Base Datos (SGBD) facilita normalmente tres tipos de mecanismos:
para prevenir los fallos (subsistemas de control),
para detectarlos una vez que se han producido (subsistemas de deteccin) y
para corregirlos despus de haber sido detectados (subsistemas de recuperacin).
Actualmente se considera generalmente aceptado que la seguridad comprende tres aspectos
fundamentales:
Confidencialidad: no mostrar datos a usuarios no autorizados; comprende tambin la
privacidad (la proteccin de datos personales)
Integridad: permite asegurar que los datos no se han falseado
Disponibilidad: que la informacin se encuentre disponible
Hay que tener en cuenta que tanto las amenazas como los mecanismos para contrarrestarlas, suelen
afectar a estas tres caractersticas de forma conjunta.
As, por ejemplo, fallos del sistema que hacen
que la informacin no sea accesible pueden llevar
consigo una prdida de integridad.
Tambin debemos ser conscientes que las
medidas de seguridad que debern establecerse
en cuanto a los datos, no slo afectan al SGBD,
ya que comprenden el hardware y el sistema
operativo, las medidas de seguridad fsica, los
controles legales y organizativos (polticas,
procedimientos, normas, etc.).
Anexo U6 Seguridad en Bases de Datos
Pg.: 75 de 98

Confidencialidad
Autorizacin en sistemas de bases de datos
En un SGBD, al igual que sucede con el sistema operativo, existen diversos elementos bsicos que
ayudan a controlar el acceso a los datos. En primer lugar, el sistema debe identificar y autenticar al
usuario (sujeto), utilizando para ello algunos de las siguientes formas:
Cdigo y contrasea ( password ).
Identificacin por hardware.
Caractersticas bioantropomtricas (huellas dactilares, voz, retina del ojo, palma de la
mano, etc.).
Conocimientos, aptitudes y hbitos del usuario (estilo de pulsacin del teclado).
Informacin predefinida (aficiones, datos culturales, personales).
Como sabemos la forma ms usual es la primera en la que el usuario da su identificacin, el SGBD le
pide la contrasea y le concede el acceso al sistema, si ambos son vlidos.
Adems, el administrador o el propietario de los datos, deber especificar los privilegios que un usuario
autorizado tiene sobre los objetos de la base de datos (Se entiende por "objeto" cualquier elemento de la
base, sea sta relacional (tablas, vistas, dominios, etc.) u orientada al objeto (clases, servicios, etc.). Por
lo que no debe considerarse en este contexto de forma restringida a los conceptos de la orientacin a
objetos).
Estos privilegios incluyen, entre otros:
Utilizar una base de datos
Seleccionar datos
Actualizar (modificar, insertar o borrar) datos
Crear o actualizar objetos
Ejecutar procedimientos almacenados
Referenciar objetos
Indexar objetos
Crear identificadores
Conceder privilegios
Para facilitar la administracin de la confidencialidad, los SGBD suelen incorporar el concepto de perfil,
rol o grupo de usuarios, que rene una serie de privilegios por lo que el usuario que se asigna a un grupo,
hereda todos los privilegios del grupo.
Con esta informacin, el mecanismo de control de acceso se encarga de denegar o conceder el acceso
a los usuarios, garantizando tambin la integridad de los datos, en caso de tratarse de operaciones de
actualizacin.
Adems, hay que tener en cuenta que en un SGBD pueden existir diferentes tipos de autorizacin:
Autorizacin explcita, es la utilizada normalmente en los sistemas tradicionales, que
consiste en almacenar qu usuarios pueden acceder a los objetos con determinados
privilegios; para lo que se suele utilizar una matriz de control de accesos.
Autorizacin implcita, que consiste en que una autorizacin definida sobre un objeto puede
deducirse a partir de otras, por ejemplo, si se puede acceder a una clase en un SGBO
(Sistema de Gestin de Bases de Objetos) tambin se puede acceder a todos los ejemplares
(instancias) de la clase. Con este tipo de autorizacin se puede ahorrar espacio de
almacenamiento, a costa de consumir tiempo de proceso.
Pg.: 76 de 98

Autorizacin fuerte, en caso de que las autorizaciones deducidas a partir de la misma no

puedan ser invalidadas
Autorizacin dbil, en este caso se permiten excepciones sobre las autorizaciones implcitas
Autorizacin positiva, su presencia indica la existencia de autorizacin
Autorizacin negativa, es la negacin explcita de una autorizacin.
El tipo de autorizacin que se adopte depender entre otras cosas de:
- La poltica de control elegida, pudiendo el SGBD operar como sistema abierto (en el que un
usuario puede acceder a todos los objetos, excepto a aquellos que se prohiben explcitamente), o
como sistema cerrado (el usuario accede slo aquellos objetos para los que tiene autorizacin
previa).
- El modelo de datos, ya que utilizar, por ejemplo, autorizacin explcita en los SGBO consume
mucho espacio de almacenamiento, debido a la existencia de un gran nmero de elementos a
controlar (clases, subclases, servicios, objetos complejos, etc.)
Otra tcnica de proteccin de confidencialidad que puede utilizarse en los SGBD es la criptografa, que
permite transformar el contenido de la base, hacindolo ininteligible a cualquier usuario que acceda a la
misma sin la correspondiente clave de descifrado.
Por ltimo, cabe destacar las facilidades de auditora que ofrecen los SGBD, que permiten recoger en un
archivo de pistas de auditora (audit trail) ciertas operaciones realizadas por los usuarios, pudiendo, de
esta manera, detectar accesos no permitidos.
Un sistema de base de datos multinivel soporta datos con diferentes niveles o clases de confidencialidad
y usuarios con diferentes niveles de autoridad.
Una clase de confidencialidad consta de dos componentes: uno jerrquico (ALTO SECRETO,
SECRETO, CONFIDENCIAL, NO CLASIFICADO) junto a un conjunto de categoras no jerrquicas
(Finanzas, Ventas, Investigacin, etc.).
Disponibilidad
Los sistemas de bases de datos deben asegurar la disponibilidad de los datos a aquellos usuarios que
tienen derecho a ello, por lo que proporcionan mecanismos que permiten recuperar la base de datos
contra fallos lgicos o fsicos que destruyen los datos en todo o en parte.
Estos fallos van desde catstrofes como un incendio o un terremoto, sabotajes, fallos del sistema
operativo, fallos de disco, u otras cadas del sistema sea cual sea la causa que los ha provocado.
Aqu nos ocuparemos slo de los instrumentos que proporciona el propio SGBD para evitar o remediar
estos fallos, aunque hay que ser conscientes de que para obtener un sistema robusto podra ser
conveniente, bajo determinadas circunstancias, utilizar facilidades ajenas al SGBD, como, por ejemplo,
mquinas tolerantes a fallos ("fault tolerance"), sistemas de alimentacin ininterrumpida (UPS), tcnicas
de tolerancia para redes de comunicaciones, etc.
El principio bsico en el que se apoya la recuperacin en una base de datos es la redundancia fsica (ya
que para el usuario de la base de datos, a nivel lgico, la redundancia no es visible).
En lo que afecta al SGBD existen dos tipos importantes de fallos:
Los que provocan la prdida de memoria voltil, usualmente debidos a un corte del suministro
elctrico o por funcionamiento anormal del hardware
Los que provocan la prdida de contenido de memoria secundaria (no voltil), por ejemplo, el
producido al fallar las cabezas de un disco.
Pg.: 77 de 98

Concepto de transaccin
Lo importante ante cualquier tipo de fallo es asegurar que la base de datos queda en un estado
consistente, para lo cual se crean unidades de ejecucin denominadas transacciones, que pueden
definirse como "una secuencia de operaciones que han de ejecutarse de forma atmica", es decir, o se
realizan todas las operaciones que comprende la transaccin globalmente, o no se realiza ninguna.
El ejemplo clsico de una transaccin es la de una operacin bancaria de transferencia de dinero entre
dos cuentas corrientes, en la cual o bien se substrae dinero de una cuenta y se aade a otra, o bien no se
lleva a cabo ninguna operacin, pero lo que hay que impedir, es que por un fallo del sistema se restase el
dinero de una de las cuentas sin llegar a sumarlo a la otra.
Por definicin, la base de datos se encuentra en un estado consistente antes de que se empiece a
ejecutar una transaccin y tambin lo estar cuando la transaccin termine de ejecutar.
Propiedades de una transaccin

Las propiedades principales que debe poseer una transaccin son las siguientes
Atomicidad, en el sentido que hemos especificado anteriormente de que se ejecutan todas
las sentencias de una transaccin, o ninguna.
Preservacin de la consistencia, la ejecucin de una transaccin debe dejar a la base de
datos en un estado consistente.
Aislamiento, ya que una transaccin no muestra los cambios que produce hasta que finaliza.
Persistencia, ya que una vez la transaccin finaliza con xito, sus efectos perduran en la
base de datos.
Se suelen conocer por las siglas ACID (Atomicity, Consistency, Isolability, Durability).
Las transacciones pueden finalizar de dos maneras distintas:
Con xito, en cuyo caso las actualizaciones de que consta la transaccin se graban (commit), esto
significa que se hacen permanentes
Con fracaso, en cuyo caso debe ser restaurado el estado en el que se encontraba la base antes
de que empezara a ejecutarse la transaccin. Las actualizaciones de que consta la transaccin
debern, por tanto, "deshacerse" (rollback).
Los SGBD suelen gestionar las transacciones de forma implcita, ofreciendo adems al usuario
sentencias para la gestin explcita de transacciones.
Recuperacin en caliente
Al ocurrir un fallo que d lugar a prdida de memoria voltil, es preciso realizar la operacin que se suele
denominar "recuperacin en caliente", en la que el sistema consulta el archivo diario para determinar las
transacciones que hay que deshacer porque no han sido completadas y las que hay que rehacer porque,
si bien se han completado, no haban sido grabadas en la base de datos cuando se produjo el fallo.
Recuperacin en fro
En caso de un fallo de memoria secundaria que afecte a la base de datos, se lleva a cabo una
"recuperacin en fro", que consiste en utilizar una copia de seguridad de la Base de Datos, tambin
llamada de "respaldo" ( backup), que permitir, junto con los archivos diarios que se han ido produciendo
desde que se realiz la copia de seguridad, reconstruir la Base de Datos llevndola de forma consistente
a la situacin anterior a que se produjera el fallo.
Otro caso que se puede dar es el denominado "error fatal" que se produce cuando se pierde el archivo
diario grabado en un soporte, en este caso resulta imposible recuperar la base de datos a su estado
actual. La mejor solucin para evitar este problema es la que ofrecen algunos SGBD, que permiten la
gestin de copias del archivo diario en dispositivos independientes.
Pg.: 78 de 98

Tambin se puede duplicar la base de datos. En general todas las tcnicas de duplicacin se conocen
como "espejo" ( mirroring) o duplicacin ( duplexing).
Integridad
El objetivo en cuanto a la integridad es proteger la base de datos contra operaciones que introduzcan
inconsistencias en los datos, por eso hablamos de integridad en el sentido de "correccin", "validez" o
"precisin" de los datos de la base.
El subsistema de integridad de un Sistema Gestor de Base Datos (SGBD) debe, por tanto, detectar y
corregir, en la medida de lo posible, las operaciones incorrectas.
Hay que tener en cuenta, sin embargo, que habr operaciones cuya falta de correccin no sea
detectable, por ejemplo, si se introduce como fecha de nacimiento de un empleado el 17/02/31 cuando en
realidad era el 19/02/31, este error nunca podr ser detectado por el sistema ya que ambas fechas son
igualmente vlidas.
Existen dos tipos de operaciones que pueden atentar contra la integridad de los datos que son:
las operaciones semnticamente inconsistentes y
las interferencias debidas a accesos concurrentes
Integridad semntica
Existen operaciones que pueden violar restricciones definidas al disear la base de datos, como pueden
ser restricciones sobre los dominios (el estado civil como soltero, casado, divorciado o viudo), o sobre
los atributos (la fecha de nacimiento de los empleados debe ser posterior al 1 de enero de 1926). Estas
restricciones pueden ser estticas, como las apuntadas anteriormente, o dinmicas; por ejemplo, el
sueldo de un empleado no puede disminuir.
Los SGBD tienen que ofrecer facilidades que permitan describir las restricciones, con una sintaxis
adecuada y gran flexibilidad. Lo ms deseable es que esta definicin se haga de forma declarativa,
aunque una gran parte de los productos existentes exige emplear un enfoque procedimental (por medio
de disparadores y procedimientos almacenados).
Podemos clasificar las reglas de integridad en cuatro categoras:
Reglas de dominio
Reglas de atributo
Reglas de relacin
Reglas de base de datos
Se considera que una regla de integridad est constituida por lo menos por dos componentes:
La restriccin propiamente dicha, que establece la condicin que deben cumplir los datos
La respuesta a la violacin, que especifica las acciones a tomar: rechazar las operaciones,
informar al usuario, corregir el error con acciones complementarias, etc.
A veces se incluye tambin un tercer componente:
La condicin de disparo, que especifica cundo debe desencadenarse la accin: antes, despus
o durante cierto evento.
Se puede considerar, por tanto, las reglas de integridad como reglas ECA (Evento Condicin - Accin)
que "disparan" la accin al ocurrir un evento, siempre que se cumpla la condicin.
Un aspecto muy importante de las reglas de integridad, es que puedan almacenarse en el diccionario,
como parte integrante de la descripcin de los datos (control centralizado de la semntica), de modo
que ya no han de incluirse en los programas, con lo que se consiguen las siguientes ventajas:
Las reglas de integridad son ms sencillas de entender y de cambiar, facilitando su mantenimiento
Pg.: 79 de 98

Se detectan mejor las inconsistencias

Se protege mejor la integridad, ya que ningn usuario podr escribir un programa que las viole
llevando la base de datos a estados inconsistentes.
El subsistema de integridad del SGBD debe realizar, por tanto, las siguientes funciones:
Comprobar la coherencia de las reglas que se definen
Monitorear las distintas transacciones y detectar las violaciones de integridad
Cuando se produce una violacin, ejecutar las acciones pertinentes.
Integridad operacional
En sistemas multiusuario es imprescindible, adems, un mecanismo de control de concurrencia para
conservar la integridad de la base de datos ya que se pueden producir importantes inconsistencias
derivadas del acceso concurrente.
Los siguientes son algunos problemas clsicos de concurrencia:
Operacin perdida
Salidas inconsistentes
Introduccin de inconsistencias en la base de datos
Lectura no reproducible
Operacin perdida
T1
T2
Leer A a1
Leer A a2
a2 + 1 a2
Grabar a2 A
a1 + 1 a1
Grabar a1 A
Dentro de la transaccin T1 se lee el dato A almacenndose en la memoria en a1,

posteriormente se suma uno al valor ledo y se vuelve a escribir en la base de datos;
pero mientras tanto en una transaccin T2 tambin se ha ledo A, y actualizado su
valor. Sin embargo, esta ltima actualizacin no ha quedado reflejada (se ha
"perdido").
Pg.: 80 de 98

Salidas inconsistentes
T1
T2
Leer A a1
a1 + 1 a1
Grabar a1 A
Leer A a2
Imprimir a2
Leer B b2
Imprimir b2
Leer B b1
b1 + 1 b1
Grabar b1 B
Si se supone que A=B, la transaccin T1 (tomada de forma aislada) conserva esta

restriccin ya que suma 1 a ambos elementos. Sin embargo el resultado de T2 sera
inconsistente ya que imprimira dos valores diferentes, al haberse producido en
medio de las actualizaciones de T1.
Introduccin de inconsistencias en la base de datos
T1
T2
Leer A a1
a1 + 1 a1
Grabar a1 A
Leer A a2
a2 * 2 a2
Grabar a2 A
Leer B b2
b2 * 2 b2
Grabar b2 B
Leer B b1
b1 + 1 b1
Grabar b1 B
Es un caso anlogo al anterior, pero ms grave al destruir la consistencia de la base de datos.
Lectura no reproducible
T1
T2
Leer A a1
Imprimir a1
Leer A a2
a2 + 1 a2
Grabar a2 A
Leer A a1
Imprimir a1
Pg.: 81 de 98

En este caso una transaccin que quiere leer un dato dos veces se encuentra con que ese dato vara, sin
que en la transaccin se hubiera realizado ninguna actualizacin.
Para asegurar la consistencia de las transacciones se tiene que cumplir que sean seriables, en el sentido
de que el efecto de ejecutar transacciones de forma concurrente debe ser el mismo del que se producira
al ejecutarlas por separado en un orden secuencial segn van entrando al sistema. El concepto de
serialidad es fundamental para el control de concurrencia.
A continuacin presentaremos las tcnicas de control de concurrencia ms tradicionales (como las
basadas en bloqueos o las que utilizan "marcas de tiempo"); para, posteriormente, resumir las principales
tcnicas avanzadas (aquellas que surgen como consecuencia de aplicar la tecnologa de bases de datos
a nuevos campos de la ingeniera, medicina, gestin de redes, diseo, etc.
Tcnicas clsicas
Bloqueo
Se puede definir "bloqueo" o "lockeo" como "una variable asociada a cada elemento de datos, que
describe el estado de dicho elemento respecto a las posibles operaciones (recuperacin o actualizacin)
que se pueden realizar sobre ellos en cada momento".
Las transacciones pueden llevar a cabo bloqueos, por ejemplo, sobre los registros que vayan a utilizar,
impidiendo a otros usuarios la recuperacin o actualizacin de los elementos bloqueados, pudindose as
evitar inconsistencias en el acceso concurrente.
Aunque el propio SGBD gestiona ciertos bloqueos a fin de asegurar la consistencia, tambin los usuarios
pueden bloquear, de forma explcita, los objetos deseados, a fin de impedir la actualizacin o acceso por
parte de otros usuarios.
Los bloqueos pueden ser de varios tipos:
Bloqueos exclusivos (o de escritura): Cuando una transaccin mantiene un bloqueo de este tipo
sobre un objeto, ninguna otra transaccin puede acceder a l, ni adquirir ningn tipo de bloqueo
sobre ese objeto, hasta que sea liberado por la transaccin que lo haba retenido. Este tipo de
bloqueos se utiliza cuando una transaccin quiere actualizar algn objeto.
Bloqueos compartidos (o de lectura): Cuando una transaccin tiene sobre un objeto un bloqueo
de tipo compartido, permite que otras transacciones retengan tambin ese mismo objeto en
bloqueos compartidos, pero no exclusivos. Este tipo de bloqueo se utiliza cuando las transacciones
no necesitan actualizar datos, pero quieren impedir cualquier modificacin de stos mientras son
consultados.
El problema con las tcnicas de bloqueo es que puede producirse un "interbloqueo" (llamado deadlock"),
que es una situacin que se da cuando dos o ms transacciones estn esperando cada una de ellas que
otra libere algn objeto antes de seguir.
Este problema, que ha sido estudiado con detenimiento en los sistemas operativos, puede tener dos
soluciones:
Prevenir el interbloqueo, obligando a que las transacciones bloqueen todos los elementos
que necesitan por adelantado. En caso de no poder conseguir todos estos elementos, no
bloquea ninguno y se queda en espera hasta volverlo a intentar.
Detectar el interbloqueo, controlando de forma peridica si se ha producido. La solucin es ir
escogiendo transacciones como "vctimas" y deshacerlas, hasta que desaparezca el
interbloqueo. Cada SGBD tiene su propia "poltica" para escoger las vctimas, aunque suelen
ser las transacciones ms recientes.
El tema de los bloqueos es muy importante al afectar fuertemente al rendimiento del sistema.
Pg.: 82 de 98

Marcas de tiempo", (TimeStamping)

Las marcas de tiempo son identificadores nicos que se asignan a las transacciones y que pueden
considerarse como el tiempo de inicio de la transaccin.
Con esta tcnica no existen interbloqueos, y todas las actualizaciones fsicas se retrasan hasta la
grabacin de las transacciones, si una transaccin quiere acceder algn dato que ha sido actualizado por
una ms reciente, se deshace y se vuelve a empezar.
En definitiva, esta tcnica permite ordenar las transacciones y controlar un acceso en secuencia de las
mismas a los datos.
Tcnicas optimistas
Otra modalidad para el control de accesos concurrentes, la constituyen las denominadas "tcnicas
optimistas", que permiten que las transacciones accedan libremente a los objetos, determinando antes de
su finalizacin si ha habido o no interferencias.
Cada transaccin consta de dos o ms fases: una fase de lectura, una fase de validacin, y posiblemente
una fase de escritura. Durante la fase de lectura todas las escrituras tienen lugar en copias locales
(versiones transitorias) y durante la fase de validacin se establece si se viola la serialidad, y las copias
locales se hacen globales.
Pg.: 83 de 98

Anexo U8 - Estndares Modelo de datos lgico y fsico

Si bien depende del motor de base de datos a utilizar y debe ser compatible 100 % con ello. Esto es una
propuesta de mnima.
1. Generales:
La longitud de cualquier nombre de tablas, atributos, etc debe ser de un mximo de 15
caracteres alfanumricos , en minscula, sin caracteres especiales salvo el underline( _ )
2. Nombre de las bases de datos:
En plural y en minscula: Ej: clientes
3. Nombre de las tablas:
En plural, todo en minscula, con underline para separar nombres compuestos de tablas : Ej:
socios, pagos, det_boletas(detalles boletas)
Para tablas con nombres compuestos, se defini lo siguiente:
Primera parte 3 dgitos, ltima parte hasta 12 dgitos
4. Nombre de los campos:
En singular, todo en minscula, con underline para campos con nombres compuestos: Ej.:
saldo, sal_cliente, cod_cliente
Para campos con nombres compuestos, se defini lo siguiente:
Primeras partes 3 dgitos, ltima parte hasta 12 dgitos
Casos detectados:
cod (cdigo)
Ej: cod_cliente
dsc (descripcin)
Ej: dsc_falta
nro (nmero)
Ej:nro_factura
tpo (tipo)
Ej:tpo_doc o tpo_doc_persona
nom (nombre)
ape (apellido)
usr (usuario)
fec (fecha)
hor(hora)
tel (telfono)
Ej: tel_persona
dir (direccin)
Ej: dir_alumno
pci(provincia)
5. ndices de las tablas:
Comienza con idx, en singular y cada parte que se referencia de un atributo separada por
underline. Ej.: idxape_nom(campos ape_persona y nom_persona).
Anexo U8 Estndares Modelo de datos
Pg.: 84 de 98

Anexo U9 Estndares Modelo Fsico Externo o del Usuario

Pantallas/Formularios
Generalidades:
Todas las pantallas tendrn un botn Ayuda, con el cual se podr visualizar la descripcin del
funcionamiento de la misma.
Nombre de la pantalla. Debe ser representativo, til para el usuario y debe ubicarse en la barra de
ttulo de la pantalla.
Sobre los campos de las pantallas, se deber usar el ToolTipText para dar una gua rpida, cuando
considere necesario alguna aclaracin.
Manejo de las pantallas. Dadas las siguientes dos opciones para el manejo de las ventanas:
MDI (Multiple Document Interface).
Si se usa esta modalidad, todas las ventanas que se abran deben estar dentro de los
lmites de la segunda pantalla, permitiendo la visualizacin de su barra de men.
Una nica ventana activa. Se podr trabajar de dos formas diferentes:
Modal, donde no se puede ir a la pantalla anterior sin salir de la actual por medio de los
botones de comandos establecidos (Ej. no se puede volver con un clic que active la otra
pantalla).
No modal, donde para volver a la pantalla anterior solo hace falta un clic para activarla.
Entonces, proponemos el uso de una nica ventana activa, forma modal.

El alumno podr decidir el uso de los botones rpidos de minimizar, restaurar/maximizar y cerrar (esquina
superior derecha del formulario).
Botones
Nombres de los botones
En infinitivo los siguientes: Mostrar, Aceptar, Guardar, Cancelar, Imprimir, Salir, Buscar, Agregar,
Modificar y Eliminar.
Los de posicin: Siguiente, Anterior, Primero y Ultimo.
La ayuda: Ayuda.
Grupos, posicin y funcin de los botones

Ver los definidos en las pantallas de ABMC , Consultas y Bsqueda.
Los botones se mantendrn deshabilitados mientras no se puedan efectuar las acciones que realizan.
Imgenes
Las imgenes podrn mostrarse en forma de vista rpida (preview) y con un doble clic ser visualizadas en
pantalla completa. Luego con doble clic volver a la vista anterior.
Anexo U9 Estndares Modelo Externo
Pg.: 85 de 98

Formulario de ingreso al sistema
Debe pedir el ingreso de un usuario y su contrasea.
Se utilizan los botones: Aceptar y Cancelar.
Formulario principal
En este se muestra una barra de men descolgable.
Los menes podrn tener hasta dos submenes, es decir tres niveles de opciones.
Los menes sern:
Procesos: son los procesos principales del sistema. Por ejemplo: Alta Docentes, Altas
Alumnos, Actas, etc.
Consultas: son las consultas de datos definidas para el sistema. Tendrn opcin de ser
impresas.
ABMC: altas, bajas, modificaciones y consultas de las tablas secundarias del sistema. Por
ejemplo: Tipos de documentos, Cdigos postales, etc.
Ayuda: debe incluir un ndice con la ayuda de todo el sistema
Salir: se sugiere poner confirmacin antes de salir del formulario
Pg.: 86 de 98

Formulario de ABMC (para tablas secundarias del sistema)
Los datos se mostrarn verticalmente desde la esquina superior izquierda.
Siempre se mostrar el formulario vaco (sin ningn registro recuperado) y con los botones Mostrar,
Agregar, Salir y Ayuda habilitados. El resto de botones debern encontrarse deshabilitados. (Ej.:
Modificar, Eliminar, Imprimir)
No se permitirn las altas de otros datos dentro de estos formularios de ABMC. Ej.: si est dando de
alta una calle cuya orientacin no existe, NO se deber agregarla en este momento, sino que se
deber salir, ir al alta de Orientaciones de calles y luego regresar a este ABM de Calles.
Los botones estarn agrupados y ubicados de la siguiente manera:
El botn Mostrar, a la misma altura del botn Guardar, pero a su izquierda.
Los botones Guardar y Cancelar, son los que confirman la actualizacin o no de los registros.
Posicionados en forma vertical, lado derecho y hacia arriba de la pantalla.
Los botones de Agregar, Modificar, Eliminar, Todos, Ayuda y Salir posicionados en la parte
inferior del formulario en forma horizontal.
El botn Todos, abrir un nuevo formulario que mostrar todos los registros de la tabla con
sus campos y tendr los siguientes botones: Imprimir, Ayuda y Salir.
El botn Salir, vuelve al formulario anterior, ejecutando el evento unload del formulario.
El botn Ayuda, debe mostrar ayuda sobre el uso del formulario donde se est posicionado .
Los botones Primero, Anterior, Siguiente, Ultimo en la parte inferior de la zona interna del
formulario, en forma horizontal.
Se mostrar la cantidad de registros recuperados en un label o caja de texto (inhabilitada) a la

derecha del botn Ultimo, en donde se indicar registro actual y cantidad total de registros
recuperados (Ej.: 0/0 al inicio , luego podr ser 1/30, etc.)
Ingreso
Datos
de
Navegacin
de Registros
ABM
Pg.: 87 de 98

Formulario de Consultas
Se colocan los campos que definen el criterio de bsqueda de la consulta.
Se utilizarn los botones:
Mostrar: para aplicar el criterio de bsqueda definido.
Cancelar: para limpiar la pantalla y permitir una nueva consulta.
Imprimir: imprime el resultado de la consulta.
Ayuda: muestra la ayuda sobre el uso del formulario donde se est posicionado.
Salir: vuelve al formulario anterior, ejecutando el evento unload del formulario.
Ingreso y filtro
Presentacin
de datos
Pg.: 88 de 98

Formulario de Bsqueda
Este formulario se utilizar en los procesos principales del sistema, permitiendo buscar los registros
que coincidan con el texto ingresado sobre el campo en donde est parado.
No se utilizar en eventos de ABMC de tablas secundarias.
Tendr los botones de Mostrar, Seleccionar (selecciona una fila para retornar los datos de la misma
al formulario que llam esta bsqueda), Ayuda y Salir.
Pg.: 89 de 98

Herramientas
Generalidades
Se realiza un diagrama para cada evento (uno o varios formularios).
En el mismo se deben reflejar:
los distintos estados del evento con rectngulos.
las principales transiciones entre los distintos estados con flechas.
Debe hacerse una breve descripcin de la condicin y accin por la cual se produce la transicin
(Ej.: Click Salir (condicin) - Sale del formulario actual (accin))
Ejemplo: Evento de Ingreso al sistema
Click CANCELAR
Salir Formulario
Click ACEPTAR y Datos invlidos
Mensaje
Click ACEPTAR y Datos vlidos

Llama Men Principal
INGRESO AL SISTEMA

Generalidades
Se realiza un diagrama por cada formulario.
Se deben reflejar, cuando producen efectos sobre otros controles del formulario, lo siguiente:
las acciones derivadas del load del formulario (Ej.: carga un combo con los registros de la
tabla calles).
las interacciones del usuario con el formulario (Ej.: click en cbocalles, muestra nombre de
calle y altura desde y hasta en los txt correspondientes).
Debe hacerse una breve descripcin de las acciones a seguir ante la ocurrencia de un evento en
la parte izquierda del diagrama.
Nombres y grficos
En las columnas, donde se describen los controles debern usarse los nombres definidos para
los controles (Ej.: cmdAceptar) .
Para diagramar procedimientos nativos del lenguaje se usan los crculos.
Para diagramar procedimientos desarrollados se usan los rectngulos.
La ltima columna se utiliza para reflejar las interacciones con otros formularios.
Pg.: 90 de 98

Ejemplo: Formulario de ingreso al Sistema

Acciones
ME
CmdAceptar
cmdCancelar
Otros
Formularios
Click
Blanquea Datos
Click
Si Datos Vlidos
Men
Principal
Si Datos Invlidos
Mensaje
Pg.: 91 de 98

Anexo U10 Estndares Modelo Fsico Interno o de

Programas
1. Herramientas
Diagrama de Composicin (DC)
4. Generalidades
Se realiza un diagrama por cada formulario.
Los controles label no se incluyen en este diagrama.
Los nombres del control deben ser los que tienen realmente en el formulario.(ver Ej. en Controles
Nombres)
Las propiedades no estndar del formulario o del control son aquellas que salen de los
estndares fijados para la organizacin o que no son por default.. Como por ejemplo: en un
proceso de ABMC, las cajas de texto que muestran los datos de los registros debern
permanecer bloqueadas hasta que se haga un click en el botn Modificar. Esta propiedad no est
definida por defecto como bloqueada.
2. Modelo
Descripcin del funcionamiento del formulario:

Control:<nombre del control 1>
................
.....
..................................
Control:<nombre del control n>
................
.....
Anexo U10 Estndares Modelo Interno
Pg.: 92 de 98

Controles
5. Nombres
Se definen los siguientes nombres a usar para los controles:
Tipo de control
Prefijo
Ejemplo
3D Panel
Pnl
PnlGroup
Animated button
Ani
aniMailBox
Check box
chk
chkReadOnly
Combo box, drop-down list box
cbo
cboEnglish
Command button
cmd
cmdExit
Common dialog
dlg
dlgFileOpen
Communications
com
comFax
Data control
dat
datBiblio
Data-bound combo box
dbcbo
dbcboLanguage
Data-bound grid
dbgrd
dbgrdQueryResult
Data-bound list box
dblst
dblstJobType
Directory list box
dir
dirSource
Drive list box
drv
drvTarget
File list box
fil
filSource
Form
frm
frmEntry
Frame
fra
fraLanguage
Gauge
gau
gauStatus
Graph
gra
graRevenue
Grid
grd
grdPrices
Horizontal scroll bar
hsb
hsbVolume
Image
img
imgIcon
Key status
key
keyCaps
Label
lbl
lblHelpMessage
Line
lin
linVertical
List box
lst
lstPolicyCodes
MAPI message
mpm
mpmSentMessage
MAPI session
mps
mpsSession
MCI
mci
mciVideo
MDI child form
mdi
mdiNote
Menu
mnu
mnuFileOpen
MS Flex grid
msg
msgClients
MS Tab
mst
mstFirst
OLE
ole
oleWorksheet
Outline
out
outOrgChart
Pen Bedit
bed
bedFirstName
Pen Hedit
hed
hedSignature
Pen ink
ink
inkMap
Picture
pic
picVGA
Picture clip
clp
clpToolbar
Report
rpt
rptQtr1Earnings
Pg.: 93 de 98

Shape
Spin
Text box
Timer
UpDown
Vertical scroll bar
Slider
ImageList
TreeView
Toolbar
TabStrip
StatusBar
ListView
ProgressBar
RichTextBox
shp
spn
txt
tmr
upd
vsb
sld
ils
tre
tlb
tab
sta
lvw
prg
rtf
shpCircle
spnPages
txtLastName
tmrAlarm
updDirection
vsbRate
sldScale
ilsAllIcons
treOrganization
tlbActions
tabOptions
staDateTime
lvwHeadings
prgLoadFile
rtfReport
Se definen los siguientes nombres a usar para los controles DAO:

Objeto
Prefijo
Ejemplo
Container
con
conReports
Database
db
dbAccounts
DBEngine
dbe
dbeJet
Document
doc
docSalesReport
Field
fld
fldAddress
Group
grp
grpFinance
Index
idx
idxAge
Parameter
prm
prmJobCode
QueryDef
qry
qrySalesByRegion
Recordset
rec
recForecast
Relation
rel
relEmployeeDept
TableDef
tbd
tbdCustomers
User
usr
usrNew
Workspace
wsp
wspMine
Variables
6. Nombres
No se describir el tipo de dato que contiene la variable
La cantidad de caracteres para los nombres es 15 (igual que los definidos para los campos de las
tablas)
Segn el alcance de la variable:
Global a todo el proyecto, por Ej. gcantidad, gcan_hojas
Global dentro del mdulo o formulario, por Ej. mcantidad, mcan_hojas
Cuando se definen dentro de un procedimiento no llevarn ninguna letra que las caracterice
Pg.: 94 de 98
Anexo U11 Depuracin de errores (debugging)

Introduccin
Este proceso se inicia cuando la etapa prueba ha sido efectiva, es decir que se encontraron errores
(los datos obtenidos en la prueba no coinciden con los datos esperados).
Los datos errneos son un sntoma del error, pero la causa del mismo puede no ser evidente. El
encontrar la causa del error y corregirlo son los objetivos del proceso de depuracin.
Este proceso consta de 2 actividades principales: buscar la causa del error y corregirlo. La primera
de ellas representa hasta el 95% del problema.
Caractersticas de los errores:
El sntoma del error y la causa pueden estar geogrficamente distantes; esto se da en

estructuras fuertemente acopladas
El sntoma puede desaparecer temporalmente al corregir otro error
El sntoma puede ser producido por algo que no es un error, por ejemplo los redondeos
El sntoma puede aparecer en forma intermitente
No descartar errores humanos
Principios de la bsqueda de errores

Pensar
El proceso de debugging consiste en la resolucin de un problema. Como se ver en las tcnicas
de debugging, se debe ser capaz de ubicar la mayora de los errores sin necesidad de acudir a la
computadora.
Si se arriba a un impasse, descanse
Si no se puede resolver el problema en un tiempo razonable, conviene abandonarlo y trabajar en
otra cosa. Lo ms frecuente es que despus del descanso el error aparece rpidamente.
Describir el problema a otra persona
Con frecuencia el poder relatar el problema a un buen interlocutor hace posible que se encuentre la
solucin sbitamente.
Usar herramientas de debugging solo en segundo trmino
En este caso usarlas como herramientas auxiliares y no como sustituto del razonamiento.
Tcnicas de depuracin
Fuerza Bruta
Es el peor de los enfoques, el enfoque no racional, y por lo tanto solo debe aplicarse cuando todos
los dems mtodos fallan. Consiste en dejar que la computadora encuentre el error.
Existen varias categoras:
Volcados de memoria: Consiste en analizar un vuelco de memoria (generalmente en forma

hexadecimal). Tiene como problemas el brindar una visin esttica del programa, no se
puede saber si en el vuelco se encuentra el error.
Consiste en esparcir sentencias dentro del programa para producir mensajes o mostrar el
valor de ciertas variables. Es algo mejor que el anterior pues brinda una visin dinmica del
programa. Defectos:
a. Puede producir una enorme cantidad de datos a ser analizados.
b. Requiere la introduccin de cambios en el programa, los cuales enmascaran el
error o incluso producen nuevos errores.
Uso de herramientas de depuracin provistas generalmente por el lenguaje. Se basan

fundamentalmente en la introduccin de puntos de ruptura (BREAK POINTS) que hacen
que se suspenda la ejecucin del programa cuando la ejecucin del programa pasa por
una determinada sentencia.
Vuelta atrs
Puede ser utilizado con xito en pequeos programas. Se parte del lugar donde se descubre el
sntoma, se recorre hacia atrs el cdigo fuente hasta que se llega a la posicin del error. Si
tenemos un programa o mdulo muy extenso, tenemos muchos caminos de vuelta, lo que lo hace
inmanejable.
Mtodo inductivo
Los datos relacionados con la ocurrencia del error son organizados para aislar las posibles causas.
Se llega a una hiptesis de causa y se usan los datos anteriores para probar o revocar la hiptesis.
En forma alternativa se puede crear una lista de las posibles causas y llevar a cabo pruebas para
eliminar cada una de ellas.
El proceso consta de los siguientes pasos:
1) Ubicacin de los datos pertinentes
Consiste bsicamente en enumerar todo lo que se sabe que el programa hace
correctamente y todo lo que se sabe que hace mal, o sea, los sntomas que llevan a pensar
en la existencia de un error.
2) Organizacin de los datos
Se tratan de encontrar contradicciones o situaciones particulares.
A tal fin es posible utilizar la tabla que sigue:
ES
QUE
DONDE
NO ES
La mediana en el informe 3 es
incorrecta
El clculo del valor medio y el

desvo estndar
Solo el informe 3
Los dems valores calculados

en los otros informes son
correctos
No ocurre con 2 y 200
alumnos
CUANDO
Se presenta en la prueba con 51

alumnos
CON QUE
ALCANCE
La mediana result = 26.

Lo mismo ocurri en la prueba con 1
alumno y result ser = 1
En la casilla QUE se hace una lista de los sntomas generales.
Las marcadas DONDE reciben la informacin del lugar donde se han observado esos
sntomas.
Las casillas CUANDO contendrn todo lo que se puede conocer respecto del
momento en que los sntomas aparecen .
Las casillas CON QUE ALCANCE reciben informacin acerca del alcance y la
magnitud de los sntomas.
En las columnas ES y NO ES se anotan las contradicciones que podran

eventualmente permitir la confeccin de una hiptesis acerca del error.
3) Formulacin de una hiptesis

Consiste en estudiar las relaciones entre los sntomas y formular una o ms hiptesis sobre
la causa del error. Si no es posible establecer ninguna hiptesis se requieren ms datos,
los que se pueden obtener a travs de casos adicionales de prueba.
4) Prueba de la hiptesis
Hay que demostrar la razonabilidad de la hiptesis antes que abocarse a la correccin del
error. La omisin de esta etapa lleva a menudo a corregir solo una parte del error o la
eliminacin del sntoma.
Hay que estar seguro que la hiptesis explica completamente la existencia del error. De no
ser as, tenemos una hiptesis incompleta o bien estamos frente a errores mltiples.
Mtodo por deduccin

Consiste en partir de ciertas premisas o teoras generales utilizando los procesos de eliminacin y
clasificacin para llegar a una conclusin (la ubicacin del error).
Incluye los siguientes pasos:
1. Enumerar las causas e hiptesis posibles
Se desarrolla y lista de todas las posibles causas de error. Estas pueden ser simples
teoras mediante las cuales se pueden estructurar y analizar los datos disponibles.
2. Usar los datos para eliminar causas posibles
Mediante el anlisis de los datos, buscando contradicciones, se intenta eliminar todas las
posibles causas menos una.
3. Clarificar las hiptesis remanentes
La causa posible en este punto podra ser correcta, pero difcilmente es tan especfica
como para mostrar exactamente el error.
Se utilizan las pistas disponibles para transformar la teora (por ejemplo error en el ltimo
registro del archivo) en algo ms especfico (ltimo registro del archivo superpuesto con
indicador de final de archivo).
4. Prueba de la hiptesis (idntico al punto 4 del mtodo Inductivo)
Bibliografa
Ingeniera del Software, un enfoque prctico, (3ra edicin) Roger S. Pressman, McGraw Hill.

Apuntes Diseno Sistemas

Cargado por

Información del documento

Título 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

Apuntes Diseno Sistemas

Cargado por

Copyright:

Formatos disponibles

Academia de Computacin

Centro de Estudios Tecnolgicos Industrial y de Servicios

Ing. Edgar Paredes Basilio

Apuntes de Diseo de Sistemas

Etapas en el desarrollo de sistemas de informacin

Herramientas informticas utilizadas en cada etapa

2. Objetivos del CASE

4. Clasificacin de las herramientas CASE

Problemas en el desarrollo de software

UNIDAD 2 Calidad del Software

Uso de Estndares y su importancia

Garanta de Calidad del Software (SQA)

10. Actividades de SQA

Aplicacin de mtodos y tcnicas

Realizacin de Revisiones Tcnicas Formales (RTF)

Prueba del software

Ultima actualizacin: 03/2002

Apuntes de Diseo de Sistemas

Registro y realizacin de informes

11. Revisiones Tcnicas Formales

12. Ventajas y desventajas de la SQA

UNIDAD 3 Diseo de Sistemas

15. Modelo de Implementacin

16. Fundamentos del Diseo

17. Requerimientos No Funcionales

Requerimientos de adaptacin a diferentes instalaciones

UNIDAD 4 Modelo de Tecnologa

19. Componentes del modelo

Tecnologa en produccin (necesaria para implementar el sistema)

Tecnologa para desarrollo (necesaria para desarrollar el sistema)

Ultima actualizacin: 03/2002

Apuntes de Diseo de Sistemas

UNIDAD 5 Modelo Fsico de Datos

22. Pautas generales:

Codificar lo mximo posible

Numeraciones / codificaciones internas

Campos para parametrizacin

Funciones provistas por los motores de bases de datos

UNIDAD 6 Modelo Fsico Externo o del Usuario

Niveles de conocimiento del Usuario

Roles de los usuarios

24. Diseando en Windows

25. Orientacin a Eventos

Cmo funciona una aplicacin controlada por eventos?

1. Objetivos medibles en un diseo de interfaces

2. Reglas tiles para el diseo de interfaces

Bosquejo de pantallas y descripcin de procesos

Diagrama de Transicin de Estados (DTE)

Diagrama de Interaccin (DI)

26. Diseo de la ayuda

UNIDAD 7 Modelo Fsico Interno o de Programas

28. Pautas Generales

Ultima actualizacin: 03/2002

Apuntes de Diseo de Sistemas

Acoplamiento de estructura de datos

31. Herramienta: Diagrama de Composicin

UNIDAD 6 Prueba del Software

33. Conceptos bsicos

Encargado de realizar la prueba

34. Estrategia de prueba

Prueba del Sistema

35. Casos de prueba

Diseo de casos de prueba