Sistemas de Información Basados en Computadoras (CBIS) Para nuestro propósito, la definición de sistema nos será útil para estudiar la manera en que empresas u organizaciones, que constituyen sistemas, manejan la información necesaria para su funcionamiento.

AIS Accounting Information Systems Es un conjunto de elementos que interactúan para proporcionar información contable y financiera precisa y oportuna a la gestión interna para la toma de decisiones y para las partes externas tales como acreedores, inversores y autoridades reguladoras. Permite: Recopilar datos (transacciones). Manipular datos: clasificación, ordenación, cálculos, resúmenes. Almacenamiento de datos (base de datos). Preparación de documentos (informes).

AIS concepto de sistema Antes de ofrecer una definición del concepto de sistema de información, comenzaremos por definir los términos que lo constituyen: sistema e información. La palabra sistema se emplea actualmente en muchos ámbitos distintos: se habla de sistemas eléctricos, sistemas monetarios, sistemas de seguridad, el sistema solar e, incluso, de sistemas de juego en equipos de fútbol. La razón es que, al igual que le ocurre con otras palabras como conjunto, el término sistema se emplea para designar un concepto, una herramienta genérica que se puede emplear para explicar o analizar mejor cómo es o qué ocurre en una determinada área social, económica, física, etc. El diccionario de la Real Academia Española nos dice que sistema es un conjunto de cosas que ordenadamente relacionadas entre sí contribuyen a un determinado objetivo. A partir de esta definición, podemos identificar cuáles son los principales elementos presentes en cualquier sistema: Los componentes del sistema. Las relaciones entre ellos, que determinan la estructura del sistema. El objetivo del sistema. En cualquier tipo de sistema podemos identificar estos elementos. En el sistema circulatorio del ser humano podemos determinar sus órganos constitutivos (corazón, arterias, venas, etc.), las relaciones entre ellos (el corazón bombea sangre hacia las arterias que están dispuestas según una determinada estructura, etc.) y el objetivo (asegurar el suministro de sangre a todo el cuerpo). En todos los sistemas también podemos identificar otros elementos importantes para comprender cómo son y cómo funcionan: El entorno del sistema: aquello que lo rodea, dentro del cual está ubicado. Los límites del sistema: la frontera entre lo que es el sistema y lo que constituye el entorno. En el caso del sistema circulatorio de los humanos, el entorno donde se localiza es el cuerpo, y la frontera la constituye la membrana o el límite de cada uno de sus órganos con el resto del cuerpo que no pertenece al sistema. También suelen existir relaciones entre el sistema o sus componentes y el exterior representado por el entorno (el sistema nervioso envía órdenes al corazón o para modificar sus latidos). Estas relaciones con el exterior suelen conocerse como entradas y salidas del sistema. Para nuestro propósito, la definición de sistema nos será útil para estudiar la manera en la que las empresas u organizaciones, que constituyen sistemas, manejan la información necesaria para su funcionamiento. Para este estudio nos basamos no sólo en la definición de sistema, sino en todas las técnicas creadas para el análisis de los sistemas siguiendo el enfoque sistémico o teoría general de sistemas.

Mitos del Software Propagaron confusión e información errónea. Del administrador del proyecto Mitos del SW Del usuario final o cliente Del desarrollador A diferencia de los mitos antiguos que a menudo proporcionaban a los hombres lecciones dignas de tener en cuenta, los mitos del SW propagaron información errónea y confusión. De hecho, muchas de las causas de la crisis del software pueden encontrarse en esta mitología surgida en los primeros años del desarrollo de software. Existen tres tipos de mitos de acuerdo a quién sea la persona que se aferre a la creencia. Tenemos los mitos del administrador o gestor del proyecto, los del cliente y los del desarrollador de software

Figura 3 – El impacto del cambio Mitos del Software “Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido” (MA) “Los requisitos cambian continuamente, pero los cambios pueden acomodarse fácilmente porque el SW es flexible” (MC) “Lo único que se entrega al terminar el proyecto es el programa funcionando” (MD). En la transparencia vemos un ejemplo de cada uno de ellos. El primer mito, también conocido como el concepto de la horda mongoliana, en realidad no hace más que producir más demora ya que cuando se añaden nuevas personas, surge la necesidad de aprender y comunicarse con los miembros del equipo de desarrollo más antiguos haciendo que se reduzca el tiempo productivo. Puede agregarse gente, pero sólo de una manera planificada. El segundo mito corresponde a un ejemplo de un mito del Cliente. Si bien es cierto que los requisitos cambian continuamente, el impacto varía de acuerdo al momento en que los cambios son introducidos. La figura 3 ilustra el impacto de los cambios de acuerdo al momento. Finalmente, el tercer ejemplo de mito corresponde a un mito del desarrollador de software. Si bien es cierto que entregar el programa funcionando es lo más importante, no es lo único. La documentación, que sirvió durante la etapa de desarrollo, es fundamental para el futuro mantenimiento del software. Muchos otros ejemplos de mitos pueden encontrarse en el capítulo I del libro de Pressman. Definición Desarrollo Después de la Entrega Figura 3 – El impacto del cambio C o s t e 1x 1,5 – 6x 60 – 100x

Ciclo de Vida del Software Descripción Planificación Análisis de requerimientos. Definición (qué) Diseño Generación de Código Prueba Desarrollo (Cómo) Veamos ahora cuales son las características genéricas del proceso de desarrollo de software, es decir aquellas características que se encontrarán presentes en cualquiera sea el proceso de desarrollo particular que adoptemos. Más adelante veremos en detalle distintos modelos específicos de procesos de desarrollo. La fase de Definición se ocupa del qué. Es decir, durante la Definición se intenta identificar qué información debe ser procesada, qué funcionalidad se desea, qué interfaces van a ser usadas, qué restricciones de diseño existen. Por lo tanto, se deberán identificar los requerimientos tanto de hardware como de software. Básicamente, durante la fase de Definición tendrán lugar tres actividades: la Ingeniería del Sistema, la captura y análisis de los requerimientos y la planificación del proyecto de software. La fase de Desarrollo se ocupa del cómo. Es decir, acá se debe definir cómo serán las estructuras de datos, cómo será la arquitectura del software, cómo se implementarán los detalles procedimentales, cómo serán las interfaces, cómo traducimos el diseño en código, cómo llevamos a cabo la prueba. Básicamente, tres tareas deberán ocurrir en esta fase: el diseño del software, la generación de código y la prueba del software. La fase de Mantenimiento o Soporte se ocupa de los cambios en el software. En esta fase se podrán llevar a cabo cuatro tipos de mantenimientos diferentes dependiendo del tipo de cambio: Mantenimiento Correctivo: cambiar el software para corregir errores. Mantenimiento Adaptativo: cambiar el software para adaptarlo a su entorno, por ejemplo cambios en la CPU, en el sistema operativo, en las políticas de la empresa, en las características externas del producto, etc.). Mantenimiento Perfectivo: cambiar el software para mejorarlo y obtener nuevos beneficios. Mantenimiento Preventivo: debido al deterioro producido en el software por los sucesivos cambios, se suele llevar a cabo un procesos de Reingeniería para producir un nuevo software con la misma funcionalidad pero de mejor calidad. Mantenimiento Correctivo Mantenimiento Adaptativo Mantenimiento Perfectivo Mantenimiento Preventivo o Reingeniería del Software Soporte (Cambios)

Ingeniería de Producto El producto completo Análisis de sistema (Vista Panorámica) características Ingeniería de hardware software componentes (Vista de Dominio) Requerimiento de procesamiento Modelo datos funciones comportamiento Análisis y Diseño (Vista de Elemento) componentes de programa Ingeniería Software Construcción e Integración (vista detallada)

Notación del Modelo de Flujo entidad externa proceso flujo de datos almacenamiento de datos

Entidad Externa Un productor o consumidor de información Ejemplos: una persona, un dispositivo, un sensor Otro ejemplo: un sistema basado en computadora Los datos deben siempre originarse en algún lado y deben siempre enviarse a otro

Flujo de Datos Los flujos de datos a través de un sistema, comienzan con una entrada y deben ser transformados a una salida. base calcular el área de un triángulo área altura

Almacenamiento de Datos Los datos son frecuentemente almacenados para un uso posterior #sensor #sensor, tipo, ubicación, intervalo revisión de los datos del sensor reporte requerido tipo, ubicación, intervalo #sensor datos del sensor

Diagramación del Flujo de Datos: todos los íconos deben ser etiquetados con nombres significativos el DFD evoluciona a través del número de niveles de detalle siembre comienzan con un diagrama de contexto (siempre llamado “nivel 0”) muestran las entidades externas a nivel 0 los flujos de datos simpre están etiquetados no se representa la lógica procedural

Proceso Un transformador de datos (cambia una entrada por una salida) Ejemplos: impuestos calculados, calcular áreas, formatear un reporte, desplegar un gráfico. Los datos deben siempre ser procesados de alguna manera para llevar a cabo una función.

Construcción de un DFD revisar un ERD para aislar los objetos de datos y revisar gramaticalmente para determinar “operaciones” determinar las entidades externas (productores y consumidores de datos) crear el nivel 0 del DFD

Modelo de Flujo Cada sistema basado en computadora es una transformación de información sistema basado computadora entrada salida

Ejemplo de un Nivel 0 del DFD requerimiento de procesam. usuario señal de video requerida procesador de video digital monitor fuente de video Señal de video NTSC

Jerarquía del Flujo de Datos b x P y nivel 0 c p2 a f p1 b p4 d 5 g p3 e nivel 1

DFD: Un vistazo modelo de análisis Se mapea en modelo de diseño