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.
Suscribirse a:
Entradas (Atom)
