Sistemas de Informacion

dar una opinion concreta con respecto a la asignatura sera muy precipitado en estos momentos en los cuales estamos apenas viendo las primeras clases. pero basandonos en los diferentes conceptos referidos a lo que es un sistema de informacion, se puede tener una vision global de lo que puede llegar a ser dicha materia.


La asignatura pretende proporcionar al estudiante los conceptos básicos que le permitan consolidar unos conocimientos sobre los fundamentos más importantes de los sistemas de información en cualquier organización. Se establece una especial incidencia en la comprensión de los conceptos de los sistemas de información más necesarios en la formación de un gestor de información. En consecuencia, no se tratan en profundidad los temas sino que se pretende dar una visión clara y completa sobre los conceptos principales.

Relación con el resto del plan de estudios
"Sistemas de información I" está fuertemente relacionada con otras asignaturas troncales del plan de estudios de ingenieria de sistemas, como "Sistemas de operacion", "Sistemas de control" o "implementacion de bases de datos" que recogen conceptos presentados en esta asignatura. A su vez tiene una relación con la asignatura de ingenieria de software I y II, "planificacion y control de proyectos", de carácter más técnico. esta ultima se involucra directamente con los sistemas de informacion ya que todo sistema de informacion conocido en la actualidad comemzo como un proyecto, aplicando los diferentes pasos necesarios para el desarrollo del mismo termina en lo que se trata de enseñar en la materia inicialmente analizada.


OBJETIVOS

1. Definir el concepto de sistema de información


2. Conocer las funciones de los sistemas de información en las organizaciones


3. Conocer los diversos tipos de sistemas de información según la funcionalidad de la organización


4. Advertir la importancia del usuario en el éxito de un sistema de información

Etapas del diseño de software

Cada organización es única, tiene su propia combinación exclusiva de hombres, recursos económicos, máquinas, materiales y métodos. No solamente son diferentes los componentes individuales de la organización, sino también el grado de evolución de su sistema de información para la administración. Esta singularidad hace necesario que cada organización desarrolle sus propias especificaciones de su sistema de información para la administración, mediante una evaluación sistemática de su propio ambiente externo e interno y de su punto de vista, de acuerdo con sus propias necesidades únicas.

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:

Análisis de requerimientos

Extraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requerimientos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de requerimientos, por ejemplo en dos capítulos del libro de Sommerville "Ingeniería del Software" titulados "Requerimientos del software" y "Procesos de la Ingeniería de Requerimientos".

La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de Requerimientos de Software (Software Requirements Specification).

Especificación

La Especificación de Requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

Los Casos de Uso y las Historias de usuario, Siendo los primeros más rigurosas y formales, los segundas más ágiles e informales.

Arquitectura

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La Arquitectura de Sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases
Diagramas de base de datos
Diagramas de despliegue plegados
Diagramas de secuencia multidireccional

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar. Entre las herramientas para diseñar arquitecturas de software se encuentran:

Enterprise Architect
Microsoft Visio for Enterprise Architects

Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.

Diseño conceptual Fisico y Logico en la Ingenieria de Software

El diseño conceptual se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas:

Identificar los usuarios y sus roles
Obtener datos de los usuarios
Evaluar la información
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa

Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quién, qué, cuándo, dónde y por qué de la solución.



Diseño Lógico

El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios.

Un objeto de negocios es la encapsulación de un servicio que abstrae las cualidades esenciales de algo de interés.

Un servicio es una unidad con capacidad de cómputo. Un servicio debe satisfacer lo siguiente:

Ser seguro, lo que equivale a un uso correcto y con autorización
Ser válido, qué tareas o reglas se pueden aplicar
Manejar excepciones, informando al cliente
Contar con un catálogo de servicios que constituye un repositorio de servicios.

Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los módulos operen como unidades completas de trabajo. Las tareas de verificación incluyen:

Una verificación independiente:

Pre y post condiciones
Lógica y funcionalidad individual

Una verificación dependiente:

Verificación de dependencias Que operan como una unidad específica de trabajo

El diseño lógico comprende las siguientes tareas:

Identificar y definir los objetos de negocio y sus servicios
Definir las interfases
Identificar las dependencias entre objetos
Validar contra los escenarios de uso
Comparar con la arquitectura de la empresa
Revisar y refinar tanto como sea necesario

Para definir los objetos de negocios y sus servicios se puede usar la técnica de análisis nombre-verbo de los escenarios de uso. También se puede emplear la técnica sujeto-verbo-objeto directo. En estas técnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios.

Una interfase tiene las siguientes partes:

Nombre
Precondiciones, lo que debe estar presente antes de ejecutarse
Postcondiciones, estado final
Capacidad o funcionalidad (SQL, pseudocódigo, función matemática)
Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realización de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente:

Identificar los eventos disparadores (triggers)
Determinar cualquier dependencia (existencial o funcional)
Determinar cualquier problema de consistencia o secuencia
Identificar cualquier regulación de tiempo crítica
Considerar algún problema organizacional (transacciones)
Identificar y auditar los requerimientos de control
Determinar lugares y dependencias a través de la ubicación
Determinar cuando el servicio que controla la transacción es dependiente de los servicios contenidos en otros objetos de negocio

La validación del modelo lógico debe ser tal que éste sea:

Completo – debe representar todos los escenarios de uso,
Correcto – el comportamiento lógico debe corresponder con el comportamiento conceptual, y
Claro – los objetos de negocio y servicios no deben ser ambiguos

En el diseño lógico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología cambiando únicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos.

Los servicios de usuario (user services) controlan la interacción. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinación de éstos. Generalmente involucra una interfase gráfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interacción con la aplicación. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. Un servicio de usuario incluye un contenido (qué se necesita comunicar al usuario) y una forma (cómo se comunica el contenido) cuando es necesaria la comunicación.

Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en información (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea.

Las tareas de los servicios de negocio son:

Dar formato a los datos
Obtener y mover datos desde y hasta los servicios de datos
Transformar los datos en información
Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transacción.

Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categorías como las siguientes:

Declaración del esquema y su evolución (estructuras de datos, tipos, acceso indexado, SQL, APIs)
Respaldo y recuperación (recuperación de datos si un evento falla)
Búsqueda y Lectura (búsquedas, compilación, optimización y ejecución de solicitudes, formación de un conjunto de resultados)
Inserción, actualización y borrado (procesar modificaciones consistentemente transaccional). Una transacción es atómica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o después) y durable (una vez completada, ésta sobrevive).
Bloqueo (permite al acceso concurrente a los datos)
Validación de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores)
Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios)
Administración de la conexión (mecanismos básicos para establecer una sesión de los servicios de datos). Establecer una conexión involucra: una identificación, la colocación y provisión de datos, tiempo de sesión, el tipo de interacción (conversacional, transaccional, multiusuario, monousuario).
Distribución de datos (Distribuye información, a múltiples unidades de recuperación, bases de datos heterogéneas, según la topologías de la red).


Diseño físico

El diseño físico traduce el diseño lógico en una solución implementable y costo-efectiva o económica.

El componente es la unidad de construcción elemental del diseño físico. Las características de un componente son:

Se define según cómo interactúa con otros
Encapsula sus funciones y sus datos
Es reusable a través de las aplicaciones
Puede verse como una caja negra
Puede contener otros componentes

En el diseño físico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico) y la agregación y contención (un componente puede reusar utilizando técnicas de agregación y contención, sin duplicar código).

El diseño físico debe involucrar:

El diseño para distribución – debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red.
El diseño para multitarea – debe diseñarse en términos de la administración concurrente de dos o más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso)
El diseño para uso concurrente – el desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud.
El diseño con el manejo de errores y prueba de eventos:
Validando los parámetros- a la entrada antes de continuar con cualquier proceso.
Protegiendo recursos críticos –manejar excepciones para evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria.
Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las bases de datos.
Debugging – crear una versión para limpiar errores.
Protección integral de transacciones de negocios – los errores deben regresarse al componente que llama.







El diseño físico comprende las siguientes tareas:

Definir los componentes
Refinar el empaquetamiento y distribución de componentes
Especificar las interfases de los componentes
Distribuir los componentes en la red
Distribuir los repositorios físicos de datos
Examinar la tolerancia a fallas y la recuperación de errores
Validar el diseño físico

De las tareas anteriores la más importante es la distribución de los datos que pueden ser centralizados, una partición, un extracto o una réplica.

Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos.

Una partición de datos es una segmentación de la base de datos maestra. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposición entre particiones. En una partición horizontal cada hilera existe en una sola base de datos. En una partición vertical cada columna es contenida en una y solo una base de datos.

Un extracto de datos es una copia de toda o una porción de la base de datos maestra. No se permite la actualización. Se usa un timestamp o etiqueta de tiempo para indicar qué tan viejos son los datos.

Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local. No se permiten actualizaciones en la base de datos réplica y en la base de datos maestra a la vez, por lo que debe de haber sincronización entre ambas.

El diseño físico está íntimamente ligado a una alternativa tecnológica. Ante la acelerada evolución tecnológica es importante considerar los estándares del momento y las tendencias ya que una mala decisión implicará un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta.

La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicándose entre sí en una plataforma internet con protocolos estándar en redes heterogéneas.

Ingenieria de Software

Desde mi punto de vista esta es una materia sumamente teorica, donde recordamos los principios de la programacion y las herramientas de apoyo para el desarrollo de software alguno, desde pseudocodigo, pasando por diagramas de flujo de datos hasta llegar a los diferentes lenguajes de programacion.

Al ser ingenieria, uno como estudiante debe ingeniarselas para lograr un fin en especifico, en el caso especifico de la ingenieria de software, es ingieniarnos una solucion a un problema dado, apoyandonos en los conocimientos y nociones que nos da esta materia en la parte suave (soft) del sistema (ware).

Basada en la logica, esta materia proporciona conocimientos fundamentales para todo buen profesional de sistemas, ya sea que este se especialize en programacion o en la tecnologia de la informacion

un poco sobre mi

Nace en agosto 18 de 1980 este humilde servidor, graduado de bachiller en la unidad educativa los chaguaramos inicia sus estudios fallidos de tsu en informatica en el año 2000 y los culmina luego de un semestre, lamentablemente la pasion por el dinero pudo mas que la de los estudios.

Este ilustre caraqueño aunque nacido en baruta, estado Miranda donde actualmente reside, continua su intento por seguir creciendo en el campo de la informatica, es alli donde despues de salir de su primer trabajo en las tiendas graffitti, consigue trabajo en una empresa de publicidad bajo el cargo de analista de soporte tecnico. donde tiene la gran responsabilidad de manejar 200 estaciones de trabajo a nivel nacional en 9 sucursales en total. viendo que esto era mucho trabajo para lo poco que gana, decide retirarse y consigue trabajo en Epson Venezuela donde alli comienzan sus certificaciones a nivel de Microsoft, alli hace los cursos certificados MOC: 2276, 2277, 2400, 2824.

Teniendo dentro de si ansias de superacion profesional, este manganzon comienza estudios de ingenieria en telecomunicaciones en la UNEFA, donde lamentablemente sale por razones politicas. Sencillamente el codigo de etica de la UNEFA fue violentado al meter el color rojo en esa casa de estudios. Pero con las ganas de seguir superandose consigue entrar en la universidad Santa Marian bajo la carrera de Ingenieria de Sistemas donde actualmente va en el septimo semestre.

Siendo una persona con sentido de responsabilidad social, este servidor comienza entrenamientos en primeros auxilios, busqueda y rescate en espacios confinados, es decir, jugando a ser paramedico dando resultados positivos hasta los momentos, todo esto gracias a este ser miembro de la brigada de emergencia de Tolon Fashion Mall donde actualmente presta sus servicios de Analista de Sistemas logrando asi tambien la anhelada estabilidad laboral pero siempre teniendo aspiraciones mas alla de donde esta.

Bienvenidos pues a este humilde blog destinado a una tarea de Ingenieria de software, quien sabe si mas adelante lo deje fijo...