Etiqueta: software

Operador between en SQL

PHPUncategorized

En el último proyecto que participe necesitamos desarrollar reportes con gráficas, estos reportes eran por un periodo de tiempo, es decir, el usuario seleccionaba el rango de fechas del que quería buscar registros en el sistema y generar dicho reporte usando los datos obtenidos. Para este fin tuve que emplear el operador Between de SQL, en las secciones siguientes se muestran ejemplos de su uso, espero que les sea de utilidad.

Keep reading

Metodologías para el desarrollo ágil del software

Uncategorized

Metodologías para el desarrollo ágil del software.

Actualmente los negocios operan en un entorno global que cambia rápidamente. Tienen que responder a nuevas oportunidades y mercados, condiciones económicas cambiantes y la aparición de productos y servicios competidores. El software es parte de casi todas las operaciones de negocio, por lo que es fundamental que el software nuevo se desarrolle rápidamente para aprovechar nuevas oportunidades y responder a la presión competitiva. Actualmente el desarrollo y entrega de manera rápida son los requerimientos más críticos de los sistemas. De hecho, muchas organizaciones están dispuestas a obtener una pérdida en la calidad del software y en el compromiso sobre los requerimientos en favor de una entrega rápida del software.

Los procesos de desarrollo del software basados en una completa especificación de los requerimientos, diseño, construcción y pruebas del sistema no se ajustan al desarrollo rápido de aplicaciones. Cuando los requerimientos cambian o se descubren problemas con ellos, el diseño o implementación del sistema se tiene que volver a realizar o probar. Como consecuencia, normalmente se prolonga en el tiempo un proceso en cascada convencional y el software definitivo se entrega mucho tiempo después al cliente con el que inicialmente se pactó. En un entorno de negocios tan cambiante, esto puede causar verdaderos problemas. Para cuando esté disponible el software, la razón original de su adquisición puede ser que haya cambiado de forma radical que en realidad éste sea inútil. Dicha metodología combina una filosofía y un conjunto de directrices de desarrollo. La filosofía busca la satisfacción del cliente y la entrega temprana de software incremental, equipos pequeños con alta motivación, métodos informales y una simplicidad general del desarrollo. Los procesos de desarrollo rápido de software están diseñados para producir software útil de forma rápida. Generalmente, son procesos interactivos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas.

En los años 80 y principios de los 90, existía una opinión general de que la mejor forma de obtener un software de calidad era a través de una planificación cuidadosa del proyecto y de la utilización de métodos de análisis y diseño soportados por herramientas CASE (Computer Aided Software Engineering). Esta opinión venía fundamentalmente de la comunidad de ingenieros de software implicado en el desarrollo de grandes sistemas y que normalmente se componían de un gran número de programas individuales. Este software era desarrollado por grandes equipos que trabajaban para compañías diferentes y que a menudo estaban dispersos geográficamente y trabajaban durante largos periodos de tiempo.

Sin embargo, cuando este enfoque era aplicado a sistemas de negocios pequeños y de tamaño medio, el esfuerzo invertido era tan grande que algunas veces dominaba el proceso de desarrollo del software, es decir, se pasaba más tiempo pensando en cómo se debía desarrollar el sistema que en cómo programar el desarrollo y cómo hacer las pruebas pertinentes. El descontento de esto produjo que varios desarrolladores propusieran nuevos métodos que eran más ágiles. Aunque estos métodos se basan principalmente en la noción del desarrollo y en las entregas incrementales, proponen procesos diferentes para alcanzar el objetivo.

En una reunión celebrada en febrero de 2001 en Utah-EEUU, nace el término «ágil» aplicado al desarrollo de software. En esta reunión participan un grupo de diecisiete expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos a desarrollar software rápidamente y respondiendo a los cambios que podrían surgir a lo largo de los proyectos. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Varias de las denominadas metodologías ágiles ya estaban siendo utilizadas con éxito en proyectos reales, pero les faltaba una mayor difusión y reconocimiento. Tras esta reunión se creó “The Agile Alliance” (2001), una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos.

El punto de partida fue el manifiesto ágil, un documento que resume la filosofía «ágil». A continuación en la tabla 2.8, vamos a enumerar las principales diferencias de una Metodología Ágil respecto a las Metodologías Tradicionales (llamadas peyorativamente “no ágiles” o “pesadas”). Estas diferencias que no se refieren sólo al proceso en sí, sino también al contexto de equipo y organización que es más favorable a cada uno de estas filosofías de procesos de desarrollo de software.

Si bien la idea de participación del cliente en el proceso de desarrollo es atractiva, el éxito dependerá de tener un cliente que esté dispuesto y lo más importante pueda pasar tiempo con el equipo de desarrollo para así presentar a todos los implicados del sistema, los clientes están sometidos a otras presiones y no pueden participar plenamente en el desarrollo del software. El cliente es el punto clave, solicita los requerimientos que se deben de incluir. Los miembros individuales del equipo puede no tener la personalidad propia para una participación intensa. Por lo tanto, es posible que no se relacionen adecuadamente con los otros miembros del equipo. Priorizar los cambios puede ser extremadamente difícil, específicamente en sistemas en los que existen muchos implicados.

Mantener la simplicidad requiere un trabajo extra. Cuando se trabaja bajo presión por las agendas de entregas, los miembros del equipo no pueden tener a tiempo las especificaciones del sistema. Por consiguiente los métodos ágiles tienen que depender de contratos donde el cliente paga por el tiempo necesario para el desarrollo del sistema en lugar de por el desarrollo de un conjunto de requerimientos específicos. Siempre y cuando el proyecto vaya caminando en forma, esto beneficiará tanto al cliente como al desarrollador. Todos los métodos tienen límites y los métodos ágiles son apropiados para algunos tipos de desarrollo de sistemas. Son los más idóneos para el desarrollo de sistemas para pequeños negocios y medianas empresas. No son adecuados para el desarrollo de sistemas a gran escala con equipos de desarrollo situados en diferentes lugares geográficamente hablando ya que puede haber complejas interacciones con otros sistemas o hardware.

Los métodos ágiles no se deben de utilizar para el desarrollo de sistemas críticos en los que es necesario generar un análisis detallado de todos los requerimientos del sistema para así comprender mejor sus implicaciones de seguridad o de protección. El crecimiento de los métodos ágiles y su penetración ocurre a un ritmo pocas veces visto en la industria: en tres o cuatro años, según el Cutter Consortium, el 50% de las empresas define como “ágiles” más de la mitad de los métodos empleados en sus proyectos (Charette, 2004). Algunas de las metodologías agiles mas usadas en la actualidad se describen a continuación.

  • Metodología XP programación extrema
    La programación extrema XP es posiblemente el método ágil más conocido y ampliamente utilizado. El nombre de XP fue acuñado por Beck (2000), debido a que el enfoque fue desarrollado utilizando las mejores prácticas del desarrollo iterativo y con la participación extrema del cliente. La programación extrema (XP), que algunos consideran una innovación extraordinaria y otros creen cínica (Rakitin, 2001). En la metodología extrema, todos los requerimientos se expresan como escenarios (llamados historias de usuario), los cuales se implementan directamente como una serie de tareas. Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando el código nuevo se integra al sistema. Existe un pequeño espacio de tiempo entre las entregas del sistema.

    El desarrollo incremental se lleva a través de entregas pequeñas y frecuentes del sistema y por medio de un enfoque que sirve para la descripción de requerimientos basado en las historias del clientes o escenarios que pueden ser la base para el proceso de planificación.

La participación del cliente se lleva a cabo a través del compromiso y del tiempo completo del cliente en el equipo de desarrollo. Los colaboradores directos de los clientes participan en el desarrollo y son los responsables de definir las pruebas necesarias que servirán para la aceptación del sistema. El interés de las personas, en vez de los procesos, se lleva a través de la programación en parejas, la propiedad colectiva del código y un proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo. El cambio se lleva a cabo a través de las entregas regulares del sistema, un desarrollo previamente probado y la integración continua. El mantenimiento se lleva a cabo a través de una recta actualización constante para mejorar la calidad del código y la utilización de diseños sencillos que no prevén cambios futuros en el sistema.

En XP, los clientes están implicados en la especificación y establecimiento de prioridades de los requerimientos del sistema. Dichos requerimientos no se especifica como una lista de funciones requeridas en el sistema. Más bien, los clientes del sistema son parte fundamental del equipo de desarrollo esto permite que discutan escenarios con todos los miembros del equipo. Desarrollar conjuntamente tarjetas de historia (story card) que recogen las necesidades del cliente. Por ende el equipo de desarrollo intentará implementar esos escenarios en una entrega futura del software. Un punto fundamental en la ingeniería del soporte tradicional es que se debe de diseñar para futuros. Esto es que se deben de prever los cambios futuros y diseñar éste de forma que tales cambios se puedan implementar fácilmente. La metodología XP ha descartado este principio partiendo del hecho de que diseñar para el cambio es a menudo un esfuerzo inútil. Con frecuencia los cambios previstos nunca se materializa y realmente se efectúan peticiones de cambios completamente diferentes. La metodología extrema aborda este problema sugiriendo que se debe revisar constantemente el software. Esto es, que el equipo de programación busca posibles mejoras y las implementa de forma inmediata así lo que se busca es que siempre sea fácil de entender y cambiar cuando simplemente nuevas historias.

 

 

¿Qué es la computación en la nube o cloud computing?

redes

Es un término que representa un nuevo modelo de informática, tenido por muchos analistas por una innovación tan relevante como lo fue internet en su momento. Además, es el mejor sinónimo de la propia Web.

Cloud Computing es la evolución de un conjunto de tecnologías que afectan al enfoque de las organizaciones y empresas en la construcción de sus infraestructuras de TI. Al igual que ha sucedido con la evolución de la Web, con la Web 2.0 y la Web Semántica, la computación en nube no incorpora nuevas tecnologías. Se han unido tecnologías potentes e innovadoras, para construir este nuevo modelo y arquitectura de la Web.

Si bien Internet es un fundamento necesario, la nube es algo más que Internet. Es aquel lugar donde utilizar tecnología cuando se necesita, mientras se necesite, ni un minuto más. No se instala nada en su escritorio, ni se paga por la tecnología cuando no se utiliza.

La nube puede ser infraestructura o software, es decir, puede ser una aplicación a la que se accede a través del escritorio y se ejecuta inmediatamente tras su descarga, o bien un servidor al que se invoca cuando se necesita. En la práctica, la informática en nube proporciona un servicio de software o hardware.

No existe una definición aceptada universalmente; sin embargo, existen organismos internacionales cuyos objetivos son la estandarización de Tecnologías de la Información y, en particular, de Cloud Computing. Uno de los organismos más reconocidos es el National Institute of Standards and Technology (NIST) y su Information Technology Laboratory, que define la computación en nube (cloud computing) como:

«Un modelo que permite el acceso bajo demanda a través de la Red a un conjunto compartido de recursos de computación configurables (redes, servidores, almacenamiento, aplicaciones y servicios) que se pueden aprovisionar rápidamente con el mínimo esfuerzo de gestión o interacción del proveedor del servicio».

La nube es un conjunto de hardware y software, almacenamiento, servicios e interfaces que facilitan la entrada de la información como un servicio. El mundo de la nube tiene un gran número de actores o participantes. Los grupos de intereses del mundo de la computación en nube son: los vendedores o proveedores: proporcionan las aplicaciones y facilitan las tecnologías, infraestructura, plataformas y la información correspondiente; los socios de los proveedores: crean servicios para la nube, ofreciendo servicios a los clientes; los líderes de negocios: evalúan los servicios de la nube para implantarlos en sus organizaciones y empresas; los usuarios finales utilizan los servicios de la nube, gratuitamente o con una tarifa.

Modelos de la nube

El NIST clasifica los modelos de la computación en nube en dos grandes categorías:

  1. Modelos de despliegue. Se refieren a la posición (localización) y administración (gestión) de la infraestructura de la nube (Pública, Privada, Comunitaria, Híbrida).
  2. Modelos de servicio. Se refieren a los servicios específicos a los que se puede acceder en una plataforma de computación en la nube (Software, Plataforma e Infraestructura como Servicios).

Estas tecnologías ofrecen tres modelos de servicios:

  1. Software. Al usuario se le ofrece la capacidad de que las aplicaciones suministradas se desenvuelvan en una infraestructura de la nube, siendo las aplicaciones accesibles a través de un navegador web, como en el correo electrónico Web. Posiblemente, este es el ejemplo más representativo, por lo extendido, de este modelo de servicio. El usuario carece de cualquier control sobre la infraestructura o sobre las propias aplicaciones, excepción hecha de las posibles configuraciones de usuario o personalizaciones que se le permitan.
  2. Plataforma. Al usuario se le permite desplegar aplicaciones propias (adquiridas o desarrolladas por el propio usuario) en la infraestructura de la nube de su proveedor, que ofrece la plataforma de desarrollo y las herramientas de programación. En este caso, el usuario mantiene el control de la aplicación, aunque no de toda la infraestructura subyacente.
  3. Infraestructura. El proveedor ofrece recursos como capacidad de procesamiento, de almacenamiento o comunicaciones, que el usuario puede utilizar para ejecutar cualquier software; desde sistemas operativos hasta aplicaciones.

Los modelos de despliegue de las infraestructuras y servicios de la nube se clasifican en las siguientes categorías:

  • Nube privada. Los servicios no son ofrecidos al público en general. La infraestructura es íntegramente gestionada por una organización.
  • Nube pública. La infraestructura es operada por un proveedor que ofrece servicios al público en general.
  • Nube híbrida. Resultado de la combinación de dos o más nubes individuales que pueden ser privadas, compartidas o públicas. Permite enviar datos o aplicaciones entre ellas.
  • Nube comunitaria (community). Ha sido organizada para servir a una función o propósito común. Es preciso compartir objetivos comunes (misión, políticas, seguridad). Puede ser administrada bien por las organizaciones constituyentes, bien por terceras partes. Este modelo es el definido por el NIST, aunque la mayoría de organizaciones, proveedores y usuarios de la nube aceptan los tres modelos de despliegue: pública, privada e híbrida.

Proveedores de servicios en la nube

Dentro de este nuevo esquema informático tenemos a varios tipos de proveedores los cuales se muestran a continuación

  • Los servicios de la nube proporcionan la red e infraestructuras de computación mediante plataformas y soluciones. Los proveedores de servicios y soluciones de la nube son similares, y permiten desarrollar y proporcionar servicios y soluciones de la nube desde la perspectiva de los consumidores. Los proveedores de servicios de la nube incluyen organizaciones que operan con centros de datos propios y apoyados en servicios de virtualización. Los proveedores son variados y tienen gran implantación, aprovechando sus centros de datos y de su experiencia en alojamiento de datos y aplicaciones.
  • Proveedor de servicios de plataformas de la nube. Proporcionan plataformas basadas en la nube, hospedados en entornos de sistemas e infraestructuras específicos, para que los desarrolladores puedan acceder a la plataforma, desarrollar una nueva aplicación de negocios y alojarlas en la plataforma basada en la nube.
  • Proveedores de tecnologías. Desarrollan las herramientas y tecnologías que facilitan que la nube se establezca y se proporcione a los consumidores de recursos proporcionados por la nube. Ofrecen un amplio rango de herramientas, tecnologías, sistemas operativos para facilitar el despliegue de nubes públicas, privadas, híbridas y comunitarias.
  • Proveedores de soluciones. Desarrollan aplicaciones o suites completas, para conseguir un amplio mercado de consumidores de la nube (otras operadoras de telefonía e internet).

En la actualidad los gigantes como Microsoft, Google , IBM , Amazon y Rackspace son los líderes mundiales en proveer servicios relacionados con esta tecnología, un caso a destacar es el de Rackspace, el mayor proveedor de hosting a nivel mundial , llega a obtener 100% de ganancias netas por sus servicios , y plataforma en la nube.

Los sistemas operativos en la nube más populares son Redhat,debian , ubuntu server, MacOS server, y Windows Server.Para la virtualizacion en centro de datos utilizan VMware vSphere y Citrix XenServer.

 

Bibliografía Computacion en la nube , José Joyanes Aguilar (Autor)

Modelo Vista Controlador

PHPUncategorized

¿Qué es MVC?

MVC (Model-View-Controller) es un patrón de diseño de software en torno a la interconexión de los tres tipos de componentes principales en un lenguaje de programación como PHP, a menudo con un fuerte enfoque en la programación orientada a objetos (POO). Estos tres tipos de componentes son vagamente llamados modelos, vistas y controladores.

El modelo es donde se guarda todo la lógica del negocio de una aplicación, la lógica del negocio puede ser cualquier cosa específica acerca de cómo una aplicación almacena los datos, o utiliza servicios de terceros con el fin de cumplir con sus necesidades. Si la aplicación debe acceder a la información en una base de datos, el código deberá estar guardado en el modelo.

La vista es donde se encontrarán todos los elementos de la interfaz de usuario de una aplicación, esta puede contener código HTML, hojas de estilo CSS y archivos Javascript. Cualquier cosa que el usuario pueda ver, es guardado en la vista, y algunas veces lo que ve el usuario actualmente es la combinación de varias vistas en la misma petición.

El controlador es el componente encargado de conectar el modelo con la vista. Los controladores aíslan la lógica del negocio de un modelo de los elementos de la interfaz de usuario de una vista y maneja la forma en la que la aplicación responde a la interacción del usuario en la vista. Los controladores son el primer punto de entrada en estos componentes, ya que la primera solicitud se pasa a un controlador, que luego instancia a los modelos y vistas requeridas para cumplir con una petición a la aplicación (2).

Ciclo de vida del MVC.

  • El usuario realiza una petición.
  • El controlador captura la petición del usuario.
  • El controlador llama al modelo.
  • El modelo interactúa con la base de datos, y retorna la información al controlador.
  • El controlador recibe la información y la envía a la vista.
  • La vista procesa la información recibida y la entrega de una manera visualmente entendible al usuario (3).

Figura 1. Ciclo de vida del MVC.

Ventajas de MVC

Las principales ventajas del uso del patrón MVC son (4):

  1. La separación del Modelo y la Vista, lo cual logra separar los datos, de su representación visual.
  2. Facilita el manejo de errores.
  3. Permite que el sistema sea escalable si es requerido.
  4. Es posible agregar múltiples representaciones de los datos.

Desventajas de MVC

Las principales desventajas del uso del patrón MVC son (4):

  1. La cantidad de archivos que se deben mantener incrementa considerablemente.
  2. La curva de aprendizaje es más alta que utilizando otros modelos.
  3. Su separación en capas, aumenta la complejidad del sistema.

Newsletter

Suscríbete y recibe contenido exclusivo.

* indicates required