Ingenieria Asistida por Computadoras

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



¿ Que Significa 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.


Bloques Básicos Para CASE


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 constituye la base del siguiente, con las herramientas situadas en la cima de la pila. Es interesante ver que el fundamento para un CASE efectivo tiene poco que ver con las herramientas de ingeniería del software en si mismas.


Marco de integración:  Es un conjunto de programas especializados  que permiten a cada herramienta CASE comunicarse con las demás.

Servicios de portabilidad: Este conjunto constituye un puente entre las herramientas CASE, su marco de integración y la arquitectura de entorno. De esta forma permiten que las herramientas CASE y su marco de integración puedan migrar a través de diferentes plataformas de hardware y sistemas operativos sin problemas de adaptación.

Sistema operativo: Gestiona el hardware, la red y las herramientas; mantiene el entorno unido.

Plataforma hardware: Son las estaciones de trabajo individuales interconectadas mediante la red para que los ingenieros del software puedan comunicarse de forma efectiva.

Arquitectura de entorno: Es la base del CASE, en este bloque se construyen los entornos de la ingeniería del software, engloba los sistemas de software y hardware. Además considera los patrones del trabajo humano que se aplican durante el proceso de ingeniería del software

Herramientas CASE

Clasificación de las herramientas case

Las herramientas CASE se pueden clasificar bajo diferentes enfoques:

♦ Por su función
♦ Por su papel como instrumentos para el personal técnico o los directivos.
♦ Por la arquitectura del entorno que las soporta (hardware y software)
♦ Origen

Tomando la funcionalidad como criterio principal se creó la siguiente clasificación:


Herramientas de planificación de sistemas de gestión
Proporcionan un "metámodelo" del cual se pueden obtener sistemas de información específicos,  mediante la modelización de los requisitos de información estratégica de una organización. El objetivo principal de las herramientas de esta categoría es ayudar a comprender mejor como se mueve la información.

Herramientas de gestión de proyectos
Pueden hacer estimaciones útiles de esfuerzo, coste y duración del proyecto, definir una estructura de partición del trabajo, planificación del mismo y hacer el seguimiento de proyectos de forma continua. Además se pueden utilizar para recoger datos que permitan realizar una estimación de la productividad del desarrollo y la calidad del producto.

Herramientas de planificación de proyectos:
Las herramientas que caen dentro de esta categoría se centran en dos áreas fundamentales: el esfuerzo y coste de un proyecto de software; y la planificación del proyecto.

Herramientas de seguimiento de requisitos:
El objetivo de estas herramientas es de proporcionar un enfoque sistemático para aislar requisitos, comenzando con las especificaciones del cliente. La extracción de requisitos puede ser tan sencilla como encontrar cada ocurrencia del verbo “deber”.

Herramientas de gestión y medida:
Las herramientas de medidas actuales se centran a las características del producto y del proceso.
 

Las herramientas orientadas a la gestión parten de medidas específicas del proyecto que proporcionan una indicación global de la productividad y de la calidad.

Herramientas de soporte
La categoría de herramientas de soporte engloba las herramientas de aplicación y de sistemas que complementan el proceso de ingeniería de software. Estas incluyen herramientas de documentación, herramientas para gestión de redes y software del sistema, herramientas de control de calidad y herramientas de gestión de bases de datos y de configuración del software.


Herramientas de documentación:
Las herramientas de producción de documentación y autoedición se utilizan en casi todos los aspectos de la ingeniería del software y representan una oportunidad muy interesante para todos los que desarrollan software.

Herramientas para software de sistemas:
El CASE es una tecnología de estaciones de trabajo. Por esto, el entorno CASE debe soportar software de redes de comunicación de alta calidad, correo electrónico, boletines electrónicos y otras posibilidades de comunicación.

Herramientas de control de calidad:
La mayoría de las herramientas CASE que se venden como orientadas al control de calidad, son  en realidad herramientas de medida que comprueban el código fuente para determinar su compatibilidad con lenguajes estándar. Otras herramientas extraen métricas técnicas como base para medir la calidad del software que se está desarrollando.


Herramientas de bases de datos y de GCS:
El software de gestión de bases de datos sirve como base para el establecimiento de una base de datos CASE (almacén).

Herramientas de análisis y diseño
Las herramientas de análisis y diseño permiten al ingeniero de software crear un modelo del sistema que se va a construir.

Herramientas de AE/DE:
la mayoría de las herramientas de diseño y análisis se basan en el método de análisis y diseño estructurado (AE/DE). El AE/DE es una técnica que permite al ingeniero de software crear progresivamente modelos más complejos de un sistema, comenzando en el nivel de requisitos y concluyendo con un diseño de arquitectura


Herramientas PRO/SIM:
las herramientas de creación de prototipos y de simulación (PRO/SIM) proporcionan al ingeniero de software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de que sea construido.

Herramientas para el diseño y desarrollo de interfaces:

Las herramientas de diseño y desarrollo de interfaces son, en realidad un conjunto de componentes de software, tales como menús, botones, estructuras de ventanas iconos, mecanismos de visualización, controladores de dispositivos y otros elementos de este tipo.


Herramientas de programación
Engloba los compiladores, los editores y los depuradores que se utilizan con los lenguajes de programación convencionales.

Herramientas de codificación convencionales:
durante casi 30 años las únicas herramientas disponibles para los programadores eran las herramientas convencionales de programación y por esto, cada problema de ingeniería de software era como un problema de programación.

Herramientas de codificación de cuarta generación:
los sistemas de consulta a bases de datos, los generadores de código y los lenguajes de cuarta generación han cambiado la forma de desarrollar sistemas.


Herramientas de programación orientadas a objetos:
Es una de las tecnologías más actuales de la ingeniería de software. Los entornos de programación orientados a objetos suelen estar unidos a lenguajes de programación específicos como: C++, Eiffel, Objetive-C, Smalltalk o Java.

Herramientas de creación de prototipos
La realización de prototipos es un paradigma de la ingeniería de software ampliamente utilizado, todas las herramientas de creación de prototipos se sitúan en algún lugar del espectro de implementación

Herramientas de ingeniería inversa:
utiliza como entrada el programa fuente para extraer y analizar su arquitectura, su estructura de control, el flujo lógico y la estructura y flujo de datos.

Herramientas de reingeniería:
pueden dividirse en dos subcategorías – de reestructuración de código, que aceptan como entrada código fuente si estructurar y realizan el análisis de ingeniería inversa reestructurando el código y agostándolo a los conceptos modernos de programación estructurada; de revisión de datos, que analizan las definiciones de los datos o una base de datos descrita en un lenguaje de programación o en lenguaje de descripción de base de datos, traducen esta descripción a una notación grafica que puede ser analizada por el ingeniero de software.



Ejemplos de herramientas CASE

Conclusiones

Las herramientas de ingeniería del software asistida por computadora abarcan todas las actividades del proceso del software y también aquellas actividades generales que se aplican a lo largo de todo el proceso. CASE combina un conjunto de bloques de construcción que comienzan en el nivel del hardware y del software de sistema operativo y finalizan en las herramientas individuales.

La integración entre hombre y computadora se logra mediante estándares de interfaz que se están volviendo cada vez más comunes a lo largo y ancho de toda la industria. Para facilitar la integración de los usuarios con las herramientas, de las herramientas entre sí, de las herramientas con los datos y de los datos con otros datos se diseña una arquitectura de integración

Reingenieria

La ingeniería se produce en dos niveles distintos de abstracción. En el nivel de negocios, la reingeniería se concentra en el proceso de negocios con la intención de efectuar cambios que mejoren la competitividad en algún aspecto de los negocios. En el nivel del software, la reingeniería examina los sistemas y aplicaciones de información con la intención de reestructurarlos o reconstruirlos de tal modo que muestren una mayor calidad.

Cuáles son los pasos?

El proceso de reingeniería del Software:

REINGENIERIA DE PROCESOS DE NEGOCIOS.


* La reingeniería constituye una recreación y reconfiguración de las actividades y procesos de la empresa, lo cual implica volver a crear y configurar de manera radical él o los sistemas de la compañía a los efectos de lograr incrementos significativos, y en un corto período de tiempo, en materia de rentabilidad, productividad, tiempo de respuesta, y calidad, lo cual implica la obtención de ventajas competitivas.

* Reingeniería es el rediseño rápido y radical de los procesos estratégicos de valor agregado y de los sistemas, las políticas y las estructuras organizacionales que los sustentan para optimizar los flujos de trabajo y la productividad de una organización.




Procesos de negocios

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

Todo sistema es en realidad una jerarquía de subsistemas.

Cada uno de los sistemas de negocios (también llamados función  de negocios) están compuestos por uno o más procesos de negocio, y cada proceso de negocio está definido por un conjunto de subprocesos.

La RPN se puede aplicar a cualquier nivel de la jerarquía, pero a medida que se amplía el ámbito de la RPN (esto es, a medida que se asciende dentro de la jerarquía) los riesgos asociados a la RPN crecen de forma dramática. Por esta razón, la mayor parte de los esfuerzos de la RPN se centran en procesos o subprocesos individuales.

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




Modelo de reingeniería de procesos de negocio

 

Advertencias:

Es muy frecuente que se exagere la importancia de un nuevo enfoque de negocio - e n este caso, la RPN como si fuese la panacea, para después criticarla con tanta severidad que pase a ser un desecho. A lo largo de los Últimos años, se ha debatido de forma exagerada acerca de la eficacia de la RPN. En un resumen excelente del caso a favor  y en contra de la RPN, Weisz  expone su argumento de la manera siguiente:

Resulta tentador atacar a la RPN como si se tratase de otra reencarnación de la famosa bala de plata. Desde varios puntos de vista -pensamiento de sistemas, tratamiento de personal, simple historia- habría que predecir unos índices de fallos elevados para el concepto, índices que parecen ser confirmados por la evidencia empírica. Para muchas compañías parece  que la bala de plata no da en el blanco.

Para otras, sin embargo, el nuevo esfuerzo de la reingeniería ha tenido evidentemente su fruto.

La RPN puede funcionar, si es aplicada por personas motivadas y formadas, que reconozcan que el proceso de reingeniería es una actividad continua. Si la RPN se lleva a cabo de forma efectiva, los sistemas de información se integran mejor con los procesos de negocios..


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.

Un modelo de procesos de reingeniería del  software:

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. Más adelante, en esta misma sección, se describirá este modelo, pero veamos en primer lugar algunos de los principios básicos. 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.


Análisis de inventario. Todas las organizaciones de software deberán disponer de un inventario de todas sus aplicaciones. El inventario puede que no sea más que una hoja de cálculo con la información que proporciona una descripción detallada (por ejemplo: tamaño, edad, importancia para el negocio) de todas las aplicaciones activas.

Reestructuración de documentos. Una documentación escasa es la marca de muchos sistemas heredados.

Ingeniería inversa: Es el proceso de construir especificaciones de un mayor nivel de abstracción partiendo del código fuente de un sistema software o cualquier otro producto (se puede utilizar como punto de partida cualquier otro elemento de diseño, etc.).

Estas especificaciones pueden volver ser utilizadas para construir una nueva implementación del sistema utilizando, por ejemplo, técnicas de ingeniería directa.

Ventajas de la Ingeniería Inversa:

Reducir la complejidad del sistema: al intentar comprender el software se facilita su mantenimiento y la complejidad existente disminuye.

Generar diferentes alternativas: del punto de partida del proceso, principalmente código fuente, se generan representaciones gráficas lo que facilita su comprensión.

Recuperar y/o actualizar la información perdida (cambios que no se documentaron en su momento).

Detectar efectos laterales: los cambios que se puedan realizar en un sistema puede conducirnos a que surjan efectos no deseados, esta serie de anomalías puede ser detectados por la ingeniería inversa.

Facilitar la reutilización: por medio de la ingeniería inversa se pueden detectar componentes de posible reutilización de sistemas existentes, pudiendo aumentar la productividad, reducir los costes y los riesgos de mantenimiento.

La finalidad de la ingeniería inversa es la de desentrañar los misterios y secretos de los sistemas en uso a partir del código. Para ello, se emplean una serie de herramientas que extraen información de los datos, procedimientos y arquitectura del sistema existente.

TIPOS DE INGENIERIA INVERSA.

Ingeniería inversa de datos: Se aplica sobre algún código de bases datos (aplicación, código SQL, etc) para obtener los modelos relacionales o sobre el modelo relacional para obtener el diagrama entidad-relación.

Ingeniería inversa de lógica o de proceso: Cuando la ingeniería inversa se aplica sobre código de un programa para averiguar su lógica o sobre cualquier documento de diseño para obtener documentos de análisis o de requisitos.


Ingeniería inversa de interfaces de usuario: Se aplica con objeto de mantener la lógica interna del programa para obtener los modelos y especificaciones que sirvieron de base para la construcción de la misma, con objeto de tomarlas como punto de partida en procesos de ingeniería directa que permitan modificar dicha interfaz.


HERRAMIENTAS PARA LA INGENIERIA INVERSA.

• Los Depuradores.

• Las Herramientas de Inyección de Fallos.

• Los Desensambladores.

• Los compiladores Inversos o Decompiladores.

• Las Herramientas CASE.

REESTRUCTURACION DEL SOFTWARE.

La reestructuración del software modifica el código fuente y/o los datos en un intento de adecuarlo a futuros cambios. Tiende a centrarse en los detalles de diseño de módulos individuales y en estructuras de datos locales definidas dentro de los módulos. Los beneficios de de la reestructuración son:

Programas de mayor calidad con mejor documentación y menos complejidad, y ajustados a las prácticas y estándares de la ingeniería del software moderno.

Reduce la frustración entre ingenieros del software que deban trabajar con el programa, mejorando por tanto la productividad y haciendo más sencillo el aprendizaje.

Reduce el esfuerzo requerido para llevar a cabo las actividades de mantenimiento.
Hace que el software se mas sencillo de comprobar y depurar.

La reestructuración se produce cuando la arquitectura básica de la aplicación es sólida, aún cuando sus interioridades técnicas necesiten un retoque. Comienza cuando existen partes considerables del software que son útiles todavía y solamente existe un subconjunto de todos los módulos y datos que requieren una extensa modificación.


Los tipos de reestructuración, básicamente son 2: del código y de datos.


Reestructuración del código.

La reestructuración del código se lleva a cabo para conseguir un diseño que produzca la misma función pero con mayor calidad que el programa original.

Reestructuración de datos.

1. Primero se realiza el ANALISIS del código. 
2. Se evalúan las definiciones de los datos, archivos, O/I e Interfaces.
3. Extraer elementos y objetos de datos para obtener información del flujo de datos y comprender la estructura.

Ingeniería directa (forward engineering):

En un mundo ideal, las aplicaciones se  reconstruyen utilizan utilizando un «motor de reingeniería» automatizado. En el motor se insertm’a el programa viejo, que lo analizaría, reestructurm’a y después regeneraría la forma de exhibir los mejores aspectos de la calidad del software. Después de un espacio de tiempo corto, es probable que llegue a aparecer este «motor», pero los fabricantes de CASE han presentado herramientas que proporcionan un subconjunto limitado de estas capacidades y que se enfrentan con dominios de aplicaciones específicos (por ejemplo, aplicaciones que han sido implementadas empleando un sistema de bases de datos específico). Lo que es más importante, estas herramientas de reingeniería cada vez son más sofisticadas.

La ingeniería directa, que se denomina también renovación o reclamación, no solamente recupera la información de diseño de un software ya existente, sino que, además, utiliza esta información para alterar o reconstruir el sistema existente en un esfuerzo por mejorar su calidad global. En la mayoría de los casos, el software procedente de una reingeniería vuelve a implementar la funcionalidad del sistema existente, y añade además nuevas funciones y/o mejora el rendimiento global.

LA ECONOMIA DE LA REINGENIERIA:

En un mundo perfecto, todo programa que no se pudiera mantener se retiraría inmediatamente, para ser sustituido por unas aplicaciones de alta calidad, fabricadas mediante reingeniería y desarrolladas empleando las prácticas de la ingeniería del software modernas. Sin embargo, vivimos en un mundo de recursos limitados. La reingeniería consume recursos que se pueden utilizar para otros propósitos de negocio. Consiguientemente, antes de que una organización intente efectuar una reingeniería de la aplicación existente, deberá llevar a cabo un análisis de costes y beneficios.

Se ha propuesto un modelo de análisis de costes y beneficios para la reingeniería. Se definen nueve parámetros:

P, = coste de mantenimiento anual actual para una aplicación;
P, = coste de operación anual de una aplicación;
P, = valor de negocios anual actual de una aplicación;
P, = coste de mantenimiento anual predicho después
P, = coste de operaciones anual predicho después de
P, = valor de negocio actual predicho después de la
P, = costes de reingeniería estimados;
P, = fecha estimada de reingeniería;



P, = factor de riesgo de la reingeniería (P, = 1 ,O es
L = vida esperada del sistema.

El coste asociado al mantenimiento continuado de una aplicación candidata (esto es, si no se realiza la reingeniería) se puede definir como:

Cmant=  [P3-(P1+P2)] *L

Los costes asociados con la reingeniería se definen empleando la relación siguiente:

Creing=[P6 - (P4+P5)] * (L –P8) – (P7 * P9)]

Empleando los costes presentados en la ecuaciones (30.1) y (30.2), los beneficios globales de la reingeniería se pueden calcular en la forma siguiente>

Beneficio y coste = Creing- Cmant  El análisis de costes y beneficios presentados en las ecuaciones anteriores se puede llevar a cabo para todas aquellas aplicaciones de alta prioridad que se hayan identificado durante un análisis de inventario (Sección 30.2.2). Aquellas aplicaciones que muestren el mayor beneficio en relación con los costes podrán
destinarse a la reingeniería, mientras que las demás podrán ser propuestas hasta que se disponga de más recursos.

Caso de Estudio

La fábrica de accesorios militares el jaguar  http://www.accesoriosmilitareseljaguar.com desea hacer una modificación en sus procesos. Para ello ha contratado los servicios de usted como Ingeniero(a) del software, y se considera que como usted es una persona actualizada, aplicará el método de Reingeniería del software (análisis, reestructuración, ingeniería inversa, ingeniería directa) iniciando desde su sitio web hasta obtener los novedosos requerimientos.

 

Análisis:

En el sitio web de la fábrica de accesorios militares el jaguar, se encontró que solo cuenta con tipos de información: primero una bienvenida a la pagina, su misión, algunos productos (específicamente solo 12) y  un enlace a un documento con la descripción de los productos sin su precio, un formulario que se llena con datos personales y la consulta a realizar, el cual se abre en una página en blanco.

Reestructuración:

En esta página hay dos enlaces que muestran  una misma información (home, quienes somos), lo cual representa un mal diseño ya que solo debería de establecer uno solo. También  el enlace donde deberían de aparecer los precios solo muestra la descripción de los productos y no lo que indican. A las imágenes se les podría agregar una descripción de producto  con  su respectivo  precio, y así hacer que la pagina sea más atractivo y más rápido de navegar para el usuario.



Quienes Somos:

Productos:

Ingeniería Directa

En este tipo de ingeniería se necesita modificar detalladamente mas la información que los clientes desean y lo que les  interesa visualizar, así como una lista de productos con sus respectivos precios, este sistema de información también tiene muchas debilidades conforme al diseño y de cómo está estructurado la pagina web, osea no tiene un orden cronológico, no tiene mucha variedad de productos, no sale una buena descripción sobre su empresa…


 

Ingenieria Web

La ingenieria de la Web es la aplicación de metodologias 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 ingenieria 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.

 Atributos de Aplicaciones basadas en Web

Intensivas de Red

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 para todo el mundo).

De forma alternativa, una aplicación se puede ubicar en una Intranet o una Extranet.

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

Evaluación Continua

A difrencia del Software de aplicaciones convencional, que evoluciona con una serie versiones planificadas y cronológicamente espaciadas, las aplicaciones Web están en constante evolución. No es inusual que algunas Web Apps se actualicen cada hora.

Las siguientes características de las WebApps son las que conducen al proceso:

1. Inmediatez
2. Seguridad
3. Estética

Formulación y Análisis

¿Cuál es la motivación principal para la WebApp?

¿Por qué es necesaria la WebApp?

¿Quién va a utilizar la WebApp?

Análisis

Análisis del contenido: Se trata de la identificación de espectro completo del contenido que se va a proporcionar. En el contenido se incluyen los datos de texto, gráficos, imagenes, video y sonido.

Análisis de la interacción: Se trata de la descripción detallada de la interacción del usuario y la WebApp.


 Las estructuras jeraquicas: Son sin duda la arquitectura WebApp más común. A difrencia de la división de jerarquías de software que fomentan el flujo de control solo a lo largo de las ramas verticales de la jerarquía.

Una estructura en red: Los componentes arquitectónicos se diseñan de forma que pueden pasar el control a otros componentes del sistema.

Las estructuras reticulares: Son una opción arquitectónica que puede aplicarse cuando el contenido de la WebApp puede ser organizado categoricamente en dos dimensiones o más.

Estructuras de las WebApp

La estructura arquitectónica global va unida a las metasestablecidas para una WebApp, al contenido que se va a presentar, a los usuarios que la visitarán y a la filosofía de navegación establecidos.

Las estructuras lineales: aparecen cuando es común la sucesión predecible de interacciones.

 

Tipo de diseño para aplicaciones basadas en Web

Diseño arquitectónico: para los sistemas y aplicaciones basados en web se centra en la definición de la estructura global hipermedia para la WebApp, y en la aplicación de las configuraciones de diseño y plantillas constructivas para popularizar la estructura.

Diseño de navegación: Una vez establecida una arquitectura de WebApp, una vez identificados los componentes de la arquitectura, el diseñador deberá definir las rutas de navegación que permitan al usuario acceder al contenido y a los servicios de la WebApp.

Diseño de Interfaz:  Son todos aplicables al diseño de interfaces de usuario para WebApps. Sin embargo, las caracteristicas especiales de los sistemas y aplicaciones web requieren otras consideraciones adicionales.

En el siguiente link se puede mostrar una de tantas aplicaciones web que se pueden hacer http://www.youtube.com/watch?v=yRpNWtONhXQ&feature=related

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

Definició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.


El Modelo Cliente-Servidor

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


En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.

La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar muchas tareas, pero con la consideración de que realice aquellas que son mas adecuadas a sus características.

Si esto se aplica tanto a clientes como servidores se entiende que la forma más estándar de aplicación y uso de sistemas Cliente/Servidor es mediante la explotación de las PC’s a través de interfaces gráficas de usuario; mientras que la administración de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los procesos cliente sólo se ocupan de la interacción con el usuario (aunque esto puede variar).

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.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

La red Cliente/Servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se esté utilizando en una red mixta.


¿Cuándo implantar Cliente-Servidor?

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


¿Qué ayuda a la implementación?

1. La demanda de sistemas fáciles.
2. Precio/rendimiento de estaciones y servidores.
3. Creciente acceso a la información para decisiones:
Separación datos-programas.
Programas flexibles.
4. Nuevas tecnologías de alta productividad.



Funcionamiento del sistema Cliente-Servidor


Un sistema cliente/servidor funciona tal como se detalla en el siguiente diagrama:

• El cliente envía una solicitud al servidor mediante su dirección IP y el puerto, que está reservado para un servicio en particular que se ejecuta en el servidor.

• El servidor recibe la solicitud y responde con la dirección IP del equipo cliente y su puerto.

Cliente

Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los datos o de las aplicaciones es totalmente transparente para el cliente. En la arquitectura C/S el remitente de una solicitud es conocido como cliente.



Caracteristicas del Cliente

• Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).

• Espera y recibe las respuestas del servidor.

• Por lo general, puede conectarse a varios servidores a la vez.

• Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

• Al contratar un servicio de redes , se tiene que tener en la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza , por ejemplo : cable de cobre ronda entre 1 ms y 50 ms.

Servidor

Es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a través de redes, para proveer de múltiples servicios a los clientes y ciudadanos tales como impresión, acceso a bases de datos, fax, procesamiento de imágenes, etc. Al receptor de la solicitud enviada por cliente se conoce como servidor.



Caracteristicas del Servidor


1. Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
2. Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
3. Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).
4. No es frecuente que interactúen directamente con los usuarios finales.


Funciones

Cliente:

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor, se le conoce con el término front-end.


El Cliente normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de una red.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

• Administrar la interfaz de usuario.
• Interactuar con el usuario.
• Procesar la lógica de la aplicación y hacer validaciones locales.
• Generar requerimientos de bases de datos.
• Recibir resultados del servidor.
• Formatear resultados.


Servidor:
Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se le conoce con el término back-end.

El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos.

Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:

• Aceptar los requerimientos de bases de datos que hacen los clientes.
• Procesar requerimientos de bases de datos.
• Formatear datos para trasmitirlos a los clientes.
• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

Arquitectura Cliente-Servidor

Conceptos:

Cualquier combinación de sistemas que pueden colaborar entre sí para dar a los usuarios toda la información que ellos necesiten sin que tengan que saber donde está ubicada.

Es una arquitectura de procesamientos cooperativo donde uno de los componentes pide servicios a otro.

Es un procesamiento de datos de índole colaborativo entre dos o más computadoras conectadas a una red.

El término cliente/servidor es originalmente aplicado a la arquitectura de software que describe el procesamiento entre dos o más programas: una aplicación y un servicio soportante.


Caracteristicas de la Arquitectura Cliente-Servidor


Combinación de un cliente que interactúa con el usuario, y un servidor que interactúa con los recursos compartidos. El proceso del cliente proporciona la interfaz entre el usuario y el resto del sistema. El proceso del servidor actúa como un motor de software que maneja recursos compartidos tales como bases de datos, impresoras, módems, etc.

Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos de cómputo como velocidad del procesador, memoria, velocidad y capacidades del disco y input-output devices.

Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo de la red.

Modelo de Arquitectura Cliente-Servidor

Front/end : Es la parte de la aplicación que interactúa con el usuario. Basados en una interfaz gráfica con el usuario (GUI). El Cliente corre la aplicación que ofrece la interfaz con el usuario.

Back/end: Es la parte no-interactiva de la aplicación. La mayor parte reside en las Bases de Datos (relacionales o no).


Aplicaciones Simples:

No requieren una gran Base de Datos compartida, pueden ser elaboradas solamente en el Cliente.


Aplicaciones Complejas:

Exigen dos capas, una para la aplicación del usuario (Cliente) y otra para la base de datos (Servidor).

Funciones en los niveles en la Arquitectura Cliente/Servidor

 Arquitectura de 2 niveles:

1. Generalmente usa los modelos de función distribuida o datos distribuidos.
2. Muy productivo.
3. Distribución no flexible.
4. Dependiente del suministrador.


Arquitectura de 3 niveles:

La Arquitectura de tres niveles es lógica y no física. Se preocupa con las funciones y no con la implantación.

La Arquitectura puede ser utilizada para desarrollar sistemas Centralizados o Distribuidos.

La Arquitectura facilitará la distribución de los componentes del sistema.

1. Modelo presentación-negocio-datos
2. Distribución flexible.
3. Sistema abierto. No dependiente.

Beneficios

Estructura para la elaboración de aplicativos flexibles y fáciles de modificar, según las necesidades del negocio(cambio).
Alto nivel de reutilización del software y datos.
Fácil y rápido desarrollo de aplicativos grandes y complejos, para las transacciones y los SSD.
Fácil y rápido desarrollo de sistemas distribuidos que dan soporte a la administración central y a equipos auto-gestionados.


Niveles de Abstracción

Beneficios de la Abstracción

Esconde de cada nivel los detalles contenidos en los niveles inferiores:

Desarrollo simplificado del aplicativo: Al desarrollar un nivel no precisa preocuparse por el otro.

Mayor seguridad y protección: El desarrollador de un nivel no puede controlar físicamente otra camada en ningún nivel de detalle.



Interfaz entre Camadas


Es la superficie entre los componentes adyacentes de un aplicativo y el dispositivo por medio del cual ellos interactúan a través de las siguientes funciones:

Informa lo que el otro componente debe hacer, pregunta el estado actual del otro componente, recibe el resultado de las operaciones solicitadas.

Tipos de Interfaces

Proyecto de cada nivel

División del Trabajo

El desarrollo de un buen sistema Cliente / Servidor exige especialización de:

1. Interfaz gráfica
2. Redes de computadora
3. Programación de Negocios
4. Base de Datos
5. Programación de Base de Datos
6. Distribución de sistemas

Metodología Actual de Proyectos

Diagrama para un proyecto de sistemas

Conclusión de Arquitectura Cliente/Servidor

En la arquitectura Cliente/Servidor se como los tres niveles de aplicación se relacionan. Focaliza sobre la estructura y la adaptación. Y determina qué entra en cada nivel y cómo la aplicación se relaciona con otras aplicaciones.

¿Es posible crear un sistemas distribuido?
*Distribución de Datos*Distribución de Procesamiento*Interfaz gráfica con el usuario

Sistema Distribuido

 

 Cambios en la naturaleza de los sistemas de aplicación

Históricamente el área de informática elabora los sistemas de aplicación de forma completa, estando los usuarios obligados a “tomarlos o dejarlos”.

En el futuro, el área informática elaborará la infraestructura, o sea: La base de Datos, los módulos de los procesos de negocio, y kits de herramientas; para que el usuario pueda elaborar sus propias aplicaciones.


Funciones del área de Informática

1. Proveer los procesos de las reglas del negocio.
2. Proveer las estructuras fundamentales de las Bases de Datos
3. Proveer los elementos de la interfaz.
4. Proveer la infraestructura general de los sistemas, sobre la cual los equipos de trabajo puedan montar sus aplicaciones.

Un modelo para el planteamiento y desarrollo

Del modelo Conceptual a lo Físico

Ventajas del Modelo Cliente/Servidor

1. Uno de los aspectos que más ha promovido el uso de sistemas Cliente/Servidor, es la existencia de plataformas de hardware cada vez más baratas.
 
2. El esquema Cliente/Servidor facilita la integración entre sistemas diferentes y comparte información permitiendo, por ejemplo que las máquinas ya existentes puedan ser utilizadas pero utilizando interfaces mas amigables al usuario.
 
3. Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos bajo este esquema tienen mayor interacción más intuitiva
con el usuario.
4. Es más rápido el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear las herramientas existentes (por ejemplo los servidores de SQL o las herramientas de más bajo nivel como los sockets o el RPC ).

Caso de Estudio C/S:

La Empresa “Autonica” es una empresa Nicaragüense que se dedica a vender repuestos automotrices, esta tiene su sede principal en Managua con sucursales en Estelí, Chinandega y en Rivas, dicha empresa desea implementar un sistema de ventas en línea y quiere conservar su información automatizada y bien organizada entre todas sus sucursales, mediante la implementación de un modelo C/S para esto se requiere:

1)    Modelo de Negocio
2)    Modelo de Datos


Modelo de Negocio