Aplicación de la ingenieria de la información a la planeación y desarrollo informático (página 3)

•  Tipo de información. Que contiene alguna metodología concreta, datos, gráficos, procesos, informes, modelos o reglas.

•  Tipo de controles. Si incorpora algún módulo de gestión de cambios, de mantenimiento de versiones, de acceso por clave, de redundancia de la información.

•  Tipo de actualización. Si los cambios en los elementos de análisis o diseño se ven reflejados en el repositorio en tiempo real o mediante un proceso por lotes (batch). Esto será importante en función a la necesidad de que los cambios sean visibles por todos los usuarios, en el acto.

•  Reutilización de módulos para otros diseños. El repositorio es la clave para identificar, localizar y extraer código para su reutilización.

•  Posibilidad de exportación e importación para extraer información del repositorio y tratarla con otra herramienta (formateo de documentos, mejora de presentación) o incorporar al repositorio, información generada por otros medios.

•  Interfases automáticas con otros repositorios o bases de datos externos.

• 2.6.4.1.  DIAGRAMACION AUTOMATICA

Algunos de los diagramas y modelos utilizados con mayor frecuencia son:

•  Diagrama de flujo de datos.

•  Modelo entidad – relación.

•  Historia de la vida de las entidades.

•  Diagrama Estructura de datos.

•  Diagrama Estructura de cuadros.

•  Técnicas matriciales.

Algunas características referentes a los diagramas son:

•  Número máximo de niveles para poder soportar diseños complejos.

•  Número máximo de objetos que se pueden incluir para no encontrarse limitado en el diseño de grandes aplicaciones.

•  Número de diagramas distintos en pantalla o al mismo tiempo en diferentes ventanas.

•  Dibujos en formato libre con la finalidad de añadir comentarios, dibujos, información adicional para aclarar algún punto concreto del diseño.

•  Actualización del repositorio por cambios en los diagramas. Siempre resulta más fácil modificar de forma gráfica un diseño y que los cambios queden reflejados en el repositorio.

•  Control sobre el tamaño, fuente y emplazamiento de los textos en el diagrama.

•  Comparaciones entre gráficos de distintas versiones. De esta forma será más fácil identificar qué diferencias existen entre las versiones.

•  Inclusión de pseudocódigo que servirá de base a los programadores para completar el desarrollo de la aplicación.

•  Posibilidad de deshacer el último cambio facilitando que un error no conlleve perder el trabajo realizado.

La Figura 14, muestra un ejemplo de él contenido de entidades en DbEasy.

Prototipado El objetivo principal de esta herramienta es poder mostrar al usuario, desde los momentos iniciales del diseño, el aspecto que tendrá la aplicación una vez desarrollada. Ello facilitará la aplicación de los cambios que se consideren necesarios, todavía en la fase de diseño. La herramienta será más útil, cuanto más rápidamente permita la construcción del prototipo y por tanto antes, se consiga la implicación del usuario final en el diseño de la aplicación. Asimismo, es importante poder aprovechar como base el prototipo para la construcción del resto de la aplicación.

• 2.6.4.2.  VERIFICACION DE ERRORES

En la verificación de errores tenemos a los errores de tipo y de sintaxis, las cuales se basan en las reglas de los diagramas de flujos de datos. Así, cada representación de proceso debe tener por lo menos un flujo de datos de entrada y por lo menos uno de salida. Dos datos de almacenamiento no pueden conectarse directamente. En los errores de tipo tenemos que un símbolo de proceso debe usarse siempre para representar un componente de procedimiento, etc. Las reglas de tipo se introducen para eliminar ambigüedades que puedan causar confusión cuando se intenta comprender una especificación o la transformación en código.

• 2.6.4.3  VERIFICACION DE INTEGRIDAD Y CONSISTENCIA

El propósito de esta verificación es asegurarse que el diagrama ha sido completado y que contiene toda la información necesaria. Esta verificación se la realiza cuando se haya terminado de elaborar el diagrama. Podemos mencionar, como ejemplo, la comprobación de que todos los componentes del diagrama estén debidamente etiquetados. También debe asegurarse de que cada objeto o elemento conste en las definiciones en el depósito CASE.

• 2.6.4.4.  VERIFICACION DE DESCOMPOSICION FUNCIONAL

Esta verificación se la realiza en una estructura de árbol jerárquico. Observando la jerarquía, lo componentes de cada nivel sucesivo contienen funciones que definen las funciones en el nivel anterior. Toda metodología estructurada contiene reglas para la descomposición funcional. La verificación de la descomposición funcional es una forma de control de calidad que puede realizarse en un diagrama de estructura de árbol.

Una clase especial de verificación de la descomposición funcional se denomina refinamiento semántico, en ella cada descomposición de una función en subfunciones se comprueba para asegurar que proporciona información más detallada sobre la función. Como ejemplo se puede mencionar que; si en un nivel una función se describe como realizadora de una operación de entrada/salida, en el siguiente nivel debe definirse el tipo de operación de entrada/salida.

• 2.6.4.5.  VERIFICACION DE LA METODOLOGIA

Al verificar la metodología depende de las particularidades de la metodología que se haya implantado en el CASE Workbench. Al verificar los errores, diagramas, sintaxis, se está comprobando la metodología, debido a que cada una tiene diferentes reglas y procedimientos.

• 2.6.4.6.  EL DEPOSITO CASE

Podemos definir a la palabra depósito como todo objeto o persona que se considera como centro de acumulación o almacenamiento.

Durante las primeras fases de la historia del desarrollo del software, el depósito era en realidad una persona, el programador que tenía que recordar la ubicación de toda la información relevante para un determinado proyecto de software, que tenía que recordar información que nunca se había escrito y reconstruir información que se había perdido. En la actualidad, el depósito es una base de datos que actúa como centro tanto para la acumulación como para el almacenamiento de información de ingeniería del software. El papel de la persona (del ingeniero del software) es interactuar con el depósito empleando herramientas CASE integradas con él.

Se utiliza un determinado número de términos distintos para hacer alusión al lugar de almacenamiento de la información de la ingeniería del software: base de datos CASE, base de datos del proyecto, base de datos de entorno de apoyo de proyecto integrado, diccionario de datos (una base de datos limitada) y depósito. Aún cuando existen sutiles diferencias entre algunos de estos términos, todos ellos se refieren al centro de acumulación y almacenamiento.

El depósito de un entorno I-CASE es el conjunto de mecanismos y de estructuras de datos que consiguen la integración entre datos y herramientas y entre datos y datos. Proporciona las funciones y herramientas de un sistema de gestión de bases de datos, pero además, el depósito lleva a cabo o precipita las funciones siguientes:

•  Integridad de datos: incluye funciones para validar las entradas efectuadas en el depósito, para asegurar la consistencia entre objetos relacionados, cuando un cambio efectuado en un objeto exige algún cambio en otros objetos relacionados con él.

•  Información compartida: proporciona un mecanismo para compartir información entre múltiples desarrolladores y entre múltiples herramientas, gestiona el control multiusuario a los datos y bloquea/desbloquea objetos para que los cambios no se superpongan inadvertidamente.

•  Integración datos-herramientas: establece un modelo de datos al que pueden acceder todas las herramientas del entorno I-CASE, controla el acceso a los datos y lleva a cabo las funciones de gestión de configuración adecuadas;

•  Integración datos-datos: el sistema de gestión de bases de datos relaciona los objetos de datos de tal modo que se puedan llevar a cabo las demás funciones;

•  Imposición de la metodología: el modelo E-R de datos almacenado en el depósito puede implicar un paradigma específico de ingeniería del software, como mínimo, las relaciones y los objetos definen un conjunto de pasos que será preciso realizar para construir el contenido del depósito; y

•  Estandarización de documentos: la definición de objetos de la base de datos da lugar directamente a un enfoque estándar para la creación de documentos de ingeniería del software.

Para realizar estas funciones, se define el depósito en términos de un metamodelo. El metamodelo determina la forma en que se almacena la información en el depósito, la forma en que las herramientas pueden acceder a los datos y estos datos pueden ser visualizados por los ingenieros de software, el grado hasta el cual se puede mantener la seguridad e integridad de los datos y la facilidad con que se puede extender el modelo ya existente para admitir nuevas necesidades.

El metamodelo es la plantilla en la cual se sitúa la información de ingeniería del software. Características y contenidos Las características y contenido del depósito se establecen a partir de determinar qué es lo que hay que almacenar en el depósito y qué servicios específicos son los que proporciona el depósito. Estos incluyen:

•  El problema que hay que resolver

•  Información acerca del dominio del problema

•  La solución del sistema a medida que vaya surgiendo

•  Las reglas e instrucciones relativas al proceso de software (metodología) que se está siguiendo

•  El plan del proyecto, sus recursos y su historia

•  Información acerca del contexto organizativo

Muchos requisitos del depósito son iguales a los de aplicaciones típicas que se construyen tomando como base un sistema de gestión de bases de datos (SGBD). De hecho, muchos de los depósitos CASE actuales hacen uso de un SGBD como tecnología de gestión de datos básica. Las características de un SGBD estándar en un depósito CASE que preste su apoyo para la gestión de información de desarrollo del software incluye lo siguiente:

Almacenamiento de datos no redundante. El depósito CASE proporciona un único lugar para el almacenamiento de toda la información pertinente al desarrollo de los sistemas de software, eliminando una duplicación que supone un desperdicio y es potencialmente proclive a errores.

Acceso de alto nivel. El depósito proporciona un mecanismo de acceso a los datos común de tal modo que no sea preciso duplicar las capacidades de gestión de datos en todas las herramientas CASE.

Independencia de datos. Las herramientas CASE de las aplicaciones blanco se aíslan del almacenamiento físico para que no se vean afectadas cuando cambie la configuración.

Control de transacciones. El depósito gestiona las interacciones entre múltiples partes de tal modo que se mantiene la integridad de los datos cuando existen usuarios concurrentes y en caso de fallo del sistema.

Seguridad. El depósito proporciona mecanismos para controlar quién puede visualizar y modificar la información contenida en él. Como mínimo, el depósito debería de imponer contraseñas multinivel y niveles de permiso que fueran asignados a usuarios individuales. El depósito debería de proporcionar también asistencia para copias de seguridad y restauraciones automáticas y también para archivar grupos seleccionados de informaciones.

Apertura. Los depósitos suelen proporcionar un mecanismo de importación/exportación. Apoyo multiusuario. Un depósito robusto debe de permitir que múltiples desarrolladores trabajen en una aplicación al mismo tiempo. Debe de gestionar el acceso concurrente a la base de datos mediante múltiples herramientas y por parte de múltiples usuarios, con arbitraje de accesos y con bloqueos en el nivel de archivos o registros.

El entorno CASE también efectúa demandas especiales con respecto al depósito que van más allá de lo que está disponible directamente en un SGBD comercial. Las características especiales de los depósitos CASE incluyen:

•  Almacenamientos de estructuras de datos sofisticadas. El depósito debe de admitir tipos de datos complejos tales como diagramas, documentos y archivos, así como sencillos elementos de datos. Un depósito también incluye un modelo de información (metamodelo) que describe la estructura, relaciones y semántica de los datos almacenados en él. El metamodelo debe de poder extenderse para dar cabida a nuevas representaciones y a informaciones organizativas únicas.

•  Interfaz de herramientas semánticas. El modelo de información del depósito (metamodelo) contiene una semántica que hace posible que toda una gama de herramientas interpreten el significado de los datos almacenados en el depósito. Entonces otra herramienta CASE puede interpretar el contenido del depósito y emplear la información según la necesite para su tarea. De este modo, la semántica almacenada en un depósito permite compartir datos entre una gama de herramientas.

•  Gestión de procesos/proyectos. Un depósito contiene información no sólo acerca de la aplicación de software en sí, sino también acerca de las características de cada proyecto particular y del proceso general de la organización para ingeniería del software (fases, tareas y productos).

Las siguientes características del depósito son abarcadas todas ellas por la gestión de configuración del software.

•  Versiones. A medida que progresa un proyecto, se irán creando muchas versiones. El depósito debe de ser capaz de guardar todas estas versiones para hacer posible una gestión efectiva de las versiones de los productos y para permitir que los desarrolladores vuelvan a las versiones anteriores durante la comprobación y depuración.

•  Seguimiento de dependencias y gestión de cambios. El depósito gestiona una amplia variedad de relaciones entre los elementos de datos almacenados en él. Entre estas se cuentan las relaciones entre entidades y procesos de la empresa, entre las partes de un diseño de aplicación, entre componentes del diseño y la arquitectura de la información de la empresa, entre elementos de diseño y productos, etc. Algunas de las relaciones son meramente asociaciones y algunas son dependencias o relaciones obligatorias. El mantenimiento de estas relaciones entre objetos de desarrollo se denomina administración de enlaces.

•  Seguimiento de requisitos. Una función especial que depende de la gestión de enlaces es el seguimiento de requisitos. Esta es la capacidad de seguir la pista de todos los componentes de diseño y de todos los productos que resulten de una especificación de requisitos concreta (seguimiento progresivo) así como la capacidad de identificar el requisito que haya generado cualquier producto dado (seguimiento regresivo).

•  Seguimiento de una auditoría. Relacionada con la gestión de cambio está la necesidad de un seguimiento de auditoría que establezca informaciones adicionales acerca de cuándo, por qué y por quién son efectuados los cambios. La información acerca de las modificaciones efectuadas en el código fuente se puede introducir en forma de atributos de objetos específicos del depósito. Un mecanismo de activación en el depósito resultará útil para solicitar al desarrollador o a la herramienta que esté utilizando que inicie la introducción de información de auditoría (tal como la razón del cambio) siempre que se modifique un elemento de diseño.

• 2.6.5.  CAMBIOS EN EL USO DE LAS HERRAMIENTAS CASE

La CASE representa un cambio fundamental en la actitud hacia el desarrollo del software.

A finales de los años sesenta; la introducción de las técnicas estructuradas ya representó un cambio en la actitud. Reaccionando ante el nacimiento de la crisis del software, entonces el punto de vista era que el desarrollo de software era un proceso complicado, tedioso y proclive al error. No debería ser tratado como arte privado de cada programador individual, sino como un proceso disciplinado y mecánico. El concepto de estructuración hacía hincapié en los estándares y procedimientos de programación y en el control de la gestión. La actitud era que la productividad y calidad del software podrían controlarse mejor a través de la disciplina, la formalidad y la estandarización.

Después, a finales de los años setenta volvió a suceder otro cambio de actitud en el proceso del software. Esta vez el punto de vista era que la productividad del software podría incrementarse con la utilización de herramientas que simplificasen el desarrollo de software. La crisis del software podría aliviarse si muchas personas pudieran desarrollar ciertos tipos de software para aplicaciones. Este cambio estuvo marcado por la introducción de las herramientas de cuarta generación y la programación dirigida al usuario final. Actualmente, desde finales de los años ochenta, vemos otro cambio de actitud ante el proceso del software. En un sentido, este cambio representa un paso atrás, hacia una visión más conservadora del desarrollo de software. De nuevo, el punto de vista es que el desarrollo de software es una tarea difícil que requiere una formulación disciplinada y mecánica, y que para la realización de sistemas complejos son necesarios profesionales del desarrollo de software altamente preparados. Aunque la programación orientada al usuario final y las herramientas de cuarta generación han realizado una valiosa contribución, la experiencia ha demostrado que tienen un puesto limitado en el desarrollo de software. El cambio más reciente es un redescubrimiento de los principios fundamentales de la ingeniería del software definidos durante los últimos 25 años. Aparecen de nuevo las técnicas estructuradas pero esta vez reforzadas con el concepto de la automatización del proceso de software. La CASE es un renacimiento de las técnicas estructuradas.

La actitud de la CASE es que el desarrollo y el mantenimiento del software debería verse como una actividad formal y disciplinada capaz de una comprobación mejor de la exactitud y automatización del proceso. La única forma real para incrementar significativamente la calidad y la productividad del software es a través de la automatización.

• 2.6.6.  HACIA DONDE SE DIRIGE LA CASE

Las principales líneas de evolución hacia las que parecen encaminarse las herramientas CASE son:

•  La utilización de la tecnología multimedia.

•  La incorporación de técnicas de inteligencia artificial.

•  Sistemas de realidad virtual.

• 2.7.  ACOPLAMIENTO DE METODOLOGIAS

Opciones de Integración Las herramientas Case pueden ser integradas de muchas formas. En un extremo se utiliza una herramienta CASE de forma aislada. Se crea un número limitado de elementos de configuración de software (documentos, programas o datos) que se manipulan mediante una única herramienta y cuya salida tiene el formato de copia de pantalla y/o documentación gráfica. Pocas herramientas CASE se utilizan en forma aislada. Se suele disponer de las siguientes opciones: Niveles de Integración CASE:

• a.  Intercambio de datos,

• b.  Acceso común a herramientas,

• c.  Integración de datos,

• d.  Integración total.

a) Intercambio de datos. La mayoría de las herramientas permiten exportar datos en forma de archivo sin estructura con un formato conocido. Esto permite un intercambio de datos punto a punto entre las distintas herramientas CASE, utilizando normalmente un filtro de transmisión intermedio. La desventaja del intercambio de datos punto a punto está en que, a menudo, sólo parte de los datos exportados es utilizable por la herramienta receptora, ya que no fue diseñada para ser totalmente compatible. Además, a medida que evoluciona el software, la necesidad de transferir archivos cada vez que se hace un cambio pequeño puede llevar mucho tiempo. No hay posibilidad de que los cambios se reflejen en ambos sentidos y, es difícil hacer comprobaciones cruzadas de documentos y mantener la integridad de la configuración a través de las distintas herramientas que se estén utilizando. b) Acceso común a herramientas. Permite al usuario utilizar distintas herramientas de forma similar. En un entorno multitarea, un usuario podría abrir simultáneamente varias herramientas, coordinando manualmente sus entradas y comparando las representaciones de diseño a medida que evolucionan. Por ejemplo, el usuario podría visualizar un diagrama de flujo de datos, un diagrama de estructura, un diccionario de datos y un segmento de código fuente, todos mantenidos por diferentes herramientas. c) Integración de Datos: 1) Gestión común de datos. Los datos de distintas herramientas se pueden mantener en una única base de datos lógica, que puede estar físicamente centralizada o distribuida. Hay una modalidad de fusión que permite combinar el trabajo de varias personas trabajando en diferentes partes de una aplicación. Aunque los datos generados por las distintas herramientas se gestionan de forma conjunta en el nivel de gestión de datos comunes, las herramientas no conocen de forma explícita las estructuras de datos y la semántica de representación del diseño de las demás. Consecuentemente, se requiere una etapa de traducción para permitir que una herramienta utilice la salida generada por otra. 2) Datos compartidos. Las herramientas del nivel de datos compartidos tienen estructuras de datos y semántica compatible, pudiendo intercambiar datos sin necesidad de una etapa de traducción.

3) Interoperabilidad. Las herramientas que combinan las características de acceso común y la capacidad de compartir datos, tienen la capacidad de interoperación. Esto representa el mayor nivel de integración entre herramientas diferentes. d) Integración total. Para alcanzar la integración total del entorno CASE se necesitan dos características más: gestión de metadatos y capacidad de control. Los metadatos representan información sobre los datos de ingeniería generados por las distintas herramientas CASE. Esta información incluye:

•  Definiciones de objetos (tipos, atributos, representaciones y relaciones válidas).

•  Relaciones y dependencias entre objetos (un proceso en un DFD, una entidad única o un fragmento de código de una subrutina).

•  Reglas de diseño del software (las distintas formas válidas de dibujar y equilibrar un diagrama de flujo de datos).

•  Procedimientos (fases estándar, informes, etc.) y sucesos (revisiones, finalizaciones, informes de problemas, peticiones de cambios, etc.) del flujo de trabajo (proceso).

CAPITULO III

Estudio y analisis costo / beneficio de planeacion y desarrollo informatico

• 3.1.  ESTUDIO DE EQUIPO DE PROCESAMIENTO

Las herramientas CASE abarcan también al análisis de la plataforma hardware existente en una organización, en razón de que depende mucho del equipamiento existente para poder implantar una herramienta que pueda correr bajo aquellos equipos.

Además, la debida importancia que debe tener el equipamiento de hardware radica en gran medida en que la información que generan nuestras organizaciones ha crecido en grandes volúmenes, por lo que, estas ayudarán a manejar con una mejor efectividad dicha información. Pero no solamente manejar, almacenar o distribuir información y/o datos debe ser la finalidad de las computadoras. Estas también deben servir para mejorar las relaciones de trabajo, fomentar la administración, elevar la productividad, incrementar las capacidades humanas, etc.

• 3.1.1.  REQUERIMIENTOS DE LA ORGANIZACIÓN

Toda organización actualmente, requiere de cambios innovadores para sus tareas administrativas y operacionales. Los requerimientos son variados y de diversa índole. Pueden ir desde la adquisición de grandes equipos hasta los más sofisticados. Para tener una mejor valoración de qué recursos debe tener una organización, es importante asegurarse que quien elabora dichos requerimientos, sea una persona que conozca el ambiente de la organización y que además sepa cual es la misión estratégica de la misma. De ahí, que es importante el contar con un comité que se encargue de la valoración informática organizacional.

• 3.1.2.  CONSIDERACIONES DE EQUIPO EXISTENTE EN LA ORGANIZACIÓN

Si una institución cuenta ya con algún equipamiento, se debería realizar un inventario de lo existente. Con este detalle, se puede elaborar una propuesta de reestructuración y/o reasignación de equipos. Esto estará condicionado al compromiso del personal y motivación que se haya dado al respecto, debido a que, puede generar un sentimiento de rechazo o descontento.

• 3.1.3.  CONSIDERACIONES DE EQUIPO DEL MERCADO

La oferta de hardware ha evolucionado a pasos agigantados. Conocer hoy en día, cuales son las nuevas tecnologías puede ser una labor de muchas personas que se dediquen solo a investigarlas, desplazando, como puede ser obvio, a las labores y tareas administrativas que deban ejecutar.

Al realizar implementaciones informáticas, es imprescindible tener el conocimiento adecuado de la oferta existente. Antes de realizar adquisiciones de equipo que puede ser catalogado como clave en nuestra organización, es importante conocer que otras instituciones ya lo poseen y cual ha sido su rendimiento y grado de satisfacción. Solo entonces se podrá tener una visión más clara de lo que se va a adquirir y del equipo en análisis.

• 3.2.  ESTUDIO DE SOFTWARE

En muchas áreas de aplicación del software, a menudo es más rentable adquirir el software de computadora que desarrollarlo. Los gestores de ingeniería del software se enfrentan con la decisión de desarrollar o comprar, que se puede complicar aún más con las opciones de adquisición:

• ? El software se puede comprar (con licencia) ya desarrollado,

• ? Se pueden adquirir componentes de software y entonces modificarse e integrarse para cumplir las necesidades específicas; o

• ? El software puede ser construido de forma personalizada por una empresa externa o por equipo interno, para cumplir las especificaciones de la organización.

Los pasos dados en la adquisición del software se definen según el sentido crítico del software que se va a comprar y el coste final, se pueden aplicar las directrices siguientes:

• 1.  Desarrollo de una especificación para la función y rendimiento del software deseado. Definición de las características medibles, siempre que sea posible.

• 2.  Estimación del costo interno de desarrollo y la fecha de entrega.

• 3.  Selección de tres o cuatro aplicaciones candidatas que cumplan mejor las especificaciones.

• 4.  Selección de componentes de software reutilizables que ayudarán en la construcción de la aplicación requerida.

• 5.  Desarrollo de una matriz de comparación que permita una comparación una a una de las funciones clave. Alternativamente, el seguimiento de las pruebas de evaluación para comparar el software candidato.

• 6.  Evaluación de cada paquete de software o componente según la calidad de productos anteriores, soporte del vendedor, dirección del producto, reputación y otros.

• 7.  Contacto con otros usuarios de dicho software y petición de opiniones.

En el análisis final, la decisión de desarrollar-comprar se basa en las condiciones siguientes:

•  Fecha de entrega del producto de software.

•  Tiempo y facilidad de traslado para mantenimiento.

•  Costo de adquisición vs. costo de desarrollo interno del software.

•  Costo del soporte externo vs. costo del soporte interno.

•  Costo de modificaciones externo vs. costo interno de modificaciones.

•  Costo de traslados para mantenimiento externo vs. interno.

Subcontratación (outsourcing) Las actividades de ingeniería del software pueden ser contratadas con un tercero quien hace el trabajo y que debería asegurar una alta calidad. El trabajo de software llevado dentro de la compañía se reduce a una actividad de gestión de contratos.

Con independencia de la amplitud del enfoque, la decisión de elegir "outsourcing" es a menudo financiera. Los ahorros de costos se pueden lograr reduciendo el número de personas y las instalaciones (por ejemplo: computadoras, infraestructura) necesarios para desarrollarlos internamente; en cambio, se pierde control sobre el software que necesita. Como el software es una tecnología que diferencia sus sistemas, servicios y productos, una organización corre el riesgo de poner su destino en manos de un tercero.

• 3.2.1.  EVALUACION DE SOFTWARE DEL MERCADO

Al evaluar el software que exista en el mercado, debemos entre otros aspectos ya mencionados anteriormente, tomar muy en cuenta los siguientes criterios:

• a.  Precio del software

• b.  Requerimientos del sistema:

•  Espacio en disco duro,

•  Necesidad de Ram,

•  Tipo de Procesador,

•  Sistema operativo a usar,

•  Tipo de capacidad gráfica,

•  Accesorios adicionales (unidad de cinta, unidad escritora óptica, equipo de digitalización, etc.)

• c.  Incorporación con otras tecnologías (internet, intranet, multimedia, etc.)

• d.  Capacidad de manejar acceso en red (cliente/servidor, centralizado, distribuido, etc.)

• e.  Interconectividad con otras herramientas.

• f.  Capacidad de ampliación del software.

• g.  Portabilidad.

Al evaluar un tipo de software, es determinante medir la calidad de mismo. Como se muestra en la Figura 15, el proceso incluye tres elementos: Tecnología, personas, producto (bien o servicio). Estos están dentro de un entorno de riesgo, desarrollo y rasgos del cliente. Tanto los elementos del proceso, como las condiciones de su interacción, deben desenvolverse eficazmente para poder desarrollar un buen servicio u ofrecer un producto. En este ambiente, el software al ser parte de la tecnología, toma el papel de apoyar el proceso, mediante el cual las personas (usuarios del software), podrán determinar una demora o agilidad en el procesamiento.

En el Anexo 1 nos permitimos exponer la recopilación de varias herramientas CASE con su respectivo análisis.

• 3.2.2.  EVALUACION PARA EL DESARROLLO DE SOFTWARE EN LA ORGANIZACIÓN

Al decidir si el desarrollo del software se lo realizará por parte de equipos propios de la institución, esta debe considerar varios parámetros claves, que permitan que los riesgos del proyecto sean reducidos al máximo para obtener un buen resultado. Podemos mencionar que uno de estos parámetros, es el convencimiento tácito que deben tener los directivos y además del apoyo incondicional a dicho proceso. Antes de tomar esta decisión podríamos mencionar que se debe estructurar una serie de requisitos, entre los que señalamos:

•  Identificar el nivel estratégico que deben tener los sistemas.

•  Identificar la magnitud de problemas a resolver en la Institución.

•  Evaluar los recursos de hardware y software disponibles en la Institución y el medio.

•  Evaluar el nivel del personal.

•  Efectuar un estudio de costo-beneficio, definiendo metas a lograr.

•  Elegir las herramientas apropiadas para la Institución.

•  Establecer un programa de capacitación de personal de sistemas y usuarios

•  Elegir una aplicación que reúna la mayor parte de los siguientes requisitos:

•  Gran impacto de resultados.

•  Disponibilidad de recursos.

•  Mínimo nivel de riesgos.

•  Máxima colaboración de usuarios.

•  Tamaño reducido de solución.

La decisión, como es lógico, siempre la tomarán los directivos de la organización. Esta responde a decisiones de la política global que se haya implantado; sin embargo, es importante que antes de tomar tal decisión exista al menos mecanismos o enunciados técnicos de qué es lo más conviene a la institución.

• 3.2.2.1.  TECNOLOGIAS DE DESARROLLO

Al evaluar las tecnologías de desarrollo, debe hacerse mucho hincapié en el grado de conocimiento y experiencia que tenga el equipo de desarrollo. Como quedó manifestado anteriormente en la sección 1.5.2.4, actualmente están vigentes las tecnologías de cuarta y quinta generación; y algunos todavía se inclinan por usar las de tercera generación.

Cada una es aplicable al desarrollo del software, la diferencia radica en las potencialidades que las generaciones vigentes poseen sobre las otras; de esta manera, el equipo de desarrollo puede centrarse en actividades claves tal como son el análisis y diseño.

• 3.2.2.2.  LA CASE EN EL ANALISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN

Los errores más comunes al desarrollar un sistema informático, se los comete más profundamente en las primeras fases del desarrollo. Por esto, depende como se realice el análisis y diseño del sistema para obtener resultados más favorables. Con una herramienta CASE, se puede dedicar más tiempo al análisis y diseño. Las especificaciones de diseño adoptan la forma de diagramas estructurados, que representan la estructura de los datos del programa, las entidades y las funciones de los procedimientos. Los prototipos rápidos reemplazan a los métodos manuales en la definición de los requerimientos de los usuarios eliminando de esta manera extensos documentos de especificaciones..

• 3.2.3.  CAMBIOS EN EL PROCESO DE GENERACION DEL SOFTWARE

Durante los primeros años de la era de las computadoras, el software era un añadido, se diseñaba a medida para cada aplicación. Durante la segunda era (mitad de la década de los sesenta hasta finales de los setenta), se introdujeron la multiprogramación, sistemas multiusuario, sistemas de tiempo real, además del aparecimiento de varios productos de software. Aquí aparece la crisis del software debido a los fallos detectados en los códigos cuando los usuario se trasladaban a otro tipo de plataformas hardware, empezó entonces a tomar forma el mantenimiento de software. Para la tercera era (hasta finales de los ochenta) se incorporan los sistemas distribuidos, incorporación de conceptos de inteligencia. La cuarta era se caracteriza por proporcionar tecnologías orientadas a objetos, sistemas expertos, redes neuronales, computación en paralelo y la incorporación masiva de las redes de computadoras.

En cuanto a las técnicas de desarrollo de software podemos decir que se encuentran vinculadas con el desarrollo de los lenguajes de programación. Inicialmente estas se dieron al nivel de lenguaje de máquina, posteriormente mediante una programación por lotes en la cual el traductor ejecuta instrucción por instrucción, lo cual generaba extensos programas. Los lenguajes de tercera generación hacen uso de las técnicas estructuradas, técnicas de orientación a objetos y de inteligencia artificial. Para los lenguajes de cuarta generación se caracterizan ya por tener soporte y generación inteligente propia de cada lenguaje y además de la incorporación de programación multiusuario, distribuida, multimedia, etc. Cada una de estas generaciones tienen acoplado metodologías propias de cada época, ya que las metodologías de desarrollo de sistemas de información no hubiesen tenido el efecto deseado sin el acompañamiento de herramientas que puedan soportar las fases de cada metodología. En lo que se refiere a la evolución y soporte de las herramientas CASE ya se lo trató en el apartado 1.5.

• 3.3.  ANALISIS COSTO BENEFICIO

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y pérdidas, la estimación del costo y del esfuerzo la planeación y desarrollo del software nunca será una ciencia exacta, son demasiadas las variables: Humanas, técnicas, de entorno, políticas, etc., que pueden afectar el costo final del proceso y el esfuerzo aplicado para desarrollarlo.

• 3.3.1.  COSTO VS. CARACTERISTICAS TECNICAS

Una importante consideración en la selección de máquinas es su flexibilidad y capacidad. Si la máquina que se está considerando puede utilizarse con efectividad para varios trabajos que se realizan en la oficina.

La velocidad de procesamiento puede ser un factor contribuyente, pero esto no debe ser el factor decisivo.

Además, existe el factor de los valores estéticos; la apariencia resultante de la oficina al contar con lo último y lo mejor en máquinas y equipo de oficina. Tales valores tienen un lugar, ya que las máquinas y el equipo de oficinas no sólo representan un medio físico de ayudar a los empleados a desahogar su trabajo, sino que también sirven como estímulo mental. El proporcionar la unidad apropiada no sólo forma una actitud positiva y de cooperación sino que ayuda a colocar al empleado en el marco mental apropiado para que trabaje con eficiencia.

• 3.3.2.  COSTO VS. PRODUCTIVIDAD

En la mayoría de los casos se hace la adquisición de equipo sobre la base del incremento en la productividad, expresada por costos más bajos, mayor volumen, mejor calidad o ahorro esperado. Los factores que determinan la productividad de la máquina por lo general, son:

•  El precio total corriente, incluyendo entrega e instalación;

•  Si se trata de un reemplazo, la marca, el modelo, el tipo y la condición de la unidad reemplazada y su probable valor de mercado

•  El porcentaje de tiempo de trabajo futuro de la unidad

•  El porcentaje de devolución de la inversión para la compañía

• 3.3.3.  COSTO VS. BASE DE LA ADQUISICION

El usuario de la máquina dispone de cuatro opciones:

• 1)  Comprar: el cual incluye un gasto de capital además de un gasto anual por operación y mantenimiento.

• 2)  Rentar a corto plazo: Implica una erogación menor inicial, con gastos estándar de operación.

• 3)  Rentar a largo plazo: La renta a largo plazo representa un mínimo del 75% de la vida útil de la máquina, las rentas varían.

• 4)  Utilizar un servicio de máquina: Los cobros varían de acuerdo al tipo de máquina y la cantidad de trabajo.

• 3.3.4.  COSTO VS. PRACTICA ADMINISTRATIVA

La depreciación y el mantenimiento son factores administrativos de importancia que afectan al costo de una máquina de oficina. En la depreciación, se debe remitir a las prácticas contables que siga una institución.

Las máquinas y el equipo de oficina son activos; y después de determinado periodo se las cancela debido a la depreciación. El periodo de depreciación de una computadora varía entre 3 a 5 años. Sin embargo, debido a los avances tecnológicos este período puede ser mucho menor, todo dependerá del sitio en el cual esté asignada y tipo de trabajo que realice.

El porcentaje usado en el periodo puede calcularse por varios métodos. Son comunes la línea recta y la suma de los dígitos. Todas las máquinas y equipo de oficina requieren una atención periódica para conservarlas en una condición satisfactoria. Debería aplicarse mayormente el mantenimiento preventivo en vez del correctivo.

• 3.3.5.  COSTO VS. CONSIDERACIONES DEL PERSONAL

La instalación de las máquinas y del equipo de oficina cambia las necesidades de personal, tanto con respecto al número de empleados como del nivel de su especialización; por lo tanto, debe tenerse en cuenta el problema de transferir, reducir y entrenar al personal de la organización. La preferencia del empleado también es de gran importancia. El elemento humano es vital para determinar si el equipo está adecuadamente operado o utilizado. Como quedó manifestado, son demasiadas las variables que intervienen para realizar un análisis de costo beneficio. En este capítulo, se ha presentado un esquema general de consideraciones que deben tenerse en cuenta a la hora de hacer una evaluación de conveniencia para la organización. Sin embargo; no siendo un recetario, podemos establecer algunos lineamientos generales para decidir en primera instancia si el costo de la planeación y desarrollo informático, será retribuido mediante los beneficios que podemos alcanzar; así:

• a) Consideraciones sobre planificación:

• 1. Establecer un presupuesto aproximado basándose en técnicas de estimación de proyectos.

• 2. Analizar el sistema de planificación a través de redes activas u otro método.

• 3. Determinar que procesos agregan valor a los bienes o servicios que la organización brinda al entorno.

• 4. Calcular y evaluar los factores de productividad; es decir, cuánto se demora en ser ejecutada una orden sobre el tiempo total de estar en el proceso.

• 5. Medir el grado de aceptación de la persona que usa el sistema (cliente de la organización).

• 6. Medir el grado de eficacia (hacer las operaciones correctas) y el grado de eficiencia (hacer las operaciones bien) del personal encargado de los procesos de la organización.

• b) Consideraciones sobre equipamiento:

• 1. Realizar un inventario detallado.

• 2. Revisar los recursos que se necesitan en cada proceso a modificar y/o implementar.

• 3. Reasignar los recursos a los procesos, en donde sea factible de hacerlo.

• 4. Evaluar rendimiento de equipos similares en la propia organización y en otras afines.

• 5. Estudiar la plataforma que se desea modificar, actualizar y/o implementar; basándose en la estrategia planificada.

• 6. Estudiar y revisar todas las posibilidades de características técnicas del equipamiento necesario para la implementación de los procesos.

• 7. Analizar posibilidades de: compra, contratación, renta; en los procesos que de acuerdo a cada caso lo permita realizar.

• 8. Realizar diagnósticos sobre conocimientos de los usuarios que serán afectados.

• 9. Analizar el volumen de carga de trabajo en cada proceso y equipararlo con el equipo asignado.

• c) Consideraciones sobre el software:

• 1. Detallar todos los procesos que serán automatizados, en el cual se haga constar fechas probables de funcionamiento del mismo.

• 2. Evaluar las condiciones del personal existente para desarrollo de software.

• 3. Evaluar las herramientas con las que cuenta la organización para desarrollar sistemas informáticos.

• 4. Mediante algunas métricas de software, estimar costos de desarrollo en la propia organización.

• 5. Analizar posibilidades de: compra, contratación a terceros; en el cual se realice un análisis de los requerimientos de mantenimiento posterior, posibles modificaciones en el software, tiempo de entrega de terceros.

• 6. En caso de asociación con terceros, realizar una proyección de incremento de costos por servicios.

• 7. Revisar cual es el requerimiento de portabilidad e integración; entre plataformas, procesos, software.

• 8. Analizar los niveles de aceptación del usuario, frente a un software de terceros.

• 9. Comparar costos de asesoría y apoyo in situ.

• 10. Establecer estrategias de métricas técnicas del software, que permitan mediar la calidad del mismo.

• d) Consideraciones sobre el personal:

• 1. Realizar un estudio sobre el nivel de conocimiento tecnológico del personal.

• 2. Evaluar el impacto que traerá consigo la implantación de nuevas tecnologías.

• 3. Estimar el impacto de posibilidades de reducción de personal.

• 4. Definir que cambios internos se necesitan para la implantación de nuevas tecnologías.

• 5. Proyectar el nivel de especialización de cada miembro de la organización y el entrenamiento respectivo.

• 6. Determinar, implicaciones económicas por efecto del mayor nivel de conocimiento del personal.

CAPITULO IV

Controles en la planificacion y desarrollo informaticos

• 4.1.  IMPORTANCIA DE CONTROLES ESPECIFICOS

La última fase de la planeación se ocupa de llevar a cabo las decisiones hechas en las fases anteriores y controlar su implementación.

El control es una actividad de comprobación que se ejerce sobre los procesos para determinar su grado de aceptación y verificar que se cumplan con las regulaciones, especificaciones y normas establecidas.

En esta tarea se puede implementar flujos de tipo PERT-CPM , en donde se pueden establecer e identificar las actividades requeridas, relaciones entre ellas y el tiempo destinado a cada una. Se puede hacer una ampliación indicando los responsables en la ejecución y además de las necesidades de recursos para dicha actividad. De esta manera se puede controlar aún mejor la fase de desarrollo e implementación.

• 4.2.  COMITES ORGANIZACIONALES

Los comités son los que someten las disposiciones que van a dictarse, al acuerdo de cuerpos de individuos a cuyo cargo están la dirección, la administración o la vigilancia de una empresa o de una institución.[22] Los comités se pueden dividir en organizacionales, ejecutivos, de vigilancia, consultivos, deliberativos; cada uno de los cuales en función de los niveles de la organización tendrán su respectivo campo de acción, responsabilidades y trabajos específicos asignados a ellos.

• 4.2.1.  IMPORTANCIA DE COMITES

La importancia radica en que comparten la responsabilidad de las órdenes, ya que éstas se dictan conforme al acuerdo que se toma de entre miembros. Permite la participación de varias personas en la realización de la política de la institución y de las decisiones de funcionamiento y en la responsabilidad directa de la realización del trabajo. Evitan de esta manera la personalización o individualización del trabajo.

• 4.2.2.  RESPONSABILIDADES

Dentro de los comités, y de acuerdo al nivel de jerarquía del mismo, pueden establecerse responsabilidades como:

•  Estudiar y resolver los problemas de la organización.

•  Revisión, coordinación de la actividad individual.

•  Verificar o inspeccionar las labores de los funcionarios o empleados.

•  Dar sugerencias que le son consultados por autoridades u otros consejos.

•  Dictar normas, manuales, procedimientos de trabajo.

•  Proponer mejoras en el desempeño de las funciones, entre otras.

• 4.2.3.  SELECCIÓN DE SUS MIEMBROS

Es importante que aparte de los encargados de la elaboración del proyecto, se incorporen las personas que se verán beneficiadas. Dichos miembros deberán tener un carácter consultivo, porque depende en gran medida de las orientaciones y experiencia que ellos tengan, para la consecución de un buen modelo de requerimientos y necesidades.

• 4.2.4.  DEPARTAMENTO DE AUDITORIA

La palabra auditoría proviene del latín "auditorius", y de esta proviene la palabra auditor, que se refiere a todo aquel que tiene la virtud de oír.

Por ende, debido a su importancia en el funcionamiento de una organización, existe la Auditoría Informática. El término de Auditoría se ha empleado incorrectamente con frecuencia ya que se ha considerado como una evaluación cuyo único fin es detectar errores y señalar fallas. El concepto de auditoría es mucho más que esto. Es un examen crítico que se realiza con el fin de evaluar la eficacia y eficiencia de una sección, un organismo, una entidad, etc.

La Figura 16, muestra que resultados obtiene una organización, cuando el rendimiento de sus procesos en general, se miden en función de la eficiencia y la eficacia.

Los principales objetivos que constituyen a la Auditoría Informática son el control de la función informática, el análisis de la eficiencia de los Sistemas Informáticos, la verificación del cumplimiento de la normativa general de la organización y la revisión de la eficaz gestión de los recursos materiales y humanos informáticos. El auditor informático a de velar por la correcta utilización de los amplios recursos que la organización pone en juego para disponer de un eficiente y eficaz Sistema de Información. Claro está, que para la realización de una auditoría informática eficaz, se debe entender a la organización en su más amplio sentido, ya que una Universidad, un Ministerio, un Hospital o cualquier tipo de organizaciones públicas o privadas utilizan la informática para gestionar sus "negocios" de forma rápida y eficiente con el fin de obtener beneficios económicos, de costes y/o sociales.

• 4.2.5.  RELACION ENTRE COMITÉ ORGANIZACIONAL Y DEPARTAMENTO DE AUDITORIA.

El comité organizacional que se integre para el desarrollo informático, muchas de las veces, es de carácter operativo-técnico; es decir, se encarga de elaborar planes y diseños arquitectónicos de los sistemas por implementar en la organización. Por su parte, al ser función de Auditoría Informática la de evaluar la eficacia y eficiencia de los sistemas, el cumplimiento de la normatividad del aseguramiento de calidad para Sistemas Informáticos; es importante que estos se realicen desde el mismo proceso de planeación. De ahí que, el cruzar información en la planeación y auditar los modelos resulta un paso muy importante para detectar errores y mejorar procesos en la fase de análisis y diseño.

• 4.3.  CONTROLES EN EL PROCESO DE PLANEACION INFORMATICA

En el desarrollo de la planeación, las actividades del equipo de sistemas de información deberán planearse de manera que los objetivos del equipo estén de acuerdo con las metas de la organización, de tal manera que se debe verificar que estas sean coherentes y estén en concordancia. A parte de los objetivos y metas se debe establecer un equipo multidisciplinario que pueda interaccionar todos los elementos de la organización, cambios organizacionales, avances tecnológicos y posibles requisitos gubernamentales.

En este proceso de control, es de vital importancia asegurarse de que los recursos que se necesiten para su posterior implementación y aplicación sean asignados adecuadamente y a tiempo; y además, que exista el compromiso de las autoridades a adquirir dicha implementación.

• 4.4.  CONTROLES EN LA APLICACION DE LA PLANEACION

Cada organización debe establecer o adoptar una metodología para el desarrollo del proyecto y asignar responsabilidades a cada fase que así lo determine. Se debe además evaluar si su división en varias fases es coherente, y si cada fase da lugar a un resultado cuantificable.

La asignación de responsabilidades y de tiempo para cada equipo así como de recursos pueden afectar a una buena marcha del desarrollo del proyecto.

Es importante también el que se establezca claramente cual es la naturaleza y alcance del proyecto. En este sentido, la documentación que se deba manejar debe ser concisa y estandarizada, de tal manera, que no se realicen trabajos dispersos en un mismo proyecto.

También es necesario, el que se incorpore documentación apropiada que pueda ser utilizada como pistas de auditoría en los diseños e implementaciones.

El control es una parte de la planeación, no pasos subsiguientes. Constituyen la culminación de un ciclo y el inicio de otro.

• 4.5.  CONTROLES EN EL PROCESO DE DESARROLLO INFORMATICO

El objetivo es asegurarse de que una vez concluido todo el desarrollo o parte de él, el sistema funcione conforme a las especificaciones funcionales, a fin de que el usuario tenga la suficiente información para su manejo, operación y aceptación. Las revisiones se efectúan en forma paralela desde el análisis hasta la programación y cumple entre sus objetivos:

•  Identificar inexactitudes, ambigüedades y omisiones en las especificaciones.

•  Descubrir errores, debilidades, omisiones antes de iniciar la codificación.

•  Buscar la claridad, modularidad y verificar con base en las especificaciones.

• 4.6.  IMPLEMENTACION DE VERIFICACION DE ERRORES EN LA HERRAMIENTA CASE

La verificación y comprobación de errores es una de las tareas de un CASE Workbench. La comprobación de errores comienza en el mismo momento en que empieza la diagramación y esta debe ser de manera interactiva. Al realizar el control de errores de forma interactiva, la calidad del software y las especificaciones reducen gran parte del tiempo que utilizará para efectuar las pruebas y correcciones del sistema final.

La forma de implementar, se la realiza a través de las reglas que cada metodología utiliza para especificar sus diagramas y procesos. La verificación de errores puede ser de tipo, sintaxis, integridad, consistencia, descomposición funcional, familia de diagramas, rastreo de requerimientos. Cada uno de estos errores se los trató en el apartado 2.6.

• 4.7.  ANALISIS DE LA LEGISLACION ECUATORIANA

Dentro de la legislación ecuatoriana, no existen normas establecidas para la utilización de metodologías, que permitan desarrollar e implantar planeaciones informáticas. Con la eliminación y limitaciones de algunos organismos estatales, entre los que podemos destacar al Consejo Nacional de Planificación, Consejo Nacional de Ciencia y Tecnología, Dirección Nacional de Informática, entre otras, la planificación para las instituciones públicas prácticamente es casi inexistente. Los intentos de planificación son cambiados constantemente debido al cambio de quienes rigen las políticas en el Ecuador. Para las instituciones privadas, estas se rigen de acuerdo a estándares internacionales de certificación.

Sin embargo, vale resaltar que la Contraloría General del Estado tiene normas de auditoría sobre "Sistemas de Información Computarizados" en el Vademécum Legal Volumen III código 133 y 134; en el cual consta de algunos lineamientos generales para instituciones del Sector Público y Organismos Autónomos, y trata sobre aspectos como: sistemas nuevos, actualización, accesos, proyectos, organización, financiamiento, entre otros.

• 4.8.  ANALISIS DE LA LEGISLACION INTERNACIONAL GENERALMENTE ACEPTADA

La legislación internacional se resume a la aplicación de Normas de Sistemas de Calidad, que en su mayor parte son dadas a través de la ISO.

Se entiende por Sistema de Calidad la estructura organizacional, las responsabilidades, los procedimientos, procesos y recursos que se requieren para la Gestión de Calidad.[23] Es importante comprender que el Sistema es propio de la organización y por ende los requisitos a él son definidos, por la necesidad de la misma y no en forma arbitraria por la Norma. En éste contexto la definición de la política de Calidad establece la relación entre la estrategia de la organización y su visión de la Calidad. Esto debe a su vez corresponder con la estructura organizacional, las responsabilidades, procedimientos, procesos y recursos que se definan para el Sistema de Calidad. Entre las normas que se destacan tenemos:

Sistemas de Calidad ISO 9001: Modelo para el aseguramiento de la calidad en el diseño, desarrollo, producción, instalación y servicio. Es la Norma más completa de las tres normas contractuales y fue diseñada para empresas que diseñan, producen y venden productos o servicios. Está estructurada en un total de 20 subcapítulos. Estos son:

• 1.  Responsabilidad de la Gerencia

• 2.  Sistema de Calidad

• 3.  Revisión del contrato

• 4.  Control del diseño

• 5.  Control de documentos y datos

• 6.  Adquisiciones

• 7.  Control de producto suministrado por el cliente

• 8.  Identificación y trazabilidad del producto

• 9.  Control de proceso

• 10.  Inspección y ensayo

• 11.  Control del equipo de inspección, medición y ensayo

• 12.  Condición de inspección y ensayo

• 13.  Control de producto no conforme

• 14.  Acciones correctiva y preventiva

• 15.  Manipulación, almacenamiento, envasado, preservación y despacho

• 16.  Control de registros de calidad

• 17.  Auditorías internas de calidad

• 18.  Capacitación y entrenamiento

• 19.  Servicios

• 20.  Técnicas estadísticas

Sistemas de Calidad ISO 9002: Modelo para el aseguramiento de la Calidad en la producción, instalación y servicio. La ISO 9002 es la segunda norma contractual. A diferencia de la Norma ISO 9001 la ISO 9002 fue diseñada para empresas que no diseñan sus productos o servicios. En gran medida es una versión de la ISO 9001 sin la inclusión del subcapítulo 4 que trata del control del diseño. Está estructurada en un total de 19 subcapítulos. Sistemas de Calidad ISO 9003: Modelo para el aseguramiento de la Calidad en la instalación y ensayos finales. La Norma ISO 9003 es la tercera de la norma contractual. Es básicamente una norma que regula solo el Control de Calidad y se deriva directamente de las normas militares norteamericanas de los años 40. En distintas ocasiones se trató de eliminar de la serie, dado que solo aplica a empresas que no producen ni dan servicio. Adicionalmente no contiene los capítulos de acciones correctivas y auditorías internas por lo cual le falta el proceso de mejoramiento continuo que las otras dos normas si exigen. Esta norma no aplica los subcapítulos 4, 6, 9 y 19.

También se tiene una serie de estándares en lo que respecta al desarrollo del software, tecnologías de información y sistemas informáticos: a) Nombre abreviado / código ISO/IEC 14102 Título: Tecnologías de la información. Líneas de orientación para la evaluación y selección de herramientas CASE Naturaleza: Norma internacional Ambito:

• Desarrollo de sistemas de información

• Entornos de ingeniería del software

• Entornos de desarrollo/ herramientas CASE

Las herramientas CASE representan una parte significativa de los utensilios tecnológicos utilizados en el desarrollo y en el mantenimiento del software. Esta  norma fue desarrollada por ISO/IEC JTC1/SC7 para auxiliar a los responsables de estas áreas a:

• Identificar requisitos organizativos para las herramientas CASE;

• Construir correspondencias entre tales requisitos y las características de las herramientas CASE a evaluar;

• Seleccionar la herramienta CASE mas apropiada, basada en mediciones de esas características.

Campo de aplicación y alcance Esta norma define los  procesos en un conjunto estructurado según las características de las herramientas CASE, para su utilización en la evaluación técnica y elección de una de tales herramientas. No debe utilizarse en caso de software de índole general (procesadores de texto, hojas de cálculo), ni en el caso de cuadros de referencia en el dominio de la ingeniería del software cuyo objetivo sea proveer mecanismos para la integración de datos, control y presentación. Estructura La norma se subdivide en dos grandes bloques: uno respetando los procesos de evaluación y elección de herramientas CASE y el otro describiendo las características funcionales de este tipo de herramientas. A continuación se presenta el índice resumido de la norma: •Entorno •Referencias normativas •Definiciones y acrónimos •Evaluación y elección de herramientas CASE •Proceso de iniciación •Proceso de estructuración •Proceso de evaluación •Proceso de elección •Características de las herramientas CASE •Características funcionales relacionadas con los procesos del ciclo de vida •Características funcionales relacionadas con la utilización de las herramientas CASE •Características genéricas de la calidad •Características genéricas no relacionadas con la calidad Conexión con otras normas Esta norma sigue el modelo de evaluación de productos de software descrito en ISO/IEC 9126 : Tecnologías de la información – Evaluación de los productos del software – Características de la calidad y líneas de orientación para su utilización, ampliando tales características en el caso de las herramientas CASE. Utilización: Se espera que esta norma conduzca a opciones más efectivas de herramientas CASE, así como a una mayor uniformidad en el modo como se describen las funciones y las características de estas herramientas. Acceso: Las normas ISO son documentos con copyright vendidos normalmente en forma impresa y, en ciertos casos, en microfilm o CD-ROM. El precio de una norma, debido a gastos adicionales, difiere de un país. Por lo tanto,  ISO indica los precios de sus publicaciones mediante un código alfabético en lugar de un valor monetario, código  que depende del número de páginas de la norma. En cada organismo nacional de normalización existe una lista que establece la correspondencia entre los códigos y los precios en vigor en el país en cuestión. La presente norma, al pertenecer a ISO/IEC JTC1/SC7 , tiene 55 páginas.

b) Nombre abreviado / código IEEE 1016 IEEE 1016-1 Título:

IEEE 1016: Recommended Practice for Software Design Descriptions. Práctica recomendada para descripciones de diseño de software IEEE 1016-1: Guide to Software Design Descriptions Guía para las descripciones de diseño de software Naturaleza:

Especificación técnica internacional de un consorcio industrial Ambito:

• Desarrollo de sistemas de información

• Procesos del ciclo de vida del software

Campo de aplicación y alcance:

IEEE 1016 es una recomendación para la "descripción de un diseño de software", entendiendo por tal la representación que sirve para comunicar cómo está diseñado el sistema. Especifica la información que una descripción de este tipo a de contener y la organización o esquema de presentación recomendada. Puede aplicarse a software de cualquier tipo (científico, comercial, etc.) destinado a funcionar en un ordenador. Su aplicación no está restringida por ninguna consideración relativa al tamaño, complejidad o carácter crítico del software. Tampoco está condicionada por la aplicación de una determinada metodología de diseño, gestión de configuraciones o control de la calidad, pues se supone que la información relativa a la calidad o los cambios en el diseño de la descripción será gestionada por otras actividades del proyecto. Así mismo, la norma no apoya ni se ve limitada por una técnica descriptiva particular, pudiéndose aplicar a documentos en papel, bases de datos automatizadas, lenguajes de descripción de diseños, etc. La Guía 1016-1 se ocupa de la aplicación de los métodos y la documentación de diseño contemplados en la recomendación 1016-1987, utilizando diferentes métodos de diseño comunes como ilustración y concreción de sus conceptos. Un nuevo proyecto de la IEEE se propone conseguir la armonización de la definición de contenidos entre los diversos productos de la línea de estándares IEEE en materia de ingeniería del software y de éstos con estándares internacionales relacionados, particularmente ISO/IEC 12207, estándar para la gestión del ciclo de vida del software, cuyos conceptos quedarán correlacionados con los de la IEEE 1016 a través de un anexo que se incorporará a ésta. Estructura / partes de la norma •Alcance/Referencias/Definiciones •Consideraciones para la producción de una DDS (Descripción de un diseño de software) •Información que a de contener una DDS •Organización de una DDS Conexión con otras normas •IEEE 729, Glosario estándar de terminología de ingeniería de software. •IEEE 730, Planes de aseguramiento de la calidad del software •IEEE 828, Planes de gestión de configuraciones •IEEE 830, Guía para la especificación de requisitos •ISO/IEC 12207 c) Nombre abreviado / código IEEE 1074 IEEE 1074-1 Título:

IEEE Standard for Developing Software Life Cycle Processes.

Estándar de IEEE para el desarrollo de procesos del ciclo de vida del software Naturaleza:

Especificación técnica internacional de un consorcio industrial Ambito

• Desarrollo de sistemas de información.

• Procesos del ciclo de vida del software

Campo de aplicación y alcance El estándar se ocupa del conjunto de actividades constituyentes de los procesos que son preceptivas para el desarrollo y mantenimiento de software, tanto considerado de manera independiente, como formando parte de un sistema, así como la información de entrada y salida correspondiente. Están fuera de la cobertura de la norma otras actividades complementarias como las relativas a la adquisición o al desarrollo de hardware. La revisión propuesta difiere de la original de 1995 en los siguientes aspectos: Todas las actividades de planificación se reúnen ahora en un solo grupo que pasa a llamarse "Actividades de Planificación del Proyecto". •El proceso de verificación y validación (V&V) es sustituido por un nuevo grupo de "Actividades de Evaluación" que incluye acciones específicas de V&V como revisiones, inspecciones y pruebas. El propósito general de la norma es contribuir a que las organizaciones que desarrollan o mantienen software puedan ajustarse mejor a los plazos y costes establecidos. Prevé que el usuario principal de esta especificación en un determinado proyecto de software será el arquitecto de procesos, el individuo cuya función es seleccionar un Modelo de Ciclo de Vida para el Software, crear el Ciclo de Vida del Software concreto del proyecto y asegurarse de que se sigue este ciclo durante el tiempo de vigencia de aquel. Estructura / partes de la norma IEEE 1074-1995 (Rev. de IEEE 1074-1991) IEEE 1074.1-1995 GUÍA para el desarrollo de Procesos de Ciclo de Vida del Software IEEE 1074 (proyecto de revisión de 1074-1995) Conexión con otras normas IEEE 0016 ISO/IEC 12207 d) Nombre abreviado / código IEEE 1209:1993 Título:

IEEE 1209:1993 Recommended Practice for the Evaluation and Selection of CASE Tools IEEE 1209:1993 Prácticas recomendadas para la evaluación y selección de herramientas CASE Naturaleza Especificación técnica internacional de un consorcio industrial Ambito:

• Desarrollo de sistemas de información.

• Entornos de ingeniería de software.

• Entornos de desarrollo/ herramientas CASE

Campo de aplicación y alcance IEEE 1209 normaliza la evaluación y selección de herramientas CASE que ofrecen soporte a los procesos de ingeniería de software, incluyendo gestión de proyectos, predesarrollo, desarrollo, posdesarrollo y procesos integrales. Los procesos de evaluación y selección recomendados se basan en la perspectiva del usuario de una herramienta CASE. Los criterios utilizados, por tanto, se ocupan únicamente de los aspectos de los programas visibles para el usuario, como entradas y salidas, funciones, interfaces con el usuario e interfaces con programas externos documentadas. El IEEE Estándar 1209 (Evaluation and Selection of CASE Tools) presenta un conjunto de líneas generales para evaluar herramientas CASE para «procesos de gestión de proyectos, procesos de predesarrollo, procesos de desarrollo, procesos de posdesarrollo y procesos integrales». Conexión con otras normas Reference Model for SEE Frameworks (ECMA TR/55) ISO/IEC 15504 (SPICE) CAPITULO V

5. Implementacion de una herramienta case para las fases de analisis y diseño de sistemas de informacion basado en la metodologia de la ingenieria de la informacion

• 5.1.  OBJETIVOS DE LA APLICACION CASE

La aplicación CASE desarrollada tiene por objetivos:

•  Automatizar tareas de diseño.

•  Automatizar los chequeos de errores de diagramación.

•  Mantener en el diccionario de datos detalles de los elementos del diagrama.

•  Mantener datos para ser reutilizables.

•  Controlar el proyecto de cada usuario.

•  Navegar por los diferentes niveles de un diagrama.

• 5.2.  CATEGORIA DE LA HERRAMIENTA CASE

Las categorías, en las que se han dividido a las herramientas Case son:

Herramientas Front-end.

•  Herramientas de planificación y definición de requisitos.

•  Herramientas de análisis y diseño.

•  Herramientas modelización y generación de prototipos.

Herramientas back-end.

•  Compiladores.

•  Generadores de estructura y código.

Gestión.

•  Gestión de proyectos (dirección proyecto).

•  Gestión de proyectos o ciclo de vida.

•  Gestión requisitos.

•  Gestión cambios y configuraciones.

Workbench

•  Conjunto de herramientas integradas que interactúan unas con otras de forma consistente.

La herramienta Case diseñada esta ubicada como una herramienta de alto nivel, debido a que las herramientas de alto nivel, (U-CASE: Upper CASE – CASE superior o front-end), están orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño de sistemas.

• 5.3.  PROCESOS QUE SOPORTA LA APLICACION CASE

Una Herramienta Case puede tener las siguientes capacidades:

•  Diccionario de Datos.

•  Verificación de errores.

•  Diagramación Automática

•  Generador de código

•  Capacidad para desarrollo Cliente / servidor y desarrollar sistemas para ser ejecutados en un ambiente cliente / servidor.

•  Componentes Web

•  Componentes multimedia, etc.

La aplicación desarrollada, soporta:

•  Diccionario de Datos.

•  Verificación de errores.

•  Diagramación Automática

•  Control del proyecto y niveles

• 5.4.  COMPONENTES Y DESCRIPCION DEL SISTEMA CASE A IMPLEMENTAR

• 5.4.1.  DICCIONARIO DE DATOS

En el diccionario de datos es un conjunto de definiciones de todos los datos que aparecen en un diagrama de flujo de datos. Este contendrá:

•  El nombre y el sinónimo (alias) del dato.

•  Descripción del contenido del dato.

•  Los datos elementales que se relacionan con el término.

•  El rango permitido del dato.

•  Elementos u objetos con los cuales se interrelaciona.

•  La longitud disponible en caracteres.

•  Información adicional

• 5.4.2.  BANCO DE TRABAJO

Para muchos autores, Banco de Trabajo, Diccionario de Datos, Repositorio; son palabras que definen la misma operación dentro de un entorno CASE. De tal manera que creemos que esta semántica es la más acertada.

• 5.4.3.  DIAGRAMACION AUTOMATICA

Los diagramas que serán generados son:

• 5.4.4.  PROCESOS DE VERIFICACION

Los procesos de verificación de errores que se aplicarán son:

Verificación de errores de sintaxis y tipo.

Verificación de consistencia e integridad.

• 5.5.  DESARROLLO Y CODIFICACION DE LOS COMPONENTES DEL SISTEMA CASE

La Metodología de la Ingeniería de la Información de Martin, se centra en la información y el modelo de la empresa a alto nivel. Este modelado a alto nivel, se consigue a través de realizar una planificación de la estrategia de la información.

La planificación de la estrategia de la información ve a todo el negocio como una entidad y aísla los dominios del negocio importantes para la totalidad de la empresa. PEI define los objetos de datos visibles a nivel empresa, sus relaciones y cómo fluyen entre los dominios del negocio.[24] En este estadio (estadio 1) se comienza con la creación de un plan de los sistemas de negocio en el que se definen los objetivos del negocio para los próximos cinco a diez años.[25] Junto con el plan estratégico se construyen los modelos de alto nivel (funciones básicas y la estructura de la organización) y datos de la empresa (relaciones existentes de cada entidad). El concepto de dominio, se encarga de realizar un Análisis del Area de Negocio (Estadio 2 de la Metodología). Las funciones definidas anteriormente permite dividir a la empresa en áreas lógicas (dominios); con lo cual se definirán y construirán los sistemas de información necesarios.

En la definición y diseño del sistema (estadio 3), se ocupa de las consideraciones del sistema lógico.[26] Es en este estadio que la metodología de la Ingeniería de la Información hace un salto hacia la Ingeniería del Software y se transforma en metodología similar de diseño y desarrollo de sistemas que abarca además al estadio 4 (construcción). Utiliza para esto: diagramas de flujo, de acción, de descomposición, de estructura, etc. Con estos breves antecedentes; la aplicación realizada se centra a una parte del estadio 3 de la metodología de la Ingeniería de la Información. Es decir, la aplicación servirá para apoyar al análisis y a las tareas de diseño de sistemas, los cuales incluye Diagrama de Flujo de Dato, Diagrama de Entidad Relación, Diccionario de Datos y Verificación de Errores. Conceptos De Diseño En La Aplicación La implementación de los componentes del Sistema Case se los realizó de la siguiente manera:

EL BANCO DE TRABAJO: Un conjunto integrado de Herramientas CASE diseñados para trabajar conjuntamente y automatizar (o proporcionar ayuda automatizada) totalmente el ciclo de vida del software, que incluye el análisis, el diseño, la codificación y la prueba.[27] Dado este concepto, la aplicación realizada alcanza la fase de diseño y permite de manera conjunta trabajar en:

• a) Control del proyecto y niveles (Child)

• b) Capacidad gráfica de diagramación

• c) Comprobación de errores

• d) Depósito de Información

Control del proyecto y niveles Al plantearse la construcción de un diagrama, así sea este uno solo, necesariamente deberá ser visto como un proyecto a desarrollar. La definición de proyecto, en esta aplicación es: conjunto de uno o más diagramas, uno o más diccionarios, que permiten mantener información acerca del análisis de un sistema y su correspondiente diseño.

De esta manera, cada sistema que se desee analizar y diseñar, deberá tener su propia identificación y nomenclatura, que en este caso el usuario deberá ser quien proporcione estos datos.

En el control de niveles subsiguientes, la aplicación es la responsable de administrar dichos niveles, tanto en manera ascendente (child de elementos del diagrama que lo posean) como descendente (parent de elementos).

Una vez realizado un diagrama child, este puede ser visualizado independientemente; situación ante la cual, no pierde vínculo permanente con todo el proyecto, sino momentáneo mientras el usuario lo requiera. Sin embargo, esto no quita, que a partir de ahí, el usuario pueda seguir generando más childs que sean necesarios. El momento que abre el proyecto respectivo, estos childs, se vinculan automáticamente a la totalidad del proyecto.