Caja Negra de Facebook

Caja Transparente de Facebook

PAGINA PRINCIPAL

REGISTRO NUEVO USUARIO

ENTRAR A LA CUENTA

CONFIGURACION DE LA PRIVACIDAD DE FACEBOOK

PUBLICAR ESTADO

BARRA DE BUSQUEDA

SALA DE CHAT

ENVIO DE MENSAJES

ACTUALIZAR INFORMACION DEL USUARIO

CENTRO DE APLICACIONES

MENU DE CONFIGURACIONES 

MENU CONFIGURACION DE LA CUENTA

Ingenieria Web

La ingeniería 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.

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 tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafío para los (Ingeniería del software) 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.

Los métodos de Ingeniería Web dirigidos por modelos han mejorado tanto la calidad como la eficiencia, a la hora de desarrollar aplicaciones Web. Estos métodos utilizan modelos conceptuales para capturar, de manera abstracta, una representación detallada de la aplicación Web a desarrollar. La ventaja más destacada de esta aproximación es que a partir de estos modelos, ampliamente validados en entornos industriales, es factible la generación sistemática del código que implementa la aplicación Web.

En esta línea de investigación se ha abordado el desarrollo de sistemas software para la Web, a partir de la construcción de modelos conceptuales. En este ámbito, los resultados de investigación abarcan tanto la descripción de los sistemas Web a nivel de modelado como la transformación de modelos al código Web.

A nivel de modelado se ha trabajado en: 

 (1) mejorar la captura de requisitos inherentes a los sistemas Web

 (2) ampliar el grado de adaptatividad de las aplicaciones actuales

 (3) dar soporte a las características que introducen los sitios Web Accesibles

 (4) la generación de servicios Web/REST

 (5) incluir aspectos colaborativos y de interfaces de usuario avanzadas propios de la Web 2.0

A nivel de implementación, se están aplicando nuevas técnicas al desarrollo de compiladores avanzados que transforman estos modelos conceptuales Web en código en una plataforma Web, como puede ser PHP, J2EE o gestores CMS.

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 termino de ingeniería de la web ha sido un termino muy controvertido 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ño 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.
• 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.

Reingeniera del Software

La evolución del software ha constado de diferentes etapas de desarrollo, y una de ellas se llamo la “crisis del Software”. Esta crisis fue el resultado de la introducción de la tercera generación del Hardware. El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido.
A raíz de esta crisis se vio la necesidad de crear estándares de desarrollo del software, esto dio lugar a lo que hoy llamamos "Ingeniería de software" la cual es el establecimiento y uso de principios de la ingeniería a fin de obtener un software que sea fiable y que funcione eficientemente, con los menores costos posibles.

La reingeneiria del software la podemos definir como la modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, re-utilización, comprensión o evaluación.

Cuando una aplicación lleva siendo usada años, es fácil que esta aplicación se vuelva inestable como fruto de las múltiples correcciones, adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que cada vez que se pretende realizar un cambio se producen efectos colaterales inesperados y hasta de gravedad, por lo que se hace necesario, si se prevé que la aplicación seguirá siendo de utilidad, aplicar reingeniería a la misma.

Entre los beneficios de aplicar reingeniería a un producto existente se puede incluir:

• Pueden reducir los riegos evolutivos de una organización.
• Puede ayudar a las organizaciones a recuperar sus inversiones en software.
• Puede hacer el software más fácilmente modificable
• Amplía las capacidades de las herramientas CASE
• Es un catalizador para la automatización del mantenimiento del software
• Puede actuar como catalizador para la aplicación de técnicas de inteligencia artificial para resolver problemas de reingeniería

La reingeniería del software involucra diferentes actividades como son:

• análisis de inventarios
• reestructuración de documentos
• ingeniería inversa
• reestructuración de programas y datos
• ingeniería directa

con la finalidad de crear versiones de programas ya existentes que sean de mejor calidad y los mismos tengan una mayor facilidad de mantenimiento.

Modelo Cliente - Servidor

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras

En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:

• 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 debe tener en cuenta la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza.

Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus características son:

• Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
• Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
• 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).
• No es frecuente que interactúen directamente con los usuarios finales.



Herramientas Case

Las herramientas CASE en ingles  (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversasaplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos:

1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Clasificacion:

 las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.

Introducción a la Ingeniería del Software

¿QUE ES LA INGENIERIA DE SOFTWARE?

 

 El video nos explica todo sobre la Ingenieria del Software.

                                                    Fuente: http://www.youtube.com/watch?v=YFin8nNnARA

Sala Limpia en Ingeniería del Software

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

Caja Transparente

Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados.

Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las pruebas también deberán rediseñarse.

Aunque las pruebas de caja blanca son aplicables a varios niveles —unidad, integración y sistema—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Las principales técnicas de diseño de pruebas de caja blanca son:

• Pruebas de flujo de control
• Pruebas de flujo de datos
• Pruebas de bifurcación (branch testing)
• Pruebas de caminos básicos

Pruebas de Software

La prueba es la ejecución de un programa con la intención de encontrar un error. Objetivos Descubrir un error. Una buena prueba es la que tiene una alta probabilidad de detectar un error. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Principios de la prueba Hacer un seguimiento de las pruebas hasta los requisitos. Los errores más graves son aquellos que impiden que el software cumpla con los requisitos del cliente. Planificar las pruebas desde antes que comiencen. Aplicar el principio de Pareto. El 20% de las instrucciones provocan el 80% de los errores. Comenzar las pruebas por lo pequeño (módulos individuales) y terminar en lo grande (todo el sistema). No hacer pruebas exhaustivas. Las pruebas deben ser conducidas por un grupo independiente. Diseño de pruebas Pruebas de caja blanca. Examinan los detalles procedimentales. Comprueban los caminos lógicos. Examinan el estado del programa en varios puntos. Pruebas de caja negra. No toma en cuenta la estructura lógica. Examinan si las entradas se aceptan de forma adecuada y si se produce un resultado correcto. Revisa la integridad de la información externa (archivos). Pruebas de caja blanca. Prueba del camino básico Genera casos de prueba que garanticen que se ejecuta, por lo menos una vez, cada instrucción del programa. Usando el código dibujar el grafo de flujo. Obtener la complejidad ciclomática V(G). V(G) = aristas - nodos + 2, o V(G) = nodos predicado + 1 Especificar un conjunto básico de caminos linealmente independientes. Un camino independiente está constituido por lo menos por una arista que no haya sido recorrida anteriormente a la definición del camino. Preparar los casos de prueba que forzarán la ejecución de cada camino del conjunto básico. Prueba de condición Construye pruebas que ejecuten las condiciones lógicas. Prueba de flujo de datos Busca caminos de prueba de acuerdo a la definición y uso de las variables el programa. Si se limita el uso de variables globales, se puede eliminar estas pruebas. Prueba de ciclos Busca validar los ciclos. Ciclos independientes. Hacer casos de prueba para: Pasar por alto el ciclo. Entrar una sola vez. Entrar dos veces. Entrar m veces, con m < n. Entrar n - 1, n y n + 1 veces. Ciclos anidados. Aplicar las pruebas de ciclos independientes al ciclo más interno dejando los ciclos externos con sus valores mínimos. Seguir hacia afuera, dejando los ciclos externos con sus valores mínimos y los internos con valores "típicos". Continuar hasta probar todos los ciclos. Ciclos dependientes. Aplicar el enfoque usado para los ciclos anidados. Pruebas de caja negra. Partición equivalente. Divide el dominio de la entrada del módulo en clases de datos de las cuales se pueden derivar casos de pruebas. Las clases se pueden derivar de acuerdo a cada variable de entrada: Si es un rango, se define una clase válida y dos no válidas. Si es un valor específico, se define una clase válida y dos no válidas. Si es miembro de un conjunto, se define una clase válida y una no válida. Si es booleana, se define una clase válida y una no válida. Pruebas de valores límite Desarrollar pruebas para ejercitar los valores límite en las entradas y salidas (p.e. generar el número máximo o mínimo de datos a desplegar). Prueba de la interface gráfica de usuario (GUI) Hacer casos de prueba para revisar: Ventanas. Accesabilidad de los componentes dentro de la ventana. Funciones operativas de la ventana (cerrar, mover, ajuste del tamaño). Nombre de cada ventana. Colores de la ventana de acuerdo a la especificación. Menús. Contexto adecuado de los menús. Nombres claros de las opciones. Checar cada opción. Checar los short-cuts. Fuente y tamaño de texto adecuada. Ayuda sensible al contexto. Entradas de datos. Validación de los datos de entrada. Mensajes de error adecuados.

Caja Negra

Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace.

Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

Cuando de un subsistema se conocen sólo las entradas y las salidas pero no los procesos internos se dice que es una caja negra.

Un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente.