Unidades | Fundamentos de Ingeniería de Software\nEspacio dedicado a la materia de Fundamentos de Ingeniería de Software\nEn Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.\nLa versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.\nDe esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.\nAnálisis de requisitos. En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.\nDiseño del Sistema. Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.\nDiseño del Programa. Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber qué herramientas usar en la etapa de Codificación\nCodificación. Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.\nPruebas. Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.\nVerificación. Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo.\nMantenimiento. Una de las etapas más críticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.\nLa metodología de desarrollo en espiral es una evolución de método clásico en cascada (Waterfall, top-down) y se considera un método de desarrollo incremental. Este tipo de metodología equivale al de cascada, pero en él se permite el solapamiento de varias etapas con el objetivo de flexibilizar y compensar el tiempo de desarrollo total y alcanzar resultados funcionales en etapas tempranas. Está considerada como un método de desarrollo rápido y eficiente.\nEs adecuada para proyectos en los que se tienen claros los objetivos finales pero no todos los detalles de implementación están elucidados.\nLa metodología de desarrollo en espiral permite construir aplicaciones de tamaño medio manteniendo los recursos constantes. Normalmente el proyecto se divide en módulos más pequeños y a cada uno de ellos se le aplica el siguiente proceso:\nAnálisis de requerimientos. Durante esta etapa de estudia detalladamente los requerimientos que cada objetivo conlleva. Aquí establecen todos los detalles funcionales deseados.\nDiseño del sistema. Con los datos de la etapa anterior, se diseña el sistema. Se realizar el diseño de la base de datos (en caso de ser aplicable), interface de usuario, entorno, etc.\nEtapas de construcción. La etapa de construcción comprende básicamente la codificación y test de unidades. Esta etapa es un trabajo de programación pura.\nTest y evaluación. En esta etapa se realiza un test del módulo completo así como su evaluación frente al estudio de requerimientos. En muchos casos en es esta etapa los usuarios finales participan de manera activa aportando información decisiva para la usabilidad del sistema.\nPermite el desarrollo de proyectos en donde los objetivos finales están perfectamente definidos pero todos los detalles no pueden ser completamente establecidos al principio.\nEs adaptable: algunos de los requerimientos (que no los objetivos) pueden cambiar durante el ciclo de desarrollo.\nPermite la especialización de los equipos de trabajo.\nApela a una gestión de proyecto ordenada.\nFacilita la distribución de recursos de desarrollo.\nEconomía: es posible mantener constantes los recursos de desarrollo.\nPermite conseguir funcionalidad en etapas tempranas.\nModelo Rational Unified Process (RUP)\nEl Proceso Racional Unificado (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.\nProceso: Las etapas de esta sección son: Modelado de negocio\nFase de Inicio. Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.\nFase de elaboración. En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.\nFase de Desarrollo. El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.\nFase de Transición. El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.\nProgramador. Escribe las pruebas unitarias y produce el código del sistema.\nCliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.\nTester. Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.\nTracker. Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.\nEntrenador (coach). Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.\nConsultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico.\nGestor (Big boss). Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.\nModelo desarrollo manejado por rasgos\nEste proceso se considera como punto medio entre los procesos pesados y ágiles, aunque en la práctica es más similar a este último, es una combinación de XP y RUP. Pensado para proyectos relativamente cortos, al igual que los anteriores también está basado en iteraciones que producen un software funcional que puede ser visto, probado y monitorizado por el cliente.\nEstas iteraciones son decididas en base a las funcionalidades que el software debe tener, funcionalidades definidas por el cliente, este proceso está dividido en cinco fases:\nDevelop an Overall Model – Desarrollo de un modelo global,\nBuild a Feature List – Construcción de una lista de funcionalidades,\nPlan by Feature – Plan de releases (entregas) basadas en las funcionalidades a implementar,\nDesign by Feature – Diseñar en base a las funcionalidades definidas.\nBuild by Feature – Implementar en base a las mismas funcionalidades.\nAquí en el equipo de trabajo si existen jerarquías, siempre debe haber un jefe de proyecto, y aunque es un proceso considerado ligero también incluye documentación (la mínima necesaria para que algún nuevo integrante pueda entender el desarrollo de inmediato).\nEs un enfoque personalizable para entregar con éxito soluciones tecnológicas de manera más rápida, con menos recursos humanos y menos riesgos, pero con resultados de más calidad. MSF ayuda a los equipos a enfrentarse directamente a las causas más habituales de fracaso de los proyectos tecnológicos y mejorar así las tasas de éxito, la calidad de las soluciones y el impacto comercial.\nAlinear los objetivos de negocio y de tecnología\nEstablecer de manera clara los objetivos, los roles y las responsabilidades\nImplementar un proceso iterativo controlado por hitos o puntos de control\nControlar los riesgos de manera proactiva\nResponder con eficacia ante los cambios\nLos siguientes principios y conceptos de MSF sirven de guía al equipo de proyecto para entregar una solución de calidad. Cada miembro del equipo deberá comprender y aplicar estos principios en sus interacciones con otros miembros del equipo, con la organización y con las partes interesadas.MSF se basa en nueve principios fundamentales:\nFomentar una comunicación abierta. Para que el equipo sea eficaz y eficiente, tanto usted como su equipo deben compartir niveles de información apropiados entre los miembros del equipo y en toda la empresa.El equipo debe comprender la naturaleza de lo que se debe hacer y el modo en que se comunican los miembros del equipo y los contactos externos.Lo difícil es determinar un nivel apropiado para cada relación y qué información se debe compartir.\nIntentar lograr una visión compartida. El hecho de tener una visión compartida empodera a los miembros del equipo y les permite actuar con agilidad para poder tomar decisiones rápidas pero bien fundadas con el objetivo de lograr una visión.Al tener una visión compartida, los miembros del equipo pueden ir satisfaciendo los requisitos a medida que se vayan detectando.\nEmpodere a los miembros del equipo. Empoderar a los miembros del equipo no solo es una de las muchas maneras de sobrevivir en un entorno en constante cambio, sino que los miembros del equipo también aprenden a encontrar modos de alcanzar el éxito de manera creativa y a ayudarse unos a otros.Si no se permite a los miembros del equipo dar lo mejor de sí mismos, no solo disminuye su creatividad, sino que también pueden sufrir de baja moral y ser incapaces de contribuir a crear un equipo de alto rendimiento.\nEstablecer responsabilidades claras y compartidas. A menudo, los miembros del equipo empoderados se sienten más responsables de sus decisiones y están dispuestos a ser corresponsables de un proyecto.A mayor responsabilidad de los miembros del equipo, mayor calidad.Por ejemplo, si un miembro del equipo afirma que ha completado una tarea pero se detecta que no tiene el nivel de calidad adecuado, ese miembro del equipo es responsable de resolver este problema de manera que la tarea completada tenga los niveles de calidad indicados.Si se fomenta el crecimiento positivo y la responsabilidad en lugar de castigar tales deslices, el miembro del equipo comparte la responsabilidad de la solución general y sus entregas.Esto fomenta la motivación entre los miembros más sólidos del equipo para ayudarse mutuamente a dar lo mejor de sí mismos.\nOfrecer valor incremental. Este principio tiene dos facetas:\nAsegurarse de que lo que se entrega tiene un valor óptimo para las partes interesadas.\nDeterminar los incrementos óptimos en los que se entregará valor (o la “frecuencia de entrega”).\nMantenerse ágil, esperar cambios y adaptarse a ellos. Como los cambios pueden darse a menudo y en el peor momento posible, disponer de una manera ágil de manejarlos ayuda a minimizar los trastornos habituales que provocan.Mantenerse ágil significa que una organización está preparada para los cambios y puede adaptarse y ajustarse sin contratiempos.\nInvertir en la calidad. Muchas organizaciones adoptan el principio de calidad, a menudo con una definición bastante difusa, pero no saben cómo cuantificarla.La calidad es algo que se debe incorporar de manera proactiva al ciclo de vida de entrega de la solución y no es algo que aparezca de la nada.\nAprender de todas las experiencias. Si todos los niveles de una organización no aprenden de lo que funcionó y lo que no funcionó anteriormente, ¿cómo se puede esperar que mejoren la próxima vez?Los miembros del equipo deben comprender y darse cuenta de que el aprendizaje se da en todos los niveles:\nA nivel de proyecto, como por ejemplo, al perfeccionar un proceso válido para todo el proyecto\nA nivel individual, como por ejemplo, al buscar la manera de interactuar mejor con otros miembros del equipo\nA nivel de la organización, como por ejemplo, al ajustar las métricas de calidad que se recopilan para cada proyecto\nColaborar con clientes internos y externos. Las probabilidades de éxito del proyecto aumentan cuando el cliente trabaja con el equipo del proyecto.Eso no quiere decir que los clientes tengan que hacer el trabajo de un equipo.Sin embargo, cuando los clientes colaboran estrechamente y de manera incremental con un equipo de entrega, la solución satisface mejor sus expectativas.Colaborar con los clientes es ventajoso para ambas partes, ya que ayuda a reducir la incertidumbre, reduce el tiempo necesario para resolver temas de requisitos y aumenta la comprensión por parte del equipo de las propuestas de valor de la solución por medio del contacto periódico.\nEl modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:\nMétodo de las comparaciones limitadas sucesivas.\nCiencia de salir del paso.\nMétodo de atacar el problema por ramas.\nEl Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.\nEn una visión genérica, el proceso se divide en 4 partes:\nDifícil de evaluar el costo total.\nDifícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.\nEl resultado puede ser positivo.\nCon un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.\nTambién provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software.\nResulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.\nEl modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de riesgos.\nRequiere de mucha planeación, tanto administrativa como técnica.\nRequiere de metas claras para conocer el estado del proyecto.\nEl desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Maslow en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.\nHoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Lazarus, Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo, GeneXus o Clarion. En el área de la autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones, dentro de ciertos límites.\nFases del rad\nPruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.\nEquipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos.\nLos desarrolladores de RAD deben ser “renacentistas”: analistas, diseñadores y programadores en uno.\nSe reunen los usuarios finales y los desarrolladores.\nLos clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios.\nLos cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.\nDespués de haber investigado y analizado cada uno de los modelos de desarrollo de software, ahora conocemos y sabemos que existen diversas formas de crear nuestras aplicaciones. Cada uno de los modelos tienen sus características, sus ventajas y desventajas, principalmente los pasos o procedimientos que se deben seguir para realizar nuestro software. El modelo de cascada, en lo personal, es el modelo que más llamó mi atención, opino que es un modelo práctico y eficiente, hasta ahora la mayoría de pasos que se especifican en este modelo, se han estudiado y llevado a cabo en nuestro proyecto realizado. También considero que los demás modelos son ramificaciones del modelo de cascada, ya que son muy parecidos, pero entre ellos conservan sus especificaciones que los hacen diferentes.\n1.- PARADIGMAS DE LA INGENIERÍA DE SOFTWARE\nEn el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos) como principal herramienta para entender al sistema antes de plasmarlo a código fuente. DFD es un diagrama en el que participan procesos (métodos), flujo de datos (argumentos) y archivos (Base de datos). Hay de diferentes niveles dependiendo la complejidad del sistema que se analiza, hablando de lenguajes tiene muchas diferencia con la orientada a objetos, un mínimo cambio en el código puede llegar alterar al resto del programa cosa que en la orientada a objetos eso no sucede lo cual es una ventaja porque así no se pierde tiempo en arreglar cosas ya hechas. Una desventaja es que una porción de código en lenguaje estructurado es difícil que pueda servir en otros proyectos, esto si es habitual en lenguaje orientada a objetos, con solo importar clases ya hechas se escribe menos código y se ahorra tiempo.\nUn modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un Modelo de Datos permite describir:\nLas restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.\nOperaciones de manipulación de los datos: Operaciones de agregado, borrado, modificación y recuperación de los datos de la base.\nEl enfoque Estructurado, fue seleccionado como técnica de investigación de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lógica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle. Este es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a través de un sistema, la representación gráfica de los procesos del sistema estará a cargo de los Diagramas de Flujos de Datos (DFD).\nEl contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad que encapsula datos (atributos) y acciones o funciones que los manejan (métodos). También para el EOO un objeto se define como una instancia o particularización de una clase.\nLos objetos de interés durante el desarrollo de software no sólo son tomados de la vida real (objetos visibles o tangibles), también pueden ser abstractos. En general son entidades que juegan un rol bien definido en el dominio del problema. Un libro, una persona, un carro, un polígono, son apenas algunos ejemplos de objeto.\nCada objeto puede ser considerado como un proveedor de servicios utilizados por otros objetos que son sus clientes. Cada objeto puede ser a la vez proveedor y cliente. De allí que un programa pueda ser visto como un conjunto de relaciones entre proveedores clientes. Los servicios ofrecidos por los objetos son de dos tipos:\nLos datos, que llamamos atributos.\nLas acciones o funciones, que llamamos métodos.\nFundamentos del Enfoque Orientado a Objeto\nEl Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos. Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia. Otros elementos a destacar (aunque no fundamentales) en el EOO son: Polimorfismo, Enlace dinámico (o binding), Concurrencia y Persistencia.\nEl análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO) constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan en los conceptos de la programación orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelación), un lenguaje estandarizado de modulación en el cual los objetos generados no solo incluyen código referente a los datos sino también instrucciones acerca de las operaciones que se realizaran sobre los datos.\nEL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo y modelado de software que permite construir más fácilmente sistemas complejos a partir de componentes individuales.\nEl proceso Orientado a Objetos se mueve a través de una espiral evolutiva que comienza con la comunicación con el usuario. Es en esta parte donde se define el dominio del problema y se identifican las clases básicas del problema. La planificación y el análisis de riesgos establecen una base para el plan de proyecto OO. El trabajo técnico asociado con la ingeniería del software OO sigue las siguientes tareas:\nIdentificar clases candidatas.\nBuscar clases en biblioteca.\nExtraer nuevas clases si existen.\nDesarrollar las clases sino existen.\nAñadir las nuevas clases a la biblioteca.\nConstruir n-ésima iteración del sistema.\nLa ingeniería de software hace hincapié en la reutilización. Por lo tanto las clases se buscan en una biblioteca (de clases existentes) antes de construirse\nLas Características del Enfoque Orientado a Objetos son:\nObjeto: Los datos están cuantificados en entidades discretas y distinguibles llamadas objetos.\nClase: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupa para formar una clase.\nAtributo: Describen la clase o el objeto de alguna manera\nMensajes: Medio por el cual interactúan los objetos\n2.- MODELOS DE PROCESO DE SOFTWARE\nProceso de desarrollo unificado\nEl proceso personal de software Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro “An introduction to the Personal Software Process” se dirige ahora a ingenieros juniors.\nRegistro de defectos.\nNivel 0.1 :\nEstándares de codigo.\nMedición de tamaño.\nNivel 1 – Inicial:\nEstimacion de tamaño.\nReporte de pruebas.\nCalendario de planeación de tareas.\nNivel 2 – Repetible:\nRevisión de diseño y código.\n3.- MODELO DE CASOS DE USO\nEl modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un caso de uso representa una unidad discreta de interacción entre un usuario (humano o máquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo significativo; por ejemplo, “Validarse en el sistema”, “Registrarse en el sistema” y “Crear un pedido” son todos casos de uso.Cada caso de uso tiene una descripción que describe la funcionalidad que se construirá en el sistema propuesto. Un caso de uso puede “incluir” la funcionalidad de otro caso de uso o “extender” a otro caso de uso con su propio comportamiento.Una descripción de caso de uso generalmente incluirá:\nEl ejemplo de arriba muestra que el caso de uso “Acceso” implementa el requisito formal “1.01 Acceder al sitio web”. También establece que el componente de lógica de negocios y el componente de páginas ASP implementan alguna parte o toda la funcionalidad de “Acceso”. Un refinamiento adicional es mostrar la pantalla de “Acceso” (una página web) como una implementación de su interfaz. Estos enlaces de implementación o realización definen la trazabilidad desde los requisitos formales, a través de casos de uso, a componentes y pantallas.\n4.- MODELO DE SECUENCIAS\nUn diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.\nTípicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede “caminar sobre” esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.\nPueden ser usados en dos formas\nGenérico: describe la interacción para un caso de uso. Utiliza ramificaciones (“Branches”), condiciones y bucles.\nLos mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre ‘business’ de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre ‘business’ es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.\nDespués de haber leído este interesante tema me doy cuenta de que existen muchas técnicas para desarrollar nuestro software; en la mayoría de las ocasiones, los programadores si no tienen una buena base, lo primero que quieren hacer es codificar, sin antes haber analizado el problema a solucionar.\nEso es un error my común y fatal, ya que esto no nos permite hacer un análisis minucioso de lo que se quiere resolver, en ocasiones si se llega a una solución, sin embargo es posible que no sea la solución óptima a nuestro problema.\nEn nuestra carrera los casos de uso son vistos y utilizados en muy pocas ocasiones, o al menos en una materia que curse los utilizamos muy poco, realmente no se tiene bien cimentadas este tipo de técnicas, solo en primer semestre se nos enseña a utilizar los diagramas de flujo que son utilizados en la programación estructurada, pero el resto de los semestre se enfoca a la programación orientada a objetos.\nPresentación de: MODELO DE CASOS DE USO\n2.1 Tareas de la ingeniería de requisitos\nNormalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE .\n(I) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).\nLa Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:\nLa educción (a veces llamada “elicitación”, debido a una mala traducción de “elicitation”) de los requisitos de usuario.\nEl análisis y negociación de requisitos para derivar requisitos adicionales.\nLa documentación de los requisitos como especificación.\nLa validación de los requisitos documentados contra las necesidades de usuario.\nAsí como los procesos que apoyan estas actividades.\nDesde un punto de vista conceptual, las actividades son de cinco clases.\nObtener requisitos: A través de entrevistas o comunicación con clientes o futuros usuarios, para saber cuáles son sus expectativas.\nAnalizar requisitos: Detectar y corregir las carencias o falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño.\nDocumentar requisitos: Igual que todas las etapas, los requisitos deben estar debidamente documentados.\nVerificar los requisitos: Consiste en comprobar la implementación de los requerimientos.\nValidar los requisitos: Comprobar que los requisitos implementados sean funcionales para lo que inicialmente se construyó el producto.\nInicio: Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.\nObtención: Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:\n1 Problema de ámbito\n1 Problema de comprensión\n1 Problemas de volatilidad\nElaboración: Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.\nNegociación: En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.\nEspecificación: Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.\nValidación: Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de requisitos. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.\nGestión de requisitos: Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.\nEjemplo gráfico de las tareas de ingeniería de requisitos:\nLa ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.\nLas entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema.\nLos requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.\nExisten dos técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La diferencia que existe entre ambas técnicas es que durante la tormenta de ideas se tiene como objetivo generar una gran cantidad de ideas, es desestructurada y la información que se obtiene puede ser visual, textual o coloquial; mientras que en el JAD el taller es ordenado, la información que se obtiene es visual y su objetivo es generar requisitos y la interfaz del sistema.\nDurante una sesión de Lluvia de ideas, todos los participantes pueden aportar distintas ideas en un ambiente libre de prejuicios. Ningún participante debe juzgar negativamente la propuesta de otros, sino que se anotan todas las ideas en una pizarra y serán evaluadas al final de la sesión. El principio básico es no descartar de manera apresurada ningún planteo, de modo que existe la posibilidad de que surjan otras ideas derivadas de la idea original y se generan varios puntos de vista del problema.\nEn el Joint application development se trabaja directamente sobre los documentos a generar, las temáticas que se tratan durante las reuniones siguen un esquema y se busca que la misma sea ordenada y racional. Se define una agenda con los puntos principales a tratar durante la jornada. Este tipo de taller tiene el inconveniente de que es muy difícil poder reunir a todas los participantes, es costoso y generalmente es necesaria más de una reunión para establecer los requisitos del sistema.\n· Forma de contrato\nEn lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.\nLos requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.\n· Prototipos y Casos de uso\nUn prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.\nUn caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.\nA los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.\nLos diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.\nLos prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.\nLos diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.\nLos prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.\n· Especificación de requisitos del software\nUna especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).\nLas estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.\nEl modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.\nEl modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología Objectory (Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.\nActualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos, y se resume aquí:\nRequisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.\nAnálisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.\nDiseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.\nImplementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.\nPruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.\nDocumentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.\n2.4 Herramientas CASE para la ingeniería de requisitos\nA medida que pasa el tiempo se logra entender que el empleo del software es una buena opción para agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es la excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería De Software Asistida Por Computador). Estas incluyen un conjunto de programas que facilitan la optimización de un producto ofreciendo apoyo permanente a los analistas, ingenieros de software y desarrolladores. CASE es la aplicación de métodos y técnicas que dan utilidades a los programas, por medio de otros, procedimientos y su respectiva documentación.\nA continuación se hace referencia a 3 herramientas que ayudan a la gestión de requisitos; es decir al proceso de identificación, asignación y seguimiento de los mismos, incluyendo interfaz, verificación, modificación y control de cada requisito, durante el ciclo de vida del proyecto. Los cambios/actualizaciones de requisitos deben ser gestionados para asegurar que se mantenga la calidad del producto.\nHasta hace poco tiempo las herramientas para la gestión de requisitos de software se limitaban a editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación:\nHerramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable a cada cliente.\nHerramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.\nHerramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.\nLos temas abordados anteriormente fueron de gran interés, principalmente porque se va conociendo todo el proceso que se debe ejecutar para llevar a cabo un software de calidad. Como estudiantes estamos acostumbrados a escribir las líneas de código, sin antes pensar bien en su planeación; muchas veces solo se escribe y ni siquiera hacemos uso de un diagrama de flujo o de un diagrama de casos de uso.\nLa ingeniería de requisitos sirve para prever, para realizar nuestro software y así satisfacer la demanda del cliente, esta tiene una serie de actividades y técnicas para poder conocer los porqués y para que del software, pudiera decirse que son los cimientos del software.\nDentro del modelado de requisitos se lleva a cabo, como su nombre lo dice el modelo o planeación más formal de lo que vamos a crear, de igual forma existen diferentes modelos a seguir, pero el más famoso y usado es el de casos de uso. Las herramientas CASE tienen un papel importante para la ingeniería de requisitos, porque una clasificación de ellas, es porque también sirven para el diseño del software, por lo tanto esta ingeniería y las herramientas CASE van de la mano y trabajan en conjunto.\n3.1 Arquitectura de clases\nEl objetivo del modelo de analisis es crear una arquitectura de objetos que sirva como base para el diseño del sistema. Dependiendo del tipo de aplicación existen varias arquitecturas. Ellas se distinguen según la organización de los objetos de acuerdo a su funcionalidad. Esto es llamado dimension de arquitectura.\nDimension de la arquitectura\nUnidimensional: un solo grupo de objetos para manejar la funcionalidad y la interacción externa.\nBidimensional: un grupo de objetos para manejar la funcionalidad y otros para las interacciones externas.\nTridimensional: La más usada en los sistemas de información que siendo el Modelo-Vista-Control.\nEs un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz del usuario y la lógica de negocio en tres componentes distintos. El modelo es el sistema de gestión de base de datos y la lógica de negocio y el controlador es el responsable de recibir los eventos de entrada desde la vista.\nModelo à Información\nVista à Presentación con el usuario\nControl à Comportamiento\n3.2 Identificación de clases según estereotipos\nPara llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.\nEn general, los cambios más comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo a los objetos borde.\nLos cambios a la funcionalidad son más difíciles de administrar, ya que ésta puede abarcar todos los tipos de objetos.\nToda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a través de ellos se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentación comprensible para el actor.\nLas clases borde en otras palabras, describen la comunicación bidireccional entre el sistema y los actores. Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:\nSe pueden identificar con base a los actores.\nSe pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.\nSe pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.\nEstrategia correspondiente a los actores. Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.\nSe utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.\nDurante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.\nValidar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que se hace en la clase entidad RegistroUsuario, utiliza también por el caso de uso RegistroUsuario.\nOfrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.\nRegistrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.\nRegistrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.\nConsultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.\nHacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.\nPagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.\nEn la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.\nEs difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.\nUna clase es una plantilla para la creación de objetos de datos según un modelo predefinido. Las clases se utilizan para representar entidades o conceptos, como los sustantivos en el lenguaje. Cada clase es un modelo que define un conjunto de variables -el estado, y métodos apropiados para operar con dichos datos -el comportamiento. Cada objeto creado a partir de la clase se denomina instancia de la clase.\nUna clase también puede tener una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo en tiempo de ejecución para la manipulación de los metadatos relacionados con la clase.\nLas clases se componen de elementos, llamados genéricamente «miembros», de varios tipos:\nCampos de datos: almacenan el estado de la clase por medio de variables, estructuras de datos e incluso otras clases.\nMétodos: subrutinas de manipulación de dichos datos.\nCiertos lenguajes permiten un tercer tipo de miembro: las «propiedades», a medio camino entre los campos y los métodos.\nUtilizando un símil con el lenguaje, si las clases representan sustantivos, los campos de datos pueden ser sustantivos o adjetivos, y los métodos son los verbos.\nLos campos de datos se utilizan para contener datos que reflejan el estado de la clase. Los datos pueden estar almacenados en variables, o estructuras más complejas, como structs, uniones e incluso otras clases.\nHabitualmente, las variables miembro son privadas al objeto (siguiendo las directrices de diseño del Principio de ocultación) y su acceso se realiza mediante propiedades o métodos que realizan comprobaciones adicionales.\nLos métodos implementan la funcionalidad asociada al objeto. Los métodos son el equivalente a las funciones en programación estructurada. Se diferencian de ellos en que es posible acceder a las variables de la clase de forma implícita. Cuando se desea realizar una acción sobre un objeto, se dice que se le manda un mensaje invocando a un método que realizará la acción.\nLas propiedades son un tipo especial de métodos. Debido a que suele ser común que las variables miembro sean privadas para controlar el acceso y mantener la coherencia, surge la necesidad de permitir consultar o modificar su valor mediante pares de métodos: GetVariable y SetVariable.\nLos lenguajes orientados a objetos más modernos (por ejemplo Java o C#) añaden la construcción de propiedad, que es una sintaxis simplificada para dichos métodos:\n3.4 Diagramas de secuencias\nEl diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como “sequence diagram”, “event-trace diagrams”, “event scenarios” o “timing diagrams”\n3.5 Diccionario de clases según módulos\nUn diccionario de clases es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda los detalles y descripciones de todos estos elementos.\nLos analistas utilizan los diccionarios de datos por cinco razones importantes:\nPara facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar dónde efectuar cambios en el sistema.\nLos sistemas grandes tienen enormes volúmenes de datos que fluyen por ellos en forma de documentos, reportes e incluso pláticas. De manera similar, se llevan a cabo muchas actividades que utilizan los datos existentes o que generan nuevos detalles. Recuérdese, como se mencionó en la historia al inicio de este capítulo, que Lodos los sistemas experimentan cambios continuos y manejar de manera completa todos los detalles es un desafió. Con franqueza, es imposible que los analistas recuerden todo. Los que tratan de hacerlo cometen de manera invariable equivocaciones u olvidan elementos importantes. Los mejores analistas no intentan recordarlo todo, en lugar de hacerlo registran toda la información. Algunos lo hacen sobre hojas de papel y otros quizá sobre tarjetas indexadas. Muchos emplean para tal fin un procesador de palabras y una computadora personal por supuesto. Los analistas mejor organizados y más eficaces utilizan diccionarios de datos automatizados diseñados de manera específica para el análisis y diseño de sistemas.\nComunicación de significados\nLos diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qué datos representan a la factura y al cheque. Los dos son términos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripción de flujos de datos, almacenes de datos o procesos.\nHerramientas CASE para el análisis\nBorland Caliber Analyst. Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía Borland.\nPor un lado está el Caliber DefineIT (la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como capturar los diferentes escenarios de negocio a través de diferentes herramientas visuales; es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.\nPor el otro está Caliber RM que nos permite gestionar dichos requisitos durante el ciclo de vida del producto, si bien no ayudaba al usuario a visualizar los requerimientos y por lo tanto no resultaba tan efectiva como ellos demandaban.\nEl paquete que incluye ambas aplicaciones nos permitirá realizar las siguientes tareas: representar y especificar los escenarios de manera visual, permitiendo el uso de un lenguaje común; generar diagramas de casos de pruebas y UML, mejorando tanto la velocidad como la exactitud de la definición de los requisitos; rastrear los requisitos software durante el ciclo de vida del proyecto, respondiendo de manera rápida a cualquier cambio que se produzca.\nLa compañía Seilevel Inc., una de las más fuertes en cuanto a los servicios relacionados con los requisitos del software, ha seleccionado esta herramienta como la mejor de este tipo. Según palabras de un directivo de la compañía ven características únicas en esta herramienta así como una experiencia de usuario excelente y una oportunidad para mejorar el trabajo de sus clientes en cuanto al análisis y gestión de requisitos se refiere.\nCASE Spec. Esta herramienta está desarrollada por la empresa Goda Software, siendo esta una aplicación comercial de uso exclusivo para el sistema operativo Windows. Las principales características que avalan a esta herramienta son las siguientes:\nEspecificación: posibilidad de realizar las especificaciones tanto con las técnicas tradicionales como con los diagramas de casos de uso. Además, nos permite crear diagramas UML y de flujo de datos.\nSeguimiento de los requisitos: a través del uso combinado de un procesador de textos y una hoja de cálculo, el usuario será capaz de realizar el seguimiento de los requisitos así como hacer un informe acerca de los mismos.\nCapacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el proyecto.\nCapacidad de importar y exportar archivos.\nGeneración automática de la documentación del proyecto así como posibilidad de realizar amplios informes.\nIRQA 4. Herramienta desarrollada por Visure y que tiene la meta de servir como aplicación para proporcionar un soporte integral en la ingeniería de requisitos de un proyecto de informática.\nA parte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado, organización y seguimiento), esta aplicación dispones de las siguientes características:\nReutilización de requisitos: permite que los requisitos definidos en un proyecto puedan ser utilizados en otros proyectos realizados por la organización, a través del uso de librerías. De esta manera se consigue ofertar una pequeña ventaja a la hora de realizar líneas de productos.\nVista documental: esta nueva opción ofrece un agrupamiento de los requisitos que permite al usuario observar una diferenciación clara entre los mismos así como facilitar toda labor relacionada con estos.\nIngeniería de requisitos: además de la gestión de los requisitos, esta aplicación proporciona funcionalidades relacionadas con la ingeniería de requisitos, lo que permite centralizar en una sola herramienta todas las actividades relacionadas con los requisitos (incluyendo las pruebas de validación y aceptación).\nAl ser esta una herramienta integrada, se ofrece al usuario la libertad de seleccionar aquellas otras aplicaciones más adecuadas para la realización de otras tareas relacionadas con el ciclo de vida de un proyecto, lo que hace que no se dependa de un solo proveedor de aplicaciones.\nTiger Pro. Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que aparecen a la hora de definir los requisitos de un programa. También ayuda al usuario a aclarar algunos de los requerimientos desde el punto de vista de las pruebas a realizar, señalando aquellos requerimientos cuya verificación pueda resultar complicada.\nLa herramienta, que se va actualizando con el paso del tiempo, permite exportar el trabajo realizado en archivos bajo el formato CSV. Los usuarios que utilicen esta herramienta podrán trabajar en los requisitos tomando como referencia los siguientes conceptos: palabras claves relacionadas con el mismo (hasta 3 palabras para cada requisito), criterio de aceptación del requisito, seguimiento del mismo (tanto hacia la fuente como hacia otros lugares), prioridad del requerimiento, riesgo que trae consigo el requisito y coste del mismo. Además, a la hora de realizar los informes correspondientes, la herramienta nos proporcionará la opción de redactar los mismos en forma textual o bien nos presentará la información de forma gráfica.\nGatherSpace. A la hora de realizar la definición de los requisitos para un proyecto de informática, el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta herramienta de definición y gestión de requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar ningún programa para utilizarla: bastará con crear una cuenta en el sitio web de la misma y comenzar a definir el proyecto que se quiere desarrollar. De esta manera, la aplicación consigue que la colaboración de todos los miembros del grupo de desarrollo sea posible de una manera mucho más eficaz.\nLas características más representativas de esta herramienta son las siguientes:\nCreación de una jerarquía de requerimientos: permite crear paquetes funcionales para después relacionarlos con componentes de más alto nivel para después permitir asociar casos de uso más detallados y requisitos del software a dichos componentes.\nManipular varios proyectos al mismo tiempo, controlando el acceso de los usuarios para que estos puedan ver solo alguno de los proyectos.\nPosibilidad de visualizar la documentación generada a partir de los requisitos en tres formatos diferentes: HTML, PDF y Microsoft Word.\nAdemás de contar con todas estas opciones, la compañía ha dispuesto un buen sistema de seguridad que protegerá los datos introducidos en la herramienta. Para asegurar la integridad del trabajo realizado se realizan copias de seguridad diaria de la información introducida en la herramienta y además existe la posibilidad de encriptar los datos introducidos en la misma. También es necesario señalar que el usuario podrá descargarse la información desde el servidor de la empresa tantas veces como le sea necesario.\nIBM Rational RequisitePro. Esta herramienta, desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramientas más completas y potentes dentro del análisis y la gestión de los requisitos.\nUna de las grandes ventajas que aporta este producto es la compatibilidad existente entre su software y algunos de los programas más utilizados. Por ejemplo, esta herramienta es capaz de comunicarse de manera muy eficiente con el Microsoft Word, de manera que la realización de los informes es más sencilla al tiempo que se ofrece al usuario una interfaz conocida para el desarrollo de su labor. Además de esta compatibilidad, el programa también se comunica con gran eficiencia con algunos de los sistemas de bases de datos más utilizados en el mundo de la informática (DB2 de IBM, Microsoft SQL Server, Microsoft Access y Oracle) de manera tal que se controla el acceso a los datos existentes en el sistema al tiempo que se tiene un repositorio central de datos.\nPor si esto no fuera suficiente, la comunicación entre la base de datos utilizada y el Microsoft Word permite al usuario gestionar los requisitos desde la base de datos seleccionada al tiempo que estos se mantienen dentro de su contexto en el procesador de textos.\nAl igual que la herramienta estudiada anteriormente, Racional RequisitePro ofrece la posibilidad de trabajar mediante acceso Web. De esta manera se logra tener tanto un acceso remoto como un acceso distribuido y además no se necesita que el software esté instalado en el cliente. También es necesario mencionar que la herramienta dispone de una matriz de seguimiento de los requisitos (al igual que la herramienta CASE Spec); en este caso, dicha matriz puede representarse tanto de forma gráfica como de forma textual. Además, en este caso se incorpora al seguimiento de los requisitos la existencia de un árbol de seguimiento global.\nRaQuest. Se trata de la herramienta de gestión de requisitos desarrollada por la empresa Sparx Systems, desarrolladora también de la herramienta de análisis y modelado Enterprise Architect, utilizada en la Escuela.\nDefinición y gestión de los elementos relacionados con los requisitos, entre los que se encuentran el tipo, el estado, la dificultad del requisito, las relaciones existentes entre diferentes requisitos, etc.\nCreación de paquetes para gestionar de manera más sencilla y completa los requisitos.\nGeneración de documentación del proyecto (tanto parcial como total) en los siguientes formatos: HTML, CSV, Word, Excel, RTF\nAdemás de estas características, la herramienta nos ofrece una serie de vistas diferentes, dependiendo de la vista que queramos obtener del proyecto. Estas vistas son: vista del tipo lista (permite ordenar los requisitos, mostrar diferentes listas, filtrar las listas en relación a diferentes palabras y buscar en el proyecto) y vista del tipo árbol (se pueden mostrar los árboles de proyecto y miembro así como mostrar los árboles por el tipo y por el estado).\nElección de la Herramienta a Utilizar\nDebido a la gran compatibilidad existente con el Enterprise Architect, a la variedad de formatos para generar la documentación y a las numerosas opciones existentes en cuanto al tipo de vistas y la definición de los elementos relacionados con los requisitos, me he decantado por utilizar la herramienta RaQuest.\nDespués de haber leído la información aquí presentada, de manera personal me doy cuenta de todo el trabajo que hay detrás de un “software”, principalmente si el sistema es para un proyecto ya pagado, porque ahí ya no debe haber errores y todo debe quedar lo más apegado a la perfección, el modelo de análisis, es la base, como su nombre lo dice nos ayuda a analizar qué es lo que vamos a resolver y como lo vamos a resolver, este modelo es el cimiento para desarrollar un buen proyecto. De ahí se desglosa la arquitectura de clases, que en pocas palabras es donde se determina como se estructurara nuestro software, es decir en cuantas partes y cómo van a interactuar entre ellas. Las clases son el alma del sistema. Dentro de ellas van los objetos, atributos, funciones del programa, sin ellas no sería posible desarrollar un sistema, y por otra parte tenemos las herramientas CASE destinadas al análisis, estas no son de mucha ayuda porque optimizan nuestro trabajo, le dan un toque más profesional a nuestro trabajo. En conclusión el modelo de análisis es la base para comenzar a desarrollar cualquier sistema, es importante desarrollar cada uno de los pasos ya mencionados aquí, para que después no haya problemas con la ejecución, la lógica y principalmente se logre el objetivo.


Aplicaciones para conseguir seguidores en Instagram dentro de tu presupuesto - Famouz.io\nAplicaciones para conseguir seguidores en Instagram dentro de tu presupuesto\nPuedes utilizar estas aplicaciones para aumentar el número de seguidores en Instagram. Instagram se ha convertido en una aplicación de moda entre los jóvenes de hoy en día. Todo el mundo en la franja de edad de 20 a 50 años tiene Instagram en sus teléfonos. Muchos influencers de las redes sociales utilizan las aplicaciones para conseguir seguidores en Instagram para aumentar el número de seguidores, comentarios y likes.\n1 Seleccione entre la gran variedad de planes\n2 ¿Cómo aumenta Famouz el número de seguidores en Instagram?\nLos influencers tienen que ocuparse de todo, como la creación de contenidos. Tienen que enviar solicitudes, aceptar solicitudes (si su cuenta es privada), mantenerse activos y poner historias. Puede ponerse en contacto con los sitios web en línea y consigue tus seguidores de Instagram con la ayuda de proveedores de seguidores online. Te ayudarán a crear un buen perfil que aumente el número de seguidores de forma orgánica en tu perfil. Lea para más información.\nComprar seguidores de Instagram ahora es fácil para que puedas concentrarte en construir la calidad de tu contenido sin distraerte. Hay varias aplicaciones para conseguir seguidores en Instagram de forma fácil y con tu presupuesto. También puedes comprar likes en tus publicaciones, carretes y un buen número de comentarios en las publicaciones que compartes en tu cuenta con la ayuda de sitios web online.\nSi estás buscando aplicaciones para conseguir seguidores en Instagram, para obtener una lista de las mejores aplicaciones. Visite el sitio web y compruébelo usted mismo. Puedes comprar todo y concentrarte en crear contenido que sea beneficioso para quienes te siguen. Si te centras en crear contenido, atraerás a más seguidores de los que ya tienes. Compartirán tus contenidos con sus amigos y familiares, y también empezarán a seguirte.\nSeleccione entre la gran variedad de planes\nPuede elegir entre una amplia gama de planes en los sitios web en línea. Obtenga su esquema de acuerdo a su necesidad. Puedes empezar comprando 100 seguidores (número mínimo de seguidores disponible en los diferentes sitios web) al principio. Una vez que entienda el concepto de ordenar los seguidores, entonces usted puede ordenar más seguidores de la página web en línea. Hay opciones para el número de seguidores que puedes comprar. La gente pide seguidores por miles.\nEl primer paso es que usted tiene que seleccionar cualquiera de los sitios web / empresas que ofrece seguidores pagados y haga clic en la etiqueta de Instagram en la parte superior de la página. También encontrará otras plataformas de medios sociales en el sitio web. Una vez que hagas clic en la etiqueta de Instagram, verás una lista de esquemas en tu pantalla. Elige cualquiera de los planos de la lista. Los que han probado estos sitios web en línea saben que son fiables y seguros de usar. También puede leer las reseñas en Internet sobre cómo ha funcionado cualquiera de los sitios web en los últimos años.\n¿Cómo aumenta Famouz el número de seguidores en Instagram?\nTienes que pegar el enlace de tu cuenta de Instagram en el color deseado. No es necesario que proporcione su contraseña a nadie. Nadie de ningún sitio web en línea le pediría la contraseña de su cuenta. Pero si te encuentras con alguien que te pide tu contraseña, puedes denunciar inmediatamente el nombre o el número de contacto de esa persona en ese sitio web. Y el personal se encargará de todo.\nLuego tienes que escribir unos cuantos hashtags que definan perfectamente tu cuenta y el tipo de contenido que publicas en ella. Una vez introducidos los hashtags, tienes que seleccionar el plan que más te convenga. Si quieres, puedes consultar las reseñas. Póngase en contacto con el equipo del sitio web que ha seleccionado en línea, si quiere saber más en detalle sobre todo. Puedes preguntar por los diferentes planes que puedes conseguir en Instagram, preguntar por el procedimiento de compra de likes en Instagram.\nLos expertos del sitio web seleccionan todos los hashtags que les has mencionado y buscan una cuenta similar a la tuya. Y ellos dirigirán tus publicaciones y vídeos a su público, lo que aumentará automáticamente el número de seguidores en Instagram. Asegúrese de mantener su cuenta pública después de pedir los seguidores. No cambie su nombre de usuario después de pedir seguidores, ya que puede confundir al equipo. Puede llamar al número de atención al cliente de cualquier sitio web que ofrezca seguidores de pago y obtener todas las respuestas.


Los viales SporeMate son una gran oportunidad para profundizar en el proceso reproductivo de los hongos o cultivar tus propias setas mágicas. El uso de estos viales es muy sencillo. Solo tienes que quitar la tapa transparente que protege el sitio de la inyección, sin romper el aluminio. Agita el vial SporeMate para dispersar las esporas antes de que recoger una muestra de la tapa de aluminio con el hisopo de alcohol, e insertar la jeringa para extraer la suspensión de esporas. Para una mejor observación por microscopio, recomendamos una magnificación de 400x - 1000x. El segundo hisopo de alcohol es para los cultivadores. Utilízalo para tomar muestras del sitio de inyección de la bolsa de substrato.\nVial De Esporas 'Psilocybe cubensis PES Amazonian' De Mondo\nLa 'Psilocybe cubensis PES Amazonian' es una seta enorme de las profundidades de la selva amazónica, que puede alcanzar una altura de 15cm y está repleta de psilocibina. Este producto forma parte de la gama de Mondo, ¡y es la elección perfecta para los psiconautas experimentados que quieran llevar sus viajes al próximo nivel!\nVial Mondo 'Psilocybe cubensis B+'\nVial Mondo Psilocybe Cubensis B+ (be positive) – sus preciosos y grandes frutos hacen que esta cepa sea muy popular. Conviértete en un investigador y profundiza en la reproducción de los hongos alucinógenos. Ideal para la investigación microscópica o para cultivar a partir de la espora (siempre que sea legal donde vives) El vial contiene 10ml de suspensión. Conservar en lugar oscuro y...\nVial Mondo 'Psilocybe cubensis Golden Teacher'\nVial Mondo Psilocybe cubensis Golden Teacher - Esta Psilocybe cubensis lleva un sombrerillo dorado y te mostrará un nuevo punto de vista. Por lo menos de ahí se deriva su nombre; el origen de esta cepa es desconocido, pero es muy popular por sus enormes frutos con sombrerillos de hasta 5cm de diámetro. Profundiza en el proceso de reproducción de los hongos o hazte criador.\nVial Mondo 'Psilocybe cubensis McKennaii'\nVial Mondo Psilocybe cubensis McKennaii – Esta potente cepa ha sido nombrada en honor del famoso filósofo, escritor, investigador, profesor y psiconáuta americano, Terence McKenna. Y es un nombre adecuado porque el consumo de los frutos de esta cepa provocan un viaje muy filosófico con visones medias/fuertes. Ideal para la investigación microscópica.\nVial De Esporas 'Psilocybe cubensis Moby Dick' De Mondo\nLas setas alucinógenas Moby Dick son un cruce entre la Albino A+ y la Golden Teacher, y son realmente increíbles. Potentes, enormes y fáciles de cultivar, sin duda satisfarán tanto a los psiconautas novatos como a los más veteranos.


Cuando alguien afirma haber visto o creer en ovnis es común que haya risas disimuladas o burlas hirientes\nPublicada en Info News23\nLa existencia de vida extraterrestre es uno de los temas más controvertidos. Cuando alguien afirma haber visto o creer en ovnis es común que haya risas disimuladas o burlas hirientes. Sin embargo, el fenómeno ovni sigue siendo un misterio del cual el ser humano aún no es capaz de entender. ¿Tienen explicación? ¿Son reales, fraudes o errores de cámara? ¿Mentiras, encubrimientos, verdades solapadas? Muchos son los que han intentado proyectar algo de luz en el tema. Entre ellos, varios astronautas. Escucharlos afirmar la existencia extraterrestre es bastante extraño y más aún cuando presentan tan poca evidencia. ¿Qué los motiva a hacerlo? Es obvio que al hablar abiertamente de ovnis y vida extraterrestre se arriesgan a la infamia y la desacreditación de la comunidad científica y del mundo entero.\nBrian O’Leary: Aunque O’Leary no fue al espacio, sí fue astronauta y participó en un proyecto que llevaría al ser humano a Marte. Sin embargo, se canceló y O’Leary renunció a la NASA. Poco después fue seleccionado por Carl Sagan para dar clases en la Universidad de Cornell. Entre los 70 y 80 colaboró en varias revistas de ciencia y astronomía. Durante los años siguientes se desvió de la ciencia ortodoxa y profundizó en temas metafísicos y poco respetados. En los 90 comenzó a aceptar la existencia de vida extraterrestre y a señalar que la NASA y que el gobierno ocultaba información. Creía fervientemente en que los extraterrestres tenían ya mucho tiempo visitando la Tierra. Desde el 2008 fue un fiel defensor de la ufología, hasta que murió en 2011. Edgar D. Mitchell: Este astronauta fue el sexto hombre en pisar la Luna. Entre sus estudios destacan sus doctorados en ciencias de aeronáutica y astronáutica. Participó en la misión Apollo 14 como piloto. En el regreso a la Tierra experimentó un savikalpa samadhi, un tipo de iluminación espiritual, que le cambió la vida. Desde entonces ha tenido un gran interés en los llamados fenómenos paranormales. También cree que los gobiernos de varios países han establecido contacto con seres de otro mundo. Según sus informantes, el incidente de Roswell es real, pero que ha sido encubierto por el gobierno. Según afirma Mitchell, la forma en que el gobierno lo hace es ofreciendo una verdad entre muchas mentiras. James McDivitt: Este astronauta fue testigo de un extraño avistamiento ovni. Mientras el Gemini 4 surcaba sobre Hawái, McDivitt observó un objeto cilíndrico y metálico. Le tomó varias fotos, pero al volver las fotos fueron confiscadas y nunca han salido al público. Joseph Walker: Este piloto de la NASA participó en el programa X-15, el cual le permitió surcar los cielos en una nave supersónica hasta alcanzar el espacio. Por ello se le otorgó la medalla de astronauta. También participó en las pruebas de varias naves, incluidas ciertos prototipos de módulos espaciales. Pero fue durante un vuelo del X-15, en abril de 1962, cuando atisbó 6 ovnis. No fue la única vez que sucedió. Walker tomo fotos y videos de los extraños objetos, pero solo una foto salió al público. Walker, curiosamente, murió en un accidente aéreo 4 años después. Se trataba de un vuelo en formación para tomar fotos para General Electric.\n¿Son reales, fraudes o errores de cámara Mentiras, encubrimientos, verdades solapadas?\nEl avión de Walker desvió su rumbo y colisionó con otro. Las fotos del incidente dejan claro que no hubo algún ovni involucrado, aparentemente. Gordon Cooper: Fue un renombrado piloto y miembro de la Fuerza Aérea. Participó en las misiones Mercury y Gemini. Pero no fue en ellas donde vio a estos extraños objetos voladores, sino años atrás y en varias ocasiones. La primera tuvo lugar mientras volaba por Alemania Occidental en 1951, estos avistamientos se repitieron en varias oportunidades durante ese año. Seis años después tuvo lugar otro avistamiento mucho más cercano. Sucedió cercas de un centro de pruebas aeronáutico. Junto con otro testigo observaron como la nave aterrizaba y minutos después desaparecía a gran velocidad. Tomaron fotos y videos que fueron enviados al Pentágono. No se volvió a saber de ellos, pero Gordon Cooper vio una gran preocupación en ello. Por eso habló abiertamente del tema e incluso presentó ante la ONU una iniciativa que investigue el fenómeno ovni, pues representaba un tema de interés mundial. Sin embargo, sus reclamos no fueron atendidos y durante el resto de su vida continuó exigiendo que los gobiernos hablaran abiertamente del tema y revelaran la verdad. Estaremos más cerca de la verdad


instalacion plantas mas\nColombia activó planta de energía solar más grande ...\n* Enel Green Power puso en pleno funcionamiento la instalación solar más grande en toda la historia de Colombia. Localizada en el departamento del Cesar en el norte de Colombia, la planta solar, con su 86,2 Mega Watt de capacidad total, representa el 80 por ciento de la capacidad solar instalada hasta la fecha en el país.\nApr 11, 2020· Una posición que se ve reflejada en el ranking de Las 20 mayores plantas fotovoltaicas del mundo, dominado abrumadoramente por proyectos de estos tres países. Hay proyectos mayores, pero que se encuentran en sus inicios, y la foto fija a día de hoy de las mayores plantas fotovoltaicas del mundo queda como sigue: ... hola solicito informacion ...\nLas 10 plantas termosolares más grandes del mundo: EEUU y España se reparten el 90% del pastel. José A. Roca 13/06/16 . 1. La energía solar termoeléctrica podría suministrar el 6% de la demanda de electricidad global en 2030 y alcanzar el 12% en 2050, si …\nNov 26, 2018· descargar plantas vs zombies 2 para pc sin emulador ... la forma mas segura de jugar este juego en la computadora o laptop es emulando el SO de los moviles. ... Como Instalar Plants vs Zombies 2 ...\nEn Qmadis somos muy "manitas" y nos encantan las instalaciones caseras. Y una de las primeras instalaciones en las que pensamos cuando comenzamos a vivir en un nuevo hogar es, aparte de la iluminación de la vivienda, la instalación de la antena de televisión. Es por ello que en este artículo vamos a explicar el método de instalación de una antena para una vivienda …\nLa primera planta solar flotante que enchufa España no ...\nLa primera planta solar flotante que enchufa España no está en el mar, está en Extremadura Acciona conectará a la red eléctrica en fase de pruebas una planta fotovoltaica de 12.000 metros cuadrados en un embalse de Cáceres. Hasta ahora, todas las plantas flotantes del país eran instalaciones aisladas sin conexión.\nNov 17, 2019· Leer mas abajo ⬇ ... En esta oportunidad te enseñare a como descargar e instalar plantas vs zombies completo (full) en español para tu pc libre de VIRUS ...\nLos ascensores son sin duda una gran ayuda a la hora de salvar diferentes plantas de altura, sobretodo cuando se trata de salvar 3 plantas o más, la instalación de un ascensor puede suponer una mejora notable tanto en movilidad como en comodidad. Una de las principales cuestiones a la hora de decidirse por instalar un ascensor es el precio.\nACCIONA instala en Extremadura la primera planta ...\n¡Identifica más de 600.000 especies de plantas de todo el mundo en un instante! Con PlantSnap puedes identificar el 90% de todas las especies de flores, hojas, árboles, setas, suculentas y cactus, y hacer que la aplicación se traduzca a 37 idiomas diferentes. ¡Conéctate de nuevo con la naturaleza y comparte las imágenes de las plantas que descubras! ¡Con el Feed Social de …\n¿Cuáles son las principales instalaciones fotovoltaicas en ...\nLa planta solar de Longyangxia, situada en la provincia de Qinghai, en China. Utiliza la tecnología mixta hidro-solar. De este modo, se trata de la planta solar fotovoltaica más grande del mundo utilizando esta tecnología. Esta central …\nMANUAL INSTALACION PLANTAS ELECTRICAS DE EMERGENCIA | PLANTAS DE LUZ ... 2.2.3 En caso de instalación de dos o mas equipos en un mismo cuarto, la separación entre los mismos será de 1.5 metros, y deberán tener espacios independientes para las descargas de aire.\ncepellón se minimiza al transferir la planta al suelo. Los árboles cul-tivados en recipientes varían en tamaño: de plantas muy pequeñas en macetas de 1 galón a grandes árboles en macetas de 25 galones. Las bolsas maceteras son parecidas a los recipientes en el sentido que las plantas se cultivan en el medio y la bolsa durante un tiempo, y se\nPlantas de Emergencia. ... Es la red de conductores eléctricos unidos a una o mas tomas de tierra y provisto de una o varias terminales a las que puede conectarse puntos de la instalación. f) Conexión a tierra. La unión entre u conductor y un sistema de tierra. g) Tierra Física. Cuando se une solidamente a un sistema de tierra que a su vez ...\nLa planta es la fuente de energía más importante de Phoenix y del Sur de California. Inició su pleno funcionamiento en 1988, tras un período de construcción que duró 12 años, con un coste de 5900 millones de dólares, y dando empleo a alrededor de 2.500 personas.\nComo instalar Juego Plantas contra Zombies en tu computadora Para ellos deberás descargar el juegos, lo puedes obtener en el siguiente link juego-plantas-contra-zombis-plants-vs.html. Debes descomprimir el archivo, ingresa a la carpeta Plantas …\nPlanta de tratamiento de aguas residuales domésticas. En el caso de las aguas negras, no es posible reutilizarlas. En este caso la tubería sanitaria se conecta directamente con el red municipal. Puedes diseñar una casa ecológica que reutilice el agua y reduzca la contaminación de agua en la comunidad.\nAlgunas de las aplicaciones de estos sistemas de energía solar fotoeléctrica son las siguientes:. Instalaciones de paneles solares en tejados, terrazas, etc. de viviendas que dispongan de conexión a la red de distribución eléctrica: Se aprovecha la superficie del tejado para colocar sistemas modulares de fácil instalación.; Plantas de producción: Estas plantas de energía ...


Centro de estética integral Lola Sebastian - Zaragoza - Paseo de María Agustín, 4 | PELUQUERIAS UNISEX Páginas Amarillas\nCentro de estética integral Lola Sebastian Zaragoza\nMaquillaje y peinado de novias /novios a domicilio\nCómo ir 41.65035896-0.888624007 Contactar Llamar 976442266\nPaseo de María Agustín, 4 , 50004, Zaragoza\nContacta con Centro de estética integral Lola Sebastian\nInformación y servicios de Centro de estética integral Lola Sebastian\nAcerca de Centro de estética integral Lola Sebastian\nSomos Lola Sebastián, uno de los mejores centros de estética integral en Zaragoza, en donde podrá encontrar servicios garantizados para el cuidado corporal y del cabello, garantizando trabajos de calidad, ya que somos profesionales capacitados y con una continua formación en el campo de la belleza.\nEn Lola Sebastián encuentra:\n- Peinados para toda ocasión.\nMaquillaje y peinado de novias y novios a domicilio.\nContáctenos o visítenos para mayor información.\nCentro de estética integral Lola Sebastian es una empresa que fue constituida el 19/11/1993 bajo la forma social de SOCIEDAD LIMITADA y cuyo CNAE (Clasificación Nacional de Actividades Económicas) se corresponde con la actividad: Peluquería y otros tratamientos de belleza. Cuenta actualmente con una plantilla de de 0 a 10. Su capital social es de 0€ - 3.500€. Actualmente, su facturación se encuentra en el rango de entre 0€ - 500.000€.\nFecha de constitución: 19/11/1993\nInformación de Centro de estética integral Lola Sebastian\nEncuentra en Páginas Amarillas toda la información y servicios sobre Centro de estética integral Lola Sebastian. Consulta el teléfono de contacto y la dirección en Zaragoza para saber cómo llegar.\nOpina sobre Centro de estética integral Lola Sebastian y sube una foto o vídeo del negocio.


Aplique pared cristal | Lampara.es\nCuarto de baño Dormitorio Pasillos Salón / Comedor\nAluminio / Gris / Cinc Blanco / Ópalo Bronce / Latón viejo Claro / Transparente Crema / Ámbar Cromo / Plata Latón / Oro Marrón / Óxido Morado / Rosa / Rosado Multicolor Negro Rojo Verde\nAcero Inoxidable Aluminio Cobre Cristal Latón Otros Metales Plástico Tela / Tejido / Seda Vidrio\nALMA LIGHT BARCELONA AXO LIGHT BEGA FABBIAN KOLARZ LUCANDE MAYTONI SCHULLER TOP LIGHT\nAplique Ninfea en cromo con flores de cristal\nSchonbek Eclyptix aplique de cristal, 91cm, oro\n1.848,68 € (IVA excl.)\nPrecio habitual: 435,45 €\nAplique Celeste con cristales K9\nAplique Trilly en cromo con cristales 1 luz\nAplique Jacqueline, 2 luces, negro\nAplique Kate, 2 luces, blanco, cristales rosas\nAplique Teresa como lámpara de araña, 1 luz\nLámpara de pared ICARO 1 luz, vidrio cristal\nbaño de oro de 24 quilates\nAplique de hoja de plata Sara, 4 luces\nAplique Sevilla con vidrio de cristal, 3 luces\nAplique de 2 luces PERUGIA\nLámpara de pared brillante Aurea en rojo-ámbar\nAplique Royal con cristales, 2 luces, oro antiguo\nAplique de vidrio Mary\nAplique de pared SHERATON 24 k oro 3 llamas\n834,63 € (IVA excl.)\nLámpara de pared Jevana exclusiva con cristales\nPrecio habitual: 768,51 €\nFabbian Vicky - aplique de diseño\nAplique Dolores con cristales, 1 luz\nAplique textil Manfred con cristales\nAplique Viticcio con joyas florales\nLámpara de techo Ontario, 39 x 39 cm, oro\n512,31 € (IVA excl.)\nAplique de cristal Manacor, efecto centelleante\nAplique de cristal DIAMOND LED\nLámpara de pared de cristal decorativa Leila\nAplique Ontario, altura 41 cm, cromo\nAplique Ontario, altura 41 cm, oro\nMás sobre Apliques pared cristal\n¿Qué marcas de apliques de pared de cristal existen?\n¿Se pueden combinar los apliques de pared de cristal con un estilo antiguo?\n¿Hay apliques de cristal con varios brazos?\n¿Debería utilizar apliques de pared de cristal con tecnología LED?\n¿Cómo se limpian los apliques de pared de cristal?\nLos apliques de pared de cristal en tonos dorados ofrecen un aspecto especialmente antiguo.\nLos apliques de cristal pueden encenderse y apagarse mediante un interruptor de pared, un interruptor incorporado en el propio aplique, o un interruptor incorporado en el cable. También pueden encenderse y apagarse mediante control remoto.\nHay apliques de pared cristal de uno o varios brazos.\n¿No estás seguro de cuál es el mejor aplique para tu pared? Aquí encontrarás nuestra guía sobre apliques de pared de cristal.\nApliques de pared de cristal, para un efecto centelleante\nA veces un poco de lujo no está mal, ¿no te parece? ¡Y qué mejor para lograrlo que un sensacional efecto brillante! El cristal es sin duda el material ideal para esto. Además, nada llama tan claramente la atención como un aplique de pared que se coloca precisamente a la altura de los ojos. De esta manera, se garantiza un ambiente de iluminación cálido y atractivo, con maravillosos efectos de luces y sombras. En conclusión, lo ideal para estos casos son los apliques de pared de cristal.\nYa que te has decidido a comprar una nueva lámpara, ¿quieres un modelo de alta categoría? ¿Prefieres además que sea de una marca conocida? En nuestra tienda online puedes ver todas las marcas que te ofrecemos de forma fácil. Solo tienes que utilizar el filtro "Fabricante". Marca las casillas de los fabricantes que más te gusten, como Schonbek o Swarovski, y enseguida obtendrás una lista de resultados.\n¿Te gustaría adornar tu pared con un aplique que parezca venido de otra época? En ese caso, el cristal es el motivo de decoración perfecto. Te sentirás como si estuvieras en un palacio. El toque nostálgico está garantizado. Consejo: Los apliques de cristal en tonos dorados se combinan especialmente bien con los interiores de estilo antiguo.\nLos hay con una sola bombilla, pero también con varias. Son lo que se denomina "apliques de varios brazos o luces". En las imágenes de producto verás rápidamente cuántos brazos tiene el aplique que te gusta, y si se trata de un modelo de un solo brazo o de varios. En la mayoría de los casos, los apliques tienen uno o dos brazos.\nLa moderna tecnología LED tiene tantas ventajas que resulta casi imprescindible, incluso si el aplique de cristal tiene un aspecto antiguo. Estas son las ventajas en comparación con una bombilla convencional:\nun ahorro de energía del 80-90 %,\nuna vida útil 50 veces mayor,\nhasta 50.000 horas de luz,\nuna excelente gestión del calor y\nla posibilidad de crear diseños más compactos.\n¿Cómo se encienden los apliques de pared de cristal? Hay diferentes posibilidades. ¿Cuál de estas prefieres?\nMediante un interruptor de pared\nMediante un interruptor incorporado en el aplique\nMediante un interruptor incorporado en el cable de alimentación\nMediante control remoto (que también permite utilizar la función "multicolor", si está disponible)\nConsejo: En nuestra tienda online, puedes utilizar nuestro filtro "con interruptor" para decidir cuál es la mejor opción para ti.\nBasta con realizar una limpieza en seco: solo tienes que quitar el polvo y la suciedad con un plumero y ¡listo! Si lo haces con regularidad, no tendrás que preocuparte de que la suciedad se quede adherida. Consejo: Hay que tener mucho cuidado con la limpieza en húmedo. Lo mejor es no utilizarla para los apliques. El spray de limpieza podría gotear por la pared y podrías tener que volver a pintarla antes de lo esperado. No obstante, si estás decido a hacer una limpieza en húmeda, ten en cuenta lo siguiente: por tu propia seguridad, no te olvides de apagar antes la luz y de retirar el fusible.\n¿Todavía tienes alguna pregunta? Nuestro servicio de asistencia estará encantado de atenderte. Solo tienes que llamar al 911 791 264 o usar el formulario de contacto.


Escucha una nueva canción de Grizzly Bear – Listen and Wait\nComo ya os contamos a finales de septiembre, Grizzly Bear publicará el próximo 12 de noviembre una reedición de su último y exitoso disco Shields (2012). Los norteamericanos incluirán en esta nueva versión de Shields un disco con caras B,demos y remixes realizados por artistas como Liars, ...\n31 octubre 2013 Dejar un comentarioInternacionalPor asier\nElbow anuncia nuevo disco para 2014: Carry Her Carry Me\nElbow ha anunciado que publicará un nuevo álbum titulado Carry Her Carry Me el próximo 3 de marzo de 2014. La continuación Build A Rocket Boys! ha sido grabada en los estudios Blueprint de Manchester y también en los estudios de Peter Grabriel, y la banda avisa que Carry Her Carry Me tiene ...\nDavid Bowie publicará el próximo 4 de noviembre una nueva edición de su último disco The Next Day, que incluirá cinco nuevos temas y un par de remixes como extra. Por otro lado, cuatro de estos nuevos temas ya se pueden escuchar a través de Youtube desde ayer a la tarde, así que no tendréis que ...\nJames Blake ha sido el ganador de los premios Mercury Prize 2013 celebrados la pasada noche, gracias a su excelente disco Overgrown. El británico ha luchado en estos premios con bandas de la talla de David Bowie, Arctic Monkeys o Foals, así que el jurado lo ha tenido complicado este año. Antes ...\nVídeo del concierto de Queens of the Stone Age en el ‘Bridge School Benefit 2013’\nQueens of the Stone Age han participado en la última edición del Bridge School Benefit, un evento con carácter benéfico que tiene lugar de forma anual y que está organizado por Neil Young y su mujer. Si queréis ver el concierto por parte de QOTSA en el Bridge School Benefit 2013, aquí va el ...\nDespués de liberar hace unos días un nuevo tema llamado Nobody There, la banda británica Veronica Falls acaba de estrenar otra nueva canción titulada Need You Around. La canción ha sido subida ya a soundcloud, así que lo tenéis fácil para poder escucharla. Veronica Falls – Need You Around...