jueves, 21 de mayo de 2009

lunes, 18 de mayo de 2009

Ingeniería del Software Asistida Por Computadora

Todo el mundo ha oído ese proverbio que habla de los hijos del zapatero: el zapatero está tan ocupado haciendo zapatos para los demás que sus hijos no tienen sus propios T zapatos. Antes de los años 90, muchos de los ingenieros de software fueron los hijos del zapatero. Aunque estos profesionales técnicos construyeron sistemas complejos y productos que automatizan los trabajos de otros, no utilizaron mucha automatización para ellos mismos.

En la actualidad, los ingenieros de software han recibido por fin su primer par de zapatos nuevos -la ingeniería del software asistida por computadora (CASE)-. Los zapatos no vienen con tanta variedad como querrían, a veces son un poco duros y en algunos casos resultan incómodos, no proporcionan una sofisticación suficiente para los que los gustan de vestir bien, y no siempre coinciden con la ropa que utilizan los que desarrollan el software. Ahora bien, suponen una prenda absolutamente esencial en el guardarropa del que desarrolla el software y, con el tiempo, serán más cómodos, se utilizarán con más facilidad y se adaptarán mejor a las necesidades de cada uno de los desarrolladores.

En este capítulo, nuestro centro de interés se desplaza hacia las herramientas y entornos que ayudarán a automatizar el proceso del software.

¿Que es CASE?

El taller de ingeniería del software se denomina un entorno de apoyo integrado a proyectos, y el conjunto de herramientas que llena ese taller se denomina ingeniería del software asistida por computadora (CASE).

CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar que la calidad se diseñe antes de llegar a construir el producto.

Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill

Reingenieria

La Reingeniería de procesos de negocio, RPN (Business Process Reingineering, BPR2) va más allá del ámbito de las tecnologías de la información y de la ingeniería del software. Entre las muchas definiciones (la mayoría de ellas, algo abstractas) que se han sugerido para la RPN, se cuenta con una publicada en la revista Fortune [STE93]: «. . .la búsqueda e implementación de cambios radicales en el proceso de negocios para lograr un avance significativo». Ahora bien ¿cómo se efectúa la búsqueda, y cómo se lleva a cabo la implementación? O lo que es más importante, ¿cómo podemos estar seguros de que el «cambio radical» que se sugiere va a dar lugar realmente a un «avance significativo» en lugar de conducimos a un caos organizativo?

Procesos de negocios

Un proceso de negocio es «un conjunto de tareas lógicamente relacionadas que se llevan a cabo para obtener un determinado resultado de negocio» [DAV90]. Dentro del proceso de negocio, se combinan las personas, los equipos, los recursos materiales y los procedimientos de negocio con objeto de producir un resultado concreto. Entre los ejemplos de negocio se incluyen el diseño de un nuevo producto, la adquisición de servicios y suministros, la contratación de nuevos empleados o el pago a proveedores. Cada una requiere un conjunto de tareas y se basa en diversos recursos dentro del negocio.

Cada proceso de negocio posee un cliente bien definido -una persona o grupo que recibe el resultado (por ejemplo: una idea, un informe, un diseño, un producto). Además, los procesos de negocio cruzan los límites organizativos. Requieren que distintos grupos de la organización participen en las «tareas lógicamente relacionadas » que definen el proceso.

Principios de reingeniería de procesos

En muchos aspectos, la RPN tiene un objetivo y un ámbito idéntico al proceso de la ingeniería de la información

(Capítulo 10). Lo ideal sería que la RPN se produjera de forma descendente, comenzando por la identificación de los objetivos principales del negocio, y culminando con una especificación mucho más detallada de las tareas que definen un proceso específico de negocios. Hammer [HAM90] sugiere una serie de principios que nos guiarán por las actividades de la RPN cuando se comienza en el nivel superior (de negocios):

Organización en torno a los resultados, no en torno a las tareas. Hay muchas compañías que poseen actividades de negocio compartimentadas, de tal modo que no existe una Única persona (u organización) que tenga la responsabilidad (o el control) de un cierto resultado de negocio. En tales casos, resulta difícil determinar el estado del trabajo e incluso más difícil depurar los problemas de proceso cuando esto sucede. La RPN deberá diseñar procesos que eviten este problema.

Hay que hacer que quienes utilicen la salida del proceso lleven a cabo el proceso. El objetivo de esta recomendación es permitir que quienes necesiten las salidas del negocio controlen todas las variables que les permitan obtener esa salida de forma temporalmente adecuada. Cuanto menor sea el número de personas distintas implicadas en el proceso, más fácil será el camino hacia un resultado rápido.

Hay que incorporar el trabajo de procesamiento de información al trabajo real que produce la información pura. A medida que la TI se distribuye, es posible localizar la mayor parte del procesamiento de información en el seno de la organización que produce los datos. Esto localiza el control, reduce el tiempo de comunicación y la potencia de computación se pone en manos de quienes tienen fuertes intereses en la información producida.

Hay que manipular recursos geográficamente dispersos como si estuviesen centralizados. Las comunicaciones basadas en computadoras se han sofisticado tanto que es posible situar grupos geográficamente dispersos en una misma «oficina virtual». Por ejemplo, en lugar de emplear tres turnos de ingeniería en una única localización, toda la compañía podrá tener un turno en Europa, un segundo turno en Norteamérica y un tercer turno en Asia. En todos los casos, los ingenieros trabajarán durante el día y se comunicarán empleando redes de un elevado ancho de banda.

Hay que enlazar las actividades paralelas en lugar de integrar sus resultados. Cuando se utilizan diferentes grupos de empleados para realizar tareas en paralelo, es esencial diseñar un proceso que exija una continuación en la comunicación y coordinación. En caso contrario, es seguro que se producirán problemas de integración.

Hay que poner e1 punto de decisión en el lugar donde se efectúa el trabajo, e incorporar el control al proceso. Dentro de la jerga del diseño del software, esto sugiere una estructura organizativa más uniforme y con menos factorización.

Hay que capturar los datos una sola vez, en el lugar donde se producen. Los datos se deberán almacenar en computadoras, de tal modo que una vez recopilados no sea necesario volver a introducirlos nunca.

Todos y cada uno de los principios anteriores representan una visión dotalmente general» de la RPN. Una vez informados por estos principios, los planificadores de negocios y los diseñadores de procesos deberán empezar a procesar el nuevo diseño.

Reingeniería del Software

Este escenario resulta sumamente conocido: Una aplicación ha dado servicio y ha cubierto las necesidades del negocio de una compañía durante diez o quince años.

A lo largo de este tiempo, ha sido corregida, adaptada y mejorada muchas veces. Las personas se dedicaban a esta tarea con la mejor de sus intenciones, pero las prácticas de ingeniería del software buenas siempre se echaban a un lado (por la urgencia de otros problemas). Ahora la aplicación se ha vuelto inestable. Sigue funcionando, pero cada vez que intenta efectuar un cambio se producen efectos colaterales graves e inesperados.

¿Qué se puede hacer? La imposibilidad de mantener el software no es un problema nuevo. De hecho, el gran interés por la reingeniería del software ha sido generado por un «iceberg» de mantenimiento de software que lleva creciendo desde hace más de treinta años.

Un modelo de procesos de reingeniería

La reingeniería requiere tiempo; conlleva un coste de dinero enorme y absorbe recursos que de otro modo podrían emplearse en preocupaciones más inmediatas. Por todas estas razones, la reingeniería no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos años. La reingeniería de sistemas de información es una actividad que absorberá recursos de las tecnologías de la información durante muchos años. Esta es la razón por la cual toda organización necesita una estrategia pragmática para la reingeniería del software.

Una estrategia de trabajo también acompaña al modelo de procesos de reingeniería.

La reingeniería es una tarea de reconstrucción, y se podrá comprender mejor la reingeniería de sistemas de información si tomamos en consideración una actividad análoga: la reconstrucción de una casa. Consideremos la situación siguiente:

Suponga que ha adquirido una casa en otro lugar.

Nunca ha llegado a ver la finca realmente, pero la consiguió por un precio sorprendentemente reducido, advirtiéndosele que quizá fuera preciso reconstruirla en su totalidad. ¿Cómo se las arreglaría?

· Antes de empezar a construir, sería razonable inspeccionar la casa. Para determinar si necesita una reconstrucción, usted (o un inspector profesional) creará una lista de criterios para que la inspección sea sistemática.

· Antes de derribar y de construir toda la casa, asegúrese de que la estructura está en mal estado. Si la casa tiene una buena estructura, quizá sea posible remodelarla sin reconstruirla (con un coste muy inferior y en mucho menos tiempo).

· Antes de empezar a reconstruir, asegúrese de que entiende la forma en que se construyó el original. Eche una ojeada por detrás de las paredes. Comprenda el cableado, la fontanería y los detalles internos de la estructura. Aunque vaya a eliminarlos todos, la idea que haya adquirido de ellos le servirán de mucho cuando empiece a construirla.

· Si empieza a reconstruir, utilice tan solo los materiales más modernos y de mayor duración. Quizá ahora le cuesten un poquito más, pero le ayudarán a evitar un mantenimiento costoso y lento en fecha posterior. Si ha decidido reconstruir, tenga una actitud disciplinada. Utilice prácticas que den como resultado una gran calidad -tanto hoy como en el futuro.

Aunque los principios anteriores se centran en la reconstrucción de una casa, son aplicables igualmente a la reingeniería de sistemas y aplicaciones basados en computadoras.


Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill

Ingenieria Web



La 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?

La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía.

Desde que esto empezó a suceder el Internet se volvió más que una diversión y empezó a ser más serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafío para los ingenieros del software, a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías donde tuvieron en cuenta aspectos específicos de este nuevo medio.

Uno de los aspectos más tenidos en cuenta, en el desarrollo de sitios web es sin duda alguna el diseño gráfico y la organización estructural del contenido. En la actualidad la web esta sufriendo grandes cambios, que han obligado a expertos en el tema a utilizar herramientas y técnicas basadas en la ingeniería del software, para poder garantizar el buen funcionamiento y administración de los sitios web.

Ahora para garantizar el buen funcionamiento y mantenimiento de los sitios web, este debe contar con ciertos atributos y características que en conjunto forman un concepto muy importante, para alcanzar el éxito en cualquier organización, herramienta, y todo aquello que se pueda considerar como servicio. Dicho concepto es la calidad, que con atributos como, usabilidad, navegabilidad, seguridad, mantenibilidad, entre otros, hace posible por un lado la eficiencia del artefacto web y por ende la satisfacción del usuario final.

Pero para tener artefactos de calidad, a esa misma se le debe planificar, programar y controlar, es decir la calidad no podrá ser agregada a un artefacto web o a cualquier otro producto, al final del proceso de desarrollo, si no que se deberá implementar durante todo el ciclo de vida del desarrollo. Para finalizar el resultado de un proceso de calidad, podría arrojar recomendaciones para introducir mejoras, y la decisión final podría consistir en lanzar una nueva versión del sitio web o en modificar algunos atributos ausentes o pobremente diseñados.

Cabe destacar que la ingeniería de la web hace una diferencia entre un sitio web y un aplicativo, ya que la ingeniería de la web no se dedica a la construcción de sitios web si no a la construcción de aplicativos web, la principal característica que los distingue (aplicativos de sitios web) es que los sitios web son sitios en la web en donde se publica contenido generalmente estático o un muy bajo nivel de interactividad con el usuario, mientras que los aplicativos son lugares con alto contenido de interactividad y funcionalidades que bien podrían ser de un software convencional, el aplicativo web más sencillo seria uno que contenga formularios y subiendo de nivel encontramos los que realizas conexión con bases de datos remotas, y administradores de contenidos entre otras.

Entonces la ingeniería de la Web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. En este sentido, la ingeniería de la Web hace referencia a las metodologías, técnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web complejas y de gran dimensión en las que se apoya la evaluación, diseño, desarrollo, implementación y evolución de dichas aplicaciones.

El desarrollo de aplicaciones Web posee determinadas características que lo hacen diferente del desarrollo de aplicaciones o software tradicional y sistemas de información. La ingeniería de la Web es multidisciplinar y aglutina contribuciones de diferentes áreas: arquitectura de la información, ingeniería de hipermedia/hipertexto, ingeniería de requisitos, diseño de interfaz de usuario, usabilidad, diseño gráfico y de presentación, diseño y análisis de sistemas, ingeniería de software, ingeniería de datos, indexado y recuperación de información, testeo, modelado y simulación, despliegue de aplicaciones, operación de sistemas y gestión de proyectos.

La ingeniería de la Web no es un clon o subconjunto de la ingeniería de software aunque ambas incluyen desarrollo de software y programación, pues a pesar de que la ingeniería de la Web utiliza principios de ingeniería de software, incluye nuevos enfoques, metodologías, herramientas, técnicas, guías y patrones para cubrir los requisitos únicos de las aplicaciones web. Sin embargo el término de ingeniería de la web ha sido un término muy controversial especialmente para profesionales en disciplinas tales como la ingeniería del software ya que no la consideran como un campo dentro de la ingeniería

Los principales aspectos de la ingeniería de la Web incluyen, entre otros, los siguientes temas:

* Diseño de procesos de negocio para aplicaciones web.

* Herramientas CASE para aplicaciones web.

* Generación de código para aplicaciones web.

* Desarrollo web colaborativo.

* Modelado conceptual de aplicaciones web.

* Diseñó de Modelos de datos para sistemas de información web.

* Ingeniería web empírica.

* Entornos de desarrollo de aplicaciones web integrados.

* Herramientas de autor para contenido multimedia.

* Pruebas de rendimiento de aplicaciones basadas en web.

* Personalización y adaptación de aplicaciones web.

* Modelado de procesos para aplicaciones web.

* Herramientas y métodos de prototipado.

* Control de calidad y pruebas de sistemas.

* Ingeniería de requisitos para aplicaciones web.

* Aplicaciones para la Web Semántica.

* Factorías de software para la web.

* Métodos, herramientas y automatización de pruebas para aplicaciones web.

* Aplicaciones web móviles y ubícuas.

* Usabilidad de aplicaciones web.

* Accesibilidad para la web.

* Metodologías de diseño web.

* Formación en ingeniería de la web.

* Diseño de interfaces de usuario.

* Métricas para la web, estimación de costes y medición.

* Gestión de proyectos web y gestión de riesgos.

* Desarrollo y despliegue de servicios web.


Categorías

Los sitios web pueden ser categorizados de la siguiente forma:

* Sólo estático que se enfoca en la organización de la estructura y el contenido, en la forma como se va a presentar la información y que sea fácil de manejar para cualquier usuario, pero debe tener en cuenta la eficiencia y la confiabilidad.

* Sitio estático con formularios de entrada este sitio tiene las mismas características que el anterior, adicionándole que el le permite a los usuarios la interacción por medio de cuestionarios, comentario y sugerencias.

* Sitio con acceso de datos dinámicos aquí, además de las características antes mencionadas, cuenta con bases de datos en las cuales el usuario puede realizar consultas y búsquedas.

* Sitio creado dinámicamente en este sitio los requerimientos son parecidos pero deben suplir con las necesidades de cada usuario; creando sitios dinámicos que sean compatibles con el entorno de navegación de cada usuario.

* Aplicación de software basada en la Web este sitio puede tener todas las características antes mencionadas, pero logrando un parecido con una implementación cliente/servidor comúnmente conocido que a un sitio web estático.

Con el pasar del tiempo y la constante evolución tecnológica que atraviesa nuestro mundo circundante hemos podido observar la necesidad y la utilidad de la red de redes; Internet para mejorar de cierta manera nuestras condiciones de vida y así fortalecer más nuestro proceso de formación educativa y contribuir con un mejoramiento del global de las necesidades de cada quien observemos que un proyecto que comenzó meramente con fines militares para no centralizar los datos, ha tenido un crecimiento significable hoy en día el mundo se mueve con la web, ayudando a pequeñas, medianas y grandes empresas a si como todo entidad educativa.

Tengamos en cuenta que empresas mueven sus negocios por medio de la internet y que hasta políticas como el CRM para el manejo de clientes, son muy importantes para las empresas como por ejemplo, Dell, surgen políticas para el mantener los clientes y tenerlos en contactos vía Web, mediante Internet se cuidada de cierta manera la imagen de una empresa, por ejemplo mediante el marketing a través de Internet permite reforzar el servicio, haciendo más fuerte la relación entre la marca y el cliente.

Esto implica un uso creativo del medio, involucrando verdaderamente a las personas con la compañía. Utilizando la inmediatez, que brinda esta vía de comunicación. Con la herramienta comunicacional, se permite una relación constante e inmediata con los clientes, así como mantener a los clientes contentos, conquistar nuevos nichos de mercado y, por ende, incrementar las ventas.

Debemos tener en cuenta que para la efectiva comunicación en la web , se tienen protocolos que es como el lenguaje para que se haga efectiva el intercambio de comunicación, vale la pena preguntarse, así para poder acceder a toda la información que nos puede suministrar Internet sólo debes poseer un servicio de algún proveedor de Internet un navegador como Mozilla o Netscape.

Por medio de un sitio web podremos tener nuestro sitio accesible o disponible 24 horas al día, 365 días del año en absolutamente todo el mundo para quienes tienen acceso; es decir, cerca de 600 millones de personas aproximadamente, es por esto que nuestros datos en internet publicados en el sitio web podrían ser accesibles a toda persona en cualquier momento en cualquier parte del mundo.

Todas estas consideraciones nos llevan a la conclusión de que un sitio web bien logrado no es únicamente un espacio en la red para ver el mismo comercial que en televisión; es en realidad una extensión de las empresas o instituciones, así mismo teniendo en cuenta la importancia y aplicabilidad que tiene la ingeniería Web en nuestro desarrollo cognitivo, social y vivencial es fácil visionar que cada una de las funciones que ella emana estarán siempre ligadas a la vanguardia del desarrollo progresivo de la tecnología y del hombre.

Naturaleza Multidisciplinar

La ingeniería del software, incluye nuevas metodologías de desarrollo esenciales para la administración de proyectos. Actualmente la ingeniería web ha adoptado también metodologías de la ingeniería del software y ha creado muchas nuevas. Debido a que la información es publicada para conocimiento de todo el mundo, hay que tener muy en cuenta aspectos sociales, jurídicos y éticos que pueden influir a la hora de la publicación. De acuerdo con esto, la ingeniería Web puede utilizar una parte de cada una de estas disciplinas y no ser dominada por puntos de vista muy particulares, es una respuesta de carácter multidisciplinario para las aplicaciones Web.

Usualmente, las aplicaciones web son multidisciplinares, ya que son construidas en un medio constantemente cambiante, donde los requerimientos son inestables, los equipos de desarrollo generalmente son pequeños, las comunidades de usuarios son más amplias que antes y la competición ahora es a nivel mundial. En general, las aplicaciones web, necesitan ser funcionales, mantenibles, escalables y seguras. Como podemos ver, la actual demanda de las aplicaciones web es totalmente diferente de las aplicaciones convencionales y por lo tanto hay una gran necesidad de la ingeniería web.

Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill

Ingenieria del Software del Comercio Electronico

A finales de siglo, el desarrollo de una nueva generación de máquinas herramientas capaces de soportar fuertes tolerancias dieron poder a los ingenieros que diseñaban un pro- A ceso nuevo de fabricación llamado producción en masa. Antes de la llegada de esta tecnología avanzada de máquinas herramientas, no se podían soportar fuertes tolerancias. Pero con esta tecnología se podían construir piezas intercambiables y fácilmente ensamblables - la piedra angular de la producción en masa-.

Cuando se va a desarrollar un sistema basado en computadora, un ingeniero de software se ve restringido por las limitaciones de las tecnologías existentes y potenciadas cuando las tecnologías nuevas proporcionan capacidades que no estaban disponibles para las generaciones anteriores de ingenieros. La evolución de las arquitecturas distribuidas de computadora ha capacitado a los ingenieros de sistemas y del software para desarrollar nuevos enfoques sobre cómo se estructura el trabajo y cómo se procesa la información dentro de una empresa.

Las nuevas estructuras de las organizaciones y los nuevos enfoques de proceso de información (por ejemplo: tecnologías intranet e Internet, sistemas de apoyo a las decisiones, software de grupo, e imágenes) representan una salida radical de las primeras tecnologías basadas en minicomputadoras o en mainframes. Las nuevas arquitecturas de computadora han proporcionado la tecnología que ha hecho posible que las empresas vuelvan a diseñar sus procesos de negocio.

En este capítulo, examinaremos una arquitectura dominante para el proceso de información -los sistemas cliente servidor (C/S) dentro del contexto de los sistemas de comercio electrónico-. Los sistemas cliente servidor han evolucionado junto con los avances de la informática personal, en la ingeniería del software basada en componentes, con las nuevas tecnologías de almacenamiento, comunicación mejorada a través de redes, y tecnología de bases de datos mejoradas.

Los últimos diez años han sido testigos de avances masivos en las áreas de computación. La primera es que el hardware se ha ido abaratando cada vez más, y a su vez se ha ido haciendo más potente: las computadoras de sobremesa hoy en día tienen la potencia que poseían los mainframes hace algunos años. La segunda área es la de las comunicaciones; avances tales como los sistemas de comunicación vía satélite y los sistemas de teléfonos digitales significa que ahora es posible conectar económicamente y eficientemente con otros sistemas informáticos separados físicamente. Esto ha llevado al concepto de un sistema de computación distribuido. Dicho sistema consiste en un número de computadoras que están conectadas y que llevan a cabo diferentes funciones. Existen muchas razones por las que tales sistemas se han hecho populares:

Rendimiento. El rendimiento de muchos tipos de sistemas distribuidos se puede incrementar añadiendo simplemente más computadoras. Normalmente esta es una opción más sencilla y más barata que mejorar un procesador en un mainframe. Los sistemas típicos en donde se puede lograr este incremento en el rendimiento son aquellos en donde las computadoras distribuidas llevan a cabo mucho proceso, y en donde la relación trabajo de comunicaciones y proceso es bajo.

Compartición de recursos. Un sistema distribuido permite a sus usuarios acceder a grandes cantidades de datos que contienen las computadoras que componen el sistema. En lugar de tener que reproducir los datos en todas las computadoras se pueden distribuir por un pequeño número de computadoras. Un sistema distribuido también proporciona acceso a servicios especializados que quizás no se requieran muy frecuentemente, y que se puedan centralizar en una computadora del sistema.

Tolerancia a fallos. Un sistema distribuido se puede diseñar de forma que tolere los fallos tanto del hardware como del software. Por ejemplo, se pueden utilizar varias computadoras que lleven a cabo la misma tarea en un sistema distribuido. Si una de las computadoras funcionaba mal, entonces una de sus hermanas puede hacerse cargo de su trabajo. Una base de datos de una computadora se puede reproducir en otras computadoras de forma que si la computadora original tiene un mal funcionamiento, los usuarios que solicitan la base de datos son capaces de acceder a las bases de datos reproducidas.

Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill

Ingenieria del Software de 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 [LIN94]:

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 prueba Su modelo de proceso incluye la certificación estadística de calidad de los incrementos de código, a medida que estos se van añadiendo con el sistema.

En muchos aspectos, el enfoque de sala limpia eleva la ingeniería del software a otro nivel.

Al igual que las técnicas de métodos formales, 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 Resultante 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.

EL ENFOQUE DE SALA LIMPIA

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 [WIL87] durante los años 80. Aun cuando las primeras experiencias acerca de este enfoque disciplinado para los trabajos relacionados con el software mostraban promesas significativas [HAU94], no ha alcanzado una amplia utilización. Henderson [HEN95] sugiere tres posibles razones:

· 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.

· 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

· 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 beneficios 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.

Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill

Ingenieria del Software Basada en Componentes



INGENIERÍA DEL SOFTWARE BASADA EN COMPONENTES

En el contexto de la ingeniería del software, la reutilización se puede considerar una idea nueva y antigua. Los programadores han reutilizado ideas, abstracciones y procesos desde el principio de la era de los computadores, pero el primer enfoque de reutilización era muy concreto. Hoy en día, los sistemas complejos y de alta calidad basados en computadora se deben construir en períodos de tiempo muy cortos. Esto se mitiga con un enfoque de reutilización
Más organizado.
La ingeniería del software basada en componentes (ISBC) es un proceso que se centra en el diseño y construcción de sistemas basados en computadora que utilizan «componentes» de software reutilizables. Clements [CLE95] describe la ISBC de la manera siguiente:
[La ISBC] está cambiando la forma en que se desarrollan los sistemas de software. [La ISBC] representa la filosofía de «comprar, no construir», que expusieron Fred Brooks y otros. De la misma manera que las primeras subrutinas liberaban al programador de tener que pensar en detalles, [ISBC] cambia su objetivo y pasa de programar el software a componer sistemas de software. La implementación ha dado paso a la integración como núcleo del enfoque. Se puede decir que en su base se encuentra la suposición de que en muchos sistemas grandes de software existe una base común suficiente como para justificar los componentes reutilizables para explotar y satisfacer a esa base común.

Superficialmente, la ISBC parece bastante similar a la ingeniería del software orientada a objetos. El proceso comienza cuando un equipo de software establece los requisitos del sistema que se va a construir utilizando las técnicas convencionales de obtención de requisitos. Se establece un diseño arquitectónico, pero en lugar de entrar inmediatamente en tareas de diseño detalladas, el equipo examina los requisitos para determinar cuál es el subsistema que está dispuesto para la composición, y no para la construcción. Esto es, el equipo formula las siguientes preguntas para todos y cada uno de los requisitos del sistema: ¿Es posible disponer de componentes comerciales ya desarrollados (CYD) para implementar el requisito? ¿Se dispone de componentes reutilizables desarrollados internamente para implementar el requisito? ¿Son compatibles las interfaces de los componentes que están disponibles dentro de la arquitectura del sistema a construir? El equipo intenta modificar o eliminar aquellos requisitos del sistema que no se pueden implementar con componentes CYD o de desarrollo propio'. Si los requisitos no se pueden ni cambiar ni borrar, se aplican métodos de ingeniería del software convencional u orientado a objetos para desarrollar los componentes nuevos que se deben diseñar para cumplir los requisitos.
Pero para esos requisitos que se afrontan con los componentes disponibles comienza un conjunto diferente de actividades de ingeniería del software:
Cualificación de componentes. Los requisitos del sistema y la arquitectura definen los componentes que se van a necesitar. Los componentes reutilizables (tanto si son CYD como de desarrollo propio) se identifican normalmente mediante las características de sus interfaces.
Es decir, se describen «los servicios que se proporcionan y el medio por el que los consumidores acceden a estos servicios» [BR096] como parte de la interfaz del componente. Pero la interfaz no proporciona una imagen completa del acople del componente en la arquitectura y en los requisitos. El ingeniero del software debe de utilizar un proceso de descubrimiento y de análisis para cualificar el ajuste de cada componente.

Adaptación de componentes. La arquitectura del software representa los patrones de diseño que están compuestos de componentes (unidades de funcionalidad), conexiones y coordinación.
Esencialmente la arquitectura define las normas del diseño de todos los componentes, identificando los modos de conexión y coordinación. En algunos casos, es posible que los componentes reutilizables actuales no se correspondan con las normas del diseño de la arquitectura.
Estos componentes deben de adaptarse para cumplir las necesidades de la arquitectura o descartarse y reemplazarse por otros componentes más adecuados.
Composición de componentes. El estilo arquitectónico vuelve a jugar un papel clave en la forma en que los componentes del software se integran para formar un sistema de trabajo. Mediante la identificación de los mecanismos de conexión y coordinación (por ejemplo, las propiedades de ejecución en el diseño), la arquitectura dicta la composición del producto final.
Actualización de componentes. Cuando se implementan sistemas con componentes CYD, la actualización se complica por la imposición de una tercera parte (es decir, es posible que la empresa que desarrolló el componente reutilizable no tenga el control de la empresa de ingeniería del software).

EL PROCESO DE ISBC

El proceso ISBC se debe caracterizar de forma que no sólo identifique los componentes candidatos sino que también cualifique la interfaz de cada componente, que adapte los componentes para extraer las faltas de coincidencias arquitectónicas, que ensamble los componentes en un estilo arquitectónico seleccionado y que actualice los componentes a medida que cambian los requisitos del sistema [BR096].

El modelo de proceso para la ingeniería del software basada en componentes hace hincapié en las pistas paralelas en las que aparece concurrentemente la ingeniería del dominio con el desarrollo basado en componentes. La ingeniería del dominio realiza el trabajo que se requiere para establecer el conjunto de componentes de software que el ingeniero del software puede reutilizar. Estos componentes entonces se transfieren a través de un «límite» que separa la ingeniería del dominio del desarrollo basado en componentes.

La Figura 27.1 ilustra un modelo de proceso típico que acopla la ISBC explícitamente [CHR95]. La ingeniería del dominio crea un modelo de dominio de aplicación que se utiliza como base para analizar los requisitos del usuario en el flujo de la ingeniería del software. Finalmente, después de que se han comprado los componentes reutilizables, se han seleccionado a partir de las bibliotecas existentes o se han construido (como parte de la ingeniería del dominio), los ingenieros del software dispondrán de ellos durante la actividad de desarrollo basada en componentes.

Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill