Tecnologias de la Informacion

Hola, como están, este post es raro, no acostumbro ah vincularme con otros tecnologías si no estoy trabajando en ellas, pero un amigo me pregunto de como trabajar C# con PostgreSql, como sabes PostgreSql es un servidor de base de datos orientada a objetos cuya procedencia es de software libre.

Investigando encontré un proveedor de datos para .NET llamado Npgsql, ya que como sabrán, no está dentro de los proveedores de datos predefinidos en .NET. Este proveedor funciona para versiones 7. Xxx de PostgreSql y posteriores. Tambien me descargue el PostgreSql 8.3.

Despues de instalar el servidor de PostgreSql, se comienza a ver las diferencias con Sql Server, ya que este servidor se ejecuta en el puerto 5432.

Lo primero es vincular las librerías correspondientes al poryecto.

Despues es vincular los namespace al proyecto.

using Npgsql;

using NpgsqlTypes;

using Npgsql.Design;

 

Despues de crear una pequeña BD y de crear  una tabla con unos daticos. se hace la conexion y se prueba.

y hace queda la aplicacion

 y aqui esta la demo.

Bueno espero les guste.

Romny Duarte

 

 

 

 

Visión general del proceso

 

El resultado final se construye de forma iterativa e incremental.

 

Al comenzar cada iteración (“sprint”) se determina qué partes se van a construir, tomando como criterios la prioridad para el negocio, y la cantidad de trabajo que se podrá abordar durante la iteración.

 

 

 

Los componentes y conceptos empleados en Scrum son:

 

Las reuniones

 

·         Planificación del sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál es el trabajo y los objetivos que se deben cubrir con esa iteración.

 

Esta reunión genera la “sprint backlog” o lista de tareas que se van a realizar, y en ella también se determina el “objetivo del sprint”: lema que define la finalidad de negocio que se va a lograr.

 

·         Seguimiento del sprint: Breve reunión diaria para dar repaso al avance de cada tarea, y al trabajo previsto para la jornada.

 

 

 

Sólo interviene el equipo, y cada miembro responde a tres preguntas:

 

 

1.     Trabajo realizado desde la reunión anterior.

2.     Trabajo que se va a realizar hasta la próxima reunión de seguimiento.

3.     Impedimentos que se deben solventar para que pueda realizar el trabajo.

 

·         Revisión de sprint: Análisis y revisión del incremento generado. Esta reunión no debe tomarse como un “acontecimiento especial”, sino como la presentación normal de los resultados.

 

 

 

Los elementos

 

·         Product backlog: Requisitos del sistema. Se parte de la visión del resultado que se desea obtener; y evoluciona durante el desarrollo.

 

Es el inventario de características que el propietario del producto desea obtener, ordenado por orden de prioridad. Es un documento “vivo”, en constante evolución. Es accesible a todas las personas que intervienen en el desarrollo. Todos pueden contribuir y aportar sugerencias.

 

El responsable del product backlog es una única persona y se le denomina: propietario del producto.

 

·         Sprint Backlog: Lista de los trabajos que realizará el equipo durante el sprint para generar el incremento previsto.

 

El equipo asume el compromiso de la ejecución. Las tareas están asignadas a personas, y tienen estimados el tiempo y los recursos necesarios.

 

·         Incremento: Resultado de cada sprint.

 

Se trata de un resultado completamente terminado y en condiciones de ser usado.

 

Los roles o responsabilidades

 

El grado de funcionamiento de Scrum en la organización depende directamente de estas tres condiciones:

 

·         Características del entorno (organización y proyecto) adecuadas para desarrollo ágil.

 

·         Conocimiento de la metodología de trabajo en todas las personas de la organización y las implicadas del cliente.

 

·         Asignación de responsabilidades:

 

·         Del producto.

 

·         Del desarrollo.

 

·         Del funcionamiento de Scrum

 

Responsabilidad del producto: El propietario del producto

 

En el proyecto hay una persona, y sólo una, conocedora del entorno de negocio del cliente y de la visión del producto. Representa a todos los interesados en el producto final y es el responsable del Product Backlog.

 

Se le suele denominar “propietario del producto” y es el responsable de obtener el resultado de mayor valor posible para los usuarios o clientes.

 

Es responsable de la financiación necesaria para el proyecto, de decidir cómo debe ser el resultado final, del lanzamiento y del retorno de la inversión.

 

En desarrollos internos puede ser el product manager, o responsable de marketing… quien asume este rol.

 

En desarrollos para clientes externos lo más aconsejable es que sea el responsable del proceso de adquisición del cliente.

Responsabilidad del desarrollo: El equipo

 

Todo el equipo de desarrollo, incluido el propietario del producto conoce la metodología Scrum, y son los auténticos responsables del resultado.

 

Es un equipo multidisciplinar que cubre todas las habilidades necesarias para generar el resultado.

 

Se auto-gestiona y auto-organiza, y dispone de atribuciones suficientes en la organización para tomar decisiones sobre cómo realizar su trabajo.

 

Responsabilidad del funcionamiento de Scrum (scrum manager)

 

La organización debe garantizar el funcionamiento de los procesos y metodologías que emplea, y en este aspecto Scrum no es una excepción.

 

En el modelo de Scrum definido por Jeff Sutherland, esta responsabilidad se garantiza integrando en el equipo una persona con el rol de ScrumMaster.

 

Considerando que las realidades de unas y otras empresas pueden ser muy diferentes, y que siempre que sea posible es mejor optar por adaptar las prácticas de trabajo a la empresa, y no al revés, en ocasiones puede resultar más aconsejable:

 

·         Que en lugar de una persona con la función de “ScrumMaster”, sean las personas y puestos más adecuados en cada organización los que reciban la formación adecuada y asuman las funciones correspondientes para cubrir esta responsabilidad.

 

·         Que al compromiso de funcionamiento del proceso se sume también la dirección de la empresa, con el conocimiento de gestión y desarrollo ágil; y facilitando los recursos necesarios.

 

Scrum Manager designa por tanto, más que al rol, a la responsabilidad de funcionamiento del modelo. Puede ser a nivel de proyecto o a nivel de la organización; y en algunos casos resultará más apropiado un rol exclusivo (tipo ScrumMaster) y en otros, puede ser mejor que la responsabilidades de funcionamiento las asuman los responsables del departamento de calidad o procesos, o del área de gestión de proyectos…

 

 

El modelo Scrum

 

El origen

 

Scrum es una metodología ágil para gestionar proyectos de software, que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80 (Ikujiro & Takeuchi, 1986). Aunque surgió como práctica en el desarrollo de productos tecnológicos, resulta válido en los entornos que trabajan con requisitos inestables, y necesitan rapidez y flexibilidad; situaciones habituales en el desarrollo de algunos sistemas de software.

 

Scrum para software

 

En 1993, Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 presentó, junto con Ken Schwaber, las prácticas que empleaba como proceso formal, para gestión del desarrollo de software en OOPSLA 96 (Schwaber & Sutherland, 1996). En 2001 formaron parte de los firmantes del Manifiesto Ágil. Las prácticas diseñadas por Schwaber y Sutherland para gestionar el desarrollo de software están incluidas en la lista de modelos ágiles de Agile Alliance.

Introducción al modelo

Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro, porque la gestión no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

 

Scrum es una metodología ágil:

 

• Es un modo de desarrollo de carácter adaptable.

 

• Orientado a las personas antes que a los procesos.

 

• Emplea desarrollo ágil: iterativo e incremental.

 

El desarrollo se inicia desde la visión general de producto, dando detalle solo a las funcionalidades que, por ser las de mayor prioridad para el negocio, se van a desarrollar en primer lugar, y pueden llevarse a cabo en un periodo de tiempo breve (entre 15 y 60 días).

 

Cada uno de los ciclos de desarrollo es una iteración (sprint) que produce un incremento terminado y operativo del producto. Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves de seguimiento en las que todo el equipo revisa el trabajo realizado desde la reunión anterior y el previsto hasta la reunión siguiente. El protocolo de Scrum para Software definido por Jeff Sutherland y Ken Schwaber prescribe que las reuniones de seguimiento del sprint (iteración) sean diarias.

 

Control de la evolución del proyecto

 

Scrum controla de forma empírica y adaptable la evolución del proyecto, con las siguientes prácticas de la gestión ágil:

 

Revisión de las Iteraciones

 

Al final de cada sprint o iteración, se realiza una revisión con todas las personas implicadas en el proyecto. Este es el periodo máximo que se puede tardar en reconducir una desviación del proyecto o de las circunstancias del producto

 

Desarrollo incremental

 

 

En el proyecto, no se trabaja con diseños o abstracciones. El desarrollo incremental implica que al final de cada iteración se dispone de una parte del producto operativa que se puede inspeccionar y evaluar.

 

Desarrollo evolutivo

 

Como modelo ágil, es útil en entornos con incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales cómo será el resultado final, y sobre dicha predicción desarrollar el diseño y la estructura del producto no es realista, porque las circunstancias obligarán a remodelarlo muchas veces. ¿Para qué predecir los estados finales de la estructura, arquitectura o diseño si van a estar cambiando? Scrum toma a la inestabilidad como premisa; por eso el protocolo de las prácticas de trabajo que se diseñen tiene que permitir la evolución continua sin degradar la calidad de la arquitectura, que se irá generando durante el desarrollo. Con Scrum, el diseño y la estructura del resultado se construyen de forma evolutiva. No se considera que la descripción detallada del producto, del servicio, de la estrategia o de la arquitectura del software (según el caso) deban realizarse en la primera “fase” del proyecto. El desarrollo ágil no es un desarrollo por fases.

 

En la aplicación de Scrum para software, para evitar los problemas de degradación del sistema o de la arquitectura por la evolución continua del producto se deben incluir prácticas de refactorización en las tareas de diseño y codificación.

 

Auto-organización

 

Durante el desarrollo de un proyecto surgen circunstancias impredecibles en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos. En Scrum los equipos son auto-organizados, con margen de decisión suficiente para tomar las decisiones que consideren oportunas.

 

 

Que puedo decir, solo que es la oficina ideal de los informaticos o los que tienen afines con la carrera.

 

 

 

 

Muy bueno ciero. Fuente: M@atinX