La ingeniería del software asistida por computadora puede ser tan sencilla como una única herramienta que preste su apoyo para una única actividad de ingeniería del software, o tan compleja como todo un entorno que abarque «herramientas», una base de datos, personas, hardware, una red, sistemas operativos, estándares, y otros mil componentes más. Cada bloque de construcción forma el fundamento del siguiente, estando las herramientas situadas en la parte superior del montón. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos tiene relativamente poco que ver con las herramientas de ingeniería del software en sí. Más bien, los entornos para la ingeniería del software se construyen con éxito sobre una arquitectura de entornos que abarca un hardware y un software de sistemas adecuados. Además, la arquitectura del entorno deberá tener en cuenta los patrones de trabajo humano que se aplicarán durante el proceso de ingeniería del software.
Las arquitecturas del entorno, que constan de una plataforma hardware y de un soporte de sistema operativo (incluyendo software de red, gestión de la base de datos y servicios de gestión de objetos), establece los cimientos para un entorno CASE. Pero el entorno CASE en sí requiere otros bloques de construcción. Existe un conjunto de servicios de portabilidad que proporciona un puente entre las herramientas CASE, su marco de integración y la arquitectura del entorno. El marco de integración es un grupo de programas especializados que permiten a cada una de las herramientas comunicarse entre sí, para crear una base de datos del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero del software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de integración migren entre distintas plataformas del hardware y sistemas operativos sin un mantenimiento adaptativo significativo.
Los bloques de representan un fundamento completo para la integración de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE que se utilizan en la actualidad no han sido construidas empleando todos los bloques de construcción anteriormente descritos. De hecho, algunas herramientas siguen siendo las «soluciones puntuales». Esto es, una herramienta se utiliza para prestar apoyo en una actividad de ingeniería del software concreta (por ejemplo, modelado de análisis), pero esta herramienta no se comunica directamente con otras, no está unida a una base de datos del proyecto, y no forma parte de un entorno integrado CASE (1-CASE). Aunque esta situación no es la ideal, se puede utilizar una herramienta CASE bastante eficiente, aunque se trate de una solicitud puntual.
martes, 5 de agosto de 2008
Tecnologia de la Información y la Productividad
La Paradoja de la Productividad.
Las organizaciones se constituyen para generar y distribuir un producto o servicio y con ello conseguir un beneficio, ya sea económico o social. Las organizaciones intentan funcionar de la manera más efectiva y eficiente posible. Se considera que una buena medida de la eficiencia de las organizaciones consiste en evaluar su productividad, definida como la relación entre el valor de los productos o servicios que genera y los costes de los recursos consumidos para la generación o prestación de los mismos.
La productividad de una organización es, pues, el cociente entre el output y el input en la misma. En los mismos términos se puede definir la productividad de un sector industrial, así como la productividad a nivel nacional o internacional. En todos los casos, la principal utilidad de las medidas de productividad surge cuando se comparan los datos de distintas empresas, sectores o naciones, más que cuando se analizan los datos de una sola entidad.
Uno de los objetivos permanente de toda organización, sector o nación consiste en aumentar su productividad. Y ello porque la mejora de la productividad es “el único medio válido para poder pagar niveles de vida creciente”.
Tradicionalmente, los medios utilizados para aumentar la productividad han consistido, por un lado, en cambiar los métodos de trabajo, ya sea mediante su reorganización metódica o la incorporación de tecnología, a fin de aumentar el outpu de cada unidad operativa, y, por otro lado, reducir coste, a fin de disminuir el input necesario para la elaboración de los productos o la prestación de los servicios.
El factor realmente indicativo del desarrollo de las organizaciones no es su productividad en sí, sino la tasa anual de crecimiento de la productividad. Y aquí es donde aparece lo que se ha venido en llamar “paradoja de la productividad”: la tasa de crecimiento de la productividad en el conjunto de los países occidentales se ha desacelerado durante las dos últimas décadas, y no ha conseguido igualar las cifras de crecimiento conseguidas tras la Segunda Guerra Mundial, y ello a pesar de que los avances tecnológicos son ahora mayores y más rápidos que nunca.
Lo más sorprendente de la paradoja es que la desaceleración en el crecimiento de la productividad se produce justo cuando la tecnología parece avanzar más, y cuando las inversiones en tecnología por parte de las organizaciones suman cantidades muy relevantes.
En concreto, en lo que se refiere a las tecnologías de la información, durante las tres últimas décadas, y en especial durante los ochenta, se han producido avances en capacidad y prestaciones impresionantes, avances que pueden ser medidos, por ejemplo, en términos de la relación potencia/coste de los equipos informáticos, que no ha dejado de crecer, así, por ejemplo, la unidad de potencia de proceso de un ordenador personal pasó de costar tres mil dólares 1987 a costar menos de setecientos cincuenta 1991, y menos de quinientos en 1992.
Por otra parte, las inversiones en TI ha ido paralela al avance técnico. Así, desde 1982, el 52 % del crecimiento acumulado de bienes de capital en el conjunto de los sectores económicos de los Estados Unidos ha correspondido a inversiones en TI (Ordenadores, Telecomunicaciones, reprografía, instrumentos científicos, equipo ofimático en general.
Razones de la paradoja de la productividad.
Distintos autores y estudios han propuesto un conjunto de posibles razones de la “paradoja de la productividad”, es decir, de la desaceleración del crecimiento de la productividad experimentada en los países occidentales justo en las décadas que el avance tecnológico ha sido más evidente. No existe aún unanimidad en el diagnóstico de las causas de la paradoja, aunque hay un cierto acuerdo en que quizás sea algo pronto para encontrarlas, ya que las TI no se han implantado de una manera suficientemente amplia como para desarrollar todo su potencial de aceleración de la productividad.
La desaceleración de la productividad puede ser, en cierta medida, resultado de un espejismo estadístico, es decir, no se trata de un hecho real sino que se deriva de las dificultades surgidas en la medida estadística de la productividad.
No es que se haya producido una desaceleración de la productividad en los setenta y ochenta, sino que la aceleración fue extraordinariamente alta en los cincuenta y sesenta, a causa de la conjunción de un aserie de factores, como, por ejemplo, la necesidad de reconstrucción de la mayoría de bienes de capital en Europa y Japón tras la Segunda Guerra Mundial.
La razón fundamental de la paradoja de la productividad, en lo que se refiere a las TI, consiste quizá en que su aplicación implica un verdadero cambio de paradigma, el paso de un sistema basado en el uso intensivo de energía aun sistema intensivo en información, y que, como en todo cambio de paradigma, se requiere en un cierto tiempo para que las potencialidades del nuevo paradigma puedan manifestarse.
El nuevo paradigma traído por las TI posibilitara nuevo avances en productividad, pero sólo si las TI se difunden adecuadamente por todo el sistema económico, lo que exige muchos cambios sociales e institucionales… así como un gran aumento de nuevas habilidades de las personas y transformaciones de los bienes existentes.
Las empresas pretenden aumentar su productividad automatizando labores manuales para conseguir actividad ininterrumpida las veinticuatro hora de los sietes días de cada semana del año, pero el ahorro en personal y en duplicación de maquinaria (que contribuye a aumentar la productividad) es superado por los nuevos costes de la automatización, es decir, por el hardware, el software y su correspondiente mantenimiento. Advierte que son otras las verdaderas ventajas de la automatización, como, por ejemplo, la posibilidad de aumentar la calidad disminuyendo al máximo los errores, o de disminuir el tiempo des respuesta tras la recepción de un pedido. La importancia de las TI son pues más de orden estratégico que de orden táctico; la competitividad del producto o servicio prima más que la mera productividad.
El estudio del MIT (Massachusset Institute of Technology) con el objeto de estudiar el impacto de las tecnologías de la información (TI). En este estudio se proponen diversas razones por las que el avance de las TI no se ha traducido en mejoras de las variables tradicionales con las que con las que se mide el éxito de una empresa (Productividad y rentabilidad). Entre las distintas razones propuestas, cabe destacar las siguientes:
Los beneficios aportados por las tecnologías de la información no son inmediatamente visibles.
Los beneficios aportados por las tecnologías de la información no son capturables por la empresa.
El entorno de la empresa se vuelve cada vez más exigente.
El impacto de las tecnologías de la información es escaso si su aplicación no viene acompañada de cambios en la organización de la empresa.
La implantación de las tecnologías de la información no ha respondido a las necesidades fundamentales de la empresa.
El estudio MIT señala también cuáles son las características comunes de las empresas que han sabido aprovechar satisfactoriamente el potencial de las tecnologías de la información. Entre ellas, cabe destacar las siguientes:
Tenían un objetivo empresarial concreto, y una visión clara de lo que debía ser la organización.
Habían alienado su estrategia de tecnología de la información con la estrategia general de la empresa y con las dimensiones de la organización.
Tenía una estructura de tecnología de la información capaz y robusta.
Habían invertido en recursos humanos, a fin de sacar el máximo partido de las tecnologías.
Esta última característica se considera fundamental, hasta el punto de que se concluye que una causa fundamental de la falta de impacto de las tecnologías de la información en la mejora del comportamiento económico de las organizaciones es de la poca disposición de ésta a invertir fuertemente, y suficientemente pronto, en los recursos humanos.
El Futuro de la TI la Productividad.
El panorama descrito hasta el momento en este capítulo puede parecer algo sorprendente y sombrío. Se ha empezado indicando que la productividad se ha desacelerado justo en la época en que el avance de las tecnologías es mayor. Se ha dicho también que esta paradoja es más evidente en el sector servicios, y que la importancia creciente de éste en el conjunto de la economía hace del aumento de la productividad en servicios uno de los mayores condicionantes de la mejora del nivel de vida en las sociedades desarrolladas.
La verdad es que no se dispone aún de un arsenal de datos comparables al existente para la década de los ochenta. Sin embargo, algunos autores anticipan que se están produciendo cambios relevantes en lo que respecta a la justificación de las inversiones en TI. Por un lado, las organizaciones están adaptando sus estructuras con el fin de sacar mayor provecho de su principal activo, las personas.
Ello conlleva en muchos casos una definición del trabajo, de las jerarquías, del estilo de dirección, con una eliminación de procesos y procedimientos innecesarios y con la distribución de información allí donde es necesaria, y no sólo en el nivel directivo como antes.
Por otro lado, se está produciendo un cambio importante en las metodologías de análisis y diseño de sistemas de información. Así, la denominada reingeniería pone en cuestión todos los procedimientos y procesos en los que se han aplicado TI en una empresa y no duda en empezar desde el principio si es necesario. El enfoque está en aplicar las TI para aumentar la efectividad, más que para aplicar la eficiencia necesaria no hace más que aminorar la productividad de la empresa.
Finalmente, las TI empiezan a ofrecer productos con verdadero impacto en la productividad. Y a diferencia de lo que ocurría hasta ahora, el avance se produce en los interfaces gráficos de usuarios, los softwares para la interconexiones en red, que finalmente facilitan el trabajo en grupo, las bases de datos relacionales, que pueden ser compartidas por distintas personas y departamentos de una empresa, o las técnicas de imágenes a través de las redes. Todo ello se caracterizan por su gran facilidad de aprendizaje y de utilización.
De alguna forma, se ha tenido que esperar a que el software avanzara suficientemente para que pueda entreverse un impacto positivo de las TI en la productividad de las empresas.La realización de cambios en la estructura organizativa de las empresas, la aplicación de nuevas metodologías de desarrollo de sistemas de información, y la incorporación de software más potentes, pueden traducirse en los próximos años en el esperado aumento de la productividad, especialmente en el sector servicios, pueden conllevar la superación de la paradoja de la productividad. Pero para ello será necesario que se produzcan un cambio sustancial en la filosofía de las organizaciones, por el que se pase a concebir las TI como instrumento para manejar mejor el activo información de la empresa en lugar de considerarlas como meros instrumentos de automatización de tareas más o menos rutinarias.
Las organizaciones se constituyen para generar y distribuir un producto o servicio y con ello conseguir un beneficio, ya sea económico o social. Las organizaciones intentan funcionar de la manera más efectiva y eficiente posible. Se considera que una buena medida de la eficiencia de las organizaciones consiste en evaluar su productividad, definida como la relación entre el valor de los productos o servicios que genera y los costes de los recursos consumidos para la generación o prestación de los mismos.
La productividad de una organización es, pues, el cociente entre el output y el input en la misma. En los mismos términos se puede definir la productividad de un sector industrial, así como la productividad a nivel nacional o internacional. En todos los casos, la principal utilidad de las medidas de productividad surge cuando se comparan los datos de distintas empresas, sectores o naciones, más que cuando se analizan los datos de una sola entidad.
Uno de los objetivos permanente de toda organización, sector o nación consiste en aumentar su productividad. Y ello porque la mejora de la productividad es “el único medio válido para poder pagar niveles de vida creciente”.
Tradicionalmente, los medios utilizados para aumentar la productividad han consistido, por un lado, en cambiar los métodos de trabajo, ya sea mediante su reorganización metódica o la incorporación de tecnología, a fin de aumentar el outpu de cada unidad operativa, y, por otro lado, reducir coste, a fin de disminuir el input necesario para la elaboración de los productos o la prestación de los servicios.
El factor realmente indicativo del desarrollo de las organizaciones no es su productividad en sí, sino la tasa anual de crecimiento de la productividad. Y aquí es donde aparece lo que se ha venido en llamar “paradoja de la productividad”: la tasa de crecimiento de la productividad en el conjunto de los países occidentales se ha desacelerado durante las dos últimas décadas, y no ha conseguido igualar las cifras de crecimiento conseguidas tras la Segunda Guerra Mundial, y ello a pesar de que los avances tecnológicos son ahora mayores y más rápidos que nunca.
Lo más sorprendente de la paradoja es que la desaceleración en el crecimiento de la productividad se produce justo cuando la tecnología parece avanzar más, y cuando las inversiones en tecnología por parte de las organizaciones suman cantidades muy relevantes.
En concreto, en lo que se refiere a las tecnologías de la información, durante las tres últimas décadas, y en especial durante los ochenta, se han producido avances en capacidad y prestaciones impresionantes, avances que pueden ser medidos, por ejemplo, en términos de la relación potencia/coste de los equipos informáticos, que no ha dejado de crecer, así, por ejemplo, la unidad de potencia de proceso de un ordenador personal pasó de costar tres mil dólares 1987 a costar menos de setecientos cincuenta 1991, y menos de quinientos en 1992.
Por otra parte, las inversiones en TI ha ido paralela al avance técnico. Así, desde 1982, el 52 % del crecimiento acumulado de bienes de capital en el conjunto de los sectores económicos de los Estados Unidos ha correspondido a inversiones en TI (Ordenadores, Telecomunicaciones, reprografía, instrumentos científicos, equipo ofimático en general.
Razones de la paradoja de la productividad.
Distintos autores y estudios han propuesto un conjunto de posibles razones de la “paradoja de la productividad”, es decir, de la desaceleración del crecimiento de la productividad experimentada en los países occidentales justo en las décadas que el avance tecnológico ha sido más evidente. No existe aún unanimidad en el diagnóstico de las causas de la paradoja, aunque hay un cierto acuerdo en que quizás sea algo pronto para encontrarlas, ya que las TI no se han implantado de una manera suficientemente amplia como para desarrollar todo su potencial de aceleración de la productividad.
La desaceleración de la productividad puede ser, en cierta medida, resultado de un espejismo estadístico, es decir, no se trata de un hecho real sino que se deriva de las dificultades surgidas en la medida estadística de la productividad.
No es que se haya producido una desaceleración de la productividad en los setenta y ochenta, sino que la aceleración fue extraordinariamente alta en los cincuenta y sesenta, a causa de la conjunción de un aserie de factores, como, por ejemplo, la necesidad de reconstrucción de la mayoría de bienes de capital en Europa y Japón tras la Segunda Guerra Mundial.
La razón fundamental de la paradoja de la productividad, en lo que se refiere a las TI, consiste quizá en que su aplicación implica un verdadero cambio de paradigma, el paso de un sistema basado en el uso intensivo de energía aun sistema intensivo en información, y que, como en todo cambio de paradigma, se requiere en un cierto tiempo para que las potencialidades del nuevo paradigma puedan manifestarse.
El nuevo paradigma traído por las TI posibilitara nuevo avances en productividad, pero sólo si las TI se difunden adecuadamente por todo el sistema económico, lo que exige muchos cambios sociales e institucionales… así como un gran aumento de nuevas habilidades de las personas y transformaciones de los bienes existentes.
Las empresas pretenden aumentar su productividad automatizando labores manuales para conseguir actividad ininterrumpida las veinticuatro hora de los sietes días de cada semana del año, pero el ahorro en personal y en duplicación de maquinaria (que contribuye a aumentar la productividad) es superado por los nuevos costes de la automatización, es decir, por el hardware, el software y su correspondiente mantenimiento. Advierte que son otras las verdaderas ventajas de la automatización, como, por ejemplo, la posibilidad de aumentar la calidad disminuyendo al máximo los errores, o de disminuir el tiempo des respuesta tras la recepción de un pedido. La importancia de las TI son pues más de orden estratégico que de orden táctico; la competitividad del producto o servicio prima más que la mera productividad.
El estudio del MIT (Massachusset Institute of Technology) con el objeto de estudiar el impacto de las tecnologías de la información (TI). En este estudio se proponen diversas razones por las que el avance de las TI no se ha traducido en mejoras de las variables tradicionales con las que con las que se mide el éxito de una empresa (Productividad y rentabilidad). Entre las distintas razones propuestas, cabe destacar las siguientes:
Los beneficios aportados por las tecnologías de la información no son inmediatamente visibles.
Los beneficios aportados por las tecnologías de la información no son capturables por la empresa.
El entorno de la empresa se vuelve cada vez más exigente.
El impacto de las tecnologías de la información es escaso si su aplicación no viene acompañada de cambios en la organización de la empresa.
La implantación de las tecnologías de la información no ha respondido a las necesidades fundamentales de la empresa.
El estudio MIT señala también cuáles son las características comunes de las empresas que han sabido aprovechar satisfactoriamente el potencial de las tecnologías de la información. Entre ellas, cabe destacar las siguientes:
Tenían un objetivo empresarial concreto, y una visión clara de lo que debía ser la organización.
Habían alienado su estrategia de tecnología de la información con la estrategia general de la empresa y con las dimensiones de la organización.
Tenía una estructura de tecnología de la información capaz y robusta.
Habían invertido en recursos humanos, a fin de sacar el máximo partido de las tecnologías.
Esta última característica se considera fundamental, hasta el punto de que se concluye que una causa fundamental de la falta de impacto de las tecnologías de la información en la mejora del comportamiento económico de las organizaciones es de la poca disposición de ésta a invertir fuertemente, y suficientemente pronto, en los recursos humanos.
El Futuro de la TI la Productividad.
El panorama descrito hasta el momento en este capítulo puede parecer algo sorprendente y sombrío. Se ha empezado indicando que la productividad se ha desacelerado justo en la época en que el avance de las tecnologías es mayor. Se ha dicho también que esta paradoja es más evidente en el sector servicios, y que la importancia creciente de éste en el conjunto de la economía hace del aumento de la productividad en servicios uno de los mayores condicionantes de la mejora del nivel de vida en las sociedades desarrolladas.
La verdad es que no se dispone aún de un arsenal de datos comparables al existente para la década de los ochenta. Sin embargo, algunos autores anticipan que se están produciendo cambios relevantes en lo que respecta a la justificación de las inversiones en TI. Por un lado, las organizaciones están adaptando sus estructuras con el fin de sacar mayor provecho de su principal activo, las personas.
Ello conlleva en muchos casos una definición del trabajo, de las jerarquías, del estilo de dirección, con una eliminación de procesos y procedimientos innecesarios y con la distribución de información allí donde es necesaria, y no sólo en el nivel directivo como antes.
Por otro lado, se está produciendo un cambio importante en las metodologías de análisis y diseño de sistemas de información. Así, la denominada reingeniería pone en cuestión todos los procedimientos y procesos en los que se han aplicado TI en una empresa y no duda en empezar desde el principio si es necesario. El enfoque está en aplicar las TI para aumentar la efectividad, más que para aplicar la eficiencia necesaria no hace más que aminorar la productividad de la empresa.
Finalmente, las TI empiezan a ofrecer productos con verdadero impacto en la productividad. Y a diferencia de lo que ocurría hasta ahora, el avance se produce en los interfaces gráficos de usuarios, los softwares para la interconexiones en red, que finalmente facilitan el trabajo en grupo, las bases de datos relacionales, que pueden ser compartidas por distintas personas y departamentos de una empresa, o las técnicas de imágenes a través de las redes. Todo ello se caracterizan por su gran facilidad de aprendizaje y de utilización.
De alguna forma, se ha tenido que esperar a que el software avanzara suficientemente para que pueda entreverse un impacto positivo de las TI en la productividad de las empresas.La realización de cambios en la estructura organizativa de las empresas, la aplicación de nuevas metodologías de desarrollo de sistemas de información, y la incorporación de software más potentes, pueden traducirse en los próximos años en el esperado aumento de la productividad, especialmente en el sector servicios, pueden conllevar la superación de la paradoja de la productividad. Pero para ello será necesario que se produzcan un cambio sustancial en la filosofía de las organizaciones, por el que se pase a concebir las TI como instrumento para manejar mejor el activo información de la empresa en lugar de considerarlas como meros instrumentos de automatización de tareas más o menos rutinarias.
Inteligencia Artificial
Se denomina inteligencia artificial a la rama de la informática que desarrolla procesos que imitan a la inteligencia de los seres vivos. La principal aplicación de esta ciencia es la creación de máquinas para la automatización de tareas que requieran un comportamiento inteligente.
Algunos ejemplos se encuentran en el área de control de sistemas, planificación automática, la habilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento de escritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmente son parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usado en gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador y otros videojuegos.
Algunos ejemplos se encuentran en el área de control de sistemas, planificación automática, la habilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento de escritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmente son parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usado en gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador y otros videojuegos.
El Nuevo Proceso de Ingenieria de Software
Es razonable caracterizar las dos primeras décadas de la práctica de ingeniería del software como la era del «pensamiento lineal». Impulsado por el modelo de ciclo vital clásico, la ingeniería del software se ha enfocado como una actividad en la cual se podían aplicar una serie de pasos secuenciales en un esfuerzo por resolver problemas complejos. Sin embargo, los enfoques lineales del desarrollo del software van en contra de la forma en que se construyen realmente la mayoría de los sistemas. En realidad, los sistemas complejos evolucionan de forma iterativa, e incluso incremental. Por esta razón, un gran segmento de la comunidad de la ingeniería del software se está desplazando hacia modelos evolutivos para el desarrollo del software. Los modelos de proceso evolutivos reconocen que la incertidumbre domina la mayoría de los proyectos; que las líneas temporales suelen ser imposibles y cortas; y que la iteración proporciona la habilidad de dar una solución parcial, aunque un producto completo no es posible dentro del marco de tiempo asignado. Los modelos evolutivos hacen hincapié en la necesidad de productos de trabajo incrementales, análisis de riesgos, planificación y revisión de planes, y realimentación que provenga del cliente.
A lo largo de la década pasada, el Modelo de madurez de capacidad desarrollado por el Software Engineering Institute (SEI) ha tenido un impacto apreciable sobre los esfuerzos por mejorar las prácticas de ingeniería del software y sin embargo proporciona una buena indicación de los una buena ingeniería del software.
Las tecnologías de objetos, junto con la ingeniería del software son un brote de la tendencia hacia los modelos de proceso evolutivos. Ambos tendrán un impacto profundo sobre la productividad de desarrollo del software y sobre la calidad del producto. La reutilización de componentes proporciona beneficios inmediatos y convincentes. Cuando la reutilización se une a las herramientas CASE para los prototipos de una aplicación, los incrementos del programa se pueden construir mucho más rápidamente que mediante la utilización de enfoques convencionales. La construcción de prototipos arrastra al cliente al proceso. Por tanto es probable que clientes y usuarios se impliquen más en el desarrollo del software. Esto, a su vez, puede llevar a una satisfacción mayor del usuario final y a una calidad mejor del software global.
El crecimiento rápido de las aplicaciones basadas en Web (WebApps) está cambiando tanto en el proceso de la ingeniería del software como en sus participantes. De nuevo, nos encontramos con un paradigma incremental y evolutivo. Pero en el caso de las WebApps, la inmediatez, seguridad y estética se están convirtiendo en las preocupaciones dominantes. Un equipo de ingeniería de Web mezcla técnicos con especialistas de contenido para construir una fuente de información para una comunidad de usuarios grande e impredecible. El software que ha surgido del trabajo de la ingeniería de Web ya ha dado como resultado un cambio radical tanto económico como cultural.
A lo largo de la década pasada, el Modelo de madurez de capacidad desarrollado por el Software Engineering Institute (SEI) ha tenido un impacto apreciable sobre los esfuerzos por mejorar las prácticas de ingeniería del software y sin embargo proporciona una buena indicación de los una buena ingeniería del software.
Las tecnologías de objetos, junto con la ingeniería del software son un brote de la tendencia hacia los modelos de proceso evolutivos. Ambos tendrán un impacto profundo sobre la productividad de desarrollo del software y sobre la calidad del producto. La reutilización de componentes proporciona beneficios inmediatos y convincentes. Cuando la reutilización se une a las herramientas CASE para los prototipos de una aplicación, los incrementos del programa se pueden construir mucho más rápidamente que mediante la utilización de enfoques convencionales. La construcción de prototipos arrastra al cliente al proceso. Por tanto es probable que clientes y usuarios se impliquen más en el desarrollo del software. Esto, a su vez, puede llevar a una satisfacción mayor del usuario final y a una calidad mejor del software global.
El crecimiento rápido de las aplicaciones basadas en Web (WebApps) está cambiando tanto en el proceso de la ingeniería del software como en sus participantes. De nuevo, nos encontramos con un paradigma incremental y evolutivo. Pero en el caso de las WebApps, la inmediatez, seguridad y estética se están convirtiendo en las preocupaciones dominantes. Un equipo de ingeniería de Web mezcla técnicos con especialistas de contenido para construir una fuente de información para una comunidad de usuarios grande e impredecible. El software que ha surgido del trabajo de la ingeniería de Web ya ha dado como resultado un cambio radical tanto económico como cultural.
Garantia de Calidad del Software
Hasta el desarrollador de software más agobiado estará de acuerdo con que el software de alta calidad es una meta importante. Pero, ¿cómo definimos la calidad? Un bromista dijo una vez: «Cualquier programa hace algo bien, lo que puede pasar es que no sea lo que nosotros queremos que haga».
En los libros se han propuesto muchas definiciones, &calidad del software. Por lo que a nosotros respecta, Ib calidad del software se define como: Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.
No hay duda de que la anterior definición puede ser modificada o ampliada. De hecho, no tendría fin una discusión sobre una definición formal de calidad del software. Para los propósitos de este libro, la anterior definición sirve para hacer hincapié en tres puntos importantes:
1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.
En los libros se han propuesto muchas definiciones, &calidad del software. Por lo que a nosotros respecta, Ib calidad del software se define como: Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.
No hay duda de que la anterior definición puede ser modificada o ampliada. De hecho, no tendría fin una discusión sobre una definición formal de calidad del software. Para los propósitos de este libro, la anterior definición sirve para hacer hincapié en tres puntos importantes:
1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.
Tecnicas de Prueba del Software
Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pueden costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos.
Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.
Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores.
Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.
Principios de las pruebas.
Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.
A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos.Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.
El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente.
Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero.No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.
Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Por «mas eficaces» queremos referirnos a pruebas con la más alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las razones que se expusieron anteriormente, el ingeniero del software que creó el sistema no es el más adecuado para llevar a cabo las pruebas para el software.
Facilidad de prueba.
En circunstancias ideales, un ingeniero del software diseña un programa de computadora, un sistema o un producto con la «facilidad de prueba» en mente. Esto permite a los encargados de las pruebas diseñar casos de prueba más fácilmente. Pero, ¿qué es la facilidad de prueba?
La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos.
Existen, de hecho, métricas que podrían usarse para medir la facilidad de prueba en la mayoría de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. También es empleada por los militares para indicar lo fácil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que «facilidad de prueba del software». La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.
Operatividad. «Cuanto mejor funcione, más eficientemente se puede probar.»El sistema tiene pocos errores (los errores añaden sobrecarga de análisis y de generación de informes al proceso de prueba).
Ningún error bloquea la ejecución de las pruebas.El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).
Observabilidad. «Lo que ves es lo que pruebas.».Se genera una salida distinta para cada entrada.Los estados y variables del sistema están visibles o se pueden consultar durante la ejecución.
Los estados y variables anteriores del sistema están visibles o se pueden consultar (por ejemplo, registros de transacción).
Todos los factores que afectan a los resultados están visibles.Un resultado incorrecto se identifica fácilmente.
Los errores internos se detectan automáticamente a través de mecanismos de auto-comprobación.
Se informa automáticamente de los errores internos.El código fuente es accesible.
Controlabilidad. «Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.»
Todos los resultados posibles se pueden generar a través de alguna combinación de entrada.Todo el código es ejecutable a través de alguna combinación de entrada.El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software.Los formatos de las entradas y los resultados son consistentes y estructurados.Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.
Capacidad de descomposición. «Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. »
El sistema software está construido con módulos independientes.Los módulos del software se pueden probar independientem
Simplicidad. «Cuanto menos haya que probar, más rápidamente podremos probarlo.»
Simplicidad funcional (por ejemplo, el conjunto de características es el mínimo necesario para cumplir los requisitos).
Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos).
Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento).
Estabilidad. «Cuanto menos cambios, menos interrupciones a las pruebas.»
Los cambios del software son infrecuentes.
Los cambios del software están controlados.
Los cambios del software no invalidan las pruebas existentes.
El software se recupera bien de los fallos.
Facilidad de comprensión. «Cuanta más información tengamos, más inteligentes serán las pruebas.»
El diseño se ha entendido perfectamente.
Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente.
Se han comunicado los cambias del diseño.
La documentación técnica es instantáneamente accesible.
La documentación técnica está bien organizada.
La documentación técnica es específica y detallada.
La documentación técnica es exacta.
Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.
Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores.
Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.
Principios de las pruebas.
Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.
A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos.Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.
El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente.
Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero.No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.
Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Por «mas eficaces» queremos referirnos a pruebas con la más alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las razones que se expusieron anteriormente, el ingeniero del software que creó el sistema no es el más adecuado para llevar a cabo las pruebas para el software.
Facilidad de prueba.
En circunstancias ideales, un ingeniero del software diseña un programa de computadora, un sistema o un producto con la «facilidad de prueba» en mente. Esto permite a los encargados de las pruebas diseñar casos de prueba más fácilmente. Pero, ¿qué es la facilidad de prueba?
La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos.
Existen, de hecho, métricas que podrían usarse para medir la facilidad de prueba en la mayoría de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. También es empleada por los militares para indicar lo fácil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que «facilidad de prueba del software». La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.
Operatividad. «Cuanto mejor funcione, más eficientemente se puede probar.»El sistema tiene pocos errores (los errores añaden sobrecarga de análisis y de generación de informes al proceso de prueba).
Ningún error bloquea la ejecución de las pruebas.El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).
Observabilidad. «Lo que ves es lo que pruebas.».Se genera una salida distinta para cada entrada.Los estados y variables del sistema están visibles o se pueden consultar durante la ejecución.
Los estados y variables anteriores del sistema están visibles o se pueden consultar (por ejemplo, registros de transacción).
Todos los factores que afectan a los resultados están visibles.Un resultado incorrecto se identifica fácilmente.
Los errores internos se detectan automáticamente a través de mecanismos de auto-comprobación.
Se informa automáticamente de los errores internos.El código fuente es accesible.
Controlabilidad. «Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.»
Todos los resultados posibles se pueden generar a través de alguna combinación de entrada.Todo el código es ejecutable a través de alguna combinación de entrada.El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software.Los formatos de las entradas y los resultados son consistentes y estructurados.Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.
Capacidad de descomposición. «Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. »
El sistema software está construido con módulos independientes.Los módulos del software se pueden probar independientem
Simplicidad. «Cuanto menos haya que probar, más rápidamente podremos probarlo.»
Simplicidad funcional (por ejemplo, el conjunto de características es el mínimo necesario para cumplir los requisitos).
Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos).
Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento).
Estabilidad. «Cuanto menos cambios, menos interrupciones a las pruebas.»
Los cambios del software son infrecuentes.
Los cambios del software están controlados.
Los cambios del software no invalidan las pruebas existentes.
El software se recupera bien de los fallos.
Facilidad de comprensión. «Cuanta más información tengamos, más inteligentes serán las pruebas.»
El diseño se ha entendido perfectamente.
Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente.
Se han comunicado los cambias del diseño.
La documentación técnica es instantáneamente accesible.
La documentación técnica está bien organizada.
La documentación técnica es específica y detallada.
La documentación técnica es exacta.
miércoles, 23 de julio de 2008
Estrategias De Prueba Del Software.
Estrategias De Prueba Del Software.
Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.Las características generales son:La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
La prueba y la depuración son actividades diferentes.
Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
· Planificación de las pruebas.
· Diseño de las pruebas.
· Implementación de las pruebas.
· Ejecución de las pruebas.
· Evaluación de las pruebas.
Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:
· Plan de Pruebas.
· Casos de Prueba.· Informe de evaluación de Pruebas.
· Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.
Los participantes responsables de las realizar las actividades y los productos de desarrollo del software son:
· Diseñador de pruebas: Es responsable de la planificación, diseño, implementación y evaluación de las pruebas. Esto conlleva generar el plan de pruebas y modelo de pruebas, implementar los casos de prueba y evaluar los resultados de las pruebas. Los diseñadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparación y evaluación de las mismas.· Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integración y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecución, recuperar los errores y garantizar los resultados de las pruebas.Durante la fase de Inicio puede hacerse parte de la planificación inicial de las pruebas cuando se define el ámbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre todo cuando un producto de desarrollo software es sometido a pruebas de integración y de sistema. Esto quiere decir que la realización de pruebas se centra en las fases de Elaboración, cuando se prueba la línea base ejecutable de la arquitectura, y de construcción, cuando el grueso del sistema está implementado. Durante la fase de Transición el centro se desplaza hacia la corrección de defectos durante los primeros usos y a las pruebas de regresión.Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cómo probar los primeros productos de desarrollo software pueden ser utilizadas también como casos de prueba de regresión que especifican cómo llevar a cabo las pruebas de regresión sobre los productos de desarrollo software siguientes. El número de pruebas de regresión necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las últimas iteraciones requerirán un gran esfuerzo en pruebas de regresión. Es natural, por tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, aunque el modelo de pruebas cambia constantemente debido a:· La eliminación de casos de prueba obsoletos.· El refinamiento de algunos casos de prueba en casos de prueba de regresión.· La creación de nuevos casos de prueba para cada nuevo producto de desarrollo de software.La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.
Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.Las características generales son:La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
La prueba y la depuración son actividades diferentes.
Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
· Planificación de las pruebas.
· Diseño de las pruebas.
· Implementación de las pruebas.
· Ejecución de las pruebas.
· Evaluación de las pruebas.
Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:
· Plan de Pruebas.
· Casos de Prueba.· Informe de evaluación de Pruebas.
· Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.
Los participantes responsables de las realizar las actividades y los productos de desarrollo del software son:
· Diseñador de pruebas: Es responsable de la planificación, diseño, implementación y evaluación de las pruebas. Esto conlleva generar el plan de pruebas y modelo de pruebas, implementar los casos de prueba y evaluar los resultados de las pruebas. Los diseñadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparación y evaluación de las mismas.· Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integración y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecución, recuperar los errores y garantizar los resultados de las pruebas.Durante la fase de Inicio puede hacerse parte de la planificación inicial de las pruebas cuando se define el ámbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre todo cuando un producto de desarrollo software es sometido a pruebas de integración y de sistema. Esto quiere decir que la realización de pruebas se centra en las fases de Elaboración, cuando se prueba la línea base ejecutable de la arquitectura, y de construcción, cuando el grueso del sistema está implementado. Durante la fase de Transición el centro se desplaza hacia la corrección de defectos durante los primeros usos y a las pruebas de regresión.Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cómo probar los primeros productos de desarrollo software pueden ser utilizadas también como casos de prueba de regresión que especifican cómo llevar a cabo las pruebas de regresión sobre los productos de desarrollo software siguientes. El número de pruebas de regresión necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las últimas iteraciones requerirán un gran esfuerzo en pruebas de regresión. Es natural, por tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, aunque el modelo de pruebas cambia constantemente debido a:· La eliminación de casos de prueba obsoletos.· El refinamiento de algunos casos de prueba en casos de prueba de regresión.· La creación de nuevos casos de prueba para cada nuevo producto de desarrollo de software.La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.
Gestion De La Configuracion Del Software.
Gestion De La Configuracion Del Software.
El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores.
La gestión de configuración del software (GCS) es una actividad de autoprotección que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aquellos que puedan estar interesados.
Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina sólo cuando el software queda fuera de la circulación.
El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías: (1) programas de computadora (tanto en forma de código fuente como ejecutable), (2) documentos que describen los programas de computadora (tanto técnicos como de usuario) y (3) datos (contenidos en el programa o externos a él). Los elementos que componen toda la información producida como parte del proceso de ingeniería del software se denominan colectivamente configuración del software.
A medida que progresa el proceso del software, el número de elementos de configuración del software
(ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía de información. Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable -el cambio-. El cambio se puede producir en cualquier momento y por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [BERSO] establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.
¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios:
Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales;Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora;Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software;Restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto.
La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.
La gestión de configuración del software es un elemento importante de garantía de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS también es responsable de la identificación de ECSs individuales y de las distintas versiones del software, de las auditorias de la configuración del software para asegurar que se desarrollan adecuadamente y de la generación de informes sobre todos los cambios realizados en la configuración.
El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores.
La gestión de configuración del software (GCS) es una actividad de autoprotección que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aquellos que puedan estar interesados.
Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina sólo cuando el software queda fuera de la circulación.
El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías: (1) programas de computadora (tanto en forma de código fuente como ejecutable), (2) documentos que describen los programas de computadora (tanto técnicos como de usuario) y (3) datos (contenidos en el programa o externos a él). Los elementos que componen toda la información producida como parte del proceso de ingeniería del software se denominan colectivamente configuración del software.
A medida que progresa el proceso del software, el número de elementos de configuración del software
(ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía de información. Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable -el cambio-. El cambio se puede producir en cualquier momento y por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [BERSO] establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.
¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios:
Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales;Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora;Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software;Restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto.
La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.
La gestión de configuración del software es un elemento importante de garantía de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS también es responsable de la identificación de ECSs individuales y de las distintas versiones del software, de las auditorias de la configuración del software para asegurar que se desarrollan adecuadamente y de la generación de informes sobre todos los cambios realizados en la configuración.
Diseño De Interfaz Del Usuario.
Diseño De Interfaz Del Usuario.
El plano de una casa (su diseño arquitectónico) no está completo sin la representación de puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora. Puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora.
El plano de una casa (su diseño arquitectónico) no está completo sin la representación de puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora. Puertas, ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» del software informático es lo que constituye el diseño de la interfaz de usuario. El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los componentes del software; (2) el diseño de las interfaces entre el software y los otros productores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora.
Analisis De Requisitos Del Sistema Del Software.
Analisis De Requisitos Del Sistema Del Software.
El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.
Inicio del proceso.
La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener expectativas radicalmente diferentes): los dos están deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un éxito.Técnicas para facilitar las especificaciones de una aplicación.Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este método no funciona muy bien. Abundan los malentendidos, se omite información importante y nunca se establece una buena relación de trabajo.
El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.
Inicio del proceso.
La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener expectativas radicalmente diferentes): los dos están deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un éxito.Técnicas para facilitar las especificaciones de una aplicación.Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este método no funciona muy bien. Abundan los malentendidos, se omite información importante y nunca se establece una buena relación de trabajo.
Ingenieria De Sistema De Computadora.
Ingenieria De Sistema De Computadora.
HACE casi 500 años, Maquiavelo dijo: “no hay nada más difícil de llevar a cabo, más peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción de un nuevo orden de cosas”. Durante los Últimos 50 años, los sistemas basados en computadora han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avances desde que habló Maquiavelo, sus palabras siguen sonando a verdad. La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información. El proceso de ingeniería de sistemas es denominado ingeniería de procesos de negocio cuando el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniería de producto. Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desarrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de aplicación diferente, ambas intentan poner al software en su contexto.
La palabra sistema es posiblemente el término más usado y abusado del léxico técnico. Hablamos de sistemas políticos y de sistemas educativos, de sistemas de aviación y de sistemas de fabricación, de sistemas bancarios y de sistemas de locomoción. La palabra no nos dice gran cosa. Usamos el adjetivo para describir el sistema y para entender el contexto en que se emplea. El diccionario Webster define sistema como:
1. un conjunto o disposición de cosas relacionadas de manera que forman una unidad o un todo orgánico;
2. Un conjunto de hechos, principios, reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes; 3. Un método o plan de clasificación o disposición; 4.una manera establecida de hacer algo; método; procedimiento ...
Se proporcionan cinco definiciones más en el diccionario, pero no se sugiere un sinónimo preciso. Sistema es una palabra especial. Tomando prestada la definición del diccionario Webster, definimos un sistema basado en computadora como:
Un conjunto o disposición de elementos que están organizados para realizar un objetivo preteñido procesando información. El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:
Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido. Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real.
Personas. Usuarios y operadores del hardware y software.
Documentación. Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema.
Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema.Los elementos se combinan de varias maneras para transformar la información. Por ejemplo, un departamento de marketing transforma la información bruta de ventas en un perfil del típico comprador del producto; un robot transforma un archivo de órdenes, que contiene instrucciones específicas, en un conjunto de señales de control que provocan alguna acción física específica. Tanto la creación de un sistema de información para asesorar a un departamento de marketing, como el software de control para el robot, requieren de la ingeniería de sistemas. Una característica complicada de los sistemas basados en computadora es que los elementos que componen un sistema pueden también representar un macroelemento de un sistema aún más grande. El macroelemento es un sistema basado en computadora que es parte de un sistema más grande basado en computadora. Por ejemplo, consideremos un «sistema de automatización de una fábrica» que es esencialmente una jerarquía de sistemas. En el nivel inferior de la jerarquía tenemos una máquina de control numérico, robots y dispositivos de entrada de información. Cada uno es un sistema basado en computadora por derecho propio. Los elementos de la máquina de control numérico incluyen hardware electrónico y electromecánico (por ejemplo, procesador y memoria, motores, sensores); software (para comunicaciones, control de la máquina e interpolación); personas (el operador de la máquina); una base de datos (el programa CN almacenado); documentación y procedimientos. Se podría aplicar una descomposición similar a los dispositivos de entrada de información y al robot. Todos son sistemas basados en computadora.
HACE casi 500 años, Maquiavelo dijo: “no hay nada más difícil de llevar a cabo, más peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción de un nuevo orden de cosas”. Durante los Últimos 50 años, los sistemas basados en computadora han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avances desde que habló Maquiavelo, sus palabras siguen sonando a verdad. La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información. El proceso de ingeniería de sistemas es denominado ingeniería de procesos de negocio cuando el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniería de producto. Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desarrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de aplicación diferente, ambas intentan poner al software en su contexto.
La palabra sistema es posiblemente el término más usado y abusado del léxico técnico. Hablamos de sistemas políticos y de sistemas educativos, de sistemas de aviación y de sistemas de fabricación, de sistemas bancarios y de sistemas de locomoción. La palabra no nos dice gran cosa. Usamos el adjetivo para describir el sistema y para entender el contexto en que se emplea. El diccionario Webster define sistema como:
1. un conjunto o disposición de cosas relacionadas de manera que forman una unidad o un todo orgánico;
2. Un conjunto de hechos, principios, reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes; 3. Un método o plan de clasificación o disposición; 4.una manera establecida de hacer algo; método; procedimiento ...
Se proporcionan cinco definiciones más en el diccionario, pero no se sugiere un sinónimo preciso. Sistema es una palabra especial. Tomando prestada la definición del diccionario Webster, definimos un sistema basado en computadora como:
Un conjunto o disposición de elementos que están organizados para realizar un objetivo preteñido procesando información. El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:
Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido. Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real.
Personas. Usuarios y operadores del hardware y software.
Documentación. Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema.
Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema.Los elementos se combinan de varias maneras para transformar la información. Por ejemplo, un departamento de marketing transforma la información bruta de ventas en un perfil del típico comprador del producto; un robot transforma un archivo de órdenes, que contiene instrucciones específicas, en un conjunto de señales de control que provocan alguna acción física específica. Tanto la creación de un sistema de información para asesorar a un departamento de marketing, como el software de control para el robot, requieren de la ingeniería de sistemas. Una característica complicada de los sistemas basados en computadora es que los elementos que componen un sistema pueden también representar un macroelemento de un sistema aún más grande. El macroelemento es un sistema basado en computadora que es parte de un sistema más grande basado en computadora. Por ejemplo, consideremos un «sistema de automatización de una fábrica» que es esencialmente una jerarquía de sistemas. En el nivel inferior de la jerarquía tenemos una máquina de control numérico, robots y dispositivos de entrada de información. Cada uno es un sistema basado en computadora por derecho propio. Los elementos de la máquina de control numérico incluyen hardware electrónico y electromecánico (por ejemplo, procesador y memoria, motores, sensores); software (para comunicaciones, control de la máquina e interpolación); personas (el operador de la máquina); una base de datos (el programa CN almacenado); documentación y procedimientos. Se podría aplicar una descomposición similar a los dispositivos de entrada de información y al robot. Todos son sistemas basados en computadora.
Fundamento De Analisis De Requisitos.
Fundamento De Analisis De Requisitos.
La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de aproximaciones contrastadas.
El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.
Por ejemplo, un mayorista de recambios de automóviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rápidamente el estado de un componente; (2) dos o tres días de media para actualizar un archivo a base de tarjetas; (3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista determina qué información va a producir el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del inventario.
Una vez evaluados los problemas actuales y la información deseada (entradas y salidas), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en el Plan del Software? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software para posteriores fases de desarrollo. A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones debe realizar el sistema, qué interfaces se definen y qué restricciones son aplicables?
Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.
La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de aproximaciones contrastadas.
El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.
El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema, (2) evaluación y síntesis, (3) modelado, (4) especificación y (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario.
La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.
Por ejemplo, un mayorista de recambios de automóviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rápidamente el estado de un componente; (2) dos o tres días de media para actualizar un archivo a base de tarjetas; (3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista determina qué información va a producir el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del inventario.
Una vez evaluados los problemas actuales y la información deseada (entradas y salidas), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en el Plan del Software? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software para posteriores fases de desarrollo. A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones debe realizar el sistema, qué interfaces se definen y qué restricciones son aplicables?
Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software.
viernes, 18 de julio de 2008
Acortando el Tiempo de Reacción
Acortando el Tiempo de Reacción
Cuando la localización de organización separada es ligada por las redes de ordenadores, el tiempo de reacción de organización sea más corto venido. Un acontecimiento en una localización se siente inmediatamente en una diversa localización. Como corporaciones separadas se liga electrónicamente, uno puede dar un pequen@o codazo el otro en la acción a la velocidad electrónica.
Un cliente compra el coche y la orden se transmite inmediatamente a la fábrica del coche y se absorbe en horario del produccion. Los acontecimientos en la bolsa destellan a la máquina lejana que hacen, compran, o venden cómputos y transmiten inmediatamente éstos al intercambio mundial. El cambio del comprador de la ropa sus patrones de compra en San Francisco, y la computadora de Benetton´s en Roma toman medidas inmediatas. Los almacenes de los efectos de escritorio reducen al mínimo su inventario porque tienen de computadora personal en línea a los libreros unidos, que garantiza a las órdenes de acometida a sus clientes en el día que él los coloca.
Las oportunidades en negocio esté de una duración más corta en que las corporaciones se ligan electrónicamente. Las ventajas de precio tienen que ser utilizadas inmediatamente. Para alcanzar control de inventario “justo a tiempo”, los surtidores tienen que entregar exactamente a cuando las computadoras les dicen. El correo electrónico y el facsímil dan interacciones inmediatas. Las computadoras generan ofertas de las ventas. La computadora en una corporación explora los vendedores posibles electrónicamente y la línea on- de las órdenes de la computadora en otra corporación.
El mundo del negocio ha acelerado debido a las computadoras, y acelerará mucho más cuando las computadoras en una corporación están generalmente en la comunicación electrónica con las computadoras en otras corporaciones. El mundo pronto será una tela compleja de computadoras intrincado que obran recíprocamente.
En tal mundo si una empresa tarda tres años para introducir nuevos procedimientos automatizados, estará en una desventaja seria comparada a las empresas que pueden introducir y modificar procedimientos rápidamente. Primera Boston en Nueva York en los mercados financieros turbulentos de la segunda mitad de los años 80 podía introducir los nuevos vehículos financieros más rápidamente que sus competidores porque construyó las aplicaciones informáticas con un generador de código dentro de un marco de ingeniería de información. El ciclo vital clásico del desarrollo es mortal en tal ambiente porque es tan lento, porque no puede integrar los sistemas separados, y porque construye a menudo los sistemas que no resuelven el negocio verdadero necesitan. En muchos casos tan poco es sabida por los programadores sobre los requisitos verdaderos del negocio que es solamente después que se ha construido el sistema que sale a luz la verdad.
Ovejas y cabras
No podemos diseñar y mantener la integración compleja de sistemas que es necesaria a menos que utilicemos las computadoras ellos mismos para esta tarea. Necesitamos la automatización de la automatización.
Hay hoy una diferencia extensa entre el diseño y el mantenimiento de los sistemas informáticos en las organizaciones mejores y peores de I.S. El mejor está utilizando la ingeniería de información disciplinada con las herramientas automatizadas. El peores están utilizando plantillas plásticas y están creando código de espagueti. El vendedor de la automatización de fábrica guarda lejos de las fábricas posteriores con las vides que cubren las paredes. El vendedor de las herramientas de la automatización de diseño guarda lejos de los departamentos de I.S. que no se han movido a la programación estructurada y diseña. La mejor mejora de las corporaciones a las herramientas más modernas; el peores se dejan al fester en su lío desorganizado.
Ingeniería rigurosa
La automatización afecta directamente a productividad. Los sistemas de información afectan directamente a la toma de decisión. Las computadoras y las redes están creciendo rápidamente en rentabilidad, y cada vez más en el futuro, las corporaciones con la automatización pobre y los sistemas de información no podrán competir. Mientras que los sistemas llegan a ser más complejos no pueden ser construidos sensible sin la ingeniería rigurosa. No podemos alcanzar la ingeniería rigurosa del software y de la información sin las herramientas automatizadas. Las herramientas para el diseño de sistemas se deben ligar a las herramientas para la generación del código. Los sistemas complejos necesitan las herramientas que facilitan el desarrollo iterativo o exploratorio. Las herramientas deben relacionarse con la pirámide entera de I.S. de modo que los sistemas por separado desarrollados liguen juntos y el control estratégico de sistemas sea práctico. Las herramientas deben hacer cumplir por completo la estructuración del código y de datos, con los redactores automatizados de modo que los sistemas sean tan fáciles de cambiar como sea posible. La trampa del mantenimiento es extremadamente dañosa; evita que una corporación cambie sus procedimientos para continuar con la evolución dinámica del negocio. Los sistemas de ingeniería Well- construidos con las herramientas automatizadas se diseñan para poderlos modificarse rápidamente. Las herramientas deben asegurar esta facilidad de la modificación.
Integración de sistemas
Los sistemas separados son desarrollados por los equipos separados. No es práctico para que un equipo construya todas las instalaciones de una corporación compleja. Para hacer que los sistemas por separado desarrollados trabajan juntas, las técnicas para la síntesis y la coordinación son necesarias. Una descripción de arriba hacia abajo es necesaria del proceso y de los datos se utilizan que. Los datos empleados por los sistemas por separado desarrollados deben ser compatible_ que debe ser derivada del mismo modelo de datos total. Desarrollando los sistemas separados usando la misma enciclopedia, la compatibilidad de datos puede ser alcanzada. Las características del análisis de la enciclopedia comprueban que los sistemas ligan juntos lógicamente. La ingeniería de información es alcanzada sintetizando el conocimiento de mucha gente, que puede ser dispersada extensamente a través de una empresa grande. La síntesis usando las herramientas automatizadas es esencial porque ninguna persona tiene más que una fracción del conocimiento requerido. Además de asegurar a compatibilidad lógica es necesario que los sistemas son compatibles desde el punto de vista del establecimiento de una red. El planeamiento estratégico total de la red corporativa es esencial.
El conocimiento de la empresa y de sus sistemas en la enciclopedia del IE crece constantemente. Sus ayudas la empresa integran sus numerosos sistemas por separado desarrollados. Ayuda a mejores sistemas y procedimientos del plan, y los gastos del acoplamiento I.S. a las metas de la gerencia superior. Ayuda a quitar insectos en diseño de sistema. Ayuda a planear la jerarquía de crítico. Ayuda a conseguir la información correcta a la gente adecuada para el control y la toma de decisión eficaces. La enciclopedia se convierte en un recurso corporativo cada vez más valioso.
Inteligencia artificial
En muchas organizaciones, las bases de datos bien pensadas se han convertido en un activo corporativo vital en el futuro, las base de conocimiento serán una maestría vital del activo incorporadas a base de conocimiento se refinan constantemente, como tiene en el uso pionero de Digital Equipment Corporation de los sistemas expertos afecta todo que toca. En la DEC se esperará que a todos los vendedores utilicen un sistema experto (XSEL) para configurar, tasar, y las órdenes que controlan. Los diseñadores de nuevas computadoras tienen paso de s en sus procedimientos, que es el adición del conocimiento necesario para configurar los nuevos sistemas al sistema experto de la configuración (XCON). Esta ayuda experta automatizada debe existir antes de que se anuncie la computadora. Los detalles de los sistemas expertos de las ventas van al sistema experto s de la fábrica, y las fechas de expedición del sistema experto del planeamiento de producción van a los vendedores. La base de conocimiento del planeamiento de producción alternadamente afecta al otro sistema experto de la fábrica. El conocimiento en tales sistemas acumula constantemente, aumentando una base automatizada de la maestría para dirigir la corporación tan eficientemente como sea posible. Estos sistemas expertos utilizan los datos que están en las bases de datos corporativas. La ingeniería cognitiva debe ser una extensión de la ingeniería de información.
Cuando la localización de organización separada es ligada por las redes de ordenadores, el tiempo de reacción de organización sea más corto venido. Un acontecimiento en una localización se siente inmediatamente en una diversa localización. Como corporaciones separadas se liga electrónicamente, uno puede dar un pequen@o codazo el otro en la acción a la velocidad electrónica.
Un cliente compra el coche y la orden se transmite inmediatamente a la fábrica del coche y se absorbe en horario del produccion. Los acontecimientos en la bolsa destellan a la máquina lejana que hacen, compran, o venden cómputos y transmiten inmediatamente éstos al intercambio mundial. El cambio del comprador de la ropa sus patrones de compra en San Francisco, y la computadora de Benetton´s en Roma toman medidas inmediatas. Los almacenes de los efectos de escritorio reducen al mínimo su inventario porque tienen de computadora personal en línea a los libreros unidos, que garantiza a las órdenes de acometida a sus clientes en el día que él los coloca.
Las oportunidades en negocio esté de una duración más corta en que las corporaciones se ligan electrónicamente. Las ventajas de precio tienen que ser utilizadas inmediatamente. Para alcanzar control de inventario “justo a tiempo”, los surtidores tienen que entregar exactamente a cuando las computadoras les dicen. El correo electrónico y el facsímil dan interacciones inmediatas. Las computadoras generan ofertas de las ventas. La computadora en una corporación explora los vendedores posibles electrónicamente y la línea on- de las órdenes de la computadora en otra corporación.
El mundo del negocio ha acelerado debido a las computadoras, y acelerará mucho más cuando las computadoras en una corporación están generalmente en la comunicación electrónica con las computadoras en otras corporaciones. El mundo pronto será una tela compleja de computadoras intrincado que obran recíprocamente.
En tal mundo si una empresa tarda tres años para introducir nuevos procedimientos automatizados, estará en una desventaja seria comparada a las empresas que pueden introducir y modificar procedimientos rápidamente. Primera Boston en Nueva York en los mercados financieros turbulentos de la segunda mitad de los años 80 podía introducir los nuevos vehículos financieros más rápidamente que sus competidores porque construyó las aplicaciones informáticas con un generador de código dentro de un marco de ingeniería de información. El ciclo vital clásico del desarrollo es mortal en tal ambiente porque es tan lento, porque no puede integrar los sistemas separados, y porque construye a menudo los sistemas que no resuelven el negocio verdadero necesitan. En muchos casos tan poco es sabida por los programadores sobre los requisitos verdaderos del negocio que es solamente después que se ha construido el sistema que sale a luz la verdad.
Ovejas y cabras
No podemos diseñar y mantener la integración compleja de sistemas que es necesaria a menos que utilicemos las computadoras ellos mismos para esta tarea. Necesitamos la automatización de la automatización.
Hay hoy una diferencia extensa entre el diseño y el mantenimiento de los sistemas informáticos en las organizaciones mejores y peores de I.S. El mejor está utilizando la ingeniería de información disciplinada con las herramientas automatizadas. El peores están utilizando plantillas plásticas y están creando código de espagueti. El vendedor de la automatización de fábrica guarda lejos de las fábricas posteriores con las vides que cubren las paredes. El vendedor de las herramientas de la automatización de diseño guarda lejos de los departamentos de I.S. que no se han movido a la programación estructurada y diseña. La mejor mejora de las corporaciones a las herramientas más modernas; el peores se dejan al fester en su lío desorganizado.
Ingeniería rigurosa
La automatización afecta directamente a productividad. Los sistemas de información afectan directamente a la toma de decisión. Las computadoras y las redes están creciendo rápidamente en rentabilidad, y cada vez más en el futuro, las corporaciones con la automatización pobre y los sistemas de información no podrán competir. Mientras que los sistemas llegan a ser más complejos no pueden ser construidos sensible sin la ingeniería rigurosa. No podemos alcanzar la ingeniería rigurosa del software y de la información sin las herramientas automatizadas. Las herramientas para el diseño de sistemas se deben ligar a las herramientas para la generación del código. Los sistemas complejos necesitan las herramientas que facilitan el desarrollo iterativo o exploratorio. Las herramientas deben relacionarse con la pirámide entera de I.S. de modo que los sistemas por separado desarrollados liguen juntos y el control estratégico de sistemas sea práctico. Las herramientas deben hacer cumplir por completo la estructuración del código y de datos, con los redactores automatizados de modo que los sistemas sean tan fáciles de cambiar como sea posible. La trampa del mantenimiento es extremadamente dañosa; evita que una corporación cambie sus procedimientos para continuar con la evolución dinámica del negocio. Los sistemas de ingeniería Well- construidos con las herramientas automatizadas se diseñan para poderlos modificarse rápidamente. Las herramientas deben asegurar esta facilidad de la modificación.
Integración de sistemas
Los sistemas separados son desarrollados por los equipos separados. No es práctico para que un equipo construya todas las instalaciones de una corporación compleja. Para hacer que los sistemas por separado desarrollados trabajan juntas, las técnicas para la síntesis y la coordinación son necesarias. Una descripción de arriba hacia abajo es necesaria del proceso y de los datos se utilizan que. Los datos empleados por los sistemas por separado desarrollados deben ser compatible_ que debe ser derivada del mismo modelo de datos total. Desarrollando los sistemas separados usando la misma enciclopedia, la compatibilidad de datos puede ser alcanzada. Las características del análisis de la enciclopedia comprueban que los sistemas ligan juntos lógicamente. La ingeniería de información es alcanzada sintetizando el conocimiento de mucha gente, que puede ser dispersada extensamente a través de una empresa grande. La síntesis usando las herramientas automatizadas es esencial porque ninguna persona tiene más que una fracción del conocimiento requerido. Además de asegurar a compatibilidad lógica es necesario que los sistemas son compatibles desde el punto de vista del establecimiento de una red. El planeamiento estratégico total de la red corporativa es esencial.
El conocimiento de la empresa y de sus sistemas en la enciclopedia del IE crece constantemente. Sus ayudas la empresa integran sus numerosos sistemas por separado desarrollados. Ayuda a mejores sistemas y procedimientos del plan, y los gastos del acoplamiento I.S. a las metas de la gerencia superior. Ayuda a quitar insectos en diseño de sistema. Ayuda a planear la jerarquía de crítico. Ayuda a conseguir la información correcta a la gente adecuada para el control y la toma de decisión eficaces. La enciclopedia se convierte en un recurso corporativo cada vez más valioso.
Inteligencia artificial
En muchas organizaciones, las bases de datos bien pensadas se han convertido en un activo corporativo vital en el futuro, las base de conocimiento serán una maestría vital del activo incorporadas a base de conocimiento se refinan constantemente, como tiene en el uso pionero de Digital Equipment Corporation de los sistemas expertos afecta todo que toca. En la DEC se esperará que a todos los vendedores utilicen un sistema experto (XSEL) para configurar, tasar, y las órdenes que controlan. Los diseñadores de nuevas computadoras tienen paso de s en sus procedimientos, que es el adición del conocimiento necesario para configurar los nuevos sistemas al sistema experto de la configuración (XCON). Esta ayuda experta automatizada debe existir antes de que se anuncie la computadora. Los detalles de los sistemas expertos de las ventas van al sistema experto s de la fábrica, y las fechas de expedición del sistema experto del planeamiento de producción van a los vendedores. La base de conocimiento del planeamiento de producción alternadamente afecta al otro sistema experto de la fábrica. El conocimiento en tales sistemas acumula constantemente, aumentando una base automatizada de la maestría para dirigir la corporación tan eficientemente como sea posible. Estos sistemas expertos utilizan los datos que están en las bases de datos corporativas. La ingeniería cognitiva debe ser una extensión de la ingeniería de información.
No hay nada más difícil de planificar, más dudoso de que sea exitoso, ni más peligroso que administrar la creación de un nievo sistema.
No hay nada más difícil de planificar, más dudoso de que sea exitoso, ni más peligroso que administrar la creación de un nievo sistema.
A menudo nosotros los Ing. En Sistemas y otros profesionales del área nos encontramos con grandes proyectos en las diferentes empresas, estos ´proyectos cada vez más extensos y ambiciosos pueden intimidarnos por su complejidad y gran cantidad de detalles a controlar, dichos proyectos son unos de los grandes temores por la difícil planificación que requieren, esto es un gran problema para los profesionales especialmente los que no tienen mucha experiencia en la ejecución y control de estos tipos de proyectos.
Algo que llena de intriga a los programadores y manejadores de proyectos es que si este a su conclusión será un proyecto exitoso, muchas veces nos hacemos esta pregunta, en ese sentido solo hay algo que pueda asegurar que el proyecto sea exitoso o no y esto es una buena planeación, tener los objetivos claros, saber lo que se desea y concentrarse en hacer todo lo establecido, siguiendo estas directrices la implementación de cualquier proyecto será exitoso.
Administrarla la creación de un nuevo sistema, yo no diría que es algo peligroso, si se conoce lo que se desea y se analiza y diseña bien todo lo referente a la creación del nuevo sistema. La implementación de un nuevo sistema es algo que puede intimidar a algunos profesionales pero siguiendo los pasos para la resolución de ese problema todo terminara y se implementara de una manera satisfactoria.
El establecimiento del título universitario del Ingeniero en informática, ha sido un paso súper importante en lo que es el desarrollo de los pueblos, las industrias y todo lo que necesita de tecnología, también ha servido durante todos estos años para el desarrollo de nuevas tecnologías y la implementación de estas tecnologías en las empresas. Desde este momento yo diría que se produjo una explosión en el mercado, implementando nuevas tecnologías y a los profesionales que las manejarían para aumentar la productividad de las empresas
A menudo nosotros los Ing. En Sistemas y otros profesionales del área nos encontramos con grandes proyectos en las diferentes empresas, estos ´proyectos cada vez más extensos y ambiciosos pueden intimidarnos por su complejidad y gran cantidad de detalles a controlar, dichos proyectos son unos de los grandes temores por la difícil planificación que requieren, esto es un gran problema para los profesionales especialmente los que no tienen mucha experiencia en la ejecución y control de estos tipos de proyectos.
Algo que llena de intriga a los programadores y manejadores de proyectos es que si este a su conclusión será un proyecto exitoso, muchas veces nos hacemos esta pregunta, en ese sentido solo hay algo que pueda asegurar que el proyecto sea exitoso o no y esto es una buena planeación, tener los objetivos claros, saber lo que se desea y concentrarse en hacer todo lo establecido, siguiendo estas directrices la implementación de cualquier proyecto será exitoso.
Administrarla la creación de un nuevo sistema, yo no diría que es algo peligroso, si se conoce lo que se desea y se analiza y diseña bien todo lo referente a la creación del nuevo sistema. La implementación de un nuevo sistema es algo que puede intimidar a algunos profesionales pero siguiendo los pasos para la resolución de ese problema todo terminara y se implementara de una manera satisfactoria.
El establecimiento del título universitario del Ingeniero en informática, ha sido un paso súper importante en lo que es el desarrollo de los pueblos, las industrias y todo lo que necesita de tecnología, también ha servido durante todos estos años para el desarrollo de nuevas tecnologías y la implementación de estas tecnologías en las empresas. Desde este momento yo diría que se produjo una explosión en el mercado, implementando nuevas tecnologías y a los profesionales que las manejarían para aumentar la productividad de las empresas
Terminos Informaticos
1- ¿Qué es Software?
Bajo esta definición, el concepto de software va más allá de los programas de cómputo en sus distintos estados: código fuente, binario o ejecutable; también su documentación, datos a procesar e información de usuario es parte del software: es decir, abarca todo lo intangible, todo lo “no físico” relacionado.
El término «software» fue usado por primera vez en este sentido por John W. Tukey en 1957. En las ciencias de la computación y la ingeniería de software, el software es toda la información procesada por los sistemas informáticos: programas y datos. El concepto de leer diferentes secuencias de instrucciones desde la memoria de un dispositivo para controlar los cálculos fue introducido por Charles Babbage como parte de su máquina diferencial. La teoría que forma la base de la mayor parte del software moderno fue propuesta por vez primera por Alan Turing en su ensayo de 1936, “Los números computables”, con una aplicación al problema de decisión.
2- Diferencias entre Programa y Software.
Programa es una secuencia de instrucciones que se le da a una computadora para que haga determinadas cosas, hay programas que van desde lo más simple hasta los muy complejos, un programa que te pregunte tu nombre y te dé una respuesta ya se puede considerar como programa. Y software es aquello que es intangible, lo que no puedes tocar, es la parte lógica de un programa, entre el software están videos, imágenes, sonidos, textos, bases de datos, etc.
3- Evolución del Programa.
Los programas de computación nacen en 1950 junto con el diseño de las primeras computadoras y estaban escritos en lenguaje de máquina. Es decir, estaban formados por una sucesión de instrucciones, cada una de las cuales era un grupo de 1’s y 0’s. El usuario codificaba estos 1’s y 0’s directamente usando interruptores pare codificar cada instrucción. Posteriormente, fue creada la primera máquina que habría de funcionar con un programa almacenado en 1943. Esta máquina recibió el nombre de EDSAC y fue fabricada en la Universidad de Cambridge. Sus autores Wilker, Wheeler y Gill fueron también los primeros en elaborar un texto de programación. Los programas almacenados diferían de los anteriores en que la sucesión de instrucciones se codificaban en una cinta de papel mediante perforaciones. La cinta era leída por la computadora y de esta manera si el usuario deseaba ejecutar el programa una segunda vez, no tenia que codificarla nuevamente, sino que solo alimentaba la cinta.
El codificar en lenguaje de maquina resultaba difícil para el usuario; así que se comenzaron a desarrollar programas en lenguaje de máquina que interpretaban instrucciones inteligibles pare la mayoría de los usuarios y que eran traducidos a lenguajes de máquina. A este tipo de programas se les denomino lenguajes de “alto nivel”, mismos que subsisten hasta la fecha.
En 1951, surge la primera computadora disponible comercialmente a gran escala, la UNIVAC I, la cual estaba diseñada para ser fácilmente programada en su propio código. Era una maquina decimal alfanumérica con instrucciones mnemónicas fáciles de recordar y utilizar. La aparición de las computadoras en el ámbito comercial es crucial en la historia de los lenguajes, ya que entonces se vuelve importante la facilidad de programación y la posibilidad de transportar programas. A partir de aquí comienzan a surgir una serie de lenguajes de programación cada vez más lejanos al lenguaje de máquina y más cercanos al usuario.
Por ejemplo, la UNIVAC I de 1951 tiene los lenguajes AT3 y B-0 que tuvieron gran influencia en el diseño de otros lenguajes de maquina más avanzados como son el FORTRAN y el COBOL respectivamente, ambos de difusión mundial.
En la segunda mitad de la década de los 50’s y basados en las ideas de los lenguajes anteriores, surge con gran rapidez la primera generación de lenguajes de “alto nivel”, mismos que siguen vigentes veinticinco años después. Dichos lenguajes son:
1. FORTRAN (FORmula TRANslating) resultado de un proyecto encabezado por John Backus y que llevo 25 años hombre esfuerzo. Se utiliza principalmente pare resolver problemas científicos y técnicos. En ocasiones, sin embargo, se emplea en aplicaciones comerciales.
2. ALGOL (ALGOrithmic Language; lenguaje algorítmico) se desarrollo con el propósito de contaron un lenguaje común pare diversas computadoras. Este lenguaje se parece al FORTRAN y es de aplicación particular en los problemas matemáticos y numéricos, Este lenguaje es popular en las universidades, y en la actualidad es utilizado en los Estados Unidos pare fines pedagógicos y la comunicación de algoritmos.
3. COBOL (COmmon Business Oriented Language) el propósito de este lenguaje es el de contar con un lenguaje que resultara común pare las diversas computadoras en el mercado para el procesamiento de información comercial. Es un lenguaje que se utiliza principalmente para la programación de problemas de proceso de datos comerciales, por su naturaleza descriptiva y su adaptabilidad pare resolver los problemas de proceso de ficheros que entraña el proceso de datos comerciales.
4- Lenguaje Maquina.
Los circuitos microprogramables son sistemas digitales, lo que significa que trabajan con dos únicos niveles de tensión. Dichos niveles, por abstracción, se simbolizan con el cero, 0, y el uno, 1, por eso el lenguaje de máquina sólo utiliza dichos signos. Esto permite el empleo de las teorías del álgebra booleana y del sistema binario en el diseño de este tipo de circuitos y en su programación.
Una visión típica de la arquitectura de computadores como una serie de capas de abstracción: hardware, firmware, ensamblador, kernel, sistema operativo y aplicaciones
Claude Elwood Shannon, en su Analysis of Relay and Switching Circuits, y con sus experiencias en redes de conmutación, sentó las bases para la aplicación del álgebra de Boole a las redes de conmutación.
Una red de conmutación es un circuito de interruptores eléctricos que al cumplir ciertas combinaciones booleanas con las variables de entrada, define el estado de la salida. Este concepto es el núcleo de las puertas lógicas, las cuales son, por su parte, los ladrillos con que se construyen sistemas lógicos cada vez más complejos.
Shannon utilizaba el relé como dispositivo físico de conmutación en sus redes. El relé, a igual que una lámpara eléctrica, posee dos estados: 1 ó 0, esto es, está activado, encendida, o está desactivado, apagada.
5- Lenguaje Ensamblador.
El lenguaje ensamblador es un tipo de lenguaje de bajo nivel utilizado para escribir programas informáticos, y constituye la representación más directa del código máquina específico para cada arquitectura de computadoras legible por un programador.
Fue usado ampliamente en el pasado para el desarrollo de software, pero actualmente sólo se utiliza en contadas ocasiones, especialmente cuando se requiere la manipulación directa del hardware o se pretenden rendimientos inusuales de los equipos.
6- Lenguaje de Programación.
Un lenguaje de programación es un lenguaje que puede ser utilizado para controlar el comportamiento de una máquina, particularmente una computadora. Consiste en un conjunto de símbolos y reglas sintácticas y semánticas que definen su estructura y el significado de sus elementos y expresiones.
Aunque muchas veces se usa lenguaje de programación y lenguaje informático como si fuesen sinónimos, no tiene por qué ser así, ya que los lenguajes informáticos engloban a los lenguajes de programación y a otros más, como, por ejemplo, el HTML (lenguaje para el marcado de páginas web).
Un lenguaje de programación permite a uno o más programadores especificar de manera precisa: sobre qué datos una computadora debe operar, cómo deben ser estos almacenados, transmitidos y qué acciones debe tomar bajo una variada gama de circunstancias. Todo esto, a través de un lenguaje que intenta estar relativamente próximo al lenguaje humano o natural, tal como sucede con el lenguaje Léxico. Una característica relevante de los lenguajes de programación es precisamente que más de un programador puedan tener un conjunto común de instrucciones que puedan ser comprendidas entre ellos para realizar la construcción del programa de forma colaborativa.
7- Herramientas de Programación.
Las herramientas de programación, son aquellas que permiten realizar aplicativos, programas, rutinas, utilitarios y sistemas para que la parte física del computador u ordenador, funcione y pueda producir resultados.
Hoy día existen múltiples herramientas de programación en el mercado, tanto para analistas expertos como para analistas inexpertos.
8- Lenguaje Orientado a Objetos.
Se le llama así a cualquier lenguaje de programación que implemente los conceptos definidos por la programación orientada a objetos.
Cabe notar que los conceptos definidos en la programación orientada a objetos no son una condición sino que son para definir que un lenguaje es orientado a objetos. Existen conceptos que pueden estar ausentes en un lenguaje dado y sin embargo, no invalidar su definición como lenguaje orientado a objetos.
Quizás las condiciones mínimas necesarias las provee el formalismo que modeliza mejor las propiedades de un sistema orientado a objetos: los tipos de datos abstractos.
9- Encapsulación.
En programación modular, y más específicamente en programación orientada a objetos, se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.
Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
De esta forma el usuario de la clase puede obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado se evita que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.
10- Análisis y Diseño Orientado a Objetos.
Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.
En éste método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por ejemplo, el lenguaje únificado de modelado (UML). ADOO aplica técnicas de modelado de objetos para analizar los requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño más modernas son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.
El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño orientado a objetos.
11- Interfaz del Usuario.
La interfaz de usuario es la forma en que los usuarios pueden comunicarse con una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo. Sus principales funciones son:
Manipulación de archivos y directorios
Herramientas de desarrollo de aplicaciones
Comunicación con otros sistemas
Información de estado
Configuración de la propia interfaz y entorno
Intercambio de datos entre aplicaciones
Control de acceso
Sistema de ayuda interactivo.
12- Lenguaje Poliformico.
El polimorfismo es la presencia de dos o más variantes heredables para una misma característica que coexisten dentro de una población. Esta característica puede ser apreciable tanto a nivel morfológico, como el número de cerdas en Drosophila melanogaster (mosca común de la fruta), como a nivel molecular, tal es el caso de las alozimas.
13- Polimorfismo.
Polimorfismo es la presencia de dos o más variantes heredables para una misma característica que coexisten dentro de una población. Esta característica puede ser apreciable tanto a nivel morfológico, como el número de cerdas en Drosophila melanogaster (mosca común de la fruta), como a nivel molecular, tal es el caso de las alozimas.
14- Gestión de Proyectos Orientados a Objetos.
Las técnicas modernas de gestión de proyectos de software se pueden dividir e as siguientes actividades:
• Establecimiento de un marco de proceso común para el proyecto.
• Uso del marco y de métricas históricas.
• Especificación de productos de trabajo y avances.
• Definición de puntos de comprobación.
• Gestión de los cambios que ocurren invariablemente.
• Seguimiento.
Para aplicar estas actividades hay que tomar en cuenta que todas hay que enfocarlas usando un modelo propio.
Marco de proceso común para OO. (Orientado a objeto)
Este tópico define un enfoque organizativo para el desarrollo y mantenimiento del software. Identifica el paradigma de Ing. De software aplicado para construir y mantener software. Tiene la cualidad de ser adaptable, de forma que cumpla con las necesidades individuales del equipo de proyecto.
Para el desarrollo de proyectos de esta naturaleza no se pueden aplicar modelos lineales (ciclo de vida), sino que es necesario aplicar un modelo que contemple un desarrollo iterativo. Iterativo significa que el software evolucione a través de un número de ciclos. El software OO debe ser evolutivo por naturaleza. Existen autores que sugieren un modelo recursivo/paralelo para el desarrollo orientado a objeto.
15- Productividad de Programación.
La productividad de programación se refiera al rendimiento de un programador en un proyecto de programación, este tipo de productividad se mide por las horas que el programador aplica a la programación del proyecto, comparado por la evolución del programa en sí.
16- Tiempo de Programación.
El tiempo de desarrollo del proyecto es indefinido, puede mantenerse durante el período que se considere necesario, la ventaja que tiene es que se pueden involucrar distintas comunidades donantes y receptoras, el objetivo inicial sería lograr la capacitación de los mediadores en los aspectos técnicos necesarios para llegar a una instalación de computadores con software Libre.
17- Cantidad de Código.
Es la medición del tamaño en líneas de código, generalmente se utiliza en programación lineal y en lenguajes de programación antiguos.
18- Protocolo.
Protocolo de red o también Protocolo de Comunicación es el conjunto de reglas que especifican el intercambio de datos u órdenes durante la comunicación entre las entidades que forman parte de una red.
19- ¿Quién es George Boole?
George Boole, (2 de noviembre de 1815 - 8 de diciembre de 1864) fue un matemático y filósofo irlandés.
Como inventor del álgebra de Boole, la base de la aritmética computacional moderna, Boole es considerado como uno de los fundadores del campo de las Ciencias de la Computación. En 1854 publicó “An Investigation of the Laws of Thought” en él desarrollaba un sistema de reglas que le permitía expresar, manipular y simplificar, problemas lógicos y filosóficos cuyos argumentos admiten dos estados (verdadero o falso) por procedimientos matemáticos.
20- ¿Quién es Norbert Wiener?
Norbert Wiener (26 de noviembre de 1894, Columbia, Missouri - 18 de marzo de 1964, Estocolmo, Suecia) fue un matemático estadounidense, conocido como el fundador de la cibernética. Acuñó el término en su libro Cibernética o el control y comunicación en animales y máquinas, publicado en 1948.
Su padre, Leo Wiener, fue profesor en lenguas eslavas en la Universidad de Harvard. Norbert se educó en casa hasta los siete años, edad a la que empezó a asistir al colegio, pero durante poco tiempo. Siguió con sus estudios en casa hasta que volvió al colegio en 1903, graduándose en el instituto de Ayer en 1906.
En septiembre de 1906, a la edad de once años, ingresó en la Universidad Tufts para estudiar matemáticas. Se licenció en 1909 y entró en Harvard. En Harvard estudió zoología, pero en 1910 se trasladó a la Universidad de Cornell para empezar estudios superiores en filosofía. Volvió a Harvard al año siguiente para continuar sus estudios de filosofía. Wiener obtuvo el doctorado por Harvard en 1912 con una tesis que versaba sobre lógica matemática.
21- API
Una API (del inglés Application Programming Interface - Interfaz de Programación de Aplicaciones) es el conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
22- Aristóteles
Aristóteles (en griego clásico Ἀριστοτέλης Aristotélēs; Estagira, Macedonia 384 a. C. – Calcis Eubea, Grecia 322 a. C.) es uno de los más grandes filósofos de la antigüedad y acaso de la historia de la filosofía occidental. Fue precursor de la anatomía y la biología y un creador de la taxonomía.
23- Lógica
La Lógica es un término que deriva del griego “Λογικός” (logikê-logikós), que a su vez es “λόγος” (logos), que significa razón.1
Se considera que Aristóteles fue el que fundó la Lógica como Propedéutica, herramienta básica para todas las Ciencias.2
La Lógica es una ciencia formal. Esto quiere decir que no tiene contenido, porque estudia las formas válidas de inferencia.3
La lógica tradicional se basaba en el silogismo como razonamiento basado en el juicio categórico aristotélico. Hoy día la lógica utiliza como unidad básica la proposición y las reglas de inferencia en la argumentación discursiva.4
24- Lógica de Aristóteles.
Como su nombre lo indica, el padre de la lógica aristotélica es el filosofo griego Aristóteles; primer pensador en formalizar el sistema lógico de tan acertada manera que sus propuestas han trascendido hasta nuestros días. Aristóteles planteó sus ideas en varias obras, para difundir su conocimiento sobre las leyes del razonamiento, argumentando que estas eran vitales para adentrarse en el mundo de la filosofía.
La lógica aristotélica supone que la mente reproduce sólo la realidad, la existencia de las cosas tal y como son, por ello es una ciencia objetiva que se dedica a estudiar conceptos, desglosándolos en predicables y predicamentos. La lógica analiza juicios y formas de razonamiento y su manera de expresar resultados es el silogismo o razonamiento deductivo categórico. Concepto: Este representa un objeto en la mente del hombre de manera que no pueda ser afectado por los sentidos, la memoria o la mente. Un concepto tiene comprensión (características del objeto) y extensión (hace alusión la cantidad de sujetos a los que el concepto puede aplicarse). Cucharón (siglo III d.c.), en los que se clasifican los conceptos estableciendo entre ellos una relación de jerarquía y subordinación, de mayor a menor extensión.
La que es conocida como lógica clásica (o tradicional) fue enunciada primeramente por Aristóteles, quien elaboró leyes para un correcto razonamiento silogístico. Un silogismo es una proposición hecha de una de estas cuatro afirmaciones posibles: “Todo A es B” (universal afirmativo), “Nada de A es B” (universal negativo), “Algo de A es B” (particular afirmativo) o “Algo de A no es B” (particular negativo). Las letras sustituyen a palabras comunes como “perro”, “animal de cuatro patas” o ‘cosa viviente’, llamadas “términos” del silogismo. Un silogismo bien formulado consta de dos premisas y una conclusión, debiendo tener cada premisa un término en común con la conclusión y un segundo término relacionado con la otra premisa. En lógica clásica se formulan reglas por las que todos los silogismos bien construidos se identifican como formas válidas o no válidas de argumentación.
25- Lógica Difusa
La lógica borrosa o difusa se basa en lo relativo de lo observado. Este tipo de lógica toma dos valores aleatorios, pero contextualizados y referidos entre sí. Así, por ejemplo, una persona que mida 2 metros es claramente una persona alta, si previamente se ha tomado el valor de persona baja y se ha establecido en 1 metro. Ambos valores están contextualizados a personas y referidos a una medida métrica lineal.
26- OLAP
OLAP es el acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la llamada Inteligencia empresarial (o Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de Datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares.
La razón de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos relacional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es buena en un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un modelo mejor para búsquedas, aunque peor desde el punto de vista operativo, es una base de datos multidimensional.
La principal característica que potencia a OLAP, es que es lo más rápido a la hora de ejecutar sentencias SQL de tipo SELECT, en contraposición con OLTP que es la mejor opción para operaciones de tipo INSERT, UPDATE Y DELETE.
27- Trivial
En matemática, el término trivial se usa frecuentemente para los objetos (por ejemplo, cuerpos o espacios topológicos) que tienen una estructura muy simple. Para los no matemáticos, son a veces más difíciles de visualizar o entender que otros objetos más complicados.
Algunos ejemplos incluyen:
conjunto vacío - el conjunto que no contiene elementos
grupo trivial - el grupo matemático que contiene solo el elemento identidad
También, trivial se refiere a soluciones (a una ecuación) que tienen una estructura muy simple, pero que por completitud no pueden ser ignoradas. Estas soluciones se denominan soluciones triviales. Por ejemplo, considérese la ecuación diferencial.
28- Digital
Se dice que una señal es digital cuando las magnitudes de la misma se representan a través de valores discretos en lugar de variables continuas. Por ejemplo, el interruptor de la luz sólo puede tomar dos valores o estados: abierto o cerrado, o la misma lámpara: encendida o apagada (véase circuito de conmutación).
Los sistemas digitales, como por ejemplo el ordenador, usan lógica de dos estados representados por dos niveles de tensión eléctrica, uno alto, H y otro bajo, L (de High y Low, respectivamente, en inglés). Por abstracción, dichos estados se sustituyen por ceros y unos, lo que facilita la aplicación de la lógica y la aritmética binaria. Si el nivel alto se representa por 1 y el bajo por 0, se habla de lógica positiva y en caso contrario de lógica negativa.
Cabe mencionar que además de los niveles, en una señal digital están las transiciones de alto a bajo o de bajo a alto, denominadas flanco de subida o de bajada, respectivamente. En la siguiente figura se muestra una señal digital donde se identifican los niveles y los flancos.
Señal digital: 1) Nivel bajo, 2) Nivel alto, 3) Flanco de subida y 4) Flanco de bajada.
Es conveniente aclarar que, a pesar de que en los ejemplos señalados el término digital se ha relacionado siempre con dispositivos binarios, no significa que digital y binario sean términos intercambiables. Por ejemplo, si nos fijamos en el código Morse, veremos que en él se utilizan, para el envío de mensajes por telégrafo eléctrico, cinco estados digitales que son:
punto, raya, espacio corto (entre letras), espacio medio (entre palabras) y espacio largo (entre frases)
Referido a un aparato o instrumento de medida, decimos que es digital cuando el resultado de la medida se representa en un visualizador mediante números (dígitos) en lugar de hacerlo mediante la posición de una aguja, o cualquier otro indicador, en una escala
29- Análogo
Se refiere a las magnitudes o valores que varían con el tiempo en forma continua (distancia, temperatura, velocidad, voltaje, frecuencia, amplitud, etc.) y pueden representarse en forma de ondas.
Las computadoras emplean lo digital y, por lo tanto, si entra información analógica, se debe convertir; este es el caso de la conexión a Internet por Dial up, donde un módem convierte la señal analógica (el sonido) en digital.
30- Neurona.
La neurona es uno de los tipos de las células nerviosas que se encuentran por todo el cuerpo; son el elemento fundamental de la estructura del sistema nervioso. Son células excitables especializadas en la recepción de estímulos y conducción del impulso nervioso. Una neurona está formada por un cuerpo celular y diferentes prolongaciones. Está encargada principalmente de trasmitir el flujo nervioso. Un cerebro humano contiene aproximadamente 100.000 millones1 de neuronas (1011). Las neuronas se hallan en el encéfalo, la médula espinal y los ganglios nerviosos; forman una red de contacto en todo el cuerpo. Se unen entre ellas a través de una unión discontinua llamada sinapsis. Si dicha sinapsis ocurre por contacto físico se trata de una sinapsis eléctrica, y si es a través de una hendidura, se le llama sinapsis química.
31- Claude Elwood Slawnon
Claude Elwood Shannon (30 de abril de 1916, Michigan - 24 de febrero de 2001), ingeniero eléctrico y matemático, recordado como “el padre de la teoría de la información”.
32- Algebra Booleana.
Álgebra de Boole (también llamada Retículas booleanas) en informática y matemática, son estructuras algebraicas que rigorizan las operaciones lógicas Y, O y NO, así como el conjunto de operaciones unión, intersección y complemento.
Se denomina así en honor a George Boole, matemático inglés que fue el primero en definirla como parte de un sistema lógico a mediados del siglo XIX. Específicamente, el álgebra de Boole fue un intento de utilizar las técnicas algebraicas para tratar expresiones de la lógica proposicional. En la actualidad, el álgebra de Boole se aplica de forma generalizada en el ámbito del diseño electrónico. Claude Shannon fue el primero en aplicarla en el diseño de circuitos de conmutación eléctrica biestables, en 1938.
33- Lenguaje de Alto Nivel
Los lenguajes de programación de alto nivel se caracterizan por expresar los algoritmos de una manera adecuada a la capacidad cognitiva humana, en lugar de a la capacidad ejecutora de las máquinas. En los primeros lenguajes de alto nivel la limitación era que se orientaban a un área específica y sus instrucciones requerían de una sintaxis predefinida. Se clasifican como lenguajes procedimentales. Otra limitación de los lenguajes de alto nivel es que se requiere de ciertos conocimientos de programación para realizar las secuencias de instrucciones lógicas. Los lenguajes de muy alto nivel se crearon para que el usuario común pudiese solucionar tal problema de procesamiento de datos de una manera más fácil y rápida.
La programación en un lenguaje de bajo nivel como el lenguaje de la máquina o el lenguaje simbólico tiene ciertas ventajas:
Mayor adaptación al equipo.
Posibilidad de obtener la máxima velocidad con mínimo uso de memoria.
Pero también tiene importantes inconvenientes:
Imposibilidad de escribir código independiente de la máquina.
Mayor dificultad en la programación y en la comprensión de los programas.
Por esta razón, a finales de los años 1950 surgió un nuevo tipo de lenguajes de programación que evitaba estos inconvenientes, a costa de ceder un poco en las ventajas. Estos lenguajes se llaman “de tercera generación” o “de alto nivel”, en contraposición a los “de bajo nivel” o “de nivel próximo a la máquina”.
34- Lenguaje de Bajo Nivel.
Un lenguaje de programación de bajo nivel es el que proporciona poca o ninguna abstracción del microprocesador de un ordenador. Consecuentemente es fácilmente trasladado a lenguaje de máquina.
La palabra “bajo” no implica que el lenguaje sea inferior a un lenguaje de alto nivel; se refiere a la reducida abstracción entre el lenguaje y el hardware.
35- Ciencia Real
Una prueba segura de cualquier afirmación verdaderamente científica es su capacidad de predecir el futuro: de decir qué sucederá bajo circunstancias dadas. Cuando se la somete a medidas válidas y objetivas de predicción, la pseudociencia no obtiene mejores resultados que la mera adivinación, en contraste con la ciencia real. Piense en la historia tal como la predijo la astrología, comparada con la gravedad y la certeza experimental y verificable de la ley del cuadrado inverso.
36- Ciencia Fisión
La ciencia ficción (también fue conocida en su origen como literatura de anticipación) es la denominación popular con que se conoce a uno de los géneros derivados de la literatura de ficción (junto con la literatura fantástica y la narrativa de terror). Nacida como subgénero literario distinguido en la década de 1920 (aunque hay obras reconocibles muy anteriores) y exportada posteriormente a otros medios, el más notable de ellos el cinematográfico, gozó de un gran auge en la segunda mitad del siglo XX debido al interés popular acerca del futuro que despertó el espectacular avance tanto científico como tecnológico alcanzado durante esos años.
Entre los estudiosos del género no se ha podido llegar a un consenso amplio sobre una definición formal, siendo éste un tema de gran controversia. En general se considera ciencia ficción a los cuentos o historias que versan sobre el impacto que producen los avances científicos, tecnológicos, sociales o culturales, presentes o futuros, sobre la sociedad o los individuos.
37- Inteligencia Artificial
Se denomina inteligencia artificial a la rama de la informática que desarrolla procesos que imitan a la inteligencia de los seres vivos. La principal aplicación de esta ciencia es la creación de máquinas para la automatización de tareas que requieran un comportamiento inteligente.
Algunos ejemplos se encuentran en el área de control de sistemas, planificación automática, la habilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento de escritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmente son parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usado en gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador y otros videojuegos.
El matemático sudafricano, Seymour Papert, es considerado pionero en esta ciencia
38- Programas Tradicionales
Los programas tradicionales se denominan a todas aquellas aplicaciones que los usuarios normales utilizan, tales como paquete para oficinas, email, en general todo lo que se denomina programas de utilería.
39- Generación de los Programas.
Los equipos (el hardware) han pasado por cuatro generaciones, de las que las tres primeras (ordenadores con válvulas, transistores y circuitos integrados) están muy claras, la cuarta (circuitos integrados a gran escala) es más discutible.
Algo parecido ha ocurrido con la programación de los ordenadores (el software), que se realiza en lenguajes que suelen clasificarse en cinco generaciones, de las que las tres primeras son evidentes, mientras no todo el mundo está de acuerdo en las otras dos. Estas generaciones no coincidieron exactamente en el tiempo con las de hardware, pero sí de forma aproximada, y son las siguientes:
Primera generación Los primeros ordenadores se programaban directamente en código binario, que puede representarse mediante secuencias de ceros y unos sistema binario. Cada modelo de ordenador tiene su propio código, por esa razón se llama lenguaje de máquina.
Segunda generación Los lenguajes simbólicos, asimismo propios de la máquina, simplifican la escritura de las instrucciones y las hacen más legibles.
Tercera generación Los lenguajes de alto nivel sustituyen las instrucciones simbólicas por códigos independientes de la máquina, parecidas al lenguaje humano o al de las Matemáticas.
Cuarta generación Se ha dado este nombre a ciertas herramientas que permiten construir aplicaciones sencillas combinando piezas prefabricadas. Hoy se piensa que estas herramientas no son, propiamente hablando, lenguajes. Algunos proponen reservar el nombre de cuarta generación para la programación orientada a objetos.
Quinta generación Se llama así a veces a los lenguajes de la inteligencia artificial, aunque con el fracaso del proyecto japonés de la quinta generación el nombre ha caído en desuso.
40- Que es Case.
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.
41- Programas Compactadores.
Son programas que permiten comprimir o compactar un archivo y/o descomprimirlo o descompactarlo . El objeto de estos programas es reducir el tamaño de los archivos que se transmiten o se transportan en disquetes, al reducir su tamaño se reduce también el tiempo de conexión. Este software se basa en el algoritmo de compresión ZIP, que ya se usaba antes del windows con programas como PKZIP y PKUNZIP.
Muchos archivos en la Web están Compactados. Y es Fundamental para el acarreo de grandes volúmenes de información que pueden viajar “zipeados” en lugar de ocupar demasiado tamaño en su formato original. Entre las ventajas que posee esta la de ser posible su uso como herramienta para ejecutar y realizar BACKUPS de archivos y productos, la opción de utilizar claves de seguridad para que solo quienes estén autorizados puedan descompactar y acceder a los datos comprimidos.
42- Lenguaje SQL
El Lenguaje de consulta estructurado (SQL [/esekuele/ en español, /ɛskjuːˈɛl / en inglés] Structured Query Language ) es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas. Una de sus características es el manejo del álgebra y el cálculo relacional permitiendo lanzar consultas con el fin de recuperar -de una forma sencilla- información de interés de una base de datos, así como también hacer cambios sobre la misma. Es un lenguaje de cuarta generación (4GL).
Interface
Como principio, el Diccionario de la Real Academia de la Lengua Española define interfaz como una palabra derivada del término inglés “interface”(superficie de contacto) y la define de la siguiente manera: 1. f. Inform. Conexión física y funcional entre dos aparatos o sistemas independientes.
Por confusión con el término anglosajón “interfazear”, “interfasear”, “interfacear” suele utilizarse en muchos manuales de motherboard, pero no debe tomarse esto como correcto ya que existe una palabra muy simple de referencia de este artículo.
43- ABI
En los programas informáticos, un interfaz de aplicación binaria (ABI) describe el bajo nivel de interfaz entre un programa de aplicación y el sistema operativo, o la interfaz entre una aplicación y sus bibliotecas, o que entre los componentes de una aplicación. Un ABI es similar a una interfaz de programación de aplicaciones (API), sin embargo, este último define una interfaz de código fuente. [1] En pocas palabras, abis permitir la compatibilidad binaria, mientras que las API de permitir la compatibilidad de código fuente.
44- Loger Susana Catherine
45- OLP
OLP (Open License Program) lo cual es un programa de licenciamiento por volumen en el cual una empresa puede adquirir sus licencias con un solo contrato, entre estos programas esta el Open Business y Open Value.
46- OLTP
OLTP (Online Transaction Processing) es un tipo de procesamiento de transacciones a través de una red de computadoras. Algunos tipos de aplicaciones OLTP pueden ser banca electrónica, procesamiento de pedidos o comercio electrónico. Es un programa que facilita y administra aplicaciones transaccionales, usualmente para data entry y transacciones en empresas, incluyendo bancos, aerolíneas, etc.
47- Data Ware House
Es un repositorio de datos de muy fácil acceso, alimentado de numerosas fuentes, transformadas en grupos de información sobre temas específicos de negocios, para permitir nuevas consultas, análisis, reportador y decisiones.
48- Data Monts
Los Data Marts son las bases de datos locales o departamentales basadas en subconjuntos de la información contenida en el Data Warehouse central o maestro.
49- Lisp
Lisp es el segundo lenguaje de programación, después de Fortran, de alto nivel. Lisp es de tipo declarativo y fue creado en 1958 por John McCarthy y sus colaboradores en el MIT.
Bajo esta definición, el concepto de software va más allá de los programas de cómputo en sus distintos estados: código fuente, binario o ejecutable; también su documentación, datos a procesar e información de usuario es parte del software: es decir, abarca todo lo intangible, todo lo “no físico” relacionado.
El término «software» fue usado por primera vez en este sentido por John W. Tukey en 1957. En las ciencias de la computación y la ingeniería de software, el software es toda la información procesada por los sistemas informáticos: programas y datos. El concepto de leer diferentes secuencias de instrucciones desde la memoria de un dispositivo para controlar los cálculos fue introducido por Charles Babbage como parte de su máquina diferencial. La teoría que forma la base de la mayor parte del software moderno fue propuesta por vez primera por Alan Turing en su ensayo de 1936, “Los números computables”, con una aplicación al problema de decisión.
2- Diferencias entre Programa y Software.
Programa es una secuencia de instrucciones que se le da a una computadora para que haga determinadas cosas, hay programas que van desde lo más simple hasta los muy complejos, un programa que te pregunte tu nombre y te dé una respuesta ya se puede considerar como programa. Y software es aquello que es intangible, lo que no puedes tocar, es la parte lógica de un programa, entre el software están videos, imágenes, sonidos, textos, bases de datos, etc.
3- Evolución del Programa.
Los programas de computación nacen en 1950 junto con el diseño de las primeras computadoras y estaban escritos en lenguaje de máquina. Es decir, estaban formados por una sucesión de instrucciones, cada una de las cuales era un grupo de 1’s y 0’s. El usuario codificaba estos 1’s y 0’s directamente usando interruptores pare codificar cada instrucción. Posteriormente, fue creada la primera máquina que habría de funcionar con un programa almacenado en 1943. Esta máquina recibió el nombre de EDSAC y fue fabricada en la Universidad de Cambridge. Sus autores Wilker, Wheeler y Gill fueron también los primeros en elaborar un texto de programación. Los programas almacenados diferían de los anteriores en que la sucesión de instrucciones se codificaban en una cinta de papel mediante perforaciones. La cinta era leída por la computadora y de esta manera si el usuario deseaba ejecutar el programa una segunda vez, no tenia que codificarla nuevamente, sino que solo alimentaba la cinta.
El codificar en lenguaje de maquina resultaba difícil para el usuario; así que se comenzaron a desarrollar programas en lenguaje de máquina que interpretaban instrucciones inteligibles pare la mayoría de los usuarios y que eran traducidos a lenguajes de máquina. A este tipo de programas se les denomino lenguajes de “alto nivel”, mismos que subsisten hasta la fecha.
En 1951, surge la primera computadora disponible comercialmente a gran escala, la UNIVAC I, la cual estaba diseñada para ser fácilmente programada en su propio código. Era una maquina decimal alfanumérica con instrucciones mnemónicas fáciles de recordar y utilizar. La aparición de las computadoras en el ámbito comercial es crucial en la historia de los lenguajes, ya que entonces se vuelve importante la facilidad de programación y la posibilidad de transportar programas. A partir de aquí comienzan a surgir una serie de lenguajes de programación cada vez más lejanos al lenguaje de máquina y más cercanos al usuario.
Por ejemplo, la UNIVAC I de 1951 tiene los lenguajes AT3 y B-0 que tuvieron gran influencia en el diseño de otros lenguajes de maquina más avanzados como son el FORTRAN y el COBOL respectivamente, ambos de difusión mundial.
En la segunda mitad de la década de los 50’s y basados en las ideas de los lenguajes anteriores, surge con gran rapidez la primera generación de lenguajes de “alto nivel”, mismos que siguen vigentes veinticinco años después. Dichos lenguajes son:
1. FORTRAN (FORmula TRANslating) resultado de un proyecto encabezado por John Backus y que llevo 25 años hombre esfuerzo. Se utiliza principalmente pare resolver problemas científicos y técnicos. En ocasiones, sin embargo, se emplea en aplicaciones comerciales.
2. ALGOL (ALGOrithmic Language; lenguaje algorítmico) se desarrollo con el propósito de contaron un lenguaje común pare diversas computadoras. Este lenguaje se parece al FORTRAN y es de aplicación particular en los problemas matemáticos y numéricos, Este lenguaje es popular en las universidades, y en la actualidad es utilizado en los Estados Unidos pare fines pedagógicos y la comunicación de algoritmos.
3. COBOL (COmmon Business Oriented Language) el propósito de este lenguaje es el de contar con un lenguaje que resultara común pare las diversas computadoras en el mercado para el procesamiento de información comercial. Es un lenguaje que se utiliza principalmente para la programación de problemas de proceso de datos comerciales, por su naturaleza descriptiva y su adaptabilidad pare resolver los problemas de proceso de ficheros que entraña el proceso de datos comerciales.
4- Lenguaje Maquina.
Los circuitos microprogramables son sistemas digitales, lo que significa que trabajan con dos únicos niveles de tensión. Dichos niveles, por abstracción, se simbolizan con el cero, 0, y el uno, 1, por eso el lenguaje de máquina sólo utiliza dichos signos. Esto permite el empleo de las teorías del álgebra booleana y del sistema binario en el diseño de este tipo de circuitos y en su programación.
Una visión típica de la arquitectura de computadores como una serie de capas de abstracción: hardware, firmware, ensamblador, kernel, sistema operativo y aplicaciones
Claude Elwood Shannon, en su Analysis of Relay and Switching Circuits, y con sus experiencias en redes de conmutación, sentó las bases para la aplicación del álgebra de Boole a las redes de conmutación.
Una red de conmutación es un circuito de interruptores eléctricos que al cumplir ciertas combinaciones booleanas con las variables de entrada, define el estado de la salida. Este concepto es el núcleo de las puertas lógicas, las cuales son, por su parte, los ladrillos con que se construyen sistemas lógicos cada vez más complejos.
Shannon utilizaba el relé como dispositivo físico de conmutación en sus redes. El relé, a igual que una lámpara eléctrica, posee dos estados: 1 ó 0, esto es, está activado, encendida, o está desactivado, apagada.
5- Lenguaje Ensamblador.
El lenguaje ensamblador es un tipo de lenguaje de bajo nivel utilizado para escribir programas informáticos, y constituye la representación más directa del código máquina específico para cada arquitectura de computadoras legible por un programador.
Fue usado ampliamente en el pasado para el desarrollo de software, pero actualmente sólo se utiliza en contadas ocasiones, especialmente cuando se requiere la manipulación directa del hardware o se pretenden rendimientos inusuales de los equipos.
6- Lenguaje de Programación.
Un lenguaje de programación es un lenguaje que puede ser utilizado para controlar el comportamiento de una máquina, particularmente una computadora. Consiste en un conjunto de símbolos y reglas sintácticas y semánticas que definen su estructura y el significado de sus elementos y expresiones.
Aunque muchas veces se usa lenguaje de programación y lenguaje informático como si fuesen sinónimos, no tiene por qué ser así, ya que los lenguajes informáticos engloban a los lenguajes de programación y a otros más, como, por ejemplo, el HTML (lenguaje para el marcado de páginas web).
Un lenguaje de programación permite a uno o más programadores especificar de manera precisa: sobre qué datos una computadora debe operar, cómo deben ser estos almacenados, transmitidos y qué acciones debe tomar bajo una variada gama de circunstancias. Todo esto, a través de un lenguaje que intenta estar relativamente próximo al lenguaje humano o natural, tal como sucede con el lenguaje Léxico. Una característica relevante de los lenguajes de programación es precisamente que más de un programador puedan tener un conjunto común de instrucciones que puedan ser comprendidas entre ellos para realizar la construcción del programa de forma colaborativa.
7- Herramientas de Programación.
Las herramientas de programación, son aquellas que permiten realizar aplicativos, programas, rutinas, utilitarios y sistemas para que la parte física del computador u ordenador, funcione y pueda producir resultados.
Hoy día existen múltiples herramientas de programación en el mercado, tanto para analistas expertos como para analistas inexpertos.
8- Lenguaje Orientado a Objetos.
Se le llama así a cualquier lenguaje de programación que implemente los conceptos definidos por la programación orientada a objetos.
Cabe notar que los conceptos definidos en la programación orientada a objetos no son una condición sino que son para definir que un lenguaje es orientado a objetos. Existen conceptos que pueden estar ausentes en un lenguaje dado y sin embargo, no invalidar su definición como lenguaje orientado a objetos.
Quizás las condiciones mínimas necesarias las provee el formalismo que modeliza mejor las propiedades de un sistema orientado a objetos: los tipos de datos abstractos.
9- Encapsulación.
En programación modular, y más específicamente en programación orientada a objetos, se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.
Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
De esta forma el usuario de la clase puede obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado se evita que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.
10- Análisis y Diseño Orientado a Objetos.
Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.
En éste método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por ejemplo, el lenguaje únificado de modelado (UML). ADOO aplica técnicas de modelado de objetos para analizar los requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño más modernas son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.
El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño orientado a objetos.
11- Interfaz del Usuario.
La interfaz de usuario es la forma en que los usuarios pueden comunicarse con una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo. Sus principales funciones son:
Manipulación de archivos y directorios
Herramientas de desarrollo de aplicaciones
Comunicación con otros sistemas
Información de estado
Configuración de la propia interfaz y entorno
Intercambio de datos entre aplicaciones
Control de acceso
Sistema de ayuda interactivo.
12- Lenguaje Poliformico.
El polimorfismo es la presencia de dos o más variantes heredables para una misma característica que coexisten dentro de una población. Esta característica puede ser apreciable tanto a nivel morfológico, como el número de cerdas en Drosophila melanogaster (mosca común de la fruta), como a nivel molecular, tal es el caso de las alozimas.
13- Polimorfismo.
Polimorfismo es la presencia de dos o más variantes heredables para una misma característica que coexisten dentro de una población. Esta característica puede ser apreciable tanto a nivel morfológico, como el número de cerdas en Drosophila melanogaster (mosca común de la fruta), como a nivel molecular, tal es el caso de las alozimas.
14- Gestión de Proyectos Orientados a Objetos.
Las técnicas modernas de gestión de proyectos de software se pueden dividir e as siguientes actividades:
• Establecimiento de un marco de proceso común para el proyecto.
• Uso del marco y de métricas históricas.
• Especificación de productos de trabajo y avances.
• Definición de puntos de comprobación.
• Gestión de los cambios que ocurren invariablemente.
• Seguimiento.
Para aplicar estas actividades hay que tomar en cuenta que todas hay que enfocarlas usando un modelo propio.
Marco de proceso común para OO. (Orientado a objeto)
Este tópico define un enfoque organizativo para el desarrollo y mantenimiento del software. Identifica el paradigma de Ing. De software aplicado para construir y mantener software. Tiene la cualidad de ser adaptable, de forma que cumpla con las necesidades individuales del equipo de proyecto.
Para el desarrollo de proyectos de esta naturaleza no se pueden aplicar modelos lineales (ciclo de vida), sino que es necesario aplicar un modelo que contemple un desarrollo iterativo. Iterativo significa que el software evolucione a través de un número de ciclos. El software OO debe ser evolutivo por naturaleza. Existen autores que sugieren un modelo recursivo/paralelo para el desarrollo orientado a objeto.
15- Productividad de Programación.
La productividad de programación se refiera al rendimiento de un programador en un proyecto de programación, este tipo de productividad se mide por las horas que el programador aplica a la programación del proyecto, comparado por la evolución del programa en sí.
16- Tiempo de Programación.
El tiempo de desarrollo del proyecto es indefinido, puede mantenerse durante el período que se considere necesario, la ventaja que tiene es que se pueden involucrar distintas comunidades donantes y receptoras, el objetivo inicial sería lograr la capacitación de los mediadores en los aspectos técnicos necesarios para llegar a una instalación de computadores con software Libre.
17- Cantidad de Código.
Es la medición del tamaño en líneas de código, generalmente se utiliza en programación lineal y en lenguajes de programación antiguos.
18- Protocolo.
Protocolo de red o también Protocolo de Comunicación es el conjunto de reglas que especifican el intercambio de datos u órdenes durante la comunicación entre las entidades que forman parte de una red.
19- ¿Quién es George Boole?
George Boole, (2 de noviembre de 1815 - 8 de diciembre de 1864) fue un matemático y filósofo irlandés.
Como inventor del álgebra de Boole, la base de la aritmética computacional moderna, Boole es considerado como uno de los fundadores del campo de las Ciencias de la Computación. En 1854 publicó “An Investigation of the Laws of Thought” en él desarrollaba un sistema de reglas que le permitía expresar, manipular y simplificar, problemas lógicos y filosóficos cuyos argumentos admiten dos estados (verdadero o falso) por procedimientos matemáticos.
20- ¿Quién es Norbert Wiener?
Norbert Wiener (26 de noviembre de 1894, Columbia, Missouri - 18 de marzo de 1964, Estocolmo, Suecia) fue un matemático estadounidense, conocido como el fundador de la cibernética. Acuñó el término en su libro Cibernética o el control y comunicación en animales y máquinas, publicado en 1948.
Su padre, Leo Wiener, fue profesor en lenguas eslavas en la Universidad de Harvard. Norbert se educó en casa hasta los siete años, edad a la que empezó a asistir al colegio, pero durante poco tiempo. Siguió con sus estudios en casa hasta que volvió al colegio en 1903, graduándose en el instituto de Ayer en 1906.
En septiembre de 1906, a la edad de once años, ingresó en la Universidad Tufts para estudiar matemáticas. Se licenció en 1909 y entró en Harvard. En Harvard estudió zoología, pero en 1910 se trasladó a la Universidad de Cornell para empezar estudios superiores en filosofía. Volvió a Harvard al año siguiente para continuar sus estudios de filosofía. Wiener obtuvo el doctorado por Harvard en 1912 con una tesis que versaba sobre lógica matemática.
21- API
Una API (del inglés Application Programming Interface - Interfaz de Programación de Aplicaciones) es el conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
22- Aristóteles
Aristóteles (en griego clásico Ἀριστοτέλης Aristotélēs; Estagira, Macedonia 384 a. C. – Calcis Eubea, Grecia 322 a. C.) es uno de los más grandes filósofos de la antigüedad y acaso de la historia de la filosofía occidental. Fue precursor de la anatomía y la biología y un creador de la taxonomía.
23- Lógica
La Lógica es un término que deriva del griego “Λογικός” (logikê-logikós), que a su vez es “λόγος” (logos), que significa razón.1
Se considera que Aristóteles fue el que fundó la Lógica como Propedéutica, herramienta básica para todas las Ciencias.2
La Lógica es una ciencia formal. Esto quiere decir que no tiene contenido, porque estudia las formas válidas de inferencia.3
La lógica tradicional se basaba en el silogismo como razonamiento basado en el juicio categórico aristotélico. Hoy día la lógica utiliza como unidad básica la proposición y las reglas de inferencia en la argumentación discursiva.4
24- Lógica de Aristóteles.
Como su nombre lo indica, el padre de la lógica aristotélica es el filosofo griego Aristóteles; primer pensador en formalizar el sistema lógico de tan acertada manera que sus propuestas han trascendido hasta nuestros días. Aristóteles planteó sus ideas en varias obras, para difundir su conocimiento sobre las leyes del razonamiento, argumentando que estas eran vitales para adentrarse en el mundo de la filosofía.
La lógica aristotélica supone que la mente reproduce sólo la realidad, la existencia de las cosas tal y como son, por ello es una ciencia objetiva que se dedica a estudiar conceptos, desglosándolos en predicables y predicamentos. La lógica analiza juicios y formas de razonamiento y su manera de expresar resultados es el silogismo o razonamiento deductivo categórico. Concepto: Este representa un objeto en la mente del hombre de manera que no pueda ser afectado por los sentidos, la memoria o la mente. Un concepto tiene comprensión (características del objeto) y extensión (hace alusión la cantidad de sujetos a los que el concepto puede aplicarse). Cucharón (siglo III d.c.), en los que se clasifican los conceptos estableciendo entre ellos una relación de jerarquía y subordinación, de mayor a menor extensión.
La que es conocida como lógica clásica (o tradicional) fue enunciada primeramente por Aristóteles, quien elaboró leyes para un correcto razonamiento silogístico. Un silogismo es una proposición hecha de una de estas cuatro afirmaciones posibles: “Todo A es B” (universal afirmativo), “Nada de A es B” (universal negativo), “Algo de A es B” (particular afirmativo) o “Algo de A no es B” (particular negativo). Las letras sustituyen a palabras comunes como “perro”, “animal de cuatro patas” o ‘cosa viviente’, llamadas “términos” del silogismo. Un silogismo bien formulado consta de dos premisas y una conclusión, debiendo tener cada premisa un término en común con la conclusión y un segundo término relacionado con la otra premisa. En lógica clásica se formulan reglas por las que todos los silogismos bien construidos se identifican como formas válidas o no válidas de argumentación.
25- Lógica Difusa
La lógica borrosa o difusa se basa en lo relativo de lo observado. Este tipo de lógica toma dos valores aleatorios, pero contextualizados y referidos entre sí. Así, por ejemplo, una persona que mida 2 metros es claramente una persona alta, si previamente se ha tomado el valor de persona baja y se ha establecido en 1 metro. Ambos valores están contextualizados a personas y referidos a una medida métrica lineal.
26- OLAP
OLAP es el acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la llamada Inteligencia empresarial (o Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de Datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares.
La razón de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos relacional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es buena en un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un modelo mejor para búsquedas, aunque peor desde el punto de vista operativo, es una base de datos multidimensional.
La principal característica que potencia a OLAP, es que es lo más rápido a la hora de ejecutar sentencias SQL de tipo SELECT, en contraposición con OLTP que es la mejor opción para operaciones de tipo INSERT, UPDATE Y DELETE.
27- Trivial
En matemática, el término trivial se usa frecuentemente para los objetos (por ejemplo, cuerpos o espacios topológicos) que tienen una estructura muy simple. Para los no matemáticos, son a veces más difíciles de visualizar o entender que otros objetos más complicados.
Algunos ejemplos incluyen:
conjunto vacío - el conjunto que no contiene elementos
grupo trivial - el grupo matemático que contiene solo el elemento identidad
También, trivial se refiere a soluciones (a una ecuación) que tienen una estructura muy simple, pero que por completitud no pueden ser ignoradas. Estas soluciones se denominan soluciones triviales. Por ejemplo, considérese la ecuación diferencial.
28- Digital
Se dice que una señal es digital cuando las magnitudes de la misma se representan a través de valores discretos en lugar de variables continuas. Por ejemplo, el interruptor de la luz sólo puede tomar dos valores o estados: abierto o cerrado, o la misma lámpara: encendida o apagada (véase circuito de conmutación).
Los sistemas digitales, como por ejemplo el ordenador, usan lógica de dos estados representados por dos niveles de tensión eléctrica, uno alto, H y otro bajo, L (de High y Low, respectivamente, en inglés). Por abstracción, dichos estados se sustituyen por ceros y unos, lo que facilita la aplicación de la lógica y la aritmética binaria. Si el nivel alto se representa por 1 y el bajo por 0, se habla de lógica positiva y en caso contrario de lógica negativa.
Cabe mencionar que además de los niveles, en una señal digital están las transiciones de alto a bajo o de bajo a alto, denominadas flanco de subida o de bajada, respectivamente. En la siguiente figura se muestra una señal digital donde se identifican los niveles y los flancos.
Señal digital: 1) Nivel bajo, 2) Nivel alto, 3) Flanco de subida y 4) Flanco de bajada.
Es conveniente aclarar que, a pesar de que en los ejemplos señalados el término digital se ha relacionado siempre con dispositivos binarios, no significa que digital y binario sean términos intercambiables. Por ejemplo, si nos fijamos en el código Morse, veremos que en él se utilizan, para el envío de mensajes por telégrafo eléctrico, cinco estados digitales que son:
punto, raya, espacio corto (entre letras), espacio medio (entre palabras) y espacio largo (entre frases)
Referido a un aparato o instrumento de medida, decimos que es digital cuando el resultado de la medida se representa en un visualizador mediante números (dígitos) en lugar de hacerlo mediante la posición de una aguja, o cualquier otro indicador, en una escala
29- Análogo
Se refiere a las magnitudes o valores que varían con el tiempo en forma continua (distancia, temperatura, velocidad, voltaje, frecuencia, amplitud, etc.) y pueden representarse en forma de ondas.
Las computadoras emplean lo digital y, por lo tanto, si entra información analógica, se debe convertir; este es el caso de la conexión a Internet por Dial up, donde un módem convierte la señal analógica (el sonido) en digital.
30- Neurona.
La neurona es uno de los tipos de las células nerviosas que se encuentran por todo el cuerpo; son el elemento fundamental de la estructura del sistema nervioso. Son células excitables especializadas en la recepción de estímulos y conducción del impulso nervioso. Una neurona está formada por un cuerpo celular y diferentes prolongaciones. Está encargada principalmente de trasmitir el flujo nervioso. Un cerebro humano contiene aproximadamente 100.000 millones1 de neuronas (1011). Las neuronas se hallan en el encéfalo, la médula espinal y los ganglios nerviosos; forman una red de contacto en todo el cuerpo. Se unen entre ellas a través de una unión discontinua llamada sinapsis. Si dicha sinapsis ocurre por contacto físico se trata de una sinapsis eléctrica, y si es a través de una hendidura, se le llama sinapsis química.
31- Claude Elwood Slawnon
Claude Elwood Shannon (30 de abril de 1916, Michigan - 24 de febrero de 2001), ingeniero eléctrico y matemático, recordado como “el padre de la teoría de la información”.
32- Algebra Booleana.
Álgebra de Boole (también llamada Retículas booleanas) en informática y matemática, son estructuras algebraicas que rigorizan las operaciones lógicas Y, O y NO, así como el conjunto de operaciones unión, intersección y complemento.
Se denomina así en honor a George Boole, matemático inglés que fue el primero en definirla como parte de un sistema lógico a mediados del siglo XIX. Específicamente, el álgebra de Boole fue un intento de utilizar las técnicas algebraicas para tratar expresiones de la lógica proposicional. En la actualidad, el álgebra de Boole se aplica de forma generalizada en el ámbito del diseño electrónico. Claude Shannon fue el primero en aplicarla en el diseño de circuitos de conmutación eléctrica biestables, en 1938.
33- Lenguaje de Alto Nivel
Los lenguajes de programación de alto nivel se caracterizan por expresar los algoritmos de una manera adecuada a la capacidad cognitiva humana, en lugar de a la capacidad ejecutora de las máquinas. En los primeros lenguajes de alto nivel la limitación era que se orientaban a un área específica y sus instrucciones requerían de una sintaxis predefinida. Se clasifican como lenguajes procedimentales. Otra limitación de los lenguajes de alto nivel es que se requiere de ciertos conocimientos de programación para realizar las secuencias de instrucciones lógicas. Los lenguajes de muy alto nivel se crearon para que el usuario común pudiese solucionar tal problema de procesamiento de datos de una manera más fácil y rápida.
La programación en un lenguaje de bajo nivel como el lenguaje de la máquina o el lenguaje simbólico tiene ciertas ventajas:
Mayor adaptación al equipo.
Posibilidad de obtener la máxima velocidad con mínimo uso de memoria.
Pero también tiene importantes inconvenientes:
Imposibilidad de escribir código independiente de la máquina.
Mayor dificultad en la programación y en la comprensión de los programas.
Por esta razón, a finales de los años 1950 surgió un nuevo tipo de lenguajes de programación que evitaba estos inconvenientes, a costa de ceder un poco en las ventajas. Estos lenguajes se llaman “de tercera generación” o “de alto nivel”, en contraposición a los “de bajo nivel” o “de nivel próximo a la máquina”.
34- Lenguaje de Bajo Nivel.
Un lenguaje de programación de bajo nivel es el que proporciona poca o ninguna abstracción del microprocesador de un ordenador. Consecuentemente es fácilmente trasladado a lenguaje de máquina.
La palabra “bajo” no implica que el lenguaje sea inferior a un lenguaje de alto nivel; se refiere a la reducida abstracción entre el lenguaje y el hardware.
35- Ciencia Real
Una prueba segura de cualquier afirmación verdaderamente científica es su capacidad de predecir el futuro: de decir qué sucederá bajo circunstancias dadas. Cuando se la somete a medidas válidas y objetivas de predicción, la pseudociencia no obtiene mejores resultados que la mera adivinación, en contraste con la ciencia real. Piense en la historia tal como la predijo la astrología, comparada con la gravedad y la certeza experimental y verificable de la ley del cuadrado inverso.
36- Ciencia Fisión
La ciencia ficción (también fue conocida en su origen como literatura de anticipación) es la denominación popular con que se conoce a uno de los géneros derivados de la literatura de ficción (junto con la literatura fantástica y la narrativa de terror). Nacida como subgénero literario distinguido en la década de 1920 (aunque hay obras reconocibles muy anteriores) y exportada posteriormente a otros medios, el más notable de ellos el cinematográfico, gozó de un gran auge en la segunda mitad del siglo XX debido al interés popular acerca del futuro que despertó el espectacular avance tanto científico como tecnológico alcanzado durante esos años.
Entre los estudiosos del género no se ha podido llegar a un consenso amplio sobre una definición formal, siendo éste un tema de gran controversia. En general se considera ciencia ficción a los cuentos o historias que versan sobre el impacto que producen los avances científicos, tecnológicos, sociales o culturales, presentes o futuros, sobre la sociedad o los individuos.
37- Inteligencia Artificial
Se denomina inteligencia artificial a la rama de la informática que desarrolla procesos que imitan a la inteligencia de los seres vivos. La principal aplicación de esta ciencia es la creación de máquinas para la automatización de tareas que requieran un comportamiento inteligente.
Algunos ejemplos se encuentran en el área de control de sistemas, planificación automática, la habilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento de escritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmente son parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usado en gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador y otros videojuegos.
El matemático sudafricano, Seymour Papert, es considerado pionero en esta ciencia
38- Programas Tradicionales
Los programas tradicionales se denominan a todas aquellas aplicaciones que los usuarios normales utilizan, tales como paquete para oficinas, email, en general todo lo que se denomina programas de utilería.
39- Generación de los Programas.
Los equipos (el hardware) han pasado por cuatro generaciones, de las que las tres primeras (ordenadores con válvulas, transistores y circuitos integrados) están muy claras, la cuarta (circuitos integrados a gran escala) es más discutible.
Algo parecido ha ocurrido con la programación de los ordenadores (el software), que se realiza en lenguajes que suelen clasificarse en cinco generaciones, de las que las tres primeras son evidentes, mientras no todo el mundo está de acuerdo en las otras dos. Estas generaciones no coincidieron exactamente en el tiempo con las de hardware, pero sí de forma aproximada, y son las siguientes:
Primera generación Los primeros ordenadores se programaban directamente en código binario, que puede representarse mediante secuencias de ceros y unos sistema binario. Cada modelo de ordenador tiene su propio código, por esa razón se llama lenguaje de máquina.
Segunda generación Los lenguajes simbólicos, asimismo propios de la máquina, simplifican la escritura de las instrucciones y las hacen más legibles.
Tercera generación Los lenguajes de alto nivel sustituyen las instrucciones simbólicas por códigos independientes de la máquina, parecidas al lenguaje humano o al de las Matemáticas.
Cuarta generación Se ha dado este nombre a ciertas herramientas que permiten construir aplicaciones sencillas combinando piezas prefabricadas. Hoy se piensa que estas herramientas no son, propiamente hablando, lenguajes. Algunos proponen reservar el nombre de cuarta generación para la programación orientada a objetos.
Quinta generación Se llama así a veces a los lenguajes de la inteligencia artificial, aunque con el fracaso del proyecto japonés de la quinta generación el nombre ha caído en desuso.
40- Que es Case.
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.
41- Programas Compactadores.
Son programas que permiten comprimir o compactar un archivo y/o descomprimirlo o descompactarlo . El objeto de estos programas es reducir el tamaño de los archivos que se transmiten o se transportan en disquetes, al reducir su tamaño se reduce también el tiempo de conexión. Este software se basa en el algoritmo de compresión ZIP, que ya se usaba antes del windows con programas como PKZIP y PKUNZIP.
Muchos archivos en la Web están Compactados. Y es Fundamental para el acarreo de grandes volúmenes de información que pueden viajar “zipeados” en lugar de ocupar demasiado tamaño en su formato original. Entre las ventajas que posee esta la de ser posible su uso como herramienta para ejecutar y realizar BACKUPS de archivos y productos, la opción de utilizar claves de seguridad para que solo quienes estén autorizados puedan descompactar y acceder a los datos comprimidos.
42- Lenguaje SQL
El Lenguaje de consulta estructurado (SQL [/esekuele/ en español, /ɛskjuːˈɛl / en inglés] Structured Query Language ) es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas. Una de sus características es el manejo del álgebra y el cálculo relacional permitiendo lanzar consultas con el fin de recuperar -de una forma sencilla- información de interés de una base de datos, así como también hacer cambios sobre la misma. Es un lenguaje de cuarta generación (4GL).
Interface
Como principio, el Diccionario de la Real Academia de la Lengua Española define interfaz como una palabra derivada del término inglés “interface”(superficie de contacto) y la define de la siguiente manera: 1. f. Inform. Conexión física y funcional entre dos aparatos o sistemas independientes.
Por confusión con el término anglosajón “interfazear”, “interfasear”, “interfacear” suele utilizarse en muchos manuales de motherboard, pero no debe tomarse esto como correcto ya que existe una palabra muy simple de referencia de este artículo.
43- ABI
En los programas informáticos, un interfaz de aplicación binaria (ABI) describe el bajo nivel de interfaz entre un programa de aplicación y el sistema operativo, o la interfaz entre una aplicación y sus bibliotecas, o que entre los componentes de una aplicación. Un ABI es similar a una interfaz de programación de aplicaciones (API), sin embargo, este último define una interfaz de código fuente. [1] En pocas palabras, abis permitir la compatibilidad binaria, mientras que las API de permitir la compatibilidad de código fuente.
44- Loger Susana Catherine
45- OLP
OLP (Open License Program) lo cual es un programa de licenciamiento por volumen en el cual una empresa puede adquirir sus licencias con un solo contrato, entre estos programas esta el Open Business y Open Value.
46- OLTP
OLTP (Online Transaction Processing) es un tipo de procesamiento de transacciones a través de una red de computadoras. Algunos tipos de aplicaciones OLTP pueden ser banca electrónica, procesamiento de pedidos o comercio electrónico. Es un programa que facilita y administra aplicaciones transaccionales, usualmente para data entry y transacciones en empresas, incluyendo bancos, aerolíneas, etc.
47- Data Ware House
Es un repositorio de datos de muy fácil acceso, alimentado de numerosas fuentes, transformadas en grupos de información sobre temas específicos de negocios, para permitir nuevas consultas, análisis, reportador y decisiones.
48- Data Monts
Los Data Marts son las bases de datos locales o departamentales basadas en subconjuntos de la información contenida en el Data Warehouse central o maestro.
49- Lisp
Lisp es el segundo lenguaje de programación, después de Fortran, de alto nivel. Lisp es de tipo declarativo y fue creado en 1958 por John McCarthy y sus colaboradores en el MIT.
Suscribirse a:
Entradas (Atom)
