Skip to main content

Operador between en SQL

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.

(más…)

Leer Más

Metodologías para el desarrollo ágil del software

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.

 

 

Leer Más

7 razones para vender en internet

Panorama del comercio electrónico en México

 

La gente está cambiando sus hábitos de compra. Un estudio realizado por Asociación Mexicana de Internet (AMIPCI), arrojó que México tiene 51.2 millones de usuarios en Internet, de los cuales, el 50% han realizado una compra en línea.

Las ventas generadas por el comercio electrónico en el 2013, según AMIPCI (Asociación Mexicana de Internet) alcanzaron 9,000 millones de dólares, que representan un 42% en la venta de productos y bienes de consumo.

Esto es una de las razones por la cual muchas de las tiendas más grandes del país tienen su propia tienda en línea, venden sus productos en plataformas de comercio electrónico o ambas.

Pero el comercio electrónico no solo está al alcance de las grandes compañías, esta manera de vender a los consumidores la puede implementar cualquier persona.

Las principales ventajas de tener un catálogo de productos en internet son las siguientes:

1.- Reduce costos. Abrir una tienda virtual es lógicamente más económico, pues permite a las empresas crecer con menos recursos al evitar el pago de renta del local, servicios, sueldos, etcétera. También es más económico  porque al anunciar sus productos online, están haciendo publicidad por Internet,  el cual es un medio de promoción más barato que la publicidad la cual se utiliza en medios de comunicación tradicionales.


2.- Genera lealtad con los clientes. No existen muchas empresas que ofrezcan una buena  experiencia de compra  electrónica, incluso todavía hay miles que no tienen presencia en línea.  Esta es una oportunidad para lograr que tus clientes disfruten esa experiencia, a través de ofrecerles un amplio catálogo de productos,  buenos precios y facilidad en el uso de las plataformas.

3.- Atención y Garantía de Satisfacción Total. Los sitios de e-commerce conocen la importancia de la atención al cliente y  saben que en la mayoría de los casos hasta no ver o tocar un producto es como se toma la decisión final de compra, por ello cuenta con un chat para asesorarte durante la elección del producto, así como una Garantía de Satisfacción Total, en la que los clientes tienen 30 días después de que les llegue el producto para devolverlo y pedir el reembolso de su dinero si los artículos no cumplieron con sus expectativas. Si un cliente está satisfecho con su experiencia de compra del algún producto seguramente regresará al sitio y hará su recomendación a través del “word of mouth” o de boca en boca.

4.- Mayor alcance de público. Al comprar y vender  por Internet, los productos están al alcance de todos desde cualquier lugar y a cualquier hora los 365 días de año. Además, en Internet hay más de 350 millones de usuarios activos, es decir cuenta con un público mucho mayor que los que podrían transitar por una tienda física. Sin lugar a dudas, las posibilidades de crecimiento y el alcance de internet son espectaculares.

5.- Seguridad para el vendedor y el comprador. Una de las principales causas por las que los internautas aún no se atreven a comprar en línea, es por el desconocimiento y/o desconfianza  en el uso de los sistemas de pago online; sin embargo, vendiendo a través de plataformas electrónicas tienes la seguridad de que cuenta con el sello de confianza otorgado por Amipci.  Con esto proteges los datos de tus usuarios y  evitas que los de su tarjeta sean utilizados con fines maliciosos.  Si los usuarios tienen la seguridad de realizar compras online con su tarjeta de crédito, las ventas por ende aumentan, pues los clientes podrán disfrutar de grandes beneficios como rebajas y/o facilidades de pago.

6.- Facilidad de entrega de productos. Algunos usuarios consideran que un riesgo de las compras por Internet, es que la mercancía no llegue bien o a tiempo, pero cada vez existen más empresas de logística que ofrecen servicios de entrega rápidos, eficaces y seguros, con precios accesibles.  También puedes utilizar una plataforma que cuente con rastreo de pedido, para que tus clientes comprueben el estado del envío de su producto, y tengan la  confianza de que su compra llegara en tiempo y forma.

 

7.-Mayor participación en la cartera de los clientes. Otro de los beneficios que reciben las empresas al vender por Internet, es que generan mayor participación en la cartera de los clientes, pues el 50% de los usuarios investiga los productos en Internet antes de buscarlos en la tienda física, por lo que es importante para cualquier compañía crear vínculos e interacción con el consumidor a través de internet, pues es una parte relevante en  su proceso de compra.

Leer Más

Modelo Vista Controlador

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

Leer Más

Implementación de dos zonas gatekeeper H.323

 

Figura 1. Topología de red practica

Para la segunda práctica utilizamos 2 gatekeeper para marcar 2 zonas diferentes, aquí cambia la configuración de ambos Gateways y de ambos gatekeeper.

Para el gatekeeper 1 tomamos las configuraciones de la practica uno y se le agrega las siguientes secciones

[RasSrv::Neighbors] Nombre para identificar a los vecinos en la red

GK1=GnuGK

GK2=GnuGK

[Neighbor::GK1] Aquí se especifican las configuraciones de un vecino

GateKeeper Identifier=GK1 Identificador del gatekeeper

Host=172.16.0.3 una dirección ip para este vecino

SendPrefixes=100, 200, 300, 400, 4444, 700, 800 Lista de prefijos que este vecino espera recibir

AcceptPrefixes=500, 600, 700, 800, 5555, 100, 200, 300 lista de prefijos que el gatekeeper aceptara

ForwardLRQ=always determina si el LRQ recibido deberá o no ser reenviado

[Neighbor::GK2] Aquí se especifican las configuraciones de un vecino

Gatekeeper Identifier=GK2 Identificador del gatekeeper

Host=172.16.0.4 una dirección ip para este vecino

SendPrefixes=500, 600, 700 800 Lista de prefijos que este vecino espera recibir

AcceptPrefixes=100, 200, 300, 400, 5555, 900 lista de prefijos que el gatekeeper aceptara

ForwardLRQ=always determina si el LRQ recibido deberá o no ser reenviado

Figura 2. Archivo creado para Gatekeeper 1.

Para el caso del gatekeeper 2 instalamos el GnuGK como en la práctica uno y creamos el archivo GK2.ini con la siguiente información del GK1

Figura 3. Archivo creado para Gatekeeper 2.

Después se configura un Gateway como en la práctica uno.

Figura 4. Pantalla inicial del entorno web de los fxs.

Figura 5. Advance Setup del entorno web de los fxs.

Figura 6. Parámetros de configuración del Gateway 1.

Y para el segundo Gateway queda de la siguiente manera

Figura 7. Parámetros de configuración del Gateway 2.

Iniciamos los servicios del GnuGK con el siguiente comando, teniendo en cuenta que la ruta y el nombre del archivo puede cambiar (la ruta y el nombre puede variar según donde se creara el archivo).

gnugk –tt –c /home/Joel/GK1.ini para el gatekeeper uno

gnugk –tt –c /home/GK2.ini para el gatekeeper dos

Acto seguido Aplicamos las configuraciones y reiniciamos ambos Gateways para realizar las pruebas necesarias.

 

Leer Más