Desarrollo del sistema de información contable: Enterprise, base de datos y módulos de interfaz.

Desarrollo del Sistema de Información Contable: Enterprise, Base de Datos y Módulos de Interfaz!

Hay disponibles varios paquetes de software de contabilidad que ofrecen una variedad de características. Cuestan mucho menos de lo que costaría el software de contabilidad personalizado. Sin embargo, estos paquetes de software ofrecen solo la estructura para los sistemas de información contable. A lo sumo, reducen el esfuerzo de programación para los sistemas de información contable.

Cortesía de imagen: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

El desarrollo de los sistemas de información contable es mucho más que el software para la publicación de contabilidad y la formación de informes. También implica establecer procedimientos para capturar datos y distribución, así como el análisis de información contable.

El desarrollo de un sistema de información contable se explica con referencia especial a los requisitos de una empresa de negocios de tamaño mediano a grande. Sin embargo, estos pasos serían comunes a la mayoría de los otros sistemas de información en una empresa comercial.

1. Módulo de empresa:

El módulo empresarial de desarrollo de sistemas de información implica la identificación de entidades básicas y sus interrelaciones, la identificación de actividades básicas y la agrupación de estas actividades en subsistemas. Luego, las prioridades se deciden sobre la base del análisis de costo-beneficio para la empresa.

Entidades identificadoras:

Existe una gran cantidad de entidades en una empresa comercial y la lista es tan variada como lo son las actividades comerciales. Sin embargo, en esta etapa, la principal preocupación es identificar las entidades amplias, cada una de las cuales contiene un grupo de entidades elementales. Kerner ⁵ señala seis entidades básicas en una empresa comercial.

Son clientes, productos, vendedores, personal, instalaciones y dinero. En un sistema de información contable, hay tres entidades básicas, a saber, transacciones, cuenta y período de procesamiento. Las interrelaciones entre estas entidades se pueden expresar utilizando los diagramas ER como se muestra en la Fig. 8.2.

Las transacciones deben ser de diferentes tipos, como recibos, pagos, ventas, compra, adquisición de activos o reembolso de pasivos, etc., y cada uno de ellos puede denominarse entidad de nivel inferior. De manera similar, las cuentas pueden ser de diferentes tipos, como activos, pasivos, ingresos y gastos.

Cada uno de estos jefes puede tener entidades de nivel inferior, como activos fijos y activos corrientes. Estas entidades pueden dividirse aún más en entidades de nivel aún más bajo, como terrenos y edificios, plantas y maquinaria, etc. Sin embargo, en esta etapa, es necesario identificar las entidades amplias. Los detalles se elaboran a la hora de diseñar las bases de datos.

Las entidades se identifican a la luz de y con vistas a definir el alcance y el enfoque del sistema de información. Por ejemplo, si el sistema de información se considera un sistema de información estratégico, las entidades amplias se identificarán a la luz de los impulsos estratégicos que la empresa planea dar a sus actividades con la ayuda del sistema de información.

Estos impulsos podrían ser la minimización de costos, el servicio al cliente, la diferenciación de productos y las alianzas estratégicas. Las entidades básicas en tal caso serían clientes, canales, empresas competidoras, productos, etc.

Análisis de actividad:

Otro aspecto importante del módulo empresarial es la identificación de actividades asociadas con las entidades. Estas actividades se identifican ampliamente en forma de relaciones en los diagramas de ER. Sin embargo, los detalles se obtienen con la ayuda del análisis de actividad. La estructura organizativa existente es una fuente importante de información sobre las actividades generales emprendidas por la empresa.

Pero, para desarrollar sistemas de información que sean independientes de la estructura actual de la organización, es esencial basar el análisis de la actividad en las entidades básicas ya identificadas anteriormente. El siguiente nivel de análisis de actividad implica la identificación de las actividades del ciclo de vida. En el caso de que las 'transacciones' sean una de las entidades básicas en un sistema de información contable, existen cuatro actividades de ciclo de vida amplio, a saber:

1. Ciclo de vida de compra.

2. Ciclo de vida de la producción.

3. Ciclo de vida de los ingresos

4. Inversiones del ciclo de vida.

Del mismo modo, el período de procesamiento tiene dos actividades básicas del ciclo de vida, a saber:

a. Planificación y control del ciclo de vida.

segundo. Ciclo de vida interno y externo

Estas actividades del ciclo de vida son actividades en curso y se realizan continuamente. Cada una de estas actividades puede estar relacionada secuencialmente con algunas otras actividades. El tercer nivel de análisis de actividad implica la división de las actividades del ciclo de vida en funciones.

Por ejemplo, cada tipo de transacción debe ser iniciada y reconocida; luego los datos relativos a la transacción deben ser capturados, codificados para una clasificación futura, clasificados, resumidos e informados. Estas funciones se deben realizar de manera diferente para diferentes tipos de transacciones. El proceso de definición de las funciones se enfoca solo en aquellas actividades que crean, actualizan o usan información en la base de datos de la empresa.

En este nivel de análisis de actividad, las actividades son autónomas, tienen eventos o nodos de inicio y finalización claramente definidos y una persona identificable o un grupo de personas responsables de realizar la función.

Estas funciones se pueden dividir en sub-funciones hasta que las funciones sean lo suficientemente específicas para definir el módulo para programas de computadora. La división de las actividades del ciclo de vida en funciones y subfunciones ayuda a identificar las funciones que se repiten en más de una actividad del ciclo de vida.

Por ejemplo, la función de clasificación de los datos capturados se puede realizar en los ciclos de vida de compras y marketing. Dicho análisis de actividad ayuda a identificar oportunidades para mejorar el diseño existente al:

1. eliminando las funciones redundantes

2. Combinando las funciones duplicadas.

3. Simplificar y mejorar los métodos de procesamiento.

La redundancia se puede identificar mediante un análisis cuidadoso de las actividades. Las actividades que pueden ofrecer oportunidades para mejorar el procesamiento incluyen actividades:

a. Que se realizan en otros lugares también

segundo. Eso se puede combinar con otras actividades.

do. Eso puede ser manejado por otra persona también

re. Esto se puede realizar en alguna otra etapa del ciclo de vida que no agregue ningún valor al producto o servicio del sistema de información.

Una advertencia aquí es que no todos los despidos son malos. De hecho, se puede permitir que cierta redundancia o duplicación se introduzca en el sistema intencionalmente. Esto se puede hacer para mejorar el rendimiento y la confiabilidad del sistema.

Por ejemplo, parte de la duplicación puede ser necesaria para garantizar la simplicidad de los procedimientos y mejorar la velocidad de procesamiento. La eliminación de la redundancia puede resultar en "poner todos los huevos en una canasta" y, por lo tanto, puede afectar la confiabilidad. El riesgo de implicaciones inesperadas y los bajos rendimientos del nuevo método o procedimiento propuesto son otros factores que merecen atención antes de que se propongan cambios en el sistema de información.

Agrupar las actividades en subsistemas:

Una vez que las actividades se definen utilizando el enfoque descendente adoptado anteriormente, se reagrupan para formar subsistemas. Una decisión importante que se debe tomar en esta etapa se relaciona con la base de la agrupación. Puede que no exista un único criterio objetivo para decidir a qué subsistema pertenece una actividad.

La estructura organizativa actual puede proporcionar una de las bases para agrupar actividades. Sin embargo, la estructura organizativa actual puede sufrir cambios y la utilidad del sistema de información puede perderse.

Para agrupar las actividades en un subsistema, tomamos la ayuda de la teoría de la organización. Una de las características esenciales de cualquier buena estructura de la organización es que tiene como objetivo facilitar la coordinación de las actividades.

Un sistema de comunicación eficaz es un requisito esencial para una mejor coordinación. Por lo tanto, es esencial agrupar las actividades de tal manera que la comunicación se facilite dentro del grupo y se minimice la necesidad de comunicación entre grupos.

Con el fin de representar y documentar la agrupación de actividades en subsistemas, se utilizan diagramas de estructura o diagramas de bloques jerárquicos. La figura 8.3 muestra un diagrama de estructura que muestra los componentes del ciclo de ingresos.

Se pueden preparar cuadros de estructura similares para otros grupos de actividades y, finalmente, estos subsistemas se integran entre sí y proporcionan los elementos básicos para un sistema de información contable.

Los subsistemas así identificados por la agrupación de actividades son contendientes serios por ser entidades en la estructura de la organización. La ventaja con el método de agrupación para agrupar actividades es que la agrupación se basa en funciones y recursos, y no en regiones geográficas.

Una agrupación de este tipo basada en funciones garantiza la homogeneidad entre los miembros del grupo de personas asociadas con cada uno de los subsistemas. El impacto de la organización del sistema de información en la estructura de la organización no es infrecuente.

A menudo, la introducción de sistemas de información ha estado acompañada por cambios en las estructuras de la organización debido al hecho de que los nuevos sistemas de información cambian la forma en que las personas trabajan en una organización.

Por lo tanto, es tanto más importante que los diseñadores de sistemas de información trabajen en asociación activa con las personas de desarrollo de la organización mientras se realiza la agrupación de actividades en grupos y subsistemas. Esto garantiza no solo que la nueva estructura sea más pragmática sino también más aceptable para las personas. En tales casos, la transición del sistema antiguo al nuevo es menos dolorosa y menos costosa.

Estableciendo prioridades:

Una vez que los subsistemas se han identificado e integrado como un todo, las prioridades deben determinarse entre los diversos subsistemas y características de cada sistema. El sistema de información requeriría compromiso de recursos financieros.

Además, puede haber costos implícitos del nuevo sistema en términos de cambios necesarios en el proceso de operaciones. Por lo tanto, es esencial sopesar los pros y los contras de cada subsistema y subsistema de sistemas antes de que se diseñen e implementen.

Cada subsistema se evalúa sobre la base de criterios de evaluación bien definidos definidos en términos de factores críticos de éxito (CSF). Estos factores ya han sido identificados en la Sección 8.2.

El otro método es el intercambio de ideas, en el que las personas relevantes de la organización se reúnen para identificar los factores que merecen consideración para determinar las prioridades. Se fomenta el libre flujo de ideas en la primera etapa.

El principio subyacente, aquí, es que ninguna idea es tonta o irrelevante en esta etapa. Durante la segunda etapa, comienza el proceso de eliminación y, luego de las discusiones, se finalizan las sugerencias.

Una vez que se finaliza la lista de factores, se asignan los pesos relativos y se define la función de un criterio para evaluar cada componente del sistema de información contable propuesto.

2. Módulo de base de datos:

El sistema de información contable procesa gran volumen de datos. La gestión de los datos es, por lo tanto, una de las principales consideraciones en el proceso de su desarrollo. Hay dos enfoques básicos para el diseño de datos, a saber:

a. El enfoque tradicional, orientado a la aplicación, y

segundo. El enfoque de base de datos.

Enfoque tradicional:

El enfoque tradicional del diseño de datos está orientado a la aplicación en el sentido de que para cada aplicación se genera un conjunto separado de archivos de datos según sus requisitos. En otras palabras, los archivos de datos están dedicados a una aplicación determinada y de alguna manera son "propiedad" de la aplicación.

Por ejemplo, una aplicación de cuentas por cobrar debe tener el archivo de datos maestros del cliente, un archivo de transacciones de ventas y un recibo del archivo de transacciones de los clientes. Estos archivos de datos se utilizan solo para la aplicación de cuentas por cobrar.

Este enfoque es adecuado para sistemas de información contable más pequeños debido a su simplicidad. Sin embargo, a medida que el sistema de información crece en términos de volumen de datos y complejidad de análisis, también da lugar a ciertos problemas.

El problema fundamental con el enfoque tradicional es que los programas de aplicación dependen de los archivos de datos que utilizan y manipulan. Como consecuencia, cualquier cambio en el archivo de datos (en términos de adición o eliminación del elemento de datos) requiere cambios en todos los programas que utilizan el archivo de datos.

Esta dependencia de datos desalienta los cambios en los archivos de datos que conducen a la inflexibilidad. En ausencia de cualquier herramienta para realizar actividades de gestión de datos de tipo de rutina en los datos, dichas instalaciones se incluirán en los programas que utilizan el archivo de datos. Esto complica el programa. Otro problema se relaciona con el cumplimiento de la consulta ad hoc.

Para consultas inesperadas, se deben escribir programas especiales. Tales programas especiales toman tiempo para desarrollarse y tienen un solo uso por lo que son costosos. Hay una gran cantidad de duplicación en el registro de elementos de datos.

Por ejemplo, los elementos de datos como el nombre del cliente, el número de factura, el precio, etc. pueden incluirse en los archivos de transacciones para la aplicación de procesamiento de pedidos de venta, así como en la aplicación de cuentas por cobrar. Esto provoca redundancia en los datos.

La redundancia de datos resulta en un uso ineficiente de los medios de almacenamiento. También afecta la calidad de los datos, ya que la actualización de un elemento de datos dado puede no tener lugar en todos los archivos donde se almacena ese elemento de datos.

Enfoque de la base de datos:

El enfoque moderno para el diseño de datos es el enfoque de base de datos. Este enfoque se basa en los supuestos de que varias aplicaciones requieren conjuntos de datos que tienen mucho en común. Por lo tanto, es mejor tener un depósito común de datos que cumpla con los requisitos de datos de cada aplicación en el sistema de información.

El repositorio común se llama la base de datos y es administrado por un sistema de administración llamado Sistema de administración de bases de datos (DBMS). El DBMS es un software especialmente diseñado para administrar los datos en bases de datos de acuerdo con las solicitudes de los programas de aplicación, así como de aquellos que provienen directamente de los usuarios. El diseño conceptual del entorno de base de datos se muestra con la ayuda de la Fig. 8.5.

El enfoque de base de datos se ocupa de los problemas del enfoque de aplicaciones. Asegura la independencia de los datos ya que el DBMS se encarga del flujo de datos desde la base de datos a los programas de aplicación. La aplicación de usuario no necesita preocuparse por la ubicación de los datos en la base de datos. Se mantiene un diccionario de datos y se puede llamar a los datos utilizando las palabras especificadas en el diccionario de datos.

El enfoque de base de datos también reduce el tamaño y la complejidad de los programas de aplicación, ya que el DBMS realiza el tipo de rutina de las operaciones de procesamiento de datos, como la clasificación. El DBMS también se utiliza para atender las necesidades de consultas ad hoc. El DBMS utiliza el lenguaje de consulta estructurado (SQL) como el idioma para la comunicación entre el usuario y la base de datos.

El idioma es muy sencillo y muy cercano al inglés. Esto asegura que el usuario pueda obtener información de la base de datos cuando sea necesario. La cantidad de capacitación requerida por los gerentes para hacer consultas ad hoc es mínima y unas pocas horas de capacitación pueden proporcionar las habilidades básicas para usar el idioma. Quizás, la ventaja más importante del enfoque de base de datos es la reducción de la redundancia en las bases de datos.

Hay muchos modelos que se utilizan comúnmente en el diseño de bases de datos. Sin embargo, el enfoque moderno es seguir el modelo ER del diseño de la base de datos. Este enfoque es de arriba hacia abajo y los gráficos de ER dibujados anteriormente en el Módulo de Enterprise se convierten en el punto de partida.

Para cada entidad y relación, los atributos se identifican y documentan en los diagramas ER extendidos (diagramas EER). En un sistema de información contable, el EER puede dibujarse para cada entidad (transacción y cuentas) y la relación (efecto) para las cuentas de transacción se muestra en el diagrama de ER. Por ejemplo, para una transacción de venta, los atributos pueden especificarse y documentarse como se muestra en la Fig. 8.6.

Estos atributos se convierten en los elementos de datos (campos) en un registro en el archivo de datos para cada entidad (en este caso, el archivo de transacciones de ventas). De manera similar, para otras entidades y relaciones, se dibujan diagramas de ER extendido (EER).

Una vez que se identifican estos atributos, es probable que algunos de los atributos sean comunes en diferentes gráficos EER. Para evitar la duplicación de tales atributos comunes, se lleva a cabo la normalización de los datos.

3. Módulo de interfaz:

Un módulo de interfaz define las fuentes de los elementos de datos y los formatos de entrada / salida y pantallas de diálogo que se utilizarán en el sistema. También define los formatos de informe y las pantallas para la navegación de una parte de los sistemas de información a la otra.

En otras palabras, el módulo se ocupa de definir la interfaz entre el usuario y la máquina. La importancia del módulo de interfaz ha aumentado debido a una mayor comunicación entre el usuario y los sistemas de información.

Tanto la entrada de datos como la consulta de datos se han vuelto interactivas. En muchos casos, los formularios de entrada se eliminan del proceso y la entrada de datos se realiza directamente. Los requisitos cambiantes de la consulta de datos hacen que muchos formularios de informes sean demasiado rígidos. Las pantallas de informes interactivas proporcionan una mayor flexibilidad en la consulta de datos y permiten formatos de informes definidos por el usuario para ver e imprimir.

Pantallas de entrada:

Las pantallas de entrada se definen a la luz del proceso natural de la actividad comercial. Por lo tanto, dependen principalmente de los formularios que se utilizan para registrar manualmente los datos cuando la empresa los recibe por primera vez. Estos formularios, en un sistema de información contable, pueden incluir facturas, órdenes de compra, órdenes de venta, comprobantes de gastos, etc.

Así, en el módulo de interfaz, también se revisan los formularios; Las pantallas rediseñadas y de entrada se definen a la luz de las formas utilizadas por la empresa. En un sistema de información contable, hay que tener más cuidado con el diseño de la pantalla.

Una pequeña mejora en la pantalla de entrada que guarda el ingreso de datos puede resultar en ahorros sustanciales porque la cantidad de veces que se usa la pantalla de ingreso de datos es muy grande. Los siguientes factores pueden tenerse en cuenta al diseñar la pantalla de entrada:

(a) Emparejando con las formas:

El formato de la pantalla de entrada debe coincidir con los formularios de entrada. A veces, vale la pena adoptar el mismo formato que utiliza el formulario de entrada. En la medida de lo posible, incluso el color del fondo de la pantalla puede coincidir con el color del formulario de entrada.

(b) Interactivo:

La pantalla de entrada debe ser interactiva. Debe señalar los errores en la entrada de datos en el momento de la entrada y permitir las correcciones. Cada elemento de datos debe tener alguna condición de validación de datos y cualquier violación de dicha condición de validación de datos debe resaltarse automáticamente en el momento de la entrada de datos.

Por ejemplo, una pantalla de ingreso de datos para el ingreso de la factura debe señalar un error en el ingreso de la fecha si la fecha no es válida. La fecha puede no ser válida porque está fuera del período contable o el mes ingresado es mayor a doce.

(c) Consistencia:

Las pantallas de entrada deben ser coherentes para definir los términos y la ubicación de ciertos tipos comunes de elementos de datos. Ayuda a reducir el tiempo de entrenamiento ya que mejora la familiaridad; por ejemplo, la fecha de la transacción siempre se puede colocar en la esquina derecha de cada uno de los documentos de la transacción.

(d) Simplicidad:

Una de las características básicas de una buena pantalla de entrada es la simplicidad. Demasiadas secciones resaltadas, parpadeo de valores o atributos, o poner demasiadas casillas y subrayar solo agregan complejidad y confusión. A veces, los pitidos se utilizan para señalar los errores de entrada de datos. Debe haber un uso juicioso de tales pitidos y, en general, deben evitarse.

(e) Flexibilidad:

La pantalla de entrada debe estar sujeta a modificaciones. Debe permitir a los usuarios realizar modificaciones en términos de adición o eliminación y reubicación de elementos de datos. El procedimiento de modificación debe ser simple. En estos días, los generadores de pantalla disponibles de varios fabricantes de software ofrecen características tales como arrastrar y arreglar / soltar cualquier elemento de datos de la pantalla mediante el uso de un dispositivo señalador normal como el mouse.

(f) Por encargo:

Las pantallas deben ser personalizadas para cada categoría de usuario. Esto reduciría indebidamente los procedimientos de arranque y entrada.

Pantallas de informe:

Los informes pueden prepararse para un análisis posterior por parte de algún otro programa informático o por el propio usuario. Los datos dirigidos para el procesamiento por programas informáticos, como hojas de cálculo, paquetes estadísticos, procesadores de texto, se guardan en archivos de datos.

Es mejor colocarlos en un formato de datos estándar para que se pueda acceder fácilmente. Los informes destinados a los usuarios normalmente se guardan en forma de texto, tablas y gráficos. Se deben hacer esfuerzos para asegurar que los informes se realicen y se comuniquen de manera oportuna, precisa, clara y a bajo costo.

Pantallas de diálogo:

Las pantallas de diálogo son las que se utilizan para identificar y realizar las tareas en el sistema de información. Definen lo que se puede hacer con la ayuda del sistema de información, cómo navegar de una tarea a otra y cómo realizar varias tareas que el sistema de información permita.

Estas pantallas deben ser simples e inequívocas. La simplicidad puede introducirse al proporcionar una Interfaz Gráfica de Usuario (GUI) y tener un número limitado de elementos de menú en una pantalla. El procedimiento para navegar de un menú a otro debe ser simple, en la secuencia correcta y fácil de seguir. También debe señalar errores en el ejercicio de las opciones y ser rápido para corregir el procedimiento.

Herramientas CASE para diseño de pantalla:

Hay una variedad de herramientas CASE disponibles para diseñar formularios, pantallas e informes. Estas herramientas tienen la ventaja de ofrecer un entorno de diseño que es flexible y fácil de entender incluso para un nuevo usuario.

Dado que estas herramientas cuentan con instalaciones de creación de prototipos de pantalla, es posible tener una mayor participación de los usuarios en el proceso de diseño de la pantalla. Por supuesto, estas herramientas permiten cambios rápidos y mejoran la productividad de los programadores al generar códigos para la implementación final. Esto resulta en un tiempo de desarrollo reducido.

Una vez que los formularios, las pantallas de entrada / salida y las pantallas de diálogo estén listos, se deben probar y modificar en consecuencia. Las formas y pantallas diseñadas utilizando las herramientas CASE se pueden modificar fácilmente. Por lo tanto, se deben hacer esfuerzos para mejorar la aceptabilidad del sistema mediante pruebas y modificaciones adecuadas de formularios y pantallas.

4. Módulo de aplicaciones:

Este módulo amplía los subsistemas ya identificados en el módulo empresarial. Para cada subsistema identificado en el diagrama de estructura, los procedimientos de procesamiento detallados se definen en este módulo.

En otras palabras, el módulo de aplicación se ocupa principalmente de los procesos involucrados en convertir los datos de entrada en valores que formarán parte de los informes tal como se definen en el módulo de interfaz. Cabe señalar que solo se deben definir aquellos procesos que

(a) Cambiar los valores en las bases de datos, o

(b) Eso no es parte de la base de datos pero se requiere en los informes definidos en el módulo de interfaz.

Se puede acceder a los valores que ya existen en la base de datos utilizando el lenguaje de consulta DBMS según el requisito de los usuarios sin desarrollo de programas para este propósito. Por lo tanto, la tarea del módulo de aplicación se reduce por el trabajo ya realizado en el diseño de la base de datos y el diseño de la pantalla.

Diagrama de flujo de datos:

El rol del administrador en este módulo es básicamente identificar el procedimiento de procesamiento básico. Los algoritmos detallados generalmente están definidos y documentados por un profesional del sistema de información, por supuesto, con la ayuda activa del gerente.

La herramienta utilizada para expresar los procesos a realizar para convertir los datos de entrada en salida es el Diagrama de flujo de datos (DFD). Describe el flujo de datos. Define lo que se debe hacer e ignora cómo se debe hacer o cómo se estaba haciendo antes. Este enfoque permite cambios en el sistema y las debilidades del sistema existente se pueden eliminar siguiendo este enfoque.

Símbolos DFD:

Hay cuatro símbolos básicos utilizados en DFDs. Son:

(i) Terminador:

Terminator es una fuente externa de flujo de datos o un receptor externo de datos. Es una entidad u objeto externo, como cliente, proveedor, accionistas, etc. Dado que los terminadores son entidades externas, la comunicación entre los terminadores se excluye del sistema. El terminador está simbolizado por un rectángulo (generalmente, sombreado) y la etiqueta se coloca en el rectángulo.

(ii) Flujo de datos:

El flujo de datos transporta una serie de elementos de datos relacionados con el evento que inicia el terminador. Se simboliza con una flecha en DFD y la dirección del flujo se indica mediante la dirección de la flecha. Las flechas están, generalmente, etiquetadas a menos que estén dirigidas hacia o desde archivos de datos. Como se señaló anteriormente, los flujos de datos entre dos terminadores no se incluyen en DFD y, por lo tanto, los datos no pueden fluir directamente entre dos terminadores.

(iii) Proceso:

El proceso transforma los datos entrantes para la redirección al almacén de datos o al terminador. Está simbolizado por un rectángulo con esquinas redondeadas o un círculo. Está etiquetado con un verbo, por supuesto.

(iv) Almacén de datos:

Los archivos son los almacenes de datos en sistemas de información y se representan en DFD en forma de rectángulos abiertos. En general, corresponden a tablas en bases de datos. En la Fig. 8.7 se presenta una vista parcial del diagrama de flujo de datos para el procesamiento de pedidos de venta.

Cabe señalar que también se utilizan algunos símbolos complementarios y variaciones menores en los símbolos que representan diversos componentes de DFD. Los símbolos anteriores son los que se usan más comúnmente y están de acuerdo con la convención gráfica sugerida por Gane y Sarson.

Muchas veces, un gerente encuentra el dibujo de DFD una experiencia muy difícil y frustrante. Cada vez que uno dibuja un DFD, se descubre que ha ignorado uno u otro aspecto del flujo de datos. Afortunadamente, las herramientas CASE disponibles tienen facilidades para crear y modificar DFD. Sin embargo, se recomienda a los principiantes que sigan los siguientes pasos para superar este problema:

(a) Identifique todos los flujos de datos de entrada y los flujos de datos de salida por separado junto con los terminadores, colocando los flujos de datos de entrada en el lado izquierdo y el flujo de datos de salida a la derecha.

(b) Etiquete los terminadores usando nombres de flujo de datos o nombres de adjetivos.

(c) Identifique los procesos hacia adelante desde los flujos de datos de entrada y hacia atrás desde los flujos de datos de salida hasta que se encuentren en el medio.

(d) Etiquetar los procesos usando nombres verbales.

Un administrador debe estar preparado para volver a dibujar el DFD porque, muchas veces, los flujos de datos se vuelven claros para el administrador solo después de dibujar el DFD. La participación del usuario en esta etapa es muy útil no solo para reducir el esfuerzo por parte del administrador, sino también para mejorar el DFD.

Pruebas de DFD:

Se sugiere que el DFD se debe probar minuciosamente antes de que se finalice. Los siguientes son algunos de los errores comunes en el diseño de DFD:

a. La etiqueta de terminación puede ser el nombre de una persona o una empresa en lugar de una clase. Por ejemplo, un terminador se puede etiquetar como M / s. BR Ltd. en lugar de único vendedor. Otro error podría ser que el operador se ponga como terminador en lugar de la entidad externa directamente asociada con el flujo de datos.

segundo. Los datos pueden fluir directamente de un terminador a otro terminador.

do. Ningún flujo de datos puede ser indicado hacia o desde un proceso.

re. El flujo de datos se indica desde el terminador a un almacén de datos (archivo) o desde un archivo al terminador, o entre dos archivos sin procesamiento.

mi. Los procesos se etiquetan como objetos, como factura o un nombre como empleado de la reserva.

Después de que se dibujan los DFD para cada subsistema, los detalles del procesamiento futuro se pueden marcar y describir en inglés estructurado (códigos psedo). Estos códigos psedo se usan más tarde para codificar las aplicaciones. El rol del administrador en este proceso se limita solo a ayudar al profesional de sistemas de información a identificar y comprender los algoritmos involucrados en el procesamiento.

5. Módulo de implementación:

Este módulo se ocupa principalmente de las pruebas del sistema, la capacitación de los usuarios y la instalación del sistema.

Probando el sistema:

La prueba de varios módulos se realiza en varias etapas del proceso de desarrollo. La regla de oro que debe tenerse en cuenta durante las pruebas es que las pruebas deben realizarse con el fin de identificar las formas en que es probable que el sistema falle. No debe ser con el objetivo de demostrar que el sistema funcionará según la especificación de diseño. La prueba del sistema es el proceso de buscar respuestas a dos preguntas básicas:

1. ¿El sistema de información satisface las necesidades de información de la empresa? El proceso que busca responder a esta pregunta es denominado por los profesionales del sistema de información como proceso de validación del sistema.

2. ¿Funciona correctamente el sistema de información? El proceso de verificación busca respuesta a esta pregunta.

Como la naturaleza y el grado de gravedad de los errores son diferentes en las diferentes etapas del desarrollo del sistema, las diferentes pruebas se administran en diferentes módulos y en todo el sistema.

Prueba de unidad:

Las pruebas utilizadas a nivel de módulo pueden denominarse pruebas unitarias. Estas pruebas se realizan para detectar errores en interfaces, bases de datos, operaciones aritméticas y lógica de control. Se realizan ejecutando un módulo del sistema de información en datos de prueba especialmente diseñados para probar si el sistema:

a. Acepta el tipo incorrecto de datos (por ejemplo, acepta un valor numérico para el nombre);

segundo. Acepta datos fuera del rango válido (por ejemplo, acepta la fecha con un mes mayor a 12);

do. Causas incorrectas saltando de un procedimiento a otro procedimiento.

Prueba del sistema

Como las pruebas de unidad se realizan de forma aislada, es esencial que las pruebas de integración se realicen para verificar si estas unidades funcionan correctamente como grupo. Debido a la diversidad de la naturaleza de los errores, se deben seguir diferentes estrategias de prueba para verificar la validez y verificar el sistema. Fertucks sugiere tres estrategias para probar el sistema de información:

(a) Prueba de caja clara:

En esta estrategia, las pruebas están diseñadas para establecer si los procedimientos seguidos para el procesamiento coinciden con los requisitos de la aplicación. Esto se puede lograr con la ayuda de la revisión de colegas profesionales del sistema de información que no estaban asociados directamente en la etapa de desarrollo.

Alternativamente, se puede utilizar un método de recorrido estructurado. En este método, un grupo de personas revisa los procedimientos, primero analiza las partes propensas a errores e identifica las correcciones que deben realizarse. Luego, los miembros del grupo evalúan la salida que el sistema ofrecerá para un tipo dado de entrada y comprueban si la salida del sistema es correcta o no.

(b) Prueba de caja negra:

En esta estrategia, el sistema se prueba para datos no válidos o datos que pueden causar errores en el funcionamiento del sistema. La salida se verifica para establecer si se ha producido algún error. Por ejemplo, los datos pueden contener un valor negativo para la cantidad ordenada o un valor fraccionario para una variable que puede tomar solo un valor entero.

(c) Prueba de casilla de verificación:

Esta estrategia asume que nunca es posible entregar un sistema de información totalmente libre de errores. Por lo tanto, después de todas las pruebas y modificaciones, es necesario estimar el número de errores que aún quedan en el sistema. Para estimar este número, se pueden introducir deliberadamente algunos errores en el sistema. Luego se vuelven a realizar las pruebas para detectar errores.

La proporción de errores introducidos detectados se toma como una estimación de la proporción de errores reales detectados durante las pruebas anteriores. Por lo tanto, si el 90% de los errores introducidos se detectaron durante la prueba de la casilla de verificación mientras que se detectó un total de 450 errores originalmente durante la prueba de la casilla transparente y la prueba de la caja negra, significa que 50 errores reales siguen sin ser detectados en el sistema.

Instalación:

La instalación es un proceso de reemplazo del sistema anterior por un sistema nuevo. En general, hay cuatro enfoques para la instalación. La instalación 'en frío' se realiza cuando el sistema antiguo se interrumpe inmediatamente y se reemplaza por un nuevo sistema.

Tal instalación tiene la ventaja de un ajuste psicológico más rápido con el hecho de que el nuevo sistema se va a utilizar. Sin embargo, tal enfoque puede no ser adecuado si los datos antiguos del sistema anterior son valiosos o si el nuevo sistema tiene algunos problemas. Para instalar sistemas de información contable, este enfoque no se ha encontrado aceptable. Los enfoques alternativos incluyen:

(a) Instalación piloto:

Se puede instalar un sistema para que lo use solo un grupo selecto de usuarios que prueba el sistema al usarlo. Otros usuarios continúan usando el sistema antiguo. Cuando se resuelven los problemas en el sistema, otros usuarios también comienzan a usar el sistema. Este enfoque tampoco es muy popular para los sistemas de información contable porque toda la base de datos contable debe actualizarse antes de que pueda ser utilizada por los usuarios.

Los requisitos de información del usuario cruzan los límites del departamento y las divisiones en el organigrama. Sin embargo, este enfoque puede usarse para entidades contables completas, como sucursales, oficinas regionales, etc. Por lo tanto, las sucursales seleccionadas pueden utilizar un sistema de información contable. Una vez que se descubre que están libres de errores, también pueden ser utilizados por otras sucursales.

(b) Instalación en fase:

Bajo este enfoque, la instalación tiene lugar en etapas. Estas etapas son componentes independientes del sistema de información. Por lo tanto, el ciclo de vida de los ingresos de un sistema de información contable se puede instalar primero y otros ciclos de vida pueden seguir uno tras otro. Este enfoque ayuda a centrarse en una parte seleccionada del sistema. Ayuda a mejorar la aceptabilidad del sistema entre los usuarios, ya que permite al usuario hacer frente al cambio fácilmente.

(c) Instalación paralela:

La instalación paralela significa ejecutar el sistema antiguo y el nuevo simultáneamente durante un período determinado hasta que se demuestre la utilidad del nuevo sistema. Este método es el más popular para el sistema de información contable porque es el más seguro de todos los demás métodos. La única dificultad, aquí, es el costo de la ejecución paralela y la tendencia a extender el período de ejecución paralela de aquellos que se resisten al cambio.

Revisión posterior a la implementación:

Cada sistema debe ser revisado después de que se complete la implementación. Tal revisión no solo ayuda a identificar las debilidades del sistema, sino que también prepara una agenda para la modificación para el futuro. Es, de hecho, un proceso de aprendizaje. La auditoría del sistema también se puede realizar para examinar qué tan exitoso es el sistema, en términos de costo, programa de entrega, integridad y calidad.