ENERO-JUNIO 2014 1

Instituto Tecnolgico de
Pachuca
Alumno:
Clara Tolentino Monter 10200984
Erick Snchez Snchez 10200986
David Gonzlez Cuatle 10200958
Gabriel Luna Ortega 10200966

Catedrtico:
Lic. Jos Fructuoso Gutirrez Daz

Materia:
Calidad de Software

Manual de validacin de calidad.

ENERO-JUNIO 2014

























Calidad de Software

ENERO-JUNIO 2014 2


Tabla de contenido
Introduccin .................................................................................................................................. 5
Apartado Interfaz de Salida ........................................................................................................... 5
Lineamientos generales ............................................................................................................ 5
Estableciendo las Medidas ........................................................................................................ 6
Interfaz de Salida ....................................................................................................................... 7
Formato de RTF ......................................................................................................................... 8
Apartado Interfaz de Entrada ...................................................................................................... 11
Lineamientos Generales .......................................................................................................... 11
Estableciendo las Medidas ...................................................................................................... 11
Interfaz de Entrada .................................................................................................................. 12
Formato de la RTF ................................................................................................................... 13
Apartado Diseo Base de Datos .................................................................................................. 18
Lineamientos Generales .......................................................................................................... 18
Objetivos de los lineamientos de las bases de datos. ......................................................... 18
Lineamientos para el diseo de relaciones de bases de datos: .......................................... 18
Caractersticas adicionales considerar en la etapa del diseo. .......................................... 19
Diseo fsico ................................................................................................................................ 19
Mtricas: ............................................................................................................................. 20
Informe de Revisin Tcnica Formal (RTF) ..................................... Error! Marcador no definido.
Plan de Verificacin y Validacin de un diccionario de datos de una base de datos. ......... Error!
Marcador no definido.
Versin 2.0 ..................................................................................... Error! Marcador no definido.
Historia de revisiones ..................................................................... Error! Marcador no definido.
Contenido ....................................................................................... Error! Marcador no definido.
1 Producto revisado .................................................................. Error! Marcador no definido.
1.1 Nombre y Versin del Producto revisado ...................... Error! Marcador no definido.
1.2 Participantes de la revisin ............................................ Error! Marcador no definido.
1.3 Tcnica utilizada ............................................................. Error! Marcador no definido.
2 Objetivos de la RTF ................................................................. Error! Marcador no definido.
Calidad de Software

ENERO-JUNIO 2014 3
3 Problemas detectados ............................................................ Error! Marcador no definido.
(Descripcin) .............................................................................. Error! Marcador no definido.
3.1.1 Sugerencia de correccin .............................................. Error! Marcador no definido.
4 Evaluacin .............................................................................. Error! Marcador no definido.
4.1 Estado actual del Producto ............................................ Error! Marcador no definido.
4.2 Acciones a tomar ............................................................ Error! Marcador no definido.
4.3 Prxima Revisin del Producto ...................................... Error! Marcador no definido.
Diseo lgico ............................................................................................................................... 30
Informe de Revisin Tcnica Formal (RTF) ..................................... Error! Marcador no definido.
Plan de Verificacin y Validacin del diseo lgico de una base de datos .... Error! Marcador no
definido.
Versin 2.0 ..................................................................................... Error! Marcador no definido.
Historia de revisiones ..................................................................... Error! Marcador no definido.
Contenido ....................................................................................... Error! Marcador no definido.
1 Producto revisado .................................................................. Error! Marcador no definido.
1.1 Nombre y Versin del Producto revisado ...................... Error! Marcador no definido.
1.2 Participantes de la revisin ............................................ Error! Marcador no definido.
1.3 Tcnica utilizada ............................................................. Error! Marcador no definido.
2 Objetivos de la RTF ................................................................. Error! Marcador no definido.
3 Problemas detectados ............................................................ Error! Marcador no definido.
(Descripcin) .............................................................................. Error! Marcador no definido.
3.1.1 Sugerencia de correccin .............................................. Error! Marcador no definido.
4 Evaluacin .............................................................................. Error! Marcador no definido.
4.1 Estado actual del Producto ............................................ Error! Marcador no definido.
4.2 Acciones a tomar ............................................................ Error! Marcador no definido.
4.3 Prxima Revisin del Producto ...................................... Error! Marcador no definido.
Diccionario de datos. ................................................................................................................... 35
Medidas: .................................................................................................................................. 35
Informe de Revisin Tcnica Formal (RTF) ..................................... Error! Marcador no definido.
Plan de Verificacin y Validacin de un diccionario de datos de una base de datos. ......... Error!
Marcador no definido.
Versin 2.0 ..................................................................................... Error! Marcador no definido.
Historia de revisiones ..................................................................... Error! Marcador no definido.
Contenido ....................................................................................... Error! Marcador no definido.
1 Producto revisado .................................................................. Error! Marcador no definido.
Calidad de Software

ENERO-JUNIO 2014 4
1.1 Nombre y Versin del Producto revisado ...................... Error! Marcador no definido.
1.2 Participantes de la revisin ............................................ Error! Marcador no definido.
1.3 Tcnica utilizada ............................................................. Error! Marcador no definido.
2 Objetivos de la RTF ................................................................. Error! Marcador no definido.
3 Problemas detectados ............................................................ Error! Marcador no definido.
(Descripcin) .............................................................................. Error! Marcador no definido.
3.1.1 Sugerencia de correccin .............................................. Error! Marcador no definido.
4 Evaluacin .............................................................................. Error! Marcador no definido.
4.1 Estado actual del Producto ............................................ Error! Marcador no definido.
4.2 Acciones a tomar ............................................................ Error! Marcador no definido.
4.3 Prxima Revisin del Producto ...................................... Error! Marcador no definido.
Apartado Diseo de Procesos ..................................................................................................... 39
Lineamientos Generales .......................................................................................................... 39
Establecimiento de las medidas .............................................................................................. 39
Medidas directas e Indirectas del Diseo de Procesos ....................................................... 40
Por Diagrama de Flujo ......................................................................................................... 41
Medidas ............................................................................................................................... 41
Mtricas ............................................................................................................................... 41
Formato de RTF ........................................................................................................................... 43












Calidad de Software

ENERO-JUNIO 2014 5


Introduccin

En este documento se examinaran los lineamientos generales, medidas, mtricas y el formato
de la revisin tcnica formal en las interfaces de entrada con el objeto de llevar a cabo los
lineamientos de calidad de software para nuestra empresa; ya que sin ellas no existira la
calidad y por tanto fracasara nuestro producto.
El desarrollar cada uno de los puntos nos dar un panorama de qu tanta calidad existe en el
producto y cules son las caractersticas a mejorar de dicho producto.
Pues el objetivo de una interfaz es utilizar un conjunto de imgenes y objetos grficos para
representar la informacin y acciones disponibles en un sistema. Su principal uso, consiste en
proporcionar un entorno visual sencillo para permitir la comunicacin con el sistema operativo
de una mquina con el humano.

Apartado Interfaz de Salida
Lineamientos generales

Facilidad de comprensin, aprendizaje y uso
Representacin fija y permanente de un determinado contexto de accin (fondo)
El objeto de inters ha de ser de fcil identificacin
Diseo ergonmico mediante el establecimiento de mens, barras de acciones e
iconos de fcil acceso
Las interacciones se basarn en acciones fsicas sobre elementos de cdigo visual o
auditivo (iconos, botones, imgenes, mensajes de texto o sonoros, barras de
desplazamiento y navegacin...) y en selecciones de tipo men con sintaxis y rdenes
Las operaciones sern rpidas, incrementales y reversibles, con efectos inmediatos
Existencia de herramientas de Ayuda y Consulta para el usuario
Tratamiento del error bien cuidado y adecuado al nivel de usuario
Mnima diferencia entre el objeto real y el objeto representado.
Presentar en la misma posicin en todas las pantallas.
Fcilmente discriminables del resto de iconos.
Evitar que tengan varias interpretaciones los mismos iconos


Calidad de Software

ENERO-JUNIO 2014 6


Estableciendo las Medidas

Permitir a los usuarios utilizar teclado o ratn
Permitir al usuario interrumpir su tarea y continuarla ms tarde
Utilizar mensajes y textos descriptivos
Permitir deshacer las acciones, e informar de su resultados
Permitir una cmoda navegacin dentro del producto y una fcil salida del mismo
Permitir distintos niveles de uso del producto para usuarios con distintos niveles de
experiencia.
Hacer transparente la interfaz del usuario (este debe creer que trabaja directamente
con los objetos)
Aliviar carga memoria corto plazo (deshacer, copiar y pegar, mantener los ltimos
datos introducidos)
Reconocimiento antes que recuerdo (elegir de listas mejor que teclear)
Dar indicaciones visuales de donde est el usuario, que est haciendo y que puede
hacer a continuacin
1. Dar el control al usuario: debe ser intuitiva
Definir los modos de interaccin: Flexibles y adecuados
Dar opciones de rehacer/deshacer
Dar opciones de interrumpir una accin, volver a ejecutar una accin
Pasos repetidos: macros
2. Reducir la carga de memoria:
Metforas del mundo real
Colocar valores por defecto
3. Mantener una interfaz consistente
Fuente, colores, distribucin de los controles: deben ser iguales

De Jure: Constituidos por un organismo internacional.
ISO 9241: Criterios ergonmicos para VDT (terminales de despliegue visual).
De Facto: Corporaciones o empresas
CUA: Common User Access
(IBM-86): Componentes Visuales

Calidad de Software

ENERO-JUNIO 2014 7


Interfaz de Salida

Medidas asociadas Mtricas asociadas
Mens de tipo ndice Mximo 2
Fondo Evitar la combinacin de rojo-verde,
amarillo-azul, verde-azul, rojo-azul
Contraste entre Letras y fondos Altos contrastes por ejemplo fondo blanco
con letras negras
Nmero de colores 4 para novatos y 7 para expertos
reas de fondo Azul claro
Informacin perifrica Blanco
Cdigos redundantes Iconos no repetitivos
Nmero de botones De 8 a 10
Tipo de letras Bitmap, escalables
Resolucin VGA * 640480 en 16 colores
* 640350 en 16 colores
* 320200 en 16 colores
* 320200 en 256 colores
Formularios Dependiendo de la necesidad del usuario
Cuantas fuentes se pueden utilizar No ms de 3 fuentes
Tamao de letra No usar ms de tres tamaos de la misma
fuente, una fuente menor a 8 es difcil de
leer
Fuentes preferentes Preferentemente usar fuentes sans serif
nfasis en el texto No utilizar nfasis en el texto (subrayado,
itlico, sombreado) salvo en casos
especiales
Alineacin de texto Etiquetas a la izquierda, nmeros a la
derecha








Calidad de Software

ENERO-JUNIO 2014 8

Formato de RTF
Formato I

Formato RTF

Lder del proyecto Jefe de revisin Versin de Proyecto

Plataforma Fecha de Lanzamiento Fecha de Revisin

Nombre de la empresa Software a revisar Revisor No. y firma
Hora de Inicio Hora de salida

Preguntas Cumple No cumple
Ingeniera de la Interfaz


Se han definido las funciones principales de forma delimitada y
sin ambigedad?
Se han definido las interfaces entre los elementos de la
interfaz?
Se han establecido lmites de presentaciones para el sistema
como un todo y para cada elemento?
Se han establecido restricciones de diseo para cada
elemento?
Se ha elegido la mejor alternativa?
Es factible la solucin tcnica?
Se ha establecido un mecanismo de verificacin y validacin?
Existe consistencia entre todos los elementos de la interfaz?


Anlisis de requisitos
Funcin y rendimiento de los elementos.
Se han definido las funciones principales de forma delimitada y
sin ambigedad?
Se han definido las interfaces entre los elementos de la
interfaz?
Se han establecido lmites de presentaciones para el sistema
como un todo y para cada elemento?
Se han establecido restricciones de diseo para cada
elemento?
Se ha elegido la mejor alternativa?
Es factible la solucin tcnica?
Se ha establecido un mecanismo de verificacin y validacin?
Existe consistencia entre todos los elementos de la interfaz?


Diseo preliminar
Calidad de Software

ENERO-JUNIO 2014 9



Arquitectura del software
Estn reflejados los requisitos en la
arquitectura?
La modularidad es efectiva?
Depende de algunos factores la
arquitectura del programa?
Se han definido las interfaces para los
mdulos y los elementos externos del
sistema?
Es consistente la estructura de datos con
el mbito de informacin?
Es consistente la estructura de datos con
los requisitos del software?
Se ha considerado la facilidad de
mantenimiento?
Se han evaluado explcitamente los
factores de calidad?




Tcnica Utilizada Fecha de Prxima Revisin

Versin Plataformas


Problemas a grandes rasgos Material


Aprobacin de
revisores


Formato II y continuacin
Listas de Comprobacin para la revisin (check list).
Ingeniera de la Interfaz
Funcin y rendimiento de los elementos.
Se han definido las funciones principales de forma delimitada y sin ambigedad?
Se han definido las interfaces entre los elementos de la interfaz?
Se han establecido lmites de presentaciones para el sistema como un todo y para
cada elemento?
Se han establecido restricciones de diseo para cada elemento?
Calidad de Software

ENERO-JUNIO 2014 10
Se ha elegido la mejor alternativa?
Es factible la solucin tcnica?
Se ha establecido un mecanismo de verificacin y validacin?
Existe consistencia entre todos los elementos de la interfaz?
Anlisis de Requisitos
Es completo, consistente y exacto el anlisis del campo de informacin?
Es completa la particin del problema?
Estn definidas adecuadamente las interfaces internas y externas?
Refleja el modelo de datos correctamente los datos, sus atributos y sus relaciones?
Se pueden seguir todos los requisitos a nivel del sistema?
Se ha realizado un prototipo para el usuario?
Son alcanzables las prestaciones con las restricciones impuestas por otros elementos
de la interfaz?
Son consistentes los requisitos con la planificacin, los recursos y el presupuesto?
Son completos los criterios de validacin?
Diseo preliminar
Arquitectura del software
Estn reflejados los requisitos en la arquitectura?
La modularidad es efectiva?
Depende de algunos factores la arquitectura del programa?
Se han definido las interfaces para los mdulos y los elementos externos del sistema?
Es consistente la estructura de datos con el mbito de informacin?
Es consistente la estructura de datos con los requisitos del software?
Se ha considerado la facilidad de mantenimiento?
Se han evaluado explcitamente los factores de calidad?

Plan de Prueba
Se han identificado y secuenciado adecuadamente las principales fases de
prueba?
Se ha establecido un seguimiento de los criterios/requisitos de validacin como
parte del anlisis de requisitos del software?
Se han comprobado pronto las funciones importantes?
Es consistente el plan de prueba con el plan global del proyecto?
Se ha definido explcitamente un plan de tiempos para la prueba?
Se han identificado y estn disponibles los recursos y las herramientas para la
prueba?
Se ha establecido un mecanismo para registrar los resultados de la prueba?
Se han identificado los conductores y los resguardos y se ha planificado el trabajo
para desarrollarlos?
Calidad de Software

ENERO-JUNIO 2014 11
Se ha especificado la prueba de resistencia para el software?
Mantenimiento
La facilidad de mantenimiento debe ser una caracterstica esencial en cualquier software y
factores para la facilidad de mantenimiento deben ser incluidas durante las fases del
desarrollo, adems de esto se considera lo siguiente:
Se han considerado los efectos laterales asociados al cambio?
Se ha documentado, evaluado y aprobado la peticin de cambio?
Se ha documentado el cambio, una vez hecho e informado a las partes
interesadas?
Se han hecho RTFs adecuadas?
Se ha hecho una revisin de aceptacin final para garantizar que todo el software
ha sido actualizado, probado y reemplazado adecuadamente?


Apartado Interfaz de Entrada

Lineamientos Generales

Facilidad de comprensin, aprendizaje y uso
Representacin fija y permanente de un determinado contexto de accin (fondo)
El objeto de inters ha de ser de fcil identificacin
Diseo ergonmico mediante el establecimiento de mens, barras de acciones e
iconos de fcil acceso
Las interacciones se basarn en acciones fsicas sobre elementos de cdigo visual o
auditivo (iconos, botones, imgenes, mensajes de texto o sonoros, barras de
desplazamiento y navegacin...) y en selecciones de tipo men con sintaxis y rdenes
Las operaciones sern rpidas, incrementales y reversibles, con efectos inmediatos
Existencia de herramientas de Ayuda y Consulta para el usuario
Tratamiento del error bien cuidado y adecuado al nivel de usuario
Mnima diferencia entre el objeto real y el objeto representado.
Presentar en la misma posicin en todas las pantallas.
Fcilmente discriminables del resto de iconos.
Evitar que tengan varias interpretaciones los mismos iconos

Estableciendo las Medidas

Calidad de Software

ENERO-JUNIO 2014 12
Permitir a los usuarios utilizar teclado, ratn y touch screen
Permitir al usuario interrumpir su tarea y continuarla ms tarde
Utilizar mensajes y textos descriptivos
Permitir deshacer las acciones, e informar de su resultados
Permitir una cmoda navegacin dentro del producto y una fcil salida del mismo
Permitir distintos niveles de uso del producto para usuarios con distintos niveles de
experiencia
Hacer transparente la interfaz del usuario (este debe creer que trabaja directamente
con los objetos)
Aliviar carga memoria corto plazo (deshacer, copiar y pegar, mantener los ltimos
datos introducidos)
Reconocimiento antes que recuerdo (elegir de listas mejor que teclear)
Dar indicaciones visuales de donde est el usuario, que est haciendo y que puede
hacer a continuacin

1. Dar el control al usuario: debe ser intuitiva
Definir los modos de interaccin: Flexibles y adecuados
Dar opciones de rehacer/deshacer
Dar opciones de interrumpir una accin, volver a ejecutar una accin
Pasos repetidos: macros
2. Reducir la carga de memoria:
Metforas del mundo real
Colocar valores por defecto
3. Mantener una interfaz consistente
Fuente, colores, distribucin de los controles: deben ser iguales

Estndares:
De Jure: Constituidos por un organismo internacional.
ISO 9241: Criterios ergonmicos para VDT (terminales de despliegue visual).
De Facto: Corporaciones o empresas
CUA: Common User Access
(IBM-86): Componentes Visuales

Interfaz de Entrada

Medidas asociadas Mtricas asociadas
Mens de tipo ndice Mximo 2
Calidad de Software

ENERO-JUNIO 2014 13
Fondo Evitar la combinacin de rojo-verde,
amarillo-azul, verde-azul, rojo-azul
Contraste entre Letras y fondos Altos contrastes por ejemplo fondo blanco
con letras negras
Nmero de colores 4 para novatos y 7 para expertos
reas de fondo Azul claro
Informacin perifrica Blanco
Cdigos redundantes Iconos no repetitivos
Nmero de botones De 8 a 10
Tipo de letras Bitmap, escalables
Resolucin VGA * 640480 en 16 colores
* 640350 en 16 colores
* 320200 en 16 colores
* 320200 en 256 colores
Formularios Dependiendo de la necesidad del usuario
Cuantas fuentes se pueden utilizar No ms de 3 fuentes
Tamao de letra No usar ms de tres tamaos de la misma
fuente, una fuente menor a 8 es difcil de
leer
Fuentes preferentes Preferentemente usar fuentes sans serif
nfasis en el texto No utilizar nfasis en el texto (subrayado,
itlico, sombreado) salvo en casos
especiales
Alineacin de texto Etiquetas a la izquierda, nmeros a la
derecha

Entradas tctiles para equipos touch Onda Acstica Superficial, resistiva,
capacitivas, infrarrojo, imagen ptica, Galga
extensiomtrica, Tecnologa de seal
Dispersiva y Reconocimiento de Pulso
Acstico

Formato de la RTF
Formato I

Formato RTF

Lder del proyecto Jefe de revisin Versin de Proyecto

Plataforma Fecha de Lanzamiento Fecha de Revisin

Nombre de la empresa Software a revisar Revisor No. y firma
Hora de Inicio Hora de salida
Calidad de Software

ENERO-JUNIO 2014 14

Preguntas Cumple No cumple
Ingeniera de la Interfaz


Se han definido las funciones principales de forma
delimitada y sin ambigedad?
Se han definido las interfaces entre los elementos de la
interfaz?
Se han establecido lmites de presentaciones para el
sistema como un todo y para cada elemento?
Se han establecido restricciones de diseo para cada
elemento?
Se ha elegido la mejor alternativa?
Es factible la solucin tcnica?
Se ha establecido un mecanismo de verificacin y
validacin?
Existe consistencia entre todos los elementos de la
interfaz?


Anlisis de requisitos
Funcin y rendimiento de los elementos.
Se han definido las funciones principales de forma
delimitada y sin ambigedad?
Se han definido las interfaces entre los elementos de la
interfaz?
Se han establecido lmites de presentaciones para el
sistema como un todo y para cada elemento?
Se han establecido restricciones de diseo para cada
elemento?
Se ha elegido la mejor alternativa?
Es factible la solucin tcnica?
Se ha establecido un mecanismo de verificacin y
validacin?
Existe consistencia entre todos los elementos de la
interfaz?


Diseo preliminar

Arquitectura del software
Estn reflejados
los requisitos en
la arquitectura?
La modularidad
es efectiva?
Depende de
algunos factores
la arquitectura
del programa?

Calidad de Software

ENERO-JUNIO 2014 15
Se han definido
las interfaces
para los mdulos
y los elementos
externos del
sistema?
Es consistente la
estructura de
datos con el
mbito de
informacin?
Es consistente la
estructura de
datos con los
requisitos del
software?
Se ha
considerado la
facilidad de
mantenimiento?
Se han evaluado
explcitamente
los factores de
calidad?



Tcnica Utilizada Fecha de Prxima Revisin

Versin Plataformas


Problemas a grandes rasgos Material


Aprobacin y firma de revisores

Formato II y continuacin
Listas de Comprobacin para la revisin (check list).
Ingeniera de la Interfaz
Funcin y rendimiento de los elementos.
Se han definido las funciones principales de forma delimitada y sin ambigedad?
Se han definido las interfaces entre los elementos de la interfaz?
Calidad de Software

ENERO-JUNIO 2014 16
Se han establecido lmites de presentaciones para el sistema como un todo y para
cada elemento?
Se han establecido restricciones de diseo para cada elemento?
Se ha elegido la mejor alternativa?
Es factible la solucin tcnica?
Se ha establecido un mecanismo de verificacin y validacin?
Existe consistencia entre todos los elementos de la interfaz?
Anlisis de Requisitos
Es completo, consistente y exacto el anlisis del campo de informacin?
Es completa la particin del problema?
Estn definidas adecuadamente las interfaces internas y externas?
Refleja el modelo de datos correctamente los datos, sus atributos y sus relaciones?
Se pueden seguir todos los requisitos a nivel del sistema?
Se ha realizado un prototipo para el usuario?
Son alcanzables las prestaciones con las restricciones impuestas por otros elementos
de la interfaz?
Son consistentes los requisitos con la planificacin, los recursos y el presupuesto?
Son completos los criterios de validacin?
Diseo preliminar
Arquitectura del software
Estn reflejados los requisitos en la arquitectura?
La modularidad es efectiva?
Depende de algunos factores la arquitectura del programa?
Se han definido las interfaces para los mdulos y los elementos externos del sistema?
Es consistente la estructura de datos con el mbito de informacin?
Es consistente la estructura de datos con los requisitos del software?
Se ha considerado la facilidad de mantenimiento?
Se han evaluado explcitamente los factores de calidad?

Plan de Prueba
Se han identificado y secuenciado adecuadamente las principales fases de prueba?
Se ha establecido un seguimiento de los criterios/requisitos de validacin como parte
del anlisis de requisitos del software?
Se han comprobado pronto las funciones importantes?
Es consistente el plan de prueba con el plan global del proyecto?
Se ha definido explcitamente un plan de tiempos para la prueba?
Se han identificado y estn disponibles los recursos y las herramientas para la
prueba?
Se ha establecido un mecanismo para registrar los resultados de la prueba?
Calidad de Software

ENERO-JUNIO 2014 17
Se han identificado los conductores y los resguardos y se ha planificado el trabajo
para desarrollarlos?
Se ha especificado la prueba de resistencia para el software?
Mantenimiento
La facilidad de mantenimiento debe ser una caracterstica esencial en cualquier
software y factores para la facilidad de mantenimiento deben ser incluidas durante las
fases del desarrollo, adems de esto se considera lo siguiente:
Se han considerado los efectos laterales asociados al cambio?
Se ha documentado, evaluado y aprobado la peticin de cambio?
Se ha documentado el cambio, una vez hecho e informado a las partes interesadas?
Se han hecho RTFs adecuadas?
Se ha hecho una revisin de aceptacin final para garantizar que todo el software ha
sido actualizado, probado y reemplazado adecuadamente?



















Calidad de Software

ENERO-JUNIO 2014 18


Apartado Diseo Base de Datos
Lineamientos Generales
Objetivos de los lineamientos de las bases de datos.
Satisfacer los requisitos de contenido e informacin de los usuarios y aplicaciones.
Proporcionar una estructura de la informacin con facilidad de entendimiento.
Soportar los requisitos de procesamiento, rendimiento, espacio de almacenamiento y
cualesquiera otros objetivos.

El diseo de una base de datos deber de componerse en tres etapas:
1. Diseo fsico.
2. Diseo lgico.
3. Diccionario de datos.

Lineamientos para el diseo de relaciones de bases de datos:

1. Cada entidad de datos separada debe crear un archivo maestro. No es correcto
combinar dos entidades distintas en un solo archivo.
2. Un campo de datos especfico debe existir solamente en un archivo maestro.
3. Cada archivo maestro o relacin de base de datos debe tener programas para crear,
leer, actualizar y borrar registros, lo ideal es que solo un programa aada registros y
otro elimine.

El proceso de normalizacin proporcionar a los diseadores los siguientes aspectos
importantes:

Un marco formal para analizar los esquemas de relacin basndose en sus llaves y en las
dependencias funcionales entre sus atributos.
Una serie de pruebas de formas normales que puedan afectarse sobre esquemas de
relacin individuales de modo que la base de datos pueda normalizarse hasta el grado
deseado.

Generalizando deber buscarse que el esquema de datos definido en su conjunto alcance
la tercera forma normal, en cuyo caso una relacin no debera de tener un artculo no
clave determinado funcionalmente por otro atributo no clave-

Almacenamiento de informacin:
Durante el diseo, se deber decidir qu informacin es realmente necesaria.
Calidad de Software

ENERO-JUNIO 2014 19

Uso de tablas temporales:
El diseador podr considerar el uso de tablas temporales para la manipulacin de
informacin que no necesariamente deba ser almacenada en forma definitiva, existiendo
generalmente cuando esta conexin no se interrumpa. De lo contrario, el DBMS deber
remover automticamente la tabla y liberar el espacio que utilizaba.

Criterios para la creacin de ndices:

Cuando existen bsquedas frecuentes sobre un atributo o conjunto de ellos, lo
recomendable es tener esa columna indexada para obtener de manera ms rpida la
informacin.
Si la informacin de la base de datos se consultar con frecuencia sobre un atributo, ese es
el candidato ideal para ser indexado.

El almacenamiento de grandes textos en una base de datos puede resultar errneo, as
como crear ndices sobre campos de texto. En todos los casos si se tiene visualizado que
algn dato es candidato a convertirse en criterio de bsqueda, no deber ser definido del
tipo texto libre, sino que se buscara que pueda ser catalogado en un archivo maestro.

Caractersticas adicionales considerar en la etapa del diseo.
Independencia de los datos.
Crecimiento: mantenimiento constante al modelo de datos. Conforme crezca la base de
datos para incorporar nuevos tipos de informacin.
Capacidad de auditoria: el diseo de la base de datos siempre deber considerar el
manejo y registro de usuarios y permitir la rastreabilidad de las transacciones.
Las entidades que estn diseadas para soportar el intercambio de informacin en
procesamiento batch, deber ser diseada vista y almacenamiento de bitcoras. Ayudando
a mejorarla calidad de la informacin contenida en el sistema, coadyuva asegurando su
confiablidad.

Desempeo: el diseo de la base de datos, siempre deber responder a las necesidades
del desempeo. Realizando los ajustes apropiados durante la fase de diseo fsico, o antes
de los requerimientos funcionales y tcnicos.

Diseo fsico
El diseo fsico es el diseo de producir la descripcin de la implementacin de la base de
datos en estructuras de almacenamiento y mtodos de acceso que garanticen un desempeo
eficiente en la manipulacin de los datos.
Para llevar a cabo esta etapa: ya debi haberse tomado la decisin respecto a cul ser el
DBMS que se va a utilizar, ya que el esquema fsico se adopta en mayor parte a l. Entre el
Calidad de Software

ENERO-JUNIO 2014 20
diseo fsico y lgico existe un proceso que requiere de constante realimentacin, ya que
algunas decisiones que se tomen para mejorar el diseo fsico, afectan al modelo lgico.



Medidas del diseo de la base de datos:
1. Nomenclatura.
2. Utilizar caracteres alfanumricos.
3. Limitar los nombres a menos de 50 caracteres
4. Utilizar el guion bajo (_) para separar palabras.
5. Utilizar palabras en minsculas.
6. Los nombres de las tablas debern ir en plural y los nombres de las columnas en
singular.
7. Utilizar las letras ID en la columnas de llave primaria y fornea.
8. En una tabla, colocar primero la llave primaria seguida de las llaves forneas.
9. Los nombres de los campos deben de ser descriptivos de su contenido.
10. Los nombres de los campos deben de ser unvocos entre tablas, excepcin hecha de
las llaves.
11. Los puntos sealados, permitirn que paulatinamente la nomenclatura utilizada en las
bases de datos diseadas sean coherentes y consistentes, minimizando la posibilidad
de errores al momento de crear interfaces que permitan el intercambio de
informacin.
Mtricas:

1. Mtricas de Calidad para Esquemas Conceptuales de Bases de Datos.
Una mtrica de calidad para esquemas conceptuales de bases de datos deber
considerar como variables, aquellas caractersticas descritas en la seccin anterior,
siendo de la forma:
Q = q (L, Cm, Crr, M, E, A, Ext, Con), con
L: Legibilidad.
Cm: Complecin.
Cfr.: Correccin.
M: Nominalidad.
E: Expresividad.
A: Auto explicacin.
Ext: Extensibilidad.
Con: Consistencia.

Para cada una de estas cualidades se podra dar una valoracin subjetiva, por ejemplo
de un rango de 1 a 10, con 1 la peor valoracin, y 10 la mxima valoracin. Luego,
utilizando ponderadores, se podra obtener una mtrica de la calidad

Q0= p1* L+ p2*Cm+p3*Crr+p4*M+p5*E+p6*A+p7*Ext+p9* Con, con (p1++p9)=1

De este modo, se obtendr un valor de Q0 entre 1 y 10, siendo el esquema con mayor
valoracin el de mejor calidad.

Calidad de Software

ENERO-JUNIO 2014 21
En la siguiente seccin se presentan tres mtricas, una que evala la expresividad,
correctitud semntica y complecin de un esquema, (denominada Q1), y otra mtrica
que evala la auto explicacin de un esquema (denominada A). Luego, se define una
mtrica de calidad (parcial) Q que considera las caractersticas de expresividad,
correctitud semntica, complecin y auto explicacin, como una propuesta que
pretende obtener valores menos subjetivos.


1. Mtrica de Expresividad, Correctitud Semntica y Complecin de un
esquema.

La base para el uso correcto de esta mtrica es la existencia de una
especificacin de requisitos detallada, que haya sido validada por el usuario.
Se utilizar como unidad base el "requisito", el cual expresa un requerimiento
de informacin, o una restriccin a los datos.

El encuestado debe "traducir" el esquema a lenguaje natural, luego de lo cual
se contrasta con la especificacin de requisitos.
De ah se obtienen los siguientes valores.
Nmero de Requisitos reales : RT
Nmero de requisitos acertados con los reales : RA
Nmero de requisitos inexistentes : RI
Nmero de requisitos no correctos : RNC
Con
RT: nmero total de requisitos presentes en la especificacin de
Requisitos,
RA : nmero de requisitos que el esquema satisface y que coinciden
con algn requisito existente (de aquellos que se contabilizaron en
RT),
RI: nmero de requisitos que el esquema satisface, que no aparecen
en la especificacin de requisitos y que no tienen conflicto con algn
requisito de la especificacin.
RNC: nmero de requisitos que, estando presentes en la especificacin
de requisitos, estn representados de manera errnea en el esquema
(no se contabilizan en RA ni en RI).
Adems, RE = RA + RI + RNC; indica los Requisitos del Esquema, es decir,
nmero de requisitos que el esquema representa.
Sobre la base de lo anterior, se obtienen las siguientes mtricas:
Complecin = RA/RT
Correctitud Semntica = 1- RNC/RT
Expresividad = 1 - RI/RE
Para cada mtrica, los valores ms cercanos a 1 indican mayor calidad.

2. Mtrica de Auto explicacin de un esquema.
Un esquema se auto explica si encierra en s toda la informacin del problema
abordado, por ello no necesita de otras notaciones para ser entendido.
Se distinguen dos tipos de informacin externa o no incluida en el esquema.
Supuestos y descripciones no soportados por el esquema.
Restricciones no modeladas y no soportadas por el esquema (o por el
lenguaje utilizado, por ejemplo MER).
Calidad de Software

ENERO-JUNIO 2014 22
Sobre la base de la examinacin de la informacin externa al esquema se
obtiene:
Nmero de supuestos y descripciones : NS
Nmero de restricciones no modeladas : NR
Adems, se utiliza de la especificacin de requisitos:
Nmero total de requisitos : RT
Donde NS es el nmero de supuestos, que deben fraccionarse al nivel de
clusulas similares a un requisito.
RT es el nmero total de requisitos en la especificacin.
NR es el nmero total de restricciones presentes en la especificacin y no
modeladas en el esquema, pero expresadas utilizando otros lenguajes.
El auto explicacin quedara entonces determinada por:
Auto explicacin= 1- (NS + NR)/RT
Donde el mayor valor de calidad con respecto al auto explicacin es 1.

3. Mtrica de calidad sobre la base de la expresividad, correctitud semntica,
complecin y auto explicacin de un esquema.
Se define la mtrica de calidad Q1 como
Q1 = Auto explicacin + Complecin + Correctitud Semntica + Expresividad
Esta mtrica entrega valores entre 0 y 4, asignndole a cada caracterstica la misma
importancia.
Considerando ahora una cierta priorizacin de criterios, donde complecin y
correctitud semntica son de mayor importancia que auto explicacin y expresividad,
se define la siguiente mtrica de calidad.
Q = 0.5* Auto explicacin + 0.5 * Expresividad + 1.8* Complecin + 1.2 * Correctitud
semntica



ENERO-JUNIO 2014 23

Concepto Smbolo Medidas Mtricas
Entidad
Entidad fuerte


Representacin de
rectngulo
obligatorio

1.-Los nombres de los tipos de entidad deben ser nombres genricos y,
por
consiguiente:
Deben escribirse con todas las letras en minscula, salvo que sea un
acrnimo.
Omitiendo los signos ortogrficos, y no simplificando los trminos.
Cuando el nombre consta de varios trminos, se borran los posibles
vnculos
lingsticos y se concatenan los trminos principales que quedan
mediante un
Guion bajo).
2.- Deben utilizarse nombres significativos lo ms cortos posibles,
despreciando lo que
No es relevante para la significacin.
3.- Deben utilizarse nombres distintos para tipos de entidad distinguidos.
4.- No se deben utilizar distinciones tcnicas sin sentido para distinguir
nominalmente.
5.- tipos de entidad, Long. mx.: 20 caracteres
Entidad dbil


Representacin de
rectngulo con doble
lnea
Clave primaria


Utilizar las letras ID en
la columnas de llave
primaria.

Los nombres de los atributos se escriben en minsculas y en singular.
Debe ser un campo o un conjunto de campos que identifiquen
inequvocamente cada registro almacenado en la tabla.
Atributo

Se representa con
una elipse simple
Los nombres de los atributos se escriben en minsculas y en singular.
Todo atributo debe tener un nombre
que lo identifique entre los atributos
Calidad de Software

ENERO-JUNIO 2014 24
Atributo
multiavariado


Se representa con
una elipse en doble
lnea
del tipo de entidad o, segn sea el
Caso, entre los del tipo de relacin.
El nombre debe referir genricamente a la propiedad aplicable.
Para todo atributo se debe expresar su cardinalidad.
Por cardinalidad se
entiende el nmero mnimo
(cardinalidad mnima) y el nmero mximo (cardinalidad mxima) de
valores de la propiedad que pueden
Ser percibidos sobre una entidad o una relacin, segn sea el caso.
Atributo derivado



Atributo
discriminador de un
conjunto de
entidades dbiles

DOMINIOS DE LOS ATRIBUTOS
Boolean boolean Valor booleano
Char Char(<long>) Cadena de caracteres de longitud fija <long>.
Varchar varchar(<long>)
Cadena de caracteres de longitud variable acotada
Por <long>. Si el valor de long es N, significa
Que no existe cota.
Numeric numeric(<long>,<decim>)
Valor numrico de longitud <long> (sin contar
el signo ni la coma decimal) y con un nmero
<Decim> de dgitos en su parte decimal.
Float float(<long>)
Valor de punto flotante con un nmero <long>
De dgitos significantes.
Date date Una fecha.
RELACIN
Calidad de Software

ENERO-JUNIO 2014 25
Relacin




1.- Integrar en el nombre del tipo de relacin los nombres de los tipos
de entidad relacionados.
2.- Concatenar todos los elementos lingsticos mediante un guin bajo.
3.- Escribir con todas las letras en maysculas los elementos lingsticos
que refieren expresamente a la relacin. Escribir el resto en minsculas.
4.- No omitir ningn elemento lingstico que refiera a la relacin.
Omitir todos los signos ortogrficos.
5.- Sobre los nombres de los tipos de entidad aplicar las reglas de
simplificacin
a) Se toma la primera silaba y todas las consonantes iniciales de la slaba
siguiente si con ello se llega a cuatro caracteres o ms.
b) En caso contrario se toman las dos primeras slabas y todas las
consonantes iniciales de la tercera.
c) Como excepcin se consideran los trminos que empiezan con prefijo
(como prerrequisito). En ese caso, se toma el prefijo, siguiente slaba y
todas las consonantes iniciales de la siguiente.
Obligatorio long. mx.: 20
caracteres
Especializacion y
generalizacin


Relacin muchos a
muchos


un registro de la Tabla A
puede tener muchos
registros coincidentes en
la Tabla B, y viceversa
Relacin uno a uno


cada registro de la Tabla
A slo puede tener un
registro coincidente en
la Tabla B y viceversa
Relacin muchos a
uno

Una entidad en A se
relaciona
exclusivamente con una
entidad en B. Pero una
entidad en B se puede
relacionar con 0 o
muchas entidades en A.



ENERO-JUNIO 2014 26



Formato RTF

Lder del proyecto Jefe de revisin Versin de Proyecto

Plataforma Fecha de Lanzamiento Fecha de Revisin

Nombre de la empresa Software a revisar Revisor No. y firma
Hora de Inicio Hora de salida

Tcnica Utilizada Fecha de Prxima Revisin

Versin Plataformas


Problemas a grandes rasgos Material

Observaciones

Aprobacin y firma de revisores


ENERO-JUNIO 2014 27

Elemento Escala observaciones
1.-Los nombres de los tipos de entidad deben ser nombres genricos y, por
consiguiente:
las letras en minscula, salvo que sea un acrnimo.
omitiendo los signos ortogrficos, y no simplificando los trminos.
Cuando el nombre consta de varios trminos, se borran los posibles
vnculos
lingsticos y se concatenan los trminos principales que quedan
mediante un
guin bajo).
2.- Deben utilizarse nombres significativos lo ms cortos posibles.
3.- Deben utilizarse nombres distintos para tipos de entidad distinguidos.
4.- No se deben utilizar distinciones tcnicas sin sentido para distinguir
nominalmente.
5.- tipos de entidad, long. mx.: 20 caracteres
0% 20% 40% 60% 80% 100%


Llave primaria
6.-El nombre de la clave primaria: se escribe en minsculas y en singular.
Debe ser un campo o un conjunto de campos que identifiquen
inequvocamente cada registro almacenado en la tabla.
Escala Observaciones
0% 20% 40% 60% 80% 100%


Atributos

Escala Observaciones
Calidad de Software

ENERO-JUNIO 2014 28
0% 20% 40% 60% 80% 100%

7.- Los nombres de los atributos se escriben en minsculas y en singular.
Todo atributo debe tener un nombre que lo identifique entre los
atributos
del tipo de entidad o, segn sea el caso, entre los del tipo de relacin.
El nombre debe referir genricamente a la propiedad aplicable.
8.-Para todo atributo se debe expresar su cardinalidad.
nmero mnimo
nmero mximo



DOMINIOS DE LOS ATRIBUTOS
9.- Dominio
Escala Observaciones

0% 20% 40% 60% 80% 100%

Valor booleano

Cadena de caracters de longitud fija <long>.

Cadena de caracters de longitud variable acotada por <long>. Si el valor de
long es N, significa que no existe cota.
Valor numrico de longitud <long> (sin contar
el signo ni la coma decimal) y con un nmero
<Decim> de dgitos en su parte decimal.

Calidad de Software

ENERO-JUNIO 2014 29
Valor de punto flotante con un nmero <long> de dgitos significantes.

Una fecha.

RELACIN

Escala Observaciones

0% 20% 40% 60% 80% 100%


10.- Integrar en el nombre del tipo de relacin los nombres de los tipos de
entidad relacionados.
11.- Concatenar todos los elementos lingsticos mediante un guin bajo.
12.- Escribir con todas las letras en maysculas los elementos lingsticos que
refieren expresamente a la relacin. Escribir el resto en minsculas.
13.- No omitir ningn elemento lingstico que refiera a la relacin. Omitir
todos los signos ortogrficos.
5.- Sobre los nombres de los tipos de entidad aplicar las reglas de
simplificacin
a) Se toma la primera silaba y todas las consonantes iniciales de la slaba
siguiente si con ello se llega a cuatro caracteres o ms.
b) En caso contrario se toman las dos primeras slabas y todas las consonantes
iniciales de la tercera.
c) Como excepcin se consideran los trminos que empiezan con prefijo
(como prerrequisito). En ese caso, se toma el prefijo, siguiente slaba y todas
las consonantes
14.- long. mx.: 20 caracteres



ENERO-JUNIO 2014 30


Diseo lgico

En esta etapa, se transforma el esquema conceptual en un modelo lgico que utilizara las
estructuras de datos del modelo de base de datos en el que se basa el DBMS que se vaya a
utilizar, como puede ser:
1. Modelo relacional
2. Modelo de red.
3. Modelo jerrquico.
4. Modelo orientado a objetos.

Conforme se va desarrollando el esquema lgico, este se probar y validara contra los
requisitos del usuario, en el caso de los sistemas de informacin transaccionales se utilizara el
modelo relacional.
El esquema lgico es una fuente de informacin para el diseo fsico. Adems es un apartado
muy importante durante la etapa de mantenimiento del sistema de informacin, ya que
permite que los futuros cambios que se realicen sobre los datos, sean representados
correctamente en la base de datos.
Tanto el diseo conceptual como el diseo lgico, son procesos interactivos.

Medidas y mtricas :


El modelo relacional:
El concepto de relacin: El concepto de relacin: tuplas, atributos y dominios. , atributos y
dominios.
Restricciones de integridad en el modelo relacional.
El proceso de diseo lgico en el modelo relacional.
Del modelo E/R al modelo relacional:
Entidades.
Entidades dbiles.
Relaciones.
Relaciones de especializacin / generalizacin.
Fusin de tablas.
Normalizacin.

Representacin lgica Representacin Fsica Modelo relacional
Tabla Archivo secuencial Relacin
Fila Registro Tupla
Columna Campo Atributo

Calidad de Software

ENERO-JUNIO 2014 31

El concepto de relacin:
Tuplas, atributos y dominios, atributos y dominios
Atributo
(Ai): Elemento susceptible de tomar valores (cada una de las columnas de la tabla).
Dominio
(Di): Conjunto de valores que puede tomar un atributo (se considera finito).
Tupla: Cada uno de los elementos que contiene una instancia de la relacin (filas).





































Calidad de Software

ENERO-JUNIO 2014 32


























Formato RTF
Lder del proyecto Jefe de revisin Versin de Proyecto

Plataforma Fecha de Lanzamiento Fecha de Revisin

Nombre de la empresa Software a revisar Revisor No. y firma
Hora de Inicio Hora de salida

Tcnica Utilizada Fecha de Prxima Revisin

Versin Plataformas


Problemas a grandes rasgos Material

Observaciones

Aprobacin y firma de revisores
Calidad de Software

ENERO-JUNIO 2014 33

Elemento Escala Observaciones
0% 20% 40% 60% 80% 100%
Restricciones de integridad:
Asociadas a las relaciones de la base de datos.
Clave primaria





Integridad de entidad







Clave externa







Integridad referencial








Transformacin de un diagrama E/R en un esquema relacional:
Elemento Escala Observaciones
0% 20% 40% 60% 80% 100%
Entidades
Entidades fuertes
Atributos:
Compuestos
Derivados
Multivaluados

Clave primaria (una de las claves
candidatas del conjunto de
entidades)

Entidades dbiles:
Clave primaria
Clave externa

Relaciones
Elemento Escala Observaciones
0% 20% 40% 60% 80% 100%
Relacin muchos a muchos
Calidad de Software

ENERO-JUNIO 2014 34
Relacin uno a uno
Elemento Escala Observaciones
0% 20% 40% 60% 80% 100%
1 forma normal
2 forma normal
3 forma normal
4 forma normal
5 forma normal
































Calidad de Software

ENERO-JUNIO 2014 35
Diccionario de datos.
Medidas:
Durante el diseo de la base de datos deber, procurarse eliminar al mximo el uso y
aplicacin de datos almacenados en texto libre, ser importante que a criterio del diseador se
promueva el uso de informacin catalogada. Facilitando la localizacin plenamente
identificada.

Esencialmente se guardarn objetos que puedan resultar de inters para el sistema, como:
1. Tablas.
2. Vistas.
3. ndices.
4. Usuarios.
5. Planes de aplicacin.
6. Privilegios de acceso.
La informacin contenida en el catlogo es indispensable para que el sistema se comporte de
manera adecuada. El conocer los ndices que existen por ejemplo, facilitara o influira sin
dudas en la planificacin de la estrategia en una determinada consulta.

El subsistema de autorizacin, chequear por ejemplo que cada operacin que intente realizar
el usuario est permitida. De manera que tambin vemos que el catlogo sirve para chequear
la validez de una sentencia y mantener la integridad y la coherencia de los datos.

Las consultas al catlogo pueden realizarse con las mismas sentencias que se consulta
cualquier base de datos o tabla. Sin embargo las actualizaciones al catlogo (INSERT, DELETE,
UPDATE) no son posibles.

En contraposicin a estas sentencias existen otras proposiciones de definicin de datos, como
son CREATE TABLE, CREATE INDEX, DROP y ALTER. Cuando hacemos un CREATE TABLE,
solamente se hace un ingreso en la tabla systables (tabla que contiene todas las tablas del
sistema) del catlogo, sino que tambin se dan ingresos en la tabla syscolumns a todas las
columnas que contiene la nueva tabla a crear.


Medidas y Mtricas:
Durante el diseo de la base de datos deber, procurarse eliminar al mximo el uso y
aplicacin de datos almacenados en texto libre, ser importante que a criterio del diseador se
promueva el uso de informacin catalogada. Facilitando la localizacin plenamente
identificada.

Esencialmente se guardarn objetos que puedan resultar de inters para el sistema, como:
1. Tablas.
2. Vistas.
3. ndices.
4. Usuarios.
Calidad de Software

ENERO-JUNIO 2014 36
5. Planes de aplicacin (esquemas externos, conceptuales e internos y correspondencia
entre los esquemas).
6. Estadsticas de utilizacin, tales como la frecuencia de las transacciones y el nmero de
accesos realizados a los objetivos de las bases de datos.
7. Privilegios de acceso.
La informacin contenida en el catlogo es indispensable para que el sistema se comporte de
manera adecuada. El conocer los ndices que existen por ejemplo, facilitara o influira sin
dudas en la planificacin de la estrategia en una determinada consulta.

El subsistema de autorizacin, chequear por ejemplo que cada operacin que intente realizar
el usuario est permitida. De manera que tambin vemos que el catlogo sirve para chequear
la validez de una sentencia y mantener la integridad y la coherencia de los datos.

Las consultas al catlogo pueden realizarse con las mismas sentencias que se consulta
cualquier base de datos o tabla. Sin embargo las actualizaciones al catlogo (INSERT, DELETE,
UPDATE) no son posibles.

En contraposicin a estas sentencias existen otras proposiciones de definicin de datos, como
son CREATE TABLE, CREATE INDEX, DROP y ALTER. Cuando hacemos un CREATE TABLE,
solamente se hace un ingreso en la tabla systables (tabla que contiene todas las tablas del
sistema) del catlogo, sino que tambin se dan ingresos en la tabla syscolumns a todas las
columnas que contiene la nueva tabla a crear.






















Calidad de Software

ENERO-JUNIO 2014 37

























Elemento Escala Observaciones
Formato RTF
Lder del proyecto Jefe de revisin Versin de Proyecto

Plataforma Fecha de Lanzamiento Fecha de Revisin

Nombre de la empresa Software a revisar Revisor No. y firma
Hora de Inicio Hora de salida

Tcnica Utilizada Fecha de Prxima Revisin

Versin Plataformas


Problemas a grandes rasgos Material

Observaciones

Aprobacin y firma de revisores
Calidad de Software

ENERO-JUNIO 2014 38
0% 20% 40% 60% 80% 100%
1.-Tablas.





2.- Vistas.







3.- ndices.







4.- Usuarios.







5.- Planes de aplicacin (esquemas
externos, conceptuales e internos y
correspondencia entre los
esquemas).








6.- Estadsticas de utilizacin, tales
como la frecuencia de las
transacciones y el nmero de accesos
realizados a los objetivos de las bases
de datos.











7.- Privilegios de acceso.







Calidad de Software

ENERO-JUNIO 2014 39
Apartado Diseo de Procesos
Lineamientos Generales

Se presenta el marco conceptual, la importancia y perspectivas en el modelado de procesos.
Estas ltimas son necesarias para entender la relacin que existe entre los objetivos, las
actividades y las interacciones. Posteriormente, se analizan diversas tcnicas diagramticas y
las herramientas que utilizan un enfoque de procesos y su respectiva seleccin basndose en
las necesidades especiales de cada proceso o en la etapa de anlisis del mismo.

Implementar nuevos o mejores procesos en prcticas actuales y que sean aplicados en
el desarrollo de software
Evaluar y seleccionar el modelo de uso y mantenimiento de la plataforma
seleccionada. Por lo que debe proveer los recursos propios de la puesta en operacin
de software que permite la automatizacin de procesos de calidad de software.
Implementacin de todos los requisitos explcitos del diseo de procesos para calidad
de software.
Verificar si la plataforma permite la construccin e implantacin de los requerimientos
funcionales definidos en la etapa de Estudio y Definicin del proyecto. Con este fin
debe determinar si la plataforma cuenta con la capacidad y disponibilidad para
satisfacer los requerimientos funcionales de calidad de procesos de software.
Segn la experiencia y conocimiento adquirido desarrollo de procesos de software, es
necesario seleccionar los mecanismos y protocolos de, que se usarn en la
automatizacin de procesos.

Establecimiento de las medidas

Los defectos que detectan y reportan los usuarios finales
Los productos de trabajo de procesos entregados
Esfuerzo humano gastado en el diseo de procesos.
Tiempo de planificacin consumido en el diseo de procesos.






Calidad de Software

ENERO-JUNIO 2014 40
Medidas directas e Indirectas del Diseo de Procesos



La medicin del Proceso significa recoger, analizar e interpretar informacin cuantitativa sobre
nuestros procesos, para identificar las fuerzas y las debilidades de los mismos y para evaluarlos
despus de que hayan sido implementados y/o cambiados. Muchos son los propsitos que
abarca la medicin del Proceso en el presente caso de estudio nos centraremos en la medicin
del proceso para gestionar un proyecto de software enfocado en la implementacin y cambio
del proceso.
El medir un proceso de software implica medir las actividades relacionadas con el software
como por ejemplo el esfuerzo, el coste y los defectos encontrados, mientras que se pueden
hacer algunos esfuerzos para valorar la utilizacin de herramientas y de hardware, un recurso
principal que necesita ser gestionado en la ingeniera del software es el personal.

Existen tres tipos de mtricas de proceso:

Tiempo requerido para completar un proceso en particular: total del proyecto, por
ingeniero, por actividad, etc.

Recursos requeridos para un proceso en particular: esfuerzo en personas/da, costes de
viajes, recursos de hardware, etc.

Nmero de Ocurrencias de un Evento nmero de defectos descubiertos durante la
revisin del cdigo, nmero de peticiones de cambio en requerimientos, nmero promedio
de lneas de cdigo (LDC) modificadas en respuesta a un cambio de requerimientos, errores
detectados por el usuario, etc.





Calidad de Software

ENERO-JUNIO 2014 41
Por Diagrama de Flujo

Un diagrama de flujo es la representacin grfica de flujo de un algoritmo o de una secuencia
de acciones rutinarias. Se basan en la utilizacin de diversos smbolos para representar
operaciones especficas. Se les llama diagramas de flujo porque los smbolos utilizados se
conectan por medio de flechas para indicar la secuencia de la operacin.

Medidas

Conformar un grupo de trabajo donde participen aquellos que son responsables de la
ejecucin y el desarrollo de los procesos que se encuentran debidamente
interrelacionados y que constituyen un proceso.
Establecer el objetivo que se persigue con el diseo de procesos de los diagramas y la
identificacin de quin lo emplear, ya que esto permitir definir el grado de detalle y
tipo de diagrama a utilizar.
Definir los lmites de cada procedimiento mediante la identificacin del primer y
ltimo paso que lo conforman, considerando que en los procesos que estn
interrelacionados el comienzo de uno es la conclusin del proceso previo y su trmino
significa el inicio del proceso siguiente.
Identificacin de los pasos que estn incluidos dentro de los lmites de cada proceso y
su orden cronolgico.
Identificar los puntos de decisin y desarrollarlos en forma de pregunta.
Revisin del proceso con el fin de corroborar que el mismo se encuentra completo y
ordenado, previendo as la omisin de pasos relevantes.

Mtricas
Como mtrica para el diseo de procesos (por Diagrama de flujo), utilizaremos la simbologa
de diseo de Diagramas de Flujo.


Calidad de Software

ENERO-JUNIO 2014 42


















Calidad de Software

ENERO-JUNIO 2014 43
Formato de RTF

Lder del proyecto Jefe de revisin Versin de Proyecto

Plataforma Fecha de Lanzamiento Fecha de Revisin

Nombre de la empresa Giro de la Empresa a que va
Dirigido
Revisor No.

SI NO
El sistema requiere respaldo y recuperacin confiables?
Se requieren comunicaciones de datos especializadas para
transferir informacin a la aplicacin?
Se requieren comunicaciones de datos especializadas para
transferir informacin a la aplicacin?

Hay funciones distribuidas de procesamiento?
El desempeo es crtico?
El sistema requiere entrada de datos en lnea?
Las entradas, las salidas, los archivos o consultas son
complejos?


Tcnica Utilizada Sugerencia de Correccin Fecha de Prxima Revisin


Ttulo de Diagrama de Flujo Nombre de Analista que
realizo el D. Flujo
Fecha de Realizacin de D. Flujo

Simbologa utilizada y significado:








Observaciones:



Firmas de Revisores:


Calidad de Software

ENERO-JUNIO 2014 44