NOMBRE: MORELLA TATIANA GARCS VIVANCO

SEMESTRE: SPTIMO A
FECHA: 18/07/2014 DOCENTE: ING. MARCOS ARBOLEDA

Demasiadas personas a cargo del uso y adquisicin de software puede con
frecuencia resultar en que diferentes departamentos, sin saberlo, soliciten los
mismos ttulos de software. Centralizar su adquisicin de software puede beneficiar
a su compaa de varias maneras. Al crear una poltica centralizada de adquisicin
de software como parte de su plan SAM, su compaa puede:
Controlar los costos al comprar el tipo correcto de licencias y aprovechar
los descuentos de Licenciamiento por Volumen.
Optimizar el valor del software al reutilizar potencialmente o redistribuir
software a otros departamentos*.
Mantenerse organizado conforme crece su compaa al dar seguimiento a
todas las adquisiciones nuevas de software y mantener las licencias y los
contratos en una ubicacin central.

Para ayudar a lograr estos objetivos, su poltica de adquisicin de software
debe solicitar a su organizacin:
Delegar claramente y documentar la responsabilidad de adquirir software
nuevo y mantener registros.
Adquirir software solo de resellers acreditados.
Almacenar de manera segura la documentacin de prueba de licencias
(CDs originales, Certificado de Autenticidad, trminos de la Licencia de
Software de Menudeo (tambin conocido como End User License
Agreement), Manual de Usuario original y recibo de compra) en una
ubicacin centralizada y segura.
Dar seguimiento y actualizar el inventario de software sobre una base
regular para ayudar a garantizar el licenciamiento y cumplimiento apropiados.

Fusiones y adquisiciones de compaas tambin proporciona activos
adicionales de software y deben ser administrados en la misma manera que el
resto del software que se describe aqu.
Al comprender que las compras centralizadas pueden no ser lo adecuado para
todas las organizaciones, puede aprovechar algunos de los beneficios de compras
centralizadas a travs de otros medios. Por ejemplo, algunas organizaciones han
tenido xito al crear y mantener una base de datos centralizada de ttulos de
software que estn disponibles para re-implementacin dentro de su compaa. Las
filiales pueden comprar esta biblioteca de software antes de hacer compras locales
individuales, haciendo un mejor de los activos comunes de la organizacin.
Registro de software nuevo
El proceso para registrar software nuevo con frecuencia se pasa por alto, pero es
una de las maneras ms fciles para garantizar que su inventario de software
permanezca actualizado. Ayudar a evitar que su compaa desperdicie dinero en
comprar software que ya tiene. Para garantizar que se aada el software nuevo al
inventario de software de su compaa, desarrolle una serie de pasos que deban
seguir los empleados cuando arribe el software nuevo.
Los pasos deben cubrir:
Almacenar documentacin original, incluyendo rdenes y facturas de compra.
Almacenar el empaque y los medios originales.
Actualizar el informe o la base de datos del inventario de software.


.
Las normas y estndares aplicables a los SGBD podrn ser los siguientes:
Lenguaje SQL:
ISO/IEC 9075 (1987). "Database Language SQL".
ISO/IEC 9075 (1989). "Database Language SQL with Security
enhancements".
ISO/IEC 9075 (1992). "Database Language SQL" (conocido como SQL2).
Arquitectura de los SGBD:
ANSI/X3/SPARC (1977). "DBMS Framework".
ANSI/X3/SPARC DBTG (1986). "Reference model for DBMS
Standardization".
Incorpora el anterior, aadiendo la interconexin de sistemas abiertos y las bases de
datos distribuidas.
ANSI/X3/SPARC DBTG (1988). "Reference model for DBMS User Facility".
Bases de datos distribuidas
ISO DIS 9579 partes 1 y 2 (1990). "Remote Database Access".
Diccionarios de recursos de Informacin:
ISO 10027 (1990a). "Information Resource Dictionary System (IRDS).
Framework".
ISO 10027 (1991b). "Information Resource Dictionary System (IRDS).
Services Interface".
Dimensionamiento de la BD
El SGBD deber garantizar que es capaz de manejar el volumen de datos
requerido. Para ello, deber comprobarse que es adecuado en cada uno de los
siguientes puntos:
Nmero total de bases de datos que se van a crear.
Nmero total de tablas por base de datos.
Nmero mximo de filas por tabla.
Longitud mxima de fila.
Nmero mximo de ndices por tabla.
Nmero mximo de campos por ndice.
Rendimiento transaccional exigible
Si se va a utilizar el SGBD en un entorno transaccional, se deber conocer cul es
la carga (en transacciones por segundo o por minuto) que deber soportar el
sistema y tambin, se debe indicar cul es el tiempo de respuesta aceptable
(mximo y medio).
Plataforma/s sobre la/s que debe funcionar
Se deber especificar la plataforma o plataformas, fsicas y lgicas, sobre las que
debe funcionar el SGBD. Para cada una se deber especificar, al menos, el
fabricante, modelo y sistema operativo (especificando el nmero de versin).
Tipo de informacin que se va a tratar
Todos los productos incluyen soporte para una serie de datos bsicos:
alfanumricos, numricos (enteros y decimales), empaquetados, lgicos y fecha.
Segn las necesidades especficas de cada caso se deber exigir el soporte de
tipos de datos especiales tales como grficos, informacin textual, etc.
Acceso a los datos
Para el acceso a los datos debera evaluarse, adems del acceso desde el lenguaje
propio del SGBD (si existe), la existencia de herramientas de usuario final tales
como generadores de informes, formularios de entrada de datos, etc. Tambin, la
posibilidad de acceder desde los lenguajes que se estn utilizando previamente
como COBOL, PL/I, etc., que suelen estar soportados por medio de pre
compiladores.
Se debe tener en cuenta que el lenguaje SQL, es el nico modo estandarizado de
acceso a los datos en BDs relacionales, por lo que es especialmente deseable que
est soportada la versin normalizada de dicho lenguaje.

Integracin en el entorno existente
Aunque todo SGBD suele tener alguna herramienta de desarrollo propia, en las
instalaciones con desarrollos previos es importante examinar si se podr acceder a
la base de datos con las antiguas herramientas y a qu coste. Este punto
determinar, en gran medida, si es posible integrar las aplicaciones antiguas con el
SGBD. Tambin es necesario preparar la migracin de los datos del soporte antiguo
a la BD y evaluar el coste en recursos y de personal que supondr. Otro factor
importante es la integracin del SGBD con el sistema operativo en que se vaya a
instalar, por ejemplo, su integracin con las herramientas estndar de seguridad del
sistema operativo o su capacidad para aprovechar las facilidades de los monitores
de teleproceso instalados.
Herramientas de administracin
El nmero de las herramientas a disposicin del administrador de la base de datos
suele ser muy variable segn el SGBD. Se deber tener en cuenta que es frecuente
que parte de ellas se comercialicen como opciones separadas.
Tpicamente existirn herramientas para crear la base de datos, definir la estructura
fsica, cargar los datos a partir de ficheros secuenciales externos y viceversa, copias
de seguridad, utilidades para reorganizar la base de datos para mejorar su
eficiencia, aumentar o reducir su tamao, etc.
Tambin se debe valorar la existencia de herramientas para gestionar la seguridad
de monitorizacin y de obtencin de estadsticas (de utilizacin, consumo,
rendimiento...) .
Caractersticas de multiproceso
En entornos donde se requiere un alto rendimiento, puede ser interesante que el
SGBD soporte multiproceso. Esto permite que una BD sea accedida por varios
procesos que estn ejecutndose a la vez, en distintos procesadores y, por tanto,
evita las contenciones debidas a sobrecarga del procesador.

Conectividad y comunicaciones
Cuando se necesite poder acceder a BDs situadas en varias mquinas, habr que
asegurarse que el SGBD es capaz de hacerlo o que se incluye el producto
adecuado que lo permite. Igualmente, se debe comprobar que funciona con el
protocolo de comunicacin bajo el que se desea trabajar.
En la definicin del objeto del contrato y los requisitos inherentes al mismo, as
como en la valoracin y comparacin de ofertas de los licitadores, pueden intervenir
muchos factores y de muy diversa ndole.
Todos los factores que intervienen debern estar recogidos dentro del conjunto de
cuestionarios disponibles a tal efecto:
De empresa
Econmicos
Tcnicos particulares
Se van a relacionar a continuacin, algunos de los factores que suelen tener mayor
peso al seleccionar un SGBD. Sin embargo, debe tenerse en cuenta que la
importancia de cada factor variar en funcin de cada caso particular, por lo que
siempre ser necesario identificar la importancia relativa de cada punto.
Pruebas en condiciones reales
Como se ha expresado anteriormente, el rendimiento real de un SGBD es muy difcil
de predecir mediante procedimientos tericos. Por ello, si se va a instalar una BD
que contendr un gran volumen de datos o, si por cualquier otra razn, existen
dudas sobre la capacidad del SGBD de dar unas prestaciones adecuadas en las
mquinas disponibles, se debe exigir al suministrador una prueba anterior a la
adquisicin del SGBD. Esta prueba debe realizarse en la propia instalacin de
destino.


Volumen y organizacin de los datos
Debe estar garantizado que el SGBD es capaz de tratar el volumen de datos que se
vaya a necesitar en la instalacin. Para ello debe verificarse no slo que el SGBD
puede manejar el volumen total de datos, sino que no existe ninguna limitacin que
impida organizarlo de la forma ms conveniente.
Como ejemplo, se pueden sealar limitaciones al nmero total de bases de datos,
de tablas por base de datos, de filas por tabla o de ndices por tabla. La importancia
de las limitaciones en cada uno de estos puntos debe evaluarse por separado.