SQL Compact Edition

Presentación

SQL Compact Edition es un nuevo integrante de la familia SQL de Microsoft, y se trata de un motor SQL muy liviano y portable, pensado para utilizar pequeñas bases de datos en forma local.
Esta nuevo producto es la evolución de SQL Mobile Edition, el cual nos permitía tener un "mini" motor SQL en dispositivos portátiles (PocketPCs, Smart Phones), ahora extendido al resto de la sistemas operativos Windows (Tablet PCs y computadoras de escritorio).



Arquitectura

SQLCe, a diferencia de sus hermanos mayores, no se trata de un servicio de datos (tipicamente accesible de forma permanente, esperando consultas de aplicaciones cliente, locales o remotas), sino que se trata de una libreria (dll) que es refernciada por la aplicación cliente, es un motor "embebido" en la aplicación, optimizado para dispositivos de escritorio o portátiles.

Características Principales

• SQLCe acepta sintaxis Transact-SQL, lo que lo vuelve facilmente escalable a sus hermanos mayores (SQL Express Edition, Standard Edition, etc). Aún así a la hora de portar código desde/hacia otro SQL Server es necesario tener en cuenta algunos puntos, por ejemplo: los tipos de datos en SQLCe, son un subconjunto de los disponibles para SQL Express Edition.
• No pueden utilizarse Stored Procedures, esta limitación es clave a la hora de pensar en escalabilidad. Puede ser el punto que nos lleve a inclinarnos por SQL Express Edition. Más adelante, en una comparación entre SQLCe y SQL EE voy a resumir algunas razones por las que podría prescindirse de Stored Procedures.
• Una base de datos SQLCe se almacena en un único archivo, lo que facilita la transferencia de bases de datos individuales.
• SQLCe es un conjunto de librerías de alrededor de 2Mb, que pueden ser distribuídas con nuestra aplicación sin necesidad de registrar componentes, ni servicios, por lo tanto, no se necesitan privilegios de administrador durante la instalación, y los recursos de memoria y espacio en disco son mínimos.
• Dado el tipo de dispositivos en los que SQLCe pretende funcionar (desde notebooks, pc's de escritorio a pocket pcs y smartphones), cuenta con características de seguridad, y protección contra errores (robo, perdida de energía) que son exclusivos para estas plataformas.
• Herramientas para la sincronización de datos con SQL Server 2005
  
  

Veamos algunos puntos a tener en cuenta al decidir entre SQL Compact Edition y otras bases de datos locales.

SQL Compact Edition vs. XML o Archivos de Texto

• Consultas, transacciones y manipulación de los datos
• Encriptación nativa

SQL Compact Edition vs. Access o FoxPro

• Integración con Visual Studio
• Compatibilidad con el resto de la familia SQL Server

SQL Compact Edition vs. SQL Express Edition

SQL Compact Edition y SQL Express Edition se presentan como las dos opciones, ambas gratuitas, a la hora de implementar bases de datos locales en PC's de escritorio (Windows XP/Vista o Tablet PC), en cambio la opción es clara para dispostitivos móviles (SQLCe), y para bases de datos centrales, multiusuario (SQL Express).

• Stored Procedures

Para los que estén acostumbrados a trabajar con bases de datos centrales, de gran escala, con múltiples usuarios accediendo concurrentemente con diversos privilegios, resulta inmediato basar la capa de datos en Stored Procedures, las históricas razones de esto son 3, voy a resumir porque estas razones podrían no tener tanto peso en un escenario muy distinto, como es una base de datos embebida, local y monousuario (escenario al que apunta SQL Ce).

1. Rendimiento: Los stored procedures permiten ejecutar código de acceso a datos, optimizado para este uso. Sin embargo teniendo un solo usuario, sobre una base de datos local, implica que las consultas no llegarán con mayor concurrencia que los clicks de un usuario, por lo tanto (en lo que a performance se refiere) resulta aceptable codificar esta lógica procedural en la capa de datos de la aplicación.
2. Abstracción: Acceder a los datos únicamente con stored procedures, es una forma de construir una capa de abstracción sobre éstos, sin embargo tanto el motor de SQLCe como las bases de datos pueden ser distribuídas y versionadas junto con la aplicación, y el beneficio de mantener esa abstracción ya no resulta tan evidente.
3. Seguridad: Una vez más, los stored procedures permiten restringir el acceso a los datos, permitiendo únicamente ciertas operaciones sobre éstos, sin embargo la base de datos es distribuída con la aplicación y el usuario es único, en este escenario tienen más sentido otras medidas de seguridad, como encriptar la base de datos, e incluir en ésta únicamente el subconjunto de datos que el usuario local necesita.
4. Dicho esto, por supuesto hay que evaluar la escalibilidad de nuestra aplicación, para evitar a toda costa verse en un futuro en la situación de traducir procedimientos C#/Vb.NET, a Transact-SQL.

• Recursos, SQL Ce requiere de solo 2Mb en disco y un uso de memoria y procesador muy inferiores a SQL Express Edition, que al instalarse ocupa alrededor de 200Mb en disco, y al ser un servicio, se encuentra constantemente esperando ser invocado por una aplicación cliente (a pesar de estar preparado para "adormecerse" en períodos de inactividad)
• Instalación, SQL Ce, puede distribuirse con nuestra aplicación, de manera que no requiera privilegios de administrador para instalarse y poder controlar su versionado. Alternativamente puede (como SQL Express) instalarse mediante un MSI, y recibir actualizaciones de Windows Update.
• Almacenamiento, Ambos motores esta limitados a bases de datos de 4Gb, sin embargo las bases de datos de SQLCe estan contenidas en archivos individuales, "code-free" (sin código ejecutable, no sucede lo mismo con bases de datos de SQL Express), que pueden ser encriptados y protegidos con contraseña. Por lo tanto estos archivos pueden ser facilmente enviados, backupeados y asociados a una aplicación mediante una extensión de archivo particular.

Sql Ce con Enterprise Library 3.0

Una de las novedades en Enterprise Library 3.0 es la incorporación de clases para el manejo de SQL Compact Edition, bajo el nuevo namespace System.Data.SqlServerCe.

Una curiosidad es que el manejo de conexiones abiertas es distinto a los demás providers en Enterprise Library, por lo cual es aconsejable (para mantener la performance) utilizar transacciones para mantener una conexion abierta en operaciones en lote. Este comportamiento es explicado aqui:

http://www.codeplex.com/entlib/WorkItem/View.aspx?WorkItemId=9005

(fue reportado como bug, aunque la respuesta aclara que fue una decisión de diseño)

Links

http://www.microsoft.com/sql/editions/compact/default.mspx

http://www.microsoft.com/sql/editions/compact/sscecomparison.mspx

http://www.codeplex.com/entlib/WorkItem/View.aspx?WorkItemId=9005

Leer más...

Cryptography Application Block

Introducción

Este es un bloque de aplicación integrado en las versiones de Enterprise Library 2.0 y 3.0, basado en la criptografía, que intenta facilitarla y acercarla a los desarrolladores y sus aplicaciones, pudiendo utilizarlo para encriptar información, crear datos compactados y compararlos para verificar que la información no ah sido alterada.

Dentro de las principales características encontramos

Reduce los requerimientos para escribir código normalizado proveyendo implementaciones para solucionar problemas comunes de criptografía.

Ayuda a mantener prácticas consistentes de criptografía en la aplicación y la empresa.

Facilita la curva de aprendizaje de los desarrolladores usando un modelo de arquitectura consistente a través de varias áreas de funcionalidad que son provistas.

Provee implementaciones que pueden ser utilizadas para resolver los problemas básicos.

Es esténcil y soporta implementaciones adicionales de criptografía.

Escenarios comunes

Los desarrolladores frecuentemente escriben aplicaciones que requieren encriptación y compactación de datos, para cumplir los requerimientos de seguridad de la organización. Tanto los datos que son creados y mantenidos por las aplicaciones como la información de configuración necesitan ser resguardadas. Adicionalmente las contraseñas que son usadas para acceder a la funcionalidad o datos de la aplicación requieren compactación. También favorece la abstracción del código de la aplicación respecto al de los proveedores de criptografía, permitiendo el cambio en la encriptación sin necesidad de modificaciones en el código del resto de la aplicación.
Este bloque solo soporta algoritmos simétricos, que utilizan una misma llave para ambos procesos, pero no así los asimétricos, para los cuales el método de encriptación y desencriptación difieren en el código.

Objetivos

Proveer una interfase simple e intuitiva para las funcionalidades más comúnmente requerida.

Encapsular la lógica de encriptación.

Lograr un modelo consistente y estandarizado para las tareas comunes relacionadas con la criptografía.

Asegurar un bloque de aplicación extensible.

Minimizar el impacto de las funciones criptográficas al resto de la aplicación.

Proveer un modelo basado en una “llave” que puede ser modificada por el usuario, para personalizar la encriptación.

Estructura y posibilidades

El bloque separa las implementaciones de la encriptación y el resto de la aplicación permitiéndonos modificar uno sin alterar en nada el funcionamiento del otro. Dentro del mismo podemos encontrar con tres diferentes ámbitos.

La clase “Cryptographer” es una interfase que media entre el código de la aplicación y las funciones del “Cryptography Application Block”. El código del cliente llama a métodos estáticos de esta clase para crear compactaciones de información, compararlas, encriptar y desencriptar datos. Cada método estático llama a una clase de generación y pasa el código de configuración al constructor de la clase, con el mismo la clase determina que tipo de proveedor crear.

La clase “DpapiCryptographer” utiliza DPAPI (Data Protection API) para encriptar y desencriptar datos. DPAPI utiliza las credenciales de logueo para encriptar los datos, las mismas pueden ser de un usuario en una máquina o dominio, o de una computadora dentro de una red. En el caso de utilizar las credenciales de logueo de un usuario en una máquina, estas permiten que cualquier aplicación que el mismo usuario ejecute, pueda desencriptar toda información resguardada bajo la misma llave. Para no permitir esto se puede utilizar una clave o “entropy”. Hay métodos sobrecargados en la clase que permiten encriptar y desencriptar utilizado esta clave.
Es importante remarcar que la necesidad de resguardar la seguridad de esta clave es tan necesaria como la encriptación de la información sensible.

La clase “SymmetricCryptographer” encapsula la implementación de la clase base abstracta “SymmetricAlgorithm”, la cual se encuentra dentro de “System.Security.Cryptography” en el .NET Framework. Esto significa que la clase en cuestión nos permite utilizar cualquier algoritmo simétrico de encriptación como por ejemplo el “Rijndael”. El bloque de aplicación utiliza DPAPI para encriptar y desencriptar la clave del algoritmo simétrico.

Conclusiones

Este bloque de aplicación no intenta solucionar todos los casos en los cuales el resguardo de información y por ende la encriptación de los datos es necesaria, sino facilitar a los programadores novatos los primeros pasos, sin perder de vista que para determinadas aplicaciones, este bloque es lo suficientemente completo como para cumplir con todos los requisitos de seguridad de la misma. Con esto queremos concluir en que si bien el bloque es muy útil en muchos tipos de aplicaciones no hay que forzar la utilización del mismo en cualquier desarrollo, sino estudiar previamente si cumple con los requisitos que tenemos en ese momento.

Leer más...

Accediendo a la configuración

La clase ConfigurationManager (incluida a partir de la versión .Net 2.0) perteneciente al NameSpace System.Configuration, nos permite acceder a los archivos de configuración de nuestra aplicación.

Esta incluye miembros que permiten llevar a cabo las siguientes tareas:

• Leer una sección de un archivo de configuración.


• Leer y escribir totalmente archivos de configuración.


• Compatibilizar tareas de configuración.

Un motivo importante para utilizarla, es que nos independiza del tipo de aplicación final que estemos construyendo (Aplicación de escritorio, Sitio Web, Web Service, etc).

Para poner un ejemplo práctico, en una aplicación en 3 capas típica, es normal querer obtener el String de Conexión en la capa de acceso a datos, para poder conectarnos con nuestra base de datos.

Supongamos que este String de conexión lo tenemos almacenado en el archivo de configuración de nuestra aplicación (app.config para una aplicación WinForms, web.config en una aplicación ASP.NET, etc) .

Una de las maneras de acceder a esta información sería escribir el siguiente código dentro de nuestra capa de acceso a datos, sin importar que tipo de aplicación final la este consumiendo:

string conString = System.Configuration.ConfigurationManager.
 ConnectionStrings["Conexion"].ConnectionString;

Para este ejemplo en particular deberíamos incluir en nuestro archivo de configuración, estas lineas dentro del tag Configuration:

<connectionstrings>
<add name="Conexion" connectionstring="Data Source=localhost;
 Initial Catalog=NombreBD; Integrated Security=True">
</connectionstrings>

Utilizar las clases que nos provee .Net FrameWork es una buena práctica, principalmente para no perder tiempo en escribir código, que ya tengamos disponible para nosotros.

Para poder acceder a esta clase debemos referenciar al ensamblado: System.Configuration (en system.configuration.dll).

Este es uno de los usos que le podemos dar a esta clase, quizás el más utilizado, para más información dejo un link.

http://msdn2.microsoft.com/es-es/library/system.configuration.configurationmanager(VS.80).aspx

Leer más...

Lean Product Development

Lean es una metodologia genérica para mejorar la calidad y productividad. Es usada exitosamente en industrias de manufacturación o logística.

Lean Product Development es una variación de la metodologia Lean, toma los principios Lean para aplicarlos en el diseño y producción de software. Se basa en la identificación y eliminación de cualquier fuente que genere "desperdicios", para que los objectivos globales se cumplan exitosamente, estimulando la productividad. El uso de esta metodologia puede ser el paso previo al uso de metodologías de las llamadas Agiles.

Los principios Lean, aplicados al desarrollo de software, son:

• Eliminar los desperdicios
  Es el principio fundamental y del cual dependen el resto de los principios.
  Significa invertir el tiempo solo en aquello que agregue valor real. Hay que entender cual es el valor real y qué actividades y recursos son necesarios para crearlo. A menudo, el trabajo de determinar qué es y qué agrega valor se hace en los niveles altos de la jerarquía.
  
  Los principales tipos son:
  Funcionalidad que se desarrolla y no se utiliza en producción. Esto genera código extra, el cual tuvo que seguirse, compilarse y testearse, el mismo incrementa la complejidad y es un posible punto de fallo.
  La documentación, consume recursos, demoras, se pierde y se vuelve obsoleta. Si se utiliza, que sea solo la necesaria.
  Asignar una misma persona a múltiples proyectos. Cada vez que el desarrollador de software tiene que cambiar entre tareas, pierde un tiempo significativo para recordar de que se trataba el proyecto. Pertenecer a diferentes equipos de trabajo causa más interrupciones que beneficios.
  Las Esperas, uno de los grandes desperdicios, en cuanto a tiempo, es esperar a que sucedan cosas: se espera al comienzo del proyecto, en la definición de requerimientos, en el armado de la excesiva documentación, en la codificación, en revisión y aprobación, en testeo, etc.
  Puesta en marcha, cuando un desarrollador tiene una pregunta, ¿cuanto cuesta encontrar la respuesta? Los requerimientos van a los analistas, de los analistas a los diseñadores, de aquí a los desarrolladores y luego al testeo… en cada pasaje es probable que se pierda algo, ya que un porcentaje de conocimiento tácito queda con el creador del documento y no se transmite.
  Errores en el Software, el porcentaje de desperdicio causado por un error se puede medir como el impacto del mismo por el tiempo sin ser detectado. Hay que encontrarlos en cuanto ocurran, corregirlos, testearlos y actualizar la versión en producción.

• Ampliar el aprendizaje
  Hay que incrementar el feedback con el usuario, para poder determinar con la mayor exactitud posible lo que desea y para resolver los problemas complicados que se presenten. Esto derivará en que la funcionalidad que se desarrolle sea exactamente lo que el usuario deseaba y que la utilice, de esta forma se puede eliminar alguna fuente de despercidio.
  Se puede, por ejemplo, mostrar al usuario los bosquejos de las pantallas de la aplicación y así tener su punto de vista, no solo del diseño visual, sino también de la funcionalidad.
  

  También es necesario incrementar el feedback dentro del equipo de trabajo, lograr que todos los involucrados conozcan el problema y participen en la resolución.
  Por ejemplo, se pueden hacer tests periódicos para detectar rápidamente cuando un proceso no funciona. Esto nos permite aprender mediante la experimentación.

• Decidir lo mas tarde posible
  La idea no es aplazar la toma de decisiones, sino poder tomar una decisión en el momento de mayor certeza, así la misma estará basada en conocimiento concreto, no en especulación.
  

  La idea es esperar hasta el momento en que se encuentre disponible la mejor y mayor información. De esta forma, se evitarán cambios en la etapa final del desarrollo, y se bajarán los costos del mismo.

  Por ejemplo, antes de desarrollar una funcionalidad de diferentes formas, es mejor comunicarlas y decidir junto al usuario.

• Entregar lo mas temprano posible
  Hacer entregas de funcionalidad rápidamente tiene muchas ventajas:
  El usuario tiene la funcionalidad que necesita cuando la necesita
  Se tiene un feedback más confiable por parte del usuario
  Se puede retrasar la toma de decisiones: se pueden tener varias opciones hasta estar mejor informado.
  Es mas claro, para el equipo de trabajo, de qué forma contribuir más efectivamente: pueden resolver qué hacer y cómo por si solos..

• Dar poder al equipo
  Se le da prioridad a la gente y a los equipos de colaboración por sobre los procesos.
  Al reconocer que las personas que realizan el trabajo son las que conocen los detalles, se focaliza en métodos de formación de equipos para que puedan resolver sus propios problemas. Se los involucra en la toma de decisiones, de esta forma se logra que cada integrante el equipo se sienta participe del proyecto y la organización, y, por lo tanto, usen su potencial al máximo.
  El líder del equipo se encargara de marcar el objetivo, establecer ciertas pautas de trabajo, ser el guía.

• Construir Integridad
  Se pueden encontrar 2 clases distintas de integridad: Perceptiva, Conceptual.
  La integridad perceptiva tiene que ver con la percepción que tiene del cliente del sistema, cuanto mas a gusto este y cuanto mas cercano sea a sus exigencias y requerimientos, mas alta será la integridad perceptiva.
  La integridad conceptual significa que el concepto central del sistema trabaje en conjunto, como un todo cohesivo, y es un factor crítico que impacta en la integridad perceptiva.
  Otro nivel de integridad para el software es aquel que esta relacionado con la adaptabilidad del mismo en el futuro. Un software con integridad tiene una arquitectura coherente, se ajusta a los propósitos, es mantenible, adaptable y extensible fácilmente.
  La integridad se puede lograr con un sabio liderazgo, comunicación efectiva y una disciplina saludable.

• Ver el Todo
  La integridad, en sistemas complejos, require una profunda experiencia en diversas areas. Uno de los problemas mas difíciles a tratar en el desarrollo de un producto es que los expertos en alguna area especifica tienden a maximizar la performance de la parte del producto que representan, en lugar de hacer foco en la performance del sistema en gral. Esto se denomina Sub-Optimización. El desafio es implementar practicas que la eliminen.

Conclusión

La aplicación de los principios Lean en el desarrollo de software permite mejorar los procesos y asi obtener mejores resultados.

Aumenta la calidad del producto, posibilitando bajar los costos y acortar los tiempos de desarrollo.

Estos principios son una guia, son algo general y universal, las metodologias agiles serian la forma de aplicar esta guia en la practica, indican qué hacer, adaptadas al dominio.

Lo importante es poder entender y adoptar la escencia de los principios Lean. Es claro que su aplicación puede ser dificil en algunas companias, ya que requiere un cambio importante en la cultura y en los habitos organizacionales. Pero las mejoras que se pueden lograr son importantisimas, no solo en el producto final sino tambien en su evolución, en la participación, compromiso y satisfacción de las personas involucradas.

Para leer mas sobre LSD y como aplicarlo: "Lean Software Development: An Agile Toolkit", autores: Mary y Tom Poppendieck.

Leer más...

De XP, Scrum, RUP, CMM(I), Crystal Clear y otras yerbas

En la búsqueda de cómo optimizar nuestra forma de trabajo, nos encontramos frecuentemente ante la duda de "qué metodología aplicamos". Para dar respuesta a esa pregunta, y sabiendo de antemano que queremos movernos dentro de prácticas ágiles, nos fue útil tratar de conocer, evaluar y en algunos casos, ensayar, distintas alternativas.

Por el momento optamos por seguir algunas de las directivas propuestas por Crystal Clear, pero entendemos que el proceso de decidir qué metodología implementar es un trabajo constante y debe responder a las necesidades del negocio y al crecimiento del equipo.

Sin ser especialistas en el tema, describimos brevemente algunas comparaciones entre Crystal Clear (http://ideas3p.blogspot.com/2007/02/ms-all-de-las-capacidades-tcnicas-que.html) y otras metodologías.

eXtreme Programming (XP)

Crystal Clear comparte algunas características con XP (iteraciones cortas, entregas frecuentes, contacto directo con usuarios) pero es un poco menos demandante, es un buen punto de comienzo antes de lanzarse a abordar XP.

• Las iteraciones en XP deben ser más cortas: de 1 día a 1 mes y no propone reglas sobre la duración de cada ciclo, a diferencia de CC que requiere que las entregas no se extiendan más allá de 3 meses, pero permite que la iteración pueda ser tan larga como el entregable.
• XP requiere pair programming, CC no. Esto es porque XP apunta reducir el grado de libertad en las elecciones técnicas de los miembros del equipo para hacer las decisiones más efectivas. CC es más tolerante y flexible permitiendo al equipo adecuar sus propias convenciones a cada proyecto.
• XP requiere tests automatizados con un gran conjunto de unit tests e integraciones varias veces al día. CC sólo recomienda lo primero y el período de integración puede variar según la complejidad de cada proyecto.
• XP requiere un usuario como miembro del equipo, mientras que CC sólo promueve el “fácil acceso a los usuarios clave” con un mínimo de 1 hora a 1 semana de tiempo. Se busca el tiempo mínimo que permita satisfacer la seguridad del proyecto.
• XP habla explícitamente de “simplicidad en el diseño y refactoring” como parte del largo término del desarrollo (a lo largo de todo el proceso). CC lo recomienda en las estrategias “Walking Skeleton” y “Rearquitectura Incremental”. Si bien CC aboga por diseños simples y refactoring, la duda es si esto tiene que ser un estándar de la metodología.
• XP no requiere casi documentación, CC si. En términos de los 2 objetivos principales del “modelo de juegos cooperativos”
  

Scrum

Scrum se focaliza en 3 prácticas (además de tener a la comunicación como uno de sus pilares).

• Time-Boxing: el subconjunto de requerimientos a ser desarrollados durante cada iteración se “congela” al principio de las mismas. Esto permite al equipo trabajar concentrados en los temas sabiendo que los mismos no van a cambiar.
• Dynamic backlog: para compensar este “congelamiento” de requerimientos durante cada iteración, se lleva una lista de todo lo que resta por hacer. Esta lista puede cambiar cada vez que sea necesario. Al inicio de cada período el equipo revisa la lista, reprioriza los requerimientos, selecciona los que se van a desarrollar en esa iteración y los “congela” nuevamente.
• Reuniones diarias: el equipo se reune cada día en una reunión muy rápida para comentar qué hizo el día anterior, qué va a hacer ese día y qué le resta por hacer.

Estas tres técnicas serían el paralelo de las tres principales prácticas de Crystal (entregas frecuentes, comunicación, reuniones de reflexión).

RUP (Rational Unified Process)

RUP es similar a Crystal en cuanto a su estructura. Ambos son “generadores de metodologías”
Los dos coinciden en que no hay un único proceso a aplicar en todos los proyectos.

Ambos recomiendan un crecimiento incremental de la aplicación usando desarrollo por iteraciones, buenas prácticas de testing, contacto cercano y feedback con los usuarios y manejo de riesgos.

Pero las diferencias de base se encuentran en los siguientes puntos:

• RUP requiere definir una arquitectura, modelaje visual y uso de herramientas como puntos fundamentales. Crystal considera la arquitectura como propia de cada proyecto. Para el caso del modelaje visual, Crystal propone que el grado de detalle de la documentación es propio de cada proyecto y la documentación debe ser considerada como soporte y no como guía. Además, Crystal no cree en la necesidad de basarse en herramientas, sobre todo cuando éstas se usan para modelar.
• Así como Crystal sostiene que cada metodología que se genere debe ser lo más simple, llana y eficiente que sea posible, RUP no declara la necesidad de características como estas.

CMM(I) - Capability Maturity Model Integration

Partiendo de la base que Crystal Clear no fue pensado para cumplir los requerimientos de CMM(I), muchas de las actividades que propone también son invocadas desde CMM(I), teniendo en cuenta que una de las principales diferencias es que Crystal se focaliza en proyectos mientras que CMM(I) apunta a organizaciones.

Por otro lado, pensar que una organización que certifica en CMM(I) pueda incorporar algunos puntos impulsados por Crystal es altamente probable, y puede ayudar a incrementar su eficiencia

Por ejemplo, ubicar al equipo en un espacio que permita una fuerte comunicación o adoptar las reuniones de reflexión no violan ninguna de las reglas de CMM(I). Tampoco lo hacen el apuntar a lograr seguridad personal, el tener fácil acceso a los usuarios expertos, el lograr un entorno tecnológico con testing automatizado o la práctica de integraciones frecuentes. Algunos puntos pueden llevar más trabajo, pero son totalmente aplicables.

Evidentemente una de las mayores diferencias reside en que CMM(I) está soportado por una organización que capacita y actúa como evaluadora, cosa que no ocurre con Crystal.

Y qué hacemos con todo esto ?

En nuestra experiencia de pequeña empresa "con inquietudes de hacer las cosas mejor", por el momento nos volcamos a tomar ciertos aspectos de algunas de estas metodologías ágiles, sin ajustarnos estrictamente a una en particular y siguiendo fundamentalmente la regla principal de Crystal Clear de evaluar en cada momento y para cada proyecto, qué herramientas conviene aplicar.

Suponemos que una evolución natural de la empresa y del equipo nos irá orientando a la adopción de prácticas más formales, como puede ser CMM(I), pero seguramente al momento de elegir cómo encarar nuestros trabajos seguiremos valorando la posibilidad de flexibilidad por encima de otras capacidades.

Para consultar a los que saben:

XP: http://www.salias.com.ar/articles.asp ; http://www.agilealliance.org/

Scrum: http://www.scrumalliance.org/

RUP: http://www-306.ibm.com/software/rational/

“Crystal Clear – A human powered methodology for small teams”, de Alistair Cockburn http://alistair.cockburn.us/index.php/Crystal_methodologies_main_foyer

Leer más...

C# null coalescing operator

A partir de la versión 2.0 de .NET, aparece para c# un nuevo operador "??", que es muy útil.

Este nos permite devolver el valor que nosotros queramos, cuando una variable por ejemplo es Null, similar al isnull() del Transact-SQL.

La forma de utilizarlo es muy simple veamos un ejemplo:

Al utilizar esta Clase si queremos leer la propiedad Nombre y esta no fue asignada previamente, devolverá el mensaje de Nombre no disponible.

public class Persona
{
    private string nombre;

    public string Nombre
    {
        get
        {
            return nombre ?? "Nombre no disponible";
        }
        set
        {
            nombre = value;
        }
    }
}

Cabe aclarar que este operador solo puede utilizarse con Tipos que acepten valores nulos.

Leer más...