martes, marzo 27, 2007

Así es la izquierda ...

La escritora Almudena Grandes dice que cada mañana "fusilaría" a dos o tres voces que le "sacan de quicio" En una rueda de prensa en Sevilla, quiso añadir que "estamos en un país en el que la derecha española recuerda más a la de la II República que a la del franquismo". Grandes, que colabora con el Grupo Prisa, resaltó que este sector de la sociedad reclama el derecho a gobernar "por gracia divina". Así, Almudena Grandes resaltó que "es una reacción que se ha repetido a lo largo de la historia pero, que esta vez, el Ejército, la coyuntura internacional, las instituciones y los ciudadanos ya no son lo que eran".

Leia Mais…

martes, marzo 13, 2007

I'm a techie !

eXtreme Programming

La programación extrema ( eXtreme Programming ) o XP , es una disciplina de desarrollo basada en la simplicidad. XP aparece para, que equipos pequeños que necesitan desarrollar software rápidamente, puedan realizarlo en un ambiente donde los requisitos cambian rápidamente.

La metodología de Desarrollo de Software, siempre necesitará ser modificada para adaptarla a los requisitos particulares del cliente y de las circunstancias. XP no es ninguna excepción.

Hay doce prácticas para aplicar XP:

El proceso de planteamiento o juego de la planificación

      Permite que el XP cliente defina el valor de negocio y las características deseadas, y utiliza las valoraciones de coste proporcionadas por los programadores, para elegir si necesita ser desarrollado o dejar aparcado. Con este proceso es fácil llevar el proyecto a ?buen puerto? .
Entregas pequeñas
      La idea es producir rápidamente versiones del sistema que sean operativas, aunque obviamente no cuenten con toda la funcionalidad, pero constituyan un resultado de valor para el negocio.
Metáfora
      Una metáfora, es una historia compartida que describe cómo debería funcionar el sistema. El sistema es definido por una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. La metáfora consiste en formar un conjunto de nombres que actúen como vocabulario para hablar sobre el dominio del problema.
Diseño simple
      Se debe diseñar la solución más simple que puede funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el código extra debe ser removido inmediatamente.
Pruebas
      La producción de código está dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el código y son ejecutadas constantemente ante cada modificación del sistema. En este desarrollo y pruebas constantes, la automatización para apoyar esta actividad es crucial.
Refactorización (Refactoring)
      La refactorización es una actividad constante de reestructuración del código con el fin de remover duplicación de código, mejorar legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios. Para mantener un diseño apropiado, es necesario realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
Programación en parejas
      Toda la producción de código debe realizarse en parejas de programadores. Muchos errores son detectados conforme son introducidos y la tasa de errores del producto final son mucho menores, los diseños son mejores y el tamaño del código menor, los problemas de programación se resuelven más rápido, se transfieren los conocimientos de programación entre los miembros del equipo, varias personas entienden las diferentes partes del sistema, mejora el flujo de información y la dinámica del equipo.
Propiedad colectiva
      Cualquier programador puede cambiar cualquier parte del código en cualquier momento. Esta práctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algún programador sea imprescindible para realizar cambios en alguna porción de código.
Integración continúa
      Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en un mismo día. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo código sea incorporado definitivamente. La integración continua a menudo reduce la fragmentación de los esfuerzos de los desarrolladores por falta de comunicación sobre lo que puede ser reutilizado o compartido. Esto es esencial para un proyecto controlado.
40 horas por semana
      Se debe trabajar un máximo de 40 horas por semana. No se trabajo horas extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que debe corregirse. El trabajo extra desmotiva el equipo. Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificación para cambiar el ámbito del proyecto o la fecha de entrega.
Cliente in-situ
      El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran parte del éxito del proyecto XP se debe a que es el cliente quien conduce constantemente el trabajo hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. Algunas recomendaciones propuestas para dicha situación son las siguientes: intentar conseguir un representante que pueda estar siempre disponible y que actúe de interlocutor del cliente, contar con el cliente al menos en las reuniones de planificación, establecer visitaqs frecuentes de los programadores al cliente para validar el sistema, anticiparse a los problemas aosociados estableciendo llamadas telefónicas frecuentes y conferencias, reforzando el compromiso de trabajo en equipo.
Estándares de programación Es indispensable que se sigan ciertos estándares de programación. Estos mantienen el código legible para los miembros del equipo, facilitando los cambios. Fuentes de Errores
Como se puede ver gana la toma de requerimientos . Y también:
    • No disponer de ningún mecanismo de control de cambio
    • Evitar cambios de alcance durante el proyecto
    • Parálisis del proyecto debido a un excesivo tiempo recogiendo requisitos
    • No hacer captura de requisitos de ningún tipo
    • No realizar planificación de las iteraciones (tras pasarse a un método supuestamente ágil)
    • Demasiada planificación de las iteraciones
Julián Macías GIS & JAVA DEVELOPMENT

Leia Mais…

lunes, marzo 12, 2007

Nuevas Tecnologías

Artículo 17.1 de la Ley de Servicios de la Sociedad de la Información y de Comercio electrónico. (aka LSSI) Los prestadores de servicios de la sociedad de la información que faciliten enlaces a otros contenidos o incluyan en los suyos directorios o instrumentos de búsqueda de contenidos no serán responsables por la información a la que dirijan a los destinatarios de sus servicios, siempre que:

a) No tengan conocimiento efectivo de que la actividad o la información a la que remiten o recomiendan es ilícita o de que lesiona bienes o derechos de un tercero susceptibles de indemnización, o

b) Si lo tienen, actúen con diligencia para suprimir o inutilizar el enlace correspondiente.

Se entenderá que el prestador de servicios tiene el conocimiento efectivo a que se refiere la letra a) cuando un órgano competente haya declarado la ilicitud de los datos, ordenado su retirada o que se imposibilite el acceso a los mismos, o se hubiera declarado la existencia de la lesión, y el prestador conociera la correspondiente resolución, sin perjuicio de los procedimientos de detección y retirada de contenidos que los prestadores apliquen en virtud de acuerdos voluntarios y de otros medios de conocimiento efectivo que pudieran establecerse.

Leia Mais…

Entradas populares