sábado, 1 de diciembre de 2012

RMM (Metodología de Administración de Relaciones).


La RMM o Relationship Management Methodology se define como un proceso de análisis, diseño y desarrollo de aplicaciones hipermedia. Los elementos principales de este método son el modelo E-R (Entidad-Relación) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. La metodología fue creada por Isakowitz, Stohr y Balasubramanian. Esta metodología es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por ejemplo, catálogos o "frentes" de bases de datos tradicionales. Según sus autores, está orientada a problemas con datos dinámicos que cambian con mucha frecuencia, más que a entornos estáticos.

El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los mecanismos de navegación hipermedia de la aplicación. Los objetos del dominio se definen con la ayuda de entidades, atributos y relaciones asociativas. El modelo introduce el concepto de slice (trozo) con el fin de modelizar los aspectos unidos a la presentación de las entidades. Un slice corresponde a un subconjunto de atributos de una misma entidad destinados a ser presentados de forma agrupada. La navegación se modeliza con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y bidireccional) que permiten especificar la navegación entre slices, y visita guiada condicional, índice condicional y agrupación, que permiten especificar la navegación entre entidades. El esquema completo del dominio y de la navegación de la aplicación se denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del método. Las etapas son:

 Primera etapa: representar los objetos del dominio con la ayuda del modelo Entidad-Relación ampliado con relaciones asociativas (aquéllas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de análisis).

 Segunda etapa: determinar la presentación del contenido de las entidades de la aplicación así como su modo de acceso. El esquema obtenido como resultado de esta etapa se denomina esquema E.R+. Se trata de un esquema Entidad-Relación en el que cada entidad ha sido reemplazada por su esquema de entidad. Un esquema de entidad está constituido por nodos (los trozos o slides) unidos por relaciones estructurales.

 Tercera etapa: definir los caminos de navegación inducidos por las relaciones asociativas del esquema E-R+. A continuación, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicación de accesos jerárquicos a niveles diferentes de los trozos de información. El esquema RMDM resultante se obtiene añadiendo al esquema E-R+ las agrupaciones y caminos navegacionales definidos en esta etapa.

Las cuatro etapas restantes consisten en:

 Definición del protocolo de conversión de elementos del diagrama RMDM en objetos de la plataforma de desarrollo.

 Concepción del interfaz usuario.

 Concepción del comportamiento en ejecución.

 Construcción del sistema y test.

Muestra de un diagrama entidad-relación (las entidades se representan con un recuadro y las relaciones mediante un símbolo en forma de tridente).


Veamos con más detalle algunos ejemplos del modelo de datos RMDM (Relationship Management Data Model), que se genera a partir de un diagrama entidad-relación. Con él se describirá no sólo la información referente a las clases de objetos, sino también a la navegación entre ellos. Así, hay definidas unas primitivas para modelar los dominios o datos (clases de objetos) y otras para el acceso a tales objetos. De entre las primeras, la más típica es la entidad (se representa mediante un recuadro y su nombre). Como en la teoría relacional una entidad está compuesta por varios atributos. Además, en RMDM se incorpora una nueva primitiva denominada "slice", que define conjuntos de atributos de una entidad que se agrupan de forma lógica.

Estos diagramas especifican la navegación en el sistema:

 

De acuerdo con HDM, RMM define correspondencias tipo. Propone el modelo Entidad-Relación para especificar el dominio y lo enriquece introduciendo los conceptos de slice ( trozo) y de relación estructural para los cuales se preestablece una metáfora hipermedia. Los slices y las entidades se asocian con nodos y las relaciones asociativas (entre entidades) y las relaciones estructurales (entre trozos) se asocian con enlaces.

El modelo del dominio se enriquece, por lo tanto, con dos tipos de elementos preestablecidos que tienen una correspondencia clara en términos hipermedia.

En RMM, el modelo hipermedia retoma los elementos enlace, índice y visitas guiadas de HDM enriqueciéndolos con capacidades condicionales. Sin embargo, el método no permite al diseñador definir elementos hipermedia propios que tengan capacidades específicas ya que impone la utilización de metáforas preestablecidas.

Ante las limitaciones que ofrecía RMM, sus autores Balasubramanian, Bieber e Isakowitz, analizaron la estructura de navegación en RMM y propusieron añadir 2 nuevos tipos de slices: los slices híbridos (que permiten combinar atributos de diferentes entidades y estructuras de acceso), los slices mínimos (la mínima parte de una entidad que es necesaria para identificar uno de sus elementos y que se utilizará como ancla) y los m-slices (que permiten combinar primitivas de acceso con otros slices de otras entidades para crear un m-slice).  Se propone crear la estructura de la navegación no en base a las entidades sino a los slices, es decir a conjuntos de atributos.

A partir de las carencias de RMM e incorporando la novedad de los slices mínimos e híbridos, Lopistéguy, Losada y Dagorret analizan el modelo RMM y encuentran algunas carencias, por lo que proponen la creación de unas nuevas estructuras de navegación que doten de una mayor flexibilidad al modelo RMM, a la vez que crean unas serie de primitivas de acceso nuevas.

Estas son las estructuras que introducen:

 Navegación jerárquica: al tener varias relaciones 1:N encadenadas, se permite navegar desde cualquier entidad a otra que esté por debajo de ella en la jerarquía. Estos enlaces inferidos, no extraídos directamente de una relación 1:N, se representarán con trazo discontinuo.

 Navegación en relaciones N:M: se permite navegar de un extremo al otro de la relación, pero teniendo en cuenta la entidad intermedia, cuyos atributos deberán incluirse en un slice híbrido. Para representar un enlace de este tipo, uniremos la primitiva de acceso (índice, visita guiada, ...) con la entidad intermedia.

 Navegación múltiple: se crean unas nuevas primitivas que permiten el acceso múltiple de una entidad a otra, seleccionando un elemento de una tercera entidad de la que la entidad destino es parte. En el enlace quedará especificado qué entidad es la origen, cuál la destino y cuál la tercera. Recordar que esta navegación es especialmente apropiada en estructuras todo-parte.

 Acceso aleatorio: permite acceder a un elemento de forma aleatoria, sin saber exactamente a cuál.

 Acceso simultáneo: permite representar el acceso a todos los elementos de una entidad a la vez. Por ejemplo, si estamos en un Seminario, con esta primitiva accedemos a todos sus ponentes simultáneamente, todos a la vez, y no mediante un índice o uno tras otro en una visita guiada

Y así quedará la lista de primitivas con la inclusión de las nuevas primitivas de acceso:



La metodología RMM permite hacer explícita la navegación al hacer el análisis, lo que permite, teóricamente, obtener una navegación más estructurada e intuitiva, y lo hace de una forma muy sencilla, como es  añadir unas primitivas a un modelo entidad-relación tradicional. El concepto de slice es muy útil, ya que permite agrupar datos de una entidad en diferentes pantallas. Se utilizaría, por ejemplo, para mostrar dos vídeos en dos pantallas diferentes sobre un mismo fenómeno. También es interesante la primitiva de grupo, que permite mostrar la jerarquía de menús.

RMM representa el primer caso en el que se crea una metodología completa definiendo las distintas fases y no únicamente un modelo de datos. Además,  se basa en un modelo de datos relacional, ajustándose así a la gran mayoría de las aplicaciones existentes. Sin embargo, los mecanismos de acceso a la información son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran número de ellas.

Diagrama Entidad-Relación

Jerarquía de menús con detalle

Metodología del software educativo por Álvaro Galvis.

Metodología del software educativo por Álvaro Galvis (ISE) 

Es una metodología de desarrollo de software que contempla una serie de fases o etapas de un proceso sistemático atendiendo a: análisis, diseño, desarrollo, prueba y ajuste, y por último implementación. 

Etapas:


Etapa 1: Análisis
Características de la población objetivo: edad (física y mental), sexo, características físicas y mentales (si son relevantes), experiencias previas, expectativas, actitudes, aptitudes, intereses o motivadores por aprender. 
Conducta de entrada y campo vital: nivel escolar, desarrollo mental, físico o psicológico, entorno familiar y escolar, etc. 

Problema o necesidad a atender: Para establecer la necesidad se puede recurrir a los mecanismos de análisis de necesidades educativas en. Estos mecanismos usan entrevistas, análisis de resultados académicos, etc. para detectar los problemas o posibles necesidades que deben ser atendidas. El problema o necesidad no tiene que estar necesariamente relacionado con el sistema educativo formal, pueden ser necesidades sentidas, económicas, sociales, normativas, etc. 

Principios pedagógicos y didácticos aplicables: se debe analizar cómo se ha llevado a cabo el proceso de enseñanza-aprendizaje para establecer cómo debe enfocarse el ambiente, qué factores tomar en cuenta, qué objetivos debe cumplir. 

Justificación de uso de los medios interactivos: Para cada problema o necesidad encontrada se debe establecer una estrategia de solución contemplando diferentes posibilidades. El apoyo informático debe ser tomado en cuenta siempre y cuando no exista un mecanismo mejor para resolver el problema: soluciones administrativas, ver si el problema se soluciona al tomar decisiones de tipo administrativo; soluciones académicas, cambios en metodologías de clase; mejoras a los medios y materiales de enseñanza contemplando el uso de medios informáticos. Una vez que se han analizado todas las alternativas se puede decir por qué el uso de medios informáticos es una buena solución. La justificación se puede basar en la no existencia de otro medio mejor y en la relación costo-beneficio para la institución pues puede ser que exista una mejor solución pero que demande mayor tiempo y esfuerzo o un mayor costo económico, etc. 

Diagramas de interacción: Permiten ver secuencias de interacción entre el usuario y la aplicación, representando lo que se espera del diálogo y dando más detalle a la descripción textual de la descripción de la aplicación. Los diagramas de interacción son un formalismo que permite ver la secuencia de acciones entre diferentes partes de la aplicación involucrada en llevar a cabo determinada actividad. Es importante ver la secuencia de acciones para cada escenario de interacción. Con base en estos diagramas se pueden ver cuáles pueden ser las necesidades de información en cada escenario de interacción y se puede ir pensando en cuáles pueden ser los algoritmos que serán usados. 


Etapa 2: Diseño 
Educativo (este debe resolver las interrogantes que se refieren al alcance, contenido y tratamiento que debe ser capaz de apoyar el Sistema Educativo). 

Comunicacional (es donde se maneja la interacción entre usuario y máquina, se denomina interfaz). 

Computacional (con base a las necesidades se establece qué funciones es deseable que cumpla el Sistemas Educativo en apoyo de sus usuarios, el docente y los estudiantes). 


Etapa 3: Desarrollo 
En esta fase se implementa la aplicación usando la información obtenida anteriormente. Tomando en cuenta las restricciones que se tengan. 


Etapa 4: Prueba Piloto 
En esta etapa se pretende ayudar a la depuración del Sistema Educativo a partir de su utilización por una muestra representativa de los tipos de destinatarios para los que se hizo y la consiguiente evaluación formativa. Es imprescindible realizar ciertas validaciones (efectuadas por expertos) de los prototipos durante las etapas de diseño y prueba en uno a uno de los módulos desarrollados, a medida que estos están funcionales. 


Etapa 5: Prueba de Campo La prueba de campo de un Sistema Educativo es mucho más que usarlo con toda la población objeto.
Si se exige, pero no se limita a esto. Es importante que dentro del ciclo de desarrollo hay que buscar la oportunidad de comprobar, en la vida real, que aquello que a nivel experimental parecía tener sentido, lo sigue teniendo, es decir, si efectivamente la aplicación satisface las necesidades y cumple la funcionalidad requerida.

Metodología de James Martin y UML.


Metodología de James Martin
Esta metodología de desarrollo de Software es mejor conocida como Metodología RAD (Rapid Application Development) o Desarrollo rápido de Aplicaciones,   y fue creada por el gurú de computación James Martin en 1991. Está orientada a disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas de Información, el RAD cuenta con una participación intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código. El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas.

Fases o Etapas de Metodología RAD de James Martin.

Esta metodología consta de 4 etapas a saber:

  1) Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compañía determinen cuáles serán las funciones del sistema. Debe darse una discusión estructurada sobre los problemas de la compañía que necesitan solución.

  2) Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data.

  3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.

  4) Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.



Ventajas y Desventajas de la Metodología RAD

Ventajas             |             Desventajas

Ahorro dramático de tiempo durante el desarrollo del sistema.            Mayor velocidad y menores costos pueden repercutir en la calidad del sistema (p.e., debido a falta de atención en controles internos).
Puede ahorrarse tiempo, dinero y esfuerzo humano. Peligrosa incoherencia entre el sistema desarrollado y el negocio, debido a la falta de información o a procesos del negocio sobreentendidos.
Estrecha correspondencia entre los requerimientos del usuario y las especificaciones del sistema.
Pueden producirse inconsistencias entre diseños internos y entre sistemas.
Trabaja muy bien cuando la velocidad de desarrollo es importante (cambios rápidos de las condiciones del negocio), o cuando lo sistemas pueden capitalizarse en oportunidades estratégicas. Posibles violaciones de estándares de programación relacionadas con nomenclaturas inconsistentes e insuficiente documentación.
Permite cambiar rápidamente el diseño de los sistemas cuando los usuarios lo demandan Dificultades con el reuso de módulos para futuros sistemas.
Los sistemas son optimizados por los usuarios involucrados en el proceso del RAD. Carencia de un diseño escalable dentro del sistema.
Se concentra en los elementos esenciales del sistema, desde el punto de vista del usuario. Falta de atención de la futura administración del sistema dentro de los sistemas existentes (p.e., falta de integración con el modelo de datos organizacional y facilidades de recuperación del sistema)        . El usuario se compromete y se hace propietario del sistema. Altos costos de compromiso por parte del personal clave.


UML

Concepto:
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

Fases en el desarrollo basado en UML

En la versión definitiva de la metodología publicada por Booch, Rumbaugh y Jacobson se pueden tener en cuenta las siguientes fases o etapas:

· Análisis de Requerimientos
· Diseño del sistema
· Diseño detallado
· Implementación y pruebas
Cada etapa consta de actividades que le dan cuerpo y los documentos que se esperan al final de cada una de ellas.

Cuadro Estructural UMl
El lenguaje UML se expresa con símbolos y/o agrupaciones de estos llamadas diagramas. Nos sirve fundamentalmente para crear diferentes tipos de ellos permitiéndonos ver desde diferentes perspectivas un sistema software.

 
Existe un tipo primordial que es “Diagrama UML” del cual heredan “Diagrama Estructural” y “Diagrama Comportamiento”, de estos a su vez heredan los trece diferentes tipos de diagramas más comunes, existiendo un tipo intermedio que serían los “Diagrama de Interacción”.

Diagramas Utilizados en UML:

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
  * Diagrama de clases
  * Diagrama de componentes
  * Diagrama de objetos
  * Diagrama de estructura compuesta (UML 2.0)
  * Diagrama de despliegue
  * Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
  * Diagrama de actividades
  * Diagrama de casos de uso
  * Diagrama de estados
Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
  * Diagrama de secuencia
  * Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración (UML 1.x)
  * Diagrama de tiempos (UML 2.0)
  * Diagrama global de interacciones o Diagrama de vista de interacción (UML 2.0)

Clases y Objetos.
Un objeto es una representación de una entidad, ya sea real o conceptual, con límites bien definidos y con significado dentro de un modelo. Cada objeto en un modelo se caracteriza por su estado, su comportamiento y su identidad.
El estado de un objeto es una de las posibles condiciones bajo las que el objeto puede existir. El estado de un objeto cambia con el tiempo y está definido por un conjunto de propiedades (atributos), por los valores de esas propiedades y por las relaciones que dicho objeto puede tener con otros objetos.

El comportamiento de un objeto determina la forma en que responde ante peticiones de otros objetos, y tipifica todo lo que el objeto puede hacer. El comportamiento de un objeto se materializa en el conjunto de operaciones definidas para dicho objeto.

La identidad implica que cada objeto es único, incluso si su estado es idéntico al de otro objeto.
En UML una clase es una descripción de un grupo de objetos con propiedades comunes (atributos), comportamiento común (operaciones), relaciones comunes y semántica común. Por tanto, una clase es una plantilla (template) para la creación de objetos, donde cada objeto de dicha clase será una instancia de ella (no pudiendo ser instancia de más de una clase).

Antes de describir los distintos elementos que forman parte de un diagrama de clases, es importante aclarar la forma en que dichos diagramas pueden ser utilizados durante el proceso software. A la hora de confeccionar o interpretar un diagrama de clases pueden considerarse tres perspectivas:

Conceptual: Permite representar los conceptos del dominio. Aunque dichos conceptos suelen llevar, de una forma natural, a las clases que los implementan, puede que no exista una correspondencia directa.

Especificación: Cuando se trata de representar las interfaces del software y no el software en sí.

Implementación: Es en esta perspectiva donde realmente tenemos clases, siendo ésta la perspectiva más utilizada.

Un diagrama de clases UML puede ser utilizado desde cualquiera de estas perspectivas, resulta en este caso conveniente el indicar la perspectiva de la que se trata por medio de estereotipos.

Diagrama de clases.

Los diagramas de clases son diagramas de estructura estática que muestran las clases del sistema y sus interrelaciones (incluyendo herencia, agregación, asociación, etc). Los diagramas de clase son el pilar básico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido. El diagrama de clases de más alto nivel (main class diagram), será lógicamente un dibujo de los paquetes que componen el sistema. A su vez cada paquete tendrá un main class diagram que muestra las clases del paquete Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de su propósito, su cardinalidad (cuantos objetos intervienen en la relación) y su opcionalidad (cuando un objeto es opcional el que intervenga en una relación). La descripción de clases complejas se puede documentar con diagramas de estados.

jueves, 29 de noviembre de 2012

Metodología Kendall & Kendall.

“El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario.” (Kendall & Kendall) Según la metodología de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificación del problema, la segunda identificación de requisitos de información, la tercera es el análisis de las necesidades del sistema, la cuarta es el diseño del sistema recomendado, la quinta desarrollo y documentación del sistema, la sexta prueba y mantenimiento y la última implementación y evaluación. Cada fase se explica por separado pero nunca se realizan como pasos aislados, más bien es posible que algunas actividades se realicen de manera simultánea, y algunas de ellas podrían repetirse. 


FASE I: Identificación de problemas, oportunidades y objetivos.

Observación directa del entorno. 
Aplicación de entrevista para recolectar información. 
Sintetizar la información recolectada para construir objetivos. 
Estimar el alcance del proyecto. 
Identificar si existe una necesidad, problema u oportunidad argumentada. 
Documentar resultados. 
Estudiar los riesgos del proyecto. 
Presentar un informe de vialidad. 

En la primera fase el analista es el encargado de identificar los problemas de la organización, detallarlos, examinar, evaluar las oportunidades y objetivos. 

El analista debe identificar y evaluar los problemas existentes en la organización de manera crítica y precisa. Mayormente los problemas son detectados por alguien más y es cuando el analista es solicitado a fin de precisarlos. Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados, lo cual le da mayor seguridad y eficacia a las organizaciones además de obtener una ventaja competitiva. El analista debe identificar los objetivos, es decir, el analista debe averiguar lo que la empresa trata de conseguir, se podrá determinar si algunas funciones de as aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos. Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase son las entrevistas a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase en un informe de viabilidad que incluye la definición del problema y un resumen de los objetivos. La administración debe decidir si se sigue adelante o si se cancela el proyecto propuesto.




FASE II: Determinación de los requerimientos de información.

Revisión de los objetivos. 
Identificar el dominio. 
Investigar la razón por la cual se implementa el sistema actual. 
Recolectar información sobre los procedimientos y operaciones que se desempeñan actualmente. 
Detallar específicamente: Quiénes son los involucrados, cuál es la actividad, regla y restricciones del negocio, entorno de desarrollo de las actividades, momentos oportunos de desarrollo de cada función, la manera en que se desempeñan los procedimientos actuales. 
Elaborar una lista detallada y organizada de todos los procedimientos. 
Separar requerimientos funcionales y no funcionales. Adicionar al informe de la primera fase, esta nueva información.



En esta fase el analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades. Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos e oficina, al igual que métodos de amplio alcance como la elaboración de prototipos. 

Esta fase es útil para que el analista confirme la idea que tiene de la organización y sus objetivos. 

Los implicados en esta fase son el analista y los usuarios, por lo general los trabajadores y gerentes del área de operaciones. 

El analista necesita conocer los detalles de las funciones del sistema actual: 
El quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. 

Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados. 


FASE III: Análisis de las necesidades.

Evaluar las dos fases anteriores. 
Modelar las entradas, los procesos y las salidas de las funciones ya identificadas. 
Elaborar diccionario de datos y sus especificaciones. 
Elaborar diagramas de procesos de cada función. 
Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos. 
Realizar el análisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el aspecto económico, técnico y operacional (estudio de factibilidad) 
Estimar en un diagrama de Gantt el tiempo que tomará desarrollar el sistema. 

En esta fase el analista evalúa las dos fases anteriores, usa herramientas y técnicas como el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma gráfica estructurada. 


A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema así como sus respectivas especificaciones. 

El analista prepara en esta fase, una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. 


FASE IV: Diseño del sistema recomendado.

Evaluar las tres fases anteriores. 
Realizar el diseño lógico de todo el sistema. 
Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de información. 
Elaborar el diseño de la base de datos. 
Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o función. 
Diseñar controles y procedimientos de respaldos que protejan al sistema y a los datos. 
Producir los paquetes específicos de programas para los programadores. 
Elaborar una lista de las funciones genéricas y de las que será obligatorio crear.


En esta fase el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información. 

El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos. 

Facilita la entrada eficiente de datos al sistema de información mediantes técnicas adecuadas de diseño de formularios y pantallas. 

La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. 

La interfaz conecta al usuario con el sistema y por tanto es sumamente importante. 

También incluye el diseño de archivos o bases de datos que almacenarán gran parte delos datos indispensables para los encargados de tomar las decisiones en la organización. 

En esta fase el analista interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos. 

Finalmente el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. 

Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento.


FASE V: Desarrollo y documentación del software.

Evaluar los procedimientos que va a ser desarrollados por el programador. 
Mostrar y explicar cada procedimiento, función y operación al programador. 
Elaborar manuales de procedimientos internos del sistema. 
Elaborar manuales externos de ayuda a los usuarios del sistema. 
Elaborar demostraciones para los usuarios y la interacción con distintas interfaces. 
Elaborar actualizaciones para los diferentes procedimientos. Elaborar un informe con el tiempo que se llevó construir cada procedimiento.



En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y el pseudocódigo. 

Durante esta fase el analista trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en archivos “léame” que se integrarán al nuevo software. 

La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso. Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo.



FASE VI: Prueba y mantenimiento del sistema.

Realizar la programación de las pruebas del sistema. 
Realizar un instrumento para evaluar el sistema de información. 
El programador deberá elaborar un resumen de las pruebas del sistema. 
El analista deberá realizar un informe de sus pruebas y discutirlo con el programador. 
Elaborar la planificación de las horas del mantenimiento del sistema. Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos.



Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios. 

Una parte de la pruebas la realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realizan las pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual. 

El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan de manera rutinaria durante toda su vida útil.





FASE VII: Implementación y evaluación del sistema.

Planificar gradualmente la conversión del sistema anterior. 
Instalar los equipos de hardware necesarios para el funcionamiento del software creado. 
Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados. 
Evaluar la adaptabilidad de los usuarios al sistema.

Esta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas. 

Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en áreas del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases. 

El trabajo de sistemas es cíclico, cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar a regresar a la fase previa y modificar el trabajo realizado.


Técnica, herramienta, método y metodología.



La técnica: 

Es un conjunto de saberes prácticos o procedimientos para obtener el resultado deseado. Una técnica puede ser aplicada en cualquier ámbito humano: ciencias, arte, educación etc. Aunque no es privativa del hombre, sus técnicas suelen ser más complejas que la de los animales, que sólo responden a su necesidad de supervivencia. 

En los humanos la técnica muchas veces no es consciente o reflexiva, incluso parecería que muchas técnicas son espontáneas e incluso innatas. 

La técnica requiere de destreza manual y/o intelectual, generalmente con el uso de herramientas. Las técnicas suelen transmiten de persona a persona, y cada persona las adapta a sus gustos o necesidades y puede mejorarlas. 

La técnica surgió de la necesidad humana de modificar su medio. Nace en la imaginación y luego se lleva a la concreción, siempre de forma empírica. En cambio la tecnología surge de forma científica, reflexiva y con ayuda de la técnica (desde el punto de vista histórico). 

Otra definición de técnica: "Supone el razonamiento inductivo y analógico de que en situaciones similares una misma conducta o procedimiento produce el mismo efecto, cuando éste es satisfactorio. Es por tanto el ordenamiento de la conducta o determinadas formas de actuar y usar herramientas como medio para alcanzar un fin determinado." 

Herramienta: 

En un sentido amplio, una herramienta es aquel elemento elaborado con el objetivo de hacer más sencilla una determinada actividad o labor mecánica, que requiere, para llevarla a buen puerto, de una aplicación correcta de energía. 

Otro uso recurrente que observa el término herramienta es el de dispositivo o procedimiento que aumenta la capacidad de llevar a cabo determinadas tareas, por ejemplo herramientas de programación, herramientas de gestión, matemáticas, entre otras. 

Método: 

Se refiere al medio utilizado para llegar a un fin. Su significado original señala el camino que conduce a un lugar. 

La palabra método puede referirse a diversos conceptos. Por ejemplo, a los métodos de clasificación científica. Esta es la disciplina que permite a los biólogos agrupar y separar en categorías a los diversos organismos y conjuntos. 

El método científico, por su parte, es la serie de pasos que sigue una ciencia para obtener saberes válidos (es decir, que pueden verificarse a través de un instrumento fiable). Gracias al respeto por un método científico, un investigador logra apartar su subjetividad y obtiene resultados más cercanos a la objetividad o a lo empírico. 

Según el filósofo inglés Francis Bacon, las distintas etapas del método científico son la observación (que permite analizar un fenómeno según se aparece ante la realidad); la inducción (para distinguir los principios particulares de cada una de las situaciones observadas); la hipótesis (la planteada a partir de la observación y de acuerdo a ciertos criterios); la prueba de la hipótesis mediante la experimentación; la demostración o refutación de la hipótesis; y el establecimiento de la tesis o teoría científica (las conclusiones). 

Otro método conocido es el hipotético deductivo, que es una descripción posible del método científico. Esta metodología sostiene que una teoría científica nunca puede calificarse como verdadera: en cambio, lo correcto es considerarla como no refutada. 

El método racional es el utilizado para obtener conocimiento sobre fenómenos que no son susceptibles de comprobación experimental. Entre las áreas que se apoyan en este método para la resolución de sus inquietudes, destaca la filosofía. Gracias a él puede cuestionar la realidad a partir del método racional, basado en la observación y en la aceptación de ciertas existencias que poseen evidencia en la realidad. A través de él puede conseguirse comprender de una forma más amplia la humanidad, la vida, el mundo y al ser. 

El método experimental es aquel que se caracteriza por comprobar, midiendo las variaciones y los efectos de una situación. Las ciencias que más lo aplican son las ciencias naturales y biológicas. 

El método estadístico se encarga de recopilar datos numéricos, y de interpretarlos y elaborar relaciones entre determinados grupos de elementos para determinar tendencias o generalidades. 

El término método, por último, también se utiliza en el concepto de métodos anticonceptivos, que es la metodología que imposibilita o minimiza la chance de que se produzca un embarazo al entablar una relación sexual. Los métodos anticonceptivos incluyen acciones, medicación o dispositivos que permiten controlar la natalidad. 

Metodología: 

Hace referencia al conjunto de procedimientos racionales utilizados para alcanzar una gama de objetivos que rigen en una investigación científica, una exposición doctrinal o tareas que requieran habilidades, conocimientos o cuidados específicos. Alternativamente puede definirse la metodología como el estudio o elección de un método pertinente para un determinado objetivo. 

No debe llamarse metodología a cualquier procedimiento, ya que es un concepto que en la gran mayoría de los casos resulta demasiado amplio, siendo preferible usar el vocablo método. 

Análisis, análisis estructurado y orientado a objeto


El analista de sistemas es imprescindible en cualquier organización, debido al abanico de destrezas que éste posee y los beneficios que le produce. se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen. 

El analista de sistemas también tiene dentro de sus actividades el análisis y diseño de sistemas el cual se refiere al "proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados." (senn, 1992, p.11). Ésta actividad se puede dividir en dos: el análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable. 

Todo análisis y diseño de sistemas liderizado o no por un analista de sistemas posee fases que pueden dividirse de forma lógica en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. es aquí donde pueden ser utilizadas diferentes metodologías entre las cuales se pueden mencionar: el análisis y diseño estructurado y el análisis y diseño orientado a objeto. 

la investigación que se presenta a continuación define las dos metodologías mencionadas anteriormente así como también, las diferencias que existen entre ellas. por último se presenta un caso práctico donde se plantea un ejemplo de cómo se puede utilizar la metodología orientada a objeto en un proyecto web que le sirva a la empresa donde laboro. 

Análisis y diseño estructurado. 

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. el método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de: 1) la división del sistema en componentes y 2) la construcción de un modelo del sistema. el método incorpora elementos tanto de análisis como de diseño. 

Análisis estructurado. 

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. no se establece cómo se cumplirán los requerimientos o la forma en que se implantará la aplicación. más bien permite que las personas observen los elementos lógicos (lo que hará el sistema) separado de los componentes físicos (computadoras, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado. 

Elementos del análisis estructurado. 

Descripción gráfica: utiliza símbolos o iconos para crear un modelo gráfico del sistema. Sin introducir procesos manuales o informatizados, archivos, entre otros. 

Diagramas de flujo de datos: tienen la misión de mostrar las fuentes y destinos de los datos, identificar y dar nombre a los procesos, dar nombre a los grupos de datos que relacionan una función con otra, señalar los almacenes de datos a los que se tiene acceso. 

Diccionario de datos: se definen flujo de datos, procesos y almacenes de datos. 

Diseño estructurado. 

El diseño estructurado, otro elemento del análisis estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. la meta del diseño estructurado es crear programas formados por módulos independientes unos de otros desde el punto de vista funcional. este enfoque no sólo conduce hacia mejores programas sino que facilita el mantenimiento de los mismos cuando surja la necesidad de hacerlo. 

El diseño estructurado es una técnica específica para el diseño de programas y no un método de diseño de compresión. es decir, no indica nada relacionado con el diseño de archivos o bases de datos, la presentación de entradas o salidas, la secuencia de procesamiento o el hardware que dará soporte a la aplicación. Esta técnica conduce a la especificación de módulos de programa que son funcionalmente independientes. 

La herramienta fundamental del diseño estructurado es el diagrama de flujo de datos, los diagramas estructurados son de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los diagramas estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él. Estas especificaciones funcionales para los módulos se proporcionan a los programadores antes que dé comienzo la fase de escritura de código. 

Empleo del análisis y diseño estructurado con otros métodos. 

Se combina, con bastante frecuencia, con el método de ciclo de vida clásico de desarrollo de sistemas. Por ejemplo los analistas pueden optar por desarrollar diagramas de flujo de datos como una forma para documentar las relaciones entre componentes durante la investigación detallada de algún sistema existente. Así mismo, se pueden definir los archivos y datos en un diccionario centralizado de datos de acuerdo con las reglas del análisis estructurado. 

Análisis y diseño orientado a objetos. 

Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de comportamiento específico. los propios objetos se pueden construir a partir de otros, que a su vez pueden estar formados por otros objetos. 

El análisis de sistemas en el mundo orientado a objetos se realiza al estudiar los objetos en un ambiente, así como los eventos que interactúan con dichos objetos. El diseño del software se realiza al volver a utilizar clases de objetos ya existentes y, en caso necesario, al construir nuevas clases. al modelar una empresa, los analistas deben identificar sus tipos de objetos y las operaciones que hagan que los objetos se comporten en determinada forma. 

Las técnicas orientadas a objetos se pueden utilizar como medios para el diseño sencillo de sistemas complejos. El sistema se puede ver como una colección de objetos, donde cada uno de ellos puede llegar a tener varias posibilidades. Las operaciones que modifican el estado son relativamente sencillas. los objetos se construyen a partir de otros objetos. Los sistemas se construyen a partir de otros componentes probados con un formato definido para las solicitudes de las operaciones del componente. El analista orientado a objetos ve el mundo como objetos (con estructuras de datos y métodos) y eventos que activan operaciones, las cuales modifican el estado de los objetos. Las operaciones aparecen como objetos que hacen solicitudes a otros objetos. El analista crea diagramas de la estructura de los objetos y de los eventos que los modifican. El modelo del diseñador es similar al modelo del analista, pero se toma con el detalle suficiente como para crear el código. el análisis y diseño orientado a objetos intenta lograr la reutilización masiva de las clases de objetos. Modela el mundo en términos de objetos que tienen propiedades y comportamientos, y eventos que activan operaciones que modifican el estado de los objetos. los objetos interactúan de manera formal con otros objetos. 

Programación orientada a objeto. 

La programación orientada a objetos no es un concepto nuevo, sus inicios y técnicas de programación se iniciaron a principios de los 70. se puede definir programación orientada a objetos (oops) como una técnica de programación que utiliza objetos como bloque esencial de construcción. la oops, es un tipo de programación más cercana al razonamiento humano. La oops surge como una solución a la programación de grandes programas, y para solventar el mantenimiento de dichas aplicaciones, ya que en la programación estructura el más mínimo cambio supone la modificación de muchas funciones relacionadas, en cambio con la oops solo es cuestión de añadir o modificar métodos de una clase o mejor, crear una nueva clase a partir de otra (herencia). 

Objeto: 

Los objetos son las cosas físicas y conceptuales que encontramos en el universo alrededor de nosotros. Hardware, software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos.

Clases: 

Las clases son como plantillas o modelos que describen como se construyen ciertos tipos de objeto. Cada vez que se construye un objeto de una clase, se crea una instancia de esa clase ("instance"). Una clase es una colección de objetos similares y un objeto es una instancia de una clase. Se puede definir una clase como un modelo que se utiliza para describir uno o más objetos del mismo tipo. 

Herencia: 

Una característica muy importante de los objetos y las clases es la herencia, una propiedad que permite construir nuevos objetos (clases) a partir de unos ya existentes. Esto permite crear "sub-clases" denominadas clases derivadas que comparten las propiedades de la clase de la cual derivan (clase base). las clases derivadas heredan código y datos de la clase base, asimismo incorporan su propio código y datos especiales. se puede decir que la herencia permite definir nuevas clases a partir de las clases ya existentes. 

Polimorfismo: 

En un sentido literal, polimorfismo significa la cualidad de tener más de una forma. En el contexto de poo, el polimorfismo se refiere al hecho de que una simple operación puede tener diferente comportamiento en diferentes objetos. En otras palabras, diferentes objetos reaccionan al mismo mensaje de modo diferente. Los primeros lenguajes de poo fueron interpretados, de forma que el polimorfismo se contemplaba en tiempo de ejecución. Por ejemplo, en c++, al ser un lenguaje compilado, el polimorfismo se admite tanto en tiempo de ejecución como en tiempo de compilación. 

Diferencias análisis y diseño estructurado y orientado a objeto. 

- la metodología de análisis y diseño estructurado, examinan los sistemas desde el punto de vista de las funciones o tareas que deben realizar, tareas que se van descomponiendo sucesivamente en otras tareas más pequeñas y que forman los bloques o módulos de las aplicaciones. En la orientación a objeto, por su parte, cobra mucho más importancia el aspecto de "modelado" del sistema, examinando el dominio del problema como un conjunto de objetos que interactúan entre sí. 

- en la metodología de análisis y diseño estructurado se produce una división entre los dos elementos de un sistema: funciones que llevan a cabo los programas y datos que se almacenan en archivos o bases de datos. y por otro lado, la orientación al objeto da un enfoque unificado de ambos aspectos, que se unen en los objetos. 

- en la metodología de análisis y diseño estructurado las herramientas que utilizan para el análisis son: diagramas de flujos de datos, diccionarios de datos, diagramas entidad-relación, diagramas de transición de estado, especificaciones de procesos. en las metodologías orientadas a objetos se emplean distintos modelos que depende de la metodología, entre los principales están modelo de objetos, modelo de estado u objeto-estado, entre otros. 

Además, podemos agregar otras diferencias secundarias tales como: 

- se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto. 

- aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables. 

- hay un alto grado de interacción y solapamiento, lo que lleva a una forma de trabajo muy dinámica.

sábado, 29 de septiembre de 2012

Sistemas de Información


  Un sistema de información es un conjunto de componentes que interaccionan entre sí para alcanzar un fin determinado, el cual es satisfacer las necesidades de información de dicha organización. Estos componentes pueden ser personas, datos, actividades o recursos materiales en general, los cuales procesan la información y la distribuyen de manera adecuada, buscando satisfacer las necesidades de la organización.

  Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información.

Entrada de Información: Es el proceso mediante el cual el Sistema de Información toma los datos que requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales son aquellas que se proporcionan en forma directa por el usuario, mientras que las automáticas son datos o información que provienen o son tomados de otros sistemas o módulos. Esto último se denomina interfaces automáticas.

  Las unidades típicas de entrada de datos a las computadoras son las terminales, las cintas magnéticas, las unidades de diskette, los códigos de barras, los escáners, la voz, los monitores sensibles al tacto, el teclado y el mouse, entre otras.

Almacenamiento de información: El almacenamiento es una de las actividades o capacidades más importantes que tiene una computadora, ya que a través de esta propiedad el sistema puede recordar la información guardada en la sección o proceso anterior. Esta información suele ser almacenada en estructuras de información denominadas archivos. La unidad típica de almacenamiento son los discos magnéticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM).

Procesamiento de Información: Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos introducidos recientemente en el sistema o bien con datos que están almacenados. Esta característica de los sistemas permite la transformación de datos fuente en información que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyección financiera a partir de los datos que contiene un estado de resultados o un balance general de un año base.

Salida de Información: La salida es la capacidad de un Sistema de Información para sacar la información procesada o bien datos de entrada al exterior. Las unidades típicas de salida son las impresoras, terminales, diskettes, cintas magnéticas, la voz, los graficadores y los plotters, entre otros. Es importante aclarar que la salida de un Sistema de Información puede constituir la entrada a otro Sistema de Información o módulo. En este caso, también existe una interfaz automática de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interfaz automática de salida con el Sistema de Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes.


Clasificación de los Sistemas de Información.

Sistemas transaccionales: Son Sistemas de Información que logran la automatización de procesos operativos dentro de una organización ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, entradas, salidas, etc.

Sistemas de soporte a la toma de decisiones: Son Sistemas de Información que apoyan el proceso de toma de decisiones.

Sistemas estratégicos: Son sistemas de información desarrollado en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información.

Video explicativo:




Características del sistema de información.

  Un SI tiene diversas características dependiendo de la perspectiva con la que se observa, lo dividiremos en dos grupos (1) desde la naturaleza:

Propósito u objetivo: todo sistema tiene uno o algunos propósitos u objetivos Las unidades o elementos (u objetos), como también las relaciones, definen una distribución que trata siempre de alcanzar un objetivo.

Globalismo o totalidad:  todo sistema tiene una naturaleza orgánica, por la cual una acción que produzca cambio en una de las unidades del sistema, con mucha probabilidad producirá cambios en todas las otras unidades de éste. En otros términos, cualquier estimulación en cualquier unidad del sistema afectará todas las demás unidades, debido a la relación existente entre ellas. El efecto total de esos cambios o alteraciones se presentará como un ajuste del todo al sistema. El sistema siempre reaccionará globalmente a cualquier estímulo producido en cualquier parte o unidad. Existe una relación de causa y efecto entre las diferentes partes del sistema. Así, el sistema sufre cambios y el ajuste sistemático es continuo. De los cambios y de los ajustes continuos del sistema se derivan dos fenómenos el de la entropía y el de la homeostasia.

Entropía: es la tendencia que los sistemas tienen al desgaste, a la desintegración, para el relajamiento de los estándares y para un aumento de la aleatoriedad. A medida que la entropía aumenta, los sistemas se descomponen en estados más simples. La segunda ley de la termodinámica explica que la entropía en los sistemas aumenta con el correr del tiempo, como ya se vio en el capítulo sobre cibernética. 

  A medida que aumenta la información, disminuye la entropía, pues la información es la base de la configuración y del orden. Si por falta de comunicación o, por ignorancia, los estándares de autoridad, las funciones, la jerarquía, etc. de una organización formal pasan a ser gradualmente abandonados, la entropía aumenta y la organización se va reduciendo a formas gradualmente más simples y rudimentarias de individuos y de grupos. De ahí el concepto de negentropía o sea, la información como medio o instrumento de ordenación del sistema.

Homeostasis: es el equilibrio dinámico entre las partes del sistema. Los sistemas tienen una tendencia a adaptarse con el fin de alcanzar un equilibrio interno frente a los cambios externos del medio ambiente.

Aunque también se pueden ver las características que tienen desde el (2) tipo de sistema:

Sistemas Transaccionales:
Agilizar las tareas operacionales de la organización.
Alta transaccionabilidad (entradas y salidas de información).
Nivel de cálculo bajo.

Sistemas de Apoyo de las Decisiones:
Baja transaccionabilidad (entradas y salidas de información).
Nivel alto de cálculo, y operaciones complejas.

Sistemas Estratégicos:
La complejidad de estos SI es alta.
Generalmente su implementación en la organizacional va precedida de los anteriores.
Apuntan a “apuntar” a otros horizontes la organización.


Importancia de los Sistemas de Información de las Organizaciones.


  Las organizaciones siempre utilizaron sistemas que les permitieron administrar el manejo de su información, con lo cual no necesariamente debe existir una computadora para reconocer la existencia de estos tipos de sistemas pues estos pueden ser también del tipo manuales; por ejemplo una distribuidora pequeña que no tenga informatizada la totalidad de sus esquemas de logística y comercialización. Lo importante es que el sistema permita almacenar, recuperar, procesar y distribuir información.
  Sin embargo, es cada vez más necesario el disponer de sistemas de información basados en computadoras por los beneficios que estos proporcionan: reducción de errores provocados por las personas a través del control de las entradas, velocidad en el procesamiento de datos, posibilidad de realizar tediosos análisis sobre los mismos, reducción de espacio físico destinado a su almacenamiento, agilidad al momento de buscar algún dato en particular, y otros tipos de ventajas que podrían lograrse en caso de enfocarse en el uso estratégico de los mismos.
  En los entornos de negocio actuales, el disponer de una buena gestión en el uso de los sistemas de información se convierte en una estrategia que pueden utilizar las empresas para hacer frente a sus fuerzas competitivas.

Ciclo de vida de los Sistemas de Información.

  Existen pautas básicas para el desarrollo de un SI para una organización:

Conocimiento de la Organización: analizar y conocer todos los sistemas que forman parte de la organización, así como los futuros usuarios del SI. En las empresas (fin de lucro presente), se analiza el proceso de negocio y los procesos transaccionales a los que dará soporte el SI.

Identificación de problemas y oportunidades: el segundo paso es relevar las situaciones que tiene la organización y de las cuales se puede sacar una ventaja competitiva(Por ejemplo: una empresa con un personal capacitado en manejo informático reduce el costo de capacitación de los usuarios), así como las situaciones desventajosas o limitaciones que hay que sortear o que tomar en cuenta(Por ejemplo: el edificio de una empresa que cuenta con un espacio muy reducido y no permitirá instalar más de dos computadoras).

Determinar las necesidades: este proceso también se denomina elicitación de requerimientos. En el mismo, se procede identificar a través de algún método de recolección de información (el que más se ajuste a cada caso) la información relevante para el SI que se propondrá.

Diagnóstico: En este paso se elabora un informe resaltando los aspectos positivos y negativos de la organización. Este informe formará parte de la propuesta del SI y, también, será tomado en cuenta a la hora del diseño.

Propuesta: contando ya con toda la información necesaria acerca de la organización es posible elaborar una propuesta formal dirigida hacia la organización donde se detalle el presupuesto, relación costo-beneficio, presentación del proyecto de desarrollo del SI.

Diseño del sistema: Una vez aprobado el proyecto, se comienza con la elaboración del diseño lógico del SI; la misma incluye el diseño del flujo de la información dentro del sistema, los procesos que se realizarán dentro del sistema, etc. En este paso es importante seleccionar la plataforma donde se apoyará el SI y el lenguaje de programación a utilizar.

Codificación: con el algoritmo ya diseñado, se procede a su reescritura en un lenguaje de programación establecido (programación), es decir, en códigos que la máquina pueda interpretar y ejecutar.

Implementación: Este paso consta de todas las actividades requeridas para la instalación de los equipos informáticos, redes y la instalación del programa generado en el paso anterior.

Mantenimiento: proceso de retroalimentación, a través del cual se puede solicitar la corrección, el mejoramiento o la adaptación del SI ya creado a otro entorno. Este paso incluye el soporte técnico acordado anteriormente.




enlaces de interés:

Introducción a la Teoría General de Sistemas [PDF]
La Teoría General de Sistemas (M. en C. Eduardo Bustos Farías) [PDF]

 

Reloj