Una computadora por US$25

 

No es mucho más grande que un dedo y parece un residuo de una fábrica de electrónica, pero sus creadores creen que su equipo de US$25 podría ayudarle a una nueva generación a descubrir la programación.

El programador británico David Braben y sus colegas le mostraron a la BBC algo que se llama Raspberry Pi (“Frambuesa Pi”).

Es un equipo completo en una pequeña placa de circuito, compuesto por un procesador ARM, un puerto USB y una conexión HDMI.

En un extremo, se le puede conectar un teclado y en el otro una pantalla.

El resultado es una computadora que funciona con el sistema operativo Linux, a un costo mínimo, y que, como los equipos para armar uno mismo de los años 70 y 80, podría alentar a los usuarios a jugar con las partes y a aprender un poco de programación.

FUENTE : tecnologicos.org

EL DICCIONARIO DE DATOS

Un análisis del ámbito de información estaría incompleto si solo se considera el flujo de la información. Cada flecha del diagrama de flujo de datos representa uno o varios elementos de información, cada archivo de datos es una colección de elementos de datos individuales; incluso puede que el contenido de una entidad externa requiera ser expandido antes de que su significado pueda ser definido explícitamente. Por lo tanto, el analista debe disponer de algún método para representar el contenido de cada componente del modelo de flujo de datos.

Se ha propuesto el Diccionario de Datos como gramática casi formal para describir el contenido de los objetos definidos durante el análisis estructurado.

Esta importante notación ha sido definida de la siguiente marea:

El Diccionario de Datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que le permite al usuario y al proyectista del sistema tener una misma comprensión de las entradas, de las salidas, de los componentes de los repositorios, y también de cálculos intermedios.

CONTENIDO DEL DICCIONARIO DE DATOS

El Diccionario de datos debe contener la siguiente información:

Nombre: el nombre principal del elemento; del flujo de datos, del repositorio de datos o de una entidad externa.

Alias: otros nombres usados para la entrada, dado que un mismo elemento puede ser conocido por diferentes nombres.

Definición: Exposición clara y precisa de las características genéricas y diferenciales del objeto.

Descripción: Explicar las diversas partes o circunstancias, que componen la definición, de los objetos.

Dónde se usa/cómo se usa: Un listado de los procesos que usan un elemento de datos, o del control de cómo lo usan.

Descripción del contenido: El contenido es representado mediante una anotación que se describe en la siguiente tabla.

Existen muchos esquemas de anotación usados por los analistas de sistemas el que sigue es uno de los mas usados.

Símbolo	Descripción
=	Está compuesto de
+	Y
( )	Opcional (puede estar presente o ausente)
{ }	Interacción entre componentes
[ ]	Elección de una de las opciones
* *	Comentario
|	Separa opciones de alternativas en la construcción [ ]
@	Identificador campo llave

Referencias

Diagramas De Flujos De Datos

Un diagrama de flujo de datos (DFD) es un modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software. Sus elementos gráficos son círculos, flechas, y rectángulos cerrados o abiertos. Los cerrados representan entidades externas mientras que los abiertos describen almacenes o archivos. Los círculos significan procesos y las flechas flujos de datos desde, o hacia, un proceso.

En un DFD también se utiliza la escritura. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Los procesos se etiquetan con un número y un verbo en infinitivo con objeto directo.

Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos, en este caso la etiqueta tendrá un número adicional. No hay un límite para el número de procesos.

Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación gráfica del “flujo” de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y la entidades externas. Este contexto a nivel de DFD se “explotó” para mostrar más detalles del sistema que se está modelando.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: “flujo gráfico de datos” . Los diagramas de flujo de datos(DFDs) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado puede determinarse a través de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificación de los datos de la transacción en el modelo de datos.

Los diagramas derivados de los procesos principales se clasifican en niveles, los cuales son:

           Nivel 0: Diagrama de contexto.

           Nivel 1: Diagrama de nivel superior.

           Nivel 2: Diagrama de detalle o expansión.

EXPERIENCIA CON HYPERCASE®

"Bienvenido a Maple Ridge Engineering, al que en adelante llamaremos MRE. Esperamos que disfrute su trabajo de consultor de sistemas para nosotros. A pesar de que he trabajador aquí durante cinco años en diferentes actividades, recién fui asignado para fungir como apoyo administrativo para Snowden Evans, el jefe de nuevo Departamento de Capacitacion y Administración de Sistemas. Ciertamente somos un grupo heterogéneo. Conforme se familiarice con la compañía, asefurece de aprovechar todos sus conocimientos, tanto técnicos como relativos a las personas, para entender como somos e identificar los problemas y conflictos relacionados con nuestros sistemas de información que usted considere susceptibles de arreglar".

"Para ponerlo al tanto, le diré que Maple Ridge Engineering es una compañía de ingeniería medica de mediano tamaño. El año pasado nuestros ingresos rebasaron 287 millones de dólares. Empleamos alrededor 335 personas. Hay cerca 150 empleados administrativos, así como personal directivo de oficinas, como yo, y aproximadamente 75 profesionalitas, como ingenieros, médicos y analistas de sistemas, y cerca de 110 empleados como dibujantes y técnicos".

"Hay cuatro oficinas a través de HyperCase, usted no visitará en nuestras oficinas centrales en Maple Ridge, Tennessee. Tenemos otras tres sucursales al sur de Estados Unidos: Atlanta, Georgia, Charlotte, Carolina del Norte; y Nueva Orleáns, Luisiana. Nos dará gusto que nos visite".

"Por el momento, explore HyperCase.con Nestcape Navigator o Microsoft Internet Explorer".

"Para aprender mas sobre Maple Ridge Engineering como compañía, para saber como entrevistar a nuestro empleados, quien utilizara los sistemas que usted diseñe y como son sus oficinas dentro de nuestra compañía, visite el sitio Wed de este libro y seleccione el vinculo HyperCase. Al desplegarse la pantalla de HyperCase, elija Stara e ingresara a la recepción de Maple Ridge Engineering. A partir de aquí puede empezar de inmediato su trabajo de consultaría".

Este sitio Wed contiene información útil para el proyecto de archivos que usted puede bajar a su computadora. Uno de los archivos contiene una serie de archivos de datos de visible Analyst para utilizarse en HyperCase. Estos archivos incluyen una serie parcialmente construidas de diagramas de flujo de datos, diagrama de entidad-relación y el deposito CASE. El sitio Wed de HyperCase también contiene ejercicios adicionales. HyperCase esta diseñado para facilitar su exploración, así que no ignore cualquier objeto o pista que encuentre en la página Web.

Los analistas de sistemas recomiendan, diseñan y dan mantenimiento a diversos tipos de sistemas, como los sistemas de procesamiento de transacciones (TPS), sistemas de automatización de la oficina (OAS), sistemas de trabajo del conocimiento (KWS) y sistemas de información gerencial (MIS). También crean sistemas orientados a la toma de decisiones, como los sistemas de apoyo a la toma de decisiones (DSS), sistemas expertos (ES), sistemas de apoyo a la toma de decisiones en grupo (GDSS), sistemas de trabajo colaborativo apoyados por computadoras (CSCWS) y sistemas de apoyo a ejecutivos (ESS). Muchas aplicaciones se conciben originalmente para, o se migran a, la Web para apoyar el comercio electrónico.

El diseño y análisis de sistemas es un enfoque sistemático para identificar problemas, oportunidades y objetivos; para analizar los flujos de información de las organizaciones, y para diseñar sistemas de información computarizados destinados a solucionar problemas. Los analistas de sistemas se ven precisados a desempeñar diversos roles durante le transcurso de su trabajo. Algunos de estos roles son: 1) consultor externo para el negocio 2) experto en apoyo dentro de un negocio y 3) agente de cambio en situaciones tanto internas como externas.

Los analistas poseen un amplio rango de habilidades. En primer lugar, y mas importante, el analista es un solucionador de problemas; alguien que disfruta el reto de analizar un problema e idear soluciones factibles. El analista de sistemas requiere habilidades de comunicación que le permitan relacionarse de manera significativa con diversas clases de gente diariamente, así como habilidades de computación. El involucramiento del usuario del usuario final es crítico para el éxito del proyecto.

Los analistas actúan de manera sistemática. El marco para este enfoque sistemático lo ofrece el ciclo de vida del desarrollo de sistemas (SDLC). Este ciclo de vida se puede dividir en siete fases secuenciales, aunque en realidad las fases s interrelacionan y con frecuencias se llevan a cabo de manera simultanea. Las siete fases son: identificación de problemas, oportunidades y objetivos; determinación de los requerimientos de información; análisis de las necesidades del sistema; diseño del sistema recomendado; desarrollo y documentación del software; prueba y mantenimiento del sistema, e implementación y evaluación del sistema.

Los paquetes de software automatizados, basado en el PC, para el análisis y diseños de sistemas se reconocen como herramientas de ingeniería de software asistida por computadora (CASE). Las cuatros razones para adoptar las herramientas CASE son: incrementar la productividad del analista, mejorar la comunicación entre analistas y usuarios, integrar las actividades las actividades del ciclo de vida, y analizar y valorar el impacto de los cambios en el mantenimiento. Los analistas también emplean enfoques de reingeniería inversa de software y reingeniería con el propósito de extender la vida útil del software heredado.

El análisis orientado a objetos (OOA) y el diseño orientado a objetos (OOD) constituyen un enfoque distinto de desarrollo de sistema. Estas técnicas se basan en los aspectos de la programación orientada a objetos que hayan sido codificados en UML, un lenguaje estandarizado de modelación en el cual los objetos generados no solo incluyen código referente a los datos sino también instrucciones acerca de las operaciones que se realizaran sobre los datos.

Cuando la situación particular de una organización así lo requiera, el analista podría dejar el SDLC y probar una metodología alterna. Un enfoque

, denominado programación externas (XP), lleva al límite las prácticas de análisis y diseño. La creación de prototipos, ETHICS, el uso de un campeón del proyecto, la metodología Soft Systems y Multiview son enfoques de desarrollo que ofrecen perspectivas diferentes.

Fuente: http://www.monografias.com/trabajos59/rol-analista-sistemas/rol-analista-sistemas2.shtml