Frase del Día

La tecnología vino a resolver problemas que no teníamos

miércoles, 8 de diciembre de 2010

Ingenieria Web

LA World Wide Web e Internet han introducido a la población en general en el mundo de la informática. Compramos fondos de inversión colectivos y acciones, descargamos música, vemos películas, obtenemos asesoramiento médico, hacemos reservas de habitaciones en hoteles, vendemos artículos personales, planificamos vuelos en líneas aéreas, conocemos gente, hacemos gestiones bancarias, recibimos cursos universitarios, hacemos la compra -es decir, en el mundo virtual se puede hacer todo lo que se necesite-. Se puede decir que Internet y la Web son los avances más importantes en la historia de la informática. Estas tecnologías informáticas nos han llevado a todos nosotros a la era de la informática (con otros millones de personas quienes finalmente entrarán también). Durante los primeros años del siglo veintiuno estas tecnologías han llegado casi a formar parte de nuestra vida diaria.

Para todos nosotros que recordamos un mundo sin Web, el crecimiento caótico de la tecnología tiene su origen en otra era -los primeros días del software-. Eran tiempos de poca disciplina, pero de enorme entusiasmo y creatividad. Eran tiempos en que los programadores a menudo entraban en otros sistemas, algunas veces con buena intención y otras con mala intención. La actitud que prevalecía parecía ser la de «Hazlo rápidamente, y entra en el campo, que nosotros lo limpiaremos (y mejor sería que entendieras lo que realmente queremos construir) cuando actuemos». ¿Le suena familiar?

En una mesa redonda virtual publicada en IEEE Software, mantuve en firme mi postura en relación con la ingeniería de Web:


Me parece que cualquier producto o sistema importante es merecedor de recibir una ingeniería. Antes de comenzar a construirlas, lo mejor es entender el problema, diseñar una solución viable, implementarla de una manera sólida y comprobarla en profundidad. Probablemente también se deberían controlar los cambios a medida que el trabajo vaya avanzando, y disponer de mecanismos para asegurar la calidad del resultado final. Muchos de los que desarrollan Webs no dicen lo mismo; ellos piensan que su mundo es realmente diferente, y que simplemente no se van a aplicar los enfoques de ingeniería del software convencionales.

Qué es?
Los sistemas y aplicaciones (WebApps) basados en Web hacen posible que una población extensa de usuarios finales dispongan de una gran variedad de contenido y funcionalidad.

La ingeniería Web no es un clónico perfecto de la ingeniería del software, pero toma prestado muchos de los conceptos y principios básicos de la ingeniería del software, dando importancia a las mismas actividades técnicas y de gestión. Existen diferencias sutiles en la forma en que se llevan a cabo estas actividades, pero la filosofía primordiales idéntica dado que dicta un enfoque disciplinado para el desarrollo de unsistema basado en computadora.

Quiénlo hace? 
Los ingenieros Web y los desarrolladores de contenido no técnicos crean las WebApps. 

Por qué es importante?
A medida que las WebApps se integran cada vez más en grandes y pequeñas compacompañías (por ejemplo, comercio electrónico), y cada vez es más importante la necesidad de construir sistemas fiables, utilizables y adaptables. Esta es la razón por la que es necesario un enfoque disciplinado para el desarrollo de WebApps.

Cuáles son los pasos a seguir ?
Al igual que cualquier disciplina de ingeniería, la ingeniería Web aplica. un enfoque genérico que se suaviza con estrategias, tácticas y métodos especializados. El proceso de ingeniería

Web comienza con una formulación del problema que pasa a resolverse con las WebApps. Se planifica el proyecto y se analizan los requisitos de l a WebApp, entonces se lleva a cabo el diseño de interfaces arquitectónico y del navegador. El sistema se implementa utilizando lenguajes y herramientas especializados asociados con la Web, y entonces comienzan las pruebas Dado que las WebApps están en constante evolución, deben de estae los mecanismos para el control de configuraciones, garantía de calidad y soporte continuado.

Cuál es el producto obtddo? 
La elaboración de una gran variedad de productos de trabajo de ingenierfa Web (por ejemplo, modelos de análisis. modelos de diseño, procedimientos de pruebas). Y como producto final la WebApp operativa.

Cómo puedo estar seguro de que lo he hecho correctamente? 
Aplicando las mismas prácticas SQA que se aplican en todos los procesos de ingeniería del software -las revisiones técnicas formales valoran los modelos de análisis y diseño las revisiones especializadas tienen en consideración la usabilidad y la comprobación se aplica para descubrir errores en el contenido, funcionalidad y compatibilidad. 

Esto nos lleva a formular una pregunta clave: ¿Pueden aplicarse principios, conceptos y métodos de ingeniería en el desarrollo de la Web? Creo que muchos de ellos sí se pueden aplicar, pero su aplicación quizás requiera un giro algo diferente. 

Pero, ¿qué ocurriría si estuviera equivocado?, y ¿si persiste el enfoque actual y específico para ese desarrollo de la Web? Con la ausencia de un proceso disciplinado para sistemas basados en Web, cada vez nos preocupa más la manera en que nos podemos enfrentar con problemas serios para obtener éxito en el desarrollo, empleo y «mantenimiento» de estos sistemas. En esencia, a medida que entramos en el nuevo siglo, la infraestructura de las aplicaciones que se están creando hoy en día puede llevamos a algo que se podría llamar «Web enmarañada». Esta frase connota un cúmulo de aplicaciones basadas en Web pobremente desarrolladas y con una probabilidad de fallo bastante alta. Y lo que es peor, a medida que los sistemas basados en Web se van complicando, un fallo en uno de ellos puede propagar y propagará problemas muy extensos en todos. Cuando ocurra esto, la confianza en Internet se puede romper provocando resultados irremediables. Y lo que es aún peor, puede conducir a una regulación gubernamental innecesaria y mal concebida, provocando daños irreparables en estas tecnologías singulares. 

Con objeto de evitar una Web enmarañada y lograr un mayor éxito en el desarrollo y aplicación de sistemas basados en Web complejos y a gran escala, existe una necesidad apremiante de enfoques de ingeniería Web disciplinada y de métodos y herramientas nuevos para el desarrollo, empleo y evaluación de sistemas y aplicaciones basados en Web. Tales enfoques y técnicas deberán tener en cuenta las características especiales en el medio nuevo, en los entornas y escenarios operativos, y en la multiplicidad de perfiles de usuario implicando todo ello un reto adicional para el desarrollo de aplicaciones basadas en Web.

La Ingeniería Web (IWeb) está relacionada con el establecimiento y utilización de principios científicos, de ingeniería y de gestión, y con enfoques sistemáticos y disciplinados del éxito del desarrollo, empleo y mantenimiento de sistemas y aplicaciones basados en Web de alta calidad.

LOS ATRIBUTOS DE APLICACIONES BASADAS EN WEB.

No hay mucho que decir con respecto al hecho de que los sistemas y las aplicaciones' basados en Web (nos referiremos a estas como WebApps) son muy diferentes de las otras categorías de software informático que se tratan en el Capítulo 1. Powell resume las diferencias básicas cuando afirma que los sistemas basados en Web «implican una mezcla de publicación impresa y desarrollo de software, de marketing e informática, de comunicaciones internas y relaciones externas, y de arte y tecnología». Los atributos siguientes se van a encontrar en la gran mayoría de las WebApps2:

Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes. Una WebApp puede residir en Internet (haciendo posible así una comunicación abierta par todoel mundo). De forma alternativa, una aplicación se puede ubicar en una Intranet (implementando la comunicación a través de redes de una organización) o una Extranet (comunicación entre redes).

Controlada por el contenido. En muchos casos, la función primaria de una WebApp es utilizar hipermedia para presentar al usuario el contenido de textos, gráficos, sonido y vídeo.
Evolución continua. A diferencia del software de aplicaciones convencional, que evoluciona con una serie de versiones planificadas y cronológicamente espaciadas, las aplicaciones Web están en constante evolución. No es inusual que algunas WebApps (específicamente, su contenido) se actualicen cada hora.

Un cuidado y una alimentación continua permite que un sitio Web crezca (en robustez y en importancia). Pero a diferencia de un jardín, las aplicaciones Web deben de servir (y adaptarse a) las necesidades de más de un jardinero, Las siguientes características de WebApps son las que conducen el proceso:

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez [NOR99] que no se encuentra en otros tipos de software. Es decir, el tiempo que se tarda en comercializar un sitio Web completo puede ser cuestión de días o semanas3. Los desarrolladores deberán utilizar los métodos de planificación, análisis, diseño, implementación y comprobación que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.

Seguridad. Dado que las WebApps están disponibles a través de1 acceso por red, es difícil, si no imposible, limitar la población de usuarios finales que pueden acceder a la aplicación. Con objeto de proteger el contenido confidencial y de proporcionar formas seguras de transmisión de datos, deberán implementarse fuertes  medidas de seguridad en toda la infraestructura que apoya una WebApp y dentro de la misma aplicación.

Estética. Una parte innegable del atractivo de una WebApp es su apariencia e interacción. Cuando se ha diseñado una aplicación con el fin de comercializarse o vender productos o ideas, la estética puede tener mucho que ver con el éxito del diseño técnico.

Las características generales destacadas anteriormente se aplican a todas las WebApps, pero con un grado diferente de influencia. Las categorías de aplicaciones que se enumeran a continuación son las más frecuentes en el trabajo de la Web:

informativa: se proporciona un contenido solo de lectura con navegación y enlaces simples.

descarga: un usuario descarga la información desde el servidor apropiado.

personalizable: el usuario personaliza el contenido a sus necesidades específicas.

interacción: la comunicación entre una comunidad de usuarios ocurre mediante un espacio chat (charla), tablones de anuncios o mensajería instantánea; entrada del usuario: la entrada basada en formularios es el mecanismo primario de la necesidad de comunicación.

orientada a transacciones: el usuario hace una solicitud (por ejemplo, la realización un pedido) que es cumplimentado por la WebApp;

orientado a servicios: la aplicación proporciona un servicio al usuario, por ejemplo, ayuda al usuario a determinar un pago de hipoteca.

portal: la aplicación canaliza al usuario llevándolo a otros contenidos o servicios Web fuera del dominio de la aplicación del portal.

acceso a bases de datos:
 el usuario consulta en una base de datos grande y extrae información.

almacenes de datos:
 el usuario hace una consulta en una colección de bases de datos grande y extrae información.

Las características y las categorías destacadas anteriormente en esta sección, y las categorías de aplicaciones representan los hechos reales para los ingenieros de la Web. La clave es vivir dentro de las restricciones impuestas por las características anteriores y aun así tener éxito en la elaboración de la WebApp.

ATRIBUTOS DE CALIDAD.

Todas las personas que hayan navegado alguna vez por la Web o hayan utilizado una intranet de una compañía pueden opinar sobre lo que hace una «buena» WebApp. Los puntos de vista individuales vm’an enormemente. Algunos usuarios disfrutan con gráficos llamativos, en cambio otros solo quieren un texto sencillo. Algunos exigen información copiosa, otros desean una presentación abreviada. En efecto, la percepción de «lo bueno» por parte del usuario (y como consecuencia, la aceptación o no aceptación resultante de la WebApp) podría ser más importante que cualquier discusión técnica sobre la calidad de la WebApp.

Pero ¿cómo se percibe la calidad de la WebApp? ¿qué atributos deben de exhibirse ante los ojos de los usuarios para lograr lo bueno y al mismo tiempo exhibir las características técnicas de calidad que permitan a un ingeniero corregir, adaptar, mejorar y soportar la aplicación a largo plazo?

En realidad, todas las características generales de la calidad del software estudiadas en los Capítulos 8, 19 y 24 se aplican también a las WebApps. Sin embargo, las características más relevantes -usabilidad, fiabilidad, eficiencia y capacidad de mantenimiento- proporcionan una base Útil para evaluar la calidad de los sistemas basados en Web.

Olsina y sus colaboradores [OSL99] han preparado un «árbol de requisitos de calidad» que identifica un conjunto de atributos que conduce a WebApps de alta calidad. La Figura 29.1 resume su trabajo. 

FIGURA 29.1. Árbol de requisitos de calidad (OSL 99).


Las tecnologías.

El diseño y la implementación de sistemas basados en Web incorporan tres tecnologías importantes: el desarrollo basado en componentes, la seguridad y los estándares de Internet. Un ingeniero Web deberá estar familiarizado con las tres para construir WebApps de alta calidad.

Desarrollo basado en componentes Las tecnologías de componentes estudiadas en los Capítulos 27 y 28 han evolucionado en gran parte gracias al crecimiento explosivo de los sistemas y aplicaciones basados en Web. Retomando el estudio del capítulo anterior, los ingenieros Web disponen de tres estándares importantes para la infraestructura: CORBA, COMDCOM y JavaBeans. Estos estándares (acompañados por los componentes preconstmidos, herramientas y técnicas) proporcionan una infraestructura que permite a los que diseñan emplear y personalizar componentes de terceras partes permitiéndoles así comunicarse unos con otros y con servicios a nivel de sistemas.

Seguridad

Si en una red reside una WebApp, ésta está abierta a un acceso sin autorización. En algunos casos, ha sido el personal interno el que ha intentado acceder sin autorización. En otros casos, intrusos (hackers) pueden intentar acceder por deporte, por sacar provecho o con intenciones más maliciosas. Mediante la infraestructura de red se proporciona una variedad de medidas de seguridad, tales como encriptación, cortafuegos y otras. Un estudio amplio de este tema queda fuera del ámbito de este libro.

Estándares de Internet.

Durante la última década el estándar dominante en la creación del contenido y la estructura de la WebApp ha sido HTML, un lenguaje de marcas que posibilita al desarrollador proporcionar una serie de etiquetas que describen una gran variedad de objetos de datos (texto, gráficos, audio/vídeo, formularios, etc.). Sin embargo, a medida que las aplicaciones crecen en tamaño y complejidad, se ha adoptado un nuevo estándar -XMLpara la próxima generación de WebApps. XML (Extensible Markup Language) el Lenguaje de marcas extensible es un subconjunto estrictamente definido del metalenguaje SGML [BRA97], permitiendo que los diseñadores definan etiquetas personalizadas en las descripciones de una página Web. Mediante una descripción del metalenguaje XML, el significado de las etiquetas personalizadas se define en la información transmitida al sitio del cliente.

EL PROCESO DE INGENIERIA WEB.

Las caracteristicas de Sistemas y aplicaciones basados en web influyen enormemente en el proceso IWEB. La inmediatez y evoluci[on continuan dicctando un modelo de proceso incremental e interactivo que elabora versiones de WebApps muy rapidamente. La Naturaleza intensiva de red de las aplicaciones en este dominio sugiere una poblacion de usuarios diversa (exigiendo especialmente la obtención y modelado de requisitos) , y una arquitectura de aplicacion que pueda ser altamente especializada (realizando de esta manera exigencias en el diseño). Dado que las WebApps suelen ser controladas por el contenido haciendo hincapié en la estetica, es probable que las actividades de desarrollo paralelas palnifiquen  dentro del rpoceso IWEB y necesitan un equipo de personas tanto tecnicas como no, (por ejemplo, redactores  publicitarios, diseñadores graficos).

UN MARCO DE TRABAJO PARA LA IWEB


La formulación y el análisis de sistemas y aplicaciones basados en Web representan una sucesión de actividades de ingeniería Web que comienza con la identificación de metas globales para la WebApp, y termina con el desarrollo de un modelo de análisis o especificación de los requisitos para el sistema. La formulación permite que el cliente o diseñador establezca un conjunto común de metas y objetivos para la  construcción de la WebApp. También identifica el ámbito de esfuerzo en el desarrollo y proporciona un medio para determinar un resultado satisfactorio. El análisis es una actividad técnica que identifica los datos y requisitos funcionales y de comportamiento para la WebApp.
Formulación.
 
Powell [POW98] sugiere una serie de preguntas que deberán formularse y responderse al comienzo de la etapa de formulación:

¿Cuál es la motivación principal para la WebApp?
¿Por qué es necesaria la WebApp?
¿Quién va a utilizar la WebApp?
¿Qué preguntas se deberían hacer para formular el problema? 
La respuesta a estas preguntas deberá ser de lo más sucinto posible. Por ejemplo, supongamos que el fabricante de sistemas de seguridad en el hogar ha decididoestablecer un sitio Web de comercio electrónico para vender sus productos directamente a los consumidores. Una frase que describiera la motivación de la WebApp podría ser la siguiente:

HogarSeguroInc.com5 permitirá a los consumidores configurar y comprar todos los componentes necesarios para instalar un sistema de seguridad en casa o en su comercio.
Es importante destacar que en esta frase no se ha proporcionado ningún detalle. El objetivo es delimitar la intención global del sitio Web. Después de discutir con otros propietarios de Hogar- Seguro Inc., la segunda pregunta se podría contestar de la siguiente manera:
HogarSeguroInc.com nos permitirá vender directamente a los consumidores, eliminando por tanto los costes de intermediarios, y mejorando de esta manera los márgenes de beneficios.
También nos permitirá aumentar las ventas en un 25 por 100 por encima de las ventas anuales y nos permitirá penetrar en zonas geográficas en donde actualmente no tenemos dmacenes
de ventas.
Finalmente, la compañía define la demografía para la WebApp: «Los usuarios potenciales de HogarSeguroInc. com son propietarios de casas y de negocios pequeños.»

Las respuestas que se han establecido anteriormente implican metas específicas para el sitio Web Hogar- SeguroInc.com. En general, se identifican dos categorías:
Metas informativas: indican la intención de proporcionar el contenido y/o información específicos para el usuario final.

Metas aplicables: indican la habilidad de realizar algunas tareas dentro de la WebApp.
En el contenido de la Web HogarSeguroInc.com, una meta informativa podría ser la siguiente:

El sitio proporcionará a los usuarios especificaciones de un producto detallado, como descripción técnica, instrucciones de instalación e información de precios.
 
 El examen de las respuestas anteriores llevará a HogarSeguroInc.com consultará al cliente sobre la instalación (es decir, sobre la casa, oficina/almacén rninorista) que se va a proteger, y dará recomendaciones personalizadas sobre el producto y la configuración que se va utilizar.

Una vez que han identificado todas las metas aplicables e informativas se desarrolla el perfil del cliente. El perfil del usuario recoge «las características relevantes de los usuarios potenciales incluyendo antecedentes, conocimiento, preferencias e incluso más. En el caso de HogarSeguroInc.com, el perfil de usuario identificará las características de un comprador
típico de sistemas de seguridad (esta información sería proporcionada por el departamento de marketing de HogarSeguroInc.com). 

Una vez que se han desarrollado las metas y los perfiles de usuarios, la actividad de formulación se centra en la afirmación del ámbito para la WebApp (Capítulo 5). En muchos casos, las metas ya desarrolladas se integran en la afirmación del ámbito. Además es Útil, no obstante, indicar el grado de integración que se espera para la WebApp. Es decir, a menudo es necesario integrar los sistemas de información existentes (por ejemplo, la aplicación de base de datos existente) en un planteamiento basado en Web. En este punto se tienen en consideración también los temas de conectividad.
Análisis:

Los conceptos y principios que se trataron para el análisis de los requisitos del software (Capítulo 11) se aplican sin revisión en la actividad de análisis de ingeniería Web. Para crear un modelo de análisis completo para la WebApp se elabora el ámbito definido durante la actividad de formulación. Durante la IWeb se realizan cuatro tipos de análisis diferentes:
Análisis del contenido. Se trata de la identificación del espectro completo de contenido que se va a proporcionar. En el contenido se incluyen datos de texto, gráficos, imágenes, vídeo y sonido. Para identificar y describir cada uno de los objetos de datos que se van a utilizar dentro de la WebApp se puede utilizar el modelado de datos (Capítulo 12).
Análisis de la interacción. Se trata de la descripción detallada de la interacción del usuario y la WebApp. Para proporcionar descripciones detalladas de esta interacción se pueden desarrollar casos prácticos (Capítulo 11). 

Análisis funcional. Los escenarios de utilización (casos de uso) creados como parte del análisis de interacción definen las operaciones que se aplicarán en el contenido de la WebApp e implicarán otras funciones de procesamiento. Aquí se realiza una descripción detallada
de todas las funciones y operaciones. 
Análisis de la configuración. Se efectúa una descripción detallada del entorno y de la infraestructura en donde reside la WebApp. La WebApp puede residir en Internet, en una intranet o en una Extranet. Además, se deberá identificar la infraestructura (es decir, la infraestructura de los componentes y el grado de utilización de la base de datos para generar el contenido) de la WebApp.

Aun cuando se recomienda una especificación detallada de los requisitos para WebApps grandes y complejas, tales documentos no son los usuales. Se puede decir que la continua evolución de los requisitos de la WebApp puede hacer que cualquier documento se quede obsoleto antes de finalizarse. Aunque se puede decir que esto sucede de verdad, es necesario
definir un modelo de análisis que pueda funcionar como fundamento de la siguiente actividad de diseño. Como mínimo, la información recogida durante las cuatro tareas de análisis anteriores deberá ser revisada, modificada a petición, y organizada para formar un documento que pueda pasarse a los diseñadores de WebApps.

Fuente
Ingeniería del Software, un enfoque práctico
Roger S. Pressman
McGraw-Hill, 2006 - 958 páginas

Arquitectura Cliente-Servidor

En el mundo de TCP/IP las comunicaciones entre computadoras se rigen básicamente por lo que se llama modelo Cliente-Servidor, éste es un modelo que intenta proveer usabilidad, flexibilidad, interoperabilidad y escalabilidad en las comunicaciones.

El término Cliente/Servidor fue usado por primera vez en 1980 para referirse a PC’s en red.

Este modelo Cliente/Servidor empezó a ser aceptado a finales de los 80’s. Su funcionamiento es sencillo: se tiene una máquina cliente, que requiere un servicio de una máquina servidor, y éste realiza la función para la que está programado (nótese que no tienen que tratarse de máquinas diferentes; es decir, una computadora por sí sola puede ser ambos cliente y servidor dependiendo del software de configuración).

Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Separa los servicios situando cada uno en su plataforma más adecuada.
Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma.

En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio).

Cliente Servidor

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.
Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

Cuando implantar Cliente servidor

1. Cambios estructurales y organizativos.
2. Cambios en organigramas.
3. Respuesta dinámica de mercado.
4. Cambio en procesos de negocio.

Fuente:
Ingeniería del Software, un enfoque práctico
Roger S. Pressman
McGraw-Hill, 2006 - 958 páginas

fuente:

Sala Limpia


La utilización integrada del modelado de ingeniería del software convencional, métodos formales, verificación de programas (demostraciones de corrección) y estadística SQA se han combinado en una técnica que puede dar lugar a un software de calidad extremadamente alta. La ingeniería del software de sala limpia es un enfoque que hace hincapié en la necesidad de incluir la corrección en el software a medida que éste se desarrolla. En lugar del ciclo clásico de análisis, diseño, pruebas y depuración, el enfoque de sala limpia sugiere un punto de vista distinto :

La filosofía que subyace tras la ingeniería del software de sala limpia consiste en evitar la dependencia de costosos procesos de eliminación de defectos, mediante la escritura de incrementos de código desde un primer momento, y mediante la verificación de su corrección antes de las pruebas.  Su modelo de proceso incluye la certificación estadística de calidad de los incrementos de código, a  medidad que estos se van añadiendo cn el sistema.

En muchos aspectos, el enfoque de sala limpia eleva la ingenicría del software a otro nivel. Al igual que las técnicas de métodos formales que se presentaban en el Capítulo 25, el proceso de sala limpia hace hincapié en el rigor en la especificación y en el diseño, y en la verificación formal de cada uno de los elementos del modelo de diseño Fesultante mediante el uso de pruebas de corrección basadas en fundamentos matemáticos. Al extender el enfoque adoptado en los métodos formales, el enfoque de sala limpia hace hincapié también en técnicas de control estadístico de calidad, incluyendo las comprobaciones basadas en el uso anticipado del software por parte de los clientes.

Qué es? Cuántas veces se ha oído decir «Hazlo correctamente a la primera.?

Esa es la filosofía primordial de la ingeniería del software de sala limpia, un proceso que da importancia a la verificación matemática de la corrección antes de que comience la construcción de un programa y de que la certificación de la fiabilidad del software forme parte de la actividad de pruebas. Haciendo hincapié en una filosofía más profunda, se trataría de aquella que tiene índices de fallo extremadamente bajos y que es dificil o imposible de lograr utilizando métodos menos formales.

¿Quién lo hace?                                                                                                                

Un ingeniero del software formado para esta especialización.

¿Por qué es importante?

Los errores conllevan doble trabajo. Trabajar el doble lleva más tiempo y es más caro. NO sería maravilloso poder reducir dramáticamente la cantidad de errores (fallos informáticos) que se cometen en el diseño y construcción del software? Esto es lo que promete la ingeniería del software de sala limpia.

¿Cuáles son los pasos?

Los modelos de análisis y diseño se crean utilizando la representación de estructura de caja. Una <caja. encapsula el sistema (o algún aspecto del sistema) a un nivel específico de abstracción. La verificación de la corrección se aplica una vez que se ha completado el diseño de la estructura de caja Y la prueba estadística de l a utilización comienza una vez que se ha verificado la corrección en cada estructura de caja. El software se prueba definiendo un conjunto de escenarios, determinando la probabilidad de utilización de cada uno y definiendo entonces las pruebas aleatorias que se ajustan a las probabilidades. Por último, los registros de errores resultantes se analizan para permitir el cálculo matemático de la fiabilidad proyectada en el componente de software.

¿Cuál es el producto obtenido?

El desarrollo de especificaciones de caja negra, de caja de estado y de caja limpia. Y, además, el registro de los resultados de las pruebas formales de corrección y las pruebas estadísticas de utilización.

¿Cómo puedo estar seguro de que lo he hecho correctamente?

La prueba formal de corrección se aplica a la especificación de estructura de cajas. Las pruebas estadísticas de utilización ejercitan los escenarios de utilización para asegurar que no se revelen y se puedan corregir los errores en la funcionalidad del usuario. Los datos de prueba se utilizan para proporcionar una señal de la fiabilidad del software.

Cuando el software falla en el mundo real, suelen abundar los peligros a largo plazo así como los peligros inmediatos. Los peligros pueden estar relacionados con la seguridad humana, con pérdidas económicas o con el funcionamiento efectivo de una infraestructura social y de negocios. La ingeniería del software de sala limpia es un modelo de proceso que elimina los defectos antes de que puedan dar lugar a riesgos graves.


La filosofía de la «sala limpian en las técnicas de fabricación de hardware es en realidad algo bastante sencillo:

se trata de una forma rentable y eficiente, en términos de tiempo, de establecer un enfoque de fabricación que impida la introducción de defectos de producción. En lugar de fabricar un producto y dedicarse después a eliminar defectos, el enfoque de sala limpia demanda la disciplina necesaria para eliminar errores en las especificaciones y en el diseño, fabricando entonces el producto de forma «limpia».

La filosofía de sala limpia fue propuesta por primera vez para la ingeniería del software por parte de Mills y sus colegas  durante los años 80. Aun cuando las primeras experiencias acerca de este enfoque disciplinado para los trabajos relacionados con el software mostraba promesas significativas , no ha alcanzado una amplia utilización. Henderson sugiere tres posibles razones:

1- La creencia en que la metodología de sala limpia es excesivamente teórica, excesivamente matemática y excesivamente radical para utilizarla en el desarrollo de software real.

2- No propugna una comprobación unitaria por parte de los desarrolladores, sino que la sustituye por una verificación de la corrección y por un control estadístico de la calidad -estos conceptos que representan una desviación fundamental con respecto a la forma en que se desarrolla la mayor parte del software en la actualidad-.

3- La madurez de la industria de desarrollo del software. El uso de procesos de sala limpia requiere una aplicación rigurosa de procesos definidos en todas las fases del ciclo de vida. Dado que la mayor parte de la industria funciona todavía en el nivel ad hoc (según se ha definido por parte del Software Engineering Institute Capability Maturity Model), la industria no ha estado preparada para aplicar estas técnicas.

Aun cuando existen ciertos indicios de verdad en todas las indicaciones expresadas anteriormente, los posibles bencficios de la ingeniería del software de sala limpia compensan más que sobradamente la inversión requerida para superar la resistencia cultural que se encuentra en el núcleo de estas objeciones.


 La estrategia de sala limpia:

El enfoque de sala limpia hace uso de una versión especializada del modelo incremental de software. Se desarrolla un «cauce de incrementos de software»  por parte de equipos de ingeniería del software pequeños e independientes. A medida que se va certificando cada incremento, se integra en el todo. Consiguientemente, la funcionalidad del sistema va creciendo con el tiempo.

¿Cuáles son las tareas principales que se realizan en la ingeniería del software de sala limpia?

 Los requisitos globales del sistema o producto se van desarrollando empleando los métodos de ingeniería de sistemas. Una vez que se ha asignado una funcionalidad al elemento de software del sistema, el tubo de la sala limpia comienza sus incrementos. Se producen las tareas siguientes:

Planificación de incrementos. Se desarrolla un plan de proyecto que adopta la estrategia incremental. Se van estableciendo las funcionalidades de cada uno de los incrementos, su tamaño estimado y un plan de desarrollo de sala limpia. Es preciso tener especial cuidado para asegurar que los incrementos certificados se vayan integrando de forma temporalmente oportuna.

Recolección de requisitos. Mediante el uso de técnicas similares a las presentadas en el Capítulo 1 1, se desarrolla una descripción más detallada de requisitos del nivel del usuario (para cada incremento).

Especificación de la estructura de cajas. Se utiliza un método de especificación que hace uso de estructuras de caja para describir la especificación funcional.

Ajustado a los principios de análisis operacional, la estructura de caja «aísla y separa la definición creativa del comportamiento, de los datos, y de los procedimientos para cada nivel de refinamiento».

Diseño formal. Mediante el uso del enfoque de estructura de cajas, el diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Aun cuando es posible efectuar una distinción clara entre estas dos actividades, las especificaciones (que se denominan «ca.jas negras>>)s e refinan iterativamente (dentro de cada incremento) para transformarse en diseños análogos a la arquitectura y a los procedimientos (que se denominan «cajas de estado» y «cajas trasparentes», respectivamente).

Verificación de corrección. El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificación de corrección aplicadas primero al diseño y después al código. La verificación comienza con la estructura de cajas del más alto nivel (la especificación) y avanza hacia el detalle de diseño y el código. El primer nivel de verificación de corrección se lleva a cabo aplicando un conjunto de cuestiones de corrección» [LIN88]. Si este conjunto de preguntas no demuestra que la especificación es correcta, se utilizan métodos más formales (matemáticos) de verificación.

Generación de código, inspección y verificación: Las especificaciones de estructura de caja, que se representan mediante un lenguaje especializado, se traducen al lenguaje de programación adecuado. Se utilizan entonces técnicas estándar de recorrido o de inspección para asegurar el cumplimiento sernántico de las estructuras de código y de cajas, y la corrección sintáctica de código. A continuación, se efectúa una verificación de corrección para el código fuente.

Planificación de la comprobación estadística. La utilización estimada del software se analiza, se planifica y se diseña un conjunto de casos de prueba que ejerciten la «distribución de probabilidad» de esa utilización. Según se muestra en la, esta actividad de sala limpia se realiza en paralelo con la especificación, la verificación y la generación de código.

Comprobación estadística de utilización. Recordando que es imposible una comprobación exhaustiva del software de computadora, siempre resulta necesario diseñar un conjunto finito de casos de prueba. Las técnicas estadísticas de utilización ejecutan una colección de pruebas derivadas de una muestra estadística (la distribución de probabilidad indicada anteriormente) de todas las posibles ejecuciones del programa por parte de todos los usuarios de una cierta población objetivo.

Certificación. Una vez que se ha finalizado la verificación, la inspección y la comprobación de utilización (y después de corregir todos los errores) se certifica el incremento como preparado para su integración.

Al igual que otros modelos de proceso del software descritos en otras partes de este libro, el proceso de sala limpia hace especial hincapié en la necesidad de conducir unos modelos de análisis y de diseño de muy alta calidad. Según se verá posteriormente en este capítulo, la notación de estructura de cajas no es más que otra forma para que el ingeniero del software pueda representar los requisitos y el diseño. La distinción real del enfoque de sala limpia consiste en que se aplica la verificación formal a los modelos de ingeniería.


¿Qué hace diferente la sala limpia?

Dyer alude a las diferencias del enfoque de sala limpia cuando define el proceso:

La sala limpia representa el primer intento práctico de poner el proceso de desarrollo del software bajo un control estadístico de calidad con una estrategia bien definida para la mejora continua del proceso. Para alcanzar esta meta, sc definió un ciclo único de vida de sala limpia, que hacía hincapié en una ingeniería del software basada en las matemáticas para obtener diseños de software correctos y que se basaba en software basado en estadística para la cei-tificación de fiabilidad de ese software.

La ingeniería del software de sala limpia ditiere de los puntos de vista convencionales y orientados a objetos que se representan en la Partes Tercera y Cuarta de este libro porque:

1. Hace uso explícito del control estadístico de calidad.

2. Verifica la especificación del diseño empleando una demostración de corrección basada en las matemáticas.

3. Hace mucho uso de la comprobación estadística de utilización para descubrir errores de especial incidencia.

Evidentemente, el enfoque de sala limpia aplica la mayor parte, si es que no todos, de los principios básicos de ingeniería del software y de los conceptos que se han presentado a lo largo de este libro. Son esenciales unos buenos procedimientos de análisis y diseño si es que se desea producir una elevada calidad. Pero la ingeniería de sala limpia diverge de las prácticas de software convencionales al quitar importancia (hay quien diría eliminar) al papel de las pruebas de unidad y a la depuración y al reducir dramáticamente (o eliminar) la cantidad de comprobaciones que son realizadas por quien desarrolla el software'.

En el desarrollo convencional del software, los errores se aceptan como cosas que pasan. Dado que se considera que los errores son inevitables, cada módulo del programa debe ser comprobado unitariamente (para descubrir los errores) y depurado después (para eliminar los errores). Cuando se publica finalmente el software, la utilización práctica descubre aun más defectos, y comienza otro ciclo de comprobación y depuración. Este trabajo repetido asociado a las actividades mencionadas resulta costoso y lleva mucho tiempo. Y lo que es peor, puede ser degenerativo; la corrección de errores puede (inadvertidamente) dar lugar a la introducción de otros errores.

En la ingeniería del software de sala limpia, la comprobación unitaria y la depuración se ven sustituidas por una verificación de corrección y por pruebas basadas en la estadística. Estas actividades, junto con el mantenimiento de registros para una continua mejora, hacen que el enfoque de sala limpia sea único.

ESPECIFICACIÓN FUNCIONAL

Independientemente del método de análisis seleccionado, los principios de operación presentados en el Capítulo 1 1 siempre serán aplicables. Se modelan los datos, las funciones y el comportamiento. Los modelos resultantes deben de ser descompuestos (refinados) para proporcionar un grado de detalle cada vez más elevado. El objetivo global consiste en pasar de una especificación que captura la esencia de un problema, a una especificación que proporciona una cantidad de detalle sustancial para su implementación.

La ingeniería del software de sala limpia satisface los principios de análisis operacional por cuanto emplea un método denominado especijicución de estructuru de caja Una < a j a » encapsula el sistema (o algún aspecto del sistema) con un cierto grado de detalle. Mediante un proceso de refinamiento progresivo, se van refinando las ca-jas para formar una jerarquía en la cual cada caja tiene transparencia referencial.

Esto es, «el  contenido de información de cada especificación de caja basta para definir su refinamiento, sin depender de la implementación de ninguna otra caja». Esto capacita al analista para desglosar jerárquicamente el sistema, pasando de la representación esencial situada en la parte superior, hasta los detalles específicos de la implementación situados en la parte inferior. Se utilizan tres tipos de ca-jas descubrir los errores) y depurado después (para eliminar los errores). Cuando se publica finalmente el software, la utilización práctica descubre aun más defectos, y comienza otro ciclo de comprobación y depuración. Este trabajo repetido asociado a las actividades mencionadas resulta costoso y lleva mucho tiempo. Y lo que es peor, puede ser degenerativo; la corrección de errores puede (inadvertidamente) dar lugar a la introducción de otros errores.

En la ingeniería del software de sala limpia, la comprobación unitaria y la depuración se ven sustituidas por una verificación de corrección y por pruebas basadas en la estadística. Estas actividades, junto con el mantenimiento de registros para una continua mejora, hacen que el enfoque de sala limpia sea único.

Caja negra. Esta caja especifica el comportamiento del sistema, o de parte de un sistema. El sistema (o parte de él) responde a estímulos específicos (sucesos) mediante la aplicación de un conjunto de reglas de transición que hacen corresponder el estímulo con la respuesta.

Caja de estado. Esta caja encapsula los datos de estados y de servicios (operaciones) de forma análoga a los objetos. En esta vista de especificación, se representan las entradas de la caja de estados (los estímulos) y sus salidas (las respuestas). La caja de estados también representa la «historia de estímulos» de la caja negra, es decir, los datos encapsulados en la caja de estado que deben ser mantenidos entre las transiciones implicadas.

Caja limpia. Las funciones de transición que están implicadas en la caja de estado se definen en la caja limpia. Dicho literalmente, la caja limpia contiene el diseño procedimental correspondiente a la caja de estados.

A medida que se va realizando cada uno de estos pasos de refinamiento, se produce también una verificación de la corrección. Se verifican las especificaciones de las cajas de estado para asegurar que todas y cada una de ellas se ajustan al comportamiento definido por la especificación de la caja negra predecesora. De manera similar, se verifican las especificaciones de las cajas transparentes con respecto a la caja de estados predecesora.


Es preciso tener en cuenta que los métodos de especificación basados en métodos formales se pueden utilizar en lugar del enfoque de especificación de estructura de cajas. El unico requisito es que se puede verificar formalmente cada uno de los niveles de especificación.

Especificación de caja negra

Una especificación de caja negra describe una abstracción, estímulos y respuestas. La funciónf'se aplica a una secuencia, S*, de entradas (estímulos) y esta función los transforma en una salida (respuesta), R. Para componentes sencillos de software,f; puede ser una función matemática, pero en genera1,f se describe empleando el lenguaje natural (o bien un lenguaje de especificación formal).

Muchos de los conceptos introducidos para sistemas orientados a objetos son aplicables también para la caja negra. Las abstracciones de datos y las operaciones que manipulan estas abstracciones, se ven encapsuladas por la caja negra. Al igual que una jerarquía de clases, la especificación de caja negra puede mostrar las jerarquías de utilización en que las cajas de nivel inferior heredan las propiedades de las cajas de nivel superior dentro de la estructura de árbol.

Especificación de caja de estado


La caja de estado es «una generalización sencilla de una máquina de estado». Recordando la descripción del modelado de comportamiento y de los diagramas de transición de estados que se ofrece en el Capítulo 12, un estado es algún modo observable de comportamiento del sistema. A medida que se produce el procesamiento, el sistema va respondiendo a sucesos (estímulos) efectuando una transición que parte del estado y llega a algún nuevo estado. A medida que se efectúa la transición, puede producirse una acción. La caja de estado utiliza una abstracción de datos para determinar la transición al estado siguiente (respuesta) que se producirá como consecuencia de la transición.

Según se muestra en la fig.  la caja de estado contiene una caja negra. El estímulo, S, que se introduce en la ca-ja negra, procede de alguna fuente externa y de un conjunto de estados internos del sistema, T. Mills proporciona una descripción matemática de la función,,f, de la caja negra contenida en el seno de la caja de estado:

g:S*xT*+RxT

donde g es una subfunción que está asociada a un estado específico t. Cuando se consideran en su conjunto, las parejas de estados y subfunciones (t, g) definen la función de caja negra.6.

Especificación de caja limpia.

 La especificación de caja limpia está íntimamente relacionada con el diseño de procedimientos y con la programación estructurada. En esencia, la subfunción g, que se encuentra dentro de la caja de estado, se ve sustituidapor las estructuras de programación estructurada que implementa g.

Como ejemplo, considérese la caja limpia que se muestra en la Figura.  La caja negra g, que se muestra en Figura 26.4 se ve sustituida por una sucesión de estructuras que contienen una estructura condicional. Éstas, a su vez, se pueden refinar para formar Lajas transparentes del interior a medida que vaya avanzando el procedimiento de refinamiento progresivo.

Es importante tener en cuenta que la especificación de procedimientos descrita en la jerarquía de caja liinpia se puede demostrar a efectos de corrección. Este tema se considerará en la sección siguiente.

REFINAMIENTO Y VERIFICACIÓN DEL DISEÑO.

El enfoque de diseño que se utiliza en la ingeniería del software de sala limpia hace mucho uso de la filosofía de la programación estructurada. Pero, en este caso, la programación estructurada se aplica de forma mucho más rigurosa.

La funciones básicas de procesamiento (que se describían durante los refinamientos anteriores de la especificación) se refinan ahora utilizando una «expansión progresiva de funciones matemáticas en estructuras de conectividad lógica [por ejemplo, si-entonces-sino] y subfunciones, donde la expansión [se] efectúa hasta que todas las funciones identificadas pudieran ser enunciadas directamente en el lenguaje de programación utilizado para la implementación».

El enfoque de la programación estructurada se puede utilizar de forma eficiente para refinar la función, pero ¿qué pasa con el diseño de datos'? En este aspecto, entra en juego un cierto número de conceptos fundamentales de diseño. Los datos del programa se encapsulan como un conjunto de abstracciones a las cuales prestan servicio las subfuncionec. Los conceptos de encapsulamiento de datos, ocultamiento de información y los tipos de datos se utilizan entonces para crear el diseño de datos.

Refinamiento y verificación del diseño.

Cada especificación de caja limpia representa el diseño de un procedimiento (subfunción) necesario para efectuar una transición de caja de estado. Mediante la caja limpia, se utilizan las estructuras de programación estructurada y de refinamiento progresivo. Una función de programa, .f; se refina para dar lugar a una sucesión de subfunciones 8 y h. Éstas a su vez se refinan para formar estructurascondicionales (si-entonces-sino y hacer-mientras). Un refinamiento posterior ilustra la elaboración lógica continuada.

Para lograr una verificacion formal de correccion, se asocia un conjunto de condiciones de corrección genéricas a las estructuras de programación estructurada. Si se expande una función f para dar una sucesión g y h, entonces la condición de corrección para todas las  entradas defes:

¿Es cierto que g seguido por h da lugar af!

Si se refina una función p para llegar a una estructura condicional (si-entonces-sino), la condición de corrección para toda entrada de p es: ;Siempre que sea cierta la condición (c) es cierto que q realizap y siempre que (c) sea falsa, es cierto que Y realizap? Si se refina una función m en forma de bucle, las condiciones de corrección para todas las entradas de ni son:

¿Está garantizada la finalización?

¿Siempre que (c) sea verdadera es cierto que IZ seguido por m realiza m, siempre que (c) seafalso, sigue realizándose m si se obvia el bucle?

Cada vez que se refina una caja limpia hasta el siguiente nivel de detalle, se aplican las condiciones de corrección indicadas anteriormente.

Es importante tener en cuenta que la utilización de estructuras de programación estructurada restringe el número de comprobaciones de corrección que es preciso efectuar. Se verifica una sola condición en busca de sucesiones; se verifican dos condiciones para los sientonces- sino; y se verifican tres condiciones para los bucles.

Con objeto de ilustrar alguna verificación de corrección para un diseño de procedimientos, se utiliza un sencillo ejemplo presentado por primera vez por parte de Linger y sus colaboradores. Nuestro objetivo es diseñar y verificar un pequeño programa que calcule la parte entera, y, de una raíz cuadrada de un entero dado, x Para verificar la corrección de este diseño, es preciso definir las condiciones de entrada y de salida. La condición de entrada indica que x debe ser mayor o igual a O. La condición de salida requiere que x permanezca intacta y que adopte un valor dentro del intervalo mostrado en la figura. Para demostrar que el diseño es correcto, es necesario demostrar que las condiciones son ciertas en todos los casos. En algunas ocasiones se denominan subdemostraciones

Resolución de  caso Aplicando Método de sala limpia
Caja Negra:

F: es la función de validación en General de los Datos.
E: conjuntos de entradas
T: estado de los datos correctos o incorrectos
R: es la respuesta
.





Caja de Estado

F: es la función de validación en General de los Datos.
E: conjuntos de entradas
T: estado de los datos correctos o incorrectos
R: es la respuesta

 


Caja Transparente.

F: es la función de validación en General de los Datos.
E: conjuntos de entradas
T: estado de los datos correctos o incorrectos
R: es la respuesta
 


Fuente:
Ingeniería del Software, un enfoque práctico
Roger S. Pressman
McGraw-Hill, 2006 - 958 páginas