¿Por qué ASP.NET MVC en vez del viejo y conocido ASP.NET Web Forms?

ASP.NET Web Forms es simple: si quiero hacer una funcionalidad de búsqueda en mi página, arrastro un cuadro de texto, un botón, y programo el evento click de este último con la lógica de la búsqueda. El proceso es prácticamente idéntico a lo que se haría en una aplicación de escritorio, en donde los eventos gobiernan el comportamiento de la aplicación.

Y ése, es precisamente el problema. En realidad cuando desarrollamos aplicaciones web no deberíamos pensar en términos de páginas, eventos y botones, por la sencilla razón de que la web no funciona así. La Web funciona en términos del protocolo HTTP y sus comandos, como GET y POST. La presentación se obtiene mediante HTML y CSS. El documento HTML se manipula con JavaScript. De hecho en realidad no hay páginas, ya que una URL es básicamente un puntero a un recurso que no necesariamente debe estar mapeado a un archivo físico (.html o .aspx) en el servidor.

Por esa razón, ASP.NET Web Forms debía hacer mucho trabajo detrás de escena para lograr que la aplicación orientada a eventos que nosotros escribimos desde Visual Studio se convirtiera en una aplicación HTTP real. Básicamente Web Forms genera por nosotros el código HTML y JavaScript respectivo, lo que implica que realmente nunca tenemos el control real sobre el código que ejecutará el navegador.

En ese sentido, MVC nos permite volver a lo básico. Mediante este modelo podremos desarrollar aplicaciones Web que funcionen como realmente opera la Web, haciendo uso de HTTP y sus comandos, y separando la lógica de la presentación. Podremos incorporar con mayor facilidad tecnologías como jQuery, HTML5 o CSS3 a nuestros sitios y lo más importante, tendremos absoluto control sobre el código HTML y JavaScript que será entregado al navegador.

Esta es la primera de varias entradas que buscan ayudarle a los desarrolladores a nivelar sus conocimientos en Web Forms y MVC, y hacer que la transición entre las dos tecnologías sea lo más simple posible.

Autor: Hugo Fernando Aristizabal - Consultor & Arquitecto de Software

Evolución de la Ingeniería de Requisitos: El análisis de negocio

Si bien, el término de Ingeniería de Requisitos es ampliamente conocido en el ámbito de la Ingeniería de Software, orientado siempre a determinar las necesidades de un sistema nuevo o modificado. Se ha venido  generado y madurando un enfoque de alto nivel orientado a los negocios. De aquí aparece el concepto de Análisis de Negocio, donde inserta la Ingeniería de Requisitos como uno de sus pilares y cambia su enfoque pasivo de identificar necesidades a determinar activamente soluciones a problemas concretos del negocio. Por lo cual, acompañar temas de requisitos, modelado de procesos y arquitecturas empresariales es una idea que suena muy bien.

Para ello, se requiere un organismo de estandarización en este campo y se da origen al IBBA (International Institute of Business Analysis).

Más información en:

http://www.iiba.org/

Autor: Juan Diego Moreno- Ingeniero de requisitos

Clasificación de proceso de negocio

En generar los procesos de negocio de una organización pueden ser clasificados en tres grandes grupos según el BPM CBOK (Process Management Common Body of Knowledge), estos tres  grupos son:

Autor: José Benjamín Vega Pérez - Consultor y Arquitecto de Software

Modelo de madurez en redes inteligentes (Smart Grid Maturity Model)

Si bien es cierto que varias de las empresas de generación, transmisión, distribución y comercialización de energía han desarrollado una serie de iniciativas en pos de mejorar la calidad del servicio incorporando nuevas tecnologías y nuevos procesos, logrando resultados interesantes en varios niveles, es difícil comparar el nivel de desarrollo que tiene cada una de las empresas del sector en varias áreas de interés con relación a redes inteligentes (en adelante Smart Grid). El SEI (Software Engineering Institute) define el Smart Grid Maturity Model, el cual consiste en clasificar áreas de interés en el ecosistema Smart Grid y calificar de 0 a 5 el nivel de madurez que tiene cada empresa.

Las áreas de dentro del ecosistema Smart Grid son:

• ·         Estrategia, Administración y Regulación
• ·         Organización y estructura
• ·         Operaciones en la red
• ·         Administración de activos
• ·         Tecnología
• ·         Clientes
• ·         Integración de cadena de valor
• ·         Sociedad y ambiente

A continuación se puede observar las características propias de cada nivel de madurez:

Nivel de madurez	Nombre	Características
5	Pioneros	Liderazgo en la industria, con una innovación marcada y una referenciación en el entorno.
4	Optimizando	Optimizando los beneficios a lo largo de toda la organización. En esta etapa se contemplan implementaciones que pueden ir más allá de la organización y se incrementa el nivel de automatización.
3	Integrando	Integrar de manera transversal en toda la organización los desarrollos realizados, teniendo en cuenta un nivel de desempeño óptimo.
2	Habilitando	Realizando inversiones basados en la visión establecida  y en la estrategia de la empresa. Implementar proyectos que habiliten el entorno de red inteligente (se pueden trabajar proyectos de manera aislada).
1	Iniciando	Se realizan primeros pasos, explorando opciones, realizando experimentos y desarrollando una visión de red inteligente.
0	Defecto	Nivel por defecto (status quo)

El modelo de madurez es pues una forma adecuada de medir el nivel  que tiene una organización en torno a Smart Grid y es un medio para plantear una hoja de ruta para llegar a un nivel deseado en determinado tiempo, tal como se puede apreciar en la siguiente figura:

Fuente: SEI https://www.sei.cmu.edu/smartgrid/start/

Autor: Juan Camilo Cardona - Analista Sr de negocio

  JQuery Mobile   

"Write Less, Do More".

En lugar de desarrollar aplicaciones únicas para cada dispositivo móvil o sistema operativo, el framework jQuery Mobile nos  permite diseñar una aplicación o sitio web que podrá correr en las más populares plataformas de Smartphone y  Tablet, como:

jQuery Mobile es un sistema de interface de usuario basado en el framework jQuery Javascript y HTML5,  soporta Ajax y gestos para dispositivos táctiles.

JQuery Mobile utiliza un sistema de soporte de plataformas de 3 niveles:

A (Full), B (Full sin Ajax), C (HTML básico).

Más información en: http://jquerymobile.com/gbs/1.4/

Autor: David Álvarez- Consultor y Arquitecto de software.

PRUEBAS BI

Primera Parte del flujo

El detalle de las actividades del flujo son las siguientes:

Solicitud de Pruebas: El proceso de pruebas se iniciará mediante una solicitud por parte del Analista de Negocio  quien enviara la información necesaria para comenzar el proceso de aseguramiento de calidad.

 Documento de Visionamiento Completo o Incompleto: Una vez se haya generado el documento de Visionamiento, el QA valida con el Analista de Negocio si el documento está completo o no.

 Planeación de Pruebas y Estimación de Tiempos: Luego de analizar la complejidad y revisar muy bien la documentación, se procederá a elaborar el documento de plan de pruebas. En él que se detallan los aspectos relevantes que harán parte del proceso de aseguramiento de calidad, incluyendo el alcance de la prueba, supuestos, estrategias, recursos humanos, etc. Además de lo anterior, en esta actividad se realiza el cronograma detallado de actividades, tareas que serán realizadas por el QA y tendrán la supervisión directa del Analista de Negocio .

  Aprobación o Rechazo del Plan de Pruebas: Una vez se haya generado el plan de pruebas y el cronograma, el QA envía dicha información al Analista de Negocio para recibir su aprobación o rechazo. En caso de modificaciones al plan de pruebas o al cronograma, serán negociados entre QA y el Analista de Negocio .

  Verificación del Visionamiento: El proceso de verificación de requerimientos consiste en identificar errores en la definición inicial que se realiza con el cliente, con el fin de tener una especificación mucho más refinada de la solución.

 Diseño de Casos de Prueba: Esta actividad consiste en la descripción detallada de todos los requerimientos que debe tener la solución de BI en casos de prueba. Los casos de prueba permitirán validar el aplicativo en forma sistémica, con el fin de seguir un orden consecutivo en la ejecución y no perder de vista ninguna incidencia o dejar de probar algún escenario específico.

  Entrega de la Solución de BI: Esta actividad verifica si la versión de la solución  que se va a probar es lo suficientemente estable en el ambiente de desarrollo, como para que sea implementada en un ambiente de pruebas en donde la versión debe estar congelada y así se comiencen a ejecutar los casos de prueba diseñados.

Autor: Andrea Marcela Barrientos 

Reglas de Negocio

En los últimos años el termino regla de negocio (Business Rule) se ha perfilado como muy  importante, tanto así, que diversas iniciativas y esfuerzos se han realizado a nivel mundial para estandarizarlas  y automatizarlas a través de motores de reglas de negocio, los cuales hay varios disponibles en el mercado. 

¿Qué es una regla de negocio?

Según el  Business Rule Group: "Una Regla de Negocio es una declaración que define o limita algún aspecto del negocio".  Esta definición es bastante  general por lo que podemos observar otras definiciones como:

·        Una Regla de Negocio es una declaración completa y atómica, (es decir, indivisible en otras Reglas) que permite ser expresada de forma inteligible y que, al juntarse con las demás Reglas, conforman el marco estructural, la política, la estrategia y la operativa de una empresa u organización. 

·         Las Reglas de Negocio se encuentran siempre presentes en la actuación de una organización, bien de manera explícita (una política de salarios, el horario laboral, el descuento a aplicar en función de las condiciones de la venta, etc.) o de manera implícita no expresada (el trato cortés con los clientes, la responsabilidad del supervisor sobre sus supervisados, etc.) implicando en general la participación directa o indirecta de personas.

Para mayor entendimiento en el siguiente enlace se observar el “Manifiesto de Reglas de Negocio. Los Principios de la Independencia de las Reglas”.

http://www.businessrulesgroup.org/brmanifesto/BRManifiesto.pdf

En el siguiente enlace se observa la implementación de reglas de negocio en un motor de reglas de negocios  del mercado.

http://pic.dhe.ibm.com/infocenter/brjrules/v7r1/index.jsp?topic=%2Fcom.ibm.websphere.ilog.jrules.doc%2FContent%2FBusiness_Rules%2FDocumentation%2F_pubskel%2FJRules%2Fps_JRules_Global1384.html

Autor: Jose Benjamin Vega- Consultor & Arquitecto de Software

Diferencia entre error, defecto y fallo

Error (“Error”) (IEEE 610):

Acción humana que produce un resultado incorrecto, por ejemplo: un código escrito sin seguir un estándar, un error producido por un error en la sintaxis de una instrucción.

Defecto (“Defect”, “Bug”):

Desperfecto en un componente o sistema que puede ser la causa por la cual el sistema o componente no logre llevar a cabo su función específica, por ejemplo: Sentencia o definición de datos incorrectas, operaciones erradas.

Fallo (“Failure”):

Desviación de un componente o sistema respecto de la prestación, el servicio o resultado esperados. (Fenton).

Cuando un defecto es encontrado durante la ejecución de una aplicación puede producir un fallo.

Autor: Patricia Gómez