Aspectos relevantes en el sector eléctrico

Se define el Sector Eléctrico Colombiano como el conjunto de participantes del Mercado de Energía Mayorista que hacen parte de la cadena productiva, así: generadores, transmisores, distribuidores y comercializadores. A continuación se presentan las entidades que realizan las actividades de Dirección, Planeación, Regulación, Control y vigilancia del sector eléctrico en Colombia.

Ministerio de Minas y Energía:

Ente adscrito a la Presidencia de la República, encargado de la dirección del Sector Eléctrico.

Unidad de Planeación Minero-Energética (UPME):

Unidad administrativa especial, adscrita al Ministerio de Minas y Energía, encargada de la planeación integral del sector minero energético, creada por el decreto 2119 de 1992 y organizada según lo previsto en el artículo 15 de la Ley 143 de 1994.

Comisión de Regulación de Energía y Gas (CREG):

Organismo creado mediante el artículo 68 y siguientes de la Ley 142 de 1994, como unidad administrativa especial, con independencia administrativa, técnica y patrimonial, adscrita al Ministerio de Minas y Energía, encargada de emitir la Regulación del sector eléctrico y de Gas combustible.

Superintendencia de Servicios Públicos Domiciliarios (SSPD):

Entidad encargada de la inspección y vigilancia de las entidades que presten los servicios públicos domiciliarios, y los demás servicios públicos a los que se aplica la Ley 142 de 1994, creada por el artículo 75 y siguientes de dicha Ley.

Autor: Constanza Escobar Ángel - Especialista de negocio.

Certificaciones en Análisis de Negocio

Actualmente es el IBBA (International Institute of Business Analysis) el encargado de la estandarización de la práctica de Análisis de Negocio. Por ello actualmente cuenta con dos certificaciones:

·         Certification of Competency in Business Analysis (CCBA®):  Reconocimiento formal en habilidades esenciales de BA.

·         Certified Business Analysis Profesional (CBAP®): Clasificación Senior en análisis de negocio.  Son la élite de la comunidad de BA.

Más información en:

http://www.iiba.org/Certification-Recognition.aspx

                                                                              Autor: Juan Diego Moreno- Ingeniero de requisitos

SEGUNDA PARTE DEL FLUJO – PRUEBAS BI

Ejecución de Pruebas: Una vez se haya finalizado el diseño de los casos de prueba, se procederá a ejecutar el primer ciclo de pruebas en un ambiente de pruebas congelado, donde se garantice que no se realizarán actualizaciones mientras se ejecute el ciclo de pruebas. En esta instancia se hallarán incidencias que deberán ser formalmente reportados a través de una herramienta de seguimiento de defectos.

 Corrección de Incidencias: Luego de finalizar el primer ciclo de pruebas, o incluso durante este, el analista de desarrollo corregirá las incidencias reportadas y realizará una primera prueba en su propio ambiente de desarrollo. Una vez se hayan realizado y validado las correcciones en el ambiente de desarrollo, se generará una nueva versión de la solución que será instalada en el ambiente de pruebas.  El analista de desarrollo será el responsable de la actualización del estado de avance de las incidencias que tuviera asignadas.

Cuando la nueva versión se encuentre disponible en el ambiente de pruebas, se estará en condiciones de iniciar un segundo ciclo de pruebas. En este ciclo se sumarán los casos de prueba asociados con las incidencias reportadas en el ciclo anterior, esto con el objetivo de verificar el impacto de los cambios derivados de las correcciones de las incidencias. Los pasos “Ejecución de Pruebas” y “Corrección de Incidencias” se repetirán por cada ciclo de prueba hasta alcanzar los criterios de completitud de la prueba, especificados en el plan de pruebas.

Diseñar Nuevos Casos de Prueba: Si durante el proceso de ejecución de cualquier ciclo de pruebas se llega a la conclusión que existe un escenario de la solución que no se había identificado, este se adicionará como un nuevo caso de prueba.

Uno de los controles en el proceso de aseguramiento de calidad para nuevos desarrollos consiste en ejecutan pruebas de aceptación de usuarios finales. En esta prueba el usuario verificará que lo implementado cumpla con los requerimientos solicitados inicialmente, además puede sugerir cambios mínimos que deben ser tenidos en cuenta por desarrollo.  Luego el QA, validara que todas las incidencias que hayan sido reportadas están solucionados y no hay ningún error adicional.

Generar Resumen de Pruebas: Al finalizar todos los ciclos de prueba se recolectaran todos los resultados de la misma, con el fin de establecer indicadores, gráficos estadísticos y métricas que permitan analizar cómo fue conducido el proceso y establecer recomendaciones sobre el mismo. Para ello, el QA  generará un documento llamado Resumen de Pruebas, que contendrá todos los resultados del proceso.

 Certificación: Por medio de una carta de certificación se garantizara que la solución cumple con las condiciones pactadas en el Visionamiento y que no existen más incidencias en la misma, por lo que la solución de BI es apta para ser desplegada en el ambiente de producción.

                                                                                                      Autor: Andrea Marcela Barrientos 

Notaciones de modelado de procesos

Una notación de modelado de proceso es básicamente un conjunto de símbolos, iconos,  figuras, conectores y reglas, que ayudan a mostrar el relacionamiento entre los diferentes componentes de un proceso de negocio.

Seleccionar y utilizar una notación de modelado en la definición de procesos de negocio es lo recomendado por las mejores prácticas y nos ofrece ventajas como:

                     Permitir un fácil entendimiento de los procesos de negocio por parte de los interesados.

      Facilitar la presentación de los procesos de negocio en la organización.

      Estandarizar del lenguaje para comunicar los procesos.

      Facilitar en el modelado, gracias a la existencia de herramientas de software en el mercado                    que permiten realizar la diagramación.

Entre las notaciones de modelado de procesos más utilizadas a nivel mundial tenemos:

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

¿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